( 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.
|
|
