The ubiquitous Small Computer System Interface (SCSI) standard is the peripheral bus of choice in the 1990s. SCSI, or formally ANSI X3.131, can be found in disc drives, CD-ROM drives, tape drives, stackers, serial port multiplexers and even high speed communications interfaces. SCSI is almost everywhere, being used in proprietary as well as industry standard equipment.

SCSI has taken the world, wiping out SMD, IPI and a large number of proprietary interfaces. This has occurred for some very good reasons, and this feature will examine in some detail the technical aspects of SCSI, with a focus upon SCSI bus and device robustness.

The ANSI SCSI Standard

When the first SCSI-1 standard emerged in the early 1980s, it was a very radical departure from the established technology of the day. This was a period when the market was dominated by either proprietary standards, both in disk and tape busses, or the now increasingly obsolete SMD (Storage Module Device) standard. Virtually all of these busses were built around the seventies philosophy of an intelligent controller board in the host, and a dumb disc drive which had to be told which cylinder to seek to and which sector to read. Virtually all of these busses used a split bus strategy, with a separate command/control interface, and a shared data interface.

SCSI was very different, as it used a shared command and data bus, and relied upon each device upon the bus to provide both buffering of data and the intelligence to manage itself. This was a major technological leap as many of the functions which had traditionally resided in the host controller were now shifted into the peripheral. Peripherals acquired an onboard controller and were responsible for managing their own state as well as negotiating access to the bus.

The first generation of SCSI devices were cumbersome and typically involved a separate SCSI interface controller board in the drive chassis, the controller then accessing non-SCSI devices, eg ESDI disks, or tapes via internal proprietary cabling. While the bits and pieces were not SCSI, the controller created the illusion of a box of SCSI devices to the host.

The following generation of devices saw the controller embedded in the device, thus providing for a very compact arrangement where disks and tapes connected directly to the SCSI bus.

By the mid 1980s, the draft SCSI-1 standard had taken hold in the industry, but equipment designers wanted more features and performance. ANSI therefore released the SCSI-1 spec (X3.131-1986), but proceeded concurrently to define the follow on SCSI-2 spec as well as a expanded Common Command Set (CCS) standard.

The SCSI-2 standard, which proliferated in the early nineties, saw the tightening of some areas in the SCSI-1 spec, the adoption of the CCS-4B spec and support for a range of performance enhancing options, which are not mandatory. The most important of these are Wide SCSI (16 or 32 bit), Fast SCSI (up to 10 MHz bus clocking) and Command Queueing. A SCSI device may be SCSI-2 compliant without having any of these options (ie SCSI-2 does not mean by default "fast" or "wide").

At this time SCSI-2 is the preferred interface for open systems, as it is widely supported, delivers good performance, is cheap due high volume production, supports diverse devices on a single bus, and allows for more robust device driver and utility design. The latter is because system programmers may focus all of their effort on a single interface, unlike in times past.

SCSI-2 - A Technical Overview

The central objective of the SCSI-2 standard, as stated in the document, is to "provide host computers with device independence within a class of devices". What this means, is that during operation a host need not distinguish between various types of device, eg disc, on the bus, because all it needs to know to access a block of data is the logical block address.

There are two perspectives from which we can view the SCSI bus, the first is the low level bus protocol or physical level and the second is the command/message format or logical level.

The SCSI bus protocol and signalling scheme is both a strength and a weakness of the standard. It is based upon a scheme of distributed access to a shared channel, which is contended for by each device. Once a pair of devices have negotiated access, they communicate by means of multiple byte messages or commands. The result of this communication may be a transfer of status information, a command to transfer data between the devices, or a data transfer.

To understand the physical level of the SCSI protocol we must look at the electrical interface and the bus protocol phases. The SCSI bus is an exercise in simplicity, using a set of shared data/address lines and a set of control signals. All signals use RS-485 style TTL-like drivers and receivers, and both ends of the bus are terminated with resistive networks which should match the electrical impedance of the bus cable and provide an electrical bias voltage for bus receivers. Since all bus lines are shared by all devices, and devices may attach at any point along the legal length of the bus, most signals are electrically wire-ORed active low. The standard allows for a cable length of up to 6 metres for single ended and up to 25 metres for differential buses, but does not guarantee operation at these lengths. The standard also does not guarantee that a full eight devices will operate on the bus, nor does it guarantee that the bus will achieve a full 10 MHz clock rate.

The cable impedance must be between 90 and 132 Ohms, and the standard specifies the cable lossiness, and differential propagation delay between cable pairs.

Each SCSI device has a unique address, termed a SCSI ID, and the bus data bits are used as ID bits during certain bus phases. SCSI ID may be 0 through 7, 7 by convention is usually reserved for the host. The SCSI bus may be in a number of legal phases (states) at any point in time. Each bus phase serves a particular purpose and all conforming SCSI devices know what to do when they enter a bus phase.

A typical SCSI bus transfer will see an idle bus transition to ARBITRATION, then SELECTION or RESELECTION, followed by a COMMAND, DATA IN/OUT, STATUS or MESSAGE IN/OUT transfer. At the lowest level, each byte of data transfered is controlled by handshaking of the REQ and ACK bus lines.

This is where the distinction between asynchronous and synchronous data transfers must be made. In asynchronous transfers, each byte of data transfered must be acknowledged with an ACK, before another byte can be sent by the other party. In a synchronous transfer, bytes may be clocked out in bursts while the handshaking signal is toggled, without having to wait for acknowledgements on a byte by byte basis. An offset parameter provides for flow control.

The differentiation between "fast" and "slow" SCSI is given by the speed at which the bytes are clocked out, a "slow" transfer will see data clocked out at speeds from as low as 2 MHz, asynchronously, whereas a synchronous "slow" transfer will run at 2 to 5 MHz and a synchronous "fast" transfer at 5 to 10 MHz. For purposes of comparison, a 4 kbyte block on a "narrow" 8-bit SCSI bus will take about 4 microseconds to transfer at 10 MHz, 8 microseconds at 5 MHz, 10.5 microseconds at 4 MHz and about 21 microseconds at 2 MHz.

The differentiation between "narrow" and "wide" SCSI is given by the width of the datapath of the bus. A "wide" bus may be 16 or 32 bits wide, effectively doubling or quadrupling the amount of data to be transfered per bus cycle. Running at 10 MHz, a 16 bit bus will transfer two 4 k blocks in 4 microseconds, and a 32 bit bus four blocks in the same time. The standard defines the byte ordering in the transfer.

Were we to put a logic state analyser on the bus and trace the activity, we would see first an idle bus, then a short burst of activity as the initiator starts a transfer, then some time later, a long (ie several microseconds) burst of activity as the target transfers the data. In most instances, the SCSI bus spends most of its time idle, not unlike a LAN.

The logical level of the SCSI protocol is defined by the COMMAND and MESSAGE set, which is very large and no doubt a delight for writers of SCSI device drivers. The extensive COMMAND set is a powerful tool for designers of SCSI devices, and provides many fields for optional or proprietary information.

The SCSI MESSAGE set is used to manage the state of the interface. Messages may be one byte, two byte or extended (multi-byte), and the standard recognises twenty eight different message codes, of which seven are most commonly used. These are COMMAND COMPLETE, DISCONNECT, ABORT, REJECT, BUS DEVICE RESET and IDENTIFY, the meanings of which should be intuitively obvious. The console messages you are likely to see with a misbehaving bus are usually a subset of these, when the device driver starts protesting about the bus state.

The messaging mechanism is also used after boot to negotiate, on a device by device basis, wide transfers using the WDTR (Wide Transfer Request) message, and fast transfers using the SDTR (Synchronous Data Transfer Request) message, which contains a field for data transfer period. Defaults are typically narrow/slow, and host device drivers and controllers must support the feature for it to be used.

The SCSI COMMAND set is used to control the device rather than the interface. The COMMAND set is so large because it is designed to accommodate a broad range of different device types, be they discs, tapes or other. Each class of device will need a different COMMAND set.

Each COMMAND is implemented as a group of bytes, termed a Command Descriptor Block (CDB). Typical CDB sizes are six byte, ten byte or twelve byte. Each CDB contains an operation code defining the task to be performed, a Logical Unit Number (LUN) specifying the entity within the device (usually only LUN=0 is used), the parameters for the COMMAND, such as a logical block address and a transfer length, and finally a control byte which defines device behaviour under some conditions. The CDB wholly describes the COMMAND to be executed, and is specific to each class of COMMAND and device.

We are now in the position to describe a typical SCSI bus operation, in this instance a read operation by a host against a disk drive. The host is the initiator and arbitrates to grab the bus. It then SELECTs the drive via its SCSI ID, and does a MESSAGE OUT and IDENTIFY to select the LUN within the device. The target (drive) then switches to the COMMAND phase and transfers the command descriptor (CDB) from the target. The target interprets the contents of the CDB and finds it to be a READ command. Because it needs to seek out and read the block, it altruistically releases the bus with a DISCONNECT message so other devices can use it during the 20 milliseconds or so it takes to find the block.

Once the block is found, assuming the bus is free, the target (drive) arbitrates for the bus, RESELECTs the initiator (host), does a MESSAGE IN and IDENTIFY to specify the LUN, and then switches to the DATA IN phase and transfers the data block to the host. It then switches to the STATUS phase, sends a GOOD status, switches to MESSAGE IN phase, transfers a COMMAND COMPLETE message and then releases the bus.

As is apparent, a lot of bus activity takes place when a block of data is transfered. This is accomplished in part by the controller chips on the host and the disc drive, the device driver code on the host, and the embedded controller firmware running on the drive. For the bus to perform properly, all of the state machines in this multilayered scheme must behave properly.

In addition to a wide range of READ and WRITE type commands, the SCSI command set provides some interesting features for management of devices as well as setting of transfer parameters. A number of commands are worth closer scrutiny.

Up to 64 pages may be so extracted from a device, covering virtually all device parameters and providing for mandatory and proprietary parameters. Fields in these pages allow for read and write cache enabling and disabling, cache prefetch policy, formatting parameters, error recovery parameters, spindle synchronisation setup and a wide range of other parameters. The popular public domain _scsiping_ tool does a MODE SENSE command on a drive and interprets the page contents.

Not all of the commands described here are supported by all devices, as the SCSI standard is quite permissive and allows many facilities to be optional. Should you be planning to write a tool to exploit the extra capabilities you don't usually see, there is no substitute for the drive manufacturer's SCSI command set specification.

SCSI Robustness

In the author's experience the SCSI bus can be remarkably tolerant of abuses by both manufacturers and users, but even it can get into difficulty if too many things are at the edge of compliance. Most problems with SCSI busses can be divided into hardware problems with the bus cabling and interfaces, and protocol problems with specific controller chips, firmware and host device drivers.

The greatest difficulty with diagnosing SCSI problems is identifying whether the problem is due to hardware issues, or protocol issues involving firmware and the host operating system. Very often the symptoms can be very similar, and only spending time with a logic state analyser and SCSI protocol disassembler will yield the full truth. Swapping drives and cables may resolve the problem but may also mask it. The resilience of the basic SCSI protocol often means that several things may be out of spec on the bus, but it will still "sort of function". Thus the cause of the fatal errors may or may not be easy to isolate.

SCSI is a very complex protocol, particularly at the message and command level. This provides the capacity to accommodate a wide range of devices, but it also creates the potential for incompatibility between host device drivers and drive firmware. A cheap and nasty test for this type of problem is to try the drive on a different host with a different SCSI controller chip and operating system. If the drive behaves itself you may have this kind of problem. Some combinations of host controller chips and drive controller chips simply don't like each other.

Whilst protocol and firmware problems are relatively infrequent, cabling problems are the plague of the industry, moreso with the proliferation of 10 MHz fast devices. The root cause of these problems lies in transmission line theory. What transmission line theory tells us is that an electrical pulse injected into some point along a transmission line will propagate away in both directions, until it hits the ends of the transmission line. If the ends are terminated properly with a matching impedance, the pulses are absorbed. If the ends are not properly terminated, part or all of the pulse is reflected back. In the extreme (theoretical) case of a lossless unterminated line, these pulses would bounce back and forth forever. The problem worsens with increasing bus speed and bus length.

A poor little SCSI controller chip may not be able to tell the difference between a real signal or a bounced reflection, or the real signal may be corrupted by a reflection arriving at the wrong time. Either way it is likely to become confused about the bus state and thereafter, anything may happen !

There are four common causes of impedance mismatch on SCSI busses. The first is poor termination. A terminator may simply be mismatched to a cable, the greater the mismatch, the worse the reflection problem. Terminators may also be in places other than the ends of the cable chain.

The second cause of mismatches is inhomogeneous cabling in a chain, where cable A is from manufacturer X, cable B from Y and so on. Each cable has a different impedance because of manufacturing tolerances in materials, geometry, connectors and any other parameter which affects impedance. A bus signal travelling in a cable of 90 Ohms hitting a cable of 130 Ohms will partially reflect. Mixing and matching cables is a recipe for trouble.

In practice many sites inherit these problems, as they add new drives and new cables from different sources. A some point things break, usually when a fast drive is added to a chain of older slow devices, or the cable length has increased such that a particular standing wave pattern of reflections for a particular bus phase happens to place an anti-node on a particular drive connector.

The third cause of mismatches is the internal stub of cabling inside a drive enclosure, which is likely to have a different impedance to the cables connecting the drives. Drive capacitive loading on enclosure cabling can also alter the effective impedance of the cable segment (increasing the reactive component).

The fourth cause is due inappropriate printed circuit wiring on host controller boards or drives, if it is too long it will add capacitance as in the previous instance. The author recalls one instance where a host adaptor added 30 pF of capacitance to a termination, thereby killing bus operation at any cable length exceeding two metres. The fix was a specially designed compensating terminator, until the board could be redesigned.

A good rule of thumb with fast SCSI is to recable the whole chain using cables from a single batch, get terminators which are guaranteed to match the cable type, testing them doesn't hurt either, and be cautious with enclosures and avoid the really cheap and nasty ones.

There are alas, two other gremlins to be contended with here. The first is that some controller chips simply do not like long cables. Devices using such chips simply won't behave if the cable exceeds some length. Should you be saddled with such a device, put it on a short (eg < 1 metre) cable on a chain of its own, or make sure it is only ever used as a local internal drive in a machine, on a private SCSI bus.

The second gremlin is the possibility that the terminator is being improperly supplied with +5V electrical power, or not powered at all. The terminator power is used to bias the idle bus controller chip receivers to a logical "1", if it is out of spec the noise margins for every device on the bus can be eroded simultaneously, thus aggravating any problems which may exist due cable-cable and cable-terminator mismatches.

It is worth restating that the SCSI standard does NOT guarantee that any given combination of SCSI devices and cable will operate to full "fast" transfers rates, or that it will operate with up to eight (the logical maximum allowed by the protocol) devices on the bus, or that it will operate to the nominal cable lengths stated in the standard (Section 4.2). If you can make it work to its full potential, you have done well for yourself, but you can still have a perfectly legal SCSI chain which will not run at "fast" speed with more than say two devices on a 2 metre chain. What sorts the men from the boys in this game is the ability to extract the best performance from the standard with the devices on hand.

Where cabling robustness is an ongoing problem, system managers should seriously think out about using differential SCSI, which can deliver better bus signal quality where used properly. The drawback is that a differential controller board and differential drives will be required, incurring a major cost penalty.

Summary

The SCSI bus is a versatile but complex interface, which can deliver good performance and reliable service when treated with respect. In practice, quality of implementation in SCSI products is critical to achieving both reliability and performance, and quality can vary dramatically in hardware, firmware and host operating systems. Success when integrating SCSI products comes from treading cautiously and avoiding predictable problems, such as those resulting from cabling. The expectation that full nominal bus performance is achievable with arbitrary components is mythology which is not supported by experience or by the SCSI standard.

Getting the best performance out of SCSI devices and host interfaces will be the subject of a future article.

Diagram 1. SCSI PIN ASSIGNMENTS (see hard copy)

The ANSI X3.131 SCSI-2 standard recognises two classes of connector for the narrow 8 bit bus and one for the wide 16 bit bus. The narrow connectors are divided into high density and low density connectors. The basic pinout arrangement for high density and low density connectors is very similar, involving a two row 25 or 32 pair arrangement.

Narrow (8 bit wide) SCSI always uses a 50 pin connector, regardless whether the bus is single ended or differential. High density connectors use a 1.27 mm (0.05") pitch, and low density connectors a 2.54 mm (0.1") pitch. The low density connector may be a dual row header or a Centronics style connector.

Wide (16 bit wide) SCSI always uses a 68 pin connector, regardless whether the bus is single ended or differential. High density connectors use a 1.27 mm (0.05") pitch, and there is no low density connector recognised.

Standard practice is to use male connectors on cables and female connectors on equipment panels.

Cables may be flat ribbon, twisted pairs, or flat ribbon with embedded twisted pairs for differential use. Flat ribbon is not recommended for differential use.

The standard explicitly states that cables of different impedance should NOT be mixed in a single chain, and states that "tradeoffs in cable lengths, shielding effectiveness, the number of loads (ie number of devices on the bus - author), transfer rate..." may be required to achieve satisfactory operation. The SCSI standard does NOT guarantee that the full 6 metre (25 metre differential) cable length may be achieved, nor does it guarantee that eight (8) devices will operate in a single chain, or that an arbitrary combination of devices and cables will run at "fast" transfer rates.

The allowable cable impedance is between 90 and 132 Ohms. The nominal terminator impedance is between 100 and 132 Ohms. Typical passive terminators are 132 Ohms +/- 5%, and the standard recommends a cable impedance closer to the top of the range.

See hardcopy for connector faces.

Diagram 2. SCSI Terminator Arrangements (see hardcopy Fig 4-9a, 4-9b, 4-10)

The SCSI-2 terminator arrangement is very permissive. A passive 132 Ohm and an active 110 Ohm terminator arrangement are both legal, but the passive termination will usually produce a certain amount of impedance mismatch with typical cables. It is worth noting that the standard does not properly address high frequency performance of the terminator design, and a legal terminator could actually produce significant mismatch at the 2nd, 3rd and 4th harmonics of the bus clock rate. The preferred choice should be an active terminator with a 75% overlap between the +5V and ground planes on the terminator, to ensure best possible high frequency performance.

Diagram 3. SCSI ID Bits (see hardcopy spec Page 31)

Diagram 4. SCSI Bus Cabling Arrangement and Impedance Profile (see hardcopy)

Diagram 5. SCSI Bus Logical Level Phase (State) Transitions (see hardcopy)

Diagram 6. SCSI Command Format - 6 Byte (see hardcopy)