作者：SmartDV Technologies
AI加速器、高性能计算（HPC）平台以及数据密集型系统正不断对处理器、内存与加速器设备之间的连接提出更高要求。随着系统架构日趋异构化、内存资源日益分布式化，高效传输数据只是挑战的一部分。系统还需要在日益复杂的互联拓扑结构中维持一致性、可靠性、安全性与可预测的行为。
Compute Express Link（CXL）4.0 对CXL架构进行了升级，以更高的带宽、更丰富的连接选项以及更强的内存可靠性等能力来应对这些需求。但对验证团队而言，这些升级也意味着需要验证的协议状态、设备配置、链路条件与系统级交互数量同步膨胀。
因此，有效的CXL 4.0验证不仅仅是确认在全新的最高速率条件下能够正常运行。团队还需要在不同设备类型下验证相应的CXL.io、CXL.cache、CXL.mem的行为，同时覆盖链路初始化、端口配置、内存事务、错误处理、安全性、向后兼容，以及日益复杂的互连结构（fabric）场景。
CXL在主处理器和诸如加速器和内存扩展器等设备之间提供缓存一致的连接。随着AI与HPC架构将CPU、加速器与大规模内存池组合在一起，并需要高效交换数据，这一能力变得愈发重要。
CXL 4.0在前几代引入的互连结构与内存能力基础上，将最高信号速率从64 GT/s提升到128 GT/s。该规范基于PCI Express 7.0技术，并保持对CXL 3.x所使用的256字节Flit架构的支持。
CXL联盟（Compute Express Link Consortium）公布了CXL 4.0的几项关键增强，包括：更高的带宽、捆绑化端口（Bundled Ports）、原生x2链路宽度，支持更多重定时器（retimer），以及增强的内存可靠性、可用性与可维护性（RAS）等能力。
这些能力可以帮助系统扩展带宽与内存连接，但每一种新配置也会带来新的行为，需要验证团队建模、施加激励（stimulate）、监控并覆盖。
基于PCIe 7.0构建，数据传输速率提升至128 GT/s
CXL 4.0借助PCIe 7.0的物理层基础而使数据传输速率达到128 GT/s。PCIe 7.0 延续了PCIe 6.0引入的PAM4信号与基于Flit的架构，同时将原始数据速率翻倍至128 GT/s。
PCI-SIG的PCIe 7.0文档将128 GT/s定义为最高原始比特率，在x16链路上可提供高达512 GB/s的双向带宽。
对CXL验证而言，这一PCIe基础意味着团队需要同时看清底层链路行为与运行在其上的CXL协议。链路协商、降宽运行、错误处理、Flit行为以及协议切换都应在各种受支持的配置下全面验证，而不是只验证标称链路状态。
SmartDV的PCIe验证IP（VIP）为覆盖至Gen 7的PCIe架构提供额外的验证支持。
捆绑化端口为验证增加了另一个新维度
CXL 4.0的重要新增特性之一是对捆绑化端口的支持。该能力允许主机与受支持的Type 1或Type 2加速器设备之间的多个CXL设备端口合并为一条捆绑在一起的连接，从而提升可用带宽。
这带来的验证需求远超“测试几条独立的链路”。
团队需要验证：流量是如何在参与捆绑的各端口之间进行分配、当各端口工作在不同条件下时设备如何表现、软件可见的设备行为如何与物理链路对应上，以及当流量在已捆绑的配置中移动时，排序与协议要求是否依然正确。
错误场景尤为重要。验证应核查：当参与捆绑的某条链路发生错误、重训练事件、复位或其他异常，而捆绑连接中其他部分仍有流量在传输时，系统会如何应对？
CXL.io、CXL.cache与CXL.mem必须协同工作
CXL不是单一事务协议。根据设备与系统架构的不同，验证团队可能需要验证以下三者之间的交互：
·CXL.io：负责设备发现、配置、中断与I/O事务
·CXL.cache：负责设备访问主内存时的缓存一致性
·CXL.mem：负责主机访问设备自带的内存
挑战并非只是独立验证每一层协议。设备可能在某一条协议路径上完全正确，但当多种事务类型、缓存状态、内存操作、复位与错误条件交织在一起时仍然会失效。
因此，验证环境需要具备足够的协议感知能力，以评估设备的整体行为，而不是检查一条条孤立的事务流。
内存RAS需要有意识地开展错误测试
CXL 4.0扩展了内存的可靠性、可用性和可维护性（Reliability, Availability and Serviceability，RAS）能力。在以内存为中心的AI和HPC系统中，这些特性至关重要，因为大规模内存资源可能被多个组件共享或访问，故障必须被正确地检测到、上报并管理。
验证团队应有针对性地触发错误上报与维护行为，而不是只验证正确的内存事务能正常工作。
这包括：在不同内存与设备条件下，检查错误通知、毒化（poisoned）数据行为、复位处理、维护操作与恢复路径。
在高要求AI与HPC工作负载下验证内存行为的重要性，也与《面向AI、HPC与边缘计算的HBM与LPDDR6验证挑战》一文中讨论的更广泛议题相关联。
向后兼容扩大了测试矩阵
CXL 4.0保持与前几代CXL的向后兼容。这有助于保护既有的系统投资，但也扩大了验证矩阵。
CXL 4.0实现可能需要在不同链路速率、设备代际、协议能力以及协商出的特性组合下都能正确工作。
因此，如果只测试CXL 4.0对CXL 4.0的配置，对于那些计划支持老版本设备的设计来说是不够的。验证应覆盖产品实际宣称支持的配置组合，并确认可选或不支持的特性能被正确协商与处理。
验证主机端与设备端角色
CXL验证应反映实际要实现的拓扑。根据目标设计，验证环境可能需要去建立主机模型，以及Type 1、Type 2或Type 3类别设备。
每种配置都会引入CXL.io、CXL.cache、CXL.mem行为的不同组合，因此，测试计划应从目标设备角色出发，而不是把同一个通用CXL流量模型应用到每一个被测设备（DUT）上。
组合式测试特性
对每个特性逐一测试是必要的，但不足以使验证收敛。
团队应将事务类型、链路条件、设备状态、内存活动、功耗切换、错误与受支持的安全特性组合起来。这些组合通常是协议假设的交汇点，并可使最难发现的错误得以显现。
跨协议栈注入错误
负向测试应从一开始就被纳入验证计划。畸形事务、链路错误、协议违规、毒化数据、复位序列、超时条件以及其他故障场景有助于判断DUT在“正常路径”之外是否仍能正确表现。
错误注入也是测试RAS功能的重要手段，需要确认故障被上报到了正确的层级，而不会在系统其他部分引发失控行为。
跨配置跟踪功能覆盖率
覆盖率不应只统计“某个协议消息是否出现过”。有价值的交叉覆盖可以包括：设备类型、事务类型、链路速率、链路宽度、端口配置、内存状态、错误条件与恢复行为。
一个可复用的验证环境能让这些组合随着设计演进而更容易扩展。SmartDV在《可复用的验证IP如何支撑可扩展SoC验证》一文中，讨论了这种更宏观的方法论。
SmartDV为AI、HPC、数据中心与基于芯粒（Chiplet）的系统所使用的各种高速互联提供设计IP与验证IP。
SmartDV的CXL 4.0 VIP支持主机端与设备端的验证，覆盖CXL.io、CXL.cache与CXL.mem，包括Type 1、Type 2与Type 3设备配置。该VIP通过PCIe 7.0物理层基础支持最高128 GT/s的信号速率，并提供捆绑端口验证、内存RAS行为、安全能力、错误注入、功能覆盖率以及可配置的验证基础设施。
SmartDV当前的产品组合还包括CXL 4.0控制器IP，为开发基于CXL的SoC与设备团队提供配套的设计IP选项。
面向异构与基于芯粒的架构，SmartDV还提供CXL到UCIe桥接IP。关于芯粒间（die-to-die）验证的更多背景，可参见《为什么UCIe验证对基于芯粒的SoC设计至关重要》。
CXL 4.0将最高信号速率提升到128 GT/s，同时新增了面向AI、HPC与数据中心架构的增强的连接性、内存可靠性与系统可扩展性的能力。
对验证团队而言，挑战远不止“测试更快的链路”。CXL.io、CXL.cache与CXL.mem的行为必须跨多种设备类型、链路配置、端口排布、内存条件、错误场景与受支持代际进行验证。
一套全面的CXL 4.0验证策略应结合具备协议感知能力的激励与监控、可配置的主机与设备模型、错误注入、断言与检查、功能覆盖率，以及将各项特性组合起来测试的系统级场景，而不是孤立地逐项测试各个功能。