1. 为什么Sequential Pattern值得单独拎出来讲做数字芯片DFTDesign for Test的人对Tessent这套工具链应该都不陌生。大部分项目里大家最常打交道的其实是Full Scan的Stuck-at Pattern流程成熟、脚本稳定、跑出来覆盖率也好看。但真正让DFT工程师头疼的往往是Sequential Pattern——也就是带时序深度的那部分Pattern生成。我见过不少团队Full Scan覆盖率能轻松做到99%以上一到Sequential Pattern就卡在80%多上不去或者Pattern数量爆炸导致测试时间超标再或者仿真能过、上机台就fail。这些问题背后其实是对Sequential ATPG工作机制理解不够深导致的。这篇内容我打算把Tessent里Sequential Pattern从环境准备到Pattern生成、再到常见问题排查的完整链路讲清楚。适合已经做过基础ATPG、想深入理解Sequential Depth和时序Pattern生成机制的DFT工程师也适合正在被Sequential Coverage卡住、需要排查思路的同行参考。核心会围绕Sequential Depth的设置逻辑、ATPG引擎在时序电路里的决策过程、以及Memory BIST与Sequential Pattern的交互这几个关键点展开。先说一个反直觉的结论Sequential Pattern的覆盖率上不去大多数时候不是ATPG算法不行而是你的Sequential Depth设错了或者Scan Chain的架构本身就不适合做深时序ATPG。这个判断我在多个项目里反复验证过后面会详细展开。2. Sequential ATPG和Full Scan ATPG的本质差异2.1 组合逻辑ATPG的理想假设在时序电路里为什么失效Full Scan ATPG之所以简单高效是因为它做了一个非常强的假设所有触发器都可以被Scan Chain直接控制或观测。在这个假设下ATPG引擎只需要处理纯组合逻辑把每个触发器的输出当作可控的Primary Input把每个触发器的输入当作可观测的Primary Output。整个电路被拍平成一个巨大的组合网络ATPG算法通常是D算法或PODEM的变种在这个组合空间里搜索测试向量。但Sequential ATPG面对的场景完全不同。当电路中存在无法被Scan Chain直接访问的时序单元——比如内部时钟域交叉的寄存器、Memory周边的控制逻辑、或者被刻意排除在Scan Chain之外的Shadow Register——ATPG引擎就必须在时间维度上做搜索。它需要决定在第1个时钟周期给什么激励第2个周期给什么激励经过若干个周期后目标故障才能被激活并传播到可观测点。这个若干个周期就是Sequential Depth。它直接决定了ATPG引擎的搜索空间大小。Depth1意味着引擎只考虑单周期内的时序行为Depth5意味着它要在5个时间帧Time Frame里做联合搜索。搜索空间随Depth指数级增长这就是为什么Sequential ATPG的运行时间和内存消耗远高于Full Scan。2.2 Tessent中Sequential Pattern的三种典型来源在Tessent的实际流程里Sequential Pattern通常来自三个地方理解这个分类对后续排查问题很关键显式Sequential ATPG通过set_atpg_mode或类似命令显式开启时序ATPG模式工具会在指定的Sequential Depth内搜索测试序列。这类Pattern的生成最耗时但对非Scan时序逻辑的覆盖最有效。Scan Chain内部的时序行为即使你跑的是Full Scan模式Scan Chain本身的Shift过程也涉及时序。如果Scan Enable信号存在时序违例或者Clock Gating逻辑在Shift和Capture之间切换不干净工具会生成额外的Sequential Pattern来覆盖这些场景。Memory BIST周边的逻辑Memory BIST控制器通常包含大量非Scan的时序逻辑如BIST Sequencer、Comparator、Address Generator。这些逻辑的故障往往需要Sequential Pattern来覆盖而且和Memory BIST的测试模式强相关。注意很多项目里Sequential Coverage上不去其实是Memory BIST周边的逻辑没覆盖到而不是核心逻辑的问题。排查时先看覆盖率报告里未覆盖故障的分布区域能省很多时间。2.3 Sequential Depth对Pattern数量和质量的双重影响Sequential Depth的设置是一个典型的过犹不及问题。设得太小ATPG引擎找不到足够长的激励序列来激活深层故障覆盖率上不去设得太大搜索空间爆炸Pattern数量激增运行时间可能从几小时变成几天。我在一个通信芯片项目里做过实测同一个设计Sequential Depth从3增加到5覆盖率从87%提升到94%但Pattern数量从1.2万涨到4.7万ATPG运行时间从6小时变成31小时。Depth再增加到7覆盖率只提升了0.8%Pattern数量却翻了一倍多。这个拐点因设计而异但规律是普遍的——存在一个边际收益急剧下降的Depth阈值。找到这个阈值的方法后面会讲核心思路是先用较小的Depth跑一轮分析未覆盖故障的类型判断哪些是再给几个周期就能覆盖的哪些是结构上就不可测的。只对前者增加Depth后者应该通过DFT结构改进或Test Point插入来解决。3. Tessent Sequential Pattern生成的环境搭建与关键配置3.1 从Full Scan切换到Sequential ATPG的配置差异如果你已经有一套跑通的Full Scan ATPG脚本切换到Sequential模式并不是简单改一个开关。Tessent里最核心的差异在于set_atpg_mode和set_sequential_depth这两个命令的配合使用。一个典型的配置片段长这样# 设置ATPG模式为Sequential set_atpg_mode -sequential # 设置Sequential Depth set_sequential_depth 5 # 设置每个故障的搜索尝试次数上限 set_atpg_effort -high # 开启多帧搜索 set_time_frame_limit 5 # 指定需要做Sequential ATPG的模块 add_sequential_module /top/u_core/u_ctrl这里有几个容易踩的坑。第一set_sequential_depth和set_time_frame_limit的关系。前者是逻辑上的时序深度后者是工具实际展开的时间帧数上限。通常两者设成一样但如果设计里有异步逻辑或Latch工具可能需要展开更多帧来处理这时候set_time_frame_limit要适当放宽。第二add_sequential_module的粒度。如果你把整个设计都加进去工具会对所有逻辑做时序ATPG运行时间会非常夸张。正确的做法是先用覆盖率报告定位未覆盖故障集中的模块只对这些模块开启Sequential ATPG其余部分保持Full Scan模式。3.2 Scan Chain架构对Sequential ATPG的隐性约束Scan Chain的架构设计直接决定了Sequential ATPG能不能跑出好结果。我遇到过最典型的问题是Lockup Latch的插入位置不合理。Lockup Latch本来是为了解决Scan Chain里不同时钟域之间的Hold违例但如果插在了关键路径上ATPG引擎在做时序搜索时会被这些Latch的透明/非透明状态搞晕导致大量故障被标记为Uncontrolled或Unobserved。另一个常见问题是Scan Enable信号的时序。在Sequential ATPG模式下Scan Enable需要在Shift和Capture之间正确切换。如果Scan Enable本身是时序逻辑产生的ATPG引擎需要额外的时间帧来建立正确的Scan Enable状态这会消耗Sequential Depth预算。排查这类问题的方法在Tessent里用report_scan_chain检查Chain的完整性用report_sequential_dependencies查看工具识别出的时序依赖关系。如果发现某个模块的时序依赖深度远超预期大概率是Scan Chain架构有问题。3.3 Memory BIST与Sequential Pattern的协同配置Memory BIST和Sequential ATPG的交互是很多项目里被忽视的环节。Memory BIST控制器通常工作在功能时钟域而ATPG工作在测试时钟域。当ATPG引擎试图覆盖Memory BIST周边的逻辑时它需要模拟BIST控制器的时序行为——包括BIST Sequencer的状态跳转、Address Generator的计数逻辑、Comparator的使能信号等。在Tessent里这部分配置主要通过set_mbist_interface和add_mbist_sequential_logic来完成。关键参数是BIST的运行周期数这个值要和Memory BIST的实际测试算法如March C-匹配。如果设小了ATPG引擎模拟的BIST序列不完整覆盖不到深层故障设大了又会浪费Sequential Depth预算。提示建议先用Memory BIST自身的测试模式跑一遍确认BIST控制器的功能正确性再把它纳入Sequential ATPG的范围。否则ATPG引擎可能在模拟一个本身就有时序问题的BIST序列结果就是覆盖率上不去还找不到原因。4. Sequential Pattern生成过程中的核心机制拆解4.1 ATPG引擎在时间帧里的搜索策略理解Tessent的Sequential ATPG引擎怎么工作对排查问题至关重要。简单来说引擎会把时序电路展开成多个时间帧Time Frame每个时间帧内是组合逻辑帧与帧之间通过触发器的状态传递连接。然后引擎在这个展开后的网络上做搜索寻找能激活并传播目标故障的激励序列。搜索策略通常是反向时间帧搜索从故障点所在的时间帧开始反向推导需要什么激励条件然后逐帧向前传播这些条件直到找到一组可以在Primary Input或Scan Chain上直接施加的激励。这个过程和组合ATPG的D算法类似但多了时间维度的回溯。关键点在于引擎的搜索深度受Sequential Depth限制但实际需要的深度可能超过这个限制。当引擎发现需要更多时间帧才能满足条件时它会放弃这个故障标记为ATPG Untestable或Aborted。这就是为什么增加Sequential Depth能提升覆盖率——它给了引擎更多的搜索空间。但增加Depth不是万能的。如果故障本身在结构上就不可测比如需要无限长的序列才能激活再大的Depth也没用。区分这两种情况是排查的核心。4.2 时序约束文件SDC对Pattern生成的影响很多人不知道的是Tessent的Sequential ATPG会读取SDC文件里的时序约束并据此判断哪些时序路径是有效的。如果SDC里定义了False Path或多周期路径ATPG引擎会尊重这些约束不会在这些路径上生成Pattern。这带来一个隐患如果SDC里的约束过于严格或不准确ATPG引擎会认为某些故障不可测导致覆盖率虚低。我遇到过一个案例SDC里把一条跨时钟域路径设成了False Path但实际上这条路径在测试模式下是有效的结果ATPG引擎直接跳过了这条路径上的所有故障覆盖率少了3个百分点。排查方法用report_atpg_constraints查看工具实际使用的时序约束和SDC原始文件对比确认没有遗漏或误设。特别是在测试模式下很多功能模式下的False Path应该被移除或放宽。4.3 Pattern压缩与Sequential Pattern的兼容性问题Pattern压缩如Tessent的set_pattern_compression在Full Scan模式下效果很好能把Pattern数量压缩到原来的1/5甚至1/10。但在Sequential模式下压缩效果会大打折扣甚至可能引入问题。原因是Sequential Pattern的每个时间帧之间有严格的时序依赖关系压缩算法在合并Pattern时可能会破坏这些依赖。Tessent的处理方式是对Sequential Pattern采用更保守的压缩策略或者干脆不压缩。这导致Sequential Pattern的数量通常远大于Full Scan Pattern。如果你的项目对测试时间有严格要求需要在Pattern生成前就规划好哪些模块用Full Scan 压缩哪些模块用Sequential 不压缩。混合模式是常见的折中方案。5. 常见问题排查从覆盖率卡住到Pattern仿真失败5.1 覆盖率卡在某个百分比上不动的排查链路这是最常被问到的问题。我的排查链路通常是这样的第一步看未覆盖故障的类型分布。用report_faults -summary查看未覆盖故障的分类。如果大部分是Uncontrolled说明激励条件不满足如果是Unobserved说明传播路径不通如果是ATPG Untestable说明工具认为结构上不可测。第二步定位未覆盖故障的模块分布。用report_faults -by_module看哪些模块贡献了最多的未覆盖故障。通常集中在几个特定模块而不是均匀分布。第三步检查Sequential Depth是否足够。对未覆盖故障集中的模块临时增加Sequential Depth跑一轮看覆盖率是否提升。如果提升明显说明Depth不够如果没变化说明是结构问题。第四步检查时序约束和Scan Chain架构。用前面提到的方法检查SDC约束和Scan Chain完整性。第五步考虑Test Point插入。如果确认是结构不可测在关键节点插入Test Point如控制点或观测点是最直接的解决方案。这个链路我用了很多次基本能覆盖90%以上的覆盖率问题。5.2 Pattern仿真通过但上机台Fail的典型原因仿真通过、机台Fail是DFT工程师的噩梦。在Sequential Pattern场景下常见原因有这几个时序违例Sequential Pattern对时序更敏感仿真时用的时序模型可能过于理想。机台上的实际时序和仿真模型有偏差导致Capture阶段的数据出错。Scan Enable信号的时序竞争在Shift和Capture切换的瞬间如果Scan Enable信号存在竞争机台上可能采到错误的状态。Memory BIST的初始化状态如果Sequential Pattern依赖Memory BIST控制器的特定初始状态而机台上电后的实际状态和仿真初始状态不一致Pattern就会Fail。电源噪声Sequential Pattern通常Toggle率更高电源噪声更大可能导致时序违例。排查这类问题建议先用Shmoo Plot在机台上扫描电压和频率看Fail是否集中在特定条件。如果集中在低压或高频基本可以确认是时序问题。5.3 Sequential Depth设太大导致的内存溢出与超时处理Sequential Depth设太大最直接的后果就是ATPG运行时间爆炸和内存溢出。Tessent在搜索空间过大时会消耗大量内存来存储中间状态。处理策略分模块跑不要对整个设计一次性跑Sequential ATPG按模块分批跑每个模块用适合它的Depth。设置资源上限用set_atpg_limit设置每个故障的搜索时间上限和内存上限超过就放弃避免单个故障拖垮整个流程。增量式增加Depth从较小的Depth开始逐步增加每次增加后看覆盖率的边际收益收益低于阈值就停止。使用Abort Limit设置合理的Abort Limit让工具在搜索一定次数后放弃而不是无限搜索。注意Abort掉的故障不一定是不可测的只是工具在给定资源内没找到解。这些故障需要单独分析可能需要手动生成Pattern或调整约束。6. 实战经验几个让我少走弯路的操作习惯6.1 先跑小规模验证再全芯片铺开我现在的习惯是任何Sequential ATPG配置先在一个小模块上跑通确认Pattern生成、仿真、覆盖率报告都正常再推到全芯片。小模块上跑一轮可能只要十几分钟全芯片可能要几十小时。用小模块验证配置能避免大量无效等待。具体做法选一个包含典型时序逻辑的模块比如一个带Clock Gating的控制模块用目标配置跑一遍检查生成的Pattern数量、覆盖率、运行时间是否符合预期。如果小模块上就有问题全芯片上只会更严重。6.2 保留每一轮的覆盖率报告做对比Sequential ATPG的调试往往需要多轮迭代。每轮调整配置后保留覆盖率报告和上一轮对比。重点看新增覆盖了哪些故障、哪些故障从Uncovered变成了Covered、Pattern数量变化了多少。Tessent支持用report_faults -compare对比两轮的故障列表。这个功能在定位为什么这轮覆盖率提升了/下降了时非常有用。6.3 和前端设计工程师确认非Scan逻辑的意图很多Sequential Coverage问题最终要回到设计本身。比如某个寄存器被刻意排除在Scan Chain之外是因为它是Analog IP的配置寄存器还是因为设计疏忽某个Clock Gating逻辑在测试模式下应该常开还是受控这些问题ATPG工具回答不了需要和前端设计工程师确认。我的经验是在跑Sequential ATPG之前先拿到一份非Scan逻辑清单逐个确认其测试意图。这份清单能帮你快速判断哪些未覆盖故障是设计上可接受的哪些是需要修复的。6.4 Pattern生成后的仿真验证不能省有些团队为了赶进度Pattern生成后直接上机台跳过仿真验证。这在Full Scan模式下可能侥幸过关但在Sequential模式下风险极高。Sequential Pattern的时序依赖复杂仿真能提前发现大部分时序问题和初始化问题。仿真验证的重点用带时序的网表SDF反标跑一遍检查是否有Setup/Hold违例用不同的初始状态跑几遍检查Pattern是否依赖特定初始条件检查Scan Enable和Clock的时序关系是否符合预期。7. 关于Sequential Pattern后续优化的一些个人体会Sequential Pattern的优化没有一劳永逸的方案每个设计都有自己的特点。我个人的体会是把Sequential ATPG当成一个需要迭代调优的过程而不是一次性的任务。第一轮跑出基础覆盖率然后通过分析未覆盖故障、调整Depth和约束、必要时插入Test Point逐步逼近目标覆盖率。另外不要忽视Memory BIST和Sequential Pattern的交互。很多项目里Memory BIST周边的逻辑是Sequential Coverage的主要缺口。提前规划好BIST控制器的测试模式把它纳入ATPG范围能省很多后期调试时间。最后分享一个小技巧在Tessent里用set_pattern_debug开启调试模式工具会输出每个Pattern的生成过程和覆盖的故障列表。这个信息量很大但在排查特定故障为什么没被覆盖时非常有用。我通常只在定位到具体故障后才开启避免日志过大。