FPGA code suddenly slows down

[GregFreeman]

I have the following code in FPGA (didn't embed the png because it's too big. You'll have to click the attachment at the bottom) and I have noticed a bottleneck in the FIFO, when both running on the FPGA and jusing simulating values in the Dev Enviroment. Here are the control values

Sample rate - 1 ms

Delay btwn samples - 1000 ms

# static samples - 10

I know my fxp conversion is crummy right now and I will fix that, but I know that is not the issue. The issue is in my FIFO because when I disable it everything works fine. Never see the following issues which I will describe Here is what I am noticing when I don't disable that part of the diagram:

Running in Dev Environment:

Code runs fine...for a while. If I watch the loop counter indicator it goes fast (about 1 ms like programmed to do) from 0-9, then pauses for the 1000 ms wait, then goes again. After about 20 while loop iterations, the for loop suddenly slows way down. I can notice this because if I look at the loop counter, it starts incrementing about once every 5 seconds. I thought, well maybe the DMA FIFO is reaching its limit, but isn't it lossy? Shouldn't old data just be overwritten? It's not timing out because the timeout indicator never goes true so I have no idea whats going on.

Running on FPGA:

Never get fast iteration time like above. Goes slow from the start. I notice this because on my RT side I have a loop dedicated to only reading FIFO elements (see below). I set it up to read 340 elements at a time (34 element array x 10 samples). It takes forever for the FIFO to reach 340 elements (it should only take 10 ms). Because I have that 1000 ms pause between grabbing data there is no reason my buffer should be overflowing.

Suggestions? Sorry I can't post my RT code, but may be able to post FPGA code if it really is needed.

[AlexNCSU]

  Hello,

  I am not sure why you have the 1000ms (1 sec) delay between samples.  It seems to me that it would be causing a slow down in itself.

  If you are having your FIFO buffer fill up to fast, I would suggest pulling them off the FPGA sooner.  You can use the FIFO.start invoke method to have the host vi grab data from the FPGA FIFO BEFORE you actually start writing data to it from your I/O.  In other words, it will continuously take the data from the FPGA FIFO buffer and store it locally on the HOST, thus your FPGA buffer will not get over filled.  Then the FIFO.read will simply pull the number of elements you request from that local stored area.  

  In the way you have it now, the FIFO.read performs both actions of first grabbing the data from the fpga buffer, and then storing it locally and then pulling of the requested number of elements.  This means that if the FPGA gets filled before the FIFO.read is executed on the host you run into trouble. 

  I hope this helps, sorry if I am way off base.

  --Alex--

[GregFreeman]

---

@AlexNCSU wrote:

  Hello,

  I am not sure why you have the 1000ms (1 sec) delay between samples.  It seems to me that it would be causing a slow down in itself.

  If you are having your FIFO buffer fill up to fast, I would suggest pulling them off the FPGA sooner.  You can use the FIFO.start invoke method to have the host vi grab data from the FPGA FIFO BEFORE you actually start writing data to it from your I/O.  In other words, it will continuously take the data from the FPGA FIFO buffer and store it locally on the HOST, thus your FPGA buffer will not get over filled.  Then the FIFO.read will simply pull the number of elements you request from that local stored area.  

  In the way you have it now, the FIFO.read performs both actions of first grabbing the data from the fpga buffer, and then storing it locally and then pulling of the requested number of elements.  This means that if the FPGA gets filled before the FIFO.read is executed on the host you run into trouble. 

  I hope this helps, sorry if I am way off base.

  --Alex--

---

I put that long delay just to see if the timing was an issue. I wanted to force a 1 second wait to give my host time to dequeue elements if overflow was the issue. I have realized by checking the "timed out?" boolean that writing elements is timing out due to the buffer being filled up. That seems to be my issue. I'll dig into it deeper and reply back if I make any headway. Thanks for your advice.

[GregFreeman · Accepted solution]

Found the problem. The RTDs I am using default to "accuracy" mode. These RTDs also do not have simultaneous sampling (NI 9217). In accuracy mode, the conversion time is set to 200 ms. That explains why when I bench marked it was taking 800 ms to execute one for loop iteration (200 ms/channel * 4 channels).

To fix this go to your project, right click any given RTD, choose properties, change conversion time to 2.5 ms.

[rex1030]

As a side note, you need to make sure that you are reading the number of elements remaining in the DMA FIFO after you read from it. You should only stop the loop if this value is zero. With the way your code is now, if you hit stop there is a good possibility you are leaving data in the FIFO that will be lost. If the FIFO isn't empty after you have read your 340 values, your loop will run one more time and read the remaining data from the FIFO. You need to do the same in your 'consumer loop' that is reading from the queue and only stop once the queue is empty, that way all of your values are written to disc before you close the program.

Just a thought

rex