History And Background

In 1980 a company - Shugart Associates - came up with a new idea of an open bus to ease the life of system integrators (and to boost their sales). On this bus (cable) there was one controller (specific to the computer type) and some disks, possibly from different vendors, although Shugart Assiciates designed the bus primarily for their own needs. They wanted to be able to sell their hard drives into the markets of various computer manufactures like DEC or Wang. Up to then each computer manufacturer usually had a special and proprietary interface for each of his disks. For Shugart this meant building a lot of drives with different interfaces - definitely not inviting for a hard drive manufacturer. (They had not only hard disks - they had other stuff, too. And the floppy connection we use now also is a product of their work - the quirks and difficulties of today were added by IBM when they introduced their PC. They brought the twist into the cable and thus prevented that ever more than two floppies can go onto the same cable. (Shugart's original could do four! The only "difficulty" was that there were two jumpers to be set according to the desired ID of the floppy drive.) But what damage the PC caused from the very beginning is not a subject of this article.)

After some succesful trial period Shugart proposed this bus, named SASI (Shugart Associates System Interface) to the ANSI commitee. As no company names are allowed in names of standards they changed it to SCSI (Small Computer Systems Interface) first. After some minor modifications it became an official standard. But it took time for it to lift off. Only almost one decade later the industry realized the potential of the original idea and since the beginning of the nineties the standard is updated in ever shorter periods to include the latest technologies. Working on it now are those big players that are involved in the computer and storage market. No other bus can connect such a variety of devices that the SCSI bus can. (But what happened to the original inventor? Gone and forgotten? You find the answer at the end of this article.)

Although EIDE or ATAPI interfaces to hard drives and CDROMs dominate the home computer market, SCSI is the choice of the upper class. Sure, the SCSI hardware is a little bit more expensive than the EIDE chips but the advantages quickly outgrow the higher investment. Everyone, who ever lost some hours with unsuccessfully trying to make two hard drives from different vendors work together on the IDE bus, will appreciate the easyness of a SCSI configuration. Not, that there aren't any compatibility problems anymore with SCSI - some funny configurations do refuse to work even with SCSI-2, but this is the exception and not the rule - the gain is the added flexibilty. With up to 15 devices on one cable the SCSI solution saves precious space in a computer housing. And if someone needs other fast peripherals (scanners or tapes for example) there is virtually no way around SCSI.

Advertisement

Emprisoned by ATAPI? Escape With SCSI! Meet SCSI and you will fall in Love!

Get more info about our courses for SCSI concepts from our partner Onsite Computer

But with these advantages for the user come some challenges for the people who must keep a sometimes pretty complex and diverse system running despite of significant configuration changes. And planning a new installation is a task on it's own when a user wants maximum performance within given restrictions on space or price. A basic knowledge of the SCSI concepts and some configuration guidelines are very good helpers here. Although some practical experience with "hooking" together SCSI systems will do the job for simple tasks an insight into the "hows" and "whys" is a must for more complex systems.

The SCSI Bus

The SCSI bus in it's classical form transfers data bit parallel on a copper cable. The original version (now called SCSI-1) used 8 data lines and one parity line for that. SCSI-2 allows for wider busses, but only the 16 bit version is used today. While the SCSI-1 required all transfers to use an asynchronous handshake SCSI-2 allows much faster data transfers by using some synchronous clocking, combined with a FIFO in the receiving device. But even with SCSI-2 all information that is necessary to configure the bus and to manage the actual data transmissions is transferred in that asynchronous mode. This ensures that devices of different generations and speed can be operated on the bus. SCSI-3 added 3 serial interfaces to the SCSI specification: Serial Storage Architecture (SSA) from IBM, FireWire from Apple/Motorola and the FibreChannel from the data comm world. The "old" parallel interface is now called "SCSI Parallel Interface" (SPI). The parallel versions now allow for 80MB/s data transfers over cables as long as 12m without additional buffers. The serial versions differ in their speed and cable length. The fastest and further reaching is the FibreChannel that can bridge kilometes at data rates of 1GBit/s and beyond. A clear winner in the medium performance market is the FireWire. It is simple and cheap, but with data rates beyond 400MBit/s it still is reasonably fast. It's advantages lies in the fact that it can combine slow (some MBit/s) and fast devices on the same bus. Currently mostly digital cameras use the FireWire, but one can expect to find it almost everywhere where USB (Universal Serial Bus, another serial bus for PCs) does not give sufficient performance.

Does the definition of 4 different "standards" for SCSI mean that someone will be forced to throw out the old equipment to get the advantages of the new specs? No, not at all! One can still (and in the foreseeable future) combine "classical" devices with the most modern ones. To help designers to implement compatible solutions the spec for the parallel interface was rewritten (but only the way how it is presented and specified, not the content). The parallel specification now clearly separates the different layers of the software (on the controllers and the devices), similar to the ISO OSI concept, although not strictly adhereing to it. This makes it possible, even relatively simple, to design and build converters that convert transparently between the different media types (parallel to FireWire to FibreChannel and whatever the market will need). So, how does the SCSI bus work in general?

Phases

First, independent of the media used (parallel cable, FibreChannel, FireWire) the operation is defined to occur in "phases" whose possible sequences are defined in the spec. Whenever one device on the bus (the serial interfaces are physically not busses, but logically with respect to the levels discussed in the following) wants to talk to some other it must notify this device about it's intention and the operation requested. This is done by exchanging messages and sending/receiving commands/statuses. But one should clearly distinguish between both groups! Although on the parallel cable both look very similar, there is a clear border between them. The former are there to ensure the "how" of a data transfer and the latter to specify the "what" (what is to be done). Messages sent on the parallel bus (and only there), for example, define the width of the data transfer to be done between both parties. If one of the partners is a 16 bit device and the other is only 8 bit then they will agree on an 8 bit transfer between them. Other messages (used on the serial busses, too) are used to agree on the amount of data that can be sent to the receiver without waiting for an acknowledge. This "window" allows to sustain high transfer rates despite of a relatively long turnaround time.

A typical sequence on the parallel cable could look like this (the arbitration is necessary here, as more than one device may want to use the cable (bus) at the same time. For the serial interfaces it is dependent on the type implemented. FibreChannel-Arbitrated Loop uses arbitration, too):

1. Free Phase
   All devices continously monitor the bus to determine when an ongoing transfer is done and the previous owner of the bus has relinquished it. Only when the bus is free a new transfer may be initiated, of course.
2. Arbitration Phase
   Each device that wants the bus activates a specific data line, all together a line called "BSY" (the physical signals are of wired-or type, so this does not lead to a conflict). As all devices on the SCSI bus are required to have an unique ID no conflict can arise in the sense that two devices will activate the same data line. Each device simply activates that data line that has the same number as it's ID. So, device with ID=3 will activate D3 and device with ID=8 will activate D8. And each device wanting the bus checks the other data lines to see if a device with higher priority wants the bus, too. After a defined period of time all devices have checked who wants the bus and know which of them has the highest priority. This devices is the winner of the bus now.

   The priorities are (high to low): 7..0,15..8. Yes, the IDs above 7 have a lower priority than 0! This is done because 8 bit devices do not have 16 data lines, but they shall still be able to get the bus. Because of this priority arrangement they even do not need to see any active data line beyond their 8. A simple but wise definition.

   Imagine what the PC could have been if Microsoft would have defined the upmost 384kB are the BIOS space and not the lowest 640kB are memory. We could easily plug gigabytes of memory into the PC and it would use them. But they were too stupid then we must live with ridiculous 640kB usable in a machine with 64MB or more memory for a long time. And it was only Microsoft who defined their address range in such a stupid way. Many years before Microsoft came into existence there were other computers and they did not have that problem.

3. Selection Phase
   The winner of the bus selects the partner to talk to by activating the data line corresponding to the ID of the partner. Concurrently it will activate the data line with it's own ID. That makes it easier to implement a mechanism called "deselect-reselect", discussed later. As all losers in the arbitration phase have gone off the bus (they drive no line at all now) the winner is the only one to drive BSY at this time. To indicate to the desired partner that the current state of the data lines is really meant to be a selection the winner activates a line called "SEL" and afterwards releases BSY. The selected device will indicate that it accepts the selection by activating BSY. The winner, seeing BSY being activated after it released it, knows that the device is there and prepared to communicate. If the winner should not see BSY being activated within some period it determines that the device is not present and release the bus (by dropping BSY).

   Important! As now the selected device is the only one that activates BSY it controls the bus and all transactions on it. A controller has no but one chance to affect the actions to follow. This single chance is to force a specific phase to be the first after this selection phase. It does this by activating a line called "ATN". This line may be driven by controllers only. If activated it forces a so called "MSGOUT" phase after the completion of the current one. In that phase the current device will retrieve a message from the controller. (IN and OUT are defined from the viewpoint of a controller, so OUT goes from the controller to the target.) In this example we will asume that the winner is a controller and it asserts ATN in this selection phase. So the next phase to follow is a

4. Message Out Phase
   As said above, the selected device, not the original winner, controls the bus after the selection until the bus becomes free again. So a controller usually asserted ATN during the selection phase to force this Message Out Phase to happen. The message exchanged here is the IDENTIFY message. It identifies mainly two things: First, whether the controller supports the deselect-reselect mechanism and second, to which logical unit of the addressed device it wants to talk to. (Each device can have up to 8 logical units.) Now both know to whom to talk to and the real work can be done. The next thing is to transfer a command from the controller to the target. This is done in a
5. Command Phase
   Here a command with all it's parameters is transferred. Typical lengths of command blocks are 6 to 10 bytes. The first byte determines the actual command to execute with the remainder being mostly the parameters, like starting block and number of blocks to read. As some commands require a significant amount of time to be executed (like seeks of a disk) the device now has the choice to release the bus to others or to hold it until it finished the command. Let us assume, that the device chooses to free the bus and deliver the requested data later. It notifies the controller by entering a
6. Message In Phase
   The device sends a DISCONNECT message to the controller and releases the BSY line. This marks the bus to be free. Other devices and controllers may now start to arbitrate for it again. After our device has completed (at least part of) the command it will arbitrate for the bus. After it won the bus (the phases are the same as described above with the exception that the selection phase now is called "reselection" phase. The distinction is minor and we do not go into detail here. So, after winning the bus and selecting the controller that sent the command to our device it will do a
7. Message In Phase
   again. In this phase it will notify the controller about the fact that it is reconnecting to send at least part of the data requested. After that it will start to transfer the data in a
8. Data In Phase
   This example is one of a read request by the controller, so the device will send data to the controller, thus the Data In Phase here. The device will send the data with the maximum speed that both of them can handle and using as much data lines as both have implemented. Only in the data transfer phases the maximum speed is achievable. As mentioned above, all other phases use the slower asynchronous mode. But messages and commands are very short, compared to data transfers, so they do not slow the bus down too much.

   If the device can supply all the data needed in one chunk it will terminate the connection after the last byte transferred. If it needs more time it will disconnect and reconnect at a later time again. This disconnect/reconnect works the same way as described above so it will not be repeated here. We assume that the device has fulfilled the whole request. So it tells the controller about any problems that may have arisen in a

9. Status Phase
   A status is the answer to a command. So the information sent to the controller here is the result of the execution of the command itself. Hopefully there were no errors and the contoller will get a positive message back. But if the controller requested some data beyond the capacity of the device it will tell that the controller now. After the controller was told what the device thought about the command the device will terminate the whole transaction by entering a
10. Message In Phase
    Ths phase actually is a series of Message In Phases. For the purpose of easy explanation the multiple phases are collapsed into one single phase. This is legal for our purposes, as we do not want to go into too much detail in a short introduction like this. The device informs the controller about the status of the transmission and other media or protocol releated issues here. It is similar to the status sent before, but the scope is not the command but rather the transmission itself. If a parity error should have occurred it is relayed by a message, not by a status. After the transmission of all the messsages the device will release the bus by negating BSY and a new transaction can be intitiated.

The above example is a little bit simplified, but it shows the basic principles of the SCSI bus. It used the parallel interface for demonstration purposes and because the parallel interface is still the most common one. With the serial interfaces the distinction between messages and commands/statuses is even more expressed, as the former are generated and exchanged by/between the media interfaces used and the latter by the real devices on the bus. Imagine a constellation of a computer with a parallel SCSI adapter that is connected to a box that converts the parallel bus to FireWire. At the other end of the FireWire cable there is (in this example) a device with a native FireWire interface. Clearly, the messages exchanged to make this configuration will involve other things than on a parallel cable, but their intention will be the same: Ensure that both endpoints can talk to each other in a reliable way. The endpoits will use the underlying path to transfer commands, data and status.

This short introduction cannot deal with all aspects of the SCSI bus in it's different flavours. But hopefully it gave an idea of how the things work there. For more information, either buy a good book or attend a course. Don't try to understand the SCSI-3 specs unless your life depends on it or you feel a masochistic attitude taking control of you. It is more suitable to brain damaged mathematicians than to engineers.

And now, finally:

The answer to "What happened to Shugart Associates" is: Shugart Associates changed their name to Seagate (with Al Shugart still the CEO in 1998!).