4、向量格式详解（STIL）：从结构到实战
各位工程师，大家好。今天我们来聊聊STIL格式。说实话，在ATE测试这个圈子里，STIL已经成了事实上的标准。我入行那会儿，各家EDA工具还各玩各的，后来大家发现，没有一个统一的格式，做DFT和ATE的同事天天吵架。STIL的出现，说白了就是让大家有个共同语言。
4.1 STIL文件结构：五根柱子撑起一片天
STIL文件的结构，我个人习惯把它拆成五个核心部分。你想想看，一个测试向量要跑起来，总得知道芯片长什么样、信号怎么走、时间怎么算、跑哪段程序、怎么分组执行吧？STIL就是干这个的。
核心五要素：
- Signals：定义芯片的管脚信号
- Timing：定义时序波形
- PatternExec：定义执行环境
- PatternBurst：定义向量分组
- Procedural Patterns：过程化向量（稍后细讲）
先看一个最简单的STIL文件骨架，我建议你把这个结构记在脑子里：
STIL 1.0 {
Signals {
// 管脚定义
}
Timing {
// 时序定义
}
PatternExec {
// 执行环境
}
PatternBurst {
// 向量分组
}
Pattern "pattern_name" {
// 向量内容
}
}嗯，这里要注意：STIL是大小写敏感的。我曾经在项目里吃过这个亏，一个同事把"Signals"写成了"signals"，结果仿真器直接报错，排查了半天。
4.2 Signals：管脚定义的艺术
Signals部分，说白了就是告诉测试机台：你的芯片有哪些管脚，每个管脚是输入、输出还是双向。我见过很多新手在这里犯迷糊，把电源管脚也定义成信号，结果测试时电流测量全乱套。
Signals {
// 输入信号
CLK In;
RESET In;
DATA InOut;
// 输出信号
Q Out;
// 电源和地（注意：不参与向量比较）
VDD Supply;
VSS Supply;
}我的经验：电源管脚一定要定义为Supply类型，否则ATE机台会把它当成普通IO去比较电平，那结果就完全不对了。另外，双向管脚（InOut）要特别小心，驱动和接收的切换时机必须精确控制。
4.3 Timing：时序是测试的灵魂
Timing部分定义了信号的波形。为什么说时序是灵魂？因为ATE测试本质上就是在特定时间点给信号、在特定时间点采结果。时序写错了，向量再漂亮也是白搭。
Timing "t1" {
WaveformTable {
// 定义时钟波形
CLK { 0: 0; 10: 1; 20: 0; }
// 定义数据波形
DATA { 0: D; @V: Compare; }
// 定义输出比较窗口
Q { 15: Compare(0,1); }
}
}这里有个坑，我必须要说。WaveformTable里的时间单位，默认是纳秒（ns）。但有些EDA工具导出时用的是皮秒（ps），如果你不检查，直接拿去用，时序就全乱了。我曾经在项目里遇到一个案例，客户说我们的测试向量跑不过，我一看，时序定义里写的是"1000: 1"，我以为是1000ns，结果是1000ps，差了整整1000倍。
避坑指南：拿到STIL文件后，第一件事就是检查Timing里的时间单位。如果文件头没有明确声明，默认是ns。但最好在Timing块里显式声明：Timing "t1" { TimeScale 1 ns; }
4.4 PatternExec：告诉机台怎么跑
PatternExec定义了测试执行的上下文。说白了，就是告诉ATE机台：用哪个时序、跑哪个向量组、要不要做shmoo、频率是多少。
PatternExec "exec1" {
Timing "t1";
PatternBurst "burst1";
// 可选参数
Category "func_test";
Frequency 100 MHz;
}我个人习惯把PatternExec写得尽量简洁，只放必要的参数。因为在实际量产中，PatternExec经常需要根据不同的测试项做微调，写得太复杂反而容易出错。
4.5 PatternBurst：向量分组管理
PatternBurst是STIL里一个非常实用的设计。它允许你把多个Pattern打包成一个组，然后一次性执行。这在量产测试中特别有用，比如你可以把功能测试、DC测试、AC测试分别打包。
PatternBurst "burst1" {
Pattern "func_test_1";
Pattern "func_test_2";
Pattern "dc_test_1";
Pattern "ac_test_1";
}注意：PatternBurst里的Pattern执行顺序是严格按定义来的。如果你需要跳转或循环，那就得用到过程化向量了。
4.6 过程化向量（Procedural Patterns）：让向量活起来
过程化向量是STIL最强大的特性之一。普通的Pattern是静态的，一条一条顺序执行。但过程化向量支持条件判断、循环、子程序调用，说白了，它让测试向量有了编程能力。
为什么会需要这个？你想想看，如果芯片有1000个寄存器需要配置，难道你要写1000条静态向量吗？那文件大小会爆炸。用过程化向量，一个循环就搞定了。
Pattern "config_registers" {
// 过程化向量示例
Procedure "write_reg" {
// 写寄存器子程序
V { DATA = 0x55; }
V { CLK = 1; }
V { CLK = 0; }
}
// 循环调用
Loop 100 {
Call "write_reg";
}
}我的经验：过程化向量虽然强大，但不要滥用。我见过有人把整个测试流程都写成过程化向量，结果调试时根本看不懂。我的建议是：只把重复性的操作（如寄存器配置、扫描链加载）写成过程化向量，核心功能测试还是用静态向量，这样可读性和可维护性都更好。
4.7 STIL与WGL的互转：兼容性那些事儿
WGL（Waveform Generation Language）是另一种常见的向量格式，主要用在一些老旧的EDA工具和ATE机台上。STIL和WGL之间的互转，说实话，是个老大难问题。
我整理了一个对比表，方便大家理解两者的差异：
| 特性 | STIL | WGL |
|---|---|---|
| 时序定义 | 支持多时序、多波形表 | 单一时序，波形定义较简单 |
| 过程化支持 | 原生支持（循环、条件、子程序） | 不支持，需外部脚本辅助 |
| 管脚定义 | 支持In/Out/InOut/Supply等 | 仅支持In/Out |
| 向量压缩 | 支持PatternBurst分组 | 不支持 |
| 兼容性 | IEEE标准，主流工具支持 | 逐渐被淘汰，部分老机台仍用 |
从STIL转WGL时，最容易出问题的是过程化向量。因为WGL不支持循环和条件，所以转换工具通常会把循环展开成静态向量。我曾经遇到一个案例，一个只有100行的STIL过程化向量，展开成WGL后变成了10万行，文件大小暴涨，加载时间从几秒变成了几分钟。
避坑指南：如果你必须做STIL到WGL的转换，我建议：
- 先检查转换工具是否支持过程化向量展开
- 转换后一定要做仿真验证，确保时序和逻辑没变
- 如果可能，尽量说服客户升级到支持STIL的ATE机台
反过来，从WGL转STIL时，问题相对少一些。因为STIL是超集，WGL能表达的东西STIL都能表达。但要注意，WGL里有些非标准的扩展语法，转换时可能会丢失信息。我建议转换后手动检查一下Timing和Signals部分。
4.8 本章小结
STIL格式，说白了就是一套标准化的测试向量描述语言。它的核心价值在于让DFT工程师和ATE工程师用同一种语言沟通。我个人觉得，掌握STIL的关键不在于背语法，而在于理解它的设计思想：信号、时序、执行环境、分组、过程化，这五个要素缺一不可。
至于STIL和WGL的互转，我的态度是：能不用就不用。如果非转不可，一定要做好验证。毕竟，测试向量是芯片量产的最后一关，出不得半点差错。