UCIe与Chiplet互连：从协议栈到封装实战解析

芯片行业这几年最热的话题，从“多少纳米”逐渐转移到了“怎么拼”。Chiplet这个概念喊了好几年，从PPT变成了AMD、Intel、英伟达这些大厂的真实产品，但很多人忽略了一个比工艺问题更卡脖子的环节：die与die之间到底怎么通信。没有一套统一的互连标准，每个厂商各玩各的，Chiplet生态就永远只是巨头们的“私人订制”。UCIe（Universal Chiplet Interconnect Express）就是冲着这个痛点来的，也是目前产业界认可度最高、落地速度最快的Chiplet互连标准。这篇文章我会从协议栈、电气信号、封装选型、版本演进这几个维度把它拆开揉碎，顺便带上一些我在实际项目里踩过的坑和排查经验，希望能帮到正在做chiplet方案选型、或者刚接触UCIe的硬件工程师、芯片架构师和学生。

1. 先搞明白Chiplet为什么需要一套“公共互连标准”

1.1 从单芯片到Chiplet的必然性

要理解UCIe的价值，先得回到Chiplet本身。传统SoC走的是“单片集成”路线，把所有功能模块都放到一颗die上，工艺节点越做越小，芯片面积越做越大。但单纯靠着缩小晶体管尺寸已经很难持续提升性能了，物理极限和成本压力都摆在那里：10nm以下的先进制程，每片晶圆的采购成本、设计费用、掩膜费用都高得惊人，而且die面积越大、良率越低。一旦面积超过光刻机的reticle极限，单片方案直接做不出来。

所以产业界换了个思路，把一颗大芯片拆成若干个小chiplet，用不同的工艺分别制造，再通过先进封装把它们拼在一起。CPU、GPU、AI加速器、IO、内存控制器这些模块，谁该用先进工艺、谁可以用成熟工艺，分开选择。这样做的直接好处有三个：第一，每个die的面积小，良率上去了，成本降下来；第二，不同功能可以采用不同工艺节点，性能与成本达到最优化；第三，可以复用成熟的设计模块，做衍生产品时不用整颗芯片从头流片。

这个思路在处理器领域已经被验证了，典型代表就是AMD的EPYC服务器芯片，把逻辑Die和IO Die分离，设计灵活性强了很多。Intel、英伟达、还有国内一些AI芯片团队也都在往这个方向走。可以看出，Chiplet不是一种“可选的未来”，而是已经落地的现在。

1.2 互连标准为什么是最大的拦路虎

但“拆开”容易，“拼起来”难。Chiplet把一颗SoC拆成了多个die，那么这些die之间怎样高速通信，就成了决定成败的关键问题。

最简单的方案是每个团队自己搞一套私有并行互连，今天做CPU的时候可能没问题，但如果想在不同供应商之间混搭chiplet，或者想从第二家采购替代模块，就傻眼了。没有统一标准，就没有通用接口，不同厂商的die之间的数据通路、协议握手、电气特性全都不一样，谁也连不上谁。

这个东西其实特别像USB和PCIe之前的外设世界。早年打印机、鼠标、键盘、网卡，每个设备都有自己的接口和协议，你买个新外设得先看自己电脑支持不支持。后来USB出现，把所有外设统一到一套标准下，整个生态才真正爆发。Chiplet产业也需要一个“USB时刻”，一套插上就能用的通用互连规范。

而UCIe正是承担这个角色的候选者。它由Intel在2022年3月率先提出，包含最初的高带宽die-to-die互连方案，后来推进到UCIe联盟，由全球多家公司共同维护，这让它从一开始就不是某一家公司的私有协议，而是一个开放的行业标准。它的目标也很明确：定义一套从物理层到协议层的完整互连栈，让任何两个厂商生产的chiplet，只要符合UCIe规范，就能在同一个封装里高速、可靠地通信。

2. UCIe协议栈拆解：三层结构分别管什么

UCIe之所以叫“协议栈”，是因为它不是一个单一层的标准，而是从上到下分了多层。理解这套分层逻辑，是读懂所有UCIe细节的基础。

2.1 物理层：连接的最底层物理载体

物理层是UCIe互连里最贴近硅片的一层。它的任务非常朴素：负责把0和1变成真正的电信号，通过封装基板上的走线传输到对面die，再把接收到的电信号还原成0和1。

UCIe物理层包含三个子层：电气层、物理层逻辑和物理层侧带信号。电气层处理的关键内容有：信号的驱动电压、终端阻抗、时钟方案、接收灵敏度这些模拟参数；物理层逻辑处理的是链路初始化、训练、状态切换和位宽协商这些数字逻辑；物理层侧带则负责低速的配置、控制和状态信息传递。三者配合，才能让一条link从静态变成一条能跑数据的通路。

值得注意的一点是，物理层从定义上就要支持标准封装（Standard Package）和高级封装（Advanced Package）两种场景。这两种场景下的走线长度、信道损耗、几何尺寸差别非常大，物理层的电气参数也会有所不同。但好消息是，在上层协议看来，这些差异被全部屏蔽掉了，你跑的是标准封装还是高级封装，协议层根本不关心。

2.2 Die-to-Die适配器：让不同协议“说同一种话”

适配器层（Die-to-Die Adapter）是UCIe最核心的一层，正是它让“标准化”真正落地。它的工作概括起来就是：把上层各种不同的协议数据，转换成统一的格式，通过物理层发出去；接收端再做反向转换。

为了统一各种协议，UCIe定义了一种通用的数据通道格式，叫做RDI（Raw Die Interface）。上层协议无论跑的是PCIe、CXL还是自定义的流协议，数据进入适配器层后，都会被切片打包成RDI格式的数据包，再加上必要的流控和重传信息，往下交给物理层。这样做相当于把“快递包裹”统一成了标准纸箱，不管里面装的是什么东西，箱子规格全都一样，运输系统就不用为每种货物设计一套装载方案。

在可靠性方面，适配器层引入了CRC校验和重传机制。物理层上的并行走线再快，也难免受到封装基板上的噪声、串扰、信号反射的影响，偶尔出现bit错误。如果直接把这些错误数据交给上层，PCIe、CXL这种高性能协议根本没法接受。UCIe的做法是在适配器层做非常轻量的链路级保护，发现CRC错误就请求重传，最大程度保证上层的“干净”体验。

2.3 协议层：面向PCIe/CXL/流协议/自定义协议

协议层是UCIe栈中最接近业务的一层，它决定了一整条链接“承载的是什么样的话”。目前UCIe联盟官方定义了三种协议：PCIe、CXL，以及UCIe流协议（Stream Protocol）。

PCIe和CXL是大家已经很熟悉的板卡/系统级互连协议，它们被搬到chiplet互连场景里，意味着一个系统中的PCIe或CXL资源可以“穿透”到另一个chiplet上。比如你有一颗CPU chiplet和一颗内存控制器chiplet，CPU侧跑CXL协议，经过UCIe互连，内存控制器chiplet看起来就像挂在CPU本地的一个CXL设备，驱动模型完全不用变。

流协议（Stream Protocol）是UCIe独有的东西，它不绑定任何电子系统现有的协议栈，而是直接支持自定义数据包收发。它适合场景是：两个die之间要跑私有加速器协议、自定义的数据包，或者特殊格式的流式数据，不想套PCIe/CXL的框架。这种灵活性让UCIe不至于被现有标准限制住，也为不同公司之间合作预留了空间。

整理一下这三层各自的职责，看这个对照关系会更清楚：

3. 关键信号与电气特性：UCIe到底“走什么线”

很多工程同行问我，UCIe到底是串行还是并行？用没用到差分信号？时钟是转发还是内嵌？这些问题非常实际，因为直接决定了封装基板怎么走线、PCB Layout注意什么。我也顺便把最近的网络热词“ucie采用差分信号吗”一并说透：答案是明确的，UCIe的数据lane、侧带信号，都是差分信号。

3.1 主数据Lane——差分对与调制方式

UCIe的每条主数据lane，收发方向各有一对差分信号。发送方向有TX差分对，接收方向有RX差分对。为什么要用差分对而不是单端信号？核心原因有两个：一是抗共模干扰能力强，外部噪声同时耦合到正、负信号线上，但两个信号相减之后噪声被抵消，信噪比更好；二是差分信号产生的EMI比单端小，这对Chiplet这种密集封装场景非常重要，毕竟die间距很近，走线也密集，信号之间的干扰控制是第一优先级。

UCIe 1.0中标准封装的lane速率可达4~32GT/s，并且支持双倍数据率（DDR）机制，也就是说在不额外增加时钟频率的前提下，每个时钟周期传输两次数据。加上该机制折算下来，每lane最大等效吞吐量可以达到64Gbps，方向分开独立工作，所以链路是全双工的。

调制方式上，标准封装默认使用NRZ（Non-Return-to-Zero）信号，一比特一个电平周期。在高级封装场景中，可以选择PAM4调制，用四种电平来表示两位数据，同等符号率下带宽翻倍。但PAM4的代价是信号电平间距变小，对噪声和信道损耗更敏感，功耗也更大。实际选型时，常规链路用NRZ就足够，只有在带宽密度压力很大时才需要考虑PAM4。

3.2 时钟方案：转发时钟与嵌入式时钟

UCIe标准中同时定义了两种时钟传输方式：转发时钟（Forwarded Clock）和嵌入式时钟（Embedded Clock）。

标准封装场景下，数据走线与转发的时钟信号一起从发送端送到接收端，接收端用这个时钟去采样数据。这种方式实现简单、延迟低，但对线长的等长控制要求很高，时钟和每根数据线之间的延迟偏差必须在设计允许范围内。如果时钟和数据到达接收端的时间错开了，采样窗口就会变小，误码率上升。

高级封装场景下，因为走线更短、信道质量更高，UCIe支持嵌入式时钟方案。也就是不在物理上单独传一路时钟，而是接收端通过CDR（时钟数据恢复）电路，直接从数据信号中恢复出时钟来。这条路省去了额外时钟线，节省了布线资源，但也对接收端的电路复杂度提出了更高要求。另外一个相关信号是CMN（Common Clock）信号，它主要用于高级封装场景，传递全局时钟和部分系统管理信息。

3.3 边带信号与系统管理信号

除了高速数据lane之外，UCIe还定义了一套低速的边带信号（Sideband），用于链路建立、配置、中断和状态上报。这套sideband本身也是差分信号，采用串行低速接口，常见实现会兼容I3C基础规范。它的速率不高，但承担着“启动顺序靠它、异常状态靠它”的任务，是整个链路先活起来的第一步。

调试和管理方面，UCIe支持通过JTAG接口访问die内部调试/测试逻辑，方便生产测试和后期固件诊断。总的来看，UCIe的信号体系可以整理成下面的表格，工程做管脚规划时能直接参考：

3.4 并行还是串行？UCIe的信号模式辨析

这个问题经常会出现在第一次接触UCIe的工程师嘴里。严格来说，UCIe既不是纯串行、也不是传统意义上的大规模并行。它更像是一个“并行差分总线”：几十条lane并行工作，每条lane用差分对承载数据信号。比起PCIe那种高速串行的“一条lane一路数据”，UCIe更像是把一组差分信号同时布在基板上。

这种方案的优势是延迟低、带宽密度高。Chiplet互连场景是die之间短距离通信，省去了传统串行链路里“并行转串行、再在接收端串行转并行”的编码/解码开销，极大地降低了端到端延迟。但代价也明显：需要更多引脚，layout复杂度更高，对基板的走线能力提出了很高要求。这也是为什么UCIe要与不同的封装类型配套——带宽密度和布线难度是一个需要权衡的硬币两面。

4. 两种封装场景：标准封装与高级封装的选型逻辑

UCIe从设计之初就考虑了不同封装形式的差异，把应用场景分为标准封装和高级封装。很多工程师刚看datasheet的时候容易被这两个词弄糊涂，其实它们分别对应不同的成本和性能档位。

4.1 标准封装：兼容现有PCB生态的务实选择

标准封装场景对应的物理介质是普通有机基板（比如常见BT树脂基板）上的走线，类似我们熟悉的BGA封装内部的走线形态，但也可以理解为“多个die封装在同一块基板上的场景”。因为走线可以直接沿用现有PCB制造能力，对工艺要求不高，成本相对可控。

标准封装模式下走线较长、线宽较大，信道的插入损耗相对于高级封装要大一些，所以UCIe物理层的电气参数会相应拉低一些速率上限，典型速率在4~32GT/s范围内，默认NRZ调制，最大支持32条lane。这种模式适合大多数商用Chiplet场景：一颗逻辑chiplet + 一颗IO chiplet封装在同一个基板上，或者多颗die以2.5D方式摆在普通硅转接板上，带宽跟得上，成本又能压得住。

4.2 高级封装：追求更高带宽密度的极限方案

高级封装场景指的是采用硅中介层、更高布线精度的2.5D/3D封装技术，最典型的就是CoWoS、InFO-LSI这一类平台。这种封装的走线间距小、信道长度极短、插入损耗低，可以让信号跑得更快，布线密度也更高。

在高级封装中，UCIe支持的lane数最多可以达到64条，每lane数据速率范围为2~16GT/s，并且允许选择PAM4调制。以同样的符号率算下来，PAM4可以将等效吞吐翻倍，所以高密度带宽场景下优势非常明显。典型的落地市场是AI训练芯片、HPC处理器：需要GPU/AI加速chiplet与高带宽内存控制chiplet之间以最低延迟、最高吞吐通信，用高级封装+UCIe互连在技术上很合适。

4.3 一个带宽估算实例

工程上最常被问的问题是：一条UCIe链路到底能提供多大带宽？我们来做一个实际估算，把算法理顺。

假设我在一个AI加速器项目里，选了标准封装方案，32条lane跑满，每lane最高速率32GT/s，同时UCIe启用了DDR双沿采样。那么换算关系是：

单lane等效速率 = 32GT/s × 2（DDR）= 64Gbps
单向总带宽 = 32 lane × 64Gbps = 2048Gbps = 2Tbps
全双工总带宽 = 单向总带宽 × 2 = 4Tbps

这个数字是挺惊人的，一个die对外窥探“2T发送、2T接收”的互连能力。换成实际产品参考：这足以把一整块高端GPU裸die的内部带宽需求支撑到非常充裕的程度。当然，实际可用带宽还会受到协议层开销和流控机制影响，但物理通道本身的量级确实已经拉得很满了。

5. UCIe版本演进：从1.0到3.0在路上

UCIe不是一成不变的标准，从1.0到现在的3.0方向，演进节奏相当快。关注版本演进，可以帮助你判断当下该押注哪一代IP，也避免选了一个很快被淘汰的旧实现。

5.1 1.0到1.1：把规范交给联盟之后

2022年3月Intel发布UCIe 1.0，同年8月正式移交给UCIe联盟管理。1.0定义了完整的物理层、适配器层和协议层，支持PCIe和CXL协议映射，同时提供流协议支持。这一版的主要贡献是从0到1，把Chiplet互连从各自为战的私有协议拉到了一个统一的框架之下。

随后推出的1.1版本，在1.0的基础上主要做了规范澄清、封装参数补充和一致性测试方法完善。这一版之后，不同厂商的UCIe PHY IP之间有了真正意义上的互操作验证基础，也意味着第三方IP厂商可以放心推出兼容方案。如果预算有限，直接采用符合UCIe 1.1的成熟IP，在当前完全没有问题，因为1.x版本在物理层的基本协议栈框架上是持续兼容的。

5.2 2.0：从单个die互连走向chiplet网络

UCIe 2.0是在2024年正式宣布的方向，它把视角从“两个die之间的一条链路”拉高到了“封装内多个die组成的互连网络”。这一版提出了UCIe Connection概念，可以理解为整个chiplet互连结构的管理中枢，负责维护多个die之间的连接关系、拓扑切换和生命周期管理。

2.0的意义相当于从“清晰的一根网线”走向“家里整个Wi-Fi网络的统一管理”。如果只做一颗小尺寸chiplet，对2.0的需求并不急迫；但如果做多die大型处理器，多个die之间需要全面互联，2.0管理的对象就不是单条链路，而是整个互连矩阵。这种机制对于可组合的可扩展处理器、数据中心的异构算力池来说，价值极大。

5.3 3.0及未来方向

关于UCIe 3.0，业界关注热度一直在涨，从目前联盟roadmap释放的信息来看，3.0的重点会继续围绕更复杂的chiplet网络化、可组合性以及更广的物理介质支持展开。比如把互连从“点对点”扩展为“多die可组网的架构能力”，把Chiplet从“一对一的拼图”变成“可以按需插拔组合的系统级方案”。

具体新增特性以官方正式发布的规范为准。对工程团队来说，现在做技术选型时不太需要担心3.0会让已有方案作废，UCIe联盟对后向兼容一直有明确要求，物理层的基础设计大概率保持延续。更值得关注的反而配套生态，比如封装设计工具的DRC支持、一致性测试工具的更新，都会跟着版本一起迭代。

6. 实际落地与生态：谁在用UCIe，怎么用

标准立起来之后，真正的考验是落地。这一节聊聊我观察到的应用场景、生态竞争状况，以及自己在接触UCIe设计流程时的一些经验。

6.1 典型应用场景：AI加速、HPC和SoC重构

AI加速器是目前UCIe迁移最积极的场景。算力越来越吃紧，单颗大die的良率和封装成本都扛不住，于是把AI计算核心、SRAM阵列、IO控制分别做成独立chiplet，再用UCIe连起来。因为AI工作负载的特点是大量规则数据传输，对带宽要求极高，UCIe的并行差分总线方案可以提供低延迟、高吞吐的互连。

HPC高性能计算领域，UCIe也在逐步取代一部分私有die-to-die接口。多颗计算chiplet + 多颗内存chiplet的组合模式，可以通过UCIe做到模块化扩容。如果客户需要半定制配置，直接把不同数量的chiplet“贴”到同一块基板上就行，硬件改版周期大幅缩短。这个玩法对服务器整机厂商非常有吸引力，因为它让SKU变得极具弹性。

传统SoC厂商则更关注UCIe带来的跨工艺复用能力。一个基板上的CPU核、ISP模块、NPU模块可以是不同团队、不同工艺节点甚至不同foundry生产的，只需要遵循UCIe物理层规范，就可以集成为一颗功能完整的系统级封装。这彻底打破了“一颗SoC必须整体流片”的枷锁。

6.2 UCIe与其它互连方案的关系

Chiplet互连领域并不是只有UCIe一个玩家。开放领域的BoW、ODSA等组织早些年也做过一些探索。但随着UCIe联盟的阵容越来越完整，包含国内外几乎所有头部半导体厂商在内，工业界实际上已经形成了向UCIe收敛的共识。

这并不是说其他方案一无是处，而是UCIe在生态丰富度、协议栈完整度、以及兼容PCIe/CXL这些存量标准上，天然拥有更强的吸引力。尤其对同时做板卡和芯片的厂商来说，UCIe可以做到板级PCIe资源和封装内die互连的协议打通，省掉大量软硬件适配工作。所以我个人建议中小团队评估Chiplet互连方案时，首选UCIe成熟IP，除非有极端定制需求才去考虑自研或引入其他小众方案。

6.3 落地时需要关注的器件与EDA工具链

UCIe虽然在协议层是标准化的，但实际落地过程依然要面对不少设计工具和工艺适配问题。我的经验是，至少要关注三块配套内容：

第一，PHY IP选择。目前主流IP厂商都有UCIe PHY IP，但每个IP在lane数、速率范围、封装类型支持上不完全一致。做选型时一定要用IP供应商提供的参考封装设计规则去跑一次真实仿真，别只看数据手册里的最大速率。

第二，EDA封装设计工具。UCIe对走线等长、阻抗匹配、回流路径有明确约束，封装设计工具必须支持相应的物理规则检查。后端团队如果临时用通用PCB工具去画UCIe互连，很容易在DRC阶段跑出一堆等长和阻抗问题。

第三，一致性测试。UCIe联盟推动的一致性测试程序，是验证两个来自不同厂商的die能否真正互通的唯一标准。量产前一定要在含实际封装的测试平台上跑过合规性验证，不要只在系统级仿真里看波形全pass就高枕无忧。

7. 常见问题与实战排查

最后这部分，我把自己在这类项目里遇到过的典型问题、排查思路和一些“不说不知道、说了直点头”的实操细节整理出来，给大家做个速查。

7.1 带宽算不对？先查这五个地方

带宽估算看似简单，但我见过好多团队在评估阶段把数字算错，导致方案白做。常见坑位是：

7.2 信号完整性：差分对布满地雷

UCIe的差分对虽然抗干扰能力强，但layout上依然有很多雷。

第一个雷是等长。只要差分对内两条线不等长，就会把差分信号变成“部分共模”，直接影响信号质量。UCIe对同lane内差分走线的长度偏差容忍度很严，通常必须在几十密耳以内，具体数值取决于你选择的lane速率，layout时必须配合自动等长调整。

第二个雷是过孔。Chiplet封装内的走线层数有限，有时不得不通过过孔换层，但每个过孔都会引入阻抗不连续和反射点。如果走线较长，建议在换层位置附近加设参考地过孔，保证回流路径连续，避免地弹和EMI问题。

第三个雷是邻近lane间的串扰。UCIe lane之间距离常被layout工具压缩以节省面积，但相邻lane靠太近会让一根信号线上的能量串到另一根的路径里。早期driving仿真时就要把串扰纳入预算，至少保证内层走线的线间距满足工艺设计规则中针对UCIe的推荐值。

7.3 协议映射：PCIe与CXL同时跑的场景怎么配置

UCIe同一套物理通道上可以承载不同的上层协议，实际项目中常见的诉求是：一条UCIe链路上同时跑PCIe流量（用于数据传输）和CXL流量（内存访问）。这种情况要注意UCIe适配器层的多协议复用功能，而不是简单地把它当一根PCIe线来用。

在设计配置时，两端的die必须使用相同的协议映射配置，也就是共享同一套链路编号、协议类型路由表。如果两端配置不一致，训练阶段就会报错误状态，链路上不去。我在调试中遇到过几次“明明物理层信号很好，就是训练失败”的问题，查到最后都是两端的协议层配置参数没对齐。建议把UCIe链路的初始化配置做成寄存器镜像，上电后由主控端统一写入，不要依赖两边BootROM各自加载。

7.4 一些实操经验总结

最后按个人经验给几条“少走弯路”的建议：

第一，先跑仿真，不要直接上板。UCIe PHY的链路训练、EQ协商、CRC重传逻辑，在仿真环境里可以提前暴露绝大多数握手问题，这些实测环境下很难抓。好的硬件团队在流片之前，会用UCIe一致性仿真平台把所有lane速率、封装类型、协议组合都跑一遍。

第二，多关注功耗。UCIe链路在高速模式下功耗并不低，尤其是PAM4模式和高lane数场景。系统散热设计时给UCIe PHY单独做功耗预算很有必要，不然容易在整机高温测试中触发降频或链路不稳定。

第三，和封装团队一起做SI，不要各干各的。UCIe互连信道的信号完整性强依赖封装基板走线设计，芯片团队、封装团队和后端团队如果不坐到一张桌子上对齐，很容易出现die的IO pad位置和基板扇出走线不匹配，结果造成本来可以走高密度模式的链路被迫降低速率自保。

我个人在实际项目里的体会是，UCIe的协议栈设计已经足够完整，真正决定项目成败的往往是PHY IP选型、layout细节、以及两端配置对齐这些“工程基本功”。标准本身解决的是“能不能互连”的问题，而“能不能连好、连得快、连得稳”，还是得靠团队一个坑一个坑踩出来。如果手头正在做Chiplet方案，建议先把标准封装的中低速率跑通，把链路训练和协议层验证做好，再去碰PAM4、64 lane高密度这些极限配置。这样风险最可控，迭代速度也最快。