最近团队招人，我面试了不少做DFT和测试的同学，发现只要聊到3D-IC，大家的目光最后都会落在Tessent这套工具上。3D-IC的火热不是一天两天了，HBM、Chiplet、2.5D/3D封装，几乎所有高性能芯片的路线图里都有它的影子，但真正愿意把测试挑战讲透的资料却不多。这篇文章我从一个做测试开发和DFT集成的工程师视角出发，把3D-IC的测试难点、Tessent解决方案的核心思路、以及我在实际项目里踩过的坑一次性讲清楚。不管你是刚接触3D-IC的测试新人，还是正在做Chiplet选型、评估工具链的团队，都应该能从里面找到能直接拿去用的东西。
很多人对3D-IC测试的第一反应是“不就是把几个die叠起来测嘛”，真正跑过项目之后才会明白，这个“叠”字背后藏着一整套全新的规则。接下来的内容我不会给你念工具手册，而是把从设计规划到量产test program落地的完整链路拆开，讲清楚每一个环节为什么难、Tessent又是怎么接招的。
1. 3D-IC为什么让测试团队这么头疼
1.1 从2D到3D，变化的不只是封装形式
先明确一个概念：这里的3D-IC不是简单地把两颗芯片放进一个封装里，而是通过硅通孔（TSV）、微凸点（micro-bump）或者混合键合（hybrid bonding）把多个裸die在垂直方向或者中介层上进行互连。这和传统的多芯片模块（MCM）有本质区别——3D-IC的die之间是超高密度、短距离的电气连接，而不是PCB走线。
这就带来一个测试团队以前完全不用面对的问题：你在2D SoC时代习惯的“一颗芯片一个完整的测试入口”被打破了。
在2D时代，测试对象是单一die，设计是完整的，DFT逻辑是统一规划的。你可以在一个TAP控制器（IEEE 1149.1）下面挂上所有扫描链、BIST控制器，一次性做全芯片的scan测试、存储器内建自测（MBIST）、逻辑内建自测（LBIST）。测试工程师拿到的是一颗物理上独立的芯片，测试程序写起来也顺理成章。
但在3D-IC里，情况完全不同了：
- 堆叠的die可能来自不同的工艺节点，一颗是先进逻辑工艺的SoC，另一颗可能是DRAM或者传感器die。
- die可能由不同的团队甚至不同的公司设计，每个die内部的测试结构未必相互兼容。
- die与die之间的互连（TSV、micro-bump、RDL走线）本身变成了新的故障来源，而且这些互连一旦堆叠完成，物理上几乎不可能单独探测。
还有一个最头疼的事：每个die在堆叠之前都必须是可测的，而且测试结果要可靠。这就逼着测试团队在项目早期就介入，定义每个die的测试接口、测试协议、以及die级测试的覆盖目标。这不是单纯工具能解决的问题，而是一个工程流程的重构。
1.2 测试目标变了：KGD从可选变成必选
先给大家算笔账。假设一个2-die堆叠的3D-IC，每个die单独测试的良率都是90%，如果在堆叠前不做任何筛选，直接堆叠后再测，那么最终良率理论上只有 90% × 90% = 81%。如果堆3个die呢？90%的三次方就只有72.9%了。HBM这类动辄8层、12层堆叠的芯片，如果每层的良率不够高，堆出来的整体良率会惨到完全没法量产的。这就是为什么3D-IC测试里必须引入Known Good Die（KGD）的概念——在堆叠之前，必须尽量保证每个die都是“已知好的”。
但KGD说起来容易做起来难。它的核心矛盾在于：die级测试做到什么程度算“够好”？
如果测试做得太狠，比如把所有全速模式、所有at-speed scan pattern都在探针台（probe）上跑一遍，产能扛不住，测试成本暴涨。如果做得太松，只跑一些慢速结构测试，那么一些只有全速下才能暴露的时序故障就会漏掉，这些坏die被堆叠进去之后，整体良率损失是不可逆的——因为堆叠之后你几乎没法拆开去替换一颗die。
从这个角度看，KGD策略本质上是在测试覆盖率和测试成本之间找平衡。Tessent这套方案里，KGD对应的是一整套die级DFT结构设计、pattern生成策略和测试数据管理流程，后面我会详细拆。
2. Tessent 3D-IC方案的核心组件与设计思路
2.1 从IEEE 1838到Tessent：标准先行
提到Tessent做3D-IC测试，绕不开一个标准：IEEE 1838。这个标准专门定义了3D-IC的测试访问架构，你可以把它理解成“3D-IC测试的交通规则”。
传统上每个die内部都有基于IEEE 1149.1（JTAG）的TAP控制器。IEEE 1838在JTAG基础上做了扩展，主要解决两个问题：一个堆叠体里多个die的测试接口如何统一访问，以及如何定义die与die之间的测试数据传递协议。
具体来说，IEEE 1838定义了die-level的测试端口（比如串行测试数据端口），以及一套die-to-die测试访问机制。这样即使不同die来自不同的设计团队，只要都遵守IEEE 1838，那么堆叠起来之后，测试工程师就能用一套统一的测试协议去访问每一颗die内部的扫描链和BIST控制器。
Tessent在实现上做得比较完整的点在于：它在工具链上把IEEE 1838变成了可以落地的EDA流程，而不是停留在纸面标准。你在Tessent里可以定义die-level TAP、stack-level TAP，工具会自动生成相应的测试访问逻辑（die wrapper register、serial test access port等），并帮助验证这些逻辑在不同测试模式下能不能协同工作。
做这个项目尤其要注意：如果你选择了IEEE 1838兼容的die，但某颗die是第三方IP或者老设计，不支持这个标准，你需要在堆叠体层面额外设计一个转换桥接逻辑。这在Tessent里可以通过定制wrapper cell来实现，但必须在设计阶段就预留资源和RTL代码。
2.2 Tessent DFT与SSN的底层支撑
在3D-IC里，测试数据和时钟分配是两大难题。多个die叠在一起，如果沿用传统的单条扫描链从stack顶部贯穿到底部，测试数据要穿越好几层die和TSV，路径长、延迟大、功耗高，而且一旦某一段互连有缺陷，整个测试链路就断了。
Tessent里有几个东西解决了这些问题，其中最核心的是Tessent SSN（Streaming Scan Network）。我第一次接触SSN的时候，觉得它本质上是一种矩阵式的扫描数据分发网络，把传统上一根扫描链里串行传数据的方式，变成了一个分层的网络结构。测试数据从一个输入端口进来，通过网络节点广播到多个扫描链，然后从输出端口流回。这个结构在3D-IC里特别有用，因为它天然支持模块化：每个die可以有自己的SSN子网，堆叠体顶层只需要一个SSN根节点就能串起所有die的测试访问。
SSN带来的直接好处是：测试向量量变大之后，传输时间不会线性增长，因为数据是从网络并行分发的。这对于multi-die堆叠体来说非常关键——多个die可以同时进入测试模式、并行灌pattern，而不是像传统串行方式那样逐个die排队测。
2.3 Tessent Multi-Die与3D-IC Planner的集成
Tessent在3D-IC方案上不止有SSN，还包括了一个完整的多die集成规划工具（3D-IC Planner）以及配套的multi-die DFT结构生成流程。
这套流程做的事情大概是这样的：在项目早期，你输入每个die的网表、约束、以及die间互连的信息，工具会帮你规划整个堆叠体的DFT测试层次结构。具体包括die-level TAP怎么连、stack-level TAP怎么连、测试时钟怎么分配、异步还是同步、哪些die可以并行测试、pattern如何跨die传递等等。
我自己的感受是，Tessent这套方案最大的价值在于把“3D-IC测试”从一个需要反复手工协调的难题，变成了一条相对明确的自动化流程。它并不是说不需要你思考，而是把你从繁琐的测试结构连线和protocol validation中解放出来，让你能把精力集中在更上层的测试策略上——比如KGD覆盖率定多少、互连测试用什么故障模型、量产测试pattern怎么调度。
3. 实操：一个双die堆叠项目的测试全流程
前面把概念讲了，接下来这部分是纯实操。我在一个2.5D/3D封装的项目里完整跑过一遍Tessent的3D-IC流程，这里把跟测试强相关的步骤和细节列出来。
3.1 第一阶段：die级DFT规划与插入
不管最终堆叠结构多复杂，每颗die都必须先能独立测试。这是KGD的前提。
在die级DFT规划时，我一般按这四步走：
- 给每颗die单独插入完整的可测试性设计（scan chain、MBIST、LBIST、TAP controller）。
- 在每颗die周围加上符合IEEE 1838/1500风格的die wrapper，也就是一个并行的边界寄存器，用来支持堆叠后的互连测试。
- 定义die级测试时钟和复位信号。每个die内部可能有多个时钟域，3D-IC里die间时钟往往不同步，所以需要把每个die的测试时钟独立可控。
- 做一次完整的die级DFT验证，确认单die模式下所有test mode都能正常使能，pattern能生成、能仿真通过。
以Tessent DFT流程为例，你需要在综合后的网表上跑类似下面的dofile（具体命令取决于工具版本，这里只给一个示意）：
# 示意dofile片段：die级DFT插入 set_current_design die_core # 定义扫描链，至少两个scan chain组 create_test_protocol -file test_protocol.spf add_scan_group -name scan_grp0 -clock CLK_CORE add_scan_group -name scan_grp1 -clock CLK_IO insert_test_logic -test_compression -scan_groups {scan_grp0 scan_grp1} # 为3D互连测试预留的wrapper cell insert_die_wrapper -ports {TSV_DATA[*] TSV_CTRL[*]} -cell_name DW_TOP write_dft -output dft_netlist.v这一步很关键，因为如果在die级不预留互连测试用的wrapper cell，后面堆叠完成之后，根本没有办法直接对die间的TSV做结构性测试。
3.2 第二阶段：KGD测试和pattern筛选
Die级DFT做完之后，就可以生成pattern用于wafer probe测试了。但KGD测试不能用“一个完整的花费最高的pattern集”直接在探针台上全跑，那样成本完全承受不了。
我的经验是把pattern分优先级排布：
- 第一优先级是低速结构测试：full-scan stuck-at测试、MBIST低速测试。这部分先跑，快速筛掉工艺缺陷和短路开路问题。
- 第二优先级是低速互连测试：通过die wrapper跑die边缘IO和TSV的开短路问题。因为TSV本身很密，细小的异物残留、刻蚀异常都可能导致开短路。
- 第三优先级才是at-speed测试：包括transition fault pattern、path delay pattern、LBIST。这些pattern只在前面低速测试全过之后才跑。
Tessent生成的pattern本身带压缩，压缩倍数通常在50~200倍之间，这对KGD测试的产能帮助很大。但还要注意一个问题：probe上跑at-speed测试时，测试通道的电感和电容会影响时钟质量，可能导致误fail。我踩过这个坑，后面在问题章节详细讲。
KGD判据怎么定？我们当时用了两个方案对比：一个是用Tessent YieldInsight收集良率数据，结合工艺良率分布去设定die级pattern的容忍边界；另一个是直接用全量pattern在probe上做了几百颗的实验，对比堆叠前后失效数据来自哪层die。最终发现，用数据驱动的方式去设定KGD pattern子集比拍脑袋定“只跑stuck-at”要靠谱得多。
3.3 第三阶段：堆叠后的互连与时序测试
堆叠完成后，测试重点就转到die间互连上了。这部分是3D-IC测试跟传统2D SoC测试差异最大的一块。
TSV和micro-bump的故障模式主要有这几类：
- 开路故障：TSV本身断裂、微凸点虚焊、混合键合界面分离。
- 短路故障：相邻TSV之间桥连（TSV-to-TSV bridge），或者TSV击穿到衬底。
- 漏电故障：TSV绝缘层退化，导致漏电流增大。
- 时延故障：互连链路太长、负载电容过大，导致信号到达时间晚于预期。
对应在Tessent里，互连测试是借助die wrapper和跨die扫描路径实现的。工具会自动识别所有die间互连网络，生成连线的stuck-at、open/short、以及时延pattern。本质上和传统板级JTAG互连测试的思路一样，只是这里的“板”换成了3D堆叠体，互连线的数量从几百条变成了几万条。
有一个值得注意的细节：测试TSV时，pattern必须能同时控制两端die的wrapper cell。也就是说，驱动端die的wrapper cell要能把数据推上TSV，接收端die的wrapper cell要能捕获数据。这就要求两个die的测试时钟同步，或者至少要有一个跨die的测试协议来协调。Tessent在生成这类pattern时会自动处理这种同步关系，但你要在测试仿真阶段多做一步跨die的时序验证，确认这个同步在worst case下也不会出错。
3.4 第四阶段：堆叠体测试与系统级测试
Die间互连测试通过之后，还要对整个堆叠体做一次完整的结构测试和功能测试。
我的流程是这样的：
- Stack-level scan测试：把所有die的扫描链通过stack TAP统一访问，跑一遍跨die的过渡故障pattern，验证连起来的逻辑路径没有时序问题。
- Stack-level MBIST：对堆叠体内的所有memory，包括die内SRAM和可能的HBM/DRAM die，触发MBIST，确认数据读写路径完整。
- 系统级功能测试（SLT）：把3D-IC封装好之后，跑真实的系统软件和应用，验证功能是否正常。这个阶段不是测结构故障，而是测系统级交互，包括功耗、热、以及die间通信协议的正确性。
在Tessent这块，SLT阶段其实更多是复用前面生成的功能pattern和BIST自检结果。我的经验是：把stack-level MBIST设计成一条可以被软件触发的自检命令，这样在系统测试阶段，直接通过固件发起一次全堆叠体memory自检，能极大缩短测试时间，还能覆盖一部分软件栈问题。
4. 常见问题与排查技巧实录
4.1 KGD判据过严过松的取舍
我在前面讲过KGD的重要性，这里单独把它当问题拿出来说，是因为太多项目在这上面翻车了。
有一类团队走得是“保守派”：不管什么die，probe阶段全量at-speed pattern全部跑完，跑不完就延长时间，把测试成本甩到天上。还有一类是“激进派”：为了省成本只跑stuck-at，结果堆叠之后发现故障率暴增，最后还搞不清楚是互连问题还是die本身问题。
我的建议是分两步走：
第一步：用数据建模代替拍脑袋。先跑一个批量的die级全量pattern，收集良率损失图谱，用统计工具分析失效率主要来自哪类pattern（比如时延fail集中在某几个时钟域），然后根据这个分析结果去精简KGD测试集。这一步Tessent的诊断工具可以用得很深，能直接定位到具体的scan chain和故障单元。
第二步：建立堆叠后的闭环反馈。系统测试阶段如果发现某个故障模式反复出现，就回头去probe数据库中看对应Die的KGD测试数据是否有疑点。把这种反馈机制跑上两三轮，你会发现KGD判据可以逐步往回收，最终找到一个“既能保证良率、又不会测到天荒地老”的平衡点。
4.2 TSV测试的真假失效：接触问题与真实缺陷
TSV测试是最容易出现误判的地方。我遇到过好几次：die间互连测试报了一大片TSV开路，但是拆开做失效分析发现TSV根本没断，问题出在测试本身。
最常见的假失效来源是探针接触不良。在die级probe阶段，针和pad的接触阻抗如果偏大，会直接导致测试pattern的驱动能力不足，看起来就像TSV开路。这个问题在3D-IC里比2D更严重，因为更先进的节点pad越来越小，接触面积变小，阻抗更容易波动。
另一个来源是微凸点自热效应。全速测试时，密排的微凸点区域电流密度很高，局部温度升高会导致额外延迟，让时延测试fail。这种fail在常温下crash，但是把测试温度调到高温区反而可能pass——这种情况你如果只认定为时延缺陷直接reject，良率就白白损失了。
排查方法我的经验是：
- 在测试pattern里加入一处“参考测量”：挑几条已知是好的TSV作为基准，实时监测它们的测试响应是否偏移。
- 如果看到大面积的TSV fail集中在一个区域，先检查是不是探针、load board、或者socket的问题，而不是急着分析die本身。
- fail诊断一定要用Tessent Diagnosis工具跑失效分析，它能把fail pattern对应到物理坐标，帮你区分真实故障和接触类假失效。
4.3 pattern数据量爆炸：如何压缩与复用
3D-IC的测试数据量是2D时代的几十倍都不止。多颗die、各自有scan pattern、互连pattern、MBIST pattern，如果都存到ATE上跑，vector memory直接爆掉。
Tessent在数据压缩这块做得确实强，但工具强不等于你可以不管。我总结了几条实用经验：
- 同一组pattern能复用的就复用。die级生成的stuck-at pattern，很多在stack级测试时依然有效。区别只是测试访问路径从die TAP变成了stack TAP。Tessent支持pattern reuse，可以省掉大量重复仿真时间。
- 不要所有pattern都上ATE。MBIST这类测试，在die级和stack级各保留一套就够。scan pattern则可以根据覆盖率报告裁剪，把没用的pattern直接删掉。
- 共享测试接口要提前规划。如果stack级只有一条测试通道，那么多die同时测试时，数据带宽是瓶颈。用SSN可以大幅度缓解这个问题，但如果带宽还是不够，就要考虑把scan pattern拆成多段，在多个die之间交错灌入。
4.4 热与供电问题：多层堆叠的隐性杀手
3D-IC的测试功耗和热管理是个没人重视就踩大坑的点。多层die叠在一起，中间层散热路径非常差，测试时如果所有die同时跑到全速，瞬间发热非常严重，轻则pattern fail，重则直接损伤die。
这个问题的解决思路有几个层面：
- 测试调度层面：把“所有die同时全速测试”调整为“分时交错测试”，比如先测die A的at-speed pattern，再测die B的at-speed pattern，而不是同时跑。虽然总时间变长了一点，但峰值功耗大大降低。
- pattern层面：Tessent支持在pattern里插入功耗控制向量（比如强制扫描链翻转率降低），这可以在pattern生成阶段就把测试功耗降下来。
- 硬件层面：在3D-IC设计时就要考虑测试热管理策略，比如预留温度传感器在die内，在测试程序中加入温度阈值判断，温度一旦超过阈值就暂停测试。
5. 工具链选型与个人经验总结
5.1 Tessent的优劣势和个人体会
这块纯粹是我个人使用感受，不一定适合所有项目。Tessent在3D-IC测试上的优势，我觉得首先是生态完整性。你不用在DFT插入、pattern生成、覆盖率分析、诊断、良率分析这些环节之间来回切换工具，整个流程在一个平台里闭环。这一点在3D-IC这种多个die、多个团队协作的项目里特别重要，数据格式不一致简直是灾难。
其次是它对标准的支持非常完整。IEEE 1838、IEEE 1500、IEEE 1149.1这些协议，Tessent都能直接映射成结构网表，你不用自己写一堆线缆级RTL去桥接。标准支持的深度直接决定了你能不能把多die的测试协议统一起来，如果靠手工做，验证工作量大到可能直接拖垮项目进度。
劣势方面，主要就是学习曲线陡峭。Tessent不仅是一套工具，更像一个平台，涉及的脚本、约束、协议多得让人头大。新人在没有经验丰富的人带的情况下，上手周期会很长。另外就是license费用确实不便宜，小团队或初创公司需要仔细评估投入产出比。
5.2 给3D-IC测试团队落地的一些建议
根据我个人踩坑的经历，给正在做或准备做3D-IC测试的团队几条建议：
- 参与设计规划要趁早。别等RTL都写完了再来做DFT规划。从架构定义阶段开始，测试团队就要介入，明确每个die的测试接口、测试通道宽度、KGD测试策略、以及堆叠后的测试层次。这些决策越早定，后期返工越少。
- 吃透标准再动手。IEEE 1838这个标准我建议团队成员至少通读一遍。工具可以帮你实现细节，但如果不理解标准背后的设计意图，出了问题你会非常被动。
- 对照HBM参考设计找感觉。HBM是所有3D-IC测试思路里最成熟的一条路线。就算你做的不是存储类3D-IC，HBM的测试策略、test flow、debug方法都值得当教科书来研究。Tessent的工具文档和培训案例里HBM的内容也最丰富。
- 别迷信覆盖率报告。工具报出来的coverage只是参考，真正有价值的是把它和量产失效数据、系统测试结果对照起来看，形成一个持续迭代的闭环。
最后分享两个我在实际项目中一直沿用的“土办法”。一个是在每颗die的TAP设计里保留一个旁路（bypass）模式，这样堆叠之后如果整体测试链断了，还能通过逐die旁路的方式快速定位到哪一层die出了问题。另一个是给每个die的wrapper cell单独加一个观察寄存器，互连测试报fail的时候，不用重新出pattern，直接读观察寄存器里的数据就能判断是驱动端的问题还是接收端的问题。这两个设计本身的成本很低，但到调试阶段能帮大忙。
3D-IC的测试道路不会越来越简单，只会因为堆叠层数增加、die间带宽提升而变得越来越复杂。但好消息是，工具链和标准在快速成熟，Tessent这套方案也确实在实打实地解决工程问题。希望这篇文章能给准备上3D-IC项目的团队一些启发，少走点我走过的弯路。
