芯片行业这几年最热的话题从“多少纳米”逐渐转移到了“怎么拼”。Chiplet这个概念喊了好几年从PPT变成了AMD、Intel、英伟达这些大厂的真实产品但很多人忽略了一个比工艺问题更卡脖子的环节die与die之间到底怎么通信。没有一套统一的互连标准每个厂商各玩各的Chiplet生态就永远只是巨头们的“私人订制”。UCIeUniversal 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定义了一种通用的数据通道格式叫做RDIRaw 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和一颗内存控制器chipletCPU侧跑CXL协议经过UCIe互连内存控制器chiplet看起来就像挂在CPU本地的一个CXL设备驱动模型完全不用变。流协议Stream Protocol是UCIe独有的东西它不绑定任何电子系统现有的协议栈而是直接支持自定义数据包收发。它适合场景是两个die之间要跑私有加速器协议、自定义的数据包或者特殊格式的流式数据不想套PCIe/CXL的框架。这种灵活性让UCIe不至于被现有标准限制住也为不同公司之间合作预留了空间。整理一下这三层各自的职责看这个对照关系会更清楚分层主要职责关键机制协议层提供业务语义支持PCIe、CXL、流协议协议映射、多协议复用适配器层统一数据格式、保证链路可靠RDI封装、CRC校验、重传、流控物理层传输原始电信号、完成链路初始化NRZ/PAM4信号、时钟方案、差分走线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方向分开独立工作所以链路是全双工的。调制方式上标准封装默认使用NRZNon-Return-to-Zero信号一比特一个电平周期。在高级封装场景中可以选择PAM4调制用四种电平来表示两位数据同等符号率下带宽翻倍。但PAM4的代价是信号电平间距变小对噪声和信道损耗更敏感功耗也更大。实际选型时常规链路用NRZ就足够只有在带宽密度压力很大时才需要考虑PAM4。3.2 时钟方案转发时钟与嵌入式时钟UCIe标准中同时定义了两种时钟传输方式转发时钟Forwarded Clock和嵌入式时钟Embedded Clock。标准封装场景下数据走线与转发的时钟信号一起从发送端送到接收端接收端用这个时钟去采样数据。这种方式实现简单、延迟低但对线长的等长控制要求很高时钟和每根数据线之间的延迟偏差必须在设计允许范围内。如果时钟和数据到达接收端的时间错开了采样窗口就会变小误码率上升。高级封装场景下因为走线更短、信道质量更高UCIe支持嵌入式时钟方案。也就是不在物理上单独传一路时钟而是接收端通过CDR时钟数据恢复电路直接从数据信号中恢复出时钟来。这条路省去了额外时钟线节省了布线资源但也对接收端的电路复杂度提出了更高要求。另外一个相关信号是CMNCommon Clock信号它主要用于高级封装场景传递全局时钟和部分系统管理信息。3.3 边带信号与系统管理信号除了高速数据lane之外UCIe还定义了一套低速的边带信号Sideband用于链路建立、配置、中断和状态上报。这套sideband本身也是差分信号采用串行低速接口常见实现会兼容I3C基础规范。它的速率不高但承担着“启动顺序靠它、异常状态靠它”的任务是整个链路先活起来的第一步。调试和管理方面UCIe支持通过JTAG接口访问die内部调试/测试逻辑方便生产测试和后期固件诊断。总的来看UCIe的信号体系可以整理成下面的表格工程做管脚规划时能直接参考信号类别信号名称方向主要作用主数据laneTX/RX差分对双向独立高速数据传输NRZ/PAM4边带信号Sideband TX/RX双向独立链路配置、状态、中断转发时钟Forwarded Clock发送端到接收端标准封装用于数据采样系统时钟/管理CMN/AON双向高级封装公共时钟/唤醒管理调试接口JTAG输入生产测试、调试访问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 × 2DDR 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 带宽算不对先查这五个地方带宽估算看似简单但我见过好多团队在评估阶段把数字算错导致方案白做。常见坑位是坑位典型错误正确理解DDR倍数漏掉以为32GT/s就是32Gbps/lane需要根据DDR机制折算为等效64Gbps/lane方向没分清楚把单向带宽当全双工UCIe的TX/RX独立全双工带宽要乘2协议开销忽略理论带宽应用带宽实际可用理论带宽减去CRC/流控/包头等开销lane数配错了标准封装硬上64 lane标准封装最大32 lane需要64 lane要用高级封装封装型号选错高速需求却选标准封装长走线信道差实际无法跑到最高速率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高密度这些极限配置。这样风险最可控迭代速度也最快。
UCIe与Chiplet互连：从协议栈到封装实战解析
芯片行业这几年最热的话题从“多少纳米”逐渐转移到了“怎么拼”。Chiplet这个概念喊了好几年从PPT变成了AMD、Intel、英伟达这些大厂的真实产品但很多人忽略了一个比工艺问题更卡脖子的环节die与die之间到底怎么通信。没有一套统一的互连标准每个厂商各玩各的Chiplet生态就永远只是巨头们的“私人订制”。UCIeUniversal 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定义了一种通用的数据通道格式叫做RDIRaw 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和一颗内存控制器chipletCPU侧跑CXL协议经过UCIe互连内存控制器chiplet看起来就像挂在CPU本地的一个CXL设备驱动模型完全不用变。流协议Stream Protocol是UCIe独有的东西它不绑定任何电子系统现有的协议栈而是直接支持自定义数据包收发。它适合场景是两个die之间要跑私有加速器协议、自定义的数据包或者特殊格式的流式数据不想套PCIe/CXL的框架。这种灵活性让UCIe不至于被现有标准限制住也为不同公司之间合作预留了空间。整理一下这三层各自的职责看这个对照关系会更清楚分层主要职责关键机制协议层提供业务语义支持PCIe、CXL、流协议协议映射、多协议复用适配器层统一数据格式、保证链路可靠RDI封装、CRC校验、重传、流控物理层传输原始电信号、完成链路初始化NRZ/PAM4信号、时钟方案、差分走线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方向分开独立工作所以链路是全双工的。调制方式上标准封装默认使用NRZNon-Return-to-Zero信号一比特一个电平周期。在高级封装场景中可以选择PAM4调制用四种电平来表示两位数据同等符号率下带宽翻倍。但PAM4的代价是信号电平间距变小对噪声和信道损耗更敏感功耗也更大。实际选型时常规链路用NRZ就足够只有在带宽密度压力很大时才需要考虑PAM4。3.2 时钟方案转发时钟与嵌入式时钟UCIe标准中同时定义了两种时钟传输方式转发时钟Forwarded Clock和嵌入式时钟Embedded Clock。标准封装场景下数据走线与转发的时钟信号一起从发送端送到接收端接收端用这个时钟去采样数据。这种方式实现简单、延迟低但对线长的等长控制要求很高时钟和每根数据线之间的延迟偏差必须在设计允许范围内。如果时钟和数据到达接收端的时间错开了采样窗口就会变小误码率上升。高级封装场景下因为走线更短、信道质量更高UCIe支持嵌入式时钟方案。也就是不在物理上单独传一路时钟而是接收端通过CDR时钟数据恢复电路直接从数据信号中恢复出时钟来。这条路省去了额外时钟线节省了布线资源但也对接收端的电路复杂度提出了更高要求。另外一个相关信号是CMNCommon Clock信号它主要用于高级封装场景传递全局时钟和部分系统管理信息。3.3 边带信号与系统管理信号除了高速数据lane之外UCIe还定义了一套低速的边带信号Sideband用于链路建立、配置、中断和状态上报。这套sideband本身也是差分信号采用串行低速接口常见实现会兼容I3C基础规范。它的速率不高但承担着“启动顺序靠它、异常状态靠它”的任务是整个链路先活起来的第一步。调试和管理方面UCIe支持通过JTAG接口访问die内部调试/测试逻辑方便生产测试和后期固件诊断。总的来看UCIe的信号体系可以整理成下面的表格工程做管脚规划时能直接参考信号类别信号名称方向主要作用主数据laneTX/RX差分对双向独立高速数据传输NRZ/PAM4边带信号Sideband TX/RX双向独立链路配置、状态、中断转发时钟Forwarded Clock发送端到接收端标准封装用于数据采样系统时钟/管理CMN/AON双向高级封装公共时钟/唤醒管理调试接口JTAG输入生产测试、调试访问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 × 2DDR 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 带宽算不对先查这五个地方带宽估算看似简单但我见过好多团队在评估阶段把数字算错导致方案白做。常见坑位是坑位典型错误正确理解DDR倍数漏掉以为32GT/s就是32Gbps/lane需要根据DDR机制折算为等效64Gbps/lane方向没分清楚把单向带宽当全双工UCIe的TX/RX独立全双工带宽要乘2协议开销忽略理论带宽应用带宽实际可用理论带宽减去CRC/流控/包头等开销lane数配错了标准封装硬上64 lane标准封装最大32 lane需要64 lane要用高级封装封装型号选错高速需求却选标准封装长走线信道差实际无法跑到最高速率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高密度这些极限配置。这样风险最可控迭代速度也最快。
