whitequark changed the topic of #amaranth-lang to: Amaranth hardware definition language · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang
lf_ has quit [Ping timeout: 240 seconds]
lf has joined #amaranth-lang
pho has quit [Ping timeout: 240 seconds]
lsneff has quit [Ping timeout: 240 seconds]
adamgreig[m] has quit [Ping timeout: 240 seconds]
adamgreig[m] has joined #amaranth-lang
lsneff has joined #amaranth-lang
pho has joined #amaranth-lang
jess has quit []
_whitenotifier has joined #amaranth-lang
<_whitenotifier> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/d89bb08c9121...b7c96473ba20
<_whitenotifier> [YoWASP/yosys] whitequark b7c9647 - Update dependencies.
d1b2 has quit [Read error: Connection reset by peer]
TD-Linux has quit [Ping timeout: 245 seconds]
kmehall_ has joined #amaranth-lang
kmehall has quit [Ping timeout: 245 seconds]
TD-Linux has joined #amaranth-lang
<lsneff> Does anyone know of a TDC written in amaranth?
<Degi> How precise does it need to be? You could just store the value of a counter when you have the signal whose time you want to measure if you only need ns granularity
<lsneff> I’m only casually thinking about the project, but I’d need ~500ps resolution
<Degi> Hmm, on an ECP5UM5G you could do that with an ordinary DDR buffer and a counter, but otherwise you can use a delay line (but that is very FPGA specific) for higher precision
bl0x has quit [Ping timeout: 240 seconds]
<Degi> You can probably use a 1:4 DDR buffer clocked at 1000 MHz with one of the PLLs and then divide that down to 1:16 or 1:32 or so and then when one of these channels is high, find which is the first which is high and then use a reverse one hot or so to convert that to a binary number which you can add to the end of your clock for extra precision. (I haven't tested personally if they work at 1000 MHz but at 800 they seemed
<Degi> to)
bl0x has joined #amaranth-lang
Degi has quit [Ping timeout: 250 seconds]
Degi has joined #amaranth-lang
<lsneff> Oh, that’s a neat idea. The DDR buffers can run that high? I’m impressed
d1b2 has joined #amaranth-lang
cr1901_ has joined #amaranth-lang
cr1901 has quit [Ping timeout: 240 seconds]
indy has quit [Ping timeout: 240 seconds]
jesopo has joined #amaranth-lang
jesopo is now known as jess
indy has joined #amaranth-lang
<Degi> Well, at least on my chip
<Degi> Some IOs can even work at 2000 MHz if you use a clock divider block right after to get it down to 250 MHz or so (since that's how high my oscilloscope does), but only some (when I use the SERDES of another LFE5UM5G to drive it)
cr1901_ is now known as cr1901
peeps[zen] has joined #amaranth-lang
peepsalot has quit [Ping timeout: 272 seconds]
cyrozap has quit [Ping timeout: 252 seconds]
cyrozap-ZNC has joined #amaranth-lang
<key2> Could someone familiar with Luna tell me why this simple example fails ? I basically redirect a usb EP to a serial port. When sending data to the EP, I get some part of if duplicated on the serial port. as if a packet that could not be sent on the USB side because the EP is not ready overflows the buffer. Or am I doing something wrong ?
<miek> could you describe the symptom in a bit more detail?
<key2> I send packets back to back to the USB EP. and I check what I receive on the serial port.
<key2> I pattern them 00 01 02 03 04 ... FE FF 00 01 02 03... to see what I am sending.
<key2> and roughtly after 3 packets of 512, I see the pattern : 00 01 02 03 00 01 02 03 04 05 060
<key2> so the "00 01 02 03" got repeated. while it was never sent
<key2> of course the serial port is not always ready because it's slow compare to the USB EP.
<key2> @miek it's weird that such a bug has never been seen before. Unless I am doing something wrong
jess has quit []
<d1b2> <dragonmux> that is looking like you might have found a bug in USBStreamOutEndpoint
<key2> I didn't look into it
<d1b2> <dragonmux> having recently done a lot of work with LUNA, we have and we just cross-referenced USBStreamOutEndpoint vs how you have it connected and all looks right
<d1b2> <dragonmux> it's possible too this is something weird to do with how the TransactionalFIFO used inside the endpoint type works
<key2> for info, if I delay the sending between each 512 bytes on the USB side, it doesn't happen
<key2> it really happens when I send a huge urb that the kernel manages to split and send on the other side.
<d1b2> <dragonmux> that makes us thing TransactionalFIFO evne more - what's probably happening (simulation required to prove this) is that the FIFOs are becoming full, TransactionalFIFO has had to discard a transaction's worth of data (but not before you've slurped 4 bytes of that traffic from the FIFO) and an error condition is occurring which is then recovered from in the next transaction
<d1b2> <dragonmux> *us think, *even more
<key2> that was also my intuition
<d1b2> <zyp> TransactionalizedFIFO shouldn't let you slurp any data before it's been committed, and once committed it can't be discarded
<d1b2> <dragonmux> with how their stuff's hooked up, we can't see any other way the behaviour that's happening, could happen
<miek> key2: i reproduced it here and pushed up a fix https://github.com/miek/luna/commit/63c9048596ded9f5cbbc22953151ccee6df06912 - let me know if that works for you too
<key2> ahh great