JTOL: Jitter Tolerance Testing

Summary

Jitter tolerance testing (JTOL) is a critical part of high speed communication system characterization and validation. It reveals how well the system's clock and data recovery unit (CDR) performs as both the magnitude and frequency of injected sinusoidal jitter is varied. When the magnitude and frequency of the sinusoidal jitter (SJ) is 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.

MATLAB version 2024a, the SerDes Toolbox and the Parallel Computing Toolbox are required for this example.

Interpreting JTOL results

The utility of JTOL is two fold, one to prove compliance to an industry standard and two, to verify 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, fc, defines the minimum system bandwidth. The JTOL mask thus separates passing behavior from failing behavior. As long as the system meets its performance requirements in the pass region with the higher jitter magnitude, then the system is 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 won't be able to respond quickly enough to track natural changes in signal frequency and if the bandwidth is too high, then the system will misinterpret uncorrelated noise as information and attempt to track the noise, thus 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 and 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 2^-11, the JTOL response dips down before settling at a near constant value at higher frequencies. For the 2nd order gain of 2^-13, this dip does not occur. This shows that due to the higher 2nd order gain of 2^-11, that 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 2^-13 has a lower bandwidth and a much more consistent behavior. Remember that higher CDR bandwidth is not always better!

Create a system with 2nd order CDR

This section of the example will walk you through creating a SerDes Toolbox Simulink model with a 2nd order CDR and run a JTOL analysis on the model.

Launch the SerDes Designer App from MATLAB:

serdesDesigner

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

In 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 mask. Change the "CDR Mode" to "2nd order".
Open the configuration block, open the SerDes IBIS-AMI Manager and change the Rx "Bits to ignore" to 10000.
Save 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" and 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 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 much more quickly collect data 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 the user setting the ignore bits sufficiently high to ensure that any adaptation loops converge and the simulation duration 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

Lee, H. C. (2007). An estimation approach to clock and data recovery (Doctoral dissertation, Stanford University).