How do I estimate the output jitter of a clock tree consisting of a clock oscillator followed by a clock buffer?

The components have the following jitter characteristics:

  • The clock oscillator has a total jitter of J1 = 25.6 ps (peak-to-peak), consisting of 1.3 ps RMS of random jitter and 6.7 ps P-P of deterministic jitter
  • The clock buffer has an additive jitter of J2 = 350 fs RMS
  • \$\begingroup\$ Is the entire clock tree comprised of just one clock_buffer? What is the power-supply-rejection of that clock_buffer? how much ripple (60Hz, or switchReg power) on the VDD? \$\endgroup\$ Apr 28, 2017 at 17:42
  • \$\begingroup\$ @analogsystemsrf yes, it consists of only those two discrete components \$\endgroup\$
    – geschema
    Apr 29, 2017 at 8:25

2 Answers 2


In general you cannot add RMS values, but you can add the squares of the values. If you are familiar with standard deviation and variance in statistics, it is the same concept.

Calculating the resulting random RMS jitter (note, this is neglecting the deterministic contributor):

$$ \sqrt{(1.3 \text{ ps rms})^2 + (0.35 \text{ ps rms})^2} = 1.346 \text{ ps rms}$$

Peak-to-peak is somewhat more complicated. Statistically, if you run your test for long enough, the peak-to-peak jitter is unbounded. Are there any details in the oscillator datasheet about exactly how they define peak-to-peak jitter? Or perhaps more importantly, what is the requirement that you are trying to meet?

Update 1 May 2017:

The comments here have inspired me to think about this a little more. Even without the datasheet for the clock oscillator, if we assume that they used some linear scaling factor to convert between pk-pk and rms jitter, then we should be able to figure out what that factor is. The spec gives

$$25.6\text{ ps p-p} = 1.3\text{ ps rms} + 6.7\text{ ps p-p}$$

Assuming that they scaled their rms value to get a p-p value, and using the formula to sum rms values:

$$\frac{25.6}{\alpha} = \sqrt{1.3^2 +\left(\frac{6.7}{\alpha}\right)^2} \implies \alpha = 19.006 $$

So they dividied their peak to peak jitter components by 19 to convert it to rms jitter when they combined their terms. Thus, we can use the same value to convert their resulting J1 value back to rms, getting \$1.347\text{ ps rms}\$.

Now that we know the rms jitter of the oscillator, we can more accurately combine it with the buffer:

$$ \sqrt{(1.347 \text{ ps rms})^2 + (0.35 \text{ ps rms})^2} = 1.392 \text{ ps rms}$$

To convert that to pk-pk, you can use a calculator like this: https://www.jitterlabs.com/support/calculators/rms-peak-peak-calculator based on your signal frequency and acceptable error rate. I plugged in some values and you are definitely below 40 ps pk-pk, assuming there are no other error sources such as from the power supply, as mentioned in another answer.

  • \$\begingroup\$ Thanks for your answer. The requirement I'm trying to meet is 40 ps P-P at the output of the clock tree. \$\endgroup\$
    – geschema
    Apr 28, 2017 at 15:20
  • \$\begingroup\$ I don't think you can say the deterministic jitter is dominant here. In my area, we typically multiply RJ rms by 14 to get equivalent peak-peak jitter; that would make RJ 3x DJ here. Even if you use a much more liberal 6x multiplier (allowing 1 excursion beyond the limit per ~1 million cycles) the RJ and DJ are approximately equal in magnitude. \$\endgroup\$
    – The Photon
    Apr 28, 2017 at 15:30
  • \$\begingroup\$ @ThePhoton - Good point. I didn't realize the multiplier was that high (I'm not very familiar with peak-peak jitter) \$\endgroup\$
    – Justin
    Apr 28, 2017 at 19:03
  • \$\begingroup\$ I suspect the appropriate multiplier varies by data rate. 1 in 100 million isn't a whole lot of errors at 100 kbps. But at 25 Gbps it's 250 errors per second. \$\endgroup\$
    – The Photon
    Apr 28, 2017 at 20:12
  • \$\begingroup\$ @Justin in order to include the deterministic jitter, would it be acceptable to convert J1 (25.6 ps P-P) to RMS by dividing it by 14 (which yields 1.83 ps RMS) and to use that value instead of 1.3 ps in the expression you provided? \$\endgroup\$
    – geschema
    Apr 29, 2017 at 8:24

As you figured out, the clock data sheet references dual-Dirac decomposition which estimates the total jitter as the linear sum of DJ components plus root-sum square of RJ components. To convert RJ in RMS to peak-peak, you need to multiply by a crest factor. A crest factor of approximately 14 is very common in high-speed digital serial-data standards (Ethernet, etc.) for bit error rates of 1e-12.

Thus, the total jitter output by the oscillator plus buffer can be estimated as,

TJ=6.7+14*(1.3^2+0.35^2) ps peak-peak at BER=1e-12

There are several assumptions here:

  • The buffer does not pass the input clock through a PLL. If it does, the PLL will filter some jitter away but also introduce it's own jitter. This is frequency dependent and you'll need more accurate analysis than the data sheet values can provide.

  • You're working with high-speed digital serial communication systems targeting a BER of 1e-12. The jitter here is what the equipment mfgrs (Keysight, Tek, etc.) refer to as time-interval error (e.g. TIE). This captures the variation of an edge in a signal. This is as opposed to period jitter, and other types of jitter. So if your application is not serial data, you'll want to do another analysis. For example, if your clock is driving a latch for digital logic, then you'd need to compute setup and hold times and period jitter must be used (with a different crest factor), etc.

  • The noise and application are broadband. Whatever system your clock is driving has a bandwidth associated with it. The frequency spectrum of the jitter (or phase noise) must be filtered to emulate this system, and extract only that jitter observed by the system. The simple equation above doesn't comprehend that, and may be viewed as pessimistic.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.