GPIF2 low rate transfer issue

[JaRo_4664191]

Hi all,

I'm trying to sample a signal for a long period of time and stream to the system host using the FX3 GPIF2 interface. If I use a high sampling rate and I keep the bus active, there is no problem. However if the sampling rate (or the bus activity is low), the FX3 seems to not respond after some time, by not asserting the DMA ready flags.

For our system, GPIF2 data is sent in burst of 1KB. An internal FIFO buffers data and a state machine waits for the buffer to fill up before sending the next burst. For this example, the amount of data to transfer is about 30M 32 bit words and the input data rate is about 92MBps. The FX3 uses a multi-channel DMA with FLAGA and FLAGB as ready flags. DMA buffers are 2x16KB for each channel and USB burst length is 8KB. As can it seen in the image below, after sending a complete 16KB buffer to the FX3, FLAGA and FLAGB don't get asserted any more and the system fails due to a FIFO overflow.

So here is my question: Is there something I am missing that can justify this behaviour? Something like a timeout at the GPIF2 level. This doesn't happen with higher sample rates.

Kind regards

[JayakrishnaT_76]

Hello,

Please let me know the following for debugging the issue:

1. What exactly do you mean by keeping the bus active? Which bus are you referring to? Can you please elaborate this statement?

2. As per my understanding, you are using 32 bit data bus for GPIF II interface. Please let me know if the clock (PCLK) used for sampling the interface signals is internal or external (from the external peripheral). Also, please let me know the value of PCLK.

3. Please let me know how you have configured FLAGA and FLAGB.

4. Please share the GPIF II designer project file so that I can understand more on this issue.

5. Please register a callback function for the DMA multi channel with the notification set to CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT. Inside the callback function, increment a global variable for every PROD_EVENT received and decrement the same variable for every CONS_EVENT. Now, print the value of this global variable in the infinite for loop and let us know its value when the error is seen.

6. Please try increasing the number of DMA buffers while creating the channel and let us know if you see any improvements.

Best Regards,

Jayakrishna

[JaRo_4664191]

Hi Jayakrishna,

I've asked your colleague Elton H. Kong to open a private thread for this issue. In the mean time I can answer some of your questions:

1) What I mean is that the GPIF2 is actively transferring data instead of waiting for long periods of time until enough data is available to send a 1KB burst to the FX3. When the waiting intervals are smaller, i.e., the input data rate is higher, this issue doesn't seem to happen.

2) PCLK is generated at the FPGA and it's 100MHz. The GPIF2 is configured in slave fifo mode, 2 address bits.

3) Both FLAGA and FLAGB are thread dedicated flags signalling a ready buffer at the FX3 side.

4) I'm afraid I can't share that.

5) The DMA channels are configured in AUTO mode. Can I still define callbacks?

6) From my point of view, increasing the number of buffers won't have any effect. If I understood this correctly, increasing the buffers will only improve data throughput, but right now I have 2x16KB buffers for each DMA channels, with 8KB USB burst. Therefore, I'm quite confident the throughput is enough and increasing the buffers will have almost no effect nor solve this issue.

Best.

[JaRo_4664191]

Hi

I've tried a different version which uses a single channel DMA and I still got the same issue for this kind of transfer.

Cheers

[JayakrishnaT_76]

Hello,

Thank you for your reply to my questions. As per my understanding, by high sampling rate (or bus active), you mean to say that GPIF II is sampling data actively without waiting for availability of enough data. Also, the low sampling rate means that the GPIF II state machine will wait until enough data is available. And, the issue occurs only if we keep waiting for the data to be available. Please correct me if I am wrong.

As per your response 3, I understand that the same problem exists when you try to use a single channel between the P Port socket and the USB socket. Please correct me if my understanding is wrong. If this understanding is correct, then we will debug the issue with the single channel implementation as of now and then check the same with the multi channel.

Please let me know the following for getting more information to debug the issue:

1. For the single channel implementation between U Port and P Port, is the state machine same as slave FIFO state machine? If there are any modifications, can you let us know how the data is sampled (interface timings) so that we can understand the snapshot shared in your query better. This is because I found that the PKTEND is also asserted in the snapshot shared in your query.

2. Please let me know how do you stop sampling the data on the GPIF side. As per your description, there are overflow errors seen while sampling data. As you might be knowing, these errors occur when we try to fill the DMA buffers associated with the GPIF II socket with more data than its capacity (16KB in this case).

Best Regards,

Jayakrishna

[JaRo_4664191]

Hi Jayakrishna,

Yes, your assumptions are correct. The GPIF2 bus remains inactive for some time before sending a new burst, while keeping CS active. The single channel implementation has the same issue so it can be used as reference.

1) I believe the FSM is a vanilla implementation, probably taken from one the SL FIFO examples. Nothing special about it. I send the PKTEND signal every time I've sent 16KB (a FX3 buffer), although I run a test without it and the error persisted.

2) I stop by sending a PKTEND with the last word I send. However, at this point I can't finish the data transfer (I got a few millions words left to send). I keep count of the amount of data I send, and by sending 1KB bursts I can easily control when the DMA buffer is full. When a buffer is sent I wait enough time for the flag update before sampling its value again.

Cheers

[JaRo_4664191 · Accepted solution]

Hi Jayakrishna,

It seem the issue comes from a wrong timeout setting when requesting the USB data from the host side. Thanks for your help. You may close the thread.

[JayakrishnaT_76]

Hello,

Thanks for the update. We are glad to hear that the issue is resolved. I will be closing this thread.

Best Regards,

Jayakrishna