Skip to content

mpl: real-design packing problems as a gtest, and mpl_bench - #11809

Open
oharboe wants to merge 10 commits into
The-OpenROAD-Project:masterfrom
oharboe:mpl-placement-problems
Open

mpl: real-design packing problems as a gtest, and mpl_bench#11809
oharboe wants to merge 10 commits into
The-OpenROAD-Project:masterfrom
oharboe:mpl-placement-problems

Conversation

@oharboe

@oharboe oharboe commented Oct 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Opened for discussion, and offered: take it or leave it. You may well prefer another way to test mpl. This is what suited me for fast iteration.

Stacked on #11808; review only the last four commits.

Two things:

  • The packing problems mpl's annealer is asked, extracted from ORFS designs, as a fast gtest. 136 problems from 18 ORFS designs (asap7, gf180, nangate45) and XiangShan's parent floorplan, written in a plain-text form one line per block. Wherever the annealer placed the macros, the exact check from mpl: settle MPL-0003 with an exact packing check, and prove what does not fit #11808 must find a legal placement too; wherever it proves that they do not fit, the fix it proposes must fit. A problem the annealer could not place either may stay undecided; one, at 99% fill, does. The test takes 6.8 s in 4 shards.
  • mpl_bench, a manual binary (tagged manual, not run in CI) that runs the macro placer on an ORFS 2_1_floorplan.odb as often and with as large an annealing budget as asked, and prints per run the wall time, whether it placed, and the half-perimeter wirelength of the nets that touch a macro. MacroPlacer::setAnnealingSteps is its only caller. The numbers in mpl: stop annealing once the best result stops improving #11807 come from it. It does not need the exact check: it lifts out of this stack with setAnnealingSteps alone.

The text form doubles as a reproducer format: a problem that misbehaves can be pasted into an issue and read back with readPackingProblem().

The extraction tooling and the full study: The-OpenROAD-Project/bazel-orfs#1290.

Commits

  1. MacroPlacer::setAnnealingSteps sets the annealing budget (default 2000)
  2. a plain-text form of a packing problem, with a round-trip test
  3. mpl_bench
  4. the real-design packing problems as a gtest

Claude made the changes and stared at paint drying.

🤖 Generated with Claude Code

@oharboe @claude
mpl: shapes as a library of their own
53d8288 
Tiling and Interval are plain value types; a library of their own lets
code that needs only them depend on them without object.cpp and odb.
No change in behaviour.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This was referenced Oct 17, 2026
Open
Open
@github-actions

github-actions Bot commented Oct 17, 2026

Copy link
Copy Markdown
Contributor

This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size.

This was referenced Oct 17, 2026
Closed
Closed
gemini-code-assist[bot]
gemini-code-assist Bot reviewed Oct 17, 2026
View reviewed changes

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request introduces an exact fixed-outline packing feasibility checker using the OR-Tools CP-SAT solver, integrating it as a fallback mechanism when annealing fails to find a valid tiling. It adds adapter classes to map the macro placer's internal representations to the packing problem, provides detailed user-facing explanations for packing failures, and includes comprehensive unit tests and benchmarks. The code review identified several critical robustness issues in the new code, such as potential division-by-zero errors, infinite loops in the bisection search, null pointer dereferences, out-of-bounds accesses, and undefined behavior with std::isspace. Resolving these edge cases is highly recommended to ensure the stability and safety of the solver integration.

Comment thread src/mpl/src/packing.cpp
Comment thread src/mpl/src/packing.cpp
Comment thread src/mpl/src/packing.cpp
Comment thread src/mpl/src/packing.h
Comment thread src/mpl/src/packingAdapter.cpp
Comment thread src/mpl/src/packingAdapter.cpp
Comment thread src/mpl/src/hier_rtlmp.cpp
Comment thread src/mpl/src/packing.cpp Outdated
oharboe and others added 8 commits October 17, 2026 10:50
@oharboe @claude
mpl: exact fixed-outline packing check
0f047d6 
checkPacking() decides whether rectangles fit in a fixed outline without
overlap, with OR-tools CP-SAT, which OpenROAD already links: rigid blocks
with one or more shapes, soft blocks whose height is floor(area / width)
as SoftMacro computes it, and fixed blocks. The answer is kFits with a
placement, kDoesNotFit with a cause (a block too wide or too tall, the
area, or the arrangement), or kUndecided when the deterministic budget
runs out; it does not depend on machine load or thread scheduling.

Cheap bounds and constructions settle most problems first: a block that
fits nowhere, the area, blocks wider than half the outline that must
stack, identical blocks that must fit as a grid, and a shelf packing. The
rest go to CP-SAT on a ladder of grids, coarse first: rounding blocks up
gives placements legal at full resolution, rounding them down gives
proofs that nothing fits. Nothing calls it yet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: the smallest outline at which a packing fits
57f2827 
smallestHeight(), smallestWidth() and smallestSameAspect() bisect over
exact checks for the one outline change that makes a problem fit, on a
given grid (rows, sites); a bigger outline never makes a packing
impossible, so a bisection is exact. The questions share one budget, and
an undecided one widens the reported range instead of stalling.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: words for why a packing does not fit
faa55b4 
explainDoesNotFit() states that the problem is proven not to fit, its
cause, and each single change to the outline that fixes it, in microns.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: the annealer's question as a packing problem
a47a8f2 
toPackingProblem() states what an annealer is asked: its sequence-pair
macros inside its outline, each with every shape the annealer can give
it (SoftMacro::resizeRandomly's area per width interval), fixed ones
where they are; terminals and empty macros take no room. The test checks
that every shape the annealer produces is one the problem allows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: settle missing tilings with the exact check (MPL-0003)
160f111 
MPL-0003 said only that annealing found no tiling. When no run finds
one, the exact check now either finds an arrangement, whose bounding box
becomes the tiling, or proves that none exists, and the error says why
and which single change to the core fixes it, on the row and site grid:

  [ERROR MPL-0003] There are no valid tilings for mixed cluster root.
  The blocks, halos included, cannot fit in the 108.432 x 108.270 um
  outline (proven).
    Cause: the area suffices (83% of the outline), but no arrangement of
    the blocks does.
    It fits with any one of:
      same width 108.432 um: height >= 109.350 um
      same height 108.270 um: width >= 109.350 um
      same aspect ratio: width >= 109.296 um
    The outline is the core area.

That is asap7/aes-block at a core of 110.5 um; a core 109.350 um wide
(2025 sites) places, one site narrower does not. A problem the check
cannot decide within its budget keeps the plain error; the README's
limitations say so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: MacroPlacer::setAnnealingSteps sets the annealing budget
bcc016f 
The step budget of each annealing run was a constant. A setter lets a
caller trade time for quality, for a measurement or a design-space
search; the default stays 2000.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: a plain-text form of a packing problem
296f575 
writePackingProblem() and readPackingProblem() write and read a problem
one line per item, so a problem can be shared as a reproducer and read
by tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe @claude
mpl: mpl_bench, a manual binary that measures the macro placer
fbf4873 
mpl_bench runs the macro placer on a floorplanned .odb as often, and with
as large an annealing budget, as asked, and prints per run the wall time
and the half-perimeter wirelength of the nets that touch a macro. It is
tagged manual: long runs and statements about annealing quality belong on
a developer's machine, not in CI.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe
oharboe force-pushed the mpl-placement-problems branch from 7b3b50a to 4c8ddb1 Compare October 17, 2026 08:56
@oharboe @claude
mpl: real-design packing problems as a gtest
a3812ce 
136 problems mpl's annealer was asked on 18 ORFS designs, and
XiangShan's parent floorplan: wherever the annealer placed the macros,
the exact check must decide the problem and find a legal placement too;
wherever it proves that they do not fit, the proposed fix must fit. A
problem the annealer could not place either may stay undecided; one, at
99% fill, does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
@oharboe
oharboe force-pushed the mpl-placement-problems branch from 4c8ddb1 to a3812ce Compare October 17, 2026 08:57
@oharboe
oharboe marked this pull request as ready for review October 17, 2026 09:50
@oharboe
oharboe requested a review from a team as a code owner October 17, 2026 09:50
@oharboe
oharboe requested a review from joaomai October 17, 2026 09:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@joaomai joaomai Awaiting requested review from joaomai joaomai is a code owner automatically assigned from The-OpenROAD-Project/openroad-mpl
1 more reviewer
@gemini-code-assist gemini-code-assist[bot] gemini-code-assist[bot] left review comments
Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

size/XL

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@oharboe