futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
whitequark: What I would try is to never rely on a full fifo condition. Set a flag level at like 90% or so, and then always go through the packet_end signal.
<tnt>
With the various registers and delay there is like 4 cycles latency between the moment the FSM decides to make a write to the first time it can actual 'sample'/react to the effect of this write on the flag.
thaytan has quit [Ping timeout: 250 seconds]
thaytan has joined #glasgow
thaytan has quit [Excess Flood]
thaytan has joined #glasgow
emily has quit [Ping timeout: 250 seconds]
emily__ has joined #glasgow
emily__ is now known as emily
emily has quit [Quit: Updating details, brb]
emily has joined #glasgow
TimRTerrible has quit [Ping timeout: 252 seconds]
TimRTerrible has joined #glasgow
<whitequark>
tnt: that's reasonable, though I had a different idea
<whitequark>
not rely on that flag at all except for determining when there are too many committed *packets*
<whitequark>
add a byte counter on the arbiter side
<tnt>
yeah, that's an option as well.
<tnt>
I was mostly proposing the above as a 'quick check' to see if missing packet end or writing to full fifo was possibly a cause of the corruption atm.
<whitequark>
tnt: i tried playing with the flag level...
<whitequark>
i didn't get very promising results and it was hard to see why exactly
<tnt>
whitequark: but you also need to disable the logic in the fpga that assumes that a full flag will result automatically in a packet being sent.
<whitequark>
tnt: i think i adjusted the register in FX2 responsible for that also
<tnt>
whitequark: but my fear is that because of the massive pipeline delay, the fpga and fx2 disagree in some corner case and I'd fine it safer to always let the fpga decide.
<tnt>
Just trying to eliminate potential errors to narrow down the cause.
<davidc__>
I tracked down an issue symptomatically similar to this in another piece of HW. The only way I found it was to generate a non-repeating bytestream, record it in SW and with a logic analyzer
<whitequark>
yes, this is reasonable and this would be my next step anyway if you wouldn't be able to look at it
<whitequark>
davidc__: i actually already do that in the benchmark applet
<whitequark>
well, it's an LFSR generated bitstream
<whitequark>
i think it requires nonperiodic stops and starts also
<davidc__>
yeah, same in $OTHERHW, I just used another random generator to generate random sized packets
<davidc__>
I figured you probably knew those tricks, but decided to chime in just in case
<davidc__>
If the issue is still around once I have a chance to build some HW, I'll take a stab at debugging it
<tnt>
whitequark: do you have any synthetic test that reproduces the error ?
<whitequark>
tnt: not yet, i might do one by generating rgb clock in gateware...
lowbyte has joined #glasgow
<whitequark>
tnt: so I was thinking, "is it common to track of FIFO level in the transmit side" and then I realized PCIe does it with credits
<gruetzkopf>
pls do not run PIPE in non-pcie glasgow
<tnt>
whitequark: huh, yeah sure. Don't really see why it's relevant here though.
<whitequark>
tnt: it's just me deciding how dirty it is to mostly ignore FX2 flags
<whitequark>
it seems like an already solved problem
<whitequark>
so i am trying to find and/or think of those existing solutions