From: Larry Smith ([email protected])
Date: Tue May 22 2001 - 14:24:45 PDT
Todd - The hardest part of this is defining our terms...
Clock-forwarded and source-synchronous are synonymous (anybody
disagree with that?).
In the recent past, component-delay usually meant the delay from when
the global clock hit the component until the data came out. Other
terminology for this is "clock-to-out" or "clock-to-Q". I see from
your attached note that we are really discussing component-delay in
terms of the skew between several different drivers. That can make a
huge difference in system timing. I think I misinterpreted the
meaning of component-delay in a previous note.
I agree with you that the skew on the data bus is a function of clock
skew on the driver chip, buffer delay, package, pcb and connector
delays, and similar stuff on the receiver chip. Many issues!
If all nets of a data bus are to be received against the same clock,
then all these skews are important. You essentially have to make an
eye diagram that is the "and" of all the individual nets and see if
there is an opening big enough to capture the data against a single
clock. If that is the case, then all of the individual skews and
delays are important.
At the next level of complexity, it is possible for the receiver clock
to have many phases. If each data bit somehow chooses the best phase
of the clock, then skew between the several data bits is less
important. But this adds a lot of complexity to the receiver design.
The bottom line question has to do with the openness of the eye diagram
for an individual bit. If it is not open, we will not recover the data
unless some pre-emphasis or equalization is performed. Within that
limited scope of discussion, 10's of pSec of accuracy are required from
But I completely agree with you. Unless the rest of the system
complexity is up to par, there really is no need to simulate at the 10
> From: "Todd Westerhoff" <[email protected]>
> To: <[email protected]>
> Subject: RE: [SI-LIST] : Accuracy
> Date: Tue, 22 May 2001 12:10:37 -0400
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Thanks, Larry.
> When I mentioned "clock-forwarded", I meant "source-synchronous". I tend to
> use the terms interchangably, and maybe I shouldn't.
> Unless I'm mistaken, there are still component timing issues with
> source-synchronous design, they're just tricker. For example, on-die clock
> skew to the different output buffers will introduce delays between outputs
> that we'd like to think are simultaneous. On any given die, there will also
> be differences in delay from buffer to buffer, that, while they may only be
> 20% of the buffer's max-min delay range, will also introduce skew across
> outputs we'd like to think are simultaneous.
> ... and then there's the issue of package delays, which introduce yet
> another set of skews. Characterizing the skew induced by the package and
> the accuracy of that analysis presents a set of problems unto itself.
> ... and the same package and internal clock skew issues present themselves
> at the receiving end. The received clock has to be buffered and routed to
> the different latch inputs on-die, and there should be skews and delays
> associated with that.
> So, my question is - to what level should we expect to be able to control
> on-die and package skews, and what methodologies/tools are people using to
> put all these disparate pieces of timing/SI information together? Are
> people thinking they need to do timing/SI analysis from pin to pin, pad to
> pad, or inside-ASIC to inside-ASIC?
> Todd Westerhoff
> SI Engineer
> Hammerhead Networks
> 5 Federal Street
> Billerica, MA 01821
> [email protected]
> ph: 978-671-5084
> -----Original Message-----
> From: Larry Smith [mailto:[email protected]]
> Sent: Monday, May 21, 2001 8:10 PM
> To: [email protected]; [email protected]
> Subject: Re: [SI-LIST] : Accuracy
> Todd - back when we were doing "synchronous" (common clock) designs,
> the component timing was important. For synchronous designs, all chips
> on a PCB were listening to the same clock. Signals were launched from
> a driver on the rising edge of the clock and received at some other
> chip on the next edge of the clock. The component delay (time from
> clock in to data out) was very important because it was part of the
> timing budget. A received signal had to come between the setup and
> hold time with respect to (WRT) the copy of the "global" clock on the
> receiving chip.
> Many of us have moved beyond synchronous design to "source synchronous"
> (clock forwarding) design. We no longer have the concept of a
> synchronous global PCB clock. A copy of the clock is driven from the
> driver chip along with all the data bits in the bus. The data bits are
> received at the receiver chip WRT the clock from the source chip.
> There may actually be several data bits and several clock pulses in
> transit between the driver chip and receiver chip at any point in
> The delay of the component is no longer important. There is no concept of
> setup and hold time WRT to some global clock. What is important is the
> skew of each of the data bits WRT the transmitted clock at both the
> driver and receiver chip and the openness of the eye pattern. If the
> eye pattern for each data bit is open, it will be possible to make a
> copy of the received clock with a phase such that the 1's and 0's of
> the data can be determined. Fifty picoseconds can be extremely
> important in the openness of the eye pattern. That's why accuracy
> at the sub-50pS level is required in our models and simulators.
> Larry Smith
> Sun Microsystems
> > From: "Todd Westerhoff" <[email protected]>
> > To: <[email protected]>
> > Subject: [SI-LIST] : Accuracy
> > Date: Mon, 21 May 2001 10:37:15 -0400
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3 (Normal)
> > X-MSMail-Priority: Normal
> > Importance: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> > Here's a question for the group that I'm hoping will invoke some
> > I've seen and heard lots of comments over the years about the need for
> > "accurate" SI analysis. We've had any number of threads over the past few
> > months discussing effects that would produce variances of 50 pS or less in
> > simulation results, and the need for such levels of accuracy.
> > But what about timing? After all, signal integrity is only one component
> > system analysis; you need to put SI analyses together with component
> > data to figure out whether your system works or not. And what's the point
> > of having 15 pS of accuracy in your SI analysis results if you only know
> > component timing to within 250 pS?
> > I'm interested in how people are coupling SI analysis with timing data,
> > both common-clock and clock-forwarded architectures, to close system-level
> > timing. I'm really interested in what level of accuracy people have for
> > timing data, and at what level. At the commercial component level, it
> > to me there's so much margin in the timing numbers that many of the finer
> > effects we discuss here are swamped out. And even when you have internal
> > timing data for an ASIC you're designing, well, it seems to me that if you
> > know your timing and skews to within 25 pS, you're doing better than most.
> > Comments, please.
> > Todd.
> > Todd Westerhoff
> > SI Engineer
> > Hammerhead Networks
> > 5 Federal Street
> > Billerica, MA 01821
> > [email protected]
> > ph: 978-671-5084
> > **** To unsubscribe from si-list or si-list-digest: send e-mail to
> > [email protected] 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
> [email protected] 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
[email protected] 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
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:12:05 PDT