Background Statement for SEMI Draft Document 5618A NEW STANDARD: SPECIFICATION FOR PRESERVATION OF RECIPE INTEGRITY (PRI) Notice: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this Document. Notice: Recipients of this Document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, “patented technology” is defined as technology for which a patent has issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided. Purpose SEMI Draft Document 5618A proposes two capabilities to improve equipment recipe management and execution in the industry: recipe parameterization and recipe header. What is the problem being solved? It is difficult to manage recipes resident on production equipment. The current equipment communication Specifications lack the ability to uniquely identify components of an equipment recipe or their purpose. Once downloaded to a production equipment, it is difficult to ascertain whether the recipe components on the equipment are the same ones that were downloaded or a modified version. A recipe component typically includes no user-accessible information beyond the recipe identifier, which is not required to be unique. The number or recipes that must be managed is significantly increased by the absence of some needed recipe variable parameters (RVPs). RVPs allow small adjustments at run time without changing the base recipe. A current solution to the lack of RVPs is to modify recipes on the fly and download new content under the same recipe identifier. However, this only increases the uncertainty of the recipe content on production equipment. These problems contribute to an environment where it is easy to cause misprocessing due to the use of the wrong recipe content (even when the correct RecipeID is used). Note that no changes to SECS-II messaging are proposed. The GEM 300 TF considered adding recipe header-aware messaging, but decided that existing messaging was sufficient for now. Future work may leverage recipe header data to improve efficiency.
Transcript
Background Statement for SEMI Draft Document 5618ANEW STANDARD: SPECIFICATION FOR PRESERVATION OF RECIPE INTEGRITY (PRI)Notice: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this Document.
Notice: Recipients of this Document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, “patented technology” is defined as technology for which a patent has issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided.
Purpose
SEMI Draft Document 5618A proposes two capabilities to improve equipment recipe management and execution in the industry: recipe parameterization and recipe header.
What is the problem being solved?
It is difficult to manage recipes resident on production equipment. The current equipment communication Specifications lack the ability to uniquely identify components of an equipment recipe or their purpose. Once downloaded to a production equipment, it is difficult to ascertain whether the recipe components on the equipment are the same ones that were downloaded or a modified version. A recipe component typically includes no user-accessible information beyond the recipe identifier, which is not required to be unique.
The number or recipes that must be managed is significantly increased by the absence of some needed recipe variable parameters (RVPs). RVPs allow small adjustments at run time without changing the base recipe. A current solution to the lack of RVPs is to modify recipes on the fly and download new content under the same recipe identifier. However, this only increases the uncertainty of the recipe content on production equipment.
These problems contribute to an environment where it is easy to cause misprocessing due to the use of the wrong recipe content (even when the correct RecipeID is used).
Note that no changes to SECS-II messaging are proposed. The GEM 300 TF considered adding recipe header-aware messaging, but decided that existing messaging was sufficient for now. Future work may leverage recipe header data to improve efficiency.
Also note that SEMI E170 Specification for Production Recipe Cache (PRC) has been published as a new SEMI Standard. SEMI Document #5618A (this proposed Specification) is compatible and complementary with SEMI E170.
What is the history of this issue and ballot?
This is the second time this new Specification has been proposed. The first was in Cycle 6 of 2014.
Who will this effect? How? Why?
As a separate standard, this Specification will affect only those who choose to require/implement it. It has the potential to affect all factories. This has been taken into account by ensuring that equipment can still accept existing recipes. The design also allows the new-format recipes to be use by existing host systems with little or no change until the host can be redesigned to take advantage of the new features. The benefits can be added gradually.
Is this a change to an existing solution, or, is it a new activity?
This is a new activity, but it does affect the current way recipe management is performed between host and production equipment. The proposal does not add or modify any SECS-II messages. Some new data may be communicated using existing mechanisms.
Note to SEMI Editorial StaffThe naming of the XML schema file proposed for the recipe header includes the standard release date. Since that can’t be known before the standard is approved and a publication date determined, the SEMI editorial staff is instructed to make the following changes:
Change the name of the Complementary File ‘Exxx-mmyy-PRI-Schema.xsd’ to replace ‘Exxx’ with the standard number and ‘mmyy’ with the publication date.
o For example, if the new specification is E999-0914, then the schema file name would become ‘E999-0914-PRI-Schema.xsd’
Change all occurrences of ‘Exxx-mmyy-PRI-Schema.xsd’ in this document to replace ‘Exxx’ with the standard number and ‘mmyy’ with the publication date:
o 9.4.4 RQ-00026o 9.4.4.3.3 RQ-00028o 9.4.4.3.3 RQ-00030o 9.4.4.6 Figure 3 (2nd line – editable in Word)
There are also some instances of reference to this specification by its standard number. This is given as Exxx and needs to be replaced by the actual standard number before final publication. This occurs in the following places in the document: (excluding the ones listed above)
o Figure 17.2.3 in Figure 1 Titleo 7.4.5.1 (2 places)o 7.4.6 (5 places)o Table 4 (2 places)o 9.4.2.4 o 9.4.3 (6 places)o 9.4.4 (15 places) – plus one inside Figure 2 (won’t show up on search)
Please work with author to revise Figure 2 The 2 instances inside Figure 3 are editable in Word
o 9.4.5 (9 places)o 9.4.6 (6 places)
Revision Control
This revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force.
Date Version Name Edits
3 Dec 2014 0.1 Lance Rist Added issues list. Proposed changes to resolve eight of the non-controversial issues. Nine issues are as yet unresolved.
28 Dec 2014 0.2 Lance Rist
Addressed all open issues pending review of TF, including VersionID, new Figure 1 relationship diagram, demotion of RQ-00004 to a recommendation, new terminology for recipe types, specification of string formats, creation of a RecipeID type definition in the XML, adjustment of date time format, update of Figure 1 to reflect changes to the schema, requirement numbering, and rewording of several requirements: RQ-00011, 15, 18, 25-31, 33-37.
22 Jan 2015 1.0 Lance Rist Made minor editorial changes in 7.4.4. All GEM 300 TF issues have been resolved.
A Note on Requirements ID’sRequirements ID’s are included in the proposed new standard. See the Conventions section in the document body for a full description. All requirements are delimited. No other text should be considered a requirement. Sections near a requirement may provide examples or other supporting text that can help with interpreting the requirement. Note that the word “should” is used in some non-requirements text and it denotes a recommendation or a best practice, not a requirement.
Each requirement has a requirement ID as contained in the [Esss.ss-RQ-nnnnn-nn] delimiter. The Esss.ss is the specification identifier and will be replaced by SEMI in the published version with the actual standard number (for example E175.00), which cannot be known before approval is achieved. The “nnnnn” string is the requirement number within this specification. The authors of this proposal have suggested requirement numbers, but the final assignment will be made by SEMI. Corrections to the requirement numbers are considered editorial.
The ballot results will be reviewed and adjudicated at the meetings indicated in the table below. Check www.semi.org/standards under Calendar of Events for the latest update.
Review and Adjudication InformationTask Force Review Committee Adjudication
Group: NA GEM300 TF NA Information & Control CommitteeDate: NA Standards Spring 2015 Meetings
Tuesday March 31, 2015NA Standards Spring 2015 MeetingsWednesday April 1, 2015
Time & Timezone: 10:00 – 17:00 Pacific Time 8:00 – 16:30 Pacific TimeLocation: SEMI Headquarters
3081 Zanker RoadSEMI Headquarters3081 Zanker Road
City, State/Country: San Jose, California 95134 San Jose, California 95134Leader(s): Brian Rubow (Cimetrix)
1 Purpose1.1 The purpose of this Specification is to help ensure that equipment recipes and related settings are executed on production equipment as intended by factory systems and personnel.
1.2 Challenges associated with the management of equipment recipes and their recipe components addressed by this specification include the following:
Lack of a process to ensure that each recipe component can be uniquely identified, resulting in excessive recipe transfer for the purpose of reconfirming the content of recipes on the equipment
Lack of transparency and description of recipe component content
Unavailability of key recipe variable parameters (RVPs) to support adjustment at run-time
2 Scope2.1 This Specification addresses problems and solutions in the area of recipe management on production equipment.
2.2 The solutions presented in the Specification are intended for 300 mm and 450 mm semiconductor factories. The production equipment in these factories typically support the GEM 300 Standards. However, these solutions may also be applicable to some 200 mm factories.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 1 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
2.3 This Specification addresses two solution areas:
Recipe parameterization – specification of which parameters within the equipment recipe must be made available as RVPs. RVP values can be set at the initiation of recipe execution (e.g., using SEMI E30 remote commands or SEMI E40 process job messaging).
Recipe header – a user accessible collection of information describing each recipe component and its use. This is enclosed, along with the traditional recipe body in a single recipe component data set (e.g., file). Existing recipe format and content is preserved.
NOTICE: SEMI Standards and Safety Guidelines do not purport to address all safety issues associated with their use. It is the responsibility of the users of the documents to establish appropriate safety and health practices, and determine the applicability of regulatory or other limitations prior to use.
3 Limitations3.1 No limitations are specified.
4 Referenced Standards and Documents4.1 SEMI Standards and Safety Guidelines
SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM)
SEMI E40 — Standard for Processing Management
SEMI E157 — Specification for Module Process Tracking
4.2 ISO Standards1
ISO 8601:2004 — Data Elements and Interchange Formats – Information Interchange – Representation of Dates and Times
4.3 W3C Standards2
Extensible Markup Language (XML) 1.1 (Second Edition) – W3C Recommendation 16 August 2006; http://www.w3.org/TR/xml11/
XML Schema Definition Language (XSD) 1.1 Part 1: Structures – W3C Recommendation 5 April 2012
XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes – W3C Recommendation 5 April 2012
NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.
5 Terminology5.1 Abbreviations and Acronyms
5.1.1 FICS — factory information and control system
5.1.2 MES — manufacturing execution system
5.1.3 RVP — recipe variable parameter
5.1.4 SECS-II — SEMI Equipment Communications Standard 2
5.1.5 UTC — coordinated universal time
5.1.6 W3C — Worldwide Web Consortium
5.1.7 XML — eXtensible Markup Language
1 International Organization for Standardization, ISO Central Secretariat, 1, Ch. De la Voie-Creuse, CP 56, CH-1211 Geneva 20, Switzerland; Telephone: 41.22.749.01.11, Fax: 41.22.733.34.30, http://www.iso.org2 World Wide Web Consortium, Massachusetts Institute of Technology (MIT), 32 Vassar Street, Room 32-G515, Cambridge, MA 02139, USA. Telephone 617.253.2613; Fax: 617.258.5999; http://www.w3.org
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 2 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
5.2.1 equipment constant — a variable on the production equipment that can be read or changed by the host via the SECS-II interface. An equipment constant is typically used to affect conditions for equipment operation or performance.
5.2.2 equipment recipe — an executable specification of an activity or process on an equipment. The recipe is the user-managed, reusable portion of the set of instructions and settings that determine the processing environment seen by the material. Recipes may be subject to change between runs or processing cycles. An equipment recipe consists of one or more recipe components. [SEMI E157]
5.2.3 eXtensible Markup Language (XML) — a markup language used for representing data rich with context and content in documents and in communications. XML is an extension of SGML, a document-oriented markup language. It was created by W3C for use on the Internet. XML can represent object-oriented structures. [SEMI T20.3]
5.2.4 factory information and control system (FICS) — the software system that controls the operation of the factory and its equipment. It may include such components commonly referred to as the MES, station controllers, recipe managers, etc. [SEMI E168]
5.2.5 GEM 300 Standards — SEMI Equipment Communication Standards commonly implemented on equipment in 300 mm wafer fabs. The most commonly used GEM 300 Standards include SEMI E30, SEMI E40, SEMI E87, SEMI E90, and SEMI E94. [SEMI E168.1]
5.2.6 host — the factory computer system or an intermediate system that represents the factory and the user to the equipment. [SEMI E87]
5.2.7 manufacturing execution system (MES) — the factory system responsible for managing the manufacturing process, including logistics and process flow. [SEMI E98]
5.2.8 master recipe — the recipe component that represents the set of recipe components that make up an equipment recipe. Through the master recipe, the other recipe components (termed subordinate recipes) can be identified. It is typically the identifier of the master recipe that is specified to the production equipment for processing activities. If the recipe consists of only one recipe component, that component is the master recipe.
5.2.9 process job — a material processing job for a processing resource specifying and tracking the processing to be applied to the material. [SEMI E40]
5.2.10 process module — a component of the equipment capable of processing material (i.e., adding manufacturing value). Process chamber is another term for process module. The term process module applies equally to equipment components where measurement or inspection occurs.
5.2.11 production equipment — equipment used to produce semiconductor devices, including sorting, process, and metrology equipment and excluding material handling and storage equipment. [SEMI E157]
5.2.12 recipe component — an executable specification that is managed by the equipment as a separate entity (e.g., file). A recipe component represents all or part of an equipment recipe. A multi-part recipe consists of multiple recipe components, including a master recipe and one or more subordinate recipes. A recipe component may contain zero or more recipe steps.
5.2.13 recipe execution — the performance of activities within equipment according to the instructions and settings specified in an equipment recipe. Recipe execution does not permanently alter any recipe component of the equipment recipe.
5.2.14 recipe header — a part of a recipe component that contains a user-accessible collection of information describing the recipe component and its use. The recipe header is a non-executable portion of the recipe component.
5.2.15 recipe body — the executable part of a recipe component. A recipe body contains all settings and instructions needed to accomplish the purpose of the recipe component.
5.2.16 recipe variable parameter (RVP) — a setting contained in a recipe component within an equipment recipe whose value can be adjusted by the host for an execution of that recipe without making a permanent change to the associated recipe component. .
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 3 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
5.2.16.1 Discussion — An RVP can be set using SEMI E40 Process Job messaging. SEMI E30 specifies that it can also be set by host commands. SEMI E30 uses the term ‘variable parameter’ – see “variable parameter settings” and CPNAME/CPVAL in SEMI E30, §4.4. In this Specification, the terms are equivalent.
5.2.17 status value — a variable on the equipment that can be read, but not changed, by the host via the SECS-II interface. A status value is used to represent the state or condition of some aspect of the equipment.
5.2.18 subordinate recipe — a subsidiary recipe component in a multi-part recipe. A subordinate recipe is typically executed based upon a command or setting within another recipe component. See also ‘master recipe’.
5.2.19 variable parameter — a formally defined variable (setting) defined in the body of a recipe, permitting the actual value to be supplied externally. [SEMI E139]
5.2.19.1 Discussion — Variable parameter is a term used in SEMI E30 for parameters applied to remote commands. These commands include recipe execution. In this Specification, the terms recipe variable parameter and variable parameter are equivalent.
6 Conventions6.1 Requirements Identification
6.1.1 The following notation specifies the structure of requirement identifiers.
6.1.1.1 The following requirements prefix format is used at the beginning of requirement text. See Table 1 for the format notation of the requirements prefix.
[Esss.ss-RQ-nnnnn-nn]
6.1.1.2 To mark the end of the requirement text the following suffix format is used.
[/RQ]
6.1.1.3 Requirements in the body text are highlighted with a border and light green background (may appear gray in black and white printouts).
[Esss.ss-RQ-nnnnn-nn] Requirement text. [/RQ]
Table 1 Requirement Identifiers
Format Notation Purpose
Esss.ss SEMI Standards Specification identifier. Examples: E30.00, E40.01.RQ Indicates this is a requirement identifier.nnnnn Unique five-digit number within this Specification. 90000–99999 are reserved for use by SEMI..nn Two-digit number that indicates version level of the requirement. A value of .00 is used for the
first version of a requirement./RQ Indicates the end of a requirement.
6.1.2 Requirements in tables are delimited in one of two ways.
6.1.2.1 Where the requirement occupies an entire row in the table, the requirement identifier is placed in column 1. No ‘[/RQ]’ is used to mark the end of the requirements text in this case. The table may also contain rows that are not requirements. In this case, the column 1 cell is left blank.
6.1.2.2 Nonrequirements text related to a requirements row may be included in an adjacent row. The relationship between the rows is indicated by a broken line separating the two.
6.1.2.3 Where the requirement occupies only one cell, the text in the cell includes the requirement identifier prefix and suffix similar to requirements in the body text.
6.1.2.4 No cell in a table will contain both requirement and nonrequirement text.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 4 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
6.1.2.5 Cells that contain requirements are shaded light green.
6.1.2.6 Table 2 provides an example of requirements in a table. Note that in this example, the same requirement is presented in two alternative formats. In practice, mixing the two approaches in the same table is not typically done.
Table 2 Example Table With Requirements
RequirementID Statement Additional Detail
Esss.ss-RQ-nnnnn-nn The light shall be blue There shall be no similar color in the light panel.
The blue light is typically placed at the leftmost position in the light panel.[Esss.ss-RQ-nnnnn-nn] The light shall be blue. There shall be no similar color in the light panel. [/RQ]
The blue light is typically placed at the leftmost position in the light panel.
6.1.3 Only text marked with the requirement identifier is a requirement of this Specification.
6.1.3.1 Clarification, examples, and related recommendations may be provided near a requirement, but are not part of the requirement.
6.1.3.2 Note that the word ‘should’ is used in some nonrequirements text, where it denotes a recommendation or a best practice, not a requirement.
6.1.3.3 Note that the words ‘must’ and ‘will’ may be used in the overview (§ 7 ) to illustrate the logical result of requirements specified in the prerequisites and requirements (§ 8 and § 9 ). Such statements should not be considered requirements.
6.1.4 Parent-child relationships of requirements are noted in the tables in Appendix 1. Where a parent requirement includes conditions or selection criteria, these are passed to their children. For example, if a parent requirement is stated to apply only to photolithography equipment, any child requirements also apply only to such equipment. The condition need not be restated for each child requirement.
6.1.4.1 Compliance to a parent requirement includes compliance to all of its child requirements.
6.1.4.2 Some cells or rows in a table may contain headings that are assigned a RequirementID. These are parent requirements for other requirements in the table, typically for the rows that immediately follow that heading.
7 Implementation Overview7.1 The focus of this Specification is a set of two capabilities:
Recipe parameterization
Recipe header
7.1.1 These capabilities are summarized here and then specified in detail in § 9 . This overview refers to requirements defined later in the Specification. However, no statement in this overview section is intended to specify a requirement.
7.2 Recipe Terminology and Relationships
7.2.1 The recipe-related terminology used in this Specification is similar to that defined in SEMI E157. This terminology recognizes that some equipment recipes are made up of multiple recipe components. Each recipe component is managed as a separate entity that can be uploaded and downloaded via the SECS-II interface.
7.2.2 The term ‘equipment recipe’ refers to a collection of recipe components that form a complete specification as needed for recipe execution in the production equipment. This may be a single recipe component or many.
7.2.3 Figure 1 illustrates the recipe component, as defined in this Specification to include a recipe header and recipe body. It also shows various items that are related to the recipe component. This diagram assumes that processing is initiated via SEMI E40 process jobs (see also ¶ 8.2.2 ).
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 5 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
7.2.3.1 Note that ‘RVP Value’ in the figure refers to the value provided by the host for a particular RVP defined in one of the recipe components of the equipment recipe being executed. All other items referenced in Figure 1 are defined in § 5.2 .
Figure 1Relationships of Exxx Recipe Components
7.3 Recipe Parameterization
7.3.1 Recipe parameterization refers to the ability of the host to modify recipe execution on production equipment by specifying new values for recipe settings at the initiation of recipe execution and/or during recipe execution. This is typically done in 300 mm factories by using the recipe variable parameters feature of SEMI E40. It can also be done using the essentially similar feature called ‘variable parameters’ with remote commands, as described in SEMI E30. The definition of RVP in this specification encompasses both cases.
7.3.2 RVPs are needed in order to control the process on a run-to-run basis without constantly modifying the equipment recipes. Other SEMI Standards, such as SEMI E30 and SEMI E40 do not specifically require that sufficient RVPs be made available on the production equipment for this purpose. Therefore, this Document specifies such a requirement (see § 9.3 ).
7.4 Recipe Header
7.4.1 Traditionally, the contents of most recipe components are hidden from the users. In those cases, the only piece of information the user can consistently gather from the recipe component is the recipe identifier (RecipeID). Any additional information about the recipe component has to be entered manually into the factory system. Such manual data entry is prone to mistakes, which can lead to lost time and misprocessing.
7.4.2 The purpose of the recipe header capability is to add a user accessible collection of information describing the recipe component and its use. The addition of the recipe header preserves the traditional recipe content by structuring the new recipe component format to contain both the header and the traditional recipe content (recipe body).
7.4.2.1 The recipe header can be used to verify the identity of the recipe component (see § 7.4.3.2 ) and to understand its purpose and structure. Header fields tell the user when the recipe component was created, where, and by whom. They also provide a detailed description (provided by the author) as well as key information such as the recipe type, the subordinate recipes needed, and any other data the supplier wishes to share.
7.4.2.2 The recipe header is included when the recipe component is created and updated each time the recipe component is modified. Thus, the header information pertains specifically to the current version of the recipe component.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 6 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
7.4.2.3 All recipe execution instructions and settings need to be contained within the recipe body. The recipe header is intended only for informational purposes.
7.4.2.4 For recipe execution, the production equipment can ignore the recipe header and extract the recipe body. Thus, recipe execution by the equipment should be essentially unchanged by the addition of the recipe header.
7.4.3 Recipe Component Types
7.4.3.1 Production equipment may support more different types of recipe components for different uses.
7.4.3.1.1 For example, a production equipment might support ‘Sequence’ recipe components that reference subordinate recipes for each type of module present (e.g., ‘Etch’, ‘Clean’, etc.). It might also support ‘Maintenance’ or ‘Calibration’ recipe components.
7.4.3.2 The recipe header contains a RecipeType field that allows the equipment supplier to identify the type of each recipe. Each type of recipe component supported may have different uses and may support a different set of RVPs. The examples given above (i.e., Sequence, Etch, Clean, Maintenance, Calibration) could be declared as RecipeTypes.
7.4.3.3 The RecipeType field in the recipe header allows the user to differentiate among the different types of recipe components the production equipment might support.
7.4.3.4 All RecipeTypes are assigned by the equipment supplier.
7.4.4 Unique Identification of Recipe Components
7.4.4.1 RecipeID is another field in the recipe header. RecipeID is not necessarily a unique identifier of a recipe component. Recipe component content can change without the RecipeID changing. Some consider these to be different versions of the same recipe.
7.4.4.2 Using a combination of recipe header fields, it can be possible to uniquely identify the recipe component.
7.4.4.2.1 For example, if the RecipeID is combined with the date and time the recipe component was created (i.e., CreateDateTime field), this will uniquely identify the recipe component in most cases. An even higher degree of confidence in the unique identity of the recipe can be achieved by adding the identities of the author (i.e., Author field) and/or the location where the most recent version of the recipe component was created (i.e. SourceID field).
7.4.4.3 The VersionID is another recipe header field that can be combined with the RecipeID to uniquely identify the recipe.
7.4.4.3.1 The VersionID is a field that can be set in the recipe component only with the cooperation of the FICS. The VersionID value is intended to be assigned by the factory. In a typical case, the recipe component is created at the equipment with the VersionID set to a zero-length string. Upon upload, the recipe component might be checked-in to a recipe management system. A part of this check-in could be the modification of the recipe header with a factory generated VersionID.
7.4.4.3.2 It is also possible for the recipe editor to work in conjunction with the FICS to obtain a VersionID from the factory at the time the recipe is created or edited. It should be noted that a recipe editor might be from the equipment supplier, from the factory user, or from a third party. It may exist on the production equipment or external to the production equipment.
7.4.4.3.3 The user has the option not to use the VersionID. In that case, the value of VersionID will remain a zero-length string.
7.4.5 Recipe Component Formats
7.4.5.1 This Specification defines two forms for recipe components:
Exxx Unformatted Recipe – a recipe component that includes a recipe header of specified content plus a recipe body whose format is left to the equipment supplier’s discretion. The recipe body is equivalent to the PPBODY of the SEMI E30 Unformatted Process Program. The recipe header is formatted in XML.
Exxx Formatted Recipe – a recipe component that is formatted according to the rules for a SEMI E30 Formatted Process Program, but with the first set of command codes specified to contain the recipe header fields defined in this Specification.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 7 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
7.4.5.2 It also recognizes two other recipe component structures that are specified in SEMI E30:
E30 Unformatted Process Program – a recipe component that consists of a single SECS data item, the PPBODY, whose format is left to the implementer and is often unknown to the host.
E30 Formatted Process Program – an ordered sequence of data item pairs, each of which consists of a command code and a list of parameters delivered in a SECS-II message.
7.4.5.3 Other recipe component structures are also acceptable. The E30 structures are listed above because they are standardized and in common use.
7.4.6 Transition to Use of Exxx Recipes
7.4.6.1 This Specification adds new requirements for production equipment to support equipment recipes with recipe headers (i.e., Exxx formatted recipes and/or Exxx unformatted recipes). It does not forbid the production equipment from also supporting recipe formats without recipe headers, such as those in existence before this Specification was approved, such as E30 unformatted process programs and E30 formatted process programs.
7.4.6.1.1 It is anticipated that the executable portion of the recipe would be essentially similar in either case.
7.4.6.2 All recipe types supported by the production equipment are intended to be allowed at all times. That is, there should be no configuration settings to determine which supported recipe types are allowed at a given moment. This will help a factory transition to use of Exxx recipes in an incremental fashion, even while some non-Exxx recipes are still in use.
7.4.6.3 If a recipe editor is present on the production equipment, the user is intended to have the option of which supported recipe type is used to save a new or modified recipe component.
8 Prerequisites8.1 This Specification applies to communications between production equipment and host. It assumes that the production equipment supports SECS-II communication as specified in SEMI E5.
[Esss.00-RQ-00002-00] Production equipment shall implement communications conforming to SEMI E5. [/RQ]
8.1.1 The Process Recipe Management section of SEMI E30 specifies a choice among multiple approaches for managing recipe components. This Specification supports the E30 Process Program approach, but is not limited from supporting other approaches if they are compatible with this specification.
8.2 Recipe parameterization assumes that RVPs can be set prior to or during initiation of recipe execution. A means for setting RVPs is needed.
[Esss.00-RQ-00003-00] The production equipment shall provide a means for setting RVPs prior to or during initiation of recipe execution. [/RQ]
8.2.1 In 300 mm factories, this is typically done using SEMI E40 Process Job Management. Process jobs specify the equipment recipes to be used during processing and a mechanism to specify values for RVPs that override the settings in the stored recipe components for the specified process job.
8.2.2 It is also possible to use remote commands, as specified in SEMI E30, to set variable parameters. This is more common in 200 mm factories.
9 Requirements9.1 The following is the top-level parent requirement of all others in this Specification.
[Esss.01-RQ-00001-00] Compliance to this Specification requires compliance to all other identified requirements in this Specification, including Complementary Files, as applicable according to stated conditions. [/RQ]
9.2 The requirements are divided into two primary capabilities: recipe parameterization, and recipe header.
9.2.1 Note that an equipment supplier can report compliance to the individual capabilities, but that RQ-00001 states that compliance to the entire specification requires compliance to both of the primary capabilities. See APPENDIX1 for the statement of compliance.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 8 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.3 Recipe Parameterization
9.3.1 Parameter Availability
9.3.1.1 For 300 mm wafer fabs, SEMI E40 specifies a mechanism to set the values of RVPs at the initiation of recipe execution. SEMI E30 provides a similar mechanism to set variable parameters for remote commands in 200 mm factories. To fully support recipe parameterization, the appropriate collection of RVPs needs to be made available.
9.3.1.2 To the extent feasible, the equipment supplier should make available, as RVPs, all recipe settings that are available to the production equipment user during recipe creation.
9.3.1.2.1 Exceptions to this recommendation include those settings whose modification requires testing, reconfiguration, or recalibration of the production equipment to assure that the recipe will run correctly.
9.3.1.2.2 Settings should also be excluded from being RVPs if it is not possible for the FICS to determine safe and accurate values for these settings without the assistance of the production equipment. .
9.3.1.3 This Specification is limited to settings that exist within the recipe components. It does not address inclusion or documentation of settings external to the equipment recipe (e.g., equipment constants) as RVPs.
9.3.1.4 The equipment supplier is recommended to list in the interface documentation any recipe settings that are not available as RVPs along with explanation of why they were not made available.
9.3.1.5 Documentation of the RVPs promotes correct usage.
9.3.1.5.1 It is recommended that this documentation be provided in a computer-readable format (for example, comma delimited or XML). The precise format is not defined in this document.
[Esss.00-RQ-00004-00] All RVPs shall be described in the interface documentation by the equipment supplier, including values for the Name, Maximum, Minimum, Description, Format, and Units as appropriate according to specifications in Table 3. [/RQ]
RequirementID Field Name Description and Structure
Esss.00-RQ-00005-00 Name The name of the RVP (string)
Esss.00-RQ-00006-00 MaximumThe maximum setting allowed for the RVP. This does not apply for non-scalar variables. The format matches the Format definition for the RVP.
Esss.00-RQ-00007-00 MinimumThe minimum setting allowed for the RVP. This does not apply for non-scalar variables. The format matches the Format definition for the RVP.
Esss.00-RQ-00008-00 Description Equipment supplier provided description of the RVP (string)
Esss.00-RQ-00009-00 FormatThe required format of the RVP. (string) If the equipment can accept multiple formats, all acceptable formats shall be included.
Esss.00-RQ-00010-00 Units
The units of the RVP, where applicable. (list of strings) Most RVPs will have only one unit listed. However, where the system configuration can change the units (for example °C to °F), all possible units should be listed.
9.4 Recipe Header
9.4.1 The recipe header feature combines the executable portion of a recipe component (called recipe body) with a user-accessible set of information called the recipe header.
[Esss.00-RQ-00011-00] The production equipment shall support upload, download, and execution of recipe components that contain a recipe header. [/RQ]
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 9 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.4.2 RecipeHeader Content
9.4.2.1 Table 4 provides definitions of the recipe header data fields.
[Esss.00-RQ-00012-00] The recipe header shall include the fields listed in Table 4 as applicable according to stated conditions. [/RQ]
[Esss.00-RQ-00013-00] The content of the recipe header shall be populated when the recipe component is created and it shall be updated whenever the recipe component is modified. [/RQ]
9.4.2.2 For example, the CreateDateTime field would contain the time this recipe component was last saved. It does not represent the time at which the recipe component was originally created.
9.4.2.3 During recipe creation and modification, user entry of the information should not be required except as noted.
Table 4 Recipe Header Data Fields
RequirementID Field Name Description and Structure
Esss.00-RQ-00014-00 Recipe Identifier (RecipeID)
A string provided by the user during recipe creation and modification to identify the recipe component, maximum 120 characters. RecipeID is equivalent to PPID in SEMI E30, RecID in SEMI E40, and RCID in SEMI E157 when those Specifications are implemented.
Esss.00-RQ-00015-00 VersionID
A string that identifies this particular adaptation of a base recipe that shares the same RecipeID, maximum 256 characters. It is intended to be populated based upon factory business rules. Upon creation or modification of a recipe component, the VersionID shall be set to a zero-length string unless the recipe editor is able to work in conjunction with the FICS for proper VersionID assignment.Any two recipes in the factory with the same RecipeID and non-zero-length VersionID shall have the same content for the recipe body.A recipe editor that is not integrated with factory business rules would not be able to determine an appropriate VersionID. The FICS may populate the VersionID at a later time, for example at the time the recipe is checked-in to the factory recipe management system. If the FICS does not choose to use the VersionID for a particular recipe component, the VersionID will remain a zero-length string. When a VersionID is assigned, the combination of RecipeID and VersionID would provide unique identification of the recipe component within the factory.
Esss.00-RQ-00016-00 Source Identifier (SourceID)
The identifier of the system on which this version of the recipe component was saved (string), maximum 80 characters
Esss.00-RQ-00017-00 For recipes created with an onboard recipe editor, the SourceID shall contain the equipment identifier.
Esss.00-RQ-00018-00 Creation Date & Time (CreateDateTime)
Date and time that this version of the recipe component was finalized and saved as a valid recipeFor an Exxx unformatted recipe, the value shall have an ISO 8601 format of the form YYYY-MM-DDThh:mm:ss.sTZD as described in ¶ 9.4.2.4 .For an Exxx formatted recipe, the value shall follow the SEMI E5 TimeFormat setting for the system where the recipe was last edited.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 10 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
RequirementID Field Name Description and Structure
Esss.00-RQ-00019-00 RecipeType Equipment supplier specified string used to differentiate the kinds of recipe components used on this equipment, maximum 80 charactersFor example, the supplier might designate a “Sequence” type plus types for specific process modules, such as “Etch”, “Clean”, etc.
Esss.00-RQ-00020-00 DescriptionExplanation of the recipe component, maximum 4096 charactersThis string is entered by the user during recipe creation and modification.
Esss.00-RQ-00021-00 AuthorIdentifier associated with the user who created this version of the recipe component, maximum 80 charactersThis can be a user-entered value.
The list of zero or more subordinate recipes needed by this recipe component to execute properly. Subordinate recipes are referenced by RecipeID, maximum 120 characters.
Esss.00-RQ-00023-00 Supplier Information (SupplierInfo)
Equipment supplier-defined information items. This field is a list of strings, maximum 1024 characters. SupplierInfo is intended to allow the equipment supplier to include information in the header that is useful to the users or to field technicians without access to the recipe body content. The SupplierInfo field shall be excluded from the recipe header if it has no content.
Esss.00-RQ-00024-00
When SupplierInfo is provided, the items within the SupplierInfo field shall be completely described by the equipment supplier in the interface documentation. This shall include name, description, format, and intended purpose.
9.4.2.4 For CreateDateTime in an Exxx unformatted recipe, the required format YYYY-MM-DDThh:mm:ss.sTZD is broken down in ISO 8601 in this way:
YYYY – four digit year value
MM – two-digit number of the month (e.g., 01 is January)
T – separator character ‘T’ that indicates that the time value follows
hh – two-digit hour value 01 through 24 (am/pm designators are not used)
ss.s – two digit seconds value 00 through 60 plus one or more digits representing a decimal fraction of a second
o Note that Table 4 specifies exactly one decimal place, which gives tenths of seconds.
TZD – time zone designator, which is an offset from UTC that is more fully explained in ISO 8601.
9.4.2.4.1 For example, a CreateDateTime in Pacific Standard Time might be 2013-06-05T06:05:43.7-08:00.
9.4.2.5 The SupplierInfo field is designed as a simple list of strings for compatibility with SECS-II formatted process programs. This allows for flexibility in implementation. See more on string formats in ¶ 9.4.3.5 .
9.4.2.5.1 The strings could contain string representations of other data types such as integers, floats, Boolean, etc.
9.4.2.5.2 The strings may be structured. For example, the string may be a comma separated set of values (such as “red, green, blue”) or include a name and value (such as “index=57”).
9.4.3 Recipe Component Format
9.4.3.1 This Specification provides for two different formats of recipe components. It differentiates between formatted and unformatted recipe components.
9.4.3.2 Unformatted recipe components are transferred via SECS-II as a single data item called PPBODY in such messages as S7F3/F4, S7F5/F6, S7F37/F38, and S7F41/F42. The internal structure of the unformatted recipe component need not be known to the systems that upload, download, and store the recipes.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 11 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.4.3.2.1 These unformatted recipe components are referred to as Exxx unformatted recipes. See § 9.4.3 for more detail and requirements related to Exxx unformatted recipes.
9.4.3.3 SEMI E5 defines the structure of ‘formatted process programs’ in SECS-II messages such as S7F23 and S7F26. These are presented as an ordered sequence of command codes, each with a simple list of associated parameters. Formatted recipe components defined in this Specification use that structure and the associated SECS-II messages.
9.4.3.3.1 These formatted recipe components are referred to as Exxx formatted recipes. See § 9.4.5 for more detail and requirements related to Exxx formatted recipes.
[Esss.00-RQ-00025-00] Production equipment shall support at least one of the following formats for recipe components: Exxx unformatted recipes and/or Exxx formatted recipes. [/RQ]
9.4.3.4 The production equipment is allowed to support additional recipe component formats, such as E30 unformatted process programs and E30 formatted process programs (see § 7.4.5 ).
9.4.3.5 Implementers should note that the two different recipe component formats include different restrictions on the formats of individual fields. The XML format is limited to UTF-8 formatting by RQ-00026. Formats for fields in SECS-II messages are specified in SEMI E5 and sometimes further restricted in other standards such as SEMI E30. It is assumed that implementers will conform to applicable specifications as appropriate.
9.4.4 Exxx Unformatted Recipes
[Esss.00-RQ-00026-00] Exxx unformatted recipes shall be formatted in XML with UTF-8 encoding and conform to the XML schema included as a Complementary File named ‘Exxx-mmyy-PRI-Schema.xsd’. [/RQ]
9.4.4.1 The Complementary File is an XML schema. An XML schema describes a type of XML document in terms of constraints on the content and structure of that document.
9.4.4.1.1 This XML schema is referred to in this Specification as the ‘PRI schema’.
9.4.4.2 Exxx unformatted recipes are formatted in XML. The word ‘unformatted’ refers to the content of the recipe body portion of the recipe component. In the XML data set, the Recipe element contains a RecipeHeader element and a RecipeBody element (see Figure 2 below). This Specification defines the content of the RecipeHeader element. The RecipeBody format is left to the equipment supplier.
9.4.4.3 Recipe Validation
9.4.4.3.1 The process of checking to see whether an XML document conforms to an XML schema is called validation. There are numerous tools available for validating an XML data set against a schema and for checking that the XML is well-formed.
9.4.4.3.2 Not all requirements can be validated by an XML schema. Certain detailed requirements are included as text within the XML schema.
[Esss.00-RQ-00027-00] When generating an Exxx unformatted recipe, the equipment supplier shall follow all textual instructions and requirements embedded in the schema. These appear in the schema within xs:documentation fields. [/RQ]
9.4.4.3.3 The equipment is responsible for validating the recipe component against the schema in two different situations, as described in RQ-00028 and RQ-00029.
[Esss.00-RQ-00028-00] All Exxx unformatted recipes shall be successfully validated using the Exxx-mmyy-PRI-Schema.xsd schema upon creation and modification, before they become available for use. [/RQ]
[Esss.00-RQ-00029-00] When an Exxx unformatted recipe is downloaded to the production equipment, it shall be accepted only if it is successfully validated by the production equipment using the Exxx-mmyy-PRI-Schema.xsd schema. [/RQ]
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 12 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.4.4.4 Exxx Unformatted Recipe Structure
9.4.4.4.1 As noted above, the structure of an unformatted recipe component that includes the RecipeHeader is governed by the PRI schema. Figure 2 illustrates the structure of the Exxx unformatted recipes defined in that XML schema. The diagram is a representation of an XML schema using the graphical notation created by Altova GmbH3.
Figure 2Exxx Unformatted Recipe Structure
9.4.4.4.2 Table 5 provides an explanation of the symbols used in Figure 2.
Table 5 Schema Diagram Symbols
Denotes a required ordered sequence of the right hand elements with a cardinality of one for each element. (sequence)
Denotes a required choice of one the right hand elements. (choice)
Denotes an element that contains other elements or attributes.
NameName Denotes an element that contains a data value.
Notes: All optional items are denoted by the element outlined with dashed
lines as shown to the right. Cardinality is assumed to be exactly one unless a value is shown. In
this example, it is “zero or more.”
3 The image in Figure 2 and symbols in Table 5 were created using Altova XMLSPY®. Copyright 2007-2011 Altova GmbH.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 13 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.4.4.5 RecipeBody
9.4.4.5.1 The RecipeBody enclosed in the ExxxUnformattedRecipe construct is allowed to be an equipment supplier-defined format. In the XML-based recipe component, the RecipeBody can be represented as any format allowed in XML, signified by the format xs:any defined in the XML schema. As shown in Figure 2, the simpler binary (xs:hexBinary or xs:base64Binary) and string (xs:string) formats are available for the case where a more complex format is not needed.
9.4.4.5.1.1 It should be noted that binary fields must be serialized to be included directly in an XML data set (e.g., XML file). There are various other methods available for handling large binary elements in XML.
9.4.4.6 Exxx Unformatted Recipe Example
9.4.4.6.1 Figure 3 contains an example of an unformatted recipe component. This recipe component conforms to the PRI schema. The RecipeBody content is abbreviated for display purposes.
Figure 3Example Exxx Unformatted Recipe
9.4.5 Exxx Formatted Recipes
9.4.5.1 Exxx formatted recipes use the structure and messaging defined in SEMI E5 for formatted process programs.
[Esss.00-RQ-00030-00] Exxx formatted recipes shall be structured to be compatible with SEMI E5 formatted process programs. This includes the use of SECS-II messages such as S7F23-F24 and S7F25-F26 to transfer these recipe components between production equipment and host. [/RQ]
9.4.5.2 It should be noted that S7F39-F40 and S7F43-F44, used for large process programs, are also applicable.
9.4.5.3 SEMI E5 formatted process programs are structured as a list of CCODE (command code), with each CCODE containing a list of PPARM (process parameter):
L,n (n = Number of Commands) L,2
1. <CCODE>2. L,m (m = Number of Parameters) 1. <PPARM1
: m. <PPARMm
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
<RecipeHeader><RecipeID>P257S057V21</RecipeID><SourceID>TrackSys404-15421</SourceID><CreateDateTime>2013-06-05T06:05:43.7-08:00</CreateDateTime><RecipeType>Bake</RecipeType><Description>Purpose is to...</Description><Author>Bill.Jones</Author><SubordinateRecipes/>
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
9.4.5.4 The following requirements also apply to formatted recipe components:
[Esss.00-RQ-00031-00] Each field in the recipe header of an Exxx formatted recipe shall be represented as a separate CCODE in the E5 formatted process program structure. [/RQ]
[Esss.00-RQ-00032-00] If the equipment supplier uses ASCII-formatted CCODES, then the CCODE shall match the name of the recipe header field: RecipeID, SourceID, CreateDateTime, RecipeType, Description, Author, SubordinateRecipes, and SupplierInfo. Otherwise, the equipment supplier shall specify in the interface documentation which CCODE corresponds to each of those recipe header fields. [/RQ]
[Esss.00-RQ-00033-00] PPARM items in the Exxx formatted recipes shall contain the value(s) of for each of the recipe header fields formatted as strings (format 20). [/RQ]
[Esss.00-RQ-00034-00] The recipe header items shall appear in Exxx formatted recipes at the beginning of the recipe structure. That is, the first eight CCODEs in the list shall be the recipe header fields (or the first seven if no SupplierInfo is included – see Table 4, RQ-00022) [/RQ]
9.4.5.5 Exxx Formatted Recipe Example
9.4.5.5.1 Figure 4 contains an example of an Exxx formatted recipe. This recipe component conforms to the SECS-II structure for formatted process programs as found within the SEMI E5 messages S7F23, S7F26, and others. The content of the recipe header portion is the same as the example Exxx unformatted recipe shown in Figure 3.
9.4.5.5.2 The example does not show a complete SECS-II message. It shows only the list of CCODEs and accompanying PPARM values. For the complete message structure, please see SEMI E5, Stream 7, Functions 23, 26, 31, 39, or 43.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 15 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
Figure 4Example Exxx Formatted Recipe
9.4.6 Production Equipment Handling of Recipe Components
[Esss.00-RQ-00035-00] At any time that the production equipment is able to accept a recipe component for upload, download, or execution, it shall accept recipes of any recipe type that it supports. This includes Exxx formatted recipes and/or Exxx unformatted recipes. [/RQ]
9.4.6.1 The production equipment is not intended to accept only one supported recipe type at a time. For example, there should not be a configuration setting to switch between accepting recipe components with recipe headers and those without.
[Esss.00-RQ-00036-00] A production equipment that includes an onboard recipe editor shall be capable of creating or modifying a recipe component in any recipe format supported by that production equipment. This includes Exxx formatted recipes and/or Exxx unformatted recipes. [/RQ]
9.4.6.2 This specification does not prevent a production equipment from providing the user an option to create recipe components without a recipe header.
[Esss.00-RQ-00037-00] A production equipment that includes an onboard recipe editor shall be capable of modifying a recipe component of any recipe format supported by that production equipment and saving it either as an Exxx formatted recipe or as an Exxx unformatted recipe (whichever format is supported). [/RQ]
9.4.6.3 Thus, the recipe editor is expected to be able to modify an existing recipe component that has no recipe header and save the new version in a format with a recipe header.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
10 Related Documents10.1 SEMATECH4
10.1.1 SEMATECH Process Recipe Management Guidance, Version 1.0; December 2, 2013
4 SEMATECH, 257 Fuller Road, Suite 2200, Albany, NY 12203, USA, Telephone: 518-649-1000, http://www.sematech.org
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 17 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
DRAFTDocument Number: 5618A
Date: 5/5/23
APPENDIX 1STATEMENT OF COMPLIANCENOTICE: The material in this Appendix is an official part of SEMI Esss.1 and was approved by full letter ballot procedures on MMM DD, YYYY.
A1-1 Statement of Compliance
[Esss.00-RQ-90001-00] Each implementer of this Specification shall complete a Capability Requirements compliance table per Table A1-1 when reporting on compliance to Esss.00. [/RQ]
A1-2 Compliance Table: Capability Requirements
[Esss.00-RQ-90002-00] Each implementer of this Specification shall document compliance to Esss.00 capability requirements per Table A1-1 with the following compliance codes: C – comply, NC – not comply, WC – will comply, NA – not applicable. [/RQ]
[Esss.00-RQ-90003-00] The NA code shall be used only in the case where a requirement is conditional and the condition evaluates to render the requirement not applicable for the current implementation. [/RQ]
A1-2.1 Child requirements inherit the conditional status of the parent requirement. Where a parent requirement is marked NA, the child requirements should also be marked NA.
[Esss.00-RQ-90004-00] An explanation for NC shall be provided by the implementer. [/RQ]
A1-2.2 If WC is assigned, the implementer should provide a date for implementation.
A1-2.3 Items included in the Condition/Selection Criteria column of Table A1-1 are defined in Table A1-2.
[E168.00-RQ-90006-00] Each implementer of this Specification shall include in the completed Capability Requirements compliance table a value as specified in Table A1-2 for all defined conditions or selection criteria included in Table A1-1. [/RQ]
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 18 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 19 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
Capability: 9.4.6 Production Equipment Handling of Recipe Components9.4.6 Esss.00-RQ-00035-00 Esss.00-RQ-00011-00 <none>9.4.6 Esss.00-RQ-00036-00 Esss.00-RQ-00011-00 OnBoardEditor =9.4.6 Esss.00-RQ-00037-00 Esss.00-RQ-00011-00 OnBoardEditor =
A1-3 Compliance Table: Equipment Conditional and Selection Criteria
[Esss.00-RQ-90005-00] Each implementer shall document Esss.00 specific conditional and selection criteria per Table A1-2. [/RQ]
A1-3.1 Conditional and selection criteria are used to identify when and how certain requirements are to be implemented on the equipment.
Table A1-1 Conditional and Selection Criteria
Name Values Description Section
OnBoardEditor
True
False
The production equipment includes a recipe editing capability.
No recipe editing capability is included on the production equipment.
9.4.2 , 9.4.6
SupplierInfoProvided
True
False
Recipe components of a particular recipe type include SupplierInfo data.
Recipes of the particular recipe type do not include SupplierInfo data.
9.4.2
CCODEFormat
Numeric
ASCII
The CCODE used for formatted process programs is numeric (formats 32, 34, 52, or 54).The CCODE used for formatted process programs is ASCII (format 20).
9.4.5
NOTICE: Semiconductor Equipment and Materials International (SEMI) makes no warranties or representations as to the suitability of the Standards and Safety Guidelines set forth herein for any particular application. The determination of the suitability of the Standard or Safety Guideline is solely the responsibility of the user. Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant literature, respecting any materials or equipment mentioned herein. Standards and Safety Guidelines are subject to change without notice.
By publication of this Standard or Safety Guideline, SEMI takes no position respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this Standard or Safety Guideline. Users of this Standard or Safety Guideline are expressly advised that determination of any such patent rights or copyrights, and the risk of infringement of such rights are entirely their own responsibility.
This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.
Page 20 Doc. 5618A SEMI
Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943
