This article is part of a series:
- Jitter and Phase Noise
- Jitter Characterization
- Jitter Creation
- Jitter Capture
- Jitter Tracking
- Jitter Reference Clock Settings
PLL Response Time
A PLL is a tracking device. When its input changes, the PLL responds, but not instantly. The time it takes for a PLL to respond to a step change in its input is called the response time. From the response time you can derive the PLL tracking bandwidth.
Relation of response time to tracking bandwidth.
The response time and tracking bandwidth for a particular PLL vary inversely with each other according to the internal architecture of the PLL. Even if you vary the PLL parameters, the product of its response time and tracking bandwidth remains constant.
The response time of a PLL circuit is usually specified in terms of the PLL response to a sudden step change in input (the so-called step response). The step-response speed may be measured in various ways. The tables below specify the zero to 63% response, the 20-80 percent response, and the 10-90 percent response.
The tracking bandwidth is usually specified in cycles per second (Hertz). In ordinary PLL circuits the response is a low-pass filter function. That is, the PLL tracks very slow events almost perfectly, but beyond a certain point it cannot track fast-moving events. The cutoff frequency between what the PLL can and cannot track is given in the table below as the point where the response is down 3 dB from nominal, or 6 dB from nominal, or, in the middle column, the rms bandwidth. That number plays a role in calculating the PLL's output response when presented with a flood of white Gaussian jitter at its input. The rms bandwidth for many filter types is wider than the 3dB bandwidth, but not as wide as the 6dB bandwidth.
Very simple control systems work like a single-pole filter. Most PLL circuits are more sophisticated; they have at least a two-pole response. The following tables show the product of various measures of response time and bandwidth.
From these relations you may compute rise time from tracking bandwidth or vice-versa. For example, assuming a two-pole critically-damped PLL, the product of the 10 to 90 percent step response and the 3dB tracking bandwidth equals (0.377853). From that fact derive these relations:
F[3dB] = 0.377853 / T[10-90]
T[10-90] = 0.377853 / F[3dB]
If you simply remember that the 3dB attenuation point for a low-pass filter equals about 1/3 divided by its 10-90% rise time you'll come close to the right answer for many popular PLL types.
A concrete example
Let's make some jitter. The circuit in Figure 1 creates a wonderfully jittery clock. The clock source is a low-noise RF oscillator. The RF oscillator pumps out a 100-MHz sine wave at +12 dBm. On top of that sine wave I superimpose a phase-modulating signal. The phase-modulating signal alternately raises and lowers the DC bias level of the RF sine wave, changing slightly the position in time of its zero crossings. The pulse generator, used in GATE mode, squares up that signal creating a digital clock output with time-modulated phase.
I'll use the LeCroy SDA 6020 to simulate the clock-recovery PLL in a digital receiver. By adjusting the PLL tracking bandwidth and damping factor I can experiment with different PLL architectures. I'll look to see what adjustments you can make in a PLL architecture that might ameliorate the effect of jitter in this signal.
Attenuation of wander
I produced the four jitter tracks in Figure 2 using the TIE@Level function of my LeCroy scope. Each track shows the difference, at each moment, between the incoming signal timing and the local internal reference clock timing. That difference represents the potential misalignment that might occur in your circuit between recently incoming data edges and the PLL internal reference clock. In other words, the tracks show how far off-center the reference clock will fall within your data window. They are directly related to the likelihood of data errors.
The four traces each use a different PLL reference-clock strategy. The topmost signal uses the "PLL_OFF" method described in "Jitter Reference Clock Settings". Since we are dealing with a repetitive waveform, I can use the PLL_OFF method to display the absolute phase track of the modulated waveform.
The other three traces engage PLL tracking functions with various different PLL tracking bandwidths. Note that all choices display the same peak jitter.
They are all the same because the incoming signal in Figure 2 exhibits a sudden (and violent) phase-modulation. The phase-modulation rise and fall time for this figure is set to 10 ns (1 clock cycle). That fast-edged event, because it occurs instantly from one clock edge to the next, always appears in the detected jitter track regardless what tracking bandwidth you use. No PLL clock-recovery architecture can withstand such events. The recovered clock simply cannot respond quickly enough to prevent sudden events like this, if they are large enough, causing data errors.
Figure 3 uses the same four PLL setups, but in this case I set the phase-modulation rise and fall time to a more languorous rate of 100 ns. It now takes 10 clock cycles for the received clock phase to slew from one extreme to the other.
Just that small change makes a marked difference in the waveforms, especially the bottommost case. The response at bottom, instead of rising to 100% peak amplitude, begins to fall off before the waveform has a chance to rise to its full value. That happens because the PLL response in this case is set so fast that the PLL begins to track each phase excursion as it happens.
These two figures illustrate a general principle of PLL behavior. A tracking PLL will not follow incoming phase events faster than the response time of the PLL. It will, however, follow slowly-moving timing variations (wander).
In the context of a serial data recovery system, that behavior suggests that to minimize jitter you should select the highest PLL tracking bandwidth practicable. That keeps the recovered clock phase close to the incoming datastream phase. If the phase of the incoming stream suddenly shifts, the PLL responds quickly, getting back to the correct phase relationship in mininum time.
Choose a PLL response time that fits your application
If you are implementing a standard, then by all means use that standard's stipulated PLL parameters. If, on the other hand, you are designing a new system, you have a choice of PLL strategies. Here are two of the most commonly encountered PLL applications:
Jitter cleanup. Given a jittery reference clock, you may wish to clean it up, removing the jitter. That is achieved with a very low PLL tracking bandwidth. Because the PLL responds slowly, the output timing can never vary quickly, thus limiting the output timing variations.
The limit as to how low you can set the tracking bandwidth depends on the ability of your phase detector to properly ascertain phase misalignments greater than half a UI. That problem arises because even small frequency offsets, held for long periods of time, can accumulate phase discrepancies of arbitrary size. The phase accumulation problem is overcome using a divide-and-multiply PLL architecture, where both the input signal and the PLL output are divided by some large ratio. The phase detector then looks only at the divided signals. This technique extends the range of potential misalignment by the divider ratio, permitting the PLL to smoothly "ride through" long periods of incoming timing variation that may exceed half a UI.
Serial data recovery. A serial data recovery application requires a low bit error rate. That is achieved with the highest PLL tracking bandwidth practicable. A fast-reacting PLL responds quickly, tracking most variations in the incoming data timing, minimizing any potential misalignment between recently incoming data edges and the PLL internal reference clock.
The limit as to how high you can push your tracking bandwidth is set mostly by the transition density of your data code. If the data signal incorporates long runs of ones and zeros, your PLL must be able to "ride through" those periods without running off the rails and losing track of the data phase. To keep the PLL stable one usually makes the PLL response time sluggish, slow enough to exceed the maximal-length run of ones or zeros. Long runs of ones or zeros therefore place a constraint on your choice of PLL tracking bandwidth. Good data codes (like 8B10B) guarantee a very high density of transitions, eliminating the constraint. That makes it possible to crank the PLL tracking bandwidth up closer to the bit rate, guaranteeing better jitter performance and fewer data errors.
Dr. Howard Johnson