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

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 ?

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                  |
======================================

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 ?
>>
>>
>