As might be expected, most of the challenges appear with code around the FPGA. Special care is needed to assure efficient use of the FPGA fabric. Furthermore, efficient methods must be used to get data off the FPGA into PC memory (and eventually onto the RAID drives) to handle high data rates and preventing lost data from buffer overflows.
Technically, the biggest challenge in these Digital Record and Playback systems deals with the integration of the CLIP nodes with the LabVIEW FPGA code. Developing the CLIP nodes requires good understanding of VHDL and, potentially, a good understanding of the Xilinx chipset capabilities.
If you are using external clocking, avoid a mistake we made in early projects: use only internal clocks or FAM-based oscillators as base clocks for the top-level FPGA application. Otherwise, as we discovered the hard way, the FPGA can lock-up when an external clock stops.
Also, if multiple clocks are needed, follow design rules carefully by using FIFOs to decouple clock domains.
Using external clocks or DDS clocks (from a timing module) is ok for some loops as long as controls/indicators are not used in those loops. Instead, input/outputs should be buffered through global variables or registers to the controls/indicators executing in a loop clocked by a permanent clock.
Use the provided base clocks for high speed loops whenever possible. Derived clocks may not be able to achieve the same timing as the provided base clocks.
Be aware of how many DMA channels will be required before purchasing hardware. Some FlexRIO models have significantly fewer channels than others, and don’t assume that a newer FPGA model has more DMA channels than an older model.
Regarding schedule management, the biggest lesson we learned early on in these projects is the compile time. Do not underestimate the FPGA compile times. Complex FPGA coding coupled with CLIP nodes will require multiple recompiles and the hours add up, which obviously extends the project delivery date.
The host layer provides the user interface and communication with the RT layer for messaging and data. Interfacing with the RAID drives might have made sense in the RT layer, but the RT OS does not support the RAID drives.
Also, our initial thought of pushing all the data into on giant TDMS file turned out to be slower than using multiple file streams. Of course, applications that need external clocking will likely require multiple file streams due to the possibly different data rates.