在芯片后端和测试领域摸爬滚打这些年有一个话题几乎每隔一段时间就会被团队拿出来反复讨论Scan Test明明覆盖率已经跑到99%以上了为什么还要折腾At-Speed Test更让人头疼的是一旦决定上At-SpeedOCCOn-Chip Clock Controller、Clock Gating、复位策略这三座大山就横在面前稍有不慎就是仿真过、硅上挂。我经历过不止一次这样的场景扫描链本身没问题但一上高速测试就出现大量随机失效排查几天最后发现是OCC的时钟切换时序和复位释放顺序没对齐。这篇文章就把我从Scan Test过渡到At-Speed Test过程中关于OCC设计、Clock Gating处理和复位策略的实战经验完整梳理一遍适合已经了解DFT基础、正在推进At-Speed测试方案的工程师参考也适合想搞清楚为什么低速扫描不够用的读者建立系统认知。1. 为什么低速Scan Test撑不住现代芯片的测试需求1.1 Scan Test能覆盖什么、漏掉了什么Scan Test的核心思路很直接把芯片内部的触发器串成扫描链通过移位把测试向量灌进去再通过捕获和移出比对结果。这套方法对静态故障模型——比如固定型故障Stuck-At Fault——的检测效率极高覆盖率轻松做到99%以上。但问题在于现代芯片里大量的失效并不是某根线固定为0或1这么简单。实际流片回来的失效分析中相当比例的缺陷表现为时序相关的路径延迟某条组合逻辑路径在低速下功能正常但在芯片标称工作频率下建立时间不够导致数据捕获错误。Scan Test跑在几MHz到几十MHz的慢速时钟下这些延迟缺陷根本暴露不出来。你可以把Scan Test理解成用慢动作检查每个关节能不能动而At-Speed Test是让芯片在真实奔跑速度下看会不会摔倒。1.2 延迟缺陷的两种模型Transition和Path DelayAt-Speed Test主要针对两类延迟故障模型。Transition Delay FaultTDF关注的是每个节点上的慢翻转——上升沿太慢或下降沿太慢。它的向量生成相对成熟覆盖率容易做高。Path Delay FaultPDF则关注整条路径的累积延迟更贴近真实失效但向量生成复杂度高得多实际项目中通常以TDF为主、PDF为辅。这里有个经验性的取舍TDF覆盖率做到95%以上通常就能抓住大部分延迟缺陷但如果你的芯片有特别关键的高速接口路径建议针对这些路径单独做PDF分析。我在一个高速SerDes项目里就吃过亏——TDF覆盖率98%但某条跨时钟域的数据路径在硅上间歇性出错后来补了针对性的路径延迟向量才定位到问题。1.3 At-Speed Test对时钟结构的硬性要求低速Scan Test可以用一个统一的慢速时钟驱动所有扫描链简单省事。但At-Speed Test要求捕获时钟必须是芯片的功能时钟而且要在正确的频率和相位关系下工作。这就引出了核心矛盾测试模式下芯片的PLL可能还没锁定功能时钟树可能被Clock Gating关掉复位状态也可能和功能模式不同。所以你需要一套机制能在测试模式下从慢速的扫描移位时钟平滑切换到高速的功能捕获时钟并且保证切换过程中不产生毛刺、不丢失脉冲。这套机制就是OCC。没有OCCAt-Speed Test基本无从谈起。2. OCC到底在做什么时钟切换的时序账2.1 OCC的基本结构和信号流OCC本质上是一个时钟选择与门控电路通常放在时钟树的根部或每个时钟域的入口。它的核心输入包括慢速的扫描移位时钟通常来自ATE的参考时钟、高速的功能时钟来自PLL或外部高速时钟源、以及一组控制信号Test Mode、Scan Enable、Capture Enable等。典型结构里OCC内部有一个时钟多路选择器MUX和一个脉冲发生器。在Shift阶段MUX选择慢速时钟让扫描链稳定移位在Capture阶段MUX切换到高速时钟并只放出指定数量的脉冲通常是1到2个用于捕获。这个指定数量非常关键——放多了会导致多次捕获覆盖结果放少了捕获不到。2.2 时钟切换的毛刺问题与同步处理时钟切换最怕的就是毛刺。如果MUX的选择信号在时钟高电平期间翻转输出端可能产生一个窄脉冲这个窄脉冲会破坏扫描链状态甚至触发意外的捕获。解决办法是用时钟的下降沿来同步选择信号确保切换发生在时钟低电平期间。具体做法是把选择控制信号打两拍用目标时钟的下降沿触发再送到MUX的select端。这样即使控制信号本身有抖动MUX的切换点也始终落在时钟低电平窗口内。我在实际项目里见过因为省了这两级同步触发器导致硅上偶发扫描链数据错乱的案例排查了很久才定位到是切换毛刺。2.3 脉冲生成为什么不能直接放功能时钟有人会问既然Capture阶段要用高速时钟为什么不直接把功能时钟接到扫描链上原因是功能时钟在测试模式下可能不受控——它可能被Clock Gating关掉可能频率还没稳定也可能连续跑很多个周期导致多次捕获。OCC的脉冲发生器通过一个边沿检测加计数的逻辑精确控制只放出N个脉冲。N的值通常由测试向量或控制寄存器配置。对于TDF测试N2一个launch脉冲加一个capture脉冲对于某些PDF测试可能需要更复杂的脉冲序列。这个脉冲计数逻辑本身也要用高速时钟同步否则计数会出错。2.4 OCC的旁路与调试通路实际设计中OCC必须支持旁路模式。当芯片处于功能模式时OCC应该被完全旁路功能时钟直接通过不引入任何额外延迟或功耗。这通过Test Mode信号控制MUX实现。另外为了调试方便建议在OCC输出端加一个可观测的测试点这样在硅上调试时能直接看到捕获时钟的实际波形。注意OCC旁路路径的时序约束必须和功能路径一样严格。我见过因为旁路路径没做时序约束导致功能模式下建立时间违例的案例——测试逻辑反而拖累了功能性能。3. Clock Gating在At-Speed测试中的双面性3.1 Clock Gating为什么会让测试时钟消失Clock Gating是低功耗设计的标配通过在与门或锁存器上叠加使能信号在模块空闲时关掉时钟。但在At-Speed测试中它是个大麻烦如果某个模块的Clock Gating使能信号在测试模式下没有被正确控制捕获时钟就传不到这个模块的触发器上导致这些触发器捕获不到数据测试覆盖率出现黑洞。更隐蔽的问题是Clock Gating的使能信号本身可能来自功能逻辑。在测试模式下这些功能逻辑的状态是不确定的导致使能信号随机翻转时钟时有时无。这种间歇性失效在仿真中可能因为初始状态恰好正确而通过但硅上就暴露了。3.2 测试模式下的Clock Gating强制使能策略标准做法是在测试模式下强制打开所有Clock Gating。具体实现有两种一种是在Clock Gating单元的使能端加一个OR门Test Mode信号为高时强制使能另一种是直接用Test Mode信号旁路整个Clock Gating单元。第一种方法更常用因为它保留了Clock Gating单元的结构对功能模式影响小。但要注意强制使能的时机。如果在Shift阶段就强制打开可能导致移位过程中时钟不稳定正确的做法是在Capture阶段才强制使能Shift阶段仍然让Clock Gating按功能逻辑工作或者也强制打开但用慢速时钟。3.3 局部Clock Gating与OCC的协同大型芯片通常有多个时钟域每个域可能有自己的局部Clock Gating。OCC通常放在域入口控制整个域的捕获时钟。但域内部的局部Clock Gating如果没处理好OCC放出的脉冲到了局部就被截断了。解决办法是在OCC的Capture脉冲期间所有局部Clock Gating都必须处于使能状态。这要求Clock Gating的强制使能信号和OCC的Capture Enable信号同步。我通常会把Capture Enable信号扇出到所有Clock Gating单元确保脉冲期间时钟畅通。3.4 实测中Clock Gating引发的典型失效分享一个真实案例某芯片At-Speed测试在仿真中覆盖率99.2%但硅上测试良率只有70%左右。排查发现是一个DSP模块的Clock Gating使能信号来自一个配置寄存器而该寄存器在测试模式下没有被正确初始化导致使能信号随机。修复方法是在测试模式下用Test Mode信号强制使能该Clock Gating良率立刻回到95%以上。这个案例的教训是不要假设仿真通过就万事大吉。仿真中的初始状态往往是确定性的而硅上上电状态是随机的。所有Clock Gating的使能来源都要在测试模式下有确定的状态。4. 复位策略被低估的At-Speed测试关键环节4.1 测试复位与功能复位的差异复位在At-Speed测试中的角色经常被低估。功能模式下复位信号由复位控制器管理有明确的释放顺序和同步处理。但测试模式下复位信号可能来自ATE时序和功能模式完全不同。关键差异在于测试复位必须在扫描移位之前完成并且在Capture阶段保持释放状态。如果复位在Capture期间意外有效触发器会被强制复位捕获结果全错。更麻烦的是有些复位信号是异步的释放时如果不在时钟边沿附近可能引发亚稳态。4.2 复位释放与时钟启动的顺序问题这是At-Speed测试中最容易踩的坑之一复位释放和时钟启动的先后顺序。正确的顺序应该是先释放复位让触发器进入可操作状态再启动捕获时钟。如果顺序反了时钟先到而复位还没释放触发器处于复位状态捕获不到数据。但先释放复位也有讲究复位释放必须同步到捕获时钟域否则异步释放可能在不同触发器上产生不同的释放时刻导致部分触发器先进入工作状态、部分还在复位捕获结果不一致。标准做法是用复位同步器把异步复位释放同步到目标时钟域。4.3 多时钟域下的复位协调多时钟域芯片的复位协调更复杂。每个时钟域可能有独立的复位信号OCC也可能每个域一个。如果各域的复位释放和时钟启动没有协调好跨时钟域路径上的数据就会出错。我的经验是在测试模式下用一个全局的Test Reset信号统一控制所有域的复位释放并且这个释放信号要同步到每个域各自的捕获时钟。同时OCC的Capture Enable要在所有域复位释放完成后才有效。这需要在测试控制逻辑里做一个简单的握手或延时。4.4 复位路径上的DFT插入注意事项在复位路径上插入DFT逻辑时要特别小心。比如为了可控性在复位线上加MUX这个MUX的选择信号必须稳定否则复位可能随机有效。另外复位树的平衡也很重要——如果复位到不同触发器的延迟差异太大释放时刻不一致的问题会更严重。提示建议在复位路径的DFT插入点做专门的时序分析确保测试模式下复位释放的偏斜skew在可接受范围内。我通常会把复位释放路径的skew控制在捕获时钟周期的5%以内。5. 从仿真到硅上的排查链路一个完整的调试案例5.1 问题现象仿真通过、硅上随机失效某次流片回来At-Speed测试的失效图案非常奇怪同一颗芯片有时通过有时失败不同芯片的失效位置还不一样。低速Scan Test完全正常功能测试也正常唯独At-Speed测试良率只有60%左右。这种随机性通常指向时序或同步问题而不是固定的逻辑缺陷。5.2 第一步排查确认OCC时钟切换是否干净首先用示波器探测OCC输出的捕获时钟。发现切换瞬间有窄毛刺宽度大约几百皮秒。虽然这个毛刺在大多数情况下不会触发触发器因为宽度小于建立保持窗口但在某些工艺角下可能刚好落在敏感区域。这解释了为什么失效是随机的。根因是OCC的MUX选择信号同步级数不够只打了一拍。修复方案是增加到两拍同步并且用下降沿触发。改版后毛刺消失。5.3 第二步排查Clock Gating使能的确定性毛刺修复后良率提升到80%但仍有失效。继续排查Clock Gating。发现有一个模块的Clock Gating使能来自一个上电复位值为X的寄存器仿真中初始化为0但硅上上电值不确定。在测试模式下如果该寄存器上电为1Clock Gating被关掉该模块的触发器捕获不到数据。修复方法是在测试模式下用Test Mode信号强制使能这个Clock Gating。同时把所有测试模式下状态不确定的寄存器都做类似处理。良率提升到92%。5.4 第三步排查复位释放的同步性还剩8%的失效。这次把注意力转向复位。用片上调试逻辑抓取复位释放和捕获时钟的相对时序发现复位释放信号没有同步到捕获时钟域导致在不同工艺角下释放时刻漂移有时落在时钟边沿附近引发亚稳态。修复方案是增加复位同步器把复位释放同步到每个时钟域的捕获时钟。同时调整OCC的Capture Enable确保它在复位释放完成后至少两个时钟周期才有效。最终良率稳定在97%以上。5.5 排查链路总结与可复用的检查清单这个案例的排查顺序可以复用到类似问题排查步骤检查内容常见问题修复手段1OCC输出时钟波形切换毛刺、脉冲数错误增加同步级数、检查脉冲计数逻辑2Clock Gating使能状态测试模式下使能不确定Test Mode强制使能3复位释放时序未同步、释放顺序错误增加复位同步器、调整释放顺序4跨时钟域路径握手信号未同步增加跨时钟域同步逻辑注意这个排查顺序是从最可能且最容易检查到最隐蔽排列的。实际调试时不要跳步每一步都要用波形或调试逻辑确认而不是靠猜。6. 写给正在推进At-Speed测试的工程师几条硬核经验6.1 测试控制逻辑的时序约束不能省很多团队在DFT插入时只关注扫描链本身的时序忽略了测试控制逻辑OCC选择信号、Capture Enable、复位同步等的时序约束。这些信号虽然不在功能路径上但它们的时序直接决定测试能否正常工作。我的做法是把所有测试控制信号都当作功能关键信号来做时序约束和分析该加的时序例外false path、multicycle path要仔细确认不能随手加。6.2 仿真激励要覆盖工艺角和上电不确定性仿真通过不代表硅上通过。仿真时要注意用多个工艺角跑At-Speed测试向量并且在仿真中引入上电状态的不确定性比如把未初始化寄存器的初始值设为X观察是否有X传播到测试控制路径。如果仿真中X传播导致覆盖率下降说明测试控制逻辑有确定性问题必须在流片前修复。6.3 片上调试逻辑是硅上排查的生命线硅上调试时如果没有片上调试逻辑你只能看到测试失败这个结果无法定位原因。建议在DFT设计阶段就规划好调试通路OCC输出时钟的可观测点、关键测试控制信号的状态寄存器、复位释放的时序捕获逻辑。这些逻辑面积开销很小但调试价值巨大。6.4 与ATE程序的协同时钟频率和脉冲数的匹配At-Speed测试的时钟频率和脉冲数需要和ATE程序精确匹配。ATE提供的参考时钟频率、OCC的分频比、脉冲计数器的配置三者必须一致。我见过因为ATE程序里脉冲数配错配了3个而不是2个导致捕获结果被覆盖的案例。建议在ATE程序开发时用仿真波形作为golden reference逐项核对。6.5 版本迭代中的回归测试策略每次DFT逻辑或测试控制逻辑有改动都要重新跑完整的At-Speed回归测试包括多工艺角仿真和硅上验证如果有工程样片。不要因为只改了一点点就跳过回归。我吃过这个亏改了一个Clock Gating的强制使能逻辑觉得影响很小结果引入了新的复位时序问题硅上良率掉了10个百分点。7. 关于Shared Bus DFT和PVT IP DFT的延伸思考7.1 Shared Bus DFT对OCC提出的新要求现在很多SoC采用共享总线架构多个模块通过总线互连。在At-Speed测试中如果多个模块共享同一个OCC捕获脉冲会同时到达所有模块。这本身没问题但如果某些模块在测试模式下应该被隔离比如模拟IP就需要额外的门控逻辑。我的做法是为共享总线的每个分支加独立的Capture Enable门控这样可以在OCC放出脉冲的同时选择性地只让目标模块接收时钟。这增加了控制复杂度但提高了测试灵活性。7.2 PVT IP DFT设计的特殊考量PVTProcess-Voltage-Temperature监控IP通常有自己的时钟和复位在At-Speed测试中需要特别处理。这些IP的测试模式可能和主芯片不同OCC需要为它们提供独立的捕获时钟路径。另外PVT IP的复位释放时机可能影响其输出数据的有效性需要和主芯片的捕获窗口对齐。7.3 DFT计算智能体的潜在应用最近行业内开始讨论用智能体辅助DFT计算比如自动生成测试向量、自动优化OCC配置。从我的实践角度看这类工具在向量生成和覆盖率分析上确实能提效但在测试控制逻辑的时序调试上目前还替代不了人工经验。测试控制逻辑的问题往往需要结合波形、工艺角和硅上数据综合判断这是智能体短期内难以完全胜任的。不过用智能体做初步的日志分析和异常检测可以帮工程师快速缩小排查范围这是值得尝试的方向。8. 我个人在At-Speed测试上踩过的几个坑第一个坑是OCC脉冲计数器的复位值。有一次流片回来发现Capture阶段放了0个脉冲排查发现脉冲计数器的复位值配错了导致计数器一开始就处于已完成状态。这个错误在仿真中因为复位值被正确初始化而没暴露。教训是所有测试控制寄存器的复位值都要在测试模式下有明确定义不能依赖仿真初始化。第二个坑是Clock Gating的使能信号在Shift阶段被强制打开导致移位过程中时钟不稳定扫描链数据出错。正确的做法是Shift阶段让Clock Gating按功能逻辑工作或者用慢速时钟强制打开Capture阶段才强制使能。这个细节在文档里往往不会写但实际项目中很容易踩。第三个坑是复位释放和OCC Capture Enable的握手缺失。早期设计里Capture Enable直接由Test Mode信号驱动没有等复位释放完成。结果在某些工艺角下Capture Enable有效时复位还没释放捕获结果全错。后来加了一个简单的状态机确保复位释放完成后才发Capture Enable问题解决。这些坑的共同点是它们都不是功能逻辑的错误而是测试控制逻辑的时序和状态问题。这也是At-Speed测试比Scan Test难做的根本原因——它要求测试逻辑本身在高速下正确工作而测试逻辑往往不在功能验证的覆盖范围内。所以如果你正在推进At-Speed测试我的建议是把测试控制逻辑当作一个独立的功能模块来验证给它写专门的验证用例覆盖各种工艺角和上电状态。这样虽然前期多花一些时间但能避免硅上调试时那种明明仿真都过了为什么硅上不行的痛苦。