吞吐率基础：定义、关键指标
吞吐率这个词，说白了就是测试系统的出货速度。
你想想看，我们每天守在ATE机台前，盯着屏幕上的pass/fail结果，最关心的是什么？不是某个芯片测得多准，而是一天能出多少货。我早年刚入行时，总以为覆盖率越高越好，后来被产线经理追着问“你这条线的UPH（每小时产出）怎么又掉了？”才真正意识到，吞吐率才是量产测试的命门。
吞吐率定义：传送带的速度
在ATE领域，吞吐率（Throughput）指的是单位时间内，测试系统能够完成测试并输出的芯片数量。注意，这里强调“完成测试”，包括上下料、电性能测试、结果判定和数据存储的全过程。
用公式表示就是：
总吞吐量 = 并发工位数 × (3600秒 / 单颗芯片测试时间)
单位：颗/小时（UPH）
我习惯把ATE机台想象成一条流水线。每个测试位（Site）就是一个工位，测试时间就是工位处理一件产品的节拍。节拍越短，工位越多，产出自然就越高。但这个公式看着简单，实际落地时，很多坑就藏在这些变量里。
| 因素 | 对吞吐率的影响方向 | 你一定要注意的地方 |
|---|---|---|
| 测试时间（Test Time） | 越短，UPH越高 | 但时间太短可能漏掉缺陷 |
| 并发工位数（Parallel Sites） | 越多，UPH越高 | 但受限于机台资源和芯片Pin数 |
| 索引时间（Index Time） | 越短，UPH越高 | Handler/Prober的机械动作时间容易忽略 |
| 良率（Yield） | 越高，有效UPH越高 | 但良率来自工艺，测试能做的有限 |
关键指标一：测试时间（Test Time）
测试时间是最硬的指标。它决定了你的最低节拍。
你会问：“测试时间不就是跑完所有pattern的时间吗？”其实没那么简单。我在项目中踩过最深的坑，就是把pattern执行时间和总测试时间划等号。实际上，总测试时间包含：
- Pattern执行时间：ATE向量机跑scan、functional pattern的时间。
- DC/AC参数测试时间：每测一个参数，机台需要建立新的电平/时序条件，这个开销不小。
- Datalog传输时间：尤其是大量fail数据写log时，总线会卡住。
- 机台开销（Overhead）：包括向量加载、pattern跳转、结果比较。
我曾经优化过一个产品，把pattern执行时间压到了180ms，结果总测试时间还是到了230ms。一查，发现光是参数测试的set-up时间就占了25ms。后来我调整了测试顺序，把相同电压域的DC测试排在一起，减少电压切换次数，才把这部分降下来。
注意：不要盲目追求“零测试时间”。我见过有人为了压时间，把Iddq测试跳过了。结果出货后客户投诉漏电流超标，整批退货。测试时间是双刃剑，该测的不能省。
关键指标二：并发工位（Parallel Sites）
并发工位是吞吐率的杠杆。你增加一个site，理想情况下吞吐率翻倍。但现实是，你加的每个site，都会带来额外的开销。
我记得有一次调试一个128 pin的MCU项目。机台支持16 site并行，但实际跑到12 site时，测试时间反而变长了。后来我用scope抓了信号，发现是Site之间的串扰（Cross-talk）问题。高并行度下，相邻site的Pattern同时在跳变，导致电源噪声耦合进了测量结果，机台反复做retest才能通过，反而拖慢了整体节奏。
我的建议：确定并发数时，不要只看机台的理论最大值。先跑一个负载测试：用4 site、8 site、12 site分别测一批样本，看哪个配置下UPH最大。你可能会发现，某个并行数之后，测试时间会跳涨，那就是你的甜点区。
影响并发工位效率的因素包括：
- 测试通道资源竞争：每个site独立占用机台板卡资源，通道不足会阻塞。
- 电源供给能力：多site同时VDD/VDDQ供电，机台PMU的灌电流能力够不够？
- Handler/Prober对接时序：机械臂的取放动作能否跟上并行的节奏？
- DUT接触电阻一致性：socket磨损后，某些site接触不好，经常出现open/short假fail。
关键指标三：总吞吐量（Total Throughput）
总吞吐量是前面两个指标的乘积结果，但还受良率的影响。实际上，我们关心的不只是产出多少颗，而是产出多少颗好的。
所以有效吞吐量可以写成：
有效吞吐量 = 总吞吐量 × 测试良率
单位：颗好品/小时 （Good UPH）
这就带来一个有意思的权衡：覆盖率 vs 吞吐率。我的经验是，很多团队在项目初期拼命加测试项，导致测试时间膨胀，吞吐率暴跌；等量产节点到了，又疯狂裁测试项去压时间，覆盖率掉到离谱。
我的方法：先确定最低必要覆盖率。比如客户要求scan coverage > 95%，那你的pattern就不能砍到低于这个线。在这个前提下，再去优化测试时间。我习惯做一张测试项-时间-覆盖率的贡献度表，像下面这样，一眼就能看出哪些测试项是“时间黑洞”。
| 测试项 | 测试时间（ms） | 覆盖率贡献（%） | 时间效率（%/ms） |
|---|---|---|---|
| scan pattern1（logic） | 85 | 40% | 0.47 |
| scan pattern2（mem） | 60 | 25% | 0.42 |
| functional test1 | 120 | 12% | 0.10 |
| functional test2 | 200 | 8% | 0.04 |
看到没？functional test2 用了200ms，只贡献了8%的覆盖率，时间效率最低。这种测试项在量产时就要考虑，是不是能放到characterization阶段，或者转成BIST on-chip来做。我在一个客户项目里，就靠这张表，把测试时间从480ms砍到290ms，覆盖率只掉了1.2%，客户很满意。
为什么吞吐率这么重要？
说白了，测试是成本。每颗芯片多测1秒，乘上百万级的产量，那就是成千上万的测试机台使用费。我见过一些项目，芯片设计得很优秀，却因为测试方案没考虑吞吐率，导致量产成本比竞争对手高出一大截，最终丢掉了市场份额。
所以当你下次设计测试程序时，记得多问自己一句：“我这套方案，能不能在保证覆盖率的前提下，跑得更快？”