Guest6667 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
joerg has joined #glasgow
setrofim has quit [Ping timeout: 248 seconds]
trh has quit [Quit: weg]
trh has joined #glasgow
redstarcomrade has quit [Quit: Connection closed for inactivity]
setrofim has joined #glasgow
roybatty2019 has quit [Quit: WeeChat 3.8]
roybatty2019 has joined #glasgow
balrog has joined #glasgow
hanetzer has joined #glasgow
<hanetzer>
hello folks. interesting project here. was hoping to get some answers on some things. for use as a logic analyzer: is the 100Mhz sampling rate a hard limit of hardware?
<hanetzer>
(intending to sniff the LPC bus (33.3Mhz, 6 signals) on a desktop machine. I can already do 100Mhz via my beaglebone black with beaglelogic and that's not quite cutting it). I mean it as in, if you were to minmax the device to *only* sample 6 pins as fast as possible and shut down all the other goodies, could one surpass that limit, or is the device simply incapable of it?
lxdr has quit [Remote host closed the connection]
lxdr has joined #glasgow
<d1b2>
<zyp> have you considered synchronous sampling on the LPC clock instead of asynchronous oversampling?
jstein has joined #glasgow
<hanetzer>
as in, run at lpc clock speeds and 'be careful' about reading?
<d1b2>
<zyp> as in, trigger reading directly from the LPC clock
<hanetzer>
either way, 33.3Mhz is more (I think) than I can spit out with, say for example, my raspi pico (12mbps) unless I'm misunderstanding something.
<hanetzer>
over usb*
<hanetzer>
(I don't have a glasgow yet [does anyone in the general public?], but even if I solve my problems without it I'll still prolly get one, looks neat)
<d1b2>
<zyp> 6 bits at 33.3 MHz is reasonably within what HS USB can sustain streaming, even if you pad each sample out to a full byte
<d1b2>
<zyp> but it makes sense to do further decoding on the device so you only have to send the useful data
<hanetzer>
tru. trick is I gotta figure out exactly how pio works. I get the idea of it, but no idea how to deal with the data on the c side of things :P
<hanetzer>
I should continue reading the datasheet more
<hanetzer>
however, unless I'm mathing it wrong, is not a byte every 33.3Mhz 'too fast' for usb hs? is that not 33.3Mhz*byte something like 133.3mbps?
<d1b2>
<zyp> HS is 480 Mb/s, your 12 Mb/s is FS
<d1b2>
<Rogan> That is a very odd bot relaying to Discord 😱
<hanetzer>
yeah, and you responded with the hs comment after I mentioned pico, so I got mixed up.
<hanetzer>
oof, June. but yeah, glasgow *is* properly rigged for HS?
<hanetzer>
still gonna grab one tho, it looks neat.
redstarcomrade has joined #glasgow
<hanetzer>
hrm... if I'm reading this right the bbb has a HS usb port... maybe with some massaging I can make the pru do what I want :P
jstein has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
fibmod has quit [*.net *.split]
Stary has quit [*.net *.split]
n0p has quit [*.net *.split]
elle has quit [*.net *.split]
fibmod has joined #glasgow
jstein has joined #glasgow
Foxyloxy has joined #glasgow
elle has joined #glasgow
n0p has joined #glasgow
Stary has joined #glasgow
jstein has quit [Max SendQ exceeded]
jstein has joined #glasgow
<d1b2>
<Rogan> Quite possible. An example using the PRU is BeagleLogic, which seems to have fallen by the wayside, but seemed to be making good use of the capabilities of the PRU
<d1b2>
<esden> @Rogan It looks fine over here. Maybe your discord client needs restarting? They sometimes get confused by the bots. :/
<d1b2>
<Rogan> Could be
<d1b2>
<Rogan> It is showing up correctly now (even before reloading my Discord browser window)
<d1b2>
<esden> Ok, at least it "sorted itself out" 😉
<d1b2>
<Rogan> love when that happens. Heisenbugs ftw!
<d1b2>
<esden> hehe, don't look to closely at the bug it might disappear 😉
<d1b2>
<zyp> I saw the same issue in #amaranth the other day
<d1b2>
<zyp> I couldn't spot an obvious pattern in it, but the names on several of the bridged messages changed several times
<d1b2>
<esden> Ohh interesting. I know that the bridge is using web hooks to modify names on the messages it posts to the channel. Maybe the webhook interface is being wonky.
<d1b2>
<zyp> something somewere was… one moment all messages looked like they were from wq, and then from somebody else
<d1b2>
<zyp> for a while it looked like all messages were from whoever wrote anything last, but that weren't entirely correct either
<d1b2>
<esden> all that IRC to Discord bridge cruft is severely unmaintained or at least undermaintained ... so oddness is to be expected as the stuff starts to bitrot
<d1b2>
<esden> Yeah that observation would make sense. I think the bot changes "it's name" before posting a message to imitate the IRC side user. So if the name update does not go through the discord system before the message is posted it will post with the name of the previous "person"
<d1b2>
<esden> At least it is able to correct things after the fact when it comes around to it.
<d1b2>
<zyp> ah, yes, that sounds like a plausible explanation
<d1b2>
<hanetzer> Yeah I have that a go, still not quite up to the task at 100mhz oversampling
<d1b2>
<hanetzer> Gave that a go*
<ar>
yeah, bridging between discord and irc is always a bit wonky, and especially if the irc side isn't "puppetting". matrix ↔ irc bridges only suffer from a bit of lag if your matrix instance (or the database it's using) is slow…
<d1b2>
<hanetzer> but yeah. if I'm reading my dd output right:
<d1b2>
<hanetzer> dd if=/dev/zero of=/dev/sda bs=1M count=64 oflag=dsync 64+0 records in 64+0 records out 67108864 bytes (67 MB, 64 MiB) copied, 8.29662 s, 8.1 MB/s then I don't have HS on that usb port :/
<d1b2>
<hanetzer> or if I do, its catching some overhead somewhere.
<d1b2>
<zyp> you absolutely do
<d1b2>
<hanetzer> should that not be 12 then? (480/8)
<d1b2>
<hanetzer> erm. wait. I'm ass at math apparently.
<d1b2>
<hanetzer> lmao
<d1b2>
<zyp> only if you assumed usb were the bottleneck
roybatty2019 has quit [Quit: WeeChat 3.8]
<d1b2>
<hanetzer> I mean, it is a bottleneck on the rp2040. and tbh I wish I could do it on that, because then it could be made into a nice plugin card :P
hanetzer has left #glasgow [WeeChat 3.8]
<d1b2>
<zyp> 8.1 MB/s is almost seven times as fast as you theoretically could push data through FS USB, so that device is obviously on a faster interface…
<d1b2>
<hanetzer> yeah I just somehow got it in my mind that 480/8 = 12, which is obviously wrong (I swear I'm not an idiot)
<d1b2>
<zyp> it's not strictly 480/8 either, since there's USB overhead involved
<d1b2>
<hanetzer> yeah, but as an estimate I mean.
<d1b2>
<hanetzer> but yeah... so, one byte every 33.3Mhz is what, 266Mbps ?
<d1b2>
<zyp> theoretical max HS throughput is around 53 MB/s, but in the real world 49 MB/s is a more realistic limit, and that's assuming one device gets a whole bus more or less to itself
<d1b2>
<hanetzer> well, there's only two usb ports on the bbb, and only one is populated in this scenario so yeh, its got all of it.
<d1b2>
<hanetzer> so if I can get the PRU to sync sample every clock pulse then I should in theory be able to get this data out in an expedient fashion.
<d1b2>
<hanetzer> just dd if=/dev/pru-lpc-bridge of=/dev/sda
<whitequark>
so I've started writing an LPC applet a long time ago
<whitequark>
but it bumped into deficiencies of Migen, which is a part of why we now have Amaranth
<whitequark>
no LPC applet though...
<d1b2>
<hanetzer> fun stuff :)
<whitequark>
we'll get there
<whitequark>
need to ship Amaranth 0.4 and then it's Glasgow time
<mwk>
glasgow is still mostly migen, right?
<mwk>
like there's a bunch of amaranth applets but the core logic is migen
<d1b2>
<zyp> isn't the entirety amaranth?
<whitequark>
it's entirely amaranth, but some of it is amaranth.compat
<whitequark>
amaranth.compat isn't migen; it's just using migen syntax
<mwk>
right, speaking of which
<mwk>
I had a go at converting the spi controller applet to native amaranth recently
<mwk>
and bumped into an issue
<mwk>
there's a bunch of other applets that reuse the controller gateware, and add some minor interface stuff on top of it
<whitequark>
oh right
<whitequark>
I hoped I could fix the architecture of the SPI applet before that
<mwk>
with amaranth.compat, they just directly add stuff on the subtarget; this doesn't work with amaranth, as the subtarget is an elaboratable at this point
<whitequark>
yeah
<mwk>
any preferences on how to deal with that?
<whitequark>
uhh, can you do like... anything that works and feels right for you for one applet and show me?
<whitequark>
it's probably fine but if it's not I'll come up with something and show how
<mwk>
I could wrap the entire subtarget with another top-level elaboratable
<whitequark>
all of that stuff is definitely getting rewritten anyway so it's not super important, as long as the solution is not too bad
<whitequark>
yeah sure
<whitequark>
that works
<mwk>
(well as "top-level" as applet code goes)
<d1b2>
<Attie> @hanetzer - to clarify zyp's comment on synchronous sampling, it's related to how / when the samples are actually captured... as LPC has a clock, you don't need to have a free-running and independent sample clock which is oversampling / running too fast... instead the sample can be taken at the correct time in line with the protocol - i.e: at 33.3 MHz
<d1b2>
<hanetzer> Yeah I understand that. Trick is getting the lpc and sniffer clocks in sync
<d1b2>
<hanetzer> That, and getting the data out fast enough
<d1b2>
<Attie> ah cool / apologies - with glasgow, that's easy... with a micro, you could use a pin interrupt...?
<d1b2>
<hanetzer> Pico can't do the latter with raw lpc data as the 12mbps USB is too slow, and pru docs on the BBB are tricky as compared to pico PIO, and well, Glasgow isn't in my toolbox yet lmao
<d1b2>
<Attie> IIRC the bus is pretty "bursty"...? i.e: you're not looking for a sustained 33.3 MB/s (with 6-signals padded to a byte)
<d1b2>
<Attie> you may miss stuff during busy periods, which would be frustrating
<d1b2>
<hanetzer> Yes, but catching the bursty bits is fun.
<d1b2>
<Attie> (:
<d1b2>
<Attie> Doesn't RP2040 have a huge slab of RAM?.... rolls eyes
<d1b2>
<hanetzer> Tbh I don't even mind that, if it had faster usb
<d1b2>
<hanetzer> That's basically my only beef with it
<whitequark>
hanetzer: so my plan for LPC capture on Glasgow was to have most of the applet run in the LPC clock domain
<whitequark>
because the LPC bus has idle cycles, despite the bandwidth being higher than Glasgow USB's, it will on average be lower if you discard idle cycles
<whitequark>
the problem I hit is the lack of asynchronous reset capability in Migen, meaning the applet could not be reset without the LPC clock
<whitequark>
even now, AsyncFIFO has some weird reset issues that I don't entirely understand
<d1b2>
<hanetzer> How is lpc higher than USB HS?
<whitequark>
oh, wait
<d1b2>
<hanetzer> 33.3Mhz * ~1 byte is like, 266Mbps?
<whitequark>
I misremembered; that was done on revB, where the applet clock was 30 MHz as it was using the much slower iCE40 UltraPlus FPGA
<whitequark>
it wasn't a USB limitation, it was an FPGA limitation, I couldn't hit 48 MHz on the FX2 interface
<whitequark>
that's much easier to handle then, all you need is a CDC from LPC to the main applet clock
<whitequark>
I think unfortunately the only board I had with LPC is in a different country rn or I would have helped you with the applet
<whitequark>
I still remember most of the design
<whitequark>
moving is stressful :/
<d1b2>
<Attie> 😦
<d1b2>
<Attie> here's an early-boot trace I took from a project a while ago... (in terms of idles / porosity, etc...)