LabVIEW
LabVIEW Architecture for RT and FPGA
For the next month you can take the online RT and FPGA training for free.
That might get you started with some background information.
For design details, you might consider documents like the CompactRIO Developers Guide or the High-Performance FPGA Developer's Guide.
Hi Voyager,
NI offers all online training courses for free until end of April: did you already check your options?
Hi Voyager,
LabVIEW comes with a huge library of example VIs and projects, many of them dedicated to RT and FPGA…
I would definitely recommend going through the cRIO Developer's Guide (linked earlier). That will get you most of the way there. After that, it is mostly preference. I like to put as much into the FPGA as possible due to the reliability (will keep running even if the RT OS crashes). Others find it better to limit what goes into the FPGA since you have to recompile it for every update.
As mentioned before, a lot depends on personal preferences in this respect. Definitely worth studying are the two earlier mentioned documents. Especially LabVIEW FPGA is a very different way of programming and requires some adjustments in your thinking in respect to code structure.
While on RT and Desktop you do want to use the case structure a lot to disable execution of code paths when they are not required to be evaluated, this can be counterproductive in FPGA. The FPGA code doesn't necessarily run slower if a certain "code" path is executed or not and unless you use non-reentrant subVIs, each code element is instantiated on the fabric anyways and in fact requires extra logic to implement the selective execution of that code or not. But non-reentrant subVIs disable the possibility to be used in the SCFL (single cycle for loop), which is often the preferred code execution engine on FPGA (unless timing of the resulting signals is not important). Instead of a case structure it is in these cases just as perfect to simply use a selector to select either of the results depending on the condition and let the whole evaluation happen anyways even if the result is not used at that moment.
Also when using SCFLs, you do want to separate code into different clock domains (code running on a specific clock) if possible, with each SCFL only handling one single clock domain. It is allowable to have multiple SCFLs running on the same clock. You also should avoid having to share lots of data between different SCFLs as that requires a lot of resources. Of course some sharing is always necessary but try to design the system such that that can be minimized without sacrificing other recommendations from the aforementioned documents.
One aspect of the FPGA is that unless you do very simple (external input read, some simple process, external output write) only, you will use the Feedback Node a lot. It is the primary means to allow to have algorithms refer to previous iteration values. Unless you have been working a lot with Feedback Nodes and/or Shift Registers already in your normal LabVIEW code, this will require a significant rethinking when coding for FPGA. It's also an interesting brain exercise as it adds a time dimension in reverse order to the whole coding algorithm. 😀 Evaluating boolean operations with such logic can be at first a little challenging.
For the rest, you do want as a clean and concise interface between RT and FPGA as possible. And you need to think about some synchronization mechanism between the two. If you use FIFOs (for large and/or fast data transfers) this is already taken care of, but if you use frontpanel controls to pass data to the FPGA (configuration and control settings for instance) you have to consider that your FPGA is likely looping a few 100 times around in the time it takes your RT application to update two different controls on the FPGA interface. So if you have more than one control that can affect the same code path in your FPGA you either need to evaluate that the resulting execution will never run into an inconsistent state when you update one control while the other has still the old value, contain all the related settings into one control (cluster), or use some specific handshake mechanism where an extra boolean or such indicates that the settings are now consistent and can be used in the FPGA logic.
