Hi all

we encounter bulk transfer problems with the FX3 when performed repeatedly for a long period of time - any help or input on this is very much appreciated.

Background: We are working with the FX3 controller in slafe fifo mode and are trying to stream continuous data (60Mb/s) from the FPGA to our software in multiple bulk transfers [=tf] (we have set up the fx3 ss tf size to 16*1024, and work in 16bit mode). Short transfers (<10000 tf at 10000 tf/sec, where the tf packet size is up to 8kB) work and usually perform well (=>80MB/s). The software works with the CyUSB.Net dll and repeated XferData() on one bulk-in SS endpoint.

We now would like to record data for more than the one second (>10000 transfers) (desired: -> minutes, hours.... -> millions of transfers) but this fails.

Problem: When performing many and repeated bulk transfers for more than one second so we encounter repeated, very short USB/FIFO overflow/full problems (see capture attached). The USB transfer gets paused.
The FX3 signals the FPGA a "USB Full" - normally seen during transfers. While USB Full, the FPGA buffers data in its own fifo (FIFO full) and stops writing (WR) to the FX3 - this usually works well. However, as you can see on the capture, this USB full sometimes (seemingly at random) is set way too long and the FPGA's fifo gets full as well - our data is lost. We've played with all the firmware parameters - nothing helped

Thougts & Questions: Some of the reasons we thought of and the questions that arised:

- First of all, we were thinking of the restricted bus-access time by the host controller/software - how can we improve this and make sure that our device gets the needed time? Is isochronous transfer an option at such high data rates? what about data integrity? Should we use a differend driver (WinUSB, ...)?

- We found, that during the first few transfers - the data can only be held low and can later gradually be increased. Could it be that windows somehow restricts our thread priority in the beginning and after a while allows it more time? (recording and Xferdata is done in a seperate thread from our main application that is instantiated/created for every record). How can we make sure the thread gets its processing time right from the first time? (C#)

- The FX3 has SRAM on it. Could we use this to buffer the USB data? How-to would we do that? (SRAM/Blockram in the FPGA is very limited).

- Any other ideas that you can think of?

Thank you in advance,

Walt

I am observing the same beahviour, means that the FX3 sometimes reports buffer full for 1 ms or more, where no data can be sent upwards to the host computer. Therefore I am also interested to know if there exists a solution for this problem.

-Silvio

Bulk transfers occur across the USB link in burst format rather than continuous transfers - sometimes more packets are transferred per unit time than others and this depends on the host controller and PC. There are times during a transfer that the PC / operating system goes off and does something else for a relatively long time and no USB tranfers occurs which can be a problem if you have real time data you want to send over USB. The solution is to buffer the data while there are no USB transfers but the question is how much buffering do you need? From experience with USB 2 I have seen USB tranfers paused by the PC for about 100 ms so you have to allow buffering for at least this amount. (300ms is what I allow). The more buffering you can put in the better but realistically the FPGA or the FX3 wil not have enough memory to do what you want - we are talking MBs here. So you will need external memory probably 1Gb or 2 Gb of DDR2.

As for using Isochronous transfers the data should be streamed continuously but there will be no checks to see if the data has been transfered correctly and also you can still get these transfers paused by the PC if it suddendly decides to do something else.

Sodafarl

Walt ,

Are you setting "Max no. of packets in a burst to 15"?  You should not be seeing these delays in 1 or 2 sec if data rate is about 60MB/s, I have seen host continuously reading data at 300MB/s for hours.

thanks for your responses.

dbir, yes we actually did set it to 15.

the problem is not the speed that we achieve: we reach high enough data rates with no problem for repeated short periods of time (180MB/s). The problem is that we are continuously (and with that I really mean a continuous data stream of 60MB/s) streaming data via the GPIFII into the FX3. because of USB's packet nature we rely on permanent delivery of data towards the PC - very short interruptions (may be due to heavy processor load and thus lower thread priority of our host application) lead to a buffer full signal of the GPIF. It is exactly as sodafarl mentioned.

We thus need a way to maintain the thread priority and bus access time of the host... Sodafarl: you are completely right, 300ms in our case is >18MB - which the FX3 won't be able to buffer. We also tried isochronous transfers - but there we have the problem that

our next step is to try asynchronous data transfers as proposed in http://www.cypress.com/?app=forum&id=167&rID=63477. IRod and Sil obviously have the exact same problems.

Walt

Hi,

I think I encountered similar problem as yours. I am using 32-bit slave FIFO though.

I experienced that when the FPGA has enough data to fill the USB FIFOs regularly. For my case for instance, there are always 256 of 32-bit data available to be written to the USB FIFOs, no problem occured.

However, when the FPGA does not received the data regularly from its source and therefore, the writing to the USB FIFOs happens irregularly: write 30 data, then write 2 data, then...., after several transfers, the FullFlag goes low and stays low forever.

I already opened a case for it and I think they are working on it.

To solve this problem, I made sure that I always have 256 of 32-bit data available in the FIFO inside the FPGA before start writing to the USB FIFOs. Now I can download the maximum of 16GB of data with data rate of 250MB/s.

Hope it helps,

Nazila

Hi,

I have had this issue with other hardware writing to the PC over the USB. I have only seen it on Windows 7. From time to time, the OS would momentarily suspend data flow from the USB to my PC application and cause havoc. I set the priority of my process to high in the device manager and the problem went away.

I am not claiming this is your issue, but if you want to see if it is, try this.

Start the Task Manager. Go to the Process tab. Find your program and right click on it. There will be a mean with Set Priority as a choice. Left click on this and you will see where Windows has set you process priority. You can change it to a higher level and see if it helps. My reading on this says that setting it to real time is a bad idea.  If this helps, it can be done in your PC software. The kernal32.dll has API calls to find and set the priority of your application.