PLL usage

I appologize. FvM is correct. The definition given by Altera indicates that uncertainty truly refers to the cycle-cycle clock uncertainty.

So I would like to open a discussion. Feel free to correct my thinking.

It is interesting that Timequest applies the uncertainty value directly to the PLL output. Uncertainty of this frequency should be outside the closed-loop bandwidth of the PLL.

For example, assume a clock of 100MHz. Let's say the first rising edge occurs at 0ns, the next rising edge occurs at 9.9ns and the third rising edge occurs at 20.1ns and assume the pattern continues. The clock therefore has a peak-peak jitter of 0.02UI or 200ps. The frequency of that jitter is 50MHz. Or in other words, if you were to examine the jitter on that clock using an oscilloscope, you would see 200ps of jitter at 50MHz. (please feel free to correct me if my numbers are wrong).

Now take for example a Stratix II GX device (I can't find a spec for Cyclone III). The maximum closed-loop bandwidth of an enhanced PLL in Stratix II GX is 16.9MHz. Meaning that best case, the PLL cannot track changes in the clock that occur at a rate faster than 16.9 MHz. That jitter from the input clock is essentially filtered out by the PLL. This is simply due to the nature of the control loop within the PLL.

This is where my original statement comes from. The PLL is limited in its ability to pass jitter from the input to the output by its closed-loop bandwidth.

Now the reality is that some of that jitter will carry through to the output clock. However, the calculation of how much jitter is a difficult calculation. I assume this is why they simply carry the uncertainty constraint over to the PLL output. It's too difficult to calculate what the actual clock uncertainty would be given the PLL bandwidth.

Ideas from anyone? I welcome any corrections in my understanding.

Jake