X3T9.3/89-xxx REV 1.0 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � � � � � � � IPI-3--HPPI � � � � IPI-3 Device Generic Command Set � � � � for HPPI � � � � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 Working draft proposal American National Standard for Information Systems NOVEMBER 29, 1989 Secretariat: Computer & Business Equipment Manufacturers Association ABSTRACT: This standard is a bridge document which describes the use of the Intelligent Peripheral Interface Device Generic Command Set (IPI-3) on a High Performance Parallel Interface (HPPI). NOTE: This is an internal working document of X3T9.3, a Task Group of Accredited Standards Committee X3. As such, this is not a completed standard. The contents are actively being modified by the X3T9.3 Task Group. This document is made available for review and comment only. For current information on the status of this document contact the individuals shown below: POINTS OF CONTACT: Bob Morris (X3T9.3 Chairman) Don Tolmie (X3T9.3 Vice Chairman) Intelligent Interface Inc. Los Alamos National Laboratory 2382-C Walnut Avenue C-5, MS-B255 Tustin, CA 92680 Los Alamos, NM 87545 (714) 730-9625 (505) 667-5502 Thomas Mortenson Horst L Truestedt (Editor) Maximum Strategy Inc. IBM Corp; 52A/030-2 1650-B Berryessa Rd. Highway 52 N & 37th Street San Jose, CA 95133 Rochester, MN 55901 Tel: (408) 729-1526 Tel: (507) 253-4101 Fax: (408) 729-7084 Fax: (507) 253-8684 IPI-3--HPPI Draft 1.0, November 29, 1989 IPI-3--HPPI Draft 1.0, November 29, 1989 PREFACE The IPI-3--HPPI Standard describes how the Intelligent Peripheral Interface Device Generic Command Set (IPI-3) can be implemented on the High Performance Parallel Interface (HPPI) to allow data transfer rates of 100-200 MBytes/sec. Page ii IPI-3--HPPI Draft 1.0, November 29, 1989 CONTENTS Preface ......................................................... ii 1.0 Scope and purpose ............................................ 1 1.1 Scope ........................................................ 1 1.2 Purpose ...................................................... 1 1.3 Description of clauses ....................................... 1 1.4 Editorial conventions ........................................ 1 1.5 Functional characteristics ................................... 2 1.5.1 Purpose .................................................. 2 1.5.2 Characteristics .......................................... 2 1.6 Configuration characteristics ................................ 2 2.0 Normative references ......................................... 4 3.0 Definitions .................................................. 5 4.0 Using IPI-3 with HPPI ........................................ 8 4.1 Packet Format ................................................ 8 4.1.1 Header Burst Format ...................................... 9 4.1.2 Data Bursts Format ....................................... 9 4.2 Connections ................................................. 10 4.2.1 Connection Operation .................................... 10 4.2.2 Rejected Connections .................................... 11 4.2.3 I-Field Handling ........................................ 12 4.3 Data Transfers .............................................. 12 4.3.1 Simple GET Operation .................................... 12 4.3.2 Simple PUT Operation .................................... 12 4.3.3 Complex GET/PUT Operation ............................... 13 4.3.4 Error Conditions ........................................ 13 5.0 Highlights of IPI-3 and HPPI ................................ 15 5.1 IPI-3 Command Set and Features .............................. 15 5.2 HPPI Features ............................................... 16 LIST OF ILLUSTRATIONS Figure 1. HPPI Header Burst ...................................... 9 Figure 2. HPPI Data Burst ....................................... 10 Page iii IPI-3--HPPI Draft 1.0, November 29, 1989 1.0 SCOPE AND PURPOSE 1.1 SCOPE This standard provides a description of how to use the Intelligent Peripheral Interface Generic Command Set (IPI-3) on the physical portion of the High Performance Parallel Interface (HPPI). 1.2 PURPOSE The purpose of this standard is to facilitate the development and use of computer systems by providing a common command set that has been developed for IPI-3 to function on the physical hardware what has been developed for HPPI. 1.3 DESCRIPTION OF CLAUSES * Clause 1 provides the introductory material. * Clause 2 lists the publications referenced in this standard. * Clause 3 provides a glossary. * Clause 4 provides the description of using IPI-3 on HPPI. 1.4 EDITORIAL CONVENTIONS In this standard, certain terms that are proper names of signals, state mnemonics, or similar terms are printed in uppercase to avoid possible confusion with other uses of the same words (e.g., BURST, PACKET). Any lowercase uses of these words have the normal English meaning. A number of conditions, sequences parameters, events, English text, states, or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g., In, Out, Enabled). Any lowercase uses of these words have the normal English meanings. The American convention of number is used (i.e., the thousands and higher multiples are separated by a comma and a period is used as the decimal point. This is equivalent to the ISO convention of a space and comma. Page 1 IPI-3--HPPI Draft 1.0, November 29, 1989 American ISO 0.6 0,6 1,000 1 000 1,323,462.9 1 323 462,9 1.5 FUNCTIONAL CHARACTERISTICS 1.5.1 Purpose The purpose of the interface is to exchange information between connected equipments, and meet the following criteria: * Content Independence. The operation of the interface is not affected by the contents of the Information Transfers. * Timing Independence. The control of the interface is not dependent on timing critical operations in the IPI-3 layer. 1.5.2 Characteristics Characteristics of this standard include: * Support a command structure as described in the IPI-3. * Support a physical interface as described in the HPPI. This description includes: - data rate of 100-200 MB/sec - point-to-point - 25 meter - parallel copper. * the use of two HPPI channels to allow full-duplex communications between a Host and Peripheral. 1.6 CONFIGURATION CHARACTERISTICS The topologies targeted by this standard include the following: * Point-to-point topology - one Host is connected to one Peripheral subsystem. * Switched - This topology consists of a switch (or switches) through which a Connection is established between two end-points (i.e., for any given Connection, the identity of the Host and Peripheral is statically implied. The use of switches is not Page 2 IPI-3--HPPI Draft 1.0, November 29, 1989 described in this document. Page 3 IPI-3--HPPI Draft 1.0, November 29, 1989 2.0 NORMATIVE REFERENCES The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. * IPI-3 Device Generic Command Set for Magnetic and Optical Disk - BSR X3.132 * IPI-3 Device Generic Command Set Magnetic Tape - BSR X3.147 * HPPI Mechanical, Electrical Requirements, X3T9.3/88-023, Rev 6.9 * HPPI Data Framing Specification, X3T9.3/89-013, Rev 2.1 Page 4 IPI-3--HPPI Draft 1.0, November 29, 1989 3.0 DEFINITIONS For the purposes of this standard, the following definitions apply. burst: A group of words sent by the Source to the Destination. Bursts shall contain 1 to 256 words. Bursts that contain less than 256 words are called short bursts. A packet shall contain no more than one short burst. A short burst can only be the first burst of a packet. The definition of burst in this standard is comparable to both IPI-3 and HPPI. byte: A group of eight bits ("octet" in IPI-3 terms). Bytes are packed four per 32-bit word, or eight per 64-bit word. command field: The area of the HPPI ULP Data Set which carries the IPI-3 "Command Packet" information from the Host to the Peripheral. commands: The contents of an IPI-3 "Command Packet" (from Host to Peripheral) which instruct the Peripheral of an operation. command packets: A packet which is sent by the Host to the Peripheral via the OUT-channel. This should not be confused with the IPI-3 definition of "Command Packet" which is contained in the ULP portion of the HPPI packet. Connection: A condition of the HPPI when data transfers from Source to Destination are possible.. destination: The equipment at the end of the channel that receives a packet (either Host or Peripheral). GET: Data transfer is from the Peripheral to the Host. header burst: The first physical burst of an HPPI packet. This is the only physical burst which is permitted to be a short burst in this standard. Host: The equipment which establishes a Connection and sends command or data packets on the OUT-channel to a Peripheral. IN-channel: The HPPI used from the Peripheral to the Host. link: A link consists of two uni-directional physical HPPI channels, one outbound and the other inbound. master: IPI-3 definition for the Host which establishes a session and sends commands or data packets on the OUT-channel. node: Each end of a link is a node. operation: A complete command process which includes up to Page 5 IPI-3--HPPI Draft 1.0, November 29, 1989 three phases: command phase from Host to Peripheral; data phase (if there is any) in either direction; and, response phase from the Peripheral to the Host. OUT-channel: The HPPI used from the Host to the Peripheral. packet: A data set sent from Source to Destination which shall be composed of one or more bursts. In IPI, this definition is comparable to "Information Transfer". Peripheral: The equipment which establishes a Connection and sends response or data packets on the IN-channel to the Host. The Peripheral performs operations as commanded by the Host. PUT: Data transfer is from the Host to the Peripheral. response field: The area of the HPPI ULP Data Set which carries the IPI-3 "Response Packet" information from the Peripheral to the Host. response packet: A packet which is sent by the Peripheral to the Host via the IN-channel. This should not be confused with the IPI-3 definition of "Response Packet" which is contained in the ULP portion of the HPPI packet. responses: One of the following IPI-3 "Response Packets" (from Peripheral to Host): * IPI-3 Completion response - informs the Host of completion status (this may be inhibited on read operations by the Inhibit Operation on Success (IORS) attribute). * IPI-3 Transfer Notification Response (TNR) - informs the Host with which command the following data transfer is associated. TNR precedes all data transfers: either from or to the Host. Note: TNR is required in this standard. * IPI-3 Asynchronous response - informs the Host of a condition in the Slave which is not associated with command completion. slave: IPI-3 definition for the Peripheral which sends Responses or data packets on the IN-channel. source: The equipment at the end of the channel that transmits the data (either Host or Peripheral). Page 6 IPI-3--HPPI Draft 1.0, November 29, 1989 ULP Data Set: The Upper Level Protocol "payload" or data set that is transferred in an HPPI packet. This data set can consist of: * an IPI-3 Command or Response packet. * an IPI-3 Command or Response packet and its associated data. word: A unit of information, consisting of 32 or 64 bits, as defined in HPPI. Page 7 IPI-3--HPPI Draft 1.0, November 29, 1989 4.0 USING IPI-3 WITH HPPI 4.1 PACKET FORMAT The basic HPPI Data Link Packet is defined in HPPI Data Framing Specification, X3T9.3/89-013, Rev 2.1. It consists of the following components: * Header * Gap * ULP Data Set: Command/Response Field, and Data Field * Fill All packets have the same general structure; i.e., they consist minimally of an initial header burst, followed by zero, one, or more data bursts. The number of data bursts following the header burst is either implicitly specified by the command/response type or explicitly specified by a count field in the header burst. Packets may consist of the following: 1. One header burst containing IPI-3 Commands ("Command Packets") 2. One header burst containing an IPI-3 Response ("Response Packet") 3. One header burst containing an IPI-3 Write Command followed by one or more bursts of IPI-3 write data. 4. One header burst containing an IPI-3 Transfer Notification Response followed by one or more bursts of IPI-3 read data. Note: except for the header burst (which is allowed to be less than 256 words as defined in the HPPI standard), all data bursts must be 256 words (if a burst cannot fill the 256 word requirement, it must be padded with the HPPI pad character). Page 8 IPI-3--HPPI Draft 1.0, November 29, 1989 4.1.1 Header Burst Format The first burst of a packet is always the header burst which is defined in Figure 1 on page 9. It is the only burst that this standard allows to be a short burst. Included in this burst are the HPPI Data Link Packet Header (Header Field) and that portion of the ULP Data Set which contains the Command/Response Field (only in the header burst are the IPI-3 "Command/Response Packets" allowed; if the commands do not fit into the 256 word burst, they must be included in a subsequent HPPI Packet). Figure 1. HPPI Header Burst 旼컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � HPPI � UPL � � Header Field � IPI-3 Command or Response Field � 읕컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 Word Word 0 256 where: HPPI Header Field: the standard HPPI header. Command Field: one or more standard IPI-3 "Command Packets" including all parameters. Response Field: one standard IPI-3 "Response Packet" including all parameters. 4.1.2 Data Bursts Format Header bursts may or may not be followed by one to n data bursts which are defined in Figure 2 on page 10. Each data burst must be 256 words (short bursts must be padded with the HPPI pad character to 256 words). The data burst(s) contain that portion of the ULP Data Set which is associated with data only. Page 9 IPI-3--HPPI Draft 1.0, November 29, 1989 Figure 2. HPPI Data Burst 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � UPL � � Data Field � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 Word Word 0 256 where: Data Field: the normal IPI-3 read/write data associated with the operation defined in the Command/Response Field. The IPI-3 command set provides a high-level GET/PUT operation. The GET is used to extract information from the Peripheral (e.g., a read operation) and the PUT is used to place information into the Peripheral (e.g., a write operation). 4.2 CONNECTIONS 4.2.1 Connection Operation Prior to packet transfers, a connection must be established between the Source and Destination of each HPPI (OUT- and IN-channel). The Source initiates a connection by asserting the REQUEST signal, and the Destination acknowledges the connection by asserting the CONNECT signal. Once a connection has been established, the Destination must send READY indications (pulses). The Destination sends one READY indication for each burst that it is prepared to accept from the Source. For each READY indication, the Source has permission to send one burst. A connection may be broken either by the Source negating REQUEST, or by the Destination negating CONNECT. This standard supports two methods of connection between a Source and Destination: 1. Protocol A - connect/disconnect: A connection is established at the beginning of each packet and remains in effect until the last burst of the packet has been transferred. This method might be used where two or more Peripheral subsystems are connected to the same Host in a network. The Host initiates the connection on the OUT-channel by asserting the REQUEST signal. If the Peripheral is able to acknowledge, it does so by asserting the CONNECT signal, and sending one READY Page 10 IPI-3--HPPI Draft 1.0, November 29, 1989 pulse giving the Host permission to send a header burst. After the entire command packet has been transferred, the Host must initiate a disconnection sequence. Once the Peripheral is ready to return the response packet, it will assert REQUEST on the IN-channel. If the Host is able to acknowledge, it does so by asserting the CONNECT signal, and sending at least one READY pulse (up to 63) giving the Peripheral permission to send the response packet. After the entire packet has been transferred, the Peripheral must initiate a disconnection sequence (even if another response packet is ready to be transmitted). 2. Protocol B - always connected: Once a connection has been established, the connection remains until specifically broken. This may be a typical DASD subsystem connection where there is only one Peripheral. The Host initiates the connection on the OUT-channel by asserting the REQUEST signal. If the Peripheral is able to acknowledge, it does so by asserting the CONNECT signal, and sending one READY pulse giving the Host permission to send a header burst. As a result of connection on the OUT-channel, the Peripheral will initiated a connection sequence on the IN-channel. If the Host is able to acknowledge, it does so by asserting the CONNECT signal, and sending at least one READY pulse (up to 63) giving the Peripheral permission to send bursts. Following the successful transfer of a command packet from the Host over the OUT-channel, the Peripheral must generate another READY pulse, to allow the Host to send the next header burst. Similarly, following the successful transfer of a response packet from the Peripheral on the IN-channel, the Host must generate another READY pulse, to allow the Peripheral to send the next response packet. Whenever the Host or Peripheral disconnects in order to abort an operation, it must immediately attempt to re-connect. If the Host disconnects the OUT-channel following successful transmission of a command packet, the Peripheral must disconnect the IN-channel immediately following transmission of all related response packets. 4.2.2 Rejected Connections If the Peripheral detects a "Rejected Connection Sequence" on the IN-channel, REQUEST is negated and re-asserted after a time-delay of TBD. Page 11 IPI-3--HPPI Draft 1.0, November 29, 1989 4.2.3 I-Field Handling When the Host connects with the Peripheral over the OUT-channel, the I-field is captured and saved by the Peripheral. Thereafter, any commands sent during this connection are "tagged" with the contents of the I-field. Whenever the Peripheral must connect to the Host (e.g., send a response packet), the I-field information (which was previously saved) must be used during the connection on the IN-channel. 4.3 DATA TRANSFERS In the following discussion, a new HPPI packet is denoted whenever a "header burst" is mentioned. 4.3.1 Simple GET Operation Transferring information from the Peripheral to the Host. 1. On the OUT-channel (Host to Peripheral), the following command packet is sent: a. Header burst containing the IPI-3 command. More than one IPI-3 command may be in this first burst if the slave allows command queuing (as defined by an IPI-3 Attribute). 2. On the IN-channel (Peripheral to Host), the following response packets are sent: a. If data is being transferred, a header burst which contains the Transfer Notification Response (TNR) to indicate for which command the following data transfer is associated. b. one to n bursts containing the requested Read data. Each burst must be the full 256 words (i.e., each burst must be padded with the HPPI pad character to fill this burst). c. A header burst of completion response to inform the Master of completion status (this may be inhibited by the Inhibit Operation on Success (IORS) attribute). Note: there are some IPI-3 commands where the data may be part of the completion response and, therefore, there would be no TNR nor any data bursts. 4.3.2 Simple PUT Operation Transferring information from the Host to the Peripheral: 1. On the OUT-channel (Host to Peripheral), the following command Page 12 IPI-3--HPPI Draft 1.0, November 29, 1989 packet is sent: a. Header burst containing the IPI-3 Write command. b. One to n bursts containing the data to be transferred to the transferred to the Peripheral (if there is any). Each burst must be the full 256 words (i.e., each burst must be padded with the HPPI pad character to fill this burst). Note: there are some IPI-3 commands where the data may be part of the command and, therefore, there would be no data bursts. 2. On the IN-channel (Peripheral to Host), the following response packet is sent: a. Header burst which contains the completion response to inform the Master of completion status. 4.3.3 Complex GET/PUT Operation The command packet from the Host may contain more than one command if the slave allows command queuing (as defined by an IPI-3 Attribute). If a mixture of GET and PUT is in the command packet, the following burst sequence shall be used (IN=IN-channel; OUT=OUT-channel): 1. OUT - one header burst containing the IPI-3 commands. * IF TNR refers to a read command: a. IN - one header burst containing the IPI-3 TNR. b. IN - one or more bursts of read data. c. IN - one header burst containing the IPI-3 response (unless inhibited by the Inhibit Operation Response on Success Attribute). * IF TNR refers to a write command: a. IN - one header burst containing the IPI-3 TNR. b. OUT - one header burst containing the IPI-3 write command. Note that since this is a repeat of the write command itself, the associated parameters are not required (i.e., the Peripheral already has them). c. OUT - one or more bursts of write data. d. IN - one header burst containing the IPI-3 response. 4.3.4 Error Conditions During data transfer, two conditions exist when it may be necessary to abort the data transfer: 1. GET (data transfer from Peripheral to Host) The Host may abort a GET operation by breaking the connection on the IN-channel before the last burst has been received. After Page 13 IPI-3--HPPI Draft 1.0, November 29, 1989 negating REQUEST, the Host must still count BURSTs sent by the Peripheral until CONNECT is deasserted (at most 1). After the connection is broken, the Host must determine if it was broken before the last burst was transferred. The Peripheral must re-connect to the Host and the Host must send at least one READY to allow the Peripheral to transfer a response packet containing Aborted status. The Peripheral may abort a GET operation (e.g., if an unrecoverable read error occurs). The Host must recognize this abort by noticing that not all the required bursts have been transferred and REQUEST has been deasserted. 2. PUT (data transfer from Host to Peripheral) The Host may abort a PUT operation by breaking the connection on the OUT-channel before the last burst has been transferred. Host aborts must only occur on a burst boundary and before the last burst was transferred. A Host abort is noticed by the Peripheral when the Host negates REQUEST (this is "seen" as a control sequence error). The Peripheral response packet must include the Machine Exception major status bit to indicate this error. The Peripheral may abort a PUT operation (e.g., if an unrecoverable media check occurs). The abort will only be initiated if the last READY for this transfer has not already been sent to the Host. Following this abort, there may potentially be partial files that have been updated on the media and other data may still be in internal buffers. The response packet must be used by the Host to determine the actual amount of data that was transferred to the media. Page 14 IPI-3--HPPI Draft 1.0, November 29, 1989 5.0 HIGHLIGHTS OF IPI-3 AND HPPI 5.1 IPI-3 COMMAND SET AND FEATURES The command set described in the IPI-3 Generic Command Set documents is used to instruct the Peripheral on the action that the Host desires. This includes simple read and write commands, attributes, and diagnostic commands. Since the connection (once established) is a point-to-point connection between the Host and the Peripheral (master and slave), the normal IPI-3 address bytes (slave and facility) are defined as follows: Slave Address: logical address of the Peripheral. Since there is only one, this address is set to X'00'. Facility Address: logical address of the devices in the Peripheral subsystem. The following addresses are defined: * Address X'00' to X'FE' - address of device 0 to 254. * Address X'FF' - address of the Slave. Two features of IPI-3 should be considered here: 1. Transfer Notification Response (TNR). This information is contained in a header burst that indicates to the Host for which command the following data transfer should occur. In the case of a write operation, the Host will respond with the write command followed by the write data. In the case of a read operation, the Peripheral will follow TNR with the read data. 2. Inhibit Operation Response on Success (IORS). This attribute provides the option for the Peripheral to report to the Host that it can inhibit completion response packets and for the Host to tell the Peripheral that it should operate in the IORS mode (i.e., both Host and Peripheral communicate that they can and want to operated in IORS mode to each other). In this standard it is intended that IORS would only be used for read commands (GET operations). If the Peripheral is operating in IORS mode, no completion response packet will be sent to the Host after normal completion (i.e., there were no errors) of a command. If an error is detected by the Peripheral, the Peripheral must disconnect the IN-channel before the last data burst has been transmitted. It must then immediately reconnect to allow the Host to receive the expected completion response packet. Page 15 IPI-3--HPPI Draft 1.0, November 29, 1989 5.2 HPPI FEATURES HPPI supports a protocol for low-latency and variable size packet transfers. Once a connection has been established, multiple bursts may be transferred without a round-trip cable delay. Signalling and control sequences are kept simple to allow average transfer rates for large transfers to approach the peak transfer rate. Look-ahead flow control is used to enable these same high data rates over long distances. Since the HPPI is a simplex channel, capable of data transfer in one direction only, the use of it in this standard requires two HPPI channels: one for commands and out-data called the OUT-channel, and one for responses and in-data called the IN-channel. Relative to the OUT-channel, the Host assumes the role of Source and the Peripheral assumes the role of Destination. Relative to the IN-channel, the Peripheral assumes the role of Source and the Host assumes the role of Destination. Page 16 IPI-3--HPPI Draft 1.0, November 29, 1989 旼컴컴컴컴컴컴컴컴� � � � � � � � � � End of Document � � � � � � � � � 읕컴컴컴컴컴컴컴컴� Page 17 e partial files that have been upd