SCSI Parallel Interface


The SPI is most commonly called the SCSI bus. Chapter 1, "Overview of Storage Networking," purposely refers to the SPI as the SCSI bus for the sake of common terminology. Chapter 2, "OSI Reference Model Versus Other Network Models," introduces the more accurate term SPI, which is used in this and in all subsequent chapters. The SPI does not enable modern storage networking per se, but it did shoulder the burden of SCSI transport for many years before the mainstream adoption of open systems storage networks. As such, this trusty technology established many of the criteria by which we judge modern open systems storage networks. We can summarize those criteria as:

  • High bandwidth

  • Low latency

  • No jitter

  • Inherent in-order delivery of frames and I/O transactions

  • Low probability of dropped frames

These criteria are easy to meet when designing a new network technology for small-scale deployments with only one application to transport. However, the modern business climate demands efficiency in all areas, which inevitably leads to infrastructure consolidation. Meeting all of the SPI's legacy requirements in a converged network environment can be quite challenging and complex. So we include a brief discussion of the SPI herein to ensure that readers understand the legacy requirements.

The Right Tool for the Job

The simplicity of the SPI relative to other network technologies is the primary reason that so many people fail to recognize the SPI as a network technology. Indeed, the SPI is a network technology, albeit localized and of very small scale and limited capability. The SPI was designed to perform a limited set of functions in a specific environment. Traditionally, a SCSI storage device (target) was used by a single host (initiator) and was deployed inside the chassis of the host or in a separate chassis located very near the host. The host might have used multiple SCSI storage devices, but the total device count generally remained low. The short distance requirements, combined with the low number of attached devices, allowed a simple interconnect to meet the needs of the SCSI protocol. Because SCSI was the only application using the interconnect, no other requirements needed to be considered. Though the SPI might be simple in the context of other network technologies, the latter versions are impressive engineering works in their own right.

SPI Throughput

As is true of most network technologies, the throughput of the SPI has improved significantly since its inception. Four factors determine the maximum supported data transfer rate of each SPI specification. These are data bus width, data transfer mode, signal transition mode, and transceiver type. There are two data bus widths known as narrow (eight bits wide) and wide (16 bits wide). There are three data transfer modes known as asynchronous, synchronous, and paced. There are two signal transition modes known as single transition (ST) and double transition (DT). There are four transceiver types known as single-ended (SE), multimode single-ended (MSE), low voltage differential (LVD), and high voltage differential (HVD). All these variables create a dizzying array of potential combinations. SCSI devices attached to an SPI via any transceiver type always default to the lowest throughput combination for the other three variables: narrow, asynchronous, and ST. Initiators must negotiate with targets to use a higher throughput combination for data transfers. Table 3-1 summarizes the maximum data transfer rate of each SPI specification and the combination used to achieve that rate. Because the SPI is a parallel technology, data transfer rates customarily are expressed in megabytes rather than megabits. Though the SPI-5 specification is complete, very few products have been produced based on that standard. Serial attached SCSI (SAS) was well under way by the time SPI-5 was finished, so most vendors opted to focus their efforts on SAS going forward.

Table 3-1. SPI Maximum Data Transfer Rates

Specification

Common Name

Transfer Rate

Negotiated Combination

SPI-2

Ultra2

80 MBps

Wide, Sync, ST, LVD, or HVD

SPI-3

Ultra3 or Ultra160

160 MBps

Wide, Sync, DT, LVD

SPI-4

Ultra320

320 MBps

Wide, Paced, DT, LVD

SPI-5

Ultra640

640 MBps

Wide, Paced, DT, LVD


Note

A 32-bit data bus was introduced in SPI-2, but it was made obsolete in SPI-3. For this reason, discussion of the 32-bit data bus is omitted.


The SPI consists of multiple wires that are used for simultaneous parallel transmission of signals. Some of these signals are used for control and operation of the SPI, and others are used for data transfer. The set of wires used for data transfer is collectively called the data bus. References to the data bus can be confusing because the data bus is not a separate bus, but is merely a subset of wires within the SPI. The data bus also can be used to transfer certain control information. Use of the data bus is regulated via a state machine. An SPI is always in one of the following eight states (called bus phases):

  • BUS FREE

  • ARBITRATION

  • SELECTION

  • RESELECTION

  • COMMAND

  • DATA

  • STATUS

  • MESSAGE

The COMMAND, DATA, STATUS, and MESSAGE phases use the data bus, whereas the other four phases do not. The COMMAND, STATUS, and MESSAGE phases always operate in narrow, asynchronous, ST mode. The DATA phase may operate in several modes subject to initiator/target negotiation. The transfer rates in Table 3-1 apply only to data transfer across the data bus during the DATA phase. Data can be transferred across the data bus only during the DATA phase. Control information can be transferred across the data bus only during the COMMAND, STATUS, and MESSAGE phases. Each DATA phase is preceded and followed by other phases. This is the reason some references to the SPI's throughput describe the maximum transfer rate as a burst rate rather than a sustained rate. However, the intervening phases are the logical equivalent of frame headers and inter-frame spacing in serialized network technologies. During the BUS FREE, ARBITRATION, SELECTION, and RESELECTION phases, the data bus is not used. Those phases transfer information using the control wires of the SPI.

A closer analysis of the SPI's data transfer rate is possible. However, given the SPI's declining importance in modern storage networking solutions, further analysis is not germane to this book. Detailed analysis of data transfer rates is provided for Ethernet and Fibre Channel in subsequent sections.

SPI Topologies

As previously stated, the SPI operates as a multidrop bus. Each attached device is connected directly to a shared medium, and signals propagate the entire length of the medium without being regenerated by attached devices. The device at each end of the bus must have a terminator installed to prevent signal reflection. All intermediate devices must have their terminator removed or disabled to allow end-to-end signal propagation. Each device uses the data bus for both transmission and reception of data. Moreover, there are no dedicated transmit wires or dedicated receive wires in the data bus. There are only data wires. Each device implements a dual function driver per data bus wire. Each driver is capable of both transmission and reception. This contrasts with other technologies in which separate transmit and receive wires require separate transmit and receive drivers in the attached devices. In such technologies, the transmit driver of each device is connected to the receive driver of the next device via a single wire. The signal on that wire is perceived as transmit by one device and as receive by the other device. A second wire connects the reciprocal receive driver to the reciprocal transmit driver. Figure 3-8 illustrates the difference.

Figure 3-8. SPI Common Drivers Versus Dedicated Drivers


The data bus implementation of the SPI makes the SPI inherently half-duplex. Though it is possible to build dual function drivers capable of simultaneous transmission and reception, the SPI does not implement such drivers. The half-duplex nature of the SPI reflects the half-duplex nature of the SCSI protocol. The SPI was designed specifically for the SCSI protocol, and the multidrop bus is the SPI's only supported topology.

SPI Service and Device Discovery

The SPI uses a device-oriented approach. When an SPI is initialized or reset, the initiator discovers attached devices by sending a TEST UNIT READY command to each address in sequential order. Because the SPI address space is very small, this works well and avoids the complexity of a central registration facility. Name resolution is not required because device names are not implemented by the SPI. Address resolution is not required because the SPI supports only OSI Layer 2 addressing. The initiator then sends, in sequential order, an INQUIRY command to each device that responded to the TEST UNIT READY command. Each device response includes the device type (direct access, sequential access, enclosure services, and so on), the medium type (removable or non-removable), the version number (SPC, SPC-2, or SPC-3), the supported address space (8 or 16) and indicators for support of protocol options (for example, synchronous data transfers and hierarchical Logical Unit Numbers [LUNs]). A response may include optional information such as manufacturer name, hardware model number, or other information. After probing each target device, the initiator issues a REPORT LUNS command to each target device to discover the existence of LUNs. SCSI I/O operations can occur after all LUNs have been discovered, but the initiator may choose to issue additional discovery or configuration commands before beginning I/O operations.

Note

The SPI supports multiple initiators, but such a configuration is very rare in the real world. Thus, a single initiator is assumed in all SPI discussions in this book unless otherwise stated.





Storage Networking Protocol Fundamentals
Storage Networking Protocol Fundamentals (Vol 2)
ISBN: 1587051605
EAN: 2147483647
Year: 2007
Pages: 196
Authors: James Long

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net