1. 项目背景一个量产爬坡期的“灵异”良率波动先交代下项目背景。去年我接手了一颗电源管理芯片PMIC的量产测试项目工艺节点是180nm BCD封装是QFN40单颗芯片集成了3路DCDC和5路LDO外加一堆保护功能。这颗芯片在ATE自动测试设备上跑了三个多月测试程序是前任留下的加急上线那种基本功能项都覆盖了但量产数据始终不太好看——不是那种“良率太低没法出货”的难看而是“每个lot的良率忽上忽下找不到规律”的诡异感。同一片晶圆前道CP的良率明明稳定在96%以上到了FT最终测试阶段有些批次能掉到91%有些批次又正常。更头疼的是客户端偶尔会退回几颗早期失效的样片失效模式集中在LDO输出电压漂移。当时团队里有两种声音一种是怀疑测试程序覆盖不够漏掉了某些模拟参数的极端情况另一种是觉得封装厂工艺波动大芯片本身的可靠性分布有问题。我一开始也在这两个方向上折腾加过测试项、调过温度循环的筛选条件效果都不明显。后来我仔细把几个批次的全参数测试数据拉出来做了分布比对才意识到问题根本不在“测没测出来”上而在于测试程序里缺少一个关键环节——PATPart Average Testing良率统计测试控制。这就是这篇博文想分享的核心。芯片测试这件事很多人以为把测试项写好、上下限设对、跑通流程就算完事实际上量产测试真正考验的是数据管理和统计筛选能力。一颗芯片在ATE上测出来的参数落在规格书范围内不代表这颗芯片就可靠它还需要跟同一批次的芯片做横向比对那些“在规格内但明显偏离群体分布”的个体恰恰是早期失效的高发区。PAT控制就是干这个的。如果你正在做芯片测试或者刚入门ATE测试程序开发这篇文章里踩过的坑、调过的参数、排过的故障应该能帮你少走不少弯路。2. 芯片测试的整体设计CP和FT怎么分工测试程序怎么搭2.1 为什么一道测试根本不够用芯片测试分两道CPChip Probing晶圆测试和FTFinal Test成品测试。CP是在晶圆上用探针卡扎到每个die的pad上通电测试测完把坏的用墨点标出来或者干脆记录在map文件里后续封装时跳过坏die。FT是芯片封装完之后在分选机上把芯片一颗颗放进测试座里测。很多人问过我既然FT测得更准为什么还要多花一道CP的钱原因有几方面。第一成本控制。封装一颗坏芯片进去材料和工时都是浪费尤其QFN这种封装框架成本不低一颗die的封装成本合到几毛钱到几块钱人民币不等CP先把坏die筛掉能省下这笔冤枉钱。第二工艺反馈的速度。CP测完的数据可以直接反馈到前道工艺线哪个die区域周边出现cluster失效大概率是工艺缺陷可以指导良率改善。这个信息反馈链路如果拖到FT才建立周期太长产线上可能已经连续投了好几批问题晶圆。第三有些参数必须在晶圆阶段测。比如某些模拟芯片的基准电压微调trim必须在探针台上完成激光修调或熔丝修调封装之后的物理结构和应力状态会变这时候再修调就不准了。FT的定位则是最终质量把关。封装过程会引入新的失效模式比如打线bonding开路、塑封体应力导致内部结构微裂纹、引线框架短路等这些只能在封装完成后通过FT检查出来。另外FT测试条件和CP也有差异比如FT会做更严格的温度测试常温、高温、低温三温测试CP阶段因为探针接触压力大、测试时间长会导致晶圆局部升温温度控制难度高一般不做过高温度的老化筛选。2.2 测试程序的核心模块拆解一个完整的ATE测试程序不管用的是泰瑞达Teradyne的UltraFlex/J750、爱德万Advantest的V93000还是国产的胜达克、宏邦逻辑架构上都包含这么几块测试项目Test Items每一个测试项对应一个参数测量比如开短路测试Open/Short Test、电源电流测试IDD/ICC、输出电压精度测试、线性调整率测试Line Regulation、负载调整率测试Load Regulation、纹波抑制比测试PSRR等。每个测试项又包含好几个子步骤比如先给DUT上电配置成特定模式等信号稳定后再量测。测试流程Test Flow测试项按照特定顺序排列中间还有判断逻辑。比如某项测试失败了是直接判Fail终止还是跳过一个依赖项继续测剩下的。流程里还可以插入bin分选逻辑把不同失效模式的芯片分到不同的bin里方便后端分析失效根因。测试限值Test Limits这里分datasheet limit规格书限值来自设计规格和test limit测试限值通常比规格书限值更严格给量产留出裕量。测试限值的设定很有讲究设太严会把好芯片误杀设太松又起不到筛选作用一般要根据CpK/Cp数据来定。数据处理和统计Data Log Statistics每个测试项的测量结果都要记录下来输出成数据文件datalog。量产阶段这些数据会汇总到良率管理系统YMS里做SPC监控。我当时接手的测试程序前三个模块都有唯独数据处理这块比较薄弱。测试项的上下限是按datasheet设的规格内就Pass规格外就Fail完全没有做参数分布的统计分析和批次间的横向比对。这也是PAT控制的引入点。3. PAT控制到底是什么以及量产测试为什么要非做不可3.1 PAT控制的基本原理和工程意义PAT全称是Part Average Testing有些资料里也叫“良率统计测试”或“参数均值测试”。它的核心思想用一句话概括不仅看单颗芯片的参数是否在绝对规格内还要看这颗芯片的参数是否偏离了同批次芯片的整体分布。具体实现是对一批芯片通常是同一个lot、同一片晶圆或者同一个测试批次的某个测试参数先统计出均值和标准差然后计算统计上下限再拿这个统计限值去筛选每一颗芯片。凡是在统计上下限范围之外的都判定为“边缘个体”虽然它们的参数可能在绝对规格内但存在生产异常的风险通常会被降级、标记或者直接Fail。这样做背后的逻辑是半导体制造工艺的统计学特性。工艺波动是天然的掺杂浓度、氧化层厚度、光刻对准偏差都会有随机涨落而且大部分工艺参数的分布是近似正态的。同一批次的芯片如果某项参数跟整体分布差了好几个标准差说明这颗芯片经历的工艺条件大概率偏离了正常范围可能对应着某种潜在的物理缺陷。这类芯片在出厂时可能还是好的但工作一段时间后缺陷会逐渐演化成功能性失效也就是我们常说的“早期失效率”Early Failure Rate偏高。业界标准的做法参照AEC-Q004汽车电子委员会的可靠性指南里面的推荐PAT已经是车规级芯片的强制要求了。消费类芯片虽然没到强制的地步但手机、通信这类对可靠性要求高的场景客户也会在规格书里明确提出PAT要求。我做的这颗PMIC客户在最初的产品spec里其实写了一句“PAT shall be performed”但这份文档在前任手上没被重视造了一堆后账。3.2 PAT控制的两类实现方式动态PAT和静态PATPAT控制在实际落地时有两种流派工程上按统计基准的不同来区分。动态PATDynamic PAT统计的均值和标准差不是提前算好的而是边测边算——当前这个测试批次lot测完前几十颗芯片后程序实时算出这批芯片的参数分布再以此为准判别后续芯片。动态PAT的优点是自适应能力强能跟上工艺漂移的趋势。比如夏季和冬季的环境温湿度差异、不同晶圆批次之间的自然偏移这些系统性的波动动态PAT都能自动消化掉。但缺点也很明显——如果某个批次恰好存在大规模的失效集中比如一批晶圆都偏了那它计算出来的基准本身就有偏差反而可能把正常的芯片误杀。而且动态PAT在样本量小的时候统计不稳定第一批刚开始测的时候测试程序还没积累足够数据容易乱杀。静态PATStatic PAT统计基准在测试程序发布之前就确定好了用的是工程验证阶段积累的黄金批次golden lot数据把那些数据的均值和标准差固化进测试程序。此后不管来了什么批次都拿这套固定的统计限值去筛。静态PAT的优点是稳定、可复现不会出现同一个型号的芯片这周能过、下周不能过的抽风现象。缺点是要定期回顾这些限值因为工艺不可能永远不变跑半年之后原基准可能已经不适应当前的工艺水平了需要定期用新数据刷新基准。我在这个项目里最终采用的是动态PAT为主、静态PAT为辅的混合策略测试系统里同时跑两套统计逻辑动态PAT负责实时捕捉异常批次静态PAT主要用来监控工艺漂移趋势。两套逻辑如果同时触发Fail这颗芯片判Fail没什么可争议的只有动态PAT判断Fail而静态PAT判断Pass的芯片会流入一个特殊的“review bin”由良率工程师定期人工复核。3.3 PAT触发方式和参数选择的关键考量PAT不是对所有的测试参数都做的。理论上每个测试项都能算PAT但工程上只挑那些对可靠性敏感的、物理上容易出问题的参数来做。我在实际项目中选PAT参数是有优先级的第一优先级是模拟输出电压和基准电压类参数。这类参数直接反映了带隙基准bandgap和内部LDO的工艺匹配情况对掺杂浓度和应力极其敏感是最容易发生早期漂移的指标。我项目里的LDO输出电压项是必做的PAT对象。第二优先级是静态功耗电流IDD/Iq类参数。漏电异常往往跟栅氧化层缺陷、掺杂异常直接相关这类缺陷在高温工作下会被放大。第三优先级是那些跟封装和pin脚接触相关的参数比如开短路测试的钳位电压值。这类参数本身不代表芯片核心性能但它的异常分布可能暗示打线工艺的异常趋势做PAT监控可以帮助发现封装环节的系统性问题比如某一批框架的镀层厚度不均。PAT参数选定之后还有个关键细节一个参数如果同一个die上有多路通道比如5路LDO各有各的输出电压那PAT统计的对象到底是每一路独立算还是5路电压算一个综合统计量我这次的做法是各路独立算因为5路LDO在die上的物理位置不同工艺偏差的敏感度方向不一样混在一起算只会把统计模型的灵敏度拉低。标准差的倍数K值设定也是门学问。业界惯用的K值是6也就是6σ法则意味着统计上只有百万分之几的芯片会被随机误杀但如果芯片参数分布本身就是偏态的、厚尾的实际误杀率会比理论上高不少。我项目里有一项参数的分布明显是双峰的6σ的动态PAT会把侧峰上的一部分边缘芯片全部杀掉这部分芯片良率损失接近2%。后来我把这一项的K值放宽到7再配合静态PAT的交叉验证误杀率才压下来。关于这个坑后面第5节单独展开。4. 实战记录测试程序搭建、PAT代码实现和量产导入流程4.1 测试系统架构和硬件配置先列一下我用的测试平台配置给大家一个参考。ATE用的是泰瑞达J750系列这是目前市场上做PMIC、MCU、逻辑芯片测试的主力机型模拟混合信号测试能力强机台产能高。DUT板Device Under Test Board也叫load board上集成了DUT供电单元DPS、精密测量单元PMU、模拟波形发生器等资源。探针台和分选机分别应用于CP和FT阶段。CP用的是东京精密Accretech的UF3000搭配悬臂式或垂直式探针卡probe card针数大概300pin因为PMIC的pad间距不大用的探针是垂直式的接触稳定性比悬臂式好很多。FT用的分选机是鸿劲科技Hon Tech的一款三温分选机支持常温、高温125℃、低温-40℃三温度循环测试。测试程序语言用的是泰瑞达的IG-XL框架底层脚本是VB.NET。IG-XL有个好处是模块化和面向对象编程测试项可以封装成一个独立的test method数据流、结果判断和统计逻辑能分成不同层级来管理。PAT的逻辑我用的是一个自定义的test method在测试主流程里作为后处理环节调用。4.2 PAT控制逻辑的代码实现示例这里给出一个简化版的PAT核心逻辑代码用类Python伪代码写方便大家理解实现思路。实际工程中在IG-XL里是用VB.NET或者C#写的但逻辑本质是一样的import numpy as np from collections import deque class DynamicPAT: def __init__(self, test_name, k_value6.0, min_sample_size25, max_sample_size512): self.test_name test_name self.k_value k_value # PAT触发系数通常取6 self.min_sample min_sample_size # 最少样本量少于这个数不触发PAT self.max_sample max_sample_size # 滑动窗口大小超出后丢弃旧样本 self.history deque(maxlenmax_sample) self.mean None self.std None self.pat_upper_limit None self.pat_lower_limit None def update_statistics(self, new_value): self.history.append(new_value) if len(self.history) self.min_sample: return None # 数据量不够暂时不启用PAT # 剔除前本身就在两端极端的异常点避免统计基准被污染 values np.array(self.history) q1, q3 np.percentile(values, [25, 75]) iqr q3 - q1 mask (values q1 - 1.5*iqr) (values q3 1.5*iqr) clean_values values[mask] self.mean np.mean(clean_values) self.std np.std(clean_values, ddof1) # 防止标准差为0导致除法异常 if self.std 1e-12: self.std 1e-12 self.pat_upper_limit self.mean self.k_value * self.std self.pat_lower_limit self.mean - self.k_value * self.std return (self.pat_lower_limit, self.pat_upper_limit) def evaluate(self, dut_value): if self.pat_upper_limit is None: return 0 # 未触发统计模式直接放行 if dut_value self.pat_upper_limit or dut_value self.pat_lower_limit: return 1 # PAT Fail判为边缘个体 return 0 # PAT Pass这段代码里有几个细节值得提一下。一是滑动窗口sliding window的设计。动态PAT需要实时更新统计基准但如果把所有历史数据都放进去早期工艺状态跟当前状态差异太大统计基准会失真。我设置的窗口是512颗大约相当于同一片晶圆上两个row的芯片数量能较好地反映当前小区域的工艺状态。当然这个窗口大小不是固定的需要根据产量和工艺稳定性来调。二是先用四分位距IQR做一次粗筛。这个是我从第一个版本踩坑之后加上的。原因是统计基准本身不能被极端值污染——假设一个批次里有一批芯片因为探针接触不良测出来的输出电压异常低如果这些异常值参与均值计算会把均值拉偏导致后面正常芯片反而显得“偏高”而被误杀。所以必须先做一轮IQR揪出离群点再把剩余样本拿来做均值和标准差。4.3 测试流程集成PAT放在哪里执行最合适PAT逻辑写好了放在测试流程的哪个位置也是个讲究事。放太早、太晚都会出问题。我项目里的做法是放在所有常规功能测试项结束之后、最终bin判定之前。原因有二第一先跑完所有硬性测试项把确定Fail的芯片先筛掉这些Fail芯片的参数本来就不应该进入PAT统计否则会拉宽统计分布把好芯片一起拖下水第二PAT需要用到的参数值在功能测试阶段已经全部量测完毕PAT逻辑只是对这些已经测出来的数值做数学处理和判断不涉及额外的电学测量几乎不增加测试时间。需要特别注意的是PAT统计的数据来源应该是同一状态下测出的参数。如果某颗芯片在常温下的LDO输出电压是4.95V高温下变成了5.02V那这两个值是两种完全不同的物理状态绝对不能放在同一个统计模型里。所以我的PAT逻辑是按温度区间分别维护独立统计窗口的常温的数据只跟常温的比高温的只跟高温的比。这个细节一开始没注意导致高温测试段出现了一堆莫名其妙的PAT误杀。4.4 量产导入前的三阶段验证PAT逻辑不是写完就能直接推到量产线的我在上线之前做了三轮验证。第一轮是离线回放验证offline replay。用之前三个月的量产历史数据把每颗芯片的测试参数和最终测试结果拿回来在软件里模拟跑一遍PAT逻辑看看如果当时启用PAT哪些芯片会被筛掉这些芯片的良率分布和后续客户端退回的失效样片有没有重叠。这个验证特别能说明问题——我回放之后发现客户端退回来的那几颗早期失效芯片竟然有三颗都被PAT逻辑抓到了。这三颗在以前的测试程序里是Pass的但它们的LDO输出电压都偏高且偏离均值超过了5.5个标准差。这个结果可以直接说服项目组所有人PAT不是可有可无的。第二轮是小批量试产验证pilot run。选了三片晶圆大概一千多颗dieCP阶段启用PAT看良率影响是多少同时工程部挑了一些PAT Fail的芯片做破坏性物理分析DPA和高温老化HTOL实验看这些芯片是不是真的有缺陷。DPA结果验证了我的猜想那些PAT Fail的芯片里确实有芯片的金属层厚度偏薄、氧化层存在缺陷等问题。第三轮是跟客户对标验证。因为客户规格书里提出了PAT要求但没说具体参数和限值怎么设我把我们的PAT策略整理成一份报告发给客户客户的质量工程师审核通过之后才正式导入量产。这一步千万别省PAT参数设严了导致良率下降客户会找你设松了客户又会觉得可靠性保障不够提前沟通对齐很有必要。5. 实战中踩过的坑以及问题排查的实录5.1 双峰分布导致的PAT误杀这应该是我这次项目里最典型的坑值得拿出来单独讲。CP阶段有一个参数叫Bandgap参考电压Vbg理论上应该稳定在一个标称值附近标准正态分布。但我把某个批次的所有die的Vbg直方图画出来之后发现分布出现了明显的双峰——主峰在1.22V附近另一个小峰在1.24V附近两个峰之间几乎没有过渡。这是典型的工艺偏移导致的子群体效应可能跟晶圆边缘的掺杂浓度偏差有关。问题来了标准的PAT算法假设数据是单峰近似正态的算出均值和标准差之后那个1.24V的次峰整体落在6σ范围之外导致整个次峰上的几百颗芯片全部被判PAT Fail。工程部拿去做了失效分析发现这些芯片电性上完全正常封装后也能正常工作没有任何可靠性问题。这就尴尬了——PAT本来是用来抓异常个体的结果把一群“正常但工艺偏移”的芯片全部误杀了。排查思路是这样的我先把数据按晶圆区域拆开画了空间分布图发现这个次峰主要集中分布在晶圆边缘的两三个shot区域。然后我查了这批晶圆在前道的离子注入均匀性数据确认边缘区域确实存在轻微的工艺偏差但偏差幅度在可接受范围内。解决方法是给这个参数的PAT加了条件判定逻辑先做双峰检测用聚类或简单阈值分离两个峰如果判定存在明显的次峰且次峰占总体比例超过某阈值比如3%则放弃对该参数的单峰PAT改用基于IQR的稳健统计判定。对于这次事件最终方案是把该参数的K值从6调整到7并且在PAT Fail的复核bin里增加了一个人工抽检流程。那个次峰上被判Fail的芯片重新做一次功能全测和可靠性抽检确认没问题再Release。这个坑给我一个教训PAT不是说算术平均值和标准差就能直接套的先画分布图、确认分布形态是一切的前提。5.2 多站点并行测试引入的系统偏差J750一次可以同时测4个site4工位并行。理论上4个site的硬件资源是完全相同的DUT板上的每个site电路布线也做了等长等阻设计但实际测下来site之间的读数总是存在微小偏差大约在0.2%到0.5%之间。这个偏差在普通功能测试中完全在容差范围内但在PAT场景下就被放大了。因为PAT是按批次跑完之后统一算的程序每测完一个lot会把4个site的数据混在一起算统计分布。site1和site4之间的系统偏差大概有1mV左右而这个参数的6σ统计窗口总共才不到10mV这个固定偏差直接导致site1上正常分布的芯片有一部分落到了PAT窗口外。排查的时候我发现一个问题PAT Fail的芯片在site1和site4上特别多site2和site3上几乎没有。这就不符合随机分布的特征明显是有site因素参与的。我逐个site单测跑了一遍同一个晶圆把那几个疑似有偏差的site的datalog单独拿出来画分布才发现site之间确实存在系统偏差。解决办法有两个层面一是硬件层面把偏差大的site的DUT板连接器重新插拔清洁检查了继电器接触电阻偏差缩小了一些但不是全部消除二是软件层面PAT计算时按site分组来统计site1的芯片跟site1的芯片比site4的跟site4的比相当于给每个site建了一套独立的统计窗口。这样的代价是需要维护4套统计模型代码复杂度上去了但PAT判定结果变得干净了。经验总结就是多site并行测试时PAT统计基准必须按site分组不要混在一起算。5.3 探针接触不良伪装成参数漂移CP阶段另一个高频问题是探针接触不良。随着测试的推进探针针尖会积累氧化物和碎屑接触电阻逐渐变大导致某些参数的测量值异常。这种异常如果幅度不大不会触发功能测试Fail但会以“参数漂移”的形式混进PAT统计模型里造成两大类问题一是探针脏导致的异常芯片混进统计窗口把分布拉宽二是探针突然接触好的时候测出的“正常值”反而被之前拉宽的窗口误杀。我们的排查方法比较笨但有效——在测试程序里增加了一个接触电阻检查项Contact Check每次上电测试前先做一个微小电流的强制测试计算接触电阻如果超过阈值就判断为接触不良先做探针自清洁。同时PAT统计窗口里把接触电阻检查项异常的数据屏蔽掉不让它们进入统计样本。此外探针清洁频率的设定也跟PAT数据稳定性直接相关。我们后来把自动探针清洁使用清洁片或激光清洁的触发条件从“固定每500次”调整为“接触电阻异常时触发清洁”这样既能减少不必要的停机也能保证统计数据始终是干净的。5.4 样本量不足引发的初始阶段误杀动态PAT在测试批次刚开始时有一段统计窗口的“冷启动”阶段。我的最小样本量设在25颗这个数字不是随便拍的。样本量太小均值和标准差的估计误差太大6σ窗口也会跟着飘样本量太大又会导致前期几百颗芯片没法使用PAT失去了早期拦截的作用。但25颗这个阈值在初期还是出了状况。一个lot开始测试的头几十颗芯片中如果恰巧有几颗因为静电、搬运等原因导致的随机异常芯片它们的值会把均值拉偏导致统计窗口整体偏移。前面提到我先用IQR做了一次粗筛就是为了缓解这个问题但实际效果有限。后来我在动态PAT前增加了“启动保护期”逻辑——样本量达到100颗之前PAT Fail的芯片不直接判Fail而是标记为Review等样本量充足、统计模型稳定之后再启用真正的判定。另外测试程序跑动态PAT时统计基准的更新时机也很关键。我采用的逻辑是每测完一颗芯片就实时更新统计窗口但这带来一个问题如果某个lot前半段的工艺状态跟后半段有差异统计窗口会被一点点漂移拉升导致这种漂移被“正常化”。后来我把更新策略改成了每25颗为一个块block一个block结束后统一更新统计基准这样既保留了动态性又避免了个别异常值的过度影响。6. 后续还能怎么扩展从PAT到智能制造的数据闭环PAT控制做起来之后手里就有了大量实时的量产数据。我在这台测试机台上维护了一套简单的SPC监控看板把PAT Fail的比率按照晶圆批次、测试站点、时间维度做了趋势分析出现异常波动时自动告警。有了这个机制封装厂那边反馈的某些失效模式我能提前在测试数据里找到苗头。比如有一次FT的PAT Fail率连续三天缓慢爬升从正常的0.3%涨到了0.8%。我拉出数据按封装批次一看发现是某一台封装设备处理的产品Fail率明显高于其他设备反馈给封装厂后确认是那台设备的真空吸嘴磨损导致贴装压力偏大。如果不是PAT Fail率做了趋势监控这种封装设备的细微劣化可能要等到客户端出现批量失效才能被发现损失完全不是一个量级。现在测试行业的整体趋势也在往这个方向走。ATE机台本身的数据采集能力越来越强加上YMS之类的良率管理系统越来越普及PAT已经不只是单机台的统计筛选工具而是整条制造链路的闭环数据节点。有些客户甚至要求测试数据直接上云做实时SPC建模PAT的触发阈值由云端模型动态下发以实现不同产线、不同季节的工艺自适应。这块我已经有部分客户在推了往后的测试工程师如果只懂写测试项、编流程不懂数据分析会越来越吃力。对我个人来说这次项目最大的收获不是把用户退片率降下来了多少、良率提升了几个百分点而是彻底改变了对芯片测试这件事的理解测试不只是一道质量检验步骤它是一个数据密集型的数据处理过程每一个测量值、每一个统计窗口、每一条判Fail逻辑背后都是对工艺物理的理解、对失效模型的推演、对风险收益的权衡。最后分享个小技巧收尾。PAT参数的窗口上下限设置好之后别急着写死在程序里我习惯把上下限跟内部规格限datasheet limit的比值定义成一个全局变量暴露出来方便后续在测试现场调试时快速调整。量产阶段工程变更时多留一个可配置的口子能省很多来回编译测试程序的时间。这个细节看起来不起眼真到产线半夜报警、你在远程改参数的时候就知道有多香了。