Was ist STDF? Der vollständige, leicht verständliche Leitfaden

1. Was STDF ist

STDF (Standard Test Data Format) ist ein einfaches, flexibles, portables, binäres Datenformat zum Speichern der Ergebnisse von Halbleiter-Testgeräten. Es wurde von Teradyne entwickelt und 1985 erstmals vorgestellt. Weil es gut dokumentiert und herstellerneutral ist, wurde es zum De-facto-Standard in der gesamten Branche der automatischen Testgeräte (Automatic Test Equipment, ATE).

Wenn ein Tester einen Die auf einem Wafer oder ein gehäustes Bauteil misst, schreibt er die parametrischen Messwerte, die Pass/Fail-Ergebnisse, die Bin-Zuordnungen und die Testbedingungen in eine STDF-Datei — üblicherweise als Datalog bezeichnet. Eine STDF-Datei enthält die Testdaten für ein Los von Bauteilen aus einer einzelnen Insertion (ein Durchlauf eines Loses durch den Test).

Der Grundgedanke: STDF ist keine Datenbank und kein starrer Bericht. Es ist ein definierter Satz logischer Record-Typen. Jeder Record beschreibt einen Teil des Testlaufs (ein Bauteil, einen Wafer, eine einzelne Messung, einen Bin-Zähler und so weiter). Weil die Daten als logische Records beschrieben sind, funktioniert dasselbe Format, ganz gleich ob die Daten in einem Speicherpuffer, in einer Datei auf der Festplatte liegen oder über ein Netzwerk übertragen werden — unabhängig von einer bestimmten Datenbank- oder Netzwerkarchitektur.

2. Warum STDF existiert

Als die ATE-Branche reifer wurde, bauten die Hersteller Netzwerk- und Analysesysteme rund um gängige Standards wie Ethernet. Doch eine gravierende Lücke blieb: Testergebnisdaten waren zwischen Testern verschiedener Hersteller nicht kompatibel — und manchmal nicht einmal zwischen Produktlinien desselben Herstellers.

Ohne ein gemeinsames Format bräuchte jede Fab und jeder OSAT (Assembly- & Test-Dienstleister) einen eigenen Parser für jede Maschine. STDF schließt diese Lücke. Es stellt einen einzigen gemeinsamen Container bereit, sodass:

• ein Tester seine Rohergebnisse schnell in seiner eigenen nativen Darstellung schreiben kann;
• eine zentrale Datenbank-Engine mit einem einzigen Programm Daten von einer breiten Palette von Testern akzeptieren kann;
• Daten in einer gut dokumentierten, gründlich getesteten Form zurück in interne Netzwerke exportiert werden können;
• portable Berichts- und Analysesoftware einmal geschrieben und überall verwendet werden kann.

Teradyne zieht aus dem Standard keinen direkten kommerziellen Nutzen — es veröffentlichte STDF gerade deshalb, damit die gesamte Branche mit einem gemeinsamen, vollständig dokumentierten Format produktiver arbeiten kann.

3. Entwurfsziele

Der Entwurf von STDF folgte einer kleinen Reihe klarer Ziele:

• Testdaten für alle Halbleiter-Tester und -Trimmer speichern zu können.
• Ein gemeinsames Format sowohl für die Speicherung als auch für die Übertragung von Daten bereitstellen.
• Eine Grundlage für portable Berichts- und Analysesoftware bieten.
• Das Datennachrichtenformat vom Datenbankformat entkoppeln, sodass sich beide unabhängig voneinander weiterentwickeln können.
• Unterstützung für optionale (fehlende oder ungültige) Daten bieten.
• Vollständige, prägnante Dokumentation für Entwickler und Anwender liefern.
• Es Kunden einfach machen, eigene Berichte zu schreiben oder Daten für ihre eigene Datenbank umzuformatieren.

4. Wie eine STDF-Datei aufgebaut ist

Eine STDF-Datei ist einfach eine Folge von Records, einer nach dem anderen. Jeder Record — gleich welchen Typs — beginnt mit demselben 4-Byte-Record-Header:

Das Paar (REC_TYP, REC_SUB) identifiziert jeden Record-Typ eindeutig. Die Gruppierung nach REC_TYP erlaubt es Analyseprogrammen, Familien von Records schnell zu erkennen (zum Beispiel „alles, was pro Bauteil erfasst wird“). Alle Typ-/Sub-Typ-Codes unter 200 sind von Teradyne reserviert; Codes über 200 stehen für eigene Anwendungen frei zur Verfügung.

Record-Gruppen (REC_TYP)

Byte-Reihenfolge und der CPU_TYPE-Trick

Verschiedene Prozessoren (DEC, Motorola, Intel, IBM, Sun …) speichern Ganzzahlen und Gleitkommazahlen mit unterschiedlicher Bit-Anordnung. Anstatt jeden Tester zu zwingen, die Daten schon beim Schreiben umzuwandeln (was den Test verlangsamen würde), lässt STDF jedes System in seiner eigenen nativen Darstellung schreiben und hält im Feld CPU_TYPE des allerersten Records (des FAR) fest, welche CPU die Datei geschrieben hat. Wenn ein anderes System die Datei liest, prüft es CPU_TYPE und wandelt jeden Record nur bei Bedarf in seine eigene Darstellung um. Die Datenkonvertierung wird so beim Lesen transparent, und der Test wird nie verlangsamt.

Datum und Uhrzeit

Jedes Datums-/Zeitfeld ist eine vorzeichenlose 4-Byte-Ganzzahl, die die Anzahl der Sekunden seit Mitternacht des 1. Januar 1970 (UNIX-Epoche) in der lokalen Zeitzone zählt.

5. Datentyp-Codes

STDF verwendet kurze, gut erkennbare Codes für seine Feldtypen. Zum Beispiel bedeutet R*4 eine 4-Byte-Realzahl (Float). Die Zahl nach dem * ist die Größe in Bytes; ein Byte hat 8 Bit.

6. Optionale, fehlende & ungültige Daten

Viele Felder sind als optional gekennzeichnet. Ein optionales Feld muss dennoch im Record vorhanden sein, aber es gibt zwei Standardwege, um „dieser Wert ist nicht aussagekräftig“ auszudrücken:

1. Ein vordefinierter reservierter Wert bedeutet „fehlend“ — z. B. ein Längenbyte von 0 bei einer Zeichenkette oder eine bestimmte Zahl wie -1 bei einem numerischen Feld.
2. Ein Optional-Data-Bitfeld: ein Byte, in dem jedes Bit anzeigt, ob ein bestimmtes optionales Feld gültige Daten enthält.

Um Platz zu sparen, dürfen optionale Felder am Ende eines Records ganz weggelassen werden — aber nur, wenn sie (und alles danach) fehlende/ungültige Daten enthalten. Ein optionales Feld aus der Mitte eines Records darf niemals weggelassen werden.

7. Erforderliche Records & die Anfangssequenz

Unter STDF V4 muss eine gültige Datei vier erforderliche Records enthalten:

• FAR — genau einer, und er muss der erste Record in der Datei sein.
• MIR — genau einer, direkt nach dem FAR (und nach etwaigen ATRs).
• PCR — mindestens einer (ein Summen-PCR mit HEAD_NUM = 255, oder einer pro Head/Site, oder beides).
• MRR — genau einer, und er muss der letzte Record in der Datei sein.

Bei mehreren Records heißt es, ihr Platz sei „nach der Anfangssequenz“. Die Anfangssequenz ist der feste Block von Records ganz am Anfang der Datei. Ihre Reihenfolgeregeln:

• Der FAR steht immer an erster Stelle.
• Etwaige ATRs (Audit Trail) folgen unmittelbar auf den FAR.
• Der MIR folgt auf FAR und ATRs.
• Wird ein RDR (Retest) verwendet, folgt er unmittelbar auf den MIR.
• Werden SDRs (Site Description) verwendet, folgen sie unmittelbar auf den MIR (und den RDR, falls vorhanden).

# Die Anfangssequenz, vollständig:
FAR → [ATRs] → MIR → [RDR] → [SDRs] → … alle übrigen Records … → MRR

8. Alle STDF-V4-Record-Typen

Nachfolgend ist jeder von STDF V4 definierte Record-Typ aufgeführt, gruppiert danach, was er beschreibt. Zu jedem gibt es seine Funktion, wie oft er vorkommt, wo er in der Datei steht und — für die wichtigen Records — die vollständige Feldliste. Die Header-Felder (REC_LEN, REC_TYP, REC_SUB) sind in den Feldtabellen weggelassen, da sie für jeden Record identisch sind.

9. Wie Records in einer Datei angeordnet sind

Die genaue Record-Reihenfolge hängt davon ab, ob Wafer oder gehäuste Bauteile getestet werden, ob Parallel-Test aktiv ist und ob das Datalogging eingeschaltet ist. Hier die kanonischen Muster.

Ein Los gehäuster Bauteile (voller Datalog)

FAR                         Info auf Dateiebene
MIR                         globale Los-Info
  PIR                       ┐ erstes Bauteil beginnt
    PTR / MPR / FTR …         │ jeder Test an diesem Bauteil
  PRR                       ┘ Ergebnis des ersten Bauteils
  PIR … PTR/MPR/FTR … PRR      (für jedes Bauteil wiederholt)
  …
TSR × N                     eine Synopse pro Test im Programm
HBR × N                     einer pro Hardware-Bin
SBR × N                     einer pro Software-Bin
PCR                         Bauteil-Zählsummen
MRR                         globale Los-Ergebnisse (letzter Record)

Nur Zusammenfassung (kein Datalog pro Bauteil)

Wie oben, aber ohne den gesamten PIR…PRR-Block — nur FAR, MIR, dann die TSR/HBR/SBR/PCR-Zusammenfassungen und der MRR.

Ein Los bei der Wafer-Probe

FAR · MIR · WCR              Wafer-Abmessungen & -Ausrichtung
  WIR                       ┐ erster Wafer beginnt
    PIR · PTR/MPR/FTR · PRR    │ jeder Die auf dem Wafer
    …                         │
  WRR                       ┘ Zusammenfassung des ersten Wafers
  WIR … WRR                    (für jeden Wafer wiederholt)
TSR… HBR… SBR… PCR… MRR    Los-Zusammenfassungen + letzter Record

Eine reine Wafer-Map-Datei ist dieselbe, speichert aber nur PIR/PRR pro Die (kein PTR/MPR/FTR) und behält nur, was zum Zeichnen der Map nötig ist.

Parallel-Test

Bei mehreren Heads und Sites verschachteln sich die Records verschiedener Dies: Zunächst öffnen mehrere PIRs, der Tester gibt während der Testläufe PTR/MPR/FTR-Records mit Head+Site-Kennung aus, und der PRR jedes Dies erscheint, sobald dieser Die fertig ist (nicht unbedingt in Startreihenfolge). Der WRR jedes Wafers wird geschrieben, sobald alle Dies dieses Heads fertig sind, und der PCR-Block enthält einen PCR pro Head/Site plus einen Summen-PCR mit HEAD_NUM = 255.

10. Skalierung, Einheiten & Grenzen

In einem PTR/MPR werden RESULT, Grenzen und Specs alle auf die in UNITS genannte Basiseinheit normiert gespeichert. Das heißt, UNITS ist immer eine ganze Einheit — „AMPS“, niemals „uAMPS“ — und man kann direkt mit allen Werten rechnen, deren Einheiten übereinstimmen.

Für die Anzeige werden zwei zusätzliche Angaben genutzt: ein Skalierungsexponent und ein ANSI-C-Formatstring. Der _SCAL-Wert ist die Zehnerpotenz des Skalierungsfaktors und wählt zugleich das SI-Präfix aus:

Der skalierte Wert ist einfach Wert × 10^_SCAL. Um zum Beispiel „123,45 uAMPS“ zu speichern:

• RESULT = 123,45 × 10⁻⁶
• RES_SCAL = 6  (der Code für „mikro“)
• C_RESFMT = %7.2f
• UNITS = AMPS

Zur Anzeige: mit 10⁶ multiplizieren, mit zwei Nachkommastellen formatieren, das Präfix „u“ voranstellen und die Einheiten anhängen → 123.45 uAMPS.

11. Verwenden der Pin-Mapping-Records

Wenn ein Bauteil getestet wird, gibt es eine Zuordnung zwischen Bauteil-Pins und Tester-Kanälen. Drei Record-Typen beschreiben sie, und FTR/MPR-Records verweisen per Index auf sie:

• PMR (Pin Map Record) — definiert eine Kanal↔Pin-Zuordnung und vergibt ihr einen eindeutigen PMR-Index (1–32.767). Jeder Kanal hat einen Typ und einen Namen; jeder Pin hat einen physischen und einen logischen Namen; auch Head und Site werden festgehalten.
• PGR (Pin Group Record) — benennt eine Gruppe von Pins (z. B. „Adressbus“) und listet die darin enthaltenen PMR-Indizes auf, mit eigenem Gruppenindex (32.768–65.535).
• PLR (Pin List Record) — definiert für eine Liste von Pins/Gruppen die Anzeige-Basis (binär, oktal, dezimal, hexadezimal, symbolisch), den Betriebsmodus (normal, Dual-Drive, SCIO …) und die ASCII-Zeichen zur Darstellung programmierter und zurückgelieferter Zustände.

Wenn Software ein funktionales Ergebnis dekodiert, liest sie die PMR-Index-Arrays im FTR/MPR, um zu wissen, welche Pins welche Werte hatten, nutzt den PMR, um die physischen/logischen/ Kanalnamen des Pins und dessen Head/Site zu erhalten, nutzt den PGR, um die Gruppe des Pins zu erkennen, und nutzt den PLR, um die Zustände in einer für diesen Tester und dieses Bauteil vertrauten Form darzustellen.

12. Speichern von Repair-Informationen

STDF kann auch Repair-Daten für Speicher, Leiterplatten und andere Bauteile transportieren und diese zwischen Test- und Reparaturprozess übergeben. Die Repair-Information jedes Bauteils liegt im Feld PART_FIX des PRR. Sie ist anwendungsspezifisch — bit-kodiert, Integer, Float oder Text — wobei das erste Byte die Anzahl der folgenden Bytes angibt, sodass sie nur von einem passenden Analyseprogramm dekodiert werden kann. Eine minimale Repair-Datei kann die Records pro Test ganz weglassen und nur FAR · MIR · (WIR ·) PRR… · PCR · MRR behalten.

13. STDF-Dateinamen

Die Spezifikation empfiehlt einen Dateinamen der Form filename.STD[string], wobei:

• filename 1–39 Zeichen aus A–Z a–z 0–9 _ umfasst und mit einem Buchstaben beginnt.
• die Erweiterung mit .STD beginnt und auf Systemen mit Groß-/Kleinschreibung am besten klein geschrieben wird (.std).
• das Dollarzeichen $ nicht mehr erlaubt ist (es verursachte auf einigen Betriebssystemen Probleme).
• nur ein einziger Punkt verwendet wird und die Erweiterung kurz bleibt — Software kann ihr Zeichen anhängen, um den Verarbeitungsstand anzuzeigen.

Gute Dateinamen sind systemweit eindeutig, deuten auf ihren Inhalt und ihre Erzeugungszeit hin und funktionieren über verschiedene Betriebssysteme hinweg.

14. Unterschiede zwischen STDF V3 und V4

STDF wurde 1985 eingeführt und wuchs zu einem De-facto-Industriestandard heran. Nach dem Sammeln von fast hundert Anfragen von Kunden und anderen ATE-Herstellern veröffentlichte Teradyne Version 4, die heute verwendete Version. Die größten Änderungen:

• Vier erforderliche Records (V3 verlangte nur MIR und MRR): FAR, MIR, PCR, MRR — und die Datei muss nun mit dem FAR beginnen.
• Neue Records: ATR, PCR, PGR, PLR, RDR, SDR und MPR.
• Entfallene Records: die Beschreibungs-Records PDR und FDR (ihre halbstatischen Infos liegen nun im ersten PTR/FTR jedes Tests) und alle site-spezifischen Records SHB, SSB, STS, SCR (ihre Funktion übernehmen jetzt Head/Site-Felder in HBR, SBR, TSR und PCR).
• Bauteil-Zählwerte verschoben aus dem MRR in den neuen PCR; CPU_TYPE und STDF_VER liegen jetzt nur noch im FAR.
• Pin-Mapping neu gestaltet: der V3-PMR (der auch Gruppen definieren konnte) wurde in PMR + PGR + PLR aufgeteilt.
• Anzeigefelder modernisiert: alte Ziffernzahl-Felder wurden durch ANSI-C-Formatstrings (C_RESFMT usw.) ersetzt, und Spec-Grenzen (LO_SPEC/HI_SPEC) wurden dem PTR/MPR hinzugefügt.
• Neue Datentypen D*n und N*1 wurden hinzugefügt und die Bit-Reihenfolge von B*n wurde präzisiert.
• Unveränderte Records: BPS, EPS, GDR und DTR.

15. Glossar

↑ Nach oben