一、前言：CXL 是 SSD 驗證的新戰場
隨著人工智慧（AI）、高效能運算（HPC）與大規模資料中心對運算能力的渴求呈現爆炸性增長，「記憶體牆」（Memory Wall）問題日益凸顯，成為制約系統效能提升的關鍵瓶頸 [1]。記憶體牆是指處理器速度的增長遠遠超過記憶體頻寬與存取速度的提升，導致強大的運算核心常常處於等待資料的閒置狀態。為了解決此一困境，Compute Express Link（CXL）技術應運而生，它作為一個開放的業界標準，旨在打破中央處理器（CPU）、記憶體（Memory）與儲存裝置（Storage）之間的傳統界線，提供一個高頻寬、低延遲的互連通道 [2]。
二、CXL SSD 的三大類型與架構解構
CXL 標準定義了三種主要的裝置類型，每種類型都針對不同的應用場景，並利用 CXL.io、CXL.cache 和 CXL.mem 這三種協定來實現其功能。
**Type 1 裝置（Cache Device）**主要用於需要快取加速的裝置，如智慧網卡（SmartNICs）。這類裝置可以快取主機記憶體中的資料，實現一致性存取，但自身不帶有可供主機直接管理的記憶體。它主要使用 CXL.io 和 CXL.cache 協定，透過快取機制來提升特定應用的效能 [3]。
**Type 2 裝置（Accelerator）**主要用於加速器，如 GPU 或 AI 晶片。這類裝置不僅可以快取主機記憶體，自身也帶有高頻寬記憶體（如 HBM），可供主機和其他裝置存取。它同時使用 CXL.io、CXL.cache 和 CXL.mem 三種協定，實現主機與裝置記憶體空間的統一與一致性，為異質運算提供了強大的支援 [3]。
**Type 3 裝置（Memory Expander / CXL SSD）**主要用於記憶體擴充和持久性儲存。這類裝置為系統提供額外的記憶體容量，主機 CPU 可以透過 CXL.mem 協定以記憶體語意（Load/Store）直接存取。CXL SSD 正是此類型的典型應用，它將 NAND Flash 等非揮發性儲存介質呈現為位元組可定址的記憶體空間 [3]。
本文將重點聚焦於 Type 3 CXL SSD，其設計旨在滿足以下關鍵應用場景的需求：
• AI 訓練與推論：為大型語言模型（LLM）提供龐大的參數快取池，解決 GPU 記憶體容量不足的問題。
• 記憶體即儲存（Memory as Storage）：將儲存裝置無縫融入記憶體階層，應用程式可以直接以記憶體存取模式操作持久性資料，無需傳統的檔案系統 I/O。
• 記憶體池化（Memory Pooling）：將 DRAM 或其他記憶體資源從單一伺服器中解放出來，形成一個可供多台伺服器共享的資源池，從而將記憶體容量從 GB 等級擴展至 TB 等級，大幅提升資源利用率與系統彈性 [4]。
三、CXL SSD 驗證五大關鍵差異
CXL SSD 的驗證方法論與傳統 NVMe SSD 存在根本性的不同。傳統 SSD 驗證主要圍繞著基於區塊（Block-based）的 I/O 操作、儲存協定合規性以及儲存介質的耐久性。然而，CXL SSD 作為一種記憶體裝置，其驗證重點轉向了記憶體語意、系統一致性與延遲敏感度。以下是五大關鍵的驗證差異：
1. 主控權轉移：從裝置自主到主機管理
在傳統的 NVMe SSD 中，裝置本身擁有一個強大的控制器（Controller），負責管理 Flash Translation Layer (FTL)、垃圾回收（Garbage Collection）和磨損均衡（Wear Leveling）等內部操作。主機僅透過 NVMe 命令佇列下達高階的讀寫指令。但在 CXL SSD 的架構中，裝置通常被設計為一個相對「被動」的記憶體控制器。大部分的管理權力轉移至主機端的記憶體控制器。因此，驗證工作不再是簡單地向裝置發送 NVMe 命令，而必須模擬主機 CPU 發出的記憶體讀寫指令（Memory Read/Write），並在系統層級觀察裝置的反應。
2. 記憶體語意（Memory Semantics）驗證
這是 CXL SSD 驗證中最核心的轉變。NVMe SSD 使用的是基於區塊的 I/O 模型，而 CXL SSD 則採用與 DRAM 相同的載入/儲存（Load/Store）模型。這意味著驗證的重點不再是 LBA（Logical Block Addressing）的正確性，而是位元組可定址（Byte-addressable）存取的資料一致性（Data Consistency）與快取同調（Cache Coherency）。驗證工程師必須設計測試案例，以驗證 CXL 的一致性協定（CXL.cache 和 CXL.mem）是否正確實現，包括處理來自多個 CPU 核心的並行存取、快取行的狀態轉換（如 MESI 協定）以及快取失效（Cache Invalidate）機制的有效性 [3]。
3. 需搭配記憶體池（Memory Pool）進行測試
CXL 的一個關鍵價值在於實現記憶體池化。單獨測試一個 CXL SSD 裝置是遠遠不夠的。驗證必須在一個包含多個 CPU 插槽、多個 CXL 交換器（Switch）以及多個 CXL 裝置的複雜拓撲中進行。測試場景需要涵蓋記憶體池的動態分配與釋放、跨越多個裝置的記憶體交錯（Interleaving）以及記憶體分層（Tiering）策略的驗證，例如，系統如何有效地在不同層級的記憶體（如本地 DRAM、CXL 附加記憶體、CXL SSD）之間搬移熱點資料（Hot Data）和冷點資料（Cold Data）。
4. 可靠性測試方式的根本改變
傳統 SSD 的可靠性測試，如長時間的老化測試（Burn-in Test）和電源循環測試（Power Cycle Test），雖然仍然有其價值，但已不足以涵蓋 CXL SSD 的所有風險。由於 CXL SSD 被視為記憶體的一部分，其可靠性要求遠高於傳統儲存。驗證需要引入針對記憶體系統的測試方法，例如：在意外斷電情況下，驗證寫入快取中的資料是否能被正確地持久化到 NAND Flash，確保資料一致性；透過錯誤注入（Error Injection）來測試裝置的 ECC（Error-Correcting Code）和 CRC（Cyclic Redundancy Check）機制能否有效地偵測和恢復單位元錯誤（Bit Error）；以及在長時間高壓力的記憶體交換（Memory Swap）與容錯回復（Failback）測試中，觀察系統的穩定性。
5. 效能測試不再僅看 IOPS 與頻寬
雖然頻寬（Bandwidth）仍然是 CXL SSD 的一個重要指標，但傳統衡量儲存效能的 IOPS（Input/Output Operations Per Second）指標已不再是重點。由於 CXL SSD 直接掛載在記憶體匯流排上，其效能表現對系統的整體影響更為直接，特別是延遲（Latency）。驗證的焦點轉向了延遲的穩定性，即延遲抖動（Latency Jitter）的分析。測試需要精確測量在不同負載下的記憶體響應時間，並分析其長尾延遲分佈（如 99.99%、99.999%ile）。此外，還需要評估在非均勻記憶體存取（NUMA）架構下，跨 CPU 節點存取 CXL SSD 所帶來的延遲影響，這對測試平台和量測工具提出了全新的要求。
四、CXL SSD 驗證測試計畫（Test Plan）草案
基於上述的關鍵差異，一個全面的 CXL SSD 驗證測試計畫應涵蓋功能、效能、可靠性和相容性四大方面。
✅ 功能性測試 (Functional Test)
• 裝置發現與記憶體區域映射 (Device Discovery & Memory Region Mapping): 驗證主機 BIOS/OS 能否正確識別 CXL 裝置，並將其記憶體空間（HDM - Host-managed Device Memory）成功映射到系統實體位址空間。
• 主機到裝置的載入/儲存測試 (Host-to-Device Load/Store Test): 進行各種大小和模式的記憶體讀寫操作，並驗證資料的完整性。此測試需包含對快取同調機制的壓力測試。
• 快取刷新與失效操作 (Cache Flush & Invalidate Operations): 驗證主機能夠透過 CXL 命令（如 `Flush`、`Invalidate`）正確管理裝置端的快取狀態。
• 動態記憶體熱插拔 (Dynamic Memory Hot Plug / Unplug): 測試在系統執行中動態新增或移除 CXL 裝置時，OS 和應用程式的反應是否正常，記憶體資源是否能被平穩地納入或釋放。
🚀 效能測試 (Performance Test)
• 隨機存取延遲分佈 (Random Latency Distribution): 使用專門的記憶體延遲測試工具（如 `mlc`），測量在不同壓力下的隨機讀寫延遲，並分析其 P99、P99.9、P99.999 等長尾延遲數據。
• 記憶體分層效能測試 (Memory Tiering Performance Test): 建立一個包含 DRAM、CXL SSD 和傳統 NVMe SSD 的混合記憶體環境，執行典型應用負載（如資料庫、AI 推論），評估不同資料放置策略對整體效能的影響。
• 頻寬擴展性測試 (Bandwidth Scaling Test): 在多 CPU、多核心的環境下，逐步增加存取 CXL SSD 的核心數量，測試其總頻寬是否能線性增長，並找出效能瓶頸。
🔁 可靠性測試 (Reliability Test)
• ECC 錯誤注入與校正測試 (ECC Injection & Correction Test): 在裝置韌體或硬體層級注入單位元或多位元錯誤，驗證裝置的 ECC 機制能否正確偵測、回報並修復錯誤。
• 部分寫入恢復測試 (Partial Write Recovery Test): 模擬在一次寫入操作（如 64 位元組的快取行寫入）中途發生電源故障，驗證裝置能否恢復到一個一致的狀態，避免資料損毀。
• 長時間記憶體交換與容錯回復測試 (Long-duration Memory Swap & Failback Test): 讓系統在高記憶體壓力下長時間執行，頻繁地在主記憶體與 CXL SSD 之間交換頁面（Page Swap），同時模擬節點故障，測試系統的穩定性與資料完整性。
🖥️ 相容性測試 (Compatibility Test)
• 多平台支援驗證: 在支援 CXL 2.0/3.0 的不同 CPU 平台（如 Intel Xeon Scalable Processor 和 AMD EPYC Processor）上進行完整的測試，確保裝置的互通性 [5]。
• 作業系統與驅動程式相容性: 驗證裝置能與主流的 Linux 發行版（如 Ubuntu 22.04、RHEL）及其內建的 CXL 驅動程式良好協同工作。
• 記憶體池多裝置資源管理驗證: 在一個包含來自不同供應商的多個 CXL 裝置的記憶體池中，驗證資源管理軟體（如 MEMVerge Memory Machine）能否統一、高效地管理和調度這些異質資源。
五、CXL SSD 驗證工具與平台現況
CXL 是一個相對較新的技術，因此市場上成熟且公開可用的驗證平台與工具仍然處於發展初期。許多大型雲端服務商（如 Meta、Google）和 CPU 製造商都擁有其內部客製化的驗證框架。然而，一些領先的測試與量測公司已經推出了相應的解決方案：
• 協定分析儀與產生器 (Protocol Analyzer & Exerciser): Teledyne LeCroy、Keysight、Viavi 等公司提供 CXL 協定分析儀，用於擷取和解碼 CXL 匯流排上的流量，幫助工程師進行底層的除錯與協定合規性驗證。
• 驗證 IP 與模擬平台 (Verification IP & Emulation Platform): Synopsys、Cadence 和 Siemens EDA 等公司提供 CXL 的驗證 IP（VIP），可用於晶片設計的早期模擬與驗證，確保設計符合 CXL 規範 [6]。Intel 也提供其模擬平台（Emulation Platform）供合作夥伴進行早期開發與測試。
• 系統級驗證平台與軟體: Teledyne LeCroy 的 OakGate 測試平台和 Endeavor 軟體提供了系統級的功能與效能驗證解決方案，專門用於 CXL 記憶體裝置 [7]。Astera Labs 和 MEMVerge 等新創公司則專注於 CXL 記憶體控制器和記憶體池化管理軟體，其解決方案也包含了重要的驗證與互通性測試套件 [8]。
• 與 CPU 廠商的緊密合作: 由於 CXL 的驗證與 CPU 架構高度耦合，因此與 CPU 供應商（如 AMD 和 Intel）的緊密合作至關重要。只有在真實的伺服器平台上，才能進行最完整和最有效的系統級驗證。
六、結語：抓住 CXL SSD 驗證的破口，就是技術領先的開始
CXL SSD 的出現，不僅僅是 SSD 技術的一次簡單升級，它更代表著一場深刻的架構變革。其驗證工作不再是傳統儲存驗證的延伸，而更像是記憶體驗證在持久性儲存領域的變形與挑戰。從區塊 I/O 到記憶體語意，從被動的儲存裝置到主動參與系統同調的記憶體擴充器，這一切的轉變都對驗證工程師的知識體系和技能組合提出了全新的要求。
未來，能夠同時掌握 SSD 內部原理、記憶體系統架構以及 CXL 協定驗證能力的複合型人才，將在 AI 與 HPC 時代的激烈競爭中佔據無可取代的戰略先機。對於企業而言，率先建立起成熟、高效的 CXL SSD 驗證流程與能力，不僅是確保產品質量的基礎，更是抓住技術破口、實現市場領先的關鍵一步。
參考資料
[1] Penguin Solutions. “Scaling the AI Memory Wall Bottleneck With CXL Technology.” Accessed November 23, 2025. https://www.penguinsolutions.com/en-us/challenges/memory-wall-scaling
[2] Compute Express Link. “About CXL.” Accessed November 23, 2025. https://computeexpresslink.org/about-cxl/
[3] Synopsys. “An Introduction to the CXL Device Types.” March 3, 2020. https://www.synopsys.com/blogs/chip-design/introduction-cxl-device-types.html
[4] MEMVerge. “Memory Pooling and Emerging Architectures for Efficient AI/ML Infrastructure.” October 17, 2022. https://memverge.com/wp-content/uploads/2022/10/CXL-Forum-OCP_Astera-Labs-Microsoft-Google.pdf
[5] Marvell. “Marvell Announces Successful Interoperability of Structera CXL Portfolio with AMD EPYC CPU and 5th Gen Intel Xeon Scalable Platforms.” April 23, 2025. https://www.marvell.com/company/newsroom/marvell-announces-successful-interoperability-structera-cxl-portfolio-amd-intel.html
[6] Cadence Design Systems. “Simulation VIP for CXL.” Accessed November 23, 2025. https://www.cadence.com/en_US/home/tools/system-design-and-verification/verification-ip/simulation-vip/pcie/cxl.html
[7] Teledyne LeCroy. “Validating CXL Memory Device Functionality and Performance with OakGate.” January 29, 2024. https://www.teledynelecroy.com/doc/cxl-memory-device-wp
[8] Astera Labs. “Astera Labs Delivers Industry-First CXL® Interop with DDR5-5600 Memory Modules.” Accessed November 23, 2025. https://www.asteralabs.com/astera-labs-delivers-industry-first-cxl-interop-with-ddr5-5600-memory-modules/
