Question about straight wire routing between macros

[oharboe]

Below are two macros next to eachother where I have mirrored the pins, so the connections are nice and horizontal.

The pins are on ASAP7 M4, but the route is on M2.

Looking at the image, I'm curious as to why M4 wasn't just used in a straight line across? Why go via M2?

The reason I'm asking about this is that my design does detailed routing quickly when I scale it down, but as I scale up, add more macros and a wider data path, it seems like detailed routing has to spend more time(ca. 20x longer) getting signals from M2, to M4 and back to M2 to do the routing between macros. I believe there is non-linear increase(with datapath width) in complexity with getting signals from M4 to M2 and back to M2.

[maliberty]

does this happen on the mock array?

[maliberty]

If you select one of the nets, in the inspector there is an option to show the route guide. It would be interesting to see what the guide for one of these nets looks like.

[oharboe]

[maliberty]

The global router prefers to put wires on lower layers, which is a good strategy for standard cell connections. It isn't so good here.

@eder-matheus I think we should update the 3d embedding in grt to handle the case where the pins being connected are all at layer N or above to avoid layers below N if possible. Would you take care of this or work with Luis or Arthur to do so.

[eder-matheus]

I can take it. I'm more familiar with this code, and this update might be a bit tricky to implement.

[eder-matheus]

@oharboe Could you try this branch: https://github.com/eder-matheus/OpenROAD/tree/grt_upper_layer_nets?

[maliberty]

@eder-matheus he does not have access to the private repo. Please sync it to public in a PR.

[eder-matheus]

My bad. It was supposed to be the link from my fork. I've updated it with the correct one.

[QuantamHD]

@eder-matheus I looked at the code, and it seems like this code is setting the min routing layer to the layer the pins are on. Isn't this going to cause a problem if there's an obstruction on that layer?

[eder-matheus]

If you have room on the upper layers, the router should be able to complete. Otherwise, grt will probably fail with high congestion.

[maliberty]

If you had an obs that you couldn't go over or around then it could be an issue. However it is similar to the clock net constraints we already have that are similar. Probably we would need to introduce a costing scheme to allow out of range layers to be used in extreme cases but that seems like a separate enhancement.

The motivating case is simply two m4 pins that have an easy planar connection but we drop down to m2 for no good reason (the router prefers lower layers on the erroneous assumption that pins are on the lower layer).

[QuantamHD]

This solution is artificially constraining the solution space to guide that particular case at the cost of things just not working in others. Which would be okay if GRT had a way to break out if these nets were unroutable, but it doesn't.

This case seems really common and useful, but its implementation seems too coarse.

[maliberty]

The problem is actually much harder as we initially route in a 2d space. Should the capacities reflect the other layers or not (if yes you may find you are forced to use a lower layer when another upper layer path exists; if not you can't see those resources to use). Do you have an algorithm in mind to solve this?

[QuantamHD]

I would attempt to route using @eder-matheus's solution, but if it failed i'd rip up and reroute, and try again with one more metal layer.

[QuantamHD]

Beyond the hypothetical obstruction if the pins on the left and right aren't identically ordered you may run into these issues as well.

[maliberty]

You would only run into issues if every other layer above was blocked which is unlikely. People designing arrayed layouts don't generally swizzle the pin order.

[oharboe]

Master is MUCH better with this now. If the route is not straight, there's generally a reason, like powergrid in the way, buffers added at edge of design before pins, or something.