UCIe · Module 2

What Is a Chiplet?

A definition strict enough to reason with — what qualifies as a chiplet and what does not, how chiplet differs from IP block, die, and multi-die system, and why a chiplet does not have to use any particular interface standard.

The previous chapter used the word "chiplet" freely while pointing out that not every die in a multi-die product deserves it. This chapter fixes that. The goal is a definition precise enough to reason with — one that lets you look at a real design and say what it is, rather than one loose enough to apply to anything in a package. Industry usage is genuinely looser than what follows; that is fine for conversation and useless for architecture.

1. The Definition

A chiplet is an independently manufactured die that implements a meaningful subsystem function, connects to the rest of the system through a defined die-to-die interface, and is intended for modular integration or reuse rather than for one hard-wired implementation.

Five clauses, each doing work. Remove any one and the term stops discriminating.

Independently manufactured. It is a real die — fabricated, tested, and handled as its own physical object. This is what separates a chiplet from an RTL block, and it is not a technicality: it is why a chiplet has a yield, a test result, a process, and a cost of its own.

Meaningful subsystem function. It owns a coherent piece of the system — compute, I/O, memory, acceleration — rather than an arbitrary slice drawn wherever the area happened to divide. If you cannot describe what it does without referring to the floorplan, it is a fragment, not a subsystem.

Defined die-to-die interface. Its boundary is specified, not incidental. Chapter 1.6 covered why: the moment a connection crosses dies, the assumptions an on-die wire relies on evaporate and something has to replace them explicitly.

Part of a larger system. A chiplet is not normally the whole product. It is a component that becomes a product in combination with others.

Modular or reusable intent. The clause that does the most work, and the one most often dropped. This is what distinguishes chiplet architecture from arbitrary multi-die partitioning — and it is a design-time intent, visible in whether the boundary was specified for partners the die was not co-designed with.

Figure 1 — the five properties that together make a die a chiplet. Each is necessary and none is sufficient alone: a die can be independently manufactured and still be a fragment, or own a coherent function and still be drawn for exactly one neighbour. Modular intent is the clause most often missing in practice, and the one that separates chiplet architecture from ordinary multi-die decomposition.

2. The Vocabulary Around It

Most confusion here is vocabulary, not concept. These terms are not interchangeable.

Term	What it is	Key distinction
IP block	A design asset — RTL, and possibly a hardened layout	A description. It has no yield, no test result, no process until someone builds it
Die	One independently fabricated piece of silicon	Physical, but says nothing about intent or reuse
Chiplet	A die-level subsystem built for modular composition	A die plus coherent function, a defined boundary, and modular intent
Multi-die system	A system implemented across two or more cooperating dies	The broader category. Its dies may or may not be chiplets
Package	The structure that houses and connects the dies	Since 1.6, part of the interconnect architecture — not merely a container
Chip	Colloquial, context-dependent	Means die, packaged part, or whole product depending on speaker. Avoid it when precision matters

Two relationships worth stating outright: every chiplet is a die, but not every die is a chiplet, and every chiplet system is multi-die, but not every multi-die system is built from chiplets.

3. What Is Not Automatically a Chiplet

Applying the definition negatively sharpens it:

An IP block. However reusable and well-verified, it is a design, not a manufactured object. It becomes silicon only when someone builds it into a die.
A die split purely out of manufacturing necessity. If a design was cut only because it would not otherwise fit or yield, and neither piece is intended to appear anywhere else, that is decomposition. Real, useful, and not composition.
Two unrelated dies that happen to share a package. Co-packaging is a mechanism, not an architecture. If they do not cooperate to implement one larger system, the definition does not apply.
A board-level accelerator. A complete product with its own package, connected over a board-level interface — not a die-level component of someone else's system.
A small die with no modular intent. Size is not a criterion anywhere in the definition.

Two honest caveats. First, industry usage is looser than this, and people will call things chiplets that fail one of the clauses — often the intent clause. That is not worth arguing about; VLSI Mentor uses the stricter definition because it predicts things. Second, these are not sharp binary categories in practice: modular intent is a matter of degree, and a die can be somewhat reusable. The definition is a reasoning tool, not a certification.

4. Two Dies, One Difference

The intent clause is easiest to see by comparison. Both cases below are multi-die; both are hypothetical.

Case A. Two dies designed together for one product. The connection between them is whatever the two teams found convenient — signals added as needed, timing tuned to these specific partners, no specification written because none was required. The product works well. Neither die can meet any other partner, and the next product gets new dies.

Case B. A compute die with a boundary specified before its partners existed: defined width and signalling, flow control, bring-up sequence, error behaviour, and a stated notion of what makes a compatible partner. It ships in three products with different I/O dies. Nothing inside it changed between them.

The physical difference may be small — Case B mostly spent effort on its boundary. The architectural difference is total: Case A's dies are pieces of a product, Case B's compute die is a component. Case A is still often called a chiplet product colloquially, and that is not worth fighting. Under this chapter's definition it is proprietary multi-die, and the distinction tells you something useful: only Case B can be recombined without redesign.

5. The Boundary Is a Contract

The reason the interface clause matters is a principle you already know from software, now with manufacturing consequences attached.

Inside the chiplet: implementation freedom. Microarchitecture, floorplan, process, internal protocols — all of it can change between revisions, as long as the boundary behaviour holds.

At the boundary: contract stability. What the interface promises must stay true, because other dies were designed against it.

That is ordinary modular design. What differs from software is the cost of getting it wrong. A broken software interface is a recompile; a broken chiplet interface means silicon that cannot be combined, discovered after masks, wafers, and packages have been paid for. It is also why versioning and compatibility management are real engineering work here rather than bookkeeping — the pieces evolve independently, on separate schedules, and each combination has to remain valid.

6. What the Abstraction Costs

Chapters 1.4–1.6 covered the benefits of partitioning and reuse, so this section only names what modularity specifically adds on top.

Designing a die for partners it has not met means over-specifying relative to any single product: the interface must be general enough for several combinations, which usually costs some interface area and power beyond a point-designed link. Compatibility becomes a maintained property rather than a one-time check, and every valid combination needs validating rather than just the one you shipped. Test criteria must be stringent enough that a die is genuinely known-good before a partner commits to it. And configuration and version management becomes ongoing work as each piece revises on its own schedule.

None of this is an argument against modularity. It is the reason a modular die is a deliberate investment rather than a free by-product of splitting a design.

7. Common Misconceptions

Definitional errors worth avoiding

"Any small die is a chiplet." Size appears nowhere in the definition. A small die drawn for exactly one partner is not a chiplet; a large die with a stable interface reused across products is.
"An IP block and a chiplet are the same thing." An IP block is a design; a chiplet is manufactured silicon with its own yield, test result, process, and cost. The same function can exist as both — and integrating it as IP versus composing it as a chiplet are completely different engineering problems.
"A chiplet must come from a different vendor." No. Most chiplet-style products today compose dies designed inside one organisation. Cross-vendor sourcing is an ambition the model enables, not a requirement of the definition.
"A chiplet must use UCIe." No. The definition requires a defined die-to-die interface, not any particular one. Proprietary die-to-die interfaces existed before UCIe and remain in use. UCIe is one standardised answer to the interface question — the answer that makes cross-organisation composition practical — but a die with a well-specified proprietary boundary and genuine modular intent is still a chiplet. Keep the requirement (a specified boundary) separate from one implementation of it.
"A chiplet architecture always uses different process nodes." Heterogeneous process choice is something the model permits, not something it demands. A system whose dies all use the same process can be perfectly good chiplet architecture if the dies are composable.
"A reusable chiplet needs no integration validation." Its internal verification is amortised across products; its integration verification is not. Each new combination, configuration, and package is a new system that must be validated.

8. Understanding Check

9. Summary and What Comes Next

A chiplet is an independently manufactured die, implementing a meaningful subsystem function, connecting through a defined die-to-die interface, as part of a larger system, built with modular or reusable intent. Every clause discriminates; the last one does the most work and is the one most often absent. Every chiplet is a die, not every die is a chiplet; every chiplet system is multi-die, not every multi-die system uses chiplets. The boundary is a contract — freedom inside, stability at the edge — and a chiplet does not have to use any particular interface standard to qualify.

With the term defined, the rest of Module 2 works through the categories that show up in real systems, starting with the one that usually dominates a design's area and power:

2.2 — Compute Chiplets — what belongs in a compute die, why compute partitions well, and what changes when the subsystem being modularised is the one doing the work.

Browse the full path on the UCIe tutorials index.