Re: Are clock and divided clock synchronous?

John_H,

A few comments...

Austin

John_H wrote:

> Bob, thanks for putting the question forward so well.
>
> Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
> 2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
> 6.1i will adjust for the input-jitter induced timing skew.

Skew is a fixed phase offset, or error, from a nominal value.  Think of it aas
DC.

Jitter is variations around the "significant instant" (ie where a perfect clock
would be).  Think of it as AC.  Don't mix AC and DC.  They don't mix well.  AC
adds RMS or peak to peak root mean square.  DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate)
so that you do not have to make an Excel spreadsheet to keep track of
everything.

>
>
> If the caution we've been designing against can be a non-issue with a proper
> INPUT_JITTER number, I'm a happy guy.  Primarily because of this caution, I
> was ecstatic to see these new constraints.  If the caution we've been
> designing against is a non-issue because it never was a problem (despite
> apparent empirical evidence otherwise) I'm still happy though a little
> confused.

If you can state your confusion to me, I will attempt to clarify (can post, or
send to me directly).

>
>
> I never did find out if the multiple clocks were guaranteed to use the same
> delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

Clocks fromt he same DCM are spec'd to arrive at their destinations when using
the global clock buffers +/- 140 ps (for example) when the destinations are all
on the same H clock tree within a few CLBs or IOBs of one another (ie removing
clock skew on the global).

>
>
> "Bob Perlman" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Peter -
> >
> > I don't want to put words in Ray Andraka's mouth, but I distinctly
> > remember him posting about the dangers of using the supposedly
> > low-skew outputs from the DLLs of Virtex parts.  As I recall, the
> > problem he experienced was that jitter on the clock coming into the
> > part resulted in jitter on the DCM output clocks, in a way that didn't
> > track from clock to clock.  (Such jitter could be caused by the clock
> > generator itself, or by SSO noise from nearby FPGA outputs.) So while
> > the spec for output-to-output skew is indeed low, the effects of input
> > clock jitter could increase these numbers.  (If this is wrong, Ray,
> > please jump in and correct me.)
> >
> > For that reason, I've always treated transfers between f and Nf
> > domains carefully, and I assume that rising-edge-to-rising edge
> > transfers won't work reliably in all cases.
> >
> > So, my questions:
> >
> > 1) To what extent does jitter on the input clock affect DLL/DCM
> > output-to-output skew?
> >
> > 2) Is there some amount of input clock jitter below which the skew
> > published in the data sheets dominates?  For example, for a Virtex II
> > part, how much jitter can I tolerate on the DCM clock input before the
> > DCM output-to-output phase offset exceeds the +/-140ps number in the
> > data sheet?  (The Virtex II data sheet says that the input clock
> > period jitter can be as high as +/-1ns; is this just the amount of
> > jitter we can tolerate before losing lock, or do I get the +/-140ps
> > clock-to-clock output skew with this much jitter?)
> >
> > Thanks,
> > Bob Perlman
> > Cambrian Design Works
> >
> > On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <[EMAIL PROTECTED]>
> > wrote:
> >
> > >DLLs ain't misbehavin' !
> > >
> > >The DLL in Spartan-2 does not have all the functionality of the
> > >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> > >offer extremely low ("zero") skew between their output drivers. So I
> > >disagree with Jeff's statement.
> > >
> > >Peter Alfke, Xilinx Applications
> > >=================
> > >Jeff Cunningham wrote:
> > >>
> > >> Peter Alfke wrote:
> > >> > If you use the Digital Clock Manager in Virtex-II or Spartan3,  you
> have
> > >> > four outputs with practically zero skew (<100ps?)between them, and
> they
> > >> > can be fractions or multiples of the incoming clock. When you
> distribute
> > >> > these signals on global clocks, there will not be any hold-time
> caused
> > >> > problems. The skew is definitely less than any clock-to-Q.
> > >>
> > >> Just to make sure I understand, this is NOT the case with the Spartan-2
> > >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> > >>
> > >> Jeff
> >