深入解析UCIe：从差分信号到Chiplet互连选型实践

如果你最近在关注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有AIBAMD有Infinity Fabric的芯片间扩展NVIDIA有NVLink-C2CArm则力推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。这个区分的意义在于它没有像某些标准那样“一刀切”地给出唯一参数而是通过定义两种Level1.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.03D封装与管理能力补全UCIe 2.0在2024年发布核心变化有两个方向。第一是正式把3D封装纳入规范支持Die-to-Die的垂直堆叠场景Face-to-Face与Face-to-Back。这是一种物理形态上的扩展原来UCIe主要面向2D平面上并排放置的Die2.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 DiePCIe流量和内存DieCXL内存流量同时还有一条流式通道连接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方案选型有帮助。