Using FPGAs in Test Applications

Publish Date: May 06, 2014 | 2 Ratings | 4.50 out of 5 | Print | Submit your review

Table of Contents

  1. Background: What Is an FPGA?
  2. Specific Implementations for FPGAs in Automated Test
  3. Advantages of LabVIEW and NI Hardware Platforms for FPGA Applications
  4. LabVIEW FPGA Code Compilation Tools
  5. Choosing the Right Model for Your Needs
  6. Additional Resources

Software-defined test system architectures have become mainstream over the last several decades. Almost every automated test system uses application software to communicate through a driver to a bus interface on an instrument with I/O tailored to the needs of the measurement. You use this model when you connect a box oscilloscope over GPIB to a PC running NI LabVIEW software. Similarly, you can plug a multifunction data acquisition module into the same PC running LabVIEW to provide a different set of I/O across a different bus – PCI or PCI Express. In either method, the overall system architecture is the same, including the benefits: flexible, user-defined, automatable, and upgradable.

This model works perfectly for more than 95 percent of the automated test applications in use today, but new technologies and test methodologies on the horizon can pose some challenges to this model. Take hardware-in-the-loop (HIL) testing of an engine control unit (ECU) as an example. For an intelligent device like an ECU, the best way to test it is to see how it performs under the same types of conditions it experiences during real-world use. The most natural way to do this is to install the ECU in a vehicle and run it through a gauntlet of driving tests and conditions so each of the sensors and actuators sends varied data and receives responses for every possible driving condition from the ECU. However, this style of testing is not feasible in high quantities, and it more than likely leads to some conditions being under tested.

Using an electrical test system to emulate the sensors and actuators connected to the ECU provides a much more controlled and manageable test environment, but the demands placed on that test system are extremely high. How can the controlling PC respond to commands from the ECU as fast as a physical device like an actuator can? Each command may have to go through multiple layers of a software stack and allow for processing inside an operating system, making every decision a relatively time-consuming process compared to the raw feedback from the actuator.

Figure 1. NI PXI Hardware Modeling an Engine to Test an ECU

At some point, the efficiency gained from incorporating intelligence into the test hardware itself, which reduces the computational involvement of the PC, becomes the only way to meet timing requirements on such a system. Parallels also exist in modern RF and high-speed serial systems, where coding/decoding, modulation/demodulation, packing/unpacking, and other data-intensive tasks may need to happen inside a clock cycle of the device under test (DUT). In these cases, the software-defined architecture needs to be flexible enough to incorporate user-programmable hardware – often a field-programmable gate array (FPGA) – to place the necessary intelligence inside the instrument. This document describes common use cases and methodologies for FPGAs in test applications.

1. Background: What Is an FPGA?

At the highest level, FPGAs are reprogrammable silicon chips. Using prebuilt logic blocks and programmable routing resources, you can configure these chips to implement custom hardware functionality without ever having to pick up a breadboard or soldering iron. You develop digital computing tasks in software and compile them down to a configuration file or bit stream that contains information on how to wire the components together. In addition, FPGAs are completely reconfigurable and instantly take on a new personality when you recompile a different configuration of circuitry.

In the past, FPGA technology was available only to engineers with a deep understanding of digital hardware design. However, the rise of high-level design tools is changing the rules of FPGA programming, with new technologies that convert graphical block diagrams or even C code into digital hardware circuitry.

Because FPGAs combine the best parts of ASICs and processor-based systems, all industries are adopting FPGAs. FPGAs provide hardware-timed speed and reliability, but they do not require high volumes to justify the large up-front expense of custom ASIC design. Reprogrammable silicon also has this flexibility of software running on a processor-based system, but it is not limited by the number of processing cores available. Unlike processors, FPGAs are truly parallel in nature so different processing operations do not have to compete for the same resources. Each independent processing task has its own dedicated section of the chip, and each task can function autonomously without any influence from other logic blocks. As a result, adding more processing does not affect the performance of another part of the application.

FPGAs offer the following benefits for automated test applications: high reliability, high determinism, true parallelism, and reconfigurability. Each of these traits can be a large value-add for complex test applications like the HIL system referenced earlier.

Back to Top

2. Specific Implementations for FPGAs in Automated Test

You can use FPGAs in the following situations for automated test:

1.      Data reduction and signal processing

2.      System control

3.      Closed-loop I/O and protocols

Each of these methods uses different traits of the FPGA.

Data Reduction and Signal Processing

Because of the raw processing power and parallel computing ability of an FPGA, you may want to use the FPGA to perform inline processing on a data stream, such as one coming from an A/D converter on a digitizer. The goal in this case is to reduce the processing burden on the host PC, as well as limit the amount of data you need to transfer across the bus to the PC. Examples of algorithms that you might use on an inline FPGA include filtering, peak detection, fast Fourier transforms (FFTs), custom triggering, or algorithmic pattern generation for signal generator applications.

In a specific example, consider a continuous acquisition performed on a digitizer where only data that occurs between triggers is of interest. Normally, you can handle this by configuring the digitizer to trigger and then rearm for the next trigger. However, in a case where the rearm time might be too slow, the standard use model of the digitizer is insufficient. You can use an inline FPGA to eliminate data outside the trigger windows and return only valuable data to the host without invoking the standard triggering scheme of the digitizer. The graph in Figure 2 shows how this data might look.

Figure 2. Data Returned after FPGA Custom Triggering

Figure 3 shows this system. With an open FPGA on the digitizer, you can perform this custom triggering or any other algorithm on the data before sending it to the host PC over the data bus.

Figure 3. Digitizer with Custom Triggering Implemented in an FPGA

System Control

Another use case for FPGAs in test systems is as the master trigger controller of multiple instruments. By using an independent FPGA to handle the coordination of tasks across multiple devices, you add another level of determinism and intelligence to the decision making of a complex test system. You can also benefit from a quicker response to a system change with fault routines hard-coded into the silicon, eliminating any delay from a host OS interaction.

For example, consider a state machine implemented on an FPGA whose purpose is to coordinate starts and stops of scripts running on separate arbitrary waveform generators and digitizers. The FPGA is the master trigger input device, which sends the appropriate commands to the instruments for upcoming operations, as shown in the Figure 4 diagram. In this case, the FPGA is present in a PXI NI R Series Multifunction RIO module, and you can easily facilitate the triggering communication across the PXI backplane to the digitizer and the arbitrary waveform generator in adjacent slots.

Figure 4. PXI NI R Series Multifunction RIO Module Sending Commands to Instruments

Closed-Loop I/O and Protocols

When the DUT requires real-time decision making by the host to properly test the device, such as the HIL system described earlier, you must fully deploy the intelligence to the FPGA for pass/fail guidance. This is often the only way to meet the intense timing and determinism required by the DUT. Examples of this type of device include RFID tags, memory, microcontrollers, and ECUs. For some applications, you also perform the communication over a protocol – wireless or wired – which requires a significant layer of coding and decoding before making a decision.

For example, RFID standards specify minimum and maximum response times. Therefore, the process of testing these devices requires full emulation of the test sequence in hardware, and the tester must meet the timing requirements, which are often as strict as tens of microseconds. The Figure 5 diagram represents a typical RFID tag test sequence, with the tester functioning as the interrogator.

Figure 5. Link Timing Requirements (T1, T2, T3, and T4) for RFID Tags Heavily Burden Test Equipment

Through a sequence of commands sent and received between both devices – called the inventory round – an RFID reader can identify the electronic product code (EPC) of an RFID tag. For passive tags, the interrogator initiates an interrogation round with a query command. Upon receiving the command, the tag responds with an RN16 command in accordance with the T1 link timing specifications. Based on the exchange of these two commands, it is essential that the interrogator respond with an Ack (acknowledge) command within the given T2 specification to ensure that the tag responds with the PC + EPC + CRC16 command sequence. Therefore, to validate proper operation and timing, you must simulate a complete inventory round. Table 1 details the link timing requirements specified by ISO 1800-6C.

  Minimum Nominal Maximum Description
T1 MAX (RTcal, 10Tpri) x (1-FT) – 2 µs MAX (RTcal­, 10Tpri) MAX (RTcal, 10Tpri) x (1+FT) + 2 µs Measure of time from interrogator transmission to tag response
T2 3.0Tpri­   20.0Tpri Measure of time from tag response to interrogator transmission
T3 0.0Tpri     Time an interrogator must wait after T1 before issuing another command
T4 2.0 RT­cal     Minimum allowable time between interrogator commands

Table 1. Link Timing Requirements as Specified by ISO 1800-6C

Note: RTcal is the duration of a data-0 symbol plus the duration of a data-1 symbol in an interrogator-to-tag transmission. Tpri is the equivalent of 1/BLF, where BLF is the backscatter link frequency.

Sending the data from the tag through a measurement system and back to the host does not meet the timing requirements (microseconds) demanded by this system. However, you can solve the problem by using an FPGA inside the measurement system to run the intelligence for coding/decoding, modulation/demodulation, and so on.

The NI PXIe-5641R RIO IF transceiver has the necessary analog-to-digital and digital-to-analog converters (14 bits, 20 MHz real-time bandwidth), digital upconversion and digital downconversion capability, and FPGA space to include decision making for the RFID tag test. When you pair the NI PXIe-5641R with the NI PXI-5610 2.7 GHz upconverter and the NI PXI-5600 2.7 GHz downconverter, you can perform these tests in the HF (13.56 MHz), UHF (850 to 950 MHz), or microwave (2.4 to 2.45 GHz) ranges, depending on your DUT.

Back to Top

3. Advantages of LabVIEW and NI Hardware Platforms for FPGA Applications

The NI LabVIEW FPGA Module can help you program FPGAs with a LabVIEW block diagram. The module uses code-generation techniques to synthesize the graphical development environment to FPGA hardware. This block diagram approach to FPGA is well-suited for an intuitive depiction of the inherent parallelism that FPGAs provide. Use this module with commercial off-the-shelf (COTS) hardware to create FPGA-based measurement and control hardware regardless of whether you have worked with hardware description languages (HDLs). This module offers the following benefits:

  • Use hardware targets that include PCI/PXI devices and modular stand-alone systems
  • Develop quickly with more than 100 FPGA IP blocks
  • Achieve fast communication with a host system using built-in I/O DMA
  • Create logic that can execute in one cycle of 40 MHz, 80 MHz, or faster clocks
  • Manage memory, first-in-first-out memory buffers (FIFOs), clocks, and I/O in the LabVIEW project
  • Use available wizards for a quick start or begin from a blank slate
  • Save development time by compiling faster with the LabVIEW FPGA Compile Farm Toolkit and LabVIEW FPGA Cloud Compile Service Beta, new in LabVIEW 2010

Several different hardware targets are available for the LabVIEW FPGA Module, and the following targets are specifically well-suited to test applications:

  • R Series Multifunction RIO – Feature a dedicated analog-to-digital converter (ADC) per channel for independent timing and triggering. This offers specialized functionality such as multirate sampling and individual channel triggering, which are outside the capabilities of typical data acquisition hardware. Instead a fixed ASIC for controlling device functionality, R Series offers a user-programmable FPGA chip for onboard processing and flexible I/O operation.
  • RIO IF Transceivers – Include A/D and D/A converters with up to 200 MS/s and 16 bits with high-performance FPGAs (Virtex-5 SX95T) for communications applications. The backbone of RF test systems, these transceivers are often connected to upconverters and downconverters.
  • NI FlexRIO – Provides a PXI FPGA module with a user-defined front end for a range of I/O offered by National Instruments or third parties, or I/O designed by the user with the module development kit. NI FlexRIO features the most flexibility for unique system requirements.

Back to Top

4. LabVIEW FPGA Code Compilation Tools

LabVIEW FPGA includes a standard compiler; however, FPGA compile times can last minutes to hours and require some amount of creativity and planning to schedule different work hours, take your lunch, or go home for the day during the compile time. Below are a couple of tools you can use to more efficiently compile your FPGA code and save time.

LabVIEW FPGA Compile Farm Toolkit
Using the LabVIEW FPGA Compile Farm Toolkit, you can to create an in-house compile farm that has many workers and that can be targeted by multiple developers. With this toolkit, any number of developers can target the central server. The server is responsible for farming out the compilation jobs to all available workers. Because you can have multiple workers, compiles run in parallel. If there are no available compile workers, the server queues the requests (FIFO) and farms them out when a worker becomes available.

Figure 6. Diagram of LabVIEW FPGA Compile Farm Toolkit

LabVIEW FPGA Cloud Compile Service Beta
With this beta service, National Instruments is giving FPGA programmers access to compile VIs in the “cloud,” completely offloading them from the development computer. By default, you target high-RAM 64-bit machines that churn on FPGA compilations with the latest computing technology. Additionally, you can compile many VIs in parallel to test different versions of a code fix. To sign up for this high-security cloud service, e-mail Rick Kuhlman at rick.kuhlman@ni.com.

Back to Top

5. Choosing the Right Model for Your Needs

This document covered the use cases for FPGAs in automated test applications and some of the products available to meet those needs. However, every application does not require an FPGA, and the true benefit of a software-defined test system architecture is its ability to scale from more standard use cases like the oscilloscope connected to a PC mentioned earlier all the way to some of the FPGA techniques described later in this white paper. A flexible system designed with these architectures in mind can meet the needs of DUTs today as well as even more complex devices developed in the future.

Back to Top

6. Additional Resources

Read an Introduction to LabVIEW FPGA

View a Case Study on Using LabVIEW FPGA and the NI PXIe-5641R RIO IF Transceiver to Create a Channel Emulator
 

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit