当前位置: 首页 > news >正文

【芯片测试】: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 会在以下情况下结束:

  1. 正常完成(测量完毕,控制返回调用方)
  2. 所控制的仪器被断开
  3. Operating Sequence 执行完毕(非 keep-alive)
  4. Operating Sequence 中下一个元素使用了同一信号
  5. 用户显式调用终止

三、从 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

执行流程:

  1. Pattern 1 → Action 1 → Pattern 2(串行执行)
  2. 并行组 1 启动:Pattern 3 和 Pattern 4 同时开始
    • Pattern 3 完成 → Action 2 执行
    • Action 2 和 Pattern 4 都完成后 → Pattern 5 开始
  3. 并行组 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 vectors

Padding 对测试程序透明,但可能影响测试时间(特别是大量并行执行时)。

两种特殊模式

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 APIinitialize(),setup()程序化创建/修改配置文件(spec、operating sequence 等)
Device Test APIupdate(),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 SequencePattern 和 Action 的时序编排框架顺序组(串行)和并行组(同时启动)
Padding自动在短 Pattern 后补充 break vectors 以同步对程序透明,但影响性能
Test Method四个 Java 方法按不同执行阶段被调用initialize/setup/update/execute 各司其职

下一篇(终篇)将解析Test Program 的完整执行流程与状态机:从 activate 到 stop 的每个阶段、辅助 Testflow 的触发时机、内存管理与异常处理。


http://www.jsqmd.com/news/875517/

相关文章:

  • 新手避坑指南:在Ubuntu 22.04上从零搭建Plexe-SUMO自动驾驶仿真环境
  • 年薪50万必备技能:.NET云原生架构实战,3分钟部署全球可用的微服务
  • GE 和 Runtime:不是上下游,是协同决策
  • Midjourney --style raw + 调色板协同失效?3步诊断流程+4类硬件级色彩配置冲突解决方案
  • 反应坐标映射:非马尔可夫开放量子系统的高效模拟方法
  • B物理反常的全局拟合:有效场论与机器学习解析新物理信号
  • 神经材质:NeRF之后,下一代数字内容的“皮肤”革命
  • Harness Engineering:麻绳还是马绳
  • SVM在频繁模式挖掘中的应用:从高维稀疏数据中提取判别性关联规则
  • Leslie矩阵建模:从种群动力学到捕食竞争与机器学习拟合
  • 从《原神》到《黑神话》都在用的AI Agent中间件:轻量级推理框架v0.9.3内部测试版首次泄露(仅限前500名开发者)
  • 别急着重启!深入理解Ubuntu 22.04的needrestart:守护进程、库文件与系统更新背后的原理
  • Telnet与SSH协议安全本质对比:从明文传输到公钥认证
  • 神经阴影:当AI学会“画影子”,实时渲染的下一个突破口
  • KNO标度律与粒子多重数:从QCD喷注结构到夸克-胶子鉴别的理论推导
  • 从语义网到神经符号系统:知识图谱与LLM融合实战指南
  • 为什么你的MJ图总像“老胶片过曝”?揭秘ISO模拟算法缺陷,5种降颗粒参数组合实测对比(含LUT映射表)
  • Spark Transformer:稀疏激活优化与计算效率提升
  • 别再手动处理表格了!用PyQt6的QTableWidget自定义右键菜单,5分钟搞定复制粘贴与格式设置
  • 基于共享潜在空间的贝叶斯优化:解决异构算法超参数联合选择难题
  • ml_edm:基于成本敏感的时间序列早期分类Python工具包详解
  • Node.js版Frida实战指南:告别Python环境陷阱
  • 软共线因子化与IRC安全:从QCD发散到喷注算法的物理基础
  • 傅里叶变换与FFT:从信号处理到深度学习卷积加速的工程实践
  • 端侧智能与多模态传感:OmniBuds平台如何重塑下一代智能耳戴设备
  • 从DALL·E 3到Midjourney 6:对比度渲染引擎差异白皮书(附17组跨模型PSNR/SSIM实测数据)
  • 开源机器学习项目贡献者角色演化与社区健康度分析
  • 量子贝叶斯网络在环境监测中的应用:解决数据不平衡的油污检测
  • 虚幻引擎程序化体积云渲染:告别天气纹理,实现动态天空
  • Agent 状态持久化:基于 Redis 的多轮交互上下文存储方案