Managing Duplicate Pin Routing in OpenROAD

[oharboe]

I have a macro where I need the same output pin to be routed to both the top and bottom of the macro.

Currently, I achieve this by modifying the Verilog code to include duplicate pins, assigning one for the top and one for the bottom, and connecting the respective Verilog code to each pin. However, this approach mixes topological concerns with layout concerns, creating a leaky abstraction. It also lengthens turnaround times since the RTL needs to be re-tested and the concern can no longer be handled solely by the backend engineer.

Are there methods or features in OpenROAD that can help manage this issue? Specifically, I am looking for solutions that allow the same signal to be routed to multiple locations without modifying the Verilog code, keeping the logical design and physical layout concerns separate.

There's also an argument to be made that the layout concerns should make it into the Verilog so that it is easier to read the layout concerns from within the Verilog code. The mixing of concerns is from this point of view not a problem, but a solution.

Thoughts/experiences?

[maliberty]

LEF's MACRO has the PIN / PORT construct to handle this case. A PIN is logical and roughly equal to Verilog. A PORT is a set of electrically equivalent shapes (i.e. strongly connected). So you could put the shapes that are internally connected into a single PORT and the router can connect to any or multiple of them. There also exists a weak-connect (connect to one but not multiple) and a must-join model (connect to all) though they are less common.

OR support for all this may be more limited today. Note that in odb PIN=dbMTerm and PORT=dbMPin to add confusion.

[maliberty]

Note that though this all can work on the physical design side that doing timing signoff will be more complex/difficult. Its easy to lose the effect of the internal connection's resistance and/or capacitance.

[oharboe]

I am starting to lean towards that letting backend concerns such as this be mixed into the Verilog is a solution and not a problem...