做SOC芯片DFT时间长了我越来越觉得OCC和ATPG的协同才是at-speed测试里最容易被低估的一环。早年很多人以为DFT就是把扫描链插好、stuck-at覆盖率做到98%就能收工直到碰上小延迟缺陷逃逸到客户现场才回头去琢磨OCCOn-Chip Clock Controller和ATPGAutomatic Test Pattern Generation之间的配合。这篇文章不打算重复教科书里的定义而是从一个DFT/测试工程师的视角把OCC的电路结构、ATPG的故障模型、多时钟域的时钟分组以及两者联调时的典型翻车现场串起来讲一遍。适合正在做DFT实现、后端时钟树设计、ATE测试程序开发的工程师参考也适合刚入行、想搞明白“为什么芯片要跑at-speed capture”的朋友。1. 从一颗实测失效率的芯片说起stuck-at全过为何还会翻车1.1 静态故障测不出来延迟类缺陷才是常态我三年前接手过一颗28nm的SoCATE上全芯片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可能跑800MHzDisplay 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、sescan 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脉冲的用法分成两种一个叫LOCLaunch Off Capture一个叫LOSLaunch 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脉冲数要求不一样我整理了一张表团队里新人都先看这个故障模型需要at-speed吗需要的capture沿/脉冲数主要覆盖目标stuck-at fault否1个沿慢速即可短路、开路、固定电平缺陷transition fault是2个沿launchcapture门延迟、连线延迟、小延迟缺陷path delay fault是2个沿且要沿特定路径关键路径时序裕量不足cell-internal fault视库而定通常2个沿单元内部特定缺陷理论上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多时钟域的SOCOCC分组与ATPG约束要一起定4.1 时钟分组不是后端一个人的事SOC的DFT时钟分组经常被误以为只是后端CTS的事。实际上CTS关心的是时钟树的skew和latency但DFT关心的是哪个时钟域能在capture阶段同时处于高速状态、哪个域必须保持慢速或停振。这两个维度必须对齐。我习惯的做法是把芯片的时钟域按“能否安全同时at-speed capture”分组。简单示例DFT测试模式参与at-speed capture的时钟域时钟源主要测试目标slow_scan全部域慢速captureATE时钟/OCC bypassstuck-at基础扫描链fast_cpu_busCPU、总线、互连PLL0CPU总经路径transitionfast_gpuGPU、NPUPLL1/PLL2大算力域transitionfast_mem_intfDDR控制器及相关PHYPLL3内存接口时序async_brdg跨异步桥逻辑PLL0 慢速时钟补偿跨域胶水逻辑覆盖率这个分组表不是随便拍的。CPU和总线如果频率比例固定、相位关系由同一个PLL分频出来就可以放进同一组同时captureGPU和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 captureATPG工具要么把跨域路径全设成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频率。假设扫描链深度8000shift频率25MHz单个vector的shift时间就是8000/25MHz320us5000个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各管一段中间没人盯迟早出乱子。