这两年只要聊到ChipletUCIe就是绕不开的名字。做芯片的人都知道Chiplet把一颗大SoC拆成多个小die思路很好但拆完之后怎么把这些die又快又稳地连起来才是真正决定成败的地方。UCIeUniversal Chiplet Interconnect Express就是把这个问题标准化的答案。它定义了die与die之间的物理层信号、链路层握手和上层协议映射目标很明确让不同厂商、不同工艺、不同封装的Chiplet像乐高积木一样拼在一起。这篇内容我会从标准背景、技术分层、版本演进、工程落地和常见坑几个方向聊一遍适合做芯片架构、封装集成、系统验证的朋友也适合刚开始接触Chiplet、想搞明白UCIe到底是什么的新人。1. Chiplet时代UCIe凭什么成为互连的“通用语言”1.1 为什么Die-to-Die互连需要一个统一标准传统SoC是一整颗die所有模块通过片内总线通信距离短、延迟低、信号干净。但到Chiplet时代一颗大芯片变成了几个diedie与die之间要么通过基板走线要么通过硅中介层连接信号要跨出die的边界在封装内“远行”。这时候你会发现片内总线的假设全部不成立了信道更长、阻抗不连续、串扰变大、校准要求变高连电源噪声都不一样。在没有UCIe之前各大厂都在用私有die-to-die接口。AMD用自家Infinity Fabric做ChipletIntel早些年推AIB开放社区还有BOW这类的并行接口方案。每个方案都绑定了特定的封装材质、特定的物理层设计、特定的控制器等于每家都得自己维护一套接口IP、验证环境和封装规则。这对行业是巨大的重复劳动。更重要的是它没法形成生态你用台积电的工艺做了一个CPU die拿给另一个厂商的加速die去配如果接口标准对不上根本没法互操作。Chiplet要想做成“产业分工”而不是“一家独大”第一步就是统一接口语言。UCIe就是在这个背景下被推上台面的。不妨这么理解传统SoC像一个人包办所有工作Chiplet像一个团队协作但团队协作需要统一的工作流和交流语言。UCIe就是这个语言标准。1.2 从UCIe联盟到“开放标准”免费不等于开源UCIe联盟在2022年3月正式对外发布了UCIe 1.0规范创始成员名单基本覆盖了整个半导体产业链Intel、AMD、Arm、台积电、三星、ASE、Google Cloud、Meta、Microsoft、Qualcomm等。这不是某一家公司关起门来定的私有标准而是由联盟成员共同推动、面向全行业开放的规范。注意这里要区分两个概念开放标准和开源。UCIe是一个开放标准规范文档可以申请获取但接口IP核不是白送的通常需要向IP厂商购买授权或者自己实现。这跟Linux这种开源软件是完全不同的模式。对企业来说UCIe降低的是“互操作成本”而不是“IP成本”。联盟的架构分得很细有物理层工作组、协议层工作组、封装工作组、合规性测试工作组等后面我们聊到的很多参数细节都是这些工作组来回拉扯的结果。这种组织方式决定了一件事UCIe的演进是相对缓慢但靠谱的不会像开源社区那样三天两头改接口。1.3 UCIe的定位先兼容PCIe/CXL再做新的扩展UCIe在协议层设计上做得非常聪明它没有另起炉灶发明一套全新的上层协议而是把PCIe和CXL直接搬了进来。PCIe是几乎所有服务器、PC、加速卡都支持的标准CXL是当下内存扩展和缓存一致性的主流互连协议。UCIe的协议层原生支持这两者意味着上层软件栈基本不需要改动。打个比方UCIe干的活是“标准插座”而不是重新发明“用电标准”。你的设备只要支持PCIe/CXL插到UCIe这个插座上系统看到的就是一个标准的PCIe/CXL设备完全无感。这为Chiplet大规模商用扫清了最大的障碍软件生态。除此之外UCIe还定义了Streaming模式和Raw模式前者是给需要高吞吐定制协议的加速器用的后者是裸管道给那些想完全自己定义链路的深度玩家留了后门。后面我在协议层部分会展开讲。2. 从物理层到协议层一层层拆开UCIe2.1 三层架构解决的问题UCIe的逻辑架构分为三层物理层Physical Layer、Die-to-Die适配层D2D Adapter Layer、协议层Protocol Layer。很多第一次接触的人会觉得这是不是太复杂了直接像PCIe那样拉起一条高速链路不就行了但Chiplet场景和板级PCIe场景差别很大分层是必须的。物理层负责信号在封装信道上的可靠传输包括驱动电流、端接、时钟转发、接收均衡等。适配层相当于“翻译官”把上层协议的数据转换成适合物理层收发的flow control信号同时负责链路的初始化、训练、校准、CRC校验和链路级重传。协议层则决定链路上跑的是什么语义是PCIe事务、CXL事务还是你自定义的流式数据。分层的核心价值在于解耦。你可以在协议层跑CXL但物理层随时换封装从标准封装换成先进封装适配层不需要动你也可以保持同一套物理层在协议层从Streaming模式切换到PCIe模式接口管脚定义不变。实际项目中这套分层结构能省掉大量重新谈判管脚和封装的成本。2.2 物理层差分还是单端取决于你用什么封装先直接回应很多人问过的问题UCIe采用差分信号吗正确答案是“不一定是取决于封装模式”。这也是UCIe在设计上比较实际的地方。UCIe定义了两种物理层选项分别对应不同的封装场景。第一种是标准封装模式也就是die通过有机基板、RDL走线互连信道长度相对较长损耗和串扰都要认真对待。这种模式下主链路数据和转发的时钟都采用差分信号differential signaling传输。差分信号的好处很明显抗共模噪声强、对地弹不敏感、EMI表现好适合在损耗较大的基板信道上跑高速。这个时候管脚数会翻倍因为一对信号需要两个物理pin但换来的信号质量是值得的。第二种是先进封装模式比如通过硅中介层CoWoS类、InFO-LSI或者3D堆叠互连die之间的信道极短信道干净、损耗很小。这种模式下主链路数据用单端信号只有时钟仍然保持差分转发。单端信号占用的物理通道少一半带宽密度更高功耗也明显下降。距离短到一定程度复杂的差分传输反而成了浪费。边带信号sideband的情况也要说清楚。UCIe定义了一条低速的边带通道用来做链路训练、状态协商和维护管理这条通道是单端信号。也就是说一个UCIe物理层接口里面是“差分单端”并存的不能一刀切说UCIe用了差分或者没用差分。速率方面UCIe 1.0定义的标准封装模式每lane可以跑到32GT/s量级先进封装模式还能更高。实际产品一般会组成x4到x16不等的链路就是多个lane并行工作。这里想提醒一句很多人看速率只看单lane带宽但Die-to-Die互连最重要的指标其实是带宽密度也就是在单位mm边缘上能传多少数据。单端信号在先进封装下的优势说到底就是在带宽密度这个指标上碾压差分。2.3 D2D适配层训练、检错和重传的秘密适配层D2D Adapter Layer是UCIe里最容易被低估的一层。它的职责包括链路初始化、训练与校准、链路状态管理、CRC校验、链路级重传、协议多路复用等。链路一开始上电时收发双方并不知道对方的预期速率、lane配置和协议模式。适配层会通过边带通道交换能力集协商出一套双方都支持的配置然后启动物理层的训练序列。训练过程包括时钟恢复、接收端均衡器系数的自适应调整、眼图开度的探测这些步骤做完链路才算进入可用的Up状态。训练完成之后适配层要做的事情更多。它会在数据流上切分成固定大小的flit每个flit里包含头信息、数据和CRC校验字。接收方每收到一个flit就校验一次一旦发现CRC错误就触发链路层重传。这个机制跟PCIe的重传有些类似但用于die-to-die短距离场景延迟开销要小得多。有人可能会问既然信道这么短为什么还需要CRC和重传答案是封装和基板的工艺缺陷、电源噪声、串扰仍然可能引入瞬态错误不做链路层保护一旦出错就只能靠上层的协议层恢复延迟会大得多。适配层还负责协议多路复用。当一个UCIe链路上同时跑PCIe和CXL流量时适配层会根据数据包头把流量分发到对应的协议通道。此外还定义了Raw模式相当于绕过协议层直接对接适配层这在定制加速器场景非常有用。用一句话总结适配层的作用让上层协议感觉不到物理层的存在尽量做到透明可靠的数据管道。2.4 协议层PCIe、CXL、Streaming和Raw怎么选协议层是用户最直接接触的部分UCIe的协议层支持PCIe、CXL、Streaming和Raw这几类模式。如果Chiplet产品最终要挂到主机系统里当标准设备用比如一个IO die连接PCIe交换机或者CPU那协议层直接选择PCIe就好了让主机认为这个Chiplet就是一个PCIe设备。如果涉及内存扩展或者缓存一致性CXL是更合适的选择。用UCIe把两个die连接起来对外呈现为完整的CXL设备这种模式已经在不少原型系统上验证通过了。Streaming模式是给需要极高吞吐、低延迟且协议固定的场景准备的。比如一个AI加速器die和一个存储die之间的数据通路走PCIe的话头开销太大走Streaming模式可以直接定义自己的数据格式在适配层之上做扁平传输效率高得多。代价是生态不通用数据的含义只有自己知道不适合做产业互联。Raw模式则是完全绕开协议封装直接让上层应用控制适配层和物理层。这个模式适合芯片内部调试、定制链路实验、或者自己设计轻量协议。如果你不想被UCIe绑定的协议层约束Raw模式是最自由的但自由的另一面是很多东西要自己实现。选哪种模式没有绝对的对错核心是看产品形态对外标准接口优先选PCIe/CXL内部加速器互联优先选Streaming想快速做芯片验证选Raw最简单直接。3. UCIe版本演进从1.0、1.1到2.0还有热议的3.03.1 UCIe 1.0/1.1把地基打牢UCIe 1.0发布于2022年3月定义了整个标准的框架包括物理层、适配层、协议层、标准封装和先进封装两种选项以及PCIe/CXL/Streaming等传输模式。1.0版本已经可以支撑实际产品的开发到现在为止仍然有不少Chiplet方案基于1.0在做。1.1版本是在1.0基础上的小步快跑重点补了一些工程化的细节包括带外管理的增强、互操作性测试方法的完善、以及一些针对不同封装形态的优化。1.1没有改动整体架构但让不同厂商的UCIe实现之间更容易对接成功。这里说一个实际经验UCIe这种标准大家最容易忽略的是合规性测试。纸面上大家都说支持UCIe 1.1但真正把两个不同厂商的die连起来问题全在细节上比如训练序列的超时时间、边带信号的时序、均衡系数的初始值。所以从1.1开始联盟花了很多精力在定义互操作测试规范上这对行业来说是很有价值的工作。3.2 UCIe 2.0面向3D封装和AI负载的大版本UCIe 2.0是2024年发布的重大版本更新它最重要的变化是加入了3D封装的正式支持包括面对面的die堆叠方式face-to-face。3D封装跟2D封装最大的区别是信道更短但复杂度大幅上升对错位、翘曲、热应力的容忍度更低。2.0围绕3D场景重新定义了物理层的设计目标和封装规则让UCIe可以适配更激进的异构集成方案。除了物理层2.0在管理和安全上补了很多功课。它加入了对链路完整性、数据保密性、防篡改等安全机制的定义还增强了可管理性接口支持更完善的调试、遥测和故障隔离功能。这些特性对服务器和数据中心场景尤为重要毕竟Chiplet产品如果出了问题定位到具体die和具体链路的能力直接决定了运维成本。另外2.0针对AI工作负载做了专门的优化。AI加速器通常是多die并发协同数据搬运量极大对带宽密度的要求远高于传统CPU。2.0扩展了面向这类多die、高带宽、低延迟场景的配置选项比如更大的链路宽度支持、更灵活的多通道复用机制。很多人把2.0看作UCIe从“能用”走向“好用”的关键版本。3.3 行业热议的UCIe 3.0还没发布但方向清晰最近“UCIe 3.0”这个词在社区里越来越热。先说明一下目前联盟官方还没有正式发布UCIe 3.0规范但是行业里关于下一代标准的讨论已经很充分方向也基本清晰。从公开信息和产业链反馈来看UCIe 3.0的讨论热点集中在几个方面一是更高带宽密度继续往上推速率可能到64GT/s甚至更高同时进一步压低单位比特功耗二是更长距离的互连比如面向面板级封装Panel-level Packaging的传输需求信道比传统硅中介层更长意味着物理层要做更多均衡和编码方面的工作三是更灵活的多die网络拓扑现在的UCIe链路基本是point-to-point下一代可能会在网络化拓扑、多跳路由方面做文章四是和光互连、光I/O的结合这会是面向数据中心大规模Chiplet系统的长期方向。对这些还停留在讨论阶段的方向我的建议是产品选型不要抢跑。除非你有明确的长期规划节点否则现阶段选择已经成熟的UCIe 1.1或者2.0实现是完全够用的。追赶尚未冻结的规范就像踩在浮桥上跑步风险远大于收益。4. 落地UCIe的工程实践封装、信号完整性与协议配置4.1 标准封装还是先进封装先算一笔成本账做UCIe产品第一步不是写代码而是决定采用哪种封装。标准封装模式成本低、供应链成熟适合大多数中低密度互连场景先进封装模式带宽密度高、功耗低但成本、供应链和散热复杂度都会上升。维度标准封装Standard Package先进封装Advanced Package信号形式差分数据 差分时钟单端数据 差分时钟带宽密度中等高信道长度较长基板走线为主极短硅中介层/3D堆叠单位功耗偏高很低成本与复杂度低成熟供应链高良率/热应力挑战大典型场景消费级Chiplet、IO dieAI加速器、高性能计算这个表格是选型的起点。我见过不止一个项目一开始因为追求先进封装的炫酷参数上了CoWoS结果发现量产良率和成本完全扛不住最后不得不退回标准封装重新做物理层。反过来也有项目因为带宽密度实在满足不了业务需求咬牙上先进封装反而跑通了。工程决策没有银弹就是拿需求卡预算。另外提醒一下封装模式的选择会直接影响UCIe的管脚定义和物理层约束比如驱动强度、端接方案、均衡档位都要跟着变。所以这个决策一定要尽早做最好在architecture阶段就定下来否则后期换封装等于重新做一遍PHY。4.2 信号完整性差分线、阻抗和时钟分配的核心点UCIe链路能不能跑上去一半看信号完整性设计。先讲差分信号。标准封装模式下数据lane和转发时钟都是差分对PCB和基板上的差分走线要控制特征阻抗常见目标是85Ω差分阻抗具体值跟UCIe IP实现和封装模型有关。走线要做到等长等间距特别是P和N之间不要有大的长度差否则共模转差模会直接劣化眼图。时钟分配方面UCIe使用转发时钟架构也就是发送端在发数据的同时把一路时钟信号跟数据一起发到接收端。接收端利用这路时钟对数据进行采样避免了复杂的CDR电路。这带来一个好处链路训练更快抖动要求相对宽裕。但代价是时钟走线必须跟数据lane同步长度匹配非常重要。实测中时钟对和数据对的skew偏大是导致误码率骤升的常见原因之一。电源完整性也特别容易被忽略。UCIe高速收发电路工作时会有很大的瞬态电流如果电源网络设计不好电源噪声耦合到信号上就会表现为随机误码而且这种误码用常规的阻抗检查很难发现。我的习惯是在仿真阶段就把PDN网络和差分走线一起建模做完整的电源-信号协同仿真实测阶段再结合片上眼图监视器对比双管齐下。先进封装模式下信道短很多信号完整性问题相对轻但bump排列、RDL走线、以及3D堆叠时的热应力对信号的影响会变成新难点。这种场景下跟封装厂的协同设计比自身电路设计更关键。4.3 一次典型链路初始化的配置过程UCIe的链路初始化看似黑盒其实有固定的流程。我这里以一套常见的UCIe PHY控制器为例写一个简化的初始化序列帮助大家理解整个过程。# UCIe链路初始化简化示例伪代码 # 1. 确保物理层电源域正常复位释放 phy_power_up() assert phy_reset_done() # 2. 读取sideband能力寄存器协商模式 cap sideband_read(REG_CAPABILITY) peer_cap sideband_read(REG_PEER_CAPABILITY) # 3. 配置链路宽度、速率、协议模式 cfg_lane_width min(cap.lane_width, peer_cap.lane_width) cfg_speed min(cap.max_speed, peer_cap.max_speed) cfg_protocol PROTOCOL_PCIE # 或CXL / STREAMING / RAW adapter_configure(cfg_lane_width, cfg_speed, cfg_protocol) # 4. 启动物理层训练 phy_start_training() # 5. 等待训练完成链路状态进入UP timeout 0 while not adapter_link_up(): timeout 1 if timeout LIMIT: dump_sideband_status() raise LinkTrainFailed(sideband状态异常/时钟未锁定) # 6. 链路正常后开始协议层握手 protocol_layer_handshake(cfg_protocol) print(UCIe link is UP)这个流程看着简单实际工程里每一步都有很多细节。第一步的电源域检查就常出问题多个die的电源域上电时序不一致导致UCIe PHY的复位释放时机不对链路就起不来。第二步的能力集协商要求两边的固件版本和寄存器映射表保持一致否则读到的peer_cap全是0一问一个不吱声。第四步的物理层训练是问题高发区尤其是均衡系数自适应收敛慢或者根本不收敛的情况。这时候优先去检查信道阻抗设计有没有达标走线有没有跨分割参考平面其次再看训练参数配置是否正确。一般来说硅前仿真做得越充分硅后训练阶段踩的坑越少这条经验我屡试不爽。5. 常见问题与避坑实录5.1 链路训练失败、误码、重传风暴的排查实际调试UCIe链路的时候绝大部分问题集中在三种现象链路训练失败、随机误码率高、CRC重传风暴。链路训练失败先看边带通道是否正常。边带是单端低速信号时序和电平要求相对宽松但它信号质量太拉的话双方连握手都握不上。如果边带正常再用边界扫描类方法确认时钟信号有没有起来模拟前端有没有从reset状态释放。边带、时钟、电源这三项排掉之后大多数训练失败都能定位到信道问题基本就是走线阻抗或信号完整性的锅。随机误码率高首先考虑电源噪声其次是串扰最后才是收发端均衡问题。判断方法很简单看误码出现的时机如果刚好跟某些固定数据pattern相关大概率是码间干扰如果是全随机分布电源干扰的可能性更大。用示波器实测一下高速信号的片上眼图监视器能很快缩小范围。CRC重传风暴通常不是物理层问题而是适配层的配置错位。比如收发双方的flit大小不一致、CRC开关状态不匹配、或者是重传缓冲区大小设置不合理导致溢出。这种情况下不要盲目去调物理层先把适配层的寄存器状态读一遍对比两边的版本和配置往往能快速定位。5.2 几个被问烂了的概念澄清-UCIe和PCIe/CXL是什么关系 UCIe协议层原生支持PCIe和CXL。UCIe是die之间传输数据用的物理和适配标准PCIe/CXL跑在UCIe上面。系统层面看UCIe只是把PCIe/CXL设备“拆”成多个die再连起来对外表现一致。-UCIe用差分还是单端 关键看封装模式标准封装下数据走差分先进封装下数据走单端时钟基本都用差分转发边带走单端。以后谁再问直接甩这句话过去。-UCIe是免费的吗 UCIe规范是开放的但IP核不免费。不同IP厂商的授权模式不一样有些按项目收费有些按量产数量收费评估的时候要算清楚。-非要做Chiplet就一定要用UCIe吗 不一定UCIe是主流选项不代表唯一选项。还可以用私有协议或者别的D2D标准但生态支持力度差别很大。自研D2D接口的维护成本极高除非有特别硬核的理由否则建议优先UCIe。-UCIe 3.0现在能用到产品里吗 不能。目前还没正式发布不要为传闻中的特性调整产品规划老老实实按已发布版本设计。5.3 我实践下来最重要的避坑顺序第一架构阶段就决定封装路线。我见过太多项目把封装决策拖到物理设计中期结果返工成本巨大。UCIe的不同封装模式直接决定管脚和物理层选型一定前置。第二先跑通最简配置再谈优化。很多团队一上来就追求满速、全带宽、低功耗结果是三个目标一个都没实现。建议先按UCIe IP厂商的参考配置把链路跑起来再做逐项调优一步一步来。第三从第一天就建立硅前仿真和硅后测试的闭环。UCIe链路看不见摸不着出了问题要能随时对比仿真和实测数据。没有这个闭环光靠感官经验调试效率极低。第四别忽略边带通路的设计。UCIe调试里最难受的场景就是主链路没起来而边带也一言不发你连状态信息都拿不到。边带通路虽然速度低但它是调试生命线一定要保证信号完整性和逻辑正确。最后说点实在的体会。UCIe这项技术看着是标准文档实际拼的是系统工程能力封装、板级、电源、固件、协议软件全要打通。我见过多个团队在单个维度上都做得不错但一到系统联调就抓瞎。原因就是大家只盯自己的模块忽略了链路是一个整体。做UCIe最忌讳的就是“我这边肯定没问题有问题一定是对方那边”。真要顺利落地团队里得有人从物理层一直盯到协议层对整个链路有完整认知。这一点比用什么IP、选什么封装都重要。
这两年只要聊到ChipletUCIe就是绕不开的名字。做芯片的人都知道Chiplet把一颗大SoC拆成多个小die思路很好但拆完之后怎么把这些die又快又稳地连起来才是真正决定成败的地方。UCIeUniversal Chiplet Interconnect Express就是把这个问题标准化的答案。它定义了die与die之间的物理层信号、链路层握手和上层协议映射目标很明确让不同厂商、不同工艺、不同封装的Chiplet像乐高积木一样拼在一起。这篇内容我会从标准背景、技术分层、版本演进、工程落地和常见坑几个方向聊一遍适合做芯片架构、封装集成、系统验证的朋友也适合刚开始接触Chiplet、想搞明白UCIe到底是什么的新人。1. Chiplet时代UCIe凭什么成为互连的“通用语言”1.1 为什么Die-to-Die互连需要一个统一标准传统SoC是一整颗die所有模块通过片内总线通信距离短、延迟低、信号干净。但到Chiplet时代一颗大芯片变成了几个diedie与die之间要么通过基板走线要么通过硅中介层连接信号要跨出die的边界在封装内“远行”。这时候你会发现片内总线的假设全部不成立了信道更长、阻抗不连续、串扰变大、校准要求变高连电源噪声都不一样。在没有UCIe之前各大厂都在用私有die-to-die接口。AMD用自家Infinity Fabric做ChipletIntel早些年推AIB开放社区还有BOW这类的并行接口方案。每个方案都绑定了特定的封装材质、特定的物理层设计、特定的控制器等于每家都得自己维护一套接口IP、验证环境和封装规则。这对行业是巨大的重复劳动。更重要的是它没法形成生态你用台积电的工艺做了一个CPU die拿给另一个厂商的加速die去配如果接口标准对不上根本没法互操作。Chiplet要想做成“产业分工”而不是“一家独大”第一步就是统一接口语言。UCIe就是在这个背景下被推上台面的。不妨这么理解传统SoC像一个人包办所有工作Chiplet像一个团队协作但团队协作需要统一的工作流和交流语言。UCIe就是这个语言标准。1.2 从UCIe联盟到“开放标准”免费不等于开源UCIe联盟在2022年3月正式对外发布了UCIe 1.0规范创始成员名单基本覆盖了整个半导体产业链Intel、AMD、Arm、台积电、三星、ASE、Google Cloud、Meta、Microsoft、Qualcomm等。这不是某一家公司关起门来定的私有标准而是由联盟成员共同推动、面向全行业开放的规范。注意这里要区分两个概念开放标准和开源。UCIe是一个开放标准规范文档可以申请获取但接口IP核不是白送的通常需要向IP厂商购买授权或者自己实现。这跟Linux这种开源软件是完全不同的模式。对企业来说UCIe降低的是“互操作成本”而不是“IP成本”。联盟的架构分得很细有物理层工作组、协议层工作组、封装工作组、合规性测试工作组等后面我们聊到的很多参数细节都是这些工作组来回拉扯的结果。这种组织方式决定了一件事UCIe的演进是相对缓慢但靠谱的不会像开源社区那样三天两头改接口。1.3 UCIe的定位先兼容PCIe/CXL再做新的扩展UCIe在协议层设计上做得非常聪明它没有另起炉灶发明一套全新的上层协议而是把PCIe和CXL直接搬了进来。PCIe是几乎所有服务器、PC、加速卡都支持的标准CXL是当下内存扩展和缓存一致性的主流互连协议。UCIe的协议层原生支持这两者意味着上层软件栈基本不需要改动。打个比方UCIe干的活是“标准插座”而不是重新发明“用电标准”。你的设备只要支持PCIe/CXL插到UCIe这个插座上系统看到的就是一个标准的PCIe/CXL设备完全无感。这为Chiplet大规模商用扫清了最大的障碍软件生态。除此之外UCIe还定义了Streaming模式和Raw模式前者是给需要高吞吐定制协议的加速器用的后者是裸管道给那些想完全自己定义链路的深度玩家留了后门。后面我在协议层部分会展开讲。2. 从物理层到协议层一层层拆开UCIe2.1 三层架构解决的问题UCIe的逻辑架构分为三层物理层Physical Layer、Die-to-Die适配层D2D Adapter Layer、协议层Protocol Layer。很多第一次接触的人会觉得这是不是太复杂了直接像PCIe那样拉起一条高速链路不就行了但Chiplet场景和板级PCIe场景差别很大分层是必须的。物理层负责信号在封装信道上的可靠传输包括驱动电流、端接、时钟转发、接收均衡等。适配层相当于“翻译官”把上层协议的数据转换成适合物理层收发的flow control信号同时负责链路的初始化、训练、校准、CRC校验和链路级重传。协议层则决定链路上跑的是什么语义是PCIe事务、CXL事务还是你自定义的流式数据。分层的核心价值在于解耦。你可以在协议层跑CXL但物理层随时换封装从标准封装换成先进封装适配层不需要动你也可以保持同一套物理层在协议层从Streaming模式切换到PCIe模式接口管脚定义不变。实际项目中这套分层结构能省掉大量重新谈判管脚和封装的成本。2.2 物理层差分还是单端取决于你用什么封装先直接回应很多人问过的问题UCIe采用差分信号吗正确答案是“不一定是取决于封装模式”。这也是UCIe在设计上比较实际的地方。UCIe定义了两种物理层选项分别对应不同的封装场景。第一种是标准封装模式也就是die通过有机基板、RDL走线互连信道长度相对较长损耗和串扰都要认真对待。这种模式下主链路数据和转发的时钟都采用差分信号differential signaling传输。差分信号的好处很明显抗共模噪声强、对地弹不敏感、EMI表现好适合在损耗较大的基板信道上跑高速。这个时候管脚数会翻倍因为一对信号需要两个物理pin但换来的信号质量是值得的。第二种是先进封装模式比如通过硅中介层CoWoS类、InFO-LSI或者3D堆叠互连die之间的信道极短信道干净、损耗很小。这种模式下主链路数据用单端信号只有时钟仍然保持差分转发。单端信号占用的物理通道少一半带宽密度更高功耗也明显下降。距离短到一定程度复杂的差分传输反而成了浪费。边带信号sideband的情况也要说清楚。UCIe定义了一条低速的边带通道用来做链路训练、状态协商和维护管理这条通道是单端信号。也就是说一个UCIe物理层接口里面是“差分单端”并存的不能一刀切说UCIe用了差分或者没用差分。速率方面UCIe 1.0定义的标准封装模式每lane可以跑到32GT/s量级先进封装模式还能更高。实际产品一般会组成x4到x16不等的链路就是多个lane并行工作。这里想提醒一句很多人看速率只看单lane带宽但Die-to-Die互连最重要的指标其实是带宽密度也就是在单位mm边缘上能传多少数据。单端信号在先进封装下的优势说到底就是在带宽密度这个指标上碾压差分。2.3 D2D适配层训练、检错和重传的秘密适配层D2D Adapter Layer是UCIe里最容易被低估的一层。它的职责包括链路初始化、训练与校准、链路状态管理、CRC校验、链路级重传、协议多路复用等。链路一开始上电时收发双方并不知道对方的预期速率、lane配置和协议模式。适配层会通过边带通道交换能力集协商出一套双方都支持的配置然后启动物理层的训练序列。训练过程包括时钟恢复、接收端均衡器系数的自适应调整、眼图开度的探测这些步骤做完链路才算进入可用的Up状态。训练完成之后适配层要做的事情更多。它会在数据流上切分成固定大小的flit每个flit里包含头信息、数据和CRC校验字。接收方每收到一个flit就校验一次一旦发现CRC错误就触发链路层重传。这个机制跟PCIe的重传有些类似但用于die-to-die短距离场景延迟开销要小得多。有人可能会问既然信道这么短为什么还需要CRC和重传答案是封装和基板的工艺缺陷、电源噪声、串扰仍然可能引入瞬态错误不做链路层保护一旦出错就只能靠上层的协议层恢复延迟会大得多。适配层还负责协议多路复用。当一个UCIe链路上同时跑PCIe和CXL流量时适配层会根据数据包头把流量分发到对应的协议通道。此外还定义了Raw模式相当于绕过协议层直接对接适配层这在定制加速器场景非常有用。用一句话总结适配层的作用让上层协议感觉不到物理层的存在尽量做到透明可靠的数据管道。2.4 协议层PCIe、CXL、Streaming和Raw怎么选协议层是用户最直接接触的部分UCIe的协议层支持PCIe、CXL、Streaming和Raw这几类模式。如果Chiplet产品最终要挂到主机系统里当标准设备用比如一个IO die连接PCIe交换机或者CPU那协议层直接选择PCIe就好了让主机认为这个Chiplet就是一个PCIe设备。如果涉及内存扩展或者缓存一致性CXL是更合适的选择。用UCIe把两个die连接起来对外呈现为完整的CXL设备这种模式已经在不少原型系统上验证通过了。Streaming模式是给需要极高吞吐、低延迟且协议固定的场景准备的。比如一个AI加速器die和一个存储die之间的数据通路走PCIe的话头开销太大走Streaming模式可以直接定义自己的数据格式在适配层之上做扁平传输效率高得多。代价是生态不通用数据的含义只有自己知道不适合做产业互联。Raw模式则是完全绕开协议封装直接让上层应用控制适配层和物理层。这个模式适合芯片内部调试、定制链路实验、或者自己设计轻量协议。如果你不想被UCIe绑定的协议层约束Raw模式是最自由的但自由的另一面是很多东西要自己实现。选哪种模式没有绝对的对错核心是看产品形态对外标准接口优先选PCIe/CXL内部加速器互联优先选Streaming想快速做芯片验证选Raw最简单直接。3. UCIe版本演进从1.0、1.1到2.0还有热议的3.03.1 UCIe 1.0/1.1把地基打牢UCIe 1.0发布于2022年3月定义了整个标准的框架包括物理层、适配层、协议层、标准封装和先进封装两种选项以及PCIe/CXL/Streaming等传输模式。1.0版本已经可以支撑实际产品的开发到现在为止仍然有不少Chiplet方案基于1.0在做。1.1版本是在1.0基础上的小步快跑重点补了一些工程化的细节包括带外管理的增强、互操作性测试方法的完善、以及一些针对不同封装形态的优化。1.1没有改动整体架构但让不同厂商的UCIe实现之间更容易对接成功。这里说一个实际经验UCIe这种标准大家最容易忽略的是合规性测试。纸面上大家都说支持UCIe 1.1但真正把两个不同厂商的die连起来问题全在细节上比如训练序列的超时时间、边带信号的时序、均衡系数的初始值。所以从1.1开始联盟花了很多精力在定义互操作测试规范上这对行业来说是很有价值的工作。3.2 UCIe 2.0面向3D封装和AI负载的大版本UCIe 2.0是2024年发布的重大版本更新它最重要的变化是加入了3D封装的正式支持包括面对面的die堆叠方式face-to-face。3D封装跟2D封装最大的区别是信道更短但复杂度大幅上升对错位、翘曲、热应力的容忍度更低。2.0围绕3D场景重新定义了物理层的设计目标和封装规则让UCIe可以适配更激进的异构集成方案。除了物理层2.0在管理和安全上补了很多功课。它加入了对链路完整性、数据保密性、防篡改等安全机制的定义还增强了可管理性接口支持更完善的调试、遥测和故障隔离功能。这些特性对服务器和数据中心场景尤为重要毕竟Chiplet产品如果出了问题定位到具体die和具体链路的能力直接决定了运维成本。另外2.0针对AI工作负载做了专门的优化。AI加速器通常是多die并发协同数据搬运量极大对带宽密度的要求远高于传统CPU。2.0扩展了面向这类多die、高带宽、低延迟场景的配置选项比如更大的链路宽度支持、更灵活的多通道复用机制。很多人把2.0看作UCIe从“能用”走向“好用”的关键版本。3.3 行业热议的UCIe 3.0还没发布但方向清晰最近“UCIe 3.0”这个词在社区里越来越热。先说明一下目前联盟官方还没有正式发布UCIe 3.0规范但是行业里关于下一代标准的讨论已经很充分方向也基本清晰。从公开信息和产业链反馈来看UCIe 3.0的讨论热点集中在几个方面一是更高带宽密度继续往上推速率可能到64GT/s甚至更高同时进一步压低单位比特功耗二是更长距离的互连比如面向面板级封装Panel-level Packaging的传输需求信道比传统硅中介层更长意味着物理层要做更多均衡和编码方面的工作三是更灵活的多die网络拓扑现在的UCIe链路基本是point-to-point下一代可能会在网络化拓扑、多跳路由方面做文章四是和光互连、光I/O的结合这会是面向数据中心大规模Chiplet系统的长期方向。对这些还停留在讨论阶段的方向我的建议是产品选型不要抢跑。除非你有明确的长期规划节点否则现阶段选择已经成熟的UCIe 1.1或者2.0实现是完全够用的。追赶尚未冻结的规范就像踩在浮桥上跑步风险远大于收益。4. 落地UCIe的工程实践封装、信号完整性与协议配置4.1 标准封装还是先进封装先算一笔成本账做UCIe产品第一步不是写代码而是决定采用哪种封装。标准封装模式成本低、供应链成熟适合大多数中低密度互连场景先进封装模式带宽密度高、功耗低但成本、供应链和散热复杂度都会上升。维度标准封装Standard Package先进封装Advanced Package信号形式差分数据 差分时钟单端数据 差分时钟带宽密度中等高信道长度较长基板走线为主极短硅中介层/3D堆叠单位功耗偏高很低成本与复杂度低成熟供应链高良率/热应力挑战大典型场景消费级Chiplet、IO dieAI加速器、高性能计算这个表格是选型的起点。我见过不止一个项目一开始因为追求先进封装的炫酷参数上了CoWoS结果发现量产良率和成本完全扛不住最后不得不退回标准封装重新做物理层。反过来也有项目因为带宽密度实在满足不了业务需求咬牙上先进封装反而跑通了。工程决策没有银弹就是拿需求卡预算。另外提醒一下封装模式的选择会直接影响UCIe的管脚定义和物理层约束比如驱动强度、端接方案、均衡档位都要跟着变。所以这个决策一定要尽早做最好在architecture阶段就定下来否则后期换封装等于重新做一遍PHY。4.2 信号完整性差分线、阻抗和时钟分配的核心点UCIe链路能不能跑上去一半看信号完整性设计。先讲差分信号。标准封装模式下数据lane和转发时钟都是差分对PCB和基板上的差分走线要控制特征阻抗常见目标是85Ω差分阻抗具体值跟UCIe IP实现和封装模型有关。走线要做到等长等间距特别是P和N之间不要有大的长度差否则共模转差模会直接劣化眼图。时钟分配方面UCIe使用转发时钟架构也就是发送端在发数据的同时把一路时钟信号跟数据一起发到接收端。接收端利用这路时钟对数据进行采样避免了复杂的CDR电路。这带来一个好处链路训练更快抖动要求相对宽裕。但代价是时钟走线必须跟数据lane同步长度匹配非常重要。实测中时钟对和数据对的skew偏大是导致误码率骤升的常见原因之一。电源完整性也特别容易被忽略。UCIe高速收发电路工作时会有很大的瞬态电流如果电源网络设计不好电源噪声耦合到信号上就会表现为随机误码而且这种误码用常规的阻抗检查很难发现。我的习惯是在仿真阶段就把PDN网络和差分走线一起建模做完整的电源-信号协同仿真实测阶段再结合片上眼图监视器对比双管齐下。先进封装模式下信道短很多信号完整性问题相对轻但bump排列、RDL走线、以及3D堆叠时的热应力对信号的影响会变成新难点。这种场景下跟封装厂的协同设计比自身电路设计更关键。4.3 一次典型链路初始化的配置过程UCIe的链路初始化看似黑盒其实有固定的流程。我这里以一套常见的UCIe PHY控制器为例写一个简化的初始化序列帮助大家理解整个过程。# UCIe链路初始化简化示例伪代码 # 1. 确保物理层电源域正常复位释放 phy_power_up() assert phy_reset_done() # 2. 读取sideband能力寄存器协商模式 cap sideband_read(REG_CAPABILITY) peer_cap sideband_read(REG_PEER_CAPABILITY) # 3. 配置链路宽度、速率、协议模式 cfg_lane_width min(cap.lane_width, peer_cap.lane_width) cfg_speed min(cap.max_speed, peer_cap.max_speed) cfg_protocol PROTOCOL_PCIE # 或CXL / STREAMING / RAW adapter_configure(cfg_lane_width, cfg_speed, cfg_protocol) # 4. 启动物理层训练 phy_start_training() # 5. 等待训练完成链路状态进入UP timeout 0 while not adapter_link_up(): timeout 1 if timeout LIMIT: dump_sideband_status() raise LinkTrainFailed(sideband状态异常/时钟未锁定) # 6. 链路正常后开始协议层握手 protocol_layer_handshake(cfg_protocol) print(UCIe link is UP)这个流程看着简单实际工程里每一步都有很多细节。第一步的电源域检查就常出问题多个die的电源域上电时序不一致导致UCIe PHY的复位释放时机不对链路就起不来。第二步的能力集协商要求两边的固件版本和寄存器映射表保持一致否则读到的peer_cap全是0一问一个不吱声。第四步的物理层训练是问题高发区尤其是均衡系数自适应收敛慢或者根本不收敛的情况。这时候优先去检查信道阻抗设计有没有达标走线有没有跨分割参考平面其次再看训练参数配置是否正确。一般来说硅前仿真做得越充分硅后训练阶段踩的坑越少这条经验我屡试不爽。5. 常见问题与避坑实录5.1 链路训练失败、误码、重传风暴的排查实际调试UCIe链路的时候绝大部分问题集中在三种现象链路训练失败、随机误码率高、CRC重传风暴。链路训练失败先看边带通道是否正常。边带是单端低速信号时序和电平要求相对宽松但它信号质量太拉的话双方连握手都握不上。如果边带正常再用边界扫描类方法确认时钟信号有没有起来模拟前端有没有从reset状态释放。边带、时钟、电源这三项排掉之后大多数训练失败都能定位到信道问题基本就是走线阻抗或信号完整性的锅。随机误码率高首先考虑电源噪声其次是串扰最后才是收发端均衡问题。判断方法很简单看误码出现的时机如果刚好跟某些固定数据pattern相关大概率是码间干扰如果是全随机分布电源干扰的可能性更大。用示波器实测一下高速信号的片上眼图监视器能很快缩小范围。CRC重传风暴通常不是物理层问题而是适配层的配置错位。比如收发双方的flit大小不一致、CRC开关状态不匹配、或者是重传缓冲区大小设置不合理导致溢出。这种情况下不要盲目去调物理层先把适配层的寄存器状态读一遍对比两边的版本和配置往往能快速定位。5.2 几个被问烂了的概念澄清-UCIe和PCIe/CXL是什么关系 UCIe协议层原生支持PCIe和CXL。UCIe是die之间传输数据用的物理和适配标准PCIe/CXL跑在UCIe上面。系统层面看UCIe只是把PCIe/CXL设备“拆”成多个die再连起来对外表现一致。-UCIe用差分还是单端 关键看封装模式标准封装下数据走差分先进封装下数据走单端时钟基本都用差分转发边带走单端。以后谁再问直接甩这句话过去。-UCIe是免费的吗 UCIe规范是开放的但IP核不免费。不同IP厂商的授权模式不一样有些按项目收费有些按量产数量收费评估的时候要算清楚。-非要做Chiplet就一定要用UCIe吗 不一定UCIe是主流选项不代表唯一选项。还可以用私有协议或者别的D2D标准但生态支持力度差别很大。自研D2D接口的维护成本极高除非有特别硬核的理由否则建议优先UCIe。-UCIe 3.0现在能用到产品里吗 不能。目前还没正式发布不要为传闻中的特性调整产品规划老老实实按已发布版本设计。5.3 我实践下来最重要的避坑顺序第一架构阶段就决定封装路线。我见过太多项目把封装决策拖到物理设计中期结果返工成本巨大。UCIe的不同封装模式直接决定管脚和物理层选型一定前置。第二先跑通最简配置再谈优化。很多团队一上来就追求满速、全带宽、低功耗结果是三个目标一个都没实现。建议先按UCIe IP厂商的参考配置把链路跑起来再做逐项调优一步一步来。第三从第一天就建立硅前仿真和硅后测试的闭环。UCIe链路看不见摸不着出了问题要能随时对比仿真和实测数据。没有这个闭环光靠感官经验调试效率极低。第四别忽略边带通路的设计。UCIe调试里最难受的场景就是主链路没起来而边带也一言不发你连状态信息都拿不到。边带通路虽然速度低但它是调试生命线一定要保证信号完整性和逻辑正确。最后说点实在的体会。UCIe这项技术看着是标准文档实际拼的是系统工程能力封装、板级、电源、固件、协议软件全要打通。我见过多个团队在单个维度上都做得不错但一到系统联调就抓瞎。原因就是大家只盯自己的模块忽略了链路是一个整体。做UCIe最忌讳的就是“我这边肯定没问题有问题一定是对方那边”。真要顺利落地团队里得有人从物理层一直盯到协议层对整个链路有完整认知。这一点比用什么IP、选什么封装都重要。
