走一条 TAP 进来的时钟链在 CGBClock Gating Block里完成分频、门控、状态复位的编排。标准 OCC 的标准在于它把你需要的一整套时钟协议都暴露出来支持capture_enable、shift_enable两个主控信号分别对应捕获与移位模式内部带可配置计数器能够精确控制捕获脉冲个数最常用的就是“1 个 capture pulse”和“2 个 capture pulse”两种模式对每个时钟域独立产生使能信号时钟域之间可以做到不同脉冲个数、不同延迟对齐支持 OCC 复位信号和事件同步保证跨时钟域捕获时的确定性。面积和复杂度同样也“标准”一个标准 OCC 往往要占用几百个单位门时钟资源多的时候每个时钟域都要一套脉冲控制和同步逻辑。更麻烦的是如果芯片里有几十个时钟域全都上标准 OCC 会让 DFT 逻辑的面积和走线压力都很大。后面我在做大芯片项目时一般只会把标准 OCC 花在最重要的那几条关键路径和高速接口时钟上。同步 OCC 则是一个明显向面积和复杂度妥协的方案。它把多时钟域的捕获控制简化成“同步启动”模式所有绑定的时钟域在捕获阶段由同一个sync_capture_enable统一拉高大家几乎同时发出各自的 capture pulse。因为少了逐域独立的计数器配置和大量同步握手同步 OCC 的门数大约只有标准 OCC 的一半甚至更低。但同步 OCC 的可控性也相应下降主要体现在三个方面首先是无法对单个时钟域设置不同的脉冲个数要么全部打一拍要么全部打两拍其次是时钟域之间完全靠时钟关系对齐如果两个时钟不是同源或没有明确相位关系很容易在捕获窗口上出现偏差最后是同步 OCC 对异步跨时钟域路径的支持比较弱需要额外的同步器辅助不然测试覆盖率会掉得很难看。所以同步 OCC 更适合那些时钟结构规整、路径关系明确的 SoC 模块比如总线互联、存储控制器里的低频时钟域。Mini OCC 则是最近几年在面积敏感的 DFT 方案里非常吃香的选择。它不是对同步 OCC 的简单缩小而是把 OCC 的核心功能压缩到极限只保留最基础的单脉冲捕获、单个时钟域控制、以及一个精简的scan_enable同步逻辑。Mini OCC 的典型门数只有标准 OCC 的三分之一左右甚至可以做到更小。代价也很直白Mini OCC 没有多个捕获脉冲配置没有跨时钟域对齐能力一般也不支持作为 3D-IC 测试中 die-to-die 时钟的捕获控制器。它适合的场景非常明确——大量低频、单时钟域、路径余量充足的模块例如 GPIO 控制器、低速外设、电源管理子系统的扫描测试。从成本角度Mini OCC 的意义其实很大很多 SOC 里 60% 以上的时钟域都属于低频、简单、风险低的类型用 Mini OCC 把这些域全部覆盖住可以把 DFT 面积和布局拥塞降低一个明显的数量级。从选择角度我自己的口诀是关键路径、高速接口、跨时钟域对齐上标准 OCC时钟规整、低频模块上同步 OCC单时钟域、面积优先、低频小模块上 Mini OCC。3. SSN 到底改变了什么从扫描端口到串行网络SSN 的全称是 SmartScan Network这个功能近几年在很多项目里几乎是绕不开的关键词尤其是用 Tessent 做 DFT 的老用户基本都认可它是压缩 IO、降低测试时间和提高测试质量的综合解。传统扫描测试中一个 64 位的扫描链组需要 64 根甚至更多数据线连到 SoC 顶层外加每个扫描链的 shift enable、capture enable 控制信号以及大量观察端口。随着芯片规模扩大这样的并行扫描端口会让后端布线压力巨大测试 IO 面积损耗也很严重。早期我做过一个大概 40 多个扫描域的设计光 DFT 端口就占用了顶层 300 多根引脚封装出来以后测试资源严重浪费。SSN 的核心思路是不再把每个扫描链独立引到顶层而是通过一个串行化的网络接口把扫描数据的装载和卸载统一管理起来。每个扫描域内部依然有完整的扫描链但对外只有一个串行端口。测试数据按帧格式逐 bit 送入 SSN Controller再由控制网络分配到各扫描域回收数据同样以串行形式读出。这样做带来的好处非常明显测试 IO 大幅减少。典型 SOC 可以把 DFT 顶层端口从几百根压缩到几十根甚至十几根测试功耗显著下降。并行扫描切换产生的动态功耗集中在 SSICSSN 内部控制器和少量网络上各扫描域只在必要时刻被激活测试时间更可控。SSN 支持多链并行装载与压缩回读配合 EDTEmbedded Deterministic Test可以做到比传统多链并行方案更高效的压缩率。SSN 与 OCC 的集成说白了就是在扫描捕获阶段OCC 负责发时钟脉冲SSN 负责控制这个时钟脉冲何时被实际上送到扫描链上。两者是协同关系不是替代关系。实际操作里一个典型的 Tessent SSN 接 OCC 的层次关系大概是这样的顶层测试控制器Top-level Test Controller由 Tessent SSN 工具自动生成每个测试域内部有独立的 OCC 实例OCC 控制该域内扫描触发器的捕获时钟SSN 控制器通过occ_enable、capture_enable信号把捕获指令下发到 OCCOCC 收到使能后根据配置产生精确的 capture pulse驱动扫描链进入捕获态。这个设计里最容易出问题的点是SSN 控制器的时序和 OCC 的异步启动之间的握手。如果捕获使能信号到达 OCC 的时间和 OCC 内部同步器的建立时间窗口不匹配捕获窗口就可能偏移。后面我会专门讲到用 BFM 解决这类问题的思路。4. OCC 与 SSN 集成实操从配置到生成4.1 初始化 DFT 配置文件Tessent 集成 OCC 和 SSN 需要一套完整的 DFT 规格说明书Spec一般是以Tessent shell的 Tcl 命令写成。最开始我用的时候最常犯的错就是把 OCC 当作普通的时钟门控单元直接往 netlist 里塞结果后面 run 起来各种 timing violation。正确的做法是在 DFT Specification 里以set_db的方式显式声明 OCC 类型和时钟关系。核心配置项大概是这样# 创建测试时钟域 create_test_clock domain1 -period 10.0 -waveform {0 5} create_test_clock domain2 -period 7.5 -waveform {0 3.75} # 声明 OCC 类型 set_db design:chip.occ_type standard set_db design:chip.occ_clocks {domain1 domain2} # 使用 SSN 作为扫描网络 set_db design:chip.tessent_ssn_enable true set_db design:chip.ssic_cells {ssic1 ssic2}需要特别说明的是occ_type这个属性决定了后面insert_dft命令生成 OCC 的方式。有同事问过我“为什么我明明在 RTL 里手工例化了 OCC工具还是给我插了一套新的”原因就是occ_type没有设置成 manualTessent 默认会自己往扫描链上补 OCC。4.2 三种 OCC 的针对性配置在同一个 SOC 里混用标准、同步、Mini OCC 是完全可以的关键是配置要分别落到各自的时钟域上。标准 OCC 的完整配置我做了一个简化示例set_db design:top.u_ahb.occ_type standard set_db design:top.u_ahb.occ_mode dual_pulse set_db design:top.u_ahb.occ_capture_enable edge_sensitive这里的dual_pulse就表示捕获阶段输出两个时钟脉冲对应 at-speed 测试里常用的“loadmeasure”双拍模式。edge_sensitive指定捕获使能由边沿触发这是为了保证 SSN 下发的 capture_enable 能够被精确采样。同步 OCC 的配置只需要绑定到主时钟上附属时钟域全部跟随主时钟启动set_db design:top.u_bus_sync.occ_type synchronous set_db design:top.u_bus_sync.occ_master_clock domain1 set_db design:top.u_bus_sync.occ_sync_clocks {domain1 domain2}Mini OCC 的配置更简单基本上只需要指定时钟域和捕获模式set_db design:top.u_gpio.occ_type mini set_db design:top.u_gpio.occ_capture_mode single_pulse在实际项目中真正能提升质量的反而是这些配置之外的细节。一个容易踩的坑是同步 OCC 和 Mini OCC 对于 SSN 网络的capture_enable信号默认不做异步同步处理。如果你的 SSN 时钟和被测时钟域是异步关系必须在 OCC 内部加一个同步器或者直接绑定到scan clock 上否则会在高速捕获时出现概率性的时序失败。4.3 生成 OCC 和 SSN 网表配置写好后运行插入流程Tessent -shell insert_dft.tcl工具会根据 spec 自动生成 OCC 逻辑、SSN 控制器、SSIC 以及顶层 IO 接口。生成完以后我一般会做三件事检查生成的 OCC 数量和类型是否和预期一致检查 SSN Controller 是否被正确连接在 OCC 和扫描链之间检查顶层测试 IO 列表中是否同时出现了occ_capture_enable和ssn_data_in/out信号。这三项任何一个对不上后面 99% 都会出 scan shift 或 capture 的问题。4.4 手动插入 OCC 的兼容性问题有些老项目或者某些特定 IPDFT 工程师会坚持在 RTL 里手动例化 OCC。Tessent 并不排斥这种做法但你必须保证手动例化的 OCC 接口符合工具对 OCC 的预期模型。需要手动例化 OCC 的场景主要包括两大类一类是第三方 IP 自带原子时钟控制逻辑工具无法从 RTL 推断另一类是某些超高速接口比如 HBM 或 PCIe PHY时钟控制时序要求极其苛刻工具自动插入的 OCC 无法满足 delay 约束。我见过最惨的一次是一个团队在 HBM 接口上手动例化了标准 OCC但忘记手动例化同步 OCC 需要的跨时钟域握手逻辑结果 at-speed 测试覆盖率只有预期的一半。后来排查了很久才发现 OCC 输出的 capture pulse 和 SSN 控制器的使能信号之间有个亚稳态问题。从这个角度讲手动 OCC 并不是不行但必须把配套的同步逻辑一起做完整。5. BFM/BFD 与 OCC 验证确认你的 OCC 真的在干活写 OCC 配置容易但验证 OCC 到底有没有按预期工作才是真正见功力的时候。这几年我在项目里用ssn bfmBus Function Model和bfdBus Function Diagram做 OCC 行为级验证比较多这里整理一套可靠的流程。5.1 BFM 是干什么的BFM 是验证领域的老概念全称是 Bus Function Model初代主要是为总线协议模拟服务的。Tessent 把 BFM 用到了 SSN 和 OCC 的验证中本质上是用一套行为级模型来模拟 SSN Controller 和 OCC 之间的信号交互时序。为什么需要 BFM因为直接在任何网表上做 OCC 波形级仿真很慢特别是芯片规模几十亿门的时候跑一次模拟几个小时起步。BFM 替代了真实的 SSN 内部逻辑只保留接口行为仿真速度提高一到两个数量级。同时因为 BFM 是行为模型你可以在时序、状态跳转上做非常细致的检查。BFD 则是描述这些行为图形的工具或格式它把 OCC 的使能、捕获、释放流程用状态图方式定义出来再映射成 BFM 模型。简单理解BFD 是图BFM 是执行引擎。5.2 用 BFM 验证 OCC 的关键步骤在实际项目中我会在仿真环境里把 OCC 和 BFM 对接按下面几个步骤做验证。第一步在 DFT 配置里开启 BFM 测试模式set_db design:top.tessent_ssn_bfm_enable true set_db design:top.tessent_occ_bfm_enable true第二步在测试平台里加载 BFM 例化文件。Tessent 会生成对应的ssn_bfm和occ_bfm的 SystemVerilog interface你在 testbench 里例化它们并把 OCC 的输入输出接上去。第三步设计测试用例。最常见的用例是先断言移位移位模式验证scan_enable1时 OCC 输出保持为移位时钟然后切换捕获模式验证capture_enable上升沿之后 OCC 输出的 capture pulse 个数和周期是否符合配置验证释放时序是否干净没有毛刺或半脉冲。从我自身经验看最容易在 BFM 验证阶段暴露的问题有三个使能信号到达时间不稳定。capture_enable在 OCC 内部同步器上的建立时间不足导致有些仿真 run 捕获一个脉冲有些 run 捕获两个跨时钟域握手信号丢失。同步 OCC 里主从时钟域之间的握手信号在低功耗关断后被拉低了导致捕获时钟悬挂SSN 回读数据错位。OCC 的捕获窗口和 SSN 的数据装载窗口之间有一个时钟周期的错位如果不做ssn_occ_skew_check回读数据会出现整周期偏移。第三类问题尤其容易被忽略因为从波形上看每个信号都对但最终测试程序测试结果在十几个 die 上概率性失败。加了ssn_occ_skew_check以后工具会检查 OCC 捕获完成信号与 SSN 数据回读起始信号之间的周期关系帮助快速定位偏移来源。5.3 通过 BFD 来约束期望行为BFD 在 Tessent 中的使用方式是给验证人员一个形式化的 OCC 行为定义。你可以在 BFD 里指定 OCC 的状态机跳转条件然后由工具转化为可执行的 BFM。例如标准 OCC 的 BFD 里可以定义空闲态scan_enable0capture_enable0移位移位态scan_enable1时钟直通捕获态scan_enable0capture_enable1经过irun周期后输出捕获脉冲完成态捕获脉冲结束回空闲。如果你在 BFD 里定义的状态跳转与网表中的真实逻辑不一致工具会给出 mismatch report。这一层形式化的检查是网表仿真的有力补充因为它可以直接证明你定义的协议在逻辑上没有死锁或意外路径。5.4 BFM/BFD 使用过程的性能提示BFM 不是万能的。有些团队图省事希望用 BFM 覆盖所有 scan chain 的行为结果反而把验证周期拉长了。我的建议是BFM 只做控制时序验证扫描数据路径仍然用正常的 SDF 仿真。这样既保证了控制信号的精确性又避免行为模型掩盖真实物理路径上的建立/保持违例。6. 项目实战中的常见问题与定位思路6.1 捕获脉冲个数不对我在多个项目里都遇到过同一个诡异问题OCC 配置为单脉冲捕获但实际波形上出现了两个脉冲。最初怀疑是 OCC 内部计数器翻转问题后来发现根因是配置里同时使能了 EDT 的 capture 窗口Tessent 在 EDT 侧又额外交代了一次捕获。两个使能叠加计数就翻倍了。排查思路查看 Tessent 生成的occ_report中捕获脉冲个数检查 EDT 的edt_capture_mode是否和 OCC 的capture_mode冲突检查 SSN 的capture_enable到达 OCC 时OCC 内部是否还处于复位未释放状态。6.2 扫描移位模式下 OCC 输出悬空这个问题一般出现在 Mini OCC 上。因为 Mini OCC 为了省面积只在捕获模式时接入原始时钟移位模式下默认由扫描时钟直接驱动。如果你在 RTL 里没有把扫描时钟连到 Mini OCC 的输入移位阶段 flip-flop 的时钟就会悬空。定位方法很简单直接看波形移位模式下扫描时钟上无翻转就是输入没连上。6.3 SSN 回读数据与 at-speed 捕获结果不匹配这个问题的症状是仿真时 OCC 捕获的数据明明正确但 SSN 回读出来的 pattern 错了一整段。原因一般不是数据路径而是ssn_unload窗口没有和 OCC 捕获完成信号对齐。常见解决办法是在 OCC 和 SSN 之间加一个ssn_unload_sync寄存器或者把ssn_unload_start延迟一个周期让 SSN 等 OCC 稳定后再读数据。6.4 低功耗域关断后 OCC 无法复位现代 SoC 都有多电压域。当某个低功耗域被电源关断后再唤醒OCC 的复位信号可能被埋在断电域里导致唤醒后 OCC 状态未知。这个问题在扫描链上会表现出随机失败且很难复现。建议在 OCC 设计阶段就把复位信号处理成“异步复位、同步释放”并且保证这个复位信号由常开电源域产生。如果做不到至少要在 SSN 控制器的复位树里加入断电域的隔离逻辑。针对这个问题我在一个车规级项目里吃过很大的亏前前后后花了整整一周才定位。后面我做法就改变了凡是 OCC 挂在低功耗域上的统一额外接一个always_on_reset信号并在 DFT 验证用例里专门加一个“断电域唤醒后捕获”的回归测试。6.5 如何快速定位 OCC 是否正常三条命令对于已经跑起来的项目我建议每次插入 OCC 后都第一时间跑三条命令来确认基础状态# 检查 OCC 类型和时钟连接 report_occ -clock_tree # 检查 SSN 控制器与 OCC 之间的使能连接 report_ssn_connectivity -type occ # 检查捕获使能时序关系 report_occ_capture_check -verbose这三条命令的输出如果全部 clean再往下跑 scan chain 和 pattern 才有意义。7. 经验与建议从工具走向方法论Tessent OCC 和 SSN 的组合用熟了以后我越来越觉得这类 DFT 工具的核心价值并不在于“自动生成”而在于你如何设计出与物理实现匹配的时钟控制策略。OCC 类型的选择不是越高级越好而是要根据时钟结构、功耗域、测试覆盖需求综合权衡。从我自己的项目经验看一个比较靠谱的实践方法是在 DFT 规划阶段就做一张“OCC 选型矩阵”把每个时钟域的类型、频率、功能、低功耗属性、at-speed 测试需求全部列出来逐项决策该用标准、同步还是 Mini。多数项目在早期缺少这种表格结果到了后端流程发现 DFT 面积超标再回头换 OCC 类型不仅重跑时间长还容易引入新的时序问题。另外想专门提一下ssn bfm和bfd的重要性。很多工程师忙于跑工具流程很少愿意花时间搭建一个完整的 BFM 验证环境。但我的实际经验告诉我最贵的 bug 从来不是工具报出来的而是在仿真或者 silicon bring-up 阶段才暴露出来的 OCC 时序问题。有了 BFM/BFD 这套行为级验证手段相当于给 OCC 加了一层低成本、高覆盖的安全网。后续如果有机会我还会再写一篇关于 SSN 与 EDT 联合压缩、以及如何优化 at-speed pattern 生成的实操笔记。老规矩有问题欢迎留言讨论能帮到的我一定知无不言。