From: Larry Smith ([email protected])
Date: Mon May 21 2001 - 17:09:54 PDT
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" <[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 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
> [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
****
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:12:03 PDT