semi合集-English.pdf - 第1751页

SEMI E42-0704 © SEMI 1995, 2004 20 for namespace and class , and there are rules for determining the appropriate v ersion . The recipe name must always be specified. For external references within a recipe, the default c…

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

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.