semi合集-English.pdf - 第1857页
SEMI E42.1-0704 © SEMI 1996, 2004 5 RELATED INFORMATION 1 NOTE: This re lated information i s not an official part of SEMI E42.1 and i s not intended to m odify or superce de the official standard. Publication was author…
SEMI E42.1-0704 © SEMI 1996, 2004 4
Parameter Name SECS-II Data Item
AttachToken OBJTOKEN
RMChgType RMCHGTYPE
RMManagerSpec OBJSPEC
RMPermit RMGRNT
RMRecorderSpec OBJSPEC (S15,F43) and RMRECSPEC otherwise
RMRequestor RMREQUESTOR
RMSegSpec RMSEGSPEC
RMTimestamp TIMESTAMP
TargetSpec TARGETSPEC
6.2 There are also several data items that are used in the SECS-II messages which do not map to specific services
parameters. Services with the same set of parameters are mapped to the same SECS-II message by adding an
additional data item to differentiate between the services. In addition, SECS-II restrictions require multi-block
primary messages to be preceded by a multi-block inquire/grant transaction defined within the same stream. For
RMS messages, this requirement is satisfied with the S15,F1 and F2 messages. Data items defined for these two
messages have no counterpart in RMS service parameters.
6.3 Table 3 contains the SECS-II data items that have no corresponding RMS service parameter:
Table 3 Additional Data Item Requirements Table
Function SECS-II Data Item
Used to satisfy SECS-II conventions for linking a multi-block inquiry with a subsequent multi-
block message.
DATAID
Used for the name of any non-identifier recipe attribute. RCPATTRID
Used for the value of any non-identifier recipe attribute. RCPATTRDATA
Used by S15,F19 to differentiate between RMNCopy and RMNRename services. RCPRENAME
Used to satisfy SECS-II multi-block requirements. RMGRNT
Used by S15,F3 to differentiate between RMNCreateNS and RMNDeleteNS services.
Used by S15,F39 to differentiate between RMDRAddSegRecord and RMDRDelSegRecord.
Used by S15,F41 to differentiate between RMDRAddChgRecord and RMDRDelChgRecord.
RMNSCMD
Used to satisfy SECS-II multi-block requirements. Neither required nor specified by RMS. RMDATASIZE
Used by S15,F13 to differentiate between RMNCreate and RMNUpdate services. RCPUPDT
Used by S15,F35 to differentiate between RMEDelete and RMEDeselect services. RCPDEL
Used by S15,Fy to differentiate between A and B services. RCPDEL
NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for
any particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer's instructions, product labels, product data sheets, and other relevant
literature respecting any materials mentioned herein. These standards are subject to change without notice.
The user’s attention is called to the possibility that compliance with this standard may require use of copyrighted
material or of an invention covered by patent rights. By publication of this standard, SEMI takes no position
respecting the validity of any patent rights or copyrights asserted in connection with any item mentioned in this
standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and
the risk of infringement of such rights, are entirely their own responsibility.
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
1
/CLASS
2
/.../CLASS
n
/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
16
) 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
ATTRIBUTEAttributeName
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
ATTRIBUTEAttributeName “text”(eol) (single-value attributes)
or
ATTRIBUTEAttributeNameLIST“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
ATTRIBUTEAttributeNameLIST(eol)
PARAMNAME“text”, PARAMSETTING“text”, PARAMRULE“text”(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.