semi合集-English.pdf - 第1319页

SEMI E5-1104 © SEMI 1982, 2004 261 form as S6,F3-4 but does not require the value name in the data set. Instead, the order of the values is fixed format for the particular DS ID in that particular equipment . R1-3.3.5 Wh…

SEMI E5-1104 © SEMI 1982, 2004 260

R1-3.2.2 The trace feature will only exist in equipment

which implements it.

R1-3.2.3 The host sets up the trace with the S2,F23-24

transaction. At this time, the host assigns several

important parameters. TRID is the trace request ID and

is used later when the equipment sends back the data.

Every trace data reply includes the TRID corresponding

to the request that set up the trace. Several traces can

theoretically be done at the same time if the equipment

allows it and the TRID keeps the data for each trace

distinct from other trace data. DSPER is the data

sample period and is used to indicate how often the

specified parameters should be sampled (that is, have

their values saved). TOTSMP is the total number of

samples to be made. Since TOTSMP is finite and the

number of parameters is specified in this transaction,

the host can reserve adequate file space for the reported

data if required. The REPGSZ is the reporting group

size and corresponds to the number of time samples that

should be combined into one message prior to

transmission. Thus, if it is desired to sample one or two

parameters every second but only send those samples to

the host once a minute, the reporting group size would

be 60. Having the reporting group size parameter

allows the host to have some control over how often it

may be interrupted to handle the trace data. However,

as presently defined in the standard, the trace data is

reported as a single block message (S6,F1), which

restricts both the number of status variables or the

number of samples which can be combined into one

message. The equipment may be able to accommodate

this in several ways, to be described shortly.

R1-3.2.3.1 The last element in the trace initialize

request is a list of status variable IDs. The trace

command only allows tracing variables that have been

declared and are known to the equipment as status

variables. It is assumed that the equipment will report

the variable values in the same order as specified in the

trace request. This will allow the host to identify the

values returned.

R1-3.2.4 The trace data send message, S6,F1-2, sends

the trace data as a single block message to minimize the

overhead in reporting data. The TRID is the first item

and identifies the request that asked for the data. The

next item is SMPLN, the sample number of the last

sample in this message, should more than one sample

be combined. The next item is STIME which is the

time of the last sample in this message. These three

items are followed by the list of values. If five (5)

values were requested with a reporting group size of 5,

then 25 values would be in this list, each group of 5 in

the same order as requested and in the time order

sampled. Some flexibility is allowed in how the

equipment chooses to report the data to the host when

the reporting group size exceeds one block of data. The

equipment can send the data when it has a complete

block or it can reject the request when it is set up.

R1-3.3 Event Driven Data Reporting

R1-3.3.1 The second major type of data reporting is

initiated by some event in the equipment. Data

reporting is often desired after some event such as the

completion of a measurement, the completion of a lot,

the completion of a wafer, the occurrence of a special

event command in the recipe, or some other action

which is determined by the equipment. The two aspects

involved in event driven data reporting are the control

of which events cause data to be sent to the host and the

formatting of the data sent to the host.

R1-3.3.2 It is assumed that a set of events has been

established for a particular piece of equipment and that

each event can produce a report of some sort. It is

further assumed that a set of equipment constants exist

in the machine such that they have control over the

optional reporting of the events. For example, a

boolean constant may exist for each possible reporting

event, and when the host sets the constant to a logical 1,

the corresponding event will cause a report to be sent to

the host, when the host sets the constant to logical 0, the

event will not send a report. S2,F15-16 in the

equipment constant send transaction can be used to

control the event reporting.

R1-3.3.3 When an event causes data to be sent to the

host, there are several possible conversations,

depending upon the length of the data and the

complexity of the formatting. S6,F3-4 is the basic data

transaction, which has a very general format. The

parameters provide for an overall name, DATAID, for

the type of data; a collection event identification, CEID,

should there be more than one event that could generate

the same type of data; and a list of data sets. This

structure allows reporting such data as the

measurements taken on each of the wafers in a lot. The

measurements on each wafer make up one data set, and

the list of data sets is the whole lot. The collection

event would be the lot completion, and the data ID

might be film thickness measurements. Other types of

organizations are possible, depending upon the type of

data being sent. The same type of data might be

produced by a different CEID, such as the forced

termination of the lot. This collection ID would

indicate that the data is incomplete for the lot. Within

each data set, each data value is reported as a pair of

items, one item being the name of the value and the

other being the value.

R1-3.3.4 Since many simple measuring devices have

only a very few types of data sets, an alternative data

format is provided in S6,F9-10, which has the same

SEMI E5-1104 © SEMI 1982, 2004 261

form as S6,F3-4 but does not require the value name in

the data set. Instead, the order of the values is fixed

format for the particular DSID in that particular

equipment.

R1-3.3.5 When either of the above data messages is

long enough to require multiple blocks, it must be

preceded by S6,F5-6 to gain permission to send a

multiple block message.

R1-3.3.6 The last data control transaction is S6,F7-8,

which is initiated by the host and causes a specified

DATAID to be sent to the host. The implementation of

this function is highly equipment-dependent. In

essence, it is equivalent to the host causing an event

that triggers the sending of the data. Since the

equipment may be generating the data, the actual data

sent depend upon the equipment implementation. The

equipment can respond with a zero length item if no

data can be sent.

R1-3.4 Event Reporting

R1-3.4.1 The third major type of data reporting is

similar to that described in A3.3 above, with the

following enhancements:

1. Contents of data reports are not limited to

DVVALs, but may include SVs or even ECVs.

2. Contents of data reports are user programmable.

R1-3.4.2 It is assumed that the equipment vendor

supplies a list of all “events” identified within a

particular piece of equipment. A Collection Event

Identifier (CEID) must be specified for each of these

events. It is further assumed that the vendor supplies a

list of all available variables within the machine. This

includes Status Variables (SVs) and their identifiers

(SVIDs), Equipment constants (ECVs) and their

identifiers (ECIDs), and Data Values (DVVALs) and

their identifiers(DVNAMEs). Each of the identifiers

must be unique. The term VID (Variable Identifier)

encompasses all SVIDs, ECIDs, and DVNAMEs.

Likewise, the term V (Variable Data) encompasses all

SVs, ECVs, and DVVALs.

R1-3.4.3 Note that a Variable (V) may be a list (format

code 0). This provides for referencing a group of

related data values with one identifier. Consider the

following:

VID

= 1 zone 1 temperature ID Format 32

zone 1 temperature value Format 52

VID

= n zone n temperature ID Format 32

zone n temperature value Format 52

VID

= x all temperatures ID Format 32

L,n Format 0

1. L,2

1. <VID

2. <V

n. L,2

1. <VID

2. <V

Any V in a list may also be a list (for nesting).

R1-3.4.4 In a typical initialization sequence, the host

would define all the desired programmable data reports

with S2,F33/S2,F34 (Define Report) transactions. Then

S2,F35/S2,F36 (Link Report/Event) transactions would

be used to define which reports are to be made by the

equipment upon specific events (CEIDs). An

individual report may be linked to more than one event.

At this point the host may request reports with the

S6,F15/S6,F16 (Report Request) transactions to obtain

initial report data and/or to verify reports as defined and

linked. Finally, the desired reports would be enabled

by the host with S2,F37/S2,F38 (Enable/Disable Event

Report) transactions.

R1-3.4.5 There are two methods for the equipment to

send event reports to the host. S6,F13 includes the

Variable Identifier (VID) with each Variable Data item

(V). S6,F11 is a shorter form, without the identifiers;

some users prefer this form to reduce message size.

R1-3.4.6 When any message is long enough to require

multiple blocks, it must be preceded by an inquire/grant

transaction.The DATAID parameter is used only to link

the inquire/grant transaction with a multiblock message.

This linkage is to alleviate problems in the case of

interleaved messages. A unique value for DATAID

must be used for each Inquire/Grant/Send/Ack-

nowledge conversation (similar to the use of

SYSBYTES in SECS-I). The DATAID parameter

should not be used for any other purpose.

R1-4 Process Programs

R1-4.1 Introduction

R1-4.1.1 Two forms of process programs are supported

by SECS-II: unformatted and formatted. The contents

of an unformatted process program conform to no set

standard. The format of the program is defined by the

vendor of the equipment and probably bears no

similarity to the format used by other vendors for their

SEMI E5-1104 © SEMI 1982, 2004 262

equipment. Because special programming would be

required at the host to understand the equipment’s

unique data format, the process program is most likely

generated at the machine and the host is only used as a

data repository, saving the foreign data for later

retransmission to the equipment. S7,F3 and S7,F6 are

the SECS-II messages used to move unformatted

process programs between host and equipment.

R1-4.1.2 Unformatted process programs were the

original accepted means for moving processing

instructions between host and equipment under SECS-

II. However, the inability of a host to generate process

programs for its subordinate machines was quickly

recognized as a severe problem. As a result, the

formatted process program and its associated

transactions were added. Five transactions are provided

under SECS-II for handling formatted process

programs: S7,F23-24, S7,F25-26 allow movement of

process programs between host and equipment; S7,F21-

22 originates at a machine and provides a host with the

information it needs to generate a process program for

that machine; S7,F27-28 allows the equipment to tell

the host whether or not the contents of the formatted

process program received from the host are valid; and

S7,F31-32 provides the host with the ability to ask the

equipment to check the validity of a process program

without actually downloading the program into the

machine for production use.

R1-4.2 Normal Sequence of Operations

R1-4.2.1 Formatted process programs may be

generated at a host or machine. The actions taken to

generate one in a machine are left to the equipment

manufacturer. If the process program is created at a

host, a sequence of operations is assumed.

R1-4.2.1.1 Once the host’s process program generator

has been invoked and has been told for which machine

a process program is to be created, the host editor must

obtain a copy of the process capabilities data for that

machine. The information may already be available on

the host or it may be obtained directly from the

machine. In either case, the information originates at

the equipment and is obtained using S7,F21-22. (See

Section R1-4.4 for additional information.)

R1-4.2.1.2 With the machine’s process capabilities in

its possession, the process program editor may proceed

with creating the desired process program. At the

conclusion of the editing session, the new machine

process program will either be saved at the host or sent

directly to the machine for storage and/or use.At this

point, the process program is known to satisfy a number

of constraints, but it is not necessarily completely

acceptable to the machine due to interrelationships of

the process program data which are too complex to be

described in the machine process capabilities data. The

host at any time may verify that a process program is

truly valid by sending the process program to the

machine and asking it to check the process program and

tell the host whether or not the process program is, in

fact, correct. If not correct, the equipment is expected

to provide information on what data in the process

program is unacceptable. This action is accomplished

through S7,F31-32. This transaction is equivalent to

S7,F23-24, with one important exception, the machine

is not to do anything with the process program received

under S7,F31 except acknowledge that it got the

message (S7,F32) and, as soon as it is able, respond

with S7,F27, which provides the host with information

on the validity of the process program. In this way, a

new version of a process program already held by a

machine may be checked for validity without affecting

the operation of the machine (i.e., a newer version of a

particular process program may be checked while an

older version is simultaneously being used by the

equipment for material processing).

R1-4.2.1.3

At some point, a host resident process

program will be required by the equipment for material

processing. Transfer of a program may be

accomplished in either of two ways. First, the host may

initiate transfer by transmitting S7,F23. In this case,

immediately upon reception of the message, the

equipment is required to respond with S7,F24, which

tells the host that the process program arrived and

whether or not the process program is accepted for

further processing by the equipment. The second

means is for the equipment to initiate the transfer by

asking for a process program using S7,F25. In this

case, the host will send the process program to the

equipment or tell the equipment it is unable to satisfy

the request. S7,F23 may also be used by a piece of

equipment to transfer a process program to its host for

archiving. In this case, the host will respond with

S7,F24 and an appropriate completion code. Likewise,

a host may request a process program transfer from its

machine using S7,F25. The machine will respond with

S7,F26, which will contain the process program or an

error indication.

R1-4.2.1.4 Following reception by the equipment of

the process program, it is the machine’s responsibility

to check the contents of the process program for

validity and respond to the host with a S7,F27 message

formatted with the appropriate information about the

just received process program. To complete the process

program exchange transaction, the host will

acknowledge the S7,F27 message with S7,F28. What is

done with the process program once accepted and

checked for validity is dependent on the state of the

process equipment.