The-OpenROAD-Project / The-OpenROAD-Project/OpenROAD
DRT: Compatibility Oriented Pin Access
@bnmfw is already working on this.
Since May 21, 2026.
- Dominant language
- Verilog
- Stars
- 3.1k
- Forks
- 1k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 136
Description
Description
Advanced nodes frequently have both LEF58_RIGHTWAYONGRIDONLY and LEF58_RECTONLY properties. This make so every possible access point is of the OnGrid/OnGrid type. In turn, this makes so every possible valid access pattern has the same cost, making the choice of any completely arbitrary, the first one in the loop.
However, even though all access points are OnGrid/OnGrid not every ap has the same quality. In hard to route PDKs access point compatibility is very valuable. For example, say an instance has two pins. One of these pins has two access points, both OnGrid/OnGrid, the other pin has four. If the first of the access points on the first pin is compatible with all four of the other pin, while the second of the access points on the first pin is incompatible with one of the four, making it only compatible with three. We can therefore assign an integer to each access point determining the number of compatible neighbors it has.
Access Points with higher compatibility scores are more desirable. If pin 1 and 2 have highly compatible access points the router can change which access point is being used on pin 1 while keeping the access on pin 2, because it is most likely compatible with the new choice. Using highly compatible access points as the proffered ones would be better than just any arbitrary pattern.
Suggested Solution
The compatibility idea is already encompassed in the usual access pattern creation of pin access. During the creation of the flow graph the compatibility of a given access point is just the degree of its node in the access pattern graph, so calculating this information is almost free.
Choosing the best access pattern based on compatibility can be tricky. The graph still has to optimize for access type quality, compatibility only has to be significant during tie breaking (In advanced PDK it is always tied). Multiple solutions can be implemented to allow for this.
Additional Context
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.