"The combination of the semiconductor slump, the general economy and
then the tragic events of Sept. 11 are causing customers to slow
purchases even further. It's clear that some parts of the EDA offering
have been affected -- services, and anything that has to do with
capital spending, like hardware simulators or emulators."
- Ray Bingham, the CEO of Cadence (EE Times 10/8/01)
( ESNUG 379 Subjects ) ------------------------------------------ [10/11/01]
Item 1: ( ESNUG 378 #1 ) Thanks For DC 2001.08 Presto/Tcl/DW/Verilog Alert
Item 2: ( ESNUG 377 #3 ) Magma & User Happy About ESNUG Block Size Report
Item 3: ( ESNUG 378 #14 ) PhysOpt def2ver Script Is Now Downloadable
Item 4: ( ESNUG 378 #2 ) Turning Off The Secret "Consume Licenses" Switch
Item 5: ( ESNUG 378 #4 ) Equivalency Checking Finds Yet Another Presto Bug
Item 6: ( ESNUG 377 #9 ) Free GridWare Better Than Buying Platform's LSF
Item 7: ( ESNUG 378 #5 ) Cadence CTGEN vs. Silicon Perspectives Benchmark
Item 8: ( ESNUG 378 #10 ) Analog Simulator With PrimeTime For PCI Specs?
Item 9: ( ESNUG 373 #8 ) Flaws In The Solaris 7.0 vs. Linux PC Benchmark
Item 10: ( ESNUG 377 #22 ) SmartModels Are Faster In NC-Verilog vs. NC-VHDL
Item 11: Seeking Good/Bad Experiences With PrimeTime On Red Hat 7.0 Linux
Item 12: ( ESNUG 377 #13 ) How To Simulate 12.5 M Gate Designs In Verilog
Item 13: ( ESNUG 377 #10 ) Extract A Hierarchy From A Flat Gate Netlist
Item 14: What Are The Pro's And Con's Of Sync vs. Async Resets In Designs?
Item 15: ( ESNUG 376 #11 ) The Specman Side Of The Vera/Specman Debate
Item 16: A Useful PhysOpt Script For Pulling Tri-state Drivers Together
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 379 Item 1 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #1 ) Thanks For DC 2001.08 Presto/Tcl/DW/Verilog Alert
> I want to do a rant about the new 2001.08 ver of DC. We've switched over
> to it and had nothing but problems. Tcl scripts which ran flawlessly on
> 2000.11-SP2 break for variables that should be set that aren't (such as
> "synopsys_program_name"), DesignWare license issues during initial linking
> and flattening after compiles, Presto issues, and illegal Verilog being
> written out. Ugh. I hate debugging new versions, and I think we'll wait
> to switch over when 2001.08-SP1 gets released in the very near future.
>
> - Gregg Lahti
> Corrent Corp. Tempe, AZ
From: "Gayatri Japa" <gayatri.japa@indiatimes.com>
Dear John,
Please thank Gregg for his advisary on DC 2001.08. We were thinking of
switching, but his letter has convinced us to wait for the SP1.
- Gayatri Japa
India Times
---- ---- ---- ---- ---- ---- ----
From: "Gregg Lahti" <gregg.lahti@corrent.com>
FYI, John,
DC 2001.08-SP1 was released for Sun/HP, but not for Linux. Insiders say
that the Linux release is going to be released mid-November.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 379 Item 2 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #3 ) Magma & User Happy About ESNUG Block Size Report
> [ 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 ]
From: Paul Pontin <Paul.Pontin@3dlabs.com>
Hi, John,
I wanted to thank you for putting the record straight so openly in ESNUG and
Deepchip. There is a lot of marketing dollars spent by "the big boys" to
blow the start ups out of the water. These new contenders should be allowed
to flourish or die on the strength of their technology alone. I feel ESNUG
is the ideal forum to allow the designers and managers to openly express
their opinions. If we look back over the last few years there has been a
huge market shift away from the old ECO/IPO flows. This technology is not
rocket science, it should have happened years ago. It took companies like
Monterey and Magma to push the pace. The EDA industry needs these start-ups
to make sure that the pace of development is kept in line with the growing
complexity of the silicon.
The EDA industry can no longer sit on its behind and collect revenues for
small incremental tool changes. The design community is not being well
served and we are struggling to make full use of the advances in silicon
technology. We need to help the start-ups as much as possible. It is a huge
risk relying on these unproven guys, but unless we push we will never know
what is possible.
- Paul Pontin
3Dlabs Egham, Surrey, UK
---- ---- ---- ---- ---- ---- ----
From: Patrick Groeneveld <patrick@Magma-DA.COM>
Thanks John,
Wanna become the moderator of the Magma Users Group? :)
- Patrick Groeneveld
Magma Design Automation Cupertino, CA
( ESNUG 379 Item 3 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #14 ) PhysOpt def2ver Script Is Now Downloadable
> I am sending you my DEF to Verilog perl script, def2ver. It will read a
> DEF (version 5.2) and generate a flat Verilog.
>
> - [ A Synopsys PhysOpt FAE ]
From: "John McGehee" <johnm@best.com>
Hi, John,
This PhysOpt def2ver script would make a nice addition to your Downloads
section in DeepChip.
- John McGehee
Voom, Inc.
[ Editor's Note: Agreed; I'll put it in the DeepChip Downloads. - John ]
( ESNUG 379 Item 4 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #2 ) Turning Off The Secret "Consume Licenses" Switch
> 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.)
>
> - Romas Rudis
> Intrinsix
From: Nikolaus Mittermaier <nikolaus@synopsys.com>
John,
The reason why a VHDL-Compiler is checked out during compile are the high
level optimizations done during compile. If you start from HDL, the
license is needed for:
1. DesignWare implementation selection
2. Sharing common subexpressions
3. Resource sharing (Sharable Operators: + - * > < >= <= = /= ==)
4. Operator reordering
If you do an incremental compile on a mapped Netlist a VHDL-Compiler
license is needed to do the incremental implementation selection for
DesignWare components.
> Has Romas tried setting the Synopsys variable:
>
> hdl_prefered_license = verilog
>
> You can do a list -variables all to see what it's currently set to. I
> think the default is vhdl.
>
> - Tom Cruz
> IBM
If you set the variable "hdl_preferred_license = verilog" and no HDL-Compiler
license is available then DC will check a VHDL-Compiler license for high
level optimizations. If the variable is set to Verilog and you read a VHDL
design, a VHDL-Compiler license will be checked out.
The default value of this variable is an empty string and therefore DC
picks the first available.
- Nikolaus Mittermaier
Synopsys GmbH Munich, Germany
( ESNUG 379 Item 5 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #4 ) Equivalency Checking Finds Yet Another Presto Bug
> A couple of months ago I discovered that Presto (DC's new HDL Compiler)
> doesn't have all the kinks worked out. Our team decided to use Presto's
> support for new Verilog features in our RTL code. ... Seems as though
> Presto is bug ridden. The Synopsys support engineer conveyed that much
> to me through my email exchanges with them.
From: Theo Band <tband@lucent.com>
Hi John,
I used Presto to speed up reading a Verilog netlist. The result was that
the netlist was broken because some bussed port got swapped. (2000.11-SP1)
I submitted the following bug report to Synopsys, Inc.:
module latchin ( din, min, cin, ti, te, .dout({dout_15_3, dout_15_2,
dout_15_1, .....})
After instantiation of the above module the connections to the "dout" bus
are swapped. Using the old netlist reader by setting
enable_verilog_netlist_reader = false
solves the problem. The problem was discovered by equivalency checking
close to tapeout. Since we do only PrimeTime verification and hardly any
functional verification on this netlist, I consider this a major bug.
Please inform your other customers about this error as soon as you're
able to recreate it.
The problem was identified and STAR 122936 has been filed. I cannot find
this STAR on SolvNet however. So be warned if you have these constructs in
your netlist while using Presto.
- Theo Band
Lucent Technologies Huizen, the Netherlands
( ESNUG 379 Item 6 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #9 ) Free GridWare Better Than Buying Platform'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: "Mike Sullivan" <mikes@netrake.com>
Hi, John,
We have been using Gridware with much success for the past 6 months in our
ASIC development work. I have used many of the alternatives including
vendor, custom, and shareware tools, and I find Gridware to be a worthy
solution. Our CPU farm is hard at work on simulations, compiles, and other
queuable type jobs. All under the direct control of Gridware defined
queues and policies.
Working in a small company where money for design tools is always an issue,
it is always nice to find a free solution with all the desired bells and
whistles!
- Mike Sullivan
Netrake Corp.
( ESNUG 379 Item 7 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #5 ) Cadence CTGEN vs. Silicon Perspectives Benchmark
> Cadence CTGEN's results: 466 ps skew, max trans of 490 ps, met the
> insertion delay, took around 6 hours, 3498 buffers used.
>
> Silicon Perspective FE clock tree results: 162 ps skew, max trans of
> 480 ps, met the insertion delay, took 7 minutes, 1820 buffers used.
From: "Donepudi Narasayya" <donepudi.narasayya@st.com>
Hello John,
I think that the slew & skew figures given in this benchmark are generated
by the clocktree generation tools right after clock tree generation. It
would be interesting to know the values of skew & slew after signal routing.
CTGen has an option of reporting post-route skew & slew if you provide it
with an RSPF. This can help us know how good is the correlation between
pre-route and post-route values (especially of the skew.)
In general, skew analysis done with a neutral STA tool like PrimeTime would
be more acceptable. This is because, CTGEN and First Encounter may have
different timing engines.
If the person who did the benchmark can do such post-route analysis also,
the benchmark would then be more realistic.
- Donepudi Narasayya
STMicroelectronics
---- ---- ---- ---- ---- ---- ----
From: [ The Lone Ranger ]
John, keep me anon.
I have some questions. These results look very impressive, but please give
us more and meaningful details! For example:
- Were his timing numbers pre-route, post-route, or post-extraction?
- Was WRoute used for routing?
- What was the utilization of the design?
- What extraction tool was used?
- What were the clock frequencies?
- Where were the CT buffers legalized?
- Did the pre-route and post-extraction timing numbers correlation?
I am not challenging his results, but numbers w/o this context are about as
meaningful as a timing report out of DC with WLMs in a 0.10 library!
If these numbers were pre-route, then they are might not be as exciting. A
guy could write his CTS tool in Perl and do better than SPC and CTGen (as
long as he used his own timing engine, was optimistic about interconnect
delay, and slapped the buffers any which where!)
- [ The Lone Ranger ]
---- ---- ---- ---- ---- ---- ----
From: "Jim Jok" <jok@erols.com>
John,
Did this post indicate if the user's results were obtained with post-routed
SDF? Or were they obtained from the preliminary report which comes from
clock tree insertion tools. Normally the initial report is based on steiner
routing or some other ball-park algorithm for routing estimates. To be
fair, the post-routed SDF should be used.
We have noticed that CTGEN is using 'extra' buffers, also. The tool seems to
fair well with small die, but on the larger dies the tool is behaving as
this user pointed out. As in most production environments, time for doing
what-if and detailed analysis is hard to come by. Thus the solution is the
main goal. The vendor needs to do some serious looking at these issues or
lose out to the competition.
The combination of large die and high-speed requirement is a hurdle that
might be new to the existing CTGEN algorithm and the algorithm needs to be
re-visited and possibly refined. Also, did Silicon Perspective use the same
array LEF as the CTGEN tool or were parasitics obtained from some other
step? i.e. 8 minutes vs. time for some other step to get parasitics plus 8
minutes?
Maybe this user's benchmark could be thrown to the CTGEN developers to
determine if they can drive the tool to meet the required performance.
I would like to see Cadence address the clock tree issue since if one is
using a Cadence flow, life is much simpler if you can stick with CTGEN.
- Jim Jok
---- ---- ---- ---- ---- ---- ----
From: "Eric Meyer" <eric.meyer@audiologic.cirrus.com>
John,
We've seen some "interesting" CT-Gen behavior related to not having accurate
caps in the .LEF file (e.g., too many buffers, optimistic/pessimistic skew,
and optimistic/pessimistic insertion delay.)
I'd be interested in other's experience with Silicon Perspectives FE and
whether or not they got back good Silicon.
- Eric Meyer
Cirrus
( ESNUG 379 Item 8 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 378 #10 ) Analog Simulator With PrimeTime For PCI Specs?
> One approach is to constrain the delay using the set output delay and use
> some arbitrary load capacitance. Then using PrimeTime to generate a
> timing report for the clock-to-output paths. From the timing
> report determine the delay up to the input of the PCI output buffer. To
> determine the delay associated with the buffer use an analog simulator
> tool like Interconnectix and IBIS models simulate the driver and the
> backplane. Add this delay to the internal delay from the PrimeTime
> report to get the total delay.
>
> Is this good appoach or is there a way to do this only using PrimeTime?
>
> - Lou Villarosa, Jr.
> Honeywell Space Systems Clearwater, FL
From: "Hui Fu" <Hui.Fu@infineon.com>
Hi John,
I think the PCI spec has the load information for 3.3v signal timing.
(rev2.2, pg 123 and pg 128). For maximum timing, the condition is 10 pf
with 25 ohm pull down/up for rising/falling edge. For minimum timing,
the load is 10 pF with 1 K ohm pull up and pull down. However the V/I
curve requirement for the driver has to be respected also. But that
should already take into account during your I/O cell (pad) design.
Extensive analog simulation should be already performed during the I/O
cell design.
To be able to use PrimeTime for delay calculation, the resistor effect
need to be considered in your library characterization. The values given
in the .lib or your STAMP model are simulated with the specified
resistance( 1 K for min, 25 for max). So you only need specify the pad
load (10 pF) to get the right delay of the pad cell. However if the
library has not take those into account, you can not avoid to use the
analog simulator along with PrimeTime.
- Hui Fu
Infineon Asia Pacific
( ESNUG 379 Item 9 ) -------------------------------------------- [10/11/01]
Subject: ( ESNUG 373 #8 ) Flaws In The Solaris 7.0 vs. Linux PC Benchmark
> The systems I used were a Sun Enterprise 420 (4x450MHz processor) running
> Solaris 7 and a VA Linux Systems 2200 Series 2U Linux Server (2x800MHz
> Pentium III) running Red Hat Linux 6.2. A direct MHz speed comparison has
> the PC running 1.8x Mhz of the Sun.
>
> The following table lists the values reported back from the Unix "time"
> command on a couple of small synthesis jobs.
>
> job cpu Sun cpu Linux PC ratio
> 1 3059 sec 1715 sec 1.8x
> 2 652 347 1.9x
>
> Seems to track the MHz scale fairly nicely.
>
> - Scott Evans
> Sonics Inc. Mountain View, CA
From: Frank Wolff <wolff@eecs.cwru.edu>
Hi John,
I have a problem with the way these benchmarks are being compared. There
seems to be a underlying assumption that the application software can
distribute the workload to other processors. Application software and its
associated algorithms have to be specifically written to do this.
Observe that, 800 Mhz / 450 Mhz is 1.78 (i.e. 1.8). That would seems to
indicate that the EDA tool is written for a uniprocessor (i.e. no "fork()",
process spawning, etc). Slightly higher numbers (1.9), indicated that the
other processor is being used for doing strictly operating systems functions
used by the application software (i.e. heavy I/O, page swapping).
Correct me, if I am wrong on this point.
- Frank Wolff
Case Western Reserve University Cleveland, Ohio
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@sonicsinc.com>
Frank,
I had no intent to imply that any speed-up came from running on a
multi-processor machine. I was only reporting on the hardware I ran on
for completeness. As you mentioned, the other processor's are likely
being used for OS and other tasks which allows the single threaded DC
shell to hopefully use close to 100% of the CPU it has been allocated to.
- Scott Evans
Sonics Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Frank Wolff <wolff@eecs.cwru.edu>
Hi, Scott,
Thanks for your response. My personal experience is that EDA/IT support
people want to dump and jump to Linux-based Intel machines because they see
results like this. It would be nice if multi-processor benchmarks will list
the average CPU utilization of "each processor" during the run of the
application.
This benchmark makes an important statement (some will say, slam) to Sun
Microsystems in the EDA world to help EDA tool developers to re-write their
software for multi-processors. Clearly, synthesis and P&R tools are CPU
intensive and the speed demons are winning. But sooner or later, the speed
demons of the world will hit the brick wall, too.
In the limit, EDA vendors who still have single thread software will not
survive. Ironically, at this year's DAC, Avanti has already rewritten some
of their products for multi-threads (of course, you must acquire additional
licenses!) showing performance gains. While sitting at this presentation,
it was amazing how many decision makers didn't understand these issues.
- Frank Wolff
Case Western Reserve University Cleveland, Ohio
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@sonicsinc.com>
Frank,
As an EDA user I'd much prefer to buy a $5K Linux machine which will run my
jobs twice as fast (hopefully up to 4x with the 2.1 GHz machines but things
don't always scale directly) than $100K for another dc_shell license to
accomplish the same task on the Sun Solaris box. So lump me in the category
of dump and jump... I agree we need to better specify what we're comparing.
As you mention, the licensing issue is likely the sticky point for the EDA
vendors/users to work out. DC has a top down compile mode which allows
you to run multiple jobs concurrently (definitely not what you would call
multi-threading) but each one requires it's own license so is not of much
use to companies with limited budgets. As long as the computer companies
keeping coming out with bigger/faster boxes there's not much incentive for
EDA vendors to deal with multi-threading their algorithms to improve
performance. My crystal ball doesn't tell me how far away is that brick
wall you mention.
- Scott Evans
Sonics Inc. Mountain View, CA
( ESNUG 379 Item 10 ) ------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #22 ) SmartModels Are Faster In NC-Verilog vs. NC-VHDL
> 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?
>
> - Paul Stuverud
> Unisys Corp.
From: "Mick Posner" <mposner@synopsys.com>
Hi John,
I can shed some light on Paul's issue but I am afraid that I cannot solve
the problem he has. First of all some clarification. If the model is of
a vendors proprietary ASIC, then it would have been created by either the
Synopsys Verilog Model Compiler, VMC, VHDL Model Compiler, VhMC or the
C Model Compiler, CMC. The vendor uses the compiler to create a model
that interfaces with the simulator via the SWIFT interface. The models
look a lot like the Synopsys SmartModels but the vendor supports the model
function, Synopsys only supports the models creation. We call these SWIFT-
based models, not SmartModels. SmartModels are the Synopsys created and
supported verification models shipped and licensed as part of the DesignWare
library.
I expect the reason Paul is seeing different simulation speeds between
MTI and NC-SIM is down to the way that each simulator interfaces to SWIFT.
This is, of course, a guess as Synopsys does not have access to MTI or
NC-SIM.
MTI created their own direct interface to SWIFT. They have a layer in their
simulator kernel that talks directly to the SWIFT model thus their is
minimal interaction overhead. Synopsys VCS and Scirocco interface to SWIFT
in the same way & have the added advantage of interfacing via a full bussed
model interface. This yields even more simulator model performance.
NC-SIM has two interfaces to SWIFT. If you access the SWIFT based model on
the VHDL side you are going through what I think is the same SWIFT interface
that was used in Leapfrog. If you access the SWIFT based model via the
Verilog side you have a slightly different interface. On the Verilog side,
you make use of what is called lmtv, Logic modeling to Verilog. This is the
Synopsys written and supported SWIFT interface for NC-Verilog. I expect
the Synopsys lmtv interface is more optimized that the old Leapfrog one.
Feel free to pass on my name to Cadence. I would be happy to work with them
to improve the performance of their SWIFT interface. A slow SWIFT interface
does not look good for both Cadence and Synopsys.
- Mick Posner
Synopsys Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: "Paul Stuverud" <Paul.Stuverud@Unisys.Com>
Hi, John,
Since I posted this message, we have identified the root-cause of the
problem and implemented a solution. Here's a summary of what we found:
Cadence revealed that there are actually two different PLI's developed...
one for NC-VHDL, and another for NC-Verilog. The PLI for NC-Verilog was
actually written by Synopsys. The PLI for NC-VHDL is a derivative of an
old Leapfrog interface that has been migrated forward. Because of this,
there is more efficiency when running Synopsys SmartModels in NC-Verilog
vs. in NC-VHDL.
So what we're doing is running mixed-mode simulation. The SmartModel is
running in NC-Verilog, and the rest of our circuit is running in NC-VHDL.
The performance is now acceptable.
By the way, it's too bad I didn't post this problem on ESNUG months ago.
We originally ran into it back in late June and didn't didn't ID the root
cause until early Sept! We didn't think to compare NC-Verilog and NC-VHDL
runs until very late, even though we had both versions of the model and
simulators avail to us early-on.
- Paul Stuverud
Unisys Corp.
( ESNUG 379 Item 11 ) ------------------------------------------- [10/11/01]
From: "Bob Flynn" <Bflynn@massana.com>
Subject: Seeking Good/Bad Experiences With PrimeTime On Red Hat 7.0 Linux
John,
I am unsure how to get involved with a discussion regarding use of Synopsys
tools and Linux on your site. I have noticed some comments but they appear
to be of people's experiences rather than config issues.
Basically, I am looking to get some feedback from anyone who has experience
of running PrimeTime on a Red Hat 7.0 machine.
- Bob Flynn
Massana
( ESNUG 379 Item 12 ) ------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #13 ) How To Simulate 12.5 M Gate Designs In Verilog
> 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?
>
> - Robert Hindle
> STMicroelectronics Bristol, UK
From: "Chris Browy" <cbrowy@avery-design.com>
Hi, John,
Avery offers solutions to provide scalable performance and capcity increases
for our Verilog simulations. Please take a look at Avery's products:
* SimCluster scalable distributed Verilog simulation that delivers
5-10X performance and capacity speedup, and
* TestWizard testbench automation offering Verilog and C/C++
transaction-based verification, protocol analysis, and functional
(architectural) coverage analysis
These products are part of our new SimLib add-on product series that extends
your existing Verilog simulator (VCS, NC-Verilog, MTI). SimLib add-ons are
Verilog PLI packages that link to the simulators you already own.
- Chris Browy
Avery Design Systems
---- ---- ---- ---- ---- ---- ----
From: "Bala Sreekandath" <bsreekan@synopsys.com>
Hi, John,
I am a member of the Applications group in Synopsys working with VCS. I saw
Robert's posting on ESNUG and wanted to get back to you to inform you that
VCS has a 64-bit port for Solaris and HP. This is officially not released
because typically VCS is very memory efficient and hence we don't have a big
demand from customers for the 64-bit port. But we have used this 64-bit
port very successfully at a few customer sites where they have had problems
with capacity issues.
We also have a mode where this 64-bit port can be run in a cross compiled
mode so that the compiles are done in the 64-bit mode and the simulations
can be still done in a 32-bit mode so that performance is not sacrificed
(64-bit ports usually run slower than the 32-bit ports).
- Bala Sreekandath
Synopsys
( ESNUG 379 Item 13 ) ------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #10 ) 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: "Sanjeev Patel" <sanjeev.patel@wipro.com>
John,
I have a couple of ideas:
1. If the gate instance names reflect the hierarchical block name, one
can *create the hierarchy by instance name* in synthesis tool. For
example, if all instances in block A are called uA_g1, uA_g2 etc in
the flat netlist of say design mychip, you can use a command to
"group mychip_uA_* " to re-create hierarchical block A in the netlist.
Then, write netlist for this block and use it in simulation along with
the rest of the blocks in RTL.
You have to be careful however to use switches that allow "preserving
of buses" and "avoiding feedthroughs" so that you get exactly the same
port list back as that in the RTL of that block. Also, you may need
to run sed commands to remove the prefixes that will appear in the port
names (legacy flat netlist.)
(I am using terms from Ambit, like create_hierarchy, preserve_busses
and -no_feedthrough, but I'm sure similar commands exist in Design
Compiler, too.)
This method is not my choice though. I would go the rather clean way,
enabled by logic equivalence checking. See below.
2. Make required changes to the netlist. Make equivalent change to the
RTL of the correspoding hierarchical block. Then perform a *new RTL
(full chip) to changed netlist* equivalence check. (Or alternately,
synthesize the new RTL and perform *newly synthesized chip netlist to
hand-edited chip netlist* compare.)
Here we simulate only RTL, no gates and hence is faster and cleaner.
Once RTL is found functionally okay, it's just a matter of a few hours
in equivalence check to validate the manual edits in netlist. The
process can be made even faster by selectively comparing only the
instances of interest while ignoring the others.
This is a good method for ECOs. Verplex easily handles RTL to netlist
equivalence check for large designs.
I can explain more if there are any questions.
- Sanjeev Patel
Wipro Technologies Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <gzimd@improvsys.com>
Hi, John,
I ran into the issues with a flattened layout and a hierarchical
design way back in my Big Yellow Box (read Kodak) days when we first
started working with Motorola as a vendor.
At that time after getting back a flattened design from their tools, I
created some scripts that used DC to re-group the parts in the flat
netlist back into their hierarchical "containers". This was possible
since with the Moto flow back then, the instances in the flattened
design had their names modified to contain their entire original path.
I started parsing the netlist and found all of the hierarchical block
names and then performed "group" commands working top down to generate
a "hierarchical" post layout netlist. This was done via a lot of
brut force techinques since back then I didn't know much Perl.
My basis for performing this task was to make life easier for me in
post-layout simulations so that I could make sense of nets that I was
tracing for timing. Even back then tracing through a flattened 100 K
gate netlist was absolutely NO fun... ;-)
Now working out this back-end flow was the last thing I was able to
complete before leaving back in '96 and I'm sure that there's better
ways to do it than the way I hacked together then. But suffice it to
say that DC and "group" using "find" and instance names makes the task
pretty quick and painless (after getting that first script together).
Anyway, I've thought for a long time that this should be a service
provided by the place and route tools. What designer just LOVES tracing
through a flat netlist to find a timing problem after working for months
on a hierarchical design to keep DC happiest??? Would be nice if after
P&R the tools could spit back a hierarchical netlist that was guaranteed
equivalent to the flattened one, generate hierarchical SDF to match and
feed THOSE files back to the designer for simulation and post-layout
verification, no??? (Speaking of SDF, I think that if the instances keep
their hierarchical names after flattening, you can end up using the same
SDF on both versions of the netlist, flat and hier.)
- Gzim Derti
Improv Systems, Inc. Rochester, NY
( ESNUG 379 Item 14 ) ------------------------------------------- [10/11/01]
From: Siegfried Weidelich <Siegfried.Weidelich@McDATA.com>
Subject: What Are The Pro's And Con's Of Sync vs. Async Resets In Designs?
Hello, John,
We currently use synchronous resets in our ASIC designs. We are finding a
lot of time is spent meeting timing on synchronous resets, especially at
clock speeds 200+ MHz. We are considering switching to asynchronous resets
so that the logic connected to the D pin is not impacted by reset.
Can someone list the pros and cons of sync vs. async resets? Are there RTL
versus gate simulation issues? What are the PrimeTime and test issues?
How do you avoid them?
- Siegfried Weidelich
McDATA Corporation
( ESNUG 379 Item 15 ) ------------------------------------------- [10/11/01]
Subject: ( ESNUG 376 #11 ) The Specman Side Of The Vera/Specman Debate
> I am experienced with are Specman and Vera. Majority of the people I am
> familiar with are using Vera and some are using Specman. I don't know
> anyone using Rave.
>
> - Faisal Haque
> Cisco Systems
From: Yossi Levhari <yossi@veri-sure.com>
Hi John,
I want to add a little more to the Specman/Vera debates. I am wondering if
people can see:
1) How much revenue Vera is claiming within deals including (VCS, Design
Compiler, wave viewers, VCS)? The advantage Verisity has is if they
say they sold in $1, you know what they sold. For example, I wonder
has any Synopsys client bought just Vera with a MTI simulator?
2) I would like to see a clear message from Synopsys about what SystemC
is and what Vera is and how they connect. (A year ago this was not
clear.)
I would like to add a ('Specman biased') opinion to counter Faisal Haque's
'VERA biased' ones that he expressed in ESNUG 376 #11.
> 1) Performance. I give Vera the edge here. Specman does not work with
> Save/Restore in VCS. But both tools need to improve in this area.
Specman works very nicely with save and restore in VCS. It also allows just
saving one side (Specman, or RTL) side. Even when I worked in Verilog, it
always stays around 10-30% overhead on the testbench side so even if the
verification is improved 10x it still will only improve overall performance
by 20%.
> 2) Ease of Learning. Definitely give a huge edge to Vera. Whereas Vera
> is very similar to traditional languages such as C++ and Verilog,
> Specman has its own unique, non-intuitive lexicon. This I think is
> its biggest weakness. Learning curve for Vera is in weeks whereas
> learning curve for Specman is in months. Feature wise they are both
> powerful and very comparable.
It seems that this is the most major point being made here, and I would
guess that Faisal's first language is VERA (of the two that is). In general
terms Vera is more 'verilogish'. It is not like C++ unless constructors is
considered C++. I would make a statement that an engineer coming from a
solid 'software engineering background' will see Specman as easier where the
opposite (EE background) will see Vera as easier.
> 3) Support for Concurency . Give Vera an edge here, too. It has more
> built-in concurrency constructs which are more generic and therefore
> more widely applicable.
Specman has 'fork/join' (called "all off", "first off")
> 4) Test case generation efficiency. Specman gets the edge here because
> of its more powerful recursive constraint solver.
Actually even here this is not true. The constraint solver works its way
recursively on the verification hierarchy, but for each item it generates it
does it 'correct by construction' (somehow recursively I hear backtracking.)
> 5) Testbench creation efficiency. Vera gets an edge here. This is due to
> longer debug cycles, because of the non-intuitive nature of Specman.
Specman has a very powerfull debugger + wave form support. (I do not know
this about VERA.) The Specman debugger has the ability to debug parallel
threads together, having break points on both code, and data events.
> 6) Temporal expressions. They appear to be even. Vera has recently added
> support for temporal expressions. However, Vera's syntax appears to be
> more intuitive.
Be serious !!! How can you compare Vera's Temporal? Have you used it ?
> 8) Code Reuse. Vera has the edge here because of the virutalized RTL
> interface capabilities, also the more structured object oriented
> paradigm is easier to maintain in a large collaborative environment.
Code reuse is not a function of a language. It is a direct outcome of your
architecture. So I do not see how this statement can hold without
collaborating data. How many projects have you taped-out using Specman, and
how many VERA ?
And what about:
Coverage ?
FSM coverage ?
synchronization events ?
VHDL ? mixed VHDL-VERILOG models ?
Verification Advisor ?
Models ?
IP ?
Support ? (questions etc ...).
Also, I would like to know how many of the original System Science R&D have
stayed aboard at SNPS as their product seems very 'stable'. (No new
features, that is.) Verisity is very rapidly pursuing new frontiers
(coverage maximizer/formal demos etc ....).
- Yossi Levhari
VeriSure Consulting Ltd. Zichron Yaacov, Israel
( ESNUG 379 Item 16 ) ------------------------------------------- [10/11/01]
From: "Mike Montana" <montana@synopsys.com>
Subject: A Useful PhysOpt Script For Pulling Tri-state Drivers Together
Hi, John,
We're seeing more ASICs using that "wonderful" design feature called an
internal tri-state bus. I use "wonderful" because optimizing tri-state
busses to meet timing and design rules is a real challenge for DC and
PhysOpt. You can't simply go in and add buffers to fix problems on a
tri-state net. And in some libraries, there may only be 1 internal tri-
state driver so cell sizing is not even possible. The only solution for
this problem is to make sure all the drivers on a tri-state net are placed
close enough together to avoid timing and design rule violations.
In the past, this was a manual task done in the back end. But with PhysOpt,
you can eliminate these tri-state issues before handing off the netlist to
route. But you must "prioritize" placement of the tri-state drivers
relative to the other cells in the design if you're using PhysOpt.
The script attached was created by an AC here in Dallas working with a local
PhysOpt customer. Here's how it works:
1) The script parses the netlist to identify all the tri-state nets
from the net attribute "three_state."
2) Once these nets are identified, the script finds all of the gates
that drive each tri-state net.
3) Finally, the script groups these gates into a movebound. A movebound
is a floating soft region. PhysOpt can place the cells in the
movebound anywhere on the die based on timing, DRC, and congestion
rules while also keeping them close together. (See the man page
for the set_bounds command for more user options.)
The script outputs a movebound for each group of cells driving tri-state
nets in the design. The script does not define a size for the movebounds,
but rather assigns the movebounds with a level effort high. PhysOpt uses
an internal algorithm to size the movebounds and it places the gates
accordingly. Other effort levels for the movebound command are also
available (low, medium or ultra) to control how tightly the cells are
grouped.
The result, the cells attached to each tri-state net are pulled close
together eliminating timing and DRC violations.
- Mike Montana
Synopsys Dallas, TX
#
# TCL Procedure to constrain tri-state cells to be close to each other
#
proc tri_state { } {
echo "Started- procedure tri_state [date]"
suppress_message UID-95 ;# warnings for dummy cell below
# initialize counter for number of bounds
set count 0
# create the flag to signal continuation of procedure
exec touch .go
set all_tri_nets [get_nets -hier * -filter "@three_state == true"]
set number [sizeof_collection $all_tri_nets]
echo "There are $number tri-state nets in this design"
# itterate through the nets to make a collection of pins
set all_tri_pins [add_to_collection {} {} ];# start empty collection
foreach_in_collection mynet $all_tri_nets {
set all_tri_pins [add_to_collection -unique $all_tri_pins \
[all_fanin -flat -levels 0 -to $mynet]]
set all_tri_pins [add_to_collection -unique $all_tri_pins \
[all_fanout -flat -levels 0 -from $mynet]]
# check for the existance of the go flag to continue the procedure
if {![file exists .go]} {
set all_tri_nets ""
}
}
set num_pins [sizeof_collection $all_tri_pins]
echo "there are $num_pins pins to process"
while {[sizeof_collection $all_tri_pins] != 0} {
set mypin [index_collection $all_tri_pins 0]
set tri_net [all_connected $mypin]
set net_name [get_attribute $tri_net full_name]
echo "processing net $net_name for a set_bounds"
set bound_pins [all_fanin -flat -levels 0 -to [get_net $tri_net]]
set bound_pins [add_to_collection -unique $bound_pins \
[all_fanout -flat -levels 0 -from [get_net $tri_net]]]
set all_tri_pins [remove_from_collection $all_tri_pins $bound_pins]
set bound_cells [get_cell dummy]
foreach_in_collection target_pin $bound_pins {
set pin_name [get_attribute $target_pin full_name]
if {[regexp {(.*)/[^/]+$} $pin_name match cell_name] != 0} {
set bound_cells [add_to_collection -unique $bound_cells \
[get_cell $cell_name]]
}
};# end of foreach loop for target bound cells
set_bounds -effort high $bound_cells
set count [sizeof_collection $all_tri_pins]
echo "there are $count pins left to process"
# check for the existance of the go flag to continue procedure
if {![file exists .go]} {
set all_tri_pins ""
}
};# end of while loop for tri state pins
echo "Completed - procedure tri_state [date]"
# remove the go flag
file delete .go
unset all_tri_nets
unset all_tri_pins
};# end of procedure
============================================================================
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
|
|
