CXL Explained: Protocols, Device Types, Versions, and Memory
CXL (Compute Express Link) is becoming a key interface for expanding, pooling, and eventually sharing memory beyond the traditional CPU-attached DDR subsystem.
In the first three parts of this series, we examined memory technologies positioned close to the GPU. HBM increases bandwidth by stacking DRAM next to the accelerator, while HBF combines NAND capacity with HBM-class packaging to address much larger datasets.
CXL approaches the memory problem from a different direction.
It appears whenever data-center architects discuss memory expansion, memory pooling, VM consolidation, or hot/warm/cold memory tiering. Yet CXL can be difficult to understand because the standard combines three protocols—CXL.io, CXL.cache, and CXL.mem—while also defining Type 1, Type 2, and Type 3 devices across multiple generations from CXL 1.1 through CXL 3.x.
The easiest way to understand CXL is to start with a fundamental question:
If servers already have DDR and PCIe, why do we need another interface for memory?
The answer explains both where CXL sits in the memory hierarchy and why Samsung, SK hynix, and Micron are all developing increasingly broad CXL memory portfolios.
This article focuses on the architectural concepts behind CXL and the current direction of the CXL memory ecosystem. Product specifications and commercialization status can change as vendors introduce new generations.
🧩 Why CXL Exists: The Gap Between DDR and PCIe #
The simplest explanation is:
DDR does not scale indefinitely, while PCIe was not designed to behave like coherent memory.
A server CPU broadly relies on two different interconnect paths.
- DDR memory channels connect the CPU directly to DRAM.
- PCIe links connect the CPU to peripherals such as GPUs, NICs, SSDs, and accelerators.
Both interfaces are highly effective at what they were designed to do. The problem is that neither is ideal for the emerging requirement to place large amounts of memory farther away from the CPU while still exposing it as usable system memory.
DDR: High Performance, Limited Scalability #
Adding more DDR memory generally requires more memory channels.
More channels increase CPU package pin count, motherboard routing complexity, power consumption, and platform cost. Server processors therefore cannot simply keep adding memory channels indefinitely.
Modern server CPUs can expose many memory channels, but each socket still has a finite number of channels and DIMM slots. As a result, practical per-socket DRAM capacity eventually reaches a physical and economic ceiling.
That limitation becomes increasingly important for workloads such as LLM inference.
Model weights, KV caches, embeddings, retrieval indexes, and other data structures can push memory requirements far beyond what a conventional CPU socket can economically accommodate.
The problem is therefore not simply that DRAM is expensive. It is that the CPU’s direct memory interface is fundamentally bounded by the number of channels and physical connections available on the package and motherboard.
PCIe: Expandable, but Not Native Memory #
The obvious alternative is to connect additional memory through PCIe.
For example, a PCIe 5.0 x16 link provides roughly 64 GB/s per direction, or approximately 128 GB/s of aggregate bidirectional bandwidth. That is substantial bandwidth and can be comparable to the bandwidth of an individual DDR memory channel.
But bandwidth is not the fundamental problem.
The first issue is cache coherency.
CPU caches and attached DDR memory operate inside the CPU’s coherency domain. If multiple agents access the same cache line, the CPU’s coherency mechanisms maintain a consistent view of the data.
Traditional PCIe devices do not automatically provide that same memory semantics. PCIe is fundamentally an I/O interconnect rather than a cache-coherent memory protocol.
Without an additional coherency mechanism, software generally has to treat the memory behind a PCIe device as device-owned memory and explicitly move or manage data rather than simply treating it as ordinary system RAM.
The second issue is access semantics.
CPU memory operations naturally work at cache-line granularity. PCIe transactions, meanwhile, are designed around I/O transactions rather than native CPU load/store semantics.
So although memory can physically be attached through PCIe, the CPU does not automatically see it as an extension of its own coherent memory system.
CXL Fills the Empty Seat #
This creates a clear architectural gap:
We need an interface that preserves memory coherency like DDR while allowing memory and devices to be physically separated like PCIe.
CXL was designed to fill this gap.
Importantly, CXL does not invent an entirely new physical interconnect. It uses the PCIe physical layer and adds a set of protocols designed specifically for coherent communication between CPUs, accelerators, and memory devices.
This is the core CXL idea:
Use the existing high-speed PCIe infrastructure while adding memory and cache coherency semantics above it.
That architectural decision is one of the reasons CXL can scale faster than a completely new physical interface would.
🔗 The Three CXL Protocols: CXL.io, CXL.cache, and CXL.mem #
CXL.io, CXL.cache, and CXL.mem operating over a common CXL link
CXL is not a single protocol. It is a family of three related protocols that can operate over the same physical link.
| Protocol | Primary Role | Direction / Relationship |
|---|---|---|
| CXL.io | Device discovery, configuration, interrupts, and DMA | PCIe-like I/O |
| CXL.cache | Allows a device to cache host memory | Device → Host memory |
| CXL.mem | Allows the host to access device-attached memory | Host → Device memory |
Understanding these three protocols makes the CXL device types much easier to understand.
CXL.io: The PCIe-Compatible Foundation #
CXL.io handles functions that are familiar from PCIe:
- Device enumeration
- Configuration-space access
- Interrupt handling
- DMA
- General device management
Every CXL device uses CXL.io.
This is important because CXL was designed to coexist with existing PCIe infrastructure rather than requiring an entirely separate ecosystem of firmware, operating-system mechanisms, and platform hardware.
CXL.cache: Bringing Host Memory Closer to the Device #
Consider an accelerator that repeatedly accesses structures stored in CPU memory.
With a conventional PCIe connection, the accelerator can access host memory, but it does not automatically participate in the CPU’s cache-coherency domain.
CXL.cache changes that model.
It allows a device to cache host memory at cache-line granularity while maintaining coherency with the host’s memory system.
This is useful for devices such as accelerators, SmartNICs, and other programmable devices that repeatedly access host-resident data structures.
Conceptually, CXL.cache extends coherency across the link. Instead of treating the host’s memory as an external resource that must always be fetched through ordinary I/O semantics, the device can maintain coherent cached copies.
CXL.mem: Making Device Memory Part of the Host Address Space #
CXL.mem addresses the opposite direction.
Here, the device contains memory—such as DRAM—and the host wants to access that memory using ordinary load/store operations.
From the host’s perspective, the CXL-attached memory can appear as an addressable region of system memory.
This is particularly important for Type 3 devices, which are essentially dedicated memory expanders.
The host acts as the primary coherency manager for this memory. The device does not need to maintain a cache of host memory, which keeps the implementation significantly simpler.
Type 2 devices are more complicated because they combine device-attached memory with device-side caching of host memory. They therefore need mechanisms to coordinate ownership and coherency across both sides of the link.
How the Three Protocols Combine #
The protocols can be combined according to the device’s role.
| Device Role | Protocol Combination |
|---|---|
| Device caches host memory but has no device-attached memory | CXL.io + CXL.cache |
| Device has memory and also caches host memory | CXL.io + CXL.cache + CXL.mem |
| Device provides memory to the host without caching host memory | CXL.io + CXL.mem |
These combinations map directly onto the three standard CXL device types.
🧱 CXL Type 1, Type 2, and Type 3 Devices #
CXL devices are commonly divided into three types according to their memory and coherency capabilities.
| Type 1 | Type 2 | Type 3 | |
|---|---|---|---|
| Protocols | CXL.io + CXL.cache | CXL.io + CXL.cache + CXL.mem | CXL.io + CXL.mem |
| Device-attached memory | No | Yes | Yes |
| Caches host memory | Yes | Yes | No |
| Typical role | Coherent accelerator | Coherent accelerator with local memory | Memory expansion |
The distinction is architectural rather than simply a product-category label.
Type 1: Coherent Access to Host Memory #
A Type 1 device has no device-attached memory but can cache host memory.
A SmartNIC or FPGA accelerator is a useful conceptual example. Such a device may repeatedly access host-side queues, descriptors, or data structures. CXL.cache allows the device to maintain coherent cached copies instead of repeatedly retrieving data through conventional I/O mechanisms.
Type 1 therefore targets workloads where the device needs frequent, low-latency access to host-resident data structures but does not require a large independent memory space.
Type 2: Accelerator With Local Memory and Host Coherency #
Type 2 devices combine both capabilities.
They have their own memory and can also cache host memory. As a result, they use all three CXL protocols.
A conceptual example is a GPU or AI accelerator with local HBM or other high-bandwidth memory that also needs coherent access to CPU memory.
The architectural flexibility comes at a cost.
A Type 2 implementation has to handle coherency across device-local memory, device caches, and host memory. The controller and software architecture are therefore substantially more complex than those of a Type 3 memory expander.
This complexity is one reason Type 2 has not become the dominant CXL product category.
Type 3: The CXL Memory Expander #
Type 3 devices contain their own memory and expose that memory to the host through CXL.mem.
They do not cache host memory.
In simplified terms, a Type 3 device is:
A memory module positioned farther from the CPU and connected through CXL instead of a conventional DDR channel.
This makes Type 3 the most straightforward CXL product category for existing DRAM manufacturers.
The implementation is comparatively simple, the product directly addresses the DDR capacity ceiling, and the architecture maps naturally onto memory expansion and pooling.
Consequently, most commercial CXL memory products have focused on Type 3.
🌐 CXL Evolution: From Direct Attachment to Fabric #
CXL’s evolution from 1.x through 2.0 and 3.x can be understood as a progression in distance, scale, and sharing.
More memory, farther from the CPU, shared across more hosts, with increasingly sophisticated fabric management.
CXL 1.1: Direct-Attached Expansion #
CXL 1.1 represents the basic CXL topology.
A CXL device connects directly to a host CPU, similar to how a PCIe device connects to a PCIe root complex.
The primary objective is straightforward:
Expand the memory or coherent-device capabilities of a single host beyond what conventional interfaces can provide.
At this stage, CXL is primarily a single-node technology.
CXL 2.0: Switching and Memory Pooling #
CXL 2.0 introduced a major architectural change by adding CXL switching and enhanced resource-management capabilities.
This makes it possible to connect multiple hosts and memory devices through a shared infrastructure.
One of the most important applications is memory pooling.
Instead of provisioning every server with enough DRAM to handle its absolute peak requirement, a data center can place additional memory into a shared pool and allocate portions of that pool to individual hosts as required.
However, an important distinction must be made.
CXL 2.0 memory pooling is primarily resource allocation, not unrestricted simultaneous sharing of the same memory region.
A large memory resource can be divided into logical portions through mechanisms such as Multi-Logical Devices (MLDs). A Fabric Manager can then assign those portions to different hosts.
Conceptually:
One memory region can move between hosts, but a given allocation is not simultaneously owned by multiple hosts.
This model avoids many of the coherency problems associated with true multi-host shared memory.
The result is a more efficient model for data-center memory provisioning. Instead of purchasing enough dedicated memory for every server’s worst-case workload, operators can potentially centralize additional capacity and allocate it where demand appears.
CXL 3.x: Fabric-Based Scaling and Shared Memory #
CXL 3.0, 3.1, and 3.2 continue this evolution toward larger and more flexible fabrics.
Two changes are particularly important.
First, the architecture moves beyond simple resource rotation toward multi-host access to shared memory resources, with hardware mechanisms for maintaining coherency where applicable.
This enables architectures such as Global Fabric Attached Memory (GFAM), in which memory resources can be accessible across multiple hosts under controlled fabric management.
Second, CXL 3.x expands the architecture from simple switched connections into a more general fabric.
Port-Based Routing (PBR) provides mechanisms for routing traffic based on destination-port information rather than relying exclusively on a conventional hierarchical topology.
This creates opportunities for larger and more flexible network structures, including topologies such as mesh, dragonfly, and 3D torus configurations.
At this point, CXL begins to look less like a peripheral interface and more like a data-center-scale interconnect architecture.
That puts it into the same broader architectural conversation as accelerator interconnects such as NVIDIA NVLink and open standards such as UALink, although their target workloads and system roles are not identical.
As of 2026, commercial CXL deployments remain heavily centered on CXL 2.0-class products, while CXL 3.x capabilities are increasingly moving from specifications into silicon and platform implementations.
💾 The CXL Memory Roadmap of Samsung, SK hynix, and Micron #
The architectural discussion becomes much more concrete when looking at actual memory products.
Although CXL is developed through a broad industry ecosystem that includes CPU vendors, cloud providers, accelerator companies, and infrastructure vendors, the memory manufacturers have strong incentives to commercialize Type 3 CXL products.
Samsung, SK hynix, and Micron have all developed CXL memory offerings targeting similar parts of the market.
| Company | Representative Product | Form Factor | Primary Direction |
|---|---|---|---|
| Samsung | CMM-D | E3.S | CXL 2.0 memory expansion |
| Samsung | CMM-B | Box appliance | Memory pooling |
| Samsung | CMM-H | E3.S | DRAM + NAND hybrid memory |
| SK hynix | CMM-DDR5 | E3.S | DDR5-based expansion |
| SK hynix | CMM-Ax | E3.S | Memory + compute integration |
| Micron | CZ120 / CZ122 | E3.S | CXL memory expansion |
The repeated appearance of the E3.S form factor is notable.
E3.S is already familiar in modern data-center infrastructure, particularly in high-density storage deployments. Using an established server form factor can simplify mechanical integration, serviceability, and hot-swap-oriented platform design.
Specific capacities and configurations vary by generation and product, but the broader pattern is clear: vendors are initially positioning CXL memory as an additional tier of DRAM rather than as a direct replacement for conventional DDR.
Tier One: Straightforward Type 3 Memory Expansion #
The first and most direct product category is a CXL memory module built around DRAM.
Examples include:
- Samsung CMM-D
- SK hynix CMM-DDR5
- Micron CZ120/CZ122
The concept is simple.
Instead of placing every byte of memory directly on a CPU’s DDR channels, the system adds another memory tier through CXL.
This targets workloads such as:
- In-memory databases
- Large-scale analytics
- VM consolidation
- CPU-side KV-cache storage
- Embedding stores
- Applications constrained by per-socket DRAM capacity
The trade-off is equally straightforward: CXL memory provides additional capacity at higher latency than directly attached DDR.
Tier Two: Pooling and Memory Appliances #
The next step is to move beyond an individual memory module.
Samsung’s CMM-B, for example, represents a memory-appliance direction in which multiple CXL memory resources are combined behind a larger infrastructure layer.
A CXL switch can then expose pooled memory to multiple hosts.
This changes the product from a component into a system-level memory resource.
Instead of asking:
How much DRAM should this server contain?
the infrastructure designer can begin asking:
How much memory capacity should this rack or cluster have, and how dynamically should that capacity be allocated?
That distinction is fundamental to CXL’s long-term value proposition.
Tier Three: Bringing Compute Into the Memory System #
Another direction is to place processing capabilities closer to the memory itself.
SK hynix’s CMM-Ax and related industry concepts illustrate the broader idea of combining CXL memory with compute capabilities.
This falls into the territory of Near-Memory Processing (NMP) and Processing-in-Memory (PIM).
The basic principle is:
When moving the data is more expensive than processing it locally, perform the computation near the data and return only the result.
Potential workloads include:
- Vector similarity search
- Embedding filtering
- Database filtering
- Aggregation
- Selected stages of LLM inference
- KV-cache processing
- Top-k selection
For such architectures to make economic and performance sense, the computation must have a favorable compute-to-data-movement ratio.
Moving a huge embedding database from a CXL memory device to the CPU just to perform a relatively simple similarity calculation can waste bandwidth and energy. Performing the operation near the memory and returning only the relevant candidates can substantially reduce data movement.
This is conceptually related to the HBF + HAVEN architecture discussed earlier in this series: place a large data set close to the compute engine that searches it instead of repeatedly moving the entire data set through the system interconnect.
CXL provides another architectural path toward that same principle.
🏗️ Beyond Memory Modules: CXL Controllers, Switches, and Fabric Silicon #
The CXL ecosystem extends well beyond DRAM manufacturers.
A second group of companies focuses on the controllers, switches, and silicon infrastructure required to connect CXL devices into larger systems.
Astera Labs #
Astera Labs has developed CXL controller and connectivity products such as its Leo family.
These controllers are designed to sit between host CPUs and CXL memory infrastructure, making them important building blocks for memory expansion and pooling architectures.
CXL controllers are particularly valuable because they allow memory vendors and system manufacturers to integrate CXL without designing the entire protocol stack from scratch.
Marvell and Microchip #
Marvell and Microchip are also active in CXL connectivity and controller infrastructure.
Microchip’s SMC 2000 controller, for example, has been used in CXL memory products such as Micron’s CZ-series modules.
The broader ecosystem illustrates an important point: CXL is not just a memory standard. It is becoming an ecosystem spanning controllers, switches, firmware, memory devices, CPUs, operating systems, and management software.
Panmnesia and the CXL Fabric Layer #
Panmnesia is a Korean fabless semiconductor company associated with KAIST’s Computer Architecture and Memory Systems Laboratory (CAMELab).
Its work extends beyond CXL memory controllers toward fabric-level silicon, including its PANSWITCH architecture.
The company’s focus is particularly relevant to the CXL 3.x direction, where switching, routing, topology, and fabric management become increasingly important.
Architectures involving PBR and topologies such as mesh, dragonfly, and 3D torus require substantially more sophisticated silicon than a simple point-to-point Type 3 memory controller.
This creates a new opportunity for specialized CXL silicon vendors as the ecosystem moves from individual CXL devices toward large-scale fabrics.
📈 Why Memory Vendors Are Moving Into CXL #
The common motivation behind Samsung, SK hynix, and Micron’s CXL strategies is larger than simply selling another DRAM module.
CXL gives memory vendors an opportunity to participate at a higher level of the system architecture.
There are at least three important effects.
More Memory Capacity per Server #
CXL provides a way to add memory beyond the direct DDR channel limit.
That creates additional addressable memory capacity without requiring the CPU package and motherboard to expose an unlimited number of DDR channels.
More Value per Memory Module #
A conventional DRAM module is primarily differentiated by capacity, speed, density, and power characteristics.
A CXL device can add value through:
- Memory pooling
- Device management
- Error handling
- Fabric connectivity
- Compute acceleration
- Data-movement reduction
- Memory-tiering capabilities
That potentially moves the product from a commodity memory component toward a more sophisticated infrastructure device.
A Path Toward System-Level Memory Products #
The most strategically important change may be the transition from selling memory components to participating in memory infrastructure.
A pooled-memory appliance, for example, sits much closer to the system architecture than a conventional DIMM.
In this sense, CXL can be viewed as a way for the memory industry to expand its role from:
“How much DRAM can we put next to the CPU?”
to:
“How should memory be organized across the entire server or rack?”
That is a much larger architectural opportunity.
⚠️ The Remaining Challenges: Latency, Software, and Type 2 #
CXL’s architecture is compelling, but it does not eliminate the physical and software costs of moving memory farther away from the CPU.
The CXL Latency Tax #
CXL-attached memory is inherently slower than directly attached DDR.
Typical figures depend heavily on the platform and implementation, but a useful architectural comparison is:
- Direct DDR5: roughly 80–100 ns
- CXL Type 3 memory: roughly 170–300 ns in representative configurations
The exact values vary by CPU, controller, topology, queueing, and workload.
The important point is not the exact number. It is the hierarchy:
CXL memory has significantly higher access latency than local DDR.
Therefore, CXL is better understood as a memory tier than as a universal replacement for local DRAM.
A practical architecture can look like:
CPU → DDR → CXL memory → lower-cost or higher-capacity memory
The challenge is deciding which data belongs in which tier.
Software and Memory-Tiering Maturity #
From the operating system’s perspective, CXL memory introduces another NUMA-like resource with different performance characteristics.
The software stack therefore has to answer questions such as:
- Which pages should remain in local DDR?
- Which pages can move to CXL memory?
- When should hot pages migrate back?
- How should applications express memory-placement preferences?
- How should multiple hosts share pooled memory?
- How should latency and bandwidth differences influence scheduling?
Linux has been adding increasingly sophisticated CXL support, memory-management mechanisms, and page-placement capabilities.
However, optimal placement remains highly workload-dependent.
For deterministic workloads such as many LLM inference pipelines, application-aware placement can potentially outperform completely transparent operating-system tiering because the application already knows which data structures are latency-sensitive.
This makes CXL not only a hardware problem but also a systems-software problem.
The Type 2 Question #
The CXL specification defines Type 1, Type 2, and Type 3 devices, but commercial products remain heavily concentrated around Type 3.
Type 2 faces a difficult combination of hardware complexity and competitive pressure.
A Type 2 accelerator needs coherent access to host memory while also maintaining its own memory hierarchy. That creates significantly more demanding coherency and controller requirements.
At the same time, accelerator vendors already have specialized interconnect ecosystems designed around their own devices.
This leaves an important architectural question open:
Will CXL ultimately become a major accelerator interconnect, or will its primary role remain memory expansion, pooling, and fabric-based memory infrastructure?
The answer will depend on how CXL 3.x silicon, CPUs, accelerators, operating systems, and data-center fabrics evolve together.
🧭 Conclusion #
CXL exists because the traditional memory hierarchy leaves a gap between high-performance but capacity-limited DDR and highly scalable but non-coherent PCIe-attached devices.
Its architecture can be summarized through three protocols and three device types:
- CXL.io provides PCIe-like discovery, configuration, interrupts, and DMA.
- CXL.cache allows devices to cache host memory coherently.
- CXL.mem allows hosts to access device-attached memory.
- Type 1 devices provide coherent access to host memory without their own large memory space.
- Type 2 devices combine device-attached memory with coherent host-memory access.
- Type 3 devices provide dedicated memory expansion and currently dominate commercial CXL memory deployments.
The standard itself has evolved from direct-attached devices toward increasingly sophisticated memory fabrics:
- CXL 1.1: direct host-to-device attachment
- CXL 2.0: switching, resource management, and memory pooling
- CXL 3.x: larger fabrics, advanced routing, and multi-host shared-memory capabilities
The memory industry is responding accordingly.
Samsung, SK hynix, and Micron are developing Type 3 CXL memory modules, while other vendors are building controllers, switches, and fabric silicon around them. The ecosystem is gradually moving from “add another memory module” toward “treat memory as a dynamically managed system resource.”
But CXL is not free capacity.
Its higher latency means local DDR remains important for latency-sensitive data. Its software stack still has to mature around memory placement and tiering. And its more ambitious Type 2 and fabric-based architectures require significantly more sophisticated hardware and system software.
That is what makes CXL interesting in the AI era.
HBM addresses the need for more bandwidth close to the accelerator. CXL addresses a different problem: how to make substantially more memory available beyond the traditional CPU memory boundary while preserving useful system-level semantics.
The next question is therefore not simply what CXL is, but which workloads can actually benefit from CXL memory—particularly LLM serving scenarios involving KV-cache offload, memory pooling, and hot/warm/cold data tiering.