聊 Chiplet 最容易掉进一个坑所有人都在谈先进封装、谈互连密度有多高可真到动手的时候卡住进度的往往不是工艺能力而是三件非常具体的事——拓扑怎么摆、接口怎么定、封装怎么选。这三件事单独拎出来看都不算难难的是它们互相咬着拓扑决定了需要多少条链路链路数量决定了接口位宽和速率而位宽和速率又直接压到封装的凸点数量和走线密度上反过来封装能提供的布线资源又限死了你拓扑能画成什么样子。我做过几个多裸片multi-die方案也踩过只考虑逻辑拓扑、没考虑物理落地的坑。这篇就按我自己的思路把这三块串起来讲从为什么要拆到拓扑形态怎么取舍到 Die-to-Die 接口的参数怎么算、链路怎么训练再到封装形态、凸点间距、基板协同最后给一套从需求到样片的落地流程和一份问题速查表。刚接触这个概念的朋友能看懂全貌已经上手的朋友可以重点看第二、三、四章的算账部分和第六章的排查顺序。1. 先把 Chiplet 拆开三个绕不开的核心问题Chiplet 这个词现在被用得很泛有人拿它指代任何多裸片封装有人特指符合某个具体互连标准的方案。我更愿意把它还原成一句大白话把原来画在一张大硅片上的电路切成几块小硅片再通过封装里的高密度互连把它们重新变成一个系统。拆的动作是手段重新连起来才是目的而连这个动作正好对应三个问题连成什么形状拓扑、用什么规则连接口、在什么介质上连封装。1.1 为什么把大芯片切开反而更划算最直接的推力是面积。光刻单次曝光的可用面积有个硬上限大约是 26mm × 33mm 这个量级超过就得靠拼接曝光成本和难度陡增。一块 800mm² 级别的芯片已经贴着天花板走而当你需要更多计算单元、更多缓存、更多 I/O 时面积只会继续涨。第二个推力是良率。硅片上的缺陷是按密度分布的面积越大落在有效区域里的概率越高。用最粗的模型算良率约等于缺陷密度乘以面积的指数衰减。假设缺陷密度是每平方厘米 0.3 个一块 200mm² 的裸片良率大概在 94% 上下而 800mm² 就只有 79% 左右。四个小裸片平均下来的成品率看着差不多但关键在于筛小裸片可以逐颗测试、只挑好的用坏一颗换一颗大芯片坏一个角落整颗几万块的硅片直接报废。这个可替换性带来的收益比单纯的良率公式算出来的要实在得多。第三个推力是工艺异构。SerDes、模拟前端、电源管理这些模块对先进节点的收益很小放在成熟节点上做成本低、风险小、迭代还快而计算核心和高速缓存必须吃先进节点的红利。把两者分到不同裸片上各用各的节点这才是 Chiplet 最被低估的价值。存储同理大容量 SRAM 在有些节点上单位面积成本并不划算单独做一颗存储裸片反而更灵活。1.2 拓扑、接口、封装是一条因果链不是三个独立选项我见过不少方案在架构评审阶段就把拓扑定了八个计算裸片做 2D Mesh四个方向各连一条链路。听起来很漂亮等到了封装团队那边才发现中介层的可用布线层数和凸点区域根本排不下这么多链路最后被迫砍掉两个方向的连接Mesh 退化成了一条不闭合的环带宽直接掉一半前期基于 Mesh 做的延迟估算全部作废。所以这三个东西的正确处理顺序是先根据流量特征确定逻辑拓扑再由拓扑推导出每条链路的带宽和延迟预算据此算出接口的位宽、速率和通道数然后把这些接口映射到具体的凸点布局上看封装是否放得下如果放不下就回头调拓扑或者调接口参数。这是一个至少要走两到三轮的迭代过程一轮定方案的想法基本都会返工。1.3 不同角色该盯住哪一块多裸片项目里参与方的关注点差别很大我整理了一张表方便你对号入座也方便开会时知道该拉谁进来。角色首要关注最常踩的坑架构/算法流量模型、拓扑形态、带宽与延迟预算只算平均带宽忽略突发和热点数字设计协议层与适配层、跨裸片地址映射把跨裸片访问当成片内访问来写时序假设后端/DFT凸点映射、电源完整性、可测性设计测试通路设计得太晚没有预留探针位置封装/工艺中介层或基板选型、翘曲与散热被架构催着定方案走线余量没留够系统/软件枚举流程、设备发现、管理接口假设上层永远能看到一颗芯片这张表里最值得强调的是最后一行。软件视角如果处理不好前面硬件做得再漂亮也白搭。多裸片系统上电后操作系统看到的到底是几个设备、地址空间怎么拼、热插拔和复位怎么处理这些在方案早期就得定不能等到流片前才补。2. 拓扑怎么选从点到点到 Mesh 的取舍逻辑拓扑这个词在软件和硬件里有不同的语境计算图调度里的拓扑排序和互连拓扑结构完全是两回事只是名字撞了车。这一章只谈物理意义上的互连形态也就是裸片之间到底以什么形状连起来。2.1 拓扑本质是四个指标的博弈任何一个拓扑方案最终都是在四个指标之间做加减法。对分带宽是最核心的指标。把系统从中间切成两半跨过切面的总带宽就是对分带宽。它决定了系统最坏情况下的通信能力。一个只连成一条链的拓扑对分带宽就是那条链的带宽因为任何跨过切面的通信都得走这条独木桥。直径指的是任意两个节点之间最短路径的最大跳数。跳数越多延迟越高而且拥塞时延迟抖动会放大。先进封装里的单跳延迟可以做到很低物理层加上链路层的往返大概在几纳秒量级但你要是转五六跳累计起来就是几十纳秒跟访问一次片外存储的开销差不多了。度数是每个节点向外连出的链路数。度数越高单个裸片的边缘需要预留的凸点区域越大布线越挤而且每个端口都要一套物理层电路面积和功耗都是实打实的成本。能效常被忽略。把这些链路跑起来是要耗电的先进封装下每比特的传输能耗可以做到零点几皮焦耳标准封装下会高一到两倍。你自己算一笔账如果系统需要 1TB/s 的双向互连那就是每秒 16 万亿比特的吞吐按每比特 0.5 皮焦耳算光互连就要吃掉 8 瓦。这个数字在功耗预算紧张的产品里是要命的会逼着你重新审视拓扑是不是画得太奢侈。2.2 几种常见形态的实际适用边界我在项目里真正用过的形态有这几种按规模从小到大排列。点到点。两个裸片直接连布线最简单延迟最低没有路由和仲裁的开销。适用场景很明确计算裸片配一颗 I/O 裸片或者主控配一颗专用加速器。缺点是扩展性为零加第三个裸片就得重新设计。星型或集中交换。设一个中心裸片其他裸片都连到它上面。延迟是两跳结构清晰管理简单。问题是中心节点的端口数和布线压力随节点数线性增长而且中心节点一旦出问题整系统就废了。适合五六颗裸片以内、流量模式以中心节点为核心的场景。环Ring。所有节点首尾相连。布线极其规整非常适合在中介层上实现每个节点只需要两个方向的端口。对分带宽是环的两倍因为可以往两个方向走延迟随节点数线性增长节点多了就顶不住。我的经验是四到六个节点用环很舒服超过八个就要小心因为最远两点的跳数会变成节点数的一半延迟和拥塞都开始难看。Mesh 网格。二维网格是当前大规模多裸片方案里最常见的形态每个节点连上下左右四个邻居。它的优势是扩展性好、布线规律、对分带宽随规模增长。缺点也很明显边缘节点和中心节点的通信距离差异很大流量分布不均时容易在中间区域形成热点。另一个实际问题是四个方向的端口意味着每个裸片四条边都要留出互连区域对面积规划是个硬约束。交叉开关Crossbar。任意到任意的全连接延迟最低、带宽最高。代价是布线数量和端口数量随节点数平方增长实际项目里超过四五个节点就不现实了。它更多用在交换裸片内部而不是裸片之间的互连。层次化结构。把节点分成若干簇簇内用高带宽低延迟的紧密连接簇间用少量高带宽链路串起来。这是我目前最推荐的大规模方案既能控制单个裸片的端口数又能保证簇内的通信效率代价是跨簇通信的延迟和带宽需要仔细规划。拓扑端口数/节点布线难度扩展性典型规模主要问题点到点1极低无2无法扩展星型1中心 N-1低中3-6中心瓶颈与单点风险环2低中4-6延迟随规模线性增长Mesh4中好8 以上边角不均、热点集中交叉开关N-1极高差不超过 5布线爆炸层次化2-4中很好8 以上跨簇路径规划复杂2.3 用一个流量模型来验算拓扑够不够用拓扑定了以后不要急着往下走先拿真实的流量模型跑一遍。我自己习惯做三件事。第一件画出通信矩阵。把所有裸片两两之间的平均带宽和峰值带宽列成矩阵。如果矩阵里某一行明显比其他行重说明那个裸片是天然的枢纽应该给它更多端口或者干脆把它放到中心位置。第二件算最坏路径延迟。以 Mesh 为例8 个节点排成 2×4最远两点的曼哈顿距离是 13 等于 4 跳改成 3×3 就是 4 跳。按每跳 3 纳秒算单程 12 纳秒往返 24 纳秒。这个数字要拿去和内存访问延迟、缓存行填充时间做比较看是否可接受。如果某类流量对延迟极其敏感就得在拓扑上给它开专线比如把两个交互密集的裸片直接相邻摆放把跳数压到 1。第三件估对分带宽的利用率。假设所有裸片同时向对面的一半发起全带宽通信你现在的拓扑能承受多少比例。这个比例长期超过 70% 就是危险信号因为实际系统里一定有突发和热点留不出余量就会在压力测试下崩。2.4 逻辑拓扑和物理拓扑必须分开看这是我最想强调的一点。逻辑上的 Mesh 不意味着物理上也要画成规整的网格。实际项目里物理层面的连线往往受制于凸点布局会呈现出一条条链式串联的样子这就是大家常说的菊花链式fly-by拓扑。这个词在板级 DDR 布线里用得更多控制器到各个存储颗粒的走线依次串下去每条支路的长度不同靠写均衡来补偿时序差异。把这种串联思路用到裸片互连上也一样如果每个裸片只有一个进口和一个出口物理上最省凸点但逻辑上它可能表现得像一条长链中间节点的延迟会明显高于两端。这时候要么在协议层做补偿要么在物理上给关键节点加一条旁路。还有一个容易被忽略的问题是路由死锁。只要拓扑里存在环就必须考虑路由算法是否无死锁。常见做法是采用确定性的维序路由配合虚通道来打破环路依赖。这些细节在方案评审时经常被跳过等项目后期发现偶发挂死才回头补代价非常大。3. 接口怎么定从协议分层到参数计算接口这一层是最容易写出漂亮文档、也最容易在实现时翻车的地方。我见过接口定义写了几十页结果没人写清楚链路训练失败时寄存器里哪个位会置起来最后排查问题靠猜。3.1 短距互连为什么普遍走并行片间互连和板级高速接口的思路不太一样。板级走线长、损耗大所以普遍采用串行加均衡的方式把速率推到很高用少量差分对承载大带宽。而同一封装内的裸片间距离短损耗小更适合用较宽的并行总线每条线速率适中靠位宽堆带宽。这么选的理由很直接并行总线的物理层电路简单每条通道的时钟恢复和均衡开销小能效更好位宽宽了以后单条线的速率不用推到极限信号完整性压力小。代价是走线数量多对凸点区域和布线层数的占用大。所以你会看到一个明显的取舍先进封装能提供更高的布线密度就允许更宽的并行接口标准封装的布线稀疏就只能降低位宽、提高单线速率。3.2 协议栈该分成几层一个完整的裸片间接口从下往上大致分四层这个分层思路在各种公开的互连规范里都差不多。物理层负责电气驱动、采样、时钟、训练。它管的是这条线上的电平能不能被正确识别包括驱动强度、终端匹配、采样点选择、眼图优化。链路层负责把位流组织成可靠的数据包做循环冗余校验、重传、流控。它保证的是我发出去的一串数据对方收到的和我发的完全一样。适配层是裸片间接口特有的东西它的作用是抹平协议层的差异把上层的读写事务翻译成链路层能承载的格式。这一层还负责把不同的上层协议——比如以内存语义为主的、以设备枚举为主的、以及纯流式的——统一到同一条物理链路上。协议层就是上层真正在用的那套东西可能是一套内存一致性协议也可能是一套设备互连协议甚至可以是完全自定义的流式协议。分层带来的好处是物理层和链路层可以独立演进上层协议不用跟着改。坏处是层与层之间的接口必须定义得极其清楚尤其是错误上报和恢复流程。我在实际项目里见过因为适配层对重试语义理解不一致导致上层以为写成功了、下层其实丢了包的情况排查了两个多月。3.3 参数怎么算从一个具体例子说起我拿一个真实推演过的例子来算。假设某个方向需要 100 GB/s 的有效带宽。第一步先定单通道速率。先进封装下单条数据线跑到 16 GT/s 是比较稳的选择再往上对均衡和功耗的要求会陡增。第二步算编码效率。如果用的是 128b/130b 这类轻量编码效率约 98.5%如果用的是 8b/10b效率只有 80%这在现代裸片互连里已经很少用了除非对直流平衡有特殊要求。第三步定位宽。有效带宽 单线速率 × 位宽 × 编码效率 ÷ 8。反推一下100 GB/s × 8 ÷ (16 GT/s × 0.985) ≈ 50.8取整就是 52 条数据线。工程上会往上凑到 64 条因为 2 的幂次对于位交织、通道映射、故障降级都更友好而且留出了做坏道替换的余量。第四步看通道切分。64 条线通常不会作为一个整体来管理而是切成 4 个 16 线的通道组每组有独立的时钟和独立的训练流程。这样做的好处是单组出问题时可以降级运行坏一组剩下三组还能工作带宽掉 25% 而不是掉 100%。把几个量级放在一起对比会更清楚。参数含义先进封装典型量级标准封装典型量级单线速率每条数据线的传输速率4-32 GT/s4-16 GT/s凸点间距相邻互连凸点的中心距40-55 微米100-130 微米单模块位宽一个通道组的数据线数16-648-16传输能效每比特传输能耗0.3-0.5 皮焦耳1-2 皮焦耳单跳延迟物理层加链路层往返数纳秒数纳秒到十几纳秒这里我要提醒一句上面这些数字都是量级参考具体项目一定要以你所选规范的当前版本和代工厂的实际工艺能力为准直接照抄表格里的数去做设计会出事。3.4 链路训练和侧带通道别等到出问题才想起它链路训练是裸片间接口能不能跑起来的第一次大考。上电之后两边并不知道对方的速率、位宽、通道映射关系需要一步步协商先在最慢最稳的模式下建立连接交换能力信息协商出共同的最高工作点然后逐通道调整采样相位和均衡参数最后做误码测试确认质量达标。这个过程通常靠一条独立的侧带通道来承载。侧带通道速率很低但必须极其可靠因为它是唯一的救援通道。主通道训练失败时重试指令、参数调整、复位请求全得靠它传。侧带通道上跑的管理接口设计时一定要注意一个词幂等性。因为链路不稳定管理命令可能被重复发送如果一条写入配置的命令被重复执行导致状态错乱排查起来会非常痛苦。我的做法是给每条管理命令加序号和状态机校验重复的命令直接返回缓存结果不做二次生效。3.5 接口定义文档到底该写什么接口文档最容易写成参数罗列正确的写法是按出错时我需要什么信息来组织。我自己的清单大致包含这几块电气参数表驱动、终端、电压摆幅、眼图模板、时序参数表建立保持、采样窗口、训练序列、寄存器映射每一个状态位、中断位、错误计数器的含义和清除方式、状态机图每个状态的进入退出条件、初始化序列上电到链路可用的完整步骤、降级策略坏道怎么屏蔽、通道组怎么重组、以及管理接口的完整命令列表。其中寄存器映射这块最容易被敷衍。我坚持的一个原则是任何一个可能导致链路不可用的错误都必须有对应的状态位和计数器否则现场排查就是瞎子摸象。错误计数器还要能区分是偶发还是持续因为偶发错误可能只需要重训持续错误说明是硬件问题。跨裸片访问的地址映射规则也要写清楚尤其是访问落在裸片边界上时怎么拆分、怎么保序、怎么处理部分失败这些在文档里不写清楚软件层一定会在某个深夜给你惊喜。4. 封装怎么落地形态、凸点与协同前面两章讨论的都是想连成什么样这一章讨论能不能连得出来。封装不是把裸片放上去就完事它决定了你的拓扑和接口有多少能真正实现。4.1 从二维到三维物理上的区别到底在哪二维多芯片模块是最简单的形态几颗裸片并排贴在同一块有机基板上互连走基板的内层走线。成本低、工艺成熟但基板的线宽线距比硅片粗一到两个数量级能支持的互连密度很有限。适合互连需求不高的场景比如主控加几颗独立的存储裸片。2.5D在裸片和基板之间加了一层中介层。中介层可以是硅的也可以是有机或重新分布层做的。硅中介层能用上晶圆级的精细工艺线宽线距能做到亚微米级凸点间距也能压到几十微米互连密度比二维形态高一个档次。代价是硅中介层本身面积大、成本高而且它需要额外的工艺步骤良率也会受影响。有些方案用桥接结构只在需要高密度互连的局部放一小块硅桥其他区域走普通基板这是一个成本和性能之间很实用的折中。三维堆叠把裸片直接上下叠起来用硅通孔或者混合键合连接。混合键合能把互连间距压到个位数微米甚至更低几乎是片内互连的密度带宽和能效都有巨大优势。代价是散热路径变长、堆叠良率放大、测试难度陡增。三维堆叠适合带宽需求极端、面积又极其受限的场景比如计算裸片和它的近存之间的连接。形态互连密度相对成本散热难度典型用途二维基板低低低主控加独立存储、低速外设桥接局部高密度中高中中计算裸片与 I/O 裸片之间硅中介层 2.5D高高中多计算裸片加多存储裸片有机中介层 2.5D中高中中成本敏感的中等规模方案三维堆叠极高很高高计算与大容量近存4.2 凸点间距决定了你能连多少条线凸点间距是封装能力最直观的指标。假设一颗裸片的一整条边缘长 5 毫米凸点间距 50 微米理论上这条边能放 100 个凸点。听起来不少但这些凸点要同时承载信号、电源、地、测试和冗余真正能分配给数据的可能只有三分之一到一半。如果再考虑相邻信号之间的串扰要求实践中往往还要隔一个地一个信号那有效数据线就只剩四分之一。这个账算下来你就明白了一条边能提供的数据线数量是有限的而你的拓扑可能要求每个方向几十条甚至上百条。这时候就得做取舍——要么降低每个方向的位宽、提高单线速率要么减少拓扑的度数要么换用更高密度的封装工艺。我自己习惯在方案早期就做一张凸点预算表把每条边可用的凸点数列清楚然后按功能分配。信号、电源、地、测试这四类里电源和地的占比经常被低估。高带宽接口同时翻转的驱动器很多瞬态电流大电源和地的凸点不够电源噪声会直接反映到眼图上这不是靠调均衡能解决的。4.3 封装选型不能只看密度选封装形态的时候密度只是其中一个维度。我用过的判断维度有五个。互连密度需求。把拓扑要求的总线宽加起来除以可用边长的凸点数得出所需的密度等级据此判断是二维够用还是必须上中介层。成本结构。中介层的成本不只是材料还包括它自身的良率和装配良率。裸片数量越多装配良率的指数衰减越明显四颗裸片的装配良率可能是单颗的四次方量级。这个账要在方案阶段算清楚。散热能力。中介层会额外增加一层热阻硅中介层比有机材料导热好但下面还有基板和焊球。多颗高功耗裸片挤在一起热点会非常集中单纯看总功耗是不够的要看每平方毫米的功耗密度。机械应力与翘曲。不同材料的热膨胀系数不同硅、有机基板、中介层和焊球在温度循环下会产生应力面积越大越明显。翘曲会直接影响装配良率也会在温度变化时让互连承受额外的机械载荷。可测试性。中介层本身也需要测试裸片之间的互连也需要测试。这些测试通路要在设计阶段就预留包括探针接触点、内建自测结构、以及串联的扫描通路。测试方案定晚了很可能因为找不到探针位置而被迫加一轮改版。4.4 封装和接口必须联合迭代不能串行推进前面反复提到这一点这里给一个具体的协同流程。第一轮架构给出拓扑草图和每条链路的带宽需求。封装团队据此估算凸点预算反过来给出每条边实际能提供的数据线数量。这一轮的结果通常是接口位宽需要下调。第二轮接口团队根据实际可用线数重算速率和编码方案可能还要把原本一条宽链路拆成两条窄链路或者改用不同的通道切分方式。同时要重新评估功耗和延迟。第三轮把最终的凸点映射画出来检查电源和地的分布是否均匀、高速信号的参考平面是否连续、相邻通道之间是否有足够的隔离。这一步经常会发现个别通道的走线长度差异过大需要做长度匹配或者调整映射关系。这三轮走下来快的话几周慢的话一两个月。想省掉其中任何一轮都会在后面以更大的代价补回来。我见过最典型的翻车是跳过第三轮直接出图结果发现某个通道组的走线比同组其他通道长了将近一倍采样窗口完全对不齐只能重新做基板。5. 一次完整的落地流程从需求到样片前面讲的是原理和取舍这一章讲操作流程你可以直接拿去当检查清单用。5.1 第一步把需求拆成可量化的预算不要从我要做几颗裸片开始而要从我需要多少算力、多少带宽、多少功耗、多少成本开始。把需求翻译成三个数字总有效带宽、最坏路径延迟上限、总功耗上限。然后做一次分配总带宽里多少是裸片之间的、多少是裸片到外存的、多少是对外的。经验上裸片间互连常常会吃掉总带宽预算里很大一块如果这个比例超过一半就得反思一下是不是拆分方式不合理——拆分的目的是让通信局部化而不是把片内通信变成片间通信。5.2 第二步画出通信矩阵和通道预算表通信矩阵把每个裸片对之间的带宽需求列清楚。通道预算表则把每条物理链路拆解到通道组、位宽、速率、编码、能效。我做的通道预算表大概长这样链路方向有效带宽单线速率编码效率数据线数通道组数传输功耗A-B单向100 GB/s16 GT/s0.985644×16约 0.8 WA-C单向50 GB/s16 GT/s0.985322×16约 0.4 WB-D双向80 GB/s12 GT/s0.985644×16约 0.8 W这张表的价值在于它把抽象的带宽需求变成了可以拿去和封装团队对的物理资源数量。每一行的数据线数加上对应的电源地就是这条链路在凸点预算里占的位置。5.3 第三步凸点映射与基板走线协同这一步是接口和封装的交界处也是最容易扯皮的地方。我的做法是先用脚本把凸点映射自动生成包括信号、电源、地的分配以及与通道组的对应关系然后把映射导出给封装团队做走线规划走线规划完成后把实际的走线长度和寄生参数导回来做一次时序和信号完整性复核。如果发现某些通道的走线明显比其他通道差就在映射上做调整把关键通道换到更好的位置。这个迭代可能要跑好几轮所以自动化脚本非常值得投入。手工画凸点映射、手工核对出错的概率几乎是百分之百。5.4 第四步硅前验证、硅后验证、量产测试验证分三个阶段每个阶段的目标完全不同。硅前验证主要靠仿真和形式验证。互连部分重点看协议一致性、流控逻辑、错误处理路径。这里有个诀窍错误注入测试一定要做人为制造校验失败、超时、乱序看恢复流程能不能正常走通。只在正常路径上做验证等于没验证。硅后验证先做单裸片测试确认每颗裸片本身是好的这就是所谓的已知良好裸片筛选。然后再做封装后的互连测试从低速模式开始逐步提速率每一步都记录误码率。我建议保留一整套眼图扫描工具通过扫描采样相位和参考电压画出一张二维图能直观看出裕量有多少。压力测试也要做长时间满带宽跑观察误码计数器是否持续增长——偶尔几个错误和持续增长是完全不同性质的问题。量产测试要考虑的更多。中介层的互连怎么测、堆叠后的内部节点怎么访问、测试时间怎么控制成本这些都要在方案阶段规划。业内有一些针对三维堆叠的标准测试架构提供了从外部访问内部裸片的通路思路值得参考。5.5 时间和人力的现实预期一个中等规模的多裸片项目从架构定义到第一版样片点亮我见过的最快也要一年半左右。时间主要花在三个地方接口方案迭代、封装协同、以及各种验证。人力上光互连这一块至少要有一个懂协议、一个懂物理层、一个懂封装的人长期投入兼职做基本做不成。给一个更实际的建议第一版方案不要追求极致。先把拓扑简化把链路数量压到最少把速率定在成熟区间把完整的流程跑通一遍。等第一版点亮了、测试流程建起来了第二版再往上加带宽和密度。我自己的经验是第一版追求性能的项目返工的概率远高于第一版追求稳妥的项目。6. 常见问题与排查实录这一章是我这些年攒下来的问题清单按出现频率排序。排查的原则是先物理后逻辑、先低速后高速、先单点后系统。6.1 链路训练不过按这个顺序查训练失败是最常见的问题也是最容易乱查的问题。我固定的排查顺序是这样的先确认电压和时钟。电源有没有达到额定值、参考时钟是否存在且频率正确、复位信号时序是否符合要求。听起来很基础但我在至少三个项目里见过因为时钟没起来导致训练失败团队却花了三天在调均衡参数。再看侧带通道。侧带通不通是所有后续步骤的前提。用示波器抓侧带的波形确认命令和响应能正常收发。侧带不通却去查主通道纯属浪费时间。然后看低速模式。大部分接口都支持一个降速的启动模式先确认在这个模式下能不能建立连接。能建立说明物理连接基本没问题问题在高速路径的参数收敛上不能建立说明是连接或者配置本身的错误。最后才是均衡和采样点。用眼图扫描看裕量分布如果整个眼图都是闭合的多半是走线或终端匹配的问题再调参数也没用如果眼图有开口但很窄那是参数优化的问题可以慢慢收敛。6.2 误码率飘忽不定往这几个方向想误码率不是零但也不高忽好忽坏这种问题最磨人。我的经验是分三类。与温度相关。跑一会儿热了就出错冷下来就好这是典型的温度相关失效。查散热路径、查热膨胀导致的接触不良、查某些器件的参数漂移。与流量模式相关。空闲时没事满负载就出错这说明是电源完整性问题。同时翻转的驱动器太多瞬态电流把电源拉下来了耦合到信号上就成了误码。解决办法是增加电源和地的凸点、优化去耦、或者调整数据编码降低同时翻转率。与特定通道相关。如果错误计数器显示错误集中在某几条通道上那是这几条通道的物理问题可能是走线长度差异、参考平面不连续、或者相邻通道串扰。换映射位置或者调整走线是最直接的办法。6.3 良率问题和已知良好裸片筛选多裸片封装的良率是乘出来的任何一颗裸片出问题整颗封装就报废。所以已知良好裸片筛选是必须的而且筛选标准要比单裸片出货标准更严因为封装后无法修复。一个常被低估的问题是测试覆盖率。单裸片测试如果只测功能不测互连封装后才发现互连接口有问题那损失就大了。我的做法是在单裸片阶段就做互连的自环测试把发送端接到自己的接收端验证物理层的基本功能。还有一个问题是中介层本身的测试。中介层面积大、走线密本身也会失效但它的测试通路不像裸片那么容易设计。这个要在中介层设计阶段就规划好预留测试结构。6.4 常见问题速查表现象优先排查方向常用手段容易误判的点训练完全不启动电源、时钟、复位、侧带示波器抓时序、读状态寄存器把配置错误当成硬件故障低速能连高速不能连均衡、采样点、终端匹配眼图扫描、参数扫描误以为是走线问题而改封装误码随温度变化散热、接触、参数漂移温箱试验、红外热像归因为偶发干扰误码随负载变化电源完整性、同时翻转电源纹波测量、编码调整加大去耦却不改凸点分配错误集中在特定通道走线长度、串扰、参考平面换映射、查走线报告只调均衡不查物理封装后才有问题装配应力、翘曲、凸点接触翘曲测量、切片分析认为封装工艺不会有偏差偶发挂死路由死锁、流控超时长跑压力测试、加超时保护归因为软件缺陷排查这类问题我的一个核心心得是一定要有足够详细的状态寄存器和错误计数器。没有可观测性再厉害的工程师也只能靠猜。所以在接口定义阶段宁可多花两周把可观测性做足也不要在后期靠反复试验去定位问题。7. 几个踩坑之后才明白的道理最后说几个我自己的体会都是花过代价才记住的。第一拓扑要按最差情况设计不能按平均情况。我早期做过一个方案按流量平均值算 Mesh 的带宽绰绰有余结果实际负载里有两个裸片之间的通信量远超预期把中间路径堵死整体性能掉到预期的一半。后来复盘发现问题根本不在拓扑本身而在于任务划分不合理——本该在同簇内的通信被分到了跨簇。所以拓扑设计之前先看一眼任务划分很多拓扑问题其实是划分问题。第二凸点预算要留余量至少留两成。中途总会有需求变更加一条调试通道、补几根电源地、给测试结构留位置。预算做满的方案任何一个变更都会引发连锁反应。第三接口文档里要写清楚出错了怎么办而不是只写正常怎么工作。这一点我强调过但还是要再说一次。正常流程谁都写得出来真正体现工程功力的地方在于异常路径重试多少次、多久算超时、超时之后降级到什么状态、怎么恢复、恢复过程中上层看到的是什么。我见过太多方案在正常路径上无比优雅一遇到异常就整系统卡死。第四把自动化做在前面。凸点映射生成、走线长度提取、误码统计、眼图扫描这些事情手工做一遍可以做十遍一定会出错。我现在的习惯是任何需要重复三次以上的操作都先写脚本。前期花的这点时间后面会连本带利地还回来。第五第一版别贪心。多裸片系统的复杂度不是线性的每多一颗裸片互连、散热、测试、良率都会成倍复杂。先把两到三颗裸片、成熟的接口速率、完整的测试流程跑通再谈扩展。这个顺序看起来慢实际上是最快的路。
