Define serial-data jitter spec with clock analysis

Article By : Gary Giust, Jayaprakash Balachandran, Bidyut Sen

You can automate the complexity of analysing reference clocks to custom or standard specifications to calculate their contribution to overall system jitter.

Almost all high-speed SERDES designs require reference clocks that you must properly select to ensure that your links meet jitter requirements of high-speed serial-data communication standards. Unfortunately, most of these standards don't have explicit jitter requirements for reference clocks. Instead, clock jitter is acknowledged to occupy some portion of the specification for jitter in data, enabling SERDES adopters to select a clock device that fits their budget. While that freedom provides you with a wide range of device options, it also presents several challenges.

One of the challenges is there's no universal measurement that establishes success for reference clocks. Thus, you must develop your own analyses. Clock datasheets are a logical place to start for they typically report an integrated phase noise value over 12kHz to 20MHz offset frequencies. You can't use this generic number to predict in-system performance. Moreover, the generic number ignores spurious noise, which is a source of deterministic jitter (DJ) that is widely included in serial-data jitter specifications.

Requesting samples and evaluating them in the lab seems the next logical step. Indeed, the high-speed serial-data industry has developed technologies to decompose a signal's total jitter (TJ) into various sub-components of jitter, including random jitter (RJ), DJ, duty-cycle dependent jitter (DCDJ), data-dependent jitter (DDJ) and so on. In fact, standards adopt these measures to define jitter specifications for serial data.

Although such measurement technologies work well for high-speed data, they fall short for precision clock sources. Therefore, most engineers use spectrum analysers or dedicated phase-noise analysers to measure oscillator noise. Unfortunately, these analysers capture magnitude information but not phase information. Thus, they can't measure total peak-to-peak DJ.

 

Figure 1: You can automate the complexity of analysing reference clocks to custom or standard specifications to calculate their contribution to overall system jitter. The methodology lets you compare the performance of different clock devices in a system.
 

A methodology for overcoming said challenges begins by recognising that serial-data jitter specifications are based on statistically decomposing total jitter into its components. The measurement methodology we present lets you quantify clock jitter similarly. Using this method, anyone can determine, by inspection, how much of the serial-data specification is consumed by a reference clock.

Intro to measurement methodology

 

Figure 2: Flowchart diagram of the key steps in reference clock analysis.
 

First, we acquire a clock signal using a deep-memory real-time oscilloscope. Each rising and falling edge is evaluated for time-interval error (TIE) jitter. To compute TIE jitter, we acquire a voltage waveform, then perform post-processing outside the instrument using custom code. You can purchase jitter-analysis software sold by instrument manufacturers to make the computation. An edge polarity is selected as rising edges, falling edges or all edges. Most high-speed SERDES applications use either rising-only or falling-only edges to avoid adding DCDJ from the reference clock, which we'll adopt in our discussion as well. The acquired data is then used to compute a TIE jitter time-trend. We then apply an FFT to obtain a jitter spectrum. From that, we detect spurious noise sources (i.e. spurs) in the spectrum, and spurs generated internally by the oscilloscope are detected and removed.

 

Figure 3: Reference clock TIE jitter spectrum before and after filtering: The black curve illustrates a spectrum for falling-only edges of an example 156.25MHz LVPECL 5 x 7mm crystal oscillator. The spurs represent DJ with the random noise representing RJ.
 

Because high-speed standards separate TJ into RJ and DJ for serial data, we analyse clock signals similarly. Otherwise, we can't compute the margin that a clock device consumes to the specified limits for serial-data jitter, which is the goal (i.e. to make clock devices much easier to analyse for their intended application).

For example, if an industry standard specifies that serial data must have less than X amount of jitter when analysed using procedure A, we use procedure A for the clock as well and report that, for example, the clock consumes 30% of X. Evaluating reference clocks this way is, therefore, intuitive to understand. Clock datasheets might use a different procedure (call it procedure B) to report Y amount of jitter and no comparison can be made. That results in each designer having to embark on a unique analysis for every design, which requires a lot more skill, data and time to perform.

We then filter the jitter spectrum as required by the application and/or industry standard in question. In high-speed SERDES applications, the jitter filter typically comprises a low-pass function followed by a high-pass function representing transmit (TX) PLL and receive (RX) observed jitter-transfer functions, respectively.

The red curve shown in Fig. 3 arbitrarily applies first-order low-pass (e.g. TX) and high-pass (e.g. RX) filters with cutoffs of 12MHz and 10MHz, respectively, to illustrate the filtering effect of a SERDES link on reference clock phase noise. Thus, it applies a 2MHz first-order band-pass filter, centred at 11MHz. That lets you extract only the jitter observed by the system. The RX bandwidth is called out by the standard: "The effect of a single-pole high-pass filter with a 3dB frequency of 10MHz is applied to the jitter." (see 802.3bj-2014 clause 92.8.3.8). The TX bandwidth is SERDES-specific and 12MHz is simply used for example here.

Next, we separate spurious tones in the spectrum from the random noise floor. We then apply an inverse FFT to the spur-only spectrum to obtain a DJ time trend, as shown in Figure 4.

 

Figure 4: A plot showing the TIE DJ time trend of the filtered clock signal from Figure 3.
 

The DJ time trend is then used to derive a distribution for DJ, as shown in Figure 5a. The red-coloured data in Figs. 4 and 5 are related to each other; they both represent DJ in the clock. Fig. 4 is a time-trend for DJ while Fig. 5 is the distribution of this time-trend data.

 

Figure 5: Distribution for (a) DJ and (b) RJ and TJ.
 

Separately, we measure clock signal for phase noise with spurs omitted. The phase-noise data is then filtered as described above and integrated to obtain random phase jitter in seconds RMS.

 

Figure 6: Illustration of the filtering process for phase noise.
 

We then use the phase jitter value to create a Gaussian model of RJ in the clock signal. Finally, we convolve the RJ and DJ distributions to obtain a TJ distribution, as shown in Figure 5b. These three distributions are then used to quantify jitter. For example, a BER bathtub curve can be computed to evaluate TJ at a given BER, and estimate dual-Dirac RJ and DJ, considering only the reference clock jitter.

Reference clock jitter can also be expressed in terms of margin to the serial-data jitter requirements specified by a standard, as shown in the last step of Fig 2. Additionally, the clock's dual-Dirac jitter may be summed with similar values from other elements in the system for jitter budgeting or troubleshooting. In this case, dual-Dirac RJ components add in root-sum-square (RSS) fashion, and dual-Dirac DJ components add linearly. RJ adds as RSS to account for the statistical unlikelihood that different components each contribute their worst-case jitter (which is deep in a Gaussian tail region) simultaneously. Likewise, DJ adds linearly because the worst-case jitter from different components occurs much more frequently and thus, they're more likely to occur simultaneously.

The result is a methodology that expresses clock jitter using the same terminology found in high-speed serial-data standards. This greatly simplifies evaluating reference clocks to high-speed serial-data standards lacking explicit clock-jitter specifications, and based on jitter decomposition. This includes markets for Ethernet, Fibre Channel, CEI, SFP+, XFP, USB, JESD204B, and many more.

 
Next:Test serial-data clock jitter via LCC »