Testing DigRF for 3G handsets
The MIPI Alliance’s DigRF interface standards can simplify the design of cellphone handsets, but they challenge test engineers to find ways to reduce test-time overhead.
By Ed Seng, Teradyne -- Test & Measurement World, 5/1/2009 2:00:00 AM
|
See other articles from our May 2009 issue. |
DigRF stands poised to replace the two main forms of data-communication paths between RF and baseband semiconductor devices: analog signaling and design-specific, proprietary digital signaling (parallel or serial). With the DigRF (Digital Radio Frequency) standards, the MIPI (Mobile Industry Processor Interface) Alliance is striving to replace the assortment of I/Q (in-phase/quadrature-phase) signaling interfaces with a common digital, packet-based serial interface. A MIPI Alliance working group has developed DigRF specifications for the 2.5G and 3G mobile standards, and a follow-on revision with increased data throughput to support 4G standards is expected.
The use of a standard interface like DigRF provides designers with more flexibility in component selection. A designer, for example, may want to purchase an expensive baseband IC (which tends to be one of the more expensive chips in a cellphone) from one vendor while buying RF, power-management, and other devices from others. Yet, the very flexibility of the DigRF technology that leads to versatile products also creates challenges that affect your test strategy.
The main goal of the test engineer during RF receive tests remains the same as before DigRF—capture the I/Q information, execute custom digital signal processing algorithms on the resulting data set, and log the parametric result to determine whether the device passes or fails. But compared to previous generations of RFICs, DigRF devices can add significant overhead to production test. Finding ways to minimize this overhead is the major challenge for engineers designing an automated production test system.
Understanding the interface
DigRF 3G defines a minimum number of signals required to implement the interface; only six wires are needed in a basic handset configuration (Figure 1). The RxData/TxData signals transfer the digital representation of I/Q data as well as the control and status messages in a packet protocol.
 Figure 1. The basic DigRF handset configuration requires only six wires. |
Data transferred on the DigRF signals is encompassed in protocol packets, or frames. Each frame comprises three pieces: sync, header, and payload (Figure 2). The beginning of every packet consists of the same 16-bit synchronization sequence, used by the digital receive circuit for real-time strobe-phase alignment on every frame.
The subsequent eight bits make up the header, defining the purpose and content of the payload. The header itself is made up of three sections: three bits for the payload size, four bits to describe the LCT (logical channel type), and one bit for a CTS (clear-to-send) signal.
 Figure 2. A DigRF 3G data frame begins with a 16-bit synchronization sequence, followed by an 8-bit header and I and Q data. |
The payload may vary in size from packet to packet, resulting in different levels of encoding overhead. The LCT defines “what” the payload contains and can be categorized into control or I/Q data. The CTS allows the RF device to control data flow from the baseband device during RF transmission.
The remaining N bits of the frame contain the actual data to be transferred; for example, in the nondiversity mode of DigRF 3G, the RxData frame will use data channel C and 256-bit payloads consisting of alternating 8-bit I-data and Q-data.
| Table 1. DigRF timing modes for digital transfer | ||
| Speed mode | Speed | Usage |
| Slow | SysClk / 4 | 2.5G (interface start-up) |
| Medium | SysClk | 2.5G RxData |
| Fast | 312 Mbps | 3G and 2.5G (diversity, etc.) |
DigRF 3G supports three timing modes for digital transfer, determined by the type of RF information being transferred (Table 1). The DigRF standard also supports three common input reference-clock frequencies (19.0, 26.0, and 38.4 MHz); the clock is passed to the baseband over the SysClk signal. Independent of the speed mode, the DigRF processor manages the data flow with a local FIFO buffer, leading to an unpredictable timing of when the frame is transmitted.
Production testing challenges
The key to successfully testing devices that use the DigRF protocol is finding a way to manage the nondeterministic behavior of RxData packets during RF receive tests. During RF receive tests on DigRF products, the resulting behavior of the RxData signal is viewed at multiple levels of uncertainty:
-
phase timing,
-
frame timing,
-
frame type, and
-
data in payload.
A 312-Mbps data rate is derived from a 1/4 divider from a 1248-MHz master clock, typically generated with a PLL (phase-locked loop). In the production test system, the device clock input should be provided by RF instrumentation, considering the importance of phase-noise performance affecting the RF front end. The start-up phase of this clock source is usually not controlled relative to the normal digital subsystem. The combination of the unknown input clock phase of the DUT (device under test) and the phase-uncertainty generated by the PLL multiplier/divider results in RxData output timing that is unpredictable—both between device power cycles and between different devices in a multisite parallel test setup.
 Figure 3. Because of packet nondeterminism, during each of a device’s RF receive tests, the tester will not know on which tester cycle each packet will be transmitted, what type of packet it is, or if the packet type is expected. |
A production tester should have the ability to keep the digital subsystem running while making the necessary tester-hardware and DUT changes between tests. This enables the tester to preserve the strobe timing relative to the DUT output, saving test time by avoiding the need for strobe-phase realignments during the job run.
The next major test challenge is finding a way to handle the multiple levels of nondeterministic packet transfer behavior. As depicted in Figure 3, during each of the DUT’s RF receive tests, the tester will not know on which tester cycle each packet will be transmitted, what type of packet it will be, or if the packet type is expected (for example, the RFIC could generate an unsolicited control status message).
It is immediately clear that the test program cannot use fixed-cycle strobes in a digital test pattern to isolate the desired I/Q data. Similarly, digital match loops on the sync or header cannot flush through an ATE instrument’s pipeline fast enough at DigRF speeds, nor can the instrument perform the real-time recognition and decision making of the header information.
Comparison of ATE strategies
Traditional production test systems have static-strobe timing and a primitive compare functionality (for instance, H, L, X, M, V, store), so they do not inherently have the strong alignment necessary for addressing the nondeterministic behavior expected from DigRF devices. The digital instruments in such testers do, however, have the necessary digital-capture capability, which is commonly used for ADC (analog-to-digital converter) output data or DUT register-read actions. As a result, you can preserve your investment in this equipment and address the RF receive test challenges of DigRF by employing a block-capture-and-post-processing test strategy.
For RF receive tests, 1-kbyte to 4-kbyte I/Q samples are common for CW (continuous-wave) tests, while the increasingly common system-level tests using modulated waveforms use 16-kbyte to 32-kbyte I/Q samples. Note the conversion to actual serial bits:
1k I/Q = 1024 • [8 bits (I) + 8 bits (Q)] • protocol_overhead = number of serial bits
To address the nondeterministic behavior in real time, the tester must provide digital logic coded specifically for DigRF 3G between the DUT and the digital capture. The goal is to mitigate all the timing and data uncertainty while the capture is taking place, before the data reaches the tester’s DSP (digital signal processor).
One test option is to design an FPGA (field-programmable gate array) circuit on the DIB (device interface board) itself. This approach would enable you to provide custom logic in an inexpensive component, but it introduces three obstacles:
-
interfacing and providing support signals to the circuit will be much more complex,
-
there is an increased risk of adding a digital noise generator so close to these sensitive RF signals with limited ability for isolation and shielding, and
-
adding components to each device load board will increase cost and test development time.
As another option, you could use a digital test instrument that offers an embedded real-time capability, which would reduce costs while simplifying the DIB complexity. The downside to this approach is it lacks the flexibility needed by test engineers who must test a proliferation of communication protocols. Providing a solution solely for DigRF may not be practical.
In this option, the test program captures a large block of data on the RxData bus when it is known that RF receive data is available; the block must be sized to reliably capture enough packets that a sufficient number of I/Q samples will be present for postprocessing algorithms. The data is moved from the digital instrument’s capture memory to a DSP engine, where a preprocessing algorithm executes a three-step process:
-
find the start index of each packet,
-
analyze the header of each packet, and
-
sequentially de-interleave the embedded I/Q samples in the payload and store into new individual arrays.
Once the data is preprocessed, the user’s custom processing algorithms can execute the desired I/Q data sets or export them to other ATE software tools that will perform tests for properties such as EVM (error vector magnitude).
The success of this method relies on the data-move time and the efficiency of the required processing step. The key to minimizing overall test time is to avoid unnecessary host-PC interactions that require the test program to pause execution of the DUT tests. If the tester possesses the ability to move the data during the pattern capture, the entire time to transfer the data to the DSP is hidden in the background, resulting in a zero test-time penalty.
If the tester does not have this capability, the test engineer would have to find ways to reduce the amount of data moved. One option would be to only capture fail data, but this would add a new processing step for reconstructing the original data in the DSP; this unnecessary step alone could add multiple milliseconds of critical test time.
 Figure 4. Shown here are the test-time overhead of three test options: (a) serialized execution flow, (b) a block-capture-and-post-processing approach, and (c) real-time processing. |
A complete DigRF solution needs to execute both the preprocessing algorithm and the I/Q processing completely in the background. Thus, a third option would require the tester architecture to support dedicated processors to execute the digital signal processing algorithms, allowing the test program to immediately begin the setup of the next test once the capture of the DUT signal is complete. Additionally, multisite testing requires high parallel efficiency of this background processing.
Figure 4 illustrates the possible test-time impact of the three options. In the first option, the lack of background processing creates a serialized test flow, resulting in the longest test time. The third option, which employs real-time processing, seems most ideal, as it addresses the test challenges in the most efficient manner with full background processing.
Yet, the block-capture and post-processing approach can also have a low test-time overhead, as long as the data move takes place in the background and the processing is performed efficiently—without wasted steps and on separate multisite parallel processors. With the appropriate system capabilities, the preprocessing time can reach less than a few milliseconds in an octal-site program, good enough to remain hidden behind a typical RF setup time.
| FOR FURTHER READING |
| “Dual Mode 2.5G/3G Baseband/RFIC Interface v3.09.04 (DigRF),” MIPI Alliance, www.mipi.org. |
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
View All Webcasts
