全文 - version.A - AMBA CHI Chip-to-Chip（C2C）

AMBA® CHI Chip-to-Chip（C2C）架构规范（中文翻译）

项目	内容
文档编号	IHI0098
文档质量	Release（正式版）
文档版本	A
文档密级	非机密（Non-confidential）
发布日期	2024 年 2 月

翻译说明：本文档为 Arm IHI0098 A《AMBA® CHI Chip-to-Chip (C2C) Architecture Specification》（2024 年 2 月发布）的完整中文翻译。如中英文版本之间存在任何冲突，以英文原版为准。

---

发行信息

日期	版本	变更
2024/02/07	A	• 首次公开发布

---

---

第一部分 前言（Preface）

关于本规范

本规范描述 AMBA® CHI Chip-to-Chip（C2C）架构。

目标读者

本规范面向希望熟悉与 CHI 架构兼容的 C2C 架构的工程师。

如何使用本规范

本规范中的信息按以下部分组织：

• 第 B1 章 简介（Introduction）：阅读本章以了解 CHI C2C 架构及本规范中使用的术语。
• 第 B2 章 接口结构（Interface structures）：阅读本章以概览片上 CHI 与 CHI C2C 之间的各功能层。
• 第 B3 章 打包（Packetization）：阅读本章以了解消息如何被装入容器（Container）。
• 第 B4 章 消息结构（Message structures）：阅读本章以了解每种消息类型的大小和字段。
• 第 B5 章 流控（Flow control）：阅读本章以了解用于对消息进行流控的信用（Credit）交换机制。
• 第 B6 章 DVM 事务（DVM transactions）：阅读本章以了解 DVM 事务格式及其传播方式。
• 第 B7 章 RME-DA 与 RME-CDA 支持：阅读本章以概览 RME 设备分配（RME-Device Assignment，RME-DA）与 RME 一致性设备分配（RME-Coherent Device Assignment，RME-CDA）。
• 第 B8 章 接口状态管理（Interface state management）：阅读本章以了解如何管理接口的连接状态。
• 第 B9 章 接口初始化（Interface initialization）：阅读本章以概览 C2C 接口的初始化方式。
• 第 B10 章 协议层属性交换（Protocol layer property exchange）：阅读本章以了解接口属性以及这些属性如何传递。

约定（Conventions）

排版约定

本规范的排版约定如下：

• 斜体：用于突出重要注释、引入专门术语，以及表示内部交叉引用和文献引用。
• 粗体：表示信号名称；在适当情况下也用于描述性列表中的术语。
• 等宽字体：用于汇编语法描述、伪代码和源代码示例；在正文中也用于指令助记符，以及对出现在汇编语法描述、伪代码和源代码示例中的其他条目的引用。
• 小型大写字母（SMALL CAPITALS）：用于少数具有特定技术含义的术语。

信号

信号约定如下：

• 信号电平 ：有效（asserted）信号的电平取决于该信号是高电平有效还是低电平有效。"有效"指：
  • 对高电平有效（active-HIGH）信号，为 HIGH；
  • 对低电平有效（active-LOW）信号，为 LOW。
• 小写字母 n：位于信号名称的开头或结尾时，表示该信号为低电平有效。

数字

数字通常以十进制书写。二进制数前加 0b，十六进制数前加 0x，两者均以等宽字体书写。

补充阅读

本节列出 Arm 及第三方发布的出版物。访问 Arm 文档请见 Arm Developer：http://developer.arm.com。

• 1 AMBA® CHI Architecture Specification（ARM IHI 0051 G），Arm Ltd.
• 2 Universal Compute Interconnect Express（UCIe），Universal Compute Interconnect Express Consortium.
• 3 Compute Express Link（CXL），Compute Express Link Consortium.
• 4 Arm® Realm Management Extension（RME）System Architecture（ARM AES 0053 Issue B 00eac5），Arm Ltd.
• 5 Arm® Architecture Reference Manual Supplement, The Realm Management Extension（RME）, for Armv9-A（ARM DDI 0615 Issue A.d），Arm Ltd.

反馈

Arm 欢迎对其文档提出反馈意见。

对本规范的反馈

如果您对我们的文档有任何意见或疑问，请在 https://support.developer.arm.com 创建工单。请在工单中注明：

• 标题（AMBA® CHI Chip-to-Chip (C2C) Architecture Specification）；
• 编号（IHI0098 A）；
• 您的意见所涉及的章节名称；
• 您的意见所涉及的页码；
• 对您意见的简明说明。

Arm 也欢迎关于增补和改进的一般性建议。

包容性术语承诺

Arm 重视包容性社区。Arm 认识到，我们及本行业过去使用过一些可能令人反感的术语。Arm 致力于引领行业并推动改变。本规范不包含此类术语。如果您在本文档中发现令人反感的术语，请联系 terms@arm.com。

---

第二部分 规范（Specification）

第 B1 章 简介（Introduction）

本规范是《AMBA® CHI 架构规范》1 的 Chip-to-Chip（C2C）扩展。本章包含以下小节：

• B1.1 概述
• B1.2 术语

B1.1 概述（Overview）

C2C 扩展使构建包含多个 CPU、加速器或其他设备的系统成为可能。CHI C2C 专注于 CHI 消息的打包（packetization），使其适合通过片间（chip-to-chip）链路传输。该打包格式针对链路利用率和延迟进行了优化，同时避免了复杂的打包与解包方案。

两个主要用例是：

• 多芯片对称多处理器（Symmetric Multi-Processor，SMP）
• 多芯片一致性加速器挂接（coherent accelerator attach）

C2C 扩展也可称为 Chip(let)-to-Chip(let)，因为它既涵盖多个芯片在板级的连接，也涵盖多个裸片（die）或小芯片（chiplet）在封装级的连接。

B1.1.1 多芯片对称多处理器（SMP）

所关注的 SMP 配置是：少量功能相似、紧密连接在一起的芯片。每个芯片都包含片上系统（System-on-Chip，SoC）组件，具有大量处理核。每个芯片预计都带有挂载的内存，该内存由所有芯片上的处理核以一致（coherent）方式共享。

图 B1.1 展示了一个双芯片拓扑的示例。

图 B1.1：双芯片拓扑示例

图 B1.2 展示了一个四个芯片全连接拓扑的示例。挂载的内存实际存在，但图中未画出。

图 B1.2：四芯片全连接拓扑示例

B1.1.2 多芯片一致性加速器挂接

所关注的加速器挂接配置是：一个或多个一致性加速器连接到主机（host）芯片。加速器可以是全一致（fully coherent）的，也可以是 IO 一致（IO coherent）的。

图 B1.3 展示了一个带一致性加速器的拓扑示例。

图 B1.3：带一致性加速器的拓扑示例

B1.2 术语（Terminology）

以下术语在本规范中具有特定含义：

• DN：DVM 节点（DVM Node，DN）是位于芯片内部的节点，用于处理发往和来自远程芯片的 DVM 操作。
• RP：资源平面（Resource Plane，RP）是链路缓冲资源，使同一消息类（Message Class）内的消息组能够相互独立地在链路上传输。
• 发送器（Transmitter）：将消息转发到链路层（Link layer）的接口组件。
• 接收器（Receiver）：从链路层接收消息的接口组件。
• 容器（Container）：容器是消息在接口上传输的最小固定大小单位。

---

第 B2 章 接口结构（Interface structures）

本章描述 C2C 接口的结构，包含以下小节：

• B2.1 接口分层
• B2.2 消息类
• B2.3 通道连接
• B2.4 多接口

B2.1 接口分层（Interface layers）

消息从片上 CHI 接口到芯片引脚之间所经过的功能逻辑被划分为多个功能层，这些层称为：

• 协议层（Protocol layer）
• 打包层（Packetization layer）
• 链路层（Link layer）
• 物理层（Physical layer）

连接两个芯片时，预计会存在链路层和物理层，但不是必需。

图 B2.1 展示了 C2C 接口结构。

图 B2.1：C2C 接口结构

B2.1.1 协议层（Protocol layer）

协议层处理片上 CHI 与 CHI C2C 之间的协议转换。转换所需的逻辑极少。

B2.1.2 打包层（Packetization layer）

当链路层存在时，打包层位于协议层与链路层之间。如果链路层不存在，打包层直接连接到外部信号。必要时，打包层将待发送的消息打包进固定大小的容器（container），并将收到的容器解包为各条消息。收到的消息被转发到协议层或打包层内的其他功能模块。

B2.1.3 链路层（Link layer）

链路层负责以流控单元（FLow control unIT，Flit）粒度处理消息传输。

链路层还负责可选的数据完整性以及传输错误检测与恢复。典型做法是：在待发送的 flit 上附加生成的循环冗余校验（Cyclic Redundancy Check，CRC）校验和，并在接收的 flit 上检查 CRC 校验和。

发生错误时，链路层可以使用 flit 重试（retry）机制从错误中恢复。

B2.1.4 物理层（Physical layer）

物理层负责在两个芯片之间提供可靠的电气连接。

物理层的部分能力包括：用于克服不同信号之间延迟偏差（latency skew）的逻辑，以及用于维持信号完整性的链路重训练（link retraining）。

容器中必须为链路层预留空间，以填入以下传输信息：

• Flit 头（Flit header）
• 链路可靠性信息（Link reliability）

链路层和物理层的细节不在本规范的范围之内。

B2.2 消息类（Message classes）

本规范将消息类（message class）定义为单一 CHI 消息类型的消息组。消息类类似于片上 CHI 的物理通道。

消息被分为以下五个消息类：

• 请求（Request，REQ）
• 响应（Response，RSP），不包含数据
• 监听（Snoop，SNP）
• 数据（Data，DAT）
• 杂项（Miscellaneous，MISC）

MISC 是 C2C 特有的消息类，用于归集所有与片上 CHI 协议消息不直接相关的消息。MISC 消息的示例用途包括接口初始化和消息信用授予（credit grant）。有关 MISC 消息的更多细节，参见 B4.2.7 无信用杂项消息字段。

B2.3 通道连接（Channel connection）

在芯片之间连接不同消息类通道有两种不同的方式：

1. 共享通道连接（Shared channel connect）
2. 独立通道连接（Independent channel connect）

C2C 接口的常见用法预计是共享通道连接：所有片上通道共享芯片之间的同一连接。

固定大小的容器用作 C2C 接口上的交换单位。待发送的消息被放入容器中。容器可以包含来自同一消息类的多条消息，也可以包含来自不同消息类的消息。

与每个消息类使用独立物理通道相比，使用可容纳任意消息类消息的容器通常能获得更好的链路效率。

图 B2.2 展示了共享通道连接。

图 B2.2：共享通道连接

或者，可以使用独立通道连接，即每个消息类使用一组独立的物理连线。这种连接方式由于不需要打包逻辑而更易于实现。然而，其代价是：可能因消息不足而无法充分利用所有可用通道，导致物理通道利用率不足。

B2.4 多接口（Multiple interfaces）

预计使用单个 C2C 接口连接两个芯片。

允许在两个芯片之间使用多个 C2C 接口以满足更高的吞吐量需求。使用多个接口时，两个芯片都必须遵循消息关联要求：

• 事务内部（Within transaction）：对于一个请求（Request）或监听（Snoop），所有关联的数据或响应消息必须使用同一接口。
• 事务之间（Between transaction） ：
  • 发往同一地址的所有请求和监听必须使用同一接口。
  • 所有端点有序（endpoint ordered）的请求必须使用同一接口。
  • 来自同一来源的 DVMReq 和 DVMSync 事务必须使用同一接口，参见 B6.3 DVM 事务流程。
  • 发往同一目标的 MISC 消息必须使用同一接口。

Completer 可以通过跟踪请求所使用的接口，确保响应在与对应内存请求或监听请求相同的接口上发送。

Home 可以通过跟踪请求接收时所用的接口，或使用公共地址哈希（address hash），确保监听请求在与发往该地址的请求相同的接口上发送。

使用地址哈希时：

• 一个芯片对发往给定目标芯片的请求必须使用单一的地址哈希。
• 发往不同目标芯片的请求可以使用不同的地址哈希函数。
• 允许采用请求侧和监听侧都可编程配置哈希函数的方式。B2.4.1 哈希函数示例给出了一个哈希函数示例。

允许用于聚合两个组件之间流量的接口数量为 1 到 16 个。

B2.4.1 哈希函数示例

图 B2.3 展示了如何通过地址哈希确定接口编号。

图 B2.3：由地址哈希确定接口

使用以下步骤确定应在哪个接口上发送请求或监听：

1. 按缓存行对齐的输入地址首先经过哈希掩码（Hash Mask）过滤。在过滤地址之前，未使用的最高有效地址位必须为 0。在本示例中，过滤的结果标记为 Masked_Addr。
2. 将 Masked_Addr 的各个比特进行异或（XOR），以两芯片之间的接口数量所定义的方式得到目标接口。

当接口数量为以下情况时，确定给定地址的接口编号的示例如下：

• 2 的幂次 ：
  • 2 个接口：Interface Num0 = Masked_Addrn-1 XOR Masked_Addrn-2 ... Masked_Addr7 XOR Masked_Addr6
  • 4 个接口：Interface Num1:0 = Masked_Addrn-1:n-2 XOR Masked_Addrn-3:n-4 ... Masked_Addr9:8 XOR Masked_Addr7:6
  • 8 个接口：Interface Num2:0 = Masked_Addrn-1:n-3 XOR Masked_Addrn-4:n-6 ... Masked_Addr11:9 XOR Masked_Addr8:6
• 非 2 的幂次：第一步先按一个大于实际可用接口数量的 2 的幂次接口数量进行哈希运算，得到中间接口编号；然后使用查表或其他实现手段将该中间接口编号映射到实际接口编号。该表以启发式方式设置，使哈希后的编号尽可能均匀地分布在可用接口数量上。中间接口数量相对于实际接口数量越大，消息在各接口上的分布均匀性就越好。

---

第 B3 章 打包（Packetization）

本章描述 C2C 接口内的打包过程，包含以下小节：

• B3.1 容器
• B3.2 协议头
• B3.3 消息打包

B3.1 容器（Containers）

一个容器为 256 字节，由链路头（Link header）字节、协议头（Protocol header）字节以及按粒度块（granule）组织的消息字节组成。

定义了以下两种容器格式：

1. Format X ，组成如下：
   • 240 字节载荷，划分为 12 个 20 字节的粒度块
   • 6 字节链路头
   • 10 字节协议头
   • 该格式兼容 UCIe 2 的 256 字节延迟优化模式（Latency Optimized Mode，含可选字节）。
2. Format Y ，组成如下：
   • 226 字节载荷，划分为：
     • 10 个 20 字节粒度块
     • 1 个 16 字节粒度块
     • 1 个 10 字节粒度块
   • 20 字节链路头
   • 10 字节协议头
   • 该格式兼容 CXL 3 的 256 字节延迟优化 flit 格式。

图 B3.1 展示了 Format X 和 Format Y 的容器字节布局。粒度块的分布使其在容器的 64 字节和 128 字节部分之间对齐。

图 B3.1：容器布局格式

有关 ProtHdr 比特位的信息，参见 B3.2 协议头。

B3.2 协议头（Protocol header）

未用于消息粒度块的字节，要么是链路头，要么是协议头。

链路头字节的描述不在本规范范围内。这些比特的典型用途是添加 flit 头、CRC 和 FEC。

协议层头（Protocol header）各比特的分配如图 B3.2 所示。

图 B3.2：协议头字段布局

表 B3.1 列出了图 B3.2 中协议头各字段的编码。

表 B3.1：协议头字段

字段名	宽度	描述
MsgCredit	16	由接收器（Receiver）授予的消息信用。参见 B5.2 消息信用。
MsgStart	12	MsgStarti 指示是否有消息在粒度块 i 中开始。每个粒度块对应一个 MsgStart 位。 MsgStarti = 0：没有消息在粒度块 i 中开始。该粒度块可能为空，也可能是从更早粒度块开始的消息的一部分。 MsgStarti = 1：有一条消息在粒度块 i 中开始，即该粒度块的起始比特处存在 MsgType 字段。

B3.3 消息打包（Message packing）

消息以粒度块为单位装入容器。消息只允许从粒度块的起始处开始。这限制了每种消息类型在容器内可占用的位置数量，从而最小化解码逻辑。

协议头中的 MsgStart 向量决定某粒度块处是否有新消息开始。每条消息以 MsgType 字段开头，该字段定义消息的类型。

B3.3.1 规则与限制

容器内消息放置的限制如下：

• 在 Format X 容器中，消息可以放置在任何粒度块中。
• 在 Format Y 容器中：
  • 除 Resp 和 Misc 类型外，消息可放置在除 G5 和 G11 之外的任何粒度块中。
  • Resp 可放置在任何粒度块中。
  • Misc 消息：
    • 总消息大小不超过 10 字节的，可放置在任何粒度块中。
    • 总消息大小不超过 16 字节的，可放置在除 G11 之外的任何粒度块中。
    • 总消息大小大于 16 字节的，可放置在除 G5 和 G11 之外的任何粒度块中。
• 跨粒度块消息（Multi-granule messages）：
  • 可从任何粒度块开始（Format Y 中的 G5 和 G11 除外）。
  • 必须连续，除非在 Format Y 中跨越 G5 或 G11------Format Y 中的跨粒度块消息会跳过 G5 和 G11。
  • 可跨越相邻的容器。跨多个容器时，消息必须在下一个容器的 G0 中继续。

此外，容器打包规则如下：

• 粒度块中是否包含消息是可选的。允许容器不包含任何消息。
• 消息的最低有效位（LSB）放置在粒度块的最低有效位处。
• 未使用的比特必须为 0，包括：
  • 不包含消息的粒度块；
  • 消息末尾与粒度块末尾之间的任何比特。
• 32 字节数据放置在 64 字节数据字段的哪一半，由请求地址 bit5 的值决定。
• 粒度块分组为：G0--G2、G3--G5、G6--G8、G9--G11。
  • 每个组可以：
    • 不填充任何粒度块；
    • 仅填充编号最低的粒度块；
    • 填充编号最低的两个粒度块；
    • 填充全部粒度块；
    • 最多包含一条 MiscU 消息；
    • 最多包含四条响应消息，其中 Resp2 按两条响应消息计数。
  • 例如，如果 G6 未填充，则 G7 和 G8 也必须为空。
  • MiscU.LinkStatus 消息只能使用 G0。

图 B3.3：Format X 容器打包示例

图 B3.3 展示了一个 Format X 容器打包的示例。图 B3.3 中的两个容器包含：

• 两条 ReqS 消息和两条 ReqL 消息，其中一条 ReqL 消息跨越两个容器。
• 一条 Resp 消息和一条 Resp2 消息。
• 一条 Snoop 消息。
• 一条 DataS 消息。
• 容器 B 中的空粒度块。

图 B3.4：Format Y 容器打包示例

图 B3.4 展示了一个 Format Y 容器打包的示例。图 B3.4 中的四个容器包含：

• 两条 ReqS 消息和一条 ReqL。
• 六条 Resp 消息。
• 一条 Snoop 消息。
• 一条 DataS 消息和一条 DataL 消息。
  • 容器 A 中的 DataS 消息跨越 G5。
  • DataL 消息从容器 A 开始，跳过 G11，回绕到容器 B 的开头。
• 六条 WrReqDataS 消息。
  • 容器 B 中的一条 WrReqDataS 消息跨越 G5。
  • 一条 WrReqDataS 消息从容器 C 的 G9 开始，跳过 G11，回绕到容器 B 的开头。
• 容器 B 中的空粒度块。

---

第 B4 章 消息结构（Message structures）

本章描述对片上 CHI 事务流程的支持范围、因不需要而在消息中被优化掉的片上 CHI 字段，以及由此得到的消息格式（列出每个消息类中的字段）。本章包含以下小节：

• B4.1 事务与事务流程
• B4.2 消息字段

B4.1 事务与事务流程（Transactions and transaction flows）

本节描述从属节点（Subordinate Node）收到的请求中的字段到片上 CHI 字段的映射，并列出不受支持的 CHI 事务。

B4.1.1 发往上从属节点（Subordinate Node）的请求中的字段映射

接收发往上从属节点的请求的接口，必须按以下方式将收到的请求中的字段映射到片上 CHI 请求消息：

• 将 SrcID 复制到 ReturnNID
• 将 TxnID 复制到 ReturnTxnID
• 将 DoDWT 置为 0

B4.1.2 不支持的事务

以下事务不受支持：

• 转发监听（Forwarding snoops）
• 对 Non-cacheable 和 Device 内存的独占访问（Exclusive access）
• 请求重试（Request Retry）流程
• 直接内存传输（Direct Memory Transfer，DMT）。用于 DMT 的 ReturnNID 和 ReturnTxnID 字段不包含在请求消息中。
• 直接缓存传输（Direct Cache Transfer，DCT）。专用于 DCT 的 FwdNID 和 FwdTxnID 字段不包含在监听消息中。
• 直接写传输（Direct Write Transfer，DWT）。用于 DWT 的 ReturnNID 字段不包含在请求消息中。
• 启用 Tag Match 时，不支持从属节点向请求节点（Request Node）直接返回 TagMatch 响应。
• 在持久化缓存维护操作（Persist Cache Maintenance Operation，CMO）事务流程中，不支持从属节点向请求节点直接返回 Persist 响应。

注意

对于读（Read）事务，包含 Home 节点和从属节点的芯片可以在该芯片内部使用 DMT。这允许数据由从属节点直接转发到 C2C 端口。然而，由于 C2C 接口不支持 DMT，数据响应中只有单个 SrcID 字段，而不是同时具有 SrcID 和 HomeNID 字段。在 C2C 端口处，数据响应中的 SrcID 字段必须填入 Home 的节点 ID。这可以确保事务中的任何后续消息（例如 CompAck）被正确发送到 Home。

对于写事务和监听事务，数据响应的 SrcID 字段将包含正确的节点 ID，无需替换为 Home ID。

在 Requester 芯片接口处，返回给 Requester 的响应中的 SrcID 和 HomeNID 必须通过复制公共字段值来填充。

通过在将转发监听转换为非转发监听之前跟踪监听类型，可以在 Home 芯片的出口（egress）部分支持 DCT。当收到带数据的监听响应时，接口逻辑可以将响应拆分：一个发送给 Requester，另一个发送给 Home。

B4.2 消息字段（Message fields）

本节描述每个消息类中的字段。

C2C 中存在、但片上 CHI 消息中不存在的字段，在 B4.2.1 C2C 特有消息字段 中描述。在 C2C 消息中被移除的片上 CHI 字段，在 B4.2.8 冗余字段中描述。

B4.2.1 C2C 特有消息字段

以下字段被添加到 C2C 消息中，片上 CHI 消息中不存在这些字段：

• MsgType
• ResPlane
• SharedCrdt
• ChunkValid
• RsvdZero

B4.2.1.1 消息类型（MsgType）

该字段按消息类和大小标识消息类型，其中：

• Request、Data、WrReqData 消息可以是两种类型之一，取决于消息长度。更多细节参见 B4.2.2 请求消息字段 、B4.2.4 数据消息字段 和 B4.2.5 WritePush 消息。
• Response 消息可以是每 20 字节粒度块装一条或两条。参见 B4.2.3 响应消息字段。
• Miscellaneous 消息可以是带信用（credited）或无信用（uncredited）的。
  • 无信用 MISC 消息的细节参见 B4.2.7 无信用杂项消息字段。
  • 本规范尚未定义任何带信用的 MISC 消息。

表 B4.1 给出了 MsgType 字段的编码。

表 B4.1：MsgType 编码

MsgType	类型	CHI 通道
0b0000	MiscU	-
0b0001	MiscC	-
0b0010	ReqS	REQ
0b0011	ReqL	REQ
0b0100	Resp	RSP
0b0101	Resp2	RSP
0b0110	Snoop	SNP
0b0111	DataS	DAT
0b1000	DataL	DAT
0b1001	WrReqDataS	REQ 和 DAT
0b1010	WrReqDataL	REQ 和 DAT
0b1011 - 0b1111	保留（Reserved）

B4.2.1.2 资源平面（ResPlane）

该字段用于在 Request 和 WritePush 消息中支持多资源平面。参见 B5.3 资源平面 和 B5.4 数据信用池。

B4.2.1.3 共享信用（SharedCrdt）

该字段用于在 Request 和 Data 消息类消息中支持多资源平面和数据信用池。参见 B5.3 资源平面 和 B5.4 数据信用池。

B4.2.1.4 块有效（ChunkValid）

该字段存在于 DataS、DataL、WrReqDataS 和 WrReqDataL 消息中。其值指示两个 32 字节数据块中的一个或两个是否包含有效数据。

表 B4.2 给出了 ChunkValid 字段的编码。

表 B4.2：ChunkValid 字段编码

ChunkValid1:0	有效块
0b00	保留（Reserved）
0b01	低 32 字节
0b10	高 32 字节
0b11	全部 64 字节

B4.2.1.5 RsvdZero

该字段表示这些比特的用途为保留（Reserved）：发送器必须将该字段置为 0，接收器必须忽略该字段，中间代理必须原样转发。消息中包含 RsvdZero 字段，可能是为了使后续字段从字节或粒度块边界开始，或用于填充最后一个粒度块中超出有效信息的比特。

B4.2.2 请求消息字段（Request message fields）

本节描述请求消息类型中的字段：

• ReqS，短尺寸格式
• ReqL，长尺寸格式

当请求中存在以下任何字段且其值为非零时，请求消息必须使用 ReqL 消息格式：

• 任何请求中的 Addr3:0。对普通内存的 64 字节大小的无数据（Dataless）请求，其 Addr5:0 位允许置零。
• 独占事务中的 LPID。
• Persist CMO、StashOnceSep 或 TagOp 值为 Match 的写操作中的 GroupID。
• StashNID10:1
• StashLPIDValid
• PBHA
• LikelyShared
• DataTarget6:1
• RSVDCN-1:16

当允许使用 ReqS 时，发送器可以用 ReqL 消息代替 ReqS。使用 ReqL 代替 ReqS 可能会降低容器打包效率。

表 B4.3 列出了请求消息字段及其在 ReqS 和 ReqL 中的放置。

表中各列定义如下：

• Common（公共）：标有相同 "Cx" 标记的字段在消息中共享同一位置。
• ReqS：请求包含所有必需字段和最常用的可选字段。
• ReqL：请求大小扩展为包含所有受支持的请求字段。

表 B4.3：请求消息字段

Common	字段名	ReqS（比特）	ReqL（比特）
	MsgType	4	4
	SharedCrdt	1	1
	ResPlane	3	3
	QoS	4	4
	SrcID	11	11
	TxnID	12	12
	NS	1	1
	NSE	1	1
	SecSID1	1	1
	Order	2	2
	MemAttr	4	4
	ExpCompAck	1	1
	TraceTag	1	1
	Addr51:6	46	46
	Addr5:4	2	2
	SnpAttr	1	1
	MPAM	15	15
C0	MECID StreamID	16	16
	RSVDC15:0	16	16
	Size	3	3
	Opcode	7	7
	TagOp	2	2
C1	StashNIDValid Endian Deep PrefetchTgtHint	1	1
C2	Excl SnoopMe CAH	1	1
C3	DataTarget0 StashNID0	1	1
	RsvdZero	3	3
	PBHA	0	4
	Addr3:0	0	4
	StashLPIDValid	0	1
	StashLPID	0	5
C4	{4'b0, DataTarget6:1} StashNID10:1	0	10
C5	{3'b0, LPID} PGroupID StashGroupID TagGroupID	0	8
	RSVDC23:16	0	8
	RSVDC31:24	0	8
	LikelyShared	0	1
	RsvdZero	0	111
	总计（比特）ᵃ	157	206

ᵃ 总比特数不包含 RsvdZero 位。

B4.2.3 响应消息字段（Response message fields）

本节描述响应消息类型中的字段：

• Resp
• Resp2

B4.2.3.1 Resp 消息类型

表 B4.4 给出了 Resp 消息类型的字段，其中一个响应装入单个粒度块。

表 B4.4：Resp 响应消息字段

Common	字段名	宽度（比特）
	MsgType	4
	QoS	4
	TgtID	11
	SrcID	11
	TxnID	12
	Opcode	5
	RespErr	2
	Resp	3
	DataPull	1
	CBusy	3
	TagOp	2
	TraceTag	1
C6	DBID {4'b0, PGroupID} {4'b0, StashGroupID} {4'b0, TagGroupID}	12
	RsvdZero	9
	总计（比特）ᵃ	71

ᵃ 总比特数不包含 RsvdZero 位。

B4.2.3.2 Resp2 消息类型

表 B4.5 给出了 Resp2 消息类型的字段，其中两个响应装入单个粒度块。

表 B4.5：Resp2 响应消息字段

Common	字段名	宽度（比特）
	MsgType	4
	QoS	4
	TgtID	11
	SrcID	11
	TxnID	12
	Opcode	5
	RespErr	2
	Resp	3
	DataPull	1
	CBusy	3
	TagOp	2
	TraceTag	1
C6	DBID {4'b0, PGroupID} {4'b0, StashGroupID} {4'b0, TagGroupID}	12
	RsvdZero	9
	RsvdZero	4
	QoS	4
	TgtID	11
	SrcID	11
	TxnID	12
	Opcode	5
	RespErr	2
	Resp	3
	DataPull	1
	CBusy	3
	TagOp	2
	TraceTag	1
C6	DBID {4'b0, PGroupID} {4'b0, StashGroupID} {4'b0, TagGroupID}	12
	RsvdZero	9
	总计（比特）ᵃ	138

ᵃ 总比特数不包含 RsvdZero 位。

B4.2.4 数据消息字段（Data message fields）

DataS 和 DataL 消息格式用于读数据、监听响应数据以及非 WritePush 的数据消息。

DataS 和 DataL 消息格式的特点包括：

• SrcID 和 HomeNID 共享单个 11 位字段。该字段由以下两者使用：
  • CompData 和 DataSepResp 中的 HomeNID
  • SnpRespData 和 WriteData 中的 SrcID
• 数据毒化（Data poison）为每次数据传输单个比特，由 RespErr 值为 DERR 来指示。
• ChunkValid 字段用于指示对应的 32 字节是否包含有效数据，参见表 B4.2。
• Data 字段从字节边界开始。这要求在 Data 字段之前进行 RsvdZero 位填充。
• 仅存在于 DataL 消息中的字段从粒度块边界开始。
• 任何数据消息的 Data 字段中的无效字节（由 ChunkValid 指示），以及写数据和监听响应数据中由 BE 指示的无效字节，必须置零。

当以下任何条件为真时，必须使用 DataL 消息格式代替 DataS：

• 对部分写（partial write）请求的数据响应中，BE 字段有一个或多个比特为零值。
• 消息中存在以下字段且值为非零：
  • QoS
  • PBHA
  • RSVDCN-1:16

当允许使用 DataS 时，发送器可以用 DataL 消息代替 DataS。使用 DataL 代替 DataS 可能会降低容器打包效率。

表 B4.6 给出了 DataS 和 DataL 的消息字段。

表 B4.6：DataS 和 DataL 消息字段

Common	字段名	DataS	DataL
	MsgType	4	4
	SharedCrdt	1	1
	RsvdZero	1	1
	ChunkValid	2	2
	TgtID	11	11
C8	SrcID HomeNID	11	11
	TxnID	12	12
	Opcode	4	4
	RespErr	2	2
	Resp	3	3
	DataSource	8	8
	DataPull	1	1
	CBusy	3	3
	CCID	2	2
	TagOp	2	2
	Tag	16	16
	TU	4	4
	TraceTag	1	1
	CAH	1	1
C9	{4'b0, DBID} MECID	16	16
	RSVDC15:0	16	16
	RsvdZero	7	7
	Data	512	0
	RsvdZero	0	32
	RSVDC31:16	0	16
	QoS	0	4
	PBHA	0	4
	RsvdZero	0	40
	BE	0	64
	Data	0	512
	非数据总计（比特）ᵃ	120	208
	总计（比特）ᵃ	632	720

ᵃ 总比特数不包含 RsvdZero 位。

B4.2.5 WritePush 消息

带有 NonCopyBackWriteData 数据的立即写（Immediate Write）、原子操作（Atomic）和 DVMReq 事务，允许（但不要求）使用写推送（write push）语义来优化其事务流程。写推送流程将发送器发往接收器的请求和数据合并为一条消息，从而消除了对 DBIDResp 响应的需求。

这种两步写推送相对于三步写拉取（write pull）事务具有以下优势：

• 减少消息数量，从而提高链路利用率。
• 同时存在于请求和数据中的字段只需发送一次。
• 减少请求缓冲区占用时间。

定义了以下接口属性以支持 WritePush 事务：

• WritePush_Support ：该属性指示接口是否支持对立即写和原子事务使用 WritePush。参见 B10.4.2 接收器和发送器属性。
• DVMPush_Support ：该属性指示接口是否支持对 DVM 事务使用 WritePush。参见 B10.4.2 接收器和发送器属性。

消息格式细节参见 B4.2.5.2 消息字段。

B4.2.5.1 事务流程

图 B4.1 展示了使用写推送语义的立即写事务的事务流程。

图 B4.1：WritePush 事务流程

WritePush 事务的顺序如下：

• 事务由 Requester 发出 WrReqDataS 或 WrReqDataL 消息开始。
• Completer 发送 Comp 响应。

B4.2.5.2 消息字段

表 B4.7 列出了允许使用 WrReqDataS 消息的请求操作码（opcode）。在这些请求中，BE 字段的值必须全为 1。所有其他推送事务------包括需要 WrReqDataS 消息中未包含字段的事务------必须使用 WrReqDataL 消息格式。

在 WrReqDataS 和 WrReqDataL 中，Data 字段中的无效字节必须置零。

注意：接口可以使用 ChunkValid 来确定哪些字节需要置零。

表 B4.7 中的 OWO 字段指示该写操作是否属于需要有序写观察（Ordered Write Observation，OWO）保证的一组写操作。

• 当 OWO = 0：不需要 OWO 保证。
• 当 OWO = 1：需要 OWO 保证。

当规则允许使用 WrReqDataS 时，写推送消息允许使用 WrReqDataL 代替 WrReqDataS。使用 WrReqDataL 可能会降低容器打包效率。

表 B4.7：WrReqDataS 和 WrReqDataL 消息字段

Common	字段名	WrReqDataS（比特）	WrReqDataL（比特）
	MsgType	4	4
	SharedCrdt	1	1
	ResPlane	3	3
	QoS	4	4
	SrcID	11	11
	TxnID	12	12
	NS	1	1
	NSE	1	1
	SecSID1	1	1
	Order	2	2
	MemAttr	4	4
C10	ExpCompAck OWO	1	1
	TraceTag	1	1
	Addr51:6	46	46
	Opcode2	2	0
	Union1ᵃ	34	0
	Data	512	0
	Addr5:4	0	2
	SnpAttrᵇ	0	1
	MPAM	0	15
	MECID	0	16
	RSVDC15:0	0	16
	Sizeᶜ	0	3
	Opcode	0	7
	TagOpᵈ	0	2
C1	StashNIDValid Endian Deep PrefetchTgtHint	0	1
C2	Excl SnoopMe CAH	0	1
C3	DataTarget0 StashNID0	0	1
	RsvdZero	0	3
	PBHA	0	4
	Addr3:0	0	4
	StashLPIDValid	0	1
	StashLPID	0	5
C4	{4'b0, DataTarget6:1} StashNID10:1	0	10
C5	{3'b0, LPID} PGroupID StashGroupID TagGroupID	0	8
	RSVDC23:16ᵉ	0	8
	Tag	0	16
	TU	0	4
	ChunkValid	0	2
	RespErr	0	2
	BE	0	64
	Data	0	512
	非数据总计（比特）ᶠ	128	285
	总计（比特）ᶠ	640	797

ᵃ 该字段由 MECID、MPAM 和 RSVDC 共享，参见图 B4.2。

ᵇ 对于 WrReqDataS，该字段由 Opcode2 派生。

ᶜ 对于 WrReqDataS，该字段隐含为 64 字节。

ᵈ 请求中的 TagOp 值与数据消息中的 TagOp 值相同。

ᵉ C2C 接口的 RSVDC 最多允许 24 位。

ᶠ 总比特数不包含 RsvdZero 位。

表 B4.8 给出了 WrReqDataS 消息中的 Opcode2 字段。

表 B4.8：WrReqDataS 消息中 Opcode2 字段编码

Opcode21:0	WrReqDataS 命令	备注
00	WriteNoSnpFull
01	WriteUniqueFull
10	WriteNoSnpPtl	全部 64 个 BE 位置位
11	WriteUniquePtl	全部 64 个 BE 位置位

图 B4.2 展示了 Union1 字段在 MPAM、MECID 和 RSVDC 字段之间的共享方式。

Union1 字段的低位决定该字段的其他比特如何用于 MPAM、MECID 和 RSVDC 值。

图 B4.2：Union1 字段用于 MPAM、MECID 和 RSVDC

B4.2.6 监听消息字段（Snoop message fields）

表 B4.9 给出了监听消息中的字段。

表 B4.9：监听消息字段

Common	字段名	宽度（比特）
	MsgType	4
	QoS	4
	TgtID	11
	SrcID	11
	TxnID	12
	PBHA	4
	StashLPIDValid	1
	StashLPID	5
	Opcode	5
	Addr	48
	NS	1
	NSE	1
	DoNotGoToSD	1
	RetToSrc	1
	TraceTag	1
	MPAM	15
	MECID	16
	RsvdZero	19
	总计（比特）ᵃ	141

ᵃ 总比特数不包含 RsvdZero 位。

B4.2.7 无信用杂项消息字段（Uncredited Miscellaneous message fields）

MiscU 消息中的字段如表 B4.10 所示。

MiscU 消息使用的 Payload 比特数取决于 MISC 消息类型。使用的符号说明如下：

• X：可变字段宽度，具体值取决于 MiscOp 字段的值。

表 B4.10：MiscU 消息字段

字段名	宽度（比特）
MsgType	4
MiscOp	4
Payload	X
总计（比特）	8 + X

MiscOp 描述杂项消息类支持的消息子类型。

MiscU 消息中 MiscOp 字段的编码如表 B4.11 所示。

表 B4.11：MiscU 消息中 MiscOp 字段的编码

MiscOp3:0	MiscU 消息
0000	保留（Reserved）
0001	保留（Reserved）
0010	Activation
0011	Connect
0100	CrdtGrant
0101	Properties
0110	LinkStatus
其他	保留（Reserved）

B4.2.8 冗余字段（Redundant fields）

某些 CHI 字段在 C2C 消息中不需要，原因包括以下一项或多项：

• 使用该字段的事务流程不受支持。
• 该字段仅在 Home 节点到从属节点接口的消息中使用，用于支持 C2C 不支持的流程优化。
• 该消息类的消息路由基于地址译码而非 ID。

表 B4.12 给出了 C2C 消息中不需要的 CHI 字段。

表 B4.12：不包含在 C2C 消息中的 CHI 消息字段

消息类	字段名	比特数	描述
Request	TgtID	11	该字段被移除，因为请求使用地址译码而非 TgtID 进行路由。
Request	ReturnNID ReturnTxnID DoDWT	11 12 1	这些字段被移除，因为它们仅用于 Home 节点到从属节点的请求中，用于在请求节点与从属节点之间提供优化的直接路径响应通信。这些节点之间的直接响应不受支持。
Request	AllowRetry PCrdType	1 4	这些字段被移除，因为它们仅用于请求重试（Request Retry）事务流程。
Response	FwdState	3	该字段被移除，因为它仅用于 DCT 事务流程。
Response	PCrdType	4	该字段被移除，因为它仅用于请求重试事务流程。
Data	FwdState	3	该字段被移除，因为它仅用于 DCT 事务流程。
Data	DataID	2	该字段被移除，因为数据在 C2C 接口上始终以单个 64 字节块发送。
Data	Poison	8	该字段被移除，因为毒化指示以缓存行为单位，编码在 RespErr 字段中。RespErr 编码 0b10 用于指示 Poison 或 Data Error。
Data	DataCheck	64	该字段被移除，因为链路层可以使用其自有机制（如 CRC 和前向纠错 FEC）来支持传输可靠性，这使 DataCheck 字段成为冗余。
Data	NumDat Replicate	2 1	这些字段被移除，因为它们用于支持有限的数据省略（data elision）。缓存行数据始终以 64B 粒度块传输。
Snoop	FwdNID FwdTxnID	11 12	这些字段被移除，因为它们仅用于转发监听（Forwarding snoop）。
Snoop	VMIDExt	8	该字段被移除，因为它仅用于 DVM 监听。DVM 监听以 DVM 请求的形式在 C2C 接口上发送，因此监听中不需要该字段。

---

第 B5 章 流控（Flow control）

本章描述 C2C 接口的消息流控，包含以下小节：

• B5.1 简介
• B5.2 消息信用
• B5.3 资源平面
• B5.4 数据信用池
• B5.5 有序接口

B5.1 简介（Introduction）

消息必须满足以下条件：

• 消息在传输中不得被丢弃或丢失，即发送器发送的每条消息都必须被接收器接收并处理。
• 来自链路层或物理层的传入报文必须在不施加背压（backpressure）的情况下被接收，这符合业界通用的物理设计标准。更多信息参见 UCIe 2。
• 响应和数据通道消息必须被接收，而不依赖于任何请求或监听消息的前向进展。
• 监听通道消息必须能够推进，而不依赖于请求通道消息的前向进展。
• 写推送请求不得阻塞任何与写推送无关的数据的前向进展。

采用以下机制来支持流控要求：

• 为每个消息类提供独立的信用，以确保来自某个消息类的消息能够在其他消息类消息被背压时继续推进。
• 在 REQ 和 DAT 消息类内支持多个资源平面（Resource Plane，RP）和 DAT 信用池，以为每个消息类内的不同消息组提供前向进展保证。
• 还支持同一消息类和同一 RP 内消息的有序性。

B5.2 消息信用（Message credits）

为支持流控要求，必须满足：

• 来自每个消息类的消息必须独立进行流控。
• 对于每个消息类，接收器必须向发送器提供消息信用。这确保发送器在发送消息之前拥有适当的信用。
  • 无信用 MISC 消息不需要消息信用，接收器必须保证接收此类消息。
  • 要发送 WrReqDataS 或 WrReqDataL 消息，发送器需要持有一个 REQ 和一个 DAT 消息信用。参见 B5.4 数据信用池。

参见表 B4.1 以确定每种消息类型需要哪种信用。

信用可以使用协议头授予，也可以使用 MiscU 消息授予。

B5.2.1 使用协议头授予信用

可以使用协议头中的消息信用授予字段 MsgCredit 向发送器授予信用。

MsgCredit 字段的子字段如图 B5.1 所示。MsgCredit 字段可用于授予除 MISC 之外所有消息类的信用。

带有 Activation 消息的容器不能使用协议头来授予信用。有关 Activation 消息的细节，参见 B8.2 接口激活与去激活。

图 B5.1：协议头中的消息信用字段

SharedCrdt（ShC）和 RP 字段用于在 REQ 或 DAT 消息类支持多个 RP 时使用。ShC 和 RP 字段值适用于 REQCredit 和 DATCredit 字段，但不适用于 RSPCredit 或 SNPCredit 字段。

• 当 ShC = 0 ：REQCredit 和 DATCredit 均对应于由 RP 字段值指示的信用池，并且：
  • 当 WritePush_Support 和 DVMPush_Support 均为 False 时，DATCredit 必须为 0。
  • 当 WritePush_Support 或 DVMPush_Support 之一（或两者）为 True 时，若 RP 值大于 1，DATCredit 必须为 0。
  • 不允许 RP 值大于或等于 REQ 的最大 RP 数。
• 当 ShC = 1：REQCredit 和 DATCredit 均对应于共享信用池。RP 字段不适用，必须为 0。

共享信用和专用信用池用法的细节，参见 B5.3 资源平面 和 B5.4 数据信用池。

B5.2.2 使用 MiscU 消息授予信用

可以通过在 MISC 通道上发送显式的信用授予消息，使用 MISC 通道消息为所有消息通道授予信用。参见 B5.2.3 信用授予消息格式。

图 B5.2：消息信用

已授予的信用在发送相应消息类中的消息时使用。

表 B5.1 给出了消息信用字段的编码。

表 B5.1：消息信用字段编码

Message credit2:0	信用数量
000	0
001	1
010	2
011	4
100	8
101	16
110	保留（Reserved）
111	保留（Reserved）

B5.2.3 信用授予消息格式

MiscU.CrdtGrant 用于为消息授予信用。

表 B5.2 给出了 CrdtGrant MiscU 消息的字段。

表 B5.2：CrdtGrant 消息字段

字段名	宽度（比特）
MsgType	4
MiscOp	4
REQShCredit	3
RSPCredit	3
DATShCredit	3
SNPCredit	3
MISCCredit	3
REQ0Credit	3
REQ1Credit	3
REQ2Credit	3
REQ3Credit	3
REQ4Credit	3
REQ5Credit	3
REQ6Credit	3
REQ7Credit	3
DAT0Creditᵃ	3
DAT1Creditᵃ	3
RsvdZero	27
总计（比特）	80

ᵃ 当 WritePush_Support 和 DVMPush_Support 均为 False 时，该字段不适用且必须为 0。

B5.3 资源平面（Resource Planes）

多个资源平面通常用于实现：

• 针对不同请求的前向进展保证。例如，确保 PCIe 投递写（posted write）的前向进展不依赖于其他写事务的进展。
• 服务时间保证。例如，属于实时流量、需要在规定延迟界限内得到服务的消息。
• 简化协议。例如，即使事务的两个阶段使用同一传输，也能消除请求重试（Request retry）而不产生传输死锁。

本规范支持请求资源平面（RP），以在请求之间提供传输独立性。

使用资源平面时：

• 使用不同资源平面的消息，从本地协议层到远程协议层之间不得相互阻塞。
• 可以发放以下类型的信用：
  • 专用信用（Dedicated credit）：针对特定 RP，只能用于属于该 RP 的消息。
  • 共享信用（Shared credit）：不指定 RP，可用于分配到任何 RP 的消息。
• 使用同一 RP 的消息必须保持顺序，即使它们使用共享信用。
• 发送器持有信用的任何 RP 都可用于发送消息。
• 建议（但不要求）发送器在使用专用信用之前先使用共享信用。

请求消息最多可以有八个资源平面。

接收器可以将其缓冲区在共享信用池和专用信用池之间划分。每个专用信用池的消息信用数量允许不同。

接收器必须为其支持的每个请求 RP 提供至少一个专用信用，并为共享信用池提供至少一个信用。

请求消息必须：

• 指示其是否使用共享池信用。
• 即使使用共享池信用，也必须包含其所属的 RP。

请求消息中包含 SharedCrdt 和 ResPlane 字段以支持资源平面：

• SharedCrdt ：指示请求是否使用共享信用。
  • 当 SharedCrdt = 0：请求使用专用 RP 信用。RP 编号由 ResPlane 字段值指示。
  • 当 SharedCrdt = 1：请求使用共享池信用。即使使用共享信用，消息所属的 RP 也必须由 ResPlane 字段值指示。
• ResPlane2:0：指示请求所属的 RP。字段值可以是 0 到 Num_RP_REQ。Num_RP_REQ 属性定义请求消息类支持的专用 RP 的最大数量。Num_RP_REQ 编码参见表 B10.7 和表 B10.8。

ReqS 和 ReqL 消息格式参见 B4.2.2 请求消息字段。

B5.4 数据信用池（Data credit pools）

用于传输带数据消息的信用（DAT 信用）分为以下信用池：

• DAT0Credit：专用信用，用于传输需要在任何被阻塞的 WritePush 消息之上保证进展的 Data 消息。使用 DAT0Credit 发送消息不得依赖于使用其他数据信用池信用的消息的进展。
• DAT1Credit：专用信用，用于传输需要前向进展保证的 WrReqData 消息。使用 DAT1Credit 发送消息不得依赖于使用其他数据信用池信用的消息的进展。
• DATShCredit：共享信用，可用于传输任何数据消息。与一个请求 RP 相关的消息使用 DATShCredit 时，不得阻塞与另一个请求 RP 相关的消息，也不得被其阻塞。

表 B5.3 给出了每种消息类型允许使用的信用类型。

表 B5.3：每种消息类型的数据信用选项

消息类型	消息	信用类型
Data	带数据的读响应、带数据的监听响应、写拉取数据响应	DATShCredit、DAT0Credit
WrReqData	需要前向进展保证的 WritePush	DATShCredit、DAT1Credit
WrReqData	不需要前向进展保证的 WritePush	DATShCredit

选择使用专用信用还是共享信用可取决于传输所需的进展程度。例如：

• 必须前向推进的 PCIe 写操作在使用 WrReqData 消息时，预计在没有可用共享信用时使用专用信用。
• 可被其他消息停顿的 DVM 消息可以等待共享信用可用，不需要专用信用支持。

必须至少提供一个 DATShCredit 类型的信用。

如果 WritePush_Support 或 DVMPush_Support 之一为 True，则每种专用 DAT 信用类型都必须至少提供一个信用。

如果 WritePush_Support 和 DVMPush_Support 均为 False，则不需要 DAT0Credit 和 DAT1Credit，且不得发送这两种信用。

B5.4.1 DataS 和 DataL 消息的信用

DataS 和 DataL 字段包含 SharedCrdt 字段，编码如下：

• 当 SharedCrdt = 0：数据消息使用 DAT0Credit。
• 当 SharedCrdt = 1：数据消息使用 DATShCredit。

DataS 和 DataL 消息格式参见 B4.2.4 数据消息字段。

B5.4.2 WrReqData 消息的信用

WrReqData 消息包含请求和写数据，因此需要一个 REQ 消息信用和一个 DAT 消息信用。

WrReqData 消息的请求部分可以像其他请求消息一样被分配一个 RP。

任何 WrReqData 消息：

• 需要前向进展保证的，允许使用 DATShCredit 或 DAT1Credit。建议（但不要求）在使用 DAT1Credit 之前先使用 DATShCredit。
• 不需要前向进展保证的，必须使用 DATShCredit。

WrReqData 消息的信用和 RP 选项在 SharedCrdt 和 ResPlane 字段中编码如下：

• SharedCrdt
  • 当 SharedCrdt = 0：请求使用 REQxCredit，数据使用 DAT1Credit。
  • 当 SharedCrdt = 1：请求使用 REQShCredit，数据使用 DATShCredit。
• ResPlane2:0：指示请求被分配到的 RP。

WrReqData 消息格式参见 B4.2.5.2 消息字段。

注意：一条需要同时具备请求和数据共享信用才能以 WritePush 语义推进的写消息，当两种共享信用无法及时同时可用时，可以改为使用写拉取（Write pull）来推进事务。

B5.5 有序接口（Ordered interface）

要求 C2C 接口必须是有序的。

容器在 C2C 接口上的接收顺序必须与链路远端 C2C 接口发送它们的顺序相同。

要求：

• 在发送器侧 ：
  • 来自同一消息类且（在适用时）同一 RP 的消息，必须按从协议层接收的顺序放入容器，即从编号最低的粒度块开始，依次向更高编号填充。
  • 来自不同消息类的消息没有这种有序放置限制。
• 在接收器侧 ：
  • 打包层必须保持所接收容器内给定消息类消息的放置顺序，以及容器的接收顺序。
  • 同一 RP 值的同一消息类内的消息，必须按接收顺序转发到协议层。

在两个组件之间使用多个接口时的有序性要求，参见 B2.4 多接口。

有序接口是必需特性，因此不包含用于控制其是否存在的接口属性。

---

第 B6 章 DVM 事务（DVM transactions）

本章包含以下小节：

• B6.1 简介
• B6.2 DVM 节点（DN）
• B6.3 DVM 事务流程
• B6.4 DVM 事务响应
• B6.5 流控

B6.1 简介（Introduction）

C2C 接口支持所有 CHI DVM 事务。本规范定义了一种新的节点类型------DVM 节点（DVM Node，DN），它负责将本地 DVM 事务传播到远程芯片，并按远程 DVM 请求的要求执行所需的本地无效化（invalidation）操作。

DVM 节点还管理流控，以保证 DVM 事务的前向进展。

通过引入新的响应类型并减少消息数量，DVM 消息流程得到了优化。

B6.2 DVM 节点（DVM Node，DN）

DN 处理发往和来自远程芯片的 DVM 操作。DN 执行以下功能：

• 为本地 DVM 事务向远程 DVM 节点发送 DVM 请求。向多个节点发送请求时，可以向每个远程 DN 单播（unicast）DVM 请求，也可以使用层次化的树形通信模式：先发送给远程 DN 的一个子集，由它们进一步转发给另一个子集，从而将 DVM 请求扩展到系统中的所有 DVM 节点。
• 收集其发往远程 DN 的 DVM 请求的响应。
• 为远程 DVM 请求执行本地所需的无效化操作。
• 协调本地与远程 DVM 事务之间的交互。

每个芯片只允许有一个 DN。

系统中 DVM 节点的数量限制为 64 个。

B6.2.1 DVM 节点分配

DN 允许与同一芯片上的请求节点（Request Node）和 Home 节点共享 ID 命名空间。

这要求将发往 DN 的 DVM 响应与发往请求节点的响应区分开来。

注意：共享节点 ID 命名空间的能力可使系统中所需的唯一 ID 总数最小化。

B6.3 DVM 事务流程（DVM transaction flows）

C2C 上的两种 DVM 事务是：

• DVMReq
• DVMSync

在本规范中，DVMReq 指 DVMOp(NonSync)，DVMSync 指 DVMOp(Sync)。

B6.3.1 DVMReq

DVMReq 事务流程如图 B6.1 所示。该流程类似于 32 字节部分写（write partial）事务流程。DVMReq 事务可以使用写推送（write push）或写拉取（write pull）语义。

仅当 DVMPush_Support 属性为 True 时，DVMReq 才允许使用写推送语义。

Completer 的响应为：

• 使用写推送流程时：CompDVM。
• 使用写拉取流程时：CompDVM、DBIDRespDVM，或组合形式的 CompDBIDRespDVM。

响应消息细节参见 B6.4 DVM 事务响应。

DVM 事务载荷分布在请求的 Addr 和 Data 字段中，与片上 CHI 相同。DVM 事务的 Comp 和 DVMData 通过使用不同的操作码与非 DVM 事务的 Comp 和 Data 响应相区分。

图 B6.1：DVMReq 事务流程

注意：片上 CHI 用于将 DVM 事务从本地 DN 或入口（ingress）端口传递到 C2C Requester。在跨越 C2C 接口发送之后，C2C Completer 使用片上 CHI 将事务传递到本地 DN 或出口（egress）端口。

B6.3.2 DVMSync

DVMSync 事务流程如图 B6.2 所示。该流程类似于带单个响应的无数据（Dataless）请求事务流程。

完成响应为 CompSyncDVM。

所有必需的载荷都位于请求地址字段中，因此 DVM 事务的数据响应被消除。

当片上 Opcode 字段指示 DVMOp 且 DVMType 子字段指示 Synchronization 时，使用 DVMSync。

请求仅由 SrcID 跟踪。每个来源只能有一个未完成（outstanding）的 DVMSync 事务。因此，响应中的 TgtID 用于将响应与其对应的请求匹配。

在请求中，TxnID 不适用，必须为 0。

在响应中，TxnID 字段不适用，必须为 0。

图 B6.2：DVMSync 事务流程

B6.4 DVM 事务响应（DVM transaction responses）

DVMReq 和 DVMSync 消息的响应消息为：

• 对于 DVMReq：CompDVM、DBIDRespDVM、CompDBIDRespDVM 和 DVMData
• 对于 DVMSync：CompSyncDVM

DVM 事务响应（包括数据响应和非数据响应）的操作码参见表 B6.1 和表 B6.2。

表 B6.1：DVM 事务响应操作码编码

Opcode4:0	Resp
0x1C	CompDVM
0x1D	DBIDRespDVM
0x1E	CompDBIDRespDVM
0x1F	CompSyncDVM

表 B6.2：DVMReq 数据响应操作码编码

Opcode4:0	Resp
0xD	DVMData

B6.5 流控（Flow control）

DVM 事务的 Requester 和 Completer 必须遵循以下规则，以保证事务的前向进展。

一个 DN：

• 对远程 DVM 节点只能有一个未完成的 DVMSync 请求。
• 允许有任意数量发往远程 DVM 节点的未完成 DVMReq 请求。
• 必须接收来自每个远程 DN 的一个 DVMSync。

规定所有 DVMSync 请求必须被目标 DN 接收（sink），是为了避免请求路径在 C2C 处被阻塞。

DN 处的 DVMSync 不得阻塞 DVMReq 事务的前向进展。也就是说，必须保证从远程节点收到的 DVMReq 事务的前向进展。可以通过为接收的 DVMReq 事务预留缓冲区来获得该保证。

DVMReq 事务在 C2C 接口上的前向进展不得依赖于 DVMSync 事务的前向进展。

---

第 B7 章 RME-DA 与 RME-CDA 支持

本章描述 C2C 对 RME 设备分配（Device Assignment，DA）和 RME 一致性设备分配（Coherent Device Assignment，CDA）的支持，它们是 Arm 机密计算架构（Confidential Compute Architecture）的一部分。本章包含以下小节：

• B7.1 简介
• B7.2 支持 RME-DA 和 RME-CDA 的字段
• B7.3 主机与设备的职责
• B7.4 每个设备的请求节点数

B7.1 简介（Introduction）

RME-DA 是 Realm 管理扩展（Realm Management Extension）架构的一部分，它实现对可分配设备接口的安全分配。设备权限表（Device Permission Table，DPT）包含与物理地址关联的权限属性，并规定了一组相应的 DPT 检查，应用于来自设备的传入访问。

在本节中，术语 RME-DA 指 IO 一致（IO coherent）的设备，术语 RME-CDA 指具备全一致（fully coherent）能力的设备。

本规范在多加速器设备拓扑中支持 RME-DA 和 RME-CDA，其中加速器连接到一台主机。参见图 B7.1。

图 B7.1：连接两台加速器设备的主机

主机由单个或多个 SoC 裸片构成，构成可信计算基（Trusted Computing Base，TCB）。主机：

• 负责强制执行系统所需的安全策略。
• 可以连接多台设备。
• 可以直接挂载称为主机一致性内存（Host Coherent Memory，HCM）的内存。HCM 可被主机或任何全一致或 IO 一致的设备一致性地访问。
• 不得向设备发送 Stash 监听，除非该缓存行已被合法允许由该设备缓存。
• 允许向设备发送 DVMOp 请求或 SnpDVMOp 监听。

设备是单个物理芯片（或小芯片），从信任角度被视为单一单元，并单独进行证明（attestation）。设备：

• 仅在一组 Realm 范围内整体受信，并受信在需要时维持 Realm 间的隔离。
• 可以拥有私有的内存映射资源。
• 可以拥有一个或多个接口。
• 可以直接挂载称为设备一致性内存（Device Coherent Memory，DCM）的内存。DCM 可被主机、该设备以及其他一致性设备一致性地访问。
• 只有在访问经由主机计算节点中转时，才能访问另一台一致性设备的 DCM。
• 仅在 Realm 和 Non-secure 物理地址空间（PAS）中操作。
• 预计（但不要求）在发往主机的所有请求中包含以下字段：
  • 安全状态（SecSID1）字段
  • 流 ID（StreamID）字段
• 仅接收针对信任该设备的 Realm 所拥有的内存区域的监听请求。
• 不能直接连接到另一台设备。
• 不允许向主机发送 DVMReq 或 DVMSync 请求。

主机和设备都可以拥有多个请求节点和 Home 节点。

预计主机会对发往或来自设备的某些消息执行额外检查。这些检查可以确保：

• 从设备发往 HCM 的请求被允许访问该内存。这意味着设备不能发出带有随机 PA 的请求并期望获得对该位置的访问。
• 来自设备的监听仅针对 DCM。这意味着设备不能发出带有任意 PA 的请求来获取对某位置的访问。
• 针对已缓存 HCM 位置而发往设备的监听，只暴露设备被允许观察的访问。这意味着设备无法建立关于所有可信系统活动的完整图景以实施更有针对性的攻击。

有关 RME-DA 和 RME-CDA 的更多信息，参见 1。

B7.2 支持 RME-DA 和 RME-CDA 的字段（Fields supporting RME-DA and RME-CDA）

用于启用 RME-DA 和 RME-CDA 支持的字段包括：

• StreamID ：流标识符（Stream Identifier）。StreamID 是与同一系统 MMU 上下文关联的一个或一组 Requester 所发出请求流的唯一标识符。接口上消息中的 StreamID 字段的适用性由 DevAssign_Support 属性定义。 注意：与 PCIe 对接时，StreamID 是与单个 PCIe 端点（endpoint）关联的 Requester ID。
• SecSID1：安全流标识符（Secure Stream Identifier）。SecSID1 限定 StreamID 的安全状态。接口上消息中的 SecSID1 字段的适用性由 DevAssign_Support 属性定义。
• MECID：内存加密上下文标识符（Memory Encryption Context Identifier）。MECID 是分配给内存访问的标识符，将每次访问与一个内存加密上下文关联。MECID 值对每个 Realm 是唯一的。接口上消息中的 MECID 字段的适用性由 MEC_Support 属性定义。

有关这些字段及其适用性的更多细节，参见 1。

B7.3 主机与设备的职责（Host and device responsibilities）

有关支持 RME-DA 或 RME-CDA 的系统中主机或设备职责的细节，参见 4 和 5。

B7.4 每个设备的请求节点数（Request Nodes per device）

在加速器挂接配置中，当 DevAssign_Support_Tx 属性指示某接口被表示为一台设备时：

• 在该接口上，允许的请求节点最大数量为 16 个。其中最多 8 个节点可以是 RN-F，其余可以是 IO 一致的请求节点。RN-F 节点必须被分配 0 到 7 范围内的节点 ID 值。
• 接口必须精确跟踪设备缓存，以确定该设备上的某个 RN-F 是否缓存了缓存行的副本。

注意：Home 处跟踪内存缓存的方式决定了监听过滤器（snoop filter）实现的效率。

精确知道某缓存行被缓存在何处，可使 Home 向该缓存发送有针对性的监听。

使用粗粒度跟踪时，Home 需要将监听多播到缓存的子集，或将监听广播到除 Requester 之外的所有缓存。监听的多播和广播都涉及 Home 发送多个单播监听。

Home 处的细粒度跟踪器（通常是监听过滤器或目录）的大小随需要精确跟踪的缓存数量的增加而增大。

为控制细粒度跟踪监听过滤器大小的增长，对每个接口的缓存代理（caching agent）数量设置了架构上限。支持 RME-CDA 的主机可以预先按该上限来规划其缓存跟踪结构的容量。

---

第 B8 章 接口状态管理（Interface state management）

本章描述 C2C 接口的状态管理，包含以下小节：

• B8.1 简介
• B8.2 接口激活与去激活
• B8.3 Connect 杂项消息
• B8.4 一致性连接与断开
• B8.5 DVM 域连接与断开

B8.1 简介（Introduction）

硬件流程管理接口（从而管理链路）的连接状态。

三组不同的连接与断开流程分别影响全一致流量、DVM 消息或所有协议消息。

B8.2 接口激活与去激活（Interface Activation and Deactivation）

接口激活与去激活用于启用或禁用跨接口的所有协议流量的传输。

MiscU 消息类型中的 Activation 消息支持接口激活与去激活。这些消息的细节参见 B8.2.2 消息。

B8.2.1 活动状态（Activity states）

接口可以处于四种活动状态之一：

• STOP：接口与所有协议活动断开。
• ACTIVATE：接口正在准备启用协议活动。
• RUN：接口已启用协议活动。
• DEACTIVATE：接口正在准备与所有协议活动断开。

各状态下接口行为的细节参见 B8.2.4 激活与去激活流程。

允许的状态转换为：

• STOP → ACTIVATE
• ACTIVATE → RUN
• RUN → DEACTIVATE
• DEACTIVATE → STOP

图 B8.1 展示了允许的状态转换。

图 B8.1：激活/去激活状态转换

当接口进入 STOP 状态时，远程信用被隐式归还。也就是说，所有发送器消息信用计数被清零，接收器消息信用被重置为接口初始化时的值。

B8.2.2 消息（Messages）

定义了以下五条消息来支持接口激活流程：

• ActivateReq
• ActivateAck
• DeactivateReq
• DeactivateAck
• DeactivateHint

消息格式参见表 B8.2，ActivationOp 编码参见表 B8.1。

B8.2.2.1 ActivateReq 和 ActivateAck

ActivateReq 和 ActivateAck 消息对用于将接口从 STOP 状态迁移到 RUN 状态。关于何时发送 ActivateReq 和 ActivateAck 消息以及接口收到它们时的响应，参见 B8.2.4 激活与去激活流程中的 STOP 和 ACTIVATE 状态条目。

B8.2.2.2 DeactivateReq 和 DeactivateAck

DeactivateReq 和 DeactivateAck 消息对用于将接口从 RUN 状态迁移到 STOP 状态。

B8.2.2.3 DeactivateHint

DeactivateHint 是一条向远程接口告知发送器已准备好去激活接口的消息。该消息的特点包括：

• 它是一条 MiscU.Activation 消息，参见表 B8.1。
• 接口只允许在 RUN 激活状态下发送此消息。
• 接口允许发送 DeactivateHint 后又在链路上恢复活动。
• 接口允许发送多条 DeactivateHint 消息，消息之间可以有也可以没有链路活动。
• 接口允许不先发送 DeactivateHint 消息而直接发送 DeactivateReq。
• 如果接口已发送 DeactivateHint，则允许在不等待对 DeactivateHint 的任何响应的情况下发送 DeactivateReq。

注意：发送方可以使用启发式方法来决定何时发送 DeactivateHint 消息。例如，启发式方法可以使用链路不活动的时长，即链路上没有发送或接收任何消息的时间段。

• 接收器允许以以下方式响应 DeactivateHint 消息：
  • 可以丢弃该提示而不做任何状态改变。
  • 接受该提示，并在满足发送条件时以 DeactivateReq 响应。

B8.2.3 Activation 消息格式

表 B8.1 给出了 Activation 消息中 ActivationOp 字段的编码。

表 B8.1：MiscU.Activation 消息中 ActivationOp 字段的编码

ActivationOp3:0	消息
0000	ActivateReq
0001	ActivateAck
0010	DeactivateReq
0011	DeactivateAck
0100	DeactivateHint
其他	保留（Reserved）

激活消息的细节参见 B8.2.2 消息。

表 B8.2 给出了 Activation 消息的字段。

表 B8.2：Activation 消息字段

字段名	宽度（比特）	值
MsgType	4	0b0000
MiscOp	4	0b0010
ActivationOp	4
PropertyReq	1	0 或 1ᵃ
RsvdZero	19
总计（比特）	32

ᵃ 当 ActivationOp == ActivationReq 时适用，否则不适用且必须为 0。

B8.2.3.1 PropertyReq

该字段值决定在接口激活完成时是否需要属性交换。

• 当 PropertyReq = 0：不得交换属性。
• 当 PropertyReq = 1：在 ActivateAck 被发送和接收之后，必须发送 Properties 消息。

该字段在 ActivationOp 为 ActivateReq 时适用。对于其他 Activate 消息类型，该字段不适用且必须为 0。

参见 B10.1 简介。

B8.2.4 激活与去激活流程（Activation and Deactivation flow）

本节描述接口在每种激活状态下的行为。

接口去激活的启动条件有两种选项。这两种去激活条件由 Deactivation_Support 属性定义：

1. 协议无关（Protocol agnostic）：允许在 RUN 状态下随时发送 DeactivateReq，无需检查协议消息流。此外，在发送 DeactivateReq 之后、直到接口回到 RUN 状态之前，不得发送协议消息。
2. 协议感知（Protocol aware）：仅当接口处于 RUN 状态且两个方向上都完全静默（quiesce）时，才允许发送 DeactivateReq。使接口静默的原因可能是为了给接口或芯片下电。静默条件要求双方都不得有任何待发送的协议流量，即所有未完成的请求必须已完成、不得发送响应消息、不得跨链路发送新的请求或监听消息。

接口在每种激活和去激活状态下的行为包括：

• STOP
  • 信用在该状态下被重置。
  • 接收器持有所有信用，但不得发送任何信用。
  • 发送器没有信用，只允许发送 LinkStatus 或 ActivateReq 消息。
  • 如果接口想开始发送其他消息，必须发送 ActivateReq 消息。
  • 当接口已发送或收到 ActivateReq 消息时，必须迁移到 ACTIVATE 状态。
• ACTIVATE
  • 如果尚未发送，则发送 ActivateReq 消息。
  • 如果尚未收到，则等待 ActivateReq 消息。
  • 收到 ActivateReq 消息后，必须及时发送 ActivateAck 作为对该请求的响应。
  • 在 ActivateAck 发送之后，允许（但不要求）发送信用。
  • 在 ActivateAck 收到之后，可以接收信用。
  • 当接口已发送并收到 ActivateAck 消息时，必须迁移到 RUN 状态。
• RUN
  • 如果被请求，则发送接口属性。
  • 必须发送与协商的接口属性相适应的信用。
  • 可以发送带信用的消息。
  • 如果接口可能想要停止，可以发送 DeactivateHint 消息。该消息可能被远端忽略，也可能促使其发送 DeactivateReq 消息。
  • 如果接口想要迁移到 STOP 状态，可以发送 DeactivateReq 消息。
  • 当接口已发送或收到 DeactivateReq 消息时，必须迁移到 DEACTIVATE 状态。
• DEACTIVATE
  • 如果尚未发送，则在所需活动完成后发送 DeactivateReq 消息。
  • 在收到 DeactivateReq 之前，必须继续发送信用。
  • 在发送 DeactivateReq 消息之后，不得发送带信用的消息。
  • 收到 DeactivateReq 之后，必须及时发送 DeactivateAck。
  • 在发送 DeactivateAck 消息之后，不得发送信用。
  • 当接口已发送并收到 DeactivateAck 消息时，必须迁移到 STOP 状态。

B8.2.4.1 激活触发（ActTrigger）

定义了一个软件可见的 2 位激活控制字段 ActTrigger，使硬件能够发起激活或去激活流程。

表 B8.3 给出了 ActTrigger 字段的编码。

表 B8.3：ActTrigger 位编码

ActTrigger1:0	描述
00	无动作
01	发送 ActivateReq
10	发送 DeactivateReq
11	保留（Reserved）

只需在一侧设置触发位即可启动激活或去激活序列。

例如，如果加速器通过 C2C 链路挂接到主机，触发器可以只在主机侧实现。

B8.3 Connect 杂项消息（Connect Miscellaneous messages）

MiscU.Connect 消息用于将接口连接到监听域和 DVM 域或从中断开。关于这些消息的使用方式，参见 B8.4 一致性连接与断开 和 B8.5 DVM 域连接与断开。

表 B8.4 给出了 Connect 消息的字段。

表 B8.4：MiscU.Connect 消息字段

字段名	宽度（比特）	值
MsgType	4	0b0000
MiscOp	4	0b0011
ConnectOp	4
RsvdZero	20
总计（比特）	32

表 B8.5 给出了 Connect 消息中 ConnectOp 字段的编码。

表 B8.5：MiscU.Connect 消息中 ConnectOp 字段的编码

ConnectOp3:0	消息
0000	CohConnectReq
0001	CohConnectAck
0010	CohDisconnectReq
0011	CohDisconnectAck
0100	DVMConnectReq
0101	DVMConnectAck
0110	DVMDisconnectReq
0111	DVMDisconnectAck
其他	保留（Reserved）

B8.4 一致性连接与断开（Coherency connect and disconnect）

接口一致性连接与断开消息用于将接口连接到一致性管理需求或从中断开。

B8.4.1 一致性连接状态（Coherency connect states）

C2C 接口的每个方向可以处于四种一致性状态之一。各状态的细节参见表 B8.6。

• CohDisabled：接口上的 Requester 缓存不包含一致性数据。
• CohConnect：接口正在请求被允许缓存一致性数据。
• CohEnabled：接口上的 Requester 参与一致性数据交换。
• CohDisconnect：接口上的 Requester 正在请求退出一致性数据交换。

芯片上参与一致性域的 Requester 与该接口上的 Home 节点向远程节点发送监听是相互独立的。因此，一致性连接与断开是按方向进行的。互连的一致性状态影响该接口上的所有 Requester。

允许的状态转换为：

• CohDisabled → CohConnect
• CohConnect → CohEnabled
• CohEnabled → CohDisconnect
• CohDisconnect → CohDisabled

从 CohDisconnect 迁移到 CohDisabled 状态的接口必须保留（而不是清零）其持有的来自远端的 SNP 信用。

图 B8.2 展示了允许的状态转换。

图 B8.2：一致性域连接/断开状态转换

B8.4.2 消息（Messages）

作为 MiscU.Connect 消息类型的一部分，定义了四条消息来支持接口一致性连接流程：

1. CohConnectReq
2. CohConnectAck
3. CohDisconnectReq
4. CohDisconnectAck

消息格式参见表 B8.4，ConnectOp 编码参见表 B8.5。

表 B8.6 描述了两个接口在连接到一致性域和从一致性域断开期间的行为。

表 B8.6：C2C 一致性连接状态描述

状态	Tx C2C 接口行为	Rx C2C 接口行为
CohDisabled	此接口上的 Requester 不得包含一致性数据。 不得发送可监听的分配型（Snoopable Allocating）请求。 不会： -- 从远端接收监听请求； -- 影响反方向的一致性连接状态。 允许向远端授予 SNP 消息信用。 必须保持在 CohDisabled 状态，直到 CohConnectReq 被发送，然后必须迁移到 CohConnect 状态。	不得向远端发送监听请求。 必须能够处理接收 SNP 消息信用。 不影响反方向的一致性连接状态。 必须保持在 CohDisabled 状态，直到收到 CohConnectReq，然后必须迁移到 CohConnect 状态。
CohConnect	允许发送 SNP 消息信用。 必须做好响应监听请求的准备。 必须保持在 CohConnect 状态，直到收到 CohConnectAck，然后必须迁移到 CohEnabled 状态。	必须能够处理接收 SNP 消息信用。 必须及时发送 CohConnectAck，然后迁移到 CohEnabled 状态。
CohEnabled	允许发送可监听的分配型请求。 -- 此接口上的 Requester 允许缓存一致性数据。 必须以符合一致性要求的方式响应任何收到的监听请求。 当希望从一致性域断开、且接口上的 Requester 缓存不包含一致性数据时，发送 CohDisconnectReq 并迁移到 CohDisconnect 状态。	允许按维持一致性的需要发送监听请求。 必须保持在 CohEnabled 状态，直到收到 CohDisconnectReq 消息，然后必须迁移到 CohDisconnect 状态。
CohDisconnect	不得发送可监听的分配型请求。 必须继续授予 SNP 信用。远端可能有排队待发的监听请求。 必须继续响应监听请求。 必须保持在 CohDisconnect 状态，直到收到 CohDisconnectAck，然后必须迁移到 CohDisabled 状态。	完成未完成的监听请求。 必须及时发送 CohDisconnectAck 消息并迁移到 CohDisabled 状态。

注意：一致性连接状态在每个方向上是独立的。接口的发送器可以继续发送监听请求，即使接口同侧的接收器处于一致性禁用（coherency disabled）状态。

B8.5 DVM 域连接与断开（DVM domain connect and disconnect）

DVM 域连接与断开消息用于将接口连接到地址转换表管理或从中断开。

B8.5.1 DVM 连接状态（DVM connect states）

C2C 接口可以处于四种 DVM 域连接状态之一。各状态的细节参见 B8.5.3 DVM 域连接与断开流程。

• DVMDisabled：接口已从 DVM 域中移除，不发送也不接收 DVM 请求。
• DVMConnect：接口正在请求加入 DVM 域。
• DVMEnabled：接口正在参与 DVM 域活动。
• DVMDisconnect：接口正在请求退出 DVM 域。

当接口将自身从 DVM 域中移除时，它既不发送也不接收 DVM 请求。

允许的状态转换为：

• DVMDisabled → DVMConnect
• DVMConnect → DVMEnabled
• DVMEnabled → DVMDisconnect
• DVMDisconnect → DVMDisabled

图 B8.3 展示了允许的状态转换。

图 B8.3：DVM 域连接/断开状态转换

B8.5.2 消息（Messages）

定义了以下四条消息（归并为 MiscU.Connect 消息类型的一部分）来支持接口 DVM 连接流程：

• DVMConnectReq
• DVMConnectAck
• DVMDisconnectReq
• DVMDisconnectAck

消息格式参见表 B8.4，ConnectOp 编码参见表 B8.5。

B8.5.3 DVM 域连接与断开流程

接口在每种 DVM 连接状态下的行为包括：

• DVMDisabled
  • 接口上的 Requester 不得缓存地址转换。
  • 接口不得发送或接收 DVM 事务。
  • 接口允许接收 DVMConnectReq 消息。
  • 如果接口想要参与 DVM 域活动，可以发送 DVMConnectReq 消息。
  • 当接口已发送或收到 DVMConnectReq 消息时，必须迁移到 DVMConnect 状态。
• DVMConnect
  • 如果尚未发送，则发送 DVMConnectReq。
  • 如果尚未收到，则等待 DVMConnectReq 消息。
  • 一旦收到 DVMConnectReq，及时发送 DVMConnectAck。
  • 必须保持在 DVMConnect 状态，直到 DVMConnectAck 被发送并收到，然后迁移到 DVMEnabled 状态。
• DVMEnabled
  • 允许发送 DVM 事务。
  • 可以接收 DVM 事务。
  • 如果接口想要从 DVM 域中移除，必须先完成所有未完成的 DVM 事务，然后发送 DVMDisconnectReq。
  • 当接口已发送或收到 DVMDisconnectReq 消息时，必须迁移到 DVMDisconnect 状态。
• DVMDisconnect
  • 如果尚未发送，则等待所有未完成的 DVM 事务完成，然后发送 DVMDisconnectReq 消息。
  • 发送 DVMDisconnectReq 之后，不得再发送任何 DVM 请求。
  • 在收到 DVMDisconnectReq 之前，必须继续响应 DVM 请求。
  • 收到 DVMDisconnectReq 之后，必须及时发送 DVMDisconnectAck。
  • 当接口已发送并收到 DVMDisconnectAck 消息时，必须迁移到 DVMDisabled 状态。

---

第 B9 章 接口初始化（Interface initialization）

本章描述 C2C 接口的初始化，包含以下小节：

• B9.1 简介
• B9.2 初始化流程

B9.1 简介（Introduction）

C2C 接口初始化建立接口，使协议消息的发送和接收得以进行。

初始化流程包含以下步骤：

1. 与链路层协调，检查接口内远程协议层是否已就绪（up）。
2. 使用 MiscU.Properties 消息交换接口属性。这为接口建立起先交换消息信用、随后交换协议消息的条件。

注意：全局或公共能力的发现、枚举和协商------例如 Req_Addr_Width、节点 ID 分配、地址映射、路由表设置------不由硬件属性交换流程管理。不属于硬件属性交换流程的能力交换，预计由软件处理。

B9.2 初始化流程（Initialization flow）

初始化流程的关键特性包括：

• 在链路初始化完成之前，保证链路两侧的协议层能够接收杂项（Miscellaneous）消息。这使协议层能够使用默认容器格式交换 MiscU.Activation 消息。

图 B9.1 展示了接口初始化可能的事务流程。

图 B9.1：C2C 链路初始化

接口初始化的顺序如下：

1. 接口初始化从链路复位和初始化开始。在链路初始化完成之前，链路层必须唤醒协议层。链路层到协议层的唤醒握手方法由实现定义（IMPLEMENTATION DEFINED）。图 B9.1 展示了链路层与协议层之间使用 CXS 接口的唤醒握手示例。
   • 链路层向本地协议层发送 CXSACTIVEREQ。
   • 一旦就绪，协议层发送 CXSACTIVEACK 响应。
   • 为响应来自链路层的 CXSACTIVEREQ，协议层在反方向执行相同的握手。这个反向 CXSACTIVE 握手最晚可以在端到端（即协议层到远程协议层）的 Activate 握手期间执行。
2. 链路层初始化完成后，链路层必须能够接收并识别来自远端的 ActivateReq。这是为了能够接收 (4) 中所述的 ActivateReq 请求消息。
3. 链路层初始化完成后，链路层向本地协议层发送 MiscU.LinkStatus 消息。LinkStatus 消息通知协议层链路初始化已完成，并包含已协商的 flit 格式信息。LinkStatus 消息细节参见 B9.2.1 LinkStatus 消息格式。
4. 协议层确保远程协议层已激活：
   • 每个协议层向远程协议层发送 ActivateReq 消息。
   • 协议层以 ActivateAck 消息响应收到的 ActivateReq。
5. 在此阶段，如果在 ActivateReq 中有请求，双方已准备好使用 Properties 消息交换支持的属性值：
   • 协议层向远端发送 Properties 消息。
   • 一旦协议层收到来自远端的 Properties 消息，协议层即被允许向远端授予信用。

接口属性及其交换与协商的细节，参见第 B10 章 协议层属性交换。

在链路激活阶段完成、且需要进行属性交换时，接口的一致性和 DVM 状态处于 Disabled 状态。如有需要，必须分别通过各自的一致性连接流程和 DVM 连接流程来启用接口一致性连接和 DVM 连接。

B9.2.1 LinkStatus 消息格式

MiscU.LinkStatus 消息由链路层使用，用于向协议层告知链路层初始化的完成以及链路电源状态的变化。该消息在 B9.2 初始化流程所述的接口初始化期间发送，并且每当物理链路电源状态发生变化时，链路层都允许发送该消息。

表 B9.1 给出了 LinkStatus 消息的字段。

表 B9.1：LinkStatus 消息字段

字段名	宽度（比特）	值
MsgType	4	0b0000
MiscOp	4	0b0110
FlitFormat	3
LinkPowerState	3
RsvdZero	18
总计	32

B9.2.1.1 FlitFormat

LinkStatus 消息中的 FlitFormat 字段由链路层使用，用于告知协议层填充链路层特定字段（如链路头、FEC 和 CRC）需要多少字节。

表 B9.2 给出了 FlitFormat 值到协议层容器格式的映射。

表 B9.2：LinkStatus 消息中 FlitFormat 的编码

FlitFormat2:0	所需字节数	备注
000	保留（Reserved）
001	6	兼容 Format X
010	20	兼容 Format Y
其他	保留（Reserved）

B9.2.1.2 LinkPowerState

LinkStatus 消息中的 LinkPowerState 字段允许链路层向协议层告知链路的电源状态。该信息在链路初始化期间发送给协议层，并且在链路电源状态发生任何变化时也会发送。

表 B9.3 给出了 LinkPowerState 字段的编码。

表 B9.3：LinkStatus 消息中 LinkPowerState 的编码

LinkPowerState2:0	电源状态
000	Disabled
001	Active
100	Reset
其他	保留（Reserved）

注意：协议层在收到带有 Reset 的 LinkStatus 消息后，可能需要重置某些协议配置设置。

---

第 B10 章 协议层属性交换（Protocol layer property exchange）

本章描述协议层的属性交换，包含以下小节：

• B10.1 简介
• B10.2 片上载荷属性
• B10.3 片上操作码与流程属性
• B10.4 C2C 特有属性
• B10.5 MiscU.Properties 消息中的属性打包
• B10.6 属性打包到寄存器

B10.1 简介（Introduction）

在接口初始化完成、且激活序列要求进行属性交换之后，在发送任何协议消息之前，每条逻辑链路的两个方向都必须交换接口属性。

属性用于声明一项能力。

接口属性分为三类：

1. 片上载荷（On-chip payload）
   • 描述某些片上字段是否存在、或其宽度、或两者。
   • 允许在消息选择之前对载荷字段进行优化，从而可能实现更高效的打包。
2. 片上操作码/流程（On-chip opcode/flow）
   • 描述片上对特定类别事务的支持。
   • 通过阻止不受支持的消息在 C2C 链路上发送，确保接口不发生死锁。
3. C2C 特有（C2C specific）
   • 描述接口支持哪个版本的规范，以确保向后兼容。
   • 提供辅助链路使用的附加信息。

逻辑链路的两侧都发送 MiscU.Properties 消息，以表明各自的能力。

每条 Properties 消息中的属性值由一组定义发送该消息的芯片能力的寄存器驱动。

某些属性具有接收器（Rx）和发送器（Tx）两种变体：

• Property_Rx：指示发送 Properties 消息的芯片作为接收器的能力。发送器芯片必须能够终结（terminate）接收器芯片表明其不支持的任何消息。
• Property_Tx：指示发送 Properties 消息的芯片作为发送器的能力。接收器芯片了解其可能收到的内容，有助于实现潜在的功耗优化。

没有 _Tx 或 _Rx 后缀的属性归类为统一（Uniform）属性，适用于接口的两个方向。

允许软件在发送 Properties 消息之前更新寄存器值，以降低接口所通告的能力。

收到 Properties 消息后，接收方必须将所交换的每个属性与自己的属性进行比较。

当属性值一致时，无需修改行为。

当属性不同时，发送器允许相应地调整其行为。所需的调整取决于属性分类以及以下方面的差异：

• 片上载荷

  • 如果发送器（_Tx）属性为 True 而接收器（_Rx）属性为 False，则允许（但不要求）在消息选择和容器打包之前将关联字段值置零。
  • 如果发送器（_Tx）属性为 False 而接收器（_Rx）属性为 True，则必须在消息选择和容器打包之前将关联字段值置零。
  • 如果发送器（_Tx）属性值大于接收器（_Rx）属性值，则允许（但不要求）发送器在消息选择和容器打包之前将接收器不支持的最高有效位置零。
  • 如果发送器（_Tx）属性值小于接收器（_Rx）属性值，则必须在消息选择和容器打包之前由发送器对关联字段值进行零扩展。

• 片上操作码与流程

  • 如果本地发送器（_Tx）属性为 True 而接收器（_Rx）属性为 False，发送器必须以符合片上协议的方式终结或降级（downgrade）任何关联的片上消息。降级或终结的具体方式由实现定义（IMPLEMENTATION DEFINED）。

  注意：例如：

  • 降级包括：如果目标芯片不支持 stash 但持有完成事务所需的数据副本，则将 SnpUniqueStash 转换为 SnpUnique。
  • 终结包括：当确定下游不支持原子操作时，Requester 在本地执行原子事务。这可以通过 Requester 上的片上 BROADCASTATOMIC 信号或替代的控制寄存器来实现。

  • 如果发送器（_Tx）属性为 False 而接收器（_Rx）属性为 True，则无需进一步动作。关联的片上协议消息不应被提供给发送器以在 C2C 链路上传输。
  • 可选地，如果接收器（_Rx）属性为 True 而发送器（_Tx）属性为 False，接收器芯片可能可以通过关闭部分逻辑来节省功耗。

• C2C 特有

  • 如果发送器（_Tx）属性为 True 而接收器（_Rx）属性为 False，发送器不得使用关联的特性或事务流程。
  • 如果发送器（_Tx）属性为 False 而接收器（_Rx）属性为 True，接收器可能可以通过关闭部分逻辑来节省功耗。
  • 如果发送器（_Tx）和接收器（_Rx）属性的值不是 True 或 False，且链路两侧的这些值不同，将有附加说明描述预期行为。
  • 如果链路任一侧的统一（Uniform）属性不匹配，将有附加说明描述预期行为。

链路上相反方向的属性可以不同。也就是说，某些事务可能只能在一个方向上发起，而不能在另一个方向上发起。

B10.1.1 Properties 消息格式

MiscU.Properties 字段由协议层使用，用于与远程协议层交换各自支持的属性值。

表 B10.1 给出了 Properties 字段的编码。Payload 字段的细节参见表 B10.11。

表 B10.1：Properties 消息字段

字段名	宽度（比特）	值
MsgType	4	0b0000
MiscOp	4	0b0101
Payload	152
总计（比特）	160

B10.2 片上载荷属性（On-chip payload properties）

表 B10.2 列出了用于描述芯片作为接收器时特定片上字段载荷特征的属性。

表 B10.2：接收器片上载荷属性

属性	宽度（比特）	描述
MPAM_Support_Rx	2	对 MPAM 的支持。 0b00：False，MPAM 字段不存在。 0b01：True，MPAM 字段存在。 其他：保留。
PBHA_Support_Rx	2	对 PBHA 的支持。 0b00：False，PBHA 字段不存在。 0b01：True，PBHA 字段存在。 其他：保留。
MEC_Support_Rx	2	对 MEC 的支持。 0b00：False，MECID 字段不存在。 0b01：True，MECID 字段存在。 其他：保留。
RSVDC_REQ_Rx	3	REQ 通道上 RSVDC 的宽度。 0b0000：0 位；0b0001：4 位；0b0010：8 位；0b0011：12 位；0b0100：16 位；0b0101：24 位；0b0110：32 位；其他：保留。
RSVDC_DAT_Rx	3	DAT 通道上 RSVDC 的宽度。 0b0000：0 位；0b0001：4 位；0b0010：8 位；0b0011：12 位；0b0100：16 位；0b0101：24 位；0b0110：32 位；其他：保留。

表 B10.3 列出了用于描述芯片作为发送器时特定片上字段载荷特征的属性。

表 B10.3：发送器片上载荷属性

属性	宽度（比特）	描述
MPAM_Support_Tx	2	对 MPAM 的支持。 0b00：False，MPAM 字段不存在。 0b01：True，MPAM 字段存在。 其他：保留。
PBHA_Support_Tx	2	对 PBHA 的支持。 0b00：False，PBHA 字段不存在。 0b01：True，PBHA 字段存在。 其他：保留。
MEC_Support_Tx	2	对 MEC 的支持。 0b00：False，MECID 字段不存在。 0b01：True，MECID 字段存在。 其他：保留。
RSVDC_REQ_Tx	3	REQ 通道上 RSVDC 的宽度。 0b0000：0 位；0b0001：4 位；0b0010：8 位；0b0011：12 位；0b0100：16 位；0b0101：24 位；0b0110：32 位；其他：保留。
RSVDC_DAT_Tx	4	DAT 通道上 RSVDC 的宽度。 0b000：0 位；0b001：4 位；0b010：8 位；0b011：12 位；0b100：16 位；0b101：24 位；0b110：32 位；其他：保留。

B10.3 片上操作码与流程属性（On-chip opcode and flow properties）

表 B10.4 列出了用于描述芯片作为接收器时特定片上操作码与流程支持的属性。

表 B10.4：接收器片上操作码/流程属性

属性	宽度（比特）	描述
Atomic_Transactions_Rx	2	对原子事务的支持。 0b00：False，不支持原子事务。 0b01：True，支持原子事务。 其他：保留。
Cache_Stash_Transactions_Rx	2	对 Stash 请求和监听的支持。 0b00：False，不支持 Stash 事务。 0b01：True，支持 Stash 事务。 其他：保留。
Persist_Transactions_Rx	2	对面向 PoP 和 PoDP 的 CMO 操作的支持。 0b00：False，不支持 Persist CMO 事务。 0b01：True，支持 Persist CMO 事务。 其他：保留。
Deferrable_Write_Rx	2	对 WriteNoSnpDef 的支持。 0b00：False，不支持可推迟写（Deferrable Write）事务。 0b01：True，支持可推迟写事务。 其他：保留。
RME_Support_Rx	2	对 Realm 管理扩展的支持，包括 Realm 和 Root 物理地址空间以及 PoPA 缓存维护操作。 0b00：False，不支持 RME 事务。 0b01：True，支持 RME 事务。 其他：保留。
Snoop_Support_Rx	2	对监听事务的支持。 0b00：False，不支持监听事务。 0b01：True，支持监听事务。 其他：保留。
DVM_Support_Rx	2	对 DVM 消息的支持。 0b00：False，不支持 DVM 事务。 0b01：True，支持 DVM 事务。 其他：保留。
MTE_Support_Rx	2	对 MTE 的支持。 0b00：False，不支持 MTE。 0b01：缩减的 MTE 事务支持。 0b10：完整的 MTE 事务支持。 0b11：保留。
CMO_Transactions_Rx	2	对 CMO 事务的支持。 0b00：False，不支持 CMO 事务。 0b01：True，支持 CMO 事务。 其他：保留。

表 B10.5 列出了用于描述芯片作为发送器时特定片上操作码与流程支持的属性。

表 B10.5：发送器片上操作码/流程属性

属性	宽度（比特）	描述
Atomic_Transactions_Tx	2	对原子事务的支持。 0b00：False，不会发送原子事务。 0b01：True，可以发送原子事务。 其他：保留。
Cache_Stash_Transactions_Tx	2	对 Stash 请求和监听的支持。 0b00：False，不会发送 Stash 请求或监听。 0b01：True，可以发送 Stash 请求或监听。 其他：保留。
Persist_Transactions_Tx	2	对面向 PoP 和 PoDP 的 CMO 操作的支持。 0b00：False，不会发送 Persist CMO 事务。 0b01：True，可以发送 Persist CMO 事务。 其他：保留。
Deferrable_Write_Tx	2	对 WriteNoSnpDef 的支持。 0b00：False，不会发送可推迟写事务。 0b01：True，可以发送可推迟写事务。 其他：保留。
RME_Support_Tx	2	对 Realm 管理扩展的支持，包括 Realm 和 Root 物理地址空间以及 PoPA 缓存维护操作。 0b00：False，不会发送 RME 事务。 0b01：True，可以发送 RME 事务。 其他：保留。
Snoop_Support_Tx	2	对监听事务的支持。 0b00：False，不会发送监听事务。 0b01：True，可以发送监听事务。 其他：保留。
DVM_Support_Tx	2	对 DVM 消息的支持。 0b00：False，不会发送 DVM 事务。 0b01：True，可以发送 DVM 事务。 其他：保留。
MTE_Support_Tx	2	对 MTE 的支持。 0b00：False，只发送 TagOp 为 Invalid 的事务。 0b01：缩减的 MTE 事务支持。不会发送 TagOp 为 Match 的事务，可以发送其他 TagOp 值的事务。 0b10：完整的 MTE 事务支持。可以发送任何 TagOp 值的事务。 0b11：保留。
CMO_Transactions_Tx	2	对 CMO 事务的支持。 0b00：False，不会发送 CMO 事务。 0b01：True，可以发送 CMO 事务。 其他：保留。

B10.4 C2C 特有属性（C2C specific properties）

本节描述 C2C 特有属性，包括：

• B10.4.1 统一属性
• B10.4.2 接收器和发送器属性

B10.4.1 统一属性（Uniform properties）

表 B10.6 列出了用于描述接口两个方向上统一的 C2C 特有能力的属性。

表 B10.6：统一的 C2C 特有属性

属性	宽度（比特）	描述
Protocol	4	支持的协议。 0b0000：CHI C2C；其他：保留。
Version	4	支持的版本。 0b0000：A；其他：保留。
Num_Properties_Messages	4	此接口每条逻辑链路可发送和接收的 MiscU.Properties 消息数量。 0b0000：1；其他：保留。
Container_Format	4	接口两个方向上支持的容器格式。不允许为 0b0000。 Bit 0（Format X）：0 = 不支持，1 = 支持。 Bit 1（Format Y）：0 = 不支持，1 = 支持。 Bit 2 和 3：保留。
Deactivation_Support	4	接口支持的去激活模式。 Bit 0（Protocol Agnostic，协议无关）：0 = 不支持，1 = 支持。 Bit 1（Protocol Aware，协议感知）：0 = 不支持，1 = 支持。 Bit 2 和 3：保留。

B10.4.2 接收器和发送器属性（Receiver and Transmitter properties）

表 B10.7 列出了用于描述接口作为接收器的 C2C 特有能力的属性。

表 B10.7：接收器 C2C 特有属性

属性	宽度（比特）	描述
Num_RP_REQ_Rx	4	指示接口在 REQ 通道上支持的资源平面最大数量。 0b0000：1；0b0001：2；0b0010：3；0b0011：4；0b0100：5；0b0101：6；0b0110：7；0b0111：8；其他：保留。
WritePush_Support_Rx	2	指示接口是否支持写事务的 WritePush 流程。 0b00：False，立即写和原子事务不支持 WritePush。 0b01：True，立即写和原子事务均支持 WritePush。 其他：保留。
DVMPush_Support_Rx	2	指示接口是否支持 DVM 事务的 WritePush 流程。 0b00：False，DVM 事务不支持 WritePush。 0b01：True，DVM 事务支持 WritePush。 其他：保留。 注意：无论 DVMPush_Support_Rx 属性值如何，DVM 事务都不能使用 WrReqDataS 消息。
DevAssign_Support_Rx	4	对 RME-DA 或 RME-CDA 的支持。仅在 RME_Support_Rx 为 True 时有效。 仅用于提供信息，以辅助设置或调试，预计单独来看不产生任何功能影响。 每个比特定义本芯片可以连接的对端芯片的角色： Bit 0（Host）：0 = 不能连接主机；1 = 可以连接主机。 Bit 1（Device_StreamID_SecSID1）：0 = 不能连接设备，不使用 SecSID1 和 StreamID 字段；1 = 可以连接设备，可以使用 SecSID1 和 StreamID 字段。 Bit 2（Device_NoStreamID_NoSecSID1）：0 = 不能连接设备，不使用 SecSID1 和 StreamID 字段；1 = 可以连接设备，不使用 SecSID1 和 StreamID 字段。 Bit 3：保留。

表 B10.8 列出了用于描述接口作为发送器的 C2C 特有能力的属性。

表 B10.8：发送器 C2C 特有属性

属性	宽度（比特）	描述
Num_RP_REQ_Tx	4	指示接口在 REQ 通道上支持的资源平面最大数量。 0b0000：1；0b0001：2；0b0010：3；0b0011：4；0b0100：5；0b0101：6；0b0110：7；0b0111：8；其他：保留。
WritePush_Support_Tx	2	指示接口是否支持写事务的 WritePush 流程。 0b00：False，立即写和原子事务不支持 WritePush。 0b01：True，立即写和原子事务均支持 WritePush。 其他：保留。
DVMPush_Support_Tx	2	指示接口是否支持 DVM 事务的 WritePush 流程。 0b00：False，DVM 事务不会使用 WrReqDataL 消息。 0b01：True，DVM 事务可以使用 WrReqDataL 消息。 其他：保留。 注意：无论 DVMPush_Support_Tx 属性值如何，DVM 事务都不能发送 WrReqDataS 消息。
DevAssign_Support_Tx	4	对 RME-DA 或 RME-CDA 的支持。仅在 RME_Support_Tx 为 True 时有效。 仅用于提供信息，以辅助设置或调试，预计单独来看不产生任何功能影响。 每个比特定义本芯片可向对端芯片呈现的角色： Bit 0（Host）：0 = 不能呈现为主机；1 = 可以呈现为主机。 Bit 1（Device_StreamID_SecSID1）：0 = 不能呈现为设备，不发送 SecSID1 和 StreamID 字段；1 = 可以呈现为设备，发送 SecSID1 和 StreamID 字段。 Bit 2（Device_NoStreamID_NoSecSID1）：0 = 不能呈现为设备，不发送 SecSID1 和 StreamID 字段；1 = 可以呈现为设备，不发送 SecSID1 和 StreamID 字段。 Bit 3：保留。

B10.4.3 交换的 C2C 特有属性不一致时的预期行为

表 B10.9 详细说明了当链路两侧的 C2C 特有属性不一致时的预期结果，这些属性包括：

• 统一属性
• 值不是 True 或 False 的发送器（_Tx）和接收器（_Rx）属性

表 B10.9：交换的 C2C 特有属性不一致时的预期行为

属性	预期行为
Protocol	如果远程接口支持的协议与本地接口不同，则可能存在不兼容。本版本规范仅支持一种协议。
Version	较新版本的接口预计向后兼容较旧版本。当版本不同时，双方必须协商以较旧版本运行。目前规范只有一个版本，因此两侧在支持的版本上不会不同。
Num_Properties_Msg	与 Protocol 属性相关联。发送器应只发送接收器能够接受的正确数量的 MiscU.Properties 消息。
收到的 Num_RP_REQ_Rx 与发送的 Num_RP_REQ_Tx	如果收到的 Num_RP_REQ_Rx 值大于发送的 Num_RP_REQ_Tx 值，不应出现任何功能问题。发送器可能会收到其不打算使用的资源平面的信用。 如果收到的 Num_RP_REQ_Rx 值小于发送的 Num_RP_REQ_Tx 值，当发送器芯片无法将流量整合到减少后的资源平面数量上时，可能会出现功能问题。发送器将不会收到其可能需要用于流量依赖隔离的资源平面的信用。这应在芯片或小芯片的选型和构建时加以考虑。
收到的 Num_RP_REQ_Tx 与发送的 Num_RP_REQ_Rx	如果收到的 Num_RP_REQ_Tx 值小于发送的 Num_RP_REQ_Rx 值，不应出现任何功能问题。接收器允许（但不要求）重新分配原本会为未使用的资源平面提供的信用。 如果收到的 Num_RP_REQ_Tx 值大于发送的 Num_RP_REQ_Rx 值，接收器的行为预计没有变化。
收到的 DevAssign_Support_Rx 与发送的 DevAssign_Support_Tx	仅用于提供信息，以辅助设置或调试，预计单独来看不产生任何功能影响。预计还需要额外的软件证明（attestation）和配置。
收到的 DevAssign_Support_Tx 与发送的 DevAssign_Support_Rx	仅用于提供信息，以辅助设置/调试，预计单独来看不产生任何功能影响。预计还需要额外的软件证明和配置。
Container_Format	参见 B10.4.3.1 Container_Format 的确定。
Deactivation_Support	如果没有任何属性位断言匹配，则协议不支持去激活。 如果只有一个属性位断言匹配，则仅支持关联的模式。 如果多个属性位断言匹配，则可以使用任何一种关联的去激活方式。

B10.4.3.1 Container_Format 的确定

确定所使用的容器格式分为两部分：

1. 两个协议层交换 Container_Format 属性，以确定可用的选项。
2. 将协议层可支持的容器格式与链路层所需的 FlitFormat 的要求相结合。

表 B10.10 展示了这两个方面如何结合。

表 B10.10：容器格式与 FlitFormat 的组合（译注：原文此处表题占位为"Enter table title"）

支持的 Container_Format	协商的 FlitFormat（6 字节）	协商的 FlitFormat（20 字节）
Format X	Format X	不兼容
Format Y	Format Y	Format Y
Format X 和 Format Y	Format X	Format Y

B10.5 MiscU.Properties 消息中的属性打包（Property packing in MiscU.Properties message）

表 B10.11 展示了属性在 MiscU.Properties 消息载荷中的打包方式。

表 B10.11：MiscU.Properties 消息格式

MISC 比特位置	字段名	宽度（比特）	值	属性分类
3:0	MsgType	4	MiscU	不适用
7:4	MiscOp	4	Properties
11:8	Num_Properties_Msg	4		统一属性
15:12	Protocol	4
19:16	Version	4
23:20	Container_Format	4
27:24	Deactivation_Support	4
39:28	Reserved	12
43:40	Num_RP_REQ_Rx	4		接收器属性
47:44	Reserved	4
49:48	WritePush_Support_Rx	2
51:50	DVMPush_Support_Rx	2
53:52	Snoop_Transactions_Rx	2
55:54	DVM_Support_Rx	2
57:56	Atomic_Transactions_Rx	2
59:58	Cache_Stash_Transactions_Rx	2
61:60	Persist_Transactions_Rx	2
63:62	MTE_Support_Rx	2
65:64	Deferrable_Write_Rx	2
67:66	RME_Support_Rx	2
69:68	CMO_Transactions_Rx	2
71:70	MPAM_Support_Rx	2
73:72	PBHA_Support_Rx	2
75:74	MEC_Support_Rx	2
79:76	RSVDC_REQ_Rx	4
83:80	RSVDC_DAT_Rx	4
87:84	DevAssign_Support_Rx	4
99:88	Reserved	12
103:100	Num_RP_REQ_Tx	4		发送器属性
107:104	Reserved	4
109:108	WritePush_Support_Tx	2
111:110	DVMPush_Support_Rx	2
113:112	Snoop_Transactions_Tx	2
115:114	DVM_Support_Tx	2
117:116	Atomic_Transactions_Tx	2
119:118	Cache_Stash_Transactions_Tx	2
121:120	Persist_Transactions_Tx	2
123:122	MTE_Support_Tx	2
125:124	Deferrable_Write_Tx	2
127:126	RME_Support_Tx	2
129:128	CMO_Transactions_Tx	2
131:130	MPAM_Support_Tx	2
133:132	PBHA_Support_Tx	2
135:134	MEC_Support_Tx	2
139:136	RSVDC_REQ_Tx	4
140:143	RSVDC_DAT_Tx	4
147:144	DevAssign_Support_Tx	4
159:148	Reserved	12

B10.6 属性打包到寄存器（Property packing into registers）

预计每个接口都有多组 64 位寄存器，包含运行期间使用的属性。已定义的寄存器组详见表 B10.12。

表 B10.12：属性寄存器组

寄存器组	访问权限	实例数量	描述
Supported	RO	1	提供本地芯片接口复位后的直接信息
Advertised	RW	每条逻辑链路 1 个	Supported 寄存器的副本，可由软件修改，以降低 MiscU.Properties 消息中所通告的属性
Informed	RW	每条逻辑链路 1 个	逻辑链路对端发送的 MiscU.Properties 消息中所接收属性的副本
Negotiated	RO	每条逻辑链路 1 个	对逻辑链路两侧每个属性进行比较后的结果。可被以下两者使用： -- 发送器：用于控制发送哪些消息； -- 接收器：用于对不会被使用的逻辑启用节能。

统一属性寄存器使用的格式如表 B10.13 所示。

表 B10.13：统一寄存器属性格式

比特位置	比特数	属性
3:0	4	Num_Properties_Msg
7:4	4	Protocol
11:8	4	Version
15:12	4	Container_Format
19:16	4	Deactivation_Support
63:20	44	Reserved

接收器属性寄存器使用的格式如表 B10.14 所示。

表 B10.14：接收器寄存器属性格式

比特位置	比特数	属性
3:0	4	Num_RP_REQ_Rx
7:4	4	Reserved
9:8	2	WritePush_Support_Rx
11:10	2	DVMPush_Support_Rx
13:12	2	Snoop_Transactions_Rx
15:14	2	DVM_Support_Rx
17:16	2	Atomic_Transactions_Rx
19:18	2	Cache_Stash_Transactions_Rx
21:20	2	Persist_Transactions_Rx
23:22	2	MTE_Support_Rx
25:24	2	Deferrable_Write_Rx
27:26	2	RME_Support_Rx
29:28	2	CMO_Transactions_Rx
31:30	2	MPAM_Support_Rx
33:32	2	PBHA_Support_Rx
35:34	2	MEC_Support_Rx
39:36	4	RsvdC_REQ_Rx
43:40	4	RsvdC_DAT_Rx
47:44	4	DevAssign_Support_Rx
63:48	16	Reserved

发送器属性寄存器使用的格式如表 B10.15 所示。

表 B10.15：发送器寄存器属性格式

比特位置	比特数	属性
3:0	4	Num_RP_REQ_Tx
7:4	4	Reserved
9:8	2	WritePush_Support_Tx
11:10	2	DVMPush_Support_Tx
13:12	2	Snoop_Transactions_Tx
15:14	2	DVM_Support_Tx
17:16	2	Atomic_Transactions_Tx
19:18	2	Cache_Stash_Transactions_Tx
21:20	2	Persist_Transactions_Tx
23:22	2	MTE_Support_Tx
25:24	2	Deferrable_Write_Tx
27:26	2	RME_Support_Tx
29:28	2	CMO_Transactions_Tx
31:30	2	MPAM_Support_Tx
33:32	2	PBHA_Support_Tx
35:34	2	MEC_Support_Tx
39:36	4	RsvdC_REQ_Tx
43:40	4	RsvdC_DAT_Tx
47:44	4	DevAssign_Support_Tx
63:48	16	Reserved

---

（全文完）