第三章：测试结果日志解析——Tester日志结构、Pass/Fail统计、Shmoo图初步解读

各位好，我是你们的DFT讲师。今天咱们聊聊测试结果日志。说实话，我刚入行那会儿，看到Tester吐出来的日志文件，头都是大的。密密麻麻的数字、符号，完全不知道从哪看起。后来带我的老工程师跟我说了一句话，我到现在都记得：「日志就是芯片的体检报告，你得学会看指标。」

好，那咱们今天就一起来学学，怎么读懂这份「体检报告」。

先说说日志的结构。不同ATE厂商的日志格式略有差异，但核心骨架是一样的。我以最常见的STIL（Standard Test Interface Language）格式为例，给大家拆解一下。

一个典型的Tester日志，通常包含这么几块：

Header（头部）：记录了测试时间、操作员、测试程序版本、芯片批次号等信息。这部分主要是追溯用。
Setup（配置区）：列出了测试条件，比如电压、温度、时钟频率、IO电平。嗯，这里要注意，如果配置错了，后面的结果全是废的。
Pattern Execution（向量执行区）：这是核心部分。每一条测试向量（Pattern）的执行结果都会在这里体现。Pass还是Fail，哪个Cycle出错了，都会记录。
Summary（汇总区）：最后给出总的Pass/Fail统计，以及Bin分类结果。

我给大家画个简单的结构图，方便理解：

说白了，日志就是从上到下，一步步记录测试过程。你按这个顺序看，就不会乱。

很多人拿到日志，第一眼就去看最后的Pass/Fail总数。我刚开始也是这样。但后来发现，这其实是个坑。

为什么？因为总数只能告诉你「芯片好不好」，不能告诉你「哪里不好」。真正的诊断，得看细分的统计。

我给大家列一个典型的统计表：

测试项	测试向量数	Pass	Fail	良率
Scan Chain Test	10	8	2	80%
Stuck-At Fault	500	498	2	99.6%
Transition Fault	800	790	10	98.75%
IDDQ Test	5	5	0	100%
总计	1315	1301	14	98.94%

你看，总良率98.94%，看起来不错对吧？但仔细看Scan Chain Test，良率只有80%。这说明什么？说明有2条扫描链出了问题。这2条链如果不去修，后面测再多向量都是白搭。

核心要点：Pass/Fail统计要分层看。先看大项，再看小项。哪个大项良率低，就优先排查哪个。

Shmoo图，这名字挺有意思的。我第一次听到的时候还以为是某种海鲜。其实它就是一个二维的「通过/失败」地图。

横轴通常是电压，纵轴通常是频率。每个格子代表一个测试条件组合。绿色表示Pass，红色表示Fail。

我画个简单的Shmoo图给大家看看：

这张图怎么看？我教你个口诀：「绿区是安全区，红区是雷区」。

你看，左上角是低频高电压，芯片工作得很舒服，全绿。右下角是高频低电压，芯片开始扛不住了，全红。中间那条分界线，就是芯片的「性能边界」。

我的经验：Shmoo图最值钱的地方，不是看Pass/Fail，而是看那条边界线的形状。如果边界线是平滑的，说明芯片的失效是渐进的，可能是时序问题。如果边界线是锯齿状的，说明有随机缺陷，可能是制造问题。

我曾经遇到过一个项目，Shmoo图在某个电压点突然出现一个「红岛」，周围全是绿的。一开始大家以为是测试程序的问题，排查了三天。后来我用诊断工具一查，发现是那个电压点下，某条扫描链的驱动能力不够。换了库单元就解决了。

注意：Shmoo图不是万能的。它只能告诉你「在什么条件下芯片会挂」，但不能告诉你「为什么挂」。要找到根因，还得结合诊断工具做进一步分析。

最后，我分享几个实战中总结的小技巧：

我曾经有一次，芯片在量产测试时良率突然掉了5%。所有人都在查设计、查工艺。我翻出三个月前的日志一对比，发现是测试程序里某个时序参数被改动了。改回去，良率就恢复了。你想想看，如果没有日志归档，这问题得查多久？

好，今天的内容就到这里。日志解析是DFT诊断的第一步，也是最基础的一步。把这一步走扎实了，后面的诊断才能有的放矢。

可可精品资料库