The-OpenROAD-Project / The-OpenROAD-Project/OpenROAD

DRT: Compatibility Oriented Pin Access

Open
#10,486 2 comments 0 reactions 1 assignee View on GitHub

@bnmfw is already working on this.

Since May 21, 2026.

drt
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.

Image

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.

Image

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.