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
Anonymous
Not applicable

1) Have you checked by transmitting short packets in AN65974 firmware. We have tested this thoroughly and it is supposed to transmit short packets. Please check if you have not checked it yet. (you may have to set sw8 if you are using Xilinx board).

   

2) I understand you application, and I think that you can probably use the exact same state machine of AN65974.  I suppose by short packet you mean that the last buffer is not complete and the data in the last buffer is not a multiple of packet size . If the data in the buffer is multiple of endpoint packet size, then you will need to send a ZLP as well for the host to recognize the end of transfer. 

   

3)

   

a) First, you can check how much data are you loosing, is it only the last buffers (short packet)? If so, you can check if the GPIF state machine is going in the required short packet state. You can check the state of the state machine by using the API CyU3PGpifGetSMState. (you can also add a intr cpu just to see if you are getting in this state). 

   

b) Once you have made sure that state machine is going in this state, see if you get a buffer commit. You can also do a channel wrap up at the Inrt-CPU event CyU3PDmaChannelSetWrapUp. Once you have made sure that the data is committed to from the GPIF side to the USB, then you should check on the host side. As i suppose that the data is not a multiple of packet size (1024/512), then you need not send a ZLP- (else add a ZLP at the end). 

   

c) If the above things are okay, then you can check the transfers on USB bus using a hardware protocol analyzer. 

   

I saw the timings you have attached, but as I am not sure how you have configured the flags, I cannot say much.I request you to first try my previous methods to analyze the problem. 

0 Likes