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.
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.