做DFT这块时间长了会明显感觉到一个趋势3D-IC已经不是停留在论文里的概念而是实实在在流片、量产的方向。把多个die堆叠起来用TSV和微凸点做垂直互连功耗和带宽确实香但测试的复杂度直接翻了几倍。你不仅要验证每个die本身是好是坏还要验证die与die之间的互连是否可靠甚至要考虑“某一层已经坏了剩余部分还能不能继续用”。这也是为什么最近两年无论行业社区还是DFT面试题里3D-IC和Tessent这两个词出现的频率越来越高。Tessent是西门子EDA家的DFT工具全家桶覆盖了扫描链插入、ATPG、MBIST、LogicBIST、诊断等全流程基本成为了3D-IC测试方案里的主流参考。这篇文章我想把自己在3D-IC测试这块的实战理解整理出来重点聊聊测试难在哪、Tessent是怎么拆招的以及真正落地时会踩到哪些坑给芯片DFT工程师、测试工程师还有准备转3D-IC方向的同学做个参考。1. 为什么3D-IC会让测试变得格外棘手1.1 测试对象从“单片”变成了“堆叠系统”传统2D芯片测试你面对的就是一个die端口从pad或bump引出来扫描链、BIST、ATPG都是围绕这一个die展开逻辑清晰工具链也非常成熟。但到了3D-IC问题一下子变成了立体问题最底下可能有interposer中间叠着多个diedie之间还有TSV、micro-bump、hybrid bonding这些新增互连。测试对象不再是单一芯片而是一个包含多个die和大量互连的完整系统。任何一个环节出问题最终堆叠体的良率都会受影响。举个例子一个由四颗die堆叠的芯片如果每颗die单独测试的良率都是95%理想情况下四颗die堆叠后的良率最多也就是0.95的4次方大约81%。注意这还没算TSV、微凸点、键合工艺引进的互连缺陷。所以3D-IC测试首先要解决的不是“怎么测”而是“到底要测哪些层级、每个层级要测到什么程度”。这个决策直接影响后端的测试成本、测试时间以及整个芯片的最终良率。这里我想多说一句很多人一上来就纠结“用Tessent还是其他工具”但真正应该先想清楚的是测试策略。有没有interposerdie之间是微凸点还是混合键合堆叠后是否有额外的测试访问端口这些物理和架构层面的信息决定了DFT方案的上限。工具只是把策略落地的手段。1.2 TSV与混合键合带来了全新的故障类型TSV从刻蚀、填充到研磨每一步都可能引入空洞、裂缝、填充不完整的问题微凸点可能出现开路、桥接混合键合更薄更脆弱对表面平整度和洁净度要求极高。这类互连缺陷在传统2D芯片里几乎不存在传统测试pattern很难直接复用。更麻烦的是很多TSV缺陷并不是静态的它会随着温度、电流应力发生变化。我在实际项目中就遇到过这种情况某个TSV在常温功能测试时明明是通的到了高温测试阶段表现为阻抗漂移甚至间歇性开路。这种缺陷如果只用常规stuck-at测试非常容易漏掉。应对这种问题至少需要两层准备第一层是专门的互连测试结构比如对TSV网络做类似边界扫描方式的测试把每条互连路径单独激活、单独验证第二层是测试条件必须覆盖多个温度点不能只做常温。对于工程师来说这直接意味着pattern数量、测试时间、硬件复杂度的成倍增加。TSV的测试覆盖率如果不足堆叠完成后才发现缺陷整颗芯片作废成本远高于在die阶段就把它筛掉。1.3 Known Good Die与良率博弈绕不开的决策题在把die堆叠起来之前每颗die是否known good直接决定最终良率。如果某一层die是坏的堆叠完成才发现整颗芯片报废损失的不只是这一颗die还有上面所有已经堆叠的好die。所以在3D-IC流程里die级测试的目标通常是“尽可能确认这颗die没问题”这也就是大家常说的KGD测试。但“预测试”本身也有代价。测试覆盖率越高测试时间越长成本越高覆盖率不足又会让坏die流到堆叠后。这个平衡在3D-IC里会被放得很大因为stacking之后的测试成本往往是die级测试的好几倍。另外一个实际的问题就是“部分损坏”策略。一颗die可能部分功能有问题但未损坏的模块仍然能满足目标应用需求这种情况下很多团队会选择继续堆叠尤其在消费级芯片里很常见。这种策略对诊断能力要求很高必须在堆叠前就准确知道坏在哪个模块并且验证剩余模块在堆叠后不受影响。这也是为什么3D-IC的测试规划必须前置到设计阶段不能等物理设计做完了再补DFT。2. Tessent是怎么拆解3D-IC测试问题的2.1 分层DFT架构die级测试与堆叠后测试分开设计Tessent应对3D-IC测试的核心思路总结下来就是四个字分而治之。每个die在RTL或网表阶段就独立插入扫描链、BIST控制器独立做ATPG生成die级pattern堆叠之后通过Tessent Shell把多个die的DFT结构整合进同一个设计视图再去做stack级的ATPG、互连测试和芯片级测试。这样做最大的好处是die级pattern能复用到堆叠后的测试流程里不需要重新生成。另一大好处是每颗die的测试结构和测试向量保持一致方便诊断时回溯到具体die。比如堆叠后一个fail发生在逻辑路径上可以通过诊断工具把结果对应到具体die的扫描单元不需要靠猜。但分层架构是有代价的DFT规划必须提前。dfx pin、测试时钟、test mode信号都要在物理设计阶段预留好否则后期想补根本补不进去。很多团队第一次做3D-IC最容易在floorplan阶段忽略测试访问端口的需求等到后端发现没有空间放test pin的时候只能退而求其次用功能引脚复用代价是测试pattern冲突和调度复杂度上升。2.2 扫描、ATPG、MBIST和LogicBIST怎么各司其职Tessent产品线里Tessent Scan负责扫描链插入和DFT规则检查Tessent ATPG负责生成测试patternTessent MBIST覆盖片上存储器Tessent LogicBIST针对逻辑做内建自测试。在3D-IC场景里MBIST和LogicBIST的价值会格外突出。原因在于堆叠之后IO访问受限很多内部节点无法直接由外部ATE控制自测试可以在片内运行大幅降低对ATE通道的需求。举个例子一颗堆叠了HBM显存的3D-IC存储阵列的测试完全可以靠MBIST完成外部只需要给一个启动信号和时钟就能在整个存储系统上做March测试这在量产测试里能节省大量时间。但ATPG依然有它不可替代的位置。ATPG对逻辑故障的覆盖率更高配合压缩技术可以降低pattern体积在die级测试里尤其重要。LogicBIST更适合堆叠后快速筛查它不需要外部灌入大量向量但诊断能力比ATPG弱一些。实际项目里我通常的搭配是die级主要用ATPG跑高覆盖率stack级用LogicBIST做快速判断再结合少量ATPG pattern做精确诊断。2.3 Tessent SSN堆叠后并行测试的关键拼图Tessent SSN在整个3D-IC测试方案里是我认为非常值得单独拿出来讲的一块。传统扫描测试依赖把所有扫描链都串到有限的chip IO上堆叠之后芯片外部可用引脚更少、测试带宽受限如果扫描链数量再一上来测试时间会拉得非常难看。SSN的做法是把各die的扫描网络按流式方式并行访问支持多die同时灌入不同的pattern而不是一颗一颗串行测。这样能明显压缩堆叠后的测试时间同时配合片上压缩把需要从外面灌入的数据量大幅降低。实践中SSN还能处理“部分损坏die”带来的测试策略问题——你可以只测试某颗die仍然有效的模块其他模块在测试配置里跳过这在量产场景里非常实用。我自己的经验是SSN这种能力需要设计阶段就规划好。每个die的扫描输出要能够独立地连接到SSN网络并且能在test mode下把多个die的扫描链组成可配置的并行访问路径。如果等到netlist都整合完了再想改基本已经来不及了。3. 实操中的关键环节与参数考量3.1 测试规划一定要前置到设计阶段很多刚接触3D-IC的团队容易犯一个错先把设计做完再想测试。结果做DFT时发现关键的test pin已经被普通逻辑占用时钟树没有预留扫描时钟多个die的测试时钟频率还不一致SSN配置根本做不出来。这些问题到了后端阶段几乎是灾难。正确做法是在floorplan阶段就确定几件事哪些die用Tessent hierarchical flow哪些pin作为test pintest mode如何跨die传递stack级测试时钟使用外部时钟还是内部PLL。这些决定应该写进DFT plan文档由DFT工程师和物理设计工程师一起评审。我在项目里的习惯是DFT plan至少要在RTL freeze之前定稿一版并在每次网表版本更新时同步刷新绝不等后端来催。还有一个容易被忽视的细节是测试时钟跨die传递。多die堆叠后如果每颗die自己产生测试时钟频率和相位可能会有偏差如果统一用一颗die的时钟驱动所有die的扫描链时钟树的长度和延迟又必须仔细做平衡。这里我建议优先考虑由stack controller统一分发测试时钟必要时通过边界扫描或JTAG配置PLL避免各die测试时钟各自为政。3.2 覆盖率、pattern数量与测试时间的平衡3D-IC测试方案里最常被问到的参数问题是“覆盖率目标定多少”。我的回答是分场景。die级为了追求known good die会尽量把DC stuck-at、transition coverage做到98%以上transition coverage也不能太低否则小延迟缺陷很容易漏到堆叠后。TSV和互连测试则对bridge fault和open fault覆盖率有单独目标这类pattern量通常不多但针对性极强。真正需要权衡的是测试时间。覆盖率目标越高pattern越多测试时间越长成本越不可控。实际项目中我常用的做法是分两套pattern一套用于die级覆盖率尽量高因为这时候测试时间再长也还能接受另一套用于stack级重点覆盖互连、部分损坏修复后的模块、以及die之间的时序路径pattern数量可以控制在较小规模。这里有个原则需要强调stack级pattern的数量不要盲目追求高覆盖率盲目堆pattern只会让量产测试时间失控。堆叠新增的互连和跨die路径必须测到位而原本已经由die级pattern覆盖的逻辑除非诊断需要否则不必在stack级重复覆盖。工程上做减法有时候比做加法更重要。3.3 诊断导向的良率分析3D-IC更依赖它3D-IC一旦出现良率损失定位到具体die和具体互连位置效率差别非常大。Tessent Diagnosis支持layout-aware的诊断可以把fail掉的pattern数据回读进来结合物理布局信息把故障定位到具体的标准单元、net甚至TSV或micro-bump位置。实际使用中我建议在量产阶段就启用volume diagnosis把fail die的pattern log自动收集起来定期做批量分析。比如每周跑一次看fail pattern是否集中在某些固定的物理区域。一旦某个TSV位置反复出现fail就要立刻反馈给工艺或封装团队这比等良率暴跌后手忙脚乱地排查要高效得多。从成本角度看3D-IC的die往往成本高、堆叠价值也高一次精准诊断就能省下大量用于失效分析的时间和资源。尤其在高密度互连的场景下靠人工用探针或FIB去定位TSV问题成本极高layout-aware diagnosis从效率上确实有很明显的优势。4. 常见问题与避坑经验4.1 常见问题速查表结合我自己做3D-IC项目的经验把容易出问题的环节整理成一个表格方便快速自查问题场景主要原因建议处理方式堆叠后测试时钟不稳定多die测试时钟频率、相位不一致通过stack controller统一分发必要时用JTAG配置PLLTSV或微凸点缺陷漏检常规stuck-at coverage对互连缺陷不敏感增加专用互连测试pattern结合多点温度测试多die pattern同时灌入时带宽不足外部ATE通道有限扫描链数量大引入Tessent SSN 片上解压缩die级与stack级pattern复用混乱版本管理不清die_id和stack_id未定义在每个pattern header写入die_id和stack_id诊断结果定位到错误的diedie级pattern被误用于stack级环境检查堆叠环境的物理层次映射确保与layout一致堆叠后部分模块无法访问测试访问端口被功能逻辑占用在设计阶段预留专用test pin必要时采用功能引脚复用方案这张表里的问题我自己基本都遇到过。尤其是诊断结果定位错误这种问题排查起来非常耗时因为表面上看pattern是过了只是fail log对应位置不对但追下去往往是层次映射配置错了导致工具把故障归到了错误的物理坐标。4.2 关于KGD测试覆盖率的个人经验对需要堆叠的die我个人建议DC stuck-at覆盖率尽量往99%靠transition coverage也尽量做高。KGD测试如果漏掉一颗坏die堆叠后修复的成本会成倍放大在量产层面直接侵蚀利润。有些团队觉得“反正堆叠后还要测”就降低了die级覆盖率目标这个想法在3D-IC场景里很危险。为什么因为堆叠后的测试主要覆盖stack新增的互连和跨die路径对原先die内部的低频逻辑故障其实覆盖不到。如果die内部本来就有一个隐藏的transition故障堆叠后因为工作环境变化才暴露出来这时候定位和修复的成本远不是在die阶段用一颗pattern能筛掉那么简单。在消费电子这类价格敏感的产品里这个平衡尤其需要认真算。当然覆盖率高不等于无脑堆pattern。覆盖率在99%以上继续往上提测试时间的增量是肉眼可见的。工程上要做的是找到那个“再增加1%覆盖率所需的额外测试时间”已经明显不划算的拐点并把验证工作做扎实。4.3 环境与流程上容易被忽视的坑工具版本、PDK里的DFT rule deck、Tessent SSN配置在3D-IC多die流程中任何一处不匹配都会导致flow跑不动。每颗die可能来自不同团队甚至不同工艺节点DFT约束文件、时钟定义、复位策略都可能不一致。跨die整合时必须用一套统一的约束语言把各die的时钟、复位、test mode对齐。另外DFT pin在顶层可能被BIST控制器复用扫描链顺序在不同层次命名不同这类命名和复用问题在后端实现阶段经常会冒出来。我的习惯是在每个die的交付文档里注明DFT接口的完整定义包括信号方向、电平、时钟域、复位方式这样在stack整合时不会出现语义模糊。还有一点是测试数据的存储和管理。3D-IC的pattern数量通常不小die级和stack级要分开存而且每个pattern要能追溯到它对应的die版本和堆叠配置。否则等你量产一个月后要查某个fail光找对应版本的pattern都可能让你怀疑人生。写在最后一点实际体会跑过完整的3D-IC项目之后我最大的感受是测试永远不是设计流程的收尾而是必须前置参与设计决策的一部分。Tessent这套工具确实强大但它不会替你决定“这颗die到底要不要继续堆叠”也不会替你规划“哪些pin留给测试更重要”。真正决定项目成败的还是在floorplan阶段把DFT结构放进去、在每颗die的测试策略里提前想好复用和诊断方案以及把stack级测试和die级测试之间的边界理清楚。如果非要给刚接触3D-IC的团队三个建议我会说第一先把“每颗die做成known good”这件事做到位这是所有堆叠策略的前提第二从设计一开始就考虑SSN和测试带宽别等到netlist整合完再补第三量产阶段一定跑volume diagnosis让数据告诉你问题在哪而不是靠猜测。3D-IC的测试复杂度还会随着堆叠层数、混合键合工艺的普及继续上升但底层的方法论是稳定的清晰的DFT规划、合理的覆盖率目标、可追溯的pattern管理加上诊断驱动良率提升。把这四件事想清楚工具层面的问题反而都好解决。