Proprietary Die-to-Die Links

Module 2 ended with a system correctly partitioned and physically buildable, whose dies still have to talk. That problem was solved long before UCIe existed, and solved well — companies shipped high-volume chiplet products years ahead of any cross-industry die-to-die standard. So Module 3 does not open with a gap in capability. It opens with something more interesting: an approach that worked technically and could not become a foundation for anyone else. Understanding why is the whole point of this chapter, and getting it right requires resisting the easy version of the story.

1. The Interface Nobody Had to Publish

Picture the situation of a company building both dies of a two-die product. It designs the transmitter and the receiver. It owns the package. It knows the traffic, because it designed both endpoints. It controls the schedule on both sides, and it decides when either changes.

Under those conditions, ask what a published specification would be for. A specification exists so that parties who cannot coordinate directly can still build things that work together. When both ends are inside one organisation, that coordination happens in design reviews. Writing a public, general, stable specification would cost real effort and deliver nothing the company needed.

A proprietary die-to-die link can optimise one company's system extremely well, because both ends are controlled together — and that same private optimisation becomes a compatibility barrier outside that system.

Both halves of that sentence matter, and the first half is where most treatments of this topic go wrong. Private links were not a failure of foresight or an industry mistake to be corrected. They were the correct engineering answer to the problem as it existed, and much of what they achieved is unavailable to a general standard. The limitation appears only when the goal changes.

2. What Owning Both Ends Buys

The advantages are concrete and worth enumerating, because a reader who cannot state them will not understand what standardisation later gave up.

Full co-design. The interface can be shaped to the exact traffic it carries. If the only thing crossing is a known mix from a known source, the link need not accommodate anything else — no unused modes, no generality, no negotiation for cases that cannot occur.

Latency tuned to the actual path. Layers of abstraction that exist to accommodate unknown partners can be removed. Handshakes can be simplified or skipped where both sides' timing is known at design time.

Bandwidth and energy optimised for the known package. The electrical design can target the specific channel it will run over — the actual reach, the actual routing structure, the actual bump arrangement — instead of the range of channels a general specification must tolerate. Chapter 2.6 explained why that matters: a link designed for one known short, dense channel can be more aggressive than one that must also work over a longer, coarser path.

Simpler version control. Both sides revise together. There is no requirement to interoperate with an older partner, because no older partner will ever be paired with the new die.

No external compatibility burden. No conformance programme, no interoperability testing against third parties, no obligation to support configurations the company will never build.

Freedom to evolve quickly. A private interface can change substantially between generations, because the only thing that must agree is the next product.

Read that list as a set of permissions granted by controlling both ends. Every one of them is a permission a cross-vendor standard cannot grant, which is the trade §8 returns to.

3. Two Historical Examples — and a Complication

The curriculum names two pre-UCIe approaches. Both are instructive, and the second one complicates the story in a way that is more useful than the simple version.

AMD's Infinity Fabric on-package die-to-die transport (IFOP). Infinity Fabric is AMD's system interconnect architecture, and its on-package variant carries traffic between dies within a package — in products where compute dies connect to a separate die hosting memory and I/O. It is an AMD-internal interconnect: designed by AMD, for AMD dies, in AMD packages. This is the archetype of the pattern in §1 and §2 — both ends owned, so no public specification required. (Published bandwidth, lane, and energy figures for it vary between secondary sources and are not consistent, so none are quoted here.)

Intel's Advanced Interface Bus (AIB) — and here the neat story breaks. AIB began as an Intel-developed die-to-die interface, used with Intel's packaging. But Intel did not keep it private: it made AIB available royalty-free to participants in DARPA's CHIPS programme, and subsequently contributed it to the CHIPS Alliance, which describes AIB as "an open-source, royalty-free PHY-level standard for connecting multiple semiconductor die within the same package."

So one of the two canonical "pre-UCIe proprietary links" was, in fact, opened — years before UCIe. Which raises the obvious question: if an open, royalty-free die-to-die standard already existed, why did the industry still need another one?

The answer is in five words of that quotation, and it is the most valuable thing in this chapter. AIB is a PHY-level standard.

4. Opening the PHY Is Not Enough

Recall from Chapter 1.6 what a die boundary actually requires. The physical layer — how a bit is driven onto a conductor and recovered at the other end, at what rate, with what electrical characteristics and bump arrangement — is one part of it. Sitting above that are questions the PHY does not answer:

• Framing. Where does a unit of data begin and end? How is a stream of bits divided into meaningful transfers?
• Flow control. How does the receiver tell the transmitter to stop? How much can be in flight before it must?
• Error behaviour. What is detected, how is it reported, and what does recovery consist of — retry, drop, or escalate?
• Bring-up. In what sequence do two independent dies establish a working link, and how does each know the other is ready?
• Management. How is the link configured, monitored, and put into or taken out of low-power states?
• Protocol mapping. What kind of traffic does the link carry, and how do higher-level transactions map onto it?

Two dies can implement the same PHY specification — identical electrical behaviour, identical bump pattern, physically capable of exchanging bits — and still be unable to work together, because they disagree about every one of those. Bits cross successfully and nothing useful happens.

A shared PHY makes two dies electrically compatible. It does not make them interoperable.

That is why an open PHY standard, genuinely open and genuinely useful, did not by itself produce an ecosystem of interchangeable chiplets. It solved one layer of a multi-layer agreement problem. What the remaining layers cost, and why cataloguing them is harder than it looks, is the subject of the next chapter — this one only needs to establish that the gap exists and that openness at one layer does not close it.

5. The Full Stack of Agreement

Which makes the general statement clearer. For a die designed by one party to work with a die designed by another, they must agree on:

• Electrical behaviour — signalling, rates, termination, and the physical bump arrangement the package must match.
• Framing and data representation — how bits become transfers.
• Flow control — backpressure semantics and buffering expectations.
• Bring-up and training — the sequence to reach a working state, and what happens when it fails.
• Error semantics — detection, reporting, attribution, and recovery.
• Management and power — configuration, telemetry, and coordinated power states.
• Package assumptions — reach, routing structure, and bump pitch that the electrical design presumes.
• Higher-level protocol — what the traffic means once it arrives.

Each is an independent opportunity to be incompatible. Two private links can perform the same conceptual job — move transactions between two dies in a package — and differ on all eight. Doing the same job is not the same as being interchangeable, which is why "they both connect dies" tells you nothing about whether a die from one system can be used in the other.

6. Closed Compatibility Islands

The structural consequence follows directly. A proprietary interface works because one organisation effectively owns both ends of the contract. Remove that condition and the interface has no mechanism for filling gaps: there is no shared context, no review meeting, no common roadmap.

So a compute die designed for private Link A cannot be paired with an I/O die designed for private Link B. Not because either is deficient, but because the agreement each relies on was made with a different partner. Each system is internally coherent and externally closed.

7. Internal Reuse Versus Ecosystem Reuse

An important distinction, because the easy conclusion here is wrong.

Internal reuse works fine with a private link. A company can define a stable proprietary interface and get genuine modular reuse from it: one compute die across several products, an I/O die paired with different compute configurations, product tiers by population. Everything Chapter 1.7 called Stage 3 — the manufactured die as the reuse unit — is achievable without any public standard. Proprietary systems absolutely can be chiplet architectures, and by Chapter 2.1's definition they qualify, since that definition requires a defined interface rather than a standard one.

Ecosystem reuse is the part that does not work. It requires dies designed independently, by parties without private coordination, to agree — across all eight layers of §5 — with no opportunity to negotiate. That is a categorically different requirement, and no amount of internal discipline produces it.

So the limitation of proprietary links is precise and narrow: not that they prevent chiplet architecture, but that they prevent cross-source composition. Stating it any more broadly is inaccurate and undersells what these links achieved.

8. Standardisation Is a Trade, Not a Victory

The balanced view, which matters because the alternative is a narrative in which standards simply win.

A cross-vendor standard must support more configurations, because it cannot know which will be used. It must offer broader compatibility, including with partners and packages its authors did not design. It necessarily changes more slowly, because every change must be agreed among independent parties and remain compatible with deployed silicon. And it carries interoperability obligations — conformance, testing, and negotiation machinery that a private link needs none of.

Every one of those is a cost paid in silicon, latency, or schedule. A private link tailored to one known channel, one known traffic mix, and one known partner may legitimately be faster, smaller, lower-power, or simpler than a general standard doing the same job. That is not a hypothetical concession — it follows directly from the permissions in §2.

Standardisation trades some local optimisation for ecosystem compatibility.

Whether that trade is worth making depends entirely on whether cross-source composition is a goal. For a company shipping a closed product family, it may not be. The industry moved toward standardisation because enough participants wanted the ecosystem — not because private links stopped working.

9. Versioning: Stability Matters More Than Openness

A subtler problem, and one that shows the axis people usually reach for is the wrong one.

Suppose a company keeps its link entirely private but changes it incompatibly every generation. Then a die from generation N cannot pair with a die from generation N+1. The consequences are immediate: reuse collapses back to within a single generation, the verification matrix grows with every combination that must be supported, and the product roadmap becomes coupled — dies must be revised together whether or not each needs it.

Now suppose the same company keeps its private link stable across generations. Reuse works, dies mix across generations, and the verification matrix stays manageable.

Same openness in both cases; completely different reuse outcomes. Which isolates the real variable:

What enables reuse is interface stability. Openness determines who can rely on that stability.

A stable private interface supports excellent reuse within one organisation. An unstable public one supports very little for anyone. Openness widens the set of parties who can build against a contract; stability is what makes the contract worth building against at all. A useful standard needs both — which is why specification versioning and backward compatibility are first-order concerns in standards work rather than administrative detail.

10. What Changes for Verification

The verification consequences are worth making explicit, because they scale differently in the two worlds.

Inside one proprietary ecosystem, verification can assume a great deal: which partners exist, which versions are in play, that interface evolution is coordinated, and that both endpoints can be simulated together because both are available. Interface bugs are found by testing the actual pairing that will ship. The matrix is bounded by the products the company builds.

Across independently designed endpoints, none of those assumptions survive. Verification must establish that an implementation is correct against a specification rather than against a specific partner — because the partner may not exist yet, may not be available to test against, and may be built by someone with no obligation to share it. That requires conformance to a defined behavioural contract, compatibility testing across permitted configurations, and an explicit policy for version negotiation and mismatch.

The shift is from "does this pairing work?" to "is this implementation correct against the contract, for every partner the contract permits?" That is a materially larger scope, and it is why interoperability has machinery that private links never needed. What that machinery looks like belongs to later chapters.

11. Common Misconceptions

12. Understanding Check

13. Summary and What Comes Next

Private die-to-die links were the rational answer to the problem as it stood. When one organisation designs both endpoints, owns the package, knows the traffic, and controls both schedules, a published specification solves a coordination problem that does not exist — while costing real capability, because a private link can be co-designed with the exact channel and traffic it serves. Owning both ends grants permissions a general standard cannot: full co-design, tuned latency, electrical design targeted at one known channel, simple versioning, no conformance burden, and fast evolution.

The cost appears only when the goal changes. Interoperability requires agreement across roughly eight independent layers — electrical behaviour, framing, flow control, bring-up, error semantics, management and power, package assumptions, and higher-level protocol — and performing the same job is not the same as being interchangeable. Since a private interface works precisely because one organisation owns both ends of the contract, removing that condition leaves nothing to fill the gaps, and each system becomes a closed compatibility island: internally coherent, externally unusable.

Two refinements keep the picture honest. Proprietary links do not prevent chiplet architecture — they support real internal reuse and satisfy the definition of a chiplet system; what they prevent is cross-source composition specifically. And openness alone is not the answer, which AIB demonstrates directly: an open, royalty-free PHY-level standard existed before UCIe and did not produce interchangeable chiplets, because the layers above the PHY remained unspecified. Meanwhile stability, not openness, is what makes an interface reusable — openness only determines who may rely on that stability. Standardisation is therefore a trade, exchanging some local optimisation for ecosystem compatibility, worth making only when the ecosystem is the goal.

Which leaves the problem stated but not yet examined. Proprietary links solved die-to-die communication inside individual companies; what remained unsolved was how two independently designed dies could meet without a private bilateral agreement:

• 3.2 — The Interoperability Problem — what it actually takes for a die from one vendor to be usable by another, and why the answer is larger than a shared interface specification.

Browse the full path on the UCIe tutorials index.