Editor's Note: Recently I got a very large UNIX-workstation-sized box
delivered to my farm with very explicit directions that only "John Cooley"
should open it. My girlfriend freaked yelling: "Oklahoma! Aaaah!
Unabomber! Aaaaaah! It's a big bomb!!! Aaaah!" -- but the hope that
*finally* someone had sent me a UNIX workstation for use on the farm blinded
me to any fears of the box exploding. I greedily opened it only to find:
To: The "Real" Harvey & Aart
c/o John Cooley, Holliston Poor Farm, PO Box 6222, Holliston, MA 01746
Dear little Harv & Aart,
We were honored last Christmas to hear that your Uncle John had named
you after us. We thought you might like to have a picture of your
Synopsoidal namesakes to hang in your barn. The enclosed photograph
was taken when Uncle Harvey was young and thinnner and Uncle Aart had
a mustache and was more technical. Also enclosed is a 50 lb bag of
TOP GOAT (feed grain); we hope you kids enjoy it!
Aart J. de Geus Harvey C. Jones
President & CEO Chairman of the Board
My girlfriend laughed & said "Oh, honey! How nice of them!" while reading
the letter. I was still a little bummed because I risked our lives for a
50 lb bag of goat food & a framed photo. I groped in the styrofoam packing
in the box hoping to find the other note saying "P.S. We have a nice big
workstation waiting for you to pick up at our Boston office! Merry X-mas!".
I couldn't find it. (Damn!) :^(
- John Cooley
the ESNUG guy
( ESNUG 231 Item 1 ) ---------------------------------------------- [12/8/95]
From: vito@synopsys.com (Vito Mazzarino)
Subject: Deadline Extended For SNUG '96 Papers
John,
I just wanted to drop you a quick note to tell you that the deadline for
submitting abstracts for next year's SNUG '96 meeting has been extended to
Friday, December 17th. Please tell the ESNUG readers that we could use more
papers on either design verification or using LMC models. Also, there seems
to be some sort of wrong assumption that just because Synopsys currently
only offers a VHDL simulator that SNUG '96 doesn't want Verilog based papers!
(This couldn't be more wrong!!!!!) Users should e-mail abstracts for
proposed papers directly to me at "vito@synopsys.com"
- Vito Mazzarino
Synopsys SNUG'96 Chair
( ESNUG 231 Item 2 ) ---------------------------------------------- [12/8/95]
Subject: ( ESNUG 230 #5 ) Is Synopsys Killing Schematics In Design Analyzer?
>I would like to ask Synopsys users on ESNUG to speak out if anyone has used,
>or desired to use, the schematic cross probing feature of Design Analyzer.
>Or maybe would have used it if it was less buggy. Anyone out there???
>
>I ask this because Synopsys is/has been removing support for schematic cross
>probing, and apparently schematic support in general from Design Analyzer.
>I have been told that this is because no one uses schematics in Design
>Analyzer. I was hoping to make use of it for gate level debugging. Now we
>are required to generate schematic plots. Does anyone care that we pay
>maintenance to have a company *remove* useful features?
From: peer@iis.fhg.de (Dieter Peer)
We regularily use the schematic capabilities of Design Analyzer - very
often in order to _understand_ critical paths or weird simulation results.
Due to different sdf delays before and after layout or to understand the
scan chain this grafical aid is extremely helpful. Synopsys should not take
it away.
- Dieter Peer
Fraunhofer-Gesellschaft Institut fuer Integrierte Schaltungen
---- ---- ---- ---- ---- ---- ----
From: taimei.dezeeuw@tempe.vlsi.com (Taimei E. DeZeeuw)
John,
What is the use of Design Analyzer without schematics and schematic probing?
The majority of users are scripting everything and using dc_shell to do
development, but when there is a problem that's when Design Analyzer is
useful. I have found these features to be very helpful in debugging designs.
I would hate to see anyone try to go to schematic hardcopy or searching
through a netlist. Isn't this moving drastically backwards in time? I would
hope these features would not go away.
- Taimei E. DeZeeuw
VLSI Technology, Inc.
[ Editor's Note: Taimei & Dieter, I agree with you 100%! I use the schematic
feature constantly in my consulting practice to get a quick look at what's
causing my client's problems synthesis-wise. Design Analyzer is a lot like
the EDA equivalent of an oscilloscope -- it let's me see the raw gates.
Synopsys removing schematic viewing would be just plain stupid! - John ]
( ESNUG 231 Item 3 ) ---------------------------------------------- [12/8/95]
Subject: (ESNUG 229 #2 230 #2) "Is Synopsys Floorplan Manager Worth It?"
>I would like to point out that, in my opinion, the wire load calculation
>algorithm used by FM has one flaw. When computing wire load models for
>higher level design units (major blocks of the chip) the tool incorrectly
>includes all net that exist at lower levels of hierarchy thus giving a much
>more optimistic estimate (lower than actual) than the real capacitances. I
>found it to be over 200% off for nets that exist at top level of a chip
>(nets interconnecting large blocks). BTW, we have reported this issue to
>Synopsys that it's a flaw but they are not motivated to fix it.
From: jaym@hpcvcdt.cv.hp.com (Jay McDougal)
John,
I agree that "generic" wire load models can be vastly improved for a given
design. Also, you may want to be more pessimistic or optimistic than a
standard model depending on your design methodology and goals. However, all
that is needed to create a custom wire load model is a simple unix script
that calculates statistical data from a file of wire loads and fanouts. The
model itself can be compiled without a library compiler license -- that is,
if you have Library Compiler you don't need Floorplan Manager here. The
advantage of a unix script is you can modify the algorithm you use to create
your wire load model for any special cases you have and you can easily run
it on wires from different levels of hierarchy to get around the problem
mentioned above.
- Jay McDougal
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: jeffb@asic.mtv.nec.com (Jeff Buckles)
John,
It sounds like what you are getting is analogous to the set_wire_load "-mode
top", when what you want is "-mode enclosed". So I think this would only
happen if you dont use the "-hierarchical" switch to create_wire_load. By
describing a module and all of it's sub-modules as a single cluster (no
-hier switch), you have essentially "flattened" that module for the purpose
of wire load estimation. So it *must* take into consideration all of the
nets in the hierarchy. And if this is a cluster rather than a hierarchical
block, then it is conceivable that the cells in the lower levels could end
up spread out to various regions throughout that floorplan group.
I found that by using the "-hierarchical" switch to create_wire_load, it
created wire loads that were analogous to "-mode enclosed". That is,
top-level wire load models were based only on nets that came all the way
up to the top level.
Even so, since your wire-load models were based on a full route, and, as
I've seen that the postlayout spread can be higher than 6 to 1, I think
2 to 1 is pretty darn close!
The only true timing is postlayout timing. Everything else is a "best
guess". We can play games with the numbers to try to make our guesses
better, but it's still only a guess. I think that custom wire load
models did a good job of moving the guess closer to postlayout reality
by taking into consideration more data about my specific design.
The best that we can do is find some way to easily fix the problems
that fall out of the statistical model. And I'm satisfied that the
postlayout capabilities of Links To Layout addressed these problems
very well. I hope this doesn't sound too much like Synopsys marketing
hype, and I was as skeptical as any one when I set out to use it. But
it let me sleep at night. What else can I say?
- Jeff Buckles
NEC Electronics Inc.
---- ---- ---- ---- ---- ---- ----
>Most ASIC vendor's libraries provide a set of wire load models that are
>grossly inaccurate (or have huge margins built in). If you design to
>these targets you will be very hard pressed to meet your timing goals for
>high frequency designs. We use the Floorplan Manager to generate custom
>wire load models after a trial layout to get a good wire load model. This
>helps us fine tune the synthesis results for a better pre- and post- layout
>(actual layout for sign off) correlation. Our experience has been that
>(for various reasons) the models in vendor libraries are up to 200+%
>inaccurate. With Floorplan Manager generated models you can come within 25%
>of actuals. Custom models reduce post-layout surprises & design iterations.
From: jeffb@asic.mtv.nec.com (Jeff Buckles)
John,
As this user pointed out, Floorplan Manager's Links-To-Layout can be used
to create custom wire load models for use during prelayout optimization.
However, I would not say that the vendor supplied wire-load models are
"inaccurate".
Let's call a collection of gates a "group". This "group" can be a
hierarchical module and all of it's submodules; it can be only the
top level of a hierarchical block, or it can be set of cells that
are constrained to a specific physical region of the layout (floor-
plan cluster).
The vendor supplied wire-load model is simply a 2d table in which one axis is
the number of cells in the "group" and the other axis is the number of
fanouts on a net within that group. For example, for any group with G gates,
the statistical wireload model will predict a wire-load of W for all nets
with fanout F ( W = f(F,G) ). This can be illustrated in the following graph
of wire-load vs. fanout, in which all nets of fanout F get the same wire_load
W. (Each "X" represents many nets.)
Statistics for Wire load 'example_from_real_life':
( 1 character = 0.01 capacitance units )
load "W"
1-------10--------20--------30--------40--------50--------60
f 1 X
a 2 X
n 3 X
o 4 X
u 5 X
t 6 X
"F"
Now, here's the reason for the conservatism in the vendors' wire-load models.
In a real postlayout design, every net with a fanout of F will obviously not
have the same wire load. In fact, in one test case I found more than 6 to 1
range in wire-load for nets with the same fanout within the same "group".
So the vendor is burdened with choosing a value that is not *too*
conservative, but also takes into account those few nets that "blow-out" to
some ridiculously large value (which seem invariably to fall within the
critical path :( ) Here's what that example looked like postlayout.
Statistics for Wire load 'example_from_real_life':
( 1 character = 0.01 capacitance units)
load "W"
1-------10--------20--------30--------40--------50--------60
f 1 ...X.....
a 2 ......X..............
n 3 ............X............
o 4 ...........X................
u 5 .......X....................
t 6 ..........X...................
"F"
Note the spread on low-fanout nets. What single wire-load model could
be chosen to represent this during prelayout opt.? In order to be
usable, the wire-load model must tend toward conservatism, but they
will inevitably be too aggressive for some specific instances.
The same problem exists using custom wire load models. We're trying to
cover a wide range of possible results with a single estimated value.
The only difference is that the statistics are based on one specific
design (yours), rather than on a composite of many different unrelated
designs chosen by the vendor. The greatest benefit occurs, I think,
when you can use cluster based wire load models, rather than basing
them on logical hierarchy.
> The PDEF interface is a useful feature that allows you to have different
> physical and logical hierarchies. So far have not have a need to use it.
The ability to describe the physical grouping was essential to us being
able to perform reoptimization from the floorplan and from the layout.
I tried back-annotating without the clusters, and the estimated timing
tended to be too aggressive. This was especially evident where the
"boundary" between floorplan groups did not occur at a single level in
the logical hierarchy. For prelayout custom-wire-load generation, I
agree that clusters are optional (though I recommend using them), but
for postlayout, I wouldn't have it any other way.
- Jeff Buckles
NEC Electronics Inc.
( ESNUG 231 Item 4 ) ---------------------------------------------- [12/8/95]
From: greg@cqt.com (Greg Bell)
Subject: There's Even A Clever Way To Work Without Library Compiler!
Hi John,
Here's a way you can do a lot of library-like fakeouts without even having a
Library Compiler license. I believe the only thing you can't do is have
cell functionality described in your library. (Hopefully this isn't a
convenient freebie "bug" that I just broadcasted to Synopsys' corporate
offices so that it'll be fixed in the next release. Doh!)
In other words, you can create fake cells with high drive, RAM cells for
timing through black-box RAMs (see SolvIt), etc. To read the library in, do
a read_lib <sourcename>. You'll get an error about not having the Library
Compiler license, but it will then complete with a "Technology library read
successfully" message. Then do a write_lib <libname> -output <libname>.db
to save it out. For reference, here's an example of some library source
that can be compiled:
library(manly_inverter) {
technology (cmos);
default_output_pin_rise_res : 0.1;
default_output_pin_fall_res : 0.1;
date : "Oct 5, 1995";
revision : 0.1;
time_unit : "1ns";
voltage_unit : "1V";
current_unit : "1mA";
pulling_resistance_unit : "1kohm";
capacitive_load_unit (1000, ff);
cell (manly_inverter) {
area : 10 /* area of cell */
pin(i) {
direction : input
capacitance : 0.060 /* capacitance of pin */
fanout_load : 0.060 /* fanout load */
}
pin (zn) {
direction : output
max_fanout : 1000
timing() {
intrinsic_rise : 2.000000 /* intrinsic delay of A1 to Z1 */
intrinsic_fall : 2.000000
rise_resistance : 0.000000 /* drive strength of output port */
fall_resistance : 0.000000
related_pin : "i"
timing_sense : negative_unate
}
}
}
}
Because we had gated clocks and Synopsys doesn't treat the clock *network*
as ideal, just the clock port, we had to create a super-high drive buffer
and put it after the clock gate for each sub-module. This is replaced by
a clock tree at the P&R stage.
- Greg Bell
CommQuest Technologies, Inc.
( ESNUG 231 Item 5 ) ---------------------------------------------- [12/8/95]
Subject: ( ESNUG 228 #1 ) How To Piss Off Salesman By Minimizing DW Useage
>Here's an example way to minimize usage of DesignWare licenses (in this case
>"SynLib-ALU") that may be of interest to ESNUG readers. When compiling for
>the first time, HDL-Compiler may call up a SynLib-ALU license to get the job
>done. Under many circumstances the compiled design is then written out in a
>hierarchical format, with DesignWare components written out as separate
>submodules in the compiled netlist. The problem comes when you want to
>re-optimze the design for timing, or whatever ... the previously compiled
>hierarchical design with DesignWare components is read in, it will
>automatically tie up SynLib-ALU license and potentially cause other
>designers to wait, or pay more money for another license! To get around
>this, simply write out all designs to be re-compiled as *flat* netlists.
>This eliminates the DesignWare component reference in the module names and
>also stops Synopsys from calling up the "SynLib-ALU" license on a re-compile
>of structural code inside these designs.
From: [ A Synopsys DesignWare R&D Engineer ]
Hey John,
The behavior the user describes (DC requiring a SynLib-ALU license upon
subsequent compiles of designs containing DesignWare parts) allows DC to
revisit the implementation choices for each DesignWare part to see if by
changing the implementation a better circuit can be created. We call this
incremental implementation selection (IIS), and it was created by the
DW engineering team as part of our general charter to improve synthesis
Quality Of Results through automated design re-use.
IIS is a nice feature, because it enables architectural decisions to be
re-made as the synthesis of your chip progresses. In most hierarchical
compile approaches there is some form of time budgeting performed (either
by the user or using characterize); as a design progresses the budgets on
individual blocks often change, due to optimizations made within other
blocks. If these budgets change significantly it may warrant revisiting
an earlier implementation decision; normal logic-level optimization cannot
easily compensate for an incorrect implementation choice.
This user's suggested approach will help reduce the demand for DW licenses,
BUT it comes at some potential optimization expense! A flattened DW part
cannot have its implementation re-selected, so you're stuck with the initial
implementation choice (good or bad.) Synopsys users should be warned of
this trade-off should they decide to follow the approach!
- [ A Synopsys DesignWare R&D Engineer ]
( ESNUG 231 Item 6 ) ---------------------------------------------- [12/8/95]
From: Lev.Tal@ecitele.com (Lev Tal)
Subject: The Bewildering World Of Embedded Multiport RAM Arrays
Hi, John,
We are designing ASICs that include embedded multiport RAM arrays, which
require using vendors' libraries. The problem is that different vendors
offer different RAM cells:
1. Sizes: some vendors (such as LSI Logic) offer RAM compilers, while
others offer standard sizes. Needless to say, there is no standard
for these "standard" sizes.
2. Synchronous / asynchronous: again, no standard. Seems that the
future trend is to support only _synchronous_ RAMs.
3. Number and type of ports: 2-port? 3-port? Are these ports all R/W,
or whether some are read-only or write-only?
4. Controls: WE and OE control inputs - per bit, or per word?
We are trying to find a common base, so as to define a common model of the
RAM cells that will yield a design compatible with all (or most) vendor
libraries, present and future (some sort of an "industry-standard" RAM cell).
The common model seems to be: synchronous, 2-port (one read and one
read/write), one WE and one OE control input per word. Does this model make
sense? Can one define such "industry-standard" RAM cells? What do vendors
plan to support in the future?
- Tal Lev,
ECI Telecom.
( ESNUG 231 Networking Section ) ---------------------------------- [12/8/95]
Dublin, Ireland - Massana seeks DSP ASIC Design Engineers w/ exp. in DSP/HDL
& Synthesis based ASIC design. No Agencies. "paul.costigan@massana.ie"
|
|
