semi合集-English.pdf - 第1225页

SEMI E5-1104 © SEMI 1982, 2004 167 Figure 10 Wafer Map Received by Equipment 10.17 Stream 13 Data Set Transfe rs — This stream provides prot ocols to trans fer data sets between sys- tems. It is not intended to provide a…

100%1 / 7923
SEMI E5-1104 © SEMI 1982, 2004 166
Figure 9
Wafer Map Transmitted by Equipment
SEMI E5-1104 © SEMI 1982, 2004 167
Figure 10
Wafer Map Received by Equipment
10.17 Stream 13 Data Set Transfers — This stream
provides protocols to transfer data sets between sys-
tems. It is not intended to provide a general file access
mechanism.
10.17.1 Data Set Characteristics — The data set may
reside on the host or the equipment.
10.17.1.1 The term data set is used in a very general
sense. A data set may represent a file, a data structure
in memory, a collection of sensor values, or high
density wafer profile data. The protocols define only
the way data is sent from one system to another and do
not define how the data set is stored by either the host
or equipment.
10.17.1.2 The sending system is defined to be the
system that has the data set. The receiving system is
defined to be the system to which the data set is being
transferred. The host or the equipment may assume
either role.
10.17.2 Unformatted Data Set Protocol — The proto-
col for transferring unformatted data sets has the fol-
lowing characteristics:
1. Information about the record structure of the data
set may be available.
2. ASCII records are transferred without the record
terminating “noise” characters used by some
operating systems.
3. Data sets do not need to be transferred in a single
message.
4. No arbitrary limits are imposed on the length of
one message. The maximum amount of data sent
in each message is determined by both the sending
and receiving systems, so there can be no data
overruns.
5. There is a method of restarting a transfer in the
event of an interruption.
SEMI E5-1104 © SEMI 1982, 2004 168
10.17.2.1 Data Set Name — An ASCII string (format
20) which performs a function similar to the Message
ID (Stream and Function) of the SECS-I protocol. This
is a logical name which has meaning to both the equip-
ment and the host. Neither the equipment nor the host
is required to use the Data Set Name for the same
information in any other context. For example, mainte-
nance data may be stored in the equipment in the file
“WIDGET.DAT” and in the host as records in a data-
base, but the Data Set Name may be “S11,F2”.
10.17.2.2 Records — The Record Type determines the
way the data set is divided into messages for transfer to
the receiving system. There are two types of records:
Discrete and Stream.
1. A data set with Discrete records has a traditional
record structure, such as ASCII text.
RecordLength is the length of the longest record.
Zero-length records are allowed. Each record from
the data set is sent as a single item in a message.
2. If Record Type is Stream, then the data set has no
internal structure which can be communicated with
this protocol.
These kind of data set might be, for example, a dump of
main memory, SECS-II structured data, or data which
has implicit record boundaries. RecordLength has no
meaning for this kind of data set. Items containing data
from the data set have no relationship to the structure of
the data set.
10.17.2.3 Transactions — The basic data transfer is
performed by the OPEN, READ, and CLOSE transac-
tions. There is no explicit write transaction. A write is
performed indirectly using the SEND transaction. A
RESET transaction is provided to allow a graceful
recovery after a crash. This protocol describes the
transactions over the communications channel only. No
assumption is made about the implementation of the
transactions. For example, the OPEN transaction on a
data set which is stored on a disk file does not
necessarily cause the sending system to open the file.
10.17.2.3.1 The OPEN, READ, and CLOSE transac-
tions are initiated by the receiving system. The SEND
transaction is initiated by the sending system. The
RESET transaction is initiated by either system. The
usual transaction timer operates between the primary
and secondary messages of each transaction. The time
between transactions, especially between READ trans-
actions, is application-specific so no additional timer is
defined.
10.17.2.3.2 Internally, the protocol uses a Handle to
keep track of multiple open data sets, and a Checkpoint
which aids in error recovery. A value called
ReadLength is used to negotiate the amount of data sent
at one time.
10.17.2.4 Handle — Between the sending and
receiving systems, more than one data set may be open
at a time, or one data set may be opened many times.
The Handle is a short name used to keep track of the
state of a particular data set and instance of OPEN
between the sending and receiving systems (see Figure
11). This Handle may be thought of as a name for a
single application level connection from the sending to
the receiving system. Its value is assigned in the
primary message of the OPEN transaction.
10.17.2.4.1 The value used for the Handle must not be
used in another OPEN by the receiving system to the
same sending system until it is used in a CLOSE to that
sending system, or the RESET transaction is sent by
either system. For example, assume a host system
opens a data set on equipment 255 using Handle 1. The
host may not issue another OPEN to equipment 255
using Handle 1 until it closes 1 on 255. However, the
host may use Handle 1 to open a data set on another
piece of equipment, and equipment 255 may use Han-
dle 1 to open a data set on the host.
10.17.2.4.2 The number of data sets which may be
open at one time and the number of times one data set
may be opened is not specified by this standard. Error
codes are defined for situations where the limits are
exceeded. It must be possible to have one outstanding
transaction (i.e., a primary message for which there has
not been a reply) for each open Handle. If the sending
system receives a primary message for a Handle which
already has an outstanding transaction, then the error
code for Pending Transaction is returned in the second-
ary message (see Figure 11).
10.17.2.5 Checkpoint — The response to each READ
transaction contains the data and a new Checkpoint
value. The Checkpoint is defined by and has meaning
only for the sending system. Its purpose is to allow a
data transfer to be restarted from the point of the last
complete message after some communication interrup-
tion. The exact nature of the Checkpoint is not speci-
fied. It could be the byte index in the data set, a record
counter (for Discrete records), or some other system-
dependent value.
NOTE 12: Checkpoint and the SECS-II transaction timer
define a performance requirement for the sending system.
The sending system must be able to get data from any
checkpoint location within a data set between the receipt of
the OPEN primary message and the time for reply to the first
READ.
10.17.2.5.1 The value of Checkpoint must conform to
several rules:
1. The Checkpoint value is exactly four bytes long.