Congestion analysis using reportCongestion and Congestion GUI

It is recommended to refer below section of Innovus user guide, before going through this article.
Prototyping Flow Capabilities-> Using Early Global Route for Congestion
and Timing Analysis

The philosophy of EGR (or TrialRoute in older versions) is to detour minimum number of nets and show
congestion so that the problem can be seen at pre-route stage and resolved. During final routing
(NanoRoute) of design, tool will try to resolve the congestion by detouring the nets. In case congestion is
very high, router may not be able to resolve it and there will be shorts or DRC in the design.

Congestion analysis uses GCELL area

for calculating available or used tracks.
GCELL is usually 1 row height but can
change depending on design size

Congestion analysis is usually done at two levels.

• Statistical: Overall design congestion by looking at overflow table and hotspot information printed
in log
• Visual: More detailed look at the congestion map to understand what is causing congestion

Statistical: This information is printed in the log whenever EGR runs. You can also report this information
using command reportCongestion -hotSpot -overflow -includeBlockage. Overflow
part of that, reports information similar to below.
----------------------------------------------------------------------
Usage: (34.3%H 15.7%V) = (1.055e+08um 5.367e+07um) = (156996376 79867977)
Overflow: 232358 = 225878 (0.87% H) + 6480 (0.03% V)

Congestion distribution:

Remain cntH cntV

--------------------------------------
-5: 10563 0.04% 411 0.00%
-4: 12401 0.05% 317 0.00%
-3: 23935 0.09% 598 0.00%
-2: 41815 0.16% 995 0.00%
-1: 75398 0.29% 2403 0.01%
--------------------------------------
0: 152960 0.59% 5743 0.02%
1: 309627 1.20% 32547 0.13%
2: 546755 2.11% 35022 0.14%
3: 838237 3.24% 61334 0.24%
 4: 1113188 4.30% 111996 0.43%
5: 22768121 87.93% 25630066 99.03%
----------------------------------------------------------------------

In above report overflow reported is, 0.87% in horizontal layer and 0.03% in vertical layers. Which means
@0.87% of the GCELLS on the horizontal layers in the design has overflow (more track required than
available). Table below that provide information about its distribution. e.g. 0.04% in Horizontal & 0.00%
in Vertical direction of the gcells have more than 5 track deficiency.

Thumb rule is, if overflow in either Horizontal or Vertical (on the highlighted line in above report) is more
than 1% then that needs more in-depth analysis and fixing. If its approaching 1% then more analysis is
required to understand and fix if it turns out to be actionable. More analysis here means looking at
hotspots and visual plot.

HotSpot part of that information is like below.

[hotspot] +------------+---------------+---------------+
[hotspot] | | max hotspot | total hotspot |
[hotspot] +------------+---------------+---------------+
[hotspot] | normalized | 1301.85 | 5315.43 |
[hotspot] +------------+---------------+---------------+
Local HotSpot Analysis: normalized max congestion hotspot area = 1301.85,
normalized total congestion hotspot area = 5315.43 (area is in unit of 4 std-
cell row bins)
[hotspot] top 5 congestion hotspot bounding boxes and scores of normalized
hotspot
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | top | hotspot bbox | hotspot score |
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | 1 | 4128.77 53.76 4354.56 107.52 | 1193.50 |
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | 2 | 4053.50 53.76 4118.02 86.02 | 207.52 |
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | 3 | 1924.61 354.82 1978.37 387.07 | 192.30 |
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | 4 | 1892.35 344.06 1913.86 376.32 | 81.65 |
[hotspot] +-----+-------------------------------------+---------------+
[hotspot] | 5 | 3999.74 64.51 4021.25 86.02 | 49.56 |

The hotspot is collection of nearby GCELLS (within 4 std cell row bin) which has overflow. Score of the
hotspot is area of that hotspot. More adjacent GCELL have overflow, more problems it can cause and also
more difficult for tool to resolve it. The area can be rectilinear in shape but is normalized to rectangular
shape.

Thumb rule is that if you have hotspot with score reaching 100, it needs detailed analysis and fixing.

Visual: Statistical analysis can give overall idea if there is any congestion in the design. If there is, you
need to visually analyze it so that it can be fixed.
This can be enabled from menu Route > NanoRoute > Analyze Congestion or
from the overlay option in the layer control pallet as shown in adjacent snap.

Congestion GUI

Diamond style is default to display congestion with EGR, line style is default for NanoRoute.

This diamond shows 74 horizontal tracks are required, however,

only 69 are available. A diamond is created for each
Congestion Cell where the number of tracks needed,
exceeds the number of available tracks. A diamond is displayed
when: (TracksNeeded - TracksAvailable) > violationSetting

You can specify value for the violationSetting mentioned above in the
GUI form fields Horizontal Violation and Vertical Violation.

You can also enable or disable

congestion label. This is useful when
you are looking at overall congestion
map and red diamonds hide
congestion colors.

Congestion cell size by default is 2x1

(4x1 before version 16.10)

Sometimes you may need to set it to

1x1 to see congestion which may not
show up with 2x2 size as it gets
average out over bigger cell.

Overflow in GUI is color coded with

range. You can also enable or disable
visibility of the range by using the tick
box against it.