Table Of Contents

Strategies for Testing FPGA Applications

Last Modified: April 22, 2016

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 unit is 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. Testing at the unit level allows you to make sure each algorithm or processing function in your application generates the results you expect. A unit cannot include any the following characteristics:
    • I/O, data communication, or target resources.
    • Multiple loops running in parallel or at different rates.
    • Reliance on the specific passing or control of time.

    You can call units as subVIs, subCDLs, or subMRDs that you can reuse in other parts of your application.

  • Component—Components are more complex levels of code that rely on the timing in the system. Like units, components are modular and usually have a clear task or objective to accomplish. However, unlike units, components test multiple processing functions or algorithms and how they interact with each other. A top-level FPGA VI usually consists of multiple components. Testing at the component level allows you to make sure that a component interacts properly with the I/O or host VI without having to wait until you assemble the whole system.
  • System—The system is 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. If the FPGA VI runs on its own after you deploy it and does not send data to the host, just the top-level FPGA VI represents 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. Testing at the system level allows you to make sure that all the components in your system communicate with each other properly and the system generates the results you expect. 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 testbenches 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 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:

  • Multirate diagram on the host— When developing a Multirate diagram on the host, call the Multirate diagram from a testbench VI on the host. Unit test Multirate diagrams on the host before you convert the floating-point data types in the document to fixed-point so you can more easily adjust your design based on the test results.
  • Multirate diagram in an FPGA VI—To test a Multirate diagram called by an FPGA VI, create a testbench VI on the FPGA that uses FIFO references to send data samples to the Multirate diagram.
  • Optimized FPGA VI on the host—When developing an optimized FPGA VI on the host, call the optimized FPGA VI from a testbench VI on the host. Unit test optimized FPGA VIs on the host before you convert the floating-point data types in the document to fixed-point so you can more easily adjust your design based on the test results.
  • Optimized FPGA VI in Clock-Driven Logic—To test an optimized FPGA VI called by Clock-Driven Logic (CDL), make sure the optimized FPGA VI is in a CDL document. Then use a Run FPGA Simulation node to call the CDL document from a testbench VI on the host.
  • Clock-Driven Logic—To test CDL code, use a Run FPGA 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, such as a single Clock-Driven Loop that calls an optimized FPGA VI and communicates with a Multirate diagram, 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.

Recently Viewed Topics