Skip to content

mpl: fix io blockages' micron -> dbu conversion and add tests#6834

Merged
eder-matheus merged 1 commit intoThe-OpenROAD-Project:masterfrom
AcKoucher:mpl-boundary-push-fix
Mar 14, 2025
Merged

mpl: fix io blockages' micron -> dbu conversion and add tests#6834
eder-matheus merged 1 commit intoThe-OpenROAD-Project:masterfrom
AcKoucher:mpl-boundary-push-fix

Conversation

@AcKoucher
Copy link
Contributor

@AcKoucher AcKoucher commented Mar 11, 2025

Resolve #6821

During the initialization of the Pusher class - which is the responsible for the boundary pushing step - we're messing up the creation of the dbu blockage by using the wrong mpl::Rect APIs.

Signed-off-by: Arthur Koucher <arthurkoucher@precisioninno.com>
@AcKoucher
Copy link
Contributor Author

Running Secure-CI

@github-actions
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link
Member

@maliberty maliberty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine; awaiting CI

Comment on lines -3097 to -3098
= odb::Rect(block_->micronsToDbu(box.getX()),
block_->micronsToDbu(box.getY()),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The is a confusing API. Perhaps getCenterX/Y would make it more obvious.

@AcKoucher
Copy link
Contributor Author

I got one problem in Secure-CI:
The number of hold violations in ngt45/bp_fe_top went from 167 -> 1354 violating the limit which is 309.

The macro placement is slightly different, because the 2x4 array is not being pushed to the right edge anymore, as it is correctly identifying the pin access blockage that lies there. (There are only unconstrained pins in this block and they're excluded from the top edge, meaning left/bottom/right have pin access blockages).

image

Overall, the paths look relatively similar when comparing base/branch (I didn't compare many). However, paths that had their required hold time being met now are being violated due to a subtle increase in the required time:

image

The problem seems to be related with the capture path and that could indicate a problem caused by CTS. However, apparently there are no hold violations just after CTS.

I'll investigate the evolution of the hold violations along the flow.

@AcKoucher
Copy link
Contributor Author

AcKoucher commented Mar 13, 2025

The investigation of the hold violations along the flow showed that these violations actually arise during detail route. This points in the direction of the necessity of having a post-drt repairing stage (there's already work being done in that regard).

However, CTS results for this design are somewhat bad. Specially, because, as there's no insertion delay and we currently make the decision to split macros from regs when creating the clock tree based on it, we end up with a clock tree for both macros/regs.

I opened #6845 for CTS (using .LEF instead of insertion delay as decision taker solves all the violations here).

@eder-matheus eder-matheus merged commit 9dbe447 into The-OpenROAD-Project:master Mar 14, 2025
11 checks passed
@AcKoucher AcKoucher deleted the mpl-boundary-push-fix branch March 14, 2025 13:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mpl: add regression tests for boundary pushing step

3 participants