3、测试流程介绍：CP测试、FT测试、测试程序加载、测试项分类归纳总结

做HS400量产测试这些年，我最大的感受是：流程就像流水线，每一站都有它非做不可的理由。CP、FT、程序加载、测试项分类，这四个词几乎天天挂在嘴边。但说实话，真正能把它们串起来讲清楚的人，不多。今天我就按自己实际产线上的经验，把这一套掰开揉碎了说说。

3.1 CP测试与FT测试：一对“孪生兄弟”，使命不同

很多刚入行的工程师容易把CP和FT混为一谈，觉得都是上电跑向量嘛。其实差远了。

CP（Chip Probing，晶圆测试）是在晶圆还没切割的时候进行的。探针卡直接扎到pad上，测的是裸die的电性能。为什么要在这一步测？说白了，就是早点把坏die揪出来。封装和测试都是成本，一个坏die送去封装，等于白花钱。我见过最夸张的案例——某批次晶圆边缘有划伤，CP阶段良率掉到60%，如果没有CP，后道FT根本承受不住那个浪费。

FT（Final Test，最终测试）是封装完成之后做的。这时候芯片有外壳、有引脚，测试条件更接近真实应用。FT会覆盖所有datasheet上的参数，包括极限电压、温度、频率等。CP只测功能基本项和部分DC参数，FT则要“全检”。

我个人的经验是：CP 像入学考试，FT 像毕业答辩。入学考试只筛掉完全不合格的，毕业答辩才决定你能不能拿到学位。

下表把两者的关键区别列出来，你直接参考：

对比项	CP 测试	FT 测试
测试阶段	晶圆级（未切割）	封装后
接触方式	探针与pad接触	Socket与引脚接触
测试项数量	较少（功能+部分DC）	完整参数（功能+AC/DC+极限）
测试速度	快（平行测试多）	相对慢（串行IO）
主要目的	早期筛选坏die	确保成品符合规格
良率影响	影响封装成本	直接决定出货良率

3.2 测试程序加载：测试的“大脑”不能搭错线

测试程序就是告诉测试机“怎么测、测什么、标准是多少”的指令集。一个HS400芯片的测试程序可能包含几十个pattern文件、上百个test class、一堆datalog设置。程序加载这一步看似简单，实际坑很多。

程序加载流程大致分三步：

1. 编译与校验：把C/C++/Python写的测试代码编译成机器码，并校验格式。我用的是Advantest T2000平台，每次改程序后必须跑“dry run”（空跑），否则真上片子时可能直接烧坏探针。
2. 装载到测试机：通过以太网或GPIB把程序下载到测试机本地硬盘。注意网络延迟！我曾经遇到过网线接触不良，下载到一半中断，导致程序不全——测试结果全是FAIL。
3. 资源分配：分配DIB板、socket、site数量、pattern内存等。这一步最容易忽略的是pattern内存上限。HS400的pattern很大，如果不预先算好，跑着跑着就报“pattern memory full”，整批次报废。

嗯，这里要注意：每个测试机的程序存储路径、命名规则、版本号管理一定要严格。我习惯用YYYYMMDD_vX.XX格式，并且在程序头加入CRC校验，防止传输过程出错。

3.3 测试项分类归纳：从“测什么”到“为什么测”

HS400的测试项少说也有两百多项。如果全部平均用力，测试时间根本承受不住。你必须学会分类归纳，把资源用在刀刃上。

我一般把测试项分成四大类：

• 功能测试（Functional Test）：验证芯片能不能按照设计正常工作。比如写一个寄存器、读回来对不对。这类测试跑得快，但覆盖率高。
• DC参数测试（DC Parametric）：测电压、电流、电阻等。比如VDD漏电流、IO高低电平阈值。这类测试最耗时，但良率敏感度最高——我90%的失效都是DC参数先暴露的。
• AC参数测试（AC Parametric）：测时序、频率、建立保持时间等。HS400的DDR接口部分就是典型例子，时序稍微偏一点就挂。
• Iddq测试（静态功耗电流）：专门测芯片休眠时的电流。很多人觉得Iddq不重要，其实它对工艺缺陷非常敏感。我曾经靠Iddq抓出一批氧化层漏电的wafer，避免了后续FT的灾难。

分类之后，你还得排序。我的策略是：先跑最有可能暴露问题的项，再跑费时的项。举个例子，先跑VDD短路测试（最快），如果直接短路，后面的测试全停，省时间。这叫“stop on first fail”。

3.4 避坑指南：那些年我踩过的雷

讲几个真实案例，每一条都是用工时和晶圆换来的教训。

• CP测试中探针清洁频率问题：我刚开始做量产时，以为探针扎几千次再清洁没事。结果某次测到一半，接触电阻突然飙升，导致整批die被判FAIL。后来我规定每2000次清洁一次，并自动记录探针接触电阻的变化趋势。
• FT测试中socket磨损：HS400封装脚数多，socket很容易弹力下降。我曾在量产中发现某个site一直报开短路，换了新socket就好了。从此我在程序里加了socket接触次数计数器，超过10万次自动报警。
• 测试程序版本打架：有一次新来的工程师误把开发版程序当成量产版上传，结果测试标准改了，整批良率从92%掉到15%。幸好及时发现，回滚版本，重新测试。这之后我强制要求程序版本必须经过双重签名——测试工程经理和NPI工程师各签一次。

流程清楚了，后面的事就好办。下一节我们会深入讲测试硬件——loadboard和socket的设计要点，那才是真正决定测试稳定性的根基。