From: Stu Sutherland <stuart in sutherland-hdl spot tom moomoomoo>
John,
I thought your readers might be interested in this...
I just finished making my hotel reservations for DVCon and SNUG-San Jose,
and found I could get a better rate on the internet than what either
conference has negotiated. Both conferences are at the Doubletree Hotel,
in San Jose, CA. DVCon (24-26 Feb 2003) negotiated $165/night (per the
Doubletree reservation toll free number), but using the Doubletree
internet reservation system (http://www.doubletree.com) I was able to
get $152/night. SNUG (17-19 Mar 2003) negotiated $169/night, but the
$152 rate was also available on the internet for those dates.
- Stu Sutherland
Sutherland HDL Inc. Tualatin, OR
( ESNUG 404 Subjects ) ------------------------------------------- [01/08/03]
Item 1: ( ESNUG 403 #14 ) Customer Runs Into Newbie PowerMill Problems
Item 2: ( ESNUG 403 #6 ) We Like Chrysalis As Our Gold Model vs. Formality
Item 3: Can TetraMAX Generate Path Delay Patterns With Don't Cares?
Item 4: ( ESNUG 403 #5 ) EEcad.com, Everest Glint, Novas nLint, Verilint
Item 5: Dave's Special DC TCL Scripts That Fix Hold Times On Scan Cells
Item 6: ( ESNUG 400 #7 ) Why DC 2002.05 Differs On HPUX vs. Linux/Solaris
Item 7: ( ESNUG 396 #3 ) Rectilinear Blocks In PhysOpt/Apollo/Astro Flows?
Item 8: Synopsys Officially Kills Off Chrysalis In Favor Of Formality
Item 9: Questions on Mentor Mach TA vs. Synopsys Nanosim vs. Nassda HSIM
Item 10: ( ESNUG 403 #11 ) Do NOT Run Contending Patterns On Your Tester!
Item 11: Gregg's PhysOpt, Astro, PrimeTime, VCS, Tcl, BSD, Virsim Wish List
Item 12: A User Mix/Max Delay Extract_Model PrimeTime Methodology Question
Item 13: ( ESNUG 371 #5 ) DC & Synchronizers With Inputs Tied To Zero
Item 14: EDA Community Gives 450 Toys And 532 Pounds Of Food To The Needy
Item 15: How Are The Tools/Techniques For Sync/Async Resets Down At 0.13 ??
Item 16: Our DC, Monterey, Calibre, Simplex, PrimeTime, Formality Tapeouts
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 404 Item 1 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 403 #14 ) Customer Runs Into Newbie PowerMill Problems
> I just started to use PowerMill for quick power simulation. I have two
> problems on it:
>
> 1. When I tried to simulate a design, PowerMill asked me to provide SPICE
> netlist of ALL modules used in my design. All my designs are written
> in VHDL and synthesized by Synopsys Design Compiler/Analyzer. Then
> they are saved in Verilog format. After converting to EPIC using
> Vlog2e, these designs contain only Synopsys standard gates like AO5
> and EO1, etc. I think PowerMill should know what they are. But now
> I have to provide the netlist of even AN2. Is there another way to do
> this? It is hard to provide all of them because the libraries of
> Synopsys are un-readable.
>
> 2. In simulating some designs, I got error message like "Bus error-Core
> dumped". I have no idea of this error. I don't think its my design
> that's causing this.
>
> Any ideas, anyone?
>
> - Jia Di
From: Ruma Sen <r58740|04785r ofofof email.mot dot domme catcatcat>
Hi John,
This is regarding the PowerMill problems that Jia Di is facing.
PowerMill simulation needs these files for its SPICE-like simulation:
1. Complete hierarchical Verilog netlist (single or multiple files
may be provided through -vlog option)
2. Transistor-level netlist for each cell in the library
(SPICE/Spectre) (individual netlists in a directory through "-L"
option or one netlist of all subcircuits specified using -nspice/
-nspectre)
3. Transistor-level netlist of any macro cell not in the cell library
4. A technology file (needed if models are not directly supported;
otherwise models may be directly included)
Difficult to predict what might cause coredump; it may be possible to
get some insight into this using 'truss'.
- Ruma Sen
Motorola
---- ---- ---- ---- ---- ---- ----
From: Joe Cook <cluckcluck joe.cook from synopsys|sysponys spot dawn>
Hi John,
PowerMill is a transistor level simulator, therefore, you must have
transistor level representation of all cells as well as the transistor
models. If you do not have transistor sub-circuits and models but you
do have power characterized libraries, you can use Synopsys' PrimePower
tool to analyze power.
- Joe Cook
Synopsys
---- ---- ---- ---- ---- ---- ----
From: Maureen Ladd <maureen.ladd barkbark by s*y*n*o*p*s*y*s rot palm>
Hello John,
I do not know what version of PowerMill Jia's using, but he should NOT be
running the separate Vlog2e utility anymore and converting to EPIC format.
PowerMill will directly read in a Verilog gate-level netlist, but you do
need to supply the transistor-level subckts for each cell. This is
because PowerMill runs at transistor-level to obtain the current and
voltage information for each device; it does not use the timing inside of
a .lib or .db.
Has he checked into Synopsys SolvNet to read the articles on this topic?
There are a couple about what the PowerMill command line looks like to bring
in Verilog gate-level netlists, and what other set up is needed to run at
transistor-level.
Or maybe he really wants to run at gate-level, in which case he would run
PrimePower, which requires that the cell library is characterized for power.
- Maureen Ladd
Synopsys, Inc.
( ESNUG 404 Item 2 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 403 #6 ) We Like Chrysalis As Our Gold Model vs. Formality
> We also used to use Formality but got sick of the bugs and decided to dump
> it in favor of something else. We tried out both Verplex Tuxedo & Mentor
> FormalPro. ... but I do recommend anyone looking into a formal tool to
> consider the Mentor FormalPro tool.
>
> - Russ Petersen
> Scientific Atlanta
From: Luis Basto <luis.basto by moomoomoo aannaalloogg fraught calm>
Hi, John,
We looked briefly at Formality and found it failed some modules that
passed Chrysalis. Since we still treat Chrysalis as the "golden model",
we are rating Formality lower. Caveat: we don't have as much experience
or spent as much time with Formality so we are still evaluating it.
- Luis Basto
Analog Devices Austin, TX
( ESNUG 404 Item 3 ) --------------------------------------------- [01/08/03]
From: Puneet Gupta <puneet near vlsicad.ucsd bought edu dogdogdog>
Subject: Can TetraMAX Generate Path Delay Patterns With Don't Cares?
Hi, John,
I am working on improving path delay fault coverage in a full scan design.
For this I need test patterns which are not completely specified (i.e. for
a given path, I need 0/1 values on the flip-flops that actually sensitize
the path and "x" or don't-care on the flip-flops which do not effect the
path.) How can I do this in Tetramax? If Tetramax can not do this, this
should be possible using DC or Primetime. Does anyone have pointers to
such a script ?
- Puneet Gupta
UCSD
( ESNUG 404 Item 4 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 403 #5 ) EEcad.com, Everest Glint, Novas nLint, Verilint
> Glint is our Verilog and VHDL code verifier which is provided by Everest
> Design solution, Inc. a subsidiary of Silvaco International.
>
> - Frank Li, Sales Manager
> Silvaco International Santa Clara, CA
From: Ryan Melius <ryan.melius meowmeow near eecad got plomb>
Hi John,
A few guys mentioned Everest's Glint for Verilog linting. If Jeff is
looking for an inexpensive solution, he can find Glint on our company's
http://www.eecad.com web site for $8 an hour.
- Ryan Melius
e*ECAD Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Pradip Thaker <bleatbleat pthaker in zagrosnetworks not calm>
Hi, John,
If this not too late to chime in on linting discussion...
About an year ago, I evaluated Verilint, HDLint, nLint (NOVAS) and
Verisity's SureLint. Although analysis was subjective, it wasn't partial.
I found Novas's nLint as a credible and reliable product. They were not
too expensive to afford either. My experience with NOVAS has been is that
they generate good quality products.
The fundamental problems with linting tools in Verilog (since Verilog is a
loosely-typed language) is that some tend to be too conservative and
generate so many messages that designers tend to learn to ignore them and
throw out baby with bath water (good catches are being lost due to
overwhelming number of messages since filtering methods are not efficient).
Other exterme of this is when some tools behave too liberally and do not
catch bad coding style practices (although they may be synthesizable,
certain coding practices are considered better avoidable). I found NOVAS's
nLint a good balance between these two extermes. They catch most of what
I consider bad coding practices from synthesis, DFT, partitioning, etc.
point of views and provide programmable switches for "style" related
issues. My team has been using this tool for about an year now and have
found it satisfying.
- Pradip Thaker
Zagros Networks Rockville, MD
( ESNUG 404 Item 5 ) --------------------------------------------- [01/08/03]
From: David Simmons <simmod goatgoat near taec.toshiba caught bomb>
Subject: Dave's Special DC TCL Scripts That Fix Hold Times On Scan Cells
Hi, John,
This set of scripts will fix hold times on scan chain inputs using Design
Compiler, by inserting delays. Hold time problems in scan chain shift
timing can be fixed by a DC recompile, of course, but in such case care
must be taken to keep Design Comapiler from doing anything to create
problems with functional logic, which usually requires multiple compile
scripts with "case" statements, repeated timing analysis runs to monitor
DC's effect on the netlist, etc. With these scripts we can avoid all that,
at least in those cases where we have a library with scan FFs which have a
dedicated scan shift data pin. (Reordering the scan chain in order of clock
delays is another (and possibly better overall) solution to fixing scan
shift hold time problems, but is somewhat more complicated to automate).
I have a main script which does some setup and it then calls my "add_delays"
routine, which then will fix hold times in the design specified by the
"TARGET_DESIGN" variable.
In this implementation of the scripts, the "add_delays" procedure looks for
all FF "TI" input pins. Those inputs are normally used only for scan chain
shift connections, so if you're using them for something else anywhere, be
aware that the script does not discriminate and will also fix hold times on
TI pins used for functional logic. Generalll, the "get_scan_hold_violators"
procedure could be replaced with something that loads the "TI_PIN_LIST"
variable using a different selection criterion (i.e. something other than
"[get_pins -hier */TI]"), in order to get an arbitrary list of violating
endpoints. Or, the violating endpoint pins could be extracted from some
PrimeTime as "an exercise is left to the reader".
The main script calls "add_delays" twice, rereading SDF annotation in
between calls, since we've observed that hold time violations aren't always
worst-case with min SDF annotation. The "PASS_CYCLE" variable is
incremented between runs to make sure the netlist doesn't end up with
duplicate instance names being added.
The "DELAY_CELL_TYPES" variable needs to be loaded with a list of the
buffers to be used for delays, preferably in order of ascending delay
(choice of delay cells is another topic which could be discussed at length).
The "add_delays" routine then cyclically inserts a cell from the list on
the violating inputs, rechecks to see if it fixed the hold-time problem,
iterating in the delay cell list and retrying as necessary. If the
maximum-size delay cell won't fix the hold-time violation, it starts the
cycle over, adding another delay cell in series. Delay cell instance names
are tagged with the "pass cycle" (corresponding in this case to successive
SDF annotations), the "delay cycle" (corresponding to the current target
delay cell), and a date code. The date code prevents identical instance
names from being generated in the unlikely event that the script finds the
same error twice on the same design, in successive ECO cycles. The user
might want to change the naming convention to suit themselves (the current
protocol tends to generate some rather stupendous net names). The scripts
assume that all buffers or delay cells use the "pin A input/pin Z output"
format for inserted cells; the pin names in the scripts will have to be
modified for libraries which don't conform to this regime.
In addition to being applied to the netlist, the commands to add delays are
also written to the file named by the MOD_COMMAND_FILE variable. Since
typically the scripts will be run on a post-layout netlist and then used to
generate an ECO for layout, it may be necessary to do the delay cell
insertion on a pre-layout netlist for the ECO, so they are preserved in
this file for future use.
As far as known bugs goes, I think there are problems if "TARGET_DESIGN" is
not set to the top level design (which is not an issue unless someone wants
to insert delays only on a submodule) but that's all I know of at the
moment. One thing to keep in mind, though, is that when inserting cells in
a post-layout, SDF-annotated netlist, new nodes are created for which SDF
annotation will not exist, and which will be timed using whatever other
timing parameters Design Time can find (typically wire loads). So as the
script repeatedly runs its analysis looking for hold time violations, it
may inaccurately assess the remaining hold-time violations as a result of
now-inaccurate timing due to missing SDF annotation. Worst case, of course,
this simply results in another ECO cycle, and of course this problem will be
fixed some time in 2073, when the EDA industry has finally succeeded in
interactively coupling layout with synthesis.
A note on the TCL code... I'm not a professional programmer ("Make Silicon,
Not Software"). So in the code there are probably numerous prime targets
for objection by those who are such. For instance, I didn't like the global
variables, but I couldn't find a way out of using them without making the
code even more complex by using TCL's "namespaces" and "uplevel" commands
and other byzantine constructs.
In any case, if anyone has any complaints (other than programming "style")
or suggestions or finds any bugs (or wants to throw money!!), email me at
"icnerd@ieee.org".
Credit and appreciation is due Dave Unterseher and Anil Moolchandani of
Synopsys, who both contributed solutions to extracting data from DC when
it wasn't at all obvious how to get at it...
- David Simmons
Toshiba
[ Editor's Note: Dave's scripts are #35 on the DeepChip Downloads - John ]
( ESNUG 404 Item 6 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 400 #7 ) Why DC 2002.05 Differs On HPUX vs. Linux/Solaris
> Our team is trying to close on timing analysis (using PrimeTime) with our
> ASIC vendor on our post-route netlist. We are using PrimeTime
> 2001.08-SP1. Our vendor is running Linux and Solaris and gettings the
> same results on either platform. Here running on HPUX we get different
> violators from the vendor using the same constraints and scripts. We
> also checked the violators using the following commands:
>
> 1. report_analysis_coverage ......
> 2. report_timing -delay_type min ......
> 3. report_constraints -all_violators -verbose ....
>
> All commands show that we have 34 hold violations and they are all the
> same. But our ASIC vendor running the same scripts reports zero hold
> time violations running under Linux and Solaris. Does anyone know of
> any reason why there would be discreprencies across platforms?
>
> - Craig Taniguchi
> TRW
From: Pierre Ragon <bullbullbull pprraaggoonn from lucent cot balm>
Hi, John,
I had a similar experience using Design Compiler 2002.05 on a Sun-Solaris
workstation. What is even more puzzling is that running on same OS and
workstation the same optimization of the same design gave different results.
I start noticing it when we ran optimization of quite large partitions (20
to 25 k flops) of the design. Then the final area would differ. A test
case for this has been submitted .
When I enquired for the cause of that behavior I was first answered that it
was due to the synopsys cache. During the optimization DC stores
information about the DW modules that it compiles to optimize the design.
In subsequent runs it reuses these results that have been stored in the
cache saving the compilation time needed to generate the DW technology
specific view. These slightly different processes may supposedly cause the
differences. Still I was not pleased with that explanation because I
believe that in any case identical optimization should give identical
results. I kept on experimenting starting with an empty cache. The area
results were again different. I submitted the test case at the local
support and they could not reproduce the problem at the beginning. I
finally found a configuration where I first optimized targeting the slow
asic lib, followed by the same optimization targeting the fast asic lib,
followed by the same optimization targeting the slow asic lib. This
sequence appears to always lend to different area results for the 2
optimizations targeting slow lib. This has been recognized as an issue
and will be fixed in a coming release of DC.
I havent got any explanation regarding the actual cause, but I can think
of some possibilities:
- unitialized variables
- read outside data structures boundaries
Other possible causes that did not apply to my specific case:
- multi-threading execution
- program that rely on seed value to initialize some algorithm
Hope this helps your readers.
- Pierre Ragon
Lucent
[ Editor's Note: Pierre what you describe here is what I called the
white space bug waaaaay back in ESNUG 135 #1. Basically it boils down
to the fact that DC relies on OS specfic seeds for its algorthms;
which means each OS can give you slightly different results. - John ]
( ESNUG 404 Item 7 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 396 #3 ) Rectilinear Blocks In PhysOpt/Apollo/Astro Flows?
> For our upcoming hierarchical design chip, I see that our blocks will be
> well utilized based on the connectivity and functionality -- if our blocks
> are allowed to be rectilinear (non rectangular) in shape -- rather than
> the conventional rectangular shapes. Even though the EDA tools out there
> claim that they can handle rectilinear shapes, I am very positive that I
> will run into a lot of implementation and integration issues in doing so.
> So I am wondering if your readers have experience in handling rectilinear
> blocks, especially with Synopsys (PhysOpt)/ Avanti (Jupiter/Apollo) tools.
>
> Some stuff that I am curious about are
>
> 1. How difficult is it in getting the pins assigned when the number of
> edges exceeds 4?
> 2. Is power routing capable of dropping straps of different lengths
> because of different dimensions in one direction or do I have to
> manually alter the lengths?
> 3. Will writing out the GDSII have any problems?
> 4. Can the parasitic extractor handle arbitrary shaped blocks?
>
> Plus is there anything else that would make my life miserable here?
>
> - Jay Pragasam
> Brecis Communications San Jose, CA
From: Raghav Yerramreddikalva <raghav.yerramreddikalva in intel pot pomme>
Hi John,
I read the ESNUG 395 #6 question regarding "How to deal with Rectilinear
Block Designs in PhysOpt/Jupiter/Apollo Flows", and the corresponding
feedback. The corresponding feedback in ESNUG 396 #3 was not directly
dealing with the PhysOpt/Jupiter/Apollo tools. I was wondering if you
were aware of any fully user-debugged rectilinear block flows using
PhysOpt, Jupiter, Apollo and/or Astro tools? If so, can you please let
me know?
- Raghav Yerramreddikalva
Intel
( ESNUG 404 Item 8 ) --------------------------------------------- [01/08/03]
From: [ Kenny, from South Park ]
Subject: Synopsys Officially Kills Off Chrysalis In Favor Of Formality
Hi, John,
Synopsys is putting the nail in the coffin of Chrysalis.
From: Dave Guinther <david.guinther atatat synopsys|sysponys hot mom>
Subject: Synopsys Design VERIFYer -inFORMAL Update- November, 2002
To: xxx@xxxxxx.xxx
Hi [Name Deleted]-
This email contains important information regarding your Design
VERIFYer licenses. Please read this now.
READ THIS SUMMARY - IT'S IMPORTANT
------------------------------------
In July we told you we'd have our roadmaps in place regarding our plans
for Design VERIFYer and Formality. Since then we've visited many
sites, talked with even more, and sent official 'snail mail' to our
customers announcing our decision to continue support for Design
VERIFYer while we focus our R&D efforts on Formality.
The purpose of this email is to make sure each of our users has been
contacted and is fully aware of our roadmap and migration plans.
The Synopsys 'DV2FM' Migration Program includes:
* Continued Design VERIFYer support for 18 months
* No-Charge Upgrades to Formality from Design VERIFYer
* Shared Licenses to enable you to use BOTH Design VERIFYer
and Formality during the migration period.
Many of you have already received 'shared licenses' and are using
Formality. If this is the case at your site, thanks for your support
and feedback welcome. If not, read on to make sure you don't miss this
opportunity to request your shared licenses and upgrade to Formality at
no charge. There's no cost, no risk, and no commitment if you order
by March, '03.
Formality Technology Roadmap
------------------------------
The September release of Formality included 'shared licensing'
capabilities for our Design VERIFYer users. The December release is
the first of several that will add key Design VERIFYer capabilities to
Formality; it will also include hot new DataPath support for hard
verifications. In March, ?03, Formality users will be able to verify
SPICE- and transistor-based designs. If you?d like to hear more about
our roadmap let us know and we?ll arrange a briefing for your site.
Migration Program Details
--------------------------
Contact your account manager to make sure you obtain your Synopsys
'DV and Formality Shared Add-on' licenses. This is the first step in
the migration, and an important one to maintain the no-cost option for
upgrading to Formality. If, after trying out Formality, you decide to
continue to use Design VERIFYer (not likely once you try out the GUI-
based set-up and debug capabilities and get a chance to see how fast
Formality runs on RTL and gate-level designs :) you will have the
option to request 20-year 'off maintenance' keys for Design VERIFYer.
Getting the Shared License keys NOW preserves your ability to migrate
to Formality next year at no charge.
The Formal Landscape here at Synopsys
----------------------------------------------------
We're excited to have a larger-than-ever R&D team working exclusively
on formal verification. Our combined team, with development centers in
Oregon and Massachusetts, is focused on providing you with the best
possible solutions for verifying your chips quickly and efficiently.
This team is working to protect the investment you?ve made in Formality
and Design VERIFYer. Enhancing the performance, capacity, and 'time-
to-results' capabilities for a wide range of those verification
problems in the RTL, gate and transistor space where you're competing
is our Top Priority.
These are challenging times economically, and we're pleased to provide
a DV2FM Migration Plan using a Zero-Cost, Zero-Risk approach that
provides you with the best equivalence checking solution on the market
today. Synopsys III has much to offer customers in terms of stability,
worldwide support, and technical excellence - thanks again for your
support and for being our customer.
Dave G
PS - AS always, any questions, comments suggestions welcome. Call or
email any time:)
Dave Guinther,
Formality Technical Marketing Manager
Synopsys, Inc.
508.263.8248
Glad I never purchased Chrysalis, but somehow I'm on the user list anyway.
- [ Kenny, from South Park ]
( ESNUG 404 Item 9 ) --------------------------------------------- [01/08/03]
From: Russell Mohn <rrmmoohhnn close to sarnoff mott dawn naynaynay>
Subject: Questions on Mentor Mach TA vs. Synopsys Nanosim vs. Nassda HSIM
Hi, John,
With a trial license of Nanosim, I saw great improvements in simulation
of a 12-bit DAC relative to Mentor's Accusim (Eldo engine). The
simulation was a ramp, from 0 to 2^12 - 1. Nanosim had a useful counter
function which made setting up this particular stimulus doable with 1
line of code. I'm still not sure how to implement a digitized sinusoid
in SPICE format, but that's a tangential problem. The ramp simulation,
which is useful for INL/DNL analysis, took 17 days (408 hours) in
Accusim and 4.5 hours with Nanosim. This seems too good to be true.
The simulator's waveforms passed my visual inspection of accuracy.
Nanosim's waveform viewer, TurboWave, didn't thrill me. Zooming caused
some of the waves to become distorted. And zooming also takes place
either along the x-axis or along the y-axis, which is annoying because I
expect a zoom box which zooms in both dimensions simultaneously.
I didn't like Nanosim's documentation. The blank pages were
unprofessional. Seemed like no one bothered to check the PDF after it
was converted from MS word. The typos in some of Nanosim's error
messages were also unprofessional. Mentor's documentation has grown on
me over the past year - I had my doubts as I learned AMPLE (a function's
possible return values are useful information overlooked in some of
Mentor's documentation), until I looked at Cadence's OpenBook
superficial confusion. I wrote a perl script that converted an Assura
results database to an ICRules results database, and I'm still not
exactly sure what a Cadence "environment" is. So I believe Mach's
documentation will be good.
I've heard generic positive comments about Nassda's HSIM, but I've also
heard that it is more costly than the other products.
On the input side of the simulation process, which simulator works best
with which schematic capture/netlister?
I'm concerned about which tool has the highest product of accuracy
and speed. Are all of them apropos for mixed-signal circuits and SOCs?
What kind of silicon successes are out there as a result of these tools?
I am trying to decide which is the superior fast SPICE simulator of
Mentor's Mach, Synopsys's Nanosim, and Nassda's HSIM. The tool will be
used for large mixed-signal blocks, such as data converters, and even
larger SOCs. What are other people using?
- Russell Mohn
Sarnoff Corporation
( ESNUG 404 Item 10 ) -------------------------------------------- [01/08/03]
Subject: ( ESNUG 403 #11 ) Do NOT Run Contending Patterns On Your Tester!
> I need to do floating node analysis. For that I need iddq/stuck-at
> patterns which should include as much contention/floating conditions
> as possible. Is there some way to force TetraMAX ATPG to generate such
> patterns so that they have contetion/float conditions? I can change the
> severity level of contention checking in TetraMax, but I am doubtful.
> This might just switch off the messaging of contention conditions and
> it'll neglect to actually generate contention patterns. Can somebody
> clear this doubt of mine?
>
> - Vijay Bhargava
> Motorola India Gurgaon, India
From: Ankur Gupta <ankur.gupta|atpug.ruka inside synopsys lot palm neyney>
Hi John,
I am an Applications Engineer with Synopsys. This is in response to the
contention check query (ESNUG 403 #11). It's true that TetraMAX by default
will not generate patterns which may lead to contentions on the chip.
It is not at all a good idea to let contending patterns run on the tester.
We discourage this practice. If you want to turn off or customise the
various contention checks during ATPG you can do that using set contention
command. Please refer to the online help to know about the various options.
Floating conditions are still fine and are supported by the default behavior
of TetraMAX. Also with -no atpg option you can generate random patterns.
- Ankur Gupta
Synopsys
( ESNUG 404 Item 11 ) -------------------------------------------- [01/08/03]
From: Gregg Lahti <gregg.lahti dogdogdog by corrent|tnerroc got fawn>
Subject: Gregg's PhysOpt, Astro, PrimeTime, VCS, Tcl, BSD, Virsim Wish List
Hi, John,
My daughters have been busy updating a Santa wish list since they consumed
the last slice of pumpkin pie on Thanksgiving day. Every day my 3-year-old
points to a TV toy commercial and says "Daddy, I want THAT for Christmas".
I told her that I'll write down everything she likes and then she can pick
out a few items from the list to ask the Mall Santa for Christmas. I then
realized that I could use a Synopsys EDA wish list as well. So I've made
up my own "Christmas wish list" that I hope to get from the Synopsys Santa
this upcoming year. Here goes:
1) Keep the variable names consistent between all products. I stumbled
on the differences of the $arch variable in DC and PT which caused me
pain in a legacy script.
2) Eliminate or improve the "get_object_name()" usage. Why return a file
handle when searching through a collection when the user will
ultimately need to convert it into a human-readable object name? It
would be great if DC/PT returned the name of the item and had the
option to use the & prefix if the filehandle was needed. Or maybe
just simplify get_object_name() to a * prefix character like C.
Something reasonable in Tcl terms without having to litter my code
with seemingly redundant Tcl calls.
3) Improve the linkage between BSD Compiler, PhysOpt and Astro so it can
place & route boundary scan cells near the pads and know to route the
chain in a "backwards" fashion for fast timing.
4) Allow multiple TAP controllers in BSD Compiler. This would be really
beneficial to engineers embedding IP that come with its own TAP
controller.
5) Allow VCS to read compressed SDF files.
6) A Datapath Compiler-like feature in PhysOpt that can handle large
width buses for RTL-to-placed-gates methodolgy. Gates-to-placed-
gates methodology did a much better job in placement and final
route timing in our datapath.
7) PhysOpt is good, but it would be great if the buffering removal
capabilities in PhysOpt were better. We realized a 10-15% timing
and area savings when going from gates-to-placed-gates if we
compiled with 0 wireload and fast timing, as PhysOpt just added more
buffering to the already buffered paths instead of ripping or
upsizing.
8) A replacement for Virsim.
9) An ECO Compiler with PhysOpt/Astro compatibility.
10) Verilog 2000 and System Verilog support in VCS and DC/PhysOpt. This
includes multi-dimensional arrays, generates, and the ability to put
* instead of a sensitivity list in an always block statement.
My daughters will sit on the Mall Santa's lap to tell him their wish list
and get their picture taken. I'd rather email my list instead.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 404 Item 12 ) -------------------------------------------- [01/08/03]
From: <sshheerrvviinn.hhoojjaatt around sun brought mom yodelyodel>
Subject: A User Mix/Max Delay Extract_Model PrimeTime Methodology Question
Hi John,
I have a PrimeTime question that I hope you can help me with.
In "extract_model" is there a way to generate model for min or max delay and
not both in the same file?
- Shervin Hojat
Sun Microsystems
( ESNUG 404 Item 13 ) -------------------------------------------- [01/08/03]
Subject: ( ESNUG 371 #5 ) DC & Synchronizers With Inputs Tied To Zero
> I have a design in which there are some instances of synchronizers whose
> inputs will be tied to zero depending on the requirement. The problem is
> that Design Compiler does not remove such instances. It keeps the
> instance with the input tied and the output not defined at all in the
> gate level netlist. All this is fine for gate level simulation, etc.,
> but the problem occurs when I try to insert scan in the design. DFT
> Compiler sees a sequential cell with inputs defined and no outputs and
> issues a Warning as this cell cannot be included in the scan chain.
>
> Is there anyway to optimize away the unused instances, using some Synopsys
> variable? I know only of two solutions:
>
> 1. ungroup -- but I do not want to run ungroup on the design.
> 2. grep manually for such unused cells and remove it. Ugly.
>
> Any other solution is welcome.
>
> - Rajkumar Kadam
> Quantum Corp.
From: Priya Natarajan <priyadft/priyadft of yahoo/yahoo goatgoat dot aplomb>
Hi John,
I am Priya, a DFT Applications Engineer, recently laid off from Texas
Instruments. One solution for Rajkumar would be the following:
Assumptions: One net say, sync_tie0_net is connected to the LOW pin of the
tieoff cell and to the input pin of all the synchronizer instances.
Importantly, sync_tie0_net is not connected to anything else.
Solution: In Synopsys dc_shell, get a list of all the pins connected to
sync_tie0_net and disconnect the net from the list as shown below:
current_design <********>
temp_list = ""
remove_variable temp_list
temp_list = all_connected (find (net, sync_tie0_net))
disconnect_net find(net, sync_tie0_net) temp_list
remove_net find(net, sync_tie0_net)
remove_variable temp_list
Since in Rajkumar's case, the synchronizers do not have anything else
connected to them, they will be unused. Synopsys does not write out unused
cells in the verilog netlist. As for the tieoff cell, it will not have
anything connected to the LOW pin. If its HIGH pin is connected to
anything, those connections will be retained, and the tieoff cell will
still remain in the netlist. If the HIGH pin is unused, then the tieoff
cell will also be absent in your output netlist.
Hope this helps.
- Padmapriya Natarajan
ex-TI and looking
( ESNUG 404 Item 14 ) -------------------------------------------- [01/08/03]
From: Heidi Ehrenfeld <heidi|idieh from mmccbbrruu sought tom chirpchirp>
Subject: EDA Community Gives 450 Toys And 532 Pounds Of Food To The Needy
Hi, John,
Some arrived with food, some with toys, some with essentials like diapers,
clothing and baby formula. All were members of the EDA community and they
were gathered at South First Billiards in San Jose last Tuesday to celebrate
the holiday season and enjoy an evening of billiards and blues music with
their peers. But more importantly, they were present to reach out to those
hardest hit by the difficult economic climate. 532 pounds of food were
collected and donated to the Second Harvest Food Bank, along with $72 from
cash collection cans, and approximately 450 toys, clothing items, and other
necessities were given to the Sacred Heart Community Service organization.
Both organizations work year round to support and service local Bay Area
communities.
Aside from toys and food, corporate and individual sponsors donated amounts
ranging from $250 to $1,000 apiece to cover party costs. A surplus
from those donations of $1,000 will be split equally between the Second
Harvest Food Bank and the Sacred Heart Community Service organization. In
addition, a special auction was held in which a case of Della Mare
Chardonnay, donated by Artisan Components' Jim Hogan, raised $650 for the
Second Harvest Food Bank.
"The party itself was really fun, but when we realized who the charities
were supporting, we decided to focus on making a difference in the lives of
kids and families who need a little extra help right now," said Lori Kate
Calise, senior marketing manager at Axis Systems, Inc. Axis' sixty
Sunnyvale-based employees contributed three barrels of food and toys during
the week prior to the party. "The idea for the party sprung from wanting
to celebrate the EDA industry's resilience in difficult economic times and
demonstrate our solidarity," said Gary Smith, Gartner's senior EDA industry
analyst and party co-chair. "As it evolved into a charitable event, it was
fun to watch companies that are arch rivals come together to ensure the
charities selected would receive meaningful contributions."
The crowd, numbering 250, enjoyed music provided by blues band Shine-Ola,
most of whose members work in the EDA industry.
- Heidi Ehrenfeld
McClenahan-Bruer Communications Portland, OR
( ESNUG 404 Item 15 ) -------------------------------------------- [01/08/03]
From: John Gyurek <gyurekj/gyurekj atatat tttccceee pot calm frogfrog>
Subject: How Are The Tools/Techniques For Sync/Async Resets Down At 0.13 ??
Hi, John,
I would like to hear from anyone with experience in 0.13 um and below on
the reset synchronous vs. asynchronous issue. In the past this was purely
a religious debate but now with signal integrity issues, momentum toward
synchronous global resets is building. Several articles have been
published, but I have not heard from anyone with a horror story about
glitches causing unwanted resets of flops. What about the output of the
signal integrity tools? Have glitches above threshold been reported? How
many? Bottom line: is this a manageable problem in today's tools or
something one should just avoid altogether? Does anyone recommend
re-writing legacy code?
- John Gyurek
Thomson Consumer Electronics Indianapolis, IN
( ESNUG 404 Item 16 ) -------------------------------------------- [01/08/03]
From: Tim Lantz <goldfishgoldfish tim of taunetworks wrought calm>
Subject: Our DC, Monterey, Calibre, Simplex, PrimeTime, Formality Tapeouts
Hi, John,
A little over a year ago, we had the opportunity to implement a backend flow
from scratch at Tau Networks. Here's our Monterey experience.
Our switch fabric chip set consists of two chips implemented in a 0.15u
technology. The larger one contains more than 3M placeable objects, and the
smaller one more than 1M placeable objects plus RAM. Both chips have high
speed 3.125 GBd serdes I/O designed as full custom blocks with some fancy
P&R work around them and then placed as macros. The smaller chip also has
another custom block: a 20 Gbps implementation of the Network Processing
Forum Streaming Interface.
Our trial runs of Dolphin made us believe we could tapeout using Monterey's
tool set. Their algorithms and approach made sense. Their solution was
"gates-in to GDS out": floorplanning, physical prototyping, timing aware
logical optimizations and placement, timing aware routing and antenna
fixing. Our P&R flow is strictly Monterey. We don't have any other P&R
tools.
Our Basic Design Flow
---------------------
a) Synopsys Design Compiler
b) Floorplanning with Monterey ICWizard
c) Quick estimates with Monterey Sonar
d) Detailed P&R with Monterey Dolphin
e) Magic (enhanced) layout editor for custom/flip chip cover cell.
f) Mentor Calibre LVS/DRC/Antenna
g) Simplex Extraction and Power Analysis
h) Synopsys PrimeTime
i) Synopsys Formality
Floorplanning with ICWizard
----------------------------
ICWizard was used to floorplan our two multimillion gate hierarchical
chips. ICW's command language (python) is cumbersome and syntax
intensive. This made the initial flow development difficult and time
consuming. However, once the flow was scripted and driven by a
makefile, it easily worked with RTL, black boxes, size estimates, and
gate level netlist. ICWizard is a very powerful chip planner that
allowed us to quickly change block sizes, pin placements, and to
estimate global routes.
ICWizard cannot insert power with correct design rule constraints;
therefore, power insertion required two passes. ICWizard's power
insertion is used for pin placement obstructions and better global
route congestion analysis. The power structure is then duplicated
in Dolphin, which creates the final design rule correct power mesh.
Monterey tells us this has been fixed/improved in current releases.
Two pin placement algorithms for placing pins on macros exist in
ICWizard. The first algorithm is a quick pin placement based on
all top level connectivity for the level that you are working at.
The second pin placement algorithm uses global route. This second
algorithm works well, except that it takes time to correctly specify
blockages inside of mega cells if they all are not blocked to the
same metal level. The difficulty comes about from having mega
cells that have blockages at different levels, which we did.
Quick P&R results with Sonar
----------------------------
Sonar is very powerful because of its quick run time and good
correlation to Dolphin. In most cases the results of Sonar matched
Dolphin to within 5-10%. Sonar's quick run time helps to reduce
iterations due to incorrect inputs, poor floorplanning, or bad
netlists. The placement and optimization algorithms do an amazing
job. We spent considerable time investigating the critical path cell
sizes and placement. 99% of the results were excellent, but a couple
of our designs encountered two problems in the placement algorithm.
The first problem in the placement algorithm is that it may
incorrectly place flops next to an output port when the input to the
flop fails timing and the output delay is met by many nanoseconds. We
were able to get around this by regioning the design. The regions are
used during initial placement and they are usually obeyed unless the
region creates extra congestion or poor timing in which case Dolphin
will optimize the placement of cells out of the requested region.
The second problem is that high fanout nets in the critical paths
are ignored if the fanout goes above a hard coded threshold. Before
Dolphin places the design, it removes all buffering, so the critical
path may have large fanouts. The logic before the high fanout net is
clustered, as is the logic after the high fanout net, but the clusters
are not necessarily placed near each other. In the current release,
v2.5, this is user controlled.
Detailed P&R results from Dolphin
----------------------------------
For large designs, Dolphin requires a large machine with lots of
memory: at our peak, we used 12 GB of RAM for our full chip. Monterey
is working on a port to Linux which should significantly decrease the
run time for smaller blocks. Also, they claim that the upcoming v2.5
has 30% faster run time than v2.1. Sonar is the early
quadrisectioning of Dolphin, and Dolphin builds off of the Sonar
results so no time is wasted by running Sonar. In general, Dolphin
takes more time than other P&R tools that we've used; however it
performs more optimizations, giving better end results. Many hand
fixes that we've had to do with past tools were not required with
Dolphin.
One of Dolphin's biggest strengths is its CTS engine, which allows the
user to balance separate trees and to utilize useful skew. It is
difficult to control latency, but the overall skew was consistently
low. We specified the clock insertion of every block when we put the
top level together and Dolphin did the right thing and balanced the
trees at the top level. Where we specified things correctly, the
resulting clock trees in all the block level and chip level designs
did not require any manual fixes.
The router is one of Dolphin's biggest strengths and biggest
weaknesses. It does a good job, but isn't very fast. For all of
Dolphin's parallelism, antenna avoidance and diode insertion are
performed independently at the end of the routing process, and since
you know the detailed route is already done, it seems excruciatingly
slow. Although the run time in v2.1 is relatively poor, the router
does produce LVS/DRC clean GDS. Many times, we went from Dolphin
straight through Calibre with LVS/DRC clean results. LVS text is also
difficult to insert and does not have any features that allow the user
to rename ports or to make power ports non-unique. We have seen
significant speed up in the router in our initial usage of v2.5.
PrimeTime, Simplex, & Dolphin Timing
------------------------------------
Unfortunately our DEF extracted Simplex SPEF file timing runs with
PrimeTime did not always correlate to Dolphin. They differed up to
5%. With help from Simplex and Monterey, we found that in comparison
to the standard, Quickcap, Simplex was pessimistic and Dolphin was
optimistic. Monterey found a couple of bugs that have been fixed in
v2.5 and Dolphin now correlates to QuickCap very well. Simplex has
also released a new version which isn't as pessimistic and we feel
comfortable that this issue is now resolved.
Dolphin is very good at the block level, but it is missing a few
features for an optimal hierarchical flow. The top level chip is
treated the same as block level designs, such that a .lib and LEF is
required for all mega cells. The LEF abstract generated by Dolphin
has to be modified due to extra pins and vias in the port definitions,
nothing that some perl can't handle. The .lib generation in Dolphin
is slow, so we used PrimeTime. The biggest problem at the top
integration level is that different types of buffering schemes are
required due to the area consumed by large mega cells, leaving small
"island" areas for buffer insertion. We had many transition
violations at the chip level that were hand fixed when it seems as if
they could have been automatically fixed; the fixes involved simple
upsizing or moving a buffer a millimeter to center it in a line.
We came to realize that it was important to let Synopsys DC choose the
correct architecture/implementation for the logic, but then rely on
Dolphin to do the actual technology mapping. Dolphin removes all
buffers and double inversions, and also does local logic synthesis
taking the placement and routing into consideration. It makes sense
to minimize time in the synthesis tool and let Dolphin choose the
ideal logic and buffering required in order to meet timing. Further
experimentation after tapeout found that we could reduce the area of
some blocks even further by not using any wireload models during
synthesis, just fanout rules and reduced cycle times to get the faster
architectures, and then letting Dolphin do the appropriate logic
mapping and sizing. The savings were on the order of 10% for a one
million gate block.
Formality & The ECO Flow
------------------------
We always used Formality to verify both RTL-to-gates and gates-to-gates
at the block level. We never found an error made by Dolphin.
The biggest problem with the ECO flow is incremental place on a global
or detailed routed netlist takes a very long time and the results were
less than optimal. The high level overview of our ECO flow is:
a) dump out a Verilog netlist
b) edit the netlist with the ECO changes (use formal verification
against your RTL as appropriate)
c) run Dolphin's eco_netlist command to compare the ECO netlist to the
current Dolphin database and recognize the changes
d) have Dolphin dump out a DEF placement file
e) start a fresh Dolphin database using the ECO netlist and the dumped
DEF file (you now have a placement except for the ECO cells/changes)
f) Now run incremental place to place your new ECO cells.
g) Then continue on with optimizations, global route, and detail route
to finish up.
We used area array I/Os, I/Os sprinkled through out the die in optimal
locations, and routed them with the upper layer of metal to the flip
chip bump locations. Dolphin does not support this type of I/O
distribution and the routing from the I/O to the bump location so
we manually drew a "cover cell" in magic that had our top metal
redistribution layer (RDL) route from the I/O locations to the bump
locations and additional power and ground strapping. This cover cell
was merged with the rest of the chip at final chip assembly and the
entire merged chip ran through LVS/DRC. Our package has built in
power planes and by using the RDL and flip chip we were able to drop
down power and grounds straight into the middle of the die as needed.
This provided us a robust power grid.
Custom blocks were drawn with Magic, .lib and LEF files created, and
treated as macro blocks in the P&R world. The P&R needs were always
considered when implementing physical characteristics of the custom
blocks, i.e. pin placement, aspect ratio, routing obstructions, etc.
Due to the complexity of our design, i.e. the hierarchy, the large
size of the design, the use of area array I/O, we definitely filed
our fair share of bugs and enhancement requests. We had great support
from Monterey's technical team and they would roll our required fixes
into development builds and share them with us as needed. We realized
the risks we were taking with development builds, but we never hit
any problems. One of the keys to our success was Monterey's support
model, which involved not only an applications engineer as our
official conduit into Monterey, but also an R&D engineer who was our
champion in the R&D world, he would watch out for us in R&D meetings
and if we hit something really nasty. Of course, this also benefits
Monterey by giving their R&D team immediate access to customers.
Most of our routine bugs were fixed in v2.1, with which we taped out.
Our designs and hierarchical needs uncovered some methodology issues
that are being addressed in future releases: issues relating to
flip-chip support and better top level buffering.
Overall
-------
Monterey provided us a set of tools, instructions, and good support.
We ran the tools ourselves, and while we needed bug and enhancement fixes,
we didn't rely on any taxicab mode operations -- all P&R was done by Tau
employees in house. TCL and Perl skills are definitely required.
We were able to tapeout two complex chips in relatively short order with a
small team on a deterministic schedule -- I don't think we could have
achieved as much as we did with any other physical synthesis tool.
Both chips are back and working.
- Tim Lantz
Physical Design Lead
Tau Networks Scotts Valley, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 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
|
|
