( SNUG 03 Item 15 ) ---------------------------------------------- [05/14/03]
Subject: PrimeTime, PrimeTime-SI, Sequence ShowTime & NoiseIT, Cadence Pearl
THE GOOD SON & THE BAD SON: No news on the plain PrimeTime front. Synopsys
owns 98.3% of the $26 million static timing analysis market. The multitude
of happy PrimeTime customer comments explain why. Yea, there are complaints
that PrimeTime needs to run on top of the Milkyway database, needs more
capacity, more speed -- but the overall tone is that users *like* PrimeTime.
In stark contrast, the user comments start to turn ugly when they switch to
talking about PrimeTime-SI. You get the sense that some customers liked
PT-SI while most others definitely didn't. It's not bugs that's bothering
them as much as a general disappointment with PT-SI itself. Too many
complaints about the wild goose chases PT-SI's pessimism and inaccuracy
makes users go through. (Ouch.)
"PrimeTime proved very useful in the last ASIC project that I was on.
It would have been even more useful if my ASIC vendor's libraries
hadn't changed monthly."
- Aaron Byman of Elektrobit Finland
"PrimeTime is the basis of all we do. It works very well, no problems
with the last device, however the runs take a while to perform, about
5 to 8 hours to load for some of the 1 million gate blocks, and 30 min
to 2 hours each time we want a 'report_timing'. And if you change
something (for example: set false path) it can take about 1/2 the load
time again to re-calculate. So, ironically, the timing of the use of
the timing analysis tool is critical."
- Bob Lawrence of Agere Systems
"PrimeTime:
For normal STA the performance and capability in the tool today is
good, especially the latest release on Linux. We need to get full
support for the latest features in the SDC-files, too. And support
from 3rd party tools so we can use it.
OCV based PrimeTime will need to be improved with respect to accuracy,
runtime and specially memory consumption (which can be huge.)
A very useful feature would be to support multiple modes/corners
reports. Even if you have to run the analysis in each mode/corner
there should be summary reports that show all violations in the
design in all corners. Today most teams develop there own scripts
for this, which means they all look different."
- Torsten Larsson of Texas Instruments
"We use PrimeTime very heavily and so far we don't have any major
problems, some hickup here and there but nothing serious. I myself
rely heavily on PrimeTime to check timing for all the test modes in
any particular design (scan, mem BIST, logic BIST, JTAG...)"
- Amar Guettaf of Broadcom
"It would seem that Synopsys has made significant improvements in the
performance of PrimTime. This is good, because STA is a time killer
in big designs."
- [ An Anon Engineer ]
"Definitely Primetime is the most useful tool for timing analysis. It's
a pity that the other Synopsys backend tools (PhysOpt, Astro) are not
100% script/constraints compatible with PrimeTime. PT seems to be
always ahead in this. We develope scripts/constraints using PrimeTime
only to later find that we have to modify the scripts (slightly,
though) to run in other tools. I'm referring to PhysOpt 2002.05,
and Astro patch3, Dec 2002 release."
- Santiago Fernandez-Gomez of Pixim, Inc.
"The SPF interface is slow in PrimeTime. We extract SPF using Star-RC
and wait for SDF for 4 hours on Solaris. The same function in Apollo
takes 20 minutes. Linux greatly improves this. Later versions of
PrimeTime may also improve this. However, we often slowly adopt new
versions of PrimeTime because we find bugs and non-backwards
compatability issues. We have not tried PrimeTime-SI.
- Craig Farnsworth of Cogency Semiconductors
"PrimeTime is the standard. Is there really any other player in that
market?"
- [ An Anon Engineer ]
"Thumbs up for PrimeTime."
- [ An Anon Engineer ]
"Is there an alternative to PrimeTime? Since I don't know of any
alternative, I guess I would have to rate it as useful. There's no
way I would want to do a chip without static timing analysis. I
guess I could compare PrimeTime to IBM's Einstimer. I don't really
prefer one over the other. Handling clock dividers is easier in
PrimeTime. I don't trust the clock gating checks in Einstimer.
Setting up DDR output timing seemed to be easier in Einstimer. But
basically, they both get the job done. And they both have warts,
just in different places."
- Matt Weber of Silicon Logic
"PrimeTime vs. Cadence Pearl. Despite that they calculate differently
with the same inputs (huge diff for timing checks) I would say that our
designers prefer Pearl since it has an easy tracing. The bad thing is
the licensing."
- Bengt-Erik Embretsen of Zarlink Semiconductor
"Is there other choice besides PrimeTime? I think PrimeTime kills its
competition better than DC. Cadence stopped any new R&D in the past
5 years. Mentor does not any thing in this area."
- [ An Anon Engineer ]
"PrimeTime is a great tool. Easy to use if you are familiar with DC.
Best of all, we are starting to see great correlation between Astro
and PT. I understand the latest release of Astro uses the PT engine.
No surprises here.
No experience with PT-SI, yet."
- Roberto Landrau of Mitre
"We depend on PrimeTime and it does a good job."
- Lance Flake of Maxtor
"We do not use PrimeTime in our flow. No problems so far."
- [ An Anon Engineer ]
"Like it or not, PrimeTime is the only game in town that has any support
going forward. Cadence is thrashing trying to replace it's failed
Pearl STA engine with something it's acquired, but their roadmap here
gets a bit vague very quickly. Synopsys does need to keep it's eye on
the ball, and keep capacity and performance where it needs to be."
- [ An Anon Engineer ]
"We have seen PrimeTime issues lately which have caused us to believe
that it has some issues going forward. Run times are also very high."
- Amit Sanghani of Nvidia
"PrimeTime is fine but quite a few times I have found my Verilog sim
results not corroborating with my STA results."
- [ An Anon Engineer ]
"PrimeTime is definitely useful. PrimeTime-SI is too pessimistic to be
practical. Noise propagation was missing for a long time. Synopsys
finally fixed it with all these new library characterization
requirement for noise. But it will be a while before all these new
stuff is put into .lib's."
- Wilson Chan of Qualcomm
"For PT-SI, the timing windows work well, but, especially when strong
and weakly driven nets are close, there may be glitches induced in the
weakly driven net that can affect circuit behavior."
- [ An Anon Engineer ]
"Not very impressed on PrimeTime-SI."
- John Zhang of Broadcom
"PrimeTime : very useful.
PrimeTime-SI: trash, should be abandoned."
- Tie Li of Applause Technolgy
"PrimeTime-SI is useful. It's uncovered significant cross-talk effects
at AMCC. I actually only heard about this second hand. I know that
PrimeTime-SI found enough cross talk problems for AMCC to buy it and
make it manditory in their process flow."
- Tomoo Taguchi of Hewlett-Packard
"I like both PrimeTime & PrimeTime-SI."
- [ An Anon Engineer ]
"PT-SI is not really needed if you've a preventative approach to XTalk.
In this case PT-SI doesn't really apply until you get to very high
frequencies."
- Gregg Shimokura of STMicroelectronics
"PrimeTime-SI has the same issues as all other point tools. Analysis
is great, but if it can't make the fix, what's the point? If they can
integrate PrimeTime-SI deeper into Astro where the change is made,
THEN it's a tool of great value."
- [ An Anon Engineer ]
"PT-SI needs a better solution for IR drop analysis. (Currently,
there's no support for IR drop effects on VSS; only VDD drops are
supported.) I talked to a number of PT-SI R&D folks at the San Jose
SNUG this year, and they mentioned they had no plans to include VSS
rail changes into the analysis either. They were still in a 'touchy-
feely' mode: one of them asked for a show of hands to ask people if
rail voltage effects were important to analyze! With threshold
voltages and supply voltages getting reduced with each new (smaller)
technology node, chips are going to be even more susceptible to both
DC and AC effects of IR drop.
Another problem users (at least those using external libraries) are
going to run into is getting the libraries characterized properly to
take advantage of PT-SI's capabilities. We all need to work with the
library vendors and get this done."
- Neel Das of Corrent Corp.
"Used PrimeTime-SI in our flow. SI is getting more an more a must for
new technologies (0.13 um and below) to reflect all those awful DSM
effects (OCV, etc.). PrimeTime-SI runtimes are bad. Useful? I mean,
what's the alternative for ~0.1 um technologies? Trash? Yes, a bit,
because it's getting more and more difficult to model the DSM reality
within the STA algorithms. PrimeTime-SI results differed +/- 50% from
our TITAN simulations."
- Markus Schutti of Infineon
"PrimeTime-SI is slow and out of date technology. Try Sequence's
ShowTime. More accurate and less pessimistic SI analysis. We have
TO several high performance chips using this TA tool. They all work
at speed."
- [ An Anon Engineer ]
"I also use Sequence FormIT, NoiseIT for timing closure and timing
optimization. I have not used PrimeTime to be able to compare.
However I am very happy with the Sequence timing tool. It seems very
robust to me. Their noise analysis is also OK."
- Srinivas Jammula of Procket Networks
"PT-SI, much like STA in general, is designed to bound the impact of
coupling on delay. It can give very very pessimistic results.
The first step in PT-SI is to do some electrical and structural
filtering. Without aggressive filters, run times for PT-SI can be
ridiculously long (e.g., for a block where lumped analysis takes
us 5 minutes, very conservative electrical and structural filtering
takes 2 hours and more aggressive filtering takes 20 minutes). PT-SI
users need to be very careful when tuning these filtering parameters
to avoid missing corner conditions.
PT-Noise saves a bunch of run time and file I/O since it no longer has
to write timing windows etc. for tools such as Celtic or Pacific (or
whatever fancy names Cadence uses for these ex-CadMOS tools now). Pre-
characterization is somewhat a pain, but this has enabled us to use
some novel methods for measuring noise thresholds etc. that non-
characterization-based approaches lack."
- [ An Anon Engineer ]
"PrimeTime is quite useful. PT-SI is okay; we think it's probably worth
a look now, as it has glitch noise analysis. The other thing is a flow
from PT-SI to Astro/Apollo to fix crosstalk violations would be quite
useful. I believe this feature might be available soon."
- [ An Anon Engineer ]
"PrimeTime-SI:
The runtimes are long. Its timing reports with delta delay are OK, but
when you start to look at details there are severe limitations to the
reports. PrimeTime-SI is also too GUI oriented.
Examples when you look at aggressors you need to focus on one net, you
can't get all aggressors for a path, all paths one victim is in, the
contribution from all aggressors on a path, etc.
To me it feels OK to use PrimeTime-SI for a design with few cross-talk
violations. If you have hundreds or thousands, a GUI is not useful and
there will be a lot of scripting to do.
We need support in how to fix the problem."
- Torsten Larsson of Texas Instruments
"We use PrimeTime, and we verify timing from our vendor's SDF. I don't
think we've had any involvement with PrimeTime-SI."
- [ An Anon Engineer ]
"Use PrimeTime all the time. Backend group did a tape out that had SI
problems. Ended up using a combination of tools one of which was
PrimeTime-SI."
- Ross Swanson of Flextronics
"PrimeTime is very useful. I haven't been able to use PrimeTime-SI.
It could be useful if we could setup the flows to get the SPEF data
that it needs."
- [ An Anon Engineer ]
"Have not used Primetime-SI, but will have to investigate. At present
our team is looking at Cadence's Celtic."
- Alan Duffy of Motorola
"We did use PrimeTime-SI on our latest design (0.18 um). It did point
out some problems, which we fixed. We were pretty happy with it."
- Tom Thatcher, ex-Agilent and looking
"I'm happy with PrimeTime. So far, PrimeTime's numbers are trustworthy,
much better than that from Astro/PhysOpt.
But PrimeTime-SI needs a lot of improvement on accuracy. PT-SI can
only indicate noise spot give a rough timing with crosstalk effort
factored in. But we can NOT use PT-SI to sign off. Especially for
the hold time, PT-SI's rough/pessimistic report number make us crazy.
We see a thousand small hold violation, but we decide to ignore them,
because PT-SI is very pessimistic. What are you going to do with
100 psec hold time violation in a PT-SI report? If you want to fix
them, there are a thousand waiting for you.
By talking to the Synopsys PT-SI R&D group, it again shows that their
algorithm is too pessimistic. If two clock domain are async to each
other, then they assume infinite timing window. This is ridiculous.
If one of the clock domain is 20 MHZ, the other is 250 MHZ, during
50 nsec, the 20 MHZ clock only switch twice, but PT-SI algorithm,
consider it switching all the time during this 50 nsec. Can this
algorithm be used in noise signoff tool?
Only one question left, is there any plan for Synopsys R&D to make
PT-SI a signoff tool? Or shall we start to evaluate another tool?"
- Ying Gao of Qualcomm
|
|
