1. 为什么MBIST Pattern Spec值得单独拿出来讲做DFT这行的朋友大概率都有过这样的经历芯片流片回来ATE上跑MBIST测试结果fail了一大片debug半天发现不是设计问题也不是memory本身的问题而是pattern spec里某个参数配错了。这种事说出来丢人但确实常见。Tessent MBISTMemory Built-In Self-Test的Pattern Spec说白了就是一份告诉工具怎么生成测试向量的配置文件。它决定了March算法的选择、数据背景的排布、地址译码的方式、诊断模式的开关等等。你可以把它理解成做菜时的菜谱——食材memory model是设计团队给的厨具Tessent工具链是EDA厂商提供的但菜谱得你自己写。菜谱写得好测试覆盖率高、pattern数量少、测试时间短菜谱写得烂要么覆盖率不够漏掉故障要么pattern膨胀导致测试成本飙升。这篇文章面向的是已经接触过Tessent基本流程、但对Pattern Spec的配置细节还不够有把握的DFT工程师。我会从整体设计思路讲到具体参数配置再到实际生成过程中踩过的坑尽量把每个为什么这么配讲清楚。不管你是刚接手MBIST项目的新人还是想系统梳理一遍流程的老手应该都能从中找到有用的东西。2. Pattern Spec的整体设计与思路拆解2.1 Pattern Spec在MBIST流程中的位置先理清楚整个MBIST插入和验证的流程。通常一个完整的Tessent MBIST流程包含这几个阶段memory识别与BIST插入、Pattern Spec配置、pattern生成与仿真验证、ATPG pattern导出。Pattern Spec处在第二个环节上承BIST电路的插入结果下接pattern的生成和验证。很多人容易忽略的一点是Pattern Spec不是孤立存在的。它和memory model、BIST controller的配置、以及后续的pattern格式都有强耦合关系。比如你在spec里选了某个March算法但BIST controller的地址位宽配置不支持对应的地址遍历方式那生成阶段就会报错。所以写spec之前一定要先把memory列表和BIST配置过一遍。2.2 核心设计考量覆盖率、pattern数量与测试时间的三角平衡写Pattern Spec本质上是在做一场三角博弈故障覆盖率要尽可能高pattern数量要尽可能少测试时间要尽可能短。这三者互相制约你不可能同时把三个都拉到最优。举个实际的例子。March C-算法覆盖了SAFStuck-At Fault、TFTransition Fault、SoCStuck-open Fault等多种故障模型但它的操作序列比较长每个memory cell需要经过多次读写。如果你换成March SR算法pattern数量会少一些但对某些耦合故障的覆盖就不如March C-。所以选哪个算法取决于你的memory类型、工艺节点、以及产品对DPPM的要求。我的经验是对于先进工艺节点比如FinFET以下的SRAM优先选March C-或者March SS因为耦合故障和动态故障的概率更高对于成熟工艺的小容量memoryMarch SR或者MATS就够用了没必要为了那一点点覆盖率提升把pattern数量翻倍。2.3 配置文件的组织架构Tessent的Pattern Spec通常以.spec或者嵌入在.dofile中的形式存在。一个典型的spec包含以下几个区块Memory Instance声明指定哪些memory需要生成pattern以及它们的类型SRAM、DRAM、ROM等算法选择区为每类memory指定March算法数据背景配置定义测试用的数据pattern如00、FF、55、AA、walking 1/0等地址遍历方式选择升序、降序、或者自定义顺序诊断与调试选项是否开启diagnostic mode、是否生成failure log等输出格式控制pattern的格式如STIL、WGL、VEC等每个区块之间有关联关系。比如你选了某个算法它可能隐含了特定的数据背景要求你开了诊断模式pattern数量可能会翻倍。这些关联关系在后面的实操部分会详细展开。3. 核心参数配置与实操要点3.1 Memory Instance的声明与分组策略在spec里声明memory instance看起来简单但分组策略直接影响后续的pattern生成效率。Tessent允许你把多个memory instance归到同一个group里共享同一套算法配置。这样做的好处是pattern可以并行生成减少总的pattern数量。但分组不是随便分的。我的原则是同类型、同容量、同端口数的memory才放在一组。如果你把一个大容量SRAM和一个小容量SRAM放在一起工具会按照最大的那个来生成地址遍历序列小memory那边就会产生大量无效的地址操作白白浪费测试时间。# 典型的memory分组声明 add_memory_instances -group sram_1024x32 \ -instances {u_sram_bank0/mem0 u_sram_bank0/mem1} \ -type sram \ -address_bits 10 \ -data_bits 32 add_memory_instances -group sram_256x16 \ -instances {u_sram_bank1/mem0} \ -type sram \ -address_bits 8 \ -data_bits 16上面这段配置里address_bits和data_bits必须和memory model里的定义一致否则生成阶段会报地址越界或者数据位宽不匹配的错误。我见过有人直接从别的项目copy过来忘了改结果debug了一整天。注意memory instance的路径名必须和网表中的层次路径完全一致大小写敏感。建议直接从综合后的网表里copy不要手敲。3.2 March算法的选择逻辑与参数化配置March算法是MBIST pattern的核心。Tessent内置了多种标准算法也支持用户自定义。常见的几种算法名称故障覆盖相对pattern数量适用场景MATSSAF, TF低成熟工艺小容量memoryMarch C-SAF, TF, SoC, CFin中通用SRAMMarch SSSAF, TF, SoC, CFin, dynamic中高先进工艺SRAMMarch SRSAF, TF, SoC中低对测试时间敏感的场景CheckerboardSAF, 部分耦合低快速筛查选择算法时除了看故障覆盖还要看memory的物理结构。比如对于多端口memory需要考虑端口间的干扰故障这时候可能需要用March SS或者自定义算法来覆盖。在spec里配置算法的典型写法set_mbist_algorithm -group sram_1024x32 \ -algorithm march_c_minus \ -data_background {00 FF 55 AA} \ -address_order {up down}这里data_background指定了测试时使用的数据背景。00和FF覆盖了全0和全1的SAF55和AA覆盖了相邻位之间的耦合故障。address_order指定了地址遍历方向up和down各跑一遍可以覆盖地址译码器的故障。3.3 数据背景与地址遍历的联合优化数据背景和地址遍历不是独立的它们的组合方式会影响故障覆盖的完整性。举个简单的例子如果你只跑00和FF两个背景且地址只升序遍历那么某些需要地址降序才能触发的耦合故障就覆盖不到。我的建议是至少使用4个数据背景00、FF、55、AA地址遍历至少包含升序和降序。对于高可靠性要求的场景可以加入walking 1和walking 0背景但pattern数量会显著增加。# 高覆盖率配置示例 set_mbist_algorithm -group sram_1024x32 \ -algorithm march_ss \ -data_background {00 FF 55 AA walking_1 walking_0} \ -address_order {up down} \ -enable_diagnostic开了enable_diagnostic之后工具会为每个memory instance生成独立的诊断pattern方便定位具体是哪个cell出了问题。但代价是pattern数量可能增加30%到50%。所以量产测试时通常关掉诊断只有在debug阶段才打开。3.4 诊断模式的配置与输出控制诊断模式是MBIST debug的利器。当ATE上跑出fail时诊断pattern可以告诉你具体是哪个地址、哪个数据位出了问题。Tessent支持多种诊断级别Basic只报告fail的memory instanceDetailed报告fail的地址和数据位Full报告fail的地址、数据位以及故障类型配置诊断模式时需要注意诊断pattern的生成需要额外的仿真时间。如果你的memory数量很多full diagnostic可能会让仿真时间从几小时变成几天。所以建议在项目初期就用basic模式快速验证等到debug阶段再切换到detailed或full。# 诊断模式配置 set_diagnostic_mode -level detailed \ -output_format stil \ -failure_log mbist_fail.log实操心得诊断pattern的仿真一定要在gate-level下跑RTL级仿真可能会因为时序问题导致误判。我吃过这个亏RTL仿真全过gate-level跑出来一堆fail最后发现是memory的setup/hold时间不满足。4. 完整实操流程从配置到Pattern生成4.1 环境准备与工具版本确认在开始写spec之前先确认你的Tessent版本和license支持的功能。不同版本的Tessent在命令语法和参数支持上有差异。比如Tessent 2020.2之后的版本对March SS算法的参数化支持更灵活而老版本可能需要手动定义操作序列。# 确认Tessent版本 tessent -version # 确认license支持的feature tessent -licenses | grep -i mbist环境变量也要检查一遍。TESSENT_HOME、PATH、LD_LIBRARY_PATH这些必须指向正确的安装路径。我遇到过因为LD_LIBRARY_PATH指向了旧版本库导致工具崩溃的情况排查了半天才发现是环境变量的问题。4.2 编写Spec文件从模板到定制Tessent提供了一些spec模板可以从安装目录下的templates/文件夹里找到。但模板只是起点实际项目里几乎每个参数都需要根据memory的具体情况调整。我的习惯是先写一个最小可用的spec跑通基本流程然后再逐步添加算法、数据背景、诊断等配置。这样出问题时容易定位是哪个参数导致的。# 最小可用spec示例 # Step 1: 声明memory instance add_memory_instances -group sram_main \ -instances {u_soc/u_cpu/u_cache/mem0} \ -type sram \ -address_bits 12 \ -data_bits 64 # Step 2: 选择算法 set_mbist_algorithm -group sram_main \ -algorithm march_c_minus \ -data_background {00 FF 55 AA} \ -address_order {up down} # Step 3: 输出配置 set_pattern_output -format stil \ -output_file mbist_pattern.stil \ -include_diagnostic false4.3 运行Pattern生成并检查日志Spec写好后通过Tessent的generate_pattern命令触发生成。这个过程可能会跑几分钟到几小时不等取决于memory的数量和算法的复杂度。# 运行pattern生成 tessent -shell -dofile generate_mbist.do mbist_gen.log 21生成完成后重点检查日志里的几个关键信息Pattern数量是否在预期范围内覆盖率报告工具会给出故障覆盖率的估算Warning和Error有没有未连接的memory、地址越界、数据位宽不匹配等问题# 检查日志中的关键信息 grep -i error\|warning mbist_gen.log grep -i coverage mbist_gen.log grep -i pattern count mbist_gen.log4.4 Pattern仿真验证与调试生成的pattern需要在gate-level网表上跑仿真验证。这一步是必须的因为工具生成的pattern是理想情况下的实际电路中可能存在时序问题、memory model不匹配等情况。仿真时建议先用小批量pattern跑一遍确认基本功能正常再跑全量pattern。仿真脚本里要加入对memory输出数据的自动比对不要靠人工看波形。# 仿真验证示例使用VCS vcs -full64 -sverilog \ -f filelist.f \ defineMBIST_SIM \ -o simv_mbist ./simv_mbist patternmbist_pattern.stil verbose常见坑仿真时memory model的行为模型和实际芯片可能有差异。比如某些memory在读写切换时需要额外的wait cycle如果model里没建模这个行为仿真会过但芯片会fail。建议用memory厂商提供的仿真model不要用自己写的简化模型。5. 常见问题与排查技巧实录5.1 Pattern生成失败地址越界与位宽不匹配这是最常见的问题通常表现为工具报address out of range或者data width mismatch。根本原因一般是spec里的address_bits或data_bits和memory model不一致。排查方法很简单打开memory model文件找到parameter ADDR_WIDTH和parameter DATA_WIDTH和spec里的值逐一比对。注意有些memory的地址是字节地址有些是字地址换算关系要搞清楚。问题现象可能原因解决方法address out of rangeaddress_bits配置偏小检查memory model的ADDR_WIDTHdata width mismatchdata_bits配置错误确认memory的物理位宽instance not found层次路径错误从网表中copy路径algorithm not supported工具版本不支持升级Tessent或换算法5.2 覆盖率不达标算法与背景的调整策略如果生成后的覆盖率报告显示某些故障模型没覆盖到首先检查算法选择是否合适。比如你用的是MATS那它本来就不覆盖SoC故障换成March C-就好了。如果算法没问题但覆盖率还是不够可能是数据背景或地址遍历方式需要调整。试着增加数据背景比如加入walking 1或者把地址遍历改成双向。还有一种情况是memory的某些cell因为物理布局的原因标准March算法覆盖不到。这时候可能需要自定义算法在spec里手动定义操作序列。Tessent支持通过add_custom_algorithm命令来定义。5.3 仿真与ATE结果不一致时序与模型问题仿真过了但ATE上fail或者反过来这是最让人头疼的问题。常见原因有时序问题gate-level仿真时没有加载SDF文件导致时序检查不准确Memory model差异仿真用的model和实际芯片的行为不一致ATE时序配置ATE的clock频率、setup/hold时间和仿真不一致电源噪声仿真无法建模电源噪声导致的动态故障我的经验是仿真时一定要加载SDF并且用memory厂商提供的sign-off model。ATE上的时序配置要和仿真保持一致特别是clock的duty cycle和jitter。5.4 Pattern数量膨胀优化策略与取舍Pattern数量直接关系到测试成本。如果发现pattern数量远超预期可以从以下几个方面优化减少数据背景从6个减到4个pattern数量大概能减少20%到30%关闭诊断模式量产pattern不需要诊断关掉能省不少合并memory group同类型的memory合并生成减少重复的地址遍历选择更精简的算法在覆盖率满足要求的前提下选pattern数量少的算法但要注意优化不能牺牲覆盖率。我的做法是先跑一版全配置的pattern记录覆盖率和pattern数量然后逐步精简每次精简后重新检查覆盖率直到找到一个平衡点。6. 一些实操中的个人体会MBIST Pattern Spec这个东西看文档觉得简单真正上手才知道细节多如牛毛。我做了这么多年最大的体会是不要怕麻烦每个参数都要搞清楚为什么这么配。copy别人的spec看起来省事但出了问题你根本不知道从哪查起。另外spec的版本管理很重要。每次修改都要记录改了什么、为什么改、改完之后覆盖率和pattern数量有什么变化。我见过项目后期因为spec版本混乱导致pattern和设计不匹配的情况返工成本极高。还有一点多和memory设计团队沟通。他们最清楚memory的物理结构和潜在的故障模式这些信息对选择算法和配置数据背景非常有帮助。闭门造车写出来的spec覆盖率往往不尽如人意。最后分享一个小技巧在spec里加注释。Tessent支持在spec文件里用#加注释把每个参数的选择理由写清楚。过几个月再回来看你会感谢自己当初写了注释。