1. 从一颗芯片的叠罗汉说起Memory-on-Logic堆叠测试到底难在哪三年前我第一次接触Memory-on-Logic堆叠项目时犯了一个很典型的错误把逻辑die和存储die当成两颗独立的芯片分别做DFT然后在系统级简单拼起来。结果流片回来一测良率惨不忍睹大量失效都卡在存储die和逻辑die之间的接口上而单独测每一颗die都是好的。这个教训让我彻底明白了一件事——3D IC的测试核心矛盾从来不在单颗die内部而在堆叠这个动作本身带来的新问题。Memory-on-Logic顾名思义就是把存储die堆叠在逻辑die上方通过硅通孔TSV和微凸块micro-bump实现垂直互连。这种架构的好处很直接带宽大、延迟低、功耗省特别适合AI加速器、高带宽缓存、存内计算这类场景。但好处有多大测试的麻烦就有多大。逻辑die通常是先进工艺节点晶体管密度极高测试向量量大存储die可能是DRAM、SRAM或者新型非易失存储器测试模式完全不同。两颗die各自有自己的DFT架构、自己的ATPG流程、自己的JTAG TAP控制器堆在一起之后你怎么测从哪测什么时候测这就是Memory-on-Logic堆叠测试的DFT解决方案要回答的核心问题。它涉及的不只是传统的扫描链插入和ATPG向量生成还包括堆叠前的中测KGDKnown Good Die策略、堆叠后的互连测试、TSV的边界扫描、跨die的测试访问机制TAM、以及IEEE 1838标准定义的die间测试架构。关键词里的DFT、ATPG、JTAG在这个场景下都有了新的含义——它们不再是单颗芯片的测试手段而是贯穿整个堆叠流程的测试基础设施。这篇文章适合谁看如果你正在做3D IC的DFT设计或者负责堆叠封装的测试工程又或者你只是对先进封装的测试方案感兴趣那接下来的内容应该能给你一些可以直接参考的东西。我会从整体设计思路讲起然后拆解核心细节再给出实操流程和踩坑记录。不废话直接上干货。2. 整体设计思路为什么不能把两颗die当一颗来测2.1 堆叠测试的三个阶段与DFT策略的对应关系Memory-on-Logic的测试流程我习惯把它分成三个阶段每个阶段的DFT策略完全不同第一阶段堆叠前的中测Pre-bond Test。这时候逻辑die和存储die还是分开的各自做晶圆级测试。逻辑die跑标准的扫描ATPG存储die跑存储器BISTMBIST。这个阶段的目标是筛掉坏die保证只有KGD进入堆叠流程。为什么这一步至关重要因为堆叠之后再发现某颗die是坏的整颗堆叠芯片就报废了成本是单颗die的好几倍。所以中测的覆盖率要求极高通常逻辑die要做到99%以上的固定故障覆盖率存储die要做到95%以上的故障覆盖率。第二阶段堆叠后的互连测试Post-bond Test。两颗die通过TSV和微凸块连在一起之后首先要测的就是这些垂直互连有没有问题。TSV可能出现空洞、断裂微凸块可能虚焊、偏移。这个阶段的DFT方案核心是边界扫描Boundary Scan和TSV测试结构。IEEE 1838标准就是专门为这个阶段设计的它定义了die间测试的硬件架构和访问机制。第三阶段最终测试Final Test。堆叠芯片封装完成之后跑系统级的功能测试和结构测试。这个阶段要验证整个堆叠系统在真实工作条件下的行为包括跨die的数据通路、存储控制器的时序、功耗和热特性。三个阶段对应的DFT策略可以用下面这张表来概括测试阶段主要目标DFT手段覆盖率要求关键挑战堆叠前中测筛选KGD扫描ATPG、MBIST逻辑99%存储95%测试时间与成本平衡堆叠后互连测试验证TSV和微凸块边界扫描、TSV测试结构互连故障99%测试访问路径建立最终测试系统级功能验证功能测试、系统BIST系统级90%热管理与功耗控制2.2 为什么选择IEEE 1838而不是自己搭一套在IEEE 1838标准出来之前很多团队的做法是自己定义一套die间测试接口。我早期项目也这么干过用自定义的测试总线把两颗die的TAP控制器串起来。能跑通但问题很多复用性差换个项目就得重新设计工具支持弱ATPG工具不认你的自定义结构调试困难出了问题很难定位是协议问题还是硬件问题。IEEE 1838的核心价值在于它定义了一个标准化的Die Wrapper结构。每颗die外面包一层wrapperwrapper里有边界扫描单元、测试访问端口TAP、以及一个叫Flexible Parallel PortFPP的并行测试接口。逻辑die作为主die存储die作为从die通过FPP实现高速测试数据搬运。这样一来ATPG工具可以直接针对wrapper生成向量EDA工具链也有标准接口可以对接。选择IEEE 1838的另一个理由是测试访问机制TAM的标准化。在堆叠结构中测试数据要从外部引脚进入经过逻辑die再到达存储die。这条路径如果自己设计很容易出现带宽瓶颈或者协议不兼容。IEEE 1838定义的TAM支持串行和并行两种模式串行模式用JTAG的TAP适合低速调试并行模式用FPP适合高速ATPG向量搬运。两种模式可以根据测试阶段灵活切换。2.3 逻辑die和存储die的DFT架构如何协同逻辑die和存储die的DFT架构差异很大协同设计是难点。逻辑die的DFT以扫描链为核心ATPG工具生成固定故障和跳变故障的测试向量通过扫描链移入移出。存储die的DFT以MBIST为核心内建自测试电路生成March算法向量自动比较读写结果。在堆叠场景下这两套架构需要打通。我的做法是在逻辑die上设计一个测试调度器Test Scheduler它负责协调逻辑die的扫描测试和存储die的MBIST。具体来说当测试存储die时逻辑die的扫描链可以同时跑自己的测试向量两者并行执行节省测试时间。但要注意并行测试会带来功耗问题两颗die同时跑高速测试功耗可能超过封装的热设计功耗TDP。所以调度器还需要根据功耗预算动态调整测试频率。另一个协同点是测试数据的复用。逻辑die的ATPG向量中有一部分是用于测试逻辑die和存储die之间接口的。这部分向量需要同时考虑逻辑die的输出时序和存储die的输入建立保持时间。我在实际项目中遇到过一个问题逻辑die的ATPG向量在单独测试时覆盖率很高但堆叠后测接口时发现大量时序违例。原因是ATPG工具默认逻辑die的输出负载是标准负载但实际堆叠后输出要经过TSV和微凸块负载特性完全不同。解决办法是在ATPG阶段就导入堆叠后的寄生参数让工具生成考虑实际负载的向量。3. 核心细节解析Die Wrapper、TSV测试与ATPG向量生成3.1 Die Wrapper的设计要点与边界扫描单元插入Die Wrapper是IEEE 1838的核心它的作用是在每颗die的边界上插入一层测试逻辑使得die间互连可以被单独测试。Wrapper的基本结构包括边界扫描单元BSC每个die-to-die互连信号都配一个BSC支持捕获、移位、更新三种操作。Wrapper TAP控制器管理wrapper的测试访问支持IEEE 1149.1和IEEE 1500的指令集。FPP接口并行测试数据端口用于高速ATPG向量搬运。设计Wrapper时有几个关键决策点。第一BSC的插入位置。我通常把BSC插在die的I/O缓冲器和内部逻辑之间这样既能测试互连又能测试I/O缓冲器本身。第二BSC的数量。每个互连信号都需要一个BSCMemory-on-Logic的互连信号可能上千个BSC的面积开销不能忽视。我的经验是对于数据信号BSC可以共享对于控制信号每个信号独立BSC。第三Wrapper的测试模式切换。Wrapper需要支持三种模式正常功能模式、互连测试模式、内部测试模式。模式切换通过TAP指令控制切换逻辑要保证不会在功能模式下引入额外延迟。边界扫描单元的插入流程我一般用EDA工具自动完成但有几个参数需要手动调整# 示例Wrapper BSC插入的Tcl脚本片段 set_wrapper_config \ -bsc_type bidirectional \ -capture_clock wr_cap_clk \ -shift_clock wr_shift_clk \ -update_clock wr_upd_clk \ -reset wr_rst_n insert_wrapper_bsc \ -signals [get_ports data_*] \ -bsc_per_signal 1 \ -shared_capture 0 insert_wrapper_bsc \ -signals [get_ports ctrl_*] \ -bsc_per_signal 1 \ -shared_capture 1注意BSC的时钟域必须与对应信号的时钟域一致否则会出现亚稳态问题。我在一个项目里因为BSC时钟域搞错导致互连测试结果随机翻转排查了整整一周。3.2 TSV测试结构的选型与实现TSV是3D IC的命脉也是测试的难点。TSV的典型故障包括空洞void、断裂open、短路short to substrate、以及电阻偏高。传统的边界扫描只能测逻辑互连测不了TSV的模拟特性。所以需要专门的TSV测试结构。我常用的TSV测试方案有三种方案一环形振荡器Ring Oscillator。把TSV串入环形振荡器通过测量振荡频率来判断TSV的延迟是否正常。频率偏高说明TSV电阻偏大或者有空洞频率偏低说明TSV可能短路。这种方案面积小但只能测延迟不能测电阻绝对值。方案二电荷泵Charge Pump。用TSV作为电容测量充放电时间来计算TSV的电容值。电容值异常说明TSV结构有问题。这种方案精度高但测试时间长。方案三比较器Comparator。在TSV两端加参考电压通过比较器判断TSV的电阻是否在允许范围内。这种方案速度快适合量产测试但需要额外的参考电压源。实际项目中我通常组合使用方案一和方案三。中测阶段用方案一快速筛选最终测试用方案三做精确判断。下面是一个TSV测试结构的Verilog示例module tsv_test_structure ( input wire tsv_in, output wire tsv_out, input wire test_en, input wire ref_voltage, output wire test_result ); // 环形振荡器模式 wire ro_out; ring_oscillator u_ro ( .enable(test_en), .tsv_path(tsv_in), .out(ro_out) ); // 比较器模式 comparator u_comp ( .in_p(tsv_out), .in_n(ref_voltage), .out(test_result) ); // 模式选择 assign tsv_out test_en ? ro_out : tsv_in; endmodule提示TSV测试结构的面积开销要控制在TSV总面积的5%以内否则会影响3D IC的集成密度。我在一个项目里因为测试结构面积过大被迫减少了TSV数量影响了带宽。3.3 ATPG向量生成跨die测试的向量如何构造跨die测试的ATPG向量生成和单颗die的ATPG有本质区别。单颗die的ATPG工具只需要考虑die内部的逻辑和时序。跨die的ATPG工具需要考虑两颗die的接口时序、TSV的延迟、以及Wrapper的测试模式。我的做法是分两步走。第一步分别对逻辑die和存储die做独立的ATPG生成各自的测试向量。第二步针对die间接口生成专门的互连测试向量。互连测试向量的生成需要把两颗die的网表合并成一个虚拟堆叠网表然后在这个网表上跑ATPG。合并网表时有几个关键点TSV模型TSV要建模成RC延迟模型不能简单当成理想导线。我通常用Foundry提供的TSV SPICE模型提取R和C参数然后在网表中插入。微凸块模型微凸块的电阻和电感也要建模特别是高频测试时。Wrapper逻辑Wrapper的BSC要建模成扫描链的一部分这样ATPG工具才能控制互连信号的捕获和移位。下面是一个简化的堆叠网表合并脚本# 合并逻辑die和存储die网表插入TSV模型 def merge_stacked_netlist(logic_netlist, memory_netlist, tsv_model): merged Netlist() # 添加逻辑die merged.add_subckt(logic_netlist) # 添加存储die merged.add_subckt(memory_netlist) # 插入TSV模型 for tsv in get_tsv_list(): merged.add_instance( nameftsv_{tsv.id}, modeltsv_model, nodes[tsv.logic_port, tsv.memory_port] ) # 连接Wrapper BSC for bsc in get_wrapper_bsc_list(): merged.add_instance( namefbsc_{bsc.id}, modelwrapper_bsc, nodes[bsc.in, bsc.out, bsc.capture, bsc.shift, bsc.update] ) return mergedATPG向量生成之后还要做向量验证。我通常用门级仿真验证向量的正确性特别是跨die的时序。仿真时要注意两颗die的仿真模型要分别加载TSV的延迟要准确建模。我踩过的一个坑是仿真时TSV延迟设得太小导致向量在仿真中通过但实际芯片上因为TSV延迟过大而失败。后来我把TSV延迟设为实际值的1.5倍留出足够的余量。4. 实操过程从DFT插入到堆叠测试的完整流程4.1 DFT插入阶段Wrapper、BSC与TSV测试结构的集成DFT插入是整个流程的起点也是最容易出问题的环节。我的实操流程通常分四步第一步定义测试架构。根据堆叠结构确定哪些信号需要Wrapper BSC哪些TSV需要测试结构测试访问路径怎么走。这一步要和设计团队充分沟通因为DFT逻辑会占用面积和布线资源。第二步插入Wrapper和BSC。用EDA工具自动插入但需要手动调整参数。我通常会把BSC的扫描链单独规划不和功能扫描链混在一起这样测试模式切换更干净。第三步插入TSV测试结构。TSV测试结构通常手动插入因为需要根据TSV的物理位置优化布局。我一般把测试结构放在TSV阵列的边缘减少对信号TSV的干扰。第四步连接测试访问机制。把逻辑die的TAP控制器和存储die的TAP控制器通过FPP连接起来形成完整的测试访问路径。这一步要特别注意时钟域 crossingTAP控制器的时钟和功能时钟通常是异步的需要加同步器。DFT插入完成后要跑一遍DRC检查确保没有测试逻辑的时序违例。我常用的检查项包括检查项检查内容常见问题BSC时钟域BSC时钟与信号时钟一致亚稳态、测试结果翻转TSV测试结构测试结构不影响功能TSV功能TSV负载过大TAP连接TAP控制器时钟同步测试模式切换失败扫描链扫描链长度均衡测试时间过长4.2 堆叠前中测KGD筛选的测试向量与流程堆叠前中测的目标是筛选KGD所以测试覆盖率要求极高。逻辑die的中测流程扫描测试跑ATPG生成的固定故障和跳变故障向量覆盖率要求99%以上。MBIST测试如果逻辑die内有SRAM跑MBIST。边界扫描测试测逻辑die的I/O缓冲器。TSV测试测逻辑die上的TSV测试结构。存储die的中测流程MBIST测试跑March算法覆盖率要求95%以上。边界扫描测试测存储die的I/O缓冲器。TSV测试测存储die上的TSV测试结构。中测的测试时间是个大问题。逻辑die的扫描向量可能几百万个跑一遍要几十分钟。我的优化策略是并行测试。用多site测试同时测多颗die。但并行测试会带来功耗问题需要根据测试机的电源能力调整并行度。实操心得中测阶段一定要做测试向量压缩。我用EDA工具的on-chip compression功能把扫描向量压缩10倍以上测试时间大幅缩短。但压缩会带来诊断困难所以我会保留一小部分未压缩的向量用于失效分析。4.3 堆叠后互连测试TSV与微凸块的故障检测堆叠后互连测试是Memory-on-Logic测试的核心。这个阶段的测试流程第一步建立测试访问路径。通过JTAG TAP控制器把测试模式切换到互连测试模式。逻辑die作为主die存储die作为从die通过FPP建立数据通路。第二步跑边界扫描测试。用Wrapper BSC捕获互连信号移位输出比较预期值。这一步可以检测互连的固定故障和桥接故障。第三步跑TSV测试。用TSV测试结构测量TSV的延迟和电阻判断TSV是否正常。第四步跑微凸块测试。微凸块的测试通常用菊花链Daisy Chain结构测量链路的连通性。互连测试的故障检测率我通常要求达到99%以上。但实际项目中TSV的故障检测率很难做到99%因为TSV的模拟特性如电阻偏高不容易用数字测试检测。我的做法是数字测试检测硬故障断裂、短路模拟测试检测软故障电阻偏高。下面是一个互连测试的JTAG指令序列示例# JTAG互连测试指令序列 # 1. 切换到互连测试模式 SIR 0x05 # 加载互连测试指令 SDR 0x01 # 进入互连测试模式 # 2. 捕获互连信号 SDR 0x00 # 捕获当前互连状态 # 3. 移位输出 SDR 0xFFFF # 移位输出捕获值 # 4. 比较预期值 # 如果输出与预期不符标记失效4.4 最终测试系统级功能验证与热管理最终测试是堆叠芯片封装完成后的测试目标是验证整个系统的功能。这个阶段的测试流程系统级功能测试跑真实的应用场景验证跨die的数据通路。系统BIST跑内建自测试验证存储控制器和逻辑die的协同。热测试在高温和低温条件下跑测试验证热稳定性。功耗测试测量不同工作模式下的功耗验证是否在TDP范围内。最终测试的难点是热管理。Memory-on-Logic堆叠结构中逻辑die通常功耗密度很高热量要通过存储die传导出去。如果散热不好存储die的温度可能超过其工作范围。我的做法是在测试程序中加入温度监控当温度超过阈值时降低测试频率或者暂停测试。注意最终测试的测试时间通常比中测短但测试条件更复杂。我建议在最终测试阶段用自适应测试根据芯片的实时表现动态调整测试向量既保证覆盖率又节省时间。5. 常见问题与排查技巧实录5.1 互连测试失效是TSV问题还是Wrapper问题互连测试失效是最常见的问题但定位原因往往很困难。我的排查思路是第一步确认失效模式。是固定失效还是随机失效固定失效通常是硬件问题随机失效可能是时序问题。第二步隔离问题。用JTAG单独测逻辑die的Wrapper再单独测存储die的Wrapper。如果单独测都通过问题在互连如果单独测失败问题在Wrapper。第三步TSV测试。如果Wrapper正常跑TSV测试判断TSV是否正常。第四步微凸块测试。如果TSV正常跑微凸块测试判断微凸块是否正常。下面是一个常见问题速查表问题现象可能原因排查方法解决方案互连测试固定失效TSV断裂或微凸块虚焊跑TSV测试和微凸块测试更换堆叠工艺互连测试随机失效时序违例或时钟域问题跑时序仿真检查时钟同步调整测试频率或加同步器Wrapper测试失败BSC时钟域错误检查BSC时钟与信号时钟修正时钟域TSV测试失败TSV电阻偏高测量TSV电阻优化TSV工艺测试模式切换失败TAP控制器时钟不同步检查TAP时钟加时钟同步器5.2 ATPG覆盖率不达标跨die向量的调试方法ATPG覆盖率不达标是另一个常见问题。跨die向量的覆盖率通常比单die低因为接口逻辑的测试向量不容易生成。我的调试方法方法一检查网表合并是否正确。TSV模型、微凸块模型、Wrapper逻辑是否都正确插入。我遇到过一个案例TSV模型漏了一个参数导致ATPG工具认为TSV是理想导线生成的向量在实际芯片上失败。方法二检查测试模式约束。ATPG工具需要知道哪些信号在测试模式下是可控的哪些是不可控的。如果约束设置错误工具会生成无效向量。方法三手动添加测试点。对于覆盖率低的区域手动添加测试点Test Point提高可控性和可观测性。实操心得跨die ATPG的覆盖率我通常要求达到95%以上。如果达不到先检查网表和约束再考虑加测试点。加测试点会增加面积所以要权衡。5.3 JTAG链路调试TAP控制器不响应的排查步骤JTAG链路调试是DFT工程师的基本功。TAP控制器不响应通常有以下几个原因TCK时钟问题TCK频率太高TAP控制器跟不上。降低TCK频率试试。TMS信号问题TMS信号时序不对TAP控制器状态机跑飞。检查TMS的建立保持时间。TDI/TDO连接问题TDI和TDO接反了或者链路断了。检查连接。电源问题TAP控制器电源没上或者电压不对。检查电源。复位问题TAP控制器没有正确复位。检查TRST信号。我的排查步骤通常是先降TCK频率再检查TMS时序再检查TDI/TDO连接最后检查电源和复位。这个顺序是从最简单到最复杂能快速定位问题。5.4 测试功耗超标并行测试的功耗控制策略并行测试能节省测试时间但功耗会成倍增加。Memory-on-Logic堆叠结构中逻辑die和存储die同时跑测试功耗可能超过TDP。我的功耗控制策略策略一动态频率调整。根据实时功耗动态调整测试频率。功耗高时降频功耗低时升频。策略二分时测试。逻辑die和存储die分时测试不同时跑高速测试。策略三测试向量优化。优化ATPG向量减少同时翻转的信号数量降低动态功耗。策略四电源管理。在测试模式下关闭不必要的电源域降低静态功耗。提示测试功耗超标不仅会影响测试结果还可能损坏芯片。我在一个项目里因为测试功耗过高导致存储die过热失效。后来加了功耗监控电路才解决这个问题。6. 工具选型与流程自动化的一些经验6.1 DFT工具链的选型考量Memory-on-Logic的DFT工具链我通常选择支持IEEE 1838的EDA工具。主流工具包括Synopsys的DFT Compiler、Cadence的Modus、Mentor的Tessent。选型时考虑几个因素IEEE 1838支持工具是否支持Die Wrapper和FPP的自动插入。ATPG能力工具是否支持跨die的ATPG向量生成。调试能力工具是否支持JTAG链路调试和失效诊断。集成能力工具是否能和堆叠设计流程集成。我的经验是Synopsys的DFT Compiler在Wrapper插入方面比较成熟Cadence的Modus在ATPG方面比较强Mentor的Tessent在调试方面比较好。具体选哪个要看项目需求和团队熟悉度。6.2 测试流程自动化的脚本框架测试流程自动化能大幅提高效率。我通常用Python写自动化脚本框架包括配置管理管理不同项目的DFT配置。流程控制控制DFT插入、ATPG、仿真、测试的流程。结果分析分析测试结果生成报告。异常处理处理流程中的异常自动重试或报警。下面是一个简化的自动化脚本框架# DFT流程自动化脚本框架 class DFTFlow: def __init__(self, config): self.config config self.steps [] def add_step(self, step): self.steps.append(step) def run(self): for step in self.steps: try: result step.execute(self.config) if not result.success: self.handle_failure(step, result) except Exception as e: self.handle_exception(step, e) def handle_failure(self, step, result): # 记录失败尝试重试或报警 pass def handle_exception(self, step, e): # 记录异常报警 pass # 使用示例 flow DFTFlow(config) flow.add_step(WrapperInsertion()) flow.add_step(BSCInsertion()) flow.add_step(TSVTestInsertion()) flow.add_step(ATPGGeneration()) flow.add_step(VectorValidation()) flow.run()6.3 测试数据管理与失效分析测试数据管理是DFT流程中容易被忽视的环节。Memory-on-Logic的测试数据量很大包括ATPG向量、仿真结果、测试机日志、失效分析报告。我通常用数据库管理这些数据方便查询和分析。失效分析是测试数据管理的核心应用。当测试失效时需要快速定位失效原因。我的做法是把测试机日志和ATPG向量关联起来当某个向量失效时可以快速找到对应的设计信号然后做物理失效分析。实操心得失效分析的数据要保留至少一年因为有些失效是批次性的需要长期跟踪。我在一个项目里因为删除了早期的测试数据后来出现批次性失效时无法追溯吃了大亏。7. 一些踩坑之后的个人体会Memory-on-Logic堆叠测试的DFT方案说到底是一个系统工程问题。它不是单纯地在两颗die上分别做DFT然后拼起来而是要从堆叠架构的角度重新思考测试策略。我踩过的最大的坑就是早期把两颗die当独立芯片来测忽略了堆叠带来的新问题。TSV测试结构的面积开销是我第二个深刻的教训。TSV是3D IC的命脉但测试结构不能喧宾夺主。我现在的做法是TSV测试结构的面积严格控制在TSV总面积的3%以内宁可降低一点测试覆盖率也不能影响集成密度。JTAG链路调试看起来简单实际上很容易出问题。我的经验是JTAG链路的时钟域一定要仔细检查TAP控制器的时钟和功能时钟的同步器不能省。我见过太多因为时钟域问题导致的随机失效排查起来非常痛苦。最后分享一个小技巧在DFT插入阶段一定要做测试模式的功能仿真。不仅要验证测试模式下测试逻辑的正确性还要验证功能模式下测试逻辑不会引入额外延迟。我通常会在功能仿真中把测试逻辑的使能信号拉低确认功能路径的时序没有变化。这个步骤花不了多少时间但能避免很多后期调试的麻烦。这个领域还在快速演进IEEE 1838标准也在不断完善。后续可以关注的方向包括基于机器学习的测试向量优化、自适应测试调度、以及新型存储器的测试方法。如果你也在做类似的项目欢迎交流踩坑经验。