PLL usage

[Altera_Forum]

Hello all, 

I've noticed that many use PLL on the reference clock input even if they do not need to divide/multiply/shift this clock or do not have external clock to synchronize to the reference frequency.   For example 50 MHz input clk goes to PLL and then 50MHz c0 is used everythere in the design.   What is the purpose of this type of PLL usage?   Thank you in advance.

[Altera_Forum]

The PLL can be used to clean up (de-jitter) the input clock before using it in the system. 

 Jake

[Altera_Forum]

Interesting. I thought PLLs are sensitive to jitter.  

Means that typical PLL is only as good as the reference clock that is supplied to it, because the phase detector seeks to continually adjust the VCO to match the incoming reference. Maybe loop filter with a long time constant can be used to reduce jitter.... And what will be if the PLL has a noisy analog power supply?  Thanks

[Altera_Forum]

Everything you mentioned is true. Altera PLLs have various bandwidth settings. The "PLL usage" report in the Quartus fitter results will tell you specifically what the resulting bandwidth of your PLL is. The PLLs internal to the FPGA will help remove high-frequency jitter.  

 Also, jitter on the input clock will be integrated through the PLL. (So square wave jitter looks like a sawtooth, sawtooth looks like a parabolic, etc.) The integration of random jitter is theoretically 0. It can be a lot of fun to inject jitter onto the input clock and measure the jitter on the PLL output clock.  The PLLs can also clean up the duty cycle on a clock.   You are also correct that noise on the PLL analog supply can translate to jitter on the clock outputs. It can also be a lot of fun to inject noise on the analog supply and watch the resulting jitter on the output clock.  Jake

[Altera_Forum]

Hi, 

 You could also use the PLL to "free-run" if you suddenly loose the input clock. This might allow your design enough time to enter a safe state. A sudden loss of the clock might leave your design in an unsafe state if it is not accompanied by an asynchronous reset.   Regards, Niki

[Altera_Forum]

Cool. 

Jake, what type of PLL (options in the altpll megawizard) should I specify to guarantee that my PLL will remove a jitter?   Niki, if the registers in my design all have an asynchronous reset, should i still use a PLL to enter a safe state?   Thak you for your help.

[Altera_Forum]

I'm new member, just test my account!

[Altera_Forum]

Guarantee huh ... no guarantees. The effectiveness of the PLL at removing jitter depends entirely on the type of jitter in the signal. Obviously the simple answer is to set the bandwidth of the PLL as low as possible.  

 Your original question was why designs use a PLL to produce a clock of the same frequency as the input clock. The simple answer is that a PLL can clean up the clock (jitter, duty cycle, etc.). Some clock outputs from crystal oscillators can look kind of trashy. Doesn't hurt to run it through a PLL.  Jake

[Altera_Forum]

Jake, all is clear. 

Thank you very much.

[Altera_Forum]

the PLL helps balance setup and hold timing to meet i/o constraints which explains using it with a 1:1 ratio: 

 http://www.altera.com/literature/wp/wp_stxtco.pdf

[Altera_Forum]

As a follow up to this discussion on the PLL being possibly used to clean up input clock jitter, does anyone know if Timequest takes this into account when reporting the resulting clock uncertainty? 

 I've tried applying the set_clock_uncertainty command to the PLL input clock but when I look at the timequest report, this uncertainty appears to be directly transferred to the latch clock (PLL output) uncertainty in the data required path of a setup/hold analysis. This was somewhat unexpected, but I'm wondering if anyone else has experience with this.  Raphael

[Altera_Forum]

Clock uncertainty is not the same as jitter. For example, if you have an input clock that you expect to be 100MHz, is that input clock really 100MHz or could it possibly be 100.0001MHz or perhaps 99.999MHz. That is clock uncertainty. By giving timequest a clock uncertainty constraint, you are telling it to perform timing analysis at the extreme ends of your uncertainty. 

 And as expected, this uncertainty will apply directly to the PLL outputs.  Jake

[Altera_Forum]

Clock uncertainty is as a time domain parameter in the Quartus vocabulary, jitter is actually a part of it. 

 I didn't take part in the previous discussion und don't want to bring it up again. But I don't read much jitter removing capability from the PLL specifications. Simplified, they say, if your input clock has a jitter, use a fast bandwidth setting to allow the PLL to follow it. Consequently, the timing analysis adds input clock jitter to the overall uncertainty.

[Altera_Forum]

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

[Altera_Forum]

As another note, the minimum closed-loop bandwidth for an enhanced PLL in Stratix II GX is 130kHz. So if you manage to configure your PLL with a bandwidth of 130kHz, you will filter out a great deal of jitter (at frequencies higher than 130kHz) from the input clock. However, doing so also makes the PLL more susceptible to jitter induced by noise from the PLL's VCO which includes noise on the PLL's power supply. 

 Jake

[Altera_Forum]

Also note that Altera (along with many other chip vendors) shows all kinds of ferite beads, capacitors and other funky power supply "filters" for the PLL supply pins in app notes and user guides. But... never really specify any special requirements for these supply pins :-) 

 What kind of engineering is that?

[Altera_Forum]

You're absolutely correct when demanding a detailed analysis. Basically, it's necessary to decribe jitter as parameter that depends on measurement bandwidth respectively period. A phase noise spectrum (frequency domain) or jitter versus run length (time domain) are suitable to represent it completely. 

 Altera device manuals also mention the ability of a PLL, to reduce jitter, e.g. from Stratix IV PLL chapter:   --- Quote Start ---  A low-bandwidth PLL filters out reference clock jitter but increases lock time.   --- Quote End ---    Other documentation parts, e.g. in the PLL chaining chapter, give the impression, that feeding a clock to a PLL would only increase  the jitter until you finally cause unlock. But they don't provide a detailed analysis. In the switching specifications, only maximum  cycle-to-cycle jitter is given.   I'm doing a lot of PLL chaining in designs and didn't yet experience problems, also any source synchronous serial link typically  does a double chaining: Master PLL to TX PLL, TX PLL to RX PLL.  But whatever the PLL behaviour in this designs may be (it's rather reliable, I think), it seems clear that the timing analysis can't consider the actual dynamic, bandwidth dependend jitter. It can just add up uncertainties.  P.S.: I don't agree with pcie-rat's comment on Altera's layout recommendations and reference circuits. You can see, that Altera has been playing around with suggested PLL supplies during the last years. But it's really a complex matter. In my opinion you must acquire an own understanding of good design practice. Altera has given valuable help in this regard, and they, first of all, have improved the PLL hardware by supplementing analog regulators.  I have seen other manufacturer's reference circuits (e.g. in the RF field) with part numbers and good sounding suggestions: copy the reference circuit and everything is perfect. You may want to believe it, until you ever measured their development kits ...

[Altera_Forum]

Hi! 

 I have the following problem: I'm using a PLL of a StratixEP1S20 chip. I want to connect a PLL input to the output of an internal logic ( Clock Mux) and I get the following error message: ------------------------ Error: inclk0 port of PLL "Clocks_Delay:inst1|altpll0:inst9|altpll:altpll_component|pll" must be driven by a non-inverted input pin or, in a fast PLL, the output of a PLL Info: Input port INCLK[0] of node "inst1|altpll0:inst9|altpll:altpll_component|pll" is driven by Clock_MUX:inst|inst24 which is COMBOUT output port of Logic cell type node Clock_MUX:inst|inst24 --------------------   Is it ONLY possible to use PLL if the input signal is an external clock ? any comments!   Kind regards JJ

[Altera_Forum]

You cannot drive the PLL from internally generated logic. It can be driven from a global route through an input pin. It can also be driven from the output of another PLL. 

 The only way you might be able to fake it out is if you have a feedback path on the board so you can drive a clock out of the FPGA and into a suitable clock pin.  What is it you're trying to accomplish by switching between the two clocks? Maybe there is another approach.  Jake

[Altera_Forum]

Many thanks Jake, 

in fact I have 4 sources of clock ! and it's the reason why I have a such configuration. Another question about PLL: Is it possible to have a programmable delay in the feeback ( i.e. modif the phase according external data) ?   Kind regards JJ

[Altera_Forum]

--- Quote Start ---  Hi,   You could also use the PLL to "free-run" if you suddenly loose the input clock. This might allow your design enough time to enter a safe state. A sudden loss of the clock might leave your design in an unsafe state if it is not accompanied by an asynchronous reset.   Regards, Niki  --- Quote End ---    Niki,  How to set the PLL in free run mode? Or it execute automatically?  thanks