From: "Daniel DeSantis, P.I." <DDeSantis4442@aol.com>
Dear John,
I am a licensed private investigator in San Jose, CA working on behalf
of SVR in their lawsuit against Avanti. Do any of your ESNUG readers
know of the physical whereabouts of Gerald Cheinkuo Hsu (aka "Gerry
Hsu")? I must serve him with legal documents pending this civil matter
in the US District Court, Northern District of California. This is not
a joke. My California state PI number is 22551. If any ESNUG reader
has information in regards to Mr. Hsu's whereabouts, please call my
office at (408) 295-4442.
- Daniel DeSantis
DeSantis & Assoc. San Jose, CA
Editor's Note: I called the California Bureau of Security. DeSantis
checks out as a private investigator. This is not a joke. - John
( ESNUG 385 Subjects ) ------------------------------------------- [12/19/01]
Item 1: DC Creates Incorrect Logic With Verilog Signed/Unsigned Arithmetic
Item 2: ( ESNUG 384 ) Aart Replies To The 100 Avanti Merger User Letters
Item 3: Tips For Getting High Speed Sim With Cadence NC-Verilog & NC-Sim
Item 4: How Do I Use Calibre And Star-RC For Transistor-Level Extractions?
Item 5: PhysOpt set_ideal_net & "set_auto_ideal_net -scan true" Has Changed
Item 6: Do Anyone Have An RTL-Level Hierarchy Tracing Tool/Methodology?
Item 7: ( ESNUG 382 #7 ) Maybe Arcadia Can't, But Hercules/Star-RCXT Can !
Item 8: ( ESNUG 383 #2 ) We Can't Duplicate The Alleged PhysOpt "Case" Bug
Item 9: ( ESNUG 383 #16 ) ModelSim 5.5c Didn't Scale With Linux Mhz Either
Item 10: ( ESNUG 383 #1 ) I'd Like To Hear More About Ambit-RTL's Bad Logic
Item 11: ( ESNUG 382 #9 ) PhysOpt/DFT Spends A *Long* Time Fixing DRC's
Item 12: I'm Seeing Conflicting User Comments On Synopsys Route66 Here ...
Item 13: Help! These Mixed Voltage Libs Are A DC/Apollo/PrimeTime Nightmare!
Item 14: ( ESNUG 383 #9 ) How To Use The Absolute Minimum PLI With VCS 6.0
Item 15: How Do I Best Fill The Holes In A Cadence PKS/BuildGates/SE Flow?
Item 16: ( ESNUG 383 #17 ) More Setup/Hold Library Characterization Gotchas
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 385 Item 1 ) --------------------------------------------- [12/19/01]
From: Jenny Yee <jyee@synopsys.com>
Subject: DC Creates Incorrect Logic With Verilog Signed/Unsigned Arithmetic
Hi, John,
Design Compiler 2001.08 might generate incorrect logic (STAR-131010) when
all of the following conditions are true:
* Verilog code uses signed and unsigned arithmetic (Verilog 2001)
* Different bit-widths are used
* Tree-height minimization is invoked by Design Compiler
The following design will be incorrectly compiled if tree-height minimization
is invoked:
module bad (a, b, c, z);
input [4:0] a, b;
input signed [4:0] c;
output [6:0] z;
wire signed [5:0] tmp_1;
assign tmp_1 = a + b; // unsigned
assign z = tmp_1 + c; // signed
endmodule
You can work around this problem by using the following two methods.
1. Disable tree-height minimization by:
hlo_minimize_tree_delay = false
Tree-height minimization is invoked based on optimization requirements.
In the above example, it will be used if input "a" arrives late.
2. Modify your Verilog code. Here's an appropriate modification:
module ok (a, b, c, z);
input [4:0] a, b;
input signed [4:0] c;
output [6:0] z;
wire signed [6:0] tmp_1, tmp_c;
// unsigned operation -> convert to signed
assign tmp_1 = {2'b00, a} - {2'b00, b};
assign tmp_c = {c[4],c[4],c}; // extend sign
assign z = tmp_1 + tmp_c; // signed
endmodule
A software fix will be available in January 2002 and will be available to
all users in the general Synopsys' 2001.08-SP2 Service Pack release.
Again, if you are not using the Verilog 2001 signed/unsigned features, this
won't be an issue for you.
- Jenny Yee
Synopsys, Inc. Mountain View, CA
( ESNUG 385 Item 2 ) --------------------------------------------- [12/19/01]
From: [ Aart de Geus, Chairman & CEO of Synopsys ]
Subject: ( ESNUG 384 ) Aart Replies To The 100 Avanti Merger User Letters
Hi, John,
Although often tempted, I've never written to ESNUG, believing that it should
truly be a user forum, free of what you would call "executroid, marketing
droid, and Wall Street distractions." I plan to stick to this discipline,
with only today's exception, which I am making after reading the 100 or so
letters in ESNUG 384 about the pending Avanti merger.
Let me try to address some of the issues your readers raised. In general,
their questions fell into four categories:
First, "Is the merger good for the customer?" (ESNUG 384 #6, #8, #14)
We have found that customers want three things:
a.) Best flow: For many of you, the merger of Synopsys and Avanti occurred
in your design flow a long time ago. A rapid integration of our
front-end tools with the Avanti back end will immediately improve
this flow. (ESNUG 384 #14)
b.) Interoperability: There were a number of references to interoperability
issues in ESNUG 384 #6. Many of you use a Synopsys-Cadence flow and
have also produced impressive results. Whatever your choice of tools,
we will actively continue to support flows with competitors via
standard interfaces. We have always believed that providing strong
open interfaces is a must. (Note that we have been open with several
interfaces, including .lib, SystemC, SDC, and OpenVera.)
c.) Competition: No one wants any supplier to become too powerful. As of
today, there is one strong complete supplier of front-to-back
solutions and two smaller suppliers. When Synopsys and Avanti merge,
there will be two strong suppliers. Competition from both large and
small companies brings out the best in everyone: best design flows,
best support, best solutions, best pricing, and best ROI for customers.
(ESNUG 384 #8)
Second, "What about the legal stuff?" (ESNUG 384 #3 & #17)
Let me be very clear: We don't condone what happened in the past. But it's
important to remember that a huge price has already been paid. Some
individuals responsible are serving jail time. Avanti made a very large
restitution payment upon closure of the criminal case and has suffered for
years under a cloud of doubt and mistrust. This is especially unfortunate
in light of the outstanding new technology that their engineers have
produced over the years.
"What about Gerry Hsu?" some readers asked in ESNUG 384 #3. Neither he nor
any of the Avanti board members will be part of Synopsys going forward. None
of Avanti's severance and non-compete agreements were entered into as part of
the merger agreement; instead, all were pre-existing contractual obligations
between Avanti and the people in question.
Synopsys' focus is entirely on the future: Retain the best Avanti has to
offer and build a company that serves its customers well.
We believe that our acquisition of Avanti should remove any remaining doubts
that users have about the ethical integrity of today's Avanti products. We
have done our homework, and we are convinced that the products we will
acquire are clean. And going forward, we will run the merged business with
the same ethical standards under which Synopsys has always operated.
Third, "What about a potential culture clash?" (ESNUG 384 #7 & #13)
I have found that people have often made the mistake of attributing to all
of Avanti's employees the worst things that they have heard or believed
about some of their management. In my opinion, this is a mistake.
During our negotiations and since the announcement, I have met many Avanti
employees and have spent time with a number of their technical stars. If
there is one piece of DNA that is identical between Synopsys and Avanti, it
is their strong commitment to technology leadership. There is no question in
my mind that we both see a future in which product, people, and management
decisions are largely determined by the question: "How can we drive the state
of the art forward faster, now that we are together?"
Fourth, "What about the roadmap going forward?"
In the first two weeks since the acquisition announcement, many of you have
already asked us for our new roadmap, and I saw lots of questions along this
line throughout ESNUG 384. Please be patient; we will communicate much more
as soon as the merger closes. But rest assured that customers will not have
to worry about in-progress design projects. We will support those through
to completion with existing products. Going forward, we will choose the
best product features ("best" according to customers), whatever their
origin, for future releases.
Our desire to meet your technology and support needs has a long history,
which leads me to my next subject:
Synopsys' 15th Anniversary
--------------------------
This week, on December 18, Synopsys celebrates its 15th anniversary.
There is only one word that really matters on this subject: THANKS!
Thanks to our customers for having bet their chips (literally!) on Synopsys
when we were a small company with brand-new, unproven technology. Thanks
for sticking with us year after year as we introduced new products and
evolved old ones because you (sometimes relentlessly) pushed us to do better
in product features, runtime, quality of results, capacity, and support.
But above all, thanks to all of you who stuck with us when we did not always
live up to your expectations. We will never stop trying, because you're the
only judge that counts in assessing our performance.
Thanks also for the occasional user thank-you letter (they always make my
day!), describing your success on some really sophisticated design. I am
truly amazed at the complexity and sheer engineering ingenuity that goes
into our users' products, and then I realize: "Did they really do this with
our software? Wow!" Thanks.
For 15 years, we have had the privilege of being part of your chip designs.
We used to be proud of your 1,000-gate synthesis runs; now they're
million-gate runs. Simulation has sped up 110X over this timeframe, too.
With your continued input, prodding, and support, together we intend to give
Moore's law many more turns of the crank.
Thank you.
- Aart de Geus, Chairman & CEO
Synopsys, Inc. Mountain View, CA
( ESNUG 385 Item 3 ) --------------------------------------------- [12/19/01]
From: "Kathleen Meade" <meade@cadence.com>
Subject: Tips For Getting High Speed Sim With Cadence NC-Verilog & NC-Sim
Hello John,
I'm sending this to give your NC-Verilog and NC-Sim readers a summary of
command-line options and how they affect simulator performance. It may give
them some hints as to how to maximize NC-Sim's performance for their designs
and testbenches. I will show the syntax of command line options as they
apply to the single-step invocation mode (ncverilog +<options>) and indicate
the alternate ncvlog/ncelab/ncsim options in parenthesis.
My first tip is this: Please try to use the latest release of Cadence LDV
software that is available. Ever since NC-Verilog was first released (in
1996) our R&D team has focused on simulator performance as a highest
priority requirement. In every release they continue to add enhancements
that optimize the simulator for specific design styles, so always try to use
the latest. As of this date (12/07/2001), the latest release is LDV3.3(s10).
My second tip is similar: Use the profiler built into the NC products. The
profiler generates a log file listing which modules, lines of code and
construct types are taking the most time in the simulator.
+ncprofile (ncsim -profile)
By default, if timing exists in your design, NC-Sim will run with full
timing, sdf annotation and timing checks. There are options available to
reduce the timing capability, speed up performance and reduce the design
size. A quick command line string to use for max performance when you're
not concerned with timing is:
+delay_mode_distributed +notimingcheck +noneg_tchk
Here are some other global timing options:
+no_notifier (ncelab -nonotifier) :disables notifier register
+notimingcheck (ncelab -notimingchecks) :disables timing checks
+delay_mode_unit (ncelab -delay_mode unit) :delay 1 sim time unit
+delay_mode_zero (ncelab -delay_mode zero) :zero delay
+delay_mode_distributed (ncelab -delay_mode distributed)
:ignores specify block delays
We have also recently (LDV3.3) added the capability of applying timing
options to specific modules in the design using a timing control file. You
can enable/disable timingchecks, iopath delays, port delays, primitive
delays and full timing on a module by module basis. The syntax of the
control file is described in cdsdoc.
+nctfile <timing_ctrl_file> (ncelab -tfile <timing_ctrl_file>)
SDF precision can also be controlled. Previous to the LDV3.1 release the
default SDF precision was truncated to 10ps. As of LDV 3.1, all timing
values (including those less than 10ps) are used. This results in more
accurate results but slower simulation. (In most cases, 10 ps is
sufficient).
+ncelabargs+"-sdf_precision 10ps" (ncelab -sdf_precision [10ps|1ps|100fs])
Special Note on Negative Timing Checks: In the LDV3.3 release (July 2001)
we changed the default behavior of the simulator on negative timing checks.
The new behavior is if a negative timing check exists, it WILL be used.
+neg_tchk (ncelab -neg_tchk) : still exists for backward compatibility
+noneg_tchk (ncelab -noneg_tchk) : to set negative timing checks to zero
Previous to the LDV3.3 release, you must specify +neg_tchk
(ncelab -neg_tchk) on the command line for negative timing checks to be
applied.
Now for some switches that might slow down performance but are useful for
debug. By default, the NC products run in a fast mode with minimal
debugging capability. To access signals, modules and lines of code during
simulation, debug options can be applied using the access and linedebug
options.
+access+[rwc] (ncelab -access r|w|c)
r : read capability for waveform dumping
w : write for modifying values through PLI or TCL
c : connectivity for querying drivers and loads in C or TCL
+afile <access_file> (ncelab -afile <access_file>)
:to specify access options for specific modules in the design.
+linedebug (ncvlog -linedebug)
:to set breakpoints on lines of code during simulation
This causes more of a slowdown than the "access" options
I hope that this information proves useful to the ESNUG readers.
- Kathleen Meade
Cadence Design Systems Atlanta, GA
( ESNUG 385 Item 4 ) --------------------------------------------- [12/19/01]
From: "S. H. Park" <sh.park@api-networks.com>
Subject: How Do I Use Calibre And Star-RC For Transistor-Level Extractions?
John,
I need to generate a BACK-ANNOTATED RC extracted Spice netlist of a
transistor-level design from a GDSII and a Spice netlist using Mentor's
Calibre (for LVS) and Avanti's Star-RC. I would like to know if somebody
has a methodology or script that accomplished this with these two
different tools.
- S. H. Park
Api Networks
( ESNUG 385 Item 5 ) --------------------------------------------- [12/19/01]
From: Michael Krause <mkrause@synopsys.com>
Subject: PhysOpt set_ideal_net & "set_auto_ideal_net -scan true" Has Changed
Hi, John,
The PhysOpt behavior of "set_ideal_net" command has changed in the 2001.08
release (which affects flows using "insert_dft -physical".) An AC in Korea
ran into this issue, and I thought your readers might be interested in what
he found out.
Typically customers coming into PhysOpt with already scan-stitched netlists
use either "set_ideal_net" on the scan enable net or "set_auto_ideal_net
-scan true" prior to reordering their scan path. Customers who did this in
the 2000.11 base release (or its succeeding service packs) need to be aware
that in 2001.08, these commands result in the addition of a dont_touch
attribute that interferes with reordering.
For example, in 2000.11-SP2, "report_net" on the TEST_SE net would show
the following Attributes:
i - ideal
Net Fanout Fanin Load Resistance Pins Attributes
--------------------------------------------------------------------------
TEST_SE 380 1 6.49 0.00 381 i
--------------------------------------------------------------------------
Here is the same report run in the 2001.08 version. Notice the addition of
the dont_touch attribute:
Information: set_ideal_net disables DRC, sets dont_touch on the net and
makes its timing ideal. (UID-406)
Attributes:
d - dont_touch
i - ideal_net
Net Fanout Fanin Load Resistance Pins Attributes
--------------------------------------------------------------------------
TEST_SE 380 1 0.00 0.00 381 d, i
--------------------------------------------------------------------------
The dont_touch attribute interferes with reordering. When you attempt to run
"insert_dft -physical", you will see the following message:
Warning: Cannot use port 'TEST_SE' as a 'test_scan_enable'.
It's net has a dont_touch attribute. (TEST-358)
This causes DFT Compiler ("under the hood" of Physical Compiler) to add a new
scan enable port, test_se, but since this port has no placement information,
it causes further problems:
Error: Cannot inherit location from pad pin 'I_ALU/Zro_Flag_reg/SE' to
port 'test_se' because this cell I_ALU/Zro_Flag_reg is not a
real pad cell.
Please check the library.. (PSYN-117)
Error: Port test_se has no location. (PSYN-007)
Error: Command 'physopt' had an error while executing.
Discontinuing. (PSYN-003)
Error: physopt has abnormally terminated. (OPT-100)
The solution is to use "set_auto_disable_drc_nets -scan true" in 2001.08.
This command is new in 2001.08 and is used to disable DRC checking on nets
like clocks, scan signals, and constants. It replaces "set_auto_ideal_net".
With the new command, you will see the following "report_net" output:
Attributes:
dr - drc disabled
Net Fanout Fanin Load Resistance Pins Attributes
--------------------------------------------------------------------------
TEST_SE 380 1 6.49 0.00 381 dr
--------------------------------------------------------------------------
Now, you can apply "insert_dft -physical" and complete scan reordering.
- Mike Krause
Synopsys, Inc. Schaumburg, IL
( ESNUG 385 Item 6 ) --------------------------------------------- [12/19/01]
From: "Chet Juall" <juallc@dialogic.com>
Subject: Do Anyone Have An RTL-Level Hierarchy Tracing Tool/Methodology?
Hi, John,
I am looking for a tool or script which will trace a specified reg or wire
through the RTL hierarchy with possibly many name changes. When studying
an RTL design which was writtem by somebody else, it helps to make drawings
of one functional section of the design at a time. I find it very tedious
to track nets through the entire RTL design. This process is especially
difficult when there is a deep hierarchy with many name changes. Do you
know of a tool which could solve this problem?
- Chet Juall
Dialogic
( ESNUG 385 Item 7 ) --------------------------------------------- [12/19/01]
Subject: ( ESNUG 382 #7 ) Maybe Arcadia Can't, But Hercules/Star-RCXT Can !
> The fundamental problem Eyal has is that once his database has been
> converted to GDSII, all the LEF/DEF information has been lost. There
> is no way for any extractor to know what the gate level primitives are
> such that they could be reformed at the gate level and fed back to a
> gate level timing engine like PrimeTime.
>
> - Ken Maples
> Synopsys, Inc. Mountain View, CA
From: Krishna Sundaresan <krishna_kumar@avanticorp.com>
Hi, John,
The reason why Arcadia cannot do hierarchical extraction with GDSII, is
because the database is flattened by LVS tool possibly Dracula/Calibre.
It is WRONG to say no EXTRACTOR can do this.
Hercules and Star-RCXT supports both cell-level (hierarchical) and
transistor level extraction from GDSII. This flow is setup at multiple
customer sites and works.
The cell level netlist with cross referencing can be back-annotated to
PrimeTime or any STA tool.
- Krishnkumar Sundaresan
Avanti Corp.
( ESNUG 385 Item 8 ) --------------------------------------------- [12/19/01]
Subject: ( ESNUG 383 #2 ) We Can't Duplicate The Alleged PhysOpt "Case" Bug
> My design has signal names with UPPER and lower case. When I'm doing
> 'write_script' in PhysOpt, it writes all of the signals in lower case.
> Verilog doesn't like this. How can I fix PhysOpt so the names in the
> write_script will be liked in Verilog?
>
> - Ofer Paperni
> Motorola
From: "Mike Montana" <montana@synopsys.com>
Hi, John,
I saw Ofer's post to ESNUG and was a little perplexed. I have several
customer designs with a mixture of upper and lower case names and I find
that the write_script command in Physical Compiler outputs the net names
without any changes. Can he provide a little more detail about his
situation? Is Ofer running any change_names commands as part of his flow?
Perhaps with a few more details, I can help out.
- Mike Montana
Synopsys, Inc. Dallas, TX
( ESNUG 385 Item 9 ) --------------------------------------------- [12/19/01]
Subject: ( ESNUG 383 #16 ) ModelSim 5.5c Didn't Scale With Linux Mhz Either
> Has anyone seen that the ratio of performance improvement is not that much
> on NC-Verilog on Linux vs. Solaris? (i.e. faster Mhz didn't speed up
> NC-Verilog much.) I would like to see if others had similar experiences.
>
> - [ To Infinity And Beyond ]
From: Rainer Mueller <rainer@oasis.com>
Hi, John,
I'm wondering if anybody has used ModelSim on both the Solaris/Sparc and
Linux/x86 platforms, and can comment on the performance on each platform?
We use ModelSim version SE VHDL 5.5c.
We've been using Sun Ultra 5 workstations with ModelSim for several months
and recently began evaluating ModelSim on a 2 GHz Pentium 4. We expected
to see at least 3X performance improvement, but we're not seeing anything
close to that. Our Mentor apps engineer has been unwilling or unable to
provide us with benchmarks for their tool on various platforms, so I'm
hoping someone else has tried this and can share their experience.
Here are the systems we've tried:
A) Sun Ultra 5 workstation, with one Ultrasparc IIi CPU at 333 MHz with
2M cache, 512MB RAM. Solaris 8, ModelSim SE 5.5c.
B) Same as A, but with a 400 MHz CPU.
C) Dell Optiplex GX240, with one Pentium 4 CPU at 2 GHz with 1/4M cache.
512MB RAM (PC133). Redhat 7.1, ModelSim SE 5.5e.
The files used for these tests are mounted via NFS from a common fileserver.
Once the simulation loads, network traffic is almost nil. On each platform
the simulation takes less than 200MB of RAM so there's no swapping. The
system load is 1.00 - no other processes apart from the usual OS overhead.
Running a 200 us simulation of an approx. 50K gate design in non-interactive
batch mode gives the following times:
A) 1098 sec
B) 1012 sec
C) 638 sec
Using http://www.spec.org, here's benchmarks for some sparc and x86 systems:
SPECint_base2000 SPECfp_base2000
Dell Precision Workstation 340 648 715
(2.0 GHz P4, 1/4M cache, PC800 RDRAM)
Sun Blade 1000 Model 1900 438 427
(900 MHz Ultrasparc III, 8M cache)
Asus A7V 438 348
(1.3 GHz Athlon, 1/4M cache, PC133 SDRAM)
Intel D815EEA2 421 258
(1.1 GHz P3, 1/4M cache, PC133 SDRAM)
Sun Ultra 10 133 126
(333 MHz Ultrasparc IIi, 2M cache)
Looking at the benchmarks for the Ultra 10 and the Pentium III and 4's, we
were hoping for about 3-4X performance improvement in simulation time.
Instead we're seeing about 1.6-1.8X.
If anybody here has used ModelSim on both x86 and sparc architectures and
could comment on the performance they observed, that'd be greatly
appreciated. Likewise if you've tried ModelSim on an Ultrasparc III, I'd
be interested to know how it compares to an older Sparc. We're a little
disappointed in the performance under Linux/x86 and wondering if we should
be evaluating some high end Sun products to get the performance we expected.
- Rainer Mueller
Oasis SiliconSystems AG Germany
---- ---- ---- ---- ---- ---- ----
> I've also noticed that VCS gives a speedup which scales somewhat with the
> MHz of the machine.
From: Tom Loftus <tloftus@intrinsix.com>
Hi, John,
Since I am in the middle of a puzzling sim performance problem, this topic
caught my interest so I thought I would throw in my two cents.
My experience is that synthesis jobs track CPU performance closer than
digital simulation jobs. My theory is that digital simulations do less
calculations and more random data accesses. This causes poor cache
performance and tends to saturate the CPU to memory datapath before the
CPU can be fully utilized.
I first ran into this several years ago when a former employer made the
mistake of buying Ultra-5 series workstations because they were cheaper
than the Ultra-30's. The CPU specs were comparable, but the memory
bandwidth was lower and the performance was poor. We returned them and
bought more Ultra-30's.
Fast, efficient compiled simulators like MTI and NC-Verilog when run on
workstations (or PC's) which use cheaper low bandwidth memory subsystems
will not perform very well, no matter what speed CPU you put in. Obviously,
swapping should be avoided in all cases as the performance is terrible.
To answer the specific question raised, my experience has been that VCS is
slower than NC-Verilog and therefore would scale with CPU MHz until it also
reached the memory bottleneck whereas NC-Verilog is already there. It
wasn't clear from the post if the VCS and NC-Verilog jobs were the same.
- Tom Loftus
Intrinsix Corp. Rockville, MD
( ESNUG 385 Item 10 ) -------------------------------------------- [12/19/01]
Subject: ( ESNUG 383 #1 ) I'd Like To Hear More About Ambit-RTL's Bad Logic
> 3) Bad logic from Ambit BuildGates. Yes, Ambit-RTL produced bad logic
> in our case. We caught the bugs in Verplex. The problem did not
> stop us from using Ambit because DC is too slow and area consuming.
> It's a trade-off. We can handle the bug instead of delaying the
> chip and getting larger area.
>
> - Ching Hsiang Yang
> Sunplus Technology HsinChu, Taiwan
From: "Mark Warren" <mwarren@xtremespectrum.com>
Hi, John,
I'm a PKS user, too. Ching, can you expand on the problems you saw with
the logic?
- Mark Warren
XtremeSpectrum
( ESNUG 385 Item 11 ) -------------------------------------------- [12/19/01]
Subject: ( ESNUG 382 #9 ) PhysOpt/DFT Spends A *Long* Time Fixing DRC's
> I want to alert your readers to the recent changes in the DFT Compiler /
> PhysOpt flow in the new 2001.08 release.
>
> - Vandana Kaul
> Synopsys, Inc. Mountain View, CA
From: "Neel Das" <neel.das@corrent.com>
Hi John,
Some time back we saw this update from Synopsys on the new insert_dft flow.
We're seeing some interesting things in our flow, and I wanted to check if
some other readers have seen similar stuff, and could (of course!) suggest
some workarounds...
1) insert_dft seems to spend a *long* time, fixing DRC violations. We
are getting better runtimes and lower gatecounts with insert_scan
followed by a 'physopt -incremental -eco'.
2) One of our clusters (floorplan units) needs to have
a) a set of pre-placed registers, which get placed in Apollo,
then show up in the PDEF's as FIXED cells
b) also a set of registers that we place with 'set_bounds', and
are hard bounded.
In both (a) and (b), the registers inherit the dont_touch attribute.
insert_scan then skips these cells during scan stitching: which is
not good!
To work around (a), I removed the FIXED attributes from the PDEF file, then
applied 'set_cell_location' for each register I wanted in a specific
location. Then I ran insert_scan followed by 'physopt -inc -eco'. The cells
did not remain at *exactly* the original spots, but they're close enough.
I don't have a workaround for (b) yet... any pointers, anyone??
Here's an interesting aside:
If I do a 'report_cell -verbose -physical' on one of the cells from (a)
or (b), I can see that dont_touch is set to TRUE.
****************************************
Report : cell
-physical
-verbose
Design : ddr_oeddr
Version: 2001.08-1
Date : Tue Dec 11 00:39:45 2001
****************************************
cell 'ddrc/io/address_0/ffr':
Loc: (5095.20, 183.36) ORIENT: 180-mirror
Area: 48.384
dont_touch: TRUE
blah blah blah ...
1
However, if I do a report_attribute or a remove_attribute, PhysOpt reports
that a dont_touch attribute DOES NOT exist on the cell!
psyn_shell-t> get_attribute ddrc/io/address_0/ffr dont_touch
Warning: Attribute 'dont_touch' does not exist on cell
'ddrc/io/address_0/ffr'. (UID-101)
I'm waiting to get Synopsys support respond on this one...
- Neel Das
Corrent Corp. Tempe, AZ
( ESNUG 385 Item 12 ) -------------------------------------------- [12/19/01]
From: "Mark Wroblewski" <markwrob@colorado.cirrus.com>
Subject: I'm Seeing Conflicting User Comments On Synopsys Route66 Here ...
Hi John,
I saw some comments on the Avanti purchase good/bad/pawn-in-game-of-life
issue suggesting that maybe Route66 is no good and/or that Route66 will soon
replace Avanti router.
Meanwhile, I just read the Synopsys marketing foils on Route Compiler which
contained a few tantalizing "early user" comments that all say Route66 is
the greatest thing since sliced bread.
So, put it to the list if you can:
Are there any ESNUGers that have any real-world tapeout Route66 experiences
yet? If so, just what do they think?
- Mark Wroblewski
Cirrus Logic
( ESNUG 385 Item 13 ) -------------------------------------------- [12/19/01]
From: "Wayne Miller" <Wayne.A.Miller@smsc.com>
Subject: Help! These Mixed Voltage Libs Are A DC/Apollo/PrimeTime Nightmare!
Hi John,
I just received word from a Synopsys AC that if I have a PAD and a CORE
library that have two different operating voltages, then I end up with
significant problems in Apollo, Design Compiler and PrimeTime.
Let me explain.
For a 0.25u core library, my Synopsys libraries have the following
definitions:
best case: 2.75 V
typical: 2.5 V
worst case: 2.25 V
My 3.3V PAD library has the following definitions:
best case: 3.6 V
typical: 3.3 V
worst: 3.0 V
Now, if I specify my operating condition as typical (from the core library)
for timing analysis, then the timing engine (Apollo, Design Compiler, or
PrimeTime) does the following. For core cells:
core typical voltage = 2.5 V
operating voltage = 2.5 V
scaled timing = timing + (2.5 - 2.5) * delta = Typical core timing
(as expected)
For PAD cells:
PAD typical voltage = 3.3 V
operating voltage = 2.5 V
scaled timing = timing + (3.3 - 2.5) * delta = Some other timing, (not what
I expected nor want)
This can't be true! Can it? What am I missing?
Design Compiler (presently, I know the new library format is coming) can only
handle ONE operating condition. Not one per library. Can someone shed some
light on this problem?
- Wayne Miller
Standard Microsystems Corporation
( ESNUG 385 Item 14 ) -------------------------------------------- [12/19/01]
Subject: ( ESNUG 383 #9 ) How To Use The Absolute Minimum PLI With VCS 6.0
> By running VCS with only the Signalscan PLI compiled in VCS (but not used),
> I got a speed-up of 8 to 10 percent on a 3 Mgate RTL design and close to
> 20 percent on a 500 kgate RTL design.
>
> By not compiling in any PLI routines I got a speed-up of 42 to 48 percent
> on both my small and large design.
>
> - Anders Nordstrom
> Nortel Networks, Ltd. Ottawa Canada
From: Amitabh Chand <amitabh@synopsys.COM>
Hi John,
Anders brings up an important point about enabling VCS optimizations. It's
true that turning on global PLI access will hurt VCS performance even if no
actual dumping is done. This is a serious problem with any company that has
a corp CAD group that controls VCS scripts since they want to make everything
available to the verification engineers. VCS engineering is working on
fixing this problem. Until then, we recommenced to use Adaptive PLI which
was introduced in VCS 6.0.
Two steps to use adaptive PLI:
1.) add one flag to the runtime simulation: simv +vcs+learn+pli
This tell VCS to monitor all PLI access and create an new
table file containing just the modules that really needed
to talk to the PLI program.
2.) recompile your design with one additional flag: vcs +applylearn
This tells VCS to override PLI visibility with the new table file.
Thus now VCS will be able to compile and do much more optimizations without
all the overhead of PLI access to Verilog modules that do not need it.
- Amitabh Chand
Synopsys, Inc. Marlboro, MA
( ESNUG 385 Item 15 ) -------------------------------------------- [12/19/01]
From: "Pradip Thaker" <pthaker@zagrosnetworks.com>
Subject: How Do I Best Fill The Holes In A Cadence PKS/BuildGates/SE Flow?
Hi, John,
We use Cadence PKS for our synthesis and back-end needs. However, we are
currently looking to fill up the tool gaps such as DFT needs (JTAG, RAMBIST,
DFT Checker, ATPG, etc.), formal verification, etc.
I am familiar with some choices (especially the ones that fit well with a
Synopsys-based flow such as TetraMax, Formality, etc.) You can also add
Static Timing Analysis (Perl v/s Primetime) issues to this list. I am also
familiar with other solutions such as Verplex, FormalPro, FastScan, GenSys,
SynTest, LogicVision products, etc.
So many permutations are possible. My question is what fits really well with
Cadence Cadence-PKS/BuildGates/SE flow, what are the issues?, what works?,
what doesn't work well?
- Pradip Thaker
Zagros Networks Rockville, MD
( ESNUG 385 Item 16 ) -------------------------------------------- [12/19/01]
Subject: ( ESNUG 383 #17 ) More Setup/Hold Library Characterization Gotchas
> The .lib format has no mechanism for expressing any of these tradeoffs,
> even if you gather all the needed data. That forces the guard-banding
> to be unnecessarily large, which in turn reduces the accuracy of timing
> analysis and synthesis.
>
> - Howard Landman
> Vitesse Semiconductor Longmont, CO
From: "Fred Obermeier" <fwo@z-circuit.com>
Hi, John,
Howard's comments concerning limitations of the .lib and this aspect of
timing analysis are correct. To be safe, you end up creating models for
worst-case situations.
A widespread technique for picking setup and hold times involve a maximum
degraded clk-to-Q over nominal, such as 10%. From a design standpoint,
you want the smallest combination of setup time and clk-to-Q for your models,
since these are used to determine the maximum operating frequency of your
design. A conflicting design consideration is to have as small hold times
as possible. Small hold times tremendously reduce the need to insert
buffers to fix hold time problems late in the design process. So the
characterization of cells should reflect the design goals of circuits as
well as how these models will be used by timing analysis and/or synthesis.
Let's say you determine the minimum setup time given a large hold time and
the minimum hold time given a large setup time. You can be more aggressive
when you don't see simultaneous minimum setup and hold conditions. For
example, setup and hold times for a typical range of slew are +/- 150 psec
between slow and fast libraries. Clk-to-Q times increase about +300 psec
when going from fast to slow libraries for typical loads and slews. If you
consider a min/max design practice, setup time is analyzed with slow libs
and hold times are analyzed with fast libs.
This causes the setup/hold window to be wider than the minimum possible at a
specific PVT point which is where circuits closely operate. Thus, even
though the flop may be vulnerable to dependent setup/hold failures at a
specific PVT, the min/max design practice usually prevents that from
occurring because that minimum window does not occur.
Let's look at the PVT variation for a typical FF at the same input slews
and output load conditions:
setup hold clk-to-Q clk-to-Q
(small load) (large load)
slow 0.1766 -0.1382 0.4662 2.5090
fast 0.0625 -0.0234 0.2115 1.0240
What you get if you use the minimum setup time will mostly likely be larger.
This represents a larger guard-band, to address the case where a path with
a minimum setup and minimum hold time can occur.
Z-circuit characterization software supports both of these techniques.
Therefore, dependent setup/hold is an area where you need to be careful not
to over-design when you characterize especially if you are pushing
performance. Certainly, some types of flops can operate in unusual ways at
slow and fast PVT, so this is a case where dependent setup/hold may be
important and you can determine this by understanding the flop operation
at slow and fast PVT.
The issue of degraded clk-to-Q is more clearly an issue when better timing
analysis and .lib models would help. Consider the case:
------
A -----|D Q|----- B
| |
clk -----|> |
------
Where A is the path going to the D input and B is the path from clk-to-Q
and on to the next flop. Let's say A is a path where we barely meet
timing and thus setup time is minimum. Then the clk-to-Q for B will really
be the degraded value and thus that better be what we model in the library.
However, let's say that path A meets timing easily. Then the clk-to-Q will
NOT be degraded; however, we still will have used the degraded value because
thats the only option we have in the .lib model. Thus we are over-designing
path B for no reason. This is too bad since the timing analysis tool has
the information about path A, and knows how close to the setup time it
really is. But there is no model to describe this.
A similar issue occurs for hold time and fast models. However, in this case,
you better be sure to use the library that has the fastest value, rather than
the degraded value of clk-to-Q. Otherwise, you risk a hold-time violation
even though the timing analysis report is clean. The problem with this
fastest value is that you are over-designing again because you are using the
worst case. Of course, circuits often operate faster than expected, so a
little extra margin for hold is good since hold-time violations have few
work-arounds. With marginal setup time violations, you can slow the clock a
bit.
- Fred Obermeier
Z Circuit Automation, Inc.
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
