Evaluate reference clocks for serial-data jitter specifications
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 significant challenge occurs because 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 12 kHz to 20 MHz offset frequencies. You can't, however, 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. For example, oscilloscope RJ noise floors are often significantly larger than those of precision oscillators. Therefore, most engineers use spectrum analyzers or dedicated phase-noise analyzers to measure oscillator noise. Unfortunately, these analyzers capture magnitude information but not phase information. Thus, they can't measure total peak-to-peak DJ.
We present here a methodology (Figure 1) that overcomes these challenges. It begins by recognizing that serial-data jitter specifications are based on statistically decomposing total jitter into its components. The measurement methodology we present here 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.
Figure 1. Analyze clock devices to custom or standards-based specifications to calculate their contribution to overall system jitter.
Furthermore, you can automate (and thus minimize) the complexity of analyzing reference clocks to custom or standard specifications for jitter in high-speed SERDES applications. The methodology lets you compare the performance of different clock devices in a system.
Figure 2 diagrams the key steps used by the methodology.
Figure 2. This flow diagram outlines the key steps for analyzing reference clocks.
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. The black curve shown in Figure 3 illustrates a spectrum for falling-only edges of an example 156.25 MHz LVPECL 5x7mm crystal oscillator.
The spurs in Figure 3 represent DJ with the random noise representing RJ. Because high-speed standards separate TJ into RJ and DJ for serial data, we analyze 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 analyze for their intended application).
Figure 3 Reference clock TIE jitter spectrum before and after filtering, showing detected spurs and random noise floor.For example, if an industry standard specifies that serial data must have less than X amount of jitter when analyzed 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 12 MHz and 10 MHz, respectively, to illustrate the filtering effect of a SERDES link on reference clock phase noise. Thus, it applies a 2 MHz first-order band-pass filter, centered at 11 MHz. 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 3 dB frequency of 10 MHz is applied to the jitter." (see 802.3bj-2014 clause 220.127.116.11). The TX bandwidth is SERDES-specific, and 12 MHz 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. The plot represents 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-colored 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 functions 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 illustrates the filtering process for phase noise.
Figure 6. Filtering removes spurs from phase-noise plots.
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.