Zaiq Technologies












 
Optical
Wireless
Broadband
Case Studies
White Papers
Methodology Briefs
Explore our domain capabilities and experience.

Verification of Skew and Jitter Tolerance and Compensation in High-Speed Interfaces

Alex Genusov, Zaiq Technologies, Woburn, MA
Steve Callahan, Zaiq Technologies, Woburn, MA

PDF IconClick Icon for a PDF version of this document.


Introduction
Historically, design engineers implementing high-speed interfaces have met numerous challenges in maintaining interface signal timing relationships and signal quality. Issues such as skew, jitter, crosstalk, and noise have been addressed through a combination of analog circuitry and board/chip physical design rules. Analog circuitry has been used for signal conditioning, filtering, impedance matching, and noise suppression, while physical design rules have targeted skew and crosstalk minimization.

Hybrid parallel-serial interfaces that leverage high-speed serial links have evolved out of the need to scale bus bandwidth, while containing interface electrical and physical design challenges. The transition to serial and parallel-serial interfaces has been accompanied by an increase in design complexity caused by the loss of signal-to-signal timing relationships. The assumption that inter-signal timing relationships are fixed within functional simulations no longer holds. Using hybrid parallel-serial interfaces eliminates the notions of setup, hold, and fixed skew times at the interface, rendering static timing at the interface meaningless.

These factors call for a change in approach to functional verification that now must support uncertainty in edge placement, programmability of signal delay and skew over a wide range of values, variable timing relationships between channels, and the ability to vary timing parameters across and outside of the valid range.

In this paper we propose a common verification approach applicable to a variety of high-speed interfaces and based on reusable verification components that insert and monitor skew and jitter.

De-skewing Techniques
All hybrid parallel-serial interfaces incorporate de-skewing logic that realigns data transmitted over multiple serial lines. At this point it is helpful to review the definitions [1] of the timing variations that are in the focus of this paper.

Skew is the constant portion of the difference in the arrival time between data of any two in band signals. In hybrid parallel-serial interfaces an allowed skew between data in-band signals is usually several unit intervals (UI), e.g. up to 24 UI in InfiniBand.

Jitter is a deviation of the data rate frequency of a digital signal observed as the mis-positioning of the significant edges in a sequence of data bits from their ideal positions. Jitter is characterized by two generalized types of jitter: deterministic or systematic and random or non-systematic jitter. The total jitter is the sum of the peak-to-peak values of deterministic and random jitter.

Deterministic jitter is measured as a peak-to-peak value and adds linearly. The main sources of the deterministic jitter are: inter-symbol interference (ISI), reflection noise, switching noise, cross-talk, power supply noise, and common mode noise. Random jitter is all jitter that is Gaussian in nature.

Figure 1. Eye opening diagram.

Figure 1 shows an eye diagram created by overlapping in time the traces of multiple symbols of the differential signal. The eye opening is the time that the signal can be sampled with fidelity. The height of the eye represents the amplitude of the differential signal that should meet minimum requirement of respective technology. The width of the crossover represents the amount of jitter present in the signal.

Interfaces operating at higher data rates (2.5-3.5Gbps) use clock and data recovery circuits (CDR) for all serial receivers. The use of CDR filters most jitter. Interfaces with data rates below 1Gbps usually do not transfer clock embedded with the data. They tend to have some form of reduced clock transmitted with the data, although it is not necessarily phase aligned (e.g. SPI-4.2). A receiver without CDR is more susceptible to jitter, but proper jitter budgeting guarantees a wide enough eye opening to enable operation with an acceptable bit error rate.

Data is re-timed to the local clock at the receiver after being de-serialized. A re-timing (elastic) buffer absorbs the worst-case frequency mismatch between the receive data (recovered clock) and the local clock resetting the jitter. The data signals are realigned using one of the following techniques.

Static Alignment
In the case of static alignment the receiver latches data at a fixed point in time relative to clock, requiring a more precisely specified sampling window. The static alignment assumes that the skew between data signals can be compensated and the variations in propagation delays of data signals will be contained within the allowed range. The SPI-4.2 and SFI-4 operate in 622-800 Mbps range and require static alignment. An example of high-speed interfaces using static alignment is the Yellowstone interface, proposed by Rambus and targeted to run at 3.2-6.4 Gbps.

Dynamic Alignment, Training
Dynamically aligned interfaces (e.g. SPI-4.2 and SPI-5) perform a "Training" procedure during initialization. During training, a known bit sequence is transmitted across all data lanes. The Training pattern consists of 10 (SPI-4) or 16 (SPI-5) Training Control Words (0FFF hex) and 10 or 16 Training Data Words (F000 hex). A sequence of Training patterns is repeated multiple times and is transmitted during the initialization, after the loss of synchronization, and periodically. Transmitting a square wave with a period sufficiently large to allow detection and compensation for delay variation of multiple UI provides a distinct transition point to simplify delay variation measurements. After deskew, the Training pattern will produce a synchronous wavefront across all bit channels in the bus word.

Character based
Character-based interfaces segment data words into bytes, with each byte sent over a separate channel or bit lane. Interfaces such as XAUI, InfiniBand, and Rapid I/O use 8B/10B encoding to create data symbols, which embed clocking and control information into the data stream. All the bit lanes are realigned in the receiver after detection of a common pattern "comma", so the data can be reassembled without errors. The comma patterns are transmitted with a sufficient frequency in each lane to maintain the alignment.

Dedicated channel
The SFI-5 interface employs a dedicated reference signal, known as the Deskew Channel. The bit-lane Deskew function is shared between the SFI-5 source and sink devices at either end of the Receive and Transmit interfaces. In the source device, data is sampled from each of the 16 data channels sequentially, and copied onto the Deskew Channel. The Deskew Channel is then sent with the 16 data channels to the sink device over the SFI-5 interface. It is the function of the Deskew algorithm operating in the sink device to measure the amount of skew on each data channel, and then to use this skew information to compensate for the amount of skew.

Introducing Variable Signal Timing into the Simulation Environment

Figure 2. Receiver block diagram.

A typical implementation of high-speed receivers includes the following blocks (see Figure 2):

  • A differential I/O buffer (LVDS for SPI-4 and SFI-4, DRSL for Yellowstone, CML for XAUI, InfiniBand, SPI-5, and SFI-5),
  • CDR or bit alignment block,
  • De-serialization or rate reduction block (DDR, QDR, or ODR),
  • Lane alignment or deskew block,
  • Re-timing buffer.

While I/O buffers and CDR are built as hard macros and represented in functional simulation as behavioral models, the rest of the logic is implemented using standard or special (e.g. DDR) cell library elements. Hence, the interface design verification employs both a circuit simulation of I/O, CDR, and transmitter-receiver path and a logic simulation of the rest of the circuit.

Modeling jitter and skew effects is necessary to verify the functionality of the receiver. Even in the case of high performance FPGAs, the existing hard macros (e.g. RocketIO from Xilinx) implement only one type of interface (in the case of RocketIO it is XAUI). Designing a different interface (i.e. SFI-5) requires that protocol specific logic be designed and verified.

Verification of jitter and skew effects requires a "fine-grain" simulation precision, because the clock phase variations are defined with 1% accuracy. However, modifying simulation precision via the timescale directive, substantially increases simulation time. Jitter and skew insertion is usually implemented as an add-on module and can be used by any test. In order to keep simulation time within an acceptable range, exhaustive testing of a high-speed receiver can be run at the block level and only a subset of system tests should run with jitter and skew insertion.

Verification of Deskew and Alignment
Verification of the deskew and alignment logic focuses on the synchronization and alignment state machines. Bit synchronization is tested using various values of sub-UI phase shift. Character synchronization is verified by modifying received bit sequences, along with the interval between comma characters.

Channel alignment is verified by exercising the state machine under various settings of inter-channel skew covering the entire range of allowed values. In the case of training based alignment, training sequences of various lengths are used. Verification of the deskew logic requires injection of skew on each of the channels. The skew value is fully controlled by the test.

A critical part of the verification process is verification of error conditions and error recovery. The deskew logic is tested under loss of synchronization (LOS) and loss of alignment (LOA) conditions. Depending on the interface, a receiver recovers from the LOS or LOA conditions or just reports an error.

Similar to the deskew logic, the receiver jitter compensation mechanism has to be tested. Jitter may affect the bit alignment and re-timing buffer operation. The jitter compensation tests will insert jitter within the allowed range.

Jitter tolerance of the receiver is tested by checking boundary conditions. If excessive jitter causes an error, it has to be recorded and reported. Depending on the alignment mechanism used, a loss of synchronization is detected and a re-alignment process is launched. Typically, synchronization and alignment state machines allow isolated errors to occur and will treat a condition as LOS only after multiple errors have been detected within a specified interval. Similarly, the synchronization is obtained after a specified number of data blocks (i.e. characters or training patterns) were successfully received.

A Reusable Approach to Verification
As common jitter and skew mechanisms exist in all the interfaces described herein, it is possible to use a common solution to verify the interface behavior in the presence of skew and jitter.

While developing tests for several high-speed IO standards we identified and implemented two common modules: skew_jitter_control and skew_jitter_monitor. The former is used to add skew and/or jitter to the data signals before applying them to a DUT (see Figure 3). The latter allows measuring the delay variations between data signals.

An additional module is used to compensate for delay variations and to align the data signals for the transmit section of a DUT, but as the alignment techniques are protocol-specific, this module requires customization. The value of this module in verification is limited because no device under test actually adds skew or jitter in logical simulation. Therefore this module is used to check the skew and jitter insertion capabilities of the verification environment.

The skew_jitter_control is implemented in HDL. It has a variable width bus and is capable of inserting skew (constant delay) and/or jitter (variable delay) on each of the lanes. The skew range is from 0% to N*100% of UI, where N is the maximum allowed delay variation. Jitter range is from 0% to +/-100% of UI. As jitter does not change the signal frequency, it's average has to be 0. The jitter range parameter specifies the maximum value of jitter while the actual value is computed using a periodic jitter source equation (e.g. a sine wave) or is randomly selected from the allowed range taking into account the "average 0" requirement over a specified number of UI.

Figure 3. Skew and jitter insertion.

The skew_jitter_control module is instantiated with the following parameters: bus width, precision, unit interval, maximum jitter, and averaging period (if required). The data inputs to the skew_jitter_control are stored in FIFO buffers provided for each of the bit lanes. A variable FIFO threshold determines a number of stages in the delay line for each bit lane. Differences in FIFO delays are translated into skew for each lane defined with UI granularity. The sub-UI skew and jitter are added to each lane by generating an uncorrelated delayed output clock for each FIFO. The output clock delay is measured in % of the UI. In the Verilog code example (see Figure 4) the skew component is fixed, while the jitter component is randomly selected from the allowed range. The granularity of the output clock delay is determined by the Precision parameter with a typical setting of 1%. The out_clock represents a reference clock without any skew or jitter. In order to support negative jitter values not easily achieved in Verilog with unsigned arithmetic, the nominal output clock delay (after averaging jitter to 0) is equal to (skew %UI + max_jitter). The maximum number of delays is determined by the (UI/Precision) ratio and determines the simulation timescale, affecting the simulation speed.

Figure 4. Jitter insertion code example.

Tests written in C or another high-level language have a full control of the skew_jitter_control by activating the module, specifying timing parameters and setting HDL registers in the module. More specifically, a test initializes and modifies the skew and jitter parameters for each lane. Typically, the same value of the maximum jitter is used for all the lanes, but this is not a requirement.

The skew_jitter_monitor module measures transmission delays for each of the data lanes. The results are presented as maximum and average values accessible from the test. Monitoring skew and jitter values allows analysis of receiver performance and permits prediction of data loss due to timing errors. It also detects out-of-range values and generates warnings and/or error messages.

This approach was used to verify a few interfaces, including SPI-4 (see below), SFI-5 and XAUI. In all cases the skew_jitter_control and skew_jitter_monitor modules were used without modifications. A new, protocol specific, compensation module was created in each case to test the environment in a loopback mode (connecting TX and RX transactors) and support tests development before DUT RTL was available.

Verifying Skew and Jitter Tolerance of a SPI-4.2 Interface
The jitter and skew verification methodology was applied to a SPI-4.2 [2] interface design that was implemented as a soft macro directly interfacing to the I/O buffers. The goal was to verify the dynamic alignment and deskew logic for both the data and status channels.

The SPI-4.2 interface uses a source-synchronous clock at half the data rate. The dynamic alignment requires that the receiver have the capability of centering the data bits relative to clock. A bit alignment circuit utilizes data oversampling by 4 and selects a clock phase which is close to the eye center.

Verification of the bit-alignment circuit has to be performed under realistic conditions, so jitter has to be added to the input data. The standard specifies jitter at the transmitter output as 0.10 UI and 0.24 UI maximum for clock and data/control signals, respectively, but total jitter can approach UI value at receiver inputs, preserving enough eye opening for data sampling.

The SPI-4.2 standard allows relative skew differences on the data and control lines of up to +/-1 UI. The receiver uses a training sequence to deskew the data. Verification of the deskew block requires skew insertion.

We created a verification environment for SPI-4.2 receiver that is depicted in Figure 5. This environment was used to verify the SPI-4.2 receiver functionality using an extensive suite of directed and random tests (written in C). The skew and jitter insertion was used in most of the tests, but only the error tests and tests targeted to exercise the deskew and alignment circuits used jitter and skew values exceeding or on the boundary of the allowed range. Tests fully controlled jitter and skew values and changed them in the process of test execution if necessary to increase the test coverage.

Figure 5. SPI-4.2 verification environment.

The example in Figure 6 shows how the jitter and skew parameters are defined and modified in one of the SPI-4.2 tests. The test sends a number of data frames to the DUT in each iteration and modifies jitter and skew values between iterations. Most of the test parameters can be randomly selected, thus supporting constrained random testing.

Figure 6. SPI-4.2 test code example.

The receiver under test had to realign the data channel or to report an error if it could not obtain synchronization. Multiple errors due to excessive jitter caused a loss of synchronization. Tests varied the length and frequency of training sequences. After the block level verification was completed, most of the tests were reused at the chip level, but only with a limited use of skew and jitter insertion.

We found five design problems in the alignment and deskew logic in the process of SPI-4.2 verification. The most serious one was related to resynchronization of the latched oversampled data to the internal clock. The problem was detected for a particular combination of skew and jitter values that flagged the timing sensitivity of the circuit under test. Another problem was found in the deskew logic operating at a reduced clock rate: the channel alignment logic was skipping one bit under certain conditions. Both these problems, found while running skew and jitter tests, would have made the device using this SPI-4.2 interface design unreliable.

Conclusions
This paper demonstrated a need to perform functional verification of devices implementing high-speed data interfaces. In particular, the deskew logic has to be verified in the presence of skew and jitter. A common approach to the verification of data synchronization and alignment mechanisms found in high-speed interfaces was described including a set of re-usable verification components. A case study of the SPI-4.2 interface verification demonstrated how to apply this common approach to the deskew logic.

As hybrid parallel-serial interfaces enter the mainstream of system design, their verification will combine circuit and logical simulation. Reusable verification components that insert and monitor skew and jitter will simplify the verification process and increase the design coverage.

References
[1] "NCITS TR-25-1999", National Committee for Information Technology Standards, 1999.

[2] "OIF-SPI4-02.0", Optical Internetworking Forum, 2000.

Back To Top

Home | About Us | Solutions | Innovation | Jobs@Zaiq |News | Partners | Site Map | Contact Us




In The News
Read the latest on Zaiq
Apply for a position today!