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.
preference. The days of purchasing a new box to test a new standard are simply behind us, especially as multiple standards make their way onto the same devices. The latest Apple iPhone is one example – UMTS/HSDPA, GSM/EDGE, 802.11b/g, Bluetooth 2.0, GPS and multiple non-RF audio and video formats are all combined into one cost-sensitive device.

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

click to enlarge

Figure 2. This LabVIEW FPGA code demonstrates acquiring data and sending it to a coprocessor for spectral analysis. The top section is the acquisition from one device, and the bottom section is the coprocessing performed on another device.
generator quadrature DUC capability takes I and Q complex waveform data, and, through onboard signal processing in the FPGA, interpolates the baseband signal and upconverts the data to a carrier frequency of up to 43 MHz with 40 MHz of real-time bandwidth. Performing this processing in hardware rather than software results in dramatically faster waveform computation and smaller sizes, saving waveform download time and providing longer playback time (through more efficient use of onboard memory). This improves the statistical significance of many measurements and visualizations, such as bit error rate, trellis plots and constellation plots. Table 1 illustrates some of the common communications applications and the waveform playtimes possible from the PXIe-5442, allowing for large PN sequence signal generation for enhanced bit error rate test (BERT) of receivers.

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.
processing, it is difficult to surpass the capability of a FPGA. With intense signal or image processing applications and real-time rendering requirements using multiple fast Fourier transforms (FFTs), a sequential processor struggles. Using the new fixed-point math capability of the LabVIEW FPGA module and the available FFT IP on, an engineer can place up to eight parallel FFT operations onto the Virtex-5 LX50 FPGA of the NI PXI-7842R multifunction intelligent data acquisition R Series module. With the dedicated bandwidth of PXI Express (up to 1 GB/s per direction) and peer-to-peer streaming on the horizon, this type of capability increasing in value for future test systems.

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, 512-683-3562.