芯片设计后期DFT友好ECO：原理、实践与工具选型

1. 项目概述：当功能修复遇上可测性设计

在芯片设计的后期，尤其是流片前的最后阶段，工程师们最怕听到的词可能就是“Bug”和“ECO”。前者意味着设计有误，后者则代表着一次“工程变更指令”。如果说发现Bug是晴天霹雳，那么执行一次不恰当的ECO，可能就是雪上加霜，因为它可能悄无声息地破坏掉另一个至关重要的设计属性——可测性。今天，我们就来深入聊聊什么是“DFT友好的功能ECO”，以及为什么它在现代芯片设计中，尤其是汽车电子、数据中心等对可靠性要求极高的领域，已经从一个“加分项”变成了“必选项”。

简单来说，DFT友好的ECO，就是在对芯片网表进行功能性修改和修复时，能够确保芯片原有的可测试性设计结构完好无损的一套方法论和工具实践。它要求工程师在进行任何逻辑增减、寄存器替换、连线调整时，都必须像保护眼睛一样，保护扫描链的完整性、时钟与复位信号的可控性，以及所有DFT模式切换逻辑的正常工作。我经历过不止一个项目，因为一个看似微小的ECO操作，导致ATPG覆盖率掉了零点几个百分点，最终不得不额外增加一轮测试向量调试，耽误了宝贵的上市时间。因此，理解并实践DFT友好的ECO，不是纸上谈兵，而是真金白银的效率和成本考量。

2. DFT与ECO：一对需要精心平衡的伙伴

2.1 芯片可测性设计的核心支柱

在深入ECO之前，我们必须先理解DFT在芯片中扮演的角色。你可以把DFT想象成给芯片植入的一套“内置自检系统”。当芯片制造出来，我们无法像软件调试一样设置断点、单步执行，只能通过外部引脚输入特定的测试向量，并观察输出。DFT技术，特别是基于扫描链的设计，将芯片内部成千上万个时序逻辑单元（主要是寄存器）串联成一条或多条“扫描链”。在测试模式下，这些寄存器不再执行正常功能，而是变成一个超长的移位寄存器。

测试时，我们通过扫描输入端口将测试向量“串行移位”灌入所有寄存器，然后切回功能模式运行一个时钟周期，捕获故障响应，再切回测试模式将结果串行移出检查。这套机制的核心支柱有三：

1. 扫描链完整性：所有需要测试的寄存器都必须正确地首尾相连，形成无断裂的链。
2. 时钟与复位可控性：在测试模式下，必须能独立、稳定地控制扫描链的移位时钟和功能时钟，并能将电路置于确定的初始状态。
3. 模式隔离：必须确保功能逻辑和测试逻辑在各自模式下互不干扰，通常通过scan_enable,test_mode等信号严格切换。

任何破坏这三条中任意一条的修改，都会直接导致芯片无法被有效测试，或者测试覆盖率大幅下降，使得有缺陷的芯片流入市场风险激增。

2.2 功能ECO的典型场景与潜在冲突

ECO通常发生在设计流程的末端，此时物理布局布线已经完成，甚至光罩已经制作。进行ECO的原因多种多样：可能是逻辑功能错误、时序违例修复、功耗优化，或者应对最新的协议变更。ECO的粒度可大可小，小到替换一个驱动能力不足的缓冲器，大到增加一个状态机或数据通路。

然而，正是这种在“固化”设计上的“外科手术”，极易与DFT结构发生冲突：

• 逻辑插入切断扫描链：最常见的场景。如果你在两个相邻的扫描寄存器之间插入了组合逻辑，而工具没有识别并处理，那么扫描链的移位路径就被阻断了。
• 寄存器类型转换的副作用：将普通寄存器改为带异步复位/置位的寄存器，或者反之，如果处理不当，新寄存器可能没有被纳入扫描链，或者其复位/置位端在测试模式下被意外激活。
• 新逻辑对DFT控制信号的干扰：新增的逻辑可能无意中驱动了scan_enable信号或其相关逻辑，导致测试模式切换异常。
• 工具自动化带来的“想当然”错误：一些ECO工具为了追求逻辑等效性，可能会选择非DFT友好的连接方式，例如从多路选择器的非测试路径上取信号，破坏了测试模式下的可控性。

注意：许多工程师有一个误区，认为只要在ECO时把test_mode或scan_enable信号拉成非活动值（通常是0），就能屏蔽所有DFT问题。这只解决了模式隔离问题，但无法解决扫描链物理连接被破坏、或新增寄存器未接入链的根本性问题。后者需要工具或流程有意识地去维护。

3. DFT不友好ECO的典型案例与破坏性分析

3.1 案例一：扫描链的无声断裂

原始描述中提到了在相邻寄存器B_REG和C_REG之间插入组合逻辑的例子。这里我们展开分析一下其破坏性。假设原始扫描链片段为：A_REG[SO] -> B_REG[SI]->B_REG[Q] -> C_REG[SI]->C_REG[Q] -> D_REG[SI]。其中C_REG可能因为某些设计原因（如处于关键时序路径）被标记为非扫描寄存器，但由于B_REG的Q直接驱动C_REG的SI，扫描数据流在形式上仍能通过。

当ECO在B_REG和C_REG之间插入一个组合逻辑块（比如一个与门）时，连接变为：B_REG[Q] -> 与门 -> C_REG[D]。此时，从B_REG到C_REG的扫描路径彻底消失了。ATPG工具在插入测试向量时，无法将值移入C_REG；在捕获响应后，也无法将C_REG的值移出。C_REG及其后面的所有逻辑都变成了测试的“盲区”。

更糟糕的是，如果ECO工具没有DFT感知能力，它可能根本不会报告这个错误。逻辑等效性检查也会通过，因为从功能上看，组合逻辑的插入是正确的。这个问题只有在运行DFT规则检查或ATPG时才会暴露，此时修复成本极高。

实操心得：在进行任何涉及寄存器间路径的ECO时，第一反应应该是检查这两个寄存器是否属于同一条扫描链。如果是，必须采用DFT友好的插入策略，例如将C_REG转换为扫描寄存器，并将新逻辑旁路在扫描路径之外，或者重新规划扫描链的走线。

3.2 案例二：信号选择的“等效陷阱”

图4的例子非常经典地说明了“逻辑等效”不等于“DFT等效”。一个寄存器需要驱动复位信号，有两个候选来源：多路选择器的输入mux_in和输出mux_out。在功能模式下，当选择信号固定时，两者确实等效。

但在DFT模式下，情况截然不同。scan_mode信号会改变多路选择器的选择端，使其选择扫描输入路径。如果ECO工具选择了mux_in作为复位源，那么在测试模式下，这个复位信号将受到扫描数据流的干扰，变得不可预测，可能导致整个扫描链或部分逻辑被意外复位，测试完全失败。而选择mux_out则是安全的，因为在测试模式下，多路选择器会被配置为让扫描路径通过，其输出是受控的扫描数据。

排查技巧：对于驱动时钟、复位、使能等全局或关键控制信号的ECO网线，必须追溯其来源。如果来源是一个多路选择器、与门、或门等受测试模式控制的逻辑单元，务必确认在scan_mode=1和scan_enable=0/1的各种组合下，该信号的行为是否符合测试要求（通常是保持恒定或可控）。一个简单的检查方法是，在ECO工具中设置DFT模式约束后，再进行逻辑锥的追溯和选择。

3.3 案例三：寄存器类型转换的“画蛇添足”

将可复位寄存器转换为可置位寄存器，听起来只是改变寄存器的配置属性。但如原始描述中Conformal ECO工具的做法所示，它没有直接替换实例，而是新增了一个reg1_1，让旧的reg1去驱动扫描链。这造成了双重灾难：

1. DFT覆盖率损失：新增的reg1_1不在任何扫描链中，它存储的状态在测试时既不可控也不可观测。如果设计中有大量此类转换，ATPG覆盖率会出现明显的、难以解释的下降。
2. 形式验证混乱：逻辑等效性检查工具无法将reg1_1识别为reg1的等价点，导致报告大量非等价比较点，极大地增加了验证工程师的工作量，并可能掩盖真正的逻辑错误。

正确的做法应该是像GOF工具所示范的，直接修改原寄存器实例的lib cell类型，从复位寄存器换为置位寄存器，并确保其扫描端口（SI, SO, SE）的连接保持不变。这要求ECO工具和标准单元库支持这种“原位类型转换”，并且能正确处理复位/置位信号在测试模式下的绑定（通常绑定到非活动值）。

3.4 案例四：新增寄存器的“链外孤儿”

这是功能ECO中最常见也最容易被忽视的问题。为了修复功能或满足时序，设计增加了新的寄存器。如果这些寄存器没有被纳入扫描链，它们就成了“链外孤儿”。ATPG工具无法直接控制或观察它们，只能通过影响其上下游的组合逻辑来间接测试，覆盖率自然大打折扣。

原始描述给出了一个量化的影响：在10万寄存器的设计中，100个非扫描寄存器会导致超过0.1%的覆盖率损失。对于追求99%+测试覆盖率的汽车芯片，这是不可接受的。因此，“凡新增，必入链”应成为一条铁律。

4. 实现DFT友好ECO的工程方法与脚本实践

4.1 方法论：预防、检测与修复

要实现DFT友好的ECO，需要一个系统性的方法，而不是依赖工程师的临时检查。

1. 预防阶段（ECO制定时）：

   • DFT约束导入：在启动ECO工具时，必须将DFT约束文件（如SDC中的set_scan_configuration、set_dft_signal等）以及扫描链定义文件一并导入。让工具从一开始就知道哪些是扫描链、测试信号。
   • 识别DFT关键网络：工具应自动识别出scan_enable,test_mode,scan_in,scan_out以及所有时钟和异步复位/置位网络，并将其标记为“受保护”或“只读”。
   • 制定DFT友好的ECO规则：例如，禁止在扫描寄存器间插入组合逻辑；替换寄存器时必须保持其扫描属性；新增寄存器必须提供缝合点等。

2. 检测阶段（ECO实施后）：

   • 运行DFT DRC：ECO后的网表必须重新运行全套DFT设计规则检查，包括扫描链连续性检查、时钟和复位混用检查、三态总线冲突检查等。
   • 逻辑等效性检查：必须使用集成了DFT模式约束的LEC工具进行比较，确保在scan_mode=0和scan_mode=1两种模式下，参考设计和ECO后设计均等价。
   • ATPG覆盖率快速评估：对ECO影响的模块进行快速的ATPG测试向量生成，看覆盖率是否有明显下降。

3. 修复阶段（问题发现后）：

   • 使用DFT感知的ECO工具：如果检测到问题，应使用具备DFT修复能力的ECO工具或脚本进行修正，而不是手动修改网表。

4.2 脚本实践：以GOF为例的扫描链缝合

原始文档中提供的GOF脚本是DFT友好ECO实践的优秀范例。我们来逐段解析其关键点：

# GofCall ECO script, run_manual_stitch_scan_chain_example.pl use strict; undo_eco; # 丢弃之前的ECO操作，确保干净的环境 setup_eco("eco_manual_stitch_scan_chain_example"); # 建立ECO任务 read_library("art.5nm.lib"); # 读取工艺库，库中需定义扫描寄存器的类型 read_svf("-ref", "reference.svf.txt"); # 可选，读入形式验证指导文件，帮助定位 read_svf("-imp", "implementation.svf.txt"); read_design("-ref", "reference.gv"); # 参考网表（黄金标准） read_design("-imp", "implementation.gv"); # 待ECO的实现网表 set_top("topmod"); # 设置顶层模块名 set_ignore_output("scan_out*"); # 忽略扫描输出端口的比较，聚焦功能逻辑 set_pin_constant("scan_enable", 0); # 关键！将scan_enable信号在ECO比较时固定为0（功能模式） set_pin_constant("scan_mode", 0); # 关键！将test_mode/scan_mode信号固定为0（功能模式） fix_design; # 执行核心的ECO修复，此命令后，新寄存器已被添加 save_session("current_eco_name"); # 保存会话，便于回溯 set_error_out(0); # 遇到错误不退出，继续执行 my @flops = get_cells("-hier", "-nonscan"); # 获取整个设计中所有还未接入扫描链的新寄存器 if (scalar(@flops)){ # 如果存在这样的寄存器 new_port("so1", "-output"); # 创建新的扫描输出端口 new_port("si1", "-input"); # 创建新的扫描输入端口 my $cnt = 0; my $now_si; foreach my $flop (@flops){ $cnt++; if (is_scan_flop($flop)==0){ # 如果该寄存器本身不是扫描类型 my $flop_name = get_ref($flop); my $scanflop = get_scan_flop($flop_name); # 从库中找到对应的扫描类型单元 change_gate($flop, $scanflop); # 将非扫描寄存器替换为扫描寄存器 } if ($cnt==1){ change_port("so1", "$flop/Q"); # 第一个寄存器的Q驱动新扫描输出端口 } else { change_pin($now_si, "$flop/Q"); # 上一个寄存器的Q驱动当前寄存器的SI } $now_si = "$flop/SI"; # 记录当前寄存器的SI引脚，供下一个寄存器连接 change_pin("$flop/SE", "test_se"); # 将所有寄存器的扫描使能端连接到测试信号 } change_pin($now_si, "si1"); # 最后一个寄存器的SI由新扫描输入端口驱动 } write_verilog("eco_verilog.v"); # 输出ECO后的网表 exit;

脚本解析与注意事项：

• set_pin_constant：这是确保ECO在功能模式下进行的关键。工具只比较scan_enable=0和scan_mode=0时的逻辑，避免了测试逻辑的干扰。
• get_cells("-hier", "-nonscan")：这个API能智能地找出所有不在现有扫描链中的寄存器，包括新增的和因类型转换被排除的。
• change_gate：该API不仅替换实例，还能保持实例原有的所有连接（除替换单元本身的引脚映射差异外），这对于保持其他连接（如时钟、复位）至关重要。
• 手动缝合策略：脚本采用了创建新扫描端口(si1,so1)并将新寄存器链成一串的方法。这是一种稳妥的策略，尤其适用于新增寄存器分散在不同模块的情况。它避免了修改原有复杂扫描链结构可能带来的风险。
• 连接顺序：脚本实现了标准的扫描链连接：si1 -> Flop1[SI] -> Flop1[Q] -> Flop2[SI] -> ... -> FlopN[Q] -> so1。

重要提示：在实际项目中，新增寄存器是集成到现有扫描链中，还是新建一条链，需要根据物理布局、时序和DFT架构来决定。如果新增寄存器物理位置集中，且原有扫描链长度已优化，新建链是更好的选择。脚本中的手动模式提供了这种灵活性。自动模式stitch_scan_chain()则更适用于将新寄存器插入到其所在局部模块的现有链中。

5. 主流EDA工具策略对比与选型考量

在DFT友好ECO方面，不同EDA工具的策略和成熟度差异显著。原始文档中多次对比了Cadence Conformal ECO和GOF，这里我们将其系统化，并补充其他考量。

选型考量建议：

1. 项目阶段与复杂度：对于后期、复杂的ECO，尤其是涉及大量寄存器变动的，应优先选择DFT友好性内建的工具，一次性解决问题，避免反复迭代。
2. 团队技能与流程：如果团队有强大的内部脚本开发能力，可能选择基础ECO工具+自研DFT修复脚本的模式。但对于大多数团队，集成化的解决方案更能降低风险、提高效率。
3. 工艺节点：在16nm及更先进的工艺节点，物理效应显著。工具的“物理感知”DFT ECO能力变得非常重要，应作为选型的关键评估点。
4. 验证流程整合：工具是否能与形式验证、ATPG工具无缝衔接？ECO后的网表能否直接通过DFT DRC和模式下的LEC？这直接决定了验证周期。

6. 实战中的常见陷阱与深度排查指南

即使使用了DFT友好的工具，工程师在实际操作中仍会踩坑。以下是一些“血泪教训”汇总：

陷阱一：忽略了层次化设计中的局部扫描链问题：在模块A中做了ECO，并成功将新寄存器缝入了模块A的局部扫描链。但模块A的局部扫描链输出so_local在顶层连接时，可能因为ECO导致的端口驱动变化而悬空或连接错误。 排查：完成模块级ECO和DFT检查后，必须进行顶层的扫描链完整性检查。使用report_scan_chain -verbose命令，从顶层扫描输入端口开始，追踪到顶层扫描输出端口，确保路径上的所有模块端口连接正确。

陷阱二：异步复位/置位网络的毛刺问题：ECO修改了异步复位或置位信号的组合逻辑生成电路。在测试模式下，虽然该信号被约束为常值，但工具在计算常数传播时可能无法完全消除毛刺风险，在时钟边沿附近出现冒险，导致寄存器意外复位。 排查：除了常规的DRC，需要运行针对时钟和复位信号的动态仿真。在测试模式下，施加扫描移位和捕获的时钟波形，用仿真工具检查异步复位/置位网络上是否有任何非预期的跳变。静态时序分析工具中的set_case_analysis可能掩盖了这种动态冒险。

陷阱三：工具版本或库模型的差异问题：ECO工具使用的标准单元库模型版本与DFT插入、ATPG工具使用的版本有细微差异。例如，扫描寄存器的SE引脚在库中定义的默认值或时序弧不同，导致ECO后仿真失败。 排查：建立统一的库文件管理流程。确保整个流程（综合、DFT插入、ECO、形式验证、ATPG）使用完全相同版本的标准单元库、IO库和任何特殊单元库。在启动ECO前，确认工具读取的.lib文件是最新且一致的。

陷阱四：ECO脚本中的“隐蔽”假设问题：如前面脚本中的change_pin("$flop/SE", "test_se")，假设顶层存在一个名为test_se的扫描使能信号。如果顶层该信号实际名为scan_enable，或者该模块的扫描使能信号由内部逻辑产生，脚本就会出错。 排查：所有ECO脚本中的信号名称、实例命名规则都应是参数化或从设计环境中动态获取的。最好的实践是，编写一个预检查脚本，在正式运行前，验证所有脚本中引用的信号名、端口名在目标网表中都存在且唯一。

深度排查清单（ECO Sign-off前必做）：

1. 逻辑等效性检查（LEC）：运行两次。一次在功能模式下(scan_mode=0, scan_enable=0)，一次在测试移位模式下(scan_mode=1, scan_enable=1)。两次都必须通过。
2. DFT DRC：使用与流片前相同的DRC规则集和设置，对ECO后的完整网表运行检查。重点关注扫描链连续性、时钟混用、复位可控性。
3. 扫描链报告验证：对比ECO前后的扫描链报告，确认：a) 扫描链总数不变；b) 每条链的长度变化符合预期（新增寄存器数）；c) 链中寄存器列表没有意外的丢失或增加。
4. ATPG覆盖率回归：对受ECO影响的模块或整个设计，重新运行ATPG，比较覆盖率。允许有微小波动（如由于逻辑变更导致某些故障变得冗余或不可测），但不应有超过0.1%的意外下降。
5. 关键路径时序再验证：ECO可能改变布线，需要重新提取寄生参数，并对受影响的关键路径进行时序分析，确保没有引入新的违例。

7. 面向未来的DFT友好ECO趋势

随着芯片规模扩大和工艺演进，DFT友好ECO的内涵也在扩展。

趋势一：物理感知的DFT ECO在7nm、5nm及更先进的节点，布线资源紧张，线延迟占比高。简单地将新寄存器插入扫描链末端，可能导致该链的时序无法闭合。下一代ECO工具需要具备“物理感知”能力，在缝合扫描链时，考虑寄存器的物理位置，智能地将新寄存器插入到物理位置邻近的节点，甚至对局部扫描链进行重排序，以优化布线长度和时序。

趋势二：与功耗感知测试的协同现代测试不仅关注故障覆盖率，还关注测试功耗。过高的测试功耗会导致芯片过热、电压降，影响测试可靠性。DFT友好的ECO需要开始考虑“功耗友好”。例如，在插入新寄存器或修改逻辑时，评估其对测试模式下开关活动性的影响，避免在已经很高的功耗区域增加密集的扫描活动。

趋势三：机器学习辅助的ECO影响预测利用机器学习模型，基于历史ECO数据，预测某项ECO修改对DFT覆盖率、时序、功耗的潜在影响。在设计早期或ECO制定阶段，就给出风险提示，引导工程师选择DFT更友好的修改方案。

趋势四：全流程的DFT一致性管理将DFT约束和规则从RTL设计阶段就一直向下传递，贯穿综合、布局布线、ECO等所有步骤。任何工具在修改网表时，都必须遵守这些约束。这需要EDA工具链之间更开放、更标准化的DFT信息交换格式。

在我个人经历过的多次流片冲刺中，那些因为DFT问题而在最后关头被迫返工的ECO，消耗的不仅仅是工程资源，更是宝贵的市场窗口期。因此，培养对DFT友好性的条件反射，选择合适的工具，建立严谨的检查清单，不再把它视为一个可选项，而是芯片功能修改不可分割的一部分。这或许就是我们从一次次“踩坑”中学到的最有价值的经验：在芯片设计的世界里，修复一个功能而破坏可测试性，从来都不是一个成功的修复。