Huge runtime for AES sky130hd

The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/

https://theopenroadproject.org/

BSD 3-Clause "New" or "Revised" License

1.42k stars 496 forks source link

Huge runtime for AES sky130hd #5305

Open gadfort opened 4 days ago

gadfort commented 4 days ago

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 commented 4 days ago

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

gadfort commented 4 days ago

@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 commented 3 days ago

Ok let's look at both

gudeh commented 1 day ago

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 commented 1 day ago

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 commented 18 hours ago

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 commented 17 hours ago

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 commented 17 hours ago

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 commented 17 hours ago

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