"They are swallowing a toxic ball."
- Cadence general legal counsel Smith McKeithen on the Synopsys/
Avanti merger. (Wall Street Journal, 06/05/02)
( ESNUG 396 Subjects ) ------------------------------------------- [07/11/02]
Item 1: ( ESNUG 393 #1 ) Synchronous vs. Asynchronous Resets In Designs
Item 2: ( ESNUG 394 #3 ) Conflicting Letters On The 3 Monterey Tape-outs
Item 3: ( ESNUG 395 #6 ) Aristo/SPC/PhysOpt Rectilinear Block Design Flows
Item 4: Can I Swap My Chip Arch Licenses For Floorplan Compiler Licenses?
Item 5: User Asks What's The Deal With The New PhysOpt 2.5 D Extraction?
Item 6: MIPS Reviews The Synopsys coreBuilder & coreConsultant DW IP Tools
Item 7: Installing Current Revs Of Synopsys Tools Is A Customer Nightmare
Item 8: Reader Reactions To "The Genius of Ray Bingham" EE Times Column
Item 9: ( ESNUG 395 #9 ) VHDL <-> Verilog Or Vera <-> Verisity Xslators
Item 10: DW Artifacts Will Mess With Your PrimeTime SPEF Reader Runtimes!
Item 11: Surprise! VCS 6.2 FCS Doesn't Support gcc On 64-bit Solaris!
Item 12: How Can I Convert A Cadence Diva DRC File Into A Dracula DRC File?
Item 13: graph_log -- A Graphical Perl Log Script For PhysOpt And DC Users
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 396 Item 1 ) --------------------------------------------- [07/11/02]
Subject: ( ESNUG 393 #1 ) Synchronous vs. Asynchronous Resets In Designs
> We are starting a new ASIC design and had new member coming from another
> group. When discussing methodology, our new collegue suggested using a
> synchronous reset flip-flop over asynchrous flip-flop which was a shock
> to us. Our past design guideline has been using async reset flops only
> (because all ASIC vendors we know about only have async reset flops in
> their libraries, so if you choose to code a sync reset flop the
> Synthesis tool will try to build some logic in front of your D pin).
>
> Do your readers have any suggestions on this?
>
> - Jerry Yang
> Nortel Networks Nepean, Ontario, Canada
From: Marco Winzker <MWinzker@Liesegang-electronics.com>
Dear John,
You definitely need an asynchronous reset and not a synchronous reset. Two
arguments:
- An asynchronous reset will always be synthesized to a
FF-cell with a reset, while a synchronous reset might be pulled
into a complex combinational cell. Then, in gate-level simulation
this combinational cell has the reset input which is '1' and
maybe two or three undefined signals. Depending on how the
library-guys implemented the library, the simulator might set the
output of the cell to undefined (as it has undefined inputs).
- If you have a synchronous reset, you must make sure, that
during reset you have a clock. This might sound trivial, but
imagine the clock comes from an AD-converter or video
decoder which outputs no clock, when it does not detect
a proper input signal.
Regards,
- Marco Winzker
Liesegang electronics GmbH Germany
---- ---- ---- ---- ---- ---- ----
From: [ Chicken Man ]
Hi, John,
This must be anonymous!
A technique we have been using is asynchronous activation of reset and
synchronous release.
|-----| |-----|
clock ---|> | clock --|> |
| | | |
reset ---|D Q|-----------|D Q|---reset-out
| |--O--| |--O--|
|____|_________________|
The two flip-flops are for metastability control. Reset causes reset-out to
go active, but reset-out will not release until after two clock edges. This
gives a full clock period for all downstream logic to respond to reset since
reset-out always goes inactive on a rising clock edge (assuming you are not
using lots of negative logic). This can prevent reset skew from allowing
different flip-flops to see reset in different clock periods (e.g. two flops
in a state machine seeing reset release just before and just after the clock
edge due to skew in the reset net). An extension to this is to cascade
reset-out from one section of the circuit to another to control start up
sequencing (e.g. different clock domains).
This has been implemented on multiple ASICs using a Synopsys flow.
In response to Jerry Yang's concern this puts the logic in the reset circuit
and leaves the logic on the D input untouched.
- [ Chicken Man ]
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jlk@brecis.com>
Hi John,
Regarding Jerry Yang's question about the set/resets in a design being
synchronous or asynchronous with respect to the clock, there seem to be two
schools of thought in making a choice and obviously they do not preach the
same methodology. I am not sure if one is better over the other because I
know SOC designs that have been done in both ways are currently working
first-silicon. As I am a backend engineer, I prefer the resets being
async, because my library does not have sync reset flops and therefore I do
not like more logic in my datapath eating up timing and I also do not like
the reset pins being wasted (tied high or low to deactivate it). But there
are libraries that have sync reset flops and one of Artisan's datasheets
talks about a sync reset flop. And now,thanking the RTL people who helped
me with their suggestions, here are the thoughts.
1. All set/resets should be Asynchronous.
Reasons: Typically in a CPU design, the clock is stable when reset
comes in and so synchronous reset is used, but in system design
(chipset/networking) the clock (internal) takes quite a while to
stablize and may be unpredictable due to different clock domains
in the same design. So it is safer to use asynchronus reset. Or
else some clocks might not be stable when reset goes away causing
some flops to propagate unknowns instead of reset values.
2. All set/resets should be Synchronous.
Reasons: Async controls on Registers create paths that the designer
is unaware of. Many async designs CAN NOT be proven to work with
timing analysis tools and/or simulation. Synchronous designs are
easy to analyze for timing, and therefore easy to determine that they
will work. By definition using an async input to a register creates
an asynchronous design which makes the problem of timing analysis much
more difficult. In a system with multiple clocks with different
stabilization times, each clock domain should reset synchronously
within its time domain.
In the best of all worlds, the external reset would be sent to a central
system reset block and then distributed to the individual blocks so that the
system reset sequence could be controlled. The reset state of each block
(in the time domain of that block) could go back to the central system
reset block (where it would be synchronized to its time domain) to complete
the reset sequence control loop. The reset of a system should be designed
instead of being a result of the way the individual blocks happen to reset
themselves. This can be difficult to do if a block resets asynchronously.
When each block resets asynchronously, the system reset sequence may be
constrained by one or more of the lower level blocks. The typical result is
to add extra time for reset to be asserted. This is particularly true for
controlling X propagation, which is not only a pain for simulation, but can
affect how a chip must be tested (on a tester). What may seem like a good
idea for an individual block may not work when the block is a small part of
a larger system.
A common mistake with systems that use async resets to initialize themselves
is that the reset path is not considered as a valid timing path (it is
ignored). The result of this usually is a reset timing path that is
multiple clocks long. Although this has little affect on simulation, it
is a big deal for test. In some cases the tester is limited to running
functional patterns at the frequency that makes the reset path single cycle.
- Jay Pragasam
Brecis Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jlk@brecis.com>
Hi John,
Here is some more that I've found on sync/async set/resets issue:
"Each has its pros and cons. This is another religious issue. I prefer
asynchronous resets to synchronous ones. Early in DC's life there were
problems with merging the synchronous reset signal in with the cloud of
logic in front of a flip-flop. This would result in a simulation lock-up
of unknowns as the Verilog simulator started each flip flop in an unknown
state and they never came out of the unknown state. It was never really
a DC problem, but DC got the blame. It is no longer an issue since DC
has had the ability to recognize synchronous reset/set signals and put
them as close to the inputs of the flip-flops as possible (no merging
with regular functional logic). The ability to check for synchronous
resets is activated by setting a variable to true:
hdlin_ff_always_sync_set_reset = true
But I got used to describing asynchronous resets and the coding style
stuck. The big thing you ve got to watch out for is not when the
asynchronous reset goes active, but rather when it goes inactive. As
soon as the asynchronous reset goes inactive the flip-flop is free to
change state when the next clock edge occurs. If the reset signal is
distributed throughout your design without care to how long the delay is
on the reset network you can have parts of the chip working in
functional mode while other parts of the chip are still in reset mode.
You've got to treat the asynchronous reset signal like a clock line and
balance it so that the signal goes inactive within the same clock cycle
throughout the entire chip. In case you don t plan to have a perfectly
balanced reset signal you can define the reset states for the flip-flops
and the combinatorial logic sections to hold their values stable for X
number of cycles or until the data inputs to the chip change (or some
other equivalent trigger event occurs). What this means is that you
design your default states or reset states such that they don't cause a
change in the logic values downstream from their position in the logic
cone when they are released (and free to change) from the reset state.
This could also save power if the chip doesn't start switching as soon
as the reset is released but rather when there is work to do."
This was in a paper presented in the SNUG'02.
- Jay Pragasam
Brecis Communications San Jose, CA
( ESNUG 396 Item 2 ) --------------------------------------------- [07/11/02]
Subject: ( ESNUG 394 #3 ) Conflicting Letters On The 3 Monterey Tape-outs
> Last month Monterey claimed 30+ tape-outs. And Goering rightly reported
> that Monterey "claims just over 30 tapeouts". I know of two customers
> who've done 3 Monterey tape-outs -- therefore I'll only report 3 tape-outs
> until I hear otherwise from the Monterey customers themselves. - John
From: [ The Truth Is Out There ]
Dear John,
Please keep me anonymous. I'm an engineer that uses Aristo IC-Wizard of
Monterey. With Dolphin, I know:
1. There are currently, 0 tapeouts (!) were done using Dolphin only.
The tapeouts in Infineon and in Zoran use Silicon Ensamble as a
router. In addition, both tapeouts were done using Cadence tools
for clock.
2. All 3 "tapeout" uses a huge R&D support by Monterey.
3. The tool itself is extremely slow, and require a lot of special
tricks and bypasses.
4. There is no real connection between Dolphin timing engine and Aristo
IC-Wizard. We have heard a lot promises, with 0 results.
I do not know where Mr. Goering found 30 tapeouts. If it is so, why is it
so confidential??
To me it seems like someone's trying to fool ESNUG readers.
- [ The Truth Is Out There ]
---- ---- ---- ---- ---- ---- ----
From: Hiroyuki Nakamura <nakamura.hiroyuki@canon.co.jp>
Cooley-san,
Monterey asked me to tell you how many tapeout we made. We made 2 tapeouts
last year. One is for Sensor's peripheral mixed signal ASIC by 0.35 um
technology. Another one is also mixed signal IC including area sensor by
0.8 um technology. I can also inform you that these 2 chips work on 1st
silicon without problem. Now we believe that Monterey's Dolphin is very
reliable EDA tool.
- Hiroyuki Nakamura
Canon, Inc. Japan
---- ---- ---- ---- ---- ---- ----
From: [ The Infineon Man ]
John,
Pls. keep me anonymous. I'll try to clearly mark my opinion from facts.
We have used a Monterey "physical synthesis" flow for 2 tapeouts so far.
Designs: Telecommunication SoC's, 700 K gates, 1M gates, each dominated by
macros (70%,80% chip area is macros). One design 30 clocks other 50 clocks,
60 MHz base frequencies (one design locally up to 500MHz).
Our simplified design flow:
1.) designs simulated RTL VHDL
2.) Synopsys DC (no special options) and test insertion
3.) Monterey Sonar/Dolphin Layout + "physical synthesis"
4.) Extraction, STA, formal verif., LVS/DRC
The only new tool in our flow is Monterey's "physical synthesis". In our
case this has been Sonar/Dolphin 2.0 -- which has proven reasonnably
stable and very useful (opinion).
We give Design Compiler fairly simple block-level (clock, some basic
block-level IO etc.) constraints and leave chip-level timing, buffering
etc. to layout.
We have designed the system to ease timing on the interface definition of
blocks (registered outputs, etc.)
There's been only one occurence of a case of bad architecture selection
(arithmetic) by DC when it thought it could get away with a simple ripple
structure when more complex (carry-look ahead) was needed (due to a non-
registered top-level path which had slipped by.)
Dolphin usually improved on the timing expected by Design Compiler even
using aggressive wire-load models.
Personal Opinion: In this flow, Design Compiler still wastes too much
time tinkering with wire-load models, drive strengths, fanout buffering
and low level time-driven structuring. It should leave all that up to
physical synthesis. Physical synthesis is in a better position for that
as it has more accurate information and it can do better optimization
(by not only taking placement into account but by controlling placement
to improve timing). Really aggressive timing driven placement can
generate surprisingly fast logic for datapath designs.
To take advantage of this flow, however, new libraries are needed. We are
seeing critical paths placed so tightly that smaller cells without output
buffering would be strong enough drivers yielding more speed and less power.
Currently the smallest library cells available still "overdrive" those
paths.
Our DC effort had no extreme time/memory/compute intensive toplevel
characterization, bottom-up, top-down, etc. runs. We're back to good ol'
straight forward module level DC runs which we parallelized. Dolphin
uses the same format timing constraints as PrimeTime, thus it's no big
deal to convert between them. (Figuring out how to constrain between
50 clocks is a different story.)
On a side note: Clocks which are derived off of other clocks (in our
case most of our clocks) can be specified as such to Dolphin. It can
balance them and determine the actual phase relationship between them
into account when doing setup/hold fixing. That takes the burden
(and uncertainty) of determining false paths off the user's shoulders.
Opinion: This doesn't sound like much, but we believe it greatly enhances
design reliability as false-path statements always bear the risk of being
less false than the designer believes. Since Dolphin knows about the exact
timing between the clocks it fixes whatever paths there are - no worries.
(Yes, we likely fix more paths than we really have to - but who cares when
it's free?) Another side effect is that one can quite flexibly describe
how to do the clocks (e.g. skewing flops early for fast chip-output paths)
and still get all other timing needs (hold to those flops, scan etc.) fixed
without any extra effort.
All this is -IMHO- only possible in a physical synthesis flow/tool, which
makes absolutely sure that the timing you see is what you get as there
are no further steps afterwards. (Unlike the traditional synthesis-
layout flow.)
After running through layout (less than 24 hours) of course we do some
DRC/LVS/extraction, independant STA, formal verification. This usually
comes out somewhat clean. (Whenever we saw major issues the causes
where human errors, library mismatches, timing mis-characterization,
wrong derating, etc.)
Opinion: With more experience/maturity of the flows/tools/methodologies,
we believe we can take some of those backend-backend steps off the
critical path and move them into parallel (sort of qualification-) paths.
Basically like years ago when we started to believe synthesis not to
produce bad logic (we still check - but not as insistently and rigorously
as years ago) and when we adopted STA to replace timing simulation.
Opinionated Summary:
Even though the Monterey flow is already clearly better, we are not
seeing the full potential of it yet:
- No clear distinction of tasks between "Front-End" and "Physical"
Synthesis. (IMHO these require extremely different key features:
Architectural vs. Physical)
- Basically no library support in place. Need: Front End libraries
without distracting information (like wire-load models, many drivers,
wire-resistance etc.)
Backend libraries need significantly more drive-strenghts (finer grain,
much smaller), availability of more aggressively designed cells (complex
functions, non-buffered cells.)
- [ The Infineon Man ]
( ESNUG 396 Item 3 ) --------------------------------------------- [07/11/02]
Subject: ( ESNUG 395 #6 ) Aristo/SPC/PhysOpt Rectilinear Block Design 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: Anthony Galdes <anthony@mondes.com>
Hi John,
Rectilinear (L-shaped) blocks can be a real headache. The biggest problems
lie in two areas; design planning and block implementation.
- Inside the block, the area that's left for macro and cell placement might
be quite fragmented, so the utilization & congestion might not be great.
Depending on the nature of the problem, you can sometimes use the
mega-cells to mask some of the fragmentation by placing them in the
"alcove" areas and effectively reducing the number of edges of the
placeable standard cell area. It also helps to tune macro placement at
the chip-level rather than at the block level.
- At the chip-level the problems are a little tougher. The largest area of
concern is port placement. You'll need a tool that can place ports along
all 6, 8, 10... edges of your block. Doing this by hand isn't an option,
unless you have lots of time in your schedule. The port placement needs
to look into the block so that it doesn't create more headaches for the
guy implementing the block itself. Your planning tool will also need to
keep track of the power grid so that all the edges of the rectilinear
block synchronize with the top-level power mesh. If you keep track of
these issues, life shouldn't be too "miserable".
Our customers have been using Aristo IC Wizard to build designs w/ L-shaped
blocks for over two years. They don't seem to have problems interfacing
L-shaped blocks to Avanti Apollo. IC Wizard helps Cadence users by creating
overlap blockages for cutout areas when exporting DEF and also creating a
MAC (command script) file that SE uses to trim the rows as necessary.
So my vote? Go ahead and crank out that design with a couple of L-shaped
blocks.
- Anthony Galdes
Monterey Design Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: Steve Cline <scline@cadence.com>
Hi, John,
Some PhysOpt/Apollo users use Cadence's First Encounter (FE) for rectilinear
partitions. FE allows you to select any module in the design hierarchy as
a partition. Once the decision has been made on which blocks to partition,
a typical sequence runs as follows:
1. Specify the module to be partitioned using the Partition -> Specify
Partition... menu. In the Specify Partition form, give the
hierarchical instance name and a partition name, and click on
Add/Replace to add the partition to the list of modules to be
partitioned. Clicking 'OK' will change the module 'guide' (FE-ese
for a non-exclusive placement area) to a 'fence' (FE-ese for
exclusive placement area). (Also make sure you check the "Save
Partition Spec to" button and give a filename which can be used
in the top-level reassembly process starting in step 7 below.)
2. Select the 'Add Partition Rectilinear Cut' Tools Widget.
3. Using the left mouse button draw the rectilinear cut(s) over the
existing rectangular module definition to create the rectilinear
shape desired.
4. 'Place' and 'Trial route' the design using the Place -> Place... and
Route -> Trial Route... menus respectively.
5. Create the block level partition using the Partition -> Partition...
menu, selecting the 'Perform Pin Assignment' button.
6. Save the partition data using the Partition -> Save Partition... menu.
Select the PDEF output format button if you are going into PhysOpt.
This will then save data into a directory with the partition name
given to the partition in step 2. This information can then be used
to complete the block-level design. There will be a Verilog netlist
as well as a PDEF file which contains a definition of the rectilinear
region, including the pin assignments on the boundary, as well as
power busing pushed down from the top-level. Furthermore there will
be block-level timing constraints derived from the top-level timing
constraints that can be used to drive PhysOpt. These constraints are
based on the full-chip timing analysis done in FE and budgeted
accordingly. The pin assignments will be based on the actual routing
done in step 5. Note that the user has control to guide pin
assignments if desired, including putting in pin placement blockages.
All this data is used as the source for the PhysOpt run.
Once you have done the block-level implementation in PhysOpt, your block-
level design data can be read back into FE for further top-level analysis
and/or floorplan refinement using the following steps:
7. Re-import the design into FE using the new Verilog netlists. One of
the features of FE when partitioning is to also create a "top-level
partition" which includes a top-level Verilog netlist which includes
abstract instantiations for the partitioned modules. (Note that the
top-level partition directory also allows top-level hierarchical
optimization using both abstract timing (ILM, Stamp) and physical
(LEF for example) views for the partitioned blocks.) This netlist can
be read into FE along with the updated block-level Verilog netlists
to create a description of the newly optimized hierarchical design.
The FE Design Import form in the GUI allows navigating to find and
select the updated Verilog netlists.
8. Reload the original top-level floorplan.
9. Reload the partitions. This is done using the Partition -> Specify
Partition... menu and then clicking the Load... button and loading the
partition spec file saved in step 1 above.
10. Repartition the design using the Partition -> Partition... menu. Don't
do pin assignment.
For each partitioned module, do the following:
11. Select the partitioned block in the FE GUI.
12. Do Partition -> Change Partition View. This will push down into that
block.
13. Load the placement and/or routing data for that block using either the
Place -> Load Place... or Route -> Load Route... menu. This will allow
you to load place/route data from your block-level tool using PDEF or
other formats.
After doing steps 11-13 for each partitioned block:
14. Partition -> Unpartition... selecting all modules to be unpartitioned.
At this point you will have all of the detailed block-level place/route
data loaded back into FE and stitched together. You can then run
full-chip timing analysis, and IPO if necessary. Furthermore, if your
timing is still not being met at this point, you can refine your
floorplan and repartition (for example getting more refined block-level
timing budgets/constraints) based on this updated data.
There are several steps in this process, but in practice the whole sequence
runs fast and is pretty easy to use; and offers a number of advantages in
terms of accurate partitioning, timing and congestion analysis, etc.
- Steve Cline, FE FAE
Cadence Santa Clara, CA
( ESNUG 396 Item 4 ) --------------------------------------------- [07/11/02]
From: Mark Wroblewski <markwrob@colorado.cirrus.com>
Subject: Can I Swap My Chip Arch Licenses For Floorplan Compiler Licenses?
Hi, John,
Floorplan Compiler (v2002.05) is available at the SNPS ftp site. Does
anyone know if Chip Architect licenses will be converted to FPC licences?
I'm meeting with my SNPS folks today to ask that question, but would like
to double check this. With tight budgets and the risk of more layoffs,
now is not a good time for me to suggest the firm even evaluate another
tool. But since we already have two Chip Arch licenses....
- Mark Wroblewski
Cirrus Logic Broomfield, CO
( ESNUG 396 Item 5 ) --------------------------------------------- [07/11/02]
From: Mahsa Vahidi <mahsa@mindspeed.com>
Subject: User Asks What's The Deal With The New PhysOpt 2.5 D Extraction?
Hi John,
I'm wondering if anybody knows what's the deal with the new 2.5 D extraction
engine in PhysOpt. Specifically, will it eliminate the RC correlation step
in PhysOpt?
I was told by the PhysOpt R&D manager at DAC that this new extraction engine
should eliminate the need for correlation. That we should try it for
ourselves and if the R and C factors are not close to 1, we should file a
bug report. However, our scaling factors turn out exactly the same as their
1-D extraction and nowhere close to 1.
I can't get a straight answer from Synsopys. Any ideas?
- Mahsa Vahidi
Mindpseed Technologies San Diego CA
( ESNUG 396 Item 6 ) --------------------------------------------- [07/11/02]
From: Larry Hudepohl <lhh@mips.com>
Subject: MIPS Reviews The Synopsys coreBuilder & coreConsultant DW IP Tools
Hi John,
My group at MIPS has been working on the DW-4KE family of DW parts.
We've been using the Synopsys coreBuilder tool so that a MIPS customer
could use our parts simply through the Synopsys coreConsultant tool.
Here are our benchmarks from trying to get our IP through coreBuilder.
Scan. We only support the Mentor test tools with our version of the MIPS
4KE cores. DFT Advisor for scan insertion and FastScan for ATPG. So we
didn't have any experience with the Synopsys test tools. Synopsys's
coreBuilder provides automation and scripts for their testability tools,
DFTCompiler and TetraMax.
FYI: Verilog/VHDL simulation seems to be the only place where Synopsys
coreBuilder acknowledges the existence of rival tools. It supports
simulators from Cadence and Mentor. Third party support for other tools
(synthesis, STA, DFT, and power analysis) is not included in coreBuilder.
We found that the Synopsys test tools yielded very good results compared
to the Mentor tools on our 4KE cores. TetraMax achieved better test
coverage in about 27% fewer vectors than FastScan.
ATPG tool Test coverage Vectors
--------- ------------- -------
FastScan 98.94% 1062
TetraMax 99.36% 773
The data above compares two identically configured 4KEc core netlists. One
had scan insertion performed by Mentor DFT Advisor after synthesis with DC,
then ATPG performed by FastScan (version 8.9_2.10). In the second case,
scan insertion was done by Synopsys DFT Compiler during DC synthesis, then
ATPG was run with TetraMax (version 2001.08).
Gated clocks and Power Compiler. The coreConsultant tool includes direct
hooks for Design Compiler synthesis with Power Compiler power optimizations.
(Remember that coreBuilder is what we used to package our MIPS IP. Our
customers then use coreConsultant to customize our MIPS core in their
designs.) The power savings is from it replacing conditional flops in our
MIPS core with gated flops. Power Compiler lets our customers dynamically
trade-off the amount of clock gating within the MIPS core by choosing the
threshold for how many flops are controlled by the same condition. (This is
all before clock gating is employed.)
Here is a table showing some results for various thresholds, all based on
our MIPS DW-4KEc core in a maximum configuration, containing a total of
8688 flops. These runs used an Artisan 0.18um G library and were
synthesized using Design Compiler and Power Compiler (version 2001.08),
under coreConsultant (version 3.1.3).
Case # Gated # Unique Relative Relative Power
Flops Cond Area Period (mw/MHz)
------------------------------------------------------------
No PowerComp 0 0 1.00 1.00 1.70
thresh = 16 6598 231 0.87 1.01 0.80
thresh = 8 7284 305 0.89 1.01 0.69
thresh = 4 7722 396 0.86 0.97 0.59
thresh = 2 7789 422 0.85 0.98 0.57
thresh = 1 7949 583 0.86 1.00 0.59
The "Gated Flops" column shows how many flops Power Compiler identified for
gating, while the next column shows the number of clock gating elements
needed. The "Relative Area" shows the area improvement with clock gating,
normalized to the case where Power Compiler was not run. The "Relative
Period" column indicates minimal impact on cycle time. The "Power" column
shows absolute average power dissipation, from PrimePower analysis while
simulating a Dhrystone 2.1 benchmark at 1.8 v.
- Larry Hudepohl
MIPS Technologies, Inc. Mountain View, CA
( ESNUG 396 Item 7 ) --------------------------------------------- [07/11/02]
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Subject: Installing Current Revs Of Synopsys Tools Is A Customer Nightmare
Hi John,
I just finished trying to install the latest and greatest Synopsys tools.
What a nightmare! Working at a start-up, one gets to wear many hats
sometimes, and I've been helping out in the SysAdmin area with maintaining
Synopsys tool installations. With the 2000.11-SP2-2 suite, all the tools we
use at least had the same model year and sold documentation. Not any more!
For Design Compiler, I installed the 2001.08-SP2-2 version/patches. For
TetraMax, I overlayed the 2001.08 version (note that there is a listing for
TetraMax 2001.08-TX1 on the Solvnet release library, but no links for
download instructions or release notes). For PrimeTime, I installed 2002.03
stand alone - the only option, and had to break my convention as follows:
Installation tree was $TOOLS/synopsys/[release number, ex. 2001.08-SP2],
where $TOOLS is the general tools installation root. This became the
value of $SYNOPSYS.
Now I add to that $TOOLS/synopsys/primetime/[release number], keeping the
old convention for Design Compiler. I also have to create a $SYNOPSYS_PT
variable so as not to stomp on the $SYNOPSYS variable.
Since we're looking at Formality, I installed the 2002.03-FM1-SP2 version,
again stand alone as that was the only option. This adds
$TOOLS/synopsys/formality/[release number] and $SYNOPSYS_FM to the mix.
So far, so good. Now I try to install the 2002.03 SOLD documantation.
First I tried to overlay it on top of the sold in the 2001.08-SP2
installation tree. No deal! The installation script detected the
difference in versions and bailed on me. Ok, there's more than one way to
skin a cat, I figured I'd just overlay in on top of the 2002.03 PrimeTime.
The version numbers match, there shouldn't be a problem, right? Wrong!
This time the installation script detects that something already occupies
the 2002.03 space and again bails. Want to play hard ball, huh?, OK, I'll
give it it's own tree!
I now add $TOOLS/synopsys/sold/[release number] to the mix.
Now that all the tools are actually installed, I've got a few more problems
to solve. The convention I've used so far is to have a central repository
of .cshrc files for individual tool suites with version stamps in the file
name, and a link without the version stamp to point to the correct version.
For example:
.cshrc.synopsys.2001.08-SP2 contains all the necessary settings for
this version,
.cshrc.synopsys links to .cshrc.synopsys.2001.08-SP2
.cshrc.synopsys.old links to a previous working version's
.cshrc.synopsys.[version]
.cshrc.synopsys.new links to the next version being experimented with.
An individual user's .cshrc file sources the .cshrc files for the
appropriate tools they need, including the .cshrc.synopsys file, or the
specific version they may require.
Since the release trains are now separate for PrimeTime and Formality, I now
have to add .cshrc.synopsys.pt and .cshrc.synopsys.fm with the .new or .old
extentions as necessary.
Oh yeah, I now have two separate installations of SOLD to deal with, they
both use sold as the alias by default. I now have sold_pt and sold_fm
aliases created in the appropriate .cshrc file for each tool to point to the
stand alone SOLD for 2002.03 so the original sold alias can point to the
documentation for Design Compiler. Yikes!
Since we're starting to look at Linux, I dual installed all of the above as
SparcOS5 and Linux. That was actually the easy part! Synopsys did a nice
job with multi-OS installation, minimizing the overhead of adding an
additional OS instead of requiring a full replication in a separate
installation space like some other vendors. I created separate
.cshrc.synopsys.version files for Solaris and Linux, and my original
.cshrc.synopsys link now does an OS test with uname -s, and chooses between
the Solaris and Linux versions of the actual .cshrc.synopsys.version file.
It turns out that TetraMax has a built in script to do just that, it would
be nice if the remaining Synopsys tools did the same.
- Bob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 396 Item 8 ) --------------------------------------------- [07/11/02]
Subject: Reader Reactions To "The Genius of Ray Bingham" EE Times Column
> That was a little over two years ago. When I stepped into the Cadence
> suite at DAC last month, I suddenly realized how wrong I was about Ray.
> He may not know technology, but his advisors do. And what I saw told
> me that Ray had organizational skills I hadn't appreciated before. Ping
> Chao, Wei-Jin Dai, Chin-Chi Teng, and Kit Lam Cheong from Silicon
> Perspectives were there. From CadMOS, there was Ken Tseng, Vinod Kariat,
> and Nishath Verghese. From Plato there was Limin He, David Yao, Louis
> Chao, and Wenyong Deng. And from what I heard about Simplex, Steve Teig,
> Tom Kronmiller, Narain Arora, and David Overhauser were coming over to
> Cadence, too.
>
> This shocked me. Instead of Cadence traditionally milking a start-up's
> success while slowly killing off its R&D development, Ray's Cadence had
> the acquired R&D people from the start-ups put into positions of power
> within Cadence! They were replacing the Cadence old guard that had failed
> in that EDA niche. Whoa! Ray's Cadence had gotten over the Not Invented
> Here syndrome. Intergration Ensemble's broke? Use Silicon Perspectives
> instead. Hyperextract's choking? Try Simplex instead. Warp Route's
> dying? Say hello to Plato! Assura-SI gives you flakey results? Then
> replace it with CadMOS. The Cadence Ray has made has no sacred cows.
> Double Whoa.
>
> - from "The Genius Of Ray Bingham"
From: Helene Deng <hdeng@tensilica.com>
But John, many of these talented people were in Cadence before! You made
it sound like Cadence's old guards are no good that they need the fresh
blood. In my mind, it is not what the talented individuals can do, but
how the talents are organized and utilized.
- Helene Deng
Tensilica, Inc.
---- ---- ---- ---- ---- ---- ----
From: Mark Rencher <markr@pivotalenterprises.com>
Hi John,
In your recent comments on Cadence and to a large extent Ray Bingham, I
agree that Ray has really turned the Titanic around in some important areas.
Having visited with Ray about 6 weeks ago with Lambert vanden Hoven
(Philips) regarding RF EDA, Lambert and myself made a recommendation and the
results were the Agilent/Cadence alliance.
Ray is a mover and shaker when it comes to business. But what my clients
are looking for are nano-mete" and RF Mixed Signal solutions. Can Ray
close the gap? Time will tell, but Ray needs to focus on making the
nano-meter fabs profitable. You can bet that behind every 90 nano-meter
fab/alliance announcement there is a mandate (I know I was on the Philips
90 nano-meter product selection team while @ Philips) of making the fab
profitable.
- Mark Rencher, President
Pivotal Enterprises
---- ---- ---- ---- ---- ---- ----
From: Nir Sever <nir@zoran.co.il>
Hi John,
What amazes me is that Cadence is basically admitting they have no R&D and
by acquiring all these technologies, they won the "IEEE Award For Industry
Leadership In Innovation". What innovation?
- Nir Sever
Zoran Israel
---- ---- ---- ---- ---- ---- ----
From: Simon Wilkinson <Simon.Wilkinson@sde.eu.sony.com>
Dear John,
I would agree, having noticed for a while that Cadence now sets the
standard in the EDA industry (if not for others as well) for 'win-win'
acquisitions/'mergers'/'joint ventures'. Three of the recent ones,
CadMOS, Neolinear and Silicon Perspective, were really good moves.
The other big players have realised this -- which I think pushed Synopsys
into the difficult 'merger' with Avanti (which will take some time yet to
bear fruit.)
- Simon Wilkinson
Sony Semiconductor Basingstoke, Hants, UK
---- ---- ---- ---- ---- ---- ----
From: Anthony Galdes <anthony@mondes.com>
Hi John,
Hey when you were talking about Simplex, you forgot to mention Aki Fujimura.
I used to work for Aki at Tangent. Wow was that a few years ago! Let's
see we worked together back before the first MAC was introduced by Jobs! It
was before the days of menu driven interfaces, everything was command based.
You must have worked with Tancell or Tangate so you know what I mean
"set variable draw.wire. ..."
Anyway, Aki is the key guy, he knows how to motivate a team, not to mention
create strategic alliances with customers. But you are right, guys like
Tom, Steve and Aki can really make a big difference. What about YT Lin?
Also from Tangent.
- Anthony Galdes
Monterey Design Systems
---- ---- ---- ---- ---- ---- ----
From: [ A Cadence Employee ]
John,
Until now I had not realised your were so mis-informed. But full marks for
trying to arouse some controversy. My point is general with regard to all
corporate manouvering, not just Cadence's latest white rabbit.
A policy of buying innovation from small companies seems very short term
to me. The original founders soon leave (after they are vested), are
"assimilated", or piss-off the rest of the organisation with their
arrogrance. Perpetual revolution seems a poor substitute for real
leadership. Perhaps an admission of abject failure even to compete?
- [ A Cadence Employee ]
Editor's Note: I've omitted this person's name to protect his job. - John
---- ---- ---- ---- ---- ---- ----
From: Mark Wroblewski <markwrob@colorado.cirrus.com>
John,
Nice column! You get some of the "inside info" I don't, such as the senior
officers of the acquired companies taking apparently substantial roles at
Cadence. Let's hope that continues to hold, it could mark that Cadence will
keep the groups innovating.
- Mark Wroblewski
Cirrus Logic Broomfield, CO
---- ---- ---- ---- ---- ---- ----
From: Vladimir Orlt <Orlt.V@ems-t.ca>
John,
It's nice to read about positive stories coming out of what seems to be a
generally dismal EDA industry.
- Vladimir Orlt
EMS Technologies Ste. Anne de Bellevue, Quebec, Canada
---- ---- ---- ---- ---- ---- ----
From: Scott Hamm <scott@fulcrummicro.com>
Nice column, John.
- Scott Hamm
Fulcrum Micro
---- ---- ---- ---- ---- ---- ----
From: Eric Lin <elin@celestry.COM>
John,
I thought Ray worked for Red Lion Inn and not Red Roof Inn. Can you
double check? I could be wrong.
- Eric Lin
Celestry
---- ---- ---- ---- ---- ---- ----
From: Louis Mac <louispmac@yahoo.com>
John,
I liked your info on Cadence's talent pool - but what little I know of the
business stuff - I think Cadence had to go into crisis mode and go out and
buy all these people in a pinch. My colleagues were saying last year that
Cadence physical design tools were going to fall off a cliff soon !?!?!
So Cadence acquired a bunch of companies ASAP to cover their butts.
All I know is that I am years away from an integrated, real common database
back-end flow from Cadence, yet I'm stuck using it for now. Anyway, my boss
never calls me a genius when I have to pull a rabbit out of the hat to
finish my chips, and he never gives me a ton of money to cover the situation
either.
- Louis Mac
---- ---- ---- ---- ---- ---- ----
From: Jim Tully <jim.tully@gartner.com>
John,
Great piece!
- Jim Tully, Chief Analyst
Semiconductor Group
Gartner/Dataquest Egham, Surrey, UK
---- ---- ---- ---- ---- ---- ----
From: Dale Hayes <dale@simplex.com>
Hi, John,
I'm happy to see Tom Kronmiller recognized in your article. He's a pretty
smart guy, keeps a low profile, and is incredibly valuable in what he
produces -- plus he lives in North Carolina (though he hasn't quite acquired
the accent, we're still working on him.)
Oh, BTW, one small correction on Bingham's bio. It was Red LION Inn.
- Dale Hayes
Simplex Cary, NC
---- ---- ---- ---- ---- ---- ----
From: John Jensen <john.s.jensen@intel.com>
John,
Great article.
- John Jensen
Intel
( ESNUG 396 Item 9 ) --------------------------------------------- [07/11/02]
Subject: ( ESNUG 395 #9 ) VHDL <-> Verilog Or Vera <-> Verisity Xslators
> What vendors out there are offering translators for VHDL <-> Verilog or
> Vera <-> Verisity?
>
> - Bill Billowitch
> Agere Systems Allentown, PA
From: Thomas Bollaert <tbollaert@sd.com>
Hi John,
Summit Design provides VHDL <-> Verilog translation as well as design
documentation and design reuse features as part of our Visual Elite
design environment.
- Thomas Bollaert
Summit Design Cergy Pontoise, France
---- ---- ---- ---- ---- ---- ----
From: janick@qualis.com (Janick Bergeron)
Hi, John,
It is very unlikely one would be able to translate Vera <-> e. The two
languages are just too different in their approach.
VHDL and Verilog are *much* simpler in their syntax and semantics, yet one
cannot find a translator that supports anything beyond the RTL subset (which
is *really* simple).
- Janick Bergeron
Qualis Design
( ESNUG 396 Item 10 ) -------------------------------------------- [07/11/02]
From: Eitan Zahavi <eitan@mellanox.co.il>
Subject: DW Artifacts Will Mess With Your PrimeTime SPEF Reader Runtimes!
Hi John,
I think there might be some other poor guys who would be interested in this:
We were unable to use PrimeTime versions past 2000.05 since reading
parasitics (SPEF files) has degraded by more than 2X on regular blocks and
got to over 2 days for the top level.
We just realized what was the problem.
For some reason dc_shell generated instances named something like:
a/b/*cell*/c
These are DesignWare artifacts to our best understanding. These "*" were
causing the slow down. Once removed our runtime improved dramatically.
- Eitan Zahavi
Mellanox Technologies LTD Yokneam, ISRAEL
( ESNUG 396 Item 11 ) -------------------------------------------- [07/11/02]
From: Gregg Lahti <gregg.lahti@corrent.com>
Subject: Surprise! VCS 6.2 FCS Doesn't Support gcc On 64-bit Solaris!
Hi, John,
I've been using the VCS 6.2 beta versions for the past few months. I've
been pretty impressed with the compile & sim speeds of the newer releases,
so that really got me motivated to use the VCS 6.2 FCS version that was
just announced. Surprise! VCS with gcc is not supported for 64-bit
compiles on Solaris! After many emails between tech support, I've been
told that for 64-bit Slowaris, only the Sun C compiler is supported and
gcc will be supported "in the future" with no anticipated release date.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 396 Item 12 ) -------------------------------------------- [07/11/02]
From: Carla De Leo <carla.deleo@acco-ic.com>
Subject: How Can I Convert A Cadence Diva DRC File Into A Dracula DRC File?
Hi John,
I just want to ask you if it is possible to convert a Cadence Diva DRC file
into a Cadence Dracula DRC file? Are the differences between the two types
of files only syntact differences or what?
- Carla De Leo
ACCO SA Saint Germain en Laye, France
( ESNUG 396 Item 13 ) -------------------------------------------- [07/11/02]
From: Kevin Croysdale <croysdal@synopsys.com>
Subject: graph_log -- A Graphical Perl Log Script For PhysOpt And DC Users
Hello John,
I wanted to share with your ESNUG readers a Perl script that I wrote for
analyzing the results of a PhysOpt or Design Compiler run. This script
creates a graph of the various design metrics from a DC/PhysOpt log. It
does this by plotting WNS, TNS, DRC, and AREA over time using logs
generated by compile_physical, physopt, or compile.
This script provides an easy to understand graphical view of the progress
PhysOpt/Design Compiler has made optimizing a design. The graph displays
each optimization stage using a different color.
Delay Optimization - white
Design Rule Fixing - red
Timing Optimization - blue
Legalization - violet
Area-Recovery - green
These graphical plots can be used as aids in visually analyzing & debugging
compile runs, on top of the detailed textual information that is already
present in the optimization logs.
The script uses as its input a log file from PhysOpt or DC. It will pull
up interactive graph windows by default.
Usage: graph_log [-wns] [-tns] [-drc] [-area] [-help]
-wns : graph WNS over time
-tns : graph TNS over time
-drc : graph DRC over time
-area : graph AREA over time
If no -wns, -tns, -drc, or -area options are given, then all are plotted.
I have provided a winzip file that your readers can download. There's also
a README file that describes the installation procedure and files contained
in the winzip file.
John, please encourage your readers to give this script a try. I can't
guarantee that it is perfect, but it has been used on over 100 different
log files this past year and it really helps.
- Kevin Croysdale
Synopsys, Inc. Hillsboro, OR
[ Editor's Note: I'll put Kevin's graph_log PhysOpt/DC script into the
Downloads section of http://www.DeepChip.com for downloading. - John ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,063 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
|
|
