rsz: fix tie placement status#10074
rsz: fix tie placement status#10074gudeh wants to merge 9 commits intoThe-OpenROAD-Project:masterfrom
Conversation
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
|
This should require metrics update. Secure-CI is running at: https://jenkins.openroad.tools/blue/organizations/jenkins/OpenROAD-flow-scripts-Private/detail/secure-rsz-fix-tie-placement/2/pipeline |
![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
This pull request updates the createNewTieCellForLoadPin method in src/rsz/src/Resizer.cc to handle cases where a load pin's instance is not placed. In such instances, the newly created tie cell is now explicitly marked as unplaced to avoid using meaningless coordinates. Additionally, a debug print statement was added to log the tie instance creation details. I have no feedback to provide as no review comments were submitted.
|
clang-tidy review says "All clean, LGTM! 👍" |
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
|
secure-CI presented 4 designs with fatal failures |
|
clang-tidy review says "All clean, LGTM! 👍" |
|
clang-tidy review says "All clean, LGTM! 👍" |
|
sky130hd/riscv is failing at GRT. I see this expected difference comparing to master, where GPL does not use the initial position from ODB for 32 TIE cells anymore: master placement at 4-1 (left) versus branch placement at 4-1 (right). Highlighted instances are the TIE cells. and this is RUDY at 4-1 master by left and branch by the right: I made a diff with all the logs between the two and I see nothing strange. Any tips on what to investigate? @maliberty |
|
sky130hd/riscv can just be updated but there are other failures in the CI here to fix |
|
clang-tidy review says "All clean, LGTM! 👍" |
|
clang-tidy review says "All clean, LGTM! 👍" |
Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
|
clang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
|
clang-tidy review says "All clean, LGTM! 👍" |
3 participants
Summary
During
repair_tie_fanoutcommand we insert TIE cells, they are currently being placed at the origin (0,0) but being set as PLACED, which is incorrect. This PR sets them as UNPLACED if the load pin's instance is not placed.This change implies functional changes since GPL will initiate instances other than the ODB given position (which was 0,0).
Type of Change
Impact
No more cluttered instances at the origin at stage 2-1.
Verification
./etc/Build.sh).Related Issues
#9804
https://github.com/The-OpenROAD-Project-private/OpenROAD-flow-scripts/issues/1565