USB3 glitching issues

[allenyin]

(Originally comments on OpenEphys wiki)
I've gotten the Rhythm Interface largely working on XEM6310-LX150, while referencing the OpenEphys USB3 Rhythm verilog design.

One thing I'm noticing, and also pointed out by Intan Evaluation Software v1.5, is bytes-dropping in USB2 (and in my case, USB3) transfers. Intan's solution, in the updated rhd2000evalboard.cpp::readAdditionDataWords(), is to simply ignore the sample frame in which the byte drop happens, and then reads additional bytes (number of bytes per sample frame - the number of dropped bytes) to complete the frame.

This is hard to achieve with USB3 block-throttled transfer (since USB3 regular pipeouts are unreliable), since bytes transfered as to be multiples of at least 16 bytes. I can think of a few rather hacky ways, where I would stitch together data read out later with the previous ones, but I'm curious about whether you have encountered similar bytes-dropping in your USB3 development..judging from the plugin-GUI repo, I don't see any glitch-handling...

My Verilog code is here, the modified Intan Eval software is here .

[aacuevas]

I don't recall any report of byte dropping on our USB interface (I assume this would cause misalignment, immediately causing bad header errors for all following reads, so they should be easy to spot). All we've had is block drops due to high cpu load, but that occurs in software only and doesn't affect data alignment in any way, just causes some samples to drop.

Have you noticed this glitches in our software too or just on Intan's? There's a couple of things we do differently and could affect byte drops.

(BTW, where in the wiki did you comment this issue?)

[allenyin]

Link on the wiki

I haven't gotten my Verilog to work with plugin-GUI. Could you maybe outline the differences in handling data incoming from the FPGA? I've gone through plugin-GUI's modified version of rhd2000evalboard and rhd2000datablock files, and I noticed the main changes are the pipe_ready_override to assert block_ready on the throttled pipe, and the variable burst length. But since these are only used during flushing, shouldn't affect actual data acquisition.

Regarding the glitch -- I think it's inevitable a glitch would happen, USB3 is not 100% error-proof, so I think there needs to be a way to handle it gracefully.

[allenyin]

Turns out I was getting a glitch consistently because of a mistake in the state-transition in the ddr2 controller. I have yet to run acquisition long enough to encounter a dropped-byte glitch otherwise.

Perhaps it would turn out to be much more rare in USB3 than in USB2..