JTOL: Jitter Tolerance Testing

This example uses:

Jitter tolerance testing (JTOL) is a critical part of high-speed communication system characterization and validation. It reveals how well the clock and data recovery unit (CDR) of the system performs as both the magnitude and frequency of injected sinusoidal jitter are varied. When the magnitude and frequency of the sinusoidal jitter (SJ) are within the CDR bandwidth, the CDR is able to track the jitter and compensate for it. As the magnitude and frequency of the jitter increases, the CDR loses the ability to track and system performance suffers.

This example illustrates how to run a JTOL test on a SerDes Toolbox™ Simulink® model, provides context for interpreting JTOL results, and explains the JTOL search algorithm used.

Interpreting JTOL results

The utility of JTOL is two-fold:

to prove the compliance to an industry standard, and
to verify that the CDR design has the desired characteristics such as bandwidth.

The figure below illustrates the JTOL as often described in standards, where a corner frequency (f_c) defines the minimum system bandwidth. The JTOL mask separates the passing behavior from the failing behavior. As long as the system meets its performance requirements in the pass region with the higher jitter magnitude, the system is considered JTOL compliant.

For the system designer, the JTOL test is an opportunity to empirically determine the clock recovery bandwidth profile. Clock recovery units track the phase (1st-order CDR loop) and the frequency (2nd-order CDR loop) of the incoming signal. The figure below shows the passing result of a 20 point JTOL test with the blue curve. The bandwidth of this CDR is approximately 4 MHz as indicated by the green arrow. The CDR designer has a delicate job to accomplish: if the bandwidth is too low, then the system cannot respond quickly enough to track natural changes in signal frequency. If the bandwidth is too high, then the system misinterprets uncorrelated noise as information and attempt to track the noise, lowering the total system performance. In the figure, the green dots indicate a simulation, with a given SJ magnitude and frequency injected, where the system performance was adequate. The red dots indicate simulations where the eye was closed or smaller than a target eye opening. As the JTOL algorithm increased the SJ magnitude for each SJ frequency, it stresses the system until its performance drops below the target eye opening. This pass/fail boundary thus provides the JTOL response of the system.

Beyond measuring the bandwidth of the system, a JTOL response can inform the system designer about other characteristics of the CDR. The figure below shows the JTOL responses for a sweep of 2nd order gains. For the 2nd order gain of 2e-11, the JTOL response dips down before settling at a near constant value at higher frequencies. For the 2nd order gain of 2e-13, this dip does not occur. This shows that due to the higher 2nd order gain of 2e-11, the system is too responsive to the SJ jitter and lost performance chasing this noise and amplified the jitter. The system with a 2nd order gain of 2e-13 has a lower bandwidth and a much more consistent behavior. This proves that the higher CDR bandwidth is not always better.

Create System with Second-Order CDR

Create a Simulink model with a second-order CDR from SerDes Toolbox and run a JTOL analysis on the model.

Launch the SerDes Designer App from MATLAB®:

serdesDesigner

Add a CDR block to the receiver.
Export the model to Simulink.

Open the Simulink model.

Comment out the eye scope. When running simulations in parallel, the scope is not needed.
Look under the Rx subsystem and open the CDR block parameters dialog box. Change the CDR Mode to 2nd order.
Open the SerDes IBIS-AMI Manager dialog box and change the Rx Bits to ignore in the Export tab to 10000.
Save the model.

Open the example script simulinkJTOLController.m and review the following parameters at the top. You may need to adjust the numberOfWorkers parameter depending on the capabilities of your computer.

mdl --- This is the filename name of the opened Simulink project. Set to 'bdroot' if you have a single Simulink model open, otherwise specify the exact filename.
sjFrequencyStart --- The lower frequency bound of the JTOL test.
sjFrequencyEnd --- The upper frequency bound of the JTOL test.
nsjFrequencyPoints --- The number of logarithmically spaced frequency points in the test.
numberOfWorkers --- The number of parallel simulations to run in each batch.
maxIteration --- Number of batches allowed before giving up in the search for pass/fail boundary of system.
sjCeiling --- Maximum SJ magnitude to explore for pass/fail boundary of system.
ewTargetPct --- Pass/fail eye width (percentage of symbol time).
ewTargetPctTol --- Convergence tolerance of ewTargetPct (in percentage).
SjTolPct --- SJ tolerance percentage. If two cases, one with performance greater than the ewTargetPct and one less than, have a difference of SjTolPct or less then conclude search.
doDashboard --- View dashboard performance during JTOL.
jtolDashboardFigureNumber --- Figure number of dashboard.
echoRunInfo --- Control to echo out JTOL progress to the Command Window.
saveResultsToMatFile --- Control to save results to .mat file.
saveFileName --- Filename of saved .mat file.

Run the script simulinkJTOLController.m. While the JTOL analysis is running continue reading below to understand how the algorithms used for this JTOL are different from commercial hardware based JTOL algorithms.

JTOL Algorithm

Several key differences exist between the JTOL algorithm used in simulinkJTOLController.m and the ones found in commercial hardware. The first difference is: hardware has a speed advantage that simulation cannot match. For a symbol time of 100ps over a duration of 1 second, the hardware system processes 10 billion symbols. This means that hardware systems can collect data much more quickly to determine the system performance. Simulations can utilize some assumptions to speed up performance but simulations will never come close to the speed of the actual hardware. The second difference is: simulations can be run in parallel. Since simulations can be exactly repeated, even in the presence of 'random' noise, the exact simulation setup can be distributed to many compute units to accelerate the search for the JTOL pass/fail boundary.

High Level Search

For each SJ frequency, the JTOL search algorithm utilizes a basic upward search, varying the SJ magnitude until a failing case is encountered. Then the algorithm switches to a binary-type search, where the interval between passing and failing cases is subdivided to further narrow in on the pass/fail boundary. When the search has converged, the algorithm continues to the next SJ frequency as illustrated below.

Convergence Conditions

There are four possible "convergence" conditions:

Found it. This is the situation where the eye width of a simulation case is within the tolerance of the system performance target as defined by the parameters ewTargetPct and ewTargetPctTol.
Found cliff. This is the situation where two simulation cases, one failing and one passing, are outside the ewTargetPct tolerance, but have a difference in SJ magnitude less than SjTolPct. When such a sharp drop in performance is encountered, the search is halted.
Found quasi-stable behavior. This is the situation where there exists passing and failing simulation cases but where the SJ magnitude for the passing is greater than the SJ magnitude of the failing cases. This situation can occur when the system adaptation loops (CDR, DFE, etc.) are impacted differently by the SJ magnitude such that some cases converge faster than others. Regardless of the specific cause of the behavior, the system is not performing well and the JTOL search can be suspended.
SJ ceiling found. For low frequency SJ, the system could potentially track very high magnitude jitter. By stopping the JTOL search at some maximum value of SJ, the algorithm can proceed to higher (and more interesting) frequencies of SJ.

The script provides a dashboard view of the progress of the JTOL test and included the individual simulation results as it refines the search for the JTOL boundary. The figure below shows such a case where the current frequency search found a case within the performance tolerance and the prior frequency search concluded with a 'found cliff' condition.

Limitations

The SerDes simulation relies on you setting the ignore bits sufficiently high to ensure that any adaptation loops converge and the simulation runs long enough to collect enough information to accurately measure the system eye width. If these settings are not appropriate, then the JTOL analysis itself will be impaired.

This JTOL algorithm includes SJ from the beginning of the simulation and if the system adaptation algorithms (1st-order phase CDR, DFE, etc.) have difficulty converging, then the resulting simulation results will be impacted.

Currently the BaudRateTypeA phase detector in the SerDes Toolbox CDR and DFECDR blocks is not robust enough to tolerate high levels of sinusoidal jitter as required by the JTOL analysis.

Currently only a single frequency and magnitude of SJ can be applied through the SerDes Toolbox stimulus.

Further exploration

Explore what happens to the JTOL response when you:

Change the 2nd order gain.
Change the 1st order gain.
Modify the delay of the 1st order loop "Early/late count threshold" or the delay of the 2nd order loop "Frequency tracking update".
Include equalization.
Different modulations and channel losses.

References

[1] Lee, H. C, An estimation approach to clock and data recovery, PhD dissertation, Stanford University,2007.