Semi E139.2

SEMI E139.2 defines the SECS-II message set for RaP — the specific remote commands for downloading, selecting, and verifying a recipe, and the collection-event IDs (CEIDs) that report success, mismatch, or failure back to the host — carrying the XML process-definition content E139.1 structures, over the classic SECS-II wire protocol most GEM-compliant equipment already speaks, rather than the web-services path a SOAP binding would take. E139 defines RaP's lifecycle and E139.1 defines what a recipe document actually contains, but neither says what specific SECS-II stream/function numbers, remote-command names, or report-back events carry that document between host and equipment — and the overwhelming majority of installed fab equipment communicates over SECS-II first, with SOAP/web-services bindings layered in only where the newer EDA/Interface A ecosystem applies.

E139 defines RaP's lifecycle; E139.1 defines the recipe's XML content
Neither fixes which SECS-II messages actually carry that content
SEMI E139.2 — SECS-II protocol for RaPFixes the remote commands and CEIDs over the classic wire protocol
Defined remote commands for recipe download, select, verify
Same stream/function numbering across every compliant tool
Defined CEIDs reporting success, mismatch, or verification failure
Host knows definitively which recipe version is actually active
Host manages recipes over SECS-II the same way across any compliant tool
Works on the communication layer the vast majority of fab equipment already uses

The reason RaP needed a SECS-II-specific binding alongside its XML content schema is that most fab equipment was never built around web-services infrastructure in the first place — SECS-II over the classic GEM communication stack remains the baseline nearly every tool supports, so a recipe-management standard that only defined its content format and left the transport unspecified would still require each vendor to improvise exactly how that content gets requested and confirmed over the wire they already use. E139.2 closes that gap by fixing the actual remote-command and CEID numbering for RaP's download/select/verify operations on SECS-II specifically, giving fabs a standardized recipe-management path that works on the communication layer the installed base already runs, without requiring a parallel web-services upgrade just to get consistent recipe handling.

A Full E139.2 Recipe Download Over SECS-II a content schema still needs a defined carrier on the wire protocol most tools already speak Host Equipment S7F3 PPID="etch-v2.3", PPBODY=[XML] S7F4 ACKC7=0 (accepted) S7F5 PPSelect("etch-v2.3") S6F11 CEID=RECIPE_VERIFIED, checksum OK S6F11 CEID=RECIPE_MISMATCH — lot held Same remote-command numbers and CEIDs on every compliant tool No parallel web-services upgrade needed just to get this

E139.2 is what makes RaP usable on the communication layer the vast majority of fab equipment already runs — by fixing the SECS-II remote commands and CEIDs for recipe download, selection, and verification, it gives E139's lifecycle and E139.1's content schema an actual wire-level carrier that doesn't require a fab to adopt web-services infrastructure just to get standardized recipe management.

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