( ESNUG 372 Item 11 ) ------------------------------------------- [05/31/01]
From: [ A PhysOpt AC in Chicago ]
Subject: The 4 GB PhysOpt Memory Limit & How To Reduce PhysOpt Memory Usage
John,
I thought your readers doing big designs with PhysOpt might be interested
in some tips for reducing the amount of memory PhysOpy uses. Our advertised
capacity for Physical Compiler for gates-to-placed-gates runs is around 350K
instances (due to the current 4 GB memory footprint), but this capacity can
be influenced by a number of things. Here's what you need to check if you
need to squeeze the memory required for your design:
1. Command-line switches: Make sure that you are using the appropriate
switches for your design. The high effort, congestion, and area
recovery switches can be useful in some situations but do come with
a memory (and runtime) penalty.
2. Constraints: Just like Design Compiler and PrimeTime, path exceptions
can consume large amounts of memory. Be on the lookout for excessive
use of wildcards. Maybe you were overconstraining as part of your DC
synthesis strategy, but now that you are using actual placement-based
delays in PhysOpt, some of those constraints are no longer needed.
Critical range can also cause increased memory use because it forces
PhysOpt to simultaneously optimize more than just the worst path.
Don't just think of timing and DRC constraints -- physical constraints
like the "set_bounds" command take memory as well. Make sure they are
needed before you use them. They cost memory!
3. LEF detail for black boxes: If you have access to it, look at the LEF
for cells like RAMs and cores and see how detailed it is. If you're
treating the entire area of the cell as a complete obstruction, there
is little to be gained by having detailed modelling of every metal
shape. If you see this, work with your layout folks to get a better
(less detailed) abstraction of the cell.
4. Unusable routing layers in LEF: The LEF usually represents all of the
routing layers available for a given technology. In many cases, not
all of these layers are intended to be used for signal routing. Look
especially for names like M0 or METAL0, which are likely not true metal
layers. You get two big benefits from removing these types of layers.
First, they often have different RC characteristics from the other
layers which can skew the automatic calculations PhysOpt does. Second,
this will reduce the number of layers the router within the tool has to
account for, with a corresponding reduction in the memory usage.
5. Filler cells: Check your floorplan to see if you are using filler cells
to act as obstructions. Memory efficiency is much improved if you
remove them and represent them in one of two different ways available
within PhysOpt:
Method 1: Use the create_obstruction command to define them as
placement or routing blockages
Method 2: If the fillers are being used in the neighborhood of a
fixed cell like a RAM, use set_keepout_margin to define
an area where cells are completely prohibited (i.e.,
"hard" keepout) or discouraged (i.e., "soft" keeout)
6. PNETs: If the die area is not highly utilized, you can remove some of
the PNETs. Start with the PNETs that connect power to the standard
cells since they do not affect the placement of the cells. Try to
leave in any PNETs that do restrict placement. You can also consider
modelling the PNETs as complete obstructions via the create_obstruction
command.
7. Die area: Again, for low utilization designs, remove some of the area
available for placement. It's best if you can actually remove site
rows from the floorplan, but the create_obstruction command is another
option. Make sure to also remove any PNETs in the obstructed area to
get further memory savings.
Follow these 7 steps, John, and you'll maximize your PhysOpt memory usage.
- [ A PhysOpt AC in Chicago ]
|
|
