An Improved SDR FPGA Verification Methodology for Emerging OFDMA Waveforms

February 1, 2013

The rapid evolution of commercial technologies such as Long Term Evolution (LTE) is becoming more attractive for Software-Defined Radio (SDR) and public safety applications ^[1,2]. They have the potential to support high data throughput applications with scalable subcarriers and the use of multiple antenna techniques such as Multiple-Input Multiple- Output (MIMO) technology.

Figure 1. Using SystemVue LTE test vector references for HDL code verification and FPGA hardware testing.

The complexity of commercial Orthogonal Frequency Division Multiple Access (OFDMA) waveforms such as LTE, however, poses significant challenges for SDR physical layer baseband development in which a common platform may be required to support multiple wireless formats. The baseband coding and decoding required for these waveforms are complex, and may require an improved design and verification methodology to ensure that FPGA test vectors are consistent with commercial implementations before customizing the waveform for potential SDR applications such as secure military communications.

For example, an issue with the implementation on a CRC (cyclic redundancy check) encoding block can result in many errors downstream at each subsequent coding stage. Tracing the error back to the CRC coding block can be difficult unless test vectors can be compared to reference vectors at each stage. Similarly, a simple sign reversal for an FPGA FIR (finite impulse response) tap coefficient may result in a demodulation problem that would be measured as Error Vector Magnitude (EVM) at the output of an SDR’s RF transmitter. At first glance, one might assume that a demodulation issue at the transmitter’s output would be an RF issue. However, probing the EVM at various stages along the mixed-signal/ RF transmitter chain (RF, IF, I/Q, digital) may trace the problem back to the FPGA section. Furthermore, probing at different stages within the FPGA implementation can help to pinpoint the problem in the FPGA implementation.

Figure 2. Using HDL co-simulation in SystemVue for debugging.

This article discusses an improved methodology to verify FPGA implementations for complex OFDMA waveforms such as LTE. This improved methodology will show how simulated LTE reference vectors can be used to ensure a consistent interpretation with commercial LTE configurations. The commercial LTE reference vector simulation blocks can also be customized for potential SDR applications such as secure military communications. In addition, Vector Signal Analysis (VSA) measurement software will also be used on a logic analyzer to probe within an FPGA design to ensure that the FPGA implementation can be demodulated with the VSA software at various test points within the FPGA implementation.

FPGA Development: Today’s Existing Approach

Figure 3. LTE I/Q modulator implementation on FPGA development board. Left: DAC output measured by Infiniium oscilloscope and VSA software, and right: FPGA digital IF measured by logic analyzer and VSA software.

FPGA developers typically start with system specifications that include behavioral requirements. These specifications will likely have some level of mathematical or pseudo-code representation, and may be part of a wireless standard that is still evolving and incomplete.

The FPGA development team will interpret these specifications and may develop their own reference models to generate stimulus inputs and expected outputs. These values, often called test vectors, can be used in testing of the HDL code used to generate the actual design through synthesis and backend map, place, and route tools.

Today’s OFDMA technologies such as LTE support many configurations, which can make it time-consuming and difficult to generate test vector reference models to support the many configurations. For example, LTE is scalable in which the number of subcarriers varies with the channel bandwidth selected (1.4, 3, 5, 10, 15, or 20 MHz). In addition, there are many coding configurations and modulation configurations such as QPSK, 16QAM, and 64QAM.

Generating LTE reference test vectors can present significant development time overhead for the FPGA engineer, given the many configurations supported by the LTE standard. Complex blocks, such as the Turbo coder/decoder, may involve significant time to create a behavioral test vector reference from scratch. Unfortunately, this can extend the development time already required for the primary task at hand — writing the HDL code for the actual FPGA implementation.

In addition to the development time overhead, there can be significant risk associated with this approach: the FPGA developer is writing/creating their own behavioral verification vectors to check their own HDL code. This is analogous to an author writing their own spellchecker. If an author is unsure about the spelling of a word, or convinced that a word is spelled in a particular manner, then spell checking with a self-written spell-checker can be ineffective in verifying the spelling. The same holds true for FPGA development. If the LTE standard is misinterpreted when writing the HDL code, the same misinterpretation may be repeated when creating the behavioral vector reference.

Configurable Reference Test Vectors

Figure 4. Close-up of logic analyzer VSA measurement (left) at FPGA digital IF and Infiniium oscilloscope measurement (right) at DAC output. Both showed degraded waveform quality and EVM of 7.2%.

An independent test vector reference conforming to the LTE standard, which is parameterized and configurable for the many supported LTE configurations, can help address these challenges.

This is illustrated in Figure 1, where vectors are generated with the independent test vector reference using the same stimulus that is applied to the HDL simulator. The HDL simulator output is then compared to the independent test vector reference to verify that they agree behaviorally.

If they do agree, the interpretation of the wireless standard is consistent. If they don’t agree, further de-bugging can be performed with the intermediate nodes of the independent test vector reference. The LTE reference blocks are configurable for the many configurations supported by LTE (e.g. different channel bandwidths, coding configurations, and modulation types).

Furthermore, the simulated test vector reference algorithms can be customized for applications that require customization of standardized technology for applications such as secure SDR military radio.

Figure 5. Probing at filtered I and Q outputs within the FPGA implementation.

It can also be useful to bring the HDL code into design simulation for direct comparison to the simulated test vector references in the design simulation environment. An example is shown in Figure 2, where HDL co-simulation is used to directly compare vectors with the simulated model.

Debugging with Vector Signal Analysis

Performing VSA modulation domain analysis on the digital I/Q or digital IF provides an additional level of FPGA design verification in addition to comparing test vectors of the baseband coding/ decoding stages. To illustrate this, let’s examine a case study.

An LTE I/Q modulator design is implemented on an FPGA development board as shown in Figure 3. The FPGA board includes a DAC, to convert the FPGA output to an analog output. A real-time oscilloscope with VSA software is used to probe the analog IF signal at the output of the DAC, as shown in the left side of Figure 3. In addition, a logic analyzer with VSA software is used to simultaneously probe the digital IF signal at the input of the DAC, as shown in the right side of Figure 3.

A close-up view of the VSA modulation domain measurements, performed with the logic analyzer probing the digital IF and oscilloscope probing the DAC output, reveal degraded waveform quality and EVM performance of approximately 7.2%. Waveform distortion can also be observed with the dispersion shown in the measured constellations on the upper left of the VSA displays. Since the digital IF from the FPGA output (input to DAC) and the DAC output reveal the same EVM result, the issue is resulting from an issue in the FPGA implementation and not from the digital-to-analog conversion with the DAC.

The challenge now is how to figure out the source of the error in the FPGA I/Q modulator implementation. Possibly, there is an issue with the digital upconverter (digital IF) from within the FPGA, or an issue with the digital I and Q paths or FIR filtering. How can the source of error be pinpointed?

Figure 6. Probing at filtered I and Q outputs within the FPGA implementation after correcting the FIR tap coefficient.

To debug the FPGA implementation, test points are placed within the Xilinx FPGA by using the Xilinx ChipScope Pro Core Inserter. One option in that tool is the insertion of a Trace Core 2 nd (ATC2). With such a measurement core, designated signals get assigned to “Signal Banks” through the use of a multiplexor and FPGA routing created inside the FPGA. Then selected signals are routed out to the FPGA I/O and ultimately to a connection point for a logic analyzer. Now deep capture traces can be taken on the signals.

The FPGA Dynamic Probe application can be used to select the measurement bank associated with the filtered I and Q data. The MUX is switched within the FPGA to access those signals, the logic analyzer captures those signals, and the VSA software processes them. The VSA constellation diagram shows significant dispersion that is contributing to an EVM 5.1%. The spectrum also looks incorrect.

Upon closer inspection of the individual filtered I and Q data signals (right side of Figure 5), we can see a difference in the overall shape of each signal. Notice that the I data, displayed in a “chart” mode (which converts digital data to displayed time domain waveform), has some higher frequency distortion present, yet the Q data does not have this distortion. A closer examination of the HDL code revealed a tap coefficient sign inversion on the I FIR. The FIR tap coefficient was corrected, and the FPGA design was recompiled.

Figure 6 shows the new measurement results with the I FIR tap coefficient corrected. The resulting constellation is noticeably cleaner, and EVM is now 0.5%. The spectrum no longer has images, and the I data on the right of Figure 6 no longer shows the distortion previously observed in Figure 5.

The VSA software also works with RF signal analyzers, so this debug methodology could be extended to the output of an SDR’s RF transmitter output to debug issues at RF, IF, and analog I/Q using an oscilloscope, or probing within an FPGA implementation, as shown in this example.

Summary

This article discussed an improved methodology to verify FPGA implementations for complex OFDMA waveforms such as LTE. Simulated commercial LTE reference vectors can be compared with baseband coding/decoding test vectors from an HDL simulation or by probing vectors with a logic analyzer. This can help to ensure a consistent interpretation of the many coding configurations and modulation configurations (e.g. QPSK, 16QAM, and 64QAM) supported by the LTE standard. In addition, the LTE reference vector simulation blocks can be customized for potential SDR applications such as secure military communications. Modulation domain analysis of the FPGA design can also be performed to verify the performance of the digital I/Q and digital IF stages. Using VSA software on a logic analyzer enables the FPGA implementation to be probed and debugged at various stages within the FPGA implementation, as discussed in the case study. Furthermore, using the same VSA software in design simulation software, oscilloscopes, and RF signal analyzers enables the system engineer to probe along the SDR’s analog baseband and RF chains (analog I/Q, IF, or RF), both in the design and test phases, to quickly identify and resolve potential issues.

This article was written by Greg Jue, Applications Development Engineer/Scientist, and Brad Frieden, Product Planner for the Digital Debug Solutions (DDS) product line at Agilent Technologies, Santa Clara, CA. For more information, Click Here