Editor's Note: I wish to apologize for not getting ESNUG published over
the last 2 weeks. It was in New York's LaGuardia airport where my
laptop computer died 2.5 weeks ago. I've painfully learned the lesson
of the importance of backing up one's computer files more than once
every 6 months. Painfully. Very painfully. Oh, so very painfully.
- John Cooley
the ESNUG guy
( ESNUG 388 Subjects ) ------------------------------------------- [02/27/02]
Item 1: ( ESNUG 387 #1 ) What Synopsys Plans To Do With C-Level's Tools
Item 2: ( ESNUG 386 #14 ) Cooley Spanked For Omitting PhysOpt's Viewer
Item 3: PhysOpt Rounded Placement Co-ordinates In My Physical Chip Design!
Item 4: The Avanti User Group "AURORA 2002" Meets This Week In San Jose
Item 5: ( ESNUG 387 #3 ) Formality 2002.03 (Beta) Finds PhyOpt Buffer Bug
Item 6: Is Anyone Currently Using Innoveda's Regent? What Did you Think?
Item 7: ( ESNUG 386 #16 ) BSD Compiler With Core Logic, HIGHZ, & Pull-Ups
Item 8: Can Cadence's CTGEN Generate A Viable Clock Tree For This Design?
Item 9: ( ESNUG 387 #6 ) 2nd Edit. "Advanced Chip Synthesis" Available
Item 10: ( ESNUG 387 #8 ) Remove That Extra Hierarchy Power Compiler Creates
Item 11: Which Engineering Bug/Issue/Problem Tracking Software Do You Use?
Item 12: Three EDA Users Discuss Three And A Half Books On Backend Design
Item 13: ( SNUG 01 #2 ) Customer Discusses Debug Session Using ViewConnect
Item 14: Are There Any Known EDA Tools That Detect Asynchronous Crossings?
Item 15: How Much Did Synopsys Charge You For Verilog Model Compiler (VMC)?
Item 16: ( ESNUG 386 #2 ) Francine Spanked By 16 Users For Her "Sour Grapes"
Item 17: ( ESNUG 386 #8 ) Using Power Estimation Tools Vs. Actual Silicon
Item 18: VCS Rounding Of SDF Delays Doesn't Match Our PrimeTime Analysis !
Item 19: ( ESNUG 387 #5 ) Using Synopsys DesignWare vs. Rolling Your Own IP
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 388 Item 1 ) --------------------------------------------- [02/27/02]
Subject: ( ESNUG 387 #1 ) What Synopsys Plans To Do With C-Level's Tools
> When I heard of the Synopsys purchase of C-Level, I had the same reaction
> as Dan Joyce of Compaq. I hope the C-Level technology continues, but I'm
> afraid it will suffer the same fate as MOTIVE, which we owned and were
> using successfully until Synopsys bought and killed it in favor of
> PrimeTime.
>
> Do you know if it's still possible to buy the C Level tools now?
>
> - Doug Blettner
> Yotta Networks, Inc. Plano, TX
From: "Mark Hartoog" <markh@cupertino.synopsys.com>
Hi John,
Keep in mind, support for the C-Level products stopped when C-Level went out
of business. Instead, we will support their CycleC methodology by enhancing
our VCS' DirectC to support their restricted C/C++ coding style for
simulation performance. VCS will include waveform viewing and a DirectC-to-
RTL-Verilog translator. There will also be (aptly named) "helper functions"
provided and a coding style checker built into VCS.
DirectC, which provides faster RTL simulation, will compliment our CoCentric
Studio SystemC simulator, which provides faster architectural and HW/SW
simulation. We are planning a release for this summer.
- Mark Hartoog
Synopsys, Inc.
( ESNUG 388 Item 2 ) --------------------------------------------- [02/27/02]
From: "Cyrus Malek" <cyrusm@synopsys.com>
Subject: ( ESNUG 386 #14 ) Cooley Spanked For Omitting PhysOpt's Viewer
Hi John,
I was just reviewing my post in ESNUG 386 #14 and I noticed you chose to
omit some of my post, specifically:
Some Physical Viewer (GUI) highlights that can help you determine
what your cell obstructions look like:
In psyn_gui, when the Physical View is opened, a cell's internal
obstructions can be made visible by checking the check box next to
'Obstruction'. Likewise, the cell's port shapes can be made
visible by checking the check box for 'Port Shape'. In the
standard display mode for cells, all cells that are fixed in place
will show up in a different color. The color setting can be
modified in the Cell Preferences menu.
The tone of my postings has been to gather as much useful information as
possible directly related to 'obstructions' and put it in one place (or a
few postings) in ESNUG. Since not everybody knows what the PhysOpt GUI can
be use for, they aren't necessarily going to use the GUI to sanity-check or
analyze their designs. By posting this GUI information together with the
'obstruction backgrounder' material, I am hoping to help empower users to
be able do debug issues themselves. Not all users are going to be back-end
savvy, and hopefully information like the above can ease the transition to
being more familiar with the back-end.
- Cyrus Malek
Synopsys, Inc. Austin, TX
[ Editor's Note: Sorry, on my second reading of your post, I agree that I
shouldn't have removed the Physical Viewer GUI stuff. Sorry. - John ]
( ESNUG 388 Item 3 ) --------------------------------------------- [02/27/02]
Subject: PhysOpt Rounded Placement Co-ordinates In My Physical Chip Design!
> Here is my problem:
>
> psyn_gui-t> set_cell_location -coord { 129.150 320.210 } cellName
> 1
> psyn_gui-t> report_attrib cellName
>
> ****************************************
> Report : Attribute
> Design : blockName
> Version: 2001.08-SP1-2
>
> Design Object Type Attribute Name Value
> --------------------------------------------------------------------
> blockName cellName cell bounding_box_dim_x1 129149
> blockName cellName cell bounding_box_dim_y1 320210
> blockNamec cellName cell cell_orientation 4
> blockName cellName cell restrictions 2
> 1
>
> The attribute bounding_box_dim_x1 is not the right one. The 1000 coeff is
> OK but I am expecting 129150 ! Any idea ?
>
> - Matt Thieu
> ProXad
From: Muzaffer Kal <muzaffer@dspia.com>
This is either a grid problem or a rounding problem. The cell either can't
be placed at the location you want or the number can't be represented
correctly after doing the multiplication by 1000. Try changing the location
by +-.001 and see if that helps.
- Muzaffer Kal
DSPIA, Inc.
---- ---- ---- ---- ---- ---- ----
From: Matt Thieu <m.r@post.com>
I think it is a rounding problem because if I use:
set_attribute cellName bounding_box_dim_x1 129150
command instead of set_cell_loc, the report_attrib is OK.
- Matt Thieu
ProXad
( ESNUG 388 Item 4 ) --------------------------------------------- [02/27/02]
From: "John McGehee" <johnm@voomtown.com>
Subject: The Avanti User Group "AURORA 2002" Meets This Week In San Jose
Hi, John,
I would like to invite you and your readers to the AURORA 2002 Avanti
User Group Meeting coming up this week on February 25th and 26th in
San Jose, CA. See http://www.avanticorp.com/aurora/agenda for the
schedule. Avanti users should find it well worth their time to attend
this informative event.
- John McGehee, President, AURORA 2002
Voom, Inc.
( ESNUG 388 Item 5 ) --------------------------------------------- [02/27/02]
Subject: ( ESNUG 387 #3 ) Formality 2002.03 (Beta) Finds PhyOpt Buffer Bug
> One of the ACs in San Diego told me about a situation where PhysOpt can
> put "extra inversions" in your netlist and create bad logic. This
> problem can occur if your library has certain cell that can act as *both*
> a buffer and an inverter.
>
> - Mike Montana
> Synopsys, Inc. Dallas, TX
From: [ The French Olympic Skating Judge ]
Hi, John,
I must be anon here. Company politics.
We also encountered that PhysOpt bad logic bug in one of our designs using
Formality while running an RTL-to-synthesized-netlist check. But we were
in trouble. Formality 2000.05-FM.2 couldn't isolate the error due to the
size and complexity of our logic cone.
Our design was 60 K gates, ~310 Mhz, 0.18 TSMC. We were using PhysOpt
v2001.08-1. It turns out that during synthesis set_boundary_optimization
introduced an extra inversion in one path.
We decided to try the Beta version of Formality 2002.03. (It's supposed to
have larger capacity.) It pinpointed exactly where the problem was in our
synthesized netlist. Once we identified the problem and the net where the
change was needed, its new "Source Links" feature showed us exactly where
our Verilog source code needed to change.
We then quickly implemented and verified the fix by running another complete
RTL-to-Synthesized-Netlist check. I strongly recommend using Beta Formality
2002.03, if you can get it from Synopsys. At one point, we were afraid
we would have to re-synthesize this entire (very complex) design. That
would have taken 2 days when you consider that you'd have to restitch the
scan chain back into the new netlist plus redoing all the backend stuff.
Instead, our problem was completely resolved in a matter of hours.
- [ The French Olympic Skating Judge ]
( ESNUG 388 Item 6 ) --------------------------------------------- [02/27/02]
From: [ Scooby Doo, Where Are You? ]
Subject: Is Anyone Currently Using Innoveda's Regent? What Did you Think?
John,
Please keep me anon. Thanks.
Has anyone used Innoveda Regent? It is a pre-RTL front end tool to capture
register definitions (programming model registers). What do you think?
Does it have enough register types (RO, R/W, etc.)? Does it integrate well
with bus protocols (PCI, ARM, Intel, etc.)?
The advertized price seems high for a tool of this category: $15K. This tool
apparently only saves you the RTL design entry step. It is hard to justify
this to management!
- [ Scooby Doo, Where Are You? ]
( ESNUG 388 Item 7 ) --------------------------------------------- [02/27/02]
Subject: ( ESNUG 386 #16 ) BSD Compiler With Core Logic, HIGHZ, & Pull-Ups
> I wouldn't call it perfect as of yet, but BSD Compiler works and it is now
> automated enough that a even co-op student can use it in our design flow.
>
> - Shin Wu, ASIC Division
> Atmel Corporation Columbia, MD
From: Francisco Russi <russi@synopsys.com>
Hi John,
I'd like to address some of the issues Shin Wu from Atmel brought up in
ESNUG 386 #16 reguarding BSD Compiler.
> 1.) BSD Compiler was not able to insert Boundary Scan with the design core
> in the netlist, contrary to BSD Compiler User Guide's claims. We
> overcome this by removing the core before inserting Boundary Scan.
BSD Compiler supports boundary scan logic insertion with or without the
core logic. However, we recommend (but not necessary) our customers to
run the tool without the core logic to avoid any potential run time
performance issue during compliance checking. Running the tool with the
core logic, will impact run times during 1149.1 compliance check, which
uses simulation technique and simulation can create activity within core
logic that is not relevant to compliance checking. This is avoided if
design is used without core logic
> 3.) BSD Compiler had problems with our Synopsys Atmel libraries as well.
> It could not synthesize functional 1149.1 components when input
> buffers supported both true and complementary outputs going into the
> array. It couldn't implement the HIGHZ instruction with bidi buffers.
There were some limitations in implementing the HIGHZ instructions for
complementary ports, which lacked certain special attributes in the library
cell, and could not characterize "bidi buffers formed by combining separate
input and output IO buffer pieces". Although "insert_bsd" was able to
insert the BSR's correctly, the compliance check required a second vector
to properly characterize these pads. We fixed this issue in the 2001.08
release, and a special feature was added to validate pads up front in the
design cycle during "preview_bsd" to let customers know of any pad related
problems early in the design cycle.
> 4.) We still have an outstanding issue with our pullup/pulldown terminators
> which we are trying to get resolved soon. (A workaround for this
> problem is in place until we get a permanent solution from Synopsys.)
BSD Compiler supports library cell pads with internal pull-up and pull-down
resistors. However, pad cells with an external pull-up resistor without a
compliance enable logic to switch off the pull-up for compliance check or
Iddq testing will cause a violation of the 1149.1 standard. The 1149.1
compliance check in BSD Compiler will flag this as a violation to the
Standard since no logic can exist between the pad and the BSR. The
workaround to this issue is to design the pad cell with an internal pull-up,
and use the tool capability to change link libraries for verification.
Once again, I very much appreciate Shin Wu's feedback here on ESNUG.
- Francisco Russi
Synopsys, Inc. Austin, TX
( ESNUG 388 Item 8 ) --------------------------------------------- [02/27/02]
From: "Suttinan Chattong" <suttinan@cyberway.com.sg>
Subject: Can Cadence's CTGEN Generate A Viable Clock Tree For This Design?
Dear John,
I'm just wondering if anyone in ESNUG has experience working with Cadence's
CTGEN (clock tree synthesis tool) in Silicon Ensemble.
I have a design with complexity of about 500 K gates, 0.25 um technology.
The largest clock domain (100 MHz) has around 9,000 flip-flops connected
to it, and clock skew requirement for that domain is 0.25 ns (this number
was obtained from post-synthesis STA. Does anyone know if such a skew
requirement is achievable by CTGEN?
If anyone has prior experience about any other clock tree synthesis tool,
I would like to hear some comments about them - whether such a skew number
is achievable by anyone's state-of-the-art CTS.
Thanks in advance. :)
- Suttinan Chattong
Centre For Wireless Communications Singapore
( ESNUG 388 Item 9 ) --------------------------------------------- [02/27/02]
Subject: ( ESNUG 387 #6 ) 2nd Edit. "Advanced Chip Synthesis" Available
> I find "Advanced Chip Synthesis" to be pretty outdated and some sort of
> a quick-guide to Synopsys manuals. It has basically condensed many
> Synopsys manuals into this one book.
>
> - Suresh Gopalrathnam
> Synplicity, Inc.
From: Carl Harris <Carl.Harris@wkap.com>
Hi, John,
I don't believe your readers know that a new Second Edition of "Advanced
ASIC Chip Synthesis" by Himanshu Bhatnagar was just released a month or so
ago. The comments indicated that the reviewers appeared to be referring
to the old edition. The first edition sold quite nicely. We hope the new
second edition will do even better.
The new Second Edition will be available at SNUG at a 20% discount if
they mention this letter in ESNUG.
- Carl Harris
Kluwer Academic Publishing
( ESNUG 388 Item 10 ) -------------------------------------------- [02/27/02]
Subject: ( ESNUG 387 #8 ) Remove That Extra Hierarchy Power Compiler Creates
> We're using clock gating and scan insertion in DC with a custom clock
> gating cell. I've specified the clock_gating_style as a sequential
> latch with control_point set to before and some appropriate bitwith and
> max_fanout settings. Works fine through synthesis, but the output result
> from DC adds a boatload of unique SNPS_CLOCK_GATE* wrappers around the
> clock gating cell for all instances where the clock gating cell would
> be added:
>
> module SNPS_CLOCK_GATE_HIGH_hdwb_0 ( CLK, EN, ENCLK, TE );
> input CLK, EN, TE;
> output ENCLK;
> GCKAD4 latch ( .TE(TE), .EN(EN), .CLK(CLK), .ENCLK(ENCLK) );
> endmodule
>
> Power Compiler adds this hierarchy at elaboration to attach a batch of
> attributes required to map the clock gating cells, presumably for clock
> gating and scan insertion. However, when going through the layout flow,
> all of these modules represent an extra layer of hierarchy that needs to
> get processed. Is there a way eliminate this extra layer of hierarchy and
> still preserve the clock gating and scan attributes? It seems to me that
> DC should just instance the cell and attach the attributes to the
> instance.
>
> Removing this layer of hierarchy would really cut down the amount of
> instances that need to get processed further down the layout methodology
> path.
>
> - Gregg Lahti
> Corrent Corp. Tempe, AZ
From: "Hamid Nassiri" <hamidn@synopsys.com>
Hi, John,
Clock-gating cells created by Power Compiler have their own hierarchy.
The wrapper design SNPS_CLOCK_GATE* contains the gating elements. It
also preserves the clock-gating attributes. These attributes are needed
for the remove_clock_gating, rewire_clock_gating, and report_clock_gating
commands to work properly. When the SNPS clock-gating cells are ungrouped,
the clock-gating information is lost due to the loss of these attributes.
In the 2001.08 release Power Compiler introduced the power_cg_flatten
variable. By default, it preserves SNPS clock-gating cell hierarchies
during ungroup. This allows the commands mentioned earlier to work fine
because the clock-gating attributes are kept. The default setting for
this variable is "false". When set to "true", it allows the ungroup
command to flatten these cell hierarchies. But then, the clock-gating
attributes are lost and the commands related to clock gating mentioned
before will not work properly. The above description holds true for
"integrated" clock-gating cells as well.
Please note this feature has been documented in the 2001.08 Release Note.
- Hamid Nassiri
Synopsys, Inc. Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: "Gregg Lahti" <gregg.lahti@corrent.com>
Hi, John,
I got it figured out after a few email exchanges from the SNPS AE Chris
Papademetrious -- a big thanks to Chris for his invaluable input. SNPS
added a feature in the Power Compiler section of 2001.08 that enables
smashing of the extra hierarchy:
set power_cg_flatten true;
However, you must set this flag and then run an ungroup to completely
remove the extra hierarchy. I've got two methods to do the ungroup:
1) Compile as normal and run the following Tcl procedure to break up the
hierarchy:
# Usage: P_proj_ungroup_cg
#
# This procedure is used to ungroup the clock gating components
# (SNPS_CLOCK_GATE_*) extraneous hierarchy. Useful so that layout
# doesn't need to deal with thousands of 1-cell hierarchy designs.
proc P_proj_ungroup_cg {} {
echo "#UNGROUP_CG: ungrouping clock gating hierarchy"
# Save current location
set this_design [get_object_name [current_design]];
# Need to traverse through hierarchy & flatten CG components
redirect $sh_dev_null {set hier_designs [filter [find design *] \
{@is_hierarchical == true}]};
if {$hier_designs != {}} {
foreach_in_collection tmp_design $hier_designs {
redirect $sh_dev_null {set current_design $tmp_design};
redirect $sh_dev_null {set cell_list [filter [find cell *] \
{@pwr_cg_design_is_clock_gating == true}]};
if {$cell_list != {}} {
foreach_in_collection tmp_cell $cell_list {
echo "#UNGROUP_CG: ungrouping" [get_object_name $tmp_cell] \
"in design" [get_object_name $tmp_design];
ungroup $tmp_cell -flatten -prefix CG_ -simple_names;
}; # end foreach_in_collection
}; # end if
unset cell_list;
}; # end foreach_in_collection
unset tmp_design;
}; # end if
# Reset current back to where we started from */
redirect $sh_dev_null {set current_design $this_design}
# Clean up namespace
unset this_design
unset hier_designs
}; # end P_proj_ungroup_cg
define_proc_attributes P_proj_ungroup_cg \
-info "PROJ_PROCS: Used to ungroup the SNPS_CLOCK_GATE_* clock gating
hierarchy for the design"
2) Or, set the following variable after elaboration of the design but before
the compile command:
set_ungroup [get_designs {SNPS_CLOCK_GATE_*}];
This was suggested by Chris initially, but didn't work without setting
the power_cg_flatten to be true. This command ungroups designs during
the compile (after the initial mapping but before optimization) to
ungroup the appropriate designs. A much easier command and a lot less
Tcl code.
A side note -- I tried the set_ungroup command frome example (2) to remove
extraneous DesignWare hierarchy but it didn't work. I use essentially the
same script from example (1) (replace the @pwr_cg_design_is_clock_gating
with @DesignWare, replace CG_ with DW_) to smash the DW hierarchy into plain
standard cells after the compile phase.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 388 Item 11 ) -------------------------------------------- [02/27/02]
Subject: Which Engineering Bug/Issue/Problem Tracking Software Do You Use?
> On a recent chip design project, we missed a few issues that came up during
> the quarter. We simply forgot to jot down the problems in a centralized
> location. So during the design-review, the issues went unaddressed.
>
> We need some recommendations on software which will help us track
> problem-reports. The problem-reports are going to be used internally only
> (they won't be sent to third parties.) I'm not sure what category this
> application falls under, but basically, we just need some kind of database
> for problem-reports. We'd like to be able to open and close issues, as
> well as query the database for a list of all outstanding/active problems.
>
> Does MS-Office2000 niclude a package with this kind of function?
From: "Leon Heller" <leon_heller@hotmail.com>
You could probably use MS Access for this. It's part of the Professional
version of MS Office. I've used it for tracking design requirements.
- Leon Heller
---- ---- ---- ---- ---- ---- ----
From: "Pallav Gupta" <pgupt@ece.arizona.edu>
Or if your using Unix/Linux you can also use GNATS, the GNU Bug Tracking
Software. http://www.gnu.org/software/gnats/
- Pallav Gupta
University of Arizona
---- ---- ---- ---- ---- ---- ----
From: "Srinivasan Venkataramanan" <srinivasan.venkataramanan@intel.com>
Hi, you may want to try IPlan from:
http://www.iplanenterprise.com/default.htm
I had attended a demo from them in my previous company. It was very
impressive; looked similar to MS Excel, etc. I think it does much more than
just Bug Tracking, so perhaps might also cost much more. :-) Perhaps you
can ask them for just Bug Tracking capabilities.
- Srinivasan Venkataramanan
Intel Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: "Michael A. Beaver" <mbeaver408@aol.com>
I just recently used bugzilla which is a free public domain package written
in Perl. It is slanted toward tracking SW projects but can used for ASIC
design and firmware projects. http://www.mozilla.org/projects/bugzilla
- Mike Beaver
3D Modeling Labs Pacific Grove, CA
( ESNUG 388 Item 12 ) -------------------------------------------- [02/27/02]
Subject: Three EDA Users Discuss Three And A Half Books On Backend Design
> I'm searching for a good book about backend design. All the way from
> floorplanning, P&R, extraction, to GDSII. It should be more general, but
> can have sections about the tools from Cadence/Avanti, etc. A web search
> didn't result in anything useful.
>
> - Lars Rzymianowicz
> University of Mannheim Germany
From: Bernd Fischer <bernd.fischer@xignal.de>
This are two books someone suggest me some time ago.
Clein, Dan
CMOS IC Layout
Newnes
ISBN 0-7506-7194-7
CMOS IC Layout: concept, methologies and tools
Hastings, Alan
The Art of Analog Layout
Prentice-Hall
ISBN 0-13-087061-7
The Art of Analog Layout, Integrated Circuits - Design & Construction
They are both interesting. My preference is 'The Art of Analog Layout'.
You can get them form amazon.com.
- Bernd Fischer
Xignal Technologies AG
---- ---- ---- ---- ---- ---- ----
From: "Srinivasan Venkataramanan" <srinivasan.venkataramanan@intel.com>
I am not sure if this book will help you with any particular tool, but the
basic concepts are best described (IMO) in this book.
http://www.addall.com/Browse/Detail/0792392949.html
Algorithms for VLSI Physical Design Automation
Author: Naveed A. Sherwani
Binding: Hardcover, 512 pages
Publisher: Kluwer Academic Publishers
Published Date: 01/01/1993
List: USD $130.00
ISBN: 0792392949
A bit bulky - but worth every page, I would say. We used it during our VLSI
Master's programme and was extremely useful.
- Srinivasan Venkataramanan
Intel Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Thanks for the tip, Srini.
I was first worried about the publish date: 1993. A bit outdated. ;-)
But I found a 3rd edition (1998) at http://www.wkap.nl/prod/b/0-7923-8393-1
That looks like what I searched for.
- Lars Rzymianowicz
University of Mannheim Germany
( ESNUG 388 Item 13 ) -------------------------------------------- [02/27/02]
Subject: ( SNUG 01 #2 ) Customer Discusses Debug Session Using ViewConnect
> ...yawn. Sorry, Aart... not much new, but more hope to see more soon. I
> wanted more on topics like Linux, 64 bit support, cross talk in timing
> delays, & the new tool for sharing views on machines between Synopsys and
> customers out in the field for debugging problems (ViewConnect.) I didn't
> get to see any of this at SNUG, but heard about a good demo on it done at
> EuroSNUG.
>
> - Chris Kiegle of IBM
From: Jay Dutt <JDutt@NetSilicon.com>
Hi, John,
Here's my experience with Tetramax and ViewConnect. At Netsilicon I was
using the old Test Compiler tool but was getting unacceptable (77%) test
coverage results. Since Synopsys informed me that Test Compiler was "end-
of-life" soon and support was minimal, I decided to evaluate Tetramax to
see if I could get that coverage up to the mid-90's %age or higher.
I started the Tetramax evaluation and got stuck -- lots of "cell blockage"
error messages. Synopsys wanted to see the netlist, libraries, scripts,
etc. I was using, but I didn't have permission from management to make
these available off-site, even under NDA. I also had very limited amounts
of time that I could spend on the eval, as I had to get some other real
work done. The Synopsys Applications Consultant was not able to spend a
lot of time at our site to help me solve this problem (there were always
schedule conflicts with my time or her's.) So she suggested using
ViewConnect. This is a Synopsys tool we got set up and running on my Sun
workstation which enabled her to see what was going on from her remote
office, while I was typing commands, running scripts, editing files, etc.
We quickly found that I was using ASIC vendor verilog simulation specific
libraries, not the libraries which called out Tetramax primitives. Fixed
the problem by getting the right libraries from our ASIC vendor.
Then I started getting the good coverage results that I wanted, but there
was another snag: rerunning those vectors through "simulation playback"
revealed mismatches on one of the scan chains in our design. This would
mean that those ATPG vectors would probably cause mismatches on the ASIC
vendor's tester, so the problem had to be corrected. Again, I shared the
problem remotely with the Synopsys AC using ViewConnect. This time with
the Tetramax Analyzer GUI showing the problem chain. We found that there
were two phases of a clock used in the chain (ie. some registers had one
phase, the rest used the other phase). I corrected this, and now have a
set of high coverage ATPG vectors to release to the vendor for test.
By the way, ViewConnect was double-password protected (one on my side and
on from Synopsys) so I was reasonably confident about security. I made
sure I wasn't running as "root" in the xterms under ViewConnect, so
really bad things couldn't happen! Also, I guess you do have to trust
Synopsys not to do something bad on their side, as they can remotely
type commands on the xterm shell as well. It took about 3 or 4
ViewConnect sessions to complete the Tetramax evaluation, each lasting
about 30 minutes.
- Jay Dutt
Netsilicon, Inc.
( ESNUG 388 Item 14 ) -------------------------------------------- [02/27/02]
From: Al Jacoutot <Al.Jacoutot@SiliconAccess.com>
Subject: Are There Any Known EDA Tools That Detect Asynchronous Crossings?
Hi, John,
Are you aware of any EDA tools that identify a design's asynchronous
crossings and check for safe design practice? I posed this question to a
few EDA companies, but nobody I spoke with had anything available, in
development, or even in mind.
- Al Jacoutot
Silicon Access Networks, Inc.
( ESNUG 388 Item 15 ) -------------------------------------------- [02/27/02]
From: "Dale Walter" <Dale.Walter@actel.com>
Subject: How Much Did Synopsys Charge You For Verilog Model Compiler (VMC)?
Hi John,
Do you know how much Synopsys charges for Verilog Model Compiler?
- Dale Walter
Actel Corporation Sunnyvale, CA
( ESNUG 388 Item 16 ) -------------------------------------------- [02/27/02]
Subject: ( ESNUG 386 #2 ) Francine Spanked By 16 Users For Her "Sour Grapes"
> Verisity has been a member of Synopsys' in-Sync program for several years
> and Synopsys is a member of our interoperability program, VIP. This year,
> for the first time, we were informed that we (Verisity) would not be
> allowed to participate (as we always have) in the vendor fair that is
> always held during SNUG. ... Was it perhaps that we are competitors? Is
> favoritism being given to those companies that are helping to push Synopsys
> standards? Is this truly in Aart's stated spirit of interoperability and
> competition? Or is it in fact Synopsys trying to choose for the customer
> rather than listening to the customers?
>
> Perhaps interoperability and competition are only important when it is
> Synopsys that is trying to compete against Cadence.
>
> - Francine Ferguson
> Verisity Design, Inc. Mt. View, CA
From: "Leah Clark" <xlc@cypress.com>
Hi John -
It's funny, I was actually offended when I read what Francine said. It
seems that she has never actually been to SNUG, or she would know that
there's nothing about it that's "pushing" Synopsys' marketing agenda. The
SNUG Tech Committee is led by a non-Synopsys employee, and is responsible
for determining paper acceptance. The content of the papers is 100% up to
the authors, with the exception that no marketing content of any kind is
allowed. The tutorials are very technical in nature, and the only
*possible* marketing content is in Aart's address. That's it.
I have been involved with SNUG in some form for 5 or 6 years now, and have
always been impressed at the resources Synopsys dedicates to the group, from
a full-time (non technical!) conference organizer to the incentives given
industry presenters and tech committee members. I think it's an impressive
show of dedication to the users and their issues, without the overhead of
marketing content.
I'd be happy to go on about this, but I'll stop here. I hope you will let
Francine know that her accusations are without ground, and that she's
probably already pissed off a lot of Synopsys users and SNUG attendees.
- Leah Clark
Cypress Semiconductors
---- ---- ---- ---- ---- ---- ----
From: "Steve Golson" <sgolson@trilobyte.com>
Hi, John,
Francine wonders why Verisity is excluded and speculates "Was it perhaps
that we are competitors?". I seriously doubt that! After all, Cadence
and Mentor will be there. I suspect there is more to this than Ms. Ferguson
would have us think, and that Verisity caused some of this mixup themselves.
Methinks Verisity doth protest too much.
Anyway, SNUG is much more than the interoperability fair. I've been
attending SNUG for over ten years, I've authored several papers, and I'm
currently on the technical committee helping to select and review user
papers. The important letter in SNUG is not the S for Synopsys, but the U
for Users! I go to meet my fellow designers and see what great new ideas
I can glean from them.
Plus, the food is great! See you in San Jose.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ---- ----
From: Erich Whitney <ewhitney@axiowave.com>
Hi John,
The people that attend SNUG are smart enough to smell a rat a mile away.
I've been on both sides of this issue being a former Synopsys employee
myself. And I can assure you that the marketing folks are well away from
the internals of the conference. In fact, it always kind of bothered me
when I worked for Synopsys and attended SNUG that I couldn't really say what
was going on because of the fact that we didn't want to be in any way seen
as trying to do marketing. It was strictly business and we spent countless
hours preparing the Synopsys SNUG presentations to keep them 100% factual
and accurate.
Quite frankly, I don't have much time for people who want to spread this
kind of FUD. I have been and continue to be extremely proud of the SNUG
folks.
- Erich Whitney
Axiowave
---- ---- ---- ---- ---- ---- ----
From: Mark Sprague <msprague@ati.com>
Hi, John,
There is a requirement that the papers be related somehow to Synopsys tools.
However, I've reviewed several papers that have used other companies
tools for parts of their flows.
My guess is that if a Cadence employee proposed a paper on getting good
clock tree results from a Power Compiler design, or tricks to interface
PhysOpt with the Cadence back end, these would be well received.
I don't know what happened that caused Francine's claim, but at least from
my naive view, it sounds like sour grapes more than anything.
- Mark Sprague
ATI
---- ---- ---- ---- ---- ---- ----
From: "Al Czamara" <czamara@zaiqtech.com>
Hi, John.
I remember Francine's comment. My impression was "sour grapes," so I didn't
give it much credence. Standing in her shoes, however, I would likely feel
slighted, too. If Verisity were the only company omitted from the vendor
fair at SNUG, I'd start thinking something smelled rotten. If not, I'd
want to sanity check how emotionally involved I let myself become to the
decision.
- Al Czamara
Zaiq Technologies, Inc. Marlboro, MA
---- ---- ---- ---- ---- ---- ----
From: "Rodney Pesavento" <rodney.pesavento@corrent.com>
John,
A paper I reviewed for SNUG'02 didn't mention a Synopsys tool. Synopsys
complained that the examples didn't cover VCS. I did ask the author to add
a note that similar techniques could be used in VCS. Synopsys was happy
and the paper really didn't change. So, no I don't think Synopsys controls
SNUG too much.
- Rodney Pesavento
Corrent
---- ---- ---- ---- ---- ---- ----
From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
Hi, John,
I don't think competition was the reason Verisity was not invited to the
SNUG vendor night this year. I think the bigger issue is space availability
and a judgement call on the part of Synopsys (the "tiered" system). I see
plenty of Synopsys competitors at the fair each year and have marveled that
they were even invited. I have tried to get booth space at the fair a few
times myself to promote my Verilog language and synthesis classes but I
think there is more interest in tools that relate to the core synthesis and
simulation businesses than there is in my training. I believe every vendor
at the fair is an In-Sync partner and I believe every vendor at the fair
would argue that their tools and services are vitally important to SNUG
attendees (whether they are or not - I know my training booth would be the
most attended booth at the conference ;-)
That having been said, I personally would like to see Verisity return to
the SNUG vendor fairs. Maybe Francine has flagged their absence in a public
enough way to encourage SNUG attendees to subpoena the presence of Verisity
at future vendor fairs by noting it on their SNUG conference evaluation
forms. If there are lots of requests, I think Verisity will make a swift
return. No requests might show that the attendees have other primary
interests at this conference.
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: Brian Kane <briank@torrentnet.com>
Hi John,
I know that Cadence always has a small booth at SNUG, Avanti was usually
there and I remember Plato presenting NanoRoute in Boston SNUG last year
which was after Synopsys Route Compiler had been announced. I'm sure
there are other examples that I can't think of off the top of my head.
I don't think that SNUG is driven by the Synopsys Marketing agenda since
the user papers and tutorials make up over 90% of the conference.
- Brian Kane
Ericsson IP Infrastructure
---- ---- ---- ---- ---- ---- ----
From: Peet James <peetj@qualis.com>
Hi, John,
The only marketing that sometimes might get through is by some presenter
trying to promote their company (not Synopsys, but some other EDA company.)
This is one of the main tasks of the SNUG Tech Commitee, to weed marketing
out and to ensure good, technical user content. I think they accomplish
this task well, but every once and awhile (maybe twice that I can think of
in the last 5 years) someone slips some marketing by. I know guys on the
Verisity Club V committee and I believe they have the same goal to
ensure good technical user content and stamp out marketing pitches.
- Peet James
Qualis Design Laffayette, CO
---- ---- ---- ---- ---- ---- ----
From: "Darell Whitaker" <darell@us.ibm.com>
John,
While I see where companies competing in Synopsys arenas may think that
Synopsys is using SNUG as a marketing venue, I have to disagree. The only
area where marketing poop is done, besides the vendor fair, is the keynote
address. (Sorry, Art.)
The SNUG tutorial sessions can't be beat for value. Not everyone can afford
the bucks to go to a formal Synopsys class, but can afford the price for the
conference.
- Darell Whitaker
IBM
---- ---- ---- ---- ---- ---- ----
From: "Tim Wilson" <tim.l.wilson@intel.com>
John,
The SNUG Technical Committee works hard to screen out marketing pitches by
the presenters. The process of selecting User Papers is driven by the SNUG
Technical Committee and not by Synopsys Marketing.
- Tim Wilson
Intel
---- ---- ---- ---- ---- ---- ----
From: "Christopher Kiegle" <ckiegle@us.ibm.com>
Hey John,
To be honest, the SNUG Vendor Fair is at the bottom of my list in terms of
SNUG value. The user papers are at the top. It's nice to hear about other
tools, but there are other forums for that, like DAC.
I'm sure floorspace is also a concern at SNUG, too, since the vendor spaces
spilled out into the hall last year.
- Chris Kiegle
IBM
---- ---- ---- ---- ---- ---- ----
From: Stefan Scharfenberg <Stefan.Scharfenberg@motorola.com>
Hi John,
Well SNUG is a bit Synopsys biased, but that's no surprise after all it is
a Synopsys User Group meeting. I think everybody involved tries to be as
objective and neutral as possible. That's what I have seen on ESNUG and
during my time as a Tech Committee member. Calling SNUG a marketing puppet
is by far exaggerated.
I do see that Synopsys people pay a lot of attention to SNUG, but that's
not a bad thing. We use SNUG sometimes to get things done faster. Things
that Synopsys did not react upon quickly enough or to our satisfaction,
suddenly become more important if they appear in the public in SNUG/ESNUG.
- Stefan Scharfenberg
Motorola GmbH Munich, Germany
---- ---- ---- ---- ---- ---- ----
From: Don Mills <mills@lcdm-eng.com>
John,
This is what I would expect from a Marketeer trying to degrade the
competition. Just last year there was a paper submitted on the flow and
application of Test Languages (Vera or E from Verisity). The paper did not
mention any tool specifically, therefore it came under the category of
"generic flow" and was accepted. I (as Chair) got calls from the Vera
group telling me that the paper had to be pulled because the author did
not use Vera. The Vera group could not believe that we would permit a
paper to be presented from an author that used E from Verisity. The
paper was accepted because it only discussed flow and methodology.
A few years back, there was a paper submitted that discussed comparisons
between different synthesis tools. I again was called (as Chair) and asked
to have the paper pulled. In this case, because the paper was discussing non
Synopsys tools, there was some merit to the request. The paper was presented
at SNUG. In fact, it was one of the few papers ever presented in which
Synopsys offered a rebuttal to the paper. It was great.
- Don Mills
LCDM Engineering, Inc. Utah
---- ---- ---- ---- ---- ---- ----
From: Gil Herbeck <gilherbeck@attbi.com>
John,
I think Francine's questions are legitimate. I'm not crying foul. At some
point there will be more interested vendors than available space at the
fair. Someone's going to be left out.
- Gil Herbeck
---- ---- ---- ---- ---- ---- ----
From: "Ahmad Salah Ammar" <asammar@canada.com>
Hello John,
I'm actually shocked that such a statement was made. I've been on the Tech
Committee for SJ and Boston SNUG for about 2 years and I definitely did not
sense this, not even remotely. My experience has been that SNUG is
extremely user-driven.
I don't think I would be stretching it if I said that the statement is an
insult to the members of the Tech Committee! Just because Synopsys supports
the conference and probably benefits from it somehow does not make it a
puppet organization used to push the Synopsys Marketing agenda. I don't
think it is too much to ask Ms. Ferguson to support her statement with some
concrete incidents/examples!
- Ahmad Salah Ammar
( ESNUG 388 Item 17 ) -------------------------------------------- [02/27/02]
Subject: ( ESNUG 386 #8 ) Using Power Estimation Tools Vs. Actual Silicon
> I have been reviewing reader comments on your http://DeepChip.com looking
> for information on the correlation between calculations of total power by
> cell level power analysis tools and actual silicon. Not a word to be
> found... hmmm... So then how good are these 4 significant digit power
> model library characterizations that many are using? Are they useful only
> for relative power comparison or can they be used more reliably?
>
> - Ken Wagner
> PMC-Sierra, Inc.
From: Yoshi Iwase <yiwase@amis.com>
Hi, John,
I've been using a dynamic power calculation tool for almost two years.
The tool is called PrimePower from Synopsys. It uses the 4 digits power
library characterized by PowerArc tool. After some experience, we have
been seeing very consistent result between the PrimePower results and
our final silicon. The key issues are the accuracy of library/LPE (since
all power such as internal power, gate cap and wire cap comes from there)
and the measurement technique. After calibrating these, we easily saw
correlation within 10% between PrimePower and silicon.
I am presenting more details on PrimePower at San Jose SNUG, Mar.13-15.
- Yoshi Iwase
AMI Semiconductor Inc.
( ESNUG 388 Item 18 ) -------------------------------------------- [02/27/02]
From: "Stephen O'Connor" <soconnor@silicon-packets.com>
Subject: VCS Rounding Of SDF Delays Doesn't Match Our PrimeTime Analysis !
Hi John,
We've been annotating an SDF to a gate level netlist and seeing behaviour
that doesn't link up with the results of our PrimeTime analysis. In
particular, we're seeing scan chain shift issues caused by clock skew that
seem to be okay in Primetime. It seems the skew that is seen between the
flops in the VCS simulation is larger than that predicted in PrimeTime,
slightly larger, and that's enough to kill our sims.
My specific question is: how does one control the timing resolution in a
VCS simulation that is annotated with an SDF? I've always assumed that
the precision of the SDF would control the simulation precision. The SDF
we have is specified down to 0.0001 nsec increments, but the simulation
'seems' to be running with a 0.01 nsec precision. It seems that we're
hitting a situation where rounding going on.
I should point out that the SDF I'm using has CELL entries annotated with
IOPATH delays, and INTERCONNECT delays. The INTERCONNECT delays can be
smaller than the 0.01 value that VCS seems to be simulating.
Also the clock tree delays do not contain any negative delays, which could
be rounded to zero and aggravate the skew. Any help appreciated.
- Stephen O'Connor
Cypress Semiconductor San Jose, CA
( ESNUG 388 Item 19 ) -------------------------------------------- [02/27/02]
Subject: ( ESNUG 387 #5 ) Using Synopsys DesignWare vs. Rolling Your Own IP
> DesignWare does do trade-offs of different adder architectures for you, as
> does the Ambitware stuff in the Cadence synthesis tool. If you really
> must use DC, you can improve its default results (if you have the
> appropriate licence) by adding the following:
>
> set synthetic_library "dw_foundation.sldb"
> set dw_prefer_mc_inside true
>
> Why isn't this the default, then? Because you need to have an extra DC
> licence to use it. Don't recall which one, sorry. There is a similar
> "datapath" option when running Ambit which I think is specified on the
> ac_shell command line.
>
> - Andrew MacCormack
> Cadence/Tality Livingston, Scotland
From: Oliver Meisel <oliver@synopsys.com>
Hi John,
A couple of things regarding DesignWare usage and the type of tradeoffs it
makes.
First a minor correction to Chris' message.
The license required to enable the more advanced architectures is now called
simply "DesignWare". (This is the same license required to use the more
complex IP blocks and the verification models in DesignWare such as PCI-X.)
With this license, and by setting the synthetic_library variable to
"dw_foundation.sldb", DC will be able to leverage more arithmetic and
datapath components with more complex architectures and therefore will
make better tradeoffs.
The Standard DW Library only contains ripple carry and carry look ahead
(CLA) architectures for adders and carry save arrays for multipliers.
DesignWare offers a variety of high performance structures such as Wallace
tree multipliers and Brent-Kung, fast CLA, carry-save, and carry-select
architectures for adders.
Chris also mentioned the dw_prefer_mc_inside variable (he is right, no
Module Compiler license needed.) When this variable is set to "true",
the datapath elements are dynamically generated using Module Compiler
technology.
In addition, if a DC-Ultra license is available, two more advanced
commands can be used - transform_csa and partition_dp. The partition_dp
command transforms arithmetic operators (+,-,*) into datapath blocks
which will be implemented with the Module Compiler based datapath
generator mentioned above. The transform_csa command transforms those
arithmetic operators into carry save architectures (CSA).
Here's a simple datapath example and different timing/area results with
different flows.
module mux4 (m0,m1,x,b0,b1,z);
parameter n=32;
input [n-1:0] m0,m1,x;
input [2*n-1:0] b0,b1;
output [n:0] z ;
wire [2*n:0] y1;
wire [2*n:0] y0;
wire [2*n:0] y2;
assign y0 = m0*x + b0;
assign y1 = m1*x + b1;
assign y2 = (y1>y0) ? y1 : y0;
assign z = y2[2*n:n] + y1[(n-1):0];
endmodule
All of these have been achieved using TSMC's 0.13 um technology and the
2001.08-SP2 release of DC.
Flow Path Length Path Slack Design Area Compile Time
-------------------- ----------- ---------- ----------- ------------
DC-Expert + DW_Standard 13.74 -7.24 240760.28 2745.29
DC-Expert + DW 7.33 -0.83 213677.06 3161.75
DC-Ultra + DW + MCI + TCSA 6.63 -0.13 210615.31 2754.35
DC-Ultra + DW + MCI + PD 6.50 0.00 174409.92 952.84
DW_Standard is the standard library shipped with DC. DW is the full
DesignWare library. "DW + MCI + TCSA" means DesignWare, with
dw_prefer_mc_inside set to true and transform_csa command. "DW + MCI
+ PD" means DesignWare, with dw_prefer_mc_inside set to true and
partition_dp command
- Oliver Meisel
Synopsys, Inc. Mountain View, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 12,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
