Compute Chiplets

What Is a Chiplet? defined the term. This chapter applies it to the first and most common category: the die whose job is to compute. Compute is where chiplet partitioning is most often attempted, and the reasons are worth understanding precisely — not because compute is special, but because it happens to combine three properties that make a partition work. It is also where the failure mode is sharpest, because the traffic a compute die generates is exactly the traffic that is expensive to move across a boundary.

1. What a Compute Chiplet Is

A compute chiplet is a chiplet whose dominant role is executing computation — CPU cores, GPU or accelerator cores, or a mix.

What it contains beyond that is a partitioning decision, not a definition. It will hold the cores themselves, cache close to them, some local fabric connecting them, local clock and power management, and the die-to-die interface logic that lets it talk to the rest of the system. Whether it also holds last-level cache, memory controllers, or I/O controllers varies genuinely between architectures — and those choices are the interesting part of the design, because each one moves traffic either inside the die or across the boundary.

Resist the urge to memorise a canonical block list. The useful question is never "what goes in a compute chiplet?" but "what did this architecture choose to keep local, and what did that force across the link?"

2. Why Compute Partitions Well

Three properties tend to coincide in compute, and a partition works best when all three hold:

It replicates. Many compute architectures are built from repeated units — cores, tiles, clusters. Anything you would have instantiated N times on one die can often be manufactured once and instantiated N times as dies instead.

Its traffic can be aggregated. Compute generates enormous fine-grained internal traffic between cores and their caches, but the traffic leaving a compute cluster — memory requests, host and I/O traffic — is coarser and more regular. That is precisely the shape §5 of the previous module said survives being turned into an interface.

It benefits from dense logic. Compute is usually the part of a system that gains most from an advanced process, which makes it a natural candidate to separate from functions that gain less.

Note the hedges. None of these holds universally: not every compute architecture replicates cleanly, and a design whose cross-cluster traffic is fine-grained and latency-critical is a poor candidate no matter how much of the die it occupies. Compute is a common good partition, not an automatic one.

3. Replication as a Scaling Model

This is the payoff, and it is the clearest example of the shift 1.7 described.

Suppose one compute die provides some quantity of compute capacity. A product family can then be built by using one of them, two, or four, paired with a shared system die — without designing a new compute die for any of those points.

Product scaling becomes replication of a known die rather than redesign of a larger one.

Compare the monolithic alternative honestly. To offer three performance tiers monolithically you generally design three dies, or one large die with regions disabled to create lower tiers — which means the smallest product still pays for the largest die's area on the wafer. Replication addresses both: each tier consumes only the silicon it uses, and one design amortises across the whole family.

4. What Stays Local, What Crosses

The partition rule from Chapter 1.6 applies directly, and for compute it has a specific shape.

Keep local the traffic that is high-volume, fine-grained, and latency-critical: cores talking to their private caches, a locally shared cache level, coherence structures among cores on the same die, and any tightly coupled accelerator fabric. This traffic is precisely what a die-to-die interface handles worst — narrow relative to on-die wiring, and carrying real latency.

Expect to cross the traffic that is coarser and more tolerant: memory requests and their responses, host and I/O traffic, system-level coherence where the architecture requires it, and inter-die synchronisation.

Keep expensive fine-grained traffic inside the die; expose aggregated, manageable traffic at the boundary.

Every ownership decision in §1 is really a decision about which side of that line something falls on. Moving last-level cache onto the compute die keeps cache traffic local but replicates that cache in every instance; moving it to the system die shares it but sends every access across a link. Neither is universally right — which is exactly why the block list is a decision rather than a definition.

5. Coherence Makes the Boundary Harder

If several compute chiplets are meant to behave as one coherent machine — a shared, coherent view of memory across dies — the boundary gets substantially more demanding.

Coherence traffic is the opposite of what a die boundary wants. It is fine-grained, latency-sensitive, and it amplifies: a single memory operation can generate probes or snoops to other dies, responses back, and state transitions that must be ordered correctly. The interface now has to preserve ordering guarantees the architecture depends on, carry that additional traffic, and do it fast enough that the latency does not undermine the coherence protocol's performance assumptions.

A compute boundary is much harder when the architecture wants the dies to behave like one coherent machine.

This is why coherent multi-die compute is a genuinely difficult architecture rather than a matter of adding links, and why the alternatives — partitioning memory so cross-die coherence is rare, or relaxing what the software may assume — are real design options rather than evasions. The protocols themselves come much later in this curriculum; what matters now is recognising that coherence is the thing that decides whether a compute partition is easy or hard.

6. Where the Memory Controllers Live

This single choice reshapes the whole system, and there is no universal answer.

On the compute die, memory access is local and fast for that die's own traffic, and each compute die brings its own memory bandwidth as the system scales. The cost is that memory interface circuitry is replicated in every instance, the compute die inherits whatever process the memory interface needs, and accessing another die's memory becomes a cross-die operation with non-uniform latency.

On a shared system die, memory controllers exist once, memory is reached uniformly by every compute die, and the compute die stays focused on compute. The cost is that every memory access crosses a link — so the link's bandwidth and latency now sit directly in the memory path, which is the most performance-critical path most systems have.

What changes with this choice: traffic volume across the links, memory latency and its uniformity, required link bandwidth, which die a memory-related failure affects, and which process each die wants. The right answer depends on the workload's memory behaviour and how much link bandwidth the packaging can actually provide.

7. What Replication Does Not Buy

Adding compute dies does not add proportional system performance, and the reasons are worth knowing because they are where real designs disappoint.

• Software has to scale. More parallel hardware helps only work that can use it. Amdahl's argument did not stop applying because the cores arrived on separate dies.
• Memory bandwidth is finite. If compute dies share memory through a system die, doubling compute does not double memory bandwidth — it doubles the demand on it.
• Coherent interconnect complexity grows with the number of participants, and cross-die coherence traffic can grow faster than the compute that generates it.
• Synchronisation costs more across a die boundary than within one, so workloads with frequent global synchronisation lose some of what the extra compute provides.
• Thermal density and total power are package- and system-level limits. More dies in one package means more heat in one place, and power budgets do not scale with die count.
• Package routing is finite. Every additional compute die needs its links physically routed, and the package has limited connectivity and reach.

More compute dies do not produce proportionally more delivered performance. Whether they produce usefully more depends on the workload, the memory system, the interconnect, and the package.

8. The Verification Questions This Creates

A replicated compute system generates verification work that a monolithic design never had, and most of it lives at the boundary or in the configuration space:

• Does traffic route to the correct compute die, and does the response return correctly?
• What happens when one compute die resets, or has not finished booting when another starts issuing traffic?
• Is ordering preserved for traffic that crosses dies, in every case the architecture promises?
• Do cache and coherence behaviours remain correct across the boundary, including under contention?
• Does backpressure propagate correctly, so a busy system die throttles compute dies without deadlock or loss?
• Does the system behave correctly with one, two, and N compute dies? Every populated configuration is a distinct system.
• Are topology and configuration differences handled — including asymmetric or partially populated arrangements?

That second-to-last item is the one teams underestimate. Replication makes manufacturing simpler and the configuration space larger: verifying one arrangement does not verify the others.

9. Common Misconceptions

10. Understanding Check

11. Summary and What Comes Next

A compute chiplet is a chiplet whose dominant role is computation; what else it holds — last-level cache, memory controllers, I/O — is a partitioning decision, and each choice moves traffic either inside the die or across the link. Compute partitions well when it replicates, when its outbound traffic aggregates, and when it benefits from a dense process — none of which is guaranteed.

The payoff is that product scaling becomes replication of a known die rather than redesign of a larger one. The constraint is the partition rule: keep fine-grained latency-critical traffic local, expose aggregated traffic at the boundary. Coherence is what decides whether a compute boundary is easy or hard, because its traffic is fine-grained, latency-sensitive, and amplifying. And memory-controller placement — on the compute die or on a shared system die — reshapes bandwidth, latency uniformity, failure domain, and process choice in one decision.

What replication does not buy is proportional performance: software parallelism, memory bandwidth, interconnect scaling, synchronisation, thermal density, power, and package routing all bound the result. It also enlarges the configuration space, so every populated arrangement is a distinct system to verify.

Compute is only half the picture. The system die in Figure 1 has been doing a great deal of work in the background — memory, external interfaces, management — and it deserves its own treatment:

• 2.3 — IO Chiplets — what happens to the functions that connect the system to memory, storage, networking, accelerators, and the outside world, and why consolidating them onto their own die is attractive.

Browse the full path on the UCIe tutorials index.