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.
The Protocol Layer's One Job
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.
The Three Things That Can Ride the Link
⬡
PCIe (flit mode)Standard PCIe 5.0/6.0 traffic — existing PCIe software and enumeration flows work unchanged, just over a die-to-die link
🔗
CXLCXL.io, CXL.cache, and CXL.mem — cache-coherent CPU-to-accelerator and CPU-to-memory traffic between chiplets
🌐
Streaming (raw)A protocol-agnostic channel to map any proprietary fabric onto the standardized UCIe link and packaging
The 256-Byte FLIT — UCIe's Unit of Transport
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:
Because UCIe's flit size matches PCIe 6.0 and CXL 3.0, protocol packets from those standards map into UCIe flits with minimal translation
Fixed-size flits make flow control, error checking, and lane mapping far simpler than variable-length packets would
The same 256-byte flit framing is reused across protocols, so the adapter and physical layer below don't need to know or care which protocol produced a given flit
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.
ARB/MUX — Sharing One Link Between Protocols
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).
It uses weighted round-robin arbitration — with the weights set by the host — to interleave traffic from the CXL.io and CXL.cache/mem link layers fairly but tunably
It multiplexes the selected flits down onto the single link based on those arbitration results
It also coordinates power-state transitions, collapsing separate link-layer power requests into a single, clean request to the physical layer so the link powers down smoothly
PCIe Over UCIe — What Gets Dropped, and Why
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.
Why This Design Is So Powerful
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.
🎯 Day 5 Key Takeaways
The Protocol Layer generates/terminates protocol packets and hands flits to the adapter across the FDI interface
Three things can ride a UCIe link: PCIe flit mode, CXL (.io/.cache/.mem), and raw streaming for custom protocols
UCIe uses a 256-byte FLIT, matching PCIe 6.0 and CXL 3.0 so protocol packets map in with minimal translation
The ARB/MUX uses host-weighted round-robin arbitration to share one link between CXL.io and CXL.cache/mem, and coordinates power-state transitions
PCIe over UCIe can drop 8b/10b and 128b/130b encoding plus non-flit CRC/retry and legacy framing — saving area and latency on the short, clean die-to-die link
The net effect: existing PCIe/CXL software stacks run unchanged; only the physical transport changes from board-level to on-package
Frequently Asked Questions
What protocols can the UCIe protocol layer carry?
The UCIe protocol layer carries PCIe (flit mode), CXL — including CXL.io, CXL.cache, and CXL.mem — and a raw streaming mode that can map any other protocol. This lets existing PCIe and CXL software stacks run unchanged over a die-to-die link instead of a board-level connection.
What is a FLIT in UCIe?
A FLIT (Flow Control Unit) is the fixed-size unit of data the protocol layer works with. UCIe uses a 256-byte FLIT, consistent with the 256-byte flit defined in PCIe 6.0 and CXL 3.0, so protocol packets are mapped into these fixed 256-byte units for transport across the die-to-die link.
What is the ARB/MUX in UCIe?
The ARB/MUX (Arbitration and Multiplexing block) sits in the CXL-based protocol path and uses weighted round-robin arbitration — with weights set by the host — to interleave traffic from the CXL.io and CXL.cache/mem link layers onto the single physical link, and to coordinate power-state transitions into one request to the physical layer.
Why does PCIe over UCIe drop 8b/10b and 128b/130b encoding?
Those line-coding schemes and non-flit-mode CRC/retry and framing logic exist to make PCIe robust over long board traces and connectors. A UCIe die-to-die link is extremely short and clean by comparison, so a PCIe protocol layer optimized for UCIe can omit that legacy overhead, saving area and latency while relying on UCIe's own flit-mode reliability.
What is the FDI interface?
FDI (Flit-Aware Die-to-Die Interface) is the standardized boundary between the protocol layer and the die-to-die adapter. The protocol layer hands flits and link-management signals across FDI, which lets protocol-layer IP and adapter/PHY IP be developed and sourced independently while still interoperating.