Semi E178

SEMI E178 specifies EDA freeze versions, a standardized way to pin and version the equipment self-description E125's EqSD publishes, so that a data-collection plan validated against one version of that self-description keeps working even after equipment firmware changes what EqSD reports. E125 answers "what can this tool report right now" — a live, current snapshot that can change the moment a vendor pushes a firmware update adding, removing, or redefining parameters. E178 answers a question that live snapshot was never built to answer: how does a host that built a validated collection plan against last quarter's EqSD description know whether this quarter's firmware update silently broke it, and how does the host pin a specific, frozen version of that description so its collection plan has something stable to validate against in the first place.

SEMI E125 (EqSD) publishes the tool's current, live self-description
What this tool can report right now, as of this moment
What a live self-description alone doesn't provideA live snapshot has no concept of past or pinned versions
A firmware update can silently change what EqSD reports
A collection plan built against last quarter's description may now be invalid
No standardized way to pin a validated version for later comparison
Hosts have no formal way to detect drift between what was validated and what's live now
SEMI E178 — EDA freeze versionsA versioning model that pins a specific EqSD description as a frozen reference
A collection plan references a frozen EqSD version, not the live one
Equipment changes are detected by comparing against the pinned version
A validated collection plan stays valid, or a firmware change is caught explicitly
Instead of silently drifting out of sync with the tool's live capability set

A few things are worth knowing about why EqSD's live self-description needed a freeze-and-version layer in addition to the publishing mechanism itself:

EqSD was built to answer "what can this tool report," and a live answer to that question is exactly right at the moment it's asked — but a data-collection plan isn't built and used in a single moment, it's validated once and then relied on for months, which means the live answer EqSD gives today is implicitly assumed to still be the right answer every time that plan runs. A vendor's firmware update that adds a new sensor, renames a parameter, or changes a reported unit is a routine, expected part of equipment lifecycle — but without any version pinning, that update changes what EqSD reports with no mechanism for a host to notice that the collection plan it validated six months ago was built against a description that no longer matches reality. The plan doesn't fail loudly; it silently collects against assumptions the equipment has already moved past.

A Live Description Has No Memory of Last Quarter SEMI E178 pins the version a collection plan was actually validated against Collection plan validated in Q1 against EqSD v1: 40 parameters, pressure in mTorr Plan assumes this description stays true for as long as it keeps running With E178 freeze versions Plan references pinned EqSD v1 explicitly; Q2 firmware update ships EqSD v2 Host detects v1≠v2, flags plan for review Without freeze versions Plan only ever sees "the live EqSD"; Q2 firmware update ships EqSD v2 Plan silently collects against mismatched assumptions Same firmware update, same EqSD change — one path catches it, one doesn't

EDA freeze versions matter because the alternative to explicit version pinning isn't "no versioning problem," it's "an undetected versioning problem," and the second one is strictly worse for exactly the fabs running the most EDA-dependent analytics. A fab that has invested in building sophisticated collection plans and downstream analytics around a specific tool's parameter set has the most to lose when that tool's underlying description shifts quietly beneath those plans. E178 doesn't prevent equipment vendors from updating firmware or evolving their EqSD descriptions — that evolution is normal and expected — it gives hosts a formal way to know exactly which version a plan was built against and to catch drift the moment it appears, rather than discovering it months later when an analyst notices a parameter's units have changed.

E178 sits directly downstream of E125's EqSD as the version-control layer this glossary has already covered from the self-description side — EqSD defines what a tool publishes about itself, and E178 is what makes that publication something a host can reference reliably over time instead of only ever trusting the most recent snapshot. Neither standard works without the other: freeze versions have nothing to pin without EqSD's underlying self-description model, and EqSD's live snapshot has no way to protect a long-lived collection plan without freeze versions sitting on top of it.

Read E178 as the standard that closes the gap EqSD's live self-description was never built to close: a tool's capability description is only trustworthy at the instant it's published, but a collection plan built from that description has to stay trustworthy for months, and freeze versions are what actually let a host pin a specific version and catch the moment equipment moves past it.

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