读懂STDF：记录头、字节序与测试数据状态机解析

简介这份PDF手册是STDFStandard Test Data Format第4版规范文档面向半导体测试工程师、ATE系统开发者和测试数据分析人员用于解决不同厂商测试系统间测试数据兼容与交换问题。文档系统定义FAR、MIR、MRR等记录结构覆盖硬件与软件分类、晶圆及零件测试信息、参数测试结果并纳入ATR、RDR等新增记录对并行测试支持、字段定义和数据表示方法也有说明还涉及文件名与文件排序、修复信息存储、引脚映射记录及V3与V4差异。包内为1个PDF文件约550KB便于随查随用。已有669人学习。读者可据此理解STDF记录层级与字段含义掌握测试数据读写、转换和追溯审计的依据也能对照版本差异处理历史数据与并行测试场景适合需要规范级参考的中高级从业者。1. 一份测试 log 为什么能被十年后的软件读懂先给一个反直觉的结论解析 STDF 最核心的能力不是「读懂每一条记录」而是「跳过你看不懂的记录」。半导体测试数据格式 STDF 的 V4 规范里记录头固定 4 字节其中 2 字节是长度、1 字节是族号、1 字节是族内编号。任何解析器拿到一条不认识的记录只要读长度就能整段跳过不用中断、不用报错。正是这个设计让一台十年前出厂的 ATE 产出的数据能被今天刚写的测试数据分析脚本读起来不崩。搞懂这套结构你才知道为什么它敢自称「与数据库架构无关」也才能在数据对不上的时候快速定位是格式问题还是语义问题。2. 记录头与类型码三个字段怎么撑起一个自描述二进制流STDF 文件本质上是记录的串联没有全局索引没有分块目录也没有 XML 那样的标签闭合。它把「自描述」这件事压缩到了极致的 4 个字节里剩下的全部交给规范文档。这种设计在今天看有点朴素但在测试机每秒吐几十万条结果的场景下每一条记录的解析开销都是实打实的成本。2.1 REC_TYP 与 REC_SUB用两个字节做二维寻址每条记录以三字段头开始REC_LEN是两字节无符号整数表示头之后的数据字节数不包含头本身的 4 字节REC_TYP是一字节无符号整数标识一组相关记录类型REC_SUB也是一字节标识该组内的具体成员。前两个字段合起来唯一确定记录类型。这里有个容易忽略的约束REC_LEN是两字节意味着单条记录的 body 最大 65535 字节。测试数据里如果要把一整片 wafer 的原始采样塞进一条记录就必须拆成多条这是后面设计 GDR通用数据记录时必须考虑的上限。族号的分组逻辑不是按时间顺序排的而是按数据的逻辑归属排的REC_TYP含义该族下的 REC_SUB0文件级信息10 FAR 文件属性、20 ATR 审计追踪1按 lot 采集10 MIR、20 MRR、30 PCR、40 HBR、50 SBR、60 PMR、62 PGR、63 PLR、70 RDR、80 SDR2按 wafer 采集10 WIR、20 WRR、30 WCR5按 part 采集10 PIR、20 PRR10按测试项采集30 TSR15按测试执行采集10 PTR、15 MPR、20 FTR20按程序段采集10 BPS、20 EPS50通用数据10 GDR、30 DTR族号小于 200 的编码全部保留给规范后续扩展大于 200 的留给用户自定义。这个划分很关键——它意味着你完全可以在自己的测试机上加私有记录而不会和标准记录冲突代价是别的厂商的分析软件只会安静地跳过它们。下面是最小可用的记录迭代器它体现了「长度前缀」带来的全部好处import struct # STDF 记录头固定 4 字节REC_LEN(U*2) REC_TYP(U*1) REC_SUB(U*1) # 这里先按小端解真实字节序要等读出 FAR 的 CPU_TYPE 后再定见第 3 章 HEADER struct.Struct(HBB) def iter_records(buf): 流式遍历 STDF 记录不认识的类型直接按长度跳过 off 0 while off 4 len(buf): rec_len, rec_typ, rec_sub HEADER.unpack_from(buf, off) body buf[off 4: off 4 rec_len] # REC_LEN 不含头 4 字节 if len(body) rec_len: # 文件被截断提前退出 break yield rec_typ, rec_sub, body off 4 rec_len # 关键用长度做指针推进 # 只关心 PTR15/10和 FTR15/20其余一律略过 for typ, sub, body in iter_records(open(lot0001.std, rb).read()): if (typ, sub) in ((15, 10), (15, 20)): pass # 交给具体的字段解析器参数说明rec_len是 body 字节数rec_typ和rec_sub各一字节。逻辑上有两点值得强调第一指针推进完全依赖rec_len解析器不需要知道任何记录的内部结构就能正确走到下一条——这就是「未知记录可跳过」的实现基础第二body长度不足时直接break避免文件尾部被意外截断时读出脏数据。这套机制的代价也很明显记录内部字段的布局、顺序、类型文件里一个字都没有全在规范文档里。所以 STDF 从来不是一个自包含格式文档本身就是协议的另一半。你换一个版本的解析库很可能就是换了一份字段表。2.2 类型码表C*n、R*4、B*n 背后是同一套内存模型记录内部字段用一套紧凑的类型码描述一眼能看出宽度和符号性比如R*4就是 4 字节浮点。完整列表不长但每一条都有它的存在理由类型码含义对应的 C 类型C*12定长字符串不足右补空格char[12]C*n变长字符串首字节为无符号长度≤255char[]C*f变长字符串长度存在本记录的其他字段里char[]U*1/U*2/U*4无符号整数unsigned char/short/longI*1/I*2/I*4有符号整数char/short/longR*4/R*8四字节/八字节浮点float / doubleB*6定长位编码数据char[6]V*n变长首字节是类型码数据紧随其后—B*n变长位编码首字节为字节数char[]D*n变长位编码前两字节为位数≤65535char[]N*1半字节整数低 4 位存第一个值—kxTYPE数组元素个数 k 在记录前面的字段里TYPE[]三个变长位编码类型是踩坑高发区因为它们的单位不一致B*n首字节是字节数D*n前两字节是比特数N*1压根按半字节算一个字节要塞两个值、奇数个时高半字节补零。写解析时把D*n当字节数读后面的字段会整体错位一格而且不会抛异常——数据看起来「有值」只是全错。def read_c_n(body, pos): C*n首字节是字节数后面跟 ASCII 内容 n body[pos] return body[pos 1: pos 1 n].decode(ascii, replace), pos 1 n def read_d_n(body, pos): D*n前两字节是比特数不是字节数末字节高位必须为 0 nbits body[pos] | (body[pos 1] 8) nbytes (nbits 7) // 8 # 向上取整才是实际占用 return body[pos 2: pos 2 nbytes], pos 2 nbytes def read_n_1(body, pos): N*1一个字节装两个 4 位值先低后高 b body[pos] return (b 0x0F, (b 4) 0x0F), pos 1read_d_n里那个(nbits 7) // 8是必须的规范允许位数不是 8 的整数倍最后一个字节的高位空闲位必须填 0。如果你按位读取器逐位消费务必从每个字节的最低位开始——这是规范里明确写死的位序约定和很多网络协议的 MSB-first 是反的。数组类型kxTYPE的 k 不在数组本身里而在本记录更靠前的字段中。这意味着解析器必须严格按规范给的字段顺序读不能跳读、不能随机访问——这也是为什么 STDF 解析库通常实现成一个顺序游标cursor而不是一次性映射成结构体。3. 字节序与缺失值CPU_TYPE 和 Optional Data 位图解决了什么如果说记录头解决的是「结构」问题这一章解决的是「值」的问题。两个看起来很小的设计实际决定了 STDF 能不能在异构机器之间流通。3.1 CPU_TYPE字节序差异为什么放到读的时候再处理不同处理器的数据表示差异是老问题同一个 4 字节浮点不同厂商的机器位序可能完全不同甚至同一厂商不同型号之间也不兼容。STDF 的解法很克制文件属性记录 FAR 里有一个CPU_TYPE字段标明写这个文件的处理器类型。写文件时用本机原生表示不做任何转换读文件时读端检查CPU_TYPE如果不兼容就在读取过程中逐条转换。这个选择带来的三个好处规范里写得很直白所有测试机和主机都能用原生表示读写本地数据本地测试和数据分析不会被转换开销拖慢转换发生在读取路径上对上层透明。第三条尤其重要——数据分析软件拿到的是已经转好的本机表示不需要在每个业务函数里操心字节序。代价是把复杂度全部压给了读端。写端几乎零成本读端必须实现全类型的转换而且每个文件都必须正确填写CPU_TYPE填错了比不填更糟。这里有个规范没写、但实现上绕不开的问题你读第一条记录之前并不知道这个文件是什么字节序。常见的实现思路是先按某一种字节序解REC_LEN如果算出的长度明显不合理比如超出文件剩余字节数或者后续记录无法对齐就换另一种字节序重解。因为 FAR 通常是文件里的第一条记录且它的 body 只有寥寥几个单字节字段这个探测过程非常短。import struct def detect_byteorder(buf): 用记录头长度做启发式探测不合理的 REC_LEN 说明字节序猜错了 for fmt in (, ): rec_len, rec_typ, rec_sub struct.unpack_from(fmt HBB, buf, 0) # 记录头之后必须还有 rec_len 字节否则这条长度不可信 if rec_len 4 len(buf) and rec_typ 200: return fmt raise ValueError(无法确定字节序文件可能损坏) fmt detect_byteorder(buf) # 后续所有数值字段都用这个前缀解 cpu_type buf[4] # FAR 的第一个 body 字节单字节不受字节序影响参数说明fmt是struct的字节序前缀表示小端、表示大端后面拼类型码时统一带上即可。cpu_type是单字节字段读它本身不需要知道字节序这一点让探测逻辑可以先于转换完成。实践中更稳妥的做法是把CPU_TYPE记进解析上下文后面每读一条记录都检查一次是否与当前fmt匹配防止有人在同一个文件里混入不同来源的数据。3.2 缺失值三套写法长度 0、哨兵值、位图标记测试数据里「这个值没有」是常态某个测试项在这一片 wafer 上没跑、某个 bin 的计数在早期阶段还不存在。很多格式用 null 或 NaN 表示STDF 选了另一条路——可选字段必须存在但可以用约定值标记它无效。具体有三套写法按字段类型分字段类型缺失/无效的标记方式变长字符串长度字节置 0定长字符串整段填空格定长二进制在 Optional Data 字节里置对应标志位时间和日期二进制 0有符号/无符号整数预定义哨兵值常见是 -1即全 1浮点预定义哨兵值第三套是 Optional Data 位图每条带可选字段的记录里有一个专门的字节字段第 n 位对应记录里第 n 个可选字段。位被置 1 表示该字段数据无效应当忽略。这个语义和很多人的直觉是反的——不是「置 1 表示有效」是「置 1 表示别信」。写反了不会报错只会让一堆本该被丢弃的脏值流进下游统计。def get_optional(body, pos, opt_flag, bit_index, reader): 按 Optional Data 位图判断字段是否可用不可用则返回 None # 注意位被置 1 表示该字段无效需要跳过 if opt_flag (1 bit_index): return None return reader(body, pos) # 假设 opt_flag 来自本记录的 OPT_FLAG 字段 val get_optional(body, 12, opt_flag, 3, read_r_4) if val is not None: accumulate(val)参数说明opt_flag是本记录的 Optional Data 字节bit_index是该字段在记录里的序号从 0 起reader是对应的类型读取函数。逻辑上要注意两点即使字段被标记为无效它的字节仍然占据空间指针必须照常前进否则后续字段全部错位返回None之后下游的聚合函数必须显式处理空值不能默认当 0。还有一条容易漏的规则记录末尾的可选字段可以被直接省略前提是它本身及其后所有字段都是缺失或无效状态。这样可以省存储但绝不允许从中间省略。这直接导致了 5.1 那个坑——很多解析器假定字段偏移固定遇到被截断的记录直接越界。4. 记录时序从 MIR 到 MRR文件顺序本身就是一台状态机STDF 没有外键没有引用表。一条 PTR 记录里不会重复写它属于哪个 lot、哪片 wafer、哪颗芯片这些上下文靠文件里的位置顺序隐含表达。换句话说解析器必须是一个流式状态机读错顺序就全错。4.1 五级层次lot / wafer / part / test / program segment从族号就能看出层次0 是文件级1 是 lot 级一次生产批次2 是 wafer 级5 是 part 级15 是单次测试执行级20 是程序段级。一次典型测试的数据流大致是FAR文件属性必须是第一条可选的 ATR审计追踪MIR主信息记录描述这次测试任务可选的 RDR重测数据可选的 SDR、PMR/PGR/PLRsite 描述、引脚映射、引脚组、引脚列表PCRpart 计数、HBR/SBR硬件/软件 bin 定义每片 waferWIR → 若干 part 的 PIR … PRR → WRR可能夹一条 WCR每个 partPIR → 若干 PTR/MPR/FTR → PRR全部结束后MRR主结果记录这个顺序不是建议是约束。解析器维护一个「当前 lot / 当前 wafer / 当前 part / 当前 site」的上下文栈遇到 MIR 重置 lot 上下文遇到 WIR 重置 wafer 上下文遇到 PIR 重置 part 上下文。PTR 里的数值只对当前上下文有效。class StdfContext: def __init__(self): self.lot None # MIR 建立 self.wafer None # WIR 建立 self.part None # PIR 建立 self.site None # SDR 建立 def feed(self, typ, sub, parsed): # 遇到层级记录就重置下层上下文避免脏状态跨 wafer 泄漏 if (typ, sub) (1, 10): self.lot, self.wafer, self.part parsed, None, None elif (typ, sub) (2, 10): self.wafer, self.part parsed, None elif (typ, sub) (5, 10): self.part parsed elif (typ, sub) (15, 10): return (self.lot, self.wafer, self.part, parsed) return None参数说明parsed是已经按字段表解好的字典或对象typ/sub来自记录头。这个状态机的价值在于它让记录本身不需要携带冗余的外键文件体积能压下来代价是数据一旦乱序整段结果都会挂到错误的 wafer 上而且不会报错。4.2 Pin Map 与 Site并行测试下结果怎么对回物理引脚引脚信息是最容易被误解的部分。PTR 和 FTR 里只要出现了引脚相关的字段用的都不是物理引脚号而是本文件内的引脚索引PMR_INDX。真正的物理引脚号、它属于哪个测试头、哪个 site都记在引脚映射记录 PMR 里。PMR 的关键字段是HEAD_NUM测试头编号、SITE_NUMsite 编号、PIN_NUM物理引脚号和PMR_INDX本文件内的索引。同一颗物理引脚在不同 site 上可能是不同的PMR_INDX因为并行测试时每个 site 有独立的引脚映射。PGR 把引脚分组成组PLR 则给出一个引脚列表用于描述「这批测试共用这些引脚」的场景。这带来的实践结论很直接只看 PTR 里的PMR_INDX是不知道测的是哪个引脚的必须先用 PMR 建一张(HEAD_NUM, SITE_NUM, PMR_INDX) → PIN_NUM的映射表再做关联。多 site 并行时如果 site 维度漏了不同 site 的数据会被错误合并到同一个引脚上——这是 5.5 那个坑的根源。V4 相比更早的版本正是在这个方向上做了增强引入了独立的 site 描述记录把并行测试的 site 概念从隐含变成显式新增了审计追踪记录和重测数据记录让数据来源和重测链路可以追溯还补了程序段起止记录、通用数据记录和文本记录让测试过程里的非结构化信息也有正式归宿。5. 解析 STDF 时的常见问题五条会让人翻车的记录规范读得再细落到代码里还是会在几个固定的地方出问题。下面五条是我在真实数据上反复撞过的每条都按「看到什么现象 → 底层原因 → 怎么改」写。5.1 硬编码字段偏移遇到尾部省略的记录直接崩现象大多数文件解析正常偶尔某几个文件在解析 PTR 时抛越界异常或者读出来的后几个字段是垃圾值。原因规范允许记录末尾的可选字段在被标记为缺失/无效时整段省略前提是它和它之后的所有字段都无效。很多实现直接把记录 body 当成一个固定布局的结构体用struct.unpack一把解完一旦 body 比预期短要么抛异常要么读到不属于这条记录的内存。解决改成顺序游标每读一个字段前先检查pos 字段宽度 len(body)越界就按「剩余字段均为无效」处理并跳出。游标式解析还有额外好处字段表变了只改读取顺序不用重算偏移常量。5.2 把 D*n 的长度当字节数位图整体错位一格现象含位编码字段的记录比如某些 bin 汇总、引脚状态位图解析出来后后面的字段值全部错乱但字段本身的值看起来「像个正常的数」。原因D*n的前两字节存的是比特数不是字节数B*n存的才是字节数。两者前缀宽度也不同——B*n一字节D*n两字节。写解析器时如果按B*n的逻辑套到D*n上指针会少走一个字节外加若干位。解决给每个变长类型单独实现读取函数并在函数名里带上单位read_d_n_bits、read_b_n_bytes强制调用方显式选择。不要写一个通用的「变长读取」函数那个函数迟早会被人用错。5.3 定长字符串不裁空格去重和关联全部失效现象按测试项名称做分组统计本该是同一组的记录被分成好几组或者按 bin 名称关联定义表时大量匹配不上。原因定长字符串类型C*12在内容不足时必须左对齐、右侧补空格。如果有人手工填了较短的名字而没补或者读取时没做右侧裁剪字符串比较就会因为尾部空格不一致而失败。空格的另一个陷阱是整段填空格本身是「该字段无效」的合法表示裁剪后变成空串语义又变了。解决读取时统一rstrip()再比较但要先判断原始内容是否全为空格——全空格说明字段无效应该返回None而不是空串。这两个分支不能合并。5.4 时间戳按 UTC 解析跨时区数据整体偏移现象同一批数据在不同地点的分析系统里时间轴差了好几个小时或者某些老文件的时间显示成负数。原因规范里的时间日期字段是 4 字节无符号整数表示自某一固定基准时刻起的秒数且明确是按本地时区调整过的不是纯 UTC。解析时如果一律当 UTC 处理跨时区就会出现固定偏移。另一个坑是无符号性——它是一个 32 位无符号值如果解析库按有符号 32 位整数解超出上限的那一天之后全部变成负数。解决读出来先按无符号处理再根据数据产生的时区做补偿不要假设所有文件都在同一时区。做时间序列对比前先把整批文件的时间基准对齐一次比事后逐条修正省事得多。5.5 把 PMR_INDX 直接当引脚号多 site 数据全串了现象单 site 数据看着没问题一上并行测试不同 site 的同一个引脚被合并成一条曲线或者引脚号对不上实际的探针卡布局。原因测试结果记录里引用的是本文件内的引脚索引不是物理引脚号。索引到物理引脚号的映射在引脚映射记录里而且映射是(测试头, site, 索引)三元组决定的。只用了索引这一维多 site 数据必然串。解决解析前先完整扫一遍所有引脚映射记录建好三元组映射表再做结果关联。如果一个文件里同一个索引在不同 site 下映射到不同物理引脚说明探针卡在不同 site 上的接线确实不同这是合法数据不是错误。注意这五条里有三条5.1、5.2、5.5不会抛异常只会安静地给出错误结果。解析器写完先拿一条已知答案的记录做断言比跑一万条数据看有没有崩更有效。6. 设计取舍为什么它选了「能省则省」而不是「严格校验」回头看这套格式它几乎每一个设计都在做同一个方向的取舍把校验和解释的责任推给读端把写端的成本压到接近零。长度前缀换来了跳过未知记录的能力代价是记录内部布局完全依赖外部文档写端用原生字节序换来了零转换开销代价是读端必须实现全类型转换、并且必须正确维护CPU_TYPE可选字段位次固定但允许尾部截断兼顾了偏移可预测和体积节省代价是解析器必须同时支持「字段存在但无效」和「字段整个不存在」两种状态记录顺序承载层级关系省掉了每条记录里的重复外键代价是乱序数据会静默错位。这些取舍放在今天看未必是最优解——如果重来一次可能会有人主张加一个可选的全局索引块或者给记录内部加轻量字段标签。但在测试机每秒产出几十万条结果、存储介质按兆字节计价的年代「每条记录少几个字节」是能算出来收益的。如果你想验证自己对这套结构的理解最直接的办法是做一次 round-trip用自己写的序列化器生成一条 PTR再用自己写的解析器读回来比对每个字段然后手工把文件里的字节序翻转测试转换路径是否还能还原出同样的值最后手工截断一条记录末尾的可选字段看解析器是崩、是报错、还是安静地返回一组None——第三种才是对的。从那以后我每次接一个新的测试数据源都会先把第一条文件属性记录单独解一遍把CPU_TYPE、版本号、记录总数打印出来再决定后面用哪套字段表。这一步只花两分钟但能省掉后面好几个小时的「数据看起来没问题但结论就是不对」。希望帮到你。本文还有配套的精品资源点击获取