 芯片测完了，良率也算了，报告也出了。然后呢？三个月后客户投诉，你需要回头查那颗芯片当时的测试数据。打开文件夹，一堆.log、.txt、.csv，文件名是“test1”“output”“result”，根本不知道哪个对应哪颗芯片。 点开一个，里面只有Pass/Fail，没有具体数值。再点开一个，数值是有的，但不知道是什么条件下测的。 这就是Datalog没规范好的后果。 今天聊聊测试程序中的Datalog应该怎么设计，才能在需要的时候真正派上用场。  一、Datalog不是随便记，要有结构 一份好的Datalog，至少包含三部分：头信息、测试项明细、尾信息。 1. 头信息：这批测试是谁、什么时候、在哪测的。 至少包括： 程序名称和版本号 测试机台号 测试开始时间 操作员ID或工号 批次号和晶圆号 封装批次号 这些信息写在文件开头，一行一条。不要分散在文件各处。 2. 测试项明细：每个测试项测了什么、结果如何。 每个测试项至少记录： 测试项名称 测试条件 测量值 判断限 结果 推荐用表格形式，一行一个测试项。这样无论是人眼看还是脚本解析，都很方便。 3. 尾信息：这批测试的整体结果。 包括： 总体判断（Pass/Fail） 测试结束时间 总测试项数、Fail项数 可选：测试总耗时、Bin分类结果 尾信息可以帮助快速过滤，不用翻遍整个文件就知道这颗芯片是否合格。 二、文件名和存储路径要有规律 Datalog文件本身的名字，是追溯的第一道索引。 推荐命名规则：工位号_批次号_晶圆号_坐标_日期_时间（或其他能唯一标识一颗芯片的组合）。 例如：Site1_Lot20260427_Wafer12_X15Y20_20260507_143022.csv 看到文件名就知道是哪个工位、哪批、哪颗芯片、什么时候测的。不需要打开文件就能定位。 存储路径按层级建文件夹：/测试数据/批次号/晶圆号/ 或 /测试数据/封装批次号/。不要把几千个文件全扔在一个文件夹里。 三、数据格式要通用，不要私有 Datalog文件格式推荐以下两种： 1. CSV（逗号分隔值） 2. TSV（制表符分隔） . 这两种格式通用，Excel能打开，脚本能读取，数据库能导入。 不要用二进制格式，也不要在同一套系统里混用不同的分隔符。比如今天用逗号，明天用空格，后天用竖线，会给后续数据处理带来很大麻烦。 如果确实需要输出文本日志（例如.log文件），至少要保证每行的字段顺序固定，并且能用简单的脚本解析。不要写成自由文本，比如“漏电流测量值为0.5uA，结果通过”——这种写法人眼能看，但程序没法批量解析。 四、字段名称要自解释 不要用缩写。Ilkg 是漏电流，但不是所有人都能一眼看出来。写成Leakage_VDD，或者用统一的缩写字典并在头信息里附上。更推荐直接用完整单词：leakage_current_vdd。 单位一定要写在字段里。比如leakage_ua 明确表示单位是微安。数值写成0.5 而不是0.5uA。数字和单位分开，便于程序读取。 判断限也要分开存：limit_low 和 limit_high，而不是混在一个字符串里。 五、哪些数据必须记，哪些可以省略 必须记的：每个测试项的测量值、判断结果、测试条件中变化的参数（如温度、电压）。没有这些，客诉时无法判断芯片到底好不好。 可选的：中间计算结果、调试信息、临时变量。这些只占空间，对事后分析没太大用。可以单独输出一个调试log，不混入正式Datalog。 不该记的：测试机内部状态、多余的换行、乱码、二进制blob。这些让文件变大，解析变慢。 Datalog不是写给今天看的，是写给三个月后、一年后的自己或同事看的 几个简单的规则： 文件名能读出身份 头信息交代测试背景 每个测试项带单位、带限 用CSV或TSV，不搞私有格式 字段名写全，不缩写 下次写测试程序，多花十分钟把这些规范写进去。以后你会感谢当时的自己。  |
