企业官网建设流程全解析

做芯片测试的朋友应该都有这种体验：被测芯片从探针台或者机械手上下来的那一瞬间，到底被丢进哪个料盒、贴上哪个标签、记进良率报表的哪一行，完全取决于测试程序在最后那一刻写下的一个数字——Bin号。在SmarTest 8平台上，这套从测试项判定到物理分拣的完整逻辑就叫Binning。它不只是一个"填个数字"的小事，而是从Bin Table配置、结果传递、Soft Bin/Hard Bin映射、多站点计数到数据落盘的一整套运行机制。

这篇文章就围绕SmarTest 8的Binning机制做一次系统总结。我会把规则定义在哪里、测试结果怎么变成Bin号、两套Bin体系怎么配合、多站点并行测试下有哪些坑，结合实际调试经验讲清楚。适合刚接触SmarTest 8的测试开发工程师，也适合已经写过程序但一直对Bin计数和行为机制"半懂不懂"的同行。

1. Binning在芯片测试流程中的定位：为什么一个"分拣号码"决定芯片命运

1.1 从良率统计到物理分拣：Bin概念的出发点

芯片测试的最终目的不是简单说一句"这颗是好的，那颗是坏的"。一片晶圆上有几千上万颗die，同一批封装出来的芯片在速度、功耗、漏电等特性上存在天然差异，供应链下游需要的往往是"分等级收货"，而不仅是"好坏两堆"。

这就催生了Bin这个概念。Bin在中文环境里常被译作"分类"或"仓"，它本质上是给每颗芯片一个编号：测试系统根据测试结果，把芯片归入某一个数字编号对应的类别。编号不同，芯片的后续流向就不同。比如Bin 1代表合格品，进出货料盒；Bin 2代表开短路失效，进报废盒；Bin 3代表功能失效，进分析盒；Bin 4代表漏电超标，可能进返工盒或报废盒。

在这个过程里，Bin承担了两个完全不同的职能。第一个职能是物理分拣：Handler或者Prober必须根据测试机输出的Hard Bin号，把芯片拨到对应的料仓或墨点位置。这个动作是机械层面的，它要求Bin号稳定、明确、可被设备识别。第二个职能是良率统计与失效定位：测试工程师需要知道一批芯片到底坏在哪、坏的比例有多高，这个需求比物理分拣要细得多，所以又产生了Soft Bin的概念，用来记录更具体的失效模式。

1.2 SmarTest 8中Binning的平台化设计

早期很多测试程序的做法很直接：某个测试项Fail了，就跳到一个特定标签，把某个内存地址设成指定数字，然后结束。这种"过程式跳转"式的Binning在小程序、少测试项的场合够用，但放到大规模量产程序里就非常痛苦——测试项一多，跳转逻辑满天飞，想加一个新失效类别，得改好几处代码，还容易漏。

SmarTest 8把Binning做成了平台级机制。它不再要求工程师在每个测试方法里用跳转维护Bin号，而是通过一套集中式的Bin Table定义所有分类规则，测试程序通过动态的Bin赋值函数来更新当前芯片的Bin编号，系统再在测试结束时统一处理输出和计数。这样的好处很明显：分类规则和测试逻辑分离，新增一种失效模式时，只在Bin Table里加一行、在对应判定分支里加一次赋值即可；同一个Bin可以被多个测试项复用，不用重复维护。

理解了这层平台化设计，你就能明白为什么标题要强调"运行机制"四个字——SmarTest 8的Binning不是某个函数那么简单，而是一条贯穿程序配置、测试执行、结果输出三个阶段的完整数据链路。下面我按这条链路逐步拆解。

2. Bin Table的底层结构与配置入口：规则定义在哪，才算真正定义

2.1 Bin Table的核心字段：编号、类型、字符输出、计数开关

在SmarTest 8里，所有Bin的合法定义都集中在一张Bin Table（分类表）中。这张表是整个Binning机制的规则源头，每一个在测试程序里出现过的Bin号，理论上都应该能在表里找到对应条目，否则轻则计数异常，重则物理分拣无法处理。

Bin Table的核心字段大致如下，我拿一个实际项目的典型配置来说明：

这里要提醒一点：Bin编号不强制从0或者1开始，完全由项目自定义。我见过不少项目把Bin 0保留给"未测"状态，Bin 1~5留给不同等级的好片，Bin 6~20留给各种失效类型。还有车规项目直接按客户要求把Hard Bin号映射成客户编码，Bin号本身变成了外部追溯的一部分。所以，Bin Table的配置一定要和下游封装、出货环节对清楚，测试机这边的编号只是内部逻辑，封装厂看的是Datagram里输出的字符和Hard Bin号。

2.2 配置入口与文件化管理：Bin Table要当成代码来管

SmarTest 8的Bin Table通常在测试程序的项目配置界面里打开，普通编辑操作就是增删行、改字段。但真正到了量产release阶段，我强烈建议把Bin Table通过导入导出功能保存成文本映射文件，放到测试程序目录里统一管理。

为什么强调文件化管理？因为Bin Table太容易被版本问题坑了。产线测试程序更新时，如果只更新了测试方法代码，忘了同步Bin映射文件，测试机加载到的分类规则很可能还是旧的。最常见的结果是：程序里新加了一个Soft Bin 15，但Bin Table里没有这一行，或者映射关系已经变了，于是这个Bin输出的Hard Bin号与预期不一致，芯片被分错料盒。把Bin Table映射文件纳入版本管理，每次release时和测试程序一起发布，是避免这类事故最简单的办法。

另外要注意导出文件格式的兼容性。SmarTest 8不同代际版本之间，Bin Table文件的字段可能不完全相同。跨版本拷贝配置时，务必逐列检查，特别是类型字段和字符串字段的匹配规则，别想当然地认为新版本一定能完整兼容旧文件。

2.3 Pass可以细分吗？Fail必须一个Bin吗？

很多刚接触测试程序的人会默认"Pass就是一个Bin，Fail是另一个Bin"。真实量产里完全不是这样。

Pass完全可以细分成多个Bin。最典型的例子是速度分级：同一颗芯片在不同工作电压或不同时钟频率下分别执行功能测试，如果都能通过，就按通过的最高等级落进不同的好片Bin。比如Bin 1是最高速度等级，Bin 2是中等速度等级，Bin 3是较低速度等级，三者都是Pass，但在供应链端代表不同产品规格，售价和管理方式都不同。

Fail更需要细分。我通常建议至少粗分为开短路Fail、DC参数Fail、功能Fail、AC时序Fail几大类，再按具体测试项细分成Soft Bin。这样当某批芯片良率异常时，通过Bin Pareto图能立刻看出是哪个失效模式在恶化，而不是面对一堆"Fail"无从下手。细分Fail Bin不是浪费，是在给后续的失效分析节省时间。

3. 从Test Result到Bin赋值的完整链路：测试项判定之后到底发生了什么

3.1 结果传递路径与Bin赋值的最终时机

搞清楚Bin号什么时候被确定，是理解整个运行机制的关键。测试程序执行过程中，每一个测试项由对应的Test Method完成测量和判定，但注意，测试项判定通过与否，并不直接决定最终Bin。它只是产生一个结果，这个结果再交由测试流程逻辑决定"应该把当前芯片的Bin设置成什么"。

大概的链路是这样的：

1. Test Method执行测量，得到Result（Pass或Fail）以及若干测量值；
2. 测试流程中插入判定逻辑，根据Result和测量值决定当前芯片属于哪个分类；
3. 流程调用平台的Bin设置接口，写入Soft Bin和Hard Bin，此时芯片的Bin被更新；
4. 测试流程继续执行后面的测试项，后续代码可能再次更新Bin；
5. 整个测试流程结束后，SmarTest 8把最终的Bin值提交给站点计数器、Datagram记录和Handler/Prober控制接口。

这里最关键的一点是：Bin赋值是"可覆盖"的，最终以整个测试流程结束时的值为准。如果你在测试项A里设置了Bin 5，后面的测试项B又把Bin改成了Bin 3，那最终这颗芯片落进的就是Bin 3，除非B后面还有赋值把它们再改回来。很多Bin计数对不上号的案例，根源都在这里。

3.2 流程控制中的Bin赋值：正常Pass、条件Fail与Abort

下面这段示意代码并不是SmarTest 8的官方API语法，而是为了说明判定逻辑和Bin赋值的关系：

// 示意代码：测试项判定与bin赋值（伪代码，非官方语法） // 假设已经拿到了某个测试项的测量结果 measurement_result if (measurement_result == PASS) { // 好片不急着赋Bin，让最终默认Pass Bin生效 // 但如果是速度分级，这里可以按等级赋给不同Pass Bin // set_soft_bin(1); // set_hard_bin(1); } else if (measurement_result == FAIL_OPEN_SHORT) { set_soft_bin(10); set_hard_bin(2); } else if (measurement_result == FAIL_IDD_LEAK) { set_soft_bin(11); set_hard_bin(2); } else { set_soft_bin(99); set_hard_bin(9); }

实际编程时的核心分支无非三种：

• 正常Pass：通常不需要显式赋Bin，程序会在没有设置任何Fail Bin的情况下，默认落入Pass Bin（常见是Bin 1）。但如果是分级测试，就需要在每个分级测试项通过后，显式把Bin设置为当前等级对应的编号。
• 条件Fail：这是最常见的Binning赋值场景。根据测试项结果或者测试项测得的数值范围，把Soft Bin和Hard Bin一起设置好，分别满足失效细分和物理分拣两个需求。
• Abort异常：测试过程中如果发生设备报警、测试超时、接触失败、过流保护等异常情况，必须把芯片放进专门的Abort Bin（比如Soft Bin 90、Hard Bin 8）。绝不能让它混进普通Fail Bin，否则失效分析会被大量“假Fail”污染，而且Abort往往意味着测试机状态有问题，需要单独处理。

3.3 多测试项共同决定Bin：为什么最后赋值会覆盖前面

承接上文说的覆盖问题，我再展开一下实际场景。假设一个程序里有三个测试模块：开短路测试、IDD静态电流测试、功能测试。开短路Fail会赋Bin 2，但程序后续还会执行IDD测试和功能测试。如果你在开短路Fail后没有用流程控制"跳过后续测试"，而是继续往下跑，IDD测试Fail会把Bin改成Bin 11（假设这是IDD专用Bin），功能测试Fail又会改成Bin 21。最终这颗芯片落进的是Bin 21，而不是Bin 2。

这个现象本身不是Bug，它就是Binning机制的设计逻辑——后面的测试结果覆盖前面的。问题在于，很多新手写程序时没意识到这个覆盖关系，导致Fail分类被后执行的测试项"冲洗"掉。解决方案通常有两种：一是Fail发生后立即跳过后面的无关测试项，这既省测试时间又能保住Bin分类；二是如果必须执行完整测试，那就要按照优先级顺序重新赋Bin，或者使用延迟到测试结束前统一判定的方式。我个人的习惯是优先使用Fail后跳过的流程控制，让第一个Fail的定位信息直接成为最终分类，这是最直观、最不容易出错的方案。

4. Soft Bin与Hard Bin的映射机制：一宽一细，两条线并行

4.1 为什么需要两套Bin体系

SmarTest 8和大多数主流ATE平台一样，把Bin分成Soft Bin和Hard Bin两套体系并行运行。这不是多此一举，而是分别服务两类完全不同的用户。

Hard Bin面向的是物理分拣设备和生产统计数据。Handler和Prober等设备通过硬件接口读取Hard Bin号，把芯片分到指定料盒；产线主管看Hard Bin比例就知道当天好片率和总体失效水平。它要求数量少、含义稳定，通常不会超过二三十个，因为分拣设备料盒数量有限，操作员也不可能记太多编号的含义。

Soft Bin面向的是测试开发工程师和失效分析工程师。它记录的是"这颗芯片具体因为哪个测试项、哪种失效机理被判定为不良"，数量可以很大，几十上百个都不稀奇。调试阶段看Soft Bin Pareto图，能快速定位良率损失的来源，甚至能定位到探针接触不良、某个测试通道老化、某种版图缺陷等具体根因。

打个比方，Hard Bin好比医院体检报告首页的结论——“合格”或“某科室复查”；Soft Bin则是详细化验单，告诉医生到底哪个指标异常、异常到什么程度。两者互相补充，缺一不可。

4.2 映射规则与典型配置示例

Soft Bin和Hard Bin之间不是独立的，必须通过映射关系连接起来。一个Soft Bin对应一个Hard Bin，多个Soft Bin可以映射到同一个Hard Bin。下面是一个比较典型的映射配置：

这个例子里，所有参数类失效都归入Hard Bin 2，功能失效归入Hard Bin 3，AC时序失效归入Hard Bin 4。从物理分拣角度看，只有几个明确的去向；从调试角度看了Soft Bin明细，立刻知道大批Hard Bin 2的芯片里到底是开短路多还是漏电多。

配置映射时有一个必须处理的边界情况：某个Soft Bin没有找到对应映射。稳妥的做法是给映射规则设置一个默认Fallback项，通常指向专门的"未定义Bin"或者Fail Bin。如果没有默认规则，映射失败时可能出现计数异常或者分拣设备收到无法识别的Bin号，这个隐患在release前一定要通过测试验证掉。

4.3 映射关系如何反哺调试：从Datagram看到失效定位

量产测试中，测试机输出的Datagram会同时记录Soft Bin和Hard Bin信息。良率分析系统拿到这批数据后，从Hard Bin维度可以快速汇总出各批次的好片率、各类Fail比例；切换到Soft Bin维度，就能深挖到具体测试项。

我经常用这个联动关系做排查。比如某天某个批次的Hard Bin 2比例从5%涨到15%，先看Pareto图，发现Soft Bin 10（开短路）占比大幅上升，那就优先怀疑探针接触、Socket磨损或者封装工艺的焊接问题；如果涨的是Soft Bin 11（IDD漏电），那就要往工艺线漏电、器件阈值漂移方向排查。没有Soft Bin，这种定位根本无从下手。

反过来，调试新测试程序时也一样：先把Soft Bin做好做细，再设计Hard Bin映射，让产线和失效分析各自取所需。先粗后细还是先细后粗，决定了整个调试阶段的效率。

5. 多站点并行测试下的Binning管理：分站点计数与一致性

5.1 为什么每个站点的Bin计数不能合在一起

现在的量产测试几乎都是Multi-Site并行，一块探针卡或者一个测试板上同时测试四颗、八颗甚至更多DUT。SmarTest 8里每个Site是独立的测试通道，有独立的测量资源和独立的结果缓存，所以Bin计数天然也应该按Site独立统计。

如果两个Site的Bin计数合并在一起看，会有几个问题。第一，异常被平均稀释。假设四个Site里一个Site接触不良，单独看它的Fail率是90%，四个合并很快就把比例拉低了，问题没那么显眼，等到良率恶化到无法忽略时，已经浪费了很多产能。第二，调试时无法区分是哪一组通道的问题。Bin计数不按Site拆开，排查探针卡局部抬高、Socket磨损这类和通道强相关的问题时会非常痛苦。

5.2 站点差异与虚假Fail：Bin数据暴露的接触问题

我们实际遇到过一种典型场景：某个批量程序中，Site 3的Hard Bin 2（参数失效）比例是其他Site的五六倍。单看整体Bin数据，只发现总Fail率偏高；按Site拆分后，矛头立刻指向Site 3的物理通道。检查发现是那一组探针针尖有残留物，接触电阻变大，导致接触测试和部分DC参数测试不稳定。处理完针尖清洁，Site 3的Bin分布立刻恢复正常。

这类问题靠看Bin数据是最快的发现途径。我建议在调试和量产监控阶段，都养成按Site查看Bin汇总的习惯。SmarTest 8的测试结果汇总界面支持按Site过滤，后面如果接入了良率分析系统，也尽量按Site维度做报表。Bin计数里的异常往往是硬件问题的第一信号，而且相当可靠。

5.3 多站点程序里的Bin表共享与赋值覆盖

多站点测试时，所有Site共用一份Bin Table，不存在每个Site一套分类规则的情况。每个Site只是各自维护一份Bin计数器和当前测试芯片的Bin值，但分类定义本身是全局的。这就意味着，某个Site的测试方法里改动了Bin赋值，不会影响其他Site的分类定义，但会影响这个Site自己的当前芯片分类。

一个容易忽略的细节是：多个Site并行执行过程中，如果某个Site的测试流程因为调试需要临时修改了Bin映射，而其他Site还在用旧规则执行，现场就会出现同一批程序、不同Site分类结果不一致的乱象。所以，所有涉及Bin Table和映射配置的修改，都应该在测试程序整体加载后统一生效，不要在产线做零敲碎打的在线修改。

6. Release前校验与实例：我实际遇到的三个Binning问题

6.1 问题一：坏片被分进了好片料盒

有一次量产测试，操作员发现Bin 1料盒里抽检到一颗明显的不良品。这属于最严重的一类Binning事故。

排查链路是这样的：先看Datagram，发现那颗芯片记录的Soft Bin是20（功能失效），但Hard Bin竟然是1（好片），说明问题出在映射环节。回到Bin Table检查映射配置，发现Soft Bin 20对应的Hard Bin被配成了1。进一步查原因，原来是测试程序版本更新时，映射文件是从老项目拷贝的，老项目里Soft Bin 20正好代表一个特殊Pass等级，而新项目把Soft Bin 20定义成了功能失效，映射文件没有同步改。新程序加载了旧映射文件，分类规则和测试逻辑对不上，于是酿成误分。

这个案例教会我一个铁律：测试程序release时必须把测试方法代码和Bin映射文件当成一个整体来验证，任何一边改动，都要同步检查另一边的合法性。最好专门用已知好片和已知坏片做一轮完整验证，而不是只看程序跑得通。

6.2 问题二：Bin计数总是对不上，重复测试覆盖导致

另一个项目里，程序调试阶段发现某个Soft Bin的计数和实际测试项Fail次数对不上，明显偏少。

一开始怀疑是Bin Table计数开关没打开，检查后发现没问题。后来一条条梳理测试流程，才发现问题出在重复测试上：某个失效判定在测试项A里触发后赋了Soft Bin 10，但流程没有跳过后面的功能测试模块，功能测试模块里有一个"兜底"逻辑，对所有Fail重新赋了Soft Bin 20，结果Soft Bin 10的计数被覆盖成了20。从数据看就是Bin 10数量少、Bin 20数量虚高。

解决的方案就是前面说的：在第一个Fail点确定分类逻辑后，用流程控制跳过不必要继续执行的测试项；如果确实需要完整测试，那兜底赋值逻辑就应该只在"此前未赋Bin"的条件下执行，而不是无条件覆盖。改完之后，各Bin计数和测试项Fail次数的对应关系立刻恢复正常。

6.3 问题三：某个站点整片Fail，Bin汇总却看起来正常

还有一次，产线反馈某一片晶圆测试时间异常长，但最终Bin汇总比例看着还好。因为时间异常，我们调出了按Site拆分的Bin计数，发现其中一个Site的Fail率接近100%，而其他Site几乎全是Pass。整体Bin汇总里Fail比例被"稀释"了，乍一看完全正常。

定位过程也很有意思：先确认不是Bin映射问题，因为Fail的Soft Bin分布集中在接触测试和部分DC测试项上。再检查那个Site对应的探针通道，发现针尖高度已经明显偏低，接触压力不足，导致大量虚假开短路Fail。更换针卡后，该Site的Bin分布和其他Site完全对齐。

这类故障提醒我：Bin数据不只要看整体比例，还要形成"按Site、按Soft Bin、按时间"多维度的监控习惯。只看汇总数字，很容易把硬件问题当成工艺良率波动，耽误排查窗口。

6.4 Golden Sample验证流程与发布检查清单

经历了几次Binning事故后，现在每次release测试程序之前，我都会强制自己走一遍验证流程，几个关键步骤基本固定：

1. 准备两组Golden Sample：一组已知好片，一组覆盖主要失效模式的已知坏片；
2. 加载完整的Bin Table和映射文件，先用好片跑一轮，确认最终Hard Bin等于预期好片Bin；
3. 用坏片跑一轮，逐一确认不同失效模式对应到预期Soft Bin和Hard Bin；
4. 核对Datagram输出，看一眼Soft Bin、Hard Bin和输出字符字段是否正确；
5. 按Site拆分检查Bin计数，确认没有站点异常；
6. 把验证结果和Bin映射文件一起存档，作为此次release的记录。

这个过程看起来繁琐，但每次都能在测试程序正式量产出货前，拦下一批本来会造成批量误分的隐患。花半小时做一次完整的Golden验证，比事后在产线废掉一批料再追责要划算得多。

最后说一点个人的长期习惯。我始终把Bin Table当成和测试方法代码同等重要的交付物来管理。它不只是一张配置表，而是连接测试意图、物理分拣、良率分析三端的契约。运行机制理解得越透彻，写测试程序时就越能把Bin分类设计得清晰稳定，量产阶段也越少遇到分类错乱、计数对不上的问题。如果你正在调试SmarTest 8的Binning配置，建议先打开Bin Table，把当前程序的全部Soft Bin、Hard Bin和映射关系完整梳理一遍，再对照本文的链路走一遍，应该能把很多藏在角落里的坑提前找出来。