( ESNUG 383 Item 14 ) ------------------------------------------- [11/28/01]

From: "Cyrus Malek" <cyrusm@synopsys.com>
Subject: How To Treat Power Nets (PNETs) As Routing Obstructions In PhysOpt

Hi John,

Every now and then, I see a number of user questions regarding obstructions
in PhysOpt.  With PhysOpt, we classify obstruction objects as:

  (a) Power nets
  (b) Fixed placement
  (c) General 
  (d) External

In this letter I'd like to focus on "Power Net Objects".

But, before I begin, I must advise users to please not overlook the detailed
information in the Physical Compiler User Guide.  In our 2001.08 release, the
"Preparing Physical Data" chapter provides valuable information about how
PhysOpt works with obstructions.  I also recommend the following SolvNet
articles:
                  pss_kjs.html: Placement Obstructions In PhysOpt
    Physical_Synthesis-57.html: Check Size of Hard Macro LEF (Runtimes)
    Physical_Synthesis-81.html: How To Turn PNETS In Blockages 
   Physical_Synthesis-124.html: How Do I Ignore Routing Layers ?
   Physical_Synthesis-146.html: How To Remove Obstructions (2000.11)
   Physical_Synthesis-149.html: Define Custom Obstruction Over Hard Macros
   Physical_Synthesis-162.html: Get Past Over-Capacity Issues In PhysOpt
   Physical_Synthesis-178.html: Sanity Checking Your Design for PhysOpt
   Physical_Synthesis-202.html: Tips on Efficient PhysOpt Memory Usage
   Physical_Synthesis-256.html: GUI obstr and keep out buttons

That being said, I'll get back to "Power Net Objects".

In general, all cells must eventually be located in a legal location, or
'site', before the block placement is considered 'routable'.  PhysOpt knows
where the available (unobstructed) sites are by their definition in the input
floorplan.  If there are no sites in the input floorplan, then there are no
legal locations to place any cells.  
  
Placement obstructions are used to tell the placer what sites are blocked
(not valid locations to place cells).  Routing obstructions are factored 
into timing and congestion analysis.

For the purposes of this discussion, let us assume the input floorplan has
a clean site array defined. 

Power net objects can take on two basic forms:

    1. Default power net object = routing obstruction
    2. Placement obstruction

Let us take each of these in turn:
 
Power Net Routing Obstructions
------------------------------
  
By default, power nets (PNETs) are treated as routing obstructions and are
factored into routing congestion and net delay calculations.  If power nets
are defined in the input PDEF floorplan, these nets will resemble the
following PDEF code:

     (PNET VSS
       (TYPE GND)
       (ROUTE 
         (LAYER_WIDTH 18  100.00)
         ( 18 ( 5000.00 8000.00 ) ( 5500.00 * ) )
       )
     )

Power Net Placement Obstructions
--------------------------------

If your floorplan has pre-routed PNETs that you would like the placement
engine to heed (in addition to the congestion and delay engines), you should
use the following variables:
 
  set physopt_pnet_complete_blockage_layer_names "metal layer names ... "
  set physopt_pnet_partial_blockage_layer_names  "metal layer names ... "

To find out what metal layers are available, look in the technology section
of your PLIB for "routing_layer" constructs:

       /* BEGIN example Rumpelstiltskin.plib */

       routing_layer ( "METAL1" ) {
         routing_direction : horizontal;
         . . .
       } 
       routing_layer ( "METAL2" ) {
         routing_direction : vertical;
         . . .
       } 
       routing_layer ( "METAL3" ) {
         routing_direction : horizontal;
         . . .
       } 
       /* END example Rumpelstiltskin.plib */

If you do not have access to your PLIB, you can get the layer information
from your physical library loaded in memory.  If you do not know the name of
the physical library, then in a psyn_shell session, you can load your design
plus floorplan and run "legalize_placement -check".  This command will load
all the necessary libraries and link the logical to physical libraries.  A
message (or several) similar to the following will appear:

      Information: Linking logical library slow with physical
         library Rumpelstiltskin.  (PSYN-036)

You *now* know the physical library is called "Rumpelstiltskin".  Next do a
"report_lib -physical Rumpelstiltskin".  The output of this command will
contain a table of available layers in the library:

   layer    layer_type   direction    pitch        width        spacing
   ----------------------------------------------------------------------
   POLY1    masterslice  -            -            -            -
   CONT     cut          -            -            -            -
   METAL1   routing      horizontal   4.600e-01    1.300e-01    1.300e-01
   VIA12    cut          -            -            -            -
   METAL2   routing      vertical     4.600e-01    1.800e-01    1.800e-01
   VIA23    cut          -            -            -            -
   METAL3   routing      horizontal   4.600e-01    1.800e-01    1.800e-01

In the above report, any of the 'layer' entries that contain a 'layer_type'
entry of 'routing' are valid routing layers for PhysOpt.  Similarly, in the
PLIB section above, all valid routing layers are specified within the
'routing_layer()' statements.  So, from the information above we have three
routing layers available: 

                         METAL1, METAL2, METAL3

Valid routing layers can be used in the list passed to either of the two
physopt_pnet_*_blockage_layer_names variables.  As an example, using the
above data:

       set physopt_pnet_complete_blockage_layer_names "METAL1 METAL2"
       set physopt_pnet_partial_blockage_layer_names  "METAL3"

PNETs that are specified as complete blockages are 'visible' to the placement
engine during both coarse placement and placement legalization.  PNETs that
are specified as partial blockages are seen during placement legalization,
but *NOT* coarse placement *UNLESS* an additional variable is set:

       set physopt_create_placement_see_partial_blockages true

In addition, if this variable is 'true', then the user has control over what
'size' PNETs are seen as blockages during coarse placement with:

       set physopt_minimum_pnet_height <threshold value>
       set physopt_minimum_pnet_width <threshold value>

Note: Designs containing *partial* PNETs will suffer a runtime penalty, so
if it's an issue, users may choose to just use *complete* PNET blockages. 
It is recommended to only use these blockage variables if:
    
   1a. The power nets cover placement sites in the floorplan

                           - AND -

   1b. The power nets could possibly short to obstructions within the
       cells or completely obstruct pins within the cells

                            - OR -

    2. The power nets are rather wide and only a few routing layers
       are available (placing cells under these wide nets will
       dramatically increase local routing congestion).

Also to note: if partial blockages exist AND the *_see_partial_blockages
variable is NOT set to 'true', then large cell displacements could occur
during placement legalization.  These large displacements can negatively
affect design timing.  (I am sure no one wants to see their design that
met timing at the end of Optimization experience a dramatic increase in
negative slack due to displacements during final legalization!)

Finally, remember that variables are *not* persistent on the saved design
DB and they must be re-defined each time the tool is re-started!


To view PNETs in the psyn_gui Physical Viewer, check the box next to 'Nets'
and make sure the sub-menu has 'Power Routes' also checked.  In the
Preferences menu, you can selectively turn on/off as well as change the fill
style of the various metal layers.  Note: Setting the physopt_pnet*blockage*
variables has no effect on the appearance of PNETs in the Physical Viewer.


In closing, I would like to briefly touch on the effects of having a power
grid in your design.  When a power grid exists in the floorplan, it is more
information that PhysOpt must store, keep track of, and perform checks
against -- therefore it requires additional memory and runtime.  Moreover,
highly-complex power grids can require significant extra memory, even for
small designs, so it is advisable to check that the grid that is specified
in your floorplan makes sense.

For example, if you have many PNET structures on Metals 4, 5, and 6, but you
do not allow block-level detail routing on these levels, then instead of 
including them in your floorplan, just create full-block layer obstructions
on these levels.  On the other hand, including the power grid will provide
PhysOpt with a more realistic view of the physical aspects of the design,
improving it's ability to estimate timing and congestion.

    - Cyrus Malek
      Synopsys, Inc.                             Austin, Texas


 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)