Phase 1 taught the concepts that are true of CXL in general. Phase 2 walks the actual spec versions in order, because each one added a specific, nameable capability — and knowing which version brought what is exactly the knowledge that separates someone who's read a CXL blog post from someone who understands it. We start at the beginning: the foundational 1.0/1.1 generation.
Released in 2019 on the PCIe 5.0 physical layer (32 GT/s), CXL 1.0 and its 1.1 refinement laid the entire foundation this course has been describing. Everything in Phase 1 — the three sub-protocols, the three device types, the coherence model, the 68-byte flit — was defined here. Its three headline capabilities:
In other words, CXL 1.1 was the generation that proved the core idea worked: coherent memory, shared between a host and a device, over a PCIe-based link. That was the hard part. Everything after it is scaling that proven idea outward.
The defining structural characteristic of CXL 1.1 is simplicity: every CXL device connects point-to-point, directly to a single host. There is no switch in between, and no sharing of a device across hosts.
Technically, this makes CXL 1.1 a single-host, direct-attached architecture. Every device is dedicated to its one host. This is perfectly sufficient for expansion — giving one server more memory or a coherent accelerator — but it fundamentally cannot do pooling or sharing, because those require a switch sitting between multiple hosts and the memory. That switch arrives in CXL 2.0 (Day 7).
One capability worth calling out from this era: CXL persistent memory. Because a Type 3 device can present different memory types to the host (Day 4), non-volatile memory can be exposed over CXL.mem — a natural successor to the earlier NVDIMM-N persistent-memory modules that lived in DIMM slots. Bringing persistence onto the CXL link means the memory fabric itself can carry data that survives power loss, not just volatile DRAM. This foreshadows a recurring theme: CXL's Type 3 abstraction is memory-media-agnostic, which becomes increasingly powerful as the fabric grows.
Understanding a spec version is as much about its limits as its features — because those limits are precisely the roadmap for what came next:
| Not in CXL 1.1 | Added In |
|---|---|
| Switching (a CXL switch between hosts and devices) | CXL 2.0 |
| Memory pooling across multiple hosts | CXL 2.0 |
| Hot-plug of CXL devices | CXL 2.0 |
| Link-level Integrity & Data Encryption (IDE) | CXL 2.0 |
| Multi-host coherent memory sharing | CXL 3.0 |
| Multi-level switching & non-tree fabrics | CXL 3.0 |
Version feature attribution per CXL Consortium specifications and comparison materials.
A security note worth flagging: CXL 1.1 has no link-level encryption. Data on a CXL 1.1 link travels unprotected. This was acceptable for a single-host, physically-contained first generation, but became untenable as CXL moved toward pooled and disaggregated deployments where a link might cross a rack — which is exactly why CXL 2.0 added IDE (Day 7).
Every later CXL capability — switching, pooling, sharing, fabrics, confidential computing — is layered directly onto the CXL 1.1 foundation. The sub-protocols never change their fundamental roles; the device types stay the same three; the coherence model extends rather than replaces. When Day 7 adds a switch and Day 8 adds a fabric, they're adding structure around the exact primitives defined here. Master 1.1, and the rest of the version history reads as a series of clean additions rather than a confusing pile of features.