5/12/2015 Reducing Congestion With IC Compiler

Search SolvNet Go Advanced

SYNOPSYS.COM |  FEEDBACK |  SITE MAP |  HELP |  SIGN OUT

Documentation Support Downloads Training Methodology My Profile

HOME SOLVNET ARTICLE

Reducing Congestion With IC Compiler SAVED ARTICLES

Doc Id: 020963   Product: IC Compiler   Last Modified: 08/05/2008   TAGS

Average User Rating:     (22)    Rate Article:      Send comment None

Add Tags
Save Article   Tag Article   Print   Email

Reducing Congestion With IC Compiler

Congestion is a problem that you face when designing chips. Congestion means 
that more routing resources are needed than you actually have. Congestion can 
occur locally in a portion of a block or globally for the whole block. Sometimes 
your designs are congested at different locations with different severity. 
This document describes how to solve congestion issues.

Divide‐and‐Conquer Approach

The divide‐and‐conquer approach resolves congestion step by step and does not 
attempt to solve all congestion problems at once. This approach can appear to 
be more time‐consuming, but it can actually take less time. You might need to 
solve a few problems at the same time, for example, a high utilization issue, 
a datapath structure issue, or a port location issue. Some problems are 
interdependent or influential, so solving those problems might improve 
some results but produce other poor results. You should save your results 
after each successful experimental stage.

You should neither optimize (using place_opt or psynopt) nor explore congestion 
issues of a design at the same time. With large designs, it might be useful 
to segment out the problematic hierarchy (by using grouping commands in Design 
Compiler/Design Compiler topographical mode) and generate the expected floorplan 
(by using minimum physical constraint options); then work stand‐alone until you 
get the best results.

Avoid Very High Utilization

The first step of design optimization in IC Compiler is done with a thin netlist. 
This means that the netlist does not contain elements to be added later in 
the flow such as clock tree buffers, hold fixing cells (buffers), and so on. Area 
should be preserved to add these elements later. The amount of the area to be saved 
depends on each design, but it is around 10 percent. Timing issues and wire 
distances can determine the amount of the area needed. In difficult signal integrity 
cases, 20 percent should be sufficient. Therefore, it is recommended that you avoid 
very high utilization. If you have a design with very high utilization, take the
following actions to eliminate potential problems resulted by routing congestion 
and/or insufficient placement area: 

1. Check the design constraints (both timing and design rule checking). An 
optimized design that contains many large cells and buffers could indicate bad 
constraints. Commands that might help are: 

    check_timing
    report_timing_requirements ‐ignored

2. Perform netlist reduction by using either Design Compiler or IC Compiler.

    Design Compiler: compile ‐area_effort high [‐inc] 
    IC Compiler: psynopt ‐area_recovery ‐area_effort high [‐only_area_recovery]
    IC Compiler: place_opt ‐area_recovery

Setting physopt_ultra_high_area_effort to true adversely impacts the design 
area when used with place_opt ‐area_recovery ‐effort medium or place_opt 
‐area_recovery ‐effort high.

Reducing the number of cells in the design or even specifying a few subblocks 
to reduce the number of cells, you use fewer routing resources. To avoid 
repeating this step for each stage in the flow (it might cause longer runtime), the 
resulting reduced netlist should be saved with a new name. The saved netlist
becomes your starting point.

Congestion Hot Spots and Block Timing

Some block inspections reveal timing issues that force cell placement. A subblock 
can have very tight timing and design rule checking(DRC) constraints, especially a 
path with many logic levels between flip‐flops or latches. In many cases, the 
tight timing is caused by timing and DRC constraint propagation from the top level. 

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 1/6
5/12/2015 Reducing Congestion With IC Compiler
The top‐level constraints should be checked carefully. If you find unjustified 
constraints, apply a different DRC or timing constraint to the block.

You can also try other techniques such as using case analysis, setting false 
path or multicycle path constraints, adding input delay to the associated clock, 
or constraining the ports.    

Automatic Congestion Handling
If you want IC Compiler to resolve congestion automatically, follow the below
steps. 

Set the Congestion Options
For best results, you should provide realistic numbers for the routing 
availability of the metal layers. For example, metal1 is mostly used for cell 
building and power and often has limited availability for routing. 

To specify the routing availability for a layer, use the following command:

    set_congestion_options ‐layer <layer> ‐availability <percentage> \
    ‐coordinate [get_placement_area] 

These settings affect congestion optimization and reporting.

Check the Results

Some locations in the design are expected to be congested if they are not well
planned for channel and port areas. The treatment for these areas is described 
in the "Floorplan‐Driven Problems" section that follows.

View the ASCII congestion report generated by the report_congestion command. 
You can also view congestion information in the GUI. 

Use the ‐congestion Option 

IC Compiler provides powerful algorithms to resolve congestion. Unlike the 
default behavior that the placer minimizes wire length (the default) or optimizes 
path location to meet timing, the goal of the algorithms is to reduce congestion. 
The algorithms are invoked by using the ‐congestion* option with the psynopt, 
place_opt, create_placement, or refine_placement command during placement stage. 

Two primary concerns when using the congestion‐removal algorithms are:

     1. Runtime is increased, so congestion‐removal algorithms should be invoked 
        only when needed. 

     2. Congestion‐removal algorithms can result in less optimized design for timing. 

When using the create_placement and refine_placement commands, you can control 
the congestion effort. The ‐congestion_effort option determines how much effort
IC Compiler uses to resolve congestion. A medium effort is the default for 
tradeoff between quality and runtime. For more difficult designs, setting the 
congestion effort to high causes a longer runtime. 

The recommended way of using congestion options is as follows:

     Medium ‐ The maximum routing congestion might be greater than 100 percent, 
     but most routing congestion is below 100 percent. Congestion hot spots are not 
     large compared with the overall floorplan size and do not form large 
     masses.

     High ‐ The maximum congestion is much higher than 100 percent and the 
     routing congestion is above 100 percent. Hot spots are large.

     ‐timing_driven ‐congestion ‐ To trade off between congestion and timing, 
     invoke the ‐timing_driven and ‐congestion options. The tool tries to 
     resolve timing and congestion problems concurrently. The fact that timing and 
     congestion cost functions are fully recognized at all points can greatly benefit 
     designs with both timing and congestion problems. 

Use Global‐Route‐Based Congestion

In difficult cases, you might want to use a more accurate congestion calculation 
based on global route. The default report_congestion command is based on a tradeoff 
between accuracy and fast runtime. Even the result of using global route command 
might not differ much, but it is more accurate. Use the following command: 

    route_global ‐congestion_map_only

Use the High‐Effort Congestion Algorithm

IC Compiler provides a new high‐effort congestion algorithm. To enable this 
algorithm, set the placer_enable_high_effort_congestion variable to true before 
you run place_opt ‐congestion or psynopt ‐congestion. When you enable the  
high‐effort congestion algorithm, IC Compiler does a very detailed 
congestion‐driven placement and generates a log as follows:

     100% done.

     69%...75%...81%...88%...94%...69%...75%...81%...88%...94%...100% done.

     [begin initializing data for legality checker]

Performing the psynopt congestion optimization without the high‐effort congestion 
algorithm gives you the following log:

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 2/6
5/12/2015 Reducing Congestion With IC Compiler

     100% done.

     69%...75%...81%...88%...94%...100% done.

Floorplan‐Driven Problems

This section discusses floorplan‐driven problems such as channels, macros, 
power grids, and port location changes.

Channels (Slivers, Tunnels) Causing Congestion Problems

A channel is defined as the routing (placement) area between macros or the
distance between macros and the borders of a design. You block the channel from 
placement with a complete placement blockage. However, congestion can appear 
at the internal edge of the blockage, or timing problems might occur. The  
worst‐case scenario happens when the pins of one macro are placed in the same
channel where the pins of another macro opposite are placed. Another problem
is that ports are located at the end of the channel. 

In a densely‐packed design, a large number of complete blockages might cause 
insufficient placement area to place the design.

Channel Planning

Create channels wide enough to accommodate all routing, power rings (if any), 
and the bus expansion area outside the macros pins so that nets can go across
the channels toward the internal part of a block. However, use only necessary
width for channel routing to save area.

Macro Treatment

Macro placement (or orientation) should minimize the interconnect between 
the pins of macros and internal block. The same macros are facing the pins 
if they are connected to the same bus, the pins should align respectively even
if the pins are not organized visually. If the macros are connected to different 
buses and more than two routing layers are available, pin alignment is still
recommended. 

Power Grid (Mesh)

A power grid supplies power to all chip components (transistors). IR drop
(voltage drop) along the power supply line can cause the basic components of 
the design, the transistors, to fail or malfunction. If a design has a pad
ring containing all the pads including power pads that are located at the chip 
boundaries, some areas (especially in the center or near areas that are masked 
from power routing) might not get the voltage level needed to function properly.
To avoid this problem, you can design a very robust grid to encompass the chip. 
When you cannot meet the goals of IR drop using a single layer per direction or 
the top metal with the smallest resistance, you can design a grid with two or 
more layers per direction. However, an extensive use of routing resources or 
placing metal in a nondefault power grid metal direction might create a design 
that is not routable. 

Analyzing the Power Plan 
Power planning is derived from chip‐level floorplanning, so your initial
work should be done at the power plan stage. Analyzing the power plan 
before getting to the block level can be a good starting point. Tools 
such as JupiterXT power network analysis and Astro‐Rail should be used to 
verify that a grid is robust enough but does not waste routing resources. 
Use JupiterXT power network synthesis and power pad synthesis to help you 
create a more efficient power plan.  

Nonoptimized Track Use
In many cases, a power grid is spread evenly across the whole chip regardless
of the basic routing pitch and routing grid location. An evenly spread power 
grid can result in losing routing resources near the power grid. To avoid  
losing routing resources, adjust both the power strap width and distance between 
straps along the grid.

Different Widths Inside a Specific Block
Because a power strap width is specified for the power supply of the entire 
chip regardless of the distance from a power pad, the power strap has the same 
width all along. For high routing demand, consider thinning or removing a few
power straps (after consulting with your power plan designer) and analyze the 
results. If the solution adversely affects the IR drop of the entire chip but 
the block looks fine, adding a power ring around this block might help. 

Nondefault Via Rules 
The default behavior of a power grid routing is specified by putting a via 
array at the crossing point. Every pass between two different layers with the 
same direction creates a stack via. A stack via is a small metal area generated 
from a layer dedicated to a different direction. For example, if metal#3 and 
metal#5 are dedicated to vertical direction, and metal#4 and metal#6 are 
dedicated to horizontal direction, a stack via between metal#3 and metal#5 uses
metal#4. In this case, the amount and shape of vias should be limited. This can 
be achieved by putting more effort in the stripes design step; that is, keep the
vertical layer lower than the horizontal to avoid unconnected power straps. 
Use separate steps for vias by selecting the axgCreatePrerouteContacts menu and 
the axgPrerouteStandardCells menu Advance Via Rules dialog box. 

Port Location Changes

This section describes some congestion problems driven from port locations.  

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 3/6
5/12/2015 Reducing Congestion With IC Compiler
For the purposes of this document, it is assumed that you don't have full control 
over port locations and sides at the block level. 

Inputs vs. Outputs
Port location has huge impact on placement. Many placement approaches (including
wire length and timing) place both input cells and port isolation cells and 
connect them close to input ports. Placing isolation cells close to the ports
often occurs in the cases of very high input delay versus clock rates. Output 
ports have fewer port location issues. From a timing point of view, if there 
are strong cells in the library that can support DRC and output delays versus 
clock rates, output ports can be within a certain distance from the ports. 
Many ports that are condensed within a small portion of the design area might 
conflict with reasonable cell placement, especially those cells with direct 
connections to ports. The solution for this issue is to spread out the input 
ports as much as possible. 

Routing Bottlenecks

Another issue is the routing bottleneck where you have many routing segments 
with a limited amount of layers and you try to follow back‐end design rules to 
change the direction of ports with minimum spacing rules. One solution for 
this issue is to spread out these ports as much as possible. Another solution 
is to use placement soft blockages near the ports. Use soft blockages instead of
hard blockages to avoid timing and DRC issues. In very difficult cases, use a 
progressive blockage approach. 

Limited Channels

A limited channel is the use of ports hidden behind hard macros. When a channel 
(both the area between a few macros and the distance between macros and design 
borders) is too small, even to the amount of routing that should pass through 
it, it is called a limited channel. A limited channel might be an issue where 
there are a limited number of layers, especially in technologies where there 
are fewer routing layers over macros. In this case, no blockage can be used, 
so the channel should be resized. This phenomena can be detected at the design 
planning stage. 

Block‐Level Floorplan Adjustments

You can use the following block‐level floorplan adjustments to improve congestion. 

Local Utilization

One method you can use with IC Compiler to improve congestion is local utilization. 
Note that congestion and utilization are two different design challenges. After 
locating a bottleneck, you can control the amount of cells by defining local 
utilization by percentage. 

Use the following command to implement local utilization:

    set_congestion_options  ‐coordinate {} ‐max_util 0.X 

This solution can be used in several places in a block, and you can specify 
a different number for each place. A restriction to this command is that
the max_util value should be less than 1.0 but not too low. In some cases,
you might find that the congested area floats to nearby areas. Therefore, 
using local utilization to improve congestion can lead to further adjustments.

Nondefault Direction Routing 

This solution uses a nondefault routing direction with route guides. It might 
be helpful to allow routing over macros to solve massive detour routing. Some 
macro manufacturers allow you to route with metals that are higher than metal#5 
over certain macros. This can sometimes be done after fitting the design rules 
of lower metals. Within some designs, this metal routing direction is opposite 
to the desired direction. By using route guides, you can solve some of the 
congestion problems using create_route_guide or choose Flourplan > Create
Route Guide in the GUI. 

    create_route_guide ‐switch_preferred_direction

Bounding or Grouping Subblocks Without Congestion Options

Sometimes you might want to put specific subdesigns or subblocks either
together or within a specific place in a design primarily to solve timing 
issues. You can do this by generating bounds, which can be used to solve 
congestion issues in other cases. The command used to implement this 
approach is as follows. (Use different numbers for each subblock.)
    
    create_bounds ‐name bound1 ‐coordinate {} ‐effort high|ultra ‐type \ 
        hard [get_cells cell_list1]
    create_bounds ‐name bound2 ‐coordinate {} ‐effort high|ultra ‐type \ 
        hard [get_cells cell_list2]
 
The solution has one restriction that too many bounds can slow down the 
placement stage. The allocated area should fit the expected cell area. If the 
area is too large, moving other cells into the spaces inside the bound causes 
congestion again. If the area is too small, this approach won't be honored. 
After inspection, this step should be done carefully. When the balance is broken, 
results can become much worse.

Combining Bounding Subblocks With Local Utilization (With Congestion Options)

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 4/6
5/12/2015 Reducing Congestion With IC Compiler
When you inspect local utilization usage, determine if the placer can put a 
group of cells together especially for timing. If the reasonable location of 
a group of cells has a local utilization restriction and the placer puts the
group somewhere else, the effort is not successful because congestion 
remains and timing is adversely impacted. 

You can force cells to group in a specific location and to utilize locally 
by combining a bounding command for this group of cells together. The commands 
to implement this approach are as follows: 
   
    create_bounds ‐name bound1 ‐coordinate {X1 Y1 X2 Y2} ‐effort high \
        ‐type hard [get_cells cell_list1]
    set_congestion_options  ‐coordinate { X1 Y1 X2 Y2} ‐ max_util 0.X
    create_placement ‐timing (or refine_placement)

The restriction for this solution is that too many bounds can slow down the 
placement stage. The allocated area should fit into the expected cell area for 
this utilization. If the area is too big, other cells can jump into the spaces 
inside the bound to cause congestion again. If the area is too small, the
utilization won't be honored. On inspection, determine if the grouping is 
timing‐based. Cells that get stuck in the corner or side violate the max_util 
value while some of the bounding area remains empty. 

Strategic Keepouts
 
This solution puts placement blockages in areas with very high congestion. 
After allocating the bottleneck, you can control the amount of cells by defining 
the strategic keepouts. By default, IC Compiler has some keepout areas around 
macros especially for macro pins. You can define strategic keepouts manually 
or create script in IC Compiler. The script takes the congested regions based 
on the threshold you define and generates blockages over the highly congested 
area. In some cases, if the utilization is limited, the optimization might 
later try to put the cells in other places so that the congestion can move 
to a less restricted area.

An Example of Using Script to Generate Strategic Keepouts 

   # Customer Control #

    set run_num 1

    set congestion_threshold 1.3

    set con_placement_type hard

   # Script Body

    redirect ‐var congested_area { get_congested_regions ‐threshold \ 

      $congestion_threshold }

    set congestion_vector [split [lindex $congested_area [expr [llength \ 

      $congested_area ] ‐2 ]] "," ]

    foreach i $congestion_vector { \

         set sbn "[ string trim [ lindex [split $i " "] 0 ] \{ ][ lindex\ 

                [split $i " " ] 1 ]" ;\

         create_placement_blockage ‐type $con_placement_type ‐coordinat \

                [list [ string trim [ lindex [split $i " "] 0 ] \{ ] \

                [ lindex  [split $i " "] 1 ] [ lindex [split $i " "] 2 ]  \

                [ string trim [ lindex [split $i " "] 3 ] \} ]  ] \

                ‐name conblckg$run_num$sbn 

        }

For More Information:
See also the SNUG‐Israel 2006 user paper (C4): "The Congestion Dragon Can 
be Defeated. Fighting Congestion Techniques with Physical Compiler."

Average User Rating:     (22)    Rate Article:      Send comment

Save Article   Tag Article   Print   Email

Your Recently Viewed Articles

Reducing Congestion With IC Compiler

Your Recent Searches

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 5/6
5/12/2015 Reducing Congestion With IC Compiler

  ©  2015  S y no p s y s ,  I nc .  A ll  R ig hts   R e s e r v e d . CONTACT US | TERMS OF USE | PRIVACY POLICY

https://solvnet.synopsys.com/retrieve/020963.html?otSearchResultSrc=advSearch&otSearchResultNumber=3&otPageNum=1 6/6