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 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, subCDLs, or subMRDs 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:

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.