As wireless standards continue to evolve, software-defined ?test systems will continue to evolve with them.
By Luke Schreier, National Instruments
As the proliferation of wireless standards continues, the idea of using software-defined measurement capability has become a necessity as opposed to a matter of
click to enlarge
Figure 1. The link timing requirements (T1, T2, T3, and T4) for RFID tags force decision making to occur in the hardware rather than the host.
Thankfully, the core set of measurements required to test each of these standards is similar. As an example, error vector magnitude (EVM) measurements are a part of the EDGE, WCDMA, WiMAX, Wi-Fi, ZigBee and Bluetooth standards with varying degrees of accuracy necessary to be compliant. So, it’s possible to have a set of tools, often a vector signal generator and vector signal analyzer, that can cover the measurements across most of the standards. The key then becomes having the right software to take advantage of the hardware. This is the concept of virtual instrumentation, where the software defines the capability of the equipment to test for a standard. This concept is visible in many different boxes or modular instruments where separate software packages are available for different standards with the same hardware.
But, what happens when the computational power of the software alone does not meet the test requirements? Some applications do not allow for the latency involved in moving data from an instrument across a shared bus to a microprocessor and then back to the instrument. And even with high-bandwidth buses like PCI Express and multiple processing cores on the latest PCs, the sheer amount of data involved in RF applications can be overwhelming. For this reason, many virtual instruments are now offering the ability to take standard-specific code or measurement capability and deploy it onto user-programmable FPGAs inside the instrument for signal processing, data reduction, coprocessing or digital upconversion/downconversion. This article examines several applications for this technology using off-the-shelf instrumentation and graphical programming with the NI LabVIEW FPGA Module.
Data Reduction through Digital Upconversion
One of the most useful applications for a user-programmable FPGA is on an instrument reducing the amount of data that must be sent to or from the host, thereby freeing up the communications bus for other data transfers while reducing the burden on the CPU. In the case of RF, the amount of data alone can be more than the bus or onboard memory can handle, so reducing it in some way is the only option. For instance, generating an RF signal with only 100 kHz of bandwidth still requires you to digitally upconvert the 100 kHz signal to an IF (say, for example, 25 MHz) before you can further upconvert it to the desired radio frequency. This process is called digital upconversion (DUC). For 16-bit data, performing DUC on the host processor for the 25 MHz IF requires you to transfer more than 100 MS/s of data to the vector signal generator. Even with several hundred megabytes of onboard memory on the instrument, the playback time would be very limited for most wireless standards.
One method of data reduction for that situation would be moving the DUC computation to the instrument’s FPGA. For example, the NI PXIe-5442 16-bit, 100 MS/s arbitrary waveform
Protocol-Aware RFID Testing
In the semiconductor test arena, previous test methods involving standard digital test vectors are becoming difficult or even impossible with protocol-based devices. This is especially true for RF chips where the only means of communication is through wireless protocols, often requiring master and slave responses within a clock cycle. This shift has led to the demand for “protocol-aware ATE,” or test equipment’s knowledge of the protocols used on the device and onboard processing to accommodate timing requirements.
An RFID tag provides a challenging example of this. The only way to communicate with the tag is through a wireless protocol featuring minimum and maximum response times. Therefore, the process of testing these devices requires full emulation of the test sequence in hardware to meet the timing requirements. Figure 1 represents a typical RFID tag test sequence with the tester functioning as the interrogator.
Through a command sequence between the devices, an RFID reader can identify the electronic product code (EPC) of an RFID tag. According to the ISO 18000-6 type C protocol, an RFID tag reader can send data at a variety of symbol data rates. In fact, the period to transmit a binary “zero” symbol, called “Tari” (type A reference interval), can range from 6.25 to 25 ms. For a test to be successful, the RFID test system must simulate an entire inventory round using custom values for parameters, such as Tari, link timing and modulation depth. Meeting the microsecond timing specifications, though, virtually eliminates the option of communicating back and forth with a host processor.
When engineers can run the intelligence for coding/decoding, modulation/demodulation and more on a LabVIEW FPGA target inside the measurement system, the timing is well within range. The NI PCI-5640R IF-RIO transceiver has the necessary A/D and D/A converters (14 bits, 20 MHz real-time bandwidth), DUC and DDC capabilities, and FPGA space to include decision making for the RFID tag test. When engineers pair the PCI-5640R with RF upconverters or downconverters, they can perform these tests in the HF (13.56 MHz), UHF (850 to 950 MHz) or microwave (2.40 to 2.45 GHz) ranges, depending on their DUTs.
For very complex data manipulation and signal processing, it is often necessary to dedicate processing power to this task alone. Multicore controllers provide one suitable avenue for this, but, for the ultimate in parallel
click to enlarge
Table 1. Performing digital upconversion in the onboard FPGA of an arbitrary waveform generator results in significantly longer playback times across multiple RF standards.
As wireless standards continue to evolve, there is little doubt that software-defined test systems will continue to evolve with them. Wireless system designers and test engineers alike can take advantage of the latest tools and techniques described in this article for programming the hardware in a test system as well as the software for the most complicated devices. This, as well as the natural progression of multicore controllers and high-bandwidth buses like PCI Express, will help keep measurement equipment moving in the right direction.
Luke Schreier is the group manager for modular instruments in the strategic marketing organization at National Instruments. He can be contacted at Luke.Schreier@ni.com, 512-683-3562.