CXL概述（二）_cxl back invalidate

《An Introduction to the Compute Express LinkTM (CXL) Interconnect》

前言

之前自己根据 CXL2.0 Spec 总结了一篇, 跟这篇相比，少了很多内容，跟论文总归是比不过的。有兴趣的同学可以去看原文，有些术语可能翻译不准确，机翻略修改而已。

Abstract

Compute Express Link（CXL）是处理器与加速器、内存缓冲器、智能网络接口、持久内存和固态硬盘等设备之间的开放式行业标准互连。CXL 提供内存一致性和内存语义(load/store)，其带宽可与 PCIe 带宽相匹配，同时延迟大大低于 PCIe。所有主要 CPU 供应商、设备供应商和数据中心运营商都已采用 CXL 作为通用标准。这样就形成了一个可互操作的生态系统，支持包括高效加速器、服务器内存带宽和容量扩展、多服务器资源池和共享以及高效点对点通信在内的关键计算用例。本文介绍了 CXL，包括 CXL 1.0、CXL 2.0 和 CXL 3.0 标准。我们将进一步调查 CXL 的实施情况，讨论 CXL 对数据中心格局的影响以及未来的发展方向。

1 Introduction

Compute Express Link (CXL) 是一个开放的行业标准，定义了 CPU 和设备之间的一系列互连协议。虽然有 CXL 规范手册^[3]和新闻机构的简短摘要，但本教程力求在提供技术细节的同时，让广大受众能够理解。CXL 协议横跨整个计算堆栈，涉及计算机科学的多个分支。为了处理这种广泛性，我们将重点放在基础工程方面，而较少关注安全特性、安全影响和更高层次的软件功能。
作为一种通用设备互连，CXL 采用了广泛的设备定义，包括图形处理器 (GPU)、通用图形处理器 (GP-GPU)、现场可编程门阵列 (FPGA)，以及各种专用加速器和存储设备。传统上，这些设备使用外围组件互连 Express®（PCI-Express® 或 PCIe®）串行接口。CXL 还针对传统上通过双倍数据速率 (DDR) 并行接口连接到 CPU 的存储器。

CXL 协议可以应用到 GPU、GP-GPU、FPGA、内存存储器。

虽然 PCIe 和 DDR 一直是各种设备的理想接口，但它们也有一些固有的局限性。这些限制导致了以下挑战，促使我们开发和部署 CXL。

PCIe 与 DDR 当前面临的挑战：

挑战 1：连贯地访问系统和设备内存。系统内存通常通过 DDR 连接，并可由 CPU 高速缓存分级缓存。相比之下，PCIe 设备对系统内存的访问是通过非一致性读/写实现的，如图 1 所示。PCIe 设备无法缓存系统内存以利用时间或空间位置性或执行原子操作序列。从设备到系统内存的每次读/写都要经过主机的根复用器 (RC)，从而使 PCIe 与 CPU 的缓存语义保持一致。同样，连接到 PCIe 设备的内存从主机进行非一致性访问，每次访问都由 PCIe 设备处理。因此，设备内存无法映射到可缓存的系统地址空间。

PCIe 设备内存无法缓存，导致主机访问设备内存延迟高；内存读写无法执行原子操作。

非一致性访问对于流式 I/O 操作（如网络访问或存储访问）非常有效。对于计算加速器而言，整个数据结构在移回主存储器之前，会从系统内存移至加速器以实现特定功能，并部署软件机制以防止 CPU 和加速器之间的同时访问。这对人工智能 (AI)、机器学习 (ML) 和智能网络接口卡 (NIC) 等新的使用模式构成了障碍，在这些使用模式中，设备需要使用设备本地缓存与 CPU 同时访问相同数据结构的部分内容，而无需来回移动整个数据结构。这一挑战也出现在不断发展的内存处理（PIM）领域，该领域试图将计算迁移到数据附近。目前，PIM 设备还没有标准化的方法来连贯地访问 CPU 高速缓存层次中可能存在的数据。这导致了繁琐的编程模型，阻碍了 PIM 的广泛应用^[67,68]。

非一致性访问对大数据量的读写是有效的，但是AI、NIC等可能会与主机访问相同的一段内存中的部分内容，没必要整段内存全部读到设备，这就产生了问题。

挑战 2：内存可扩展性。内存容量和带宽需求的增长与计算量的指数增长成正比（图 2）。遗憾的是，DDR 内存无法满足这一需求,从而限制了每个 CPU 的内存带宽。造成这种扩展不匹配的一个关键原因是并行 DDR 接口的引脚效率低下。通过增加 DDR 通道进行扩展会大大增加平台成本，并带来信号完整性的挑战。原则上，PCIe 引脚将是一个很好的替代方案，因为其单位引脚内存带宽更出色。例如，32GT/s 的 x16 Gen5 PCIe 端口可通过 64 个信号引脚提供 256 GB/s 的带宽。DDR5-6400 的速度为 50 GB/s，信号引脚约为 200 个。PCIE 还支持使用 Retimer 实现更长的传输距离，这样就可以将内存移到离 CPU 更远的地方，每个 DIMM 的功耗超过 15W，从而实现更出色的性能。遗憾的是，PCIe 不支持一致性，设备连接的内存无法映射到一致性内存空间。因此，PCIe 无法取代 DDR。

硬件方面， DDR 引脚多 ，200+ 个，PCIe 引脚少，DDR5-6400 的速度为 50 GB/s, x16 Gen5 PCIe 64个引脚可提供 256 GB / s 的带宽。

另一个扩展挑战是 DRAM 存储器的每比特成本最近一直保持不变。虽然有多种前景看好的介质类型，包括 Managed DRAM^[71]、ReRam^[72]、3DXP/Optane^[73]。但 DDR 标准依赖于特定于 DRAM 的命令进行访问和维护，这阻碍了新介质类型的采用。

挑战 3：内存和计算资源搁置导致效率低下。当今的数据中心由于资源搁置而效率低下。当一种资源闲置容量仍然存在，而另一种资源（如计算资源）已被充分利用时，这种资源（如内存）就会被搁置。其根本原因是资源耦合过紧，计算、内存和 I/O 设备只属于一台服务器。因此，每台服务器都需要超量配置内存和加速器，以处理峰值容量需求的工作负载。例如，一台服务器上的应用程序需要的内存（或加速器）超过了可用的内存（或加速器），而这台服务器又不能从同一机架上另一台未充分利用的服务器上借用内存（或加速器），因此必须承受页面未命中所带来的性能后果。另一方面，当服务器的所有内核都被工作负载使用时，往往会出现内存闲置的情况。搁置对功耗^[36]、成本^[18]和可持续性^[35]都有不利影响，也是阿里巴巴^[29]、AWS^[34]、谷歌^[30]、Meta^[17,33]和微软^[18,31,32]资源利用率低的原因。

内存资源不能被池化共享。

挑战 4：分布式系统中的细粒度数据共享。分布式系统经常需要细粒度同步。底层更新通常较小，对延迟敏感，因为更新时会出现工作块。这方面的例子包括网络搜索、社交网络内容组合和广告选择等网络规模应用中的分区/聚合设计模式 ^{[38、39、41、42]}。在这些系统中，查询更新通常小于 2kB（如搜索结果）,其他例子包括依赖 kB 级页面的分布式数据库和更新更小的分布式共识 ^{[37, 44-46]}。以如此精细的粒度共享数据，意味着典型数据中心网络中的通信延迟将主导更新的等待时间，并减慢这些重要用例的运行速度^{[38, 40]}。例如，以 50GB/s（400Gbit/s）的速度传输 4kB 的数据需要不到 2us 的时间，但在当前的网络中，通信延迟超过 10us^[40]。一致性共享内存的实现有助于将通信延迟缩短到微秒以下，我们稍后将看到这一点。

分布式系统共享kb级数据量的时候，网络延迟占比大，一致性内存可以降低延迟。

CXL 的作用: CXL的开发就是为了应对上述四项挑战和其他挑战。自 2019 年首次发布以来，CXL 已经发展了三代（见第 2 节）。每一代都规定了互连和多种协议（见第 3 节），同时保持完全的向后兼容。表 1 概述了当前 CXL 的三代版本和关键用例示例。

如图 1 所示，CXL 1.0 规范在 PCIe 基础上增加了一致性和内存语义。通过使 CXL 设备能够缓存系统内存，解决了挑战 1（一致性）和挑战 2（内存扩展）。这也使一致性接口标准化，便于广泛采用 PIM 系统和编程模型。中央处理器还可以缓存设备内存，从而解决异构计算的细粒度数据共享问题。此外，连接到 CXL 设备的内存可映射到系统可缓存内存空间。这有利于异构处理，并有助于应对图 2 所示的内存带宽和容量扩展挑战。CXL 1.0 还继续支持 PCIe 的非一致性生产者-消费者语义 ^[1,2,8]。

• 解决了挑战1，设备可以使用本地缓存访问系统内存，与主机缓存保持一致性；
• 解决了挑战2，可以使用 PCIe 接口进行内存扩展；
• CXL 的.io 协议可认为与 PCIe 协议一致；

CXL 2.0 还通过在多台主机之间建立资源池来解决挑战 3（资源搁置）。我们把由单一操作系统或管理程序控制的单插槽或多插槽系统成为主机。资源池通过将资源（如内存）重新分配给不同的主机来克服资源搁置和碎片化的问题，而无需重新启动这些主机。CXL 协议通过引入 CXL switch 来构建一个由主机和内存设备组成的小型网络，从而实现资源池。

CXL switch ： 与 USB HUB 或 PCIe Switch 类比，扩展接口用；
CXL2.0 引入资源池将内存池化，解决挑战 3. 将内存细分为不同块，多个主机通过 switch 连接在链路中，按需申请分配使用；

CXL 3.0 通过多级 CXL 交换在更大范围内应对挑战 3。这样就能在机架甚至 pod 层构建动态可组合系统。此外，CXL 3.0 通过实现跨主机边界的细粒度内存共享，解决了挑战 4（分布式数据共享）。

章节分布：

CXL 需要 CPU 和设备支持。几乎所有芯片供应商都在商业产品中广泛采用 CXL，这证明该技术因其解决实际问题的能力而获得广泛认可。这使得 CXL 在解决关键行业挑战方面走上了一条可行之路，并得到了广泛应用 ^{[8,15,16,17,18]}。CXL 3.0 也已经达到了一定的成熟度，有助于对其基本设计选择进行审查。
本教程第 2 节介绍了背景。
我们将在第 3、4 和 5 节分别深入探讨 CXL 1.0、CXL 2.0 和 CXL 3.0 增量版本的细节。
第 6 节介绍了 CXL 的实现和性能预测。
第 7 节讨论了更广泛的影响和未来发展方向。

2 CXL BACKGROUND AND DESIGN CHOICES

高速缓存一致性互连历来是 "对称 "的，因为它们侧重于多插槽系统或多 GPU 系统。每个节点（CPU 或 GPU）都将执行相同的一致性算法，并跟踪所需的状态。常见的例子有英特尔的快速路径互连（QPI）和超路径互连（UPI）、AMD 的 Infinity Fabric、IBM 的 Bluelink 和 Nvidia 的 NvLink。多年来，对称互联的多种扩展试图解决第 1 节中的一些难题，如 CCIX 和 OpenCAPI。一些公司还授权使用 QPI 等协议。然而，行业经验表明，对称高速缓存一致性的复杂性和性能要求给部署带来了巨大挑战，因为随着时间的推移,协调一致性的机制在不同的架构和设计选择中差异很大。此外，并非所有用例都需要一致性支持，例如挑战 2（内存扩展）和挑战 3(资源搁置)。

广泛采用 PCIe 还要求有一个即插即用的生态系统，能够与前几代产品和不同的系统架构兼容。事实证明，向后兼容性是二十多年来 PCIe 成功成为普遍 I/O 互连的主要原因之一。它为设备和平台制造商独立进行技术过渡提供了便利。例如，平台可能会迁移到 PCIe 第 5 代，而固态硬盘供应商可能会决定继续使用第 4 代，并在以后根据固态硬盘的技术发展进行迁移。这也有助于保护客户的投资，因为客户可能会在新平台中重复使用一些老一代设备，例如，为了减少碳排放^[35]。

在英特尔，在 PCIe 上添加简化一致性机制的想法可以追溯到 2005 年，其动机是加速器需要缓存系统内存。其结果是，在保持 PCIe 非一致性的同时，在 PCIe 3.0 中添加了事务处理提示，以使用 CPU 的高速缓存层次结构实现更快的设备访问和原子语义。英特尔最初还打算在 PCIe 3.0 的基础上添加内存语义，以便通过共享内存控制器 (SMC) 实现池化。然而，PCIe 3.0 的带宽（8.0 GT/s）严重限制了使用一个 SMC 进行资源池的服务器数量。多 SMC 拓扑结构会因多次跳转而导致更高的延迟。另一个挑战是布线。2019 年，32.0 GT/s 的 PCIe 5.0（以及 64.0 GT/s 的 PCIe 6.0 的进展）和强大的布线技术支持重振了英特尔的技术方案。英特尔由此推出了英特尔加速器链接（IAL）：一种在 PCIe 5.0 上同时支持缓存和内存的专有协议。利用二十多年来开发 PCI-Express 的经验，英特尔开源了 IAL 1.0 规范，并于 2019 年 3 月与阿里巴巴、思科、戴尔、谷歌、华为、Meta、微软和 HPE 共同发起了 CXL 联盟。IAL 1.0 规范更名为 CXL 1.0 规范。

CXL 在一致性、向后兼容性和开放性方面采用了一种非对称方法，以建立一个多样化的开放生态系统，促进广泛部署。CXL 一致性与特定于主机的一致性协议细节脱钩, 主机处理器还负责协调缓存一致性，以简化设备一致性的实施。设备的高速缓存代理使用一个小命令集执行简单的 MESI（修改、独占、共享、无效）一致性协议。CXL 通过提供复杂程度不同的多种协议来支持多种用例，设备只能实施协议的一个子集（第 3 节）。

CXL 在 PCIe PHY 上运行，设备可插入任何 PCIe 插槽。CXL 的后向兼容演进（如 PCIe）及其与 PCIe 的互操作性，确保了公司在 CXL 上的投资可以保证与上一代 CXL 设备以及任何 PCIe 设备的互操作性。PCIe 基础设施的重复使用降低了进入门槛，因为相同的 IP 构建模块、平台、通道以及软件基础设施都可以重复使用。从 SoC 的角度来看，如图 3 所示，具有多协议功能的 PCIe PHY 有助于减少硅面积、引脚数和功耗 ^{[1、2、8、9]}。

CXL 设备可以插在 PCIe 插槽内，主机侧RC 也要有支持 CXL 的硬件，否则，一开始电主机与设备底层协商，走不通 CXL 就会走PCIe 协议。

CXL 于 2019 年推出时，行业内还存在 OpenCAPI、GenZ 和 CCIX 等相互竞争的互连标准。从那时起，CXL 成员已增加到约 250 家公司，所有 CPU、GPU、FPGA、网络、IP 提供商都在联盟内积极贡献力量。在英特尔于 2019 年 3 月捐赠 CXL 1.0 之后，该联盟于 2019 年 9 月发布了 CXL 1.1，增加了合规性测试机制。之后，联盟分别于 2020 年 11 月和 2022 年 8 月发布了 CXL 2.0 和 CXL 3.0，在保持完全向后兼容性的同时，纳入了更多的使用模式。随着时间的推移，行业已围绕 CXL 形成合力。例如，竞争标准 GenZ 和 OpenCAPI 向 CXL 捐赠了知识产权和资金，以支持共同的标准。

3 CXL 1.1 PROTOCOL

CXL 的第一代产品为直接连接到主机的设备引入了一致性和内存语义。这使得 CPU 和加速器能够对共享数据结构进行细粒度异构处理（第 1 节中的挑战 1），并以经济高效的方式扩展内存带宽和容量（第 1 节中的挑战 2）。

CXL 1.1 的设备只能作为 RCiEP 直连主机RC.

CXL 是一种非对称协议，与 PCIe 类似。主机处理器包含 “Root Complex”（RC），每个 CXL 链路中，每个 RC 连接到作为 “End Point” (EP) 的设备。主机处理器协调高速缓存一致性，如下所述。软件通过在主机处理器中执行的指令配置系统，主机处理器生成配置事务以访问每个设备。CXL 支持 x16、x8 和 x4 链路宽度，在降级模式下支持 x2 和 x1 宽度。降级模式是指 PCIe 链路自动进入更窄的宽度和/或更低的频率，以克服特定通道上高于预期的错误率。CXL 支持 32.0 GT/s 和 64.0 GT/s 的数据速率，而在降级模式下支持 16.0 GT/s 和 8.0 GT/s 的数据速率^{[1, 5, 8]}。

图 3 说明了 CXL 如何与 PCIe 实现完全互操作性，因为它使用的是 PCIe 协议栈。CXL 设备开始以 2.5 GT/s 的 PCIe 第 1 代数据速率启动链路训练，并使用 PCIe 5.0 和 PCIe 6.0 规范中定义的备用协议协商机制协商 CXL 作为操作协议。如果其链路合作伙伴支持 CXL，则使用 PCIe 5.0 和 PCIe 6.0 规范中定义的备用协议协商机制协商 CXL 作为运行协议。

与之前提过的一致，上电以 PCIe 1.0 速率启动链路训练，在 RC 与 EP 软硬件都支持 CXL 的情况下，该端口协商成 CXL 模式，使用 CXL 协议。

3.1 CXL Protocols and Device Types

CXL 通过三种协议实现，即 CXL.io、CXL.cache 和 CXL.memory（又名 CXL.mem），它们在 PCIe PHY 上动态多路复用。图 3 展示了 CXL 的多协议支持。CXL.io 协议基于PCIe 协议。它用于设备发现、状态报告、虚拟到物理地址转换以及直接内存访问（DMA）。CXL.io 使用 PCIe 的非一致性load-store 语义 ^[7、8、9]。现有的 PCIe 软件基础设施将现有的 PCIe 软件基础架构将通过必要的增强重新使用，以利用 CXL.cache 和 CXL.mem 等新功能。CXL.cache 用于设备缓存系统内存。CXL.mem 可使 CPU 和其他 CXL 设备将设备内存作为可缓存内存访问, CXL.mem 使连接到设备的内存成为可缓存内存，称为 “主机管理的设备内存” – HDM，与主机内存类似，从而实现主机在 HDM 和主机内存之间的统一视图（图 3）。所有设备都必须使用 CXL.io，而 CXL.cache 和 CXL.mem 则是可选的，并视具体使用情况而定。如图 4 所示。

图 4 显示了 CXL 1.0/1.1 规范中定义的三种设备类型，它们获得了不同的使用模式。类型 1设备是智能网卡等加速器，使用一致性语义和 PCIe 式直接内存访问（DMA）传输。因此，它们只实施 CXL.io 和 CXL.cache 协议。第 2 类设备是加速器，如GP GPU 和 FPGA 等加速器，其本地内存可部分映射到可缓存系统内存。这些设备也会缓存系统内存以进行处理。因此，它们执行 CXL.io、CXL.cache 和 CXL.mem 协议。第三类设备用于内存带宽和容量扩展，可用于连接不同类型的内存、包括支持连接到设备的多个内存层。因此，Type-3 设备将仅实施 CXL.io和 CXL.mem 协议。CXL Type-3 设备为在服务器 CPU 上增加更多 DDR通道的替代方案，同时由于更长的线路长度为系统拓扑结构提供了灵活性，从而减轻了电力传输和冷却压力^[8,9]。

详情可见另一篇。

CXL 采用分层协议方法。物理层负责物理信息交换、接口初始化和维护。数据链路层（或链路层）负责可靠的数据传输服务，并在设备之间建立逻辑连接。事务层负责处理与每个协议相关的事务以及任何架构排序语义、流量控制和信用。每个层都有一组寄存器，软件可访问这些寄存器来配置、控制和获取链路状态。读者可参阅相关规范^{[5, 7]}了解详情。

3.2 CXL 68-Byte Flit

CXL 在 PCIe PHY 层复用三种协议。每个协议的传输单位都是 Flit（流量控制单元）。CXL 1.0、1.1 和 2.0 规范定义了 68 字节的 Flit^{[1, 2, 3, 4, 8, 9]}。CXL 3.0 规范引入了额外的 256 字节 Flits^{[5, 6, 7, 8, 9, 13, 14]}，这个将在第 5 节中讨论。每个 Flit 由一个 2 字节协议ID、一个 64 字节有效载荷和一个保护有效载荷有效性的 2 字节 CRC（循环冗余校验）组成（图 5a）。协议ID可划分不同类型的数据包，并具有内置冗余功能，可检测和纠正这 2 个字节内的多个位翻转。CRC 可保证在 64 字节有效载荷（加上 2 字节的 CRC）中检测到多达 4 个随机位翻转，从而实现极低（<< 10-3）的故障时间failure in time（FIT，即链路中十亿小时内的故障次数），规范规定的误码率（BER）小于 10-12^{[5, 7]}。

图 5b 显示了 CXL.cache、CXL.mem 和 Arb/Mux 链路管理数据包 Arb/Mux Link Management Packets (ALMP) 使用的 16 字节 slot 机制，其中 4 个 16 字节 slots 构成了 Flit 的 64 字节有效载荷。Arb/Mux 向其链路伙伴的 Arb/Mux 设备发送 ALMP 数据包，以根据需要协调链路管理功能，如跨多个堆栈的电源管理。图 5c 显示了 CXL.cache 和 CXL.mem 协议使用的全数据 Flit 布局，简称为 CXL.cache+mem，因为两者之间的区分发生在链路层。CXL.io 原封不动地使用 PCIe 事务/数据链路层数据包（TLP/ DLLP），这些数据包在 Flit 的有效载荷部分发送。由于 TLP 和 DLLP 有自己的 CRC（分别为 32 位和 16 位）^[7]，CXL.io 数据包的接收器会忽略 16 位 Flit CRC ^[2,3]。

CXL.cache和CXL.mem的访问延迟很低，类似于本地CPU到CPU的对称一致性链路^{[1, 8, 9]}。CXL.cache和CXL.mem的链路层和事务层路径具有低延迟特性，因为它们是基于原生的 Flit 协议，而Flit的64字节有效载荷选择与这些协议的高速缓存行大小的传输相同。在物理层（PHY）（相对于堆栈的更高层）进行多路复用有助于为 CXL.cache 和 CXL.mem 流量提供低延迟路径。由于 PCIe/ CXL.io 路径支持可变数据包大小、排序规则、访问权限检查等，因此相比之下这消除了链路层和事务层的较高延迟^{[1, 3]}。物理层可区分 CXL.io、CXL.cache-mem、ALMP 和 NULL Flits（不发送时）。在发送有序集之前，这 4 种 Flits 中的每一种都有两种情况来指示当前 Flit 是否是数据流的终点（EDS）。这些有序集由物理层注入，用于周期性时钟补偿或任何链路恢复事件等功能。这 8 个编码使用 8 位，保证汉明距离为 4，重复两次，以便进行校正和检测 ^[2,3]。每个有序集有一个区块（130b）长，用于链路训练和时钟补偿。每个Lane独立发送其有序集。

在以 32 GT/s 或更低的速度运行时，CXL 使用 PCIe 的 128b/130b 编码方案，即在每条 Lane 上每 128 位数据预置 2 位同步头，以区分数据块和有序集块 ^[7,8]。如图 5d 中 x16 链路的两个数据块所示，每个 Lane 上的 128 位数据有效载荷用于传输 Flit。一个 Flit 可以跨越多个数据块，一个数据块可以包含多个 Flits。由于 CXL.io 数据包（TLP 和 DLLP）本身并不基于 Flit，因此一个 TLP 或 DLLP 可以跨越多个 Flit，而一个 Flit 可能包含两个数据包。对这些开销进行描述，就能得到第 6.3 节中讨论的有效载荷吞吐量。为了优化延迟，在协商 CXL 协议^[2]的初始 PCIe 链路培训过程中，当链路的所有组件（包括 Retimers（如有））都宣布支持该优化时，CXL 允许移除 2 位同步头。

3.3 CXL.io Protocol

CXL.io 协议基于 PCIe，用于设备发现、配置、初始化、I/O 虚拟化和使用非一致性 load-store 语义的直接内存访问（DMA）等功能。与 PCIe 一样，CXL.io 也是一种基于信用的分批交易协议^[7]。拆分事务是指与 CXL.io 请求事务相关的任何完成都会在稍后时间独立异步到达。这与早期基于 PCI 总线的架构不同，在早期的架构中，事务会锁定总线，直到其完成。之所以能做到这一点，是因为每个事务都是作为独立的事务层数据包（TLP）发送的，其消耗的 “信用” 与接收器上的缓冲空间一致。有三种流量控制类别（FC）：posted（P，用于内存写入和信息）、non-posted（NP，需要完成的事务，如内存读取和配置/I/O 读/写）和完成（C）。CXL.io 在这些 FC 中遵循 PCIe 排序规则，如图 6 所示（如第 5 节所述，CXL 3.0 引入了这些排序规则的例外情况）。这些规则可确保向前推进，同时执行生产者-消费者序列模式。CXL.io 规定了两个虚拟通道，以确保服务质量（QoS）。具有不同要求和延迟特性的流量被置于不同的虚拟通道（VC）中，以尽量减少系统中队列顶部阻塞的影响。例如，带宽大容量流量和对延迟敏感的等时流量可以放在不同的虚拟通道中，并设置不同的仲裁策略。同样，我们可以将 DRAM 访问和持久内存访问放在两个不同的 VC 中，因为它们具有非常不同的延迟和带宽特性，以确保其中一个的流量不会影响另一个。

其中 “Yes” 表示数据包（第2笔）可以超越先前的数据包（第1笔），以确保向前推进。为确保生产者的利益，“No” 表示不允许跳跃。为优化性能，"Y/N "适用于排序规则放宽的情况。

比如，内存写不能绕到前一个内存写的后面，因为后一个写可能是前一个写的写完成标志，先收到后一个内存泄，可能会导致读到旧的数据；
因为 Non-posted 产生 completion , 所以 Completion 必须能够绕过前一个 non-posted， 否则，就会导致系统死锁。
此机制详情可参考 PCIe 协议层。

图 7a 描述了生产者-消费者排序模型，它是硬件和软件之间的规定。这种模式在整个系统中强制执行，即使是跨越不同层次的事务，以及位于不同内存位置并可能具有不同属性（如可缓存与不可缓存）的地址位置也不例外。设备可以是 CPU、CXL/PCIe 设备或交换机中的任何实体。基本原理是，生产者产生（内存写入）数据，随后写入标记；数据和标记可以位于系统中的多个内存位置。如果消费者看到标记，就可以读取数据，并确保获得生产者写入的最新数据。标志可以是系统内存中的环形缓冲区、设备中的内存映射 I/O 位置或发送到处理器的中断。图 6 中描述的排序规则确保了生产者-消费者排序模式。排序规则的另一个作用是设备同步使用，如图 7b 所示。在这里，两个设备可能正在执行两个任务，并将 A 和 B 作为它们完成任务的指示器。如果读取到的是旧数据，则该设备中的进程可以暂停，由稍后完成执行的设备重新安排。如果（a，b）是可能的，那么两个设备中的两个进程都将永远暂停，这是不希望看到的结果。

生产者消费者模型介绍，就是两个进程，一个进程写，一个进程读，要保证读到的数据是写入的数据的一种机制。

虽然 CXL.io/PCIe 排序模型可用于某些类型的同步，但图 7c 所示的同步用法无法通过流水线访问来执行，因为写入可以绕过之前的读取。这种限制导致具有分区全局地址空间 (PGAS) 的智能网卡在排序事务时，会在读取后序列化写入。CXL.cache 克服了这一限制；设备可以不按顺序预取所有数据，并在符合程序顺序的本地缓存中以低延迟完成事务。

CXL.cache+mem 大部分情况下是无序的，但在每个高速缓存行的基础上有一些排序限制，这将在后面讨论。在支持源-目对之间多路径的拓扑结构中，这些限制可以通过路由机制来解决，该机制可确保任何给定高速缓存行的相关事务始终遵循相同的路径。但是，传统 PCIe（和 CXL.io）的排序要求跨越整个内存空间。因此，传统 PCIe（以及 CXL）必须遵循树状拓扑结构。在 CXL 3 中，我们放宽了 CXL.io 的排序要求，可以支持任何结构拓扑，详见第 5 节。

CXL.io 使用标准 PCIe 数据链路包(DLLPs)交换信息，如信用、可靠的 TLP 传输、电源管理等^{[2, 3, 7]}。 CXL.io 使用 PCIe 的配置空间，并为 CXL 的使用对配置空间进行了增强。这有助于使用现有的设备发现机制。我们预计，PCIe 设备驱动程序将进行必要的增强，以利用 CXL.cache 和 CXL.mem 等新功能，而系统软件将对与新功能相关的新寄存器集进行编程。这将建立在现有基础设施的基础上，使生态系统更容易采用 CXL。

CXL 相关的寄存器一部分会在 PCIe 配置空间中的 DVSEC（详见 CXL 协议手册）。

3.4 CXL.cache Protocol

CXL.cache 协议允许设备使用 MESI 一致性协议^[49]缓存主机内存，缓存行大小为 64 字节。为了保持协议在设备上的简单性，主机管理所有 peer 高速缓存的一致性跟踪，设备从不与任何 peer 高速缓存直接交互。该协议建立在每个方向的 3 个通道上。通道的方向是主机到设备（H2D）和设备到主机（D2H）。每个方向都有一个请求、响应和数据通道。每个方向上的通道都是独立流动的，但有一个例外：主机在 H2D 请求通道中发出的窥探（Snoop）信息必须在 H2D 响应中针对相同的高速缓存行地址推送之前的全局观察（GO）信息。GO 信息向设备指出一致性状态（MESI）和一致性提交点。

GO 信息就是告诉设备某个缓存行应该处在哪种 MESI 状态。

CXL.cache 仅使用主机物理地址。缓存设备与中央处理器一样，在执行代码时使用虚拟地址。同样，高性能设备也应使用虚拟地址，以避免软件层提供转换。预计设备将实现一个与 CPU 的 TLB 类似的设备转换旁路缓冲器 (DTLB)，以缓存页表条目。它使用 PCIe（和 CXL.io）的地址转换服务（ATS）^{[2, 3, 5, 7]}来获取虚拟到物理的转换以及访问控制，以确保多个虚拟机/容器之间的适当隔离。此外，CXL 还对 ATS 进行了扩展，以传达对地址的访问是允许使用 CXL.cache 还是仅限于 CXL.io。由于 DTLB 是非一致性的，ATS 希望主机处理器跟踪整个平台上 DTLB 中的待处理条目，并对软件已失效的 DTLB 条目（或条目）启动失效。主机处理器使用其 ATS 硬件机制完成与 DTLB 的失效握手，然后再向正在失效页表条目的软件指示完成。

CXL 设备中也可以有 DTLB 和 ATC, 这样，设备处理器可以像主机处理器一样，根据虚拟地址和页表访问主机系统中的进程地址空间。详情查阅 TLB/ATS/IOMMU 等机制。

D2H 请求通道包括 15 条命令，分为 4 类： 读"、“读 0”、“读 0-写”、“写”。如图 8 所示，读取类别允许设备请求缓存行的一致性状态和数据。响应将是 H2D 响应通道中的一致性状态（如果需要一致性）和 H2D 数据。读 0 "类请求只针对一致性状态，数据为 “0”（表示不需要数据）。这可用于升级高速缓存中的现有数据（S 到 E），或在预计写入整个高速缓存行时引入 E 状态。H2D 响应通道表示主机提供的一致性状态。读 0 写类别允许设备直接向主机写入数据，在发出之前不需要任何一致性状态。当主机准备好接受 D2H 数据时，H2D 响应将显示 “WritePull”，而当系统 “全局观测”（GO）该数据时，主机将在显示之前解决一致性问题。写类别用于设备从设备缓存中删除数据。这些请求可以是脏数据（M 状态），也可以是清洁数据（E 或 S 状态）。在设备需要提供数据的情况下，主机将指示 “WritePull” + GO。

MESI 协议，详情查阅其他资料了解，状态代表 Cache line 的状态这里简单说明:

• M 修改，表示该缓存行有效，数据被修改，和内存数据不一致，数据只存在本 Cache 中
• E 独享，表示该缓存行有效，数据和内存数据一致，数据只存在于本 Cache 中
• S 共享，表示该缓存行有效，数据和内存数据一致，数据存在于多个 Cache 中
• I 无效，该缓存行无效

图 8.A 中
 RdOwn 表示，设备读主机内存X地址数据，缓存行想要 Own 独享; 主机通过 H2D 通道返回数据， 并返回 GO 指示 Cache line 状态为 E;
 H2D 主机 Snoop 请求对X地址缓存行， SnpInv 代表想要独享； 设备通过 D2H 响应，RspIHitSE 表示在设备缓存中 hit, 之前是 SE 状态，现在是 I 无效状态，因为主机请求的共享；

图 8.B 中，Snoop 在 D2H Req 之前的流程，特殊的就是 RspIHitI 表示设备对主机 Snoop 的响应，在设备缓存中没有找到该地址 X 缓存行，主机则认为设备中该缓存行已经清空；
图 8.C 中，Snoop 在 Evict 之前的流程，RspIFwdM 表示该缓存行在设备 hit 且状态是 M 状态， 之后则是 I 状态，主机可以假设设备没有该缓存行的备份了，被主机缓存独占；GO_WritePull Go + WritePull 表示设备可以直接将数据写入主机内存；

H2D 请求通道用于主机改变设备的一致性状态，这被称为 “窥探”（Snooping，缩写为 Snp）。设备必须根据窥探类型的要求更新缓存，如果缓存中存在脏数据（M 状态），还必须将该数据返回给主机。图 8 举例说明，主机发送 SnpInv X，要求设备使地址 X 的高速缓存失效。设备将地址 X 的高速缓存状态从 E 改为 I，然后在 D2H 响应通道上发送 RspIHitSE。RspI 表示其最终缓存状态为 I 状态，HitSE 表示缓存在降级为 I 状态之前为 S 或 E 状态。

一致性协议的一个重要组成部分是如何处理对同一地址的冲突访问。有两种情况需要重点说明：(1) Req-to-Snoop 和 (2) Eviction-to-Snoop。对于 “请求到窥探”（Req-to-Snoop），设备在决定如何响应时，H2D 响应通道上的 GO 消息必须排在未来对同一高速缓存行地址的任何 “窥探”（Snoop）之前。其原因如图 8A 所示，从主机发送的 GO 信息必须先于后面的窥探信息，这样设备才能意识到它已独占该地址的所有权，并能正确处理窥探信息。图 8B 是相反顺序的情况，主机首先处理窥探，并在窥探完成前停止未来的请求，因此设备在 GO 之前观察到窥探会导致在缓存处于无效状态时处理窥探。对于 Evict-to-snoop，图 8C 显示了当 DirtyEvict 未处理时 snoop 到达的情况，设备必须用当前的 M 状态数据回复 snoop。随后的 GO_WritePull 仍必须返回数据，但包括数据是假的（意味着可能是过期数据）的提示，因此主机必须放弃数据，因为更新的数据可能存在于其他 Agent 中。

3.5 CXL.mem Protocol

内存协议使设备能够公开主机管理设备内存（HDM），允许主机管理和访问该内存，类似于连接到主机的本地 DDR。该协议独立于所使用的媒体介质，使用一组简单的主机物理地址读写，要求设备在内部转换为设备的内存地址空间。对于希望同时缓存该内存的加速器设备，我们提供了高级语义，使设备能够直接缓存内存，并依靠设备跟踪主机对该内存的缓存。

主机可以像访问本地内存一样访问 CXL 设备内存，设备内部存在地址转换，主机物理地址-》PCIe 总线地址 -》PCIe 总线地址 -》设备物理地址 -》设备内存存储器地址

该协议在每个方向上使用两个通道，分别称为 Master 对 Subordinate (M2S) 和 Subordinate 对 Master (S2M)。M2S 方向提供一个请求通道和一个带数据的请求（RwD）通道。S2M 方向提供非数据响应（NDR）通道和数据响应（DRS）通道。为了实现简单/低延迟，通道之间没有排序。

CXL.mem 有两种用途： (1) 作为 “主机内存扩展器”，(2) 作为暴露给主机的加速器内存。两者都使用 HDM 术语来描述 CXL.mem 协议访问的内存区域，但协议要求有所不同。HDM-H 不包括任何一致性协议假设，而 HDM-D 包括每个报文中使用的高速缓存状态和高速缓存窥探属性。HDM-D 还需要一种方法，用于从设备到主机通信所需的内存高速缓存状态，称为 "偏置翻转 "流（Bias Flip Flow）。

最初的 CXL 1.0 和 1.l 规范没有使用 -D 和 -H 术语，而是根据设备类型隐含属性，其中 Type-3 设备为 HDM-H，Type-2 设备为 HDM-D。由于新的要求，CXL 3.0 取消了与设备类型的对齐，因此本文的描述将使用 CXL 3.0 术语，以提高一致性。
"偏置翻转 "指的是设备偏置表（或一致性目录），它跟踪主机是否拥有地址的缓存副本。偏置跟踪可能显示 Host-S（仅在主机中共享）、Host-A（主机中的任何缓存状态）或设备（主机没有地址的缓存副本，因此称为 “设备偏置”）。翻转 "指的是偏置表将跟踪的状态从 "主机偏置 "改为 “设备偏置”。

HDM-H 为每个高速缓存行提供 2 位可选的 Meta Value，供主机使用。可能的用途包括一致性目录、安全属性或数据压缩属性。图 9A 显示了一个示例流程，主机读取更新设备中的 Meta Value，设备返回 Meta Value 的先前状态。在此示例中，设备需要更改存储在设备中的当前 Meta Value，因为值已从 2（旧值）变为 0（新值）。请注意，Meta Value和 ECC 的存储介质是针对特定设备的。

HDM-D 使用 Meta Value 字段的方式不同，它在该字段中向设备公开主机一致性状态，从而使设备能够知道主机为 HDM-D 区域中的每个地址缓存的状态。本规范使用设备一致性（Dcoh）代理一词来描述设备中管理/跟踪设备和主机一致性的代理。图 9B 显示了 HDM-D 的一种情况，即主机在 S 状态下读取数据到高速缓存，并要求设备检查其高速缓存（Dev $）是否有当前副本，但在本例中，高速缓存没有数据，因此数据从主机内存传送。

DCOH Agent 位于设备中，管理设备缓存一致性，Meta Value 是主机向设备说明本地缓存行的状态；例子中，缓存行没有命中，因此从设备内存中读取数据，返回给主机。

HDM-D 一致性模型允许设备通过 CXL.cache 请求来改变主机的状态。CXL.cache 是实现这一目的天生的方法，因为 HDM-D 只针对Type-2设备定义，因此CXL.cache协议可用。设备改变主机高速缓存状态的流程称为 "偏置翻转 "流程。图 10 是该流程的示例，设备首先向主机发送 “RdOwnNoData X”，这将检测到地址 X 是由发出设备拥有的 HDM-D 地址，其行为将与其他方式不同，因为它将直接改变主机的缓存状态，迫使所有主机缓存进入 I 状态。偏置翻转流的响应与传统的 CXL.cache 响应不同，在本例中，主机将在 CXL.mem M2S Req 信道上发送响应 MemRdFwd 消息，以表明主机已完成缓存状态更改。通过使用 CXL.mem M2S Req 通道，可以避免与主机的竞争条件，即未来对同一地址的 CXL.mem 请求要求 M2S 请求通道排序访问同一高速缓存行。排序要求仅适用于 HDM-D 地址。

3.6 Protocol Hierarchy

CXL 与 CPU 内部的一系列一致性实现兼容。图 11-A 获得了一个可能的主机 CPU 架构，其中 CXL.cache 位于与 CPU 内核共享的主机 L3 cache 下。在此示例中，CXL.io/PCIe 协议访问主机内存时也会通过相同的高速缓存，并遵循主机内存路径上使用的目标一致性语义。本图显示的是 socket 中的单个 L3。另外，主机架构也可以拆分 L3 或其他内部高速缓存，而不影响不了解主机高速缓存细节的 CXL.cache。根据主机特定协议（专有 CPU-to-CPU）的定义，主机可扩展到多个 CPU socket 或缓存，该协议定义了一个内部 Home Agent，用于解决主机缓存（包含 CXL.cache 设备）之间的一致性问题。该主机 Home Agent 可包括用于解决一致性问题的主机特定优化，如 on-die snoop filters or in-memory directory states。CXL.mem 协议位于主机 Home Agent 逻辑之后，可支持仅主机一致性（HDM-H）或设备一致性（HDM-D）的简单内存扩展。对于 HDM-D，在主机 Home Agent 之后还包括一个额外的一致性解决 level，允许设备成为设备所拥有地址一致性的最终仲裁者。

图 11-B 显示了 CXL 中预期的协议依赖图。协议依赖图定义了哪些协议通道可能依赖于（或阻塞）其他协议通道。如果没有创建循环依赖关系，依赖关系图是一种显示通道间死锁自由度的方法。依赖关系图中的一个例子是，L1 Req 可能依赖于 L1-Snp 通道完成，然后才能处理新的 L1 Req。之所以存在这种依赖关系，是因为请求可能需要先发送并完成窥探，然后才能完成请求。L1 协议为 CXL.cache，显示了 CXL.cache 中提供的通道抽象，其中 L1-Req 映射到 D2H Req，L1-Snp 映射到 H2D-Req，L1 RSP 映射到 H2D/D2H RSP 和数据通道，这些通道预先分配给主机或设备，从而将这两个通道结合在一起，形成依赖关系图。L2 协议是针对主机的，以主机可能存在的通道为例，但也可以选择其他通道。如果依赖关系图没有循环，主机还可以包含其他级别的协议。L3 协议为 CXL.mem，其中 L3 Req 映射到 M2S-Req，L3-RwD 映射到 M2S-RwD，而 L3-Rsp 则覆盖预分配的 S2M NDR 和 DRS 信道。依赖关系图是一种用于显示协议中和协议间的法律关系和依赖关系的方法，可快速确定 CXL 本身以及主机或设备内部协议的高级死锁自由度。

4 CXL 2.0 PROTOCOL

CXL 的第二代产品实现了资源池功能，可在一段时间内将相同的资源分配给不同的主机。在运行时重新分配资源的能力解决了资源搁置的问题（第 1 节中的挑战 3），因为它克服了资源与单个主机之间的紧密耦合。如果一台主机运行计算密集型工作负载，但没有使用从池中分配的设备内存，操作员可以将该设备内存重新分配给另一台主机，后者可能运行内存密集型工作负载。由于操作员在设计时通常不知道哪些工作负载在哪些主机上运行，因此资源池可以节省大量内存：操作员无需根据任何类型的内存密集型工作负载所使用的最坏情况内存容量来确定两台主机的大小，而是根据平均情况提供内存^[18]。同样的资源池结构也适用于加速器等其他资源。

资源池化，是 CXL 2.0 的一大特点，通过 CXL switch 将多个主机与设备互联，资源按需申请分配，解决挑战3；

4.1 CXL 2.0 Protocol Enhancements

CXL 2.0 增加了热插拔、单级交换、内存服务质量 (QoS)、内存池、设备池和全局持续刷新 (GPF)。CXL 1.1 不允许热插拔，这就排除了在平台启动后添加 CXL 资源的可能性。CXL 2.0 支持标准 PCIe 热插拔机制，实现了传统的物理热插拔和动态资源池。

为支持单级交换，CXL 对 HDM 解码器中 CXL.mem 地址区域的地址解码进行了标准化。分层解码遵循 PCIe 内存解码模型，允许在每个交换机上进行解码，避免主机或交换机完全解码在架构中的所有 agents。为支持多主机连接并启用设备池，每个主机都将 CXL 拓扑表示为一个虚拟层次结构（VH），其中包括 switch、主机端口的虚拟网桥以及具有设备资源的每个端口。如图 12 所示，每个主机都能看到一个单独的 VCS（虚拟 CXL 交换机），其中包括分配给该主机的设备的网桥。流量会根据 VH 中的活动虚拟网桥路由到设备。这就限制了 CXL 2.0 的有向树拓扑结构，每个主机和设备之间最多只有一条路径。此外，由于需要在交换机中跟踪每个 VH 的地址映射，CXL 3.0 克服了这一限制（第 5.3 节）。配置和更改 VH 将在第 4.2 节中介绍。

设备池建立在多主机 switch 支持的基础上，允许设备一次动态分配给一台主机。标准设备一次分配给一台主机，称为单逻辑设备（SLD）。CXL 还定义了多逻辑设备（MLD），允许将单个 CXL.mem 设备的资源划分为逻辑设备（最多 16 个），同时分配给不同的主机。MLD 中的每个逻辑设备都可分配给不同的主机。CXL 3.0 引入了名为 "动态容量设备 "的扩展，灵活性更高。MLD 中的每个逻辑设备 (LD) 都由一个标识符 (LD-ID) 标识。这种扩展只在交换机和设备之间的链路上可见，主机看不到。主机将 LD-ID 字段留空。CXL 交换机根据主机端口将 LD-ID 标签应用到主机的 CXL.io 和 CXL.mem 事务中。

由于交换、MLD 和潜在的不同类型内存（可能不是基于 DRAM），单个交换机中的资源可能会被超量占用，从而导致服务质量问题。例如，一台设备的低性能可能会导致使用交换机的所有 agent 出现拥塞。为缓解这一问题，CXL 2.0 在 CXL.mem 响应信息中引入了 DevLoad 字段，以告知主机在其访问的设备中观察到的负载情况。主机应使用此负载信息来降低向该设备发送 CXL 请求的速率。CXL 规范定义了一个参考模型，即在高负载或临界负载时降低注入速率，直到达到额定负载；在轻负载时，主机可提高注入速率，直到达到额定负载。

4.2 Pool management

池管理是指在运行时将 CXL 设备分配给主机。该标准使用术语 CXL Fabric Manager (FM) 来表示做出分配决策的应用逻辑和策略。实际上，FM 可以是在主机上运行的软件、嵌入在底板管理控制器 (BMC) 或 CXL 交换机内的固件，也可以是专用设备。FM 通过使用组件命令接口 (CCI) 将（逻辑）设备分配给主机。这既可以在带内进行，例如通过内存映射输入/输出（MMIO），也可以通过管理组件传输协议（MCTP）在带外进行。MCTP 支持多种带外通信，包括 SMBus/I2C、PCIe、USB 和串行链路。

FM 通过绑定命令将设备分配到主机，该命令需要四个参数：CXL switch ID、虚拟网桥 ID、物理端口 ID 和逻辑设备 ID（SLD 的逻辑设备 ID 为空）。FM 将此命令发送到指定的交换机，交换机会检查该物理端口当前是否未绑定。如果未绑定，交换机将更新其内部状态以执行绑定。然后，它会向主机发送 hot-add 指示，最后通知 FM 绑定成功。虚拟网桥和相关设备现在出现在主机的虚拟层次结构中。图 12A 和图 12B 之间显示了这种转换。

对于 MLD，FM 可能需要首先通过 Set-LD 命令配置逻辑设备。该命令根据内存粒度（如 256MB）和多个内存范围创建逻辑设备。当 FM 没有与 MLD 的带外连接时，可通过 CXL 交换机传输该命令。创建 LD 后，FM 可使用绑定命令将其分配给主机，并使用相应的 LD-ID 将其绑定。

MLD 多逻辑设备、LD 逻辑设备

要撤销设备分配，FM 使用 unbind 命令，该命令需要三个参数：CXL switch ID、虚拟网桥 ID 和 unbind 选项。解除绑定选项表示如何执行解除绑定，包括等待主机停用端口、hot-remove 并等待主机或强制 hot-remove 等选项。利用最后一个选项，FM 可以处理不合作的主机，例如由于故障或分配给第三方客户的主机。

除此处描述的三条命令外，FM 还支持 19 条其他命令。它们包括 QoS 控制，如在 MLD 内的逻辑设备之间分配带宽。这些命令还包括识别 switch 端口和设备以及查询和配置其状态的方法（见 表 205^[3]）。

4.3 Host Software Support

尽管大部分 CXL 都是通过主机外部的硬件和软件（如 FM）实现的，但主机软件在支持 CXL 方面仍发挥着重要作用。在高层次上，系统固件会枚举和配置启动时存在的 CXL 资源。操作系统（OS）枚举和配置运行时连接和分离的 CXL 资源，例如 hot-add 和 hot-remove 的内存地址范围。因此，操作系统在支持 CXL 2.0 方面发挥着重要作用。

2.0 支持热插拔，这需要操作系统相关驱动软件的支持、

传统上，资源拓扑和亲和性通过静态 ACPI 表进行通信。例如，NUMA 域在 SRAT 表中定义，内存带宽和延迟在 HMAT 表中定义。通常情况下，这些表由固件配置，固件在启动时获取所有资源的基本情况。在 PCIe 中，这个问题比较简单，因为插入设备不会影响系统映射的内存。而在 CXL 中，需要为运行时连接的内存传递特定于内存的资源特性。在 CXL 供应商和设备的生态系统中，事先定义配置是不可行的。CXL 2.0 引入了 Coherent Device Attribute Table（CDAT），该表描述了内部 NUMA 域、内存范围、带宽、延迟和内存使用建议 ^[47，48]。当内存（逻辑）设备在运行时被 hot-add 时，主机会读取相关的 CDAT 寄存器，操作系统会分配一个空闲的 HPA 范围，并对 HDM 解码器进行编程。

在 CXL 1.1 中，BIOS 可以像传统 PCIe 一样枚举和配置设备。具体来说，BIOS 固件使用 CXL 早期发现表检索主机桥接寄存器指针、内存窗口，设置内存地址映射，并对 HDM解码器 ^[47]进行配置。

5 CXL 3.0 PROTOCOL

为应对大型分布式系统中的数据共享的挑战（挑战 4），CXL 3.0 将 CXL 2.0 中引入的资源池扩展到更大规模，利用更大的 Flit 大小、低延迟和足够的带宽，为多达 4096 个终端设备提供多级交换和协议支持。终端设备可以是代表独立服务器或节点的主机 CPU、内存、加速器或任何其他 I/O 设备（如网卡）。如图 13 所示，总体目标是根据工作负载动态组合系统，以提供高能效性能和较低的总体拥有成本。为实现这些目标，CXL 3.0 引入了以下内容：

• 将每引脚带宽增加一倍，同时保持扩展到更大拓扑所需的平缓延迟。
• 支持 Fabric 拓扑： 这是负载存储互连标准的首创，因为该标准对事务之间的排序有限制。CXL 在任何源-目对之间都有多条路径，摆脱了树状拓扑结构的限制，这对扩展到数千台设备至关重要。这使得延迟更低、分段带宽更高、故障切换能力更强。
• 从 PCIe/CXL 设备直接点对点访问，由 Type-2/type-3 设备托管的一致性 HDM 存储器，如果不发生冲突，则无需涉及主机处理器。因此，延迟低、拥塞少、带宽效率高，这对大型系统至关重要。例如，在图 13 中，网卡到内存的直接 P2P 距离为 8 跳，而通过 CPU 的往返距离为 16 跳。
• 跨主机共享一致内存和信息传递： 这可以通过硬件或软件实现。共享一致性内存可使多个系统共享数据结构、执行同步或使用低延迟负载存储语义传递信息。信息传递也可以使用负载存储 CXL.io 语义（相对于延迟较高的网络语义）来完成。
• 近内存处理，允许在内存附近进行计算，以提高性能和能效。

5.1 Flit Formatting to support doubling of Data Rate to 64.0 GT/s

CXL 3.0 基于 PCIe 6.0 规范 ^[5,6,7]，使用 PAM-4（脉冲幅度调制 4 级）信令支持 64.0 GT/s。PAM-4 采用 4 个电压电平对每个单位间隔 (UI) 的两个比特进行编码，由于眼高和眼宽（即电压和时间）降低，因此错误率非常高 ^[13,14]。为了克服这一问题，PCIe 6.0 规范采用了 10-6 的首次突发错误率，并引入了 256 字节的 Flit（图 14a），其中由 236B 的 TLP 和 6B 的数据链路包 (DLP) 组成的有效载荷由基于 GF(28) 的 Reed-Solomon 码的 8B CRC 保护，而整个 250B 的有效载荷则由每路 2B 的 3 向交错单符号正确前向纠错码 (FEC) 保护^[7,14]。速率为 64.0 GT/s 的 CXL 3 使用相同的电气层和 256-B Flit，但做了一些修改。如图 9b 和图 9c 所示，对于 256B 大小的 Flit 的两种变体，它保留了与 PCIe 相同的 FEC 机制。

图 14b 显示了 CXL 3 中常规 256B Flit 的布局，其中 8B CRC 与 PCIe 6.0 相同。唯一的区别是 2B Hdr（Header，是 DLP 前两个字节的增强版本，用于可靠的 Flit 传输管理，如确认、重放请求、重放序列号）得到了增强，以指示 Flit 类型（CXL.io、CXL.cache+mem、ALMP、Idle）和可靠的 Flit 传输管理控制，并置于 Flit 的起始位置，以管道方式将 Flit 传输到相应的协议栈，而无需累积整个 256B Flit 以减少延迟。可选的延迟优化（LO）256B Flit，如图 14c 所示。LO Flit 被细分为两个子 Flit，每个 128B，奇数 Flit half 中有 FEC，偶数 Flit half 中有 2B Flit Hdr。每个 Flit half 中都有一个 6B CRC。如文献 ^{[5, 13, 14]} 所述，6B CRC 源自 8B CRC，以减少 gate count。第一个 6B CRC 保护偶数 Flit half 中的 2B Flit Hdr 和 120B 数据，第二个 6B CRC 保护奇数 Flit half 中的 116B 数据。如果偶数 Flit-half 的 CRC 通过，就可以按顺序处理，而无需等待奇数 Flit-half 处理。如果奇数 Flit half 的 CRC 通过，则可以处理奇数 Flit half，前提是偶数位已经处理完毕（即没有 CRC 错误）。由于 CRC 逻辑约为 10 级，而 FEC 为 50 级^[14]，因此在 x16 链路上，先应用 CRC 有助于将延迟减少 2 纳秒^[13]。此外，128B 以上的 CRC 使 accumulated 延迟略好于 32 GT/s 的 68-B Flit 累积延迟。如果检测到错误，则 accumulated 整个 Flit，应用 FEC，然后再次应用 CRC。有关 Flits 以及 FEC 和 CRC 机制的详细信息，请参阅 [5、7、13、14]。

使用的 Flit 类型（68B、256B、LO）是在协商 CXL 协议采用 8b/10b 编码时预先协商确定的。任何 CXL 设备都必须支持 68B Flit。如果 CXL 设备支持 64.0 GT/s 数据传输速率，它还必须公布 256B Flit 模式，而对 LO Flit 模式的支持则是可选的。如果链路的所有组件（两个设备以及中间的任何 Retimer）都支持 LO Flit 模式，则会选择 LO；否则，如果所有组件都支持 256B Flit，则会选择 256B Flit 模式；否则，将支持 68B Flit 模式。一旦在早期协商过程中选择了 Flit 模式，无论运行的数据速率如何，都将使用该模式。假设我们选择了 LO Flit 模式，因为链路中的所有组件都支持该模式和 64.0 GT/s，但如果链路以 32.0 GT/s 运行（例如，在 64.0 GT/s 时出现节能速度下移或链路稳定性问题），则仍将使用 LO Flit 模式。

对于 CXL.io，"数据 "的最后 4B 将用于 DLLP（相当于 PCIe 6.0 ^[7,14] 中 6B DLP 的最后 4B）。这样，在 256B Flit（与 PCIe 6.0 Flit 相同）模式下，就有 236B 用于 TLP，在 LO Flit 模式下，有 232B 用于 TLP。对于 ALMP，大部分 "数据 "字段是保留的。对于 CXL.cache-mem，slots 如图 15 所示。H slots 和 G slots的用途与 68-B 相同（即 H slots或标头slots仅用于标头，而 G slots或通用slots用于标头或数据），但 H slots中的额外 2B 用于构建更大的拓扑结构。HS slots 只有 10B ，用于 2DRS 或 2NDR 等小型报头。

5.1 Protocol extensions with CXL 3.0: Unordered I/O (UIO) and Back-Invalidate (BI) for fabric support

第 3 节中描述的 PCIe 排序规则排除了任何非树状拓扑结构，这意味着 CXL 网络中的任意两个节点（主机或设备）之间只有一条路径。我们需要在任何一对源-目的节点之间建立冗余的多条路径，以创建性能良好的大型分布式系统。由于软件依赖于 "生产者-消费者"排序模型，因此 CXL 协议需要在适应非树状拓扑结构的同时保留这种排序模型。CXL 3.0（因此也是 PCIe）通过在一个或多个不同的虚拟通道（VC，参见第 3.1 节）上引入 "无序 "读/写/完成事务，并将排序执行功能仅转移到源节点，从而解决了这一难题。每个虚拟通道独立于其他虚拟通道，每个虚拟通道包括三个流控制（FC）类别： Posted（P）用于内存写入等事务，Non-Posted（NP）用于内存读取等事务，Completions（C）用于完成每个 NP 事务，详见第 3.3 节。其基本思想是，每个 UIO 写入都有一个完成（C FC 类中的 “UIO 写入完成”）。因此，UIO 写入从根本上说是 non-posted，即使它是在 P FC 类上，以便让源执行排序。因此，生产者（如图 7a 中的设备 X）必须等待所有 "数据 "完成后，才能向 "标志 "写入信号，表示数据可用。UIO 读取就像普通的内存读取一样，它可以获得一个或多个完成（C FC 类中的 “UIO 读取完成”），并带有或不带数据以及状态（包括错误）。因此，在 UIO VC 中，P 和 NP 各只有一种类型的事务（分别是 UIO 写和 UIO 读），而 C 有三种类型的事务（UIO 写完成 - 无数据、UIO 读完成（带数据）和 UIO 读完成 - 无数据）。此外，如图 16 所示，跨 FC 和在 FC 内部进行的事务没有排序要求。这样，CXL.io（和 PCIe）事务就能在源-目的对之间具有多条路径的拓扑中的任意路径上发送，并仍然执行生产者-消费者排序语义。VC0 将始终用于传统的非 UIO 排序，以实现路由树拓扑的向后兼容性，VC1-VC7 中的一个或多个 VC 可用于 UIO 流量，UIO 流量可使用任何路径进行任何传输。

5.2 Peer-to-peer communication between devices and mapping large chunks of local memory

CXL 3.0 引入了一个新流程，在 CXL.mem 中增加了两个通道： 在 S2M 方向上的 Back-Invalidate (BI) 和在 M2S 方向上的响应 BI-Rsp。这实现了三组用途：通过 CXL.io UIO 访问 HDM-DB 内存，实现 CXL/PCIe 设备之间的直接点对点通信（如图 17 所示）；Type-2 设备实现窥探过滤器并将大块本地内存映射到 HDM-DB 区域的能力（如图 18a 所示）；以及跨多个独立主机的硬件强制连贯共享内存（如图 18b）。在 CXL.mem 中设置 BI 的理由是确保不存在避免死锁所需的其他依赖关系。

利用 UIO 和 BI，设备可以直接访问 HDM-DB 内存，而无需通过主机 CPU。连接到 switch 的加速器设备需要访问直接连接到 switch 的映射到 HDB-D 区域的内存（图 17a），需要通过主机 CPU（图 17b）使用 CXL 2.0 流程，这涉及主机从内存获取数据，并在完成设备访问之前解决一致性流程。但是，使用 CXL 3.0 流量时，设备会在 UIO VC 中使用 CXl.io 发送相同的内存读写事务。switch 不会将这些 UIO 事务路由到主机。如果高速缓存行的状态为 I 或 S（UIO 读取）或 I（UIO 写入），则 UIO 事务直接由内存提供服务；否则，内存控制器将使用 BI 流程反向侦查主机处理器，如图 17c 所示。正如我们稍后将看到的，即使需要 BI，这种新机制也比现有的将所有请求发送到主机的方法更节省带宽，因为后者会造成更多的流量和额外的延迟。

UIO 与 BI 的结合实现了 I/O 一致性模型，可以扩展到大量设备。那些需要缓存内存的设备仍可在需要时使用 CXL.cache 语义，其余情况下则使用 UIO。这就减少了窥探开销，也减少了一直进入主机处理器的延迟。

BI 的第二个方面是使 Type-2 设备能够拥有一个窥探过滤器，而不是拥有一个完整的目录和调用现有的 bias-flows。图 18a 演示了这一点，在图中，如果新请求遇到容量缺失，Type-2 设备会调用 BI 流程，从其窥探过滤器中删除缓存行。

如图 18b 所示，BI 机制还能在多个主机间实现共享和硬件强制的一致性内存。在这里，内存设备（GFD/MLD）维护一个目录（或窥探过滤器），以跟踪一致性共享内存中高速缓存行的所有权。因此，当主机 1 获得作为共享副本的高速缓存行 X 的所有权时，它会将目录从 "I "状态更新为 "S "状态，主机 1 为共享者。当主机 3 请求共享状态下的同一高速缓存行 X 时，它会提供数据并更新 X 的目录，以表明主机 1 和主机 3 都共享该数据。当主机 4 请求独占副本时，它会同时向主机 H1 和主机 H3 发出 Back Invalidate（回无效），等待这两个主机的响应，以确保主机 1 和主机 3 已将 X 的副本无效，并更新其目录，将 X 标记为主机 4 的 “E”，然后将数据和所有权发送给主机 4。该内存设备可以是多逻辑设备（MLD）或 GFAM 设备（GFD）。

Back-Invalidation 在协议层和链路层创建了两个额外通道： BISnp 和 BIRsp。这些通道是确保协议无死锁所必需的, 如图19 添加了 BISnp(S2M BISnp)与图 11-B 中 CXL 1.1/CXL 2.0 依赖关系图的比较。BIRsp 是预先分配的，因此对于依赖关系图中，它被合并到图中的 L3 RSP 中。

5.3 Port Base Routing (PBR) and Extensions for CXL Fabric

为了能扩展到 4096 个端点（主机或设备）和非树（多路径）网络拓扑，CXL 3.0 增加了一种新的可选协议格式，称为基于端口的路由（PBR）。其理念是，与 CXL 2.0 相比，PBR 是一种比 CXL 2.0 的分层路由（第 4.1 节）更简单、更可扩展的信息。例如，分层路由需要 switch 知道每个主机的虚拟分层和地址映射。CXL 3.0 在大多数端点与第一个交换机之间的链路中继续使用标准的 CXL 2.0 信息（如图 13 中的叶子到端点链路）。连接设备或主机的第一个 switch 端口被称为 “边缘端口”，因为它在标准报文（HBR）和 PBR 报文之间的转换中起着特殊作用。PBR 路由本身用于 switch 间链路，如图 13 中的 Spline 到 Spline 和 Leaf 到 Spline 链路）。从软件角度看，只有 Fabric 管理器需要配置交换机网络；主机上运行的软件只需看到一个平面拓扑，该拓扑以第一个 switch 端口为终点。

… 已经糊涂了，省略，未完，事后再补

5.4 CXL.cache Device Scaling Limits

… 已经糊涂了，省略，未完，事后再补

6 SURVEY OF CXL IMPLEMENTATIONS

CXL 生态系统需要 CPU 和设备的支持。虽然 CXL 3.0 产品预计将在几年内面世，但 CXL 1.1 和 CXL 2.0 已部署在多个商用产品中。英特尔从 Sapphire Rapids（SPR）CPU 和 Agilex7 FPGA 开始支持 CXL，支持所有三种协议。AMD 宣布 Genoa CPU 和 SmartNIC 设备支持 CXL ^[52]，ARM 宣布 V2、N2 和 E2 系列 CPU 支持 CXL 2.0 ^[57]。

在设备方面，Synopsys、Cadence、PLDA/Rambus、Mobiveil 等 IP 供应商已经展示了与 SPR CPU 的互操作性 ^{[8、21、22、23、24]}。三星制造了一个 CXL 1.1 内存扩展设备，并公开分享了其基准测试结果^[54]。美光拥有 CXL 1.1 近内存计算设备的原型^[53], 国内 Montage ^[55] 和 SK Hynix ^[56] 已经发布了 CXL Type-3 内存设备。学术研究也独立复制了 SPR ^{[50]<、sup> 上的结果，并实现了定制的 CXL 硬件和软件原型 [51]。}

根据我们对参考文献的调查，我们发现 SPR 的详细程度非常高。事实上，它是目前唯一一款报告了所有三种协议结果的 CPU。这也在意料之中，因为英特尔捐赠了 CXL 1.0 规范，并一直引领着已公开报告的生态系统的互操作性。由于公开的性能数据主要针对 SPR CPU，而设备功能和性能高度异构，因此我们的调查侧重于 SPR 实现的性能，以此作为 CXL 实现的代表性性能指标。

图 20 是具有代表性的 CXL IP 微体系结构，其中包含 PIPE ^[25]、LPIF ^[26]、CPI ^[27] 和 SFI ^[28]等行业标准接口，用于 CXL EP 以及 SPR 等主机处理器。图 11a 中的内存大小、高速缓存层次结构和高速缓存大小只是提供了一个比例，而不是精确的大小。最后一级高速缓存（LLC）包括层次结构中的低级高速缓存以及与 CPU 内部 PCIe/ CXL.io 堆栈相关的写高速缓存。LLC 还覆盖所有 CXL 设备的缓存。窥探过滤器为主代理提供了何时窥探特定 CXL 设备的信息。无论是与 CPU 本地连接的内存（如 DDR），还是属于映射到系统地址空间的 CXL 设备的内存，都属于主代理的权限范围（图 11a 中用蓝色和绿色表示）。

6.1 Measured Latency of CXL 1.1 implementations

图 20 中的 PHY 模块具有模拟电路，负责数据的序列化/反序列化。它通过 PIPE 的并行接口与 PHY 逻辑块连接（32.0 GT/s 链路，每车道 1GHz 32 位）。物理层逻辑模块负责链路训练、均衡、（去）扰码、预编码、线路反转、链路宽度衰减、极性反转、时钟域交叉、时钟补偿、de-skew 和物理层成帧。

LPIF 芯片到芯片接口^[26]将物理层逻辑连接到 Arb/Mux 模块，再从 Arb/Mux 模块连接到多个链路层。Arb/Mux 块在两个堆栈（CXL.io 和 CXL.cache+mem，见第 3.2 节）之间执行仲裁和多路复用，并将物理层虚拟化为独立的链路层堆栈，以进行电源管理 ^[1,2,3,8]。

链路层（如图 20 所示）执行 CRC 校验、管理 credits 并处理链路层重试，而事务层则执行 Flit 包装/解包、将事务存储在适当队列中并处理事务。在 CXL 3.0 实现中，当协商 256 字节或 128 字节延迟优化 Flit 时，逻辑物理层将执行所有堆栈通用的 CRC 和重放功能，而每个堆栈的链路层将继续为该堆栈的 68 字节 Flit 模式提供相同功能，以实现向后兼容性。如图 20 所示，CXL.io/PCIe 事务层对事务进行排队、处理并执行生产者-消费者排序 ^[8]。

图 20 详细介绍了 CXL.cache+mem 路径，包括延迟。延迟包括发送和接收路径。与标准 PCIe PHY 逻辑实现相比，这包括几种延迟优化技术, 这些技术包括绕过 128b/130b 编码（如果在链路培训期间协商好^[3]）、绕过支持降级模式所需的逻辑和串行化触发器（如果一个或多个 Lanes 出现问题，或如果为电源管理而调用）、如果 Lanes 与 Lanes 之间的偏移小于内部 PHY 逻辑时钟周期的一半，则绕过纠偏缓冲器、采用预测策略处理弹性缓冲器中的条目（而不是等待每个条目的时钟域同步握手）等。PHY 和 PHY 逻辑延迟的不同取决于部署的是通用参考时钟还是独立参考时钟。如果组件位于单个机箱内，我们希望使用延迟为 15 纳秒的通用参考时钟。但是，如果链路跨机箱连接，我们希望使用独立参考时钟，由于时钟交叉和同步 Hdr 开销，会造成 4 纳秒的延迟损失。

在通用参考时钟模式下，从 SERDES 引脚到内部应用层（CPI 或等效接口）再返回的总延迟为 21 ns，在独立参考时钟模式下为 25 ns。一家 IP 供应商也报告了 25 ns 的往返延迟^[15]，估计是在公共时钟模式下。我们预计，通过更严格的工程设计和工艺改进，后续几代产品将缩短这一延迟时间。由于各种模块的位置、工艺技术和物理层设计类型造成的传播延迟等因素，预计延迟会有细微变化。例如，与基于 DFE/CTLE（决策反馈均衡器/连续时间线性均衡器）的接收器设计相比，现有的基于 ADC（模数转换器）的 PHY 可能会增加约 5 ns 的延迟。

在 21/25 纳秒的往返延迟下，即使考虑到因设计实践不同而产生的额外 0-10 ns 的设计差异，以及保守的 15 纳秒往返飞行时间（含 retimer）^[17,18]，我们预计通过 CXL 链路进行内存访问的延迟总计为 52-75 纳秒（2x21-25 + 0-10 + 15）。总之，CXL 规范中针对 DRAM/ HBM 存储器的 CXL.mem 访问的引脚到引脚延迟目标为 80 纳秒，窥探的响应时间为 50 纳秒^[3,4,6]，这在实践中是可以实现的。空载到使用的延迟预计在 150 到 175 纳秒之间。这与 CPU-CPU 缓存一致性链路上的内存访问相当，也在 CPU 的延迟工作点范围内^[20]。对于 CXL.io，如同在 PCIe 中一样，在 Xeon 中，从引脚到引脚的往返延迟约为 275 ns，其中包括 LLC 错失和 IOTLB 命中（由于设备的 TLB 由 CXL 强制规定，我们预计延迟将与 IOTLB 命中类似）。

6.2 Projected Latency of large system topologies with CXL 3.0 and beyond

采用 CXL 的更大拓扑结构可通过 switch 以及 “共享存储器控制器”（SMC）等设备实现，SMC 是 CXL switch 与多个存储器控制器的组合^[9]（图 17a），具有多域功能和 PBR 路由功能，可用于扩展。CXL switch 与往返的延迟加法器预计为 2x21-25+10ns（内部解析/查找）+10ns（线上飞行时间）=62-70ns ^[18，58]。表 2 总结了不同访问/系统配置下 CXL.cache 和 CXL.mem 的各种延迟。

6.3 Realizable Data Bandwidth

x16 CXL 链路在 32.0 (64.0) GT/s 数据速率下，每个方向的原始带宽为 64 (128) GB/s。然而，除了实际有效载荷（包括报头、CRC 和协议 ID/ Flit HDR）外，链路传输数据还会产生协议开销（见第 3.2 节）。此外，不同的工作负载会产生不同的请求和响应模式，对 Flit 插槽的占用也不尽相同。因此，可实现的数据带宽是由工作负载、协议和底层 IP 之间的多层交互决定的。我们首先讨论三种协议（CXL.io、CXL.cache 和 CXL.mem）的共同开销，然后讨论常见流量组合下的可实现数据带宽。

对于 68 字节 Flit 模式下的 CXL.io，假设 DLLP 开销为 2%，在同步 Hdr 开启或关闭的情况下，效率分别为 0.906 和 0.92 ^[8]。请注意，由于 PCIe 不包含 Flit 开销，因此本地 PCIe 的效率要高出 6%。对于具有 256B 和 128B LO Flit 的 CXL.io，Flit 开销为 6B (Hdr, DLLP) + 6B (FEC) + 8B for 256B / 12B for 128B LO for CRC ^[10,11]，256B Flit 总开销为 20B，128B LO Flit 总开销为 24B；链接效率= (256-20 或 24)/256 = 256B 为 0.92，128B LO Flit 为 0.91 ^[8,9]。

68 字节 Flit 模式（CXL 1.1-2.0）下的 CXL.cache+mem 有三个常见开销： 128/130 表示同步 Hdr 开销（除非支持同步 Hdr 旁路），374/375 表示共同时钟 SKP 有序集造成的带宽损耗（其他模式更高），64/68 表示 Flit 开销（协议 ID 和 Flit CRC 各 2 字节）。因此，在同步 Hdr 开启时，链路效率（Linkefficiency）为 0.924；在同步 Hdr 关闭时，链路效率（Linkefficiency）为 0.939，其中包括信用和链路可靠性机制，如 Ack/Nak（Ack：确认，Nak：负确认）^[8]。

对于 CXL.cache 和 CXL.mem 的 256 字节和 128 字节延迟优化 (128B LO) Flits，整体链路效率为 15/16 (=0.938)，因为有 15 个时隙，一个等效时隙用于 FEC/ CRC/ Hdr 等^[8,9]。 CXL.cache 和 CXL.mem 的时隙即使在考虑了可扩展性的额外比特后也是相似的。因此，正如稍后所见，三种 Flit 类型的带宽效率趋于相似。

在 CXL.io 和 PCIe 中，有三种常见的流量组合可作为性能基准：100% 读取、100% 写入和 50-50 读写。表 3：针对 CXL 2.0 68B Flits 和 CXL 3.0 256B 和 128B Flits 的不同流量组合和有效载荷大小的 CXL.io 可实现带宽根据 [8] 中描述的方法，总结了三种流量组合中每种 Flit 类型的不同有效载荷大小的 CXL.io 可实现带宽。典型的工作负载包括小型有效载荷（4B-32B）和中大型有效载荷（64B 及以上）的混合。尽管商用系统为客户端 CPU 部署的最大有效载荷大小为 128B（或 32 个双字，又称 DW），为服务器 CPU 部署的最大有效载荷大小为 256B/512B（64/128 DW），但为了完整起见，我们还是提供了最大 4KB （1024 DW）有效载荷大小的预测值。

CXL.cache： 设备使用 D2H 中的 RdCurr 从内存读取高速缓存行时，会产生一个 H2D Data_Hdr 和 H2D Data。每个 H2D Data_Hdr 为 24 位，一个 slots 可容纳 4 个，即一个 slots 可传输 4 个高速缓存行。每个 H2D 数据为 64 字节，因此需要 4 个 slots。因此，x16 CXL 设备从处理器读取 68 字节 Flit 格式的数据时，可获得 (16/17) 0.9464 GB/s = 56.6 GB/s 的带宽。对于 256 字节和 128 字节延迟优化 Flits，数据是瓶颈，因为每个 H slots 最多可以有 4 个 H2D Data_Hdr。对于 256 字节的 Flit，我们只有 14 个插槽可用于数据，可容纳 3.5 个高速缓存行。因此，256-Byte Flit 的可实现带宽为 (14/16) *128=112 GB/s，128-Byte Latency-Optimized Flit 的可实现带宽为 (13/16) *128=104 GB/s^[8，9]。

对于写入，设备会发出 D2H 请求 (RdOwn)。这将产生一个带数据的 H2D 响应。然后，设备发出 D2H Dirty Evict，获得 H2D Resp (Wr Pull)，从而执行 D2H Mem Wr。这样，D2H 方向上每一行缓存数据就会产生 3 个 Hdr（D2H Req RdOwn、D2H Dirty Evict + Data Hdr）。对于 68 字节 Flit，3 个 Hdrs 占用两个 slots（例如，D2H Req RdOwn+ Data Hdr、D2H Dirty Evict），因此每个方向的速度为 (4/6) 0.9464 GB/s = 40 GB/s。对于 256 字节和 128 字节延迟优化 Flit 格式，D2H 方向上有 4 个 G slots 和 2.25 个任意 slots（Req 和 Evict Dirty slots 各一个，Data_Hdr slots 为 1/4，因为任意 slots 中可以有 4 个，因此可实现的数据带宽为（4 个数据 slots /6.5 个总插槽）*(15/16)*128 = 73.8 GB/s^[8,9]。

CXL.mem： 从 CPU 读取内存在 M2S（第 3.5 节）中作为 MemRd 发送。对于 3 型设备，其响应包括 S2M DRS Hdr (MemData) 和 4 个数据 slots (64B)。如果设备是 2 型设备，则需要额外的 S2M NDR 来完成 (Cmp)。对于写入，CPU 发送一个 M2S Req (MemWrite) 和 4 个数据 slots，生成一个 S2M NDR 作为 Cmp。

为了最大限度地提高效率，实现时会尝试将多个标头打包到一个 slots 中。CXL 规范允许在一个插槽中对各种报头进行不同的打包排列，这些排列使用所谓的 H* 符号表示。例如，在 68 字节 Flits 中，H3 表示一个 slot 中包含一个 S2M DRS + 一个 S2M NDR；H5 表示一个 slot 中包含两个 S2M DRS。图 21a 和图 21b 展示了使用 2R/1W 的 2R/1W 类型 3 和类型 2 设备，在 68 字节 Flit ^[8] 下，2 读 + 1 写的重复模式结果。我们仅介绍 S2M 方向，因为它决定了最高的可实现带宽 ^[8]。图 21c 和图 21d 表示在相同的 2R/1W 流量组合下，使用 256 字节和 128 字节延迟优化 Flit 的可能位置^[8]。我们希望未来的研发能进一步完善这种打包算法（第 7 节）。

有几种具有代表性的工作负载可用于评估内存带宽性能。100% 读取，表示为 1R0W；100% 写入，表示为 1R1W，因为每个高速缓存行的写入都会在更新前读取内存内容；等量读取和写入，表示每次写入都会读取 2 个高速缓存行。表 4 总结了不同流量组合下 CXL.mem 的可实现带宽。详细推导见 ^[8]。当只有读取而没有写入时，M2S 方向上没有真正的数据传输（只有读取请求）。因此，该方向的数据带宽为 0，而 S2M 方向则主要是数据（2DRS 有 1 个数据头插槽，2 个高速缓存行有 8 个数据插槽）。因此，数据效率为：链路效率 0.939 x 插槽效率 8/9 x 64 GB/s 原始带宽 = 53.5 GB/s。其他条目也采用类似方法，详见 ^[8]。SPR Flit 包装逻辑中的调度程序遵循 CXL.mem 的贪婪算法，优先将 H3 用于 Flit 中的第一个 16B 插槽，然后是 H5，如果计划发送的数据少于 64 字节，则在剩余的 Flit 中填充数据。如果计划发送 64 字节或更多数据，则会调度一个全数据 Flit。采用这种方法后，68-B Flit 模式的测量带宽非常接近表 4 中的数字。

对于 256 字节标准或 128 字节延迟优化 Flit，设计人员需要考虑更多限制。例如，H/HS-slot 可能只用于数据头。调度将确保在有数据（或报头）要发送时，G-slot 不会空着。因此，先于数据发送的报头将被优先考虑，并择机放置在 H/HS-slot中，同时确保调度的数据不超过 5 个缓存行。我们还确保其他报头也能向前推进。

7 DISCUSSION

我们讨论了 CXL 对计算领域的四种影响，然后概述了一系列初步的未来发展方向。

7.1 Implications for the compute landscape

影响 1：CXL 对设备的网络效应。与 PCIe 相比，CXL 显著扩展了使用模式和功能，例如，延迟更低、池化和硬件一致性。这些优势促使 I/O 设备采用 CXL。最初，这可能最适用于加速器和内存/存储设备，因为CXL.cache和CXL.mem可带来巨大的性能提升，而CXL池可节省总体拥有成本。最终，CXL 的采用可能会对网络方面产生影响，网络接口等其他 IO 设备必须提供 CXL，因为 CXL 将成为通用访问机制。近内存或内存处理系统同样有可能采用 CXL，因为 CXL 强大的高速缓存一致性支持使其编程模型大大简化。

影响 2：内存向封装内并行总线和封装外 CXL 迁移。与本地连接内存（DDR）相比，CXL 具有基本的扩展和效率优势。CXL 的每引脚带宽高出 8 倍，容量也更大，因此具有显著的扩展优势。内存池和异构内存介质使 CXL 具有成本优势 ^[58]。CXL 还有助于散热，因为与 DDR 相比，它能实现更长、更灵活的主板布线。这些优势是以比 DDR 更高的空闲延迟（通常是延迟的两倍）为代价的。在考虑加载延迟时，CXL 由于其带宽优势可能比 DDR 性能更好，而封装内存的性能将明显优于两者。一个自然的预期是，越来越多的内存将迁移到 CXL 和封装内存。最终，CXL 将成为 CPU 和加速器的唯一外部内存连接点。

影响 3：CXL 将发展成为机架或集群级互连。与当今基于以太网和 InfiniBand 的数据中心网络相比，CXL 可将延迟降低一个数量级。此外，CXL 的连贯内存共享和细粒度同步可显著提高分布式系统的性能，适用于大型机器学习模型和数据库等关键工作负载。不过，CXL 需要专用布线，对电缆长度、适配器和 retimedr 的使用等有严格要求。这导致成本大大增加，灵活性也比现在的数据中心网络低。因此，CXL 有可能部署在较小的范围内，如机架内或跨几个机架（集群或 pod）。例如，当前的财务模型指出，子机架 CXL 部署是总体拥有成本的 sweet spot ^[58]。随着标准化带来的成本改善，CXL 的应用范围可能会扩大，但 CXL 不太可能取代以太网成为整个数据中心的网络标准。

影响 4：CXL 将实现高度可组合系统。可组合性意味着可在运行时动态组装组件和资源，并将其分配给工作负载或虚拟机。我们预计，内存设备和 IO 设备（如网卡、加速器和存储设备）都将发展出多主机功能，允许通过 CXL 将其容量的一部分动态分配给各个主机。由于增加了多路复用的机会，聚合和池化设备大大提高了资源利用率，从而降低了成本。这种设计还有利于通过共享内存、消息传递和 CXL 点对点通信加速分布式系统。不过，可组合系统仍有别于将通过 CXL 连接的所有资源视为一个单一的大系统。工作负载仍然倾向于本地化，并尽可能少地跨越 CXL 链接，以最大限度地减少一致性流量和任何故障的爆炸半径。

7.2 Future Directions

CXL 开启了计算机科学与工程领域的研究方向。在计算机体系结构中，CXL 为新内存控制器功能的原型设计和部署开辟了道路^[61]，例如自适应 DRAM 刷新以节省功耗和提高性能^[62,63]，低成本提高可靠性^[64]，以及减少内存浪费^[65,66]。外部存储器控制器的发展可以独立于主 CPU，而且成本较低，有利于加快迭代和定制。研究还可探讨对 CPU 架构的影响。例如，随着内存延迟的增加和高速缓存线的增多，人们可能会期待不同的预取和缓冲区大小策略，以及对减少内存访问延迟的更大兴趣^[69,70]。另一个挑战可能是延迟命中的影响，这需要更严格的模拟和建模^[60]以及不同的缓存管理策略^[59]。

在计算机系统中，CXL 内存池将引发本地和分布式内存管理的变革。例如，面对来自远程主机的内存压力，我们需要能够优先处理工作负载并保证性能的机制。我们可能还需要系统级方法来缓解分布式内存结构中的拥塞和故障。例如，CXL 标准中的 QoS 目前仅限于 CXL.mem，无法解决结构拥塞问题。工作负载调度也需要发展，以支持可组合性，与现有的数据中心设计相比，设计空间大幅扩大，定位的定义也有所不同。

在计算机工程领域，研发工作需要继续缩短 CXL 存储器、加速器和 switches 的延迟时间，以扩大 CXL 的应用范围。现在有很多机会，包括迭代工程 CXL 构建模块、利用工艺进步（第 6.1 节）和更好的打包算法（第 6.3 节）。生态系统还需要制定严格的方法来控制误差和管理 CXL 增加的爆炸半径。使用负载存储语义处理故障和拥塞热点与网络应用的限制条件不同，后者可以处理丢失的数据包以及完全失序的数据包交付。最后，CXL 还可以进一步增强和部署，以扩展到多个机架，并通过动态故障切换和更细粒度的服务质量 (QoS) 增强功能为多个应用提供高可靠性、低延迟的负载存储访问，这些功能将纳入未来的规范修订中。通过 Universal Chiplet Interconnect Express（UCIe）retimers ^{[10、50、74、75、76]}实现的协同封装光学技术，我们有望实现在数据中心构建从机架到 pod 的可组合和可扩展系统的愿景，从而实现具有显著总体拥有成本优势的高能效性能。

7.3 Conclusions

CXL 解决了行业面临的重大挑战，同时遵循开放、简单和向后兼容的设计理念。这使得 CXL 成为整个行业的通用标准，受到广泛关注。所有这些因素使得 CXL 也成为学术界的一个热门研究领域。我们希望本教程既能作为该标准的介绍和起点，也能作为研究思路的基础。

8 REFERENCES

1. D. Das Sharma, “Compute Express Link”, white paper, Compute Express Link Consortium, March 2019
2. CXL Consortium, “Compute Express Link 1.1 Specification”, July 2, 2019
3. CXL Consortium, “Compute Express Link 2.0 Specification”, Sept 9, 2020
4. D. Das Sharma and S. Tavallaei, “Compute Express LinkTM 2.0”, white paper, CXL Consortium, Nov 2020
5. CXL Consortium, “Compute Express Link 3.0 Specification”, www.computeexpresslink.org, Aug 2022
6. D. Das Sharma and I. Agarwal, “Compute Express Link 3.0”, white paper, CXL Consortium, Aug 2022
7. PCI-SIG, “PCI Express® Base Specification Revision 6.0, Version 1.0”, Jan, 2022
8. D. Das Sharma, “Compute Express Link®: Enabling Heterogeneous Data-Centric Computing with Heterogeneous Memory Hierarchy”, IEEE Micro, Mar-Apr 2023
9. D. Das Sharma, “Novel Composable and Scale-out Architectures using Compute Express LinkTM”, IEEE Micro, Special Issue on Interconnects, Special Issue on Hot Interconnects 29, Mar-Apr 2023
10. D. Das Sharma, “Transforming the Data-Centric World”, Keynote, Flash Memory Summit, Santa Clara, CA, Aug 3, 2022.
11. D. Das Sharma, “Evolution of Interconnects and Fabrics to support future Compute Infrastructure”, Opening Keynote in Open Fabrics Alliance Workshop, March 2021
12. D. Das Sharma, “The Compute Express Link (CXL)* open standard is changing the game for cloud computing”, Opening Keynote in IEEE Hot Interconnects, 2021
13. D. Das Sharma, “A Low-Latency and Low-Power Approach for Coherency and Memory Protocols on PCI Express 6.0 PHY at 64.0 GT/s with PAM-4 Signaling”, IEEE Micro, Mar/ Apr 2022
14. D. Das Sharma, “PCI Express 6.0 Specification: A Low-Latency, High-Bandwidth, High-Reliability, and Cost-Effective Interconnect With 64.0 GT/s PAM-4 Signaling”, IEEE Micro, Jan/ Feb 2021
15. PLDA, https://www.brighttalk.com/webcast/18357/420129/breaking-the-pcie-latency-barrier-with-cxl, July 16, 2020
16. Microchip Inc., “XpressConnectTM PCIe® Gen 5 and CXLTM Retimer Family”, Nov 2020
17. H. AL Maruf et al, “TPP: Transparent Page Placement for CXL-Enabled Tiered Memory”, June 2022
18. H. Li et al, “Pond: CXL-Based Memory Pooling Systems for Cloud Platforms”, ASPLOS ’23, 2023
19. CXL Specification. Available at https://www.computeexpresslink.org/download-the-specification. Accessed 1/29/2023.
20. Lim, Kevin, et al. “Disaggregated memory for expansion and sharing in blade servers.” ACM SIGARCH computer architecture news 37.3 (2009): 267-278.
21. Synopsys Inc, https://news.synopsys.com/2020-10-13-Synopsys-Demonstrates-Industrys-First-PCI-Express-5-0-IP-Interoperability-with-Intels-Future-Xeon-Scalable-Processor, Oct 13, 2020
22. Synopsys Inc, “Compute Express Link (CXL)”
23. Mobiveil, https://www.globenewswire.com/news-release/2020/12/02/2138545/0/en/Mobiveil-Announces-Compute-Express-Link-CXL-2-0-Design-IP-Successful-Completion-of-CXL-1-1-Validation-with-Intel-s-CXL-Host-Platform.html, Dec 2, 2020
24. PLDA, https://www.brighttalk.com/webcast/18357/420129/breaking-the-pcie-latency-barrier-with-cxl, July 16, 2020
25. Intel Corporation, “PHY Interface for the PCI Express, SATA, USB 3.1, Display Port, and Converged I/O Architectures”, Version 5.1, 2018
26. Intel Corporation, “Logical PHY Interface (LPIF) Specification”, Version 1.0, March 2019
27. Intel Corporation, “CXL-Cache/Mem Protocol Interface (CPI)”, Rev 0.7, Mar 18, 2020
28. Intel Corporation, “Streaming Fabric Interface (SFI)”, Rev 0.7, Mar 27, 2020
29. Guo, Jing, et al. “Who limits the resource efficiency of my datacenter: An analysis of Alibaba datacenter traces.” Proceedings of the International Symposium on Quality of Service. 2019.
30. Tirmazi, Muhammad, et al. “Borg: the next generation.” Proceedings of the fifteenth European conference on computer systems. 2020.
31. Cortez, Eli, et al. “Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms.” Proceedings of the 26th Symposium on Operating Systems Principles. 2017.
32. Zhang, Qizhen, et al. “Redy: remote dynamic memory cache.” Proceedings of the VLDB Endowment 15.4 (2021): 766-779.
33. Gu, J., Lee, Y., Zhang, Y., Chowdhury, M., & Shin, K. G. (2017, March). Efficient Memory Disaggregation with Infiniswap. In NSDI (pp. 649-667).
34. Liu, Huan. “A measurement study of server utilization in public clouds.” 2011 IEEE Ninth International Conference on Dependable, Autonomic and Secure Computing. IEEE, 2011.
35. Berger, Daniel, et al. “Research Avenues Towards Net-Zero Cloud Platforms”. NetZero 2023: 1st Workshop on NetZero Carbon Computing.
36. Zhang, Chaojie, et al. “Flex: High-availability datacenters with zero reserved power.” 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2021.
37. Verbitski, Alexandre, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, and Xiaofeng Bao. “Amazon aurora: Design considerations for high throughput cloud-native relational databases.” In Proceedings of the 2017 ACM International Conference on Management of Data, pp. 1041-1052. 2017.
38. Alizadeh, Mohammad, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan. “Data center tcp (dctcp).” In Proceedings of the ACM SIGCOMM 2010 Conference, pp. 63-74. 2010.
39. Greenberg, Albert, James R. Hamilton, Navendu Jain, Srikanth Kandula, Changhoon Kim, Parantap Lahiri, David A. Maltz, Parveen Patel, and Sudipta Sengupta. “VL2: A scalable and flexible data center network.” In Proceedings of the ACM SIGCOMM 2009 conference on Data communication, pp. 51-62. 2009.
40. Zhang, Irene, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez et al. “The demikernel datapath os architecture for microsecond-scale datacenter systems.” In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, pp. 195-211. 2021.
41. Putnam, Andrew, Adrian M. Caulfield, Eric S. Chung, Derek Chiou, Kypros Constantinides, John Demme, Hadi Esmaeilzadeh et al. “A reconfigurable fabric for accelerating large-scale datacenter services.” ACM SIGARCH Computer Architecture News 42, no. 3 (2014): 13-24.
42. Firestone, Daniel, Andrew Putnam, Sambhrama Mundkur, Derek Chiou, Alireza Dabagh, Mike Andrewartha, Hari Angepat et al. “Azure accelerated networking: Smartnics in the public cloud.” In 15th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 18), pp. 51-66. 2018.
43. Ben-Nun, Tal, and Torsten Hoefler. “Demystifying parallel and distributed deep learning: An in-depth concurrency analysis.” ACM Computing Surveys (CSUR) 52.4 (2019): 1-43.
44. Aguilera, Marcos K., Naama Ben-David, Rachid Guerraoui, Antoine Murat, Athanasios Xygkis, and Igor Zablotchi. “uBFT: Microsecond-Scale BFT using Disaggregated Memory.” In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, pp. 862-877. 2023.
45. Corbett, James C., Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, Jeffrey John Furman, Sanjay Ghemawat et al. “Spanner: Google’s globally distributed database.” ACM Transactions on Computer Systems (TOCS) 31, no. 3 (2013): 1-22.
46. Antonopoulos, Panagiotis, Alex Budovski, Cristian Diaconu, Alejandro Hernandez Saenz, Jack Hu, Hanuma Kodavalla, Donald Kossmann et al. “Socrates: The new sql server in the cloud.” In Proceedings of the 2019 International Conference on Management of Data, pp. 1743-1756. 2019.
47. Mahesh Natu and Thanu Rangarajan. “Compute Express Link (CXL) Update”. Presented at UEFI 2020 Virtual Plugfest. 2020
48. UEFI. “Coherent Device Attribute Table (CDAT) Specification”. Available at Coherent Device Attribute Table (CDAT) Specification (uefi.org). 2020
49. Papamarcos, M. S.; Patel, J. H. (1984). “A low-overhead coherence solution for multiprocessors with private cache memories”, Proceedings of the 11th annual international symposium on Computer architecture – ISCA ’84. P. 348.
50. Sun, Yan, et al. “Demystifying CXL Memory with Genuine CXL-Ready Systems and Devices.” arXiv preprint arXiv:2303.15375 (2023).
51. Gouk, D., Kwon, M., Bae, H., Lee, S., & Jung, M. (2023). Memory Pooling with CXL. IEEE Micro.
52. Dastidar, J., Riddoch, D., Moore, J., Pope, S., & Wesselkamper, J. (2023). AMD 400G Adaptive SmartNIC SoC–Technology Preview. IEEE Micro.
53. Boles, D., Waddington, D., & Roberts, D. A. (2023). CXL-Enabled Enhanced Memory Functions. IEEE Micro.
54. Kim, Kyungsan, Hyunseok Kim, Jinin So, Wonjae Lee, Junhyuk Im, Sungjoo Park, Jeonghyeon Cho, and Hoyoung Song. “SMT: Software-Defined Memory Tiering for Heterogeneous Computing Systems with CXL Memory Expander.” IEEE Micro 43, no. 2 (2023): 20-29.
55. Montage Technology. Cxl memory expander controller (mxc). Available at https://www.montage-tech.com/MXC, accessed 4/10/2023.
56. SK Hynix Inc. SK Hynix Introduces Industry’s First CXL-based Computational Memory Solution (CMS) at the OCP Global Summit. Available at https://news.skhynix.com/sk-hynix-introduces-industrysfirst-cxl-based-cms-at-the-ocp-global-summit/, 2022, accessed 4/10/2023
57. Parag Beeraka. Enabling CXL within the Data Center with Arm Solutions. OpenCompute Summit 2022. Available at 2022 OCP Global Summit. Open Compute Project, accessed 4/10/2023
58. Berger, Daniel S., Daniel Ernst, Huaicheng Li, Pantea Zardoshti, Monish Shah, Samir Rajadnya, Scott Lee et al. “Design Tradeoffs in CXL-Based Memory Pools for Public Cloud Platforms.” IEEE Micro 43, no. 2 (2023): 30-38.
59. Atre, Nirav, Justine Sherry, Weina Wang, and Daniel S. Berger. “Caching with delayed hits.” In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pp. 495-513. 2020.
60. Genbrugge, Davy, and Lieven Eeckhout. “Memory data flow modeling in statistical simulation for the efficient exploration of microprocessor design spaces.” IEEE Transactions on Computers 57.1 (2007): 41-54.
61. Mutlu, Onur, and Lavanya Subramanian. “Research problems and opportunities in memory systems.” Supercomputing frontiers and innovations 1.3 (2014): 19-55.
62. K. Chang et al., “Improving DRAM performance by parallelizing refreshes with accesses,” in HPCA, 2014.
63. J. Liu et al., “RAIDR: Retention-aware intelligent DRAM refresh,” in ISCA, 2012.
64. P. J. Nair et al., “ArchShield: Architectural framework for assisting DRAM scaling by tolerating high error rates,” in ISCA, 2013.
65. G. Pekhimenko et al., “Linearly compressed pages: A main memory compression framework with low complexity and low latency.” in MICRO, 2013.
66. Choukse, Esha, Mattan Erez, and Alaa R. Alameldeen. “Compresso: Pragmatic main memory compression.” 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2018.
67. Mutlu, O., Ghose, S., Gómez-Luna, J., & Ausavarungnirun, R. (2022). A modern primer on processing in memory. In Emerging Computing: From Devices to Systems: Looking Beyond Moore and Von Neumann (pp. 171-243). Singapore: Springer Nature Singapore.
68. Singh, Gagandeep, et al. “Near-memory computing: Past, present, and future.” Microprocessors and Microsystems 71 (2019): 102868.
69. Hassan, H., Pekhimenko, G., Vijaykumar, N., Seshadri, V., Lee, D., Ergin, O., & Mutlu, O. (2016, March). ChargeCache: Reducing DRAM latency by exploiting row access locality. In 2016 IEEE International Symposium on High Performance Computer Architecture (HPCA) (pp. 581-593).
70. Lee, D., Kim, Y., Pekhimenko, G., Khan, S., Seshadri, V., Chang, K., & Mutlu, O. (2015, February). Adaptive-latency DRAM: Optimizing DRAM timing for the common-case. In 2015 IEEE 21st International Symposium on High Performance Computer Architecture (HPCA) (pp. 489-501).
71. Lee, S., Jeon, B., Kang, K., Ka, D., Kim, N., Kim, Y., … & Oh, J. (2019, February). 23.4 a 512GB 1.1 V managed DRAM solution with 16GB ODP and media controller. In 2019 IEEE International Solid-State Circuits Conference-(ISSCC) (pp. 384-386).
72. Chen, Y. (2020). ReRAM: History, status, and future. IEEE Transactions on Electron Devices, 67(4), 1420-1433.
73. Hady, F. T., Foong, A., Veal, B., & Williams, D. (2017). Platform storage performance with 3D XPoint technology. Proceedings of the IEEE, 105(9), 1822-1833.
74. D. Das Sharma, “Universal Chiplet Interconnect express (UCIe)®: Building an open chiplet ecosystem”, White paper published by UCIe Consortium, Mar 2, 2022
75. D. Das Sharma et. al., “Universal Chiplet Interconnect Express (UCIe)®: An Open Industry Standard for Innovations with Chiplets at Package Level”, invited paper, IEEE Transactions on Components, Packaging, and Manufacturing Technology, Oct 2022
76. D. Das Sharma, “Universal Chiplet Interconnect Express (UCIe)®: An Open Industry Standard for Innovations with Chiplets at Package Level”, IEEE Micro Special Issue, Mar-Apr 2023