FIFO DMA Target to Host

[Fathy]

I have a system that composed of

1- NI-cRIO9014

2- Chassis (cRIO-9104)

3- Three Mods. NI9215

 

I use this system to capture 12 analog signals.

What is the relation between sampling frequency defined by time delay in fpga.vi and the Requested number of Elements defined in FIFO?. 

When I use a time delay of 40us and Requested number of Elements 8191, it produces wrong data.

When I use a time delay of 40us and Requested number of Elements 65535, it produces correct data.

[ned]

There are a lot more issues to consider than the ones you listed - in particular, the size of the host-side FIFO buffer, the speed at which you read elements out of the FIFO on the host, and the number of elements you read on the host at a time. What is your host code doing? Show us your code.

 

A DMA FIFO has two buffers: one on the FPGA, and one on the host. For a target-to-host (FPGA to RT) FIFO, the FPGA fills its buffer, and in the background the contents of that buffer are automatically moved to the host buffer periodically or when the buffer is full, whichever happens first, assuming there's room available in the host buffer. (For a host-to-target FIFO, this happens in the other direction - elements are copied out of the host buffer to the FPGA when the FPGA buffer has space available.)

 

If you fill the FIFO buffer faster than you empty it, you'll start losing data. This will probably appear as though the channels are shifted. You can fix this by reading from the FIFO on the host more frequently, or increasing the size of the host buffer and reading more elements at a time.

[Jordan Kuehn]

Check the discussion here.  The initial post mentions host->target FIFO, but I mistakenly started a discussion regarding target->host FIFO.  Size of buffers is not addressed, but Ned is correct to bring that up as well as frequency of data transfer.  You should be pulling data frequently enough to need the check I illustrated with the screenshot, otherwise you are likely overflowing the buffer.

[smithd]

I'd recommend just using this:

http://www.ni.com/example/31206/en/

It attempts to simplify the problem. 

 

If you want to understand it better, make sure you take a look at this:

http://www.ni.com/pdf/products/us/criodevguidesec3.pdf

starting pg 14 ("90" in the PDF)

[Jordan Kuehn]

I'd recommend just using this:

http://www.ni.com/example/31206/en/

It attempts to simplify the problem. 

 

Without derailing too much, I've not found great use for the crio waveform library as my applications aren't this straightforward typically (though I imagine it could be used for this application).  Is there something I'm missing?

[smithd]

Probably not, its designed to handle the situation that sometimes came up prior to the RT-cDAQ where you needed a RT processor but didn't care about the FPGA. The goal was to make a simple daqmx-like API for that specific use case.

 

That having been said, its so simple that I've used it as a starting point for any streaming acquisition from the FPGA, for example you could be processing data, and then wanting to stream up the results. So in the acquisition loop instead of reading directly from I/O you could read from a target-scoped fifo or a local register.

 

Its true value to me, now that the RT-cRIO is out, is (a) as a teaching tool, and (b) as a template which reminds me of all the stuff I might need, like having an idle state on the FPGA, acquisition stopping and restarting, checking for timeouts, etc. If you have your own template or pattern you start from, or your projects are different enough that such a tool doesn't make sense, then the reference library doesn't make sense. The page itself also has some great benchmarks for network and disk streaming which i reference regularly.