@User quite a few people I've been speaking to have had routing congestion issues with mpw5 tools as compared with previous versions. Do you know if anything substantial has changed?

Not to forget that the RAM requirements seem to have increased too. I was able to route my design with 8GB of RAM comfortably before and now it fails with the same size of the design (even 16GB doesn't seem to be enough for me).

We are often tweaking things but there is nothing expected to be breaking. Are you sure it is a router issue or is something caused an increased density to be presented to the router

I generally update my openlane version once a month (roughly). When I first observed the issue, I had filed this ticket. So we could roughly workout from that time to a month before. I'm not sure what openlane or other commits would have gone in between.

Can confirm. My run that was comfortably passing under 8GB, no longer works under 11GB of RAM. Also: Same issue: Super common to have congestion issues and sometimes even segfaults for big designs. I noticed that my design successfully passes the flow with 45ns clock period, but using 10ns the router crashes consistently with segfault.

I noticed that my design successfully passes the flow with 45ns clock period, but using 10ns the router crashes consistently with segfault.

I'm not expert is physical design, but that could be an indication that there are far more cells in the design to close timing and hence the routing congestion. Although in my case the clock period was fixed to

10ns

.

@User is there an open issue for the segfault?

I certainly can try, but it will have to be after 8th of April 🙂. Still plenty of things to do to hit the shuttle date.

That's ok, I have plenty of things to do too 🙂

I have not created an issue regarding this. But it certainly in my plans

@User if you want results sooner you might help with isolating the issue

Same here, routing congestions have been an issue once place density goes above 35%.

could it be related to the change of GLB_RESIZER_TIMING_OPTIMIZATIONS now defaulting to 0? https://github.com/The-OpenROAD-Project/OpenLane/commit/569e10c86826864d2f01927a883ef4a0da3aaf74

I've built user_proj_example for the vanilla caravel_user_project with both mpw-3a & mpw-5c toolchains and compared the detailed routing phase. For mpw-3a it reached zero violations during the 4th iteration taking 127 seconds of cpu time and using 648 MB of ram. For mpw-5c it reached zero violations during the 15th iteration taking 429 seconds of cpu time and using 2421 MB of ram. Before doing further analysis, could someone from the core team reproduce these results to rule out user error in my installation of the toolchains?

@User the existing of that option is itself rather new so I don't think it will explain it.

@User mpw-3a toolchain openlane: 6905a12d2efe18502c37c3207b5ee84cdf720d9c caravel-lite: 477c17fb986b0d3f7f3581e940095b68bd62422f skywater-pdk: c094b6e83a4f9298e47f696ec5a7fd53535ec5eb open_pdks: 14db32aa8ba330e88632ff3ad2ff52f4f4dae1ad docker image: efabless/openlane:mpw-3a mpw-5c toolchain openlane: e4bfdd7834f90d7f276af72fcf074aef8e002597 caravel-lite: 477c17fb986b0d3f7f3581e940095b68bd62422f skywater-pdk: c094b6e83a4f9298e47f696ec5a7fd53535ec5eb open_pdks: 7519dfb04400f224f140749cda44ee7de6f5e095 docker image: efabless/openlane:2022.02.23_02.50.41