"I'm looking in every corner I can find, and it's pretty bleak.
We're probably the only player in the C marketplace that's figured
out how to make a business of it."
- Dan Skilken, the CEO of C Level, on the difficulty of
finding 4th round VC funding for the past 6 months.
"Basically the third- and fourth-round funding is drying up. If you
can't convince the VCs that you're ready to go IPO this year or early
next year, you have a big problem."
- Gary Smith, chief EDA analyst at Dataquest (EE Times 9/12/01)
( ESNUG 378 Subjects ) ------------------------------------------ [10/03/01]
Item 1: You Might Want To Wait For DC 2001.08-SP1 Release Before Upgrading
Item 2: ( ESNUG 377 #2 ) Turning Off The Secret "Consume Licenses" Switch
Item 3: Call-For-Papers HDL Con'02 And SNUG'02 Moved To 10/14 And 10/19
Item 4: ( ESNUG 371 #14 ) We're Disappointed With Synopsys Presto, Too
Item 5: A Customer Benchmark Of Cadence CTGEN vs. Silicon Perspectives FE
Item 6: ( ESNUG 377 #20 ) Getting Expanded PrimeTime Clock Path Reports
Item 7: ( DAC 01 #35 ) User Asks: "Is Primetime-SI Ready For Primetime?"
Item 8: ( ESNUG 377 #15 ) What Competes With Synchronicity's "IP Gear"
Item 9: ( ESNUG 377 #19 ) Faking Internal Clocks In Synopsys PrimeTime
Item 10: Must I Use An Analog Simulator Along With PrimeTime For PCI Specs?
Item 11: ( ESNUG 377 #17 ) How To Create DC Statistical Wireload Models
Item 12: ( ESNUG 377 #1 ) Synopsys Rebuts "Hey, We've Been Advancing VCS!"
Item 13: ( DAC 01 #6 ) Offis Explains That Orinoco Does "Low Power Binding"
Item 14: ( ESNUG 377 #4 ) A DEF 5.2-To-Flat-Verilog PhysOpt Perl Script
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 378 Item 1 ) -------------------------------------------- [10/03/01]
From: "Gregg Lahti" <gregg.lahti@corrent.com>
Subject: You Might Want To Wait For DC 2001.08-SP1 Release Before Upgrading
Hi, John,
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.
Some of these issues are known by Synopsys and filed as STARs. Some aren't.
Unfortunately, Synopsys doesn't list all user filed STARs on SolvNet. It
seems the only way to find out about any of these known issues is to post
the bug and get a response back from SNPS support telling you that it's a
known issue, or have inside info from your local AE listing all of them.
Wouldn't it be great to see a list of user filed STARs for each tool & rev
on SolvNet, updated on a real-time basis? The data would be most helpful
to the customers, especially since one could do a quick reference check and
verify that it's a bug and there's a workaround rather than spend hours
determining the root cause/work-around and wasting the Support line's time
in a submission.
Here are the details of some of the DC 2001.08 issues I've found so far:
1) Presto is enabled by default. Reading in Verilog may fail if you don't
have a Module Compiler license when Presto starts reading in certain
structures. We weren't relying on Presto to get the newer indexed-
array features, but I did find that using Presto gave better error
messages when I had problems reading in Verilog. A quick edit to
our setup file with "set hdlin_enable_presto false;" made this issue
go away.
2) We're using the TOPS Tcl environment for synthesis which a few of us
presented at Boston SNUG 2000. Within the Tcl code procedures there
is an "if" construct that looks like this:
if {[set synopsys_program_name] != "pt_shell"} {
...
}
On various synthesis runs, I'd see an error from DC 2001.08 that the
"synopsys_program_name" variable doesn't exist even though it was
defined as "global" at the beginning of the procedure. Granted,
this code is not the most efficient way to do a comparison but it
worked fine in 2000.11. The workaround to fix it was:
if {$synopsys_program_name != "pt_shell"} {
...
}
Once we did that, the problem went away. Weird.
3) We've had some issues with reading in Verilog netlists, re-grouping,
and writing out a new Verilog netlist, where the resultant Verilog
netlist didn't get the input/output assignments listed in the
sub-module. Effectively, the resultant Verilog netlist was illegal
and DC 2001.08 couldn't read in what it wrote out. Our workaround
for now was to use the DB file for everything and then write out the
verilog at the last step.
My local AE has said that a 2001.08-SP1 release is due soon. I think I'll
wait until that comes out before I'll switch over.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 378 Item 2 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #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):
>
> 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.
>
> - Romas Rudis
> Intrinsix
From: "Tom Cruz" <tomcruz@us.ibm.com>
Hi, John,
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
( ESNUG 378 Item 3 ) -------------------------------------------- [10/03/01]
From: Stuart Sutherland <stuart@sutherland-hdl.com>
Subject: Call-For-Papers HDL Con'02 And SNUG'02 Moved To 10/14 And 10/19
Hi, John,
The San Jose SNUG 2002 conference and the HDL Con'02 conference will be held
in the same week, and at the same location. Your readers may want to mark
these dates in their calendars.
HDL Con'02 : Monday - Tuesday, 11-12 March 2002
San Jose SNUG'02: Wednesday - Friday, 13-15 March 2002
BECAUSE OF THE 9/11 ATTACK, THE CALL-FOR-PAPERS DEADLINES HAVE BEEN MOVED TO
14 OCTOBER 2001 AND 19 OCTOBER 2001, RESPECTIVELY! Both conferences are
counting on your readers to submit proposals for papers regarding their
experiences with design, modeling, simulation, synthesis and verification.
SNUG is a technical conference on getting the most from Synopsys products
and services. SNUG always delivers on excellent tutorials technical papers
reflecting real user experiences. More details on the SNUG conference AND
HOW TO SUBMIT PAPER PROPOSALS is available at http://www.snug-universal.org
HDL Con is an international conference on the usage of Hardware Design and
Verification Languages. Papers and tutorials will be presented on VHDL,
Verilog, Vera, E, Superlog, SystemC, and several other languages related to
hardware design. The exhibit hall has vendor booths for HDL and HVL
related products from around the world. More information on HDL Con AND HOW
TO SUBMIT PAPER PROPOSALS can be found at http://www.hdlcon.org.
- Stuart Sutherland
Sutherland HDL, Inc. Tualatin, OR
( ESNUG 378 Item 4 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 371 #14 ) We're Disappointed With Synopsys Presto, Too
> We're investigating using the new Synopsys Presto Verilog 2000 features
> like arrayed instantiation and multiply-dimensioned arrays. In our
> preliminary evaluations of Presto's support for these features,
> I have been sorely disappointed (using 2000.11-SP1). I have been even
> more disappointed by the Synopsys On Line Documentation provided
> describing Presto's support of these particular features.
>
> We have also encountered some serious backwards incompatibility with HDL
> Compiler issues (i.e., Verilog that works fine with HDL Compiler that
> breaks Presto), and Synopsys has publicly stated its intent to make Presto
> the default Verilog reader starting with the 2001.08 release.
>
> I would be very interested in hearing about others' experiences with
> Verilog 2000 and Presto to date.
>
> - Rich Conlin
> Paradigm Works Andover, MA
From: "Gabriel Ricardo" <Gabriel.Ricardo@tsc.tdk.com>
John,
This was for DC 2000.11. We subsequently abandoned the use of Presto so I
don't know if these problems have been fixed in later releases.
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. Specifically we had a
parameterizable design with many instances all configured differently and
we wanted to use Presto's support for the defparam construct to control the
overriding of parameters in each instance. Turned out defparam didn't do
what we wanted it to do. The construct would override the first two
parameters passed down and do nothing to the rest of the parameters.
Seems as though Presto is bug ridden. The Synopsys support engineer
conveyed that much to me through my email exchanges with them. So the
problem with defparam has been captured as a STAR, which had I known that
when I ran into the problem, would have saved me some time. It would be
nice if as a user, I could search a database for related STARs and any
known workarounds. But as I've been told by Synopsys support, Synopsys
makes it clear when a STAR is fixed but doesn't do much to let user's know
about "known" bugs. I think users should have access to a list of STARs
(and known workarounds) and how they impact the use of the tool. In all
fairness, I do have to say the Synopsys support was much better at getting
back to me this time.
So our project switched to using HDL Compiler and using the #(param, param
...) construct to override parameters. Switching to the older construct
and disabling the use of Presto wasn't such a big deal.
As I mentioned above, if I had been able to find out about the Presto STAR
up front it would have saved me a hassle.
- Gabriel Ricardo
TDK Semiconductor Nevada City, CA
( ESNUG 378 Item 5 ) -------------------------------------------- [10/03/01]
From: [ Rinse, Lather, Repeat ]
Subject: A Customer Benchmark Of Cadence CTGEN vs. Silicon Perspectives FE
Hi, John,
Keep me anonymous on this.
We were doing clock tree generation on a block: 400,000 gate block, 36,200
endpoints. Desired max skew of 200 ps, insertion delay of 4.5 ns, max
trans of 500 ns with a .18 micron process.
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 First Encounter clock tree results: 162 ps skew, max
trans of 480 ps, met the insertion delay, took 7 minutes, 1820 buffers used.
Both tools were given the same buffers to use and same netlist, same
floorplan, etc....
Is it any wonder CTGEN is a piece of trash?
Oh yeah, and don't let people tell you that its because I don't know how to
run their tool. I have read the entire manual (hey, it's short) backwards
and forwards and feel I know all the possible help/constraints you can give
it.
- [ Rinse, Lather, Repeat ]
( ESNUG 378 Item 6 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #20 ) Getting Expanded PrimeTime Clock Path Reports
> 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.
From: "William Natter" <wnatter@nortelnetworks.com>
Hi John,
PrimeTime gives you access to a lot of its internal objects, and allows you
to create Tcl procedures. If you want, you can create a procedure that
traces its way from the first master clock, through generated clocks, and
all the way to the startpoint of interest using "get_timing_paths".
Remember that this clock network delay includes the latencies of the clocks.
- William Natter
Nortel Networks Nepean, ON, Canada
---- ---- ---- ---- ---- ---- ----
From: Leo Butler <lbutler@brocade.com>
Hello, John.
report_timing has the option "-path_type full_clock" which will expand the
propagated clock delay calculation. I don't know how far back that command
goes in PrimeTime versions, but it's present in at least 2000.11 and above.
- Leo Butler
Brocade Communications
---- ---- ---- ---- ---- ---- ----
From: Lars Bo Graversen <larsg@mips.com>
John,
Russ might want to try '-path_type full_clock' in the report_timing command.
I think that it might get him the information he wants.
- Lars Bo Graversen
MIPS Denmark
---- ---- ---- ---- ---- ---- ----
From: Wayne Miller <Wayne.A.Miller@smsc.com>
Hi John,
I'm sure I'm chiming in late, but I think this is what Russell wants:
report_timing -path full_clock
Hope this helps,
- Wayne Miller
Standard Microsystems Corporation Long Island, NY
---- ---- ---- ---- ---- ---- ----
From: Khris Kofford <kkofford@amis.com>
John,
Saw Russ' post on ESNUG. Not totally sure what he's trying to do, but has
he tried: "pt_shell> report_timing -from FOO1/C -to FOO2/D -input_pins
-path_type full_clock" ? This will split the clocktree into individual
buffers in the report instead of giving you the lumped delay.
- Khris Kofford
AMI Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
John,
I assume by now that a hundred people have suggested to Russ to "-path_type
full_clock". If not, try it. I think it does what he wants.
By the way, you can get some "interesting" results with this if you haven't
controlled your clock MUXes with set_case_analysis. I had a case where
PrimeTime would report DIFFERENT values when I had -path_type full_clock
turned on than it did when it was not! The problem was ultimately traced
to an uncontrolled clock MUX.
- Paul Zimmer
Cisco Systems
( ESNUG 378 Item 7 ) -------------------------------------------- [10/03/01]
Subject: ( DAC 01 #35 ) User Asks: "Is Primetime-SI Ready For Primetime?"
> "PrimeTime-SI is only for analysis of cross-talk. It can't solve
> problems and can't analyze IP-drop now."
>
> - Jeong-Fa Sheu of Acute Communications
From: Caesar Abedin <cabedin@amcc.com>
John,
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
( ESNUG 378 Item 8 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #15 ) What Competes With Synchronicity's "IP Gear"
> Do you know of any competitive tools to Synchronicity's IP Gear design
> reuse tool? Thanks for any pointers.
>
> - Maynard Carlson
> Hewlett-Packard
From: "James Brown" <james_brown@mentorg.com>
John,
We have an offering that competes with Synchronicity's IP Gear. We have a
customizable tool call QuickUse Development System (QDS). It can also be
utilized in areas outside of design which can really save you the time and
expense of maintaining multiple files in multiple places.
- James Brown
Mentor Graphics Austin, Texas
---- ---- ---- ---- ---- ---- ----
From: "Hans J. Kuffer" <hansjk@inicore.com>
Hi, John,
D&R's IP manager Series software is a toolset allowing you to manage IP
over the internet or intranet. It consist of the: IP Catalog Builder,
IP Right Manager, IP Exchange, IP Profiler, and IP Version Uploader.
- Hans J. Kuffer
Design & Reuse, Inc. Newark, CA
---- ---- ---- ---- ---- ---- ----
From: "Peter A. Stokes" <stokes@cmc.ca>
Hi John.
Here's my view of the available options:
- Synchronicity IP Gear
- Mentor QDS
- Cadence IPinfraNet
- Design and Reuse
Regards,
- Peter A. Stokes
Canadian Microelectronics Corporation
( ESNUG 378 Item 9 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #19 ) Faking Internal Clocks In Synopsys PrimeTime
> Does anyone have a way to create a clock in PrimeTime on an internal net?
>
> - Derek Brasili
> Cavium
From: Glen McDonnell <gmcdonne@ati.com>
Hi, John,
You cannot create a clock directly on a net. Since Derek doesn't appear to
want to create the clock on startpoint of the net, he should try creating
it at the endpoints of his top-level net, i.e. his hierarchical boundaries.
I'm assuming that RCLK is his top-level port and the 80 ps is the measured
wire delay from the RCLK port to the clock input of the lower-level netlist
and/or db file. Then he can use set_clock_latency to add in the 80 ps.
create_clock [get_pins {U1/ECLK U2/ECLK}] -name ECLK -period <same as RCLK>
-waveform <same as RCLK>
set_clock_latency -source 0.080 [get_clocks ECLK]
Do not set a false path between RCLK and ECLK.
- Glen McDonnell
ATI
---- ---- ---- ---- ---- ---- ----
From: [ A PrimeTime CAE ]
Hi John,
Instead of trying to run create_clock on a net, you can set create_clock
on the pin of the cell (the output pin of the driving cell or input pin
of the load cell). For example, assuming a 10 ns clock period, you would
use something similar to this:
create_clock -name ECLK -period 10 -waveform {0.08 5.08} ECLK_source_cell/Z
The key is not to run create_clock on a net but on a pin or port.
- [ A PrimeTime CAE ]
---- ---- ---- ---- ---- ---- ----
From: "Derek Brasili" <derek.brasili@cavium.com>
Hi John,
I know you like users to follow-up once we solve a question we ask on ESNUG.
Here's the solution I found to my PrimeTime problem.
It turns out that you can define a clock on module pins. So in my case, we
have a module, lets call it GEN_ECLK. This module has an output pin called
ECLK. Now ECLK goes to a bunch of synthesized modules and is the clock to
the flops in these modules.
Now when I run PrimeTime at the top level, I am using Verilog to hook up all
the lower level modules. So my global clock, RCLK, is a port to my top
level module. So I use the following command to define ECLK as a clock and
get it to be delayed by 80 ps in reference to RCLK.
create_clock -name "rclk" -period 10 -waveform {0 5} [get_ports {rclk}]
create_generated_clock -name "eclk" -source "rclk" -edges {1 2 3}
-edge_shift {0.08 0.08 0.08} [get_pins {gen_clk/eclk}]
By doing this I have found that PrimeTime ignores the delay that it would
see from RCLK to ECLK inside of the GEN_ECLK schematic. It only uses the
80 ps delay which is what I want.
You can do a man on create_generated_clock if you don't understand what it
is doing. There is also some info on SolvNet that explains better what the
-edges and -edge_shift are doing. But if anyone has questions about it I
can explain it.
Hope this helps others facing this.
- Derek Brasili
Cavium
( ESNUG 378 Item 10 ) ------------------------------------------- [10/03/01]
From: "Louis Villarosa" <Louis.Villarosa@honeywell.com>
Subject: Must I Use An Analog Simulator Along With PrimeTime For PCI Specs?
Hello, John,
The Local PCI Bus Specification specifies the maximum clock-to-output delay.
However, for the 3.3 v signal environment, the load capacitance is not
given. Instead the specification defines V/I curves for the output driver
and states that the output current must exceed a specified value with the
maximum clock-to-output time. The reason for this is that outputs drive a
backplane trace. Therefore lumped load models don't apply. It does not
appear that it is possible to strictly use PrimeTime to calculate the delay
or to constrain the synthesis to meet the PCI output delay requirement.
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 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 strictly using PrimeTime?
- Lou Villarosa, Jr.
Honeywell Space Systems Clearwater, FL
( ESNUG 378 Item 11 ) ------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #17 ) How To Create DC Statistical Wireload Models
> 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. Help!
>
> - Chia-Lan Li
> Medtronic, Inc. Tempe, AZ
From: [ An Arizona Synopsys FAE ]
Hi, John,
I can tell you from my experience there is no standard way of generating
statistical wireload models. What the Synopsys documentation provides you
is the syntax and the way that the information is used in the timing engine
and then the vendors are responsible for figuring out how to come up with
the numbers for their technology. The most common way to generate models:
1) Gather as many designs as you can from within your user community
of your given technology. (This seems to be the biggest issue is
getting enough designs to get a good distribution of information.)
2) Take blocks of a given size of design, plot out the wire length
per number of pins on the net minus 1. (This is to eliminate the
driver itself.)
3) Plot out the median value in the distribution points to include in
your statistical model (you may need to throw out some values that
fall way out of the model.)
4) Use these values to plug into your models.
The biggest problem with statistical wireload models is that they usually
don't represent the specific design you are working on and it is very
dependent on getting enough data points. The process can be very time
consuming to gather all the information and the information does not scale
in a predictable way from technology to technology. Another problem is
that most tables are generated assuming a square area when often the actual
block in the floorplan may have a rectangular or rectilinear shape which
makes the estimates even farther off. As the technology gets smaller and
smaller, and the net delays become more and more of a factor, every amount
of delay estimation that is incorrect makes it more difficult to come
to timing closure. The wireload models do not account for other
obstructions the design may encounter in the floorplan as well.
- [ An Arizona Synopsys FAE ]
---- ---- ---- ---- ---- ---- ----
From: Edmond Macaluso <edmond@z-circuit.com>
John,
Normally, you take a previous design or a part of a design that is
representative, compile it, do a quick P&R, extract, created SDF, Set_load
and then build WLM's from this.
You can then use this for the initial compiles of new RTL. Once you
get compiles of the design, build custom models for it. I think the word
"statistical" is a bit mis-leading. Look at Golson's "Resistance Is
Futile!" paper on building wireload models #28 in the DeepChip's Downloads.
It is a useful paper. Also, look at Synopsys Floorplan Manager manual which
is pretty good. It has all sorts of methods for building and assigning
wire-load models. Synopsys also supports "sticky loads" for long nets
which help a lot.
I teach a flow training workshop through Artisan Components and this is one
of the topics we cover.
- Edmond Macaluso
Z Circuit Automation Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys CAE ]
John,
A fair amount of research work exists on both effectiveness and derivation
of accurate wireload models. Bottom line though is that calibration of
initial wireload is highly dependent on design style (lots of busses vs.
random, lots of global signals vs localized), layers of metal available and
your choice of placer/router(s). When all is said and done, you need to
base wireload models on as many statistically relevant (similar process,
metal, design style) finished chip data sets as possible.
Some references:
http://www-device.EECS.Berkeley.EDU/~dennis/papers/iccad98.pdf
http://www-device.EECS.Berkeley.EDU/~dennis/papers/tau99.pdf
http://www-device.eecs.berkeley.edu/~dennis/bacpac/models/delay.html#wire_model
W.E. Donath, "Placement and average interconnection lengths of computer
logic," IEEE Transactions on Circuits and Systems, vol. 26,
pp. 272-277, April 1979.
A. Masaki and M. Yamada, "Equations for estimating wire length in
various types of 2-D and 3-D system packaging structures," IEEE
Transactions on Components, Hybrids, and Manufacturing Technology,
vol. 10, pp. 90-198, June 1987.
J.A. Davis, V.K. De, and J.D. Meindl, "A stochastic wire-length
distribution for gigascale integration (GSI) - part I: derivation
and validation," IEEE Transactions on Electron Devices, vol. 45,
pp.580-589, March 1998.
In addition there is also a SNUG'99 paper on wireload models "Resistance is
Futile! Building Better Wireload Models" by Steve Golson.
Hope this helps.
- [ A Synopsys CAE ]
---- ---- ---- ---- ---- ---- ----
From: Chia-Lan Li <cli@tmp.medtronic.com>
Dear John,
I am using Golson's approach and scripts to examine the wire load model I
generated from Synopsys and Cadence HyperExtract. I am also trying to
compare how different in timing/area when using table format and standard
format wire load model. HyperExtract generates standard format WLM while
Synopsys generates both table and standard format WLM. Synopsys Floorplan
Manager User Guide indicates table-format models are more accurate than
standard format models (p.4-9).
After sorting out which tool and which format WLM to generate, I'll try
the approach suggested by the Synopsys Arizona FAE.
There are two new papers coming out which I think are worth reading. One is
from Boston SNUG 2001 by Duane Galbi and Dwight Galbi, "Improved Interconnect
Modeling using Path Based Time Budgeting Instead of Wire Load Models". The
other is to be published at ICU 2001 by Kenneth Boese, Andrew Kahng and
Stefanus Mantik, "On The Relevance Of Wire Load Models".
Thanks John for your well organized ESNUG so we can have a place to research
and post questions.
- Chia-Lan Li
Medtronic, Inc. Tempe, AZ
---- ---- ---- ---- ---- ---- ----
From: Jerry Gebhard <jerryg@intimesw.com>
Hi, John,
I work for InTime Software. Our tools are used before synthesis, during RTL
development. DesignWarrior allows designers to predict performance and area
before running CPU-intensive DC runs. This allows a designer to look at
many more RTL architecture variations before deciding on the final one to
use for physical implementation.
We automatically create custom wireload models and design specific "set
load" parasitic files for your DC runs.
- Jerry Gebhard
InTime Software Austin, Texas
( ESNUG 378 Item 12 ) ------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #1 ) Synopsys Rebuts "Hey, We've Been Advancing VCS!"
> 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.
>
> - Gregg Lahti
> Corrent Corp Tempe, AZ
From: Tim Schneider <tims@synopsys.com>
John,
It's more of a space/time continuum of increasing performance. If you've
been away for a while, here's some of what was added since '97 (VCS 4.0):
* Increased the number of ASIC sign-off vendors to 30+
* Support compiled SDF (and incremental compile for SDF files)
* DirectKernel integration (DKI) with VirSim GUI for speed
* DirectKernel integration with Novas Debussy GUI (also for speed)
* Dynamic and static race detection
* Dynamic profiler to understand where CPU time is spent
* VirSim enhancements - glitch detection, event origin, value
annotation of source code, etc.
* Mixed-HDL with Scirocco VHDL simulator
* Mixed-signal with NanoSim
* Radiant Technology Optimizations
* Direct C Integration
* Adaptive PLI
* +timopt timing optimizations to speed gate-level timing runs
* full comprehensive code coverage built in
> 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).
All the latest and greatest docs on VCS can be found in $VCS_HOME/doc.
In there you will find:
ReleaseNotes - what has changed/been fixed
UserGuide directory - current .pdf's
The docs underwent a complete overhaul and rewrite a few years back. I
remember helping review some of the changes (around the VCS 5.x
timeframe.) Searching for 'VCS' AND 'performance' yielded some 79
hits on SolvNet. A few of the more pertinent are listed here:
20: Maximizing VCS Performance
Doc Name: Doc-134.html Last updated: 06/14/2001
21: Debugging VCS with the +rad Switch
Doc Name: Field-154.html Last updated: 11/03/1999
22: Improving gate level simulation performance with SDF
Doc Name: Verilog_Simulation-194.html Last updated: 08/30/2001
25: TIMOPT improves gate level simulation
Doc Name: Verilog_Simulation-344.html Last updated: 09/04/2001
27: VCS timopt
Doc Name: Field-290.html Last updated: 09/04/2001
28: Improving Memory Usage and Runtime Performance with waveform dumping
Doc Name: Verilog_Simulation-247.html Last updated: 08/24/2001
32: How can I reduce simulation time?
Doc Name: Verilog_Simulation-50.html Last updated: 03/02/1999
35: How do I measure compile/run time performance?
Doc Name: Verilog_Simulation-65.html Last updated: 01/23/1998
36: Should I write a large part of my design in PLI (C) for speed-up?
Doc Name: Verilog_Simulation-61.html Last updated: 01/23/1998
45: Precompiled SDF Methodology
Doc Name: Facilities-2.html Last updated: 08/24/2001
47: Improving gate level debug performance
Doc Name: Field-86.html Last updated: 08/24/2001
51: How should I write my Verilog code for maximum speed?
Doc Name: Verilog_Simulation-62.html Last updated: 01/23/1998
52: How do I profile a VCS simulation?
Doc Name: Verilog_Simulation-59.html Last updated: 01/23/1998
> 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.
Admittedly there is no PLI 2.0 in VCS yet. This will be fixed *shortly*.
The VCS PLI 2.0 (VPI) beta program begins next month, and we've already
been working with a few partners for several months.
> 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.
GUI's are like opinions, everyone is entitled to one. :-) And sometimes
they border on 'religion'. (vi versus emacs?) Virsim is pretty powerful.
Debussy is too. You can use either or both since *both* are tightly
integrated with VCS. Hey, we even let you change the colors and the buttons
if you like! :-)
> Finally, it's mid-year 2001. How many more years must I wait for VCS to
> integrate all of the Verilog 2000 language updates?
It's getting there. It's moving pretty much along with Design Compiler as
far as construct support. Many Verilog 2001 constructs were supported with
VCS 6.0, released Jan 2001. Stu Sutherland and Don Mills presented a paper
at San Jose SNUG this past spring describing VCS and DC support for Verilog
2000. See http://www.snug-universal.org/sj/sj2001_papers.htm#MC2
- Tim Schneider
Synopsys, Inc Mesa, AZ
( ESNUG 378 Item 13 ) ------------------------------------------- [10/03/01]
Subject: ( DAC 01 #6 ) Offis Explains That Orinoco Does "Low Power Binding"
> "The Offis Orinoco guys had some neat ideas about going from C/C++ down
> to gates optimizing for power. However, without an underlying logic
> synthesis engine, I would never trust Orinoco to give me real results.
> The idea of generating scripts to coerce Behavioral Compiler into
> giving them the schedule that they thought was optimal (for power) was
> ridiculous -- not ridiculous in theory, but in practice."
>
> - [ An Anon Engineer ]
From: Frank Poppen <frank.poppen@offis.de>
Hi John,
it was nice meeting you in during the Boston SNUG. Germany seems to be so
far away from the SNUG community. It was really great to finally get to
know all the people. (Though the circumstances where quite shocking with
the terror and no way to fly back home before Sunday.) We at Offis didn't
appreciate part of the comment of the Anon Engineer in the DAC 01 report:
1.) Next to C/C++ (not necessarily SystemC) ORINOCO also processes VHDL.
2.) Orinoco does NOT create a "low power schedule" (yet). We plan to
implement this. What you DO get is a "low power binding". This is a
completely different story and it does work. This comment hit me
someway personally. My SNUG paper proved that with this methodology
power savings are possible up to 20%.
Let me try to explain what I mean with the terms scheduling, allocation
and binding: Designers either do scheduling manually (which operation has
to be executed first depending on the data-dependency-graph) or use Synopsys
Behavioral Compiler. The next step is synthesis. In this step DC,
allocates resources. Depending on the timing constraints and the possible
parallelism in the design, DC might allocate two adders for an algorithm
that contains 100 additions. Some of these operations (not necessarily one
half) will be bound to one allocated adder. The rest will be bound to the
other adder. If we do this step of binding operations on allocated
resources wisely we can save power. Let's assume we have to bind 4
additions to 2 adders:
op1 = 0111 + 0111
op2 = 0000 + 0000
op3 = 0110 + 0111
op4 = 0000 + 0001
High activity means high power consumption. Low activity means low power
consumption.
"bad binding" {op1,op2} => adder1
{op3,op4} => adder2
0000 0000 0000 0001
0111 0111 0110 0111 <- High activity at inputs
| | | |
----------- -----------
\ + / \ + / <- High activity in ALU
--------- ---------
| |
0000 0001
1110 1101 <- High activity at output
This bad binding causes a high power consumption!
"good binding" {op1,op3} => adder1
{op2,op4} => adder2
0110 0111 0000 0001
0111 0111 0000 0000 <- Low activity at inputs
| | | |
----------- -----------
\ + / \ + / <- Low activity in ALU
--------- ---------
| |
1101 0001
1110 0000 <- Low activity at output
This good binding uses much less power.
By using data correlation and not destroying it with a "bad binding" we can
reduce activity dramatically and save power. The complete paper is in the
Boston SNUG'01 proceedings and the title is: "Evaluation of a Behavioral
Low Power Design Flow Based on a Design Case".
- Frank Poppen
OFFIS Research Institute Oldenburg, Germany
( ESNUG 378 Item 14 ) ------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #4 ) A DEF 5.2-To-Flat-Verilog PhysOpt Perl Script
> 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!
>
> - Tommy Zounes
> ST Microelectronics
From: [ A Synopsys PhysOpt FAE ]
Hello John,
Replying to ESNUG 377 #4 from Tommy Zounes of ST, I am sending you my DEF
to Verilog perl script. The syntax is:
def2ver <def_file> <design_name>
Input: <def_file>
Output: design_name.v
It will read a DEF (version 5.2) and generate a flat Verilog.
- [ A Synopsys PhysOpt FAE ]
#!/usr/local/bin/perl5
#********************************************************
#* DEF2VER *
#* DEF2VER: Generate Verilog from DEF 5.2 *
#* Date 9/15/01 *
#********************************************************
#* *
#* Version 1.0 Initial release 9.15/01 by TNN *
#* *
#********************************************************
#* USAGE: def2ver <DEF> <design_name> *
#********************************************************
$def_file = $ARGV[0];
$verilog = "$ARGV[1]";
$design = "$ARGV[1]";
#
open (DEF,"$def_file");
open (VER, ">$verilog.v");
open (NET,"+>jnk_jnk.dat");
open (WIRE,"+>jnk_wire.dat");
open (INS,"+>jnk_cell.dat");
#
$t = &time();
print "Running DEF parser program $t\n";
&def_parser();
$t = &time();
print "Processing nets $t\n";
&def_proc();
$t = &time();
print "Generate Wire file $t\n";
&proc_wire();
$t = &time();
print "Output Verilog $verilog.v $t\n";
&gen_ver();
$t = &time();
print "FINISHED $t\n";
#
#********************************************************
sub def_parser
{
$r_i = 0;
$pi = 0;
while (<DEF>)
{
$prr = 1 if ($_ =~ /^NETS/);
$prr = 2 if ($_ =~ /^COMPONENTS/);
$prr = 3 if ($_ =~ /^PINS/);
$prr = 0 if ($_ =~ /^END/);
#
# NETS Section
#
if ($prr == 1)
{
if ($_ =~ /- /) {$ll = $_; $pr = 1;}
elsif ($_ =~ /\+/) {$nn =$_; $nn =~ s/\+.*//; $ll == $ll.$nn; $pr = 0;}
elsif ($pr == 1) {$ll = $ll.$_;}
$ll =~ s/\n//g;
print NET "$ll\n" if ($_ =~ /\;/);
}
#
# Components Section
#
elsif ($prr == 2)
{
@c = split(" ",$_);
$r = $c[1];
$cell{$r} = $c[2];
$port{$r} = "";
$ref[$r_i]=$r;
$r_i++;
}
#
# PINS Section
#
elsif ($prr == 3)
{
if ($_ =~ /- /) {$l = $_;}
else {$l = $l.$_;}
#
$l =~ s/\n//g;
if (($l =~ /- /) & ($l =~ /\;/))
{
$tem = $l;
$tem =~ s/[\+,\-]//g;
$tem =~ s/USE.*//;
@pp = split(" ",$tem);
$pin[$pi] = $pp[0];
$pin_pro[$pi] = "$pp[4]:$pp[0]";
$net_pin[$pi] = $pp[2];
$pi++;
$l ="";
}
}
}
close <DEF>;
}
#********************************************************
sub def_proc
{
$nn = 1;
seek(NET,0,0);
@n = <NET>;
close(NET);
for ($i=0; $i<= $#n; $i++)
{
$n[$i] =~ s/[\-,\)]//g;
@q = split(/\(/, $n[$i]);
$net = $q[0];
$net =~ s/\s//g;
$wire[$n_i] = $net;
$net =~ s/\s//g;
$n_i++;
$nn++;
if ($nn == 100000) {print "Processed $i nets\n"; $nn =1;}
for ($j=1; $j<=$#q;$j++)
{
$tem = $q[$j];
@p = split(" ",$tem);
$r = $p[0];
$port{$r} = "$port{$r} \-$p[1]:$net\+" ;
}
}
@n = "";
}
#*****************************************************************
sub proc_wire
{
for ($i= 0; $i< $n_i; $i++)
{
print WIRE "$wire[$i]:" if ($wire[$i]=~ /./);
}
#
# print wire from pin section
#
for ($i= 0; $i< $pi; $i++)
{
print WIRE "$net_pin[$i]:";
}
for ($i= 0; $i< $r_i; $i++)
{
$r = $ref[$i];
$port{$r} =~ s/\-/\./g;
$port{$r} =~ s/\:/\(/g;
$port{$r} =~ s/\+/\)/g;
$port{$r} =~ s/\) \./\)\, \./g;
if ($port{$r} =~/[A-Z]/)
{
print INS "\t$cell{$r} $r\( $port{$r} \)\; \n" ;
}
else
{
print "//ERROR: No nets connected to $r $cell{$r}\n";
}
}
}
#*******************************************************************
sub time
{
my $t;
$t = `date`;
chop($t);
return ($t);
}
#*******************************************************************
sub gen_ver
{
my $t, $i, $j;
$t = &time;
print VER "// $verilog.v is generated from DEF2VER program\n";
print VER "// at $t \n";
# Module statement
print VER "module $verilog \( $pin[0]";
for ($i=1; $i<$pi; $i++)
{
print VER ", $pin[$i]";
}
print VER "\)\;\n\n";
# ports statement
@s_pin = sort(@pin_pro);
$prev="NEW";
$wid = 1;
for ($i=0;$i< $pi; $i++)
{
$tem = $s_pin[$i];
@jn = split("\:",$tem);
$jn[0] =~ tr/A-Z/a-z/;
if ($prev !~ /$jn[0]/)
{
print VER "\;\n" if ($prev !~ /NEW/);
print VER "$jn[0] $jn[1]";
$prev = $jn[0];
$wid = 1;
}
else
{
print VER ", $jn[1]";
$wid ++;
}
if ($wid > 4) {$prev = "DIFF" ; $wid = 1;}
}
print VER "\;";
# wires statement
seek(WIRE,0,0);
$wid = 1;
$jn = <WIRE>;
@n = split("\:",$jn);
print VER "\n\nwire ";
for ($i=0; $i<=$#n; $i++)
{
$n[$i] =~ s/\//__/g;
if (($wid >= 4) && ($i < $#n)) {$nl = 1; $wid = 1;}
elsif ($i == $#n) {$nl = 2;}
else {$wid ++; $nl = 0;}
print VER "$n[$i]";
if ($nl == 1) {print VER "\;\nwire "; $nl = 0;}
elsif ($nl == 2) {print VER "\;\n\n";}
else {print VER "\, ";}
}
close (WIRE);
# Inst statement
seek(INS,0,0);
while (<INS>) {$tem = $_; $tem =~ s/\//__/g; print VER $tem;}
close (INS);
#end module statement
print VER "\nendmodule\n";
}
============================================================================
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
|
|
