One of the unexpected reactions I got from the intro to this year's ESNUG
DAC Awards (where I compared pensive engineers to live-for-the-moment
truckers) was that 5 engineers replied with "colorful" anecdotes about
what *they* saw at DAC. One reprintable example:
"John I guess that I hung out with the wrong crowd. After the Mentor
party we went straight to the strip clubs wearing our new white
Mentor shirts and carrying our stuffed "Network" dogs. Everywhere
I looked in the club I saw white shirts and good ol' Network. The
Sun campaign for the little doggie is "Network is everywhere" and,
let me tell you, when the dancers got of hold of the many stuffed
dogs, <YOWL!> he was indeed everywhere! Lucky dog..."
And a sixth engineer has been mailing me his selected favorites from
the "alt.sex.stories" newsgroup. (oh, joy.)
- John Cooley
the ESNUG guy
( ESNUG 241 Item 1 ) ---------------------------------------------- [6/96]
From: chrisd@Synopsys.COM (Chris Dace)
Subject: SNUG Europe Call For Papers
Hello John,
This is the annual Call for Papers for the SNUG Europe event to be held in
Geneva, Switzerland on September 19th. This year we are aiming for 22
user presentations, each of approximately 20 minutes duration on:
* Design Productivity in RTL Synthesis * Higher Levels of Abstraction
* Deep Submicron Design *Verification Experiences * Logic Modeling
Should anyone wish to discuss a potential contribution, please feel free to
contact your local applications engineering manager or me.
- Chris Dace, the SNUG Europe '96 Programme Chair.
Tel: +44 1734 313 822 or "chrisd@synopsys.com"
( ESNUG 241 Item 2 ) ---------------------------------------------- [6/96]
From: bodack@sican.de (Ruediger Bodack)
Subject: Is Anyone Using The Synopsys ECL Compiler?
Hi John,
Do you know anybody who uses Design Compiler for ECL? The people at the
Munich support center told me that ECL is not supported since 3.1a. However
by browsing the library compiler books in iview I found a lot of features
for ECL libs in 3.4a. If ECL is not supported, why is it still in the
latest version of the Library Compiler? Is anybody doing great ECL designs
in a very secret lab with 3.4a and I just do not have the licenses?
- Ruediger Bodack
SICAN GmbH
( ESNUG 241 Item 3 ) ---------------------------------------------- [6/96]
Subject: ( ESNUG 240 #4 ) Backannotation Isn't Used By Floorplan Manager?
> My problem: I read in cluster files (PDEF) and 'set load' scripts & select
> a custom wire load model. When I do 'report_timing' from the *top level*
> of the hierarchical design I get indication about the clusters in the
> report & negative slack time. Yet when I do 'report_timing' *inside* a
> big module that I want to reoptimize (the whole design takes days) there
> is no indication that the report is using any backannotated data leaving
> my slack time positive!!?? (Likewise, 'reoptimize_design' on the sublevel
> finishes without doing much. I have the feeling that the backannotated
> data is not considered on any level other than the top level.)
From: rray@msai.mea.com (Russell Ray)
I'm not an expert on what is really happening but I ran into this same
problem with only using set_load and set_resistance commands. It appears
that the loads are only visible if the current design is set to the same
design as whey you performed the set_load commands. When the current design
is anything else, they are not taken into account.
The large amount of time spent re-optimizing is due to the fact that it is
off re-timing the design and using the wire_load models in the library being
used rather than seeing the back annotated information.
We had to use the characterize command from the top level to perform lower
level optimizations after back annotation. This seemed to be the only way
to get the back annotated data into our "compile -in_place_optimization".
- Russell Ray
Mitsubishi Semiconductor America, Inc.
---- ---- ---- ---- ---- ---- ----
From: rnair@BayNetworks.COM (Rajesh Nair)
John,
Design Constraints, Timing constraints and any Backannotated parameters will
only apply in the context of the design to which it was applied. (Because
one could potentially be using the same subdesign in other designs or in
another context in the same design. In this case, you would not want the
backannotated value from the previous design to be present any more.)
In order to propagate constraints to a design down the hierarchy, you will
need to use the 'characterize' command on the particular instance from
your top level design.
- Rajesh Nair
Bay Networks, Inc.
---- ---- ---- ---- ---- ---- ----
From: Andrew Inness <ainness@asic.sc.ti.com>
Hi John,
Yes, the custom wire load models created by Floorplan Manager are only used
by the same level that they were created at. This is similiar to the problem
that when constraints are annotated to a sub-block, they must be re-annotated
when you change levels of hierarchy. They will still be visible when using
the current_instance command to change levels of hierarchy for timing
reports, but they can not be used by the reoptimize_design at any other level
than where they were created.
There are two ways around this. One is to create the custom wire load models
from the top level, and then reassign them at the sub-level (with the
set_wire_load command) when needed. The main problem with this would
approach is that there may be a large number of models that would have to be
manually set all through the hierarchy. The second option would be to
use a script (either provided by your Si vendor, or written inhouse)
that will modify the set_load script to annotate the capacitance values
to whatever level of hierarchy that is needed, and then create the
custom wire loads at that level (for use with the reoptimize_design command
as well as the timing reports).
- Andy Inness
Texas Instruments, ASIC Applications
( ESNUG 241 Item 4 ) ---------------------------------------------- [6/96]
Subject: ( ESNUG 240 #3 ) What Does Power Compiler Really Get Us Power-wise?
> I'm mystified, so I need some assistance. I don't see why Synopsys is
> putting so much effort into marketing Power Compiler. My experiments with
> many designs (>20) show that core power typically accounts for less than
> 25% of the total chip power, with I/O and clock macro power the two
> biggest consumers. If that is true, what difference will a few percent
> saving from the core make? Is it worth buying an expensive tool? Are
> there design examples that show a significant overall power savings?
From: [ Synopsys' Sr. Low Power CAE ]
Hi John,
Specifically regarding power dissipation in clock networks; Power Compiler
does perform power optimization on the clock network. Power on a clock
network has two major components:
1. Power dissipation in clock buffer network (clock net + clock buffers)
2. Power dissipation within the driven elements (i.e sequential cells)
This power is the power dissipated internal to sequential elements
during clock transitions. Note that Power Compiler models the
situation when the clock transitions but the flip-flop output does not.
Power Compiler will work to reduce the power consumption in both the clock
buffer network (minus clock generator) and in the sequential elements.
Power Compiler will select (based on the switching activity, timing and DRC
constraints) the lowest power implementation for each sequential element
without violating timing or design rule constraints. Power Compiler will
also configure lower input pin capacitances (without violating timing or
design rule or clock skew constraints) for the cells connected to clock
network to reduce the power dissipation in clock network.
As pointed out by the user, I/O may be responsible for a significant
fraction of the total power dissipation, and design engineers may have
little flexibility to change I/O characteristics that are constrained by
system specifications. In these situations, core power reductions may
be the designer's only opportunity. In most applications where reduced
power consumption is a primary objective, system specifications will
reflect this goal by accomodating low-power I/O and memory technology,
as well as low-voltage power supplies. After the big power consumers
such as I/O and embedded memories have been addressed, core power
reductions represent a larger fraction of the the total power dissipation.
The solution which Synopsys currently offers starts with a gate level power
analysis tool (DesignPower). Using this tool, designers can analyze their
RTL architectures and perform "what if?" analysis. It is at the RT level
where significant reductions in power consumption can be achieved. It is
somewhat a manual process today.
Once a low power RTL has been selected, Power Compiler provides for an
additional push-button reduction in power. Power Compiler optimizes both
the sequential logic as well as the combinational power dissipation in the
synthesized portions of your design. These gate-level tradeoffs are done
automatically and doesn't introduce downstream issues such as testability
or clock tree synthesis problems.
Power Compiler is integrated with Synopsys' Links-to-Layout methodology.
All of synthesis is now power sensitive, including reoptimize_design with
Floorplan Manager. This means that after back-annotation of parasitics from
floor-planning, the critical path reoptimization and area recovery
algorithms are power sensitive (activity based). The ultimate result is the
lowest power implementation within your timing constraints.
- [ Synopsys' Sr. Low Power CAE ]
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
The basic reason why I was giving such excited comments about Power Compiler
was that it was the first tool to *pro-actively* enable designers to reduce
power consumption. That is, virtually all the currently available power
related EDA tools only do analysis and leave the designer with the classic
Oh-shit!-we-gotta-go-back-to-the-beginning-to-fix-this problem. Yea, sure,
a 10 - 15% power reduction may be chump change, but it's a beginning. I've
been on more than a few ASIC design projects where this would have saved us.
- John Cooley
the ESNUG guy
( ESNUG 241 Item 5 ) ---------------------------------------------- [6/96]
From: gmann@ford.com (Greg Mann)
Subject: Looking For A Lazy Way To Deal With Interblock Timing
John,
I'm looking for a method to determine the worst paths in a multi-block design
without reading the entire design into memory and generating timing reports
at that level. (Each block of a rather large design is being compiled
separately and a timing report is generated for it based on the constraints
for the block.) Of course, some of the timing paths will include more than
one block, so the slack numbers reported in each report tell only part of
the story. For such a path, we need a combined slack value to be able
to accurately rank it with other paths in the design. The approach I'm
looking at is the following:
1) Determine the connectivity between modules.
2) Associate reported timing paths from the different
modules based on the connectivity.
3) Combine associated timing paths and report a total
slack value for the total path.
Before I go too far, I was wondering if anyone else had encountered this
problem (or part of it) and had developed a solution. Help!
- Greg Mann
Ford Microelectronics
( ESNUG 241 Item 6 ) ---------------------------------------------- [6/96]
From: celiac@teleport.com (Celia Clause)
Subject: Celia's Script To Find Clock & Data Pins Coming From The Same Logic
Hi, John! Here's a script I recently wrote to find clock and data pins
that originate from the same logic:
CELL_LIST = {}
all_registers -edge
cells = dc_shell_status
foreach(latch,cells){
data_pin = latch + "/D"
clock_pin = latch + "/C"
all_fanin -to data_pin -flat -start
d_pins = dc_shell_status
all_fanin -to clock_pin -flat -start
clk_pins = dc_shell_status
match = false
foreach(dip,d_pins) {
foreach(ckp,clk_pins) {
if (ckp==dip){
match = true
}
}
}
if(match==true) {
CELL_LIST = CELL_LIST + latch
}
}
echo CELL_LIST
I figured that someone else might find that this would come in handy...
- Celia Clause
RadiSys
( ESNUG 241 Item 7 ) ---------------------------------------------- [6/96]
From: [ Mr. Don't-Know-What-To-Do ]
Subject: We Like Avant! But Don't Know How To Handle The Legal Hassles
Hi John -- Please keep me anonymous on this, OK?
We're currently looking at setting up a proper n-layer routing
environment as we need to do something to convert cute Synopsys-synthesized
schematics to real abstract colourful artwork which layout guys can poke at.
We currently have Cadence's Cell Ensemble but this is proving too slow,
results are proving too large, etc. etc.
We've looked at a couple of products and even asked some vendors to try out
one of our 60K gate designs. Compass still haven't come back with
Pathfinder results. Cadence Cell3 results are fairly impressive (12%
smaller than our Cell Ensemble and the job took about 1/30th of the original
P&R time!) Avant! ArcCellBV and ArcCellXO were both even better than Cell3.
Moreover we were able to bash on the ArcCell keys ourselves & get results.
Avant! looked like clear winners in terms of ease of use, DSO (design-size
optiization), raw results, etc.
Then Cadence stepped up with their Silicon Ensemble and PBS (placement-based
synthesis) which looked set to end the days when a designer ping-ponged
between synthesis and layout. Avant! responded with Solar which sounds even
better than PBS.
Our problem is how can we do business with the Avant!/Cadence lawsuit
looming? Is there any way an Avant! customer can get burned if they lose?
- [ Mr. Don't-Know-What-To-Do ]
( ESNUG 241 Item 8 ) ---------------------------------------------- [6/96]
From: kevind@shannon.tellabs.com (Kevin Dewar)
Subject: 'X's Along With Verifying VHDL RTL vs Gates
Dear John,
Our problem is in the handling of 'X's in comparison statements. As we see
it, the use of the built-in comparison operators in VHDL will force the
multi-valued logic through a boolean type "funnel" in a way that the designer
may not have intended and can easily be unaware of.
The effect is that designers can very easily be lured into a false sense of
security by simulating RTL that has been written with IEEE 'std_logic'
multi-value signals and assuming that unknown values will be handled in a
correct manner. They won't, so the gates can simulate differently from the
RTL (but the gates are correct). (A lot of people must think that this
RTL/gates mismatch is a synthesis problem.)
For example, this (Case 1 below) will correctly handle the situation where
check_bit='X' (as long as 'data_valid' has the appropriate value):
if (check_bit /= '1' and data_valid='1') then
fail_reg <= '1';
end if;
Yet this (Case 2 below) will treat a check_bit of 'X' or 'U' as a failure
which will highlight the fact that there is a problem with the logic. This
is found in the RTL simulations:
if (check_bit /= '1') then
fail_reg <= '1';
end if;
And this (Case 3 below) will treat a check_bit of 'X' or 'U' as a pass which
will obscure the fact that there is a problem with the logic. The RTL will
appear to work!
if (check_bit = '0') then
fail_reg <= '1';
end if;
This will synthesise to the same gates as Case 2 (when the problem will be
found -- but be much more difficult and time-consuming to debug).
We probably don't want to have to write the RTL shown below everywhere but
how else can we find this class of bug before synthesis?
if (check_bit = '0') then
fail_reg <= '1';
elsif (check_bit = '1') then
null;
-- synopsys synthesis_off
else
fail_reg <= 'X';
-- synopsys synthesis_on
end if;
We had hoped that we could run all of our verification runs at the RTL level,
and only a handful of functional tests, with timing information to ensure
that the synthesis was OK, at gate level. Now though it looks like we may
need to run all the verification tests at the gate level. Is there a
better way?
- Kevin Dewar & Brendan O'Dowd
Tellabs Ltd., Ireland
( ESNUG 241 Item 9 ) ---------------------------------------------- [6/96]
From: [ Prisoner of Zenda ]
Subject: Will Trade My Secret Switches For Yours!
John, I don't want to get hassled for this by Synopsys. No names, OK?
I'd like to see more secret switches "exposed" in ESNUG. In trade, here's
mine: I was having headaches with Synopsys putting in unnecessary buffers.
(I figured out that there was no capacitance, fannout, or timing problem, but
I was still getting two inverters on each output.) Here's the fix:
/* clean up unnecessary inverters */
compile_clean_inverters = true
(Sure enough. My extra inverters went away. I am wondering why Synopsys
hasn't published this switch. Could there be some sort of side effect?
So far, I have had no problems with it.) Has anyone else found any helpful
undocumented features that they would like to share?
- [ Prisoner of Zenda ]
( ESNUG 241 Item 10 ) --------------------------------------------- [6/96]
From: krug@avionics.itt.com (Eric Krug)
Subject: Seeking "Gotchas" Using Mixed Mode Cadence With LMC Models
Dear John,
I am currentlydoing a mixed-signal simulation using Cadence Concept, Logic
Work Bench (used in Mixed Signal mode), Leapfrog, and Verilog-XL (all of
which are from release 9502.)
The Synopsys LMC models I'm using include the old-fashioned Verilog
Smartmodels (Release 39) and the generic SWIFTModels (Release 40). We are
in the process of obtaining and installing SWIFTModel Release 40b (this has
Concept symbols for the devices being modeled) and VHDL SWIFTModel Release
8. (I do not intend to use the Verilog models because they will not be
supported after this year.)
What are the gotchas in this approach?
- Eric Krug
ITT Industries
|
|
