Semi E142

SEMI E142 defines substrate mapping — the standard for how equipment determines and reports which slots in a carrier actually hold a wafer, and which wafer is in which slot, as a prerequisite that has to be resolved before any transport, process, or data-collection step can proceed correctly. A FOUP or cassette can arrive at a tool partially loaded, with wafers in non-contiguous slots, or with a slot map that doesn't match what the host's database expects, and if the equipment doesn't know precisely which physical slots are occupied before it starts moving a robot arm or running a recipe, the result is a wafer-handling error at best and a collision or dropped wafer at worst — substrate mapping is the standardized check that happens before any of that, confirming the carrier's actual physical state matches what everyone downstream assumes.

A carrier arrives at the tool — host assumes a slot map from its database
Actual physical occupancy may not match: gaps, misloads, slide events
SEMI E142 — substrate mappingStandardized method for determining actual slot occupancy before handling
Defined mapping sensor behavior and slot-occupancy reporting
Confirms which slots are occupied, independent of what the host assumed
Standardized correlation between physical slot and wafer identity
Equipment and host agree on which wafer is where before any move
Robot handling and recipe execution proceed only on a confirmed, accurate map
No handling step committed against a stale or assumed slot map

The reason substrate mapping needed to be its own standardized step, rather than something each equipment vendor implements as an incidental part of wafer handling, is that the consequence of getting it wrong is severe and often physical — a robot arm commanded to pick from a slot it believes is occupied, when that slot is actually empty or holds a wafer the host doesn't expect, can collide with hardware or damage a wafer in a way no later process step can undo. E142 treats slot-occupancy verification as a formal precondition that has to pass before transport or process begins, rather than an assumption baked silently into whatever robot-control logic a vendor happens to write, closing a failure mode whose cost is measured in scrapped wafers and hardware damage rather than a missed data point.

What the Carrier Actually Holds vs. What the Host Assumed a wrong assumption here costs a wafer or a collision, not a missing data point Host's assumed slot map (from database) slot 1: wafer present slot 2: wafer present slot 3: wafer present slot 4: wafer present slot 5: wafer present (what the manifest says) E142 mapping sensor, actual scan slot 1: ✓ present slot 2: EMPTY — mismatch slot 3: ✓ present slot 4: CROSS-SLOTTED slot 5: ✓ present (laser/optical sensor sweep, physical truth) confirm Robot arm move HELD until the physical map is reconciled — no pick commanded against an assumed slot A pick against slot 2's assumed wafer would find nothing — or worse, a collision E142 makes this scan a precondition, not an implementation detail

E142 is what keeps a wafer-handling sequence from ever committing against an unverified assumption — by standardizing how equipment determines actual slot occupancy and correlates it to wafer identity before a robot arm or recipe step proceeds, it closes a failure mode whose cost is a damaged wafer or a hardware collision, not merely a data-collection gap, and it does so as a formal precondition rather than an implementation detail left to each vendor's own handling logic.

Take SEMI E142 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app