Improving Instrumentation With User-Programmable FPGAs
The concept of virtual instrumentation is more than 30 years old, and its tenets are as true today as they were at its inception. Test functionality is defined by the user in software, as opposed to instrument functionality fixed by the equipment vendor using application-specific modular hardware.
This approach creates a flexible test-system architecture that can quickly integrate with the latest commercial technologies, such as multicore processors and the PCI Express data bus, resulting in increased performance and shorter test times with little or no change to test software. The embodiment of this concept has spread from simple GPIB interfaces to graphical programming languages to modular instrumentation platforms of many kinds.
For more demanding applications that require response times within a clock cycle, computation of large data sets, or extremely fast data transfer, virtual instruments are beginning to incorporate user-available field-programmable gate arrays (FPGAs). FPGAs on instruments are not necessarily a new concept; but in the past, you could not directly benefit from them. Today, more manufacturers include FPGAs on modular instruments and give you access in software to reprogram them according to your requirements.
Custom Data Reduction
One of the most useful applications for a user-programmable FPGA on an instrument is to reduce the amount of data that must be sent back to the host for post-processing. The most common methods for this are filtering, peak-detecting, or running (FFTs) on the acquired data set of an oscilloscope or digitizer.
Also consider a scenario where you are continually acquiring data through a digitizer but only concerned about the data that occurs in a window between rising and falling edges of a trigger clock. Normally, you could treat the acquisition as a simple trigger start/stop condition, but if the re-arm time for the next trigger is too long, you might lose subsequent data values on the next acquisition. With a user-programmable FPGA in the data path back to the host, you can return only the values occurring between edges of an external signal (Figure 1).
Another useful operation might be to add two channels in the FPGA and send back a single waveform as opposed to two separate waveforms that then would be added at the host. This type of signal processing, and many other examples like it, is relatively simple to code, and putting it on the user-programmable FPGA can free up valuable system bandwidth.
Protocol Emulation
Serial protocol communications can be challenging for standard instrumentation, especially digital equipment which normally deals with parallel test vectors. Andrew Evans of Broadcom presented a paper, “The New ATE—Protocol Aware,” at the 2007 International Test Conference, that examines a growing challenge with traditional digital testers. One excerpt states:
“The missing item is the programmable logic that would be used for the emulation. This logic would primarily consist of FPGAs and would reside between the ATE pin electronics and the rest of the ATE pin, which is the vector memory, pattern/timing generators, and formatters.”
The advantage of user-programmable FPGAs in this situation is the increased capability to provide in-cycle response in protocol communications scenarios. For traditional pin electronics that have been programmed with test vectors, adapting on the fly to the idiosyncrasies of different protocols is simply impossible, and asking the same digital pins to perform any signal processing inside that communications cycle is well outside their capability without a processing engine behind them.
Consider the implementation of SPI communications using the LabVIEW Statechart Module with LabVIEW FPGA for the NI PXI-7851R R Series FPGA Module. Embedding the SPI communications into an FPGA allows in-cycle response as a talker and listener for the chip. More specifically, the following steps are found in an SPI timing diagram:
1. Set ChipSelect low
2. Set Data (0)
3. Set Clock high
4. Set Clock low
5. Set Data (1)
6. Set Clock high
7. Set Clock low
8. Repeat Data and Clock for bits 2 to 15
9. Set ChipSelect high
In this example, there are five unique steps, though some are repeated for each data bit.
Figure 2 shows the LabVIEW statechart for the master device or, in this case, the tester digital pin. Each of the steps is broken down into five states in the statechart. Each state corresponds to setting or resetting one of the digital lines output by the FPGA.
Once created, this statechart diagram can be deployed directly to a PXI FPGA target to interface to the DUT. In this way, protocol intelligence or awareness is embedded behind each digital pin on the user-programmable FPGA, and decision-making for the communications happens in silicon. With SPI communications and frequencies in the tens of megahertz, this capability is beneficial. For serial buses at higher data rates such as PCI Express or Serial ATA, it becomes mandatory.
RFID Testing
Taking the protocol-aware use case a step further, consider RFID testing. With an RFID tag, you do not have any physical access points to probe, so the only way to communicate with the DUT is through a wireless protocol, often referred to as the air interface. Also, RFID standards specify minimum and maximum response times.
As a result, the process of testing these devices requires full emulation of the test sequence in hardware, and the tester must meet the timing requirements, often as strict as tens of microseconds. Figure 3 represents a typical RFID tag test sequence with the tester functioning as the interrogator.
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 basic idea is that the interrogator will initiate 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 that tag will respond with the PC + EPC + CRC16 command sequence. So, to validate proper operation and timing, it is necessary to simulate a complete inventory round. Table 1 details the link timing requirements specified by ISO 1800-6C.
Table 1. Link Timing Requirements as Specified by ISO 1800-6C
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 microsecond timing requirements demanded by this system. However, when you run the intelligence for coding/decoding and modulation/demodulation on an FPGA inside the measurement system, you can solve the problem.
Updating Firmware on Existing Instruments
Another use case for programming FPGAs to increase the performance of an instrument involves instrumentation vendors themselves. By leaving space on the FPGA of an instrument already in the customer's hands, they provide the ability to upgrade the firmware and add functionality.
A good example of this is the NI PXI-6552 100-MHz digital I/O module. At its release, this product only supported two logic levels: 0 and 1. You could program the VOH, VOL, VIH, and VIL of the module, but you could not achieve more advanced functionality like tri-stating or compare states.
Based on customer demand, we were able to update the FPGA on the module to support four more states: Z high impedance, H compare high, L compare low, and X don't care. With these additional states understood by the FPGA engine of the module, per-cycle tri-stating and onboard hardware comparison became available with a software driver update that downloaded new firmware. This opened the door for more traditional digital ATE applications where hardware decision-making on pass/fail operations is expected. It also made real-time bit error rate testing possible.
Future of FPGA-Based Instrumentation
As programming environments become even more powerful, programming FPGAs no longer is left in the hands of pure VHDL or Verilog developers. Test engineers specializing in many different domains, such as automotive, aerospace, medical devices, and high-energy physics, will be free to apply their vertical domain expertise to COTS technology and push the envelope even farther. The application of this concept assures the viability of virtual instrumentation for decades to come.
About the Author
Luke Schreier is the group manager for modular instruments in the strategic marketing organization at National Instruments. He joined NI in 2001 as an applications engineer before transitioning to product management in 2003. Since late 2006, Mr. Schreier also has been in charge of market development in semiconductor-related applications. He holds a B.S. in mechanical engineering from the University of Nebraska-Lincoln. National Instruments, 11500 N. Mopac Expwy., Austin, TX 78759, 512-683-3562, e-mail: [email protected]