[SI-LIST] Re: timing analysis

Mort,

A few things I thought were worth adding:

Logic Thresholds (Robert's point) - I'd argue that the whole point of 
signal integrity analysis is determining whether an interface works at 
speed.  That means extracting an interconnect delay (A.K.A. flight time) 
from signal integrity simulation based on how component timing is 
specified.  Understanding the exact details of output timing and 
setup/hold times are spec'd (including) derating are key.  Measuring to 
VIL/VIH won't give you the correct delays if your setup and hold times 
are spec'd at different voltage thresholds.  That's not understood well 
enough, and kudos to Robert for pointing that out.

Statistical Timing - it's true that there's a probability associated 
with how timing lines up, and it's true that having everything line up 
with best or worst case values is pretty unlikely (I call this 
band-based timing analysis). Thus, it's tempting to assume some 
distribution for the elements of the timing equation and use that to 
compute statistics for the timing margin.  It makes sense, doesn't it?

In theory - yes.  In practice - typically no.  If we're going to apply 
statistical methods to timing analysis, then the pieces of data we 
operate on need to fit certain statistical assumptions.  For instance - 
we might assume that component timing is centered around a nominal 
point, and has an regular, symmetric distribution of faster and slower 
values ... in other words a Gaussian distribution.  But what happens if 
we're buying a component that's binned by speed grade - can we assume 
the timing will be evenly distributed?  No.  If the faster and slower 
bins fall within the outer regions of our distribution (and they 
typically do), then the distribution of timing gets distorted, and 
affects our ability to make statistical assumptions about how the 
elements of our timing equation fit together.

The hardest part of part of being an engineer, in my opinion, is saying 
"I don't know".  We're trained to make assumptions, analyze problems and 
provide answers.  We take great pride in being able to use our ingenuity 
to provide answers even when key pieces of data are missing, because we 
can leverage our knowledge of the science behind the problem to deduce 
the solution.

The problem the system designer faces in this case, however, is that too 
much of the data is missing.  We know the timing and voltage specs we 
get from the component vendors are guardbanded, but by how much?  That's 
a key piece of data that has a big impact on our analysis of system 
reliability.  We could beat on the vendors to give us data with smaller 
guardbands.  Fact is - there are limits on their ability to measure and 
guarantee component behavior in a production environment (which is where 
the guardbands come from in the first place).  There's not much point in 
getting a better spec if the vendor can't guarantee the component will 
meet it.

Then there's the problem of not knowing what the distributions of 
component behavior really are.  A Gaussian distribution is simple 
analytically, but it's rarely the reality when all the complexities of 
binning and semiconductor process management are factored in.  Just how 
good can our analysis be if we don't know how component behavior will be 
distributed?  How much will our analysis be off if we assume a Gaussian 
distribution and do the analysis anyway?  We typically just don't know.

... all of which brings me back to most of the advice you've gotten 
already: it's about what you can prove, what you're willing to assume, 
and what risk you're willing to take.  Worst-case or band-based timing 
analysis will give you the most conservative answer, but it's an answer 
you can defend analytically based on a set of specs you can hold your 
vendors accountable to.  Statistical analysis will let you push the 
system faster, but components that meet their individual specs can still 
produce a system that fails.  Either way - neither band-based nor 
statistical timing analysis is a magic answer - they are simply 
analytical tools that you, as the designer, can apply to the problem at 
hand.  Like any tools, it's up to the user to understand their 
capabilities and use them accordingly.

Thanks for a great question,

Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com


>   
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field


List technical documents are available at:
                http://www.si-list.net

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: