Keeping Pace with CXL Specification Revisions

By Ettore Giliberti

September 4, 2025

As the Compute Express Link® (CXL®) specification rapidly evolves, so too must the tools and infrastructure used to verify designs built around it. Maintaining verification IP (VIP) that keeps pace with new specification revisions is no small task, particularly when dealing with major version shifts like the transition from CXL 2.0 to 3.0.

At SmartDV Technologies, we’ve seen firsthand how important it is for VIP to adapt quickly while preserving robustness, accuracy, and coverage across revisions. This post explores the technical challenges and engineering considerations that come with such updates, drawing on real examples from recent work on CXL 3.0 support.

The Need for Constant Evolution

Pre-silicon verification of CXL-based hardware is complex and demanding. VIPs must accurately model both the host and device sides of the interconnect and provide reliable protocol checkers to validate system behaviour.

A solid VIP infrastructure is essential for building reliable verification IP and enabling rapid updates as specifications evolve. The two diagrams below illustrate the high-level architecture of the SmartDV CXL VIP.

Figure 1: SmartDV CXL VIP BFM

Figure 2: SmartDV CXL VIP Block Diagram

As CXL specifications are updated, VIPs must be revised accordingly, often under tight timelines.

The shift from CXL 2.0 to 3.0, for example, introduces several significant changes that require substantial updates to the VIP, both in terms of functionality and protocol handling.

Key Changes and Implementation Challenges

Support for 256B Data Flits

In CXL 3.0, protocol flits can now carry up to 256 bytes of data, up from 68B in CXL 2.0. This introduces a few architectural changes:

• Credit values (LLCRD), previously transmitted in a separate flit, are now embedded directly within the protocol flit using a 2-byte field (bytes 240–241).
• Before transmitting a non-empty protocol flit, the initial credit values for requests, responses, and data (with flit type cache/mem) need to be advertised in the protocol flit.
• The advertised credit values reflect the current availability of the receiver buffer.

Flit Format Enhancements and Cyclic Redundancy Check (CRC) Handling

CXL 3.0 introduces three types of flit formats:

• Standard 256B
• Latency-Optimized Flits
• PBR Flits

Latency-optimized flits require the CRC to be calculated differently. The first 8 slots (122B) need one CRC placed in slot 7 (6B), while the remaining slots (116B) require a separate CRC. This dual CRC structure demands precise implementation and verification within the VIP.

Additionally, the ARB/MUX Link Management Packet (ALMP) flit now includes CRC and Forward Error Correction (FEC), eliminating the need to replicate data for integrity purposes, as required in CXL 2.0. While this change simplifies the physical layer representation, it shifts the responsibility of CRC/FEC management to a new location in the stack.

Memory Coherency and Back-Invalidate Handling

CXL 3.0 improves memory protocol behaviour with support for M2S Back-Invalidate Snoop (BISnp) channel. In CXL 2.0, Device-to-Host (D2H) requests could block while waiting for M2S progress, limiting architectural choices such as inclusive Snoop Filters. By resolving coherence through BISnp instead of the CXL.cache channel, CXL 3.0 enables more flexible and efficient memory architectures.

Retry Mechanisms Moved to the Physical Layer

One of the most significant changes in CXL 3.0 is the relocation of retry mechanisms from the link layer to the physical layer. In CXL 2.0, retry was managed using local and remote state transitions in the link layer. Now, in CXL 3.0, retry is handled through a flit sequence number handshake system.

Key features of the new retry mechanism include:

• Transmit-side retry buffers that store all protocol flits (CXL.io, CXL.cache/mem, ALMP).
• Acknowledgment-driven buffer clearance based on sequence numbers.
• Selective NACK (Negative Acknowledgement) Replay: The ability to retransmit specific flits instead of replaying all unacknowledged ones.
• Standard Replay: Full replay of all flits pending acknowledgment.

Final Thoughts

Developing and updating a CXL Universal Verification Methodology (UVM) VIP to support new specification revisions is no small task. Even with a robust, reusable VIP infrastructure, deep domain knowledge and significant engineering efforts are essential. To give a sense of the complexity and timeline involved, estimated engineering efforts for major CXL 3.0 updates are:

• Relocating retry mechanism to physical layer: ~4 weeks
• Adding support for 256B flits and related protocol changes: ~5 weeks

These estimates assume the tasks are being undertaken by experienced engineers with strong familiarity with the existing VIP and CXL protocol stack.

Building a scalable, adaptable CXL VIP isn’t just about coding; it’s about anticipating specification changes and structuring the architecture to accommodate future growth.

CXL member companies, like SmartDV Technologies, with extensive experience in both design and verification IP, support engineering teams with high-quality, specification-compliant VIPs for advanced protocols like CXL. As the standard continues to evolve, SmartDV remains committed to helping ensure CXL specification revisions and adapted implementations help end users stay ahead of the curve.

Related Links

• SmartDV Technologies
• CXL Verification IP
• Request Data Sheet
• Request Evaluation