Data Transfer methods between FPGA and RT

[guilio_2008]

I have 10 values that I combined into a cluster that I want to send to the RT controller.  The problem is if I just the read/write FPGA, I only get 1/10th of the data.  I am assuming that it is the time taking to transfer from FPGA to RT.  So I looked into DMA FIFO.  When I use this, I do capture the data, but I notice jumps/shifts in the data.  It's almost like the buffer fills up, and then dumps it at the last sec. To reduce this, I went from 10 values from the cluster to 2, and there were not shifts/jumps.  The problem is I need all 10 values.  So I'm wondering if I need to increase my DMA FIFO or if there is another meathod I need to use like Shared Varibles? 

Thanks,

guilio

[Brinoceros]

Hi Guilio,

I have a few questions about what you have been doing.  First, what version of LabVIEW FPGA, and NI-RIO do you have (I ask because there have been changes to supported DMA data types, as well as some issues with front panel clusters)? 

Next, you say when you used a  Read/Write Control you only get 1/10th of the data?  Does this mean you get about every 10th set of values (in time) in your cluster that you are trying to transfer?  You may be missing this data since there is no synchronization or buffering with this method, and you are most likely on the right track switching to a DMA FIFO.

Finally, how are you sending your cluster through a FIFO?  The cluster is not a supported data type for a DMA FIFO between the FPGA and RT controller.  Maybe a screen shot of your FPGA block digram will show up what is going on. 

Regards, 

[guilio_2008]

I have a few questions about what you have been doing.  First, what version of LabVIEW FPGA, and NI-RIO do you have (I ask because there have been changes to supported DMA data types, as well as some issues with front panel clusters)? Labview 8.6; CRIO 3.0 with scan engine support, I believe field point is what the FPGA is and it's 6.0.2.  I recently installed the lastest updates that NI has sent me.

Next, you say when you used a  Read/Write Control you only get 1/10th of the data?  Does this mean you get about every 10th set of values (in time) in your cluster that you are trying to transfer?  You may be missing this data since there is no synchronization or buffering with this method, and you are most likely on the right track switching to a DMA FIFO.  What I mean is if I'm running a 1000Hz signal, and I save the data for 1 sec, I should get 1000 points of data (given that I am extracted values once each cycle) but instead, I get 100.  I figured that since there wasn't no buffering or somewhere it can hold data, that I needed to switch to DMA FIFO.

Finally, how are you sending your cluster through a FIFO?  The cluster is not a supported data type for a DMA FIFO between the FPGA and RT controller.  Maybe a screen shot of your FPGA block digram will show up what is going on. I'm not sending the cluster.  What I am doing is taking the 10 values that are FXP before I send them in the build cluster, converting them to u32, building an array that is u32, putting the DMA FIFO into a for loop, then sending the array to the DMA FIFO  Now, one thing I am noticing is in the RT software, the output is a 1D array.  If I remember, I would save that array, get 1000 data points, but only 100 of each of the 10 values that I wanted.

Thanks,

guilio

[guilio_2008]

Here are some images of the VI's.  I have noticed that when I increase the number of elements in the RT, and save it, it increase the amount of cell in the excel file to which the jump accurs.  (ie, if I set it at 3000, then when the jump occurs, it happens for 300 cells, then jumps back.)  I tried increasing the size of the DMA FIFO, but it still happens and even when I set the number of elements to it's max (currently 32768), the the jump occurs at roughly 61555 roughly. 

[Brinoceros]

Thanks for all of the info.  If you installed the latest NI-RIO driver it should be 3.0.1.  Make sure it is, and install it if not (there ahve been some DMA issues addressed).  Also, FYI with LabVIEW FPGA 8.6 you can now use FXP DMA FIFOs.

The one thing I still don't understand is what you mean by this "jump" in your data. Can you be a bit more specific about this? Maybe it will help us locate the problem.  Otherwise, your DMA FIFO looks OK.  Can you verify the number of times your data is written to the FIFO from the FPGA? I would like to see a definite count of this.  Then on the RT side, what does the "Elements Remaining" output look like?  Since this is a FIFO we should be able to keep very close track of elements in and out.

Regards, 

[guilio_2008]

The one thing I still don't understand is what you mean by this "jump" in your data. Can you be a bit more specific about this? What I mean by jump.  The elements coming from the FIFO in the RT controller will display on my array visual aid normally.  Then you will see the data jump. Here is an example.  I am bringing out 3 elements, X Y Z into an array.  I'll read lets say 9 elements at a time.  So my array, after I transform it into a 2D array for saving will look like this.  [x y z;x y z;x y z].  At some points in time, the array will jump and look like this. [x y z;z x y ;z x y].  Then it will go back to how I expect it to look [z x y;x y z;x y z].  Right now, I am reading ~3000 elements.  The elements remaining depends on what else is going on.  If the visual aids are deleted, then elements remaining will never max out and thus, I won't get jumps.  If I put visual aids in, then I get jumps because elements remaining maxes out.  This leads me to believe that the FIFO is filling up and since it can't release all the information fast enough, then it just dumps it and fill it up again.  The weird thing about it, It doesn't happen in a pattern (every 3000 elements).  I tried putting them in seperate loops, it still slows things down.  I tried queing/dequeing, still slows it down.  I need to be able to read all elements fo all 3 DMA transfers at once.   Maybe it will help us locate the problem.  Otherwise, your DMA FIFO looks OK.  Can you verify the number of times your data is written to the FIFO from the FPGA? When I put a clock in to measure loops speed, it was showing 8-9us.  I can't have this no more than 10us or I will missed data. I would like to see a definite count of this.  Then on the RT side, what does the "Elements Remaining" output look like?  As before, elements remaining depends on what else is going on.  If I just have the DMA FIFO's, then I can adjust the read elements number so all three don't max out, but as soon as I put something else in, it will max out.  Since this is a FIFO we should be able to keep very close track of elements in and out.

Let me know if you need more info.  I know about the FXP point transfer, unfotunately, not all my FXP elements are the same data type.

Thanks,

guilio

[Brinoceros]

Hi guilio,

So it looks like our problem is that we are overflowing the FIFO. This usually gives us 3 options:

1. Decrease the rate of data written into the FIFO.  Most likely this is something you wont be interested in doing.
2. Increase the size of of the FIFO.  Sometimes this is sufficient, sometimes not.  If we continually read less than we write, then we will eventually run into trouble.  However, if you can, try increasing the FIFO size.
3. Increase our read rate on the host side.  It seems this is our best option.  You mention that without the extra processing from your visuals, we don't see the problem.  What I recommend is using a producer/consumer architecture on your host side.  You can put your visualizations in the consumer loop, and read from the FIFO in the consumer loop (You did mention queuing, but I'm not sure where you were doing this).  This should help you to avoid overflowing the FIFO.

You could also try reading the number of elements remaining, then reading that number of elements from the FIFO on the next loop iteration.

I hope this helps!

Message Edited by Brian_A on 11-10-2008 01:37 PM

[guilio_2008]

I tried the producer/comsumer loop with the que deque vi's.  Even when I placed the que in the loops, it still happens.

What I currently done was reduce the number of data.  From 10 to 5 and this did some speeding up.  However, when I try to save, (i'm using a producer consumer loop)  this causes it to be choppy.  Now, I don't see any jumps, but when I see this kind of choppy pattern, it makes me concerned if it is missing data.

Any ideas?

guilio

[Brinoceros]

What do you mean by "choppy"? Maybe you have the visuals and file writing both in a consumer loop?  In this case you will probably see each update individually which may look choppy due to the time it is taking to execute the consumer loop each time.  However, if your FIFO does not overflow, and all data being read from the FIFO in the producer loop is being queued, you will not be missing any data.

[guilio_2008]

I think it maybe the visual aids, but the visual aid and writing are in seperate loops.

The problem I'm having now is with the que and deque.  I have it set up as unlimited by default.  The data goes into the que, and is dequed out.  However, after a some time, the program just shuts off.  The only way I can keep it from shutting down by itself is putting a flush que in the loop where it deques the elements.  Since this is on the real time controller, is it possible that the que is filling up and not dequeing fast enough on the RT controller that it stops the program?

Thanks,

guilio