全文笔记01 - Ultra Accelerator Link Consortium Inc. (UALink) – UALink 128G DL/PL

原创于 2026-08-04 16:20:29 发布 · 130 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

Ultra Accelerator Link Consortium, Inc. 规范

UALink 128G 数据链路层与物理层（Data Link and Physical Layers）

修订版 Rev 1.0

Ultra Accelerator Link Consortium Inc.（UALink）—— UALink 128G DL/PL

ULTRA ACCELERATOR LINK™　UALink™

本文档为 UALink 128G Data Link and Physical Layers Rev 1.0 规范的完整中文翻译，仅供学习研究使用。原文版权归 Ultra Accelerator Link Consortium, Inc. 所有。

关于本公开规范的 legal notice（法律声明）

本《Ultra Accelerator Link Consortium, Inc. 规范：UALink 128G 数据链路层与物理层 Rev 1.0》（下称"本 UALink 规范"或"本文档"）由 Ultra Accelerator Link Consortium, Inc.（一家特拉华州非营利公司，有时简称为"UALink"、“UALink 联盟"或"本公司”）及/或其继承人和受让人所有并为其专有财产。

致 UALink 联盟成员用户的通知：

如果您是 UALink 联盟的成员（有时称为"UALink 成员"），即使您是在同意 UALink 联盟《评估版协议》（Evaluation Copy Agreement，副本见 https://ualinkconsortium.org/specification/）之后获得本 UALink 规范的公开版本，每位 UALink 成员仍必须同时遵守以下全部 UALink 联盟文件、政策和/或程序（统称"UALink 治理文件"），其对本 UALink 规范的使用和/或实施方可获得并享有 UALink 联盟成员身份的全部权利、利益、特权和保护：（i）UALink 联盟《知识产权政策》；（ii）UALink 联盟《章程》（Bylaws）；（iii）任何及所有其他 UALink 联盟政策与程序；以及（iv）该 UALink 成员的《参与协议》（Participation Agreement）。

致非 UALink 联盟成员的通知：

如果您不是 UALink 成员而获得了本 UALink 规范的公开版本，您对本文档的使用以您遵守 UALink 联盟《评估版协议》的全部条款和条件为前提并受其限制（协议副本见 https://ualinkconsortium.org/specification/）。

除《评估版协议》规定的限制外，任何对本文档的引用或引述都必须注明 Ultra Accelerator Link Consortium, Inc. 对本 UALink 规范的独有版权。正确的版权引用格式为：“© 2024-2025 ULTRA ACCELERATOR LINK CONSORTIUM, INC. ALL RIGHTS RESERVED.” 在进行此类引用时，未经 Ultra Accelerator Link Consortium, Inc. 事先明确书面许可，您不得以任何方式修改、变更、改编、制作所引用部分的衍生作品或以其他方式改动之。

除根据 UALink 联盟《评估版协议》的明确条款明确授予非 UALink 成员的有限权利外，本 UALink 规范中的任何内容均不应被视为向任何非 UALink 成员方授予（无论明示或默示）：（i）实施或使用本 UALink 规范或其任何部分或内容的任何形式的许可，或关于 UALink 联盟拥有或控制的任何其他知识产权（包括但不限于 UALink 联盟的任何商标）的任何形式的许可；或（ii）任何 UALink 治理文件下作为 UALink 成员的利益和/或权利。

为明确起见，且不以任何方式限制上述通知：如果您不是 UALink 成员但仍选择实施本 UALink 规范或本文所述的任何部分，特此告知，您的这一选择不会使您获得 UALink 成员的任何权利、利益和/或保护，包括但不限于 UALink 联盟《知识产权政策》赋予 UALink 成员的任何权利、利益、特权或保护。

对所有各方的法律免责声明及附加通知：

本文档及本文提供的所有规范和/或其他内容均按"原样"（AS IS）提供。在适用法律允许的最大范围内，ULTRA ACCELERATOR LINK CONSORTIUM, INC.（连同本文档的贡献者）特此否认所有明示或默示的、法定的或普通法上的陈述、保证和/或承诺，包括但不限于对适销性、特定用途适用性、所有权、有效性和/或不侵权的默示保证。

如果本 UALink 规范引用（包括但不限于援引纳入）了其他标准制定组织或任何其他方（“第三方”）的内容或成果，包括但不限于任何此类第三方的规范或标准（“第三方规范”），特此通知：您对任何第三方规范的使用或实施——（i）不受任何 UALink 治理文件管辖；（ii）可能需要使用第三方的专利、版权或其他知识产权，进而可能需要您独立获得该第三方的许可或其他同意，方可拥有实施或使用该第三方规范的完整权利；和/或（iii）可能受拥有该第三方规范的第三方的知识产权政策或其他政策或程序管辖。本 UALink 规范中可能引用的任何第三方商标或服务标志归其各自所有者所有。

UALINK™ 商标、ULTRA ACCELERATOR LINK CONSORTIUM™ 商标及相关标识（统称"UALink 商标"）是特拉华州公司 Ultra Accelerator Link Consortium, Inc. 所有的商标，其特此保留对其全部 UALink 商标的所有权利、所有权和权益。本文档不授予（也不应被解释为构成授予）使用任何 UALink 商标的任何权利或许可的协议或文书。

关于本 UALink 规范中提供的 PCI-SIG 唯一值（UNIQUE VALUE）的通知

致用户：本 UALink 规范中提供的唯一值（UNIQUE VALUE）仅可用于"供应商自定义消息字段"（Vendor Defined Message Fields）、“指定的供应商特定扩展能力”（Designated Vendor Specific Extended Capabilities）以及"替代协议协商"（Alternate Protocol Negotiation），不得以任何其他方式使用；且唯一值的使用者不得以（A）改变、修改、损害或破坏 PCI-SIG 生态系统或其任何部分的技术功能、安全性或防护性的方式，或（B）可能或将被认定为改变、修改、损害或破坏 PCI-SIG 生态系统或其任何部分的技术功能、安全性或防护性的方式使用该唯一值（就本通知而言，"PCI-SIG 生态系统"指 PCI-SIG 各项规范、PCI-SIG 成员及其包含了 PCI-SIG 规范全部或部分内容的关联产品与服务，并扩展至与 PCI-SIG 成员产品和服务相连接的那些产品与服务）。

1 引言
2 数据链路层（DL）
- 2.1 概述
- 2.2 数据链路层特性
  - 2.2.1 Flit 打包（Packing Flits）
  - 2.2.2 DL 消息服务
  - 2.2.3 UART
  - 2.2.4 发送方步调控制（Tx Pacing）与接收方速率适配（Rx Rate Adaptation）
  - 2.2.5 链路状态与电源状态
- 2.3 Flit 格式
  - 2.3.1 PCIe Flit 背景
    - 2.3.1.1 UALink Flit 与 PCIe Flit 的差异
    - 2.3.1.2 UALink Flit 与 PCIe Flit 的共同点
    - 2.3.1.3 PCIe Flit
  - 2.3.2 DL Flit 概述
  - 2.3.3 Flit 头（Flit Header）
  - 2.3.4 段头（Segment Header）
    - 2.3.4.1 DL 备选扇区（DL Alternative Sector）
    - 2.3.4.2 TL 节拍（TL Beat）
    - 2.3.4.3 M0、M1 消息
  - 2.3.5 Flit 打包规则
  - 2.3.6 TL Flit 到 DL Flit 的映射
- 2.4 DL 消息
  - 2.4.1 消息概述
    - 2.4.1.1 消息类型
    - 2.4.1.2 消息仲裁
  - 2.4.2 基本消息（Basic Messages）
    - 2.4.2.1 通用流程
    - 2.4.2.2 TL 速率通知（TL Rate Notification）
    - 2.4.2.3 设备 ID 请求（Device ID Request）
    - 2.4.2.4 端口号请求与响应（Port Number Request and Response）
    - 2.4.2.5 空操作消息（No-OP Message）
  - 2.4.3 控制消息（Control Messages）
    - 2.4.3.1 通用流程
    - 2.4.3.2 链路宽度协商消息（Link Width Negotiation Message）
    - 2.4.3.3 链路速率协商消息（Link Speed Negotiation Message）
    - 2.4.3.4 链路状态协商消息（Link State Negotiation Message）
    - 2.4.3.5 DL 通道上线/下线协商消息（DL Channel Online/Offline Negotiation Message）
  - 2.4.4 UART 消息
    - 2.4.4.1 协议概述
    - 2.4.4.2 UART 流复位请求（UART Stream Reset Request）
    - 2.4.4.3 UART 流复位响应（UART Stream Reset Response）
    - 2.4.4.4 UART 流传输消息（UART Stream Transport Message）
    - 2.4.4.5 UART 流信用更新（UART Stream Credit Update）
- 2.5 发送方步调控制（Transmitter Pacing）
  - 2.5.1 概述
  - 2.5.2 交换机（Switch）
  - 2.5.3 加速器（Accelerator）
  - 2.5.4 时序（Sequence）
- 2.6 链路状态与错误
  - 2.6.1 DL 链路状态
  - 2.6.2 不可纠正错误
  - 2.6.3 错误遏制（Error Containment）
3 物理层（PL）
- 3.1 引言
- 3.2 框图
  - 3.2.1 发送（Transmit）
  - 3.2.2 接收（Receive）
- 3.3 链路特性
  - 3.3.1 替代协议协商（Alternate Protocol Negotiation）
  - 3.3.2 Flit 模式
  - 3.3.3 交叉链路（Cross Links）
  - 3.3.4 通道反转（Lane Reversal）
  - 3.3.5 重放（Replay）
- 3.4 Flit 格式
  - 3.4.1 Flit 头
  - 3.4.2 数据链路层载荷（DLP）
  - 3.4.3 载荷 Flit（Payload Flit）
  - 3.4.4 空闲 Flit（Idle Flit）
  - 3.4.5 NOP Flit
  - 3.4.6 CRC 与 FEC
- 3.5 链路训练（Link Training）
  - 3.5.1 链路断开（Link down）
  - 3.5.2 替代协议协商
  - 3.5.3 L0
  - 3.5.4 均衡（Equalization）
  - 3.5.5 扩展速率模式（Extended Speed Mode, ESM）
- 3.6 电源管理（PM）
  - 3.6.1 L1
  - 3.6.2 L0p
4 电源管理（Power Management）
- 4.1 L1
  - 4.1.1 L1 进入
  - 4.1.2 L1 退出
- 4.2 L0p
  - 4.2.1 事务层
  - 4.2.2 数据链路层
  - 4.2.3 物理层

插图目录

图 2-1 DL 框图
图 2-2 UART
图 2-3 PCIe Flit 打包（仅供参考）
图 2-4 DL 256 字节 Flit 概述
图 2-5 带段细节的 DL Flit
图 2-6 Flit 打包流程图
图 2-7 TL Flit 示例
图 2-8 TL Flit 跨 Flit 延续（carry over）
图 2-9 单请求流程
图 2-10 双请求流程
图 2-11 单请求成功流程
图 2-12 单请求不成功流程
图 2-13 单请求"决定待定"流程
图 2-14 请求冲突流程
图 2-15 请求相同流程
图 2-16 供应商自定义数据包
图 2-17 步调控制（Pacing）
图 3-1 发送框图
图 3-2 接收框图
图 3-3 DLP 定义
图 3-4 载荷 Flit
图 3-5 空闲 Flit
图 3-6 NOP Flit
图 4-1 L1 进入（第 1 部分）
图 4-2 L1 进入（第 2 部分）

表格目录

表 2-1 每段的扇区分配
表 2-2 段头
表 2-3 DL 消息类型
表 2-4 TL 速率通知
表 2-5 设备 ID 请求
表 2-6 端口 ID 请求
表 2-7 空操作消息
表 2-8 链路宽度协商
表 2-9 链路速率协商
表 2-10 链路状态协商
表 2-11 通道协商
表 2-12 供应商自定义"类型-长度"（TL）双字
表 2-13 UART 流复位请求
表 2-14 UART 流复位响应
表 2-15 UART 流传输消息
表 2-16 UART 流信用更新
表 3-1 Flit 头
表 3-2 DLLP 类型
表 3-3 ESM 数据速率
表 3-4 ESM 超时

修订历史

版本	日期	变更
UALink 128G, DL/PL 0.7	2025/5/8	初始版本
0.9	2025/6/27	更新电源管理，针对链路断开场景
1.0	2025/7/27	小幅修正

1 引言

UALink 支持多种物理层技术。本文档描述基于 PCI Express 6.4 的 UALink 变体。PCIe 6.4 支持的每通道最高信号速率为 64 GT/s、PAM4 调制、1b/1b 编码。UALink 128G 规定的每通道信号速率为 128 GT/s、PAM4 调制、1b/1b 编码。128 GT/s 被定义为一种扩展速率模式（Extended Speed Mode, ESM）：训练序列（training set）中仍使用 64 GT/s 的数据速率标识，LTSSM（链路训练与状态机）按 64 GT/s 的方式运行。仅支持 Flit 工作模式。

数据链路层是 UALink 128G 特有的。所用的 Flit 大小为 256 字节，与 PCIe 6.4 使用的 Flit 大小一致。链路级重放（replay）属于 PCIe 6.4 物理层的功能，因此数据链路层不支持重放。

站点（station）支持 8 条通道、每条 128 GT/s，因此站点带宽为 1024 GT/s。

2 数据链路层（DL）

2.1 概述

框图如下所示。数据链路层位于事务层（Transaction Layer）与物理层（Physical Layer）之间。数据链路层把来自事务层的 64 字节 Flit 打包成供物理层使用的 256 字节 Flit。数据链路层还在链路伙伴（link partner）之间提供一种消息服务，该服务在数据链路层发起并终止。该消息服务用于通告事务层速率、电源管理及其他功能。消息服务还在链路伙伴之间提供 UART 风格的通信，供固件（F/W）通信使用。

物理层 (Physical Layer)
数据链路层 (Data Link)
事务层 (Transaction Layer)
        ┌─────────────────────────────┐
        │  Flit 打包 (Flit Packing)    │
        │  DL 消息服务 (DL Message     │
        │    Service)                  │
        │  Tx 步调 / Rx 速率适配       │
        │  (Tx Pacing / Rx rate        │
        │   adaptation)                │
        └─────────────────────────────┘

图 2-1 DL 框图

2.2 数据链路层特性

2.2.1 Flit 打包

数据链路层在** egress（发送）方向**的主要功能是把来自事务层的 64 字节 Flit 打包成 256 字节的 DL Flit；在 ingress（接收）方向则把 256 字节 DL Flit 拆包还原为 64 字节 Flit 交给事务层。DL 消息也会被打包进 DL Flit。

2.2.2 DL 消息服务

带内（in-band）的 DL 到 DL 消息通过**备选段（alternate segment）**承载，这些段与 TL Flit 数据一起被打包进 256 字节 DL Flit 载荷。DL 到 DL 消息支持以下功能：

通过 UART 进行固件（F/W）消息定序
协商通道（Channel）上线/下线
- 通道 0：用于 TL Flit
- 通道 4：用于 DL UART 消息
通告事务层速率
协商链路（宽度、速率、状态）变更
请求链路伙伴的设备 ID 和端口号

2.2.3 UART

UART 在给定链路两侧的固件代理（firmware agent）之间提供一条通信路径。通过 DL 消息在链路上提供硬件驱动的、基于信用（credit）的流控，以防止 Rx 缓冲区溢出。

UART 的最初用途是使能链路伙伴之间供应商自定义的通信。安全（Security）功能也可以使用 UART。未来版本可能定义更多基于标准的通信。

见图 2-2：固件写入 UART Tx 缓冲区，数据被插入 DL Flit 并发送给链路伙伴；接收方 DL 从 DL Flit 中取出数据放入 UART Rx 缓冲区，接收侧固件读取该数据。

物理层               物理层
UALink PIPE         UALink PIPE
UART TXB   UART RXB │ UART TXB   UART RXB
SERDES ── 物理介质 ── SERDES
数据链路             数据链路

图 2-2 UART

2.2.4 发送方步调控制（Tx Pacing）与接收方速率适配（Rx Rate Adaptation）

Tx Pacing 提供一种机制，使链路伙伴可以限制对端 TL Flit 的发送速率。这使得加速器（Accelerator）能够以低于线速的 UPLI 时钟运行，而不至于使其 Rx 速率适配逻辑中的 Rx FIFO 溢出。

2.2.5 链路状态与电源状态

DL 把基于 TL 的电源与链路状态翻译为基于 PL 的电源与链路状态。

DL 把来自 TL 的"链路断开（link down）"请求传递给 PL。当链路断开时，DL 向 TL 上报链路断开；当链路断开而 TL 并未请求时，DL 向 TL 上报意外链路断开（surprise link down）。

2.3 Flit 格式

2.3.1 PCIe Flit 背景

UALink 使用一种相对 PCIe 6.4 经过修改的 256 字节 Flit。载荷 Flit 中没有用于 DLLP 的 6 字节。UALink 链路上基于信用的流控由 **TL（事务层）**实现。

2.3.1.1 UALink Flit 与 PCIe Flit 的差异

没有 6 字节 DLLP
前 2 个字节保留给 Flit 头：序列号、Flit 用途等，由 **PL（物理层）**填充数据。Flit 头的功能等同于 DLLP0 和 DLLP1。

2.3.1.2 UALink Flit 与 PCIe Flit 的共同点

6 字节 FEC
CRC 64

2.3.1.3 PCIe Flit

为便于比较，下面给出 PCIe Flit 的非事务层字段：

FLIT 组成  PCI Express 6.0（CRC64, FEC, DLLP）

DLLP0  DLLP1  DLLP2  DLLP3  DLLP4  DLLP5
FEC0   FEC1   FEC2   FEC3   FEC4   FEC5
CRC0   CRC1   CRC2   CRC3   CRC4   CRC5   CRC6   CRC7

图 2-3 PCIe Flit 打包（仅供参考）

2.3.2 DL Flit 概述

256 字节 Flit 由 **4 个段（segment）组成。每个段由整数个扇区（sector）**组成，一个扇区为 4 字节。每个段的扇区数取决于该段中头部与 CRC 的位置，具体如下表所述。

段头	载荷扇区数	载荷字节数	扇区编号
SH0	16 扇区	64 字节	15:0
SH1	15 扇区	60 字节	30:16
SH2	16 扇区	64 字节	46:31
SH3	12 扇区	48 字节	58:47

表 2-1 每段的扇区分配

FH[1:0] 字段包含 Flit 头信息：指示 Flit 类型、用于链路级重放的序列号以及其他信息。
**段头（SH）**定义该段的起始内容。
8 字节 CRC 在整个 DL Flit 的全部内容上计算。

下图描述 DL Flit 中各非数据字段的位置：

FH[1:0]：Flit 头
SH[3:0]：段头
CRC
FEC
段载荷：与每个段头对应的载荷

与 PCI Express 6.0 共用的 FLIT 组成（CRC64, FEC）：

Flit 头        段头                    段载荷                          CRC/FEC
┌──────┬──────────────┬─────────────────────────────┬──────────────┐
│ FH0  │ SH0          │ Segment 0                   │              │
│ FH1  │ SH1          │ Segment 1                   │ CRC0..CRC7   │
│      │ SH2          │ Segment 2                   │ FEC0..FEC5   │
│      │ SH3          │ Segment 3                   │              │
└──────┴──────────────┴─────────────────────────────┴──────────────┘

图 2-4 DL 256 字节 Flit 概述

2.3.3 Flit 头

见第 3.4 节。

2.3.4 段头（Segment Header）

段头描述从该段开始的 TL Flit 序列（TL Flit sequence）。一个 TL Flit 序列中最多包含一个 64 字节 TL Flit。段载荷可能不足 64 字节，且某些段可能包含备选扇区（alternative sector），因此 TL Flit 序列的一部分会延续（carry over）到下一段。

段头为 8 位，字段编码如下。TLBeat 指示段内是否打包了 TL Flit 以及与之关联的消息数据（如存在），见图 2-6。

字段名	位位置	描述
DLAltSector	[0]	DL 备选扇区： `0b` — 段内无备选扇区 `1b` — 段内有 DL 备选扇区
Reserved	[1]	保留
TLBeat	[6:2]	`00000b` — 无 TL Flit `01111b` — TL Flit `10010b` — TL Flit，M1 置位 `11011b` — TL Flit，M0 置位 `11110b` — TL Flit，M0 和 M1 均置位
Reserved	[7]	保留

表 2-2 段头

2.3.4.1 DL 备选扇区

当 DLAltSector 位置位时，表示该段包含一个备选扇区。一个扇区为 4 字节。备选扇区用于承载 DL-DL 消息，见第 2.3.5 节。

2.3.4.2 TL Beat

指示是否存在 TL Flit 数据，以及半 Flit（half flit）数据是否置位了其关联的消息位。

2.3.4.3 M0、M1 消息

每个从某段开始的 TL Flit 都带有与之关联的消息位（message bit）。消息数据就是随关联的 TL 半 Flit 一起、透明地穿过 DL 传输的元数据（meta data）。

2.3.5 Flit 打包规则

下图描述了 DL Flit 各字段的位置，包括段载荷细节。Sx.By 表示段内扇区号（Sx）和扇区内字节号（By）。

Flit 头    段头     段载荷扇区（S#B#：Flit 内载荷扇区号，扇区内字节号）          CRC64, FEC
┌──────┬───────┬────────────────────────────────────────────────┬─────────────┐
│ FH0  │ SH0   │ S0B0..S0B3  S1B0..S1B3  ... S15B0..S15B3        │             │
│ FH1  │ SH1   │ S16B0..S16B3  ... S30B0..S30B3                  │ CRC0..CRC7  │
│      │ SH2   │ S31B0..S31B3  ... S46B0..S46B3                  │ FEC0..FEC5  │
│      │ SH3   │ S47B0..S47B3  ... S58B0..S58B3                  │             │
└──────┴───────┴────────────────────────────────────────────────┴─────────────┘
        段 1 可含备选扇区（Segment 1-Altsector DL）

图 2-5 带段细节的 DL Flit

Flit 打包规则如下：

DL Flit 打包器以扇区为单位操作，扇区为 4 字节。
DL 备选扇区具有优先级：如果指示了 DL 备选扇区，它被放置在该段的第一个扇区，先于当前 TL Flit 或上一个 TL Flit 的延续部分。
一条 DL 消息（备选扇区）占用一个扇区（4 字节）。
段内必须至少有一个未分配扇区，才能开始加入一个 TL Flit。
如果一个 TL Flit 无法完整装入当前段，剩余部分延续到下一段。
TL Flit 必须按接收顺序打包，并以与产生时相同的顺序呈现给接收方 TL。
每段最多开始打包一个 TL Flit。
TL Flit 应当边到边打包（on the fly），以降低发送延迟。
注：对于 512 位（64 字节）数据通路，每 4 个时钟节拍打包一个 DL Flit。由于存在 20 字节的 DL 开销（以及偶发的 DL 消息），TL Flit 不可能每个时钟节拍都连续打包。其他数据位宽也是允许的，但必须满足相同的打包行为。
如果 TL 在某个周期没有 Flit 可提交（通常通过一个 valid 边带信号指示），则每个节拍都标记为 TLBeat = 00000b。打包器绝不会把 DL Flit 标记为 NOP。

打包流程如下（见图 2-6）：

开始打包一个段。
如果存在 DL ALT 扇区，将其放入该段的第一个扇区，然后继续。
如果存在上一段的延续（carryover），按扇区顺序打包；若延续部分打包完成则继续，否则转（7）。
如果段内还有未分配扇区则继续，否则本段完成。
如果本周期有 TL Flit 可用，则开始按扇区顺序把它打包进当前段并继续；否则将未分配扇区清零直到段尾，本段完成。
如果该 TL Flit 打包完成，则本段完成，否则继续。
保存延续部分，留给下一段。
转（1）。

                        ┌─────────────────────┐
                        │ 开始打包一个段(Start)│
                        └─────────┬───────────┘
                                  ▼
                          有 DL ALT 扇区？ ──N──┐
                                  │Y            ▼
                     ┌────────────┘        有延续(carry over)? ──N──┐
                     ▼                          │Y                  ▼
              加入 DL ALT 扇区          加入上一 TL Flit 延续   有 TL Flit 且
                     │                          │             有未分配扇区? ──N──┐
                     ▼                          ▼                  │Y           ▼
                     └──────────────►  延续打包完成？ ◄──N──┐       ▼      剩余段清零
                                        │Y                  ▼    加入 TL Flit  (Zero fill)
                                        ▼              保存延续给下一段     │
                                  有未分配扇区？ ──N──► 本段完成(carry over=0)
                                        │Y
                                        ▼
                                  TL Flit 打包完成？ ──Y──► 本段完成
                                        │N
                                        ▼
                              保存延续给下一段(Save carry over)

图 2-6 Flit 打包流程图

2.3.6 TL Flit 到 DL Flit 的映射

在下面的示例中，TL Flit 以**镜像视图（mirrored view）**显示，以便与 DL Flit 的逻辑视图对齐。DL Flit 的顺序为从左到右、从上到下，即按扇区号和字节号的顺序。

图 2-7 描述了一个从 segment[0] 开始打包的 TL Flit。消息位 [1:0] 连同"TL Flit 存在"一起编码进 SH0。TL Flit 扇区 [0] 映射到 DL Flit 扇区 [0]，依此类推。本例中没有来自前一个 TL Flit 的延续。

SH0 │ S0B0 S0B1 S0B2 S0B3 │ S1B0..S1B3 │ ... │ S15B0..S15B3
      └──── TL Flit 扇区 0 ────┘└── 扇区 1 ──┘      └── 扇区 15 ──┘
64 字节 TL Flit（16 扇区）镜像视图：
  扇区 0..7  = 下半 TL Flit（Lower half）
  扇区 8..15 = 上半 TL Flit（Upper half）
  消息位 M0（bit 0）、M1（bit 1）随扇区 S0.B0 编码

图 2-7 TL Flit 示例

图 2-8 描述了一个从 segment[2] 开始打包的 TL Flit。消息位 [1:0] 连同"TL Flit 存在"一起编码进 SH2。TL Flit 扇区 [0] 映射到 DL Flit 扇区 [45]，依此类推，延续进入后面两个段乃至下一个 DL Flit。本例中存在一个备选扇区，且有持续到扇区 [44] 的先前延续。SH3 编码为 0x00：没有 TL Flit 从该段开始，也没有备选扇区。

SH2 │ S31B0..S31B3 │ ... │ S44B0..S44B3（先前延续至此）│ S45B0..S45B3 ← TL Flit 扇区 0
    │ S46B0..S46B3（备选扇区/延续边界）
SH3 │ S47B0..S47B3 │ ... │ S57B0..S57B3 ＋ 下一 Flit 的 S58B0..S58B3（延续部分）

图 2-8 TL Flit 跨段/跨 Flit 延续（carry over）

2.4 DL 消息

保留字段必须置为 0x0，且接收方链路伙伴必须忽略之。

2.4.1 消息概述

2.4.1.1 消息类型

DL Flit 的任何段都可以包含一个 DL 备选扇区（DLAltSector）。DLAltSector 用于发送 DL 消息。DL 消息在 DL 层发起、在 DL 层终止。

所有消息的 bit 0 均为保留位。

消息类别与类型汇总如下：

消息类别（mclass）	类别编码	消息类型（mtype）	类型编码
基本消息（Basic Messages）	`0b0000`	No-Op 消息	`0b000`
		TL 速率通知（TL Rate Notification）	`0b100`
		设备 ID 请求（Device ID Request）	`0b101`
		端口号请求与响应（Port Number Request and Response）	`0b110`
控制消息（Control Messages）	`0b1000`	链路宽度协商	`0b000`
		链路速率协商	`0b001`
		链路状态协商	`0b010`
		DL 通道上线/离线协商	`0b100`
UART 消息（UART Messages）	`0b0001`	UART 流传输消息	`0b000`
		UART 流信用更新	`0b001`
		UART 流复位请求	`0b110`
		UART 流复位响应	`0b111`

表 2-3 DL 消息类型

2.4.1.2 消息仲裁

消息有多个来源。除 UART 流传输消息外，所有消息都是单个双字（DWord）序列；UART 流传输消息最长可达 33 个 DWord。UART 流传输消息必须顺序地打包进每个段，可能跨越多个 Flit。在 UART 流传输消息发送期间，其他 DL 消息必须被阻塞。

仲裁分为两级：

第一级在每种消息类别内部进行：
- 各基本消息之间采用轮询（Round Robin），选出该组的潜在胜出者；
- 各控制消息之间采用轮询，选出该组的潜在胜出者；
- 各 UART 消息之间采用轮询，选出该组的潜在胜出者。
最后一级仲裁在基本消息组、控制消息组和 UART 消息组三者之间进行轮询。

2.4.2 基本消息（Basic Messages）

基本消息用于把信息从一个链路伙伴发送给另一个，或向对端请求信息。不存在协商过程。对于每个 mtype，链路伙伴不得同时存在超过一个未完成（outstanding）的请求，即当前请求必须先完成，才能针对该 mtype 发出新请求。

2.4.2.1 通用流程

2.4.2.1.1 单请求

单请求流程如下所示。本地链路伙伴发出请求，远端链路伙伴必须以 Ack 响应接受该请求。

本地 (Local)                远端 (Remote)
   │ ──── 发起请求 (Initiate Request) ────▶ │
   │ ◀────── 响应 Ack ────────────────── │
   │            成功完成 (Complete, successful)

图 2-9 单请求流程

2.4.2.1.2 双请求

可能同时出现两个具有相同 mclass 和 mtype 的请求。这些请求相互独立，因此按两个独立序列运行，如下所示。

本地 (Local)                远端 (Remote)
   │ ──── 发起请求 A ────▶ │ ◀──── 发起请求 B ────
   │ ◀── 请求 A 成功响应 ── │ ── 请求 B 成功响应 ──▶
   │      （两个序列各自独立完成）

图 2-10 双请求流程

2.4.2.2 TL 速率通知

TL 速率通知消息用于向已连接的链路伙伴传达 TL 速率（时钟频率）的变化。该消息的使用场景见第 2.5 节。

这是一条单向消息，仅用于通知。链路伙伴必须在请求后 1 µs 内以 Ack 响应。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	11:9	保留
Ack	12	0：请求消息；1：响应消息
Reserved	15:13	保留
Rate	31:16	TL 速率，仅对请求消息有效，其他情况保留

表 2-4 TL 速率通知

Rate 以 50.0 kHz 每 LSB 表示。2000 MHz 的全速率编码为十进制 40,000；100 MHz 参考时钟速率编码为十进制 2,000。参考时钟速率是必须支持的最低速率。

x8 链路假设在 2000 MHz 下为 512 位宽，因此 512 × 2000 MHz = 1024 Gbps。其他数据位宽也是允许的，但必须归一化到 512 位宽。
x4 链路假设在 2000 MHz 下为 256 位宽，因此 256 × 2000 MHz = 512 Gbps。其他数据位宽也是允许的，但必须归一化到 256 位宽。
x2 链路假设在 2000 MHz 下为 128 位宽，因此 128 × 2000 MHz = 256 Gbps。其他数据位宽也是允许的，但必须归一化到 128 位宽。

注：DL Flit 存在开销——8 字节 CRC、6 字节 FEC、2 字节 Flit 头、4 字节段头。每个 256 字节 DL Flit 中有 236 字节 TL 载荷。来自 Tx 流水线的反压会自然地把吞吐限制到 (236/256) × 1024 = 944 Gbps。这相当于寄存器设置为十进制 36,875，即 1843.75 MHz。

2.4.2.3 设备 ID 请求

为帮助确定横向扩展（scale out）网络拓扑，链路伙伴可以请求对端的 ID。链路伙伴必须在请求后 1.0 µs 内响应。如果链路伙伴尚未被配置 ID，则在 Valid 位以及 ID 字段中返回 0x0。请求方在请求中通告自己的 ID（若已知）。

当 Ack 字段为请求时：

Valid 指示 ID 是否有效；
Type 指示交换机或加速器；
ID 指示请求方 ID，若 Valid 置 0x0 则该字段置 0x0。

当 Ack 字段为响应时：

Valid 指示 ID 是否有效；
Type 指示交换机或加速器；
ID 指示响应方 ID，若 Valid 置 0x0 则该字段置 0x0。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	11:9	保留
Ack	12	0：请求消息；1：响应消息
Reserved	15:13	保留
ID	25:16	10 位交换机或加速器 ID
Reserved	28:26	保留
Type	30:29	0：交换机；1：加速器；其他保留
Valid	31	0：ID 无效；1：ID 有效

表 2-5 设备 ID 请求

2.4.2.4 端口号请求与响应

为帮助确定纵向扩展（scale up）网络拓扑，链路伙伴可以请求对端在该链路上所接的端口号。链路伙伴必须在请求后 1 µs 内响应。如果链路伙伴尚未被配置端口号，则在 Valid 位返回 0x0，端口号字段未定义并置 0x0。请求方在请求中通告自己的端口号（若已知）。

当 Ack 字段为请求时：

Valid 指示端口号是否有效；
Port number 指示设备端口号（若 Valid 置位）。

当 Ack 字段为响应时：

Valid 指示端口号是否有效；
Port number 指示设备端口号（若 Valid 置位）。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	11:9	保留
Ack	12	0：请求消息；1：响应消息
Reserved	15:13	保留
Port number	27:16	12 位端口号
Reserved	30:28	保留
Valid	31	0：端口号无效；1：端口号有效

表 2-6 端口 ID 请求

2.4.2.5 空操作消息（No-OP Message）

No-Op 消息仅用于 UART 复位序列。在 UART 复位序列期间必须发送 40 条 No-Op 消息，以冲刷（flush）发送器与接收器之间的任何数据。mtype 和 mclass 字段按表 2-3 设置。No-Op 消息不作 ACK。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	31:9	保留

表 2-7 No-Op 消息

2.4.3 控制消息（Control Messages）

控制消息由 DL 用于协商链路上工作方式的变更。协商成功完成后变更生效；协商未成功完成则不发生任何变更。链路是对等（peer to peer）的，任一链路伙伴都可以请求变更。某些链路伙伴类型（例如交换机）不允许发起某些请求。对于本 mclass，链路伙伴不得同时存在超过一个未完成请求，即当前请求必须先完成，才能针对本 mclass 发出新请求。

一旦某链路伙伴收到一个请求，在该请求完成之前，它不得再调度同一 mclass 的请求。两个请求有可能同时或近乎同时发生，从而出现同一 mclass、mtype 的两个冲突请求或相同请求。当一个请求已发出、随后又收到同一 mclass mtype 的请求时，链路伙伴不得以"决定待定（decision pending）"响应，必须以 Ack 或 Nack 响应。

对于每个 mtype 都存在一个裁决函数（resolution function），使冲突的请求最终裁决为：一个请求被 Ack，另一个被 Nack。

2.4.3.1 通用流程

2.4.3.1.1 单请求成功流程

单请求成功流程如下所示。本地链路伙伴发出请求，远端链路伙伴以 Ack 接受请求；本地链路伙伴随后向远端发送一个确认 ACK（confirming ACK）。

本地 (Local)                     远端 (Remote)
   │ ────── 发起请求 (Initiate Request) ──────▶ │
   │ ◀────────── Ack（接受）──────────────── │
   │ ────── 确认 ACK (confirming ACK) ──────▶ │
   │              成功完成 (Complete, successful)

图 2-11 单请求成功流程

2.4.3.1.2 单请求不成功流程

单请求不成功流程如下所示。本地链路伙伴发出请求，远端链路伙伴以 Nack 拒绝该请求。

本地 (Local)                     远端 (Remote)
   │ ────── 发起请求 (Initiate) ─────────────▶ │
   │ ◀────────── Nack（拒绝）─────────────── │
   │            完成：请求不成功 (request unsuccessful)

图 2-12 单请求不成功流程

2.4.3.1.3 单请求"决定待定"流程

单请求"决定待定"流程如下所示。本地链路伙伴发出请求，远端链路伙伴以决定待定（decision pending）响应。远端链路伙伴必须在稍后发出一个请求。在远端链路伙伴就该"决定待定"的 mclass、mtype 发出新请求并且其完成之前，本地链路伙伴不得发出同一 mclass mtype 的请求。如果远端伙伴是交换机，即使它通常不允许发起该请求，此时也必须发出请求。例如：交换机不允许发起进入 L1 的请求，但在发送了"决定待定"响应之后，允许其请求 L1。

本地 (Local)                     远端 (Remote)
   │ ────── 发起请求 (Initiate Request) ──────▶ │
   │ ◀────── 决定待定 (Decision Pending) ──── │
   │ ◀────── 远端发起新请求 ──────────────── │
   │ ────── 响应（请求成功 req successful）─▶ │
   │                  完成 (Complete)

图 2-13 单请求"决定待定"流程

2.4.3.1.4 冲突请求流程

冲突请求流程如下所示。在此场景中，本地与远端链路伙伴在收到对方冲突请求之前都各自发出了请求：

远端链路伙伴把自己发出的请求与收到的请求比较，判定收到的请求应被确认，于是发送 Ack；
本地链路伙伴把自己发出的请求与收到的请求比较，判定收到的请求不应被确认，于是发送 Nack；
本地链路伙伴收到 Ack 后，向远端发送确认 ACK。

本地链路伙伴必须按图示顺序发送 Nack 和 Ack。与收到的请求或响应相关的响应，必须按接收顺序发出。两个链路伙伴中的裁决函数是相同的，因此双方对如何解决冲突能作出一致的判定。

本地 (Local)                     远端 (Remote)
   │ ────── 发起请求 ─────────────▶ │ ◀────── 发起请求 ──────
   │ ────── Nack（拒绝收到的请求）─▶ │ ────── Ack（确认收到的请求）─▶
   │ ◀────────────── Ack ───────── │
   │ ────── 确认 ACK ─────────────▶ │
   │   完成：一个请求成功，一个请求不成功

图 2-14 冲突请求流程

2.4.3.1.5 相同请求流程

相同请求流程如下所示。在此场景中，本地与远端链路伙伴在收到对方相同请求之前都各自发出了请求：

远端链路伙伴把自己的请求与收到的请求比较，判定收到的请求应被确认，发送 Ack；
本地链路伙伴把自己的请求与收到的请求比较，判定收到的请求应被确认，发送 Ack；
本地链路伙伴收到 Ack 后，向远端发送确认 ACK；远端链路伙伴收到 Ack 后，也向本地发送确认 ACK。

本地/远端双方必须按图示顺序发送 Ack。与收到的请求或响应相关的响应，必须按接收顺序发出。两个链路伙伴中的裁决函数相同，因此双方对如何解决冲突能作出一致的判定。

本地 (Local)                     远端 (Remote)
   │ ────── 发起请求 ─────────────▶ │ ◀────── 发起相同请求 ────
   │ ◀────────────── Ack ───────── │ ────────────── Ack ──────▶
   │ ────── 确认 ACK ─────────────▶ │ ◀──────── 确认 ACK ──────
   │        完成：两个请求均成功 (req successful ×2)

图 2-15 相同请求流程

2.4.3.2 链路宽度协商消息

链路宽度协商是 DL 提供的一种消息服务，供两个链路伙伴协商 UALink 链路的宽度变更。

只有加速器（accelerator）可以请求链路宽度变更。

以下描述链路宽度协商消息（DL L0p 消息）的格式与握手序列。

收到链路宽度协商消息后，按以下规则生成响应：

如果 Priority 置位，任何要求宽于当前链路宽度的请求都将被 NACK；
如果 Priority 未置位，任何要求小于所允许最大链路宽度的请求都将被 ACK。

当链路宽度请求以 Priority = 1 发出时，该请求是紧急的，很可能由于热失控（thermal excursion）或其他供电相关的异常所致。该请求必须被确认（acknowledged），即使性能需求可能表明不应如此。

当任一链路伙伴发出带 Priority 置位的链路宽度协商时，硬件必须设置一个软锁定（soft lockout）：在软锁定生效期间，硬件请求的链路宽度增加不得被接受。软锁定的发生必须通报给固件，由固件负责清除软锁定，使系统恢复正常的链路宽度变更操作。

在链路宽度变更请求冲突的情况下，按以下规则确定胜出者：

Priority 置 1 的最小链路宽度请求胜出；
如果双方都没有通告 Priority 置 1，则最宽的链路宽度请求胜出。

从每个链路伙伴的角度看，当它已发出一条 Command = Ack 的链路宽度协商 DL 消息、并且已收到一条 Command = Ack 的链路宽度协商 DL 消息时，协商即告完成。当某链路伙伴发出 Command = 决定待定的链路宽度协商 DL 消息时，该伙伴实际上是终止当前的协商交换，并承担起重新发起协商交换、把协商推向结论的责任。

当某链路伙伴在一轮协商中落败，在发生以下事件之一前，该代理不得再次请求链路宽度变更：

最近落败的链路伙伴有了一个既不同于其最近一次请求、也不同于当前链路宽度的新请求；
最近胜出的链路伙伴发起了链路宽度变更请求。

收到请求后，必须在 1.0 µs 内发出响应（Ack、Nack 或决定待定）。以"决定待定"响应的链路伙伴必须在 10 ms 内发出请求。

当 Channel.Command 字段为请求时：

Channel.TargetState 指示发送方链路伙伴期望的链路宽度；
Channel.Response 保留，必须置 0x0。

当 Channel.Command 字段为决定待定时：

Channel.TargetState 保留，必须置 0x0；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

当 Channel.Command 字段为 Ack 或 Nack 时：

Channel.TargetState 指示发送方链路伙伴期望的链路宽度状态；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	14:9	保留
Priority	15	L0p 优先级
Channel.TargetState	19:16	0000：x1 链路宽度 0001：x2 链路宽度 0010：x4 链路宽度 0011：x8 链路宽度其他保留
Channel.Command	23:20	0100：请求（Request） 0110：Ack 0111：NAck 1000：决定待定（decision pending）其他：保留
Channel.Response	27:24	0000：x1 链路宽度 0001：x2 链路宽度 0010：x4 链路宽度 0011：x8 链路宽度其他保留
Reserved	31:28	保留

表 2-8 链路宽度协商

2.4.3.3 链路速率协商消息

链路速率协商是 UALink DL 提供的一种消息服务，供两个链路伙伴就 PL 链路速率变更的意向进行协商。

只有加速器可以请求链路速率变更。

链路速率变更通过 DL 消息协商。一旦链路速率变更协商完成，UALink DL 使用标准 PCIe 机制指示 PL 改变数据速率，即经由一次 Recovery（恢复）流程来改变数据速率。

收到链路速率协商消息后，按以下规则生成响应：

如果 Priority 置位，任何要求高于当前链路速率的请求都将被 NACK；
如果 Priority 未置位，任何要求低于所允许最大链路速率的请求都将被 ACK。

如果链路速率变更请求以 Priority = 1 发出，该请求是紧急的，很可能由于热失控或其他供电相关异常所致。该请求必须被同意，即使性能需求可能表明不应如此。当 Priority 位置位时，所请求的速率必须低于当前速率，否则将给出 NACK。

当链路速率下调被强制执行时（即任一侧置位了 Priority），硬件必须设置一个软锁定（soft-lockout）：所有（来自硬件的）要求高于该强制状态的链路速率请求都必须被拒绝。软锁定的发生必须通报给固件，由固件负责清除软锁定，使系统恢复正常的链路速率变更操作。

在链路速率变更请求冲突的情况下，按以下规则确定胜出者：

Priority 置 1 的最低链路速率请求胜出；
如果双方都没有通告 Priority 置 1，则最高链路速率请求胜出。

从每个链路伙伴的角度看，当它已发出一条 Command = Ack 的链路速率协商 DL 消息、并且已收到一条 Command = Ack 的链路速率协商 DL 消息时，协商即告完成。当某链路伙伴发出 Command = 决定待定的链路速率协商 DL 消息时，该伙伴实际上是终止当前协商交换，并承担起重新发起协商交换、把协商推向结论的责任。

当某链路伙伴在一轮协商中落败，在发生以下事件之一前，该代理不得再次请求链路速率变更：

最近落败的链路伙伴有了一个既不同于其最近一次请求、也不同于当前链路速率的新请求；
最近胜出的链路伙伴发起了链路速率变更请求。

收到请求后，必须在 1.0 µs 内发出响应（Ack、Nack 或决定待定）。以"决定待定"响应的链路伙伴必须在 10 ms 内发出请求。

当 Channel.Command 字段为请求时：

Channel.TargetState 指示发送方链路伙伴期望的链路速率；
Channel.Response 保留，必须置 0x0。

当 Channel.Command 字段为决定待定时：

Channel.TargetState 保留，必须置 0x0；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

当 Channel.Command 字段为 Ack 或 Nack 时：

Channel.TargetState 指示发送方链路伙伴期望的链路速率状态；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	14:9	保留
Priority	15	优先级
Channel.TargetState	19:16	0000：2.5 GT/s 0001：32.0 GT/s 0010：64.0 GT/s 0011：ESM（128、120、112、104 GT/s）其他保留
Channel.Command	23:20	0100：请求 0110：Ack 0111：NAck 1000：决定待定其他：保留
Channel.Response	27:24	0000：2.5 GT/s 0001：32.0 GT/s 0010：64.0 GT/s 0011：ESM（128、120、112、104 GT/s）其他保留
Reserved	31:28	保留

表 2-9 链路速率协商

2.4.3.4 链路状态协商消息

链路状态协商是 UALink DL 提供的一种消息服务，供两个链路伙伴就 PL 链路状态变更的意向进行协商。

只有加速器可以请求链路状态变更。

从 L0 到 L1 的链路状态变更通过 DL 消息协商。一旦链路状态变更协商完成，DL 使用标准 PCIe 机制指示 PL 改变链路状态，即指示链路执行 L0 → L1.0，或 L1.0 → Recovery（恢复）然后回到 L0。不支持 L1 子状态（L1 substates）。

收到链路状态协商消息后，按以下规则生成响应：

任何要求 L0 的请求都将被 ACK，除非 Priority 置位；
如果 Priority 置位，任何要求比当前链路状态功耗更高的链路状态请求都将被 NACK。

如果链路状态变更请求以 Priority = 1 发出，该请求是紧急的，很可能由于热失控或其他供电相关异常所致。该请求必须被同意，即使性能需求可能表明不应如此。当 Priority 位置位时，所请求的状态必须低于当前状态，否则将给出 NACK。

当链路速率下调被强制执行时（即任一侧置位了 Priority），硬件必须设置一个软锁定：所有（来自硬件的）要求高于该强制状态的链路速率请求都必须被拒绝。软锁定的发生必须通报给固件，由固件负责清除软锁定，使系统恢复正常的链路状态变更操作。

链路状态只有 L0 和 L1 两个状态，因此不可能出现双方链路伙伴的冲突请求。不允许请求当前状态：如果收到针对当前状态的请求，应予以 Ack，并由收到请求的链路伙伴记录一个错误。

从每个链路伙伴的角度看，当它已发出一条 Command = Ack 的链路状态协商 DL 消息、并且已收到一条 Command = Ack 的链路状态协商 DL 消息时，协商即告完成。当某链路伙伴发出 Command = 决定待定的链路状态协商 DL 消息时，该伙伴实际上是终止当前协商交换，并承担起重新发起协商交换、把协商推向结论的责任。

当某链路伙伴在一轮协商中落败，在发生以下事件之一前，该代理不得再次请求链路状态变更：

最近落败的链路伙伴有了一个既不同于其最近一次请求、也不同于当前链路状态的新请求；
最近胜出的链路伙伴发起了链路状态变更请求。

收到请求后，必须在 1.0 µs 内发出响应（Ack、Nack 或决定待定）。以"决定待定"响应的链路伙伴必须在 10 ms 内发出请求。

当 Channel.Command 字段为请求时：

Channel.TargetState 指示发送方链路伙伴期望的链路状态；
Channel.Response 保留，必须置 0x0。

当 Channel.Command 字段为决定待定时：

Channel.TargetState 保留，必须置 0x0；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

当 Channel.Command 字段为 Ack 或 Nack 时：

Channel.TargetState 指示发送方链路伙伴期望的链路状态；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	14:9	保留
Priority	15	优先级
Channel.TargetState	19:16	0000：L0 0001：L1 其他保留
Channel.Command	23:20	0100：请求 0110：Ack 0111：NAck 1000：决定待定其他：保留
Channel.Response	27:24	0000：L0 0001：L1 其他保留
Reserved	31:28	保留

表 2-10 链路状态协商

2.4.3.5 DL 通道上线/离线协商消息

格式如下所示。这些消息用于协商通道（Channel）的离线与上线。默认情况下，复位后所有通道均为离线。

只有加速器可以请求通道离线/上线。

已定义的通道如下：

通道 0：TL Flit
通道 4：DL UART

当某通道离线时，不得发送与该通道关联的数据。收到的属于离线通道的数据被静默丢弃。 当通道 0 离线时，所发送 DL Flit 的段头中 TL Flit[1:0] 必须置 0。当通道 4 离线时，所发送 DL Flit 的备选扇区中不得出现 mtype = 0b0001（即 UART 消息）。

只有上线和离线两个状态，因此不可能出现双方链路伙伴的冲突请求。不允许请求当前状态：如果收到针对当前状态的请求，应予以 Ack，并由收到请求的链路伙伴记录一个错误。

收到请求后，必须在 1.0 µs 内发出响应（Ack、Nack 或决定待定）。当收到通道上线请求（且该通道当前状态为离线）时，响应必须是 Ack 或决定待定；对上线请求以"决定待定"响应的链路伙伴必须在 10 ms 内发出通道上线请求。当收到通道离线请求（且该通道当前状态为上线）时，响应必须是 Ack。

当 Channel.Command 字段为请求时：

Channel.TargetState 指示发送方链路伙伴期望的上线/离线状态；
Channel.Response 保留，必须置 0x0。

当 Channel.Command 字段为决定待定时：

Channel.TargetState 保留，必须置 0x0；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

当 Channel.Command 字段为 Ack 或 Nack 时：

Channel.TargetState 指示发送方链路伙伴期望的上线/离线状态；
Channel.Response 为从远端链路伙伴收到的所请求 Channel.TargetState。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Reserved	15:9	保留
Channel.TargetState	19:16	0xxx：通道离线 1xxx：通道上线 xNNN：通道 ID
Channel.Command	23:20	0100：请求 0110：Ack 0111：NAck 1000：决定待定其他：保留
Channel.Response	27:24	0xxx：通道离线 1xxx：通道上线 xNNN：通道 ID
Reserved	31:28	保留

表 2-11 通道协商

2.4.4 UART 消息

2.4.4.1 协议概述

UART 提供一种机制，利用链路带宽的一小部分，在一端的 UART 发送缓冲区（UART Transmit Buffer）与另一端的 UART 接收缓冲区（UART Receive Buffer）之间传送数据。这是一个双向协议。每个段中可以以备选扇区形式发送 32 位。一个段为 512 位，因此链路带宽的约 6% 可用于 UART 流传输消息。

UART 流传输消息长度可变，长度在消息的第一个 DWord 中指示。第一个 DWord 不存入 UART 发送缓冲区或 UART 接收缓冲区。消息长度根据可用信用（credit）和 UART 发送缓冲区的填充量动态确定。后续 DWord 是消息数据，存入 UART 发送缓冲区和 UART 接收缓冲区。

建议的 UART 发送缓冲区与接收缓冲区大小为每流各 128 个 DWord。当前只定义了单一流（stream），但流 ID 字段为最多 8 个流预留了空间。

2.4.4.1.1 初始化

UART 发送缓冲区和接收缓冲区的初始状态必须为空。通道 4 必须在运行前使能。发送与接收信用计数器的初始状态必须为 0，即发送器没有可用于发送数据的信用。

2.4.4.1.2 流复位（Stream Reset）

流复位序列如下：

本地固件判定需要进行 UART 流复位。
禁用该 UART 流。
冲刷受影响流的 UART 发送缓冲区和接收缓冲区。
被禁用流的信用计数复位为 0x0。
此后对被禁用 UART 发送缓冲区的任何写入都被丢弃。
此后来自链路伙伴的、属于被禁用流的任何接收数据都被丢弃。在复位握手完成之前，这些丢弃的错误上报被抑制。
阻塞所有 DL 消息（所有类别、所有类型），以防进一步污染。
发送 40 条 DL No-Op 消息，确保任何在途的 UART 流传输消息完全流出（run-out）。
发送一条 UART 流复位请求消息。
解除对 DL 消息（所有类别、所有类型）的阻塞，以允许继续推进。
等待 status = SUCCESS 的 UART 流复位响应：
- 10 ms 超时后，若未收到 status = SUCCESS 的复位响应，回到步骤（7）循环。
恢复正常运行。

收到 UART 流复位请求消息的远端链路伙伴执行以下序列：

禁用该 UART 流。
冲刷受影响流的 UART 发送缓冲区和接收缓冲区。
被禁用流的信用计数复位为 0x0。
此后对被禁用 UART 发送缓冲区的任何写入都被丢弃。
发送一条 status = SUCCESS 的 UART 流复位响应消息。
恢复正常运行。

2.4.4.1.3 流控（Flow Control）

流控由两个模 2¹² 信用计数器管理——每个方向各有一对：接收器一个（接收信用计数器，Receiver Credit Counter），发送器一个（发送信用计数器，Transmit Credit Counter）。初始化时两个计数器都置 0x0。每个计数值代表一个 DWord。

接收信用计数器规则如下：

复位期间接收信用计数器初始化为 0；
复位释放后，接收信用计数器更新为 UART 接收缓冲区的大小；
每当从 UART 接收缓冲区读出一个 DWord，接收信用计数器加 1；
如果通道 4 已使能，则在以下条件下调度发送一条 UART 流信用更新消息，其 DataFCSeq 字段携带接收信用计数器的值：
- 自复位以来尚未调度过任何 UART 流信用更新；
- 当接收信用计数器递增、且已发送了 4 个 Flit 时。

发送信用计数器规则如下：

复位期间发送信用计数器初始化为 0；
每发送一条 UART 流传输消息，发送信用计数器即更新。

当以下条件全部成立时，应调度一条 UART 流传输消息：

通道 4 已使能；
UART 发送缓冲区中有一个或更多 DWord；
最近收到的 UART 流信用更新中的 DataFCSeq 字段，减去本地发送信用计数器（采用模 2¹² 减法），结果大于 0——这表示对端 UART 接收缓冲区中有空间。

UART 流传输消息的 length 字段取以下三者的最小值：

上述模减法的结果减 1；
UART 发送缓冲区填充量减 1；
32 减 1（即 31）。

2.4.4.1.4 供应商自定义数据包 TLV

UART 流传输消息的长度与供应商自定义数据包（Vendor Defined Packet）的长度没有关系。下图展示一个跨越 3 条 UART 流传输消息的供应商自定义数据包 [i]。供应商自定义数据包的第一个 DWord 是一个 TL（类型-长度），描述该包的类型（Type）与长度（Length），随后的 3 个 DWord（V[2:0]）描述消息的值（Value）。

供应商自定义数据包 [i]（Vendor Defined Packet [i]）
┌──────────────────────────────────────────────────────────┐
│ TL │ V0 │ V1 │ V2                                        │
└────┴────┴────┴───────────────────────────────────────────┘
  │    │    │    │
  ▼    ▼    ▼    ▼
UART 流传输消息 #1:  [L=3][TL][V0][V1]
UART 流传输消息 #2:  [L=2][V2][...]
UART 流传输消息 #3:  [L=3][TL][V0][...]   ← 下一个数据包

图 2-16 供应商自定义数据包

供应商自定义消息的第一个 DWord 描述如下：

字段	位	描述
Length	7:0	载荷长度 −1： 0x00：载荷长度 = 1 DWord 0xFF：载荷长度 = 256 DWord
Type	15:8	消息类型
Vendor ID	31:16	已定义的供应商 ID，或 0xFFFF 表示 UALink 定义的消息

表 2-12 供应商自定义"类型-长度"（TL）双字

2.4.4.2 UART 流复位请求

UART 流复位请求消息如下所示。它用于发起复位序列，可针对单个流，也可针对所有流。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Stream ID	11:9	000：流 0；其他保留
allStreams	12	0：仅所指示的流；1：所有流
Reserved	31:13	保留

表 2-13 UART 流复位请求

2.4.4.3 UART 流复位响应

UART 流复位响应消息如下所示。它用于上报复位序列的状态，可针对单个流，也可针对所有流。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Stream ID	11:9	000：流 0；其他保留
allStreams	12	0：仅所指示的流；1：所有流
Status	15:13	000：成功；其他保留
Reserved	31:16	保留

表 2-14 UART 流复位响应

2.4.4.4 UART 流传输消息

UART 流传输消息如下所示。该消息以每段 32 位、每次一个 DWord 的方式发送。消息长度以 DWord 为单位按字段指示。载荷最大长度为 32 个 DWord；传输消息最大长度为 33 个 DWord。 UART 流传输消息必须连续发送，即在任何两个 UART 流传输消息 DWord 之间不得插入其他 DL 消息。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Stream ID	11:9	000：流 0；其他保留
Reserved	26:12	保留
Length	31:27	载荷长度 +1（DWord 数），即 length = 0 表示 1 个 DWord 载荷
DWord payload 0	63:32	第一个载荷 DWord
DWord payload 1	95:64	第二个载荷 DWord（如需要）
DWord payload n	(n+2)×32−1 : (n+1)×32	第 n 个载荷 DWord（如需要）

表 2-15 UART 流传输消息

2.4.4.5 UART 流信用更新

UART 流信用更新消息如下所示。它用于从接收器向发送器通告信用可用情况。

字段	位	描述
Compressed	0	置 0，不支持
Reserved	1	保留
mclass	5:2	消息类别
mtype	8:6	消息类型
Stream ID	11:9	000：流 0；其他保留
Reserved	19:12	保留
DataFCSeq	31:20	数据流控序列更新

表 2-16 UART 流信用更新

2.5 发送方步调控制（Transmitter Pacing）

2.5.1 概述

事务缓冲区位于 TL 中，基于信用的流控保证接收方 TL 缓冲区中始终有空间。TL 由 UPLI 时钟驱动。加速器可以把其 UPLI 时钟改到更低频率，使其吞吐低于物理层吞吐。

注：降低时钟频率是加速器和 CPU 中常用的降功耗机制。

当接收方 UPLI 时钟运行在较低频率时，发送设备上必须有发送方步调控制（Transmitter Pacing），以防止接收设备的 DL Rx FIFO 溢出。Rx FIFO 的写入速率由**恢复时钟（recovered clock）**导出，默认为 1024 Gb/s，实现为 512 位（64 字节）× 2000 MHz = 1024 Gb/s。如果 UPLI 时钟已被降低，读出速率可能更慢，从而导致 Rx FIFO 逐渐填满。

Pacing（步调）定义为来自 TL 的 Tx Flit 被准许进入 DL Tx FIFO 的速率。 DL 通过调制发往 TL 的 “Ready” 信号，指示在哪些时钟节拍上数据可以传输。

注：“ready” 信号只是一种可能的实现方式，其他实现也是允许的。此处仅为说明用途。

        发送器 (Transmitter)                     接收器 (Receiver)
  ┌───────────────────────────┐         ┌───────────────────────────┐
  │ 事务层                     │         │ 事务层                     │
  │   ↑ ready                  │         │   ↑                        │
  │ 数据链路                   │         │ 数据链路                   │
  │  [Flit 打包]               │         │  [Flit 拆包]               │
  │  [Transmit Pacing]         │         │   ↑                        │
  │   ↓ Tx FIFO                │ SerDes  │  Rx FIFO                   │
  │  SerDes ───────────────────┼────────►│  SerDes                    │
  │  Transmit CLK / UPLI CLK   │  PL     │  Recovered CLK / UPLI CLK  │
  └───────────────────────────┘         └───────────────────────────┘

图 2-17 步调控制（Pacing）

2.5.2 交换机（Switch）

交换机必须以固定 UPLICLK 运行，使吞吐为 1024 GT/s（512 位 × 2000 MHz）。如果加速器改变了其 UPLICLK，它向交换机发送一条 TL 速率通知消息。交换机收到该消息后，相应调整其发送步调速率，以避免加速器中的 Rx FIFO 溢出。

2.5.3 加速器（Accelerator）

加速器可以改变其 UPLI 时钟。如果加速器打算改变其 UPLI 时钟，必须通过 TL 速率通知消息告知其链路伙伴。允许链路上的两个加速器以不同速率运行，也允许加速器各自独立地同时改变速率。

2.5.4 时序（Sequence）

以下规则适用于 UPLI 时钟速率变更：

默认速率为 1024G GT/s 或 2000 MHz。
只有加速器可以改变其 UPLI 时钟频率。
改变 UPLI 时钟频率需要重新编程 PLL，因此两次速率变更之间必须经过一个中间 UPLI 时钟频率——即 100 MHz 参考时钟。在 PLL 导出时钟与 100 MHz 参考时钟之间的切换通过**无毛刺时钟复用器（glitchless clock mux）**完成。
当加速器打算改变其 UPLI 时钟频率时：
- a. 把其 Tx 步调调整到参考时钟速率；
- b. 发送一条针对参考时钟速率的 TL 速率通知消息；
- c. 等待 TL 速率通知消息 ACK；
- d. 把其 UPLI 时钟复用到参考时钟；
- e. 调整其 PLL 到新的 UPLI 时钟频率；
- f. 把其 UPLI 时钟复用到新的 PLL 频率，Tx 步调设置为链路伙伴的速率（若对方的 UPLI 时钟速率更低）；
- g. 发送一条针对新时钟速率的 TL 速率通知消息；
- h. 等待 TL 速率通知消息 ACK；
- i. 完成。
当链路伙伴收到 TL 速率通知消息时：
- a. 登记该值；
- b. 必要时调整其 Tx 步调（即对方通告了更低速率时）；
- c. 在 1.0 µs 内发送 TL 速率通知消息 ACK；
- d. 完成。

2.6 链路状态与错误

2.6.1 DL 链路状态

DL 链路状态遵循 PCIe 基础规范 6.4，参见该规范的 Table 4-58《Link Status Mapped to the LTSSM》。UALink PL 不支持 L0s 和 L2。

DL 从 TL 接收 link down 与 link up 命令，并把这些命令传递给 PL。DL 从 PL 接收链路状态并传递给 TL。

DL 还可以基于检测到的错误条件自行产生 link down 请求，见下一节。

2.6.2 不可纠正错误

不可纠正错误可能发生在 PL 重放功能之上的各层。这些数据与控制通路必须有适当的奇偶校验（parity）保护，以检测软错误或硬错误。

2.6.3 错误遏制（Error Containment）

错误遏制的目标是阻止已知有错误的数据继续传播。

2.6.3.1 PL

PL 重放之下的错误遏制由 FEC 与 CRC 重放覆盖。只有通过 FEC 纠错和 PL CRC 校验的数据才会被转发给 DL。

2.6.3.2 数据链路层

Ingress（接收）方向：从 PL 接收 DL Flit 并拆包后，DL 把 TL Flit 传给 TL。如果任何 DL Flit 或 TL Flit 被判定出错（通过奇偶校验错误或其他手段），则在传给 TL 时将其标记为错误（flagged as errored）或在传递前丢弃。后续的 TL Flit 一律丢弃。

Egress（发送）方向：当 TL 指示一个出错的 TL Flit，或打包过程中检测到奇偶校验错误时，该 DL Flit 的 CRC 被取反（inverted）——这保证该 DL Flit 在链路伙伴处必然 CRC 校验失败。后续的 DL Flit（包括 NOP Flit）不再发送给 PL。

在上述两种情况下，DL 均转为 link down，并通知 PL 进入 link down；DL 同时告知 TL 链路已断开。

3 物理层（PL）

3.1 引言

UALink PL 基于 PCIe 6.4 物理层逻辑层（Phy logical layer, PL）。

必须支持所有 PCIe LTSSM 状态与行为，以下列出的例外除外；
链路只能以 Flit 模式运行；
通道在链路训练前静态配置为 1x8、2x4 或 4x2：
- 所有模式都应支持，至少必须支持一种模式；
必须支持以下数据速率：
- 2.5 GT，8b10b，NRZ
- 32.0 GT，128b130b，NRZ
- 64.0 GT，1b1b，PAM4
- 128.0、120.0、112.0、104.0 GT，1b1b，PAM4（ESM）
必须支持到最高 NRZ 数据速率的均衡（equalization）；
必须支持低功耗状态 L1；
不支持 L1 子状态；
不支持 L1 ASPM；
应支持 L0p；
不支持 L0s；
必须支持交叉链路（cross links）；
必须支持 SRNS 时钟，可支持 SRIS 时钟；
必须支持 256 字节 Flit（按 PCIe 规范）；
必须支持 CRC-64 数据完整性校验（按 PCIe 规范）；
必须支持三重交织 FEC（Triple-interleaved FEC）（按 PCIe 规范）；
必须支持标准重放（standard replay），可支持选择性重放（selective Replay）；
必须支持使用 UALink 唯一值 0x20AE1 ¹ 进行替代协议协商（alternate protocol negotiation）；
应支持通道反转（lane reversal）。

¹ 致用户：本规范中提供的唯一值（UNIQUE VALUE）仅可用于"供应商自定义消息字段"、“指定的供应商特定扩展能力"以及"替代协议协商”，不得以任何其他方式使用；且唯一值的使用者不得以（A）改变、修改、损害或破坏 PCI-SIG 生态系统或其任何部分的技术功能、安全性或防护性的方式，或（B）可能或将被认定为改变、修改、损害或破坏 PCI-SIG 生态系统或其任何部分的技术功能、安全性或防护性的方式使用该唯一值（就本通知而言，"PCI-SIG 生态系统"指 PCI-SIG 各项规范、PCI-SIG 成员及其包含了 PCI-SIG 规范全部或部分内容的关联产品与服务，并扩展至与 PCI-SIG 成员产品和服务相连接的那些产品与服务）。

3.2 框图

3.2.1 发送（Transmit）

发送框图如下所示。数据通路把来自 DL 的 256 字节 DL Flit 流式送入 PL。LTSSM 控制有序集发生器（ordered set generator），同时把状态信息发送给 DL，供其跟踪链路 up/down 状态。重试缓冲区（retry buffer）保存 DL Flit，直到接收方给出肯定确认（positive acknowledgement）。CRC 和 FEC 被写入 DL Flit，然后数据被加扰（scramble）并按数据速率进行预编码（preceding）。随后数据按数据速率编码，由 SerDes 发送到线路上。DLP 发生器生成用于 L1 和 L0p 协商的 DLLP，它们只出现在 NOP Flit 中。

UPLICLK        UALink-DL ──► UALink-PL (Phy)
┌─────────────────────────────────────────────────────┐
│ UALink Data Link                                    │
│   │ 256B DL Flits                                   │
│   ▼                                                 │
│ LTSSM ──► Ordered-Set Generator（有序集发生器）      │
│   │                                                 │
│   ▼                                                 │
│ Flit TX Retry Buffer（发送重试缓冲区）               │
│   │                                                 │
│   ▼                                                 │
│ DLP Generator（DLP 发生器，用于 L1/L0p 协商）        │
│   │                                                 │
│   ▼                                                 │
│ CRC64 ──► FEC ──► Scrambler（加扰器）                │
│   │              ──► Precoding（预编码）             │
│   ▼                                                 │
│ Encoding：1b/1b | 128b/130b | 8b/10b（按速率选择）   │
│   │                                                 │
│   ▼                                                 │
│ SERDES ──► 线路（TxCLK）                             │
│ （AES-GCM 加密可选位置）                             │
└─────────────────────────────────────────────────────┘

图 3-1 发送框图

3.2.2 接收（Receive）

接收框图如下所示。SerDes 把串行数据转换为并行数据，数据按数据速率解码后进行解扰（descramble）。执行通道去偏斜（lane deskew）与时钟补偿（clock compensation）。有序集被解码并驱动 LTSSM。256 字节 DL Flit 经过 FEC 纠错与 CRC 校验后递交。若支持选择性重放（selective replay），DL Flit 可选地送入 Rx Retry 缓冲区；最后 DL Flit 按序递交给 DL。

SERDES ──► 并行数据（RxCLK）
   │
   ▼
Decoding：1b/1b | 128b/130b | 8b/10b（按速率选择）
   │
   ▼
Rx Precoding（接收预编码）──► Descrambler（解扰器）
   │
   ▼
Elastic Buffer（弹性缓冲，时钟补偿/通道去偏斜）
   │
   ▼
Ordered-Set Receiver（有序集接收器）──► LTSSM
   │
   ▼
FEC Decoding and Correction（FEC 解码与纠错）
   │
   ▼
CRC64 Check（CRC64 校验）
   │
   ▼
Replay Controller（重放控制器）──► Flit RX Retry Buffer（可选，选择性重放）
   │
   ▼
按序递交 UALink-DL ──► UALink Data Link（UPLICLK 域）
（AES-GCM 解密可选位置）

图 3-2 接收框图

3.3 链路特性

3.3.1 替代协议协商（Alternate Protocol Negotiation）

替代协议协商发生在初始链路建立（link up）时的 Configuration（配置）状态。UALink 设备必须通过修改版 TS1/TS2 有序集（Modified TS1/TS2 ordered sets）、使用 UALink 唯一值 0x20AE 来通告对 UALink 的支持。

修改版 TS 有序集中的"Modified TS information 1"、"Alternate Protocol Details"字段以及"Modified TS information 2"均为保留并置 0x0。实现上：发送值必须基于一个寄存器设置（默认 0x0），接收值必须捕获到一个只读寄存器中。这将允许未来版本通过固件传递信息。

3.3.2 Flit 模式

训练序列中必须置位 Flit Mode Supported 位，表示支持 Flit 模式。

3.3.3 交叉链路（Cross Links）

交换机端口为交叉链路：在链路训练开始时通过寄存器配置为上游端口（upstream port）。
加速器端口为交叉链路：在链路训练开始时通过寄存器配置为下游端口（downstream port）。

3.3.4 通道反转（Lane Reversal）

应支持通道反转（在 PCIe 基础规范中为可选）。链路应能在训练期间、或因运行中出错，以更小的链路宽度组建。必须支持以 x1 链路运行。

3.3.5 重放（Replay）

重放与 PCIe 基础规范相同。必须支持标准重放，可支持选择性重放。

3.4 Flit 格式

PL 处理三种类型的 Flit：

载荷 Flit（Payload Flit）
空闲 Flit（Idle Flit）
NOP Flit

载荷 Flit 在发送方向由 DL 生成、在接收方向终止于 DL。空闲 Flit 和 NOP Flit 在发送方向由 PL 生成、在接收方向终止于 PL。

3.4.1 Flit 头

两字节的 Flit 头沿用 PCIe 定义中 DLP0、DLP1 的格式，其位置与 CXL 3.0 规范相同。Flit 头用于序列号与重放。参见 CXL 3.0 规范的 Table 6-5，以及 PCIe 6.4 规范的 Table 4-16、4-17。

Flit 头字段	Flit 头位位置	描述
Flit Usage[1:0]	[7:6]	000b：NOP/IDLE 010b：载荷 Flit 其他：保留
Prior Flit Type	[5]	PCIe 定义
Flit Usage[2]	[4]	见上
Replay Command[1:0]	[3:2]	PCIe 定义
Flit Sequence Number[9:0]	{[1:0], [15:8]}	PCIe 定义

表 3-1 Flit 头

3.4.2 数据链路层载荷（DLP）

PCIe 6.4 基础规范定义了 6 字节 DLP 序列用于承载 DLLP。DLP0、DLP1 包含序列号及其他用于标识 Flit 的信息。在 UALink 中，这些信息包含在 Flit 头里，其位置见图 3-4 载荷 Flit。Flit 头存在于所有 Flit 中。

载荷 Flit 不包含 PCIe 6.4 基础规范所定义的 DLP[5:2]。因为 UALink 基于信用的流控在 TL 层管理，无需与信用相关的 DLLP。

电源管理 DLLP 按 PCIe 定义使用。 当需要电源管理 DLLP 时，由 PL 生成 NOP Flit，并把相应的 DLLP 作为载荷的一部分插入，见图 3-6。空闲 Flit 也包含 DLLP，其 DLLP 类型置为 NOP2。

下表描述所支持的 DLLP 及其使用场景。定义见 PCIe 6.4 基础规范 Table 3.5。

类型	DL 载荷（Payload Flit）	NOP Flit	空闲 Flit（Idle）
NOP	否	是	是
NOP2	否	是	是
PM_Enter_L1	否	是	否
PM_Request_Ack	否	是	否
Link Management（L0p）	否	是	否

表 3-2 DLLP 类型

下面给出 PCIe 的 DLP 字节分配与 UALink 的 DLP 字节分配的对比：

                DLP0        DLP1        DLP2       DLP3        DLP4       DLP5
PCIe 定义      │ 序列号等   │ 序列号等   │ DLLP类型 │ DLLP类型  │ DLLP类型  │ DLLP类型
               │            │            │          │ 特定信息  │ 特定信息  │ 特定信息
UALink 载荷    │ FH 0       │ FH 1       │ —— 载荷 Flit 不含 DLP[5:2] ——
   定义        │（序列号等）│（序列号等）│
UALink NOP/    │ FH 0       │ FH 1       │ DLP2     │ DLP3      │ DLP4     │ DLP5
  Idle 定义    │（序列号等）│（序列号等）│ DLLP类型 │ DLLP类型特定信息…   │

图 3-3 DLP 定义

3.4.3 载荷 Flit（Payload Flit）

DL 载荷 Flit 如下所示。灰色部分对 PL 透明，由 DL 生成。PL 生成 Flit 头，然后在整个内容上计算 FEC 和 CRC。载荷 Flit 不包含 DLLP[5:2]。

与 PCI Express 6.3 共用的 FLIT 组成（CRC64, FEC）：

┌──────────┬──────────────────────────────┬──────────┬─────────┐
│ Flit 头   │ DL 载荷（对 PL 透明，DL 生成）│ CRC0..7  │ FEC0..5 │
│ FH0, FH1 │                              │          │         │
└──────────┴──────────────────────────────┴──────────┴─────────┘

图 3-4 载荷 Flit

3.4.4 空闲 Flit（Idle Flit）

空闲 Flit 由 PL 生成并消耗。灰色部分填 0x0，4 字节 DLLP 为 NOP2（按 PCIe 6.4 基础规范定义）。空闲 Flit 在 LTSSM 要求时生成，例如在 recovery.idle 状态下。

与 PCI Express 6.3 共用的 FLIT 组成（CRC64, FEC）：

┌──────────┬───────┬───────┬───────┬───────┬───────────────┬──────────┬─────────┐
│ Flit 头   │ DLLP2 │ DLLP3 │ DLLP4 │ DLLP5 │ 空闲 Flit      │ CRC0..7  │ FEC0..5 │
│ FH0, FH1 │       │       │       │       │ （填 0x0）     │          │         │
└──────────┴───────┴───────┴───────┴───────┴───────────────┴──────────┴─────────┘

图 3-5 空闲 Flit

3.4.5 NOP Flit

NOP Flit 不由 DL 生成——DL 总是发送载荷 Flit。

在电源管理协商（L1 进入和 L0p）期间，PCIe 6.4 把 DLLP 作为协议的一部分使用。当需要调度 PM 相关的 DLLP 时，PL 暂停发送载荷 Flit，插入带有相应 DLLP 载荷的 NOP Flit。

其他 LTSSM 状态和行为也要求 PL 生成 NOP Flit，这些 Flit 使用 NOP2 DLLP。

支持的 DLLP 类型定义如下：

NOP2
PM_Enter_L1
PM_Request_Ack
Link Management（L0p）

4 字节 DLLP 载荷承载在 NOP Flit 中，如下所示：

与 PCI Express 6.3 共用的 FLIT 组成（CRC64, FEC）：

┌──────────┬───────┬───────┬───────┬───────┬───────────────┬──────────┬─────────┐
│ Flit 头   │ DLLP2 │ DLLP3 │ DLLP4 │ DLLP5 │ NOP Flit       │ CRC0..7  │ FEC0..5 │
│ FH0, FH1 │       │       │       │       │               │          │         │
└──────────┴───────┴───────┴───────┴───────┴───────────────┴──────────┴─────────┘

图 3-6 NOP Flit

3.4.6 CRC 与 FEC

CRC 和 FEC 的计算与 PCIe 6.4 基础规范中的定义完全相同。

3.5 链路训练（Link Training）

链路训练必须遵循 PCIe 6.4 基础规范，本文注明的例外除外。

3.5.1 链路断开（Link down）

如果 UALink PL 进入链路断开状态，在固件通过写寄存器位使能该链路之前，LTSSM 不得退出 Detect 状态。每次链路断开都需要同样的操作。这提供了一个固件联锁（F/W interlock）：先完成系统级清理，然后才允许链路重新训练。

DL 也可以指示 PL 链路断开。在这种情况下，PL 通过 LTSSM 执行一次热复位（hot reset）。

3.5.2 替代协议协商

必须支持针对 UALink 的替代协议协商。替代协议协商见 PCIe 6.4 基础规范第 4.2.5.2 节。替代协议协商发生在 linkUp = 0 时的 Configuration（配置）状态。

3.5.3 L0

在 DL 请求数据速率变更之前，链路不得训练到 2.5 GT/s 以上。 只有加速器发起链路速率变更。由高层负责先发起向 32.0 GT/s、再向 PAM4 数据速率的速率变更——因为这会在这些数据速率上执行均衡（equalization）过程。该过程应在 TL Flit 通道上线之前完成。

3.5.4 均衡（Equalization）

当 TL Flit 通道在线时不应执行均衡，因为均衡过程期间 DL Flit 会被阻塞，这将导致高层超时。

均衡按照 PCIe 6.4 基础规范执行。一个例外是：ESM 数据速率可以编程为使用更长的均衡超时。

3.5.5 扩展速率模式（Extended Speed Mode, ESM）

扩展速率模式允许支持比 PCIe 6.4 基础规范定义的最高数据速率更高的速率。启用 ESM 时，训练序列中使用 64.0 GT/s 数据速率标识，从协议角度看其行为与 64.0 GT/s 相同。ESM 必须在链路训练之前启用并配置好 ESM 速率。 由系统管理负责确定所有加速器与交换机共同运行的 ESM 速率。

支持的 ESM 数据速率映射如下：

标称速率	无 ESM	104G ESM	112G ESM	120G ESM	128G ESM	线路编码
G1	2.5 GT/s	2.5 GT/s	2.5 GT/s	2.5 GT/s	2.5 GT/s	NRZ
G5	32.0 GT/s	32.0 GT/s	32.0 GT/s	32.0 GT/s	32.0 GT/s	NRZ
G6	64.0 GT/s	104.0 GT/s	112.0 GT/s	120.0 GT/s	128.0 GT/s	PAM4

表 3-3 ESM 数据速率

在多节点加速器系统中，所有链路必须配置为相同的 G6 ESM 速率。在上电和初始链路训练期间（以及某些错误情形下），各链路会以不同速率运行；一旦系统完成全部训练并投入运行，所有链路都应以相同的 G6 ESM 速率运行。

ESM 速率的超时必须支持在均衡（EQ）期间增加超时时间，且必须在系统中所有链路上配置为相同值。表中 1x 列为 LTSSM 默认设置。

超时项	1x	2x	4x	8x	16x	32x
phase 1 上游端口	12 ms	24 ms	48 ms	96 ms	192 ms	384 ms
phase 1 下游端口	24 ms	48 ms	96 ms	192 ms	384 ms	768 ms
Phase 2/3	48 ms	96 ms	192 ms	384 ms	768 ms	1536 ms
Phase 2/3	64 ms	128 ms	256 ms	512 ms	1024 ms	2048 ms
Recovery.speed	96 ms	192 ms	384 ms	768 ms	1536 ms	3072 ms

表 3-4 ESM 超时

3.6 电源管理（PM）

3.6.1 L1

必须支持 L1。

L1 进入遵循 PCIe 6.4 基础规范，例外是：当需要调度 PM DLLP 时，DL Flit 暂停发送、创建 NOP Flit，并把 DLLP 放入 NOP Flit 中。见 3.4.4 和 3.6.1 节。

L1 退出遵循 PCIe 6.4 基础规范。

3.6.2 L0p

应支持 L0p。L0p 遵循 PCIe 6.4 基础规范，例外是：当需要调度链路管理（Link Management）DLLP 时，DL Flit 暂停发送、创建 NOP Flit，并把 DLLP 放入 NOP Flit 中。见 3.6.2 和 3.4.5 节。

4 电源管理（Power Management）

电源管理基于 PCIe 6.4 基础规范。支持以下特性：

4.1 L1

必须支持 L1。不支持 L1 子状态，不支持 L1 ASPM。 L1 进入不是通过对端点的 PCIe 配置写事务（PCIe Configuration Write Transaction）发起的——UALink 不支持 PCIe 配置事务。

4.1.1 L1 进入

L1 进入的高层序列如下：

TL 发起链路断开（Link disconnect）；
TL 指示 DL 进入 L1；
DL 层协商进入 L1；
DL 指示 PL 进入 L1；
PL 层协商进入 L1；
PL 进入 L1。

4.1.1.1 事务层

事务层基于实现特定的判据发起链路断开。只有加速器可以请求链路断开。 链路断开必须在链路两端的事务层之间成功协商。一旦链路断开请求或 Ack 已发出，TL 不得再向 DL 发送任何 TL Flit。请求方 TL 指示其 DL 把 TL 通道下线。TL 链路断开的细节见 UALink 200G 规范第 5 章。

4.1.1.2 数据链路层

从 DL 的角度看，必须按顺序发生以下序列，使链路过渡到 L1：

TL 通道下线协商；
UART 通道下线协商；
L1 进入协商。

在通过链路状态变更协商 L1 进入之前，DL 必须先协商 TL 通道和 UART 通道下线（两者的确切顺序由实现决定）。这确保在 L1 进入之前，这两项服务都不再使用 DL。详见第 2.4.3.5 节。

当 TL 离线状态协商完成后，DL 在发送方向不得再接受来自 TL 的任何 TL Flit，发往 PL 的 DL Flit 中将不含 TL Flit 载荷。

当 UART 离线状态协商完成后，DL 在发送方向不得再接受任何 UART 数据，发往 PL 的 DL Flit 中将不含 UART 段。

DL 发送 DL 消息协商链路状态变更为 L1，见第 2.4.3.4 节。

协商成功结束时：

两端 DL 在发送方向都不得再接受来自 TL 的 TL Flit；
两端 DL 在发送方向都不得再接受来自 UART 的 UART 数据；
各 DL 指示其 PL 进入 L1，并停止向 PL 发送 DL Flit。

4.1.1.3 物理层

物理层的 L1 进入遵循 PCIe 6.4 行为。注意：PCIe 4 字节 DLLP 载荷出现在 NOP Flit 中，DLLP 永远不会成为载荷 DL Flit 的一部分。 当 DL 指示 PL 进入 L1 状态时，PL 在发送方向不得再接受来自 DL 的任何 DL Flit。PL 生成包含 DLLP 的 NOP Flit 并连续发送（NOP Flit 定义见第 3.4.5 节）。4 字节 DLLP 载荷的内容如下：

上游端口：NOP Flit 包含 PM_Enter_L1 的 DLLP 类型编码；
下游端口在收到 PM_Enter_L1 之前：NOP Flit 包含 NOP2 的 DLLP 类型编码；
下游端口在收到 PM_Enter_L1 之后：NOP Flit 包含 PM_Request_Ack 的 DLLP 类型编码。

当上游端口收到 PM_Request_Ack 时，PL 发送 EIOSQ（电气空闲有序集）并把其发送器置于电气空闲（Electrical Idle）。当下游端口判定链路已处于电气空闲时，也把其发送器置于电气空闲。

4.1.1.4 L1 流程图

下面的流程图展示了 L1 进入的第一阶段步骤：TL-TL 链路断开，随后是 TL 通道下线、UART 通道下线。UART 通道下线与 TL 通道下线流程相同，图中未画出。

加速器（下游端口, Downstream Port）      交换机（上游端口, Upstream Port）
      T=TL, D=DL, P=PL                        T=TL, D=DL, P=PL

1. 加速器阻止新 TL Flit 的发送，并向
   交换机发送链路断开（Link disconnect） ────▶
                                             2. 交换机阻止新 TL Flit 的发送
                                             3. 交换机确认链路断开
                                          ◀────
4. 加速器发送 DL 消息，请求 TL 通道下线  ────▶
                                             5. 交换机 DL 同意 TL 通道下线
                                             6. 交换机发送 DL 消息，确认 TL 通道下线
                                          ◀────
7. 加速器发送确认 DL 消息，确认 TL 通道下线 ────▶

        （对 UART 通道下线重复同样流程）

图 4-1 L1 进入（第 1 部分）

下面的流程图展示了 L1 进入的最后阶段步骤：DL 协商 L1 进入，随后是 PL 的 DLLP 协议。

加速器（下游端口, Downstream Port）      交换机（上游端口, Upstream Port）
      T=TL, D=DL, P=PL                        T=TL, D=DL, P=PL

8.  加速器发送 DL 消息，请求链路状态变更为 L1。
    DL Flit 从 D 层被阻塞                              ────▶
                                                       9.  交换机 DL 同意 L1
                                                       10. 交换机发送 DL 消息，确认
                                                           链路状态请求 L1。DL Flit 从 DL
                                                           被阻塞，PL 连续发送 NOP Flit
                                                    ◀────
11. 加速器发送确认 DL 消息，确认链路状态
    请求 L1。DL Flit 从 DL 被阻塞，PL 连续
    发送 NOP Flit                                      ────▶
12. 加速器连续发送带 NOP2 DLLP 的 NOP Flit
                                                       13. 交换机 PL 连续发送带
                                                           PM_Enter_L1 DLLP 的 NOP Flit
                                                    ◀────
14. 加速器连续发送带 PM_Request_Ack DLLP
    的 NOP Flit                                        ────▶
                                                       15. 交换机发送 EIOSQ，并把发送器
                                                           置于电气空闲（Electrical Idle）
16. 加速器发送 EIOSQ，并把发送器置于电气空闲

图 4-2 L1 进入（第 2 部分）

4.1.2 L1 退出

交换机或加速器都可以发起 L1 退出。 虽然 L1 退出在 TL 发起，但链路上的协议流程方向与 L1 进入相反。发起方 TL 告知其 DL 退出 L1 的意图，DL 再告知其 PL 退出 L1 的意图。

L1 退出的高层序列如下：

TL 请求 DL 退出 L1；
DL 指示 PL 退出 L1；
PL 经由 Recovery 从 L1 退出到 L0。

4.1.2.1 物理层

PL 按照 PCIe 6.4 基础规范退出电气空闲：先进入 Recovery，然后进入 L0。

4.1.2.2 数据链路层

数据链路层不协商 L1 退出——它是隐式的。各链路伙伴最初发送的 DL Flit 将是载荷 Flit，其中不含 TL Flit 或 UART 备选扇区。当 TL 请求时，数据链路层应协商 TL 通道上线——这确保未发起 L1 退出的链路伙伴已准备好恢复正常运行。请求方代理应请求由 DL 把 UART 通道上线。一旦 DL 完成 UART 通道上线的协商，DL 就可以把 UART 数据打包进备选扇区。TL 通道与 UART 通道上线的先后顺序由实现决定。

4.1.2.3 事务层

一旦 DL 完成 TL 通道上线的协商，TL 重新连接（re-connect）链路。

4.2 L0p

应支持 L0p。L0p 宽度变更的高层序列如下：

TL 指示 DL 通过 L0p 变更宽度；
DL 层协商通过 L0p 变更宽度；
DL 指示 PL 通过 L0p 变更宽度；
PL 层协商通过 L0p 变更宽度；
PL 通过 L0p 变更宽度。

4.2.1 事务层

事务层基于实现特定的判据发起 L0p 宽度变更。只有加速器可以请求 L0p 宽度变更。

4.2.2 数据链路层

当 TL 指示其 DL 变更链路宽度时，DL 按第 2.4.3.2 节所述与链路伙伴协商。假设宽度变更协商成功，发起方 DL（即加速器）指示 PL 变更宽度。

4.2.3 物理层

当 DL 指示 PL 变更宽度时，PL 使用 NOP Flit 中的链路管理（Link Management）DLLP 执行协商，机制与 PCIe 6.4 基础规范所规定的相同。当需要调度发送链路管理 DLLP 时，常规 DL 载荷 Flit 暂停发送，由 PL 插入带有链路管理 DLLP 的 NOP Flit。使用普通优先级（Normal Priority）L0p 请求。

—— 全文完 ——

翻译说明：

本译文基于《UALink 128G Data Link and Physical Layers Rev 1.0》（2025 年 7 月 27 日发布）PDF 全文翻译，章节编号与原文一致。
原文中的位图/流程图等矢量图形在译文中以文字化 ASCII 示意图重绘，字段、位位置与逻辑关系均按原文保留；阅读时可对照原文插图。
规范中的关键英文术语（Flit、Segment、Sector、LTSSM、ESM、L0p、decision pending 等）在首次出现时保留英文原词，便于对照 PCIe 6.4 / CXL 3.0 规范原文。
原文版权归 Ultra Accelerator Link Consortium, Inc. 所有，本译文仅供学习研究使用。

标签

#服务器 #GPU #AI