V93000 SmarTest 8 软件体系架构与测试机操作解析
摘要:本文系统梳理 SmarTest 8 软件环境的核心设计理念、关键技术概念、Model File 机制及测试机启动操作规范,旨在为从事半导体测试软件开发与调试的工程师提供结构化的技术参考。
目录
- [SmarTest 8 软件环境总览](#SmarTest 8 软件环境总览)
- 核心设计理念
- [SmarTest Setup Format(SSF)](#SmarTest Setup Format(SSF))
- [SmarTest Work Center 集成开发环境](#SmarTest Work Center 集成开发环境)
- [Java 编程语言集成](#Java 编程语言集成)
- [Model File 机制](#Model File 机制)
- [SmarTest 8 启动操作](#SmarTest 8 启动操作)
- 总结
1. SmarTest 8 软件环境总览
SmarTest 8 是 Advantest V93000 系列测试机的配套软件平台,基于 Eclipse IDE 框架构建,面向 SOC 器件的全流程测试需求(从测试程序开发、调试到量产执行)提供统一的软件环境。
其核心设计围绕以下三个目标展开:
- 硬件抽象(Hardware Abstraction):屏蔽不同测试卡之间的硬件差异,提供统一的仪器编程接口。
- 跨域同步(Cross-Domain Synchronization):在单一 Sequencer Start 下,协调 Digital、DC、PA、MX、RF 等多域仪器的同步执行。
- 测试程序复用(Test Program Reuse):通过层次化 Testflow 与模块化 Setup,支持团队协作开发与跨项目资产复用。
2. 核心设计理念
2.1 跨域操作序列同步(Operating Sequence)
SmarTest 8 引入**操作序列(Operating Sequence)**机制,允许在单次 Sequencer Start 触发下,跨所有仪器域并行执行测试步骤,从根本上消除域间切换的时间开销。
操作序列的核心特性:
- 易于组合 :将 Pattern Call、Transaction、Action 等测试步骤以
parallel/sequential块结构进行灵活组合,并内建同步点(sync)控制。 - 多域覆盖:单一操作序列可同时涵盖 Digital、DC、PA、MX、RF 五大仪器域。
操作序列语法结构示例:
sequence ExampleIntroSlides {
parallel parGrp1 {
sequential seq1_1 {
patternCall crossconnect.operatingSequence.patterns.Init InitDUT;
}
}
parallel parGrp2 {
sequential seq2_1 {
patternCall crossconnect.operatingSequence.patterns.DigTestA FuncA;
}
}
parallel parGrp3 {
sequential seq3_1 {
actionCall vForce1;
}
}
parallel parGrp4 {
sequential seq4_1 {
patternCall crossconnect.operatingSequence.patterns.DigTestB FuncB;
parallel parGrp4_1_1 {
sequential seq4_1_1_1 {
patternCall crossconnect.operatingSequence.patterns.DigTestC FuncC;
}
sequential seq4_1_1_2 {
actionCall capture;
}
}
}
sequential seq4_2 {
wait 0.6ms;
actionCall vForce2;
}
}
}
上述结构清晰体现了并行(parallel)与顺序(sequential)块的嵌套组合能力,以及 patternCall 与 actionCall 跨域调用的统一语法。
2.2 硬件抽象与统一仪器设置(Unified Setups for Tester Resources)
SmarTest 8 的核心抽象原则:凡是可由多种硬件资源完成的任务,其设置方式始终相同。
以 Force Voltage / Measure Current(直流激励与测量)为例,无论底层硬件是 Pin Scale 1600(PMU)、Pin Scale 1600(BADC)、DC Scale DPS128 还是 Wave Scale MX(PMU),用户均通过同一仪器类型 dcVI 进行配置,底层 Translation Layer 负责将设置映射至实际物理硬件。
用户配置层:dcVI setup of a signal
↓ Translation to HW
┌─────────────────────────────────┐
│ Pin Scale 1600(BADC) │
│ Pin Scale 1600(PMU) │
│ DC Scale DPS128 │
│ Wave Scale MX(PMU) │
└─────────────────────────────────┘
支持的仪器类型包括:awg、clock、dcVI、digInOut、digitizer、rfMeas、rfStim、rfVna、utility 等,各类型通过统一的 Setup API 和运行时 API 进行控制,与底层资源解耦。
2.3 多域调试工具融合(Convergence of Digital, Analog & RF Tools)
SmarTest 8 提供的调试工具均为多域工具(Multi Domain Tools),可在同一界面中同时呈现 Digital、Analog、RF、DC、PA 等多个域的信号与测量结果。
主要多域调试工具一览:
| 工具名称 | 功能描述 |
|---|---|
| Signal Analyzer | 跨域信号波形分析与叠加显示 |
| Operating Sequence Viewer | 操作序列执行时序可视化 |
| Measurement View(MV) | 各域测量结果统一展示与判决 |
| Tester View | 测试机资源状态监控 |
| Timing Debug View(TDT) | 时序参数调试,支持 Action 标注 |
2.4 层次化 Testflow 与测试程序复用(Reuse of Self-Contained Test Program Parts)
SmarTest 8 支持自包含测试程序片段的多层次复用:
- 同一测试程序内多次复用:使用不同参数多次调用同一子流程。
- 跨测试程序复用:不同产品(如同系列 MCU 的两个变型)可共享相同的功能子流程(DC、WLAN、GPS 等)。
层次化 Testflow 的设计规则:
- Testflow 的每个节点可以是一个 Test Suite 或另一个 Testflow(支持无限嵌套)。
- 每个 Testflow 均可定义输入参数与输出参数,实现参数化复用。
2.5 团队协作开发支持(Team Development of Test Programs)
SmarTest 8 通过模块化 Setup 文件结构支持大型团队的并行开发:
- 灵活的文件结构:每个 Setup 实体(信号、电平、时序、序列等)可独立存储为单独文件。
- 版本控制集成:内建 SVN 和 GIT 支持,与行业标准版本控制系统无缝对接。
- 外部 Setup 文件链接:支持引用外部团队提供的 Setup 文件,实现跨团队内容共享而无需合并文件。
3. SmarTest Setup Format(SSF)
3.1 概述
为支持仪器抽象、操作序列和层次化 Testflow 等新概念,SmarTest 8 定义了专用的文件描述语言------SmarTest Setup Format(SSF)。SSF 针对不同类型的 Setup 数据分别设计,以易用性为首要目标。
SSF 涵盖的文件类型:
| 文件类型 | 内容描述 |
|---|---|
Test Program File (.prog) |
定义 Testflow 节点与 Test Suite 的整体结构 |
Testflow File (.flow) |
定义可复用的子流程及其参数 |
Specification File (.spec) |
包含仪器设置参数(电平、时序、DC 配置等) |
Operating Sequence File (.sq) |
定义跨域操作序列的并行/顺序结构 |
DUT Board Description File (.dbd) |
描述 DUT Board 信号与 Pogo 编号的对应关系 |
SmarTest 同时提供标准 API,供外部工具以正确格式生成和读取 SSF 文件,便于与第三方 EDA 工具链集成。
3.2 Specification File 示例
Specification File 用于定义仪器的电平、时序等参数,示例结构如下:
import crossconnect.digitalPattern.levels.FunctionalLevel;
spec Functional_Par3Seq {
// level settings
vcc = 1.4 V;
IV_Swing = 1.4 V;
OV_Swing = 0.4 V;
// timing settings
per = 200 ns;
t_drive = per / 4;
t_exp = per - 2 ns;
setup digInOut allInputs+allOutputs {
result.cyclePassFail.enabled = true;
}
}
3.3 DUT Board Description File 示例
DUT Board Description File 定义每个信号在各测试 Site 的 Pogo 编号映射:
dutboard CrossConnect4Site {
sites = 4;
signal D00 {
site 1 { pogo = 10101; }
site 2 { pogo = 10301; }
site 3 { pogo = 10501; }
site 4 { pogo = 10701; }
}
@Disabled
signal D01 {
site 1 { pogo = 10103; }
site 2 { pogo = 10303; }
...
}
}
上述文件同时支持 Source 视图 (直接编辑 SSF 源码)和 Table 视图(以表格形式编辑各 Site 的 Pogo 映射),两种视图内容实时同步,无需手动转换。
4. SmarTest Work Center 集成开发环境
4.1 整体架构
SmarTest Work Center 基于 Eclipse 框架构建,采用透视图(Perspective)与视图(View)的组合,为 Setup、执行和调试三个工作阶段提供专属界面布局。
4.2 主要视图组成
| 编号 | 视图名称 | 核心功能 |
|---|---|---|
| ① | Package Explorer | 工程文件树管理,展示所有 Setup 文件的层次结构 |
| ② | Testflow Editor | 图形化 Testflow 编辑,支持节点拖拽与参数配置 |
| ③ | Measurement View | 实时展示各 Test Suite 的测量结果、判决值及 Pass/Fail 状态 |
| ④ | Instrument View | 以电路图形式呈现单信号的仪器设置参数与硬件连接状态 |
| ⑤ | Result View | 最近若干分钟的 Test Suite 执行历史,含 Site、Pass/Fail、Time 列 |
| ⑥ | Operating Sequence View | 操作序列执行时序图,以甘特图形式显示各域的执行块与时间轴 |
4.3 辅助生成与导航功能
SmarTest 8 在 Eclipse 框架的基础上扩展了若干面向测试程序的专属功能:
内容辅助(Content Assist) :在 SSF 文件编辑过程中,按 Ctrl+Space 触发上下文感知的补全提示。例如,当语法预期输入仪器类型时,系统自动列出所有可用仪器类型(awg、clock、dcVI、digInOut、digitizer、rfMeas、rfStim、rfVna、utility 等)及对应的版本说明。
导航功能:
| 快捷操作 | 功能描述 |
|---|---|
F3 |
Open Declaration:跳转至当前引用的定义处 |
| 右键 → "show in" | 在 Package Explorer 中定位当前编辑文件 |
| 右键 → Context Help | 显示当前上下文的帮助文档 |
实践建议:SOC 测试程序通常规模较大,模块化设计进一步增加了文件数量。实际操作中应优先使用右键导航("show in" / F3)而非从 Package Explorer 逐层展开,可显著提升调试效率。
5. Java 编程语言集成
SmarTest 8 选用 Java 作为测试方法(Test Method)的底层编程语言,与 Eclipse 框架深度融合,带来以下工程优势:
5.1 与 Eclipse 的原生集成
Java 是 Eclipse 框架的原生语言,二者集成带来的具体特性:
| 特性 | 说明 |
|---|---|
| 实时语法检查 | 编写代码时即时显示语法错误,无需等待编译 |
| 类型自动推断 | 根据上下文自动确定变量类型,减少冗余声明 |
| 保存时编译 | 保存文件时自动触发增量编译,加速迭代周期 |
| 集成内存管理 | JVM 自动垃圾回收,避免手动内存管理带来的错误 |
5.2 Smart Test Methods 设计理念
SmarTest 8 的测试方法 API 采用面向器件测试的设计范式,而非面向底层硬件资源操作:
- 自动 Multi-Site 扩展:测试方法按单 Site 编写,SmarTest 8 框架自动将其扩展至多 Site 并行执行,并自动管理各 Site 间的测试机资源分配。
- 高层 API 封装 :使用
measurement.execute();替代open relayX; close relayY; run;等低层指令序列,框架自动处理所需资源的准备与释放。 - 跨域 API 一致性:所有仪器类型和域均共享一致且精简的 API 接口。
- 后台结果处理:单次 API 调用即可在后台完成结果上传、分析与评估,期间测试机继续执行后续 Test Suite,实现硬件执行与软件处理的并行化。
6. Model File 机制
6.1 Model File 的定义与作用
Model File 是 SmarTest 的硬件配置描述文件,基于专有语法,完整描述特定 V93000 测试机的硬件构成,是 SmarTest 启动时的必要输入。
Model File 的三项核心描述内容:
| 内容 | 说明 |
|---|---|
| 已安装的测试卡及其特性 | 各卡的型号、功能模式(HS/HR/HC 等) |
| 卡至 DUT Board Pogo 引脚的映射 | Card Slot 编号与 Pogo Block 编号之间的对应关系 |
| 测试系统参考时钟 | 系统级参考时钟信号的来源与配置 |
6.2 默认路径与文件名
| 属性 | 值 |
|---|---|
| 默认目录 | /etc/opt/hp93000/soc/ |
| 默认文件名 | tester.model |
6.3 Model File 结构
Model File 由四个顶层段落(Section)构成:
GLOBAL 段
指定测试系统的类型(如 V93000_A、V93000_S 等)及系统级全局特性开关。
CARD_CONFIGURATION 段(核心段落)
指定所有卡的物理安装位置,以及卡槽(Card Slot)与 DUT Board 接口 Pogo Block 之间的映射关系。
语法格式:
CARD_CONFIGURATION
slot = <槽位编号>, HW = <卡型号>, pogoblocks = <Pogo Block 列表或范围>
典型配置示例:
CARD_CONFIGURATION
slot = 114, HW = PS1600, pogoblocks = 101-108
slot = 105, HW = DPS128, pogoblocks = HC:(225 425 229 429 226 426 230 430)
slot = 213, HW = WSRF, pogoblocks = 901-902
slot = 215, HW = WSMX, pogoblocks = HS:(227 627) HR:(427 827), type=HD2x32
各字段语义说明:
| 字段 | 说明 |
|---|---|
slot |
Test Head 中的物理槽位编号(三位数:百位=Cage,十+个位=Slot) |
HW |
硬件卡型号(PS1600、DPS128、WSRF、WSMX 等) |
pogoblocks |
Pogo Block 编号,支持范围(101-108)或离散列表((225 425 ...)) |
| 前缀标识 | HC: = High Current,HS: = High Speed,HR: = High Resolution |
type |
Pogo 线缆类型(HD2x32 = High Density 2×32,SD = Standard Density 等) |
ETC 段
定义系统通用参数,例如参考时钟信号来源(source=933 等)。
DMM 段
(可选)指定外接数字万用表(Digital Multimeter)的配置信息。
6.4 Model File 的加载行为
SmarTest 在 Offline 模式 和 Online 模式下对 Model File 的处理方式不同:
| 模式 | 加载行为 | Report Window 输出 |
|---|---|---|
| Offline 模式 | 读取 Model File,将其描述的硬件配置作为模拟参考硬件 | 显示 Model File 定义的 "requested configuration" |
| Online 模式 | 读取 Model File,并与 Test Head 实际检测到的硬件进行比对 | 输出 "MAXIMUM POSSIBLE CONFIGURATION BASED ON THE DETECTED HW",并报告差异所产生的 Error / Warning |
Report Window 示例输出(Offline 模式):
V93000 OFFLINE
Testhead: V93000_A
Model file: /etc/opt/hp93000/soc/tester.model
System serial number: None (Offline)
Master release date: 2020.10
MAXIMUM POSSIBLE CONFIGURATION BASED ON THE DETECTED HW:
Pogo | HW | PogoCable | misc
101-832 | WiringBoard | UTILITY | sequencer_controlled
10101-10816 | PS1600 | SD |
22501-22516 | DPS128-HC | SD |
22801-22816 | WSMX-HS | SD |
...
90101-90216 | WSRF | SD | source=933
Report Window 同时列出当前加载的 Model File 路径与文件名,便于确认会话所使用的硬件配置。
Verify Model File 的内容验证:
启动后可在 Report Window 中验证以下三项关键信息:
- 已安装的测试卡(HW 列)
- 卡至 DUT Board Pogo 引脚的映射(Pogo 列)
- Pogo 线缆类型(PogoCable 列,如 SD / E8023PD / E8024UHPS 等)
7. SmarTest 8 启动操作
7.1 Online 模式启动
通过应用程序菜单:Advantest → SmarTest(非 "SmarTest offline")
系统自动加载默认 Model File:/etc/opt/hp93000/soc/tester.model,并与实际 Test Head 硬件进行握手和比对。
7.2 Offline 模式启动
通过应用程序菜单:Advantest → SmarTest offline
Offline 模式下,SmarTest 使用 Model File 定义的硬件配置作为模拟目标,不需要连接实际 Test Head。这是测试程序开发阶段的标准工作模式。
最佳实践 :Offline 模式下使用的 Model File 必须与目标测试机的实际硬件配置完全一致,才能保证测试程序在切换至 Online 模式(上机)时能够正确加载,避免因 Pogo 映射或卡配置不匹配导致的加载失败。
7.3 指定非默认 Model File 的两种方法
方法一:使用环境变量 V93000_MODEL
在终端中依次执行以下命令:
bash
export V93000_MODEL=<file_path>/<myfile.model>
/opt/hp93000/soc/prod_env/bin/HPSmarTest -o &
注意 :
export命令与HPSmarTest启动命令必须在同一 Shell 会话中紧接执行。若中间执行其他操作或切换 Shell,环境变量信息将丢失,导致仍加载默认 Model File。
方法二:将默认 Model File 替换为符号链接
使用 Linux 符号链接命令,将默认路径下的 tester.model 指向目标文件:
bash
ln -s <file_path>/<myfile.model> /etc/opt/hp93000/soc/tester.model
创建符号链接后,可通过任意方式启动 SmarTest(包括应用程序菜单),系统将自动加载符号链接所指向的 Model File。
两种方法对比:
| 方法 | 适用场景 | 持久性 | 操作复杂度 |
|---|---|---|---|
环境变量 V93000_MODEL |
临时切换 Model File,适合快速验证 | 当前 Shell 会话有效 | 低(需注意顺序执行) |
| 符号链接 | 长期固定使用特定 Model File | 持久有效,直至链接被更改 | 中(需要 root 权限) |
8. 总结
SmarTest 8 软件体系的设计思想可从以下维度加以概括:
架构层面:以 Eclipse 框架为基础,将测试程序的编写、调试、执行统一在单一 IDE 环境中,通过 Perspective / View 机制为不同工作阶段提供专属界面。
抽象层面:仪器抽象层(Instrument Layer)与操作序列(Operating Sequence)机制相互配合,使测试工程师得以以"测试意图"而非"硬件操作"的视角编写程序------测试工程师描述"需要对哪个信号做什么",由框架负责将意图翻译为底层硬件指令并协调多域同步执行。
工程层面:层次化 Testflow、模块化 Setup 文件、SVN/GIT 集成及外部文件链接机制,共同构成了面向大型团队、复杂产品线的工程化开发基础设施。
配置层面:Model File 作为软件层与硬件层之间的"契约文件",其正确性直接决定测试程序能否成功从 Offline 开发环境迁移至 Online 量产环境。模型文件的版本管理与验证是工程团队在项目管理中必须重视的关键环节。