Will a RT-side sbRIO-9606 keep up with this DMA FIFO writing rate?

[biscay]

Hi,

Please have a look at this super-simple FPGA vi which I run on my sbRIO-9606:

I am doing my best to design an RT host-side vi to read the DMA FIFO data, and show them somehow; but I have not succeeded yet: plenty of timeouts occur.

I am afraid I may have hit some sort of built-in limitation on the RT part of the sbRIO-9606 -- or within myself 🙂

So, could anyone suggest some sort of simple host-side vi being able to keep up with this 40-MHz transfer rate?

Any help appreciated!

Biscay.

[Terry_ALE]

Looks like the datatype is U32.

4 bytes x 40 million = 160 megabytes per second. Did you check the throughput specs? 

[biscay]

Hi Terry, this is the closest thing to a spec that I found:

So the question may be, how many clock cycles does it take for the RT Host (to be precise, its RT OS) to grab the data from the FIFO?

[Terry_ALE]

That is not the spec I would use for this.  PXIe chassis have throughput specs but I cannot find one for this product.

I did find a similar discussion on the topic which quotes throughput at 300 MB/sec so you should be fine.

See: https://forums.ni.com/t5/Hardware-Developers-Community-NI/Bandwidth-from-FPGA-to-RT-on-9606-and-9651...

Moving ahead, what happens to the data after it gets to the RT?

PS have you considered data reduction?  One of the benefits of an FPGA is that you can add filtering or some kind of data reduction so you look at only the data you care about and save on storage and post-processing.

[RVallieu]

How many elements are you reading at once on the RT side?

If you are trying to keep up by reading one element at a time, you will get timeouts as the RT won't be able to keep up.

You should read back an array of data (typically a fixed number of elements).

You have to adjust the size of the FIFOs on the host and the FPGA to reduce the likelihood of Timeouts.

[biscay]

Terry, thanks again for your advice. And Hello Ryan.

I have considered data reduction, yes indeed.

Here's the full story: I need to process the ABZ signals provided by a 2500-ppt rotational encoder. The final design will to plenty of data reduction: a subvi of the FPGA will take charge of "understanding" the "encoder language", and hand a neat position value out to some internal register.

However, I'm still curious as to whether the custom-made interface board will do its work. For example, I used two ADN4668 "3V LVDS Quad CMOS Differential Line Receivers", and would like to check them out before plugging the encoder. So I thought, "let's first try to pass the raw encoder ABZ signals to a Waverform Graph, to see that everything goes OK on the hardware part". So, right now, basically I'm trying to implement a 40-MHz digital scope. Which seems to be too much for the relatively feeble RT-side of the sbRIO-9606.

Regards!

[RVallieu]

I've done that in the past - passing up encoder signals to a host for visualization - you should be able to do it, you just need to buffer accordingly on the RT and then pass the data to the PC over TCP connection - don't try to use the RT in Interactive Front Panel mode plotting data and trying to keep up with DMA transfers, etc.  Interactive Front Panel operation really taxes the RT processor. (if that is what you are doing).

[Terry_ALE]

The link with the other specs looks like the hardware should be able to handle 40 MHz of data.

If it cannot keep up, you can put decimator on the FPGA so that it sends every other sample or less to the point where the RT can keep up with the FPGA.

[biscay]

Hi both! Thanks for your advice. Yes, I'm going to decimate the samples; I'll have to. On the other hand, yes, I'm using the RT front panel; I agree that it is an avid resource eater; I wish I had time for delving into programming TCP sockets... but that's not the case for the time being.

If I find out something meaningful I will let you know.

Regards!