Semi E157

SEMI E157 specifies Module and Substrate Process Tracking — a GEM-based data model that lets a host track a substrate's progress at the module level inside a cluster tool, not just at the tool's overall input/output boundary the way E90's substrate tracking already does. A modern cluster tool processes a wafer through a sequence of chambers — load lock, several process modules, sometimes a cool-down step — and E157 exists because a host that only sees "wafer entered the tool" and "wafer exited the tool" is blind to everything that happened to that wafer between those two events.

E90 substrate tracking already covers tool-level entry and exit
Host knows when a wafer entered and left the tool as a whole
What E90 alone can't seeA cluster tool's internal module sequence is invisible from outside
Which module processed the wafer, in what order
Load lock → module A → module B → cooldown, for example
How long the wafer dwelt in each module
Per-module process time, not just total tool time
SEMI E157 — Module and Substrate Process TrackingExtends GEM-based tracking down to the module level
Per-module substrate state and transition events
Host-visible record of the wafer's internal path through the tool
A process excursion traced to the specific module and dwell time that caused it
Root-cause data E90's tool-level view alone could never provide

A few things are worth knowing about why module-level tracking needed its own standard rather than being folded into E90:

E90 and E157 are tracking two different objects, even though both are called "substrate tracking." E90 answers "where is this wafer right now, among all the tools in my fab" — the question a dispatch and scheduling system needs answered. E157 answers "where has this wafer been, module by module, inside this one tool" — the question a yield engineer needs answered when a specific cluster tool starts producing excursions and the fab needs to know whether the problem tracks to one chamber, one dwell time, or one sequence path rather than the tool as a whole. Both require a GEM-based event model, but they're built around different levels of granularity, which is exactly the kind of distinction SEMI drew the same way between E82's vehicle-level AMHS tracking and E153's equipment-level tracking one layer down.

SEMI E157 — Tracking What Happens Inside the Box E90 sees the tool boundary; E157 sees every module the wafer actually touched cluster tool boundary — this is all E90 can see from outside Load lock entry event t = 0s Module A dwell: 42s t = 2s–44s Module B dwell: 61s t = 46s–107s excursion traced here Cooldown exit event t = 109s E157 records every arrow and every dwell time in this diagram E90 only ever sees the first and last box Without E157: "wafer excursion in cluster tool #4" — which module, unknown With E157: "wafer excursion — module B, 61s dwell, deviates from 42s baseline"

Per-module tracking is what turns a tool-level yield excursion into an actionable root cause. When a fab sees output drift from one specific cluster tool, the first diagnostic question is almost always "which chamber" — a process module running hot, a dwell time creeping up from a worn seal, a sequencing error that occasionally routes a wafer through modules in the wrong order. E90's tool-boundary data can tell a fab which tool to investigate; it can't tell an engineer where inside that tool to start looking. E157 is the data layer that closes that gap, turning a host's substrate-tracking system from a dispatch tool into something that also supports chamber-level process engineering.

E157 depends on the same GEM state/event conventions as E90 for exactly the same interoperability reason E153 depends on them for AMHS equipment. A host integration already built to consume E90's substrate-tracking events doesn't need a separate protocol stack to also consume E157's per-module events — both speak the same collection-event vocabulary, which is what lets a single host application layer handle tool-level dispatch and module-level diagnostics without maintaining two incompatible data models side by side.

Read E157 as the standard that finally lets a host see inside the cluster-tool black box E90 could only bound from the outside: by recording which module a substrate visited, in what order, and for how long, it turns "something went wrong in that tool" into "something went wrong in that module, after that dwell time" — the difference between knowing a problem exists and knowing where to fix it.

Take SEMI E157 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