mpl: settle MPL-0003 with an exact packing check, and prove what does not fit

[oharboe]

Opened for discussion.

When no annealing run finds a tiling for a mixed cluster, MPL-0003 now settles whether one exists with an exact fixed-outline packing check (OR-tools CP-SAT, which OpenROAD already links). Either it finds an arrangement, whose bounding box becomes the tiling, or it proves that none exists and the error names each single change to the core that fixes it. When annealing succeeds, nothing changes: the check runs only after every annealing run has failed.

asap7/aes-block with a 110.5 um core (The-OpenROAD-Project/OpenROAD-flow-scripts#4681), before and after:

[ERROR MPL-0003] There are no valid tilings for mixed cluster: root

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

Checked in the ORFS flow: at a 111.35 um core (outline 109.296 um wide) MPL-0003 proves again that the macros do not fit; at 111.402 um (outline 109.350 um, the proposed width) the floorplan completes.

Measured on 18 ORFS designs (asap7, gf180, nangate45):

	result
every tiling problem mpl's annealer was asked (285)	the check agrees with every annealing result: 165 fit, 120 proven not to fit, 0 undecided; 17 of the 165 are fits that annealing run missed
causes of the 120 proofs	block too tall 50, block too wide 28, area 25, arrangement 17
time of the check on those 285 problems	0.7 s in total, slowest 77 ms (annealing them took 32 s)
macro placement on each design's own core, master vs this PR	identical macro-net wirelength on all 18 designs in every run (3 per arm); runtime 0.98x to 1.02x, within noise

How these were measured, and the rest of the study: The-OpenROAD-Project/bazel-orfs#1290.

Commits

1. shapes as a library of its own, so the check depends on Tiling and Interval without object.cpp and odb
2. the exact fixed-outline packing check
3. the smallest outline at which a packing fits: same width, same height, same aspect ratio
4. words for why a packing does not fit
5. the annealer's question as a packing problem
6. MPL-0003 settled by the exact check

Tests

C++ gtests that check what the code must do against an independent reference, not golden output: planted packings with known answers, an exhaustive search on small cases, a geometry validator written in the test, the same answer for the same input, a tiny budget answering "undecided" rather than failing, the fixes being the smallest that fit on the given grid, every shape SoftMacro::resizeRandomly produces being one the packing problem allows, and malformed input (an outline without area, a block without a shape, a step <= 0) being refused with an exception rather than answered. The existing Tcl regressions pass unchanged.

#11809 offers the 136 packing problems behind the table above as a gtest, and the bench used to measure.

Limits

• A problem the check cannot decide within its deterministic budget keeps the plain error; the README says so. None of the 285 tiling problems above needed it.
• Placement failures (MPL-0040, MPL-0008, MPL-0010) are not covered here.

Claude made the changes and stared at paint drying.

🤖 Generated with Claude Code

[github-actions]

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.

[gemini-code-assist]

Code Review

This pull request introduces an exact packing feasibility check using OR-Tools CP-SAT to determine if a valid macro tiling exists when annealing fails, integrating it into the hierarchical macro placement flow and providing detailed outline fix suggestions. The review feedback highlights several safety improvements to prevent potential division-by-zero errors in utility functions, a signed integer overflow risk when calculating block areas, and an out-of-bounds access vulnerability if width and height interval sizes mismatch.