DCM Jitter

I would like to use a Spartan 3 DCM to divide a clock by 5.  I don't care 
about skew and would prefer not to connect the CLK_FB.  I do care very much 
about jitter.  I'm actually using the FPGA to output a pulse-width-modulated 
signal, so I'm committing a total "no-no" by using it as an analogue 
component!

I've read that the DCM DLL function is actually very clean as far as phase 
noise / spectral purity are concerned, as long as the DLL doesn't keep 
swapping taps.  Does anyone know any sneaky non-standard tricks that would 
allow me to have my divide-by-5 with tap-swapping disabled?  I could do the 
divide with CLBs; but I wonder if the DCM, with its dedicated routing to the 
global clock buffers, could actually be better?

One caveat: I need the FPGA to be totally static at certain times, to 
completely eliminate digital switching noise.  Does enabling a DCM activate 
any internal free-running oscillators?

Finally, I must confess that my frequency is below the specified minimum; 
but I'm hoping the minimum doesn't apply if I'm only doing division.  Am I 
in luck?

TIA
Andrew. 

On Wed, 20 May 2009 00:40:42 +0100
"Andrew Holme" <ah@nospam.co.uk> wrote:

> I would like to use a Spartan 3 DCM to divide a clock by 5.  I don't
> care about skew and would prefer not to connect the CLK_FB.  I do
> care very much about jitter.  I'm actually using the FPGA to output a
> pulse-width-modulated signal, so I'm committing a total "no-no" by
> using it as an analogue component!
> 
> I've read that the DCM DLL function is actually very clean as far as
> phase noise / spectral purity are concerned, as long as the DLL
> doesn't keep swapping taps.  Does anyone know any sneaky non-standard
> tricks that would allow me to have my divide-by-5 with tap-swapping
> disabled?  I could do the divide with CLBs; but I wonder if the DCM,
> with its dedicated routing to the global clock buffers, could
> actually be better?
> 
> One caveat: I need the FPGA to be totally static at certain times, to 
> completely eliminate digital switching noise.  Does enabling a DCM
> activate any internal free-running oscillators?
> 
> Finally, I must confess that my frequency is below the specified
> minimum; but I'm hoping the minimum doesn't apply if I'm only doing
> division.  Am I in luck?
> 
> TIA
> Andrew. 
> 
> 

If you don't care about a 50% duty cycle, you could build a 2 up/3 down
divider out of logic that would have very low jitter.

Though the usual question applies: are you sure you wouldn't be better
served just clock-enabling the logic?

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

On May 19, 4:40=A0pm, "Andrew Holme" <a...@nospam.co.uk> wrote:
> I would like to use a Spartan 3 DCM to divide a clock by 5. =A0I don't ca=
re
> about skew and would prefer not to connect the CLK_FB. =A0I do care very =
much
> about jitter. =A0I'm actually using the FPGA to output a pulse-width-modu=
lated
> signal, so I'm committing a total "no-no" by using it as an analogue
> component!
>
> I've read that the DCM DLL function is actually very clean as far as phas=
e
> noise / spectral purity are concerned, as long as the DLL doesn't keep
> swapping taps. =A0Does anyone know any sneaky non-standard tricks that wo=
uld
> allow me to have my divide-by-5 with tap-swapping disabled? =A0I could do=
 the
> divide with CLBs; but I wonder if the DCM, with its dedicated routing to =
the
> global clock buffers, could actually be better?
>
> One caveat: I need the FPGA to be totally static at certain times, to
> completely eliminate digital switching noise. =A0Does enabling a DCM acti=
vate
> any internal free-running oscillators?
>
> Finally, I must confess that my frequency is below the specified minimum;
> but I'm hoping the minimum doesn't apply if I'm only doing division. =A0A=
m I
> in luck?
>
> TIA
> Andrew.

On May 19, 4:40=A0pm, "Andrew Holme" <a...@nospam.co.uk> wrote:
> I would like to use a Spartan 3 DCM to divide a clock by 5. =A0I don't ca=
re
> about skew and would prefer not to connect the CLK_FB. =A0I do care very =
much
> about jitter. =A0I'm actually using the FPGA to output a pulse-width-modu=
lated
> signal, so I'm committing a total "no-no" by using it as an analogue
> component!
>
> I've read that the DCM DLL function is actually very clean as far as phas=
e
> noise / spectral purity are concerned, as long as the DLL doesn't keep
> swapping taps. =A0Does anyone know any sneaky non-standard tricks that wo=
uld
> allow me to have my divide-by-5 with tap-swapping disabled? =A0I could do=
 the
> divide with CLBs; but I wonder if the DCM, with its dedicated routing to =
the
> global clock buffers, could actually be better?
>
> One caveat: I need the FPGA to be totally static at certain times, to
> completely eliminate digital switching noise. =A0Does enabling a DCM acti=
vate
> any internal free-running oscillators?
>
> Finally, I must confess that my frequency is below the specified minimum;
> but I'm hoping the minimum doesn't apply if I'm only doing division. =A0A=
m I
> in luck?
>
> TIA
> Andrew.

I suggest you use the highest possible frequency for your pulse-width
modulator clock. That gives you best resolution (granularity) and
avoids the jitter issue you are (rightfully) concerned about.
Peter Alfke

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:0cb28ad3-c345-41dd-ac70-ee9ad001938e@v35g2000pro.googlegroups.com...

>I suggest you use the highest possible frequency for your pulse-width
>modulator clock. That gives you best resolution (granularity) and
>avoids the jitter issue you are (rightfully) concerned about.

Hi, Peter.  The PWM is a continuous analogue output, generated by an 
AD9901-style phase detector inside the FPGA.  There is no granularity. 

On May 19, 7:40=A0pm, "Andrew Holme" <a...@nospam.co.uk> wrote:
> I would like to use a Spartan 3 DCM to divide a clock by 5. =A0I don't ca=
re
> about skew and would prefer not to connect the CLK_FB. =A0I do care very =
much
> about jitter. =A0I'm actually using the FPGA to output a pulse-width-modu=
lated
> signal, so I'm committing a total "no-no" by using it as an analogue
> component!
>
> I've read that the DCM DLL function is actually very clean as far as phas=
e
> noise / spectral purity are concerned, as long as the DLL doesn't keep
> swapping taps. =A0Does anyone know any sneaky non-standard tricks that wo=
uld
> allow me to have my divide-by-5 with tap-swapping disabled? =A0I could do=
 the
> divide with CLBs; but I wonder if the DCM, with its dedicated routing to =
the
> global clock buffers, could actually be better?
>

The DCM is clean, but the output can only be as clean as the
input.  A DCM does not reduce jitter under any circumstance
as its core is a variable delay line rather than a VCO.

> One caveat: I need the FPGA to be totally static at certain times, to
> completely eliminate digital switching noise. =A0Does enabling a DCM acti=
vate
> any internal free-running oscillators?
>

As a delay line, the DCM does not have any oscillators.  However
if you stop the input clock, you will need to re-lock the DCM
when the clock re-starts.  This can take quite a few clock cycles
and requires a reset to the DCM.

> Finally, I must confess that my frequency is below the specified minimum;
> but I'm hoping the minimum doesn't apply if I'm only doing division. =A0A=
m I
> in luck?
>

No.  The DCM will only lock if it's delay line is long enough to
make up one full cycle of the input clock.  You can use the DCM
at lower frequencies when you only use the CLKFX outputs, but the
CLKDV output requires the delay line for duty cycle control.

> TIA
> Andrew.

If you use a global clock input pin to the FPGA and place the BUFG
component near the clock pin, you could probably get as good jitter
performance as with using a DCM.  If you need to clean up your input
clock jitter you'll need a part with a PLL in it.  Try to minimise
the routing delays from the final flip-flop stage in your design
to the output pins (i.e. use the IOB output flop if possible).
Also note that jitter is often introduced from the power supply
system, so make sure your power is clean.  This includes core
power, where power supply variation causes variation in internal
delays (hence the note about reducing output routing).  It also
includes Vcco which can cause changes in the switching threshold
level.  The clock input is especially susceptible to this when
the rise and fall times are longer.  Using a differential clock
source will minimize this effect.

HTH,
Gabor

gabor wrote:
>
> The DCM is clean, but the output can only be as clean as the
> input.  A DCM does not reduce jitter under any circumstance
> as its core is a variable delay line rather than a VCO.
>
Hi Gabor,
Are you sure about that? I believe the DCM only updates it's taps every now 
and then, in fact I think the attribute "FACTORY_JF" controls the update 
rate. If the input jitter was several 'taps' in amplitude, and faster than 
the tap update rate, perhaps the DCM would attenuate jitter.
The point I'm trying to make is that a delay locked loop certainly can 
attenuate jitter in some circumstances, for example if the incoming jitter 
is more than 1 tap in amplitude. I'm not certain the Xilinx ones do, but I 
believe your reasoning that they don't because "its core is a variable delay 
line rather than a VCO" is not valid.
Cheers, Syms.

Syms,

The DCM never attenuates jitter.  It can not be accidentally 'correct'
all the time (zig for every zag...).  It is a delay line.  What goes
in, is guaranteed to come out.

The DCM only changes one tap at a time (based on the FACTORY_JF
setting, it is that number times 6 or 36 -- depending on family --
input clocks for one tap change).  The FACTORY_JF is completely miss-
leading, as the intent was to allow the DCM to tolerate input jitter,
but correcting often, or not so often, does nothing to tolerate input
jitter.  And since it only updates one tap, the FACTORY_JF also does
nothing to increase or decrease the output jitter.  The only time we
recommended changing the FACTORY_JF setting was for the Vccaux dV/dt '
issue' on Virtex II (subsequently fixed in all later devices).

I suspect that if the output is a PWM signal, that jitter is no issue
whatsoever, as the PWM signal is a signal that has potentially 100%
"jitter" just to do what it is supposed to be doing.  I am not sure
what the poster really is concerned about.

There is a hidden setting to freeze the DCM updates of the taps, but
it really isn't of any use, other than for testing (does the added tap
switch jitter break the design?  If so, you are so close to your
timing margin -- no slack -- that you really need to find and
constrain the paths where the device has insufficient slack).

Austin

"austin" <austin@xilinx.com> wrote in message 
news:a193c66c-bf74-4f77-ba75-a18ba5957165@w35g2000prg.googlegroups.com...
> Syms,
>
> The DCM never attenuates jitter.  It can not be accidentally 'correct'
> all the time (zig for every zag...).  It is a delay line.  What goes
> in, is guaranteed to come out.
>
> The DCM only changes one tap at a time (based on the FACTORY_JF
> setting, it is that number times 6 or 36 -- depending on family --
> input clocks for one tap change).  The FACTORY_JF is completely miss-
> leading, as the intent was to allow the DCM to tolerate input jitter,
> but correcting often, or not so often, does nothing to tolerate input
> jitter.  And since it only updates one tap, the FACTORY_JF also does
> nothing to increase or decrease the output jitter.  The only time we
> recommended changing the FACTORY_JF setting was for the Vccaux dV/dt '
> issue' on Virtex II (subsequently fixed in all later devices).
>
> I suspect that if the output is a PWM signal, that jitter is no issue
> whatsoever, as the PWM signal is a signal that has potentially 100%
> "jitter" just to do what it is supposed to be doing.  I am not sure
> what the poster really is concerned about.
>

Hi Austin,

I'm building fractional-N synthesizers like this using the Spartan 3:

http://www.holmea.demon.co.uk/Frac3/Main.htm


> There is a hidden setting to freeze the DCM updates of the taps, but
> it really isn't of any use, other than for testing (does the added tap
> switch jitter break the design?  If so, you are so close to your
> timing margin -- no slack -- that you really need to find and
> constrain the paths where the device has insufficient slack).
>
> Austin


What is the hidden setting?

I'm designing a new synthesizer with two PLLs.  One PLL is the same as in my 
design  above.  The other will lock the VCXO reference to an external 
standard.  The standard is a very clean  and stable 5 MHz which I would like 
to divide down to 1 MHz or 500 KHz.  Unfortunately, in the first spin of the 
PCB, the 5 MHz enters on an LVDS pair in a corner close to one of the DCMs, 
and I was wondering if I could use the DCM to do the division.  Next time, I 
will probably use a global clock pair as I do for the VCO and XCO clocks. 

On May 21, 2:13=A0pm, "Andrew Holme" <a...@nospam.co.uk> wrote:
> "austin" <aus...@xilinx.com> wrote in message
>
> news:a193c66c-bf74-4f77-ba75-a18ba5957165@w35g2000prg.googlegroups.com...
>
>
>
> > Syms,
>
> > The DCM never attenuates jitter. =A0It can not be accidentally 'correct=
'
> > all the time (zig for every zag...). =A0It is a delay line. =A0What goe=
s
> > in, is guaranteed to come out.
>
> > The DCM only changes one tap at a time (based on the FACTORY_JF
> > setting, it is that number times 6 or 36 -- depending on family --
> > input clocks for one tap change). =A0The FACTORY_JF is completely miss-
> > leading, as the intent was to allow the DCM to tolerate input jitter,
> > but correcting often, or not so often, does nothing to tolerate input
> > jitter. =A0And since it only updates one tap, the FACTORY_JF also does
> > nothing to increase or decrease the output jitter. =A0The only time we
> > recommended changing the FACTORY_JF setting was for the Vccaux dV/dt '
> > issue' on Virtex II (subsequently fixed in all later devices).
>
> > I suspect that if the output is a PWM signal, that jitter is no issue
> > whatsoever, as the PWM signal is a signal that has potentially 100%
> > "jitter" just to do what it is supposed to be doing. =A0I am not sure
> > what the poster really is concerned about.
>
> Hi Austin,
>
> I'm building fractional-N synthesizers like this using the Spartan 3:
>
> http://www.holmea.demon.co.uk/Frac3/Main.htm
>
> > There is a hidden setting to freeze the DCM updates of the taps, but
> > it really isn't of any use, other than for testing (does the added tap
> > switch jitter break the design? =A0If so, you are so close to your
> > timing margin -- no slack -- that you really need to find and
> > constrain the paths where the device has insufficient slack).
>
> > Austin
>
> What is the hidden setting?
>
> I'm designing a new synthesizer with two PLLs. =A0One PLL is the same as =
in my
> design =A0above. =A0The other will lock the VCXO reference to an external
> standard. =A0The standard is a very clean =A0and stable 5 MHz which I wou=
ld like
> to divide down to 1 MHz or 500 KHz. =A0Unfortunately, in the first spin o=
f the
> PCB, the 5 MHz enters on an LVDS pair in a corner close to one of the DCM=
s,
> and I was wondering if I could use the DCM to do the division. =A0Next ti=
me, I
> will probably use a global clock pair as I do for the VCO and XCO clocks.

If your final output is a PWM signal synchronous to the 5 MHz
input clock, wouldn't it make sense to re-clock it with an external
part (picoGate or similar flip-flop) using the clean 5 MHz?
  Then your FPGA jitter just needs to stay
within the portion of a cycle time to guarantee setup and hold
to the external flip-flop.  You could also make sure the external
flop has a clean Vcc for a stable analog PWM voltage.

Regards,
Gabor