S²I: IEEE P1285 Scalable Storage Interface


Much of the efficiency of moving data between storage and main memory is governed by the storage interface. IEEE P1285 Scalable Storage Interface endeavors to facilitate this process by providing a lightweight, but powerful, storage access protocol. Features are:

S²I Status

P1285 has passed initial sponsor ballot. A number of comments have been received and responses are being incoporated in a new document that will be re-circulated later this year.


Dave Bursky writes in the February 6, 1995 issue of Electronic Design pp 33-34 of S²I:

A proposed low-cost and high-performance storage interface promises to give designers a scalable and interconnect-dependent option for tying mass storage devices to a host system. The interface, now in draft form, is called the IEEE P1285 Scalable Storage Interface (S²I), is RAID- (redundant array of independent disks) and multiprocessor-friendly. It can supply those benefits by supplying disk drives with autonomous data transfer capabilities, and by taking advantage of the buffer RAM typically embedded by drive manufacturers in their disk drives for read-ahead caching and buffering incoming data.

Basically, what the new interface does is expose the drive's internal buffer to the outside world, allowing the host computer system to manage the drive's internal buffer space. The drive can also execute commands from system memory (or the drive's internal buffer). Those commands transfer data between the buffer, the media, and the system memory spaces.

Thus, the drive can access system memory directly, rather than use the slow, byte-serial interface traditionally employed by SCSI and IDE disk drives. As a result, the drive can fetch commands or transfer data at memory bus speeds, increasing the burst data rate past the 100 Mbyte/s mark with a 32-bit data bus operating at a clock frequency of 25 MHz.

The S²I draft standard can be used with almost any physical-level bus interface --- the peripheral component interconnect (PCI), the scalable coherent interface (SCI), the RamLink, or standard SRAM or DRAM interfaces. When used with one of these interfaces, the storage device attaches directly to the host systems bus' address and data paths. For example, if a PCI physical layer is implemented, S²I/PCI storage devices can be built to plug into a PCI socket on the host-system motherboard or adapter card.

The economies of scale in the PC marketplace also should drive the cost of S²I/PCI disk drives down to very competitive levels. On top of that, because the drives just plug into a PCI backplane, they can be configured to implement small RAID subsystems. With PCI-to-PCI bridge circuits, the size of the RAID subsystem can be expanded further. Moreover, the high bus throughput with 32- and eventually 64-bit PCI connections (132 and 264 Mbytes/s) makes the combination ideal for such systems as video/media servers, database servers, and other high-throughput applications. The S²I scheme also can be linked to SCI, thereby increasing the interface throughput up to 1 Gbyte/s.

To make this happen, however, storage-device manufacturers will have to re-think their designs --- no longer will the 8- or even 16-bit SCSI or IDE interfaces be usable. They'll have to replace them with address and data busses and a few control lines (see the figure). In addition, the disk drive won't be attached to the system via a long cable. The drive might just "plug-in" (like a pin-grid array package) to a daughtercard or directly onto the motherboard, or possibly use the very short (a few inches) controlled-impedance values. The appeal of the plug-in concept lies in the socketing scheme, which keeps the external loading very consistent.

How does the interface work? Each device has a command list that's set up by the host software driver in a part of the system memory that can be shared and accessed by the host or storage device. Onto that list are placed the commands that will subsequently be transferred into the storage device's buffer and then executed by the unit. Also, the command list might itself have been previously placed in the storage device's buffer and directly executed from there.

Each command-list entry contains a command field, modifier fields, a transfer-count field, a memory/buffer offset value, and a media address. The command field specifies the direction of the data transfer, the modifier field specifies specifies other options (such as when interrupts are sent), and the count field specifies the relative starting position in the memory or device buffer, while the media address specifies the starting position on the storage media.

Most of the commands defined in the proposed P1285 standard support the movement of data between shared memory buffer locations and the device's media. Other commands are also available to synchronize command execution and provide branching capabilities to execute other command entriesd after specified conditions (e.g., errors) are detected.

The bus-control portion of the storage device is responsible for accessing the host system's memory and controlling access to the shared system interconnect (such as the bus), if required. The command-processing portion of the storage device causes the device to read the next command from the associated command list and then begin executing the command.

Command-list entries can specify transfers to scattered lists of system-memory addresses and scattered device addresses. Special modifier bits indicate when requests can be reordered to improve throughput.

Each S²I is contained within a node and is visible through a set of memory-mapped addresses. The node contains ROM, a segment of memory-address space, and a segment of registers. The ROM identifies the storage device's S²I capabilities -- storage device parameters, architecture, part identifiers, etc. The memory address segment maps to the device buffer, while the register segment maps to the Special and Mover(n) registers.

Each Mover register (actually a bank or registers that are used to initiate, manage, and monitor the autonomous transfer of data between an attached device and shared (bus-accessible) memory. The Mover register bank is allocated 256 bytes of memory-mapped address space, and in that space, 128 bytes are defined by the standard, and the other 128 bytes are allocated for device-specific registers. The configuration and I/O driver software is thus simplified by using fixed-sized Mover registers. The configuration and I/O driver software is thus simplified by using fixed-size Mover registers. Extra registers (when needed) also can be located in a special portion of the register's address space. the predefined registers include those for power sequencing and event reporting, as well as those set aside for data-transfer capabilities.

Two versions of the proposed specification are being defined, with engineers from Philips Research Laboratories, Palo Alto, Calif.; Apple Computer Corp., Cupertino, Calif., and Quantum Corp., Milpitas, Calif., driving the definition of S²I.

One version is targeted for 32-bit bus interfaces and optimized for uniprocessor systems, while the other focuses on 64-bit bus interfaces and is optimized for multiprocessor systems (dubbed Beta and Gamma, respectively).

The scalability of the system, however, depends on the physical layer interface that's selected. Architecturally, thousands of drives can be plugged into the same bus. However, what does limit the number of drives is the bus loading of the interfaces, the amount of power available, and physical space requirements.

For more information, contact Dr. Martin Freeman at Philips Research at (415) 846-4329.


Draft 1.0 is available in Adobe PDF (1154K) and in Adobe PDF Gzip'd(687K) and in Postscript (1268K) and in Postscript Gzip'd (266K).
Chairman:       
Martin Freeman
Philips Research
1070 Arastradero Road
Palo Alto, CA  94304
PHONE: (408)617-4763
H/fax:   (650) 846-4309
EMAIL: martin@pmc.philips.com