RE: [SI-LIST] : PLL clock buffer chips and the feedback loop

About this list Date view Thread view Subject view Author view

From: Andy Peters (apeters@noao.edu)
Date: Thu Apr 06 2000 - 13:25:02 PDT


> From: owner-si-list@silab.eng.sun.com
> [mailto:owner-si-list@silab.eng.sun.com]On Behalf Of Ingraham, Andrew
>
> One thing not mentioned previously, is what else you will be
> doing with the
> clock that goes into to the PLL.
>
> Generally, people use a "zero delay" or PLL-based clock buffer when they
> must control the delay THROUGH the clock buffer, that is, to control clock
> skew between all your SDRAMs/FPGAs, and whatever other devices use the
> upstream clock before the PLL.
>
> If this delay is unimportant to you, then drop the PLL and use an ordinary
> non-PLL clock buffer. The only purpose of the PLL is to control
> or null the
> delay through the clock fanout part. It has no effect on skew between the
> chip's outputs.
>
> For example it looks here like you are driving the PLL input with an
> oscillator. If that oscillator goes nowhere else, then you
> certainly don't
> need a PLL in the clock buffer, and should eliminate it! The PLL adds
> complexity and clock jitter, and you must use very good bypassing
> of the PLL
> chip and isolate any loop filter pins, or it's going to have
> noisy outputs.
>
> Also, cascading PLLs has risks. In extreme cases, the combination can be
> unstable. More likely, it can in some cases make the downstream PLL's
> outputs very jittery, with a lot of effective skew between the
> two PLLs. I
> have heard of designs that were unusable because of cascaded PLLs.
>
> You might already have two cascaded PLLs if the "oscillator" itself is
> PLL-based. Cascading a third increases the risk.

Andy,

I see all of your points. What lead me down the yellow-brick-road of these
PLL clock buffer chips was not so much the delay through the device, but
rather the skew between the outputs. I am concerned about meeting setup
times at both the FPGA and the SDRAMs, and I thought that using such a
buffer and careful attention to clock line lengths would give me one less
thing to worry about. I cascaded the buffers so that the oscillator would
only see one load. Perhaps I am being overly conservative, and creating
more problems than I'm solving.

Anyways, a data sheet for the IDT74FCT807CT tells me that the max skew
between outputs is 250 ps - nearly the same as the output skew of the TI
CDCF2509 PLL part! I just wish it had twelve outputs instead of ten,
although I'm sure I can find something that'll work.

> Regarding the <1ms start-up time, are you sure that (a) the power
> supplies,
> and (b) the oscillator, come up and into spec fast enough? Even XTAL
> oscillators can take some time to start up and stabilize, and 1ms is not a
> lot of time. ~50ms is not uncommon for just a PC supply to ramp up; much
> more if multiple power rails are involved.

The 1ms startup time was the PLL spec. I just re-read the VME chip's info
on what it does at power up. It resets itself, and waits for four clock
ticks before starting its initialization. (It also starts to reinitialize
itself if VME SYSRST* is asserted.) My prototype board reliably fails to
configure itself at power-on, but always works after pushing the reset
button. To be honest, I'm not sure if the failure is because of an unstable
clock or not; however, the VME chip's clock is driven from the output of the
cascaded PLL buffer, so it might very well be trashed! I need to look at
that part of the board a bit more closely.

much thanks,

a

-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520 318 8191
apeters@noao.edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens

**** To unsubscribe from si-list or si-list-digest: send e-mail to majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:36:05 PDT