HomeCXL CourseDay 4
DAY 4 · PHASE 1 — FOUNDATIONS

CXL Device Types
Type 1, Type 2 & Type 3

By EcrioniX · Updated July 2026

Day 3 ended with a preview: a CXL device's "type" is simply which sub-protocols it implements. Day 4 makes that concrete. The three device types are the single most-referenced classification in all of CXL — every product, every spec discussion, every deployment is framed around them. By the end of this lesson you'll instantly know what a "Type 3 device" can and can't do.

The Rule: Type = Which Protocols You Speak

There's an elegant logic here. From Day 3, the three sub-protocols are CXL.io (mandatory), CXL.cache (device caches host memory), and CXL.mem (host accesses device memory). The three device types are just the three meaningful combinations of these:

Device Type = Combination of Sub-Protocols TYPE 1 accelerator, no local mem CXL.io CXL.cache e.g. SmartNIC TYPE 2 accelerator + local mem CXL.io CXL.cache CXL.mem e.g. GPU / FPGA TYPE 3 memory expander CXL.io CXL.mem e.g. DRAM expander

Type 1 — Accelerator With a Cache

TYPE 1

Coherent cache, no local memory

CXL.io + CXL.cache

A Type 1 device implements a fully coherent cache but has no host-managed device memory of its own. It uses coherency semantics (via CXL.cache) alongside PCIe-style DMA (via CXL.io). Because it has no local memory to expose, it only ever reaches into host memory — never the reverse.

Classic example: the SmartNIC. A network accelerator that needs to coherently touch host memory — inspecting packets, updating data structures, participating in host data with a consistent view — benefits enormously from a coherent cache, but has no reason to expose memory of its own back to the host. Type 1 is exactly that shape. These devices may also need to implement a custom ordering model on top of the coherent cache, depending on their workload.

Type 2 — Accelerator With Coherent Memory

TYPE 2

Coherent cache + host-managed device memory

CXL.io + CXL.cache + CXL.mem

A Type 2 device uses all three protocols. It has an (optional) coherent cache and its own local memory that can be mapped into the host's coherent address space. This is the only device type that operates in both directions — it caches host memory (CXL.cache) and exposes its own memory to the host (CXL.mem).

Classic examples: GPUs and FPGAs with local memory. These accelerators have large, high-bandwidth local memory (e.g. GDDR or HBM) that traditionally lived in a completely separate address space from the CPU, forcing explicit copies back and forth. As a Type 2 CXL device, that local memory can be partly mapped into the host's cacheable system memory, enabling unified memory access — the CPU and accelerator working on the same data without manual copying. This is one of the most powerful things CXL enables, and it's unique to Type 2.

Type 3 — The Memory Expander

TYPE 3

Host-managed device memory, no cache

CXL.io + CXL.mem

A Type 3 device has host-managed device memory but no coherent cache. Its entire purpose is to be memory the host reaches into via CXL.mem. It deliberately omits CXL.cache — a pure memory expander has nothing to cache from the host.

This is the workhorse of the CXL memory story. Type 3 devices provide memory capacity and bandwidth expansion — presenting additional DRAM or persistent memory to the host beyond what fits in the CPU's own DIMM slots. They can connect different memory types and even support multiple memory tiers attached to a single device. Every CXL memory-expansion, pooling, and disaggregation deployment (Days 11–13) is built on Type 3 devices, precisely because they're simple, cheap, and purpose-built to be memory.

Why omitting CXL.cache is a feature, not a limitation: leaving out coherent-caching logic makes a Type 3 device dramatically simpler and cheaper to build than a Type 2. Since a memory expander genuinely has nothing to cache from the host, that logic would be dead weight. This simplicity is a big part of why Type 3 memory expanders were the first CXL devices to reach real volume in the market.

Host-managed Device Memory (HDM)

The phrase "host-managed device memory" (HDM) keeps appearing — it's worth defining precisely. HDM is memory physically attached to a CXL device but mapped into the host's address space, so the host can access it with ordinary loads and stores. In its simplest form, the host is responsible for managing that memory's coherence.

Type 1: no HDMAn accelerator-only device with no memory to expose
Type 2: has HDMLocal accelerator memory mapped into the host's coherent space
Type 3: has HDMThe device's entire purpose — memory for the host to use

HDM is exactly what makes device-attached memory behave like part of the system's own memory rather than a separate island reachable only through explicit I/O. How the coherence of that HDM is actually managed — whether the host tracks everything, or the device takes a more active role, and the bias modes that govern it — is the entire subject of Day 5.

Quick Reference

TypeProtocolsCache?Device Memory?Typical Example
Type 1io + cacheYesNoSmartNIC, I/O accelerator
Type 2io + cache + memYes (optional)Yes (HDM)GPU, FPGA with local memory
Type 3io + memNoYes (HDM)DRAM / persistent-memory expander

🎯 Day 4 Key Takeaways

Frequently Asked Questions

What is a CXL Type 1 device?
A Type 1 device is an accelerator that implements a fully coherent cache but has no host-managed device memory of its own. It uses CXL.io and CXL.cache. Typical examples are SmartNICs and other I/O accelerators that benefit from coherently caching host memory alongside PCIe-style DMA transfers.
What is a CXL Type 2 device?
A Type 2 device is an accelerator that has both an (optional) coherent cache and its own host-managed device memory, using all three protocols — CXL.io, CXL.cache, and CXL.mem. GPUs and FPGAs with local memory are the classic examples, because they can both cache host memory and expose their own local memory into the host's coherent address space for unified memory access.
What is a CXL Type 3 device?
A Type 3 device is a memory expander. It has host-managed device memory but no coherent cache, using CXL.io and CXL.mem only. Its entire purpose is to present additional DRAM or persistent memory to the host for capacity and bandwidth expansion — it's the device type behind CXL memory expansion, pooling, and disaggregation.
What is Host-managed Device Memory (HDM)?
Host-managed Device Memory (HDM) is memory that is physically attached to a CXL device but mapped into the host's address space and, in the simplest mode, managed for coherence by the host. Type 2 and Type 3 devices have HDM; Type 1 devices do not. HDM is what lets device-attached memory behave like part of the system's own memory.
Why does a Type 3 memory expander not need CXL.cache?
A memory expander's only job is to be memory the host reaches into, which is exactly what CXL.mem provides. It has nothing to cache from the host, so CXL.cache would serve no purpose. Omitting it keeps memory expanders simple and cheap — a key reason Type 3 is the workhorse of CXL memory pooling and disaggregation.