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 ?
<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