1. 为什么Sequential Pattern值得单独拎出来讲做数字IC测试的人迟早会撞上Sequential Pattern这堵墙。组合逻辑的ATPG跑得再顺一旦设计里塞进了大量跨时钟域路径、异步复位、内部状态机、存储器接口组合pattern的覆盖率就会卡在一个尴尬的数字上不去。这时候你打开Tessent的日志看到满屏的uncontrolledunobserved就知道该上Sequential Pattern了。Sequential Pattern的本质是让ATPG工具在时间维度上展开电路行为——它不再假设所有触发器可以被扫描链直接控制或观测而是通过多个时钟周期的激励序列把电路驱动到目标状态再传播故障效应到可观测点。这跟组合ATPG的思维模式完全不同组合ATPG是空间维度的求解Sequential ATPG是时空联合搜索。这篇文章面向的是已经跑过基础ATPG、正在被覆盖率瓶颈卡住的DFT工程师。我会把Tessent里Sequential Pattern从环境准备、约束编写、pattern生成到调试排查的完整链路拆开讲重点放在那些工具手册里不会写、但实际项目中一定会踩的坑。全文基于我在多个SoC项目中的实操经验涉及具体命令和参数的地方会给出可直接参考的写法。2. Sequential Pattern的核心机制与方案选型2.1 组合ATPG和Sequential ATPG的本质差异先把这个概念掰清楚不然后面很多现象你会觉得工具在乱来。组合ATPG的假设是每个触发器的输出可以被扫描链直接控制通过shift-in每个触发器的输入可以被扫描链直接观测通过shift-out。在这个假设下电路被压扁成一个纯组合网络ATPG只需要求解一个组合逻辑的布尔可满足性问题。速度快、pattern数量少、确定性强。Sequential ATPG打破了这个假设。它面对的场景包括触发器不在扫描链上比如某些IP内部的shadow register跨时钟域路径导致shift-in的值无法可靠传递异步接口如I2C、SPI的pad端需要外部激励序列存储器BIST接口需要特定的初始化序列模拟模块的数字控制接口需要多周期配置在这些场景下Tessent需要启动时序引擎在多个时钟周期内搜索激励序列。这个搜索空间是指数级增长的所以工具会采用启发式算法——这也是为什么Sequential Pattern的生成时间往往比组合pattern长一个数量级。2.2 Tessent中Sequential Pattern的两种生成模式Tessent提供两种主要的Sequential Pattern生成模式选错了模式后面全是白费功夫。第一种Full Sequential模式。工具完全依赖时序搜索来生成pattern不要求设计支持扫描。这种模式适用于完全没有扫描链的设计或者扫描链覆盖不到的角落。优点是通用性强缺点是pattern数量爆炸、生成时间长、覆盖率提升有限。第二种Scan-based Sequential模式。这是实际项目中最常用的。设计本身有扫描链但某些故障需要多个时钟周期的序列才能激活和传播。工具会先利用扫描链把电路驱动到某个状态然后通过几个功能时钟周期完成故障激活和效应传播最后再通过扫描链把结果shift出来。这种模式的关键在于load/unload用的是扫描时钟capture用的是功能时钟。选哪种模式取决于你的设计特征和覆盖率目标。我的经验是先跑Scan-based Sequential看覆盖率缺口在哪里如果缺口集中在完全不可扫描的区域再针对那部分逻辑单独跑Full Sequential。2.3 时钟域交叉Sequential Pattern最大的挑战来源多时钟域设计是Sequential Pattern生成困难的头号原因。假设你有clk_a和clk_b两个异步时钟域一条路径从clk_a域的触发器出发经过组合逻辑到达clk_b域的触发器。在功能模式下这条路径的时序由设计保证但在ATPG模式下工具需要同时控制两个时钟的相位关系才能可靠地激活和传播故障。Tessent处理跨时钟域路径的基本策略是在capture阶段按照一定的时钟序列依次pulse各个时钟给跨时钟域信号足够的传播时间。但这个足够是有限度的——如果路径上有异步FIFO、握手同步器工具很难在有限的周期内把数据从一端传到另一端。实际操作中我通常会在ATPG约束里明确告诉工具哪些时钟域之间的关系是异步的让工具采用保守策略。具体命令后面会讲。3. 环境准备与约束文件编写要点3.1 生成Sequential Pattern前的检查清单在敲下第一条命令之前先确认以下事项。这些检查看起来琐碎但跳过任何一项都可能导致后面几个小时的调试白费。网表版本确认确保你用的网表是最终tape-out版本或至少是接近最终的版本。Sequential Pattern对网表变化非常敏感一个触发器的增删可能导致大量pattern失效。扫描链完整性跑一遍scan chain integrity check确认所有扫描链的shift和capture都正常。扫描链有问题的话Sequential Pattern的结果不可信。时钟定义在Tessent的dofile中所有功能时钟必须正确定义包括时钟周期、占空比、相位关系。时钟定义错误是Sequential Pattern失败的最常见原因之一。复位序列确认设计的复位策略。同步复位还是异步复位复位需要几个周期复位释放后需要等待多久电路才能稳定这些信息必须体现在约束中。黑盒处理设计中的模拟模块、第三方IP如果作为黑盒处理需要确认黑盒的接口时序要求。Sequential Pattern生成时工具需要知道黑盒的输入需要保持多少个周期才能产生有效输出。3.2 Tessent Sequential ATPG的关键约束命令Tessent的约束体系比较庞大这里只挑Sequential Pattern相关的核心命令讲。时钟定义用add_clock命令。对于Sequential ATPG需要特别注意-period和-waveform参数add_clock clk_a -period 10 -waveform {0 5} add_clock clk_b -period 13 -waveform {0 6.5}周期和波形必须和SDC中的定义一致。如果SDC里clk_a和clk_b是异步的在ATPG约束里也要体现这种异步关系。时钟分组用add_clock_group命令。这个命令告诉工具哪些时钟是同步的、哪些是异步的add_clock_group -name sync_group -clocks {clk_a clk_b} -synchronous add_clock_group -name async_group -clocks {clk_a clk_c} -asynchronous同步时钟组内的时钟工具会尝试用固定的相位关系来生成pattern异步时钟组之间的路径工具会采用保守的时序假设。这个设置直接影响pattern的生成效率和覆盖率。时序例外用add_timing_exception命令。对于跨时钟域路径如果设计中有专门的同步器可以告诉工具这些路径不需要在ATPG中测试add_timing_exception -type false_path -from clk_a -to clk_b但要注意false path的设置有风险。如果设多了覆盖率会虚高设少了工具会浪费大量时间在不可能测试的路径上。我的建议是先不设false path跑一轮看结果再根据覆盖率报告决定哪些路径确实需要排除。Sequential depth设置用set_sequential_depth命令。这个参数控制工具在capture阶段最多展开多少个时钟周期set_sequential_depth 10默认值通常是8。设得太小复杂故障激活不了设得太大生成时间指数增长。我的经验值是对于大多数设计8-12之间比较合适。如果某个模块需要更深的序列可以针对该模块单独设置。3.3 约束文件编写中的常见陷阱约束文件写错是Sequential Pattern失败的头号原因。以下是我踩过的几个典型坑陷阱一时钟相位关系写反。比如clk_a和clk_b实际是clk_b滞后clk_a半个周期但约束里写成了超前。这会导致工具生成的pattern在仿真中行为异常。解决办法从SDC中直接导出时钟定义不要手写。陷阱二复位极性搞错。有些设计的复位是低有效有些是高有效还有些是混合的。约束里写错极性工具会在错误的时刻释放复位导致电路状态不确定。陷阱三忽略时钟门控。如果设计中有时钟门控单元ATPG约束里需要正确设置门控使能信号。否则工具可能在某些时钟周期里看不到时钟导致pattern无效。陷阱四黑盒时序约束缺失。对于模拟IP的数字接口如果没有给出正确的建立/保持时间约束工具生成的pattern在仿真中可能无法正确驱动黑盒。4. Sequential Pattern生成实操全流程4.1 从Dofile到Pattern完整命令序列下面是一个典型的Sequential Pattern生成流程。假设你已经有了一个可用的Tessent环境网表和库文件都已就绪。第一步读入设计。set_context patterns -scan read_verilog ./netlist/top.v read_cell_library ./lib/tech.lib set_current_design top第二步读入约束。read_sdc ./constraints/top.sdc read_atpg_constraints ./constraints/atpg_constraints.tcl第三步设置Sequential ATPG模式。set_atpg_mode -sequential set_sequential_depth 10 set_atpg_effort highset_atpg_effort有三个级别low、medium、high。Sequential Pattern建议直接用high因为low级别下工具会跳过很多难解的故障覆盖率会明显偏低。第四步运行DRC检查。run_drcDRC检查会报告设计中的规则违反比如时钟定义冲突、扫描链断裂、约束矛盾等。这一步绝对不能跳过。我见过太多人直接跑ATPG结果pattern生成失败回头查DRC发现有一堆问题。第五步生成Pattern。create_patterns -sequential -output ./patterns/sequential_patterns这个命令会启动Sequential ATPG引擎。生成时间取决于设计规模和复杂度小设计可能几分钟大SoC可能需要几个小时甚至过夜。第六步查看覆盖率报告。report_fault_coverage -summary report_fault_coverage -not_detected -limit 100第一份报告给你总体覆盖率第二份报告列出未检测的故障帮助你定位覆盖率缺口。4.2 关键参数的计算与选择依据Sequential Pattern生成中有几个参数直接影响结果这里展开讲一下选择逻辑。Sequential depth的计算。这个参数的理论上限是从任何可控点到任何可观测点之间的最长时序路径深度。实际设置时我通常用以下方法估算找到设计中最长的跨时钟域路径数一数从源触发器到目的触发器之间经过了多少个时钟周期。加上复位释放和初始化所需的周期数。再加上2-3个周期的余量。比如一个设计中最长的跨时钟域路径需要5个周期传播复位需要2个周期那么sequential depth至少设为7-8。Pattern count的控制。Sequential Pattern的数量通常远多于组合pattern。一个中等规模的SoC组合pattern可能几千条Sequential Pattern可能几万条。如果测试机台的pattern内存有限需要通过set_pattern_limit命令限制生成数量set_pattern_limit 50000但要注意限制pattern数量会直接降低覆盖率。我的做法是先生成全部pattern看总数和覆盖率再决定是否需要压缩。Compression的选择。Tessent支持on-chip compression和off-chip compression。Sequential Pattern对compression的兼容性不如组合pattern好因为compression逻辑本身可能引入额外的时序约束。如果设计中已经有compression架构建议先用set_compression off跑一轮确认Sequential Pattern本身没问题再开启compression。4.3 生成过程中的监控与日志分析Sequential Pattern生成过程中Tessent会输出大量日志。以下是我重点关注的信息Fault progress报告。工具会定期输出已检测故障数和剩余故障数。如果发现长时间没有进展说明工具卡在了某些难解故障上。这时候可以考虑调整sequential depth或增加时钟周期。Abort reason统计。工具放弃某个故障时会给出原因。常见原因包括Abort Reason含义应对策略uncontrolled无法将故障点驱动到目标值检查约束确认可控性unobserved无法将故障效应传播到观测点增加sequential depthclock_conflict时钟约束冲突检查时钟定义black_box黑盒阻塞了路径补充黑盒时序约束memory_block存储器阻塞了路径考虑memory bypass模式Memory usage监控。Sequential ATPG非常吃内存。一个百万门级的设计Sequential Pattern生成可能占用几十GB内存。如果机器内存不足工具会频繁swap速度急剧下降。建议在生成前确认可用内存至少是设计规模的100倍以门数为单位。5. 常见问题排查与调试技巧实录5.1 覆盖率上不去的五大原因及排查路径覆盖率卡住是Sequential Pattern最常见的痛点。以下是我总结的排查路径按优先级排列原因一约束不完整。这是最常见的。工具不知道某些信号的可控性就会放弃相关故障。排查方法用report_constraints -unconstrained命令列出所有未约束的信号逐一确认是否需要补充约束。原因二Sequential depth不足。如果abort reason中unobserved占比很高大概率是depth不够。排查方法逐步增加depth观察覆盖率变化。如果增加depth后覆盖率明显提升说明之前设小了。原因三时钟定义错误。时钟周期、相位、分组任何一项出错都会导致大量故障无法检测。排查方法用report_clocks命令检查时钟定义和SDC逐项对比。原因四黑盒阻塞。如果设计中黑盒较多且黑盒接口没有正确的时序约束工具无法穿透黑盒传播故障效应。排查方法用report_black_boxes列出所有黑盒确认每个黑盒的接口时序是否已约束。原因五设计本身的不可测逻辑。有些逻辑在功能模式下就不可测比如冗余逻辑、未使用的状态编码。这类故障无法通过ATPG覆盖需要在覆盖率报告中排除。排查方法用report_faults -not_detected -class untestable查看不可测故障列表。5.2 Pattern仿真失败的调试方法Pattern生成成功不等于仿真通过。Sequential Pattern在仿真中失败的情况很常见调试起来也比组合pattern麻烦。第一步确认失败pattern的编号。仿真日志中会给出失败的pattern编号。用report_patterns -pattern id命令查看该pattern的详细信息包括激励序列、期望响应、实际响应。第二步对比期望响应和实际响应。如果实际响应中有X态说明电路中有未初始化的状态。Sequential Pattern对初始状态非常敏感一个未初始化的触发器可能导致整条pattern链失效。第三步检查复位序列。很多Sequential Pattern仿真失败是因为复位没有正确执行。确认仿真中的复位时序和ATPG约束中的复位定义一致。第四步检查时钟序列。Sequential Pattern的时钟序列比组合pattern复杂得多。确认仿真中的时钟pulse顺序和ATPG生成的序列一致。特别注意有些pattern可能在capture阶段使用了多个时钟仿真环境需要支持这种多时钟序列。第五步检查时序。如果仿真中有时序检查timing check确认Sequential Pattern的时钟周期满足设计的时序要求。有些pattern在零延迟仿真中通过但在带时序的仿真中失败说明时序约束有问题。5.3 独家避坑经验那些手册不会告诉你的细节以下是我在实际项目中积累的经验每一条都对应着一次真实的调试经历。经验一先跑小规模测试。不要一上来就对全芯片跑Sequential Pattern。先用一个子模块跑通流程确认约束、时钟、复位都没问题再扩展到全芯片。这样可以把问题定位在可控范围内。经验二保存中间结果。Sequential Pattern生成可能耗时数小时如果中途失败重新来过代价很大。Tessent支持在生成过程中保存检查点set_checkpoint -interval 1000 -directory ./checkpoints这样即使生成中断也可以从最近的检查点恢复。经验三关注X态传播。Sequential Pattern中X态传播是覆盖率杀手。一个未初始化的触发器产生的X态可能污染大量故障的观测。在约束中明确设置所有触发器的初始状态可以显著减少X态问题。经验四分模块生成再合并。对于大型SoC全芯片Sequential Pattern生成可能不现实。我的做法是按时钟域或功能模块分别生成pattern再用Tessent的pattern合并功能整合。这样每个模块的生成时间可控调试也更容易。经验五定期清理临时文件。Sequential Pattern生成会产生大量临时文件占用磁盘空间。如果磁盘满了生成会失败。建议在生成前确认磁盘可用空间至少是设计规模的50倍。经验六仿真环境要匹配。Sequential Pattern的仿真环境比组合pattern复杂。确认仿真平台支持多时钟序列、支持X态检查、支持时序反标。如果仿真环境不匹配pattern仿真失败的原因可能不在pattern本身。5.4 常见问题速查表问题现象可能原因排查命令解决方向覆盖率低于预期约束不完整report_constraints -unconstrained补充缺失约束生成时间过长sequential depth过大report_sequential_depth降低depth或分模块大量uncontrolled时钟定义错误report_clocks修正时钟定义大量unobserveddepth不足或黑盒阻塞report_black_boxes增加depth或补充黑盒约束Pattern仿真失败复位/时钟序列不匹配report_patterns -pattern id对齐仿真和ATPG时序内存不足设计规模过大-分模块生成或增加内存X态污染触发器未初始化report_x_sources设置初始状态覆盖率虚高false path设多了report_timing_exceptions审查false path设置6. 从生成到签核Sequential Pattern的完整交付链路6.1 Pattern格式转换与测试机台适配Tessent生成的pattern通常是内部格式需要转换成测试机台支持的格式。常见的转换目标包括STIL、WGL、VCD等。转换命令write_patterns ./patterns/sequential.stil -format stil -replace转换过程中需要注意时序信息STIL格式需要包含完整的时序定义包括时钟周期、边沿位置、strobe点。如果时序信息缺失机台无法正确执行pattern。Pin mapping确认pattern中的信号名和测试机台的pin名对应。如果有差异需要在转换时做映射。Pattern顺序Sequential Pattern的执行顺序可能影响结果。有些pattern依赖前序pattern建立的电路状态转换时需要保持顺序。6.2 硅后调试中的Sequential Pattern问题Pattern在硅后测试中失败排查起来比仿真阶段更困难因为你无法直接观测内部信号。以下是我总结的硅后调试思路第一步区分是pattern问题还是芯片问题。用同一套pattern测试多颗芯片如果只有部分芯片失败可能是芯片制造问题如果所有芯片都在同一pattern失败可能是pattern本身有问题。第二步用组合pattern交叉验证。如果组合pattern全部通过只有Sequential Pattern失败说明问题出在时序相关的逻辑上。重点检查跨时钟域路径、异步接口、复位序列。第三步缩小失败范围。通过修改pattern的起始位置逐步缩小失败pattern的范围。比如如果pattern 1000-2000失败可以尝试从pattern 1500开始执行看是否仍然失败。第四步检查测试机台设置。测试机台的时钟频率、电压、时序设置可能与仿真环境不同。确认机台设置和pattern的时序要求匹配。6.3 覆盖率收敛的最后冲刺当覆盖率接近目标但还差几个百分点时以下策略可以帮助你完成最后冲刺策略一针对性生成。用add_faults -focused命令指定特定故障集合让工具集中精力生成能检测这些故障的pattern。策略二调整ATPG effort。从high提升到exhaustive如果工具支持让工具尝试更多搜索路径。策略三手动分析不可测故障。对于工具报告为untestable的故障逐一分析是否真的不可测。有些故障可能因为约束过严而被误判放宽约束后可能变得可测。策略四接受合理的覆盖率上限。不是所有设计都能达到100%覆盖率。如果经过多轮尝试覆盖率稳定在某个值且未检测故障都是已知的不可测逻辑可以接受这个结果。关键是未检测故障必须有合理的解释不能有不知道为什么没测到的故障。7. 一些个人体会Sequential Pattern这件事工具命令本身不难难的是对设计的理解。我见过太多工程师把ATPG当成黑盒——输入约束输出pattern覆盖率不够就调参数。但Sequential Pattern的调试本质上是对设计时序行为的理解。你得知道电路在功能模式下是怎么工作的才能写出正确的约束才能判断工具的行为是否合理。另外Sequential Pattern的生成时间通常很长调试周期也长。我的建议是在项目计划中给Sequential Pattern留出足够的时间余量。不要等到tape-out前两周才开始跑那时候发现问题可能已经来不及改了。最后分享一个实用技巧在生成Sequential Pattern之前先用小规模测试用例验证约束的正确性。具体做法是选一个简单的时序路径手动构造激励序列在仿真中验证电路行为然后对比ATPG生成的pattern是否产生相同的激励。这个验证过程可能花半天时间但可以避免后面几天的无效调试。