UCIe in Practice: The Spec vs What Actually Interoperates

UCIe is often described as a plug-and-play standard for chiplets, and its guiding principles do aim at that. Version 3.0 takes the top data rate to 64 GT/s and the specification now runs from the bump map up to firmware download. Read that as the promise. A team buying a die from another company has a narrower question: which parts of this link will work on first power-up, and which depend on choices nobody has written down yet?

This post works through the stack from protocol to test. It separates what the specification fixes from what it leaves to you, sets out what has been shown in public between different vendors, and gives a small worked model you can redo with your own numbers.

Key takeaways

• The physical layer and die-to-die adapter are tightly specified. Protocol-layer interoperability for streaming traffic is vendor specific, by the Consortium's own description.
• Manageability is optional. Two conforming dies can have no common way to download firmware, report errors or expose debug unless you make it a contract term.
• Public cross-vendor results in the sources we read either state rates no higher than 16 GT/s, give no rate, or are simulation work. The headline 64 GT/s rate is a specification target until someone shows otherwise.
• 64 GT/s is specified at a bit error rate of 10⁻¹², against 10⁻¹⁵ at 48 GT/s. In our model that is about 11 errors a second instead of one every 88 seconds, for the same module count.
• Ask for evidence at your package type, data rate, width and flit format. A result at any other combination tells you less than it appears to.

What the stack actually pins down

UCIe has three layers and two named internal interfaces. The Flit-aware Die-to-Die Interface (FDI) sits above the adapter, and the Raw Die-to-Die Interface (RDI) sits below it. The Consortium's published figures look like this:

Item	UCIe-S (2D)	UCIe-A (2.5D)
Data lanes per module	16	64
Bump pitch	100 to 130 µm	25 to 55 µm
Channel reach	Under 25 mm	Under 2 mm
Data rates	4, 8, 12, 16, 24, 32, 48 and 64 GT/s
Power efficiency target	0.5 pJ/b up to 16 GT/s, 0.75 pJ/b from 32 GT/s	0.25 pJ/b up to 12 GT/s, 0.3 pJ/b from 16 to 32 GT/s, 0.5 pJ/b from 48 GT/s

These are targets from the Consortium's 2025 webinar deck, which carries a disclaimer that material may change, so your specification revision has the final word. Two rules matter for interoperability. A component must support every data rate up to its advertised maximum, and a link is formed from one, two or four modules. So a 64 GT/s die paired with a 32 GT/s die should train at 32 GT/s, and three modules is not an option.

One catch is easy to miss. In the UCIe 1.1 bump map guidance, the maximum rate depends on pitch: 12 GT/s at 25 to 30 µm, and 32 GT/s only from 45 µm. The finest pitch does not carry the fastest signal. The 3.0 deck quotes its 48 and 64 GT/s shoreline targets at 45 µm.

A worked example: 48 or 64 GT/s?

Faster looks like an easy win, so here is a small model. The bandwidth requirement, the 90% protocol efficiency and the die layout are illustrative assumptions, and the energy figures are Consortium targets treated as if achieved. None of this is measured silicon or a vendor quote. Replace them with your own.

Assumption	Value
Required usable bandwidth	600 GB/s in each direction
Package and bump map	UCIe-A at 45 µm, 10-column x64: 388.8 µm shoreline and about 1,043 µm depth per module
Flit efficiency	68B flit with 64B of payload: 64 ÷ 68 = 94.1%
Protocol efficiency above the flit	90%
Combined efficiency	94.1% × 90% = 84.7%
Traffic on the wire	600 ÷ 0.847 = 708.3 GB/s each way, or 11.33 Tb/s in total

Result	32 GT/s	48 GT/s	64 GT/s
Raw per module, per direction (64 × rate ÷ 8)	256 GB/s	384 GB/s	512 GB/s
Usable per module	216.8 GB/s	325.3 GB/s	433.7 GB/s
Modules needed	2.77, so 4	1.84, so 2	1.38, so 2
Usable capacity	867.4 GB/s	650.5 GB/s	867.4 GB/s
Data lanes per direction	256	128	128
Shoreline, modules side by side	1,555.2 µm	777.6 µm	777.6 µm
PHY footprint	1.62 mm²	0.81 mm²	0.81 mm²
Link power at target energy	0.3 pJ/b: 3.40 W	0.5 pJ/b: 5.67 W	0.5 pJ/b: 5.67 W
Errors at the specified BER	Not in our sources	0.011 per second, about one per 88 s	11.3 per second

A check on the method: 2 × 512 GB/s over 388.8 µm gives 2,634 GB/s/mm, which matches the 64 GT/s shoreline target in the deck when both directions are counted.

Three things come out of this:

1. The module rule creates steps. At 32 GT/s the sum asks for 2.77 modules and you pay for four, doubling the footprint. That still saves 2.27 W against the faster options, so it can be the right answer if shoreline is free.
2. 64 GT/s buys nothing here. It uses the same two modules as 48 GT/s and has a thousand times the error budget. Above 650.5 GB/s the picture flips: 48 GT/s has to jump to four modules while 64 GT/s stays at two.
3. Replay cost is latency, not bandwidth. Eleven replays a second is negligible throughput, but it sets your tail latency and your error-counter thresholds. A real link may do better than the specified figure, and errors may cluster, so measure it. In Raw format the adapter's CRC and retry are bypassed, so those eleven errors a second become your protocol layer's problem.

The checklist, layer by layer

This is our reading of the Consortium's published material. The right-hand column is what we would put in a contract or a joint test plan.

Layer	What UCIe fixes	What is left to you	Ask for
Protocol	PCIe and CXL mappings, plus a streaming option for anything else, such as AXI or CHI	Streaming protocol-layer interoperability is vendor specific. Addressing, ordering and credit rules at that level are yours to agree	A written protocol profile, and that protocol's own compliance evidence
Flit format	Six formats, with a matrix of mandatory and optional per protocol. Raw is mandatory for streaming; 1.1 allows other formats too	Two streaming dies may share only Raw unless both implement the same flit format. That would lose adapter CRC and retry	The exact format list from both sides, before IP selection
Adapter	CRC and retry when used, link state management, parameter exchange over sideband	Which optional parameters you turn on, and how errors escalate to your system	A parameter exchange log from joint simulation
Logical PHY	Training state machine, lane repair on UCIe-A, width degrade on UCIe-S, lane reversal	Timing behaviour inside the states. See the Cadence and Intel findings below	Co-simulation up to ACTIVE, at your rate and width
Electrical	NRZ, quarter-rate clock at 48 and 64 GT/s, 3-tap TX FFE, RX CTLE, six TX presets	The 1-tap RX DFE is optional, so margin at 64 GT/s can differ between dies. Channel design is yours	Eye margins on your channel at each preset
Bumps and package	Bump maps, with rotation and mirroring supported; x64 can talk to x32 on the lower 32 lanes	Power delivery, die size, thermal placement and the choice of assembly house	A joint floorplan review with the assembly house
Management	From 2.0, an optional architecture with a management director and DFx hubs. From 3.0, firmware download, priority sideband packets and open-drain pins	Who acts as director, what is implemented at all, and vendor-specific extensions	A feature matrix of optional items for each die
Thermal	Fast throttle and emergency shutdown signalling in 3.0	Throttle levels are pre-negotiated, and each chiplet has its own Tj limit and sensor error	A SiP-level thermal agreement listing limits and thresholds
Test	Compliance registers from 1.1, eye margin and per-lane error logs, parity flit checks	Micro-bumps cannot be probed at sort, and nothing plugs into a package. Known-good-die strategy is yours	Sort coverage figures and access through JTAG or a UCIe-S port

A consultancy review of UCIe 3.0 verification, published in 2026, makes the same point at the system level: timeouts, firmware policy, recovery behaviour and optional features can all expose defects between implementations that each pass alone. We would add one narrow trap. In continuous transmission mode you can vary REFCLK to run at an adjusted speed, but the 3.0 deck says compliance is only performed at the IP's defined link speed settings. An adjusted rate is your own qualification.

What has been shown in public

Only pairings that a source names are listed here. Each result applies to the configuration tested, and it does not make those companies' other products interoperable.

Date	Pairing	What was shown	Source type
September 2023	Intel and Synopsys	Described as the first UCIe silicon interoperability, with Intel silicon on an Intel process and Synopsys silicon on a TSMC process	Consortium slide
August 2024	Intel vectors and Cadence UCIe-A x64 PHY	Pre-silicon RTL simulation up to ACTIVE, with a speed change to 16 Gbps	Cadence article
2025	Siemens EDA, Ayar Labs and Alphawave Semi	Co-simulation at PHY and controller level	Consortium blog
March 2026	Intel and Cadence	Live UCIe-S demonstration on the Cameron Creek test chip with 16G PHY IP, described as the first of its kind	Consortium blog

We found no public cross-vendor result at 48 or 64 GT/s in the sources we read. That is an absence of evidence, and work may exist that we did not find, so ask your vendor directly.

The Cadence article is the most useful of these, because it lists what went wrong. Sideband messages ran ahead of the PHY and caused an unrecoverable loss of sync. A PHY lane check order was wrong and had to be corrected. The vectors illegally skipped MBINIT substates. The vectors did not wait long enough for the PLL to relock after the speed change. The PHY ran 15 eye sweeps by default where the vectors ran one. Some of this reflects a vector-driven testbench rather than real dies, and the link did reach ACTIVE. Still, these are the kinds of mismatch to look for, and Cadence's point stands: everything except the analogue front end is digital and can be tested before silicon.

Compliance is not a finished answer

The published plan centres on a golden die in a reference package with reference channels. PHY checks cover timing and voltage margin, BER, lane-to-lane skew, even and odd eye asymmetry and TX equalisation. The golden die can also inject errors and force timeouts during training. Protocol compliance leans on the PCIe and CXL specifications, and streaming protocols use their own.

As of Cadence's August 2024 article, the plan had separate golden dies for standard and advanced packages, initial protocol support aimed at raw-mode streaming, and vendors still being sought to build them. We could not find a public Consortium statement on current status, so treat this as something to ask rather than assume. Tooling may also trail the specification: MathWorks' R2026b UCIe signal integrity kit targets Revision 2.0, for example. Check the revision on every tool and report.

How much interoperability do you need to prove?

Answer these five questions before you commit to a partner or an IP:

1. Do you control both dies? If you do, using the same IP on both sides removes most of this list. If not, joint simulation belongs in the contract.
2. Is your traffic PCIe or CXL, or streaming? PCIe and CXL bring an existing compliance base. Streaming means writing your own protocol profile.
3. Does your rate have public or private evidence? If the only evidence is at a lower rate, plan a fallback and check whether the product still meets its bandwidth there.
4. Are the optional features you rely on written down? If firmware download, debug or throttle levels are assumed, they are a risk until both vendors sign them off.
5. Can you tell a bad die from a bad link after assembly? If not, a failure costs you the whole package, and the test plan needs work first.

Two or more weak answers argue for a lower data rate, a single IP source or a test chip before the product. Our chiplet lifecycle on The Semiconductor Hub shows where these decisions fall in a programme.

FAQ

Is UCIe 3.0 backward compatible?

The Consortium says it is fully backward compatible with earlier versions, keeping the sideband, valid, track, data and training protocols. Expect the link to run at the lower partner's capability, and test that fallback.

Does UCIe-3D fit the same interoperability story?

Less so. The 2.0 white paper says bump pitches must match, so a 1 µm chiplet can only be bonded to another 1 µm chiplet. The Consortium itself says this is not broad plug-and-play.

Does passing compliance mean two dies will work together?

It raises the odds, but it does not cover your protocol profile, optional features, channel or thermal limits. Keep a joint test plan even with compliant parts.

Sources

• Das Sharma, "UCIe 3.0 Specification: Driving Innovation for Efficient, Scalable, and Reliable Chiplet Integration", UCIe Consortium white paper, 2025.
• Das Sharma, "Introducing the UCIe 3.0 Specification: Continued Innovations in the Open Chiplet Ecosystem", UCIe Consortium webinar deck, 2025.
• UCIe Consortium announcement of the 3.0 specification, 5 August 2025, as reported by DQIndia, 7 August 2025, and the Consortium post "UCIe 3.0 Specification: Redefining Chiplet Interconnects", 3 September 2025.
• Das Sharma, "UCIe 2.0 Specification: Continuing Innovation to Drive an Open Chiplet Ecosystem", UCIe Consortium white paper, 2024.
• Das Sharma, "The UCIe 1.1 Specification: Future Applications of Chiplets", UCIe Consortium webinar deck, 2023.
• Das Sharma et al., "UCIe" overview and protocol sessions, Hot Chips tutorial, August 2023.
• Taylor, Dick, Edmonds, Turker Melek and Bhatnagar (Cadence), "Intel and Cadence Collaboration on UCIe: Demonstration of Simulation Interoperability", 20 August 2024.
• UCIe Consortium, "The Growing Chiplet Ecosystem: Collaboration, Innovation, and the Next Wave of UCIe Adoption", 25 November 2025.
• UCIe Consortium, "Chiplet Summit 2026: UCIe Momentum Across a Growing Ecosystem", 5 March 2026.
• Bartley (Alpinum Consulting), "UCIe 3.0 Verification: Test, Debug and Sign-Off", 31 July 2026, updated 17 August 2026.
• MathWorks, "UCIe Compliance Kit", Signal Integrity Toolbox documentation, R2026b.

The worked example uses illustrative assumptions and Consortium targets rather than measured results. Vendor and Consortium statements are their own claims, as published on the dates shown.