`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Recognized as an
`American National Standard (ANSI)
`
`IEEE Std 1596-1992
`(Adopted by ISO/IEC and redesignated as
`ISO/IEC 13961:2000)
`
`IEEE Standard for Scalable Coherent
`Interface (SCI)
`
`Sponsor
`Microprocessor and Microcomputer Standards Subcommittee
`of the
`IEEE Computer Society
`
`Approved 19 March 1992
`IEEE-SA Standards Board
`
`Adopted by ISO/IEC and redesignated as
`ISO/IEC 13961:2000
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 1
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Abstract: The scalable coherent interface (SCI) provides computer-bus-like services but, instead
`
`of a bus, uses a collection of fast point-to-point unidirectional links to provide the far higher through-
`put needed for high-performance multiprocessor systems. SCI supports distributed, shared
`memory with optional cache coherence for tightly coupled systems, and message-passing for
`loosely coupled systems. Initial SCI links are defined at 1 Gbyte/s (16-bit parallel) and 1 Gb/s
`(serial). For applications requiring modular packaging, an interchangeable module is specified
`along with connector and power. The packets and protocols that implement transactions are
`defined and their formal specification is provided in the form of computer programs. In addition to
`the usual read-and-write transactions, SCI supports efficient multiprocessor lock transactions. The
`distributed cache-coherence protocols are efficient and can recover from an arbitrary number of
`transmission failures. SCI protocols ensure forward progress despite multiprocessor conflicts (no
`deadlocks or starvation).
`
`Keywords: bus architecture, bus standard, cache coherence, distributed memory, fiber optic,
`interconnect,I/O system, link, mesh, multiprocessor, network, packet protocol, ring, seamless
`distributed computer,shared memory, switch, transaction set
`
`The Institute of Electrical and Electronics Engineers, Inc.
`3 Park Avenue, New York, NY 10016-5997, USA
`
`Copyright © 2001 by the Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved. Published 23 May 2001. Printed in the United States of America.
`
`Print:
`
`
`PDF:
`
`ISBN 1-55937-222-2 SH15255
`ISBN 0-7381-1206-2 SS15255
`
`No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
`written permission of the publisher.
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 2
`
`

`

`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 3
`
`

`

`
`
`
`
`
`
`
`
`IEEE Standards
` documents are developed within the IEEE Societies and the Standards Coordinating Committees of the
`IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus develop-
`ment process, approved by the American National Standards Institute, which brings together volunteers representing varied
`viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve with-
`out compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus devel-
`opment process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained
`in its standards.
`
`Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other dam-
`age, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting
`from the publication, use of, or reliance upon this, or any other IEEE Standard document.
`
`The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims
`any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that
`AS IS
`.”
`the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “
`
`The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market,
`or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
`time a standard is approved and issued is subject to change brought about through developments in the state of the art and
`comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revi-
`sion or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude
`that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check
`to determine that they have the latest edition of any IEEE Standard.
`
`In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services
`for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or
`entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a com-
`petent professional in determining the exercise of reasonable care in any given circumstances.
`
`Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific
`applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare
`appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any
`interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its soci-
`eties and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in
`those cases where the matter has previously received formal consideration.
`
`Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with
`IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate
`supporting comments. Comments on standards and requests for interpretations should be addressed to:
`
`Secretary, IEEE-SA Standards Board
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`USA
`
`Note: Attention is called to the possibility that implementation of this standard may require use of subject mat-
`ter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
`validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents
`for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or
`scope of those patents that are brought to its attention.
`
`IEEE is the sole entity that may authorize the use of certification marks, trademarks, or other designations to indicate com-
`pliance with the materials set forth herein.
`
`Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of
`Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To
`arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
`Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational
`classroom use can also be obtained through the Copyright Clearance Center.
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 4
`
`

`

`Introduction
`
`(This introduction is not a part of IEEE Std 1596-1992, IEEE Standard for Scalable Coherent Interface [SCI].)
`
`The demand for more processing power continues to increase, and apparently has no limit. One can usefully saturate
`the resources of any computer so easily by merely specifying a finer mesh or higher resolution for the solution of some
`physical problem (hydrodynamics, for example), that engineers and scientists are desperate for enormously larger
`computers.
`
`To get this kind of computing power, it seems necessary to use a large number of processors cooperatively. Because of
`the propagation delays introduced when signals cross chip boundaries, the fastest uniprocessor may be on one chip
`before long. Pipelining and similar large-mainframe tricks are already used extensively on single-chip processors.
`Vector processors help, but are hard to use efficiently in many applications. Multiprocessors communicating by
`message passing work well for some applications, but not for all. The shared-memory multiprocessor looks like the
`best strategy for the future, but a great deal of work will be needed to develop software to use it efficiently.
`
`It is important to support both the shared-memory and the message-passing models efficiently (and at the same time)
`in order to support optimal software for a wide range of problems, especially for a system that dynamically allocates
`processors and perhaps changes its configuration depending on the nature of its load.
`
`SCI started from an attempt to increase the bandwidth of a backplane bus past the limits set by backplane physics in
`order to meet the needs of new generations of processor chips, some of which can single-handedly saturate the fastest
`buses. We soon learned that we had to abandon the bus structure to achieve our goals.
`
`Backplane performance is limited by physics (distributed capacitances and the speed of light) and by a bus's one-at-a-
`time nature, an inherent bottleneck. To gain performance far beyond what buses and backplanes can do, one needs
`better signaling techniques and the concurrent use of many signaling paths.
`
`Rather than using bused backplane wires, SCI is based on point-to-point interconnect technology. This design
`approach eliminates many of the physics problems and results in much higher speeds. SCI in effect simulates a bus,
`providing the bus services one expects (and more) without using buses.
`
`SCI has turned out to be surprisingly simple, much simpler than many of the alternative designs we explored and much
`simpler than bus-based systems would be if they tried to approach a comparable size and performance. This simplicity
`may not be obvious to the first-time reader of this rather thick document, but much of this bulk is due to the large
`amount of tutorial material necessary to introduce such a new way of doing things (a paradigm shift), and even more
`is due to the comprehensive executable description of cache behavior under all possible conditions.
`
`The switch from a shared backplane bus to a point-to-point interconnect has created many new problems and research
`topics, which have been resolved in record time by this SCI project. Much research remains to be done on determining
`optimal ways to use the mechanisms SCI provides. SCI has also required the development of novel allocation and
`cache-coherence protocols, which has made the project a challenging one indeed, particularly in view of our schedule
`objectives.
`
`Historical Perspective and Acknowledgments
`
`Most of the developers of SCI come from high-speed-bus backgrounds, such as Fastbus (IEEE Std 960-1989) or
`Futurebus (IEEE Std 896.1-1987). Paul Sweazey, who was the coordinator of the Futurebus cache coherence task
`group, initiated a SuperBus Study Group under the IEEE Computer Society's Microprocessor Standards Committee in
`November 1987 to consider whether something could be done for the next bus generation to avoid the multitude of
`competing incompatible standards we saw in the 32-bit generation. Futurebus tried to solve that problem, starting in
`the late 1970s, but could not converge to a single best solution in time to head off the development of many
`alternatives.
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`iii
`
`Samsung
`Ex. 1032 - Page 5
`
`

`

`The SuperBus Study Group met for less than a year before deciding that there was indeed a way to do better and to
`achieve the throughput rates that are required for supporting multiple 100-MFLOPS-class processor chips, namely
`about 1 Gbyte/s per processor. We were particularly urged on by Paul L. Borrill, Futurebus chairman, and John
`Moussouris (one of the founders of MIPS), who frightened us all by his predictions of immensely powerful processors
`in the near future—which already are coming true!
`
`Our July 1988 Project Authorization Request was approved by the IEEE Standards Board in October. David B.
`Gustavson was appointed Chairman and David V. James became the logical-task-group coordinator and Vice
`Chairman. Gustavson also served as physical-task-group coordinator, handled the records and mailings, and shared
`minutes-taking and editing duties with David James.
`
`A Control and Status Register and I/O Architecture effort was started within SCI, based on some significant
`contributions by David James. When it was recognized as important for other standard buses as well, it was split off as
`an independent activity shared by Futurebus+, Serial Bus (P1394), and others. In April 1989 this also became an
`official project, P1212, with David James as chairman. The goal of a uniform CSR architecture has been attempted
`many times before (e.g., by the Fastbus Software Working Group, chaired by Gustavson), and has proven elusive. The
`reason P1212 has had a more comprehensive success is that David James brought considerable architectural
`experience to bear, generating sufficient rationale for the various choices so that decisions no longer seem entirely
`arbitrary. Much of this rationale is a consequence of multiprocessor architectural considerations; without the constraint
`of efficient multiprocessor interoperability, many CSR design issues would be too arbitrary to be able to achieve timely
`standardization.
`
`The CSR Architecture has become a unifying force for the latest generation of buses, encouraging VME and
`MULTIBUS® II users to use the CSR architecture as they interface to Futurebus+, thus facilitating a future interface to
`SCI as system requirements grow. In this way, there is a relatively smooth and well-defined growth path from present-
`generation single-processor systems through Futurebus+'s several-processor systems with cache coherence, to SCI's
`many-processor systems. Because of the importance of such a migration path to the future acceptance of SCI, we place
`high priority on interfacing SCI with other buses. For that reason we include protocol hooks that would not otherwise
`be needed. In exchange, SCI users will be able to take advantage of the large number of existing I/O interfaces.
`
`In March 1989, a Fiber Optic Task Group (SCI-FI) was started, led by Hans Wiggers, and an SCI/Futurebus+ Bridge
`Task Group was started, led by Mark Williams (a joint appointment with Futurebus+).
`
`Throughout the development of SCI, Knut Alnes and Ernst Kristiansen were working on an early implementation,
`providing input for the details of the specification. They also initiated work at the University of Oslo, by Stein Gjessing
`and others, on formal verification of the cache-coherence mechanisms. This real implementation effort was extremely
`valuable to SCI, and greatly accelerated convergence to a practical specification.
`
`David James generated documents at an incredible rate. As the result of his single-handed effort the bulk of the text of
`this specification first appeared in June 1989. At the same time he was producing two volumes of similar size for the
`CSR working group! He is convinced that having something on paper produces more productive discussions, and our
`experience supports that view.
`
`In September 1990, the working group requested the initiation of a project to standardize an SCI/VME bridge
`architecture, P1596.1, chaired by Ernst Kristiansen. The first meeting was held in November.
`
`September 1990 also saw the P1212 draft completion and the beginning of its ballot phase.
`
`In November 1990 the Fiber Optic part of SCI was given a big boost by Hewlett Packard's decision to release its Gbit/s
`serial G-link specification for use by SCI. This link is able to transfer the 17th bit that makes possible a transparent
`synchronous interface with the parallel 16-bit-plus-flag SCI link. The other serial links considered needed occasional
`extra symbols in place of the flag bit, which made such an interface much more difficult because the serial and parallel
`
`® MULTIBUS is a registered trademark of Texas Instruments, Inc.
`
`iv
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 6
`
`

`

`clock frequencies could not have a constant ratio. (Subsequently, ways to solve this problem were discovered that are
`compatible with other encodings, such as 8b/10b, so future link standards could use these if that proves desirable.)
`
`In January 1991, the working group voted unanimously to submit the draft specification to the Microprocessor
`Standards Committee (MSC) for forwarding to the balloting body. This was the only vote taken by the working group,
`which worked entirely by consensus from start to finish. Our philosophy was that, given choices, we would always
`take the technically superior way. If superiority was not apparent, an arbitrary choice would be used until it ran into
`problems. This method worked very well, resulting in rapid progress and a nearly ego-free working environment. It
`helped that this project was at the leading edge of technology, and thus attracted contributors of sufficiently high
`stature that their egos were under control. It also helped that SCI was not considered a threat to existing commercial
`interests, but rather a path to new markets.
`
`In order to avoid the chaos of the 32-bit-bus world, SCI would have to finish in record time. (Normal development time
`for a new bus standard that involves new design without major historical constraints has run from eight to twelve
`years.) To this end, the group worked at a feverish pace, with multiday meetings every month and much work between.
`Many workers put in nearly full-time (in some cases much more than full-time) effort. One benefit, as the pace
`increases, is that the progress improves more than proportionally because there is no time between meetings for
`forgetting. The result is that the work goes faster and has higher quality and coherence, as we hope the reader will
`agree upon examining this standard.
`
`The P1596 Working Group is grateful to all who have participated directly or indirectly in the development of the SCI
`standard. In the initial design phases, novel concepts were often mistakenly discarded before being resurrected and
`included in the SCI standard. The working group extends its gratitude to those who had the perseverance to withstand
`this learning process, and its apologies to those whose contributions were not appreciated properly. Some of the
`multiprocessor architectural issues in SCI are very esoteric, and we recognize that has been frustrating to newcomers,
`as it takes a long time to get up to speed. The working group is also grateful for the patience that the experts in various
`areas have shown while time was spent on other areas.
`
`Particular acknowledgment is due Manolis Katevenis, who suggested register rings before the working group was
`ready to accept them. Sverre Johanssen, Steinar Wenaas, Alain Kägi, Evan Torrie, and Wayne Yamamoto executed and
`helped debug the specification code. Stein Gjessing and Jim Goodman were major contributors to the cache-coherence
`and Queue on Lock Bit features. John Mellor-Crummey of Rice University and Michael Scott of the University of
`Rochester (NY) helped the working group understand how to make nonblocking message queues and spin-lock
`queues. David Black helped the working group understand the requirements of coherent TLB support.
`
`Craig Hansen and Mike Koster provided good architectural insights, a RISC-like philosophy, and helpful critical
`review. Gary Demos motivated the working group to consider the needs of HDTV and other graphics applications.
`Pete Fenner provided much helpful review on the logical layer. Kurt Baty showed efficient ways to interconnect
`ringlets to optimize cost and keep the number of hops low.
`
`Ralph Lachenmaier, Julian Olyansky, Tim Scott and Joanne Spiller helped the working group to consider real-time
`issues and put in some hooks that can be used for real-time support in future extensions. Ralph also helped by finding
`financial support to enable some of our technical experts to attend the meetings. (By real-time support, SCI generally
`means sacrificing its forward-progress guarantees under unknown but presumed-heavy computing load, which may
`result in large variations of latency, in exchange for deterministic latency that can be used with Rate Monotonic
`Scheduling to set task priorities for a fully understood computing load so that critical deadlines are never missed. Other
`definitions of real-time also exist. SCI may be used without modification in some real-time applications.)
`
`Phil Ponting of CERN provided European redistribution for SCI mailings and liaison with related European activities.
`Hans Müller of CERN served as contact person for the CERN SCI group.
`
`Charles Grimsdale shared with the working group useful experiences of Division Ltd. in building a system with similar
`goals to SCIs. Randy Rettberg and Guy Fedorkow shared experience from BBN's multiprocessor systems. Steve
`Nelson shared experience from Cray Research, particularly on signaling technology. Wayne Downer and Mark
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`v
`
`Samsung
`Ex. 1032 - Page 7
`
`

`

`Mellinger shared experience from Sequent, particularly convincing the working group of the importance of good
`diagnostic support.
`
`Steve Deiss evaluated SCI from a neural-net point of view, and helped create the broadcast mechanism. Ken Dawson
`(the Fastbus editor) spent a week in California in November 1990 helping edit the draft to significantly improve its
`clarity.
`
`Several vendors, particularly AMP (Jim Schroeder) and DuPont (Robert Appleby), made significant investments in
`connector modeling to ensure that SCI's signals would successfully pass through the chosen connectors.
`Measurements of the performance of actual hardware were done by Dolphin Server Technology and Hewlett Packard.
`Steve Hunter of Gore presented prototype cables for SCI. Useful presentations on connectors and signaling were made
`by David Brearley, Ram Goel, Robert Southard, Robert Weber, Ken Wratten, and others. Branko Leskovar evaluated
`fiber and coaxial connectors for SCI. The serial encoding scheme and optical specification were largely drawn from a
`Serial HIPPI draft and the work of David Cunningham, George Kwan, Bill McFarland, Steve Methley, Richard
`Walker, and Chu-Sun Yen of Hewlett Packard Laboratories, Palo Alto and Bristol.
`
`Eike Waltz of Schroff helped with the mechanical specification, as did the P1301 working group, led by Hans
`Karlsson. Gone Schramm of AT&T was particularly helpful in addressing the tolerance issues. Joe Trainor of ITT
`pointed out common connector reliability problems that could be avoided. Ed Kantner of IBM helped the working
`group understand the importance of detailing pin shape and metallurgy in the connector, which P1301.1 then added to
`the connector specification. Ernie Crocker and Dick Lawrence of Digital Equipment Corporation were helpful in
`providing current information on the P896.2 Profile B mechanics, which were followed as closely as possible. (In
`addition to defining a different connector layout, some changes were necessary because certain SCI-module designs
`prefer to use PC boards that are thicker than the standard card-guide grooves. That is very difficult with the ESD
`discharge mechanism used in Profile B, which requires a conductive surface on the region of the PC boards that must
`be removed to thin the board to fit the card guide.)
`
`Hans Wiggers of Hewlett Packard provided and maintained electronic archives on an anonymous-FTP server
`accessible throughout the world via the Internet. This was used for electronic distribution of drafts and code, and for
`rapid feedback and communication among our collaborators. This service was particularly important because of the
`large volume of work being done in Norway as well as in California—the latest draft could make the trip in minutes.
`Documents were provided in MicroSoft Word® 4 format (compressed) and in PostScript format. The latter made it
`possible for collaborators without Macintosh® access to print documents (complete with graphics) on a wide variety
`of machines.
`
`Alain Kägi and Evan Torrie contributed extensively to the SCI C-code specification while working one summer at
`Apple Computer. In addition to debugging, they modernized the naming conventions and generated the concept of a
`communication “cloud” within each node. Wayne Yamamoto helped refine the interface to the C-code specification,
`including support for simulation/execution and debugging environments. Colin Plumb pointed out that the original
`CRC stomp value (cc33) was suboptimal. He provided a program that the working group modified and used to search
`for a better number.
`
`We are grateful to the following individuals and their companies, who served as hosts for one or more of the working
`group's multiday meetings (listed alphabetically by company): Donald Senzig, Amdahl; David James, Apple
`Computer; Randall Rettberg, BB&N; Hans Müller, CERN; Ernst Kristiansen, Dolphin Server Technology; Viggy
`Mokkarala, Hans Wiggers, Mark Williams, Hewlett Packard; Carl Warren, McDonnell Douglas; Paul Borrill, Gary
`Murdock, Paul Sweazey, National Semiconductor; Wayne Downer, Sequent; Anatol Kaganovich, Signetics; David
`Gustavson, Stanford Linear Accelerator Center; John Theus, Tektronix; Jay Cantrell, Texas Instruments; Michael
`Koster, Unisys; Jim Goodman, University of Wisconsin. The P1596 Working Group is also grateful to many others
`who hosted SCI presentations or task-group meetings.
`
`vi
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 8
`
`

`

`Committee Membership
`
`The specification has been developed with the combined efforts of many volunteers. The following is a list of those
`who were members of the Working Group while the draft and final specification were compiled:
`
`David B. Gustavson, Chair
`David V. James, Vice Chair
`
`Nagi Aboulenein
`Knut Alnes
`Robert H. Appleby
`Kurt Baty
`Amir Behroozi
`David L. Black
`Andre Bogaerts
`Paul Borrill
`David Brearley, Jr.
`Charles Brill
`Patrick Boyle
`Haakon Bugge
`Jan Buytaert
`Jay Cantrell
`Mike Carlton
`Fred L. Chong
`Graham Connolly
`James R.(Bob) Davis
`W. Kenneth Dawson
`Stephen R. Deiss
`Gary Demos
`Roberto Divia
`Gregg Donley
`Wayne Downer
`Guy Fedorkow
`Peter Fenner
`David Ford
`Stein Gjessing
`Torstein Gleditsch
`James Goodman
`Robert J. Greiner
`Charles Grimsdale
`
`*deceased
`
`Emil N. Hahn
`Horst Halling
`Craig Hansen
`Marit Jenssen
`Rajeev Jog
`Svein Erik Johansen
`Sverre Johansen
`Ross Johnson
`Anatol Kaganovich
`Alain Kägi
`Hans Karlsson*
`Tom Knight
`Michael J. Koster
`Ernst Kristiansen
`Stein Krogdahl
`Ralph Lachenmaier
`Branko Leskovar
`Dieter Linnhöfer
`Robert McLaren
`Mark Mellinger
`Svein Moholt
`Viggy Mokkarala
`John Moussouris
`Hans Müller
`Klaus D. Müller
`Ellen Munthe-Kaas
`Russell Nakano
`Tom Nash
`Steve Nelson
`Julian Olyansky
`Chris Parkman
`Dan Picker
`
`Phil Ponting
`Steve Quinton
`Jean F. Renardy
`Randy Rettberg
`Molten Schanke
`Gene Schramm
`James L. Schroeder
`Tim Scott
`Donald Senzig
`Gurindar Sohi
`Robert K. Southard
`Joanne Spiller
`Paul Sweazey
`Lorne Temes
`Manu Thapar
`John Theus
`Mike van Brunt
`Phil Vukovic
`Anthony Waitz
`Richard Walker
`Steve Ward
`Carl Warren*
`Steinar Wenaas
`Mike Wenzel
`Richard J. Westmore
`Wilson Whitehead
`Hans Wiggers
`Mark Williams
`Philip Woest
`S. Y. Wong
`Ken Wratten
`Chu-Sun Yen
`
`The following persons were on the balloting committee that approved this document for submission to the IEEE
`Standards Board:
`
`M. R. Aaron
`Scott Akers
`Ray S. Alderman
`John Allen
`Knut Alnes
`Richard P. Ames
`Bjorn Bakka
`David M. Barnum
`
`Kurt Baty
`Harrison A. Beasley
`Amir Behroozi
`Janos Biri
`David Black
`William P. Blase
`Andre Bogaerts
`W. C. Brantley
`
`David Brearley, Jr.
`Haakon Bugge
`Kim Clohessy
`Graham Connolly
`Jonathan C. Crowell
`W. Kenneth Dawson
`Stephen Deiss
`Dante Del Corso
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`vii
`
`Samsung
`Ex. 1032 - Page 9
`
`

`

`Stephen L. Diamond
`Jean-Jacques Dumont
`William P. Evertz
`Guy Federkow
`Timothy R. Feldman
`Peter Fenner
`Gordon Force
`Stein Gjessing
`Andy Glew
`Patrick Gonia
`James Goodman
`Charles Grimsdale
`David Hawley
`Phil Huelson
`Zoltan R. Hunor
`Edgar Jacques
`David V. James
`Kenneth Jansen
`Rajeev Jog
`Sverre Johansen
`Ross Johnson
`Jack R. Johnson
`Anatol Kaganovich
`Christopher Koehle
`Michael J. Koster
`Ernst H. Kristiansen
`Ralph Lachenmaier
`Glen Langdon, Jr.
`
`*deceased
`
`Gerry Laws
`Minsuk Lee
`Branko Leskovar
`Anthony G. Lubowe
`Svein Moholt
`James M. Moidel
`James D. Mooney
`Klaus-Dieter Mueller
`Ellen Munthe-Kaas
`Cuong Nguyen
`J. D. Nicoud
`Dan O'Connor
`Mira Pauker
`Donald Pavlovich
`Thomas Pittman
`Steve Quinton
`Richard Rawson
`Steven Ray
`Randy Rettburg
`Hans Roosli
`Paul Rosenberg
`Carl Schmiedekamp
`James L. Schroeder
`Don Senzig
`Philip Shutt
`Michael R. Sitzer
`Gurindar Sohi
`Robert K. Southard
`
`Joanne Spiller
`David Stevenson
`Robert Stewart
`Paul Sweazey
`Daniel Tabak
`Daniel Tarrant
`Lorne Temes
`Manu Thapar
`Michael G. Thompson
`Chris Thomson
`Joseph P. Trainor
`Robert Tripi
`Robert J. Voigt
`Phil Vukovic
`Yoshiaki Wakimura
`Richard Walker
`Eike Waltz
`Carl Warren*
`Richard J. Westmore
`Hans A. Wiggers
`Mark Williams
`Andrew Wilson
`Joel Witt
`Ken Wratten
`David L. Wright
`Chu Yen
`Oren Yuen
`Janusz Zalewski
`
`When the IEEE Standards Board approved this standard on March 19, 1992, it had the following membership:
`
`Marco W. Migliaro, Chair
`Donald C. Loughry, Vice Chair
`Andrew G. Salem, Secretary
`
`Donald N. Heirman
`Ben C. Johnson
`Walter J. Karplus
`Ivor N. Knight
`Joseph Koepfinger*
`Irving Kolodny
`D. N. “Jim” Logothetis
`Lawrence V. McCall
`
`T. Don Michael*
`John L. Rankine
`Wallace S. Read
`Ronald H. Reimer
`Gary S. Robinson
`Martin V. Schneider
`Terrance R. Whittemore
`Donald W. Zipse
`
`Dennis Bodson
`Paul L. Borrill
`Clyde Camp
`Donald C. Fleckenstein
`Jay Forster*
`David F. Franklin
`Ramiro Garcia
`Thomas L. Hannan
`
`*Member Emeritus
`
`Also included are the following nonvoting IEEE Standards Board liaisons:
`
`Fernando Aldana
`Satish K. Aggarwal
`
`James Beall
`Richard B. Engelman
`
`Stanley Warshaw
`
`Paula M. Kelty
`IEEE Standards Project Editor
`
`viii
`
`Authorized licensed use limited to: Columbia University Libraries. Downloaded on February 23,2021 at 05:13:05 UTC from IEEE Xplore. Restrictions apply.
`
`Samsung
`Ex. 1032 - Page 10
`
`

`

`CLAUSE
`
`PAGE
`
`1.
`
`Introduction.........................................................................................................................................................1
`
`1.1 Document structure .................................................................................................................................... 1
`1.2 SCI overview.............................................................................................................................................. 2
`1.3 Interconnect topologies .............................................................................................................................. 8
`1.4 Transactions ............................................................................................................................................. 13
`1.5 Cache coherence ...................................................................................................................................... 30
`1.6 Reliability, availability, and support (RAS)..............................................................................