CHI (Chip-to-Chip) C2C 协议（翻译）

For 2 interfaces Interface Num[0] = Masked_Addr[n-1] XOR Masked_Addr[n-2]...Masked_Addr[7] XOR Masked_Addr[6]
For 4 interfaces Interface Num[1:0] = Masked_Addr[n-1:n-2] XOR Masked_Addr[n-3:n-4]...Masked_Addr[9:8] XOR Masked_Addr[7:6]
For 8 interfaces Interface Num[2:0] = Masked_Addr[n-1:n-3] XOR Masked_Addr[n-4:n-6]...Masked_Addr[11:9] XOR Masked_Addr[8:6]

非2的幂次

第一步是使用两个接口数量的幂次数大于可用数量的接口数。获得的中间接口号通过使用表或其他某些实现方式映射到接口号。该表是在启发式上设置的，以尽可能均匀地分布在可用数量的接口数上。相对于接口的实际数量，中间界面数越大，大于跨接口的消息分布的均匀性。

B3 Packetization 装包

B3.1 容器

一个容器为256个字节，包括链接标头字节，协议标头字节和颗粒中组织的消息字节。

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

1. 格式X，包括：

240字节有效载荷，分为十二个20字节颗粒
6个字节 link header
10个字节 protocol header
此格式与UCIE [2] 256-Byte可选字节延迟优化模式兼容。

2. 格式Y，包括

226字节的有效载荷，分为：
- 十个20字节颗粒
- 一个16字节颗粒
- 一个10字节颗粒
20个链路标头的20字节
20个字节 link header
10个字节 protocol header
此格式与CXL [3] 256-Byte延迟优化模式兼容

图B3.1显示了格式X和格式Y的容器字节布局。颗粒是分布式的，因此它们在容器的64字节和128字节上对齐。

有关Prothdr位的信息，请参见B3.2协议标题。

B3.2 协议头

不用于消息颗粒的字节是link头或协议头。

link头字节的描述不在此规范的范围之内。这些位的典型用法是添加flit头，一个CRC和FEC。

协议头分配如图B3.2所示。

表B3.1显示了图B3.2中存在的协议标头字段的编码。

B3.3 消息打包

消息使用颗粒包装到容器中。仅允许消息在颗粒开始时开始。这限制了每个消息类型可以在容器中占据的位置数量，以最大程度地减少解码逻辑。

协议标头中的MsgStart向量确定新消息是否在特定颗粒处开始。每条报文都以定义报文类型的 MsgType 字段开始。

B3.3.1 规则和限制

在容器内放置报文的限制是：

在格式 X 容器中，信息可以放在任何颗粒中。
在格式 Y 容器中：
除Resp和Misc类型外，报文可放在除 G5 和 G11 以外的任何粒度中。
Resp信息可放置在任何颗粒中。
杂项信息
信息总大小为 10 字节或更小，可放在任何粒度中。
报文总大小为 16 字节或以下时，可放在除 G11 以外的任何粒度中。
报文总大小大于 16 字节的报文可放在除 G5 和 G11 以外的任何粒度中。

多粒度报文
可从任何粒度开始，格式 Y 中的 G5 和 G11 除外。
格式 Y 中的多粒度报文跳过 G5 和 G11。
可跨连续容器。跨多个容器时，报文必须在下一个容器的 G0 中继续。

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

在颗粒中包含报文是可选的。允许容器中没有报文。
报文的 LSB 位被置于颗粒的 LSB 位。
未使用的位必须为 0，包括
不包含报文的粒度。
信息末尾和颗粒末尾之间的任何位。

32 字节数据放在 64 字节数据字段的一半，与请求地址位[5]值相对应。
颗粒按组排列： G0-G2、G3-G5、G6-G8、G9-G11。
每个组可以有（此处考虑为何要这样限制？效率？还是设计简化等？）
无颗粒。
有编号最低的颗粒。
两个编号最低的颗粒。
所有颗粒都已填充。
最多一条 MiscU 信息。
最多四条响应信息，其中 Resp2 算作两条响应信息。

例如，如果 G6 没有填充，那么 G7 和 G8 也必须为空。

- MiscU.LinkStatus 报文只能使用 G0。

图 B3.3 是格式 X 集装箱包装的一个示例。图 B3.3 中的两个容器包括：

两个 ReqS 和两个 ReqL 报文，其中一个 ReqL 报文跨越两个容器。
一个 Resp 和一个 Resp2 报文。
一条 Snoop 报文。
一条 DataS 信息。
容器 B 中的空颗粒。

图 B3.4 是格式 Y 集装箱包装的示例。图 B3.4 中的四个容器包括

两个 ReqS 报文和一个 ReqL 报文。
六条 Resp 信息。
一条 Snoop 报文。
一条 DataS 报文和一条 DataL 报文。
容器 A 中的 DataS 报文跨越 G5。
DataL 报文从 A 容器开始，跳过 G11，然后滚动到 B 容器的开头。
六条 WrReqDataS 报文。
一个 WrReqDataS 报文在 B 容器中，跨越 G5。
一个 WrReqDataS 报文从 C 容器 G9 开始，跳过 G11，然后滚到 B 容器的起始位置。
容器 B 中的空颗粒。

B4 Message structures 消息结构

B4.1 Transactions and transaction flows

本节描述了下级节点收到的请求中的字段与片上 CHI 字段的映射，还列出了不支持的 CHI 事务。

B4.1.1 请求下级节点时的字段映射

接收下级节点请求的接口必须按以下方式将收到的请求中的字段映射到片上 CHI 请求信息：

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

B4.1.2 不支持的 transaction

不支持以下事务：

Forwarding snoops
独占访问不可缓存内存和设备内存
请求重试流
-直接内存传输 (DMT)。请求报文中不包含用于 DMT 的 ReturnNID 和 ReturnTxnID 字段。
直接缓存传输（DCT）。窥探报文中不包括专门用于 DCT 的 FwdNID 和 FwdTxnID 字段。
直接写入传输 (DWT)。请求报文中不包含用于 DWT 的 ReturnNID 字段。
启用标签匹配后，不支持下级节点直接向请求节点发出 TagMatch 响应。
在 Persist Cache Maintenance Operation (CMO) 事务流程中，不支持从下级节点直接 Persist 响应到请求节点。

注意

对于读事务，包括主节点和从属节点的芯片可在该芯片内部使用 DMT。这样，数据就可以直接从下级节点转发到 C2C 端口。

但是，由于 C2C 接口不支持 DMT，因此数据响应只有一个 SrcID 字段，而没有 SrcID 和 HomeNID 字段。在 C2C 端口，数据回复中的 SrcID 字段必须填入原点的节点 ID。这可确保事务中的任何后续信息（如 CompAck）都能正确发送到主站。

对于 “写 ”事务和 “窥探 ”事务，数据响应的 SrcID 字段将包含正确的Node ID，无需替换为Home ID。

在请求芯片接口上，必须通过复制通用字段值来填充请求器响应中的 SrcID 和 HomeNID。

通过在将转发窥探转换为非转发窥探之前跟踪窥探类型，可在主控芯片出口处部分支持 DCT。当收到带数据的窥探响应时，接口逻辑可将响应拆分，其中一个发送给请求者，另一个发送给原点。

B4.2 消息字段

本节描述了每个报文类别中的字段。

B4.2.1 C2C 特定报文字段描述了 C2C 中存在但芯片上 CHI 报文中不存在的字段。C2C 报文中删除的片上 CHI 报文字段在 B4.2.8 冗余字段中描述。

B4.2.1 C2C特有字段

以下字段添加到 C2C 报文中，片上 CHI 报文中没有这些字段：

MsgType
ResPlane
SharedCrdt
ChunkValid
RsvdZero

B4.2.1.1 消息类型，MsgType

该字段按报文类别和大小确定报文类型，其中：

请求、数据、WrReqData 报文可以是两种类型之一，取决于报文长度。详见 B4.2.2 请求报文字段、B4.2.4 数据报文字段和 B4.2.5 WritePush 报文。
响应报文可以是一个或两个，每个粒度 20 字节。请参阅 B4.2.3 响应报文字段。
杂项报文可记入或不记入。
有关未记名 MISC 报文的详情，请参阅 B4.2.7 “未记名杂项 ”报文字段。
本规范尚未定义任何已记入的 MISC 报文。

表 B4.1 显示了 MsgType 字段的编码。

B4.2.1.2 Resource plane, ResPlane

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

B4.2.1.3 Shared credit, SharedCrdt

该字段用于支持请求和数据报文类报文中的多个资源平面和数据信用池。请参阅 B5.3 资源平面和 B5.4 数据信用池。

B4.2.1.4 Chunk valid, ChunkValid

该字段出现在 DataS、DataL、WrReqDataS 和 WrReqDataL 报文中。其值表示 32 字节数据块中的一个或两个数据块是否有有效数据。

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

B4.2.1.5 RsvdZero

该字段表示这些比特的使用是保留的，发送方必须将该字段值设置为零，接收方必须忽略该字段，中间代理必须原封不动地转发这些比特。在报文中包含 RsvdZero 字段可能是为了在字节或粒度边界处开始后续字段，或者是为了填充最后一个粒度中有用信息以外的比特。

B4.2.2 请求信息字段

本节将介绍请求报文类型中的字段：

ReqS 用于短格式
ReqL 用于长格式

当请求中出现以下字段且其值不为零时，请求信息将使用 ReqL 信息格式：

任何请求中的 Addr[3:0]。64 字节大小的正常内存无数据请求中的 Addr[5:0] 位允许清零。
独占事务中的 LPID
在 Persist CMO、StashOnceSep 或 Write 中的 GroupID，TagOp 值为 Match。
StashNID[10:1]
StashLPIDValid
PBHA
LikelyShared
DataTarget[6:1]
RSVDC[N-1:16]

当允许使用 ReqS 时，允许发射机使用 ReqL 信息代替 ReqS。使用 ReqL 代替 ReqS 可能会降低容器包装效率。

表 B4.3 列出了请求报文字段及其在 ReqS 和 ReqL 中的位置。

表中各列定义如下：

Common 在 “Cx ”中标有相同 “x ”的共用字段在信息中的位置相同。

ReqS 请求包括所有必填字段和最常用的可选字段。

ReqL 请求大小扩展到包括所有支持的请求字段。

B4.2.3 响应消息字段

本节将介绍响应报文类型中的字段：

Resp
Resp2

B4.2.3.1 Resp消息类型

表 B4.4 显示了 Resp 报文类型中的字段，其中一个响应被打包成一个颗粒

B4.2.3.2 Resp2 消息类型

表 B4.5 显示了 Resp2 报文类型中的字段，在这种报文类型中，两个Resp被打包到一个颗粒中。

B4.2.4 数据消息字段

DataS 和 DataL 消息格式用于读取数据、snoop响应数据和非 WritePush 数据消息。

DataS 和 DataL 报文格式的特点包括：

SrcID 和 HomeNID 共享一个 11 位字段。该字段用于
- CompData 和 DataSepResp 中的 HomeNID
- SnpRespData 和 WriteData 中的 SrcID
数据注错是指每次数据传输只有一个比特，由值为 DERR的RespErr 表示。
ChunkValid 字段用于指示相应的 32 字节是否包含有效数据。参见表 B4.2。
数据字段以字节边界开始。这就要求在数据字段之前填充 RsvdZero 位。
DataL 报文中的专用字段以颗粒边界开始。
任何数据报文中数据字段的无效字节（由 ChunkValid 表示）以及写入数据和窥探响应数据中的 BE 必须清零。

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

部分写入请求数据响应中的 BE 字段有一个或多个位值为零。
报文中存在以下字段，且其值不为零：
- QoS
- PBHA
- RSVDC[N-1:16]

当允许使用 DataS 时，允许发射机使用 DataL 报文代替 DataS。使用 DataL 代替 DataS 可能会降低容器包装效率。

表 B4.6 显示 DataS 和 DataL 的报文字段。

B4.2.5 WritePush 消息

使用 NonCopyBackWriteData 数据的即时写入、Atomics 和 DVMReq 事务允许（但不要求）使用写推送语义来优化其事务流。写推送流程将从发送方发送到接收方的请求和数据合并为一条消息，因此无需 DBIDResp 响应。

这种两步式写入推送比三步式写入拉出事务具有以下优势：

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

为支持 WritePush 事务，定义了以下接口属性： WritePush_Support 此属性表示接口是否支持将 WritePush 用于立即写入和原子事务。请参阅 B10.4.2 Receiver 和 Transmitter 属性。

DVMPush_Support 该属性指示接口是否支持对 DVM 事务使用 WritePush。请参见 B10.4.2 “接收器 ”和 “发送器 ”属性。

信息格式详见 B4.2.5.2：信息字段。

B4.2.5.1 事务流

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

WritePush 事务的顺序为：

事务开始时，请求者发出 WrReqDataS 或 WrReqDataL 消息。
完成者发送 Comp 响应。

B4.2.5.2 消息字段

表 B4.7 列出了允许使用 WrReqDataS 报文的请求操作码。在这些请求中，BE 字段值都必须为 1。所有其他推送事务，包括那些需要 WrReqDataS 报文中不包括的字段的事务，都必须使用 WrReqDataL 报文格式。

在 WrReqDataS 和 WrReqDataL 中，数据字段中的无效字节必须清零。

Note

接口可以使用 ChunkValid 来确定哪些字节需要清零。

表 B4.7 中的 OWO 字段表示写入是否属于需要有序写入观察 (OWO) 保证的写入组。

当 OWO = 0 时，不需要 OWO 保证。

当 OWO = 1 时，需要 OWO 保证。

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

表 B4.8 显示 WrReqDataS 报文中的 Opcode2 字段。

图 B4.2 说明了 MPAM、MECID 和 RSVDC 字段共享 Union1 字段的情况。

Union1 字段的低阶比特位决定了 MPAM、MECID 和 RSVDC值。

B4.2.6 Snoop消息字段

表 B4.9 显示了窥探报文的字段。

B4.2.7 未授权杂项信息字段

MiscU 报文的字段如表 B4.10 所示。

MiscU 报文使用的有效载荷比特数取决于 MISC 报文类型。

使用的关键字如下： X 可变字段宽度，精确值取决于 MiscOp 字段值。

MiscOp 描述杂项报文类支持的报文子类型。

MiscU 报文中 MiscOp 字段的编码见表 B4.11。

B4.2.8 冗余字段

由于以下一个或多个原因，C2C 报文中不需要某些 CHI 字段：

不支持使用该字段的事务流程。
主节点到下级节点接口的报文中使用该字段只是为了支持 C2C 中不支持的流程优化。
该报文类别的报文路由基于地址解码而非 ID。

表 B4.12 列出了 C2C 报文中不需要的 CHI 字段。

B5 Flow Ctrl

B5.1 介绍

信息必须符合以下条件：

信息在传输过程中不得丢弃或丢失，也就是说，发送方发送的每条信息都必须由接收方接收和处理。
从链路层或物理层传入的数据包必须在不施加反向压力的情况下被接收，这符合业界广泛的物理设计标准。更多信息请参见 UCIe [2]。
接收响应和数据通道报文时必须不依赖于任何请求或窥探报文的前进进度。
窥探（Snoop）信道信息必须在不依赖于请求（Request）信道信息向前推进的情况下进行。
写推送请求不得阻止与写推送无关的任何数据的向前推进。

以下机制用于支持流量控制要求：

为每个报文类提供单独的信用额度，以确保单个报文类的报文能够向前推进，而其他报文类的报文则受到反压。
在 REQ 和 DAT 报文类中支持多个资源平面和 DAT 信用池，以支持每个报文类中不同报文组的前向进度保证。
还支持对消息类和 RP 中的消息进行排序。

B5.2 消息信用

为支持流量控制要求，必须做到

每个信息类别的信息必须独立进行流量控制。
对于每个信息类别，接收方必须向发送方提供信息额度。这可确保发送方在发送信息前拥有适当的信用额度。
- 未入账的 MISC 报文不需要报文入账，接收方必须保证接受此类报文。
- 要发送 WrReqDataS 或 WrReqDataL 报文，发送方需要有一个 REQ 和一个 DAT 报文信用点。请参阅 B5.4 数据信用池。

请参见表 B4.1，确定每种报文类型所需的信元。

可使用协议标头或 MiscU 报文授予信用。

B5.2.1 使用协议标头授信

可使用协议头中的报文信用授予字段（MsgCredit）向发送端授予信用。

MsgCredit 字段的子字段如图 B5.1 所示。MsgCredit 字段可用于授予除 MISC 以外的所有报文类别的信用。

有激活报文的容器不能使用协议标头授予学分。有关激活报文的详情，请参阅 B8.2 接口激活和停用。

当 REQ 或 DAT 报文类中支持多个 RP 时，就会包含 SharedCrdt (ShC) 和 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 字段不适用，必须为零。

有关共享信用和专用信用池使用的详情，请参阅 B5.3 RP和 B5.4 数据信用池。

B5.2.2 使用 MiscU 报文授信

通过在 MISC 信道上发送明确的信用授予报文，可使用 MISC 信道报文授予所有报文信道的信用。请参见 B5.2.3 信用授予报文格式。

当发送相关报文类别的报文时，将使用授予的信用。

表 B5.1 显示了报文信用字段的编码。

B5.2.3 信用授予信息格式

MiscU.CrdtGrant 用于授予报文信用。

表 B5.2 显示了 CrdtGrant MiscU 报文字段。

B5.3 Resource Planes

通常使用多个资源平面来实现以下功能：

针对不同请求的前向进度保证。例如，确保 PCIe 发布写入的前向进度不依赖于其他写入事务的进度。
服务时间保证。例如，作为实时流量一部分的信息需要在规定的延迟范围内提供服务。
简化协议。例如，消除请求重试，即使事务的两个阶段使用相同的传输，也不会造成传输死锁。

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

使用资源平面时：

- 从本地协议层到远程协议层，使用不同资源平面的报文不得相互阻塞。
- 可发放以下类型的信用：
- - 专用信用针对特定的 RP，只能用于属于该 RP 的报文。
- - 共享信用不指定 RP，可用于分配给任何 RP 的信息。
- 即使使用共享信用点数，使用同一 RP 的信息也必须保持顺序。
- 发送器拥有信用点数的任何 RP 都可用于发送信息。
- 建议但不要求发送器在使用专用信用点之前使用共享信用点。

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

接收方可在共享和专用信用池之间分配其缓冲区。每个专用信用池的报文信用数量可以不同。

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

请求信息必须：

- 说明是否使用共享池信用。
- 包括所属的 RP，即使在使用共享池信用时也是如此。

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

- SharedCrdt. 表示请求是否使用共享额度。

SharedCrdt = 0 时请求使用专用 RP 内存。RP 编号由 ResPlane 字段值表示。

SharedCrdt = 1 时请求使用共享池信用。即使使用的是共享积分，也必须通过 ResPlane 字段值指明报文所属的 RP。

- ResPlane[2:0]。表示请求所属的 RP。

字段值可以是 0 到 Num_RP_REQ。Num_RP_REQ 属性定义了请求报文类支持的专用 RP 的最大数量。有关 Num_RP_REQ 的编码，请参见表 B10.7 和表 B10.8。

有关 ReqS 和 ReqL 信息格式，请参阅 B4.2.2 请求信息字段。

B5.4 数据信用池

用于传输数据报文的信用点数（DAT 信用点数）分为以下信用点数池：

- DAT0Credit 是用于传输数据报文的专用信用点数，这些报文的传输进度需要比任何受阻的 WritePush 报文有保证。使用 DAT0Credit 发送报文时，不得依赖于使用其他数据信用池信用的报文进度。
- DAT1Credit 是一种专用信用点数，用于传输需要保证前进进度的 WrReqData 报文。使用 DAT1Credit 发送报文时，不得依赖于使用其他数据学分池学分的报文进度
- DATShCredit：共享信用，可用于传输任何数据报文。与一个请求 RP 有关的报文使用 DATShCredit 时，不得阻塞或被阻塞与另一个请求 RP 有关的报文。

表 B5.3 显示哪些报文类型允许使用哪些信用类型。

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

- 必须向前推进并使用 WrReqData 报文的 PCIe 写入，在没有可用共享信用额度时，应使用专用信用额度。
- 可能被其他报文阻滞的 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。

- ResPlane[2:0]

表示分配给该请求的 RP。

有关 WrReqData 报文格式，请参阅 B4.2.5.2。

Note：

使用 WritePush 语义的写消息需要请求和数据共享信用点数才能进行交易，如果不能及时同时提供这两个共享信用点数，则可能会改为使用 Write pull 语义来进行交易。

B5.5 Ordered interface

C2C 接口必须是有序的。

C2C 接口接收容器的顺序必须与链路远端的 C2C 接口发送容器的顺序一致。

要求

在发送端：

- 在适用的情况下，同一报文类别和同一 RP 的报文必须按照从协议层收到报文的顺序放入容器中，即按从低到高的顺序排列。

- 不同报文类别的报文没有这种有序放置的限制。

在接收方：

- 分组层必须保持给定报文类别的报文在接收容器中的放置顺序以及容器的接收顺序。

- 具有相同 RP 值的报文类别中的报文必须按照接收的顺序转发给协议层

两个组件之间使用多个接口时的排序要求见 B2.4 多接口。

有序接口是一个必备功能，因此不包括控制其存在的接口属性。

B6 DVM transactions

B6.1 Introduction

通过 C2C 接口支持所有 CHI DVM 交易。定义了一种新的节点类型，即 DVM 节点（DN），它负责将本地 DVM 事务传播到远程芯片，并根据远程 DVM 请求执行所需的本地无效处理。

DVM 节点还负责管理流量控制，以保证 DVM 事务向前推进。

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

B6.2 DVM Node，DN

DN 处理与远程芯片之间的 DVM 操作。DN 执行以下功能：

- 为本地 DVM 事务向远程 DVM 节点发送 DVM 请求。当向多个节点发送请求时，它可以使用单播 DVM 请求到每个远程 DN，或使用分层树通信模式发送到远程 DN 的子集，再由子集将请求转发给另一个子集，从而将 DVM 请求扩展到系统中的所有 DVM 节点。
- 收集向远程 DN 发送的 DVM 请求的响应。
- 为远程 DVM 请求执行本地所需的无效处理。
- 协调本地和远程 DVM 事务之间的交互。

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

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

B6.2.1 DVM 节点分配

允许 DN 与同一芯片上的请求节点和主节点共享 ID 名称空间。

这就要求针对 DN 的 DVM 响应与针对请求节点的响应分开识别。

Note：

共享节点 ID 名称空间的功能最大限度地减少了系统中所需的唯一 ID 总数。

B6.3 DVM 传输流

C2C 上的两个 DVM 事务是

- DVMReq

- DVMSync

在本规范中，DVMReq 指 DVMOp（NonSync），DVMSync 指 DVMOp（Sync）。

B6.3.1 DVMReq

DVMReq 事务流程如图 B6.1 所示。该流程类似于 32 字节写部分事务流程。DVMReq 事务可使用写推或写拉语义。

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

完成器的响应是

- 当使用写推流时： CompDVM。
- 当使用写入拉流程时： CompDVM、DBIDRespDVM 或组合 CompDBIDRespDVM。

有关响应信息的详细信息，请参阅 B6.4 DVM 事务响应。

DVM 事务有效负载分布在请求的 Addr 和 Data 字段中，就像片上 CHI 一样。Comp 和 DVMData 通过使用不同的操作码与非 DVM 事务的 Comp 和 Data 响应区分开来。

Note：

片上 CHI 用于将 DVM 交易从本地 DN 或入口端口传送到 C2C 请求器。

通过 C2C 接口发送后，C2C 完成器使用片上 CHI 将事务传送到本地 DN 或出口端口。

B6.3.2 DVMSync

DVMSync 事务流程如图 B6.2 所示。该流程类似于只有一个响应的无数据请求事务流程。

完整的响应是 CompSyncDVM。

所有需要的有效负载都在请求地址字段中，因此不需要 DVM 事务数据响应。

当片上操作码字段指示 DVMOp 且 DVMType 子字段指示同步时，将使用 DVMSync。

仅通过 SrcID 跟踪请求。每个源只能有一个未完成的 DVMSync 交易。

因此，响应中的 TgtID 用于将响应与其相应的请求进行匹配。

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

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

B6.4 DVM 事务响应

DVMReq 和 DVMSync 信息的响应信息如下：

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

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

B6.5 Flow control

DVM 事务的请求者和完成者必须遵守以下规则，以保证事务向前推进。

一个 DN：

- 必须只有一个 DVMSync 请求尚未处理到远程 DVM 节点。
- 允许向远程 DVM 节点发出任意数量的 DVMReq 请求。
- 必须接受来自每个远程 DN 的一个 DVMSync。

要求所有 DVMSync 请求都必须在目标 DN 处下沉，是为了避免请求路径在 C2C 处受阻。

DN 上的 DVMSync 不能阻止 DVMReq 事务的向前推进。也就是说，必须保证从远程节点接收的 DVMReq 事务的前进进程。这种保证可通过为收到的 DVMReq 事务预留缓冲区来实现。

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

B7 RME-DA and RME-CDA support

本章介绍 C2C 对 RME 设备分配（DA）和 RME 相干设备分配（CDA）的支持。

B7.1 介绍

RME-DA 是 Realm Management Extension 架构的一部分，可实现可分配设备接口的安全分配。设备权限表（DPT）包含与物理地址相关的权限属性，并指定了一套相应的 DPT 检查，适用于设备的传入访问。

在本节中，术语 RME-DA 指的是 IO 一致性设备，术语 RME-CDA 指的是具有完全一致性能力的设备。

本规范支持多加速器设备拓扑结构中的 RME-DA 和 RME-CDA，其中加速器与主机相连。参见图 B7.1。

由单个或多个 SoC 芯片组成的主机构成可信计算基地（TCB）：主机

- 负责执行系统所需的安全策略。
- 可连接多个设备。
- 可直接连接称为主机相干内存（HCM）的存储器。主机或任何全相干或 IO 相干设备都可以对 HCM 进行相干访问。
- 不得向设备发送 Stash Snoop，除非该行已被设备合法允许缓存。
- 允许向设备发送 DVMOp 请求或 SnpDVMOp Snoop。

设备是单个物理芯片，从信任角度看被视为单个单元，并经过单独验证。设备

- 仅对一组 “域 ”整体信任，并在需要时保持 “域 ”分离。
- 可拥有私有内存映射资源。
- 可以有一个或多个接口。
- 可直接连接称为设备一致性内存（DCM）的内存。主机、设备和其他一致性设备都可以对 DCM 进行一致性访问。
- 只能通过主机计算节点访问其他一致性设备的 DCM。
- 只能在 Realm 和非安全 PAS 中运行。
在向主机提出的所有请求中，预计但不要求包括以下字段：
- - 安全状态 (SecSID1) 字段
- - 数据流 ID (StreamID) 字段
只接收对信任该设备的 Realms 所拥有内存区域的窥探请求。
- 不能直接连接到其他设备。
- 不允许向主机发送 DVMReq 或 DVMSync 请求

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

预计主机将对设备发出或接收的某些信息执行额外检查。这些检查可确保

- 允许从设备发送到 HCM 的请求访问内存。这意味着设备不能发出带有随机 PA 的请求，并期望获得对该位置的访问权限。
- 从设备发出的侦听只针对 DCM。这意味着设备不能通过任意 PA 发出请求来访问某个位置。
- 针对缓存的 HCM 位置向设备发出的侦查只能暴露设备允许观察到的访问。这意味着设备无法建立所有受信任系统活动的图像，以进行更有针对性的攻击。

有关 RME-DA 和 RME-CDA 的更多信息，请参阅 [1]。

B7.2 Fields supporting RME-DA and RME-CDA

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

StreamID 流标识符。StreamID 是来自与同一系统 MMU 上下文相关联的一个或一组请求者的请求流的唯一标识符。接口信息中的 StreamID 字段适用于 DevAssign_Support 属性所定义的内容。

注意与 PCIe 接口时，StreamID 是与单个 PCIe 端点相关联的请求者 ID。

SecSID1 安全流标识符。SecSID1 用于限定 StreamID 的安全状态。接口信息中的 SecSID1 字段适用于 DevAssign_Support 属性所定义的内容。

MECID 内存加密上下文标识符。MECID 是分配给内存访问的标识符，将每次访问与内存加密上下文相关联。MECID 值对每个 “域 ”都是唯一的。接口报文中的 MECID 字段适用于 MEC_Support 属性所定义的内容。

有关这些字段及其适用性的更多详情，请参阅 [1] 。

B7.3 Host and device 责任

关于主机或设备在支持 RME-DA 或 RME-CDA 的系统中的责任，详见 [4] 和 [5]。

B7.4 每个设备的请求节点

在加速器附加配置中，当 DevAssign_Support_Tx 属性指示接口表示为设备时：

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

Note:

主页跟踪内存缓存的方式决定了窥探过滤器的执行效率。

准确了解一行的缓存位置，可使 “归属地 ”向该缓存发送有针对性的窥探。

在粗粒度跟踪的情况下，“主页 ”需要将窥探信息多投给一组缓存，或将窥探信息广播给除请求者之外的所有缓存。多播和广播窥探都需要 “家庭 ”发送多个单播窥探。

随着需要精确跟踪的高速缓存数量的增加，高速缓存中心的细粒度跟踪器（通常是窥探过滤器或目录）也随之增加。

为了管理细粒度跟踪窥探过滤器规模的增加，对每个接口的缓存代理数量设置了架构上限。支持 RME-CDA 的主机可以预先将其缓存跟踪结构的大小控制在该上限内。

B8 接口状态管理

B8.1 介绍

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

三种不同的连接和断开流量会影响完全一致的流量、DVM 信息或所有协议信息。

B8.2 接口激活和停用

接口激活和停用用于启用或禁用接口上所有协议流量的传输。

MiscU 报文类型中的激活报文支持接口激活和停用。有关这些报文的详细信息，请参阅 B8.2.2。

B8.2.1 活动状态

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

STOP（停止）接口与所有协议活动断开。

ACTIVATE （激活）接口正准备启用协议活动。

RUN（运行）接口已启用协议活动。

DEACTIVATE（停用) 接口准备断开所有协议活动。

有关各状态下接口行为的详情，请参阅 B8.2.4 “激活 ”和 “停用 ”流程。

允许的状态转换有

- 停止到激活
- 激活到运行
- 运行到停用
- 停用到停止

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

当接口进入 STOP（停止）状态时，远程信用点数将隐式返回。也就是说，所有发送端报文点数清零，接收端报文点数重置为接口初始化时的值。

B8.2.2 Messages

为支持接口激活流程，定义了以下五种报文：

- ActivateReq
- ActivateAck
- DeactivateReq
- DeactivateAck
- DeactivateHint

其报文格式见表 B8.2，ActivationOp 编码见表 B8.1

B8.2.2.1 ActivateReq and ActivateAck

激活请求（ActivateReq）和激活应答（ActivateAck）报文对用于将接口从 STOP（停止）状态转为 RUN（运行）状态。

请参阅 B8.2.4 激活和停用流程中的 STOP 和 ACTIVATE 状态条目，了解何时发送 ActivateReq 和 ActivateAck 报文以及接口在收到它们时的响应。

B8.2.2.2 DeactivateReq and DeactivateAck

DeactivateReq 和 DeactivateAck 信息对用于将接口从运行状态转为停止状态。

B8.2.2.3 DeactivateHint

DeactivateHint（停用提示）是一条信息，通知远程接口发射机准备停用接口。该报文的特征包括

- 它是 MiscU.Activation 报文。见表 B8.1。
- 接口只允许在 RUN（运行）激活状态下发送此报文。
- 允许接口发送 DeactivateHint（停用提示），然后恢复链路上的活动。
- 允许接口发送多个 DeactivateHint 信息，无论它们之间是否有链路活动。
- 允许接口在未发送 DeactivateHint 信息的情况下发送 DeactivateReq。
- 如果接口已发送 DeactivateHint，则允许发送 DeactivateReq，而无需等待对 DeactivateHint 的任何回应。

Note:

发送方可使用启发式方法决定何时发送 DeactivateHint 信息。例如，启发式方法可以使用链路处于非活动状态的时间长度，即链路上没有发送或接收信息的时间段。

- 允许接收方以以下方式响应 DeactivateHint 信息：
- - 可以放弃提示而不改变状态。
- - 接受提示，并在符合发送信息的条件时回复 DeactivateReq。

B8.2.3 激活信息格式

表 B8.1 显示激活报文中激活操作字段的编码。

有关激活报文的详细信息，请参阅 B8.2.2。

表 B8.2 显示激活报文字段。

B8.2.3.1 PropertyReq

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

PropertyReq = 0 时，不得交换属性。

PropertyReq = 1 时 必须在发送和接收 ActivateAck 后发送属性信息。

此字段适用于 ActivationOp 为 ActivateReq 时。

该字段不适用于其他激活报文类型，且必须为零。

参见 B10.1 简介。

B8.2.4 Activation and Deactivation flow

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

接口停用的启动条件有两个选项。这两种停用条件由 Deactivation_Support 属性定义，分别是

与协议无关：允许随时从 RUN 状态发送 DeactivateReq，且无需检查协议信息流。此外，DeactivateReq 发送后，在接口回到 RUN 状态之前，不得发送协议信息。
协议感知：只有当接口处于 RUN 状态且双向完全静止时，才允许发送 DeactivateReq。静止接口的原因可能是关闭接口或芯片电源。静止状态要求双方必须没有任何协议流量要发送。也就是说，所有未完成的请求必须已完成，不得发送任何响应信息，也不得在链路上发送任何新的请求或窥探信息。

每种激活和停用状态的接口行为包括:

STOP

- 在此状态下，信用被重置。
- 接收器拥有所有信用点数，但不得发送任何信用点数。
- 发送方没有信用，只允许发送 LinkStatus 或 ActivateReq 信息。
- 如果接口要开始发送其他信息，它必须发送一条 ActivateReq 信息。
- 当接口发送或接收到激活请求（ActivateReq）报文后，它必须进入激活（ACTIVATE）状态。

ACTIVATE

- 如果尚未发送，则发送激活请求（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 Activation trigger, ActTrigger

ActTrigger 是一个软件可见的 2 位激活控制字段，用于使硬件启动激活或停用流程。

表 B8.3 显示了 ActTrigger 字段的编码。

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

例如，如果加速器通过 C2C 链路连接到主机，则触发器只能在主机端执行。

B8.3 Connect Miscellaneous messages

MiscU.Connect 报文用于连接接口和断开接口与 Snoop 和 DVM 域的连接。有关如何使用这些报文，请参阅 B8.4 一致性连接和断开以及 B8.5 DVM 域连接和断开。

表 B8.4 显示了连接报文字段。

表 B8.5 显示连接报文中 ConnectOp 字段的编码。

B8.4 Coherency connect and disconnect

接口一致性连接和断开信息用于连接或断开接口，使其符合一致性管理要求。

B8.4.1 Coherency connect states

C2C接口的每个方向都可以处于四种一致性状态之一。每个状态的详细信息请参阅表B8.6。

CohDisabled 接口上的缓存器缓存不包含一致数据。

CohConnect 接口正在请求允许缓存一致性数据。

CohEnabled 接口上的数据交换器参与一致的数据交换。

CohDisconnect 接口上的路由器正在请求从参与一致性数据交换中删除。

参与一致性域的芯片上的转发器独立于该接口上向远程节点发送监听的Home节点。因此，一致性连接和断开是单向的。互连的一致性状态影响该接口上的所有转发器。

允许的状态转换为：

· CohDisabled到CohConnect
· CohConnect到CohEnabled
· CohEnabled到CohDisconnect
· CohDisconnect到CohDisabled

从CohDisconnect状态移动到CohDisabled状态的接口必须保留而不是将从远程侧保持的SNP信用清零。

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

B8.4.2 Messages

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

CohConnectReq
CohConnectAck
CohDisconnectReq
CohDisconnectAck

其报文格式见表B8.4，ConnectOp编码见表B8.5。

表B8.6描述了连接和断开一致性域时两个接口的行为。

Table B8.6: C2C coherency connect state description

State

Tx C2C interface behavior

Rx C2C interface behavior

CohDisabled

此接口上的转换器不得包含相干数据。

不得发送可监听分配请求。

不要：

-从远程接收监听请求。

- 反向影响一致性连接状态。

允许向远程授予SNP消息信用。

在发送CohConnectReq之前必须保持CohDisabled状态，然后必须移至CohConnect状态

不得向远程发送监听请求。

必须能够处理接收SNP消息信用。

不影响反向的一致性连接状态。

必须保持CohDisabled状态，直到收到CohConnectReq，然后必须移至CohConnect状态。

CohConnect

允许发送SNP消息信用。

必须准备好响应监听请求。

必须保持CohConnect状态，直到收到CohConnectAck，然后必须移至CohEnabled状态。

必须能够处理接收SNP消息信用。

必须及时发送CohConnectAck，然后进入CohEnabled状态。

CohEnabled

允许发送可监听分配请求。

- 允许此接口上的缓存器缓存一致性数据。

必须以一致性兼容的方式响应任何接收到的监听请求。

当需要从一致性域断开连接并且接口上的缓存器缓存不包括一致性数据时，发送CohDisconnectReq并进入CohDisconnect状态。

允许根据需要发送监听请求以保持一致性。

必须保持CohEnabled状态，直到收到CohDisconnectReq消息，然后必须移至CohDisconnect状态。

CohDisconnect

不得发送Snoopable分配请求。

必须继续授予SNP信用。远程端可能有排队等待发送的监听请求。

必须继续响应监听请求。

必须保持CohDisconnect状态，直到收到CohDisconnectAck，然后必须移至CohDisabled状态。

完成未完成的窥探请求。

必须及时发送CohDisconnectAck消息并进入CohDisabled状态。

Note：

一致性连接状态在每个方向上都是独立的。当接口同一侧的接收器处于一致性禁用状态时，接口发送器可以继续发送监听请求。

B8.5 DVM domain connect and disconnect

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

B8.5.1 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.5.2 Messages

以下四个消息（组合在一起作为MiscU.Connect消息类型的一部分）被定义为支持接口DVM连接流：

· DVMConnectReq
·DVMConnectAck
· DVMDisconnectReq
·DVMDisconnectAck

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

B8.5.3 DVM domain connect and disconnect flow

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

DVMDisabled

-接口上的缓存器不得缓存地址转换。
- 接口不能发送或接收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请求。
- 必须继续响应DVM请求，直到收到DVMDisconnectReq。
- 收到DVMDisconnectReq后，必须及时发送DVMDisconnectAck。
- 当接口发送并接收DVMDisconnectAck消息后，它必须进入DVMDisabled状态。

B9 Interface initialization

B9.1 介绍

C2C接口初始化建立接口，以启用协议消息的发送和接收。

初始化流程有以下步骤：

与链路层协调，检查接口内的远程协议层是否已启动。
使用MiscU.Properties消息交换接口属性。这将设置接口以开始交换消息信用，然后交换协议消息。

Note

诸如Req_Addr_Width、节点ID分配、地址映射、路由表设置之类的全局或公共能力的发现、枚举和协商不由硬件属性交换流管理。

不属于硬件属性交换流程的能力的交换预期由软件处理。

B9.2 初始化流程

初始化流程的主要功能包括：

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

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

接口初始化的顺序为：

1. 接口初始化从链路复位和初始化开始。

在链路初始化完成之前，链路层必须唤醒协议层。链路层到协议层的唤醒握手方法是IMPLEMENTATION DEFINED。

在链路层和协议层之间使用CXS接口的唤醒握手示例见图B9.1。

·链路层将CXSACTIVEREQ发送到本地协议层。
·一旦启动，协议层发送CXSACTIVEACK响应。
·响应于来自链路层的CXSACTIVEREQ，协议在相反方向上经历相同的握手。该反向CXSACTIVE握手可以晚至在端到端期间执行，即PL到远程PL激活握手。

2. Link层初始化完成后，Link层必须能够接收并识别来自远端的ActivateReq。这是为了能够接收ActivateReq请求消息，如（4）所述。

3. 链路层初始化完成后，链路层向本地协议层发送MiscU.LinkStatus消息。

链路状态消息通知协议层链路初始化完成，并包括协商的微片格式的信息。有关链路状态消息的详细信息，请参见B9.2.1链路状态消息格式。

4. 协议层，以确保远程协议层处于活动状态：

·每个协议层向远程协议层发送ActivateReq消息。
·协议层使用ActivateAck消息响应接收到的ActivateReq。

5. 在此阶段，如果在ActivateReq中请求，双方都准备好使用Properties消息交换支持的属性值：

·协议层向远程发送Properties消息。
·一旦协议层从远端接收到属性消息，协议层就被允许向远端授予信用。

有关接口属性及其交换和协商的详细信息，请参阅第B10章协议层属性交换。

当链路激活阶段完成，需要进行属性交换时，接口Cohesion和DVM状态为Disabled状态。如果需要，必须通过各个Cohesion和DVM连接流程启用接口Cohesion连接和DVM连接。

B9.2.1 LinkStatus消息格式

链路层使用MiscU.LinkStatus消息通知协议层链路层初始化的完成和链路功率状态的变化。该消息在接口初始化期间发送，如B9.2流程中所述，并且允许链路层在物理链路功率状态变化时发送。

表B9.1显示了链路状态消息字段。

B9.2.1.1 FlitFormat

链路层使用LinkStatus消息中的FlitFormat字段来通知协议层需要多少字节来填充链路层特定字段，例如链路报头、FEC和CRC。

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

B9.2.1.2 LinkPowerState

LinkStatus消息中的LinkPowerState字段允许链路层通知协议链路的功率状态。此信息在链路初始化期间以及链路功率状态发生变化时发送到协议层。

表B9.3显示了链路功率状态消息字段。

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

B10 Protocol layer property exchange

B10.1 介绍

接口初始化完成后，激活序列需要属性交换，在发送任何协议消息之前，必须在每个逻辑链路的两个方向上传递接口属性。

属性用于声明能力。

接口属性分为三类：

1.片上有效载荷

·详细说明某些片上字段的存在或宽度，或两者。
·允许在消息选择之前优化有效载荷字段，潜在地允许更有效的打包。

2.片上操作码/流程

·详细说明对某些事务分类的片上支持。
·通过防止跨C2C链路发送不支持的消息，确保接口不会死锁。

3. C2C特定

·详细说明接口支持的规范版本，以确保向后兼容性。
·提供附加信息以帮助使用链接。

逻辑链路的两端都发送MiscU.Properties消息，并指示它们的功能。
每个Properties消息中的属性值都是从一组寄存器驱动的，这些寄存器定义了发送消息的芯片的功能。
某些属性具有Receiver 和Transmitter 变体：

Property_Rx 这表示芯片作为接收器发送属性消息的能力。发送器芯片必须能够终止接收器芯片表示不支持的任何消息。
Property_Tx 表示芯片作为发送器发送Properties消息的能力。在接收器芯片处对其可以接收的内容的感知实现了潜在的功率优化。

如果没有_Tx或_Rx扩展，则该属性被分类为Uniform，并在两个方向上应用于接口。

允许软件在发送Properties消息之前更新寄存器值，以减少接口的通告功能。

在收到属性消息时，接收方必须将每个传递的属性与其自己的属性进行比较。

当属性值对齐时，不需要修改行为。

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

·片上有效载荷

-如果发送器_Tx属性为真并且接收器_Rx属性为假，则允许但不要求在消息选择和容器打包之前将相关联的字段值归零。

- 如果Transmitter，_Tx，属性为False，Receiver，_Rx，属性为True，则需要在消息选择和容器打包之前将关联的字段值置零。

- 如果Transmitter，_Tx属性的值大于Receiver，_Rx属性的值，则允许但不要求在消息选择和容器打包之前在Transmitter处将接收器不支持的最高有效位置零。

- 如果Transmitter，_Tx，属性的值小于Receiver，_Rx，属性的值，则在消息选择和容器打包之前，需要在Transmitter处扩展关联字段值0。

·片上操作码和流

-如果本地发送器_Tx属性为真并且接收器_Rx属性为假，则发送器必须以片上协议兼容的方式终止或降级任何相关联的片上消息。实现定义了这种降级或终止如何发生。

Note:

例如：

- 降级包括将SnpUniqueStash转换为SnpUnique，如果目标芯片不支持存储，但具有完成交易所需的数据副本。

- 终止包括当确定没有下游原子支持时，在本地执行原子事务的编译器。这可以通过在请求者上使用片上BROADCASTATOMIC信号或供选择的控制寄存器来实现。

- 如果发送器_Tx属性为False，接收器_Rx属性为True，则不需要执行进一步的操作。相关的片上协议消息不应提供给发送器，以便通过C2C链路进行通信。

- 可选地，如果Receiver_Rx属性为True而Transmitter_Tx属性为False，则Receiver芯片可能能够通过关闭逻辑的某些部分来节省功率。

· C2C特定的

-如果发送器_Tx属性为真并且接收器_Rx属性为假，则发送器不得使用相关联的特征或事务流。

- 如果Transmitter，_Tx，属性为False，Receiver，_Rx，属性为True，则Receiver可能能够通过关闭某些逻辑部分来节省功率。

- 如果Transmitter（_Tx）和Receiver（_Rx）属性具有True或False以外的值，并且这些值在链路两端之间不同，则其他语句将描述预期的行为。

- 如果链接两侧的Uniform属性不匹配，则将使用附加语句描述预期行为。

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

B10.1.1 属性消息格式

协议层使用MiscU.Properties字段与远程协议层交换其支持的属性值。

表B10.1显示了属性字段的编码。有关有效负载字段的详细信息，请参见表B10.11。

B10.2 片上有效载荷特性

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

表B10.3列出了用于描述作为发射机的芯片的特定片内字段有效载荷特性的属性。

B10.3片上操作码和流属性

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

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

B10.4 C2C特有的属性

B10.4.1 Uniform properties

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

B10.4.2 Receiver and Transmitter properties

表B10.7列出了用于描述接口的C2C特定功能的属性。

表B10.8列出了用于描述作为发射机的接口的C2C特定功能的属性。

B10.4.3 当交换的C2C特定属性不同时的期望

表B10.9详细说明了当链路两端的C2C特定属性不同时的预期结果，这些属性为：

·统一属性
·发送器，_Tx和接收器，_Rx，具有True或False以外的值的属性

B10.4.3.1 容器_格式解析

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

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

表B10.10显示了如何将这两个方面结合起来。

B10.5 MiscU.Properties消息中的属性包装

表B10.11说明了MiscU.Properties消息的有效载荷中的属性打包。

B10.6 Property packing into registers

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

统一特性寄存器所用的格式见表B10.13。

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

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

Additional reading
This section lists publications by Arm and by third parties.
See Arm Developer, http://developer.arm.com for access to Arm documentation.
[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.