Static Timing Analysis vs Timing Simulation
Author Message
Static Timing Analysis vs Timing Simulation

I would like to get your opinion on the utility and frequency
with which designers use Static Timing Analysis vs utility and
frequency with which designers use Timing Simulation.

What percentage of the designs you are familiar with were amenable
to static timing analysis and functional verification ?

What percentage required timing simulation ?

What was the actual percentage of use of static timing analysis and
timing simulation ?

My interest in these answers is as an architect of simulators; i am trying
to balance features and resources applied to functional and timing simulation.

Please respond to me if you are answering the questions and i will
summarize and post.
If you are questioning the premise etc. you may choose to post to
the net.

regards,
ramesh

Some background:

Most processor design teams have a rigorous clocking scheme and
a static timing analyzer suited to that scheme. They accomplish
their verification by combining static timing analysis and
functional simulation (i.e., logic simulation that does not use
precise delays; such as zero delay on combinatorial elements, and
unit delay on sequential elements etc.).

Many ASIC design teams tended to use Timing Simulation with estimated
delays and post layout extracted delays on cells to verify their designs.

Because functional simulation tends to be faster than timing simulation
there has been a trend towards greater use of timing analysis.

However, asynchronous logic does not lend itself to static timing analysis,
so presumably designs that have some degree of asynchrony in them will require
timing simulation.

Definitions:

An Asynchronous Circuit is an arbitrary interconnection of logic gates.
There is no distinguished signal called clock, and external signals can
arrive at any time.

A Synchronous Circuit satisfies the further restriction that all cycles
(in the circuit graph) must be broken by clocked memory elements; the
clocking scheme must ensure that no event can propagate freely along a
cycle without being "stopped" by a memory element that is not actively clocked
when the event reaches its input. Further, setup and hold constraints of
the memory elements should be satisfied.

[definitions from Algorithms for Synthesis and Testing of Asynchronous
Circuits, by L. Lavagno etal]

Fri, 10 Oct 1997 03:00:00 GMT
Static Timing Analysis vs Timing Simulation
Here is the situation:
1) If your design is synchronous, static timing analysis can catch
basically all your timing problems, without having to write test
vectors.

2) If your design is async, you will need to use static timing analysis,
plus write a lot of test vectors to check timing.

In deep submicron (0.5u), routing delay is 50%+ of your delay, and you're
building 50k gate parts (at least).  So you need static timing analysis
to check your layout, and to save you years of writing test vectors.

I would say that as designs get bigger, designers are starting to move
towards static timing analysis more and more, and using synchronous
design to reduce probabilities of metastable states, and to simplify
the design.

In the long run, I expect that the design flow will be as follows:
- behavi{*filter*}simulation, to verify function
- synthesis to RTL code
- RTL simulation, to verify clock-cycle timing, using bus models purchased
from EDA vendors, and stimulus extracted from the behavi{*filter*}
simulations.
- synthesis to gates
- place & route
- static timing analysis
- use of scan techniques/BIST to generate production test vectors

This will minimize the amount of work put into stimulus
generation/verification.

Thu, 16 Oct 1997 03:00:00 GMT
Static Timing Analysis vs Timing Simulation
|> Here is the situation:
|> 1) If your design is synchronous, static timing analysis can catch
|>    basically all your timing problems, without having to write test
|>    vectors.
|>
|> 2) If your design is async, you will need to use static timing analysis,
|>    plus write a lot of test vectors to check timing.
|>
--

...I would qualify this further.  If you design has 1 and only 1
clock, static timing is fine for signoff.  If you have multiple
clocks, EVEN if one is a multiple of the other, there can be problems
crossing between the domains that static timing analysis won't catch,
if you've declared multicycle paths in any global way.

This is no kidding; full timing simulation during signoff found one
of these in one of our designs.  A path that was declared to be multicycle
wasn't really, and caused an X to pop up.

+----------------------------+----------------------------+

| 3COM Switching Division    | fx: 508-670-9014           |
| 85 Rangeway Road           | ph: 508-262-1420           |
| North Billerica, MA 01862  | (email or fax preferred)   |
| gender=M                   +----------------------------+
+----------------------------+

Tue, 21 Oct 1997 03:00:00 GMT
Static Timing Analysis vs Timing Simulation

Quote:

> ...I would qualify this further.  If you design has 1 and only 1
>clock, static timing is fine for signoff.  If you have multiple
>clocks, EVEN if one is a multiple of the other, there can be problems
>crossing between the domains that static timing analysis won't catch,
>if you've declared multicycle paths in any global way.
> This is no kidding; full timing simulation during signoff found one
>of these in one of our designs.  A path that was declared to be multicycle
>wasn't really, and caused an X to pop up.

Without knowing anything about your design, I would say that the big
problem is declaring multicyle paths in a global way, not the fact that
there are multiple clocks.

We just finished a design that we analyzed with MOTIVE that has
multiple clocks.  By telling MOTIVE that the clocks have enormous
skew between them, MOTIVE will show all clock region boundaries
as violations.  You can then go in and check all of these boundaries by
hand to make sure you've taken care to synchronize them.

MOTIVE is an exceptional tool in this regard.  I don't know how easy
the process would be with other static timing tools.

Keith Vertrees

Tue, 21 Oct 1997 03:00:00 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages