ISO IEC 13213-1994 Information technology - Microprocessor systems - Control and Status Registers (CSR) architecture for microcomputer buses《信息技术 微处理机系统 微处理机总线的.pdf

《ISO IEC 13213-1994 Information technology - Microprocessor systems - Control and Status Registers (CSR) architecture for microcomputer buses《信息技术 微处理机系统 微处理机总线的.pdf》由会员分享，可在线阅读，更多相关《ISO IEC 13213-1994 Information technology - Microprocessor systems - Control and Status Registers (CSR) architecture for microcomputer buses《信息技术 微处理机系统 微处理机总线的.pdf（130页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL STANDARD ISO/IEC 13213 ANSI/IEEE Std 1212 First edition 1994-l O-05 Information technology - Microprocessor systems - Control and Status Registers (CSR) Architecture for microcomputer buses Technologies de Iinformation - Syst.Gmes 2 microprocesseurs - Architecture des registres de comm

2、ande et dgtat pour bus de micro-ordinateur Reference number ISO/IEC 13213: 1994(E) ANSI/IEEE Std 1212, 1994 Edition Abstract: The document structure and notation are described, and the objectives and scope of the CSR Architecture are outlined. Transition set requirements, node addressing, node archi

3、tectures, unit architectures, and CSR definitions are set forth. The ROM specification and bus standard requirements are covered. Keywords: CSR Architecture, bus architecture, bus standard, interoperability, microprocessors, node addressing, registers, transaction sets The Institute of Electrical an

4、d Electronics Engineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA Copyright 0 1994 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 1994. Printed in the United States of America ISBN l-55937-448-9 No part of this publication may be reproduc

5、ed in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. October 5, 1994 SH94220 ISO/lEC 13213 : 1994 ANSI/IEEE Std 1212,1994 Edition (Incorporates ANSI/IEEE Std 1212-1991) Information technology- Microprocessor systems-Control and Status

6、 Registers (CSR) Architecture for microcomputer buses Sponsor Microprocessor and Microcomputer Standards Committee of the IEEE Computer Society Adopted as an International Standard by the International Organization for Standardization and by the International Electrotechnical Commission Published by

7、 The Institute of Electrical and Electronics Engineers, Inc. - American National Standard Foreword IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standard- ization. National bodies that are me

8、mber of IS0 or IEC participate in the develop- ment of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. IS0 and IEC technical committees collaborate in fields of mutual interest. Other international

9、organizations, governmental and nongovernmental, in liaison with IS0 and IEC, also take part in the work. In the field of information technology, IS0 and IEC have established a joint technical committee, ISOAEC JTCl 1. Draft International Standards adopted by the joint tech- nical committee are circ

10、ulated to national bodies for voting. Publication as an Inter- national Standard requires approval by at least 75% of the national bodies casting a vote. In 1994, ANSI/IEEE Std 1212-1991 was adopted by ISO/IEC ITCl, as draft Intema- tional Standard ISO/IEC DIS 13213. This edition incorporates editor

11、ial comments received in the review of ISO/IEC DIS 132 13. International Organization for Standardization/International Electrotechnical Commission Case postale 56 l CH-1211 Geneve 20 l Switzerland IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the S

12、tandards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute

13、as well as those activities outside of IEEE that have expressed an interest in partici- pating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, mar- ket,

14、 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 I

15、EEE Standard is subjected to review at least every five years for revision or reaflirmation. 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. User

16、s are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in docu- ments should be in the form of a proposed chan

17、ge of text, together with appropriate supporting comments. 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 acti

18、on to prepare appro- priate responses. Since IEEE Standards represent a consensus of all concerned inter- ests, 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 technical com- mittees are not ab

19、le to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ

20、08855-1331 USA IEEE Standards documents may involve the use of patented technology. Their approval by the Institute of Electrical and Electronics Engineers does not mean that using such technology for the purpose of conforming to such standards is authorized by the patent owner. It is the obligation

21、 of the user of such technology to obtain all necessary permissions. Introduction (This introduction is not a part of this International Standard or of ANWIEEE Std 1212, 1994 Edition.) Bus standards have often been set by hardware designers who have focused on the transport mechanisms for sending re

22、ad and write transactions on a bus. Additional software considerations are needed to ensure interoperability between boards, as users of current bus “standards” have discovered. Therefore, many bus standards have been supplemented with one or several de facto or recommended register architectures, w

23、hich have usually differed for each bus standard. Through the cooperative efforts of the P1394 Serial Bus, P896 Futurebus+, and P1596 Scalable Coherent Interface (SCI) Working Groups, the need for a more formal approach to defining a common scalable bus- technology-independent Control and Status Reg

24、ister (CSR) Architecture was recognized. The hope is that, by sharing a uniform CSR Architecture, these systems will minimize the software and firmware changes when migrating a processor from one system bus to another or when bridging from one bus to another, and that software costs for migrating be

25、tween standards (as technology evolves) will be reduced. The P1212 CSR Architecture Working Group was fortunate to have the wide range of bus technologies (from approxi- mately 40 Mb/s for Serial Bus to approximately 1 Gbyte/s for SCI) to test the performance and cost scalability of its designs. The

26、 popularity of the Futurebus+ standard ensured that the CSR Architecture spec- ification would be reviewed by a large audience for use in a wide variety of applications. The scope of the CSR Architecture includes the definition of the generic registers needed to initialize, con- figure, and test nod

27、es within a system. Other broadcast registers are sufficiently standardized to ensure interoperability between modules supplied by different vendors. The CSR document also defines address- space maps, bus transaction sets (reads, writes, and locks), and ROM data formats. Protocols are defined for in

28、terrupting processors, passing messages, and for accurately synchronizing dis- tributed clocks. These definitions are intended to provide a sufficient and standard framework for the design of vendor-dependent unit architectures. Parts of this CSR Architecture are likely to indirectly influence the p

29、rocessor designs of the future. The following is a list of participants in the IEEE Control and Status Register (CSR) Working Group at the time ANSI/IEEE Std 1212-1991 was approved: David V. James, Chair Barbara Aichinger Knut Alnes Robert S. Baxter Harrison Beasley David Brash Mark Bunker Robert C.

30、 Carpenter D. Del Corso Jon Crowell Stephen Deiss Ian Dobson Emer Dooley Michael A. Dorsett Sam Duncan WI? Evertz Frank Fidducia John R. Fortier Ralph Frangioso Tony Grigg David B. Gustavson Claes-G&an Gustavsson Mark Hassel David Hawley Hubert Holierhoek Ed Jacques Marit Jenssen Ernst Kristiansen R

31、alph Lachenmaier Jim Leahy Jim McGrath Thanos Mentzelopoulous Jim Moidel Klaus Mueller George Nacht Mitsunori Nakata Richard Napolitano Daniel C. OConnor Mira Pauker Chet Pawlowski James M. Pexa Mike Roby Tim Scott Don Senzig Patricia Smith Joanne Spiller Bob Squirrel1 Haruhisa Suzuki Michael Teener

32、 John Theus Yoshiaki Wakimura Mike Wenzel Martin Whittaker Hans Wiggers Dwight Wilcox Mark Williams David L. Wright iv The following persons were on the balloting committee that approved this document for submission to the IEEE Standards Board: John Allen Knut Alnes Harrison A. Beasley Kyle M. Black

33、 John Black Kim Clohessy Jonathan C. Crowell Stephen L. Diamond Samuel Duncan Wayne Fischer Joseph D. George Andy Glew David B. Gustavson Zoltan R. Hunor John Hyde Ed Jacques David V. James Kenneth Jansen Hubert Kirrmann Ernst H. Kristiansen Gerry Laws James D. Mooney Klaus Dieter Mueller Gary A. Ne

34、lson J. D. Nicoud Daniel C. OConnor Mira Pauker Donald Pavlovich Richard Rawson Carl Schmiedekamp Don Senzig Paul Sweazey Michael G. Thompson Eike Waltz Hans A. Wiggers Mark Williams Oren Yuen When the IEEE Standards Board approved this standard on December 5, 1991, it had the following member- ship

35、: Marco W. Migliaro, Chair Donald C. Loughry, Vice Chair Andrew G. Salem, Secretary Dennis Bodson Paul L. Borrill Clyde Camp James M. Daly Donald C. Fleckenstein Jay Forster* David F. Franklin Ingrid Fromm Thomas L. Hannan Donald N. Heirman Kenneth D. Hendrix John W. Horch Ben C. Johnson Ivor N. Kni

36、ght Joseph L. Koepfinger* Irving Kolodny Michael A. Lawler *Member Emeritus Also included are the following nonvoting IEEE Standards Board liaisons: Fernando Aldana Satish K. Aggarwal James Beall Richard B. Engelman Stanley Warshaw John E. May, Jr. Lawrence V. McCall Donald T. Michael* Stig L. Nilss

37、on John L. Rankine Ronald H. Reimer Gary S. Robinson Terrance R. Whittemore IEEE Std 1212-1991 was approved by the American National Standards Institute on May 14, 1992. V Contents CLAUSE PAGE 1. Document structure and notation . 1 1.1 Document structure 1 1.2 References 1 1.3 Conformance levels . 1

38、 1.4 Technical glossary . 2 1.5 Bit, byte, and quadlet ordering . 9 1.6 Numerical values . 9 1.7 C code notation 10 1.8 CSR, ROM, and field notation . 10 1.9 Register specification format . 11 1.10 Reserved registers and fields . 12 Objectives and scope 15 2.1 scope 15 2.2 Objectives 15 Transaction

39、set requirements . 17 3.1 Transaction overview . 17 3.2 Read and write transactions . 17 3.3 Noncoherent lock transactions . 18 3.4 Transaction errors 20 3.5 Immediate effects . 2 1 Node addressing . 23 4.1 Node addresses . 23 4.2 Extended addressing 23 4.3 64-bit fixed addressing . 25 4.4 Private a

40、ddresses 26 4.5 Initial node space . 26 4.6 Extended address spaces 27 4.7 Indirect space . 28 4.8 Address space offsets . 29 Node architectures . 31 5.1 Modules, nodes, and units 31 5.2 Node states . 32 5.3 Node testing . 33 5.3.1 Access-path tests . 33 5.3.2 Reset test . 33 5.3.3 Diagnostic tests

41、. 34 5.3.4 Non-standard diagnostic tests . 35 5.4 Multinode modules 36 5.5 On-line replacement (OLR) . 36 6. Unit architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 vii CLAUSE PAGE 6.1 Unit architecture overview . 39 6.2 Interrupts 39 6.2.1 Interrupt-target registers 39 6.2.2 Interrupt-poll registers . 40 6.3 Message passing . 41 6.4 Globally synchronized clocks 41 6.4.1 Clock overview . 4

43、1 6.4.2 Clock synchronization . 42 6.4.3 Clock update models . 43 6.4.4 Updating clock registers 44 6.4.5 Clock accuracy requirements 45 6.5 Memory unit architectures . 45 6.6 Unit architecture environment .45 7. CSR definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.1 Register names and offsets . 47 7.2 Minimal implementations 50 7.3 Unsupported register accesses . 5 1 7.4 Register definiti

45、ons 5 1 7.4.1 STATE-CLEAR . 51 7.4.2 STATE-SET . 54 7.4.3 NODE-IDS . 55 7.4.4 RESET-START 56 7.4.5 INDIRECT-ADDRESS 57 7.4.6 INDIRECT-DATA . 58 7.4.7 SPLIT-TIMEOUT 58 7.4.8 ARGUMENT 59 7.4.9 TEST-START 61 7.4.10 TEST-STATUS 64 7.4.11 UNITS-BASE . 66 7.4.12 UNITS-BOUND . 68 7.4.13 MEMORY-BASE 69 7.4.

46、14 MEMORY-BOUND 70 7.4.15 INTERRUPT-TARGET . 71 7.4.16 INTERRUPT-MASK . 72 7.4.17 CLOCK-VALUE 72 7.4.18 CLOCK-TICK-PERIOD . 74 7.4.19 CLOCK-STROBE-ARRIVED 75 7.4.20 CLOCK-STROBE-INFO 76 7.4.21 Message targets . 76 7.4.22 ERROR-LOG registers . 77 8. ROM specification . . . . . . . . . . . . . . . . .

47、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.1 Introduction 79 8.1.1 ROM design assumptions . 79 8.1.2 ROM formats 79 8.1.3 Driver

48、and diagnostic identifiers . 79 8.1.4 ASCII text . 81 8.1.5 CRC calculations . 81 8.2 ROM formats . 83 . . . Vlll CLAUSE PAGE 8.2.1 First ROM quadlet 83 8.2.2 Minimal ROM format . 83 8.2.3 General ROM format 83 8.2.4 Directory formats 84 8.2.5 Leaf format 86 8.2.6 Textual-descriptor 86 8.3 bus-info-

49、block . 88 8.4 Root directory entries . 89 8.4.1 Bus-Dependent-Info 90 8.4.2 Module-Vendor-Id . 90 8.4.3 Module-Hw-Version 90 8.4.4 Module-Spec-Id . 91 8.4.5 Module-SW-Version 91 8.4.6 Module-Dependent-Info 9 1 8.4.7 Node-Vendor-Id . 91 8.4.8 Node-Hw-Version 91 8.4.9 Node-Spec-Id . 91 8.4.10 Node-SW-Version 92 8.4.11 Node-Capabilities . 92 8.4.12 Node-Unique-Id . 92 8.4.13 Node-Units-Extent . 92 8.4.13.1 Node-Units-Extent immediate format 93 8.4.13.2 Node-Units-Extent offset format 94 8.4.14 Node-Memory-Extent 95 8.4.14,1 Node-Memory-Extent immediate format . 95 8.4.14.2 Node-Memory-Exte