semi合集-English.pdf - 第1748页

SEMI E42-0704 © SEMI 1995, 2004 17 performance by reducing t he demand f or recipe checking by the recipe execut or . The final responsibility for determining th e correctness of a recipe shall belong to t he recipe exec…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 16
Because the managed recipe may be applied to multiple
agents, it may have multiple agent-specific datasets.
When a recipe is downloaded from a recipe namespace
to a recipe executor, the managed recipe is transformed
into an execution recipe by taking the agent-specific
attributes of the agent-specific dataset for that agent (its
recipe executor) and merging them into the attributes of
the execution recipe.
Methods of storing a recipe or the components of a
recipe are not dictated by RMS. However, the
association between a recipe's body and its attributes
shall be carefully maintained.
3.2.2.1 Recipe Body — The recipe body contains the
reusable instructions, settings, parameters, and other
data that the recipe executor reads to execute the recipe
and control its operation.
A recipe body may be in one of two basic forms:
source (text) or object. The purpose of the source form
is to encourage the use of human-readable and human-
editable text. The object form supports the types
intended only to be read and applied by machines and
other automated systems, such as those produced by
vision systems or CAD programs, as well as proprietary
formats created and used by the recipe executor.
3.2.2.1.1 Source Form — Recipes that are created and
modified by a form of editor should be available in
source form. The source form of a recipe body is
equivalent to a text file, such as ASCII or JIS-8, that
can be created, read, printed, or modified with any
"standard" text editor
5
. The executing agent is not
required to supply such a text editor, but its recipe
executor should be able both to read and write recipes
in source form. Editing is not covered by RMS.
The source form of a recipe may be copied from one
namespace to another namespace and from a
namespace to a recipe executor's recipe execution
storage, and all recipe executors with access to a given
namespace are assumed to use the same recipe
language and the same functionality.
Two restrictions are placed on the interpretation of the
text transferred between agents:
• In ASCII, the valid characters are from space
(20
16
) through "~" (7D
16
), plus the tab (09
16
),
linefeed (0A
16
), carriage return (0D
16
), and form
feed (0C
16
) characters. The space and tab are
5 The intent is not to specify the text editor, but rather to allow a user
to modify text on the basis of clear guidelines and restrictions that
may apply. Source form recipes are highly desirable to reduce the
proliferation of, and need for, proprietary editors that are dedicated
and language-specific.
considered as horizontal whitespace characters,
and the carriage return and form feed characters
are considered vertical whitespace characters. The
line-feed character is used to define the end of a
line of text (eol).
• The meaning of a recipe should not depend on
embedded control characters, or specific
whitespace characters, or the existence of
whitespace at the end of a line. Horizontal
whitespace characters should be treated alike for
purposes of interpretation, as should vertical
whitespace characters. All other characters, aside
from those specified here, are discouraged and, if
found, should be removed from the text prior to
transfer.
In general, the recipe language and syntax used within a
recipe body are beyond the scope of recipe
management. However, to reduce arbitrary variability
for the user, the following "rules" are recommended:
• Case is not significant for the purpose of
comparison or meaning but should be retained as
encountered, since it is often used to enhance
readability. For example, the tokens alarmlevel,
ALARMLEVEL, and AlarmLevel should all have
the same meaning.
• Comments may be included in the text and are
ignored in recipe interpretation. Two types of
comments are defined: comments that begin with
the character pair "//" continue to the end of the
line, while comments that begin with the character
pair "/*" are terminated only by the character pair
"*/". A comment of the second type is terminated
by the first character pair "*/" that follows.
Comments may not be nested. Nested comments
are not honored and may generate a syntax error.
• The minimum line consists of a single line-feed
character.
In addition, recipe languages that support external
references to other recipes should use the text form
defined for the recipe identifier (Section 3.2.3.4) and
for the recipe specifier (Section 3.2.4.1.2).
The supplier of the recipe executor shall provide
documentation that formally defines each recipe
language that the agent supports. Two forms are
required, one for the user, who must be able to write
correct recipes, and one that covers both the syntactical
and lexical structures of the language using a formal
descriptive protocol such as the Backus-Naur Form
(BNF). The second form of documentation allows
parsers to be built that are capable of pre-checking a
recipe for syntactic and lexical correctness prior to
downloading it. Pre-checking improves efficiency and
SEMI E42-0704 © SEMI 1995, 2004 17
performance by reducing the demand for recipe
checking by the recipe executor.
The final responsibility for determining the correctness
of a recipe shall belong to the recipe executor.
3.2.2.1.2 Object Form — Recipes that cannot be
translated into a meaningful source form include
datasets derived from vision systems or mechanical
systems through a special hardware-dependent "teach"
operation. Such recipes may remain in a proprietary
object form and may or may not be applicable to other
recipe executors because of their hardware
dependencies.
For greater efficiency, recipe executors may rewrite
(e.g., tokenize) a source recipe to generate a
proprietary object form of the recipe. This is called the
derived object form, to distinguish it from object form
recipes that never exist in source form. The agent's
manufacturer may choose to make this form available
for transfer as well. From the point of view of the
supervisor, the body of a recipe that is in object form is
an unstructured binary vector or string. In general, it
cannot be edited on a supervisor, and the source form
of the recipe is still required. Derived object form
recipes that cannot be used by multiple recipe executors
should not be stored in recipe namespaces that are
shared.
Where both the source form and the derived object form
exist, the identifier for the object form of the recipe
shall be different from that of the source form in some
recognizable way. The supplier of the recipe executor
shall provide a documented method for distinguishing
one from the other within the identifier. This method
must be such that the relationship of the derived object
form recipe from the original source recipe is obvious
to the user. (See Section 3.2.3.4 for examples.) An
attribute of the recipe, SrcRcpID, is provided to retain
the relationship between the source form recipe and the
derived object form recipe.
3.2.3 Recipe Identification — The ability to properly
and unambiguously identify a recipe is critical to both
recipe management and processing. It is also important
for the user that identification be logical. RMS defines
three elements used to uniquely identify a recipe within
any recipe namespace. These three elements are the
recipe's class, name, and version. Each element is
expressed as a text string, and they are concatenated
together to form the recipe identifier (see Section
3.2.3.4).
3.2.3.1 Recipe Name — The recipe name is a user-
defined text string that may be used to encode the
technology, layer, manufacturing area, and other
characteristics. The recipe name alone is not necessarily
unique within either a given class or a given
namespace.
The recipe name is subject to the conventions for text
as defined in Section 1.5.1.
3.2.3.2 Recipe Class — A recipe class is a formal
grouping of recipes that have a common syntax. A class
may contain subclasses where the recipes within the
subclasses operate in different environments or have
different syntaxes from the parent class and/or from one
another. A subclass is itself a class and may contain
further subclasses.
The overall model for recipes is a set of class
hierarchies or "class trees" defined by the supplier of
the recipe executor. The major classes of recipes are the
PROCESS class, the SERVICE class, and possibly
other agent-specific classes. These are called primary
classes. A primary class is a class that is not a subclass
of another class.
The PROCESS class is a required primary class and is
composed of recipes whose primary purpose is to
increase the manufactured value of the production
material
6
.
The SERVICE class is an optional primary class used
for recipes whose purpose is to maintain, prepare,
calibrate, or test the operation of equipment. Typical
subclasses of the SERVICE class might be
CALIBRATION and CLEANING. SERVICE recipes
that use the same recipe language as normal process
recipes are not required to be placed into a separate
primary class. The SERVICE class allows separation
and use of a different syntax for special non-process
purposes.
Other primary classes that do not fit the PROCESS or
SERVICE may be provided by the supplier of the
recipe executor. Such additional classes, and their
function, shall be documented.
Recipes that are not in the PROCESS class or one of its
subclasses shall not be used for production purposes.
However, recipes within the PROCESS class may be
used for purposes other than production.
Figures 3.3 and 3.4 show examples of object models of
possible classes and subclasses for a wire-bonder and
for a furnace with an automatic boat-loader subsystem.
6 Material handling systems, wafer metrology, wafer measurement,
wafer inspection systems, as well as process equipment which
directly changes the characteristics of the material, increase the value
of the material in some way.
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”.