Megaboom: 20k routing congestion DRCs with just 0.24 placement density

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.62k stars 561 forks source link

Megaboom: 20k routing congestion DRCs with just 0.24 placement density #6066

Open jeffng-or opened 3 weeks ago

jeffng-or commented 3 weeks ago

Describe the bug

The current BoomTile design fails global routing with 20k routing congestion DRCs, but the placement density is only 0.24. There appears to be a lot of space especially at the top of the design.

The tarball with the design data can be found at: https://drive.google.com/file/d/15grexnVmOSpRFUK8gHTMJj7DnZpPgzpL/view?usp=sharing

Expected Behavior

Either better placement or the ability to global route the design.

Environment

ORFS v3.0-1735-gdefc349e (https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/commit/defc349ec719f45e115b85e317e95db86769e439)

To Reproduce

After unpacking the tarball, you can bring up the GRT view in the GUI with:

run-me-BoomTile-asap7-base.sh gui

The gui keyword will bring up the GUI.

Relevant log output

No response

Screenshots

placement density
placement_density

routing congestion routing_congestion

Additional Context

No response

maliberty commented 3 weeks ago

@jeffng-or did increasing the number of overflow iterations help?

jeffng-or commented 3 weeks ago

@jeffng-or did increasing the number of overflow iterations help?

It's currently running as part of my sweep. Will report back once it's completed

oharboe commented 3 weeks ago

@jeffng-or did increasing the number of overflow iterations help?

No, I checked, the artifact is available for the git commit below. Here is after 30 iterations(default GLOBAL_ROUTE_ARGS).

Note that I think the number of markers is capped at 10000, but one could hope that the 10000 markers are representative for where the congestion is?

$ git log -1
commit 30811e018e7cbb10634e43f70e486d27e245d7a5 (HEAD, origin/variants-macro-placement)
Author: Øyvind Harboe <oyvind.harboe@zylin.com>
Date:   Thu Oct 31 08:24:42 2024 +0100

    variants: macro placement from hierarchical synthesis

    Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
$ bazel run BoomTile_grt /tmp/grt gui_grt

oharboe commented 3 weeks ago

I've created make global_place_issue to reproduce the global place run for the congestion seen above:

$ git log -1
commit 30811e018e7cbb10634e43f70e486d27e245d7a5 (HEAD, origin/variants-macro-placement)
Author: Øyvind Harboe <oyvind.harboe@zylin.com>
Date:   Thu Oct 31 08:24:42 2024 +0100

    variants: macro placement from hierarchical synthesis

    Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
$ bazel run BoomTile_place_deps /tmp/place 
$ /tmp/place/make do-place
[ctrl-c when it gets to global place, now I have all the dependencies required]
$ /tmp/make global_place_issue

untar https://drive.google.com/file/d/1LB_ZLO8vRxypvDIrHVak2bpYESvFahHG/view?usp=sharing

./run-me-BoomTile-asap7-base.sh

jeffng-or commented 3 weeks ago

@oharboe , thanks for the confirmation. I tried running the 30 iterations in a sweep, but the multiple jobs killed my machine.

oharboe commented 1 week ago

Is anything more known about this issue at this point?

eder-matheus commented 1 week ago

Is anything more known about this issue at this point?

We are investigating with this design and a few others related to megaboom, and we could finish GRT by changing the routing layer adjustments from 0.45 to 0.2. I guess the 0.45 value came from other designs in asap7 that uses it, but 0.2 for megaboom seems more reasonable. We also changed the number of congestion iterations to 35 to complete BoomTile.

oharboe commented 1 week ago

"layer adjustment" could do with some elaboration in the docs. what does it mean? what does a high/low value do? What are the pros/cons?

Any luck in an understanding looping around the macro multiple times?

eder-matheus commented 1 week ago

"layer adjustment" could do with some elaboration in the docs. what does it mean? what does a high/low value do? What are the pros/cons?

This is defined in the docs: https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/grt#set-global-routing-layer-adjustment. In summary, we reduce the resources that the global router have to route the design, in order to avoid congested regions for the detailed router. Using higher values would produce less congested areas in DRT, but values too high can make GRT to not complete.

Any luck in an understanding looping around the macro multiple times?

I'm not sure what is this about. @jeffng-or could you comment on this?

jeffng-or commented 1 week ago

Regarding the looping path, the issue is tracked in https://github.com/The-OpenROAD-Project/OpenROAD/issues/5971. @precisionmoon looked at it and commented on it. No new information beyond that at this point.

oharboe commented 1 week ago

"layer adjustment" could do with some elaboration in the docs. what does it mean? what does a high/low value do? What are the pros/cons?

This is defined in the docs: https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/grt#set-global-routing-layer-adjustment. In summary, we reduce the resources that the global router have to route the design, in order to avoid congested regions for the detailed router. Using higher values would produce less congested areas in DRT, but values too high can make GRT to not complete.

Thanks! This makes things clearer.

I am having a bit of trouble connecting the dots from ORFS variables to OpenROAD documentation/options/commands. Perhaps variables.yaml could be extended with fields to link to corresponding OpenROAD commands and options.

I think some more convenience in docs of ORFS variables could mitigate my lack of spelunking efforts to connnect the dots.

eder-matheus commented 1 week ago

Thanks! This makes things clearer.

I am having a bit of trouble connecting the dots from ORFS variables to OpenROAD documentation/options/commands. Perhaps variables.yaml could be extended with fields to link to corresponding OpenROAD commands and options.

I think some more convenience in docs of ORFS variables could mitigate my lack of spelunking efforts to connnect the dots.

I can work on improving the correlation between OR and ORFS documentation. There's a bunch of things in OR, so I totally understand the difficulty to find things from ORFS in OR. I will start with the tools I'm more familiar with.

oharboe commented 1 week ago

Thanks! This makes things clearer.

I am having a bit of trouble connecting the dots from ORFS variables to OpenROAD documentation/options/commands. Perhaps variables.yaml could be extended with fields to link to corresponding OpenROAD commands and options.

I think some more convenience in docs of ORFS variables could mitigate my lack of spelunking efforts to connnect the dots.

I can work on improving the correlation between OR and ORFS documentation. There's a bunch of things in OR, so I totally understand the difficulty to find things from ORFS in OR. I will start with the tools I'm more familiar with.

Let us give this some tought and not jump right in.

I think I would like to see changes to variables.yaml and autogenerate links and documentation.

Start by creating a github feature request to ORFS?