Open FPGAs add flexibility to test
Most instruments today incorporate closed FPGAs (field programmable gate arrays) with fixed firmware to implement the capabilities of the instrument. If you ever seen a teardown of an oscilloscope, you've probably seen the FPGAs inside. FPGAs add processing power to test instruments and if you have access to an instrument's open FPGA, you can program your own test functions right into the instrument.
Instrument vendors have long seen the benefits of FPGAs and have taken advantage of their unique processing capabilities to implement instrument features, such as:
- The ability to do pre-trigger acquisition on an oscilloscope
- The signal processing to produce the I and Q data on a vector signal analyzer
- The pattern generation and vector comparisons of a high-speed digital instrument in real time
Test-equipment manufacturers are now opening up FPGAs to users to deliver more application-specific optimizations. To help understand why this is a good shift, here are some of the key attributes that make FPGAs useful for test applications:
- Deterministic, real-time processing
- Truly parallel execution
- Low latency
Taking that a step further, what can you do with open FPGAs that was not achievable before? To illustrate the possibilities, I'll show you some common test applications that take advantage of open FPGAs.
Test System Acceleration
In the end-of-line production test of a high-volume line, every second of test time counts. Production lines thrive when they can test at a rate matching that of production. When they cannot, innovative techniques must be employed to speed up the test time. A traditional approach would involve using separate bench-top instruments that connect to a host PC through Ethernet, USB, or GPIB. The resulting test time can be relatively slow because of the separation of DUT control, measurement, and processing through the data busses. Another approach is to use an open FPGA to accelerate the process, as shown in Figure 1.
Figure 1. In a test instrument, an open FPGA can add features such as triggering and post processing.
Instead of using external communications buses, the FPGA can use high-speed buses such as PXIe to instruments and be connected to the DUT through its configuration port, such as I²C, SPI, or another control bus. FPGAs in this kind of application can control the DUT (device under test), trigger other instruments to start acquiring samples, and even process those samples into meaningful results for the host.
Low latency is a key factor to accelerating these kinds of applications. An FPGA doesn't have an operating system, but instead has all of its logic implemented in hardware that is clocked at high rates. This means that a response might take one clock cycle to acquire, one to process, and one respond. At a clock rate of 200 MHz (clock period 4 ns), a full response would take 12 ns. Because of the deterministic nature of FPGAs, this response will take 12 ns not just once, but every time. Thus, and FPGA can cut out the latency of involving the host, plus is minimizes the non-deterministic latency of host-based processing.
Today, not all digital and MEMS devices can be tested against a known result vector. Take, for example, a PDM (pulse-density microphone) and give it a stimulus signal, you can't expect the resulting stream of bits to be identical from test to test because of the PDM's analog nature. To get meaningful results with DUTs like these, you first need to decode the digital stream with its specific protocol before you compare results. With an open FPGA, you can configure your test system to implement the PDM protocol on the FPGA instead of transferring it to be interpreted on the CPU. Extending this concept, you can have the same FPGA configured to implement the PDM protocol one day and reconfigure it to implement a different protocol for testing a digital temperature sensor, an accelerometer, or MEMs device the next day.
In Figure 2, the protocol is not implemented on the CPU, but the FPGA. Because of this, the test system can now natively support fast handshaking scripts, accommodate protocol behaviors such as precise wait cycles, and make decisions based off this communication. This approach not only allows you to receive higher-level data from the DUT, such as the decoded analog data in the case of a PDM microphone, but it allows you to write test scripts using higher level commands.
Figure 2. FPGAs can be used to process protocols, making them aware of the protocols in use by a bus.