( ESNUG 416 Item 11 ) ------------------------------------------- [07/30/03]
From: Neel Das <neel.das=user domain=corrent spot calm>
Subject: User Warns PhysOpt 2003.03 Has Weird Macro "Prisons" & "Shadows"
Hello John,
I'd be interested in feedback from those of your readers that have had some
luck with autoplacing macros with PhysOpt, particularly for designs with
large #s of macros. For designs with large numbers of embedded memory
macros, I've been experimenting with the automatic macro placement
capabilities in PhysOpt (through the 2003.03 version). This mode, if it
does work, could be very useful for designs that have large #s of rams that
need to be hand-placed with legacy flows.
My testcase has a large number of RAMs (over 100), and what I saw popping
out of the tail pipe was very curious. I've reached the conclusion that
automatic macro placement (without user-defined placements) in PhysOpt in
a 'physopt' flow is currently not very useful to me. These problems
initially surfaced on a smaller design that only had 8 RAMs.
Macro 'shadows':
----------------
About 25% of the macros PhysOpt placed end up with what I call 'shadows'
around them: extremely low-utilization (under 5%) std cell placement areas
that are 3x-5x the size of the RAMs, with equal shadows on either side of
these RAMs. There are no placement or wiring keepouts around the RAMs. The
shadows are not complete voids, however: there are some cells in them! It
appears that PhysOpt was shifting macros around before converging on a
specific spot, but every time a macro moved, the 'void' left in place only
got an incremental # of cells placed in it.
This problem severely compounded the problem of congestion in this design.
Macro 'prisons':
----------------
In several areas of the design, PhysOpt made the macros almost abut each
other, forming 'prisons' of std cell placement areas for cells that got
placed in the initial stages. Once locked in, these cells seemingly find
it impossible to ever migrate out, giving rise to timing problems. I found
several cases where certain flops got situated like this.
As a sidenote, it'd be good to be able to specify a keepout region around
macros, even when one is in an MPC flow. Currently, per my understanding,
macros can only be allocated keepout regions if they're marked 'fixed' in
an incoming PDEF. The ability to specify a macro -> core_boundary margin
would be good, too. That way, if a user likes certain macro locations,
they could write a script to dump these locations out for a 'real'
floorplanner.
Another thing: I've never seen these shadows in 'compile_physical -mpc', but
only in the 'physopt' runs where macros are *not* marked fixed. I've no
clue on why this happens.
- Neel Das
Corrent Corp. Tempe, AZ
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 17,088 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
|
|
