【芯片测试】：SmarTest 开发环境入门

SmarTest 开发环境入门：Eclipse IDE 集成与工作区管理

系列： Advantest V93000 SmarTest 8 核心概念解析｜第 1 篇（共 8 篇）
适合读者： 初次接触 SmarTest 的测试工程师、ATE 软件开发者

---

前言

很多工程师第一次打开 SmarTest，看到的是一个"长得像 Eclipse 的东西"。没错，SmarTest 的开发环境确实是基于 Eclipse 构建的------但它不是一个简单的皮肤，而是在 Eclipse 的扩展机制之上，深度定制了专门面向半导体测试的工具链。

本篇介绍三个基础概念：Workspace（工作区） 、Work Center（工作中心） 、Project（项目），以及几个容易踩坑的细节。

---

一、SmarTest 是什么样的 IDE

SmarTest 的开发界面叫做 Work Center ，是 Eclipse IDE 的专属定制版本。启动 SmarTest 后弹出的主窗口就是 Work Center，它围绕三类主要工作流预定义了多套 Perspective（视图配置）：

• Setup：编写测试配置文件（measurement spec、timing、pattern 等）
• Device Debug：调试 DUT 和测试程序
• Analysis：分析测试结果

每个 Perspective 都是一套固定布局的 Editor + View 组合。你也可以自定义 Perspective，但配置会绑定到当前 Workspace。

Editor 和 View 的区别

这个区别在日常使用中很容易混淆：

类型	用途	保存方式
Editor	打开并编辑文件（配置文件、测试方法代码等）	需要手动 Ctrl+S 保存
View	显示和分析数据，或修改选中对象的属性	修改立即自动保存

这意味着在 View 里做的操作是无法用 Ctrl+Z 撤销的，操作前需要格外注意。

---

二、Workspace：SmarTest 的工作目录

Workspace 是 SmarTest 的"工作根目录"，用来组织你的项目引用和个人偏好设置。本质上它是 Eclipse 标准 Workspace 的特化版本，但有几条 SmarTest 特有的约束。

2.1 三条必须记住的规则

规则一：Workspace 不能在 Project 目录内部

Project 目录可以放在 Workspace 里，但强烈建议不要这样做。原因是：如果你删除一个 Workspace，里面的 Project 也会被一并删除。推荐做法是把 Project 放在 Workspace 之外，然后通过**引用（reference）**的方式导入 Workspace，这样删除 Workspace 不会影响 Project。

规则二：Workspace 不能多用户共享，也不能被多个 SmarTest 实例同时使用

如果想在团队之间共享数据，共享的单位是 Project，而不是 Workspace。

规则三：Workspace 与 SmarTest 版本绑定

SmarTest 8 的 Workspace 无法用 SmarTest 7 打开。版本升级后通常需要转换旧 Workspace，但降级则几乎不可行。

2.2 Workspace 的文件结构

一个 SmarTest Workspace 根目录下有两个核心文件：

<workspace_root>/
├── projects.map      ← 必须存在，记录所有项目
└── remote.map        ← 可选，仅当项目来自远程网络时存在

projects.map 详解

这是 Workspace 最重要的元数据文件，纯文本格式（UTF-8），记录了当前 Workspace 引用的所有 Project 名称和路径。

格式规则：

• 每行一个 key=value 键值对
• key 是 Project 名称，value 是路径
• 行尾用 \n，等号两侧的空格会被自动去除
• \ 用于转义（适合路径中含空格或 = 的情况）
• # 开头的行是注释（注意：注释不会被写回文件）
• 支持环境变量：$(ENV_VAR_NAME)

路径格式有三种：

# 1. 绝对路径（Workspace 外部项目）
GlobalProjectName1=/opt/libraries/project1

# 2. 环境变量相对路径（Workspace 外部项目，适合多机共享）
SharedProjectName=$(SRC_ROOT)/project3

# 3. Workspace 相对路径（Workspace 内部项目，不推荐）
WorkspaceLocalProjectName=someDir/project4

推荐使用第 2 种（环境变量路径），便于在不同机器或用户之间共享项目配置，而不硬编码绝对路径。

remote.map

当项目来源于网络文件系统的远程位置时，SmarTest 会在本地缓存一份，并在 remote.map 中记录远程地址：

remote={$PATH$}

这与 Local Cache 功能配合使用，适合多人开发环境下的只读库引用场景。

---

三、SmarTest Project：测试程序的基本单元

Project（项目）是 SmarTest 组织测试数据的基本单元。一个 Project 对应文件系统上的一个文件夹，内部存放测试程序文件、配置文件、测试方法代码等。

3.1 Project 的必要组成

一个最小化的可运行 SmarTest Project 需要：

<project_folder>/
├── src/                    ← 源文件夹（必须有至少一个）
│   └── <功能子目录>/
│       ├── *.prog          ← 测试程序文件（必须在 src 下）
│       ├── *.flow          ← testflow 文件
│       ├── *.spec          ← measurement specification 文件
│       └── *.java          ← 测试方法（不能直接放在 src 下，必须在子目录）
├── bin/                    ← 输出文件夹（SmarTest 自动管理，勿手动修改）
├── .asourcepath            ← 自动生成，勿修改
├── .aclasspath             ← 自动生成，勿修改
├── .aproject               ← 自动生成，勿修改
└── .gitignore              ← 自动生成，可用于 Git 版本控制

几个重要约束：

• 测试方法 Java 文件必须放在 src 的子目录中，不能直接放在 src 下
• bin 目录由 SmarTest 全权管理，不要手动修改
• src 下的所有文件在 binding（绑定）阶段都会被读取，所以不要把非配置文件放到 src 里，否则会拖慢绑定速度

3.2 推荐的目录结构

Advantest 推荐三种组织方式，按需选择：

方式 A：按文件类型组织（适合小型项目）

src/
└── myDevice/
    ├── common/             ← DUT board、主 testflow 等公共文件
    ├── rxTest/             ← Rx 测试相关的所有文件
    └── txTest/             ← Tx 测试相关的所有文件

方式 B：按测试流程组织（适合流程复杂的项目）

src/
└── myDevice/
    ├── common/
    ├── functional/
    │   ├── patterns/
    │   ├── specs/
    │   └── opSeq/
    └── dc/

方式 C：按 IP Core 组织（适合多核 SOC 项目）

src/
└── myDevice/
    ├── common/
    ├── coreA/
    ├── coreB/
    └── coreC/

无论哪种方式，都建议把跨测试共用的文件（DUT board description、主 testflow）统一放在 common 目录下。

3.3 Project 命名规则

命名规则严格遵循 Java 风格：

• 第一个字符只能是 A-Z、a-z、_、$（不能以数字开头）
• 其余字符可以是 a-z、A-Z、0-9、_、$
• 不能使用 SmarTest 关键字作为文件名或文件夹名
• 同一 Workspace 内 Project 名称必须唯一
• Project 名称可以与文件夹名不同

命名惯例建议：文件夹名首字母小写，文件名首字母大写，以便在 IDE 中一眼区分。

3.4 Project 之间的共享与引用

SmarTest 支持跨 Project 共享测试数据，有两种方式：

• 引用（Reference，推荐）：项目在原位置不动，通过 SmarTest Build Path 链接过来。右键目标 Project → SmarTest Build Path → New SmarTest Project Link。
• 复制（Copy，不推荐）：将文件复制到当前 Project。会导致数据不一致，难以维护。

引用机制还会同步 Metadata（如路径变量、显示过滤器），这意味着共享 Project 也会共享相关偏好设置，协作时需要注意。

---

四、C++ 集成：JNI 与 SWIG

SmarTest 的测试方法主体是 Java，但如果已有 C++ 编写的算法库或需要调用底层 native 代码，SmarTest 提供两条路径：

Java Native Interface (JNI)

JNI 是 Java 标准的 native 调用框架，允许 Java 测试方法调用 C++ 函数，也允许 C++ 函数反向操作 Java 对象。需要手写 JNI 胶水代码，复杂但开销最小。

Simplified Wrapper and Interface Generator (SWIG)

SWIG 是开源工具，能自动生成 JNI 绑定代码，大幅减少手工编写量。代价是对复杂类型参数仍需手写转换代码，且部分场景会引入性能开销。

两种方式都需要一个独立的 Bridge Project 来存放 C++ 代码和 .so 共享库：

<bridge_project>/
└── lib/
    └── *.so           ← C++ 共享库必须放在这里

注意： Bridge Project 的代码在 SmarTest 启动时加载，修改后必须重新激活测试程序才能生效。

Foreign Function and Memory (FFM) API（较新方式）

FFM API 是 Java 17+ 引入的 native 调用机制，SmarTest 8 也支持。与 JNI/SWIG 不同，使用 FFM API 不需要单独创建 Bridge Project ，可以直接在测试方法中通过 natives 包调用 .so 库，更简洁。

---

五、Model File：测试头硬件的配置描述

Model File 是连接软件与硬件的关键文件，默认位于：

/etc/opt/hp93000/soc/tester.model

它描述了测试头（test head）上安装了哪些卡（card）、各卡的功能特性、以及这些卡到 DUT board 接口上 pogo block 的映射关系。此外，还指定了测试系统的参考时钟信号。

SmarTest 在启动时读取该文件：

• Online 模式 （光纤连接正常）：读取实际硬件，并在报告窗口中输出 MAXIMUM POSSIBLE CONFIGURATION 表
• Offline 模式（无硬件连接）：按 model file 定义的配置模拟运行

在典型安装中，tester.model 通常是一个软链接，指向 /etc/opt/hp93000/soc_common/tester.model，这样多版本的 SmarTest 可以共享同一个硬件描述文件。如果需要版本特定的配置，也可以在默认路径放一个真实文件。

---

总结

概念	一句话	关键约束
Workspace	工作根目录，管理项目引用和个人偏好	不可共享、版本绑定、不要把 Project 放在里面
Work Center	SmarTest 定制的 Eclipse IDE 主窗口	Perspective 配置绑定 Workspace
Project	测试程序及配置文件的存储单元	命名遵循 Java 风格，推荐引用而非复制共享
projects.map	Workspace 中所有 Project 的索引文件	纯文本 key=value，支持环境变量路径
Model File	描述测试头硬件配置	软件与硬件绑定的核心桥梁

下一篇将介绍 SmarTest 测试程序的整体架构，从 Test Program 到 Test Method 的四层层级结构。

---