STDF V4解析实战：记录头、端序、可选字段与守恒校验

简介《半导体测试数据格式STDFV4规范使用手册》PDF版面向半导体测试工程师、ATE系统开发者与测试数据分析人员系统说明STDF第4版如何以统一记录结构存储和传输不同厂商测试设备产生的数据解决测试结果兼容性与可追溯性问题。全文围绕记录头、记录类型与子类型、数据类型编码、时间日期表示、可选字段及缺失或无效数据处理展开并逐项梳理FAR、MIR、MRR、PIR、PRR、PTR、MPR、FTR等记录以及ATR审计追踪、RDR重测数据、SDR站点描述等新增内容同时给出文件命名、文件排序、维修信息存储和引脚映射的使用说明。包内为1个PDF文件约550KB目录按记录类型编排便于按条目检索末尾附STDF V3与V4在记录类型、数据类型、文件名字符和必需记录上的差异对照及术语表。已有669人学习适合需要查阅字段定义、核对记录结构或迁移旧版数据的读者作为案头规范。1. STDF V4 手册先摆正位置它管的不是测试原理是字节怎么排产线传过来一个.std文件记事本打开是一屏乱码测试主管却要这颗料每个 pin 的 VIL/VIH 分布和 bin 分布。这时候能救场的就是 STDF 这份规范——半导体测试里 ATE 输出测试数据的通用记录格式V4 版本把记录类型、数据类型码、可选字段的表达方式全部钉死到字节级。手册 60 多页从文件属性记录 FAR 一路讲到通用数据记录 GDR是写解析器、做测试数据分析时唯一该对着抄的底稿不是科普读物。适合三类人刚接手 datalog 转换的测试工程师、要写内部报表工具的后端开发、以及被供应商.std文件卡住的数据分析同学。它回答的问题很窄——这堆字节该怎么读、哪些字段必须存在、哪些值代表这项没测。2. 记录头解剖4 个字节里藏着 REC_LEN、REC_TYP、REC_SUB 三段校验STDF 文件没有文件级索引没有 magic number没有目录表整个文件就是一条接一条的记录首尾相连。想从里面捞出东西唯一的入口是每条记录开头那 4 个字节。这既是它简单的地方也是所有解析器翻车的起点一旦在某个位置把长度读错后面几万条记录全部平移报错点往往离真正出错的地方几百 KB 远。2.1 一条记录的三段式为什么 REC_LEN 不含头每条 STDF 记录以一个固定 4 字节的记录头开始字段顺序是 REC_LEN、REC_TYP、REC_SUB。REC_LEN 是两字节无符号整数含义是记录头之后还有多少字节它自己这 4 个字节不算在内。这个约定和很多二进制格式不一样——不少格式的总长度字段是包含头的照抄习惯就会每条记录多跳 4 个字节。REC_TYP 和 REC_SUB 各一字节组合起来唯一确定一种记录类型。REC_TYP 表示这一组记录在讲什么层级的事REC_SUB 表示组内的具体哪一种。手册里那张编码表值得打印出来贴在显示器边上200 以下的编码由规范维护方保留200 以上留给自定义应用扩展所以看到 REC_TYP 在 180 附近基本可以判断是某家设备厂商塞的私有数据需要单独对待。提示解析器一定要对 REC_LEN 做上界检查。损坏文件里 REC_LEN 可能是 65535直接按这个值切片再解码很容易把内存吃光或者读出越界异常。2.2 顺序扫描器20 行把文件切成记录流写解析器的第一层永远是把字节流切成记录不涉及任何字段语义。这一段用 Python 的标准库就够了不需要第三方依赖。我一般会先写这个扫描器跑一遍确认文件能完整走到末尾、没有残留字节再去碰具体字段——先证明切分正确再谈解码顺序反了会浪费大量时间。import struct from pathlib import Path # STDF 记录头固定 4 字节REC_LEN(U*2) REC_TYP(U*1) REC_SUB(U*1) # 默认按小端解释真实端序由第一条 FAR 记录里的 CPU_TYPE 决定 HDR struct.Struct(HBB) def walk_records(path): data Path(path).read_bytes() off 0 while off 4 len(data): rec_len, rec_typ, rec_sub HDR.unpack_from(data, off) body data[off 4: off 4 rec_len] if len(body) ! rec_len: # 长度字段声称的字节数超过文件剩余长度说明文件被截断或偏移已错 raise ValueError(f截断记录 0x{off:X}: 期望 {rec_len}, 实得 {len(body)}) yield off, rec_typ, rec_sub, body off 4 rec_len if off ! len(data): # 尾部有零头字节通常是最后一次写入被中断 raise ValueError(f尾部残留 {len(data) - off} 字节) for off, typ, sub, body in walk_records(lot_a.std): print(f0x{off:08X} TYP{typ:3} SUB{sub:3} LEN{len(body)})HDR用的是HBB表示小端H是两字节无符号两个B是一字节无符号。unpack_from配合偏移量比切片再 unpack 快得多处理几十 MB 的文件时差别明显。off这个绝对偏移我建议一律保留并写进后续的输出结构里——将来某条数据对不上能凭偏移直接跳到那一行去看原始字节这是排查时唯一的后悔药。2.3 类型码分组记忆0/1/2/5/10/15/20/50 八组怎么用硬背二十多个记录缩写没什么意义按 REC_TYP 分组记要快得多因为分组本身就对应了数据的层级结构文件级、lot 级、wafer 级、part 级、测试项级、程序段级、通用数据级。理解了这个嵌套关系后面写聚合逻辑时才知道该在哪一层收口。REC_TYP层级含义代表记录REC_SUB0文件自身属性FAR(10)、ATR(20)1整个 lot 的汇总数据MIR(10)、MRR(20)、PCR(30)、HBR(40)、SBR(50)、PMR(60)、PGR(62)、PLR(63)、RDR(70)、SDR(80)2晶圆级数据WIR(10)、WRR(20)、WCR(30)5单颗零件数据PIR(10)、PRR(20)10测试程序中某一项的汇总TSR(30)15一次测试执行的结果PTR(10)、MPR(15)、FTR(20)20程序段边界标记BPS(10)、EPS(20)50通用/文本GDR(10)、DTR(30)这张表能解释一个常见疑惑为什么 PTR 里的测试结果不能直接按出现顺序累加。PTR 属于 15 组是每次执行的粒度同一条测试项在并行测试的多个 site 上会重复出现而 TSR 属于 10 组是对整份程序的执行统计。两者数量对不上是正常的对得上反而是巧合——具体怎么对账后面第 6 章会给出守恒关系。另外FAR 是文件的第一条记录这一点是硬约定。它不是可选的装饰因为端序、版本号都写在里面解析器必须先把 FAR 读出来才能决定后面几十万条记录怎么解释。跳过 FAR 直接按小端硬解在一部分机器产出的文件上能跑通在另一部分上会静默出错——这是最坑的一类问题因为它不抛异常。3. 数据类型码翻译12 种码如何落成 struct 格式与端序开关切分对了下一步是把每种字段的值读出来。STDF 用一套短码描述数据类型比如U*2是两字节无符号、R*4是四字节浮点、C*n是带长度前缀的字符串。这套码本身很清晰真正的难点在三个地方三种字符串的差异、端序由文件自己声明、位域字段的还原。逐个说。3.1 C12、Cn、C*f三种字符串的读法差异字符串是 STDF 里最容易读错的一类因为它有三种编码方式长得像但语义完全不同。C*12是定长字符串占满固定字节数内容不足时右边补空格读出来必须rstrip掉尾随空格但不该strip左侧——有些字段确实以空格开头。C*n是自描述变长字符串第一个字节是无符号长度紧跟内容最大 255 字节长度字节为 0 表示这个字段没有值。C*f最特殊它自己的长度不写在字段里而是存在记录中另一个字段里读取时必须由调用方把长度传进来。第三种在实际解析中最容易出事。因为它打破了字段自带边界的假设一旦你用一个通用的字段读取函数去顺序推就会把长度字段当成内容读进来然后整条记录的偏移全错。我的做法是在字段描述表里给C*f单独打标记强制调用方传参谁忘了传就直接抛异常而不是默默读错。import struct # 定长数值类型字符 字节数。端序前缀在调用时拼接 FIXED { U*1: (B, 1), U*2: (H, 2), U*4: (I, 4), I*1: (b, 1), I*2: (h, 2), I*4: (i, 4), R*4: (f, 4), R*8: (d, 8), } def read_value(buf, pos, code, endian, ext_lenNone): if code C*n: # 首字节是长度 n buf[pos] return buf[pos 1:pos 1 n].decode(latin-1), pos 1 n if code C*f: # 长度来自记录里的另一个字段 if ext_len is None: raise ValueError(C*f 必须由调用方提供长度) return buf[pos:pos ext_len].decode(latin-1), pos ext_len if code.startswith(C*): # C*12 这类定长右侧空格填充 n int(code[2:]) return buf[pos:pos n].decode(latin-1).rstrip( ), pos n ch, size FIXED[code] return struct.unpack_from(endian ch, buf, pos)[0], pos sizelatin-1是我惯用的兜底编码它能把 0x00–0xFF 的每个字节一一映射成字符遇到非法字节也不会抛解码异常。STDF 的字符集约定本来就窄用 UTF-8 去解老文件偶尔会因为某个 lot id 里混进一个高位字节就整个批次导入失败得不偿失。真正要展示给人看的时候再统一做一次清洗。3.2 U/I/R 定长数值与 CPU_TYPE 决定的字节序定长数值只有八种一一对应到 C 语言的基本类型无符号单/双/四字节、有符号单/双/四字节、四字节浮点、八字节浮点。R*4就是 IEEE 754 单精度R*8是双精度手册里明确写了和 C 语言类型说明符的对应关系没什么歧义。真正的坑在字节序。规范没有规定文件必须用小端而是让写入方用自己的原生表示把处理器类型写进 FAR 记录的 CPU_TYPE 字段读取方读到 FAR 之后判断写入方的表示方法和自己是否一致不一致就在读取时逐条转换。这个设计的意图很清楚让测试机写数据时不做任何转换性能不受影响。后果是同一份代码要能处理两种端序。我在分派函数里留了一个endian参数默认一旦 FAR 的 CPU_TYPE 表明写入方是大端机器就把后续所有调用的参数切成。这个开关必须放在解析器的最外层统一管理不能让每个字段各自猜——一旦有一处漏改读出来的数值就是错的而且不报错。注意CPU_TYPE 只出现在 FAR 里而 FAR 是文件第一条记录。所以先读 FAR 拿端序再回头重读全文件是正确姿势别嫌麻烦跳过。3.3 Bn、Dn、N*1位域与半字节怎么还原成 pin 列表这三类在数字测试数据里高频出现尤其是功能测试的失败引脚信息。B*n是字节计数的位串第一个字节表示后面有几个字节的位数据D*n是位数计数的位串前两个字节表示总位数最大 65535N*1是半字节打包一个字节塞两个值低 4 位是第一个高 4 位是第二个位数是奇数时高 4 位补零。它们的共同约定是第一个数据项放在最低位。这条规则和很多人默认的从高位开始相反是位域读错的头号原因。如果拿到的失败引脚集合看起来整体偏移了几位、或者把相邻两个 pin 混在一起先怀疑这条规则。import struct def read_dn(buf, pos): # D*n前 2 字节是位数数据项从第 3 字节的最低位开始高位补零 nbits struct.unpack_from(H, buf, pos)[0] nbytes (nbits 7) // 8 payload buf[pos 2:pos 2 nbytes] hits [i for i in range(nbits) if (payload[i 3] (i 7)) 1] return hits, pos 2 nbytes def read_bn(buf, pos): # B*n首字节是字节数同样从最低位开始编号 nbytes buf[pos] payload buf[pos 1:pos 1 nbytes] hits [i for i in range(nbytes * 8) if (payload[i 3] (i 7)) 1] return hits, pos 1 nbytes这两个函数的返回值是位序号列表也就是失败位的位置集合不是 pin 编号。要变成人能看的 pin 名还得去查 PMR引脚映射记录——把 PMR 里的序号和物理引脚名、逻辑引脚名对起来。这一段对应手册里Using the Pin Mapping Records那一节讲的就是从失败位序号反查到引脚名的完整链路做失效分析时绕不过去。i 3得到字节下标i 7得到字节内偏移这种位运算写法比转成整数再移位更直观也不受大整数实现细节影响。返回的pos一定要正确推进位串字段后面往往还跟着别的字段位置算错整条记录就废了。4. 可选字段与缺失值Optional Data 位图读错后面全盘皆错STDF 最复杂的设计不在数据结构而在如何表达没有数据。测试数据天生残缺这颗料某个测试项跳过了、那台机器没装某个传感器、某次重测没有记录坐标。规范用了几套不同机制来表达这些情况混用之后解析器和数据分析两边对同一个字段的理解就会分叉。4.1 缺失与无效的四种表达0 长度、空格、标志位、二进制 0第一种是变长字符串用长度 0 表示缺失。第二种是定长字符串整体填空格读出来 rstp 之后就是空串。第三种是针对数值字段的哨兵值比如定义 -1 表示没有数据这要求分析代码在算均值之前先把这个值剔掉否则会把分布整体拉偏。第四种是二进制 0主要用在时间日期字段上表示该时间点没有记录。这四种机制里前两种在数据清洗时会被自动吞掉后两种必须显式处理。我在做 datalog 转表的时候会专门加一列标记字段的有效性把哨兵值和正常值分开存宁可多一列也不要让脏值混进统计口径。血泪经验是一颗料的某个参数全部是 -1被当成真实值算出来的 CPK 会非常好看然后被拿去汇报。4.2 Optional Data 位图位从低位数起置 1 表示这一项别信有些记录里可选字段的取值范围是全值域包括 -1所以没法用哨兵值区分。这种情况下规范在记录里放一个 Optional Data 字节每一位对应后面一个可选字段位置 1 表示该字段的数据无效、应该忽略。位图的第 0 位对应紧跟其后的第一个可选字段依次往高位排。这里有两个必须同时满足的细节位序从低位开始以及置 1 只表示值不可信而不是字段不存在。字段本身仍然老老实实占着字节你把pos推进过去才行。很多新手看到位被置 1 就直接跳过不读结果后面的字段全部错位读出一堆脏字符串和天文数字。import struct # 以参数测试记录尾部的可选字段为例顺序与手册字段表保持一致 OPT_TAIL [RES_SCAL, LLM_SCAL, HLM_SCAL, LO_LIMIT, HI_LIMIT, UNITS, C_RESFMT, C_LLMFMT, C_HLMFMT, LO_SPEC, HI_SPEC] def read_optional(buf, pos, codes, endian): flags buf[pos] # 位图字节在前之后才是各字段的数据 pos 1 out {} for i, code in enumerate(codes): invalid (flags i) 1 # 第 i 位对应第 i 个可选字段 if pos len(buf): # 尾部省略字段整体不存在 out[code] None continue val, pos read_value(buf, pos, code, endian) out[code] None if invalid else val # 无效也要读读完照常推进 return out, pos函数里最容易被改坏的是pos的推进位置。注意read_value无论字段是否有效都必须调用因为字节流不会因为值无效就消失。out[code] None if invalid else val只是把结果置空不影响读取动作。这个顺序一旦写反前面几条记录可能碰巧正常遇到第一条带无效标志的记录就开始错位。4.3 尾部省略规则哪些字段可以整体不写除了位图规范还允许在记录末尾整体省略可选字段来节省空间但限制很严只有在某字段及其后所有字段都是可选字段且都没有有效数据时才能从该字段处截断。记录中间绝不能省略字段否则偏移量无法推算。这带来一个实现上的麻烦读取一条记录时你不知道尾部到底有没有被截断只能边读边判断pos有没有到达len(body)。我的习惯是在每个字段读取前加一次边界检查一旦pos len(body)就把剩余字段全部填 None 并结束而不是让它抛 IndexError。抛异常看起来更严格但产线上经常有半截文件一抛异常整批数据都进不了库。提示解析日志里把因尾部截断而缺失和因位图标记而无效分开统计。这两类在数据质量报告里含义完全不同混在一起就查不出是设备少写了字段还是测试项本身没测。5. 解析翻车的五类现场从长度错位到 V3/V4 混读的排查顺序解析器写完之后真正的工作才开始。下面这几类问题我在不同项目里都遇到过顺序大致按出现频率排。排查时建议从第一条开始逐项排除因为后面的现象很多是前面问题的次生结果。5.1 现象第二条记录开始整体错位报错位置离起点很远原因通常是把 REC_LEN 当成包含记录头的长度导致每条记录多跳 4 个字节或者端序读反把一个本该是 30 的长度读成 7680。还有一种更隐蔽的情况REC_LEN 读对了但某条记录的字段解码多消费或少消费了字节错误累积到几十条之后才在某个长度检查处爆出来。解决方式是给扫描器加自校验每读完一条记录检查off 4 rec_len len(data)并且统计所有记录的4 rec_len之和是否等于文件大小。只要这两条成立切分层面就是对的。之后再逐条比对记录类型的出现顺序是否符合 FAR → MIR → ... → MRR 的大致层级如果 TYP 值出现明显不该出现的组合说明字段层出错了跟切分层无关。5.2 现象PTR 的 RESULT 变成 1e38 量级或者一个极小的负数两个原因。一是把R*4当成定点整数读IEEE 754 的位模式按整数解释出来就是天文数字。二是字段偏移错了参数测试记录里 RESULT 之前有若干个一字节的标志字段少跳一个字节四字节浮点就从错误的位置开始读读出来的东西毫无意义但不报错。解决方式是严格按手册字段表的顺序推进不要凭记忆跳过任何字段哪怕那个字段你根本不用。定位手段是拿一条已知结果的记录把 RESULT 那 4 个字节单独抠出来用struct.unpack(f, ...)手工解一次和解析器输出比对。两者一致说明解码没问题不一致就往回退一个字段找偏移。5.3 现象时间戳整体偏移几个小时跨时区导入时更乱规范把时间字段定义成四字节无符号整数表示从 1970 年 1 月 1 日午夜起算的秒数但这个基准是本地时区的不是 UTC。写入方按自己的本地时区算读取方如果按自己的时区去解释两台机器不在同一时区就会整体偏移。另一个常见错误是把它当有符号整数读1970 年附近没问题一旦遇到高位被置上的值就变成负数。from datetime import datetime, timezone, timedelta def stdf_time(v, tz_hoursNone): if v 0: # 二进制 0 表示该时间点没有记录 return None if tz_hours is None: return datetime.fromtimestamp(v) # 按读取方本地时区解释 tz timezone(timedelta(hourstz_hours)) return datetime.fromtimestamp(v, tztz) # 已知写侧时区时显式指定解决方式是让时区成为显式参数绝不依赖运行环境的默认设置。导入历史数据时把写侧时区连同文件一起登记后续所有转换都按这个参数走。偏移量是整小时这一点本身就是个好线索——看到差 8 小时、差 5 小时基本可以直接判定是时区问题而不是数据损坏。5.4 现象可选字段读出脏字符串或负数但记录长度是对的位图位序搞反是最常见的原因。规范规定第 0 位对应第一个可选字段如果按最高位当第一个去解后面所有字段的有效性判断全部错位本该忽略的脏值被当成真值本该采信的数据被丢掉。另一种情况是尾部已经被截断代码还在按完整字段表硬读读到了缓冲区边界外的内容。解决方式很直接打印位图字节的二进制形式对照手册字段表逐个核对同时打印每个字段读取前后的pos看它是否与记录长度吻合。这一步做完问题基本就定位了。我一般会在解析器里留一个调试开关打开后把每条记录的所有字段名、值、偏移都打出来只在单个文件上跑不用于批量。5.5 现象老文件解析到一半抛异常或者字符串字段全是乱码多半是拿 V4 的规则去解 V3 的文件。两版之间记录类型有增删V4 新增了审计追踪、重测数据、晶圆配置等记录数据类型的表达也有变化V3 里不少字符串是定长写法V4 大量改用长度前缀的变长写法文件名的允许字符集和必需记录清单同样有调整。手册里专门有一章讲两版差异做兼容前必须完整过一遍。解决方式是在解析入口先读第一条记录的 FAR拿到版本号再决定用哪套字段表。如果文件连 FAR 都没有那它本身就不是合规文件别硬解。另一个实操经验是V3 文件在 V4 解析器上往往能读出头几条记录然后在某个变长字符串处崩掉这种读一半才炸的表现本身就是版本不匹配的信号。6. 用守恒关系验收解析器记录计数、Bin 汇总与测试项对账解析器能跑通不代表结果可信。我的习惯是给它配一套自动验收每次改动代码或者接入新机台的数据都先跑一遍守恒检查。这些关系不需要知道具体工艺参数纯粹靠文件内部的逻辑约束就能查出大部分错误。6.1 四条守恒关系当验收标准下面这几条覆盖了从字节层到业务层的三个维度任何一条不成立都说明解析或聚合环节有问题。校验项期望关系不成立时的典型含义字节守恒所有记录的 (4 REC_LEN) 之和 文件字节数切分错误、文件截断零件计数零件结果记录条数 零件计数记录里的总颗数并行 site 处理遗漏、跳过空记录Bin 汇总硬件 bin 与软件 bin 的计数之和 总颗数bin 字段偏移错误、可选字段误读测试项对账某测试项的汇总执行次数 该测试项的执行记录条数测试号关联错误、并行数据重复计入第三行那条尤其有用。bin 计数分布在硬件 bin 和软件 bin 两类记录里如果解析时把 bin 编号和计数对调了位置总和立刻对不上而且不报任何异常。我见过一次整整排查两天的问题最后就是 bin 计数字段和 bin 编号字段顺序搞反了靠这条守恒关系十分钟就能定位。6.2 抽样回读拿 hexdump 对一条参数测试记录自动化检查只能证明总量对得上不能证明每条记录都对。所以我还会做一次抽样回读随机挑一条参数测试记录把它在文件里的绝对偏移记下来用十六进制工具跳到那个位置手工核对前几个字段。这一步看起来原始但它能验证字段顺序这个最容易出错的地方。# 从解析日志里拿到某条记录的偏移比如 0x1A24C直接看这 64 字节 xxd -s 0x1A24C -l 64 lot_a.std # 输出前 4 字节是记录头长度、类型、子类型后面紧跟字段数据 # 把长度字段按小端手工解出来和解析器打印的 REC_LEN 比对对照的时候重点看三处记录头的长度是否与解析器一致紧跟头部的第一个定长字段值是否合理比如测试号通常不会大得离谱字符串字段开头那个长度字节是否等于后面可见字符的数量。三处都对上这条记录基本可信。那以后我每次接新机台的数据都强制先跑一遍守恒检查再抽样回读一条两关都过了才让它进数据库。这个习惯帮我挡掉过好几次总量看着对、单条全错的情况——尤其是并行测试的 site 数据数量凑巧吻合的概率并不低光看总数根本发现不了。希望帮到你。本文还有配套的精品资源点击获取