3. FT 测试程序开发流程

FT（Final Test，最终测试）是芯片封装后、出货前的最后一道质量关卡。FT 测试程序开发遵循一套严谨的工程流程，确保测试覆盖率、执行效率与量产稳定性。本章将拆解从需求分析到 Release 的五个核心阶段，并给出每个阶段的关键交付物与常见陷阱。

3.1 需求分析

需求分析是 FT 程序开发的起点，目标是明确“测什么”和“怎么测”。输入通常来自三份文档：芯片数据手册（Datasheet）、测试规范（Test Specification）、客户特殊要求（Customer Specific Requirement）。

关键输出：测试需求矩阵（Test Requirement Matrix, TRM），包含测试项名称、测试条件、Pass/Fail 判据、测试时间预算。
输入文档 关键信息 常见问题
Datasheet 电气参数（VDD、ICC、VOH、VOL）、时序参数（tSU、tH、tCO） 参数范围过宽，需确认量产 guardband
Test Specification 测试模式、向量格式、ATE 资源分配 测试模式与 ATE 通道数不匹配
Customer Requirement 特殊 bin 分类、数据日志格式、良率报告模板 漏掉特殊 bin 定义导致客户拒收
经验提示：需求分析阶段至少与设计团队、产品工程师、ATE 硬件工程师各开一次对齐会。任何未澄清的歧义都会在调试阶段放大为 3–5 倍的工作量。

3.2 测试项定义

测试项定义将需求转化为可执行的测试序列。FT 测试项通常分为三大类：DC 参数测试、AC 时序测试、功能测试。每类测试项需要明确：测试方法、测试条件、测量通道、判据与 bin 映射。

FT 测试项分类与典型内容 DC 参数测试 • 接触测试（Contact Test） • 漏电流测试（IL） • 电源电流测试（IDD） • 输出高/低电平（VOH/VOL） • 输入高/低电平（VIH/VIL） • 短路测试（Short Test） AC 时序测试 • 建立时间（tSU） • 保持时间（tH） • 时钟到输出（tCO） • 上升/下降时间（tR/tF） • 传播延迟（tPD） • 频率测试（FMAX） 功能测试 • 扫描链测试（Scan） • 存储器 BIST • 模拟 IP 功能验证 • 边界扫描（JTAG） • 系统级功能向量 • 内建自测试（BIST）
避坑指南：测试项定义阶段最容易犯的错误是“过度测试”或“测试不足”。过度测试增加测试时间，降低产能；测试不足导致良率虚高，客户退货风险上升。建议使用 DPPM（Defective Parts Per Million） 目标反推测试项的必要性。

3.3 测试向量生成

测试向量（Test Vector）是 ATE 向 DUT 施加的激励信号序列。FT 测试向量通常由 EDA 工具（如 ATPG、FastScan、TetraMAX）自动生成，或由设计团队提供 WGL/STIL 格式的向量文件。

向量生成的关键步骤：

  1. 向量格式转换：将 EDA 输出的 WGL/STIL 转换为 ATE 平台支持的向量格式（如 Advantest 的 .PAT、Teradyne 的 .tst）。
  2. 向量压缩与优化：去除冗余向量，合并重复 pattern，减少向量深度以节省测试时间。
  3. 向量时序对齐：将向量中的时序信息与 ATE 的 timing set 匹配，确保边沿精度。
  4. 向量验证：在 ATE 离线仿真环境（如 Advantest TSS、Teradyne IG-XL Simulator）中预跑向量，检查波形完整性。
// 示例：WGL 向量片段（简化）
// 格式：时间 引脚名 状态
0.0ns  CLK  0
0.0ns  DATA 1
0.0ns  CS   1
5.0ns  CLK  1
10.0ns CLK  0
10.0ns DATA 0
15.0ns CLK  1
20.0ns CLK  0
20.0ns CS   0
// 注意：实际 WGL 文件包含更多时序和掩码信息
效率建议：向量生成后立即执行 向量覆盖率分析。如果功能测试的 stuck-at 覆盖率低于 95%，或 transition delay 覆盖率低于 85%，需要返回 EDA 工具补充向量。

3.4 程序编译与调试

程序编译将测试项定义和测试向量整合为 ATE 可执行的目标代码。不同 ATE 平台的编译流程差异较大，但核心步骤一致：

步骤 操作内容 典型工具/命令 输出产物
1. 测试程序框架搭建 创建测试 flow，定义 bin 映射、测试顺序、条件切换 IG-XL / STIL Editor .tpr / .prg 文件
2. 测试项代码编写 使用 ATE 平台脚本语言（如 IG-XL 的 OpenStar、Advantest 的 C++ API）实现测试算法 OpenStar / C++ Compiler .dll / .so 动态库
3. 向量加载与时序绑定 将向量文件与 timing set、level set 绑定 Pattern Loader .pat / .vec 二进制
4. 编译与链接 将测试项代码、向量、配置链接为完整程序 Makefile / IDE Build 可执行测试程序
5. 离线仿真 在无硬件环境下模拟测试执行，检查语法和逻辑错误 TSS / Simulator 仿真日志
6. 硬件调试 连接 ATE 测试头与 DUT 板，单步执行测试项，观察波形与测量值 Debugger / Scope 调试报告
FT 程序编译与调试流程 框架搭建 代码编写 向量加载 编译链接 离线仿真 硬件调试 红色虚线：调试失败 返回修改代码
调试阶段常见问题：
  • 接触不良：DUT 板探针氧化或压力不足，导致接触测试失败。建议每次调试前执行 接触测试自检。
  • 时序冲突：向量中的边沿位置与 ATE 的 timing set 不匹配，导致功能测试误判。使用 shmoo 图 定位时序窗口。
  • 电源噪声：大电流测试项（如 IDD）导致 DUT 电压跌落。在测试项之间插入 settling time 或增加去耦电容。

3.5 Release 流程

Release 是 FT 测试程序从开发环境进入量产环境的最终关卡。Release 流程必须包含 版本控制、评审、验证、签核 四个环节。

环节 操作 参与角色 交付物
版本控制 将程序代码、向量、配置文件提交至 Git/SVN，打 Tag 测试开发工程师 Release Tag（如 v1.2.0）
技术评审 检查测试项覆盖率、测试时间、bin 映射、异常处理 测试开发 + 产品工程师 评审纪要 + 修改清单
量产验证 在量产 ATE 上跑 3–5 批小批量（如 1000 颗/批），对比良率与参数分布 测试开发 + 量产工程师 验证报告（含 CPK、良率、DPPM）
签核 所有问题关闭后，由测试经理和产品经理签署 Release 确认单 测试经理 + 产品经理 Release 签核单 + 最终程序包
Release 签核流程 版本控制 Git Tag v1.2.0 技术评审 覆盖率/时间/异常 量产验证 3–5 批 × 1000 颗 签核 经理签署确认单 任何环节发现问题 → 返回对应阶段修复 → 重新执行后续流程
Release 最佳实践：
  • 每次 Release 前执行 回归测试，确保新版本未破坏已有测试项。
  • 保留 Release 基线，量产中一旦出现异常可快速回滚到上一稳定版本。
  • Release 包应包含：可执行程序、向量文件、配置文件、Release notes、验证报告。

FT 测试程序开发的五个阶段环环相扣，任何阶段的疏忽都会在后续阶段被放大。严格按照流程执行，并保留完整的文档与版本记录，是保障量产测试质量的基础。

← 上一章 📖 返回目录 下一章 →