( ESNUG 230 Item 2 ) ---------------------------------------------- [11/16/95]
Subject: (ESNUG 228 #10 229 #2) "Is Syn Floorplan Manager Worth The Price?"
>I would be very interested in hearing from people that have real-life
>hands-on experience with the Synopsys Floorplan Manager. For example, does
>it really do something that I can't do myself by tweaking the constraints &
>process by which I use the dc_shell? If so, under what circumstances would
>this extra something be worth the extra something Synopsys is asking for it?
From: jeffb@asic.mtv.nec.com (Jeff Buckles)
John,
I'd like to share an experience that I just completed with Links-To-Layout
(aka Floorplan-Manager).
// Synopsys Floorplan-Manger exists mode OFF
In January we processed a design from a customer using one of our 0.5um gate
array technologies. At that time we did not have Synopsys floorplan manager,
and getting the design to meet timing was a nightmare.
The design was completely hand floorplanned (about 15 floorplan regions for
80k gates). The customer used our statistical wire-load models with "-mode
enclosed", so the wire load estimates were very aggressive for lower-level
hierarchical blocks, but (so we thought) a little conservative for
higher-level blocks. However, after place & route, there were some rude
surprises:
- The statistical wire-load model grossly underestimated the wire
load between floorplan groups. Given the following hierarchy:
(Logical) (Physical)
TOP - TOP -
|__ A _ |_ A + A1 + A2
| |_ A1 |
| |_ A2 |_ B + B1
| |
|__ B _ |_ B2
|_ B1
|_ B2
Suppose that module "A" is one floorplan Group, B+B1 is a group,
and B2 is a group by itself. The statistical model (with -mode
enclosed) will estimate nets between B1<-->B2 based only on the
number of gates in all of B. However, in our case, B+B1 and B2
were rather far apart on the hand floorplan, causing the statistical
models to break. (No, we can't ask the customer to change their
logical hierarchy to match the physical; I tried that....once)
But, the real surprise was that it had under-estimated the load
between blocks such as A and B!
- Wire-loads for nets buried deep in the hierarchy were also
underestimated. Consider the same hierarchy again: nets
completely enclosed within A1 will get statistical wire loads based
on the gate count in A1. But the real physical implementation
will allow those gates to spread out over an area that is large
enough to contain all of A+A1+A2. On the other hand, there may
still be some sense of "locality" among the gates in A1.
So setting wire load -mode "top" may yield too *conservative*
wire loads for A1 (as alluded to in ESNUG 229).
- Wire loads for I/O nets were significantly overestimated. This
occurred because the statistical model for top-level nets assumes
that a net is connecting between two floorplan groups. A majority
of top-level nets do this. But since blocks that connect to I/O
are commonly placed near the I/O pads, the I/O nets tend to be much
shorter than inter-block nets.
In cases where the prelayout wireload had been significantly underestimated,
it was obvious that many of the fixes should have been achievable with IPO
("compile -in_place") -- fixes such as additional buffering, replacing
gates with higher-drive versions, etc. But, for whatever reason, IPO was
unable to accomplish the fixes. We played with the compile variables to no
avail. My own (unsubstantiated) speculation is that certain nets were
falling-back to the statistical model during IPO, thus "fooling" Synopsys
into believing that the path was "fixed".
METRICS: It took about five iterations of netlist hand-edits, four quarts of
StarBucks coffee, and a three all-nighters to coerce the layout to meet
timing. Just tweaking constraints didn't help because the nets that "broke"
were just too far "out" to be fixed by adding the small amount of margin that
could be achieved with constraint tweaks. And neither I nor the customer was
willing to risk breaking something else by completely re-synthesizing.
It would be easy to blame the vendor for having lousy wire-load models, to
blame the layout tools for doing a lousy placement, or Synopsys for not being
able to fix the problems. But I'm starting to agree that as long as you're
using statistical wire load models for submicron design there's not much else
that can be done -- it's just The Way Things Are. Many of our customers have
beaten us up on this, but it really is an industry-wide problem (wasn't there
an "ASIC & EDA" (oops, That's "Integrated System Design") article about this
a few months back?)
// Synopsys Floorplan-Manger exists mode ON
This Fall we had an opportunity to re-spin the design. We used virtually the
same design, the same technology library, and the same wire-load models. But
this time I wanted to see if Floorplan Manager Links-To-Layout (LTL) really
worked. The customer agreed to try it. So, we took a preliminary, trial
placement and created a set of custom wire-load models for it. (I had wanted
to make these based on the floorplan clusters, but screwed-up and gave them
the models based on logical hierarchy. I guess it worked anyway!)
Timing analysis on the design with these custom (hierarchical) models showed
that it *almost* met timing at 33 MHz. So I took it into our floorplanner,
created custom cluster-based wire load models, and re-analyzed the timing
using the physical hierarchy and annotated net capacitance. It blew up!! I
had 12ns violations in a 33MHz design!
Since we were only at the floorplan stage, I tried a couple of things.
"reoptimize_design -in_place" and "compile -in_place" didn't do nearly
enough, as I rather expected, even using wire_load models created from the
current floorplan. On the other hand, this did quite well:
reoptimize_design -post_layout_opto \
-tolerance_to_change high \
-map_effort high
The worst violator was now about 1.2 ns, but all the violations were
contained in modules that were deeply nested in the hierarchy. These modules
were fairly self contained (low port/gate ratio) and were embedded in much,
much larger modules. So I was confident that the Placement tool would tend
to tightly cluster the cells in these paths even though they were members of
a much larger floorplan area. We could have broken these modules out into
small floorplan groups, but I was *that* confident that placement would fix
it. (And me, not a gambling man! If it hadn't worked, I'm sure the customer
would have shot me by now....)
This design went throught layout and came back with more violations. In this
case, all of the violations could be attributed to under-estimation of net
capacitance by the floorplanner itself. So:
reoptimize_design -in_place
on the fully Placed & Routed design actually took care of almost all of the
violations.
After that I had to hand-edit exactly two gates to change them from low-power
to high-power, and move a buffer to a higher level of hierarchy so that the
unbuffered signal was available one level up (the signal was used both
locally and remotely -- the local path did not need the buffering and could
not tolerate the intrinsic delay of the buffer.)
I don't yet know if "reoptimize_design -in_place" introduced these three
problems, or why it was unable to fix them. But I plan to find out.
METRICS: One iteration. Two cups of Starbucks. No all-nighters.
- Jeff Buckles
NEC Electronics Inc.
|
|
