PLL usage

--- Quote Start ---

How to set the PLL in free run mode?

--- Quote End ---

As far as I know, the PLL behaviour during and after loss of lock is unspecified. I observed, that a PLL without input clock is often working at a low frequency (below specified range), if you don't enable automatic reset. But I fear, you can't rely on it. Particularly, you can't rule out a temporary move to high frequencies, that can cause erratic design behaviour due to timing violations.

--- 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

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

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

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

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 ...

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?

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

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

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.