企业官网建设流程全解析

1. 从零理解Tessent MBIST：为什么内存测试绕不开这套流程

1.1 一颗芯片里，内存测试到底在测什么

做DFT这行的朋友都知道，芯片里最让人头疼的模块往往不是那些几百万门的逻辑电路，而是密密麻麻嵌在角落里的SRAM和寄存器堆。一颗中等规模的SoC，内嵌SRAM动辄几十上百个实例，每个实例的位宽、深度、端口配置都不一样。这些内存一旦在流片后出现制造缺陷，轻则功能异常，重则整颗芯片报废。所以Memory BIST（内建自测试）就成了DFT流程里不可跳过的一环。

Tessent MBIST是西门子EDA（原Mentor Graphics）旗下Tessent产品线中的内存测试解决方案。它的核心思路是：在芯片内部插入一套硬件测试逻辑，由MBIST控制器自动生成地址、数据和控制信号，对每个内存实例执行写入和读取操作，然后通过比较器判断读回的数据是否与预期一致。整个过程不需要外部ATE提供复杂的测试向量，只需要给一个启动信号，剩下的交给片上逻辑自己跑。

这套方案解决的核心问题是：内存测试的自动化与可重复性。如果没有MBIST，你得为每个内存实例手工编写测试向量，考虑地址译码、数据背景模式、读写时序，工作量巨大且容易出错。而Tessent MBIST通过工具自动插入测试电路，配合参考脚本，可以在几小时内完成从内存模型导入到最终测试电路生成的全流程。

适合阅读这篇文章的读者包括：刚入行的DFT工程师、需要接手MBIST流程的验证人员、以及想了解Tessent工具链实操细节的在校研究生。我默认你已经有基本的数字电路概念，知道什么是扫描链、什么是ATPG，但对Tessent MBIST的具体操作流程可能还不太熟悉。

1.2 为什么需要“参考脚本”而不是纯GUI操作

Tessent工具本身提供了图形界面，但真正在项目里跑MBIST流程，没人会一步步点GUI。原因很简单：一颗芯片可能有几十个内存实例，每个实例的配置参数不同，GUI操作无法批量处理，也无法版本管理。参考脚本的价值在于：把整个MBIST流程固化成可重复执行的命令序列，今天跑和明天跑结果一致，张三跑和李四跑结果也一致。

Tessent MBIST的参考脚本通常是一组Tcl脚本，配合Shell脚本做流程调度。Tcl负责调用Tessent的命令接口，Shell负责环境变量设置、文件路径管理、日志记录。这种组合在DFT领域非常常见，因为Tcl是EDA工具的事实标准脚本语言，而Shell擅长做流程控制和文件操作。

我见过不少新手一上来就想跳过脚本直接操作工具，结果遇到问题连日志都找不到。所以我的建议是：先把参考脚本的骨架搭起来，哪怕一开始只是空跑，也要把流程框架建立起来。后面再往里面填充具体的内存配置和测试算法。

1.3 整体流程的五个阶段

从零搭建一个完整的MBIST测试环境，大致可以分成五个阶段：

1. 环境准备：安装Tessent工具、配置License、准备工艺库和内存模型文件。
2. 内存模型导入与配置：把SRAM的.lib或.db文件导入Tessent，定义每个内存实例的物理属性。
3. MBIST电路生成：选择合适的测试算法，配置控制器参数，生成MBIST逻辑。
4. 插入与验证：把MBIST逻辑插入到设计网表中，跑仿真验证功能正确性。
5. 测试向量生成与ATPG衔接：生成MBIST的测试向量，并与扫描链测试流程对接。

这五个阶段环环相扣，任何一个环节出问题都会导致后续流程卡住。下面我会逐个拆解每个阶段的核心操作和踩坑经验。

2. 环境搭建与工具配置：把地基打牢

2.1 Tessent工具的安装与License配置

Tessent的安装本身不复杂，但License配置经常让新手卡住。Tessent通常和Calibre、Questa等工具共用一套License管理机制，你需要确认License文件里包含tessent_mbist这个feature。如果没有，工具启动时会直接报错退出。

安装路径建议不要有空格和中文，这是EDA工具的通病。我一般会把Tessent装在/opt/siemens/tessent下面，版本号单独建目录，比如/opt/siemens/tessent/2023.4。这样多版本共存时切换方便。

环境变量需要设置以下几个：

export TESSENT_HOME=/opt/siemens/tessent/2023.4 export PATH=$TESSENT_HOME/bin:$PATH export LM_LICENSE_FILE=27000@license_server export TESSENT_LICENSE_FILE=$LM_LICENSE_FILE

注意：LM_LICENSE_FILE和TESSENT_LICENSE_FILE最好都设置，有些版本的Tessent只认后者。License服务器地址根据你实际的环境填写。

验证安装是否成功，可以跑一个最简单的命令：

tessent -version

如果输出了版本号，说明基本环境没问题。如果报License错误，检查feature是否齐全。

2.2 工艺库与内存模型的准备

MBIST流程需要两类输入文件：工艺库文件和内存模型文件。

工艺库文件通常是.lib或.db格式，包含了标准单元和内存单元的时序、功耗信息。Tessent需要这些信息来确保MBIST逻辑插入后不会引入时序违例。如果你拿到的库是.lib格式，需要用Library Compiler转成.db，Tessent读.db更稳定。

内存模型文件是MBIST的核心输入。每个SRAM实例都需要一个对应的模型文件，描述它的地址位宽、数据位宽、端口类型（单端口/双端口）、读写时序参数等。这些文件通常由内存IP供应商提供，格式可能是.lib、.db或Tessent专用的.mem格式。

我遇到过一种情况：供应商只给了.lib文件，但Tessent的MBIST流程需要.mem格式。这时候需要用Tessent自带的转换工具：

tessent -shell > read_lib -format lib -library sram_1024x32.lib > write_mem -format mem -output sram_1024x32.mem

转换完成后，检查.mem文件里的地址位宽和数据位宽是否与预期一致。我踩过一次坑：供应商的.lib文件里地址位宽写的是10位，但实际SRAM是1024深度，应该是10位没错，但数据位宽写成了32位，实际是36位（带校验位）。这种细节不检查，后面MBIST电路生成出来就是错的。

2.3 目录结构设计与Shell脚本框架

一个清晰的目录结构能让后续调试省很多事。我通常这样组织：

mbist_project/ ├── scripts/ # Tcl和Shell脚本 │ ├── run_mbist.sh │ ├── setup.tcl │ └── insert_mbist.tcl ├── libs/ # 工艺库和内存模型 │ ├── std_cell.db │ └── sram_*.mem ├── design/ # 设计网表和约束 │ ├── top.v │ └── top.sdc ├── work/ # 工具运行目录 └── reports/ # 输出报告和日志

Shell脚本的框架大致如下：

#!/bin/bash # run_mbist.sh - MBIST流程主控脚本 set -e # 遇到错误立即退出 # 环境变量 export TESSENT_HOME=/opt/siemens/tessent/2023.4 export PATH=$TESSENT_HOME/bin:$PATH export TESSENT_LICENSE_FILE=27000@license_server # 路径定义 PROJ_DIR=$(cd $(dirname $0)/.. && pwd) LIB_DIR=$PROJ_DIR/libs DESIGN_DIR=$PROJ_DIR/design WORK_DIR=$PROJ_DIR/work REPORT_DIR=$PROJ_DIR/reports # 清理工作目录 rm -rf $WORK_DIR/* mkdir -p $WORK_DIR $REPORT_DIR # 进入工作目录 cd $WORK_DIR # 执行Tcl脚本 tessent -shell -f $PROJ_DIR/scripts/setup.tcl -log $REPORT_DIR/setup.log tessent -shell -f $PROJ_DIR/scripts/insert_mbist.tcl -log $REPORT_DIR/insert.log echo "MBIST flow completed."

这个框架的好处是：所有路径都是相对项目根目录定义的，换一台机器只要改PROJ_DIR的父目录即可。set -e确保任何一步失败都会立即停止，不会带着错误继续跑。

提示：Shell脚本里的for循环在批量处理多个内存实例时特别有用。比如你有20个SRAM需要生成MBIST逻辑，可以用循环逐个调用Tessent命令，每个实例单独输出日志，方便定位问题。

3. 内存模型导入与MBIST电路生成的核心操作

3.1 用Tcl脚本导入内存模型并定义实例

Tessent MBIST的第一步是把内存模型读进来，然后告诉工具：设计里有哪些内存实例，每个实例对应哪个模型。

# setup.tcl - 导入库和设计 # 设置搜索路径 set search_path [list . ../libs ../design] set link_path "* std_cell.db" # 读取设计网表 read_verilog ../design/top.v set_current_design top # 读取内存模型 read_mem -format mem ../libs/sram_1024x32.mem read_mem -format mem ../libs/sram_512x64.mem # 列出设计中所有内存实例 set mem_insts [get_instances -hier -filter "is_memory == true"] puts "Found [llength $mem_insts] memory instances" foreach inst $mem_insts { puts " - $inst : [get_attribute $inst ref_name]" }

这段脚本跑完后，你会看到设计里所有内存实例的列表。如果某个实例没被识别为内存，说明它的模型文件没读进来，或者实例名匹配不上。

我遇到过一种情况：设计里例化的SRAM模块名是sram_1024x32_wrapper，但模型文件里定义的是sram_1024x32。这时候需要用set_attribute手动绑定：

set_attribute [get_instances u_sram_wrapper] ref_name sram_1024x32

3.2 选择测试算法：March C-还是March SS

MBIST的核心是测试算法。不同的算法覆盖不同的故障模型，跑的时间也不同。常用的几种：

选择算法时需要考虑两个因素：故障覆盖需求和测试时间预算。如果芯片对可靠性要求极高（比如汽车电子），选March SS；如果是消费类芯片，March C-通常够用。

在Tessent里指定算法：

# 为所有内存实例设置March C-算法 set_mbist_algorithm -type march_c_minus -instances $mem_insts

注意：March C-的“C-”是算法名称的一部分，不是减号的意思。有些文档写成March C减，容易让人困惑。

3.3 配置MBIST控制器参数

MBIST控制器负责生成地址、数据和控制信号。它的参数直接影响测试电路的面积和功耗。

关键参数包括：

• 数据背景模式：全0、全1、棋盘格、行走1等。背景模式越多，故障覆盖越高，但测试时间越长。
• 地址顺序：升序、降序、随机。升序最快，随机覆盖最好。
• 并行测试实例数：同时测试多少个内存实例。并行度高则测试时间短，但峰值功耗大。

# 配置MBIST控制器 create_mbist_controller -name mbist_ctrl \ -instances $mem_insts \ -algorithm march_c_minus \ -data_background {all_0 all_1 checkerboard} \ -address_order ascending \ -max_parallel 4

max_parallel 4表示最多同时测试4个内存实例。这个数字需要根据芯片的电源网络能力来定。如果电源网络较弱，并行度太高会导致电压降过大，测试结果不可靠。

我一般会先算一下峰值功耗：每个SRAM在读写时的动态功耗大约是C * V^2 * f，其中C是负载电容，V是电压，f是频率。假设单个SRAM动态功耗是5mW，4个并行就是20mW。如果电源网络能提供100mW，那并行度还可以再提高。

3.4 生成MBIST逻辑并检查报告

配置完成后，执行生成命令：

# 生成MBIST逻辑 insert_mbist -controller mbist_ctrl # 输出报告 report_mbist -controller mbist_ctrl -file ../reports/mbist_report.rpt report_area -file ../reports/area_report.rpt

生成完成后，重点检查三个报告：

1. MBIST报告：确认每个内存实例都被正确覆盖，算法和背景模式符合预期。
2. 面积报告：MBIST逻辑的面积增量。如果面积增加超过5%，需要检查是否有冗余逻辑。
3. 时序报告：MBIST逻辑插入后是否引入时序违例。如果有，需要调整控制器位置或插入流水线。

我踩过一次坑：生成MBIST逻辑后没看时序报告，直接跑仿真，结果发现MBIST控制器的输出到SRAM的路径有setup违例。原因是控制器放在芯片角落，而SRAM在另一个角落，走线太长。后来把控制器移到SRAM集群中间，问题解决。

4. 仿真验证与测试向量生成

4.1 搭建MBIST仿真环境

MBIST逻辑插入后，必须跑仿真验证功能正确性。仿真环境需要三样东西：测试平台（Testbench）、MBIST启动序列、结果检查机制。

Testbench通常用Verilog或SystemVerilog写，核心是给MBIST控制器一个启动信号，然后等待测试完成信号。

// mbist_tb.v - MBIST测试平台 module mbist_tb; reg clk; reg rst_n; reg mbist_start; wire mbist_done; wire mbist_fail; // 例化设计顶层 top u_top ( .clk(clk), .rst_n(rst_n), .mbist_start(mbist_start), .mbist_done(mbist_done), .mbist_fail(mbist_fail) ); // 时钟生成 initial begin clk = 0; forever #5 clk = ~clk; end // 测试序列 initial begin rst_n = 0; mbist_start = 0; #100 rst_n = 1; #100 mbist_start = 1; #20 mbist_start = 0; // 等待测试完成 wait(mbist_done == 1); #100; if (mbist_fail == 1) begin $display("MBIST FAILED at time %t", $time); end else begin $display("MBIST PASSED at time %t", $time); end $finish; end endmodule

跑仿真时，我习惯用VCS或Questa，命令大致如下：

vcs -full64 -sverilog mbist_tb.v top.v -o simv ./simv -l sim.log

提示：仿真时间可能很长，因为March C-算法要遍历所有地址。如果SRAM是1024深度，March C-大约需要10个周期每地址，总共约10000个周期。在100MHz时钟下，大约100微秒。仿真时可以把时钟频率调高，缩短仿真时间。

4.2 生成MBIST测试向量

仿真通过后，需要生成ATE用的测试向量。Tessent可以输出STIL或WGL格式的向量文件。

# 生成测试向量 create_test_pattern -controller mbist_ctrl -format stil -output ../reports/mbist_pattern.stil

生成的STIL文件包含了MBIST启动、地址遍历、数据比较的完整时序。ATE工程师会把这个文件转换成特定测试机的格式。

我遇到过一种情况：生成的STIL文件里，MBIST启动信号的时序与ATE的时钟域不匹配。原因是Tessent默认按设计时钟生成向量，但ATE的时钟可能不同。解决方法是在生成向量时指定时钟频率：

create_test_pattern -controller mbist_ctrl -format stil -clock_period 10 -output ../reports/mbist_pattern.stil

4.3 与扫描链测试的衔接

MBIST和扫描链测试是DFT的两个独立流程，但它们共享芯片的引脚和测试模式。衔接时需要注意：

• 测试模式切换：MBIST模式和扫描模式不能同时激活。需要在测试控制器里定义模式选择信号。
• 引脚复用：MBIST启动信号和扫描使能信号可能复用同一个引脚。需要在测试协议里明确切换时序。
• 测试时间调度：MBIST测试和扫描测试的总时间不能超过ATE的测试预算。

我通常会在测试控制器里加一个简单的状态机，根据外部引脚的电平组合决定进入MBIST模式还是扫描模式。这部分逻辑用Tessent的create_test_controller命令生成。

5. 常见问题与排查技巧实录

5.1 内存实例未被识别

现象：get_instances -filter "is_memory == true"返回空列表。

排查思路：

1. 检查模型文件是否成功读入。用report_mem命令查看已加载的内存模型。
2. 检查实例名是否匹配。用get_instances -hier列出所有实例，看内存实例的名字是否与模型文件里的定义一致。
3. 检查网表是否完整。如果网表里SRAM被优化掉了，工具自然找不到。

解决方法：手动绑定实例和模型：

set_attribute [get_instances u_sram] ref_name sram_1024x32

5.2 MBIST逻辑插入后时序违例

现象：report_timing显示MBIST控制器到SRAM的路径有setup违例。

排查思路：

1. 检查控制器和SRAM的物理位置。如果距离太远，走线延迟大。
2. 检查是否插入了流水线寄存器。MBIST控制器的输出可以直接打拍，减少组合逻辑延迟。
3. 检查时钟约束是否正确。MBIST逻辑可能工作在慢时钟域，约束要相应调整。

解决方法：在控制器输出插入一级寄存器：

set_mbist_option -pipeline_output true

5.3 仿真时MBIST不启动

现象：Testbench给了启动信号，但mbist_done一直为0。

排查思路：

1. 检查复位信号是否释放。MBIST控制器需要复位后才能工作。
2. 检查时钟是否在跑。用$monitor打印时钟信号。
3. 检查启动信号的脉宽是否足够。有些控制器需要至少2个时钟周期的启动脉冲。

解决方法：延长启动脉冲宽度，确保复位释放后再给启动信号。

5.4 常见问题速查表

5.5 独家避坑经验

经验一：先跑通一个内存实例，再批量处理。我见过新手一上来就把所有内存实例一起配置，结果一个出错全部卡住。正确做法是先拿一个最简单的SRAM跑通全流程，确认脚本没问题后再扩展到所有实例。

经验二：日志分级记录。Tessent的日志信息量很大，全部输出到终端会刷屏。我习惯把详细日志写到文件，终端只输出关键步骤：

tessent -shell -f setup.tcl -log setup.log -verbose 0

经验三：版本控制。MBIST脚本和配置文件一定要纳入Git管理。我遇到过因为脚本改动导致流片版本MBIST失效的情况，后来每次改动都提交Git，出问题可以快速回滚。

经验四：仿真加速。如果SRAM容量很大，仿真时间会很长。可以用Tessent的-fast_sim选项生成简化模型，仿真速度能提升10倍以上，但会牺牲一些时序精度。适合前期功能验证，后期签核时再用完整模型。

经验五：与ATE工程师提前沟通。MBIST测试向量的格式和时序要求，最好在生成向量之前就和ATE工程师确认。我踩过一次坑：向量生成完了才发现ATE测试机不支持STIL格式，只能重新生成WGL格式，浪费了两天时间。

6. 从脚本到流程：我的实操体会

整套MBIST流程跑下来，最深的体会是：脚本的健壮性比功能完整性更重要。一个能跑通但脆弱的脚本，不如一个功能少但稳定的脚本。我现在的习惯是，每加一个新功能，先跑10次确认结果一致，再纳入正式流程。

另外，Tessent的版本更新比较频繁，不同版本之间的命令参数可能有细微差异。建议在项目开始时锁定一个版本，不要中途升级。如果必须升级，先在测试用例上验证所有脚本，确认无误后再迁移。

最后分享一个小技巧：Tessent的Tcl接口支持catch命令，可以把可能出错的命令包起来，出错时输出友好提示而不是直接崩溃：

if {[catch {read_mem -format mem $mem_file} err]} { puts "ERROR: Failed to read $mem_file: $err" exit 1 }

这个技巧在批量处理多个内存模型时特别有用，能快速定位是哪个文件出了问题。