【導讀】AI加速器、高性能計算（HPC）平臺以及數據密集型系統正不斷對處理器、內存與加速器設備之間的連接提出更高要求。隨著系統架構日趨異構化、內存資源日益分布式化，高效傳輸數據只是挑戰的一部分。系統還需要在日益復雜的互聯拓撲結構中維持一致性、可靠性、安全性與可預測的行為。
Compute Express Link（CXL）4.0 對CXL架構進行了升級，以更高的帶寬、更豐富的連接選項以及更強的內存可靠性等能力來應對這些需求。但對驗證團隊而言，這些升級也意味著需要驗證的協議狀態、設備配置、鏈路條件與系統級交互數量同步膨脹。
因此，有效的CXL 4.0驗證不僅僅是確認在全新的最高速率條件下能夠正常運行。團隊還需要在不同設備類型下驗證相應的CXL.io、CXL.cache、CXL.mem的行為，同時覆蓋鏈路初始化、端口配置、內存事務、錯誤處理、安全性、向后兼容，以及日益復雜的互連結構（fabric）場景。
為什么CXL 4.0對AI與HPC系統很重要？
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）、監控并覆蓋。
CXL 4.0驗證中的關鍵技術挑戰
基于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 4.0驗證
驗證主機端與設備端角色
CXL驗證應反映實際要實現的拓撲。根據目標設計，驗證環境可能需要去建立主機模型，以及Type 1、Type 2或Type 3類別設備。
每種配置都會引入CXL.io、CXL.cache、CXL.mem行為的不同組合，因此，測試計劃應從目標設備角色出發，而不是把同一個通用CXL流量模型應用到每一個被測設備（DUT）上。
組合式測試特性
對每個特性逐一測試是必要的，但不足以使驗證收斂。
團隊應將事務類型、鏈路條件、設備狀態、內存活動、功耗切換、錯誤與受支持的安全特性組合起來。這些組合通常是協議假設的交匯點，并可使最難發現的錯誤得以顯現。
跨協議棧注入錯誤
負向測試應從一開始就被納入驗證計劃。畸形事務、鏈路錯誤、協議違規、毒化數據、復位序列、超時條件以及其他故障場景有助于判斷DUT在“正常路徑”之外是否仍能正確表現。
錯誤注入也是測試RAS功能的重要手段，需要確認故障被上報到了正確的層級，而不會在系統其他部分引發失控行為。
跨配置跟蹤功能覆蓋率
覆蓋率不應只統計“某個協議消息是否出現過”。有價值的交叉覆蓋可以包括：設備類型、事務類型、鏈路速率、鏈路寬度、端口配置、內存狀態、錯誤條件與恢復行為。
一個可復用的驗證環境能讓這些組合隨著設計演進而更容易擴展。SmartDV在《可復用的驗證IP如何支撐可擴展SoC驗證》一文中，討論了這種更宏觀的方法論。
SmartDV相關的CXL產品與資源
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驗證策略應結合具備協議感知能力的激勵與監控、可配置的主機與設備模型、錯誤注入、斷言與檢查、功能覆蓋率，以及將各項特性組合起來測試的系統級場景，而不是孤立地逐項測試各個功能。
