做DFT这些年每次新项目碰OCC选型我都不敢拍脑袋。几年前有颗MCUTessent做ATPGtransition测试覆盖率死活冲不上85%抓了很久才发现问题出在OCC类型上——设计里有两个异步时钟域实际需要标准OCC方案阶段却选了mini OCC。从那之后我总结出一套在Tessent环境下的OCC选型方法从时钟关系梳理、面积预算到配置示例一步到位。这篇就把这套方法完整展开先讲清楚为什么at-speed测试必须依赖OCC再拆开OCC内部看三种类型的本质差别最后给出标准OCC、同步OCC、mini OCC在Tessent中的配置参考。无论你正在做DFT集成、ATPG调试还是想理解芯片测试时钟是怎么办到的这篇都值得收藏。1. 为什么at-speed测试必须要有OCC慢测试机与快芯片之间的那座桥1.1 测试机的时钟频率根本喂不饱芯片ATE自动测试设备的本质是用可重编程的方式给芯片灌激励、收响应。但at-speed测试有一个绕不开的核心矛盾大容量测试机在高频下驱动能力会急剧下降。常见的大规模测试机在scan测试时能稳定输出的时钟频率通常只有几十到几百MHz而消费级芯片的主频轻松上GHz。不是测试机厂商做不出更快的时钟而是要让数千根测试通道同时跑GHz信号成本和功耗完全失控。在制造测试里有两类故障必须用接近真实工作频率的时钟激励才能覆盖transition delay fault过渡延迟故障和small delay defect小延迟缺陷。慢速时钟下它们不会显形只有当发射沿launch和捕获沿capture之间的时间窗口接近正常工作周期时延迟路径上的累积偏差才会被采样出来。这时候如果还指望外部测试机去提供高速时钟从技术和成本两个角度都走不通。1.2 OCC的两段式工作模式移位慢、捕获快OCC解决这个问题的思路很直接由芯片内部的PLL产生高速时钟OCC扮演一个“闸门”角色只在捕获窗口放行特定数量的高速脉冲。整个测试过程被切分成两段。第一段是扫描移位shift。扫描链上的数据通过慢速时钟逐步移入移出频率低、负载重对时序要求不苛刻绝大部分测试功耗也集中在这里。第二段是捕获capture。扫描链数据就位后PLL早已锁定OCC在合适的时机输出1到4个高速脉冲让芯片内部的组合逻辑以接近真实工作频率的速度完成一次“发射-捕获”。两个阶段的切换由scan_enable信号控制。scan_enable拉高时进入移位拉低后进入捕获。OCC的核心义务就是保证这个切换过程不产生毛刺、不多发脉冲、不少发脉冲并且和PLL的锁定状态安全握手。话虽简单实际做起来里面每一个细节都可能变成硅后测试的坑。1.3 没有OCC的备选方案为什么都走不通有人问为什么不能让测试机直接输出高速时钟原因有三个。第一是测试机成本。GHz级别的多通道测试机是按“通道数乘频率”定价的一颗小芯片可能还能忍多核SoC或大规模ASIC直接成本爆炸。第二是信号完整性。外部时钟经过socket、封装、PCB走线才到片上时钟树根部中间每一段都是阻抗不连续的地方高频信号衰减很严重很难保证到了片上还“又干净又准时”。第三是PLL锁定问题。即使外部时钟进来了如果绕过PLL片上大量同步逻辑直接吃外部时钟功耗、时序、时钟树结构全部被打乱后端CTS无从下手。所以把高速时钟生成放回芯片内部由OCC负责精准放行是目前工业界的标准解法。理解了OCC在测试链路中的位置下面再拆开它内部看个仔细。2. 拆开OCC看内部切换、计数、控制三件事要搞清标准OCC、同步OCC、mini OCC之间的差异先得明白OCC内部其实只干三件事切时钟、数脉冲、受控制。2.1 时钟切换最容易被低估的时序难题OCC的输入端至少有两路时钟一路是外部慢速测试时钟shift阶段用一路是PLL过来的内部高速时钟capture阶段用。这两路时钟相位不固定频率也不同直接做mux会产生毛刺。所以OCC的时钟切换逻辑不能是简单的组合逻辑选择而需要类似clock gating cell的锁存结构保证切换时刻发生在两路时钟的“安全区间”输出端不出现窄脉冲。在标准OCC里每一路捕获时钟源都有独立的切换逻辑用来应对不同PLL、不同相位关系的时钟。同步OCC可以共享部分切换控制前提是所有目标时钟的上升沿已经对齐。mini OCC最简单往往只支持“外部时钟和一路PLL时钟”之间切换应用场景受限也正因为此。2.2 脉冲计数器决定at-speed抓捕节奏的核心捕获阶段输出几个高速脉冲不是拍脑袋定的而是由OCC内部的脉冲计数器控制。最常见的是2位或3位可编程计数器能输出1/2/4/8个脉冲。为什么脉冲数量这么重要ATPG测transition delay fault时常用的两种捕获协议是launch-off-captureLOC和launch-off-shiftLOS。LOS需要在最后一个移位脉冲之后立刻跟一个高速发射沿对脉冲计数和时序要求极高LOC则允许扫描移位结束后通过同一时钟域产生“发射沿-捕获沿”两个连续脉冲。如果OCC不支持可编程脉冲个数ATPG工具就只能迁就它覆盖率自然打折。mini OCC通常把脉冲个数固定成最少配置几乎不支持LOS。标准OCC和同步OCC都支持可编程配置区别在于同步OCC的计数器往往多个域共享标准OCC则允许每个域独立计数。2.3 控制寄存器和PLL锁定窗口OCC不是“一根线”OCC要正常工作还需要一组控制输入scan_enable切换移位/捕获、test_mode测试模式使能、occ_reset复位以及关键的PLL锁定信号pll_lock。在Tessent的测试协议里这些信号都会被读取、解析并生成对应的时序过程。有一个容易忽略的细节PLL从开始重新配置到真正锁定需要一段时间OCC必须等待pll_lock稳定后才能释放捕获脉冲。如果锁定等待窗口配置得太短ATE上会偶发性失败配置得太长又拖慢测试时间。标准OCC通常允许等待时间可编程mini OCC往往写死。下面是一个OCC常见信号的参考表以Tessent库单元风格端口为例信号方向作用pll_clkinPLL输出的高速捕获时钟ext_clkin测试机慢速移位时钟clk_outout送往片上时钟树受控输出pll_lockinPLL锁定标志scan_enablein移位/捕获模式切换test_modein测试模式全局使能occ_reset_nin异步复位低有效pulse_cfg[1:0]in捕获脉冲数配置2.4 从内部结构反推三种OCC的本质差异理解了这三个子模块三种OCC的本质差异就清楚了。标准OCC是“每个时钟域各自一套完整逻辑”——独立的切换、独立的计数、独立的PLL握手所以它能处理任意多域和任意相位关系。同步OCC把“共享”做到了极致所有域共享统一的脉冲计数和时间基准前提是域间相位必须可预测否则共享就是灾难。mini OCC则是“安全最小集”把切换和计数逻辑都压缩到刚好够用省面积省时序但也牺牲了高级控制能力和覆盖率。这个差异不是面积数字能体现的它直接决定了你能跑什么测试协议、能达到什么覆盖率水平。3. 三种OCC真正拉开差距的维度不只面积3.1 时钟域支持能力是首要分水岭如果项目里有两个PLL它们输出的时钟之间相位完全不确定这就是异步时钟域。标准OCC的每个域独立处理ATPG工具可以分别为每个域安排捕获沿即使域间频率差几倍也没问题。同步OCC需要所有域共享一个时间基准域间相位必须对齐或有明确约束所以它天然适合单一PLL加多个分频时钟的设计。mini OCC通常只有一个时钟域可选。如果一个IP内部既有2GHz主域又有50MHz慢域mini OCC就安排不了at-speed捕获。这就是为什么mini OCC多出现在功能简单的小IP里。3.2 可编程性、门控时钟和集成方式除了时钟域关系还有几个细节会影响选择门控时钟域是否需要独立控制、是否需要与LogicBIST集成、OCC控制寄存器走JTAG还是直连信号。标准OCC对门控时钟的处理最完善能识别时钟门控并在捕获阶段正确避开无效脉冲。同步OCC对门控的支持取决于具体实现。mini OCC基本不考虑门控。如果计划在同一个内核里同时跑Tessent LogicBIST和ATPGOCC类型会影响两套流程的时序闭环。LogicBIST对OCC的依赖更高mini OCC有时也嵌入在LogicBIST的IP核里但那是“自成一派”的用法和标准ATPG的OCC不是一回事。3.3 面积与后端时序影响不是一个量级从面积看标准OCC每域约几百到上千逻辑门同步OCC共享设计后单域面积约为标准型的50%到70%mini OCC通常只有标准型的三分之一以下。不过具体数字强烈依赖工艺库和Tessent版本。从时序影响看OCC插在PLL输出和时钟树根部之间引入的插入延迟和抖动直接影响后端CTS。mini OCC因为路径短、逻辑少对时序影响最小。如果一颗芯片对面积和时序都非常敏感而覆盖率要求又不高mini OCC就是最优解。我实际遇到过一个极端案例一颗小传感器IP总逻辑才几万门强行挂标准OCC光DFT逻辑和配套约束就占了近10%的面积后端直接抗议。后来换成mini OCC面积问题立刻缓解测试覆盖虽然略降但完全满足spec要求。3.4 典型应用场景对照表维度标准OCC同步OCCmini OCC时钟域关系任意含异步同步、同源单一或极少脉冲可编程每域独立共享可编程固定或极少档位门控时钟支持完善中等基本不支持逻辑面积最大中等最小时钟树影响最深中等最浅ATPG协议复杂度高中低典型场景SoC/多PLLMCU/单PLL分频小IP/面积敏感4. 选型决策法先列时钟关系再算面积账4.1 一张清单摸清设计里的所有测试时钟域在Tessent环境里做选型前我建议先出一张时钟域清单。不要只看RTL名字要把每个时钟的物理来源、PLL关系、分频比、使能条件全部列一遍。时钟名源PLL频率/分频与其他域相位关系是否门控是否用于功能捕获clk_cpupll_cpu2GHz / 1与总线域异步部分门控是clk_buspll_bus300MHz / 1与CPU域异步否是在Tessent中用report_clocks或综合后的时钟树报告提取这一步的信息。提前整理出来后期ATPG阶段你还会用到同一份清单去约束时钟组省很多事。4.2 判断域间是同步还是异步一个域到底是同步还是异步不只看RTL里是否跨域。两个时钟来自同一个PLL、分频比为整数、相位已经对齐并且在CTS阶段有对应的时钟树关系约束——这才能算同步域。如果只是频率看起来成整数倍但相位不确定或者来自两个PLL但没有任何同步保证都要按异步处理。边界情况是分频时钟。有时分频器产生的时钟沿与源时钟对齐可以直接当同步处理有时分频器本身受门控影响沿的位置会漂移那就不能想当然。4.3 用决策表套出候选OCC类型判断逻辑可以压缩成三句话只要存在异步时钟域直接选标准OCC。所有目标域能证明是同步关系优先选同步OCC面积和协议复杂度都更友好。小IP、单域、面积/时序敏感、at-speed覆盖率要求不高选mini OCC。注意“只要存在异步域就选标准OCC”不是偷懒。异步域的捕获时序在硅上具有不确定性ATPG工具无法跨异步域做可靠的launch-capture强行用同步模型只会带来覆盖率和稳定性的双重损失。我曾见一颗IoT SoC四五个时钟域都是同源分频方案阶段选了标准OCCATPG阶段工具一直报某个域的捕获沿不匹配后来换成同步OCC问题直接消失。反过来如果异步域硬用同步OCC那就会进入第6章要讲的深坑。4.4 把ATPG调试时间算进成本OCC选型还有一个容易忽略的隐性成本ATPG调试时间。同步OCC的协议简单工具生成捕获过程时几乎不会有冲突。标准OCC协议复杂稍有不慎会在协议分析阶段报出几个域的控制信号约束冲突排错往往以小时计。mini OCC则最少出问题但它能做的测试有限。所以最终决策不是“哪个覆盖率最高”而是“在目标覆盖率和成本约束下哪个最稳”。5. Tessent中的三种OCC配置示例照着改就能跑5.1 配置前先确认的四类信号无论哪种OCC在Tessent里做配置前都要先把四类信号确认清楚。PLL相关PLL输出时钟端口、锁定信号端口。测试控制scan_enable、test_mode、occ_reset。时钟输入外部测试机时钟、移位时钟。输出目标OCC输出接到哪棵时钟树根部。Tessent不同版本的命令名称差异很大尤其是2019、2021、2023这几个大版本之间OCC相关命令改过不止一次名。下面示例我按近几个版本的通用风格写重点在参数逻辑具体命令名请以手上的Tessent用户手册为最终依据。5.2 标准OCC双PLL异步域的完整配置思路场景一颗MCU一个PLL给CPU核一个PLL给外设总线两个域之间是异步关系。DFT插入阶段脚本片段# 选择标准OCC set_dft_configuration -occ_type standard # 定义第一个时钟域CPU域 set_dft_clock_domain -name cpu_domain \ -clock_port clk_cpu_out \ -pll_port pll_cpu_out \ -pll_lock_port pll_cpu_lock # 定义第二个时钟域总线域 set_dft_clock_domain -name bus_domain \ -clock_port clk_bus_out \ -pll_port pll_bus_out \ -pll_lock_port pll_bus_lock # 使能OCC并绑定全局控制信号 set_dft_occ -enable true \ -scan_enable_port scan_enable \ -test_mode_port test_mode \ -reset_port occ_reset_n \ -pulse_count 2 insert_dft这段配置的核心意图是让每个域拥有独立的PLL和锁定握手。pulse_count设为2是因为LOC协议需要“发射沿捕获沿”两个脉冲如果计划启用LOS脉冲数就要按协议调整。insert_dft之后Tessent会在每个时钟域插入独立的OCC逻辑互不共享计数。ATPG阶段还需要把PLL模型和OCC控制信号交代给工具# 建立PLL模型锁定等待时间给足 add_pll -name pll_cpu -reference clk_tester \ -output pll_cpu_out -lock_time 5.0 add_pll -name pll_bus -reference clk_tester \ -output pll_bus_out -lock_time 5.0 # 扫描使能约束 add_scan_enable -port scan_enable5.3 同步OCC同源分频时钟域的推荐配置场景一颗IoT芯片只有一个PLL输出2GHz后面二分频得1GHz给CPU四分频得500MHz给总线域间相位对齐。# 选择同步OCC set_dft_configuration -occ_type synchronous # 只以PLL输出作为参考分频时钟交给OCC共享计数器 set_dft_clock_domain -name sys_domain \ -clock_port clk_sys_out \ -pll_port pll_sys_out \ -pll_lock_port pll_sys_lock set_dft_occ -enable true \ -scan_enable_port scan_enable \ -test_mode_port test_mode \ -reset_port occ_reset_n \ -pulse_count 2 \ -share_counter yes insert_dft重点在share_counter yes多个同步域共享同一个脉冲计数器因为这些域之间的相位关系确定一个脉冲安排下去所有域都能在同一时间窗口完成捕获。如果这里误选了标准OCC虽然也能工作但DFT逻辑更多ATPG协议分析也更慢。5.4 mini OCC单域小IP的极简配置场景一个挂在SoC上的小IP只有一个独立时钟主逻辑走ATPG里面做基本transition测试即可。# 选择mini OCC set_dft_configuration -occ_type mini set_dft_clock_domain -name ip_domain \ -clock_port clk_ip_out \ -pll_port pll_ip_out \ -pll_lock_port pll_ip_lock set_dft_occ -enable true \ -scan_enable_port scan_enable \ -test_mode_port test_mode \ -pulse_count 1 \ -programmable no insert_dft注意这里的pulse_count 1和programmable no意思是捕获阶段只输出一个固定脉冲。它不像标准OCC那样能支撑完整的LOC/LOS协议transition覆盖能力有限但对一个面积敏感的小IP来说能覆盖一部分高速路径已经够本。5.5 配置完怎么验证跑通ATPG只是第一步插入完成后别急着直接run_atpg。先做几件事。用analyze_test_protocol检查协议是否合法。常见错误是clock domain not synchronized此时回头核对时钟域配置。打开生成的test protocol文件看capture过程里时钟沿个数是否和你的pulse_count一致。这是最直观的证据。跑一个最小用例仿真把OCC输出波形拉出来确认捕获窗口内没有毛刺、脉冲数正确。再看覆盖率报告如果transition coverage异常优先查PLL锁定时间和时钟域相位约束。6. 落地时最容易翻车的三个坑6.1 坑一PLL锁定时间被忽略现象仿真波形里捕获脉冲数量正常但ATE上同一颗芯片偶发性失败时好时坏。排查链路先看每次失败是不是都集中在某几个测试项且都发生在捕获窗口。再查OCC控制寄存器的PLL等待时间配置。用硅后波形观测或增加等待时间做A/B对比。最后定位PLL锁定等待不够复位释放和PLL稳定窗口重叠。解决办法把lock_time从0.5us加到2us同时确认OCC的复位释放策略是在PLL锁定之后而不是同时。我在一个项目里为这个问题消耗了整整两天最后只是调了一个时序参数。6.2 坑二异步时钟域硬用同步OCC现象ATPG覆盖率报告中某个异步域的transition coverage明显低于其他域协议分析却没有报错。排查链路打开test protocol看该域是否被工具纳入了捕获过程。用report_clocks查看该域与主域的相位关系发现来自不同PLL。意识到方案阶段为了省面积选了同步OCC而异步域实际需要标准OCC。解决办法方案阶段就把时钟关系清单做好如果已经流片只能通过TCP排除部分violation但会损失覆盖率。这个坑我在开头提到的MCU项目里真实踩过代价是整整一轮ATPG重跑加硅后补测。6.3 坑三mini OCC的捕获脉冲个数不够现象小IP的transition覆盖率远低于预期无论怎么调ATPG约束都上不去。排查链路先确认OCC类型发现是mini且pulse固定为1。查ATPG工具为这个IP生成的捕获协议发现无法产生LOC需要的双脉冲。覆盖率瓶颈不在约束而在硬件支持。解决办法如果IP规模允许换同步OCC如果面积或时序不允许就和产品团队确认transition覆盖率spec能接受就用“慢速测试加有限高速覆盖”的方式交付。这个坑的教训是mini OCC适合“有总比没有强”但不能指望它和高等级的OCC有同等覆盖率。最后分享一个经验我在每一个DFT项目里都会把OCC选型做成checklist放在方案评审文档的第一页。表面看是在选OCC其实是在定义整个at-speed测试策略。方案阶段多花半小时把时钟关系理清楚能省掉后端、ATPG、测试多轮返工。另外一个小技巧三种OCC的Tessent配置脚本建议分成独立文件比如occ_std.tcl、occ_sync.tcl、occ_mini.tcl通过source按需加载。这样设计改动时钟时只需改一个文件不容易漏。