( ESNUG 397 Item 3 ) --------------------------------------------- [07/24/02]
Subject: ( ESNUG 393 #10 ) Why Apollo Timing Differs From PrimeTime Timing
> 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.
>
> - [ The Man With One Red Shoe ]
From: William Natter <wnatter@nortelnetworks.com>
Hi John,
PrimeTime has a variable called "case_analysis_sequential_propagation" that
allows constants to propagate across sequentials. Our methodology around
PrimeTime primarily uses SDF annotation. Of course, I would prefer full OLA
support in PrimeTime. (OLA should reduce the gap in the timing between
PrimeTime and Apollo, by the way).
At the beginning, PrimeTime was developed without modal and hierarchical
analysis in mind.
1) Modal analysis:
By modes, I mean a set of constants, constraints and exceptions
that reflect the typical state of a given circuit while performing
a significant or important function. This definition differs a
lot from the modes available in PrimeTime. This requires us to
develop a whole methodology to make sure that every mode is
completely analyzed. Lately, the report_analysis_coverage command
has tried to provide a long-awaited audit capability:
- the command only generates files, but we prefer manipulating
objects within the memory and then spit out the results;
- the command only covers (obviously) the current mode; and
- it is not possible to display all the disabled paths and
explain in detail where and why some arc or pin has been
disabled (Synopsys is working on providing more explanations)
2) Hierarchical analysis:
STAMP models, Extracted Timing Models (ETMs), Quick Timing Models
(QTMs), and Interface Logic models (ILMs) are attempts at making
this analysis possible. Extracted models (finally in the .lib
format) and ILMs work for us, with the condition that one of us
pays a lot of attention in creating these models in order to obtain
good accuracy.
PrimeTime still insists on reporting transparent latch (as opposed to
flip-flops) setup with respect to the opening of the latch.
After all this bad mouthing, I must admit that PrimeTime has seen
significant improvements. In particular, I have in mind the latest
release providing data-to-data checks (excellent for making sure that
buses are aligned, I'm sure designers would love to have that in DC),
multiple clocks per pin, and clock tree reporting capabilities.
- William Natter
Nortel Networks Nepean, ON, Canada
---- ---- ---- ---- ---- ---- ----
> 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.)
>
> - [ The Man With One Red Shoe ]
From: Srinivas Kakumanu <kakumanu@time2mkt.com>
Hi, John,
I don't think Apollo propagates the input pin slew to the output pin.
Normally output pin slew of any cell depends on the input pin slew
because of which output is transitioning. Please don't club this issue
with worst slew propagation. Apollo considers slew on input pin in
calculating cell propagation delay. But it may not be propagating the
input slew to output slew. In that case, Apollo always sees a ideal
transition at the orginating point of any net which is NOT true and then
degrades slew depending on the RCs and calculates slew at the destination
point of the net which are input pins of various cells the net is connected
to. But I guess PrimeTime propgates the input slew to output and hence
the diference. This difference you'd see only when you annotate SPEF,
DSPF, RSPF etc. If you annotate SDF files in PrimeTime, you'd NOT see any
difference in the value of timing but you might end up seeing more paths
(or less paths depending on the understanding of these two tools on
constant propagation) disabling feedback loops.
- Srinivas Kakumanu
Time2mkt
---- ---- ---- ---- ---- ---- ----
From: Robert Norton <robert.norton@sun.com>
John,
In reference to the Apollo timing differences with PrimeTime in ESNUG 393.
Make sure Apollo is pulling an Advanced Timing Driving license (ATD) and the
Table Look up Model is set correctly. If these are set correctly I agree
with you on the 3% margin of error, usually on the optimisitic side. If
the ATD is missing or the TLU is wrong in someway, you can get some strange
times.
- Robert Norton
Sun Microsystems
---- ---- ---- ---- ---- ---- ----
From: Juancarlos Diaz <juancarlos.diaz@massana.com>
Hi John,
I would like to add my small contribution to the discussion about the Apollo
and PrimeTime timing engines. In one of our ASIC designs, we had the
opportunity to discover several circumstances in which the Apollo engine
was far from the PrimeTime values. The main difference between Apollo and
PrimeTime is that the Apollo language to describe timing constraints (TLF)
is very different to the PrimeTime one (either dc-shell or tc-shell), and
not only in terms of different commands, but also in timing concepts: many
of the PrimeTime constructions are almost impossible to be translated to
Apollo (I had to fight against this for a couple of months). In addition to
this, I discovered that Apollo case analysis does not work (this is totally
true for the version I used, when setting a given case analysis, there were
*real* paths that were not considered when reporting timing), so I decided
to switch it off, which led me to have different sets of TLF files
acccording to the circuit mode (functional, test, ...), and to lose 10
pounds (I don't recommend this diet, it is too painful).
Apart from the different way of defining timing constraints (something that
I consider key, but let's forget this), we discover at a very dramatic point
(1 week to tape-out) that when the backannotated netlist has a strong buffer
(x20) connected to a very large distributed capacitance (a tree of RC's),
Apollo sees the whole structure as a single resistance and capacitor, and
the reported delay is far from the PrimeTime (distributed) calculation:
PrimeTime reported two to three times more delay (screwing up our timing
closure). We reported that to the Avanti support, and they were very
surprised ("This is the first time I've see something like this.") After
that, we decided to avoid the use of very strong buffers and limit the wire
length for future designs (Obviously we relied on the PrimeTime figures.)
My conclusion is that for straightforward designs (i.e: no case analysis, no
long wires driven by strong buffers, no complicated clock distribution ....)
Apollo keeps the pace, but when things start to get cumbersome, PrimeTime is
still a bit ahead.
- Juan Carlos Diaz
Massana Technologies Madrid, Spain
|
|
