jitter in Virtex2 DCM

[Tullio Grassi]

The VirtexII data sheet requires an input jitter for
the DCM smaller than + or - 300 ps (in Low Frequency Mode).
Obviously this ensures the proper behavior across all
permitted frequencies and modes.

In my case I have an input clock with 1ns of pk-pk jitter, but
it is a 40 MHz clock, that I only need to shift by 90 (clk90),
and to multiply by 2 (clk2x) other than having a locked version
(clk0) of the original clock.
How can I verify if it still works reliabily ?
Or is the going to DCM loose lock ?
Or will the phase relationships btw the output clocks not met ?
--
Tullio Grassi

 

[Austin Lesea]

Tullio,

The spec is for cycle to cycle jitter, not for peak to peak.

If your signal has 1 ns of cycle to cycle jitter, it would all but
unusable for just about anything. Hopefully, that is not the case, and
the signal has 1 ns of peak to peak jitter.

If you were to measure the cycle to cycle jitter of this signal, it will
have to be less than the 300 ps +/- DCM input specification (which is
most likely). There is also the "jitter filter" attribute which should
be set to 0xFFFFh for real jittery input signals, as this will allow the
DCM to track the incming signal the fastest (to prevent one cycle jitter
to the next cycle of jitter from affecting the phase detector).

The status signals will properly indicate the operation: if locked does
not go high at all, or if it goes high, and then goes low a few thousand
clock cycles later, it is an indication of too much jitter.

I have tested the DCM with sine wave jitter (at one frequency) from 100
KHz to 20 MHz with much more than 1 ns of p-p jitter, and have seen no
issues at all, because the cycle to cycle jitter is much less than the
input specification. The DCM is completely insensitive to input jitter
frequency (within the range that was tested).

For example, if in 1 microsecond (1 megahertz), a 100 MHz clock signal
had 1ns of jitter, peak to peak, then there are 100 clock cycles per
jitter modulation period (1 us), and the cycle to cycle clock jitter is
1/100 of the peak to peak (or 10 ps).

Austin

Tullio Grassi wrote:

The VirtexII data sheet requires an input jitter for
the DCM smaller than + or - 300 ps (in Low Frequency Mode).
Obviously this ensures the proper behavior across all
permitted frequencies and modes.

In my case I have an input clock with 1ns of pk-pk jitter, but
it is a 40 MHz clock, that I only need to shift by 90 (clk90),
and to multiply by 2 (clk2x) other than having a locked version
(clk0) of the original clock.
How can I verify if it still works reliabily ?
Or is the going to DCM loose lock ?
Or will the phase relationships btw the output clocks not met ?

 

[Tullio Grassi]

Yes, it is as you predicted, the cycle to cycle jitter
of my signal is much lower, and within the DLL specs.

Thanks a lot,

Tullio

On Mon, 1 Dec 2003, Austin Lesea wrote:

Tullio,

The spec is for cycle to cycle jitter, not for peak to peak.

If your signal has 1 ns of cycle to cycle jitter, it would all but
unusable for just about anything. Hopefully, that is not the case, and
the signal has 1 ns of peak to peak jitter.

If you were to measure the cycle to cycle jitter of this signal, it will
have to be less than the 300 ps +/- DCM input specification (which is
most likely). There is also the "jitter filter" attribute which should
be set to 0xFFFFh for real jittery input signals, as this will allow the
DCM to track the incming signal the fastest (to prevent one cycle jitter
to the next cycle of jitter from affecting the phase detector).

The status signals will properly indicate the operation: if locked does
not go high at all, or if it goes high, and then goes low a few thousand
clock cycles later, it is an indication of too much jitter.

I have tested the DCM with sine wave jitter (at one frequency) from 100
KHz to 20 MHz with much more than 1 ns of p-p jitter, and have seen no
issues at all, because the cycle to cycle jitter is much less than the
input specification. The DCM is completely insensitive to input jitter
frequency (within the range that was tested).

For example, if in 1 microsecond (1 megahertz), a 100 MHz clock signal
had 1ns of jitter, peak to peak, then there are 100 clock cycles per
jitter modulation period (1 us), and the cycle to cycle clock jitter is
1/100 of the peak to peak (or 10 ps).

Austin

Tullio Grassi wrote:

The VirtexII data sheet requires an input jitter for
the DCM smaller than + or - 300 ps (in Low Frequency Mode).
Obviously this ensures the proper behavior across all
permitted frequencies and modes.

In my case I have an input clock with 1ns of pk-pk jitter, but
it is a 40 MHz clock, that I only need to shift by 90 (clk90),
and to multiply by 2 (clk2x) other than having a locked version
(clk0) of the original clock.
How can I verify if it still works reliabily ?
Or is the going to DCM loose lock ?
Or will the phase relationships btw the output clocks not met ?

--
Tullio Grassi

======================================

Univ. of Maryland-Dept. of Physics |
College Park, MD 20742 - US |
Tel +1 301 405 5970 |
Fax +1 301 699 9195 |
======================================

 

[Austin Lesea]

Great!

Good luck.

Austin

Tullio Grassi wrote:

Yes, it is as you predicted, the cycle to cycle jitter
of my signal is much lower, and within the DLL specs.

Thanks a lot,

Tullio

On Mon, 1 Dec 2003, Austin Lesea wrote:


Tullio,

The spec is for cycle to cycle jitter, not for peak to peak.

If your signal has 1 ns of cycle to cycle jitter, it would all but
unusable for just about anything. Hopefully, that is not the case, and
the signal has 1 ns of peak to peak jitter.

If you were to measure the cycle to cycle jitter of this signal, it will
have to be less than the 300 ps +/- DCM input specification (which is
most likely). There is also the "jitter filter" attribute which should
be set to 0xFFFFh for real jittery input signals, as this will allow the
DCM to track the incming signal the fastest (to prevent one cycle jitter
to the next cycle of jitter from affecting the phase detector).

The status signals will properly indicate the operation: if locked does
not go high at all, or if it goes high, and then goes low a few thousand
clock cycles later, it is an indication of too much jitter.

I have tested the DCM with sine wave jitter (at one frequency) from 100
KHz to 20 MHz with much more than 1 ns of p-p jitter, and have seen no
issues at all, because the cycle to cycle jitter is much less than the
input specification. The DCM is completely insensitive to input jitter
frequency (within the range that was tested).

For example, if in 1 microsecond (1 megahertz), a 100 MHz clock signal
had 1ns of jitter, peak to peak, then there are 100 clock cycles per
jitter modulation period (1 us), and the cycle to cycle clock jitter is
1/100 of the peak to peak (or 10 ps).

Austin

Tullio Grassi wrote:


The VirtexII data sheet requires an input jitter for
the DCM smaller than + or - 300 ps (in Low Frequency Mode).
Obviously this ensures the proper behavior across all
permitted frequencies and modes.

In my case I have an input clock with 1ns of pk-pk jitter, but
it is a 40 MHz clock, that I only need to shift by 90 (clk90),
and to multiply by 2 (clk2x) other than having a locked version
(clk0) of the original clock.
How can I verify if it still works reliabily ?
Or is the going to DCM loose lock ?
Or will the phase relationships btw the output clocks not met ?