第一次在量产测试方案里正式落地Tessent MBIST时我还在做一颗带16块SRAM的SoC。当时最深的感受是可测试性设计DFT做得不到位到了ATE测试台上会成倍地还回来。MBISTMemory Built-In Self-Test存储器内建自测试就是解决存储阵列测试问题最核心的手段而Tessent MBIST是行业内落地这一方案的主流工具。这篇文章不打算做工具手册搬运我会从原理、工程准备、插入流程、测试时间权衡一直到踩坑细节完整梳理一遍从零搭建Tessent MBIST流程的思路。适合的读者正在学DFT的在校学生、刚接手DFT工作的数字IC工程师、以及想在项目里引入MBIST但不知道从哪下手的团队。看完你能掌握整套流程的骨架也知道每个环节为什么要这么做。1. 为什么存储器测试绕不开MBIST这一关1.1 存储阵列的测试困境扫描链为什么覆盖不到芯片里的存储单元和标准逻辑单元有本质区别。标准逻辑可以通过扫描链把DFF串成移位寄存器测试时把激励灌进去、把响应移出来。但到了SRAM这种高密度阵列事情就变了一颗大SRAM里面有几十万甚至上百万个bit cell每个bit cell本质上都是一个独立的状态保持节点。想用扫描链去覆盖这些bit cell理论上当然可以给每个存储单元加扫描访问通路但代价极其恐怖——面积翻倍、功耗暴涨、时序恶化没有任何量产芯片能接受这种开销。这就是为什么行业里几乎没人用纯scan方式测大容量存储器。另一个常见误区是把存储器测试完全丢给ATE外部向量。问题是存储器的测试需要高频率、连续不断的读写序列外部测试机台要提供这么大量的数据成本高、速度慢而且引脚带宽根本不够。面对高速高密度存储阵列唯一可行的方案是把测试逻辑搬进芯片内部也就是MBIST。1.2 March测试算法存储器测试的标准答案MBIST并不是简单地往存储器里写一组数据再读出来比对。行业里经过几十年沉淀形成了一整套标准化的存储器测试算法统称为March算法。March算法的核心思想是按照特定顺序对存储器中的每个地址执行一组有限的操作序列包括写0、写1、读0、读1并配合地址递增或递减。每个操作序列称为一个March元素整个算法就是这些元素的组合。举一个最经典的例子March C-算法。它一共有10个March元素复杂度是10NN是存储器的地址数。它能够覆盖绝大部分固定故障SAF、转换故障TF、地址译码故障AF和耦合故障CF。这也是Tessent MBIST中默认算法最常见的选项之一。不同的March算法在故障覆盖率和测试时间上各有取舍算法复杂度主要覆盖故障类型适用场景March C-10NSAF、TF、AF、大部分CF最常用的默认选择March SS22N在C-基础上增强CF覆盖高可靠性场景March LR14N动态故障、读干扰故障深亚微米工艺下常见March 13N13N某些特定耦合故障自定义补充测试选择哪种算法本质上是覆盖率、测试时间和硬件复杂度三者之间的权衡。Tessent MBIST允许你对不同的存储器实例单独指定算法这在实际项目中非常实用——对可靠性要求高的车规芯片用更强算法对消费类芯片则用更经济的方案。1.3 MBIST的硬件自治闭环到底在做什么理解了March算法MBIST的硬件结构就很好理解了。它本质上是一个在芯片内部实现的自洽测试闭环一个状态机BIST控制器按照预设的March算法生成地址、数据、读写控制信号把这些信号通过接口逻辑送到存储器周围的测试环绕逻辑Collar上然后对存储器的输出响应进行实时比对。Collar是MBIST架构里容易被忽视但极其关键的组件。它就像存储器外围的一道闸门在功能模式下直接让正常的读写信号通过不干扰任何功能逻辑在测试模式下则把存储器的输入输出全部切换到BIST控制器的通道上。也就是说Collar保证MBIST插入后对功能设计是透明的。整个闭环在测试模式下自主运行不需要外部机台逐位干预只需要给一个启动信号然后等待一个pass/fail的结果。这也是内建自测试这个名字的含义。如果设计还接了BIRA内建冗余分析那么测试失败后还能进一步定位故障的行列判断是否能通过冗余单元替换来实现良率修复。2. Tessent MBIST的模块化架构与项目准备2.1 工具链里有哪些角色Tessent Shell、Controller、CollarTessent MBIST并不是一个孤立的按钮而是一整套工具链里的一个环节。日常打交道最多的几个角色Tessent Shell是统一的操作入口所有设计读入、约束配置、流程执行、报告生成都在这个环境里完成。你可以把当成一个面向DFT的EDA交互环境类似DesignCompiler里的dc_shell。BIST Controller是MBIST的大脑。它内部实现了March算法的状态机负责生成测试序列、控制测试流程、收集比较结果。一个Controller可以同时挂多个存储器这取决于时钟域、测试时间规划等因素。Collar则是每个存储器实例对应的测试环绕逻辑。在插入之后每个存储器周围都有一圈由工具自动生成的测试逻辑功能模式下等同于一根直通导线测试模式下成为BIST Controller与该存储器之间的接口。在实际工程环境中Tessent MBIST通常不会单独存在而是和Tessent Scan/ATPG配合使用。MBIST插入后的网表会作为后续扫描链插入、扫描测试向量生成的输入两部分逻辑共用一套测试接口和时钟复用机制。2.2 开工前需要备齐的输入文件清单刚开始接触Tessent MBIST时很多人第一个动作就是打开工具想直接读RTL结果卡在缺文件、缺约束上。根据项目经验开工前需要准备下面这些输入文件类型格式示例用途说明设计网表或RTLVerilog / VHDL / SystemVerilog被测芯片设计数据存储器行为模型工具可识别的仿真模型定义每个存储器的端口与行为工艺库Liberty文件综合、时序分析和面积评估用设计约束SDC时钟、复位、端口约束物理设计约束PDCTessent专用的测试约束定义测试协议自定义定义扫描链、mbist_mode等接口这里面最容易出问题的是存储器行为模型。Tessent需要识别出设计中每个存储器的类型、尺寸、端口定义才能自动生成配套的Collar逻辑。如果是工艺厂提供的标准SRAM Compiler生成的存储器通常有现成的模型可用但如果是定制存储器、寄存器堆甚至是第三方IP里嵌的存储阵列就需要额外处理这一点后面踩坑部分会细说。2.3 用脚本控制流程版本、库、PDC文件一个都不能少Tessent MBIST的插入过程最好用脚本控制不要依赖图形界面。原因很简单DFT流程需要不断迭代你不可能每次改动一个存储器配置都重新手工点一遍界面。脚本化之后所有配置变更都有版本记录还可以在多个项目间复用。一个典型的Tessent Shell脚本骨架长这样具体命令以你手里的工具版本Release Note为准# 设置工艺库和设计文件 read_cell_library ./lib/xx_ss_0p99v_125c.lib read_design ./netlist/top_after_synth.v # 指定当前设计顶层次 set_current_design top # 指定存储器模型目录 set_app_var MBIST_MODEL_DIR ./memory_models # 配置MBIST插入选项 set_config_mbist -controller_num 2 \ -algorithm March_C- \ -clock mbist_clk \ -reset mbist_rst # 执行插入 run_build_mbist # 输出报告 report_mbist_insert -verbose ./report/mbist_insert.rpt需要注意不同版本的Tessent命令名可能略有差异但逻辑骨架是一致的读入库和设计指定存储器模型配置控制器和算法执行插入生成报告。PDC文件Physical Design Constraints是Tessent流程中特有的关键输入。它用来定义测试模式下的时钟、复位、测试使能信号以及它们之间的时序关系。比如mbist_mode信号和扫描使能scan_enable之间是什么关系、BIST时钟和功能时钟是否同源都要在PDC里说清楚。PDC配置得不完整后面仿真验证和时序分析都会出乱子。3. 从零搭建MBIST插入流程的关键动作3.1 第一步读入设计与存储器模型一切流程从读入设计开始。在Tessent Shell里加载综合后的网表或RTL工具会对整个设计做编译建立起层次结构和信号连接关系。这里有一个经验不要只在最顶层读入设计应该把设计层次保留下来后面配置存储器和查报告时你需要在层次路径里精确地引用某个存储器实例。读入设计之后最关键的动作是让工具识别存储器。Tessent支持从设计网表中自动推断存储器但实际项目中我更推荐半自动方式自己维护一个存储器清单把设计中所有需要做MBIST的存储器实例名、类型、尺寸列出来然后通过脚本命令逐个加到配置里。手动维护清单的好处是可控性强。自动推断偶尔会把一些本不该做MBIST的寄存器堆也识别成存储器或者漏掉一些内部带有特殊逻辑的定制存储阵列。你自己维护清单就能精确控制哪些存储器进MBIST、哪些不进。3.2 第二步定义控制器结构和时钟复位策略控制器结构设计是整个MBIST插入过程中最需要动脑子的部分。需要决定的问题包括使用一个控制器还是多个控制器每个控制器挂载哪些存储器使用什么测试算法Collar的类型怎么选。一个基本的划分原则同一个控制器下尽量挂时钟域一致的存储器。如果一块存储器在CPU时钟域另一块在总线时钟域硬把它们挂到同一个BIST控制器上要么需要额外的跨时钟同步逻辑要么就得让BIST运行频率迁就慢的一方测试时间不划算。复位策略同样关键。MBIST控制器通常使用异步复位但需要注意复位释放的时序。真实项目中mbist_rst信号往往由芯片的测试复位树控制和扫描链复位共享。要确保进入BIST测试模式时控制器已经退出复位而存储器本身处于已知状态否则仿真时会成群的不定态X态出现。3.3 第三步执行插入并检查报告配置完成后运行插入流程。工具会自动完成几件事生成BIST控制器的RTL或网表、为每个存储器实例插入Collar逻辑、把控制器和Collar连接起来、插入必要的测试模式切换逻辑、输出更新后的网表和仿真模型。插入完成后不要急着往下走仔细检查报告这个习惯非常必要。关注这几类信息面积报告MBIST逻辑总共增加了多少等效逻辑门。正常情况下BIST控制器几千到几万门每个Collar几百到几千门相对一颗大SoC来说占比很小。如果发现面积增加异常往往是某个存储器的Collar配置出了问题比如误给小型寄存器堆也加上了全套诊断逻辑。DRC报告Tessent会检查时钟、复位、测试模式信号是否存在冲突。常见的报错包括存储器的某个测试端口没有正确连接、控制器的复位信号与设计内部复位网络冲突、mbist_mode信号在某个层次没有打通等。这些DRC问题必须在仿真之前解决掉否则后面追查起来非常痛苦。存储器覆盖报告确认设计中需要测的存储器是否全部被纳入有没有遗漏。3.4 第四步仿真验证与ATPG pattern衔接插入完成只是第一步真正的验证工作才刚刚开始。Tessent MBIST会生成一套验证环境包括测试逻辑的testbench、激励文件、以及一份预期结果文件。在你的仿真工具比如Questa或VCS里跑一遍看BIST测试是否完整跑完并给出了Pass的结果。这一步要重点关注几个问题测试模式切换是否正确、算法序列是否完整执行、时钟和复位信号在仿真中是否干净没有X态传播。如果仿真挂了优先回看信号波形而不是瞎猜。好的做法是把BIST控制器的状态机信号、存储器的读数据、比较器的输出全部拉出来看定位到具体是哪个地址、哪个操作出的问题。仿真通过之后才轮到pattern生成环节。Tessent会把BIST测试转化为ATE可执行的测试pattern常见格式有WGL、STIL、TSTP2等。这些pattern会和扫描链测试pattern合并到一个最终的测试程序中在芯片量产测试时直接运行。4. 从RTL到流片测试时间、面积与功耗的平衡术4.1 多存储器共享BIST控制器怎么划组真实SoC里存储器动辄几十上百个不可能每个存储器配一个控制器那样面积和功耗都不可接受。Tessent MBIST支持多个存储器共享同一个控制器测试时可以串行或并行地驱动多个Collar。划组时我一般按这个顺序考虑时钟域是否一致尽量同域归同组位宽相近的存储器归同组Collar实现更简洁测试时间能否接受一个组串行测完需要多长时间诊断需求哪些存储器需要精确到bit的失败定位这四者往往不能同时满足需要根据项目实际情况排序。消费类产品对测试时间敏感可以多挂几个存储器并行跑车规产品更看重诊断能力宁可测试时间长一些。4.2 测试时间估算与优化空间测试时间是MBIST方案设计时绕不开的硬指标。一条简单的估算公式测试时间 March操作数 × 地址数 ÷ 测试频率 启动与切换开销举例说明一块256K×8的SRAM地址数N是262144。用March C-算法复杂度10N那么总共约262万个操作。如果BIST测试时钟跑到100MHz理论上核心测试时间约26毫秒。看起来毫秒级别并不慢但如果一颗芯片里有几十块这样的存储器而且多块存储器被串行测试累计起来就是几百毫秒。在ATE测试中这个时间会直接影响单颗芯片的测试成本。优化手段通常是这么几个方向提高BIST时钟频率、采用并行测试让多个存储器同时跑、选择复杂度更低的算法、或者把存储阵列拆分成多个bank并行测试。每一步都是在测试覆盖率和测试成本之间做取舍。4.3 报告里的覆盖率到底看什么很多新手拿到MBIST覆盖率报告会直接看那个百分比这个习惯需要修正。MBIST报告里常见的数字有成百上千个故障类型而你要关注的是这些故障是否在测试中被检测到。这里还有一个重要区别故障覆盖率Fault Coverage和测试覆盖率Test Coverage不是同一个概念。测试覆盖率是指通过某一算法能测试到的故障点占所有故障点的比例而故障覆盖率要考虑实际仿真中你要求的检测方式是否真的能把故障暴露出来。March C-在一个标准SRAM上能提供相当高的覆盖率但如果你使用的存储器有特殊的masked write行为而存储器的测试模型没有正确建模这个行为最终测出来的覆盖率和理论值会差很远。看覆盖率报告的正确姿势是先确认模型对、算法对再看百分比。反过来先看百分比很容易被表面的数字带偏。5. 实战中容易翻车的五个细节5.1 异步时钟域处理不当导致仿真挂死这是我在实际项目里遇到的第一类大坑。某块存储器挂在异步FIFO接口上它的读写时钟来自不同时钟域。我一开始按照单时钟域的简单思路配置控制器结果BIST仿真跑到一半就出现数据比对失败追查波形发现控制器的写入和读出跨越了两个不同的时钟域导致数据采样的时序完全失控。解决思路是把BIST控制器的时钟和被测存储器的时钟统一到一个测试时钟域并且在PDC里明确这个测试时钟与功能时钟的复用关系。遇到真正无法同步的情况需要在Tessent里配置异步跨时钟处理的选项让工具在生成逻辑时自动插入同步器。这个坑的教训是配置控制器之前先把设计中存储器的时钟结构彻底梳理清楚。5.2 存储器模型缺失时的应急方案Tessent官方提供了一批常见存储器模型但遇到项目里的定制存储器或者第三方IP内嵌存储阵列工具可能识别不出来。这种情况在SoC项目中经常出现尤其是一些老牌IP供应商的模块。如果识别不出来插入流程直接报错或者生成错误的Collar逻辑。一个快速反应的方案是查看Tessent内部的存储器模型格式按照存储器数据手册的端口定义手工编写一份行为模型把读操作、写操作、片选、掩码行为都描述清楚。这项工作本身不算难但一定要仔细——模型里写错一个掩码行为仿真验证阶段会折腾你好几天。如果时间实在来不及还有一个治标方案先用一个行为等效的、Tessent能识别的通用存储器模型替换先让流程跑通然后尽快补上真实的存储器模型重新迭代。5.3 MBIST与扫描测试的协同复位策略当BIST控制器、扫描链、存储器的复位网络交织在一起时复位策略的设计需要格外小心。常见的问题是BIST运行过程中其他逻辑的复位信号在不知不觉间被触发导致控制器状态被强制清零。我处理过的一个案例是MBIST本身跑得好好的但一旦芯片进入一个特殊的低功耗唤醒流程测试复位信号被误拉低BIST控制器立刻复位。这种问题在纯仿真环境里很难发现必须在综合、插入scan和ATP之后做全流程验证才能暴露。一个实用的做法是在测试模式逻辑里明确约束复位信号的优先级。测试模式下BIST运行期间任何非测试相关的复位不允许被激活扫描测试模式下BIST控制器要处于复位释放状态避免扫描链上的信号串扰影响测试结果。5.4 低功耗设计下isolated memory的测试问题现在的大SoC基本都会做多电压域和电源关断设计。如果某块存储器位于可关断的电压域上而MBIST控制器在常开域那么当电源域关断时存储器根本无法工作。测试工程师拿到这种设计时需要特别留意power gating的影响。常规做法是在设计阶段就约定一个测试模式全局控制信号强制所有电压域的隔离单元和状态保持单元在测试模式下不生效让所有存储器始终处于power-on状态。如果这个事没处理好后果是灾难性的某些存储器在ATE测试时读出来的全是垃圾数据你以为算法有问题查了大半天最后发现是隔离单元把存储器的输入给堵死了。5.5 诊断精度忽高忽低的原因产品需要返修分析时MBIST的诊断能力就派上用场了。Tessent支持把BIST运行过程中的失败数据回读出来定位到具体某一行的某一位。但诊断精度在不同的芯片上会出现忽高忽低的情况。排查下来最常见的原因是仿真和真机上的失败数据回读链路不一致。BIST测试过程中记录的失败信息往往存储在控制器内部的寄存器组里测试结束后通过扫描链或JTAG接口逐位移出来。如果回读过程中某些寄存器的值已经被后续的测试操作覆盖或者扫描链配置和仿真时不一致诊断数据就会丢位。另一个容易忽略的点是诊断时钟的选择。失败数据回读时如果用了和BIST测试不同的时钟域也会造成数据采样错误。做诊断模式验证时一定要把回读阶段的时钟、复位、扫描链配置全部体现了PDC里并且通过专门的仿真用例验证每一个回读步骤。写在最后的一点体会做MBIST流程这些年我最大的感受是这个工作真正难的部分不是工具命令怎么敲而是对整个芯片的可测性架构有通盘考虑。工具只是把你的意图实现出来但意图本身需要你想清楚哪些存储器必须测、测试时间能容忍多少、诊断能力要到什么粒度、和扫描链怎么协同、低功耗设计怎么配合。这些决定了你的MBIST方案能不能在量产中真正起作用。如果你正在项目里起步做Tessent MBIST我的建议是第一版流程不要追求完美的覆盖率先跑通整个环节确认存储器的识别、插入、仿真、pattern生成每一步都正常再逐步优化划分和算法。等到经验积累够了经过一两个项目之后这些权衡就会变成你下意识就能做出的判断。
第一次在量产测试方案里正式落地Tessent MBIST时我还在做一颗带16块SRAM的SoC。当时最深的感受是可测试性设计DFT做得不到位到了ATE测试台上会成倍地还回来。MBISTMemory Built-In Self-Test存储器内建自测试就是解决存储阵列测试问题最核心的手段而Tessent MBIST是行业内落地这一方案的主流工具。这篇文章不打算做工具手册搬运我会从原理、工程准备、插入流程、测试时间权衡一直到踩坑细节完整梳理一遍从零搭建Tessent MBIST流程的思路。适合的读者正在学DFT的在校学生、刚接手DFT工作的数字IC工程师、以及想在项目里引入MBIST但不知道从哪下手的团队。看完你能掌握整套流程的骨架也知道每个环节为什么要这么做。1. 为什么存储器测试绕不开MBIST这一关1.1 存储阵列的测试困境扫描链为什么覆盖不到芯片里的存储单元和标准逻辑单元有本质区别。标准逻辑可以通过扫描链把DFF串成移位寄存器测试时把激励灌进去、把响应移出来。但到了SRAM这种高密度阵列事情就变了一颗大SRAM里面有几十万甚至上百万个bit cell每个bit cell本质上都是一个独立的状态保持节点。想用扫描链去覆盖这些bit cell理论上当然可以给每个存储单元加扫描访问通路但代价极其恐怖——面积翻倍、功耗暴涨、时序恶化没有任何量产芯片能接受这种开销。这就是为什么行业里几乎没人用纯scan方式测大容量存储器。另一个常见误区是把存储器测试完全丢给ATE外部向量。问题是存储器的测试需要高频率、连续不断的读写序列外部测试机台要提供这么大量的数据成本高、速度慢而且引脚带宽根本不够。面对高速高密度存储阵列唯一可行的方案是把测试逻辑搬进芯片内部也就是MBIST。1.2 March测试算法存储器测试的标准答案MBIST并不是简单地往存储器里写一组数据再读出来比对。行业里经过几十年沉淀形成了一整套标准化的存储器测试算法统称为March算法。March算法的核心思想是按照特定顺序对存储器中的每个地址执行一组有限的操作序列包括写0、写1、读0、读1并配合地址递增或递减。每个操作序列称为一个March元素整个算法就是这些元素的组合。举一个最经典的例子March C-算法。它一共有10个March元素复杂度是10NN是存储器的地址数。它能够覆盖绝大部分固定故障SAF、转换故障TF、地址译码故障AF和耦合故障CF。这也是Tessent MBIST中默认算法最常见的选项之一。不同的March算法在故障覆盖率和测试时间上各有取舍算法复杂度主要覆盖故障类型适用场景March C-10NSAF、TF、AF、大部分CF最常用的默认选择March SS22N在C-基础上增强CF覆盖高可靠性场景March LR14N动态故障、读干扰故障深亚微米工艺下常见March 13N13N某些特定耦合故障自定义补充测试选择哪种算法本质上是覆盖率、测试时间和硬件复杂度三者之间的权衡。Tessent MBIST允许你对不同的存储器实例单独指定算法这在实际项目中非常实用——对可靠性要求高的车规芯片用更强算法对消费类芯片则用更经济的方案。1.3 MBIST的硬件自治闭环到底在做什么理解了March算法MBIST的硬件结构就很好理解了。它本质上是一个在芯片内部实现的自洽测试闭环一个状态机BIST控制器按照预设的March算法生成地址、数据、读写控制信号把这些信号通过接口逻辑送到存储器周围的测试环绕逻辑Collar上然后对存储器的输出响应进行实时比对。Collar是MBIST架构里容易被忽视但极其关键的组件。它就像存储器外围的一道闸门在功能模式下直接让正常的读写信号通过不干扰任何功能逻辑在测试模式下则把存储器的输入输出全部切换到BIST控制器的通道上。也就是说Collar保证MBIST插入后对功能设计是透明的。整个闭环在测试模式下自主运行不需要外部机台逐位干预只需要给一个启动信号然后等待一个pass/fail的结果。这也是内建自测试这个名字的含义。如果设计还接了BIRA内建冗余分析那么测试失败后还能进一步定位故障的行列判断是否能通过冗余单元替换来实现良率修复。2. Tessent MBIST的模块化架构与项目准备2.1 工具链里有哪些角色Tessent Shell、Controller、CollarTessent MBIST并不是一个孤立的按钮而是一整套工具链里的一个环节。日常打交道最多的几个角色Tessent Shell是统一的操作入口所有设计读入、约束配置、流程执行、报告生成都在这个环境里完成。你可以把当成一个面向DFT的EDA交互环境类似DesignCompiler里的dc_shell。BIST Controller是MBIST的大脑。它内部实现了March算法的状态机负责生成测试序列、控制测试流程、收集比较结果。一个Controller可以同时挂多个存储器这取决于时钟域、测试时间规划等因素。Collar则是每个存储器实例对应的测试环绕逻辑。在插入之后每个存储器周围都有一圈由工具自动生成的测试逻辑功能模式下等同于一根直通导线测试模式下成为BIST Controller与该存储器之间的接口。在实际工程环境中Tessent MBIST通常不会单独存在而是和Tessent Scan/ATPG配合使用。MBIST插入后的网表会作为后续扫描链插入、扫描测试向量生成的输入两部分逻辑共用一套测试接口和时钟复用机制。2.2 开工前需要备齐的输入文件清单刚开始接触Tessent MBIST时很多人第一个动作就是打开工具想直接读RTL结果卡在缺文件、缺约束上。根据项目经验开工前需要准备下面这些输入文件类型格式示例用途说明设计网表或RTLVerilog / VHDL / SystemVerilog被测芯片设计数据存储器行为模型工具可识别的仿真模型定义每个存储器的端口与行为工艺库Liberty文件综合、时序分析和面积评估用设计约束SDC时钟、复位、端口约束物理设计约束PDCTessent专用的测试约束定义测试协议自定义定义扫描链、mbist_mode等接口这里面最容易出问题的是存储器行为模型。Tessent需要识别出设计中每个存储器的类型、尺寸、端口定义才能自动生成配套的Collar逻辑。如果是工艺厂提供的标准SRAM Compiler生成的存储器通常有现成的模型可用但如果是定制存储器、寄存器堆甚至是第三方IP里嵌的存储阵列就需要额外处理这一点后面踩坑部分会细说。2.3 用脚本控制流程版本、库、PDC文件一个都不能少Tessent MBIST的插入过程最好用脚本控制不要依赖图形界面。原因很简单DFT流程需要不断迭代你不可能每次改动一个存储器配置都重新手工点一遍界面。脚本化之后所有配置变更都有版本记录还可以在多个项目间复用。一个典型的Tessent Shell脚本骨架长这样具体命令以你手里的工具版本Release Note为准# 设置工艺库和设计文件 read_cell_library ./lib/xx_ss_0p99v_125c.lib read_design ./netlist/top_after_synth.v # 指定当前设计顶层次 set_current_design top # 指定存储器模型目录 set_app_var MBIST_MODEL_DIR ./memory_models # 配置MBIST插入选项 set_config_mbist -controller_num 2 \ -algorithm March_C- \ -clock mbist_clk \ -reset mbist_rst # 执行插入 run_build_mbist # 输出报告 report_mbist_insert -verbose ./report/mbist_insert.rpt需要注意不同版本的Tessent命令名可能略有差异但逻辑骨架是一致的读入库和设计指定存储器模型配置控制器和算法执行插入生成报告。PDC文件Physical Design Constraints是Tessent流程中特有的关键输入。它用来定义测试模式下的时钟、复位、测试使能信号以及它们之间的时序关系。比如mbist_mode信号和扫描使能scan_enable之间是什么关系、BIST时钟和功能时钟是否同源都要在PDC里说清楚。PDC配置得不完整后面仿真验证和时序分析都会出乱子。3. 从零搭建MBIST插入流程的关键动作3.1 第一步读入设计与存储器模型一切流程从读入设计开始。在Tessent Shell里加载综合后的网表或RTL工具会对整个设计做编译建立起层次结构和信号连接关系。这里有一个经验不要只在最顶层读入设计应该把设计层次保留下来后面配置存储器和查报告时你需要在层次路径里精确地引用某个存储器实例。读入设计之后最关键的动作是让工具识别存储器。Tessent支持从设计网表中自动推断存储器但实际项目中我更推荐半自动方式自己维护一个存储器清单把设计中所有需要做MBIST的存储器实例名、类型、尺寸列出来然后通过脚本命令逐个加到配置里。手动维护清单的好处是可控性强。自动推断偶尔会把一些本不该做MBIST的寄存器堆也识别成存储器或者漏掉一些内部带有特殊逻辑的定制存储阵列。你自己维护清单就能精确控制哪些存储器进MBIST、哪些不进。3.2 第二步定义控制器结构和时钟复位策略控制器结构设计是整个MBIST插入过程中最需要动脑子的部分。需要决定的问题包括使用一个控制器还是多个控制器每个控制器挂载哪些存储器使用什么测试算法Collar的类型怎么选。一个基本的划分原则同一个控制器下尽量挂时钟域一致的存储器。如果一块存储器在CPU时钟域另一块在总线时钟域硬把它们挂到同一个BIST控制器上要么需要额外的跨时钟同步逻辑要么就得让BIST运行频率迁就慢的一方测试时间不划算。复位策略同样关键。MBIST控制器通常使用异步复位但需要注意复位释放的时序。真实项目中mbist_rst信号往往由芯片的测试复位树控制和扫描链复位共享。要确保进入BIST测试模式时控制器已经退出复位而存储器本身处于已知状态否则仿真时会成群的不定态X态出现。3.3 第三步执行插入并检查报告配置完成后运行插入流程。工具会自动完成几件事生成BIST控制器的RTL或网表、为每个存储器实例插入Collar逻辑、把控制器和Collar连接起来、插入必要的测试模式切换逻辑、输出更新后的网表和仿真模型。插入完成后不要急着往下走仔细检查报告这个习惯非常必要。关注这几类信息面积报告MBIST逻辑总共增加了多少等效逻辑门。正常情况下BIST控制器几千到几万门每个Collar几百到几千门相对一颗大SoC来说占比很小。如果发现面积增加异常往往是某个存储器的Collar配置出了问题比如误给小型寄存器堆也加上了全套诊断逻辑。DRC报告Tessent会检查时钟、复位、测试模式信号是否存在冲突。常见的报错包括存储器的某个测试端口没有正确连接、控制器的复位信号与设计内部复位网络冲突、mbist_mode信号在某个层次没有打通等。这些DRC问题必须在仿真之前解决掉否则后面追查起来非常痛苦。存储器覆盖报告确认设计中需要测的存储器是否全部被纳入有没有遗漏。3.4 第四步仿真验证与ATPG pattern衔接插入完成只是第一步真正的验证工作才刚刚开始。Tessent MBIST会生成一套验证环境包括测试逻辑的testbench、激励文件、以及一份预期结果文件。在你的仿真工具比如Questa或VCS里跑一遍看BIST测试是否完整跑完并给出了Pass的结果。这一步要重点关注几个问题测试模式切换是否正确、算法序列是否完整执行、时钟和复位信号在仿真中是否干净没有X态传播。如果仿真挂了优先回看信号波形而不是瞎猜。好的做法是把BIST控制器的状态机信号、存储器的读数据、比较器的输出全部拉出来看定位到具体是哪个地址、哪个操作出的问题。仿真通过之后才轮到pattern生成环节。Tessent会把BIST测试转化为ATE可执行的测试pattern常见格式有WGL、STIL、TSTP2等。这些pattern会和扫描链测试pattern合并到一个最终的测试程序中在芯片量产测试时直接运行。4. 从RTL到流片测试时间、面积与功耗的平衡术4.1 多存储器共享BIST控制器怎么划组真实SoC里存储器动辄几十上百个不可能每个存储器配一个控制器那样面积和功耗都不可接受。Tessent MBIST支持多个存储器共享同一个控制器测试时可以串行或并行地驱动多个Collar。划组时我一般按这个顺序考虑时钟域是否一致尽量同域归同组位宽相近的存储器归同组Collar实现更简洁测试时间能否接受一个组串行测完需要多长时间诊断需求哪些存储器需要精确到bit的失败定位这四者往往不能同时满足需要根据项目实际情况排序。消费类产品对测试时间敏感可以多挂几个存储器并行跑车规产品更看重诊断能力宁可测试时间长一些。4.2 测试时间估算与优化空间测试时间是MBIST方案设计时绕不开的硬指标。一条简单的估算公式测试时间 March操作数 × 地址数 ÷ 测试频率 启动与切换开销举例说明一块256K×8的SRAM地址数N是262144。用March C-算法复杂度10N那么总共约262万个操作。如果BIST测试时钟跑到100MHz理论上核心测试时间约26毫秒。看起来毫秒级别并不慢但如果一颗芯片里有几十块这样的存储器而且多块存储器被串行测试累计起来就是几百毫秒。在ATE测试中这个时间会直接影响单颗芯片的测试成本。优化手段通常是这么几个方向提高BIST时钟频率、采用并行测试让多个存储器同时跑、选择复杂度更低的算法、或者把存储阵列拆分成多个bank并行测试。每一步都是在测试覆盖率和测试成本之间做取舍。4.3 报告里的覆盖率到底看什么很多新手拿到MBIST覆盖率报告会直接看那个百分比这个习惯需要修正。MBIST报告里常见的数字有成百上千个故障类型而你要关注的是这些故障是否在测试中被检测到。这里还有一个重要区别故障覆盖率Fault Coverage和测试覆盖率Test Coverage不是同一个概念。测试覆盖率是指通过某一算法能测试到的故障点占所有故障点的比例而故障覆盖率要考虑实际仿真中你要求的检测方式是否真的能把故障暴露出来。March C-在一个标准SRAM上能提供相当高的覆盖率但如果你使用的存储器有特殊的masked write行为而存储器的测试模型没有正确建模这个行为最终测出来的覆盖率和理论值会差很远。看覆盖率报告的正确姿势是先确认模型对、算法对再看百分比。反过来先看百分比很容易被表面的数字带偏。5. 实战中容易翻车的五个细节5.1 异步时钟域处理不当导致仿真挂死这是我在实际项目里遇到的第一类大坑。某块存储器挂在异步FIFO接口上它的读写时钟来自不同时钟域。我一开始按照单时钟域的简单思路配置控制器结果BIST仿真跑到一半就出现数据比对失败追查波形发现控制器的写入和读出跨越了两个不同的时钟域导致数据采样的时序完全失控。解决思路是把BIST控制器的时钟和被测存储器的时钟统一到一个测试时钟域并且在PDC里明确这个测试时钟与功能时钟的复用关系。遇到真正无法同步的情况需要在Tessent里配置异步跨时钟处理的选项让工具在生成逻辑时自动插入同步器。这个坑的教训是配置控制器之前先把设计中存储器的时钟结构彻底梳理清楚。5.2 存储器模型缺失时的应急方案Tessent官方提供了一批常见存储器模型但遇到项目里的定制存储器或者第三方IP内嵌存储阵列工具可能识别不出来。这种情况在SoC项目中经常出现尤其是一些老牌IP供应商的模块。如果识别不出来插入流程直接报错或者生成错误的Collar逻辑。一个快速反应的方案是查看Tessent内部的存储器模型格式按照存储器数据手册的端口定义手工编写一份行为模型把读操作、写操作、片选、掩码行为都描述清楚。这项工作本身不算难但一定要仔细——模型里写错一个掩码行为仿真验证阶段会折腾你好几天。如果时间实在来不及还有一个治标方案先用一个行为等效的、Tessent能识别的通用存储器模型替换先让流程跑通然后尽快补上真实的存储器模型重新迭代。5.3 MBIST与扫描测试的协同复位策略当BIST控制器、扫描链、存储器的复位网络交织在一起时复位策略的设计需要格外小心。常见的问题是BIST运行过程中其他逻辑的复位信号在不知不觉间被触发导致控制器状态被强制清零。我处理过的一个案例是MBIST本身跑得好好的但一旦芯片进入一个特殊的低功耗唤醒流程测试复位信号被误拉低BIST控制器立刻复位。这种问题在纯仿真环境里很难发现必须在综合、插入scan和ATP之后做全流程验证才能暴露。一个实用的做法是在测试模式逻辑里明确约束复位信号的优先级。测试模式下BIST运行期间任何非测试相关的复位不允许被激活扫描测试模式下BIST控制器要处于复位释放状态避免扫描链上的信号串扰影响测试结果。5.4 低功耗设计下isolated memory的测试问题现在的大SoC基本都会做多电压域和电源关断设计。如果某块存储器位于可关断的电压域上而MBIST控制器在常开域那么当电源域关断时存储器根本无法工作。测试工程师拿到这种设计时需要特别留意power gating的影响。常规做法是在设计阶段就约定一个测试模式全局控制信号强制所有电压域的隔离单元和状态保持单元在测试模式下不生效让所有存储器始终处于power-on状态。如果这个事没处理好后果是灾难性的某些存储器在ATE测试时读出来的全是垃圾数据你以为算法有问题查了大半天最后发现是隔离单元把存储器的输入给堵死了。5.5 诊断精度忽高忽低的原因产品需要返修分析时MBIST的诊断能力就派上用场了。Tessent支持把BIST运行过程中的失败数据回读出来定位到具体某一行的某一位。但诊断精度在不同的芯片上会出现忽高忽低的情况。排查下来最常见的原因是仿真和真机上的失败数据回读链路不一致。BIST测试过程中记录的失败信息往往存储在控制器内部的寄存器组里测试结束后通过扫描链或JTAG接口逐位移出来。如果回读过程中某些寄存器的值已经被后续的测试操作覆盖或者扫描链配置和仿真时不一致诊断数据就会丢位。另一个容易忽略的点是诊断时钟的选择。失败数据回读时如果用了和BIST测试不同的时钟域也会造成数据采样错误。做诊断模式验证时一定要把回读阶段的时钟、复位、扫描链配置全部体现了PDC里并且通过专门的仿真用例验证每一个回读步骤。写在最后的一点体会做MBIST流程这些年我最大的感受是这个工作真正难的部分不是工具命令怎么敲而是对整个芯片的可测性架构有通盘考虑。工具只是把你的意图实现出来但意图本身需要你想清楚哪些存储器必须测、测试时间能容忍多少、诊断能力要到什么粒度、和扫描链怎么协同、低功耗设计怎么配合。这些决定了你的MBIST方案能不能在量产中真正起作用。如果你正在项目里起步做Tessent MBIST我的建议是第一版流程不要追求完美的覆盖率先跑通整个环节确认存储器的识别、插入、仿真、pattern生成每一步都正常再逐步优化划分和算法。等到经验积累够了经过一两个项目之后这些权衡就会变成你下意识就能做出的判断。
