拓冰网站定制 
芯片做到可测试性设计DFT这一步前端的RTL写得再漂亮如果MBIST方案没搭好流片回来一大批嵌入式存储器没法测整块芯片就只能靠外部ATE硬怼时间、功耗、管脚全都不够用。MBISTMemory Built-In Self-Test内建自测试把测试激励、响应比较、故障判定全部搬到片上用一个专用BIST控制器去驱动存储器阵列从而在不依赖外部测试机资源的情况下完成嵌入式存储器的功能测试。Tessent就是做这件事用得最多、也最成熟的工具链无论是老牌大厂还是初创公司DFT工程师手上几乎都有一套Tessent流程。这篇内容不聊空中楼阁直接从完整流程讲起把从零开始插入MBIST逻辑、生成测试向量、做仿真验证到对接ATE的整个链路给你捋清楚。1. 内容整体设计与流程拆解1.1 为什么要做MBIST内部存储器到底有多难测先看一个现实问题一颗SoC芯片里嵌入式SRAM、寄存器堆Register File、缓存阵列加起来动辄几十上百个实例有些大存储器的位宽能到512bit甚至更高端口深度也可能超过4K。这些存储器分布在芯片各个角落和外部管脚之间没有昂贵的专用数据通路。如果靠外部ATE直接访问你需要把大量地址、数据、控制信号引到封装管脚上或者靠扫描链把存储器的输入输出端口串行搬移出来代价非常夸张。更麻烦的是存储器测试不是简单地读一遍、写一遍就算完。它要测固定故障SA0/SA1、转换故障Transition Fault、耦合故障Coupling Fault、地址译码故障Address Decoder Fault等这些故障模型要求执行特定的March序列。比如常用的March C-算法是一连串的写0、读0、写1、读1操作组合按特定地址方向反复走好几遍。如果靠外部的低速测试机一条条去搬数据一个大存储器的完整测试时间会拖垮整个产品线的产能。这时候MBIST的价值就出来了在芯片内部放一个BIST控制器由它按照预定算法生成读写序列直接把pattern打到存储器端口上再把读回来的数据和期望值做比较最后输出一个PASS/FAIL信号。测试激励不需要从外部灌进来测试响应也不需要搬出去ATE只需要通过JTAG/TAP接口触发一次BIST引擎然后收一个结果信号即可。打个比方这就像图书馆从挨个人工盘点每本书变成了在每个书架上装一个自助检查终端管理员只需要按一下“开始自检”按钮最后看一眼绿灯还是红灯。Tessent做MBIST的核心理念就是把“如何生成March序列”、“如何连接BIST逻辑”、“如何把多个存储器的控制器共享和调度起来”、“如何输出可诊断的pattern”这些事全部自动化。你作为DFT工程师主要的精力集中在配置哪些存储器需要测试、用哪种算法、控制器怎么共享、时钟复位怎么约束以及后续pattern怎么仿真验证。这套流程一旦走通后面加新存储器、换工艺节点、改时钟方案都是增量式操作不会推翻重来。1.2 Tessent在可测试性设计流程里的定位Tessent这个平台覆盖了整个DFT后端链条。早期的命名你可能听过MemoryBIST、ScanInsert、ATPG、Diagnosis现在统一归在Tessent旗下。拿我常用的组件来说Tessent ScanInsert负责扫描链的插入和压缩逻辑生成现在MBIST的插入也集成在这个环境里因为MBIST本质上是在门级网表上嵌入一段带扫描接口的逻辑。Tessent Shell底层核心环境很多脚本驱动的流程都从这里发起比如读库、读网表、elaborate、做BIST插入、写pattern。Tessent MemoryBIST专门负责存储器内建自测试逻辑生成包括controller、interface、wrapper、以及可选的repair逻辑。Tessent TestCompress做扫描压缩让更少的测试管脚覆盖更多内部扫描链。Tessent Diagnosis/Tessent YieldInsight做失效诊断和良率分析MBIST的fail数据可以反标到具体存储器的某一行某一列。在一个典型的DFT流程里Tessent通常会和Synopsys的DFTMAX、Mentor的Tmax、或自家Tessent ATPG协同工作。MBIST插完之后生成的pattern文件可以通过STIL或WGL格式交给ATPG工具做进一步处理也可以直接在Tessent环境里完成仿真验证。为什么我推荐用Tessent做MBIST而不是自己写RTL BIST逻辑最直接的原因是效率和可诊断性。自己写一个固定的状态机和March序列很简单但要做到多存储器控制器自动共享、算法可配置、pattern可编程、支持repair、支持诊断数据回读工程量非常大。Tessent把这一整套工业级能力封装好了你用约束和配置驱动它而不是从零去设计硬件逻辑。1.3 从零开始的完整流程概览一个完整的Tessent MBIST流程从我实际跑项目的经验看大致分成五个阶段阶段核心动作主要产出环境准备配置工具、读入库文件和RTL/网表可正常elaborate的设计数据库DFT规划定义测试模式、时钟复位约束、存储器待测清单约束文件、BIST配置逻辑插入插入BIST控制器、interface、TAP和repair逻辑带MBIST的新网表、相关报告验证闭环仿真pattern、检查PASS/FAIL、生成STIL仿真log、pattern文件、ATE交付件诊断/良率反标fail数据、定位具体存储单元诊断报告、repair方案这个顺序我建议第一次跑的时候严格照着走不要跳步。很多新手喜欢一上来就写insert脚本结果库文件版本不对、memory模型缺失或者约束没写全跑到一半报一堆和BIST无关的DRC错误排查起来非常痛苦。先把每一步的输入输出搞清楚后面优化起来才有抓手。2. 实操准备环境、库与目录规划2.1 工具setup别在版本和license上栽跟头先说环境。Tessent工具的版本差异比你想的要大不同版本之间的命令名、选项格式、报告格式都有差异。我最早用Tessent 2019后来跳到一个用2022版本的平台很多脚本返回的对象名和属性都不一样了。所以拿到新工具后第一件事不是写脚本而是打开工具自带的Release Notes和Command Reference确认你现在用的Tessent版本里insert_memory_bist、read_memory_library这些命令的具体用法有没有变化。环境变量方面最少要保证这三件事export TESSENT_HOME/opt/mentor/tessent/2022.4 export PATH$TESSENT_HOME/bin:$PATH export LM_LICENSE_FILEportlicense_server然后启动tessent -shell如果你公司有标准的DFT环境一般还会有一个setup脚本把额外的PDK路径、标准单元库路径、memory compiler路径一次性source好。这里我强烈建议你在自己的home目录下维护一个dft_setup.tcl把固定不变的library路径、标准路径都写进去每次开新项目直接source避免把大段路径拼在insert脚本里。2.2 库文件准备标准单元Memory CollateralMBIST插入不是纯逻辑操作它需要知道你要用哪些标准单元、哪些存储器宏单元、以及存储器宏单元的端口和时序信息。所以库文件准备是整个流程里最容易出错、但也最容易提前发现问题的环节。你需要准备的材料大致如下库类型常见文件用途标准单元Verilog模型.v文件Elaborate时识别逻辑门和触发器行为标准单元Liberty.lib文件综合/时序相关DFT工具也会读取以检查时钟/复位单元物理库可选.ndm/.db/.lef用于布局布线前的数据一致性检查Memory行为模型compiler生成的.v仿真时使用也可以用于elaborate识别存储器端口Memory时序/功耗模型compiler生成的.lib让BIST逻辑插入时能合理处理时钟域、供电域Memory FastPin/FastModel厂商特定格式提升仿真的速度和质量特别注意memory的collateral模型一定要和RTL里实例化的memory型号完全对应。比如你用SMIC 28nm工艺的某款单端口SRAM宏memory compiler会生成一个版本号这个版本号和PDK目录、Liberty里的版本号如果对不上Tessent可能识别不了端口或者仿真时行为模型与门级模型对不上出现X态扩散。读取库的典型写法是read_cell_library -file $TESSENT_STDCELLS/stdcells.v read_cell_library -file $TESSENT_MEMORY/sram_256x32.v read_cell_library -file $TESSENT_MEMORY/sram_1024x64.v如果你的设计里还有模拟IP、PLL、IO单元这类非数字模块最好也提供对应的行为仿真模型或者用set_dont_touch等方式让工具不对它们做DFT处理。2.3 设计输入与测试约束Tessent的输入可以是RTL也可以是已经做了部分扫描插入的门级网表。实际项目里我多半是在一个相对干净的RTL或早期综合网表上插入MBIST再由ScanInsert流程把扫描链、TAP、MBIST统一插完。如果你输入的是纯RTL工具会先elaborate成门级参考网表再在这个网表上插入DFT逻辑。除了网表本身测试约束是决定插入成败的关键。你需要告诉Tessent哪些信号是测试模式使能信号比如test_mode、scan_enable哪些时钟是功能时钟、哪些是测试时钟复位信号是同步复位还是异步复位测试模式下如何处理顶层哪些端口是JTAG/TAP端口哪些是MBIST专用的DFT端口。一个简单的约束片段看起来像这样set_var header_file common/header.tcl open_design # 定义测试模式 define_test_mode -name func_mode -active low define_test_mode -name shift_mode -active high # 定义时钟 define_clock -port clk -period 10.0 define_clock -port tck -period 33.0 # 定义复位 define_reset -port rst_n -active low -async这里面的test mode定义直接影响后续BIST controller的插入方式。你的测试模式信号必须和芯片顶层实际接法一致否则pattern在仿真环境里能过到了ATE上根本进不了正确模式这类问题调试起来非常头疼。2.4 目录结构规划DFT流程会产出大量中间文件和报告如果你不提前规划目录跑几个迭代之后整个workspace就乱了找东西全靠猜。我通常按下面这种方式建目录project_root/ rtl/ # 前端交付的RTL或门级网表 lib/ stdcells/ # 标准单元库 memory/ # memory compiler输出模型 scripts/ setup.tcl mbist_insert.tcl sim_run.tcl runs/ insertion/ # 每次插入的独立运行目录 simulation/ # 仿真运行目录 output/ # 最终交付网表、pattern、报告 logs/ # 关键log的归档每次跑插入前我会在runs/insertion下面建一个带时间戳的目录比如run_20250412_t28然后把这次的网表输出、pattern、报告都归到独立目录里。这样如果后面发现某次插入有问题还能翻到历史版本对比。不要贪图省事把每次运行都覆盖到同一个目录DFT迭代中“对比历史输出”是很常见的调试手段。3. 核心流程实现Tessent MBIST插入全过程3.1 配置文件与关键参数MBIST插入的第一步是创建BIST配置。Tessent里有一个核心的配置对象叫memory_bist_config你可以理解为一组规则它告诉工具哪些存储器要测、用什么算法、BIST控制器怎么共享、要不要repair逻辑。我贴一个实际项目风格的配置示例# 创建BIST配置对象 create_memory_bist_config -name mbist_config # 指定BIST算法和时钟 set_var mbist_algorithm march_13n set_var mbist_clock clk # 将指定存储器加入测试计划 add_memory -name top/u_ram_0 -config mbist_config add_memory -name top/u_ram_1 -config mbist_config # 让这两个存储器共享一个BIST控制器 share_memory -name top/u_ram_0 -with top/u_ram_1 # 可选使能repair enable_repair -config mbist_config -repair_type row_col这里有几个参数值得你多花时间理解算法选择march_13n是常用的工业级March算法比March C-能覆盖更多故障类型但测试时间也略长。如果项目对测试时间极其敏感可以选更快但覆盖率稍低的算法。这个选择本质上是测试时间和故障覆盖率的折中。共享控制器多个存储器共享一个BIST控制器可以显著减少面积功耗但代价是这些存储器会被串行测试测试时间会累加而且时钟域、位宽、端口类型不同的话共享条件会更严格。Repair逻辑如果芯片要做良率提升需要插入Built-In Self-RepairBISR即在存储器旁边添加冗余行/列和repair分析逻辑。这会增加可观面积所以要在DFT早点评估成本。配置对象创建好之后你还可能需要指定BIST controller的位置和命名。不要小看这个命名因为Tessent会自动生成一堆bist_controller_0、interface_0这样的名字如果你不做规范命名等写RTL/网表交付件时回读网表会很痛苦。3.2 跑插入流程每一条命令在做什么配置就绪后开始真正的插入流程。以Tessent Shell环境为例完整脚本大致如下# 0. 环境初始化 set_var header_file scripts/setup.tcl source setups/header.tcl # 1. 打开设计 open_design # 2. 读库 read_cell_library -file $STDCELLS/stdcells_tt.v read_cell_library -file $MEM_LIB/sram_256x32.v read_cell_library -file $MEM_LIB/sram_1024x64.v # 3. 读网表 read_verilog -file $RTL_DIR/top.v -format verilog read_verilog -file $RTL_DIR/sub_module.v -format verilog # 4. Elaborate elaborate_design -root top # 5. 插入MBIST insert_memory_bist -config mbist_config \ -instruments bist_controller_0 \ -respect_do_not_touch # 6. 连接顶层DFT端口 connect_tessent_port -port soc_tdi -role tdi connect_tessent_port -port soc_tdo -role tdo connect_tessent_port -port soc_tms -role tms connect_tessent_port -port soc_tck -role tck # 7. 插入TAP insert_tap -config tap_config # 8. 检查并输出 report_bist_config report_gates write_netlist $OUTPUT_DIR/top_mbist.v -replace write_patterns $OUTPUT_DIR/top_mbist_pattern.v -format verilog -replace write_patterns $OUTPUT_DIR/top_mbist_pattern.stil -format stil -replace write_report $OUTPUT_DIR/top_mbist.rpt -replace # 9. 保存设计数据库 save_design $OUTPUT_DIR/top_mbist_design -replace每个环节说重点read_cell_library不要漏掉任何memory model。漏一个后面elaborate时工具会把那个memory当成黑盒BIST逻辑根本连不上端口。elaborate_design -root top指定设计的顶层模块名。如果顶层名写错工具会报“root not found”之类的错误这时候第一反应不是查这个命令而是去网表里确认top模块叫什么。insert_memory_bist这是核心动作。工具会根据你的config把BIST controller、interface logic、wrapper逻辑、以及必要的test register自动插到设计里。这里面的逻辑连接不需要你手工描述但你要检查报告里每个存储器是否都成功挂上了controller、有没有被误判为不可测。connect_tessent_port把TAP端口和顶层引脚连起来。这一步相当于给芯片留了一个外部访问BIST逻辑的“窗口”没有它后续ATE进不了测试模式。write_patterns不仅仅是写一个verilog testbench还会写出一整套pattern包括扫描移位、BIST的启动与结果判断。-format stil生成的是工业标准的STIL文件后面ATPG工具、ATE都可以吃。这里我特别提醒一句插入成功后不要急着交付先跑一遍report_bist_config和report_gates。我见过不少朋友只看“生成成功”就直接把网表和pattern发出去了结果某一颗memory因为端口类型特殊没有挂进共享控制器测试覆盖率报表上少了一大块最后在验证阶段才被发现。这类问题在插入阶段查几分钟就能定位到了ATPG阶段查要重跑好几轮。3.3 插入后的逻辑结构插入完成后你的网表里会多出这几类逻辑逻辑块作用BIST Controller生成地址、数据、控制信号执行March算法比较并记录fail信息BIST Interface适配不同存储器端口的一组转换逻辑处理位宽、使能、读写时序Memory Wrapper包在每个被测存储器外面在功能模式和测试模式之间切换数据通路SIB/TDR测试访问机制让外部JTAG能选择不同的BIST控制器并对结果进行回读Repair Logic可选当检测到故障时将冗余行列重映射到故障位置理解这几个块的层次很重要。Tessent不是粗暴地把BIST逻辑贴在存储器旁边而是通过SIB和TDR形成一棵可寻址的“测试访问树”。你在chip顶层看到的可能只是一个TAP口加一串SIB链每个BIST controller挂在某个SIB节点下面。这种结构的好处是多个MBIST控制器可以共享一个TAP接口测试时通过shift register来选择启动哪一个而不需要给每个控制器单独拉出一组引脚。3.4 生成文件与交付物一次完整的MBIST插入输出文件至少有这么几类文件内容用途top_mbist.v插入了MBIST逻辑的最终网表交给综合/物理设计/ATPGtop_mbist_pattern.vVerilog测试bench含完整pattern门级仿真验证BIST功能top_mbist_pattern.stilSTIL格式pattern交给ATPG工具或ATEtop_mbist.rpt插入报告和覆盖率数据确认每个存储器是否都被覆盖top_mbist_designTessent内部设计数据库后续可追加约束、重新生成pattern交付时我习惯把top_mbist.rpt里的关键信息梳理成一张自检表包括每个被测存储器的名字、所属BIST controller、使用的算法、测试时间估算、共享情况。这些信息在项目评审和ATE调试时都用得上。3.5 带修复功能的BISR扩展如果你的芯片要做量产良率提升MBIST通常会带上BISR。Tessent的BISR流程比纯BIST多几步插入repair逻辑在配置里使能enable_repair工具会在存储器旁边加入冗余行/列和repair分析逻辑。冗余资源通常由memory compiler提前预留比如每一行多出8bit冗余列或者额外2行冗余行。fail数据的收集与分配BIST跑完后fail信息不是简单地报一个PASS/FAIL而是要收集具体哪一行、哪一列的读写失败。Tessent通过controller里的fail register记录这些地址再通过TAP口回读到外部交给repair分析工具做“allocation”。生成repair方案根据fail地址和可用冗余资源决定如何用冗余行/列替换故障行/列。Tessent会计算出最优的分配结果生成一个fuse map。fuse烧写最后把fuse map通过外部接口烧进芯片可以是eFuse、OTP或其他非易失存储芯片后续上电时repair逻辑会按fuse配置把冗余资源映射上去。BISR的坑主要在于fuse规划和时序。fuse数量是固定的冗余资源越多需要的fuse位越多但这会增加面积和烧写时间。你需要提早和memory compiler厂商确认这个宏支持多少冗余行/列、fuse接口是什么样的否则等到DFT插入阶段才发现宏单元不支持repair整个PPA预算都要重新排。4. 仿真验证与Pattern交付4.1 搭建MemoryBIST仿真环境插入逻辑只是第一步真正检验插入是否成功的是仿真。Tessent通常提供两种验证途径一是在Shell里直接跑内置的仿真流程它会自动调用ModelSim、VCS或Xcelium二是生成testbench文件后你在自己熟悉的验证环境里跑。我习惯的仿真环境搭建方式是这样的从Tessent插入流程拿到top_mbist.v网表和top_mbist_pattern.v准备memory行为模型.v和标准单元仿真库写一个编译脚本把所有库和网表编译到仿真器的work library里跑仿真观察pattern是否逐条通过。难点不在编译脚本而在memory行为模型的完整性。如果某个memory没有对应的行为模型仿真时工具会把它当黑盒BIST逻辑对黑盒的操作没有反馈结果自然是一堆X态。所以我在跑仿真前有一个习惯先用report_memory_models把当前设计用到的所有memory模型列出来逐个确认模型文件存在且版本正确。4.2 跑Pattern仿真如何判断通过仿真跑起来后输出log里会有大量信息但你需要重点关注的就是PASS/FAIL判断。Tessent生成的testbench通常会把所有pattern跑完后打印类似Test PASSED或Test FAILED的结果同时每个pattern也有独立的比较逻辑。我见过不少新手在log里看到几个红色的FAIL就慌了其实要分情况看如果只是某一条pattern里的内部信号显示FAIL但最终summary是PASSED那大概率是测试bench里对某些信号的捕获机制看到的是预期内的值如果summary是FAILED并且报了具体某个pattern编号或某个存储器实例那就需要认真排查了。排查思路通常是这样打开fail对应的仿真时间点看BIST controller在跑哪个地址、哪个操作再看读回来的数据是哪一位和期望值不一致。这个数据可以帮你判断是存储器行为模型本身的问题还是BIST逻辑没连对又或者是rst/clock时序没对齐。提示仿真log里出现大量X态时先检查设计是否做了正确的初始化。很多MBIST pattern在进BIST模式前需要先通过测试模式信号把存储器和控制逻辑置到一个确定状态而不是触发器默认的X。你可以查看pattern开头那段初始化序列确认它是否包含了test_mode的拉高、复位释放等步骤。4.3 OCC与STIL/ATPG接口仿真验证通过后接着要把pattern导出成ATPG工具和ATE能消费的格式。这里就要提到一个关键概念OCCOn-Chip Clock片上时钟控制。MBIST测试里有相当一部分算法要求at-speed操作也就是用功能时钟频率去读存储器。但这个“功能时钟”在测试模式下不能直接乱来它必须受控先让BIST逻辑在慢速扫描时钟下装入状态再在捕获脉冲时切到功能时钟产生一拍高速读写最后再切回慢速时钟。OCC就是做这个切换控制的逻辑。Tessent生成STIL文件时会通过约束告诉ATPG工具哪些时钟是BIST用到的at-speed时钟哪个测试模式允许启动这些时钟。你可以在insert_memory_bist之后用类似这样的方式生成STILwrite_patterns $OUTPUT_DIR/top_mbist_pattern.stil \ -format stil \ -replace生成之后建议打开STIL文件快速扫一眼开头部分确认里面是否包含了正确的Signal声明和Timing定义。有些版本的Tessent需要你先定义OCC约束否则STIL会缺失关键时钟定义到了Tmax或Modus里会报warning。5. 常见问题与排查技巧这些坑我都踩过5.1 时钟、复位在测试模式下的坑MBIST插入过程中报的最多的一类问题就是时钟和复位约束不合理。典型场景是BIST controller的时钟来自一个自由运行的振荡器或PLL输出但测试模式要求它在扫描移位时保持恒定的低电平或高电平结果工具报unstable clock。解决办法是在test mode约束里明确告诉工具这组时钟只有在capture阶段才能toggle其他阶段都要关掉。复位也一样。很多SoC的复位控制器在功能模式下有复杂的上下电时序但测试模式下如果允许异步复位随意翻转BIST controller里的状态机会被反复打断pattern完全跑不起来。我在项目中通常会加一条约束让复位在测试期间保持释放状态只在初始化序列里给一次确定的复位脉冲。这类问题最好的排查工具是Tessent自带的DRC报告。插入前跑一遍DRC绝大多数时钟/复位问题都能提前暴露。不要等插入完了才看结果那会儿报错信息已经被一大堆逻辑连接噪声淹没了。5.2 端口连接报错的常见原因如果insert_memory_bist阶段报某个端口的连接错误多半是下面几种情况现象可能原因处理方式报“cannot connect data port width mismatch”memory数据位宽和BIST interface期望位宽不一致检查memory模型端口定义是否完整报“unconnected port”存储器某些测试专用端口没定义在memory collateral里补全端口或用set_dont_touch跳过报“unknown pin”memory实例名或端口名拼写错误打开网表确认实际端口名报“tie-off issue”某些控制端口需要固定到特定电平但工具无法决定显式给出pin约束这里尤其要注意那些multi-bit端口的定义。比如一个1024x64的SRAM数据端口的名字可能是D[63:0]但memory compiler生成的collateral模型里如果把它拆成了64个单bit端口Tessent在连接BIST interface时就会因为位宽不匹配报错。出现这种情况先检查collateral模型版本是不是和memory实例一致再来调整脚本。5.3 多个存储器共享Controller时的冲突共享controller能省面积和功耗但也会带来一些隐蔽问题。最典型的是时钟域冲突如果两个存储器分别跑在不同时钟域但被配到同一个BIST controller下工具要么拒报错误要么默默使用其中一个时钟导致另一个存储器的at-speed测试有问题。我的建议是除非两个存储器在物理上非常近、时钟域一致、端口类型一致否则不要强行共享controller。省下的面积跟后续测试时序调试花的工时相比往往不划算。如果确实要共享务必在配置里明确指定共享控制器使用的时钟并通过DRC确认两个存储器的时序约束不冲突。5.4 仿真不过时的定位思路仿真跑fail是最消耗时间的环节。按我踩过这么多次坑的经验排查顺序应该是先看是不是memory行为模型版本和实际宏不一致。换一个版本号重新编译仿真很多时候问题就消失了。再看初始化序列。打开pattern文件的头部确认test_mode、复位信号是否按预期拉高/拉低。如果pattern里根本没有初始化步骤那是生成时的约束缺失需要回到插入流程重新生成。再看时钟切换时点。BIST的at-speed操作要求在capture阶段精确控制时钟个数如果OCC逻辑没插好读取窗口会偏移表现就是某些存储单元的读结果偶尔对、偶尔错。最后才怀疑BIST逻辑本身有问题。Tessent生成的逻辑经过大量硅验证出logic bug的概率远比前几种情况低。5.5 BISR/Repair流程注意事项做BISR的时候最容易被忽略的是fuse分析和仿真验证的衔接。Tessent的repair分析跑完之后会生成一个fuse map但这个fuse map能不能在芯片量产时正确烧写还依赖于你的fuse接口和烧写时序。我遇到过项目repair仿真在EDA环境里都过了结果量产时发现eFuse接口的采样时序和BIST controller对不上烧进去的fuse总是少一组最后又回到设计端补了一版时序约束。所以如果你要做repair务必在DFT早期就和Memory Compiler厂商、以及负责eFuse/OTP的IP工程师对齐接口时序。不要等网表都冻结了再倒回来加这些约束那种改动在项目后期是非常伤筋动骨的。最后再分享一个小技巧跑DFT流程一定要养成把脚本和输出归档的习惯。同一个设计我经常因为改了一个时钟约束就要重新生成一整套网表和pattern。如果每次都在同一个目录覆盖运行后面出了问题很难判断“这个pattern是哪个版本生成的”。我现在习惯在每次跑插入之前先给脚本打一个日期版本标签比如mbist_insert_t28_0412.tcl并把对应的输出目录命名为同一个tag。这样每一条pattern都能追溯到确切的生成环境无论是调试还是团队协作都能少踩很多坑。 Tessent MBIST插入全流程：从零构建芯片存储器内建自测试方案
芯片做到可测试性设计DFT这一步前端的RTL写得再漂亮如果MBIST方案没搭好流片回来一大批嵌入式存储器没法测整块芯片就只能靠外部ATE硬怼时间、功耗、管脚全都不够用。MBISTMemory Built-In Self-Test内建自测试把测试激励、响应比较、故障判定全部搬到片上用一个专用BIST控制器去驱动存储器阵列从而在不依赖外部测试机资源的情况下完成嵌入式存储器的功能测试。Tessent就是做这件事用得最多、也最成熟的工具链无论是老牌大厂还是初创公司DFT工程师手上几乎都有一套Tessent流程。这篇内容不聊空中楼阁直接从完整流程讲起把从零开始插入MBIST逻辑、生成测试向量、做仿真验证到对接ATE的整个链路给你捋清楚。1. 内容整体设计与流程拆解1.1 为什么要做MBIST内部存储器到底有多难测先看一个现实问题一颗SoC芯片里嵌入式SRAM、寄存器堆Register File、缓存阵列加起来动辄几十上百个实例有些大存储器的位宽能到512bit甚至更高端口深度也可能超过4K。这些存储器分布在芯片各个角落和外部管脚之间没有昂贵的专用数据通路。如果靠外部ATE直接访问你需要把大量地址、数据、控制信号引到封装管脚上或者靠扫描链把存储器的输入输出端口串行搬移出来代价非常夸张。更麻烦的是存储器测试不是简单地读一遍、写一遍就算完。它要测固定故障SA0/SA1、转换故障Transition Fault、耦合故障Coupling Fault、地址译码故障Address Decoder Fault等这些故障模型要求执行特定的March序列。比如常用的March C-算法是一连串的写0、读0、写1、读1操作组合按特定地址方向反复走好几遍。如果靠外部的低速测试机一条条去搬数据一个大存储器的完整测试时间会拖垮整个产品线的产能。这时候MBIST的价值就出来了在芯片内部放一个BIST控制器由它按照预定算法生成读写序列直接把pattern打到存储器端口上再把读回来的数据和期望值做比较最后输出一个PASS/FAIL信号。测试激励不需要从外部灌进来测试响应也不需要搬出去ATE只需要通过JTAG/TAP接口触发一次BIST引擎然后收一个结果信号即可。打个比方这就像图书馆从挨个人工盘点每本书变成了在每个书架上装一个自助检查终端管理员只需要按一下“开始自检”按钮最后看一眼绿灯还是红灯。Tessent做MBIST的核心理念就是把“如何生成March序列”、“如何连接BIST逻辑”、“如何把多个存储器的控制器共享和调度起来”、“如何输出可诊断的pattern”这些事全部自动化。你作为DFT工程师主要的精力集中在配置哪些存储器需要测试、用哪种算法、控制器怎么共享、时钟复位怎么约束以及后续pattern怎么仿真验证。这套流程一旦走通后面加新存储器、换工艺节点、改时钟方案都是增量式操作不会推翻重来。1.2 Tessent在可测试性设计流程里的定位Tessent这个平台覆盖了整个DFT后端链条。早期的命名你可能听过MemoryBIST、ScanInsert、ATPG、Diagnosis现在统一归在Tessent旗下。拿我常用的组件来说Tessent ScanInsert负责扫描链的插入和压缩逻辑生成现在MBIST的插入也集成在这个环境里因为MBIST本质上是在门级网表上嵌入一段带扫描接口的逻辑。Tessent Shell底层核心环境很多脚本驱动的流程都从这里发起比如读库、读网表、elaborate、做BIST插入、写pattern。Tessent MemoryBIST专门负责存储器内建自测试逻辑生成包括controller、interface、wrapper、以及可选的repair逻辑。Tessent TestCompress做扫描压缩让更少的测试管脚覆盖更多内部扫描链。Tessent Diagnosis/Tessent YieldInsight做失效诊断和良率分析MBIST的fail数据可以反标到具体存储器的某一行某一列。在一个典型的DFT流程里Tessent通常会和Synopsys的DFTMAX、Mentor的Tmax、或自家Tessent ATPG协同工作。MBIST插完之后生成的pattern文件可以通过STIL或WGL格式交给ATPG工具做进一步处理也可以直接在Tessent环境里完成仿真验证。为什么我推荐用Tessent做MBIST而不是自己写RTL BIST逻辑最直接的原因是效率和可诊断性。自己写一个固定的状态机和March序列很简单但要做到多存储器控制器自动共享、算法可配置、pattern可编程、支持repair、支持诊断数据回读工程量非常大。Tessent把这一整套工业级能力封装好了你用约束和配置驱动它而不是从零去设计硬件逻辑。1.3 从零开始的完整流程概览一个完整的Tessent MBIST流程从我实际跑项目的经验看大致分成五个阶段阶段核心动作主要产出环境准备配置工具、读入库文件和RTL/网表可正常elaborate的设计数据库DFT规划定义测试模式、时钟复位约束、存储器待测清单约束文件、BIST配置逻辑插入插入BIST控制器、interface、TAP和repair逻辑带MBIST的新网表、相关报告验证闭环仿真pattern、检查PASS/FAIL、生成STIL仿真log、pattern文件、ATE交付件诊断/良率反标fail数据、定位具体存储单元诊断报告、repair方案这个顺序我建议第一次跑的时候严格照着走不要跳步。很多新手喜欢一上来就写insert脚本结果库文件版本不对、memory模型缺失或者约束没写全跑到一半报一堆和BIST无关的DRC错误排查起来非常痛苦。先把每一步的输入输出搞清楚后面优化起来才有抓手。2. 实操准备环境、库与目录规划2.1 工具setup别在版本和license上栽跟头先说环境。Tessent工具的版本差异比你想的要大不同版本之间的命令名、选项格式、报告格式都有差异。我最早用Tessent 2019后来跳到一个用2022版本的平台很多脚本返回的对象名和属性都不一样了。所以拿到新工具后第一件事不是写脚本而是打开工具自带的Release Notes和Command Reference确认你现在用的Tessent版本里insert_memory_bist、read_memory_library这些命令的具体用法有没有变化。环境变量方面最少要保证这三件事export TESSENT_HOME/opt/mentor/tessent/2022.4 export PATH$TESSENT_HOME/bin:$PATH export LM_LICENSE_FILEportlicense_server然后启动tessent -shell如果你公司有标准的DFT环境一般还会有一个setup脚本把额外的PDK路径、标准单元库路径、memory compiler路径一次性source好。这里我强烈建议你在自己的home目录下维护一个dft_setup.tcl把固定不变的library路径、标准路径都写进去每次开新项目直接source避免把大段路径拼在insert脚本里。2.2 库文件准备标准单元Memory CollateralMBIST插入不是纯逻辑操作它需要知道你要用哪些标准单元、哪些存储器宏单元、以及存储器宏单元的端口和时序信息。所以库文件准备是整个流程里最容易出错、但也最容易提前发现问题的环节。你需要准备的材料大致如下库类型常见文件用途标准单元Verilog模型.v文件Elaborate时识别逻辑门和触发器行为标准单元Liberty.lib文件综合/时序相关DFT工具也会读取以检查时钟/复位单元物理库可选.ndm/.db/.lef用于布局布线前的数据一致性检查Memory行为模型compiler生成的.v仿真时使用也可以用于elaborate识别存储器端口Memory时序/功耗模型compiler生成的.lib让BIST逻辑插入时能合理处理时钟域、供电域Memory FastPin/FastModel厂商特定格式提升仿真的速度和质量特别注意memory的collateral模型一定要和RTL里实例化的memory型号完全对应。比如你用SMIC 28nm工艺的某款单端口SRAM宏memory compiler会生成一个版本号这个版本号和PDK目录、Liberty里的版本号如果对不上Tessent可能识别不了端口或者仿真时行为模型与门级模型对不上出现X态扩散。读取库的典型写法是read_cell_library -file $TESSENT_STDCELLS/stdcells.v read_cell_library -file $TESSENT_MEMORY/sram_256x32.v read_cell_library -file $TESSENT_MEMORY/sram_1024x64.v如果你的设计里还有模拟IP、PLL、IO单元这类非数字模块最好也提供对应的行为仿真模型或者用set_dont_touch等方式让工具不对它们做DFT处理。2.3 设计输入与测试约束Tessent的输入可以是RTL也可以是已经做了部分扫描插入的门级网表。实际项目里我多半是在一个相对干净的RTL或早期综合网表上插入MBIST再由ScanInsert流程把扫描链、TAP、MBIST统一插完。如果你输入的是纯RTL工具会先elaborate成门级参考网表再在这个网表上插入DFT逻辑。除了网表本身测试约束是决定插入成败的关键。你需要告诉Tessent哪些信号是测试模式使能信号比如test_mode、scan_enable哪些时钟是功能时钟、哪些是测试时钟复位信号是同步复位还是异步复位测试模式下如何处理顶层哪些端口是JTAG/TAP端口哪些是MBIST专用的DFT端口。一个简单的约束片段看起来像这样set_var header_file common/header.tcl open_design # 定义测试模式 define_test_mode -name func_mode -active low define_test_mode -name shift_mode -active high # 定义时钟 define_clock -port clk -period 10.0 define_clock -port tck -period 33.0 # 定义复位 define_reset -port rst_n -active low -async这里面的test mode定义直接影响后续BIST controller的插入方式。你的测试模式信号必须和芯片顶层实际接法一致否则pattern在仿真环境里能过到了ATE上根本进不了正确模式这类问题调试起来非常头疼。2.4 目录结构规划DFT流程会产出大量中间文件和报告如果你不提前规划目录跑几个迭代之后整个workspace就乱了找东西全靠猜。我通常按下面这种方式建目录project_root/ rtl/ # 前端交付的RTL或门级网表 lib/ stdcells/ # 标准单元库 memory/ # memory compiler输出模型 scripts/ setup.tcl mbist_insert.tcl sim_run.tcl runs/ insertion/ # 每次插入的独立运行目录 simulation/ # 仿真运行目录 output/ # 最终交付网表、pattern、报告 logs/ # 关键log的归档每次跑插入前我会在runs/insertion下面建一个带时间戳的目录比如run_20250412_t28然后把这次的网表输出、pattern、报告都归到独立目录里。这样如果后面发现某次插入有问题还能翻到历史版本对比。不要贪图省事把每次运行都覆盖到同一个目录DFT迭代中“对比历史输出”是很常见的调试手段。3. 核心流程实现Tessent MBIST插入全过程3.1 配置文件与关键参数MBIST插入的第一步是创建BIST配置。Tessent里有一个核心的配置对象叫memory_bist_config你可以理解为一组规则它告诉工具哪些存储器要测、用什么算法、BIST控制器怎么共享、要不要repair逻辑。我贴一个实际项目风格的配置示例# 创建BIST配置对象 create_memory_bist_config -name mbist_config # 指定BIST算法和时钟 set_var mbist_algorithm march_13n set_var mbist_clock clk # 将指定存储器加入测试计划 add_memory -name top/u_ram_0 -config mbist_config add_memory -name top/u_ram_1 -config mbist_config # 让这两个存储器共享一个BIST控制器 share_memory -name top/u_ram_0 -with top/u_ram_1 # 可选使能repair enable_repair -config mbist_config -repair_type row_col这里有几个参数值得你多花时间理解算法选择march_13n是常用的工业级March算法比March C-能覆盖更多故障类型但测试时间也略长。如果项目对测试时间极其敏感可以选更快但覆盖率稍低的算法。这个选择本质上是测试时间和故障覆盖率的折中。共享控制器多个存储器共享一个BIST控制器可以显著减少面积功耗但代价是这些存储器会被串行测试测试时间会累加而且时钟域、位宽、端口类型不同的话共享条件会更严格。Repair逻辑如果芯片要做良率提升需要插入Built-In Self-RepairBISR即在存储器旁边添加冗余行/列和repair分析逻辑。这会增加可观面积所以要在DFT早点评估成本。配置对象创建好之后你还可能需要指定BIST controller的位置和命名。不要小看这个命名因为Tessent会自动生成一堆bist_controller_0、interface_0这样的名字如果你不做规范命名等写RTL/网表交付件时回读网表会很痛苦。3.2 跑插入流程每一条命令在做什么配置就绪后开始真正的插入流程。以Tessent Shell环境为例完整脚本大致如下# 0. 环境初始化 set_var header_file scripts/setup.tcl source setups/header.tcl # 1. 打开设计 open_design # 2. 读库 read_cell_library -file $STDCELLS/stdcells_tt.v read_cell_library -file $MEM_LIB/sram_256x32.v read_cell_library -file $MEM_LIB/sram_1024x64.v # 3. 读网表 read_verilog -file $RTL_DIR/top.v -format verilog read_verilog -file $RTL_DIR/sub_module.v -format verilog # 4. Elaborate elaborate_design -root top # 5. 插入MBIST insert_memory_bist -config mbist_config \ -instruments bist_controller_0 \ -respect_do_not_touch # 6. 连接顶层DFT端口 connect_tessent_port -port soc_tdi -role tdi connect_tessent_port -port soc_tdo -role tdo connect_tessent_port -port soc_tms -role tms connect_tessent_port -port soc_tck -role tck # 7. 插入TAP insert_tap -config tap_config # 8. 检查并输出 report_bist_config report_gates write_netlist $OUTPUT_DIR/top_mbist.v -replace write_patterns $OUTPUT_DIR/top_mbist_pattern.v -format verilog -replace write_patterns $OUTPUT_DIR/top_mbist_pattern.stil -format stil -replace write_report $OUTPUT_DIR/top_mbist.rpt -replace # 9. 保存设计数据库 save_design $OUTPUT_DIR/top_mbist_design -replace每个环节说重点read_cell_library不要漏掉任何memory model。漏一个后面elaborate时工具会把那个memory当成黑盒BIST逻辑根本连不上端口。elaborate_design -root top指定设计的顶层模块名。如果顶层名写错工具会报“root not found”之类的错误这时候第一反应不是查这个命令而是去网表里确认top模块叫什么。insert_memory_bist这是核心动作。工具会根据你的config把BIST controller、interface logic、wrapper逻辑、以及必要的test register自动插到设计里。这里面的逻辑连接不需要你手工描述但你要检查报告里每个存储器是否都成功挂上了controller、有没有被误判为不可测。connect_tessent_port把TAP端口和顶层引脚连起来。这一步相当于给芯片留了一个外部访问BIST逻辑的“窗口”没有它后续ATE进不了测试模式。write_patterns不仅仅是写一个verilog testbench还会写出一整套pattern包括扫描移位、BIST的启动与结果判断。-format stil生成的是工业标准的STIL文件后面ATPG工具、ATE都可以吃。这里我特别提醒一句插入成功后不要急着交付先跑一遍report_bist_config和report_gates。我见过不少朋友只看“生成成功”就直接把网表和pattern发出去了结果某一颗memory因为端口类型特殊没有挂进共享控制器测试覆盖率报表上少了一大块最后在验证阶段才被发现。这类问题在插入阶段查几分钟就能定位到了ATPG阶段查要重跑好几轮。3.3 插入后的逻辑结构插入完成后你的网表里会多出这几类逻辑逻辑块作用BIST Controller生成地址、数据、控制信号执行March算法比较并记录fail信息BIST Interface适配不同存储器端口的一组转换逻辑处理位宽、使能、读写时序Memory Wrapper包在每个被测存储器外面在功能模式和测试模式之间切换数据通路SIB/TDR测试访问机制让外部JTAG能选择不同的BIST控制器并对结果进行回读Repair Logic可选当检测到故障时将冗余行列重映射到故障位置理解这几个块的层次很重要。Tessent不是粗暴地把BIST逻辑贴在存储器旁边而是通过SIB和TDR形成一棵可寻址的“测试访问树”。你在chip顶层看到的可能只是一个TAP口加一串SIB链每个BIST controller挂在某个SIB节点下面。这种结构的好处是多个MBIST控制器可以共享一个TAP接口测试时通过shift register来选择启动哪一个而不需要给每个控制器单独拉出一组引脚。3.4 生成文件与交付物一次完整的MBIST插入输出文件至少有这么几类文件内容用途top_mbist.v插入了MBIST逻辑的最终网表交给综合/物理设计/ATPGtop_mbist_pattern.vVerilog测试bench含完整pattern门级仿真验证BIST功能top_mbist_pattern.stilSTIL格式pattern交给ATPG工具或ATEtop_mbist.rpt插入报告和覆盖率数据确认每个存储器是否都被覆盖top_mbist_designTessent内部设计数据库后续可追加约束、重新生成pattern交付时我习惯把top_mbist.rpt里的关键信息梳理成一张自检表包括每个被测存储器的名字、所属BIST controller、使用的算法、测试时间估算、共享情况。这些信息在项目评审和ATE调试时都用得上。3.5 带修复功能的BISR扩展如果你的芯片要做量产良率提升MBIST通常会带上BISR。Tessent的BISR流程比纯BIST多几步插入repair逻辑在配置里使能enable_repair工具会在存储器旁边加入冗余行/列和repair分析逻辑。冗余资源通常由memory compiler提前预留比如每一行多出8bit冗余列或者额外2行冗余行。fail数据的收集与分配BIST跑完后fail信息不是简单地报一个PASS/FAIL而是要收集具体哪一行、哪一列的读写失败。Tessent通过controller里的fail register记录这些地址再通过TAP口回读到外部交给repair分析工具做“allocation”。生成repair方案根据fail地址和可用冗余资源决定如何用冗余行/列替换故障行/列。Tessent会计算出最优的分配结果生成一个fuse map。fuse烧写最后把fuse map通过外部接口烧进芯片可以是eFuse、OTP或其他非易失存储芯片后续上电时repair逻辑会按fuse配置把冗余资源映射上去。BISR的坑主要在于fuse规划和时序。fuse数量是固定的冗余资源越多需要的fuse位越多但这会增加面积和烧写时间。你需要提早和memory compiler厂商确认这个宏支持多少冗余行/列、fuse接口是什么样的否则等到DFT插入阶段才发现宏单元不支持repair整个PPA预算都要重新排。4. 仿真验证与Pattern交付4.1 搭建MemoryBIST仿真环境插入逻辑只是第一步真正检验插入是否成功的是仿真。Tessent通常提供两种验证途径一是在Shell里直接跑内置的仿真流程它会自动调用ModelSim、VCS或Xcelium二是生成testbench文件后你在自己熟悉的验证环境里跑。我习惯的仿真环境搭建方式是这样的从Tessent插入流程拿到top_mbist.v网表和top_mbist_pattern.v准备memory行为模型.v和标准单元仿真库写一个编译脚本把所有库和网表编译到仿真器的work library里跑仿真观察pattern是否逐条通过。难点不在编译脚本而在memory行为模型的完整性。如果某个memory没有对应的行为模型仿真时工具会把它当黑盒BIST逻辑对黑盒的操作没有反馈结果自然是一堆X态。所以我在跑仿真前有一个习惯先用report_memory_models把当前设计用到的所有memory模型列出来逐个确认模型文件存在且版本正确。4.2 跑Pattern仿真如何判断通过仿真跑起来后输出log里会有大量信息但你需要重点关注的就是PASS/FAIL判断。Tessent生成的testbench通常会把所有pattern跑完后打印类似Test PASSED或Test FAILED的结果同时每个pattern也有独立的比较逻辑。我见过不少新手在log里看到几个红色的FAIL就慌了其实要分情况看如果只是某一条pattern里的内部信号显示FAIL但最终summary是PASSED那大概率是测试bench里对某些信号的捕获机制看到的是预期内的值如果summary是FAILED并且报了具体某个pattern编号或某个存储器实例那就需要认真排查了。排查思路通常是这样打开fail对应的仿真时间点看BIST controller在跑哪个地址、哪个操作再看读回来的数据是哪一位和期望值不一致。这个数据可以帮你判断是存储器行为模型本身的问题还是BIST逻辑没连对又或者是rst/clock时序没对齐。提示仿真log里出现大量X态时先检查设计是否做了正确的初始化。很多MBIST pattern在进BIST模式前需要先通过测试模式信号把存储器和控制逻辑置到一个确定状态而不是触发器默认的X。你可以查看pattern开头那段初始化序列确认它是否包含了test_mode的拉高、复位释放等步骤。4.3 OCC与STIL/ATPG接口仿真验证通过后接着要把pattern导出成ATPG工具和ATE能消费的格式。这里就要提到一个关键概念OCCOn-Chip Clock片上时钟控制。MBIST测试里有相当一部分算法要求at-speed操作也就是用功能时钟频率去读存储器。但这个“功能时钟”在测试模式下不能直接乱来它必须受控先让BIST逻辑在慢速扫描时钟下装入状态再在捕获脉冲时切到功能时钟产生一拍高速读写最后再切回慢速时钟。OCC就是做这个切换控制的逻辑。Tessent生成STIL文件时会通过约束告诉ATPG工具哪些时钟是BIST用到的at-speed时钟哪个测试模式允许启动这些时钟。你可以在insert_memory_bist之后用类似这样的方式生成STILwrite_patterns $OUTPUT_DIR/top_mbist_pattern.stil \ -format stil \ -replace生成之后建议打开STIL文件快速扫一眼开头部分确认里面是否包含了正确的Signal声明和Timing定义。有些版本的Tessent需要你先定义OCC约束否则STIL会缺失关键时钟定义到了Tmax或Modus里会报warning。5. 常见问题与排查技巧这些坑我都踩过5.1 时钟、复位在测试模式下的坑MBIST插入过程中报的最多的一类问题就是时钟和复位约束不合理。典型场景是BIST controller的时钟来自一个自由运行的振荡器或PLL输出但测试模式要求它在扫描移位时保持恒定的低电平或高电平结果工具报unstable clock。解决办法是在test mode约束里明确告诉工具这组时钟只有在capture阶段才能toggle其他阶段都要关掉。复位也一样。很多SoC的复位控制器在功能模式下有复杂的上下电时序但测试模式下如果允许异步复位随意翻转BIST controller里的状态机会被反复打断pattern完全跑不起来。我在项目中通常会加一条约束让复位在测试期间保持释放状态只在初始化序列里给一次确定的复位脉冲。这类问题最好的排查工具是Tessent自带的DRC报告。插入前跑一遍DRC绝大多数时钟/复位问题都能提前暴露。不要等插入完了才看结果那会儿报错信息已经被一大堆逻辑连接噪声淹没了。5.2 端口连接报错的常见原因如果insert_memory_bist阶段报某个端口的连接错误多半是下面几种情况现象可能原因处理方式报“cannot connect data port width mismatch”memory数据位宽和BIST interface期望位宽不一致检查memory模型端口定义是否完整报“unconnected port”存储器某些测试专用端口没定义在memory collateral里补全端口或用set_dont_touch跳过报“unknown pin”memory实例名或端口名拼写错误打开网表确认实际端口名报“tie-off issue”某些控制端口需要固定到特定电平但工具无法决定显式给出pin约束这里尤其要注意那些multi-bit端口的定义。比如一个1024x64的SRAM数据端口的名字可能是D[63:0]但memory compiler生成的collateral模型里如果把它拆成了64个单bit端口Tessent在连接BIST interface时就会因为位宽不匹配报错。出现这种情况先检查collateral模型版本是不是和memory实例一致再来调整脚本。5.3 多个存储器共享Controller时的冲突共享controller能省面积和功耗但也会带来一些隐蔽问题。最典型的是时钟域冲突如果两个存储器分别跑在不同时钟域但被配到同一个BIST controller下工具要么拒报错误要么默默使用其中一个时钟导致另一个存储器的at-speed测试有问题。我的建议是除非两个存储器在物理上非常近、时钟域一致、端口类型一致否则不要强行共享controller。省下的面积跟后续测试时序调试花的工时相比往往不划算。如果确实要共享务必在配置里明确指定共享控制器使用的时钟并通过DRC确认两个存储器的时序约束不冲突。5.4 仿真不过时的定位思路仿真跑fail是最消耗时间的环节。按我踩过这么多次坑的经验排查顺序应该是先看是不是memory行为模型版本和实际宏不一致。换一个版本号重新编译仿真很多时候问题就消失了。再看初始化序列。打开pattern文件的头部确认test_mode、复位信号是否按预期拉高/拉低。如果pattern里根本没有初始化步骤那是生成时的约束缺失需要回到插入流程重新生成。再看时钟切换时点。BIST的at-speed操作要求在capture阶段精确控制时钟个数如果OCC逻辑没插好读取窗口会偏移表现就是某些存储单元的读结果偶尔对、偶尔错。最后才怀疑BIST逻辑本身有问题。Tessent生成的逻辑经过大量硅验证出logic bug的概率远比前几种情况低。5.5 BISR/Repair流程注意事项做BISR的时候最容易被忽略的是fuse分析和仿真验证的衔接。Tessent的repair分析跑完之后会生成一个fuse map但这个fuse map能不能在芯片量产时正确烧写还依赖于你的fuse接口和烧写时序。我遇到过项目repair仿真在EDA环境里都过了结果量产时发现eFuse接口的采样时序和BIST controller对不上烧进去的fuse总是少一组最后又回到设计端补了一版时序约束。所以如果你要做repair务必在DFT早期就和Memory Compiler厂商、以及负责eFuse/OTP的IP工程师对齐接口时序。不要等网表都冻结了再倒回来加这些约束那种改动在项目后期是非常伤筋动骨的。最后再分享一个小技巧跑DFT流程一定要养成把脚本和输出归档的习惯。同一个设计我经常因为改了一个时钟约束就要重新生成一整套网表和pattern。如果每次都在同一个目录覆盖运行后面出了问题很难判断“这个pattern是哪个版本生成的”。我现在习惯在每次跑插入之前先给脚本打一个日期版本标签比如mbist_insert_t28_0412.tcl并把对应的输出目录命名为同一个tag。这样每一条pattern都能追溯到确切的生成环境无论是调试还是团队协作都能少踩很多坑。