From: "Rich Schranz" <RSchranz@InfiniConSys.com>
Subject: Stupid EDA Quote of The Week
Hi John,
"Poorly made IP, in particular, requires a strong support team."
- John Heighton, Xilinx Europe
It was in the March 5, EE Times in an article called "Reality hampers
vision of interoperable IP cores." I wish to nominate this as the
Stupid EDA Quote of the Week.
- Rich Schranz
InfiniCon Systems, Inc.
Editor's Note: P.S. See ya'll at SNUG'02 & HDLcon'02 next week! - John
( ESNUG 389 Subjects ) ------------------------------------------- [03/06/02]
Item 1: ( ESNUG 384 #1 ) The Janus Fund Curious About The Avanti Merger
Item 2: PhysOpt def2pdef Chokes Trying To Convert Already Routed DEF 5.3
Item 3: ( ESNUG 388 #1 ) Dan Sees Synopsys As Hand Waving On C-Level Issue
Item 4: ( ESNUG 388 #18 ) VCS Rounding SDF Delays Doesn't Match PrimeTime!
Item 5: How Do I Run DC/PhysOpt For The Fastest Adders? Any Alternatives?
Item 6: As A User What Would You Think About A Shareware Vera "Lint" Tool?
Item 7: ( ESNUG 388 #14 ) Six Letters On Detecting Clock Domain Crossings
Item 8: ( ESNUG 388 #5 ) Another Customer Likes Formality 2002.03 (Beta)
Item 9: User Discovers That Vera 4.4 Is Having Trouble With Wide Variables
Item 10: "L" Shaped Blocks In Monterey (Aristo) IC Wizard With Cadence SE
Item 11: Can't Get Static Leakage Power Of A NAND Gate In NanoSim/PowerMill
Item 12: ( ESNUG 378 #7 ) Three Users Do A Detailed Eval Of PrimeTime-SI
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 389 Item 1 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 384 #1 ) The Janus Fund Curious About The Avanti Merger
> I just received word from a Synopsys AC that if I have a PAD and a CORE
> library that have two different operating voltages, then I end up with
> significant problems in Apollo, Design Compiler and PrimeTime. ...
>
> - Wayne Miller
> Standard Microsystems Corporation Long Island, NY
From: Gregory Kolb <Gregory.Kolb@janus.com>
To: Wayne Miller <Wayne.A.Miller@smsc.com>
Dear Wayne,
Do you have any sense for how long it will likely take the "new" SNPS to
put a front-to-back flow into your team's hands? Will they be able to come
to market with a product before Cadence?
- Greg Kolb
The Janus Fund Denver, CO
---- ---- ---- ---- ---- ---- ----
From: Wayne Miller <Wayne.A.Miller@smsc.com>
To: Gregory Kolb <Gregory.Kolb@janus.com>
Hi Greg,
It's still too early to even guess what'll come out of the acquisition.
Synopsys and Avanti users are all hoping for the best. However, as a
company looking for DSM libraries, Avanti is getting hurt because of
Synopsys' previous library business sell-off.
The two companies should be able to put together a very tight RTL-to-GDS
flow, but there'll be some bumps along the way to see who stays, and where
the new lines are drawn. I hear insiders at Cadence are really shaking
in their boots!
- Wayne Miller
Standard Microsystems Corporation Long Island, NY
---- ---- ---- ---- ---- ---- ----
> Wayne might want to try the following SolvIt article: Synthesis-654.html.
> It describes two solutions, one modifying the k_volt parameters in the pad
> library, and the other modifying the nominal voltage in the pad library.
>
> - Bob Wiegand
> NxtWave Communications Langhorne, PA
From: Gregory Kolb <Gregory.Kolb@janus.com>
To: Robert Wiegand <RWiegand@NxtWaveComm.com>
Dear Bob,
This is in response to a query by Wayne Miller in ESNUG 386 #9.
I'm wondering what Wayne's question implies about the ability of Synopsys to
create an integrated front-to-backend flow with its acquisition of Avanti?
Did you work with either of the vendors prior to the deal's announcement?
How have those interactions changed, if at all, after the announcement?
I know this email comes out of the blue... I'm just interested in learning
about the space, was browsing the ESNUG email, and your post caught my eye.
- Greg Kolb
The Janus Fund Denver, CO
---- ---- ---- ---- ---- ---- ----
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
To: Gregory Kolb <Gregory.Kolb@janus.com>
Hi Greg,
I don't think Wayne's question was so much about tools interoperability as
it was about a specific functionality issue and how different tools handle
the situation. I personally haven't used Avanti tools, so I don't know how
they handle multiple operating conditions.
The Avanti acquisition announcement has not really effected my interactions
with Synopsys, but it certainly has me thinking. Obviously they are heading
for a fully integrated front to back solution, and it will take time to find
the best of both tool suites and integrate them into something better. One
thing that could be effected is the OpenAccess situation. (See EE Times
http://www.eedesign.com/story/OEG20020204S0022 for more.)
The OpenAccess Coalition is supporting Cadence's Genesis database, but there
are those who question the amount of control Cadence has over the standard.
I don't believe that Avanti would have ever offered their Milkyway database
for OpenAccess, but I believe Synopsys would have much to gain by doing so.
Another issue is that the Genesis database is only used in Integration
Ensemble, a product that wont be shipping in volume until 2003. The
Milkyway database however, is field proven with a significant customer base.
After seeing a recent demo of Silicon Perspective, I would question whether
or not Cadence really needs IE. That's a bold statement, so let me calm
that down a little. I'm not fully familiar with all the capabilities
planned for Integration Ensemble, but Silicon Perspective's First Encounter,
generally acknowledged to be everything Synopsys' Chip Architect wanted to
be and maybe even more, gives Cadence a working hierarchical flow today when
combined with pieces of Silicon Ensemble. This, IMHO, was a brilliant
acquisition by Cadence. Otherwise, if Silicon Perspective had fully
partnered with Plato (NanoRoute), they may have considerably altered the
EDA landscape.
- Bob Wiegand
NxtWave Communications Langhorne, PA
---- ---- ---- ---- ---- ---- ----
> If Synopsys takes this C technology and creates the next generation HDL
> that is capable of simulating at these remarkable speeds, I will be
> very happy.
>
> - Dan Joyce
> Compaq Austin, TX
From: Gregory Kolb <Gregory.Kolb@janus.com>
To: Dan Joyce <dan.joyce@compaq.com>
Dan,
Have you experienced any change in the operations/interactions with either
of Syposys or Avanti post their merger announcement?
- Greg Kolb
The Janus Fund Denver, CO
---- ---- ---- ---- ---- ---- ----
From: Dan Joyce <dan.joyce@compaq.com>
To: Gregory Kolb <Gregory.Kolb@janus.com>
Greg,
I don't deal with Avanti at all. Synopsys has not changed.
- Dan Joyce
Compaq Austin, TX
( ESNUG 389 Item 2 ) --------------------------------------------- [03/06/02]
From: Ofer Paperni <ofer.paperni@motorola.com>
Subject: PhysOpt def2pdef Chokes Trying To Convert Already Routed DEF 5.3
Hi John,
I have this problem while trying to convert the routed DEF (from SE-Ultra,
after CTgen and Wroute) to PDEF with the def2pdef I get the following:
Warning: Detect syntax error near token '*' at line 415183. Continue to
parse until the next correct rule can be applied. (DEFIN-16)
Warning: Probably the special wiring continue point has incorrect syntax.
(DEFIN-20)
Those lines in the DEF are net routing information:
- weim_lba_b ( PIN weim_lba_b ) ( z497 x )
+ ROUTED m1 ( 4329800 574150 ) via1 ( * * 500 ) ( 4351200 * 500 ) via2
( * * 550 ) ( * 576650 550 ) via3 ( * * 550 ) ( 4352600 * ) ;
Any ideas anyone? The .DEF version is 5.3
- Ofer Paperni
Motorola Semiconductor Israel
( ESNUG 389 Item 3 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 388 #1 ) Dan Sees Synopsys As Hand Waving On C-Level Issue
> We will support C-Level's CycleC methodology by enhancing Synopsys'
> VCS' DirectC to support C-Level's restricted C/C++ coding style
> for simulation performance. ... DirectC, which provides faster RTL
> simulation, will compliment our CoCentric Studio SystemC simulator,
> which provides faster architectural and HW/SW simulation.
>
> - Mark Hartoog
> Synopsys, Inc.
From: Dan Joyce <dan.joyce@compaq.com>
Hi, John,
This answer sounds like hand waving to me.
I can not tell if Synopsys plans to:
a) Sell a new C++ simulator that reaches performance on the scale of
C-Level. (I certainly hope that they don't think SystemC can do
this. It can't.)
or
b) Reverse engineer C-Level's tool and use the information to improve
VCS and DirectC.
My concern is they will only do b) and continue to claim that SystemC is
still the C++ solution; using C-Level technology just for Verilog tool
improvement.
Our experience with C-Level was that the C-Level C++ HDL simulated so
much faster than Verilog, that having ANY Verilog in the design reduced
the simulation speed to nearly Verilog speeds.
Let me be clear -- SystemC is NOT the answer. SystemC performance is
around 1/1000 the performance we were getting with C-Level style C++.
SystemC is not much better than VCS - if that. If you are going to
create a new language, which Synopsys did with SystemC, why not address
the simulation speed issue?
- Dan Joyce
Compaq Austin, TX
( ESNUG 389 Item 4 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 388 #18 ) VCS Rounding SDF Delays Doesn't Match PrimeTime!
> We've been annotating an SDF to a gate level netlist and seeing behaviour
> that doesn't link up with the results of our PrimeTime analysis. In
> particular, we're seeing scan chain shift issues caused by clock skew that
> seem to be okay in Primetime. It seems the skew that is seen between the
> flops in the VCS simulation is larger than that predicted in PrimeTime,
> slightly larger, and that's enough to kill our sims.
>
> My specific question is: how does one control the timing resolution in a
> VCS simulation that is annotated with an SDF? I've always assumed that
> the precision of the SDF would control the simulation precision. The SDF
> we have is specified down to 0.0001 nsec increments, but the simulation
> 'seems' to be running with a 0.01 nsec precision. It seems that we're
> hitting a situation where rounding going on.
>
> - Stephen O'Connor
> Cypress Semiconductor San Jose, CA
From: Brian Logsdon <brian.logsdon@philips.com>
Hi John,
Stephen really has an SDF with 100 fs resolution (0.0001 ns)? Ouch! That
gate sim is going to be slow. I'm glad it's him and not me running it. He
has described a common mistake... The SDF does not control the simulation
resolution. All the simulator does is annotate the delay information in the
SDF file into the timing arc variables of the gate models. Because the
simulator resolution is 10 psec, the simulator will either round off or
truncate the additional precision, depending on how the simulator was
written.
I was curious so I checked out the VCS manual and found the +delay_mode_unit
option to the VCS compiler. This is on page 3-21 of the Version 6.0.1,
"VCS/VCSi User Guide". I think this will solve his problem:
Set the 'timescale compiler directive to 1ns/100fs in the top level
source (probably the testbench) of the source files for the simulation,
including the testbench.
Then use the +delay_mode_unit option on the vcs command line. This will
force the compiler to use the smallest 'timescale it finds in the design.
Here is a potential problem: if you have a C-model or LMC model with fixed
timing resolution, and you are not running the simulator in the resolution
that the model wants, the model will likely not work. This is the case with
the LMC PCI models and it drives me bonkers!
- Brian Logsdon
Philips Semiconductors Tempe, AZ
---- ---- ---- ---- ---- ---- ----
From: Juan Carlos Diaz <juancarlos.diaz@massana.com>
Hi John,
Maybe I'm simplifying this, but it seems to me very similar to a problem
we had in the past with Modelsim. In fact, the solution was simulator
independent: no matter what the precision of the SDF file is, the
simulator will round the backannotated delays according to the "`timescale"
Verilog directive. Try to change the timescale to match your SDF accuracy,
and that's it, but remember there is a limit for this accuracy (consult any
manual to see this timescale limits).
- Juan Carlos Diaz
Massana Technologies Madrid, Spain
---- ---- ---- ---- ---- ---- ----
From: Stephen O'Connor <soconnor@silicon-packets.com>
Hi John,
Actually what Juan Carlos said is exactly what was going on. I discovered
that shortly after I mailed you John -- the `timescale in the library was
setting the precision. The root reason this was a problem SDF with lots of
tiny numbers for interconnect delays -- and I suspect these were the key
elements being rounded up.
My first suspicion was that VCS changing negative delays to zero which the
SDF also had was the issue, but gradually I figured it was precision issue.
And in retrospect it makes sense since the timescale directive is used at
compile time to set precision, and the SDF afterwards has to annotate those
delay elements, the directive would take precedence.
I also later got the detailed answer from the Synopsys VCS Support people.
The `timescale sets the precision, in our case our library had a 1ns/10ps
setup. Then if the SDF is a finer precision, which was our case, it gets
rounded off as follows:
0.001 -> 0.00
0.004 -> 0.00
0.005 -> 0.01
0.009 -> 0.01
Synopsys gives excellent VCS support.
- Stephen O'Connor
Cypress Semiconductor San Jose, CA
( ESNUG 389 Item 5 ) --------------------------------------------- [03/06/02]
From: Jay Pragasam <jlk@brecis.com>
Subject: How Do I Run DC/PhysOpt For The Fastest Adders? Any Alternatives?
Hi John,
I am wondering if anyone could share their thoughts about choosing the best
way to synthesize a processor core (say MIPS core for example) to get the
maximum speed? I currently do the conventional ASIC synthesis approach
with Synopsys tools and tweaking the outcome with the plethora of switches
that DC/PhysOpt offers. I would like to know if anyone has done any kind
of comparisons with this flow and another flow and found better results.
Also are there any faster implementations of adders and other arithmetic
elements available elsewhere that are not part of DesignWare?
- Jay Pragasam
Brecis Communications San Jose CA
( ESNUG 389 Item 6 ) --------------------------------------------- [03/06/02]
From: Dave Chapman <dave@goldmountain.com>
Subject: As A User What Would You Think About A Shareware Vera "Lint" Tool?
Hi, John,
I'm wondering how many Vera users out there in ESNUGland would be interested
in a Vera Linter? I'm working on one and would like to gauge user interest.
I'm thinking of making is shareware EDA. If you use it and like it, you can
send me money on the honor system. What do your readers think?
- Dave Chapman
Gold Mountain Sebastopol, CA
( ESNUG 389 Item 7 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 388 #14 ) Six Letters On Detecting Clock Domain Crossings
> Are you aware of any EDA tools that identify a design's asynchronous
> crossings and check for safe design practice? I posed this question to a
> few EDA companies, but nobody I spoke with had anything available, in
> development, or even in mind.
>
> - Al Jacoutot
> Silicon Access Networks, Inc.
From: Louise Thorpe <louise@veritable.com>
Hi John,
Our Verity-Check design property checking tool ( http://www.veritable.com ),
supports clock domain boundary checking. Verity-Check identifies data
signals that cross boundaries between clock domains that are asynchronous
to each other and checks for synchronization of the data.
- Louise Thorpe
Veritable, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ Yo Quiero Taco Bell ]
Hello John,
I've use a PrimeTime script from the synopsys web site that can catch cross
domain comunications that don't have proper synchronizing flipflops. You
have to ferret out the false ones, though. Seems like we also had to tweak
the script to get it to work.
Also, I believe a tool called SpyGlass will work at the RTL level, sort of
VeriLint on Steroids.
- [ Yo Quiero Taco Bell ]
---- ---- ---- ---- ---- ---- ----
From: Hirendu Vaishnav <vaishnav@synappscorp.com>
Hi John,
I can not say for sure what Al means by "crossings"; however, we do have an
asynchronous timing engine which understands ack-in/ack-out, asynchrous
cycle time, maximum through put, and captures/reports orphans. On our
web site http://www.synappscorp.com we do not talk much about asynchronous
timing engine, but that is how our entire timing engine got started. Let
me give you a brief description of our Async STA:
1) We identify and report longest and shortest paths and cycle times
(i.e., data-launch to acknowledge in) after doing special timing
analysis.
2) We report presence of orphans (i.e., lingering timing events from
previous cycle that may cause logic errors in the next cycle).
3) As part of pre-check, we report any logical/structural interaction
between two different cycles (a cycle is something that is triggered
by a unified acknowledge generation circuitry.)
We report such logical/structural interactions as errors and in fact it is
a pre-check for Async STA.
- Hirendu Vaishnav
SynApps Software Corp. Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: Jiri Prevratil <jiri@avanticorp.com>
Hi, John,
Avanti has a tool called Clock Domain Checker that does exactly this kind of
check. It reads the design, identifies all clock domains, and checks all
signals crossing domains to prove whether they conform to selected
synchronization rules. Clock Domain Checker has built-in synchronization
rules, and also allows users to specify a synchronizer cell that must be in
the signal paths between clock domains. Go to http://www.avanticorp.com
and look up "Clock Domain Checker" under "products".
- Jiri Prevratil
Avanti Corporation Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Lee Eng Han <ehlee@ftdpl.com.sg>
Hi John,
There are two type of EDA tools you can use.
1. PrimeTime
Define the timing domains, and put the design in the desired mode.
Then set false path from a timing domain to the same timing domain.
List out all the timing path. The timing path collection are all
asynchronous crossings.
If you are following some naming convention, you can write a PrimeTime
script to detect bad asynchronous crossings.
2. Formal Verification Approach
Avanti has a formal verification tool that does exactly this. Look
up Clock Domain Checker on their web site.
Hope this helps.
- Lee Eng Han
www.eda-utilities.com
---- ---- ---- ---- ---- ---- ----
From: Richard Curtin <rcurtin@athdl.com>
Hi John,
We have a product called @Verifier, which reads in Verilog RTL and reports
errors related to clock domain synchronization between the signals crossing
between the domains.
Given the top level clocks in the design it can:
- identify the clock tree and partition the design into various
clock domains.
- identify all signals that cross clock domains
- identify valid synchronizers elements amongst these signals. It
recognizes various synchronization styles commonly in use. These
include synchronization based on flops, domain enable MUX logic,
FSM's and FIFOs.
- identify all signals that cross clock domains without proper
synchronization. These could be due to no synchronizers being
present, faulty synchronization schemes or due to combinatorial
logic in the synchronization paths.
The results are presented to the user in a GUI that highlights all
the errors in a source and RTL-schematic browser. All the signals
are color-coded to their respective clocks with all interactions
between clock domains shown in 'RED'. http://www.atHDL.com
- Richard Curtin
@HDL, Inc. San Jose, CA
( ESNUG 389 Item 8 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 388 #5 ) Another Customer Likes Formality 2002.03 (Beta)
> We then quickly implemented & verified the fix by running another complete
> RTL-to-Synthesized-Netlist check. I strongly recommend using Beta
> Formality 2002.03, if you can get it from Synopsys. At one point, we
> were afraid we would have to re-synthesize this entire (very complex)
> design. That would have taken 2 days when you consider that you'd have
> to restitch the scan chain back into the new netlist plus redoing all the
> backend stuff. Instead, our problem was completely resolved in a matter
> of hours.
>
> - [ The French Olympic Skating Judge ]
From: Pontus Pleven <pontus.pleven@ebt.ericsson.se>
Hi, John,
I had the opportunity to evaluate Formality 2002.03 (Beta), too. Overall
we were fairly pleased with Formality's improvements.
We've used other LEC solutions (FormalPro, Chrysalis) but they were not to
our complete satisfaction. These LEC tools plus previous versions of
Formality had problems verifying our designs. Either they were difficult
to setup and use or they had long or inconclusive verifications. We've
found that these improper tool setups usually leads to false verification
failures that take forever to debug.
Our 300K gate scalable Bluetooth Core IP is in both VHDL and Verilog as two
tracks. (We have to serve both Verilog and VHDL customers equally.) But
these different languages, we don't want to double the time we spend on
simulations and verification. It's same functionality. So we save a lot of
time by using a LEC tool at this phase.
Our LEC situation was so bad for one chip we had to deliver verification
results based on different LEC tools! Our RTL-RTL LEC was verified with
Mentor FormalPro but not with Formality. The RTL-Gatelevel LEC did not work
with FormalPro so we used an old version of Formality instead. On top of
this, Chrysalis was the sign-off tool. We were forced to deliver Chrysalis
LEC with exceptions and unverified points.
The VHDL and Verilog readers behave differently on certain code structures
and Design Compiler has yet another view. No wonder the tools will get
problems. Intensive simulations on both Verilog & VHDL and FPGA testing
told us we had a correct flow. We weren't happy with this messy LEC flow.
All this changed with beta Formality 2002.03. We used it both for RTL-RTL
and RTL-Gatelevel LEC with great success. It was hard to believe.
Chrysalis still gives us unverified key points on the same design.
Formality 2002.03 beta's new interface was extremely easy to get into, and
the new debugging capabilities have been a big help. I especially liked
the source browsing.
During our beta period, we managed to spot some redundant logic, which
we removed from our design. A process which completed within a few
hours of work. Perhaps we made no big savings of logic but for sure it
saved us a lot of time by quickly pinpointing the issue.
Another thing we liked was easily setting constraints directly in its GUI.
Compare point matching are a major pain for LEC tools. Ideally, you want
the tool to do all the matching automatically. I still haven't seen a tool
that can automatically match all points all the time. But Formality 2002.03
got pretty close. And with the new intercative matching capabilities, we
were able to quickly verify that our constraints worked before running a
complete run. Writing batch scripts was as easy as running the GUI.
Another major problem using LEC tools is understanding why and where it
fails. Formality 2002.03 beta gave us some pretty good hints where by
listing error candidates while showing logic cones graphically.
Overall we are very happy with the new Formality 2002.03 since it's easy to
use, fast, and gives us no problems within our flow. Simple as that.
- Pontus Pleven
Ericsson Technology Licensing AB Lund, Sweden
( ESNUG 389 Item 9 ) --------------------------------------------- [03/06/02]
From: Dave Chapman <DChapman@goldmountain.com>
Subject: User Discovers That Vera 4.4 Is Having Trouble With Wide Variables
Hi, John,
If you set up 80-bit variables in Vera 4.4, load them with values which
include "z" and "x" values, and then perform ALU operations on them, you
get the wrong answers!
In particular, the logic sometimes gives you a 0 result for (0 | x). Vera
gives no error nor warning on this.
- Dave Chapman
Gold Mountain Sebastopol, CA
( ESNUG 389 Item 10 ) -------------------------------------------- [03/06/02]
From: Tim Colton <colton@mondes.com>
Subject: "L" Shaped Blocks In Monterey (Aristo) IC Wizard With Cadence SE
Hi John,
I am in the application engineering group supporting the (Aristo) IC Wizard
here at Monterey. The most common question that comes up from our
customers recently is how to support an 'L' shape block created in (Aristo)
IC Wizard when they export the block to Cadence Silicon Ensemble.
If you create a non-rectangular block in IC Wizard, you still can output
this to Silicon Ensemble for placement and routing. However, because the
DEF syntax doesn't provide direct support for this, we had to implement a
work-around. First, you need to set a hidden parameter in IC Wizard.
set parameter -key PIP_EXP_BARRIERS -integer 1
I know this is ugly but I'm told they're going to move this into the GUI
next release.
When this parameter is set, the DEF writer will output a special net called
"_BLOCKAGE_RESERVED" which defines the routing keepout for Silicon Ensemble.
IC Wizard will generate standard cell rows that fill the entire bounding box
specified by "DIEAREA" in DEF, however ROWS that cross any placed macros
will be trimmed automatically by SE using the CUT ROW command.
Unfortunately, this doesn't help with the _BLOCKAGE_RESERVED area. However,
IC Wizard will also write out a macro file that deletes the rows in the
appropriate area when the PIP_EXP_BARRIERS parameter is set. Note that any
user specified blockages in IC Wizard are handled in the same way.
If you are using the TCL interface to Dolphin instead of the DEF interface
to SE, there is no need to set this parameter as this is all handled
directly by the TCL interface.
I hope this helps prevent some problems ESNUG readers might encounter.
- Tim Colton
Monterey Design Systems Sunnyvale, CA
( ESNUG 389 Item 11 ) -------------------------------------------- [03/06/02]
From: Mouli Gopalakrishnan <cgopalak@csee.usf.edu>
Subject: Can't Get Static Leakage Power Of A NAND Gate In NanoSim/PowerMill
Hi John,
I have a question regarding measurement of static leakage power using
NanoSim (formerly EPIC's PowerMill tool.) I wasn't satisfied with the
Synopsys tech support's answer. :(
What I am trying to measure is the static wasted power in a NAND gate (or
for that matter any circuit ... I am starting off small). Input is a HSPICE
netlist of a NAND gate (4 transistors). Inputs to the NAND gate are 2 dc
inputs. Simulation time for some 400 nsec (arbitrary). What I want is the
leakage power dissipated due to the subthreshold leakage currents flowing
through the dc paths.
I do this using HSPICE by printing out VGS values and determining if each
transistor is ON/OFF and measuring the instantaneous power at that time if
it is OFF. This is time consuming and tedious and I wish there is a way by
which a tool like NanoSim could help me. :(
I was reading in the documentation NanoSim does measure leakage (wasted)
current -- both static and dynamic. I have been trying to use the
track_wasted and split_wasted option. According to the docs, it says
the split_wasted option splits the wasted currents (powers) into
static and dynamic. I tried it out for a simple nand gate. My input is
in the form of a SPICE netlist:
.inc 'TSMC-0.35um.model'
.global GND
V_vdd Vdd GND 1V
*V_a A1 GND PWL (0n 0 49n 0 50n 1 100n 1 101n 0)
*V_b B1 GND PWL (0n 0 100n 0 101n 1)
V_a A1 GND dc 0.0
V_b B1 GND dc 1.0
* HSPICE file created from nanf201.ext - technology: SCN4M.25.TSMC
.option scale=0.25u
m0 O A1 Vdd Vdd CMOSPL w=25 l=2
+ ad=150 pd=62 as=242 ps=132
m1 Vdd B1 O Vdd CMOSPL w=25 l=2
+ ad=0 pd=0 as=0 ps=0
m2 a_13_3 A1 GND GND CMOSNL w=21 l=2
+ ad=42 pd=46 as=105 ps=52
m3 O B1 a_13_3 GND CMOSNL w=21 l=2
+ ad=79 pd=52 as=0 ps=0
C0 Vdd GND 6.8fF
** hspice subcircuit dictionary
**.measure tran Vdd_pwr avg power from=0ns to=400ns
.tran .1ns 200n
.end
My cfg file:
report_block_powr total track_power=1 split_wasted=1 *
When I ran the above circuit, it gives dynamic wasted = 0 W and static
wasted = 0 W and % Wasted power = 100%. I understand the dynamic wasted
part -- since there is no switching activity, there cant be short circuit
currents -- but shouldn't there be some static leakage power ??
Can someone point out to me, what I am doing wrong -- or is the simulator
not capable of getting this value ?? I would really appreciate if someone
sheds some light on this for me.
- Mouli Gopalakrishnan
University of South Florida Tampa, FLA
( 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
|
|
