STDFとは？ Standard Test Data Format (V4) 完全ガイド

1. STDFとは何か

STDF（Standard Test Data Format、標準テストデータフォーマット）は、半導体テスト装置（ATE）で測定された結果を保存するために考案された、簡潔・柔軟・高移植性を兼ね備えたバイナリデータ形式です。1985年に Teradyne（テラダイン）社によって開発され、完全な仕様公開とベンダー中立性を基盤として、世界中の自動テスト装置（ATE）業界における事実上の業界標準（de-facto standard）として定着しました。

テスターがウェーハ上のダイ（Die）やパッケージングされた個々の半導体デバイスを測定する際、パラメトリック測定値、合否判定（Pass/Fail）、Bin（分類）判定、およびテスト条件をバイナリファイルに記録します。これを一般に データログ（datalog）と呼びます。通常、1つの STDF ファイルには、1回のテスト工程（1回の Insertion）で測定された1ロット（Lot）分のデバイスの全テストデータが格納されます。

重要概念：STDF は 固定レイアウトのレポートでもなければ、特定のリレーショナルデータベースのテーブルでもありません。厳密に仕様化された 論理レコード型（Logical Record Types）の連続したストリームです。各レコードは、テスト実行の特定の要素（個別デバイス、ウェーハ、1つのパラメトリック測定、Bin 集計カウントなど）を独立して記述します。そのため、データがメモリバッファ上にあるか、ローカルディスク上のファイルにあるか、ネットワーク経由でリアルタイム転送されているかを問わず、特定のシステム構成やデータベースエンジンに依存せず同一の仕様で扱えます。

2. STDF が存在する理由

ATE 業界が発展するにつれ、装置メーカー各社はイーサネットなどの共通ネットワーク規格を導入しました。しかし、極めて深刻な課題が残されていました。異なるメーカーのテスター間において、テスト結果データの形式がまったく互換性を持たず、時には同一メーカーの装置ラインナップ間でもフォーマットが異なっていたのです。

業界共通の標準フォーマットがなければ、すべての半導体ファブ（Fab）や組立・テスト受託企業（OSAT）は、テスターのメーカーごと、さらには装置型番ごとに異なる専用パーサーや分析ツールを個別にスクラッチ開発しなければなりません。STDF はこのデータ分断を解消する統一コンテナを提供し、以下の絶大なメリットをもたらしました：

• テスターが余計なフォーマット変換処理を行わず、自らのネイティブ表現のまま生の測定結果を超高速に記録可能。
• 中央の分析システムや歩留まり管理システム（YMS）が、単一のパーサーであらゆるテスターのデータを一括受入可能。
• 社内エンジニアリング網や顧客企業へ、標準化された信頼性の高いデータを容易に共有可能。
• 高性能なレポーティングおよび歩留まり解析ツールを一度開発すれば、すべてのファブや OSAT 環境で即座に活用可能。

Teradyne 社は STDF の仕様を囲い込まず、業界全体へ無償公開しました。その結果、半導体製造・テストのエコシステム全体でデータが統一され、歩留まり解析の効率と生産性が飛躍的に向上しました。

3. 設計目標

STDF の仕様策定にあたっては、明確な工学的目標が設定されました：

• 半導体テスターやレーザートリマーなど、あらゆるテスト装置から出力されるデータを漏れなく格納できること。
• データの「長期保存（ストレージ）」と「ネットワーク伝送」の双方に共通のバイナリフォーマットを提供すること。
• 特定の OS やプラットフォームに依存しない、ポータブルなレポート作成・解析ツールの共通基盤となること。
• データメッセージ構造をデータベース形式から分離し、双方が独立して進化・拡張できること。
• オプションデータ、欠損値、無効データの明示的処理を標準サポートすること。
• 開発者やエンジニアのために、簡潔かつ完全な公式仕様ドキュメントを提供すること。
• ユーザー企業が自社のリレーショナルデータベースや分析システムに合わせて、容易にデータを変換・ロードできること。

4. STDF ファイルの構造

STDF ファイルの実体は、バイナリレコード（Record）が先頭から末尾まで連続して並んだストリームです。すべてのレコードは、その種類やサイズに関係なく、例外なく同一の 4バイトの標準レコードヘッダー から始まります：

(REC_TYP, REC_SUB) のペアによって、各レコードの種類が一意に特定されます。REC_TYP によるグループ化のおかげで、解析パーサーは内部フィールドをすべてデコードしなくても、関心のないレコード群（例：特定のテスト測定値）を REC_LEN 分だけスキップして目的のサマリーレコードへ瞬時にジャンプできます。

レコードグループ (REC_TYP)

バイト順（エンディアン）と CPU_TYPE 判定

CPU アーキテクチャによって、整数や浮動小数点数をメモリに格納するバイト順（エンディアン）が異なります（x86/x64 や ARM リトルエンディアン、旧 SPARC や Motorola ビッグエンディアンなど）。STDF ではテスターが高速に記録できるよう、テスター自身のネイティブなバイト順でそのまま書き出すことを認めています。

パーサーがファイルのエンディアンを判別できるよう、ファイルの第1バイトに配置される FAR レコード内に CPU_TYPE フィールド（1バイト）が格納されています。FAR レコードヘッダーの REC_LEN（2バイト）を読み取り、値が 2 であればテスターと読み取り環境のエンディアンが一致しており、512（0x0200）であれば逆エンディアンであるため、パーサー側でバイトスワップを行う必要があります。

日時データの表現

STDF 内の日時フィールド（開始時刻、終了時刻など）は、1970年1月1日午前0時（UNIX Epoch）からの経過秒数を表す 4バイト符号なし整数（U*4）として記録され、テスター設置場所のローカルタイムゾーンが基準となります。

5. フィールドデータ型コード

STDF 仕様書では、フィールドのデータ型を表現するために簡潔で規則的な記号コードが使われます。例えば R*4 は 4バイトの実数（単精度浮動小数点数）を意味します。アスタリスク（*）の後の数値はバイト数を示します。

6. オプション、欠損値、無効データの扱い

STDF の多くのフィールドは Optional（省略可能） として定義されています。テスト環境によっては特定の情報（オペレーター名、温度、テスト仕様リミットなど）が存在しない場合があるためです。欠損または無効であることを明示するため、STDF では以下の標準メカニズムが用意されています：

• 定義済みの予約値： 文字列フィールドの長さバイトが 0 の場合は「未定義」、数値フィールドにおいて特定の予約値（例：最大値や -1）が設定されている場合は「無効/欠損」を意味します。
• オプションデータ用ビットフィールド（OPT_FLAG 等）： レコード内の専用フラグバイトの各ビットが、後続の個別フィールドに有効な測定値が存在するかどうかを示します。
• レコード末尾の省略： レコード末尾に位置する連続したオプションフィールドがすべて欠損値である場合、ファイルサイズを節約するためにレコード長（REC_LEN）を切り詰めて末尾フィールドを物理的に省略することが認められています。ただし、レコードの中間にあるフィールドを途中で詰めて省略することは許されません。

7. 必須レコードと初期シーケンス

有効な STDF V4 ファイルには、以下の 4 つの必須レコード が必ず含まれていなければなりません：

• FAR — ファイル内に厳密に 1 つだけ存在し、ファイルの先頭（最初のレコード）でなければなりません。
• MIR — ファイル内に 1 つだけ存在し、FAR（および任意の ATR）の直後に配置されます。
• PCR — ファイル内に 1 つ以上存在する必要があります（全体サマリー用または各テストサイト用）。
• MRR — ファイル内に厳密に 1 つだけ存在し、ファイルの末尾（最後のレコード）でなければなりません。

ファイルの先頭部分に位置する必須の開始配置規則を 初期シーケンス（Initial Sequence） と呼びます：

8. 全24種類の STDF V4 レコード完全解説

9. ファイル内のレコード配置順序

STDF ファイル内のレコードは、実際のテスト工程の流れに沿って時系列順に整然と配置されます。量産テストの形態に応じた代表的なレコードシーケンスは以下の通りです：

パッケージテスト 1 ロット（完全なデータログ）

サマリーのみ（個別デバイスのデータログなし）

大量生産ライン等でストレージを節約するため、個別の測定値ブロック（PIR…PRR）を完全に省略し、ロットヘッダー（FAR, MIR）と全体の集計サマリー（TSR, HBR, SBR, PCR, MRR）のみで構成される軽量ファイル形式です。

ウェーハプローブ（ウェーハテスト）1 ロット

ウェーハマップ専用ファイル（Wafer-map-only）： 詳細なパラメトリック測定値レコード（PTR/MPR/FTR）を省き、ダイごとの座標と Bin 判定（PIR/PRR）のみを保持することで、ウェーハマップの超高速描画とファイル容量の劇的な削減を両立した構成です。

マルチサイト並列テスト

複数のテストヘッドやテストサイト（Multi-Site）で同時測定を行う場合、異なるダイのテストレコードがインターリーブ（交互に入り混じって）記録されます。複数の PIR が先に発行され、テスト実行中に各ヘッド・サイト番号がタグ付けされた PTR/MPR/FTR が出力され、ダイの測定が完了した順に PRR が書き込まれます。該当ヘッド上の全ダイが完了した時点で WRR が出力され、PCR ブロックには各サイト別の PCR と、全体合算用（HEAD_NUM = 255）の PCR が記録されます。

10. スケーリング、単位、規格値

PTR および MPR レコード内では、測定値（RESULT）、テスト規格下限（LO_LIMIT）、上限（HI_LIMIT）などの数値データはすべて、UNITS フィールドで指定された基本単位（Base Unit）に正規化された実数として保存されます。

例えば電流であれば「uA」ではなく基本単位の「AMPS（アンペア）」として保存されます。そのため、解析ソフトウェアは単位が一致する任意の値同士で直接演算を行うことができます。画面やレポートに人間が読みやすい形式で表示するために、スケーリング指数（_SCAL）と ANSI-C フォーマット文字列（C_RESFMT）が併用されます：

11. ピンマッピングレコードの活用

複雑なデバイスのテストでは、テスターの物理計測チャネルと、IC パッケージのピン名（またはパッド名）との対応付けを管理する必要があります。STDF V4 では以下の 3 つのレコードが連携してピン情報を構築します：

• PMR (Pin Map Record)： テスターチャネル番号とデバイスピン名の関連付けを定義し、一意の PMR インデックス番号（1〜32,767）を割り当てます。ピンの論理名・物理名、テストヘッド・サイト番号も記録されます。
• PGR (Pin Group Record)： 複数の PMR ピン（例：「ADDR_BUS」や「DATA_BUS」）を 1 つのグループとして束ね、独自のグループインデックス（32,768〜65,535）を付与します。
• PLR (Pin List Record)： ピンやグループの信号表示形式（基数：2進/8進/10進/16進、ピン動作モード、表示シンボル文字）を定義します。

解析ソフトウェアが FTR や MPR のファンクションテスト結果をデコードする際は、レコード内の PMR インデックス配列を参照してどのピンでフェイルが発生したかを突き止め、PMR/PGR/PLR を組み合わせてエンジニアが理解しやすいピン名・ベクタ波形として可視化します。

12. メモリリペア（冗長救済）情報の格納

STDF は単なる合否判定にとどまらず、メモリ半導体（DRAM, NAND, SRAM）の冗長回路（Redundancy）解析やレーザーフューズブロー、欠陥救済工程に必要なリペアデータを格納できます。

デバイスごとのリペア情報は、PRR レコード内の PART_FIX フィールドに格納されます。このフィールドはアプリケーション依存の可変バイト列（ビットマップ、整数配列、救済アドレス文字列など）であり、先頭 1 バイトが後続のデータ長を示します。後工程のレーザーリペア装置や解析ツールと連携してチップの冗長救済を実行するために広く活用されています。

13. STDF ファイル命名規則

STDF 公式仕様書では、以下のファイル命名規則が推奨されています：

• ファイル名本体 (filename)： 英大文字、英小文字、数字、アンダースコア（A–Z, a–z, 0–9, _）で構成される 1〜39 文字の文字列で、英字から始まる必要があります。
• 拡張子： 大文字・小文字を区別する Linux/Unix システムでは小文字の .std または .stdf が最も一般的に使用されます。
• 記号の制限： 過去の独自仕様で使われていたドル記号（$）は、OS のシェル環境等で予期せぬ不具合を招くため、公式仕様では使用が禁止されています。
• ピリオドの使用： ファイル名内のピリオド（ドット）は 1 つだけにとどめ、拡張子を簡潔に保つことが推奨されます。

14. STDF V3 と V4 の違い

STDF は 1985 年の導入以来、半導体テスト業界の標準として定着しました。世界中の半導体メーカーや ATE ベンダーからの多数の機能改善要求を統合し、Teradyne 社が発表したのが現在最も広く使用されている STDF Version 4 です。主な変更点は以下の通りです：

• 4大必須レコードの確立： V3 では MIR と MRR のみが必要でしたが、V4 では FAR、MIR、PCR、MRR の 4 レコードが必須となり、ファイルは必ず FAR で始まらなければならなくなりました。
• 新規レコードの追加： ATR（監査証跡）、PCR（パート数集計）、PGR（ピングループ）、PLR（ピンリスト）、RDR（再テスト）、SDR（サイト説明）、および MPR（複数結果パラメトリック）レコードが新設されました。
• 冗長レコードの廃止と統合： V3 の静的仕様レコード（PDR, FDR）が廃止されて各テストの最初の PTR/FTR に統合され、サイト別レコード（SHB, SSB, STS, SCR）は各レコードの HEAD_NUM / SITE_NUM フィールドへ一本化されました。
• パーツ数カウントの独立： MRR からパーツ集計カウントが独立した PCR レコードへ分離されました。
• エンディアン判定の一元化： CPU_TYPE と STDF_VER は FAR レコードのみに格納されるようになりました。
• ピンマッピングの刷新： V3 の単一 PMR レコードが、PMR（個別ピン）、PGR（グループ）、PLR（表示書式）の 3 レコードへ構造化されました。
• 最新の表示書式に対応： ANSI-C 書式文字列（C_RESFMT など）や設計規格リミット（LO_SPEC / HI_SPEC）が PTR/MPR に追加されました。
• 新データ型の導入： D*n（ビットストリーム）および N*1（ニブル）が新設され、B*n のビット順序規則が明確化されました。
• 継承されたレコード： BPS、EPS、GDR、DTR レコードは V3 から構造を変更せずに維持されています。

15. 用語集

↑トップに戻る