从某个项目的周一开始讲起吧。那一次ATE机台上刚跑完第一批pattern我盯着fail记录整整一片红色。问题不在ATPG覆盖率也不在scan chain而是我们跳过了Verify Test Pattern直接把工具生成的pattern丢去了机台。DFT工程师都懂pattern在Tessent工具内部生成、内部“确认”过覆盖率但这不代表它在真实门级仿真器里能原样跑通。X态传播、掩码位置、compare沿的对齐这些细节都可能让pattern在仿真阶段就崩掉更别说上ATE。所以我才在5.1 Tessent ATPG系列的第八章里专门把Verify Test Pattern拿出来讲透——这是Test Pattern Generation之后、ATE之前绝对不能省的关卡。1. 为什么Pattern生成了还要再Verify一遍上ATE前的最后一道安全网1.1 ATPG流程中Verify的位置从内部计算到真实仿真的跨越先回顾一下整个Tessent ATPG的正常路径。前面几章我们经历过setup、read_design、DRC、add_faults、run_atpg最后用run_dtp生成确定性的测试向量。很多工程师走到这里就觉得“完事了”接下来把pattern转成WGL或STIL格式丢给ATE就结束。但这里有一个非常关键的认知断层工具在run_dtp阶段计算出来的每个pattern背后都有一个“good machine”响应。这个响应是工具在理想化的逻辑模型下通过fault simulation推演出来的期望值。问题是这个理想模型和真实门级网表之间存在差异——最典型的就是X态。真实的门级仿真环境里没有初始化的触发器、memory单元的输出、未约束的模块端口都可能产生X而工具在生成pattern时是通过逻辑值0/1来运算的它也会做X处理但处理的结果需要拿到真正的仿真器里去验证一次。Verify Test Pattern这一环就是把Tessent内部生成的test pattern放到真实仿真器VCS、Questa、Xcelium这类里构建一个testbench逐条或并行地加载pattern跑完整个scan shift、capture、compare流程看实际电路响应和工具的期望值是否完全一致。不一致的地方就是必须在去ATE之前解决的问题。1.2 Pattern里不止有01序列时钟、掩码、非扫描单元状态很多人对pattern的理解是“一串scan in的01数据”这个理解太窄了。一个完整的pattern文件里起码包含这几层信息scan chain的load和unload序列也就是SI/SO的数据流capture时钟的发出位置和脉冲宽度shift时钟和capture时钟之间的切换时序非扫描单元比如异步复位、memory的test mode控制信号的初始化序列compare窗口也就是在哪个时间点采样scan out的值掩码信息哪些位被mask掉、不参与比较这里面最让verify阶段难受的是后三类。Capture时钟发出的时候组合逻辑传播出来的值是不是稳定取决于门级网表的仿真模型和单元延迟compare窗口如果落在时钟沿的边缘仿真器的精度稍微差一点采样到的值就会抖动异步复位信号在pattern最前面的初始化阶段如果没建立起来整个仿真环境就带着X跑后面全是白搭。工具在内部计算的时候它自己的delay model和真实门级模型不可能完全一致。工具认为稳定的时序窗口到了仿真器里因为有真实的单元延迟和传播路径可能出现毛刺或延迟最终导致比较点的实际值和期望值不一致。这些不一致如果在仿真阶段发现我们还能通过调整pattern生成约束来解决如果等到了ATE就只能烧钱烧时间在机台上慢慢调。1.3 跳过Verify直接上ATE的成本账我见过不止一个项目为了赶交付时间把verify这步给跳了理由很统一“反正工具已经算过覆盖率了pattern肯定是对的。”这个想法非常危险。ATE机台是按小时计费的一条pattern挂了不是重新跑一遍那么简单。你需要先做failure log分析判断是contact问题还是pattern问题如果是pattern问题可能要重新生成向量、重新仿真甚至可能牵扯到DFT约束的调整。一轮下来两到三周的额外周期是保守估计。而Verify Test Pattern这一步跑一次的时间是小时级的换来的是把风险全部挡在机台之外。这个账怎么算都是划算的特别是现在先进工艺节点的测试成本水涨船高一颗芯片在机台上的时间就是真金白银。2. Verify Test Pattern的命令语义serial和simultaneous到底差在哪2.1 两种仿真模式的本质区别Tessent的verify命令核心是verify test_patterns但真正影响效率和使用场景的是它下面的仿真模式选项。多数项目里主要接触的是serial和simultaneous两种。Serial模式顾名思议是逐条pattern单独仿真。每一条pattern都会构建独立的仿真条件DUT重新初始化、应用该pattern、比对结果、生成报告。这种模式跑起来慢是肯定的但好处是干净——某条pattern挂了报告里能直接对应到pattern编号不会跟其他pattern混在一起。它非常适合debug场景比如工程师需要定位某一条具体的failing pattern或者某条pattern的mismatch到底发生在哪个compare点。Simultaneous模式就不一样了。它把多条pattern打包到一个仿真session里通过某种“并行化”的方式在同一个testbench中连续应用多条pattern甚至利用仿真器的多线程/并行特性去加速。这个模式下仿真吞吐量比serial高一个量级以上适合做大数量的全量回归。代价是debug的时候没serial那么直观——多条pattern在同一个session里连续跑日志里pattern之间的边界需要额外去区分。下面这个表是我项目里常用的模式选择逻辑维度Serial模式Simultaneous模式仿真速度慢逐条独立仿真快批量并行处理内存占用每条单独峰值较低多条并发峰值较高Debug友好性高pattern边界清晰中需要额外定位pattern边界典型场景新增pattern验证、debug全量回归、版本更新后快速验证资源需求单机即可需要多核或多机并行环境2.2 仿真器接口与版本匹配Verify Test Pattern本身不是一个仿真器它是Tessent和外部仿真器之间的桥。Tessent会根据你选择的仿真器类型生成对应的仿真脚本、testbench和pattern格式然后调起仿真器去跑。所以你的环境里必须装好了对应仿真器并且Tessent能找到它。这里有一个非常容易被忽视的点仿真器版本和Tessent版本的兼容性。Tessent的verify模块在调起VCS或Questa时生成的是特定版本语法风格的testbench。如果仿真器版本太旧可能不支持某些结构如果太新一些老语法可能被废弃导致编译报错。我建议在使用之前去确认一下Tessent版本对应的release note里列出的支持矩阵把仿真器版本稳定在一个已验证过的组合上。这种问题一旦遇到报错信息往往很诡异排查起来会绕很久。2.3 关键选项的含义不只是一个开关那么简单verify test_patterns命令下的选项很多都不是可有可无的。举个我常用的例子verify test_patterns -tool vcs -serial -pattern_summary -output_file verify.log这里的-pattern_summary会在验证完成后输出一个概要统计包括验证的pattern总数、通过数、失败数、覆盖率对比等。它们是快速判断一次验证是否干净的入口。另一个常见选项是控制仿真精度的这直接关系到X态和时序毛刺的判断。不同的仿真器对时间精度的处理方式不同Tessent默认会按照工具内部设定的精度生成testbench但某些极端情况下需要你手动指定更细的精度档。别看这个选项不起眼在遇到“compare窗口边缘采样不确定”这类问题时调整它有时候比改pattern快得多。还有一个值得了解的选项是与waveform dump相关的。打开waveform dump后verify过程中会生成FSDB或VPD波形。这玩意儿debug的时候是神器但不开的话你只能靠日志里的mismatch信息去反推问题效率会差很多。我个人的习惯是第一次跑通某条pattern或某个模块时必开waveform全量回归的时候关掉。3. 一份可以直接抄的Verify Dofile从读设计到出Waveform的完整配置3.1 环境准备与库文件加载先放一份我在实际项目中用到的简化版dofile读者可以根据自己的流片工艺和设计结构调整。它覆盖了从读入库文件、读网表到生成pattern、执行verify的完整闭环。# verify_run.dofile set DESIGN_NAME top_chip set NETLIST_FILE ../netlist/${DESIGN_NAME}_scan.v set CELL_LIB ../lib/tsmc55_lvtt.lib set SDF_FILE ../sdf/${DESIGN_NAME}_scan.sdf.gz set PATTERN_FILE ./patterns/${DESIGN_NAME}.tstl2 set WAVE_FILE ./waves/${DESIGN_NAME}.fsdb # 1. 环境初始化 setup -product tessent_atpg # 2. 读入库模型 read_cell_library -lib $CELL_LIB # 3. 读入门级网表 read_design -verilog $NETLIST_FILE -root $DESIGN_NAME # 4. 定义时钟和DFT信号 add_clocks -clock CLK -period 10.0 -waveform {0 5} add_dft_signals -scan_enable SE -scan_reset SR # 5. DRC检查 run_drc # 6. 故障与ATPG add_faults -all run_atpg -auto_compression -effort high # 7. 生成确定性的测试pattern run_dtp # 8. 输出pattern文件 create_test_patterns -format tstl2 -output_pattern_file $PATTERN_FILE # 9. 串行验证并输出波形 verify test_patterns \ -tool vcs \ -serial \ -pattern_summary \ -waveform_file $WAVE_FILE \ -output_file ./logs/verify_serial.log这个dofile的每一步都不复杂但有几个细节需要特别注意3.2 时钟定义与SDF反标verify前先想清楚要不要add_clocks里的时钟参数一定要和实际测试模式下的时钟保持一致的频率和占空比。很多工程师在ATPG阶段用的是快时钟到了verify阶段如果不显式修改Tessent会沿用之前的定义。这本身没错但你要确认一点verify阶段要不要反标SDF。这是我在多个项目中观察到的分歧点。有一部分工程师喜欢在verify时把SDF反标打开理由是“这样仿真更真实”。但我的建议是常规的ATPG pattern verify阶段不要反标SDF用unit delay或者零延迟跑就够了。原因是ATPG pattern本身就是按照慢时钟全周期来设计的它验证的是“逻辑功能是否匹配”不是“STA时序是否满足”。时序分析应该交给专门的signoff工具而不是在pattern verify里混在一起。一旦反标SDF单元延迟加上时钟树延迟很容易在capture沿附近产生各种亚稳态和毛刺最后报出来的mismatch不是逻辑问题而是时序伪报会严重干扰判断。3.3 Serial模式做Debug波形文件是定位的第一抓手如果你跑的是serial模式那强烈建议在第一次验证时就把-waveform_file选项打开并保持-pattern_summary。前面那份dofile里我已经把waveform dump打开了。跑完之后从仿真器里导出的FSDB可以直接拉进Verdi之类波形工具里。一旦后续日志里出现某条pattern失败你不需要重新跑一遍仿真直接拿这次dump的波形定位到对应时间点去观察SI/SO信号的翻转情况和pattern文件里期望的load/unload序列做对比很快就能看出是X态问题、时序问题还是掩码问题。3.4 Simultaneous模式做全量回归注意资源规划Serial模式跑通了基本功能之后正式大批量回归时我会切到simultaneous模式。命令上的差别很简单就是把-serial换成-simultaneous去掉waveform输出把-output_file对应改个文件名。verify test_patterns \ -tool vcs \ -simultaneous \ -pattern_summary \ -output_file ./logs/verify_simul.log但simultaneous模式有一个隐藏的成本资源占用。它会尝试并行起多个仿真任务如果你所在的集群节点数有限或者license数量有限反而可能跑得比serial还慢。我建议先做一个小规模的并行度测试确认当前环境能承受多少个并发任务再确定全量回归时的资源分配。Tessent本身也会做任务调度但底层还是要看你机器的真实负载。4. 结果怎么看日志、报告和Waveform里隐藏的信号4.1 Verify日志里必须盯住的几个统计值跑完verify不是看一眼“passed”就完事的日志里的信息密度很高但很多人不知道往哪儿盯。我一般会按从宏观到微观的顺序依次看四类信息pattern总数和验证通过数是否一致。如果存在任何failing pattern先记下编号。coverage对比。Verify结束时Tessent会重新统计一次fault coverage这个数字应该和run_atpg阶段报出的coverage基本一致。如果发现coverage明显下降说明有一部分fault在真实仿真环境下没有被观察到这是mask或X态处理引入的问题不能无视。DRC warning里有没有涉及到specific pattern的条目。有些DRC warning在pattern生成时被忽略但在verify阶段会暴露出来。关键message里有没有出现“X”相关的警告。这个往往是mismatch的前兆如果X传播到你关注的观察点这条pattern的覆盖率统计就会被污染。4.2 Pattern Summary表怎么读开启了-pattern_summary之后验证结束后会额外生成一个summary报告通常是一个表格列出每条pattern的编号、覆盖的fault数、pattern类型比如是基本scan测试、还是capture补偿测试、以及对应的仿真结果。表格里的信息可以快速筛出哪些pattern是“低质量”的——比如覆盖fault很少、但仿真时间很长的pattern这类pattern优先考虑在后续优化中去掉。还有一类pattern需要特别留意就是那些结果列里标记了“X”的。它们不是传统意义上的fail但可能稀释整个coverage的准确性需要结合波形去判断是否要保留。4.3 用Waveform定位Mismatch的具体操作定位mismatch时只看日志往往不够直观我的套路是这样的先用日志里给出的pattern编号和simulation time在波形里定位到对应位置然后把Tessent pattern文件里该条pattern的期望scan_out序列打开在波形里找到对应scan_out引脚的实际翻转序列逐位对比。如果发现某一位对不上继续往前追该bit对应哪条scan chain、又是scan chain上哪个触发器、这个触发器在capture cycle前接收到了什么样的数据。这一步通常能快速判断是capture沿打进去的值本身就不对还是shifting过程中被X态污染了。按照这种排查链路大部分mismatch都能在一个小时内定位到根因完全不需要“盲修”。5. 我踩过的Verify坑三类典型失败与完整排查链路5.1 X态传播导致的Mismatch根因定位全过程有一类mismatch我遇到得最多就是X态传播。表现为verify日志里哗哗地报几百条pattern全部fail而且fail的位非常集中总是落在某几个模块对应的scan chain上。拿到这类问题我不会先去看pattern而是先去看X态是从哪里来的。做法是把waveform打开在第一条failing pattern的compare时间点附近查那几个观察bit的来源寄存器。通常追两步就能看到某个寄存器的D端是一个memory的输出而memory在这个测试模式下没有被初始化输出是X。X顺着组合逻辑一路传到了scan chain的输入端又在capture沿被采样进触发器最终在compare点被报出来。这类问题的根因往往在DFT约束层面要么是该memory的test mode信号没有在pattern初始化阶段被正确拉起要么是ATPG阶段没有把该memory的cell库模型配好。解决方式也分两种一是调整初始化序列让memory在pattern开始时进入一个已知状态二是在保证覆盖率损失可接受的前提下通过工具设置把相关路径mask掉。但不管选哪种我都不建议直接用外部脚本去改pattern文件里加掩码那是治标不治本。5.2 SDF反标引发的时序伪报另一个容易踩的坑是SDF反标。有一段时间我们的项目为了“仿真更接近真实”在verify时统一加了SDF。结果同一套pattern之前零延迟仿真全过一加SDF就fail掉一大片。排查过程中我首先确认了一个现象fail的pattern在时间上不是随机分布的而是集中在capture沿附近的compare点。打开波形后观察那几个出问题的scan_out bit会发现它们并不是逻辑错误而是在compare时刻附近有一个明显的跳变翻转。也就是说信号在一点点延迟之后才稳定下来刚好错过了compare窗口。这个现象说明逻辑功能没有问题是时序窗口冲突。ATPG pattern本身就是基于慢时钟周期设计的逻辑在下一个沿之前早就稳定了但反标SDF后clock skew、cell delay组合起来把正常窗口压缩了甚至出现了竞争现象。对于ATPG pattern的verify来说这属于伪报。我们最终的处理方式就是回到不反标SDF、使用unit delay做逻辑验证。真正的时序signoff交给PT这类工具去保证。5.3 掩码缺失与Golden Value失配还有一类问题比较隐蔽是掩码相关的。一次验证新版本的pattern时发现某一条pattern在几次重复仿真中结果不稳定——偶尔pass偶尔fail。这种“间歇性”问题是最折磨人的。后来我仔细对比了Tessent生成的pattern文件和testbench中的compare逻辑发现问题出在compare窗口设置上该pattern的compare点刚好落在某个时钟沿附近仿真器受限于时间精度对沿上信号的采样值有微小的不确定性导致golden value和实际峰值判断偶发不一致。遇到这种问题首先要调整compare窗口的生成方式确保compare点避开时钟沿。如果工具不允许直接调整可以尝试修改该pattern的生成约束把capture沿和compare沿错开足够的裕量。另外一个思路是在不影响覆盖率的位上加掩码但必须是工具层面生成的掩码不是人为手工改文件否则后续维护成本会很高。这几种坑基本就是我在多个项目里踩过的绝大部分verify问题。看起来五花八门本质上都是同一个问题工具内部模型、pattern文件、真实门级仿真环境这三者之间存在细小的语义差异而verify的价值就是把它们暴露出来。每次搞定一个case我对“为什么Tessent要专门留一个verify环节”的理解就更深一层。最后分享一个我的个人经验吧。现在我每次做完ATPG pattern无论交付工期多紧都坚持把Verify Test Pattern作为一个强制步骤写进checklist里并且默认用simultaneous模式跑全量用serial模式只针对增量pattern做验证。这样既不耽误效率又能保证每一条上机台的pattern都是在真实仿真环境里验证过的。芯片测试这行前期多花一个小时做仿真后期就能省下机台上的一整天这笔账我算得滚瓜烂熟。