The-OpenROAD-Project
Improve user-experience for long global route run failures
Description
untar and run https://drive.google.com/file/d/1Nw162pCjs1HjxjzeW35vl49Qgw9_bp8D/view?usp=sharing
After 7 hours global routing fails, but there's no specific actionable advice in the logs:
[ERROR GRT-0116] Global routing finished with congestion. Check the congestion regions in the DRC Viewer.
Elapsed time: 7:06:08[h:]min:sec. CPU time: user 44323.79 sys 870.38 (176%). Peak memory: 58027380KB.
As a user my strategy here would be:
use bazel-orfs to explore some PLACE_DENSITIES, ROUTING_LAYER_ADJUSTMENT values and examine results. This would take a few days though.
I also suspect that improvements in macro placement could help, but I'm unsure how to prod macro placement to create a better starting point for global routing.
Suggested Solution
Log something at the end that is quantifiable and actionable or if it is hopeless let the user know that they should "give up"(something to the effect: there's no way that this is going to work, you have to increase the area).
Additional Context
No response
Smaller macro halos looks like a place to start to fix this.
@eder-matheus suggestions on what else we can report?
Smaller macro halos looks like a place to start to fix this.
@eder-matheus suggestions on what else we can report?
Can we can your knowledge in C++ and add a warning/info?
grt: try reducing halo from xx to yy.
Also, isnt the halo a global value? Shouldnt it be per group? Auto by default?
@oharboe GRT doesn't know about halos. This information isn't stored in ODB and AFAIK, only MPL uses it.
@maliberty One thing we can add is a suggested value for the adjustment value (issue https://github.com/The-OpenROAD-Project/OpenROAD/issues/6638). We can give some priority to this task. If GRT finds that no adjustment value would help in this case, we might thrown a message about increasing die area, but I don't think GRT is able to specify a suggested value for it.
This is not a high priority issue for me, I just wanted a better broader articulation of a previous grt issue: improve user experience of grt.
outputting recommended layer adjustment sounds great!
I think the user experience of macro placement is a separate concern and that macro placement should output recommended halo. As far as grt is concerned, I think reduced macro placement halo is effectively the same as increasing available area here.
If the answer is that there are no further actionable item here; what is needed is someone skilled in the art of grt to see what could be attempted and that the current information is adequate for that, then this issue should be closed as working as intended and the closed issue is part of the documented body of knowledge of openroad.
Global routing is only as good the placement.
- Does your RUDY map correlate with the global route one ?
- If yes, don't bother with global route til it looks good.
- If not, file a bug report. Placement routing estimates have to correlate with global route.
Placement is only as good as the netlist connectivity allows. In a lot of cases, cell area optimizing synthesis of large fanout busses cause issues.
- If the placer pulls things together it's because things are tightly connected.
- If you have design knowledge, check how your "connecting everything" muxes are synthesized. Look out for AOI graves instead of MUX implementations.
- AOI graves that are bad for any placement, 2:1 muxes are much better for wire length constraint technologies (every technology from this millennium)
- If you have AOI graves, then you need a placement based synthesis tool. No amount of area increase or fiddling with placement options can create a good placement of a bad netlist.
Module hierarchy coloring is usually not a good way to visualize connectivity.
- OpenRoad has a cone tracer as part of the timing debug.
- It's not nearly as feature rich as it could be, but helps in understanding connectivity.
- E. g. it would be very helpful to be able to select stdcells in congested area's and then use different colors for the input and output cones of the combinatorial cells
I've not tried. I don't have any designs that I synthesize and where I have design knowledge or a timing setup. I was under the impression that cone tracing depends on timing libs and constraints, one needs at least the lib for sequential/combinatorial cell identification, right ?
Trying to translate this knowledge into improved user-experience:
- Add GLOBAL_ROUTE_CHECK_RUDY=1/0, default 1. If global rout e thinks that this is a lost cause based on RUDY, don't start global route. This a) always produces a placement result b) stops wasting time on global routing that can never work c) points the user in the right direction, iterate on placement d) allows the user to proceed with global routing result to check RUDY for correctness.
- If you have design knowledge, check how your "connecting everything" muxes are synthesized. Look out for AOI graves instead of MUX implementations.
- AOI graves that are bad for any placement, 2:1 muxes are much better for wire length constraint technologies (every technology from this millennium)
- If you have AOI graves, then you need a placement based synthesis tool. No amount of area increase or fiddling with placement options can create a good placement of a bad netlist.
Sounds like years of experience... Can this be articulated as a warning or a metric that can clue in ChatGPT :-) or the user?
These days, I think warnings that clue in ChatGPT/the user are much more valuable that a manual that nobody reads. This github issue will go into what can be searched and fed into a more specialized AI model for OpenROAD.