Re: [SI-LIST] : Clock Jitter

About this list Date view Thread view Subject view Author view

From: Vinu Arumugham (vinu@cisco.com)
Date: Mon Apr 30 2001 - 10:15:04 PDT


Saeen,

You are correct. If the manufacturer specifies "available setup time" and
"available hold time" on the data with respect to the clock at the driver
output, the system designer normally does not have to account for jitter.

In some designs however, the receiver may not use the same edge of the clock
relative to which the driver data timing is specified. In such cases, jitter
and/or duty cycle will have to be accounted for.

If the manufacturer specifies only max. skew between clock and data at the
driver output, then jitter and/or duty cycle needs to be accounted for.

Thanks,
Vinu

Saeen Malik wrote:

> Andy,
>
> Thanks for your detailed explanation. I agree with what you said,
> but, my question was just a little bit different. I have a circuit
> using a component which the manufacturer specifies to output certain
> clock/data timing relationship. By the way it is a DDR interface.
> The manufacturer specifies in his data sheet a setup and hold
> time of (say) 1.0ns each. Now, this would mean that if the refclock input
> to the device has acceptable jitter (as per the data sheet),
> then the timing relationship at the source synchronous output is
> gauranteed. This would mean that I could discard jitter from my
> calculations. Is this true or am I missing something???
>
> I would really appreciate your input...
>
> Saeen
>
> p.s.: The part in question is a serdes.
>
> >From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
> >Reply-To: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
> >To: "'Saeen Malik'" <saeens@hotmail.com>
> >CC: "si-list@silab.eng.sun.com" <si-list@silab.eng.sun.com>
> >Subject: RE: [SI-LIST] : Clock Jitter
> >Date: Fri, 27 Apr 2001 17:28:51 -0400
> >
> > > You mentioned that "Hold requires jitter to be included in calculation"
> > > in case of Source Synchronous Interface. I don't quite understand it.
> >
> >Extending Scott McMorrow's example into three Source Synchronous cases:
> >
> >case2a) Clock and data emerge at same time from source. Clock is given
> >somewhat more delay so data arrives at destination first.
> > Data transmitted on Clock(N)
> > Data received on Clock(N) for setup
> > Data held against Clock(N-1)
> > Setup does not require jitter to be include in calculation.
> > Hold requires jitter to be included in calculation.
> >
> >case2b) Clock and data emerge at same time from source. Clock is given
> >somewhat less delay so clock arrives at destination first.
> > Data transmitted on Clock(N)
> > Data received on Clock(N+1) for setup
> > Data held against Clock(N)
> > Setup requires jitter to be include in calculation.
> > Hold does not require jitter to be included in calculation.
> >
> >case2c) Clock is pre-timed to emerge from source when data is stable.
> >Clock and data are given equal delays to the destination, and arrive
> >alternating.
> > Data transmitted on Clock(N)
> > Data received on Clock(N+1) for setup
> > Data held against Clock(N-1)
> > Setup requires jitter to be include in calculation.
> > Hold requires jitter to be included in calculation.
> >
> >In all cases, "jitter" means the jitter of the internal clock that drives
> >both the external clock and the data.
> >
> >Case 2c might be used if there is a faster (2x) internal clock, or
> >rising/falling clock edges, that can be used to alternate the source
> >synchronous clock and the data transitions being driven. Invariably, that
> >2x clock has some jitter, which should be accounted for ... whether that is
> >done by building it into the IC specs (if it's a known quantity that is
> >determined solely by the IC), or by explicitly adding it later when you do
> >timing verification.
> >
> >No matter what you do, it always helps to get a good understanding of
> >exactly what's doing what. I try to avoid blindly adding up numbers
> >without
> >picturing it in my head (or on paper) to make sure it really makes sense.
> >
> >Regards,
> >Andy
> >
> >
> >**** 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
> >****
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> **** 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
> ****

**** 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 Jun 21 2001 - 10:11:47 PDT