( ESNUG 376 Item 7 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #35 ) Silicon Metrics Fills PrimeTime-SI's Weaknesses
> "PrimeTime-SI is only for analysis of cross-talk. It can't solve
> problems and can't analyze IP-drop now."
>
> - Jeong-Fa Sheu of Acute Communications
From: Dan Moritz <dmoritz@lsil.com>
Hi John,
A friend of mine at Fujitsu is using Silicon Metrics to get good correlation
between various EDA tools. I understand Fujitsu is using it to measure the
impact on design turn around time, file sizes (ie w/ & w/o SDF), and
accuracy.
Silicon Metrics has funding from both Cadence and Synopsys with a mission to
provide extremely accurate timing models. Since both have their own native
timing formats and corporate battles to wage, I imagine the politics at
Silicon Metrics are excruciating. What makes the product interesting is SM
has found a way to provide the user with almost identical commands and
results in *either* Cadence/Synopsys tool suite in spite of the politics.
It's funny how the big companies can work together, albeit at arm's length,
when they both see a need for a better solution.
Metrics pitches the idea of smart models (data + algorithms) to provide not
only cell representations, but interconnect delay calculation as well. They
also have a way to drop in to SPICE to provide full accuracy timing (if you
are willing to wait for it). They have an infrastructure that's independent
of the tools and uses IEEE 1481 and Tcl registration in order for the user
to get equivalent results and usage in both tools. Check this out:
Cadence Silicon Metrics Flow
----------------------------
set dpcm_bompath ./<technology>_bom/
set dpcm_path <library install point>
set dpcm_rulepath <library install point>/<ssm_module_name>
set dpcm_rulespath {<library install point>/%RULENAME}
set dpcm_tablepath {<library install point>/%RULENAME/data}
read_verilog ./<design>.v
do_build_generic
set_dcl_level -perfLevel 1
current_design <design_top>
read_spef <design>.spef
link_ssm <parasitics_file>
report_timing
Synopsys Silicon Metrics Flow
-----------------------------
set dpcm_libraries <your_technology> /*ie LSI lcbg12p */
set dpcm_path <library install point>
set dpcm_rulepath <library install point>/<ssm_module_name>
set dpcm_rulespath {<library install point>/%RULENAME}
set dpcm_tablepath {<library install point>/%RULENAME/data}
read_verilog ./<design>.v
link
set dpcm_level accurate
current_design <design_top>
read_parasitics <design>.spef
link_ssm <parasitics_file>
report_timing
Even though I showed PrimeTime and BuildGates/PKS, Synopsys also has support
built in for SM in Design Compiler (but not PhysOpt nor any other of their
tools.)
Cadence uses a common timing engine throughout it's 5.0 release (BuildGates
all the way through Integration Ensemble.) The cool thing for Cadence is
users get the same numbers and capabilities throughout the toolset
synthesis-through-to-GDSII.
The results are pretty amazing. SM can take in a .lib and create a binary
representation that connects to both tools via a C-API. 'Metrics runs
PrimeTime/BuildGates with both the binary and the .lib (Cadence) and .d
(Synopsys). They claim 5X(!) faster runtimes on a million gate design in
STA compared to SDF flows. (I wasn't able to obtain their test suite to
verify this in time to submit my report.) It's cool enough that they can
cut a ton of SDF/SPEF parsing time out of the STA run, but the SPICE
capability embedded (with LSF support) in both tools is the best piece!
This is key in PrimeTime-SI. With PrimeTime-SI needing full accuracy models
that can be recomputed incrementally, 'Metrics gives you good performance
and accuracy when needed. (PrimeTime-SI requires a lot of incremental
computation for calculating timing windows and signal overlap. That
precludes us from using PrimeTime-SI which relies on SDF. We can't move to
PrimeTime-SI without this kind of feature set because the interconnect
algorithm variation is too big when you are talking about crosstalk.)
Silicon Metrics also has a ton of features that everyone is talking about
like instance specific IR drop and PVT scaling which are useful in both
Cadence and Synopsys signal integrity tools.
Problems:
Like anything, there are holes. SM had to cheat a little bit in order to
make things work in their infrastructure. They have to read a SPEF in
directly instead of using the tool representation of parasitics. This can
cause prelayout estimation for some nets if you are changing the netlist
and your parasitic net names get out of step. Cadence has completed the
APIs necessary, but that version of the code wasn't used in the demo
(PKS 5.0-d44). I understand that Synopsys doesn't yet have the parasitic
APIs completely tested. They are prototyped, but SM hasn't yet received
the code drop to verify this in PT2001.08.
I thought this was the best technology at DAC this year in my field
(Timing/Signal Integrity). It shows that despite the politics users can
get the same user interface and results in competing tools. Not only that,
the numbers can be SPICE accurate and incremental which are mandatory if
we going to use some of the latest tools from Synopsys and Cadence on very
large designs.
- Dan Moritz
LSI Logic
|
|
