RE: [SI-LIST] : Accuracy

About this list Date view Thread view Subject view Author view

From: Todd Westerhoff (twester@hhnetwk.com)
Date: Tue May 22 2001 - 09:10:37 PDT


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.

Todd Westerhoff
SI Engineer
Hammerhead Networks
5 Federal Street
Billerica, MA 01821
twester@hhnetwk.com
ph: 978-671-5084

-----Original Message-----
From: Larry Smith [mailto:ldsmith@lisboa.eng.sun.com]
Sent: Monday, May 21, 2001 8:10 PM
To: si-list@silab.eng.sun.com; twester@hhnetwk.com
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
time.

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.

regards,
Larry Smith
Sun Microsystems

> From: "Todd Westerhoff" <twester@hhnetwk.com>
> To: <si-list@silab.eng.sun.com>
> 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
discussion:
>
> 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
of
> system analysis; you need to put SI analyses together with component
timing
> 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,
for
> 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
seems
> 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
> twester@hhnetwk.com
> ph: 978-671-5084
>
>
> **** 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:12:04 PDT