ACE Journal

Chiplet interconnect standards after UCIe

Who this is for: hardware architects and systems engineers working on chiplet-based designs, SoC platform teams evaluating multi-vendor integration, and firmware engineers who need to understand what the UCIe stack actually delivers below CXL. You should have a working mental model of differential signaling and PCIe/CXL basics. You do not need to have read the UCIe spec, but you should be building or evaluating real silicon.

The package that showed up in the press release versus the one you ship

Picture an AI accelerator program in 2023. The architecture team decides to disaggregate: a compute tile on a leading-edge node, an HBM interface tile on a cost-optimized node, and a SerDes/I/O tile from a third-party IP vendor. The pitch looks clean on the block diagram. The argument for disaggregation is sound: you avoid the yield cliff of a monolithic die, you can source each function from the process that suits it, and you get a faster iteration cycle on the compute tile without respinning the I/O.

Then the integration questions start. How do the tiles talk to each other? What bump pitch is the packaging house qualified for? Who tests the known-good state of each die before bonding? Who owns the link bring-up when the compute tile vendor and the HBM tile vendor point at each other?

UCIe was designed precisely for this situation. It arrived in 2022 with broad industry backing (Intel, AMD, Arm, TSMC, Samsung, Qualcomm, Google among the founding members) and UCIe 1.1 refined the spec through 2023. The premise is that if the die-to-die interface is standard, the integration work shifts from “can these two dies communicate at all” to “does this design meet the link budget.” That is a meaningful improvement. It is also not the whole story.

Mechanics: the UCIe stack

UCIe defines three layers. Understanding where each layer ends is as important as understanding what it specifies.

Figure 1 shows the layered structure and how UCIe maps onto a chiplet integration scenario.

graph TD
    subgraph "UCIe Stack"
        A["Protocol layer (PCIe / CXL)\n[UCIe adapter maps these]"]
        B["Die-to-die adapter layer\n[FDI / RDI interfaces]"]
        C["Physical layer\n[differential signaling, bump map, retimer]"]
    end
    A --> B
    B --> C
    C --> D["Package substrate / bump array\n[out of scope for UCIe]"]
    D --> E["Remote chiplet PHY"]

    style A fill:#d9edf7
    style B fill:#dff0d8
    style C fill:#fcf8e3

Figure 1. The UCIe layer stack from protocol to bump array. The dashed boundary at the package substrate is deliberate: UCIe stops there, leaving substrate design, thermal, and security to implementers.

Physical layer. UCIe specifies a differential serial interface with bump pitch options that vary by package class. The advanced package variant targets bump pitches down to roughly 25 microns, compatible with TSMC’s CoWoS and Intel’s EMIB and similar 2.5D/3D substrates. The standard package variant targets pitches around 55 microns, compatible with conventional flip-chip substrates. The physical layer also specifies lane widths (16 or 64 lanes per port), signaling rate bands, and the optional retimer for longer reach. The spec publishes the bump map pattern, which matters enormously for design: two chiplets that implement the same UCIe physical variant can be placed by the package house without a custom substrate design for each pair.

Die-to-die adapter layer. Above the PHY, UCIe defines the Flit-based Data Interface (FDI) and Raw Data Interface (RDI), the handoffs between the adapter and the upper protocol and between the adapter and the PHY respectively. The adapter handles flit framing, cyclic redundancy checks, forward error correction (optional depending on link length and quality target), and link training. This is the layer that earns UCIe the “Express” in its name: it is designed to carry PCIe and CXL transactions with latency close to what a board-level PCIe link would see, but over a die-to-die bump array instead of a PCB trace.

Protocol / adapter mapping. UCIe 1.0 and 1.1 specify adapters for PCIe Gen5 and CXL 2.0. Traffic from a CXL host controller on one die arrives at the UCIe adapter, gets encapsulated into flits, traverses the bump array, and is de-encapsulated on the remote die’s adapter before being handed to whatever IP block is receiving it. From the software perspective above, it looks like a short CXL link.

What UCIe does not specify: the package substrate geometry, the underfill or molding process, thermal interface materials, power delivery across die boundaries, and (critically) any security or isolation primitive at the chiplet boundary.

The choice between advanced and standard package is not just a cost decision; it determines what bandwidth you can extract from the UCIe physical layer for a given pin count.

The UCIe 1.0 spec tables (Section 5) give the basis for estimating link throughput. At the physical layer, the raw bit rate per lane is defined per package class. With advanced packaging, the short interconnect distances (sub-millimeter bump arrays on a silicon interposer or bridge die) allow higher signaling rates and tighter bump pitches, which means more lanes in a given die-edge area.

Figure 2 sketches a simplified link-budget comparison between the two package classes for the same logical interface width.

graph LR
    subgraph "Advanced package (CoWoS / EMIB)"
        AP["~25 µm bump pitch\nHigh lane density\nLower insertion loss\nRetimer optional"]
    end
    subgraph "Standard package (flip-chip organic)"
        SP["~55 µm bump pitch\nLower lane density\nHigher insertion loss\nRetimer may be needed"]
    end
    AP -->|"Higher aggregate BW\nper die-edge mm"| OUT1["BW/area advantage"]
    SP -->|"Lower cost substrate\nBroader foundry support"| OUT2["Cost / availability trade"]

Figure 2. Advanced versus standard package trade-offs in a UCIe context. Advanced packaging wins on bandwidth density; standard packaging wins on substrate cost and foundry availability. The right choice depends on your per-chiplet bandwidth requirement and your packaging supply chain.

For a concrete sense of scale without fabricating numbers: the UCIe spec itself (Section 5.3 in v1.0) describes the achievable raw throughput per cluster of lanes as a function of bump pitch and signaling rate. Engineers sizing a link should read those tables directly rather than relying on secondary summaries; the numbers are parameter-dependent and the spec is the authoritative source.

The practical constraint for most teams is not the spec ceiling but the substrate. Advanced packaging means fewer substrate vendors, longer lead times, and stronger coupling to a specific foundry’s packaging process. A team that wants source diversity for their chiplet supply chain will sometimes pick standard package specifically to preserve optionality, accepting the bandwidth trade.

A worked integration view

To make this concrete, consider a simplified UCIe integration between a compute die and an HBM interface die in an AI inference accelerator. The two dies sit on a silicon interposer (advanced package class). Each die exposes a UCIe port. The package house receives the bump map from the UCIe spec, qualified for the interposer process, and routes the substrate accordingly.

From the IP integration perspective, the compute die’s firmware stack sees something like the following handshake at link bring-up:

/*
 * Logical bring-up flow (register-level pseudocode).
 * UCIe defines no standard C API or HAL; actual bring-up is done through
 * vendor-specific register maps and firmware sequences that implement these
 * logical steps. Function names below are illustrative, not real symbols.
 */

phy_reset_and_calibrate(port, ADVANCED_PKG, LANES_64); /* PHY reset + calibration  */
rdi_lane_train(port);                                  /* RDI: lane alignment, CDR  */
fdi_protocol_negotiate(port, PROTO_CXL_2_0);           /* FDI: protocol handshake   */

if (link_state(port) != LINK_ACTIVE) {
    log_error("UCIe link training failed on port %d", port);
    /* Retry or escalate to board-level debug                                */
    return ERR_LINK_TRAIN;
}

/* Above this point: CXL 2.0 transactions flow as if on a board-level link  */
cxl_enumerate_device(port);

The handshake is deterministic once both dies are known-good and the bump array is intact. The failure modes at this stage are almost always physical: bumps missing solder contact, PHY calibration failing due to substrate crosstalk, or a marginal CDR lock on a lane pair. Link training failure is the first signal that something went wrong in assembly.

The hard part: known-good die, test, and multi-vendor interop

The integration sequence above assumes both dies arrive known-good. That assumption is where real chiplet programs spend most of their engineering time.

Known-good die (KGD) at wafer sort. In a monolithic SoC, you test the full die at wafer sort and discard the bad ones before packaging. With chiplets, each die is tested individually before bonding. The problem is that full-speed testing of a UCIe PHY requires the die to be in a package, because the bump array is the interface. Wafer-level probe can test the digital logic, but the high-speed differential PHY is difficult to probe at rated speed with a wafer probe card. The gap between wafer-sort coverage and post-package test coverage is the yield uncertainty that chiplet programs have to model carefully. The UCIe spec is silent on KGD test methodology; that is left to each die vendor.

Multi-vendor test coordination. When the compute die comes from vendor A and the HBM interface die from vendor B, post-package failure attribution is genuinely hard. A link training failure after bonding could be a defective UCIe PHY on either die, a substrate via problem, a bump co-planarity issue, or a firmware bug in the link training sequence. Vendors tend to blame the other party’s die until there is test data to localize. Getting that test data requires agreed test modes. The UCIe spec includes a loopback test mode at the PHY level, but the handoff between vendors on who runs what test at what stage of assembly is a process agreement that has to be negotiated separately from the spec.

Multi-vendor interop in practice. UCIe compliance testing exists via the UCIe Consortium’s interoperability framework, but as of early 2026, the interop test suite is still maturing. Two dies that independently pass UCIe compliance tests may still fail to train a link at rated speed due to marginal cases in clock recovery or lane skew tolerance. The conservative approach is to do full link-speed testing on the first assembled samples of any new die pair combination before committing to volume production.

Integration and day-to-day: where UCIe fits a real platform

For a platform team adopting UCIe, the day-to-day integration picture involves three concerns: sourcing, bringup scripts, and firmware.

Sourcing. UCIe-compliant HBM interface tiles and SerDes tiles from third-party vendors (several announced during 2025) are available as hard IP blocks or as chiplet products. The procurement path is closer to buying a component than licensing an RTL block: you receive a die with a defined bump map and a datasheet that cites UCIe compliance. The substrate co-design work remains non-trivial: the package house still needs the bump maps from both dies and the interposer routing rules to build the substrate.

Bringup. Link bring-up scripting follows the sequence sketched in the code block above: PHY init, RDI training, FDI negotiation, CXL enumeration. The practical addition is a register map for the UCIe PHY that allows reading per-lane margin, CDR lock status, and FEC error counts. This telemetry is what you use to distinguish a marginal bump from a firmware bug.

Figure 3 shows the bring-up and monitoring flow as a sequence that a platform firmware engineer would implement.

sequenceDiagram
    participant FW as Platform FW
    participant PHY_A as UCIe PHY (compute die)
    participant PHY_B as UCIe PHY (HBM-IF die)
    participant CXL as CXL stack

    FW->>PHY_A: phy_reset(); phy_cal()
    FW->>PHY_B: phy_reset(); phy_cal()
    PHY_A->>PHY_B: RDI lane training (CDR, alignment)
    PHY_B->>PHY_A: RDI training ack
    FW->>PHY_A: fdi_negotiate(CXL_2_0)
    PHY_A->>PHY_B: FDI protocol handshake
    PHY_B->>PHY_A: FDI ack
    FW->>CXL: enumerate device on UCIe port
    CXL-->>FW: device enumerated
    loop Per-second health poll
        FW->>PHY_A: read lane_margin[], fec_errs[]
        FW->>FW: log_telemetry(); alert_if_degraded()
    end

Figure 3. Platform firmware bring-up and health-monitoring sequence for a UCIe link. The bring-up phase is one-time; the health poll runs continuously to catch marginal lanes before they cause link errors.

Firmware and CXL enumeration. Above the UCIe adapter, the CXL software stack enumerates the remote die as a CXL device. For an HBM interface tile, that means the memory controller on the compute die accesses the HBM pool through the CXL.mem protocol. The firmware abstracts the UCIe link entirely. From the OS or the ML runtime perspective, the memory is a CXL memory region, not a “UCIe-attached HBM chiplet.” This is the design point: UCIe is infrastructure, not an application-visible interface.

UCIe is not the only die-to-die interconnect standard, and it is not winning everywhere.

Bunch of Wires (BoW). The Open Compute Project’s Bunch of Wires interface is a parallel die-to-die link that predates UCIe and targets applications where simplicity and determinism matter more than protocol richness. BoW does not carry PCIe or CXL semantics; it is a raw parallel channel. For designs that do not need cache-coherent protocol mapping, BoW’s simpler PHY can be easier to implement and lower in latency. UCIe and BoW target different points in the protocol-complexity trade-off space.

Intel AIB and AIB2. Intel’s Advanced Interface Bus was the precursor to much of what became UCIe’s physical layer definition. AIB is deployed in Intel’s own chiplet products (Stratix 10 FPGA chiplets, for instance) and has been licensed to other vendors. AIB2 extended the interface. AIB/AIB2 are Intel-defined rather than consortium-governed, which matters for multi-vendor adoption. UCIe drew on AIB’s physical layer design while adding the consortium governance model and the protocol adapter layer.

OpenHBI. The Open High Bandwidth Interface targets the HBM-controller-to-DRAM-stack link specifically. It addresses a narrower use case than UCIe (memory interface, not general die-to-die) but is designed to be IP-provider-neutral. Teams building custom HBM controllers sometimes evaluate OpenHBI for the memory interface and UCIe for other die-to-die connections in the same package.

Proprietary links. AMD’s Infinity Fabric, Apple’s proprietary die-to-die links in multi-die Mac chips, and NVIDIA’s NVLink for GPU interconnect are all deployed at scale and outperform UCIe on the metrics their vendors optimized for (Infinity Fabric latency within an EPYC socket, for instance). The trade-off is that they are single-vendor. UCIe’s value proposition is specifically multi-vendor interoperability; it is not claiming to beat proprietary links at their own metrics on their own silicon.

Where it breaks

UCIe is a genuine step forward for multi-vendor chiplet integration. It also has a set of honest failure modes that engineers should carry into any design evaluation.

The security boundary that does not exist. UCIe assumes mutual trust between chiplets in a package. That assumption holds when a single vendor controls all dies in the package and the package never leaves a controlled supply chain. It breaks for multi-tenant accelerator architectures (a shared AI inference accelerator rented to multiple customers), for supply-chain integrity scenarios (how do you verify that a third-party die has not been tampered with before bonding?), and for any design that runs code with different privilege levels on different dies. No attestation mechanism, no hardware isolation primitive, no shared secret provisioning protocol is in the UCIe spec. This is an active research area as of early 2026, but nothing has been ratified.

KGD yield uncertainty at scale. As described in the “hard part” section, the gap between wafer-sort test coverage and post-package link-speed test coverage is a real cost driver. For expensive advanced-package chiplet assemblies, a post-bond failure that cannot be localized to one die means scrapping the whole assembly. This risk is proportional to the number of dies in the package and the assembly cost. Chiplet programs that look attractive on a per-die-cost spreadsheet sometimes look worse when post-bond yield loss is modeled honestly.

Test and debug after bonding. Once the package is sealed, physical access to individual die pads is gone. UCIe loopback modes give some visibility, but diagnosing a marginal lane at full rated speed through a substrate via and a bump array, from the outside, is genuinely hard. The tooling for post-bond chiplet debug is less mature than the tooling for PCB-level signal integrity work. Teams that have only done board-level bring-up often underestimate this.

Multi-vendor firmware ownership. A UCIe link between two dies from different vendors means two firmware teams need to agree on link training sequences, error handling, and the power state machine. The spec defines the protocol; it does not define who owns the bring-up flow or how disagreements about marginal link behavior get resolved. In practice this becomes a supply-chain and support-contract negotiation that belongs in the SoW before the design starts, not in a bug tracker after first silicon.

CXL coherence complexity above the link. UCIe carries CXL cleanly, but CXL’s own complexity (cache-coherence directory protocols, multi-host support in CXL 2.0 and later, the semantics of CXL.mem vs CXL.cache) does not simplify because the physical layer is standardized. Engineers who are new to CXL sometimes expect UCIe to abstract coherence. It does not. UCIe is the pipe; CXL semantics are still your problem.

Standard-package bandwidth ceilings. Teams that choose standard package for cost or supply-chain reasons and then find themselves wanting more bandwidth mid-program cannot easily switch packaging processes without a substrate redesign. The bump pitch and lane density of the standard package class cap the aggregate link bandwidth below what the same die count could achieve in advanced packaging. If your workload is memory-bandwidth-bound, the package class decision belongs in the architecture phase, not the cost-reduction phase.

Further reading

The UCIe Consortium’s specification page [1] is the authoritative source for the 1.0 and 1.1 specs; read the physical layer and adapter chapters before sizing a link. The BoW interface specification from OCP [2] is the right reference for comparison at the simple-parallel-link end of the spectrum. Intel’s AIB architecture paper [3] documents the physical layer lineage that UCIe’s PHY draws from. For CXL above the adapter layer, the CXL Consortium’s spec repository [4] and the CXL 2.0 white paper [5] are the starting points. The JEDEC HBM3 standard [6] is relevant background for teams integrating HBM interface tiles. For chiplet ecosystem context, the Chiplet Design Exchange (CDX) working group materials [7] address packaging co-design conventions that UCIe does not specify. The ICCAD 2022 and 2023 proceedings contain several refereed papers on UCIe PHY design and chiplet integration that are worth reading before any serious architecture decision [8].

Written with AI assistance, editorially reviewed.

References

[1] UCIe Consortium, “UCIe Specification 1.0 / 1.1.” https://www.uciexpress.org/specifications

[2] Open Compute Project, “Bunch of Wires (BoW) Interface Specification.” https://www.opencompute.org/documents/ocp-bunch-of-wires-interface-specification

[3] B. Dally et al., “High-Bandwidth, Low-Latency Die-to-Die Interconnect,” in IEEE Micro; also Intel, “Advanced Interface Bus (AIB) Architecture Specification.” https://github.com/intel/aib-phy-hardware

[4] CXL Consortium, “CXL Specification Repository.” https://www.computeexpresslink.org/spec-landing

[5] CXL Consortium, “CXL 2.0 White Paper: Enabling Breakthrough Innovations.” https://www.computeexpresslink.org/download-the-specification (CXL Consortium resources page; navigate to white papers)

[6] JEDEC Solid State Technology Association, “High Bandwidth Memory (HBM) DRAM Standard JESD235.” https://www.jedec.org/standards-documents/docs/jesd235

[7] Open Compute Project / Chiplet Design Exchange, “CDX Working Group.” https://www.opencompute.org/projects/chiplet-design-exchange

[8] IEEE/ACM International Conference on Computer-Aided Design (ICCAD), Proceedings 2022-2023. https://ieeexplore.ieee.org/xpl/conhome/1000815/all-proceedings