PLL and DLL

Hi,

What is the need for PLL / DLL ?

what kind of system requires this? When it is required?

Regards, Muthu

Reply to
Muthu
Loading thread data ...

The newer families of FPGAs run on frequencies where

1) it is hard to get oscillators 2) you wouldn't want these oscillators on your board for EMC reasons 3) the chips are too large to run on a single clock net

PLLs allow to step the frequency up from a usual clock.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

I think there is more to PLLs, DLLs and Digital Clock Managers (DCMs in Virtex/Spartan3)

Fist the obvious: They can multiply the incoming frequency, so you do not need such a fast xtal. They can also divide the frequency.They canthus generate several internal frequencies from one xtal input.

Now the more exciting: They can completely eliminate the on-chip clock delay, which is important on large chips. (They cannot eliminate clock skew. that is left to the chip dsigner to minimize)

PLLs and also the Spartan3 DCM can reduce incoming jitter.

Virtex2/Spartan3 DCMs can simultaneously multiply and divide the clock frequency by any integer up to 32, thus generating any one of a very large number of derived frequencies.

DCMs can generate a phase-offset of n/256 of the clock period, where n can be any number up to 255. This allows phase manipulation down to 50 picosecond incrments. The applications of fixed or adaptive phase control are endless...

Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Hi Muthu,

PLLs and DLLs are used to generate clocks of different frequencies by making use of a single input clock. An important characteristic of PLL and DLL output clocks is that they are 'locked' to the input clock.

If the clocks are used to clock data through an FPGA, a PLL or DLL will generate an output clock that is a precisely-specified multiple or fraction of the input clock. That is, a PLL or DLL should prevent "clock creep", where data-clocking rates vary ever-so-slightly so that your data processing logic experiences long-term problems with buffer overflows or under-runs.

I hope I will be corrected if I am wrong about DLLs, but DLLs will clean up a certain amount of input clock 'jitter' (also called phase-noise). If the relationship between the input frequency and the output frequency is divisible by a power of two, the DLL's output clock should have very little jitter. If the relationship is more arbitrary, the output clock will have a certain amount of jitter. DLL's are great for doubling, quadrupling, or halving input clock rates. They aren't so great if you want a clock division of, say, seven-elevenths, or a clock multiplication of 19.842.

A PLL/VCO combination is generally (I believe) less tolerant of input clock jitter, but can produce a more arbitrary clock division or multiplication within a reduce operating range, while minimizing output clock jitter.

For example, if you want your FPGA logic to perform a rate conversion of digital audio data from 44.1 KSPS to 32 KSPS while observing jitter restrictions imposed by a standard like AES3, you would likely use a PLL/VCO to perform the clock conversion.

If, in this example, jitter was not a concern, a DLL could be used to perform the conversion.

If you want parts of your FPGA logic to, say, operate at twice or 4x the input clock rate, you could use a DLL to generate a logic clock that is a multiple of your input clock rate.

Best regards, Dwayne Surdu-Miller

Reply to
Dwayne Surdu-Miller

Hi Dwayne,

The input jitter filtering you describe above is backwards. PLLs filter input jitter -- high-frequency jitter is attentuated, although sufficiently low frequency input jitter is passed through. DLLs pass input jitter straight through. It's a fundamental property of how they work -- PLLs are synthesizing the clock from an oscillator that won't drift fast enough to follow high-frequency input jitter. DLLs are constructing a clock that is a delayed / digitally multiplied / divided version of the input clock. So all input jitter gets copied to the output.

Regards,

Vaughn Altera

Reply to
Vaughn Betz

DLLs have advantages over PLLs, and PLLs have advantages over DLLs. It is unfortunate that the battle betwen Xilinx and Altera has polarized this more subtle topic. But things are not all black and white: I managed to feed 6 ns jitter into a Xilinx DCM and see 140 picoseconds jitter on its output. Took some secret sauce, though. Stay tuned. Peter Alfke

Reply to
Peter Alfke

All,

Xilinx uses PLLs (in the MGTs).

There is no battle here. DLLs are good, PLLs are good. Choose what you need.

Aust> DLLs have advantages over PLLs, and PLLs have advantages over DLLs. It is

Reply to
Austin Lesea

Briefly, how do the specialized jitter reduction PLLs from ICS and others achieve their performance? Just wondering.

Reply to
Tim

You start with a high-Q voltage-controlled oscillator. LC is much better than RC, but LC limits the range for pulling the frequency significantly (square root of C, vs linear with C for the RC case). Then you need some counters plus a good phase detector and a low-pass filter in its control input, so that you do not affect the oscillator with short-lived disturbances, but make it still follow the average frequency. And you decouple your Vcc and keep the ground stable. Really simple, just a bunch of engineering trade-offs. Peter Alfke

Reply to
Peter Alfke

I will slip in an 'oops' and a 'thanks' here. The input jitter generality is clearly wrong and contentious.

This issue brings up an application issue that has come up a number of times for me. I've set up a number of clock dividers using various techniques like clock-puncturing and numerator-accumulation/denominator-thresholding, but of course the output clock jitter varies directly with the input clock width.

What kind of thing could accept an extremely jittery clock output like that described above, and produce a nice clean clock with the same average frequency and substantially reduced jitter?

Best regards, Dwayne Surdu-Miller

Reply to
Dwayne Surdu-Miller

This can be done with a PLL (or a DLL that behaves like a PLL) Between phase detector and the variable oscillator you need a low-pass filter. This filter must suppress all the results of incoming jitter, but must still make the output track the average input frequency change. It must pass dc, but must suppress anything above a given frequency.

Peter Alfke

Reply to
Peter Alfke

I came across an interesting DLL that does just this. Rather than delay the input jittery clock, it uses its own oscillator which should be plesiochronous (close in frequency) to the input clock, and relatively free of jitter. Phases of this clean clock 60 degrees apart are generated, and control logic selects and interpolates different phases together to create an output clock that is of the same frequency, and synchronous with the input clock. I can dig up a link to the paper if your interested.

Cheers,

Michael.

Reply to
Michael Chan

I've seen CDR devices that do this, although I think the phases may have been less than 60 degrees apart. I could probably dig up part numbers if anyone is interested.

Regards, Allan.

Reply to
Allan Herriman

Hi!

Yes, I'd be interested, could you dig that paper up?

Jay.

Reply to
Jay

Hi Michael,

I'm definitely interested. A link to the paper would be very much appreciated.

Cheers, Dwayne

Reply to
Dwayne Surdu-Miller

Hi Allan,

I'd be interested in having a look at the parts. Could you kindly dig up the numbers?

Thanks kindly, Dwayne Surdu-Miller

Reply to
Dwayne Surdu-Miller

the

free

and

create

Here's the paper:

formatting link

Cheers,

Michael.

Reply to
Michael Chan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.