Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
The newer families of FPGAs run on frequencies whereHi,
What is the need for PLL / DLL ?
what kind of system requires this? When it is required?
From: Rene Tschaggelar <none@none.net
Newsgroups: comp.arch.fpga
Date: Sat, 17 Apr 2004 16:18:26 +0200
Subject: Re: PLL and DLL
Muthu wrote:
Hi,
What is the need for PLL / DLL ?
what kind of system requires this? When it is required?
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
Hi Dwayne,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.
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
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
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
Briefly, how do the specialized jitter reduction PLLs from ICS andAll,
Xilinx uses PLLs (in the MGTs).
There is no battle here. DLLs are good, PLLs are good. Choose what
you need.
From: "Tim" <tim@rockylogic.com.nooospam.com
Newsgroups: comp.arch.fpga
Date: Thu, 22 Apr 2004 19:48:43 +0100
Subject: Re: PLL and DLL
Austin Lesea wrote:
All,
Xilinx uses PLLs (in the MGTs).
There is no battle here. DLLs are good, PLLs are good. Choose what
you need.
Briefly, how do the specialized jitter reduction PLLs from ICS and
others achieve their performance? Just wondering.
This can be done with a PLL (or a DLL that behaves like a PLL)From: Dwayne Surdu-Miller <miller@SEDsystems.nospam.ca
Organization: Posted via Supernews, http://www.supernews.com
Newsgroups: comp.arch.fpga
Date: Fri, 23 Apr 2004 14:29:01 -0600
Subject: Re: PLL and DLL
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
input jittery clock, it uses its own oscillator which should beI 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
I came across an interesting DLL that does just this. Rather than delay the
I've seen CDR devices that do this, although I think the phases may"Dwayne Surdu-Miller" <miller@SEDsystems.nospam.ca> wrote in message
news:108iv4e3fah94df@corp.supernews.com...
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
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.
Hi!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.
Here's the paper:In article , mchan wrote:
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.
Hi!
Yes, I'd be interested, could you dig that paper up?
Jay.