semi合集-English.pdf - 第1858页

SEMI E42.1-0704 © SEMI 1996, 2004 6 followed by the attribute v alue, which may be a single item, a list of single items, or a list of complex items, such as variable param eters. If a list, t he keyword LIST prece des t…

SEMI E42.1-0704 © SEMI 1996, 2004 5

RELATED INFORMATION 1

NOTE: This related information is not an official part of SEMI E42.1 and is not intended to modify or supercede the

official standard. Publication was authorized by full letter ballot procedures. Determination of the suitability of the

material is solely the responsibility of the user.

R1-1 RMS-Compliant Equipment with a Stream 7 Host

Semiconductor manufacturers with legacy systems, capable of communicating using Stream 7 messages only, may

still take advantage of many of the Recipe Management concepts when used with equipment that is Recipe

Management-compliant. This section contains guidelines and examples for maintaining recipe attributes within the

body of a Stream 7 process program.

R1-1.1 Recipe Identifier — Both the process program identifier PPID and the object identifier, including the recipe

identifier, have a maximum length of 80 characters. Recipe class, name, and version number may be encoded into

the data item PPID using the format required for the recipe identifier.

“/CLASS

/CLASS

/.../CLASS

/NAME;VERSION”

It is recommended that recipe class names be unique, allowing use of the form

“/CLASS/NAME;VERSION”

to ensure the length conforms to the maximum allowed in SECS-II.

R1-1.2 Recipe Sections — All sections of the recipe are transferred together as the data item PPBODY. This allows

all non-default values of recipe attributes to be preserved when a recipe is uploaded to the host and later downloaded

back to equipment.

There are two potential methods for formatting PPBODY. If the recipe body is a text file, it is recommended that all

attribute values are translated into text, including numeric and boolean values, with boolean values represented by

the strings “.T.” or “.F.”. The second recommended method, applicable to both source and object forms, uses the

structure of one of the SECS-II messages containing the managed recipe, as illustrated in Figure 1, or of an

execution recipe. A cluster tool supporting shared namespaces, for example, might require multiple agent-specific

data sets, while single-process equipment types would not.

R1-1.2.1 Structuring PPBODY Using Text — For purposes of transfer, recipes are regarded as composed of

sections: The generic section, the body section, and zero or more agent-specific data-set sections (RMS, Section

12.1). This convention should also be maintained within PPBODY. The SECS-II messages used to transfer recipes

(Stream 15, Functions 15 and 18) transfer the data-set sections last, because they are variable in number and are not

always present. However, in a text format within PPBODY, it is generally easier to put all attributes before the body.

Since RMS uses the end-of-line character for source form recipes, this convention is recommended to separate the

logical components of the sections containing attributes as well. A few reserved keywords are sufficient as tags to

identify significant components: SECTION, ATTRIBUTE, LIST, PARAMNAME, PARAMSETTING, and

PARAMRULE are recommended for consistency. Keywords are in uppercase for visual impact and are not

delimited except for use of whitespace and the line-feed character (0A

) used as the end-of-line (eol) character.

Whitespace is used to separate fields within a line. The symbol  is used here to represent whitespace, which is used

both as a delimiter to separate fields within a line and also for optional visual effect.

Each section begins with a section declaration of the form

SECTION”text”(eol)

where text is a section name, one of “Generic”, “ASDS”, “Body”. Two sections are separated with two eol

characters together. The eol convention within the body section, however, must conform to the recipe language

specifications provided by the equipment manufacturer.

Each attribute begins with

ATTRIBUTEAttributeName

SEMI E42.1-0704 © SEMI 1996, 2004 6

followed by the attribute value, which may be a single item, a list of single items, or a list of complex items, such as

variable parameters. If a list, the keyword LIST precedes the values, each item in the list terminated with either a

comma or, for the last item, the eol character.

This becomes

ATTRIBUTEAttributeName “text”(eol) (single-value attributes)

ATTRIBUTEAttributeNameLIST“text”, “text”,...(eol)

for attributes consisting of lists of single items (e.g., LinkList or ExtRef).

If the keyword LIST if followed by eol, this indicates a list of complex items. The eol character, in this case, also is

used to terminate the individual items in the high-order list. An attribute consisting of a list of complex items should

identify the individual fields of each complex item. Those attributes containing variable parameters (e.g.,

Parameters) are of the form

ATTRIBUTEAttributeNameLIST(eol)

PARAMNAME“text”, PARAMSETTING“text”, PARAMRULE“text”(eol)

...

PARAMNAME“text”, PARAMSETTING“text”, PARAMRULE“text”(eol)

Each individual field within a complex attribute value is delimited with the quotation mark (“) character. The eol

character is used to terminate a section declaration, an attribute declaration, and a complex item within an attribute.

The recipe body is preceded with

SECTION “Body”(eol)

followed by the recipe body in the form normally used by the equipment.

In comparison of the two suggested formats, the advantage of the text form described in this section is that the

attributes are human-readable and printable and therefore the user is able to modify those attributes that are not

designated as read-only with a standard text editor.

The advantage of the SECS-II form (Figure 1) is that the equipment is more easily able to support a host that is only

capable of using Stream 7.

R1-2 RMS-Compliant Recipe Management with Stream 7 Equipment

For RMS-Compliant Recipe Management applications dealing with legacy Stream 7 equipment, the situation is

more restricted. While an RMS-compliant equipment may preserve attributes by bundling them inside the PPBODY

of a process program, this option is not available when the situation is reversed because the equipment determines

the permissible format(s) within the recipe. Therefore, all attributes of the recipe must be completely maintained by

the host. The host in this situation may provide a recipe namespace that is dedicated either to an individual

equipment installation, to a group of equipment capable of sharing the same process programs, or both.

If the equipment is compliant to Process Program Management as defined in SEMI E30 (GEM), then it will provide

a collection event when the process program is created, changed, or deleted. Hosts that provide a dedicated recipe

namespace for non-RMS equipment are able to use this event to trigger a process program upload and update the

corresponding recipe.

Most Stream 7 equipment use only a single type of process program. This defaults to the recipe class PROCESS.

The equipment is unaware of the internal fields used by the recipe identifier. If it preserves the contents of PPID and

does not impose its own restrictions, it may be desirable to use the format of the recipe identifier, in particular the

version component. This would allow version control at the host.

SEMI E42.1-0704 © SEMI 1996, 2004 7

Some equipment maintains more than one type of process program and may distinguish between the different types

either through providing additional Stream 7 messages, through naming conventions such as a “.ext” extension,

through program length, or other devices.

Downloading a process program in Stream 7 is equivalent to both the operation of “sending” a recipe to a different

namespace (at the equipment) and to downloading a recipe to the recipe executor for execution.

R1-2.1 Structuring PPBODY Using SECS-II Message Format — The second method of sending attributes within

PPBODY is to use a SECS-II message structure that is used to send and receive recipes. Figure 1 illustrates using

the structure of a managed recipe form S15,F13 and F16.

Note that cluster tools may provide full recipe namespace capabilities for its modules, including shared namespaces

for modules of a specific type. In this case, a cluster recipe may contain multiple agent-specific datasets (m > 1).

Other equipment may be able to use the structure for the execution recipe.

L,q (q = 1,2,3)

1. L,r (r = 0 or 2)

1. <RCPSECNM>

2. L,g (g = # generic attributes)

1. L,2

1. <RCPATTRID

2. <RCPATTRDATA

a. L,2

1. <RCPATTRID

2. <RCPATTRDATA

2. <RCPBODY>

3. L,m (m = # agent-specific datasets)

1. L,2

1. <RCPSECNM

2. L,b

1. L,2

1. <RCPATTRID

2. <RCPATTRDATA

b. L,2

1. <RCPATTRID

2. <RCPATTRDATA

m. L,2

1. <RCPSECNM

2. L,c

1. L,2

1. <RCPATTRID

2. <RCPATTRDATA

c. L,2

1. <RCPATTRID

2. <RCPATTRDATA

Figure 1

SECS-II Format for PPBODY