semi合集-English.pdf - 第1318页

SEMI E5-1104 © SEMI 1982, 2004 260 R1-3.2.2 The trace feature will onl y exist in equipm ent which implements it. R1-3.2.3 The host sets up the trace wit h the S2,F23-24 transaction. At this time, the host assigns severa…

SEMI E5-1104 © SEMI 1982, 2004 259

RELATED INFORMATION 1

APPLICATION NOTES

NOTICE: The material contained in this Related Information section is not an official part of SEMI E5 and is not

intended to modify or supersede the official standard. Rather, these notes describe possible methods for

implementing the protocol described by the standard and are included as reference material. The standard should be

referred to in all cases. SEMI makes no warranties or representations as to the suitability of the material set forth

herein for any particular application. The determination of the suitability of the material is solely the responsibility

of the user.

R1-1 The General Node Transaction Protocol

R1-1.1 This application note has been moved to follow

SEMI E4 (SECS-I) as Application Note A7.

R1-2 Some Suggested Message Usage

R1-2.1 The number of messages implemented and the

choice of messages are greatly influenced by the actual

function of the equipment. To illustrate which

messages might be appropriate, the following

suggestions are offered for a variety of different types

of equipment capabilities. It is assumed that the

minimum message sets S1,F1; F2 and S9,F1; F3; F5;

F7 are always implemented.

R1-2.2 For equipment which makes nondestructive in-

process measurements using a fixed measurement

procedure, it may be necessary only to implement S6,

F9 to send the data according to a fixed format upon

measurement. Optional remote control can be added

with S2,F21 to start a measurement.

R1-2.3 If the equipment has a variety of measurement

routines, it might be desirable to respond to S1,F5 with

S1,F6, which would give the host a brief report of the

test being made. The test can be thought of as a process

program. Accordingly, S7,F1 and S7,F2 could be used

for the host to select the program. The same messages

in conjunction with S7,F3 and S7,F4 could load a new

test procedure. S7,F19 could be used by the host to

find out what tests were available.

R1-2.4 Some equipment which automatically processes

wafers in a batch might make more extensive use of

S1,F5 or S1,F3 and might include some error reporting

on S5,F1. More sophisticated equipment may include

some trace features with S2,F23 and S6,F1 or some

control loop tuning by S2,F15.

R1-2.5 Equipment using in-line wafer movement could

utilize Stream 4, S1,F9, and Stream 3 to keep track of

wafers.

R1-2.6 Stream 7,F9 through F19 can be used to

manage a local backup of process programs should the

host fail for a short while.

R1-2.7 Microprocessor equipment can benefit from

features such as provided by Stream 8 and S2,F1

through F12 which allow managing and servicing the

software routines.

R1-2.8 Equipment, including a CRT, might elect to

make it available to the host by including Stream 10

messages.

R1-2.9 Some equipment, such as functional testers,

might have sufficient need to undertake remote file

usage such as provided in Stream 13.

R1-2.10 These brief suggestions serve to illustrate that

the final choice of the messages included in a given

equipment depends upon its function. The messages

can be viewed as interface features in the same way that

other parts of the equipment are viewed as processing

features or wafer handling features.

R1-3 Notes on SECS-II Data Transfers

R1-3.1 Introduction

R1-3.1.1 There are two primary ways to send and ask

for data in SECS-II. One of these is to use the trace

feature and the other is to use the event reporting

method. The purpose of this note is to describe the

intended operation of the messages described in the

existing standard. Discussion of completeness or need

for other reporting methods is left for task force and

committee work.

R1-3.2 Trace Data Collection and Reporting

R1-3.2.1 This method of collecting data is intended for

engineering and developmental use rather than routine

data collection for production. The features included

allow the collection of relatively large amounts of real

time data over a finite amount of time. The data is

generated at regular time intervals as determined by a

timing generator in the equipment. The function of the

host is to set up the trace and then to subsequently store

the data as it is received from the equipment. It is

assumed that some host resident applications will exist

to analyze the data either as it is received or at some

later time.

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