Strategies for Testing FPGA Applications

Testing an application, and the pieces of the application, allows you to ensure that the application functions as you expect and helps to prevent errors later in development.

Test your application on three levels: unit, component, and system. Testing smaller portions of code as you create them saves time by identifying and preventing errors and bugs as your program grows. If you test and debug the functionality of the code extensively at the unit and component levels, you reduce the potential for errors at the system level.

Refer to the following guidelines for help identifying units, components, and systems:

• Unit—The most fundamental level of code you can create that can receive known inputs and generate expected outputs. Units map to a specific processing function or algorithm that you cannot break down further to accomplish a meaningful task. Test at the unit level to make sure each algorithm or processing function in your application generates the results you expect. A unit cannot include any of the following characteristics:
  • Real-world I/O
  • Interaction with target resources or data in a separate unit
  • Multiple loops running in parallel or at different rates
  • Reliance on the specific passing or control of real-world time, as opposed to simulated time

  You can call units as subVIs or subCDLs that you can reuse throughout your application.

• Component—Complex levels of code that contain multiple units and rely on system timing. A Clock-Driven Loop and every subCDL inside of the loop is an example of a component. Like units, components are modular and usually have a clear task or objective. However, unlike units, components test multiple processing functions or algorithms and how they interact with each other. Test at the component level to make sure that a component interacts properly with the I/O or host VI without waiting to assemble the whole system.
• System—The highest level of an application, or the application as a whole. If the host VI processes or logs data and runs the FPGA VI, both the top-level host VI and the top-level FPGA VI represent the system. The system interface is exposed to the host application, so tests are either very similar in nature to running your host application or include your host application. Test at the system level to make sure that all the components in your system communicate with each other properly and the system generates the results you expect.

Note

Before you deploy the application to an FPGA, use the FPGA Host Interface nodes to simulate running the application on the FPGA. After you deploy, connect all real I/O signals to your system and use the FPGA Host Interface nodes to run the application on the FPGA.

Create Testbench VIs to test individual units and components of your application as you complete them. A testbench is typically a VI that provides simulated input values to your code and displays the output of the code on the panel. When your system is complete, you can create a Testbench VI that runs your entire application, or you can simply run your host application.

The following list provides examples of tests you might perform on various FPGA-targeted documents:

• Clock-Driven Logic—To test CDL code, use a Run GCDL Simulation node to call the CDL document from a testbench VI on the host.
• Mixed languages in an FPGA VI—To test code that mixes languages in an FPGA VI, place the code in a top-level FPGA VI testbench. Use FPGA Host Interface nodes in a host VI to run the FPGA testbench in simulation on the host.
• Top-Level FPGA VI—To test your entire application, also known as the system, use FPGA Host Interface nodes in a host VI to run the top-level FPGA VI in simulation on the host.