Viewpoint News, June 2011

Part 3: How to Architect an Embedded LVRT Application

by James Campbell - jac@viewpointusa.com

Continuing with the theme of embedded applications, this month will review the framework used for most embedded system applications using NI RIO hardware. Next month, we’ll wrap up with a closer look at some Reference Designs for inter-process communications.

An application based on the RIO platform has three components: FPGA, RT, and Client PC. We need to connect them all so data and status is available where it’s needed. How should it all go together? By the way, this architecture is also useful for any LabVIEW RT app connected to a client PC.

Three Components

Overview

A typical embedded application uses:

• RIO FPGA for signal I/O, logic and calculations simpler to do in FPGA than RT, and any hardware-timed operations.
• RIO RT for the overall monitoring and control of signals, application flow, data storage, messaging to clients, and any user interface via Remote Panels.
• Client PC for any overall configuration and setup of the RIO, data archiving, and user interfaces. Sometimes the PC is permanently connected, but for embedded applications, this connection is typically occasional and random.

Diagram

The next figure shows the three parts and how they would connect.

RIO Details

FPGA/RT

The FPGA on the RIO device has a direct connection to the HW I/O, allowing reading and writing of analog and digital channels. The loops in the FPGA execute the code that reads the inputs, performs computations, and writes the outputs. Several parallel loops are typical.

You can move data around these loops via RT FIFOs or memory blocks on the FPGA. You can move data between the FPGA and the RT code via a DMA FIFO.

Note that the loops in the FPGA and loops in the RT layers are generally asynchronous.

Best Practices: Accessing shared resources on the FPGA can slow down timing. For example, using a particular analog input channel in more than one place in the code may slow down timing because you can’t read the AI value at the same time in both places. The same is true for using an FIFO: only one write can occur at a time into the same FIFO. To assure that multiple access behaves properly (albeit slower), shared resources are arbitrated. Arbitration consumes additional space on the FPGA fabric, so it’s best to avoid such usage. Note that resources that use a read/write scheme, such as a FIFO or memory block, can be shared without issue, since writing in one spot in your code and reading in another spot does not need arbitration.

Best Practices: An RT FIFO acts like the usual LV queue structure except the RT FIFO handles only basic data types (e.g., I32). The LV queue typically introduces more jitter that the RT FIFO but is able to handle arbitrary data types.

Best Practices: A Look Up Table (LUT) allows memory access (address selection and read) all in one cycle of a Single Cycle Timed Loop (SCTL). Block memory does not work in one cycle (pipelining can help here).

RT/FPGA

The real-time part of the RIO application pulls data from the FPGA via the methods described above. In addition, typically the Time Critical Loop (TCL) receives data from and pushes to the FPGA via one or more DMA FIFOs. The Main Loop (non-time critical) is less deterministic than the TCL. Typically, it handles data from the TCL via RT FIFOs as well as writing to or reading from values in the FPGA VI controls and indicators.

RT/Cloud

Moving data to/from the RIO can be done via FTP, when dealing with data files, or via Ethernet, when dealing with anything else. (Note that the data files can be local or on a USB-drive. The USB-drive introduces jitter due to USB system interrupts.)

For Ethernet, you can use TCP or UDP. Communications are message-based, so that all data are associated with a header describing the rest of the data. You can also setup the PC on the other side of the cloud to work through Web Services. NI uses the Restful architecture for Web Services.

Usually, the cloud connection is occasional, and so message-based communications need to handle opening and closing connections.

Best Practices: The Main Loop also pushes data to file or out the Ethernet port (TCP or UDP). More correctly, the Main Loop might use another RT FIFO to push data to separate loops (not shown in the diagram above) that handle the file data and the Ethernet traffic. Using these additional RT FIFOs alleviates timing constraints on the Main Loop and pushes data to loops that can deal with the latencies of file I/O and Ethernet.

Best Practices: Look at the Reference Libraries provided by NI (at ni.com) for STM (Simple TCP/IP Messaging) and AMC (Asynchronous Message Communication) for tools to communicate data when the app on the other side of the cloud is written in LabVIEW. Alternatively, for non-LabVIEW apps, construct your own Ethernet toolkit or use Web Services.

Conclusion

Two big parts of any general architecture for an embedded RT RIO (or any LabVIEW RT/FPGA) application are 1) the data communication schemes and 2) the appropriate use of time-critical and non-critical loops to reduce jitter where needed. Clearly, since any FPGA loop runs on HW, these loops have essentially no jitter (except that induced by the HW clock). But the methods used to move data around on and off the FPGA can significantly impact FPGA fabric usage. The RT layer needs loop and data communication that work in unison to keep jitter low.