1. 从Scan Test到At-Speed Test的DFT演进逻辑
1.1 为什么Scan Test只是起点
做DFT这行的朋友都有一个共识：Scan Test能跑通，不代表芯片能在真实频率下工作。我刚开始接触DFT的时候，也觉得把scan chain串起来、pattern生成出来、覆盖率推到99%以上就万事大吉了。后来才发现，这只是万里长征第一步。
Scan Test的本质是把时序电路在测试模式下改造成近似组合电路，通过扫描链把内部触发器的状态串行移入移出，用ATP工具生成固定型故障（Stuck-at）的测试向量。它的工作频率通常远低于芯片的功能频率，一般在10MHz到50MHz之间，目的是保证信号有充足的建立时间和保持时间余量，让测试结果不受时序路径延迟的影响。
但问题来了：一颗芯片在10MHz下能正常工作，不代表它在1GHz下也能正常工作。那些因为线延迟、串扰、工艺偏差导致的时序缺陷，在低频测试中根本暴露不出来。这就是At-Speed Test要解决的核心问题。
1.2 At-Speed Test到底在测什么
At-Speed Test，顾名思义，就是在芯片的功能频率下进行测试。它主要捕捉的是延迟故障（Transition Delay Fault）和路径延迟故障（Path Delay Fault）。简单说，就是看信号在规定的时钟周期内能不能从输入端传播到输出端。
我习惯用一个类比来解释：Scan Test像是检查每条路是否连通，At-Speed Test则是检查你能否在限定时间内从A点开到B点。路通了不代表不堵车，堵车了也不代表路断了，两者互补。
At-Speed Test的实现方式主要有两种：Launch-off-Shift（LOS）和Launch-off-Capture（LOC）。LOS是在shift过程中最后一个时钟脉冲作为launch时钟，LOC则是在capture周期中产生launch脉冲。两者各有优劣，LOS的pattern数量少但可能引入额外的IR drop问题，LOC的pattern质量更高但生成复杂度更大。
1.3 从低频到高频，DFT工程师面临的三大拦路虎
从Scan Test过渡到At-Speed Test，不是简单地把时钟频率调高就行。实际项目中，我踩过的坑主要集中在三个方面：
第一，时钟域切换问题。功能模式下芯片有多个时钟域，PLL、分频器、时钟门控各司其职。测试模式下，ATE设备提供的时钟和芯片内部PLL产生的时钟需要无缝切换，切换过程中不能产生毛刺，否则触发器会误触发。
第二，Clock Gating的干扰。低功耗设计中大量使用clock gating来关闭空闲模块的时钟，但测试模式下如果clock gating没有正确旁路，capture阶段时钟可能被关掉，导致测试失效。
第三，复位信号的时序。复位信号在功能模式下有严格的时序要求，测试模式下如果复位释放时机不对，可能把扫描链中的状态冲掉，或者导致X态传播。
这三个问题，正好对应了标题中的OCC、Clock Gating和复位。下面我逐一拆解。
2. OCC：At-Speed Test的心脏
2.1 OCC是什么，为什么非它不可
OCC全称On-Chip Clock Controller，片上时钟控制器。它是At-Speed Test的核心模块，负责在测试模式下产生精确的launch和capture时钟脉冲。
为什么不能直接用ATE的时钟？因为ATE的时钟经过PCB走线、封装引脚、芯片pad之后，skew和jitter都很大，而且ATE无法精确控制脉冲的宽度和相位关系。OCC在芯片内部，靠近被测逻辑，能产生干净、精确的时钟脉冲。
我通常把OCC比作一个“时钟脉冲发生器”：它接收一个自由运行的参考时钟（通常来自PLL或ATE），然后根据scan enable信号和pattern要求，在正确的时刻产生一个或多个脉冲。
2.2 OCC的内部结构拆解
一个典型的OCC包含以下几个关键部分：
- 时钟选择器（Clock Mux）：在功能时钟和测试时钟之间切换。功能模式下选PLL输出，测试模式下选ATE时钟或PLL旁路时钟。
- 脉冲发生器（Pulse Generator）：根据scan enable和clock enable信号，产生launch和capture脉冲。通常用负沿触发的触发器实现，保证脉冲宽度等于参考时钟的半个周期。
- 时钟门控单元（Clock Gate）：在非测试窗口关闭时钟，降低功耗，同时防止毛刺传播。
- 同步器（Synchronizer）：把scan enable等控制信号同步到时钟域，避免亚稳态。
实际设计中，OCC的复杂度取决于芯片的时钟域数量和测试模式数量。我做过的一个多核SoC项目，有8个时钟域，每个域一个OCC，OCC之间还有握手信号，确保跨时钟域的测试pattern能正确同步。
2.3 OCC配置的实操要点
配置OCC时，有几个参数必须仔细核对：
| 参数 | 说明 | 典型值 | 注意事项 |
|---|---|---|---|
| 参考时钟频率 | OCC输入的基准时钟 | 与功能时钟同频或分频 | 不能超过OCC内部触发器的最大频率 |
| Launch脉冲宽度 | launch时钟的高电平时间 | 半个参考周期 | 太窄会导致触发器建立时间不足 |
| Capture脉冲宽度 | capture时钟的高电平时间 | 半个参考周期 | 太宽会增加IR drop |
| Scan enable同步级数 | 同步器链长度 | 2-3级 | 太少亚稳态风险，太多延迟大 |
| 时钟门控使能 | 测试模式下是否旁路clock gating | 必须旁路 | 否则capture时钟可能被关掉 |
注意：OCC的参考时钟必须来自一个稳定的源。如果直接用ATE时钟，要确保ATE的jitter在OCC的容忍范围内。我遇到过ATE时钟jitter过大导致capture脉冲宽度抖动，最终测试良率偏低的情况。
2.4 OCC与Scan Chain的配合
OCC不是孤立工作的，它和scan chain的配合非常紧密。在shift阶段，OCC输出连续的shift时钟，频率通常较低（10-50MHz），保证scan chain能正确移入移出。在capture阶段，OCC输出一个或两个高频脉冲，频率等于功能频率。
这里有一个关键点：shift时钟和capture时钟的切换必须在scan enable的控制下无缝完成。如果切换时产生毛刺，scan chain中的状态可能被破坏。我通常会在OCC输出端加一个glitch-free的clock mux，确保切换时输出时钟保持低电平。
另外，OCC的scan enable信号本身也需要同步。如果scan enable是异步信号，直接送到OCC会导致亚稳态。我的做法是用两级触发器同步，同步时钟用参考时钟，这样scan enable的跳变总是发生在时钟的低电平期间。
3. Clock Gating：低功耗设计的双刃剑
3.1 Clock Gating在功能模式下的价值
Clock Gating是低功耗设计中最常用的技术之一。原理很简单：当一个模块不工作时，把它的时钟关掉，动态功耗直接降为零。一个典型的SoC中，可能有上百个clock gating单元，覆盖CPU、GPU、DSP、外设等各个模块。
Clock gating的实现方式主要有两种：基于锁存器的clock gating（Latch-based）和基于触发器的clock gating（FF-based）。Latch-based更常用，因为它在时钟低电平时锁存使能信号，避免毛刺。
从DFT的角度看，clock gating带来的问题是：测试模式下，如果clock gating没有被正确控制，capture时钟可能被关掉，导致测试pattern失效。
3.2 测试模式下Clock Gating的旁路策略
解决clock gating干扰的标准做法是：在测试模式下，用一个全局的test enable信号强制打开所有clock gating。具体实现有两种：
第一种，在clock gating单元的使能端加一个OR门，test enable为高时强制使能。这种方案简单，但会增加功能路径的延迟。
第二种，用专门的测试时钟树，测试模式下切换到测试时钟，完全绕过clock gating。这种方案对功能时序无影响，但面积开销大。
我通常根据模块的关键程度选择：CPU、GPU等高频模块用第二种，外设等低频模块用第一种。
这里有一个容易忽略的细节：clock gating的使能信号本身可能来自一个触发器，这个触发器在scan chain中。如果测试模式下这个触发器的状态是X，clock gating的行为就不确定。所以，必须确保所有控制clock gating的触发器在测试模式下有确定值，通常通过scan chain预加载。
3.3 Clock Gating对At-Speed Test的特殊影响
在At-Speed Test中，clock gating的影响比Scan Test更大。因为capture阶段只有一两个时钟脉冲，如果clock gating在capture期间关掉了时钟，整个测试就白做了。
我遇到过一种情况：一个模块的clock gating使能信号来自一个跨时钟域的握手逻辑，测试模式下握手逻辑没有正确初始化，导致clock gating在capture阶段随机开关。解决方案是在测试模式下用test enable强制使能，同时把握手逻辑的触发器预加载到确定状态。
另一个坑是clock gating的锁存器在scan shift期间可能透明。如果锁存器的使能信号在shift期间翻转，锁存器输出可能变化，导致clock gating输出毛刺。我的做法是在shift期间强制关闭所有clock gating，capture期间再打开。
3.4 实操中的Clock Gating检查清单
在tapeout前，我通常会跑一遍以下检查：
- 所有clock gating单元在测试模式下是否被正确旁路？
- 控制clock gating的触发器是否都在scan chain中？
- 这些触发器的测试模式初始值是否确定？
- clock gating的输出在shift期间是否稳定？
- capture期间clock gating是否全部使能？
- 跨时钟域的clock gating控制逻辑是否同步？
提示：可以用DFT DRC工具自动检查clock gating的测试可控性，但工具报告中的warning不能忽略，每一条都要人工确认。
4. 复位信号：最容易被忽视的DFT隐患
4.1 复位在测试模式下的双重角色
复位信号在DFT中有两个作用：初始化和隔离。初始化是指把触发器复位到确定状态，避免X态传播。隔离是指把不相关的逻辑复位，防止它们干扰测试。
但复位本身也可能成为问题。如果复位在capture阶段意外释放或断言，扫描链中的状态可能被冲掉，或者组合逻辑的输出被强制到固定值，导致测试失效。
我见过最典型的问题是：复位信号是异步的，测试模式下没有正确同步。异步复位在释放时如果靠近时钟沿，可能产生亚稳态，导致触发器输出不确定。
4.2 测试模式下的复位策略
我的经验是：测试模式下，复位信号应该由ATE或测试控制器直接控制，而不是由芯片内部的复位逻辑控制。具体做法是：
- 在复位路径上加一个mux，测试模式下选择test reset。
- test reset在shift期间保持断言，把所有触发器复位到确定状态。
- capture期间释放test reset，让触发器正常工作。
- 释放test reset的时机必须在capture时钟之前，且满足复位恢复时间。
对于异步复位，还需要在复位释放路径上加同步器，把异步复位同步到测试时钟域。同步器的级数通常是2级，时钟用capture时钟。
4.3 复位与OCC的交互
复位和OCC的交互是一个容易出问题的点。OCC内部有触发器，这些触发器也需要复位。如果OCC的复位和被测逻辑的复位不同步，可能导致OCC输出错误的时钟脉冲。
我的做法是：OCC的复位和被测逻辑的复位用同一个test reset信号，确保它们同时释放。同时，OCC内部的复位路径要满足时序要求，避免复位释放时产生亚稳态。
另外，OCC的scan enable信号在复位期间应该保持低电平，防止OCC在复位释放时产生毛刺。
4.4 复位检查的实操经验
在DFT DRC阶段，我通常会检查以下内容：
| 检查项 | 目的 | 常见问题 |
|---|---|---|
| 复位是否可控 | 测试模式下能否强制复位 | 复位来自内部逻辑，测试模式不可控 |
| 复位是否可观测 | 能否观察到复位状态 | 复位没有引出到pad |
| 复位释放时序 | 释放是否满足恢复时间 | 释放靠近时钟沿，亚稳态 |
| 复位同步 | 异步复位是否同步 | 没有同步器，亚稳态传播 |
| 复位与时钟关系 | 复位释放是否在时钟低电平 | 释放时时钟高电平，触发器误触发 |
注意：复位检查不能只看RTL，还要看综合后的网表。综合工具可能对复位路径做优化，改变复位的行为。
5. At-Speed Test的完整实操流程
5.1 测试模式定义与配置
At-Speed Test通常需要定义多个测试模式，每个模式对应不同的时钟配置和复位状态。我一般会定义以下模式：
- Shift模式：scan enable为高，时钟为低频shift时钟，复位断言。
- Capture模式（LOC）：scan enable为低，OCC产生launch和capture脉冲，复位释放。
- Capture模式（LOS）：scan enable在最后一个shift脉冲后拉低，OCC产生capture脉冲。
每个模式都需要在DFT控制器中配置相应的寄存器，控制时钟选择、复位释放、OCC使能等。
5.2 Pattern生成与仿真
Pattern生成用ATP工具（如TetraMAX、Modus等），需要提供以下输入：
- 综合后的网表
- DFT DRC报告
- OCC的行为模型
- 时钟定义和时序约束
- 故障模型（TDF或PDF）
生成Pattern后，必须做门级仿真，验证Pattern在真实时序下能正确捕获故障。仿真时要用SDF文件反标延迟，确保时序准确。
我通常会用一个小规模的测试用例先跑通流程，再扩展到全芯片。这样能快速定位问题，避免在大规模Pattern上浪费时间。
5.3 ATE调试与良率分析
Pattern生成和仿真通过后，就要上ATE调试。这一步是最考验经验的。常见的问题包括：
- 时钟频率不匹配：ATE提供的时钟频率和OCC期望的不一致，导致capture脉冲宽度错误。
- 复位释放时机不对：复位释放太早或太晚，导致触发器状态错误。
- 电源噪声：At-Speed Test时功耗大，电源噪声可能导致时序失效。
- 测试顺序影响：前一个测试的残留状态影响后一个测试。
我的调试策略是：先用低频跑通功能，再逐步提高频率，观察良率变化。如果良率在某个频率点突然下降，说明存在时序临界路径，需要进一步分析。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| Shift阶段数据错误 | scan chain断开或时钟毛刺 | 检查scan chain连通性，观察shift时钟 | 修复scan chain，加glitch-free mux |
| Capture阶段无脉冲 | OCC未使能或clock gating未旁路 | 检查OCC配置和test enable | 正确配置OCC，强制旁路clock gating |
| 良率随频率下降 | 时序临界路径 | 做shmoo plot，定位失效频率 | 优化时序，或降低测试频率 |
| 复位后状态错误 | 复位释放时序不对 | 检查复位释放与时钟关系 | 调整复位释放时机，加同步器 |
| X态传播 | 未初始化触发器 | 检查scan chain覆盖率和复位覆盖 | 增加复位，预加载触发器 |
| 功耗过大 | At-Speed Test同时翻转触发器多 | 检查pattern的翻转率 | 优化pattern，分组测试 |
6. 从项目实战中积累的DFT经验
6.1 早期介入，别等RTL冻结才动手
我最大的教训是：DFT不是后端的事，必须从架构阶段就介入。OCC的数量和位置、clock gating的策略、复位方案，这些在RTL阶段就要确定。等到RTL冻结再改，成本高、风险大。
具体来说，架构阶段要确定：
- 芯片有几个时钟域，每个域是否需要独立的OCC。
- clock gating的粒度，哪些模块需要独立门控。
- 复位策略，同步复位还是异步复位，测试模式下如何控制。
- scan chain的数量和长度，如何平衡shift时间和pattern数量。
6.2 DFT DRC必须零容忍
DFT DRC报告中的每一条warning都要认真对待。我见过太多项目因为忽略了一条warning，导致tapeout后测试失败，不得不做metal fix，损失几百万。
常见的DRC问题包括：
- 时钟不可控
- 复位不可控
- 异步接口未同步
- 三态总线冲突
- 黑盒未处理
我的做法是：DRC报告逐条确认，能修的就修，不能修的要有明确的理由和风险分析。
6.3 Pattern质量比数量重要
ATP工具生成的Pattern数量可能很多，但质量参差不齐。我通常会做以下优化：
- 合并相同故障模型的Pattern
- 删除冗余Pattern
- 对关键路径增加专项Pattern
- 用压缩技术减少Pattern数量
Pattern数量少，测试时间短，成本低。但前提是覆盖率不能降。
6.4 和ATE工程师紧密配合
DFT工程师和ATE工程师的配合至关重要。DFT工程师懂芯片内部，ATE工程师懂测试设备。双方要一起定义测试流程、调试测试程序、分析良率数据。
我通常会邀请ATE工程师参与DFT架构评审，让他们提前了解芯片的测试需求。同时，我也会去ATE实验室，亲自看测试过程，了解实际限制。
6.5 持续学习，跟上工具和工艺的演进
DFT领域变化很快。新工艺节点带来新的故障模型，新工具提供新的测试方法。我每年都会花时间学习新的DFT技术，比如：
- 针对FinFET工艺的故障模型
- 机器学习辅助的Pattern生成
- 3D IC的测试方法
- 汽车电子的功能安全测试
这个领域没有一劳永逸，只有持续学习。
最后分享一个我常用的调试技巧：当At-Speed Test失败时，先不要急着改Pattern或调时序。先用低频跑一遍，确认功能正确。然后逐步提高频率，找到失效的临界点。再用波形观察失效路径上的信号，看是建立时间问题还是保持时间问题。建立时间问题通常是路径延迟太大，保持时间问题通常是时钟skew太大。定位到具体原因，解决起来就快了。
