semi合集-English.pdf - 第1752页
SEMI E42-0704 © SEMI 1995, 2004 21 “Agent-Name>Namespace-Na me>CLASS/Name;Version”. The required or der of identifiers with in the specifier is: agent, namespace , recipe. 3.2.4.1. 3 Linked Recipe Sets — Where one …
SEMI E42-0704 © SEMI 1995, 2004 20
for namespace and class, and there are rules for
determining the appropriate version.
The recipe name must always be specified.
For external references within a recipe, the default
class is the class of the recipe making the reference.
The proper class is determined when the recipe is
linked (see Section 3.2.4.1.3).
Where a recipe version is unspecified, the recipe of that
class and name having the highest approval level will
be used. Where several recipes are found with the same
approval level, the one with the highest version will be
used. Where the version is unspecified in an external
reference, the correct version is determined when a
linked recipe set is built by the link operation.
For references with managed recipes, if no namespace
is specified, the default is namespace of the referring
recipe.
3.2.4 Advanced Recipe Capabilities
3.2.4.1 Multi-Part Recipes — Use of multi-part recipes
is often dictated by the recipe executor, which may
require a set of recipes of different classes for its
process. In addition, support for multi-part recipes can
be helpful for the user, in particular where recipes are
otherwise long. The recipe language may define use of
subrecipes analogous to that of subroutines in ordinary
programming languages. This enables better re-use
where a high degree of similarity exists between
different recipes.
Where recipes of more than one class are required, it is
convenient to allow one recipe to reference another. A
recipe in the PROCESS class, for example, may refer to
recipes in other classes to ensure that an entire set of
recipes is executed together.
It is also convenient to allow one recipe to reference
other recipes within the same class, where a substantial
set of instructions and/or settings are common to a
variety of other recipes.
A reference within the body of one recipe to a different
recipe is called an external reference. The exact syntax
in which this is done is determined by the recipe
language used. An external reference may also specify
values for variable parameters defined in the
referenced recipe or in one of its subrecipes.
3.2.4.1.1 Subrecipes — When one recipe references
another recipe, both recipes are required for execution.
The starting recipe is called the main recipe.
Subrecipes are those recipes that are referenced by the
main recipe, or by another subrecipe of the main recipe.
A recipe that references other recipes is a parent recipe
to the referenced subrecipes. A parent recipe is not
necessarily a main recipe. A main recipe must not be
referenced by any of its subrecipes.
External references to recipes within the same
namespace may or may not be explicit. That is,
references to the current class (i.e., the class of the
recipe being verified) may be implicit, and versions
may be left to the rules for determining the default
version at link-time.
A recipe may also reference recipes in another
namespace. This occurs either when a recipe is to be
delegated or when a recipe in a namespace accessed by
multiple agents must reference a hardware-dependent
or other agent-specific recipe kept in a default
namespace. The default namespace of a recipe
executor is always referenced within a recipe as the
namespace named "Default". This name is interpreted
by the recipe executor at execution time, based on its
attribute DefaultNamespace
(see Section 6.3).
When specified in a text string within a recipe with the
subrecipe's identifier, the identifier is preceded by the
value of the namespace's identifier, followed by a
greater-than symbol ">". This is called the recipe
specifier. For a recipe ETCH version 5 in a namespace
named "NS-MOM", this would be specified as
“NS-MOM>/PROCESS/ETCH;5”.
According to the rules of OSS, object type may be
omitted when it may be otherwise determined. In RMS,
determination is made according to order.
3.2.4.1.2 Delegated Recipes — A recipe may reference
recipes in another namespace that are to be executed by
a component agent and are termed delegated recipes.
Although referenced by another recipe, delegated
recipes are not considered as subrecipes of the parent
(referencing) recipe as they are to be executed by a
difference agent and are themselves required to be a
main recipe. A reference to a delegated recipe is the
equivalent to an automated "select" and "start"
sequence of commands from the supervisor. As such,
they are generally subject to the constraints of a select
operation.
Delegated recipes may or may not require the name of
the executing agent (recipe executor), depending on the
rules of the particular implementation. For example, a
supervisor may be able to determine the appropriate
executing agent at run-time, based on the namespace
specified. However, the ability to specify a particular
executing agent is important to the user, as process
results may be sensitive to a particular equipment
installation. Therefore, recipe languages that support
delegation shall allow specification of the particular
executing agent to be used. The text format of the full
recipe specifier in this case is:
SEMI E42-0704 © SEMI 1995, 2004 21
“Agent-Name>Namespace-Name>CLASS/Name;Version”.
The required order of identifiers within the specifier is:
agent, namespace, recipe.
3.2.4.1.3 Linked Recipe Sets — Where one recipe
references another, a set of recipes to be executed
together is formed by starting at the main recipe and
collecting the external references to identify all the
members of the set. This set is called a linked recipe
set, and the operation of collecting the references is the
link operation.
3.2.4.2 Variable Parameters — Variable parameters
are variables that can be assigned values from outside
the recipe itself. Variable parameters allow recipes to
use variables rather than constants for such actions as
setting temperature setpoints, time delay intervals, and
data-set names. This capability greatly extends the re-
usability of a recipe.
A parameter first is formally defined within a recipe
body and given a unique parameter name, a
parameter initial value (default value) for use when
the recipe is selected for execution, unless overridden.
Where applicable, the definition also includes a
parameter restriction that represents one or more
conditions that any value assigned to that parameter is
required to satisfy to be valid.
The syntax for parameter definitions in recipe bodies
remains unspecified, so long as it conforms to the
syntax of the recipe language and contains the required
elements. Other restrictions concerning the use of
variable parameters may be imposed by the recipe
executor's supplier through the specification of the
recipe language.
The parameter domain is the set of all possible values
of a given form (see Section 1.4.3) that fulfill the
conditions of the parameter restriction (if any).
The form need not be included in the parameter
definition declared within the recipe body, but rather
may be derived by the recipe executor during the
verification process from the way in which the
parameter is applied within the recipe. If temperature is
maintained internally as an unsigned integer, for
example, those parameters that are used in the recipe to
assign temperature setpoints and ranges would typically
be required by the supplier of the executing agent to
represent unsigned integers as well. The supplier shall
document the forms and valid domains for each of the
parameters that may be used as a variable parameter.
NOTE: The parameter's value may be changed from
its initial (default) value within the text of a recipe, and
it may also be set as an "argument" passed to a
subrecipe. These capabilities are a function of the
recipe language and are beyond the scope of RMS.
Two categories of parameters are defined: numeric
and non-numeric.
3.2.4.2.1 Numeric Parameters — Numeric parameters
include all parameters that can take on any numeric
value for its format type between a parameter low
limit and parameter high limit.
The parameter restriction for a numeric parameter in
any of the attributes that store parameter definitions
shall be a text string that conforms to one of the
following:
• "(a,b)
UNITS" the domain of numbers x such that
a<x<b
• "(a, )
UNITS" the domain of numbers x such that
a<x<+∞
• "( ,b)
UNITS" the domain of numbers x such that
-∞<x<b
• "UNITS" the domain of numbers x such that
-∞<x<+∞.
where:
1. a and b are numeric values formed from the digits
"0" through "9", the plus and minus signs "+" and
"-", the period ".", and the letters "E" or "e" for
floating point numbers,
2. represents optional whitespace, and
3. UNITS is a valid case-sensitive
string conforming to
the Units of Measure Identifiers (see SEMI E5,
Section 9).
For example, both of the following strings are valid:
"(500,2000)degC" and "(0,100)".
To include equality, parentheses are replaced by the
square brace "[" and/or "]" on the left or right end,
respectively. For example, "[a,b)" represents the
domain of numbers x such that a≤x<b.
To specify units only, with no restriction on range, the
low limit may be set to -∞ and the high limit to +∞.
However, the low and high limit shall not exceed
absolute minimum and maximum limits set for that
parameter by the recipe executor's supplier.
Numeric parameters with no parameter restriction are
pure numbers (with no units) with a domain of (-∞,∞).
A numeric parameter shall have a format type of one of
the following:
• text string of a length of no more than 80
characters,
• signed or unsigned integer of an even length,
• floating point number of an even length.
SEMI E42-0704 © SEMI 1995, 2004 22
Text strings are restricted to the character set defined
above to represent the low and high limits of the domain
and shall convert to a numeric value within that
domain.
3.2.4.2.2 Non-Numeric Parameters — A non-numeric
parameter is any parameter other than a numeric
parameter, including parameters whose domains are
sets of discrete numbers that cannot be represented by a
single mathematical interval, and strings that represent
names. Non-numeric values may or may not place
restrictions on the replacement value. A parameter that
contains the name of a wafer map, for example, cannot
be easily restricted by a general rule
7
, whereas a
parameter that contains a string identifying
thermocouple type can be restricted to one of a defined,
unordered set of valid strings. Restrictions for non-
numeric parameters might also consist of, or include,
logical expressions that shall evaluate to TRUE before a
value may be used.
If a recipe language has been defined for the
corresponding class of recipes, the syntax for the
restriction is taken directly from the formal definition
of that parameter within the body of a source form
recipe (and therefore conforms to the specification for
that recipe language). Otherwise, the restriction is
expressed in a syntax defined by the recipe executor's
supplier specifically for parameter attributes.
For example, the parameter for a furnace recipe may
specify which set of PID values should be used, where
sets A-F exist on the equipment. The automatic
restriction on the value for such a parameter, as
specified by the recipe executor's supplier, might be
"{A,B,C,D,E,F}" with the default for the value
specified as the character "C" with a format type of
"ASCII string of length 1".
In another example, a restriction might be that the value
be taken from the enumerated set
“{cassette, lot , batch }”.
3.2.4.2.3 Agent-Specific Parameters — In order to
"tune" a recipe so that it produces the same result on all
recipe executors of the same type, it may be necessary
to provide a different initial value for the parameter or
a different parameter restriction for individual
executing agents. A special editing facility may be
provided by the recipe manager to allow the original
value and/or restriction of a parameter to be modified
for a specific executing agent.
7 Typically, the validity of parameters which are unrestricted names
can only be established at run-time.
NOTE: Agent-specific parameter definitions replace
the corresponding original definitions in the recipe that
is downloaded to the recipe executor. At run-time, they
are superseded by parameter values specified for the
recipe executor's select operation.
3.2.5 Attributes — The name of an attribute is a text
string required to be unique for its object. The names of
the attributes defined in this document are reserved for
their standard use.
Identification attributes are those used to identify the
object in OSS. These attributes are available through
OSS, but in RMS, services are handled separately from
the other attributes and are not transferred in parameters
for "recipe attributes".
Attributes other than identification attributes and
mandatory attributes discussed below always have a
defined default value. Attributes with a default value
not otherwise specified are considered to have a null
value corresponding to their form as their default value.
The null value for a text string is a zero-length string.
The null value for a numeric form is zero. The null
value for a boolean form is FALSE. The null value for
an empty list or structure is an empty (zero-length) list.
The manner of representing null values is left to the
protocol.
An attribute is cleared or reset by setting its value to
the default value.
Mandatory attributes are attributes that are required to
always have a non-default value.
Certain attributes are required, including all mandatory
attributes. A required attribute is one that shall be
supported with a non-default value. For example, the
BodyFormat
attribute is required. This means that
object form recipes (for which BodyFormat
has a non-
default value) shall be supported by a namespace.
Any attribute defined in this standard shall only be
modified according to the rules specified for that
attribute.
Attributes of the managed recipe and the execution
recipe may be accessed through Object Services.
However, only certain of the attributes may be set
through Object Services.
For purposes of OSS, all attributes defined in RMS
shall be recognized. That is, a response to a GetAttr
service request that references any attribute of an object
defined in RMS for that object shall not return an
"invalid attribute" error. If the attribute is not supported
by the application, then it shall show the value of that
attribute as having the null value appropriate for its
form, and it shall deny attempts to set its value through
the SetAttr service.