ChipletPart: Cost-Aware 2.5D Partitioning

• ChipletPart is a cost-driven partitioning framework that decomposes SoCs into chiplets for 2.5D integration, optimizing yield against package, assembly, and I/O costs.
• It leverages a hybrid approach combining genetic algorithms, core partitioning, and simulated annealing-based floorplanning to ensure both economic efficiency and physical feasibility.
• The framework outperforms traditional min-cut methods by reducing chiplet cost up to 58% while consistently generating floorplan-feasible solutions under strict inter-chiplet I/O reach constraints.

Searching arXiv for recent and directly related papers on chiplet partitioning, placement, and cost-aware 2.5D design. ChipletPart is a cost-driven partitioning framework for decomposing a large SoC into chiplets for 2.5D integration. It treats chipletization not as a simple cut-minimization problem but as a physically grounded, manufacturing-cost-aware optimization that jointly considers partitioning of blocks into chiplets, assignment of technology nodes to chiplets, and floorplan feasibility under inter-chiplet I/O reach limits (Graening et al., 26 Jul 2025). In that sense, ChipletPart sits at the boundary between system technology co-optimization and physical implementation: it produces candidate chiplet organizations before detailed layout, but it does so with explicit awareness of package area, yield, assembly, signaling reach, and heterogeneous technology assignment rather than relying on abstract graph metrics alone.

1. Conceptual role and research context

ChipletPart addresses block-level chiplet partitioning for 2.5D systems. Its input is a block-level SoC or system netlist in which IP blocks are the indivisible units, and its output is a set of chiplets placed on a shared package or interposer, potentially implemented in different process nodes (Graening et al., 26 Jul 2025). The framework is motivated by the central tradeoff of chipletization: smaller dies can improve yield, avoid reticle-limit issues, and enable heterogeneous integration, but inter-die communication, package or interposer cost, assembly, and yield loss can erase those benefits if the partition is poorly chosen.

This position differentiates ChipletPart from both classical partitioners and neighboring chiplet tools. State-of-the-art min-cut partitioners such as hMETIS and TritonPart optimize cutsize rather than manufacturing cost, ignore package and interposer economics, ignore floorplan feasibility and reach, and do not support heterogeneous technology assignment (Graening et al., 26 Jul 2025). CATCH, by contrast, is an early-stage cost analysis framework that computes manufacturing, assembly, test cost, and yield for candidate chip hierarchies, but it is not itself a partitioner (Graening et al., 20 Mar 2025). PlaceIT and FAPlace operate downstream or orthogonally: PlaceIT jointly optimizes chiplet placement and inter-chiplet interconnect topology under short-link constraints, whereas FAPlace jointly optimizes chiplet placement and interposer footprint when the footprint is not known a priori (Iff et al., 3 Feb 2025, Hou et al., 1 Jul 2026). ChipletPart’s distinctive contribution is to make the partition itself cost-aware, reach-aware, and technology-assignment-aware before those later placement stages.

A common misconception is that chiplet partitioning can be reduced to minimizing inter-chiplet communication. ChipletPart explicitly argues otherwise. The problem is smaller than conventional hypergraph partitioning in terms of block count, but its objective function is much more complex than hyperedge cut because package area, interposer area, assembly yield, I/O discreteness, and technology-node choice all matter (Graening et al., 26 Jul 2025). A second misconception is that “more chiplets” are inherently better. ChipletPart’s case studies show that short reach and large I/O cells can favor fewer chiplets, while heterogeneous integration can favor more nuanced decompositions whose benefit depends on signaling assumptions and node assignment (Graening et al., 26 Jul 2025).

2. Formal model and objective structure

The paper defines the multi-technology chiplet partitioning problem with a block-level netlist $\mathcal{S}$ and a set of technology nodes $\mathcal{T}$ as inputs, and a set of chiplets $\mathcal{C}$ and a technology assignment map

$\omega : \mathcal{C} \to \mathcal{T}$

as outputs (Graening et al., 26 Jul 2025). The notation also includes $\mathcal{C}_t$ for the set of chiplets implemented in technology node $t$, $N$ for the chiplet-level netlist, $V$ for manufacturing volume, $m$ for the number of technology nodes, and $\phi$ for the partitioning objective. Following prior cost-model work, the netlists are modeled as graphs rather than hypergraphs.

The stated objective is minimizing total 2.5D system cost, combining assembly cost, yield-adjusted die cost, and NRE amortized over manufacturing volume (Graening et al., 26 Jul 2025). The paper’s central interpretation is that each die’s manufacturing cost is divided by its yield, assembly cost is divided by assembly yield, and technology-dependent NRE enters through $\mathcal{T}$0. The adopted cost engine is the open-source CATCH model from prior UCLA work, translated from Python to C++ for speed by the authors (Graening et al., 26 Jul 2025). CATCH itself is a recursive cost analysis tool that models die area, I/O area, pad demand, assembly cost, yield, test cost, and NRE for chiplet hierarchies, and is therefore the economic substrate beneath ChipletPart’s search (Graening et al., 20 Mar 2025).

The primary explicit constraint is I/O feasibility of the chiplet set $\mathcal{T}$1. ChipletPart captures this through a reach-violation penalty on the chiplet-level netlist: $\mathcal{T}$2 where $\mathcal{T}$3 is the bitwidth of chiplet-level net $\mathcal{T}$4, $\mathcal{T}$5 is the floorplan-dependent wirelength, and $\mathcal{T}$6 is the maximum driveable length for the I/O on that net (Graening et al., 26 Jul 2025). The floorplanning objective is then

$\mathcal{T}$7

where $\mathcal{T}$8 is total chiplet area, $\mathcal{T}$9 is package area, and the default coefficients are $\mathcal{C}$0 (Graening et al., 26 Jul 2025). This formulation is significant because it turns floorplanning into both a feasibility oracle and a geometric cost estimator inside the partitioning loop.

The I/O model is explicitly technology-sensitive. The paper gives examples such as UCIe advanced package reach of $\mathcal{C}$1, standard package reach up to $\mathcal{C}$2, a single UCIe I/O cell area of $\mathcal{C}$3, and a parallel signaling I/O cell area of $\mathcal{C}$4 (Graening et al., 26 Jul 2025). The practical implication is that inter-chiplet I/O cost is discrete rather than smooth, so the marginal cost of a partition cut is staircase-like rather than proportional to cut weight. The benchmark-scaling methodology also invokes Rent’s rule,

$\mathcal{C}$5

to scale interconnect counts realistically when enlarging designs (Graening et al., 26 Jul 2025).

3. Optimization flow and algorithmic structure

ChipletPart is organized as a hierarchical flow with three major components: a genetic algorithm for technology assignment, Core-ChipletPart for cost-driven partitioning under a fixed technology assignment, and an SA-based floorplanner for reach-aware feasibility and geometric evaluation (Graening et al., 26 Jul 2025). The framework is thus neither a pure partitioner nor a pure floorplanner; it interleaves both.

The genetic algorithm searches over technology assignments. A gene is a technology node, and a genome is an ordered sequence of technology assignments to chiplets. The implementation canonicalizes equivalent assignments such as $\mathcal{C}$6 and $\mathcal{C}$7 because they represent the same multiset of technology assignments (Graening et al., 26 Jul 2025). The default GA parameters are $\mathcal{C}$8, $\mathcal{C}$9, maximum generations $\omega : \mathcal{C} \to \mathcal{T}$0, improvement threshold $\omega : \mathcal{C} \to \mathcal{T}$1 for $\omega : \mathcal{C} \to \mathcal{T}$2 successive generations, tournament size $\omega : \mathcal{C} \to \mathcal{T}$3, number of parent pairs $\omega : \mathcal{C} \to \mathcal{T}$4, crossover probability $\omega : \mathcal{C} \to \mathcal{T}$5, mutation probability $\omega : \mathcal{C} \to \mathcal{T}$6, and elitism $\omega : \mathcal{C} \to \mathcal{T}$7 (Graening et al., 26 Jul 2025). The GA evaluates each genome by invoking Core-ChipletPart and then the cost model.

Core-ChipletPart searches the partition space under a fixed $\omega : \mathcal{C} \to \mathcal{T}$8. It begins from a diversified pool of 11 initial partitions: 1 spectral partitioning solution, 1 high-degree-node expansion solution, 5 random partitions, and 4 METIS-based partitions (Graening et al., 26 Jul 2025). The initial pool is pruned by two criteria: a z-score threshold that discards partitions more than 1.5 standard deviations above the mean cost, and a relative-cost threshold that discards partitions worse than $\omega : \mathcal{C} \to \mathcal{T}$9 the minimum observed cost, while always retaining at least three solutions (Graening et al., 26 Jul 2025). The surviving candidates are refined using K-way FM moves followed by KL pairwise swaps. Every candidate FM move or KL swap invokes the fast floorplanner and the chiplet cost model, and after each FM or KL pass the standard floorplanner is rerun to improve the floorplan for the next pass (Graening et al., 26 Jul 2025).

This architecture reflects a deliberate methodological choice. Because chiplet block counts are only tens to hundreds of IP blocks, ChipletPart does not rely on aggressive multilevel coarsening. Instead it uses diversified initialization, explicit pruning, and refinement under a realistic evaluator. A plausible implication is that the framework treats accurate evaluation as more important than asymptotically sophisticated graph contraction, because the dominant difficulty lies in the objective rather than raw input size.

4. Reach-aware floorplanning and physical feasibility

ChipletPart’s floorplanner is central rather than auxiliary. The framework explicitly targets the fact that a topologically plausible partition can still be physically impossible because inter-chiplet I/O drivers have limited reach (Graening et al., 26 Jul 2025). A feasible floorplan must simultaneously satisfy no-overlap, required separation, acceptable reach, and sufficient geometric accommodation for I/O.

The floorplanner determines both location and shape of chiplets. Two operators are emphasized in the summary: reshape and expand or bloat. The expansion operator increases chiplet size to occupy whitespace and reduce reach violation, even though this increases chiplet and package area (Graening et al., 26 Jul 2025). This is important because ChipletPart does not assume fixed chiplet outlines. It treats chiplet geometry as part of feasibility, which distinguishes it from prior methods that assume predetermined chiplet sizes and shapes.

The physical assumptions are tightly coupled to packaging and signaling choices. The paper’s case studies explore parallel I/O with $\mathcal{C}_t$0 reach and UCIe variants with $\mathcal{C}_t$1 reach, while the broader discussion also references UCIe advanced $\mathcal{C}_t$2 and standard up to $\mathcal{C}_t$3 (Graening et al., 26 Jul 2025). Reach directly changes the admissible separation between communicating chiplets. Increasing reach from $\mathcal{C}_t$4 to $\mathcal{C}_t$5 to $\mathcal{C}_t$6 allows more chiplets, whereas short reach forces larger merged chiplets because only nearby neighbors can communicate directly (Graening et al., 26 Jul 2025). Likewise, UCIe’s larger I/O cells favor fewer chiplets, while small parallel-I/O cells enable finer partitioning (Graening et al., 26 Jul 2025).

This reach-aware geometry can be placed in a broader placement context. PlaceIT assumes candidate chiplets, PHY counts, and relay capabilities as input and then co-optimizes placement and inter-chiplet topology under a maximum link length, while FAPlace places chiplets on a sufficiently large canvas and lets the interposer footprint emerge rather than fixing it a priori (Iff et al., 3 Feb 2025, Hou et al., 1 Jul 2026). ChipletPart complements those methods by deciding which chiplets exist in the first place and whether their interconnections are economically and physically plausible under reach constraints.

5. Empirical performance and reported gains

The evaluation uses nine testcases across four categories: Waferscale systems $\mathcal{C}_t$7 through $\mathcal{C}_t$8, MemPool $\mathcal{C}_t$9, industry testcases $t$0 and $t$1, and comparison testcases EPYC and GA100 (Graening et al., 26 Jul 2025). Representative characteristics include $t$2 with 384 IP blocks and GA100 with 180 blocks. The authors intentionally scale some designs up to sizes where chipletization is economically meaningful.

Against state-of-the-art min-cut partitioners, the headline result is that ChipletPart reduces chiplet cost by up to 58% and 20% geometric mean (Graening et al., 26 Jul 2025). The text further specifies up to 55% versus hMETIS and up to 58% versus TritonPart, with geometric mean improvements of 16% over hMETIS and 20% over TritonPart (Graening et al., 26 Jul 2025). Just as important, ChipletPart consistently produces floorplan-feasible solutions, whereas hMETIS and TritonPart often violate reach constraints (Graening et al., 26 Jul 2025).

Against FloorPlet or parChiplet, ChipletPart achieves up to 47% lower cost and 6% geometric mean lower cost (Graening et al., 26 Jul 2025). The paper notes one testcase, $t$3, where FloorPlet has slightly lower nominal cost, but its solution is reach-infeasible; ChipletPart returns feasible solutions consistently (Graening et al., 26 Jul 2025). Against manual partitions, ChipletPart improves by up to 24% and 7% geometric mean (Graening et al., 26 Jul 2025). Comparing ChipletPart with and without floorplan checking yields up to 15% and 4% geometric mean improvement in chiplet cost, and without floorplan-awareness 6 out of 9 testcases become infeasible (Graening et al., 26 Jul 2025). This directly supports the claim that floorplanning is not a post-processing legality check but part of the optimization problem.

The heterogeneous integration results are similarly central. Across 7nm, 10nm, and 14nm choices, heterogeneous integration yields up to 43% cost reduction, with geometric mean reductions of 7% versus best homogeneous 7nm and 15% versus homogeneous 10nm and 14nm (Graening et al., 26 Jul 2025). The abstract summarizes this as up to 43% and 15% geometric mean reduction from heterogeneous integration (Graening et al., 26 Jul 2025). Concrete examples include $t$4, where homogeneous costs are 123.4 at 7nm, 112.7 at 10nm, and 109.4 at 14nm, while heterogeneous gives 87.8; $t$5, where homogeneous 46.5/52.4/56.4 becomes 39.8; and EPYC, where 72.5/86.2/94.6 becomes 65.1 (Graening et al., 26 Jul 2025). These examples support the recurring design lesson that advanced nodes are not always cheapest for every chiplet.

Runtime remains practical for early-stage exploration. Reported heterogeneous runs include 89 s for $t$6, 160 s for $t$7, 349 s for EPYC, and 5624 s for $t$8, with the largest case still under about two hours (Graening et al., 26 Jul 2025). The runtime breakdown is dominated by the floorplanner at 67%, followed by partition refinement and chiplet cost model at 28%, while partition pool generation, pruning, and I/O each contribute about 1–2% (Graening et al., 26 Jul 2025). The C++ translation of the cost model yields about $t$9 cost-model speedup, and the integrated framework sees over $N$0 speedup versus Python-based integration (Graening et al., 26 Jul 2025).

6. Broader significance, design rules, and limitations

ChipletPart’s broader significance lies in reframing chipletization as constrained economic optimization. Its main design rules are consistent across the case studies. Chipletization helps only when yield benefits are not offset by package and I/O overhead; more chiplets are not always better; heterogeneous integration can be highly beneficial; floorplan-awareness is essential; and packaging and interconnect choices change the optimal partition (Graening et al., 26 Jul 2025). These conclusions align with cost-analysis work such as CATCH, which similarly shows that optimal chiplet count, process choice, substrate, IO type, assembly flow, and test coverage interact nontrivially in early design-space exploration (Graening et al., 20 Mar 2025).

The framework also sits within a wider partitioning literature whose objective functions differ sharply. Performance-oriented chiplet arrangement work such as HexaMesh optimizes diameter and bisection bandwidth for hundreds of chiplets under adjacency-only rules, reporting 42% smaller diameter and 130% higher bisection bandwidth than a conventional grid (Iff et al., 2022). Gemini studies DNN inference accelerators and argues that moderate partitioning can lower monetary cost with almost no performance or energy loss, while overly fine-grained chiplets are bad for all three metrics simultaneously (Cai et al., 2023). Operation-level ML graph partitioning on MCM accelerators formulates a different problem, mapping graph nodes to chiplets under directional communication and dynamic feasibility constraints, and solves it with RL plus CP-SAT rather than a block-level SoC cost model (Xie et al., 2021). Security-oriented work goes further still: interposer-root-of-trust papers argue that in multi-vendor 2.5D systems the appropriate partition may be “by trust” rather than by function, placing enforcement logic in a trusted active interposer rather than in commodity chiplets (Williams et al., 20 Jun 2026, Nabeel et al., 2019). This suggests that future ChipletPart-like tools may eventually need objective terms beyond cost, including trust, runtime isolation, or side-channel exposure.

The limitations of ChipletPart are explicit. It assumes a fixed architecture and iso-performance across technology nodes, uses a simple I/O model with a fixed standardized I/O cell type per experiment, and does not support pass-through connections, substrate buffers or “gas stations,” buffer chiplets, or congestion-aware detailed I/O planning (Graening et al., 26 Jul 2025). Future work is said to include ILP, RL, or Bayesian optimization, hierarchical decomposition for scalability, integration with OpenROAD, and repeated-structure exploitation in regular netlists (Graening et al., 26 Jul 2025). These limitations place ChipletPart firmly in the category of early-stage partitioning and system technology co-optimization rather than final implementation.

Taken together, ChipletPart establishes a specific answer to a recurring chiplet-design question: the right partition is not the one with minimum cut, but the one with minimum yield-aware, package-aware, reach-feasible system cost under realistic technology assignment. Within the current literature, that is its defining contribution (Graening et al., 26 Jul 2025).