芯片设计后期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技术特别是基于扫描链的设计将芯片内部成千上万个时序逻辑单元主要是寄存器串联成一条或多条“扫描链”。在测试模式下这些寄存器不再执行正常功能而是变成一个超长的移位寄存器。测试时我们通过扫描输入端口将测试向量“串行移位”灌入所有寄存器然后切回功能模式运行一个时钟周期捕获故障响应再切回测试模式将结果串行移出检查。这套机制的核心支柱有三扫描链完整性所有需要测试的寄存器都必须正确地首尾相连形成无断裂的链。时钟与复位可控性在测试模式下必须能独立、稳定地控制扫描链的移位时钟和功能时钟并能将电路置于确定的初始状态。模式隔离必须确保功能逻辑和测试逻辑在各自模式下互不干扰通常通过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_mode1和scan_enable0/1的各种组合下该信号的行为是否符合测试要求通常是保持恒定或可控。一个简单的检查方法是在ECO工具中设置DFT模式约束后再进行逻辑锥的追溯和选择。3.3 案例三寄存器类型转换的“画蛇添足”将可复位寄存器转换为可置位寄存器听起来只是改变寄存器的配置属性。但如原始描述中Conformal ECO工具的做法所示它没有直接替换实例而是新增了一个reg1_1让旧的reg1去驱动扫描链。这造成了双重灾难DFT覆盖率损失新增的reg1_1不在任何扫描链中它存储的状态在测试时既不可控也不可观测。如果设计中有大量此类转换ATPG覆盖率会出现明显的、难以解释的下降。形式验证混乱逻辑等效性检查工具无法将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需要一个系统性的方法而不是依赖工程师的临时检查。预防阶段ECO制定时DFT约束导入在启动ECO工具时必须将DFT约束文件如SDC中的set_scan_configuration、set_dft_signal等以及扫描链定义文件一并导入。让工具从一开始就知道哪些是扫描链、测试信号。识别DFT关键网络工具应自动识别出scan_enable,test_mode,scan_in,scan_out以及所有时钟和异步复位/置位网络并将其标记为“受保护”或“只读”。制定DFT友好的ECO规则例如禁止在扫描寄存器间插入组合逻辑替换寄存器时必须保持其扫描属性新增寄存器必须提供缝合点等。检测阶段ECO实施后运行DFT DRCECO后的网表必须重新运行全套DFT设计规则检查包括扫描链连续性检查、时钟和复位混用检查、三态总线冲突检查等。逻辑等效性检查必须使用集成了DFT模式约束的LEC工具进行比较确保在scan_mode0和scan_mode1两种模式下参考设计和ECO后设计均等价。ATPG覆盖率快速评估对ECO影响的模块进行快速的ATPG测试向量生成看覆盖率是否有明显下降。修复阶段问题发现后使用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 ($cnt1){ 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_enable0和scan_mode0时的逻辑避免了测试逻辑的干扰。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这里我们将其系统化并补充其他考量。特性/场景DFT不友好工具以某些模式为例DFT友好工具以GOF为例核心差异与影响扫描链断裂修复可能直接在相邻扫描寄存器间插入逻辑破坏链连续性。需要手动后期检查修复。自动检测并修复。例如将非扫描寄存器转换为扫描寄存器或重新路由扫描路径绕过新逻辑。自动化程度。前者留下DRC错误后者预防问题。DFT信号选择仅基于功能等价进行选择可能选中测试模式下不稳定的信号源如MUX的非测试端。能识别测试结构如MUX优先选择在测试模式下稳定/可控的信号源。DFT语义理解。前者导致测试失败后者保证测试模式稳定性。寄存器类型转换可能采用新增实例的冗余方式导致新实例不在扫描链内造成覆盖率损失和LEC噪声。支持原位替换直接改变实例类型保持其所有现有连接包括扫描端口不变。架构优雅性与验证复杂度。前者增加设计冗余和验证负担后者保持设计干净。新增寄存器处理通常不自动处理新增寄存器默认为非扫描需工程师手动编写脚本或后续步骤集成。提供stitch_scan_chain等专用API支持自动或半自动将新寄存器缝合进扫描链。流程整合度。前者是分离的、易遗漏的步骤后者是ECO流程的自然延伸。与物理设计的协同在先进工艺下ECO后的扫描链可能产生新的布线拥塞或时序违例需要额外迭代。高级工具可以考虑物理位置信息进行扫描链的“物理感知”重排序以最小化布线影响。物理友好性。在纳米级工艺中这一点至关重要。选型考量建议项目阶段与复杂度对于后期、复杂的ECO尤其是涉及大量寄存器变动的应优先选择DFT友好性内建的工具一次性解决问题避免反复迭代。团队技能与流程如果团队有强大的内部脚本开发能力可能选择基础ECO工具自研DFT修复脚本的模式。但对于大多数团队集成化的解决方案更能降低风险、提高效率。工艺节点在16nm及更先进的工艺节点物理效应显著。工具的“物理感知”DFT ECO能力变得非常重要应作为选型的关键评估点。验证流程整合工具是否能与形式验证、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前必做逻辑等效性检查LEC运行两次。一次在功能模式下(scan_mode0, scan_enable0)一次在测试移位模式下(scan_mode1, scan_enable1)。两次都必须通过。DFT DRC使用与流片前相同的DRC规则集和设置对ECO后的完整网表运行检查。重点关注扫描链连续性、时钟混用、复位可控性。扫描链报告验证对比ECO前后的扫描链报告确认a) 扫描链总数不变b) 每条链的长度变化符合预期新增寄存器数c) 链中寄存器列表没有意外的丢失或增加。ATPG覆盖率回归对受ECO影响的模块或整个设计重新运行ATPG比较覆盖率。允许有微小波动如由于逻辑变更导致某些故障变得冗余或不可测但不应有超过0.1%的意外下降。关键路径时序再验证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友好性的条件反射选择合适的工具建立严谨的检查清单不再把它视为一个可选项而是芯片功能修改不可分割的一部分。这或许就是我们从一次次“踩坑”中学到的最有价值的经验在芯片设计的世界里修复一个功能而破坏可测试性从来都不是一个成功的修复。