Day 2 covered the physics and numbers behind die-to-die interconnect. Day 3 goes into the standard itself — who built it, how it has evolved from version 1.0 to 3.0, the interfaces that let independently-sourced IP interoperate, and why a chiplet from one foundry can plug into a package built around a chiplet from a completely different foundry.
UCIe was announced in March 2022 by a founding group that reads like a list of the entire industry's major players: Intel, AMD, Arm, ASE, Google Cloud, Meta, Microsoft, Qualcomm, Samsung, and TSMC. The consortium formally incorporated in August 2022, at which point Nvidia and Alibaba joined as newly-elected board members.
This breadth matters. UCIe isn't one company's proprietary interconnect being open-sourced for goodwill — it's the rare case of direct competitors (Intel and AMD; TSMC and Samsung) agreeing on a shared standard because the alternative — everyone building incompatible proprietary chiplet interfaces — would fragment the entire ecosystem and slow the whole industry down.
| Version | Released | What It Added |
|---|---|---|
| UCIe 1.0 | 2022 | The base standard: Physical Layer, Die-to-Die Adapter, Protocol Layer; PCIe and CXL protocol support; Standard and Advanced packaging definitions |
| UCIe 1.1 | August 2023 | A streaming protocol mode with built-in error detection and replay, making the raw/streaming path more robust for non-PCIe/CXL traffic |
| UCIe 2.0 | August 2024 | 3D packaging support (higher bandwidth density and power efficiency than 2D/2.5D); the UCIe DFx Architecture (UDA) — a standardized manageability fabric per chiplet for testing, telemetry, and debug across the SiP lifecycle |
| UCIe 3.0 | August 2025 | 48 and 64 GT/s per-pin data rates (roughly double prior top speed); runtime recalibration for better power efficiency; extended sideband reach; early firmware download and priority sideband packets for manageability |
Dates and feature summaries per UCIe Consortium press releases and specification announcements.
Day 2 covered the three-layer stack (Physical, Die-to-Die Adapter, Protocol). What makes that stack genuinely useful across vendors is that the boundaries between those layers are themselves standardized:
Because both interfaces are precisely specified, a company can buy protocol-layer IP from one vendor and PHY IP from another, and know they will interoperate — the same way a CPU and a GPU from different companies both just "work" over a standard PCIe slot, without either company needing to see the other's internal design.
UCIe does not invent a new protocol from scratch. Instead, its Protocol Layer carries existing, well-understood protocols over the die-to-die physical link:
The key insight: reusing PCIe and CXL instead of inventing something new means existing software, driver models, and enumeration flows keep working. Only the physical transport changes — from a PCIe slot or board trace to a bump array on the same package.
Here is the feature that justifies the whole consortium existing: as long as each chiplet implements a UCIe-compliant PHY and adapter, a chiplet fabricated at TSMC can interoperate on the same package with a chiplet fabricated at Intel Foundry — different companies, different fabs, different process nodes, same package, same interconnect standard.
Before an open standard like this existed, mixing chiplets across foundries meant either both parties agreeing to a bespoke, one-off interface (expensive, slow, and non-reusable) or simply not doing it at all. UCIe turns that into a solved problem for any two compliant chiplets.
Claiming that a TSMC chiplet and an Intel Foundry chiplet can interoperate is one thing; proving it before either side commits to a tapeout is another. UCIe 2.0 established an initial framework for exactly this: physical, adapter, and protocol compliance testing, structured around a "golden" UCIe die — a known-good reference implementation covering every layer of the UCIe stack. A device under test (DUT) is validated by comparing its mainband-supported features against this golden reference, rather than every vendor pair having to test bilaterally against each other.
This isn't purely theoretical process either — Intel and Cadence have publicly demonstrated simulation interoperability as part of this compliance effort, showing that independently-developed UCIe implementations can be validated against each other before silicon exists. This compliance framework is what actually makes Day 1's "TSMC chiplet plugs into an Intel Foundry package" claim testable, not just aspirational.
UCIe's core specification targets on-package, die-to-die links. But the standard also defines retimers that can extend a UCIe connection off the package entirely — over electrical or optical media — to reach pooled memory, compute, or accelerator resources sitting elsewhere in a server rack, for example in a computer-on-module or a separate memory/storage module.
This comes with an honest tradeoff: going off-package trades away much of the power and latency advantage that makes on-package UCIe attractive in the first place. It's a useful escape hatch for system architects who want UCIe's protocol consistency across both on-package and rack-scale links, not a way to get on-package performance at rack-scale distances.