3. 吞吐率优化方法：多工位并行、时分复用、负载均衡策略
吞吐率，说白了就是测试仪在单位时间能测多少颗芯片。我早年刚带ATE项目时，总觉得瓶颈在机台时钟频率上，后来才发现——真正拉开吞吐差距的，往往是调度策略和资源复用方式。
这一章我们聊三种经典优化方法。它们不是互斥的，实际项目中我经常组合着用。先搭框架，再谈细节。
3.1 多工位并行
多工位并行，就是一次同时测多颗芯片。你想想看，原来一次测一颗，现在一次测四颗，理想情况下吞吐率直接翻四倍。嗯，这里要注意“理想情况”这四个字——实际能提升多少，取决于工位间的资源冲突。
我在项目里遇到过最典型的情况：八工位并行，理论上8倍，但实际只有4倍不到。为什么？因为公用了一套电压电流源，测试器在切换工位时，每次都要重新建立测量环路。
实现多工位并行的几个关键步骤：
- 分时资源隔离——把独占资源（如高精密源表）分配给关键工位，其他工位用共享资源
- 并行执行模板——每个工位独立跑一套测试向量，互不等待
- 同步触发机制——所有工位在同一个时钟域内启动，避免时序偏移导致误判
我个人习惯的做法是：在项目初期先跑一轮“资源冲突扫描”，找出所有可能产生互锁的资源点。之后再设计并行方案，效率能高不少。
3.2 时分复用
时分复用，和“并行”正好互补。并行是空间上铺开，时分是时间上塞满。说白了，就是把测试器的空闲时间片利用起来。
还是举例子。你的测试器在测一颗芯片的ADC转换时间时，测量模块在等，CPU就在那空转。这时把CPU拿去做下一颗芯片的逻辑功能测试——这就是时分复用的典型场景。
总测试时间 = Σ(每个任务独占时间) - 可以重叠的时间
我的经验是，时分复用最关键的是“仲裁算法”。如果仲裁没做好，反而会因为频繁上下文切换，把吞吐率拖低。我曾经在某个项目里，为了让所有子模块都能抢到总线，设了个极其复杂的优先级队列。结果呢？切换开销占了总时间的30%，还不如顺序执行来得快。
后来我换成了简单的“时间片轮转”——每个子模块固定跑50微秒，到了立即切。简单粗暴，但吞吐率反而涨了15%。
// 伪代码：简单轮转仲裁
while (test_run) {
for (each_module in module_list) {
module.execute(50us); // 每个模块跑固定时间片
switch_to_next_module(); // 硬件上下文切换
}
yield_to_external_dma(); // 空闲时让给DMA传输
}3.3 负载均衡策略
负载均衡，说白了就是“不要让某颗芯片等太久，也不要让某个工位累到爆”。在ATE吞吐优化里，负载均衡通常分两层：
- 工位级负载均衡——各个工位的测试任务量，尽量分配均匀
- 模块级负载均衡——测试器内部各个测量模块的工作负载，调平
我在项目中遇到过最典型的负载不均：一个工位测CIS图像传感器，需要跑复杂的像素校准；另一个工位只测电源引脚短路。结果前一个工位跑45秒，后一个工位8秒就跑完了——后面空转37秒。
解决方案很简单：把长测试项和短测试项混搭。让每个工位都包含“一个大任务 + 几个小任务”，这样整体完成时间就按平均值收敛了。
这里给大家看一个方法和适用场景的对比表格：
| 优化方法 | 核心思想 | 适用场景 | 常见瓶颈 |
|---|---|---|---|
| 多工位并行 | 空间展开，同时测多颗 | 工位资源充裕、测试项目较长 | 电源/总线资源冲突 |
| 时分复用 | 时间填满，隐藏等待时间 | 测试中有明显空闲等待 | 切换开销过大 |
| 负载均衡 | 分配均匀，减少空转 | 工位间任务量差异大 | 长尾任务拖慢整体 |
3.4 整体逻辑框架
下面是我自己画的一个逻辑框架图。它把三种优化方法的关系和选择路径都串起来了，你看了就知道在项目中怎么下手。
框架逻辑很直白：先确认你当前吞吐率卡在哪，再选对应的优化路径。我个人习惯是先做一轮负载均衡扫描——这个投入最低，见效最快。如果负载已经平衡了，再考虑扩展工位并行，最后才上时分复用这类精细调度。