KLARF (KLA Results File) is the de facto standard format for transferring wafer inspection results between inspection tools and downstream review and analysis systems. It predates many of the engineers currently working in semiconductor quality roles, and its age shows: the format has accumulated implementation variations across vendors and tool generations that create real data compatibility problems for teams trying to build automated review workflows.
Understanding the KLARF specification — and more importantly, understanding where real implementations diverge from the specification — is essential for any process engineer responsible for integrating inspection results into yield management, SEM review, or MES systems.
KLARF Format Fundamentals
A KLARF file is a structured ASCII text file organized into a header section and a defect list section. The header contains wafer identification (lot ID, wafer ID, slot number), inspection tool identification, recipe information, and coordinate system parameters. The defect list contains per-defect records with at minimum X/Y coordinates, defect size (X dimension, Y dimension, area), and typically a rough classification code.
The coordinate system specification in the header is critical and often misread. KLARF uses a wafer coordinate system where the origin can be at wafer center, wafer flat/notch, or another reference depending on the tool and recipe configuration. The WaferOrientation and SampleOrientationMarkType fields define the reference frame. Downstream systems that assume a center-origin convention when the KLARF was generated with a notch-origin convention will misplace all defect coordinates by the notch-to-center offset — typically 150 mm on a 300mm wafer. The resulting wafer map looks geometrically distorted and causes SEM review tools to drive to the wrong location.
Defect coordinates in KLARF are in microns by default, but the SampleCenterLocation and InspectedArea records encode the scale factors. Some older tool implementations write coordinates in millimeters without updating the standard scale fields, causing 1000× coordinate errors in downstream systems that assume the standard unit. This is a documented known issue with certain generation inspection tools and is worth explicitly validating during integration testing.
The DefectRecordSpec and Why It Matters
The DefectRecordSpec field in the KLARF header defines the columns present in the defect list — their order, names, and data types. This is KLARF's mechanism for extensibility: tools can add vendor-specific columns beyond the standard set (XREL, YREL, XINDEX, YINDEX, XSIZE, YSIZE, DEFECTAREA, DSIZE, CLASSNUMBER, TEST, CLUSTERNUMBER, ROUGHBINNUMBER, FINEBINNUMBER, REVIEW, IMAGECOUNT).
The problem: downstream parsers that do not read DefectRecordSpec dynamically, and instead assume a fixed column order, will misparse any KLARF with a non-standard column arrangement. This is a common implementation error in home-grown KLARF parsers written by yield engineers who tested against a single tool's output format. When a second inspection tool with a different column order is added, the parser silently assigns values to wrong fields — coordinates become sizes, classification codes become area values, and the defect data is corrupted without any error message.
The correct implementation: always parse DefectRecordSpec first, build a field-to-column index map, then parse each defect record using that map. This is two extra lines of code that prevent a class of silent data corruption errors that are difficult to diagnose once they propagate into a yield database.
Image References and Thumbnail Handling
Modern inspection tools append image references to KLARF files: per-defect pointers to captured image tiles that the inspection tool stored at the time of detection. These image references appear in the IMAGECOUNT column (number of images for this defect) and optionally in an extended ImageList section containing file paths to the actual image files.
The image file paths in KLARF are almost always absolute paths in the inspection tool's local file system — for example, C:\InspectionData\LotXYZ\Wafer01\defect_0042_chan1.tif. These paths are meaningless when the KLARF file is transferred to a separate review system. The downstream system needs to either re-map the file paths using a network share or a KLARF post-processing step, or the KLARF generator needs to be configured to write relative paths or network UNC paths.
This is a common integration gap that causes SEM review systems to fail to load defect images despite the images being correctly generated by the inspection tool — they are accessible on the inspection tool's local storage but not via the path encoded in the KLARF. The solution requires coordination between the inspection tool's KLARF configuration and the network share mapping of the review system.
ClassNumber Mapping and Its Absence
The CLASSNUMBER field in KLARF is an integer that maps to a defect class in a vendor-defined lookup table. The lookup table is not included in the KLARF file itself — it is maintained in the inspection tool's recipe configuration. A KLARF file with CLASSNUMBER = 5 means "class 5 as defined in recipe XYZ on tool ABC." Without access to that recipe's classification table, the number is opaque.
Yield management systems that ingest KLARF files need a mechanism to resolve class numbers to class names. The cleanest architecture: the inspection tool exports a companion classification table file alongside each KLARF, or the yield management system queries the inspection tool's recipe management database directly. Ad hoc approaches — manually maintaining a class number–to–name mapping table in the yield system for each tool/recipe combination — are error-prone and frequently become stale when recipes are updated.
We are not saying that ClassNumber is a broken design — it works correctly when the classification lookup is managed systematically. The point is that teams setting up KLARF-based review workflows should explicitly design the classification table management before the integration is complete, not discover the gap when the first production KLARF arrives with class numbers that the review system cannot resolve.
KLARF in the Review Workflow
In an automated review workflow, KLARF files are the input to the review station dispatch system. The workflow: inspection tool generates KLARF, yield management system ingests KLARF and applies disposition rules (e.g., wafers with defect count above threshold → automatic hold; wafers with specific defect class → priority SEM review), review station receives a review recipe generated from the KLARF defect coordinates, SEM drives to each defect location and acquires high-resolution images for classification confirmation.
The quality of the review workflow depends critically on KLARF coordinate accuracy. A coordinate error of 5 µm — within the noise level for a poorly calibrated coordinate transfer — means the SEM review drives close to the defect but not to it, acquires a background image, and the review record shows "no defect found at location." The classification confirmation loop is broken, the review data is useless for training, and engineers lose confidence in the automated review workflow without a clear understanding of why.
End-to-end coordinate accuracy validation — inspect a wafer with known reference marks or deliberately placed test structures, generate KLARF, run through the review workflow, confirm SEM acquisition is centered on the reference marks — should be performed at integration commissioning and repeated after any inspection tool calibration event or KLARF parser update.
Common Extensions and Variants
Several inspection tool vendors have introduced KLARF extensions for higher-density data. KLA's version 1.2 and later add support for additional image metadata and extended attribute fields. Some tools output KLARF in binary encoding for large defect lists (hundreds of thousands of defects per wafer in high-sensitivity applications). XML-based variants — sometimes called xKLARF or KLARF-XML — provide better structure for extended attribute data but require different parsers.
When building a yield data infrastructure that will ingest KLARF from multiple tools, explicitly identifying the KLARF version and variant for each tool in the tool inventory prevents parser compatibility failures. A parser designed for KLARF 1.8 binary from one tool generation will not correctly handle KLARF 1.2 ASCII from a previous generation tool at the same inspection step. The version field in the KLARF header is the authoritative reference.