RE: [SI-LIST] : Accuracy

About this list Date view Thread view Subject view Author view

From: Todd Westerhoff (twester@hhnetwk.com)
Date: Mon May 21 2001 - 09:38:00 PDT


Scott,

Very good points - but they beg the question:

If I'm doing my own ASIC, and even if I characterize the behavior through
the I/O buffers to the Nth degree with HSpice (or whatever) -

- how good, on average, is the internal skew information I can get for the
path delays inside the ASIC?. This is the same question as before: if I can
only predict the signal arrival times at the inputs of the output buffers to
+/- 50 pS - how important are 25 pS effects at the board level? And more
importantly, what level of timing resolution for internal ASIC delays should
be considered "good" for a modern device?

Todd.

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

-----Original Message-----
From: Scott McMorrow [mailto:scott@vasthorizons.com]
Sent: Monday, May 21, 2001 2:00 PM
To: Todd Westerhoff; si-list@silab.eng.sun.com
Subject: Re: [SI-LIST] : Accuracy

Todd,

I would argue that for the highest accuracy chip timing should
be extracted relative to the output of the input buffers and the input of
the output buffers. These points are least influenced by package and
external effects.

Simulations in (your favorite time domain simulator) can be performed to
characterize
the end to end path from the input of the driver to the output of the
receiver. Noise can even be added to the power and reference rails
to increase the accuracy of the results. (Since output and input performance
is dependent upon the device loading, power distribution and noise
conditions,
these simulations will produce correct results for any system
configuration.)

As for commerctial timing numbers for parts, it is often unclear what these
numbers really mean and how they were actually developed. Does timing
into a 0pF load condition include all simulataneous switching and package
effects? When I increase the loading on the driver, this increases the I/O
bounce due to package power and ground inductance. How do I go about
characterizing this and seperating it from what was actually characterized
by
the manufacturer? How about timing into a 50pF load? And is the method for
measuring
minimum timing the same as that for measuring maximum timing parameters?
Oh, and when timing is measured on an input relative to some threshold
or voltage reference, is this measurement to be made relative to the
instantaneous voltages at the pins of the device or the die of the device,
and
have SSO and SSI effects been included in these numbers?

The more I think about these questions and simulate them, the more I wonder
how much guardbanding is done by the manufacturers, and how much double
counting is done of parameters (or how much is not really characterized.)

If we design our own ASICS, then the job falls on us to characterize the
entire
system. And I believe this can be done quite well with the methodology
described
in paragraphs 1 and 2. The limit on accuracy will be in the accuracy of the
models
for the device and package. Given enough data, the package can be
characterized
to any degree of accuracy desired. I cannot speak for the ability of
semiconductor
vendors to accurately characterize and model their devices, but I assume
that
this also can be done. (Otherwise the foundation of our simulation structure
falls
apart.)

For designs with commercial parts, the problem is one of what we do not
know.
We do not know how the timing specifications were derived. We do not know
what package effects were included. We do not know how measurements are
correlated back to their own internal simulations. We do not know all the
assumptions
that the manufacturer has made in specifying timing. So, when our
conditions
change from their conditions and assumptions, we do not truly know how best
to proceed to correlate our simulations to their assumptions.

When timing margins and/or skews required are above several hundred
picoseconds
I do not worry about such matters. However, when they are below 100 ps,
everything
matters ... and it is those unstated assumptions which vendors have that are
most
troubling to me.

regards,

scott

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

Todd Westerhoff wrote:

> 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:03 PDT