( SNUG 04 Item 14 ) ---------------------------------------------- [08/11/04]
Subject: Synopsys PrimeTime-SI vs. Cadence CeltIC
IS THERE A SHIFT COMING? Looking at the 2 year old Dataquest numbers, the
obvious leader is Cadence CeltIC.
Dataquest FY 2002 Signal Integrity Analysis Market (in $ Millions)
Cadence CeltIC #################### $20.1 (57%)
Sequence ##### $5.0 (14%)
Synopsys PrimeTime-SI #### $4.2 (12%)
Quantic EMC ### $3.2 (9%)
others ### $2.8 (8%)
But again, these are 2 year old numbers. Why I'm obsessing on this is that
an awful lot of the user comments I received in this survey harped on the
fact that they want to use PrimeTime-SI because it's so closely connected
to the monopoly (97% market share) PrimeTime tool. The other interesting
thing is that Synopsys now has PT-SI working now. (Earlier surveys were
filled with users complaining about how broken PT-SI was. No so now.) We
could be seeing the beginning of a market shift in this niche. Or not.
9.) How about IR drop tools like Synopsys AstroRail, Magma BlastRail,
Cadence Simplex VoltageStorm? Which do you use? How about noise
tools like PrimeTime-SI vs. CeltIC vs. Sequence NoiseIT? Who is
ahead? Who is behind? Which do you use?
None of them good enough for analog transistor level.
- [ An Anon Engineer ]
We use AstroRail and CeltIC. PrimeTime-SI looks like it is gaining
share and, more importantly, correlating better with SPICE. At some
technology inflection point (perhaps 90 nm, perhaps smaller), we will
want to have a tighter integration of SI effects in STA. Exporting
timing-windows to/from CeltIC is time-consuming, and, more importantly,
CeltIC won't honour detailed exceptions that PrimeTime does, making
its Xtalk pessimistic. I think PrimeTime-SI will win in the long run
so long as people are signing off STA with PrimeTime...
- Andrew Bell of PMC-Sierra, Inc.
We have used PrimeTime as our static timing signoff engine for our COT
flow for the last 4 years in both 0.13u and 0.18u technologies. Our
chips range from 5 to 15 million gates with both digital and analog
content. Our chips have very detailed clocking, and we have used
the multi-clock feature of PrimeTime to combine many runs into a single
run. Version 2003.12-SP1 has been able to handle designs of ours fully
flat with 1.2 to 2.0 million instances at the expense of runtime and
memory usage.
For the sake of run time, we have utilized ILM models at the top level
of our design. But, in conjunction w/ ILM runs, we run fully annotated
SI timing runs to verify we have covered all aspects of crosstalk in
our design. ILM models are useful, but we have found several corner
cases that are not covered with the ILM. An example is a timing path
between two different input clocks of the block (a reg to reg data
transfer across clock domains). In ILM generation, this path is removed
as it is fully contained within the block. However, if the clock
latencies are not properly analyzed in the block run, this path could
easily be missed without a fully annotated run.
Another issue with ILMs is how they currently store coupling caps. We
don't use this feature as we find that aggressor timing is stored based
on the block setup, and is often missing the full information from the
chip level (ie, multiple clock propagation, clock latencies, etc). A
fully annotated run is needed to see these effects. We have used ILMs
for chip level noise analysis and crosstalk reporting as these tasks
take too much time in the fully annotated runs.
On the noise front, we switched over to using PT-SI for noise last year.
We have combined our crosstalk runs with our noise runs into a single
run. Once past our initial library characterization issues, we have had
success with the noise results from PT-SI. We have completed designs
with PT-SI noise using strict DC margins, as well as propagated noise.
In the last few releases, PT has improved capacity and run time
dramatically. An area we want to see improvement on is the handling of
crosstalk/noise effects in multi-mode runs. Currently, there are few
controls to define "exclusive" clocks that are defined in the same run
for the noise and crosstalk effects.
- Todd Hawes of AMCC
We are actively using Primetime-SI for STA sign-off in our .13 micron
ASIC flow.
Having previously used PrimeTime, PT-SI did not require any significant
changes to our flow - same netlist, libraries, SDC files. Obviously the
parasitic extraction (StarRC-XT) had to include cross-coupling caps.
There were some filter settings to define. These were supplied by
Synopsys and we didn't need to modify them. Other than this it was only
necessary to add a small number of commands to our existing PT scripts
to enable crosstalk analysis in order to get PT-SI working.
Runtimes are obviously longer than PrimeTime, but when run on a 64-bit
Linux platform have not significantly impacted timing closure. PT-SI
uses an iterative approach to STA, with violating nets being reselected
for analysis on each pass. The greater the number of violating nets,
the longer the runtime. One design, in excess of 400 K instances, took
7 hours to generate two timing reports (each with 3 internal iterations)
at slow PVT corner, but only 2 hours at fast PVT corner.
The timing reports show clearly where crosstalk is hitting the critical
paths. Initially we used the GUI to 'click' through the database to
identify specific aggressors for a given victim net. More recently, we
generate reports identifying the aggressors' impact on a victim
(coupling, timing windows etc.).
The only real issue we have with using PT-SI currently is the fact that
we have not achieved the degree of crosstalk-delay correlation between
PT-SI and Magma which we would like. There's a whole new learning curve
for the understanding of the intricacies of the two tools' crosstalk
analysis (and crosstalk delay analysis in general).
There is currently no ability to feedback repair information to our
Magma P&R flow. I believe other STA tools have the ability to output
an ECO script. We rely on manual/scripting methods to fix the problems
reported by PT-SI, ultimately extending our closure time due to
iterating around the ECO/PTSI loop.
- Stuart Vernon of PowerVR / Imagination Technologies Ltd.
With PT-SI in the beginning the update_timing runtime was anything from
10 hrs to infinity. But thanks to the excellent support from a Synopsys
AE we found the correct switches and fixed few constraint issues and the
runtime was down to 6 hrs. Due to memory usage (6+ Gb), I was forced to
use 64-bit V-2003.12 for Solaris. This was still way too much. With
one mistake in the constraints you loose one working day.
In the beginning of the year I got one 64-bit Linux and with the 64-bit
PT-SI V-2003.12-SP1-3. My update_timing is now down to 2 hrs. This is
already useful; you can do several runs during one day. The memory
usage has not decreased too much, just few percents. This is something
that concerns me as my next design will be 3 times bigger.
- Pasi Tukiainen of Nokia
I have been using PT-SI for 1.5 years now on our communication chips
(.13 micron), starting from version 2002 through 2003.12. We use PT-SI
for timing sign-off, not necessarily because it is the most accurate;
instead we see its perceived pessimism as giving us more inbuilt timing
margin. Here are some of my thoughts:
- PT-SI is an extension of PrimeTime, so the basic setup is easy to
transition to. Additional effort is needed to correlate the
timing/slew with other tools we have, and to refine the settings
in PT-SI to balance between accuracy and runtime.
- Capacity. We have run chips above 5 million gates through PT-SI.
Its capacity is comparable to CeltIC.
- Runtime. I think PT-SI's runtime is decent. It has improved in
recent releases, and is helped by Linux/Opteron platforms. Turning
on the crosstalk delay analysis in PT typically doubles the total
runtime of the tool.
- I think Scalable Polynomial Delay Models are required for PT-SI when
IR drop is taken into consideration, and characterization of this
type will take much more effort. We would prefer such libraries to
be qualified and directly provided to us by library providers.
- Accuracy. In crosstalk delay, PT-SI is on the pessimistic side.
It's min-max timing windows also seems a bit pessimistic as compared
with slot-based windows available in some other tools.
We had some problems with Clock Reconvergence Pessimism Removal (CRPR)
modeling in v2003.03/06, but this is supposed to be fixed in the latest
release. PT-SI's biggest strength is its ease of use as an extension to
PrimeTime. Its biggest area to improve is accuracy; it needs to be less
pessimistic. PT-SI's recent inclusion into the TSMC reference flow 5.0
is giving it improved credibility. We will continue to monitor its
progress and other solutions in the market.
- [ An Anon Engineer ]
Currently evaluating IR tools. On the xtalk delay side of things
PrimeTime-SI lines right up with SPICE. Magma is but a few percent
away. Currently thrashing on a design that was taped out with CeltIC
and PrimeTime-SI shows massive failures. Given we trust PrimeTime-SI,
I wouldn't put as much faith in CeltIC.
- [ An Anon Engineer ]
PrimeTime-SI was our sign-off tool, but I am now fielding requests for
information from people trying to use CeltIC.
- [ An Anon Engineer ]
We went through a evaluation of PrimeTime-SI for noise during latter
part of 2003. It took a while as it has been a learning curve to
incorporate static noise as part of the PrimeTime flow. Most of the
issues we dealt with were setup related with PrimeTime-SI. Once we got
the right setup, we were happy to observe that PrimeTime-SI noise
numbers correlate reasonably to Avanti HSPICE. The accuracy we saw
was within 6% of HSPICE. We observed:
- PT-SI had good performance and memory usage. Much improved with
recent 2003.12 release. But expect 2X and up on runtime difference
between PrimeTime and PrimeTime-SI with noise analysis.
- it fit seamlessly in the PrimeTime flow
- the noise library generation by third party vendor was a hinder.
This should be provided by Synopsys as a utility. Furthermore,
QA'ing a new noise library is an extra assurance step that needs
to be considered. (Actually they have recently provided us with
such a utility and we are now evaluating it.)
- chasing down the aggressors and their contributions to the noise
is not straight forward. A series of get_attribute, report_net,
get_attribute commands are needed to get to the desire info.
- potential latch violation due to glitch propagation is not (yet)
implemented. This option is useful for pruning down non-harmful
noise violations.
To do this eval, our library group generated the noise table for a
0.15 um library. We found:
- your library units must match between time/capacitance and
voltage/current.
- the Synopsys Library Screener can be used to verify that the
characterized library meets the basic requirements for post-layout
accuracy in PrimeTime and PrimeTime-SI. (The Synopsys Lib group
gave us the screener.)
- the Synopsys Noise Correlation kit can be used to verify the noise
accuracy on a library cell, especially on a newly generated noise
library. (This kit was provided by the PrimeTime-SI group.)
- your netlist must be clean of any unnecessary bus keeper cells.
- any nets that might undergo cap or resistance characteristics
change during the fab process need to be removed from the noise
analysis.
- all design ports must have realistic transition time constraints.
- your generated clocks must also have realistic transition times
defined.
Additionally due to the fact that PrimeTime-SI is a STA approach, any
violated noise net in the fabricated chip would need to be validated
using vectors. These vectors must show the same victim and aggressor
relationship as in a final PrimeTime-SI run with the same conditions.
- Ken Wong of Conexant
We use CeltIC for noise analysis and believe that they have the right
solution. The next in line is Sequence. We use VoltageStorm, and are
unable to comment further details.
- Santhosh Pillai of Parama Networks
I'm a new PrimeTime-SI user. I started to do some real work with the
tool about 4 weeks ago. Here are my first impressions.
Just to give you some background. I'm a PT user but have not used PT-SI
before. I have however done SI analysis with an in-house developed tool
that we have been using up to now. I'm currently responsible for the
physical implementation of a subchip from netlist to layout. It is
fairly small, about 200 Kgates and is done in a 90 nm process node.
PT-SI is integrated into our design flow -- what this means is that I just
have to run a couple of make targets in order to generate a complete
setup file, with all the reselection- filtering- and exit criterias, and
a PT-SI command file that will execute the analysis. All I need to
provide is the PT constraints, the netlist and a clock grouping file.
Since the tool is integrated in our flow getting started was not a big
issue.
The key benefits as I see it is that PrimeTime-SI is fully integrated
with PrimeTime, which also is our signoff tool. This makes it easy to
get started and you don't need to learn a whole new environment nor
convert data between tools. Our old flow was executed in two steps,
first we generated timing reports in PT and these where then processed
by another tool; running PT-SI is easier and smoother.
Runtimes have been OK, this is a very small block so that is not a
limiting factor. Runtimes are between 0.5 to 1 hour CPU-time depending
on the performance of the machine, 0.5 hour is using a fairly powerful
Linux box and 2 iterations (3 timing updates). SI memory consumption
has been ~850 Mbytes which is 2.5X compared to normal STA.
So far, my biggest criticism of PT-SI is that I don't like the way
the clock grouping works. I started off by defining all the clocks I
have in the subchip as synchronous but forgot to define the virtual
clocks I use to constrain my I/O's. PT-SI then generates false paths
between the virtual clocks and all other clocks leaving my I/O paths
untimed! I would prefer if the tool gave some warning that all the
relations between the clocks are not defined. It could then treat all
clocks not covered in the set_clock_group statements as asynchronous
from an aggressor victim point of view but still time the paths to and
from these clocks. By doing it this way the worst case would be modeled
instead of not timing them at all with the risk of missing real
violations if logs are not properly read. I want to have full control
of the false paths set in the design and don't like the idea of leaving
that to the tool.
I have also played a little bit with its "what if capabilites" such as
get_alternative_lib_cells and report_alternative_lib_cell. This gives a
quick indication of what a potential fix could buy you timing wise.
With the save_session capability it is easy to fire off a number of runs
in parallel in batch mode and then pick them up and do some analysis in
interactive mode once a problem is spotted in the reports, without
having to rerun the session. This was not possible in our old flow.
- Magnus von Bromssen of Texas Instruments
For PrimeTime-SI the improvement we see is in the 3X range. Also uses
far less memory (2-3X reduction) which means we can run it on cheap
Opteron boxes instead of expensive Suns or Itaniums.
For noise we use PrimeTime-SI, which with the current performance
improvements mean that we can run our entire chip with SI analysis
in less than 3 hours on an Itanium.
- [ An Anon Engineer ]
Cadence has significant lead with CeltIC. PrimeTime-SI is still a
non-starter due to model unavailability both for commercial and
home grown IP.
- [ An Anon Engineer ]
For SI, I use CeltIC - mixed feelings.
- Gord Allan of Carleton University (Canada)
We use PrimeTime-SI for noise-induced-delay analysis; CeltIC for
noise-induced-glitch analysis. Relatively few characterization tools
available to produce the data necessary to use PT-SI on glitches.
Working towards that as low-priority. CeltIC is getting the job done,
so little motivation to work quickly on PT-SI noise. Also, still
using internal noise analysis tools left over from before there was a
CeltIC or a PT-SI. EDA vendors were at least one process generation
too late with their solutions (as per usual).
- [ An Anon Engineer ]
|
|
