What is STDF? The complete, plain-English guide

1. What STDF is

STDF (Standard Test Data Format) is a simple, flexible, portable, binary data format for storing the results produced by semiconductor test equipment. It was created by Teradyne and first introduced in 1985. Because it is well documented and vendor-neutral, it became the de-facto standard across the entire Automatic Test Equipment (ATE) industry.

When a tester measures a die on a wafer or a packaged device, it records the parametric measurements, the pass/fail results, the bin assignments and the test conditions into an STDF file — commonly called a datalog. One STDF file holds the test data for one lot of parts from a single insertion (one pass of a lot through testing).

The key idea: STDF is not a database and not a fixed report. It is a defined set of logical record types. Each record describes one piece of the test run (a part, a wafer, a single measurement, a bin count, and so on). Because the data is described as logical records, the same format works whether the data sits in a memory buffer, in a file on disk, or is being sent across a network — independent of any particular database or network architecture.

2. Why STDF exists

As the ATE industry matured, vendors built networking and analysis systems around common standards such as Ethernet. But one glaring gap remained: test-result data was not compatible between testers from different manufacturers — and sometimes not even between product lines of the same manufacturer.

Without a shared format, every fab and every OSAT (assembly & test house) would need a custom parser for every machine. STDF closes that gap. It provides a single common container so that:

• a tester can write its raw results in its own native representation, quickly;
• a centralized database engine can accept data from a wide range of testers with one program;
• data can be exported back to in-house networks in a well-documented, thoroughly debugged form;
• portable reporting and analysis software can be written once and used everywhere.

Teradyne derives no direct commercial benefit from the standard — it published STDF precisely so the whole industry could be more productive with a common, fully documented format.

3. Design objectives

The design of STDF was guided by a small set of clear objectives:

• Be capable of storing test data for all semiconductor testers and trimmers.
• Provide a common format for both storage and transmission of data.
• Provide a basis for portable reporting and analysis software.
• Decouple the data-message format from the database format, so either can evolve independently.
• Provide support for optional (missing or invalid) data.
• Provide complete, concise documentation for developers and users.
• Make it easy for customers to write their own reports or reformat data for their own database.

4. How an STDF file is structured

An STDF file is simply a sequence of records, one after another. Every record — no matter its type — begins with the same 4-byte record header:

The pair (REC_TYP, REC_SUB) uniquely identifies each record type. Grouping by REC_TYP lets analysis programs quickly recognize families of records (for example, “everything collected per part”). All type/sub-type codes below 200 are reserved by Teradyne; codes above 200 are free for custom applications.

Record groups (REC_TYP)

Byte order and the CPU_TYPE trick

Different processors (DEC, Motorola, Intel, IBM, Sun…) store integers and floating-point numbers with different bit orderings. Rather than force every tester to convert data as it writes (which would slow testing down), STDF lets each system write in its own native representation and records which CPU wrote the file in the CPU_TYPE field of the very first record (the FAR). When another system reads the file, it checks CPU_TYPE and converts each record to its own representation only if needed. Data conversion becomes transparent at read time and testing is never slowed down.

Dates and times

Every date/time field is a 4-byte unsigned integer counting the number of seconds since midnight, January 1st, 1970 (the UNIX epoch), in the local time zone.

5. Data type codes

STDF uses short, recognizable codes for its field types. For example R*4 means a 4-byte real (float). The number after the * is the size in bytes; a byte is 8 bits.

6. Optional, missing & invalid data

Many fields are marked optional. An optional field must still be present in the record, but there are two standard ways to say “this value is not meaningful”:

1. A predefined reserved value means “missing” — e.g. a length byte of 0 for a string, or a specific number like -1 for a numeric field.
2. An Optional Data bit field: a byte where each bit flags whether a particular optional field holds valid data.

To save space, optional fields at the end of a record may be omitted entirely — but only if they (and everything after them) contain missing/invalid data. You may never omit an optional field from the middle of a record.

7. Required records & the initial sequence

Under STDF V4, a valid file must contain four required records:

• FAR — exactly one, and it must be the first record in the file.
• MIR — exactly one, right after the FAR (and after any ATRs).
• PCR — at least one (a summary PCR with HEAD_NUM = 255, or one per head/site, or both).
• MRR — exactly one, and it must be the last record in the file.

Several records say their location is “after the initial sequence.” The initial sequence is the fixed block of records at the very start of the file. Its ordering rules:

• The FAR is always first.
• Any ATRs (audit trail) come immediately after the FAR.
• The MIR comes after the FAR and ATRs.
• If an RDR (retest) is used, it comes immediately after the MIR.
• If SDRs (site description) are used, they come immediately after the MIR (and RDR, if present).

# The initial sequence, in full:
FAR → [ATRs] → MIR → [RDR] → [SDRs] → …all other records… → MRR

8. Every STDF V4 record type

Below is every record type defined by STDF V4, grouped by what it describes. For each one you get its function, how often it appears, where it lives in the file, and — for the important records — the full field list. Header fields (REC_LEN, REC_TYP, REC_SUB) are omitted from the field tables since they are identical for every record.

9. How records are ordered in a file

The exact record order depends on whether you are testing wafers or packaged parts, whether parallel testing is on, and whether datalogging is enabled. Here are the canonical patterns.

A lot of packaged devices (full datalog)

FAR                         file-level info
MIR                         global lot info
  PIR                       ┐ first part begins
    PTR / MPR / FTR …         │ every test on that part
  PRR                       ┘ first part results
  PIR … PTR/MPR/FTR … PRR      (repeat for each part)
  …
TSR × N                     one synopsis per test in the program
HBR × N                     one per hardware bin
SBR × N                     one per software bin
PCR                         part-count totals
MRR                         global lot results (last record)

Summary only (no per-part datalog)

Same as above but with the whole PIR…PRR block removed — just FAR, MIR, then the TSR/HBR/SBR/PCR summaries and the MRR.

A lot at wafer probe

FAR · MIR · WCR              wafer dimensions & orientation
  WIR                       ┐ first wafer begins
    PIR · PTR/MPR/FTR · PRR    │ each die on the wafer
    …                         │
  WRR                       ┘ first wafer summary
  WIR … WRR                    (repeat for each wafer)
TSR… HBR… SBR… PCR… MRR    lot summaries + final record

A wafer-map-only file is the same but stores just PIR/PRR per die (no PTR/MPR/FTR), keeping only what's needed to paint the map.

Parallel testing

With multiple heads and sites, records for different dies interleave: several PIRs open first, the tester emits PTR/MPR/FTR records tagged by head+site as tests run, and each die's PRR appears as soon as that die finishes (not necessarily in start order). Each wafer's WRR is written once all of that head's dies are done, and the PCR block includes one PCR per head/site plus a summary PCR with HEAD_NUM = 255.

10. Scaling, units & limits

Inside a PTR/MPR the RESULT, limits, and specs are all stored normalized to the base unit named in UNITS. That means UNITS is always a whole unit — “AMPS”, never “uAMPS” — and you can do arithmetic directly on any values whose units agree.

For display, two extra pieces are used: a scaling exponent and an ANSI-C format string. The _SCAL value is the power of ten of the scaling factor and also selects the SI prefix:

The scaled value is simply value × 10^_SCAL. For example, to store “123.45 uAMPS”:

• RESULT = 123.45 × 10⁻⁶
• RES_SCAL = 6  (the code for “micro”)
• C_RESFMT = %7.2f
• UNITS = AMPS

To display it: multiply by 10⁶, format with two decimals, prepend the “u” prefix, and append the units → 123.45 uAMPS.

11. Using the pin-mapping records

When a device is tested there is a mapping between device pins and tester channels. Three record types describe it, and FTR/MPR records reference them by index:

• PMR (Pin Map Record) — defines one channel↔pin association and gives it a unique PMR index (1–32,767). Each channel has a type and name; each pin has a physical and a logical name; the head and site are recorded too.
• PGR (Pin Group Record) — names a group of pins (e.g. “address bus”) and lists the PMR indexes in it, with its own group index (32,768–65,535).
• PLR (Pin List Record) — for a list of pins/groups, defines the display radix (binary, octal, decimal, hex, symbolic), the operating mode (normal, dual-drive, SCIO…), and the ASCII characters used to render programmed and returned states.

When software decodes a functional result, it reads the PMR index arrays in the FTR/MPR to know which pins had which values, uses the PMR to get the pin's physical/logical/channel names and its head/site, uses the PGR to see what group the pin belongs to, and uses the PLR to render the states in a form engineers recognize for that tester and device.

12. Storing repair information

STDF can also carry repair data for memory, PC boards, and other parts, passing it between the test and repair processes. The repair information for each part lives in the PART_FIX field of the PRR. It is application-specific — bit-encoded, integer, float, or text — with the first byte giving the number of bytes that follow, so it can only be decoded by a matching analysis program. A minimal repair file can drop the per-test records entirely and keep just FAR · MIR · (WIR ·) PRR… · PCR · MRR.

13. STDF filenames

The spec recommends a filename of the form filename.STD[string] where:

• filename is 1–39 characters from A–Z a–z 0–9 _, starting with a letter.
• the extension begins with .STD and, on case-sensitive systems, is best written lowercase (.std).
• the dollar sign $ is no longer allowed (it caused problems on some operating systems).
• use only a single period, and keep the extension short — software may append characters to it to indicate processing state.

Good filenames are unique across a system, hint at their content and generation time, and work across a variety of operating systems.

14. Differences between STDF V3 and V4

STDF was introduced in 1985 and grew into a de-facto industry standard. After collecting nearly a hundred requests from customers and other ATE vendors, Teradyne released Version 4, the version in use today. The biggest changes:

• Four required records (V3 required only MIR and MRR): FAR, MIR, PCR, MRR — and the file must now begin with the FAR.
• New records: ATR, PCR, PGR, PLR, RDR, SDR, and MPR.
• Dropped records: the description records PDR and FDR (their semi-static info now lives in the first PTR/FTR of each test), and all the site-specific records SHB, SSB, STS, SCR (their function is now handled by head/site fields in HBR, SBR, TSR, and PCR).
• Part counts moved out of the MRR into the new PCR; CPU_TYPE and STDF_VER now live only in the FAR.
• Pin mapping was redesigned: the V3 PMR (which could also define groups) was split into PMR + PGR + PLR.
• Display fields modernized: old digit-count fields were replaced with ANSI-C format strings (C_RESFMT etc.), and spec limits (LO_SPEC/HI_SPEC) were added to the PTR/MPR.
• New data types D*n and N*1 were added and the B*n bit ordering was clarified.
• Unchanged records: BPS, EPS, GDR, and DTR.

15. Glossary

↑ Back to top