1. Scan Chain与ATPG的整体设计思路1.1 为什么测试可测性设计绕不开Scan Chain芯片设计到了后端阶段有一件事早晚要面对就是流片回来之后怎么保证每一颗die功能正常。功能测试覆盖不了深层次的逻辑故障因为内部寄存器状态不可控、不可观测测试向量需要指数级增长才能覆盖足够多的故障点。这时候可测性设计DFT就派上用场了而Scan Chain是DFT里最基础、也最成熟的一环。Scan Chain的思路本质上是把芯片内部的寄存器串成一条或者几条移位寄存器链。通过测试模式下的Shift操作把测试激励灌进内部寄存器再通过Capture操作让组合逻辑跑一拍最后把结果Shift出来比对。这套机制把“内部状态可控可观测”这个需求变成了现实ATPG工具也才能在此基础上生成高效的测试向量。Tessent原Mentor旗下现在Siemens EDA的DFT工具链在业界用得非常多尤其在数字逻辑测试这块Tessent Shell提供了从DFT规格定义、Scan插入到ATPG向量生成和验证的完整流程。这里我基于实际项目经验把Scan Chain插入和ATPG全流程拆开来梳理一遍顺带把常见的DRC错误整理成一份排查手册。1.2 Tessent工具链的流程架构Tessent DFT流程大体分几个阶段读入网表和库文件建立design环境定义DFT配置scan chain数量、scan clock、复位信号、测试模式执行DRC检查确保设计满足可测性要求插入scan逻辑包括scan flip-flop替换、scan chain连接、测试控制信号生成再跑DRC确认插入后无违例生成ATPG pattern做故障仿真验证覆盖率输出最终网表、pattern文件和测试协议文件。整个流程里最花时间的往往不是插入本身而是DRC排查。Tessent的DRC检查项非常细跑一次会出来几十上百条消息新手最容易被吓到但其实核心的error就那么几类后面我会详细拆解。工具选型方面Tessent相较于其他DFT工具有一个明显优势它的DRC规则库和ATPG引擎结合得很紧密检查出来的错误直接关联到pattern生成阶段的故障模型不像某些工具DRC过了但生成pattern时还是各种问题。而且Tessent Shell的脚本体系是Tcl风格可以直接和SDC约束、网表操作混在一起写自动化程度可以拉得很高。2. Scan Chain插入前的核心准备2.1 库文件、网表和约束的准备动手之前工具环境里必须备齐这几类文件缺一个后面都可能跑出让人摸不着头脑的错门级网表综合后的netlist通常是Verilog或VHDL格式标准单元库Liberty库文件.lib包含逻辑单元、时序信息、功耗信息Tessent需要从这里读单元的scan属性测试库如果有某些工艺库会单独提供带scan端口的单元库如果没有工具会尝试自动映射替换物理约束时钟定义create_clock、复位信号、异步信号、IO约束SDC文件。特别要提一下SDC文件。Tessent读SDC和STA工具不完全一样但用到的时钟约束必须完备。很多DRC错误比如clock not configured、clock mixing根本原因就是SDC里没定义清楚时钟或者定义了但在DFT规格里没有正确关联。用实际项目举例假设我们有一颗SoC内部有3个时钟域比如CPU主频1GHz、外设总线和DDR控制器还有若干个异步复位域。这种设计在Scan插入时最常见的问题是跨时钟域的capture丢数据以及异步复位在shift模式下被意外释放。2.2 DFT规格文件的定义方式在Tessent Shell里核心的输入是dft spec文件用Tcl语法描述所有测试相关配置。一个最小可用的dft spec大致结构如下# 指定时钟端口和频率 add_clock -port clk_primary -period 10.0 # 定义scan chain规格 add_scan_groups -name scan_group_top add_scan_chain -name chain0 -group scan_group_top -create_specification -share_all_inputs # 复位的处理 add_test_control -signal reset_n -active low -mode shift # scan时钟定义 add_scan_clock -port clk_primary -group scan_group_top # 指定pattern类型 add_pattern -type scan -name scan_chain_test这里有几个细节要注意时钟定义方式。很多项目里物理时钟端口名和功能时钟端口名不一致或者时钟经过PLL/分频器后内部才产生。这种情况下Tessent需要你把功能时钟端口加进去然后用add_clock指定端口和周期。如果时钟在内部由PLL产生需要设置add_clock_pin或者定义好related clock。Scan chain的分组。一个大的设计通常需要多条chain每条chain的寄存器数量要尽量均衡。Tessent的add_scan_chain如果不指定寄存器列表工具会自动做chain balancing。但是如果某条chain跨了太多功能模块后端布局布线时scan绕线会很难受物理实现阶段往往会有问题。所以建议在做DFT规格前就先和后端工程师对齐一下根据floorplan把chain的划分先定下来不要完全依赖工具自动分配。复位信号的处理。核心原则是shift模式下复位必须被抑制capture模式下才能按需使用。否则shift过程中寄存器一直被复位拉回初始态scan data根本传不进去。上面的例子里-mode shift就是在shift阶段强制复位无效。2.3 Scan Clock和复位信号的物理约束除了逻辑上的配置物理上还要约束scan clock的树和复位树的绕线。这不是Tessent直接管的但会影响DRC。比如你的scan clock端口直接接到寄存器时钟端绕线距离长了会导致时钟偏斜过大在shift模式下高频跑测试时会出错。常见的做法是在综合阶段给scan clock端口单独设一个set_clock_tree_options或者在physical synthesis时指定clock tree的target。另外一点容易被忽略scan clock通常要在top level单独引出来这个原则。如果底层模块已经有自己的测试时钟引脚打入subsystem后再从top合成会导致不同层级的scan时钟路径上多了逻辑Tessent在DRC阶段会报clk logic violation。最稳妥的做法是scan clock独立引出至少不要在path上放组合逻辑。同样复位信号要保证在shift模式下是无效且稳定的。如果复位来自某个控制寄存器而这个寄存器本身也被scan到了chain里那一定要在DFT规格里把这个寄存器的控制时序处理好否则DRC必然报reset_problem。我们曾经遇到过复位由测试模式寄存器控制的情况折腾了好久才意识到问题出在复位依赖了scan register的输出属于典型的DFT控制信号依赖未处理好。3. Scan Chain插入的实操过程3.1 从读入设计到插入完成准备工作做完就可以在Tessent Shell里跑流程了。用一个典型的脚本片段说明# 启动Tessent Shell并读入设计 read_lib /path/to/lib/fast_vtt.lib read_verilog /path/to/netlist/top.v read_sdc /path/to/constraints/top.sdc current_design top # 读入DFT规格 add_dft_specification /path/to/spec/top_dft_spec.tcl # 运行DRC check_dft_rules -verbose # 如果DRC干净做scan insertion insert_dft write_verilog -replace -output ./out/top_scan.v write_dft_specification -replace -output ./out/top_dft_out.tcl跑完check_dft_rules后重点关注几类消息Error必须修复存在的话插入和ATPG都无法进行Warning可能影响覆盖率或测试稳定性建议修复Info记录性信息帮助确认配置生效情况。如果DRC有error先修完再往下走。3.2 插入过程中的具体参数选择Scan chain的相关参数直接影响测试时间、IO复用和物理实现难度。Chain数量选择假设设计里有100,000个scan flip-flopChain数量 40则每条chain长度约 2,500 个寄存器。测试时钟频率 50MHz则Shift一个pattern需要 2,500 * 2shift in shift out算一次循环 5,000个周期即100us。如果ATPG生成2,000个pattern则总shift时间约200ms。这只是shift时间而测试成本是按pattern数、chain长度、测试频率三个维度共同决定的。chain数量增多则可以减少每条chain长度缩短测试时间但会增加scan IO的数量和布线压力需要根据IO资源和后端的绕线拥塞状况来权衡。Shift频率选择Shift频率并不是越高越好。事实上我在项目里踩过坑的经历是一开始为了缩短测试时间把shift频率调到100MHz仿真毫无问题但ATE上机跑pattern时某些角落的die测出来偶发fail。追查下来问题出在shift频率太高scan clock tree偏斜在多条chain之间的差异被放大加上测试过程中动态压降的影响导致某些寄存器采到错误数据。后来把shift频率降到50MHz覆盖率不变稳定多了。ATPG工具针对shift频率会做一个隐含假设shift过程中所有寄存器都能在每个时钟沿稳定移位。如果这个假设不满足就是你自己的clock tree和时序收敛问题ATPG生成的pattern在低速功能测试时也许没什么异常但在ATE上就是会有case失效。3.3 插入后的验证衔接插入后一定要重新读入scan网表重新跑DRC和STA约束一致性检查。这次的重点是确认插入后有没有引入组合loop有没有新的DRC error例如chain完整性error比如某些寄存器没被正确替换成scan flip-flop输出网表里scan enable、scan in/out信号的连接是否正确。我一般还会跑一个快速综合或者逻辑等价性检查LEC确认插入scan逻辑前后功能等价。DFT插入阶段会替换寄存器为带scan端口的版本如果映射关系出错LEC会直接报出来。这一步不要省。4. ATPG流程的完整解析4.1 故障模型与覆盖率ATPG的核心目标是生成一组pattern使得足够多的物理故障能够被检测出来。业界最常用的故障模型是stuck-at fault固定0/1故障它假设某个节点在制造过程中物理短路到电源或地导致该节点逻辑值永远固定为0或1。实际项目中还会根据工艺节点增加transition delay fault跳变延迟故障的测试专门检测时序类缺陷。Tessent里默认会同时生成两类pattern但过渡故障pattern通常需要两个capture时钟要求设计在ATPG模式下能够两拍连续capture这个约束需要在dft spec里提前定义好add_capture_clock数量。很多人第一次做过渡故障测试跑出来覆盖率远比stuck-at低排查半天发现其实是因为capture时钟配置不对。覆盖率计算公式是检测到的故障数 / 总故障数。假设设计有500万个可能故障点ATPG生成pattern后覆盖了490万个则stuck-at覆盖率为98%。剩下的故障点无法检测的原因可能是冗余逻辑比如某些逻辑本身不会影响任何输出约束限制比如异步路径被set_false_path排除不可控制/不可观测点某些内部节点没有通过scan寄存器串入链中。4.2 Pattern生成的关键配置Tessent里ATPG的流程大致如下# 读入scan插入后的网表和库 read_lib /path/to/lib/fast_vtt.lib read_verilog /path/to/out/top_scan.v read_sdc /path/to/constraints/top.sdc current_design top # 读入dft spec并检查 add_dft_specification /path/to/out/top_dft_out.tcl check_dft_rules -verbose # 生成stuck-at pattern set_pattern_type -type stuck_at create_patterns -pattern_count_limit 2000 -output_compression on report_pattern_coverage write_patterns -format verilog -output ./out/top_stuck.v关于compress和fault coverage还要多说两句现在Tessent默认会做test compression也就是同时生成scan compression的pattern。在压缩模式下你看到的pattern count大幅度减少但是每个pattern在ATE上的实际数据量反而可能更大因为有compressor/decompressor逻辑。对ATE存储深度紧张的项目压缩是必须的但如果你在前期验证跑仿真压缩pattern的仿真时间会比非压缩长因为要额外仿真解压逻辑。建议前期验证用非压缩pattern快速确认功能无误最终的量产pattern再开压缩。4.3 Pattern仿真验证与覆盖率报告分析生成的pattern不能直接用先跑仿真确认pattern在网表级的行为正确。Tessent的write_patterns可以输出多种格式常用的是WGL格式和Verilog格式。WGL是ATE标准格式Verilog格式则方便在仿真器里跑。我习惯上会用VCS或者QuestaSim做一次快速仿真验证。流程写一个testbench把scan链的shift/capture操作按pattern文件里的定义驱动起来比较每个cycle的预期输出值。这一步很大概率会暴露出dft spec里的问题比如某个信号在spec定义时相位反了、复位时序在pattern仿真路径上不对等等。覆盖率报告建议用如下命令report_pattern_coverage -verbose report_faults -class undetected -output ./out/undetected.rptreport_faults -class undetected可以列出所有未被检测的故障点按模块/层次归类。分析这些未检测点是提升覆盖率的核心手段。常见原因有三类模块内部存在冗余逻辑模块被设为false_path或clock gating导致ATPG认为不可测某些异步set/reset信号在测试模式下被强制为无效值导致相关路径不可测。5. 常见DRC错误的排查方法5.1 Tessent DRC错误分类Tessent输出DRC消息的格式一般长这样[DRC-0100] A scan chain has less than 2 scan cells. [DRC-0507] Scan clock is not properly constrained. [DRC-0017] Test control signal has unintended dependency.不同版本的错误码编号可能不一样但问题类型相对固定。根据我个人的经验90%以上的项目DRC error不出下面这几种可以按类别排查错误类别典型现象最常见根因解决思路Clock相关Clock not allowed / clock mixingSDC没定义或定义错误跨时钟域capture未处理检查SDC完整性和dft spec中的时钟关联Reset相关Async reset违规 / reset no-function异步复位在shift模式未抑制用add_test_control配置复位或修改RTL复位架构Chain完整性Chain length异常 / scan cell不可替换寄存器类型不支持scan部分always块不可综合成scan FF检查库单元检查代码风格确保时序逻辑能被综合成为标准DFF控制信号依赖Test control has dependency测试使能信号逻辑依赖scan寄存器修改控制生成逻辑测试使能信号必须来自固定引脚跨时钟域Clock domain crossing DRC不同时钟域的capture未做同步隔离在dft spec中设置capture时钟分组或使用lockup latch5.2 逐个拆解高频DRC报错Clock相关DRC这类错误排名第一。典型报错是DRC-0400: Illegal clock mixing in the same scan chain或者DRC-04xx: Clock merging cannot be performed。根因分析不同的时钟域不能混在同一条scan chain里除非你显式配置了lockup latch。工具默认要求每条chain内部的寄存器必须由同一个测试时钟驱动如果chain里的寄存器一半是clk_a、一半是clk_b工具直接报错。解决办法如果不同时钟域的寄存器必须串在同一条chain插入lockup latchTessent可以自动插入或者手动在dft spec里设置-clock_domain。如果chain分属不同时钟域干脆分chain让chain之间互不相干。这样在ATE上shift时就能按域分别供给时钟。复位信号DRC典型报错类似DRC-0502: Invalid test control signal或者DRC-0507: Asynchronous set/reset signal without test mode constraint。根因分析设计里的异步复位信号在测试模式下没有固定为有效或无效。shift阶段复位必须无效否则移位失败capture阶段复位需要满足特定时序否则故障捕捉无效。还有一个很常见的坑异步复位本身连接到寄存器的异步端但dft spec里完全没有提到这个信号。工具默认认为这个异步复位是constant value于是在生成ATPG pattern时希望推出复位无效逻辑实际网表上却根本无法满足DRC才会报出来。解决思路在dft spec里明确这个异步复位信号在shift和capture时的取值。例如add_test_control -signal reset_n -active low -mode shift -state 1 add_test_control -signal reset_n -active low -mode capture -state 1意思是shift和capture期间reset_n都固定为高电平复位无效。Chain完整性DRC典型报错DRC-0100: Scan chain name contains fewer than 2 scan cells以及DRC-0200: Some flip flops are not replaced by scan flip flops。第一种说明chain没建起来或者长度太短。检查dft spec里scan chain的配置是否被正确读取也检查网表里是否有足够多的标准DFF。如果设计里大量逻辑被综合成了latch或者基于门控时钟的寄存器这些是不能直接做scan的需要进行代码重构。第二种要关注的是单元库是否带scan端口。如果库里提供的DFF型号本身没有scan版本工具就替换不了log里会出现warning。这种情况只能换库或者让综合阶段先去换库单元。5.3 排查技巧怎么高效读DRC报告Tessent生成的DRC报告可以直接用文本编辑器打开刷但几千行消息靠人眼看效率太低了。我的建议是养成用脚本过滤的习惯report_dft_rules -severity error -output ./out/drc_error.rpt report_dft_rules -severity warning -output ./out/drc_warning.rpt把error单独提出来每一条都定位到具体的instance path。打开-verbose选项后报错消息里会带上出错的寄存器或者net的hierarchical path直接顺着去查RTL或者网表。如果是跨时钟域的error把出错的每一条chain的寄存器列表统计出来按模块名分组一眼就能看出是哪两个模块之间的寄存器被串到一起了。这个信息用脚本提取最方便手动翻很累。5.4 其他工具场景下的DRC对照参考虽然本文主题是Tessent但搜索热词里有人提到Vivado、KLayout、OrCAD的DRC这里顺带做个对照帮助理解不同工具语境下的DRC含义Vivado的DRC如DRC RTSTAT-2 partial route conflicts属于FPGA后端实现时的物理合法性检查报的是布线冲突和Tessent的DFT规则检查完全是两回事但排查思路相通——先定位冲突的net再缩小到具体模块。KLayout的DRC是基于版图的几何设计规则检查检验走线间距、宽度等物理规则是否满足工艺要求。OrCAD的DRC属于原理图电气规则检查检查网络连接、引脚悬空等逻辑问题。虽然名字都叫DRC但检查对象和目的各不相同。在芯片DFT语境下Tessent的DRC是为了保证“可测试性”这一逻辑属性成立它不关心物理间距只关心逻辑可控/可观测性是否被破坏。6. 项目实战中的避坑经验6.1 从综合到DFT的交接阶段很多DFT问题不是DFT阶段引入的而是综合阶段埋下的。最常见的情况是RTL里写了异步复位/置位逻辑综合后没有做约束导致DFF的异步端由内部逻辑驱动而在测试模式下无法固定DFT工具只能报错。因此在跑DFT之前先检查综合脚本里是否处理了以下内容所有异步复位都被约束为test mode下可取固定值综合时已经正确保留和优化了时钟门控单元clock gating cell而不是把门控逻辑打散成普通组合逻辑时钟树上的缓冲器分析正确DFT工具添加test clock引脚后后端不会因为时钟树结构变化导致时序违例。如果项目进度允许强烈建议在综合阶段就定义好DFT相关引脚scan enable、scan mode、test mode等并提前和后端对齐避免DFT阶段发现引脚端口不足或者后端规划冲突。6.2 Test Compression与ATPG的取舍现在很多项目直接上test compression因为裸scan chain的pattern数据量太大。Tessent的test compression是自带的原理是用组合逻辑在输入侧做解压、在输出侧做压缩从而用更少的ATE通道传输同等容量的测试数据。但这玩意不是免费的引入了compressor/decompressor逻辑本身有面积开销压缩逻辑可能引入新的DFT DRC error因为它也是一种组合逻辑反馈由于压缩逻辑的存在某些故障点可能因为观察路径被压缩而丢失观测性压缩pattern的外部故障覆盖率有时候低于非压缩pattern。我的建议很简单如果项目面积预算允许a small amount of test logic并且ATE通道数量不是你芯片封装引脚数的瓶颈那优先用非压缩scan chain。只有当你真正确认ATE通道不够或者pattern数据量突破存储上限的时候再上compression。使用compression的代价是排查DRC问题和故障诊断会变复杂调试难度指数级上升。6.3 时序收敛与Scan chain测试的关系Scan chain的测试是通过移位寄存器原理进行的而shift频率和组合逻辑延迟没有关系它只和寄存器到寄存器之间的clock skew有关系。所以理论上shift频率可以设置的比功能时钟高前提是clock tree skew足够小。但capture操作不同。capture那一拍实际上是让寄存器去捕抓组合逻辑的计算结果和正常功能时序一样。所以ATPG生成的pattern尤其是transition delay pattern必须满足时序收敛条件。这也就是为什么过渡故障pattern的capture频率通常比shift频率更低甚至比功能频率更低。如果你项目里ATPG跑transition pattern后仿真不过优先考虑是不是SDC里false path和multicycle path没有在ATPG模式下排除对应路径。有一个实用技巧分享跑ATPG的时候可以单独set一份用于ATPG仿真的SDC在里面把所有非测试相关的约束改成更保守的值。比如功能模式下对某些异步接口设了set_false_path但ATPG模式下这些路径如果不测就应该在SDC里统一约束为不可测否则工具在生成pattern时会尝试沿这些路径推导浪费时间还产生无数低置信度的vacuously detected故障最终覆盖率虚高或仿真异常。7. 一份可以直接抄作业的Checklist最后整理一份实际操作中的检查清单按流程顺序排列做DFT的时候可以逐项打勾确认门级网表和库文件版本一致SDC里的时钟定义完整DFT spec中每个时钟域的scan chain独立配置且chain长度均匀所有异步复位/置位信号在shift和capture模式下都有固定值约束scan clock端口无组合逻辑复位端口无组合逻辑DRC error全部清零warning逐条确认不影响覆盖率插入scan后跑LEC确认功能等价ATPG生成stuck-at pattern覆盖率目标达98%以上生成transition pattern覆盖率按产品等级要求消费级通常90%以上Pattern仿真通过在门级网表下无时序违例输出网表和pattern文件整理归档同时输出DFT spec供后端使用。第7条和第8条的覆盖率目标因产品而定。车规芯片的stuck-at覆盖率要求往往在99%以上transition也比消费级严格得多。在做覆盖率分析时不要只看最终数字一定要去看undetected fault的list确认没检测到的都是哪些模块、哪些类型的故障必要时通过增加pattern数量、调整约束来提升。我在实际项目中还发现一个非常隐蔽的问题某些工艺库的单元库里带scan属性的DFF和普通DFF的功耗特性不同后端用IR drop分析时如果电源网络设计不足scan shift时大量寄存器同时翻转会导致局部电源电压跌落进而出现测试时fail但功能正常的现象。这属于DFT和后端协同分析的问题排查起来非常痛苦建议在项目规划阶段就把scan shift场景纳入功耗分析。另外Debug ATE fail时如果怀疑是scan chain硬件问题有一个很有效的诊断手段——Tessent生成的scan chain test pattern也就是专门验证每条chain本身移位通路是否正常的pattern。这种pattern覆盖每个scan cell的shift in/out路径一旦某条chain因为物理缺陷断开chain test会直接报出停在那个断点cell的位置能快速定位是芯片哪个区域的物理损伤。这个环节在低良率排查时价值极大务必保留在量产pattern序列里。我个人经验是DFT流程本身并不复杂命令也就那几个真正区分一个工程师水平的是DRC报错时的分析能力和debug pattern仿真失败的思路。能把Tessent log里的每一类消息都解释清楚成因和影响遇到覆盖率不足时不盲目加pattern而是能准确判断出是约束问题还是架构问题这大概就是DFT工程师从入门到熟练的分水岭。
