semi合集-English.pdf - 第1045页
SEMI E4-0699 © SE MI 1980, 1999 7 6 Header St ructure 6.1 The operation of all co mmunic a t i ons functio ns above t he block tran sfer protocol is lin ked to information contained in a 10-byte data element called the h…
SEMI E4-0699 © SEMI 1980, 1999 6
any case when an NAK is sent, the receiver may dis-
card any data it has received for the block. The receiver
returns immediately to the Idle state after sending an
ACK or NAK.
5.8.6 Send Completion — After the second checksum
byte is sent, if an ACK is received within time T2, the
message protocol is notified that the send was success-
ful. If a failed send occurs, the message protocol is in-
formed of the failure. Application-level software must
take the possibility of a send failure into account.
Figure 2
Block Transfer Protocol
SEMI E4-0699 © SEMI 1980, 19997
6 Header Structure
6.1 The operation of all communications functions
above the block transfer protocol is linked to
information contained in a 10-byte data element called
the header. The header is always the first 10 bytes of
every block sent by the block transfer protocol. The
information in the header is also used by the message
protocol (see Section 7). The fixed format of the header
is described in this section. The general header structure
is shown in Figure 3.
NOTE: The header also contains information required by
SECS-II.
6.2 Reverse Bit (R-Bit) — The reverse bit (R-bit)
signifies the direction of a message. The R-bit is set to 0
for messages to the equipment and set to 1 for messages
to the host. The R-bit is included in the header so that
the direction of the message is contained in every block.
Figure 3
Block Header Structure
Table 3 Influence of the R-BIT
R-Bit Device ID Message Direction
0 Destination Host to Equipment
1 Source Equipment to Host
6.3 Device ID — The device ID defines the source or
destination of the message depending upon the value of
the R-bit as shown in Table 3. Device identification is a
property of the equipment and must be settable
according to Section 8. The host can view the device ID
as a logical identifier connected with a physical device
within the equipment. The host has no device ID.
6.4 Wait Bit (W-Bit) — The wait bit (W-bit) is used to
indicate that the sender of a primary message expects a
reply. A value of one in the W-bit means that a reply is
expected. A value of zero in the W-bit means that no
reply is expected. The W-bit must be set to zero in all
secondary messages. For multi-block messages, the
sender must ensure that the W-bit is the same in every
block of the message.
6.5 Message ID — The message ID identifies the
format and content of the message being sent (the
particular message is one of many possible for the
device in question). The exact message content is
equipment-dependent. The upper message ID is the
most significant portion of the ID.
6.5.1 Primary Message — A primar y message is
defined as any odd numbered message. An odd
numbered message will have bit 1 of the lower message
ID set to 1.
6.5.2 Secondary Message — A secondary message is
defined as any even numbered message. An even-
numbered message will have bit 1 of the lower message
ID set to 0.
NOTE: In SECS-II, byte three of the header (excluding the
W-bit) is known as the stream, and byte four of the header is
known as the function. See SECS-II for more information.
6.6 End Bit (E-Bit) — The end bit (E-bit) is used to
determine if a block is the last block of a message. A
value of one in the E-bit means that the block is the last
block. A value of zero means that more blocks are to
follow.
6.7 Block Number — A message sent as more than
one block is called a multi-block message. The first
block is given a block number of one, and the block
number is incremented by one for each subsequent
block until the entire message is sent. The blocks of a
multi-block message are sent in order. In a single-block
message, the block number must have a value of zero or
one. The maximum block number is 32,767. The upper
block number is the most significant portion of the
block number. (See also 7.2.)
6.8 System Bytes — The system bytes in the header of
each message for a given device ID must satisfy the
following requirements. (For a further discussion of
system bytes, see Related Information R1-5.)
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.