Basic Characteristics of Embedded High Speed Serial Links
by Jean-Manuel Dassonville, Agilent Technologies, Inc.
Internet mobility is growing today and is the way of the future. The challenge we are seeing with the current generation of Wireless Internet devices is revealed in the battle between Internet upload performance and battery life. End (cell phone) users’ expectations are rising to match the high upload speeds like those of the wired Internet -- without the burden of constantly recharging their batteries.
To address this challenge, the mobile industry is developing new high speed serial interconnect standards between components in a mobile handset that provide fast transfers and multiple power saving modes. As an example, DigRF V4 bus specification driven by the MIPI Alliance (Mobile Industry Processor Interface), is rapidly emerging as the next-generation serial interface between mobile baseband (BB-IC) and RF chips (RF-IC). DigRF V4 is designed for use in high bandwidth mobile systems that incorporate air interface standards such as LTE and WiMAX.
Beyond performance and power savings, the RF-IC to BB-IC connections have undergone an architectural shift (from analog or proprietary parallel busses) to standard serial links for several reasons. Standard serial links eliminate parallel bus clock skew, reduce the number of pins and traces, and therefore cost, and reduce the integration effort by enabling interoperability between chips from different vendors
However, the integration of high speed serial links in RF-ICs and BB-IC brings new design challenges:
• At multi-gigabit per second data rates and with channel flight times longer than a bit period, new effects such as signal integrity become a major concern. Under these conditions, high-speed analog effects can impair the signal quality and degrade the bit error rate of the link.
• To guarantee reliable data transfer between several devices, the DigRF standard is based on sophisticated protocol state machines, inspired from serial busses used in computer and communication systems. The result is that the design and validation of each layer of the digital protocol stack is getting more complex.
• The BB-IC to RF-IC interconnect is also a critical visibility point into the mobile system. It is used by RF designers to validate the operation of the RF-IC and debug the signal processing algorithms executed by the BB-IC. Engineers need new tools providing vector signal measurements from a digital interface.
The awareness of the convergence between the digital protocol domain and wireless domain in mobile handset design is of central importance. It helps prepare the design team for new test methodologies that would properly validate system operation in each domain, isolate domain specific issues while being equipped to find the root cause of cross domain problems. Expertise and integrated test solutions that cover the two domains (Protocol test, Modulation measurements) are of utmost importance for the design team who needs to find effective approaches to solving cross domain problems. Often times, the symptom of an issue may be visible in one domain, while the real issue sits in another. The purpose of this article is to review technical design and test challenges associated with the integration of high speed serial links in mobile RF-IC. It will describe how to setup a combination of DigRF protocol analyzer/exerciser with spectrum analyzer and sources to address these challenges.
The “dual Protocol stack"
Like many other serial busses, the DigRF interface specification is described as a stack of protocol layers, each having a specific function and mode of operation. These layers stretch from the digital physical layer to the digital application or software layer. They describe the mode of operation of the bus , the data encoding scheme, the packet structure, the flow control , the error handling mechanism, and more. These layers are referred to as the digital protocol stack. Since DigRF is designed to be used in mobile devices, there is another protocol stack “encapsulated” within the digital interface, which represents the wireless protocol operation of the mobile handset, such as LTE or WiMAX. As with other protocols, this stack definition starts from the wireless physical layer to the wireless application layer. This stack is usually called the wireless protocol stack.
From RF-IC design to mobile system integration, the design team needs to validate the proper operation of each layer of this “dual” protocol stack. From a test point of view, the test environment must provide insight into each layer in both domains.
Below are several examples of new test challenges of the digital protocol domain:
1. Data Encoding Mechanisms
With gigabit serial speeds, the data stream of random 1’s and 0’s is usually encoded into a DC balanced streams of 1s and 0’s, that includes enough transitions to enable clock recovery. These encoding and decoding algorithms operate in real-time and are the first elements of the link to be tested. The test platform must detect coding errors; DC offset errors and missing transitions generated by the DUT. To ensure that this device properly detects errors and recovers from them, the test environment should also generate traffic with data encoding errors.
2. Power Management
Power saving is critical in mobile devices, as this leads to longer battery life. Busses are now designed to operate in multiple high speed and low-power modes, to optimize the performance and power consumption. When no data needs to be sent, the bus enters into sleep mode, and requires very little power. When data needs to be transferred, the bus quickly wakes up, transmits synchronization patterns for clock recovery and starts transferring data. One of the key features of a test environment is to properly stimulate and analyze the power management mechanisms in order to verify that the DUT’s mode transitions are executed according to the specification. During system integration, it might be necessary to verify that the system is “tuned” to save power and only works in high speed when needed. To optimize performance and power, the design team needs a Bus analysis tool to monitor the bus operating mode together with the data transfers, especially when the bus is waking up. In this situation, the lock time of the test equipment is critical, as it needs to capture the data from the embedded clock. A test instrument must have a lock time that is faster than the device under test or it cannot reliably measure the behavior of the device – potentially loosing the first data elements when the bus is waking up. This effect is called the “blind” zone of serial data analyzers.
3. Testing Protocol State Machines with Smart Stimulus
Testing all branches of each protocol state machine is necessary to validate compliance with the specification. To perform this test, the DUT is connected to an active test environment which mimics a peer device. The nature of active test equipment can be divided in two categories: “stateless” and “state-full” test devices. The “stateless” test environment generates stimulus with limited or no knowledge of the protocol state machines of the device under test. It can be compared to a robot programmed to move the pieces in a chess game without knowing the rules of the game.
The “state-full” test environment, or Exerciser, incorporates the bus protocol state machines, and will act much more like a real device. To explain the benefits of an Exerciser, a typical example is the test of a retry sequence. Most digital protocol stacks include a packet resend mechanism. A receiver can require the sender to retransmit a packet if this one has not been received properly the first time. A state-full test platform will recognize the request to resend the packet and will act according to the resend sequence definition. A stateless device will simply ignore the request if it was not expected in the test script.
State-full test environments are critical to test the following bus modes:
• Transitions from sleep to active modes
• Retry sequences
• Flow control mechanisms which require the sender to throttle down or up the traffic
• Emulation of busses dynamic physical characteristics that may change further to protocol events (termination, voltage level).
4. Displaying the Data at the Right Level of Abstraction
In a typical digital protocol test environment, the level of insight needs to go from the bit level to the packet level, as shown in the protocol viewer screenshot below. Each window is dedicated to a certain level of abstraction.
As soon the DigRF link is operating properly, the next phase of the test process consists of moving up on the protocol stack and then starting the tests in the wireless domain. Below are some new test challenges for RF designers.
Migrating from Analog to Digital Test
If the link between the BB-IC and RF-IC is an analog IQ link, the test environment for modulation measurements is based on a signal source and a signal analyzer, combined with vector signal generation and vector signal analysis software. As this link migrates to DigRF, the hardware elements of the test environment are replaced by DigRF exercisers and analyzers. The digitized IQ waveform is inserted or extracted from the payload of DigRF packets.
As designs may include a combination of digital and analog IQ links (legacy inputs), it is important for the test environment to show consistent measurements independently of the link being used. The optimal test architecture includes common vector signal generation and vector signal analysis software integrated into both analog and digital analysis and stimulus hardware, as shown below.
Mixed Traffic Generation and Analysis
The traffic flowing on a DigRF link provides the homogeneous digital IQ waveform information and is used to transport a heterogeneous mix of various traffic pattern. These are the RF-IC initialization commands and control commands that are used to adjust some parameters of the RF-IC device during its operation as well as synchronization of words, and acknowledgment of messages.
From a test stimulus point of view, the challenge consists of defining each pattern and building realistic stimulus that aggregates the various patterns in a main traffic flow. Time determinism is crucial as some patterns must be sent at very precise time intervals. The proper test environment includes “signal insertion” software that works in conjunction with the vector signal generation software and automates the construction of a complete stimulus file from these different elements. If one parameter needs to be changed, the signal insertion software will ensure that all other parameters remain constant.
During the debug and system integration phase, these various traffic patterns influence the overall behavior of the system under test. If one pattern is not setup properly, the entire system may fail. The faulty pattern may be a bad signal, an improper digitization of IQ data, a wrong command, or synchronization patterns that are not sent on time. In order to get insight on the system activity, the DigRF link is the critical visibility point. A key element of the test environment is a DigRF analyzer that performs non intrusive real-time monitoring of the link, extracts digital IQ waveform from other traffic flows and provides cross-domain insight in both wireless and digital domains, as shown below
The adoption of high speed standard interconnects in mobile handsets brings tremendous benefits in terms of performance and power consumption. It is driving major changes in the test methodology from chip turn-on to system integration. True cross-domain test approaches are essential to debug and validate DigRF enabled mobile systems.