Re: [SI-LIST] : Jitter measurement

About this list Date view Thread view Subject view Author view

From: MikonCons@aol.com
Date: Fri Mar 23 2001 - 13:22:29 PST


I may as well add my view for comments, so here goes.

In today's systems, switching voltage regulator modules (VRMs) or switching
DC/DC power modules are typically used. Note that these switching modules may
or may not employ frequency dithering techniques to pass their own EMI
criteria. Unfortunately for higher frequency clocks, buffers (clock
distrubution chips), PLLs, and SERDES systems in general, the instantaneous
voltage perturbations in the delivered DC voltage will cause phase jitter.
So, while your power delivery system may allow you to pass EMC required
levels, your SERDES system may exhibit an unacceptable bit error rate (BER).

I recommend the following technique for resolving jitter problems.

You must first determine the (nominal) switching frequency of the applicable
power delivery module. Measure this item with either a spectrum analyzer or
an oscilloscope. Now, using this knowledge of your power delivery system,
turn your attention to the oscillator.

Using a spectrum analyzer centered at the oscillator frequency, measure the
impact of your power quality at the oscillator output. Repeat this same
measurement for all downstream devices such as buffers, mode-conversion chips
(e.g., TTL-to-PECL) and other in the path to your SERDES driver/transmitter.
Always measure at the output of each device. Use a sufficient frequency span
on the analyzer to observe all sidebands above -60 dBc (i.e., within 60 dB of
the oscillator frequency level). The resulting data will provide a clear
picture as to the power supply noise rejection of each device. Based on this
data, decisions on local supply pin filtering for each device can be made
later, if needed. Note: The deviation frequency of the sidebands is critical
to subsequent measurements.

Now, using the knowledge of the impact(s) of your power delivery system, turn
your attention to direct jitter measurement. The Tektronix system mentioned
by Larry Miller is excellent. Another is the Tektronix 11801x (x = A, B, C or
whatever) with a wide bandwidth sampling head. The mainframe is 50 GHz and
the SD-14 sampling head has 20 GHz bandwidth.

Contrary to some comments made in this thread, use the oscillator output (or
a buffered version if loading is a problem) as the external trigger source
for your jitter test system (real-time or sampled). Using the MINIMUM delay
offered by your test system, record a measurement (typically a histogram with
statistics applied to the resulting data). This gives you a measurement of
the combined effects of the time base jitter, the trigger threshold jitter,
and the oscillator jitter on a cycle-to-cycle level. The jitter should be
reported as very low for this test condition (preferably 12 dB or more below
your allowed limit) as it is indeed a measurement mostly of the test system
itself. If this measurement result is unacceptable (subjectively, anything
over 3 dB below your limit), you are in real trouble, and the selected
oscillator (or your test system) is clearly unacceptable for your design
needs.

Now (as is allowed by the above noted jitter test systems) crank in a time
measurement delay equal to an integral multiple of TWICE the frequency of the
worst sideband deviation frequencies measured with the spectrum analyzer and
retake the jitter measurement. Since this delay is typically equivalent to
many cycles of the clock frequency, yet synchronized with the perturbations
caused by the power delivery system, you are measuring the oscillator jitter
under altered Vcc conditions and the measurement is NOT tracking the
cycle-to-cycle variations of the trigger source. The result is an excellent
indication of the true jitter of the oscillator. You should try different
multiples of the noted delay for a bigger picture of these effects.

At this point, some of you may be thinking that "a downstream PLL (usually in
the SERDES transmitter) effectively applies a zero bandwidth detection to the
reference clock and will filter out these sideband effects." And I'm thinking
"Horse pucky." The problem with the PLLs used in the much higher frequency
SERDES link is their tracking bandwidth typically EXCEEDS the breadth of the
sidebands caused by the switching power supplies. Therefore, one man's noise
is another man's signal! The jitter in the reference clock (and passed
through and added to by any intermediate chips/devices) will be tracked by
the PLL in the SERDES chip and passed on in its output link. If the SERDES
receiver can't tolerate the resulting level of time jitter, your BER
skyrockets.

The above technique will help pinpoint inadequate devices, stimulate you to
add some LOCAL Vcc filtering for devices that exhibit poor power supply
rejection ("poor" is subjectively related to your required performance
specifications), and/or guide you to a better design architecture. One
approach is to use multi-phase VRMs with a ripple frequency well above the
SERDES PLL tracking bandwidth. Another is to use higher frequency (~1 MHz)
VRMs to accomplish the same effect.

Note: Power system delivery noise is only one source of jitter. Pay attention
to adjacent traces for coupled noise and even the loading effects of
"dormant" traces (i.e., those that carry signals out of the frequency range
of interest) as possible contributors to system jitter. There is also
pattern-dependent jitter, which results from crosstalk between separate
traces, and even-odd mode delay variability, etcetera, etcetera.

Comments welcomed.

Mike

Michael L. Conn
Owner/Principal Consultant
Mikon Consulting
(408)727-5697

        *** Serving Your Needs with Technical Excellence ***

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:19 PDT