"I fear all we have done is to awaken a sleeping giant, and filled
him with a terrible resolve."
- Admiral Isoroku Yamamoto, Commander of the Japanese Navy, to
another officer at the post-Pearl Harbor victory party (1941)
( ESNUG 377 Subjects ) ------------------------------------------ [09/19/01]
Item 1: ( DAC'01 #13 ) VCS Has Crappy GUI, Docs, & Unfindable Switches
Item 2: ( ESNUG 372 #13 ) Users Complain About Sleazy Synopsys Licensing
Item 3: ( ESNUG 376 #8 ) Cooley Humbled By Magma's 667 K Instance Blocks
Item 4: Here's How We Used PhysOpt For CTGEN Clock Buffer Legalization
Item 5: The PKS Timing Engine Differs From Pearl; Qplace Runs Within PKS
Item 6: ( ESNUG 374 #7 ) Magma R&D Responds To Customer's Technical Issues
Item 7: ( ESNUG 372 #2 ) It's The Support That Counts With Linux Boxes
Item 8: Why Can't Potential Synopsys Customers Get Access To SolvNet?
Item 9: ( ESNUG 375 #8 ) Free Sun GridWare Vs. Platform Computing's LSF
Item 10: ( ESNUG 375 #1 ) Extract A Hierarchy From A Flat Gate Netlist
Item 11: ( ESNUG 375 #3 ) Have Raphael; Switch To Raphael NES (Quickcap)?
Item 12: ( ESNUG 373 #11 ) Electromigration Is Much Worst In One Way Lines
Item 13: Help! How Can I Simulate 12.5 M Gate Designs In Verilog with SDF?
Item 14: ( ESNUG 376 #17 ) User Likes Averant Solidify Because It Works!
Item 15: What Competes With Synchronicity's IP Gear Design Reuse Tool?
Item 16: An Undocumented -log_changes Option To DC's change_names Command
Item 17: How Do I, Step By Step, Create Statistical Wireload Models For DC?
Item 18: Two Users Question PrimeTime On Its Interface Logic Models (ILMs)
Item 19: How Do I Create Actual True Internal Clocks In Synopsys PrimeTime?
Item 20: Want Expanded PrimeTime 'clock network delay (propagated)' Reports
Item 21: ( ESNUG 375 #6 ) PrimeTime Reports Ignored Exceptions; But Not WHY
Item 22: Synopsys SmartModels Run *Painfully* Slow On Cadence NC-SIM VHDL
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 377 Item 1 ) -------------------------------------------- [09/19/01]
Subject: ( DAC'01 #13 ) VCS Has Crappy GUI, Docs, & Unfindable Switches
> SAME OLD, SAME OLD: If you take a look at last year's DAC Trip Report,
> you'll find that Cadence NC-Verilog & Synopsys VCS were fighting neck and
> neck; Model Tech were doing really well in the VHDL and Verilog/VHDL
> co-simulation market...
From: "Gregg Lahti" <gregg.lahti@corrent.com>
John,
Is it just me or does it seem to me that VCS has been stuck in a timewarp?
I used VCS a little over four years ago and then wound up using ModelSim
for four years. Over those four years, ModelSim added some very useful
features and improvements plus Verilog support which I happily used. I
changed companies, and I'm now back using VCS.
But it seems that VCS hasn't evolved. VCS did change, as evident of some
speedup performances with the Radiant options and the 2-state simulation
option. But after being away from using it for four years, the VCS
documentation hasn't changed much if at all. Finding out all of the new
switches added or the performance adds to VCS isn't possible: the shipped
docs still have Chronologic plastered all over them and there is a
serious lack of any documentation available on the Solvnet site. (I had
to resort to going through my SNUG handouts of previous years to find out
about the latest and great issues with VCS).
The VCS PLI interface sure hasn't been improved, as it doesn't support
PLI 2.0 calls and still has some limited PLI 1.0 issues. The virsim
interface seems much different than what was in it four years ago.
However, the new interface seems to me more user-hostile than the
VHDL simulator interface that Synopsys finally dumped a year ago. Thank
goodness for Debussy which still offers really good debugging and a
half-way decent user doc.
Finally, it's mid-year 2001. How many more years must I wait for VCS to
integrate all of the Verilog 2000 language updates?
In all fairness, VCS seems pretty speedy. But speed isn't everything
when it's tough to use and hard to debug my problems with. Having been
away from it for four years, I would have expected some improvements and
the ability to reference them. It seems to me that I've jumped through
a timewarp and landed on the Planet of the VCS, where evolution has gone
backwards.
Hopefully I won't accidently discover the Statue of Liberty in any of the
silicon I'm simulating.
- Gregg Lahti
Corrent Corp Tempe, AZ
( ESNUG 377 Item 2 ) -------------------------------------------- [09/19/01]
Subject: ( ESNUG 372 #13 ) Users Complain About Sleazy Synopsys Licensing
> Dan's experience isn't unique. "Just don't heap too much praise upon
> Avanti until you get to know them," warned Dale Lomelino of Philips
> Semiconductors. "If anything, they have more warts and blemishes than
> Synopsys and Cadence combined. Avanti does not want to support standard
> formats like PDEF or LEF/DEF. Instead, they prefer to lock you into
> their 'unified binary Milkyway database' -- and hold you hostage."
>
> What use is any Best In Class P&R tool if you can't interface to it?
>
> - from "That Other Avanti Issue" ( EE Times 5/07/01 )
From: Tom Loftus <tloftus@intrinsix.com>
John,
I have an interesting thing I noticed about Synopsys license usage. In
certain circumstances, during a compile -scan command, it will apparently
perform optimizations which require the VHDL-Compiler or HDL-Compiler
license features, in addition to the Test-Compiler and Design-Compiler
features it already uses.
I find Synopsys licensing tactics like this ridiculous and I told the
support people that when I talked with them.
They really provided no avenue for me to express my opinion that gobbling
up multiple license features during execution of certain commands starts
to get ridiculous at some point.
I like to use batch type jobs and need to know the necessary license
features ahead of time for the jobs to succeed.
I probably waste more time in script development worrying about license
feature management than I do on other more important synthesis issues.
When some Synopsys tool doesn't work the way you think it should, the
Synopsys support response isn't "We'll fix it" -- the response is more
often than not, "That's the way the it is".
- Tom Loftus
Intrinsix
---- ---- ---- ---- ---- ---- ----
From: Romas Rudis <rudis@intrinsix.com>
John,
Synopsys seems to grab a VHDL-Compiler license for no apparent reason
during compile. I am running a Verilog-only synthesis with no DesignWare
(or other VHDL originated components):
read -f verilog srom_cntrl.v
...
remove_license HDL-Compiler
1
list -licenses
Design-Compiler
LUCENT-HL160C
LUCENT-LV160C
1
compile -map_effort medium
...
Optimization Complete
---------------------
Transferring design 'srom_cntrl' to database 'srom_cntrl.db'
Current design is 'srom_cntrl'.
1
list -licenses
Design-Compiler
LUCENT-HL160C
LUCENT-LV160C
VHDL-Compiler <<<<<*** Where did this come from?
1
Of course, I'm sure that Synopsys would prefer that we buy a copy of
VHDL-Compiler and HDL-Compiler for each copy of Design-Compiler that we
have. This would certainly solve the problem...
But, as you know John, I am a Verilog bigot, so the problem is even worse.
If anyone checks license usage, people will think I'm doing VHDL synthesis
runs and start making fun of me. IMAGINE IF THIS SITUATION HAPPENED TO
KURT BATY, WHAT PEOPLE WOULD SAY! Seriously though, I really have a problem
buying more VHDL-Compiler licenses just because, for some unknown reason,
my Verilog synthesis run grabs a VHDL-Compiler license.
So even though our LSF batch queues wait for a VHDL-Compiler licenses to
become available before execution starts, the fact the my Verilog job can
grab one randomly screws things up. If someone knows of a workaround please
let me know. The only workaround I know of is for VHDL users to ping for a
license like this inside their dc_shell script (pretty silly isn't it!):
/* Ping for license */
get_license VHDL-Compiler
/* Retry every 5 minutes (5*60=300) until license is obtained */
while (dc_shell_status == 0) {
echo "Couldn't retrieve VHDL-Compiler license. Retrying..."
sh sleep 300;
get_license VHDL-Compiler;
}
echo "Successfully Retrieved VHDL-Compiler License."
/* Now you can safely read in your VHDL code and be sure that you */
/* actually get a VHDL-Compiler license */
read -f vhdl filename.vhd
Of course this now ties up a Design-Compiler license until a VHDL-Compiler
license becomes available...
- Romas Rudis
Intrinsix
( ESNUG 377 Item 3 ) -------------------------------------------- [09/19/01]
Subject: ( ESNUG 376 #8 ) Cooley Humbled By Magma's 667 K Instance Blocks
> I noted that's a VERY BIG CLAIM because everyone else is struggling with
> hierarchical flows BECAUSE Magma/PhysOpt/PKS can only do 100K to 360K
> blocks. (Even Magma itself announced a hierarchical tool because of this
> problem!) Now if Magma can do 4 million gates flat, as their VP says,
> THAT'S NEWS. Over the past 9 days I've been phoning and e-mailing the
> Magma people to get a user to confirm that they really can do 3-4 million
> gates FLAT. Magma keeps replying the 3Dlabs people will confirm this,
> but so far, I've received nothing whatsoever from any Magma user on
> anything. After 9 days, I'm no longer holding my breath here.
>
> - John Cooley
From: "Paul Pontin" <Paul.Pontin@3dlabs.com>
John,
I just had to reply to this one!
This is the data we gave your for your tapeout survey:
8 M gates, 2.5 M instances, 30 M transistors
What we did not tell you was that the chip consisted of 4 flat blocks, held
together by a top level. The block sizes were:
Block 1: 3.1 M gates, 667 K instance count, 58 macros, 3000 I/O's
Block 2: 2.3 M gates, 600 K instance count, 98 macros, 6000 I/O's
Block 3: 1.9 M gates, 200 K instance count, 32 macros, 4000 I/O's
Block 4: 700 K gates, 505 K instance count, 88 macros, 500 I/O's
The only layout tool used was BlastFusion. (Yes, it even did the top level.
We were the ones working with Magma to develop the hierarchical flow.) One
of the main reasons we use BlastFusion is because of the large block sizes
it can handle.
BlastFusion is a major competive advantage to us in the eternal struggle to
lay out these massive chips. I do not know of another tool that could have
handled this design in 4 blocks... do you?
- Paul Pontin
3Dlabs Egham, Surrey, UK
[ Editor's Note: Wow. I got put in my place there. On my scorecard for
max block sizes (counted as placeable instances), Magma's 667 K is 2X
Cadence PKS' 360 K and 3X Synopsys PhysOpt's 250 K. Guess it's just my
day to eat some humble pie here, folks. I was wrong. Oops. - John ]
( ESNUG 377 Item 4 ) -------------------------------------------- [09/19/01]
From: "Tommy Zounes" <tommy.zounes@st.com>
Subject: Here's How We Used PhysOpt For CTGEN Clock Buffer Legalization
Hi John,
Recently, a colleague of mine asked me about a design's cell placement after
CTGEN inserts clk buffering. I never thought about this before. I just
assumed CTGEN would slightly nudge the cells over to place the new clk
buffers. To check this, I wrote a small script that compared the initial
cell placement (done by PhysOpt) to the final CTGEN output. The design used
is 0.08 mm2, has 4,900 instances, utilization is about 92%, and uses 0.12
technology. About 80 buffers were added by CTGEN. The results revealed 140
cells moved from its original location by between 12um and 25um. About
2,500 other cells were moved by less than 12 um.
This may not seem too bad, but for a 0.4 um pitch routing technology, 62
grid difference is beginning to look quite high.
I then decided to try PhysOpt to do the legalization of the cells. CTGEN
provides a DEF output file without the cells being legalized in the
<rundir>/db/qp_in.def. To be able to use PhysOpt, a Verilog netlist with
the clock tree inserted is needed. I've written SKILL routines that can
convert a DEF-in layout to Verilog. It would be nice to have a script that
can create a Verilog netlist directly from DEF!
Anyway, in the DEF file, the new clk buffers need to have their placement
set to "FIXED", otherwise PhysOpt may move these a little. I also thought
about FIXing the register placements. But in this case I did not since I
was unsure what PhysOpt would do if a clk buffer overlapped a register cell.
Also in the DEF, some clk syntax added by CTGEN needs to be removed because
Synopsys' def2pdef will give a syntax error. So when running psyn_shell, I
just load the new Verilog gate netlist and the new DEF, and I just run the
'legalize_placement' command.
The new placement results revealed no cells were moved more than 12 um.
2,800 cells were moved by less than 12um.
It would be interesting to see results from other designs.
- Tommy Zounes
ST Microelectronics
( ESNUG 377 Item 5 ) -------------------------------------------- [09/19/01]
Subject: The PKS Timing Engine Differs From Pearl; Qplace Runs Within PKS
> Does the new release of PKS use a "new" algorithm for doing the timing
> driven placement, or is the Pearl interface just buried by the GUI?
> There is some internal debate among our group about this fact. I figure
> the timing engine is based on Ambit now, rather than Pearl or any staged
> based constraints as in the old days. So there is some "new" code.
>
> - Jim Jok
From: Ralf Leisner <leisner@cadence.com>
Hallo Jim,
PKS timing engine is Ambit based, therefore it is different from Pearl and
it is not invoking Pearl. In a future release the timing engines will be
merged. To have Ambit and Pearl timing engines in parallel is an
intermediate status. I do not know the details of the schedule for this
unification.
The placement tool used by PKS is Qplace, but it is not called as standalone
tool anymore (like in SE). It is an integral part of the PKS software, with
a tight interface to the Ambit internal databases. The timing related base
of operation for PKS-Qplace are not the stage based constraints. It is the
Ambit own timing constraints environment instead. A major advantage of PKS
compared to the SE environment is the hierarchical view to the design,
including its timing constraints, as a designer is used to looking at this
thinks.
- Ralf Leisner
Cadence GmbH Feldkirchen, Germany
( ESNUG 377 Item 6 ) -------------------------------------------- [09/19/01]
From: "Kirti Parmar" <kirti@magma-da.com>
Subject: ( ESNUG 374 #7 ) Magma R&D Responds To Customer's Technical Issues
Hello John,
My name is Kirti Parmar and I'm the Director of Product Engineering at
Magma. I would like to take a moment to respond to some items identified
by users in ESNUG 374 #7. I am very happy to recommend solutions to the
issues listed and look forward to your coverage of our customer issues.
Usability of the Power Router
-----------------------------
"Power router causing DRC and signal shorts."
"We found the Blast Fusion power router to be flaky. Had to fix
some of the power manually. Also the current version of the tool
does not allow to finish the power completely before the routing."
Point well taken. We have updated the Power Router in Release 3.0 which is
currently in beta. Our new GUI-driven power router is interactive and
supports complex power routing requirements. Because it is interactive and
immediately displays the results, any issues or problems that may be induced
are immediately visible. We believe this will address many of the issues.
On-line basic Power DRC checking capabilities (which can be disabled through
the GUI) are also available in Release 3.0.
Tie-Off Routing
---------------
"Tie hi/lo pins handled by power router instead of detail router."
"...but macro pin changes or tie hi/lo pin changes are difficult
to implement."
In Release 3.0, tie-offs for standard cells are handled during detail
routing. Tie-off for "macros" is still done during power routing because
these pins frequently require special rules.
We also provide an ability to define/redefine tie-off pins on a pin-by-pin
or on a per-net basis in Release 3.0. Tie-offs can be done directly to
power/ground nets or to special tie-off cells.
Antenna Avoidance and Repair
----------------------------
"We did have to do our own workarounds for antenna fixes, tho."
"Took some work before we got the tool to fix all antenna violations"
Antenna avoidance and repair have always been an integral part of the
Blast Fusion design flow. Magma models antenna effects from the first
global routing and takes these into account throughout the flow. However,
these have sometimes come at the expense of run time or increased
congestion (specially if incorrect antenna rules had been set) in some
designs. Repairing these often required tedious manual intervention.
Clearly the status quo was unacceptable as antenna rules become increasingly
stringent in newer (0.15u and smaller) process technologies.
Beginning with Blast Fusion version 2.1 we have added area-based antenna
rules to support these new technology requirements. Enhancements are
planned for Blast Fusion version 3.0 which will focus on avoiding and
resolving antenna problems in a more localized area through "jumpers" and
"diode insertion". Our internal experiments indicate that this solution
produces high quality, antenna-free routing without increasing congestion.
Off-Grid Pins Handling
----------------------
"Detail router doesn't always find a solution for off grid closely
spaced pins on macros."
Blast Fusion requires proper modeling and library preparation in order
to achieve optimal result in the presence of off-grid pins. We found
that the quality of results produced using Blast Fusion was unnecessarily
reliant on steps that could be automated in some cases. I am pleased to
say that we have taken steps to correct this. Release 3.0 of Blast Fusion
contains both algorithmic improvements as well as minor flow changes to
address this issue.
Built-In DRC and LVS Checking
-----------------------------
"All but 1 weren't using Magma's built in DRC/LVS capabilities. They
were mostly using Menter's Calibre + a few Avanti Hercules users."
"The ASIC vendors are responsible for the top level assembly and that
includes transistor level DRC/LVS. We always run the "basic" cell
level LVS/DRC built into Apollo and it seems most design rule errors
are found at that level."
"In Blast Fusion, we found a lot of bugs and many differences with
sign-off rules. Most of these are related to routing issues."
Blast Fusion has always had a rather extensive set of DRC and LVS checking
capabilities built-in. The capabilities include checking for shorts,
same-net and different net spacing violations, notches, antennas, islands,
via overhang, multi-port and other physical or connectivity violations based
on specified rules.
The richness of the available rule set notwithstanding, it is unfair to
characterize these capabilities as lacking when compared to other Place and
Route tools. Blast Fusion, like other similar tools, models geometries only
on the layers that there will be routing on. Other layers are "abstracted".
The recommended use model for Blast Fusion is to use the built-in DRC and
LVS capabilities to get the design "clean" from a place-and-route perspective
and, at the end, follow this DRC and LVS checking using external tools such
as Mentor's Calibre, Cadence's Dracula or Avanti's Hercules. We internally
use Calibre for QA testing.
We consider it an urgent bug if violations for the specified rules are not
reported by Blast Fusion but are reported by external DRC/LVS checking tools
like Calibre, Dracula or Hercules. Vice versa, we consider it a bug if a
violation is reported by Blast Fusion but is not reported by Calibre,
Dracula or Hercules given comparable rules.
As an aside, I would like to point out one feature of Blast Fusion that
users may not be aware of: the ability to import DRC violation markers from
report files produced by Calibre, Dracula or Hercules. The command is
"import marker calibre" (or "import marker dracula" or "import marker
hercules" as may be appropriate) which parses the specified report file
produced by Calibre, Dracula or Hercules and displays the violations in the
Blast Fusion GUI.
GUI
---
"GUI crashes more than it should, ..."
"The interactive GUI is still a little flakey."
I must concur with this assessment. We are improving the stability of the
GUI as well as increasing its functionality (the new interactive Power
Router is one of these). In Blast Fusion 3.0 we have made significant
improvements in the stability and performance of the GUI. The GUI is, and
will continue to be an area of focus for Magma as we strive to improve
Blast Fusion.
We appreciate the honest feedback we have received. Thanks.
- Kirti Parmar, Director of Product Engineering
Magma Design Automation, Inc.
( ESNUG 377 Item 7 ) -------------------------------------------- [09/19/01]
Subject: ( ESNUG 372 #2 ) It's The Support That Counts With Linux Boxes
> I'm interested in what Linux hardware people are running:
>
> 1.) Which Processors, motherboards, amount of memory, are you using?
> 2.) Which flavor of Linux are they running?
> 3.) Single/multi-processor boxes?
>
> Can you organise a poll, John?
>
> - [ Chicken Little ]
From: Rainer Dorsch <rainer@rai16.informatik.uni-stuttgart.de>
John,
We did an Linux/Solaris evaluation some time ago. For the Linux side, it
turned out that the topics which the poster requests have not made a big
difference. But we found already during evaluation of the Linux boxes some
problems. And there it turned out that there are tremendous differences in
support. One of our home made tools was not running. We simply handed the
tool and a (complex) test case over to the hardware resellers support.
The results was at the end:
- VA Linux: difficult to contact support, but when this problem is solved,
the support people knew immediately what was going on and worked out a
kernel patch which solved all our problems
- "Established" IT Companies: very easy to get contact to support, but they
were after weeks still far away from identifying the problem.
To answer the questions of the original poster:
We are running VA 2200 boxes. So far one power supply died, replaced
immediately. There was one software support call. A perfect solution was
worked out by experts, but reponse time was a few days.
- Rainer Dorsch
University of Stuttgart Germany
( ESNUG 377 Item 8 ) -------------------------------------------- [09/19/01]
From: "Bipin Bhakta" <Bipin.Bhakta@Primarion.com>
Subject: Why Can't Potential Synopsys Customers Get Access To SolvNet?
John,
I am a designer (mainly custom). Although I've used Ambit (few years back),
I'm a novice in regards to synthesis, concepts, terminology, etc. I would
very much like to get appnotes, tech documents, etc. from SolvNet. But,
unfortunately, we don't have Synopsys, although we are considering the
purchase, thus no access to SolvNet. Would you happen to know if there's a
way for I could get access as a guest or anyway at all? If not, besides
DeepChip, are there any "truely" useful websites which will guide a novice
like myself in terms of intro to detailed topics on design/ synthesis/
terminology /concepts & topics.
- Bipin D. Bhakta
Primarion, Inc
( ESNUG 377 Item 9 ) -------------------------------------------- [09/19/01]
Subject: ( ESNUG 375 #8 ) Free Sun GridWare Vs. Platform Computing's LSF
> Does anyone out in ESNUGland have experience with using Sun's Grid Engine
> software (http://www.sun.com/gridware) for managing EDA compute jobs and
> licenses? I used Platform Computing's Load Sharing Facility (LSF) at a
> previous employer and liked it, but my penny-pinching current employer
> likes the cost of GridWare: it's free. I'm not fond of the GridWare
> approach to license management and of course it only runs on Sun and Linux
> platforms so far. What other user's experiences with it?
>
> - [ Grid And Bear It? ]
From: Kathleen Rose <Kathleen.Rose@sun.com>
John,
The appplication license management of Sun Grid Engine is very similiar to
LSF Batch. In both products, a count is kept of how many free floating
licenses are available, and only that many jobs are dispatched. This is the
Shared Resources facility in LSF, and the Consumable Resources facility in
Sun Grid Engine. In both LSF and Sun Grid Engine an external program can
query FlexLM (via lmstat) and report actual license count, instead of a
fixed license count. This is called the elim in LSF, and the external load
sensor in Sun Grid Engine. This scheme is not perfect, and the writer is
perfectly justified in not liking it. But I would like to correct the
implication that they are vastly different approaches - they are not.
Sun Grid Engine has been a commercial product, formerly known as CODINE, for
over 7 years. It mainly focused in Europe on high performance computing
before Sun bought Gridware. Regarding the Sun and Linux only comment,
Gridware had ported and sold CODINE on all of the major Unix platforms. Sun
will continue this through partners and the Grid Engine open source project.
In addition to free Sun Grid Engine on Solaris and Linux, Sun has a free web
based training course that can be accessed from www.sun.com/gridware. Also,
support for Grid is on http://supportforum.sun.com/gridengine. There are
app notes to step through exactly how to set up things plus there is a
newsgroup-like discussion forum that also can be searched. ESNUG readers
can get the unmodified opinions, reactions, etc. of the Gridware community
of users there.
- Kathy Rose
Sun Microsystems
---- ---- ---- ---- ---- ---- ----
From: [ Grid-aWare]
Hi John,
Please keep me anonymous please.
We've been using Gridware for the past 3-4 months on a large ASIC design
project. It does everything we need to do, however we have an administrator
to deal with setting up the queues and policies. To a "dumb" user like me
it was an efficient way to run a large amount of jobs over a mixed
Solaris/Linux environment.
- [ Grid-aWare]
( ESNUG 377 Item 10 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 375 #1 ) Extract A Hierarchy From A Flat Gate Netlist
> When we do minor (typically metal-only) re-spins of our devices. We make
> our changes by hand at the gate level. We've gotten good at specifying
> the gate changes, but have run into a roadblock in verifying them. In the
> old days, our gate level netlists preserved hierarchy, and so it was easy
> to extract the module containing the fix and either use it to replace the
> RTL block in simulation, or (more recently) re-synth the RTL and
> Formality-check the synth'd gates to the hand-fixed gates. However,
> things like clock-tree-insertion and scan-reordering are now causing our
> gate-level netlists to be totally flat. Extracting a block of gates
> that's bristle-equivalent to an RTL block has become a non-trivial task.
> I was wondering if anyone out there had licked this problem?
>
> - Jeff Winston
> Mindspeed Technologies
From: "Doug Baumann" <doug.baumann@zeevo.com>
Hi John,
We've run into similar problems. Our designs contain complex modules which
formal tools have difficulty proving against a flattened netlist. What
we've chosen is a 2-part verification which adds a little overhead but
provides a robust solution (so far). The method is to keep a hierarchical
gate-level netlist around in addition to the post-layout flat netlist. The
hierarchical netlist does not contain scan chains, clock trees, or other
messy, post-synthesis changes.
The first step is to replicate the ECO changes in the hierarchical gate-
level netlist, then formally verify the hierarchical netlist to the ECO'd
RTL. The second step is to replicate the changes in the flattened post-
layout netlist, then formally verify against the ECO'd hierarchical gate-
level netlist.
There is a little more work to maintain a golden hierarchical and post-
layout netlist, however it is well worth it when you can know for certain
that your ECO was implemented correctly.
-Doug Baumann
Zeevo
( ESNUG 377 Item 11 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 375 #3 ) Have Raphael; Switch To Raphael NES (Quickcap)?
> I am a design kit developer for the IBM SIGE RF/Analog design kits.
>
> I am interested in purchasing Raphael NES (Quickcap). My group currently
> has one copy of Raphael. I know that Quickcap is most often used as a
> 'golden' capacitance extraction tool when comparing parasitic extraction
> tool capacitance accuracy. I currently use Raphael as our 'golden' 3D
> extractor, but am thinking of replacing it with Quickcap. I believe there
> are many reasons for this switch. Here are just a couple:
>
> - Quickcap offers full chip extraction for critical nets.
> - Quickcap is a full chip extraction tool.
> - Raphael works well for test structures, but for large structures the
> run times are not reasonable.
> - Raphael is more accurate than Quickcap for capacitance but the run
> times are long.
>
> Is it worth switching to Quickcap knowing that Quickcap is $78 K and I
> already have Raphael in house?
>
> - Grant Riley
> IBM
From: "Rajiv Mathur" <rajiv.mathur@intel.com>
Hi, John,
It depends on what you do with Raphael now. If you use it for developing
and characterizing your own capacitance models, then QuickCap is not a
replacement for that. If you are wondering if the models in a vendor tool,
say StarRC, are accurate for a fullchip net, then you can use QuickCap on
that net and compare with StarRC. You cannot do full chip net extraction
with Raphael.
For model development application, Raphael is fine unless you are running
large 3D test structures (still much smaller than a full chip net). If
Raphael is choking on these, QuickCap can be used on these structures.
However remember that QuickCap data comes with an uncertainty value and
model generation based on these extractions can be rather complex (harder
to get smoothly varying behavior.)
Regarding accuracy, it is not true that Raphael is more accurate than
QuickCap. For simple 2D cross-sections, Raphael gets an accurate result
fast, however it rapidly declines in performance as the structures become
complex, while QuickCap performance degrades only slightly with increasing
strucuture complexity. In fact for some 3D crossover structures, Raphael
gives very inaccurate results if you use the default grid, so watch out.
Always make sure that your answers do not change too much as you add more
grid points to your Raphael run.
- Rajiv Mathur
Intel Corp.
( ESNUG 377 Item 12 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 373 #11 ) Electromigration Is Much Worst In One Way Lines
> So far, I've only uncovered ElectronStorm by Simplex as the only tool
> currently in the market that does EM analysis on signal nets. Am I
> missing something here? There's got to be more out there than this.
> Avanti has something in the works for this, but it won't be available
> until Q1/Q2 of 2002. What about Synopsys, Cadence, Mentor Graphics?
> Any new startups? HELP!
>
> - Caesar M. Abedin
> Applied Micro Circuits Corp. Andover, MA
From: John Weiland <jweiland@intrinsix.com>
John,
I'm assuming here that Caesar is aware that eleoctromigration problems are
far worse in lines with unidirectional current flow than with bidirectional
flow. In power supply lines, current is always flowing in the same
direction. In signal lines, it flows in both directions, depending on
whether the line is switching from 0->1 or 1->0. That's why the analysis
tools all concentrate on power supply lines.
- John Weiland
Intrinsix Corp.
( ESNUG 377 Item 13 ) ------------------------------------------- [09/19/01]
From: Robert Hindle <Robert.Hindle@st.com>
Subject: Help! How Can I Simulate 12.5 M Gate Designs In Verilog with SDF?
Hi John,
As part of the tapeout checklist for our large designs, we like to run a
subset of chip level tests using fully annotated gate-level simulations in
order to verify interconnect timing, false/multicycle paths and as a general
sanity check of our flow. This has been OK until recently, when we started
hitting the limits of our tried-and-tested simulation tools. I've tried a
few different simulators on Solaris, but anything running at 32-bits will
not cope. We hit the 4 Gb footprint limit. I'm now looking to using 64-bit
simulators as a solution to our problem, Modelsim being the only one I've
tried so far. Is this the only 64-bit simulator available at the moment?
I wanted to garner opinon from any of your readers who have experienced
similar problems, what tools they've found to provide good performance/price
(or not, as the case may be) and what problems they may have faced porting
to 64-bits (eg. PLI routines, memory usage etc.)
I'm running on Solaris 2.7/2.8 machines with up to 12Gb of total available
memory.
- Robert Hindle
STMicroelectronics
( ESNUG 377 Item 14 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 376 #17 ) User Likes Averant Solidify Because It Works!
> The engineer from Tau Networks forgot to mention that the CEO of Tau
> Networks (Phil Mak) is on the board of Averant, and is the lead investor
> for Averant.
>
> - Simi Valecha
From: Martin Harriman <martin@taunetworks.com>
Hi, John,
Sorry! If I had known that Phil Mak was an investor or on the board at
Averant, I would have mentioned it. Little did I know.
Of course, I still stand by my comments. Indeed, the more we use Averant
here, the more I like it. We're now verifying blocks with some nice
interesting pipelines and more complicated temporal behavior, and it's
working out very well indeed. It's really very nice to be able to prove
that module X will generate exactly the "right thing" three cycles from
now, especially when module X has a few thousand bits of inputs and a fair
amount of internal state. I'm happy that I also have SpecMan and VCS. Of
course, there are certainly some behaviors I haven't been able to verify
in Solidify. But for the properties I can prove in Solidify, it's been
great.
So there you go. I don't think I'm biased by the connection I didn't know
about. I'm pretty sure I like the tool because it's helping me verify my
designs.
- Martin Harriman
Tau Networks
---- ---- ---- ---- ---- ---- ----
From: "Behrooz Zahiri" <bzahiri@averant.com>
Hi John,
It would be great if our customers were also investors. So far, all of our
customers have only purchased product, and none have purchased equity.
However, many customers and suppliers have common investors and it can help
with introductions, but it becomes irrelevant as extensive technical
evaluations are done prior to each purchasing. There can be no secrets,
Solidify has to provide a substantial value or else it will not be selected.
- Behrooz Zahiri, VP of Marketing
Averant
( ESNUG 377 Item 15 ) ------------------------------------------- [09/19/01]
From: Maynard Carlson <mcarlson@boi.hp.com>
Subject: What Competes With Synchronicity's IP Gear Design Reuse Tool?
John,
Do you know of any competitive tools to Synchronicity's IP Gear design reuse
tool? Thanks for any pointers.
- Maynard Carlson
Hewlett-Packard
( ESNUG 377 Item 16 ) ------------------------------------------- [09/19/01]
From: Peter Kamphuis <peter.kamphuis@infineon.com>
Subject: An Undocumented -log_changes Option To DC's change_names Command
Hi, John,
By chance I came across SolvNet article Methodology-165, describing about
Design Compiler's change_names command and Formality. The example in the
article uses the -log_changes option of change_names. This option is not
documented and offers a very nice way of cumulatively logging the changes
of multiple change_names commands. (That means you'll end up with a list
of name changes between the design before the first and after the last
change_names command.)
This log file is not only valuable input to Formality, but also to other
formal verification tools. Use something similar to the following (in
Tcl). Note that you must delete the log file first, in case it already
exists.
file delete -force name_changes.log
change_names -rules my_rules_1 -log_changes name_changes.log
change_names -rules my_rules_2 -log_changes name_changes.log
I checked with Synopsys, this option can be used without danger. It will
be documented in a future version.
- Peter Kamphuis
Infineon Technologies AG Munich, Germany
( ESNUG 377 Item 17 ) ------------------------------------------- [09/19/01]
From: Chia-Lan Li <cli@tmp.medtronic.com>
Subject: How Do I, Step By Step, Create Statistical Wireload Models For DC?
Hello, John,
I am a design automation engineer and is currently researching the mechanism
of developing statistical wireload model for my company's process technology.
I searched in your deepchip web site and could not find any discussion on how
statistical wireload model is generated, step by step. I have read Synopsys
available on-line manuals, searched SolveNet, and asked my Synopsys AE. No
document or AE can answer it. Instead, there is a lot of criticism on the
accuracy of vendor provided "statistical wireload models" in a library vs.
custom wireload models for a specific design floating in various ESNUG posts.
Help!
- Chia-Lan Li
Medtronic, Inc. Tempe, AZ
( ESNUG 377 Item 18 ) ------------------------------------------- [09/19/01]
From: David Wang <wang@ati.com>
Subject: Two Users Question PrimeTime On Its Interface Logic Models (ILMs)
John,
Has anyone used PrimeTime's new ILM capability? I'm interested in other
people's experiences.
- David Wang
ATI
---- ---- ---- ---- ---- ---- ----
From: [ A Modern Major General ]
John,
I need to remain anonymous please ... thanks!
I am closing out on a 2 M gate equivalent chip (mix of logic, memory and
cores) and I'm moving onto something nearly 4X the complexity.
I used Primetime for timing closure, both on a block and top level -- two
levels of hierarchy from a physical design perspective. One thing is clear
for the next chip -- there is no way I'll be able to run a full netlist in
PrimeTime, especially if I want to have results in a reasonable amount of
time.
To read in the full netlist, back annotate (DSPFs) and do an update_timing
took about 2 hours. Generating very detailed timing reports, including
full path, clock skew, histograms, etc, took nearly 18 hours -- on a 900
MHz P-III running Linux with sufficient memory. (The chip has a dozen+
different clock domains to deal with, plus scan, bist, jtag, etc.)
To get run time down in the highly iterative early stages of timing closure,
I created block level ILMs to use for top level timing. This brought the
top level runtime down to 5-6 hours.
Overall, the ILM procedure worked reasonably well, but of course, wasn't
without its problems. Synopsys helped work around the problems in the
2000.11 drop with a set of procs, and the 2001.08 drop due shortly is
supposed to fix these problems, so that the procs are no longer needed.
As I ramp toward the next project, I'm interested in the ESNUG community's
experience on 5-10 M gate ASICs, especially comments on ILM usage, if anyone
has succeeded in staying on 32-bit CPUs or if they've had to move to 64-bit
platform, or any other information that can be shared.
I was surprised to look on the Synopsys SolvNet pages and only find one
article related to ILMs. Does that mean it hasn't been hammered on by the
design community to any great extent?
I would also be interested in any user feedback on PrimeTime-SI.
- [ A Modern Major General ]
( ESNUG 377 Item 19 ) ------------------------------------------- [09/19/01]
From: "Derek Brasili" <derek.brasili@cavium.com>
Subject: How Do I Create Actual True Internal Clocks In Synopsys PrimeTime?
Hi, John,
I am running PrimeTime on a top level module. Under this top level module
it calls a P&R gatelevel netlist and a custom design DB file. Within this
top level module I create a clock called ECLK. This clock is generated
from a global clock called RCLK. Now ECLK will rise/fall 80 ps after RCLK
does. We have a clock expert that will give me all the information I need
for ECLK. Now I don't want PrimeTime to analyze ECLK. I want to define it
by "create_clock". PrimeTime will not let you do this because ECLK is an
internal net to this top level module! I found a TCL script on Synopsys's
website called "create_net_clock". This supposedly allows you to create
clocks on internal nets. But what it does is traces its way back to the pin
in the top level module that creates ECLK. This happens to be RCLK.
So then it actually puts the clocking information for ECLK onto RCLK, thus
wiping out the original waveform I put on RCLK using the "create_clock"
command. The only way I have found to make this work is to make ECLK a pin
in the toplevel module.
Does anyone have a way to create a clock in PrimeTime on an internal net?
- Derek Brasili
Cavium
( ESNUG 377 Item 20 ) ------------------------------------------- [09/19/01]
From: "Russ De Hoedt" <russell.dehoedt@conexant.com>
Subject: Want Expanded PrimeTime 'clock network delay (propagated)' Reports
Hi John,
When using PrimeTime, is there anyway to get the reports to expand the
"clock network delay (propagated)" statements to see how PrimeTime is
actually calculating the clock paths? With circuit clocking getting more
complex and library modeling issues, I'd like to be able to look at the
numbers to increase my confidence in what is being reported, instead of
blindly trusting Primetime. Below is an example.
Point Incr Path
-----------------------------------------------------------------------
clock TCK (rise edge) 0.00 0.00
clock network delay (propagated) 9.02 9.02
ucore/utestblk/utst_gpio_mux/portb5_sel_reg_0/CK (SDFFX1)
Thanks,
- Russ De Hoedt
Conexant Systems, Inc.
( ESNUG 377 Item 21 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 375 #6 ) PrimeTime Reports Ignored Exceptions; But Not WHY
> PrimeTime reports "ignored exceptions" yet doesn't state -WHY- the
> exception was ignored. Nor is there any capability to help debug the
> cause for the ignored exception. I'm painfully aware of all the reasons
> why the exception *may* be ignored, but what would be really nice would
> be for PrimeTime to give me the answer so when I push the button on a new
> customer's design I won't be faced with days of work to analyze reams of
> ignored exceptions.
>
> I've requested this enhancement from Synopsys yet there has been no
> action. Anyone out there have a home grown solution? Does Ambit also
> have this shortcoming?
>
> - [ Feeling Exceptionally Ignored ]
From: [ A Synopsys PrimeTime CAE ]
Hi John,
PrimeTime currently allows you to report ignored exceptions but does not
list a reason why an exception was ignored. Admittedly, it would be nice
to report the reason why it was ignored to help in the debug of PrimeTime
analysis scripts.
Much of the reason why PrimeTime only lists the ignored exceptions is
for the sake of memory efficiency; PrimeTime drops or does not save the
information that would be needed to determine the reason why, thereby
reducing memory usage. In a future release, Synopsys will investigate
some method of maintaining the information needed to report a reason for
an ignored exception, but such behavior needs to be balanced with how
much it impacts memory usage.
Most ignored exceptions are caused by invalid startpoints or endpoints
or non-existent paths, so here are some basic tips for writing proper
exceptions:
1. Ensure all *-from* points are valid startpoints:
- Primary input ports
- Register clock pins
- Segmented path startpoints
2. Ensure all *-to* points are valid endpoints:
- Primary output ports
- Register data input pins
- Segmented path endpoints
3. Avoid excessive use of -through option or excessive use of wildcards,
which can result in many redundant or invalid exceptions.
Here is an example of a bad exception that will result in lots of ignored
exceptions:
set_multicycle_path 2 -setup -end -from A_reg*/CP -to B_reg*/*
Since the exception terminates at ALL of the pins associated with registers
B_reg, most of the exceptions will be ignored because invalid endpoints
have been included in the "to" list. The "-to B_reg*/*" includes the clock
pin and data output pins of B_reg, which are all invalid endpoints. Only
the data input pin is a valid endpoint. This bad example should be written
like this:
set_multicycle_path 2 -setup -end -from A_reg*/CP -to B_reg*/D
Lastly, users can use the following checklist to locate the root of ignored
timing exceptions:
- check to see if the timing path might not exist
- check for invalid startpoint and endpoint
- check if a set_disable_timing command blocks the path specified by the
exception
- check the output of check_timing -ignored_attributes
- check the order of precedence for timing exceptions
- check if the exception is applied on an unconstrained path
- path segmentation might have been specified incorrectly
Understanding and writing good exceptions at the start is *key* to reducing
the amount of ignored exceptions by PrimeTime.
- [ A Synopsys PrimeTime CAE ]
( ESNUG 377 Item 22 ) ------------------------------------------- [09/19/01]
From: "Paul Stuverud" <Paul.Stuverud@Unisys.Com>
Subject: Synopsys SmartModels Run *Painfully* Slow On Cadence NC-SIM VHDL
Hi, John,
We are running a Synopsys SmartModel for a vendor's proprietary ASIC hard
core on Cadence VHDL NC-SIM3.2. The SmartModel version runs in approx. 45
minutes on the NC-SIM simulator (same TestBench). We have also tried NC-SIM
versions 3.0, 3.1 & 3.3 with roughly similar results. We have also tried
both Sun and HP platforms with roughly similar results. The same SmartModel
runs in approx. 5 minutes on the Modeltech MTI simulator (same TestBench).
This is for both Sun and HP platforms. This is approx. 10X the performance
of NC-SIM. (By the way, the uncompiled native code model runs in less than
1 minute on the NC-SIM simulator.)
Has anyone else experienced relatively poor performance of SmartModels on
NC-SIM when compared to the MTI simulator? Is there some inherent difference
between the two simulators that would explain the difference is simulation
times? Is the NC-SIM poor performance limited solely to VHDL simulations or
does it include both VHDL and Verilog simulations? Is there anything that
can be done to resolve this problem?
- Paul Stuverud
Unisys Corp.
( ESNUG 377 Networking Section ) -------------------------------- [09/19/01]
Silicon Valley, CA -- Dave Chapman, BSCS/MSEE, lots of verification exper.,
seeks contract in the bay area starting Oct 2. "dchapman@goldmountain.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.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
|
|
