mpl: Fixes MPL-45 can't split cluster error

[QuantamHD]

This error seems to occur when you have a macro dominated block with just a few standard cells. Added a test case that I validated failed with HEAD and passes with my change.

Verification

• [ x ] I have verified that the local build succeeds (./etc/Build.sh).
• [ x ] I have run the relevant tests and they pass.
• [ x ] My code follows the repository's formatting guidelines.
• [ x ] I have included tests to prevent regressions.
• [ x ] I have signed my commits (DCO).

[gemini-code-assist]

Code Review

This pull request introduces a "Rocks vs Sand Check" in the clustering engine to detect when a single macro dominates the total standard cell area. When macro domination is detected, macro weights are dynamically normalized to the average standard cell area to prevent knapsack partition failures. A new test case mpl_dominated has been added to verify this behavior. The reviewer identified a critical bug where macro-only clusters (with zero standard cells) would incorrectly trigger this domination logic, leading to suboptimal weight normalization. A code suggestion was provided to ensure standard cells are present before flagging macro domination.

[gemini-code-assist]

If there are no standard cells in the cluster (num_std_cells == 0), total_std_cell_area will be 0.0f. If there is at least one macro, max_macro_area will be greater than 0.0f, which makes discrete_macro_domination evaluate to true.

This triggers macro weight normalization to 1.0f (since avg_std_cell_area defaults to 1.0f when num_std_cells == 0). For a macro-only cluster, normalizing all macro weights to 1.0f prevents the partitioner from balancing the actual physical areas of the macros, leading to poor partitioning results.

We should only consider the cluster macro-dominated if there are actually standard cells present to be balanced against.

Suggested change

	const bool discrete_macro_domination = (max_macro_area > total_std_cell_area);
	const bool discrete_macro_domination = (num_std_cells > 0) && (max_macro_area > total_std_cell_area);

[QuantamHD]

If a block contains only macros this method is never called.

[QuantamHD]

The review dog clang tidy seems to not be posting comments

[joaomai]

What's your opinion on simply splitting the cluster into [giant_macro, everyting else] when there's a macro that area is more than half of the total area of a given cluster (and checking if everyting else still is a large cluster). Could you test this approach on your failing design?

I did some testing on the current behavior of TritonPart using the mpl_dominated testcase provided and it seems like it is basically random once we have the 1 macro with 20 std cells cluster: changing the seed when a solution is fully unbalanced "solves the issue" after some retries.

Also, I think something more descriptive like macro_dominated_break_cluster for the test name works best.

[QuantamHD]

In my prod design it's six identical macros of roughly 1 million cells and 90,000 cells connecting them. Would your proposed solution work for something like that? My worry with the 50% check is that it wouldn't trigger when we have many macros, but only a small standard cell area.

Also I could use a pointer on the mechanics of implementing what you suggested. Where should I put that code?

[joaomai]

@QuantamHD
Can you try the approach from PR #10581? It uses the idea I mentioned above.