System Partitioning

Everything in this module has been preparation for one decision. You know what compute, I/O, memory, and accelerator dies do; you know that a boundary turns wiring into a contract; and you know that every contract consumes real package resource. What you have not been asked yet is the question a chiplet architect is actually paid to answer: given a system, where do the boundaries go?

There is no formula, and anyone offering one is selling something. But there is a discipline — a set of questions asked in a particular order, against a set of axes that trade against each other — and that discipline is teachable. This chapter is that framework. It is the hardest chapter in the module, and the one whose reasoning transfers most directly to real work.

1. What Partitioning Actually Decides

Strip the decision down to its essential content and it is not about boxes at all.

Every pair of functions in a system communicates with some frequency, volume, latency requirement, and ordering requirement. Partitioning takes that communication graph and draws lines through it. Whatever a line crosses becomes an interface: specified, bandwidth-limited, latency-bearing, verified, and physically routed. Whatever it does not cross stays on-die metal: cheap, wide, fast, and nobody's contract.

Partitioning is choosing which interactions remain cheap internal wires and which become expensive external contracts.

That framing does real work. It tells you the decision is fundamentally about the communication graph, not the functional hierarchy — and it tells you what "good" means. A good boundary isolates something independently valuable, keeps expensive traffic on the inside, aligns with a genuine technology advantage, improves reuse or yield or product flexibility, and can actually be built. No single one of those decides it, and they routinely conflict.

2. Start From Traffic, Not Boxes

Here is the most common failure mode in practice, and it is seductive because it looks like diligence.

An architect opens the system block diagram. The blocks are already drawn — CPU complex, GPU, memory subsystem, I/O complex, security, media. They have names, owners, and boundaries. Partitioning then becomes an exercise in grouping those boxes, and the resulting cut inherits whatever logic produced the block diagram in the first place.

But the block diagram was drawn for comprehension and organisational ownership. It reflects what belongs together conceptually and which team maintains it. Neither of those has any necessary relationship to how much data moves between two blocks, or how quickly it must arrive. Chapter 1.6 stated this as a principle — logical modularity is not physical partitionability — and this is where it becomes a working method.

So invert the process. For every candidate cut, characterise what crosses it:

• How much traffic? Sustained volume in each direction, and whether the two directions are symmetric.
• What bandwidth does it demand, at peak and in the common case?
• How much latency can it tolerate? Does anything wait on a response, or does the traffic stream?
• What ordering does it require? Must operations become visible in a particular order, and enforced by whom?
• Is it coherent traffic? This is the single most consequential answer (§8).
• Bursty or continuous? Bursty traffic needs buffering and headroom; continuous traffic needs sustained capacity.
• Fine-grained or aggregated? Many small transactions cost far more per useful byte than fewer large ones.
• How many endpoints? Point-to-point, or does everything talk to everything?
• What happens under backpressure? Can the source be throttled safely, and does throttling create a deadlock risk with other traffic?

The quality of a partition is determined by the traffic crossing the cut, not by the names of the blocks on either side.

Two practical notes. First, you often do not have this data early — which is an argument for estimating it deliberately rather than substituting the block diagram. Second, the answers are workload-dependent, so a cut can be good for one workload mix and poor for another. That is real, and it means partitioning is done against an intended workload, not in the abstract.

3. The Axes That Trade Against Each Other

With traffic characterised, the decision runs across ten axes. They are listed separately because they genuinely are separate — and because a partition that looks good on one can be disqualified by another.

Communication locality. Chatty, tightly coupled functions belong together. This is the primary axis, and it follows directly from §2.

Latency sensitivity. A tight control or dependency loop must not cross a die boundary. Bandwidth can be provisioned; latency cannot be removed, and a loop that waits on a crossing pays it every iteration.

Bandwidth demand. High-bandwidth boundaries consume package routing, die edge, and interface area and power at both ends. Chapter 2.6 priced this; here it is a reason to prefer cuts where less has to cross.

Reuse potential. A boundary is worth more if what it isolates is independently useful — in other products, other configurations, other generations. A cut that produces two halves neither of which is useful alone has bought nothing but cost.

Process technology. Split where different functions genuinely benefit from different processes. The benefit is real and design-specific; it is not automatic, and it is worth less than architects often assume when the functions in question scale similarly.

Yield and die size. Smaller dies improve manufacturing economics — Chapters 1.3 and 1.4 established the mechanism and the arithmetic, so treat it as a known term rather than a fresh argument.

Product scalability. Repeated dies enable product tiers by population rather than redesign (Chapter 2.2). This favours cuts that produce a replicable unit.

Failure and re-spin scope. A boundary contains redesign risk: a fix in one die re-spins that die. Cuts that isolate the parts most likely to change — or most likely to be wrong — are worth more than the area argument alone suggests.

Verification and integration cost. Every boundary is another protocol, another interface to verify, another set of configurations. This axis always argues against an additional cut, which is why it is easy to forget and expensive to ignore (§10).

Package feasibility. A partition that cannot be routed, placed, powered, or cooled is not a partition. Per Chapter 2.6 this is an input, not a final check.

Notice the structure: the first three and the last two generally argue for fewer, better-placed cuts; the middle ones argue for more cuts. The decision is where those pressures balance for a specific system, which is why it cannot be reduced to a rule.

4. A Scorecard, Not a Score

For any proposed boundary, work through both columns explicitly. Resist the temptation to assign numbers — a weighted score invents precision that the inputs do not support, and it hides the fact that some costs are disqualifying rather than merely expensive.

What this cut buys

• Does it produce something independently reusable?
• Does it enable a genuinely better process choice for either side?
• Does it improve yield or die size meaningfully?
• Does it enable product scaling by population?
• Does it let either side evolve on its own schedule?
• Does it contain re-spin or schedule risk?

What this cut costs

• What bandwidth must the interface sustain?
• What latency does it add, and does anything wait on it?
• How much interface area and power at both ends?
• Does coherence traffic cross it?
• Can the package route, place, power, and cool it?
• What new verification surface does it create?
• What test and known-good-die burden does it add?
• Does software have to know about it?

The discipline is in refusing to skip a row. Most bad partitions in practice are not the result of bad judgement on a hard trade — they are the result of a row nobody filled in, usually verification cost, package feasibility, or software visibility, because those sit outside the architect's immediate discipline.

And note the asymmetry: a "no" on package feasibility or coherence latency can be disqualifying, while a "no" on process benefit is merely a smaller upside. Treating all rows as equally weighted is its own error.

5. A Bad Cut, and Why It Looks Good

Concrete case. An architect has a compute complex: several cores and a substantial shared cache serving them. Two well-defined blocks, clean interface between them, separate teams. Splitting cores from shared cache looks like the obvious modular boundary — and it is close to the worst available cut.

Work through what crosses:

• Every cache access. Core-to-shared-cache traffic is among the highest-volume, most frequent communication anywhere in the system. It now traverses a die-to-die interface.
• In the latency-critical path. A cache access is something the core waits on. Adding crossing latency to it does not reduce throughput at the margin — it directly slows execution, on the most frequently exercised path in the machine.
• Fine-grained. Cache traffic is many small transactions, which is the pattern that costs most per useful byte across a boundary.
• Coherence traffic multiplies. If the cache participates in coherence, probes and state transitions now cross too, amplifying the traffic beyond the accesses themselves (§8).
• Synchronisation loops cross it. Inter-core synchronisation frequently resolves through shared cache. Those loops now include a die crossing each way.

Every axis in §3 that matters most says no: locality is terrible, latency sensitivity is maximal, bandwidth demand is enormous, and coherence crosses. And the reuse argument is weak in both directions — a core cluster without its cache is not independently useful, and a cache without cores is not a product.

The block diagram gave no hint of any of this. Two boxes, one interface, clean hierarchy. The traffic is what condemns it, and only the traffic.

6. A Better Cut

Move the line. Keep the core cluster and its cache together on one die; separate the shared system functions — memory controllers, external interfaces, system fabric, management — onto another.

Now what crosses is different in kind:

• High-frequency local traffic stays internal. Core-to-cache and intra-cluster coherence remain on-die metal where they cost nothing.
• What crosses is aggregated. Memory requests that miss the local cache, and host or peripheral traffic. Both are coarser than cache accesses and far less frequent per unit of work, because the local cache has already absorbed most of the traffic.
• Latency tolerance is better. A memory access is already slow relative to a cache hit, so adding a crossing to it is proportionally far less damaging than adding one to a cache hit — the same absolute latency, a much smaller relative penalty.
• Both sides become independently valuable. The compute die is replicable and reusable across products (Chapter 2.2); the system die can be paired with different compute configurations (Chapter 2.3).
• Process choices can diverge, since compute and external-interface circuitry no longer share a die.

This is why compute-plus-local-cache versus system functions is such a commonly reached partition: it puts the boundary at a point where the traffic has already been aggregated and where the latency penalty is proportionally smallest, while producing two halves that are each independently useful.

It is not universal. A workload whose working set overflows the local cache will send far more traffic across than this reasoning assumes, changing the calculation. A system needing tight coherence across compute dies pays for it at this boundary (§8). And where the memory controllers sit shifts the answer substantially, as Chapters 2.2 and 2.4 examined. The lesson is the method — find where traffic has aggregated and where latency is proportionally cheapest — rather than this particular line.

7. Granularity: Both Extremes Are Wrong

Given that boundaries have costs and benefits, there is an optimum number of them, and it is not at either end.

Too coarse — few, large dies. Little reuse, because large dies are specific to their product. Large dies carry the yield and cost penalties of Chapters 1.3 and 1.4. Limited process freedom, since more functions share each die. Coarse product scaling.

Too fine — many small dies. Now the costs compound in ways that surprise people:

• Interface area and power on every die. Each die needs die-to-die PHY and controller logic. Split into many pieces and a growing fraction of total silicon is interface rather than function.
• More package links, each consuming routing, die edge, and placement adjacency — the resources Chapter 2.6 showed are finite.
• More crossings per operation. Traffic that once stayed internal may now cross two or three boundaries, accumulating latency at each.
• Duplicated infrastructure. Every die needs clocking, power management, test, and debug. That overhead is paid per die, not per system.
• Configuration explosion. Every combination and population count is a distinct system to verify and support.

The optimal number of chiplets is not "as many as possible."

The useful instinct: each additional cut must justify itself against the interface, latency, package, and verification cost it adds. A cut that produces two halves neither of which is independently valuable has purchased pure overhead.

8. Coherence Raises the Bar Substantially

Of everything that can cross a boundary, coherent traffic is the most consequential — and it deserves to be weighted differently from the other axes.

If a cut crosses a coherent domain, then probes or snoops travel between dies, ordering guarantees must be maintained across the boundary, state that tracks who holds what becomes distributed across separately manufactured components, and failure and recovery become materially harder because coherence state is spread across dies that can fail or reset independently.

The traffic profile is the problem. Coherence traffic is fine-grained (per cache line, not per bulk transfer), latency-sensitive (it sits in the path of ordinary memory operations), and amplifying (one operation can generate several messages to several dies plus their responses). That is precisely the profile a die boundary handles worst — the exact inverse of the aggregated, latency-tolerant traffic §6 was looking for.

Therefore: a boundary that carries coherence needs much stronger justification than a loosely coupled one. Not that it is forbidden — coherent multi-die systems are built and shipped — but the benefits must be correspondingly larger, and the design must actively limit how often coherence has to cross. Which is why real architectures work hard to make cross-die coherence rare: partitioning memory so most traffic is local, associating memory with the dies that use it, or restricting what software may assume about uniformity. Those are legitimate architectural responses, not evasions.

The protocol mechanisms belong to later modules. What belongs here is the weighting: coherence across a cut is a reason to move the cut.

9. Clocks, Reset, and Power States

A cut creates coordination problems that were previously internal implementation details, and these are easy to underestimate because they generate no traffic in the §2 analysis.

Clock domains. The two sides may have independent clock sources with no fixed phase relationship, so the interface must manage the crossing — a new clock-domain-crossing boundary with the correctness obligations that implies.

Reset sequencing. Previously one reset tree; now two independently powered, independently manufactured components that must reach a working state together. Which side comes up first, how each learns the other is ready, and whether the link can recover when one side resets alone all become interface behaviour.

Independent power states. Each die can potentially enter and leave low-power states on its own, which requires coordination so one side does not send to a partner that is asleep, and so wake latency is accounted for.

Fault containment. With separate dies there is a real question about whether a fault on one side can be contained, or whether it propagates into a system-level event. That question does not exist inside a single die, and its answer shapes what the interface must detect and report.

What was internal coordination becomes specified interface behaviour.

10. Every Boundary Is a New Verification Surface

This is the axis most often left out of the scorecard, and the one that most reliably surprises programmes.

Before a cut, interactions between two subsystems are internal: exercised by integration tests, debuggable with full visibility, and never independently versioned. After the cut, that interaction is a protocol between separately developed components, and it needs:

• Protocol verification of the interface itself, across legal and illegal behaviour.
• Link bring-up verification — the sequence by which two independent dies establish a working connection.
• Topology and configuration coverage — every supported population count and arrangement is a distinct system.
• Independent reset behaviour — each side resetting while the other runs.
• Partial failure and degraded operation — reduced interface width, an absent partner, a partner that never becomes ready.
• Error detection, reporting, and recovery, including attribution back to the right transaction.
• Version compatibility, if either side may be revised independently.

Every die boundary creates a new verification surface — and integration risk concentrates on exactly those surfaces.

The counting matters. Verification effort does not scale with the number of dies; it scales with the number of interfaces and the product of supported configurations. That is why §7's warning about configuration explosion is a verification argument as much as an architectural one, and why an extra cut can cost more in schedule than it saves in silicon.

11. Package Feasibility Is an Input, Not a Review

Chapter 2.6 made the physical argument; here is the process consequence.

The tempting workflow is: partition logically, then hand the result to package engineering to implement. That workflow produces partitions that get sent back — because routing corridors, die-edge availability, placement adjacency for high-bandwidth interfaces, power delivery, and thermal envelope are all capable of disqualifying an otherwise excellent cut.

So package feasibility has to be consulted while candidate cuts are being compared, not after one is chosen. Concretely, that means knowing early roughly how many connections each candidate interface needs, which dies would have to be adjacent, and whether the resulting arrangement can be powered and cooled. A partition is a joint architectural and physical artefact, and treating it as purely logical is how programmes discover late that their architecture is unbuildable.

12. Why This Matters Across Roles

Partitioning is the decision whose consequences touch the most disciplines:

• SoC architects own the cut and then own the budgets it creates — bandwidth, latency, and power for every interface it produced.
• RTL engineers implement what the boundary demands: interface logic, buffering sized for the traffic, flow control, clock- and reset-domain crossings, and internal architecture that tolerates the added latency.
• Verification engineers inherit the new surfaces of §10, and the configuration matrix.
• Physical-design engineers get smaller, more tractable dies plus new obligations — PHY placement, boundary timing, and package-facing constraints.
• Package engineers determine whether the partition is realisable at all, and should be in the conversation while it is being chosen (§11).
• DFT and test engineers must enable die-level screening so each die is known-good before assembly, which is more test, earlier.
• Software may see the partition as topology — non-uniform memory or latency, and configuration that must be discovered rather than assumed. Where a partition is visible to software, that visibility is part of its cost.

13. Common Misconceptions

14. Understanding Check

15. Summary — and the End of Module 2

Partitioning is choosing which interactions stay cheap internal wires and which become expensive external contracts. It is a decision about the communication graph, not the functional hierarchy — which is why it must start from traffic: volume, bandwidth, latency tolerance, ordering, coherence, burstiness, granularity, endpoint count, and backpressure behaviour. The quality of a cut is set by what crosses it, never by how clean the boxes look.

Ten axes then trade against each other — communication locality, latency sensitivity, bandwidth demand, reuse potential, process fit, yield and die size, product scalability, re-spin containment, verification cost, and package feasibility. Locality, latency, bandwidth, verification, and feasibility generally argue for fewer cuts; reuse, process fit, yield, and scalability argue for more. Work both columns of the scorecard explicitly and refuse to skip rows, remembering that coherence latency and package feasibility can disqualify while a weak process argument merely reduces upside.

The worked contrast is the method in miniature: cores versus shared cache fails because the heaviest, finest-grained, most latency-critical traffic in the machine crosses; cluster-plus-local-cache versus system die works because the local cache has already aggregated the traffic and because a memory access absorbs crossing latency far better than a cache hit does. Both extremes of granularity are wrong, coherence across a cut is a reason to move it, and every boundary adds clock, reset, power-state, and fault-containment obligations plus a new verification surface — with verification scaling by interfaces and by the product of supported configurations.

That closes Module 2. Chiplet types are the building blocks, packaging constrains how they can physically be composed, and partitioning determines whether the composition is worth doing at all. Which leaves exactly one thing unaddressed. Even a perfectly partitioned, perfectly packaged system still needs its dies to talk — and the first generation of chiplet systems solved that privately:

• 3.1 — Proprietary Die-to-Die Links — how companies connected their own dies before UCIe, why that was the rational engineering choice, and why it could not become an ecosystem foundation.

Browse the full path on the UCIe tutorials index.