企业官网建设流程全解析

做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，中间叠着多个die，die之间还有TSV、micro-bump、hybrid bonding这些新增互连。测试对象不再是单一芯片，而是一个包含多个die和大量互连的完整系统。

任何一个环节出问题，最终堆叠体的良率都会受影响。举个例子，一个由四颗die堆叠的芯片，如果每颗die单独测试的良率都是95%，理想情况下四颗die堆叠后的良率最多也就是0.95的4次方，大约81%。注意这还没算TSV、微凸点、键合工艺引进的互连缺陷。所以3D-IC测试首先要解决的不是“怎么测”，而是“到底要测哪些层级、每个层级要测到什么程度”。这个决策直接影响后端的测试成本、测试时间，以及整个芯片的最终良率。

这里我想多说一句：很多人一上来就纠结“用Tessent还是其他工具”，但真正应该先想清楚的是测试策略。有没有interposer，die之间是微凸点还是混合键合，堆叠后是否有额外的测试访问端口，这些物理和架构层面的信息，决定了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负责生成测试pattern，Tessent 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 pin，test 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项目的经验，把容易出问题的环节整理成一个表格，方便快速自查：

这张表里的问题，我自己基本都遇到过。尤其是诊断结果定位错误这种问题，排查起来非常耗时，因为表面上看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管理，加上诊断驱动良率提升。把这四件事想清楚，工具层面的问题反而都好解决。