In the design process, after the first prototype returns from fabrication, engineers often use traditional test equipment to make low-level measurements such as digital rise times, voltage thresholds, and leakage currents, and analog harmonic and spurious distortion, noise, and more. Once these parameters are verified to be within specification, higher-level attributes such as protocol compliance on digital devices and modulation parameters on communications devices are then checked. This gives the engineer a good understanding of how the device behaves, and whether or not that behavior allows the device to properly interact with the world around it. However, how can you guarantee that the device will continue to operate over time, with the myriad of permutations of device state, data content, and in the presence of non-ideal, real-world conditions? Who has the time to run all those tests?

FPGAs

Figure 1. NI LabVIEW FPGA code for a continuous bit error rate tester, showing the simplicity of a high-performance application.
Enter FPGAs. Field-programmable gate arrays (FPGAs) have long been used to implement hardware-defined functionality in prototype and low volume systems due to their versatility, reconfigurable nature, and cost advantages over custom silicon. But as development tools continue to evolve, FPGA technology is becoming more accessible to a broader variety of users. One new application area for FPGAs is in automated test because FPGAs bring a number of advantages to test systems, namely algorithm parallelism, higher performance processing, and ultra-low latency decision making. FPGAs can add value to the design process by running extended high-level or real-world tests, interfacing with the design-under-test in a deterministic manner, with the processing capabilities to sufficiently model the outside world in real time. Take, for instance, a high-speed digital bus. Any communications channel has some non-zero probability of inducing errors, and it is important to know if the theoretical performance calculated during design holds true in the real world. Performing such a measurement using traditional methods would be prohibitively slow, however, due to the vector-based nature of most digital test equipment. As significant time would be spent creating test vectors, transferring data to and from instrumentation, and comparing stimulus and response data, the fraction of time spent actually transmitting or receiving data over the bus would be quite low. If all this functionality is instead moved onto an FPGA and the pattern generation and comparison calculations are performed in real time, the duty cycle of the test reaches 100 percent. Furthermore, this can be completely automated and requires no human intervention. In this manner, bus tests of hours or even days can be run to gain greater confidence in the design.

One example of FPGA-based test hardware is NI FlexRIO, a modular instrument for PXI which enables users to buy or build test or application-specific I/O and interface to NIST-traceable instrumentation through the high-bandwidth PCI Express / PXI Express backplane. Using the NI LabVIEW FPGA module, you can program the NI FlexRIO FPGA with a high-level software tool, configuring the FPGA graphically rather than through text-based HDL languages.

Performing A Bit Error Rate Test

To perform a continuous bit error rate test on a bus using an FPGA, you must dynamically create the stimulus test vectors as well as the anticipated response. Linear feedback shift registers (LFSRs) provide a simple, yet effective method of creating pseudo-random bit sequences (PRBS).

Figure 2. The host application for the bit error rate tester provides a simple, customizable display for calculating, viewing, and recording bit errors.
In the FPGA code in Figure 1, section A generates an 8-bit wide PRBS on connector A of the digital adapter module attached to the FPGA. Section B simultaneously reads samples from connector B, which is cabled to the opposing end of the bus, while section C provides the option of simulating digital bit errors on the bus. Another LFSR is in section D, along with the code to account for the phase delay (in clock periods) of the bus and calculate the total number of bytes received. Finally, section E performs an XOR on the stimulus and received data to accumulate any bit errors, while section F can optionally DMA the test data to the host for display.

With the speed of an FPGA, this code can run at 100 MHz for hours on end, providing a means to exhaustively test the device or design. Figure 2 shows a trace of the generated and acquired data, along with the total amount of data transferred, the number of bit errors, and the effective bit error rate. In this example, errors are injected onto the bus to simulate a noisy environment. You can see that the FPGA effectively identified 15 single-bit errors in over 1 TB of bus data. These errors would be difficult to detect through standard test vectors on traditional test hardware operating at a limited duty cycle.

Figure 3. Adding a 7, 4 Hamming code to the transmitted data reduces the bit error rate to 0, showing the ability of an FPGA-based test system to adapt to changing requirements.
One final addition to the test code that highlights the versatility of an FPGA is the ability to add forward error correction to the transmitted data through a 7, 4 Hamming code. This enables us to inject errors with the same probability as shown in Figure 2, while reducing the actual number of bit errors to zero (shown in Figure 3). This represents the ability of FPGA-based test hardware to easily accommodate and test late-stage design changes, often made to combat problems found midway through validation and verification testing.

Testing Analog Channels

Without limiting these techniques to digital channels, we can perform the same bit error rate tests on modulated, analog channels. While digital buses strive to achieve strict control over the variance in performance parameters, analog channels suffer from the potential of far greater impairment, both in magnitude and the number of distinct types of impairment. Furthermore, each of these impairments can have specific effects on the chosen modulation standard. To thoroughly test a device employing such an analog channel presents an unmanageable number of permutations. By implementing and varying these impairments on an FPGA-based test system, greater confidence can be gained in the design.

Figure 4. NI LabVIEW FPGA code for bit error rate test of a differential 8-PSK communications channel.
Swapping the high-speed digital adapter module used to test the bus in the first example for a baseband analog module, you can now test analog communications channels. Figure 4 shows the FPGA code for the link and physical layers of a communications system. The top loop generates data to be sent to dual digital-to-analog converters (DACs) for baseband (I and Q) transmission at 25 MS/s, and the bottom loop acquires data from dual analog-to-digital converters (ADCs) at 25 MS/s and compares the received data to that which was transmitted. In the generation loop, block A creates dynamic yet deterministic packets of data for transmission, while block B adds framing information to the digital data. Block C performs differential, 8-phase-shift-keying (D8PSK) modulation, and block D adds pulse shaping to minimize spectral emissions. Section E provides the ability to add gain and noise to the data streams before sending the data to the DACs. In the acquisition loop, section F acquires samples from the ADCs and performs D8PSK demodulation. Block G removes the framing information, and finally block H phaselocks packets of received data to locally-generated data (using the same method as in block A), counts the amount of data received, and searches for and accumulates any errors.

A simple host application (as seen in Figure 5) can again run tests of this communications channel for hours on end this time varying the noise injected into the analog channel. You can see that as the noise increases, the bit error rate approaches 100 percent. In addition to white noise, you can also add other impairments such as adjacent channel interference, unintended spurs, or even multi-path fading.

Summary

Figure 5. The host application for test of an analog communications channel, completely automating the 10 hour characterization of noise versus bit error rate.
With the flexibility of FPGAs and the efficiency of high-level design tools, new methods of automated design test are now accessible to a broad audience. For digital designs and interfaces, FPGAs can run indefinite bit error rate tests, emulate protocols and other devices or sub-systems providing real-world context to the device under test, inject bit

errors either randomly or deterministically and capture any anomalies to feed back into the design process for hardware changes, firmware modification, or software updates.

FPGAs can do all these same things for analog designs and interfaces through high-performance connectivity to modular test equipment or application specific FPGA adapter modules. By adding a communication protocol to the FPGA, the same digital bit error rate test can be run over a modulated analog channel. The FPGA can inject errors either bit errors in the modulated signal, or noise or harmonic distortion before raw samples are converted to an analog signal. They can even log records of any errors for off-line analysis.

In short, adding FPGAs to your design process for extended device test can give you greater confidence that your product will operate properly after deployment, continuously, and be able to handle the wide variety of conditions it will encounter over its life.

This article was written by Ryan Verret, Product Manager, FPGAs for Test, National Instruments (Austin, TX). For more information, contact Mr. Verret at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit http://info.hotims.com/28059-400 .