Two DMA FIFO's filling and been read asynchronously ??

[Rex_saint]

Hi, 

I have been working lately on the Labview for my system which includes acquiring of data from two sensors in FPGA vi and communicate this to RT vi, where i process the data from the two sensors and subtract them. I am facing a problem of syncronisation. I wanted 4 data points, 2 from each sensor at every 25th microsec. Here i attach a pseudo code which is just a mimic of my original code which shows same problem. 

When we run the code, we are acquiring 4 data points every 25 microsecs in FPGA vi and storing them in 2 DMA fifo's.

Then i read this in RT vi, and display them. 

When i have a single while loop in both FPGA and RT vi. the number of elements left in the two fifo's should be same, as i percieve. 

But in this case its not. PLease enlighten me why ?

Regards

[Rex_saint]

This is the code in jpg form, please check and enlighten me why the 'elements to be read' in the two FIFO's not same, even if i am filling them at same rate and reading same number of elements at a time

Below attached front pannel indicator value snipped at two different instances

[Intaris]

How much do the number of elements left differ?

[Rex_saint]

It is random sir,  the value in number of elements left indicator is changing. so i captured 2 instances and attached

[Rex_saint]

i have pasted the same code vi in the 1st message, please check if you are having a CRIO module with you

[Intaris]

So the difference is significantly less thant he number of points you are actually reading, correct?  If so then I'd say it's simply down to both FIFOs taking a different hardware path to the RT system coupled with the fact that both DMA READ nodes on the RT are multitasked (don't actually execute at the same instant in time but may be a few microseconds apart).

I wouldn't worry about it.  The only thing I would worry about is if the FIFO overruns (You put more into it than it can hold) because then the order of your data points within a single FIFO is messed up.

If you need them to be perfectly aligned than you need to bundle both into the same FIFO either by interleaving or bundling into a cluster.

I'm assuming that the values you are receiving from the DMA FIFO make sense (are not jumbled data)?

[crossrulz]

Do the bytes remaining even out or does one increasingly get larger than the other?

[speleato]

---

@Intaris wrote:

So the difference is significantly less thant he number of points you are actually reading, correct?  If so then I'd say it's simply down to both FIFOs taking a different hardware path to the RT system coupled with the fact that both DMA READ nodes on the RT are multitasked (don't actually execute at the same instant in time but may be a few microseconds apart). 

---

That's right. With very few exceptions the read node doesn't actually cause any data movement, it just checks the status of a local buffer and returns the data if it's available within the timeout period. Data movement is asychronous and controlled by hardware. This means that a) each FIFO's buffer can have slighly different amounts of data in it at the same period in time and b) calling read at a slighly different time can result in a different number of elements remaining.

---

 I wouldn't worry about it.  The only thing I would worry about is if the FIFO overruns (You put more into it than it can hold) because then the order of your data points within a single FIFO is messed up.

---

Just to clarify one thing here. The FIFO gurantees that every data point that's written on one end will be available on the other end. If the FIFO doesn't have room for a piece of data the write will either wait until there is room or timeout. Data in the FIFO cannot be overwritten by new data.

The situation described in the original post sounds like the expected behavior of the FIFO. Is it causing any issues or just a curiosity?

[nathand · Accepted solution]

Intaris is right on. The way DMA FIFOs work is that they fill a small buffer on the FPGA, and when that buffer is nearly full, the data is copied (automatically, and in the background) to a larger buffer in the host memory. The Elements Remaining is how much data is left in the host buffer. The automatic copy from the FPGA to the host will not happen at precisely the same time for both FIFOs, so you'll get different amounts of data in each. The total number of elements remaining (between the FPGA and host buffers) should be the same, although there's no way to see that except to read all the data (until both buffers are empty) and confirm that the total number of elements read was the same.

[Rex_saint]

Intaris:

So the difference is significantly less thant he number of points you are actually reading, correct?  If so then I'd say it's simply down to both FIFOs taking a different hardware path to the RT system coupled with the fact that both DMA READ nodes on the RT are multitasked (don't actually execute at the same instant in time but may be a few microseconds apart). 

---

Speleato:

That's right. With very few exceptions the read node doesn't actually cause any data movement, it just checks the status of a local buffer and returns the data if it's available within the timeout period. Data movement is asychronous and controlled by hardware. This means that a) each FIFO's buffer can have slighly different amounts of data in it at the same period in time and b) calling read at a slighly different time can result in a different number of elements remaining.

---

Reply:

Thank you both sir that was informative and yes i now have no wonder why the two indicators "number of elemnts remaining" in RT vi front pannel are showing different values.

---

 Speleato:

The situation described in the original post sounds like the expected behavior of the FIFO. Is it causing any issues or just a curiosity?

Reply: 

Sir thank you, i understood that it shouldn't create any problem. That was just a pseudo code mimicing my original code. In my orginal code there is some write- read problem (FPGA- RT communication), which is giving me erroneous results. I'll check it before any further disscussions.