From: SMTP%"yuryan@ornot.zko.dec.com" 16-NOV-1995 13:13:31.66 To: EVERHART CC: Subj: Wide SCSI support notes - a hack... will be revised later today Date: Thu, 16 Nov 1995 11:38:03 -0500 Message-Id: <95111611380297@ornot.zko.dec.com> From: yuryan@ornot.zko.dec.com (ZK3-4/W23 381-0572) To: everhart@GCE.MV.COM Subject: Wide SCSI support notes - a hack... will be revised later today X-Vms-To: SMTP%"everhart@gce.mv.com" X-Vms-Cc: WIDE SCSI SUPPORT NOTES - A HACK... WILL BE REVISED LATER TODAY,YURYAN 11/16/95- mcy Wide SCSI - Proj. Plan. * Add Wide SCSI/High Ids to Gryphon - Code freeze Mid-January. - this includes 64 bit wide anticipating SCSI-3 so that the support does not have to be redone for SCSI-3 - For my own clarification - define wide scsi vs. High-id's * Identify effected modules - - PKC, PKZ, PKE, PKX, PKT, PKS, PKJ, - DK ? MK? and GK ? * According to Glenn's mail, we have 3 port drivers that currently support Wide scsi in theory - for 16 bit only. Is there any signigicant increase in changes when going from 16-bit to 64 bit ? (PKQ, PKS, and PKEdrivers) * Ensure adequate testing - with people outside of SCSI core group such as Tom Coughlin, Storage folks. - Test examples Platforms - i.e. PKC, PKZ, * Each effected component updated by the current component owner i.e. Grace updates PKZdriver. * Common code updated by whom ? * Schedules - - Identify components that need to be changed - Date for first changes - there are 35 working days until January 15 - is that enough time ? * Impact of not doing it now... * RELEASE NOTE _ SCSI Cable length restrictions do not change with wide scsi and high-id's * To avoid having to add the wider support in the future, it makes sense to go to 64 (SCSI3) bit support at this time. -------------------------------------------------------------------------------- * Structures of most concern from - X64E_THETA_SSB_RESD$:[SCSI.SRC]SCSI2common.mar $DDTDEF ; Driver Dispatch Table Definitions $SCDTDEF ; SCSI Connection Descriptor Definitions $SPDTDEF ; SCSI Port Descriptor Definitions $STDTDEF ; SCSI Target Descriptor Definitions -------------------------------------------------------------------------------- * Effected sources/drivers - PKQdriver.c SCSI2COMMON.MAR PKEdriver.B32 PKCdriver.mar PKSdriver.mar PKZdriver.mar PKXdriver.mar PKJdriver.mar MKdriver.mar DKdriver.mar -------------------------------------------------------------------------------- * referenced in the scsi2 spec as WDTR -------------------------------------------------------------------------------- * SCSI2 Spec section 5.1.5.3 Wide Data Transfers - points to be aware of for implementation {} Wide Data Transfers (WDTR) - optinal, used in DATA Phase only if nonzero WDTR agreement in effect. Messages determine use of wide mode by both SCSI devices and establish the data path width to be used. {} Wide data transfers of 16- or 32- bits may be established. Although not mandatory, it is recommended that targets and initiators that support 32-bit also support 16-bit wide transfers as well. All SCSI devices shall support 8-bit data transfers. o Do we currently know of any devices that 1) support 64 bit 2) support 64-bit but do *not* support 16-bit ? o What is the potential impact of having devices support 32-bit but not 16-bit. {} During 16-bit WDTR's, the first logical data byte for each data phase shall be transfered across the DB(7-0,P) signals on the A cable and the second logical data byte shall be transferred across the DB(15-0,P1) signals on the B cable. Subsequent pairs of data bytes are transferred across the A and B cables. {} During 32-bit WDTR's, the first logical data byte for each data phase shall be transfered across the DB(7-0,P) signals on the A cable and the second,third, and fourth logical data bytes shall be transferred across the DB(15-0,P1), DB(23-16,P2), and DB(31-24,P3) signals respectively, on the B cable. Subsequent groups of four data bytes are likewise transferred in parrallel across the A and B cables. (see figure 5-1 - Wide SCSI Byte ordering - page 5-9) REQ/ACK's Sequence requirements between the REQ/ACK on the A cable and the REQB/ACKB on the B cable. 1) REQB & ACKB signals shall *only* be asserted during data phases while a non-zero wide data transfer is in effect. Not allowed in any other phases. 2) The same Asynchronous and Synchronous info shall be used for both the A and B cable. If SDTR mode is in effect, the same REQ/ACK offset and transfer period shall be used for both cables. -------------------------------------------------------------------------------- Wide Data Transfer Request Message - 5.6.23 - page 5-33 ======================================================================= | 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) | ----------------------------------------------------------------------- o WDTR message exchange initiated when a previously-arranged xfr width agreement may have become invalid. An agreement becomes invalid after any condition which may leave the data transfer agreement in an indeterminate state such as: 1) after a hard reset condition 2) after a Bus Device Reset condition 3) after a power cycle o Additionally, a SCSI device may initiate a WDTR message exchange whenever it is appropriate to negotiate a new transfer width agreement. Devices capable of WDTR (greater than 8 bits) shall not respond with a MESSAGE REJECT message. o the WDTR message exchange establishes width of data path used for DATA phases. The agreement applies to DATA IN and DATA OUT phases only. All other info xfr phases shall use an 8-bit data path. -------------------------------------------------------------------------------- Q1. If each component owner is working on the new architecture, can we yank them off of that for this update ? Q2. What is the best way to test the changes ? How many devices ? Disks ? Tapes ? CD's ?? Scanners and other mongrols ? Which platforms ?