( ESNUG 389 Item 12 ) -------------------------------------------- [03/06/02]
Subject: ( ESNUG 378 #7 ) Three Users Do A Detailed Eval Of PrimeTime-SI
> We've recently had Synopsys come and give a presentation on PrimeTime-SI
> to do signal integrity analysis. I have to say that I was pretty
> disappointed in the presentation as far as the capabilities of the tool
> in handling large designs. Run times seem unreasonable as well as their
> capabilities of handle designs on the order of 3+ million gates.
>
> I was wondering if any ESNUG readers are currently using Primetime-SI
> and would love to hear any feed back that they might have to offer.
>
> - Caesar Abedin
> Applied Micro Circuits Corp. Andover, MA
From: Ryan Hyma <ryan.hyma@amd.com>
Hi, John
PrimeTime-SI is an extension of the PrimeTime static timing tool from
Synopsys. Using the detailed parasitics information contained in the SPEF
parasitics format, PrimeTime-SI is able to include the effects of crosstalk
in delay calculations. The tool has been implemented in such a way that
adoption of the SI functionality in an existing Primetime flow should be
very smooth.
Our adoption of PrimeTime-SI was not as smooth as we had hoped, but it does
appear to do a good job of exposing the crosstalk problems in a design. We
evaled PrimeTime-SI on two designs that I'll call "Mork" and "Mindy" here.
"Mork" Results
--------------
"Mork" is a design that was timing-clean in regular PrimeTime, but it had
timing problems in silicon that were thought to be due to crosstalk. Mork
is a 300 K gate chip implemented in a UMC 0.25u process.
Highlights:
The basic PrimeTime-SI setup was trivial. All that was required was to add
a few lines to the existing top level timing scripts. All of the default
parasitic filtering and net reselection criteria were used.
The runs ran relatively quickly. It took about 5 hours - including one
hour to read in the SPEF file.
Issues:
There were many problems with generating the SPEF format parasitics files.
This was something that had never been done here since the coupling caps
are normally split to ground. Arcadia was used for extraction and there
were many tool issues.
There wasn't any significant delay due to crosstalk reported on the suspect
nets on Mork. Since crosstalk was never proven to be the culprit on these
nets, there was no way to know if PrimeTime-SI was missing this case, or if
the timing problems through these nets were due to something unknown.
"Mindy" Results
---------------
"Mindy" was currently being developed and was not timing-clean. Mindy is a
400 K gate chip implemented in a UMC 0.18u process.
Highlights:
SPEF generation was very straight-forward this time using the Star-RCXT
extraction tool from Avanti. The setup of PrimeTime-SI was much easier and
the run times on one machine were a third of the time it took Arcadia using
6 machines in parallel.
PrimeTime-SI found many more serious delays due to crosstalk on Mindy. Many
were serious enough to cause large timing violations in paths that were
meeting timing before crosstalk analysis. This was somewhat expected since
the process was 0.18u compared to the 0.25u process used on Mork.
By default, the output of the report_timing command in PrimeTime-SI is the
same as in regular Primetime. The delays due to crosstalk are combined with
the normal net delays in the report. This is a good thing because it will
not cause scripts to break that rely on this output format. However, it
does give the option of seperating out delay due to crosstalk in the
report - which makes it easier to targer problem nets.
PrimeTime-SI supports the new Synopsys Binary Parasitics Format (SBPF). It
can read and write parasitics data in this format and it has been about 10x
faster to read and 1/8th of the size of the regular SPEF files.
Issues:
We spent the first half of the Mindy evaluation debugging problems caused by
the reduced SPEF from Star-RCXT. The runtime using this SPEF was very good;
just a few hours. However, the timing results were sketchy. Some delays
due to coupling were over 900 nsec! Further investigation revealed that
PrimeTime-SI didn't fully support reduced SPEF from Star-RCXT.
The run times using non-reduced SPEF were over 20 hours for Mindy. The
ASCII-formatted SPEF file size was nearly 3 GB uncompressed. This detail
was required to get accurate results with PrimeTime-SI. Unfortunately,
Star-RCXT does not yet support the SBPF binary formatted SPEF.
PrimeTime-SI vs. HSPICE
-----------------------
We used Hspice to model the effects of crosstalk on a part of the Mindy
design and a simple testcase from Synopsys. We first compared our Hspice
results to our regular Primetime results (no crosstalk), and once those
numbers were verified, we compared PrimeTime-SI and Hspice results.
We used the new write_spice_deck command to write out a SPICE deck for a
specific Mindy timing path. This SPICE deck included all of the nets and
cells in the timing path as well as the nets and drivers for the crosstalk
aggressors affecting this path. Unfortunately, this testcase was much too
complicated. There were too many aggressors on the same net, and a
comparison with the PrimeTime-SI results would not be practical. A simpler
testcase was needed.
Synopsys provided a testcase made up of three flops, each driving a buffer,
and each buffer connected to three nets running in parallel in the layout.
We ran this testcase through PrimeTime-SI and simulated it in Hspice. The
delays with crosstalk effects were examined. In the following table, I1
designates the center wire, and I2 and I3 are the names of the two
surrounding wires.
PrimeTime-SI
Path Type Spice (ns) (ns) Delta(ps) Delta(%)
-------------- ---- ---------- -------- --------- --------
I1 Stage delay rise 1.0280 1.0975 69.5 6.8
I1 Path delay rise 1.8100 1.9081 98.1 5.4
I1 Stage delay fall 0.7340 0.8545 120.5 16.4
I1 Path delay fall 1.5320 1.7170 185.0 12.1
I2 Stage delay rise 0.7655 0.7356 -29.9 -3.9
I2 Path delay rise 1.5270 1.5254 -1.6 -0.1
I2 Stage delay fall 0.5596 0.6064 46.8 8.4
I2 Path delay fall 1.3390 1.3896 50.6 3.8
I3 Stage delay rise 0.7655 0.7356 -29.9 -3.9
I3 Path delay rise 1.5270 1.5254 -1.6 -0.1
I3 Stage delay fall 0.5596 0.6064 46.8 8.4
I3 Path delay fall 1.3390 1.3896 50.6 3.8
These results show that PrimeTime-SI was generally slightly pessimistic in
calculating delays due to crosstalk. The non-SI Primetime was too close
to Hspice to even show any trends.
Our overall conclusions were that the biggest benefit of PrimeTime-SI is
its seamless integration into regular Primetime. Assuming you have aquired
a good SPEF parasitics file (not necessarily a trivial thing), all that is
required to run a basic PrimeTime-SI job is an additional variable set in
your PrimeTime run file. (You will need more than this to take advantage of
some features, but this will definitely give you a successful analysis.)
Some of the additional setups, such as filtering, was not quite as
straight-forward. PrimeTime-SI gives you very fine control over which
coupling capacitors, aggressors, and victims to consider for analysis.
Filtering out as many of these as possible will minimize the required run
time. However, coming up with good values for these various filters is
a very tedious, trial and error process. Finding a good balance between
accuracy and efficiency can be very difficult. Filter too aggressively,
and you may mask real crosstalk problems in the design.
It's difficult to comment on the run times for PrimeTime-SI because I
haven't run any other signal integrity tool. However, they are extremely
long compared to our regular Primetime runs. With our large designs
(>300,000 gates), PrimeTime-SI took about 20x the time for a normal
Primetime run, and used about 20x the amount of memory. Our longest runs
took 30 hours to complete on a Sparc U80 workstation and used a maximum
of 7.5GB of RAM. This can be a very big burden when you are waiting on
the results of a run to tape out a chip.
On a more recent 600 K gate design with even what I consider aggressive
filtering, the PrimeTime-SI runs take 34 hours on a Sparc U80 with 4 GB of
RAM, and 20 hours on a Sun Enterprise server with 14 GB of RAM. The max
memory usage reported by PrimeTime-SI is 7.5 GB.
So PrimeTime-SI is not without its problems, but it is giving us very useful
information about our designs as our process technology gets smaller and
smaller. We have learned that by keeping max transition times under tight
control, our crosstalk problems are minimized. We have now taped out
three chips that were signed off by PrimeTime-SI.
- Ryan Hyma
AMD Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Ken Scott <kenneth.scott@conexant.com>
Hey John,
I sent you a write-up on Conexant's PrimeTime-SI experiences which you
published in your DAC'01 Trip Report. It's here at:
http://www.deepchip.com/items/dac01-35.html
That letter captured all our experiences with the tool, and raised some
PrimeTime-SI methodology questions about which I was hoping to get
some discussion going.
I believe it's possible to work around the capacity limits of PrimeTime-SI
by exploiting hierarchy, using abstraction, and employing some basic RTL
coding & synthesis disciplines to simplify the block interfaces.
We have used plain PrimeTime in this mode successfully on 8 M+ gate chips
already, and I believe this approach can be applied to PrimeTime-SI. A
bigger challenge is how you fix the crosstalk-related timing problems you
find, and close timing. That was the main focus of my original post.
- Ken Scott
Conexant
---- ---- ---- ---- ---- ---- ----
From: Caesar Abedin <cabedin@amcc.com>
John,
I was disapointed with the capabilities of Primetime-SI simply because its
a new tool on the market for doing signal integrity checks yet they haven't
taken the time to optimize the tool to handle the huge chips that are
being done these days.
According to their presentation, a 1 million gate block takes 18 to 22 hours
to run (and that's just for doing the analysis... after that, we still have
to go back and look at the failures and then figured out how to fix them and
then implement the fixes.)
This kind of run time might have been acceptable a few years ago, but today,
when our smallest chip is 5 M gates and our largest around 15 M gates, these
run times makes doing a few iterations to fix the failures seem extremely
unreasonable and unrealistic.
I can't complain about Primetime-SI without complaining about Primetime for
STA itself. I believe Synopsys is very behind in being able to handle large
designs. We know this can be done. IBM's Einstimer can fully time a 7
Million gate chip flat in an hour. Why can't Primetime do that? If IBM
ever sold Einsteimer as a COT tool, they would very quickly win market share
from Synopsys.
- Caesar Abedin
Applied Micro Circuits Corp. Andover, MA
( ESNUG 389 Networking Section ) --------------------------------- [03/06/02]
Northern Colorodo -- EDA methodology guru, 14 year Synopsys user, seeks
design/EDA leadership position. Howard Landman "howard@riverrock.org"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 12,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
