Not able to route a complex interconnect design even with PL_TARGET_DENSITY 20%; Routing fails with [ERROR GRT-0118] Routing congestion too high

[dineshannayya]

Description

I am not able to Route a complex interconnect block even with low TARGET density of 20%. I am looking for suggestion here.

Environment

Test environment is Openlane tag: 2022.05.18_02.12.32

commit 0dc6fb79c91082b94f8ded78d70f8bacbab96bf2 (HEAD -> master, tag: 2022.05.18_02.12.32, origin/master, origin/HEAD)
Author: Anton Blanchard <anton@linux.ibm.com>
Date:   Wed May 18 01:24:25 2022 +1000

    Enable PL_ROUTABILITY_DRIVEN and PL_TIME_DRIVEN (#1092)

    ORFS enables both of these by default.

Reproduction Material

openroad_issue_reproducible.tar.gz

Expected behavior

Look for solution route this design

Logs

[INFO GRT-0101] Running extra iterations to remove overflow.
[INFO GRT-0197] Via related to pin nodes: 30523
[INFO GRT-0198] Via related Steiner nodes: 496
[INFO GRT-0199] Via filling finished.
[INFO GRT-0111] Final number of vias: 43657
[INFO GRT-0112] Final usage 3D: 333964
[ERROR GRT-0118] Routing congestion too high.
Error: resizer_routing_timing.tcl, 53 GRT-0118
child process exited abnormally

[INFO]: Saving runtime environment...
[INFO]: Creating reproducible...

[maliberty]

This block has a high aspect ratio so you will have extra routing congestion in the vertical layers. I find you can route it with setting GLB_RT_ADJUSTMENT= 0.2

[dineshannayya]

@maliberty Appreciate quick follow-up. Yes with GLB_RT_ADJUSTMENT=0.2 design is able to route. Can you share how this variable impact the routing phase. This block always breaks me with small design change and finding a working combination is always a pain full activity for me. Normally I work with PL_TARGET_DENSITY, CELL_PAD combination.
Is their is recommendation on how to use PL_TARGET_DENSITY, CELL_PAD, GLB_RT_ADJUSTMENT on a complex design.

[maliberty]

You can have routing congestion from different causes.

One scenario is instances very tightly packed together where it is hard to get all the necessary wires in and down to the pins. In this case spreading out the instances is helpful and CELL_PAD will do that. Its a bit of a crude tool as it is global. There is some work in progress to make routability driven global placement handle this more automatically and locally.

Another scenario is that you simple have too many connections for the available wiring, which is what you have here. If you turn on the routing congestion display after global routing you'll see: The problem is not at all local. It is all vertical wire congestion which you can see if you show the congestion by direction: H: V:

In global routing we compute the maximum number of possible wires per area (gcell) and then back off by reducing the available resources according to GLB_RT_ADJUSTMENT. This leaves some slack for the detailed router to work with. Since you are very near the maximum available wiring I tried seeing if the detailed router could still get by with less slack and it worked. In general reducing the conservativeness in global routing may cause detailed routing failures instead.

Lowering the aspect ratio of this block would help it to be more routable and less sensitive.

[maliberty]

There are other scenarios that can cause problems too - for example poor macro placement or narrow channels.

[dineshannayya]

@maliberty Thanks for your detailed explanation ..