Using FPGAs in Test Applications

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 undertested.

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.

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 upfront 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.

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 data acquisition (DAQ) 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 DAQ 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.

[+] Enlarge Image

Figure 5. Link Timing Requirements (T₁, T₂, T₃, and T₄) 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 T₁ 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 T₂ 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: RT_cal is the duration of a data-0 symbol plus the duration of a data-1 symbol in an interrogator-to-tag transmission. T_pri 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.

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

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

• R Series DAQ – Include A/D and D/A converters in the hundreds of kilosamples/second range at up to 16 bits with up to 160 low-speed (~10 MHz) digital I/O lines. These work well for physical measurements and PID-type control applications.
• 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.

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 the scalability from more standard use cases like the oscilloscope connected to a PC mentioned earlier all the way to some of these techniques described with FPGAs. 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.

 

Additional Resources

Introduction to LabVIEW FPGA

View a User Solution on Using LabVIEW FPGA and the PXI-5641R RIO IF Transceiver to Create a Channel Emulator

Reader Comments | Submit a comment »