fpga DMA FIFO Read bandwidth

[BYeske]

I have a NI-9148 with 4 NI-9234 RIo Cards.   I seem to be having a FPGA DMA FIFO Read problem.  I have a simple loop using the Invoke Node FIFO read property.  My problem is that the time that the invoke read node is taking to execute is slower than the data filling up the Host DMA.

I have 16 channels of 51200 Samples/sec at 24 bits.  So a rate of (51200 X 16 X 3 bytes) is 2,457,600 Bytes/sec.   So, say that the FPGA collects and sends 0.1 s of data and I try to read that 0.1 seconds of data, the DMA FIFO read takes .1 seconds to execute, even with  greater than .1 seconds of data already shown in the Elements remaining indicator!   This effect scales with different amounts of data to be pulled from the DMA FIFO,  .05, .1, .2, .3 second slices of data. it takes almost exactly that long to execute the Read DMA FIFO.  .1 sec of data would be ~ 81920 elements.

On the FPGA side, I am writing to the DMA FIFO every sample available of the cRIO.

[RyanPoPo]

Hey monzue,

Are you reading multiple element at a time on the RT side, or are you trying to just read a single value? Since the FPGA is much faster, you'll need to pull multiple elements out of the FIFO at one time to be able to keep the FIFO from overflowing. One way to do this effectively is to use two FPGA Invoke Read Methods as shown below. The first node determines how many values are available to read and the second node then reads that many values.

I hope this helps.

Regards,

Ryan

[BYeske]

So, I did a test where I simply had 1 vi running with the Vi snippet you provided.   I ran into the same problem, where the LabVIEW code on the PC could not pull data out of the FIFO fast enough, so the code was unstable and the number of elements remaining slowly ramped upwards After a minute or two, the FIFO DMA buffer on the Host PC Filled up and then the FPGA threw a FIFO write overflow error.

So, the Labview code can almost pull data out of the FIFO fast enough, but it can't for this data rate, and I would suspect that if I added another 9234 card that this effect would compound itself and the FIFO would fill up even faster on the HOST PC, because the code can't empty the FIFO fast enough. 

I'm guessing that you haven't tried to pull this data rate off of a NI-9148 yet.  I would Caveat this with I am using LV2011

[RyanPoPo]

Hey monzue,

Since the 9148 is an Ethernet chassis, do you have it connected directly to your PC or are you connecting to it across the network? Also, how many elements is your FIFO set up to hold? I'm sure you have tried this as well, but did you make sure to remove or reduce the 10ms Wait that I included in my code's loop?

I suspect the issue here is due to the Ethernet connection. Other cRIOs I have worked with have transferred at higher data rates than this without issue, so it should be possible.

Regards,

Ryan

[BYeske]

Solved

To test the Ethernet I switched ethernet ports on the computer to the GigE port and I was able to Stream data at the Full Rate without overflowing the FIFO. I was previously using the 10/100 port on my PC, because I was using the GigE port for the Network.

Also, I didn't see how the ethernet could be the problem, because the Elements Remaining Number went high to 100,000 Before the FIFO overflowed, so my impression was that the counter of Elements Remaining would be the length of Data already in DMA memory waiting to be grabbed,

The read node execution time dropped from 303 ms to 270 ms for .3 ms of data, simply by chainging ethernet ports.