GRT: Routing congestion too high on shakti-soc

[proppy]

Getting routing congestion error when trying to get https://gitlab.com/shaktiproject/cores/shakti-soc.git thru OpenROAD:

[INFO]: Running Global Routing Resizer Timing Optimizations...
[ERROR]: during executing openroad script /content/OpenLane/scripts/openroad/resizer_routing_timing.tcl
[ERROR]: Exit code: 1
[ERROR]: full log: runs/RUN_2022.04.30_10.58.34/logs/routing/15-resizer.log
[ERROR]: Last 10 lines:
[INFO GRT-0101] Running extra iterations to remove overflow.
[WARNING GRT-0227] Reached 20 congestion iterations with less than 15% of reduction between iterations.
[INFO GRT-0197] Via related to pin nodes: 1111460
[INFO GRT-0198] Via related Steiner nodes: 30432
[INFO GRT-0199] Via filling finished.
[INFO GRT-0111] Final number of vias: 10813091
[INFO GRT-0112] Final usage 3D: 119389056
[ERROR GRT-0118] Routing congestion too high.
Error: resizer_routing_timing.tcl, 68 GRT-0118
child process exited abnormally

The issue can be reproduced using this notebook https://colab.research.google.com/gist/proppy/ff8ea5e98e1c90ca35705dbae9c602b9/shakti-playground.ipynb; also attached the reproducible zip (openroad_issue_reproducible.7z.zip).

Note this looks similar to https://github.com/The-OpenROAD-Project/OpenROAD/issues/1646, and other GRT issues that others (like @urish) had when hardening designs with MPW-5 tooling (while they didn't have congestion issue for the same design with previous MPW tooling); but opening a new issue seems relevant as I'm interested to explore the specifics of this design.

[vijayank88]

@proppy Can you please attach file only with .zip or .tar.gz extension? Unable to extract the .7z.zip contents

[proppy]

openroad_issue_reproducible.tar.gz (compressed in bz2 to be extracted to tar xvjf)

[vijayank88]

its hanging more than 2 hours, still not completed:

[INFO GRT-0053] Routing resources analysis:
          Routing      Original      Derated      Resource
Layer     Direction    Resources     Resources    Reduction (%)
---------------------------------------------------------------
li1        Vertical            0             0          0.00%
met1       Horizontal   41992020      23773517          43.39%
met2       Vertical     31494015      20991656          33.35%
met3       Horizontal   20996010      14692856          30.02%
met4       Vertical     12597606       8220544          34.75%
met5       Horizontal    4199202       2096704          50.07%
---------------------------------------------------------------

[INFO GRT-0101] Running extra iterations to remove overflow.

[proppy]

It did fail ultimatly with the following error:

[INFO GRT-0101] Running extra iterations to remove overflow.
[WARNING GRT-0227] Reached 20 congestion iterations with less than 15% of reduction between iterations.
[INFO GRT-0197] Via related to pin nodes: 1111460
[INFO GRT-0198] Via related Steiner nodes: 30432
[INFO GRT-0199] Via filling finished.
[INFO GRT-0111] Final number of vias: 10813091
[INFO GRT-0112] Final usage 3D: 119389056
[ERROR GRT-0118] Routing congestion too high.
Error: resizer_routing_timing.tcl, 68 GRT-0118
child process exited abnormally

See the following logs: 15-resizer.log

[vijayank88]

@maliberty Please check this issue. Its more than 12Hrs OpenROAD hangs with [INFO GRT-0101] Running extra iterations to remove overflow. at my end.

[proppy]

@antonblanchard mentioned he was also fighting with GRT congestion issues for his MicroWatt 64-bit tapeout for MPW-5 and MPW-6.

I suggested the following tweaks to workaround this:

• reducing PL_TARGET_DENSITY
• reducing GLB_RT_ADJUSTMENT (0.3 → 0.2)
• enabling PL_ROUTABILITY_DRIVEN (which could be enabled thanks to https://github.com/The-OpenROAD-Project/OpenLane/pull/1039)

[luis201420]

I tried to reduce the GLB_RT_ADJUSTMENT but it still has a lot of congestion. @proppy could you run the design reducing the PL_TARGET_DENSITY and then upload the tarball containing the stage of global route?

[maliberty]

@proppy have you tried the last suggestion?

[maliberty]

In your notebook I see:

set ::env(PL_TARGET_DENSITY) 0.80

which is very high. I also see

set ::env(PL_RANDOM_GLB_PLACEMENT) 1

which I recommend you never use. That will certainly increase your routing congestion.

[maliberty]

I tried to run OL in your notebook with slightly different settings (40% util, larger area, non-random placement) but I get:

[INFO]: Running Synthesis...
[ERROR]: during executing: "yosys -c /content/OpenLane/scripts/yosys/synth.tcl -l /content/runs/RUN_2022.07.12_15.54.14/logs/synthesis/1-synthesis.log |& tee /dev/null"
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /content/shakti-soc/asic/e-class-mukut/verilog/module_decoder_func_32.v:448.3-457.6 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Successfully finished Verilog frontend.

25. Executing Verilog-2005 frontend: /content/shakti-soc/asic/e-class-mukut/verilog/BRAM1Load.v
/content/shakti-soc/asic/e-class-mukut/verilog/BRAM1Load.v:0: ERROR: Can not open file `` for \$readmemh.
child process exited abnormally

My changes have nothing to do with yosys so I am not sure how this notebook is supposed to work.

[proppy]

@maliberty the notebook didn't pin yosys version so it's possible that a different one from the original report got used, let me try to refresh it accordingly.

[proppy]

I get the same errors after updating the dependencies, it looks like the following verilog module needs to be disabled: BRAM1Load as we don't really care of pre-initializing BRAM cells in that case (since that those mostly relevant for FPGA)

[maliberty]

Please update when it is passing yosys again.

[vijayank88]

@proppy Any update on this?