1. 从Scan Test到At-Speed Test的DFT演进逻辑1.1 为什么Scan Test不够用了刚入行做DFT的时候我对Scan Test的理解就是把触发器串成扫描链用ATE灌测试向量看输出对不对。逻辑简单、覆盖率高感觉已经够用了。但后来接触到先进工艺节点的芯片项目才发现事情远没有这么简单。Scan Test本质上是一种静态测试。它通过扫描链把测试数据移入触发器然后施加一个或多个功能时钟脉冲再把结果移出来比对。这个过程中时钟频率通常远低于芯片的实际工作频率一般在10MHz到50MHz之间。问题就出在这里一个芯片在低频下功能正常不代表它在高频下也能正常工作。先进工艺节点下芯片内部存在大量的延迟缺陷。这类缺陷不会导致逻辑功能完全失效而是在特定频率下才暴露出来。比如一条路径的建立时间因为工艺偏差、电压波动或温度变化而变得临界低频测试根本抓不到它。等到芯片装到板子上跑高频问题才爆发出来这时候已经晚了。我踩过的一个真实案例某颗芯片在Scan Test下良率99.5%但客户反馈板级测试有2%的失效。后来分析发现失效的芯片都存在一条关键路径的延迟超标而这条路径在低频Scan Test下完全测不出来。这就是典型的测试逃逸。1.2 At-Speed Test到底在测什么At-Speed Test的核心思路很直接让芯片在接近或等于实际工作频率下进行测试。它要抓的是那些在低频下表现正常、但在高频下会出问题的延迟缺陷。具体来说At-Speed Test主要覆盖以下几类缺陷过渡延迟缺陷信号从0到1或从1到0的翻转速度不够快导致在时钟沿到来时数据还没稳定。路径延迟缺陷组合逻辑路径的总延迟超过了时钟周期导致建立时间违例。串扰引起的延迟相邻信号线之间的耦合电容导致信号延迟增加这种效应在高频下更明显。和Scan Test相比At-Speed Test的测试向量生成要复杂得多。它需要在功能时钟域下施加两个或多个连续脉冲第一个脉冲负责发射Launch第二个脉冲负责捕获Capture。发射沿和捕获沿之间的时间间隔决定了测试的频率。注意At-Speed Test的覆盖率通常比Scan Test低一些因为不是所有路径都能在功能时钟下被激活和观测。但它的缺陷检出效率远高于Scan Test尤其是在先进工艺节点下。1.3 从静态到动态的测试架构变化从Scan Test切换到At-Speed Test整个测试架构需要做几件事第一时钟必须可控。Scan Test下时钟由ATE直接提供频率低、抖动大也无所谓。但At-Speed Test需要芯片内部的PLL产生高频时钟而且要求时钟的占空比、抖动、偏斜都满足功能要求。第二需要OCC来管理时钟切换。OCCOn-Chip Clock Controller是At-Speed Test的核心模块它负责在扫描移位阶段和捕获阶段之间切换时钟源。移位时用慢速ATE时钟捕获时切换到PLL输出的高速功能时钟。第三复位和时钟门控必须配合。Clock Gating在功能模式下用来省电但在测试模式下如果不受控会导致某些触发器收不到时钟测试向量失效。复位信号也一样测试模式下需要确保复位不会意外触发否则捕获阶段的数据会被清零。这三件事构成了At-Speed Test的底层支撑。下面我会逐一拆解OCC、Clock Gating和复位在DFT中的具体处理方式。2. OCC模块的设计细节与实操要点2.1 OCC的基本结构和时钟切换原理OCC的全称是On-Chip Clock Controller直译就是片上时钟控制器。它的核心功能是在移位时钟和捕获时钟之间做无缝切换。一个典型的OCC模块包含以下几个关键信号信号名方向功能说明scan_en输入扫描使能高电平表示移位阶段pll_clk输入PLL输出的高速功能时钟ate_clk输入ATE提供的慢速时钟occ_en输入OCC使能控制是否启用At-Speed模式clk_out输出输出到被测逻辑的时钟工作时序是这样的当scan_en1时OCC输出ate_clk扫描链正常移位当scan_en从1变0时OCC在几个周期内完成时钟切换输出pll_clk然后施加发射和捕获脉冲。这里有个关键细节时钟切换不能产生毛刺。如果切换过程中出现窄脉冲触发器可能误触发导致测试失败。所以OCC内部通常用同步器加时钟门控来实现无毛刺切换。2.2 时钟切换的时序约束和常见问题OCC的时钟切换时序是At-Speed Test中最容易出问题的地方。我总结了几个关键约束切换窗口必须足够宽。从scan_en拉低到第一个捕获脉冲之间需要留出至少2到3个pll_clk周期让时钟稳定下来。如果切换太快PLL可能还没锁定时钟频率和相位都不对。时钟门控的使能信号必须同步。如果使能信号是异步的可能在时钟高电平期间变化导致输出出现毛刺。标准做法是用两级触发器做同步化再配合时钟门控单元。OCC的输出时钟树需要平衡。如果OCC到不同触发器的时钟路径延迟差异太大捕获沿到达的时间不一致会导致某些触发器提前或滞后捕获测试结果不可靠。实操心得在OCC的验证阶段一定要做门级仿真把SDF文件反标进去检查时钟切换时的毛刺和时序。RTL仿真看不到这些细节问题。2.3 OCC在Shared Bus DFT架构中的特殊处理现在很多SoC采用Shared Bus DFT架构多个IP共享一条测试总线。这种架构下OCC的设计需要额外考虑几个问题。总线仲裁和OCC的配合。当多个IP同时需要At-Speed测试时总线仲裁器需要确保同一时刻只有一个IP在捕获阶段否则总线冲突会导致测试失败。通常的做法是在OCC模块中增加一个测试请求/授权机制由总线仲裁器统一调度。时钟域交叉的处理。Shared Bus DFT架构下不同IP可能工作在不同的时钟域。OCC需要为每个时钟域独立生成捕获时钟同时确保跨时钟域的路径在测试模式下被正确隔离或同步。PVT IP DFT设计的考量。PVTProcess, Voltage, Temperature传感器IP通常需要独立测试因为它们的输出是模拟量或低速数字量。在Shared Bus DFT架构下PVT IP的OCC需要支持旁路模式让测试数据直接通过不经过At-Speed捕获。我做过一个项目Shared Bus上挂了8个IP其中3个有独立的OCC。调试阶段发现其中一个IP的At-Speed测试总是失败后来定位到是总线仲裁器的授权信号和OCC的使能信号之间存在竞争。解决方案是在OCC中增加一个握手协议确保授权信号稳定后再启动时钟切换。3. Clock Gating在DFT中的双刃剑效应3.1 Clock Gating为什么会影响测试Clock Gating在功能设计中的目的是省电当某个模块不工作时把它的时钟关掉避免不必要的翻转。但在测试模式下Clock Gating如果不受控会带来两个问题第一扫描链断裂。如果某个触发器的时钟被门控关掉了它在移位阶段就收不到时钟数据无法移入或移出。这会导致扫描链的覆盖率下降甚至整条链失效。第二捕获阶段数据丢失。在At-Speed Test的捕获阶段如果被测路径上的某个触发器时钟被关掉捕获沿到来时它不会更新测试结果就是错的。所以DFT设计的一个基本原则是测试模式下所有Clock Gating必须被旁路或强制打开。3.2 测试模式下的Clock Gating旁路方案常见的Clock Gating旁路方案有两种方案一增加测试使能信号。在Clock Gating单元的使能端加一个OR门测试模式下test_en1强制使能时钟。这种方案简单直接但会增加一个OR门的延迟可能影响功能时序。方案二用多路选择器切换。在Clock Gating单元的输出端加一个MUX测试模式下直接选择原始时钟旁路整个Gating逻辑。这种方案对功能时序影响小但面积开销大一些。方案面积开销时序影响适用场景OR门强制使能小增加OR门延迟时序宽松的设计MUX旁路大几乎无影响高频设计集成到OCC中可控Shared Bus DFT在实际项目中我通常推荐集成到OCC的方案。OCC本身就在管理时钟切换把Clock Gating的旁路逻辑集成进去可以减少额外的控制信号也方便统一管理。3.3 Clock Gating对At-Speed测试覆盖率的影响Clock Gating旁路之后理论上所有触发器都能收到时钟。但实际中还有一个问题Clock Gating的使能信号本身可能来自被测逻辑。如果使能信号在捕获阶段发生变化时钟可能在捕获沿附近被关掉导致捕获失败。解决这个问题的方法是在测试模式下冻结Clock Gating的使能信号。具体做法是在OCC中增加一个锁存器在捕获阶段锁存所有Clock Gating使能信号的值确保它们在捕获窗口内保持不变。注意冻结使能信号会增加测试逻辑的面积但这是保证At-Speed测试可靠性的必要代价。我在一个28nm项目上做过对比冻结使能信号后At-Speed测试的覆盖率从87%提升到了94%。3.4 低功耗设计与DFT的平衡现在很多芯片采用多电压域和电源门控设计这给DFT带来了额外的挑战。电源门控关掉的模块在测试模式下必须上电否则无法测试。但全部上电又会导致测试功耗过高可能烧毁芯片。我的经验是采用分区域测试策略把芯片分成多个电源域每次只上电一个区域进行测试其他区域保持断电。OCC需要为每个区域独立生成时钟测试控制器负责调度不同区域的测试顺序。这种策略的代价是测试时间变长但可以有效控制测试功耗。在一个移动芯片项目中我们通过分区域测试把峰值测试功耗从8W降到了3W避免了测试时的过热问题。4. 复位策略在At-Speed Test中的关键作用4.1 复位为什么是DFT的隐形杀手复位信号在功能设计中用来把电路初始化到已知状态。但在测试模式下复位如果处理不当会直接导致测试失败。最常见的问题是捕获阶段复位意外触发。如果复位信号在捕获沿附近有效触发器会被强制清零捕获的数据全部丢失。更糟糕的是这种失败是间歇性的取决于复位信号的时序和测试向量的具体内容很难调试。另一个问题是复位树的偏斜。复位信号到达不同触发器的时间不一致导致某些触发器先复位、某些后复位。在移位阶段这可能导致扫描链中的数据被部分清零。4.2 测试模式下的复位隔离方案标准的做法是在测试模式下隔离功能复位用测试复位代替。具体方案方案一复位MUX。在复位信号进入触发器之前加一个MUX测试模式下选择测试复位。测试复位由ATE直接控制在移位阶段保持无效捕获阶段也保持无效。方案二复位同步器。在复位信号路径上增加同步器确保复位信号的释放与时钟同步。这可以避免复位释放时的亚稳态问题。方案三复位门控。用测试使能信号门控复位测试模式下直接屏蔽功能复位。我通常推荐方案一加方案二的组合用MUX隔离功能复位同时用同步器确保测试复位的释放时序。这样既保证了测试的可靠性又不会影响功能复位的正常使用。4.3 复位与OCC的协同工作复位和OCC的协同是At-Speed Test中最容易忽略的细节。OCC在切换时钟时如果复位信号同时变化可能导致触发器进入未知状态。正确的做法是在OCC切换时钟之前确保复位信号已经稳定。具体时序要求是复位释放必须在scan_en拉低之前完成复位有效必须在捕获阶段结束后才能施加。在Shared Bus DFT架构下复位和OCC的协同更加复杂。不同IP的复位信号可能来自不同的源OCC需要为每个IP独立管理复位时序。我的做法是在OCC中增加一个复位状态机跟踪每个IP的复位状态确保时钟切换和复位释放的顺序正确。4.4 常见复位相关测试失败案例案例一复位释放太晚。某个项目在At-Speed测试时捕获阶段的数据总是全0。调试发现复位信号在捕获沿之后才释放触发器一直被复位。解决方案是调整复位释放的时序提前2个周期释放。案例二复位树偏斜导致扫描链失效。移位阶段扫描链输出不对定位到复位信号到达不同触发器的时间差了3ns。解决方案是在复位树中插入缓冲器平衡延迟。案例三复位与Clock Gating冲突。某个模块的复位信号同时控制了Clock Gating的使能测试模式下复位有效时时钟被关掉扫描链断裂。解决方案是把复位和Clock Gating的控制逻辑分开测试模式下独立控制。5. At-Speed Test的完整实操流程与调试技巧5.1 从RTL到硅片的完整测试流程At-Speed Test的实操流程可以分为以下几个阶段阶段一DFT规则检查。在RTL阶段就要检查Clock Gating、复位、OCC的DFT规则。用SpyGlass或类似工具做DRC检查确保所有触发器在测试模式下可控可观测。阶段二扫描链插入。用DFT Compiler或类似工具插入扫描链同时插入OCC和Clock Gating旁路逻辑。这个阶段要特别注意时钟域的处理不同时钟域的扫描链要分开。阶段三ATPG向量生成。用TetraMAX或类似工具生成At-Speed测试向量。需要指定发射和捕获的时钟波形以及OCC的控制信号时序。阶段四门级仿真验证。把ATPG向量反标到门级网表做带SDF的仿真。检查OCC切换、Clock Gating旁路、复位隔离是否按预期工作。阶段五硅片测试调试。在ATE上跑向量分析失败案例。用Shmoo图分析电压和频率的裕量定位延迟缺陷。5.2 ATPG向量生成的关键参数设置ATPG向量生成是At-Speed Test的核心环节。以下是我常用的参数设置# TetraMAX At-Speed ATPG 参数示例 set_atpg -mode full_sequential set_atpg -launch_clock pll_clk set_atpg -capture_clock pll_clk set_atpg -launch_edge rising set_atpg -capture_edge rising set_atpg -clock_period 2.0 set_atpg -num_pulses 2 set_atpg -occ_enable true set_atpg -clock_gating_bypass true set_atpg -reset_isolation true关键参数说明launch_edge和capture_edge决定发射沿和捕获沿的极性。通常用上升沿发射、上升沿捕获或者上升沿发射、下降沿捕获。clock_period捕获时钟的周期决定了测试频率。这个值要略大于功能时钟周期留出裕量。num_pulses脉冲数量。At-Speed Test通常用2个脉冲第一个发射第二个捕获。occ_enable启用OCC控制ATPG工具会自动生成OCC的控制信号。实操心得clock_period的设置很关键。设得太小测试频率太高良率会下降设得太大测试频率太低抓不到延迟缺陷。我的经验是设为功能时钟周期的1.1到1.2倍既能覆盖大部分延迟缺陷又不会过度筛选。5.3 测试失败的分析和定位方法At-Speed测试失败的分析比Scan Test复杂得多。我通常按以下步骤排查第一步确认失败模式。是固定失败还是间歇失败是所有向量都失败还是部分失败固定失败通常是设计问题间歇失败通常是时序或噪声问题。第二步Shmoo分析。在ATE上做电压-频率的Shmoo图看失败边界。如果失败边界是一条斜线说明是延迟问题如果是一个区域说明是功能问题。第三步波形调试。用ATE的波形捕获功能抓取失败时的时钟、复位、OCC控制信号波形。检查是否有毛刺、时序违例或竞争。第四步物理分析。如果以上步骤都找不到原因可能需要做失效分析用SEM或EMMI定位物理缺陷。5.4 常见问题速查表问题现象可能原因排查方法解决方案捕获数据全0复位意外触发检查复位时序调整复位释放时间捕获数据全1时钟未切换检查OCC输出验证OCC使能信号间歇性失败时钟抖动或偏斜Shmoo分析优化时钟树扫描链移位失败Clock Gating未旁路检查Gating使能强制旁路Gating覆盖率低OCC控制信号未连接检查ATPG报告补充OCC约束测试功耗过高所有区域同时上电测量测试电流分区域测试5.5 DFT计算智能体的应用探索最近两年DFT计算智能体开始在一些项目中试点。它的核心思路是用机器学习模型来预测ATPG向量生成的结果减少迭代次数。具体做法是用历史项目的ATPG数据训练一个模型输入是设计特征触发器数量、时钟域数量、OCC配置等输出是预测的覆盖率和向量数量。在向量生成之前先用模型预测如果覆盖率不达标提前调整设计或约束。我在一个项目中试过这种方法把ATPG迭代次数从平均15次降到了8次节省了大约40%的向量生成时间。但模型的准确性依赖训练数据的质量和数量目前还只能作为辅助手段不能完全替代人工调试。6. 从项目实战中积累的DFT经验6.1 先进工艺节点下的新挑战到了7nm和5nm节点At-Speed Test面临几个新挑战时钟频率更高。功能时钟可能跑到2GHz以上OCC的时钟切换时序更加紧张。传统的两级同步器可能不够需要三级甚至四级。工艺偏差更大。先进工艺下同一颗芯片内部不同区域的延迟差异可能达到20%以上。At-Speed Test的时钟周期需要留出足够的裕量否则良率会大幅下降。测试功耗密度更高。晶体管密度增加单位面积的测试功耗上升。如果不做分区域测试局部过热可能导致测试失败甚至芯片损坏。我的应对策略是在OCC中增加可编程延迟链根据PVT传感器的读数动态调整时钟切换的时序在测试控制器中增加功耗管理单元实时监控测试电流超过阈值就暂停测试。6.2 多时钟域At-Speed测试的同步问题多时钟域设计在SoC中很常见但给At-Speed测试带来了同步问题。不同时钟域的频率可能不同相位关系也不确定。解决方案是分时测试每个时钟域独立测试测试时其他时钟域保持静止。OCC需要为每个时钟域独立生成捕获时钟测试控制器负责调度。对于跨时钟域的路径需要在测试模式下隔离或同步。隔离的方法是在跨时钟域路径上插入测试MUX测试模式下断开连接同步的方法是用握手协议确保数据在捕获沿之前稳定。6.3 DFT与功能安全的交叉功能安全Functional Safety要求芯片在故障时能进入安全状态。DFT测试需要覆盖安全相关的逻辑确保故障能被检测到。具体做法是在安全关键路径上增加测试点提高可观测性在OCC中增加安全模式测试时模拟故障注入验证安全机制是否正常工作。这部分内容比较专业涉及ISO 26262等标准这里不展开。但如果你做的是汽车芯片DFT和功能安全的交叉是必须考虑的。6.4 个人实操体会做了这么多年DFT我最大的体会是At-Speed Test的成功80%取决于设计阶段的DFT规划20%取决于测试调试。如果OCC、Clock Gating、复位的DFT规则在RTL阶段就处理好后面的测试会顺利很多。反之如果设计阶段留下隐患调试阶段可能要花几周甚至几个月来定位。另外门级仿真不能省。我见过太多项目为了赶进度跳过门级仿真结果在硅片上发现OCC切换有问题重新流片的成本是仿真成本的几百倍。最后分享一个小技巧在OCC的验证中可以写一个自动化检查脚本遍历所有时钟切换场景自动检查毛刺和时序违例。这个脚本一次编写后续项目可以复用能节省大量调试时间。