三、测试位（Site）与并行度：从单兵作战到集团冲锋
说实话，很多工程师刚开始接触ATE时，最容易忽视的就是Site这个概念。我记得自己第一次接触多site测试，还是在做一款电源管理芯片的时候。当时测一颗芯片要花好几秒，产能死活上不去。后来经验丰富的同事告诉我：“你为什么不一次测8颗？” 这才打开了我的新世界。
这一节，我们就来聊聊测试位（Site）和并行度的那些事儿。
3.1 什么是测试位（Site）？
Site，简单来说，就是一台测试机同时能测多少个芯片的“工位”。
一台ATE测试机，不一定只测一颗芯片。它可以有多个测试位。每个测试位就像是一个小房间，能独立测试一颗芯片。
举个直观的例子：
- 单Site测试： 一次只测1颗，测完换下一颗。
- 多Site测试： 一次同时测2颗、4颗、8颗甚至更多。
并行度（Parallelism）就是“同时测多少个”的意思。并行度 = N，就是一次测N颗。你想想看，如果单颗测试时间是60秒，并行度4，理论上你可以在60秒内测完4颗，效率直接提升4倍。
3.2 多Site测试的原理
多Site测试，听起来很美好。但实际做起来，不是简单地把一个Site复制N份。我个人习惯把多Site测试拆成三个核心模块：
- 共享硬件资源： 比如电源、时钟、测控总线。多个Site共用同一套底层，可以省成本，但要防止抢资源。
- 独立通道资源： 每个Site需要有独立的数字通道、模拟通道。这样测A芯片时，不会干扰B芯片。
- 软件调度： 测试程序要能支持并发执行，以及数据对齐。每个Site的测试结果要独立保存，不能混在一起。
说白了，多Site测试的本质是“共享底层，独立上层”。
我在项目中遇到过一个问题：同一个DUT（待测芯片）在不同Site上测出的结果不一致。后来发现是某个Site的电源接触不良，导致电压偏低。所以，Site之间的一致性验证，是必须要做的功课。
核心结论： 多Site测试的本质是“空间换时间”。用更多的测试位，换取更短的产线节拍时间（Test Time Per Unit, TTPU）。
3.3 Site数量与效率：不是越多越好
你可能会想：“那我一次测32颗、64颗，效率岂不是爆表？” 嗯，这里要注意：Site数量不是越高越好。
效率的公式其实很简单：
效率 = (总测试时间) / (单颗测试时间 × 总颗数)
或者反过来看：
吞吐率 (Units Per Hour, UPH) = (3600秒 / 并行测试周期时间) × 并行度但实际中，效率会被几个因素拉低：
| 因素 | 影响 | 我的建议 |
|---|---|---|
| Site间差异 | 不同Site的阻抗、路径长度不同，导至测试参数偏差 | 先做Site校准，差太多就别硬上 |
| 负载板设计 | 多Site导致PCB走线变长，信号完整性问题 | 记得做仿真，别等流片回来再哭 |
| 探针卡/插座 | 越多Site，探针卡成本越高，维护越麻烦 | 平衡一下投入产出比 |
| 良率损失 | 如果某个Site老出问题，整板跟着降效率 | 加Site健康度监控 |
避坑指南： 我曾经有一个项目，硬把2Site改成8Site，结果由于负载板设计没跟上，信号串扰严重，反而导致良率下降了5%。后来不得不降回4Site。所以，我建议从2Site或4Site起步，验证稳定后再考虑扩。
3.4 如何推算最优Site数？
没有通用的公式，但我个人习惯用三步骤来推：
- 第一步，查硬件限制： 你的ATE台子有多少数字通道、多少模拟通道？平均每个DUT需要多少通道？算一下最多能跑几个Site。
- 第二步，算时间开销： 多Site的并行测试周期时间 = max（单颗测试时间） + 额外并行开销（比如多Site同步、负载板切换）。如果并行开销太大，就没意义了。
- 第三步，观察良率拐点： 先跑2Site，看良率。再跑4Site，对比良率。如果良率掉了超过0.5%，就要怀疑是不是Site数太多了。
一个小技巧： 你可以用“效率饱和度”来判断。效率饱和度 = (实际UPH / 理论UPH)。如果饱和度低于75%，说明Site数可能不太合理，或者你的并行程序没写好。
3.5 并行度的实际案例
我还是拿那个电源管理芯片的项目来说。我们当时用了一款主流SOC测试机，单Site测试时间是4秒。但我发现测试机的数字通道资源很充足，就尝试了4Site并行。
结果呢？并行测试周期时间只增加到4.5秒。其中0.5秒是多了一个Site同步时间。
效率对比：
- 单Site： 1小时只能测 3600/4 = 900颗。
- 4Site并行： 1小时能测 (3600/4.5) × 4 = 3200颗。
效率提升了接近3.5倍！这就是多Site的威力。
但我也见过反面案例。有一次做RF芯片，每个Site之间需要独立的射频路径，而且相邻Site会串扰。硬跑4Site，良率从92%掉到84%。后来老老实实跑2Site，反而综合效率更高。
所以说，并行度不是算出来的，是调出来的。你得先跑起来，看数据，再决定扩还是降。
# 一个简单的效率评估思路（伪代码）
site_count = [1, 2, 4, 8]
for site in site_count:
t_cycle = measure_cycle_time(site) # 实际测到的周期时间
yield = measure_yield(site) # 实际良率
uph = (3600 / t_cycle) * site * yield / 100
print(f"{site}Site -> UPH: {uph}")我觉得，从1Site到2Site的收益最大，从2Site到4Site要看情况。再往上，就要掂量掂量投入产出比了。