Huge runtime for AES sky130hd

[gadfort]

Describe the bug

In the CI runner, the AES sky130hd takes 3+ hours to complete, while other platforms are < 30 mins (except for ihp130, which is 1hour+). This appears to be related to the large number of shorts reported after iteration 0: 22k+ (which take 50 iterations to resolve, a little over 2 hours), the same can be said for ihp130.

Expected Behavior

Routing runtimes based on the selected density settings that are comparable with other platforms with a lower number of initial shorts.

Environment

Jenkins CI env.

To Reproduce

Observed via jenkins interface, should be reproducible.

Relevant log output

https://jenkins.openroad.tools/blue/rest/organizations/jenkins/pipelines/OpenROAD-flow-scripts-Public/pipelines/public_tests_all/branches/master/runs/1285/nodes/123/steps/1227/log/?start=0

Screenshots

No response

Additional Context

No response

[maliberty]

This looks to be drt slowing down due to a tighter placement

vs

[gadfort]

@maliberty I'm concerned with the number of shorts that DRT is reporting (ihp130 has the same issue). This problem has been around for a while is the reason for sky130, gf180, and ihp130 having larger routing times than others. I think it's worth exploring if this is a routing guide issue or a DRT issue. Placement wise this doesn't look like it would require 22k shorts.

[maliberty]

Ok let's look at both

[gudeh]

This looks to be drt slowing down due to a tighter placement

vs

Hi @maliberty, this prints are from which versions exactly? Is it rudy vs grt on routability?

[maliberty]

The tighter one is rudy. I didn't save the version but it was just a few days ago I don't think it will have changed much.

[gudeh]

I tried inflating a lot more during gpl routabiltiy and this is the placement:

Although we still get a lot of DRCs in the beginning of DRT (left is master, right is more inflation):

Notice a really high elapsed time at each iteration, running on gcp. I am waiting for it to finish so I can investigate the DRCs.

[maliberty]

Would you include the placement image at drt as it is possible more instances where inserted post-gpl that are causing the problem and it can't be fixed in gpl.

[gudeh]

from make gui_place:

from make gui_5_1_grt:

And routing congestion from make gui_5_1_grt:

I will send from DRT after it finishes.

[maliberty]

drt won't change the placement so that's fine. It doesn't appear to be a post-gpl increase issue.

[gudeh]

For some reason DRT is running with only a few cores (up to 4 it seems) on my gcloud machine. It has been running for a whole day, and each 10% of an iteration is taking from 10min to 1 hour. It has not finished yet.

Either way, here are the DRCs after inflating more on gpl.

Here are some of the DRCs.

I can provide more information if needed.

I just started a run using grt instead of rudy in gpl routability to see what happens.

[gudeh]

Using grt on routability:

Using rudy with more inflation than master:

Current master with rudy and less inflation:

[eder-matheus]

@gadfort I've changed the global routing resources configuration for sky130hd/aes, reducing more resources than before, and DRT completes the design in 9 minutes. Similar to what happened with sky130hs/riscv32i in PR https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2142, it also had multiple shorts that were created due to GRT assigning too many nets to the same region.

We're tracking this issue in https://github.com/The-OpenROAD-Project/OpenROAD/issues/5391, so can this issue be closed?

[gadfort]

@eder-matheus this is also tracking issues from GPL, so we cannot close this.

[osamahammad21]

Update: I removed the drt tag since this doesn't seem to be drt issue.

[gudeh]

@eder-matheus this is also tracking issues from GPL, so we cannot close this.

Hi @gadfort, would mind explaining exactly what you see as an issue concerning gpl?

[gudeh]

Something that seems unusual for sky130hd/aes is that it has some placement density hotspots after placement.

After my recent GPL modification, where we keep the changes made by RSZ repair_design during timing-driven iterations (PR https://github.com/The-OpenROAD-Project/OpenROAD/pull/6165)), none of the other designs showed density hotspots—sky130hd/aes is the only one still exhibiting them!

The hotspots are located along the borders of the routing congestion regions, suggesting that routability mode may be moving the cells excessively during the inflation procedure. This behavior does not occur in other designs. On the current master branch, the first routability iteration is applying a +92% increase in area, with one iteration even reaching a 292% increase in area!

Does any of this relate to your concern regarding GPL on sky130hd/aes?