从AND/OR Control Point到XOR Tree：深入聊聊Test Point插入的那些‘门道’与避坑指南-开发者社区

从AND/OR Control Point到XOR Tree：深入聊聊Test Point插入的那些‘门道’与避坑指南

在芯片设计的可测试性（DFT）领域，Test Point技术就像一位隐形的调音师，通过精准的电路微调让故障检测的旋律更加清晰。不同于扫描链（Scan Chain）这类基础架构，Test Point的插入往往需要工程师在微观层面做出大量权衡决策——从控制点类型的选择到时序路径的处理，每一个细节都可能成为影响测试覆盖率的关键变量。本文将带您穿透工具自动化的表象，直击Test Point技术的核心逻辑与工程实践中的真实挑战。

1. Test Point的本质与分类：超越工具手册的理解

当我们在谈论Test Point时，实际上是在讨论两种截然不同的电路干预策略：控制点（Control Point）和观测点（Observe Point）。这两种类型的Test Point在电路中的作用机制和实现方式有着本质区别：

控制点：通过强制注入特定逻辑值来打破电路中的逻辑阻塞
观测点：通过新增观测窗口来捕获原本不可见的信号状态

工具在处理这两类Test Point时的时钟选择策略就体现了它们的本质差异。控制点关注的是信号能传播到多远（fan-out cone），而观测点则关心信号从何处来（fan-in cone）。这种差异直接反映在工具的算法逻辑中：

特性	Control Point	Observe Point
时钟选择优先级	fan-out cone → fan-in cone	fan-in cone → fan-out cone
电路改造方式	插入AND/OR门	新增Scan Cell或XOR Tree
主要影响指标	故障检测概率	故障传播路径

在实际项目中，我们曾遇到一个典型案例：某SoC芯片的CRC模块由于控制点不足，导致随机模式覆盖率始终低于85%。通过针对性插入AND Control Point后，不仅覆盖率提升到92%，测试向量数量还减少了17%。

2. AND vs OR Control Point：电路语境下的智能选择

工具文档通常只会告诉你AND和OR Control Point是互斥的，但不会解释在何种电路环境下应该倾向选择哪一种。经过多个项目验证，我们发现以下规律：

AND Control Point的最佳应用场景：

信号路径上存在强"0"敏感逻辑（如宽位与门）
需要打破由时钟门控引起的逻辑冻结
处理多路选择器（MUX）的控制信号隔离

// 典型AND Control Point插入示例 assign signal_out = (test_mode & tp_and_en) ? 1'b0 : original_signal;

OR Control Point的适用条件：

信号路径上存在强"1"阻塞（如级联或门）
需要绕过复位信号对数据路径的影响
处理带使能端的寄存器阵列

一个容易踩坑的场景是处理带异步复位的设计。我们发现，如果在异步复位路径上错误地插入AND Control Point，反而会引入新的测试盲区。这时改用OR Control Point配合适当的时序约束才是正解。

3. XOR Tree的隐藏成本：共享Scan Cell的得失权衡

当工具提示"多个Observe Point将共享Scan Cell"时，有经验的工程师会立即警惕起来。XOR Tree虽然节省了面积，但会带来三个常被忽视的问题：

故障混淆效应：多个观测点的信号通过XOR合并后，特定故障模式可能相互抵消
测试时间开销：需要额外的移位周期来隔离特定观测点
功耗激增风险：XOR Tree在capture阶段可能引发局部高电流

在28nm工艺的一个视频处理芯片项目中，我们曾遇到XOR Tree导致测试功耗超标的情况。通过以下调整解决了问题：

# Tessent中限制XOR Tree规模的配置 set_test_point_configuration -max_xor_fanout 4 -observability_only

建议在布局布线（P&R）前进行早期功耗分析时，特别关注以下指标：

XOR Tree驱动的Scan Cell数量
预计的toggle rate
电源网络在该区域的裕量

4. 时钟域处理的特殊挑战：当工具决策不够智能时

Test Point的时钟选择看似由工具自动完成，但在混合时钟域设计中，默认算法经常做出次优选择。我们总结出以下需要人工干预的场景：

跨时钟域处理清单：

识别位于时钟域交叉点的Test Point候选
验证工具选择的时钟是否与物理实现一致
检查异步时钟域之间的时序余量
确认测试模式下不会引入新的时钟竞争

在40nm无线通信芯片的案例中，工具自动为某个Control Point选择了错误的时钟域，导致ATPG阶段出现大量不可测故障。通过手动指定时钟解决了问题：

set_test_point_clock -point [get_pins U123/A] -clock CLK_MAIN

对于包含PLL和时钟门控的设计，建议在Test Point插入后专门进行时钟一致性检查，包括：

所有Test Point时钟与驱动Scan Cell时钟的相位关系
测试模式下时钟门控的默认状态
跨电压域的时钟路径处理

5. 黑盒与Non-Scan单元的应对策略

面对设计中的黑盒（Black Box）和Non-Scan单元，Test Point插入需要特殊处理。常见的误区包括：

未正确定义黑盒边界导致工具误判可控性
忽略Non-Scan寄存器的保持时间要求
未考虑模拟模块对数字Test Point的影响

在某汽车MCU项目中，由于未正确定义电源管理单元（PMU）为黑盒，导致工具试图在模拟信号路径上插入数字Test Point。通过以下配置避免了这个问题：

add_black_boxes PMU_TOP -type analog add_nonscan_instances [get_cells -hier *battery_monitor*]

对于包含嵌入式存储器的设计，建议采用分层Test Point策略：

首先处理存储器的输入/输出隔离
然后优化存储控制器周围的观测点
最后处理存储阵列间的控制信号

6. 模式数量与覆盖率的平衡艺术

Test Point对测试模式数量和覆盖率的影响并非线性关系。我们的实验数据显示：

前20个Test Point通常能带来显著的覆盖率提升（5-15%）
后续增加的Test Point收益会逐渐递减
超过某个临界点后，模式数量反而可能增加

在65nm物联网芯片的测试中，我们开发了一套评估框架来优化Test Point数量：

# 伪代码：Test Point效益评估模型 def evaluate_test_point(tp_candidate): coverage_gain = estimate_coverage_improvement(tp_candidate) pattern_impact = calculate_pattern_impact(tp_candidate) area_cost = calculate_area_overhead(tp_candidate) return (coverage_gain * 0.6) - (pattern_impact * 0.3) - (area_cost * 0.1)

实际项目中，建议采用增量插入策略：