Specification on LabVIEW FPGA

[Schrödinger1933]

Hello all


This might be a a dumb question, but I am new to this and have not found any resources stating the answer to my question explicitly. I am planning on running a compact RIO system, and am not clear on the division between what occurs on the cRIO processor and what occurs on the FPGA itself. From my understanding, the FPGA handles the I/O of the cRIO, and the signal analysis (the application I am working on involves input) occurs in the LabView Program that executes on the processor. Any clarification/help is appreciated! 

[Terry_ALE · Accepted solution]

I hate to give you this answer but it depends.  And that is why there probably isn't anything to give you specific direction.

This is a good starting point: http://www.ni.com/compactriodevguide/

Here are some pointers:

RT code is 'easier'

FPGA code is 'harder'

If it can run on RT or FPGA, run it on RT.

Low latency code goes on the FPGA (define low latency for application first).

Some functions cannot go on the FPGA since they do not exist or do not fit on the FPGA.

[crossrulz · Accepted solution]

You can put whatever code you want into either the FPGA or the RT.  It really does depend on your application.  The last few projects I had with a cRIO, I had almost all of the code in the FPGA.  The RT was nothing more than a pass through between my Windows application and the FPGA (I use the STM library with TCP/IP).  The RT also saved settings to a file so that it could be loaded at boot up.  But the FPGA did everything for the test.

For a background, these cRIOs were doing some basic data acquisition, limit checking on the data, and reporting the pass/fail status to a PLC.  And what really made these good for the end user is that if the Windows PC or even the RT crashes, the FPGA is still running and they can put out their parts.

So for reliability reasons, I say to put as much as possible into the FPGA.  Yes, FPGA is harder and you are limited in what you can do.  It was worth it for me.