Semi E139

SEMI E139 defines Recipe and Parameter Management (RaP) — the standard for how a host manages the full lifecycle of a process recipe on a piece of equipment, including creating, downloading, verifying, selecting, and version-controlling the parameter sets a tool runs each lot against, rather than the messaging format recipes happen to travel in. Nearly every piece of fab equipment runs lots against named recipes — a specific combination of gas flows, RF power, temperature, and timing parameters tuned for a given process step — and before RaP, recipe handling was one of the least standardized parts of the GEM/SECS-II ecosystem: hosts and equipment agreed on data collection (E134), self-description (E125), and alarm handling (E30), but recipe management was often left to vendor-specific extensions layered on top, creating exactly the kind of per-vendor integration burden every other SECS/GEM standard exists to eliminate.

Every tool runs lots against named process recipes
Recipe management was historically one of the least standardized GEM/SECS-II areas
SEMI E139 — Recipe and Parameter Management (RaP)Standardized lifecycle: create, download, verify, select, version
Defined recipe download/upload and selection commands
A host can push and activate a recipe the same way across vendors
Standardized recipe verification and version control
Equipment confirms it's running the recipe version the host intended
Host manages recipes consistently across a mixed-vendor equipment fleet
No vendor-specific recipe-management extension required

The reason recipe management needed its own dedicated standard, distinct from E134's data-collection focus or E30's general equipment-communication model, is that a recipe isn't just data flowing from equipment to host — it's a parameter set the host pushes to equipment that then has to be verified, version-tracked, and selected correctly before a lot runs against it, and getting any part of that lifecycle wrong (running lot 50 against a stale or mismatched recipe version) produces scrapped product rather than just a missing data point. E139 treats recipe integrity as a first-class concern with its own defined commands and verification steps, closing a gap that previously left fabs dependent on each equipment vendor's own, mutually incompatible recipe-management extension.

A Recipe's Lifecycle Under E139, Step by Step a wrong recipe version doesn't produce a missing data point — it produces scrap Download recipe v2.3 → tool Verify checksum matches? Select PPSelect("v2.3") Run lot against v2.3 Without E139 Vendor A's PPSelect vs Vendor B's RecipeActivate — different commands Host selects the wrong version — tool runs it without complaint lot 50 scrapped, cause found hours later With E139 (RaP) Same verify-before-select step, every vendor's tool Checksum mismatch rejected before the lot ever starts wrong-version run becomes structurally impossible E134 standardized data collection; E30 standardized basic commands E139 is what finally standardized the recipe lifecycle itself

E139 is what finally gave recipe management the same standardized treatment every other core GEM/SECS-II function already had — by defining download, selection, verification, and version-control commands as a shared RaP lifecycle rather than leaving them to each vendor's own extension, it closes a gap whose failure mode wasn't just integration overhead but the real risk of running production lots against the wrong parameter set.

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