Slow detailed routing convergence

[oharboe]

I was curious what was difficult about detailed routing for a design, so I stopped detailed routing after 4 iterations, using The-OpenROAD-Project/OpenROAD-flow-scripts#791, then looked at 5_route_drc.rpt.

Here it seems like there is a lot of congestion at the top of macros because the power strip is running inside the halo (?) of the macro.

Howevever here is a macro, just like the one above where detailed routing doesn't seem to have a problem dealing with this issue:

Perhaps nothing is wrong here and it just takes a while to do detailed routing.

Is there anything to learn or that I can do different here?

[maliberty]

How many iterations does it take to complete? In general drt is the slowest step of the flow but it also looks like something is going on here.

In the lower picture the wires appear to go straight in on m5 but in the upper the go up to a higher layer and then try to drop down (which is blocked by the strap). I'm not clear why they can't go straight in from the image. Can you tell?

[oharboe]

How many iterations does it take to complete? In general drt is the slowest step of the flow but it also looks like something is going on here.

If I leave it as above, then 50 iterations or so. If I reduce the height of the macro slightly, then it completes in 5 iterations or so.

In the lower picture the wires appear to go straight in on m5 but in the upper the go up to a higher layer and then try to drop down (which is blocked by the strap). I'm not clear why they can't go straight in from the image. Can you tell?

To me it is a mystery why the two are different. It is the same macro repeated and there's nothing else in the vicinity. I believe this should be reproducible using this design: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/mock-array-big

The problem should appear on the top row.

The good news is if this problem can be understood and dealt with, then the detailed routing times should drop dramatically.

[oharboe]

I can see the same problem on https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/mock-array-big

Zooming in, we can see that different metal is being used:

To reproduce the image above, first build, but abort after 5 iterations in detailed routing, then load the 5_route_drc.rpt and zoom in:

make DESIGN_CONFIG=designs/asap7/mock-array-big/Element/config.mk generate_abstract
make DESIGN_CONFIG=designs/asap7/mock-array-big/config.mk DETAILED_ROUTE_ARGS=\"-bottom_routing_layer M2 -top_routing_layer M7 -save_guide_updates -verbose 1 -droute_end_iter 5\"
make DESIGN_CONFIG=designs/asap7/mock-array-big/config.mk

[maliberty]

@osamahammad21 I think looking at this issue in the context of asap7/mock-array-big fits with your other drt performance work.

[maliberty]

Your pins are off the routing grid:

which I guess is why the router is gyrating to hit them.

[maliberty]

The grid is defined in https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/platforms/asap7/openRoad/make_tracks.tcl

I tried shifting the macros on grid and I get an error from global placement which I need to look at. I've attached the file for reference (I had to change .cfg to .txt to make GH happy)
macro-placement.txt

[oharboe]

I'm wondering why macro-placement.cfg allows non-aligned coordinates... Perhaps having the option to source a .tcl file instead of parsing the .cfg for placement would make sense? From .tcl, presumably, I can easily get to the routing grids values and align myself, rather than hack a python script & do manual lookup in the ASAP7 definition files.

Then again... Perhaps there could be some sort of constraints defined for macro placement and then macro placement can be done automatically, leaving all this detail to OpenROAD. In the mock-array-big example, the constraint is to place the macros in suitable distance in an array. It's what I'm trying to do manually, but I'm not aware of all the snags...

[maliberty]

That option is full manual control. We could add a command to snap the macros to the routing grid.

[oharboe]

Makes sense. That would dovetail nicely with sourcing a .tcl file instead of parsing a .cfg file... Sourcing .tcl files for configuration is done elsewhere. I wonder why it isn't done here.

[maliberty]

Just historical I suppose. We used to have more cfg files in the past.

I did manually skip over global placement (since there is nothing to place at the top level) and drt finishes on iter 5.

@osamahammad21 we should still be able to do better on the offgrid case.

[maliberty]

@osamahammad21 with the PRs from this morning this case now finishes with 0 drvs. However it reaches 2 drvs by the end of iter 4 but takes until iter 13 to reach zero. At the end of iter5 I see two cut spacing violations. They both look easy to fix, eg

you should readily move the via to the right by one track. I guess this is a costing issue.

[antonblanchard]

I missed this because it was hiding in discussions. I have noticed various issues with via spacing in drt, eg #2827 and #2844, so likely issues in both route cost and GC (drc).

[oharboe]

Near as I know all of these issues are resolved on master.