semi合集-English.pdf - 第1783页
SEMI E42-0704 © SEMI 1995, 2004 52 recipe is located, then it is called the lin k targ et recipe . 4. Determine the con tents of the Verified attribute of the link target recipe . If Verified is FALSE, the link operation…
SEMI E42-0704 © SEMI 1995, 2004 51
attribute Linked to TRUE. Figure 8.3 illustrates the
LINKAGE state of the recipe. For a description of the
transitions, see Table 8.1 in Section 8.3.
Figure 8.3
Link State Model
For multi-part recipes, this operation also collects
external references and variable parameter definitions
into the LinkList
and LinkParam attributes, to be used
by the recipe executor at run-time.
External references contained within multi-part recipes
are not required to specify the class of the subrecipe
when the class is the same as that of the parent recipe.
Where class is omitted in a recipe identifier in the
ExtRef attribute, the link operation is responsible for
adding the class of the parent recipe in the identifier
added to the LinkList
parameter, as the parent/child
relationship cannot be derived from the final contents of
LinkList
.
External references are assumed to refer to recipes
within the same namespace and are not required to give
explicit versions unless they specify a different
namespace. This ensures that the user will be able to
link together the “best choice” subrecipes. The exact
value of versions of such references is determined only
at the time the main recipe is linked.
The link operation is performed on a main recipe. That
is, it only modifies attributes of the main recipe. It
resolves all external references within that recipe and
within any of its subrecipes according to well-defined
rules for determining default versions at the time of the
link. At the same time, variable parameter definitions
are collected. The resulting explicit references are
placed in the LinkList
attribute, variable parameter
definitions are placed in LinkParam
, the ApprovalLevel
attribute is cleared, the Linked
attribute is set to TRUE,
and the main recipe is then said to be linked.
Subrecipes are not affected by this operation.
Subrecipes of a main recipe have no knowledge of
parents or of linkages. As a result, it is possible to
delete or change a subrecipe with an unintended
detrimental impact on a linked recipe set. Factory
policy may designate certain levels of approval to mean
“this recipe is used by (linked into) one or more
protected recipes.”
For multi-part recipes, linking starts at the main recipe
and works through all chains of referenced subrecipes
to determine the complete set of identifiers that will
comprise the recipe as a whole. The link operation is a
mechanical procedure that may be performed at any
time.
Successful linking implies that all referenced subrecipes
have been located and parsed for further references
until all references are exhausted. The link operation
shall fail when any recipe or subrecipe within the
namespace either is unverified or cannot be located.
If the same parameter name is used to define a
parameter in more than one recipe of a set of recipes
that are linked together, the name shall represent the
same parameter and have the same parameter
definition in all recipes in the set, to avoid ambiguity.
Parameters with the same parameter name and
differing definitions shall cause, at a minimum, a
warning to the user when the link operation completes.
For purposes of comparison of results, the order of
references in LinkList
and LinkParam at the completion
of the link operation shall conform to the results when
the following sequence is used:
1. Copy the contents of ExtRef
from the main recipe to
LinkList
, resolving class and version to each recipe
identifier as needed. For support of variable
parameters, also copy the contents of Parameters to
LinkParam. If ExtRef is empty, then LinkList is also
empty and the parsing process is complete.
2. If LinkList
is not empty, begin with the first
reference in LinkList
as the link target reference.
3. If the link target reference lies within the same
namespace, resolve the class and version if
necessary. (Note: the referenced recipe must be
already present within the namespace at the time the
link is performed, or else the link fails.) If the link
target reference specifies a different namespace, go
to Step (6) — the link operation of this chain
terminates (without error) without an attempt to
locate the actual recipe or its ExtRef
attribute. If the
SEMI E42-0704 © SEMI 1995, 2004 52
recipe is located, then it is called the link target
recipe.
4. Determine the contents of the Verified
attribute of
the link target recipe. If Verified
is FALSE, the link
operation fails immediately.
5. Determine the contents of the ExtRef
attribute of
the link target recipe. Remove any references that
duplicate those already contained in LinkList
,
resolve class and version as needed, and append the
result to LinkList
. If variable parameters are
supported, also determine the contents of
Parameters
in the link target recipe, remove
parameters already defined in LinkParam
, and
append the result to LinkParam
.
6. Set the link target reference to the next reference in
LinkList
and repeat steps (3) through (6) until all
references in LinkList
have been processed.
For recipes with no external references, the LinkList
list will be empty. Similarly, for recipes with no
variable parameters, the LinkParam
list will be empty.
The effect of allowing incomplete recipe versions to be
specified within a recipe body, and determined only
when the main recipe is linked, means that a linked
recipe set (the set of recipes linked together) produced
on one occasion may not be the same as those produced
on a different occasion. Therefore, it is necessary to
protect the contents of the LinkList
attribute from
inadvertent change.
For this reason, the link operation cannot be performed
on a read-only recipe with the Linked
attribute already
set from a previous link. Any attempt to link an already
linked read-only recipe either shall be denied or a new
copy of that recipe shall be generated with a new
identifier, which may then be automatically approved
and linked.
The link recipe operation is invoked with the
RMNAction service.
8.2.3.3 Unlink Recipe — A linked recipe that is not
write-protected may also be unlinked. The unlink
operation clears the generic attributes Linked
,
LinkList
, and LinkParam. If the recipe has agent-
specific datasets, the attributes Certified
and AgentSpec
LinkParam are cleared. If no other non-required agent-
specific attributes have a non-default value, the agent-
specific dataset is removed.
The unlink recipe operation is invoked with the
RMNAction service.
8.2.3.4 Modify Variable Parameters — The recipe
attributes Parameters
, LinkParam, and
AgentSpec
_LinkParam each consist of a list of
parameter definitions. Each parameter definition
contains the parameter name, parameter initial value,
and the parameter restriction (if any) specified for that
parameter by a formal definition within the recipe
body.
In order to “tune” a recipe so that it produces the same
result on all executing agents of the same type, it may
be necessary to provide a different initial value or a
different parameter restriction for one or more
parameters for individual executing agents. The agent-
specific attribute AgentSpec_LinkParam
is used to
provide this capability.
AgentSpec_LinkParam
is an optional agent-specific
attribute that contains a list of alternate parameter
definitions for one or more of the variable parameters
included in the definitions in the generic attribute
LinkParam
of a linked recipe. A special editing facility
may be provided to allow an authorized user to add,
delete, or modify parameter definitions to
AgentSpec_LinkParam.
Parameter definitions initially are added individually to
AgentSpec_LinkParam
by copying the definition for
that parameter from LinkParam
. The initial value or
restriction then may be modified by the user, subject to
the absolute restrictions, such as minima and maxima,
imposed by the executing agent's supplier. The initial
value may be changed to any value within the
parameter domain.
Any modification of the restriction shall cause the
certification level to be cleared in the Certified
attribute. This is required because of the potential
impact on fab operations of a change in the restriction.
The UNITS in the restriction of a numeric parameter
may be modified within constraints imposed by the use
of the parameter and the executing agent's supplier. For
example, a two-byte unsigned integer named WaitTime
that is used to set a variable time delay period may
permit units of either “min” (minutes) or “s” (seconds).
It is desirable, but not required, that suppliers of
executing agents support different options for
specifications of UNITS. The possible options for each
potential variable parameter shall be documented by
the supplier.
SEMI E42-0704 © SEMI 1995, 2004 53
The modify variable parameter operation consists of
adding, deleting, or modifying a specific parameter
definition to a list of definitions in
AgentSpec_LinkParam for a specific agent.
A definition is added when it is copied directly from
the LinkParam
attribute to the AgentSpec_
LinkParam
attribute without modification. A definition
shall only be added if there is currently no definition for
a parameter with the same parameter name in the
AgentSpec_LinkParam attribute.
A definition is deleted when it is completely removed
from the list of definitions in AgentSpec_
LinkParam
.
A definition is modified when the value or restriction
of an existing definition is replaced in
AgentSpec_LinkParam
.
The modify variable parameters operation is invoked
with the RMNVarPar service.
8.2.4 Recipe Authorization — Recipe authorization
operations include those that allow an authorized user
to change the value in the generic attribute Approval-
Level or the agent-specific attribute Certified.
The de-certify operation is invoked with the service
RMNAction.
8.2.4.1 Approve Recipe — Recipe management
provides two different methods of controlling how a
recipe is applied: through the generic attribute
ApprovalLevel
and through the agent-specific attribute
Certified
. The recipe's approval level (the value
contained in ApprovalLevel
) is also used to protect it
from change.
A recipe goes through different stages during its
lifecycle. After a recipe has been initially created, it
will typically go through a dynamic period while it is
tested and adjusted until it produces the desired results.
ApprovalLevel
is an unsigned integer used to designate
the different stages in a recipe's life cycle. It is set to
zero (its default value) whenever a recipe is created,
updated, or linked.
The approval operation allows an authorized user to
set ApprovalLevel
to a non-zero value. Otherwise, it
may not be set externally.
A recipe is said to be approved whenever Approval-
Level is non-zero. An example of a factory's
implementation of approval levels is given in the
appendix, Section 8.3. Figure 8.4 illustrates the recipe's
APPROVAL state. For a description of the transitions,
see Table 8.1 in Section 8.3.
Figure 8.4
Approval State Model
A subrecipe may be approved independently from any
recipes which reference it.
A linked recipe may not be approved to a level higher
than the lowest approval level of any of its subrecipes.
Therefore, all subrecipes referenced in the attribute
LinkList
of a linked recipe must be located prior to
granting an approval level other than zero. The
ApprovalLevel
attribute of the subrecipes must be
increased to a value equal to, or greater than, the
required level by an authorized user before the higher
approval level of the linked recipe is accepted.
The restriction on the approval level of the linked
recipe requires the user to purposefully change the
approval level in order to protect the entire linked
recipe set as a unit from unexpected change, as it is by
the main recipe identifier that the recipe as a whole will
be known. It should be noted that approval of a linked
recipe is not the same as approval of the individual
parts, as a subrecipe which is appropriate in one recipe
may be inappropriate in another.
The approve recipe operation is invoked with the
RMNAction service.
8.2.4.2 Certify — The certify operation sets the value
of Certified
for a specific executing agent to a non-zero
value specified by an authorized user. This operation
affects no other attributes (except the length and
timestamp attributes of the affected agent-specific
dataset).