X3T9.2/88-91 August 8, 1988 To: X3T9.2 Membership From: John B. Lohmeyer, NCR Principal member in X3T9.2 Subject: Normalizing Wide Negotiation with Synchronous Negotiation Every once in a while, Dal gets a good idea. Sometimes it takes me a while to recognize it. I think Dal had a good idea several months ago when he first suggested that we normalize the SDTR and WDTR negotiation procedures. Later he suggested that failing this, we explain why the two procedures are different. Steve Goldman said (more or less) that this was because we are only negotiating one parameter (transfer width) in WDTR instead of two parameters (transfer period and REQ/ACK offset) in SDTR. Everyone accepted this explanation without any real debate. I did too until I tried to edit the WDTR message for SCSI-2 revision 5. Then I couldn't make sense of the existing wording, nor could I understand why the two procedures needed to be different. In fact, it appeared to me that the wide negotiation procedure suffered from some of the same problems that the synchronous negotiation procedure suffered from until people started implementing it and found these problems. Do we really want to repeat history? I think life would be much simpler if we used the same procedure for both negotiations. So, attached for your review, is a wide negotiation procedure based on the synchronous negotiation procedure. cc: I. Dal Allan Steve Goldman 5.6.23. WIDE DATA TRANSFER REQUEST Message Table 5-9: WIDE DATA TRANSFER MESSAGE ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 02h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 03h | WIDE DATA TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | m | Transfer Width (2**m bytes) | ============================================================================== A WIDE DATA TRANSFER REQUEST (WDTR) message (Table 5-9) exchange shall be initiated by an SCSI device whenever a previously-arranged transfer width agreement may have become invalid. Examples of the agreement becoming invalid are: (1) after a hard reset condition (2) after a BUS DEVICE RESET message (3) after a power cycle and (4) after any condition which may leave the transfer width agreement in an indeterminate state. In addition, an SCSI device may initiate an WDTR message exchange whenever it is appropriate to negotiate a new transfer width agreement. SCSI devices that are capable of wide data transfers (greater than 8 bits) shall not respond to an WDTR message with a MESSAGE REJECT message, except as defined below. The WDTR message exchange establishes an agreement between two SCSI devices on the width of the data path to be used for DATA phase transfers between the two devices. This agreement applies to DATA IN and DATA OUT phases only. All other information transfer phases shall use an eight-bit data path. If an SCSI device implements both wide data transfer option and synchronous data transfer option, then it shall negotiate the wide data transfer agreement prior to negotiating the wide data transfer agreement. If a synchronous data transfer agreement is in effect, then the SCSI device shall respond to any WDTR message with MESSAGE REJECT message. The transfer width that is established applies to all logical units on both SCSI devices. Valid transfer widths are 8 bits (m = 00h), 16 bits (m = 01h), and 32 bits (m = 02h). Values of m greater than 02h are reserved. The originating SCSI device (the SCSI device that sends the first of the pair of WDTR messages) sets its transfer width value to the maximum data path width it elects to accommodate. If the responding SCSI device can also accommodate this transfer width, it returns the same value in its WDTR message. If it requires a smaller transfer width, it substitutes the smaller value in its WDTR message. The successful completion of an exchange of WDTR messages implies an agreement as follows: Responding Device WDTR Response Implied Agreement -------------------------------- ------------------------------------------- (1) Non-zero transfer width Each device transmits and receives data with a transfer width equal to the responding SCSI device's transfer width. (2) Transfer width equal to zero 8-bit Data Transfer (3) MESSAGE REJECT message 8-bit Data Transfer If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a WDTR message to begin the negotiating process. After successfully completing the MESSAGE OUT phase, the target shall respond with the proper WDTR message. If an abnormal condition prevents the target from returning an appropriate response, both devices shall go to 8-bit data transfer mode for data transfers between the two devices. Following target response (1) above, the implied agreement for wide data transfers shall be considered to be negated by both the initiator and the target if the initiator asserts ATN and the first message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to 8-bit data transfer mode for data transfers between the two devices. For the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of the pair of messages is successfully accomplished. After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR message, it shall terminate the retry activity. This may be done by either by changing to any other information transfer phase and transferring at least one byte of information or by going to the BUS FREE phase (see 5.1.1). The initiator shall accept such action as aborting the negotiation, and both devices shall go to 8-bit data transfer mode for data transfers between the two devices. If the target recognizes that negotiation is required, it sends a WDTR message to the initiator. Prior to releasing ACK on the last byte of the WDTR message from the target, the initiator shall assert ATN and respond with its WDTR message or with a MESSAGE REJECT message. If an abnormal condition prevents the initiator from returning an appropriate response, both devices shall go to 8-bit data transfer mode for data transfers between the two devices. Following an initiator's responding WDTR message, an implied agreement for wide data transfer operation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indicating that the target has accepted the negotiation. After a vendor-specific number of retry attempts (greater than zero), if the target has not received the initiator's responding WDTR message, it shall go to the BUS FREE phase without any further information transfer attempt (see 5.1.1). This indicates that a catastrophic error condition has occurred. Both devices shall go to 8-bit data transfer mode for data transfers between the two devices. If, following an initiator's responding WDTR message, the target shifts to MESSAGE IN phase and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be negated and both devices shall go to 8-bit data transfer mode for data transfers between the two devices. The implied transfer width agreement shall remain in effect until a BUS DEVICE RESET message is received, until a hard RESET condition occurs, or until one of the two SCSI devices elects to modify the agreement. The default data transfer width is 8-bit data transfer mode. The default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or after a hard RESET condition. IMPLEMENTORS NOTE: Re-negotiation at every selection is not recommended, since a significant performance impact is likely.