ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Tessent MBIST实战:从环境搭建到仿真验证的完整流程

Tessent MBIST实战:从环境搭建到仿真验证的完整流程 1. 为什么内存测试绕不开MBIST这套流程做DFT这行的朋友大多有过类似的经历芯片流片回来CPU能跑、外设能通偏偏在跑内存压力测试的时候随机挂掉定位半天发现是某颗SRAM的某个bit在特定时序下翻转不稳定。这种问题如果靠功能测试去覆盖基本等于大海捞针——你没法用软件的方式穷举所有内存地址和所有读写组合。所以行业里早就形成共识内存的测试必须走**MBISTMemory Built-In Self-Test**这条路把测试逻辑直接做进芯片里用硬件自己测自己。Tessent是西门子原Mentor旗下的DFT工具链在MBIST这块算是业界用得最广的方案之一。它的核心思路是你提供内存的模型和测试需求工具自动帮你插入BIST控制器、生成测试算法、连好总线最后产出一套可以仿真验证的电路。听起来很自动化但真正上手的时候你会发现从零搭一套能跑通的环境中间要填的坑比想象中多得多。这篇内容面向的是刚接触Tessent MBIST的DFT工程师或者已经会用工具但想系统梳理一遍流程的同行。我会从环境准备开始一步步走完内存模型导入、控制器配置、算法选择、总线连接、仿真验证这条完整链路重点讲清楚每一步为什么这么做、参数怎么算、哪里容易翻车。脚本层面我会给出可直接参考的Tcl模板你拿去改改就能用。提示本文假设你已经具备基本的DFT概念扫描链、ATPG、测试覆盖率这些如果完全没有基础建议先补一下数字电路测试的基本原理否则后面很多决策你会看不懂背后的逻辑。2. 搭建环境前必须想清楚的几件事2.1 Tessent的目录结构和文件组织逻辑很多人拿到Tessent之后第一反应是直接敲命令结果跑出来的东西散落在各个目录里过两天自己都找不到。我建议在动手之前先把目录规划好这不是强迫症是后面调试和复现的基础。我通常的目录结构是这样的project/ ├── rtl/ # 设计RTL源码 ├── libs/ # 工艺库、内存库文件 ├── tessent/ # Tessent工作目录 │ ├── scripts/ # Tcl脚本 │ ├── models/ # 内存模型文件 │ ├── reports/ # 工具输出报告 │ ├── patterns/ # 生成的测试向量 │ └── work/ # 工具运行时的中间文件 └── sim/ # 仿真环境这个结构的关键在于把输入RTL、库、模型和输出报告、向量严格分开。Tessent在运行过程中会在当前工作目录下生成大量中间文件如果你不单独开一个work目录这些文件会跟你的脚本混在一起清理的时候很容易误删。2.2 内存模型从哪来格式怎么选MBIST的核心输入之一是内存模型。Tessent需要知道每一颗内存的地址位宽、数据位宽、深度、读写时序、物理布局这些信息才能生成正确的测试逻辑。内存模型通常有三个来源Foundry提供的.lib或.db文件这是最理想的情况但很多情况下Foundry只给功能模型不给DFT需要的详细时序信息。Memory Compiler生成的模型如果你用的是ARM、Synopsys这些厂商的Memory Compiler它们一般会同时输出功能模型和DFT模型。手写模型实在没有现成的就得自己根据datasheet写。这是最费时但也最能锻炼人的方式。Tessent支持的内存模型格式主要有两种TCD格式Tessent Core Description和Verilog行为模型。TCD是Tessent自己的格式描述能力强支持复杂的物理布局信息Verilog模型更通用但需要额外指定一些参数。我的建议是如果Foundry给了TCD模型直接用如果没有优先考虑用Memory Compiler输出的Verilog模型配合Tessent的add_memory命令来导入。手写TCD模型是最后的选择因为格式要求严格一个字段写错工具就报错调试成本很高。2.3 工艺库的准备和常见坑工艺库这块Tessent需要的是标准单元库的.db或.lib文件用来做综合和时序分析。这里有个容易忽略的点MBIST控制器本身也是用标准单元搭出来的所以你的库文件必须包含工具需要的所有单元类型特别是多路选择器、触发器、时钟门控单元这些。我踩过的一个坑是库文件里缺少某种特定驱动能力的buffer工具在插入BIST逻辑的时候找不到合适的单元直接报错退出。解决办法是在跑Tessent之前先用check_library命令检查一遍库的完整性缺什么补什么。另外如果你的设计里有多时钟域库文件还需要包含时钟域交叉CDC相关的单元否则BIST控制器在跨时钟域的时候会出问题。3. 从零写一个能跑的MBIST脚本3.1 脚本骨架set_context和读入设计Tessent的脚本本质上就是Tcl但它的命令集是专门为DFT设计的。一个标准的MBIST脚本开头一定是设置上下文和读入设计。# 设置工作模式和日志 set_context dft -mbist set_log_file tessent/reports/mbist_run.log -replace # 读入工艺库 read_cell_library libs/tsmc28_stdcell.db # 读入设计RTL read_verilog rtl/top.v read_verilog rtl/memory_wrapper.v # 设置顶层模块 set_current_design top这里set_context dft -mbist是关键它告诉Tessent接下来要做的是MBIST相关的操作工具会加载对应的命令集和检查规则。如果你忘了设这个后面很多命令根本识别不了。read_cell_library读入的库文件格式取决于你用的工艺.db是Synopsys的二进制格式.lib是文本格式。Tessent两种都支持但.db读取速度更快推荐优先用.db。3.2 内存模型的导入和验证读入设计之后下一步是把内存模型告诉Tessent。有两种方式方式一自动推断# 让工具自动从RTL中推断内存实例 set_dft_signal -view existing_dft -type ScanClock -port clk -timing {45 55} add_memory -autoadd_memory -auto会让Tessent扫描设计中的所有存储器实例尝试自动推断它们的类型和参数。这种方式适合内存类型比较标准的情况但如果你的内存有特殊时序或者非标准接口自动推断大概率会出错。方式二手动指定# 手动指定每一颗内存的模型文件 add_memory -model tessent/models/sram_1024x32.tcd -instance u_sram_0 add_memory -model tessent/models/sram_512x64.tcd -instance u_sram_1手动指定更可靠但前提是你得有每颗内存的模型文件。实际操作中我通常先用-auto跑一遍看看工具能识别出多少颗内存然后对照设计文档检查有没有遗漏或识别错误的再手动补上。导入完成后一定要用report_memory命令检查一遍report_memory -all tessent/reports/memory_list.rpt这个报告会列出所有已识别的内存包括它们的地址位宽、数据位宽、深度、类型。你拿这个报告跟设计文档对一遍确认没有遗漏。3.3 BIST控制器的配置共享还是独立这是MBIST流程中最重要的决策之一多颗内存是共享一个BIST控制器还是每颗内存独立一个控制器共享控制器的好处是面积小、功耗低因为多个内存可以复用同一套测试逻辑。坏处是测试时间长因为内存只能串行测试。独立控制器则相反面积大但测试快。Tessent里通过set_dft_configuration来控制# 配置共享BIST控制器 set_dft_configuration -mbist_shared_controller on set_dft_configuration -mbist_max_shared_memories 4 # 或者配置独立控制器 set_dft_configuration -mbist_shared_controller off-mbist_max_shared_memories指定一个控制器最多管几颗内存。这个数字不是随便定的要考虑两个因素测试时间预算和控制器面积开销。假设你有16颗内存每颗测试需要1000个时钟周期。如果每颗独立控制器总测试时间就是1000周期所有内存并行测如果4颗共享一个控制器总时间就是4000周期。你需要根据芯片的测试时间要求来权衡。我的经验值是内存数量少于8颗时优先考虑独立控制器超过8颗时按4颗一组共享。当然这不是绝对的具体要看你的面积预算和测试时间要求。3.4 测试算法的选择逻辑MBIST的核心是测试算法。不同的故障模型需要不同的算法来覆盖。Tessent内置了多种标准算法算法名称覆盖故障类型测试长度适用场景March C-固定故障、跳变故障10N通用场景最常用March SS固定故障、跳变故障、耦合故障22N高覆盖率需求Checkerboard固定故障、相邻单元短路4N快速筛查GALPAT固定故障、耦合故障4N²小容量内存Walking 1/0固定故障、地址解码故障2N地址线测试N是内存的深度。March C-的10N意味着测试一颗1024深度的内存需要10240个时钟周期。选择算法的时候不能只看覆盖率还要看测试时间。GALPAT覆盖率很高但4N²的复杂度意味着1024深度的内存需要400万周期实际项目中根本不可接受。我的建议是默认用March C-如果覆盖率不够再加March SS小容量内存深度小于256可以考虑GALPAT。在Tessent里指定算法# 为所有内存设置默认算法 set_mbist_algorithm -default march_c_minus # 为特定内存设置不同算法 set_mbist_algorithm -instance u_sram_0 -algorithm march_ss3.5 总线连接和管脚分配BIST控制器需要跟外部测试设备通信这就涉及到管脚分配。Tessent提供了自动分配和手动指定两种方式。自动分配# 自动分配BIST接口管脚 set_dft_signal -view spec -type TestMode -port test_mode set_dft_signal -view spec -type ScanEnable -port scan_en set_dft_signal -view spec -type ScanClock -port clk -timing {45 55} # 自动创建BIST接口 create_dft_specification手动指定# 手动指定BIST接口信号 set_dft_signal -view spec -type MbistEn -port mbist_en set_dft_signal -view spec -type MbistClk -port mbist_clk set_dft_signal -view spec -type MbistReset -port mbist_rst_n自动分配省事但有时候工具分配的管脚跟你的封装管脚冲突。手动指定更可控但需要你对芯片的管脚规划有清晰的了解。这里有个经验BIST接口信号尽量复用功能管脚不要单独占管脚。因为测试模式只在芯片出厂测试时用平时用不到单独占管脚是浪费。Tessent支持管脚复用通过set_dft_signal的-view existing_dft选项来指定复用关系。4. 跑通流程之后必须做的验证4.1 插入BIST逻辑并检查报告配置完成后执行插入# 执行MBIST插入 insert_test_logic # 生成报告 report_dft_signal -view spec tessent/reports/dft_signals.rpt report_mbist_controller tessent/reports/mbist_controllers.rpt report_test_logic tessent/reports/test_logic.rptinsert_test_logic是核心命令它会根据你前面的配置在设计中插入BIST控制器、连接内存、分配管脚。跑完之后必须仔细看三个报告dft_signals.rpt检查所有BIST接口信号是否都正确分配了管脚。mbist_controllers.rpt检查控制器的数量、每个控制器管理的内存列表、使用的算法。test_logic.rpt检查插入的逻辑有没有违反设计规则DRC。DRC违规是常见问题比如时钟域不匹配、复位信号极性错误、管脚冲突。工具会给出具体的违规类型和位置你需要逐条修复。4.2 用仿真验证BIST功能插入完成不代表万事大吉必须用仿真验证BIST逻辑真的能工作。Tessent可以自动生成仿真环境和测试向量# 生成仿真模型 write_verilog tessent/work/top_with_mbist.v # 生成测试向量 create_testbench -output tessent/patterns/mbist_tb.v write_testbench -format verilog -output tessent/patterns/mbist_patterns.v生成的testbench会包含BIST控制器的初始化、测试启动、结果比较这些逻辑。你把它接到你的仿真环境里跑一遍看看能不能通过。仿真中最常见的问题是时序不匹配。BIST控制器的工作时钟可能跟功能时钟不同频如果testbench里的时钟配置不对BIST状态机会卡死。解决办法是在testbench里显式指定BIST时钟的频率和相位。4.3 覆盖率分析和优化仿真通过之后用Tessent的覆盖率分析工具检查测试覆盖率# 分析覆盖率 analyze_mbist_coverage -report tessent/reports/coverage.rpt这个报告会告诉你每种故障模型的覆盖率。如果覆盖率不达标通常有两个原因算法选择不当或者内存模型不准确。算法问题好解决换更复杂的算法就行。内存模型问题比较麻烦需要你对照datasheet逐项检查模型文件里的时序参数。我遇到过因为模型里写错了读写延迟导致March算法跑出来的结果全错的情况排查了一整天才发现是模型的问题。5. 那些文档里不会写的踩坑经验5.1 内存模型导入失败的排查链路内存模型导入失败是新手最常遇到的问题。工具报的错往往很模糊比如cannot resolve memory instance你根本不知道是模型文件的问题还是实例名的问题。我的排查顺序是这样的确认实例名是否正确用get_instances命令列出设计中的所有实例找到内存的完整层次路径。Tessent对实例名大小写敏感u_sram_0和U_SRAM_0是两个不同的东西。检查模型文件格式用文本编辑器打开.tcd文件确认格式是否符合Tessent的要求。TCD文件对缩进和字段顺序有严格要求一个tab写成空格就可能导致解析失败。验证模型参数用report_memory -model命令单独检查模型文件看看工具能不能正确解析出地址位宽、数据位宽这些参数。如果解析出来的参数跟datasheet对不上说明模型文件写错了。检查库文件依赖有些内存模型依赖特定的工艺库单元如果库文件不完整模型导入也会失败。用check_library命令检查库的完整性。这个排查链路我用了很多次基本上能覆盖90%以上的导入失败问题。5.2 共享总线冲突的典型表现和修复共享BIST控制器的时候多颗内存共用一条测试总线如果总线仲裁逻辑有问题会出现测试结果随机错误。典型表现是单独测每颗内存都能过一起测就有几颗报错。这个问题的根因通常是总线切换时序不对。BIST控制器在切换内存的时候需要先完成当前内存的测试再发起下一颗内存的测试。如果切换太快前一颗内存的测试结果还没读出来就被下一颗的测试数据覆盖了。修复方法是在控制器配置里增加总线切换延迟set_dft_configuration -mbist_bus_switch_delay 4这个延迟的单位是时钟周期具体值取决于你的内存读写延迟。一般设置成内存最大读写延迟的两倍比较保险。5.3 测试时间估算和优化测试时间是MBIST流程中容易被忽略但非常重要的指标。芯片出厂测试是按时间收费的测试时间每增加1秒成本就增加一大截。测试时间的估算公式是总测试时间 内存数量 × 每颗内存的测试周期数 / 并行度并行度取决于BIST控制器的共享策略。如果每颗内存独立控制器并行度就是内存数量如果4颗共享一个控制器并行度就是内存数量/4。优化测试时间的方法有几个增加并行度减少共享控制器的内存数量但会增加面积。选择更短的算法March C-比March SS短一半以上如果覆盖率够用优先选短的。分批次测试不需要一次性测所有内存可以分多次测试每次测一部分。这样虽然总时间不变但峰值功耗更低。我通常会在项目早期就做一个测试时间估算表把不同方案的时间、面积、覆盖率列出来跟项目组一起决定用哪个方案。这个表长这样方案控制器数量测试周期数面积开销覆盖率全独立1610240大98%4颗共享440960中98%8颗共享281920小98%有了这个表决策就清晰了。5.4 跟ATPG流程的衔接注意事项MBIST不是孤立的它最终要跟ATPG自动测试向量生成流程衔接。衔接的时候有几个注意点BIST控制器的旁路在跑ATPG的时候BIST控制器需要被旁路掉否则它会干扰扫描链的工作。Tessent通过set_dft_configuration -mbist_bypass on来自动插入旁路逻辑。管脚复用冲突BIST接口和扫描接口可能复用同一组管脚需要确保两种模式下的管脚方向一致。如果BIST模式下某个管脚是输出扫描模式下是输入就会冲突。测试模式切换芯片需要支持多种测试模式BIST模式、扫描模式、功能模式模式切换逻辑要设计好避免切换过程中产生毛刺。这些问题在单独跑MBIST的时候不会暴露只有跟ATPG流程集成的时候才会出现。所以我的建议是MBIST流程跑通之后尽早跟ATPG流程做集成测试不要等到项目后期才发现问题。6. 脚本模板和参数速查6.1 完整脚本模板把前面所有步骤串起来一个完整的MBIST脚本大概长这样# # Tessent MBIST Script Template # Author: DFT Engineer # Description: Complete MBIST flow for SRAM testing # # --- 1. 环境设置 --- set_context dft -mbist set_log_file tessent/reports/mbist_run.log -replace set_message_limit 1000 # --- 2. 读入库和设计 --- read_cell_library libs/tsmc28_stdcell.db read_verilog rtl/top.v read_verilog rtl/memory_wrapper.v set_current_design top # --- 3. 导入内存模型 --- add_memory -model tessent/models/sram_1024x32.tcd -instance u_sram_0 add_memory -model tessent/models/sram_512x64.tcd -instance u_sram_1 add_memory -model tessent/models/sram_2048x16.tcd -instance u_sram_2 # 验证内存导入 report_memory -all tessent/reports/memory_list.rpt # --- 4. 配置BIST控制器 --- set_dft_configuration -mbist_shared_controller on set_dft_configuration -mbist_max_shared_memories 4 set_dft_configuration -mbist_bus_switch_delay 4 # --- 5. 设置测试算法 --- set_mbist_algorithm -default march_c_minus set_mbist_algorithm -instance u_sram_2 -algorithm march_ss # --- 6. 管脚分配 --- set_dft_signal -view spec -type TestMode -port test_mode set_dft_signal -view spec -type ScanEnable -port scan_en set_dft_signal -view spec -type ScanClock -port clk -timing {45 55} set_dft_signal -view spec -type MbistEn -port mbist_en set_dft_signal -view spec -type MbistClk -port mbist_clk set_dft_signal -view spec -type MbistReset -port mbist_rst_n # --- 7. 插入BIST逻辑 --- create_dft_specification insert_test_logic # --- 8. 生成报告 --- report_dft_signal -view spec tessent/reports/dft_signals.rpt report_mbist_controller tessent/reports/mbist_controllers.rpt report_test_logic tessent/reports/test_logic.rpt # --- 9. 输出网表和向量 --- write_verilog tessent/work/top_with_mbist.v create_testbench -output tessent/patterns/mbist_tb.v write_testbench -format verilog -output tessent/patterns/mbist_patterns.v # --- 10. 覆盖率分析 --- analyze_mbist_coverage -report tessent/reports/coverage.rpt puts MBIST flow completed successfully.这个模板可以直接拿去用改改变量名和文件路径就行。6.2 关键参数速查表参数含义推荐值备注mbist_shared_controller是否共享控制器on/off内存多时开mbist_max_shared_memories每个控制器最大内存数4权衡面积和时间mbist_bus_switch_delay总线切换延迟4内存读写延迟的2倍march_c_minusMarch C-算法默认10N复杂度march_ssMarch SS算法高覆盖率时用22N复杂度mbist_bypassBIST旁路onATPG时必须开6.3 常见错误码和解决方法错误码含义解决方法DFT-001内存实例未找到检查实例名和层次路径DFT-002模型文件解析失败检查TCD格式和缩进DFT-003管脚冲突检查管脚复用配置DFT-004时钟域不匹配检查BIST时钟和功能时钟DFT-005覆盖率不达标更换算法或检查模型这些错误码是我在实际项目中总结的Tessent的官方文档里不一定有完全对应的编号但错误类型是通用的。7. 从跑通到跑好一些个人体会MBIST流程跑通不难难的是跑好。跑通意味着工具不报错、仿真能过跑好意味着测试时间短、面积开销小、覆盖率达标、跟其他DFT流程无缝衔接。我做了这么多年DFT最大的体会是前期多花时间做规划后期少花时间擦屁股。具体来说在写第一行脚本之前先把这几件事想清楚内存清单设计里到底有多少颗内存每颗的类型、容量、接口是什么。测试时间预算芯片的测试时间要求是多少能容忍多长的MBIST测试时间。面积预算BIST控制器能占多大面积有没有硬性限制。管脚规划BIST接口用哪些管脚跟功能管脚和扫描管脚怎么复用。这四个问题想清楚了脚本写起来就是水到渠成的事。反过来如果这些没想清楚就动手大概率要返工。另外Tessent的版本更新比较频繁不同版本之间的命令语法可能有细微差异。我建议在项目开始的时候锁定一个版本不要中途升级。如果非要升级先在测试用例上跑一遍确认所有命令都兼容再切到正式项目。最后说一个容易被忽略的点MBIST的测试向量要跟ATE设备的能力匹配。不同ATE设备的管脚数量、时钟频率、存储深度都不一样。生成向量之前先确认ATE设备的规格避免生成的向量跑不了。这个坑我在项目后期踩过一次向量生成了才发现ATE的存储深度不够只能重新生成白白浪费了一周时间。
返回列表