企业官网建设流程全解析

做DFT这些年，每次新项目碰OCC选型，我都不敢拍脑袋。几年前有颗MCU，Tessent做ATPG，transition测试覆盖率死活冲不上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-capture（LOC）和launch-off-shift（LOS）。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库单元风格端口为例）：

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和ATPG，OCC类型会影响两套流程的时序闭环。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 典型应用场景对照表

4. 选型决策法：先列时钟关系，再算面积账

4.1 一张清单摸清设计里的所有测试时钟域

在Tessent环境里做选型前，我建议先出一张时钟域清单。不要只看RTL名字，要把每个时钟的物理来源、PLL关系、分频比、使能条件全部列一遍。

在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，四五个时钟域都是同源分频，方案阶段选了标准OCC，ATPG阶段工具一直报某个域的捕获沿不匹配，后来换成同步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_enable

5.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。先做几件事。

1. 用analyze_test_protocol检查协议是否合法。常见错误是clock domain not synchronized，此时回头核对时钟域配置。
2. 打开生成的test protocol文件，看capture过程里时钟沿个数是否和你的pulse_count一致。这是最直观的证据。
3. 跑一个最小用例仿真，把OCC输出波形拉出来，确认捕获窗口内没有毛刺、脉冲数正确。
4. 再看覆盖率报告，如果transition coverage异常，优先查PLL锁定时间和时钟域相位约束。

6. 落地时最容易翻车的三个坑

6.1 坑一：PLL锁定时间被忽略

现象：仿真波形里捕获脉冲数量正常，但ATE上同一颗芯片偶发性失败，时好时坏。

排查链路：

1. 先看每次失败是不是都集中在某几个测试项，且都发生在捕获窗口。
2. 再查OCC控制寄存器的PLL等待时间配置。
3. 用硅后波形观测或增加等待时间做A/B对比。
4. 最后定位：PLL锁定等待不够，复位释放和PLL稳定窗口重叠。

解决办法：把lock_time从0.5us加到2us，同时确认OCC的复位释放策略是在PLL锁定之后，而不是同时。我在一个项目里为这个问题消耗了整整两天，最后只是调了一个时序参数。

6.2 坑二：异步时钟域硬用同步OCC

现象：ATPG覆盖率报告中，某个异步域的transition coverage明显低于其他域，协议分析却没有报错。

排查链路：

1. 打开test protocol，看该域是否被工具纳入了捕获过程。
2. 用report_clocks查看该域与主域的相位关系，发现来自不同PLL。
3. 意识到方案阶段为了省面积选了同步OCC，而异步域实际需要标准OCC。

解决办法：方案阶段就把时钟关系清单做好；如果已经流片，只能通过TCP排除部分violation，但会损失覆盖率。这个坑我在开头提到的MCU项目里真实踩过，代价是整整一轮ATPG重跑加硅后补测。

6.3 坑三：mini OCC的捕获脉冲个数不够

现象：小IP的transition覆盖率远低于预期，无论怎么调ATPG约束都上不去。

排查链路：

1. 先确认OCC类型，发现是mini且pulse固定为1。
2. 查ATPG工具为这个IP生成的捕获协议，发现无法产生LOC需要的双脉冲。
3. 覆盖率瓶颈不在约束，而在硬件支持。

解决办法：如果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按需加载。这样设计改动时钟时只需改一个文件，不容易漏。