1. Using LabVIEW Statecharts with FPGA
With statechart diagrams, you can design systems by defining states, transitions, and events. Statecharts are most beneficial for event-based designs such as communication protocol implementation, system fault-handling design, user-interface creation, and state machine development. You can deploy LabVIEW statechart diagrams to many computing targets including desktop PCs, real-time controllers, and FPGAs. The LabVIEW Statechart Module integrates seamlessly with the LabVIEW FPGA Module so you can design digital logic on reconfigurable hardware with statechart diagrams and dataflow graphical programming without low-level description languages or board-level design.
This paper describes how to use the LabVIEW Statechart Module to program the Serial Peripheral Interface digital communication protocol onto an FPGA. The paper starts by reviewing background information on the SPI digital communication protocol, then describes how it is implemented in the LabVIEW Statechart Module with LabVIEW FPGA.
2. Serial Peripheral Interface (SPI)
SPI is a synchronous protocol often used for data streaming (as opposed to reading and writing) and, therefore, often chosen for communication between microprocessors and digital signal processors. The SPI protocol consists of data packets sent between at least two devices – a master and one or more slaves. The master device controls two digital signals, the ChipSelect signal (to choose a slave to communicate with) and the Clock signal. The slave device has a dedicated ChipSelect data line from the master and sometimes, in the case of multiple slave devices, one line for all devices. If the application involves two-way communication between master and slave, you can use two data lines – master out, slave in (MOSI) and master in, slave out (MISO). Figure 1 shows the lines used to communicate between the master and slave devices. For more information on the SPI protocol, see the link below.
Figure 1. Representation of SPI Communication between Master and Slave
3. The LabVIEW Statechart Module
Prior to the release of the LabVIEW Statechart Module, there were two common ways to implement state machines in LabVIEW. The LabVIEW implementation of a state machine without any add-ons included enclosing a case structure inside a while loop. While this method is effective, you cannot see the general flow or entire code at the same time. The LabVIEW State Diagram Toolkit brought LabVIEW a higher level of abstraction by seeing each state. The LabVIEW Statechart Module takes state machine design to the next level with a broad and total picture of a state machine, hierarchy, concurrency, triggers, and guards while incorporating the familiar LabVIEW user interface.
For this application, the LabVIEW Statechart Module is very useful to implement digital communication encoding and decoding. With the LabVIEW Statechart Module, the natural breakdown of the timing diagram happens in separate steps. This isolates each step to reduce complexity in the program for any single part of the implementation. It also simplifies generic operations, such as error and exception handling, and helps you go from anywhere in the protocol execution to special error-handling states. The LabVIEW Statechart Module also provides a higher level of abstraction to simplify a complex application by offering a system-level view.
4. FPGA Design
With LabVIEW FPGA, you can use the familiar graphical dataflow development of LabVIEW to create custom I/O measurement and control hardware without low-level hardware description languages or hardware board-level design. This hardware and software combination delivers flexibility in the system design. The SPI communication protocol is a good example of the power the combination has – you can use it to create and implement a bus for interaction with another system. With the addition of the LabVIEW Statechart Module, you can add a layer of abstraction from code to make such an interaction easier to visualize and implement.
Figure 2 is the timing diagram for SPI communication. Once the ChipSelect line is set to low, the bits are sent to that particular slave device over the MOSI line one at a time while synchronizing with the clock line.
Figure 2. SPI Timing Diagram
For the SPI timing diagram, the following steps are a possible way to break down the timing diagram into a state machine:
1. Set ChipSelect low
2. Set Data (0)
3. Set Clock high
4. Set Clock low
5. Set Data (1)
6. Set Clock high
7. Set Clock low
8. Repeat Data and Clock for bits 2-15
9. Set ChipSelect high
These steps make it easy to see how you can break up this communication protocol into a finite number of states for the LabVIEW Statechart Module. Note that there are five unique steps, though some of them are repeated for each data bit. In the statechart, you create a unique state for each step and cycle through them. For the three repeating steps that update the data line and toggle the clock line, you can configure the statechart to repeat this sequence 16 times before proceeding to the last step.
Now consider the actual implementation of SPI communication using the LabVIEW Statechart Module with LabVIEW FPGA. This code was specifically designed for the NI PCI-7831R R Series intelligent DAQ board, but you can use the LabVIEW Statechart Module with any NI CompactRIO, PXI, or PCI R Series device. Figure 3 shows the LabVIEW statechart for the master device. Each of the timing diagram steps listed above are broken down into five states in the statechart (combining resetting the clock and the MOSI line into one). It also includes the idle state in which the master device waits until it receives a send command and returns to once the 16 bits have been transmitted to wait again.
Statecharts can have various elements that define execution. The Initial terminal on the statechart, which appears as a black circle, is a pseudostate where the statechart initializes. This defines the entry point into the statechart. Next, T1 is a transition that puts the statechart into the Idle state. For each transition, you can define a trigger and/or a guard. Triggers cause a transition to take place, while guards are conditional code evaluated to determine whether the transition is taken. The Idle state waits for a send command from the main application that triggers transition T2. Once inside the Write Bits superstate, substates configure the actual data transfer. Each state corresponds to setting or resetting one of the digital lines the FPGA is outputting.
Figure 3. The Statechart of the Master Device Writing Data
The behavior within states is defined with graphical LabVIEW code. Each state can have code that defines the action taken when the system enters the state or exits the state, or when a user-defined event occurs. For example, the LabVIEW code for the entry action of the Reset Clock and Output state is shown in Figure 4. In this state, the current bit is removed from the 16-bit data array and written out on an FPGA I/O node. Then, the current bit number is incremented so the next bit is written on the following iteration. In accordance with SPI timing, the Clock is set to low and the ChipSelect is kept low while the Clock only ticks once.
The transition from the Reset Clock and Output state to the Set Clock state must occur when the half the clock period has elapsed. Figure 5 shows how this transition is evaluated with LabVIEW guard code. When the half period of the clock equals the tick count, the transition occurs. The exit terminal supersedes any of the states in the subregion and prompts the statechart to exit at the time the trigger occurs no matter which state the program is in within the subregion. If the output is complete and the statechart is not instructed to exit, it returns to the Idle state and waits.
Figure 4. Reset Clock and Output Entry Action
Figure 5. Guard for Transitioning from Reset Clock and Output to the Set Clock Configuration
When you finish developing the statechart, you can generate a LabVIEW subVI that encapsulates the diagram and the code. Figure 6 shows the statechart VI in the block diagram circled in red. It has the trigger input as well as data inputs and outputs. The Write trigger is an input into the statechart that triggers the write bits action. The statechart acts as a subVI you can use to pass data into and out of as well as open up separately in a window for editing.
Figure 6. LabVIEW FPGA Code with the Statechart Circled in Red
Statechart code generation creates LabVIEW code behind the scenes. A main advantage of the LabVIEW Statechart Module is the ability to take a computational model and translate it automatically into FPGA code without any extra work, but still getting the benefits of using a statechart including abstraction and scalability. The code can be debugged and compiled without an FPGA board so developers can easily validate their designs on the desktop before compiling and running on an FPGA. Statechart also enforces FPGA syntax rules when editing the guards and actions, helping to ensure the code smoothly compiles.
In the cases where space is a concern on an FPGA, keep in mind that the LabVIEW Statechart Module has some overhead. When compiling the code implemented with a LabVIEW statechart and comparing it to the same code written using the LabVIEW representation of a state machine, the statechart code used 3 percent more slices.
The statechart implementation also can decrease the theoretical maximum clock rate. The reason for this is that one tick corresponds to one state checking one exit transition. If there are multiple possible paths out of a state, it takes multiple ticks to evaluate them, which proportionally slows down the theoretical maximum clock rate. However, in the SPI implementation described, the drop in theoretical maximum did not affect the requested rate, so no problems occurred. This is something to take into consideration when trying to develop a fast system or communication protocol.
For comparison, Figure 7 shows the same SPI output using FPGA through the LabVIEW representation of a state machine. With this representation, you can see certain parts of the code that are inside a state or transition, but you cannot easily visualize the individual states the program goes through as with the abstraction gained from the LabVIEW Statechart Module.
Figure 7. Non-Statechart Implementation in LabVIEW with FPGA
Engineers developing test applications using unsupported or custom digital communication protocols can use the LabVIEW FPGA Module to quickly implement or prototype different communication interfaces on FPGA-based National Instruments R Series reconfigurable I/O hardware. The new LabVIEW Statechart Module helps you define states, transitions, and events to simplify state machines, such as communication protocol implementation, by adding abstraction in giving a system-level view, as well as hierarchy and concurrency. The LabVIEW Statechart Module adds another model of computation to LabVIEW and helps you design applications at a higher level of abstraction than previously possible while gaining maintainability and scalability. With this powerful new software design tool, the National Instruments graphical system design platform can help you address your increasingly complex application needs.
6. Related Links
For more information please see: