( SNUG 02 Item 14 ) -------------------------------------------- [ 5/15/02 ]
Subject: PrimeTime, PrimeTime-SI, Avanti Mars-Xtalk, Sequence, Simplex
LIFE IS GOOD: Last year Aart leaked the PrimeTime-SI story in SNUG 01 #20
in his keynote address. Since then, it's had the usual thumbs up & down & up
early acceptance feelings from the beta users. There's nothing quite like
expanding one's 97% market share Static Timing Analysis monopoly is there?
Dataquest FY 2000 Static Timing Analysis Market (in $ Millions)
Synopsys PrimeTime ########################## $26.0 (97%)
Mentor SST Velocity # $0.6 (3%)
Cadence Pearl 0.0 (0%)
"I'm getting good reports from the field on PrimeTime-SI. They seem to
have a good grasp of most of the SI analysis problems. The trouble
with SI tools is that they tend to focus on one aspect of signal
integrity. Those one trick pony tools are going by the wayside."
- Gary Smith of Dataquest
"PrimeTime is rock solid. It's GUI is a joke, but GUIs are anyways.
Haven't tried SI."
- Kevin Hubbard of Siemens
"PrimeTime Technology Update (New in 2002.03):
+ Multi Clock Propogation allows timing of multiple clocks in a
clock domain (similar to clock phases in IBM Einstimer).
+ Data to Data Timing Checks (also similar to Einstimer).
+ Clock Network Timing Reports.
+ Interface Logic Models (ILM) and Extracted Timing Models (ETM).
+ ILM are better at modeling since they keep first input, last
output FF in design.
+ ETM better when interfacing with 3rd party tools."
- Kent Ng of Microsoft/XBox
"Paul Zimmer and Andrew Cheng of Cisco did their presentation on timing
DDR interfaces in PrimeTime. They showed lots of PrimeTime tricks
along the way, which made this an effective part 2 for Paul's award
winning PrimeTime paper from last year."
- Bob Wiegand of NxtWave
"We use PrimeTime to sign off. It is still the most reliable tool out
there. We did a lot of comparison with Ambit and the results were
sometimes quite different. However the paths we extracted & simulated
in SPICE showed a incredible match between PrimeTime and SPICE."
- Karl Kaiser of Resonext
"Paul Zimmer (Cisco Systems) said that he was doing yet another
PrimeTime paper. We talked about PrimeTime-SI and the Sequence tools
and PT v2002.03 beta. He said that he really appreciated the new
ability (v2002.03) to pass multiple clocks through a MUX in PT. He
also said that he still uses a bottom-up compile strategy (with no
compile at the top level as WLMs are especially bad there). He has
an old set of scripts that supports this methodology."
- an anon engineer
"I use PrimeTime a lot and, for the most part, I like it. It has it's
issues, but, overall, it's a pretty good timing tool. The 64-bit
version is really fast.
The GUI has been improved in the last year or so and now the user gets
to see what is happening during a long run. Path exceptions are
relatively easy to assert and the case_analysis has been fixed (doesn't
propagate backward anymore) so static signals can be modeled. There
are a lot of nice 'get' and 'all' commands so it is easy to identify
and make lists of parts of interest in the design. In particular, the
'report_transitive_fanin (fanout)' commands are a great way to identify
whole cones of logic. And the user can define and set attributes on
pins, ports or nets which is handy to use in a TCL script for many
different reasons.
Tho some nice new features have recently been added for latch-based
timing, unfortunately, it still can't handle non-overlapping (split)
clocks or cut 'path sets' (yeah, yeah, I know, that is a *dynamic*
operation and this is a *static* timing tool). Maybe someday ..."
- Tamar Barry of Honeywell Space Systems
"The PrimeTime-SI stuff still assumes that every signal is in transition
which may or may not be the case. You could be over designing to get
rid of all PrimeTime-SI warnings, but as geometry's get smaller this
will become a larger issue. It nice to have the Timing Analysis and
the Signal Integrity together."
- Tom Tessier of t2design
"Many of the Primetime-SI papers at this year's SNUG looked like they
were cut and paste from Synopsys documentation. The tutorials were
rather bland and looks like Synopsys will keep telling same things
time and again."
- an anon engineer
"I found Primetime-SI not that attractive, but that is my personal
opinion. I have heard some people all praises for it."
- an anon engineer
"We use PrimeTime-SI as the successor of our internal SDF generation
tool. So signal integrity was taken into account by a 'rule of
thumb' approach. In those days PrimeTime was used to do STA.
Now we introduce PrimeTime-SI to measure the effects of signal
integrity. Our chip is roughly 400 k logic + 2 M Ram in 0.18 um.
It is a flat design.
PrimeTime-SI needed approximately 15 hours for STA (3 Cases) and
4.8 G of RAM on a Sunblade with 8 G memory. I wonder how you can
ever do STA with PrimeTime-SI on a real big chip!
Some new variables were introduced to PrimeTime-SI and we needed some
consulting on how to set these variables.
We saw that Apollo P&R did not correlate smoothly to the timing
results delivered by PrimeTime. This is really annoying because
turnover cycles (P&R -> STA -> P&R) are really long.
Three times the version of PrimeTime-SI was updated in the course of
our design. Each new version should be 'faster and less pessimistic'.
I had the impression that PrimeTime-SI crashed when you really wanted
to use TCL and analyse parts of the design thouroughly.
The main drawback of PrimeTime-SI is its speed (very slow) + its memory
requirements. Additionally the P&R/STA flow is not satisfying."
- Klaus Vongehr of Philips Semiconductors
"We just evaluated PrimeTime-SI (PT-SI) for crosstalk analysis and
Mars-Xtalk from Avanti for crosstalk prevention and correction.
PrimeTime-SI was very easy to integrate in our 'normal' STA flow. We
just installed the relevant licenses and added a few commands to the
setup script to enable the crosstalk analysis. This was done with the
assistance of our local AE. We use Simplex Fire&IceQX and getting SPEF
with coupling capacitances into PT-SI was no problem.
Our Mars-Xtalk/PT-SI evaluation was done on a relatively small block,
approximately 18K instances and 20K nets with a layout size of about
600u x 600u, for a reasonable test run time.
A 'side effect' of PT-SI is that it is possible to write (and read)
binary SPEF. This significantly reduces the time it takes to load the
parasitics into PT-SI for subsequent runs. You should expect
significantly longer run times for the update_timing (we saw something
in order of more than 2x) when enabling crosstalk analysis.
The initial layout (without Mars-Xtalk) did show a significant
performance drop (increased WNS) when analyzed with crosstalk analysis
enabled in PT-SI. Mars-Xtalk operates with a so-called 'threshold'.
By default, the threshold is 0.45 which means, that a net is considered
to have a crosstalk violation if one or more aggressors induce a total
noise voltage on it that is greater than 0.45xVDD. Playing around with
different settings of the threshold, we managed to remove almost all
crosstalk degradation (with a runtime penalty in the order of 2x for
our routing.)
This flow has a fundamental problem in that Mars-Xtalk uses the size of
the noise voltage as the selection criteria for avoiding and correcting
crosstalk violations, while PT-SI analyzes the degradation of the path
delays due to the crosstalk effects. It does not matter whether the
noise voltage is large or small. A small noise voltage might create a
setup or hold violation on a critical path, whereas a large noise
voltage might be relatively harmless on a non-critical path. This
means Mars-Xtalk is only indirectly solving the crosstalk problems. We
created sort of a workaround for this problem by extracting a list of
nets on critical paths with a 'significant' crosstalk contribution and
fed this to Mars-Xtalk as nets needing repair. This required some TCL
and Perl scripting.
It will be nice to see a better integration of the tools (PT-SI and
Mars-Xtalk) in the future with the Avanti merger. Crosstalk analysis
is of limited value without the ability to repair (and vice-versa).
Another thing we would like to do with the analysis results from PT-SI
is to verify that the tool is not overly pessimistic. We are trying
to do something with SPICE here, but have no results as of yet."
- Lars Bo Graversen of MIPS
"15. PrimeTime-SI gains great attention among designers. Within one
year of the release there are already two papers that talk about
the pros and cons of this tool in SNUG this year. 'SI' here
stands for 'signal integrity', but it is exaggerated since this
tool can only analyze the cross talk effect. No IR drop and other
SI effect can be taken cared of at this time, although Aart
promised the R&D team of PrimeTime will look into these issues
very seriously. To use PT-SI, the traditional SDF file our
vendors provide us won't be enough anymore. Because the delay of
a net now depends on the timing of the nets switching nearby, we
need the SPEF file which can give us more info. Indeed more and
more designers are asking their vendors to provide SPEF file.
Synopsys itself are promoting its own 'SBPF' format which it
claims can greatly shorten the runtime. Personally I feel that
the lack of industry standard for timing calculation is a
danger in this area.
Though PT-SI is not perfect, it is going in the right direction."
- Andrew Cheng of Cisco
"Not even a mention of Simplex or Sequence, hello? Primetime-SI is a
good incremental inprovement. But if I have to pay for mask set, I'm
going to do my post-route extraction and SI checks with Simplex and
Sequence Design tools. PrimeTime-SI is not even in the running here."
- Tom Moxon of Moxon Design
|
|
