Equipment Modeling in EDA

Transcription

1 SEMICON West 2009 Accelerating Manufacturing Productivity Equipment Modeling in EDA Gino Crispieri Copyright 2009 SEMATECH, Inc. SEMATECH, and the SEMATECH logo are registered servicemarks of SEMATECH, Inc. International SEMATECH Manufacturing Initiative, ISMI, Advanced Materials Research Center and AMRC are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners.

2 Outline Modeling Equipment in EDA Metadata Requirements Modeling Guidelines Common Metadata Constructs Material Management MaterialManager Subsystem Material Locations Load Port Subsystems Process Management JobManager Subsystem Simple Recipe Execution State Machine (SRESM) SEMI E30 State Models Relating SECSII Data to EDA SEMI E116 Conclusions 2

3 Modeling Equipment in EDA An important consideration when integrating semiconductor equipment into the factory is the ease with which the equipment s structure and capabilities can be understood and translated into functioning software The metadata should be understandable to its consumers and sufficiently detailed to accomplish the consumers tasks It is important that the metadata model provide a view that promotes understanding of the equipment and thus accessibility to the data without sacrificing accuracy It should relate the equipment function to its structural components 3

4 Metadata Model It should include the fewest hierarchical levels necessary to present an accurate representation of the equipment It is intended to help monitor and maintain equipment operational health and performance The metadata model should represent equipment components from a functional viewpoint, rather than explicit representations of the control computers and infrastructure (sensor network/bit bus, I/O cards, computer racks, etc.) 4

5 Modeling Guidelines Production Equipment Equipment Module (Process) Equipment Subsystem (Wafer Transport) Equipment Subsystem (Buffer) Equipment Subsystem (Load Port)... Equipment Subsystem (Carrier Transport) Equipment Subsystem (Carrier Storage Unit) Equipment Subsystem (Substrate Port) The preferred metadata model configuration has all major tool components (process chambers, loadports, buffers, transfer stations, etc.) defined as child nodes of the equipment Equipment nodes defined in the metadata shall have a total of two or more of any or all of the following: Parameters, Exceptions, and Events 5

6 Common Metadata Constructs Equipment EPTTracker EPTTracker EPTTracker Module Module Module MaterialManager JobManager Subsytem Subsytem Subsytem EPTTracker EPTTracker Specific constructs that will appear in equipment metadata come from three sources: Equipment supplier-defined modules and subsystems SEMI standards commonly implemented on equipment that define applicable objects, state models, etc. The primary focus for this is the 300 mm standards (SEMI E30, E40, E87, E90, and E94, but also SEMI E116) The Simple Recipe Execution state model The constructs presented here today are intended to move toward a more common metadata representation of all required equipment data 6

7 Material Management Subsystem Material Manager 1..* 0..* objtypes Carrier Substrate SEMIObjType standardversion objtype statemachineinstance 0..* attributes 1..* StateMachineInstance parameter eventdata 0..* SEMI E87 Carriers and SEMI E90 Substrates are non-static dynamic SEMI Objects that can be present on the equipment ISMI has added the concept of MaterialManager to hold these and all other instances of material objects when present The equipment metadata shall include a MaterialManager, modeled as a nonstructural Subsystem associated with the Equipment node This MaterialManager will be the source for all material-related elements All SEMI Objects that represent Carriers, Substrates, or ProcessDurables shall be associated with the MaterialManager Subsystem 7

8 Material Locations EDA-123: Equipment Type = Carrier LP: Subsystem TX: Subsystem LPML: Material Location TXML: Material Location Type = Substrate PM: Module PMML: Material Location Substrate Movement HB: Subsystem C-Temp: Subsystem Load Port (LP) Substrate Transfer Module (TX) Process Module (PM) N2MFC: Subsystem Equipment (EDA-123) Thermometer (C-Temp) Heater Block (HB) N 2 Mass Flow Controller (N2MFC) All Carrier Locations (i.e., MaterialLocations) used for transferring Carriers into or out of an equipment shall be modeled as child nodes of a loadport Substrate and Batch Location Object The SEMI E90 Substrate and Batch Locations shall be represented in the metadata as a MaterialLocation with materialtype = Substrate A StateMachineInstance of the SEMI E90 Batch Location State Model shall be attached to the MaterialLocation 8

9 Loadport Subsystems Access Mode State Model (E87) Load Port Transfer State Model (E87) EPT State Model,Module Level (E116) ElementType = Loadport Load Port Reservation State Model (E87) LP: Subsystem Load Port/Carrier Association State Model (E87) LPML: Material Location Supplier Defined State Model(s) The SEMI E87 loadport object shall be modeled as an equipment Subsystem (elementtype = Loadport ) SEMI E87 requires that a loadport have two separate locations: one where the carrier is delivered and removed and another that represents the carrier docked This model presents problems because in many equipment, the two locations are not physically distinct The SEMI E87 specification also indicates that only one carrier can reside in a loadport at a time This implies that there is, for all practical purposes, only one location. While the conflict is recognized, it is beyond the scope of these guidelines to resolve it. Each Loadport Subsystem shall include a StateMachineInstance of a StateMachine that models the SEMI E87 Loadport Transfer, Access Model, Reservation, and Carrier Association state models 9

10 Job Management Subsystem JobManager 1..* 0..* objtypes ProcessJob ControlJob SEMIObjType standardversion objtype statemachineinstance 0..* attributes 1..* StateMachineInstance parameter eventdata 0..* SEMI E40 ProcessJobs and SEMI E94 ControlJobs are used together to control processing in 300 mm equipment ISMI has added the concept of JobManager to hold all instances of both types of jobs This JobManager will be the source for all process management-related elements The equipment metadata shall include a JobManager, modeled as a non-structural Subsystem associated with the Equipment node All SEMI Objects that represent activities (jobs) shall be associated with the JobManager Subsystem 10

11 Processing Modules, Recipes, and Related Events The collection of process data during recipe execution is important in today s semiconductor factories to support process control and fault detection. To interpret trace data collected while substrates are in the chamber, it is important to know when recipe execution starts and ends in each chamber If the recipe has discrete steps, knowing when the execution of individual steps start and end in each chamber is also important The Simple Recipe Execution (SRE) state model is a process chamber (Module)-specific state model that provides a common approach to reporting processing activity on the equipment. Each process chamber (Module) in the equipment shall have a StateMachineInstance that references the SRESM 11

12 Simple Recipe Execution State Model (SRESM) # Current State Trigger New State Action(s) 1 (no state) Equipment initialization Not Executing SREInstanceInitialized event occurs 2 Not Executing 3 No Step Active 4 No Step Active 5 No Step Active Recipe execution affecting this Module has started Recipe execution affecting this Module has completed normally Recipe execution has failed to complete normally Step execution affecting this Module has started 6 Step Active Step execution has completed normally 7 Step Active Step execution has failed to complete normally No Step Active Not Executing Not Executing Step Active No Step Active No Step Active RecipeStarted event occurs RecipeCompleted event occurs; Recipe execution completion status is success RecipeFailed event occurs; Recipe execution completion status is fail StepStarted event occurs StepCompleted event occurs; Step completion status is success StepFailed event occurs; Step completion status is fail 12

13 Required SRESM Event Data SRE Parameter Description Data Type RecipeID SubstrateID LotID SlotID ControlJobID ProcessJobID RecipeParameters Recipe Identifier The identifier (or name) of the recipe component associated with the activity (starting, occurring, or ending) in the Recipe Executing state. Substrate Identifier The SEMI E90 Substrate ObjID attribute value of the substrate processed during recipe execution in the Module as set in the E87 ContentMap during carrier verification. If more than one substrate is processed at the same time, this parameter shall be an array. Lot Identifier The identifier of the lot from which the substrate(s) processed during recipe execution in the Module were taken, as set in the E87 ContentMap during carrier verification. If substrates were taken from more than one lot, this parameter shall be an array. Slot Identifier The slot identifier from which the substrate processed during recipe execution in the Module was taken as set in the E87 ContentMap during carrier verification. If more than one substrate is processed at the same time, this parameter shall be an array. The identifier of the SEMI E94 ControlJob responsible for the recipe execution in the Module. The identifier of the SEMI E40 ProcessJob responsible for the recipe execution in the Module. A structure containing a name/value pair for each recipe parameter and its value used (or to be used) during the associated recipe execution. String String String String String String Structure name:string value:varies 13

14 SRESM Considerations The recipe executed is not necessarily the recipe specified in the ProcessJob. In the case of multi-part recipes, it may instead be a subrecipe (i.e., a chamber recipe ) Individual recipes may include steps A step is a distinct portion of a recipe controlled by separate instructions in the recipe content The SRESM recognizes recipe steps and provides transitions to report their start and end If the equipment chamber recipe contains individual steps that are programmed by or known to the user, the supplier shall implement the modeling of step transitions SRE Parameter Description Data Type RecipeStepName Descriptive short name of the step whose execution is starting or ending. String RecipeStepNumber Number of the step whose execution is starting or ending. Signed Integer 14

15 Compound Recipe Execution The Simple Recipe Execution state model can track only one recipe execution at a time. However, in rare cases, a process chamber may have the capability to process multiple substrates independently, which means multiple simultaneous recipe executions To model this situation properly, each recipe execution must have a separate instance of the state model. There are two possible solutions: Multiple state model instances for a single Module Breakdown of the Module to multiple child Modules one for each possible recipe execution instance This would entail a single parent Module, with separate child Modules 15

16 SEMI E30 state Models SEMI E30, Generic Equipment Model (GEM), forms the basis for the 300 mm standards ISMI does not require representation of all GEM concepts in the metadata; only two state machines are required by some ISMI members: Control State Model The Control state model determines the ability of the equipment client to perform certain operations remotely The equipment metadata shall include a representation of the SEMI E30 Control state model associated with the Equipment node Processing State Model The Processing State Model is an Equipment-level state model. The equipment metadata should include a representation of the SEMI E30 Processing state model associated with the Equipment node 16

17 Relating SECS-II Data to EDA ISMI and its member companies expect that EDA data are a superset of the existing set of data available through SECS Data that can be collected today by the equipment s SECS interface shall be made available for collection by EDA Nearly all SECS data items will be expected to map directly to EDA Parameters (or other elements) Where SECS data items do not map directly to EDA data items, the implementer shall document which items do not match and explain why a mapping is not possible Existing SECS data shall not be changed to match or otherwise accommodate EDA data SECS data is defined in addition to new EDA data 17

18 SECS-II Mapping Convention SECS II EDA Description Field Alarm (ALIDs) Exception [ALID:xxxx] where xxxx is the value of the SECS ALID Events CEIDs) Status Values (SVs) Data Values (DVVALs) Equipment Constant Values (ECVs) Events Data Parameters (istransient = False) EDA Data Parameters (istransient = True) Control or Configuration Parameters (istransient = False) [CEID:xxxx] where xxxx is the value of the SECS CEID [SVID:xxxx] where xxxx is the value of the SECS SVID [DVID:xxxx] where xxxx is the value of the SECS DVID [ECID:xxxx] where xxxx is the value of the SECS ECID Example: SECS-II ALARM (ALID = ) EDA EXCEPTION (Name = Power Failure Description = [ALID: ] Power Failure caused by out-of-limit condition) 18

19 SEMI E116 Equipment Performance Tracking Standard SEMI E116 is not universally required by ISMI members However, consistency is a goal wherever SEMI E116 is implemented Each EPTTracker Subsystem instance shall be a child node of the SEMI E120 structural node that it represents No EPTTracker Subsystem shall exist that does not correspond directly to a structural component of the equipment 19

20 Conclusion Modeling equipment functionality using EDA constructs is important Modeling is an art that requires the supplier to organize the information in a manner that is easy to understand and use ISMI is working with its members and continues to provide guidance and examples of standardized data constructs to help suppliers on their EDA metadata instances 20