【芯片测试】:7. Action 与 Operating Sequence
Action 与 Operating Sequence:测试执行的时序编排
系列:Advantest V93000 SmarTest 8 核心概念解析|第 7 篇(共 8 篇)
适合读者:需要理解 ATE 测试执行编排机制的工程师
前言
前几篇讲了测试数据(Pattern、Spec、DUT Board),本篇讲执行:仪器动作(Action)怎么被触发,Pattern 和 Action 如何在时间轴上编排,Test Method 在什么时候执行什么代码。
这是把所有配置"接通电源"的一环。
一、Action:仪器的可触发操作
Action 定义了一个仪器可以执行的单个操作,例如:
- 施加一个电压(
forceVoltage) - 测量一个电流(
measureCurrent) - 输出一段波形(
sourceWaveform) - 修改一个仪器状态参数(
modPower)
Action 在 Measurement Specification(.spec)文件中定义,作为仪器配置的一部分。
触发 Action 的三种方式
| 触发方式 | 说明 |
|---|---|
| Test Method | 在 Java 代码中显式创建并调用(通过 Device Test API) |
| Pattern | 锚点(Anchor)绑定到 Pattern 的某个向量,该向量执行时 Action 被触发 |
| Operating Sequence | 直接列在 Operating Sequence 中,按位置顺序执行 |
二、Action 的生命周期
Action 的执行不是瞬间的——它有四个阶段,理解这些阶段对于编写精确的同步测试至关重要。
四个阶段
时间轴 ─────────────────────────────────────────────────► Preparation Begin Intended Begin Begin End Deactivation ↓ ↓ ↓ ↓ ↓ ├──── Preparation ─────────├── Activation ─├─ Execution ─├─ Cool-down ─┤ (硬件准备) (对齐暖机) (实际执行) (解锁资源)| 阶段 | 中文名 | 说明 |
|---|---|---|
| Preparation | 准备阶段 | 仪器配置自身硬件,例如校准内部电路 |
| Activation(Warm-up) | 激活阶段 | 等待到精确的时间对齐点,确保执行开始的时刻正确 |
| Execution | 执行阶段 | Action 正式执行(施加激励、采集测量结果等) |
| Deactivation(Cool-down) | 去激活阶段 | 执行结束到仪器释放可用(让出给下一个操作) |
Preparation 和 Deactivation 的时长由系统内部根据测试套件编程自动计算,不能手动指定,也不能通过 Action 类型直接得知。
关键约束:一个 Action 的仪器设置在执行期间不能被修改,直到该 Action 执行完毕或被显式终止。
重复执行的 Action
一个 Action 可以被配置为重复执行(有限次数或无限循环):
有限重复(repeatCount):
// 在 spec 文件中,某个 action 的配置 repeatCount = 10; // 执行 10 次对于有限重复,每次执行都包含独立的 Preparation 阶段。原文 Timing Debug 视图的示例(action 重复 2 次,共 3 次执行)给出了印证:
总时间 = 3 × (Preparation + Execution) = 3 × (320,000 ns + 150,000 ns) = 1,410,000 ns即每次重复均有完整的 Preparation + Execution 流程:
[Prep + Exec] → [Prep + Exec] → ... → [Prep + Exec] → Deactivation ↑_____________________________ N 次 _____________________________↑无限重复(keep-alive 或 infinite loop):
与有限重复不同,对于无限重复的 Action,Preparation、Activation、Deactivation 在整个循环生命周期内只发生一次:
Preparation → Activation → [Execution → Execution → ...(无限)] ↑_________直到被终止_________↑ → Deactivation适用场景:持续向 DUT 施加某个电压、持续发送时钟保活信号等。无限循环在以下任一条件满足时自动终止:
- 仪器被断开连接
- Operating Sequence 的下一个 Parallel Group 开始使用该仪器
- Operating Sequence 结束(除非 action 在 keep-alive context 中)
Keep-alive Context:可以让某些无限重复的 Action 在一次测量(Operating Sequence)结束后继续执行,用于维持持续的偏置电压或时钟信号,跨越多个测试套件的执行边界。
Action 的终止条件
一个 Action 会在以下情况下结束:
- 正常完成(测量完毕,控制返回调用方)
- 所控制的仪器被断开
- Operating Sequence 执行完毕(非 keep-alive)
- Operating Sequence 中下一个元素使用了同一信号
- 用户显式调用终止
三、从 Pattern 触发 Action:锚点机制
Pattern 和 Action 可以通过**锚点(Anchor)**精确关联——某个 Action 在 Pattern 的特定向量被执行时触发。
两种类型:中断型 vs 非中断型
中断型(Interruptive)Action:
Action 与 Pattern 使用相同的信号,Pattern 必须暂停,等待 Action 完成后才能继续:
Pattern 执行: → → → [向量 n-1 完成] → 暂停 → [Action_A 执行完] → [向量 n 开始]非中断型(Non-interruptive)Action:
Action 与 Pattern 使用不同的信号,Pattern 不需要暂停,Action 与向量同时开始执行:
Pattern 执行: → → → [向量 2 开始同时触发 Action_B] → → →(Pattern 继续不停) Action_B 执行: [Action_B 开始] →→→→→→→→→→→→→→→→ [Action_B 结束] (两者同时进行)Pattern 锚点的 XML 格式
<!-- 单个 Action 锚点,中断型 --><Program><Anchorvector="191"anchoring="interruptive"><Instrumentid="VCC1,VCC2,GND"><Instructionid="actionCall"value="ppmuIfVm1"/></Instrument></Anchor></Program><!-- 多个 Action 并行锚点(同一向量触发多个 Action) --><Anchorvector="191"anchoring="interruptive"><Instrumentid='pin01'><Instructionid="actionCall"value="action01"/></Instrument></Anchor><Anchorvector="191"anchoring="interruptive"><Instrumentid='pin02'><Instructionid="actionCall"value="action02"/></Instrument></Anchor>Narrowing:指定 Action 作用的信号子集
默认情况下,一个 Action 作用于其仪器设置中指定的所有信号。使用Narrowing可以限定 Action 只作用于部分信号:
// 在 Operating Sequence 中指定 narrowing actionCall myAction VCC1 + VCC2; // 只对 VCC1 和 VCC2 执行四、Operating Sequence:测试执行的时序乐谱
Operating Sequence(操作序列)是 Pattern 和 Action 的高层时序编排框架,用.seq文件描述。它回答一个问题:这些激励和测量动作,以什么顺序、什么时间关系执行?
两种基本组:顺序与并行
Sequential Group(顺序组):内部元素依次执行,前一个结束后才开始下一个。可以包含:
- Pattern
- Action
- Wait(延迟)
- 嵌套的 Parallel Group
Parallel Group(并行组):内部的所有 Sequential Group 同时启动。只能包含 Sequential Group(不能直接包含 Pattern 或 Action)。
嵌套规则:
- Parallel Group ⊂ Sequential Group ⊂ Parallel Group ⊂ …(可以无限嵌套)
- Sequential Group 不能直接包含 Sequential Group
- Parallel Group 不能直接包含 Parallel Group
一个执行步骤示例
Operating Sequence: [顺序组 1] - Pattern 1 - Action 1 - Pattern 2 - [并行组 1] [顺序组 2]: Pattern 3 → Action 2 [顺序组 3]: Pattern 4 - Pattern 5 - [并行组 2] [顺序组 4]: Pattern 6 [顺序组 5]: Pattern 7(含 Action 3 锚点) → Action 4执行流程:
- Pattern 1 → Action 1 → Pattern 2(串行执行)
- 并行组 1 启动:Pattern 3 和 Pattern 4 同时开始
- Pattern 3 完成 → Action 2 执行
- Action 2 和 Pattern 4 都完成后 → Pattern 5 开始
- 并行组 2 启动:Pattern 6 和 Pattern 7 同时开始
- Pattern 7 执行到锚点 → Action 3 触发(属于 Pattern 的锚点,不属于并行组的顺序元素)
- Action 4 与 Pattern 6/7 的并行逻辑执行
同步机制
Operating Sequence 提供三种同步手段:
① Parallel Group(最常用)
确保多个顺序组同时开始。系统会自动在较短的组后面插入 padding(break vectors)使其与较长的组对齐。
② Anchored Action
通过 Pattern 锚点,在特定向量时刻触发 Action,实现与 Pattern 内部的精确时间绑定。
③ Wait Element
在顺序组中插入固定时间的延迟,用于等待 DUT 稳定或满足协议时序要求:
// 在 Operating Sequence 中 patternCall "mySetupPattern.pat" wait 1ms // 等待 1ms DUT 建立稳定 actionCall myDcMeas注意:当wait之后紧跟 action 时,action 的 preparation 和 activation 不能与wait前的元素重叠,这可能导致 action 的执行被延迟。如有精确时序要求,应使用 anchored action 而非 wait。
Padding(自动填充)
当并行执行的多个 Pattern 长度不同时,系统自动在短 Pattern 的信号上补充 break vectors(填充),直到所有并行 Pattern 都执行完毕:
Pattern A(长):[XXXXXXXXXXXXXXXXXXXX...] Pattern B(短):[YYYYYYY][padding......] ← 自动填充 break vectorsPadding 对测试程序透明,但可能影响测试时间(特别是大量并行执行时)。
两种特殊模式
Burst Operating Sequence:仅调用其他 Operating Sequence,不含标准结构,执行速度更快(SmartBurst 功能)。
Burstable Operating Sequence:标准 Operating Sequence,但满足特定限制以允许被 Burst OS 调用。
五、Test Method:Java 代码的四个生命周期方法
Test Method 是一个继承自TestMethod的 Java 类,有四个可重写的方法,分别在不同的执行状态中被调用。
publicclassMyFunctionalTestextendsTestMethod{// 可选:在 activated → loaded 转换早期执行@Overridepublicvoidinitialize(){// 设置测试描述符的默认值// 这些值可以被 test table 的 PreBind 阶段覆盖}// 可选:在 PreBind 执行后,activated → loaded 转换后期执行@Overridepublicvoidsetup(){// 用 Device Setup API 程序化创建配置文件// 优先级高于文件中的配置}// 可选:在 loaded → bound 转换中执行@Overridepublicvoidupdate(){// 用 Device Test API 修改内存中的测试数据// 不影响原始配置文件}// 必须实现:在 testflow running 状态中执行@Overridepublicvoidexecute(){// 执行测量,评估结果,记录日志// 使用 Device Test API}}四个方法的执行时机与职责
| 方法 | 执行时机 | 可以做什么 |
|---|---|---|
initialize() | activated → loaded(早期),PreBind 之前 | 设置测试描述符默认值;这些值可以被 test table 覆盖 |
setup() | activated → loaded(后期),PreBind 之后 | 用 Device Setup API 程序化创建/覆盖配置文件中的设置 |
update() | loaded → bound | 用 Device Test API 修改内存中的测试数据(不改源文件) |
execute() | testflow running | 执行测量、判断 pass/fail、记录日志 |
不同方法之间的优先级:
文件中的配置(.spec 等) ↓ 被 setup() 覆盖 ↓ 被 update() 进一步修改(仅内存) ↓ execute() 实际运行三套 API 及其职责
| API | 用于哪个方法 | 职责 |
|---|---|---|
| Device Setup API | initialize(),setup() | 程序化创建/修改配置文件(spec、operating sequence 等) |
| Device Test API | update(),execute() | 执行测量、修改内存数据、获取结果 |
| SSF API | 由 Device Setup API 内部使用 | 生成/修改 SmarTest Setup Format 文件;也可在外部工具中使用 |
额外的 RF Demodulation API提供 RF 信号解调功能,适用于无线测试场景。
Executor Method:Test Suite 的高层控制器
除 Test Method 外,SmarTest 还提供Executor Method,它继承自ExecutorMethod类。与 Test Method 的区别在于,Executor Method 不仅控制测量,还可以控制 Test Suite 的执行:
publicclassSomeCustomExecutorMethodextendsExecutorMethod{publicStringtargetSuite="Main.SubFlow.SomeSuite";@Overridepublicvoidexecute(){ISuiteAccessaSuite=context.getSuiteAccess(targetSuite);// 修改 Test Suite 的参数IParameterAccessaParameter=aSuite.getParameter("aParameter");aParameter.setValue(2.0);// 执行 Test SuiteaSuite.execute();}}六、Wait Time:仪器动作的等待时间
每个 Action 可以配置一个wait time,指定动作执行阶段的最短持续时间:
- 对于电流/电压强制(force)动作:wait time 是强制信号保持的最短时间
- 对于测量(measure)动作:wait time 是激励稳定后到采样时刻的延迟
典型应用场景:
- DUT board 上的 relay 切换时间(通常几十 ms)
- DPS 范围切换或去合并(unganging)的建立时间
- DUT 内部电容充电所需的建立时间
- 测量路径切换后的稳定等待
// 在 spec 文件中,为某个 action 设置等待时间 action myIfvm { iforce = 1mA; waitTime = 1ms; // 电流强制后等待 1ms 再结束 }总结
| 概念 | 一句话 | 关键点 |
|---|---|---|
| Action | 仪器的单个可触发操作 | 定义在.spec,从 Test Method/Pattern/OS 触发 |
| Action 生命周期 | 四阶段:Preparation→Activation→Execution→Deactivation | 仪器在执行期间不可被修改 |
| Pattern Anchor | 将 Action 绑定到 Pattern 的特定向量 | 中断型(同信号)vs 非中断型(不同信号) |
| Operating Sequence | Pattern 和 Action 的时序编排框架 | 顺序组(串行)和并行组(同时启动) |
| Padding | 自动在短 Pattern 后补充 break vectors 以同步 | 对程序透明,但影响性能 |
| Test Method | 四个 Java 方法按不同执行阶段被调用 | initialize/setup/update/execute 各司其职 |
下一篇(终篇)将解析Test Program 的完整执行流程与状态机:从 activate 到 stop 的每个阶段、辅助 Testflow 的触发时机、内存管理与异常处理。
