尧图网页设计 
SOC流片前的DFT收敛本质上是一场“测试时序”的博弈。我前后带过好几个量产项目最深的体会就是如果只是在RTL里插个扫描链、跑一遍ATPG就觉得完事那后面等你的大概率是一连串的捕获窗口违例、过渡故障覆盖率不达标、ATE上fail乱飞。真正要把测试这块做稳必须把DFT、OCC和ATPG这三件事放在同一条时间线上协同着设计。这篇文章来自一个实际项目的复盘。芯片是典型的多时钟域SOC内部有CPU簇、总线互联、各类外设IP逻辑规模在千万门级。我们最终采用的是标准扫描加transition test的full-chip DFT方案中间涉及OCCOn-Chip Clocking片上时钟控制的设计与验证以及和ATPGAutomatic Test Pattern Generation自动测试向量生成流程的反复对齐。写出来主要是想帮两类人一是做DFT、可测性设计或者芯片后端集成的工程师二是刚接触测试还不明白“为什么非要OCC”的新人。全文按项目推进顺序组织核心观点就一句话OCC不是ATPG流程里的一个可选项而是SOC能否实现高质量at-speed测试的地基。1. 项目到底在解决什么问题DFT、OCC、ATPG三者为什么会“打架”1.1 从fault report倒推DFT不只是“事后补救”很多人把DFT理解成“给芯片插几根扫描链”这其实窄了。DFT的全称是Design for Testability它是一整套让芯片变得可测试、可诊断、可量产的设计方法。扫描链只是最基础的手段真正复杂的是如何让扫描链在测试模式下按照想要的时序工作。项目里我们吃过一次亏。早期版本在某个IP上只做了stuck-at测试覆盖率虽然过了90%但流片后跑过渡故障transition delay fault测试时fail率明显偏高。后来定位发现是数据路径上的长组合逻辑在功能频率下传播时间不够而stuck-at测试根本测不出这种“速度”相关的缺陷。所以SOC量产测试必然要上at-speed测试也就是在接近功能频率的时钟下捕获信号跳变。这时候问题就来了扫描移位需要低速时钟捕获需要高速时钟两者之间谁来切换切换得干不干净这就是OCC的职责。1.2 OCC负责在测试模式中“切换时间尺度”OCC本质上是一个位于功能时钟路径上的时钟控制模块它接收来自PLL或其他时钟源的功能时钟也接收低速测试时钟然后根据测试控制信号决定输出哪个时钟、输出几个沿、什么时候停。最常见的用法是扫描移相位用test_clkSE信号拉低进入捕获相位后OCC输出两个功能时钟沿第一个沿叫launch第二个沿叫capture两个沿之间的时间间隔等于功能时钟周期从而模拟真实工作频率下的数据传输。没有OCC会出现什么情况如果捕获还是用低速test_clk过渡故障的检测窗口被拉长很多在功能频率下会暴露的缺陷在低速下根本测不出来如果直接用功能时钟做捕获又没法准确控制脉冲数量时钟一旦多跑了几个沿捕获的数据就不是预期的状态测试结果直接废。OCC就是那个“可控的闸门”它保证在正确的时刻放出正确数量的高速沿。1.3 ATPG把故障变成一串0/1的调度器ATPG工具做的事情可以概括为两件一是基于网表和故障模型计算出能够检测故障的测试向量二是把这些向量按照测试通道和扫描链的映射关系打包成可执行的pattern。在SOC芯片里ATPG的输出通常包含stuck-at pattern和transition pattern两类。transition pattern的生成逻辑和stuck-at完全不同。它需要先给定一个初始状态launch再观察一个相邻状态capture两个状态之间的信号变化必须跨越一个功能时钟周期。为了做到这一点ATPG工具必须知道OCC在捕获阶段到底会输出几个时钟沿、第一个沿和第二个沿之间间隔多少时间否则工具算出来的测试向量在硅片上执行时根本对不上时间窗口。这就是为什么OCC和ATPG必须协同OCC是物理层的时间控制ATPG是逻辑层的向量计算两边对“什么时候launch、什么时候capture”的理解必须完全一致。1.4 为什么必须“协同优化”回到项目里我们第一天写DFT plan时就把OCC、ATPG和DFT放到了一个大的约束体系里而不是各自独立跑完再合。这么做的好处非常直接时钟域的划分和OCC的插入位置在RTL阶段就确定ATPG阶段才不会出现“这个域没有OCC导致transition无法测试”的尴尬ATPG跑完后反馈的覆盖率数字又能反过来指导OCC是否需要调整。协同优化的本质是让“测试能力设计”和“测试向量生成”互相反馈形成闭环。如果拆开做典型的失败路径是这样DFT工程师插完OCC就交付后端做时钟树时对OCC路径缺少额外约束ATPG工程师拿到设计后跑覆盖率发现大量过渡故障测不到回头排查发现是OCC的输出时钟在STA里没有被正确建模最后只能通过禁掉一批路径换覆盖率测试质量打了折扣。所以协同不是口号而是要把OCC的约束条件同时渗透到DFT插桩、STA和ATPG三个流程里去。2. OCC架构与ATPG配合关系的核心设计细节2.1 一个典型OCC的内部逻辑拆解我们项目里用的OCC是基于时钟门控单元加计数器的结构逻辑并不复杂但每个部件都不能省。最核心的部分包括三块时钟选择MUX、捕获窗口计数器、同步与使能逻辑。时钟选择MUX决定当前是输出test_clk还是func_clk。扫描移位阶段必须选test_clk因为这个时钟来自测试引脚或者片上测试时钟源速度低、相位可控捕获阶段必须选func_clk因为要模拟正常工作频率。MUX的切换不能让时钟毛刺落到寄存器上所以需要一个比较讲究的切换窗口通常是在SE稳定后再切换而不是SE跳变的瞬间立刻切。捕获窗口计数器用于控制输出多少个功能时钟沿。transition测试需要两个沿stuck-at测试只需要一个沿部分诊断场景需要更多沿计数器的作用就是精确产生这些脉冲。实现时要注意计数器本身也是时序电路它的起始点应该以断言启动信号到达为准而不是以PLL时钟的随机相位为准否则会有亚稳态风险。我们加了一级两级同步器处理启动信号的跨时钟域问题代价是多了几个触发器但对稳定性帮助很大。OCC输出还要过一道时钟门控用专门的ICG单元而不是普通AND门来做原因是ICG有内置的latch可以保证时钟沿的完整性普通组合逻辑门很容易在时钟高电平期间引入毛刺。这个细节在后端实现时经常被忽略一旦OCC输出直接驱动扫描触发器组毛刺就会导致扫描数据被错误捕获。2.2 LOC和LOS捕获策略到底选哪个过渡故障测试有两种主流捕获策略launch-on-captureLOC和launch-on-shiftLOS。两者区别在于第一个launch沿的来源。LOC模式是SE拉低后由OCC输出的第一个功能时钟沿作为launch第二个功能时钟沿作为capture时序分布和功能模式接近对后端实现友好是SOC测试的主流选择。LOS模式是shift阶段的最后一拍时钟作为launch捕获阶段只输出一个capture沿优点是launch和capture之间的激励时间更短更容易测出路径延迟缺陷但它的时序模型和功能模式偏差较大对扫描移位路径的hold time要求苛刻后端收敛成本高。对比项LOCLOSlaunch沿来源捕获窗口第一个功能时钟沿扫描移位最后一个移位时钟沿与功能时序接近度高低OCC实现复杂度需要两个沿的精确控制只需要一个沿OCC更简单后端收敛难度相对低对hold要求极高适用场景常规SOC多时钟域高速内核或少量IP的局部测试我们的项目全部采用LOC。理由是SOC内部有大量跨时钟域路径和异步接口LOC模式下的时序更贴近真实功能场景ATPG工具对LOC路径的约束也更成熟。OCC在LOC模式下只需要保证从SE下降沿到第一个launch沿之间有一段可控间隔以及两个沿之间的周期严格等于功能时钟周期复杂度完全可控。2.3 时钟域分组与跨域处理的协同SOC芯片最麻烦的就是多个时钟域。我们的芯片有CPU集群使用的PLL时钟、外设总线的低频时钟、片上SRAM的独立时钟还有部分纯异步逻辑。如果每一个时钟域都独立插入OCC会带来很大的面积开销和时钟树压力但如果合在一个OCC下管理又无法保证不同频率时钟沿之间的同步关系。我们采取的方案是“同频同相分组异频异步隔离”。同频同相的时钟域共用一个OCCATPG工具把它们当作一个时钟组处理transition pattern跨这些域的路径能正常覆盖。异频异步的域之间则用disable timing边界约束在OCC和ATPG层面都不做跨域transition测试。跨域的路径如果确实存在就把它们归到stuck-at或旁路测试不给它们分配功能时钟捕获窗口。这个分组决策要在项目早期定最好是在DFT规划文档里把每个时钟域和OCC的映射关系明确画出来。后期改分组的成本非常高因为OCC插入位置、时钟树约束、ATPG clock group定义全都跟着变。2.4 给ATPG提供正确的时钟模型ATPG工具本身不知道OCC是怎么工作的它需要用户通过约束来告诉它哪些时钟是扫描移位时钟、哪些是捕获时钟、OCC输出在什么条件下有效。这个部分我们花了不少时间调试核心是三组约束时钟分组约束、OCC使能信号约束、测试模式定义。时钟分组要做到同一OCC域内的时钟被识别为一个groupATPG才会把它们当作同源时钟来计算捕获窗口。OCC使能信号要定义成测试可控制信号这样ATPG才能在pattern里编排“拉低SE、启动OCC、输出两个捕获沿”的时序。测试模式定义要区分shift模式和capture模式不同模式下时钟的mux选择不一样约束不完整时ATPG会认为某些路径不可测。有一次我们漏掉了某个IP内部OCC的使能信号约束ATPG跑完transition覆盖率比预期低了十几个点因为工具认定该IP域内所有捕获路径都无效。加上约束后覆盖率立刻回到正常水平。这个教训说明OCC和ATPG的协同重点不在工具本身而在约束的完整性和一致。3. SOC DFT OCC与ATPG协同的实操流程3.1 DFT规划阶段OCC数量和时钟域绑定进入实操环节第一步不是写代码是先把测试策略文档做厚。我们的项目在RTL freeze之前就完成了DFT plan的初版里面至少包含这几项扫描链总条数和压缩比例、每个功能时钟域对应的OCC实例、OCC使用哪个PLL作为捕获时钟源、哪些路径不进入transition测试、pattern类型和覆盖率目标。OCC数量并不是越多越好。我们的经验是每个独立PLL输出域至少一个OCC但对多个频率相近、相位可控的域尽量合并这样可以减少时钟树上的OCC数量也不用担心不同OCC之间的沿精度偏差。代价是合并后的域如果出现频率不匹配ATPG就只能按最慢的域来定捕获周期会削弱高频域的测试强度。所以这里是一个质量与面积的权衡需要在项目例会里反复确认。规划阶段还要确定每个OCC的PLL源和分频关系。ATPG计算launch-capture窗口时默认使用PLL输出的功能时钟频率。如果深睡状态下PLL被关断测试模式下要额外保证PLL处于有效状态或者提供备用的测试时钟电路。这个在低功耗SOC里尤其重要我们的芯片在实现时就把OCC的时钟源绑定到了常开的时钟网络防止低功耗模式把关键时钟误关。3.2 插OCC与DRC验证规划完成后进入代码实现。我们用DFT编译器工具把扫描链插入和OCC实例化放在同一个flow里处理。OCC通常是独立RTL模块预先写好参数化的时钟脉冲控制逻辑在插桩时按规划例化到对应的时钟域边界。插OCC并不是简单地把模块挂上时钟网络就结束重点在DRC验证。工具会检查几个方面OCC输入时钟是否来自合法的PLL或者测试时钟源输出时钟是否覆盖了该域所有需要at-speed测试的寄存器OCC的使能信号是否由测试控制器逻辑正确驱动以及时钟切换时是否存在组合逻辑毛刺路径。任何一个问题不通过都不能直接往后跑。我们遇到最多的DRC问题是OCC输出时钟穿过了一层组合逻辑后才驱动扫描触发器工具判定这不是合法的OCC输出负载直接报错。解决方式是把OCC输出连接到后端专用的时钟树单元或者把组合逻辑搬到OCC前面的选择分支里确保OCC到触发器之间只有时钟树buffer。这类问题早期不清理后端时钟树阶段代价翻倍。3.3 约束、STA与SDC处理OCC插入完成后STA环节必须加入专门的约束。OCC路径上有几个典型的时序窗口需要验证launch沿和capture沿之间的最小间隔、SE下降沿到launch沿的建立时间、capture沿之后OCC内部计数器恢复时间。这些约束在测试模式SDC里体现为test_clock和test_mode相关的设置。我们在后端做时钟树综合时给OCC的输入功能时钟路径做了0.5倍余量的setup约束。原因是OCC电路本身的门控逻辑会引入额外延时如果时钟树综合阶段不给余量流片后的Fmax会低于预期。实际项目中这个余量让我们避免了两次短期时序修不干净的问题虽然代价是时钟树多插了一些buffer但测试稳定性明显提升。STA还要验证OCC模式下跨时钟域路径的异步约束。对不参与transition测试的跨域路径在SDC里显式设置false path并且要在ATPG的约束文件里同步disable两边一旦不一致后端时序和测试向量就会互相对不上。3.4 从ATPG生成到动态仿真ATPG阶段是把前面的协同设计兑现成最终pattern的地方。我们使用的流程是读入带OCC和扫描结构的网表指定故障模型为transition设置时钟分组和OCC行为模型然后跑向量生成。生成完后先看覆盖率报告再逐条检查是否存在memory接口或者模拟宏的未知X状态干扰。Pattern生成只是起点真正的验证在动态仿真。我们会对生成的pattern做门级仿真在网表路径上反标SDF延迟模拟真实时序行为。仿真时重点观察OCC输出的时钟波形是否在预期的时间点产生两个功能沿SE信号拉低后是否在OCC启动窗口内保持稳定。任何一个环节出现仿真与ATPG预期不一致都要回到约束文件里排查。动态仿真还会暴露X态传播问题。测试向量的初始状态来自扫描加载但某些寄存器在测试模式下可能没有被完全初始化仿真时会出现X。ATPG工具通常会通过仿真X处理机制在向量前后插入初始化序列但如果OCC在某个域的使能信号也是X态捕获时钟就可能不产生导致覆盖率瞬间下降。仿真通过后pattern还要转换到ATE可用的格式我们这边统一用WGL格式输出再在机台上做电压和时钟频率的校准。这一步的细节和ATE资源强相关但前面的协同设计如果做得好得出的pattern在机台上基本不需要反复调试。3.5 测试时间的量化估算与优化协同优化最后要落到一个可以量化的指标测试时间。测试时间直接关系到量产的芯片成本而OCC和ATPG的协同设计能显著影响这个数字。测试时间的粗略公式是pattern总数 × 单条pattern的移位周期数捕获周期数。频率一定时影响时间的主要变量是扫描链长度和pattern数量。我们的芯片满规格扫描链长度约2000个扫描单元移位时钟定在30MHz单个transition pattern的移位周期数大约几千个乘以数千条pattern之后单颗芯片测试时间很容易突破几秒。想要缩测试时间可以通过提高压缩比、增加扫描通道、优化pattern顺序、降低重复覆盖率等办法。但这些优化和OCC设计有联动关系压缩比提高后单条链变长OCC的捕获窗口还是按功能频率执行不会改变捕获沿之间的时序但捕获后数据搬运时间会变长。所以我们在设计阶段就把“压缩比、链数、测试时间、覆盖率”四个指标放在一起推演宁可多花两周做权衡也不在流片后再返工。4. 实测过程中的问题实录与排查思路4.1 过渡故障覆盖率为什么卡在70%上不去项目进行到ATPG收敛阶段transition覆盖率连续几天卡在70%怎么加pattern都动不了。我们排查后定位到两个原因。第一个原因是某个IP内部有一个低频使能信号在功能模式下由软件配置寄存器控制但测试模式下这个寄存器没有被扫描替代导致该IP的OCC使能路径被截断ATPG认为相关路径不可测。解决办法是把该寄存器纳入扫描链并让OCC使能信号直接受测试控制器驱动覆盖随即恢复。第二个原因是跨电源域的信号在测试时钟下存在较长的传输延迟ATPG工具默认把它当功能路径处理反而造成大量时序冲突。我们在SDC和ATPG约束里同时把这个路径设成异步覆盖率立刻回到80%以上。这类问题很隐蔽因为报错信息不会直接说“OCC使能被截断”而是显示一个又一个“unable to generate pattern”的条目。三个人的排查经验是覆盖率上不去时第一优先看OCC使能信号和禁测路径名清单不要一开始就怀疑故障模型设置。4.2 OCC识别失败同样一个模块DFT工具就是找不到时钟另一个高频问题是工具识别不了OCC。现象是DRC报“no valid OCC clock”但我们明明已经把OCC模块挂好了。查下来通常有两个原因一是OCC的输入时钟名带上了功能时钟的分频信息工具需要用户在dft配置里显式指出时钟树主节点二是OCC的启动信号在工具视图里被识别成普通数据引脚没有被定义成test control信号。解决方式是回到dft_signal定义里逐个核对OCC的时钟输入、启动输入、输出时钟三类引脚是否都正确声明。这个工作很琐碎但是最值得提前做的。我们在新建一个IP的DFT约束时会直接套用一套固定模板再按IP差异修改而不是每次从零开始写避免漏定义导致的低级问题反复出现。4.3 动态仿真里的X态和“仿真没有沿”动态仿真阶段有段时间仿真波形里OCC输出时钟在某些pattern里完全不动作整个捕获窗口都是平的。我们最开始以为是RTL和网表不一致后来发现是仿真激励里没把PLL输出建模成自由运行时钟PLL的初始状态是XOCC等待X信号根本没有启动。解决办法是在pattern仿真的激励脚本里把OCC依赖的PLL输出在初始化阶段显式置为有效值不能依赖仿真器自动推断。类似的问题还出现在低功耗状态下某些时钟自动门控单元在仿真初期把功能时钟关掉了OCC自然拿不到时钟源。后来我们在测试激励模板里固定加一段“时钟初始化序列”先把所有PLL和时钟门控打开再执行OCC启动问题基本清零。4.4 后端时序和功耗的反复拉锯后端做时钟树时OCC路径是最容易引起时序超额的区域。因为OCC的输入是功能时钟输出又直接驱动大片扫描寄存器时钟树的负载和分支数量都很大。我们遇到过一次OCC路径的hold违例原因是OCC输出的时钟树和捕获寄存器之间的偏移过大修复方式是在OCC后端加了多级平衡buffer同时调整了扫描寄存器的布局密度让OCC的输出负载尽量均匀分布。功耗方面OCC在测试模式下的功能时钟会以capture频率开关测试功耗常常比功能模式高一大截。我们测试时发现动态仿真中某域瞬时功耗接近功能模式上限为了压低它把测试捕获频率从原来的最高PLL频率降到了0.7倍PLL频率虽然对缺陷检测的灵敏度有一点影响但避免了ATE上的供电风险。这是典型的协同优化取舍测试质量和功耗约束之间没有绝对最优只有项目约束下的平衡。5. 工具链选型、工程落地与个人体会5.1 我们实际使用的工具链组合项目里DFT插入和ATPG用的是不同的工具组合原因是它们在OCC处理方式上各有特点。前端DFT插桩和压缩用Synopsys的DFT CompilerATPG用TetraMAX后端时序分析用PrimeTime。这套组合在标准scan和transition测试上非常成熟OCC的库单元模型支持也比较完整。另一条值得研究的路线是Siemens的Tessent系列它在OSC信号级时钟控制和高压缩比scan压缩上做得比传统流程灵活尤其适合多时钟域和层次化实现的项目。我们评估过Tessent但最终因为团队对Synopsys的flow更熟切换成本高没有换。选型建议是团队原有skill set最重要工具本身功能差异在大多数项目里都能通过约束补齐熟练度才是真正的瓶颈。5.2 约束文件一致性是这个项目最大的工程难点协同优化光靠工具跑流程不够还要有一套能贯穿DFT、STA、ATPG三端的约束体系。我们在项目里维护了一份统一的测试时钟树配置文档里面记录每个OCC实例的时钟源、使能信号、输出时钟名、测试模式定义。任何一个环节改了OCC相关的约束文件同步更新并且有专门的脚本做三个工具之间的一致性检查。这份文档在项目中期发挥了很大作用。有一次后端工程师为了优化时序调整了OCC输入路径上的一个buf尺寸如果只改SDC不通知ATPGATPG里不会感知这个变化覆盖率报告看着没问题但流片后测试时序可能出现细微偏差。有了统一配置和自动检查这类问题的风险被提前拦截。5.3 团队协作建议把DFT当“一等公民”项目里最聪明的一个决定是把DFT工程师安排到了综合环境建设的初期评审里而不是等综合脚本跑完再加入。这样前端designer在选时钟方案时会主动考虑测试可行性后端在解决时序问题时也会把DFT模式的时序作为一个独立signoff项目而不是总当成“附加项”处理。跨团队开会时我会跟大家强调一个概念DFT不再只是加几条链而是从时钟规划开始就要考虑OCC的物理实现和ATPG的时序边界。谁提方案谁负责把约束同步给下游不让任何信息停留在口头层面。这在多人协作的SOC项目里效果非常明显。5.4 最后再分享一个小技巧项目尾声调试ATE pattern时花了很多时间对比TetraMAX仿真波形和机台波形。后来发现在TetraMAX里开启pattern compression并写入仿真时间戳信息能直接在ATE上快速定位第一次fail的pattern序号不用整条向量切成几万段逐段查。这个参数在项目初期容易被忽略但对量产调试效率帮助巨大。做SOC DFT流片验证的朋友建议在流程初期就把这个选项打开能省下后面几天熬夜时间。 DFT、OCC与ATPG协同：SOC流片前测试时序收敛的关键技术
SOC流片前的DFT收敛本质上是一场“测试时序”的博弈。我前后带过好几个量产项目最深的体会就是如果只是在RTL里插个扫描链、跑一遍ATPG就觉得完事那后面等你的大概率是一连串的捕获窗口违例、过渡故障覆盖率不达标、ATE上fail乱飞。真正要把测试这块做稳必须把DFT、OCC和ATPG这三件事放在同一条时间线上协同着设计。这篇文章来自一个实际项目的复盘。芯片是典型的多时钟域SOC内部有CPU簇、总线互联、各类外设IP逻辑规模在千万门级。我们最终采用的是标准扫描加transition test的full-chip DFT方案中间涉及OCCOn-Chip Clocking片上时钟控制的设计与验证以及和ATPGAutomatic Test Pattern Generation自动测试向量生成流程的反复对齐。写出来主要是想帮两类人一是做DFT、可测性设计或者芯片后端集成的工程师二是刚接触测试还不明白“为什么非要OCC”的新人。全文按项目推进顺序组织核心观点就一句话OCC不是ATPG流程里的一个可选项而是SOC能否实现高质量at-speed测试的地基。1. 项目到底在解决什么问题DFT、OCC、ATPG三者为什么会“打架”1.1 从fault report倒推DFT不只是“事后补救”很多人把DFT理解成“给芯片插几根扫描链”这其实窄了。DFT的全称是Design for Testability它是一整套让芯片变得可测试、可诊断、可量产的设计方法。扫描链只是最基础的手段真正复杂的是如何让扫描链在测试模式下按照想要的时序工作。项目里我们吃过一次亏。早期版本在某个IP上只做了stuck-at测试覆盖率虽然过了90%但流片后跑过渡故障transition delay fault测试时fail率明显偏高。后来定位发现是数据路径上的长组合逻辑在功能频率下传播时间不够而stuck-at测试根本测不出这种“速度”相关的缺陷。所以SOC量产测试必然要上at-speed测试也就是在接近功能频率的时钟下捕获信号跳变。这时候问题就来了扫描移位需要低速时钟捕获需要高速时钟两者之间谁来切换切换得干不干净这就是OCC的职责。1.2 OCC负责在测试模式中“切换时间尺度”OCC本质上是一个位于功能时钟路径上的时钟控制模块它接收来自PLL或其他时钟源的功能时钟也接收低速测试时钟然后根据测试控制信号决定输出哪个时钟、输出几个沿、什么时候停。最常见的用法是扫描移相位用test_clkSE信号拉低进入捕获相位后OCC输出两个功能时钟沿第一个沿叫launch第二个沿叫capture两个沿之间的时间间隔等于功能时钟周期从而模拟真实工作频率下的数据传输。没有OCC会出现什么情况如果捕获还是用低速test_clk过渡故障的检测窗口被拉长很多在功能频率下会暴露的缺陷在低速下根本测不出来如果直接用功能时钟做捕获又没法准确控制脉冲数量时钟一旦多跑了几个沿捕获的数据就不是预期的状态测试结果直接废。OCC就是那个“可控的闸门”它保证在正确的时刻放出正确数量的高速沿。1.3 ATPG把故障变成一串0/1的调度器ATPG工具做的事情可以概括为两件一是基于网表和故障模型计算出能够检测故障的测试向量二是把这些向量按照测试通道和扫描链的映射关系打包成可执行的pattern。在SOC芯片里ATPG的输出通常包含stuck-at pattern和transition pattern两类。transition pattern的生成逻辑和stuck-at完全不同。它需要先给定一个初始状态launch再观察一个相邻状态capture两个状态之间的信号变化必须跨越一个功能时钟周期。为了做到这一点ATPG工具必须知道OCC在捕获阶段到底会输出几个时钟沿、第一个沿和第二个沿之间间隔多少时间否则工具算出来的测试向量在硅片上执行时根本对不上时间窗口。这就是为什么OCC和ATPG必须协同OCC是物理层的时间控制ATPG是逻辑层的向量计算两边对“什么时候launch、什么时候capture”的理解必须完全一致。1.4 为什么必须“协同优化”回到项目里我们第一天写DFT plan时就把OCC、ATPG和DFT放到了一个大的约束体系里而不是各自独立跑完再合。这么做的好处非常直接时钟域的划分和OCC的插入位置在RTL阶段就确定ATPG阶段才不会出现“这个域没有OCC导致transition无法测试”的尴尬ATPG跑完后反馈的覆盖率数字又能反过来指导OCC是否需要调整。协同优化的本质是让“测试能力设计”和“测试向量生成”互相反馈形成闭环。如果拆开做典型的失败路径是这样DFT工程师插完OCC就交付后端做时钟树时对OCC路径缺少额外约束ATPG工程师拿到设计后跑覆盖率发现大量过渡故障测不到回头排查发现是OCC的输出时钟在STA里没有被正确建模最后只能通过禁掉一批路径换覆盖率测试质量打了折扣。所以协同不是口号而是要把OCC的约束条件同时渗透到DFT插桩、STA和ATPG三个流程里去。2. OCC架构与ATPG配合关系的核心设计细节2.1 一个典型OCC的内部逻辑拆解我们项目里用的OCC是基于时钟门控单元加计数器的结构逻辑并不复杂但每个部件都不能省。最核心的部分包括三块时钟选择MUX、捕获窗口计数器、同步与使能逻辑。时钟选择MUX决定当前是输出test_clk还是func_clk。扫描移位阶段必须选test_clk因为这个时钟来自测试引脚或者片上测试时钟源速度低、相位可控捕获阶段必须选func_clk因为要模拟正常工作频率。MUX的切换不能让时钟毛刺落到寄存器上所以需要一个比较讲究的切换窗口通常是在SE稳定后再切换而不是SE跳变的瞬间立刻切。捕获窗口计数器用于控制输出多少个功能时钟沿。transition测试需要两个沿stuck-at测试只需要一个沿部分诊断场景需要更多沿计数器的作用就是精确产生这些脉冲。实现时要注意计数器本身也是时序电路它的起始点应该以断言启动信号到达为准而不是以PLL时钟的随机相位为准否则会有亚稳态风险。我们加了一级两级同步器处理启动信号的跨时钟域问题代价是多了几个触发器但对稳定性帮助很大。OCC输出还要过一道时钟门控用专门的ICG单元而不是普通AND门来做原因是ICG有内置的latch可以保证时钟沿的完整性普通组合逻辑门很容易在时钟高电平期间引入毛刺。这个细节在后端实现时经常被忽略一旦OCC输出直接驱动扫描触发器组毛刺就会导致扫描数据被错误捕获。2.2 LOC和LOS捕获策略到底选哪个过渡故障测试有两种主流捕获策略launch-on-captureLOC和launch-on-shiftLOS。两者区别在于第一个launch沿的来源。LOC模式是SE拉低后由OCC输出的第一个功能时钟沿作为launch第二个功能时钟沿作为capture时序分布和功能模式接近对后端实现友好是SOC测试的主流选择。LOS模式是shift阶段的最后一拍时钟作为launch捕获阶段只输出一个capture沿优点是launch和capture之间的激励时间更短更容易测出路径延迟缺陷但它的时序模型和功能模式偏差较大对扫描移位路径的hold time要求苛刻后端收敛成本高。对比项LOCLOSlaunch沿来源捕获窗口第一个功能时钟沿扫描移位最后一个移位时钟沿与功能时序接近度高低OCC实现复杂度需要两个沿的精确控制只需要一个沿OCC更简单后端收敛难度相对低对hold要求极高适用场景常规SOC多时钟域高速内核或少量IP的局部测试我们的项目全部采用LOC。理由是SOC内部有大量跨时钟域路径和异步接口LOC模式下的时序更贴近真实功能场景ATPG工具对LOC路径的约束也更成熟。OCC在LOC模式下只需要保证从SE下降沿到第一个launch沿之间有一段可控间隔以及两个沿之间的周期严格等于功能时钟周期复杂度完全可控。2.3 时钟域分组与跨域处理的协同SOC芯片最麻烦的就是多个时钟域。我们的芯片有CPU集群使用的PLL时钟、外设总线的低频时钟、片上SRAM的独立时钟还有部分纯异步逻辑。如果每一个时钟域都独立插入OCC会带来很大的面积开销和时钟树压力但如果合在一个OCC下管理又无法保证不同频率时钟沿之间的同步关系。我们采取的方案是“同频同相分组异频异步隔离”。同频同相的时钟域共用一个OCCATPG工具把它们当作一个时钟组处理transition pattern跨这些域的路径能正常覆盖。异频异步的域之间则用disable timing边界约束在OCC和ATPG层面都不做跨域transition测试。跨域的路径如果确实存在就把它们归到stuck-at或旁路测试不给它们分配功能时钟捕获窗口。这个分组决策要在项目早期定最好是在DFT规划文档里把每个时钟域和OCC的映射关系明确画出来。后期改分组的成本非常高因为OCC插入位置、时钟树约束、ATPG clock group定义全都跟着变。2.4 给ATPG提供正确的时钟模型ATPG工具本身不知道OCC是怎么工作的它需要用户通过约束来告诉它哪些时钟是扫描移位时钟、哪些是捕获时钟、OCC输出在什么条件下有效。这个部分我们花了不少时间调试核心是三组约束时钟分组约束、OCC使能信号约束、测试模式定义。时钟分组要做到同一OCC域内的时钟被识别为一个groupATPG才会把它们当作同源时钟来计算捕获窗口。OCC使能信号要定义成测试可控制信号这样ATPG才能在pattern里编排“拉低SE、启动OCC、输出两个捕获沿”的时序。测试模式定义要区分shift模式和capture模式不同模式下时钟的mux选择不一样约束不完整时ATPG会认为某些路径不可测。有一次我们漏掉了某个IP内部OCC的使能信号约束ATPG跑完transition覆盖率比预期低了十几个点因为工具认定该IP域内所有捕获路径都无效。加上约束后覆盖率立刻回到正常水平。这个教训说明OCC和ATPG的协同重点不在工具本身而在约束的完整性和一致。3. SOC DFT OCC与ATPG协同的实操流程3.1 DFT规划阶段OCC数量和时钟域绑定进入实操环节第一步不是写代码是先把测试策略文档做厚。我们的项目在RTL freeze之前就完成了DFT plan的初版里面至少包含这几项扫描链总条数和压缩比例、每个功能时钟域对应的OCC实例、OCC使用哪个PLL作为捕获时钟源、哪些路径不进入transition测试、pattern类型和覆盖率目标。OCC数量并不是越多越好。我们的经验是每个独立PLL输出域至少一个OCC但对多个频率相近、相位可控的域尽量合并这样可以减少时钟树上的OCC数量也不用担心不同OCC之间的沿精度偏差。代价是合并后的域如果出现频率不匹配ATPG就只能按最慢的域来定捕获周期会削弱高频域的测试强度。所以这里是一个质量与面积的权衡需要在项目例会里反复确认。规划阶段还要确定每个OCC的PLL源和分频关系。ATPG计算launch-capture窗口时默认使用PLL输出的功能时钟频率。如果深睡状态下PLL被关断测试模式下要额外保证PLL处于有效状态或者提供备用的测试时钟电路。这个在低功耗SOC里尤其重要我们的芯片在实现时就把OCC的时钟源绑定到了常开的时钟网络防止低功耗模式把关键时钟误关。3.2 插OCC与DRC验证规划完成后进入代码实现。我们用DFT编译器工具把扫描链插入和OCC实例化放在同一个flow里处理。OCC通常是独立RTL模块预先写好参数化的时钟脉冲控制逻辑在插桩时按规划例化到对应的时钟域边界。插OCC并不是简单地把模块挂上时钟网络就结束重点在DRC验证。工具会检查几个方面OCC输入时钟是否来自合法的PLL或者测试时钟源输出时钟是否覆盖了该域所有需要at-speed测试的寄存器OCC的使能信号是否由测试控制器逻辑正确驱动以及时钟切换时是否存在组合逻辑毛刺路径。任何一个问题不通过都不能直接往后跑。我们遇到最多的DRC问题是OCC输出时钟穿过了一层组合逻辑后才驱动扫描触发器工具判定这不是合法的OCC输出负载直接报错。解决方式是把OCC输出连接到后端专用的时钟树单元或者把组合逻辑搬到OCC前面的选择分支里确保OCC到触发器之间只有时钟树buffer。这类问题早期不清理后端时钟树阶段代价翻倍。3.3 约束、STA与SDC处理OCC插入完成后STA环节必须加入专门的约束。OCC路径上有几个典型的时序窗口需要验证launch沿和capture沿之间的最小间隔、SE下降沿到launch沿的建立时间、capture沿之后OCC内部计数器恢复时间。这些约束在测试模式SDC里体现为test_clock和test_mode相关的设置。我们在后端做时钟树综合时给OCC的输入功能时钟路径做了0.5倍余量的setup约束。原因是OCC电路本身的门控逻辑会引入额外延时如果时钟树综合阶段不给余量流片后的Fmax会低于预期。实际项目中这个余量让我们避免了两次短期时序修不干净的问题虽然代价是时钟树多插了一些buffer但测试稳定性明显提升。STA还要验证OCC模式下跨时钟域路径的异步约束。对不参与transition测试的跨域路径在SDC里显式设置false path并且要在ATPG的约束文件里同步disable两边一旦不一致后端时序和测试向量就会互相对不上。3.4 从ATPG生成到动态仿真ATPG阶段是把前面的协同设计兑现成最终pattern的地方。我们使用的流程是读入带OCC和扫描结构的网表指定故障模型为transition设置时钟分组和OCC行为模型然后跑向量生成。生成完后先看覆盖率报告再逐条检查是否存在memory接口或者模拟宏的未知X状态干扰。Pattern生成只是起点真正的验证在动态仿真。我们会对生成的pattern做门级仿真在网表路径上反标SDF延迟模拟真实时序行为。仿真时重点观察OCC输出的时钟波形是否在预期的时间点产生两个功能沿SE信号拉低后是否在OCC启动窗口内保持稳定。任何一个环节出现仿真与ATPG预期不一致都要回到约束文件里排查。动态仿真还会暴露X态传播问题。测试向量的初始状态来自扫描加载但某些寄存器在测试模式下可能没有被完全初始化仿真时会出现X。ATPG工具通常会通过仿真X处理机制在向量前后插入初始化序列但如果OCC在某个域的使能信号也是X态捕获时钟就可能不产生导致覆盖率瞬间下降。仿真通过后pattern还要转换到ATE可用的格式我们这边统一用WGL格式输出再在机台上做电压和时钟频率的校准。这一步的细节和ATE资源强相关但前面的协同设计如果做得好得出的pattern在机台上基本不需要反复调试。3.5 测试时间的量化估算与优化协同优化最后要落到一个可以量化的指标测试时间。测试时间直接关系到量产的芯片成本而OCC和ATPG的协同设计能显著影响这个数字。测试时间的粗略公式是pattern总数 × 单条pattern的移位周期数捕获周期数。频率一定时影响时间的主要变量是扫描链长度和pattern数量。我们的芯片满规格扫描链长度约2000个扫描单元移位时钟定在30MHz单个transition pattern的移位周期数大约几千个乘以数千条pattern之后单颗芯片测试时间很容易突破几秒。想要缩测试时间可以通过提高压缩比、增加扫描通道、优化pattern顺序、降低重复覆盖率等办法。但这些优化和OCC设计有联动关系压缩比提高后单条链变长OCC的捕获窗口还是按功能频率执行不会改变捕获沿之间的时序但捕获后数据搬运时间会变长。所以我们在设计阶段就把“压缩比、链数、测试时间、覆盖率”四个指标放在一起推演宁可多花两周做权衡也不在流片后再返工。4. 实测过程中的问题实录与排查思路4.1 过渡故障覆盖率为什么卡在70%上不去项目进行到ATPG收敛阶段transition覆盖率连续几天卡在70%怎么加pattern都动不了。我们排查后定位到两个原因。第一个原因是某个IP内部有一个低频使能信号在功能模式下由软件配置寄存器控制但测试模式下这个寄存器没有被扫描替代导致该IP的OCC使能路径被截断ATPG认为相关路径不可测。解决办法是把该寄存器纳入扫描链并让OCC使能信号直接受测试控制器驱动覆盖随即恢复。第二个原因是跨电源域的信号在测试时钟下存在较长的传输延迟ATPG工具默认把它当功能路径处理反而造成大量时序冲突。我们在SDC和ATPG约束里同时把这个路径设成异步覆盖率立刻回到80%以上。这类问题很隐蔽因为报错信息不会直接说“OCC使能被截断”而是显示一个又一个“unable to generate pattern”的条目。三个人的排查经验是覆盖率上不去时第一优先看OCC使能信号和禁测路径名清单不要一开始就怀疑故障模型设置。4.2 OCC识别失败同样一个模块DFT工具就是找不到时钟另一个高频问题是工具识别不了OCC。现象是DRC报“no valid OCC clock”但我们明明已经把OCC模块挂好了。查下来通常有两个原因一是OCC的输入时钟名带上了功能时钟的分频信息工具需要用户在dft配置里显式指出时钟树主节点二是OCC的启动信号在工具视图里被识别成普通数据引脚没有被定义成test control信号。解决方式是回到dft_signal定义里逐个核对OCC的时钟输入、启动输入、输出时钟三类引脚是否都正确声明。这个工作很琐碎但是最值得提前做的。我们在新建一个IP的DFT约束时会直接套用一套固定模板再按IP差异修改而不是每次从零开始写避免漏定义导致的低级问题反复出现。4.3 动态仿真里的X态和“仿真没有沿”动态仿真阶段有段时间仿真波形里OCC输出时钟在某些pattern里完全不动作整个捕获窗口都是平的。我们最开始以为是RTL和网表不一致后来发现是仿真激励里没把PLL输出建模成自由运行时钟PLL的初始状态是XOCC等待X信号根本没有启动。解决办法是在pattern仿真的激励脚本里把OCC依赖的PLL输出在初始化阶段显式置为有效值不能依赖仿真器自动推断。类似的问题还出现在低功耗状态下某些时钟自动门控单元在仿真初期把功能时钟关掉了OCC自然拿不到时钟源。后来我们在测试激励模板里固定加一段“时钟初始化序列”先把所有PLL和时钟门控打开再执行OCC启动问题基本清零。4.4 后端时序和功耗的反复拉锯后端做时钟树时OCC路径是最容易引起时序超额的区域。因为OCC的输入是功能时钟输出又直接驱动大片扫描寄存器时钟树的负载和分支数量都很大。我们遇到过一次OCC路径的hold违例原因是OCC输出的时钟树和捕获寄存器之间的偏移过大修复方式是在OCC后端加了多级平衡buffer同时调整了扫描寄存器的布局密度让OCC的输出负载尽量均匀分布。功耗方面OCC在测试模式下的功能时钟会以capture频率开关测试功耗常常比功能模式高一大截。我们测试时发现动态仿真中某域瞬时功耗接近功能模式上限为了压低它把测试捕获频率从原来的最高PLL频率降到了0.7倍PLL频率虽然对缺陷检测的灵敏度有一点影响但避免了ATE上的供电风险。这是典型的协同优化取舍测试质量和功耗约束之间没有绝对最优只有项目约束下的平衡。5. 工具链选型、工程落地与个人体会5.1 我们实际使用的工具链组合项目里DFT插入和ATPG用的是不同的工具组合原因是它们在OCC处理方式上各有特点。前端DFT插桩和压缩用Synopsys的DFT CompilerATPG用TetraMAX后端时序分析用PrimeTime。这套组合在标准scan和transition测试上非常成熟OCC的库单元模型支持也比较完整。另一条值得研究的路线是Siemens的Tessent系列它在OSC信号级时钟控制和高压缩比scan压缩上做得比传统流程灵活尤其适合多时钟域和层次化实现的项目。我们评估过Tessent但最终因为团队对Synopsys的flow更熟切换成本高没有换。选型建议是团队原有skill set最重要工具本身功能差异在大多数项目里都能通过约束补齐熟练度才是真正的瓶颈。5.2 约束文件一致性是这个项目最大的工程难点协同优化光靠工具跑流程不够还要有一套能贯穿DFT、STA、ATPG三端的约束体系。我们在项目里维护了一份统一的测试时钟树配置文档里面记录每个OCC实例的时钟源、使能信号、输出时钟名、测试模式定义。任何一个环节改了OCC相关的约束文件同步更新并且有专门的脚本做三个工具之间的一致性检查。这份文档在项目中期发挥了很大作用。有一次后端工程师为了优化时序调整了OCC输入路径上的一个buf尺寸如果只改SDC不通知ATPGATPG里不会感知这个变化覆盖率报告看着没问题但流片后测试时序可能出现细微偏差。有了统一配置和自动检查这类问题的风险被提前拦截。5.3 团队协作建议把DFT当“一等公民”项目里最聪明的一个决定是把DFT工程师安排到了综合环境建设的初期评审里而不是等综合脚本跑完再加入。这样前端designer在选时钟方案时会主动考虑测试可行性后端在解决时序问题时也会把DFT模式的时序作为一个独立signoff项目而不是总当成“附加项”处理。跨团队开会时我会跟大家强调一个概念DFT不再只是加几条链而是从时钟规划开始就要考虑OCC的物理实现和ATPG的时序边界。谁提方案谁负责把约束同步给下游不让任何信息停留在口头层面。这在多人协作的SOC项目里效果非常明显。5.4 最后再分享一个小技巧项目尾声调试ATE pattern时花了很多时间对比TetraMAX仿真波形和机台波形。后来发现在TetraMAX里开启pattern compression并写入仿真时间戳信息能直接在ATE上快速定位第一次fail的pattern序号不用整条向量切成几万段逐段查。这个参数在项目初期容易被忽略但对量产调试效率帮助巨大。做SOC DFT流片验证的朋友建议在流程初期就把这个选项打开能省下后面几天熬夜时间。