拓冰网站定制 
1. 别急着敲命令先想清楚Scan Chain和ATPG到底在防什么做DFTDesign for Test可测试性设计的工程师很多人被问过同一个问题花了那么多area成本插扫描链究竟图什么回答这个问题之前我们先看一个再常见不过的场景一颗芯片功能仿真全过、时序收敛、物理设计也做完了结果到了ATE自动测试机上第一颗芯片拉回来功能根本跑不起来。这时候你怎么判断是哪个module出了问题如果设计里没有插入scan chain你只能用探针一根一根在显微镜下查电平、核对信号等于大海捞针。而有了scan chain之后DFT工程师可以像点名一样把芯片内部成千上万个触发器串成一条或多条移位寄存器链通过TDI/TDO端口把测试激励灌进去、把响应吐出来按图索骥定位失效点。这就是scan chain的本质给芯片内部的所有时序单元装上可观测的眼和可控制的开关。说回工具本身。Tessent这个工具业内习惯称它为Mentor的DFT套件现在纳入了Siemens EDA它涵盖从RTL可测性分析、扫描链插入、压缩逻辑插入到ATPG向量生成、故障仿真、诊断的完整流程。和另一家主流EDA大厂的DFT方案相比Tessent在压缩Test Compression技术和EDTEmbedded Deterministic Test架构上起步早、生态成熟而且Tessent Shell这套命令环境和ATPG引擎的交互方式非常灵活适合做深层次定制。很多工程师第一次接触Tessent时会觉得命令又多又杂其实只要抓住一条主线——scan insertion把结构搭好ATPG把向量算出来整个流程就清晰了。这篇内容是写给从零开始接触Tessent的DFT新人以及虽然跑过流程但对DRC错误排查还没有形成体系化思路的工程师。我会把scan chain插入和ATPG两条主干流程完整走一遍最后用一整节专门拆解常见的DRC错误类目每一类都给出从报错现象到根因定位的完整排查链路。这些排查经验不是从用户手册里抄来的是我在多个项目里从凌晨两点的报错日志里一行一行看出来的。2. 开工前的数据准备清单少准备一样后边全是坑Scan链插入和ATPG流程和普通逻辑综合最大的区别在于——对设计数据的完整性和一致性要求极高。逻辑综合缺了一条约束顶多timing难看一点DFT流程里缺了scan definition或者SDC约束给错DRC阶段会蹦出一堆莫名其妙的violation排查起来能把人逼疯。2.1 输入文件里最容易被忽略的几样东西先列一份标准输入的检查清单每一项我会说明它为什么必不可少输入项来源缺失/错误的后果综合后网表Verilog/VHDLDC/Genus综合输出无网表则一切无从谈起UPF统一功耗格式可选但强烈建议前后端功耗设计文档多电源域设计缺UPF会导致isolation/retention cell处理错误SDC约束综合阶段同步提供scan clock定义错DRC直接报出几百条violationScan Definition/Scan ConfigDFT工程师根据架构定义扫描链数量和端口不匹配ATPG阶段无法生成有效向量Technology库的Test Model工艺厂/库厂商提供缺test model时Tessent无法做DRC检查Finders/MMMC viewMulti-Mode Multi-Cornerlib/db文件和PVT角标配置缺少时序视角导致ATPG仿真时出现X态冲突覆盖率虚高或偏低这里90%的新人会忽略的一个细节是Test Model。Tessent做DRC并不是直接用功能仿真用的Verilog库模型而是需要用tsdb的Test Model格式文件这些文件里包含了每个标准单元在测试模式下的行为描述。你如果只读了lib文件很多DRC规则是跑不起来的。在Tessent Shell里你会在report_tsdb_cells这类指令的输出来确认lib到test model的映射是否完成。2.2 关于SDC约束必须强化的一个认知DFT工程师和做逻辑综合的工程师看SDC的视角完全不同。综合工程师关心时钟周期、input/output delay、真实路径上的时序收敛但DFT阶段我们更关心的是这些约束在移位shift和捕获capture两种模式下分别如何处理。Tessent处理时钟约束有个重要概念叫Clock Group。你在Tessent Shell里经常会看到类似set_dft_clock这样的命令来声明哪几个端口是扫描时钟。假如你希望scan chain在shfit沿使用上升沿而捕获沿使用下降沿这个信息在SCAN_DEFINITIONspf文件里是通过时钟极性字段来描述的。很多人SDC里只写了一个create_clock没有区分shift和capture条件下的不同时序弧DRC阶段就很容易报出与clocking相关的violation例如时钟沿冲突、setup/hold违规归因错误。所以经验之谈是在提交SDC给DFT流程之前先把时钟分组想清楚用注释把每个时钟是scan shift clock还是capture clock标出来后边你排查DRC报错会轻松十倍。2.3 用Tessent Shell之前的启动和常规检查启动Tessent Shell没有太多玄学一般就是tessent -shell然后在tessent shell交互环境里跑set_context dft -doscan read_verilog ./netlist/riscv_core.v read_cell_library ./lib/tsmc28hpc_tt_0p9v_25c.cbd read_core_description ./dft/riscv_core.core add_clock -port clk -period 10.0 set_dft_signal -view existing_dft -port scan_in -type ScanDataIn set_dft_signal -view existing_dft -port scan_out -type ScanDataOut set_dft_signal -view spec -port test_mode -type ScanEn新手经常犯的错误是忘了set_context dft。在Tessent Shell里上下文context决定了很多命令的合法范围。如果你在dft上下文中试图读入SPF文件就会收到和上下文不符的报错类似ERROR: (TDB-4100): The command does not apply to the current context.这类信息。所以第一步先明确自己在dft context底下而不是在standalone的setup context底下。读入网表和库之后先不要急着做插入。我习惯性会先跑一个简单的report_dft_signal和check_design看看端口识别、时钟声明、扫描定义是否有误。这里有一个很多人容易踩的坑网表中可能含有多个层次模块顶层有些端口没有连接。如果不先检查设计内部层次结构有没有unconnected port后边在drc阶段出现与hierarchy相关的violation时你会分不清楚是端口没接还是DRC规则本身的触发条件不正确。3. Tessent Scan Chain插入核心实操从Compile到Insertion的三段式如果说数据准备决定了你能不能跑下去那么scan insertion这节就决定了你ATPG阶段是爽一把就死还是如丝般顺滑。Scan chain插入在Tessent里不是一条命令就完成的它分成编译、规则检查、插入、验证几个阶段。3.1 第一步Specify Design和Specify Scan Chains在Tessent Shell里你需要明确告诉工具你要插几条扫描链、每条链上要串多少位寄存器、扫描端口怎么分配。这些信息通过add_scan_chains类命令来声明或者通过读取一个SCAN_DEFINITION文件SPF格式来导入。举个例子如果我有128个扫描触发器计划插4条链每条链32位那么端口设计可以是add_scan_chains -name chain0 -scan_in scan_in[0] -scan_out scan_out[0] -shared add_scan_chains -name chain1 -scan_in scan_in[1] -scan_out scan_out[1] -shared add_scan_chains -name chain2 -scan_in scan_in[2] -scan_out scan_out[2] -shared add_scan_chains -name chain3 -scan_in scan_in[3] -scan_out scan_out[3] -shared这里有个衡量指标叫Scan Chain Balance也就是每条链的长度是否均匀。链长严重失衡会直接导致ATPG向量数上升测试时间变长。比如4条链长度分别是40、30、30、28那么shift 40拍之后所有的数据才完全load进去短链实际是在空转效率损失是很直观的。所以Tessent在做scan chain balancing时做了不少优化。建议在综合阶段就让逻辑综合工具按balance目标来优化而不是插入阶段再去处理。实际操作中还涉及-view existing_dft和-view spec两个不同视图的理解。existing_dft是告诉Tessent设计里已经存在哪些DFT结构比如原来就扫描端口或者原先已有部分链spec则是声明你要新加入的DFT结构。这两类指令如果搞混会导致工具以为某条链已经存在而实际网表里根本找不到对应的连接后边的DRC会把这条链对应的很多规则直接报出来。3.2 核心命令insert_dft到底做了什么insert_dft这条命令概括了Tessent扫描链插入的所有内部逻辑。它做三件事对声明为Spec的扫描链进行综合连接、把普通触发器替换为带扫描功能的触发器、插入测试控制逻辑比如scan_enable的产生逻辑、时钟控制逻辑。展开说替换触发器时工具会做一次映射把RTL网表中的dff映射成库里的dff_s扫描D触发器。新加的扫描触发器比原触发器面积大所以综合阶段必须保留足够多的可替换单元。这里有个常见的经验在逻辑综合时工具通常默认选择普通时序单元如果你在综合时没有允许工具把非扫描触发器替换为扫描触发器配置compile_ultra -retime这类的优化选项对DFT的影响要特别小心那在Tessent插入时会报出找不到合适的扫描替换单元的问题或者是扫描替换后出现了额外的一级组合逻辑导致移位路径出现setup违规。插入过程还有一个容易踩坑的点时钟门控。如果设计里有大量clock gating cellICG在scan shift模式下这些ICG必须保持常开否则时钟打不进去触发器根本没法移位。Tessent处理ICG的常见做法是在scan enable有效时强制打开ICG。这个逻辑如果你在RTL里没有预留测试模式控制信号工具就会自动生成这样的控制逻辑插到网表里。高级用户会在RTL阶段就定义好scan_enable和scan_mode信号的传播路径避免插入阶段的控制逻辑过于复杂。但至少你要能看懂insert_dft之后网表多出来的那部分logIC知道它是干什么的。3.3 插入后的三条验证通路插完扫描链不是直接进ATPG就完了。很多芯片项目在这个阶段会做三件验证工作第一connection check。确保每条链从scan_in到scan_out路径上的触发器和逻辑都正确连接没有断链。Tessent Shell里的report_scan_chains命令会输出每条链的完整连接信息你可以在输出日志里检查链上寄存器的顺序是否和预期一致。第二等价性检查。插入扫描链之后的网表功能逻辑相比原始网表并没有改变只是触发器被替换为带扫描功能的版本。LEC形式化验证工具在这个阶段的比对范围为功能逻辑scan相关信号需要声明为常量。我记得第一次独立跑这个环节时就因为把scan_enable设为0还是1搞反了结果LEC报了上千个failing points但我去检查网表时却发现没有实际功能差异。其实这个设定是有讲究的LEC时需要把scan_enable设为0因为功能模式下扫描路径不应生效。第三在Tessent内部跑一次compliance DRC。这个DRC检查和ATPG之前的完整DRC不是同一个层次这是扫描链基本结构是否合理的一次预检比如shif t路径是否存在环路、是否有锁存器搭在扫描路径上挡住时钟等。具体DRC规则我在第五节单独细说这里先记住scan insertion完成之后至少要跑到这些基础规则全绿再去启动ATPG。4. ATPG向量生成把Scan Chain真正用起来Scan Chain插好了接下来就是ATPGAutomatic Test Pattern Generation自动测试向量生成的环节。ATPG是DFT流程里最能体现投入产出的一步——前面折腾半天就是为了这一步能生成一批高质量的测试向量给ATE机器用它们来区分好芯片和坏芯片。4.1 在动手前先理解Tessent ATPG的故事线Tessent ATPG的主干逻辑是从设计网表里识别出故障列表Fault List最常见的是Stuck-At故障固定故障也可以包含Transition Delay Fault迁移延迟故障对每个目标故障用自动生成的测试向量去定位它——通过scan chain把逻辑状态灌入电路跑一个或两个捕获时钟再把结果通过scan chain移出对比移出的响应和仿真预期值检测差异就是故障被检测到了最终统计故障覆盖率Fault Coverage和非检测故障的情况。整个流程是一条流水线中间某一个环节出错都会直接反映在覆盖率上。我遇到过ATPG跑出100%故障覆盖率但实际到ATE上就是fail的情况后来排查下来发现是因为Pattern在芯片上跑的时候时钟沿和扫描使能的时序设置和ATPG仿真假设不一致导致测试向量在芯片上根本灌不到位。所以ATPG阶段最微妙的地方在于——仿真能过不意味着硅片能过ATPG基础规则必须能反映芯片的真实时序。4.2 用Tessent Set Up Scan Patterns的标准步骤在Tessent Shell中ATPG的入口是create_patterns或者更常用的add_atpg_patterns相关流程。一个干净有效的启动流程会包含下面这些步骤# 确保处于atpg context set_context atpg -doscan # 读入已插入扫描链的网表读入test model库 read_verilog ../output/riscv_core_scan.v read_cell_library ../lib/tsmc28hpc_tt_0p9v_25c.cbd # 指定设计属性和故障类型 set_current_design riscv_core set_fault_type stuck_at add_faults -all # 运行ATPG引擎生成向量 create_patterns -class scan -auto_compress这里我要专门说明一下为什么先set_context atpg。Tessent Shell的上下文有点像操作系统里的权限管理你在dft上下文里跑create_patterns会直接报错因为这条命令在dft上下文根本不存在。这就要求你把scan insertion和ATPG当成两个独立的阶段来管理中间通过网表和SPF文件来传递数据。故障覆盖率是一个无法回避的指标。如果一个设计有100万个故障点那么100%覆盖率意味着100万个故障点里所有的都被成功检测。但实际项目中很难达到100%因为存在一些undetectable的故障比如冗余逻辑引起的不可检测故障UD faults。如果覆盖率低于预期第一步不要急着改ATPG流程先看report_summaries里的故障分类——有多少是detected可检测、undetectable不可检测、potentially_detected潜在的等等。这些分类会引导你判断覆盖率瓶颈到底在哪。举个例子如果undetectable故障集中在某个模块很可能是这个模块存在大量时钟门控且扫描使能信号无法完全控制这时候与其硬在ATPG上想办法不如回到RTL阶段调整可测性结构。4.3 EDT压缩与Tessent Test Compression的选择如果芯片规模大、扫描链数量多直接跑Full Scan不加压缩测试时间和向量数据量会爆炸。这也是Tessent在业界能打的一个重要原因——EDT压缩技术。Tessent Test Compression的核心是在扫描链的输入输出端加入解压缩器和压缩器。输入方向少量外部数据通道EDT channel通过解压缩逻辑展开成很长的内部扫描链输出方向内部扫描链的响应通过压缩器压缩回少量输出通道。关键点是解压缩器和压缩器本身必须设计成对X值免疫否则ATPG仿真里有一点X态传到压缩器整个压缩结果都对不上了。我个人的建议是如果设计规模达到百万门级以上直接上EDT压缩如果设计很小比如几十万门Full Scan不压缩也完全可行。压缩不是免费的它引入了解压缩器和压缩器的面积开销还会增加一些测试模式下的时序约束。小芯片硬上压缩成本和收益不成正比。另外如果设计中存在大量黑盒比如memory hard macro黑盒输出会有X态这些X态进入压缩器会污染压缩结果所以用压缩之前必须仔细检查X源。4.4 仿真与验证Pattern的方式生成Pattern之后不能直接拿给ATE厂商。Tessent生成的pattern文件有多个格式最常用的是WGL格式和STIL格式。在给ATE之前通常会在仿真器里把pattern和网表一起跑一遍确保pattern的行为和预期一致。仿真这一步要留意的坑是时序模型。功能仿真用的是timescale 1ns/1ps这种单位时间精度但ATPG pattern的时序精度往往不是纳秒级别而是皮秒甚至更高精度。如果仿真精度和pattern数据的精度不匹配仿真结果会差之毫厘谬以千里。Tessent生成的pattern通常会有timescale 1ps/1ps描述你在README里要把这个信息明确传给后端的测试工程师。另一个坑是X态传播。Tessent仿真阶段如果发现pattern仿真结果和预期不符最常见的原因就是X态。X态可能来自未初始化的存储单元、黑盒输出、或者异步复位信号没有在测试模式下被正确钳制。每一个X态的源头都要追根溯源否则覆盖率统计就会失真。5. 常见DRC错误排错实录从报错现象到根因定位的完整链路DRCDesign Rule Check设计规则检查在DFT流程里指的是可测试性规则检查。Tessent里这个环节被称为Test DRC或Compliance DRC。很多刚接触Tessent的工程师在DRC阶段被一堆violation吓到但其实DRC错误有非常清晰的分类体系。掌握这种按类排查的思路比死记硬背错误代码要有效得多。5.1 DRC错误的本质工具在问你的设计能不能被测试先说一个总纲。Tessent的DRC规则本质上都是在追问同一个问题设计里的每一个时序单元是否能够被独立、确定地控制和观测如果能这条规则pass如果不能就报violation。控制指的是能否通过scan chain把触发器置成任意需要的状态观测指的是触发器的状态能否通过scan chain移出。一旦设计里出现组合逻辑环路、锁存器失控、异步信号反复翻转、时钟不可预测沿等问题测试就不再确定DRC自然就挂了。基于这个总纲见招拆招就比背规则库有效得多。下面我挑几个在多个项目里反复出现的典型DRC错误分别讲清它们的报错形态、根因和修复方法。有些是我自己踩过的有些是我帮同事debug时并肩解决的。5.2 S0/S1类violation时钟和复位控制性检查典型报错形态DRC报出类似Rule S0或Rule S1的violation日志上会跟一段说明大意是某个时钟信号或复位信号既不是常量又不能被scan enable信号控制。根因分析这条规则的本意是确保在shift模式下时钟可以由测试时钟严格控制不至于被功能逻辑里某个内部节点干扰。举个最常见的场景假设clk_g是功能逻辑经过与门产生的一个内部时钟。assign clk_g clk en;在功能模式这个电路没问题。但在测试模式如果你期望用clk_g作为扫描时钟就有一个致命问题clk和en都必须严格可控否则shift过程中时钟出现毛刺数据移位操作就不正确。Tessent会依据测试模式下的时钟约束来判断clk_g是否能被安全使用如果判断不能这就要打violation。修复思路一般在RTL阶段就为内部时钟插入测试时钟旁路test clock bypass确保测试模式下用干净的测试时钟不经过功能逻辑门控。如果你改不了RTL只能通过SDC里设置test clock来告诉工具只有哪个端口是测试时钟工具才能决定哪些内部时钟不必过分较真。5.3 锁存器相关的latches violation典型报错形态DRC报错Latch或S_Class规则指出某一个锁存器无法被直接控制或观测。根因分析Tessent对锁存器的策略是要么锁存器处于透明模式transparent要么锁存器的输出不影响扫描链的确定性。如果锁存器在测试模式下的行为是asynchronous的——时钟关掉后它还保持上一次的值——那么scan chain把数据load进去的时候锁存器可能出现hold问题即扫描链数据可能在锁存器不透明时更新导致数据丢失。修复思路大多数库都会提供带专门的扫描旁路功能的锁存器单元比如scan_latch把普通锁存器替换成这类单元让测试模式下锁存器变成一条直通路径。如果库里没有这种单元就需要在锁存器周围增加测试模式控制逻辑确保锁存器在scan模式常开。5.4 与时钟沿相关的setup/hold类violation典型报错形态DRC报出Clock类或Timing类的violation经常同时出现在shift沿与capture沿的检查报告里。根因分析Tessent在ATPG流程里做时序DRC其实是一个非常精细的过程。假设你设定shift在时钟上升沿capture在下降沿那么工具会检查两个方向上是否满足建立保持时间。由于设计的scan enable信号往往有很长的RC延迟在capture沿切换时scan enable可能还没完全稳定这会导致移位链路和捕获路径发生违规。修复思路这一类问题的修复往往不是改建网表而是调整测试时序test timing。你可以在Tessent Shell中用set_dft_timing或ATPG阶段的命令来指定时钟上升时间和下降时间、时钟沿设置等参数。另外如果scan enable信号从芯片管脚到各触发器延迟过大建议在插入环节让工具重新Register scan enable用set_dft_signal -view spec -port scan_enable -type ScanEnable -hookup_pin ...指令来重建和控制测试模式控制信号的扇出树。在所有时序类DRC violaton里scan enable的扇出过大会引发的问题绝对要排前三。记住关键是scan enable的时序要针对capture模式做balance而不是只在shift模式下考量。5.5 与X态和仿真相关的X source类violation典型报错形态DRC报告X-propagation或Unmodeled Cell类violationATPG阶段经常会看到Warning: X values may be captured in ...这样的描述。根因分析在ATPG仿真中如果某个单元输出X态并传播到捕获的触发器上那么这个触发器的最终状态就是不确定的pattern对比时无法判断芯片是好是坏。X态的来源很多未初始化的RAM/ROM黑盒输出、模拟宏单元的输出、电平转换器level shifter在电气特性上无法确定时的输出等。修复思路首先黑盒类X源对Tessent来说可以做black box extraction只要把黑盒输出作为dont care处理不给它们参与覆盖率统计就可以避免污染。但更根本的修复是让这些X源在测试模式下被钳制到确定值。比如在RAM周围加BIST模式钳制逻辑让RAM输出在非BIST测试时保持为一个稳定的已知值。另一种常见做法是在测试模式下把黑盒的output使能信号拉为无效态模拟宏模块输出隔离电阻隔离掉了。5.6 工具认知里很微妙的一类partial route conflicts在DFT流程的对应网络热搜词里有一批是后端布线DRC相关的内容比如[drc rtstat-6] partial route conflicts、vivado报错drc rtstat-2。严格来说这些不是Tessent的DFT DRC但在真实项目里Tessent ATPG跑完生成网表给后端做布局布线后端工具在route阶段经常冒出这一类和布线资源相关的DRC。我碰到过一次特别典型的情况ATPG生成的pattern里面有大量测试时钟频率很高比如200MHz后端布线时为了满足这些高耸的时序要求导致局部网线的布线密度超高出现了partial route conflict。当时我们查了好几天最后定位到根因是测试时钟树综合阶段没有给测试时钟专门设置更高的skew margin导致布线阶段信号完整性无法满足要求。这提示DFT工程师在交网表给后端之前把自己的测试约束写得尽量干净不要等后端报了一堆routing DRC再回来扯皮。5.7 特殊且容易被忽视spare cell/ECO cell带来的violation典型报错形态DRC报错指到某一个没有逻辑连接的实例上日志里说这个cell未连接到任何信号或存在连接错误。根因分析很多项目会在网表里故意保留一批spare cells备用单元和ECO cells以便后续流片前小改动使用。但这类cell如果输入端悬空或者输入被接到了常0常1电源上在测试模式下这些cell的输出可能出现X态。更讨厌的是如果spare cell的输出连着一条扫描链上的某段组合逻辑它们可能会影响扫描链的确定性。修复思路在Tessent读取网表时把spare cell设置成dont_use或者做exclude操作让它们不参与扫描链连接运算和DRC检查。如果这些cell的输入输出接到扫描链上了那你必须回头和后端工程师确认这些物理上的连接到底是什么目的。如果没有目的最好的方式是物理阶段把它们修剪掉而不是在DFT里硬撑着。5.8 排查DRC的通用方法分段排除法说了这么多具体错误最后再分享一个通用排查法我给它起名叫分段排除法。第一步缩小violation范围。Tessent会把DRC violaiton按规则类和设计层级报告出来。你不需要一次性解决所有violation先按规则类别筛选。比如你先看report_drc -violations -class Clock把所有clocking violation单独调出来。这样做的好处是同一类violation往往源于同一个根因一次修复能解决一批报错。第二步定位到具体例化路径。查看violation的具体位置它通常会写到某个module例化的完整层次路径比如chip_top/u_core/u_alu/u_adder/U3。用这个层次路径去网表里看到底是什么逻辑单元。第三步反向推导工具为何报错。打开这个cell周围100um范围内的逻辑画一下它的输入输出连接问自己这条路径在shift模式下能否被确定控制在capture模式下会不会产生X态如果不能再顺着信号扇出树往回找一定存在一个失控的输入源。第四步修复并回归。修复手段要优先采用结构修复如加旁路、替换单元、增加钳制逻辑而不是靠改约束文件绕过。约束文件写得太宽松DRC虽然放过了但ATE测试上可能啪啪打脸。我见过不止一个项目因为DRC violation靠改约束掩盖结果后边量产良率出了问题才回头来找。6. 覆盖率逼近与Pattern写出的最后一步把关DRC全绿之后还要处理覆盖率、压缩和pattern输出几个环节。这几个环节看似收尾但实际上也藏着不少经验。ATPG的故障覆盖率目标通常在95%以上很多设计要求在98%甚至更高。如果达不到先检查三个方向第一是否存在大量testability结构不足的逻辑。比如异步FIFO的控制逻辑、没有复位端且初始值不确定的寄存器组这些地方因为状态不可控会成为undetectable fault的重灾区。第二是否存在约束过紧导致ATPG引擎无法充分挖掘。在Tessent里set_atpg -auto_compress是可以自动压缩向量数量的但压缩过狠会牺牲覆盖率。有一个平衡点需要调如果你的覆盖率差一点点就能达标试着把压缩比调低放弃一部分向量压缩来换覆盖率。第三测试时钟是否覆盖了所有时钟域。多时钟域设计在ATPG阶段比较容易漏。比如有两个时钟域A和B它们之间的异步路径上存在同步器如果你的测试策略没有为B域生成独立的向量序列B域的某些故障就测不到。Tessent支持对多时钟域设计分别生成测试序列配置时要注意set_atpg -capture_clock off或者add_delay_fault这类命令对不同时钟域的区分。Pattern写出的最终形式也需要格外注意。我给出的建议是ATPG生成的vector文件wgl/stil/vcd不要直接扔给测试厂。理想的做法是在Tessent内部先做一次dofile run形式的仿真回归把pattern在RTL仿真器里过一遍确保X态行为和覆盖率统计没有偏差。跑完一遍之后再写STIL格式IEEE 1450给ATE厂商STIL格式在复杂时序和压缩配置的表达上比WGL更标准。写完pattern文件还没完。最后我对每个项目都会做一次golden media归档包括以下内容最终网表scan_insert后版本、最终SPF文件、pattern波形文件、覆盖率报告、DRC violation的waiver文件如果存在。这些文件要保证和后端签核的网表版本完全一致千万不能出现ATPG用的是V3版网表流片用的是V5版网表这种事。教训太深刻了——DFT工程师是签核链路上唯一同时接触功能网表、测试结构、测试向量和时序约束四份信息的人任何一份版本错位造成的损失都以百万计。从scan chain插入到ATPG向量生成再到把向量干净地交到测试工程师手里我对这整套流程最大的体会是DFT不是一个孤立的阶段它是一个将可测试性思维贯彻到从RTL到流片全链条的工程过程。提前在RTL阶段考虑测试模式控制信号、在综合阶段约束扫描单元替换、在DRC阶段死磕每一条violation的根因每一步的严谨都会在后面的覆盖率报告和ATE良率数据里得到回报。在工具日志和silicon数据之间找到那条可信的因果链这种成就感是DFT工作最让人上瘾的地方。 Tessent Scan Chain与ATPG实战：从插入到DRC排错全流程解析
1. 别急着敲命令先想清楚Scan Chain和ATPG到底在防什么做DFTDesign for Test可测试性设计的工程师很多人被问过同一个问题花了那么多area成本插扫描链究竟图什么回答这个问题之前我们先看一个再常见不过的场景一颗芯片功能仿真全过、时序收敛、物理设计也做完了结果到了ATE自动测试机上第一颗芯片拉回来功能根本跑不起来。这时候你怎么判断是哪个module出了问题如果设计里没有插入scan chain你只能用探针一根一根在显微镜下查电平、核对信号等于大海捞针。而有了scan chain之后DFT工程师可以像点名一样把芯片内部成千上万个触发器串成一条或多条移位寄存器链通过TDI/TDO端口把测试激励灌进去、把响应吐出来按图索骥定位失效点。这就是scan chain的本质给芯片内部的所有时序单元装上可观测的眼和可控制的开关。说回工具本身。Tessent这个工具业内习惯称它为Mentor的DFT套件现在纳入了Siemens EDA它涵盖从RTL可测性分析、扫描链插入、压缩逻辑插入到ATPG向量生成、故障仿真、诊断的完整流程。和另一家主流EDA大厂的DFT方案相比Tessent在压缩Test Compression技术和EDTEmbedded Deterministic Test架构上起步早、生态成熟而且Tessent Shell这套命令环境和ATPG引擎的交互方式非常灵活适合做深层次定制。很多工程师第一次接触Tessent时会觉得命令又多又杂其实只要抓住一条主线——scan insertion把结构搭好ATPG把向量算出来整个流程就清晰了。这篇内容是写给从零开始接触Tessent的DFT新人以及虽然跑过流程但对DRC错误排查还没有形成体系化思路的工程师。我会把scan chain插入和ATPG两条主干流程完整走一遍最后用一整节专门拆解常见的DRC错误类目每一类都给出从报错现象到根因定位的完整排查链路。这些排查经验不是从用户手册里抄来的是我在多个项目里从凌晨两点的报错日志里一行一行看出来的。2. 开工前的数据准备清单少准备一样后边全是坑Scan链插入和ATPG流程和普通逻辑综合最大的区别在于——对设计数据的完整性和一致性要求极高。逻辑综合缺了一条约束顶多timing难看一点DFT流程里缺了scan definition或者SDC约束给错DRC阶段会蹦出一堆莫名其妙的violation排查起来能把人逼疯。2.1 输入文件里最容易被忽略的几样东西先列一份标准输入的检查清单每一项我会说明它为什么必不可少输入项来源缺失/错误的后果综合后网表Verilog/VHDLDC/Genus综合输出无网表则一切无从谈起UPF统一功耗格式可选但强烈建议前后端功耗设计文档多电源域设计缺UPF会导致isolation/retention cell处理错误SDC约束综合阶段同步提供scan clock定义错DRC直接报出几百条violationScan Definition/Scan ConfigDFT工程师根据架构定义扫描链数量和端口不匹配ATPG阶段无法生成有效向量Technology库的Test Model工艺厂/库厂商提供缺test model时Tessent无法做DRC检查Finders/MMMC viewMulti-Mode Multi-Cornerlib/db文件和PVT角标配置缺少时序视角导致ATPG仿真时出现X态冲突覆盖率虚高或偏低这里90%的新人会忽略的一个细节是Test Model。Tessent做DRC并不是直接用功能仿真用的Verilog库模型而是需要用tsdb的Test Model格式文件这些文件里包含了每个标准单元在测试模式下的行为描述。你如果只读了lib文件很多DRC规则是跑不起来的。在Tessent Shell里你会在report_tsdb_cells这类指令的输出来确认lib到test model的映射是否完成。2.2 关于SDC约束必须强化的一个认知DFT工程师和做逻辑综合的工程师看SDC的视角完全不同。综合工程师关心时钟周期、input/output delay、真实路径上的时序收敛但DFT阶段我们更关心的是这些约束在移位shift和捕获capture两种模式下分别如何处理。Tessent处理时钟约束有个重要概念叫Clock Group。你在Tessent Shell里经常会看到类似set_dft_clock这样的命令来声明哪几个端口是扫描时钟。假如你希望scan chain在shfit沿使用上升沿而捕获沿使用下降沿这个信息在SCAN_DEFINITIONspf文件里是通过时钟极性字段来描述的。很多人SDC里只写了一个create_clock没有区分shift和capture条件下的不同时序弧DRC阶段就很容易报出与clocking相关的violation例如时钟沿冲突、setup/hold违规归因错误。所以经验之谈是在提交SDC给DFT流程之前先把时钟分组想清楚用注释把每个时钟是scan shift clock还是capture clock标出来后边你排查DRC报错会轻松十倍。2.3 用Tessent Shell之前的启动和常规检查启动Tessent Shell没有太多玄学一般就是tessent -shell然后在tessent shell交互环境里跑set_context dft -doscan read_verilog ./netlist/riscv_core.v read_cell_library ./lib/tsmc28hpc_tt_0p9v_25c.cbd read_core_description ./dft/riscv_core.core add_clock -port clk -period 10.0 set_dft_signal -view existing_dft -port scan_in -type ScanDataIn set_dft_signal -view existing_dft -port scan_out -type ScanDataOut set_dft_signal -view spec -port test_mode -type ScanEn新手经常犯的错误是忘了set_context dft。在Tessent Shell里上下文context决定了很多命令的合法范围。如果你在dft上下文中试图读入SPF文件就会收到和上下文不符的报错类似ERROR: (TDB-4100): The command does not apply to the current context.这类信息。所以第一步先明确自己在dft context底下而不是在standalone的setup context底下。读入网表和库之后先不要急着做插入。我习惯性会先跑一个简单的report_dft_signal和check_design看看端口识别、时钟声明、扫描定义是否有误。这里有一个很多人容易踩的坑网表中可能含有多个层次模块顶层有些端口没有连接。如果不先检查设计内部层次结构有没有unconnected port后边在drc阶段出现与hierarchy相关的violation时你会分不清楚是端口没接还是DRC规则本身的触发条件不正确。3. Tessent Scan Chain插入核心实操从Compile到Insertion的三段式如果说数据准备决定了你能不能跑下去那么scan insertion这节就决定了你ATPG阶段是爽一把就死还是如丝般顺滑。Scan chain插入在Tessent里不是一条命令就完成的它分成编译、规则检查、插入、验证几个阶段。3.1 第一步Specify Design和Specify Scan Chains在Tessent Shell里你需要明确告诉工具你要插几条扫描链、每条链上要串多少位寄存器、扫描端口怎么分配。这些信息通过add_scan_chains类命令来声明或者通过读取一个SCAN_DEFINITION文件SPF格式来导入。举个例子如果我有128个扫描触发器计划插4条链每条链32位那么端口设计可以是add_scan_chains -name chain0 -scan_in scan_in[0] -scan_out scan_out[0] -shared add_scan_chains -name chain1 -scan_in scan_in[1] -scan_out scan_out[1] -shared add_scan_chains -name chain2 -scan_in scan_in[2] -scan_out scan_out[2] -shared add_scan_chains -name chain3 -scan_in scan_in[3] -scan_out scan_out[3] -shared这里有个衡量指标叫Scan Chain Balance也就是每条链的长度是否均匀。链长严重失衡会直接导致ATPG向量数上升测试时间变长。比如4条链长度分别是40、30、30、28那么shift 40拍之后所有的数据才完全load进去短链实际是在空转效率损失是很直观的。所以Tessent在做scan chain balancing时做了不少优化。建议在综合阶段就让逻辑综合工具按balance目标来优化而不是插入阶段再去处理。实际操作中还涉及-view existing_dft和-view spec两个不同视图的理解。existing_dft是告诉Tessent设计里已经存在哪些DFT结构比如原来就扫描端口或者原先已有部分链spec则是声明你要新加入的DFT结构。这两类指令如果搞混会导致工具以为某条链已经存在而实际网表里根本找不到对应的连接后边的DRC会把这条链对应的很多规则直接报出来。3.2 核心命令insert_dft到底做了什么insert_dft这条命令概括了Tessent扫描链插入的所有内部逻辑。它做三件事对声明为Spec的扫描链进行综合连接、把普通触发器替换为带扫描功能的触发器、插入测试控制逻辑比如scan_enable的产生逻辑、时钟控制逻辑。展开说替换触发器时工具会做一次映射把RTL网表中的dff映射成库里的dff_s扫描D触发器。新加的扫描触发器比原触发器面积大所以综合阶段必须保留足够多的可替换单元。这里有个常见的经验在逻辑综合时工具通常默认选择普通时序单元如果你在综合时没有允许工具把非扫描触发器替换为扫描触发器配置compile_ultra -retime这类的优化选项对DFT的影响要特别小心那在Tessent插入时会报出找不到合适的扫描替换单元的问题或者是扫描替换后出现了额外的一级组合逻辑导致移位路径出现setup违规。插入过程还有一个容易踩坑的点时钟门控。如果设计里有大量clock gating cellICG在scan shift模式下这些ICG必须保持常开否则时钟打不进去触发器根本没法移位。Tessent处理ICG的常见做法是在scan enable有效时强制打开ICG。这个逻辑如果你在RTL里没有预留测试模式控制信号工具就会自动生成这样的控制逻辑插到网表里。高级用户会在RTL阶段就定义好scan_enable和scan_mode信号的传播路径避免插入阶段的控制逻辑过于复杂。但至少你要能看懂insert_dft之后网表多出来的那部分logIC知道它是干什么的。3.3 插入后的三条验证通路插完扫描链不是直接进ATPG就完了。很多芯片项目在这个阶段会做三件验证工作第一connection check。确保每条链从scan_in到scan_out路径上的触发器和逻辑都正确连接没有断链。Tessent Shell里的report_scan_chains命令会输出每条链的完整连接信息你可以在输出日志里检查链上寄存器的顺序是否和预期一致。第二等价性检查。插入扫描链之后的网表功能逻辑相比原始网表并没有改变只是触发器被替换为带扫描功能的版本。LEC形式化验证工具在这个阶段的比对范围为功能逻辑scan相关信号需要声明为常量。我记得第一次独立跑这个环节时就因为把scan_enable设为0还是1搞反了结果LEC报了上千个failing points但我去检查网表时却发现没有实际功能差异。其实这个设定是有讲究的LEC时需要把scan_enable设为0因为功能模式下扫描路径不应生效。第三在Tessent内部跑一次compliance DRC。这个DRC检查和ATPG之前的完整DRC不是同一个层次这是扫描链基本结构是否合理的一次预检比如shif t路径是否存在环路、是否有锁存器搭在扫描路径上挡住时钟等。具体DRC规则我在第五节单独细说这里先记住scan insertion完成之后至少要跑到这些基础规则全绿再去启动ATPG。4. ATPG向量生成把Scan Chain真正用起来Scan Chain插好了接下来就是ATPGAutomatic Test Pattern Generation自动测试向量生成的环节。ATPG是DFT流程里最能体现投入产出的一步——前面折腾半天就是为了这一步能生成一批高质量的测试向量给ATE机器用它们来区分好芯片和坏芯片。4.1 在动手前先理解Tessent ATPG的故事线Tessent ATPG的主干逻辑是从设计网表里识别出故障列表Fault List最常见的是Stuck-At故障固定故障也可以包含Transition Delay Fault迁移延迟故障对每个目标故障用自动生成的测试向量去定位它——通过scan chain把逻辑状态灌入电路跑一个或两个捕获时钟再把结果通过scan chain移出对比移出的响应和仿真预期值检测差异就是故障被检测到了最终统计故障覆盖率Fault Coverage和非检测故障的情况。整个流程是一条流水线中间某一个环节出错都会直接反映在覆盖率上。我遇到过ATPG跑出100%故障覆盖率但实际到ATE上就是fail的情况后来排查下来发现是因为Pattern在芯片上跑的时候时钟沿和扫描使能的时序设置和ATPG仿真假设不一致导致测试向量在芯片上根本灌不到位。所以ATPG阶段最微妙的地方在于——仿真能过不意味着硅片能过ATPG基础规则必须能反映芯片的真实时序。4.2 用Tessent Set Up Scan Patterns的标准步骤在Tessent Shell中ATPG的入口是create_patterns或者更常用的add_atpg_patterns相关流程。一个干净有效的启动流程会包含下面这些步骤# 确保处于atpg context set_context atpg -doscan # 读入已插入扫描链的网表读入test model库 read_verilog ../output/riscv_core_scan.v read_cell_library ../lib/tsmc28hpc_tt_0p9v_25c.cbd # 指定设计属性和故障类型 set_current_design riscv_core set_fault_type stuck_at add_faults -all # 运行ATPG引擎生成向量 create_patterns -class scan -auto_compress这里我要专门说明一下为什么先set_context atpg。Tessent Shell的上下文有点像操作系统里的权限管理你在dft上下文里跑create_patterns会直接报错因为这条命令在dft上下文根本不存在。这就要求你把scan insertion和ATPG当成两个独立的阶段来管理中间通过网表和SPF文件来传递数据。故障覆盖率是一个无法回避的指标。如果一个设计有100万个故障点那么100%覆盖率意味着100万个故障点里所有的都被成功检测。但实际项目中很难达到100%因为存在一些undetectable的故障比如冗余逻辑引起的不可检测故障UD faults。如果覆盖率低于预期第一步不要急着改ATPG流程先看report_summaries里的故障分类——有多少是detected可检测、undetectable不可检测、potentially_detected潜在的等等。这些分类会引导你判断覆盖率瓶颈到底在哪。举个例子如果undetectable故障集中在某个模块很可能是这个模块存在大量时钟门控且扫描使能信号无法完全控制这时候与其硬在ATPG上想办法不如回到RTL阶段调整可测性结构。4.3 EDT压缩与Tessent Test Compression的选择如果芯片规模大、扫描链数量多直接跑Full Scan不加压缩测试时间和向量数据量会爆炸。这也是Tessent在业界能打的一个重要原因——EDT压缩技术。Tessent Test Compression的核心是在扫描链的输入输出端加入解压缩器和压缩器。输入方向少量外部数据通道EDT channel通过解压缩逻辑展开成很长的内部扫描链输出方向内部扫描链的响应通过压缩器压缩回少量输出通道。关键点是解压缩器和压缩器本身必须设计成对X值免疫否则ATPG仿真里有一点X态传到压缩器整个压缩结果都对不上了。我个人的建议是如果设计规模达到百万门级以上直接上EDT压缩如果设计很小比如几十万门Full Scan不压缩也完全可行。压缩不是免费的它引入了解压缩器和压缩器的面积开销还会增加一些测试模式下的时序约束。小芯片硬上压缩成本和收益不成正比。另外如果设计中存在大量黑盒比如memory hard macro黑盒输出会有X态这些X态进入压缩器会污染压缩结果所以用压缩之前必须仔细检查X源。4.4 仿真与验证Pattern的方式生成Pattern之后不能直接拿给ATE厂商。Tessent生成的pattern文件有多个格式最常用的是WGL格式和STIL格式。在给ATE之前通常会在仿真器里把pattern和网表一起跑一遍确保pattern的行为和预期一致。仿真这一步要留意的坑是时序模型。功能仿真用的是timescale 1ns/1ps这种单位时间精度但ATPG pattern的时序精度往往不是纳秒级别而是皮秒甚至更高精度。如果仿真精度和pattern数据的精度不匹配仿真结果会差之毫厘谬以千里。Tessent生成的pattern通常会有timescale 1ps/1ps描述你在README里要把这个信息明确传给后端的测试工程师。另一个坑是X态传播。Tessent仿真阶段如果发现pattern仿真结果和预期不符最常见的原因就是X态。X态可能来自未初始化的存储单元、黑盒输出、或者异步复位信号没有在测试模式下被正确钳制。每一个X态的源头都要追根溯源否则覆盖率统计就会失真。5. 常见DRC错误排错实录从报错现象到根因定位的完整链路DRCDesign Rule Check设计规则检查在DFT流程里指的是可测试性规则检查。Tessent里这个环节被称为Test DRC或Compliance DRC。很多刚接触Tessent的工程师在DRC阶段被一堆violation吓到但其实DRC错误有非常清晰的分类体系。掌握这种按类排查的思路比死记硬背错误代码要有效得多。5.1 DRC错误的本质工具在问你的设计能不能被测试先说一个总纲。Tessent的DRC规则本质上都是在追问同一个问题设计里的每一个时序单元是否能够被独立、确定地控制和观测如果能这条规则pass如果不能就报violation。控制指的是能否通过scan chain把触发器置成任意需要的状态观测指的是触发器的状态能否通过scan chain移出。一旦设计里出现组合逻辑环路、锁存器失控、异步信号反复翻转、时钟不可预测沿等问题测试就不再确定DRC自然就挂了。基于这个总纲见招拆招就比背规则库有效得多。下面我挑几个在多个项目里反复出现的典型DRC错误分别讲清它们的报错形态、根因和修复方法。有些是我自己踩过的有些是我帮同事debug时并肩解决的。5.2 S0/S1类violation时钟和复位控制性检查典型报错形态DRC报出类似Rule S0或Rule S1的violation日志上会跟一段说明大意是某个时钟信号或复位信号既不是常量又不能被scan enable信号控制。根因分析这条规则的本意是确保在shift模式下时钟可以由测试时钟严格控制不至于被功能逻辑里某个内部节点干扰。举个最常见的场景假设clk_g是功能逻辑经过与门产生的一个内部时钟。assign clk_g clk en;在功能模式这个电路没问题。但在测试模式如果你期望用clk_g作为扫描时钟就有一个致命问题clk和en都必须严格可控否则shift过程中时钟出现毛刺数据移位操作就不正确。Tessent会依据测试模式下的时钟约束来判断clk_g是否能被安全使用如果判断不能这就要打violation。修复思路一般在RTL阶段就为内部时钟插入测试时钟旁路test clock bypass确保测试模式下用干净的测试时钟不经过功能逻辑门控。如果你改不了RTL只能通过SDC里设置test clock来告诉工具只有哪个端口是测试时钟工具才能决定哪些内部时钟不必过分较真。5.3 锁存器相关的latches violation典型报错形态DRC报错Latch或S_Class规则指出某一个锁存器无法被直接控制或观测。根因分析Tessent对锁存器的策略是要么锁存器处于透明模式transparent要么锁存器的输出不影响扫描链的确定性。如果锁存器在测试模式下的行为是asynchronous的——时钟关掉后它还保持上一次的值——那么scan chain把数据load进去的时候锁存器可能出现hold问题即扫描链数据可能在锁存器不透明时更新导致数据丢失。修复思路大多数库都会提供带专门的扫描旁路功能的锁存器单元比如scan_latch把普通锁存器替换成这类单元让测试模式下锁存器变成一条直通路径。如果库里没有这种单元就需要在锁存器周围增加测试模式控制逻辑确保锁存器在scan模式常开。5.4 与时钟沿相关的setup/hold类violation典型报错形态DRC报出Clock类或Timing类的violation经常同时出现在shift沿与capture沿的检查报告里。根因分析Tessent在ATPG流程里做时序DRC其实是一个非常精细的过程。假设你设定shift在时钟上升沿capture在下降沿那么工具会检查两个方向上是否满足建立保持时间。由于设计的scan enable信号往往有很长的RC延迟在capture沿切换时scan enable可能还没完全稳定这会导致移位链路和捕获路径发生违规。修复思路这一类问题的修复往往不是改建网表而是调整测试时序test timing。你可以在Tessent Shell中用set_dft_timing或ATPG阶段的命令来指定时钟上升时间和下降时间、时钟沿设置等参数。另外如果scan enable信号从芯片管脚到各触发器延迟过大建议在插入环节让工具重新Register scan enable用set_dft_signal -view spec -port scan_enable -type ScanEnable -hookup_pin ...指令来重建和控制测试模式控制信号的扇出树。在所有时序类DRC violaton里scan enable的扇出过大会引发的问题绝对要排前三。记住关键是scan enable的时序要针对capture模式做balance而不是只在shift模式下考量。5.5 与X态和仿真相关的X source类violation典型报错形态DRC报告X-propagation或Unmodeled Cell类violationATPG阶段经常会看到Warning: X values may be captured in ...这样的描述。根因分析在ATPG仿真中如果某个单元输出X态并传播到捕获的触发器上那么这个触发器的最终状态就是不确定的pattern对比时无法判断芯片是好是坏。X态的来源很多未初始化的RAM/ROM黑盒输出、模拟宏单元的输出、电平转换器level shifter在电气特性上无法确定时的输出等。修复思路首先黑盒类X源对Tessent来说可以做black box extraction只要把黑盒输出作为dont care处理不给它们参与覆盖率统计就可以避免污染。但更根本的修复是让这些X源在测试模式下被钳制到确定值。比如在RAM周围加BIST模式钳制逻辑让RAM输出在非BIST测试时保持为一个稳定的已知值。另一种常见做法是在测试模式下把黑盒的output使能信号拉为无效态模拟宏模块输出隔离电阻隔离掉了。5.6 工具认知里很微妙的一类partial route conflicts在DFT流程的对应网络热搜词里有一批是后端布线DRC相关的内容比如[drc rtstat-6] partial route conflicts、vivado报错drc rtstat-2。严格来说这些不是Tessent的DFT DRC但在真实项目里Tessent ATPG跑完生成网表给后端做布局布线后端工具在route阶段经常冒出这一类和布线资源相关的DRC。我碰到过一次特别典型的情况ATPG生成的pattern里面有大量测试时钟频率很高比如200MHz后端布线时为了满足这些高耸的时序要求导致局部网线的布线密度超高出现了partial route conflict。当时我们查了好几天最后定位到根因是测试时钟树综合阶段没有给测试时钟专门设置更高的skew margin导致布线阶段信号完整性无法满足要求。这提示DFT工程师在交网表给后端之前把自己的测试约束写得尽量干净不要等后端报了一堆routing DRC再回来扯皮。5.7 特殊且容易被忽视spare cell/ECO cell带来的violation典型报错形态DRC报错指到某一个没有逻辑连接的实例上日志里说这个cell未连接到任何信号或存在连接错误。根因分析很多项目会在网表里故意保留一批spare cells备用单元和ECO cells以便后续流片前小改动使用。但这类cell如果输入端悬空或者输入被接到了常0常1电源上在测试模式下这些cell的输出可能出现X态。更讨厌的是如果spare cell的输出连着一条扫描链上的某段组合逻辑它们可能会影响扫描链的确定性。修复思路在Tessent读取网表时把spare cell设置成dont_use或者做exclude操作让它们不参与扫描链连接运算和DRC检查。如果这些cell的输入输出接到扫描链上了那你必须回头和后端工程师确认这些物理上的连接到底是什么目的。如果没有目的最好的方式是物理阶段把它们修剪掉而不是在DFT里硬撑着。5.8 排查DRC的通用方法分段排除法说了这么多具体错误最后再分享一个通用排查法我给它起名叫分段排除法。第一步缩小violation范围。Tessent会把DRC violaiton按规则类和设计层级报告出来。你不需要一次性解决所有violation先按规则类别筛选。比如你先看report_drc -violations -class Clock把所有clocking violation单独调出来。这样做的好处是同一类violation往往源于同一个根因一次修复能解决一批报错。第二步定位到具体例化路径。查看violation的具体位置它通常会写到某个module例化的完整层次路径比如chip_top/u_core/u_alu/u_adder/U3。用这个层次路径去网表里看到底是什么逻辑单元。第三步反向推导工具为何报错。打开这个cell周围100um范围内的逻辑画一下它的输入输出连接问自己这条路径在shift模式下能否被确定控制在capture模式下会不会产生X态如果不能再顺着信号扇出树往回找一定存在一个失控的输入源。第四步修复并回归。修复手段要优先采用结构修复如加旁路、替换单元、增加钳制逻辑而不是靠改约束文件绕过。约束文件写得太宽松DRC虽然放过了但ATE测试上可能啪啪打脸。我见过不止一个项目因为DRC violation靠改约束掩盖结果后边量产良率出了问题才回头来找。6. 覆盖率逼近与Pattern写出的最后一步把关DRC全绿之后还要处理覆盖率、压缩和pattern输出几个环节。这几个环节看似收尾但实际上也藏着不少经验。ATPG的故障覆盖率目标通常在95%以上很多设计要求在98%甚至更高。如果达不到先检查三个方向第一是否存在大量testability结构不足的逻辑。比如异步FIFO的控制逻辑、没有复位端且初始值不确定的寄存器组这些地方因为状态不可控会成为undetectable fault的重灾区。第二是否存在约束过紧导致ATPG引擎无法充分挖掘。在Tessent里set_atpg -auto_compress是可以自动压缩向量数量的但压缩过狠会牺牲覆盖率。有一个平衡点需要调如果你的覆盖率差一点点就能达标试着把压缩比调低放弃一部分向量压缩来换覆盖率。第三测试时钟是否覆盖了所有时钟域。多时钟域设计在ATPG阶段比较容易漏。比如有两个时钟域A和B它们之间的异步路径上存在同步器如果你的测试策略没有为B域生成独立的向量序列B域的某些故障就测不到。Tessent支持对多时钟域设计分别生成测试序列配置时要注意set_atpg -capture_clock off或者add_delay_fault这类命令对不同时钟域的区分。Pattern写出的最终形式也需要格外注意。我给出的建议是ATPG生成的vector文件wgl/stil/vcd不要直接扔给测试厂。理想的做法是在Tessent内部先做一次dofile run形式的仿真回归把pattern在RTL仿真器里过一遍确保X态行为和覆盖率统计没有偏差。跑完一遍之后再写STIL格式IEEE 1450给ATE厂商STIL格式在复杂时序和压缩配置的表达上比WGL更标准。写完pattern文件还没完。最后我对每个项目都会做一次golden media归档包括以下内容最终网表scan_insert后版本、最终SPF文件、pattern波形文件、覆盖率报告、DRC violation的waiver文件如果存在。这些文件要保证和后端签核的网表版本完全一致千万不能出现ATPG用的是V3版网表流片用的是V5版网表这种事。教训太深刻了——DFT工程师是签核链路上唯一同时接触功能网表、测试结构、测试向量和时序约束四份信息的人任何一份版本错位造成的损失都以百万计。从scan chain插入到ATPG向量生成再到把向量干净地交到测试工程师手里我对这整套流程最大的体会是DFT不是一个孤立的阶段它是一个将可测试性思维贯彻到从RTL到流片全链条的工程过程。提前在RTL阶段考虑测试模式控制信号、在综合阶段约束扫描单元替换、在DRC阶段死磕每一条violation的根因每一步的严谨都会在后面的覆盖率报告和ATE良率数据里得到回报。在工具日志和silicon数据之间找到那条可信的因果链这种成就感是DFT工作最让人上瘾的地方。