grt: do not update resources for pin access during incremental mode#9510
grt: do not update resources for pin access during incremental mode#9510openroad-ci wants to merge 7 commits intoThe-OpenROAD-Project:masterfrom
Conversation
Signed-off-by: Eder Monteiro <emrmonteiro@precisioninno.com>
…nAccess Signed-off-by: Eder Monteiro <emrmonteiro@precisioninno.com>
Signed-off-by: Eder Monteiro <emrmonteiro@precisioninno.com>
Signed-off-by: Eder Monteiro <emrmonteiro@precisioninno.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces optimizations to the addResourcesForPinAccess function by avoiding its execution for designs without macros or PADs, skipping it during incremental iterations, and filtering nets to only iterate over those connected to PADs or macros. While these changes improve efficiency and correctness in incremental mode, there are a few issues regarding the handling of BTerms (boundary pins) which are also PADs. Specifically, BTerms should trigger the has_macros_or_pads_ flag and the net-level isConnectedToPadOrMacro flag to ensure they are correctly processed when necessary. Additionally, the new has_macros_or_pads_ member should be reset in the clear() method to maintain consistency across multiple tool runs.
|
clang-tidy review says "All clean, LGTM! 👍" |
|
clang-tidy review says "All clean, LGTM! 👍" |
|
PR with metric updates: The-OpenROAD-Project/OpenROAD-flow-scripts#3914 |
|
clang-tidy review says "All clean, LGTM! 👍" |
|
clang-tidy review says "All clean, LGTM! 👍" |
2 participants
This PR has three main fixes:
addResourcesForPinAccessfunction for designs that don't have macros/PADs;