Date: August 12, 1988 X3T9.2/88-100R0 To: X3T9.2 Committee (SCSI) From: James McGrath (Quantum) Subject: Changing SCSI IDs from non-unique ID configurations Problem Definition: This proposal addresses the following problem: A SCSI bus has both SCSI-1 and SCSI-2 devices. Each SCSI-1 device possesses an unique SCSI ID. Each SCSI-2 device either possesses a unique SCSI ID or does not have a unique ID and desires one upon powering up. The goal is to have each of the latter devices assigned a unique SCSI ID so that normal bus activity can commence. The SCSI-2 devices should not have to be previously configured to "know" anything about any other device on the SCSI bus. The entire procedure, which results in a SCSI bus with each device having an unique SCSI ID, can be done in 10 seconds (for 8 devices desiring to be configured). Any late powered on devices requiring configuration do not disturb the existing configuration (if a late powered on device assumes it has a SCSI ID already taken by another device, then the problem must be solved in some other manner). Solution Limitations: The solution assumes that all devices are "well behaved." Specifically that SCSI-1 devices do not come on line asynchronously with respect to the rest of the system (otherwise a SCSI-2 device might take its SCSI ID by mistake). Note that the problem as outlined also assumes that the SCSI-2 devices which already have unique SCSI IDs do not come on line asynchronously with respect to the SCSI-2 devices that need configuring. That is, all SCSI-1 devices and SCSI-2 devices with unique IDs must all come on line before any SCSI-2 device requiring configuration comes on line. However, a simple addition requiring all SCSI-2 devices with IDs to test for their ID uniqueness (by performing a series of SELECTIONs) before responding to the interface under that ID, and requesting configuration if the ID is not unique, is possible. It is also assumed that the SCSI "soft" reset option is not used by any of the SCSI-1 devices. Note that another proposal has been developed to solve the problem of reconfiguring from an unique SCSI ID configuration to a more "desirable" unique SCSI ID configuration. In general this problem admits many solutions, and is much easier to solve that the problem addressed in this proposal. Solution: The process of reconfiguration is done during "maintenance mode." Maintenance mode can be established by any SCSI-2 device that asserts both RST and the MM signal (currently one of the ground signals which shall become "OR-tied" like the RST and BSY lines - note that in the differential it may be desirable to define two lines to drive this signal). SCSI-1 devices shall thus ignore all SCSI bus activity during this mode, and SCSI-2 devices can distinguish it from a reset by the assertion of the MM signal (which shall be qualified like the RST signal). Define the concatenation of the vendor ID and serial number to be the device ID (as opposed to the SCSI ID). While the vendor ID is specified in the standard in the returned INQUIRY data (and is 8 bytes long), the serial number is not. Assume however that the committee can declare that the concatenation of product identification (16 bytes), product revision level (4 bytes long), and a VPD field (say 36 bytes long) does constitute a "serial number" (in that no product manufactured by the same vendor has any duplicates of this 64 byte long quantity). Note that unsupported elements of this quantity (such as VPD) can simply be padded with ASCII blanks (or whatever is the current convention) or replaced with other data. Only the length (64 bytes) and the uniqueness are important. Any device requiring initial configuration shall perform the following: Wait until BUS FREE is detected ASSERT RST Wait until RST has qualified ASSERT MO Wait until MO has qualified For bit := (MSB in the device ID) to (the LSB in the device ID) do If bit = 0 then DEASERET MO If bit = 1 then ASSERT BSY Wait a qualification time DEASERET MO Wait until MO has been DEASSERTED by everyone Wait a qualification time If (bit = 0) and (BSY = ASSERTED) then DEASSERT RST Exit this loop to LOST ASSERT MO Wait a qualification time If bit = 1 then DEASSERT BSY Wait until BSY has been DEASSERTED by everyone Wait a qualification time end loop WON: ASSERT BSY Wait a qualification time DEASSERT RST Wait a qualification time For SCSI ID := Max_SCSI_ID downto 0 do SELECT device SCSI_ID using single initiator option if SELECTION TIMEOUT then exit this loop end device SCSI ID := SCSI ID DEASSERT BSY LOST: Wait until RST is DEASSERTED Timing Analysis: Various qualification times have been placed into the algorithm. While some of these may be unnecessary, all will be included in the timing analysis. Arbitrarily it is assumed that each qualification time is 250 us (which is probably too long). Then the time it takes to determine a winning SCSI device for configuration is: 2*250 + 64*8*(4*250) us = 500 + 512 * 1000 us = 512 ms Once a device has won, it does a series of SELECTIONS. The time here is dominated by the SELECTION TIMEOUT time of 250 ms, for ((Max_SCSI_ID + 1)* 250) ms. Thus the total time is (Max_SCSI_ID * 250) + 750 ms, or 2.5 seconds for 8 devices and 8.5 seconds for 32 devices. Note that in a simple system this process shall be repeated for every device requiring configuration. This could lead to a total system configuration time that is quadratic in the number of devices (i.e. for 8 devices 20 seconds, for 32 devices 272 seconds). However, a refinement of the basic protocol allows the other devices to "easedrop" on the configuration activity of the previous winning configurating devices. Thus they can learn which SCSI ID have already been claimed by other devices, and so can avoid selecting them themselves. This reduces the time complexity to linear once again (2.5 and 8.5 seconds). This refinement is not really needed, since the worse case analysis assumes that devices respond to selection just before the 250 ms timeout, which is clearly not the case. I expect that the basic protocol shall, in practice, operate in linear time.