FX3 : Unexpected data loss when using short packets

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello,

   

We have a problem of unexpected data loss (due to some FIFO FULL) when we try to use short packets.
Please note that when we are not using short packets, we have no problem and sustain easily a 350 MB/s stream.

   

=============  Here is a description of the system  =============
Data is provided by a FPGA (running our code)
Data goes through a FX3 embedded on a PM3 enclustra card
Data then goes to a software of our own

   

Software side :
  we link to the FX3 1.3.3 CyAPI library
  we use a very efficient reading on a bulk end point, using multiple-circular-scheduled async reads (BeginDataXFer()). We are pretty sure to be very efficient
  we request reads of 4MB
  all reads actually return 4MB, except when a short packet is coming. In this case, one read will return less data, but then the next reads will get 4MB againHello,

   

We have a problem of unexpected data loss (due to some FIFO FULL) when we try to use short packets.
Please note that when we are not using short packets, we have no problem and sustain easily a 350 MB/s stream.

   

=============  Here is a description of the system  =============
Data is provided by a FPGA (running our code)
Data goes through a FX3 embedded on a PM3 enclustra card
Data then goes to a software of our own

   

Software side :
  -we link to the FX3 1.3.3 CyAPI library
  -we use a very efficient reading on a bulk end point, using multiple-circular-scheduled async reads (BeginDataXFer()). We are pretty sure to be very efficient
  -we request reads of 4MB
  -all reads actually return 4MB, except when a short packet is coming. In this case, one read will return less data, but then the next reads will get 4MB again
  -we observe no timeouts (as expected, of course)
  -for information, we want to add short packets in the stream for future development
  
FX3 side :
  -we compile our own FX3 bootimage, based on standard slavefifo example
  -we use the auto DMA mode, with 4 DMA buffers for the channel we use, configured for infinite transfers
  -we use a standard GPIF machine (see attached screenshot)

   

FPGA side :
  -we emit data, and every 250ms a short packet is (correctly) emitted by pulling PKTEND low. "Correctly" means that we think to respect the documentation about the signals timings.
  
=============  Here is a description of the problem  =============
Software side :
  -several KB are missing almost every 250 ms (see below the explanation when observing the signal lines)
FX3 side :
  -nothing to say. Everything is automatic, so we do not get much information. We tried to bypass the IDLE state of the state machine by adding connections between the SHORT_PKT and the DSS_STATE, but it does not change anything.
FPGA side :
  -we observe the signal lines. Almost at every short packet (but not at every ones), the FLAGB ("dedicated thread not ready") line remains high during dozen of microseconds (which is huge). So, the FPGA fifos will get full since data is not allowed to be transferred during that time. At the rate of emission of data, this is why the software observe several KB of missing data.

   

See the attached screen shot :
PKEND# goes to '0' along with  the last word of data and SLWR# pulse. So the GPIF state machine interprets it as a short packet. Unfortunatly, the FLAGB signal goes to '0' after around 200µs, indicate that the dedicate thread is not ready to receive data. The FLAGB remains low during around 63 µs and the upstream fifo inside FPGA goes FULL so we loose data.

   


=============  Our request  =============
We need some guidance about what is going wrong, what could be done...
For information, we plan to use short packets for a special mode where the FGPA emits few data, in unpredicatable amounts. Thus, to avoid timouts and data loss on the software side, we need to use either short packets or zeo-length packets.
Thus, it is true that short packets are not needed in our current design at 350 MB/s, but, we still want it to work in that case before going further. We don't think that it should prevent that mode from working.

0 Likes
1 Reply