企业官网建设流程全解析

做SOC芯片DFT时间长了，我越来越觉得，OCC和ATPG的协同，才是at-speed测试里最容易被低估的一环。早年很多人以为DFT就是把扫描链插好、stuck-at覆盖率做到98%就能收工，直到碰上小延迟缺陷逃逸到客户现场，才回头去琢磨OCC（On-Chip Clock Controller）和ATPG（Automatic Test Pattern Generation）之间的配合。这篇文章不打算重复教科书里的定义，而是从一个DFT/测试工程师的视角，把OCC的电路结构、ATPG的故障模型、多时钟域的时钟分组，以及两者联调时的典型翻车现场串起来讲一遍。适合正在做DFT实现、后端时钟树设计、ATE测试程序开发的工程师参考，也适合刚入行、想搞明白“为什么芯片要跑at-speed capture”的朋友。

1. 从一颗实测失效率的芯片说起：stuck-at全过为何还会翻车

1.1 静态故障测不出来，延迟类缺陷才是常态

我三年前接手过一颗28nm的SoC，ATE上全芯片stuck-at测试余量很高，模式也全部pass，但客户板卡在高温场景下返修率异常。诊断日志拉出来，fail pattern几乎都落在CPU与总线桥的接口路径附近。后来用shmoo图一压，锁定的问题是典型的路径延迟超标，而不是某一根线永久短路或者开路。

这类缺陷在28nm以下工艺里非常普遍。金属桥接没完全短死、接触孔电阻偏大、栅氧层退化，都会让信号传播变慢而不是直接失效。stuck-at故障模型本质上是静态的，它只关心节点是否被永久钳在高或低电平，完全无法暴露“信号能在1.2ns内到达，但实际上花了1.6ns”这类时序问题。所以纯stuck-at覆盖率再高，也不能代表芯片在真实工作频率下可靠。

要抓时序缺陷，就必须让测试过程里出现真正的功能时钟沿，也就是at-speed测试。而at-speed测试绕不开OCC，因为ATE测试仪的数字通道时钟通常只有几十到一两百MHz，直接拿测试仪时钟去capture，路径的时序裕量完全不存在测试意义。

1.2 SOC的多时钟域：慢速capture等于没测

单核芯片做at-speed还相对简单，SOC就不一样了。一颗通用SoC里通常有CPU核、GPU/NPU、DDR控制器、Display/Video、各类总线桥和接口IP，每个大模块都有自己的PLL和分频链。CPU跑1.8GHz，总线和DDR可能跑800MHz，Display PLL可能是27MHz基准倍频上去的。这些时钟域之间又有异步FIFO、握手信号、跨域胶水逻辑。

如果DFT阶段没有规划好OCC和时钟分组，到了ATPG阶段就会陷入两难：要么把所有时钟域都接在同一组capture脉冲下，结果跨异步域路径全被工具报成违例，覆盖率惨不忍睹；要么干脆只对少数几个时钟域做at-speed，其他域继续用测试仪慢时钟capture——这样那些域的时序缺陷照样测不到。所以我一直强调，OCC的插入和ATP G的pattern生成策略必须放在一起设计，不能等网表都合成了再补救。

2. OCC到底是怎么把ATE慢时钟换成功能快时钟的

2.1 一个OCC例子里藏着时钟切换的全部关键

OCC的核心任务用一句话说：shift阶段用测试仪的慢时钟保证数据稳定移入/移出扫描链，capture阶段切到芯片内部功能时钟，产生受控数量的脉冲，让被测路径真的跑在功能频率上。

我在RTL里看过很多种OCC实现，抽掉IP细节后骨架都差不多。输入侧有慢时钟slow_clk、功能时钟fast_clk、se（scan enable）、occ_bypass和脉冲数配置；输出侧接到扫描链或者时钟树的capture时钟。关键逻辑可以简化成下面这个示意：

assign sel_fast = !se && !occ_bypass && capture_en; assign clk_out = sel_fast ? fast_clk : slow_clk;

但实际电路绝对不能这么简单粗暴。时钟MUX的切换瞬间如果不在低电平，可能会吐出一个毛刺，这个毛刺会被扫描链当成一个多余的capture沿，导致ATPG仿真里明明只有两个沿，到芯片上实际产生了三个沿，最终结果全错。所以真正的OCC都会在内部加脉冲计数器、时钟门控ICG，以及把使能信号同步到功能时钟低电平的同步逻辑。

一个典型的完整OCC内部包括：时钟源MUX、PLL锁定状态判断、脉冲计数器（一般可配置1到8个脉冲）、旁路路径、以及复位逻辑。脉冲计数器决定capture阶段输出几个功能时钟沿；旁路路径则保证PLL没锁、芯片上电初始化或者低速测试时，时钟仍然能透传到扫描链。occ_bypass必须在DFT模式规划时好好设计，否则一旦PLL因为工艺偏差起振失败，整颗芯片连扫描测试都做不了。

2.2 LOC与LOS：两种launch方式的取舍

ATPG生成transition vector时，OCC脉冲的用法分成两种，一个叫LOC（Launch Off Capture），一个叫LOS（Launch Off Shift）。

LOC模式里，shift阶段结束之后se拉低，然后OCC输出两个功能时钟脉冲。第一个沿叫launch沿，把新的值打进组合逻辑起点；第二个沿叫capture沿，把组合逻辑在一个功能周期之后的结果捕获到扫描触发器。这个模式的好处是跟芯片真实工作行为接近，而且se在launch沿之前已经稳定，关于se的时序约束相对宽松，业界大部分at-speed pattern都用LOC。

LOS模式则是shift阶段最后一个移位时钟沿作为launch，紧接着切到功能时钟，第一个功能时钟沿就是capture沿。LOS对覆盖某些转换路径更直接，因为launch来源是扫描链本身，不依赖前级组合逻辑先稳定到某个状态。但坏处也很明显：se信号必须在移位时钟沿和功能capture沿之间极短窗口内完成翻转，这个窗口通常不到一个功能时钟周期。在GHz级频率下，SE从芯片一端穿到所有扫描触发器，延迟很难控，所以LOS在高速域里经常做完STA之后发现违例一大片。

我自己的原则是：默认优先LOC，除非有明确的路径覆盖收益证明LOS值得付出SE时序代价，否则不碰LOS。很多DFT工具和OCC IP其实两种模式都支持，但支持归支持，敢不敢在量产测试里打开是另一回事。

2.3 旁路、脉冲数与模式规划，不能只当作RTL细节

OCC设计里最容易被忽略的是模式规划。一颗SOC不会只有一个OCC，每个PLL时钟树下可能都要挂一个。每个OCC都要支持慢速scan、at-speed capture、以及可能的BIST时钟切换，还要有全局的occ_bypass总控信号。

这些模式不只是在RTL里写几个case，它直接决定ATPG工具能生成什么样的pattern。如果ATPG阶段希望某个时钟域在capture时产生两个脉冲，但OCC的脉冲计数器配置只允许一个脉冲，那这个pattern在仿真里就通过不了。反过来，如果OCC允许产生8个脉冲，ATPG工具也会头大，因为多出来的脉冲可能让某些路径发生非预期翻转，X态变多，覆盖率反而下降。

所以我会在DFT设计文档里明确每个OCC的脉冲数范围、bypass策略、PLL锁定时间预算，并且把这份文档同步给做ATPG的同事。信息不写出来，后面流程里每一步都要靠猜，这种隐性成本比工具本身慢得多。

3. ATPG生成at-speed向量时，OCC脉冲数是谁在约束谁

3.1 transition fault为什么非要两个沿

经常会有人问，为什么transition fault测试不能像stuck-at一样只给一个capture沿？因为转变型故障测的是“节点能否在规定时间内从0变成1或者从1变成0”。你只给一个沿，触发器的输入在capture之前到底是稳定在新值还是旧值，压根没法定论。必须先用launch沿把起点改成目标值，等一个功能时钟周期，再在capture沿检查终点是否变化到位。

这个逻辑落到OCC上就是：OCC至少得输出两个功能时钟脉冲。第一个脉冲产生launch，第二个脉冲产生capture。如果被测路径需要跨两个时钟周期才能稳定，甚至需要三个、四个脉冲来建立内部状态，那么OCC的脉冲数必须大于等于这些沿的需求。这就是为什么OCC脉冲配置和ATPG向量之间存在直接的物理约束关系。

可以做一个简单的数字估算。假设被测路径需要在1GHz功能时钟下测试，组合逻辑延迟约700ps，路径裕量300ps。如果OCC只给一个脉冲，压根没有launch，整个vector就是无效测试；如果给两个脉冲，路径有一个完整的1ns周期去传播；如果给三个脉冲，中间多出来的那个周期可能让某条本来应该测的长路径跑两次，实际上会改变故障激活条件，ATPG工具必须能感知这个窗口。

3.2 故障模型、脉冲数与覆盖率的关系

不同故障模型对OCC脉冲数要求不一样，我整理了一张表，团队里新人都先看这个：

理论上OCC脉冲数配到2就满足transition最基本的launch/capture需求。实际工程里很多OCC默认配到4，因为SOC内部有流水线、状态机、异步FIFO之类的逻辑，部分节点需要多一个周期才能把非目标路径稳定下来，避免X态干扰。脉冲数越多，对X收敛越友好，但每个pattern在ATE上的capture耗时会增加，而且多出来的沿可能让ATPG工具在时序上产生更复杂的约束。所以不是越大越好，而是要看ATPG工具给出的覆盖率曲线。

3.3 ATPG约束里最容易漏掉的两件事

第一件是OCC窗口与功能时钟脉冲数的声明必须显式写给ATPG工具。很多工程师在TetraMAX或者Modus里只定义了时钟端口和scan chain，没说明OCC在capture阶段到底产生多少个脉冲、哪个沿是launch、哪个沿是capture。工具只能默认按一个capture沿处理，结果生成的transition vector根本没用上OCC的功能，到门级仿真阶段才发现覆盖率掉了好几个点。

第二件是PLL锁定时间要写进ATPG的时序环境。OCC切到功能时钟前，PLL必须先锁定。如果ATPG只给了快速时钟，没告诉工具这个时钟源需要几十微秒的锁定时间，仿真时可能用一个“开关即来”的理想时钟源，和芯片实际情况完全不符。后面到了ATE上，测试程序里还得专门加等待PLL lock的宏，稍不注意时间就不够，量产测试直接fail。我建议是在ATPG流程的DRC阶段就把pll_lock、occ_bypass这些信号建模进去，哪怕初版模型粗糙一点，也比没有强。

4. 多PLL多时钟域的SOC，OCC分组与ATPG约束要一起定

4.1 时钟分组不是后端一个人的事

SOC的DFT时钟分组，经常被误以为只是后端CTS的事。实际上CTS关心的是时钟树的skew和latency，但DFT关心的是哪个时钟域能在capture阶段同时处于高速状态、哪个域必须保持慢速或停振。这两个维度必须对齐。

我习惯的做法是把芯片的时钟域按“能否安全同时at-speed capture”分组。简单示例：

这个分组表不是随便拍的。CPU和总线如果频率比例固定、相位关系由同一个PLL分频出来，就可以放进同一组同时capture；GPU和CPU如果各自有独立时钟源且没有同步关系，强行同时capture只会让跨域路径违反约束，工具能报出几百条false path，覆盖目标反而失焦。

4.2 从DFT spec到ATPG约束的流转，信息要显式

DFT spec不能只写“OCC挂在PLL0上”。要把每个OCC所属时钟域、支持的脉冲数、bypass信号名字、PLL锁定时间、以及哪些DFT模式允许进入at-speed capture全都写清楚。我在实际项目里会用一个类似下面的配置表，直接作为ATPG的输入依据：

clock_group cpu_fast { source = pll0; target_clocks = cpu_clk, bus_clk; occ_instance = u_occ_cpu; pulse_num = 2; bypass_signal = occ_bypass_cpu; } mode fast_cpu_bus { groups = cpu_fast; capture_clock = pll0_out; lock_wait_us = 40; }

这份东西同步给ATPG和DV仿真团队后，大家不用再去翻RTL猜OCC的行为。更重要的是，当后端为了时序把某个OCC的脉冲数从2改成4时，DFT spec是唯一能保证ATPG团队感知这个变化的地方。没有这个显式流转，OCC改动了，ATPG pattern还在按2个脉冲做，量产测试覆盖率不达标，你在电话会上解释都解释不清楚。

4.3 跨时钟域接口怎么处理才不会在覆盖报告上留坑

跨时钟域逻辑是SOC里绕不开的坑。异步FIFO、握手协议、双触发器同步器，这些路径上没有固定的相位关系。如果两个异步域同时at-speed capture，ATPG工具要么把跨域路径全设成false path，导致这部分逻辑覆盖率为0；要么强行约束，产生大量不可用pattern，后仿还可能fail。

我的处理思路是分层：主测频率域用at-speed capture；非目标域在capture时保持慢速时钟或者直接停振，让跨域接口不会同时翻转；再单独设计一个async_brdg模式，用慢速时钟同时capture所有域，专门覆盖跨域胶水逻辑的静态故障。虽然慢速capture的transition覆盖率没有，但至少stuck-at覆盖是补上了。这样组合下来，芯片整体覆盖率报表才不会有明显的黑洞。

5. 测试时间 vs 覆盖率：怎样合并向量才不白烧ATE机时

5.1 向量数不等于测试时间，先算清开销

ATPG报告里能看到pattern数量，但真正决定量产测试成本的是每个pattern在ATE上跑多久。芯片shift阶段的时间基本是固定的：扫描链深度除以shift频率。假设扫描链深度8000，shift频率25MHz，单个vector的shift时间就是8000/25MHz=320us，5000个vector就是1.6秒。

at-speed capture本身很快，一个功能时钟周期在纳秒级，但如果每次进入at-speed capture都要重新等PLL锁定，情况就完全不同了。PLL锁定时间通常在20到50us，看起来不多，可如果这5000个vector都单独跑fast capture模式，那就是0.1到0.25秒的附加时间。更麻烦的是ATE在等待期间不能空转，测试程序里要写等待宏，pattern执行时间可能成倍放大。所以我会在DFT阶段尽量给OCC设计“PLL常开”路径，让shift阶段PLL不被关断，只有capture窗口才切到功能时钟，这样锁定等待只发生在模式开头，而不是每个vector都来一遍。

5.2 EDT压缩在at-speed模式下会反噬覆盖率

压缩逻辑是DFT节约测试时间的大杀器，但压缩器和OCC之间有个微妙的关系。EDT解压器把测试激励广播到多条内部扫描链，压缩器再把响应压缩回ATE通道。stuck-at模式下，所有扫描触发器都在同一拍capture，压缩器对X态有成熟的mask策略。到了at-speed模式，如果多个时钟域同时capture，不同域的capture沿可能不在同一时刻，压缩器看到的时间混叠会让原本可以mask的X态变成无效数据，覆盖率直接往下掉。

另一个问题是，OCC输出的capture脉冲数如果和压缩器的时序窗口对不上，解压器送出的激励可能还没稳定，capture沿就到了。这类问题在仿真阶段表现往往是“pattern前仿pass，后仿fail”，特别难查。我的经验是，在同一个EDT session里做at-speed capture时，尽量让所有参与capture的域使用同一个OCC使能，并保持脉冲沿对齐；实在做不到，就拆成不同EDT session分别生成向量。

5.3 增量式生成与向量合并的实操思路

做ATPG不要一上来就跑全量transition vector，那是烧机时。更稳的节奏是先做慢速stuck-at测试，确定扫描链和基础逻辑没问题；然后针对高频时钟域生成增量transition vector；再对低频/外设域决定是否真的需要at-speed。

工具里通常支持增量模式，也就是在已有vector集基础上只补充当前时钟域未覆盖到的故障点。这比单独为每个域生成全套向量要省不少。两个模式如果共享大量扫描链装载，还可以用向量合并功能，把“慢速capture+快速capture”的公共shift部分合并，减少ATE上重复的时间。

我做过一次统计：单独为CPU域生成4万条vector，跟增量式生成1.2万条相比，transition覆盖率差1.5%左右，但测试时间少了将近三分之二。这个差距在量产成本上是完全值得接受的。

6. 联调阶段最容易翻车的三个场景与我的检查清单

6.1 capture的第一个沿竟是毛刺

某次和老同事联调，ATPG门级仿真全部通过，但芯片一上ATE就出现“pattern pass率随电压变化”的怪问题。用shmoo图压下来，失败点集中在capture窗口开始的边界上。打开波形，发现OCC输出在se下降沿附近多了一个很窄的毛刺。原因是后端在CTS时把OCC输出当作普通时钟源处理，没有保证选择信号在功能时钟低电平期间翻转，MUX切换瞬间产生了一个半高不低的脉冲。

这个问题在仿真里很难抓到，因为理想时钟模型下MUX切过去就是干净的沿。解决方式是回到OCC内部，把选择逻辑改成ICG时钟门控结构，锁存使能信号，让切换只发生在功能时钟低电平。修复之后同样的vector集shmoo图变得很干净。这个案例之后，我对OCC的RTL实现多了一条死规矩：时钟域切换必须有ICG，禁止裸MUX切时钟。

6.2 SDF反标和库版本不一致，覆盖率一夜回到解放前

另一次是ATPG报告transition覆盖率94%，门级仿真也过了，但换了一版综合网表之后，覆盖率掉到87%。一开始怀疑约束变了，查了一圈都不是。最后发现是SDF反标时用的仿真库和综合signoff库版本不一致，OCC路径里某个单元的延迟差了几十皮秒。几十皮秒在低速域不痛不痒，但在高速OCC窗口控制逻辑里，直接导致脉冲宽度不足，部分capture沿没有被正确识别。

从那以后，我在每次跑at-speed仿真前都会加一步：核对SDF文件生成版本、综合脚本版本、signoff库版本，并用STA里报出的OCC时钟路径延迟与门级仿真波形做交叉验证。这个动作多花半天时间，但能避免整个ATPG迭代白做。

6.3 PLL锁定时间拖垮测试预算

量产测试时间超标这种事，通常是“每个地方都慢一点点”叠加出来的。某个项目ATPG报告pattern数不多，但ATE单颗测试时间明显偏高。逐段分析测试程序后发现，每次进入fast capture模式，程序都会重新配置PLL、等锁定、再执行几个pattern，然后切出。因为OCC设计里没做PLL常开路径，导致模式切换几百次，锁定等待时间全被摊到测试成本里。

后续和设计团队沟通，在OCC控制器里增加了一个“keep_pll_on”的控制位，让PLL在shift阶段持续运行，只有capture窗口才切换通路。改版之后单颗测试时间降了大约30%。这个改动不影响覆盖率，纯属DFT策略和OCC实现没有对齐造成的浪费。

6.4 我现在固定使用的OCC-ATPG检查清单

踩过几次坑之后，我给自己定了一份固定checklist，每次SOC项目做到DFT/ATPG联调阶段都会过一遍：

• 确认每个OCC的时钟源、脉冲数、bypass信号、复位逻辑，在DFT spec里均有记录。
• 确认ATPG工具里声明的capture沿数，与OCC实际脉冲配置一致。
• 确认PLL锁定时间已建模进ATPG仿真环境，ATE测试程序的lock等待宏与之一致。
• 确认门级仿真所用SDF、库文件、综合网表来自同一版本。
• 确认OCC时钟切换路径没有裸MUX切时钟，选择信号的同步逻辑和ICG俱在。
• 确认LOC/LOS模式选择已经过STA评估，SE路径的setup/hold没有暗雷。
• 确认EDT/压缩器在at-speed模式下的X-masking策略已配置，多域同时capture有对齐方案。
• 确认跨异步域路径有专门的慢速capture模式补偿覆盖。

这张清单看起来琐碎，但每一条背后都是真实项目里花过时间、烧过机时换来的教训。芯片测试的成败往往不在某一个宏大算法上，而是在这些细节交接处——OCC和ATPG各管一段，中间没人盯，迟早出乱子。