semi合集-English.pdf - 第3590页
SEMI E139-0705 © SEMI 2005 14 Va r i a b l e Pa r a m e te r Va r i a b l e Pa r a m e te r PD E PD E PD E Pa r a m e te r PD E Pa r a m e te r P r o ces s M o dule PD E “ M ast er” PD E C oordina te s Ta rge te d For PD…
SEMI E139-0705 © SEMI 2005 13
7.12.2.4.3 Any PDE reference that contains a gid can be satisfied with any member of that group. When a PDE is
changed, it can keep the same gid, even as the uid changes. Therefore, the PDEs that reference the original PDE do
not need to change. This solves the problem of cascading references.
7.12.2.4.4 Use of gids as PDE references does add a burden, however. At some point, the gid must be resolved.
7.12.2.5 Resolving PDE References
7.12.2.5.1 ¶7.12.1.5.1 discussed the fact that PDE references can be either uids or gids. When gids are used as
references, they must be resolved to uids before the referenced PDE can be executed. Resolution must occur one
level at a time beginning with the Master PDE. Only when the specific PDE(s) referenced by the current level are
known can one know the references these PDEs make to the next lower level.
7.12.2.5.2 Resolution of a gid to a uid can be performed by either the equipment or the client of the equipment. If
configured to do so, the equipment will resolve any gids that the client does not. If the equipment is required to
resolve a gid, it will choose the member of that group currently at the equipment that has the newest createDate.
7.12.2.5.3 The client can specify gid resolutions for a specific processing job through a predefined Variable
Parameter as input to the job. In this “PDEmap” parameter, the client provides a list of gids with the corresponding
uid for each. The equipment will then preferentially use the entries in this list as it resolves the recipe. If during the
resolution process the equipment encounters any gids that are not on the PDEmap, then it will attempt to resolve the
gid as mentioned above. If the client does not supply a PDEmap, the equipment will resolve all
gids it encounters.
Allowing the equipment to select the final PDEs without supervision is not advised.
7.12.2.5.4 The client can interact with the equipment to determine the best PDEmap values. Using the
resolvePDE() service, the client can supply a PDE and receive the corresponding (fully resolved) “outputMap” from
the equipment. The outputMap contains a list of the gid – uid pairs that result from the resolution process – the
equivalent of a PDEmap. If desired, the client can supply an “inputMap” listing some gid – uid pairs and the
equipment will use these preferentially as it resolves the outputMap. See the scenarios defined in Related
Information 1 for examples of this interaction.
7.12.3 Parameterization
7.12.3.1 Parameterization of process jobs is an important concept for process control. There are other SEMI
standards that define how parameters can be passed to the equipment to affect processing (for example, see SEMI
E40 and SEMI E30). RaP supports the definition of those parameters. Figure 6 illustrates the flow of parameters in
a RaP recipe.
SEMI E139-0705 © SEMI 2005 14
Variable
Parameter
Variable
Parameter
PDE
PDE
PDE
Parameter
PDE
Parameter
Process
Module
PDE
“Master”
PDE
Coordinates
Targeted For
PDE
Parameter
Module
Parameter
Input For
Input For
Input For
PDE
Parameter
Variable
Parameter
Variable
Parameter
Process
Job
Executes
Input For
Variable
Parameter
S
et
s
S
et
s
S
et
s
Variable
Parameter
Variable
Parameter
PDE
PDE
PDE
Parameter
PDE
Parameter
Process
Module
PDE
“Master”
PDE
Coordinates
Targeted For
PDE
Parameter
Module
Parameter
Input For
Input For
Input For
PDE
Parameter
Variable
Parameter
Variable
Parameter
Process
Job
Executes
Input For
Variable
Parameter
S
et
s
S
et
s
S
et
s
S
et
s
S
et
s
Figure 6
Parameter Flow Illustration
7.12.3.2 RaP assumes that recipes are executed as part of a larger job specification. When the “Process Job” is to
be executed, settings can be passed to the job to complete its specification. In RaP, these settings are called Variable
Parameters. Figure 6 shows Variable Parameters passed to the Process Job.
7.12.3.3 The Process Job references the Master PDE as the process recipe. During execution of the Process Job,
the equipment passes Variable Parameter values to the Master PDE to satisfy its PDEparameters.
7.12.3.4 The Master PDE and each successive level of PDEs coordinate the activity of the PDEs at the next lower
level. Each PDE is responsible for passing values to its referenced PDEs to satisfy their PDEparameters.
7.12.3.5 Each PDE can also directly set “Module Parameters”, the settings that affect the Process Module (or other
equipment components). Each Process Module offers a fixed set of these input parameters that can be set from
within a recipe. Note that Module Parameters are not formally defined by RaP. They are used to represent internal
equipment settings that recipes need to manipulate.
7.12.3.6 For a particular PDE, an incoming PDEparameter value may affect an outgoing setting of another PDEs
PDEparameter or of a Module Parameter. This affect may be direct, where the incoming value is used as the
outgoing value, or it may be indirect, where some sort of transformation is done to the incoming setting to determine
the outgoing values. An example of an indirect affect is a time setting that is consumed within the PDE and is used
to determine when a particular Module Parameter is to be set.
7.12.3.7 Notice that a PDE can set Module Parameters to different values during processing according to need. For
example, a process chamber might have a “ChamberTemperatureSetpoint” Module Parameter. A PDE might
require that the value for this be 450°C for the first stage of the process and 500°C for the second stage. The PDE
could set these values directly at the proper time. However, an alternative would be to define two PDEparameters
for this purpose: FirstStageTemp and SecondStageTemp. Each would map to ChamberTemperatureSetpoint and
their default values could be set to the corresponding values. Then, when the appropriate first stage temperature is
determined to be 430°C, the change can be made through a parameter setting at runtime without changing the PDE.
In this way, multiple PDEparameters might map to the same Module Parameter.
SEMI E139-0705 © SEMI 2005 15
7.12.4 TransferContainer
7.12.4.1 ¶7.10 mentions the transfer of PDEs. RaP provides for the definition of a process activity to span multiple,
inter-related PDEs. To promote efficiency of messaging and organization of these PDEs, RaP defines the
TransferContainer. A TransferContainer bundles together multiple PDEs for transfer.
7.12.4.2 A TransferContainer contains PDEs, PDEbodies, and a Manifest. It is convenient to conceptualize the
TransferContainer as an archive file (for instance, a compressed “zip” file for efficient transfer) and the PDE and
PDEbodies as files contained within.
7.12.4.3 There is no requirement that the PDEs contained in a TransferContainer be related in any way. Nor is
there any requirement that all PDEs required for a particular equipment activity to be transferred together.
However, RaP does insist that an external PDEbody always be accompanied by its PDE (and thus, its PDEheader).
7.12.4.4 The Manifest lists which PDEs are included in the TransferContainer and associates each PDE with its
external PDEbody (if one exists). The Manifest can also specify a storage location on the equipment for each recipe
(for example a directory).
7.12.4.5 More detail is provided in ¶8.4.2.13.
7.13 Realizing the Purpose
7.13.1 The purpose of RaP was discussed in §1. In that section, six primary elements of the purpose were provided.
This section will review these six elements and show how each is satisfied by the concepts defined in §7.
On-tool & Off-tool Recipe Management — RaP provides the ability to uniquely identify each PDE. This is
done independently of the versioning systems that may be used by the host or equipment recipe managers. On-
tool management information is embedded in the PDE header (version, antecedent, etc.), but the host may
choose to ignore this information and follow its own management procedures. Few requirements are placed on
the host or equipment with regard to how management of PDEs is to be done.
Recipe Integrity — To guarantee integrity of the recipes, it must be possible to uniquely identify each PDE and
recognize that any change makes it a different PDE. The unique identification requirement is satisfied by the
definition of a unique identifier (uid) containing a uuid value and by the requirement to change the uid with any
change to the PDE. Checksums provide added certainty that no change was made.
Process Integrity — RaP addresses this requirement by making all Module Parameters available for setting by a
PDE, either directly or as input parameters to be supplied at execution time. RaP cannot guarantee that all
possible parameters have been made available to the PDEs. This is left to the supplier and user communities to
ensure.
Adjustable Parameter Definition — RaP provides a flexible system for defining parameters for process jobs in a
way that is compatible with SEMI standards (for example SEMI E40). See ¶7.12.3.
On-tool & Off-tool Recipe Creation & Editing — RaP requires that recipe creation and editing capability exist.
It defines the interfaces necessary to standardize communication with an off-tool editor. RaP does not require
an off-tool editor.
Information Accessibility — The PDEheader contains a large amount of user-accessible information about
individual PDEs and how they relate to one another.
8 Requirements
8.1 Requirements Overview
8.1.1 This section contains all of the requirements specified by RaP. This is divided into three parts.
The first is the Recipe Object Model, which describes the data content of the recipe components.
The second part is RaP Services, which defines the communications between participants in recipe
management.
The third part is RaPnode Requirements and Clarifications, which defines the responsibilities of each recipe
management participant.