semi合集-English.pdf - 第1317页

SEMI E5-1104 © SEMI 1982, 2004 259 RELATED INFORMATION 1 APPLICATION NOTES NOTICE: The materi al contained in this R elated Information section i s not an official part of SEMI E5 and i s not intended to m odify or super…

SEMI E5-1104 © SEMI 1982, 2004 258

Unit Identifier Equivalence Prefix

Allowed

Suffix

Allowed

Description

waferframe wffr None No Yes Special SECS generic unit corresponding to a

temporary fixture for wafers. The unit capacity is

specified by the symbol’s suffix, if provided.

Otherwise, the capacity is situation-dependent.

watt W J/s Yes No SI unit of power.

watthour Wh 3600*J Yes No Unit of energy.

weber Wb V*s Yes No SI unit of magnetic flux.

year yr None No No Unit of time.

NOTICE: SEMI makes no warranties or representations as to the suitability of the standard 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 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