Date: July 18, 1988                                         X3T9.2/88-088R0

To: X3T9.2 Committee (SCSI)   

From: James McGrath (Quantum)

Subject: Changing SCSI IDs from unique ID configurations




Problem Definition:

  This proposal addresses the following problem:

  Given a SCSI bus with SCSI-1 and SCSI-2 devices, each possessing a
  unique SCSI ID, reconfigure the system through the SCSI bus so that
  the SCSI-2 devices assume new SCSI IDs (although each device still
  possesses a unique ID).




Solution Limitations:

  The solution assumes that all devices are "well behaved,"
specifically that SCSI-1 devices either do not come on line
asynchronously with respect to the rest of the system or the SCSI-2
devices know of the presence of the SCSI-1 devices (and their SCSI
IDs) independently of SCSI bus activity.  It also assumes that the
SCSI "soft" reset option is not used by any of the SCSI-1 devices.

  This proposal does not solve the more general problem of
conflicting SCSI IDs.  That problem is only important during initial
system configuration, and thus is similar to a SCSI FORMAT UNIT
command (in that it is rarely done and thus can be complex and slow).
Assuming an initial unique configuration of SCSI IDs implies a
problem more similar to the SCSI READ command (in that it may be
executed often, and so must potentially be done fast).  Quick
reconfiguration is a goal of the initial IBM proposal, but the
solution presented here appears to be a better one.




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 line (currently one of the ground signals which
is "OR-tied" like the RST line).  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 line (which
shall be qualified like the RST signal).






  During maintenance mode the SCSI-2 devices may arbitrate for
control of the SCSI bus using the usual arbitration mechanism.
Whichever device wins is declared the reconfiguration master for this
round of reconfiguration.  All other SCSI devices shall deassert the
RST and MM lines (within a certain time limit).  No other
arbitrations shall be attempted by any SCSI device until maintenance
mode has been left.

  Each device which require an ID change is then selected by the
reconfiguration master, responds to selection, receives a device SCSI
ID reconfiguration message (actually one of 8 messages, one per ID),
and then goes to bus free.  Note that after bus free phase has been
reached the rconfiguration master does not have to enter arbitration
again, but simply begins the process for the next SCSI-2 device.

  After the reconfiguration master has completed reconfiguration it
may verify the reconfiguration by successfully selecting the devices
and performing an INQUIRY command (although this is optional).
Maintenance mode shall be terminated when the reconfiguration master
deasserts MM and RST (within certain timeouts).




Further Work:

  While certain timing requirements need to be fleshed out, this is
the thrust of the proposal.  Note that if verification is not done
then this sequence could be automated in hardware.  Thus a bus with
only SCSI-2 devices could be reconfigured very rapidly (in under 1
ms).

  If commands are being executed or are queued when reconfiguration
occurs, then this process is not as quick.  If this is viewed as a
serious problem then other similar techniques that allow the other
SCSI-2 devices to "snoop" on reconfigurations, and thus to know the
addresses of all reconfigured devices immediately, can be proposed.
In simplest form all SCSI-2 devices must monitor the selection and
message phases for other devices so that their reconfiguration
information is made available to all devices.  This would require
some new time limits to insure that the information was still on the
bus when read by the other devices.