第 2 章 UPLI 接口定义与操作规则
译自《UALink_200 Rev 1.0 Specification》第 2 章。
2.1 UPLI 接口
UPLI 定义了一种逻辑信令接口和一种协议，设备可通过该协议经由多种请求（Request）与响应（Response）消息来交换数据与控制信息。UPLI 协议具有以下特性和优势：
- 分离的请求/响应（Split Requests/Responses）提高了接口带宽的利用率。
- 每个 UPLI 接口端口的事务标识标签（transaction identification tags），支持在接口端口上同时存在多个未完成（outstanding）请求。
- 读、写和原子（Atomic）内存操作。
数据传输通过请求/响应消息对来完成。一个请求及其随后的响应构成一个事务（Transaction）。下图展示了一个 UPLI 接口：
图 2-1 UALink 协议级接口
在 UALink 协议级接口中，通过发出请求来发起事务的设备称为发起方设备（Originator Device）。能够对请求做出响应的设备称为完成方设备（Completer Device）。请求也称为命令（Command）。本规范中"命令"与"请求"两个术语可互换使用。
UALink 协议级接口定义了发起方可以发出的请求，以及针对每种请求类型应返回给发起方的响应。
发起方设备通过一个 UPLI 发起方（UPLI Originator）挂接到 UALink 协议级接口。类似地，完成方设备通过一个 UPLI 完成方（UPLI Completer）挂接到 UALink 协议级接口。发起方设备应通过发出读、写、原子、UPLI 写消息（UPLI Write Message）或厂商自定义命令（Vendor Defined Command）请求来发起事务。当请求完成时，完成方设备应向发起方设备发出响应。事务标签（Transaction Tag）使发起方设备能够将请求与随后的响应配对。所有请求都需要有响应。为清晰起见，本规范的大部分图中不画出发起方设备和完成方设备。
一个 UPLI 接口可以（并且通常是）通过一系列带有中间逻辑块（Intermediate Logic Block）的中间 UPLI 接口来扩展，如下图 2-2 所示：
图 2-2 通过中间 UPLI 接口扩展 UPLI 接口
与发起方设备相连的初始 UPLI 接口（Initial UPLI Interface），连接到一组中间逻辑块和中间 UPLI 接口，最终连接到与完成方设备相连的最终 UPLI 接口（Final UPLI Interface）。
作为一个典型用例，图 2-2 对应于使用交换机的 UALink 场景中、从某个特定源加速器到某个特定目的加速器的单条路径。图中第一个中间逻辑块代表源加速器与交换机之间的逻辑，用于实现事务层接口、数据链路层接口、物理接口，以及源加速器与交换机之间的另一组数据链路层和事务层接口。第二个中间逻辑块代表路由 UPLI 请求与响应的交换机核心（Switch Core）。虽然该图只表示了穿过交换机的一条路径（从某个特定源加速器到某个特定目的加速器），但交换机核心通常还连接来自多个源加速器的多个 UPLI 接口（图中未画出）。第三个中间逻辑块代表连接交换机与目的加速器的事务层、数据链路层和物理接口。
一般而言（但须遵守 2.7.9 节所述规则），中间逻辑块可以先对从一侧挂接的 UPLI 接口接收到的请求和响应重新排序，然后再将其转发到另一侧挂接的 UPLI 接口。
UALink 协议级接口包含四个通道：请求（Req）通道、读响应/数据（RdRsp）通道、发起方数据（OrigData）通道和写响应（WrRsp）通道。
图 2-3 UALink 协议级接口的通道与控制信号
请求通道应包含请求地址、请求类型（读、写、原子、UPLI 写消息、厂商自定义命令）、控制请求大小的字段、源加速器标识符、目的加速器标识符、用于在请求通道上的未完成请求中唯一标识该请求的事务标签，以及各种附加的控制与奇偶校验信号。
发起方数据通道应包含：写请求、厂商自定义写类请求或 UPLI 写消息请求的某一个节拍（Beat）的 64 字节数据（写请求、厂商自定义写类请求或 UPLI 写消息请求可能需要多达四个节拍），或原子请求/厂商自定义原子类请求的操作数数据；数据或操作数数据的字节使能（Byte Enable）；当前节拍编号的指示；以及各种附加的控制与奇偶校验信号。请求的源加速器与目的加速器由请求通道中与这些数据节拍相关联的请求来指定。
读响应/数据通道应包含：读响应的某一个节拍的 64 字节数据（一个读响应可能需要多达四个节拍）、源加速器标识符、目的加速器标识符（原请求的源与目的值互换）、用于在请求通道上的未完成读请求中标识该请求的事务标签、读响应状态的指示、当前节拍编号的指示，以及各种附加的控制与奇偶校验信号。
写响应通道应包含：源加速器标识符、目的加速器标识符（原请求的源与目的值互换）、用于在请求通道上的未完成写请求中标识该请求的事务标签、写响应状态的指示，以及各种附加的控制与奇偶校验信号。
对于上述每个通道，都存在一个用于信用（Credit）管理的信号子集。这些信号从通道的接收方流向通道的发送方。这些信用管理信号将信用从通道接收方返还给通道发送方，使发送方能够在通道上发出新的有效节拍。通道发送方在没有持有相应信用的情况下，不应发出新的节拍。
UPLIClk 信号是界定时钟同步的 UALink 协议级接口上周期边界的时钟。UPLIReset_N 信号是用于复位 UALink 协议级接口的低有效信号。
在本规范中，出现在不同通道中的同类信号可以用简写记号来指代。例如，请求通道中的 ReqVld 信号、读响应/数据通道中的 RdRspVld 信号、写响应通道中的 WrRspVld 信号以及发起方数据通道中的 OrigDataVld 信号，统称为 *Vld。这些信号指示在每个通道上是否存在一个有效的信息"节拍"。
其他例子包括：
- *Data：（读响应/数据通道中的 RdRspData 信号；发起方数据通道中的 OrigData 信号）
- *CreditVld：（请求通道中的 ReqCreditVld 信号；读响应/数据通道中的 RdRspCreditVld 信号；写响应通道中的 WrRspCreditVld 信号；发起方数据通道中的 OrigDataCreditVld 信号）
2.2 UALink 协议栈组件
下面的图 2-4 展示了 UALink 协议栈组件（UALink Stack Component），它由一个独立的 UPLI 发起方、一个独立的 UPLI 完成方，以及实现 UALink 协议各层的逻辑单元组成。给定 UALink 协议栈内的 UPLI 完成方与 UPLI 发起方不应直接相互通信，而是分别连接到 UALink TL（传输层/事务层）。
在这里插入图片描述
图 2-4 UALink 协议栈组件
UALink TL 将由 UPLI 发起方和 UPLI 完成方驱动的 UPLI 协议通道（UPLI 发起方的 Req 与 OrigData；UPLI 完成方的 Rd Rsp/Data 与 Wr Rsp）转换为传递给 UALink DL 层的 TL Flit。类似地，UALink TL 从 UALink DL 接收 TL Flit，并将其解包到由 UPLI 完成方和 UPLI 发起方接收的 UPLI 协议通道中（完成方的 Req 与 OrigData；发起方的 Rd Rsp/Data 与 Wr Rsp）。
UALink DL 接收若干个 TL Flit，为 Flit 添加 CRC 保护和头部以形成 DL Flit，并将该 DL Flit 传递给 UALink PL。类似地，UALink DL 从 UALink PL 接收 DL Flit，剥离其中的 CRC 和头部，形成 TL Flit 并传递给 UALink TL。
UALink PL 接收 DL Flit，生成经过 FEC 编码的码字，将其串行化并发送到与之相连的 UALink 协议栈组件中的 UALink PL。类似地，UALink PL 从相连 UALink 协议栈组件的 UALink PL 接收带 FEC 的串行化码字，执行 FEC 解码并将其转换回 DL Flit。
要在加速器与交换机之间建立接口，需要按下图 2-5 所示连接两个 UALink 协议栈组件。整个接口应是双向且对称的：加速器中的 UPLI 发起方与交换机中的 UPLI 完成方通信，交换机中的 UPLI 发起方与加速器中的 UPLI 完成方通信。
图 2-5 相连的 UALink 协议栈组件
2.3 UALink UPLI 请求与响应路径
图 2-6 展示了两个不同加速器（ACC "A" 和 ACC "B"）通过交换机、经由不同的 UALink 协议栈组件对相连的逻辑表示：
图 2-6 两个加速器之间的端到端 UALink 连接
要从加速器 A 向加速器 B 发出请求，加速器 A 中的 UPLI 发起方应在请求通道上发出请求（如果该请求是写、UPLI 写消息或厂商自定义写类命令，还要在发起方数据通道上发出第一拍数据。原子或厂商自定义原子写类命令则在发起方数据通道的第一拍上发出操作数数据）。UALink TL 接收该请求，并应将其打包成一个 TL 控制半 Flit（Control Half-Flit）（数据节拍应打包为后续的数据半 Flit）。TL 半 Flit 两两组合构成 TL Flit，一个 TL Flit 应由两个 TL 半 Flit 组成。随后 UALink DL 对该 TL Flit 进行修改，加入 FEC 和 CRC，形成 DL Flit，然后作为比特流经过加速器 A 的 PHY 传输到交换机上的 PHY A。交换机上的 PHY A 是交换机上若干个可接收来自加速器 A 流量的 PHY 之一。比特流由 PHY A 重新构造成 DL Flit，经过 UALink DL A 转换为 TL Flit。最后，该 TL Flit 经过 UALink TL A，呈递给挂接在 UALink TL A 上的交换机中的 UPLI 完成方。
挂接在 UALink TL A 上的交换机 UPLI 完成方应打包这些 UPLI 协议元素，交换机核心应将这些元素路由到挂接在 UALink TL B 上、能够将请求递送给加速器 B 的 UPLI 发起方。从交换机穿越两个 UALink 协议栈组件到达加速器 B 的过程，应与从加速器 A 穿越到交换机的过程相同，并最终终止于加速器 B 中的 UPLI 完成方。
当请求在加速器 B 中被处理后，响应（以及读、厂商自定义读类命令、原子请求或厂商自定义原子类命令的数据）应由加速器 B 上的 UPLI 完成方发出，并穿越两个 UALink 协议栈组件到达与 UALink TL B 相连的 UPLI 发起方。这些响应经过交换机核心路由，然后从挂接在 UALink TL A 上的交换机 UPLI 完成方开始穿越两个 UALink 协议栈组件，最终终止于加速器 A 中的 UPLI 发起方。
下图 2-7 展示了一对加速器之间响应与请求的流向。为清晰起见，图中省略了 UALink DL 和 UALink PHY 模块。由加速器 A 的 UPLI 发起方发起的请求，最终发送到加速器 B 中的 UPLI 完成方。但加速器 A 的请求首先由交换机中的 UPLI 完成方接收，然后路由到交换机中最终连接到加速器 B 的 UPLI 发起方，再由它将请求传递给加速器 B 的 UPLI 完成方。
类似地，加速器 A 请求的响应，最终从加速器 B 中的 UPLI 完成方发送到加速器 A 中的 UPLI 发起方：先经过交换机中连接到加速器 B 的 UPLI 发起方，再经过交换机中最终连接到加速器 A 的 UPLI 完成方。
加速器 B 的请求与响应所经过的路径与加速器 A 的请求与响应相对称，但方向相反。
图 2-7 UPLI 请求与响应流
2.4 事务的端到端路由
本节展示请求从发起方设备到完成方设备的流程，以及相应响应从完成方设备回到发起方设备的流程。
一个 UALink Station 有四条 UALink Lane，可以分叉为一个 x4、两个 x2 或四个 x1 的 UALink 端口。Pod 中所有 UALink Station（无论在交换机上还是在加速器上）都必须以相同方式分叉。
每个加速器上的 UALink 端口数量应相等。Station 内的端口标识符应从 0 开始连续编号。UALink Station 应连续编号；请求或响应从交换机的源端口路由到交换机的目的端口的方式是：从源 Station 上的源端口路由到目标 Station，再到该 Station 内的目标端口。请求或响应在交换机内部如何路由，最终取决于实现。
在一个 Pod 中，物理交换机的端口数至少应等于 Pod 中加速器的数量，并且物理交换机的端口数应等于 Pod 中加速器的数量（当物理交换机的端口数与系统中加速器数量相等时------如下图 2-8 所示的 32 个加速器、32 条 x1 UALink 链路的示例系统------"交换机"与"物理交换机"两个概念是等同的）。这使得每台交换机都能通过特定端口连接到 Pod 中的每个加速器。下图 2-8 所示的示例系统展示了一个具有 32 个加速器（编号为加速器 0、1 至 31）和 32 台交换机（编号 0、1 至 31）的 Pod。为清晰起见，图中只画出了部分 UALink 链路，其余链路省略。
图 2-8 具有 32 个加速器、32 条 x1 UALink 链路的示例系统
加速器与交换机应使用各 UPLI 通道中一个特定的信号子集，在系统中路由和处理请求与数据。通道中的其余信号通常不经修改地随事务一起传送。但在事务穿过 Pod 的过程中，特定信号可能在不同位置被修改。除路由信号和其他信号外，一组信用管理信号应在任意给定 UALink 协议级接口内的每个 UALink 通道中提供流控。
具体而言，请求通道（Req）应包含两个 10 位信号"ReqSrcPhysAccID"和"ReqDstPhysAccID"，用于指定请求的源加速器与目的加速器。此外，请求通道还应包含一个 2 位信号"ReqPortID"：在某些 UALink 协议级接口处，它控制请求在相关 UALink 协议栈组件上路由到哪一条分叉的 UALink 链路；并且在所有 UALink 协议级接口处，它控制这些接口的时分复用（TDM），如后续章节所述。
读响应/数据（RdRsp）通道应包含信号"RdRspSrcPhysAccID"、"RdRspDstPhysAccID"和"RdRspPortID"；写响应（WrRsp）通道应包含信号"WrRspSrcPhysAccID"、"WrRspDstPhysAccID"和"WrRspPortID"。这些信号在各 UPLI 通道中的功能与请求通道中相应信号的功能类似。
下面用一个读请求示例来说明事务的处理过程：在按上图（图 2-8）连接的 Pod 中，从加速器 A（编号"0"）向加速器 B（编号"31"）发起对地址"X"的读请求，参见下图（图 2-9 读请求端到端流程与响应）：
图 2-9 读请求端到端流程与响应
读请求始于发起方设备（未画出）形成一个针对地址"X"的读请求。从概念上讲，请求可以从加速器上的任意 UALink 链路发出（每条 UALink 链路都挂接到一台交换机，而交换机能够将任意请求路由到任意目的加速器）。然而，一般而言，为了强制请求的顺序，对任意给定 256 字节内存区域的所有访问都必须从同一个 UALink 端口路由出去（在本例中，任意选择地址"X"走 Station 4、Port 2------完整细节见 2.7.9 节）。
读请求在发起方设备处形成，并发送到 Station 4 处的 UPLI 发起方，同时指示使用 UALink 端口 2、指示源加速器（本例中为 0）、指示目的加速器（本例中为 31），以及该读请求相关的任何其他信息。该 UPLI 发起方在 UALink 协议级接口 0 上发出请求，ReqPortID 设为"2"，ReqSrcPhysAccID 设为"0"，ReqDstPhysAccID 设为"31"。从源加速器 A 中的初始发起方到目的加速器 B 中的最终 UPLI 完成方，ReqSrcPhysAccID 和 ReqDstPhysAccID 字段应保持不变。
随后，读请求沿挂接在加速器 0 的 Station 4、Port 2 上的 UALink 链路传送（由 ReqPortID 值控制）。ReqPortID 值不应在 UALink 链路上传播，而是由交换机根据读请求进入交换机的端口在本地重新生成。读请求从 Station 0、Port 0 进入交换机 18（在此示例拓扑中，所有加速器上 Station 4、Port 2 的 UALink 链路都挂接到交换机 18；所有交换机上 Station 0、Port 0 的 UALink 链路都挂接到加速器 0）。根据进入交换机的端口，ReqPortID 被赋予新值 0，并在交换机内的 UALink 协议级接口 1 上使用。UALink 协议级接口 1 上的 ReqPortID 值只控制读请求穿越该接口进入交换机核心时的 TDM。
进入交换机核心后，基于 ReqDstPhysAccID 信号在目的路由表（Dst Route Table）中进行查找，确定读请求应路由到哪个 Station 和端口才能到达目的加速器（在本例中为 Station 7、Port 3------在此示例拓扑中，加速器 31 连接到所有交换机上的 Station 7、Port 3），并将读请求路由到该 Station（Station 7），在 UALink 协议级接口 2 上以新赋予的 ReqPortID 值 3 呈递该读请求。
UALink 协议级接口 2 上的 UPLI 发起方发出读请求，该请求从端口 3 离开交换机，并丢弃 ReqPortID 值。读请求随后从 Station 4、Port 2 进入加速器 31，ReqPortID 值被重新生成为"2"，表示该请求进入加速器 31 的端口。当请求在 UALink 协议级接口 3 上发出时使用这个再生的 ReqPortID 值，它控制该接口的 TDM。当请求被目的加速器中的完成方设备处理时，UALink 协议级接口 3 上的 UPLI 完成方保留 ReqPortID、ReqSrcPhysAccID 和 ReqDstPhysAccID 的值。
当读响应的信息就绪后（读响应可能包含多个响应节拍），UALink 协议级接口 3 上的 UPLI 完成方形成一个响应节拍，其 RdRspPortID 设为所保留的 ReqPortID 值"2"，并使用所保留的 Station 值将该响应节拍递送到 Station 4。这使 UALink 协议级接口 3 上的完成方能够将响应节拍路由到正确的输出端口和 Station，而无需参照原始读请求的地址。在 UALink 协议级接口 2 上，RdRspPortID 信号取再生值"3"，反映读响应进入交换机的端口。在 UALink 协议级接口 1 上，RdRspPortID 信号值"0"指示读响应应从 Station 0 上的端口 0 离开。该值来自 UALink 协议级接口 2 上以 RdRspDstAccPhysID 为索引的目的路由表查找，该查找表明目的加速器连接在这台交换机的端口 0、Station 0。最后，UALink 协议级接口 0 上 RdRspPortID 的值为"2"，与读响应进入源加速器的端口一致。对于包含多个数据节拍的读响应，每个节拍都遵循相同的过程。
写请求的行为与读请求类似，区别在于：数据通过发起方数据通道发往目的加速器，而返回的是一个不含数据的单节拍写响应。
2.5 UPLI 通道时分复用（TDM）
由 UALink 协议栈组件驱动的每个 UALink Station 可以连接 4 条 UALink Lane，这些 Lane 可以分叉成四条 x1 UALink 链路、两条 x2 UALink 链路或一条 x4 UALink 链路。挂接到 UALink 链路的 UALink 端口应编号为：x4 分叉时为"0"；x2 分叉时为"0、1"；x1 分叉时为"0、1、2、3"。
UALink 协议级接口中的每个通道都应进行时分复用（TDM），即在给定周期内，UALink 协议栈组件上 UALink 协议级接口通道内的信号（信用管理信号除外）都与挂接到某条 UALink 链路的特定分叉端口相关联。图 2-10 展示了一个带有两个相关 UALink 协议级接口的 UALink 协议栈组件示例，其 UALink Station 分叉为四条 x1 UALink 链路：
图 2-10 x1 分叉的 UALink Station
UALink 协议栈组件中 UALink 协议级接口的每个通道都应有一个唯一的"Valid"信号（请求通道为"ReqVld"，发起方数据通道为"OrigDataVld"，读响应/数据通道为"RdRspVld"，写响应通道为"WrRspVld"），指示何时有有效数据被驱动到通道上。给定 UALink 协议级接口通道的"PortID"信号（请求通道为"ReqPortID"，发起方数据通道为"OrigDataPortID"，读响应/数据通道为"RdRspPortID"，写响应通道为"WrRspPortID"），在该通道的"Valid"信号有效时应表示当前周期的 TDM 值，否则应被忽略。
TDM 值应每 N 个周期按升序循环遍历所有可能的端口值（取决于分叉方式），到达最大值后回绕到 0，其中 N 是 Station 中的端口数。对于给定 PortID，任何 UALink 协议级接口通道上每 N 个周期只能出现一次有效周期。
请求通道与发起方数据通道的 TDM 周期，应由该请求通道第一个 ReqVld 节拍上的"PortID"信号值来设定（无论请求是读或厂商自定义读类命令------此时 OrigData 字段未使用------还是写、原子、UPLI 写消息、厂商自定义写类命令、厂商自定义原子类命令或原子请求------此时使用 OrigData 字段），此后这些通道的 TDM 应保持固定（请求通道与发起方数据通道必须处于同一 TDM 相位，以便对于任何在发起方数据通道上发出数据的请求，Req 与 OrigData 通道在第一拍同时有效）。例如，如果复位后请求通道上第一个有效包的 ReqPortID 值为"2"，则该请求通道与发起方数据通道的 TDM 从该周期的值 2 开始，此后按如下序列循环：2、3、0、1、2、3、0、1、......（这是 x1 分叉的情况。x2 分叉时序列为 0、1、0、1、......；x4 分叉时序列为 0、0、0、......）。读响应/数据通道与写响应通道的 TDM 周期，应分别基于最初读响应节拍与写响应节拍的 PortID 值独立设定。
通道上任何后续"Valid"周期的 PortID 信号都应与当前周期既定的 TDM 值一致。显式的 PortID 信号消除了用显式同步序列来建立 TDM 值的必要，使接收方只需使用 PortID 即可识别 TDM 周期，而不必显式跟踪当前 TDM 周期（不过接收方实现可以选择跟踪 TDM 周期，以校验所接收节拍上的 TDM 周期值是否正确）。最后，显式的 PortID 信号也便于调试。
UALink TL 应负责把不同 UPLI 通道上、属于不同端口的各个有效包组装成出站 TL Flit，并把接收到的各个 TL Flit 放置到每个 UPLI 接口上正确的 UPLI TDM 周期中。
2.6 UALink 协议级接口流控与 UALink 整体流控
UALink 协议级接口中的流控应采用基于信用（Credit）的控制机制，信用按端口（per Port）、按 UPLI 通道（per UPLI Channel）划分。在 UPLI 接口初始化或复位之后，UPLI 通道的发送方应不持有任何信用，UPLI 通道的接收方应向发送方发出一组初始信用。
接收方应使用以下信号来指示正在初始发出（或在初始化之后返还）一个或多个信用：
- *CreditVld3:0 信号（ReqCreditVld3:0、OrigDataCreditVld3:0、RdRspCreditVld3:0、WrRspCreditVld3:0）应指示正在向发送方返还一个或多个信用以及对应的端口（*CreditVld0=1 表示端口 0，依此类推）。通过置位 *CreditVld3:0 中相应的信号，可以在一组端口的任意端口上同时返还信用。信用返还应独立于 UPLI 接口的时分复用（即任何端口的信用都可以在任何周期返还）。
- *CreditPool3:0 信号（ReqCreditPool3:0、OrigDataCreditPool3:0、RdRspCreditPool3:0、WrRspCreditPool3:0）应指示所返还信用的"类型"（"0"表示 VC 信用，"1"表示 Pool 信用）以及对应的端口（*CreditPool0 表示端口 0 的信用类型，依此类推）。该信号仅在相应的 *CreditVld3:0 信号有效时才视为有效。
- 一组 *CreditPort0,1,2,3VC1:0 信号（ReqCreditPort0VC1:0、ReqCreditPort1VC1:0、ReqCreditPort2VC1:0、ReqCreditPort3VC1:0、OrigDataPort0VC1:0......RdRspCreditPort0VC1:0......WrRspCreditPort0VC1:0......WrRspCreditPort3VC1:0）应指示该信号所关联通道与端口上返还信用的虚拟通道（Virtual Channel）（例如 ReqCreditPort0VC1:0 是端口 0 上请求通道返还信用所属的虚拟通道，其余信号依此类推）。该信号仅在相应的 *CreditVld3:0 信号有效时才视为有效。
- 一组 *CreditPort0,1,2,3Num1:0 信号（ReqCreditPort0Num1:0、ReqCreditPort1Num1:0......WrRspCreditPort3Num1:0）应指示该信号所关联通道与端口上返还的信用数量（例如 ReqCreditPort0Num1:0+1 是端口 0 上请求通道返还的信用数，其余信号依此类推）。该信号仅在相应的 *CreditVld3:0 信号有效时才视为有效。
在初始化或复位时，UPLI 通道的接收方将释放一组与接收方可用缓冲相对应的信用。
接收方可以发出一组数量等于接收方 Pool 缓冲数量的 Pool 信用。由这些信用指示的接收方 Pool 缓冲应能够处理任意虚拟通道的 UPLI 节拍。接收方也可以发出一组与特定虚拟通道相关联的 VC 信用，数量等于接收方为所支持的每个虚拟通道准备的 VC 缓冲数量。接收方的 VC 缓冲只需处理特定虚拟通道的 UPLI 节拍。
接收方应只释放 Pool 信用、只释放虚拟通道信用，或释放 Pool 信用与虚拟通道信用的某种组合。
当接收方完成初始信用释放后，随着每个端口完成，接收方置位 *CreditInitDone3:0 信号（ReqCreditInitDone3:0、OrigDataCreditInitDone3:0、RdRspCreditInitDone3:0、WrRspCreditInitDone3:0）。*CreditInitDone3:0 中的每个信号与给定端口相关联（*CreditInitDone2 对应相关通道上的端口 2）。*CreditInitDone3:0 信号可以各自独立置位，一旦置位应保持置位，直到 UPLI 接口复位或断电。
发送方应监视 *CreditInitDone 信号，直到该信号连续置位达到一个由实现定义的、大于 1 的周期数。此后，发送方应认为初始信用发放已完成，并不再监视该信号。
对信号进行一段由实现定义长度的连续置位监视，可确保该信号上短于该突发长度的错误不会错误地提前终止初始信用释放。此外，在此突发之后忽略该信号，可确保该信号上任何后续错误都不会影响通道。
一旦给定端口和通道的初始信用释放完成，且所有其他约束都满足，发送方即可开始为该端口和通道发出 UPLI 节拍。例如，当发送方想要发出一个写操作时，它应先在请求通道上拥有必要信用（用于发出请求），并在发起方数据通道上拥有必要信用（用于从请求开始连续发出数据节拍），然后才能发出该请求。发出一个节拍时，发送方应设置 *VC1:0 信号（ReqVC1:0、OrigDataVC1:0、RdRspVC1:0、WrRspVC1:0）以指示该节拍的虚拟通道，并设置 *Pool 信号（ReqPool、OrigDataPool、RdRspPool、WrRspPool）以指示发出该节拍使用的是虚拟通道信用还是 Pool 信用。
如果初始释放了任何 Pool 信用，发送方应使用这些 Pool 信用为不同虚拟通道发出 UPLI 节拍（通过设置 *Pool = b'1' 来指示），Pool 信用在各虚拟通道之间的分配由发送方选择（且发送方可随时间调整）。如果初始释放了任何虚拟通道信用，发送方应按照初始为每个虚拟通道释放的虚拟通道信用数量，使用虚拟通道信用为这些虚拟通道发出 UPLI 节拍（通过设置 *Pool = b'0' 来指示）。
当一个 UPLI 节拍到达接收方时，接收方应记录该节拍的虚拟通道（*VC1:0）和 Pool 指示（*Pool），并在返还该节拍对应的信用时将这些值回送给发送方。发送方应把返还的信用计入相应的 Pool 计数或虚拟通道信用计数。
图 2-11 流控环路
上图（图 2-11）展示了两个加速器之间完整路径上的各种流控信用环路。路径上每个 UALink 协议级接口实例都使用 UALink 协议级接口信用控制。在相邻两个 UALink TL 之间，还使用一种独立的信用环路机制来调节 UALink TL 之间的请求与响应。
2.7 接口信号
本节描述构成 UALink 协议级接口的信号，以及事务如何在 UALink 协议级接口的各个通道上传送。
2.7.1 信号组
UALink 协议级接口应组织为以下信号组：
- 公共信号（Common signals）
- UALink 协议级接口控制信号
- 请求通道
- 读响应/数据通道
- 写响应通道
- 发起方数据通道
在本规范中，出现在不同通道中的同类信号可以用简写记号来指代。例如，请求通道中的 ReqVld 信号、读响应/数据通道中的 RdRspVld 信号、写响应通道中的 WrRspVld 信号以及发起方数据通道中的 OrigDataVld 信号，统称为 *Vld。这些信号应指示在每个通道上是否存在一个有效的信息节拍。
其他例子包括：
- *Data：（读响应/数据通道中的 RdRspData 信号；发起方数据通道中的 OrigData 信号）
- *CreditVld：（请求通道中的 ReqCreditVld 信号；读响应/数据通道中的 RdRspCreditVld 信号；写响应通道中的 WrRspCreditVld 信号；发起方数据通道中的 OrigDataCreditVld 信号）
2.7.2 公共信号
表 2-1 列出了构成公共信号组的信号。这些信号应由 SoC 全局逻辑（SOC-pervasive logic）提供给每个 UALink 协议级接口。
表 2-1 公共信号
| 名称 | 位宽 | 描述 |
|---|---|---|
| UPLIClk | 1 | 接口时钟，源自 SoC 全局逻辑。UALink 协议级接口信号以及 UPLIReset_N、*ClkReq 和 *ClkAck 信号都同步于此时钟。 |
| UPLIReset_N | 1 | 接口复位信号，低有效，其置位与撤销均同步于 UPLIClk。 |
UPLIClk 的上升沿决定跨接口信息传输的时序。一般而言，所有信号应在 UPLIClk 上升沿之前及紧随后保持稳定。UPLIReset_N 应为负有效信号（即信号电平为低时表示有效），且可以在任何时刻置位。
2.7.3 UPLI 事务/通道的使用
UALink 协议级接口上的事务可以包含读、写、厂商自定义命令、UPLI 写消息请求、厂商自定义 UPLI 写消息请求或原子操作。这些事务从内存读取、向内存写入、原子地修改内存（可选地返回内存中的原始值）、递送 UPLI 消息，或执行厂商定义的操作。
一个 UPLI 事务由多个周期（也称为"节拍"）组成，根据 UPLI 事务的类型，这些节拍应以特定顺序出现在 UALink 协议级接口的特定通道子集（请求、读响应/数据、写响应、发起方数据）上。事务应在 UPLI 发起方发出，并在 UPLI 完成方处理。UPLI 完成方应在读响应/数据通道或写响应通道之一上（但不能同时在两者上）返回对该请求的响应。使用哪个通道返回响应取决于事务类型。
每个 UPLI 事务都应由请求通道上的一个请求发起，以请求通道中有效信号（ReqVld）的置位为标志（一个节拍）。请求节拍应包含与路由和标识该请求相关的其他信息，如端口 ID（ReqPortID）、源加速器与目的加速器物理 ID（ReqSrcPhysAccID 和 ReqDstPhysAccID），以及用于将该请求与其他请求区分开的事务标签（ReqTag）。此外，请求节拍还应包含请求本身的信息，如地址（ReqAddr）、命令类型（ReqCmd）、要传输的双字数量指示（ReqLen）、请求属性（ReqAttr）以及其他字段。
读事务返回的数据应以数据节拍的形式，连同提供读响应附加信息的字段一起，通过读响应/数据通道从完成方传回发起方。这些信息应包括读事务的状态（RdRspStatus）、本节拍返回的是第几拍数据（RdRspOffset）、响应中数据节拍的总数（RdRspNumBeats）、本节拍数据是否已损坏（RdRspDataError），以及当前节拍是否为要传输的最后一拍（RdRspLast）。一个读响应可以包含一到四个数据节拍。
读响应节拍应在读请求被最终完成方接收并处理之后出现在读响应/数据通道上。
对于写事务，数据应以一到四个数据节拍的形式，通过发起方数据通道从初始发起方传送到最终完成方；每个节拍都应包含端口 ID（OrigPortID）字段以提供部分路由信息。给定事务的第一个发起方数据节拍应与写请求出现在同一周期。这使发起方数据节拍能够从请求通道中的写请求继承其余的路由与标识信息（ReqSrcPhysAccID、ReqDstPhysAccID、ReqTag）以及事务中数据节拍的数量（ReqNumBeats）。
写请求节拍还应包含如下信息：一组字节使能，用于指示内存中要更新的字节（OrigDataByteEn）；本节拍发送的是第几拍数据（OrigDataOffset）；本节拍数据是否已损坏（OrigDataError）；以及当前节拍是否为要传输的最后一拍（OrigDataLast）。
在 UALink 协议级接口中，原子请求既可以在原子地修改内存的同时返回修改前内存的初始值（称为 AtomicR 命令），也可以只执行内存修改（在 UPLI 中称为 AtomicNR 命令）。
此外，所有原子命令（AtomicR 和 AtomicNR）都需要一个或两个操作数来控制对内存的原子更新。例如，"原子加（Atomic add）"需要一个参数来指定要原子地加到内存位置上的值；"比较并交换（Compare-and-Swap）"需要两个参数：一个用于与内存位置进行初始比较的值，以及一个初始比较匹配时要交换进内存位置的值。各种 AtomicR/AtomicNR 命令的精确语义及所需参数个数不在本规范的规定范围内；但所有原子命令都应限于不超过两个参数。
对于 AtomicR 命令或 AtomicNR 命令的原子请求，事务按上述写请求的方式进行，区别在于 OrigData 通道用于传输原子的操作数数据，而不是写数据。对于 AtomicNR 命令，完成方应在写响应通道上提供响应。对于 AtomicR 命令，完成方应在读响应/数据通道上以数据形式返回最初从内存读出的值，并附带事务的状态信息。
2.7.4 请求通道
发起方应使用请求通道来请求向系统内存空间写入数据或从中读出数据。表 2-2"请求通道信号"列出了构成请求通道的信号。
标有 Driver 的列指示该信号由发起方还是完成方驱动。
表 2-2 请求通道信号
请求通道信息与控制信号------这些信号按 ReqPortID 值进行时分复用（TDM）。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| ReqVld | 1 | 发起方 | 请求有效。指示发起方正在此通道上呈递有效信息（一个节拍）。 |
| ReqPortID | 2 | 发起方 | 请求端口 ID。当发起方将请求通道驱动到某个 TL 时，指示该请求通道节拍要呈递到与该 TL 相关联的哪个端口。对所有发起方而言，ReqPortID 指示请求通道的 TDM 周期。 |
| ReqASI | 2 | 发起方 | 请求地址空间标识符。对于任何不是 UPLI 写消息请求或厂商自定义命令的请求，标识地址空间。对于 UPLI 写消息请求，该字段或为保留，或指定该类 UPLI 写消息请求的特定功能（UPLI 写消息的类型在 ReqMetaData 字段中指定）；对于厂商自定义命令，该信号由厂商定义。 |
| ReqAuthTag | 64 | 发起方 | 请求认证标签（Authorization Tag）。详见"安全"一章中关于该信号与认证的说明。当请求未启用认证或 ReqVld 撤销时，该字段应驱动为零。 |
| ReqSrcPhysAccID | 10 | 发起方 | 请求源物理加速器 ID。请求的源加速器（即发起该请求的、带有初始 UPLI 发起方的加速器）的物理加速器 ID。 |
| ReqDstPhysAccID | 10 | 发起方 | 请求目的物理加速器 ID。请求的目的加速器（即带有将满足该请求的最终 UPLI 完成方的加速器）的物理加速器 ID。 |
| ReqTag | 11 | 发起方 | 请求标签。该字段是事务标签，用于在 Station 内发出该请求的源加速器 UALink 端口的所有未完成请求中唯一标识每个请求（标签在所有命令类型间共享）。 |
| ReqNumBeats | 2 | 发起方 | 请求数据节拍数。对于写、厂商自定义写类命令、原子、厂商自定义原子类命令或 UPLI 写消息，指示该请求在 OrigData 通道上传输的数据节拍数。传输的数据节拍数为 (ReqNumBeats+1)。该字段旨在使交换机无需根据接口中的其他字段来计算该请求在 OrigData 通道上传输的节拍数。交换机应依赖该字段来确定请求在 OrigData 通道上传输的节拍数。该字段仅对 ReqCmd5=1 的请求（原子、写、厂商自定义写类命令、UPLI 写消息请求和厂商自定义 UPLI 写消息请求）有效。对于 ReqCmd5=0 且不是读类厂商自定义命令的请求（即读），该字段应驱动为 0。对于读类厂商自定义命令的请求，该信号有效，可以（但不是必须）用于计算读响应返回的数据节拍数。 |
| ReqAddr | 57 | 发起方 | 请求地址。对于任何不是 UPLI 写消息请求、厂商自定义命令或厂商自定义 UPLI 写消息的请求，该字段应指定请求地址。对于 UPLI 写消息请求，该字段或为保留，或指定 UPLI 写消息的控制信息（UPLI 写消息的类型应在 ReqMetadata 字段中指定）。除非该 UPLI 写消息类型将此字段定义为携带地址，否则该字段不为 UPLI 写消息指定地址。UPLI 写消息数据以一到四个 64 字节数据节拍发出，与 ReqAddr 字段的值无关。对于厂商自定义命令，该信号由厂商定义。对于厂商自定义命令和厂商自定义 UPLI 写消息，该字段由厂商定义。 |
| ReqCmd | 6 | 发起方 | 请求命令。该字段指示此请求的命令，详见下文。 |
| ReqLen | 6 | 发起方 | 请求长度。对于任何不是 UPLI 写消息、厂商自定义 UPLI 写消息或厂商自定义命令的请求，该字段指示事务请求要传输的数据双字数。请求的传输大小为 (ReqLen+1) 个双字。对于 WriteFull 请求，该字段应指示 64、128、192 或 256 字节的传输，分别对应一、二、三或四个 64 字节数据节拍。对于 UPLI 写消息请求，该字段或为保留，或指定该类 UPLI 写消息请求的特定功能（UPLI 写消息的类型在 ReqMetaData 字段中指定）。对于厂商自定义命令或厂商自定义 UPLI 写消息请求，该信号由厂商定义。 |
| ReqAttr | 8 | 发起方 | 请求属性。对于任何不是 UPLI 写消息、厂商自定义 UPLI 写消息或厂商自定义命令的请求，该字段应指定在目的加速器使用的扩展事务属性。该字段的编码取决于请求类型，详见下文。对于 UPLI 写消息请求，该字段或为保留，或指定该类 UPLI 写请求的特定功能（UPLI 写消息的类型由 ReqMetadata 字段定义）。对于厂商自定义命令或厂商自定义 UPLI 写消息，该字段由厂商定义。 |
| ReqMetaData | 8 | 发起方 | 对于任何不是 UPLI 写消息请求、厂商自定义 UPLI 写消息请求或厂商自定义命令的请求，该字段应为随请求传送给最终完成方的、由实现定义的控制信息字段。对于 UPLI 写消息或厂商自定义 UPLI 写消息，该字段指定 UPLI 写消息的类型，如下所述。对于厂商自定义命令，该字段由厂商定义。 |
| ReqVC | 2 | 发起方 | 请求虚拟通道。指定请求的虚拟通道。在 UALink 1.0 中，该字段对交换机而言仅是信息性的，但该值会在信用返还信号中回送给发起方。交换机只有一个虚拟通道，并将该字段原样传递给目的加速器。 |
| ReqPool | 1 | 发起方 | 请求 Pool。指定请求是使用 Pool 信用（ReqPool=1）还是虚拟通道信用（ReqPool=0）发出的。 |
请求通道信用返还信号------这些信号不进行时分复用。任何端口的信用都可以在任何周期返还。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| ReqCreditInitDone | 4 | 完成方 | 请求信用初始化完成。置位时向发起方指示，与该单个信号相关联端口的初始信用释放已完成（ReqCreditInitDone2 表示端口 2 已完成）。各个"done"信号可以独立置位，一旦置位将保持置位，直到接口复位或断电。 |
| ReqCreditVld | 4 | 完成方 | 请求信用有效。指示正在向发起方释放一个或多个信用。信用按端口划分，一个 Station 可以有 1、2 或 4 个端口。ReqCreditVldn 对应端口 n。信用可以在多个端口上同时释放。 |
| ReqCreditPool | 4 | 完成方 | 请求信用 Pool。指示所释放信用对应的请求（即消耗了该 Pool 或虚拟通道信用的请求）在 ReqPool 上所指示的信用类型。为"0"时，所释放的是虚拟通道信用；为"1"时，所释放的是 Pool 信用。与返还信用对应的请求的 ReqVC 值被放置在相应的 ReqCreditPort0,1,2,3VC 信号上。 |
| ReqCreditPort0VC | 2 | 完成方 | 请求信用端口 0 虚拟通道。指示消耗了正在为端口 0 释放的 Pool 或虚拟通道信用的请求在 ReqVC 上所指示的虚拟通道。当 ReqCreditVld0 置位时有效。 |
| ReqCreditPort1VC | 2 | 完成方 | 请求信用端口 1 虚拟通道。含义同上，对应端口 1。当 ReqCreditVld1 置位时有效。 |
| ReqCreditPort2VC | 2 | 完成方 | 请求信用端口 2 虚拟通道。含义同上，对应端口 2。当 ReqCreditVld2 置位时有效。 |
| ReqCreditPort3VC | 2 | 完成方 | 请求信用端口 3 虚拟通道。含义同上，对应端口 3。当 ReqCreditVld3 置位时有效。 |
| ReqCreditPort0Num | 2 | 完成方 | 请求信用端口 0 信用数。指示为端口 0 返还的信用数（最多 4 个，ReqCreditPort0Num+1）。仅当 ReqCreditVld0 置位时有效。 |
| ReqCreditPort1Num | 2 | 完成方 | 请求信用端口 1 信用数。指示为端口 1 返还的信用数（最多 4 个，ReqCreditPort1Num+1）。仅当 ReqCreditVld1 置位时有效。 |
| ReqCreditPort2Num | 2 | 完成方 | 请求信用端口 2 信用数。指示为端口 2 返还的信用数（最多 4 个，ReqCreditPort2Num+1）。仅当 ReqCreditVld2 置位时有效。 |
| ReqCreditPort3Num | 2 | 完成方 | 请求信用端口 3 信用数。指示为端口 3 返还的信用数（最多 4 个，ReqCreditPort3Num+1）。仅当 ReqCreditVld3 置位时有效。 |
请求通道奇偶校验信号
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| ReqVldParity | 1 | 发起方 | 请求有效奇偶校验。对 ReqVld 的偶校验。每个周期都检查。 |
| ReqAddrParity | 1 | 发起方 | 请求地址奇偶校验。对 ReqAddr 的偶校验。仅在 ReqVld 置位时检查。 |
| ReqParity | 1 | 发起方 | 请求奇偶校验。ReqParity 对 ReqTag、ReqLen、ReqAttr、ReqCmd、ReqMetaData、ReqVC、ReqSrcPhysAccID、ReqDstPhysAccID、ReqPortID、ReqNumBeats 提供偶校验。仅在 ReqVld 置位时检查。 |
| ReqCreditVldParity | 1 | 完成方 | 请求信用有效奇偶校验。对 ReqCreditVld 的偶校验。每个周期都检查。 |
| ReqCreditParity | 1 | 完成方 | 请求信用奇偶校验。对 ReqCreditPort0VC、ReqCreditPort1VC、ReqCreditPort2VC、ReqCreditPort3VC、ReqCreditPort0Num、ReqCreditPort1Num、ReqCreditPort2Num、ReqCreditPort3Num 和 ReqCreditPool 的偶校验。在 ReqCreditVld 非零的节拍中检查。 |
发起方设备应使用请求通道来请求向系统内存空间传入或从中传出数据。请求的数据量应不超过 256 字节，且不应跨越 256 字节边界。一个时钟周期最多可以传输 64 字节数据，称为一个节拍（Beat）。大于 64 字节的传输以一系列节拍来传输（也称为突发，Burst）。
2.7.4.1 ReqASI
ReqASI（请求地址空间标识符）字段的用法应由加速器定义，取决于具体实现。ReqASI 字段的一种可能用法是区分节点内通信与跨节点通信的请求。这使加速器能够识别不同的请求集合，并对不同的请求集合采取不同的地址转换、保护限制、最大地址大小等处理方式。
2.7.4.2 ReqTag
每个发起方设备在收到响应的最后一个节拍之前，不得重用某个 ReqTag（请求标签）。请求标签应在每个端口上唯一。
2.7.4.3 ReqAddr
ReqAddr（请求地址）字段应提供所传输第一个双字的字节地址。
2.7.4.4 ReqLen
ReqLen（请求长度）字段应指定要传输的双字数。所指示的传输大小应为 (ReqLen+1)。
2.7.4.5 ReqAttr
ReqAttr（请求属性）应提供关于事务请求的特定属性信息。其编码取决于请求类型，如下表所示。
表 2-3 读请求的 ReqAttr 用法
| 位域 | 子字段 |
|---|---|
| ReqAttr7:4 | 字节使能，最后一个双字。如果最后一个双字同时也是第一个双字，则忽略。 |
| ReqAttr3:0 | 字节使能，第一个双字 |
表 2-4 原子请求的 ReqAttr 用法
| 位域 | 子字段 |
|---|---|
| ReqAttr7:4 | 操作类型（OpType3:0） |
| ReqAttr3:2 | 操作数大小（OpSize） |
| ReqAttr1 | 保留 |
| ReqAttr0 | 操作类型（OpType4） |
原子读-改-写的操作类型编码在 OpType4:0 中（ReqAttr0 与 ReqAttr7:4 拼接）。读-改-写的精确语义以及它使用一个还是两个操作，由实现定义。
操作数大小 OpSize 编码在 ReqAttr3:2 字段中，如下所示。
表 2-5 原子 OpSize 编码
| OpSize | 操作数大小 |
|---|---|
| 00b | 32 位 |
| 01b | 64 位 |
| 10b | 16 位 |
| 11b | 8 位 |
对于写操作，ReqAttr 字段可以以实现特定的方式用于传递写操作的附加元数据。
对于厂商自定义命令，ReqAttr 字段应由厂商定义。
对于 UPLI 写消息请求和厂商自定义 UPLI 写消息请求，ReqAttr 字段应按下文表 2-7 定义。
2.7.4.6 ReqCmd
ReqCmd（请求命令）字段应指示此请求的命令。当 ReqCmd5 为 1b 时，发起方应在发起方数据通道上传输数据。对于此类命令，除了要从请求通道流控获得一个信用以发出请求外，还应为发起方数据通道获得一个或多个信用。
请求通道 ReqCmd 字段的合法命令类型和合法编码见下表 2-6。
标有"Data Channels"的列列出该命令使用的数据通道及其用途。Resp Chan 列指示该命令的响应在读响应/数据通道还是写响应通道上返回给发起方。
ReqCmd5=1 表示该命令将在发起方数据通道上传输数据。
- ReqCmd5:4=00 表示读类请求（即请求不随带数据或字节掩码）。
- ReqCmd5:4=10 表示写类请求（即请求随带数据以及可能的字节掩码）。
- ReqCmd5:4=11 表示原子类请求（即请求随带操作数数据和字节掩码）。
表 2-6 命令
| UPLI 命令 | ReqCmd | 数据通道 | 响应通道 | 描述 |
|---|---|---|---|---|
| 保留 | 00 0000b/00h -- 00 0010b/02h | - | - | |
| Read | 00 0011b/03h | Rd Rsp/Data（读数据） | Read | 读。I/O 一致性读，最多 256 字节（4 拍）。 |
| 保留 | 00 0100b/04h -- 00 0111b/07h | - | - | |
| 厂商自定义命令保留 | 00 1000b/08h -- 00 1111b/0Fh | - | - | 为读类厂商自定义命令保留的命令编码。 |
| 保留 | 01 0000b/10h -- 01 0111b/17h（至 10-0111b/27h） | - | - | |
| Write | 10 1000b/28h | Orig Data（写数据） | Write | 写。I/O 一致性写，最多 256 字节（4 拍）。 |
| WriteFull | 10 1001b/29h | Orig Data（写数据） | Write | WriteFull。一个或多个完整（即所有节拍的所有字节使能均置位）数据节拍的 I/O 一致性存储。 |
| UPLI Write Message | 10 1010b/2Ah | Orig Data（写数据） | Read 或 Write | UPLI 写消息，从源加速器发起方向目的加速器完成方发出一条 UPLI 消息。UPLI 消息的类型编码在 ReqMetaData 字段中。根据 UPLI 消息的类型，响应在读响应通道或写响应通道上返回。 |
| 保留 | 10 1011b/2Bh | - | - | |
| 厂商自定义命令保留 | 10 1100b/2Ch -- 10 1111b/2Fh | - | - | 为写类厂商自定义命令保留的命令编码。 |
| AtomicR | 11 0000b/30h | Rd Rsp/Data（返回的读数据）；OrigData（原子操作数） | Read | 原子返回数据。带数据返回的 I/O 一致性原子读-改-写。 |
| 保留 | 11 0001b/31h | |||
| AtomicNR | 11 0010b/32h | OrigData（原子操作数） | Write | 原子无返回数据。不带数据返回的 I/O 一致性原子读-改-写。 |
| 保留 | 11 0011b/33h -- 11 1011b/3Bh | - | - | |
| 厂商自定义命令保留 | 11 1100b/3Ch -- 11 1111b/3Fh | - | - | 为原子类厂商自定义命令保留的命令编码。 |
读（Reads）
读命令为以下一种：
- Read
发起方应执行读请求来读取数据。请求大小最多 256 字节，且不应跨越 256 字节边界。当读响应返回时，读请求在 UPLI 上视为完成。
读请求应参与目的加速器中的本地一致性协议，并应返回该加速器中一致的读取值。
写（Writes）
写命令为以下两种：
- Write
- WriteFull
发起方应执行写操作，将数据写入目的加速器上的系统内存。数据应在发起方数据通道上发送，有效字节由 OrigDataByteEn 字段指示。写请求最多 256 字节（4 个 OrigData 节拍），且不应跨越 256 字节边界。
WriteFull 请求是限于长度为 64、128、192 或 256 字节的写，且 WriteFull 请求涉及的所有字节的所有字节使能都必须有效（这使事务层可以不为该写传输字节使能，而由目的加速器处的 TL 重构字节使能，从而节省链路带宽）。
写请求和 WriteFull 请求应参与目的加速器中的本地一致性协议，并应更新内存以及为在目的加速器执行一致性更新所必需的任何缓存。
原子操作（Atomics）
原子命令为以下两种：
- AtomicR
- AtomicNR
发起方应发出原子命令来执行（在完成方处的）原子读-改-写操作。AtomicR 命令执行原子读-改-写操作并返回从内存中读出的初始值。AtomicNR 命令在内存中执行原子读-改-写操作，不返回从内存中读出的初始值。内存如何被修改的精确语义，以及原子命令需要一个还是两个操作数，由实现决定，不在本规范中定义。
原子请求应参与目的加速器中的本地一致性协议，并应更新内存以及为在目的加速器执行一致性更新所必需的任何缓存。如果该原子操作是 AtomicR，则应返回更新前该（些）位置的一致值。
UPLI 写消息（UPLI Write Messages）
UPLI 写消息由以下命令组成：
- UPLI Write Message
UPLI 写消息应是从源加速器中的 UPLI 发起方到目的加速器中的 UPLI 完成方的一条消息。该消息应以语义类似于原子操作的请求来传送。UPLI 写消息应在 OrigData 通道上传送一到四个 64 字节数据节拍的载荷，载荷可以不含有效内容；ReqMetaData 字段用于表示该消息是哪种具体的 UPLI 写消息类型（最多 256 种选择）。
对于每个 UPLI 写消息，其所需的响应应根据 UPLI 写消息的类型，在读响应/数据通道或写响应通道上传送（类似于 AtomicR 和 AtomicNR 请求的处理方式）。如果 UPLI 写消息的响应在读响应/数据通道上传送，则响应中 64 字节数据节拍的数量取决于该 UPLI 写消息的类型，可以从最少一拍到四拍不等，且不必与 UPLI 写消息请求传输的 64 字节数据节拍数一致。ReqMetaData 字段的一组取值（0xF0-0xFF）用于指定厂商自定义 UPLI 写消息类型。
UPLI 写消息或厂商自定义 UPLI 写消息和/或其相关响应在源加速器或目的加速器中产生的语义效应（如果有），取决于该 UPLI 写消息或厂商自定义 UPLI 写消息的具体类型。
厂商自定义命令（Vendor Defined Commands）
UPLI 接口定义了三类厂商自定义命令（VDC）：读类 VDC（ReqCMD=0x08h-0x0Fh）、写类 VDC（ReqCMD=0x2Ch-0x2Fh）和原子类 VDC（ReqCMD=0x3Ch-0x3Fh）。对于每个厂商自定义命令，以下 UPLI 请求接口信号应由厂商定义：ReqASI、ReqAddr、ReqLen、ReqAttr 和 ReqMetaData。UPLI 请求接口中的其余信号应保持与非 VDC 相同的功能。
写类或原子类厂商自定义请求在 OrigData 通道上传输的 UPLI 数据节拍数，应完全由该厂商自定义请求中的 ReqNumBeats 信号值控制。
对于读类厂商自定义命令，或返回数据的原子类厂商自定义命令，相关读响应中返回的数据节拍数应是该厂商自定义命令中各信号（可能包括 ReqCMD 和 ReqNumBeats）的、由实现定义的函数。相关读响应中返回的数据节拍数应完全由 RdRspNumBeats 信号控制。
厂商自定义命令的数据节拍布局和内容由厂商定义。
任何访问内存的 VDC，都应在加速器上与该 VDC 所访问的同一 256 字节内存区域内的非 VDC 请求相同的端口上发出。
任何 VDC 都不应访问和/或修改超过一个 256 字节内存区域。
读类 VDC 不应在 OrigData 通道上发出数据节拍，读类 VDC 的响应应在读响应通道上返回。
写类 VDC 应在 OrigData 通道上发出数据节拍（带相应字节使能），写类 VDC 的响应应在写响应通道上返回。
原子类 VDC 应在 OrigData 通道上发出数据节拍，原子类 VDC 的响应应在读响应通道或写响应通道上返回。
2.7.4.7 ReqMetaData
对于不是 UPLI 写消息请求的请求，ReqMetaData 字段应传送由实现定义的控制信息。
对于 UPLI 写消息请求，ReqMetadata 字段应指示 UPLI 写消息的具体类型（最多 256 种）。下表列出了合法的 UPLI 写消息请求类型、各类型下可能为保留或被使用的字段的定义，以及随请求发送的 64 字节 OrigData 节拍数：
表 2-7 UPLI 写消息请求类型
| ReqMetaData 值 | 类型 | ReqAddr | ReqASI | ReqAttr | 写节拍数/内容 | 响应通道/读时节拍数 |
|---|---|---|---|---|---|---|
| 0x00 | NOP | 保留 | 保留 | 保留 | 1 / 空（全零） | Write |
| 0x01 | KeyRollMsg.ReqChannel | 保留 | 保留 | 保留 | 1 / 空（全零） | Write |
| 0x02 | KeyRollMsg.RdRspChannel | 保留 | 保留 | 保留 | 1 / 空（全零） | Read |
| 0x03 | KeyRollMsg.WrRspChannel | 保留 | 保留 | 保留 | 1 / 空（全零） | Write |
| 0x04-0xEF | 保留 | |||||
| 0xF0-0xFF | 厂商自定义 UPLI 写消息 | 厂商定义 | 厂商定义 | 厂商定义 | 厂商定义 | 厂商定义 |
为便于与 UALink 规范未来版本的兼容，各实现应从低位开始使用 ReqMetaData 的位，并尽可能多地留出高位不使用（这将使 UALink 规范的未来版本在需要时更容易回收 ReqMetaData 的位用于新的预定义用途）。
2.7.5 读响应/数据通道
读响应/数据通道应为特定的读请求提供读响应和读响应数据。
数据应以一个或多个节拍在 RdRspData 字段中返回。响应与引发它的请求之间基于 RdRspTag 字段中的信息进行匹配。读响应要对应于某个读请求，RdRspTag 应与发起该数据传输的请求的 ReqTag 相匹配。
标有 Driver 的列指示该信号由发起方还是完成方驱动。
表 2-8 读响应/数据通道信号
读响应/数据通道信息与控制信号------这些信号按 RdRspPortID 值进行时分复用（TDM）。
| 名称 | 位宽 | 驱动方 | 描述 |
|---|---|---|---|
| RdRspVld | 1 | 完成方 | 读响应有效。指示完成方正在此通道上呈递有效信息（一个数据节拍）。 |
| RdRspPortID | 2 | 完成方 | 读响应/数据端口 ID。当完成方将读响应/数据通道驱动到某个 TL 时，指示该读响应/数据通道节拍要呈递到与该 TL 相关联的哪个端口。对所有完成方而言，RdRspPortID 指示读响应/数据通道的 TDM 周期。 |
| RdRspAuthTag | 64 | 完成方 | 读响应认证标签。详见"安全"一章中关于该信号与认证的说明。当响应未启用认证或 RdRspVld 撤销时，该字段应驱动为零。 |
| RdRspSrcPhysAccID | 10 | 完成方 | 读响应源物理加速器 ID。读响应的源加速器 ID。该字段应包含引发此读响应的请求的 ReqDstPhysAccID 值（原请求的目的加速器是读响应的源加速器）。该信息不是功能所必需的，但有助于调试（读响应使用 RdRspDstPhysAccID 字段路由）。此字段携带正确值是可选的（即 UALink TL 或 UALink DL 可以将此字段压缩掉）。当该字段不含准确值时，应将其驱动为零。由于该字段可能不准确，因此不得将其用于功能性目的。 |
| RdRspDstPhysAccID | 10 | 完成方 | 读响应目的物理加速器 ID。读响应的目的加速器 ID。该字段应包含引发此读响应的请求的 ReqSrcPhysAccID 值（原请求的源加速器是读响应的目的加速器）。该字段用于将读响应路由回最初发出请求的加速器。 |
| RdRspTag | 11 | 完成方 | 读响应事务标签。该字段包含来自初始请求的 ReqTag 字段的值。 |
| RdRspNumBeats | 2 | 完成方 | 读响应数据节拍数。指示此读响应的节拍数。传输的节拍数为 (RdRspNumBeats+1)。该信号旨在使交换机更容易将多个节拍聚合为更大的实体进行路由，并使交换机无需计算所传输的节拍数。交换机应依赖该字段来确定读响应传输的节拍数。 |
| RdRspData | 512 | 完成方 | 读响应数据。如果读成功，该字段携带所请求的数据。所请求数据的传输可能需要多个数据节拍。 |
| RdRspStatus | 4 | 完成方 | 读响应状态。该字段指示读请求的状态。RdRspStatus 在一个响应的所有节拍中必须相同。 |
| RdRspOffset | 2 | 完成方 | 读响应偏移。指示当前数据节拍的索引。要返回给发起方的数据由完成方在 RdRspData 字段中以一到多个数据节拍传输。按照数据在内存中的顺序，每个节拍从 0 开始依次编号，到 n-1 结束；n 是传输待返回数据所需的总节拍数。当传输需要多个节拍且传输处于多节拍模式（Multi-Beat Mode）时，完成方必须从 RdRspOffset 0 开始并按节拍顺序继续。在单节拍模式下，各节拍可以以任意顺序到达。该字段提供本传输周期所呈递节拍的编号。 |
| RdRspLast | 1 | 完成方 | 读响应最后一拍。该信号随一次数据传输的最后一个响应数据节拍一起置位。 |
| RdRspDataError | 1 | 完成方 | 读响应数据错误。该字段与 RdRspData 以相同时序发送，指示该节拍的状态（出错------即"被污染"（poisoned）------与否）。当 RdRspVld 未置位时，应忽略该字段。与 RdRspStatus 不同，该字段在不同节拍中可以取不同值，且该字段不应用于指示除数据或字节使能字段奇偶校验问题之外的错误。例如，对于 RdRspStatus 为 DECODE_ERROR 的数据响应节拍，应提供固定数据模式（如全 0xF）的节拍，且这些节拍的 RdRspDataError=0，除非在传输过程中发生了奇偶校验错误。DECODE ERROR 仅由 RdRspStatus 字段指示。 |
| RdRspVC | 2 | 完成方 | 读响应虚拟通道。指定读响应的虚拟通道。与原始请求的虚拟通道（ReqVC）匹配。在 UALink 1.0 中，该字段对交换机而言仅是信息性的，但该值会在信用返还信号中回送给发送方。交换机只有一个虚拟通道，并将该字段原样传递给源加速器。 |
| RdRspPool | 1 | 完成方 | 读响应 Pool。指定读响应是使用 Pool 信用（RdRspPool=1）还是虚拟通道信用（RdRspPool=0）发出的。 |
读响应/数据通道信用返还信号------这些信号不进行时分复用。任何端口的信用都可以在任何周期返还。
| 名称 | 位宽 | 驱动方 | 描述 |
|---|---|---|---|
| RdRspCreditInitDone | 4 | 发起方 | 读响应信用初始化完成。置位时向完成方指示，与该单个信号相关联端口的初始信用释放已完成（RdRspCreditInitDone2 表示端口 2 已完成）。各个"done"信号可以独立置位，一旦置位将保持置位，直到接口复位或断电。 |
| RdRspCreditVld | 4 | 发起方 | 读响应信用有效。指示正在向完成方释放一个或多个信用。信用按端口划分，一个 Station 可以有 1、2 或 4 个端口。RdRspCreditVldn 对应端口 n。信用可以在多个端口上同时释放。 |
| RdRspCreditPool | 4 | 发起方 | 读响应信用 Pool。指示所释放信用对应的读响应（即消耗了该 Pool 或虚拟通道信用的读响应）在 RdRspPool 上所指示的信用类型。为"0"时，所释放的是虚拟通道信用；为"1"时，所释放的是 Pool 信用。与返还信用对应的读响应的 RdRspVC 值被放置在相应的 RdRspCreditPort0,1,2,3VC 信号上。 |
| RdRspCreditPort0VC | 2 | 发起方 | 读响应信用端口 0 虚拟通道。指示消耗了正在为端口 0 释放的信用的读响应在 RdRspVC 上所指示的虚拟通道。当 RdRspCreditVld0 置位时有效。 |
| RdRspCreditPort1VC | 2 | 发起方 | 读响应信用端口 1 虚拟通道。含义同上，对应端口 1。当 RdRspCreditVld1 置位时有效。 |
| RdRspCreditPort2VC | 2 | 发起方 | 读响应信用端口 2 虚拟通道。含义同上，对应端口 2。当 RdRspCreditVld2 置位时有效。 |
| RdRspCreditPort3VC | 2 | 发起方 | 读响应信用端口 3 虚拟通道。含义同上，对应端口 3。当 RdRspCreditVld3 置位时有效。 |
| RdRspCreditPort0Num | 2 | 发起方 | 读响应信用端口 0 信用数。指示为端口 0 返还的信用数（最多 4 个，RdRspCreditPort0Num+1）。仅当 RdRspCreditVld0 置位时有效。 |
| RdRspCreditPort1Num | 2 | 发起方 | 读响应信用端口 1 信用数。对应端口 1。仅当 RdRspCreditVld1 置位时有效。 |
| RdRspCreditPort2Num | 2 | 发起方 | 读响应信用端口 2 信用数。对应端口 2。仅当 RdRspCreditVld2 置位时有效。 |
| RdRspCreditPort3Num | 2 | 发起方 | 读响应信用端口 3 信用数。对应端口 3。仅当 RdRspCreditVld3 置位时有效。 |
读响应/数据通道奇偶校验信号
| 名称 | 位宽 | 驱动方 | 描述 |
|---|---|---|---|
| RdRspVldParity | 1 | 完成方 | 读响应有效奇偶校验。对 RdRspVld 的偶校验。每个周期都检查。 |
| RdRspDataParity | 8 | 完成方 | 读响应数据奇偶校验。RdRspDataParity 中的每一位为 RdRspData 字段的 64 位提供基于偶校验的错误保护。RdRspDataParityi 与 RdRspData((i+1)*64-1):(i*64) 中置位位的总数恒为偶数。完成方必须提供偶校验，包括因命令的长度或地址而屏蔽了读数据的情况，以及 RdRspDataError 置位的节拍。仅在 RdRspVld 置位时检查。该字段与 RdRspData 以相同时序发送。 |
| RdRspParity | 1 | 完成方 | 读响应奇偶校验。RdRspParity 对 RdRspTag、RdRspStatus、RdRspOffset、RdRspLast、RdRspNumBeats、RdRspVC、RdRspSrcPhysAccID、RdRspDstPhysAccID、RdRspPortID、RdRspDataError 提供偶校验。仅在 RdRspVld 置位时检查。 |
| RdRspCreditVldParity | 1 | 发起方 | 读响应信用有效奇偶校验。对 RdRspCreditVld 的偶校验。每个周期都检查。 |
| RdRspCreditParity | 1 | 发起方 | 读响应信用奇偶校验。对 RdRspCreditPort0VC、RdRspCreditPort1VC、RdRspCreditPort2VC、RdRspCreditPort3VC、RdRspCreditPort0Num、RdRspCreditPort1Num、RdRspCreditPort2Num、RdRspCreditPort3Num 和 RdRspCreditPool 的偶校验。在 RdRspCreditVld 非零的节拍中检查。 |
2.7.5.1 RdRspStatus
四位 RdRspStatus 字段应提供读响应的成功/失败指示。RdRspStatus3:0 字段的编码应如表 2-9 和表 2-10 所示。交换机应将 RdRspStatus 递送给请求的初始 UPLI 发起方。
表 2-9 预定义命令的 RdRspStatus3:0 编码
| RdRspStatus3:0 | 响应 | 说明 |
|---|---|---|
| 0000b | OKAY（正常完成） | 事务正常完成。 |
| 0001b | 保留 | |
| 0010b | TARGET ABORT | 表示事务的最终目标在处理事务时发生错误，或因其他原因无法完成事务。 |
| 0011b | DECODE ERROR | 地址译码错误。 |
| 0100b-0101b | 保留 | |
| 0110b | PROTECTION VIOLATION | 保护违例。表示某些安全或保护检查导致事务被中止。此类错误通常是持久性的。 |
| 0111b | 保留 | |
| 1000b | CMPTO（完成超时） | 目的加速器中的完成方无法完成请求并发生超时。 |
| 1001b-1111b | 保留 | |
 |
表 2-10 厂商自定义命令的 RdRspStatus3:0 编码
| RdRspStatus3:0 | 响应 | 说明 |
|---|---|---|
| 0000b | OKAY（正常完成） | 事务正常完成。 |
| 0001b-1111b | 厂商定义 |
如果 RdRspStatus 指示错误（TARGET ABORT、DECODE ERROR、PROTECTION VIOLATION、CMPTO），完成方应传输所有被请求的数据节拍，包括置位 RdRspLast；如果因错误而没有可用数据，则使用人造数据（Manufactured Data）。推荐的人造数据模式为全 1（0xFF）。
如果某个读响应的数据本来会被缓存到加速器中的某个缓存里，那么对于 RdRspStatus 指示错误的读响应，应阻止这种缓存。发起方不应缓存所返回的数据。一般而言，任何以指示错误的 RdRspStatus 完成的事务，都不应改变作为该响应对应请求之源加速器的加速器中所请求缓存行的缓存状态。
对于使用读响应、但 ReqAddr 字段被定义为保留或用于传送非地址信息的 UPLI 写消息请求，DECODE ERROR 和 PROTECTION VIOLATION 这两个响应状态值不是合法的。
2.7.5.2 RdRspDataError
RdRspDataError（读响应数据错误）信号是一种数据"污染"指示，应在任何检测到 RdRsp 数据节拍上奇偶校验错误的 UALink 协议级接口（在交换机上或加速器上）置位，或由交换机核心按照交换机软错误检测机制检测到读响应数据（仅数据，不含控制信号）错误时置位。该信号根据每个节拍自身的错误状态，按节拍单独置位。
2.7.5.3 RdRspOffset
RdRspOffset（读响应偏移）用于指示当前节拍在 RdRspData 字段中返回给发起方的读数据中的位置。响应所需的每个节拍应按地址升序从 0 开始依次编号到 3，或按厂商自定义命令的定义编号。
对于非厂商自定义命令，节拍 0（RdRspOffset=0）应始终包含所请求数据载荷的初始（最低地址）字节。节拍 1-3（如存在）应按地址升序提供数据。对于厂商自定义命令，数据节拍的顺序由厂商定义。
2.7.6 写响应通道
写响应通道应向写请求的初始发起方提供反馈，指示请求在最终完成方处的结果与完成情况。响应基于请求的请求标签与请求相匹配。表 2-11 列出了构成写响应通道的信号。
标有 Driver 的列指示该信号由发起方还是完成方驱动。
表 2-11 写响应通道信号
写响应通道信息与控制信号------这些信号按 WrRspPortID 值进行时分复用（TDM）。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| WrRspVld | 1 | 完成方 | 写响应有效。指示完成方正在此通道上呈递有效信息（一个节拍）。 |
| WrRspPortID | 2 | 完成方 | 写响应端口 ID。当完成方将写响应通道驱动到某个 TL 时，指示该写响应通道节拍要呈递到与该 TL 相关联的哪个端口。对所有完成方而言，WrRspPortID 指示写响应通道的 TDM 周期。 |
| WrRspAuthTag | 64 | 完成方 | 写响应认证标签。如果 WrRspStatus 指示的值不是 ISOLATE，该字段应包含写响应的认证标签。详见"安全"一章中关于该信号与认证的说明。当响应未启用认证或 WrRspVld 撤销时，该字段驱动为零。如果 WrRspStatus 字段指示 ISOLATE，该字段为无关项（don't care），应被完成方忽略，且不应产生认证失败。 |
| WrRspSrcPhysAccID | 10 | 完成方 | 写响应源物理加速器 ID。写响应的源加速器 ID。如果 WrRspStatus 指示的值不是 ISOLATE，该字段应包含引发此写响应的请求的 ReqDstPhysAccID 值（原请求的目的加速器是写响应的源加速器）。该信息不是功能所必需的，但有助于调试（写响应使用 WrRspDstPhysAccID 路由）。此字段携带正确值是可选的（即 UALink TL 或 UALink DL 可以将此字段压缩掉）。当该字段不含准确值时，应将其驱动为零。由于该字段可能不准确，因此不得将其用于功能性目的。如果 WrRspStatus 字段指示 ISOLATE，该字段为无关项，应被完成方忽略。 |
| WrRspDstPhysAccID | 10 | 完成方 | 写响应目的物理加速器 ID。写响应的目的加速器 ID。如果 WrRspStatus 指示的值不是 ISOLATE，该字段应包含引发此写响应的请求的 ReqSrcPhysAccID 值（原请求的源加速器是写响应的目的加速器）。该字段用于将写响应路由回最初发出请求的加速器。如果 WrRspStatus 字段指示 ISOLATE，该字段为无关项，应被完成方忽略。 |
| WrRspTag | 11 | 完成方 | 写响应事务标签。如果 WrRspStatus 指示的值不是 ISOLATE，该字段应包含引发此写响应的请求的 ReqTag 字段值。如果 WrRspStatus 字段指示 ISOLATE，该字段为无关项，应被完成方忽略。 |
| WrRspStatus | 4 | 完成方 | 写响应状态。该字段应指示写请求的状态。 |
| WrRspVC | 2 | 完成方 | 写响应虚拟通道。如果 WrRspStatus 指示的值不是 ISOLATE，该字段应指定写响应的虚拟通道。该信号应与原始请求的虚拟通道（ReqVC）匹配。在 UALink 1.0 中，该字段对交换机而言仅是信息性的，但该值会在信用返还信号中回送给发送方。交换机只有一个虚拟通道，并将该字段原样传递给源加速器。如果 WrRspStatus 字段指示 ISOLATE，则当 WrRspPool=0 时，该字段应指示用于发出该命令的虚拟通道信用。 |
| WrRspPool | 1 | 完成方 | 写响应 Pool。指定写响应是使用 Pool 信用（WrRspPool=1）还是虚拟通道信用（WrRspPool=0）发出的。 |
写响应通道信用返还信号------这些信号不进行时分复用。任何端口的信用都可以在任何周期返还。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| WrRspCreditInitDone | 4 | 发起方 | 写响应信用初始化完成。置位时向完成方指示，与该单个信号相关联端口的初始信用释放已完成（WrRspCreditInitDone2 表示端口 2 已完成）。各个"done"信号可以独立置位，一旦置位将保持置位，直到接口复位或断电。 |
| WrRspCreditVld | 4 | 发起方 | 写响应信用有效。指示正在向完成方释放一个或多个信用。信用按端口划分，一个 Station 可以有 1、2 或 4 个端口。WrRspCreditVldn 对应端口 n。信用可以在多个端口上同时释放。 |
| WrRspCreditPool | 4 | 发起方 | 写响应信用 Pool。指示所释放信用对应的写响应在 WrRspPool 上所指示的信用类型。为"0"时，所释放的是虚拟通道信用；为"1"时，所释放的是 Pool 信用。与返还信用对应的写响应的 WrRspVC 值被放置在相应的 WrRspCreditPort0,1,2,3VC 信号上。 |
| WrRspCreditPort0VC | 2 | 发起方 | 写响应信用端口 0 虚拟通道。指示消耗了正在为端口 0 释放的信用的写响应在 WrRspVC 上所指示的虚拟通道。当 WrRspCreditVld0 置位时有效。 |
| WrRspCreditPort1VC | 2 | 发起方 | 写响应信用端口 1 虚拟通道。含义同上，对应端口 1。当 WrRspCreditVld1 置位时有效。 |
| WrRspCreditPort2VC | 2 | 发起方 | 写响应信用端口 2 虚拟通道。含义同上，对应端口 2。当 WrRspCreditVld2 置位时有效。 |
| WrRspCreditPort3VC | 2 | 发起方 | 写响应信用端口 3 虚拟通道。含义同上，对应端口 3。当 WrRspCreditVld3 置位时有效。 |
| WrRspCreditPort0Num | 2 | 发起方 | 写响应信用端口 0 信用数。指示为端口 0 返还的信用数（最多 4 个，WrRspCreditPort0Num+1）。仅当 WrRspCreditVld0 置位时有效。 |
| WrRspCreditPort1Num | 2 | 发起方 | 写响应信用端口 1 信用数。对应端口 1。仅当 WrRspCreditVld1 置位时有效。 |
| WrRspCreditPort2Num | 2 | 发起方 | 写响应信用端口 2 信用数。对应端口 2。仅当 WrRspCreditVld2 置位时有效。 |
| WrRspCreditPort3Num | 2 | 发起方 | 写响应信用端口 3 信用数。对应端口 3。仅当 WrRspCreditVld3 置位时有效。 |
写响应通道奇偶校验信号
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| WrRspVldParity | 1 | 完成方 | 写响应有效奇偶校验。对 WrRspVld 的偶校验。每个周期都检查。 |
| WrRspParity | 1 | 完成方 | 写响应奇偶校验。WrRspParity 对 WrRspTag、WrRspStatus、WrRspSrcPhysAccID、WrRspDstPhysAccID、WrRspPortID、WrRspVC 提供偶校验。仅在 WrRspVld 置位时检查。 |
| WrRspCreditVldParity | 1 | 发起方 | 写响应信用有效奇偶校验。对 WrRspCreditVld 的偶校验。每个周期都检查。 |
| WrRspCreditParity | 1 | 发起方 | 写响应信用奇偶校验。对 WrRspCreditPort0VC、WrRspCreditPort1VC、WrRspCreditPort2VC、WrRspCreditPort3VC、WrRspCreditPort0Num、WrRspCreditPort1Num、WrRspCreditPort2Num、WrRspCreditPort3Num 和 WrRspCreditPool 的偶校验。在 WrRspCreditVld 非零的节拍中检查。 |
2.7.6.1 WrRspStatus
表 2-12 预定义命令的 WrRspStatus3:0 编码
| WrRspStatus3:0 | 响应 | 说明 |
|---|---|---|
| 0000b | OKAY（正常完成） | 事务正常完成。 |
| 0001b | 保留 | |
| 0010b | TARGET ABORT | 表示事务的最终目标在处理事务时发生错误，或因其他原因无法完成事务。 |
| 0011b | DECODE ERROR | 地址译码错误。 |
| 0100b-0101b | 保留 | |
| 0110b | PROTECTION VIOLATION | 保护违例。表示某些安全或保护检查导致事务被中止。此类错误通常是持久性的。 |
| 0111b | 保留 | |
| 1000b | CMPTO（完成超时） | 目的加速器中的完成方无法完成请求并发生超时。 |
| 1001b-1110b | 保留 | |
| 1111b | ISOLATE | 从 UALink TL 发往加速器 UPLI 发起方的写响应，用于将该 UPLI 发起方置于隔离模式（Isolation Mode）。仅对加速器上 UALink TL 到 UPLI 完成方的写响应通道有效。 |
 |
表 2-13 厂商自定义命令的 WrRspStatus3:0 编码
| WrRspStatus3:0 | 响应 | 说明 |
|---|---|---|
| 0000b | OKAY（正常完成） | 事务正常完成。 |
| 0001b-1110b | 厂商定义 | |
| 1111b | 保留 | 厂商自定义命令不应使用此 WrRspStatus 编码。此编码仅用于 ISOLATE 响应，而 ISOLATE 不是厂商自定义命令的合法状态响应。 |
2.7.7 发起方数据通道
发起方数据通道应用于传输：写请求的写数据、厂商自定义写类命令的写数据、原子请求的操作数数据、厂商自定义原子类命令的操作数数据、UPLI 写消息请求的消息数据，以及厂商自定义 UPLI 写请求的消息数据。
标有 Driver 的列指示该信号由发起方还是完成方驱动。
表 2-14 发起方数据通道信号
发起方数据通道信息与控制信号------这些信号按 OrigDataPortID 值进行时分复用（TDM）。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| OrigDataVld | 1 | 发起方 | 发起方数据有效。指示发起方正在此通道上呈递有效信息（一个数据节拍）。 |
| OrigDataPortID | 2 | 发起方 | 发起方数据端口 ID。当发起方将发起方数据通道驱动到某个 TL 时，指示该发起方数据通道节拍要呈递到与该 TL 相关联的哪个端口。对所有发起方而言，OrigDataPortID 指示发起方数据通道的 TDM 周期。 |
| OrigData | 512 | 发起方 | 发起方数据。该字段包含写、厂商自定义写类命令、UPLI 写消息请求和厂商自定义 UPLI 写消息请求的数据，也包含原子和厂商自定义原子类命令的操作数数据。 |
| OrigDataByteEn | 64（每字节一位） | 发起方 | 发起方数据字节使能。OrigData 字段每 8 位对应一个 OrigDataByteEn 位。这些信号指示 OrigData 的哪些字节通道持有有效信息。 |
| OrigDataOffset | 2 | 发起方 | 发起方数据偏移。指示当前数据节拍的索引。要写入的数据由发起方在 OrigData 字段中以一到多个节拍传输。按照数据在内存中的顺序，每个节拍从 0 开始依次编号，到 n-1 结束；n 是传输待写入数据所需的总节拍数。当传输需要多个节拍时，发起方应从节拍 0 开始并按节拍顺序继续。该字段指示本传输周期所呈递节拍的编号。 |
| OrigDataLast | 1 | 发起方 | 发起方数据最后一拍。该信号随发起方数据传输的最后一个数据节拍一起置位。 |
| OrigDataError | 1 | 发起方 | 发起方数据错误。置位时指示当前数据节拍包含数据错误。 |
| OrigDataVC | 2 | 发起方 | 发起方数据虚拟通道。指定发起方数据节拍的虚拟通道。与原始请求的虚拟通道（ReqVC）匹配。在 UALink 1.0 中，该字段对交换机而言仅是信息性的，但该值会在信用返还信号中回送给发送方。交换机只有一个虚拟通道，并将该字段原样传递给目的加速器。 |
| OrigDataPool | 1 | 发起方 | 发起方数据 Pool。指定发起方数据节拍是使用 Pool 信用（OrigDataPool=1）还是虚拟通道信用（OrigDataPool=0）发出的。 |
发起方数据通道信用返还信号------这些信号不进行时分复用。任何端口的信用都可以在任何周期返还。
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| OrigDataCreditInitDone | 4 | 完成方 | 发起方数据信用初始化完成。置位时向发起方指示，与该单个信号相关联端口的初始信用释放已完成（OrigDataCreditInitDone2 表示端口 2 已完成）。各个"done"信号可以独立置位，一旦置位将保持置位，直到接口复位或断电。 |
| OrigDataCreditVld | 4 | 完成方 | 发起方数据信用有效。指示正在向发起方释放一个或多个信用。信用按端口划分，一个 Station 可以有 1、2 或 4 个端口。OrigDataCreditVldn 对应端口 n。信用可以在多个端口上同时释放。 |
| OrigDataCreditPool | 4 | 完成方 | 指示所释放信用对应的发起方数据节拍在 OrigDataPool 上所指示的信用类型。为"0"时，所释放的是虚拟通道信用；为"1"时，所释放的是 Pool 信用。与返还信用对应的发起方数据节拍的 OrigDataVC 值被放置在相应的 OrigDataCreditPort0,1,2,3VC 信号上。 |
| OrigDataCreditPort0VC | 2 | 完成方 | 发起方数据信用端口 0 虚拟通道。指示消耗了正在为端口 0 释放的信用的发起方数据节拍在 OrigDataVC 上所指示的虚拟通道。当 OrigDataCreditVld0 置位时有效。 |
| OrigDataCreditPort1VC | 2 | 完成方 | 发起方数据信用端口 1 虚拟通道。含义同上，对应端口 1。当 OrigDataCreditVld1 置位时有效。 |
| OrigDataCreditPort2VC | 2 | 完成方 | 发起方数据信用端口 2 虚拟通道。含义同上，对应端口 2。当 OrigDataCreditVld2 置位时有效。 |
| OrigDataCreditPort3VC | 2 | 完成方 | 发起方数据信用端口 3 虚拟通道。含义同上，对应端口 3。当 OrigDataCreditVld3 置位时有效。 |
| OrigDataCreditPort0Num | 2 | 完成方 | 发起方数据信用端口 0 信用数。指示为端口 0 返还的信用数（最多 4 个，OrigDataCreditPort0Num+1）。仅当 OrigDataCreditVld0 置位时有效。 |
| OrigDataCreditPort1Num | 2 | 完成方 | 发起方数据信用端口 1 信用数。对应端口 1。仅当 OrigDataCreditVld1 置位时有效。 |
| OrigDataCreditPort2Num | 2 | 完成方 | 发起方数据信用端口 2 信用数。对应端口 2。仅当 OrigDataCreditVld2 置位时有效。 |
| OrigDataCreditPort3Num | 2 | 完成方 | 发起方数据信用端口 3 信用数。对应端口 3。仅当 OrigDataCreditVld3 置位时有效。 |
发起方数据通道奇偶校验信号
| 名称 | 位宽（bit） | 驱动方 | 描述 |
|---|---|---|---|
| OrigDataVldParity | 1 | 发起方 | 发起方数据有效奇偶校验。对 OrigDataVld 的偶校验。每个周期都检查。 |
| OrigDataParity | 8 | 发起方 | 发起方数据奇偶校验。OrigDataParity 中的每一位为 OrigData 字段的 64 位提供基于偶校验的错误保护。OrigDataParityi 与 OrigData((i+1)*64-1):(i*64) 中置位位的总数恒为偶数，包括 OrigDataByteEn 屏蔽了该奇偶校验组中部分或全部字节的数据字节。仅在 OrigDataVld 置位时检查。 |
| OrigDataByteEnParity | 1 | 发起方 | 发起方数据字节使能奇偶校验。对 OrigDataByteEn 的偶校验。仅在 OrigDataVld 置位时检查。 |
| OrigDataFieldsParity | 1 | 发起方 | 发起方数据字段奇偶校验。OrigDataFieldsParity 对 OrigDataLast、OrigDataError、OrigDataOffset、OrigDataPortID、OrigDataVC 提供偶校验。仅在 OrigDataVld 置位时检查。 |
| OrigDataCreditVldParity | 1 | 完成方 | 发起方数据信用有效奇偶校验。对 OrigDataCreditVld 的偶校验。每个周期都检查。 |
| OrigDataCreditParity | 1 | 完成方 | 发起方数据信用奇偶校验。对 OrigDataCreditPort0VC、OrigDataCreditPort1VC、OrigDataCreditPort2VC、OrigDataCreditPort3VC、OrigDataCreditPort0Num、OrigDataCreditPort1Num、OrigDataCreditPort2Num、OrigDataCreditPort3Num 和 OrigDataCreditPool 的偶校验。在 OrigDataCreditVld 非零的节拍中检查。 |
2.7.7.1 OrigDataError
OrigDataError（发起方数据错误）信号是一种数据"污染"指示，应在任何检测到发起方数据上奇偶校验错误的 UALink 协议级接口置位，或由交换机按照交换机软错误检测机制检测到数据（仅数据，不含包括字节使能在内的控制信号）错误时置位。
2.7.8 UPLI 通道之间的关系及通道内部的要求
各通道类型之间以及通道内部应存在以下依赖关系与规则：
- 在完成 UALink 协议级接口控制握手之前，UPLI 发起方或 UPLI 完成方不应在任何通道上传输任何信息，包括信用或请求/响应/数据节拍。
- 在没有获得对端代理发出信号的足够信用之前，UPLI 发起方或 UPLI 完成方不应发出请求节拍、读响应/数据节拍、写响应节拍或发起方数据节拍。
- UPLI 通道的发送方应能够无条件地接收该通道返还的信用。
- 一个请求的第一拍发起方数据（无论是原子操作、写操作、WriteFull 还是 UPLI 写消息）应与该请求在请求通道上发出的周期相同（即对所有写和原子请求，ReqVld 与 OrigDataVld 应在同一周期置位）。
- 任何给定写、WriteFull 或原子请求的所有发起方数据节拍，都应作为连续的数据节拍序列出现，应按地址升序排列（即 OrigDataOffset 从 0 开始，对发起方数据传输中最多四个节拍逐拍递增），且发起方数据传输的最后一拍应通过置位 OrigDataLast 来指示。这条规则的一个推论是：发起方必须在发出写或原子请求之前，获得足以发出该写或原子请求的请求通道信用和发起方数据通道信用（例如，一个 256 字节的写需要一个请求通道信用和四个发起方数据通道信用）。
- 前两条规则的推论是：写事务和原子事务不得在请求通道与发起方数据通道上流水化（即当发起方发出一个写或原子请求时，必须先发出该请求的全部发起方数据节拍，然后才能发出任何后续的写或原子请求）。
- 读请求可以在发起方数据通道上存在先前写或原子请求的发起方数据节拍的周期中发出（即读请求可以流水化地叠加在写和原子请求的发起方数据节拍之上）。
- 为避免死锁，加速器上的发起方一旦发出了请求，就应能够处理（或"吸收"）与该请求相关联的响应节拍，而不以完成方处理任何其他事务为条件。
- 读响应可以采取两种不同的形式，每个事务的读响应可以自由选择：
- 多节拍模式（Multi-Beat mode）：在此模式下，与 OrigData 传输类似，读响应/数据节拍应作为连续的一组节拍出现，按地址升序排列（即 RdRspOffset 从初始值 0 开始，对传输中最多四个节拍逐拍递增），最后一个读响应/数据节拍应通过置位 RdRspLast 来指示。此外，RdRspNumBeats 字段应指示传输涉及的节拍数减 1，且对所有节拍相同（即 RdRspNumBeats=0 表示一拍，RdRspNumBeats=3 表示四拍）。
- 单节拍模式（Single Beat mode）：在此模式下，读响应/数据节拍应作为独立的读响应/数据节拍返回。这些独立节拍可以以任意地址顺序出现，但应包含传输大小所需的全部值。各个响应之间可以有任意间隔，也可以与不相关的数据节拍交织。最后一个要传输的读响应/数据节拍应通过置位 RdRspLast 来指示。交换机应保持来自同一入口端口到出口端口的所有单节拍读响应之间的顺序，并应原样传递 RdRspLast 而不做修改。对于单节拍模式下给定标签的所有节拍，RdRspNumBeats 应等于 0（1 拍传输）。
- 对于只请求一拍数据的读事务，其读响应/数据响应在两种模式下于 UALink 协议级接口上的表现是相同的。
- 交换机不应尝试"聚合"单节拍模式传输的各个节拍，而是应逐个立即转发每个节拍。
- 写响应节拍和读响应/数据节拍在返回发起方的过程中不应被阻塞。
2.7.9 UPLI 请求、读响应与写响应的排序
UPLI 请求的排序，针对每个源/目的加速器对独立定义：即在给定源加速器上的初始 UPLI 接口发出的、发往目的加速器上最终 UPLI 接口的请求集合上进行定义。
UPLI 响应的排序，针对读响应与写响应分别独立定义，并针对每个目的/源加速器对独立定义：即从给定目的加速器上的最终 UPLI 接口发出的、发往给定源加速器上初始 UPLI 接口的响应集合上进行定义。
如果某个厂商自定义命令或厂商自定义 UPLI 写消息请求需要一个地址，并且其语义要求该厂商自定义请求与其他带地址的请求保持排序，则应使用 ReqAddr 字段以与其他带地址的非厂商自定义请求相同的方式指定该地址。
所有请求，无论是否带地址，都应基于 ReqAddr 信号值进行排序，就如同该信号包含一个内存地址一样。
所有带地址的请求（带地址的非厂商自定义请求，以及将 ReqAddr 字段定义为地址、且语义要求与其他带地址请求排序的厂商自定义请求），只要其地址落在给定 256 字节内存区域内，都应从加速器上的同一端口发出。
在下文中，术语"严格排序模式（Strict Ordering Mode）"定义为：认证与加密均已启用，或仅启用加密。
当不处于严格排序模式时，在源加速器初始 UPLI 接口上为给定虚拟通道发出的、落在每个 256 字节对齐内存区域内的所有请求，应以相同的顺序出现在目的加速器的最终 UPLI 接口上（即保持有序）。各实现也可以选择在不处于严格排序模式时保持所有请求有序。
在严格排序模式下，在源加速器初始 UPLI 接口上发出的所有请求都应保持有序。
初始发起方在源加速器上发出请求的顺序，以及这些请求在目的加速器上通过最终完成方之后的处理方式，属于加速器各自的实现特性，不由 UALink 规范规定。然而，如果加速器希望维持一致性------即对给定内存位置的所有写都以所有参与者一致同意的某种顺序串行化------则加速器至少需要将访问重叠内存位置的那些请求排序。
当不处于严格排序模式时，读响应相互之间没有排序要求，因此它们在源加速器初始 UPLI 接口上出现的顺序可以与目的加速器在最终 UPLI 接口上发出它们的顺序不同（即可以自由重排）。写响应相互之间也没有排序要求，同样可以自由重排。不处于严格排序模式时，读响应与写响应之间没有排序要求。
在严格排序模式下，读响应相互之间应保持有序，写响应相互之间也应保持有序。严格排序模式下，读响应与写响应之间没有排序要求。
初始 UPLI 接口上的 UPLI 发起方，可以在发往同一 256 字节区域的先前请求的响应尚未返回之前，就向给定的 256 字节对齐内存区域发出多个读、写、WriteFull 或原子请求。
即使通过其他途径已知来自不同加速器的请求是按某种顺序发起的，也不保证这些请求之间的顺序。
2.7.10 UPLI 请求单副本原子性
如果一个 UPLI 访问总是作为一个整体执行（即对写而言内存位置被更新，对读而言要返回的值被绑定），没有可见的分割，则该访问是单副本原子（Single-Copy atomic）的。
也就是说，如果给定的一组位置只被单副本原子的读、单副本原子的写或单副本原子的原子操作访问，且每个操作都访问该集合中的全部位置，那么给定读（或原子操作的读部分）所观察到的值，将恰好是某一个写（或某一个原子操作的写部分）所写入的值，而绝不会是多个写或原子操作（或两者）所写入值的组合。
如果一个操作未被声明为单副本原子的，则它可以被分解为一组更小的、互不相交的单副本原子操作来执行，这些操作的大小可以不同。例如，一个 64 字节的写可以被分解为八个 8 字节单副本原子写操作，以某种任意顺序执行。又例如，一个 64 字节的读可以被分解为四个 8 字节单副本原子读操作和八个 4 字节单副本原子读操作，以某种任意顺序执行。
任何未被声明为单副本原子的给定读、写或原子操作，既可以以单副本原子的方式执行，也可以被分解（即对非单副本原子操作而言，分解不是强制的，只是被允许的）。
一个非单副本原子的原子操作，只能被分解为大小为该原子操作元素大小整数倍的若干操作。
虽然一个非单副本原子操作可以被分解为一组更小的、互不相交的单副本原子访问，但如果两个非单副本原子操作因某种原因而有序（例如由于处于同一 256 字节内存区域），则第一个非单副本原子操作的所有组成分解操作，都应在该非单副本原子操作的响应返回之前执行完毕。
虽然 UPLI 与 TL 接口被要求将 UPLI 操作从源加速器完整地递送到目的加速器而不做任何分解，但任意给定 UPLI 操作的单副本原子性，以及当操作不是单副本原子时所施加的分解（如果有），都是目的加速器各自的实现特性，不由 UALink 规范规定。
2.8 数据/原子操作数传输
UALink 协议级接口有一个从发起方到完成方的发起方数据通道。发起方数据通道用于向完成方传输写数据或原子操作数数据。UALink 协议级接口还有一个读响应/数据通道，用于将读数据或原子读数据（对 AtomicR 请求）从完成方传输到发起方。
读（Reads）
读请求所传输的数据，由字节可寻址系统内存地址空间中一个或多个对齐双字组成的连续块构成。该块的起始地址（第一个双字最低有效字节的地址）等于读请求的 ReqAddr 字段。由于地址是双字对齐的，ReqAddr1:0 恒为 2'b00。
ReqLen 字段指定要传输的双字数减一（例如 ReqLen=0 表示传输 1 个双字，为最小值；ReqLen=63 表示传输 64 个双字，为最大值）。读请求的最大大小为 256 字节（64 个双字），且读请求不得跨越 256 字节边界。
数据在读响应/数据通道上通过 64 字节的 RdRspData 字段传输。RdRspData 字段内的字节通道编号为 0 到 63，字节通道 0 对应低地址。在 RdRspData 字段上传输的数据字节被放置在 64 字节 RdRspData 字段内其自然对齐的字节通道上（例如，地址 X 处的字节总是放置在字节通道 X mod 64------例如地址 0 放置在字节通道 0，地址 129 放置在字节通道 1）。
跨过一个或多个 64 字节边界的传输使用多个 64 字节读响应节拍。例如，地址 60 处的一个 8 字节读由两个节拍组成：一个在高序字节通道 60-63 上传输地址 60-63，一个在低序字节通道 0-3 上传输地址 64-67。这种多节拍数据响应中的每个节拍恰好传输一次。多节拍模式下各节拍按地址从低到高排序；单节拍模式下各节拍可以以任意顺序到达。节拍由 RdRspOffset 字段标记，取值 0、1、2 或 3，指示按地址升序的数据节拍编号（包含初始双字的节拍其 RdRspOffset 为 0）。
为支持小至单个字节的任意大小、任意对齐的读访问，读访问的第一个和最后一个双字的字节使能在 ReqAttr7:0 字段中提供。ReqAttr3:0 提供字节使能，指定第一个双字中被访问的字节（ReqAttr3 指定双字中高序字节的使能，ReqAttr0 指定双字中低序字节的使能）。对于两个或更多双字的访问，ReqAttr7:4 以同样方式指定最后一个双字中被访问的字节。对于单个双字的访问，ReqAttr7:4 被忽略。对于三个或更多双字的访问，除第一个和最后一个双字外，其余双字中的所有字节都假定被访问（即字节使能只针对第一个和最后一个双字提供）。
64 字节 RdRspData 字段中被 ReqAttr7:0 屏蔽、或落在 ReqAddr/ReqLen 所指定范围之外的字节无效，发起方应忽略它们；但这些字节仍参与数据奇偶校验计算。
下图展示了从地址 0 开始的 16 字节传输的节拍与字节通道分配：
图 2-12 不跨越 64 字节边界的四双字读请求
字节 0 至 15 在单个节拍中传输。ReqAttr 字节使能全为 1，以传输首尾节拍中的所有字节。
下图展示了另一个 16 字节传输，但从字节 56 开始：
图 2-13 跨越 64 字节边界的四双字读请求
与前一个传输不同，此传输跨过一个 64 字节边界，因此必须使用多个数据节拍传输。
下图展示了访问单个字节（字节 54）的情形：
图 2-14 单字节读
ReqAddr/ReqLen 字段指定单个双字（数据字段中地址 52 处的 DW13），ReqAttr3:0 选择要访问的字节（字节 54）。ReqAttr7:4 被忽略。
下图展示了一个六字节访问，需要同时使用 ReqAttr7:4 和 ReqAttr3:0：
图 2-15 不跨越 64 字节边界的六字节读访问
在双字传输中，ReqAttr7:0 的各位控制两个双字中哪些字节有效。
下图展示了另一个双字传输，但它跨过一个 64 字节边界：
图 2-16 跨越 64 字节边界的四字节读访问
由于该传输跨过一个 64 字节边界，传输被拆分为两个数据节拍。ReqAttr7:0 字段控制分布在两个节拍上的两个双字中哪些字节有效。
写（Writes）
写数据的传输发生在发起方数据通道中的 64 字节 OrigData 字段上。与 RdRspData 字段一样，OrigData 字段的字节通道从低地址到高地址编号为 0 到 63，一次写中任意给定数据字节都在与该字节地址对齐相匹配的 OrigData 字段字节通道上传输。ReqAddr/ReqLen 字段对写的定义与对读相同：地址是双字地址（ReqAddr1:0 为 2'b00），ReqLen 字段是要传输的双字数减一。与读一样，写最大为 256 字节，且不得跨越 256 字节边界。
与读一样，如果一个写跨过一个或多个 64 字节边界（但不是 256 字节边界），传输使用多个 64 字节节拍来传输数据，且每个节拍恰好传输一次。不允许写数据在一个节拍内"回绕"（wrapping）。写的第一拍（OrigDataVld 置位）必须与该写的请求（ReqVld）出现在同一周期，后续数据节拍（如有）必须以地址升序出现在连续周期中。写数据节拍由 OrigDataOffset 字段标记，取值 0、1、2 或 3，指示按地址升序的数据节拍编号（包含初始双字的节拍其 OrigDataOffset 为 0）。
写传输还有一个额外的 64 位字节使能字段------OrigDataByteEn------允许在一次写传输中对数据节拍内的各个字节分别选择写或不写。OrigDataByteEn0 信号指示字节通道 0 是否要被写入，OrigDataByteEn1 指示字节通道 1 是否要被写入，依此类推。对于 Write 命令（不是 WriteFull 命令），落在 ReqAddr/ReqLen 所指定区域之外的字节通道的字节使能必须设为 0。其余字节使能（落在 ReqAddr/ReqLen 所指定区域之内的）可以为"0"或"1"。这些其余的字节使能可以是稀疏的------即不要求字节使能必须连续置位，也不要求必须有任何字节使能被置位。
对于 WriteFull 命令，传输被限制为：从 64 字节边界开始、长度为 64 字节的整数倍、不跨越 256 字节边界。对于这些传输，各节拍中的所有字节使能都必须设为"1"。
下图展示了从地址 0 开始的 16 字节写的节拍与字节通道分配及 OrigDataByteEn 值：
图 2-17 不跨越 64 字节边界的四双字写请求
从 OrigDataByteEn0 开始的十六个置位的字节使能使前 16 个字节被写入。
下图展示了包含在单个节拍内的稀疏写：
图 2-18 不跨越 64 字节边界的十六双字写请求
各字节使能的开或关产生一个稀疏写。ReqAddr/ReqLen 使该写保持在单个节拍内。
下图展示了分布在两个节拍上的稀疏写：
图 2-19 跨越 64 字节边界的三双字写请求
各字节使能的开或关产生一个稀疏写。ReqAddr/ReqLen 使该写分布在两个节拍上。稀疏写最多可以分布在四个节拍上。这些图中未展示的情形是所有字节使能都未置位的情况：此时节拍仍在 OrigData 字段上传输，但不对内存做任何更新。
下图展示了向地址 0 的 128 字节 WriteFull：
图 2-20 128 字节 WriteFull 请求（需要两个节拍）
WriteFull 命令使 TL 和 PHY 层可以选择将字节使能压缩掉。但字节使能仍必须出现在 UALink 协议级接口上。
原子操作（Atomics）
发起方发出原子命令以执行 I/O 一致性的（在完成方处的）原子读-改-写操作。AtomicR 命令返回读-改-写操作中读出的值；AtomicNR 命令不返回数据。各种 AtomicR 或 AtomicNR 操作的语义由 ReqAttr 字段中的 OpType 子字段指明；原子操作所操作的内存元素（4 字节或 8 字节）的大小由 ReqAttr 字段中的 OpSize 子字段指定。给定 OpType 字段值的精确语义由实现决定，原子操作需要一个操作数（带一个"Op1"操作数的单操作数原子）还是两个操作数（带"Op1"和"Op2"操作数的双操作数原子）也由实现决定。
对所有原子操作，操作数数据通过 OrigData 总线传送给完成方。对于 AtomicR 原子操作，返回的数据和响应在读响应/数据通道上传送。对于 AtomicNR 命令，状态响应（不含任何数据）在写响应通道上传送。
对所有原子操作，内存中每个对齐的 64 字节区域被划分为：4 字节原子操作对应 16 个对齐的 4 字节元素，或 8 字节原子操作对应 8 个对齐的 8 字节元素。对于单操作数原子操作，ReqAddr 必须按所操作元素的大小（4 字节或 8 字节）对齐，ReqLen 必须指定为元素大小整数倍的长度，且请求不得跨越 64 字节边界（即所有单操作数原子操作都在单个数据节拍中传输其操作数数据）。OrigData 字段中每个元素中的操作数值用于对内存中相应位置执行原子读-改-写。类似地，AtomicR 请求为给定元素返回的数据被放置在 RdRspData 字段中相应的位置上。
64 字节内存区域中的每个 4 字节或 8 字节元素都可以通过置位或不置位该元素的所有字节使能来独立地更新或不更新。每个元素的所有字节使能必须全部设为"1"或全部设为"0"。不允许元素内部的部分字节使能。被更新的元素可以是稀疏的，即不要求被更新的元素连续，也不要求必须有任何元素被更新。对于 AtomicR 请求，被读元素的数据按其自然对齐位置在 RdRspData 字段中返回。对于字节使能未置位的元素，其返回的数据必须被发起方忽略，且完成方应将其驱动为全"0"或全"1"，以防止安全泄露。
下图展示了一个 8 字节单操作数原子操作的操作数与（如存在的）返回数据的字节通道分配。ReqAddr 相对地址"0"有偏移，操作作用于两个稀疏元素：
图 2-21 单操作数（8 字节操作数）原子操作
对于 AtomicR，数据元素按其自然对齐的字节通道返回。
下图展示了一个 4 字节单操作数原子操作的操作数与（如存在的）返回数据的字节通道分配。ReqAddr 位于地址"0"，操作作用于五个稀疏元素：
图 2-22 单操作数（4 字节操作数）原子操作
对于 AtomicR，数据元素按其自然对齐的字节通道返回。
双操作数原子操作的处理与单操作数原子操作不同。双操作数的 ReqLen 总是指定 64 字节传输（ReqLen=15），且 ReqAddr 必须按 32 字节边界对齐。双操作数原子操作更新位于 ReqAddr 所指定地址的 32 字节内存。然而，双操作数原子操作的操作数数据在一个数据节拍中传输，其中 Op1 操作数数据总是出现在 OrigData 字段的字节通道 0 至 31 上，Op2 操作数数据出现在 OrigData 字段的字节通道 32 至 63 上。Op1 和 Op2 操作数数据的放置不受 ReqAddr 影响。
32 字节的操作数数据字段 Op1 和 Op2，在内存中各自被划分为：4 字节原子操作对应 8 个对齐的 4 字节元素，或 8 字节原子操作对应 4 个对齐的 8 字节元素。按地址对应的 Op1 与 Op2 元素被原子操作用于更新 ReqAddr 所指定 32 字节内存区域中的相应元素。
与单操作数原子操作一样，OrigDataByteEn 字节使能用于决定给定元素是否要被更新，且字节使能可以是稀疏的（可以更新不连续的元素，也可以不更新任何元素）。与单操作数原子操作类似，每个元素的 Op1 和 Op2 操作数的字节使能必须全部置位或全部不置位。不允许元素操作数内部的部分使能（这个条件的一个推论是：Op1 操作数数据的字节使能必须与 Op2 操作数数据的字节使能取相同值）。
下图展示了一个 8 字节双操作数原子操作的操作数与（如存在的）返回数据的字节通道分配。ReqAddr 相对地址"0x20h"有偏移，操作作用于两个稀疏元素：
图 2-23 双操作数（8 字节操作数）原子操作，数据在高 32 字节返回
对于 AtomicR，数据元素按相对于 ReqAddr 所指定地址的自然对齐字节通道返回。
下图展示了一个 4 字节双操作数原子操作的操作数与（如存在的）返回数据的字节通道分配。ReqAddr 位于地址"0"，操作作用于四个稀疏元素：
图 2-24 双操作数（4 字节操作数）原子操作，数据在低 32 字节返回
对于 AtomicR，数据元素按相对于 ReqAddr 所指定地址的自然对齐字节通道返回。
虽然上述示例没有明确展示原子操作中 1 字节和 2 字节元素的情形，但对字节使能、操作数与数据及其对齐方式做显而易见的替换即可适用于 1 字节和 2 字节元素。
不支持给定原子请求的完成方设备，在相应的读响应通道（对 AtomicR 请求）或写响应通道（对 AtomicNR 请求）上返回 SLVERR 响应。