[SI-LIST] : Accuracy vs. engineering judgement

About this list Date view Thread view Subject view Author view

From: Dr. Edward P. Sayre (esayre@nesa.com)
Date: Wed May 23 2001 - 10:22:31 PDT


Folks:

If you have automated tools then being precise where one can and
approximating where you have to is the proper use of engineering
judgement. Engineers are in the risk reduction business and so where we
can reduce risk, so we should.

ed
=======
At 12:38 PM 5/21/2001 -0400, Todd Westerhoff wrote:
>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
>****

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| NORTH EAST SYSTEMS ASSOCIATES, INC. |
| ------------------------------------- |
| "High Performance Engineering & Design" |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Dr. Ed Sayre e-mail: esayre@nesa.com |
| NESA, Inc. http://www.nesa.com/ |
| Primrose Park Tel +1.978.392-8787 |
| 5 LAN Drive, Ste 200 Fax +1.978.392-8686 |
| Westford, MA 01886 |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

**** 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:05 PDT