【芯片测试】：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 的区别

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

这意味着在 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 可以共享同一个硬件描述文件。如果需要版本特定的配置，也可以在默认路径放一个真实文件。

总结

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