1. 从Stuck-at到多模型混跑为什么单一故障模型越来越不够用如果你做过几年芯片测试大概率经历过这样的场景一个模块跑完Stuck-at ATPG覆盖率卡在98.7%死活上不去工具报了一堆uncontrolled和unobserved的点你对着网表查了半天发现那些点其实在真实硅片上根本不可能以固定0/1的方式失效——它们更可能表现为延迟偏大、跳变沿退化或者跟相邻线之间的耦合效应。这时候你才意识到Stuck-at模型只是把故障简化成了“线固定为0或1”而先进工艺下的物理缺陷远比这个假设复杂。Tessent作为业界主流的DFT工具链在ATPG阶段支持多种Fault Model从最经典的Stuck-at到Transition Delay、Path Delay、Bridge、IDDQ、Cell-Aware等等。每种模型对应不同的缺陷机理和测试目标选型不对要么覆盖率虚高但逃逸率高要么Pattern数量爆炸导致测试时间不可接受。我见过不少团队为了冲覆盖率数字把所有模型全开结果Pattern膨胀到原来的五六倍ATE上的测试成本直接翻番最后不得不回头做裁剪。这篇文章面向的是已经上手Tessent ATPG、但面对多Fault Model时不知道该怎么选、怎么配、怎么权衡的工程师。我会从每个模型解决的物理问题讲起拆到Tessent里的具体命令和参数再结合实测数据讲选型逻辑和混跑策略。不会只给你一堆命令让你抄而是把“为什么这么配”讲清楚这样你换一个工艺节点或者换一个设计类型时自己能判断该怎么调整。2. 各Fault Model的物理背景与Tessent中的建模方式2.1 Stuck-at最成熟但也最容易被误用的基线模型Stuck-at模型假设电路中某条线永久固定为逻辑0或逻辑1。它的物理对应是金属线断裂、晶体管源漏短路、栅氧击穿等导致节点电平恒定的缺陷。Tessent里用add_faults -model stuck来加载配合set_atpg -mode选择Basic或Full算法。这个模型最大的优势是成熟度高、Pattern紧凑、仿真速度快。一个百万门级的设计Stuck-at Pattern通常几千条就能到99%以上覆盖率。但问题在于它无法覆盖那些“只在特定时序条件下才表现出来”的缺陷。比如一条路径上某个门的延迟增加了30%在Stuck-at测试下功能完全正常但在实际运行中可能因为时序违例导致系统出错。我在实际项目中遇到过这样的情况Stuck-at覆盖率99.2%芯片回来后在客户板上跑了一段时间出现偶发死机最后定位到是一个加法器的进位链上有个via的电阻偏大导致高温低压角下进位延迟超标。这个缺陷Stuck-at根本测不出来必须用Transition Delay模型。Tessent中Stuck-at的配置相对简单但有几个容易忽略的点set_atpg -stuck_limit控制单条Pattern能检测的最大故障数默认值偏保守适当调大可以压缩Pattern数量但会增加仿真时间。add_faults -all会把所有可测点都加进来包括一些冗余逻辑上的点建议先用report_faults -summary看一下故障分布再决定。对于三态总线、双向端口这些特殊结构需要额外设置set_atpg -handle_bidi之类的选项否则会报大量uncontrolled。2.2 Transition Delay抓的是“慢”而不是“坏”Transition Delay模型也叫At-Speed测试检测的是信号跳变沿在指定时间窗口内是否能传播到捕获点。它把故障分为两类Slow-to-Rise上升沿太慢和Slow-to-Fall下降沿太慢。物理对应是电阻性缺陷、晶体管老化、工艺偏差导致的延迟异常。Tessent里用add_faults -model transition加载关键配置在set_atpg -transition下set_atpg -transition true set_atpg -num_clock_pulses 2 set_atpg -launch_mode launch_on_capturelaunch_mode有两个选项launch_on_capture和launch_on_shift。前者用功能时钟发射后者用扫描时钟发射。实测下来launch_on_capture的覆盖率通常更高但对时钟控制逻辑要求更严格launch_on_shift实现简单但可能引入额外的时钟域交叉问题。Transition Pattern的数量通常是Stuck-at的3到5倍因为每个故障需要至少两个向量一个初始化一个发射-捕获。在Tessent中可以通过set_atpg -merge high来合并兼容的Pattern但合并率过高会降低故障检测的确定性需要根据逃逸率要求来权衡。注意Transition测试对电源完整性非常敏感。如果IR-drop过大可能导致良品在At-Speed测试下失效。建议在Pattern生成后做一次电源感知仿真Tessent的analyze_power命令可以辅助评估。2.3 Path Delay覆盖累积延迟的“长路径”问题Path Delay模型检测的是一整条组合路径的累积延迟是否超过时钟周期。它比Transition更严格因为Transition只关心单个跳变沿能否在捕获窗口内到达而Path Delay要求整条路径的延迟都在约束范围内。Tessent中Path Delay的配置需要先定义路径add_path_delay -from [get_ports input*] -to [get_ports output*] -num_paths 1000 set_atpg -path_delay true-num_paths控制选取的路径数量选太多会导致Pattern爆炸选太少则覆盖不充分。通常建议先用静态时序分析STA工具导出关键路径列表再导入Tessent做定向生成。Path Delay的Pattern数量介于Transition和全定制之间实测中一个中等规模模块大约需要Transition的1.5到2倍Pattern。它的优势是能覆盖那些“单点延迟正常但累积超标”的缺陷缺点是路径选取依赖STA的准确性如果STA的时序约束不准生成的Pattern可能测不到真正的关键路径。2.4 Bridge与IDDQ模拟缺陷的补充手段Bridge模型假设两条相邻线之间出现非预期的短路。Tessent中通过add_faults -model bridge加载需要配合set_atpg -bridge设置短路电阻范围。这个模型对版图依赖性很强通常需要从物理设计阶段导入耦合电容信息。IDDQ模型检测的是静态电源电流异常物理对应是栅氧漏电、结漏电等缺陷。Tessent中配置为set_atpg -iddq true add_faults -model iddqIDDQ Pattern数量很少通常几十条就够但需要ATE支持精密电流测量。在先进工艺下由于漏电流本身就在增大IDDQ的信噪比越来越差很多团队已经转向用其他模型替代。2.5 Cell-Aware从门级到晶体管级的跨越Cell-Aware模型是近几年越来越受重视的方向。传统Stuck-at把标准单元当成黑盒只测输入输出端口但单元内部的晶体管级缺陷比如串联堆叠中的单个晶体管失效可能无法通过端口测试暴露。Cell-Aware通过库特征化把每个标准单元内部的缺陷也建模进来。Tessent中需要先加载Cell-Aware库read_cell_model -library my_lib -cell_aware set_atpg -cell_aware true add_faults -model cell_awareCell-Aware的覆盖率提升通常在0.5%到2%之间看起来不多但在高安全等级芯片如汽车电子中这几个百分点往往是能否过认证的关键。代价是Pattern数量增加20%到40%仿真时间翻倍。3. 选型决策从缺陷逃逸率反推模型组合3.1 先搞清楚你的芯片用在哪里选型的第一步不是看工具支持什么而是看你的芯片应用场景对缺陷逃逸的容忍度。消费类芯片Stuck-at加Transition基本够用DPPM要求通常在500以下工业级芯片需要加上Path Delay和部分Cell-AwareDPPM要求100以下汽车电子尤其是涉及功能安全的Bridge、IDDQ、Cell-Aware可能都要上DPPM要求个位数。我一般会建议团队先做一个缺陷逃逸率预算表像这样应用等级目标DPPM推荐模型组合预估Pattern倍数消费类500Stuck-at Transition1x 3x工业类100Stuck-at Transition Path Delay1x 3x 1.5x汽车类10全模型 Cell-Aware1x 4x 2x 0.5x高可靠1全模型 定制Path IDDQ1x 5x 3x 0.2x这个表不是拍脑袋来的是根据多个项目回来后做的DPPM统计反推的。当然每个工艺节点和设计类型会有差异但量级上可以作为起点。3.2 覆盖率数字背后的陷阱很多团队盯着Tessent报的覆盖率数字觉得99.5%就万事大吉。但不同模型报出来的覆盖率含义完全不同。Stuck-at的99.5%和Transition的99.5%不是一回事前者只说明固定型故障测到了后者才说明跳变延迟测到了。更关键的是Tessent默认的覆盖率计算是基于故障列表的而故障列表的生成依赖于add_faults时的选项。如果你只加了部分故障覆盖率自然高但实际逃逸风险没变。我习惯在报告覆盖率时同时看三个数字故障总数、检测到的故障数、以及未检测故障中uncontrolled和unobserved的比例。如果uncontrolled占比超过5%说明测试逻辑或时钟控制有问题需要先解决结构性问题再谈模型选型。3.3 混跑策略串行还是并行Tessent支持在同一个ATPG session中混跑多个模型也支持分开跑再合并Pattern。两种方式各有适用场景。串行混跑一个session里依次加载不同模型的优点是Pattern可以共享工具会自动做跨模型的Pattern合并最终Pattern数量通常比分开跑再合并少10%到20%。缺点是内存占用大仿真时间长一旦某个模型配置出错整个session要重来。并行分开跑每个模型独立session最后用merge_patterns合并的优点是灵活可以针对每个模型单独调参出问题容易定位。缺点是Pattern合并率低最终数量偏多。我的经验是如果设计规模在500万门以下串行混跑更划算超过500万门建议分开跑否则内存和仿真时间吃不消。Tessent的set_atpg -parallel可以开启多核并行但要注意license数量限制。4. 实操中的参数调优与常见报错处理4.1 Transition模型下时钟配置的坑Transition测试对时钟定义极其敏感。Tessent中如果时钟定义不完整会报“cannot find launch clock”或者“capture clock not defined”之类的错误。我遇到过最常见的情况是设计中有多个时钟域但set_atpg -transition只配了主时钟导致跨时钟域的故障全部报uncontrolled。解决办法是在add_clocks时把所有相关时钟都加进来并且用set_clock -domain明确时钟域关系。对于异步时钟域交叉的路径要么用set_false_path排除要么用set_atpg -cross_clock开启跨时钟测试。后者会显著增加Pattern数量但能覆盖一些真实的跨时钟缺陷。另一个坑是时钟脉冲宽度。set_atpg -num_clock_pulses 2表示两个脉冲一个launch一个capture。但如果时钟树上有分频或门控实际到达寄存器的脉冲可能变形。建议在ATPG之前先用report_clocks检查时钟树结构确认没有意外的门控逻辑。4.2 Cell-Aware库加载失败的排查链路Cell-Aware库的加载是另一个高频出错点。典型报错是“cell model not found”或者“cell_aware library version mismatch”。排查步骤我一般按这个顺序来确认库文件路径正确Tessent的read_cell_model对路径大小写敏感Linux下尤其注意。检查库版本和Tessent版本是否匹配。Cell-Aware库通常和Tessent版本绑定跨版本使用大概率报错。确认库中包含了所有标准单元。有些代工厂提供的Cell-Aware库只覆盖部分单元缺失的单元会报warning如果缺失的是关键单元覆盖率会明显偏低。检查set_atpg -cell_aware是否在add_faults之前设置。顺序错了会导致Cell-Aware故障没被加载。如果库加载成功但覆盖率没提升大概率是库特征化时用的缺陷模型和你的工艺不匹配。这种情况需要联系代工厂重新特征化或者退而求其次用Stuck-at加Transition的组合来近似。4.3 Pattern数量爆炸时的裁剪思路多模型混跑最直接的问题就是Pattern数量。我做过一个汽车MCU项目全模型跑下来Pattern超过20万条ATE上单颗芯片测试时间超过8秒完全不可接受。后来做了几轮裁剪第一轮把IDDQ模型去掉因为该工艺下漏电流太大IDDQ信噪比不够测了也白测。Pattern降到15万。第二轮Path Delay只保留STA报出的前200条关键路径而不是全量路径。Pattern降到11万。第三轮Transition模型改用launch_on_shift模式虽然覆盖率降了0.3%但Pattern减少了30%。最终降到7.8万条测试时间压到3秒以内。裁剪的核心原则是先砍掉物理意义最弱的模型再砍掉覆盖率贡献最小的配置最后才考虑降低测试严格度。每一步都要重新评估逃逸风险不能只看数字。5. 实测数据不同模型组合的覆盖率与成本对比5.1 测试用例设计为了给出有参考价值的数据我用一个约80万门的通信模块做了对比测试。工艺是28nm标准单元库来自主流代工厂Tessent版本是2023.1。测试了五种组合A仅Stuck-atBStuck-at Transitionlaunch_on_captureCStuck-at Transition Path Delay前500条路径DC Cell-AwareED Bridge IDDQ每种组合记录覆盖率、Pattern数量、ATPG运行时间、仿真时间。5.2 数据对比与解读组合Stuck-at覆盖率Transition覆盖率Pattern数量ATPG时间仿真时间A99.3%-3,20012min8minB99.3%96.8%14,50045min38minC99.3%96.8%21,00078min65minD99.4%97.1%28,500135min120minE99.4%97.1%31,200160min150min从数据看Transition是覆盖率提升最明显的模型从Stuck-at的99.3%到加上Transition后虽然Stuck-at覆盖率没变但整体缺陷覆盖能力大幅提升。Path Delay和Cell-Aware的边际收益递减但Pattern增幅依然可观。Bridge和IDDQ在这个设计上几乎没有贡献覆盖率Pattern却增加了近3000条。这个结果不是绝对的换一个设计类型可能完全不同。比如一个模拟混合信号模块IDDQ可能就很有价值一个高频处理器核Path Delay的贡献会更大。关键是要在自己的设计上做类似的对比测试用数据说话。5.3 成本敏感场景下的取舍如果ATE测试成本是硬约束我的建议是优先保证Stuck-at和Transition这两个是基线。Path Delay只在STA报出明显时序余量不足的路径上加。Cell-Aware在汽车和安全芯片上必须加消费类可以暂缓。Bridge和IDDQ看工艺和ATE能力28nm以下IDDQ基本可以放弃Bridge在版图密集的存储器周边可以考虑。还有一个容易被忽略的成本是ATPG运行时间。组合E的ATPG时间超过2.5小时如果设计迭代频繁这个时间成本很高。可以考虑把Cell-Aware和Bridge放在最终签核阶段再跑日常迭代只用组合B或C。6. 从项目经验中沉淀的几条硬规则6.1 故障列表要先清理再加载Tessent的add_faults默认会加载所有可测点但其中很多是冗余逻辑、测试逻辑、或者不可能在功能模式下激活的点。这些点如果不清掉会拉低覆盖率数字还会浪费ATPG时间。我习惯在add_faults之后先跑一次report_faults -class uncollapsed把uncontrolled和unobserved的点分类看一下。对于测试逻辑上的点用set_dont_test排除对于冗余逻辑用set_faults -class redundant标记。清理之后覆盖率通常能提升0.5%到1%Pattern数量减少5%左右。6.2 时钟和复位要单独验证多模型ATPG对时钟和复位结构非常敏感。我踩过最深的坑是一个设计里复位信号在扫描模式下没有正确隔离导致Transition测试时所有寄存器被异步复位Pattern全部失效。后来在ATPG之前加了一步check_dft_rules专门检查扫描模式下的时钟和复位路径问题才暴露出来。建议在跑ATPG之前先用report_scan_chains和report_clocks确认扫描链完整、时钟定义正确。对于有多个复位域的设计用set_atpg -reset明确复位处理方式避免工具自动推断出错。6.3 Pattern验证不能省生成的Pattern一定要做仿真验证尤其是Transition和Path Delay。我见过太多案例是ATPG报覆盖率很高但Pattern在门级仿真中大量失效原因是时序约束和实际仿真模型不一致。Tessent的write_patterns可以输出VCD或EVCD格式配合门级仿真器做验证。验证通过率低于95%就要回头检查约束不能直接拿去流片。6.4 版本升级要重新基线Tessent每个大版本对Fault Model的处理都有变化。2021版到2023版Cell-Aware的故障建模方式改过一次同样的库和设计覆盖率差了0.8%。所以每次升级Tessent版本都要用同一个设计重新跑一遍基线确认覆盖率、Pattern数量、运行时间没有异常变化。如果变化超过预期先查Release Note里关于ATPG的变更说明再决定是否调整配置。6.5 文档化你的选型决策最后一条看起来最虚但实际最有用。每次项目选型时把为什么选这个模型组合、为什么砍掉某个模型、覆盖率目标是多少、实际达到多少都记下来。下一个项目遇到类似设计时这些记录能帮你快速决策而不是每次从头试错。我自己的选型笔记已经积累了十几个项目新项目来了先翻笔记能省掉至少一周的试错时间。这些规则不是从手册上抄的都是实际项目中踩坑踩出来的。Tessent的文档很全但文档不会告诉你什么情况下该放弃IDDQ也不会告诉你Cell-Aware库加载失败时先查什么。这些判断力只能靠项目积累希望上面的分享能帮你少走一些弯路。
1. 从Stuck-at到多模型混跑为什么单一故障模型越来越不够用如果你做过几年芯片测试大概率经历过这样的场景一个模块跑完Stuck-at ATPG覆盖率卡在98.7%死活上不去工具报了一堆uncontrolled和unobserved的点你对着网表查了半天发现那些点其实在真实硅片上根本不可能以固定0/1的方式失效——它们更可能表现为延迟偏大、跳变沿退化或者跟相邻线之间的耦合效应。这时候你才意识到Stuck-at模型只是把故障简化成了“线固定为0或1”而先进工艺下的物理缺陷远比这个假设复杂。Tessent作为业界主流的DFT工具链在ATPG阶段支持多种Fault Model从最经典的Stuck-at到Transition Delay、Path Delay、Bridge、IDDQ、Cell-Aware等等。每种模型对应不同的缺陷机理和测试目标选型不对要么覆盖率虚高但逃逸率高要么Pattern数量爆炸导致测试时间不可接受。我见过不少团队为了冲覆盖率数字把所有模型全开结果Pattern膨胀到原来的五六倍ATE上的测试成本直接翻番最后不得不回头做裁剪。这篇文章面向的是已经上手Tessent ATPG、但面对多Fault Model时不知道该怎么选、怎么配、怎么权衡的工程师。我会从每个模型解决的物理问题讲起拆到Tessent里的具体命令和参数再结合实测数据讲选型逻辑和混跑策略。不会只给你一堆命令让你抄而是把“为什么这么配”讲清楚这样你换一个工艺节点或者换一个设计类型时自己能判断该怎么调整。2. 各Fault Model的物理背景与Tessent中的建模方式2.1 Stuck-at最成熟但也最容易被误用的基线模型Stuck-at模型假设电路中某条线永久固定为逻辑0或逻辑1。它的物理对应是金属线断裂、晶体管源漏短路、栅氧击穿等导致节点电平恒定的缺陷。Tessent里用add_faults -model stuck来加载配合set_atpg -mode选择Basic或Full算法。这个模型最大的优势是成熟度高、Pattern紧凑、仿真速度快。一个百万门级的设计Stuck-at Pattern通常几千条就能到99%以上覆盖率。但问题在于它无法覆盖那些“只在特定时序条件下才表现出来”的缺陷。比如一条路径上某个门的延迟增加了30%在Stuck-at测试下功能完全正常但在实际运行中可能因为时序违例导致系统出错。我在实际项目中遇到过这样的情况Stuck-at覆盖率99.2%芯片回来后在客户板上跑了一段时间出现偶发死机最后定位到是一个加法器的进位链上有个via的电阻偏大导致高温低压角下进位延迟超标。这个缺陷Stuck-at根本测不出来必须用Transition Delay模型。Tessent中Stuck-at的配置相对简单但有几个容易忽略的点set_atpg -stuck_limit控制单条Pattern能检测的最大故障数默认值偏保守适当调大可以压缩Pattern数量但会增加仿真时间。add_faults -all会把所有可测点都加进来包括一些冗余逻辑上的点建议先用report_faults -summary看一下故障分布再决定。对于三态总线、双向端口这些特殊结构需要额外设置set_atpg -handle_bidi之类的选项否则会报大量uncontrolled。2.2 Transition Delay抓的是“慢”而不是“坏”Transition Delay模型也叫At-Speed测试检测的是信号跳变沿在指定时间窗口内是否能传播到捕获点。它把故障分为两类Slow-to-Rise上升沿太慢和Slow-to-Fall下降沿太慢。物理对应是电阻性缺陷、晶体管老化、工艺偏差导致的延迟异常。Tessent里用add_faults -model transition加载关键配置在set_atpg -transition下set_atpg -transition true set_atpg -num_clock_pulses 2 set_atpg -launch_mode launch_on_capturelaunch_mode有两个选项launch_on_capture和launch_on_shift。前者用功能时钟发射后者用扫描时钟发射。实测下来launch_on_capture的覆盖率通常更高但对时钟控制逻辑要求更严格launch_on_shift实现简单但可能引入额外的时钟域交叉问题。Transition Pattern的数量通常是Stuck-at的3到5倍因为每个故障需要至少两个向量一个初始化一个发射-捕获。在Tessent中可以通过set_atpg -merge high来合并兼容的Pattern但合并率过高会降低故障检测的确定性需要根据逃逸率要求来权衡。注意Transition测试对电源完整性非常敏感。如果IR-drop过大可能导致良品在At-Speed测试下失效。建议在Pattern生成后做一次电源感知仿真Tessent的analyze_power命令可以辅助评估。2.3 Path Delay覆盖累积延迟的“长路径”问题Path Delay模型检测的是一整条组合路径的累积延迟是否超过时钟周期。它比Transition更严格因为Transition只关心单个跳变沿能否在捕获窗口内到达而Path Delay要求整条路径的延迟都在约束范围内。Tessent中Path Delay的配置需要先定义路径add_path_delay -from [get_ports input*] -to [get_ports output*] -num_paths 1000 set_atpg -path_delay true-num_paths控制选取的路径数量选太多会导致Pattern爆炸选太少则覆盖不充分。通常建议先用静态时序分析STA工具导出关键路径列表再导入Tessent做定向生成。Path Delay的Pattern数量介于Transition和全定制之间实测中一个中等规模模块大约需要Transition的1.5到2倍Pattern。它的优势是能覆盖那些“单点延迟正常但累积超标”的缺陷缺点是路径选取依赖STA的准确性如果STA的时序约束不准生成的Pattern可能测不到真正的关键路径。2.4 Bridge与IDDQ模拟缺陷的补充手段Bridge模型假设两条相邻线之间出现非预期的短路。Tessent中通过add_faults -model bridge加载需要配合set_atpg -bridge设置短路电阻范围。这个模型对版图依赖性很强通常需要从物理设计阶段导入耦合电容信息。IDDQ模型检测的是静态电源电流异常物理对应是栅氧漏电、结漏电等缺陷。Tessent中配置为set_atpg -iddq true add_faults -model iddqIDDQ Pattern数量很少通常几十条就够但需要ATE支持精密电流测量。在先进工艺下由于漏电流本身就在增大IDDQ的信噪比越来越差很多团队已经转向用其他模型替代。2.5 Cell-Aware从门级到晶体管级的跨越Cell-Aware模型是近几年越来越受重视的方向。传统Stuck-at把标准单元当成黑盒只测输入输出端口但单元内部的晶体管级缺陷比如串联堆叠中的单个晶体管失效可能无法通过端口测试暴露。Cell-Aware通过库特征化把每个标准单元内部的缺陷也建模进来。Tessent中需要先加载Cell-Aware库read_cell_model -library my_lib -cell_aware set_atpg -cell_aware true add_faults -model cell_awareCell-Aware的覆盖率提升通常在0.5%到2%之间看起来不多但在高安全等级芯片如汽车电子中这几个百分点往往是能否过认证的关键。代价是Pattern数量增加20%到40%仿真时间翻倍。3. 选型决策从缺陷逃逸率反推模型组合3.1 先搞清楚你的芯片用在哪里选型的第一步不是看工具支持什么而是看你的芯片应用场景对缺陷逃逸的容忍度。消费类芯片Stuck-at加Transition基本够用DPPM要求通常在500以下工业级芯片需要加上Path Delay和部分Cell-AwareDPPM要求100以下汽车电子尤其是涉及功能安全的Bridge、IDDQ、Cell-Aware可能都要上DPPM要求个位数。我一般会建议团队先做一个缺陷逃逸率预算表像这样应用等级目标DPPM推荐模型组合预估Pattern倍数消费类500Stuck-at Transition1x 3x工业类100Stuck-at Transition Path Delay1x 3x 1.5x汽车类10全模型 Cell-Aware1x 4x 2x 0.5x高可靠1全模型 定制Path IDDQ1x 5x 3x 0.2x这个表不是拍脑袋来的是根据多个项目回来后做的DPPM统计反推的。当然每个工艺节点和设计类型会有差异但量级上可以作为起点。3.2 覆盖率数字背后的陷阱很多团队盯着Tessent报的覆盖率数字觉得99.5%就万事大吉。但不同模型报出来的覆盖率含义完全不同。Stuck-at的99.5%和Transition的99.5%不是一回事前者只说明固定型故障测到了后者才说明跳变延迟测到了。更关键的是Tessent默认的覆盖率计算是基于故障列表的而故障列表的生成依赖于add_faults时的选项。如果你只加了部分故障覆盖率自然高但实际逃逸风险没变。我习惯在报告覆盖率时同时看三个数字故障总数、检测到的故障数、以及未检测故障中uncontrolled和unobserved的比例。如果uncontrolled占比超过5%说明测试逻辑或时钟控制有问题需要先解决结构性问题再谈模型选型。3.3 混跑策略串行还是并行Tessent支持在同一个ATPG session中混跑多个模型也支持分开跑再合并Pattern。两种方式各有适用场景。串行混跑一个session里依次加载不同模型的优点是Pattern可以共享工具会自动做跨模型的Pattern合并最终Pattern数量通常比分开跑再合并少10%到20%。缺点是内存占用大仿真时间长一旦某个模型配置出错整个session要重来。并行分开跑每个模型独立session最后用merge_patterns合并的优点是灵活可以针对每个模型单独调参出问题容易定位。缺点是Pattern合并率低最终数量偏多。我的经验是如果设计规模在500万门以下串行混跑更划算超过500万门建议分开跑否则内存和仿真时间吃不消。Tessent的set_atpg -parallel可以开启多核并行但要注意license数量限制。4. 实操中的参数调优与常见报错处理4.1 Transition模型下时钟配置的坑Transition测试对时钟定义极其敏感。Tessent中如果时钟定义不完整会报“cannot find launch clock”或者“capture clock not defined”之类的错误。我遇到过最常见的情况是设计中有多个时钟域但set_atpg -transition只配了主时钟导致跨时钟域的故障全部报uncontrolled。解决办法是在add_clocks时把所有相关时钟都加进来并且用set_clock -domain明确时钟域关系。对于异步时钟域交叉的路径要么用set_false_path排除要么用set_atpg -cross_clock开启跨时钟测试。后者会显著增加Pattern数量但能覆盖一些真实的跨时钟缺陷。另一个坑是时钟脉冲宽度。set_atpg -num_clock_pulses 2表示两个脉冲一个launch一个capture。但如果时钟树上有分频或门控实际到达寄存器的脉冲可能变形。建议在ATPG之前先用report_clocks检查时钟树结构确认没有意外的门控逻辑。4.2 Cell-Aware库加载失败的排查链路Cell-Aware库的加载是另一个高频出错点。典型报错是“cell model not found”或者“cell_aware library version mismatch”。排查步骤我一般按这个顺序来确认库文件路径正确Tessent的read_cell_model对路径大小写敏感Linux下尤其注意。检查库版本和Tessent版本是否匹配。Cell-Aware库通常和Tessent版本绑定跨版本使用大概率报错。确认库中包含了所有标准单元。有些代工厂提供的Cell-Aware库只覆盖部分单元缺失的单元会报warning如果缺失的是关键单元覆盖率会明显偏低。检查set_atpg -cell_aware是否在add_faults之前设置。顺序错了会导致Cell-Aware故障没被加载。如果库加载成功但覆盖率没提升大概率是库特征化时用的缺陷模型和你的工艺不匹配。这种情况需要联系代工厂重新特征化或者退而求其次用Stuck-at加Transition的组合来近似。4.3 Pattern数量爆炸时的裁剪思路多模型混跑最直接的问题就是Pattern数量。我做过一个汽车MCU项目全模型跑下来Pattern超过20万条ATE上单颗芯片测试时间超过8秒完全不可接受。后来做了几轮裁剪第一轮把IDDQ模型去掉因为该工艺下漏电流太大IDDQ信噪比不够测了也白测。Pattern降到15万。第二轮Path Delay只保留STA报出的前200条关键路径而不是全量路径。Pattern降到11万。第三轮Transition模型改用launch_on_shift模式虽然覆盖率降了0.3%但Pattern减少了30%。最终降到7.8万条测试时间压到3秒以内。裁剪的核心原则是先砍掉物理意义最弱的模型再砍掉覆盖率贡献最小的配置最后才考虑降低测试严格度。每一步都要重新评估逃逸风险不能只看数字。5. 实测数据不同模型组合的覆盖率与成本对比5.1 测试用例设计为了给出有参考价值的数据我用一个约80万门的通信模块做了对比测试。工艺是28nm标准单元库来自主流代工厂Tessent版本是2023.1。测试了五种组合A仅Stuck-atBStuck-at Transitionlaunch_on_captureCStuck-at Transition Path Delay前500条路径DC Cell-AwareED Bridge IDDQ每种组合记录覆盖率、Pattern数量、ATPG运行时间、仿真时间。5.2 数据对比与解读组合Stuck-at覆盖率Transition覆盖率Pattern数量ATPG时间仿真时间A99.3%-3,20012min8minB99.3%96.8%14,50045min38minC99.3%96.8%21,00078min65minD99.4%97.1%28,500135min120minE99.4%97.1%31,200160min150min从数据看Transition是覆盖率提升最明显的模型从Stuck-at的99.3%到加上Transition后虽然Stuck-at覆盖率没变但整体缺陷覆盖能力大幅提升。Path Delay和Cell-Aware的边际收益递减但Pattern增幅依然可观。Bridge和IDDQ在这个设计上几乎没有贡献覆盖率Pattern却增加了近3000条。这个结果不是绝对的换一个设计类型可能完全不同。比如一个模拟混合信号模块IDDQ可能就很有价值一个高频处理器核Path Delay的贡献会更大。关键是要在自己的设计上做类似的对比测试用数据说话。5.3 成本敏感场景下的取舍如果ATE测试成本是硬约束我的建议是优先保证Stuck-at和Transition这两个是基线。Path Delay只在STA报出明显时序余量不足的路径上加。Cell-Aware在汽车和安全芯片上必须加消费类可以暂缓。Bridge和IDDQ看工艺和ATE能力28nm以下IDDQ基本可以放弃Bridge在版图密集的存储器周边可以考虑。还有一个容易被忽略的成本是ATPG运行时间。组合E的ATPG时间超过2.5小时如果设计迭代频繁这个时间成本很高。可以考虑把Cell-Aware和Bridge放在最终签核阶段再跑日常迭代只用组合B或C。6. 从项目经验中沉淀的几条硬规则6.1 故障列表要先清理再加载Tessent的add_faults默认会加载所有可测点但其中很多是冗余逻辑、测试逻辑、或者不可能在功能模式下激活的点。这些点如果不清掉会拉低覆盖率数字还会浪费ATPG时间。我习惯在add_faults之后先跑一次report_faults -class uncollapsed把uncontrolled和unobserved的点分类看一下。对于测试逻辑上的点用set_dont_test排除对于冗余逻辑用set_faults -class redundant标记。清理之后覆盖率通常能提升0.5%到1%Pattern数量减少5%左右。6.2 时钟和复位要单独验证多模型ATPG对时钟和复位结构非常敏感。我踩过最深的坑是一个设计里复位信号在扫描模式下没有正确隔离导致Transition测试时所有寄存器被异步复位Pattern全部失效。后来在ATPG之前加了一步check_dft_rules专门检查扫描模式下的时钟和复位路径问题才暴露出来。建议在跑ATPG之前先用report_scan_chains和report_clocks确认扫描链完整、时钟定义正确。对于有多个复位域的设计用set_atpg -reset明确复位处理方式避免工具自动推断出错。6.3 Pattern验证不能省生成的Pattern一定要做仿真验证尤其是Transition和Path Delay。我见过太多案例是ATPG报覆盖率很高但Pattern在门级仿真中大量失效原因是时序约束和实际仿真模型不一致。Tessent的write_patterns可以输出VCD或EVCD格式配合门级仿真器做验证。验证通过率低于95%就要回头检查约束不能直接拿去流片。6.4 版本升级要重新基线Tessent每个大版本对Fault Model的处理都有变化。2021版到2023版Cell-Aware的故障建模方式改过一次同样的库和设计覆盖率差了0.8%。所以每次升级Tessent版本都要用同一个设计重新跑一遍基线确认覆盖率、Pattern数量、运行时间没有异常变化。如果变化超过预期先查Release Note里关于ATPG的变更说明再决定是否调整配置。6.5 文档化你的选型决策最后一条看起来最虚但实际最有用。每次项目选型时把为什么选这个模型组合、为什么砍掉某个模型、覆盖率目标是多少、实际达到多少都记下来。下一个项目遇到类似设计时这些记录能帮你快速决策而不是每次从头试错。我自己的选型笔记已经积累了十几个项目新项目来了先翻笔记能省掉至少一周的试错时间。这些规则不是从手册上抄的都是实际项目中踩坑踩出来的。Tessent的文档很全但文档不会告诉你什么情况下该放弃IDDQ也不会告诉你Cell-Aware库加载失败时先查什么。这些判断力只能靠项目积累希望上面的分享能帮你少走一些弯路。
![交环学子毕业论文工具箱：从交叉口数据到答辩PPT，我会这样搭配着用 [特殊字符]](http://pic.xiahunao.cn/yaotu/交环学子毕业论文工具箱：从交叉口数据到答辩PPT，我会这样搭配着用 [特殊字符])
