UCIe基础学习4：协议栈全景——三层栈与双连接

UCIe 协议深度精讲 · 第 04 篇 | 基准：UCIe 2.0
系列主线：20 篇 4 卷，一篇一个主题——是什么、为什么、怎么工作、怎么测、坑在哪

UCIe基础学习4：协议栈全景——三层栈与双连接

一、篇头速通

先钉住定义：UCIe 是封装内 die 间互连（die 即裸片，制造出来还未封装的单片电路）的分层协议栈，从上到下三层——Protocol Layer（协议层）承载四类协议（PCIe、CXL、Streaming、MTP），D2D Adapter（die 间适配层）把数据整理成固定长度的数据块（flit）并负责可靠性，PHY（物理层）按封装形态提供电气互联。物理连接分两路：sideband（边带，常开，干协商和调试）和 mainband（主带，跑数据）。三层之间还夹着两个标准接口：FDI 和 RDI。

本篇就是全景图：每层管什么、两个接口怎么衔接、双连接怎么分工、官方 KPI（关键性能指标）数字是多少。把这张图钉进脑子里，后面所有机制都能对号入座。

图：全系列 20 篇 4 卷导航，第 04 篇高亮（图源：自绘）

读之前先自查三条：

1. 你懂 chiplet 为什么拆、die 间互连的基本动机（不懂回第 1 篇速通）
2. 你知道 UCIe 是开放联盟标准、与 PCIe 的分工边界（不懂回第 3 篇）
3. 本篇是全景图——三层各自的细节是后续篇的事（Adapter 机制和两个接口的信号清单=第 9 篇、PHY=第 11-15 篇、Sideband=第 8 篇）

二、三层栈逐层看

任何协议栈设计本质上都在回答同一个问题：把"跑什么"和"怎么传"切开。UCIe 切得比 PCIe 更干净——协议层管跑什么，PHY 管怎么传，中间夹一个 Adapter 做翻译和质检。

图：UCIe 三层栈全景——Protocol / D2D Adapter / PHY 三层，FDI / RDI 两个接口，Sideband / Mainband 双连接（图源：自绘）

规范里配合一张官方的分层全景图（和上面那张自绘图画的是同一件事，官方视角更直观）：

图：UCIe 官方给出的分层栈与各层功能划分（图源：UCIe Spec 2.0）

Protocol Layer（协议层）：跑什么

协议层承载四类协议：

• PCIe：PCIe 基础规范定义的协议，Flit 模式、non-Flit 模式都支持
• CXL：CXL 规范定义的协议，缓存、内存、IO 三类语义都在里面
• Streaming：用户自定义协议的通用模式，PCIe/CXL 都不通告时它是默认协议
• MTP：管理传输协议（Management Transport protocol），管理网络报文的传输机制

设计上的关键决策，是把协议特性和传输格式解耦：UCIe 提供好几种 Flit 格式，协议层选哪种格式来装数据是另一回事——比如 PCIe non-Flit 模式的包，规范允许用 CXL.io 的 68B Flit 格式来装。格式跟协议松绑，组合空间就大了。

顺带排个雷：CXL 的 RCD/RCH/eRCD/eRCH 这几类内存缓冲变体，在 UCIe 上不支持。做 CXL 内存场景选型时先记住这条。

D2D Adapter（die 间适配层）：中间人

Adapter 是 UCIe 栈里最有"软件味"的一层，职责有四条：

• flit 化传输：把协议层的数据整理成固定长度的数据块往下送，该加的头、该加的校验都由它管
• 可靠性：raw BER（原始误码率，bit 在物理通道上翻转的概率）高于 1e-27 的档位，提供 CRC（循环冗余校验）加 Retry（重传）；低于这个门限可以退化成轻量校验
• 多协议复用：同一时刻跑多个协议（比如 CXL 的 io/cache/mem 并存）时做仲裁和选路，术语叫 ARB/MUX（仲裁/多路复用）
• 链路状态与参数协商：跟对端的 Adapter 交换能力、定最终配置，再把结果通知协议层

这里有一个硬约束，也是理解 UCIe 的灵魂：主数据通路上的逻辑必须尽量少。时延预算是 2ns 量级，数据路径上多放一个转发环节、多存一拍数据，预算就超了。所以直连场景（封装内两颗 die 面对面）主数据通路没有 credit 流控——转发时钟把两侧锁成同频，产出的速度就是消费的速度，没有缓冲池，也就不存在"缓冲满"的问题。

拿它跟 PCIe 的数据链路层（Data Link Layer，缩写 DLL）比一下，层的位置很像，骨子里完全不同：

一句话：Adapter 是精简版 DLL 加协议复用加协商的三合一，还在时延上做了极限压缩。

PHY（物理层）：怎么传

PHY 是三层里唯一"硬件味"十足的一层，管电气互联：模拟前端（AFE，信号的发射接收电路）、微凸块（bump，die 和封装之间的小金属凸点）、时钟、建链训练、lane（数据线）修复。逻辑上它分两块：逻辑 PHY 管训练状态机、字节到 lane 的映射、修复动作；电气部分管收发器电路和电参数。

图：规范给出的 PHY 三个子组件——逻辑 PHY、电气部分与 sideband，训练、映射、修复都在逻辑 PHY 里（图源：UCIe Spec 2.0）

这里要拎清一个点，也是网上文章翻车最多的地方：UCIe 的 PHY 是并行转发时钟架构，UCIe-S 和 UCIe-A 都没有 serdes PHY。数据线一根线一个 bit，几十上百根并排走，时钟线跟数据线一起发，接收端拿转发时钟直接采样，不需要 serdes（串行器/解串器，把信号串成一对差分线跑高速、接收端再用 CDR 从数据流里抠时钟）那套。serdes 这个词在 UCIe 语境里只出现在对比场景——UCIe 替代的就是 PCIe 这类 serdes 架构。谁要是跟你说"UCIe-S 走 serdes"，基本可以判断他没读过规范。

并行架构的账：电路简单、时延低、能效好；代价是线多、距离近——die 间走线就封装内那点长度，出了封装得靠 Retimer（中继器）接力。

建链训练也跟 PCIe 不是一套：UCIe 没有 PCIe 的 LTSSM（链路训练状态机），它的训练状态机叫 LTSM（Link Training State Machine），挂在逻辑 PHY 里，由 sideband 驱动的 MBINIT（主带初始化训练）流程推进。顺序是 sideband 先起、再训 mainband、最后 Adapter 初始化，逐层拉起。

三、两个接口：FDI 与 RDI

三层之间不是拿胶水随便粘的，规范定义了两个标准接口，这是"开放"二字的落点。

• FDI（Flit-Aware D2D Interface，Adapter 面向协议层的接口）：在 Adapter 和协议层之间，走 flit 化数据，协议感知——Adapter 把协商好的运行模式通过 FDI 通知协议层，协议层按这个模式收发；flit 里哪些位归哪层填，都在这个边界上分清
• RDI（Raw D2D Interface，Adapter 面向 PHY 的接口）：在 Adapter 和 PHY 之间，走 raw bit流，协议无关——PHY 不关心上面跑的是什么协议，它只负责电气传输、训练、加扰这些体力活

记起来很省事：F 在上（协议侧），R 在下（电气侧）。打个比方：FDI 是货单交接，双方都懂货；RDI 是传送带交接，只管搬，不认货。

接口标准化值得多说一句，因为这是生态思维的体现：三层被接口切开，A 厂的协议层、B 厂的 Adapter、C 厂的 PHY，只要对上接口握手就能拼到一颗封装里，集成成本低、上市快。对验证工程同样重要——接口固定，总线功能模型（BFM）好开发，片后互操作测试的代价能压下来。没有这两条标准接口，UCIe 就退化成几家大厂内部的私有互连，开放联盟的意义就没了。

四、双连接：Sideband 和 Mainband

任何互连系统都有数据面和控制面。UCIe 的做法是把控制面物理隔离出来，单独走一路常开的低速通道，这就是"双连接"。

Sideband（边带）：常开的后门

每个模块一组 sideband，挂在辅助电源的常开域上——mainband 没起来、甚至主电源还没上，它也活着。构成很简单：

• 每个方向 1 根转发时钟线 + 1 根数据线
• 时钟固定 800MHz，跟 mainband 速率完全无关
• 先进封装配一对冗余时钟/数据线，坏了能顶上

sideband 干三件事：参数交换（谁支持什么速率、什么宽度、什么协议，都在这条路上谈）、寄存器访问（调试和合规测试全靠它）、建链与电源管理协调。

我的判断：sideband 常开这个设计，本质是给链路留一扇永远开着的后门。干过调试的都懂，链路起不来时最绝望的是没有任何手段去看里面发生了什么。sideband 保证 mainband 烂成什么样，寄存器都还能读——这个能力在硅片调试阶段值回票价。

Mainband（主带）：主数据通路

mainband 才是真正跑数据的路。每个模块由四样东西组成：转发时钟、data valid（数据有效信号，告诉接收端这一拍算数）、track（跟踪信号，接收端拿它做运行时校准，补偿电压温度漂移对采样相位的影响）、加 N 条数据 lane。

宽度按封装形态分：

• 先进封装（2.5D，die 并排贴在硅中介层上）：x64（64 条数据 lane）或 x32（32 条），另配 4 根修复线
• 标准封装（2D，die 平贴传统基板）：x16（16 条）或 x8（8 条），没有修复线；x8 只允许单模块配置，主要给出厂前预键合（pre-bond，die 还没贴到封装基板上时）测试用

图：规范给的先进封装单模块结构——x64 数据 lane + 时钟/valid/track + 4 根修复线 + sideband（图源：UCIe Spec 2.0）

图：标准封装单模块结构——x16 数据 lane，时钟/valid/track，无修复线（图源：UCIe Spec 2.0）

lane 在 mainband 里按模块（Module）组织。模块是模拟前端结构设计的原子单位——版图、功耗、面积都按一个模块的规模来算。想加带宽就并联 2 个或 4 个模块，但共享一个 Adapter 的模块必须同速率同宽度，这是硬约束。

五、模块配置与 Retimer 场景

配置形态

• 单模块：先进封装 x64/x32，标准封装 x16/x8。多个单模块实例各自带专属 Adapter 时互相独立——两对 die 各跑各的速率和宽度，互不绑架
• 多模块：2 个或 4 个模块共享一个 Adapter，喂同一份协议数据，必须同速率同宽度，用途是带宽扩展。这个"同速同宽"约束是协商阶段最常出问题的地方——协商结果跟通告能力对不上，建链直接失败
• Sideband-only：标准封装允许只带 sideband 的配置，1/2/4 个端口，给测试或 manageability（可管理性）用。这条路的语义是：不跑数据，只挂管理面和调试面

图：规范给的两模块共享一个 Adapter 的示例结构（图源：UCIe Spec 2.0）

图：规范给的 Sideband-only 配置示例——只挂管理面，不跑数据（图源：UCIe Spec 2.0）

Retimer：出了封装的接力

die 间互连本来跑的是封装内几毫米，要跨封装、上机架，就得用 Retimer（中继器）接力，介质可以是光、电缆、毫米波。Retimer 是存储转发节点，数据进来要缓冲、要重新计时，可靠性不能指望两端的 die 直接管，规范给了三条路：

图：规范给的 Retimer 连接全景——两颗 die 各带一个 Retimer，中间是 off-package 互连（图源：UCIe Spec 2.0）

1. 隧道底层协议的原生 FEC（前向纠错）/CRC（Raw 格式场景）：外部互连的错误模型符合底层协议（PCIe/CXL）的假设时，把协议的原生比特原样隧道过去，纠错和重传由协议层自带的机制管。前提是外部互连的误码特性得达标，不然原生纠错扛不住
2. Retimer 自带 CRC + Retry：整条链路变成三段独立链路——die 到 Retimer、Retimer 到远端 Retimer、远端 Retimer 到对端 die，每段各自做独立确认（ACK/NAK，收到对的回确认、收到错的要重传）。三段各管各的账，任何一段出错不影响另外两段的可靠性记账
3. Retimer 自备 FEC，复用底层 CRC/Replay：纠错码自己定（替换或叠加原生 FEC），校验和重放机制借用底层协议内置的那套

为什么 Retimer 场景要多一套 credit 流控

直连场景没有流控，理由前面说过：转发时钟同步、无缓冲、无溢出条件。Retimer 场景必须加，因为它是存储转发节点，规范要求每个 Retimer 必须实现接收 buffer（缓冲），buffer 就有被灌满的风险。所以 die 到 Retimer 这个方向要做 credit 流控——credit 就是发送额度，接收方给发方一个额度代表"我这还能收多少"，发一块扣一块；1 个 credit 对应 256B 数据（含 FEC、CRC 等开销），die 手上没有 credit 就不许发。credit 返回复用在 valid 信号上，不占额外带宽。反向（Retimer 到 die）在 Adapter 层不流控。

六、KPI：官方钉死的数字

UCIe 是少数把性能目标直接写进规范正文的互连标准。白皮书开篇就强调：一份带实打实 KPI 的规范，是健康生态的前提。下面的数字一律以 Spec 2.0 原文为准。

先说带宽密度：沿 die 边缘每毫米能挤出多少 GB/s（速率单位 GT/s 即每秒十亿次传输）。UCIe 的带宽是"贴边堆"出来的，这个指标最能说明问题：

表里基准是 bump pitch（微凸块间距）先进封装 45µm、标准封装 110µm；先进封装 x32 的带宽密度是 x64 的一半。

能效，单位 pJ/bit（每传 1 bit 消耗的皮焦耳能量），统计范围是从 FDI 到 bump 再回到 FDI，Adapter 和 PHY 全部电路都算进去：

注意标准封装跑高速的代价：32 GT/s（0.7V）是 1.25 pJ/bit，先进封装对应档 0.6——差一倍多。这就是 2D 用宽松 bump pitch（100-130µm）换成本、2.5D 用密集 pitch（25-55µm）换能效的差价，选型时这笔账要算清。

时延目标：≤2ns，从 FDI 到 bump 往返，16 GT/s 基准。

3D 垂直堆叠是另一本账：带宽密度 4000 GB/s/mm²（9µm pitch）、能效 0.05 pJ/bit（0.65V）、时延 ≤125ps。1ns 是十亿分之一秒，125ps 是它的八分之一——die 摞起来才能拿到这种账。

拿 1.0 时代的官方白皮书对照：数据率、宽度、pitch、信道可达距离（channel reach）、带宽密度（28-224 / 165-1317）、能效目标（0.5 / 0.25 pJ/b）、低功耗进出时间、时延、可靠性 FIT，全部逐项一致——1.0 到 2.0 的 KPI 零变化，2.0 的增量只在 UCIe-3D 这一列。对选型的人，这条信息很值钱：1.0 时代定的账，2.0 没改口。

跟 PCIe 的 serdes 架构对比，白皮书给了一组硬数字：

• 能效：PCIe 那类 serdes PHY 现在约 10 pJ/b，UCIe 最多低 20 倍——标准封装 0.50 正好是 10 的 1/20，先进封装再压一半到 0.25
• 带宽密度：先进封装 1300+ GB/s/mm 量级，大约是最高效 PCIe serdes 的 20 倍
• 密度弹性：bump pitch 从 45µm 收紧到 25µm，带宽密度还能再升约 3.24 倍
• 低功耗进出：serdes 那类链路进出低功耗要多个微秒，UCIe 按速率档是 0.5ns（≤16 GT/s）到 0.5-1ns（≥24 GT/s），配合空闲关断能省 90% 以上的功耗
• 可靠性：FIT（Failure In Time，1 FIT=10^9 小时发生 1 次失效）目标 0 < FIT << 1，期望在 1e-10 量级——封装内互连把可靠性目标定得极高

版本口径：2.0 基准、1.0 基线、3.0 边界

写 UCIe 绕不开版本问题，先把版本基线定准：

• UCIe 1.0：规范文件落款 2022 年 2 月 17 日，联盟 2022 年 3 月 2 日官宣面世。两个日期差不到两星期，网上常混着写，认准落款日和公开日两个时间点。白皮书（2022 年）的 KPI 表就是 1.0 的基线
• UCIe 2.0：2024 年 8 月 6 日发布，本系列全篇基准。本篇第六节的 KPI 数字全以 2.0 为准；1.0 到 2.0 的 KPI 零变化，增量在 UCIe-3D 列和协议模式的细化上
• UCIe 3.0：已于 2025 年 8 月发布。本系列不引用 3.0 的内容——3.0 的技术细节还没逐条对着原文核对过，写数字要对读者负责。看别人的 UCIe 文章也先认版本：2.0 和 3.0 的数字混着写的大有人在

七、三张表：照着干活

故障模式：

测试方法：

判断依据：

八、文末声明

本文技术数据主要依据 UCIe Spec 2.0（2024-08）与 UCIe 官方白皮书（2022）；UCIe 3.0 已于 2025-08 发布，本文不涉及 3.0 内容。

系列首发：CSDN「UCIe 协议深度精讲」| 基准 UCIe 2.0
数字均以 UCIe Spec 2.0 为准，错误欢迎评论区指出，勘误会更新在文末。
图片版权归 UCIe Consortium，仅用于技术学习交流。