semi合集-English.pdf - 第1750页

SEMI E42-0704 © SEMI 1995, 2004 19 3.2.3.3 Version — A recipe may evolve over time and exist in several versions. This allows the user to retain a recipe name over multiple version s and show the recipe's heritage. …

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 18
Figure 3.3
Wire-Bonder Recipe Classes
The text form of a recipe class shall conform to the convention for text (Section 1.5.1). Within the text form of a
recipe identifier, a class is delimited on both ends by the forward slash character "/". The complete class
specification within recipe identifier is formed by the concatenation of classes and subclasses, starting with the
primary class and ending with the particular class of the recipe in question:
“/PRIMARY CLASS/SUBCLASS
1
/SUBCLASS
2
/…”.
For example, a recipe named DryOx, version 4, within the NORMAL CYCLE class in Figure 3.4., has an identifier
of
“/PROCESS/FURNACE/DIFFUSION/NORMAL CYCLE/DryOx;4”.
Figure 3.4
Recipe Classes for Furnace
The complete class specification, which always starts with the primary class, shall always be accepted. If class
names within a namespace are all unique, however, the service provider may also accept a class designator
consisting of a single class. The identifier in the example above then becomes
“/NORMAL CYCLE/DryOx;4”.
SEMI E42-0704 © SEMI 1995, 2004 19
3.2.3.3 Version — A recipe may evolve over time and
exist in several versions. This allows the user to retain a
recipe name over multiple versions and show the
recipe's heritage. Different versions are identified by
the version portion of the recipe's identifier. NOTE:
More than one version of a recipe may be in use for
production at the same time, not only within the
factory, but also within a single equipment.
A version is a text string consisting of at least one
character. A new version is either generated
automatically by the recipe namespace or is assigned
by the user. A user may assign any combination of text
characters and punctuation marks to the version, except
for:
• the characters prohibited by the convention for text
usage and the object identifier (Section 1.5.1),
• whitespace characters.
It is recommended, but not required, that only upper
case be used.
Numeric versions (version numbers) consist only of
the digits "0" through "9" and one decimal point
character "." and can be translated to a pure number. To
avoid confusion and multiple versions with the same
numeric value, numeric versions are further restricted
as follows:
• whole numbers (with no decimal point) may not
start with a zero "0" followed by another digit, and
• decimal numbers (with a decimal point) may not
start or end with the decimal point or end with a
zero following the decimal point.
For example, version numbers "09", "1.", ".5", and
"1.670" are prohibited. The proper forms with the same
numeric values are "9", "1", "0.5", and "1.67". The user
may assign a version of "0" but not of "00".
Versions that are assigned automatically have additional
restrictions:
• They shall be numeric versions, excluding the
decimal point and with a minimum value of "1".
• Versions shall be assigned incrementally. When
assigning a version for a recipe with a given class
and name, if no other recipe exists within the
namespace with that class and name, then a version
of "1" is assigned. Otherwise, the highest existing
version already in use for that class and name is
determined, and the new version is assigned a
value equal to that value plus 1. For example, if the
highest version in use has a numeric value of 5,
then the next version assigned would be "6". To
compare two versions, they are converted to
upper-case and compared character by character.
3.2.3.4 Recipe Identifiers — The recipe identifier is
formed from the concatenation of the recipe's class,
name, and version, in that order:
“/CLASS
1
/CLASS
2
/…/CLASS
n
/NAME;VERSION”
where CLASS
1
is a primary class and CLASS
i+1
is a
subclass of CLASS
i
. The recipe name follows class.
Name and version are always separated by a semicolon
";" (3B
16
).
Where CLASS
n
is a unique class name, the form
becomes
“/CLASS/NAME;VERSION”.
The recipe identifier is used for the OSS-required
attribute ObjID
and shall conform to restrictions
imposed on ObjID
(see SEMI E39). The total length of
ObjID
may have additional restrictions imposed by the
protocol.
NOTE: There is no necessary relationship between a
recipe's identifier or name and any file name(s) under
which the body and attributes may be stored internally.
The recipe identifier is a logical reference to the recipe
that is independent of specific platforms and
implementations. In particular, file services provided by
operating systems may have naming restrictions, such
as length, that are incompatible with the requirements
of RMS. A recipe may be stored internally in different
ways, such as in a single flat file, a set of related files,
or a database. Actual storage methods shall be invisible
to RMS.
Where suppliers supporting recipes in source form also
rewrite them, as discussed in Section 3.2.2.1.2, a
method based on the recipe identifier (ObjID
) is
required to both distinguish between the two forms and
to recognize the relationship between the original
source form recipe and the derived object form recipe.
The method may use any of the three elements of the
identifier for this purpose. For example, recipes in
object form may be placed in a separate subclass called
"/OBJ/", or a suffix such as ".obj" might be appended to
the user-defined name of the original recipe.
3.2.3.4.1 Default Recipe Identifiers — It is always
possible to reference a recipe by specifying its full
identifier (class, name, and version number). In certain
cases, described in Section 3.2.4.1.1, it may also be
necessary to specify the namespace of a recipe.
However, it is not always necessary to specify all
components of the identifier. Specifically, class and/or
version may be omitted when a recipe is selected for
execution and within an external reference. Namespace
is not normally specified. Rules define default values
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: