1. 为什么层次化DFT是复杂SoC的“必选项”大家好我是老张在芯片测试这行摸爬滚打了十几年。这些年眼看着芯片设计从百万门级直奔百亿门级一个芯片里塞进几十个、上百个功能模块我们常叫它“核心”或“Core”已经是家常便饭。面对这种“巨无霸”SoC如果你还想着用传统的、一锅端的扁平化DFT方法那测试时间、功耗、数据量这些指标绝对会让你崩溃。这就好比你要给一栋摩天大楼做全面安全检查如果只能从一楼开始一层层往上爬那得查到猴年马月更聪明的办法是把大楼分成几个功能区比如办公区、酒店区、商业区每个区有独立的检查团队同时开工最后再汇总结果。层次化DFTHierarchical DFT就是这个“分而治之”的聪明策略。简单来说层次化DFT就是把整个芯片的测试任务按照物理和逻辑的层次结构进行分解。每个功能核心Wrapped Core自己先做好内部测试Intest就像每个功能区先自查消防和电路然后在芯片顶层我们再测试这些核心之间的连接和交互逻辑Extest就像检查功能区之间的走廊和管道是否畅通。Tessent Shell作为业界顶级的DFT工具链提供了一整套方法论和自动化流程来支持这种策略。它的核心价值在于让你能从顶层规划开始清晰地定义每个核心的测试责任、测试接口和测试调度然后自底向上地、像搭积木一样完成整个芯片的测试架构搭建。这不仅大幅提升了测试效率降低了测试数据量ATE内存可是很贵的更重要的是它让超大规模芯片的测试变得可管理、可实施。接下来我就结合一个具体的多核心SoC场景带你一步步拆解如何用Tessent Shell玩转层次化DFT。2. 顶层规划画好你的“测试地图”在动手写任何脚本之前规划是重中之重。很多新手工程师拿到设计就急着跑插入结果做到一半发现引脚不够、时钟冲突、功耗超标推倒重来的代价巨大。层次化DFT的规划必须坚持“自顶向下规划自底向上实现”的原则。2.1 理解物理布局区域与测试责任划分首先你得和物理设计团队紧密沟通拿到芯片的物理布局区域Physical Layout Regions划分图。这个图不是RTL代码的模块层次而是最终版图Layout上一个个物理隔离的区块。比如你的SoC里可能有一个CPU集群区、一个GPU区、几个DSP区、还有各种外设IP区。Tessent Shell正是基于这些物理区块来部署DFT的。每个物理区块在DFT语境下就是一个潜在的“Wrapped Core”。规划的第一步就是确定哪些区块需要被“包裹”Wrap起来成为独立的测试单元。我的经验是通常满足以下条件的区块需要重点考虑功能独立比如一个完整的第三方IP如ARM CPU Core。逻辑规模大内部扫描链很长单独测试能优化测试时间。时钟域独立拥有自己独立的时钟源或时钟生成电路。需要复用同一个IP在芯片内被多次例化Instantiated。确定了Wrapped Core列表后就要为每个核心分配测试资源主要是测试访问机制TAM的通道。这就像给每个功能区分配检查人员和通道。你需要评估芯片顶层能拿出多少引脚Pins专门用于测试。假设你有64个引脚可用那么就要决定是给每个核心独占几个通道还是让多个核心共享一组通道这直接影响到后续的测试调度和并行度。2.2 核心建模Wrapper Cell与Graybox Model规划好了哪些核心要独立测试接下来就要定义它们的“测试接口”。这就是Wrapper Cell的用武之地。Wrapper Cell不是额外添加的寄存器而是巧妙利用了核心边界上已有的功能触发器Flops。这些触发器在功能模式下正常工作在测试模式下则变身成为隔离核心内外的“哨兵”我们称之为Shared Wrapper Cells。举个例子假设核心A有一个输出信号data_out连接到核心B。在核心A的边界上驱动data_out的那个触发器就可以被配置为一个Output Shared Wrapper Cell。当测试核心A内部Intest时这个Wrapper Cell能捕获核心A内部逻辑产生的测试响应当测试核心A与核心B的连接Extest时它又能向核心B施加测试激励。除了利用已有的触发器对于连接着大型组合逻辑锥Large Logic Cone的输入输出端口我们可能需要插入Dedicated Wrapper Cells。这是一种纯粹的扫描寄存器专门为了测试而添加确保那些难以观测和控制的内部门级故障也能被覆盖到。所有Wrapper Cell连接起来就形成了环绕核心的Wrapper Chain。Wrapper Chain以内的逻辑属于核心的内部模式Internal Mode以外的逻辑即核心间的互连逻辑属于外部模式External Mode。那么在芯片顶层进行测试时我们不需要把每个核心的详细门级网表都加载进来那样太笨重了。Tessent Shell使用Graybox Model灰盒模型来代表一个被包裹的核心。你可以把它想象成一个只有“外壳”的模型它只包含Wrapper Chain和必要的IJTAG测试访问网络而把核心内部庞大的逻辑全部拿掉了。使用Graybox Model能极大加快顶层设计加载和模式生成的速度。生成Graybox Model的命令很简单通常在完成核心级DFT插入后执行create_graybox_model -module core_name -output model_file3. 时钟与测试调度让测试“并行”跑起来时钟是芯片的脉搏也是测试中最棘手的部分之一。层次化测试要求每个Wrapped Core的测试模式Pattern能独立生成并在顶层被正确地“重定向”Retarget。这就离不开片上时钟控制器OCC的精细设计。3.1 层次化OCC时钟架构设计在功能模式下芯片的时钟架构可能很复杂有分频、倍频、门控等多种情况。但在测试模式下我们需要对时钟进行局部独立控制。每个Wrapped Core内部都应该插入自己的OCC。这样为核心A生成的测试模式其时钟波形是由A内部的OCC定义的与核心B的时钟无关。当这些模式被重定向到芯片顶层时顶层的ATE只需要提供原始的参考时钟各个核心内部的OCC会负责再生出测试所需的精确波形。OCC的类型Standard, Parent, Child和配置需要根据时钟平衡Clock Balancing策略和测试模式Intest/Extest下的行为来决定。比如在Intest模式下核心内部的OCC是活跃的负责产生扫描移位Shift和捕获Capture时钟而在Extest模式下该核心的OCC被旁路时钟由顶层或相邻核心的OCC来控制。规划时需要仔细定义每个核心在两种模式下的时钟来源避免时钟冲突或不可控的时钟域交叉CDC问题。3.2 基于资源约束的测试调度策略测试调度Test Scheduling的目标很简单在有限的ATE引脚、通道和内存资源下用最短的时间完成所有测试。这就像是一个资源受限的并行任务调度问题。Tessent Shell提供了强大的分析命令来辅助决策。首先你需要用analyze_compression命令为每个核心分析其最佳的压缩方案。压缩比越高意味着生成测试模式越少测试时间越短但可能需要更多的EDT输入通道Channel。你需要在这之间取得平衡。假设经过分析我们有一个包含以下核心的SoCBlk_A 12个实例每个实例需要2个输入通道1个输出通道模式数量中等。Blk_B 8个实例每个需要4个输入通道2个输出通道模式数量较多。Blk_C 1个实例需要8个输入通道4个输出通道模式数量巨大。芯片顶层共有64个测试引脚可用。一个高效的调度策略可能是并行测试相同核心将12个Blk_A实例分为两组每组6个并行测试。每组需要6 * (21) 18个通道两组先后进行充分利用资源。合并测试复杂度相近的核心Blk_B的8个实例可以一起测试需要8 * (42) 48个通道。单独测试大型核心Blk_C单独测试需要8412个通道。为了更直观我们可以用一个表格来规划测试阶段测试核心输入通道数输出通道数总计通道数并行度阶段1Blk_A (实例1-6)126186阶段2Blk_A (实例7-12)126186阶段3Blk_B (所有实例)3216488阶段4Blk_C (单实例)84121如果你的设计采用了流扫描网络SSN那么调度会更加灵活。SSN像一条内部测试总线所有核心都挂载在上面。ATE通过少数几个引脚与SSN的ScanHost通信再由ScanHost动态分配带宽给各个核心。这样你甚至可以在生成测试模式之后再动态调整哪些核心并行测试SSN会自动平衡带宽让模式数量多的核心得到更多数据吞吐从而让所有核心几乎同时结束测试减少了空闲等待Padding时间。4. 实战步骤从核心封装到系统集成理论规划得再好也得落地到具体的Tessent Shell流程。下面我就以一个包含加密引擎Crypto_Core和图像处理器ISP_Core的SoC为例梳理关键步骤。4.1 核心级DFT插入与封装首先我们针对每个需要独立测试的核心如Crypto_Core进行DFT插入。这个过程在核心本身的网表上进行。设置DFT规格使用set_dft_specification命令定义扫描链数量、时钟、复位策略等。特别要注意为层次化测试预留Wrapper Cell。set_dft_specification -scan true -clock_gating false -test_points none add_scan_segment -name seg1 -scan_elements [get_cells -hier *reg*] -length 100插入扫描链和OCC运行insert_dft命令。工具会自动插入扫描链、OCC并将边界触发器识别为Shared Wrapper Cells。你需要检查报告确认Wrapper Cell是否被正确识别。insert_dft report_wrapper_cells -verbose ./rpt/crypto_core_wrapper.rpt生成核心测试模式使用Tessent TestKompress或FastScan为核心生成内部模式Intest。这些模式是基于核心内部OCC时钟生成的是自包含的Self-contained。创建Graybox Model为核心生成灰盒模型用于顶层集成。create_graybox_model -module Crypto_Core -output ./model/crypto_core_graybox.v4.2 芯片级集成与测试模式重定向完成所有核心的独立DFT后开始芯片顶层的集成。集成Graybox Model在芯片顶层网表中用各个核心的Graybox Model替换掉原来的完整模块。这能显著减小设计规模提升工具处理速度。配置顶层测试访问机制TAM根据之前的规划使用set_dft_specification配置顶层的EDT控制器、通道分配和SSN如果使用。确保顶层引脚到各个核心Wrapper Chain的连接关系正确。模式重定向Pattern Retargeting这是层次化DFT的“魔法”步骤。使用retarget_patterns命令将之前为核心生成的内部测试模式重定向到芯片顶层。read_patterns ./patterns/crypto_core_intest.stil retarget_patterns -source_instance Crypto_Core_inst -target_design top_level这个过程会利用核心的Graybox Model和顶层的时钟、引脚映射关系自动将核心级的测试向量转换成芯片级的测试向量无需重新运行耗时的ATPG。生成外部模式Extest在顶层针对核心之间的互连逻辑生成外部测试模式。此时核心被看作黑盒其Graybox Model仅提供Wrapper Chain工具只测试连接这些Wrapper Cell的组合逻辑。4.3 验证与调试不要以为生成模式就万事大吉了。必须进行严格的验证。DRC检查在核心级和芯片级都要运行完整的DFT规则检查DRC确保没有违反扫描链、时钟、复位等规则。模式验证Pattern Validation使用仿真工具对重定向后的芯片级模式进行仿真比对输出响应与预期值。这是发现时钟、复位、Wrapper Cell控制信号等问题的最直接方法。功耗分析并行测试多个核心时瞬时开关功耗可能超标。需要使用analyze_power等命令分析测试模式下的功耗必要时调整测试调度错开高功耗核心的测试时间。我在一个项目中就踩过坑两个核心的Extest模式同时运行时由于共享电源网络导致了IR Drop超标部分触发器采样错误。后来通过调整调度将它们分开测试并加入了基于SSN的功耗感知调度才解决了问题。5. 避开那些年我踩过的“坑”层次化DFT功能强大但陷阱也不少。分享几个常见的“坑”和我的应对经验。坑一时钟异步与OCC配置错误。这是最常见的问题。如果两个Wrapped Core的时钟是异步的那么它们的测试模式必须分开运行或者在顶层设计额外的同步逻辑。在定义OCC时一定要明确每个OCC在Intest和Extest模式下的行为。我习惯用一个Excel表格列出所有核心、所有时钟域、以及它们在各种测试模式下的OCC状态和时钟源确保万无一失。坑二Wrapper Chain长度不平衡。如果来自不同核心的Wrapper Chain长度差异巨大在并行测试时工具会按照最长的链来填充Padding短链造成测试时间浪费。在规划阶段就要用report_wrapper_cells和analyze_chain_length命令预估链长并通过插入Dedicated Wrapper Cells或调整扫描链划分来平衡它们。坑三测试引脚资源争用。规划时觉得引脚够用实现时发现布线拥堵或者功能模式下的某些引脚在测试模式下无法复用。一定要尽早与芯片架构和封装团队确认测试引脚Test Pin的分配和物理位置。对于高引脚数核心积极考虑使用SSN来减少对顶层引脚的直接依赖。坑四Graybox Model与实际网表不匹配。如果核心级DFT插入后网表有改动比如ECO但忘记更新Graybox Model那么重定向的模式肯定会出错。必须将更新Graybox Model作为核心网表任何修改后的强制步骤纳入版本管理流程。坑五忽略功耗域和电压域。现代SoC常有多个功耗域Power Domain和电压域Voltage Island。一个核心可能横跨多个域。在插入Wrapper Cell和规划测试调度时必须考虑电平转换器Level Shifter和隔离单元Isolation Cell的影响确保测试模式下信号电平正确且不会产生漏电路径。Tessent Shell支持多电压设计但需要正确设置set_power_domain等相关约束。层次化DFT就像为芯片测试构建一套精密的流水线前期规划越细致后期实施就越顺畅。它要求DFT工程师不仅懂工具命令更要理解芯片架构、物理设计和ATE约束。希望这份实战指南能帮你理清思路少走弯路。记住没有最好的架构只有最适合当前项目约束的架构。多和前后端同事沟通用数据面积、时序、功耗、测试时间说话你的层次化DFT方案就能成为芯片成功量产的有力保障。