从一次流片失败复盘讲起：为什么DFT工程师必须理解时钟架构？

从流片失败案例看DFT工程师的时钟架构认知盲区

当测试团队在量产阶段发现芯片的二级PLL输出异常时，整个项目组陷入了混乱。功能模式下一切正常，但进入测试模式后，级联PLL的第二级输出时钟完全失效。这个价值数百万的流片教训，最终追溯到DFT阶段一个看似简单的OCC插入决策——工程师在UPLL1输出端直接放置了时钟控制器，阻断了UPLL2的参考时钟信号。这个典型案例揭示了DFT工作一个容易被忽视的维度：对时钟架构的深度理解不是前端设计的专属，而是DFT工程师的核心竞争力。

1. 案例复盘：级联PLL失效背后的技术真相

1.1 故障现象与问题定位

在28nm工艺节点的某款通信芯片项目中，量产测试阶段出现了一个诡异现象：当ATE机台加载扫描测试模式时，芯片的二级时钟域（由UPLL2驱动）所有寄存器均无法捕获正确数据，而功能模式下的全速测试却完全正常。故障排查过程暴露出几个关键线索：

• 测试模式专属故障：仅在扫描移位和捕获阶段出现，功能模式时钟树完全正常
• PLL行为异常：探头检测发现UPLL2输出时钟振幅不足正常值的30%
• 级联依赖断裂：UPLL2的参考时钟来自UPLL1，而OCC插入点恰好位于两个PLL之间

通过反标（back-annotation）分析发现，DFT工具在UPLL1输出端直接插入的OCC控制器，在测试模式下阻断了时钟信号向下游PLL的传输。这违反了PLL工作的黄金法则：任何PLL的参考时钟必须保持free-run特性，即使在测试模式下也不应被门控或阻塞。

1.2 OCC插入的两种方案对比

针对级联PLL结构，OCC插入存在两种典型配置方式：

正确的实现需要遵循以下物理设计约束：

# 确保隔离buffer不被综合工具优化 set_dont_touch [get_cells U1] true # 或使用尺寸锁定命令 set_size_only [get_cells U1] true

注意：即使采用层次化综合流程，也需要显式声明对隔离buffer的保护，现代综合工具的优化算法可能跨越层次边界进行优化。

2. DFT与时钟架构的耦合关系

2.1 时钟树的可测试性悖论

芯片设计中存在一个根本性矛盾：为了提升可控性和可观性，DFT需要尽可能多的控制节点；而为了保持时钟完整性，前端设计又需要尽量减少时钟路径上的干扰。这种矛盾在以下场景尤为突出：

• 多电压域芯片的时钟跨域传输
• 级联PLL结构的时钟分发网络
• 门控时钟与动态频率切换电路

OCC（On-Chip Clock Controller）作为DFT插入的时钟控制单元，其设计初衷是解决测试模式下的时钟控制问题。但不当的插入策略会导致：

1. 改变时钟路径的负载特性
2. 引入额外的时钟偏移（clock skew）
3. 破坏时钟源的稳态特性（如PLL的free-run需求）

2.2 时钟架构评审要点

DFT工程师参与时钟方案评审时，应特别关注以下维度：

时钟源特性核查清单

• [ ] 是否识别所有PLL及其级联关系？
• [ ] 每个PLL的参考时钟是否标记为free-run？
• [ ] 是否存在测试模式下需要保持活动的时钟域？

时钟路径分析矩阵

3. 预防性设计策略与实践

3.1 约束文件的精准表达

大多数DFT工具允许通过约束文件定义时钟的特殊属性。以Synopsys DFTC为例，以下命令对级联PLL场景至关重要：

# 声明PLL参考时钟的free-run属性 set_clock_sense -stop_propagation \ -clock [get_clocks UPLL2_ref] \ [get_pins UPLL2/REFCLK] # 定义OCC的安全插入区域 set_clock_controller_exclusion -no_clock_controller \ [get_nets UPLL1_OUT] \ -to [get_pins UPLL2/REFCLK]

这些约束需要与前端设计的SDC（Synopsys Design Constraints）文件协同验证，确保时序约束在测试模式下仍然有效。

3.2 物理实现的最佳实践

除了常见的buffer隔离方案，资深工程师还会采用以下防御性设计技巧：

1. 层次化隔离：将敏感时钟路径置于独立层次，避免工具全局优化
2. 金属层预留：为关键时钟线预留高层金属，减少串扰影响
3. 监控电路插入：添加测试模式下的时钟健康监测电路

例如，在FinFET工艺中可采用如下结构保护级联PLL：

UPLL1 → 金属5时钟走线 → 隔离buffer → OCC控制器 ↓ 金属6直连 ↓ UPLL2参考时钟

提示：在先进工艺节点，时钟路径的寄生参数对PLL性能影响显著，DFT插入的OCC可能改变RC特性，需要与布局工程师协同分析。

4. 跨团队协作框架构建

4.1 设计-DFT协同流程

建立高效的协作机制需要规范化的交互节点：

1. 架构阶段：DFT参与时钟方案可行性评审
2. RTL阶段：交换时钟域交叉（CDC）分析报告
3. 综合阶段：联合签核时钟约束文件
4. 物理实现：协同分析时钟树时序余量

某头部芯片公司实行的"时钟护照"制度值得借鉴：每个时钟域都有一个伴随的属性文档，记录其：

• 功能模式特性
• 测试模式需求
• 特殊约束条件
• 历史问题记录

4.2 知识体系的交叉培养

优秀的DFT团队需要具备以下跨领域知识：

• 前端方面：时钟门控策略、PLL行为模型
• 后端方面：时钟树综合、信号完整性
• 测试方面：ATE时钟激励模式、故障诊断

建议DFT工程师定期参与以下活动：

• 前端设计的时钟方案walkthrough
• 后端时钟树实现review
• 测试工程师的pattern调试session

在最近一次项目回顾中，我们发现采用这种协同模式后，时钟相关的DFT问题减少了73%，从问题发现到定位的平均时间缩短了65%。