( ESNUG 393 Item 10 ) -------------------------------------------- [04/25/02]
Subject: Three Engineers On Why Apollo Timing Differs From PrimeTime Timing
> I don't understand why the slack report that my ASIC vendor gives me via
> Apollo are different from what I get after analyzing it by Synopsys
> PrimeTime? I mean, Apollo does have all the information, how can it give
> results that are less accurate than PrimeTime?
>
> - Nahum Barnea
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Well, if you have done a pre-layout synthesis with wire load models, your
synthesis tool is only guessing the length (and capacitance) of nets.
This can differ a lot from the actual placement/routing of the design.
"I mean, Apollo does have all the information, how can it give
results that are less accurate than PrimeTime?"
It's the other way 'round. Apollo's results are more accurate, since
it has all the logical and physical information. PrimeTime only knows the
netlist, not the placement.
That's the problem of timing closure the EDA industry is attacking with
tools for physical synthesis.
I've seen pre/post layout mismatches on timing of 300% on our latest design.
With the standard ASIC flow: DC with WLMs, Apollo with length-driven P&R.
The flow is simply outdated for today's technologies...
- Lars Rzymianowicz
University of Mannheim Mannheim, Germany
---- ---- ---- ---- ---- ---- ----
From: jcooley@TheWorld.com (John Cooley)
There's two reasons for this, Nahum. The first reason is that you're
probably using PrimeTime post-synthesis but pre-P&R (i.e. with front-
annotated delays), while Apollo is giving you timing reports post-P&R.
Front-annotated delays are essentially "best guesses" based on your block
size (if you're just using Design Compiler). You can get better "best
guesses" early on in your design cycle if you use physical synthesis tools
like PhysOpt/Magma/PKS -- but there will still some timing differences
even using these tools because they use only placement info; not final
legal P&R.
The other reason why you're seeing timing differences between PrimeTime
and Apollo is that they use different timing algorithms within the tools
themselves. That is, even if you take post-P&R Apollo generated netlists
and time them in PrimeTime, you're going to find a small difference in
the timing delays each tool reports. (This difference is usually under
3%, so it's not something to lose sleep over, Nahum.)
- John Cooley
the ESNUG guy
---- ---- ---- ---- ---- ---- ----
From: [ The Man With One Red Shoe ]
John,
Keep me anonymous, please, if you decide to run this in ESNUG.
The major reasons for timing differences between Apollo and PrimeTime, in
addition to the ones that you described in your post, are:
1. Is the design latch or flop based? Flop based designs are trivial
from a timing analysis perspective and the differences between Apollo
and Primetime should be under 5% max (assuming that the same
parasitics etc are used).
On the other hand if the design is latch based, the devil that is
time-borrowing enters the picture. PrimeTime being a "pure" timing
analysis tool, does physical/greedy borrowing. On the other hand
from a design implementation tool's perspective such as Apollo, you
need to do some sort of time-borrow balancing to ensure that the tool
is not wasting cycles trying to optimize the snowballed slack at the
hard timing endpoint (output port or a flop data pin).
2. Propagation of constants across sequentials. Apollo HAD a "feature"
that would propagate constants across sequentials, while PrimeTime
does not. This could mean that a path reported by PrimeTime, is
not "seen" by Apollo.
3. Worst case slew propagation. PrimeTime used the worst case input slope
when reporting timing, not the actual slope. For example, if you have
a two input AND gate with inputs A and B and output O. For a moment
assume that the transition times at pins A and B are 5 and 10 units
respectively. PrimeTime used to (now they have a switch to control the
behaviour) always use the "10" units of trans time, when timing through
pin "A". So the timing analysis is kind of pessimistic. Apollo, I
think, uses the "5" units trans time for paths through pin "A" and "10"
for paths through "B". (I have some very preliminary indications that
the latest Apollo might have the same behaviour, but I have not fully
investigated this.)
4. For Apollo timing to match PrimeTime, a couple of other parameters
enter the picture. The Apollo timer does not use the ECS/Effective cap
model for computing cell delays (the old story of resistive shielding
etc) by default. For it to match PrimeTime, ensure that the "ntECSOn"
is set appropriately (the actual command might be slightly different.)
5. I think that Apollo uses AWE for interconnect delay while PrimeTime
uses something like Adaptive Arnoldi or something like that...
One last issue that a lot of designers tend to over look is characterization
range. For example if you are operating your cell outside of its
characterization limits, all bets are off. In general its, NOT a safe
assumption that the extrapolation is always linear.
I have seen Apollo behave kind of counter-intutively.
- [ The Man With One Red Shoe ]
|
|
