DMA FIFO number of elements to read mismatch in FPGA and RT

[arya1]

Hi all

I am using myRIO , LV14 to run my application.

Application: I have to continuously acquire data via FPGA and process in RT host once every 2000 samples are collected. I use DMA FIFO (size 8191) to acquire data, use timeout property at the FPGA to eliminate buffer overflow. I had followed cRIOdevguide to implement this part. A snippet of what I have implemented is attached. Whole code runs in SCTL at 50MHz.

Issue: Twice or thrice I encountered with this strange behaviour, that the FPGA FIFO is giving continous timeout and the RT is unable to read the FIFO. The number of elements to write propery in FPGA VI gives 0 showing that FIFO is full and no more can be written, but at the RT, elements remaining is giving 0, hence it is reading 0 (no) elements.

Workaround: I put a case where I will write to FIFO (as per the code) and if the number of elements to write is nonzero. It seems to work fine, as of now.

What confuses me is that my FPGA VI says that FIFO is full (FIFO number of elements to write = 0) and gives a timeout error, but RT VI says that number of elements remaining in FIFO is 0 and hence no data is read. Any idea why it is so? My FPGA and RT VIs continues to run, but with no data being acquired or read.

I saw this behaviour within minutes after running the code. Any idea as to why it is happening? I am trying to reproduce the behaviour and will update if i again encounter with it. Sorry, I cannot post my code here, but i guess the code snippets explain it to some extend.

Thanks

Arya

Edit: Even with the mentioned workaround, the problem persists, now that the FPGA does not write to FIFO at all. And the RT VI is not able to read any elements as it sees 0 elements in the FIFO. The FIFO continues to be in timeout state. So i guess the problem is with the RT side.

[arya1]

I am able to reproduce the problem more than once now, but not always. Basically, the FPGA VI has stopped writing data to the FIFO inside the case structure false case. Now that the FIFO is full (number of elements to write = 0), it always enters the true case inside the loop.

Meanwhile, the RT FIFO read with 0 elements still says that the number of  elements remaining in the FIFO is 0, and hence not able to read any data from it. The error code is 50400 as expected, saying FIFO underflow! I tried stopping the FIFO when such an error is encountered, which results in error 63150, which says that a hardware failure has occured. I ve also had a look at the distributed system manager, now the CPU usage is really small (15%) as opposed to around 80-90% when the code was working fine.

Arya

[nathand · Accepted solution]

Why does it look like you're reading from the same FIFO in two different locations in the same VI, in parallel? If the lower read empties the FIFO, it will never trigger the reset, which could result in the situation you're describing, I think (it's hard to tell from just screenshots).

Also, your logic looks overly complicated. I immediately notice that there's no reason for the Select with the input being the output of =0 - just use the "Equal to zero" output directly. On the FPGA side, why do you need to check for the number of elements to write? There's no harm in writing to a FIFO that's already full; the data just won't get written.

[arya1]

Hi Nathan

Thanks for the reply. Yes, I should have put the lower FIFO read in timeout false case. Agreed that if the lower FIFO reads the data, reset will never be triggered. But in that case, I should atleast see some data from the lower FIFO, isnt it? The lower FIFO also returns 0 elements!  On the FPGA side, the 'Equal to zero' output cannot be directly wired because, if it is false, it is the shift register output that is to be given, which could be either true or false (I will remove that check, if its okay to write into a FIFO that is already full).  I checked the number of elements to write because, at the RT side i sense FIFO underflow, i wanted to verify if it is the same in FPGA side (what i see here is an overflow!).

Thanks for the tips. I will make modifications in the code, test it out and update them in the thread.

Arya

[nathand]

---

arya1 wrote:

On the FPGA side, the 'Equal to zero' output cannot be directly wired because, if it is false, it is the shift register output that is to be given, which could be either true or false (I will remove that check, if its okay to write into a FIFO that is already full).

---

Sorry, what I meant to say is the Select should be replaced with a boolean OR - but yes, better to remove it entirely. What did you think would happen if you write to a full FIFO? Why make your logic so much more complicated than the sample dev guide code you provided?

[arya1]

Hi Nathan

Yes, I could have replaced it with an OR. Regarding my application, I want to acquire data in chunks of 2000 samples. If at all I receive a timeout error, I want to discard that chunk of 2k samples and start all over again. So my logic was like this, I acquire the data, if there is a timeout, the reset is triggered, and the system waits to comeback from reset, and it starts acquiring again. Btw, I tried removing the multiple FIFO reads in RT, but the error is still the same.

I have a small doubt as well, if I do not want to obtain stale data at alI, I would just check if timeout occurs, empty my FIFO and start acquiring data again (no reset button), isnt it? This was my original logic, but I saw that after a while, it stopped acquiring data and timeout led was on. I was thinking that FPGA and RT was simultaneously trying to acquire FIFO which might cause timeout. Somehow, I now feel that, as you have pointed out, my code is overly complicated. I will modify it and update the results. Thank you!

Arya

[smithd]

Hey Arya,

Normally I'm a huge fan of people using the cRIO dev guide to learn things, but in this case I'd realllly recommend just skipping ahead to this:

https://forums.ni.com/t5/Example-Code/Reference-Application-for-NI-CompactRIO-Waveform-Acquisition/t...

There are so many little annoying things you have to remember to make waveform acquisition work, and this has them done for you.

[arya1]

Hi Smith and Nathan

Sorry for the late reply, I could not work on the code for a while. I cleaned up the code according to some examples from the addon that Smith had suggested. This helped me to isolate the problem. I think Nathan was right. The first time the timeout error happened, there were two simultaneous reads, one had some elements and other did not have any. Later on, it got stuck there and there were no data transfer between FPGA and RT afterwards. The code is showing no error now, will reply to the thread if some issue happens. Thanks a lot. 

Arya