semi合集-English.pdf - 第1749页

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 th e text form of a recipe identifier , a class is…

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

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

/SUBCLASS

/…”.

For example, a recipe named DryOx, version 4, within the NORMAL CYCLE class in Figure 3.4., has an identifier

“/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

/CLASS

/…/CLASS

/NAME;VERSION”

where CLASS

is a primary class and CLASS

i+1

is a

subclass of CLASS

. The recipe name follows class.

Name and version are always separated by a semicolon

";" (3B

Where CLASS

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