What Is CXL?

Module 1 was a question, asked from six directions. This chapter is the beginning of the answer.

Chapter 1.7 ended with a specification written from the pressures rather than from a product: keep what the I/O model does well, add coherent device caching of host memory and device-attached memory that is part of system memory, and do it over infrastructure the ecosystem already has. This chapter names what was built to that specification and defines it carefully enough to be worth trusting.

1. The One-Sentence Model

CXL is a cache-coherent interconnect that runs over PCIe's physical infrastructure and carries three protocols on one link: a PCIe-derived protocol for discovery, configuration and bulk I/O; a protocol letting a device coherently cache host memory; and a protocol letting a host access device-attached memory with memory semantics. A device implements the base protocol and whichever of the other two its purpose requires.

Everything in Module 2 elaborates that sentence. Nothing in it is new pressure — every clause answers something Module 1 established.

2. What This Chapter Owns

This is an overview, and its job is a map rather than a manual.

Deliberately not published here: transactions, messages, opcodes, flit formats, channel structure, coherence states, or version-by-version feature matrices. An overview that smuggles those in is not an overview.

3. The Definition

The CXL Consortium defines CXL as "an industry-supported Cache-Coherent Interconnect for Processors, Memory Expansion and Accelerators."

That sentence is doing precise work, and it is worth unpacking clause by clause because each one maps to a chapter of Module 1.

"Cache-Coherent" — the mechanism Chapter 1.7 built and priced. It is first in the definition because it is the property that distinguishes CXL from the attach model Chapter 1.6 examined.

"Interconnect" — not a memory bus and not a replacement for on-package interfaces. It connects things that are already separate.

"for Processors, Memory Expansion and Accelerators" — three use cases, and they are not the same use case. Memory expansion and accelerator attach have different requirements, which is exactly why the architecture carries more than one protocol.

Versions, stated with their dates

Version-specific claims are labelled here and then largely left alone; an overview polluted with revision minutiae teaches worse than one that does not.

CXL 4.0 was released on 18 November 2025. Per the Consortium's own 4.0 white paper, it doubles the data rate to 128 GT/s while preserving PAM4 signalling and the flit-based structure with FEC and CRC introduced in CXL 3.0, introduces Bundled Ports — aggregating multiple physical ports into one logical entity — and maintains full backward compatibility with CXL 3.x, 2.0, 1.1 and 1.0.

That backward-compatibility clause is not a footnote. It is the same strategic decision Section 4 is about.

4. What CXL Reuses, and Why That Was Decisive

CXL runs over PCIe's physical infrastructure. That is a technical fact with an enormous strategic consequence, and understanding it is most of understanding why CXL succeeded where a clean-sheet interconnect would not have.

Chapter 1.6 §8 tabulated Module 1's requirements and found that roughly half were already solved: discovery, configuration, bulk movement, completion signalling. A new interconnect would have had to re-solve all of them to deliver a capability that is additive.

Reuse buys three things that are hard to obtain any other way:

The physical layer and its engineering. Signalling at these rates represents an investment that is not worth duplicating, and CXL 4.0's own description — preserving PAM4 and the flit structure while doubling the rate — is that reuse continuing across generations.

The discovery and configuration model. A CXL device is discoverable and configurable by mechanisms the ecosystem already implements, which is why software support was tractable at all.

A fallback. A device can behave as an ordinary endpoint on a host that does not support the newer capabilities. Without that, adoption would require the entire installed base to move at once, which is another way of saying it would not happen.

5. The Three Protocols

One link carries three protocols. They differ in what relationship they express and in which direction the memory relationship runs — and that second point is where most confusion lives.

CXL.io is the base protocol and it is required of every device. It is PCIe-derived and it carries the relationships Chapter 1.6 §3 praised: discovery, configuration, register access, interrupts, and bulk DMA. Consortium material describes it as the protocol used to manage and operate CXL devices, providing the backbone for the operation of the other protocols. Nothing about the device works before CXL.io works.

CXL.cache lets a device coherently cache host memory. The device becomes a participant in coherence over host-attached memory — able to hold copies whose state the protocol tracks, rather than snapshots software must manage. This is Chapter 1.7 applied: the flush-and-invalidate discipline stops being the driver's job.

CXL.mem lets a host access device-attached memory with memory semantics. Memory physically attached to a device is presented to the host as memory rather than as a device resource behind a mapped window — the gap Chapter 1.6 §5 identified as its third unanswered question.

The direction table is the thing to memorise, because reversing it is the single most common error:

CXL.cache is the device reaching into host memory. CXL.mem is the host reaching into device memory. They are not two names for coherence; they point in opposite directions and serve different use cases.

6. Device Classes — a Map

Because the two optional protocols are independent, a device's capability set determines what kind of device it is. The industry names three classes.

Read that against Module 1 and it stops being a list to memorise.

Type 1 is Chapter 1.4's compute peer: it needs to work on host data coherently, and it has no memory it wants the host to see. A smart network device that must operate on host structures is the canonical shape.

Type 2 is Chapter 1.5's accelerator: it has substantial local memory and it works on host data. It needs both optional protocols because it has both relationships.

Type 3 is Chapter 1.1's capacity problem: a device whose purpose is to hold memory. It does not cache host memory — it has no computation that would want to — so it implements CXL.mem and not CXL.cache.

Notice what the table makes obvious and what the misconception in Section 15 gets wrong: Type 3 devices do not implement CXL.cache, and CXL.io appears in every row. Module 10 covers each class properly; this is the map.

7. What Multiplexing Costs a Design

Carrying three protocols on one link is an architectural decision with consequences that show up in RTL, and Sections 8 to 10 make them concrete.

Three consequences matter at overview level:

Capability must be discovered. A host cannot assume what a device implements — it must ask, and route accordingly. That is why "every CXL device supports all three protocols" is a misconception rather than a simplification.

The classes contend. One physical link, several logical traffic classes with different latency sensitivities. Memory traffic and bulk I/O traffic want very different things from an arbiter.

The resources should be separate. If all classes draw from one pool of outstanding-request credits, a burst of one starves the others. Section 10 measures exactly that.

8. RTL — What Protocol Multiplexing Implies

RTL 1 — Capability

// A device capability register: which logical protocol classes this device
// implements. Conceptual only -- this is not a CXL capability structure and
// models no specification register, field or encoding.
//
// The architectural point is that capability is DISCOVERED, not assumed.
module capability_reg (
  input  logic       clk,
  input  logic       rst_n,
  input  logic       cfg_wr,
  input  logic [2:0] cfg_wdata,        // {mem, cache, io}
  output logic       cap_io,
  output logic       cap_cache,
  output logic       cap_mem,
  output logic [1:0] device_class,
  output logic       illegal_cap_err
);
  logic [2:0] cap_q;
 
  assign cap_io    = cap_q[0];
  assign cap_cache = cap_q[1];
  assign cap_mem   = cap_q[2];
 
  // A coarse classification derived from the capability bits alone. This is a
  // teaching convenience, not a specification definition.
  //   01 : io + cache        02 : io + mem        03 : io + cache + mem
  always_comb begin
    case ({cap_mem, cap_cache})
      2'b01:   device_class = 2'b01;
      2'b10:   device_class = 2'b10;
      2'b11:   device_class = 2'b11;
      default: device_class = 2'b00;
    endcase
  end
 
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      cap_q <= 3'b001;                 // io only, until configured
      illegal_cap_err <= 1'b0;
    end else if (cfg_wr) begin
      // The base class is required: a device advertising the optional classes
      // without it is misconfigured.
      if (!cfg_wdata[0]) illegal_cap_err <= 1'b1;
      else               cap_q <= cfg_wdata;
    end
  end
endmodule

Contract. The base class is mandatory; a configuration that omits it is rejected and latched rather than applied. Reset leaves the device advertising the base class only, which is the safe default — a device that has not been configured must not claim capabilities it may not have.

RTL 2 — Routing by Protocol Class

// Routes an incoming request to one of three logical protocol classes, and
// refuses classes the attached device did not advertise.
//
// This is NOT CXL packet decode. What it models is the ARCHITECTURAL
// consequence of carrying several protocol classes on one link: the classes
// have different destinations inside the device, different resources, and a
// device need not implement all of them.
module proto_class_router (
  input  logic       clk,
  input  logic       rst_n,
  input  logic       req_valid,
  input  logic [1:0] req_class,        // 00 io, 01 cache, 10 mem
  input  logic       cap_io,
  input  logic       cap_cache,
  input  logic       cap_mem,
  output logic       to_io,
  output logic       to_cache,
  output logic       to_mem,
  output logic       unsupported_class_err
);
  localparam logic [1:0] CLS_IO = 2'b00, CLS_CACHE = 2'b01, CLS_MEM = 2'b10;
  logic sel_io, sel_cache, sel_mem;
 
  assign sel_io    = req_valid && (req_class == CLS_IO);
  assign sel_cache = req_valid && (req_class == CLS_CACHE);
  assign sel_mem   = req_valid && (req_class == CLS_MEM);
 
  // A request is delivered only if the device advertised that class. Routing a
  // class the device does not implement is a configuration error, not traffic.
  assign to_io    = sel_io    && cap_io;
  assign to_cache = sel_cache && cap_cache;
  assign to_mem   = sel_mem   && cap_mem;
 
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) unsupported_class_err <= 1'b0;
    else if ((sel_io    && !cap_io)
          || (sel_cache && !cap_cache)
          || (sel_mem   && !cap_mem)) unsupported_class_err <= 1'b1;
  end
endmodule

Simulation evidence — the device-class table, produced by one router. The same routing logic sees three capability profiles in turn. Verbatim from the Icarus run:

=== EXP1: three device profiles, same router ===
  io + cache (caching device)        caps io=1 cache=1 mem=0  class=01
    io request             to_io=1 to_cache=0 to_mem=0
    cache request          to_io=0 to_cache=1 to_mem=0
    mem request            to_io=0 to_cache=0 to_mem=0
  io + cache + mem                   caps io=1 cache=1 mem=1  class=11
    cache request          to_io=0 to_cache=1 to_mem=0
    mem request            to_io=0 to_cache=0 to_mem=1
  io + mem (memory expander)         caps io=1 cache=0 mem=1  class=10
    cache request          to_io=0 to_cache=0 to_mem=0
    mem request            to_io=0 to_cache=0 to_mem=1
  unsupported_class_err=1

That is Section 6's table, executed. The first profile refuses memory-class requests; the third refuses cache-class requests; the middle one accepts both. The device classes are not a taxonomy somebody imposed — they fall out of which optional protocols a device implements, and a host that routes without checking gets the error flag.

=== EXP2: a device that omits the base class is misconfigured ===
  cache + mem, no io    illegal_cap_err=1  (caps unchanged: io=1 cache=0 mem=1)

RTL 3 — Independent Resources Per Class

// Independent outstanding-request budgets per protocol class, sharing one
// physical link. Conceptual: no CXL arbitration, flit or channel behaviour is
// modelled.
//
// The point is a system property that matters as soon as one link carries
// several classes: if the classes share ONE credit pool, a burst of one class
// starves the others. Separate budgets bound that interference.
module class_resources #(
  parameter int unsigned MAX_IO    = 4,
  parameter int unsigned MAX_CACHE = 4,
  parameter int unsigned MAX_MEM   = 8
) (
  input  logic clk,
  input  logic rst_n,
  input  logic iss_io,    input logic cpl_io,
  input  logic iss_cache, input logic cpl_cache,
  input  logic iss_mem,   input logic cpl_mem,
  output logic can_io,
  output logic can_cache,
  output logic can_mem,
  output logic [7:0] os_io_q,
  output logic [7:0] os_cache_q,
  output logic [7:0] os_mem_q,
  output logic       overflow_err
);
  assign can_io    = (os_io_q    < 8'(MAX_IO));
  assign can_cache = (os_cache_q < 8'(MAX_CACHE));
  assign can_mem   = (os_mem_q   < 8'(MAX_MEM));
 
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      os_io_q <= '0; os_cache_q <= '0; os_mem_q <= '0; overflow_err <= 1'b0;
    end else begin
      if (os_io_q > 8'(MAX_IO) || os_cache_q > 8'(MAX_CACHE) || os_mem_q > 8'(MAX_MEM))
        overflow_err <= 1'b1;
      case ({iss_io && can_io, cpl_io})
        2'b10: os_io_q <= os_io_q + 1'b1;
        2'b01: os_io_q <= os_io_q - 1'b1;
        default: os_io_q <= os_io_q;
      endcase
      case ({iss_cache && can_cache, cpl_cache})
        2'b10: os_cache_q <= os_cache_q + 1'b1;
        2'b01: os_cache_q <= os_cache_q - 1'b1;
        default: os_cache_q <= os_cache_q;
      endcase
      case ({iss_mem && can_mem, cpl_mem})
        2'b10: os_mem_q <= os_mem_q + 1'b1;
        2'b01: os_mem_q <= os_mem_q - 1'b1;
        default: os_mem_q <= os_mem_q;
      endcase
    end
  end
endmodule

Simulation evidence — isolation between classes. One class is saturated and the others are checked. Verbatim:

=== EXP3: independent per-class budgets on one link ===
  cache class saturated    : os_cache=4 can_cache=0
  other classes unaffected : os_mem=0 can_mem=1  os_io=0 can_io=1
  mem class issues anyway  : os_mem=3 can_mem=1

The cache class is fully subscribed and cannot issue. The memory class issues three requests regardless. With a single shared pool, those three requests would not have happened — and a memory access blocked by a burst of unrelated coherence traffic is a quality-of-service failure that looks like a memory-system problem.

This is Chapter 1.4's shared-resource argument arriving one level down: several classes converge on one link, and separating their budgets is how one class's burst is prevented from becoming another's latency.

9. Assertions

Bind-ready properties. Icarus does not support concurrent assertions, so these were not executed; the table gives the procedural check that verified each.

// P1 — a request is never delivered to a protocol class the device does not
// implement. Configuration and routing must agree.
a_route_only_supported: assert property (@(posedge clk) disable iff (!rst_n)
  (to_cache |-> cap_cache) && (to_mem |-> cap_mem) && (to_io |-> cap_io));
 
// P2 — exactly one class is selected for any valid request.
a_one_class: assert property (@(posedge clk) disable iff (!rst_n)
  req_valid |-> $onehot0({to_io, to_cache, to_mem}));
 
// P3 — the base class is always advertised. A device that loses it has been
// misconfigured, and every other capability depends on it.
a_base_always_present: assert property (@(posedge clk) disable iff (!rst_n)
  cap_io);
 
// P4 — per-class budgets are never exceeded. Violating this means outstanding
// state exists that the device cannot track.
a_budgets_bounded: assert property (@(posedge clk) disable iff (!rst_n)
  (os_io_q <= MAX_IO) && (os_cache_q <= MAX_CACHE) && (os_mem_q <= MAX_MEM));
 
// P5 — saturating one class does not block another. The isolation property,
// and the reason the budgets are separate at all.
a_class_isolation: assert property (@(posedge clk) disable iff (!rst_n)
  !can_cache |-> (can_mem || (os_mem_q >= MAX_MEM)));

10. Debug Lab

// Route by class. The device is a CXL device, so it handles all of them.
assign to_cache = req_valid && (req_class == CLS_CACHE);   // no capability term

  io + mem (memory expander)   caps io=1 cache=0 mem=1  class=10
    cache request              to_io=0 to_cache=0 to_mem=0
  unsupported_class_err=1

assign to_cache = req_valid && (req_class == CLS_CACHE) && cap_cache;

// One outstanding-request budget for the link.
assign can_issue = (outstanding_q < MAX_OUTSTANDING);
assign can_io = can_issue;  assign can_cache = can_issue;  assign can_mem = can_issue;

  cache class saturated    : os_cache=4 can_cache=0
  other classes unaffected : os_mem=0 can_mem=1  os_io=0 can_io=1
  mem class issues anyway  : os_mem=3 can_mem=1

// Accept whatever capability configuration is written.
if (cfg_wr) cap_q <= cfg_wdata;        // no validity check

  cache + mem, no io    illegal_cap_err=1  (caps unchanged: io=1 cache=0 mem=1)

if (cfg_wr) begin
  if (!cfg_wdata[0]) illegal_cap_err <= 1'b1;   // base class is mandatory
  else               cap_q <= cfg_wdata;
end

11. Where CXL Matters, and the Trade

The use cases follow from the protocols, and each traces to a Module 1 chapter.

And the trade, stated without hype because the hype is what makes this topic hard to learn:

Greater flexibility and semantic richness, in exchange for protocol, latency, state, verification and system-management complexity.

Every clause on the right is real. Chapter 1.7 §7 priced the coherence half; Section 8 here shows the multiplexing half in three small modules that already need capability discovery, class routing and per-class resources. A production controller is far larger, and the system-management burden — configuring, partitioning, and administering memory that is no longer behind one socket — is a category of work that did not previously exist.

12. What CXL Is Not

13. How This Appears in Real Engineering

System architect

The first question is which class of device a given problem needs, because that decides the protocol set and therefore the complexity. A capacity shortfall points at a memory device; a compute peer working on host structures points at a caching device; both together point at the full set. Getting this wrong means paying for protocol participation a device does not need.

SoC and controller architect

Protocol multiplexing is the defining structural decision: how classes share the link, how their resources are separated, where arbitration happens, and what the latency budget is for each class. Section 8's three modules are the smallest honest sketch of that; the specification governs the rest.

RTL engineer

Capability structures, class routing, per-class outstanding-request tracking and arbitration — and the discipline that each class needs its own budget, because a shared pool is simpler, functionally correct, and a quality-of-service defect.

Verification engineer

Protocol multiplexing multiplies the state space rather than adding to it: each class has its own state, and the interesting failures are in the interactions and in the capability permutations. The distinctive requirement is mixed-traffic regressions and testing against every capability profile, since single-class tests cannot find cross-class interference and a bring-up board is one profile out of several.

Firmware and system software engineer

Enumeration, capability discovery, and memory configuration for memory that is no longer behind one socket. The new obligation is that the memory map is a decision rather than a given, and that a device's capabilities must be read rather than assumed.

Datacentre architect

Memory expansion and pooling change the unit of purchase — Chapter 1.1's stranding argument becomes addressable rather than structural. The new work is administrative: partitioning, allocation policy, and failure domains for memory that several hosts may reach.

14. Interview Reasoning

15. Summary

CXL is a cache-coherent interconnect that uses PCIe's physical infrastructure and carries three protocols on one link. The Consortium defines it as "an industry-supported Cache-Coherent Interconnect for Processors, Memory Expansion and Accelerators" — and the three named use cases are why one protocol was never going to be enough.

The base protocol is required and PCIe-derived, carrying discovery, configuration, register access and bulk DMA — everything Chapter 1.6 found the I/O model already did well. CXL.cache lets a device coherently cache host memory. CXL.mem lets a host access device-attached memory with memory semantics. The two optional protocols point in opposite directions, and which of them a device implements is what its class means: io plus cache, io plus mem, or all three.

The reuse was the strategic decision. Roughly half of what coherent attach needs was already solved, so building on the existing physical and discovery infrastructure — rather than replacing it — is what made adoption possible, and what lets a device fall back to being an ordinary endpoint on a host without the newer support. CXL 4.0, released 18 November 2025, continues that pattern on PCIe 7.0 at 128 GT/s while remaining backward compatible with every earlier revision.

Carrying several protocols on one link is not free, and the three simulated modules show the smallest form of the cost: capability must be discovered rather than assumed, requests must be routed by class and refused where unsupported, and the classes need separate resources — measured, with the coherence class saturated, the memory class still issued three requests where a shared pool would have issued none.

The honest trade: greater flexibility and semantic richness, in exchange for protocol, latency, state, verification and system-management complexity. Every clause on the right is real, and a reader who carries only the left half will be surprised by a project.

16. What Comes Next

Module 2 develops the map this chapter drew. Chapter 2.2 covers the CXL Consortium and how the specification is produced. Chapter 2.3 walks the revisions and what each added. Chapter 2.4 examines the relationship to PCIe in the detail this overview deliberately compressed. Chapter 2.5 states the architectural goals the whole design serves.

After that, Module 3 opens the architecture proper — host, device and fabric — and Module 4 takes the stack layer by layer. The three protocols named here get a module each in Modules 7 to 9, and the device classes get Module 10.

For adjacent material now: the PCIe track owns the foundation CXL reuses, PCIe vs CXL compares the two contracts from the PCIe side, and the UCIe track covers CXL over UCIe for the in-package case. The full path is on the CXL tutorials index.