semi合集-English.pdf - 第3588页

SEMI E139-0705 © SEMI 2005 12 7.12.2 Recipe Structure 7.12.2.1 When a recipe has m ultiple components, RaP docu ments the relationshi ps among these components (see ¶7.12.1.5). This results in a hierarchical recipe struc…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 11
PDE
•Checksum
•PDEbody Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
• uuid
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• …
PDE
•Checksum
•PDEbody Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
• uuid
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• …
Figure 4
PDE With Separate PDEbody
7.12.1.3.2 Tracking of separate PDEbodies requires some care by the FICS, because the identity cannot be obtained
from the PDEbody itself. Thus, a method for maintaining the relationship of the PDE to its body must be employed
by the FICS.
7.12.1.3.3 The Equipment and PDEeditor can interpret the PDEbody contents, and so are able to resolve the
relationship without such careful tracking. The PDEbody must include key information, such as the uid, that
enables the equipment and the PDEeditor to make the association between PDEheader and PDEbody (see ¶8.5.4.5
).
7.12.1.4 Input Parameters
7.12.1.4.1 The PDEbody may also define input parameters that can be set at run-time. The PDEheader documents
these PDEparameters. Parameterization is discussed further in ¶7.12.3.
7.12.1.5 Reference To Other PDEs
7.12.1.5.1 The PDE may need to access other PDEs during execution (for example, a subroutine call). The
PDEheader documents these references. There are two ways to reference a PDE. The first is by a unique identifier
(uid). The uid is a reference to a specific PDE. The second way to reference is by a group identifier (gid). PDEs in
a group can be substituted for one another and so must share the same set of input parameters. This type of
reference is resolved to a specific member of the group before execution. See ¶7.12.2.5 for more on how references
are resolved.
7.12.1.6 Transition To RaP
7.12.1.6.1 The approach for defining the PDE provides a good transition path from traditional proprietary recipes.
Old style recipes can become the PDEbody when RaP is applied. Since the “PDEbody
” can be a separate entity (in
the case of proprietary content), there should be many cases where little or no modification of the original recipes
will be needed. The PDE construct, including the PDEheader, acts as a wrapper.
7.12.1.6.2 There are two areas where RaP requirements may result in changes to an existing recipe structure. The
first area is the requirement that an EquipmentNode be able to match a PDEheader with its external PDEbody. This
would be done best by inserting the uid value into the PDEbody. However, there is a “bodyChecksum” value in the
PDEheader that can be used without changing the PDEbody. This would require recalculating the checksum of the
PDEbody, however. The second area is the requirement that the user be allowed to specify which PDEparameters
exist. The PDEbody must contain information about the user-specified PDEparameters. However, in the case of an
existing recipe with no user-specified PDEparameters, no change is necessary until the user edits the PDE to add
such parameters. For example, the implementer may choose to support the old recipe format for existing recipes,
but convert all new recipes to a new format that includes PDEparameter support.
SEMI E139-0705 © SEMI 2005 12
7.12.2 Recipe Structure
7.12.2.1 When a recipe has multiple components, RaP documents the relationships among these components (see
¶7.12.1.5). This results in a hierarchical recipe structure as illustrated in Figure 5.
7.12.2.2 The recipe hierarchy must have a single PDE at the apex. This PDE is called the “Master PDE”. It is this
PDE that will be referenced when a job is specified. So, for example, in SEMI E40/Processing Management, the
RecID (or RCPSPEC) will contain the uid of the Master PDE. See Related Information §R2-2 for more discussion
of RaP support for SEMI E40 and SEMI E30. As an alternative, a gid may be supplied and later resolved to a uid.
MasterPDE
Referenced
PDE’s
PDE
PDE PDE
PDE PDE PDE
PDE PDE
ProcessJob
{
PDE’s referenced
by
either
UID or GID
RCPSPEC/PPID = UID or GID
VariableParameters
o GIDUID Map
o PDEparam1
o PDEparam2
o etc…
MasterPDE
Referenced
PDE’s
PDE
PDE PDE
PDE PDE PDE
PDE PDE
ProcessJob
PDE
PDE PDE
PDE PDE PDE
PDE PDE
ProcessJob
{
PDE’s referenced
by
either
UID or GID
RCPSPEC/PPID = UID or GID
VariableParameters
o GIDUID Map
o PDEparam1
o PDEparam2
o etc…
Figure 5
Recipe Structure Illustration
7.12.2.3 The recipe structure implies that the Master PDE is the first PDE to be executed. Beyond the Master PDE,
the recipe structure does not document the order of execution of PDEs or the flow path of wafers through
equipment. It is recommended that the equipment supplier provide a PDE that contains this flow information in an
open format (human readable) PDEbody.
7.12.2.3.1 Here are a few other items of note:
The Master PDE is a designation, not a type of PDE. A Master PDE must be marked as “executable” (see
Table 5).
There is no restriction on multiple references to the same PDE.
The number of levels in the recipe hierarchy is not limited. However, it is to be expected that two to three
levels would be sufficient in most cases. In the case where the Master PDE contains the entire recipe, only one
level is needed.
A PDE may appear in the hierarchy of multiple recipes. Such reuse of recipe components is expected and
encouraged.
7.12.2.4 Recipe Maintenance Considerations
7.12.2.4.1 Group IDs (gids) exist to make it easier to maintain multi-part recipes. It is possible to create recipes
where all PDE references are done with uids. However, this can lead to problems when a change is made to one of
the components.
7.12.2.4.2 Remember that when any change is made to a PDE, it must become a new PDE with a new uid. In order
to begin using this “new version” of the old PDE, some (or all) PDEs that referenced the original PDE must now
reference the new one. When the referencing PDEs are changed to refer to the new version, each of them becomes a
new PDE. And these have the same problem with any PDEs that reference them. The problem cascades to every
level above the first PDE.
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.