semi合集-English.pdf - 第1047页
SEMI E4-0699 © SE MI 1980, 1999 9 7.4.2 Duplicate Block Detection — A duplicate block is a block wh ic h is exactly the same as the previous block received by the B lock Transfer Protocol. This may occur when th e recei …
SEMI E4-0699 © SEMI 1980, 1999 8
6.8.1 Distinction — The system bytes of a primary
message must be distinct from those of all currently
open transactions initiated from the same end of the
communications link. They must also be distinct from
those of the most recently completed transaction. (See
Section 7.3.) They must also be distinct from any
system bytes of blocks that were not successfully sent
since the last successful block send.
6.8.2 Reply Message — The system bytes of the reply
message are required to be the same as the system bytes
of the corresponding primary message.
6.8.3 Multi-Block Messages — The system bytes of all
blocks of a multi-block message must be the same.
7 Message Protocol
7.1 A message is a complete unit of communication in
one direction. The message protocol uses the services
of the block transfer protocol to send and receive
messages. The message consists of the message data
together with the following information from the header
— R-bit, device ID, W-bit, message ID, and system
bytes.
7.2 Message Send — When a message is ready to be
sent, the message send protocol performs the functions
described below. A block send failure terminates the
message protocol action on that message.
7.2.1 Message Length — The maximum data length in
a single block of a message is 244 bytes. The maximum
number of blocks that can be sent in a multi-block
message is 32,767, and so the maximum data length
allowed in one message is 244 × 32,767 bytes.
7.2.2 Message Blocking — Message blocking is the
division of the message data into blocks to be sent to
the Block Transfer Protocol. For best performance, it is
recommended, but not required, that the sender fill all
blocks of a multi-block message, except possibly the
last block, with the maximum 254 bytes. The receiver
of a multi-block message should be able to accept any
block size from 11 to 254 bytes, and should not require
consecutive blocks necessarily to be the same size.
7.2.2.1 Certain older implementations may impose
application-specific requirements on block sizes for
certain incoming messages. Beginning with the 1988
revision of the standard, new applications may not
impose application-specific requirements on incoming
block sizes. Applications implemented before 1988
may impose such requirements.
NOTE: In SECS-II, certain messages are defined as single-
block messages and must be sent as a single block in SECS-I.
7.2.3 Header — The message protocol must establish
the header in each block of the message according to
the requirements of Section 6.
7.2.4 Interleaving Messages — This standard allows,
but does not require, the support of more than one
concurrent open transaction. This standard allows, but
does not require, the support of interleaving the blocks
of different multi-block messages. (See documentation
requirements in 9.)
7.3 Transactions — A transaction is a primary
message and an optional corresponding secondary
message is called the reply. A transaction is opened
when a primary message is ready to be sent. A
transaction is closed when the last block of a primary
message requesting no reply has been sent, or when the
last block of the reply has been received.
7.3.1 Reply Linking — When a reply is expected for a
primary message, the message protocol starts the reply
timer for the transaction after the last block of the
message is successfully sent. When a primary message
is sent for which a reply is requested, an expected block
is established for the message receive algorithm. (See
Section 7.4.) The expected block will have the
complement of the R-bit, will have the same device ID,
will be the first block of a secondary message, and will
have the same system bytes as those of the given
primary message.
NOTE: In SECS-II, the reply will have the same upper
message ID (stream), and the lower message ID (function)
will either be one greater than that of the corresponding
primary message, or it will be zero.
7.3.2 Reply Timeout, T3 — The reply timeout, T3, is a
limit on the length of time that the message protocol is
willing to wait after the last block of a primary message
has been sent and before the arrival of the first block of
the reply. If the first block of the reply does not arrive
within the T3 limit, the expected block is removed from
the list of expected blocks, and the transaction is
aborted. A timer, called the reply timer, is used to
measure the time between the last block of the primary
message and the first block of its reply. Each open
transaction for which a reply is expected requires a
separate reply timer.
7.4 Message Receive — Each block successfully
received by the block transfer protocol is passed to the
message protocol. It is the task of the message protocol
to identify the blocks and assemble them into the proper
message.
7.4.1 Routing Error — When a piece of equipment
receives a block of data which has a device ID in the
block header which does not match its own device ID
and it has no other knowledge of this device ID, it can
assume that the block was sent in error.
SEMI E4-0699 © SEMI 1980, 19999
7.4.2 Duplicate Block Detection — A duplicate block
is a block which is exactly the same as the previous
block received by the Block Transfer Protocol. This
may occur when the receiver has sent an ACK but, for
some reason, the ACK did not arrive in time at the
sender, causing a send retry. A duplicate block is
detected by the SECS-I message protocol by comparing
the full 10-byte header of a block currently received by
the block transfer protocol with the header of the last
block accepted as non-duplicate by the message
protocol. If the headers are identical, the new block is a
duplicate and should be discarded. If the headers are
different, the new block is a non-duplicate. The header
of the non-duplicate block saved for comparison with
the next block passed on by the block transfer protocol,
and the block containing the header is further processed
by the message receive algorithm.
NOTE: Some implementations which follow the 1980 version
of SECS-I may not provide the unique headers required for
duplicate block detection. An option for disabling the
duplicate block detection is required to be compatible with
these systems.
7.4.3 Inter-Block Timeout T4 — The time interval
between the successful receipt of a block in a
multiblock message, and the successful receipt of the
subsequent block of the same message, is limited to
time T4. If this time is exceeded, the message is
cancelled and the transaction is aborted. A time called
the inter-block timer is used to measure the time
between block arrivals in the message protocol. There
must be one inter-block timer for each open multi-block
message currently being received by the protocol. As
each successive block of a message is received, the
corresponding inter-block timer is reset.
7.4.4 Algorithm — When a block arrives at the
message protocol, a combination of all the bytes in the
header is used to determine what to do with the block.
The operation of the message receive algorithm is to be
understood by following the logic flow in Figure 4. The
flow chart shown in Figure 4 and the description of the
algorithm below are not meant to imply that particular
implementation is required under this standard.
However, any SECS-I message protocol
implementation must include all the logic shown in
Figure 4 on page 11.
7.4.4.1 The description of the message protocol uses
the concepts of an expected block. When a (properly
routed and non-duplicate) block is received by the
message protocol, the first determination is whether the
block is one of the expected blocks or not. In order to
determine if a block is one of the expected blocks, the
header information is compared with the header
information in a list of expected blocks.
7.4.4.2 If the block is not one of the expected blocks,
it must be the first block of a primary message,
otherwise the block has been sent in error and can be
discarded. If the block is the first block of a primary
message, and it is not the last block of the message (E-
bit = 0), an inter-block timer for the given message is
established and set, and the expected block for the
given message is set to have the same R-bit, device ID,
system bytes, W-bit, message ID, and a block number
one greater than that of the block just received.
7.4.4.3 If the block is one of the expected blocks, then
it is either the first block of a reply message or it is part
of an open message.
7.4.4.4 If the block is the first block of a reply
message, the reply timer for the given message is
cancelled. For the first block of a reply message, the
expected block will have block number one (or possibly
zero if the reply is a single block message) and will be a
secondary message, but the full message ID is
undetermined. (See Section 7.3.1.)
7.4.4.5 If the block is the last block of the given
message (E-bit = 1), the message is complete. If the
message is a primary message for which a reply is
requested (W-bit = 1), the system bytes are saved for
sending with the reply message. (See Section 7.2.3.)
7.4.4.6 If the block is not the last block of the message
(E-bit = 0), then the inter-block timer for the given
message is reset, and the (next) expected block for the
given message is set to have the same R-bit, device ID,
system bytes, W-bit, message ID, and a block number
one greater than that of the block just received.
8 Parameter Setting
8.1 The eight protocol parameters are listed in Table 4.
The selection of baud rate should be based on system
performance. The value of the device ID is determined
by the particular system requirements and is generally
unique within one factory. The values of the next five
parameters are determined by the performance
characteristics of the host system and the baud rate of
the communication channel. The first seven parameters
must be adjustable by the user. All parameters must be
stored in such a manner that the settings will be retained
if the power fails or if the system software is reloaded.
The range and resolution of protocol parameters must
be at least as shown in Table 4. The M/S parameter is
set to master in the equipment and to slave in the host.
SEMI E4-0699 © SEMI 1980, 1999 10
Table 4 Protocol Parameters
Symbol Parameter Name Typical Function Typical Value Range Resolution
BAUD Baud Rate Sets serial line speed 9600 300 - 9600 see Section
3.3
DEVID Device ID Identifier assigned to the equipment — 0 - 32767 1
T1 Inter-Character Timeout Detects an interruption between characters 0.5 sec. 0.1-10 sec. 0.1 sec.
T2 Protocol Timeout Detects a lack of protocol response 10 sec. 0.2-25 sec. 0.2 sec.
T3 Reply Timeout Detects a lack of reply message 45 sec. 1-120 sec. 1 sec.
T4 Inter-Block Timeout Detects an interruption in a multi-block message 45 sec. 1-120 sec. 1 sec.
RTY Retry Limit The maximum number of send retries allowed 3 0 - 31 1
M/S Master Slave Contention resolution — — —
9 Documentation
9.1 For equipment or host to comply with SECS-I, a
document is required containing the following
information. (See also SEMI E6, Facilities Interface
Specifications Guideline and Format.)
1. Method for setting all the parameters in Table 4.
2. Range allowed and resolution for each parameter in
Table 4.
3. Compatibility with duplicate block detection and
the method for enabling and disabling the same if
present (see Section 7.4.2).
4. Maximum expected inter-character, protocol, reply,
and inter-block delays generated under normal
operating conditions.
5. Whether multi-block messages are supported as a
receiver.
6. Whether multi-block messages are used as a
sender.
7. Whether there is a limit to the size of a message
received and, if so, what the limit is.
8. Maximum expected size of a message being sent.
9. Whether message interleaving is supported as a
receiver.
10. Whether message interleaving is used as a sender.
11. Number of device ID's supported on the port.
12. Maximum number of supported concurrent open
transactions.