避坑指南：用DFTC做OCC时钟控制，千万别让级联PLL‘饿死’（附Hierarchy Flow建议）

避坑指南用DFTC做OCC时钟控制千万别让级联PLL‘饿死’附Hierarchy Flow建议在数字电路设计的DFTDesign for Testability流程中OCCOn-Chip Clock Controller的正确配置对于测试模式的可靠性至关重要。特别是当设计涉及级联PLL结构时一个常见的陷阱是PLL因参考时钟被意外阻断而饿死——这种现象会导致测试模式下时钟网络完全失效。本文将从一个真实的项目调试案例出发剖析级联PLL时钟树中的OCC配置陷阱并分享如何通过层次化设计流程从根本上规避这类问题。1. 级联PLL时钟网络的OCC陷阱解析当设计中存在多个级联的PLL时每个PLL的参考时钟必须保持自由运行free-run状态。这意味着在测试模式下参考时钟路径不能被任何逻辑包括OCC控制器阻断。图1展示了一个典型的级联PLL结构[时钟网络示意图] UPLL1 (主PLL) → UPLL2 (次级PLL) ↘ 时钟分频器在这种结构中常见的错误OCC插入方式有两种致命错误在UPLL1的输出端直接插入OCC控制器后果UPLL2的参考时钟被阻断导致PLL失锁现象测试模式下次级时钟域完全失效次优方案仅在UPLL2的输出端插入OCC问题主时钟域缺乏测试控制风险测试覆盖率下降正确的做法是在UPLL1的输出端添加隔离缓冲器如buffer U1然后将OCC控制器插入到缓冲器下游。这种配置既保证了测试控制能力又确保了UPLL2的参考时钟自由运行。2. 隔离缓冲器的关键实现细节隔离缓冲器的实现看似简单但在实际综合过程中极易被优化工具误删。以下是确保缓冲器保留的三种方法对比方法命令示例适用场景注意事项set_dont_touchset_dont_touch U1后期ECO阶段可能影响时序优化灵活性set_size_onlyset_size_only -cells U1面积敏感设计仅阻止尺寸变化不防逻辑优化Hierarchy Flow模块级综合策略早期架构规划需要设计阶段提前规划其中hierarchy synthesis flow是最彻底的解决方案。通过将不同时钟域划分为独立模块并在模块边界保留必要的缓冲结构可以从架构层面避免优化冲突。例如# 层次化综合示例 create_block -name CLOCK_MODULE -boundary [get_pins UPLL1/OUT] set_boundary_optimization CLOCK_MODULE false3. 层次化设计流程的实践优势相比传统的扁平化flat综合流程层次化设计在解决OCC级联问题上具有显著优势物理隔离保障模块边界天然形成优化隔离区时钟域清晰划分每个PLL及其相关逻辑可独立优化团队协作便利不同时钟域可由不同工程师并行开发实施层次化流程时建议采用以下步骤在RTL设计阶段明确定义时钟域模块为每个含PLL的模块创建专用wrapper在综合脚本中设置适当的boundary优化约束使用-boundary_optimization false保留关键接口逻辑4. 调试技巧与验证方法当遇到PLL饿死问题时可通过以下流程快速定位模式验证report_clock -test [all_clocks] check_test_clock_structure信号追踪确认所有PLL的REFCLK在测试模式下保持活跃检查OCC控制信号的传播路径波形验证在ATE测试模式下捕获PLL锁定状态测量各时钟域的启动时序一个实用的调试技巧是临时插入时钟观测点// 示例插入时钟观测逻辑 assign probe_clk UPLL1_OUT test_mode;5. 架构层面的预防性设计为避免后期DFT插入时的时钟问题建议在项目初期就考虑以下架构决策时钟树类型选择对于复杂级联PLL采用混合树Hybrid Tree结构OCC规划在架构文档中明确标注各OCC的控制范围模块划分将具有严格时序要求的路径置于同一综合边界内在最近的一个7nm项目实践中我们通过提前实施层次化时钟架构将DFT插入阶段的时钟问题减少了70%项目周期缩短了2周。关键经验是时钟问题越早考虑后期代价越小。