Day 4 covered the wires. Day 5 covers what actually rides on them. The Protocol Layer is where UCIe makes its cleverest engineering decision: instead of inventing a new protocol, it reuses PCIe and CXL almost verbatim — so the software, drivers, and device models that already exist keep working, and only the physical transport changes. This lesson unpacks how, right down to the 256-byte FLIT and the arbitration block that shares one link between multiple protocols.
Sitting at the top of the UCIe stack, the Protocol Layer generates and terminates the actual protocol packets that cross the die-to-die link. It hands those packets — packaged into fixed-size flits — down to the Die-to-Die Adapter across the FDI (Flit-Aware Die-to-Die Interface) you met on Day 3. Everything below FDI (the adapter and physical layer) is protocol-agnostic plumbing; everything at and above FDI is where "this link is carrying PCIe" or "this link is carrying CXL" is actually decided.
A FLIT (Flow Control Unit) is the fixed-size chunk the protocol layer works in. UCIe uses a 256-byte FLIT, deliberately matching the 256-byte flit already defined by PCIe 6.0 and CXL 3.0. This alignment is not a coincidence — it's the whole point:
Why fixed-size matters: older PCIe used variable-length transaction-layer packets (TLPs) with 8b/10b or 128b/130b line coding to stay robust over long board traces. Flit mode replaces that with fixed 256-byte units and a cleaner reliability scheme — a much better fit for the short, clean die-to-die environment UCIe operates in.
CXL famously runs three sub-protocols at once — CXL.io (PCIe-like configuration and I/O), CXL.cache (device caching of host memory), and CXL.mem (host access to device-attached memory). When those share a single physical link, something has to decide whose flit goes next. That something is the ARB/MUX (Arbitration and Multiplexing block).
Here's a detail that shows how thoughtfully UCIe reuses PCIe. A PCIe protocol layer built for board-level links carries a lot of machinery specifically to survive long, lossy copper traces and physical connectors. Over a UCIe die-to-die link — millimeters long, on a clean package medium — much of that machinery is dead weight. So a PCIe-over-UCIe implementation may omit:
| Legacy PCIe feature | Why it can be dropped over UCIe |
|---|---|
| 8b/10b encoding | Line coding for DC balance over long traces — unnecessary on a short, clean die-to-die link |
| 128b/130b encoding | Same rationale — the lower-overhead flit-mode scheme is used instead |
| Non-flit-mode CRC / Retry | Flit mode has its own reliability scheme; the old per-TLP CRC/retry path isn't needed |
| Legacy framing logic | Fixed 256-byte flits don't need the variable-length framing that TLPs required |
The payoff: dropping this legacy overhead saves silicon area and cuts latency, while UCIe's own flit-mode reliability (and the adapter's optional CRC + retry, from Day 2) provides the data integrity that the removed logic used to.
Protocol details per UCIe Consortium materials and the PCIe 6.0 / CXL 3.0 flit specifications.
It's worth being precise about how mature the CXL side of UCIe's protocol layer really is in the field. As of the current production landscape, most shipping silicon uses CXL 2.0 — CXL 3.0 exists mainly in pre-production samples rather than volume shipping parts, and CXL 3.1 is largely a fabric-management refinement layered on top. The CXL Consortium has already moved further ahead of that, releasing CXL 4.0 in November 2025, doubling bandwidth to 128 GT/s (riding on PCIe 7.0) and introducing bundled ports supporting 1.5 TB/s connections.
Real silicon exists at the controller level too: Montage Technology's M88MX6852 controller, introduced in late 2025, supports DDR5-8000 with advanced RAS features and has become a building block for disaggregated AI memory architectures. Broader memory pooling deployment — multiple hosts sharing a common memory pool through CXL switches — is scheduled for the 2026–2027 window.
The practical implication for UCIe: when a chiplet's protocol layer is described as carrying "CXL," it's worth checking which CXL generation is actually meant. A UCIe link carrying CXL 2.0 today has meaningfully different capabilities than one built for the CXL 3.0/4.0 fabric-switching and pooling features still rolling out — the protocol mode name alone doesn't tell you the full story.
Step back and look at what this achieves. A CPU chiplet and an accelerator chiplet, possibly from different vendors and different foundries, can talk to each other over a UCIe link using CXL.cache and CXL.mem — full cache coherency — while the CPU's existing memory model, the accelerator's existing driver, and the operating system's existing CXL support all behave exactly as they would over a board-level CXL link. The chiplets don't know they're chiplets. The software doesn't know the transport changed. That transparency is the entire reason UCIe reuses these protocols instead of inventing a new one.