( ESNUG 393 Item 13 ) -------------------------------------------- [04/25/02]
Subject: ( ESNUG 388 #2 ) Handle General & External Obstructions In PhysOpt
> The tone of my postings has been to gather as much useful information as
> possible directly related to PhysOpt 'obstructions' and put it in one
> place (or a few postings) in ESNUG.
>
> - Cyrus Malek
> Synopsys, Inc. Austin, TX
From: "Cyrus Malek" <cyrusm@synopsys.com>
Hi John,
OK, this should round out my notes on obstructions in PhysOpt. Today's note
will cover the final two categories: General and External Obstructions. Let
us begin...
General Obstruction Objects
General Obstructions
--------------------
General obstructions (non-PNET and non-fixed-cell) can be created with the
command:
create_obstruction
[-name cluster_name] [-parent cluster]
[-layer layer_name] [-placement]
-coordinate {X1 Y1 X2 Y2}
In PhysOpt 2001.08, we completed the triplet of obstruction-manipulating
commands by adding:
report_obstruction
remove_obstruction
so any obstructions that are created with the create_obstruction command
can subsequently be reported and or removed within the shell... a great
tool for experimenting with minor floorplan modifications WITHOUT having
to go back to a floorplanner.
In addition, obstructions can be read in through PDEF, such as
(DISTANCE_UNIT 1.000000)
(LAYER_DEF
(LAYER "METAL1" 10)
(LAYER "METAL2" 12)
(LAYER "METAL3" 13)
)
(CLUSTER "psyn_obs_place"
(OBSTRUCTION 0)
(RECT 0.00 0.00 50.00 50.00)
(X_BOUNDS 0.00 50.00)
(Y_BOUNDS 0.00 50.00)
)
(CLUSTER "psyn_obs_route"
(OBSTRUCTION 10)
(RECT 50.00 50.00 100.00 100.00)
(X_BOUNDS 50.00 100.00)
(Y_BOUNDS 50.00 100.00)
)
In the above PDEF example, two obstructions have been defined, one on layer
ID 0 (undefined layer) with coordinates {0 0 50 50}, and one on layer ID 10
(METAL1 layer) with coordinates {50 50 100 100}. When an undefined layer
is used to create an obstruction, that obstruction will be come a PLACEMENT
obstruction. It will affect the placement of cells, however it will NOT
affect the congestion or delay calculations (due to nets crossing the
obstruction). When a previously defined layer (as show above in the
LAYER_DEF section) is specified in an obstruction, that obstruction will
reside solely on the specified layer. This type of (layer-specific)
obstruction WILL affect delay and congestion calculations since routing
tracks on the specified layer have been obstructed.
To illustrate the above, let's look at a pathalogical case, with some
fuzzy math:
Suppose your design uses a 3-layer metal technology, and suppose
(as is typically the case) your physical technology library [.pdb]
has all 3 layers specified.
Metals 1 and 3 route vertically, while metal 2 routes horizonally - all
have same width and spacing. Further, suppose your integration
team has decreed that all block designers are limited to just
metal 1 and 2! Metal 3 is reserved for top-level routing and/or power.
Since PhysOpt sees all 3 metal layers in the technology library, it will
assume it can utilize all 3 layers for timing & congestion calculations.
To make your design adhere to the integration team's decree, a full
obstruction should be placed on metal 3, either via the floorplan
PDEF or with PhysOpt's create_obstruction command.
Suppose this design is highly congested - say it uses 120% of all metal
1 and metal 2 routing tracks (which means it needs 20% more metal).
If the metal 3 obstruction IS created before PC is run, then PhysOpt will
'see' this congestion, and appropriately determine that the design is
120% utilized for routing. PhysOpt's physical viewer and the
report_congestion command can be used to analyze this congestion. If
the obstruction is NOT created before PhysOpt is run, then PhysOpt will
'see' 33% more routing tracks than it really has (it now has 3 full
layers instead of 2). To make the fuzzy math simple, if every layer has
100 routing tracks, PhysOpt now things it has 300 routing tracks instead
of 200. Remember that the design requred 20% of metal 3 on top of all of
metal 1 and 2, so therefore the grand total comes out to (1.2 * 200) =
240 required tracks. The congestion that PhysOpt would see would only
be 240/300 = 80% !
I hope the above case illustrates why it is important to understand *ALL*
constraints on a design, both logical and physical, as well as understanding
PhysOpt's default behavior with respect to these constraints.
General Routing Obstructions
----------------------------
To create a routing obstruction, use either the create_obstruction -layer
command or read in a PDEF that contains the obstruction declared on a
valid routing layer ID. Valid routing layer IDs are defined in the
"LAYER_DEF" section of the PDEF file, typically near the beginning of
the file.
In the PDEF example earlier, the obstruction named "psyn_obs_route" is
treated as a routing obstruction since the OBSTRUCTION construct declares
a valid layer (layer id 10 = METAL1, according to the LAYER_DEF section).
The following command can be used to create this exact routing obstruction
within Physical Compiler:
create_obstruction -name psyn_obs_route -layer METAL1 \
-coordinate {50 50 100 100}
This obstruction will be factored in during congestion analysis and net
delay calculations.
The physopt_pnet_*_blockage_layer_names have NO effect cell placement with
respect to these these general routing obstructions -- they are strictly
routing obstructions.
General Placement Obstructions
------------------------------
General placement obstructions can be created either by reading in a PDEF
that contains the placement obstruction (an obstruction declared on a
non-existant layer ID) or using the create_placement command.
In the PDEF example above, the obstruction named "psyn_obs_place" is
treated as a placement obstruction since the OBSTRUCTION construct
declares an invalid layer (0 = undeclared, according to the LAYER_DEF
section). The following command can be used to create this exact
placement obstruction within Physical Compiler:
create_obstruction -name psyn_obs_route -placement \
-coordinate {0 0 50 50}
Any placement site that is even partially covered by this obstruction will
be treated as an obstructed site, where PC will not place a cell.
I want to reiterate: this obstruction will NOT be factored in during
congestion analysis and net delay calculations since it does not affect
routing layer availability.
External Obstruction Objects
External Obstructions
---------------------
Obstructions can also occur in cover macros. I have seen users specifying
cover macros to either define obstructions that pre-exist at a higher level
of the physical hierarchy, or to define reserved regions for future routing
at the top level. While today PhysOpt does not automatically create and
write out physical net shapes that could short with the layer obstructions
in the cover macro, it WILL take these 'external' layer obstructions into
account when calculating congestion and timing. Be careful when using cover
macros, there are some clearly defined caveats in the LEF/DEF Reference
manual.
A sample cover macro instantiation in DEF format looks like:
COMPONENTS 1;
- instance_cover_macro_1 cover_libcell_reference + COVER ( -90 -90 ) N ;
END COMPONENTS
The library cell that this instantiation calls out must be defined in a
linked physical library. Here is an LEF example :
SITE COVER
CLASS PAD ;
SIZE 0.9 BY 0.9 ;
END COVER
MACRO cover_libcell_reference
CLASS COVER ;
FOREIGN cover_libcell_reference -0.9 -0.9 ;
ORIGIN 0.9 0.9 ;
SIZE 1468.8 BY 1342.8 ;
SITE COVER ;
OBS
LAYER OVERLAP ;
RECT -0.9 -0.9 0.9 0.9 ;
LAYER m5 ;
RECT 182.95 535.75 196.85 538.85 ;
END cover_libceell_reference
The corresponding code in .plib format would be:
resource ( "std_cell" ) {
site ( "COVER" ) {
site_class : pad;
size ( 0.900, 0.900 );
} /* end site */
} /* end resource */
macro ( "cover_libcell_reference" ) {
cell_type : cover;
source : user;
in_site : COVER;
foreign ( "cover_libcell_reference" ) {
origin ( -0.900, -0.900 );
} /* end foreign */
origin ( 0.900, 0.900 );
size ( 1468.800, 1342.800 );
obs () {
geometry ( "OVERLAP" ) {
rectangle ( -0.900, -0.900, 0.900, 0.900 );
}
geometry ( "m5" ) {
rectangle ( 182.950, 535.750, 196.850, 538.850 );
}
}
}
Both routing and placement obstructions can exist in cover macros (among
other things). These obstructions are treated just like the general
obstructions defined in the previous sections.
- Cyrus Malek
Synopsys, Inc. Austin, TX
( ESNUG 393 Networking Section ) --------------------------------- [04/25/02]
Petaluma, CA - Calix Networks, a pre-IPO start up seeks an ASIC Manager.
Requires Synopys, PrimeTime, Apollo and/or Saturn. "thang.le@calix.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 13,958 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
|
|
