1、IEEE Std 1285-2005IEEE Standard for Scalable StorageInterface (S2I)I E E E3 Park Avenue New York, NY10016-5997, USA22 March 2006IEEE Computer SocietySponsored by theMicroprocessor and Microcomputer Standards CommitteeIEEE Std 1285-2005(R2010)Recognized as an American National (ANSI)IEEE Standard for
2、 Scalable Storage Interface (S2I)SponsorMicroprocessor and Microcomputer Standards Committeeof theIEEE Computer SocietyApproved 29 December 2005Reaffirmed 28 June 2011American National Standards InstituteApproved 22 September 2005Reaffirmed 8 December 2010IEEE-SA Standards BoardAbstract: A scalable
3、interface between mass-storage devices and controlling hardware/software is specified in thisstandard. The interface is optimized for low-latency interconnects, and assumes that the processor/controller and thestorage device can often be co-located on the same printed-circuit board. The interface ca
4、n also be used with longer-distance bus-like interconnects, including (but not limited to) IEEE Std 1394-1995 Serial Bus and IEEE Std 1596-1992 Scalable Coherent Interface.Keywords: controller, mass-storage, storage interfaceThe Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, N
5、ew York, NY 10016-5997, USACopyright 2006 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 22 March 2006. Printed in the United States of America.IEEE is a registered trademark in the U.S. Patent +1 978 750 8400. Permission to photocopy portions of any ind
6、ividual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Copyright 2006 IEEE. All rights reserved.iiiIntroductionThis introduction is not a part of IEEE Std 1285-2005, IEEE Standard for Scalable Storage Interface (S2I).Technology is now enabling the
7、 miniaturization of non-volatile storage units such as magnetic disk drivesthat can now be directly mounted on printed circuit boards. Existing cable-type storage interfaces, developedto span long distances, are not cost-effective for these small packages. The Scalable Storage Interface (S2I)is inte
8、nded to provide a simpler interface for “in the box” applications.Recognizing the need for leverage across product families, the S2I interface maintains a generalized DMAtransfer model, while leveraging previous related standards (IEEE Std 1212.1-1993). Key concepts fromIEEE Std 1212.1(such as mailb
9、ox-based status reports) are leveraged, while attempting to simplify thecommand-entry delivery process based on experiences from IEEE 1212-related bus standards.Although intended to support storage-device interfaces, the S2I interface defines a scalable DMAarchitecture that is applicable to a wide r
10、ange of input/output (I/O) devices and network interfaces.Implementing a largely physical-layer independent interface allows the S2I definition to be used with a widerange of interconnect technologies. Implementing a largely device-independent interface allows new (andsurprisingly different) storage
11、 devices to be supported in the future. There is also the possibility of simplify-ing system software since one architecture can be leveraged across different classes of I/O devices.As the work on this standard progressed, Martin Freeman stressed the importance of using a RAM-likeinterface to levera
12、ge existing industry-standard buses. Chris Hamlin emphasized the need to provide asimple disk-attach interface. Andy Hospodor helped us better understand disk-drive requirements. RichardWilmont helped define the power-management structure. Mike Wenzel provided a detailed review of sharedlist-handoff
13、 variables, to ensure correctness in the presence of read/write timing hazards.Notice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL:http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata
14、periodically.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/in-terp/index.html.PatentsAttention is called to the possibility that implementation of this standard may require use of subject mattercovered by patent rights. By publicat
15、ion of this standard, no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifyingpatents or patent applications for which a license may be required to implement an IEEE standard or forconducting inquiri
16、es into the legal validity or scope of those patents that are brought to its attention.ivCopyright 2006 IEEE. All rights reserved.ParticipantsThe following is a list of participants in the IEEE Project 1285 Working Group. Voting members at the timeof publication are marked with an asterisk (*).Marti
17、n Freeman,Chair*Andy Hospodor,Vice-chair*David V. James,Editor* The following members of the individual balloting committee voted on this standard. Balloters may havevoted for approval, disapproval, or abstention. When the IEEE-SA Standards Board approved this standard on 22 September 2005, it had t
18、he followingmembership:Steve M. Mills,ChairRichard H. Hulett, Vice ChairDon Wright,Past ChairJudith Gorman,Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board liaisons:Satish K. Aggarwal, NRC RepresentativeRichard DeBlasio, DOE RepresentativeAlan H. Cookson, NI
19、ST RepresentativeMichelle TurnerIEEE Standards Project EditorDuane Anderson*Haakon BryhniBob Davis*Stein GjessingDavid Gustavson*Chris HamlinAnatol Kaganovich*Sam KarunanithiBeomsup KimDennis PakRon RobertsR. J. SafranekWink SavilleTim ScottVivian Shen*Fred ShirleyJoanne SpillerRuss TuckRichard Wilm
20、ot*James CarloKeith ChowJohn ColeBob DavisGuru Dutt DhingraSourav DuttaMartin FreemanRon GreenthalerDavid GustavsonAndy HospodorDavid JamesGregory LuriJoseph MarshallNarayanan MurugesanMatthew NouryKlaus RapfGary RobinsonMichael SchollesStephen SchwarmVeselin SkendzicRobert SnivelyThomas StaraiSrini
21、vasa VemuruOren YuenJanusz ZalewskiMark D. BowmanDennis B. BrophyJoseph BruderRichard CoxBob DavisJulian Forster*Joanna N. GueninMark S. HalpinRaymond HapemanWilliam B. HopfLowell G. JohnsonHerman KochJoseph L. Koepfinger*David J. LawDaleep C. MohlaPaul NikolichT. W. OlsenGlenn ParsonsRonald C. Pete
22、rsenGary S. RobinsonFrank StoneMalcolm V. ThadenRichard L. TownsendJoe D. WatsonHoward L. WolfmanCopyright 2006 IEEE. All rights reserved.vContents1. Overview. 11.1 Scope . 11.2 Purpose 11.3 Background 11.4 Scalable storage interface properties . 21.5 Historical perspective 21.6 Non-storage applicat
23、ions . 31.7 S2I command execution. 41.8 S2I topologies 61.9 S2I interconnects 91.10 Memory-mapped addresses . 91.11 Shared memory-mapped registers . 102. Normative references 113. Glossary and notation . 123.1 Definitions . 123.2 Field names 153.3 C-code notation . 153.4 Bit and byte ordering. 163.5
24、 Generic delta-level command lists 183.6 Data formats 184. Abbreviations and acronyms 205. Alpha-level interface 215.1 Alpha-level overview 215.2 Command execution 225.3 Alpha4 command and status entries 235.4 Alpha8 command and status entries 255.5 Command processing 265.6 Alpha-level CSRs 276. Del
25、ta interface properties 306.1 Delta-level distinctions 306.2 Delta-level memory-mapped addresses. 306.3 Address formats. 326.4 Command lists. 346.5 Legacy command-set support 376.6 Delta-level command processing 376.7 Command sequence ordering 416.8 Input/output transfers. 426.9 Scatter/gather trans
26、fers 436.10 System-bus transactions 446.11 Status reports . 466.12 Command synchronization 486.13 Error conditions. 506.14 Delta-level mover CSRs 51viCopyright 2006 IEEE. All rights reserved.6.15 Operational mover states . 547. Delta interfaces . 567.1 Delta16 overview. 567.2 Delta32 overview. 677.3
27、 Delta32 Mover CSRs. 757.4 Delta64 overview. 76Annex A (informative) Bibliography 85Annex B (informative) Illustrative applications . 86B.1 Secure logins . 86B.2 Scattered buffer allocation. 87B.3 Heartbeat timers. 88B.4 Event reports 88B.5 Power-level management 88B.6 Timed command execution . 89B.
28、7 DiskLite architecture . 90Annex C (informative) Software based RAID 93C.1 RAID I/O driver software 93C.2 Single-block OUTPUT 93C.3 Striped-block OUTPUT. 95C.4 Erasure-correcting single-block INPUT 96C.5 Erasure-correcting multiple-block INPUT 97Annex D (informative) Physical interface possibilitie
29、s 98D.1 Delta16-level backplane interface . 98D.2 Delta64 Serial Bus interface 99Annex E (informative) C-code illustrations 103Copyright 2006 IEEE. All rights reserved.1IEEE Standard for Scalable Storage Interface (S2I)1. OverviewThis is an informative introductory clause. Normative specifications a
30、re contained within following clausesand normative annexes.1.1 ScopeThis standard defines a scalable interface for use with memory-mapped storage units and other devices. Theterm “storage unit” can encompass rotating, non-rotating, volatile, and non-volatile storage. Issues of con-currency, latency,
31、 bandwidth, extensibility, and negotiation will be addressed. The interface is intended foruse with either a single storage unit or with many coordinated storage units.1.2 PurposeThis standard provides an efficient physical-layer independent interface architecture for storage units thatattach direct
32、ly to memory access buses. In this interface model, storage units have an attachment to mainmemory, rather than an attachment to an input/output (I/O) channel. This simplifies the storage unit designand supports scheduling of data transfers spanning large numbers of units.1.3 BackgroundThe S2I inter
33、face is intended to be located within the processors memory-mapped address space, in order tosupport a wide range of interconnect technologies. The memory-mapped address space is the only interfaceuniversal to all computers based on Von-Neumann processors. All microprocessors, whether RISC or CISC,a
34、re stored program machines and can access either memory or memory-mapped I/O devices directly. Theinterface consists of registers that control data-transfer engines, called movers, which can transfer data fromthe I/O device to processor accessible memory.The device-media addresses are not usually ma
35、pped directly into a memory-mapped address space, since thelatencies associated with high-capacity disk or tape storage devices are much greater than the latencies of theresources normally mapped into the bus-address space. Dealing with these large latencies is not possible onbuses with small fixed-
36、timeout periods and, even when possible, would compromise the bus performanceand error-detection capabilities.For redundant array of inexpensive disks (RAID) applications, each storage unit could have local storagethat is memory-mapped into system address space. Writes to that memory have EXOR effec
37、ts on transactionwrites. This memory facility and other command-synchronization facilities allows I/O devices to provideRAID storage facilities, without additional hardware support.IEEE Std 1285-2005 IEEE STANDARD FOR2Copyright 2006 IEEE. All rights reserved.1.4 Scalable storage interface properties
38、The following items have been identified as properties of the delta-level S2I interfaces.a)Scalable.S2I is scalable. It is cost-effective for small systems and extensible to large (thousands ofdisks) systems. Low-cost or high-speed interconnect technologies can be used. b)Bus independence.Because th
39、e S2I interface is memory-mapped, standard memory interfaces canbe used to support the logical protocols. The logical protocols can be readily supported ongeneral-purpose buses (PCI Local Bus Specification B81), low-cost expansion buses (Serial Bus),or high-performance longer-distance interconnects
40、(SCI). c)High performance.1)Scattered addresses.Indirect transfers involving lists of addresses efficiently support transfers:i) An address/length array can specify scattered sets of system- or device-memory addresses.ii) A list of commands can (somewhat less efficiently) specify scattered media add
41、resses.2)Command appending. Additional command lists can be dispatched, while a current commandlist is active, without disrupting the in-progress transfers.3)Synchronized transfers. Device-to-memory or device-to-device transfers can be paced by usinga LOOP command, whose completion is delayed until
42、a test condition has been reached.d)RAID friendly.The target-paced data transfer capabilities allow the architecture to accommodatelarge numbers of storage devices.e)Device independence.The direct memory access (DMA) data-transfer architecture can be readilyapplied to a variety of storage and/or I/O
43、 device architectures.f)Multiplexed connections. There is no limit on the number of S2I interfaces that can attach to onebus (or bus-like interconnect). However, specific bus standards typically restrict the number ofattached interfaces for speed or latency reasons.g)Emulatable.Control and Status Re
44、gister (CSR) reads have no effects and writes need not haveimmediate side effects, allowing CSRs to be placed in a register file. The microprocessors inter-pretation of recently-written CSRs can thus be done in a time insensitive fashion.1.5 Historical perspectiveYears ago on large mainframe systems
45、, mass storage was provided by physically-large disk drives. Sincethese disk drives, as well as the CPU, were large, they were typically located in physically distinct racks.Bulky (and typically expensive) cables were initially used to connect the disk-drive and the CPU cabinets, asillustrated in th
46、e left side of Figure 1.1. Magnetic disks and tapes are no longer the only types of storage devicesoptical disks (CD-ROM),non-volatile memories (FLASH), and magneto-optic drives (MO drives) now supplement them. Decreased1The numbers in brackets correspond to those of the bibliography in Annex A.Figu
47、re 1.1Evolving storage-device cabling strategies(cabinets within one room)Systems of the 70s and 80sdisk CD(components near the motherboard)MOdriveSystems after the 80sCPU memoryFLASHmemoryCPUdisk1tapedisk3disk2SCALABLE STORAGE INTERFACE (S2I) IEEE Std 1285-2005Copyright 2006 IEEE. All rights reserv
48、ed.3costs and improved densities of integrated circuits and disk storage now allow mainframe functionality to beprovided by workstations and personal computers.Within personal computer environments, the physical distance between the CPU and the storage devices hasbeen reduced, and in most cases the
49、storage devices are located adjacent to the CPUs motherboard. Thus,attaching storage devices to the processor/memory bus (or protocol-compatible, possibly switched,extensions of this bus) has become practical, allowing data to be directly transferred between storagedevices and command-specified memory addresses. Thus, a distinct set of protocols for communicatingthrough specialized storage-device connections is unnecessary and therefore is not assumed. Given the wide range of bus and system topologies, several levels of storage-device interface were found tobe
