如果你最近在关注Chiplet方案选型，大概率绕不开一个名词：UCIe。不管是和封装厂对Bump Pitch，还是和IP厂商聊Die-to-Die接口，UCIe几乎是所有人默认的对齐基准。上周我还在和团队讨论下一代多Die芯片的内部互连方案，拿串行SerDes和UCIe做了好几轮对比，发现不少同行对这个标准的理解还停留在“知道名字”的程度。这篇内容我就结合自己的实践经验，把UCIe的架构分层、差分信号设计、版本演进和实际选型逻辑一次说透。
首先说明，这篇文章不是翻译规范文档。我会从“为什么会诞生UCIe”“它到底拆成了哪几层”“差分信号为什么是必然选择”“1.0到3.0各改了什么”“UCIe和PCIe/CXL是什么关系”这几个角度展开，最后给出我自己做芯片互连选型时的评判框架。无论你是做系统架构、数字前端、封装集成还是软件栈的工程师，都能从中找到可以直接带走的东西。
1. Chiplet互联为什么要统一：从AIB、Infinity Fabric到UCIe的必然性
1.1 当chiplet需要互联，为什么SoC内部那套办法失灵了
先回到一个根本问题：我们封装一颗单芯片SoC时，芯片内部各个模块之间靠什么通信？答案是片上网络（NoC）或者各种内部总线，它们跑在统一的工艺节点上，线延迟、功耗、拥塞全部可以由设计工具精确建模。但Chiplet架构出现后，情况变了——你买来的A die是台积电工艺，B die可能来自三星甚至格芯，两个Die被放到同一个封装里，它们之间不能再用SoC内部那种“单位距离布线的物理规则”来约束，因为中间隔着封装基板、微凸点或硅中介层，电气环境和工艺都不是同一套。
这时候就需要一种专门的“Die-to-Die互连方案”。它和芯片内部总线最大的区别在于：必须考虑跨工艺、跨封装介质的信号完整性问题，需要定义明确的电气接口、链路初始化流程和容错机制。早期各家都做私有的互连方案，Intel有AIB，AMD有Infinity Fabric的芯片间扩展，NVIDIA有NVLink-C2C，Arm则力推CHI C2C。每家接口的物理层参数、协议语义、测试方法都不一样，带来的后果就是：你一旦选了某家的Chiplet生态，就被“焊死”在里面了。
1.2 UCIe与既有私有接口的关系
2022年3月，Intel联合AMD、Arm、TSMC、Samsung、Qualcomm等十余家企业成立了UCIe联盟，正式发布UCIe 1.0规范，全称Universal Chiplet Interconnect Express。这个名字起得很直白：Universal（通用）、Chiplet（芯粒）、Interconnect（互连）、Express（致敬PCIe那种“高效直达”的定位）。
很多工程师问过我：UCIe出来了，那NVIDIA的NVLink-C2C是不是要凉？AIB是不是白做了？我的看法恰恰相反。UCIe的价值在于给出了一个“公共底座”——物理层和D2D适配层统一，上层协议你想跑PCIe就跑PCIe，想跑CXL就跑CXL，想自定义流式协议也可以。NVIDIA、AMD这些厂商依然可以在上面加私有扩展，做出差异化的带宽、延迟和一致性能力，但底层互连不再是“绑架客户”的筹码。
这件事的本质是：Chiplet市场要想做大，必须降低多供应商组合的信任成本和验证成本。UCIe提供的就是这套“通用语”。它不一定是最好的技术方案，但它是第一个被全产业链认可、且有明确规范约束的开放互连标准。后面我们会看到，UCIe在设计上刻意“做减法”——只解决通用问题，把差异化空间留给上层协议。
2. UCIe的三层架构拆解：物理层、D2D适配层、协议层各自管什么
UCIe参考模型分了三层：物理层（Physical Layer）、Die-to-Die适配层（D2D Adapter Layer）和协议层（Protocol Layer）。很多文章把这个模型一笔带过，但我认为理解这三层划分，是看懂UCIe后续所有设计决策的关键。
2.1 物理层：面向封装介质的电气接口定义
UCIe物理层负责最底层的电气信号传输，包括发射机、接收机、时钟转发、边带信号、以及不同封装形式下的Bump设计。它直接面对的是“信号要从一个Die的金属层，穿过封装基板或中介层，到达另一个Die的金属层”这个物理过程。
这里有一个很重要的工程背景：不同封装形式下的信道质量差异非常大。UCIe在1.0阶段就把物理层分成了两类目标场景：标准封装和先进封装。标准封装指的是传统的有机基板封装，Die间距较大，走线损耗明显，速率被迫定在16GT/s；先进封装则对应硅中介层这类方案，Die之间距离很近，信道环境好很多，速率可以直接拉到32GT/s。
这个区分的意义在于，它没有像某些标准那样“一刀切”地给出唯一参数，而是通过定义两种Level（1.0规范里叫Standard Package和Advanced Package）来兼容不同成本和技术能力的厂商。后续的演进版本里，UCIe进一步引入3D叠Die和光学互连，物理层的定义范围还在扩大，但核心思想不变：物理层必须贴近真实制造工艺来定义，不能只看接口逻辑。
2.2 D2D适配层：链路训练与可靠性机制
D2D适配层是UCIe里最容易被忽略、但极其关键的一层。它负责链路初始化、训练、参数协商、数据路径宽度协商、CRC校验、以及可选的重传机制。
为什么需要一个专门的适配层？因为UCIe是一种“裸芯片到裸芯片”的高速链路，不是像以太网那样经过连接器和线缆的完整系统。它希望延迟极低，所以不能照搬PCIe那种复杂的链路训练状态机；但它又必须有基本的可靠性保障，因为一旦速率提高，误码率不可避免地会上升。
这里有个工程权衡：UCIe允许关闭CRC和重传机制来换取极致的低延迟。在先进封装、距离极短的场景下，信道误码率本来就低，很多设计会选择关闭重传，只保留CRC检测，甚至两者都关掉，让上层协议去兜底。这种做法我在实际项目里也见过不少。而如果是标准封装、距离较远，或者承载的是存储类数据，那通常会把CRC和重传打开。
2.3 协议层：三种上层协议的插槽化设计
协议层定义了UCIe链路之上承载哪些协议，目前官方明确了三种：PCIe、CXL、流式协议（Streaming）。其中PCIe和CXL都是成熟的事务层协议，流式协议则是UCIe专门为Chiplet互连设计的一种轻量传输模式。
这一层的设计思路很清晰：UCIe不自创一套完整的IO协议栈，而是做“适配器”，让已有的PCIe/CXL软件生态直接落到Chiplet互连上。这是什么概念？相当于你原来需要一颗支持PCIe的主机接口Die和一颗支持PCIe的末端设备Die，现在它们之间的物理通道从传统PCB走线变成了UCIe互连，但上层看到的还是PCIe的配置空间、中断、DMA语义，驱动几乎不用改。
流式协议则更灵活，它不需要事务层语义，直接把用户自定义数据流切成Flit（流控制单元）或包发过去，适合NoC直连、自定义加速器或需要极低延迟的独占带宽场景。这个三协议并存的架构，让UCIe既能吃存量软件红利，又能给差异化创新留出后门。
3. UCIe到底是不是差分信号：电气层设计与封装选型的底层逻辑
3.1 为什么高速接口“清一色”用差分信号
先直接回答热搜问题：是的，UCIe的物理层数据信号采用差分信号（Differential Signaling），而且这一选择背后有非常清晰的物理原因。
差分信号的本质是“两条线走一对互补信号”，接收端关心的是两条线之间的电压差，而不是某一条线对地的绝对电压。相比单端信号，差分信号最大的收益是抗共模噪声：外部干扰通常会以相同的方式同时叠加到两条线上，取差值的时候正好抵消掉。同时，差分信号允许很低的电压摆幅，功耗更低，EMI特性也更好。对于Chiplet互连这种“短距离、高密度、高速率”的场景，这些都是压倒性的优势。
还有一个细节值得展开：UCIe采用的是源同步时钟转发机制（Source-Synchronous Clock Forwarding），也就是说发送端把数据和时钟一起送过去，接收端直接用收到的时钟采样，而不需要像传统CDR（时钟数据恢复）那样从数据流中恢复时钟。这种方案在Die-to-Die短距离场景下非常合适，它能显著降低接收端的设计复杂度和锁定时间。这也是它和长距离SerDes最核心的区别之一。
3.2 UCIe lane结构：一根根线怎么分配
UCIe的每一条lane由四根主要信号线组成：一对差分发射（TX+ / TX-）、一对差分接收（RX+/RX-），另外还有独立的差分时钟转发对。UCIe 1.0中每个方向最多支持16条lane，形成全双工链路。最大lane数下，标准封装的单向带宽约为32GB/s，双向64GB/s；先进封装单向64GB/s，双向128GB/s。
看到这里，有人会问：UCIe的速率听起来也不是特别夸张，是不是不如传统SerDes？这种问法其实没抓住重点。UCIe的优势不在单lane速率，而在带宽密度——它把Bump间距压缩到几十微米级别，单位面积内可以布出的差分线数量远超传统SerDes，而且功耗低得多。实际对比中，UCIe先进封装下的带宽密度可以达到传统SerDes的十倍以上，pJ/bit指标也占据明显优势。对于Chiplet互连来说，决定系统的往往是总带宽、面积和功耗三者平衡，而不是某一个极值。
3.3 标准封装和先进封装的电气差异直接决定速率
前面提到UCIe把物理层分成标准封装和先进封装两类，这里展开说一下二者为什么速率不同。
标准封装（例如有机基板上两个Die并排放置）中，Die边缘到边缘的距离可能达到数毫米甚至十几毫米，走线必须穿过基板上的长距离铜线，伴随明显的插入损耗和反射。Bump pitch通常在100~130微米左右，根本无法做到很高的信号速率，UCIe将这一档速率定在16GT/s是合理且保守的选择。
先进封装则不同。以TSMC的CoWoS类硅中介层方案为例，多个Die被安装在统一的硅中介层上，Die之间的连线距离可以缩短到2毫米以内，Bump pitch可以做到25~55微米，信号损耗极低，链路可以得到近乎理想的电气环境。UCIe在先进封装档把速率定到32GT/s，实际工程中甚至还有继续超频的空间。这个差异告诉我们：选择UCIe的速率档位，本质上不是在选协议，而是在选封装路线。
3.4 “到底是不是差分信号”的常见认知误区
关于差分信号还有一个认知误区值得说清楚：有些资料会渲染“UCIe在3D封装中改用了单端信号”之类的说法，这并不准确。UCIe 2.0引入3D封装时，确实允许不同的物理层实现选项，但主流数据路径依然是差分结构。标准组织永远不会轻易放弃差分信号带来的噪声抑制优势，尤其面对3D堆叠这种电磁环境更复杂的场景。
那为什么会有类似的混淆？因为Chiplet互连的低速控制信号，例如边带接口（Sideband），有可能采用单端或简化的低速接口。不能因为低速边带用了别的方案，就认为整个标准“放弃差分信号”。如果你在评估第三方UCIe IP，建议直接看它的PHY技术文档里TX/RX pin定义，所有关键数据lane相差分对基本是确定的。
4. 从1.0到3.0版本演进：每一次迭代都补了哪些生态短板
4.1 UCIe 1.0：先把2D封装的基准定义起来
UCIe 1.0发布于2022年3月，它做的事情实质上是“确定公约数”。它的重点包括：定义标准封装和先进封装两类物理层场景；确定16GT/s和32GT/s两档速率；定义每方向最多16条lane的链路宽度；推出D2D适配层；规定协议层支持PCIe和CXL及流式协议。1.0版本把最容易达成共识的部分先冻结下来，让IP厂商、设计公司、封装厂和EDA工具链都可以围绕一个确定的基线开展工作。
从落地角度看，UCIe 1.0最实际的价值是提供了明确的可测试规范。此前各个私有的Die-to-Die接口各有各的测试方法，互不兼容；UCIe 1.0定义了物理层测试、链路层测试和协议层测试的边界，让芯片流片后可以用统一方法验证互连是否符合规范。这一点对我这种做硅后验证的人而言，比宣传的带宽数字更有价值。
4.2 UCIe 2.0：3D封装与管理能力补全
UCIe 2.0在2024年发布，核心变化有两个方向。第一是正式把3D封装纳入规范，支持Die-to-Die的垂直堆叠场景（Face-to-Face与Face-to-Back）。这是一种物理形态上的扩展：原来UCIe主要面向2D平面上并排放置的Die，2.0开始支持两个Die直接叠在一起，通过极短的TSV或微凸点互连，距离更近、带宽密度更高、延迟更低。
第二个方向是管理能力的增强。UCIe 2.0加强了链路管理相关定义，包括带外管理通道、更细粒度的功耗状态、以及更灵活的参数协商机制。这意味着UCIe不仅在传输数据，还能更好地融入系统级电源管理和可管理性体系。对于服务器、汽车电子这些对可靠性要求高的领域，这是一个关键补强。
4.3 UCIe 3.0：速率翻倍与光学互连的“越界”
到了2025年，UCIe 3.0发布，业界讨论度最高的是两件事：一是数据率翻倍到64GT/s，二是光学互连正式进入规范。
先说速率。64GT/s这个数字不是简单翻倍，它要求物理层在标准封装和先进封装下都做出大量信号完整性改进。实际在先进封装场景下，64GT/s的单lane速率已经超过了多数人对“Die-to-Die短距离链路”的预期，同时它还提出了更高的能效目标。3.0在物理层还引入了更多前向纠错和均衡机制，保证速率提升后系统的稳定性仍然可控。
再说光学互连。这件事的意义怎么强调都不过分，它把UCIe的应用空间从“封装内部”延伸到了“封装之间”，也就是板级甚至机柜级互连。光学互连和传统电互连在链路层、错误重传、功耗管理上差异巨大，UCIe 3.0要在同一套D2D适配层框架下兼容光电两种介质，协议设计非常精妙。虽然目前很多细节属于保密状态，但整体方向很清晰：Chiplet互连标准正在一步一步吃掉原来属于光模块和SerDes的市场。
5. 别把UCIe当全套协议：它与PCIe、CXL如何分工作
5.1 UCIe和PCIe/CXL不是并列关系，是上下层关系
在“ucie协议”这个热搜词背后，我发现很多人的困惑点在于：UCIe到底是一套“协议”还是“物理接口”？其实UCIe和PCIe/CXL不是同一个抽象层级的概念，用“协议栈搭积木”更容易理解。
PCIe和CXL代表的是事务层语义，是定义“软件怎么看到设备、数据怎么组织”这些高层规则的。而UCIe更多承担的是物理层和链路层职责，解决“数据怎么在Die与Die之间可靠传递”。一套完整的互连方案，是UCIe把数据从A Die搬到B Die，但数据是什么含义、按什么格式解释，则由PCIe/CXL来定义。
所以，严格说“UCIe协议”这个说法不太严谨。它更准确的定义是UCIe互连技术，物理层和适配层占主导。但在行业里大家已经习惯用“UCIe协议”泛指这套互连规范，就像很多人会说“PCIe协议”一样。
5.2 流式协议才是UCIe真正“新”的部分
如果要让一个多年的PCIe工程师说UCIe里哪个概念最有新意，大概就是流式协议了。PCIe和CXL本质上都是面向“事务”的，有明确的地址空间、请求类型、完成机制，而UCIe Streaming则完全去掉这些约束，数据以Flit或包的形式在UCIe链路上传输，内容由发送方和接收方自行约定。
这个设计让UCIe可以承载NoC或其他私有片上协议。比如你有一个自研AI加速器Die，另一个Die是HBM内存控制逻辑，二者之间本来就不需要PCIe的枚举、配置和DMA机制，只希望把数据Bypass出去，流式协议正好满足这种需求。它把“协议层”的自由度还给了用户，而UCIe负责保证链路本身可靠、低延迟、高带宽。
5.3 一个die同时跑多种协议：虚拟通道与仲裁
UCIe还支持在同一物理链路上同时承载多种协议流量。一个Die可以同时向另一个Die发送PCIe枚举报文、CXL内存请求和流式自定义数据包。系统通过虚拟通道或流量仲裁机制隔离不同类型流量，确保关键业务的延迟不被打断。
这个能力对SoC架构规划非常重要。想象一个Chiplet化的CPU：计算Die通过UCIe连接IO Die（PCIe流量）和内存Die（CXL内存流量），同时还有一条流式通道连接AI加速Die。一条物理链路解决三种业务，既节省接口面积，又简化了跨Die数据通路的设计。当然，实际配置的软硬件复杂度并不算低，链路两端的仲裁器配置、QoS策略、缓存隔离都需要仔细调试。我见过不少项目在UCIe链路训练通过后，反而在流量优先级调优上耗费了大量时间。
6. 要不要把自研接口换成UCIe：我的评估维度和判断方法
6.1 带宽密度、能效与延迟三个核心数字
每次有人问我“UCIe和SerDes选哪个”，我通常都会引导他们先算三个数：带宽密度、能效、延迟。
带宽密度指单位面积（或单位长度）能提供的互连带宽。UCIe在先进封装下的优势极大，Bump间距只有几十微米，同样的硅片面积可以开出远多于SerDes的通道数量。如果你的系统对面积敏感，例如追求极致算力的AI芯片，UCIe是明显更优的选择。
能效方面，UCIe目标在1~2pJ/bit量级，而且没有SerDes那样复杂的均衡和时钟恢复电路，功耗会更低。这个指标对功耗敏感的数据中心芯片非常关键。延迟方面，UCIe适配层设计更精简，物理层还采用前向时钟，避免了SerDes高延迟的CDR过程，所以Die到Die端到端延迟能做到几纳秒级别。对于需要在多个Die之间做一致性访问的设计，这个低延迟优势会被进一步放大。
6.2 软件生态复用程度决定切换成本
如果你把UCIe作为一个纯物理层替换方案，上层继续跑PCIe，那你最大的收益实际上是“省了一个SerDes控制器外加一组PCIe桥接逻辑”。因为上层PCIe语义完全不变，驱动、BIOS、操作系统都不需要感知底层互连方式。这也是UCIe早期最容易落地的场景。
反过来，如果你要开创流式协议，就必须自研链路两侧的适配逻辑、调试工具和性能分析手段，软件成本完全不低。我的建议是：能用PCIe/CXL语义解决的问题，优先用PCIe/CXL语义；只有带宽、延迟或面积指标确凿无法满足时，才走到流式协议这一步。
6.3 供应链与封装能力约束
UCIe的很多优势必须依赖先进封装才能完全发挥。但先进封装产能一直处于紧张状态，CoWoS这类供应链资源不是每家公司都能轻松拿到。我见过一些初创公司，在评估UCIe方案时把先进封装当作默认前提，结果流片排期一推再推。这里需要提前盘一下自己的供应链资源：你能拿到哪种封装产能，再决定选哪个UCIe速率档和物理层设计。
如果暂时无法进入先进封装阵营，标准封装UCIe的16GT/s也是一个务实的选择，至少在互连接口层面已经标准化，后续切换到先进封装时，只需要替换物理层实现和重新做封装验证，上层逻辑基本不变。
6.4 我的建议：哪些项目适合现在上车
其实UCIe目前已经不是一个“前沿试验”状态了，联盟成员覆盖了主要Foundry、IP厂商和系统公司，3.0版本也给出了非常明确的演进路线。我认为适合现在上车的项目有这么几类：一是已经有成熟PCIe/CXL系统软件栈、希望通过Chiplet方式增量扩展计算资源的产品；二是需要紧密集成多个Die且对带宽密度、延迟和能效有强诉求的AI加速芯片；三是希望走多供应商Chiplet组合路线、不想被单一互连生态锁定的系统厂商。
反而不太建议第一版就全盘转向流式协议或光学互连的项目，除非你团队里有足够的自研链路和系统软件能力。UCIe标准再完善，也只是提供了一个规范化起点，真正让它跑出性能优势的，还是你在标准之上做出的工程取舍和生态适配。
我自己在评估这类互连方案时的习惯，是先抓住“封装决定物理层，协议决定复杂度，软件决定验收周期”这条主线，再逐个维度做对比表格，最后结合手头资源和产品节奏拍板。Chiplet时代的好处在于选择变多了，而选择越多，越需要先把标准吃透——这也是我花这么长篇幅拆解UCIe的初衷。希望这篇内容对你理解UCIe和后续Chiplet方案选型有帮助。
