IEEE Standard for a High-Performance Serial Bus
IEEE Computer Society
1394
TM
Sponsored by the Microprocessor Standards Committee
IEEE 3 Park Avenue New York, NY 10016-5997, USA 21 October 2008
IEEE Std 1394™-2008 (Revision of IEEE Std 1394-1995)
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394™-2008 (Revision of IEEE Std 1394-1995)
IEEE Standard for a High-Performance Serial Bus Sponsor
Microprocessor Standards Committee of the IEEE Computer Society Approved 12 June 2008
IEEE-SA Standards Board
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
The contents of Table 1, Table 3, Table 4, Table 5, and Table 6 reprinted with permission from the 1394 Trade Association, TS2006001, “Enhanced UTP PMD for IEEE 1394b,” © 2006. Figure 4-2 through Figure 4-11 reprinted with permission from the 1394 Trade Association, TS2006002, “1394 Beta Plus PHY-Link Interface,” © 2007. Figure 4-59A, Figure 4-59B, Figure 9-17B, and Figure 14-4B reprinted with permission from the 1394 Trade Association, TS2007010, “S3200 Electrical Specification,” © 2008. Figure 4-11N, Figure 4-11P, Figure 4-11S, Figure 4-11T, Figure 4-11AVA, and Figure 9-3 reprinted with permission from the 1394 Trade Association, TB2002001, “1394 Clarifications and Errata 2.0,” © 2006. Figure 3-1 through Figure 3-5 reprinted with permission from the 1394 Trade Association, TB0002, “1394a-2000 Connector Socket and Plug,” © 2001.
Abstract: This standard provides specifications for a high-speed serial bus that supports both asynchronous and isochronous communication and integrates well with most IEEE standard 32-bit and 64-bit parallel buses. It is intended to provide a low-cost interconnect between cards on the same backplane, cards on other backplanes, and external peripherals. Interfaces to longer distance transmission media [such as unshielded twisted pair (UTP), optical fiber, and plastic optical fiber (POF)] allow the interconnection to be extended throughout a local network. This standard follows the command and status register (CSR) architecture of IEEE Std 1212™-2001. Keywords: asynchronous, bus, computers, high-speed serial bus, interconnect, isochronous, optical fiber, plastic optical fiber, POF, unshielded twisted pair, UTP
The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2008 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 21 October 2008. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated. EUI-64 is a trademark of the Institute of Electrical and Electronics Engineers, Inc. Futurebus+ is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. National Electrical Code and NEC are both registered trademarks of the National Fire Protection Association, Inc. NuBus is a registered trademark of Texas Instruments, Inc. PDF: Print:
ISBN 978-0-7381-5770-2 ISBN 978-0-7381-5771-9
STD95807 STDPD95807
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: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
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 development 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 without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, 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 the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.” 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 revision 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 competent 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 societies 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. A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal interpretation of the IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE. 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 submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA 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; +1 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: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Introduction This introduction is not part of IEEE Std 1394-2008, IEEE Standard for a High-Performance Serial Bus.
The IEEE 1394 base standard was issued in 1995, followed by three amendments: IEEE Std 1394a™-2000, IEEE Std 1394b™-2002, and IEEE Std 1394c™-2006. In December 2002, a project was approved to merge the first two amendments into the base standard. Work on this project did not begin until July 2006. The project authorization was extended for two years and expanded to include IEEE Std 1394c-2006 as well as a large number of errata and corrigenda and several new features that had been developed over the intervening years. Editorial work on the standard was completed in April 2008.
Notice to users Laws and regulations Users of these documents should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.
Updating of IEEE documents Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Standards Association website at http:// ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously. For more information about the IEEE Standards Association or the IEEE standards development process, visit the IEEE-SA website at http://standards.ieee.org.
Errata Errata, 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 for errata periodically.
iv
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Interpretations Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/ index.html.
Patents Attention is called to the possibility that implementation of this standard may require use of subject matter 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. A patent holder or patent applicant has filed a statement of assurance that it will grant licenses under these rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Other essential patent claims may exist for which a statement of assurance has not been received. The IEEE is not responsible for identifying essential patent claims for which a license may be required, for conducting inquiries into the legal validity or scope of patents claims, or for determining whether any licensing terms or conditions are reasonable or nondiscriminatory. Further information may be obtained from the IEEE Standards Association.
Participants At the time this revision was sent to Sponsor ballot, the IEEE 1394 Working Group had the following membership: Les Baxter, Chair and Editor Eric Anderson Max Bassler Duncan Beadnell Roumen Botev Branko Bukal Will Harris Don Harwood Allen Heberling David Instone Peter Johansson Suehiro Kawanishi Hyunchin Kim
Todd Krein Pascal Levesque Stephan Lietz Win Maung Azim Mohammed Richard Mourn Jeremy Nelson Jalil Oraee Steve Powers Nanda Rao James Refi
Tsuyoshi Sawada Michael Scholles Chris Thomas Dave Thompson Koen van den Brande Hans van der Ven Barry Walker Colin Whitby-Strevens Blake Witkin Ricardo Wong Andy Yanowitz John Yurtin
The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. Toru Aihara Eric Anderson Ali Al Awazi Jim S. Baca John Barr Hugh Barrass Les Baxter Tomo Bogataj James Carlo Juan Carreon Weijen Chen Naveen Cherukuri Kai Moon Chow Keith Chow Tommy Cooper James Davis
Copyright © 2008 IEEE. All rights reserved.
Russell Dietz Thomas Dineen Sourav Dutta John Fuller James Gilb Sergiu Goma Randall Groves Scott A. Gudgel C. Guy William Harris Donald J. Harwood Werner Hoelzl David Instone Peter Johansson Piotr Karocki Yongbum Kim
Mark Knight Daniel Levesque William Lumpkins G. Luri Joseph Marshall Gary Michel Michael S. Newman Chris Osterloh Ulrich Pohl Robert Robinson Fernando Lucas Rodriguez William J. Rose Michael D. Rush Bartien Sayogo Michael Scholles Thomas Schossig
v
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Gil Shultz Amjad Soomro Thomas Starai Walter Struppler Michael Johas Teener
David Thompson Michael Thompson Timothy B. Thompson Leonard Tsai Srinivasa Vemuru John Vergis
Colin Whitby-Strevens Robert Wilkens Don Wright Oren Yuen Janusz Zalewski
The following were members of the Ballot Response Committee. Eric Anderson Les Baxter Will Harris
David Instone Peter Johansson Win Maung Richard Mourn
Chris Thomas David Thompson Colin Whitby-Strevens
The following individuals have contributed to previous versions of the IEEE 1394 standard. Kazuyuki Abe Bill Anderson Eric Anderson Mark Andresen Tatsuya Arai John Atwood Oleg Awsienko Richard Baker James Baldwin Steven Bard David Barnum Peter Bartlett Max Bassler Les Baxter Patrick Beauperin Bryan Bell Bob Bellino Joe Bennett Vilas Bhade Brad Bickford Phil Bolton Paul L. Borrill David Brief Charles Brill Dave Brown Kevin Brown Mike Brown David Brunker Jim Busse Ed Butler Ed Cady Ramiro Calvo Andy Carter Don Chambers Mike Chastain Dao-Long Chen Carissa Cheung Richard Churchill Kim Clohessy Dan Colegrove Alistair Coles Mike Coletta John Creigh Forrest Crowell Claude Cruz Wayne Davis
vi
Tom Debiec Eric Deliot Dhiru Desai David Doman Chris Dorsey Jim Doyle Bill Duckwall Frank Duffy Sam Duncan Sagar Edara Mike Eneboe Dwayne Escola W. P. Evertz Firooz Farhoomand Lou Fasano Stephen Finch Greg Floryance Mike Fogg Mike Foster Tony Foster Bill Frank Giles Frazier Richard Fryer Taka Fujimori John Fuller Nobuo Furuya Dave Gampell Bob Gannon Edward A. Gardner Mike Gardner James Gay John Gildred Sreekanth Godey Carmen Gonzalez Charles Grant John Grant Michael Griffin David B. Gustavson Steffen Hagene Emil Hahn Ken Hallam Bill Ham Eric Hannah Norm Harris Don Harwood Yasumasa Hasegawa
Mark Hassel Shinichi Hatae David Hatch Jerry Hauck Rick Heidick Keith Heilmann Burke Henehan Joe Herbst John Hill Dan Hillman Daisuke Hiraoka Jack Hollins Walter Hurwitz Derek Imschweiler Tatsuo Inoue David Instone David James Mark Jander Peter Johansson David Johnson Tom Jones Prashant Kanhere Nick Kanzaki Marcus Kellerman Al Kelley Sam Khoo Sean Killeen Jinhee Kim Greg Kite Diana Klashman Mark Knecht Lawence Kopp James Kuo Akihito Kuwabara Ralph Lachenmaier David LaFollette Pascal Lagrange Lawrence J. Lamers Steven Larky Farrukh Latif Michael Lazar Thang Le Yoonsun Lee Wendell Lengefeld Fred Leung Paul S. Levy
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Francesco Liburdi Robert Liu John Lohmeyer John Lopata Ivy Lui Hirokazu Mamezaki Gerald Marazas Jun-ichi Matsuda Takashi Matsui Don May Edward McDonnell Daniel Meirsman Jack Merrow Gene Milligan Keiji Miura Takatoshi Mizoguchi Reza Moattar Palanisamy Mohanraj Cyrus Momeni Charles Monia Neil Morrow Claude Mosley Richard Mourn Ray Muggli Gary Murdock Ganesh Murthy Karl Nakamura James Nave Jay Neer Jim Nelson Richard Nesin Michael Nguyen Bill Northey Takayuki Nyu Dan O’Connor Erich Oetting Ozay Oktay Florin Oprescu Farrell Ostler Kugao Ouchi Bijit Patel Shiva Patibanda Thomas A. Patrick
Scott Petler James Piccione Kevin Pokorney Thomas J. Potyraj Bill Prouty Dennis Rehm Doug Riemer Ron Roberts Jeffrey M. Rosa Bill Russell Kyozo Saito Tomoki Saito Brad Saunders Bradley Saunders Dick Scheel David Scott Don Senzig D. C. Sessions Masood Shariff Robbie Shergill Hisato Shima Mike Shinkarovsky James Skidmore Jim Skidmore David Smith Michael Smith Patricia Smith John Smolka Scott Smyers Robert N. Snively Ron Soderstrom Martin Sodos Michael Sorna Jeff Stai Ken Stewart Chris Stone David Stone Paul Sweazey John Ta Ju-ching Tang Ken Taylor Michael Johas Teener Peter Teng
Victoria Teng Tom Thatcher Lars Thernsjö Barry Thompson David Thompson Richard Thousand C. Brendan Traw Tom Trodden Tom Truman Motoyasu Tsunoda Toru Ueda Renard Ulrey Joel Urban Roger Van Brunt Sushant Verman Hirosha Wakai Hans H. Wang Kenji Watanabe Yuji Watanabe Harvey Watersdorf Kent Waterson Mike Wenzel Alan Wetzel Lee Whetsel Colin Whitby-Strevens Bob Whiteman Dave Wickliff Paul Wiener Doug Williams Lee Wilson Michael Wingard Calto Wong David Wooten Shuntaro Yamazaki Yoshihiko Yano Roy Yasoshima Takao Yasuda Niwa Yoshikatsu Len Young Phil Young Patrick Yu Michael Zarreii Peng Zhang Johann Zipperer
When the IEEE-SA Standards Board approved this revision on 12 June 2008, it had the following membership: Robert M. Grow, Chair Thomas A. Prevost, Vice Chair Steve M. Mills, Past Chair Judith Gorman, Secretary Victor Berman Richard DeBlasio Andy Drozd Mark Epstein Alexander Gelman William R. Goldbach Arnold M. Greenspan Kenneth S. Hanus
Jim Hughes Richard H. Hulett Young Kyun Kim Joseph L. Koepfinger* John Kulick David J. Law Glenn Parsons Ronald C. Petersen
Chuck Powers Narayanan Ramachandran Jon Walter Rosdahl Robby Robson Anne-Marie Sahazizia Malcolm V. Thaden Howard L. Wolfman Don Wright
*Member Emeritus
Copyright © 2008 IEEE. All rights reserved.
vii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Also included are the following nonvoting IEEE-SA Standards Board liaisons: Satish K. Aggarwal, NRC Representative Michael H. Kelly, NIST Representative Jennie Steinhaggen IEEE Standards Program Manager, Document Development Malia Zaman IEEE Standards Program Manager, Technical Program Development
viii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Contents 1.
Overview ............................................................................................................................................. 1 1.1 Scope and purpose...................................................................................................................... 1 1.1.1 Scope ............................................................................................................................. 1 1.1.2 Purpose .......................................................................................................................... 2 1.2 Document organization .............................................................................................................. 2 1.3 Serial bus applications................................................................................................................ 2 1.3.1 Alternate bus.................................................................................................................. 2 1.3.2 Low-cost peripheral bus ................................................................................................ 2 1.3.3 Bus bridge...................................................................................................................... 3 1.4 Service model............................................................................................................................. 3 1.5 Document notation ..................................................................................................................... 4 1.5.1 Mechanical notation ...................................................................................................... 4 1.5.2 Signal naming................................................................................................................ 4 1.5.3 Size notation .................................................................................................................. 4 1.5.4 Numerical values ........................................................................................................... 5 1.5.5 Packet formats ............................................................................................................... 6 1.5.6 Register formats............................................................................................................. 6 1.5.7 C code notation.............................................................................................................. 6 1.5.8 State machine notation .................................................................................................. 8 1.5.9 CSR, ROM, and field notation ...................................................................................... 8 1.5.10 Register specification format......................................................................................... 9 1.5.11 Reserved registers and fields ....................................................................................... 10 1.5.12 Operation description priorities................................................................................... 11 1.6 Compliance............................................................................................................................... 11 1.6.1 CSR architecture compliance ...................................................................................... 11 1.6.2 Serial bus PHYs........................................................................................................... 12
2.
Normative references ........................................................................................................................ 13
3.
Definitions, acronyms, and abbreviations......................................................................................... 17 3.1 Definitions................................................................................................................................ 17 3.2 Acronyms and abbreviations.................................................................................................... 25
4.
Short-haul copper connector and cable specification ....................................................................... 29 4.1 Introduction .............................................................................................................................. 29 4.2 6-circuit Alpha connectors and cables ..................................................................................... 29 4.2.1 6-circuit connectors ..................................................................................................... 30 4.2.1.1 Connector plug ........................................................................................... 30 4.2.1.2 Connector plug terminations ...................................................................... 32 4.2.1.3 Connector socket ........................................................................................ 32 4.2.1.4 Positive retention ........................................................................................ 35 4.2.1.5 Contact finish on plug and socket contacts ................................................ 36 4.2.1.6 Termination finish on plug and contact socket terminals........................... 37 4.2.1.7 Shell finish on plugs and sockets................................................................ 37 4.2.1.8 Connector durability ................................................................................... 37 4.2.2 Cables .......................................................................................................................... 37 4.2.2.1 Cable material............................................................................................. 37 4.2.2.2 Cable assemblies......................................................................................... 37 4.2.3 Connector and cable assembly performance criteria................................................... 37
Copyright © 2008 IEEE. All rights reserved.
ix
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
4.2.3.1
Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration ............................................................................................... 40 4.2.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress.............................................................. 41 4.2.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress ..................................................................................... 42 4.2.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure......................................... 43 4.2.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress............................................................. 45 4.2.3.6 Performance group F: Mechanical retention and durability ....................... 46 4.2.3.7 Performance group G: General tests........................................................... 47 4.2.4 Signal propagation performance.................................................................................. 48 4.2.4.1 Signal impedance........................................................................................ 48 4.2.4.2 Signal pairs attenuation .............................................................................. 48 4.2.4.3 Signal pairs velocity of propagation ........................................................... 49 4.2.4.4 Signal pairs relative propagation skew ....................................................... 49 4.2.4.5 Power pair characteristic impedance .......................................................... 49 4.2.4.6 Power pair dc resistance ............................................................................. 49 4.2.4.7 Crosstalk ..................................................................................................... 50 4.3 4-circuit Alpha connectors and cables ..................................................................................... 50 4.3.1 Connectors................................................................................................................... 50 4.3.1.1 Connector plug ........................................................................................... 50 4.3.1.2 Connector plug terminations ...................................................................... 50 4.3.1.3 Connector socket ........................................................................................ 52 4.3.1.4 Contact finish on plug and socket contacts ................................................ 54 4.3.1.5 Termination finish on plug and contact socket terminals........................... 54 4.3.1.6 Shell finish on plugs and sockets................................................................ 54 4.3.1.7 Connector durability ................................................................................... 54 4.3.1.8 PCB footprints ............................................................................................ 55 4.3.2 Cables .......................................................................................................................... 56 4.3.2.1 Cable material............................................................................................. 56 4.3.2.2 Cable assemblies......................................................................................... 56 4.3.3 Connector and cable assembly performance criteria................................................... 57 4.3.3.1 Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration ............................................................................................... 58 4.3.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress.............................................................. 59 4.3.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress ..................................................................................... 60 4.3.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure......................................... 61 4.3.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress............................................................. 63 4.3.3.6 Performance group F: Mechanical retention and durability ....................... 64 4.3.3.7 Performance group G: General tests........................................................... 65 4.3.4 Signal propagation performance criteria ..................................................................... 67 4.3.4.1 Signal impedance........................................................................................ 67 4.3.4.2 Signal pairs attenuation .............................................................................. 67 4.3.4.3 Signal pairs propagation delay ................................................................... 67 4.3.4.4 Signal pairs relative propagation skew ....................................................... 68 4.3.4.5 Crosstalk ..................................................................................................... 68
x
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
4.4 9-circuit Beta and bilingual connectors and cables.................................................................. 68 4.4.1 9-circuit Beta and bilingual connectors....................................................................... 68 4.4.1.1 Plug cable termination method ................................................................... 70 4.4.1.2 Socket ......................................................................................................... 70 4.4.1.3 Mating area finish on plug and socket contacts.......................................... 79 4.4.1.4 Termination area finish on plug and socket contacts ................................. 79 4.4.1.5 Shell finish on plugs and sockets................................................................ 79 4.4.1.6 Durability.................................................................................................... 79 4.4.1.7 Socket PCB termination footprints and PHY trace routing........................ 80 4.4.1.8 Plug overmold............................................................................................. 82 4.4.1.9 Socket orientation preference ..................................................................... 82 4.4.2 Cables .......................................................................................................................... 82 4.4.2.1 Reference cable material for Beta-to-Beta cable assemblies...................... 83 4.4.2.2 Reference cable material for bilingual-to-Alpha cable assemblies ............ 84 4.4.2.3 Cable assemblies......................................................................................... 84 4.4.3 Connector and cable assembly performance criteria................................................... 88 4.4.3.1 Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration ............................................................................................... 89 4.4.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress.............................................................. 90 4.4.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress ..................................................................................... 91 4.4.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure......................................... 92 4.4.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress............................................................. 94 4.4.3.6 Performance group F: Mechanical retention and durability ....................... 95 4.4.3.7 Performance group G: General tests........................................................... 95 4.4.4 Signal propagation performance criteria ..................................................................... 97 4.4.4.1 Test hardware ............................................................................................. 97 4.4.4.2 Signal impedance...................................................................................... 100 4.4.4.3 Signal pairs attenuation ............................................................................ 101 4.4.4.4 Signal pairs velocity of propagation ......................................................... 102 4.4.4.5 Signal pairs intrapair propagation skew ................................................... 103 4.4.4.6 Crosstalk ................................................................................................... 104 4.4.4.7 Power ........................................................................................................ 104 5.
Backplane PHY specification ......................................................................................................... 105 5.1 Backplane PHY services ........................................................................................................ 105 5.1.1 Backplane PHY bus management services for the management layer ..................... 106 5.1.1.1 PHY control request (PH_CONTROL.request) ....................................... 106 5.1.1.2 PHY control confirmation (PH_CONTROL.confirmation) ..................... 106 5.1.1.3 PHY event indication (PH_EVENT.indication)....................................... 107 5.1.2 PHY layer arbitration services for the link layer....................................................... 107 5.1.2.1 PHY arbitration request (PH_ARB.request) ............................................ 107 5.1.2.2 PHY arbitration confirmation (PH_ARB.confirmation) .......................... 108 5.1.3 PHY layer data services for the link layer................................................................. 108 5.1.3.1 PHY clock indication (PH_CLOCK.indication) ...................................... 108 5.1.3.2 PHY data request (PH_DATA.request).................................................... 108 5.1.3.3 PHY data indication (PH_DATA.indication)........................................... 109 5.2 Backplane physical connection specification......................................................................... 109 5.2.1 Media attachment ...................................................................................................... 110
Copyright © 2008 IEEE. All rights reserved.
xi
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
5.2.1.1 Distribution of nodes ................................................................................ 110 5.2.1.2 Fault detection and isolation..................................................................... 110 5.2.1.3 Live insertion ............................................................................................ 111 5.2.2 Media signal interface ............................................................................................... 111 5.2.2.1 Definition of logic states........................................................................... 111 5.2.2.2 Bit rates..................................................................................................... 112 5.2.2.3 Transition times ........................................................................................ 112 5.2.2.4 Noise rejection .......................................................................................... 112 5.2.3 Media signal timing................................................................................................... 112 5.2.3.1 Backplane transmit data timing ................................................................ 112 5.2.3.2 Backplane receive data timing.................................................................. 113 5.2.3.3 Backplane and transceiver skew............................................................... 114 5.2.4 Backplane PHY timing.............................................................................................. 114 5.2.4.1 Arbitration clock rate................................................................................ 115 5.2.4.2 Bus synchronization and propagation delay ............................................. 115 5.2.4.3 Arbitration bit timing................................................................................ 116 5.3 Backplane PHY facilities ....................................................................................................... 118 5.3.1 Coding ....................................................................................................................... 118 5.3.2 Backplane PHY signals ............................................................................................. 118 5.3.3 Gap timing ................................................................................................................. 119 5.3.4 Arbitration sequence.................................................................................................. 120 5.3.4.1 Arbitration number ................................................................................... 120 5.3.4.2 Priority ...................................................................................................... 120 5.3.4.3 Format of arbitration sequence ................................................................. 121 5.4 Backplane PHY operation...................................................................................................... 121 5.4.1 Arbitration ................................................................................................................. 122 5.4.1.1 Fairness intervals ...................................................................................... 122 5.4.1.2 Fair arbitration .......................................................................................... 123 5.4.1.3 Urgent arbitration ..................................................................................... 124 5.4.1.4 Arbitration by the cycle master ................................................................ 125 5.4.1.5 Isochronous arbitration ............................................................................. 125 5.4.1.6 Immediate arbitration ............................................................................... 125 5.4.2 Backplane environment packet transmission and reception...................................... 125 5.4.2.1 Backplane environment packet transmission ........................................... 126 5.4.2.2 Backplane environment packet reception................................................. 127 5.5 Backplane initialization and reset .......................................................................................... 128 5.5.1 Backplane PHY reset................................................................................................. 128 5.5.1.1 Command reset ......................................................................................... 128 5.5.1.2 Bus reset ................................................................................................... 128 5.5.2 Backplane PHY initialization .................................................................................... 128 6.
Link layer specification................................................................................................................... 129 6.1 Link layer services ................................................................................................................. 129 6.1.1 Link layer bus management services for the node controller.................................... 130 6.1.1.1 Link control request (LK_CONTROL.request) ....................................... 130 6.1.1.2 Link control confirmation (LK_CONTROL.confirmation) ..................... 131 6.1.1.3 Link event indication (LK_EVENT.indication) ....................................... 131 6.1.1.4 Link remote configuration request (LK_CONFIG.request) (cable environment only).......................................................................... 131 6.1.1.5 Link remote configuration indication (LK_CONFIG.indication) (cable environment only).......................................................................... 132 6.1.2 Link layer asynchronous data services for the transaction layer............................... 132 6.1.2.1 Link data request (LK_DATA.request).................................................... 132
xii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
6.1.2.2 Link data confirmation (LK_DATA.confirmation).................................. 133 6.1.2.3 Link data indication (LK_DATA.indication) ........................................... 133 6.1.2.4 Link data response (LK_DATA.response) ............................................... 134 6.1.2.5 Link bus indication (LK_BUS.indication) ............................................... 134 6.1.3 Link layer isochronous data services for application layers...................................... 134 6.1.3.1 Link isochronous control request (LK_ISO_CONTROL.request)........... 134 6.1.3.2 Link cycle sync indication (LK_CYCLE.indication)............................... 135 6.1.3.3 Link isochronous request (LK_ISO.request)............................................ 135 6.1.3.4 Link isochronous indication (LK_ISO.indication) ................................... 135 6.2 Link layer facilities................................................................................................................. 136 6.2.1 Primary packets ......................................................................................................... 136 6.2.2 Asynchronous packets ............................................................................................... 137 6.2.2.1 Asynchronous packets with no-data payload ........................................... 138 6.2.2.2 Asynchronous packet formats with data quadlet payload ........................ 139 6.2.2.3 Asynchronous packet formats with data block payload ........................... 142 6.2.3 Isochronous packets................................................................................................... 145 6.2.3.1 Isochronous packet components ............................................................... 145 6.2.3.2 Isochronous data block packet format ...................................................... 146 6.2.4 Asynchronous streams............................................................................................... 147 6.2.4.1 Asynchronous stream packet format ........................................................ 147 6.2.4.2 Global asynchronous stream packet (GASP) format................................ 148 6.2.4.3 Loose vs. strict isochronous packet reception .......................................... 149 6.2.5 Primary packet components ...................................................................................... 149 6.2.5.1 Reserved fields, codes, and values ........................................................... 149 6.2.5.2 Destination address................................................................................... 149 6.2.5.3 Transaction label (tl)................................................................................. 150 6.2.5.4 Retry code (rt)........................................................................................... 150 6.2.5.5 Transaction code (tcode) .......................................................................... 150 6.2.5.6 Priority (pri) .............................................................................................. 152 6.2.5.7 Source ID (source_ID).............................................................................. 152 6.2.5.8 Data length (data_length) ......................................................................... 152 6.2.5.9 Extended transaction code (extended_tcode) ........................................... 152 6.2.5.10 Response code (rcode).............................................................................. 153 6.2.5.11 Data field .................................................................................................. 153 6.2.5.12 Tag (isochronous stream packets) ............................................................ 153 6.2.5.13 Channel ..................................................................................................... 153 6.2.5.14 Synchronization code (sy) ........................................................................ 154 6.2.5.15 CRCs......................................................................................................... 154 6.2.6 Acknowledge packets................................................................................................ 155 6.2.6.1 Acknowledge packet format ..................................................................... 156 6.2.6.2 ACK packet components .......................................................................... 156 6.3 Link layer operation ............................................................................................................... 158 6.3.1 Overview of link layer operation............................................................................... 158 6.3.1.1 Communication with the PHY layer ........................................................ 158 6.3.1.2 Priority arbitration for PHY packets and response packets ...................... 159 6.3.1.3 Sending an asynchronous packet .............................................................. 159 6.3.1.4 Receiving an asynchronous packet........................................................... 159 6.3.1.5 Sending an acknowledge concatenated to an asynchronous packet ......... 160 6.3.1.6 Isochronous cycles.................................................................................... 160 6.3.1.7 Sending isochronous packets.................................................................... 160 6.3.1.8 Receiving an isochronous packet ............................................................. 160 6.3.2 Cycle sync event........................................................................................................ 161 6.3.3 Details of link layer operation ................................................................................... 162 6.3.3.1 Link initialization ..................................................................................... 163
Copyright © 2008 IEEE. All rights reserved.
xiii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
6.3.3.2 Asynchronous operation ........................................................................... 163 6.3.3.3 Isochronous operation............................................................................... 166 6.4 Link layer reference code....................................................................................................... 168 7.
Transaction layer specification ....................................................................................................... 171 7.1 Transaction layer services ...................................................................................................... 171 7.1.1 Transaction layer bus management services for SBM .............................................. 171 7.1.1.1 Transaction control request (TR_CONTROL.request) ............................ 172 7.1.1.2 Transaction control confirmation (TR_CONTROL.confirmation) .......... 172 7.1.1.3 Transaction event indication (TR_EVENT.indication)............................ 172 7.1.2 Transaction layer data services for applications and bus management..................... 172 7.1.2.1 Transaction data request (TR_DATA.request)......................................... 173 7.1.2.2 Transaction data confirmation (TR_DATA.confirmation) ...................... 173 7.1.2.3 Transaction data indication (TR_DATA.indication)................................ 174 7.1.2.4 Transaction data response (TR_DATA.response).................................... 174 7.2 Transaction facilities .............................................................................................................. 175 7.2.1 Split transaction timer................................................................................................ 175 7.2.2 Transaction retry limit ............................................................................................... 175 7.3 Transaction operation............................................................................................................. 175 7.3.1 Overview of transaction layer operations.................................................................. 175 7.3.1.1 Read transactions ...................................................................................... 176 7.3.1.2 Write transactions ..................................................................................... 176 7.3.1.3 Lock transactions ...................................................................................... 177 7.3.1.4 Response codes (rcode) ............................................................................ 177 7.3.1.5 Error handling........................................................................................... 179 7.3.2 Transaction completion definitions ........................................................................... 179 7.3.2.1 Unified transaction ................................................................................... 180 7.3.2.2 Split transaction ........................................................................................ 180 7.3.2.3 Concatenated transaction .......................................................................... 180 7.3.2.4 Broadcast transaction................................................................................ 180 7.3.2.5 Pending transaction................................................................................... 180 7.3.3 Details of transaction layer operation........................................................................ 180 7.3.3.1 Outbound transaction state machine......................................................... 181 7.3.3.2 Inbound transaction state machine ........................................................... 184 7.3.4 Transaction types....................................................................................................... 188 7.3.4.1 Read transactions ...................................................................................... 188 7.3.4.2 Write transactions ..................................................................................... 188 7.3.4.3 Lock transactions ...................................................................................... 188 7.3.5 Retry protocols .......................................................................................................... 189 7.3.5.1 Outbound subaction retry protocol ........................................................... 190 7.3.5.2 Inbound subaction single-phase retry protocol......................................... 191 7.3.5.3 Inbound subaction dual-phase retry protocol ........................................... 191 7.4 CSR architecture transactions mapped to serial bus .............................................................. 194
8.
Serial bus management (SBM) specification.................................................................................. 197 8.1 SBM summary........................................................................................................................ 197 8.1.1 Node control .............................................................................................................. 197 8.1.2 IRM (cable environment) .......................................................................................... 197 8.1.3 IRM (backplane environment) .................................................................................. 197 8.1.4 Bus manager (cable environment)............................................................................. 197 8.2 SBM services.......................................................................................................................... 198 8.2.1 Serial bus control request (SB_CONTROL.request) ................................................ 198
xiv
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
8.2.2 Serial bus control confirmation (SB_CONTROL.confirmation) .............................. 199 8.2.3 Serial bus event indication (SB_EVENT. indication)............................................... 199 8.3 SBM facilities......................................................................................................................... 201 8.3.1 Node capabilities taxonomy ...................................................................................... 201 8.3.1.1 Repeater (cable environment)................................................................... 201 8.3.1.2 Transaction capable .................................................................................. 201 8.3.1.3 Isochronous capable ................................................................................. 202 8.3.1.4 Cycle master capable ................................................................................ 202 8.3.1.5 IRM capable ............................................................................................. 202 8.3.1.6 Bus manager capable (cable environment)............................................... 202 8.3.2 Command and status registers ................................................................................... 203 8.3.2.1 Reset conditions........................................................................................ 203 8.3.2.2 CSR architecture core registers ................................................................ 204 8.3.2.3 Serial-Bus-dependent registers ................................................................. 209 8.3.2.4 Unit registers............................................................................................. 221 8.3.2.5 TOPOLOGY_MAP registers (cable environment) .................................. 222 8.3.2.6 Configuration ROM.................................................................................. 223 8.3.3 SBM variables ........................................................................................................... 229 8.4 SBM operations...................................................................................................................... 229 8.4.1 Bus configuration procedures (backplane environment)........................................... 229 8.4.1.1 Unmanaged bus (backplane environment) ............................................... 230 8.4.1.2 Determination of the IRM (backplane environment) ............................... 230 8.4.1.3 Determination of the cycle master (backplane environment)................... 230 8.4.2 Bus configuration procedures (cable environment) .................................................. 230 8.4.2.1 Unmanaged bus (cable environment) ....................................................... 230 8.4.2.2 Prior isochronous traffic (cable environment).......................................... 231 8.4.2.3 Determination of the IRM (cable environment) ....................................... 231 8.4.2.4 Reallocation of prior isochronous resources (cable environment) ........... 232 8.4.2.5 Determination of the bus manager (cable environment) .......................... 232 8.4.2.6 Determination of the cycle master (cable environment) .......................... 232 8.4.2.7 Determination of the root (cable environment) ........................................ 233 8.4.2.8 Power management by the IRM (cable environment).............................. 234 8.4.2.9 Allocation of new isochronous resources (cable environment)................ 234 8.4.3 Isochronous resource allocation (cable environment)............................................... 234 8.4.3.1 Bandwidth allocation ................................................................................ 234 8.4.3.2 Channel allocation .................................................................................... 235 8.4.3.3 Bandwidth set-aside.................................................................................. 236 8.4.3.4 Isochronous requests with no cycle master .............................................. 236 8.4.4 Power management (cable environment) .................................................................. 236 8.4.4.1 PHY power management.......................................................................... 237 8.4.4.2 Link power management .......................................................................... 237 8.4.4.3 Unit power management........................................................................... 237 8.4.4.4 Power management by the bus manager .................................................. 237 8.4.4.5 Power management by the IRM ............................................................... 238 8.4.5 Topology management (cable environment)............................................................. 238 8.4.5.1 Accessing the topology map..................................................................... 238 8.4.5.2 Gap count optimization ............................................................................ 239 8.4.6 Filtered packets on an asynchronous-only B_bus ..................................................... 239 8.5 Bus configuration state machines (cable environment) ......................................................... 239 8.5.1 Candidate cycle master states.................................................................................... 240 8.5.2 Candidate IRM states ................................................................................................ 241 8.5.3 Candidate bus manager states.................................................................................... 242 8.5.4 Abdication by the bus manager ................................................................................. 244
Copyright © 2008 IEEE. All rights reserved.
xv
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
9.
Short-haul copper PMD electrical specification ............................................................................. 245 9.1 Introduction ............................................................................................................................ 245 9.1.1 Short-haul copper PHY operation ............................................................................. 245 9.1.2 Short-haul copper physical connection specification ................................................ 247 9.1.3 Interfaces ................................................................................................................... 248 9.1.4 Modes of operation.................................................................................................... 248 9.2 Data-strobe (DS) mode specification ..................................................................................... 248 9.2.1 Port interface ............................................................................................................. 248 9.2.1.1 Signal amplitude ....................................................................................... 250 9.2.1.2 Common mode voltage............................................................................. 251 9.2.1.3 Speed signaling......................................................................................... 252 9.2.1.4 Arbitration signal voltages........................................................................ 253 9.2.1.5 Input impedance ....................................................................................... 254 9.2.1.6 Noise ......................................................................................................... 254 9.2.1.7 Driver and receiver fault protection.......................................................... 255 9.2.2 Media signal timing................................................................................................... 255 9.2.2.1 Data rate.................................................................................................... 255 9.2.2.2 Data signal rise and fall times................................................................... 255 9.2.2.3 Jitter and skew .......................................................................................... 256 9.2.3 Coding ....................................................................................................................... 256 9.2.4 DS PHY signals......................................................................................................... 256 9.2.5 DS PHY line states .................................................................................................... 257 9.2.6 Cable PHY timing constants ..................................................................................... 259 9.2.7 Gap timing ................................................................................................................. 264 9.2.8 Speed signal sampling and filtering .......................................................................... 265 9.2.9 Data transmission and reception................................................................................ 266 9.2.9.1 Data transmission ..................................................................................... 266 9.2.9.2 Data reception and repeat ......................................................................... 267 9.3 Beta mode specification ......................................................................................................... 267 9.3.1 Transmitter electrical specifications.......................................................................... 267 9.3.2 Receiver electrical specifications .............................................................................. 271 9.3.2.1 S3200 equalization ................................................................................... 275 9.3.3 Electrical measurements............................................................................................ 275 9.3.3.1 Transmit rise and fall time........................................................................ 275 9.3.3.2 Transmit skew........................................................................................... 275 9.3.3.3 Transmit eye (normalized and absolute) .................................................. 276 9.3.3.4 Rise and fall time setting for receiver jitter tolerance test ........................ 276 9.3.3.5 Skew setting for receiver jitter tolerance test ........................................... 276 9.3.3.6 Receiver jitter tolerance............................................................................ 277 9.3.3.7 Minimum amplitude for receiver jitter tolerance test ............................... 277 9.3.3.8 S3200 BER ............................................................................................... 278 9.3.3.9 S3200 electrical test configuration ........................................................... 278 9.3.4 DC biasing ................................................................................................................. 278 9.3.5 Toning and signal detect............................................................................................ 279 9.3.5.1 Connection tone ........................................................................................ 279 9.3.5.2 PMD signal detect function ...................................................................... 280 9.3.5.3 Application note ....................................................................................... 281 9.3.6 Jitter specifications .................................................................................................... 281 9.3.7 Intrapair skew ............................................................................................................ 285 9.3.8 Termination and isolation.......................................................................................... 285 9.3.8.1 Bilingual port termination and isolation ................................................... 285 9.3.8.2 Beta-only port termination and isolation .................................................. 286 9.3.8.3 PIL-FOP termination and isolation........................................................... 287
xvi
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
9.4 Cable power and ground ........................................................................................................ 288 9.4.1 Node power classes ................................................................................................... 288 9.4.2 Ground isolation ........................................................................................................ 290 9.4.2.1 Primary power providers .......................................................................... 291 9.4.2.2 Secondary power provider........................................................................ 291 9.4.3 Protection against late VG......................................................................................... 291 10.
Glass optical fiber (GOF) PMD specification................................................................................. 295 10.1 10.2 10.3 10.4 10.5 10.6 10.7
PMD block diagram ............................................................................................................... 296 PMD-to-MDI optical specifications....................................................................................... 296 Transmitter optical specifications .......................................................................................... 297 Receiver optical specifications............................................................................................... 297 Worst-case connection optical power budget and penalties................................................... 298 Optical jitter specifications..................................................................................................... 299 Optical measurement requirements........................................................................................ 301 10.7.1 Center wavelength and spectral width measurements............................................... 301 10.7.2 Optical power measurements .................................................................................... 301 10.7.3 Extinction ratio measurements .................................................................................. 301 10.7.4 Relative intensity noise (RIN) ................................................................................... 301 10.7.5 Transmitter optical waveform (transmit eye) ............................................................ 301 10.7.6 Transmit rise and fall characteristics......................................................................... 302 10.7.7 Receiver sensitivity measurements............................................................................ 303 10.7.8 Jitter measurements ................................................................................................... 303 10.8 CPR measurement .................................................................................................................. 303 10.9 Optical connection cabling model.......................................................................................... 303 10.9.1 Characteristics of the fiber optic medium ................................................................. 303 10.9.2 Optical fiber and cable............................................................................................... 304 10.9.3 Multimode connector insertion loss .......................................................................... 304 10.9.4 Optical connection return loss ................................................................................... 304 10.10Optical connection ................................................................................................................. 304 10.11Fiber launch conditions: OFL ................................................................................................ 305 11.
PMD specification of fiber media with PN connector .................................................................... 307 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8
12.
Scope ...................................................................................................................................... 307 PMD block diagram ............................................................................................................... 308 Cables ..................................................................................................................................... 308 Connector ............................................................................................................................... 309 Connector and cable assembly performance criteria.............................................................. 310 Optical fiber interface............................................................................................................. 310 Optical jitter specifications..................................................................................................... 310 Permitted number of segments............................................................................................... 310
Unshielded twisted pair (UTP) PMD specification ....................................................................... 315 12.1 12.2 12.3 12.4
Overview ................................................................................................................................ 316 PMD block diagram ............................................................................................................... 316 Operation of UTP connections............................................................................................... 316 Media specification ................................................................................................................ 317 12.4.1 100 Ohm UTP connection segment specification ..................................................... 317 12.4.2 100 Ohm UTP cable specification............................................................................ 317 12.4.3 Connecting hardware................................................................................................. 317 12.4.4 Media interface connector ......................................................................................... 318
Copyright © 2008 IEEE. All rights reserved.
xvii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
12.4.5 Autocrossover............................................................................................................ 319 12.5 PMD electrical specifications................................................................................................. 319 12.5.1 Galvanic isolation...................................................................................................... 319 12.5.2 Transmitter specifications ......................................................................................... 320 12.5.3 Receiver specifications.............................................................................................. 323 12.5.3.1 Receiver input signals............................................................................... 323 12.5.3.2 PMD signal detect function ...................................................................... 323 12.6 PMD implementation ............................................................................................................. 325 13.
Beta mode port specification........................................................................................................... 327 13.1 Overview ................................................................................................................................ 327 13.2 Port functions ......................................................................................................................... 328 13.2.1 Overview ................................................................................................................... 328 13.2.2 Naming conventions.................................................................................................. 329 13.2.3 Control mapping........................................................................................................ 329 13.2.4 Request types............................................................................................................. 330 13.2.4.1 BOSS arbitration request mapping ........................................................... 330 13.2.4.2 Configuration requests.............................................................................. 332 13.2.5 Scrambling................................................................................................................. 332 13.2.5.1 Data scrambling ........................................................................................ 333 13.2.5.2 Request symbol scrambling...................................................................... 334 13.2.5.3 Control symbol scrambling ...................................................................... 335 13.2.6 Coding ....................................................................................................................... 336 13.2.6.1 8B/10B character coding for data and request types ................................ 336 13.2.6.2 Control coding .......................................................................................... 346 13.2.7 Character transmission .............................................................................................. 348 13.2.8 Decoding.................................................................................................................... 348 13.2.8.1 Bit and character synchronization ............................................................ 348 13.2.8.2 Data and control character decoding and error detection ......................... 348 13.2.8.3 Special character decoding ....................................................................... 348 13.2.9 Receiver running disparity ........................................................................................ 348 13.2.10 Descrambling............................................................................................................. 349 13.3 Beta mode port operation ....................................................................................................... 349 13.3.1 Transmit operations ................................................................................................... 349 13.3.1.1 Control transmission................................................................................. 349 13.3.1.2 Request transmission ................................................................................ 350 13.3.1.3 Packet transmission .................................................................................. 350 13.3.1.4 Speed signaling......................................................................................... 351 13.3.1.5 Payload transmission ................................................................................ 352 13.3.2 Receive operations..................................................................................................... 353 13.3.2.1 Port training .............................................................................................. 353 13.3.2.2 Control reception ...................................................................................... 354 13.3.2.3 Request type reception.............................................................................. 354 13.3.2.4 DATA_PREFIX reception ....................................................................... 355 13.3.2.5 Speed code determination......................................................................... 355 13.3.2.6 Payload reception ..................................................................................... 356 13.3.2.7 Error reporting .......................................................................................... 357 13.4 Beta port state machines......................................................................................................... 357 13.4.1 Port transmit state machine ....................................................................................... 358 13.4.2 Port receive state machine ......................................................................................... 359
14.
xviii
Connection management................................................................................................................. 361
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
14.1 Overview ................................................................................................................................ 361 14.2 Port characteristics ................................................................................................................. 362 14.2.1 Requirements............................................................................................................. 362 14.2.2 Properties................................................................................................................... 363 14.3 Functions, variables, and constants ........................................................................................ 363 14.4 Node-level port controller ...................................................................................................... 366 14.5 Port connection manager state machine ................................................................................. 366 14.6 Standby................................................................................................................................... 371 14.6.1 Nephew node characteristics ..................................................................................... 372 14.6.2 Uncle node characteristics......................................................................................... 372 14.7 Loop prevention ..................................................................................................................... 373 14.7.1 Test port..................................................................................................................... 373 14.7.2 Loop test data (LTD) ................................................................................................. 374 14.7.2.1 M bit ......................................................................................................... 374 14.7.2.2 G bit .......................................................................................................... 374 14.7.2.3 test_value number .............................................................................. 375 14.7.3 Holding register (HR)................................................................................................ 375 14.7.4 Maximum occupancy timer....................................................................................... 375 14.7.5 Loop test symbol (LTS)............................................................................................. 375 14.7.6 Loop test packet (LTP).............................................................................................. 376 14.7.7 Test port selection...................................................................................................... 376 14.7.8 Loop test .................................................................................................................... 376 14.7.9 Completing the attach................................................................................................ 377 14.7.10 Received ATTACH_REQUEST or bus reset............................................................ 378 14.7.11 Loop Disabled state ................................................................................................... 378 14.7.12 Connections to Alpha nodes...................................................................................... 378 14.7.13 Loop detection during bus initialization.................................................................... 378 14.7.14 Minimal LTP support ................................................................................................ 379 14.7.15 Isolated node behavior............................................................................................... 379 14.8 Connection management ........................................................................................................ 379 14.8.1 Connection detection ................................................................................................. 379 14.8.2 Connection detection and mode determination algorithm......................................... 379 14.8.3 Beta-mode speed negotiation .................................................................................... 380 14.8.4 Disabled ports............................................................................................................ 382 14.9 T-mode connectivity and operation........................................................................................ 383 14.10Simultaneous support for Beta mode and T-mode................................................................. 383 14.11Negotiation............................................................................................................................. 383 14.11.1 Overview ................................................................................................................... 383 14.11.2 S100 Beta mode parallel negotiation......................................................................... 384 14.11.2.1 Clause 22 in IEEE Std 802.3-2005 ........................................................... 384 14.11.3 Differences between T-mode and IEEE 802.3 negotiation ....................................... 384 14.11.3.1 Clause 28 in IEEE Std 802.3-2005 ........................................................... 385 14.11.3.2 Annex 28A in IEEE Std 802.3-2005 ........................................................ 387 14.11.3.3 Annex 28B in IEEE Std 802.3-2005 ........................................................ 387 14.11.3.4 Annex 28C in IEEE Std 802.3-2005 ........................................................ 387 14.11.3.5 Subclause 40.5 in IEEE Std 802.3-2005................................................... 388 15.
PHY register map............................................................................................................................ 389 15.1 Arbitration compliance levels ................................................................................................ 389 15.1.1 Arbitration Compliance Level A ............................................................................... 389 15.1.2 Arbitration Compliance Level B ............................................................................... 389 15.2 PHY register map for the cable environment......................................................................... 389 15.2.1 Port Status page ......................................................................................................... 394
Copyright © 2008 IEEE. All rights reserved.
xix
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
15.2.2 Vendor Identification page ........................................................................................ 398 15.3 PHY register map for the backplane environment ................................................................. 399 15.4 Integrated link and PHY......................................................................................................... 400 16.
Data routing, arbitration, and control.............................................................................................. 401 16.1 Overview ................................................................................................................................ 401 16.2 PHY services .......................................................................................................................... 402 16.2.1 Cable PHY bus management services for the management layer............................. 403 16.2.1.1 PHY control request (PH_CONTROL.request) ....................................... 403 16.2.1.2 PHY control confirmation (PH_CONTROL.confirmation) ..................... 403 16.2.1.3 PHY event indication (PH_EVENT.indication)....................................... 403 16.2.1.4 PHY event response (PH_EVENT.response)........................................... 404 16.2.1.5 PHY link type inquiry indication (PH_LINK_TYPE.indication) and response (PH_LINK_TYPE.response) .............................................. 404 16.2.2 PHY arbitration services for the link layer................................................................ 405 16.2.2.1 PHY arbitration request (PH_ARB.request) ............................................ 405 16.2.2.2 PHY arbitration confirmation (PH_ARB.conf)........................................ 407 16.2.3 PHY data services for the link layer.......................................................................... 407 16.2.3.1 PHY clock indication (PH_CLOCK.indication) ...................................... 408 16.2.3.2 PHY data request (PH_DATA.request).................................................... 408 16.2.3.3 PHY data indication (PH_DATA.indication)........................................... 409 16.2.4 PHY-link interface block........................................................................................... 409 16.2.5 PMD services for the PHY ........................................................................................ 410 16.2.5.1 PMD control request (PMD_CONTROL.request) ................................... 410 16.2.5.2 PMD status request (PMD_STATUS.request) and confirmation (PMD_STATUS.confirmation) ................................................................ 410 16.2.5.3 PMD Beta port data indication (PMD_DATA.indication)....................... 411 16.2.5.4 PMD Beta port transmit data request (PMD_DATA.request) ................. 411 16.2.5.5 PMD DS port receive signal request (PMD_DSPORT_SIGNAL.request) and confirmation (PMD_DSPORT_SIGNAL.confirmation)................... 411 16.2.5.6 PMD DS port receive speed request (PMD_DSPORT_RXSPEED.request) and confirmation (PMD_DSPORT_RXSPEED.confirmation)................ 412 16.2.5.7 PMD DS port transmit data request (PMD_DSPORT_DATA.request) .. 412 16.2.5.8 PMD DS port transmit arbitration state request (PMD_DSPORT_ARB.request)............................................................... 412 16.2.5.9 PMD DS port transmit speed request (PMD_DSPORT_TXSPEED.request) ..................................................... 412 16.2.5.10 PMD DS port TpBias request (PMD_DSPORT_TPBIAS.request) ......... 413 16.2.5.11 PMD cable power status request (PMD_PS.request) and confirmation (PMD_PS.confirmation)........................................................................... 413 16.2.5.12 PMD cable speed request (PMD_CABLE_SPEED.request) and confirmation (PMD_CABLE_SPEED.confirmation) .............................. 413 16.3 PHY facilities ......................................................................................................................... 413 16.3.1 PHY packet overview................................................................................................ 413 16.3.1.1 PHY packet transmission and reception ................................................... 413 16.3.1.2 PHY packet identifier bits ........................................................................ 414 16.3.2 Alpha packet formats................................................................................................. 414 16.3.2.1 Alpha self-ID packets ............................................................................... 415 16.3.2.2 Alpha Link-on packet ............................................................................... 417 16.3.2.3 Alpha PHY configuration packet ............................................................. 417 16.3.2.4 Alpha extended PHY packets ................................................................... 418 16.3.3 Beta PHY packet formats .......................................................................................... 422 16.3.3.1 Beta self-ID packets.................................................................................. 422
xx
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
16.3.3.2 Beta Remote command packet ................................................................. 424 16.3.3.3 Beta Remote confirmation packet ............................................................ 425 16.3.3.4 Beta PHY configuration packet ................................................................ 426 16.3.3.5 Loop test packet (LTP) ............................................................................. 427 16.3.4 Data packet formats................................................................................................... 428 16.3.4.1 Alpha and Beta packet formats................................................................. 428 16.3.4.2 General packet format .............................................................................. 428 16.3.4.3 Alpha format with speed code .................................................................. 429 16.3.4.4 Alpha format for S100 packets without speed code ................................. 430 16.3.4.5 Beta format for all packet speeds ............................................................. 431 16.3.4.6 Minimum packet spacing.......................................................................... 431 16.3.4.7 Deletable symbols..................................................................................... 431 16.3.4.8 Packet transmission examples .................................................................. 432 16.3.5 Packet forwarding...................................................................................................... 433 16.3.5.1 Packets at speeds greater than the port operating speed ........................... 433 16.3.5.2 Packet forwarding: DS port to Beta port .................................................. 433 16.3.5.3 Packet forwarding: Beta port to DS port .................................................. 433 16.4 Cable PHY operation ............................................................................................................. 434 16.4.1 C code functions and variables.................................................................................. 434 16.4.2 Arbitration ................................................................................................................. 436 16.4.2.1 DS-mode arbitration ................................................................................. 436 16.4.2.2 Beta-mode arbitration ............................................................................... 436 16.4.3 Hybrid bus operation ................................................................................................. 439 16.4.3.1 Hybrid bus initialization ........................................................................... 439 16.4.3.2 Border node functions .............................................................................. 440 16.4.3.3 BORDER request mapping ...................................................................... 442 16.4.3.4 Discussion of root outside the Beta cloud ................................................ 442 16.4.4 Isochronous intervals................................................................................................. 443 16.4.5 Bus reset state machine ............................................................................................. 446 16.4.6 Tree identification state machine............................................................................... 448 16.4.7 Self-identification state machine ............................................................................... 450 16.4.8 Arbitration state machine .......................................................................................... 453 16.4.9 Large diameter networks ........................................................................................... 456 16.4.9.1 BOSS_RESTART_TIME......................................................................... 456 16.4.9.2 TEST_INTERVAL................................................................................... 457 17.
Parallel PHY-link interface ............................................................................................................. 459 17.1 Introduction ............................................................................................................................ 459 17.2 Alpha (A) PHY-link interface specification........................................................................... 460 17.2.1 Initialization and reset ............................................................................................... 463 17.2.2 Link-on and interrupt indications .............................................................................. 466 17.2.3 Link requests ............................................................................................................. 466 17.2.3.1 LReq rules................................................................................................. 471 17.2.3.2 Acceleration control ................................................................................. 474 17.2.4 Status ......................................................................................................................... 474 17.2.5 Transmit..................................................................................................................... 476 17.2.6 Cancel ........................................................................................................................ 478 17.2.7 Receive ...................................................................................................................... 479 17.2.8 Electrical characteristics (cable environment)........................................................... 479 17.2.8.1 DC signal levels and waveforms .............................................................. 479 17.2.8.2 AC timing ................................................................................................. 481 17.2.8.3 AC timing ................................................................................................. 483 17.3 Beta (B) and Beta Plus (B Plus) PHY-link interface specification ........................................ 484
Copyright © 2008 IEEE. All rights reserved.
xxi
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
17.3.1 Beta (B) and Beta Plus (B Plus) PHY-link interface characteristics......................... 485 17.3.2 PHY-link interface signals ....................................................................................... 485 17.3.2.1 PHY signals .............................................................................................. 485 17.3.2.2 Link signals............................................................................................... 485 17.3.2.3 PHY-Link signal descriptions .................................................................. 486 17.3.2.4 Detailed signal descriptions...................................................................... 487 17.3.2.5 Differentiated signals................................................................................ 488 17.3.3 Interface initialization, reset, and disable .................................................................. 489 17.3.3.1 LPS signal characteristics ......................................................................... 489 17.3.3.2 Interface reset ........................................................................................... 490 17.3.3.3 Interface disable........................................................................................ 491 17.3.3.4 Restoration and initialization.................................................................... 492 17.3.3.5 Initialization completion sequence ........................................................... 492 17.3.4 LinkOn signal characteristics .................................................................................... 493 17.3.5 Link requests and notifications.................................................................................. 494 17.3.5.1 Link request characteristics ...................................................................... 495 17.3.5.2 Link notifications...................................................................................... 498 17.3.5.3 Link request and notification format ........................................................ 499 17.3.6 Interface data transfers .............................................................................................. 502 17.3.6.1 Interface phases ........................................................................................ 502 17.3.6.2 Packet reception........................................................................................ 502 17.3.6.3 Packet transmission .................................................................................. 505 17.3.7 Format of received and transmitted data ................................................................... 512 17.3.7.1 S100 data .................................................................................................. 513 17.3.7.2 S200 data .................................................................................................. 514 17.3.7.3 S400 data .................................................................................................. 514 17.3.7.4 S800 data .................................................................................................. 515 17.3.7.5 S1600 Data ............................................................................................... 516 17.3.7.6 S3200 Data ............................................................................................... 516 17.3.8 Status transfers and notifications from the PHY ....................................................... 516 17.3.8.1 Bus Status Transfers ................................................................................. 517 17.3.8.2 PHY Status Transfers ............................................................................... 518 17.3.9 Delays affecting interoperability of PHYs and links................................................. 521 17.3.10 Alpha link support ..................................................................................................... 521 17.3.11 Electrical characteristics............................................................................................ 522 17.3.11.1 DC signal levels and waveforms .............................................................. 522 17.3.11.2 AC timing ................................................................................................. 524 17.4 Isolation barrier ...................................................................................................................... 527 17.4.1 Introduction ............................................................................................................... 527 17.4.2 Capacitive isolation barrier........................................................................................ 527 17.4.3 Alternative isolation barrier....................................................................................... 530 18.
PIL-FOP serial interface ................................................................................................................ 533 18.1 Operating model..................................................................................................................... 533 18.2 PIL-FOP connection management ......................................................................................... 534 18.2.1 Power-on.................................................................................................................... 534 18.2.2 PIL-FOP negotiation ................................................................................................. 534 18.2.3 PIL-FOP restore......................................................................................................... 535 18.2.4 Port restore................................................................................................................. 535 18.2.5 Loss of synchronization............................................................................................. 535 18.2.6 Loss of power ............................................................................................................ 535 18.2.7 LPS ............................................................................................................................ 536 18.2.8 Serial bus reset........................................................................................................... 536
xxii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
18.3 Serial bus configuration request types not carried over the PIL-FOP interface..................... 536 18.4 P2P packet protocol................................................................................................................ 536 19.
PHY C code .................................................................................................................................... 539 19.1 Common declarations and functions ...................................................................................... 539 19.2 Connection management routines .......................................................................................... 558 19.2.1 Node-level connection monitor ................................................................................. 558 19.2.2 Port connection manager actions and conditions ...................................................... 567 19.3 Port state machine actions ...................................................................................................... 587 19.3.1 DS port....................................................................................................................... 588 19.3.2 Beta port .................................................................................................................... 595 19.3.3 T-mode port ............................................................................................................... 611 19.4 Border arbitration actions and conditions .............................................................................. 630 19.4.1 Border arbitration functions ...................................................................................... 630 19.4.2 Request processing .................................................................................................... 654 19.4.3 Bus reset .................................................................................................................... 664 19.4.4 Tree identification ..................................................................................................... 667 19.4.5 Self-identification ...................................................................................................... 668 19.5 Border arbitration ................................................................................................................... 673
20.
T-mode port specification ............................................................................................................... 689 20.1 Overview ................................................................................................................................ 689 20.2 Port functions ......................................................................................................................... 690 20.2.1 Port functions overview............................................................................................. 690 20.2.2 Adaptation ................................................................................................................. 690 20.2.2.1 Rate adaptation ......................................................................................... 691 20.2.2.2 Clause 40 in IEEE Std 802.3-2005 ........................................................... 691 20.2.3 Coding ....................................................................................................................... 692 20.2.3.1 Main properties......................................................................................... 692 20.2.4 Symbol types ............................................................................................................. 693 20.2.5 Data symbols ............................................................................................................. 693 20.2.6 Arbitration requests ................................................................................................... 693 20.2.7 Configuration requests............................................................................................... 695 20.2.8 Control symbols in symbol positions A and B.......................................................... 695 20.2.9 Control symbols in symbol positions C and D.......................................................... 695 20.3 T-mode port operation............................................................................................................ 696 20.3.1 Transmit operations ................................................................................................... 696 20.3.1.1 Control transmission................................................................................. 696 20.3.1.2 Request transmission ................................................................................ 697 20.3.1.3 Packet transmission .................................................................................. 697 20.3.1.4 Speed signaling......................................................................................... 697 20.3.1.5 Payload transmission ................................................................................ 697 20.3.2 Receive operations..................................................................................................... 699 20.3.2.1 Symbol decode rules................................................................................. 699 20.3.2.2 Control reception ...................................................................................... 702 20.3.2.3 Request type reception.............................................................................. 702 20.3.2.4 Speed code determination......................................................................... 702 20.3.2.5 Payload reception ..................................................................................... 703 20.3.2.6 Further robustness measures..................................................................... 703 20.3.2.7 Error reporting .......................................................................................... 704
Copyright © 2008 IEEE. All rights reserved.
xxiii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
21.
S800 UTP (T-mode) PMD electrical specification......................................................................... 705 21.1 21.2 21.3 21.4
T-mode PMD specification .................................................................................................... 706 T-mode PMD initialization .................................................................................................... 706 Gigabit media independent interface (GMII)......................................................................... 706 T-mode suspend and resume .................................................................................................. 707 21.4.1 Alternative link pulse (ALP) ..................................................................................... 707 21.4.2 Suspend...................................................................................................................... 707 21.4.3 Resume ...................................................................................................................... 707 21.5 UTP cable power.................................................................................................................... 708 Annex A (normative) Cable environment electrical isolation ..................................................................... 709 A.1 A.2 A.3
Grounding characteristics of ac-powered devices ........................................................... 709 Electrical isolation ........................................................................................................... 709 Agency requirements ....................................................................................................... 710
Annex B (normative) External connector positive retention ....................................................................... 713 Annex C (normative) Internal device physical interface ............................................................................. 715 C.1 C.2
C.3
xxiv
Overview.......................................................................................................................... 715 Electrical interface for internal devices ........................................................................... 715 C.2.1 Power requirements............................................................................................ 715 C.2.2 Bus signal requirements ..................................................................................... 716 C.2.3 Miscellaneous signals......................................................................................... 717 C.2.4 Signal descriptions ............................................................................................. 717 Internal unitized device connectors ................................................................................. 719 C.3.1 Internal unitized plug ......................................................................................... 721 C.3.2 Internal unitized receptacles............................................................................... 727 C.3.3 Connector cable receptacles ............................................................................... 731 C.3.4 Cable receptacle termination .............................................................................. 734 C.3.5 Cable................................................................................................................... 734 C.3.5.1 Flat ribbon cable.................................................................................. 734 C.3.5.2 Discrete wire ....................................................................................... 735 C.3.6 Contact finish on mating surfaces of plug and receptacle contacts.................... 735 C.3.7 Termination finish on plug and receptacle contact ............................................ 735 C.3.8 Connector performance criteria.......................................................................... 735 C.3.8.1 Test sample preparation ...................................................................... 736 C.3.8.2 Performance group A: Basic mechanical conformance and electrical functionality when subjected to mechanical shock and vibration....... 736 C.3.8.3 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress .................................................. 738 C.3.8.4 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress ................................................................... 739 C.3.8.5 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure ................................. 740 C.3.8.6 Performance group E: Contact resistance and mating and unmating force when subjected to temperature life stress .................................. 741 C.3.8.7 Performance group F: Mechanical retention and durability ............... 741 C.3.8.8 Performance group G: General tests ................................................... 742
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Annex D (normative) Backplane PHY timing formulas ............................................................................. 743 D.1 D.2
D.3
D.4
Backplane propagation delay........................................................................................... 743 Backplane arbitration timing ........................................................................................... 744 D.2.1 Synchronization timing ...................................................................................... 744 D.2.2 Arbitration sample timing .................................................................................. 745 D.2.3 Arbitration hold timing....................................................................................... 745 D.2.4 Arbitration bit timing ......................................................................................... 746 Backplane gap timing ...................................................................................................... 746 D.3.1 Acknowledge gap ............................................................................................... 747 D.3.1.1 Occurrence of acknowledge gap ......................................................... 747 D.3.1.2 Acknowledge gap timing .................................................................... 747 D.3.2 Subaction gap and arbitration reset gap ............................................................. 748 D.3.2.1 Occurrence of subaction and arbitration reset gaps ............................ 748 D.3.2.2 Subaction gap and arbitration reset gap timing................................... 748 D.3.3 Arbitration gap scenarios ................................................................................... 749 D.3.3.1 Scenario 1: acknowledge gap.............................................................. 750 D.3.3.2 Scenario 2: subaction gap.................................................................... 750 D.3.3.3 Scenario 3: arbitration reset gap.......................................................... 751 Backplane environment skew .......................................................................................... 752
Annex E (normative) Cable operation and implementation examples ........................................................ 753 E.1 E.2 E.3
Performance optimization................................................................................................ 753 Cable environment jitter budget ...................................................................................... 757 Cable PHY configuration example .................................................................................. 759 E.3.1 Bus initialization process ................................................................................... 759 E.3.2 Tree identify process .......................................................................................... 759 E.3.3 Self identify process ........................................................................................... 763 E.3.4 Topology construction........................................................................................ 769
Annex F (normative) Backplane physical implementation example........................................................... 773 F.1 F.2
Standardized parallel bus implementations ..................................................................... 773 PHY implementation ....................................................................................................... 775 F.2.1 PHY layer overview ........................................................................................... 775 F.2.1.1 Serial bus PHY logic........................................................................... 775 F.2.1.2 Serial bus link logic............................................................................. 775 F.2.1.3 Backplane transceivers........................................................................ 775 F.2.1.4 Local clock .......................................................................................... 776 F.2.2 High-level PHY logic description ...................................................................... 776 F.2.2.1 LINK/PHY interface controller........................................................... 776 F.2.2.2 Arbitration controller .......................................................................... 777 F.2.2.3 Data encode......................................................................................... 778 F.2.2.4 Arb/data multiplexer ........................................................................... 778 F.2.2.5 Data resync/decode ............................................................................. 778
Annex G (normative) Backplane IRM selection ......................................................................................... 779 G.1 G.2 G.3
Backplane configuration management............................................................................. 779 IRM selection process...................................................................................................... 779 Example of an IRM selection process ............................................................................. 779 G.3.1 IRM-capable node environment......................................................................... 779 G.3.2 Non-IRM environment ....................................................................................... 780
Copyright © 2008 IEEE. All rights reserved.
xxv
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Annex H (normative) Serial bus configuration in the cable environment ................................................... 781 H.1 H.2
H.3 H.4
Bus configuration timeline............................................................................................... 781 Bus configuration scenarios............................................................................................. 782 H.2.1 Bus configuration with a bus manager and an IRM........................................... 782 H.2.2 Bus configuration with only an IRM.................................................................. 786 Combined bus manager and IRM .................................................................................... 787 Abdication by the bus manager ....................................................................................... 788
Annex I (normative) Socket PCB terminal patterns and mounting ............................................................. 789 I.1 I.2
Socket orientation ............................................................................................................ 789 PCB mounting 0............................................................................................................... 789
Annex J (normative) Transaction integrity safeguards................................................................................ 795 Annex K (normative) Serial bus cable assembly test procedures................................................................ 797 K.1 K.2
K.3
K.4
K.5
xxvi
Scope................................................................................................................................ 797 Test fixtures ..................................................................................................................... 797 K.2.1 Cable test fixture ................................................................................................ 797 K.2.2 Differential test fixture ....................................................................................... 799 Signal pairs characteristic and discrete impedance.......................................................... 801 K.3.1 Signal pairs impedance setup calibration—short and load ................................ 802 K.3.2 Signal pairs impedance test procedure (connector)............................................ 802 K.3.3 Signal pairs impedance limits (connector) ......................................................... 803 K.3.4 IEEE 1394 bulk serial bus cable test methodology............................................ 803 K.3.4.1 Equipment ........................................................................................... 803 K.3.4.2 Sample................................................................................................. 803 K.3.4.3 Method ................................................................................................ 803 K.3.4.4 Results ................................................................................................. 803 Signal pairs attenuation.................................................................................................... 804 K.4.1 Signal pairs attenuation setup calibration........................................................... 804 K.4.2 ATPA ................................................................................................................. 805 K.4.3 ATPB.................................................................................................................. 806 K.4.4 Signal pairs attenuation limits ............................................................................ 807 K.4.5 IEEE 1394 bulk serial bus cable test methodology............................................ 807 K.4.5.1 Equipment ........................................................................................... 807 K.4.5.2 Sample................................................................................................. 807 K.4.5.3 Method ................................................................................................ 807 K.4.5.4 Results ................................................................................................. 807 Signal pairs velocity of propagation ................................................................................ 807 K.5.1 Signal pairs velocity of propagation setup calibration ....................................... 808 K.5.2 VTPA ................................................................................................................. 808 K.5.3 VTPB.................................................................................................................. 809 K.5.4 Signal pairs velocity of propagation limits ........................................................ 809 K.5.5 IEEE 1394 bulk serial bus cable test methodology (TDR) ................................ 809 K.5.5.1 Equipment ........................................................................................... 809 K.5.5.2 Sample................................................................................................. 809 K.5.5.3 Method ................................................................................................ 809 K.5.5.4 Results ................................................................................................. 809 K.5.6 IEEE 1394 bulk serial bus cable test methodology (frequency sweep) ............. 810 K.5.6.1 Equipment ........................................................................................... 810 K.5.6.2 Sample................................................................................................. 810
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
K.6
K.7
K.8
K.5.6.3 Method ................................................................................................ 810 K.5.6.4 Results ................................................................................................. 810 K.5.7 Rise and fall time................................................................................................ 810 K.5.7.1 Equipment ........................................................................................... 810 K.5.7.2 Sample................................................................................................. 810 K.5.7.3 Method ................................................................................................ 810 K.5.7.4 .Results ................................................................................................ 811 K.5.8 Static shield isolation (insulation resistance) ..................................................... 811 K.5.8.1 Equipment ........................................................................................... 811 K.5.8.2 Sample................................................................................................. 811 K.5.8.3 Method ................................................................................................ 811 K.5.8.4 Results ................................................................................................. 811 Signal pairs relative propagation skew ............................................................................ 811 K.6.1 Signal pairs skew setup calibration .................................................................... 812 K.6.2 Signal pairs skew test procedure ........................................................................ 813 K.6.3 Signal pairs skew limits...................................................................................... 813 Power pair characteristic impedance ............................................................................... 814 K.7.1 Power pair impedance setup calibration—short and load .................................. 815 K.7.2 Power pair impedance test procedure................................................................. 815 K.7.3 Power pair dc resistance ..................................................................................... 815 K.7.4 DC resistance setup calibration .......................................................................... 816 K.7.5 DC resistance test procedure .............................................................................. 817 K.7.6 DC resistance limits ........................................................................................... 817 Crosstalk .......................................................................................................................... 818 K.8.1 Crosstalk setup calibration ................................................................................. 818 K.8.2 Crosstalk test procedure (between power and signal pairs) ............................... 819 K.8.3 Crosstalk test procedure (between signal pairs) ................................................. 820 K.8.4 Crosstalk limits................................................................................................... 820 K.8.5 Crosstalk limits (between signal pairs) .............................................................. 821
Annex L (normative) Shielding effectiveness and transfer impedance testing ........................................... 823 L.1 L.2 L.3 L.4
L.5
L.6 L.7 L.8
L.9
Content............................................................................................................................. 823 Definitions ....................................................................................................................... 823 Test equipment................................................................................................................. 823 Theory .............................................................................................................................. 824 L.4.1 Reference measurement ..................................................................................... 824 L.4.2 Sample measurement.......................................................................................... 824 L.4.3 Calculations ........................................................................................................ 825 Sample preparation .......................................................................................................... 825 L.5.1 Panel-mounted connector sample....................................................................... 825 L.5.2 Measure sample Zo with TDR ........................................................................... 826 L.5.3 Cable-mounted connector sample ...................................................................... 826 Procedure ......................................................................................................................... 826 “Noise floor” plot............................................................................................................. 827 Documentation................................................................................................................. 827 L.8.1 Plots and magnetic files...................................................................................... 827 L.8.2 Test report .......................................................................................................... 828 Performance ..................................................................................................................... 828
Annex M (informative) Serial bus topology considerations for power distribution (cable environment) .. 829
Copyright © 2008 IEEE. All rights reserved.
xxvii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Annex N (normative) Jitter measurements .................................................................................................. 833 N.1 N.2 N.3 N.4
Test patterns ..................................................................................................................... 833 Random pattern (SB_RPAT) ........................................................................................... 833 Receive jitter tolerance pattern (SB_JTPAT) .................................................................. 833 Supply noise test sequence (SB_SPAT) .......................................................................... 834
Annex O (informative) Connection status change....................................................................................... 835 Annex P (informative) Deriving bus topology from self-ID packets .......................................................... 837 P.1 P.2 P.3 P.4
Bus topology analysis ...................................................................................................... 837 Topology analysis after power reset ................................................................................ 838 Topology analysis when the root changes ....................................................................... 842 Topology analysis when a node is inserted ..................................................................... 844
Annex Q (informative) Summary description ............................................................................................. 847 Q.1 Q.2
Q.3 Q.4
Q.5
Q.6
Q.7
Q.8 Q.9
xxviii
Node and module architectures........................................................................................ 847 Topology .......................................................................................................................... 848 Q.2.1 Cable environment ............................................................................................. 848 Q.2.2 Backplane environment...................................................................................... 849 Addressing ....................................................................................................................... 849 Protocol architecture and data transfer services .............................................................. 850 Q.4.1 SBP architecture ................................................................................................. 850 Q.4.2 Data transfer services ......................................................................................... 850 Transaction layer.............................................................................................................. 851 Q.5.1 Transaction layer services .................................................................................. 852 Q.5.2 Lock subcommands............................................................................................ 852 Q.5.3 Subaction queue independence .......................................................................... 853 Link layer ......................................................................................................................... 854 Q.6.1 Link layer services ............................................................................................. 855 Q.6.2 Link and transaction layer interactions .............................................................. 856 Q.6.2.1 Unified transactions ............................................................................ 856 Q.6.2.2 Split transactions ................................................................................. 857 Q.6.2.3 Subaction concatenation...................................................................... 857 Q.6.2.4 Retries ................................................................................................. 859 Q.6.3 Asynchronous arbitration ................................................................................... 859 Q.6.4 Isochronous arbitration....................................................................................... 860 Physical layer (PHY) ....................................................................................................... 861 Q.7.1 Data bit transmission and reception ................................................................... 861 Q.7.2 Fair arbitration.................................................................................................... 862 Q.7.3 Cable PHY.......................................................................................................... 863 Q.7.3.1 Cable configuration............................................................................. 864 Q.7.3.2 Normal arbitration............................................................................... 867 Q.7.3.3 Speed signaling ................................................................................... 870 Q.7.3.4 Cable media interface.......................................................................... 870 Q.7.4 Backplane PHY .................................................................................................. 871 Q.7.4.1 Backplane arbitration .......................................................................... 871 Q.7.4.2 Urgent arbitration ................................................................................ 872 Q.7.4.3 Backplane media interface .................................................................. 873 Bus management.............................................................................................................. 874 New features of IEEE Std 1394a-2000............................................................................ 874 Q.9.1 Connection debounce ......................................................................................... 875
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Q.9.2
Cable arbitration enhancements ......................................................................... 875 Q.9.2.1 Arbitrated (short) bus reset.................................................................. 875 Q.9.2.2 Ack-accelerated arbitration ................................................................. 876 Q.9.2.3 Fly-by concatenation........................................................................... 877 Q.9.2.4 Multi-speed packet concatenation....................................................... 878 Q.9.2.5 Arbitration enhancements and cycle start ........................................... 878 Q.9.3 Performance optimization via PHY “pinging”................................................... 879 Q.9.4 Priority arbitration .............................................................................................. 879 Q.9.5 Port disable, suspend, and resume...................................................................... 880 Q.9.5.1 Connection detect circuit..................................................................... 880 Q.9.5.2 Suspended connection......................................................................... 880 Q.9.5.3 Suspended domain .............................................................................. 881 Q.9.5.4 Resumption ......................................................................................... 882 Q.9.5.5 Boundary nodes................................................................................... 882 Q.10 New features of IEEE Std 1394b-2002............................................................................ 883 Q.10.1 The relationship to IEEE Std 1394a-2000.......................................................... 883 Q.10.2 Faster and further ............................................................................................... 883 Q.10.3 Nomenclature ..................................................................................................... 884 Q.10.4 Media—common properties............................................................................... 885 Q.10.4.1 Short-haul shielded twisted pair (STP) cabling .................................. 885 Q.10.4.2 CAT-5 UTP cable (see Chapter 7 of ISO/IEC 11801:2002)............... 885 Q.10.4.3 Plastic optic fiber (POF) and hard polymer clad fiber (HPCF) .......... 885 Q.10.4.4 Glass fiber ........................................................................................... 886 Q.10.4.5 Media summary for Beta-mode operation .......................................... 886 Q.10.5 Arbitration improvements .................................................................................. 886 Q.10.5.1 Legacy arbitration ............................................................................... 886 Q.10.5.2 New arbitration method—bus owner/supervisor/selector (BOSS) ..... 887 Q.10.6 PHY-link interface ............................................................................................. 892 Q.10.6.1 Evolutionary PHY-link interface ........................................................ 892 Q.10.6.2 Serial PHY-link interface.................................................................... 893 Q.10.7 Miscellaneous features ....................................................................................... 893 Q.10.7.1 Autonegotiation................................................................................... 893 Q.10.7.2 Loop breaking ..................................................................................... 894 Q.10.7.3 Power conservation improvements ..................................................... 894 Q.11 New features of IEEE Std 1394c-2006............................................................................ 894 Q.11.1 Scope .................................................................................................................. 894 Q.11.2 Purpose ............................................................................................................... 895 Q.11.3 T-mode features.................................................................................................. 895 Q.11.4 The relationship of T-mode to Beta mode ......................................................... 895 Q.11.5 The relationship to IEEE Std 802.3-2005 .......................................................... 895 Q.11.6 S800 over UTP ................................................................................................... 895 Q.11.7 Twin-mode ports ................................................................................................ 896 Q.12 New features of IEEE Std 1394-2008.............................................................................. 896 Q.12.1 Errata .................................................................................................................. 896 Q.12.2 Enhanced UTP PMD .......................................................................................... 896 Q.12.3 Beta PMD electrical specification...................................................................... 897 Q.12.4 Beta Plus PHY-link interface ............................................................................. 897 Q.12.5 Bus topology determination ............................................................................... 897 Q.12.6 Document organization ...................................................................................... 897
Copyright © 2008 IEEE. All rights reserved.
xxix
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Annex R (informative) Glossary.................................................................................................................. 899 R.1 R.2
Conformance.................................................................................................................... 899 Definitions ....................................................................................................................... 899
Annex S (informative) Bibliography ........................................................................................................... 905
xxx
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
List of figures Figure 1-1—Example hierarchical bus topology............................................................................................. 3 Figure 1-2—Service model.............................................................................................................................. 4 Figure 1-3—Bit and byte ordering................................................................................................................... 5 Figure 1-4—Sample packet format.................................................................................................................. 6 Figure 1-5—State machine example................................................................................................................ 8 Figure 1-6—Example of CSR format specification ........................................................................................ 9 Figure 1-7—Reserved CSR field behavior .................................................................................................... 11 Figure 4-1—6-circuit plug body .................................................................................................................... 31 Figure 4-2—6-circuit plug section details ..................................................................................................... 32 Figure 4-3—6-circuit socket shell ................................................................................................................. 33 Figure 4-4—6-circuit socket shell detail ....................................................................................................... 34 Figure 4-5—6-circuit socket insertion wafer................................................................................................. 35 Figure 4-6—6-circuit socket insertion wafer details ..................................................................................... 36 Figure 4-7—6-circuit cable material construction example (for reference only) .......................................... 38 Figure 4-8—Example 6-circuit cable assembly and schematic..................................................................... 39 Figure 4-9—Shock and vibration fixturing diagram ..................................................................................... 41 Figure 4-10—Shield and contact resistance measuring points ...................................................................... 45 Figure 4-11—4-circuit plug body .................................................................................................................. 51 Figure 4-12—4-circuit plug section details ................................................................................................... 51 Figure 4-13—4-circuit connector socket interface ........................................................................................ 52 Figure 4-14—4-circuit socket cross-section A–A ......................................................................................... 53 Figure 4-15—Cross-section of 4-circuit plug and socket contacts................................................................ 53 Figure 4-16—4-circuit socket position when mounted on a PCB ................................................................. 54 Figure 4-17—Flat SMT PCB 4-circuit socket footprint ................................................................................ 55 Figure 4-18—Flat through-hole mount PCB 4-circuit socket footprint ........................................................ 55 Figure 4-19—4-circuit cable material construction example (for reference only) ........................................ 56 Figure 4-20—Cable assembly and schematic (6-pin to 4-pin connector) ..................................................... 57 Figure 4-21—Cable assembly and schematic (4-pin connectors) ................................................................. 57 Figure 4-22—Shield and contact resistance measuring points ...................................................................... 63 Figure 4-23—Fixture for cable flex test ........................................................................................................ 66 Figure 4-24—Beta plug body with overmold................................................................................................ 69 Figure 4-25—Bilingual plug body with overmold ........................................................................................ 70 Figure 4-26—Beta and bilingual plug interface: Detail A ............................................................................ 71 Figure 4-27—Beta and bilingual plug section Z-Z (unmated) ...................................................................... 71 Figure 4-28—Beta and bilingual detent cross-section S-S ............................................................................ 72 Figure 4-29—Beta socket body ..................................................................................................................... 73 Figure 4-30—Beta socket outer shell profile................................................................................................. 73 Figure 4-31—Bilingual socket body.............................................................................................................. 74 Figure 4-32—Bilingual socket outer shell profile ......................................................................................... 74 Figure 4-33—Beta and bilingual socket section X-X.................................................................................... 75 Figure 4-34—Beta and bilingual socket section Y-Y.................................................................................... 75 Figure 4-35—Beta and bilingual socket section V-V.................................................................................... 76 Figure 4-36—Beta and bilingual socket section Z-Z..................................................................................... 76 Figure 4-37—Beta and bilingual socket section W-W .................................................................................. 77 Figure 4-38—Beta and bilingual socket interface ......................................................................................... 77 Figure 4-39—Beta and bilingual plug and socket detent feature cross-section............................................. 78 Figure 4-40—Socket positions when mounted on a PCB ............................................................................. 78 Figure 4-41—Beta PCB socket footprint....................................................................................................... 80 Figure 4-42—Bilingual PCB socket footprint ............................................................................................... 81 Figure 4-43—Beta and bilingual PHY trace routing ..................................................................................... 82 Figure 4-44—Example of Beta cable construction—4.5 m maximum (for reference only) ......................... 83 Figure 4-45—Example of Beta cable construction—2 m maximum (for reference only) ............................ 84
Copyright © 2008 IEEE. All rights reserved.
xxxi
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure 4-46—Interface mating chart ............................................................................................................. 85 Figure 4-47—Type 1 cable assembly and schematic (Beta plug to Beta plug)............................................. 86 Figure 4-48—Type 2 cable assembly and schematic (6-circuit plug to bilingual plug)................................ 87 Figure 4-49—Type 3 cable assembly and schematic (4-circuit plug to bilingual plug)................................ 88 Figure 4-50—Shield and contact resistance measurement points ................................................................. 93 Figure 4-51—Fixture for cable flex test ........................................................................................................ 96 Figure 4-52—PCB stack-up for connector-only differential test fixture....................................................... 97 Figure 4-53—PCB top layer for connector-only differential test fixture ...................................................... 97 Figure 4-54—PCB ground layer for connector-only differential test fixture ................................................ 98 Figure 4-55—PCB stack-up for cable assembly differential test fixture....................................................... 98 Figure 4-56—PCB top layer for cable assembly differential test fixture ...................................................... 98 Figure 4-57—PCB ground layer for cable assembly differential test fixture................................................ 99 Figure 4-58—Test fixture schematic ............................................................................................................. 99 Figure 4-59—Connector impedance exception window mask.................................................................... 101 Figure 4-60—S3200 cable insertion loss example ...................................................................................... 102 Figure 4-61—S3200 cable SCD21-SDD21 ................................................................................................. 103 Figure 5-1—Backplane topology................................................................................................................. 110 Figure 5-2—Backplane transmit data timing............................................................................................... 112 Figure 5-3—Backplane receive data timing ................................................................................................ 113 Figure 5-4—Arbitration bit timing .............................................................................................................. 117 Figure 5-5—DS coding................................................................................................................................ 118 Figure 5-6—Arbitration sequence ............................................................................................................... 121 Figure 5-7—Backplane PHY architecture ................................................................................................... 121 Figure 5-8—Fairness interval ...................................................................................................................... 123 Figure 5-9—Fair arbitration......................................................................................................................... 123 Figure 5-10—Urgent arbitration .................................................................................................................. 125 Figure 6-1—Serial bus packets.................................................................................................................... 136 Figure 6-2—Primary packet format............................................................................................................. 136 Figure 6-3—Asynchronous packet format .................................................................................................. 137 Figure 6-4—No-data payload primary packet format ................................................................................. 138 Figure 6-5—Read request for data quadlet packet format........................................................................... 139 Figure 6-6—Write response packet format ................................................................................................. 139 Figure 6-7—Data quadlet payload packet format........................................................................................ 139 Figure 6-8—Read request for data block packet format.............................................................................. 140 Figure 6-9—Write request for data quadlet packet format.......................................................................... 140 Figure 6-10—Cycle start packet format ...................................................................................................... 141 Figure 6-11—Read response for data quadlet packet format ...................................................................... 141 Figure 6-12—Data block payload packet format ........................................................................................ 142 Figure 6-13—Write request for data block packet format........................................................................... 143 Figure 6-14—Lock-request packet format .................................................................................................. 143 Figure 6-15—Read response for data block packet format ......................................................................... 144 Figure 6-16—Lock-response packet format ................................................................................................ 145 Figure 6-17—Isochronous data block packet format .................................................................................. 146 Figure 6-18—Asynchronous stream packet format..................................................................................... 147 Figure 6-19—Global asynchronous stream packet (GASP) format ............................................................ 148 Figure 6-20—Acknowledge packet format ................................................................................................. 156 Figure 6-21—Link layer packet transmit/receive state machine ................................................................. 162 Figure 7-1—Outbound transaction state machine ....................................................................................... 181 Figure 7-2—Inbound transaction state machine .......................................................................................... 185 Figure 7-3—Inbound subaction dual-phase retry state machine ................................................................. 192 Figure 8-1—STATE_CLEAR format ......................................................................................................... 205 Figure 8-2—STATE_CLEAR.bus_depend field......................................................................................... 205 Figure 8-3—NODE_IDS format ................................................................................................................. 207 Figure 8-4—SPLIT_TIMEOUT format ...................................................................................................... 208
xxxii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure 8-5—CYCLE_TIME format ............................................................................................................ 210 Figure 8-6—BUS_TIME format ................................................................................................................. 211 Figure 8-7—POWER_FAIL_IMMINENT format...................................................................................... 212 Figure 8-8—POWER_SOURCE format ..................................................................................................... 213 Figure 8-9—BUSY_TIMEOUT format ...................................................................................................... 213 Figure 8-10—PRIORITY_BUDGET format .............................................................................................. 214 Figure 8-11—BUS_MANAGER_ID format............................................................................................... 216 Figure 8-12—BANDWIDTH_AVAILABLE format ................................................................................. 216 Figure 8-13—CHANNELS_AVAILABLE format..................................................................................... 218 Figure 8-14—MAINT_CONTROL format ................................................................................................. 219 Figure 8-15—MAINT_UTILITY format .................................................................................................... 220 Figure 8-16—BROADCAST_CHANNEL format...................................................................................... 221 Figure 8-17—TOPOLOGY_MAP format................................................................................................... 222 Figure 8-18—Configuration ROM hierarchy .............................................................................................. 223 Figure 8-19—Minimal ROM format ........................................................................................................... 224 Figure 8-20—General ROM format ............................................................................................................ 225 Figure 8-21—Bus_Info_Block format......................................................................................................... 225 Figure 8-22—Module_Vendor_Id entry format .......................................................................................... 228 Figure 8-23—Node_Capabilities entry format ............................................................................................ 228 Figure 8-24—Unit_Power_Requirements entry format .............................................................................. 229 Figure 8-25—Candidate cycle master state machine .................................................................................. 240 Figure 8-26—Candidate IRM state machine ............................................................................................... 241 Figure 8-27—Candidate bus manager state machine .................................................................................. 243 Figure 9-1—PHY master architecture (short-haul copper electrical PMD in context) ............................... 245 Figure 9-2—Short-haul copper PHY architecture ....................................................................................... 246 Figure 9-3—Cable topology ........................................................................................................................ 247 Figure 9-4—Measurement points (half connection is shown)..................................................................... 248 Figure 9-5—Port interface ........................................................................................................................... 249 Figure 9-6—Differential output test loads................................................................................................... 250 Figure 9-7—Common mode current test loads............................................................................................ 253 Figure 9-8—Common mode output noise test loads ................................................................................... 254 Figure 9-9—DS coding................................................................................................................................ 257 Figure 9-10—Start of packet transmission .................................................................................................. 263 Figure 9-11—Concatenated packet transmission ........................................................................................ 263 Figure 9-12—End of packet transmission ................................................................................................... 264 Figure 9-13—Subaction response................................................................................................................ 264 Figure 9-14—Example of S1600 and S3200 de-emphasis .......................................................................... 269 Figure 9-15—Balanced transmitter test circuit............................................................................................ 269 Figure 9-16—Normalized eye diagram mask at TP2 .................................................................................. 270 Figure 9-17—Absolute eye diagram mask at TP2....................................................................................... 270 Figure 9-18—TP3 test load.......................................................................................................................... 272 Figure 9-19—Eye diagram mask at point TP3 ............................................................................................ 273 Figure 9-20—Example S3200 fixed equalizer function .............................................................................. 275 Figure 9-21—SIGNAL_DETECT timing parameters................................................................................. 281 Figure 9-22—Example of bilingual port termination .................................................................................. 286 Figure 9-23—Beta-only connection to copper cable ................................................................................... 287 Figure 9-24—Termination for PIL-FOP interface....................................................................................... 288 Figure 9-25—Node power interface for POWER_CLASS one, two, or three............................................ 289 Figure 9-26—Node power interface for POWER_CLASS four (three or more ports) ............................... 289 Figure 9-27—Providing power to a floating PHY or FOP, power class 1, 2, or 3...................................... 291 Figure 9-28—Providing power to a floating PHY or FOP, power class 1, 2, or 3 (alternative) ................. 292 Figure 9-29—Providing power to a floating PHY or FOP, power class 4 .................................................. 292 Figure 10-1—PHY master architecture (GOF PMD in context) ................................................................. 295 Figure 10-2—PMD block diagram .............................................................................................................. 296
Copyright © 2008 IEEE. All rights reserved.
xxxiii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure 10-3—Transmitter eye mask definition ........................................................................................... 302 Figure 10-4—Optical fiber cabling model................................................................................................... 304 Figure 10-5—Duplex receptacle interface................................................................................................... 305 Figure 10-6—Duplex connection interface ................................................................................................. 305 Figure 11-1—PHY master architecture ....................................................................................................... 307 Figure 11-2—PMD block diagram .............................................................................................................. 308 Figure 11-3—Plug connector interface........................................................................................................ 309 Figure 11-4—Receptacle connector interface ............................................................................................. 309 Figure 12-1—PHY master architecture (UTP PMD in context) ................................................................. 315 Figure 12-2—UTP PMD interfaces ............................................................................................................. 316 Figure 12-3—Media interface connector socket.......................................................................................... 318 Figure 12-4—S100 signal mask for transmitted signal ............................................................................... 321 Figure 12-5—S200/S400 normalized eye diagram mask at TP2 ................................................................ 322 Figure 12-6—S200/S400 absolute eye diagram mask at TP2 ..................................................................... 322 Figure 12-7—signal_detect timing parameters............................................................................................ 324 Figure 13-1—PHY master architecture (data routing, arbitration, and control interfaces in context) ........ 327 Figure 13-2—Scrambling and coding functions.......................................................................................... 328 Figure 13-3—Representation of the scrambler as a serial bit-shift register with parallel output ................ 333 Figure 13-4—Scrambler schematic (data) ................................................................................................... 334 Figure 13-5—Scrambler schematic (request symbol) ................................................................................. 335 Figure 13-6—Scrambler schematic (control) .............................................................................................. 336 Figure 13-7—Structure of packet, packet delimiters, and request types, with examples of coding process ................................................................................................................. 351 Figure 13-8—Port transmit state machine ................................................................................................... 358 Figure 13-9—Port receive state machine..................................................................................................... 359 Figure 14-1—PHY master architecture (connection management in context)............................................ 361 Figure 14-2—Port connection manager state machine................................................................................ 367 Figure 14-3—Example of dominant subnets ............................................................................................... 374 Figure 14-4—Speed code timing diagram................................................................................................... 381 Figure 14-5—Example of speed negotiation ............................................................................................... 382 Figure 14-6—Message Code 5 sequence..................................................................................................... 388 Figure 15-1—Extended PHY register map for the cable environment........................................................ 390 Figure 15-2—PHY register page 0: Port Status page .................................................................................. 394 Figure 15-3—PHY register page 1: Vendor Identification page ................................................................. 398 Figure 15-4—PHY register map for the backplane environment................................................................ 399 Figure 16-1—PHY master architecture (data routing, arbitration, and control interfaces in context) ........ 401 Figure 16-2—Alpha self-ID packet formats ................................................................................................ 415 Figure 16-3—Alpha Link-on packet format ................................................................................................ 417 Figure 16-4—Alpha PHY configuration packet format .............................................................................. 417 Figure 16-5—Alpha ping packet format...................................................................................................... 418 Figure 16-6—Alpha remote access packet format....................................................................................... 419 Figure 16-7—Alpha remote reply packet format ........................................................................................ 419 Figure 16-8—Alpha remote command packet format ................................................................................. 420 Figure 16-9—Alpha remote confirmation packet format ............................................................................ 421 Figure 16-10—Alpha resume packet format ............................................................................................... 422 Figure 16-11—Beta self-ID packet formats ................................................................................................ 422 Figure 16-12—Beta Remote command packet format ................................................................................ 424 Figure 16-13—Beta Remote confirmation packet format ........................................................................... 425 Figure 16-14—Beta PHY configuration packet format............................................................................... 426 Figure 16-15—LTP format .......................................................................................................................... 427 Figure 16-16—Bus reset state machine ....................................................................................................... 446 Figure 16-17—Tree identification state machine ........................................................................................ 448 Figure 16-18—Self-identification state machine......................................................................................... 450 Figure 16-19—Border arbitration state machine ......................................................................................... 453
xxxiv
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure 17-1—Alpha PHY-link interface logical signaling.......................................................................... 461 Figure 17-2—Digital differentiator signal transformation .......................................................................... 462 Figure 17-3—LPS waveform when differentiated ...................................................................................... 463 Figure 17-4—Alpha PHY-link interface reset via LPS ............................................................................... 464 Figure 17-5—Alpha PHY-link interface disable via LPS ........................................................................... 464 Figure 17-6—LReq and Ctl timings ............................................................................................................ 467 Figure 17-7—Alpha PHY-link interface status timing................................................................................ 475 Figure 17-8—Alpha PHY-link interface transmit timing............................................................................ 477 Figure 17-9—Link cancel timing (after Grant) ........................................................................................... 478 Figure 17-10—Link cancel timing (after Hold) .......................................................................................... 478 Figure 17-11—Receive timing .................................................................................................................... 479 Figure 17-12—Signal levels for rise and fall times ..................................................................................... 481 Figure 17-13—PHY to link transfer waveform at the PHY ........................................................................ 481 Figure 17-14—Link to PHY transfer waveform at the PHY ....................................................................... 482 Figure 17-15—PHY to link transfer waveform at the link .......................................................................... 482 Figure 17-16—Link to PHY transfer waveform at the link......................................................................... 482 Figure 17-17—Alpha link to PHY delay timing ......................................................................................... 484 Figure 17-18—Beta and Beta Plus PHY-link interface logical signalling .................................................. 486 Figure 17-19—Digital differentiator signal transformation ........................................................................ 489 Figure 17-20—LPS waveform when differentiated .................................................................................... 489 Figure 17-21—Beta and Beta Plus PHY-link interface reset ...................................................................... 491 Figure 17-22—Beta and Beta Plus PHY-link interface disable .................................................................. 491 Figure 17-23—LinkOn waveform ............................................................................................................... 493 Figure 17-24—Link request format ............................................................................................................. 499 Figure 17-25—Beta interface PHY-link packet receive operation.............................................................. 503 Figure 17-26—Beta Plus PHY-Link packet receive operation in S3200 mode .......................................... 504 Figure 17-27—Beta Plus PHY-Link packet receive operation in S1600 mode .......................................... 504 Figure 17-28—Beta and Beta Plus PHY-link packet transmit operation, including optional HOLD cycles ................................................................................................................. 507 Figure 17-29—Beta Plus PHY-Link packet transmit operation in S3200 mode......................................... 508 Figure 17-30—Beta Plus PHY-Link packet transmit operation in S1600 mode......................................... 509 Figure 17-31—Format of Beta interface data transfers in S100 mode........................................................ 513 Figure 17-32—Format of Beta Plus interface data transfers in S100 mode ................................................ 513 Figure 17-33—Format of Beta interface data transfers in S200 mode........................................................ 514 Figure 17-34—Format of Beta Plus interface data transfers in S200 mode ................................................ 514 Figure 17-35—Format of Beta interface data transfers in S400 mode........................................................ 514 Figure 17-36—Format of Beta Plus interface data transfers in S400 mode ................................................ 515 Figure 17-37—Format of Beta interface data transfers in S800 mode........................................................ 515 Figure 17-38—Format of Beta Plus interface data transfers in S800 mode ................................................ 515 Figure 17-39—Format of Beta Plus interface data transfers in S1600 mode .............................................. 516 Figure 17-40—Format of Beta Plus interface data transfers in S3200 mode .............................................. 516 Figure 17-41—Bus Status Transfer format ................................................................................................. 518 Figure 17-42—Beta and Beta Plus PHY Status Transfer format ................................................................ 520 Figure 17-43—Signal levels for rise and fall times ..................................................................................... 524 Figure 17-44—Transfer waveform at the source......................................................................................... 526 Figure 17-45—Transfer waveform at the destination.................................................................................. 526 Figure 17-46—Example of ground coupling circuit.................................................................................... 527 Figure 17-47—Example of capacitive isolation barrier circuit for Ctl[0:1] and D[0:n].............................. 528 Figure 17-48—Example of capacitive isolation barrier circuit for LinkOn ................................................ 528 Figure 17-49—Example of capacitive isolation barrier circuit for LPS...................................................... 529 Figure 17-50—Example of capacitive isolation barrier circuit for LReq and PInt ..................................... 529 Figure 17-51—Example of capacitive isolation barrier circuit for LClk and PClk..................................... 530 Figure 17-52—Example of bus holder isolation circuit for LReq, PInt, PClk, and LClk ........................... 530 Figure 17-53—Example of bus holder isolation circuit for Ctl[0:1] and D[0:n]......................................... 531
Copyright © 2008 IEEE. All rights reserved.
xxxv
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure 18-1—Possible system configuration using a FOP device .............................................................. 533 Figure 18-2—P2P packet format ................................................................................................................. 537 Figure 20-1—PHY master architecture (T-mode functions in context) ...................................................... 689 Figure 20-2—T-mode coding functions ...................................................................................................... 690 Figure 20-3—T-mode adaptation ................................................................................................................ 691 Figure 20-4—T-mode symbol type encoding.............................................................................................. 693 Figure 20-5—Arbitration request encoding................................................................................................. 693 Figure 20-6—Control symbol encoding in positions A and B .................................................................... 695 Figure 20-7—Control symbol encoding in positions C and D .................................................................... 695 Figure 20-8—Structure of packet, packet delimiters, and request types with examples of coding process 698 Figure 21-1—PHY master architecture (S800 cat-5 UTP PMD in context) ............................................... 705 Figure A.1—AC power supply with ground ............................................................................................... 709 Figure B.1—Exclusion zone for positive retention mechanism .................................................................. 713 Figure B.2—Three views of plug with shuttle type latch............................................................................ 714 Figure B.3—Cutouts in a typical personal computer option panel.............................................................. 714 Figure C.1—Recommended SMT PCB layout (connector mounting to the PC board in the device) ........ 720 Figure C.2—Recommended PCB layout (connector mounting side).......................................................... 720 Figure C.3—Internal unitized plug features ................................................................................................ 721 Figure C.4—Internal unitized plug .............................................................................................................. 722 Figure C.5—Internal unitized plug retention (detent detail) ....................................................................... 723 Figure C.6—Internal unitized plug header .................................................................................................. 723 Figure C.7—Internal unitized plug bus (bay detail) .................................................................................... 724 Figure C.8—Internal unitized plug options (bay detail).............................................................................. 724 Figure C.9—Internal unitized plug power (bay detail)................................................................................ 725 Figure C.10—Internal unitized plug dual bus (bay detail) .......................................................................... 726 Figure C.11—Internal unitized plug discrete power (bay detail) ................................................................ 727 Figure C.12—Internal unitized receptacle features ..................................................................................... 727 Figure C.13—Internal unitized receptacle................................................................................................... 728 Figure C.14—Internal unitized receptacle contact detail ............................................................................ 729 Figure C.15—Internal unitized receptacle bus (bay detail) ......................................................................... 729 Figure C.16—Internal unitized receptacle option (bay detail) .................................................................... 730 Figure C.17—Internal unitized receptacle power (bay detail)..................................................................... 730 Figure C.18—Internal unitized device connector contact (wipe detail) ...................................................... 731 Figure C.19—Internal cable receptacle bus (bay detail) ............................................................................. 732 Figure C.20—Internal cable receptacle option and power (bay detail) ....................................................... 733 Figure C.21—Overall terminated size of a power cable receptacle ............................................................ 734 Figure C.22—Shock and vibration fixturing diagram ................................................................................. 737 Figure C.23—Contact resistance measuring points..................................................................................... 738 Figure E.1—PHY pinging and round-trip times.......................................................................................... 755 Figure E.2—Example cable state after bus initialization process ............................................................... 759 Figure E.3—Tree identify process start, beginning of child handshake...................................................... 760 Figure E.4—End of child handshake ........................................................................................................... 760 Figure E.5—Parent handshake and start of root contention ........................................................................ 761 Figure E.6—End of root contention, and new child handshake start .......................................................... 761 Figure E.7—End of final child handshake and root selection ..................................................................... 762 Figure E.8—Final parent handshake ........................................................................................................... 762 Figure E.9—Tree identify process complete ............................................................................................... 763 Figure E.10—Start of self-identify process ................................................................................................. 764 Figure E.11—First node sends self-ID information .................................................................................... 764 Figure E.12—First node finishes self-identify ............................................................................................ 765 Figure E.13—Start of bus grant for second node self-identify.................................................................... 766 Figure E.14—Finish of bus grant for second node self-identify ................................................................. 766 Figure E.15—Second node self-identify ..................................................................................................... 767 Figure E.16—Second node finishes self-identify ........................................................................................ 767
xxxvi
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure E.17—Start of grant for third self-identify....................................................................................... 768 Figure E.18—Completion of grant for third self-identify ........................................................................... 768 Figure E.19—Example cable state after self-identify phase........................................................................ 769 Figure E.20—Topology information after identification of leaf nodes....................................................... 770 Figure E.21—Topology information after identification of first branch node ............................................ 770 Figure E.22—Topology information after identification of root node ........................................................ 771 Figure F.1—Typical application of serial bus in the backplane environment............................................. 773 Figure F.2—Link/PHY interface ................................................................................................................. 775 Figure F.3—PHY logic block diagram........................................................................................................ 776 Figure H.1—Bus configuration timeline ..................................................................................................... 781 Figure H.2—Bus configuration example (after power-on).......................................................................... 783 Figure H.3—Bus configuration example (after force root and reset).......................................................... 784 Figure H.4—Bus configuration example (after new node insertion and reset) ........................................... 785 Figure H.5—IRM-only bus configuration example (after power-on) ......................................................... 786 Figure H.6—IRM-only bus configuration example (after link-on to node 0) ............................................. 787 Figure I.1—Socket orientations ................................................................................................................... 789 Figure I.2—Right-angle upright through-hole mount ................................................................................. 791 Figure I.3—Right-angle upright through-hole mount (inverted)................................................................. 792 Figure I.4—Right-angle flat surface mount................................................................................................. 793 Figure I.5—Right-angle flat surface mount (inverted) ................................................................................ 794 Figure K.1—Cable test fixture schematic.................................................................................................... 798 Figure K.2—Test fixture graphic symbol.................................................................................................... 798 Figure K.3—100 W to 110 W matching pad............................................................................................... 799 Figure K.4—Differential test fixture schematic .......................................................................................... 800 Figure K.5—Differential test fixture graphic symbol ................................................................................. 801 Figure K.6—Signal pairs impedance measurement configuration (connector)........................................... 802 Figure K.7—Signal pairs impedance measurement configuration (connector)........................................... 803 Figure K.8—Signal pairs attenuation and velocity setup calibration .......................................................... 805 Figure K.9—Signal pair attenuation and velocity measurement ................................................................. 806 Figure K.10—Skew setup calibration.......................................................................................................... 812 Figure K.11—Skew measurement ............................................................................................................... 814 Figure K.12—Power pair dc resistance setup calibration............................................................................ 816 Figure K.13—Power pair resistance measurement...................................................................................... 817 Figure K.14—Crosstalk setup calibration ................................................................................................... 818 Figure K.15—Crosstalk measurement......................................................................................................... 819 Figure L.1—Equipment block diagram ....................................................................................................... 823 Figure L.2—Reference measurement fixturing ........................................................................................... 824 Figure L.3—Sample measurement fixturing ............................................................................................... 825 Figure L.4—Noise floor check fixturing ..................................................................................................... 827 Figure M.1—Power distribution example ................................................................................................... 831 Figure P.1—Reference topology (with self-ID packets) ............................................................................. 837 Figure P.2—Node data structure for normalized topology.......................................................................... 838 Figure P.3—Self-ID packet topology analysis (nodes zero and one).......................................................... 838 Figure P.4—Self-ID packet topology analysis (node two).......................................................................... 839 Figure P.5—Self-ID packet topology analysis (node three)........................................................................ 839 Figure P.6—Self-ID packet topology analysis (node four) ......................................................................... 839 Figure P.7—Self-ID packet topology analysis (node five).......................................................................... 840 Figure P.8—Normalized topology (relative to node four) .......................................................................... 840 Figure P.9—Normalized topology with EUI-64 information...................................................................... 841 Figure P.10—Reference topology (changed root) ....................................................................................... 842 Figure P.11—Normalized topology (relative to node five) ......................................................................... 843 Figure P.12—Normalized topology with EUI-64 information (changed root) ........................................... 844 Figure P.13—Reference topology (inserted node) ...................................................................................... 845 Figure P.14—Normalized topology with EUI-64 information (inserted node)........................................... 845
Copyright © 2008 IEEE. All rights reserved.
xxxvii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Figure Q.1—Module architecture................................................................................................................ 847 Figure Q.2—Serial bus physical topology................................................................................................... 848 Figure Q.3—Serial bus addressing .............................................................................................................. 849 Figure Q.4—SBP stack................................................................................................................................ 851 Figure Q.5—Transaction services ............................................................................................................... 852 Figure Q.6—Simplified lock model ............................................................................................................ 853 Figure Q.7—Transaction request and response subaction queues............................................................... 854 Figure Q.8—Example asynchronous subactions ......................................................................................... 855 Figure Q.9—Example isochronous subactions............................................................................................ 855 Figure Q.10—Link layer services................................................................................................................ 856 Figure Q.11—Unified transaction example................................................................................................. 856 Figure Q.12—Split transaction example ..................................................................................................... 857 Figure Q.13—Split transaction using concatenated subactions................................................................... 858 Figure Q.14—Example of concatenated asynchronous subactions............................................................. 858 Figure Q.15—Example of concatenated isochronous subactions ............................................................... 858 Figure Q.16—Cycle structure...................................................................................................................... 860 Figure Q.17—DS encoding ......................................................................................................................... 861 Figure Q.18—DS encoder and decoder example ........................................................................................ 862 Figure Q.19—Fairness interval.................................................................................................................... 862 Figure Q.20—Fair arbitration ...................................................................................................................... 863 Figure Q.21—Cable PHY............................................................................................................................ 864 Figure Q.22—Example cable state after bus initialization process ............................................................. 865 Figure Q.23—Tree identify process complete............................................................................................. 865 Figure Q.24—Example cable state after self-identify phase ....................................................................... 867 Figure Q.25—Arbitration request................................................................................................................ 867 Figure Q.26—Arbitration request (continued) ............................................................................................ 868 Figure Q.27—Arbitration grant ................................................................................................................... 868 Figure Q.28—Data prefix ............................................................................................................................ 869 Figure Q.29—Start of data transmission ..................................................................................................... 869 Figure Q.30—Cable interface...................................................................................................................... 871 Figure Q.31—Fair/urgent arbitration example ............................................................................................ 873 Figure Q.32—Fly-by concatenation ............................................................................................................ 878 Figure Q.33—Master architecture ............................................................................................................... 884 Figure Q.34—BOSS pipelined, overlapping arbitration ............................................................................. 888 Figure Q.35—T-mode coding functions...................................................................................................... 896
xxxviii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
List of tables Table 1-1—Size notation examples ................................................................................................................. 5 Table 1-2—C code operators summary ........................................................................................................... 6 Table 1-3—Additional C data types ................................................................................................................ 7 Table 1-4—Sample CSR addressing conventions ........................................................................................... 9 Table 1-5—Register definition fields ............................................................................................................ 10 Table 1-6—Read value fields ........................................................................................................................ 10 Table 1-7—Write-effect fields....................................................................................................................... 10 Table 4-1—Short-haul copper cables and connectors ................................................................................... 29 Table 4-2—6-circuit connector socket signal assignment ............................................................................. 34 Table 4-3—Performance group A ................................................................................................................. 40 Table 4-4—Performance group B.................................................................................................................. 42 Table 4-5—Performance group C.................................................................................................................. 42 Table 4-6—Performance group D ................................................................................................................. 43 Table 4-7—Performance group E.................................................................................................................. 45 Table 4-8—Performance group F .................................................................................................................. 46 Table 4-9—Performance group G ................................................................................................................. 47 Table 4-10—6-circuit cable attenuation ........................................................................................................ 49 Table 4-11—4-circuit connector socket signal assignment ........................................................................... 52 Table 4-12—Performance group A ............................................................................................................... 59 Table 4-13—Performance group B................................................................................................................ 60 Table 4-14—Performance group C................................................................................................................ 60 Table 4-15—Performance group D ............................................................................................................... 61 Table 4-16—Performance group E................................................................................................................ 63 Table 4-17—Performance group F ................................................................................................................ 65 Table 4-18—Performance group G ............................................................................................................... 65 Table 4-19—4-circuit signal pairs attenuation .............................................................................................. 67 Table 4-20—Beta and bilingual socket contact assignment .......................................................................... 72 Table 4-21—Cable assembly components .................................................................................................... 85 Table 4-22—Interface speed matrix .............................................................................................................. 85 Table 4-23—Type 1 cable assembly ............................................................................................................. 86 Table 4-24—Type 2 cable assembly ............................................................................................................. 87 Table 4-25—Type 3 cable assembly ............................................................................................................. 88 Table 4-26—Performance group A ............................................................................................................... 89 Table 4-27—Performance group B................................................................................................................ 90 Table 4-28—Performance group C................................................................................................................ 91 Table 4-29—Performance group D ............................................................................................................... 92 Table 4-30—Performance group E................................................................................................................ 94 Table 4-31—Performance group F ................................................................................................................ 95 Table 4-32—Performance group G ............................................................................................................... 95 Table 4-33—Text fixture pad position to PHY function map ..................................................................... 100 Table 4-34—Signal pairs attenuation .......................................................................................................... 101 Table 5-1—Summary of backplane PHY layer services ............................................................................. 105 Table 5-2—Backplane transmit data timing ................................................................................................ 113 Table 5-3—Backplane receive data timing ................................................................................................. 114 Table 5-4—Maximum transceiver package and bus skew .......................................................................... 114 Table 5-5—Backplane PHY timing requirements....................................................................................... 115 Table 5-6—Arbitration bit timing................................................................................................................ 117 Table 5-7—DATA_PREFIX signal transitions after packet transmission .................................................. 127 Table 5-8—DATA_END signal transitions after packet transmission ....................................................... 127 Table 6-1—Summary of link layer services ................................................................................................ 129 Table 6-2—Summary of link control request actions and parameters ........................................................ 131 Table 6-3—Summary of asynchronous packet components ....................................................................... 138
Copyright © 2008 IEEE. All rights reserved.
xxxix
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table 6-4—Maximum payload size for asynchronous data packets ........................................................... 142 Table 6-5—Data_length values for lock requests........................................................................................ 144 Table 6-6—Summary of isochronous packet components .......................................................................... 146 Table 6-7—Maximum payload size for isochronous stream packets.......................................................... 147 Table 6-8—Destination ID encoding........................................................................................................... 150 Table 6-9—Retry code encoding ................................................................................................................. 151 Table 6-10—Transaction code encoding ..................................................................................................... 151 Table 6-11—Extended transaction code encoding ...................................................................................... 152 Table 6-12—Response code encoding ........................................................................................................ 153 Table 6-13—Tag field encoding.................................................................................................................. 154 Table 6-14—Acknowledge codes................................................................................................................ 156 Table 6-15—Busy acknowledgments .......................................................................................................... 157 Table 6-16—Cycle sync event code ............................................................................................................ 161 Table 6-17—CRC generation and checking ................................................................................................ 168 Table 7-1—Summary of transaction layer services..................................................................................... 171 Table 7-2—Summary of transaction data confirmation during transition TX1:TX0b ................................ 183 Table 7-3—Summary of transaction event indication during transition TX2:TX0a................................... 184 Table 7-4—Acknowledge value in link data response during transition RX1:RXOb ................................ 186 Table 7-5—Summary of lock transaction functions.................................................................................... 189 Table 7-6—Outbound subaction retry code decision table ......................................................................... 190 Table 7-7—Saturated arithmetic procedures ............................................................................................... 191 Table 7-8—CSR architecture/serial bus transaction mapping..................................................................... 195 Table 8-1—Reset types................................................................................................................................ 203 Table 8-2—Core CSR locations .................................................................................................................. 204 Table 8-3—Serial-Bus-dependent registers................................................................................................. 209 Table 8-4—Request subactions eligible for priority asynchronous arbitration ........................................... 215 Table 8-5—Lock (compare_swap) algorithm for BANDWIDTH_AVAILABLE ..................................... 217 Table 8-6—Lock (compare_swap) algorithm for CHANNELS_AVAILABLE......................................... 219 Table 8-7—Serial-bus-dependent registers in initial units space ................................................................ 222 Table 8-8—Encoding of max_rec field ....................................................................................................... 226 Table 8-9—Encoding of max_ROM field ................................................................................................... 227 Table 8-10—SBM variables ........................................................................................................................ 229 Table 9-1—Short-haul copper PMD modes of operation............................................................................ 248 Table 9-2—Differential output signal amplitude......................................................................................... 250 Table 9-3—Differential receive signal amplitude ....................................................................................... 251 Table 9-4—TPA common mode output voltage.......................................................................................... 251 Table 9-5—TPB common mode input voltage............................................................................................ 252 Table 9-6—Port_Status signal condition ..................................................................................................... 252 Table 9-7—TPB common mode output current and TPA common mode input current ............................ 253 Table 9-8—Arbitration signaling levels ...................................................................................................... 253 Table 9-9—Differential input impedance.................................................................................................... 254 Table 9-10—DS media data rates ................................................................................................................ 255 Table 9-11—Output rise and fall times ....................................................................................................... 255 Table 9-12—Input slope .............................................................................................................................. 256 Table 9-13—DS jitter and skew (in ns) ....................................................................................................... 256 Table 9-14—Arbitration signal generation rules ......................................................................................... 257 Table 9-15—Arbitration signal decoding rules ........................................................................................... 258 Table 9-16—DS PHY transmitted arbitration line states ............................................................................ 258 Table 9-17—DS PHY received arbitration line states................................................................................. 259 Table 9-18—Cable interface timing constants ............................................................................................ 260 Table 9-19—Gap detection times ................................................................................................................ 265 Table 9-20—Gap times at originating node ................................................................................................ 265 Table 9-21—Beta mode short-haul copper transmitter characteristics........................................................ 267 Table 9-22—Normalized time intervals for TP2 ......................................................................................... 271
xl
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table 9-23—Eye values for Figure 9-19 ..................................................................................................... 273 Table 9-24—Short-haul copper receiver characteristics when using Beta mode ........................................ 274 Table 9-25—Minimum amplitude for receiver jitter tolerance test............................................................. 277 Table 9-26—S3200 electrical test selection ................................................................................................ 278 Table 9-27—Electrical signal assignments.................................................................................................. 279 Table 9-28—Connection tone...................................................................................................................... 279 Table 9-29—SIGNAL_DETECT value definition...................................................................................... 280 Table 9-30—signal_detect timing ............................................................................................................... 280 Table 9-31—No Signal budget .................................................................................................................... 281 Table 9-32—High-frequency jitter corner frequency .................................................................................. 282 Table 9-33—S400b short-haul copper jitter output ..................................................................................... 282 Table 9-34—S400b short-haul copper jitter tolerance ................................................................................ 282 Table 9-35—S800b short-haul copper jitter output ..................................................................................... 283 Table 9-36—S800b short-haul copper jitter tolerance ................................................................................ 283 Table 9-37—S1600b short-haul copper jitter output ................................................................................... 283 Table 9-38—S1600b short-haul copper jitter tolerance .............................................................................. 284 Table 9-39—S3200b short-haul copper jitter output ................................................................................... 284 Table 9-40—S3200b short-haul copper jitter tolerance .............................................................................. 284 Table 9-41—Intrapair skew ......................................................................................................................... 285 Table 9-42—Cable power source requirements .......................................................................................... 290 Table 10-1—Operating range for 50 μm MMF........................................................................................... 296 Table 10-2—Optical transmit characteristics .............................................................................................. 297 Table 10-3—Optical receive characteristics................................................................................................ 298 Table 10-4—Optical signal_detect thresholds .................................................................................... 298 Table 10-5—Worst-case connection optical power budget and penalties................................................... 298 Table 10-6—High-frequency jitter corner frequency .................................................................................. 299 Table 10-7—S400β MMF jitter output........................................................................................................ 299 Table 10-8—S400β MMF jitter tolerance ................................................................................................... 299 Table 10-9—S800β MMF jitter output........................................................................................................ 300 Table 10-10—S800β MMF jitter tolerance ................................................................................................. 300 Table 10-11—S1600β MMF jitter output.................................................................................................... 300 Table 10-12—S1600β MMF jitter tolerance ............................................................................................... 301 Table 10-13—50 μm MMF connection insertion loss at 850 nm wavelength ............................................ 303 Table 10-14—50 μm MMF characteristics ................................................................................................. 304 Table 11-1—Worst-case loss increments for 50m POF cable and 100m HPCF cable ............................... 309 Table 11-2—Optical parameters for POF-HPCF interface at S100β and S200β........................................ 311 Table 11-3—Optical signal_detect thresholds .................................................................................... 311 Table 11-4—High-frequency jitter corner frequency .................................................................................. 311 Table 11-5—S100β POF and HPCF jitter output........................................................................................ 312 Table 11-6—S100β POF and HPCF jitter tolerance ................................................................................... 312 Table 11-7—S200β POF and HPCF jitter output........................................................................................ 312 Table 11-8—S200β POF and HPCF jitter tolerance ................................................................................... 313 Table 11-9—Trade-off for the number of connections and transmission length......................................... 313 Table 11-10—Optical parameters in case of POF and HPCF connection................................................... 313 Table 12-1—UTP transmission distances.................................................................................................... 317 Table 12-2—Standard media interface connector pin assignments............................................................. 318 Table 12-3—Alternate media interface connector pin assignments ............................................................ 319 Table 12-4—UTP transmitter electrical specifications ............................................................................... 320 Table 12-5—Coordinates for S100 signal mask.......................................................................................... 321 Table 12-6—S200/S400 normalized time intervals for TP2 ....................................................................... 322 Table 12-7—UTP receiver electrical specifications .................................................................................... 323 Table 12-8—SIGNAL_DETECT value definition ........................................................................................ 324 Table 12-9—signal_detect timing ............................................................................................................... 324 Table 13-1—Control mapping..................................................................................................................... 330
Copyright © 2008 IEEE. All rights reserved.
xli
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table 13-2—Asynchronous request mapping ............................................................................................. 331 Table 13-3—Isochronous request mapping ................................................................................................. 331 Table 13-4—Request and phase mapping ................................................................................................... 332 Table 13-5—Configuration request mapping .............................................................................................. 332 Table 13-6—5B/6B coding.......................................................................................................................... 338 Table 13-7—3B/4B coding.......................................................................................................................... 338 Table 13-8—Valid data characters .............................................................................................................. 339 Table 13-9—K28.x special characters......................................................................................................... 346 Table 13-10—Control coding ...................................................................................................................... 347 Table 13-11—Special character decoding ................................................................................................... 348 Table 13-12—Control stretching formats.................................................................................................... 350 Table 13-13—Speed code formats .............................................................................................................. 352 Table 13-14—Data padding formats ........................................................................................................... 353 Table 13-15—Speed code decoding ............................................................................................................ 355 Table 13-16—C code variables used in Beta port state machines............................................................... 357 Table 14-1—Media-dependent Beta mode speed requirements.................................................................. 363 Table 14-2—Variables and functions used in port connection manager state machine .............................. 363 Table 14-3—Connection management constants ........................................................................................ 364 Table 14-4—Connect_status value in various connection scenarios........................................................... 380 Table 14-5—Serial bus Message Code 5, bit a............................................................................................ 388 Table 15-1—PHY register fields for the cable environment ....................................................................... 390 Table 15-2—PH_EVENT.indication(INTERRUPT) sources ..................................................................... 393 Table 15-3—PHY register Port Status page fields ...................................................................................... 395 Table 15-4—PHY register Vendor Identification page fields ..................................................................... 399 Table 15-5—PHY register fields for the backplane environment ............................................................... 400 Table 16-1—Summary of PHY services ..................................................................................................... 402 Table 16-2—Cable PHY speed codes ......................................................................................................... 406 Table 16-3—PHY packet identifier bits ...................................................................................................... 414 Table 16-4—Alpha self-ID packet fields..................................................................................................... 415 Table 16-5—Alpha Link-on packet fields ................................................................................................... 417 Table 16-6—Alpha PHY configuration packet fields ................................................................................. 418 Table 16-7—Alpha ping packet fields......................................................................................................... 418 Table 16-8—Alpha remote access packet fields.......................................................................................... 419 Table 16-9—Alpha remote reply packet fields............................................................................................ 420 Table 16-10—Alpha remote command packet fields .................................................................................. 420 Table 16-11—Alpha remote confirmation packet fields ............................................................................. 421 Table 16-12—Alpha resume packet fields .................................................................................................. 422 Table 16-13—Beta self-ID packet fields ..................................................................................................... 423 Table 16-14—Beta Remote command packet fields ................................................................................... 424 Table 16-15—Beta Remote confirmation packet fields .............................................................................. 425 Table 16-16—Beta PHY configuration packet fields.................................................................................. 426 Table 16-17—LTP fields ............................................................................................................................. 428 Table 16-18—Maximum payload size for Beta data packets...................................................................... 428 Table 16-19—C code functions and variables............................................................................................. 434 Table 16-20—Asynchronous requests......................................................................................................... 437 Table 16-21—Isochronous requests ............................................................................................................ 438 Table 17-1—Comparison of Alpha, Beta, and Beta Plus PHY-link interfaces ........................................... 459 Table 17-2—Summary of PHY-link interface signals ................................................................................ 459 Table 17-3—Alpha PHY-link interface signal descriptions........................................................................ 461 Table 17-4—Ctl[0:1] when PHY is driving ................................................................................................ 462 Table 17-5—Ctl[0:1] when the link is driving (upon a grant from the PHY) ............................................. 462 Table 17-6—LPS timing parameters ........................................................................................................... 463 Table 17-7—Initialization of the Alpha PHY-link interface ....................................................................... 465 Table 17-8—LinkOn timing parameters...................................................................................................... 466
xlii
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table 17-9—Bus request format for cable environment ............................................................................. 467 Table 17-10—Bus request format for backplane environment.................................................................... 467 Table 17-11—Register read request format................................................................................................. 468 Table 17-12—Register write request format ............................................................................................... 468 Table 17-13—Acceleration control request format ..................................................................................... 468 Table 17-14—Request type field ................................................................................................................. 469 Table 17-15—Request speed field............................................................................................................... 469 Table 17-16—Link request effects on PHY variables................................................................................. 469 Table 17-17—Link rules to initiate a request on LReq ............................................................................... 471 Table 17-18—PHY disposition of link request ........................................................................................... 472 Table 17-19—Alpha PHY-link interface timing constants ......................................................................... 473 Table 17-20—Alpha PHY-link interface status bits.................................................................................... 475 Table 17-21—Speed code signaling ............................................................................................................ 476 Table 17-22—DC specifications for the Alpha PHY-link interface............................................................ 480 Table 17-23—AC timing parameters for the Alpha PHY-link interface..................................................... 481 Table 17-24—AC timing parameters at the PHY........................................................................................ 482 Table 17-25—AC timing parameters at the link ......................................................................................... 483 Table 17-26—Alpha link to PHY delay timing parameters ........................................................................ 484 Table 17-27— Beta and Beta Plus PHY-link interface signal descriptions ................................................ 486 Table 17-28— Beta Plus PHY-link interface operating modes................................................................... 488 Table 17-29—Timing parameters specified in terms of absolute time ....................................................... 489 Table 17-30—Timing parameters specified in terms of number of PClk or LClk...................................... 490 Table 17-31—Initialization of the Beta and Beta Plus PHY-link interface ................................................ 492 Table 17-32—LinkOn timing parameters.................................................................................................... 494 Table 17-33—Link request types to PHY ................................................................................................... 494 Table 17-34—RT[0:3] field encoding ......................................................................................................... 499 Table 17-35—Request format values .......................................................................................................... 501 Table 17-36—Beta and Beta Plus speed encodings .................................................................................... 501 Table 17-37—Ctl[0:1] state encoding when the PHY controls the PHY-link interface.............................. 502 Table 17-38—Receive packet SPD interval encoding ................................................................................ 505 Table 17-39—Ctl[0:1] state encoding when the link controls the PHY-link interface ............................... 506 Table 17-40—Format type during GRANT cycle ....................................................................................... 510 Table 17-41—Grant Type values during GRANT cycle............................................................................. 510 Table 17-42—Speed types during GRANT cycle ....................................................................................... 511 Table 17-43—Subaction end notification during the MORE_INFO cycle ................................................. 511 Table 17-44—Link request type during MORE_INFO cycle ..................................................................... 512 Table 17-45—Link request speed during MORE_INFO cycle ................................................................... 512 Table 17-46—Link request format during MORE_INFO cycle ................................................................. 512 Table 17-47—Bit encoding for Bus Status Transfers.................................................................................. 518 Table 17-48—Beta and Beta Plus PHY Status Transfer encoding.............................................................. 520 Table 17-49—Beta and Beta Plus PHY-link critical delays........................................................................ 521 Table 17-50—Mapping of Beta PHY-link signals to Alpha signals ........................................................... 522 Table 17-51—DC specifications for the Beta PHY-link interface .............................................................. 523 Table 17-52—DC specifications for the Beta Plus PHY-link interface ...................................................... 524 Table 17-53—Beta interface ac timing parameters ..................................................................................... 525 Table 17-54—Beta Plus interface ac timing parameters ............................................................................. 525 Table 18-1—Packet prefix Data Byte 1 encoding ....................................................................................... 537 Table 18-2—Data Byte 1 encoding ............................................................................................................. 537 Table 18-3—Interrupt encoding .................................................................................................................. 538 Table 19-1—C code definitions................................................................................................................... 539 Table 19-2—Data structures and enumerated types .................................................................................... 539 Table 19-3—PHY services .......................................................................................................................... 545 Table 19-4—Arbitration state machine internal variables........................................................................... 548 Table 19-5—Variables shared between architectural elements................................................................... 550
Copyright © 2008 IEEE. All rights reserved.
xliii
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table 19-6—Node-level connection monitor functions and routines ......................................................... 558 Table 19-7—Port connection manager actions and conditions ................................................................... 567 Table 19-8—DS receive port ....................................................................................................................... 588 Table 19-9—DS transmit port ..................................................................................................................... 591 Table 19-10—DS speed signaling filter ...................................................................................................... 593 Table 19-11—Beta port receive actions and conditions .............................................................................. 595 Table 19-12—Beta port transmit actions and conditions ............................................................................ 606 Table 19-13—T port receive actions ........................................................................................................... 611 Table 19-14—T port transmit actions.......................................................................................................... 624 Table 19-15—Border transmit functions ..................................................................................................... 631 Table 19-16—Border receive functions ...................................................................................................... 636 Table 19-17—PHY packet processing ........................................................................................................ 641 Table 19-18—Legacy arbitration functions................................................................................................. 645 Table 19-19—Border arbitration functions ................................................................................................. 647 Table 19-20—Background request processing............................................................................................ 654 Table 19-21—Bus reset actions ................................................................................................................... 664 Table 19-22—Tree identify actions ............................................................................................................. 667 Table 19-23—Self-identify actions ............................................................................................................. 668 Table 19-24—Idle actions ........................................................................................................................... 673 Table 19-25—Grant actions......................................................................................................................... 680 Table 19-26—Transmit actions ................................................................................................................... 681 Table 19-27—Receive actions..................................................................................................................... 685 Table 20-1—Asynchronous request mapping ............................................................................................. 694 Table 20-2—Isochronous request mapping ................................................................................................. 694 Table 20-3—Legacy request and phase mapping........................................................................................ 694 Table 20-4—Configuration request mapping .............................................................................................. 695 Table 20-5—Control token mapping ........................................................................................................... 696 Table 20-6—Control stretching formats...................................................................................................... 697 Table 20-7—Speed code formats ................................................................................................................ 698 Table 20-8—Data padding formats ............................................................................................................. 699 Table 20-9—Symbol decode rules for nonerrored symbols ........................................................................ 699 Table 20-10—Symbol decode rules for errored symbols ............................................................................ 700 Table 20-11—Speed code decoding ............................................................................................................ 702 Table 21-1—GMII signal usage .................................................................................................................. 706 Table C.1—Internal device power connector pin allocation ....................................................................... 716 Table C.2—Internal device power connector configurations ...................................................................... 716 Table C.3—Internal device primary and secondary port pin allocation...................................................... 717 Table C.4—Internal device option connector pin allocation ....................................................................... 717 Table C.5—Internal device signal description ............................................................................................ 717 Table C.6—Electrical interface specifications ............................................................................................ 718 Table C.7—Options pin comparison ........................................................................................................... 719 Table C.8—Performance group A ............................................................................................................... 736 Table C.9—Performance group B ............................................................................................................... 738 Table C.10—Performance group C ............................................................................................................. 739 Table C.11—Performance group D ............................................................................................................. 740 Table C.12—Performance group E ............................................................................................................. 741 Table C.13—Performance group F.............................................................................................................. 742 Table C.14—Performance group G ............................................................................................................. 742 Table D-1—Backplane propagation delay .................................................................................................. 744 Table D-2—Gap types ................................................................................................................................. 747 Table D-3—Acknowledge gap sample time................................................................................................ 747 Table D-4—Acknowledge gap hold time .................................................................................................... 748 Table D-5—Difference in gap times ........................................................................................................... 749 Table D-6—Gap timing ............................................................................................................................... 749
xliv
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Table D-7—Backplane environment skew analysis .................................................................................... 752 Table E.1—Gap count as a function of hops ............................................................................................... 756 Table E.2—S100 jitter budget (ns) .............................................................................................................. 757 Table E.3—S200 jitter budget (ns) .............................................................................................................. 758 Table E.4—S400 jitter budget (ns) .............................................................................................................. 758 Table E.5—Port status encoding ................................................................................................................. 769 Table E.6—Example self-ID packet port status values ............................................................................... 770 Table F.1—Serial bus signal mapping and pin assignment......................................................................... 774 Table I.1—Table of socket PCB mounting styles and footprint figures ..................................................... 790 Table K.1—Connection matrix for signal pairs impedance tests (connector)............................................. 802 Table K-2—Connection matrix for power pair impedance tests ................................................................. 815 Table K-3—Connection matrix for power pair resistance tests................................................................... 817 Table K-4—Connection matrix for crosstalk tests between power and signal pairs................................... 819 Table K-5—Connection matrix for crosstalk tests between signal pairs..................................................... 820 Table L.1—Transfer impedance performance requirements ....................................................................... 828 Table M.1—Power provider ranges by POWER_CLASS and launch voltage ........................................... 830 Table P.1—Topology analysis of self-ID packets ....................................................................................... 841 Table P.2—Normalized topology comparison ............................................................................................ 843 Table Q.1—Beta-mode media summary ..................................................................................................... 886
Copyright © 2008 IEEE. All rights reserved.
xlv
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Standard for a High-Performance Serial Bus IMPORTANT NOTICE: This standard is not intended to assure safety, security, health, or environmental protection in all circumstances. Implementers of the standard are responsible for determining appropriate safety, security, environmental, and health practices or regulatory requirements. This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading "Important Notice" or "Important Notices and Disclaimers Concerning IEEE Documents." They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/disclaimers.
1. Overview 1.1 Scope and purpose 1.1.1 Scope This standard describes a high-speed, low-cost serial bus suitable for use as a peripheral bus, a backup to parallel backplane buses, or a local area network. Highlights of the serial bus include the following: a)
Bus transactions that include both block and single quadlet reads and writes, as well as an “isochronous” mode that provides a low-overhead guaranteed bandwidth service.
b)
A fair bus access mechanism that guarantees all nodes equal access. The backplane environment adds a priority mechanism, but one that ensures that nodes using the fair protocol are still guaranteed at least partial access.
c)
Automatic assignment of node addresses—no need for address switches.
d)
A physical layer (PHY) supporting both long-haul and short-haul cable media and backplane buses.
e)
Variable speed data transmission based on ISDN-compatible1 bit rates from 24.576 Mbit/s for transistor-transistor logic (TTL) backplanes to 49.152 Mbit/s for backplane transceiver logic (BTL) backplanes. For the cable medium, data transmission rates of 98.304 Mbit/s (known as S100), S200, S400, S800, S1600, and S3200 are supported.
f)
A short-haul cable medium that allows up to 16 physical connections (cable hops), each up to 4.5 m, giving a total cable distance of 72 m between any two devices. Bus management recognizes smaller configurations to optimize performance.
1
The lowest data rate of 24.576 Mbit/s is exactly 18 times the 1.536 Mbit/s and 12 times the 2.048 Mbit/s Integrated Services Digital Network (ISDN) primary rates. It is also an integer multiple of the ISDN basic rate and numerous other communication rates.
Copyright © 2008 IEEE. All rights reserved.
1
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
g)
A long-haul cable medium that permits connections up to 100 m in length over unshielded twisted pair (UTP) cable and glass optical fiber (GOF) and up to 50 m over plastic optical fiber (POF).
h)
Consistency with ISO/IEC 13213:1994 (IEEE Std 1212™, 1994 Edition).2
1.1.2 Purpose This standard incorporates the contents of IEEE Std 1394™-1995 as revised by IEEE Std 1394a™-2000, IEEE Std 1394b™-2002, and IEEE Std 1394c™-2006. In addition, over 100 errata have been corrected, and several new features have been added per Q.12.
1.2 Document organization This standard contains this overview, a list of definitions, an informative summary description, chapters of technical specification, and application annexes. The new reader should read the document in order. The actual specification follows the summary and is organized from the bottom up; that is, the specification starts at the PHY (cable and backplane), works up to the link layer, the transaction layer, and the bus management layer.
1.3 Serial bus applications Three primary applications have driven the design and architecture of the serial bus: an alternate for a parallel backplane bus, a low-cost peripheral bus, and a bus bridge between architecturally compatible 32-bit buses. 1.3.1 Alternate bus There are five main reasons for providing a serial bus on a system that already has a parallel bus: a)
The many modules that make up a system might operate on different backplane bus standards, yet they need to work together.
b)
Although located within the same enclosure, a system is too large or physically disperse to use a single backplane, yet modules in the different backplanes have to communicate.
c)
One or more modules of a system are located neither on the same backplane nor within the same enclosure.
d)
A redundant data path increases fault tolerance. A system can use the serial bus to isolate and diagnose errors without depending on the failed parallel bus.
e)
Many system modules are price-sensitive and do not need the full bandwidth of a parallel bus.
1.3.2 Low-cost peripheral bus The serial bus can also be used as a powerful and low-cost peripheral interconnect. The compact serial bus cable and connector allow bandwidths comparable with existing input/output (I/O) interconnect standards. The serial bus has the added advantage of architectural compatibility with parallel computer buses; this compatibility leads to lower communications overhead than with limited, function-dedicated I/O interconnects. 2
Information on references can be found in Clause 2.
2
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
1.3.3 Bus bridge The serial bus architecture limits the number of nodes on any bus to 63, but supports multiple bus systems via bus bridges. The command and status register (CSR) architecture defines the serial bus addressing structure, which allows almost 216 nodes. A bus bridge normally eavesdrops on the bus, ignoring all transactions between local addresses but listening carefully for remote transactions. When the bridge receives a packet for a remote address, it forwards the packet to an adjacent bus. Although the serial bus may be used in many bus configurations, when used to bridge CSR-architecturecompliant buses, it is expected to be used mostly in a hierarchical bus fashion, as illustrated in Figure 1-1 (where bus #5 is a serial bus and bridges together other CSR-architecture-compliant bus #1 through bus #4, bus #1 could be IEEE 896 Futurebus+® ([B23], [B24], [B26]),3,4 bus #2 could be IEEE 1596 scalable coherent interface (SCI) ([B25]), and so on).
Figure 1-1—Example hierarchical bus topology
1.4 Service model This standard uses a protocol model with multiple layers. Each layer provides services to the next higher layer and to serial bus management (SBM). These services are abstractions of a possible implementation; an actual implementation may be significantly different and still meet all the requirements. The method by which these services are communicated between the layers is not defined by this standard. Four types of service are defined by this standard as follows: a)
Request service. A request service is a communication from a layer to a lower or adjacent layer to request some action. A request may also communicate parameters that may or may not be associated with an action. A request may or may not be confirmed. A data transfer request usually triggers a corresponding indication on peer node(s). (Because broadcast addressing is supported on a serial bus, it is possible for the request to trigger a corresponding indication on multiple nodes.)
3 Futurebus+ 4
is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. The numbers in brackets correspond to the numbers of the bibliography in Annex S.
Copyright © 2008 IEEE. All rights reserved.
3
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
b)
Indication service. An indication service is a communication from a layer to a higher or adjacent layer to indicate a change of state or other event detected by the originating layer. An indication may also communicate parameters that are associated with the change of state or event. Indications are not necessarily triggered by requests; an indication may or may not be responded to by a response. A data transfer indication is originally caused by a corresponding request on a peer node.
c)
Response service. A response service is a communication from a layer to a lower or adjacent layer in response to an indication; a response is always associated with an indication. A response may communicate parameters that indicate its type. A data transfer response usually triggers a corresponding confirmation on a peer node.
d)
Confirmation service. A confirmation service is a communication from a layer to a higher or adjacent layer to confirm a request service; a confirmation is always associated with a request. A confirmation may communicate parameters that indicate the completion status of the request or that indicate other status. For data transfer requests, the confirmation may be caused by a corresponding response on a peer node.
If all four service types exist, they are related as shown by Figure 1-2.
Requester
Responder
Request
Indication Response
Confirmation
Figure 1-2—Service model
1.5 Document notation 1.5.1 Mechanical notation All mechanical drawings in this standard use millimeters as the standard unit and follow ASME Y14.2M2003 [B14] and ASME Y14.5M-2004 [B15] formats. 1.5.2 Signal naming All electrical signals are shown in all uppercase characters, and active-low signals have the suffix “*”. For example, TPA and TPA* are the normal and inverted signals in a differential pair. 1.5.3 Size notation This standard avoids the terms word, half-word, and double-word, which have widely different definitions depending on the word size of the processor. In their place, processor-independent terms (some of which have been defined by the CSR architecture) are used. These terms are illustrated in Table 1-1.
4
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 1-1—Size notation examples Size (in bits)
16-bit word notation
32-bit word notation
IEEE standard notation (used in this standard)
8
byte
byte
byte
16
word
half-word
doublet
32
long-word
word
quadlet
64
quad-word
double
octlet
The serial bus uses big-endian ordering for byte addresses within a quadlet and quadlet addresses within an octlet. For 32-bit quadlet registers, byte 0 is always the most significant byte of the register. For a 64-bit quadlet-register pair, the first quadlet is always the most significant. The field on the left (most significant) is transmitted first; within a field, the most significant bit (MSB), i.e., the leftmost, is also transmitted first. This ordering convention is illustrated in Figure 1-3. bits in a quadlet: quad_bit_example msb middle_bits 1
30
lsb 1
bytes in a quadlet: quad_byte_example byte_0 byte_1 byte_2
msb
8
8
8
msb Note that specifications use field widths
lsb
byte_3 8
quadlets in an octlet: dual_quadlet_example quadlet_high quadlet_low 32
msb
32
Figure 1-3—Bit and byte ordering Although the serial bus addresses are defined to be big endian, their data values may also be processed by little-endian processors. To minimize the confusion between conflicting notations, the location and size of bit fields are usually specified by width, rather than their absolute positions, as is also illustrated in Figure 1-3. When specific bit fields must be used, the CSR architecture convention of consistent big-endian numbering is used. Hence, the MSB of a quadlet will be labeled “quad_bit_example[0],” the most significant byte of a quadlet (“byte_0”) will be labeled “quad_byte_example[0:7],” and the most significant quadlet in an octlet (“quadlet_high”) will be labeled “dual_quadlet_example[0:31].” The MSB shall be transmitted first for all fields and values defined by this standard, including the data values read or written to CSRs.
1.5.4 Numerical values Decimal, hexadecimal, and binary numbers are used within this standard. For clarity, the decimal numbers are generally used to represent counts, hexadecimal numbers are used to represent addresses, and binary numbers are used to describe bit patterns within binary fields.
Copyright © 2008 IEEE. All rights reserved.
5
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Decimal numbers are represented in their standard 0, 1, 2, ... format. Hexadecimal numbers are represented by a string of one or more hexadecimal (0-9, A-F) digits followed by the subscript 16. Binary numbers are represented by a string of one or more binary (0,1) digits, followed by the subscript 2. Thus the decimal number “26” may also be represented as “1A16” or “110102”. In C code examples, hexadecimal numbers have a “0x” prefix and binary numbers have a “0b” prefix, so the decimal number “26” would be represented by “0x1A” or “0b11010”.
1.5.5 Packet formats Serial bus packets consist of a sequence of quadlets. Packet formats are shown using the style given in Figure 1-4. tra nsm itte d first qua dle t 1 qua dle t 2
othe r qua dle ts
tra nsm itte d la s t
Figure 1-4—Sample packet format Fields appear in packet formats with their correct position and widths. Field widths are also stated explicitly in field descriptions. Bits in a packet are transmitted starting with the upper leftmost bit and finishing with the bottom rightmost bit. Given the rules in 1.5.3, the MSB of each field is sent first.
1.5.6 Register formats All serial bus registers are documented in the style used by the CSR architecture.
1.5.7 C code notation The conditions and actions of the state machines are formally defined by C code. Although familiar to software engineers, C code operators are not necessarily obvious to all readers. The meanings of C code operators, arithmetic, relational logical and bitwise, both unary and binary, are summarized in Table 1-2.
Table 1-2—C code operators summary Operator
6
Description
+, -, * and /
Arithmetic operators for addition, subtraction, multiplication, and integer division
%
Modulus; x % y produces the remainder when x is divided by y
>, >=, < and <=
Relational operators for greater than, greater than or equal, less than, and less than or equal
== and !=
Relational operators for equal and not equal; the assignment operator, =, should not be confused with ==
++
Increment; i++ increments the value of the operand after it is used in the expression while ++i increments it before it is used in the expression
--
Decrement; post-decrement, i--, and pre-decrement, --i, are permitted.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 1-2—C code operators summary (continued) Operator
Description
&&
Logical AND
||
Logical OR
!
Unary negation; converts a nonzero operand into 0 and a zero operand into 1
&
Bitwise AND
|
Bitwise inclusive OR
^
Bitwise exclusive OR (XOR)
<<
Left shift; x << 2 shifts the value of x left by two bit positions and fills the vacated positions with zero
>>
Right shift; vacated bit positions are filled with zero or one according to the data type of the operand, but in this standard are always filled with zero
~
Ones complement (unary)
A common construction in C is conditional evaluation, in the form (expr) ? expr1 : expr2. This indicates that if the logical expression expr evaluates to a nonzero value, then expr1 is evaluated. Otherwise, expr2 is evaluated. For example, x = (q > 5) ? x + 1 : 14 first evaluates q > 5. If nonzero (TRUE), x is incremented; otherwise, x is assigned the value 14. The descriptions above are casual; if in doubt, the reader is encouraged to consult ISO/IEC 9899:1999. The C code examples assume the data types listed in Table 1-3 are defined.
Table 1-3—Additional C data types Data type
Description
Timer
A real number, in units of seconds, that autonomously increments at a defined rate
Boolean
A single bit, where 0 encodes FALSE and 1 encodes TRUE
All C code is to be interpreted as if it could be executed instantaneously, but time may elapse when conditional expressions are evaluated as part of iterated C code. Time elapses unconditionally only when the wait_time function is called and may elapse when the wait_event function is called: void wait_time(float time); // Wait for time, in seconds, to elapse void wait_event (event); // Wait for an event to be signaled
The C code has been extended with a construct to allow the description of operations that execute in parallel. Two new keywords are defined: fork . . . join
These keywords define a construct that contains a number of components that execute in parallel. The components may include statements that take time to execute (for example wait_time(. . .)). The
Copyright © 2008 IEEE. All rights reserved.
7
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
construct terminates when all the components have terminated. The construct is illustrated in the following example: fork { // first parallel component . . . } { // second parallel component . . . } . . . { // final parallel component . . . } join
1.5.8 State machine notation All state machines in this standard use the style shown in Figure 1-5.
state label
S0: State Zero
S1: State One
actions started on entry to S0
condition for transition from S1 to S0
condition for transition from S0 back to itself action taken on this transition
actions started on entry to S1
S0:S0
action taken on this transition
S1:S0
condition for transition from S0 to S1 S0:S1
note that the S0 actions are restarted following this transition
action taken on this transition
transition label
Figure 1-5—State machine example These state machines make three assumptions: —
Time elapses only within discrete states.
—
State transitions are logically instantaneous; therefore, the only actions taken during a transition are setting flags and variables and sending signals. These actions complete before the next state is entered.
—
Every time a state is entered, the actions of that state are started. A transition that points back to the same state will repeat the actions from the beginning. All the actions started upon entry complete before any tests are made to exit the state.
1.5.9 CSR, ROM, and field notation This standard describes a number of CSRs and fields within these registers. To distinguish register and field names from node states or descriptive text, the register name is always capitalized. Thus, the notation STATE_CLEAR.lost is used to describe the lost bit within the STATE_CLEAR register. All CSRs are quadlets and are quadlet aligned. The address of a register (which is always a multiple of four) is specified as the byte offset from the beginning of the initial register space. When a range of register
8
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
addresses is described, the ending address is the address of the last register, which is also a multiple of four. These addressing conventions are illustrated in Table 1-4.
Table 1-4—Sample CSR addressing conventions Offset 0 4–12
Register name
Description
STATE_CLEAR
First CSR location
OTHER_REGISTERS
Next three CSR locations
This standard describes a number of configuration read-only memory (ROM) entries and fields within these entries. To distinguish ROM entry and field names from node states or descriptive text, the first character of the entry name is always capitalized. Thus, the notation Bus_Info_Block.cmc is used to describe the cmc bit within the Bus_Info_Block entry. Entries within temporary data structures, such as packets, timers, and counters, are shown in lowercase (following normal C-language conventions) and are formatted in a fixed-space typeface. Examples are arb_timer and connected[i]. NOTE—Within the C code, the character formatting is not used, but the capitalization rules are followed.5
1.5.10 Register specification format This standard defines the format and function of serial-bus-specific CSRs. Registers may be read only, write only, or both readable and writable. The same distinctions may apply to any field within a register. A CSR specification includes the format (i.e., the sizes and names of bit field locations), the initial value of the register, the value returned when the register is read, and the effect(s) when the register is written. An example register is illustrated in Figure 1-6.
definition unit_dependent 12
vendor_dependent 16
sig
resv why
not
1
1
1
1
1
0
0
0
initial value unit_dependent
zeros
read value last write
last update
w
0
u
u
s
i
i
e
write effect stored
ignored
Figure 1-6—Example of CSR format specification 5
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement this standard.
Copyright © 2008 IEEE. All rights reserved.
9
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The register definition lists the names of register fields. These names are descriptive, but the fields are defined in the text; their function should not be inferred solely from their names. However, the register definition fields in Figure 1-6 have the meanings specified by Table 1-5.
Table 1-5—Register definition fields Name
Abbreviation
Definition
unit dependent
unit_depend
The meaning of this field shall be defined by the unit architecture(s) of the node.
vendor dependent
vendor_depend
The meaning of this field shall be defined by the vendor of the node. Within a unit architecture, the unit-dependent fields may be defined to be vendor dependent.
A node’s CSRs shall be initialized when power is restored [power-on reset (POR)] and may be initialized when a bus reset occurs or a quadlet is written to the node’s RESET_START register (command reset). If a CSR’s bus reset or command reset values differ from its initial values, they shall be explicitly specified. The read value fields in Figure 1-6 have the meanings specified by Table 1-6.
Table 1-6—Read value fields Name
Abbreviation
Definition
last write
w
The value of the data field shall be the value that was previously written to the same register address.
last update
u
The value of the data field shall be the last value that was updated by node hardware.
The write-effect fields in Figure 1-6 have the meanings specified by Table 1-7.
Table 1-7—Write-effect fields Name
Abbreviation
Definition
stored
s
The value of the written data field shall be immediately visible to reads of the same register.
ignored
i
The value of the written data field shall be ignored; it shall have no effect on the state of the node.
effect
e
The value of the written data field shall have an effect on the state of the node, but may not be immediately visible to reads of the same register.
1.5.11 Reserved registers and fields Reserved fields within a CSR conform to the requirements of the conformance glossary in this standard (see R.1). Within a CSR, such a field is labeled reserved (sometimes abbreviated as lowercase r or resv).
10
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Reserved fields behave as specified by Figure 1-7: they shall be zero, and any attempt to write to them shall be ignored.
definition reserved 32
initial values zeros
read values zeros
write effects ignored
Figure 1-7—Reserved CSR field behavior This is straight-forward as it applies to read and write requests. The same rules apply to lock requests, but the behaviors are less obvious; see 6.2.2.3.2 for details.
1.5.12 Operation description priorities The description of operations in this standard are done in three ways: state machines, C code segments, and English language. If more than one description is present, then priority shall be given first to the state machines, then the C code segments, and finally to the English text (including the descriptions following the state machines).
1.6 Compliance 1.6.1 CSR architecture compliance The serial bus follows ISO/IEC 13213:1994 in the following specific ways: a)
Addressing: The serial bus uses 64-bit fixed addressing. See Q.3.
b)
Transactions: 1)
The CSR-architecture-defined transactions of read1-read64, write1-write64, lock4, and lock8 are equivalent to the serial bus transactions described in 7.3.5.2. The serial bus also specifies byte-aligned block read and write transactions from 1 byte to 2048 bytes, depending on the data rate as described in Table 6-4.
2)
The clock strobe signal is implemented by the serial bus cycle start packet described in 6.2.2.2.3.
c)
Error status codes: Type_error, address_error, and conflict_error are all possible values of the status returned in a transaction response. The serial bus calls these “response codes,” and there are additional bus-specific values. See 6.1.1 for more details.
d)
Resets: Power_reset and command_reset are described in 5.5.1.
e)
STATE_CLEAR: The bus_depend bits of the STATE_CLEAR register are all optional and are described in 8.3.2.2.1.
Copyright © 2008 IEEE. All rights reserved.
11
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
f)
IEEE STANDARD FOR A
NODE_IDs: 1)
offset_id: The serial bus calls this identifier the “physical_ID.” For cable environments, the values are chosen during the self-identify process described in 16.4.7. In such environments, this physical_ID is a read-only value. For backplane environments, these values are dependent on the application environment (see 5.4.2.1).
2)
bus_depend: The bus-dependent field shall be all zeros and is a read-only value.
g)
SPLIT_TIMEOUT_HI and SPLIT_TIMEOUT_LO: Only the low-order 3 bits of SPLIT_TIMEOUT_HI (seconds) are to be implemented (8 s maximum timeout), and the higher order 13 bits of SPLIT_TIMEOUT_LO count at a granularity of 125 μs, not 1/8192 s.
h)
Bus-dependent registers: The serial bus has the following optional CSRs; see 8.3.2.3 for details: 1)
CYCLE_TIME
2)
BUS_TIME
3)
POWER_FAIL_IMMINENT
4)
POWER_SOURCE
5)
INCUMBENT_ANSWER
6)
BANDWIDTH_ALLOCATE
7)
CHANNELS_AVAILABLE_HI
8)
CHANNELS_AVAILABLE_LO
9)
MAINTENANCE_CONTROL
10) MAINTENANCE_UTILITY i)
Bus_dependent ROM entries: The serial bus has the following extra ROM entries; see 8.3.2.3.11 for details: 1)
Node_Capabilities root entry
2)
NodeUniqueId leaf
3)
Bus_Dependent_Info directory
4)
Topological_Map location
5)
Speed_Map location
1.6.2 Serial bus PHYs The following minimum performance is required: a)
Cable PHY: 1)
b)
12
98.304 Mbit/s data bit transmit/receive
Backplane PHY: 1)
Data bit transmit/receive at 49.152 Mbit/s for BTL and emitter-coupled logic (ECL)
2)
Data bit transmit/receive at 24.576 Mbit/s for TTL
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
2. Normative references The following referenced documents are indispensable for the application of this standard (i.e., they must be understood and used, so each referenced document is cited in text and its relationship to this standard is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. AF-PHY-0015.000 (Sept. 1994), ATM Physical Medium Dependent Interface Specification for 155 Mb/s over Twisted Pair Cable.6 ANSI X3.230-1994 (Reaff 2001), American National Standard for Information Technology—Fibre Channel—Physical and Signaling Interface (FC-PH).7 ANSI X3.263-1995 (Reaff 2000), American National Standard for Information Technology—Fibre Distributed Data Interface (FDDI)—Token Ring Twisted Pair Physical Layer Medium Dependent (TP-PMD). ANSI/EIA 364-B-90, Electrical Connector Test Procedures Including Environmental Classifications.8 ANSI/EIA 364-C-94, Classifications.
Electrical
Connector/Socket
Test
Procedures
Including
Environmental
ANSI/EIA 364-06A-83 (R90), Contact Resistance Test Procedure for Electrical Connectors. ANSI/EIA 364-09C-06, Durability Test Procedure for Electrical Connectors and Contacts. ANSI/EIA 364-102-98, Rise Time Degradation Test Procedure for Electrical Connectors, Sockets, Cable Assemblies or Interconnection Systems. ANSI/EIA 364-103-99, Propagation Delay Test Procedure for Electrical Connectors, Sockets, Cable Assemblies or Interconnection Systems. ANSI/EIA 364-13B-98, Mating and Unmating Forces Test Procedures for Electrical Connectors. ANSI/EIA 364-17B-99, Temperature Life With or Without Electrical Load Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-18A-84, Visual and Dimensional Inspection for Electrical Connectors. ANSI/EIA 364-20B-99, Withstanding Voltage Test Procedure for Electrical Connectors, Sockets and Coaxial Contacts. ANSI/EIA 364-21B-96, Insulation Resistance Test Procedure for Electrical Connectors. ANSI/EIA 364-23C-06, Low Level Contact Resistance Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-27B-96, Mechanical Shock (Specified Pulse) Test Procedure for Electrical Connectors. 6 ATM Forum publications are available from the ATM Forum, 2570 West El Camino Real, Suite 304, Mountain View, CA 94040-1313. They may also be downloaded from http://www.atmforum.com. 7ANSI publications are available from the Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/). 8 EIA publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com).
Copyright © 2008 IEEE. All rights reserved.
13
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
ANSI/EIA 364-28D-99, Vibration Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-31A-83 (R90), Humidity for Electrical Connectors. ANSI/EIA 364-32B-92, Thermal Shock Test Procedure for Electrical Connectors. ANSI/EIA 364-41C-99, Cable Flexing Test Procedure for Electrical Connectors. ANSI/EIA 364-46A-98, Microsecond Discontinuity Test Procedure for Electrical Connectors, Contacts and Sockets. ANSI/EIA 364-65A-98, Mixed Flowing Gas. ANSI/TIA/EIA-455-127-91, Spectral Characterization of Multimode Laser Diodes. ANSI/TIA/EIA-455-54B-98, Mode Scrambler Requirements for Overfilled Launching Conditions to Multimode Fibers. ANSI/TIA/EIA-455-95A-00, Absolute Optical Power Test for Optical Fibers and Cables. ANSI/TIA/EIA-526-14A-98, Optical Power Loss Measurement of Installed Multimode Fiber Cable Plant. ANSI/TIA/EIA-568-B.1, Commercial Building Telecommunications Cabling Standard, Part 1: General Requirements. ANSI/TIA/EIA-568-B.2, Commercial Building Telecommunications Cabling Standard, Part 2: Balanced Twisted-Pair Cabling Components. ANSI/TIA/EIA-568-B.2-1, Commercial Building Telecommunications Cabling Standard, Part 2: Balanced Twisted-Pair Cabling Components Addendum 1 — Transmission Performance Specifications for 4-Pair 100 Ohm Category 6 Cabling. ANSI/TIA/EIA-568-C.3, Optical Fiber Cabling Components Standard. ANSI/TIA/EIA-604-93 (Reaff 2000), Fiber Optic Connector Intermateability Standards (FOCIS). IEC 60060-2, High voltage test techniques—Part 2: Measuring systems.9 IEC 60603-7, Connectors for frequencies below 3 MHz for use with printed boards—Part 7: Detail specification for connectors, 8-way, including fixed and free connectors with common mating features, with assessed quality. IEC 60793-1-41, Optical fibres—Part 1-41: Measurement methods and test procedures—Bandwidth. IEC 60793-2-10, Optical fibres—Part 2-10: Product specifications—Sectional specification for category A1 multimode fibers. IEC 60950, Information technology equipment—Safety. 9 IEC publications are available from the Sales Department of the International Electrotechnical Commission, Case Postale 131, 3, rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse (http://www.iec.ch/). IEC publications are also available in the United States from the Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http:// www.ansi.org/).
14
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
IEC 61000-4-2, Electromagnetic compatibility (EMC)—Part 4-2: Testing and measurement techniques— Electrostatic discharge immunity test. IEC 61753-1, Fibre optic interconnecting devices and passive components performance standard— Part 1: General and guidance for performance standards IEC 61754-16, Fibre optic connector interfaces—Part 16: Type PN connector family. IEC 61883-1, Consumer audio/video equipment—Digital interface—Part 1: General. IEEE Std 802.3™-2005, Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications.10 IEEE Std 1014™-1987, IEEE Standard for a Versatile Backplane Bus: VMEbus. IEEE Std 1194.1™-1991, IEEE Standard for Electrical Characteristics of Backplane Transceiver Logic (BTL) Interface Circuits. IEEE Std 1212™-2001, IEEE Standard for Control and Status Registers (CSR) Architecture for Microcomputer Buses. ISO/IEC 9899:1999, Programming languages—C.11 ISO/IEC 11801:2002, Information technology—Generic cabling for customer premises. ISO/IEC 13213:1994 [IEEE Std 1212, 1994 Edition], Information technology—Microprocessor systems— Control and Status Registers (CSR) Architecture for microcomputer buses. ITU-T G.957, Optical Interfaces for Equipments and Systems Relating to the Synchronous Digital Hierarchy Series G: Transmission Systems and Media, Digital Systems and Networks Digital Transmission Systems—Digital Sections and Digital Line System—Digital Line Systems Study Group 15.12 NCITS TR-25-1999, Information Technology—Fibre Channel—Methodologies for Jitter Specification.13
10 IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/). 11ISO/IEC publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse (http://www.iso.ch/). ISO/IEC publications are also available in the United States from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com/). Electronic copies are available in the United States from the American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http:// www.ansi.org/). 12 ITU-T publications are available from the International Telecommunications Union, Place des Nations, CH-1211, Geneva 20, Switzerland/Suisse (http://www.itu.int/). 13 NCITS T11.2 working documents are available at http://www.t11.org.
Copyright © 2008 IEEE. All rights reserved.
15
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
16
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
3. Definitions, acronyms, and abbreviations 3.1 Definitions For the purposes of this standard, the following definitions, terms, and notational conventions apply. The glossary (Annex R) or The Authoritative Dictionary of IEEE Standards Terms [B22] should be consulted for terms not defined in this clause. 3.1.1 3B/4B: A line code that maps 3-bit symbols to 4-bit symbols to achieve dc balance and bounded disparity. Used to create the 8B/10B code. 3.1.2 5B/6B: A line code that maps 5-bit symbols to 6-bit symbols to achieve dc balance and bounded disparity. Used to create the 8B/10B code. 3.1.3 8B/10B: A line code that maps 8-bit symbols to 10-bit symbols to achieve dc balance and bounded disparity. 3.1.4 802_mode: A port that is operating according to the specifications, including higher layer specifications, defined in IEEE Std 802.3-2005. 3.1.5 acknowledge packet: An 8-bit packet that may be transmitted in response to the receipt of a primary packet. The most and least significant nibbles are the ones complement of each other. 3.1.6 Alpha cloud: A collection of Alpha nodes and/or border nodes in which all internode connections are made through Alpha ports. 3.1.7 Alpha mode: A mode in which a port utilizes data-strobe (DS) transmission and arbitration and an Alpha PHY-link interface. NOTE—See 9.2, 16.4, and 17.2 for more information on Alpha mode transmission, arbitration, and PHY-
link interface, respectively.
3.1.8 Alpha port: A port that is operating in Alpha mode. 3.1.9 Alpha-only port: A port that is capable of operating only as a Alpha port. 3.1.10 arbitration request: An 8B/10B-coded symbol that is sent on a Beta port when it is not transmitting data. An arbitration request is used for bus owner/supervisor/selector (BOSS) arbitration and combines requests for both isochronous and asynchronous packet transmissions into a single symbol that, after scrambling, is represented by a single data character. 3.1.11 arbitration reset: If no node has an asynchronous request for the current fairness interval, the reset that is signaled to start a new asynchronous arbitration fairness interval. In an Alpha cloud, the reset is signaled by arbitration reset gap. In a B cloud, the reset is signaled by an arbitration reset token. 3.1.12 arbitration reset gap: The period of time on an Alpha bus that indicates the start of a new asynchronous arbitration fairness interval. An arbitration reset gap is longer than a subaction gap. 3.1.13 arbitration reset indication: An arbitration reset gap in an Alpha cloud or an arbitration reset token in a B cloud. 3.1.14 arbitration reset token: Either an ASYNC_EVEN or an ASYNC_ODD control token, which is sent in a B cloud to indicate the start of a new asynchronous arbitration fairness interval by changing the phase.
Copyright © 2008 IEEE. All rights reserved.
17
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
3.1.15 asynchronous packet: A primary packet transmitted in accordance with asynchronous arbitration rules (outside of the isochronous period). 3.1.16 B bus: An operating bus in which all nodes are operating as B physical layers (PHYs). 3.1.17 B cloud: A collection of B nodes and/or border nodes in which all internode connections are made through Beta ports. 3.1.18 B link: A link that is capable of operating in Beta mode and, in particular, issues requests appropriate to bus owner/supervisor/selector (BOSS) arbitration. 3.1.19 B node. A node whose physical layer (PHY) is operating as a B PHY. 3.1.20 B physical layer (PHY): A mode of PHY operation in which all the logically connected ports are operating in Beta mode and the link, if any, is not configured to operate in Alpha PHY-link mode. 3.1.21 base rate: A data rate of 98.304 Mbit/s ± 100 ppm. In a cable environment, all Alpha-capable nodes are capable of communicating at this rate, and all B-capable nodes are capable of communicating at 4 * base rate. 3.1.22 Beta mode: The mode in which a port transmits data using the 8B/10B symbol coding and obeys the bus owner/supervisor/selector (BOSS) arbitration protocol. The speed of a port sending in Beta mode is denoted by the β suffix (e.g., S400β). 3.1.23 Beta port: A port that is operating in Beta mode. 3.1.24 Beta-only port: A port that is capable of operating only as a Beta port. 3.1.25 bilingual port: A port that is capable of operating both as a Beta port and as a data-strobe (DS) port. One of the modes is selected at the time that the logical connection is made; which one is selected depends on the capabilities of the peer port. 3.1.26 B-only physical layer (PHY): A PHY that is capable of only B PHY mode of operation, i.e., all its ports are Beta-only ports and its link, if any, is a B link or a PHY that is integrated into the link (PIL). 3.1.27 border node: A node with both of the following features: —
Either its link operating as a B link or at least one Beta port, or both, and
—
Either its link operating as an Alpha link or at least one data-strobe (DS) port, or both.
3.1.28 boundary node: A node with two or more ports, at least one of which is active and another suspended. 3.1.29 B-parallel link: A mode of link operation in which the PHY-link signalling is provided to the physical layer (PHY) using a parallel interface. 3.1.30 bus identifier (ID): A 10-bit number uniquely specifying a particular bus within a system of multiple interconnected buses. 3.1.31 bus manager: The node that provides power management, sets the gap count in the cable environment, and publishes the topology of the bus and the maximum speed for data transmission between any two nodes on the bus. The bus manager node may also be the isochronous resource manager (IRM) node.
18
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
3.1.32 bus owner/supervisor/selector (BOSS): In a B cloud, the node currently responsible for making arbitration decisions. A node becomes BOSS by virtue of being the last node to transmit data in a subaction (in general, the node transmitting an acknowledge to a nonbroadcast asynchronous packet or the primary packet transmitter in all other cases) or by receiving a grant. The BOSS determines the end of the fairness interval and the end of isochronous intervals and notifies the other nodes. Finally, the BOSS selects the path to grant next, thereby passing the BOSS rights and responsibilities to another node. 3.1.33 bus owner/supervisor/selector (BOSS) arbitration: The arbitration scheme used by Beta mode ports. The principle features of BOSS arbitration are that the node making the arbitration decision varies, that arbitration requests may be overlapped with data transmission, and that both isochronous and asynchronous requests may be pipelined for the succeeding isochronous interval or fairness interval, respectively. NOTE—BOSS arbitration is discussed in more detail in Clause 16.
3.1.34 Category 5e (CAT-5e) unshielded twisted pair (UTP): UTP cabling that meets or exceeds the ISO/ IEC 11801:2002 specifications for Class D balanced twisted pair cabling (which is equivalent to CAT-5e cabling as specified in ANSI/TIA/EIA-568-B.2). 3.1.35 Category 6 (CAT-6) unshielded twisted pair (UTP): UTP cabling that meets or exceeds the ISO/ IEC 11801:2002 specifications for Class E balanced twisted pair cabling (which is equivalent to CAT-6 cabling as specified in ANSI/TIA/EIA-568-B.2-1). 3.1.36 channel: A relationship between a group of nodes, talkers, and listeners. The group is identified by a number between 0 and 63. Channel numbers are allocated cooperatively through isochronous resource management facilities. 3.1.37 character: A 10-bit sequence of data sent on a connection that is operating in B mode. 3.1.38 comma character or comma sequence: A bit sequence that defines boundaries for byte synchronization. 3.1.39 concatenated transaction: A split transaction comprising concatenated subactions. 3.1.40 configuration request: A request that conveys information pertaining to the configuration of the bus or supporting nonbus owner/supervisor/selector (non-BOSS) arbitration. A configuration request is encoded into a single symbol that, after scrambling, is represented by a data character. 3.1.41 connection: Two ports that can communicate with each other and the media between those two ports. 3.1.42 connection attenuation: The static loss of a connection between a transmitter and receiver. It includes the loss of the fiber, connectors, and splices. 3.1.43 connection penalties: The power penalties of a connection not attributed to connection attenuation. It includes modal noise, relative intensity noise (RIN), inter-symbol interface, mode partition noise, extinction ratio, and eye opening penalties. 3.1.44 connection tone: Signal used to indicate that a port is capable of operating in Beta mode. Also confirms that a connection exists between two Beta-capable ports. 3.1.45 control character: A 10-bit character used to convey control information. Control characters are distinguishable from data characters in that they are not 8B/10B characters. Each control character has zero disparity.
Copyright © 2008 IEEE. All rights reserved.
19
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
3.1.46 cycle start or cycle start packet: A primary packet sent by the cycle master that indicates the start of an isochronous interval. 3.1.47 data bit: The smallest signaling element used by the physical layer (PHY) for transmission of packet data on the medium. 3.1.48 data character: A character used by the 8B/10B code. 3.1.49 data-strobe (DS): A form of electrical signaling where data are transmitted on one differential pair and a strobe signal is transmitted on a separate differential pair. The data signal indicates the binary value being transmitted (0 or 1), and the strobe signal changes if the data signal remains constant in successive bit periods. 3.1.50 data-strobe (DS) port: A port that is operating according to Alpha specifications, in particular using DS electrical signaling and obeying the arbitration protocols defined therein. A DS-only port or a bilingual port can operate as a DS port. 3.1.51 data-strobe-only (DS-only) port: A port capable of operating only as a DS port. 3.1.52 dc balance: The requirement that over long runs of binary symbols no net disparity shall exist. 3.1.53 disconnected port: A port whose connection detect circuitry detects no peer physical layer (PHY) at the other end of a cable. 3.1.54 disparity: The number of ones in a transmission character minus the number of zeros in a character. 3.1.55 extended unique identifier 64 (EUI-64™)14: A 64-bit extended unique identifier that consists of a concatenation of a 24-bit organizationally unique identifier (OUI) value (which is assigned by the IEEE Registration Authority) and a 40-bit extension identifier (which is assigned by the organization that owns that OUI). 3.1.56 extinction ratio: The ratio of the average optical power representing a logical 1 to the average optical power representing a logical 0 measured when transients have settled. 3.1.57 eye diagram: Oscilloscope display of the physical layer (PHY) signal that is triggered on a bit edge and shows many different bit patterns overlaid on top of each other. 3.1.58 fairness interval: A time period delimited by arbitration reset indicators. Within a fairness interval, the total number of asynchronous packets that may be transmitted by a node is limited. Each node’s limit may be explicitly established by the bus manager or it may be implicit. 3.1.59 fan-out physical layer (FOP): A multiported physical layer (PHY) that is attached to a PHY that is integrated into the link (PIL) using a serial interface. NOTE—See Clause 18 for more details.
3.1.60 fiber attenuation: The static loss per unit length of the fiber at a particular wavelength, usually expressed in decibels per kilometer. 3.1.61 galvanic isolation: A mechanism to avoid low-frequency ground loop currents. 3.1.62 hybrid bus: An operating bus that contains at least one border node. 14
EUI-64 is a trademark of the Institute of Electrical and Electronics Engineers, Inc.
20
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
3.1.63 initial node space: The 256 tebibytes of serial bus address space that are available to each node. Addresses within initial node space are 48 bits and are based at zero. The initial node space includes initial memory space, private space, initial register space, and initial units space. NOTE—See either ISO/IEC 13213:1994 or Q.3 of IEEE Std 1394-2008 for more information on address spaces.
3.1.64 initial register space: A 2048-byte portion of initial node space with a base address of 0000 FFFF F00016. This address space is reserved for resources accessible immediately after a bus reset. NOTE—Core registers defined by ISO/IEC 13213:1994 for command and status register (CSR) architecture are located within initial register space as are serial-bus-dependent registers defined in Q.3 in IEEE Std 1394-2008.
3.1.65 isochronous: Uniform in time (i.e., having equal duration) and recurring at regular intervals. 3.1.66 isochronous interval: A period that begins after a cycle start packet is sent and ends with a subaction indication. During an isochronous interval, only isochronous subactions may occur. An isochronous interval begins, on average, every 125 μs. 3.1.67 isochronous resource manager (IRM): A node that implements the BUS_MANAGER_ID, BANDWIDTH_AVAILABLE, CHANNELS_AVAILABLE, and BROADCAST_CHANNEL registers (some of which permit the cooperative allocation of isochronous resources). Subsequent to each bus reset, one IRM is selected from all nodes capable of this function. 3.1.68 isochronous subaction: Within the isochronous interval, either a concatenated packet or a packet and the gap that preceded it. 3.1.69 jitter: Any variation in the zero-crossing time from the ideal bit pattern. 3.1.70 junior border: Any border node in a B cloud except the senior border. 3.1.71 K-code: An 8B/10B symbol that represents control information. 3.1.72 legacy: Characteristics or behavior of a link, node, physical layer (PHY), cable, or connector that is operating in Alpha mode. 3.1.73 legacy request: A request type that is originated by a border node on behalf of an Alpha link or a data-strobe (DS) port. 3.1.74 link: Link layer. Also, the physical entity that implements the link layer. Also, one of the components connected to the interface between the physical layer (PHY) and link. 3.1.75 link layer: The Serial Bus Protocol (SBP) layer that provides confirmed and unconfirmed transmission or reception of primary packets. Syn: link. 3.1.76 lock transaction: A transaction that passes an address, subcommand, and data parameter(s) from the requester to the responder and returns a data value from the responder to the requester. The subcommand specifies which indivisible update is performed at the responder; the returned data value is the previous value of the updated data. 3.1.77 lock-request packet: The packet transmitted during the request subaction portion of a lock transaction. 3.1.78 lock-response packet: The packet transmitted during the response subaction portion of a lock transaction.
Copyright © 2008 IEEE. All rights reserved.
21
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
3.1.79 logically connected port: A port whose “connected” status is true. If a port is physically connected to a peer that is not powered, then the port is not logically connected. 3.1.80 low-power connection signaling: Signaling, based on the exchange of very low duty cycle tones, by which the connectivity status of a port is determined. This signaling takes place when the port is not active or is disabled. 3.1.81 modal bandwidth: The bandwidth of a multimode fiber (MMF) due to dispersion caused by variations in speed of the propagating modes. 3.1.82 mode partition noise: Amplitude, frequency, and phase noise in the detected optical signal due to the interaction of the modes of a multimode laser and the optical dispersion of the connection. 3.1.83 module: The smallest component of physical management; i.e., a replaceable device. 3.1.84 near end crosstalk (NEXT): The noise induced in the receiving pair due to the signal on the transmitting pair on the same port. For example, the signal on the twisted pair B (TPB) can cause NEXT on the twisted pair A (TPA) of a port. 3.1.85 nephew node: A node with one port in standby and all other ports (if any) disabled, disconnected, or suspended. The peer uncle node proxies for the nephew node during bus resets. 3.1.86 node: A serial bus device that may be addressed independently of other nodes. A minimal node consists of only a physical layer (PHY) without an enabled link. If the link and other layers are present and enabled, they are considered part of the node. 3.1.87 null packet: A packet in which no data are transmitted. 3.1.88 octlet: Eight bytes, or 64 bits, of data. 3.1.89 operating speed: Nominal speed at which a port operating in Beta mode is communicating clocked information with its peer, measured in megabits per second (before 8B/10B encoding), usually identified with the “S” notation (e.g., S100, S200, S400). 3.1.90 optical power budget: The minimum optical power available to overcome the sum of attenuation plus power penalties of the optical path between the transmitter and receiver calculated as the difference between the transmitter launch power (minimum) and the receive sensitivity (minimum). 3.1.91 organizationally unique identifier (OUI): A 24-bit number globally assigned by the IEEE Registration Authority that uniquely identifies an organization, vendor, or manufacturer. 3.1.92 originating port: A transmitting port on a physical layer (PHY) that has no active receiving port. The source of the transmitted packet is either the PHY’s local link or the PHY itself. 3.1.93 overfilled launch (OFL): The condition that excites both radial and azimuthal modes defined in ANSI/TIA/EIA 455-54B. 3.1.94 packet: A sequence of zero or more bits transmitted on a serial bus and delimited by a packet start symbol and a packet end symbol. 3.1.95 packet delimiter: Sequence of control symbols that delineate the beginning and ending of a data packet.
22
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
3.1.96 packet speed: The data rate of a packet (necessarily less than or equal to the operating speed of a Beta-mode connection used to transmit the packet). 3.1.97 padding: Symbols inserted between data symbols in a packet to allow slower speed data to be transmitted on a higher speed connection. 3.1.98 physical identifier (ID): The 6 least significant bits (LSBs) of the node_ID. On a particular bus, each node’s physical_ID is unique. 3.1.99 physical layer (PHY): The Serial Bus Protocol (SBP) layer that translates the logical symbols used by the link layer into electrical signals on serial bus media. The PHY is self-initializing. PHY arbitration guarantees that only one node at a time is sending data. The mechanical interface is defined as part of the PHY. The PHY for the backplane is different from the PHY for the cable environment. 3.1.100 physical layer (PHY) packet: A 64-bit packet where the 32 most significant bits (MSBs) are the ones complement of the 32 least significant bits (LSBs). 3.1.101 physical layer (PHY) that is integrated into a link (PIL): A link that uses a modified Beta port to connect a fan-out PHY (FOP) over a serial interface. NOTE—See Clause 18 for more details.
3.1.102 physical link: In the cable physical layer (PHY), the simplex path from the transmit function of the port of one node to the receive function of a port of a directly connected node. 3.1.103 physical medium dependent (PMD) interface: The part of an interface that is specific to a single kind of interconnect. 3.1.104 ping: The transmission of a physical layer (PHY) packet to a particular node in order to time the response packet(s) provoked. 3.1.105 point-to-point (P2P) packet: Special packet type that is sent on the interface between a physical layer (PHY) that is integrated into a link (PIL) and a fan-out PHY (FOP) (known as the PIL-FOP interface). This packet is used to carry data that cannot be sent as part of normal serial bus packets. 3.1.106 port: The part of the physical layer (PHY) that allows connection to one other node. 3.1.107 port state machine: The logic that controls the functioning of a port. 3.1.108 primary packet: Any packet that is not an acknowledge or a physical layer (PHY) packet. A primary packet is an integral number of quadlets and contains a transaction code in the first quadlet. 3.1.109 proxy_root: In a B-only bus, the root. In a hybrid bus where the root is in a B cloud, the senior border in the B cloud containing the root. If the root is an Alpha node, then no proxy_root exists. 3.1.110 random jitter: Jitter that comes from random sources and is characterized by Gaussian statistics and unbounded variation according to the Gaussian distribution function. 3.1.111 receiver eye opening: The interval in time within a bit period where the sampled data value will have a probability of error less than the specified bit error ratio (BER). 3.1.112 register: The group of addresses that may be read or written to by serial bus transactions.
Copyright © 2008 IEEE. All rights reserved.
23
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTE—In the context of IEEE Std 1394, the use of the term register does not imply a specific hardware implementation. For example, for split transactions that permit sufficient time between the request and response subactions, the behavior of the register may be emulated by a processor within the module.
3.1.113 request: A primary packet (with optional data) sent by one node’s link (the requester) to another node’s link (the responder). 3.1.114 request type: An 8B/10B data character that connotes either an arbitration or configuration request. 3.1.115 response: A primary packet (with optional data) sent in response to a request subaction. 3.1.116 restore: The process of causing a connection in standby to return to the active state. 3.1.117 resume signal: A signal requiring the port to resume normal operations. 3.1.118 run length: The length of a sequence of bits that have the same value, e.g., ones or zeros. 3.1.119 running digital sum: The number of ones in a character stream minus the number of zeros in a character stream. 3.1.120 running disparity: An estimate of the running digital sum at the end of a character subblock, based upon the most recently transmitted (or received) character subblock. When initialized with the same value, the running disparity and running digital sum will be equal at the end of any character subblock. Errors in a received character stream may result in the running disparity being not equal to the running digital sum. 3.1.121 scrambler: A device that chooses transmitted signals from the set of all possible symbols by using both the desired symbol and a pseudo-randomly generated offset pointer. A scrambler is used to average out the spectral content of the transmitted signal to avoid strong spectral lines. 3.1.122 self-identifier (self-ID) packet: A physical layer (PHY) packet transmitted by a cable PHY during the self-identify phase or in response to a PHY ping packet. 3.1.123 senior border: A unique border node in a B cloud. The senior border is the last node to originate a self-identifier (self-ID) packet without a speed code into the cloud (i.e., repeated from a data-strobe (DS) port or generated because of an Alpha link) and is responsible for ensuring that certain Alpha gap timings are observed. 3.1.124 services: A set of capabilities provided by one protocol layer entity for use by a higher layer or by management entities. 3.1.125 split transaction: A transaction where unrelated subactions may take place on the bus between its request and response subactions. 3.1.126 standby: A low-power state of a Beta connection in which only low-power connection signaling takes place. No bus reset is generated as a result of a port entering or leaving the Standby state. 3.1.127 standby initiator: An active port that transmits the STANDBY configuration request and engages in a protocol with its connected peer physical layer (PHY) to place the connection into the Standby state. 3.1.128 subaction: A complete link layer operation: optional arbitration, packet transmission, and optional acknowledgment. 3.1.129 subaction gap: In an Alpha cloud, the period of idle bus that precedes arbitration for an asynchronous subaction.
24
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
3.1.130 subaction indication: A subaction gap or, in a B cloud, an ASYNC_EVEN/ODD control token of the current phase. 3.1.131 suspend: To go into a low-power mode of operation while maintaining low-power connection signaling. When a port enters or leaves the suspended state, a bus reset is generated. 3.1.132 synchronization: The process of aligning the receiver’s circuits to properly detect received bits and to properly detect symbol boundaries. 3.1.133 tebibyte: A quantity of data equal to 240, or 1 099 511 627 776, bytes. 3.1.134 T-mode: The mode in which the port transmits data over an unshielded twisted pair (UTP) link utilizing an IEEE 802.3 gigabit media independent interface (GMII). NOTE—Clause 20 and Clause 21 in IEEE Std 1394-2008.
3.1.135 T-mode only port: A port that is not capable of Beta mode operation on unshielded twisted pair (UTP) at S100 but is capable of operating in T-mode. 3.1.136 transmitting port: Any port transmitting clocked data or an arbitration state. A transmitting port is further characterized as either originating or repeating. 3.1.137 twin-mode: The capability of a device to support both T-mode and IEEE 802.3 operation on a common media interface connector. 3.1.138 uncle node: A node that proxies for a peer nephew node while the connection between the two is in standby. 3.1.139 unit: A component of a serial bus node that provides processing, memory, input and output (I/O), or some other functionality. Once the node is initialized, the unit provides a command and status register (CSR) interface. A node may have multiple units, which normally operate independently of each other. 3.1.140 unit architecture: The document that specifies the interface to, and the behaviors of, a unit implemented within a node. 3.1.141 unit interval: The nominal amount of time to transmit 1 bit. 3.1.142 unshielded twisted pair (UTP): Cabling as defined in ISO/IEC 11801:2002 (and the equivalent ANSI/TIA/EIA-568 series of specifications).
3.2 Acronyms and abbreviations A bit ACK AWG BER BOSS BTL CAT-5e CAT-6 CPR CRC
asynchronous phase bit acknowledge or acknowledgment American Wire Gauge bit error ratio bus owner/supervisor/selector backplane transceiver logic Category 5e (unshielded twisted pair cabling) Category 6 (unshielded twisted pair cabling) coupled power ratio cyclic redundancy code
Copyright © 2008 IEEE. All rights reserved.
25
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
CSR DS ECL EUI FIFO FOP FR4 FWHM G bit GASP GMII GOF HPCF HR ID IDC IRM ISDN LED LPS LSB LTD LTP LTS M bit MDI MMF MSB N bit NEXT NRZ OFL OUI PCB PDU PHY PIL pk-pk PLL PMD POF POR P2P R bit RF RIN
26
IEEE STANDARD FOR A
command and status register data-strobe emitter-coupled logic extended unique identifier first in, first out fan-out physical layer flame retardant 4 full width at half maximum generation number bit global asynchronous stream packet gigabit media independent interface glass optical fiber hard polymer clad fiber holding register identifier insulation displacement contact or connector isochronous resource manager Integrated Services Digital Network light-emitting diode link power status least significant bit loop test data loop test packet loop test symbol mode bit media dependent interface multimode fiber most significant bit reset notify bit near end crosstalk nonreturn to zero overfilled launch organizationally unique identifier printed circuit board protocol data unit physical layer PHY that is integrated into a link peak-to-peak phase locked loop physical medium dependent plastic optical fiber power-on reset point-to-point root bit radio frequency relative intensity noise
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
ROM SBM SBP SCI SMA SMT STP T bit TDR TPA TPB TTL UTP VCSEL
IEEE Std 1394-2008
read-only memory serial bus management Serial Bus Protocol scalable coherent interface subminiature version A surface-mounted shielded twisted pair gap count reset disable bit time domain reflectometry Twisted Pair A Twisted Pair B transistor-transistor logic unshielded twisted pair vertical cavity surface emitting laser
Copyright © 2008 IEEE. All rights reserved.
27
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
28
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
4. Short-haul copper connector and cable specification 4.1 Introduction The short-haul copper PHY provides the actual interface between nodes, including both the mechanical and electrical interface. At the lowest level, it includes the physical connection, which consists of the cable media itself, the connectors, and the electrical transceivers. The short-haul copper PHY also performs a number of higher-level functions including bus state determination, bus arbitration, all the encoding and decoding functions, synchronization of received data to a local clock, and a data repeat function. This clause specifies the electrical and mechanical properties of the cable media and connectors that are used to support the short-haul copper physical medium dependent (PMD). The electrical characteristics of the short-haul copper PMD are specified in Clause 9. Higher-layer functions are specified in Clause 16. Annex A provides additional specifications appropriate for system designers. Note that some normative (required) specifications are included in this annex. This clause defines two different types of cables and connectors (Alpha and Beta), each of which has two connector options, as summarized in Table 4-1.
Table 4-1—Short-haul copper cables and connectors Type
Data rates
Data transmission mode
Connectors
Supports bus power
Alpha
S100 to S400
Data-strobe (DS) (9.2)
6-circuit (4.2)
YES
4-circuit (4.3)
NO
Beta
S400 to S3200
Beta (9.3)
9-circuit Beta (4.4)
YES
S100 to S3200
Beta (9.3) or DS (9.2)
9-circuit bilingual (4.4)
YES
4.2 6-circuit Alpha connectors and cables The serial bus permits a branching and daisy-chaining connection topology. Power can be provided or consumed by any node on the bus as described in 9.2.1.7. The topology puts certain constraints on the individual cable assembly lengths and wire gages. The remarks below apply to external (intercrate) cabling, where extra care has to be exercised for safety and EMC compliance. (Intracrate connections are not standardized in this clause.)
Copyright © 2008 IEEE. All rights reserved.
29
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
This subclause specifies connectors and cables that have six contacts and six wires, plus shields. The plugs and sockets are mechanically identical at both ends of the cable, i.e., there is no polarization for directionality. WARNING The shield circuit of the serial bus external connection is an integral part of the electrical operation of the bus. The cable shield provides a primary electrical reference point for the conductors in the external cables and is the means by which the external cable shield is electrically connected to the enclosure wall. If this shield circuit does not perform as specified in this standard, three serious consequences may result: a)
The external cable may provide a direct path between separate enclosures that could be a personal shock hazard or could result in serious physical damage to the cables themselves.
b)
The system may produce excessive electromagnetic radiation that may interfere with other electronic equipment.
c)
The data transmission through the external cable may suffer severe degradation in quality with resulting system performance problems.
In order to ensure that the shield circuit is properly designed, the transfer impedance testing procedure specified in Annex L is recommended.
4.2.1 6-circuit connectors In typical applications, computer or peripheral equipment boxes shall present one or more connector sockets for attachment to other boxes via cables. The detachable ends of the cable shall be terminated with connector plugs. All dimensions, tolerances, and descriptions of features that affect the intermateability of the standardized shielded connector plugs and sockets are specified within this clause. Features of connector plugs and sockets that do not affect intermateability are not specified and may vary at the option of the manufacturer. Connector features that are not directly controlled within this clause shall be indirectly controlled by performance requirements in 4.2.3 and 4.2.4. The holes and patterns (footprint) for the mounting of some of the possible versions of connectors to the PCB are recommended in Annex I.
4.2.1.1 Connector plug The mating features of the 6-circuit connector plug are specified in Figure 4-1 and Figure 4-2. They will assure the intermateability of the plug with standardized sockets. It is recommended that the plug contacts have a cylindrical section in the contact area that makes contact at a right angle to the cylindrical section of the socket contacts, thus creating a “crossed cylinders” configuration. The contacts should be designed to create a Hertzian stress (combination of cylindrical radius, normal force, and base and surface material hardnesses) of 1550 000–1 900 000 kPa in the mating area. This is to assure that the low-energy signals used in this PHY are transmitted through the nonconductive films that are typically adsorbed on connector contacts. NOTE—When a cable assembly plug is mated with a socket connector, there shall be a minimum of 1.0 mm clearance between the overmold on the assembly plug and the shield flange on the socket. This clearance is designed into the system to allow proper mating of both passive and latching cable plug assemblies. Deviation of this clearance may affect the performance of the connector interface.
30
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 4-1 and Figure 4-2 describe a plug intended to be used when only detent retention with the socket is required.
Figure 4-1—6-circuit plug body
Copyright © 2008 IEEE. All rights reserved.
31
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-2—6-circuit plug section details 4.2.1.2 Connector plug terminations The termination of the stranded wire to the plug contacts may be varied to suit the manufacturing process needs of the cable assembler. For reference, the following methods are listed: crimp, insulation displacement (IDC), insulation piercing, welding, and soldering.
4.2.1.3 Connector socket The mating features of the connector socket are described in Figure 4-3 through Figure 4-6. They will assure the intermateability of the socket with standardized plugs.
32
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 4-3 and Figure 4-4 describe the outer metal shell, which acts as a protective shield to prevent mechanical damage, to provide electrostatic protection, and to maintain shield continuity and integrity. They define features that provide “detent” retention of the mated plug.
Figure 4-3—6-circuit socket shell
Copyright © 2008 IEEE. All rights reserved.
33
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-4—6-circuit socket shell detail Figure 4-5 and Figure 4-6 describe the “socket insertion wafer,” an insulating structure that positions and retains the contacts within the outer shell. They also define the “first-make, last-break” power contact (#1) and ground contact (#2). The leading edges of contacts #1 and #2 are intended to confine any erosion during “hot plugging” to a nonfunctional area of the contact surface. This will minimize contamination of the final resting area of the contact. The contacts are attached to the signals as shown in Table 4-2.
Table 4-2—6-circuit connector socket signal assignment Contact number
Signal name
Comment
1
VP
Cable power
2
VG
Cable ground
3
TPB*
4
TPB
5
TPA*
6
TPA
Strobe on receive, data on transmit (differential pair)
Data on receive, strobe on transmit (differential pair)
It is likely that there will be several variations of sockets to meet differing mounting orientation requirements, panel/bulk-head mounting, and/or assembly techniques. The holes and patterns (footprint) for the mounting of some of the possible versions of connectors to the printed circuit board (PCB) are recommended in Annex I.
34
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 4-5—6-circuit socket insertion wafer 4.2.1.4 Positive retention The plug and socket are inherently retained together by means of a detent, which may be overcome by a prevailing force to effect a release upon unmating. Additional parts may be added to the plug and socket to provide a much stronger positive retention feature. This is specified in Annex B. A socket that is equipped with the positive retention feature shall permit a plug without this feature to be inserted and retained by the detent [only], and to function normally otherwise. A socket that is not equipped with the positive retention feature shall permit a plug that is equipped with the positive retention feature to be inserted and retained by the detent [only], and to function normally otherwise. It is also possible that the panel mounting configuration (which is not controlled within this standard) may prevent the insertion of a plug equipped with positive retention features if the equipment was not designed for this purpose. The minimum mounting interval for sockets with and without the positive retention feature is shown in Annex I.
Copyright © 2008 IEEE. All rights reserved.
35
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-6—6-circuit socket insertion wafer details 4.2.1.5 Contact finish on plug and socket contacts It is necessary to standardize the electroplated finish on the contacts to assure the compatibility of plugs and sockets from different sources. The following standardized electroplatings are compatible, and one should be used on contacts. a)
0.76 μm (30 μin), minimum, gold, over 1.27 μm (50 μin), minimum, nickel.
b)
0.05 μm (2 μin), minimum, gold, over 0.76 μm (30 μin) minimum, palladium, over 1.27 μm (50 μin), minimum, nickel.
c)
0.05 μm (2 μin), minimum, gold, over 0.76 μm (30 μin) minimum, palladium-nickel alloy (80% Pd–20% Ni), over 1.27 μm (50 μin), minimum, nickel.
NOTES 1—Selective plating on contacts is acceptable. In that case, one of the above electroplatings shall cover the complete area of contact, including the contact wipe area. 2—A copper strike is acceptable under the nickel electroplate. 3—A palladium strike is acceptable over the nickel electroplate.
36
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
4.2.1.6 Termination finish on plug and contact socket terminals It is acceptable to use an electroplate of tin-lead with a minimum thickness of 3.04 μm (120 μin) over a minimum thickness of 1.27 μm (50 μin) nickel. A copper strike is acceptable under the nickel.
4.2.1.7 Shell finish on plugs and sockets It is necessary to standardize the plated finish on the shells to insure compatibility of products from different sources. Both shells shall be electroplated with a minimum of 3.03 μm (120 μin) of tin or tin alloy, or a galvanically compatible alloy, over a suitable underplate.
4.2.1.8 Connector durability The requirements of different end-use applications call for connectors that can be mated and unmated a different number of times without degrading performance beyond acceptable limits. Accordingly, this standard specifies minimum performance criteria of 1500 mating cycles.
4.2.2 Cables All cables and cable assemblies shall meet assembly criteria and test performance found in this standard.
4.2.2.1 Cable material Linear cable material typically consists of two twisted pair and two power conductors. The two twisted pairs carry the balanced differential data signals. The third pair of wires carries the bus power (nominally 8–40 Vdc). Figure 4-7 illustrates a reference design adequate for a 4.5 m cable. Insulation shall be sufficient for safety extra-low voltage (SELV) or 42 V rms. Subclause 4.2.4 describes the performance requirements for the cable assembly.
4.2.2.2 Cable assemblies Cable assemblies consist of two identical plug connectors joined by a length of cable material. The suggested maximum length is 4.5 m. This is to assure that a maximally configured cable environment does not exceed the length over which the end-to-end signal propagation delay would exceed the allowed time. Longer cable lengths are possible if special consideration is given to the actual serial bus system topology to be used, as discussed in greater detail in Annex A. The connector pins are terminated as shown in Figure 4-8. The two signal pairs “cross” in the cable to effect a transmit-to-receive interconnection. The individual shields on the signal pairs shall be connected to the VG pins of the plug. The outer shield shall have a secure low-impedance connection to the plug shield shell.
4.2.3 Connector and cable assembly performance criteria To verify the performance requirements, performance testing is specified according to the recommendations, test sequences and test procedures of ANSI/EIA 364-B-90. Table 1 of ANSI/EIA 364-B90 shows operating class definitions for different end-use applications. For the serial bus, the test specifications follow the recommendations for environmental class 1.3, which is defined as follows: “No air conditioning or humidity control with normal heating and ventilation.” The equipment operating environmental conditions shown for class 1.3 in Table 2 of ANSI/EIA 364-B-90 are —
Temperature: + 15 °C to + 85 °C
—
Humidity: 95% maximum
Copyright © 2008 IEEE. All rights reserved.
37
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-7—6-circuit cable material construction example (for reference only)
Class 1.3 is further described as operating in a “harsh environmental” state, but with no marine atmosphere. Accordingly, the performance groupings, the sequences within each group, and the test procedures shall follow the recommendations of ANSI/EIA 364-B-90, except where the unique requirements of the serial bus connector and cable assembly may call for tests that are not covered in ANSI/EIA 364-B-90, or where the requirements deviate substantially from those in that standard. In those cases, test procedures of other recognized authorities or specific procedures described in the annexes will be cited. Sockets, plugs, and cable assemblies shall perform to the requirements and pass all the following tests in the groups and sequences shown.
38
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 4-8—Example 6-circuit cable assembly and schematic
Testing may be done as follows: a)
Plug and socket only. In this case, for those performance groups that require it, the plugs may be assembled to the cable, to provide a cable assembly, by the connector manufacturer, or by a cable assembly supplier.
b)
Cable assembly (with a plug on each end) and socket. In this case, a single supplier may do performance testing for both elements, or a connector supplier may team up with a cable assembly supplier to do performance testing as a team.
c)
Cable assembly only (with a plug on each end). In this case, the cable assembly supplier should use a plug connector source that has successfully passed performance testing according to this standard.
d)
Plug only or socket only. In this case, the other half of the interface shall be procured from a source that has successfully passed performance testing according to this standard. For those performance
Copyright © 2008 IEEE. All rights reserved.
39
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
groups that require it, the plugs may be assembled to the cable, to provide a cable assembly, by the connector manufacturer, or by a cable assembly supplier. NOTES 1—All performance testing is to be done with cable material that conforms to this standard. In order to test to these performance groups, ANSI/EIA tests require that the cable construction used be specified. 2—All resistance values shown in the following performance groups are for connectors only, including their terminations to the wire and/or PCB but excluding the resistance of the wire. Resistance measurements shall be performed in an environment of temperature, pressure, and humidity specified by ANSI/EIA 364-B-90. 3—The numbers of units to be tested is a recommended minimum; the actual sample size is to be determined by requirements of users. This is not a qualification program.
4.2.3.1 Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration Number of samples: [2] Sockets, unassembled to PCB used for Phase 1, A1, and A2 (one each) [2] Sockets, assembled to PCB [2] Plugs, unassembled to cable used for Phase 1, A1, and A2 (one each) [2] Cable assemblies with a plug assembled to one end, 25.4 cm long Performance group A is summarized in Table 4-3.
Table 4-3—Performance group A Measurements to be performed
Test Phase Title
ID number
Severity or conditions
A1
Visual and dimensional inspection
ANSI/EIA 364-18A-84
Unmated connectors
A2
Plating thickness measurement
A3
None
A4
Vibration
A5
None
A6
Mechanical shock (specified pulse)
40
Title Dimensional inspection
Requirements for performance level
ID number Per Figure 4-2 through Figure 4-7
No defect that would impair normal operations. No deviation from dimensional tolerances. Record thickness; see 4.2.1.5.
ANSI/EIA 364-28A-83
ANSI/EIA 364-27A-83
Condition III (See note and Figure 4-9).
Condition G (See note and Figure 4-9).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated pair.
Continuity
ANSI/EIA 364-46-84
No discontinuity at 1 μs or longer. (Each contact.)
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Continuity
ANSI/EIA 364-46-84
No discontinuity at 1 μs or longer. (Each contact.)
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-3—Performance group A (continued) Measurements to be performed
Test Phase Title A7
ID number
None
Severity or conditions
Title Low-level contact resistance
Requirements for performance level
ID number ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
NOTE—Connectors are to be mounted on a fixture that simulates typical usage. The socket shall be mounted to a panel that is permanently affixed to the fixture. The mounting means shall include typical accessories such as an insulating member to prevent grounding of the shell to the panel and a PCB in accordance with the pattern shown in Annex E for the socket being tested. The PCB shall also be permanently affixed to the fixture. The plug shall be mated with the socket, and the other end of the cable shall be permanently clamped to the fixture.
Figure 4-9—Shock and vibration fixturing diagram 4.2.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Cable assemblies with a plug assembled to one end, 25.4 cm long
Copyright © 2008 IEEE. All rights reserved.
41
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Performance group B is summarized in Table 4-4.
Table 4-4—Performance group B Measurements to be performed
Test Phase Title
ID number
B1
None
B2
Thermal shock
ANSI/EIA 364-32B-92
B3
Humidity
ANSI/EIA 364-31A-83
Severity or conditions
Title
Requirements for performance level
ID number
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
Condition I 10 cycles (mated).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Condition C (504h). Method III (cycling) nonenergized. Omit steps 7a and 7b (mated).
Low-level contact resistance
ANS/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
4.2.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress Number of samples: [2] Sockets, unassembled to PCB [0] Sockets, assembled to PCB [2] Plugs, unassembled to cable used for Phase 1, A 1, and A2 (one) [0] Cable assemblies with a plug assembled to one end, 2 m long Performance group C is summarized in Table 4-5.
Table 4-5—Performance group C Measurements to be performed
Test Phase Title
ID number
C1
Withstanding voltage
ANSI/EIA 364-20A-83
C2
Thermal shock
ANSI/EIA 364-32B-92
42
Severity or conditions
Requirements for performance level
Title
ID number
Test voltage 500 Vdc ± 50 Vdc. Method C (unmated and unmounted).
Withstanding voltage
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
Condition I 10 cycles (unmated).
Withstanding voltage (same conditions as C1)
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-5—Performance group C (continued) Measurements to be performed
Test Phase Title
ID number
C3
Insulation resistance
ANSI/EIA 364-21B-96
C4
Humidity (cyclic)
ANSI/EIA 364-31A-83
Severity or conditions
Requirements for performance level
Title
ID number
Test voltage 500 Vdc ± 50 Vdc (unmated and unmounted).
Insulation resistance
ANSI/EIA 364-21B-96
100 MΩ minimum between adjacent contacts and contacts and shell.
Condition A (96 h). Method III nonenergized. Omit steps 7a and 7b.
Insulation resistance (same conditions as C3)
ANSI/EIA 364-21B-96
100 MΩ minimum.
4.2.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure Number of samples: [0] Sockets, unassembled to PCB [4] Sockets, assembled to PCB [0] Plugs, unassembled to cable used for Phase 1, A1, and A2 (one) [4] Cable assemblies with a plug assembled to one end, 25.4 cm long Performance group D is summarized in Table 4-6.
Table 4-6—Performance group D Measurements to be performed
Test Phase Title D1
None
D2
Continuityhousing (shell)
ID number
Copyright © 2008 IEEE. All rights reserved.
Severity or conditions
See Figure 4-10 for measurement points.
Title
Requirements for performance level
ID number
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
Contact resistance, braid to socket shell.
ANSI/EIA 364-06A-83
50 mΩ, maximum, initial from braid to socket shell at 100 mA, 5 Vdc open circuit maximum.
43
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-6—Performance group D (continued) Measurements to be performed
Test Phase Title D3
Durability
D4
None
D5
Continuityhousing (shell)
D6
Mixed flowing gas
D7
ID number ANSI/EIA 364-09B-91
Severity or conditions
Title
Requirements for performance level
ID number
(a) 2 mated pairs, 5 cycles. (b) 2 mated pairs, automatic cycling to 750 cycles, rate 500 cycles/h ± 50 cycles. Low-level contact resistant
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure 4-10 for measurement points.
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell at 100 mA, 5 Vdc open circuit maximum.
ANSI/EIA 364-65-92
Class II Exposures: (a) 2 mated pairs— unmated for 1 day. (b) 2 mated pairs—mated for 10 days.
Low level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Durability
ANSI/EIA 364-09B-91
Class II Exposures: (a) 2 mated pairs, 5 cycles. (b) 2 mated pairs, automatic cycling to 750 cycles, rate 500 cycles/h ± 50 cycles.
D8
Mixed flowing gas
ANSI/EIA 364-65-92
Class II Exposures: Expose mated for 10 days.
Low-level contact resistance at end of exposure
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
D9
Continuityhousing (shell)
See Figure 4-10 for measurement points.
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ, maximum, initial from braid to socket shell at 100 mA, 5 Vdc open circuit maximum.
44
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 4-10—Shield and contact resistance measuring points
4.2.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable used for Phase 1, A1, and A2 (one) [2] Cable assemblies with a plug assembled to one end, 2 m long Performance group E is summarized in Table 4-7.
Table 4-7—Performance group E Measurements to be performed
Test Phase Title E1
Mating and unmating forces
ID number ANSI/EIA 364-13A-83
Copyright © 2008 IEEE. All rights reserved.
Severity or conditions
Title
Mount socket rigidly. Insert receptacle by hand.
Mating only
Auto rate: 25 mm/min.
Unmating only
Requirements for performance level
ID number
ANSI/EIA 364-13A-83
Unmating force: 9.8 N minimum 39.2 N maximum.
45
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-7—Performance group E (continued) Measurements to be performed
Test Phase Title E2
None
E3
Continuityhousing (shell)
E4
Temperature life
E5
Continuityhousing (shell)
E6
Mating and unmating forces
ID number
ANSI/EIA 364-17A-87
ANSI/EIA 364-13A-83
Severity or conditions
Title
Requirements for performance level
ID number
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
See Figure 4-11 (in 4.3.1.1).
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ, maximum, initial from braid to socket shell at 100 mA, 5 Vdc open circuit maximum.
Condition 4 (105° C) 250 h. Method A (mated).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell at 100 mA, 5 Vdc open circuit maximum.
ANSI/EIA 364-13A-83
Unmating force: 9.8 N minimum 39.2 N maximum.
Mount socket rigidly. Insert plug by hand.
Mating only
Auto rate: 25 mm/min.
Unmating only
4.2.3.6 Performance group F: Mechanical retention and durability Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Plugs, assembled to cable, one end only, 25 cm long Performance group F is summarized in Table 4-8.
Table 4-8—Performance group F Measurements to be performed
Test Phase Title F1
46
Mating and unmating forces
ID number ANSI/EIA 364-13A-83
Severity or conditions Mount socket rigidly. Insert plug by hand.
Title
Requirements for performance level
ID number
Mating only
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-8—Performance group F (continued) Measurements to be performed
Test Phase Title
ID number
Severity or conditions
Title
Requirements for performance level
ID number
F2
Mating and unmating forces
ANSI/EIA 364-13A-83
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13A-83
Unmating force: 9.8 N minimum 39.2 N maximum.
F3
Durability
ANSI/EIA 364-09B-91
Automatic cycling to 1500 cycles. 500 cycles/h ± 50 cycles.
Unmating only
ANSI/EIA 364-13A-83
Unmating force at end of durability cycles: 9.8 N minimum 39.2 N maximum.
4.2.3.7 Performance group G: General tests Suggested procedures to test miscellaneous but important aspects of the interconnect are given in Table 4-9. Since the tests listed below may be destructive, separate samples shall be used for each test. The number of samples to be used is listed under the test title.
Table 4-9—Performance group G Measurements to be performed
Test Phase
G1
Title
ID number
Electrostatic discharge
IEC 610004-2
Severity or conditions
Title
1–8 kV in 1.0 kV steps. Use 8 mm ball probe. Test unmated.
Evidence of discharge
Fix plug housing and apply a 98 N load for 1 min on cable axis.
Continuity, visual
Requirements for performance level
ID number No evidence of discharge to any of the six contacts; discharge to shield is acceptable.
[1 plug] [1 socket] G2
Cable axial pull test
ANSI/EIA 364-46-84
No discontinuity on contacts or shield greater than 1 μs under load. No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
[2 plugs]
Copyright © 2008 IEEE. All rights reserved.
47
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-9—Performance group G (continued) Measurements to be performed
Test
Requirements for performance level
Phase Title G3
Cable flexing
Severity or conditions
ID number ANSI/EIA 364-41B-89
[2 plugs]
Title
ID number
Condition I, dimension
(a) Withstandin g voltage
Per C1
Per C1
X = 3.7 × cable diameter; 100 cycles in each of two planes.
(b) Insulation resistance
Per C3
Per C3
(c) Continuity
ANSI/EIA 364-46-84
No discontinuity on contacts or shield greater than 1 μs during flexing.
(d) Visual
No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
4.2.4 Signal propagation performance The test procedures for all parameters listed in this subclause are described in Annex K.
4.2.4.1 Signal impedance The differential mode characteristic impedance of the signal pairs shall be measured by time domain reflectometry (TDR) at less than 100 ps rise time using the procedure described in K.3: ZTPA = (110 ± 6) Ω (differential) ZTPB = (110 ± 6) Ω (differential) The common mode characteristic impedance of the signal pairs shall be measured by TDR at less than 100 ps rise time using the procedure described in K.3: ZTPACM = (33 ± 6) Ω (common mode) ZTPBCM = (33 ± 6) Ω (common mode)
4.2.4.2 Signal pairs attenuation A signal pairs attenuation requirement applies only to the two signal pairs for any given cable assembly. See Table 4-10. Attenuation is measured using the procedure described in K.4.
48
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-10—6-circuit cable attenuation Frequency
Attenuation
100 MHz
Less than 2.3 dB
200 MHz
Less than 3.2 dB
400 MHz
Less than 5.8 dB
4.2.4.3 Signal pairs velocity of propagation The differential velocity of propagation (V) of the signal pairs shall be measured in the frequency domain using the procedure described in K.5: VTPA ≤ 5.05 ns/meter VTPB ≤ 5.05 ns/meter NOTE—The common mode velocity of propagation of the signal pairs should be the same or less than the differential velocity of propagation. No test procedure is described for this in K.5 since this will be the case for all but the most exotic cable constructions:
VTPACM ≤ 5.05 ns/meter VTPBCM ≤ 5.05 ns/meter
4.2.4.4 Signal pairs relative propagation skew The difference between the differential mode propagation delay of the two signal twisted pairs shall be measured in the frequency domain using the procedure described in K.5.2: S ≤ 400 ps
4.2.4.5 Power pair characteristic impedance The differential mode characteristic impedance of the power pair shall be measured by TDR at less than 100 ps rise time using the procedure described in K.7: ZVG ≤ 65 (differential)
4.2.4.6 Power pair dc resistance The dc resistance of the power wires is measured with a milliohmeter capable of “four-wire” resistance measurements using the procedure described in K.7.3: RV ≤ 0.333 Ω RG ≤ 0.333 Ω
Copyright © 2008 IEEE. All rights reserved.
49
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.2.4.7 Crosstalk The TPA-TPB and signal-power crosstalk shall be measured in the frequency domain using a network analyzer in the frequency range of 1 MHz to 500 MHz using the procedure described in K.8: X ≤ –26 dB
4.3 4-circuit Alpha connectors and cables 4.3.1 Connectors In typical applications, computer, consumer electronic, or peripheral equipment boxes shall present one or more connector sockets for attachment to other boxes via cables. The detachable ends of the cable shall be terminated with connector plugs. Subclause 4.2.1 specifies connectors that have six contacts; this subclause specifies alternative connectors that have four contacts. All dimensions, tolerances, and descriptions of features that affect the intermateability of the 4-pin shielded connector plugs and sockets are specified within this subclause. Features of connector plugs and sockets that do not affect intermateability are not specified and may vary at the option of the manufacturer. Connector features that are not directly controlled within this subclause shall be indirectly controlled by performance requirements in 4.3.3 and 4.3.4. The holes and patterns (footprint) for the mounting of some of the possible versions of connectors to the PCB are recommended in 4.3.1.8.
4.3.1.1 Connector plug The mating features of the connector plug are specified in Figure 4-11 and Figure 4-12. The features assure the intermateability of the plug with the 4-pin sockets specified in 4.3.1. Figure 4-11 and Figure 4-12 describe a plug intended to be used when only detent retention with the socket is required.
4.3.1.2 Connector plug terminations The termination of the stranded wire to the plug contacts may be varied to suit the manufacturing process needs of the cable assembler. For reference, the following methods are listed:
50
—
Crimp
—
Insulation displacement (IDC)
—
Insulation piercing
—
Welding and soldering
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Note: [1] When mated with Socket, dimension (5.6) to be deflected to get Contact Pressure.
NOTE—Reprinted with permission from 1394 Trade Association TB0002 [B3].
Figure 4-11—4-circuit plug body
NOTE—Reprinted with permission from 1394 Trade Association TB0002 [B3].
Figure 4-12—4-circuit plug section details
Copyright © 2008 IEEE. All rights reserved.
51
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.3.1.3 Connector socket The mating features of the connector socket are described in Figure 4-13 through Figure 4-15. They assure the intermateability of the socket with the 4-pin plugs specified in 4.3.1.
NOTE—Reprinted with permission from 1394 Trade Association TB0002 [B3].
Figure 4-13—4-circuit connector socket interface The contacts are attached to the signals using the guidance in Table 4-11.
Table 4-11—4-circuit connector socket signal assignment Contact number
Signal name
1
TPB*
2
TPB
3
TPA*
4
TPA
Shell
VG
Comment Strobe on receive, data on transmit (differential pair)
Data on receive, strobe on transmit (differential pair)
Necessary for ground reference
Figure 4-14 describes the relationship of the contacts and the shell. This includes the wiping portion of the contact and shell detent. Figure 4-15 shows the mated cross-section of the plug and socket contacts.
52
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTE—Reprinted with permission from 1394 Trade Association TB0002 [B3].
Figure 4-14—4-circuit socket cross-section A–A
NOTE—Reprinted with permission from 1394 Trade Association TB0002 [B3].
Figure 4-15—Cross-section of 4-circuit plug and socket contacts
Copyright © 2008 IEEE. All rights reserved.
53
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
When mounted on a printed circuit board, the socket should be at a fixed height, as illustrated by Figure 4-16.
Figure 4-16—4-circuit socket position when mounted on a PCB
4.3.1.4 Contact finish on plug and socket contacts It is necessary to standardize the electroplated finish on the contacts to assure the compatibility of plugs and sockets from different sources. The following standardized electroplatings are compatible, and one shall be used on contacts. a)
0.76 μm (30 μin), minimum, gold, over 1.27 μm (50 μin), minimum, nickel
b)
0.05 μm (2 μin), minimum, gold, over 0.76 μm (30 μin), minimum, palladium, over 1.27 μm (50 μin), minimum, nickel
c)
0.05 μm (2 μin), minimum, gold, over 0.76 μm (30 μin), minimum, palladium-nickel alloy (80% Pd–20% Ni), over 1.27 μm (50 μin), minimum, nickel
NOTES 1—Selective plating on contacts is acceptable. In that case, the above electroplating shall cover the complete area of contact, including the contact wipe area. 2—Either a copper or palladium strike is acceptable under the nickel electroplate.
4.3.1.5 Termination finish on plug and contact socket terminals It is acceptable to use an electroplate of tin-lead with a minimum thickness of 3.04 μm (120 μin) over 1.27 μm (50 μin), minimum, nickel. A copper strike is acceptable under the nickel.
4.3.1.6 Shell finish on plugs and sockets It is necessary to standardize the plated finish on the shells to ensure compatibility of products from different sources. Both shells shall be electroplated with a minimum of 3.03 μm (120 μin) of tin or tin alloy over a suitable barrier underplate.
4.3.1.7 Connector durability The requirements of different end-use applications call for connectors that can be mated and unmated a different number of times, without degrading performance beyond acceptable limits. Accordingly, this standard specifies minimum performance criteria of 1000 mating cycles.
54
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
4.3.1.8 PCB footprints The dimensional specifications recommended for the footprint of a surface-mounted (SMT) PCB socket are illustrated by Figure 4-17.
Figure 4-17—Flat SMT PCB 4-circuit socket footprint The dimensional specifications recommended for the footprint of a through-hole PCB socket are illustrated by Figure 4-18.
Figure 4-18—Flat through-hole mount PCB 4-circuit socket footprint
Copyright © 2008 IEEE. All rights reserved.
55
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.3.2 Cables All cables and cable assemblies shall meet assembly criteria and test performance in the normative portions of this standard and should be tested in accordance with the procedures described in Annex K.
4.3.2.1 Cable material Linear cable material typically consists of two twisted-pair conductors. The two twisted pairs carry the balanced differential data signals. Figure 4-19 illustrates a reference design adequate for a 4.5 m cable. Subclause 4.3.4 describes the performance requirements for the cable.
NOTE—This construction is illustrated for reference only; other constructions are acceptable as long as the performance criteria are met.
Figure 4-19—4-circuit cable material construction example (for reference only)
4.3.2.2 Cable assemblies Cable assemblies consist of two plug connectors, either the 6-pin connector or the 4-pin connector, joined by a length of cable material. Subclause 4.3.3 describes the performance requirements for the cable assemblies. The suggested maximum length is 4.5 m. This is to assure that a maximally configured cable environment does not exceed the length over which the end-to-end signal propagation delay would exceed the allowed time. Longer cable lengths are possible if special consideration is given to the actual serial bus system topology to be used, as discussed in greater detail in Annex M. Both cable configurations, 6-pin connector to 4-pin connector and 4-pin connector to 4-pin connector, are illustrated in Figure 4-20 and Figure 4-21. The connector pins are terminated as shown by Figure 4-20 and Figure 4-21. The two signal pairs “cross” in the cable to effect a transmit-to-receive interconnection.
56
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 4-20—Cable assembly and schematic (6-pin to 4-pin connector)
Figure 4-21—Cable assembly and schematic (4-pin connectors)
4.3.3 Connector and cable assembly performance criteria To verify the performance requirements, performance testing is specified according to the recommendations, test sequences, and test procedures of ANSI/EIA 364-C-94; Table 1 in that standard shows operating class definitions for different end-use applications. For the serial bus, the test specifications follow the recommendations for environmental class 1.3, which is defined as follows: “No air conditioning or humidity control with normal heating and ventilation.” The equipment operating environmental conditions shown for class 1.3 in Table 2 are —
Temperature: + l5 °C to + 85 °C
—
Humidity: 95% maximum
Class 1.3 is further described as operating in a “harsh environmental” state, but with no marine atmosphere.
Copyright © 2008 IEEE. All rights reserved.
57
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Accordingly, the performance groupings, sequences within each group, and the test procedures shall follow the recommendations of ANSI/EIA 364-C-94, except where the unique requirements of the serial bus connector and cable assembly may call for tests that are not covered in ANSI/EIA 364-C-94, or where the requirements deviate substantially from those in that document. In those cases, test procedures of other recognized authorities or specific procedures described in the annexes are cited. Sockets, plugs, and cable assemblies shall perform to the requirements and pass all the following tests in the groups and sequences shown. Testing may be done as follows: a)
Plug and socket only. In this case, for those performance groups that require it, the plugs may be assembled to the cable, to provide a cable assembly, by the connector manufacturer or by a cable assembly supplier.
b)
Cable assembly (with a plug on each end) and socket. In this case, a single supplier may do performance testing for both elements or a connector supplier may team up with a cable assembly supplier to do performance testing as a team.
c)
Cable assembly only (with a plug on each end). In this case, the cable assembly supplier should use a plug connector source that has successfully passed performance testing, according to this standard.
d)
Plug only or socket only. In this case, the other half shall be procured from a source that has successfully passed performance testing, according to this standard. For those performance groups that require it, the plugs may be assembled to the cable, to provide a cable assembly, by the connector manufacturer or by a cable assembly supplier.
NOTES 1—All performance testing is to be done with cable material that conforms to this standard. In order to test to these performance groups, ANSI/EIA 364-C-94 requires that the test results specify the cable construction used. 2—All resistance values shown in the performance groups in 4.3.3.1 through 4.3.3.7 are for connectors only, including their terminations to the wire and/or PC board, but excluding the resistance of the wire. Resistance measurements shall be performed in an environment of temperature, pressure, and humidity specified by ANSI/EIA 364-C-94. 3—The number of units to be tested is a recommended minimum; the actual sample size is to be determined by requirements of users. This is not a qualification program.
4.3.3.1 Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration Number of samples [2] Sockets, not assembled to PCB used for Phase 1, A1, and A2 (one each) [2] Sockets, assembled to PCB [2] Plugs, not assembled to cable used for Phase 1, A1, and A2 (one each) [2] Cable assemblies with a plug assembled to one end, 25.4 cm long See Table 4-12 for testing of performance group A. Connectors are to be mounted on a fixture that simulates typical usage. The socket shall be mounted to a panel that is permanently affixed to the fixture. The mounting means shall include typical accessories such as an insulating member to prevent grounding of the shell to the panel and a PCB in accordance with the pattern shown in Figure 4-17 or Figure 4-18 for the socket being tested. The PCB shall also be permanently affixed to the fixture. The plug shall be mated with the socket, and the other end of the cable shall be permanently clamped to the fixture. Refer to Figure 4-10 for details.
58
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-12—Performance group A Measurements to be performed
Test Phase Title
ID No.
A1
Visual and dimensional inspection
ANSI/EIA 364-18A-84
A2
Plating thickness measurement
A3
Severity or conditions
Requirements for performance level
Title
ID No.
Unmated connectors
Dimensional inspection
Per Figure 4-11 through Figure 4-15
No defects that would impair normal operations. No deviation from dimensional tolerances.
—
—
—
—
Record thickness; see 4.3.1.4
None
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated pair.
A4
Vibration
ANSI/EIA 364-28C-97
Condition II (See note)
Continuity
ANSI/EIA 364-46A-98
No discontinuity at 1 μs or longer. (Each contact.)
A5
None
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
A6
Mechanical shock (specified pulse)
ANSI/EIA 364-27B-96
Condition G (See note)
Continuity
ANSI/EIA 364-46A-98
No discontinuity at 1 μs or longer. (Each contact.)
A7
None
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
4.3.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress Number of samples [0] Sockets, not assembled to PCB [2] Sockets, assembled to PCB [0] Plugs, not assembled to cable [2] Cable assemblies with a plug assembled to one end, 25.4 cm long See Table 4-13 for testing of performance group B.
Copyright © 2008 IEEE. All rights reserved.
59
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-13—Performance group B Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
B1
None
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
B2
Thermal shock
ANSI/EIA 364-32B-92
Condition I 10 cycles (mated)
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
B3
Humidity
ANSI/EIA 364-31A-83
Condition A (96 hours) Method III (cycling) nonenergized Omit steps 7a and 7b (mated)
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
4.3.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress Number of samples [2] Sockets, not assembled to PCB [0] Sockets, assembled to PCB [2] Plugs, not assembled to cable used for Phase 1, A1, and A2 (one) [0] Cable assemblies with a plug assembled to one end, 2 m long See Table 4-14 for testing of performance group C.
Table 4-14—Performance group C Measurements to be performed
Test Phase Title
ID No.
C1
Withstanding voltage
ANSI/EIA 364-20B-99
C2
Thermal shock
ANSI/EIA 364-32B-92
60
Severity or conditions
Requirements for performance level
Title
ID No.
Test voltage 100 V dc ± 10 V dc Method C (unmated and unmounted)
Withstanding voltage
ANSI/EIA 364-20B-99
No flashover. No sparkover. No excess leakage. No breakdown.
Condition I 10 cycles (unmated)
Withstanding voltage (same conditions as C1)
ANSI/EIA 364-20B-99
No flashover. No sparkover. No excess leakage. No breakdown.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-14—Performance group C (continued) Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
C3
Insulation resistance
ANSI/EIA 364-21B-96
Test voltage 100 V dc ± 10 V dc (unmated and unmounted)
Insulation resistance
ANSI/EIA 364-21B-96
100 MΩ, minimum, between adjacent contacts and contacts and shell.
C4
Humidity (cyclic)
ANSI/EIA 364-31A-83
Condition A (96 hours) Method III nonenergized Omit steps 7a and 7b
Insulation resistance (same conditions as C3)
ANSI/EIA 364-21B-96
100 MΩ, minimum.
4.3.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure Number of samples [0] Sockets, not assembled to PCB [4] Sockets, assembled to PCB [0] Plugs, not assembled to cable used for Phase 1, A1, and A2 (one) [4] Cable assemblies with a plug assembled to one end, 25.4 cm long See Table 4-15 for testing of performance group D.
Table 4-15—Performance group D Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
D1
None
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
D2
Continuityhousing (shell)
—
See Figure 4-22 for measurement points
Contact resistance, braid to socket shell
ANSI/EIA 364-06A-83
50 mΩ, maximum, initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
Copyright © 2008 IEEE. All rights reserved.
61
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-15—Performance group D (continued) Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
—
—
—
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure 4-22 for measurement points
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
ANSI/EIA 364-65A-98
Class II Exposures: (a) 2 mated pairs; unmated for 1 day (b) 2 mated pairs; mated 10 days
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Durability
ANSI/EIA 364-09C-99
Class II exposures: (a) 2 mated pairs, 5 cycles (b) 2 mated pairs, automatic cycling to 500 cycles, rate 500 cycles/h ± 50 cycles
—
—
—
D8
Mixed flowing gas
ANSI/EIA 364-65A-98
Class II exposures: Expose mated for 10 days
Low-level contact resistance at end of exposure
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
D9
Continuityhousing (shell)
See Figure 4-22 for measurement points
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
D3
Durability
D4
None
D5
Continuityhousing (shell)
D6
Mixed flowing gas
D7
62
ANSI/EIA 364-09C-99
Class II Exposures: (a) 2 mated pairs, 5 cycles (b) 2 mated pairs, automatic cycling to 500 cycles, rate 500 cycles/h ± 50 cycles.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
PWB
Socket
Plug
Cable Wire
I V
X V Note: subtract bulk wire resistance of length "X" from measurement
Wire termination
I
a) contact resistance Socket
PWB
Plug
Cable
V
I V
I
b) shield resistance
Figure 4-22—Shield and contact resistance measuring points
4.3.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress Number of samples [0] Sockets, not assembled to PCB [2] Sockets, assembled to PCB [0] Plugs, not assembled to cable used for Phase 1, A1, and A2 (one) [2] Cable assemblies with a plug assembled to one end, 2 m long See Table 4-16 for testing of performance group E.
Table 4-16—Performance group E Measurements to be performed
Test Phase Title E1
Mating and unmating forces
ID No. ANSI/EIA 364-13B-98
Copyright © 2008 IEEE. All rights reserved.
Severity or conditions
Title
Requirements for performance level
ID No.
Mount socket rigidly; insert receptacle by hand.
Mating only
—
—
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13B-98
Unmating force: 4.9 N minimum 39.0 N maximum.
63
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-16—Performance group E (continued) Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
—
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
See Figure 4-22
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
ANSI/EIA 364-17B-99
Condition 2 (79° C) 96 hours Method A (mated)
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Continuityhousing (shell)
—
—
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
Mating and unmating forces
ANSI/EIA 364-13B-98
Mount socket rigidly; insert plug by hand.
Mating only
—
—
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13B-98
Unmating force: 4.9 N minimum 39.0 N maximum.
E2
None
E3
Continuityhousing (shell)
E4
Temperature life
E5
E6
—
4.3.3.6 Performance group F: Mechanical retention and durability Number of samples [0] Sockets, not assembled to PCB [2] Sockets, assembled to PCB [0] Plugs, not assembled to cable [2] Plugs, assembled to cable, one end only, 25 cm long See Table 4-17 for testing of performance group F.
64
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-17—Performance group F Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
F1
Mating and unmating forces
ANSI/EIA 364-13B-98
Mount socket rigidly; insert plug by hand.
Mating only
—
—
F2
Mating and unmating forces
ANSI/EIA 364-13B-98
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13B-98
Unmating force: 4.9 N minimum 39.0 N maximum.
F3
Durability
ANSI/EIA 364-09C-99
Automatic cycling to 1000 cycles. 500 cycles/h ± 50 cycles.
Unmating only
ANSI/EIA 364-13B-98
Unmating force at end of durability cycles: 4.9 N minimum 39.0 N maximum.
4.3.3.7 Performance group G: General tests Suggested procedures to test miscellaneous but important aspects of the interconnect. Since the tests listed in Table 4-18 may be destructive, separate samples shall be used for each test. The number of samples to be used is listed under the test title.
Table 4-18—Performance group G Measurements to be performed
Test Phase Title G1
Electrostatic Discharge
ID No.
Cable axial pull test
Title
ID No.
IEC 61000-4-2
1–8 kV in 1 kV steps. Use 8 mm ball probe. Test unmated.
Evidence of discharge
—
No evidence of discharge to any of the 4 contacts; discharge to shield is acceptable.
—
Fix plug housing and apply a 49.0 N load for 1 min on cable axis.
Continuity, visual
ANSI/EIA 364-46A-98
No discontinuity on contacts or shield greater than 1 µs under load. No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
[1 plug] [1 socket] G2
Severity or conditions
Requirements for performance level
[2 cable assemblies]
Copyright © 2008 IEEE. All rights reserved.
65
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-18—Performance group G (continued) Measurements to be performed
Test
Requirements for performance level
Phase Title G3
Cable flexing
Severity or conditions
ID No. ANSI/EIA 364-41C-99
[2 cable assemblies]
Condition I, dimension X = 5.5 × cable diameter; 100 cycles in each of two planes (see Figure 4-23).
Nearest endend Nearest of internal of internal cable clamp cable clamp
Title
ID No.
(a) Withstanding voltage
Per C1
Per C1
(b) Insulation resistance
Per C3
Per C3
(c) Continuity
ANSI/EIA 364-46A-98
No discontinuity on contacts or shield greater than 1 µs during flexing.
(d) Visual
—
No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
To cable diameter Tosuit suit cable dia.
Fixed cable Fixedfixture cable holding
holding fixt
45 45 (25.4 mm) rollers (25.4 mm) rollers
X X
203.2 mm 203.2 mmmin. min.
Figure 4-23—Fixture for cable flex test
66
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
4.3.4 Signal propagation performance criteria The test procedures for all parameters listed in this subclause are described in Annex K.
4.3.4.1 Signal impedance The differential mode characteristic impedance of the signal pairs within the cable section shall be measured by TDR at less than 100 ps rise time; the recommended procedure is described in K.3: ZTPA = (110 ± 6) Ω (differential) ZTPB = (110 ± 6) Ω (differential) The common-mode characteristic impedance of the signal pairs within the cable section shall be measured by TDR at less than 100 ps rise time; the recommended procedure is described in K.3: ZTPACM = (33 ± 6) Ω (common mode) ZTPBCM = (33 ± 6) Ω (common mode) The differential mode discrete impedance of the signal pairs within the mated connector section shall be measured by TDR at less than 500 ps rise time; the recommended procedure is described in K.3: ZTPACONN = (110 ± 25) Ω (differential) ZTPBCONN = (110 ± 25) Ω (differential)
4.3.4.2 Signal pairs attenuation A signal pairs attenuation requirement applies only to the two signal pairs, for any given cable assembly. Attenuation is measured using the procedure described in Annex K.4 and shall meet the requirements of Table 4-19.
Table 4-19—4-circuit signal pairs attenuation Frequency
Attenuation
100 MHz
Less than 2.3 dB
200 MHz
Less than 3.2 dB
400 MHz
Less than 5.8 dB
4.3.4.3 Signal pairs propagation delay The differential propagation delay of the signal pairs through the cable shall be measured in the frequency domain; the recommended procedure is described in K.5: VTPA ≤ 5.05 ns/m VTPB ≤ 5.05 ns/m
Copyright © 2008 IEEE. All rights reserved.
67
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The common-mode propagation delay of the signal pairs shall be less than or equal to the differential propagation delay. For typical cable constructions this is correct by design; consequently no test procedure is described for this in K.5. VTPACM ≤ 5.05 ns/m VTPBCM ≤ 5.05 ns/m
4.3.4.4 Signal pairs relative propagation skew The difference between the differential mode propagation delay of the two signal twisted pairs shall be measured in the frequency domain; the recommended procedure is described in K.6.1: S ≤ 400 ps
4.3.4.5 Crosstalk The TPA-TPB and signal-power crosstalk shall be measured in the frequency domain using a network analyzer in the frequency range of 1–75 MHz; the recommended procedures are described in K.8: X ≤ –26 dB
4.4 9-circuit Beta and bilingual connectors and cables This subclause defines a media and connector to support data rates greater than S400. This media and connector are known as the Beta interface. This interface is usable at speeds up to S3200. To enable interoperability with Alpha devices, a keyed version of the Beta connector is defined. This connector allows bilingual ports to be attached to either DS ports or to Beta-only ports. The Beta connector is used to prevent Alpha ports from being attached to Beta-only ports. An interconnect matrix is provided in Table 4-21 and Table 4-22 (in 4.4.2.3). The Beta interface has been designed to meet the small size requirements of consumer electronics devices while meeting the higher speed and power distribution needs of computer and peripheral devices. The 4- and 6-circuit receptacles defined in 4.2 and 4.3 shall not be used on a port that is capable of operating in Beta mode. Only the receptacles defined in this subclause are allowed for use for short-haul copper connections on a Beta-capable port.
4.4.1 9-circuit Beta and bilingual connectors The connectors and cables defined in this subclause are used to interconnect B nodes at distances of up to 4.5 m. This subclause specifies the electrical and physical properties of the Beta and bilingual cables and connectors. Some of the connector attributes that are not directly specified in this subclause are implied by the performance requirements in 4.4.3. Information about the recommended planar mounting footprints of the sockets is found in Figure 4-41 and Figure 4-42 (in 4.4.1.7). Compliance to these footprints is optional, but performance of alternative footprints should be comparable to the footprints shown in this standard. In typical computer applications, consumer electronic or peripheral equipment boxes present one or more sockets for attachment to other boxes via cables. The detachable ends of the cable shall be terminated with plugs. This subclause defines the copper Beta and bilingual cables and their mating PCB socket interfaces.
68
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
All dimensions, tolerances, and descriptions of features that affect the intermateability of the Beta and bilingual plugs and sockets are specified within this subclause. Connector features that are not directly controlled within this subclause are indirectly controlled by the performance requirements in 4.4.3. The mating features of the Beta plug and overmold features are specified in Figure 4-24. The bilingual plug and overmold features are shown in Figure 4-25. The interface, unmated plug cross-section, and detent common to both the Beta and bilingual plugs are found in Figure 4-26, Figure 4-27, and Figure 4-28. Adherence to these details helps ensure mating integrity by multiple manufacturers of these cable plugs. The plug inner shield shall be designed to mate with the detent spring on the socket (shown in Figure 4-34 and Figure 4-36 in 4.4.1.2) before any of the contacts #1 to #9 mate.
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 4-24—Beta plug body with overmold
Copyright © 2008 IEEE. All rights reserved.
69
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Theoretical sharp corner, chamfer profile tolerance excludes radii.
Figure 4-25—Bilingual plug body with overmold
4.4.1.1 Plug cable termination method The termination of the Beta and bilingual cable media’s conductor wires to the plug contacts shall be either solder or welded.
4.4.1.2 Socket The mating features of the Beta socket are described in Figure 4-29 and Figure 4-30. The detail assures the intermateability of the socket and plugs. The mating features of the bilingual socket are described in Figure 4-31 and Figure 4-32. In Figure 4-33 through Figure 4-38, the interface details common to both Beta and bilingual sockets are shown. Figure 4-39 shows mated detent cross-sections common to both Beta and bilingual plugs and sockets. The detent feature details assure the intermateability of the socket and plugs. Materials utilized in the fabrication of the Beta and bilingual sockets shall be capable of withstanding reflow soldering temperatures.
70
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 4-26—Beta and bilingual plug interface: Detail A
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Contact shape is manufacturer’s option.
Figure 4-27—Beta and bilingual plug section Z-Z (unmated)
Copyright © 2008 IEEE. All rights reserved.
71
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-28—Beta and bilingual detent cross-section S-S Contact assignment for either PCB socket is found in Table 4-20.
Table 4-20—Beta and bilingual socket contact assignment Contact number
72
Signal name
Comment
1
TPB*
Twisted Pair B (minus)
2
TPB
Twisted Pair B (plus)
3
TPA*
Twisted Pair A (minus)
4
TPA
Twisted Pair A (plus)
5
TPA (R)
Twisted Pair A (reference ground)
6
VG
Power (ground)
7
SC
Status contact (reserved for future use)
8
VP
Power (voltage)
9
TPB (R)
Twisted Pair B (reference ground)
10
Cable shield ground
Inner shell
11
Cable shield ground
Inner shell
12
Chassis ground
Outer shell
13
Chassis ground
Outer shell
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Solderable standoff feature is an option of the manufacturer. 5—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 4-29—Beta socket body
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Socket detent feature shall retain standard plug shape and contacts in reliable contact position under cable tension up to the minimum retention force. 5—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 4-30—Beta socket outer shell profile
Copyright © 2008 IEEE. All rights reserved.
73
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Solderable standoff feature is an option of the manufacturer.
Figure 4-31—Bilingual socket body
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Theoretical sharp corner, chamfer profile tolerance excludes radii. 5—Socket detent feature shall retain standard plug shape and contacts in reliable contact position under cable tension up to the minimum retention force.
Figure 4-32—Bilingual socket outer shell profile
74
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994.
Figure 4-33—Beta and bilingual socket section X-X
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Contact shape is the manufacturer’s option, but should be a spring member.
Figure 4-34—Beta and bilingual socket section Y-Y
Copyright © 2008 IEEE. All rights reserved.
75
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994.
Figure 4-35—Beta and bilingual socket section V-V
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994.
Figure 4-36—Beta and bilingual socket section Z-Z
76
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994.
Figure 4-37—Beta and bilingual socket section W-W
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Contact shape is manufacturer’s option, but shall be a spring member.
Figure 4-38—Beta and bilingual socket interface
Copyright © 2008 IEEE. All rights reserved.
77
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Socket detent features shall retain standard plug shape and contacts in reliable contact position under cable tension up to the minimum retention force. 5—Detent shape is the manufacturer’s option, but should be a spring member.
Figure 4-39—Beta and bilingual plug and socket detent feature cross-section
When mounted on a PCB, the socket shall be at a fixed height and minimum side-to-side spacing as illustrated by Figure 4-40.
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Minimum mounting interval. 5—Datum -C- of PCB sockets.
Figure 4-40—Socket positions when mounted on a PCB
78
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
4.4.1.3 Mating area finish on plug and socket contacts The electroplated finish on the contacts are standardized to assure the compatibility of plugs and sockets from different sources. The following standardized electroplatings are compatible, and one shall be used on mating contact surfaces: a)
0.76 μm, minimum, gold, over 1.27 μm, minimum, nickel, or
b)
0.05 μm, minimum, gold, over 0.76 μm, minimum, palladium-nickel alloy (80% Pd–20% Ni), over 1.27 μm, minimum, nickel.
NOTES 1—Selective plating on the mating contact surfaces is acceptable. In such cases, the above electroplating shall cover the complete area of contact, including the contact wipe area. 2—A copper strike is acceptable, under the nickel electroplate.
4.4.1.4 Termination area finish on plug and socket contacts An electroplate of tin or tin alloy with a minimum thickness of 3.04 μm over 1.27 μm, minimum, nickel is acceptable for the PCB and cable conductor termination. A copper strike is acceptable under the nickel.
4.4.1.5 Shell finish on plugs and sockets All shells shall be electroplated with a minimum of 3.03 μm of tin or tin alloy over a suitable barrier underplate, such as copper or nickel.
4.4.1.6 Durability The requirements of different end-use applications call for connectors that can be mated and unmated a number of times, without degrading performance beyond acceptable limits. Accordingly, Beta and bilingual connectors shall meet the performance requirements of this subclause after a minimum of 1000 mating cycles.
Copyright © 2008 IEEE. All rights reserved.
79
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.4.1.7 Socket PCB termination footprints and PHY trace routing The dimensional specifications recommended for the footprint of a SMT Beta PCB socket are illustrated in Figure 4-41.
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Datum J - PCB top surface. Datum K - orientation hole closest to pad matrix. Datum L - remaining orientation hole. 5—Minimum mounting interval is 14.5 mm. 6—Phantom outline of Beta socket. 7—Through holes are optional for true flat SMT sockets.
Figure 4-41—Beta PCB socket footprint
80
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The dimensional specifications recommended for the footprint of a SMT bilingual PCB socket are illustrated in Figure 4-42.
NOTES 1—All linear dimensions are in millimeters. 2—Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. 3—Interpret dimensions and tolerances per ANSI Y14.5M-1994. 4—Datum J - PCB top surface. Datum K - orientation hole closest to pad matrix. Datum L - remaining orientation hole. 5—Minimum mounting interval is 14.5 mm. 6—Phantom outline of bilingual socket. 7—Through holes are optional for true flat SMT sockets.
Figure 4-42—Bilingual PCB socket footprint
Copyright © 2008 IEEE. All rights reserved.
81
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-43 illustrates the layout of PCB traces from a Beta or bilingual socket. This information is useful for both PHY IC and PCB layout designers.
Figure 4-43—Beta and bilingual PHY trace routing
4.4.1.8 Plug overmold A simple quarter round radius shall be included for the overmold at the corner adjacent to pin 1 and at the corner adjacent to pin 4 of the plug as shown in Figure 4-24 and Figure 4-25. NOTE—The intent is that the thumb of a right-handed person should be on the flat side of the long axis of the plug, while the index finger should wrap around the radiused side of the long axis of the plug.
4.4.1.9 Socket orientation preference The 1/2/3/4 side of the socket should be on the right hand side of the socket (as viewed from the outside, or user's, point of view) if the socket has the long axis on the vertical plane, while the 1/2/3/4 side of the socket should be down if the socket has the long axis in the horizontal orientation.
4.4.2 Cables All cables and cable assemblies shall meet assembly criteria and test performance found in this subclause.
82
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
4.4.2.1 Reference cable material for Beta-to-Beta cable assemblies Cable material typically consists of two twisted pair conductors and a power pair of conductors. The two twisted pairs carry the balanced differential data signals, and the power pair carries current specified in this subclause. Figure 4-44 and Figure 4-45 illustrate reference designs for either a 4.5 m maximum or 2.0 m maximum length cable. The outer jacket of the cable shall be printed in contrasting color for the 4.5 m and 2.0 m construction. The minimum printing shall be repeated every 0.5 m and contain the following information: a)
A designation indicating the revision of the 1394 standard, for example “1394b-2002” or “1394-2008”
b)
Number of signal pairs/American Wire Gauge (AWG)
c)
Number of power conductors/AWG
For example, the 4.5 m reference construction illustrated in Figure 4-44 could have the cable jacket printing of “1394b 2PR/25AWG 2C/22AWG,” and the 2.0 m reference construction illustrated in Figure 4-45 could have the cable jacket printing of “1394-2008 2PR/30AWG 2C/26AWG.”
Figure 4-44—Example of Beta cable construction—4.5 m maximum (for reference only)
Copyright © 2008 IEEE. All rights reserved.
83
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Power wires: 26 AWG stranded / Ø 0.78 insulation Signal pair shield: metal tape over 2 uninsulated drains, metal inside (2 pairs) Signal twisted pair wires: 30 AWG stranded / Ø 0.8 insulation, twist 60 / meter
Ø 5.0 typ.
- Signal pairs should be closely matched for skew and other factors. - Inner pair shields should not make contact with each other. - Outer shield should be isolated from the inner pair shields
Outer jacket: 0.48 thick insulating jacket
Outer shield: 90-95% braided copper wire over spiral wrap metalized polyester tape with metal to the outside over an insulating tape barrier.
NOTE—This construction is illustrated for reference only; other constructions are acceptable as long as the performance criteria are met.
Figure 4-45—Example of Beta cable construction—2 m maximum (for reference only)
4.4.2.2 Reference cable material for bilingual-to-Alpha cable assemblies Alpha cables are specified in 4.2 and 4.3.
4.4.2.3 Cable assemblies Cable assemblies for connecting Beta and bilingual ports shall consist of one of the three types defined in Table 4-21 and have a suggested maximum length of 4.5 m. The type 2 and type 3 cables are the only permissible methods to connect from the bilingual plug to Alpha plugs. NOTE—It is possible to make Beta cables longer than 4.5 m provided that all the signal propagation criteria given in 4.4.4 are met.
84
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-21—Cable assembly components Cable type
Plug 1
Plug 2
Cable reference
1
Beta
Beta
4.4
2
4-circuit
Bilingual
4.3
3
6-circuit
Bilingual
4.2
Figure 4-46 illustrates keying to prevent the insertion of a bilingual plug into a beta socket. Beta Socket
Beta Plug
Bilingual Plug
Bilingual Socket
Bilingual Plug
Beta Plug
NOTE:
Bilingual plug will not plug into a Beta socket. Beta plug will plug into a Bilingual socket.
Figure 4-46—Interface mating chart
This new classification of cables specified in this subclause operates at a range of speeds based on the performance criteria set by the connectors and cables. Table 4-22 shows the various interfaces.
Table 4-22—Interface speed matrix Socket or plug
S100-S400 (Alpha)
6-circuit
X
4-circuit
X
Bilingual
X
Beta
Copyright © 2008 IEEE. All rights reserved.
S400β − S3200β (Beta)
X X
85
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
All three types of cable assembly constructions are shown in Figure 4-47 through Figure 4-49 along with cable assembly wiring charts in Table 4-23 through Table 4-25.
plug 2
2 1
6
4 3
8 9
6
7
7 2 1
5
5
4 3
8 9
plug 1
NOTE—Connectors are viewed as looking at the front plug face.
Figure 4-47—Type 1 cable assembly and schematic (Beta plug to Beta plug)
Table 4-23—Type 1 cable assembly Plug 1: Beta plug contact number
Signal name at plug 1 end: cable reference
Plug 2: Beta plug contact number
1
TPB* (Twisted Pair B minus)
3
2
TPB (Twisted Pair B plus)
4
3
TPA* (Twisted Pair A minus)
1
4
TPA (Twisted Pair A plus)
2
5
TPA (R) (Twisted Pair A ground reference)
9
6
VG (power ground)
6
a
7 (no connection)
SC (status contact)
7 (no connection)
8
VP (power voltage)
8
9
TPB (R) (Twisted Pair B ground reference)
5
Plug shield
Cable shield ground
Plug shield
a
Reserved for future use; no plug-to-plug connection exists for status contact through the cable.
86
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
plug 2
3
5
2
4
6
7
1
5 6
4 3
plug 1
8 9
2 1
NOTE—Connectors are viewed as looking at the front plug face.
Figure 4-48—Type 2 cable assembly and schematic (6-circuit plug to bilingual plug)
Table 4-24—Type 2 cable assembly Plug 1: 6-circuit plug contact number
Plug 2: bilingual plug contact number
Signal name at plug 2 end: cable reference
5
TPB* (Twisted Pair B minus)
1
6
TPB (Twisted Pair B plus)
2
3
TPA* (Twisted Pair A minus)
3
4
TPA (Twisted Pair A plus)
4
2
TPA (R) (Twisted Pair A ground reference)
5
2
VG (power ground)
6
No connection
SC (status contact)a
7 (no connection)
1
VP (power voltage)
8
2
TPB (R) (Twisted Pair B ground reference)
9
Plug shield
Cable shield ground
Plug shield
aReserved
for future use; no plug-to-plug connection exists for status contact through the cable.
Copyright © 2008 IEEE. All rights reserved.
87
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
plug 2
5 6
4 3 7
8 9
2 1
plug 1
4 3 2 1 NOTE—Connectors are viewed as looking at the front plug face.
Figure 4-49—Type 3 cable assembly and schematic (4-circuit plug to bilingual plug) Table 4-25—Type 3 cable assembly Plug 1: 4-circuit plug contact number
Plug 2: bilingual plug contact number
Signal name at plug 2 end: cable reference
3
TPB* (Twisted Pair B minus)
1
4
TPB (Twisted Pair B plus)
2
1
TPA* (Twisted Pair A minus)
3
2
TPA (Twisted Pair A plus)
4
Plug shield
TPA (R) (Twisted Pair A ground reference)
5
No connection
VG (power ground)
6
No connection
SC (status contact)a
7 (no connection)
No connection
VP (power voltage)
8
Plug shield
TPB (R) (Twisted Pair B ground reference)
9
No connection
Cable shield ground
Plug shield
a
Reserved for future use; no plug-to-plug connection exists for status contact through the cable.
4.4.3 Connector and cable assembly performance criteria To verify the performance requirements, performance testing is specified according to the recommendations, test sequences, and test procedures of ANSI/EIA 364-C-94. Table 1 in that standard shows operating class definitions for different end-use applications. For this standard, the test specifications follow the recommendations for environmental class 1.3, which is defined as follows: “No air conditioning or humidity control with normal heating and ventilation.” The equipment operating environmental conditions shown for class 1.3 in Table 2 in ANSI/EIA 364-C-94 are —
Temperature: +l5 °C to +85 °C
—
Humidity: 95% maximum
Class 1.3 is further described as operating in a “harsh environmental” state, but with no marine atmosphere.
88
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Accordingly, the performance groupings, sequences within each group, and the test procedures shall follow the recommendations of ANSI/EIA 364-C-94, except where the unique requirements of the Beta and bilingual connector and cable assembly may call for tests that are not covered in ANSI/EIA 364-C-94 or where the requirements deviate substantially from the requirements in that document. In those cases, test procedures of other recognized authorities or specific procedures described in the annexes of this standard will be cited. Sockets, plugs, and cable assemblies shall perform to the requirements and pass all the tests in the groups and sequences shown in 4.4.3.1 through 4.4.3.7. Commonality of the connector interface, either Beta or bilingual, results in qualification of the other configuration. All performance testing is to be done with cable material that conforms to this standard. To test to these performance groups, ANSI/EIA 364-C-94 tests require that the cable construction used be specified. All resistance values shown in the performance groups in 4.4.3.1 through 4.4.3.7 are for connectors only, including their terminations to the wire and/or PCB, but excluding the resistance of the wire. Resistance measurements shall be performed in an environment of temperature, pressure, and humidity specified by ANSI/EIA 364-C-94. The number of units to be tested is a recommended minimum; the actual sample size is to be determined by the requirements of users.
4.4.3.1 Performance group A: Basic mechanical dimensional conformance and electrical functionality when subjected to mechanical shock and vibration Number of samples: [2] Sockets, unassembled to PCB used for Phase 1, A1 and A2 (one each) [2] Sockets, assembled to PCB [2] Plugs, unassembled to cable used for Phase 1, A1 and A2 (one each) [2] Cable assemblies with a plug assembled to one end, 25 cm ± 1 cm long See Table 4-26 for testing of performance group A.
Table 4-26—Performance group A Measurements to be performed
Test Phase Title
ID No.
A1
Visual and dimensional inspection
ANSI/EIA 364-18A-84
A2
Plating thickness measurement
A3
None
Copyright © 2008 IEEE. All rights reserved.
Severity or conditions Unmated connectors
Requirements for performance level
Title
ID No.
Dimensional inspection
Figure 4-11 through Figure 4-40
No defects that would impair normal operations. No deviation from dimensional tolerances.
4.3.1.4, 4.3.1.5, and 4.3.1.6
Record thickness.
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated pair.
Low-level contact resistance
89
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-26—Performance group A (continued) Measurements to be performed
Test Phase Title A4
Vibration
A5
None
A6
Mechanical shock (specified pulse)
A7
None
ID No. ANSI/EIA 364-28D-99
ANSI/EIA 364-27B-96
Severity or conditions Condition Ia
Condition Aa or Condition E
Title
Requirements for performance level
ID No.
Continuity
ANSI/EIA 364-46A-98
No discontinuity at 1 μs or longer (each contact).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Continuity
ANSI/EIA 364-46A-98
No discontinuity at 1 μs or longer (each contact).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
aConnectors are to be mounted on
a fixture that simulates typical usage. The socket shall be mounted to a panel that is permanently affixed to the fixture. A PCB shall be in accord with the pattern shown in Figure 4-17 or Figure 4-42 for the socket being tested. The PCB shall also be permanently affixed to the fixture.
The plug shall be mated with the socket, and the other end of the cable shall be permanently clamped to the fixture. Refer to Figure 4-9 for details.
4.4.3.2 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Cable assemblies with a plug assembled to one end, 25 cm ±1 cm long See Table 4-27 for testing of performance group B.
Table 4-27—Performance group B Measurements to be performed
Test Phase Title B1
None
B2
Thermal shock
90
ID No.
ANSI/EIA 364-32B-92
Severity or conditions
10 cycles (mated) Test Condition I
Title
Requirements for performance level
ID No.
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-27—Performance group B (continued) Measurements to be performed
Test Phase Title B3
Humidity (Steady state)
ID No. ANSI/EIA 364-31A-83
Severity or conditions Condition A (96 h) Method II nonenergized
Title Low-level contact resistance
Requirements for performance level
ID No. ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
4.4.3.3 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress Number of samples: [2] Sockets, unassembled to PCB [0] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Cable assemblies with a plug assembled to one end, 25 cm ± 1cm long See Table 4-28 for testing of performance group C.
Table 4-28—Performance group C Measurements to be performed
Test Phase Title
ID No.
C1
Withstanding voltage
ANSI/EIA 364-20A-83
C2
Thermal shock
C3
C4
Severity or conditions
Requirements for performance level
Title
ID No.
Test voltage 100 V dc ± 10 V dc Method C (unmated and unmounted)
Withstanding voltage
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
ANSI/EIA 364-32B-92
10 cycles (unmated) Test Condition I
Withstanding voltage (same conditions as Phase C1)
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
Insulation resistance
ANSI/EIA 364-21B-96
Test voltage 100 V dc ± 10 V dc (unmated and unmounted)
Insulation resistance
ANSI/EIA 364-21B-96
100 ΜΩ minimum, between adjacent contacts and contacts and shell.
Humidity (cyclic)
ANSI/EIA 364-31A-83
Condition A (96 h.) Method III nonenergized Omit steps 7a and 7b
Insulation resistance (same conditions as Phase C3)
ANSI/EIA 364-21B-96
100 ΜΩ minimum.
Copyright © 2008 IEEE. All rights reserved.
91
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.4.3.4 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure Number of samples: [0] Sockets, unassembled to PCB [4] Sockets, assembled to PCB [0] Plugs, unassembled to cable [4] Cable assemblies with a plug assembled to one end, 25 cm ± 1 cm long See Table 4-15 for testing of performance group D.
Table 4-29—Performance group D Measurements to be performed
Test Phase Title D1
None
D2
Continuityhousing (shell)
D3
Durability
D4
None
D5
Continuityhousing (shell)
D6
Mixed flowing gas
92
ID No.
Severity or conditions
ANSI/EIA 364-65A-97
ID No.
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
Contact resistance, braid to socket shell
ANSI/EIA 364-06A-83
50 mΩ maximum initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure 4-50 for measurement points
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell. 100 mA, 5V dc open circuit maximum.
Class II Exposures: (a) 2 mated pairs, unmated for 1 day (b) 2 mated pairs, mated 10 days
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure 4-50 for measurement points ANSI/EIA 364-09B-91
Title
Requirements for performance level
(a) 2 mated pairs, 5 cycles (b) 2 mated pairs, automatic cycling to 500 cycles, rate 500 cycles/h ± 50 cycles.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 4-29—Performance group D (continued) Measurements to be performed
Test
Requirements for performance level
Phase Title
Severity or conditions
ID No.
Title
ID No.
D7
Durability
ANSI/EIA 364-09B-91
(a) 2 mated pairs, 5 cycles (b) 2 mated pairs, automatic cycling to 500 cycles, rate 500 cycles/h ± 50 cycles
D8
Mixed flowing gas
ANSI/EIA 364-65A-97
Class II Exposures: Expose mated for 10 days
Low-level contact resistance at end of exposure
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
D9
Continuityhousing (shell)
See Figure 4-50 for measurement points
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell. 100 mA, 5 V dc open circuit maximum.
PWB
Socket
Plug
Cable Wire
I V
X V Note: subtract bulk wire resistance of length "X" from measurement
Wire termination
I
a) contact resistance Socket
PWB
Plug
V
Cable
I I
V
b) shield resistance [inner shield contacts #10 and #11 to external cable shield]
Figure 4-50—Shield and contact resistance measurement points
Copyright © 2008 IEEE. All rights reserved.
93
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.4.3.5 Performance group E: Contact resistance and unmating force when subjected to temperature life stress Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Cable assemblies with a plug assembled to one end, 25 cm ± 1 cm long See Table 4-30 for testing of performance group E.
Table 4-30—Performance group E Measurements to be performed
Test Phase Title E1
Mating and unmating forces
E2
None
E3
Continuityhousing (shell)
E4
Temperature life
E5
Continuityhousing (shell)
E6
Mating and unmating forces
ID No. ANSI/EIA 364-13A-83
ANSI/EIA 364-17B-99
ANSI/EIA 364-13A-83
Severity or conditions
Title
ID No.
Mount socket rigidly. Insert receptacle by hand.
Mating only
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13A-83
Unmating force: 10.0 N minimum 39.0 N maximum.
Low-level contact resistance
ANSI/EIA 364-23C-06
50 mΩ maximum initial per mated contact.
See Figure 4-50
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum initial from braid to socket shell. 100 mA, 5 V dc open circuit maximum.
Condition 2 (79° C) 96 hours Method A (mated).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Contact resistance
ANSI/EIA 364-06A-83
50 mΩ maximum change from initial from braid to socket shell.
ANSI/EIA 364-13A-83
Unmating force: 10.0 N minimum 39.0 N maximum.
Mount socket rigidly. Insert plug by hand.
Mating only
Unmating only
94
Requirements for performance level
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
4.4.3.6 Performance group F: Mechanical retention and durability Number of samples: [0] Sockets, unassembled to PCB [2] Sockets, assembled to PCB [0] Plugs, unassembled to cable [2] Plugs, assembled to cable, one end only, 25 cm ± 1 cm long See Table 4-31 for testing of performance group F.
Table 4-31—Performance group F Measurements to be performed
Test Phase Title
ID No.
Severity or conditions
Title
Requirements for performance level
ID No.
F1
Mating and unmating forces
ANSI/EIA 364-13A-83
Mount socket rigidly. Insert plug by hand.
Mating only
F2
Mating and unmating forces
ANSI/EIA 364-13A-83
Auto rate: 25 mm/min.
Unmating only
ANSI/EIA 364-13A-83
Unmating force: 10.0 N minimum 39.0 N maximum
F3
Durability
ANSI/EIA 364-09C-99
Automatic cycling to 1000 cycles. 500 cycles/h ± 50 cycles.
Unmating only
ANSI/EIA 364-13A-83
Unmating force at end of durability cycles: 10.0 N minimum 39.0 N maximum
4.4.3.7 Performance group G: General tests Suggested procedures to test miscellaneous but important aspects of the interconnect. Because the tests listed in Table 4-32 may be destructive, separate samples should be used for each test. The number of samples to be used is listed under the test title.
Table 4-32—Performance group G Measurements to be performed
Test Phase
G1
Title
ID No.
Electrostatic Discharge
IEC 610004-2
[1 plug] [1 socket]
Copyright © 2008 IEEE. All rights reserved.
Severity or conditions 1 kV to 8 kV in 1 kV steps. Use 8 mm ball probe. Test unmated.
Title Evidence of discharge
Requirements for performance level
ID No. No evidence of discharge to any of the nine contacts; discharge to shield is acceptable.
95
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-32—Performance group G (continued) Measurements to be performed
Test Phase
G2
Title
ID No.
Cable axial pull test.
ANSI/EIA 364-38A-85
Fix plug housing and apply a 50.0 N load for 1 min on cable axis.
Continuity, visual
ANSI/EIA 364-46A-98
No discontinuity on contacts or shield greater than 1 μs under load. No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
ANSI/EIA 364-41B-89
Condition I, dimension X=5.5 × cable diameter; 100 cycles in each of two planes. See Figure 4-51.
(a) Withstanding voltage
Phase C1
Per Phase C1.
(b) Insulation resistance
Phase C3
Per Phase C3.
(c) Continuity
ANSI/EIA 364-46A-98
No discontinuity on contacts or shield greater than 1 μs during flexing.
[2 plugs]
G3
Severity or conditions
Cable flexing [2 plugs]
Title
Requirements for performance level
ID No.
(d) Visual
No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
Figure 4-51—Fixture for cable flex test
96
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
4.4.4 Signal propagation performance criteria The test procedures for all parameters listed in this subclause are described in Annex K and in ANSI/ EIA 364-102-98, and ANSI/EIA 364-103-99 with the exceptions in test hardware described in 4.4.4.1. Any test condition exceptions are noted in association with each parametric requirement.
4.4.4.1 Test hardware The test fixturing described in this subclause should be used in place of fixtures described in Annex K.
4.4.4.1.1 Connector-only differential test fixture The socket footprint is placed on a 0.25 mm thick FR4 substrate to emulate board interface loading (see Figure 4-52). The FR4 relative permittivity should be 4.3 ± 0.2.
Layer
Material
Top
17.0 µm Cu
Bottom
17.0 µm Cu
Figure 4-52—PCB stack-up for connector-only differential test fixture The recommended socket footprint is used for signal and signal ground reference pads while other functions are brought through the recommended resistive and capacitive components to ground (see Figure 4-53). A through calibration duplicate (CAL) of all footprint features is provided for time domain calibration. Additional short and open frequency domain test features are also provided.
Figure 4-53—PCB top layer for connector-only differential test fixture Interface to test equipment takes place through Gigatest Labs microprobe ports and x-y translation probe station (or equivalent). Bottom side probe ports are minimized to prevent skew. Ground layer shown in Figure 4-54 is an inverse image with light regions representing copper.
Copyright © 2008 IEEE. All rights reserved.
97
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 4-54—PCB ground layer for connector-only differential test fixture 4.4.4.1.2 Cable assembly differential test fixture The socket footprint is placed on a 0.25 mm thick FR4 substrate using guarded microstrip construction and porting to test equipment through SMA connectors (see Figure 4-55). The FR4 relative permittivity should be 4.3 ± 0.2. Layer
Material
Top
17.0 µm Cu
GND 1
34.0 µm Cu
GND 2
34.0 µm Cu
GND 3
17.0 µm Cu
Figure 4-55—PCB stack-up for cable assembly differential test fixture The recommended socket footprint is used with signal positions routed to SMA connectors through 55 Ω ± 5% traces (see Figure 4-56). All functions other than signal and signal ground reference are brought through the recommended RC components to ground. A through calibration duplicate (CAL) of all footprint features is provided for time domain calibration. This includes a mirror-imaged far-end pattern to duplicate the hardware burden of a complete link.
Figure 4-56—PCB top layer for cable assembly differential test fixture
98
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Layers GND1, GND2, and GND3 are identical. Pinning vias should be installed regularly about signal traces to tie all ground planes together. Ground layer shown in Figure 4-57 is an inverse image with light regions representing copper.
Figure 4-57—PCB ground layer for cable assembly differential test fixture
4.4.4.1.3 Test fixture schematic The component values shown in Figure 4-58 are intended to provide a connector operating environment comparable to the environment found in actual applications. This recommended test board fixture applies to both socket and cable assemblies.
Figure 4-58—Test fixture schematic
Copyright © 2008 IEEE. All rights reserved.
99
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.4.4.1.4 Pad position to PHY function map The PCB pad positions shown in the test fixture schematic in Figure 4-58 would be routed to the functions shown in Table 4-33 in an actual application.
Table 4-33—Text fixture pad position to PHY function map Pad position
PHY function
1
TPB*
2
TPB
9
TPB (R)
8
VP
7
SC
6
VG
3
TPA*
4
TPA
5
TBA (R)
10, 11
Inner shield
12, 13
Outer shield
4.4.4.2 Signal impedance This subclause applies to type 1 cable assemblies only. The differential-mode characteristic impedance of the signal pairs within the cable section shall be measured by TDR with the cable assembly differential test fixture at less than 80 ps rise time in order to establish adequate measurement resolution. The recommended procedure is described in K.3. Measured impedance shall be ZTPA = (110 ± 6) Ω (differential) ZTPB = (110 ± 6) Ω (differential) The common-mode characteristic impedance of the signal pairs within the cable section shall be measured by TDR with the cable assembly differential test fixture at less than 80 ps rise time to establish adequate measurement resolution. The recommended procedure is described in K.3. Measured impedance shall be ZTPACM = (33 ± 6) Ω (common-mode) ZTPBCM = (33 ± 6) Ω (common-mode) The differential mode discrete impedance of the signal pairs within the mated connector shall meet the exception window mask defined in Figure 4-59 and shall be measured by time domain reflectrometry with the Cable Assembly Differential Test Fixture at an 80 ps rise time. The recommended procedure is described in K.3.2 with the following exception in the test condition: evaluate differential impedance over a 300 ps
100
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
exception window to be compliant with the mask defined in Figure 4-59. The insertion plane datum is located at the midpoint of the SMT pad at the junction of the receptacle tails to the PCB (see Figure 4-50: the insertion plane is coincident with measurement point 'V' on the receptacle side).
Differential impedance
NOTE—In making time domain measurements multiply all specification values by 2 before comparison with TDR reported measurements to account for the round trip.
125 Ω 120 Ω 116 Ω 110 Ω 104 Ω 100 Ω 95 Ω
(PCB impedance)
250 ps
125 ps Insertion plane (0 ps) -25 ps Time relative to insertion plane
275 ps
(Cable impedance)
NOTE—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 4-59—Connector impedance exception window mask 4.4.4.3 Signal pairs attenuation This subclause applies to type 1 cable assemblies only. A signal pairs attenuation requirement applies only to the two signal pairs for any given cable assembly. Attenuation is measured using the procedure described in K.4. A connector insertion loss value is allowed to de-embed cable-only attenuation from measured connector and cable assemblies. The connector allowance listed in Table 4-34 is for two mated connectors, one at the assembly input and one at the output. Connector and cable assemblies shall be swept through the frequencies listed in Table 4-34 with the stop frequency at 4000 MHz. Curves shall be smooth with no anomalous behavior, and signal pair attenuation shall be less than the worst-case curve described by Equation (1) and illustrated in Figure 4-60. insertion loss (dB) < 3 * f + 4.5 * sqrt(f) ; 0.1 GHz < f (GHz) < 4 GHz
(1)
Table 4-34—Signal pairs attenuation
Frequency (MHz)
Cable attenuation recommendation
Connector allowance recommendation
250
≤ 2.30 dB
400
Total allowance Minimum requirement
Maximum recommendation
1.00 dB
N/A
≤ 3.30 dB
≤ 2.90 dB
1.20 dB
N/A
≤ 4.10 dB
500
≤ 3.50 dB
1.35 dB
N/A
≤ 4.85 dB
800
≤ 4.60 dB
1.60 dB
N/A
≤ 6.20 dB
Copyright © 2008 IEEE. All rights reserved.
101
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 4-34—Signal pairs attenuation (continued)
Frequency (MHz)
Cable attenuation recommendation
Connector allowance recommendation
1000
≤ 5.50 dB
1500
Total allowance Minimum requirement
Maximum recommendation
2.00 dB
2.50 dB
≤ 7.50 dB
≤ 7.60 dB
2.40 dB
2.75 dB
≤ 10.0 dB
2000
≤ 9.50 dB
2.90 dB
3.0 dB
≤ 12.4dB
3000
≤ 13.30 dB
3.50 dB
4.0 dB
≤ 16.8dB
4000
≤ 16.60 dB
4.40 dB
5.0 dB
≤ 21.0dB
6000
≤ 23.00 dB
6.00 dB
5.0 dB (recommended)
≤ 29.0dB
NOTE—Reprinted with permission from 1394 Trade Association TB2007010 [B6].
Figure 4-60—S3200 cable insertion loss example 4.4.4.4 Signal pairs velocity of propagation This subclause applies to type 1 cable assemblies only. The maximum differential propagation delay of the signal pairs through the cable shall be measured in the frequency domain. The recommended procedure is described in K.5. Measured propagation velocity shall be VTPA ≤ 5.05 ns/m VTPB ≤ 5.05 ns/m The common-mode propagation delay of the signal pairs shall be less than or equal to the differential propagation delay. For typical cable constructions, this delay is correct by design; consequently no test
102
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
procedure is described for this measurement in K.5. Expected propagation velocity for common-mode signals is VTPACM ≤ 5.05 ns/m VTPBCM ≤ 5.05 ns/m
4.4.4.5 Signal pairs intrapair propagation skew This subclause applies to type 1 cable assemblies only. Intra-pair skew at dc does not provide a sound basis for measuring the contribution to jitter from skew-type effects at high frequencies. Indeed, the contribution to jitter is often considerably less than might be implied from a dc skew measurement. S-parameters provide an effective method to completely define the characteristics of a cable, including attenuation, return loss, crosstalk, and skew. All parameters that affect the performance of a cable, including conversions between differential and common mode. The net impact of skew-type effects is the introduction of jitter due to differential-to-common mode conversion, which may be derived directly from S-parameter measurements across a suitable frequency range by taking the difference between SDD21 and SCD21. Differential-to-common mode conversion shall be less than shown in Equation (2). 10 * log (sin( pi * 0.1/(BASE_RATE*32*10/8/1000) * f)) where 0.1 f
(2)
represents a bound of 0.1UI jitter and is the frequency in GHz.
This shall be measured from 199.608 MHz to 3.145 GHz (0.05 of bit rate to 0.8 of bit rate). The resulting curve is shown in Figure 4-61.
NOTE—Reprinted with permission from 1394 Trade Association TB2007010 [B6]
Figure 4-61—S3200 cable SCD21-SDD21 There is no requirement to meet a dc inter-pair skew parameter.
Copyright © 2008 IEEE. All rights reserved.
103
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
4.4.4.6 Crosstalk This subclause applies to type 1 cable assemblies only.
4.4.4.6.1 Connector The TPA-TPB signal-to-signal crosstalk shall be measured within the mated connector section in the time domain using the connector-only differential test fixture and a differential TDT at 80 ps (10% to 90%) to emulate operation of the mated connector at S3200. All transmit and receive ports are sourced and terminated respectively with 50 Ω loads. The measured connector NEXT (near end crosstalk) shall be XNEXT, XFEXT ≤ 3%
4.4.4.6.2 Cable assembly The TPA-TPB signal-to-signal crosstalk shall be measured within a 4.5 m cable assembly in the time domain using the cable assembly differential test fixture and a differential TDT at 160 ps (10% to 90%) to emulate cable assembly at S1600. All transmit and receive ports are sourced and terminated respectively with 50 Ω loads. The measured NEXT for the cable assembly shall be XNEXT, XFEXT ≤ 5%
4.4.4.7 Power The power pair conductor within a type 1 cable assembly shall be capable of operating at 30 V dc maximum and maintaining 1.5 A maximum operation continuously.
104
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
5. Backplane PHY specification The backplane environment PHY provides the interface from a physical device to the backplane media. It provides arbitration services to permit a node to gain access to the bus, and it performs the signal translations required to drive the bus and receive information from the bus. Unlike the specification for the cable PHY, the backplane PHY specification does not include a description of connectors or media. Such documentation is assumed to be part of a host backplane specification or to be included in the requirements for the application environment. The term “application environment” refers to the physical environment of the bus, the nodes, and the system that contains them. This environment may be a standardized host backplane (e.g., a Futurebus+ profile) that provides the signal requirements, a detailed description of the transceivers, the mechanical arrangement of the modules, and the temperature range over which operation is guaranteed. The backplane PHY shares some commonality with the cable PHY. Common functions include: bus state determination, bus access protocols, encoding and decoding functions, and synchronization of received data to a local clock.
5.1 Backplane PHY services PHY layer services are provided at the interface between the PHY layer and higher layers; specifically, the link layer and the node controller, as illustrated in Table 5-1. The method by which these services are communicated between the layers is not defined by this standard. PHY layer services may perform actions specified by the higher layer. PHY layer services may also communicate parameters that may or may not be associated with an action.
Table 5-1—Summary of backplane PHY layer services Layer communicated with
Purpose of service
Backplane PHY control request
From the node controller
Configure the backplane PHY layer
Backplane PHY control confirmation
To the node controller
Confirm backplane PHY control request
Backplane PHY event indication
To the node controller
Alert node controller to events detected in the backplane PHY layer
Backplane PHY arbitration request
From the link layer
Cause the backplane PHY layer to request control of the bus
Backplane PHY arbitration confirmation
To the link layer
Confirm backplane PHY arbitration request
Backplane PHY clock indication
To the link layer
Indicate when it is time for the link layer to make a backplane PHY data request
Backplane PHY data request
From the link layer
Cause the backplane PHY to send one clocked data symbol or to start or end a data packet
Backplane PHY data indication
To the link layer
Indicate the reception of one clocked data symbol or a bus status change
Service
Copyright © 2008 IEEE. All rights reserved.
105
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The method by which these services are communicated between the layers is not defined in this standard. PHY layer services may perform actions specified by the higher layer. PHY layer services may also communicate parameters that may or may not be associated with an action.
5.1.1 Backplane PHY bus management services for the management layer These services are used by the node controller component of the SBM layer to control the bus level actions of the PHY layer. The PHY layer uses these services to communicate changes of state within the PHY layer or on the bus.
5.1.1.1 PHY control request (PH_CONTROL.request) The node controller uses this service to request the PHY layer to perform specific actions and to specify PHY layer parameters. It may also be used to request status about the PHY layer. The PHY layer shall service the request immediately upon receipt by the PHY layer. This service is confirmed. The following actions shall be provided by this service: a)
Bus Reset. The PHY layer shall reset the bus and initialize itself.
b)
Disable Transmit. The PHY layer shall set all bus outputs to a high impedance state. This bus output state shall be maintained until the node controller requests an Enable Transmit action. Link layer service actions that would require a change in bus output state shall not be performed.
c)
Enable Transmit. The PHY layer shall allow link layer service actions to change the state of the bus outputs.
d)
Present Status. The PHY layer shall return status to the node controller. The PHY layer shall return status via the PHY control confirmation service.
NOTE—This Present Status service is expected to be used to communicate new parameters without causing any other action.
The following parameters are communicated via this service: —
Physical_ID. This 6-bit parameter is used as the arbitration number during the arbitration process. The value of this parameter is unique for each node on the bus. Refer to 5.4.2.1.
—
Priority. This 4-bit parameter is used during the urgent arbitration process. Refer to 5.4.2.1.
NOTE—These parameters may be changed remotely by Transaction Layer “write” operations to CSRs within the node controller. Some register locations within the PHY, however, may not have corresponding CSRs or unit architectures. Such registers may be accessed locally via the LINK-PHY interface, as described in Clause 17 If an application environment requires remote access to such registers, then the application environment is expected to specify an architecture for doing this.
5.1.1.2 PHY control confirmation (PH_CONTROL.confirmation) The PHY layer uses this service to confirm the results of a PHY control request service. The PHY layer shall communicate this service to the node controller upon completion of a PHY control request. There are no actions provided by this service. When the corresponding control request is “Present Status,” the following parameters are communicated via this service: —
Physical_ID. As described in 5.4.2.1.
—
Priority. As described in 5.4.2.1.
—
Initiated_Reset. The PHY control request action was completed successfully. See 5.5.1.
106
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
5.1.1.3 PHY event indication (PH_EVENT.indication) The PHY layer uses this service to indicate PHY-level events to the node controller. There are no actions provided by this service. No response is defined for this indication. The following parameters are communicated via this service: —
PHY Event. This parameter shall contain the current state of the PHY layer. The following values are defined for this parameter: —
BUS_RESET_START. The PHY layer has detected a bus reset. See 5.5.1.
—
BUS_RESET_COMPLETE. The PHY layer has detected a subaction gap after the bus reset process has started. See 5.5.1.
5.1.2 PHY layer arbitration services for the link layer These services are used to communicate arbitration requests between the PHY layer and the link layer. See 5.4.1.
5.1.2.1 PHY arbitration request (PH_ARB.request) The link layer uses this service to request the PHY layer to start arbitration for the bus. The PHY layer shall arbitrate for the bus using the method specified by the service parameters. The PHY layer shall service the request immediately upon receipt from the link layer. This service shall be confirmed when the arbitration process completes. If a node loses arbitration (PH_ARB.conf of LOST), it shall reissue the arbitration request. The following parameters are communicated via this service: a)
b)
Arbitration Class. This parameter shall contain the method of arbitration performed by the PHY arbitration request. The method of arbitration shall be one of the following: 1)
FAIR. The PHY layer shall start arbitration at the next subaction gap if its arbitration_enable flag is set; otherwise, it shall start arbitration at the next arbitration reset gap. The link layer uses this arbitration class to send a fair asynchronous packet. The lowest priority (all zeros) is reserved for this arbitration class. Refer to 5.4.1.2.
2)
URGENT. The PHY layer shall begin arbitration at the next subaction gap if its urgent_count is not zero. Otherwise, it shall start arbitration at the next arbitration reset gap. The link layer uses this arbitration class to send an urgent asynchronous packet. The four-bit subparameter “pri” is used to set the priority level for the arbitration process, with the exception that the lowest priority and the highest priority are reserved (and cannot be used for this arbitration class; refer to 5.4.2.1). This allows urgent requests to have priority access to the bus, but the number of requests that can be made each fairness interval is limited (see 5.4.1.3).
3)
CYCLE_MASTER. The PHY layer shall begin arbitration at the next subaction gap. The link layer uses this arbitration class to send a cycle start packet. The highest priority (all ones) is reserved for this arbitration class (see 5.4.1.4).
4)
ISOCHRONOUS. The PHY layer shall begin arbitration as soon as an acknowledge gap is detected. The link layer uses this arbitration class to send an isochronous packet (see 5.4.1.5).
5)
IMMEDIATE. The PHY layer shall communicate a PHY arbitration confirmation with an Arbitration Request Status of WON to the link layer as soon as an acknowledge gap is detected. The link layer uses this arbitration class to send an acknowledge packet (see 5.4.1.6).
Pri. This parameter shall contain the priority associated with the Urgent Access Method. This parameter shall be ignored if the arbitration class is ISOCHRONOUS or IMMEDIATE.
NOTE—The Pri parameter could be used to distinguish FAIR and CYCLE_MASTER requests from URGENT requests.
Copyright © 2008 IEEE. All rights reserved.
107
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
5.1.2.2 PHY arbitration confirmation (PH_ARB.confirmation) The PHY layer uses this service to confirm the results of a PHY arbitration request service. The PHY layer shall communicate this service to the link layer upon completion of a PHY arbitration request. There are no actions provided by this service. The following parameter is communicated via this service: —
Arbitration Request Status. This parameter shall contain the result of a PHY arbitration request action. The following values are defined for this parameter: —
WON. The PHY arbitration request action was completed successfully. The PHY layer shall begin communicating PHY clock indications to the link layer. This confirmation is returned after the minimum length data_prefix (as described in 5.4.2.1) has been transmitted.
—
LOST. The PHY arbitration request action was not successful.
5.1.3 PHY layer data services for the link layer These services are used to communicate data symbols and control information between the PHY layer and the link layer.
5.1.3.1 PHY clock indication (PH_CLOCK.indication) The PHY layer uses this service to indicate to the link layer that a data symbol transmission is about to occur. The link layer shall respond to this indication with a PHY data request. There are no actions provided by this service. No parameters are communicated via this service. This indication occurs once for each bit cell time (see 5.2.3). The PHY layer shall begin communicating this indication to the link layer after it has communicated a PHY arbitration confirmation with an Arbitration Request Status of WON. The PHY layer shall stop communicating these indications to the link layer after the link layer communicates a PHY data request with data of DATA_END.
5.1.3.2 PHY data request (PH_DATA.request) The link layer uses this service to control the transmission of clocked data symbols by the PHY layer: The link layer shall communicate one PHY data request for each PHY clock indication. The PHY layer shall service the request immediately upon receipt by the PHY layer. The following parameter is communicated via this service: —
Data. This parameter shall contain the symbol to be transmitted on the bus. See 5.2.2.1 for a definition of the logic states associated with the symbols. The following values are defined for this parameter: —
DATA_ONE. A symbol representing a data bit of one shall be transmitted on the bus.
—
DATA_ZERO. A symbol representing a data bit of zero shall be transmitted on the bus.
—
DATA_PREFIX. The PHY layer shall stop sending clocked data bits and leave the bus in the data_prefix state using the algorithm described in 5.4.2.1. This symbol shall be transmitted between acknowledge and response packets during concatenated subactions.
—
DATA_END. The link layer shall stop communicating PHY data requests to the PHY layer. The PHY layer shall stop communicating PHY clock indications to the link layer. The PHY layer shall set bus outputs to the data_end state using the algorithm described in 5.4.2.1.
NOTE—A DATA_PREFIX can also be initiated by the PHY layer. This occurs once a PHY arbitration request has been completed successfully and until transmission of the packet begins, and once an acknowledge gap is detected and until transmission of the acknowledge packet begins.
108
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Once the link layer starts sending a DATA_PREFIX or a DATA_END, it shall continue sending it for at least four arbitration clock times (approximately 81.38 ns) before sending any other data symbols (see 5.4.2.1). This minimum value allows sufficient time for all nodes to detect that such a symbol has been transmitted. The duration of a DATA_PREFIX shall not exceed 160 arbitration clock times (approximately 3255.2 ns), and the duration of a DATA_END shall not exceed 16 arbitration clock times (approximately 325.52 ns). These maximum values ensure that a transaction will be completed within a limited amount of time. Once the link layer starts sending a data bit (DATA_ONE or DATA_ZERO), it shall continue to send a whole packet unless the MAX_BUS_OCCUPANCY period is exceeded (see 5.4.2.1). If data requests continue to be received after this time, the PHY shall release the bus using the signal transitions for a DATA_END. In any event, the total number of continuous data bits shall be even.
5.1.3.3 PHY data indication (PH_DATA.indication) The PHY layer uses this service to indicate to the link layer changes in the state of the PHY layer. These changes can include received data and other bus events. The PHY layer shall communicate this indication to the link layer for each data bit received. If the node is not receiving data bits, the PHY layer shall use this indication to communicate events needed by the link layer. No response is defined for this indication. The following parameter is communicated via this service: —
Data. This parameter shall contain the information decoded by the PHY that is needed by the link layer. The following values are defined for this parameter: —
DATA_START. The start of a packet has been detected on the bus.
—
DATA_ONE. A data bit of one has been received on the bus.
—
DATA_ZERO. A data bit of zero has been received on the bus.
—
DATA_PREFIX. A node has control of the bus and is preparing to transmit a packet.
—
DATA_END. The end of a packet has been detected on the bus, and the transmitting node is releasing control.
—
ARBITRATION_RESET_GAP. An arbitration reset gap event has been detected on the bus. This event is needed for link layers that implement the retry A/B protocol.
—
SUBACTION_GAP. A subaction gap event has been detected on the bus.
5.2 Backplane physical connection specification Within the backplane environment, the serial bus is implemented with a pair of signals: Strb and Data. The topology is a simple pair of bused signals, as shown in Figure 5-1. The backplane environment can be implemented with a number of different interface technologies. These include, but are not limited to: TTL for industry-standard transistor-transistor logic, BTL for backplane transceiver logic as defined by IEEE Std 1194.1-1991, and ECL for emitter-coupled logic. In addition to the requirements specified by the application environment, the physical media of the serial bus shall meet the requirements defined for media attachment, media signal interface, and media signal timing. Timing requirements shall be met over the ranges specified in the application environment. These include temperature ranges, voltage ranges, and manufacturing tolerances.
Copyright © 2008 IEEE. All rights reserved.
109
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 5-1—Backplane topology 5.2.1 Media attachment 5.2.1.1 Distribution of nodes The number of modules on a backplane shall not exceed the maximum number specified for the application environment (i.e., the host backplane). The number of nodes on the backplane shall not exceed 63, although there is no restriction on the distribution of these nodes throughout the modules on the bus. If more than one node occupies a module, they shall share the same transceivers. NOTE—Media signal timing is determined assuming that there is only one pair of serial bus transceivers per module on a given bus. If modules supported more than one pair of transceivers, the additional capacitive loading on the bus would result in higher bus propagation delays. Arbitration and data transmission, however, require that the bus propagation delay be within a certain fixed value.
As long as the arbitration and bus synchronization timing requirements are met (see 5.2.4.2), it is unnecessary to specify the number of modules on the backplane, the pitch of the modules, or the load that each module presents to the backplane. Nonetheless, these characteristics may still be defined within the specification (or profile) for a particular application environment. All nodes shall have unique numbers or node addresses. Refer to 5.4.2.1.
5.2.1.2 Fault detection and isolation It is recommended that modules be designed to support fault detection and that single points of failure between the serial bus and the host backplane bus be kept to a minimum. Within a module, it is recommended that the serial bus transceiver circuitry be packaged separately from the parallel backplane
110
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
circuitry. Within the backplane chassis, it is recommended that termination impedances and voltage supplies be packaged separately where possible. A serial bus backplane shall be capable of operation with modules unpowered or removed. A disabled or unpowered module shall not affect the operation of the bus.
5.2.1.3 Live insertion Modules may support live insertion, minimizing glitches that might occur upon insertion of a board into an active backplane. The implementation of such insertion shall in no way introduce incompatibilities, under normal operating conditions, between interface circuits supporting live insertion and interface circuits that do not. Depending upon the application environment, modules implementing a serial bus may be required to support live insertion.
5.2.2 Media signal interface The backplane media signal interface consists of two single-ended signal interfaces, one for Data and one for Strb. If the serial bus is intended to accompany a standardized parallel bus, it is recommended that the media signal interface of the serial bus be similar to this bus. It is the intention of this standard that the transceivers, terminations, and other physical parameters be the same as those required for the control lines of the host bus (e.g., Futurebus+ profile characteristics or VMEbus electrical specifications). In this case, the specification for the host bus should be referenced for a description of the media signal interface. If there is no host bus or the host bus does not adequately address the physical requirements for the serial bus, then the choice of interface technology is left to the implementor. Care should be taken with the engineering of the backplane to ensure proper performance of the bus. Requirements for bus synchronization and propagation delay (see 5.2.4.2) shall be met to ensure that nodes are able to arbitrate properly. Attention should be given to backplane and transceiver skew characteristics to ensure proper operation of the DS encoding described in 5.3.1. Attention should also be given to signal transition times to minimize noise coupling. This standard specifies parameters for the use of certain technologies (i.e., TTL, BTL, and ECL), but it does not prohibit the use of other technologies. It is not appropriate for this standard to specify a particular technology for a serial bus application.
5.2.2.1 Definition of logic states Drivers shall assert the bus to indicate a “1” logic state or release the bus to indicate a “0” logic state. To assert the bus, a driver sinks current. To release the bus, drivers are tri-stated or turned off, allowing the bus signal to be pulled to the termination voltage of the bus. NOTE—This typically results in a logical inversion of signals on TTL and BTL buses. Signals on ECL buses typically are not inverted.
All drivers shall operate in a “wired-or” or “open-collector” mode during arbitration. Drivers may operate in a “totem pole” mode during data packet and acknowledge transfers. In this mode, a driver may “drive” the bus into its released state in order to decrease the rise time of the bus signal (referred to as a “rescinding release” with TTL technology).
Copyright © 2008 IEEE. All rights reserved.
111
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
5.2.2.2 Bit rates Data transmission and reception shall occur at 24.576 Mbit/s (±100 ppm) for TTL, and 49.152 Mbit/s (±100 ppm) for BTL and ECL. Regardless of the interface technology, arbitration occurs at the same rate (refer to 5.2.4.3).
5.2.2.3 Transition times The transition times of the transceivers shall comply with the values indicated within the media signal timing (Table 5-2, Table 5-3, and Table 5-6). The minimum detectable pulse width of receivers shall be less than the edge separation specified in Table 5-3.
5.2.2.4 Noise rejection Receivers may have noise filters that reject pulses. Filters should reject pulses that are 3 ns or less for TTL and 1.5 ns or less for BTL, measured at the center of the receiver input threshold.
5.2.3 Media signal timing 5.2.3.1 Backplane transmit data timing The backplane bus signals, as they appear from the output of the transmitters and onto the backplane media, shall be within the constraints outlined in Figure 5-2 and Table 5-2. Different data rates are supported for the different backplane technologies. Rise and fall times for the bus signals are measured from 10% to 90%. Slew rates are specified to ensure minimum high-frequency noise coupling during signal transitions. Edge separation is the minimum required time between any two consecutive transitions of the bus signals, whether they be transitions on the same signal or transitions on the two separate signals. Edges are measured at the center of the receiver input threshold. A minimum edge separation is required to ensure proper operation of the DS bit level encoding mechanism.
Figure 5-2—Backplane transmit data timing
112
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 5-2—Backplane transmit data timing TTL
BTL
ECL
Data rate
S25
S50
S50
t1
Bit cell period
Approximately 40.690 ns (1/24.576 Mbit/s ± 100 ppm)
Approximately 20.345 ns (1/49.152 Mbit/s ± 100 ppm)
Approximately 20.345 ns (1/49.152 Mbit/s ± 100 ppm)
t2
Rise time
1.2 ns min 3 ns max (from 1.0 to 2.0 Va)
5 ns max
2 ns min 5 ns max
t3
Fall time
1.2 ns min 3 ns max (from 1.0 to 2.0 Va)
5 ns max
2 ns min 5 ns max
Slew rate
t4
0.5 V/ns max (from 1.3 to 1.8 Vb)
Tx edge separation
aMeasured with a 25 Ω ± bMeasured with a 16.5 Ω
33 ns min
15 ns min
15 ns min
0.25 Ω load terminated to 1.5 V ± 0.015 V. load to 2.1 V.
5.2.3.2 Backplane receive data timing The receiver typically uses the transitions on the incoming bus signals Data_Rx and Strb_Rx to derive a clock at the code bit frequency that extracts the nonreturn to zero (NRZ) signal on Data_Rx. This clock may be derived by performing an exclusive-OR of Data_Rx and Strb_Rx. The bus signals, as they appear from the backplane media and into the receivers, shall be within the constraints outlined by Figure 5-3 and Table 5-3. The minimum required edge separation is reduced to allow for backplane and receiver skew.
Figure 5-3—Backplane receive data timing
Copyright © 2008 IEEE. All rights reserved.
113
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 5-3—Backplane receive data timing TTL
BTL
ECL
Data rate
S25
S50
S50
t1
Bit cell period
Approximately 40.690 ns (1/24.576 Mbit/s ± 100 ppm)
Approximately 20.345 ns (1/49.152 Mbit/s ± 100 ppm)
Approximately 20.345 ns (1/49.152 Mbit/s ± 100 ppm)
t2
Rise time
1.2 ns min 3 ns max (from 1.0 to 2.0 Va)
5 ns max
2 ns min 5 ns max
t3
Fall time
1.2 ns min 3 ns max (from 1.0 to 2.0 Va)
5 ns max
2 ns min 5 ns max
Slew rate t4
0.5 V/ns max (from 1.3 to 1.8 Vb)
Rx edge separation
aMeasured with a 25 Ω ± bMeasured with a 16.5 Ω
26 ns min
9 ns min
9 ns min
0.25 Ω load terminated to 1.5 V ± 0.015 V. load to 2.1 V.
5.2.3.3 Backplane and transceiver skew The skew introduced between Data_Rx and Strb_Rx by the serial bus backplane and transceiver packages shall be no greater than the values mentioned in Table 5-4. This table gives the maximum allowable skew for each technology. Conformance to these requirements is necessary to ensure Tx and Rx edge separations. Calculations for edge separation and skew margin are contained in Annex D.
Table 5-4—Maximum transceiver package and bus skew TTL (in ns)
BTL (in ns)
ECL (in ns)
Tx package skew
5
3
3
Rx package skew
5
3
3
Backplane skew
7
6
6
5.2.4 Backplane PHY timing Correct operation of the backplane PHY is dependent upon a number of timing requirements. Unlike the cable PHY specification (which defines a number of PHY timing constants, see 9.2.6), the backplane PHY specification contains timing requirements but does not define them as constants. These requirements are indicated in Table 5-5. NOTE—The cable PHY specification depends upon the use of C code (using C++ syntax) to describe certain operations. Consequently, it is necessary to define timing “constants” that can be referenced by the code. The backplane PHY specification does not use C code descriptions. Consequently, it is not necessary to label timing requirements as constants. Nonetheless, many of the timing requirements that exist within the cable environment also exist within the backplane environment. Although similar timing requirements exist, they may have different values associated with them. The cable PHY specification should be referenced for values that are referenced in other clauses of this standard, but do not appear in the backplane PHY specification (in particular, values such as NOMINAL_CYCLE_TIME are defined in Table 9-18).
114
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 5-5—Backplane PHY timing requirements Timing requirement
Cross-reference
arbitration clock rate
5.2.4.1
node synchronization
5.2.4.2
bus propagation
5.2.4.2
arbitration bit timing
5.2.4.3
BUS_RESET time
5.3.3
BUS_IDLE time
5.3.3
DATA_PREFIX time
5.3.3
DATA_END time
5.3.3
gap timing
5.3.3
MAX_BUS_OCCUPANCY
5.4.2.1
ACK_RESPONSE_TIME
5.4.2.2
NOMINAL_CYCLE_TIME
9.2.6
5.2.4.1 Arbitration clock rate The arbitration clock rate is used to define a number of timing requirements within the backplane PHY. It is 49.152 MHz ± 100 ppm, regardless of the backplane interface technology. Note that this is not necessarily equal to the data bit rate (e.g., for TTL backplanes, the data bit rate is 24.576 Mbit/s ± 100 ppm).
5.2.4.2 Bus synchronization and propagation delay To ensure proper operation of the arbitration mechanism, all nodes participating in arbitration shall be synchronized to within a specified time period. This requirement allows all nodes to arbitrate at approximately the same time. To achieve synchronization, nodes preparing to arbitrate shall sample the bus until an idle condition is detected. The bus becomes idle once four arbitration clock times (approximately 81.38 ns) have occurred without Data_Rx or Strb_Rx being asserted. A node waiting to arbitrate for the bus shall detect an idle bus within 43.345 ns of the idle condition occurring at the receiver inputs. This time assumes a maximum propagation delay through the receiver (8 ns), a maximum input delay and setup time for the decision logic (15 ns), and a maximum synchronization delay of one arbitration clock period (approximately 20.345 ns). If Strb has already been asserted by another node beginning to arbitrate, all other nodes shall detect that the bus has been asserted within 43.345 ns of the arrival of the asserted signal at their receiver inputs. Once a node that is waiting to arbitrate detects that the appropriate gap has occurred (see 5.3.3), it shall assert Strb_Tx within 43.3455.3.3 ns. This time assumes a maximum output delay for the decision logic (15 ns), a maximum propagation delay through the driver (8 ns), and one state machine clock period (approximately 20.345 ns).
Copyright © 2008 IEEE. All rights reserved.
115
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
In order to guarantee proper arbitration timing, it is necessary to specify a maximum bus propagation delay. The maximum time required for a signal to propagate from one end of the backplane serial bus to the other end (a one-way propagation delay) shall be 18 ns or less.
5.2.4.3 Arbitration bit timing A node gains access to the serial bus by using the arbitration process. This is done in response to a PH_ARB.request from the link layer. To arbitrate for the bus, a node samples Strb_Rx and Data_Rx to determine if the bus is active. If the bus is inactive for a subaction gap or an arbitration reset gap (for an asynchronous transfer) or an acknowledge gap (for an isochronous transfer) the node can begin the arbitration process. It asserts Strb_Tx to indicate the beginning of the arbitration process. The assertion of Strb_Tx also ensures that long strings of “0” arbitration bits are not interpreted as gaps between packets. At the same time that Strb_Tx is asserted, the node begins to transmit its arbitration sequence (see 5.4.2.1) on Data_Tx. The MSBs are transmitted first (see 1.5.3). Each arbitration bit in the sequence has a duration of 16 arbitration clock times (approximately 325.6 ns). If the arbitration bit to be transmitted is a “1,” the node asserts Data_Tx. If the arbitration bit to be transmitted is a “0,” the node releases the Data_Tx, waits 10 arbitration clock times (approximately 203.4 ns), and then samples Data_Rx. If the bus is asserted at this time, the node has lost the arbitration contest. It sends a PH_ARB.confirmation(LOST) to the link layer, and then drops out of the arbitration process and wait for the next appropriate gap to compete for the bus. Regardless of whether arbitration is won or lost, the node shall not cause a transition on Strb or Data (i.e., release or assert the bus) until six more arbitration clock times have passed. This ensures that all participants in the arbitration process have had a chance to sample that arbitration bit in the arbitration sequence. An arbitrating node continues to transmit its arbitration sequence until it loses arbitration to a higher priority node or it successfully completes its arbitration sequence. If a PHY layer has successfully transmitted each of its 10 arbitration bits and still holds the bus, it sends a PH_ARB.confirmation(WON) to the link layer. The PHY layer also initiates the transmission of a PH_DATA.request(DATA_PREFIX) on the bus (using the transitions in 5.4.2.1) for a minimum amount of time before sending the first PH_CLOCK.indication to the link layer. The PHY layer continues to assert PH_DATA.request(DATA_PREFIX) on the bus until the first PH_DATA.request is received from the link layer. The backplane bus signals, as they appear from the output of the transmitters as well as on the inputs of the receivers, shall be within the constraints outlined in Figure 5-4 and Table 5-6. The arbitration bit period is the same regardless of the backplane interface technology. The arbitration bit period (t1) is divided into the sample time (t4) and hold time (t6). The sample time allows enough time for the bus to settle after arbitrating nodes have placed an arbitration bit on the bus. The hold time enables all nodes on the bus to sample the arbitration bit before transitions or glitches can occur on the bus. Rise and fall times for the bus signals are measured from 10% to 90%. Slew rates, if specified, ensure minimum high-frequency noise coupling during signal transitions.
116
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 5-4—Arbitration bit timing
Table 5-6—Arbitration bit timing TTL
ECL
Data rate
S25
S50
S50
t1
Arbitration bit period
16 arbitration clock times (approximately 325.6 ns)
16 arbitration clock times (approximately 325.6 ns)
16 arbitration clock times (approximately 325.6 ns)
t2
Rise time
4 ns min 30 ns max
5 ns max
2 ns min 5 ns max
t3
Fall time
4 ns min 10 ns max
5 ns max
2 ns min 5 ns max
Slew rate
a
BTL
0.5 V/ns (from 1.3 to 1.8 V)a
t4
Sample time
10 arbitration clock times (approximately 203.4 ns)
10 arbitration clock times (approximately 203.4 ns)
10 arbitration clock times (approximately 203.4 ns)
t5
Setup time
5 ns min
5 ns min
5 ns min
t6
Hold time
6 arbitration clock times (approximately 122.0 ns)
6 arbitration clock times (approximately 122.0 ns)
6 arbitration clock times (approximately 122.0 ns)
Measured with a 16.5 Ω load to 2.1 V.
More information on arbitration bit timing is contained in Annex D. Refer to 5.3.4 for a description of the arbitration sequence.
Copyright © 2008 IEEE. All rights reserved.
117
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
5.3 Backplane PHY facilities 5.3.1 Coding Peer PHY entities on the bus communicate via NRZ data. The NRZ data are transmitted and received as Data and is accompanied by a strobe signal, Strb. This strobe signal changes state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on either Data or Strb. A clock that transitions every bit period can be extracted by performing an exclusive OR of Data_Rx and Strb_Rx, as is shown in Figure 5-5.
Figure 5-5—DS coding The primary rationale for use of this transmission code is to improve the transmission characteristics of information to be transferred across the serial bus. In particular, the code ensures that transitions occurring on Data_Rx and Strb_Rx are approximately one bit period apart. This results in an increase in skew tolerance that could not be obtained with a clocked NRZ format. The procedure for encoding data during transmission of a packet is described in 5.4.2.1, and decoding during reception of a packet is described in 5.4.2.2.
5.3.2 Backplane PHY signals Backplane PHYs can send the following signals: —
BUS_RESET: Both Data_Tx and Strb_Tx are asserted for at least 352 arbitration clock times (approximately 7161.4 ns), and at most 384 arbitration clock times (approximately 7812.48 ns). This signal is sent in response to a PH_CONTROL.request(BUS_RESET) from the link layer (see 5.1.1.1).
—
ARBITRATE: An arbitrating node asserts Strb_Tx while transmitting the arbitration sequence on Data_Tx. Arbitration bit timing is described in 5.2.4.3. Arbitration occurs in response to a PH_ARB. request from the link layer (see 5.1.2.1).
—
PACKET: A node transfers a request or a response packet by transmitting NRZ Data on Data_Tx and a strobe signal on Strb_Tx. This strobe signal changes state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on either Data_Tx or Strb_Tx. This bit level encoding method is described in 5.3.1. Data bits occur in response to a PH_DATA.request (DATA_ONE or DATA_ZERO) from the link layer (see 5.1.3.2).
118
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
—
DATA_PREFIX: Before it transmits a packet, a node can hold the bus by asserting Data_Tx and deasserting (or driving into the unasserted state) Strb_Tx for at least four arbitration clock times (approximately 81.38 ns), and at most 160 arbitration clock times (approximately 3255.2 ns). The signal transitions required for this are defined in 5.4.2.1. This signal occurs in response to a PH_DATA.request(DATA_PREFIX) from the link layer (see 5.1.3.2). This signal can also be initiated by the PHY layer after arbitration is successfully completed (see 5.2.4.3).
—
DATA_END: After it transmits a packet, a node signals the release of the bus by asserting Strb_Tx and deasserting (or driving into the unasserted state) Data_Tx for at least four arbitration clock times (approximately 81.38 ns), and at most 16 arbitration clock times (approximately 325.52 ns). The signal transitions required for this are defined in 5.4.2.1. This signal occurs in response to a PH_DATA.request(DATA_END) from the link layer (see 5.1.3.2).
Backplane PHYs can receive the following signals: —
BUS_RESET: Both Data_Rx and Strb_Rx are asserted for more than 320 arbitration clock times (approximately 6510.4 ns). The duration of the reset signal distinguishes it from a sequence of ones transmitted during arbitration.
—
BUS_IDLE: Both Data_Rx and Strb_Rx are unasserted for at least four arbitration clock times (approximately 81.4 ns). The amount of time that the bus is unasserted (idle) distinguishes an acknowledge gap, a subaction gap, and an arbitration reset gap.
—
ARBITRATE: Strb_Rx is asserted as the arbitration sequence is received on Data_Rx. Arbitration bit timing is described in 5.2.4.3.
—
PACKET: NRZ Data are received on Data_Rx and is accompanied by a strobe signal on Strb_Rx. This strobe signal changes state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on either Data_Rx or Strb_Rx. This bit level encoding method is described in 5.3.1. Each bit in the packet results in a PH_DATA.indication(DATA_ONE or DATA_ZERO) to the link layer (see 5.1.3.3).
—
DATA_PREFIX: Data_Rx is asserted and Strb_Rx is unasserted for at least four arbitration clock times. This indicates that another node is holding the bus before transmitting a packet. The receipt of this signal results in a PH_DATA.indication(DATA_PREFIX) to the link layer (see 5.1.3.3).
—
DATA_END: Strb_Rx is asserted and Data_Rx is unasserted for at least four arbitration clock times. This indicates that another node has released the bus after the transmission of a packet. The receipt of this signal results in a PH_DATA.indication(DATA_END) to the link layer (see 5.1.3.3).
5.3.3 Gap timing A gap is a period of time during which the bus is idle (Data_Rx and Strb_Rx are unasserted). There are three types of gaps: a)
Acknowledge gap—Appears between the end of a packet and an acknowledge, as well as between isochronous transfers. A node shall detect the occurrence of an acknowledge gap after the bus has been in an unasserted state for four arbitration clock times (approximately 81.38 ns), but it shall not assert the bus until a total of eight arbitration clock times (approximately 182.76 ns) have occurred. This requirement ensures that a node is given adequate time to detect the acknowledge gap before the bus is asserted by another node (upon detecting an acknowledge gap). This includes the minimum time required to detect a BUS_IDLE (four arbitration clock times), as well as the maximum delay between the arbitration state machines within any two nodes on the bus (another four arbitration clock times).
b)
Subaction gap—Appears before asynchronous transfers within a fairness interval. A node shall detect the occurrence of a subaction gap after the bus has been in an unasserted state for at least 16 arbitration clock times (approximately 325.52 ns), but it shall not assert the bus until a total of 20 arbitration clock times (approximately 406.9 ns) have occurred. This requirement ensures that a node is given adequate time to detect the subaction gap before the bus is asserted by another node
Copyright © 2008 IEEE. All rights reserved.
119
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
(upon detecting a subaction gap). The duration of the subaction gap ensures that an another node asserting the bus after an acknowledge gap will have been detected by this time. c)
Arbitration reset gap—Appears before asynchronous transfers when the fairness interval starts. A node shall detect the occurrence of an arbitration reset gap after the bus has been in an unasserted state for at least 28 arbitration clock times (approximately 569.66 ns), but it shall not assert the bus until a total of 32 arbitration clock times (approximately 651.04 ns) have occurred. This requirement ensures that a node is given adequate time to detect the arbitration reset gap before the bus is asserted by another node (upon detecting a arbitration reset gap). The duration of the arbitration reset gap ensures that another node asserting the bus after an subaction gap or an acknowledge gap will have been detected by this time.
If a node is waiting for the occurrence of a particular gap, and the bus has become idle for the specified time (e.g., 32 arbitration clock times for an arbitration reset gap), the node shall detect the gap and assert the bus within the time constraints described in 5.2.4.2. These constraints ensure that an asserted signal shall have propagated through the decision/transceiver circuitry of the node and onto the bus soon enough to allow arbitration to occur properly. More information on gap timing is available in Annex D.
5.3.4 Arbitration sequence 5.3.4.1 Arbitration number The arbitration sequence uses a unique arbitration number for each module. This 6-bit number is the same as the physical_ID of the node. If less than 6 bits are provided for the arbitration number, they shall occupy the MSBs of the arbitration number. The remaining bits shall be zero-filled. The MSBs are transmitted first (see 1.5.3). NOTE—If the serial bus is contained within a host backplane, it is expected that the arbitration number (i.e., physical_ID) will be set by the host backplane at power-up (e.g., with a built-in slot identifier or configuration mechanism).
It is recommended that this number be software programmable to facilitate testing and to allow for consistent system operation and repeatability.
5.3.4.2 Priority Within the arbitration sequence, the arbitration number is preceded by 4 bits that define a priority level. The method by which priority is assigned is to be determined by the system integrator, with two exceptions: the lowest priority (all zeros) is reserved for fair arbitration and the highest priority (all ones) is reserved for Cycle Start requests. This allows 14 priority levels to be used for the urgent arbitration process. The use of an urgent priority class allows nodes to be granted a larger portion of the bandwidth on the bus. High-priority nodes are granted the bus before lower priority nodes during urgent allocation of the bus, allowing such nodes to be granted more bandwidth. NOTE—If used properly, deterministic latency algorithms (e.g., rate monotonic scheduling) may be used to assign priority to transfers so that they would be made within a predetermined amount of time. It is beyond the scope of this standard to specify the use of such algorithms.
In order to guarantee forward progress, the lowest priority level is reserved for fair arbitration. This allows all nodes arbitrating with this priority level to be allowed one fair access to the bus each fairness interval. For fair arbitration, the value of the arbitration number has a minimal impact on the allocation of the bus. Although nodes with higher arbitration numbers will be granted the bus sooner, there is only a small decrease in latency.
120
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The 4-bit priority field is not used in isochronous arbitration. When arbitrating for an isochronous transfer, the priority field is zero-filled.
5.3.4.3 Format of arbitration sequence The format in Figure 5-6 shall be used for the arbitration sequence.
Figure 5-6—Arbitration sequence a)
Each module on the backplane shall have a unique 6-bit arbitration number that is equal to the physical_ID of the node.
b)
The arbitration number shall be preceded by 4 bits of priority (refer to 5.4.2.1). The MSB of the priority field shall be transmitted first. The least significant bit (LSB) of the priority field shall be followed by the MSB of the arbitration number (refer to 5.4.2.1).
c)
Dynamic assignment of priority shall be accommodated.
d)
The lowest priority level (all zeroes) shall be reserved for fair arbitration, and the highest priority level (all ones) shall be reserved for the identification of the cycle start packet.
5.4 Backplane PHY operation The operation of the backplane PHY can best be understood with reference to the architectural diagram shown in Figure 5-7. This diagram shows the two primary functions performed by the PHY: arbitration and bit-level data transmission and reception.
Figure 5-7—Backplane PHY architecture The main controller of the backplane PHY is the block labeled “arbitration,” which responds to arbitration requests from the link layer (PHY_ARB.request) and indicates changes in the state of the bus. It provides the
Copyright © 2008 IEEE. All rights reserved.
121
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
management and timing signals for transmitting and receiving packets. It also provides the bus reset and configuration functions. The operation of this block is described in 5.4.1. The “encode” block generates the appropriate strobe signal for the transmitted data. Its operation is described in 5.4.2.1. The “data resync” block decodes the DS signal and retimes the received data to a local fixed-frequency clock provided by the “local clock” block. Since the clocks of receiving and transmitting nodes can be up to 100 ppm different from the nominal, the data resync function has to be able to compensate for a difference of 200 ppm over the maximum packet length of 87.24 μs (256 byte isochronous packet at 24.576 Mbit/s). The operation of this block is described in 5.4.2.2. The “data and signal decode” block provides a common interface to the link layer for both packet data and arbitration signals (data, gaps, and bus reset indicators). The operation of this block is also described in 5.4.2.2. An example of a backplane physical implementation is contained in Annex F. This annex describes how the PHY of a serial bus may be implemented in the backplane environment.
5.4.1 Arbitration Unless a node is using immediate arbitration to access the bus (in which case there is no contention for the bus), it is possible that more than one node may attempt to access the bus at a given time. Consequently, it is necessary for a node to arbitrate for the bus in order to gain access to the bus. NOTE—A node uses immediate arbitration to send an acknowledge. Since there is no contention for the bus in this case, arbitration is not necessary (a node that is transmitting an acknowledge does not arbitrate for the bus, but merely waits for an acknowledge gap to be detected before it begins transmission). If a node is attempting to gain access to the bus without using immediate access, it has to first arbitrate for the bus.
Arbitration occurs in response to a PHY arbitration request from the link layer. Nodes begin arbitrating once the bus has become idle for a predetermined amount of time (the appropriate gap indication occurs). Once this happens, nodes begin a bit-by-bit transmission of their arbitration sequence. Refer to 5.3.4 for a description of the arbitration sequence. Refer to 5.4.2.1 for a description of the bit-by-bit process of asserting and sampling the bus during arbitration. A node can obtain access to the bus in a limited number of ways. Because some arbitration classes allow nodes to begin arbitration before others, nodes arbitrating with certain arbitration classes may detect that the bus is busy before they can begin to arbitrate. In this way, certain arbitration classes can be bypassed (e.g., fair and urgent nodes will not get a chance to arbitrate if another node is sending an acknowledge or if it is arbitrating for an isochronous transfer). The backplane environment supports the FAIR, URGENT, CYCLE_MASTER, ISOCHRONOUS, and IMMEDIATE arbitration classes. These are described in the following subclauses. Refer to 5.1.2.1 for a description of the PH_ARB.request.
5.4.1.1 Fairness intervals NOTE—For additional information, see Q.7.2.
The fairness protocol is based on the concept of a fairness interval. A fairness interval consists of one or more periods of bus activity separated by short idle periods called subaction gaps and is followed by a longer idle period known as an arbitration reset gap. At the end of each gap, bus arbitration is used to determine the next bus owner. This concept is shown in Figure 5-8.
122
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 5-8—Fairness interval The implementation of the fair arbitration protocol is defined in terms of these fairness intervals, as is discussed in the following subclauses.
5.4.1.2 Fair arbitration NOTE—For additional information, see Q.7.2.
When using this arbitration class, an active node can send an asynchronous packet exactly once each fairness interval. Once a subaction gap is detected, a node can begin arbitration if its arbitration_enable signal is set. The arbitration_enable signal is set at the beginning of the fairness interval and is cleared when the node successfully accesses the bus through fair arbitration. This disables further fair arbitration attempts by that node for the remainder of the fairness interval. In the absence of urgent nodes, a fairness interval ends once all of the nodes attempting fair arbitration have successfully accessed the bus. At this time, all of the fair nodes have their arbitration_enable signals reset and cannot arbitrate for the bus. The bus remains idle until an arbitration reset gap occurs. Once this happens, the next fairness interval begins. All of the nodes set their arbitration_enable signal and can begin to arbitrate for the bus. This process is illustrated in Figure 5-9.
Figure 5-9—Fair arbitration Note that a node sending a concatenated subaction (see Q.6.2.3) does not reset its arb_enable bit.
Copyright © 2008 IEEE. All rights reserved.
123
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
5.4.1.3 Urgent arbitration NOTE—For additional information, see Q.7.4.2.
The backplane environment enhances the fair algorithm by splitting access opportunities among nodes based on two priority classes: “fair” and “urgent.” Nodes using an “urgent” priority may use up to three-fourths of the access opportunities, with the remaining equally shared among nodes using the “fair” priority. All nodes are required to implement the fair priority class, while the urgent priority class is optional. Packets are labeled as “urgent” if that priority class was used. The fair/urgent allocation uses the same fairness interval described in 5.4.1.1, but it accompanies the arbitration_enable flag with an “urgent_count.” The fair/urgent method works as follows: a)
If the bus is idle for longer than an arbitration reset gap, a fairness interval begins and all nodes shall set their “arbitration_enable” flags, while nodes implementing urgent priority shall set their “urgent_count” to three.
b)
A node that is waiting to send a packet using the fair priority class shall begin arbitrating after detecting a subaction gap as long as its arbitration_enable flag is set. If its arbitration_enable flag is cleared, it shall wait for an arbitration reset gap before it begins arbitrating. When such a node wins an arbitration contest, it sends a packet without the “urgent” label and its arbitration_enable flag is cleared.
c)
A node that is waiting to send a packet with urgent priority shall begin arbitrating after detecting a subaction gap if its urgent_count is nonzero. If its urgent_count is zero, it shall wait for an arbitration reset gap before it begins arbitrating. Whenever such a node wins an arbitration contest, it sends a packet with the “urgent” label.
d)
A node implementing urgent priority shall set its urgent_count to three whenever an unlabeled (i.e., fair) packet is transmitted or received. This includes received packets that are addressed to other nodes.
e)
A node shall decrement its urgent_count whenever a packet with the “urgent” label is transmitted or received. This includes received packets that are addressed to other nodes. This ensures that there will be at most three “urgent” packets for every “fair” packet. (This does not ensure that every node using urgent priority will obtain the bus three times each fairness interval. The node arbitrating with the highest priority will always obtain the bus before other nodes arbitrating with an urgent, but lower, priority.)
In the presence of urgent nodes, a fairness interval ends after the final fair node and up to three remaining urgent nodes have successfully accessed the bus. Since all fair nodes now have their arbitration_enable signals reset and all urgent nodes have their urgent_count decremented to zero, none of the nodes can access the bus. The bus remains idle until an arbitration reset gap has occurred, re-enabling arbitration on all nodes and starting the next fairness interval. This process is illustrated in Figure 5-10, which illustrates a situation where there are three nodes arbitrating for the bus with physical_IDs such that A has the highest, B is in the middle, and C has the lowest, with nodes A and C using fair priority and B using urgent. In the backplane environment, the natural priority is the concatenation of the 4-bit urgent priority level with the physical_ID. This results in the following: —
A node using the urgent priority will always win an arbitration contest over all nodes using the fair priority.
—
The node using the highest priority level will win the arbitration contest.
—
If more than one node uses the highest priority level, then the one with the highest physical_ID will win.
124
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 5-10—Urgent arbitration 5.4.1.4 Arbitration by the cycle master This arbitration class is used by the cycle master when it needs to arbitrate for the transmission of a cycle start packet. It is similar to the urgent arbitration class, except that the priority field is defined to be all ones (see 5.4.2.1). Arbitration begins once a subaction gap is detected, regardless of the state of the arbitration_enable signal or the urgent_count.
5.4.1.5 Isochronous arbitration This arbitration class is used by nodes arbitrating to send isochronous packets. Arbitration begins once an acknowledge gap is detected, regardless of the state of the arbitration_enable signal or the urgent_count. Because an acknowledge gap is shorter than an arbitration reset gap and a subaction gap, nodes arbitrating with this class will win the bus before nodes waiting to send fair, urgent, or cycle master packets. The priority field is not used in this arbitration class (see 5.4.2.1). See Q.6.4 for more information regarding isochronous arbitration.
5.4.1.6 Immediate arbitration This arbitration class is used by nodes sending an acknowledge to a received packet. Transmission of the acknowledge (beginning with a DATA_PREFIX; refer to 5.4.2.1) occurs as soon as an acknowledge gap is detected. This arbitration class is referred to as “immediate” because an arbitration sequence is not transmitted to obtain access to the bus (i.e., the node does not actually arbitrate for the bus).
5.4.2 Backplane environment packet transmission and reception Packet transmission and reception are synchronized to a local clock that shall be accurate within 100 ppm. The nominal data rates are either 49.152 Mbit/s or 24.576 Mbit/s for the backplane environment, depending on the particular backplane technology.
Copyright © 2008 IEEE. All rights reserved.
125
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
5.4.2.1 Backplane environment packet transmission Protocols and timing for packet transmission are different than those for arbitration. Packet transmission uses the DS bit level encoding method described in 5.3.1, and it is delimited by PH_DATA.request(DATA_PREFIX and DATA_END) symbols. Timing of the signals used to implement the encoding method is described in 5.2.3.1. Once a PHY layer completes an arbitration sequence, it signals the beginning of packet transmission by putting the bus into the PH_DATA.request(DATA_PREFIX) state. Because data can be either asserted or unasserted at the end of the arbitration sequence, the PHY layer first asserts Data_Tx for one arbitration clock time (approximately 20.35 ns) to put the bus into a known state (Strb_Tx is already in a known state because it is asserted during the arbitration sequence). Strb_Tx is then deasserted to transmit the DATA_PREFIX. If the PHY layer uses immediate arbitration to access the bus, the DATA_PREFIX does not follow an arbitration sequence (the bus has been idle for an acknowledge gap). In this case, Strb_Tx remains unasserted while Data_Tx is asserted to transmit the DATA_PREFIX. Once the PHY layer begins transmitting a DATA_PREFIX, it shall continue its transmission for at least four arbitration clock times (approximately 81.38), and it shall begin transmission of a packet within 160 arbitration clock times (approximately 3255.2 ns). The transmission of data within a packet occurs in response to PHY Data Requests. The link layer transmits each data bit in the packet as a PH_DATA.request(DATA_ONE or DATA_ZERO) in response to PH_CLOCK.indications from the PHY layer. The PHY layer sends PH_CLOCK.indications to the link layer for each bit to indicate the rate at which data bits are to be transmitted. The PHY layer encodes the data bits and produces the transmit signals Data_Tx and Strb_Tx. In order to provide a transition from the DATA_PREFIX state once the first bit of data is transmitted, Strb_Tx is asserted if the first bit is a DATA_ONE, or Data_Tx is deasserted if the first bit is a DATA_ZERO. This ensures that a transition will occur on either Strb or Data, and that a clock indication will be generated for the first bit of data once it is received by other nodes. The completion of a packet transmission requires two additional bits after the last bit in the packet. The first bit is required to flush the last bit in the packet through the receiving circuit. The second bit is required to put Data_Tx and Strb_Tx into the proper state to transmit a PH_DATA.request(DATA_PREFIX or DATA_END). A node transmits a DATA_PREFIX at the end of a packet in order to hold onto the bus (with a concatenated response, this would happen after a node transmits the acknowledge and before it transmits the response packet). A node transmits a DATA_END at the end of a packet in order to signal the release of the bus. Refer to 5.3.3 for further description of these signals. In order to remain in accordance with the DS bit level encoding algorithm (see 5.3.1), only one of the two signals Data_Tx and Strb_Tx can make a transition at one time. Table 5-7 and Table 5-8 indicate the proper series of transitions required to: provide the extra transition at the end of a packet; leave the bus in the proper state (DATA_PREFIX or DATA_END); and comply with the DS bit level encoding algorithm. Note that the Data_Tx and Strb_Tx cannot have the same values at the end of the packet since a)
The starting state of the bus is DATA_PREFIX (Strb is 1 and Data is 0)
b)
The number of bits in a packet must be even.
126
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 5-7—DATA_PREFIX signal transitions after packet transmission Signal state after last bit in packet
First transition
Second transition
Data_Tx Strb_Tx
0 1
1 1
1 0
Data_Tx Strb_Tx
1 0
1 1
1 0
Signal
NOTE—These signals typically undergo a “wire or” inversion at the output of TTL and BTL bus transceivers. The signals typically do not undergo an inversion at the output of ECL transceivers.
Table 5-8—DATA_END signal transitions after packet transmission Signal state after last bit in packet
First transition
Second transition
Data_Tx Strb_Tx
0 1
1 1
0 1
Data_Tx Strb_Tx
1 0
1 1
0 1
Signal
NOTE—These signals typically undergo a “wire or” inversion at the output of TTL and BTL bus transceivers. The signals typically do not undergo an inversion at the output of ECL transceivers.
Once the transmission of a DATA_PREFIX or a DATA_END begins, it shall continue for at least four arbitration clock times (approximately 81.38 ns). This allows sufficient time for all nodes to detect that such a symbol has been transmitted. The duration of a DATA_PREFIX shall not exceed 160 arbitration clock times (approximately 3255.2 ns), and the duration of a DATA_END shall not exceed 16 arbitration clock times (approximately 325.52 ns). Within this time, the PHY layer shall either begin transmission of a packet or release the bus. In order to ensure that transactions are completed within a certain amount of time, the link layer shall stop transmitting within a MAX_BUS_OCCUPANCY period of 100 μs after receiving the PHY Arbitration WON confirmation. If data requests continue to be received after this time, then the PHY shall release the bus using the signal transitions for a DATA_END. In such an event, the total number of transmitted data bits shall be even. NOTE—This assumes the longest period of bus occupancy would occur with an isochronous transmission on a TTL backplane. In such a case, this would include: a maximum-length data prefix (160 arbitration clock times), followed by a maximum-length isochronous transfer (4288 arbitration clock times on a TTL backplane), and finally a data end symbol (16 arbitration clock times). This corresponds to a total of 4464 arbitration clock times (approximately 90.820 μs).
5.4.2.2 Backplane environment packet reception Upon receipt of a packet, the receive signals Data_Rx and Strb_Rx are decoded using the method described in 5.3.1. The timing of these signals shall meet the requirements described in 5.2.3.2. Each recovered data bit is sent to the link layer as a PHY Data Indication. Data bits within the packet are indicated as a PH_DATA.indication(DATA_ONE or DATA_ZERO). DATA_PREFIX and DATA_END indications are also communicated to the link layer, as well as DATA_START indications that are generated
Copyright © 2008 IEEE. All rights reserved.
127
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
upon the reception of a packet. Indications of gap events may be communicated to the link layer, but they are used primarily within the PHY layer. When transmitting an acknowledge, the link layer shall have communicated a PHY arbitration request with an Arbitration Class of IMMEDIATE within a finite time after the end of a packet has been reported to the link layer (i.e., once the PHY layer indicates to the link layer that the transmitting node has completed the transmission of DATA_END, and has released the bus). This duration is called the ACK_RESPONSE_TIME, and shall not exceed 32 arbitration clock times (approximately 651.04 ns).
5.5 Backplane initialization and reset 5.5.1 Backplane PHY reset The following subclauses describe reset operations within the PHY layer. Refer to Clause 8 for more information regarding bus reset events and bus management. Upon a power_reset event (i.e., power up or live insertion), registers and CSRs associated with the operation of the PHY layer shall be initialized to their default values. State machines associated with PHY layer operations may be initialized. The BUS_RESET signal (as described in 5.3.2) shall not be transmitted on the bus by the PHY layer. PHY event indications of BUS_RESET_START and BUS_RESET_COMPLETE (as described in 5.1.1.3) shall not be communicated to the node controller.
5.5.1.1 Command reset Upon a command_reset event, CSRs associated with the operation of the PHY layer shall be initialized to their default values. The BUS_RESET signal shall not be transmitted on the bus by the PHY layer. PHY event indications of BUS_RESET_START and BUS_RESET_COMPLETE shall not be communicated to the node controller.
5.5.1.2 Bus reset Once a PHY control request of Bus Reset (as described in 5.1.1.1) is communicated from the node controller to the PHY layer, the registers and CSRs associated with the operation of that PHY layer shall be initialized to their default values. State machines associated with PHY layer operations may be initialized. The PHY layer shall communicate BUS_RESET onto the bus. Once this signal is initiated, a PHY control confirmation of Initiated_reset (as described in 5.1.1.2) shall be communicated to the node controller. After the BUS_RESET event is “detected” by the node transmitting it (i.e., approximately 320 arbitration clock times after the signal is initiated), the PHY layer shall initialize itself. NOTE—Since a PHY layer transmitting a BUS_RESET also has to react accordingly once the BUS_RESET event is detected, its state machines will not have had the opportunity to “advance” beyond those of other nodes. This ensures that all nodes are in somewhat similar states after such a bus reset event. Obviously, the logic (e.g., counters) used within the PHY layer to generate the BUS_RESET signal shall not be reset once that PHY simultaneously detects its “own” BUS_RESET.
Once a PHY layer detects that a BUS_RESET event has occurred on the bus, it shall initialize itself. PHY event indications of BUS_RESET_START and BUS_RESET_COMPLETE shall be communicated to the node controller.
5.5.2 Backplane PHY initialization Upon entering the bus (i.e., power up, live insertion, or bus reset), a module shall wait for an arbitration reset gap before arbitrating for the bus. A node that is live inserted should not initiate a BUS_RESET.
128
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
6. Link layer specification The link layer of the serial bus provides connectionless acknowledged data transfer services between a source node and a destination node. In the link layer the basic PDU is the packet and its corresponding acknowledge, defined in this standard as a “subaction.” There are two types of subactions: a)
Asynchronous—The source node transmits data in turn, using the appropriate access method.
b)
Isochronous—The source node transmits data every NOMINAL_CYCLE_TIME (see Table 9-18) with a guaranteed maximum latency of NOMINAL_CYCLE_TIME. The maximum size of each of these packets is set by a bus management entity.
Isochronous subactions have “guaranteed” access to the available bus bandwidth, while asynchronous subactions use the remaining bandwidth. It is the responsibility of the isochronous resource management process to guarantee that adequate bus bandwidth remains for asynchronous use. The link layer makes use of PHY layer services (see 16.2 and 5.1) to perform actions on the bus. Note that the PHY layer services may impose additional requirements on the link layer.
6.1 Link layer services Link layer services are provided at the interface between the link layer and higher layers, as illustrated in Table 6-1.
Table 6-1—Summary of link layer services Layer communicated with
Service
Purpose of service
Link control request
From the node controller
Configure the link layer
Link control confirmation
To the node controller
Confirm link control request
Link event indication
To the node controller
Alert node controller to events detected in the link layer
Link remote configuration request
From the node controller
Configure remote cable PHY layer
Link remote configuration indication
To the node controller
Report remote cable PHY configuration information
Link data request
From the transaction layer
Cause the link layer to send one primary asynchronous packet
Link data confirmation
To the transaction layer
Confirm link data request
Link data indication
To the transaction layer
Indicate the reception of one primary asynchronous packet
Link data response
From the transaction layer
Respond to link data indication
Link bus indication
To the transaction layer
Indicate bus event
Link isochronous control request
From an application
Select receive channels
Link cycle sync indication
To an application
Indicate the start of the local isochronous cycle
Copyright © 2008 IEEE. All rights reserved.
129
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 6-1—Summary of link layer services (continued) Service
Layer communicated with
Purpose of service
Link isochronous request
From an application
Cause the link layer to send one primary isochronous packet
Link isochronous indication
To an application
Indicate the reception of one primary isochronous packet
The method by which these services are communicated between the layers is not defined by this standard. Link layer services may perform actions specified by the higher layer. Link layer services may also communicate parameters that may or may not be associated with an action.
6.1.1 Link layer bus management services for the node controller These services are used by the node controller to control the resources of the link layer. The link layer uses these services to communicate to the node controller changes of state within the link layer or on the bus.
6.1.1.1 Link control request (LK_CONTROL.request) The node controller uses this service to request the link layer to perform specific actions and to specify link layer parameters. The link layer shall service the request immediately upon receipt by the link layer. This service is confirmed. The following actions defined for all link layer implementations shall be provided by this service: —
Reset. The link layer shall discard all pending transactions and subactions, disable reception of all nonbroadcast packets, and disable transmission of all packets.
—
Initialize. The link layer shall discard all pending transactions and subactions, enable reception of all nonbroadcast packets, and enable transmission of all packets.
If the link layer implementation is capable of being the cycle master, then the following actions shall also be provided by this service: —
Enable cycle master. The link layer shall send cycle start packets, as defined in 6.2.2.2.3.
—
Disable cycle master. The link layer shall not send cycle start packets.
The following parameter is communicated to the link layer via this service: —
Node_ID. This parameter shall contain the current node_ID.
If the node is an isochronous resource manager (IRM), then the following optional parameter may be communicated to the link layer via this service: —
Expected channel list. This parameter shall contain the list of isochronous channels that are expected each isochronous cycle.
NOTE—This parameter is only present in nodes that have the IRM function and is used for error detection. Note also that the IRM shall be able to receive at all bus speeds in use on the bus, or it may not be able to recognize all channel transfers.
Table 6-2 summarizes the actions and parameters provided by this service.
130
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 6-2—Summary of link control request actions and parameters Action or parameter Reset action
Supported by… All link layers
Initialize action Node_ID parameter Enable cycle master action
Link layers that are capable of being the cycle master.
Disable cycle master action Expected channel list parameter (optional)
Link layers that are capable of being IRMs
6.1.1.2 Link control confirmation (LK_CONTROL.confirmation) The link layer uses this service to confirm the results of a link control request service. The link layer shall communicate this service to the node controller upon completion of a link control request. There are no actions provided by this service. No parameters are communicated to the node controller via this service.
6.1.1.3 Link event indication (LK_EVENT.indication) Events detected by the link layer are communicated to the node controller by this service. This service provides no actions nor are there any responses defined for the indication. A single parameter, link event, may be communicated via this service; the parameter shall specify the event detected by the link layer, as defined below: —
BUS OCCUPANCY VIOLATION DETECTED. Clocked data was observed on the bus for longer than MAX_DATA_TIME.
—
CYCLE TOO LONG. A cycle start packet was received and NOMINAL_CYCLE_TIME elapsed without the detection of a subaction gap.
—
DUPLICATE CHANNEL DETECTED. A stream packet was received with a channel number equal to one of the node’s active, transmit isochronous channels.
—
HEADER CRC ERROR DETECTED. The CRC check for the header of a received primary packet failed (see 6.2.4.15).
—
UNEXPECTED CHANNEL DETECTED. The IRM observed a stream packet whose channel number is not allocated in the CHANNELS_AVAILABLE register; this event shall not be reported except by the active IRM.
Link layer implementations may be incapable of detecting some or all of these events. NOTE—The LK_EVENT.indication service is provided to report events detectable by the link layer but not reportable through the link layer data services. The node controller may log these events or it may take other implementationdependent action.
6.1.1.4 Link remote configuration request (LK_CONFIG.request) (cable environment only) The node controller uses this service to request the link layer to send PHY control packets to remote PHYs. No confirmation is defined for this request. The following actions shall be provided by this service: —
Send PHY configuration packet. A PHY configuration packet as described in 16.3.2.3 and 16.3.3.4 will be sent using the parameters listed below: —
Set force root. If true, the force_root bit will be set for the remote node with its physical_ID matching the remote physical ID. The force_root bit for all other nodes will be cleared.
Copyright © 2008 IEEE. All rights reserved.
131
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
—
Remote physical ID. (Optional, only present when the set force root parameter is true.) The physical_ID of the remote node will have its force_root bit set.
—
Set gap count. If true, the gap_count of all remote nodes will be set to the gap count parameter.
—
Gap count. (Optional, only present when the set gap count parameter is true.) The new value of gap_count for all remote nodes.
IMPORTANT—The PHY control request is used to set the parameters for the local PHY. The link remote configuration request is only used for setting parameters of remote PHYs. —
Send Link-on packet. A link-on packet as described in 16.3.2.2 will be sent using the parameter listed below:
—
Remote physical ID. The physical_ID of the node that is to receive the link-on packet.
NOTE—This request is part of the link layer specification since implementations will typically use link layer facilities to send PHY control packets. PHY hardware will typically only send self-ID packets.
6.1.1.5 Link remote configuration indication (LK_CONFIG.indication) (cable environment only) The link layer uses this service to indicate to the node controller configuration information received during the bus initialization process from the self-ID packets. No response is defined for this indication. The following parameters are communicated via this service: a)
Remote physical ID. This parameter shall contain the physical_ID of the node currently sending configuration information.
b)
Remote gap_count.
c)
Remote link_active.
d)
Remote PHY_SPEED.
e)
Remote PHY_DELAY.
f)
Remote CONTENDER.
g)
Remote NPORT.
h)
Remote Child [one for each port].
i)
Remote Connected [one for each port].
j)
Remote Initiated_reset.
NOTE—This indication is part of the link layer specification since implementations will typically use link layer facilities to receive PHY self-ID packets. PHY hardware will typically only receive and process PHY control packets (configuration and link-on packets).
6.1.2 Link layer asynchronous data services for the transaction layer These services are used to communicate asynchronous data packets between the link layer and the transaction layer. See 6.2.3.
6.1.2.1 Link data request (LK_DATA.request) The transaction layer uses this service to request the link layer to transmit one primary asynchronous packet on the bus. This service shall be confirmed. The following parameters are communicated to the link layer via this service. Some of the parameters may not be communicated because they are not required by the packet format specified by the transaction code. a)
Destination address. As defined in 6.2.5.2.
b)
Transaction code. As defined in 6.2.5.5.
132
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
c)
Extended transaction code. As defined in 6.2.5.9.
d)
Transaction label. As defined in 6.2.5.3.
e)
Retry code. As defined in 6.2.5.4.
f)
Response code. As defined in 6.2.5.10.
g)
Data length. As defined in 6.2.5.8.
h)
Data. This is the data to be sent.
i)
Priority (backplane only). As defined in Table 6-10.
j)
Speed (cable only). As defined in Table 4.2.
IEEE Std 1394-2008
6.1.2.2 Link data confirmation (LK_DATA.confirmation) The link layer uses this service to confirm the transmission of a packet. The link layer shall communicate this service to the transaction layer upon completion of a link data request. There are no actions provided by this service. The following parameters are communicated to the transaction layer via this service: a)
b)
Request status. This parameter shall contain the result of a link data request. The following values are defined for this value: 1)
ACKNOWLEDGE_RECEIVED. An expected acknowledge packet was received from the destination node.
2)
ACKNOWLEDGE_MISSING. An expected acknowledge packet was not received from the destination node.
3)
BROADCAST_SENT. The broadcast packet was transmitted.
Acknowledge. This parameter shall be set to one of the values defined in Table 6-14. This parameter is valid only when the value of request status is ACKNOWLEDGE RECEIVED.
6.1.2.3 Link data indication (LK_DATA.indication) The link layer uses this service to indicate to the transaction layer that an asynchronous packet has been received. There are no actions provided by this service. The transaction layer shall respond to this indication. The link layer shall communicate this indication to the transaction layer whenever an asynchronous packet has been received. The following parameters are communicated to the transaction layer via this service. Some of the parameters may not be communicated because they are not included in the packet format indicated by the transaction code. a)
Source ID. As defined in 6.2.5.7.
b)
Destination address. As defined in 6.2.5.2.
c)
Transaction code. As defined in 6.2.5.5.
d)
Extended transaction code. As defined in 6.2.5.9.
e)
Transaction label. As defined in 6.2.5.3.
f)
Retry code. As defined in 6.2.5.4.
g)
Response code. As defined in 6.2.5.10.
h)
Data length. As defined in 6.2.5.8.
i)
Data. This is the data received.
j)
Priority (backplane only). As defined in 6-10.
k)
Speed (cable only). As defined in Table 16-2.
l)
Packet status. This parameter shall contain the result of the receive packet operation performed by the link layer. The following values are defined for this parameter:
Copyright © 2008 IEEE. All rights reserved.
133
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
1)
GOOD. The packet was received with no errors detected by the link layer.
2)
BROADCAST. A broadcast packet was received with no errors detected by the link layer.
3)
DATA_ERROR. The CRC check (see 6.2.4.15) for the data portion of a block packet failed or the actual size of the packet’s data payload, if present, does not match that specified by the data_length field. When the transaction layer receives this information (as the result of a LK_DATA.indication) it shall respond as specified by 7.3.1.3A.
4)
FORMAT_ERROR. The received packet had an unrecognized field value, or a reserved field was nonzero.
6.1.2.4 Link data response (LK_DATA.response) The transaction layer uses this service to respond to a received packet; i.e., complete the subaction by sending an acknowledge packet. The transaction layer shall communicate this response to the link layer after receiving a link data indication. The following parameters are communicated to the link layer via this service: a)
Acknowledge. This parameter shall be set to one of the values defined in 6.2.6.2.2. The link layer shall use this parameter for the response.
b)
Bus Occupancy Control. This parameter controls whether the link layer will release control of the bus after sending the acknowledge. The following values are defined for this parameter:
c)
1)
RELEASE. The link layer shall release control of the bus.
2)
HOLD. The transaction layer shall immediately follow this response with a link data request containing the response data for the current transaction. The link layer shall not give up control of the bus. The value of the acknowledge parameter shall be set to ack_pending.
3)
NO_OPERATION. The link layer shall do nothing. This parameter value shall be used only to respond to a link data indication with packet status of BROADCAST. The acknowledge parameter is undefined.
Speed (cable only). As defined in Table 16-2.
6.1.2.5 Link bus indication (LK_BUS.indication) The link layer uses this service to indicate to the transaction layer events on the serial bus. There are no actions provided by this service. No response is defined for this indication. The following parameters are communicated to the transaction layer via this service: —
Bus event. This parameter shall contain the most recent event on the serial bus. The following values are defined for this parameter: —
ARB_RESET_GAP. An arbitration reset gap has been detected on the serial bus.
6.1.3 Link layer isochronous data services for application layers These services are used to communicate isochronous data packets between the link layer and an application layer. See 6.3.1.6 through 6.3.1.8.
6.1.3.1 Link isochronous control request (LK_ISO_CONTROL.request) The application layer uses this service to communicate the following parameter to the link layer: —
134
Channel receive list. This parameter shall contain the list of isochronous channels that the link layer shall recognize. The link layer shall generate a link isochronous data indication whenever an isochronous packet is received with the channel field set to the value of one of the channels on this list.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
6.1.3.2 Link cycle sync indication (LK_CYCLE.indication) The link layer uses this service to indicate to an application layer that the cycle sync event has occurred. See 6.3.2. There are no actions provided by this service. There is no response to this indication. The link layer shall communicate this indication to the application layer whenever the cycle sync event occurs. The following parameters are communicated to the application layer via this service: a)
Current cycle count. This parameter shall contain the current CYCLE_TIME.cycle_count value as defined in 8.3.2.2.8.
b)
Current Seconds count. This parameter shall contain the current value of the BUS_TIME register as defined in 8.3.2.2.9.
6.1.3.3 Link isochronous request (LK_ISO.request) The application layer uses this service to request the link layer to transmit one isochronous packet on the bus. This service is not confirmed. The application layer shall make at most only one link isochronous request per channel for each link cycle sync indication received by the application layer. The following parameters are communicated to the link layer via this service: a)
Tag. As defined in 6.2.5.12.
b)
Channel. As defined in 6.2.5.13.
c)
Synchronization code. As defined in 6.2.5.14.
d)
Data length. As defined in 6.2.5.8.
e)
Data. This is the data to be sent.
f)
Speed (cable only). As defined in Table 16-2.
6.1.3.4 Link isochronous indication (LK_ISO.indication) The link layer uses this service to indicate to the application layer that an isochronous packet has been received. There are no actions provided by this service. No response is defined for this indication. The link layer shall communicate this indication to the application layer whenever an isochronous packet has been received. The following parameters are communicated to the application layer via this service: a)
Tag. As defined in 6.2.5.12.
b)
Channel. As defined in 6.2.5.13.
c)
Synchronization code. As defined in 6.2.5.14.
d)
Data length. As defined in 6.2.5.8.
e)
Data. This is the data received.
f)
Speed (cable only). As defined in Table 16-2.
g)
Packet status. This parameter shall contain the result of the receive packet operation performed by the link layer, as defined in 6.1.2.3. When an isochronous application receives this information (as the result of LK_ISO.indication) it shall ignore the isochronous packet.
NOTES 1—The transaction code is implied by this service. See 6.2.3.2. 2—In some isochronous applications, delivery jitter larger than a single isochronous cycle may be tolerable. For these applications, an isochronous talker that detects an error during transmission may elect to retransmit the packet during the
Copyright © 2008 IEEE. All rights reserved.
135
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
next isochronous interval. The recipient of a malformed isochronous packet may not have a priori knowledge of the talker’s error recovery behavior; as a consequence, the only reliable strategy is to discard the malformed packet.
6.2 Link layer facilities The link layer facilities use two of the three basic packet types: primary packets and acknowledge packets. Figure 6-1 shows the relationship between the different packet types.
Figure 6-1—Serial bus packets 6.2.1 Primary packets All primary serial bus packets share the format shown in Figure 6-2.
Figure 6-2—Primary packet format
Every valid primary packet is a sequence of aligned quadlets. A primary packet is distinguished from an acknowledge packet or a PHY packet by its length and/or encoding. The length of a primary packet shall be
136
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
at least two quadlets (a zero-data isochronous packet). A primary packet shall consist of a packet header, and it may also include a data block. All packet headers shall contain one or more quadlets followed by a header_CRC. The header_CRC shall be calculated only on the packet header. A node shall not act on or generate a response to a packet in which the packet header does not pass the header_CRC check (see 6.2.5.15). The first quadlet of the packet header of every primary packet shall contain the transaction code (tcode in Figure 6-2) in bits 24 to 27. The transaction code defines the packet type of a primary packet (see 6.2.5.5). Primary packet types with a data block payload shall contain one or more quadlets of data followed by a data_CRC. The data_CRC shall be calculated only on the data block quadlets and shall not include any of the packet header quadlets. Two basic varieties of primary packet are defined for the serial bus: the asynchronous packet and the isochronous packet, which are distinguishable by the transaction code value.
6.2.2 Asynchronous packets All asynchronous serial bus packets share the format shown in Figure 6-3.
Figure 6-3—Asynchronous packet format Every valid asynchronous packet is a sequence of aligned quadlets. An asynchronous packet conforms to the rules for a primary packet. The length of an asynchronous packet shall be at least four quadlets. An asynchronous packet shall consist of a packet header, and it may also include a data block. The fourth quadlet of the header may be required to hold packet-type-specific data. Table 6-3 summarizes the asynchronous packet components and abbreviations used in this subclause. The packet components are fully defined in 6.2.5.
Copyright © 2008 IEEE. All rights reserved.
137
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 6-3—Summary of asynchronous packet components Packet component
Size (bits)
Name(s)
Subclause
Comment
Destination identifier
destination_ID
16
6.2.5.2.1
All asynchronous packets
Transaction label
tl
6
6.2.5.3
All asynchronous packets
Retry code
rt
2
6.2.5.4
All asynchronous packets
Transaction code
tcode
4
6.2.5.5
All primary packets
Priority
pri
4
6-10
All asynchronous packets
Source identifier
source_ID
16
6.2.5.7
All asynchronous packets
Packet-type-specific information
destination_offset
48
6.2.5.2.2
Request packet: destination offset
rcode & reserved
4 & 44
6.2.5.10
Response packet: response code and reserved field
quadlet data
32
6.2.5.11
Quadlet packets: quadlet payload
6.2.5.8, 6.2.5.9
Data-block packets: data length and extended transaction code
Packet-type-specific quadlet data
data_length and extended_tcode Header CRC
header_CRC
32
6.2.5.15
All primary packets
Data block payload
data field
—
6.2.5.11
All data block packets; has special meaning in lock-request and lockresponse packets
arg_value
32 or 64
6.2.2.3.2
Special for lock-request packets
data_value
32 or 64
6.2.2.3.2
Special for lock-request packets
old_value
32 or 64
6.2.2.3.4
Special for lock-response packets
data_CRC
32
6.2.5.15
All data block packets
Data block CRC
6.2.2.1 Asynchronous packets with no-data payload This packet format contains no payload. A no-data packet contains a packet header only; no data block follows the header. The generic format of a no-data packet is shown in Figure 6-4. The “packet-specific information” field differs based on the packet type.
Figure 6-4—No-data payload primary packet format
138
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
6.2.2.1.1 Read request for data quadlet This packet type requests a single data quadlet from the specified destination address (see 6.2.5.2). The packet-specific information field of this packet type specifies the destination_offset for the read request. The format of a read request is shown in Figure 6-5.
Figure 6-5—Read request for data quadlet packet format 6.2.2.1.2 Write response This packet type shall be sent only in response to a write request for data quadlet or a write request for data block. This packet type shall not be sent if the transaction was a unified transaction (see 7.3.2.1). The packet-specific information field of this packet type specifies the response code (rcode) for the corresponding write request. The format of a write response is shown in Figure 6-6.
Figure 6-6—Write response packet format 6.2.2.2 Asynchronous packet formats with data quadlet payload This packet format contains a single quadlet as a payload, which is contained within the packet header. A data quadlet payload packet contains a packet header only; no data block follows the header. The generic format of a data quadlet payload packet is shown in Figure 6-7. The “packet-specific information” and “packet-type-specific quadlet data” fields differ based on the packet type.
Figure 6-7—Data quadlet payload packet format
Copyright © 2008 IEEE. All rights reserved.
139
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.2.2.2.1 Read request for data block This packet type requests a data block from the specified destination address (see 6.2.5.2). The packetspecific information field of this packet type specifies the destination_offset for the read request. The packet-specific quadlet data field specifies the data_length of the expected response data, and the extended transaction code (extended_tcode). The extended_tcode field is reserved for this packet type, and it shall be set to 000016. The format of a read request is shown in Figure 6-8.
Figure 6-8—Read request for data block packet format 6.2.2.2.2 Write request for data quadlet This packet type requests a data quadlet be written to the specified destination address (see 6.2.5.2). The packet-specific information field of this packet type specifies the destination_offset for the write request. The packet-specific quadlet data field specifies the data quadlet to be written as a result of the request. The format of a write response is shown in Figure 6-9.
Figure 6-9—Write request for data quadlet packet format 6.2.2.2.3 Cycle start The requirements placed upon a cycle master to transmit a cycle start packet are different from the criteria used by recipients to recognize a cycle start packet. The format of a cycle start packet is shown by Figure 6-10. The tcode field shall have a value of eight. The source_ID field shall be the node_ID of the cycle master that transmits the cycle start packet. The cycle_time field shall contain the contents of the cycle master’s CYCLE_TIME register (see 8.3.2.3.1).
140
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The header_CRC field shall be calculated as specified by 6.2.4.15. transmitted first zero
FFFF16 source_ID
tcode
F16
FFFF16 F000 020016 cycle_time header_CRC transmitted last
Figure 6-10—Cycle start packet format The cycle master shall signal the start of the isochronous period by transmitting a cycle start packet with the format defined above. No node except the cycle master shall transmit a cycle start packet. A cycle start packet shall be recognized if tcode has a value of eight and the header_CRC is valid. NOTE—The cycle start packet is a write request for data quadlet whose values can be interpreted as a broadcast write to the CYCLE_TIME register. Although this could be handled in an implementation by the transaction layer and node controller, this standard assumes that the link layer is responsible for the generation and detection of the start of an isochronous period.
6.2.2.2.4 Read response for data quadlet This packet type shall be sent only in response to a read request for a data quadlet. The packet-specific information field of this packet type specifies the response code (rcode) for the corresponding read request. The packet-specific quadlet data field contains the requested read data. The format of a read response is shown by Figure 6-11. transmitted first destination_ID source_ID
tl rcode
proxy_ID
rt reserved
tcode
pri ext_rcode
reserved quadlet_data header_CRC transmitted last
Figure 6-11—Read response for data quadlet packet format The fields ext_rcode and proxy_ID are defined by IEEE Std 1394.1 and shall be treated as reserved for equipment not implementing IEEE Std 1394.1.
Copyright © 2008 IEEE. All rights reserved.
141
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.2.2.3 Asynchronous packet formats with data block payload This packet format contains a data block as a payload, which is transferred after the packet header. A data block payload packet can contain zero or more bytes of data. If the data_length is not a multiple of four, the originating node shall pad the data field to a quadlet boundary with 0016 fill data. If the data_length is zero, no data field shall be sent, and no data_CRC shall be sent. The generic format of a data block payload packet is shown in Figure 6-12. The “packet-specific information” and “packet-specific quadlet data” fields differ based on the packet type.
Figure 6-12—Data block payload packet format The number of bytes in the data field shall not exceed an absolute maximum value based on the data rate used to transmit the packet, as shown in Table 6-4.
Table 6-4—Maximum payload size for asynchronous data packets Data rate
Maximum payload (bytes)
Comment
S25
128
TTL backplane
S50
256
BTL and ECL backplane
S100
512
Alpha or Beta mode
S200
1024
S400
2048
S800
4096
S1600
8192
S3200
16 384
Beta Mode only (see Table 16-18)
6.2.2.3.1 Write request for data block This packet type requests a data block be written to the specified destination address (see 6.2.5.2). The packet-specific information field of this packet type specifies the destination_offset for the write request. The extended_tcode field is reserved for this packet type, and it shall be set to 000016. The format of a write request is shown by Figure 6-13.
142
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The fields snarf and source_portal are defined by IEEE Std 1394.1 and shall be treated as reserved for equipment not implementing IEEE Std 1394.1. transmitted first destination_ID
tl
rt
tcode
pri
source_ID destination_offset data_length
snarf
source_portal
extended_tcode
header_CRC
data field
zero pad bytes (if necessary data_CRC transmitted last
Figure 6-13—Write request for data block packet format 6.2.2.3.2 Lock request This packet type requests a locked access of the specified destination address (see 6.2.5.2). The packetspecific information field of this packet type specifies the destination_offset for the lock-request packet. The extended_tcode field is set to the lock function requested (see 6.2.5.9). The format of a lock request is shown by Figure 6-14.
Figure 6-14—Lock-request packet format
Copyright © 2008 IEEE. All rights reserved.
143
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The data_length field shall be set only to the values shown in Table 6-5. All other values for data_length are reserved. The values specified in data_length and extended tcode indicate the size of the arg_value and data_value fields.
Table 6-5—Data_length values for lock requests Data_length (bytes)
Size of arg_value (bytes)
Size of data_value (bytes)
4
0
4
Single argument 32-bit add_little/add_big
8
4
4
Two argument 32-bit function
8
0
8
Single argument 64-bit add_little/add_big
16
8
8
Two argument 64-bit function
Comment
6.2.2.3.3 Read response for data block This packet type shall be sent only in response to a read request for data block. The packet-specific information field of this packet type specifies the response code (rcode) for the corresponding read request. The extended_tcode field is reserved for this packet type, and it shall be set to 000016. If the value of rcode is not resp_complete, then the data_length shall be set to 000016, and no data block (data field and data_CRC) shall be transferred. When the response code (rcode) is resp_complete, the data_length field in the response packet shall be equal to the data length specified by the corresponding read request. If data_length is zero, no data CRC shall be transmitted. The format of a read response is shown by Figure 6-15. transmitted first destination_ID
tl
source_ID
rcode
rt
tcode
reserved
proxy_ID
reserved
data_length
extended_tcode
pri ext_rcode
header_CRC
data field
zero pad bytes (if necessary data_CRC transmitted last
Figure 6-15—Read response for data block packet format The fields ext_rcode and proxy_ID are defined by IEEE Std 1394.1 and shall be treated as reserved for equipment not implementing IEEE Std 1394.1.
144
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
6.2.2.3.4 Lock response This packet type shall be sent only in response to a lock-request packet. The packet-specific information field of this packet type specifies the response code (rcode) for the corresponding lock request. The extended_tcode field shall be set to the lock function specified in the lock-request packet. The data_length field shall be set only to a value of 000416 or 000816, corresponding to the size of old_value. If the value of rcode is not resp_complete, then the data_length shall be set to 000016, and no data block (old_value and data_CRC) shall be transferred. All other values for data_length are reserved. The format of a lock response is shown by Figure 6-16. The fields ext_rcode and proxy_ID are defined by IEEE Std 1394.1 and shall be treated as reserved for equipment not implementing IEEE Std 1394.1. transmitted first destination_ID source_ID
tl rcode
rt
tcode
reserved
proxy_ID
reserved
data_length
extended_tcode
pri ext_rcode
header_CRC
old_value
data_CRC transmitted last
Figure 6-16—Lock-response packet format 6.2.3 Isochronous packets 6.2.3.1 Isochronous packet components Every valid isochronous packet is a sequence of aligned quadlets. An isochronous packet conforms to the rules for a primary packet. The length of an isochronous packet shall be at least two quadlets. An isochronous packet shall consist of a packet header, and it may also include a data block. Only one type of isochronous packet is defined for the serial bus, as described in 6.2.3.2. Table 6-6 summarizes the isochronous packet components and abbreviations used in this subclause. The packet components are fully defined in 6.2.5.
Copyright © 2008 IEEE. All rights reserved.
145
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 6-6—Summary of isochronous packet components Packet component
Abbreviation
Size (bits)
Comment
Data length
data_length
16
All data-block packets
Isochronous data format tag
tag
2
Isochronous data block packet only
Isochronous channel
channel
6
Isochronous data block packet only
Transaction code
tcode
4
All primary packets
Synchronization code
sy
4
Isochronous data block packet only
Header CRC
header_CRC
32
All primary packets
Data block payload
data_field
—
All data block packets
Data block CRC
data_CRC
32
All data block packets
6.2.3.2 Isochronous data block packet format This packet format contains a data block as a payload, which is transferred after the packet header. The data block may contain zero or more bytes of data. If the data_length is not a multiple of four, the talking node shall pad the data field to a quadlet boundary with 00(16) fill data. If the data_length is zero, no data field shall be sent and no data_CRC shall be sent. Isochronous data block primary packets shall be sent only during an isochronous cycle (see 6.3.1.6). The format of a isochronous data block packet is shown by Figure 6-17.
Figure 6-17—Isochronous data block packet format The number of bytes in the data field shall not result in an isochronous packet that exceeds the bandwidth allocated for this channel (see 8.4.2.6). There is an additional requirement that the maximum data payload of an isochronous stream packet is speed dependent and shall conform to Table 6-7.
146
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 6-7—Maximum payload size for isochronous stream packets Data rate
Maximum payload (bytes)
Comment
S25
256
TTL backplane
S50
512
BTL and ECL backplane
S100
1024
Cable base rate
S200
2048
—
S400
4096
—
S800
8192
—
S1600
16 384
—
S3200
32 678
—
6.2.4 Asynchronous streams 6.2.4.1 Asynchronous stream packet format The format of an asynchronous stream packet is identical to that of an isochronous stream packet, as specified by 6.2.3.2 and illustrated by Figure 6-18. transmitted first data_length
tag
channel
tcode
sy
header_CRC data field zero pad bytes (if necessary) data_CRC
transmitted last
Figure 6-18—Asynchronous stream packet format The fields of an asynchronous stream packet shall conform to requirements that follow and those specified in 6.2.4. The data_length field shall specify the length in bytes of the data field in the asynchronous stream packet The number of bytes in the data field is determined by the transmission speed of the packet and shall not exceed the maximums specified by Table 6-7. The tag field shall have a value of zero, unformatted data, or three, global asynchronous stream packet (GASP) format; other values of tag are reserved for future standardization. When tag is zero the content and format of the data field are unspecified. Otherwise, when tag is three, the format of the asynchronous stream packet is specified by 6.2.4.2, unless data_length is zero, in which case the format is specified by IEEE Std 1394.1 (cycle master adjustment packet.).
Copyright © 2008 IEEE. All rights reserved.
147
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The channel field shall identify the stream; the channel identified shall be allocated from the IRM CHANNELS_AVAILABLE register. NOTE—Unlike isochronous stream packets, which may continue to be transmitted for up to 1 s subsequent to a bus reset without channel reallocation, asynchronous stream packets may not be transmitted until their channel number(s) are reallocated.
The tcode field shall have a value of A16. The new name for this transaction code value is stream packet; the context in which the packet is sent determines whether it is an asynchronous or isochronous stream packet. The usage of any fields not specified in this subclause remains as described for isochronous stream packets in 6.2.3.
6.2.4.2 Global asynchronous stream packet (GASP) format Motivated by work on IEEE P1394.1, this subclause defines an asynchronous stream packet format suitable for transport across a bridge from one serial bus to another. The format of a global asynchronous stream packet is an extension of that specified by 6.2.4.1, which utilizes the first two quadlets of the packet’s data payload. The GASP format is illustrated by Figure 6-19. transmitted first data_length
tag
channel
tcode
sy
header_CRC source_ID
specifier_ID_hi
specifier_ID_lo
version data field zero pad bytes (if necessary) data_CRC
transmitted last
Figure 6-19—Global asynchronous stream packet (GASP) format
Except as specified below, the definition and usage of the fields in Figure 6-19 is contained within 6.2.4.1. The tag field shall have a value of three. The sy field is defined by IEEE Std 1394.1 and shall be treated as reserved for equipment not implementing IEEE Std 1394.1. The source_ID field shall specify the node_ID of the sending node and shall be equal to the 16 MSBs of the sender’s NODE_IDS register. The specifier_ID field shall contain a 24-bit organizationally unique identifier (OUI) assigned by the IEEE Registration Authority. The owner of the OUI (company, accredited standards organization, or industry group) shall be responsible for defining the meaning and usage of the remainder of the data payload in the stream packet.
148
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The meaning and usage of the version field shall be defined by the owner of specifier_ID.
6.2.4.3 Loose vs. strict isochronous packet reception Although this standard previously prohibited the reception of an isochronous stream packet outside of the isochronous period (strict isochronous), a significant number of contemporary serial bus link designs relax this requirement and permit the reception of an isochronous stream packet at any time (loose isochronous). The strict isochronous requirement is removed; link designs compliant with this standard shall be capable of receiving stream packets (primary packets identified by tcode A16) without regard to whether or not the packet falls within or without the isochronous period. NOTE—It is possible for an isochronous packet properly transmitted by one node (i.e., during the isochronous period) to be observed by another node during the asynchronous period. This can happen if the cycle start packet is not received correctly. In this case, the reception of isochronous packets at any time is sensible, even without consideration of asynchronous streams. Many applications are able to make valid use of isochronous data that follows, so long as the link permits its reception
6.2.5 Primary packet components This subclause describes the component fields and codes of primary packets.
6.2.5.1 Reserved fields, codes, and values Reserved codes and reserved fields within a packet are reserved by this standard for future expansion. All reserved fields shall be set to zero by the sender of the packet. Reserved or invalid values for a field shall not be used by the sender of a packet. The appropriate responses to a reserved or unimplemented transaction code value, a reserved or unimplemented extended transaction code value, a reserved response code value, or an unimplemented or invalid length value are defined in the transaction layer (see 7.3.3.1). The receiving link shall ignore any nonzero reserved fields. NOTE—Reserved fields only occur in response packets
6.2.5.2 Destination address The destination address is a concatenation of two fields, the destination ID and the destination offset.
6.2.5.2.1 Destination ID (destination_lD) The destination ID field shall specify the node_ID of the receiving node, and it is also the concatenation of two fields. The upper 10 bits of the destination ID specify the destination_bus_ID. The lower 6 bits of the destination ID specify the destination_physical_ID. Table 6-8 describes the encoding of the destination ID field and special meanings of certain bus_ID and physical_ID values.
6.2.5.2.2 Destination offset (destination_offset) The destination offset field shall specify the lower 48 bits of the destination node address of a request packet. For the read request for data quadlet and the write request for data quadlet packets, the destination_offset value shall be a quadlet aligned address.
Copyright © 2008 IEEE. All rights reserved.
149
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 6-8—Destination ID encoding destination_bus_ID
destination_physical_ID
Comment
0 to 3FE16
0 to 3E16
The destination_ID is addressed to a specific node on a specific bus. Only the node with a node_ID equal to the destination_ID shall respond to or acknowledge the packet.
3FF16
0 to 3E16
The destination_ID is addressed to a specific node on the local bus. Only the node with an physical_ID equal to the destination_physical_ID shall respond to or acknowledge the packet.
0 to 3FE16
3F16
The destination_ID specifies a broadcast to a specific bus. Only nodes with a bus_ID equal to the destination_bus_ID shall recognize the packet.
3FF16
3F16
The destination_ID specifies a broadcast to the local bus. All nodes on the local bus shall recognize the packet.
6.2.5.3 Transaction label (tl) The transaction label shall specify a unique tag for each outstanding transaction from a node. The transaction label sent in a request subaction shall be used as the transaction label returned in the corresponding response subaction. All transaction label values are valid, and all values shall be accepted by all devices. A node is shall not originate a request with a transaction label of N to another node with the node_ID of M if the requesting node has another request outstanding to node M that uses the transaction label N value. A transaction is considered outstanding if a transaction response has not been received within a transaction timeout period as discussed in 7.2.1 and if a bus reset has not occurred. NOTE—Each transaction is uniquely identified by the source ID of the requesting node, the destination ID of the responding node, and the transaction label.
During a bus reset, all nodes shall discard currently queued asynchronous requests and responses, so that all transaction label values can be safely reused. The behavior of the responding node is not defined by this standard when the requesting node violates these restrictions.
6.2.5.4 Retry code (rt) The encoding for the retry code (rt) in an asynchronous primary packet is given in Table 6-9. Requirements for the usage of rt are also specified. The rules for the usage of the retry code are specified by 7.3.5.
6.2.5.5 Transaction code (tcode) The transaction code shall specify the packet format and the type of transaction that shall be performed. If the addressed node detects a reserved or unsupported transaction code, it shall ignore the packet. See Table 6-10.
150
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 6-9—Retry code encoding Value
Name
Comment
0
retry_1
Reservation requested; transmitter implements outbound dual-phase retry.
1
retry_X
No reservation requested.
2
retry_A
Reservation previously assigned by the receipt of ack_busy_A; transmitter implements outbound dual-phase retry.
3
retry_B
Reservation previously assigned by the receipt of ack_busy_B; transmitter implements outbound dual-phase retry.
Table 6-10—Transaction code encoding
Code
Header size (quadlets)
Name
0
5
Write request for data quadlet
Request subaction, quadlet payload
1
5
Write request for data block
Request subaction, block payload
2
4
Write response
Response subaction for both write requests types, no payload
3
—
Reserved
—
4
4
Read request for data quadlet
Request subaction, no payload
5
5
Read request for data block
Request subaction, quadlet (data_length) payload
6
5
Read response for data quadlet
Response subaction to read request for quadlet, quadlet payload
7
5
Read response for data block
Response subaction to read request for block, block payload
8
5
Cycle start
Request to start isochronous period, quadlet payload
9
5
Lock request
Request subaction, block payload
A16
2
Stream data
Asynchronous or isochronous subaction, block payload
B16
5
Lock response
Response subaction for lock request, block payload
C16
—
—
Reserved for future standardization
D16
—
—
Reserved for future standardization
E16
—
—
Utilized internally by some link designs; not to be standardized
F16
—
—
Reserved for future standardization
Copyright © 2008 IEEE. All rights reserved.
Comment
151
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.2.5.6 Priority (pri) The priority field is a 4-bit value that only has meaning for the backplane PHY. See 5.4.2.1 and 5.4.1.3 for more details. All priority values are valid, and all values shall be accepted by all devices. Link layers attached to cable PHY devices shall ignore this field when receiving, and they shall set this field to 00002 when originating any asynchronous packet except cycle start (see 6.2.2.2.3). For all environments, a priority value of all zeros corresponds to the fair arbitration mechanism and all ones to the highest priority with fairness disabled. The link layer shall not alter the priority value. All priority values shall be passed through the link layer unaltered in order to facilitate bridging between the cable and the backplane environments.
6.2.5.7 Source ID (source_ID) The source ID field shall specify the node_ID of the sending node. The source ID value of a request subaction shall be used as the destination ID value for the corresponding response subaction, if any.
6.2.5.8 Data length (data_length) The data length field shall specify the length of the data field of data block payload packets and isochronous data block packets. The data length field may have specific limits on allowed values (see 6.2.2.3 6.2.3.2and 6.2.2.3.2). If the receiving link detects an invalid or unsupported data length field in a nonbroadcast primary packet, it shall either immediately return a type_error acknowledge code or return a type_error response code during a later response subaction.
6.2.5.9 Extended transaction code (extended_tcode) The extended_tcode is a 16-bit field that is only meaningful if the transaction code indicates a lockrequest or lock-response primary packet type. For all other packet types, this field is reserved and shall be set to 000016. See 7.3.3.2.1 for the definition of lock transactions. This field uses the encoding shown in Table 6-11.
Table 6-11—Extended transaction code encoding Code
152
Name
0000
Reserved
0001
mask_swap
0002
compare_swap
0003
add_big
0004
add_little
0005
bounded_add_big
0006
wrap_add_big
0007
bus-dependent
0008
allocate_big
0009
allocate_little
000A-FFFF16
Reserved
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
6.2.5.10 Response code (rcode) The response code shall specify the response to an earlier corresponding request subaction. See Table 6-12.
Table 6-12—Response code encoding Code
Name
Comment
0
resp_complete
1
Reserved
2
Reserved
3
Reserved
4
resp_conflict_error
A resource conflict was detected. The request may be retried.
5
resp_data_error
Hardware error, data are unavailable.
6
resp_type_error
A field in the request packet header was set to an unsupported or incorrect value, or an invalid transaction was attempted (e.g., a write to a read-only address).
7
resp_address_error
The destination offset field in the request was set to an address not accessible in the destination node.
8 to F16
The node has successfully completed the command.
Reserved
6.2.5.11 Data field The data field shall contain the data to be transferred in a primary packet with a data block payload. If the data length field specifies a length that is not a multiple of four, the sender shall pad the data field with 0016 bytes such that the data field is composed of full quadlets.
6.2.5.12 Tag (isochronous stream packets) The tag field provides a label, useful to applications, that specifies the format of the payload carried by an isochronous stream packet. The values defined for tag in Table 6-13 only apply to isochronous stream packets; permissible values of tag for asynchronous stream packets are defined in 6.2.4.1. Because it is necessary to allocate different channel numbers for asynchronous and isochronous stream packets, the context in which to interpret tag is unambiguous.
6.2.5.13 Channel The channel field shall specify the isochronous channel number for the packet. A channel field value shall not be repeated within a single isochronous cycle. The channel number is assigned to a node for talking or listening by the IRM. Channel numbers 0 through 63 are available for assignment.
Copyright © 2008 IEEE. All rights reserved.
153
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 6-13—Tag field encoding Value
Meaning
0
Data field format unspecified
1
Data format and sy field specified by IEC 61883-1
2
Reserved for future standardization
3
Reserved for future standardization
6.2.5.14 Synchronization code (sy) The synchronization code is an application-specific control field. The details of its use are beyond the scope of this standard. NOTE—A synchronization point may be the defined as boundary between video or audio frames, or any other point in the data stream the application may consider appropriate.
6.2.5.15 CRCs Both the header CRC and the data CRC are generated and checked using a standard algorithm.15 The MSB [the x31 term of R(x)] of the CRC shall be transmitted first.
6.2.5.15.1 Definitions F(x) A degree k-1 polynomial that is used to represent the k bits of the packet covered by the CRC. For the purposes of the CRC, the coefficient of the highest order term shall be the first bit transmitted. L(x)
A degree 31 polynomial with all of the coefficients equal to one, i.e., L(x) = x31 + x30 + x29 + … x2 + x1 + 1
G(x)
The standard generator polynomial: G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
R(x)
The remainder polynomial that is of degree less than 32.
P(x)
The remainder polynomial on the receive checking side that is of degree less than 32.
CRC
The CRC polynomial that is of degree less than 32.
Q(x)
The greatest common multiple of G(x) in [x32F(x) + xkL(x)].
Q*(x) x32Q(x). M(x) The sequence that is transmitted. M*(x) The sequence that is received. 15
This is the same CRC used by the IEEE 802 LANs and FDDI. The remainder of this clause was extracted from Chapter 7 of the ANSI FDDI Media Access Control specification.
154
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
C(x)
IEEE Std 1394-2008
A unique polynomial remainder produced by the receiver upon reception of an error-free sequence. This polynomial has the value: C(x) = x32L(x)/G(x) C(x) = x31 + x30 + x26 + x25 + x24 + x18 + x15 + x14 + x12 + x11 + x10 + x8 + x6 + x5 + x4 + x3 + x + 1
6.2.5.15.2 CRC generation equations The equations that are used to generate the CRC sequence from F(x) are CRC = L ( x ) + R ( x ) = R$ ( x ) where R$(x) is the ones complement of R(x). 32
k
[ x F(x ) + x L( x) ] ⁄ G(x ) = Q( x ) + R(x ) ⁄ G( x) 32
M ( x ) = [ x F ( x ) ] + CRC NOTE—All arithmetic is modulo 2. Equation (1), adding L(x) (all ones) to R(x), simply produces the ones complement of R(x); thus, this equation is specifying that the R(x) is inverted before it is sent out. Equation (3) simply specifies that the CRC is appended to the end of F(x).
6.2.5.15.3 CRC checking The received sequence M*(x) may differ from the transmitted sequence M(x) if there are transmission errors. The process of checking the sequence for validity involves dividing the received sequence by G(x) and testing the remainder. Direct division, however, does not yield a unique remainder because of the possibility of leading zeros. Thus, a term L(x) is prepended to M*(x) before it is divided. Mathematically, the received checking is shown in the following equation: 32
k
x [ M ( x ) + x L ( x ) ] ⁄ G ( x ) = Q∗ ( x ) + P ( x ) ⁄ G ( x ) In the absence of errors, the unique remainder is the remainder of the division: 32
P(x) ⁄ G(x) = x L(x) ⁄ G(X) = C(X) Table 6-17 includes a C program of the generating and checking algorithms.
6.2.6 Acknowledge packets An acknowledge packet shall be sent by a destination node as the immediate response to a nonbroadcast or nonisochronous primary packet. An acknowledge packet is distinguished from a primary packet by its length, which shall be exactly 1 byte.
Copyright © 2008 IEEE. All rights reserved.
155
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.2.6.1 Acknowledge packet format Every acknowledge packet shall consist of a single byte of data, where the first 4 bits transmitted shall contain the acknowledge code (ack_code), and the 4 bits transmitted shall contain the acknowledge parity (ack_parity). The format of an ACK packet is shown by Figure 6-20.
Figure 6-20—Acknowledge packet format 6.2.6.2 ACK packet components This subclause describes the component fields and codes of acknowledge packets. Note that in tables that give the code values for a field, the leftmost bit of the code is transmitted first.
6.2.6.2.1 Reserved acknowledge codes Reserved codes within an acknowledge packet are reserved by this standard for future expansion. Reserved ack_code values shall not be used by a transmitting link. The receiving link shall check all fields for reserved code values. If the receiving link detects a reserved ack_code, the acknowledge packet shall be ignored, and a request status of ACKNOWLEDGE MISSING shall be presumed (see 6.1.2.2).
6.2.6.2.2 Acknowledge code (ack_code) The acknowledge code shall specify the immediate response to a nonbroadcast primary packet. The allowable acknowledge codes are listed in Table 6-14.
Table 6-14—Acknowledge codes Code
156
Name
Comment
0
—
Not to be used in any future serial bus standard.
1
ack_complete
The node has successfully accepted the packet. If the packet was a request subaction, the destination node has successfully completed the transaction and no response subaction shall follow.
2
ack_pending
The node has successfully accepted the packet. If the packet was a request subaction, a response subaction is expected at a later time. This code shall not be returned for a response subaction.
3
—
Reserved for future standardization.
4
ack_busy_X
The packet could not be accepted. The destination transaction layer may accept the packet on a retry of the subaction.
5
ack_busy_A
The packet could not be accepted. The destination transaction layer may accept the packet in accordance with the retry protocol specified by 7.3.5.
6
ack_busy_B
The packet could not be accepted. The destination transaction layer may accept the packet in accordance with the retry protocol specified by 7.3.5.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 6-14—Acknowledge codes (continued) Code 7 –A16
Name
Comment
—
Reserved for future standardization.
B16
ack_tardy
The node could not accept the packet because the link and higher layers are in a suspended state; the destination node shall restore full functionality to the link and transaction layers and may accept the packet on a retransmission in a subsequent fairness interval.
C16
ack_conflict_error
A resource conflict prevented the packet from being accepted.
D16
ack_data_error
The node could not accept the block packet because the data field failed the CRC check or because the length of the data payload did not match the length contained in the data_length field. This code shall not be returned for any packet whose header does not contain a data_length field.
E16
ack_type_error
A field in the request packet header was set to an unsupported or incorrect value, or an invalid transaction was attempted (e.g., a write to a read-only address).
F16
ack_address_error
The node could not accept the packet because the destination_offset field in the request was set to an address not accessible in the destination node.
An ack_complete shall not be sent in response to a read or lock request. In addition to the uses of ack_busy_X, ack_busy_A, and ack_busy_B specified in Table 6-14, these acknowledge codes may be sent when the recipient of a packet desires its retransmission for other reasons. For example, packets with invalid data CRC or a mismatch between actual data payload and that specified by the data_length field are likely the result of transient conditions, which may not be present upon retransmission. Because link layer retry behavior after receipt of a busy acknowledgment is often implemented in hardware, one of ack_busy_X, ack_busy_A, or ack_busy_B should be used in place of other acknowledge or response codes that permit transaction layer retry of the entire transaction. A node that returns ack_busy_A or ack_busy_B in cases when sufficient resources are available may introduce unintended consequences. As specified by 7.3.5, the node would be prohibited from accepting packets unless their retry code matched the preferred retry phase—even though it suffers from no lack of resources. Therefore, a node that elects to return a busy acknowledgment instead of a terminal acknowledgment shall select one of ack_busy_X, ack_busy_A, or ack_busy_B according to Table 6-15.
Table 6-15—Busy acknowledgments Resources available
Retry code
Busy acknowledgment
—
retry_A
ack_busy_A
retry_B
ack_busy_B
retry_X
ack_busy_X
Yes
retry_1
No
retry_1
Copyright © 2008 IEEE. All rights reserved.
ack_busy_A / ack_busy_B (per 7.3.5)
157
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Although a resource conflict or an address error in a request packet is usually detected by the transaction or higher-application layer, there may be circumstances in which the link is capable of detecting these errors within the time permitted for a unified response to a request subaction. The acknowledge codes ack_conflict_error and ack_address_error are defined to provide the same utility as the existing resp_conflict_error and resp_address_error. The ack_tardy code has been defined to enable low-power consumption states for serial bus devices. Such a device may be able to place its link layer in a partially functional state and suspend the transaction and all higher-application layers. The link layer shall be able to recognize nonbroadcast request packets whose destination_ID addresses the suspended node. Upon recognition of such a packet, the link shall send an ack_tardy and shall initiate the resumption of full link and transaction layer functionality. The recipient of an ack_tardy may retransmit the request packet in a subsequent fairness interval. The time required for the link and transaction layers to become fully operational is implementation dependent. NOTE—Transactions are completed by either an ack_pending and a subsequent response packet, or by an acknowledgment other than ack_pending, ack_busy_X, ack_busy_A, or ack_busy_B. At the transaction layer both methods are equivalent and the same criteria shall be used in either case to select the appropriate acknowledgment or response code. However, responses conveyed by acknowledge packets are preferred over separate response packets, since the former utilize less serial bus bandwidth.
6.2.6.2.3 Acknowledge parity (ack_parity) The acknowledge parity field shall specify the parity check bits for an acknowledge packet. The value of the acknowledge parity field shall be the ones complement of the acknowledge code. If the receiving link detects an acknowledge parity error (the ack_parity field is not the ones complement of the ack_code), the acknowledge packet shall be ignored, and a request status of ACKNOWLEDGE MISSING shall be presumed (see 6.1.2.2).
6.3 Link layer operation This subclause defines how the link layer attempts to initiate the transmission of a packet, and how the link layer receives a packet. This subclause makes extensive reference to the PHY layer services described in Clause 4 and Clause 5.
6.3.1 Overview of link layer operation This subclause gives an informal overview of link layer operations. The descriptions in this subclause are informative and nonbinding. The formal description of behavior is in 6.3.3.
6.3.1.1 Communication with the PHY layer The link layer communicates via a set of abstract services. These abstract services provide a means of documenting the information that moves between the link layer and PHY layer. Two subsets of services are defined: the PHY arbitration services and the PHY data services. The PHY arbitration services allow the link layer to gain control of the bus. The PHY arbitration request service is communicated from the link layer to the PHY layer to request control of the bus. The request contains information regarding the type of arbitration to perform. The PHY layer communicates back a PHY arbitration response service, which contains information regarding the success or failure of the request. Arbitration services are communicated in a manner that is independent of the PHY data services. The PHY data services are used to communicate data symbols between the PHY and link layers. The PHY layer controls when data will be presented to the link layer, and it also controls when the link layer may
158
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
present data to the PHY layer. The PHY layer communicates data to the link layer via the PHY data indication service. Each communication of this service presents one data symbol (a data bit or other bus symbol) to the link layer. The flow of information in the other direction is a two-step process. First, the PHY layer allows the link layer to send one data symbol by communicating the PHY Clock indication service to the link layer. The link layer responds by communicating a PHY data request to the PHY layer, which communicates the data symbol to the PHY layer. The PHY Clock indication carries no information other than the permission to the link layer to send the data symbol. See Clause 17 for a detailed specification of the PHY-link interface.
6.3.1.2 Priority arbitration for PHY packets and response packets When transmitting a PHY packet or a response packet, a link may use priority arbitration requests. If the node implements the PRIORITY_BUDGET register (see 8.3.2.3.5), priority requests for PHY packets may count but response packets shall not count against the node’s priority arbitration budget. A PHY packet is any 64-bit packet whose 32 LSBs are the ones complement of the 32 MSBs. A response packet is an asynchronous primary packet with a tcode of 2, 6, 7, or B16. If an ack_busy_X, ack_busy_A, or ack_busy_B is received in acknowledgment of a response packet, the node shall not retransmit the response packet until the next fairness interval.
6.3.1.3 Sending an asynchronous packet The link layer sends an asynchronous packet when the transaction layer requests it via the link data request service. The link layer constructs the appropriate packet format and requests the PHY layer to arbitrate for the bus via the PHY arbitration request service. If the arbitration is lost, the link layer tries again at a later time; note that a lost arbitration is usually followed by an incoming packet to be received. After the arbitration is won, the link layer communicates the packet to be sent to the PHY layer via the PHY data request service. The packet ends when the link layer communicates a data end symbol to the PHY layer. After the packet is sent, the link layer will usually expect an acknowledge to be returned. The acknowledge is communicated from the link layer to the transaction layer via the link data confirmation service. If the acknowledge is not valid, or if it is not received within a time-out period, the link layer considers the acknowledge missing. The link layer does not expect an acknowledge if the packet was a broadcast packet.
6.3.1.4 Receiving an asynchronous packet The link layer receives an asynchronous packet when the PHY layer starts communicating data to the link layer via the PHY data indication service. The link layer detects the end of packet when the PHY layer communicates an ending symbol to the link layer. The link layer examines the packet length and packet components to determine whether the packet is valid and is addressed to this node. If the packet is not valid (e.g., the header CRC check failed) or is not addressed to this node, the link layer ignores the packet. If the packet is valid and is addressed to this node, the link layer communicates the packet components to the transaction layer via the link data indication service. After receiving a valid packet, the link layer will usually return an acknowledge to the sending node. The acknowledge code is specified to the link layer by the transaction layer via the link data response service. The link layer sends the acknowledge by requesting that the PHY layer do an immediate arbitration. The link layer then communicates the acknowledge to the PHY layer. The acknowledge ends when the link layer communicates a data end symbol to the PHY layer. The link layer does not send an acknowledge if the packet was a broadcast packet.
Copyright © 2008 IEEE. All rights reserved.
159
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.3.1.5 Sending an acknowledge concatenated to an asynchronous packet The link layer may concatenate a response packet to the acknowledge described 6.3.1.4. This occurs when the transaction layer asks the link layer to hold the bus by setting Bus Occupancy Control in the link data response service to HOLD. In this case, the link layer ends the acknowledge by sending a data prefix to the PHY layer. This causes the PHY layer to hold the bus for sending another packet. After a delay time, and after the transaction layer communicates the response packet to the link layer via the link data request service, the link layer begins communicating the packet to the PHY layer, ending with a data end symbol. The link layer expects an acknowledge as described above.
6.3.1.6 Isochronous cycles An isochronous cycle begins when the cycle master notes that a NOMINAL_CYCLE_TIME has elapsed since the last isochronous cycle began. The cycle master link layer then arbitrates and sends a cycle start packet as described in 6.3.3.3. The end of the cycle start packet begins an isochronous cycle. During an isochronous cycle only isochronous packets shall be transmitted. Note that the arbitration rules prevent the transmission of any asynchronous packets during an isochronous cycle. Furthermore, between the time an isochronous cycle ends and the next isochronous cycle begins, no isochronous packets shall be transmitted. An isochronous cycle ends when a subaction gap is detected by the PHY layer. Note that the transaction layer does not manage isochronous transfers.
6.3.1.7 Sending isochronous packets An application should queue the transmission of isochronous packets when the link cycle sync indication is generated by the link layer. When there is data in this queue and a cycle start packet is received, the bus is requested using a PHY arbitration request with an arbitration class of ISOCHRONOUS. If the arbitration is lost, the link layer tries again at a later time; note that a lost arbitration is usually followed by an incoming packet to be received. After the arbitration is won, the actual sending of the packet is the same as for an asynchronous packet: the packet is constructed in the appropriate format and is communicated to the PHY layer via the PHY data request service. The packet is ended when the link layer communicates a data end symbol to the PHY layer. When the link layer has more than one isochronous packet to send during an isochronous cycle (sent to different channels), it shall arbitrate and send the first packet, and it then should concatenate subsequent isochronous packets until all channels are sent. This avoids the need to re-arbitrate for each packet. To concatenate, the link layer ends an isochronous packet by sending data prefix symbols to the PHY layer for a delay time; the link layer does not send a data end symbol. The link layer then communicates the next isochronous packet to the PHY layer. The last isochronous packet ends normally with a data end symbol. There is no requirement to queue data packets during bus reset (between PHY events of BUS_RESET_START and BUS_RESET_COMPLETE). Data may be lost during these events, since this will always take more than a single 125 μs cycle period (typically about 200 μs). The application has to be able to tolerate missing data during this interval.
6.3.1.8 Receiving an isochronous packet The link layer receives an isochronous packet when the PHY layer starts communicating data (via the PHY data indication service) to the link layer during an isochronous cycle. The link layer will receive isochronous packets if it has been configured as a listener by an application. The link layer detects the end of packet when the PHY layer communicates an ending symbol to the link layer. The link layer examines the packet
160
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
length and packet components to determine whether the packet is valid and is addressed to a channel to which this node is listening. If the packet is not valid (e.g., the header CRC check failed) or is not addressed to an active channel on this node, the link layer ignores the packet. If the packet is valid and is addressed to a channel on this node, the link layer communicates the packet components to the appropriate application via the link isochronous indication service. After receiving a packet, the link layer does not return an acknowledge to the sending node.
6.3.2 Cycle sync event If the link layer is capable of sending or receiving isochronous packets or is capable of being the cycle master, it shall generate a local cycle sync event. The generation of the cycle sync event is done using the procedure described by the C-like code in Table 6-16.
Table 6-16—Cycle sync event code boolean cycle_synch_queued; //
the cycle sync event has occurred
struct { seconds_count : 7, cycle_count : 13, cycle_offset : 12 } CYCLE_TIME;
// // //
count of seconds count of cycles (1/8000) second count of 1/24.576 microsecond periods after last event
generate_cycle_synch_event(); // invoked every 1/24.576 microseconds { if (cycle_offset == 3071) // 125 microseconds have elapsed { cycle_offset = 0; if (cycle_count == 7999) { seconds_count = seconds_count + 1; cycle_count == 0; } else { ++cycle_count; } LK_CYCLE.ind(); // notify the application of a cycle sync if (STATE_SET.cmstr) // if the node is the cycle master cycle_synch_queued = TRUE ; // queue the cycle sync event } else { ++cycle_offset; } } // end generate_cycle_synch_event
The procedure generate_cycle_synch_events is invoked every 1/24.576 μs (±100 ppm). The variable cycle_synch_queued is used to queue the cycle start for the link layer packet transmit/receive state machine described in 6.3.3. The structured variable CYCLE_TIME is the CYCLE_TIME register described in 8.3.2.2.8 and the STATE_SET.cmstr bit is described in 8.3.1.6. The CYCLE_TIME register is also set by reception of a cycle start packet as described in 6.2.2.2.3.
Copyright © 2008 IEEE. All rights reserved.
161
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.3.3 Details of link layer operation The operation of the link layer packet transmitter and receiver is described by the state machine in Figure 6-21.
Figure 6-21—Link layer packet transmit/receive state machine
162
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
6.3.3.1 Link initialization Transition A11:L0. The link layer shall transition from any other link layer state to state L0 when a link Control request with an action of Initialize is communicated from the node controller. Transition A11:L14. The link layer shall transition from any other link layer state to state L14 when a link Control request with an action of Reset is communicated from the node controller. State L14. The link layer is suspended. The link layer shall only leave state L14 via transition A11:L0.
6.3.3.2 Asynchronous operation State L0: Asynchronous operation ready. The link layer is ready to send or receive asynchronous packets. The link layer shall not send or receive isochronous packets. Any link isochronous requests received by the link layer shall be deferred until the link layer enters state L10. Transition L0:L1. The link layer shall construct the appropriate asynchronous packet format (as described in 6.2) based on parameters specified by the transaction layer in the link data request. The link layer shall communicate a PHY arbitration request to the PHY layer, using the arbitration class specified by the transaction layer. Transition L0:L4. The link layer shall begin receiving data from the PHY layer when it receives a PHY data indication with data of DATA_START. Transition L0:L8. An isochronous cycle shall only be requested by a cycle master. When the link layer of the cycle master queues a local cycle sync event (see 6.3.2), the link layer shall communicate a PHY arbitration request to the PHY layer, using an arbitration class of CYCLE_MASTER State L1: Asynchronous arbitration. The link layer shall wait for a PHY arbitration confirmation from the PHY layer. Transition L1:L0. The link layer receives a PHY arbitration confirmation. If the arbitration request status is LOST, the link layer may rearbitrate at a later time, subject to the rules for the arbitration method used. NOTE—A lost arbitration is usually followed by an incoming packet to be received by the link layer, as described in Transition L0:L4.
Transition L1:L2. The link layer receives a PHY arbitration confirmation. If the arbitration request status is WON, the link layer shall immediately begin communicating PHY data requests to the PHY layer following each PHY Clock indication received by the link layer. State L2: Asynchronous send packet. The link layer shall continue sending PHY data requests until all of the packet is transmitted. Transition L2:L0. The link layer shall end the broadcast packet by communicating a PHY data request with data of DATA END to the PHY layer. The time between the first PHY arbitration confirmation of WON and the final PHY data request of DATA_END shall be no greater than a time of MAX_BUS_OCCUPANCY. When the transaction layer specifies the asynchronous packet as a broadcast packet, the link layer shall not expect an acknowledge packet to be returned by a destination node. The link layer shall communicate a link data confirmation with a request status of BROADCAST SENT to the transaction layer. Transition L2:L3. The link layer shall end the nonbroadcast packet by communicating a PHY data request with data of DATA END to the PHY layer. The time between the first PHY arbitration confirmation of WON and the final PHY data request of DATA_END shall be no greater than a time of MAX_BUS_OCCUPANCY. When the transaction layer specified the asynchronous packet was not a
Copyright © 2008 IEEE. All rights reserved.
163
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
broadcast packet, then the link layer shall expect an acknowledge packet to be returned by the destination node. State L3: Wait for acknowledge. The link layer shall wait for either a PHY data indication of SUBACTION_GAP or a PHY data indication of DATA_START. The link layer shall begin receiving the acknowledge packet from the PHY layer when it receives a PHY data indication with data of DATA START. The link layer shall detect the end of the acknowledge packet when it receives a PHY data indication with data of DATA END or DATA PREFIX. If the packet length was one byte, and the ack_code field EXCLUSIVE-ORed with the ack_parity field equal to 11112, the packet is an acknowledge packet. Otherwise, the acknowledge packet shall be ignored by the link layer. Transition L3:L0a. If the link layer receives a PHY data indication with a data of SUBACTION GAP before receiving an acknowledge packet, the link layer shall communicate a link data confirmation with request status of ACKNOWLEDGE_MISSING to the transaction layer. Transition L3:L0b. If the link layer receives an acknowledge packet, it shall communicate a link data confirmation with a request status of ACKNOWLEDGE_RECEIVED, and it shall communicate the appropriate acknowledge to the transaction layer (see Table 6-14). State L4: Asynchronous Receive packet. The link layer shall continue to receive the packet until it detects the end of the packet. The end of the packet shall be detected when the link layer receives a PHY data indication with data of DATA_END or DATA_PREFIX. The link layer shall examine the length of the packet, the transaction code field, and the data length field to determine the packet format so that the header and data CRC can be calculated and checked. The link layer should communicate the PHY arbitration request (with an arbitration class of IMMEDIATE) as soon as possible after it verifies that the destination_ID in the packet header addresses this node (see transition L4:L5 below), in anticipation of sending an acknowledge packet in state L6. The PHY layer shall respond with a PHY arbitration confirmation of WON. NOTE—The arbitration should be done while the packet is being received to reduce the latency between the end of a packet and the acknowledge, and to meet the acknowledge_delay requirement.
Transition L4:L0a. If the destination_ID field indicates that this is a broadcast packet (see 6.2.5.2.1), the link layer shall consider the transaction complete and perform the requested action. If the destination_ID indicates the node shall not accept the packet, the link layer shall ignore the packet. Transition L4:L0b. If the packet length is 1 byte, the packet is an acknowledge packet and shall be ignored by the link layer. If the transaction code indicates that the packet is an isochronous data block packet, or that the header CRC check failed, the packet shall be ignored by the link layer. If the header CRC check failed, or an unknown or unexpected transaction code (such as isochronous data block) is detected, the link layer shall communicate the appropriate link event indication to the transaction layer. If the received packet is longer than allowed by the MAX_BUS_OCCUPANCY time, and if the link layer is capable of detecting this, the link layer shall communicate the appropriate link event indication to the transaction layer. If the link layer had requested an immediate arbitration (see state L4 above), it shall communicate a PHY data request of DATA_END to cause a release of the bus. NOTE—In state L4, the link layer requested the PHY layer to gain immediate control of the bus in anticipation of sending an acknowledge. Since the link layer cannot send an acknowledge in this transition, it shall direct the PHY layer to release the bus immediately.
If the destination_ID indicates that the node shall not accept the packet (see 6.2.5.2.1), the packet shall be ignored by the link layer.
164
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition L4:L5. If the packet length is a multiple of one quadlet, and the header CRC checks, the link layer shall interpret the packet as a primary packet. If the destination_ID indicates that the node shall accept the packet (see 6.2.5.2.1), and if the transaction code indicates that the packet is not a cycle start packet or an isochronous data block packet, the link layer shall communicate a link data indication to the transaction layer. Transition L4:L10. If the packet is a cycle start packet, the link layer shall enter an isochronous cycle. The link layer shall immediately update the value of the CYCLE_TIME register to the quadlet contained in the data field of the received packet. State L5: Wait for response (from transaction layer). The link layer shall wait for a link data response to be communicated from the transaction layer. The transaction layer shall communicate the link data response such that the time from the end of the received packet to the data prefix of the acknowledge packet on the bus is no greater than an ACK_RESPONSE_TIME plus the appropriate arb_delay. The link layer shall continue to hold the bus by communicating PHY data requests with data of DATA_PREFIX to the PHY layer following each PHY Clock indication received by the link layer. Transition L5:L6. When the transaction layer communicates a link data response, the link layer shall immediately send an acknowledge packet with the acknowledge code specified in the service. State L6: Send acknowledge. When the link layer receives a link data response from the transaction layer, the link layer shall send the acknowledge by immediately communicating PHY data requests to the PHY layer following each PHY Clock indication received by the link layer. The link layer shall continue sending PHY data requests until all of the acknowledge packet is transmitted. The link layer may hold the bus by communicating PHY data requests with data of DATA_PREFIX prior to sending the acknowledge packet data. Transition L6:L0. If the Bus Occupancy Control parameter of the link data response is RELEASE, the link layer shall end the acknowledge packet by communicating a PHY data request with data of DATA_END to the PHY layer. The time between the end of the received packet and the final PHY data request of DATA_END of the acknowledge shall be no greater than a time of DATA_END_TIME. The link layer shall consider the subaction complete. Transition L6:L7. If the Bus Occupancy Control parameter of the link data response is HOLD, the link layer shall end the acknowledge packet by communicating a PHY data request with data of DATA_PREFIX to the PHY layer. The time between the first PHY arbitration confirmation of WON and the final PHY data request of DATA_PREFIX shall be no greater than a time of DATA_PREFIX_TIME. The link layer shall consider the subaction complete. State L7: Hold Bus (for Concatenated response). The link layer shall wait for a link data request to be communicated from the transaction layer. The transaction layer should communicate the link data request such that the time from the end of acknowledge packet to the first data symbol of the response packet on the bus is no greater than a data_prefix_time. An acknowledge packet may be concatenated to a single following asynchronous response packet type, provided the response packet is the response associated with the acknowledge packet. In other words, a response packet for a transaction shall not be concatenated with an acknowledge packet for a different transaction. Another packet shall not be concatenated following the response packet.
Copyright © 2008 IEEE. All rights reserved.
165
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Transition L7:L2. When the transaction layer communicates a link data request, the link layer shall immediately send a response packet. Transition L7:L0. When the transaction layer fails to communicate link data request within a data_prefix_time, the link layer shall release the bus by communicating a PHY data request with data of DATA END to the PHY layer. NOTE—When the link data request finally arrives, the link layer treats it as a new subaction that completes a split transaction.
6.3.3.3 Isochronous operation State L8: Cycle start arbitration. The link layer shall wait for a PHY arbitration confirmation from the PHY layer. Transition L8:L0. The link layer receives a PHY arbitration confirmation of LOST; the link layer may rearbitrate at a later time. NOTE—If arbitration were instantaneous, the cycle master would never lose cycle start arbitration. However, since arbitration does take a finite amount of time, this state transition allows implementations to present the LOST status to the link if a grant occurs at the same time the link asks for a cycle start. The lost arbitration is usually followed by an incoming packet to be received by the link layer.
Transition L8:L9. The link layer receives a PHY arbitration confirmation of WON and shall immediately begin communicating PHY data requests to the PHY layer following each PHY Clock indication received by the link layer. State L9: Send cycle start. The link layer shall continue sending PHY data requests until all of the cycle start packet is transmitted. The cycle_time_data field transmitted shall be the value of the CYCLE_TIME register at the instant that transition L8:L9 is taken. Transition L9:L10. The link layer shall end the cycle start packet by communicating a PHY data request with data of DATA END to the PHY layer. The time between the first PHY arbitration confirmation of WON and the final PHY data request of DATA_END shall be no greater than a time of MAX_BUS_OCCUPANCY. The link layer shall not expect an acknowledge packet to be returned by a destination node. The link layer shall not confirm to any layer that the packet was sent. State L10: Isochronous operation ready. The link layer shall consider that an isochronous cycle has begun immediately after the request for cycle start packet is sent (if the node is a cycle master) or when the request for cycle start packet is received (all other nodes). The link layer is ready to send or receive isochronous packets. The link layer shall not send or receive asynchronous packets. Any link data requests received by the link layer shall be deferred until the link layer enters the L0 state. Transition L10:L0. When the link layer receives a PHY data indication with a data of SUBACTION_GAP, the link layer shall consider the isochronous cycle ended. If the time between transition L9:L10 or L4:L10 and L10:L0 is greater than NOMINAL_CYCLE_TIME, then a link event indication of CYCLE_TOO_LONG shall be generated. Transition L10:L11. When any link isochronous requests are pending, the link layer shall construct the appropriate isochronous packet format (as described in 6.2) based on parameters specified by the application layer in the request. The link layer shall communicate a PHY arbitration request to the PHY layer with an arbitration class of ISOCHRONOUS.
166
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTE—Implementations are free to do any kind of queuing of isochronous requests that makes sense for the application, as long as the bandwidth allocation (see 8.4.2.6) is not exceeded. A fully general implementation might queue requests between link cycle sync indications for transmission during the following isochronous cycle. Since the cycle start can be delayed almost a full NOMINAL_CYCLE_TIME from the preceding cycle sync, this implies that isochronous data requests may have to be queued for up to two cycles.
Transition L10:L13. The link layer shall begin receiving data from the PHY layer when it receives a PHY data indication with data of DATA_START. State L11: Isochronous arbitration. The link layer shall wait for a PHY arbitration confirmation from the PHY layer. Transition L11:L10. The link layer receives a PHY arbitration confirmation. If the arbitration request status is LOST, the link layer may rearbitrate at a later time within the isochronous cycle. Transition L11:L12. The link layer receives a PHY arbitration confirmation. If the arbitration request status is WON, the link layer shall immediately begin communicating PHY data requests to the PHY layer following each PHY Clock indication received by the link layer. State L12: Isochronous send packet(s). The link layer shall continue sending PHY data requests until all of the isochronous packet is transmitted. If the link layer has another isochronous packet to send, the link layer shall end the current packet by communicating a PHY data request with data of DATA_PREFIX to the PHY layer. The link layer shall communicate DATA_PREFIX for a data_prefix_delay. The link layer shall then send PHY data requests until all of the concatenated isochronous packet is transmitted. This procedure is repeated until all isochronous packets are sent. Transition L12:L10. If the current isochronous packet is the last packet to be sent, then the link layer shall end the packet by communicating a PHY data request with data of DATA_END to the PHY layer. The link layer shall not expect an acknowledge packet to be returned by a destination node. The link layer shall not confirm to the application layer that the packet was sent. State L13: Isochronous Receive packet. The link layer shall continue to receive the packet until it detects the end of the packet. The end of the packet shall be detected when the link layer receives a PHY data indication with data of DATA END or DATA PREFIX. The link layer shall examine the length of the packet, the transaction code field, and the data length field for purposes of calculating header and data CRC. Transition L13:L10. If the transaction code was not the value for an isochronous data block packet, the packet shall be ignored by the link layer. The rules of 6.2.5.1 also apply here. If the channel value does not match one of the values on the channel receive list (see 6.1.1.1), the packet shall be ignored by the link layer. When the link layer receives an isochronous packet with a channel value that matches one of the values on the channel receive list during an isochronous cycle, the link layer shall communicate a link isochronous indication to the application layer. If the channel value is not in the expected channel list (see 6.1.1.1) or is a duplicate of a channel number that has already been received this cycle, and if the node is the IRM, the link layer shall communicate the appropriate link event indication to the node controller.
Copyright © 2008 IEEE. All rights reserved.
167
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
6.4 Link layer reference code The code in Table 6-17 is an example implementation of the CRC generation and checking algorithm used by the link layer. It is informative in nature only.
Table 6-17—CRC generation and checking #define #define #define #define
MSB32 ONES32 CRC_COMPUTE CRC_RESULTS
((unsigned) 1<<31) 0XFFFFFFFF ((Quadlet) 0X04C11DB7) ((Quadlet) 0XC704DD7B)
typedef unsigned long Quadlet // where “long” is a 32-bit value // Generate the CRC for a packet containing “sizeInQuads” quadlet data values Quadlet GenerateCrc (Quadlet * inputs, int sizeInQuads) { Quadlet crcSum; assert (sizeInQuads >= 1);
//
size of packet including CRC
crcSum = CalculateCrc(inputs, sizeInQuads - 1); // compute CRc on just the data return (~crcSum); } // Validate the CRC for a packet containing “size” quadlet data values int ValidateCrc (Quadlet * inputs, int sizeInQuads) { Quadlet crcSum; assert (sizeInQuads >= 1);
//
size of packet including CRC
crcSum = CalculateCrc (inputs, sizeInQuads); // compute CRC on the data *and* the received CRC return (crcSum != CRC_RESULTS); } // The GenerateCrc() function points to protected values, // it checks these values and return a final 32-bit result Quadlet CalculateCrc (Quadlet * inputs, int sizeInQuads) { Quadlet inQuad, crcSum, newMask; int i, oldBit, newBit, sumBit; // The crcSum value is initialized to all ones crcSum = (Quadlet) 0XFFFFFFFF; // Process each of the quadlets covered by the CRC value for (i = 0, i < sizeInQuads; i += 1) { inQuad = inputs[i]; // Process each of the bits within the input quadlet value for (newMask = MSB32; newMask != 0; newMask >>= 1) { newBit = ((inQuad & newMask) != 0); // The next input bit
168
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 6-17—CRC generation and checking (continued) oldBit = ((crcSum & MSB32) != 0); // and MSB of crcSum sumBit = oldBit ^ newBit; // are EXOR’d together // Shift the old crcSum left and exclusive-OR the new newBit values crcSum = ((crcSum < 1) & ONES32) ^ (sumBit ? CRC_COMPUTE : 0); // “^” is X-OR } } return (crcSum); }
Copyright © 2008 IEEE. All rights reserved.
169
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
170
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
7. Transaction layer specification The transaction layer provides three operations for the transfer of data between nodes: a)
Write transaction—Data are transferred to an address in a different node.
b)
Read transaction—Data are retrieved from an address in a different node.
c)
Lock transaction—Data are sent to a different node, used to perform an indivisible function, and the results returned.
The transaction layer services may be multithreaded at the option of the implementor. This means that more than one transaction may be in process (pending) at the same time.
7.1 Transaction layer services Transaction layer services are provided at the interface between the transaction layer and higher layers, as illustrated in Table 7-1.
Table 7-1—Summary of transaction layer services Service
Layer communicated with
Purpose of service
Transaction control request
From the node controller
Configure the transaction layer
Transaction control confirmation
To the node controller
Confirm transaction control request
Transaction event indication
To the node controller
Alert node controller to events detected in the transaction layer
Transaction data request
From the application, node controller, or bus manager
Cause the transaction layer to initiate a transaction
Transaction data confirmation
To the application, node controller, or bus manager
Confirm transaction data request
Transaction data indication
To the application, node controller, or bus manager
Indicate the reception of a transaction request
Transaction data response
From the application, node controller, or bus manager
Respond to transaction data indication
The method by which these services are communicated between the layers is not defined by this standard. Transaction layer services may perform actions specified by the higher layer. Transaction layer services may also communicate parameters that may or may not be associated with an action.
7.1.1 Transaction layer bus management services for SBM These services are used by the node controller to control the resources of the transaction layer. The transaction layer uses these services to communicate events within the transaction layer or on the bus to the node controller.
Copyright © 2008 IEEE. All rights reserved.
171
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
7.1.1.1 Transaction control request (TR_CONTROL.request) The node controller uses this service to request the transaction layer to perform specific actions and to specify transaction layer parameters. The transaction layer shall service the request immediately upon receipt by the transaction layer. This service is confirmed. The following actions defined for all transaction layer implementations shall be provided by this service: —
Reset. The transaction layer shall discard all pending transactions. No transaction requests shall be accepted from the link layer or from any applications.
—
Initialize. The transaction layer shall discard all pending transactions. Transaction requests shall be accepted from the link layer and from applications.
The following parameters are communicated to the transaction layer via this service: —
Split transaction timeout value. This parameter shall contain the maximum time after sending a transaction request to the link layer (via a link data request) that a response will be accepted from the link layer (via a link data indication).
—
Transaction retry limit. This parameter shall contain the maximum number of times transmission of a transaction request packet or transaction response packet (via a link data request) will be retried upon receiving a busy acknowledge (via a link data confirmation).
7.1.1.2 Transaction control confirmation (TR_CONTROL.confirmation) The transaction layer uses this service to confirm the results of a transaction control request service. The transaction layer shall communicate this service to the node controller upon completion of a transaction control request. There are no actions provided by this service. No parameters are communicated to the node controller via this service.
7.1.1.3 Transaction event indication (TR_EVENT.indication) The transaction layer uses this service to indicate to the node controller events detected by the transaction layer. There are no actions provided by this service. No response is defined for this indication. The following parameters are communicated to the node controller via this service: —
Transaction event. This parameter shall contain an event detected by the transaction layer. The following values are defined for this parameter: —
RESPONSE DATA ERROR. A data error acknowledge was returned to a transaction response sent by this node.
—
RESPONSE FORMAT ERROR. A type error acknowledge was returned to a transaction response sent by this node.
—
REQUEST DATA ERROR. A data error was detected in a transaction request received by this node, and a data error response was returned.
—
ACKNOWLEDGE MISSING. No acknowledge was returned for a transaction response sent by this node.
—
UNSOLICITED RESPONSE. A transaction response was received, but there was no request pending for the transaction label and destination contained in the response (see 6.2.5.3).
—
RESPONSE RETRY LIMIT. A transaction response could not be delivered within the number of retries specified by the transaction retry limit.
7.1.2 Transaction layer data services for applications and bus management These services are used to communicate data transactions between the transaction layer and applications or bus management.
172
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
7.1.2.1 Transaction data request (TR_DATA.request) Applications or bus management use this service to initiate a data transaction on the bus. This service shall be confirmed. The following parameters are communicated to the transaction layer via this service: a)
Transaction type. This parameter shall contain the type of transaction to be performed. The following values are defined for this parameter: 1)
WRITE. A write transaction shall be performed to the destination address. See 7.3.3.2.
2)
READ. A read transaction shall be performed from the destination address. See 7.3.3.1.3.
3)
LOCK. A lock transaction shall be performed to the destination address. See 7.3.3.2.1.
b)
Local bus ID. When TRUE, this indicates that the link shall use 3FF16 as the bus_ID component of source_ID. Otherwise, the 16 MSBs of the NODE_IDS register shall be used as source_ID.
c)
Packet format. In the case of READ or WRITE transactions with a data length of four and a quadletaligned destination address, this parameter shall govern the type of tcode, block or quadlet, generated by the transaction layer. This parameter shall have a value of BLOCK TCODE or QUADLET TCODE.
d)
Extended transaction code. As defined in 6.2.5.9. This parameter is only defined for lock transactions. This parameter is reserved for read transactions and write transactions.
e)
Destination address. As defined in 6.2.5.2.
f)
Data length. As defined in 6.2.5.8.
g)
Data. This is the data to be sent for a write transaction or a lock transaction.
h)
Priority. As defined in 6-10.
i)
Speed (CABLE ONLY). As defined in Table 16-2.
7.1.2.2 Transaction data confirmation (TR_DATA.confirmation) The transaction layer uses this service to confirm the completion of a transaction. The transaction layer shall communicate this service to the requesting application, node controller, or bus manager upon completion of a transaction data request. There are no actions provided by this service. The following parameters are communicated to the appropriate layer via this service: a)
Request status. This parameter shall contain the result of the requested transaction. The following values are defined for this value: 1)
COMPLETE. The transaction was successfully completed.
2)
TIMEOUT. The transaction request was sent, but a transaction response was not received within the period specified by the transaction timeout value (see 7.1.1.1).
3)
ACKNOWLEDGE MISSING. No acknowledge was received to the transaction request.
4)
RETRY LIMIT. The transaction request could not be delivered within the number of retries specified by the transaction retry limit.
5)
DATA ERROR. A data error was detected in data received during the transaction.
b)
Response code. As defined in 6.2.5.10. The response code is valid only if the request status is COMPLETE or DATA_ERROR.
c)
Data. This is the data received if the transaction was a read transaction or a lock transaction.
d)
Data length. As defined in 6.2.5.8, only if data are present.
NOTE—It is the responsibility of the application (or bus management) to associate the transaction data request with the appropriate transaction data response.
Copyright © 2008 IEEE. All rights reserved.
173
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
7.1.2.3 Transaction data indication (TR_DATA.indication) The transaction layer uses this service to indicate to the application, node controller, or bus manager that a transaction request has been received. There are no actions provided by this service. The application, node controller, or bus manager shall respond to this indication. The transaction layer shall communicate this indication to the application, node controller, or bus manager whenever a transaction request has been received. The following parameters are communicated to the application, node controller, or bus manager via this service: a)
Transaction type. This parameter shall contain the type of transaction to be performed. The following values are defined for this parameter: 1)
WRITE. A write transaction shall be performed to the destination address. See 7.3.3.2.
2)
BROADCAST WRITE. A write transaction shall be performed to the destination address. See 7.3.3.2 and 7.3.2.4.
3)
READ. A read transaction shall be performed from the destination address. See 7.3.3.1.3.
4)
LOCK. A lock transaction shall be performed to the destination address. See 7.3.3.2.1.
b)
Destination address. As defined in 6.2.5.2.
c)
Requester ID. This parameter gives the node_ID of the requesting node.
d)
Extended transaction code. As defined in 6.2.5.5. This parameter is only defined for lock transactions. This parameter is reserved for read transactions and write transactions.
e)
Transaction label. As defined in 6.2.5.3.
f)
Data length. As defined in 6.2.5.8.
g)
Data. This is the data received.
h)
Priority. As defined in 6-10.
i)
Speed (cable only). As defined in Table 16-2.
7.1.2.4 Transaction data response (TR_DATA.response) The transaction layer uses this service to respond to a received packet; i.e., to complete the transaction. The application or bus management shall communicate this response to the transaction layer after receiving a transaction data indication. The following parameters are communicated to the transaction layer via this service: a)
Transaction type. This parameter shall contain the type of transaction to be completed. The following values are defined for this parameter: 1)
WRITE. A write transaction was performed to the destination address. See 7.3.3.2.
2)
BROADCAST WRITE. A write transaction was performed to the destination address. See 7.3.3.2 and 7.3.2.4. Note that no response packet is expected. All other parameters communicated by this service are invalid for this transaction type.
3)
READ. A read transaction was performed from the destination address. See 7.3.3.1.3.
4)
LOCK. A lock transaction was performed to the destination address. See 7.3.3.2.1.
b)
Local bus ID. When TRUE, this indicates that the link shall use 3FF16 as the bus_ID component of source_ID. Otherwise, the 16 MSBs of the NODE_IDS register shall be used as source_ID.
c)
Packet format. In the case of READ or WRITE transactions, this parameter shall indicate the type of tcode, block or quadlet, received by the transaction layer. This parameter shall have a value of BLOCK TCODE or QUADLET TCODE.
d)
Transaction label. As defined in 6.2.5.3.
174
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
e)
Extended transaction code. As defined in 6.2.5.9. This parameter is only defined for lock transactions. This parameter is reserved for read transactions and write transactions.
f)
Requester ID. This parameter gives the node_ID of the requesting node.
g)
Response code. As defined in 6.2.5.10.
h)
Data length. As defined in 6.2.5.8, only if data are present.
i)
Data. This is the data to be sent if the transaction was a read transaction or a lock transaction.
j)
Priority. As defined in 6-10.
k)
Speed (cable only). As defined in Table 16-2.
7.2 Transaction facilities Transactions are constructed of link layer packets, with one request packet and (in many cases) one response packet. These packets have many fields in common: a request/response header, requester address, responder address, and optional data.
7.2.1 Split transaction timer The split transaction timer keeps track of each pending transaction. All transactions shall have a default split transaction timeout value of 100 ms. The split transaction timeout value may be changed in those nodes that implement the SPLIT_TIMEOUT control register in the node controller. The timeout period is measured from the last data symbol on the bus of the request subaction to the first data symbol on the bus for the response subaction. If the response subaction has not been received by the node when the timeout period is exceeded, the transaction fails. NOTE—The initiating node should make allowances for any header decode delay following the receipt of the first response subaction data symbol.
7.2.2 Transaction retry limit The BUSY_TIMEOUT control register limits the number of times each request subaction is sent to its destination node. If the single-phase retry protocols are being used, a field within this register limits the number of times the subaction is retried; the retries use the same retry_X label, and no reservations are assigned. The transaction fails if the retry limit is exceeded, although recovery at a higher level is expected. If the (optional) dual-phase retry protocols are being used, distinct fields within this register limit the time interval during which the retries are performed. If the retry time interval is exceeded, the transaction fails, and no higher level recovery is expected.
7.3 Transaction operation This subclause defines how the transaction layer initiates and (if necessary) retries transaction requests, and how the transaction layer reacts to transaction requests. This subclause makes reference to the link layer services described in clause 6.
7.3.1 Overview of transaction layer operations This subclause gives an informal overview of transaction layer operations. The descriptions in this subclause are informative and nonbinding. The formal descriptions of behavior are in 7.3.2 and 7.3.3.2.2.
Copyright © 2008 IEEE. All rights reserved.
175
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
7.3.1.1 Read transactions A node originates a read transaction when the bus management or the application layer above the transaction layer communicates a transaction data request with a transaction type of READ. The request contains the destination address and the data length for the read. The transaction layer begins the transaction by communicating a link data request to the link layer. The link data confirmation completes the request subaction of the read transaction at the source node. The request subaction causes a link data indication to be communicated to the transaction layer in the destination node. The transaction layer communicates a link data response, as appropriate for how the transaction is to be completed (see 7.3.2), to complete the request subaction at the destination node. The transaction layer communicates a transaction data indication to the destination application layer, announcing the arrival of a read request. The response subaction of the read transaction begins when the application layer at the destination node completes the requested read operation and communicates a transaction data response. The response contains the read data, the data length, the node_ID of the source node, the transaction label of the corresponding request, and the response code. The transaction layer communicates a link data request to the link layer. The link data confirmation completes the response subaction of the read transaction at the destination node. The response subaction causes a link data indication to be communicated to the transaction layer in the source node. The transaction layer communicates a link data response, as appropriate for the type of transaction, to complete the request subaction at the source node. The transaction layer communicates a transaction data confirmation to the appropriate source application, completing the read transaction. A read transaction may be completed without a response subaction, but this only occurs if there was an error in the request subaction.
7.3.1.2 Write transactions A node originates a write transaction when the bus management or the application layer above the transaction layer communicates a transaction data request with a transaction type of WRITE. The request contains the destination address, the write data, and the data length for the write. The transaction layer begins the transaction by communicating a link data request to the link layer. The link data confirmation completes the request subaction of the write transaction at the source node. The request subaction causes a link data indication to be communicated to the transaction layer in the destination node. The transaction layer communicates a link data response, as appropriate for how the transaction is to be completed (see 7.3.2), to complete the request subaction at the destination node. The transaction layer communicates a transaction data indication to the destination application layer, announcing the arrival of a write request. The response subaction of the write transaction begins when the application layer at the destination node completes the requested write operation and communicates a transaction data response. The response contains the node_ID of the source node, the transaction label of the corresponding request, and the response code. The transaction layer communicates a link data request to the link layer. The link data confirmation completes the response subaction of the write transaction at the destination node. The response subaction causes a link data indication to be communicated to the transaction layer in the source node. The transaction layer communicates a link data response, as appropriate for the type of transaction, to complete the request subaction at the source node. The transaction layer communicates a transaction data confirmation to the appropriate source application, completing the write transaction.
176
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
A write transaction may also be completed without a response subaction. The write transaction begins as described above with a request subaction. This time, however, the transaction data response at the destination node is communicated before the transaction layer communicates the link data response. The response code in the transaction data response is used to create the acknowledge code for the link data response. The link data response completes the write transaction at the destination node. The value of the acknowledge code received by the source node causes the source transaction layer to communicate a transaction data confirmation to the source application layer, completing the write transaction.
7.3.1.3 Lock transactions A node originates a lock transaction when the bus management or the application layer above the transaction layer communicates a transaction data request with a transaction type of LOCK. The request contains the destination address, data, any argument required for the lock operation, the data length of the arguments and data, and the lock function to be performed. The transaction layer begins the transaction by communicating a link data request to the link layer. The link data confirmation completes the request subaction of the lock transaction at the source node. The request subaction causes a link data indication to be communicated to the transaction layer in the destination node. The transaction layer communicates a link data response, as appropriate for how the transaction is to be completed (see 7.3.2), to complete the request subaction at the destination node. The transaction layer communicates a transaction data indication to the destination application layer, announcing the arrival of a lock request. The response subaction of the lock transaction begins when the application layer at the destination node completes the requested lock operation and communicates a transaction data response. The response contains the old data value, the old data length, the node_ID of the source node, the transaction label of the corresponding request, and the response code. The transaction layer communicates a link data request to the link layer. The link data confirmation completes the response subaction of the lock transaction at the destination node. The response subaction causes a link data indication to be communicated to the transaction layer in the source node. The transaction layer communicates a link data response, as appropriate for the type of transaction, to complete the request subaction at the source node. The transaction layer communicates a transaction data confirmation to the source application layer, completing the lock transaction. A lock transaction may be completed without a response subaction, but this only occurs if there was an error in the request subaction.
7.3.1.4 Response codes (rcode) 7.3.1.4.1 No response If a packet is received with a tcode value that is reserved by this standard, the node shall not respond.
7.3.1.4.2 resp_complete Nodes shall respond with resp_complete in the following circumstance (this is not exhaustive, and is only an example of a circumstance for which there might be confusion with other response codes): —
A write request is received for a writable address that contains read-only bits or fields. The transaction completes successfully and the write effects on the read-only bits are as specified in this standard or the document that describes the unit architecture. Generally an address is not considered writable if all bits are read-only; see the discussion of resp_type_error in 7.3.1.4.5.
Copyright © 2008 IEEE. All rights reserved.
177
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Nodes may respond with resp_complete in the following circumstances: —
A read request packet is addressed to a valid destination_ID but the destination_offset references an address that is not implemented by the node.
—
A block read request packet is addressed to a valid destination_ID but the combination of the destination_offset and the data_length reference addresses, some of which are not implemented by the node.
In both of the previous circumstances, if the read request is addressed to configuration ROM, the data value returned in the response is unspecified. Configuration ROM includes not only the first 1024 bytes of ROM (quadlets in the address range FFFF F000 040016 through FFFF F000 07FC16, inclusive), but any directories or leaves that are indirectly addressed from the first 1024 bytes. Otherwise, for read requests addressed to any location not within configuration ROM, the returned data value shall be zero.
7.3.1.4.3 resp_conflict_error Nodes shall respond with resp_conflict_error in the following circumstance: —
An otherwise valid request packet is received but the resources required to act upon the request are not available. The requester may reasonably expect the same packet to succeed at some point in the future when the resources are available. Note that the distinction between resp_conflict_error and ack_busy_X, ack_busy_A, or ack_busy_B hinges upon the possibility of deadlock. The busy acknowledgments are appropriate for transient conditions of expected short duration that cannot cause a deadlock. On the other hand, resp_conflict_error shall be returned when an end-to-end retry is necessary to avoid the possibility of deadlock. Deadlocks may arise when a request cannot be queued and blocks a node’s transaction resources.
7.3.1.4.4 resp_data_error Nodes shall respond with resp_data_error in the following circumstances: —
For read requests, an otherwise valid packet is received but a hardware error at the node prevents the return of the requested data. For example, an uncorrectable memory error shall be reported as resp_data_error.
—
For write or lock requests, an otherwise valid packet is received but a hardware error at the node prevents the updates indicated by the data payload from initiation or completion.
Nodes may respond with resp_data_error in the following circumstances: —
An otherwise valid request packet is received but there is a data CRC error for the data payload.
—
An otherwise valid packet is received but the actual size of the data payload differs from that specified by data_length.
7.3.1.4.5 resp_type_error Nodes shall respond with resp_type_error in the following circumstances: —
A request packet is received with a valid tcode (transaction code) value but the extended_tcode field value is reserved by this standard.
—
A request packet is received with valid tcode and extended_tcode values, but the referenced address does not implement the indicated request. An example of this is a write request to an address that is entirely read-only (note that this is distinct from a write request that references read-only bits or fields at an otherwise writable location). Another example is a transaction whose tcode specifies a lock operation but the destination address supports only read and write operations.
—
A request packet is addressed to a valid destination_ID, the destination_offset references an address implemented by the node, but the alignment of the destination offset does not match the node’s
178
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
alignment requirements. For example, a quadlet register is implemented but cannot respond to a 1byte data block request. In addition to the previously mandated responses, nodes should respond with resp_type_error in the following circumstance: —
A request packet is received with valid tcode and extended_tcode values, but the recipient accepts requests only from particular senders, as identified by source_ID. Some protocols protect certain addresses from both unintended and malicious interference by requiring a login procedure that identifies the source_ID of a valid requester.
7.3.1.4.6 resp_address_error An address error condition exists when the combination of the destination_offset and, when present in the request, the data_length fields reference addresses, some of which are not implemented by the node. In some circumstances, a node may respond with resp_complete (see 7.3.1.4.2). Unless a node responds with resp_complete, it shall respond with resp_address_error in the following circumstances: —
A request packet is addressed to a valid destination_ID but the destination_offset references an address that is not implemented by the node.
A block request packet is addressed to a valid destination_ID but the combination of the destination_offset and the data_length reference addresses, some of which are not implemented by the node.
7.3.1.5 Error handling The transaction layer handles error conditions in certain cases, and expects the application to handle errors in other cases. This subclause is intended as a brief survey of error conditions and how they are handled. Some of the errors handled by the transaction layer are enumerated in the definition of the transaction event indication (see 7.1.1.3). These errors are handled by the transaction layer because the transaction layer should not pass the bad information from an inbound request to the application (REQUEST DATA ERROR), the transaction layer has no active context for an inbound response (UNSOLICITED RESPONSE), or the error occurs after transaction layer has completed an inbound transaction with the application (RESPONSE DATA ERROR, RESPONSE FORMAT ERROR, ACKNOWLEDGE MISSING, RESPONSE RETRY TIMEOUT). All other errors on inbound transaction requests are expected to be detected and handled by the application via the response code in the transaction data response. Errors on outbound transaction requests are reported to the application via the transaction data confirmation in the request status and response code parameters. These errors are handled by the application, perhaps by retrying the transaction request, or via some other higher level recovery protocol.
7.3.2 Transaction completion definitions This subclause defines the various ways in which a transaction can be completed. Note that the responding node determines how a transaction is completed. The method by which a responding transaction layer determines how to complete a given transaction is not defined by this standard. NOTE—The method of completing a transaction requires agreement between the transaction layer and application layers. One method is to hardwire the decision based on the destination address. For example, a write to a hardware control register can complete as a unified transaction with minimum bus overhead. On the other hand, a large read of a ROM space that is seldom accessed may be best achieved via a split transaction, allowing the application the opportunity
Copyright © 2008 IEEE. All rights reserved.
179
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
to schedule the transaction with a lower priority. Another method is to implement a timer, which can trigger the completion decision, depending on how fast the application can respond.
7.3.2.1 Unified transaction A unified transaction is defined as a transaction that begins with an acknowledged request subaction but is not followed by a response subaction. Only write transactions may normally complete as unified transactions. Read transactions and lock transactions do not normally complete as unified transactions.
7.3.2.2 Split transaction A split transaction is defined as a transaction that begins with an acknowledged request subaction and is followed by an acknowledged response subaction. Read transactions, write transactions, and lock transactions may be split transactions. Other subactions may occur between the request subaction and the response subaction.
7.3.2.3 Concatenated transaction A concatenated transaction is defined as a transaction that begins with an acknowledged request subaction and is followed immediately by the corresponding acknowledged response subaction, with no subaction gap between. Read transactions, write transactions, and lock transactions may be concatenated transactions. No other subactions shall occur between the request subaction and the response subaction of a concatenated transaction.
7.3.2.4 Broadcast transaction A broadcast transaction is defined as a transaction that contains only an unacknowledged request subaction. Only write transactions may be broadcast transactions. Read transactions and lock transactions shall not be broadcast transactions.
7.3.2.5 Pending transaction A pending transaction is defined as a transaction that is not yet completed. For a unified transaction, the transaction completes when the request subaction has been acknowledged. For a broadcast transaction, the transaction completes when the request subaction has been sent. For all other transactions, the transaction completes when the response subaction has been acknowledged. A transaction is also considered complete when the response has not been received within a period specified by the SPLIT_TIMEOUT register. The transaction layer may optionally initiate other transactions and react to transactions while a transaction is pending.
7.3.3 Details of transaction layer operation The operation of the transaction layer with respect to remote nodes is described by the state machines in Figure 7-1 and Figure 7-2. Also, the reader may also wish to refer back to the discussion of transaction types in 1.2. The two state machines described operate in concert to originate outbound transactions and process inbound transaction requests. This standard does not require that transaction requests to the local node force the generation of link-layer packets; the transaction layer may directly handle read, write, and lock transactions to local addresses. In other words, if an application requests a write to the local STATE_SET register, then that action can take place without any data packets appearing on the physical bus.
180
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
7.3.3.1 Outbound transaction state machine The state machine in Figure 7-1 describes the operation of the transaction layer when originating an outbound transaction request.
Figure 7-1—Outbound transaction state machine 7.3.3.1.1 Outbound transaction state machine initialization Transition All:TX0. The transaction layer shall transition from any other transaction layer state to the TX0 state when a transaction control request with an action of Initialize is communicated from the node controller. State TX0: Send Transaction Ready. The transaction layer is ready to send transaction requests and responses. The transaction layer shall initiate a new transaction only when in state TX0. If the transaction layer receives a transaction data request or a transaction data response when not in state TX0, it shall hold the request or response until it returns to state TX0. The method by which the transaction layer manages pending transaction data requests and transaction data responses is not defined by this standard. Transition All:TX3. The transaction layer shall transition from any other transaction layer state to the TX3 state when a transaction control request with an action of Reset is communicated from the node controller
Copyright © 2008 IEEE. All rights reserved.
181
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State TX3. The transaction layer is suspended. The transaction layer shall only leave state TX3 via transition All:TX0.
7.3.3.1.2 Sending a transaction request Transition TX0:TX1. The transaction layer receives a transaction data request. The transaction layer shall transition to state TX1. State TX1: Send Transaction Request. The transaction layer shall initiate a transaction by communicating a link data request to the link layer to cause the request subaction of the transaction to be sent to the specified destination node. The retry code of the request shall be set to retry_1 for the first attempt to send the subaction. A transaction label that uniquely identifies the transaction to the destination node (see 6.2.5.3) shall be specified by the transaction layer. The destination address, extended transaction code, speed, priority, data length, and data parameters of the link data request shall be set to the values of the corresponding fields contained in the transaction data request. The transaction code parameter value shall be set to —
Write request for data quadlet, if the transaction type value in the transaction data request is WRITE, the data length is four, the destination address is quadlet aligned, and the packet format value is QUADLET TCODE.
—
Write request for data block, if the transaction type value in the transaction data request is WRITE, the data length is four, the destination address is quadlet aligned, and the packet format value is BLOCK TCODE.
—
Write request for data block, if the transaction type value in the transaction data request is WRITE and the data length is not four, or the destination address is not quadlet aligned.
—
Read request for data quadlet, if the transaction type value in the transaction data request is READ, the data length is four, the destination address is quadlet aligned, and the packet format value is QUADLET TCODE.
—
Read request for data block, if the transaction type value in the transaction data request is READ, the data length is four, the destination address is quadlet aligned, and the packet format value is BLOCK TCODE.
—
Read request for data block, if the transaction type value in the transaction data request is READ and the data length is not four, or the destination address is not quadlet aligned; or
—
Lock request, if the transaction type value in the transaction data request is LOCK.
The retry count for the transaction shall be initialized. After issuing the link data request, the transaction layer waits until it receives a link data confirmation. If the request status is ACKNOWLEDGE_RECEIVED, and an acknowledge of ack_busy_A, ack_busy_B, or ack_busy_X is received, then the destination node is busy; the transaction layer shall retry using the appropriate retry method. The method by which the transaction layer performs the retries is defined in 7.3.3.2.2. Transition TX1:TX0a. The transaction layer receives a link data confirmation, with a request status of ACKNOWLEDGE_RECEIVED, and an acknowledge of ack_pending. The transaction will complete as a split transaction or a concatenated transaction. The destination node will return a response at some later time. The split transaction timer for the transaction shall be initialized and begin advancing. Transition TX1:TX0b. The transaction layer receives a link data confirmation, with a request status and/or an acknowledge set to values other than listed for transition TX1:TX0a or transition TX1:TX0d. The transaction has completed as either a unified transaction or a broadcast transaction. The transaction layer shall communicate a transaction data confirmation. Table 7-2 summarizes the parameters that shall be returned by the transaction data confirmation based on the contents of the link data confirmation.
182
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 7-2—Summary of transaction data confirmation during transition TX1:TX0b Value of acknowledge in link data confirmation
Value of request status in link data confirmation
Value of request status in transaction data confirmation
Value of response code in transaction data confirmation
ACKNOWLEDGE_MISSING
None
ACKNOWLEDGE_MISSING
None
BROADCAST_SENT
None
COMPLETE
resp_complete
ACKNOWLEDGE_RECEIVED
ack_type_error
COMPLETE
resp_type_error
ACKNOWLEDGE_RECEIVED
ack_data_error
COMPLETE
resp_data_error
ACKNOWLEDGE_RECEIVED
ack_complete
COMPLETE
resp_complete
Transition TX1:TX0c. The transaction layer detects that the retry count for the transaction has exceeded the transaction retry limit. The transaction layer shall communicate a transaction data confirmation, with a request status of RETRY LIMIT. The transaction shall be considered completed. Transition TX1:TX0d. The transaction layer receives a link data confirmation, with a request status of ACKNOWLEDGE_RECEIVED and an acknowledge of ack_busy_A, ack_busy_B, or ack_busy_X, and single-phase retry is to be used. The request subaction will continue to be retried using the single-phase retry algorithm (see 7.3.4). The transaction layer may transition back to state TX0 for purposes of sending a different request or response. The transaction layer may also stay in state TX1 and continue retrying the request. The transaction layer shall maintain retry counts for each subaction that is currently busy. NOTE—This transition is provided to allow a transaction layer implementation to retry busy subactions at a later time, without delaying other queued requests and responses. This implementation is allowed only for single-phase retry.
7.3.3.1.3 Sending a transaction response Transition TX0:TX2. The transaction layer receives a transaction data response for either a split transaction (see transition RX1:RX0c in 7.3.2.5) or a concatenated transaction (see transition RX1:RX0d in 7.3.2.5). The transaction layer shall transition to state TX2. State TX2: Send Transaction Response. The transaction layer shall communicate a link data request to the link layer to cause the response subaction of the transaction to be sent to the specified destination node. The retry code of the response shall be set to retry_1 for the first attempt to send the subaction. The response code, extended transaction code, transaction label, speed, priority, data length, and data parameters of the link data request shall be set to the values of the corresponding fields contained in the transaction data response. The destination address parameter shall be set to the value of the Requester ID field contained in the transaction data response. The transaction code parameter value shall be set to —
Write response for data quadlet, if the transaction type value in the transaction data request is WRITE, the data length is four, and the packet format value is QUADLET TCODE.
—
Write response for data block, if the transaction type value in the transaction data request is WRITE and the data length is not four, or the packet format value is BLOCK TCODE.
—
Read response for data quadlet, if the transaction type value in the transaction data request is READ, the data length is four, and the packet format value is QUADLET TCODE.
—
Read response for data block, if the transaction type value in the transaction data request is READ and the data length is not four, or the packet format value is BLOCK TCODE.
—
Lock response, if the transaction type value in the transaction data request is LOCK.
The retry count for the transaction shall be initialized.
Copyright © 2008 IEEE. All rights reserved.
183
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
After issuing the link data request, the transaction layer waits until it receives a link data confirmation. If the request status is ACKNOWLEDGE_RECEIVED, and an acknowledge of ack_busy_A, ack_busy_B, or ack_busy_X is received, then the destination node is busy; the transaction layer shall retry using the appropriate retry method. The method by which the transaction layer performs the retries is defined in 7.3.3.2.2. Transition TX2:TX0a. The transaction layer receives a link data confirmation. The transaction layer may communicate a transaction event indication, if necessary. The conditions that require the transaction layer to communicate a transaction event indication are summarized in Table 7-3.
Table 7-3—Summary of transaction event indication during transition TX2:TX0a Value of request status in link data confirmation
Value of acknowledge in link data confirmation
Value of transaction event in transaction event indication
ACKNOWLEDGE_MISSING
None
ACKNOWLEDGE_MISSING
BROADCAST_SENT
None
Not valid
ACKNOWLEDGE_RECEIVED
ack_complete
No indication necessary
ACKNOWLEDGE_RECEIVED
ack_data_error
RESPONSE_ERROR
ACKNOWLEDGE_RECEIVED
Any other value
Not valid
Transition TX2:TX0b. The transaction layer detects that the retry count for the subaction has exceeded the transaction retry limit. The transaction layer shall communicate a transaction event indication, with a transaction event of RESPONSE RETRY TIMEOUT. The transaction shall be considered completed. Transition TX2:TX0c. The transaction layer receives a link data confirmation, with a request status of ACKNOWLEDGE_RECEIVED and an acknowledge of ack_busy_A, ack_busy_B, or ack_busy_X, and single-phase retry is to be used. The response subaction will continue to be retried using the single-phase retry algorithm (see 7.3.4). The transaction layer may transition back to state TX0 for purposes of sending a different request or response. The transaction layer may also stay in state TX1 and continue retrying the response. The transaction layer shall maintain retry counts for each subaction that is currently busy. NOTE—This transition is provided to allow a transaction layer implementation to retry busy subactions at a later time, without delaying other queued requests and responses. This implementation is allowed only for single-phase retry.
7.3.3.2 Inbound transaction state machine The state machine in Figure 7-2 describes the operation of the transaction layer when receiving an inbound transaction request or response.
7.3.3.2.1 Inbound transaction state machine initialization Transition All:RX0. The transaction layer shall transition from any other transaction layer state to the RX0 state when a transaction control request with an action of Initialize is communicated from the node controller. State RX0: Receive Transaction Ready. The transaction layer is ready to receive transaction requests and responses. Transition All:RX3. The transaction layer shall transition from any other transaction layer state to the TX3 state when a transaction control request with an action of Reset is communicated from the node controller.
184
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 7-2—Inbound transaction state machine State RX3. The transaction layer is suspended. The transaction layer shall only leave state RX3 via transition All:RX0.
7.3.3.2.2 Responding to a transaction request Transition RX0:RX1. The transaction layer receives a link data indication, which contains a transaction code value for a transaction request; specifically, a write request for a data quadlet, a write request for a data block, a read request for a data quadlet, a read request for a data block, or a lock request. The transaction layer shall communicate a transaction data indication to the application. The destination address, extended transaction code, transaction label, speed, priority, data length, and data parameters shall be set to the values of the corresponding fields contained in the link data indication. The Requester ID parameter shall be set to the value of the source ID field contained in the link data indication. The transaction type parameter value shall be set to —
WRITE, if the transaction code value in the link data indication is either a write request for a data quadlet or a write request for a data block, and the packet status value is not BROADCAST.
—
BROADCAST_WRITE, if the transaction code value in the link data indication is either a write request for a data quadlet or a write request for a data block, and the packet status value is BROADCAST.
Copyright © 2008 IEEE. All rights reserved.
185
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
—
READ, if the transaction code value in the link data indication is either a read request for a data quadlet or a read request for a data block.
—
LOCK, if the transaction code value in the link data indication is a lock request.
NOTE—It is the responsibility of the application layer (or bus management) to associate the transaction data indication with the appropriate transaction data response.
Transition RX0:RX0a. The split transaction timer for a pending transaction has exceeded the split transaction timeout period. The transaction layer shall communicate a transaction data confirmation. The request status shall be set to ACKNOWLEDGE_MISSING. The pending transaction shall be considered completed. Transition RX0:RX0b. The transaction layer receives a link data indication, which contains a packet that has a transaction code and/or an extended transaction code that is unknown to or unimplemented by the node. The transaction layer shall communicate a link data response, the bus occupancy control shall be set to RELEASE, and the acknowledge shall be set to ack_type_error. Transition RX0:RX0c. The transaction layer is busy and shall return a busy acknowledge (the transaction has to be completed as a unified transaction). The transaction layer shall communicate a link data response, and the bus occupancy control shall be set to RELEASE. The acknowledge shall be set as defined in 7.3.3.2.2. Note that a transaction data indication shall not be communicated to the application. State RX1: Process Transaction Request. The transaction layer has received the transaction request. The next step is to complete the request subaction and then complete the transaction. Unless the transaction is to be completed as a split transaction, the transaction layer waits for a transaction data response. NOTE—Recall that the method by which a responding transaction layer determines how to complete a given transaction is not defined by this standard.
Transition RX1:RX0a. The transaction layer receives a transaction data response with the transaction type set to BROADCAST_WRITE. The transaction layer shall communicate a link data response, and the bus occupancy control shall be set to NO_OPERATION. Transition RX1:RX0b. The transaction layer receives a transaction data response and the transaction is to be completed as a unified transaction. The transaction layer shall communicate a link data response, and the bus occupancy control shall be set to RELEASE. The acknowledge shall be set based on the value of the response code contained in the transaction data response, as summarized in Table 7-4.
Table 7-4—Acknowledge value in link data response during transition RX1:RXOb Value of response code in transaction data response
186
Value of acknowledge in link data response
resp_complete
ack_complete
resp_conflict_error
NOT ALLOWED
resp_data_error
ack_data_error
resp_type_error
ack_type_error
resp_address_error
NOT ALLOWED
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The application layer, node controller, or bus manager shall not communicate a transaction data response that contains a response code of resp_conflict_error or resp_address_error with the intent to complete a unified transaction. Transition RX1:RX0c. The transaction is to be completed as a split transaction. The transaction layer shall communicate a link data response, and the bus occupancy control shall be set to RELEASE. The acknowledge shall be set to ack_pending. Transition RX1:RX0d. The transaction is to be completed as a concatenated transaction, and the transaction layer receives a transaction data response. The transaction layer shall communicate a link data response, and the bus occupancy control shall be set to HOLD. The acknowledge shall be set to ack_pending. The transaction layer shall not make this transition if the outbound transaction state machine is not in state TX0. NOTE—If the outbound transaction state machine is not in state TX0, it is currently attempting a dual-phase retry. The inbound transaction state machine has to complete all transactions that would normally complete as concatenated transactions as split transactions instead.
7.3.3.2.3 Responding to a transaction response Transition RX0:RX2. The transaction layer receives a link data indication, which contains a transaction code value for a transaction response; specifically, a write response, a read response for a data quadlet, a read response for a data block, or a lock response. The transaction layer shall not communicate a transaction data indication to the application. State RX2: Process Transaction Response. The transaction layer has received the transaction response. The next step is to complete the response subaction and then complete the transaction. NOTE—It is the responsibility of the application layer (or node controller or bus manager) to associate the transaction data request with the appropriate transaction data confirmation.
Transition RX2:X0a. The transaction layer determines that it has received the response for a pending request. The transaction layer determines this by comparing the source ID, transaction label, and transaction code from the link data indication with its pending requests. The pending transaction is completed as either a split transaction or a concatenated transaction. The transaction layer shall communicate a link data response, the bus occupancy control shall be set to RELEASE, and, if the packet status in the link data indication was set to DATA_CRC_ERROR, the acknowledge shall be set to ack_data_error; otherwise, the acknowledge shall be set to ack_complete. The transaction layer shall also communicate a transaction data confirmation to the application. If the link data indication contained valid data and data length values, these parameters shall be valid in the transaction data confirmation. The response code shall be set to the value contained in the link data indication. If the packet status in the link data indication was set to DATA_CRC_ERROR, the request status shall be set to DATA_ERROR; otherwise, the request status shall be set to COMPLETE. If the packet status in the link data indication was set to DATA_CRC_ERROR, the transaction layer shall also communicate a transaction event indication, with the transaction event set to RESPONSE_DATA_ERROR. If the packet status in the link data indication was set to FORMAT_ERROR, the transaction layer shall also communicate a transaction event indication, with the transaction event set to RESPONSE_FORMAT_ERROR. Transition RX2:X0b. The transaction layer determines that it has received a response for which there is no pending request. The transaction layer determines this by comparing the source ID, transaction label, and transaction code from the link data indication with its pending requests. The transaction layer shall communicate a link data response, the bus occupancy control shall be set to RELEASE, and the acknowledge shall be set to ack_complete.
Copyright © 2008 IEEE. All rights reserved.
187
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The transaction layer shall also communicate a transaction event indication, with the transaction event set to UNSOLICITED RESPONSE.
7.3.4 Transaction types This subclause defines the types of transactions that can be performed.
7.3.4.1 Read transactions A read transaction shall be initiated as defined in 7.3.2.5. The request subaction shall contain the address of the data to be read. A read transaction shall be reacted to as defined in 7.3.3.1. If the request subaction is received correctly, and if the address is a valid address readable by the requesting node, the read data shall be returned in the response subaction. A read transaction may only be completed as a split transaction or as a concatenated transaction. A read transaction shall not be completed as a unified transaction, except when the request subaction cannot be received correctly. A read transaction shall not be completed as a broadcast transaction.
7.3.4.2 Write transactions A write transaction shall be initiated as defined in 7.3.2.5. The request subaction shall contain the address of the data to be written, and the data to be written. A write transaction shall be reacted to as defined in 7.3.3.1. If the request subaction is received correctly, and if the address is a valid address writable by the requesting node, the write data shall be written to the requested address. A write transaction may be completed as a split transaction, as a concatenated transaction, as a unified transaction, or as a broadcast transaction.
7.3.4.3 Lock transactions A lock transaction shall be initiated as defined in 7.3.2.5. The request subaction shall contain the address of the location in the destination node to be lock accessed, the type of lock access to be performed, and the data and argument to be used in the lock access. A lock transaction shall be reacted to as defined in 7.3.3.1. If the request subaction is received correctly, and if the address is a valid address accessible by the requesting node, the lock access shall be performed to the requested address. A lock transaction may only be completed as a split transaction or as a concatenated transaction. A lock transaction shall not be completed as a unified transaction except when the request subaction cannot be received correctly. A lock transaction shall not be completed as a broadcast transaction. If a node receives any other transaction request while a lock transaction is pending, and if the address specified in the new transaction overlaps in any way the address range of the pending lock transaction, the node shall either complete the entire function to be performed by the lock transaction before completing the new transaction, or it shall complete the new transaction before performing any part of the entire function to be performed by the lock transaction. Lock functions can be performed on 32-bit or 64-bit values. The value at the destination address immediately prior to performing the lock function is always returned in the data of the lock response. The following table describes the lock functions defined for lock transactions. Both big- and little-endian fetch and add lock subcommands are defined (add_big and add_little). For the big- and little-endian adds, the byte with the smallest address within the addressed integer is assumed to be the most or least significant, respectively. Only big-endian bounded_add_big and wrap_add_big lock subcommands, which are expected to be used less frequently, are defined.
188
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
In the preceding, arg_value and data_value are the fields of the same name from the lock-request packet. The old_value field is the current value of the addressed CSR obtained as if from a read request; this is also the value returned in the lock-response packet. The new_value field is the updated value of the CSR as if a write request were used to store the calculated value. When a lock transaction addresses a CSR that has one or more reserved bits or fields, the results are not necessarily obvious. The behavior of a particular lock function shall be determined by applying rules for reserved fields (see 1.5.11) in order, as follows: a)
The CSR’s old_value shall be obtained as if via a read request and shall be returned in the lock response; reserved fields are read as zeros.
b)
An intermediate value shall be calculated according to the C code in Table 7-5 (this is not explicitly shown but is the right-hand part of each of the assignment statements in the table).
c)
The intermediate value shall be stored in the CSR as if via a write request; reserved fields shall be ignored and remain zero in the CSR. The contents of the CSR after this operation are the new_value.
Table 7-5—Summary of lock transaction functions Lock function mask_swap compare_swap
Update action new_value = (data_value & arg_value) | (old_value & ~arg_value); if (old_value == arg_value) new_value = data_value;
add_big
new_value = old_value + data_value;
add_little
(little) new_value = (little) old_value + (little) data_value;
bounded_add_big
if (old_value!= arg_value) new_value = old_value + data_value;
wrap_add_big
new_value = (old_value != arg_value) ? old_value + data_value : data_value;
7.3.5 Retry protocols Retry protocols define the complementary procedures used by the transaction layers of the sender of an asynchronous primary packet and its intended recipient when the recipient is unable to service the packet, i.e., is in some sense “busy.” The packet originator utilizes an outbound retry protocol while the intended recipient participates in an inbound retry protocol. The retry protocols may be used with any packet, whether request or response, for which an acknowledgment is expected from the recipient. In the case of dual-phase retry, revision of both the outbound and inbound state machines are necessary for the following reasons: —
Reservation time limit ambiguities. This standard specifies that retry reservations shall be held by the intended recipient for four arbitration fairness intervals before cancellation. Unfortunately, the point from which fairness intervals is measured is not clearly specified. Contemporary link implementations are known to have different (although reasonable) interpretations that are not interoperable.
—
No resynchronization. The inbound dual-phase retry state machines in this standard do not resynchronize reservation histories (phase and count of outstanding reservations) when discrepancies exist between the outbound and inbound nodes.
In order to correct these problems and to add an enhancement (the ability to count the number of outstanding reservations for each phase), dual-phase retry behavior for both outbound and inbound nodes is redefined.
Copyright © 2008 IEEE. All rights reserved.
189
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The maintenance of reservation counters permits an inbound node to immediately accept subactions that lack a resource reservation if there are no reservations held for pending subactions.
7.3.5.1 Outbound subaction retry protocol The transaction layer shall implement a decision table that selects a retry code, rt, each time an asynchronous primary packet is transmitted. The choice of retry code, specified by Table 7-6, depends upon the packet’s history, i.e., both its “age” and the last acknowledge code received for the subaction.
Table 7-6—Outbound subaction retry code decision table
Subaction age Oldest
Prior acknowledge code —
Retry code Single-phase
Dual-phase
retry_X
retry_1
ack_busy_X
Not oldest
ack_busy_A
retry_A
ack_busy_B
retry_B
—
retry_X
ack_busy_X ack_busy_A ack_busy_B
Request and response retries and their associated reservations shall be processed independently of each other. At any point in time there may be both an oldest request and an oldest response. The description of a subaction’s age is not meant to imply the necessity for timers in a link design. When an asynchronous primary packet is available for transmission and there are no subactions awaiting retry, the packet is by definition the oldest packet and may be transmitted with a retry code of retry_1. When that subaction completes with a terminal acknowledge code (any acknowledgment, including ack_pending, other than ack_busy_X, ack_busy_A, or ack_busy_B), another subaction awaiting transmission (or retransmission) may be designated oldest. The details as to which other subaction is elected oldest are implementation dependent and are not important to the proper behavior of the retry protocols so long as the following requirement is observed: An asynchronous primary packet shall not be transmitted with a retry code of retry_1 so long as a different subaction of the same type (request or response) once transmitted with a retry code of retry_1 has not yet been completed with a terminal acknowledge code or been abandoned. Subactions that do not yet have a history, i.e., this is the first time transmission has been initiated, are indicated by the absence of a prior acknowledge code. It is not necessary for the node transmitting a subaction to have a priori knowledge as to whether or not the intended recipient (inbound node) has implemented the single- or dual-phase retry protocol. Designs capable of dual-phase retry should select the initial retry code, retry_X or retry_1, from the right-hand column in Table 7-6 while designs that restrict themselves to single-phase retry shall use a retry code of retry_X in all cases. A node that implements the dual-phase retry protocol may transmit retry_X if no reservation is requested.
190
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
In order for the dual-phase retry protocol to be able to guarantee forward progress, an outbound node should be capable of retransmission of a subaction within five fairness intervals; this is the period of time for which an inbound node guarantees a retry reservation. Although the inbound dual-phase retry protocol state machine resets itself properly if a reservation is not utilized within this time limit (see 7.3.5.3 for details), the outbound node may fail to make forward progress if it loses retry reservations because of delayed retransmission. Fairness intervals are counted from the receipt of the ack_busy_A or ack_busy_B that granted the reservation; if an outbound node is unable to retransmit the subaction before five arbitration reset gaps have been observed, it may assume that the reservation has been cancelled.
7.3.5.2 Inbound subaction single-phase retry protocol Any time the transaction layer receives an LK_DATA.indication and resources are unavailable to service the subaction, the transaction layer shall communicate an LK_DATA.response with an acknowledge parameter of ack_busy_X without regard to the value of the subaction’s retry code. The preceding shall not apply to subactions for which no acknowledgment is expected, e.g., broadcast requests.
7.3.5.3 Inbound subaction dual-phase retry protocol The intended recipient of an asynchronous subaction, request or response, may be unable to accept the packet because of transient resource limitations—the node is busy. In a simple (single-phase) retry protocol, senders retransmit the subaction until resources are available or they abandon the transaction. Single-phase retry does not guarantee forward progress because it makes no attempt to reserve resources for the oldest subactions. The dual-phase protocol described in this subclause reserves resources when congestion is encountered and keeps them reserved for particular subactions identified by a retry code. As subactions complete, the inbound node resources are once again made available to all subactions, with or without reservations. The transaction layer shall allocate resources independently for request and response queues; this is necessary to prevent interdependent live-locks or starvation conditions. The dual-phase retry protocol specified by this subclause shall be separately implemented for request and response subactions. In the description that follows, the size of the reservation counter is implementation dependent. These counters are unsigned numbers and shall not be decremented to a value smaller than zero nor incremented to a value larger than their limit (often 2n – 1,where n is the size of the counter, in bits). Two procedures are defined in Table 7-7 to specify saturated operations for reservation accounting.
Table 7-7—Saturated arithmetic procedures void reserve(int retry_phase) {
// Count reservations until saturated
reservations[retry_phase] += (reservations[retry_phase) < MAX_RESERVATIONS); } void release(int retry_phase) {
// Release earlier reservation (unless saturated)
reservations[retry_phase] -= (
reservations[retry_phase) > 0 && reservations[retry_phase) < MAX_RESERVATIONS);
}
The name ack_subaction_done refers collectively to any acknowledge code defined in this standard except ack_busy_X, ack_busy_A, or ack_busy_B.
Copyright © 2008 IEEE. All rights reserved.
191
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The state machine transitions are shown in Figure 7-3 and briefly described in the paragraphs that follow. IDR: Idle
All:IDR
TR_CONTROL.request(Reset) || TR_CONTROL.request(Initialize)
IDR:IDRa
preference = retry_A; reservations[retry_A] = 0; reservations[retry_B] = 0; reset_gaps = 0
LK_BUS.indication(ARB_RESET_GAP) && reset_gaps < 4
reset_gaps++; IDR:IDRb
LK_BUS.indication(ARB_RESET_GAP) && reset_gaps == 4
reset_gaps = 1; reservations[preference] = 0; preference = (preference == retry_A) ? retry_B : retry_A;
IDRX: Retry X received IDR:IDRX
LK_DATA.indication(retry_X) resources available && reservations[preference] == 0
IDRX:IDRa
LK_DATA.response(ack_subaction_done) resources unavailable || reservations[preference] != 0
IDRX:IDRb
LK_DATA.response(ack_busy_X)
IDR1: Retry 1 received IDR:IDR1
LK_DATA.indication(retry_1) resources available && reservations[preference] == 0
IDR1:IDRa
LK_DATA.response(ack_subaction_done) resources unavailable || reservations[preference] != 0 reserve((preference == retry_A) ? retry_B : retry_A); LK_DATA.response((preference == retry_A) ? ack_busy_B : ack_busy_A)
IDR1:IDRb
IDRA: Retry A received IDR:IDRA
LK_DATA.indication(retry_A)
resources available && (preference == retry_A || reservations[retry_B] == 0) release(retry_A); LK_DATA.response(ack_subaction_done) resources unavailable && preference == retry_A
IDRA:IDRa
IDRA:IDRb
reservations[retry_A] += (reservations[retry_A] == 0); reset_gaps = 0; LK_DATA.response(ack_busy_A) (resources unavailable || reservations[retry_B] != 0) && preference == B LK_DATA.response(ack_busy_A)
IDRA:IDRc
IDRB: Retry B received IDR:IDRB
LK_DATA.indication(retry_B)
resources available && (preference == retry_B || reservations[retry_A] == 0) release(retry_B); LK_DATA.response(ack_subaction_done) resources unavailable && preference == retry_B reservations[retry_B] += (reservations[retry_B] == 0); reset_gaps = 0; LK_DATA.response(ack_busy_B)
IDRB:IDRa
IDRB:IDRb
(resources unavailable || reservations[retry_A] != 0) && preference == retry_A IDRB:IDRc LK_DATA.response(ack_busy_B)
Figure 7-3—Inbound subaction dual-phase retry state machine
192
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition All:IDR. The receipt of a TR_CONTROL.request with an action of either Reset or Initialize shall cause the inbound dual-phase retry state machine to set its reservation preference to retry_A and zero all retry counters. State IDR: Idle. The transaction layer is potentially ready to accept a request or response subaction from the link. Whether or not the subaction is serviced by the transaction layer is determined by the availability of resources [such as first in, first out (FIFO) space], outstanding reservation counts and the retry history of the subaction itself. Transition IDR:IDRa. The end of a fairness interval has been detected, indicated by an arbitration reset gap. If the accumulated count of reset gaps is less than four, the transaction layer shall increment the count. Transition IDR:IDRb. The end of the last fairness interval available to the outbound node for the retry of a subaction for which the inbound node granted a reservation. The inbound node abandons all reservations for the currently preferred retry phase, switches its preference to the opposite retry phase and counts this fairness interval as the first of the four available to holders of reservations in the now preferred phase. Transition IDR:IDRX. An LK_DATA.indication has been received from the link with a packet status of GOOD and a retry code of retry_X. Transition IDR:IDR1. An LK_DATA.indication has been received from the link with a packet status of GOOD and a retry code of retry_1. Transition IDR:IDRA. An LK_DATA.indication has been received from the link with a packet status of GOOD and a retry code of retry_A. Transition IDR:IDRB. An LK_DATA.indication has been received from the link with a packet status of GOOD and a retry code of retry_B. State IDRX: Retry_X received. The outbound node (originator of the request or response subaction) has not requested a reservation if resources are unavailable to service the subaction. Attempt to process the subaction so long as resources are free and not allocated to a different subaction that holds a reservation. Transition IDRX:IDRa. Resources are available and there are no reservations outstanding for the currently preferred phase. The transaction layer shall accept the subaction and return an appropriate terminal acknowledge code. Transition IDRX:IDRb. Resources are unavailable or there are reservations outstanding for the currently preferred phase. The transaction layer shall refuse the subaction without creating a reservation. State IDR1: Retry_1 received. The outbound node (originator of the request or response subaction) has requested a reservation if resources are unavailable to service the subaction. Attempt to process the subaction so long as resources are free and not allocated to a different subaction that holds a reservation. Otherwise, create a reservation in the opposite phase and indicate the phase of the reservation by means of the acknowledge code returned to the outbound node. Transition IDR1:IDRa. Resources are available and there are no reservations outstanding for the currently preferred phase. The transaction layer shall accept the subaction and return an appropriate terminal acknowledge code. Transition IDR1:IDRb. Resources are unavailable or there are reservations outstanding for the currently preferred phase. The transaction layer shall refuse the subaction but create a reservation for the opposite phase. The acknowledge code returned to the outbound node, either ack_busy_A or ack_busy_B, shall indicate the phase of the newly created reservation.
Copyright © 2008 IEEE. All rights reserved.
193
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State IDRA: Retry_A received. The outbound node is attempting retransmission of an earlier request or response subaction for which the inbound node created a reservation. So long as resources are available, the inbound node grants preference to reservations earlier created for the current phase. Otherwise, if there are no outstanding reservations for the current phase, opposite phase retry attempts are serviced as resources permit. Transition IDRA:IDRa. Resources are available and either retry_A is the currently preferred phase or else there are no reservations outstanding for the opposite phase. The transaction layer shall accept the subaction and return an appropriate terminal acknowledge code. Transition IDRA:IDRb. Resources are unavailable and retry_A is the currently preferred phase. If the reservation count for retry_A is nonzero, there are reservations outstanding for the currently preferred phase. The transaction layer shall refuse the subaction; the ack_busy_A acknowledge code returned indicates that the outbound node should continue retry attempts in the same phase. If the retry_A reservation count is zero, the outbound and inbound state machines are out of synchronization with respect to each other; the inbound dual-phase state machine corrects this by incrementing the reservation count. Transition IDRA:IDRc. Although a retry code of retry_A was received from the outbound node, the currently preferred retry phase is for retry_B. If either resources are unavailable or there are retry_B reservations outstanding, the transaction layer shall refuse the subaction but continue to hold a retry_A reservation for the outbound node. State IDRB: Retry_B received. The outbound node is attempting retransmission of an earlier request or response subaction for which the inbound node created a reservation. So long as resources are available, the inbound node grants preference to reservations earlier created for the current phase. Otherwise, if there are no outstanding reservations for the current phase, opposite phase retry attempts are serviced as resources permit. Transition IDRB:IDRa. Resources are available and either retry_B is the currently preferred phase or else there are no reservations outstanding for the opposite phase. The transaction layer shall accept the subaction and return an appropriate terminal acknowledge code. Transition IDRB:IDRb. Resources are unavailable and retry_B is the currently preferred phase. If the reservation count for retry_B is nonzero, there are reservations outstanding for the currently preferred phase. The transaction layer shall refuse the subaction; the ack_busy_B acknowledge code returned indicates that the outbound node should continue retry attempts in the same phase. If the retry_B reservation count is zero, the outbound and inbound state machines are out of synchronization with respect to each other; the inbound dual-phase state machine corrects this by incrementing the reservation count. Transition IDRB:IDRc. Although a retry code of retry_B was received from the outbound node, the currently preferred retry phase is for retry_A. If either resources are unavailable or there are retry_A reservations outstanding, the transaction layer shall refuse the subaction but continue to hold a retry_B reservation for the outbound node.
7.4 CSR architecture transactions mapped to serial bus The CSR-architecture-specified transactions are mapped into serial bus transactions using Table 7-8. All serial bus nodes shall implement support for transaction data requests with a transaction type of READ or WRITE, a data length of four, a destination address that is quadlet aligned, and a packet format of QUADLET TCODE. These correspond to the read4 and write4 requests of the CSR architecture.
194
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 7-8—CSR architecture/serial bus transaction mapping CSR architecture transaction
Serial bus transaction
readna
Transaction data request, transaction type of READ, length of n
writena
Transaction data request, transaction type of WRITE, length of n
b
lockn
Transaction data request, transaction type of LOCK, length of n
a n b
is 1, 2, 4, 8, 16 or 64 for CSR-architecture-specified read and write transactions. n shall be 4 or 8 for CSR-architecture-specified lock transactions.
All other transaction support, i.e., transaction data requests with a data length other than four, a destination address that is not quadlet aligned, or lock requests, is optional. NOTE—Transaction support for block reads or writes for some arbitrary data length n does not necessarily imply transaction support for any other length block read or write.
Copyright © 2008 IEEE. All rights reserved.
195
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
196
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
8. Serial bus management (SBM) specification 8.1 SBM summary This clause describes the functions and capabilities of the SBM layer. Figure Q.4 graphically illustrates the relationships between the hardware and software entities located within a serial bus node: the PHY layer, the link layer, the transaction layer, the SBM layer and, implicitly, application elements at the same node. The functions of SBM include bus management, isochronous resource management, and node control. Of these three, only node control is required at all nodes with an active link and transaction layer. At least one IRMcapable node is required on any serial bus on which there is isochronous traffic. NOTE—Annex H provides examples of the SBM procedures specified in this clause.
8.1.1 Node control The node controller implements the CSRs required by all serial bus nodes and communicates with the PHY, link, and transaction layers and any applications, as shown in Figure Q.4.
8.1.2 IRM (cable environment) Within the cable environment, the IRM is a part of the SBM layer. The IRM provides the resources necessary for serial bus nodes to allocate and deallocate cooperatively the isochronous resources, channels, and bandwidth required for orderly isochronous operations. The IRM, whose location is known immediately upon completion of the self-identify process, also provides a common location where serial bus nodes may determine the identity of the bus manager, if one is present. In the absence of a bus manager, the IRM may assume some bus management functions, such as a limited style of power management or the activation of a cycle master.
8.1.3 IRM (backplane environment) There is no requirement for isochronous resource management within the backplane environment, only a requirement for the basic services provided by the node controller. After a power-on reset (POR) or command reset has been completed within the backplane environment, nodes on the serial bus may begin to arbitrate for asynchronous transfers once an arbitration reset gap has been detected. If a serial bus in the backplane environment supports isochronous operations, the isochronous facilities should be provided and managed in essentially the same fashion as in the cable environment. Adherence to this guideline will facilitate the development of common management software for use in both environments. Equally important, it simplifies the interconnection of both backplane and cable serial buses when isochronous data crosses the bridge.
8.1.4 Bus manager (cable environment) The bus manager, if present, is also a part of the SBM layer. The bus manager provides management services to other nodes on the serial bus. These include activation of a cycle master, performance optimization, power management, speed management, and topology management. There are procedures described later that govern the orderly selection of a bus manager from potentially many candidates for the role of bus manager.
Copyright © 2008 IEEE. All rights reserved.
197
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
8.2 SBM services These services exist at the interface between the SBM layer and application(s) executing at the same node. Some services originate within an application and control actions within the SBM layer; others come from the SBM layer and communicate changes of state within this layer or on the bus.
8.2.1 Serial bus control request (SB_CONTROL.request) An application uses this service to request the SBM layer to perform specific actions or to specify bus management and node control parameters. Applications also use it to request status about the SBM layer. The SBM layer shall process the request immediately upon receipt. The SBM layer confirms this service. This service shall provide the following actions: —
Reset. The SBM layer shall request the PHY layer to reset the bus and initialize itself and shall request the link and transaction layers to discard all pending transactions and subactions. The link layer shall disable reception of all nonbroadcast packets and disable transmission of all packets. The transaction layer shall not accept data requests from applications.
—
Initialize. The SBM layer shall request the link and transaction layers to discard all pending transactions and subactions. The link layer shall enable reception of all nonbroadcast packets and enable transmission of all packets. The transaction layer shall accept data requests from applications.
—
Link-on. The SBM layer shall request the PHY layer to transmit a link-on packet to the designated node. (Cable environment only: required for bus manager nodes, optional for IRM nodes. Only to be used by active bus manager, or, if there is no bus manager, the active IRM.)
—
Present Status. The SBM layer shall return status to the application via the serial bus control confirmation service.
—
PHY configuration. The SBM layer shall request the PHY layer to transmit a PHY configuration packet. (Cable environment only: required for bus manager and IRM nodes. Only to be used by active bus manager, or, if there is no bus manager, the active IRM.)
NOTE—The PHY configuration action should never be used in single-node buses.
If the action is Reset or Initialize, the following parameters are communicated to the SBM layer via this service: —
Bandwidth Set-Aside. When a bus reset occurs, the bus manager shall reduce the available isochronous bandwidth by the quantity of bandwidth allocation units specified by this parameter. (Cable environment only: required for bus manager and IRM nodes. Only to be used by active bus manager, or, if there is no bus manager, the active IRM.)
—
Enable IRM. (Valid only in the backplane environment.) If this Boolean parameter is TRUE, the SBM layer shall enable the IRM capabilities. At most one application element within the backplane environment shall set this parameter to TRUE; all other application elements shall communicate FALSE to the SBM layers at their own nodes.
A serial bus reset has the potential to disrupt isochronous data flow. Isochronous devices may be designed to compensate adequately for occasional disruptions, but until some time elapses subsequent to the bus reset and equilibrium is reestablished they may be more vulnerable to disruption than before. Any additional bus resets that occur during this time increase the likelihood that users perceive an interruption in isochronous data flow. For this reason, applications, the bus manager, and the node controller should not make an SB_CONTROL.request that specifies a Reset action until 2 s have elapsed subsequent to the completion of the self-identify process that follows a bus reset—except for the purpose of confirming that a uniform gap_count has been set by a transmitted PHY configuration packet.
198
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
When gap_count has a value other than 63, bus resets initiated by software should be immediately preceded by the transmission of a PHY configuration packet with a nonzero T bit and gap_cnt equal to the current value of gap_count. Without this precaution, the bus manager is almost certain to transmit a PHY configuration packet to restore the optimal value of gap_count and then generate an additional bus reset (see 8.4.5.2 for details) If the action is Link-on, the SBM layer receives the following parameter via this service: —
Physical ID. This parameter shall specify the 6-bit physical_ID of the serial bus node that is to receive the link-on packet.
If the action is PHY configuration, the SBM layer receives the following parameters via this service: —
Set force root. If this flag is set, the Physical ID parameter shall specify the 6-bit physical_ID of the serial bus node that is to set its force_root bit, and all other nodes shall clear their force_root bit.
—
Physical ID. See set force root.
—
Set gap count. If this flag is set, the gap count parameter shall specify the 6-bit gap_cnt value to be used for all nodes on the bus.
—
Gap count. See set gap count.
8.2.2 Serial bus control confirmation (SB_CONTROL.confirmation) The SBM layer uses this service to confirm to an application the results of a serial bus control request service. The SBM layer shall communicate this service to the application upon completion of a serial bus control request. There are no actions provided by this service. This service shall communicate the following parameters after a control request of Present Status: a)
Bandwidth Set-aside. The actual amount of bandwidth the bus manager was able to subtract from the BANDWIDTH_AVAILABLE register at the IRM. This parameter is available only in the cable environment and if the node is the active bus manager or, if there is no bus manager, the active IRM.
b)
Bus Manager ID. The 6-bit physical_ID of the bus manager. If no bus manager is active, this parameter shall have a value of 3F16. This parameter is available only in the cable environment and if the node is bus-manager- or IRM-capable.
c)
Cycle Master ID. The 6-bit physical_ID of the cycle master. If no cycle master is active, this parameter shall have a value of 3F16. This parameter is available only if the node is bus-manager- or IRM-capable.
d)
Force Root. The force_root variable of the PHY of this node.
e)
Gap Count. The gap_cnt variable of the PHY of this node. Cable environment only.
f)
IRM. The 6-bit physical_ID of the IRM. If no IRM is active, this parameter shall have a value of 3F16. This parameter is available only if the node is bus-manager- or IRM-capable.
g)
Physical ID. The 6-bit physical_ID of this node.
h)
Root ID. The 6-bit physical_ID of the root. If no cycle master is active, this parameter shall have a value of 3F16. Cable environment only.
8.2.3 Serial bus event indication (SB_EVENT. indication) The SBM layer uses this service to indicate bus manager, node controller, or bus events to an application. There are no actions provided by this service. No response is defined for this indication. This service shall communicate the following parameters: —
BUS EVENT. This parameter shall contain the event detected on the bus. The following values are defined for this parameter: —
BUS OCCUPANCY VIOLATION DETECTED. A node on the serial bus held the bus longer than a time of MAX_BUS_OCCUPANCY.
Copyright © 2008 IEEE. All rights reserved.
199
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
—
BUS RESET START. A bus reset has started.
—
BUS RESET COMPLETE. A bus reset process has completed. In the cable environment, this is indicated by the first subaction gap after the bus reset has started.
—
CYCLE TOO LONG. The last isochronous cycle was too long. The SBM layer received this indication from the link layer. Only the bus manager and IRM shall indicate this event and then only if the node is isochronous capable.
—
CABLE POWER FAIL. In the cable environment, a loss of cable power has occurred as described in 9.2.1.7.
—
DUPLICATE CHANNEL DETECTED (Optional). A stream packet was received with a channel number equal to one of the node’s active, transmit isochronous channels.
—
HEADER CRC ERROR DETECTED. The CRC check, as described in 6.2.5.15, of the header of a received Primary Packet failed.
—
REQUEST DATA ERROR. A transaction request received by this node contained a data error, and the node returned an ack_data_error acknowledgment.
—
RESPONSE ACKNOWLEDGE MISSING. This node did not observe an acknowledgment after transmitting a transaction response packet.
—
RESPONSE DATA ERROR. This node received ack_data_error in acknowledgment of a transaction response packet.
—
RESPONSE FORMAT ERROR. This node received ack_type_error in acknowledgment of a transaction response packet.
—
RESPONSE RETRY FAILED. This node failed to transmit successfully a transaction response within the retry limits specified by Transaction Retry Limit or Transaction Retry Time-out.
—
UNEXPECTED CHANNEL DETECTED (Optional, may be signaled only at the active IRM). The IRM observed a stream packet whose channel number is not allocated in the CHANNELS_AVAILABLE register.
—
UNKNOWN TRANSACTION CODE DETECTED. The header of a Primary Packet addressed to this node or the header of an isochronous packet contained an invalid or unknown Transaction Code.
—
UNSOLICITED RESPONSE. This node received a transaction response for which there was no request pending, as determined by the transaction label and the destination contained in the response, as described in 6.2.5.3.
All of the following parameters communicated by SB_EVENT.indication are meaningful only in the cable environment when the BUS EVENT is BUS RESET: a)
Bandwidth Set-aside. The actual amount of bandwidth the bus manager was able to subtract from the BANDWIDTH_AVAILABLE register at the IRM. This parameter is available only in the cable environment and if the node is the active bus manager or, if there is no bus manager, the active IRM
b)
Bus Manager ID. The 6-bit physical_ID of the bus manager. If no bus manager is active, this parameter shall have a value of 3F16.
c)
Configuration Time-out. PHY initialization has not completed because of a timeout in the tree identify process. This parameter may indicate a loop in the serial bus topology.
d)
Cycle Master ID. The 6-bit physical_ID of the cycle master. If no cycle master is active, this parameter shall have a value of 3F16.
e)
Gap Count. The value of the gap_cnt field observed in all self-ID packets transmitted during the self-identify process. This parameter is meaningful only if the bus manager is active at this node.
f)
Gap Count Error. Either the bus manager or the IRM, if active at this node, may return this event. It indicates that the gap_cnt field does not have the same value in all the self-ID packets observed.
g)
Insufficient Cable Power. The bus manager has performed a consistency check of self-ID packets received after a bus reset and the sum of the current power requirements is greater than the sum of the power available.
200
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
h)
IRM ID. The 6-bit physical_ID of the IRM. If no IRM is active, this parameter shall have a value of 3F16.
i)
Physical ID. This parameter shall contain a unique 6-bit number, as determined by the self-identify process.
j)
Root ID. This parameter shall contain the 6-bit physical_ID of the root, as determined by the tree identify process.
k)
Self-ID Error. Either the bus manager or the IRM, if active at this node, may return this event. It indicates that a malformed self-ID packet was received, that the self-ID packets were not received in the correct sequence, or that the last self-ID packet received does not describe a root.
l)
Topology Error. Only the bus manager, if active at this node, may return this event. It is an indication that the serial bus topology described by the self-ID packets received at the bus manager describe an impossible configuration. For example, the total number of Child ports does not equal the total number of Parent ports.
8.3 SBM facilities 8.3.1 Node capabilities taxonomy Node capabilities are ranked according to functionality, from the least capable repeater nodes to the most fully capable bus manager nodes. For some of the capabilities, namely cycle master, IRM, and bus manager, at most one instance shall be active on a bus at any given moment. The configuration procedures used to determine which nodes among the candidate nodes actually assume these roles are described in 8.4.1 and 8.4.2.
8.3.1.1 Repeater (cable environment) All multiple port nodes present on a serial bus in the cable environment are, by definition, repeater nodes. This is the minimum capability required and consists of an active PHY. The PHY may be powered from the bus (via the power/ground pair in the serial bus cable) or from some other source. Repeater nodes shall a)
Have an active PHY.
b)
Function as an accurate signal repeater to propagate the signal state from the PHY port conditioned for reception to all other PHY ports conditioned for transmission.
c)
Participate in the cable initialization and normal arbitration phases.
d)
Be capable of functioning as the root of a serial bus.
e)
Reconfigure their operational characteristics in response to PHY configuration packets.
8.3.1.2 Transaction capable Any node on a serial bus with an enabled link layer shall be transaction capable, i.e., capable of origination of and response to asynchronous transactions with other transaction capable nodes on the bus. In the cable environment, a repeater node that contains an unpowered or inactive link layer may be transformed into a transaction capable node by means of a PHY link-on packet. Transaction capable nodes shall a)
In the backplane environment, have an active PHY, or In the cable environment, implement all the capabilities of repeater nodes.
b)
Have an active link layer.
c)
Implement the STATE_CLEAR, STATE_SET, NODE_IDS, RESET_START, and SPLIT_ TIMEOUT registers.
Transaction capable nodes should implement configuration ROM in the general ROM format.
Copyright © 2008 IEEE. All rights reserved.
201
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
See Annex J for requirements on transaction integrity safeguards. NOTE—An active link layer may be in a state of reduced functionality in which it can detect packets addressed to the node and return an ack_tardy but not generate any other responses.
8.3.1.3 Isochronous capable Any node on a serial bus that can either send or receive isochronous packets is isochronous capable. Isochronous capable nodes shall a)
Implement all the capabilities of transaction capable nodes
b)
Implement configuration ROM in the general ROM format
c)
Implement the CYCLE_TIME register and a free-running 24.576 MHz clock that updates the CYCLE_TIME register
8.3.1.4 Cycle master capable For a serial bus to be capable of isochronous operations, there shall be a cycle master. Through a process described in 8.4.1.3 and 8.4.2.6, a single cycle master shall be selected from possible candidates after bus reset. A node that is capable of becoming the cycle master shall a)
Implement all the capabilities of isochronous capable nodes.
b)
Be able to generate cycle start events triggered by the 8 kHz clock synchronized to the CYCLE_TIME register and broadcast the corresponding cycle start packets.
c)
Implement the BUS_TIME register.
8.3.1.5 IRM capable For a serial bus to be capable of both isochronous operations and asynchronous stream packet transmission on a default broadcast channel, there shall be an IRM. Through a process described for the backplane environment by 8.4.1.2 and for the cable environment by 8.4.2.3, a single IRM shall be selected from possible candidates after a bus reset. A node that is capable of becoming the IRM shall a)
Implement all the capabilities of transaction capable nodes.
b)
Implement the BUS_MANAGER_ID, BANDWIDTH_AVAILABLE, CHANNELS_AVAILABLE, and BROADCAST_CHANNEL registers.
c)
In the cable environment, be able to analyze received self-ID packets in order to correctly determine the physical_ID of the IRM node from all the contenders for this role.
d)
Implement configuration ROM in the general format.
e)
Execute the responsibilities of the IRM specified by 8.4.2.3.
NOTE—In a sense, the name IRM (isochronous resource manager) is misleading since such a node does not directly “manage” isochronous resources such as bandwidth and channels. In actual fact, the IRM provides a single location where other serial bus nodes may cooperatively record their usage of isochronous resources.
In the absence of a bus manager, the IRM may perform the following bus management functions: —
Gap count optimization
—
Limited power management
—
Set a node’s force_root flag to TRUE, subject to the requirements of 8.4.2.6
8.3.1.6 Bus manager capable (cable environment) The most fully capable nodes on a serial bus are those that may become bus managers. Bus manager capable nodes shall be IRM capable, may provide advanced power management, and may provide facilities to optimize serial bus performance and describe the topology of the bus. Through a process described in
202
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
8.4.2.5, a single bus manager shall be selected from all bus manager capable nodes; this occurs any time there is a bus reset. A node that is capable of becoming the bus manager shall a)
Implement all the capabilities of IRM-capable nodes.
b)
Implement the TOPOLOGY_MAP registers.
NOTE—Just as the term IRM is somewhat misleading, so is the description bus manager with respect to some of its functions. With respect to the topology information, the bus manager does not “manage” this information as much as it publishes it. However, for serial bus optimization and power management, the bus manager takes a more active role and may actually configure nodes on the serial bus.
8.3.2 Command and status registers The serial bus uses the CSR architecture, whose formal standard designations are IEEE Std 1212-2001 and ISO/IEC 13213:1994, to define the framework and selected contents of its command and status registers (CSRs) and for configuration ROM entries. This standard includes the minimal CSR and configuration ROM requirements needed for compliant serial bus implementations as well as optional CSR and ROM entries for expanded functionality. The CSR architecture is the reference for more details on the use of optional parts of required CSRs, as well as optional CSR and ROM entries needed for any purpose, including bus-dependent and unit-dependent applications. One example of an optional bus-dependent application is the SBP, which describes a command and status transfer protocol supporting a serial version of Small Computer Systems Interface (SCSI) implemented on the serial bus. Consult the SBP document for details relating to CSRs and configuration ROM specific to the Serial Bus Protocol (SBP).
8.3.2.1 Reset conditions The CSR architecture defines two types of reset events for nodes: power reset and command reset. The serial bus defines an additional reset type: bus reset. Table 8-1 describes the conditions that generate these resets.
Table 8-1—Reset types Reset Type
Description
Power reset
Restoration of primary power to link, PHY, and bus management (all environments): Upon a power reset, all CSR registers shall return to their initial values, as defined by the CSR architecture and this standard. In both the backplane and cable environments, the PHY layer shall also be reset. In the cable environment, if the PHY layer is powered locally it shall initiate a bus reset. In the backplane environment, a node that is “live inserted” shall undergo a power reset.
Bus reset (cable)
Bus reconfiguration (cable environment): A change in the topology of a serial bus shall cause a bus reset. Two events can change serial bus topology: the physical addition or removal of a node or a change between the powered and unpowered states of the PHY layer of a node. No bus reset is required when the power state of other layers, e.g., the link layer, changes, as long as the PHY remains continuously powered. In addition to these requirements, any serial bus node may initiate a bus reset at its option.
Bus reset (backplane)
Bus reinitialization (backplane environment): A bus reset may be initiated by the action of any node on the serial bus. This is done with communication of the BUS_RESET signal defined in 5.3.3. A node that is “live inserted” shall not initiate a bus reset.
Command reset
Write to RESET_START register (all environments): In the backplane environment, a command reset shall cause a reset of the PHY layer. In the cable environment, a command reset shall not cause a reset of the PHY layer nor a bus reset.
Copyright © 2008 IEEE. All rights reserved.
203
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
In general, most CSRs return to their initial values upon either a power reset, bus reset, or command reset. However, individual CSRs are defined with exceptions to this rule. The subclauses that follow and describe individual CSRs specify the special reset rules that are exceptions to the general rule.
8.3.2.2 CSR architecture core registers The CSR architecture standardizes the function of the core CSRs and their location within the initial register space. The addresses of these core registers are specified in terms of offsets within the initial register space, where the offset of the start of initial register space (from the beginning of the initial node space) is FFFF F000 000016. Table 8-2 defines the core registers defined by the CSR architecture. The offset value is the byte offset measured from the beginning of the initial register space.
Table 8-2—Core CSR locations Offset
Name
Description
00016
STATE_CLEARa
State and control information
00416
STATE_SET*
Sets STATE_CLEAR bits
00816
NODE_IDS*
Specifies 16-bit node_ID value
00C16
RESET_START*
Resets state of node
01016–01416
INDIRECT_ADDRESS, INDIRECT_DATA
Indirectly access ROMs > 1024 bytes
01816–01C16
SPLIT_TIMEOUT_HI, SPLIT_TIMEOUT_LO
Split-request timeout
02016–02C16
ARGUMENT_HI, ARGUMENT_LO, TEST_START, TEST_STATUS
Optional diagnostic-test interface
03016–04C16
UNITS_BASE, UNITS_BOUND, MEMORY_BASE, MEMORY_BOUND
Never implemented
05016–05416
INTERRUPT_TARGET,
Optional broadcast/nodecast interrupt
05816–07C16
CLOCK_VALUE, CLOCK_TICK_PERIOD, CLOCK_STROBE_ARR IVED, CLOCK_INFO
Synchronized time-of-day value and control
08016–0FC16
MESSAGE_REQUEST, MESSAGE_RESPONSE
Optional message passing registers
10016–17C16
INTERRUPT_ MASK
Reserved for CSR architecture
18016–1FC16
ERROR_LOG_BUFFER
Reserved for serial bus
20016–3FC16
Serial bus dependent
See Table 8-3
aRequired
in whole or in part
8.3.2.2.1 STATE_CLEAR register The STATE_CLEAR register provides standard fields and an 8-bit bus-dependent field, as illustrated in Figure 8-1. The CSR architecture fully defines the shaded fields (unit_depend, dreq, r, elog, atn, off, and state). The optional 16-bit unit_depend field is available for unit-dependent applications, as defined within the CSR architecture.
204
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 8-1—STATE_CLEAR format The bus_depend field provides bus-dependent information; for a serial bus, Figure 8-2 shows the format of the bus_depend field. definition gone
r
r
r
r
abdicate
1
1
1
1
1
1
linkoff
cmstr
1
1
zero
zero
initial values zero
zero
zero
zero
zero
zero
bus reset and command reset values one
zero
zero
zero
zero
zero
unchanged unchanged
read values last update
zero
zero
zero
zero
last write
last write last update
write effects nonzero value clears corresponding (writeable) bit
Figure 8-2—STATE_CLEAR.bus_depend field Although the lost bit is optional within the CSR architecture, serial bus nodes shall implement the lost bit. In the cable environment, the lost bit is not directly affected by a bus reset. However, the lost bit shall be set to 1 during a bus reset if a power reset or transition to the dead state (as defined by the CSR architecture) has occurred. Although the dreq bit is optional within the CSR architecture, serial bus nodes capable of originating transaction requests shall implement the dreq bit. In addition to the other requirements of the CSR architecture, these request-capable nodes shall be unaffected by a bus reset. If the dreq bit is subsequently set to one, the node shall not transmit transaction requests. Serial bus nodes that are not request capable, i.e., nodes that only respond to requests originated by other nodes, shall implement this bit as one. The r, elog, atn, and off bits are optional within the CSR architecture. In addition to their properties defined within the CSR architecture, the elog bit shall be unchanged by a bus reset. A serial bus reserves the atn and off bits. The four shaded r bits are reserved for future definition by the serial bus. The gone bit shall be set to one on a power reset, command reset, or bus reset. Units on a node have the option of implementing an equivalent gone bit (within their unit-dependent registers) and ignoring the value of the STATE_CLEAR.gone bit. Multiple-unit nodes are expected to have unit-dependent gone bits, if some
Copyright © 2008 IEEE. All rights reserved.
205
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
of the units (such as a processor, which initializes other nodes, and a DMA adapter, which is initialized by others) are expected to be reactivated (after a bus reset) at different times. If a unit does not have an equivalent gone bit, then that unit shall not transmit transaction requests while STATE_CLEAR.gone is set. However, a unit that independently resumes operation after a bus reset may clear its own STATE_CLEAR.gone bit before accessing the bus. To other nodes, the STATE_CLEAR.gone bit of this node may be cleared before becoming visible to other nodes (thus providing the appearance that the gone bit was never set). The abdicate bit shall be implemented by bus manager-capable nodes; it controls the behavior of the node during contention for the role of bus manager. When abdicate is zero, the incumbency of the node prior to a bus reset determines the amount of time the node waits before contending to become the bus manager. As specified by this standard, the incumbent manager contends immediately after the first subaction gap that follows a bus reset while nonincumbent, bus manager-capable nodes wait 125 ms before contending. When abdicate is one, the node shall wait 125 ms before contending, whether incumbent or not. In the cable environment, nodes whose link layer draws power from the bus shall implement the linkoff bit. If the value of the linkoff bit is zero, the link layer of the node is active. For nodes whose link layer draws power from the bus, a write of one to the linkoff bit in the STATE_SET register shall cause the link layer to become inactive and unpowered. The link layer of the node may be subsequently reactivated by a link-on packet. Cycle-master-capable nodes shall implement the cmstr bit. The cmstr bit enables the node as a cycle master. A cmstr value of one enables cycle master operations while a zero value disables cycle master operations. Only the bus manager or, in the absence of a bus manager, the IRM may change the state of cmstr by means of a write transaction. Any request that attempts to set cmstr to one shall be ignored if the recipient is not the root. An active cycle master that detects the CYCLE_TOO_LONG event shall clear the cmstr bit. In the cable environment, the value of cmstr subsequent to a bus reset is determined as follows: a)
b)
If this node 1)
Is not the root, the cmstr bit shall be cleared to zero, or
2)
Had been the root prior to the bus reset, cmstr shall retain its prior value.
Otherwise, cmstr shall be set to the value of the cmc bit (from the bus information block).
Cycle master operations are controlled by the cmstr bit in the STATE_SET register defined in 8.3.2.2.2.
8.3.2.2.2 STATE_SET register A write of one to a bit in the STATE_CLEAR register clears the corresponding bit position in the STATE_SET register (if that bit is writable in the STATE_SET register).
8.3.2.2.3 NODE_IDS register The NODE_IDS register reports and permits modification of a node’s bus_ID and physical_ID. Together these form a 16-bit node_ID used by the link to determine if a primary packet is addressed to the node. A serial bus reserves the 16-bit bus-dependent field, as indicated by the shaded field within Figure 8-3. The 10-bit read/write bus_ID field provides software with a mechanism for reconfiguration of the initial node address space. The bus_ID field permits node addresses on one bus to be distinguished from those on another. All nodes on a bus shall have identical bus_ID values.
206
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
definition local_ID
bus_ID 10
6
reserved 16
initial values ones
physical ID
zeros
command reset values unchanged
zeros
read values last write
last update
zeros
write effects (cable environment) stored
ignored
ignored
write effects (backplane environment) stored
ignored
Figure 8-3—NODE_IDS format NOTE—A bus consists of all physically connected nodes that are within the same arbitration domain, i.e., nodes that receive their arbitration grant(s) from the same root node.
The 6-bit local_ID field shall have a value generated as a side-effect of the bus initialization process. Within this standard, the value of NODE_IDS.local_ID is also known as the physical_ID of the node. This field is read-only in the cable environment and read/write in the backplane environment. NOTE—The CSR architecture requires that if there are any side-effects of a nonbroadcast write transaction to a register, the affected node delay the return of a transaction response until all effects of the write are complete. In the case of the NODE_IDS register, a return of resp_complete indicates that the node recognizes transactions to the newly assigned NODE_IDS value. The contents of the source_ID field of the response packet are required to be equal to the 16 MSBs of the updated NODE_IDS register.
8.3.2.2.4 Command reset effects A write to the RESET_START register performs an immediate command reset, as defined in the CSR architecture. A command reset shall have no effects upon any of the serial-bus-dependent registers defined by this standard.
8.3.2.2.5 INDIRECT_ADDRESS and INDIRECT_DATA registers The INDIRECT_ADDRESS and INDIRECT_DATA registers are reserved. All access to the configuration ROM shall be done with directly addressed reads. The serial bus configuration ROM may be longer than 1024 bytes by extending into the initial units space.
8.3.2.2.6 SPLIT_TIMEOUT register Split-transaction error detection requires that all nodes on a serial bus share the same time-out value and that requester and responder behave in complementary fashion. The SPLIT_TIMEOUT register establishes the time-out value for the detection of split-transaction errors. The value of SPLIT_TIMEOUT is the maximum time permitted for the receipt of a response subaction after the transmission of a request subaction. After this time, a responder shall not transmit a response for the request subaction and a requester shall terminate the transaction with a request status of TIMEOUT. For a requester the time-out period commences when
Copyright © 2008 IEEE. All rights reserved.
207
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
an ack_pending is received in response to a request subaction. A responder starts the time-out period when an ack_pending is transmitted. Figure 8-4 illustrates the portions of the SPLIT_TIMEOUT register implemented on a serial bus.
definition reserved cycles
29
13
sec 3
reserved 19
initial values zeros 800
zeros
command reset and bus reset values zeros
u
unchanged
zeros
read values zeros
w
last write
zeros
write effects ignored stored
stored ignored
Figure 8-4—SPLIT_TIMEOUT format
NOTE—A requester should not reuse the transaction label from an expired request subaction in a subsequent request subaction to the same node unless at least twice the split time-out period has elapsed since the initiation of the expired subaction.
The sec field, in units of seconds, and the cycles field, in units of 125 μs, together specify the time-out value. The value of cycles shall be less than 8000. The bus manager, if present, shall insure that all nodes on the bus have identical values in their SPLIT_TIMEOUT registers. The minimum time-out value is 800 cycles (0.1 s). If a value smaller than this is written to the SPLIT_TIMEOUT register the node shall not round the stored value but shall behave as if a value of 800 had been stored. NOTE—The serial bus definition of the SPLIT_TIMEOUT register differs from that of the CSR architecture. The serial bus interprets the 13 MSBs of the SPLIT_TIMEOUT_LO register as units of 1/8000 s, rather than a true binary fraction of a second with units of 1/8192 s. Since precise time-outs are not necessary, the bus manager may ignore this difference when calculating values for use within the SPLIT_TIMEOUT_LO register.
8.3.2.2.7 ARGUMENT, TEST_START, and TEST_STATUS registers The ARGUMENT, TEST_START, and TEST_STATUS registers are optional. If implemented, they are used to initiate or monitor the built-in test capabilities of a node, as defined in the CSR architecture.
208
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
8.3.2.2.8 UNITS_BASE, UNITS_BOUND, MEMORY_BASE, and MEMORY_BOUND registers The UNITS_BASE, UNITS_BOUND, MEMORY_BASE, and MEMORY_BOUND registers are reserved. The CSR architecture defines these registers only for the 32-bit or 64-bit extended address-space models; a serial bus uses the 64-bit fixed address-space model.
8.3.2.2.9 INTERRUPT_TARGET and INTERRUPT_MASK registers The INTERRUPT_TARGET and INTERRUPT_MASK registers are optional. If implemented, they provide a way for sending interrupts to all units on the node, as defined in the CSR architecture.
8.3.2.2.10 CLOCK_VALUE, CLOCK_TICK_PERIOD, CLOCK_STROBE_ARRIVED, and CLOCK_INFO registers The CLOCK_VALUE, CLOCK_TICK_PERIOD, CLOCK_STROBE_ARRIVED, and CLOCK_INFO registers are optional. Since the CYCLE_TIME register provides a nearly equivalent functionality, serial bus nodes usually do not implement these registers.
8.3.2.2.11 MESSAGE_REQUEST and MESSAGE_RESPONSE registers The MESSAGE_REQUEST and MESSAGE_RESPONSE registers are optional. If implemented, they provide target addresses for message transactions broadcast to all units on the bus or all units within the node, as defined by the CSR architecture.
8.3.2.3 Serial-Bus-dependent registers The CSR architecture reserves a portion of the initial register space for bus-dependent uses. The addresses of these bus-dependent registers are specified in terms of offsets within the initial register space, where the base of the initial register space (from the beginning of the initial node space) is FFFF F000 000016. Table 8-3 summarizes these bus-dependent registers.
Table 8-3—Serial-Bus-dependent registers Offset
Name
Notes
20016
CYCLE_TIME
For nodes providing isochronous services.
20416
BUS_TIME
For nodes requiring synchronized bus time.
20816
POWER_FAIL_IMMINENT
For nodes needing power-fail warning.
20C16
POWER_SOURCE
21016
BUSY_TIMEOUT
For transaction-capable nodes.
21416–21816
Reserved. a
21C16
BUS_MANAGER_ID
For selecting or locating the bus manager.
22016
BANDWIDTH_AVAILABLEa
For bandwidth allocation of IRM-capable nodes.
22416–22816
CHANNELS_AVAILABLEa
For channel allocation of IRM-capable nodes.
22C16
MAINT_CONTROL
For introducing diagnostic error conditions.
23016
MAINT_UTILITY
Copyright © 2008 IEEE. All rights reserved.
209
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 8-3—Serial-Bus-dependent registers (continued) Offset 23416
Name BROADCAST_CHANNEL
23816–3FC16 aOnly
Notes For asynchronous stream broadcast management of IRM-capable nodes. Reserved.
quadlet read and quadlet lock (compare and swap) transactions supported.
The following subclauses provide detailed definitions of the serial-bus-dependent registers.
8.3.2.3.1 CYCLE_TIME register The CYCLE_TIME register is optional. All nodes capable of providing isochronous services shall implement this register. Nodes that are isochronous capable shall implement a 24.576 MHz clock that shall run freely and update the contents of the CYCLE_TIME register. A write to the CYCLE_TIME register shall initialize the clock hardware to the value contained in the write transaction. Neither a bus reset nor a command reset shall affect the time maintained by clock hardware. The CYCLE_TIME register provides fields that specify the current time value. Figure 8-5 illustrates the formats of these fields.
Figure 8-5—CYCLE_TIME format The 7-bit read/write second_count field shall increment on each carry from the cycle_count field, with the exception that an increment from the value 127 shall cause a wraparound to zero and shall carry into the BUS_TIME.second_count_hi field. The 13-bit read/write cycle_count field shall increment on each carry from the cycle_offset field, with the exception that an increment from the value 7999 shall cause a wraparound to zero and shall carry into the second_count field. The value is the fractional part of the second of the current time, in units of 125 μs.
210
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The 12-bit read/write cycle_offset field shall be updated on each tick of the local 24.576 MHz PHY clock, with the exception that an increment from the value 3071 shall cause a wraparound to zero and shall carry into the cycle_count field. The value is the fractional part of the isochronous cycle of the current time, in units that are counts of the 24.576 MHz clock. Isochronous-capable nodes whose STATE_CLEAR.cmstr bit is zero are called cycle slaves. Cycle slaves shall update the value of the CYCLE_TIME register based upon the time value received in each cycle start packet. A cycle slave shall implement a synchronization mechanism between the cycle start packets and the CYCLE_TIME register such that time, as observed by the values of the CYCLE_TIME register, never appears to move backwards. The details of cycle slave synchronization mechanisms (as well as their sensitivity to jitter and noise) are implementation dependent and beyond the scope of this standard. Cycle-master-capable nodes shall implement hardware that can arbitrate for the bus in order to transmit a cycle start packet each time the cycle_count field increments. The cycle master (i.e., a cycle-master-capable node that is the root with its STATE_CLEAR.cmstr bit set to one), shall insert the current CYCLE_TIME value into each cycle start packet transmitted. The CYCLE_TIME value inserted into the cycle start packet shall be the time at which the cycle start packet was transmitted and not the time of the cycle start event. If bus arbitration for and transmission of the cycle start packet communicating the start of interval N both begin within isochronous interval N, then the minimum cycle_offset specified by the cycle start packet shall be 17. Due to the asynchronous occurrence of bus resets, it is possible in rare circumstances for transmission of a cycle start packet to be delayed into the interval subsequent to the one in which arbitration was requested. That is, a second cycle sync event occurs before the first cycle start packet is formed and transmitted. In such rare circumstances, there is no requirement for the link to enforce the minimum cycle_offset value.
8.3.2.3.2 BUS_TIME register The BUS_TIME register is optional. Cycle-master-capable nodes shall implement this register. May be initialized by the bus manager or, in the absence of a bus manager, the IRM. A broadcast write transaction shall be used to initialize the BUS_TIME register. The BUS_TIME register provides a measure of the current time in seconds and has a range of 232 s or approximately 136 years. Figure 8-6 shows the format of this register.
Figure 8-6—BUS_TIME format
Copyright © 2008 IEEE. All rights reserved.
211
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The 25-bit read/write second_count_hi CYCLE_TIME.second_count field.
field
shall
increment
on
each
carry
from
the
The 7-bit read-only second count_lo field is the current value of the CYCLE_TIME.second_count field.
8.3.2.3.3 POWER_FAIL_IMMINENT register The POWER_FAIL_IMMINENT register is optional; and, if this register is implemented, the POWER_SOURCE register shall also be implemented. The POWER_FAIL_IMMINENT register provides a means of notifying serial bus nodes that a power failure is about to occur. Within a backplane environment, the node responsible for the power supply, upon sensing an imminent failure, should perform a broadcast write (using node address 3F16 to the POWER_FAIL_IMMINENT register. The data written into this register includes the node_ID of the power-supply node and a time value that specifies the time remaining before the power supply is expected to go out of regulation. Figure 8-7 shows the format of this register.
Figure 8-7—POWER_FAIL_IMMINENT format The read/write pfi_flag bit indicates that a power failure is imminent. If the pfi_flag bit is one, a power failure is imminent; otherwise, the values within this register shall be ignored. The 15-bit read/write pfi_delay field defines the approximate time that remains before the power supply goes out of regulation, in hundredths of milliseconds. A value of zero represents the minimum allowable amount of time (at least 100 μs) before the power supply is expected to go out of regulation. The 16-bit read/write pfi_source field provides the 16-bit node_ID of the source of the power-fail-imminent broadcast. To validate the applicability of the POWER_FAIL_IMMINENT field, the node shall compare the values contained within its POWER_FAIL_IMMINENT.pfi_source and POWER_SOURCE.power_source fields. Unless these two values are the same, the value of the pfi_delay field shall be ignored.
8.3.2.3.4 POWER_SOURCE register The POWER_SOURCE register is optional; and, if this POWER_FAIL_IMMINENT register shall also be implemented.
212
register
is
implemented,
the
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The POWER_SOURCE register is used to screen the writes to the POWER_FAIL_IMMINENT register of the node, so that only those from the power supply of the node are accepted. The bus manager shall initialize this register during the configuration process. The techniques used by the bus manager to identify the affiliation between power supply nodes and their power consuming nodes are beyond the scope of this standard. Figure 8-8 shows the format of this register.
Figure 8-8—POWER_SOURCE format The 16-bit read/write power_source field is used to select which of the writes to the POWER_FAIL_IMMINENT register shall be ignored. See 8.3.2.2.10 for details.
8.3.2.3.5 BUSY_TIMEOUT register The BUSY_TIMEOUT is optional; and, if this register is not implemented, the node does not support retries. The BUSY_TIMEOUT register provides fields that make visible transaction layer state variables that control the behavior of retry protocols. Figure 8-9 illustrates the format of these fields.
Figure 8-9—BUSY_TIMEOUT format
The r and reserved bits are reserved for future definition by this standard.
Copyright © 2008 IEEE. All rights reserved.
213
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The second_limit and cycle_limit fields control the retry behavior utilized by the transaction layer when dual-phase retry protocol is in use, as described in 7.3.5.1. A zero value in these fields disables dual-phase retry protocol. A node whose transaction layer does not implement dual-phase retry protocol shall ignore writes to the second_limit and cycle_limit fields, and a read of the BUSY_TIMEOUT register shall return zeros. Together, the second_limit and cycle_limit fields define a time limit for retry attempts. The format of these fields and the units used are identical to the second_count and cycle_count fields in the CYCLE_TIME register. Nodes that implement the dual-phase retry protocol shall not retransmit a packet after this time limit has elapsed. Time counts from the first transmission of the packet. The retry_limit field controls the retry behavior utilized by the transaction layer when the single-phase retry protocol is in use, as described in 7.3.4. A node engaged in single-phase retry protocol shall not attempt retransmission of the busied packet if the retry_limit field is zero. Otherwise, the node shall retransmit the packet retry_limit times or until the receipt of something other than a busy acknowledgment.
8.3.2.3.6 PRIORITY_BUDGET register The PRIORITY_BUDGET register is reserved for backplane environments. The PRIORITY_BUDGET register is optional for cable environments. This register shall be implemented on nodes that use asynchronous priority arbitration for the primary packets enumerated by Table 8-4 and, if implemented, shall be located at offset 21816 within initial register space. The PRIORITY_BUDGET register permits the bus manager to configure a node’s asynchronous arbitration behavior. This register provides a mechanism for a node to be granted permission to use priority arbitration during the asynchronous period. The definition is given by Figure 8-10.
definition pri_max
reserved 18
6
r 2
pri_req 6
initial values zeros
zeros
v read values
zeros
v
z
u
write effects ignored
stored
Figure 8-10—PRIORITY_BUDGET format The pri_max field shall specify the maximum value the node expects to be stored in pri_req. If a write request attempts to update pri_req to a larger value, the result is unspecified. The pri_req field shall specify the maximum number of certain priority arbitration requests the link is permitted to make of the PHY during a fairness interval. The primary packet transaction codes for which priority arbitration may be used are specified by Table 8-4; PHY packets and response packets may also use priority arbitration (see 6.3.1.1). A serial bus fairness interval exists between the occurrence of an arbitration reset gap and the first subsequent arbitration reset gap. The pri_req default value of zero is equivalent to the fair arbitration behavior specified by this standard; any priority requests enabled by a nonzero value of pri_req are in addition to the fair arbitration request permitted each node.
214
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 8-4—Request subactions eligible for priority asynchronous arbitration tcode
Name
Comment
0
Write request for data quadlet
Request subaction, quadlet payload
1
Write request for data block
Request subaction, block payload
4
Read request for data quadlet
Request subaction, no payload
5
Read request for data block
Request subaction, quadlet (data_length) payload
9
Lock request
Request subaction, block payload
A16
Stream data
Asynchronous subaction, block payload
Each time a link receives PHY status of ARB_RESET_GAP, it shall reset an internal variable, priority_request_count, to the value of pri_req. The link may use priority asynchronous arbitration for any of the transaction codes specified by Table 8-4 so long as priority_request_count is nonzero. The link may also issue a single priority arbitration request in place of a fair arbitration request if no fair arbitration request has been granted within the current fairness interval. Even if either of those two conditions is met, if a node receives an ack_busy_X, ack_busy_A, or ack_busy_B in acknowledgment of a request subaction, the node shall not retransmit the request packet until the next fairness interval. Each time a priority arbitration request is granted (either as the result of a link request or the use of the Hold protocol to concatenate a packet) for one of the transaction codes specified and priority_request_count is nonzero, the link shall decrement priority_request_count. The bus manager shall ensure that the sum of the values of pri_req in the PRIORITY_BUDGET registers of all nodes on the local bus is less than or equal to 63 minus the number of nodes.
8.3.2.3.7 BUS_MANAGER_ID register The BUS_MANAGER_ID register is reserved for backplane environments. The BUS_MANAGER_ID register is optional for cable environments. This register shall be implemented on IRM-capable and bus-manager-capable nodes. Special transaction limitations: Only the quadlet read and lock compare swap transactions shall be supported. The BUS_MANAGER_ID register provides a “well-known” data storage location for the purpose of identifying the physical_ID of the bus manager. During bus configuration, the process that determines which node, from perhaps more than one bus-manager-capable node, assumes the role of bus manager utilizes this location. Figure 8-11 shows the format of this register. The 6-bit bus_mngr_id field provides storage accessible through the quadlet read and lock (compare and swap) transactions. The bus_mngr_id field provides a location that bus-manager-capable nodes shall use in order to determine which one among them contends successfully for the role of bus manager. The initial value of this field, 3F16, is not a permissible value for a node on the serial bus since it is the broadcast address. The initial value indicates that no bus manager, as yet, has been selected. The procedure that bus-manager-capable nodes shall use to determine the bus manager is described in 8.4.2.5.
Copyright © 2008 IEEE. All rights reserved.
215
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 8-11—BUS_MANAGER_ID format 8.3.2.3.8 BANDWIDTH_AVAILABLE register The BANDWIDTH_AVAILABLE register is optional and shall be implemented on IRM-capable and busmanager-capable nodes. Special transaction limitations: Only the quadlet read and lock compare swap transactions shall be supported. The BANDWIDTH_AVAILABLE register provides a “well-known” data storage location for the purpose of allocating and deallocating isochronous bandwidth by owners of isochronous resource. Although this register shall be implemented on every bus-manager-capable and IRM-capable node, only the one on the active IRM has valid data. Figure 8-12 shows the format of the BANDWIDTH_AVAILABLE register.
Figure 8-12—BANDWIDTH_AVAILABLE format The read/write 13-bit bw_remaining field provides storage accessible through the quadlet read and lock (compare and swap) transactions.
216
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The contents of the bw_remaining field represent the amount of isochronous bandwidth currently available for allocation. This bandwidth quantity is expressed in terms of time units referred to as bandwidth allocation units, where one unit represents the time to send one quadlet of data at S1600, or roughly 20 ns. The maximum possible value of this register derives from the highest possible value of allowed bandwidth at the S1600 data rate for one isochronous cycle of 125 μs, namely 6144 bandwidth allocation units. In order to permit a small amount of asynchronous traffic to be interleaved with each isochronous cycle, a fixed 25 μs shall be subtracted from the theoretical maximum of 6144 bandwidth allocation units. The initial value of bw_remaining shall be equivalent to a maximum of 100 μs of isochronous traffic, or 4915 bandwidth allocation units. Such a reservation is necessary even in dedicated isochronous communication environments to support command and control operations that proceed by means of asynchronous traffic on the bus. Designers are strongly encouraged to implement behavior for the BANDWIDTH_AVAILABLE register described by Table 8-5. Although this algorithm is, strictly speaking, not compliant with the definition of compare_swap in 7.3.4.3, its behavior is functionally equivalent so long as lock requests addressed to the BANDWIDTH_AVAILABLE register conform to the assumption that the register represents an unsigned integer.
Table 8-5—Lock (compare_swap) algorithm for BANDWIDTH_AVAILABLE unsigned old_value;
// Current value of BANDWIDTH_AVAILABLE
unsigned compare_swap_bandwidth(unsigned arg_value, unsigned data_value) { unsigned bandwidth; if (arg_value > 0x1FFF) return(old_value); data_value &= 0x1FFF; if (arg_value >= data_value) { bandwidth = arg_value - data_value; if (old_value >= bandwidth) { new_value = old_value - bandwidth; return(arg_value); } else return(old_value); } else { bandwidth = data_value - arg_value; if (old_value + bandwidth < 0x2000) { new_value = old_value + bandwidth; return(arg_value); } else return(old_value); }
// Impossible BANDWIDTH_AVAILABLE value? // // // //
Mask for bw_remaining field Allocation or deallocation? Bandwidth to allocate Enough bandwidth remaining?
// Bandwidth to deallocate // Will it overflow bw_remaining field?
}
The variables arg_value and data_value correspond to the same fields in the lock request; old_value and new_value represent the value of BANDWIDTH_AVAILABLE during the operations, and old_value is returned in the lock response. The performance of this algorithm is superior to that specified by 7.3.4.3, since bandwidth allocation attempts always succeed if there is enough bandwidth remaining, whether or not the requester knew the actual quantity of bandwidth remaining. A similar observation holds for bandwidth deallocation, although the performance improvements are insignificant since deallocation is not usually performed at times when a serial bus is critically busy.
Copyright © 2008 IEEE. All rights reserved.
217
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTE—An independent observer capable of monitoring all serial bus subactions and their relative order in time could detect that this algorithm does not comply with the requirements of ISO/IEC 13213:1994. However, an individual requester lacking in such omnipotent knowledge has no way to determine that the behavior is noncompliant. By the time the originator of a lock request could transmit a read request to the IRM’s BANDWIDTH_AVAILABLE register another node might have changed its value.
8.3.2.3.9 CHANNELS_AVAILABLE register The CHANNELS_AVAILABLE register is optional and shall be implemented on IRM-capable and busmanager-capable nodes. Special transaction limitations: Only the quadlet read and lock compare swap transactions shall be supported. The CHANNELS_AVAILABLE register provides a “well-known” data storage location through which serial bus nodes may cooperate in the allocation and deallocation of isochronous channel numbers in the range zero to 63. Although this register shall be implemented on every bus-manager-capable and IRMcapable node, only the one on the active IRM has valid data. Bits allocated in the channels_available_hi field of this register shall start at bit zero (channel number zero), and additional channel numbers shall be represented in a monotonically increasing sequence of bit numbers up to a maximum of bit 31 (channel number 31). Bits allocated in the channels_available_lo field of this register shall start at bit zero (channel number 32), and additional channel numbers shall be represented in a monotonically increasing sequence of bit numbers up to a maximum of bit 31 (channel number 63). Figure 8-13 shows the format of the CHANNELS_AVAILABLE register.
definition channels_available_hi 32
channels_available_lo 32
initial values FFFF FFFE16 ones read values last successful lock last successful lock lock effects conditionally written conditionally written Figure 8-13—CHANNELS_AVAILABLE format The read/write 32-bit channels_available_hi and channels_available_lo fields provide storage accessible through the quadlet read and lock (compare and swap) transactions. Bits within this register indicate which of the (zero through 63) isochronous channel numbers are in use. For each bit, a zero value indicates this channel is owned and therefore unavailable for use. Otherwise, the channel is available, and a node that wishes to obtain ownership of the channel shall use the procedure described in 8.4.2.8.
218
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The contents of the CHANNELS_AVAILABLE register are valid only at the IRM. Channel 31 is automatically allocated by the IRM for use as the default broadcast channel for asynchronous stream packets. For reasons analogous to those already presented for the BANDWIDTH_AVAILABLE register, designers are strongly encouraged to implement behavior for each of the quadlets of the CHANNELS_AVAILABLE register described by Table 8-6. Although this algorithm is, strictly speaking, not compliant with the definition of compare_swap in 7.3.4.3, its behavior is functionally equivalent so long as lock requests addressed to the CHANNELS_AVAILABLE register conform to the assumption that the register represents a bit map.
Table 8-6—Lock (compare_swap) algorithm for CHANNELS_AVAILABLE unsigned old_value;
// Current value of CHANNELS_AVAILABLE_xx
unsigned compare_swap_channels(unsigned arg_value, unsigned data_value) { unsigned affected_channels = arg_value ^ data_value; if (
(arg_value & affected_channels) // Does expected value of affected channels == (old_value & affected_channels)) { // match their actual value? new_value = old_value ^ affected_channels; return(arg_value); } else return(old_value);
}
The variables arg_value and data_value correspond to the same fields in the lock request; old_value and new_value represent the value of CHANNELS_AVAILABLE during the operations, and old_value is returned in the lock response.
8.3.2.3.10 MAINT_CONTROL register The MAINT_CONTROL register is optional and may be implemented as a means of diagnosing and verifying the error detection logic within a serial bus system. The MAINT_CONTROL register provides fields that enable the generation of serial bus errors. Figure 8-14 shows the format of this register.
Figure 8-14—MAINT_CONTROL format
Copyright © 2008 IEEE. All rights reserved.
219
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The read/write e_hcrc bit affects the generation of packet header CRC value. If e_hcrc is one, the packet header CRC component of the next primary packet generated by this node shall be in error or shall be invalid; otherwise, the bit has no effect. This bit shall be cleared to zero immediately after the next packet for this node is generated. The read/write e_dcrc bit affects the generation of the data CRC value. If e_dcrc is one, the data CRC component of the next primary packet generated by this node shall be in error or shall be invalid; otherwise, the bit has no effect. This bit shall be cleared to zero immediately upon transmission of the erroneous CRC. The read/write no_pkt bit affects the generation of the next primary packet. If no_pkt is one, the next primary packet to be generated by this node shall be discarded. This bit shall be cleared to zero immediately after the next packet for this node is discarded. The read/write f_ack bit affects the generation of the acknowledge packet. If f_ack is one, the ack field shall be used within the next acknowledge packet generated by this node. This bit shall be cleared to zero immediately after the next acknowledge packet for this node is generated. The read/write no_ack bit affects the generation of the acknowledge packet. If no_ack is one, the next acknowledge packet (that would normally have been generated by this node) is not sent. This bit shall be immediately cleared to zero when the next acknowledge packet for this node is discarded. The 8-bit read/write ack field contains the 8-bit acknowledge packet (ack_code and ack_parity) to be supplied when the f_ack bit indicates a modified acknowledge packet is to be generated. These control bits allow errors to be inserted into various places in the packets generated by this node. After the completion of the error insertion, enabled error-insertion controls are disabled. NOTE—If the control bits are set via a serial bus write transaction into this node, then the error insertion shall not affect this write; the acknowledgment of the write request and the following response subaction (if present) are not affected. The next primary packet or acknowledge packet generated after this write response shall be affected.
8.3.2.3.11 MAINT_UTILITY register The MAINT_UTILITY register is optional and may be implemented for diagnostic purposes. The MAINT_UTILITY register is a safe target for diagnostic read and write transactions. The 32-bit register is read/write, and when it is read it returns the value last written. The register otherwise has no effect on the state of the node. Figure 8-15 shows the contents of the register.
Figure 8-15—MAINT_UTILITY format
220
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
8.3.2.3.12 BROADCAST_CHANNEL register The BROADCAST_CHANNEL register is optional and, if implemented, shall be a quadlet register located at offset 23416 within initial register space. All IRM-capable nodes shall implement the BROADCAST_CHANNELS register. The BROADCAST_CHANNEL register permits the IRM to communicate the channel number assigned for asynchronous stream broadcast to other nodes on a serial bus. The BROADCAST_CHANNEL register shall support quadlet read and write requests only. The definition is given by Figure 8-16.
definition 1 v
reserved
1 1
24
channel 6
initial values 1
zeros
1 u
zeros
31
read values 31
write effects i s
ignored Figure 8-16—BROADCAST_CHANNEL format
The MSB (a constant one) differentiates the presence of the BROADCAST_CHANNEL register from the value (all zeros) that may be returned when this register’s address is read at node(s) that do not implement the register. NOTE—Nodes compliant with this standard return an address error response when unimplemented addresses are accessed—but some implementations are known to complete such requests with resp_OK and response data of zeros.
The valid bit (abbreviated as v above), when set to one, indicates that the default broadcast channel specified by the channel field may be used. Nodes shall not transmit stream packets that specify this channel while the valid bit in their own BROADCAST_CHANNEL register is zero. The channel field shall identify the channel number shared by all nodes for asynchronous stream broadcast.
8.3.2.4 Unit registers The CSR architecture reserves address space for node-dependent resources within its initial units space, defined as the space above FFFF F000 080016. A serial bus reserves a portion of initial units space for busdependent use, summarized in Table 8-7. The addresses of these registers are specified in terms of offsets within the initial register space, where the base of the initial register space (from the beginning of the initial node space) is FFFF F00 000016. Any other CSRs specific to units (peripheral devices) implemented within the node are expected to share the initial units space and shall not be located within the range reserved by the serial bus. Except as specified by this standard or future IEEE serial bus standards, unit architectures shall not implement any CSRs that fall within the above address space. The following subclauses provide detailed definitions of the Serial-Bus-dependent registers located within the initial units space.
Copyright © 2008 IEEE. All rights reserved.
221
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 8-7—Serial-bus-dependent registers in initial units space Offset
Name
Notes
80016 –8FC16
—
Reserved for serial bus
90016
OUTPUT_MASTER_PLU G
Specified by IEC 61883-1
90416 –97C16
OUTPUT_PLUG
98016
INPUT_MASTER_PLUG
98416 –9FC16
INPUT_PLUG
A0016 – AFC16
—
Reserved for serial bus
B0016 – CFC16
FCP command frame
Specified by IEC 61883-1
D0016 –EFC16
FCP response frame
F0016 – FFC16
—
Reserved for serial bus
100016 – 13FC16
TOPOLOGY_MAP
Present at the bus manager, only.
140016 –1FFC16
—
Reserved for serial bus
200016 –2FFC16
SPEED_MAP
Obsoleted
300016 – FFFC16
—
Reserved for serial bus
8.3.2.5 TOPOLOGY_MAP registers (cable environment) The TOPOLOGY_MAP register is not implemented for backplane environments. The TOPOLOGY_MAP register is optional for cable environments. These registers shall be implemented on bus manager capable nodes. These registers shall be read-only. The bus manager shall generate a record of the self-ID packets observed plus the self-ID packet transmitted by the bus manager during the most recent self-identify process; this record is externally accessible through the TOPOLOGY_MAP registers. This map shall be the resource used to deduce topological information about the given bus configuration. Although this register can be implemented on every node, only the one on the active bus manager is guaranteed to have valid data. Figure 8-17 shows the format of these TOPOLOGY_MAP registers.
Figure 8-17—TOPOLOGY_MAP format The 16-bit length field specifies the number of following quadlets in the topology map. The 16-bit CRC field covers all of the following quadlets. The CRC value is the CRC-16 algorithm described in Section 8.1.5 of ISO/IEC 13213:1994.
222
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The 32-bit generation_number value specifies how many times this node has generated the topology map since its last power reset. The 16-bit node_count value specifies the number of nodes present on the local serial bus. The node_count is redundant, since it can be derived from the self-ID packets available in the topology map. The 16-bit self_id_count value specifies the number of self-ID packets stored at the following quadlet addresses. The 32-bit self_id_packet fields in the following quadlets are a copy of the first quadlet of all self-ID packets observed by the bus manager, with the addition of a copy of the self-ID packet transmitted by the bus manager. The self-ID packets shall be stored in the order observed on the serial bus. The bus manager shall insert a copy of its own transmitted self-ID packets in the proper sequence location in the topology map. NOTE—The values of these registers may be in an inconsistent state if the bus manager updates the topology map at the same time another node reads it. In order to guarantee accurate topology map information, 8.4.4.5 defines a procedure to access the topology map.
8.3.2.6 Configuration ROM Transaction-capable serial bus nodes shall implement configuration ROM, as defined in Section 8 of ISO/ IEC 13213:1994. Two configuration ROM formats are supported: minimal and general. The minimal ROM format provides a 24-bit OUI. The general ROM format provides additional information in a Bus_Info_Block and a Root_Directory. Entries within the Root_Directory may provide information or may provide a pointer to another directory (which has the same structure as the Root_Directory) or a leaf (which contains information). The Unit_Directories contain information about the units, such as their software version number and their location within the address space of the node. Figure 8-18 illustrates the structure of these directories and leaves.
Figure 8-18—Configuration ROM hierarchy
Copyright © 2008 IEEE. All rights reserved.
223
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Either the minimal ROM format or the general ROM format may be implemented, but bus-managercapable, cycle-master-capable, and isochronous-capable nodes shall implement the general ROM format. It is expected that many unit architectures, e.g., the SBP, will also use the general ROM format, since it provides a standard and extensible access mechanism to unit-dependent parameters.
8.3.2.6.1 Organizationally Unique Identifier (OUI) The term OUI is used throughout this subclause to identify uniquely vendors that manufacture or specify components. To obtain an OUI, contact: IEEE Registration Authority 445 Hoes Lane Piscataway, NJ 08854
[email protected] 732-465-6481 http://standards.ieee.org/regauth/registry_OUI.html
8.3.2.6.2 Minimal ROM format The minimal ROM implementation consists of a single quadlet, which provides a 24-bit OUI value as illustrated in Figure 8-19.
Figure 8-19—Minimal ROM format The vendor_id value shall be the 24-bit OUI of the vendor that manufactured the module. The IEEE Registration Authority uniquely assigns an OUI to each module vendor, as described in Section 8.7 of ISO/IEC 13213:1994. Note that the minimal ROM format does not preclude the presence of additional vendor-dependent information in the ROM.
8.3.2.6.3 General ROM format In its more general form, the ROM directory structure is a hierarchy of information blocks; the blocks higher in the hierarchy point to the blocks beneath them. The locations of the initial blocks (which include the Bus_Info_Block and Root_Directory) are fixed. The location of other entries (unit directories, root, and unit leaves) is vendor-dependent but shall be specified by entries within the Root_Directory or its associated directories. Figure 8-20 shows a general ROM implementation. Note that there may be multiple Unit_Directories, one for each unit at the node. The info_length field shall have a value greater than one to distinguish the general ROM format from the minimal ROM format (whose info_length field has a value of one). The info_length value specifies the number of quadlets contained within the following Bus_Info_Block data structure. The crc_length field specifies how many of the following quadlets are protected by the rom_crc_value. The minimum number of quadlets that shall be protected is the number within the Bus_Info_Block. The maximum number of quadlets that may be protected, 255, provides protection for the largest configuration ROM size permitted for a serial bus, 1024 bytes.
224
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 8-20—General ROM format The rom_crc_value shall be calculated according to the CRC-16 algorithm described in 7.3 of IEEE Std 1212-2001.
8.3.2.6.4 Configuration ROM Bus_Info_Block The serial bus Bus_Info_Block shall have the format shown in Figure 8-21. 3116 ("1")
3316 (“3”)
capabilities
cyc_clk_acc
3916 (“9”) max_rec
3416 (“4”)
rsv
max_ ROM
generation
node_vendor_ID
b
link_spd
chip_ID_hi chip_ID_lo
Details of capabilities field: irmc
cmc
isc
bmc
pmc
adj
rsv
rsv
Figure 8-21—Bus_Info_Block format The first quadlet contains the string “1394” in ASCII as the bus_name value required by the CSR architecture. The irmc bit shall be one if the node is IRM capable; otherwise, the irmc value shall be zero. The cmc bit shall be one if the node is cycle master capable; otherwise, this value shall be zero. The isc bit shall be one if the node supports isochronous operations; otherwise, this value shall be zero. The bmc bit shall be one if the node is bus manager capable; otherwise, this value shall be zero.
Copyright © 2008 IEEE. All rights reserved.
225
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The pmc bit when set to one indicates the node is power manager-capable. A node that sets its pmc bit to one shall also set its bmc bit to one to indicate bus manager capabilities. The capabilities and responsibilities of a power manager-capable node are beyond the scope of this standard. The adjustable bit (abbreviated as “adj” in Figure 8-21) is defined by IEEE Std 1394.1 and shall be treated as reserved by nodes that do not implement IEEE Std 1394.1. The reserved fields (abbreviated as “rsv” in Figure 8-21) are reserved for future definition by a serial bus and shall be zeros. The cyc_clk_acc field specifies the cycle master clock accuracy of the node in parts per million. If the cmc bit is set, the value in this field shall be between zero and 100. If the cmc bit is cleared, this field shall be all ones. The max_rec field defines the maximum data payload size that the node supports. The data payload size applies to block write requests or asynchronous stream packets addressed to the node and to block read responses transmitted by the node. When max_rec is zero the maximum data payload is unspecified. Otherwise, it is equal to 2max_rec+1 bytes, as defined by Table 8-8. If max_ROM is nonzero, max_rec shall be greater than or equal to 2max_ROM+1 + 1.
Table 8-8—Encoding of max_rec field
Code
Maximum data payload (bytes)
0
Not specified
1
4
2
8
3
16
4
32
5
64
6
128
7
256
8
512
9
1024
A16
2048
B16
4096
C16
8192
D16
16 384
E16 to F16
Reserved
The maximum isochronous data payload supported by the node, either as a talker or listener, is not governed by max_rec.
226
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The max_ROM field shall specify the size and alignment of read requests supported by configuration ROM, whether within the address range FFFF F000 040016 through FFFF F000 07FF16 inclusive or another portion of the node’s address space, as specified by Table 8-9.
Table 8-9—Encoding of max_ROM field Code
Meaning
0
Quadlet read requests are supported. This encoding is suggested for Alpha devices and should not be reported by Beta devices.
1
Quadlet read requests and block read requests aligned on 64-byte addresses with a data length of 64 bytes are supported.
2
Quadlet read requests and block read requests aligned on quadlet addresses with a data length less than or equal to 1024 bytes are supported.
3
Reserved for future standardization.
NOTE—Devices that report a max_ROM value of zero should support block read requests capable of returning the first five quadlets of configuration ROM (which includes the entire contents of the bus information block) in one transaction even if block read requests are not supported for any other portion of configuration ROM.
The generation field is used to indicate changes in configuration ROM. Devices that do not support either Arbitration Compliance Level A or greater (see 15.1) shall report a value of zero for the generation field. Devices that support Arbitration Compliance Level A (see 15.1.1), whose configuration ROM never changes (so long as the device's link is continuously active) shall set the generation field to one. Devices that support Arbitration Compliance Level B (see 15.1.2) shall set the generation field to a value between two and F16, inclusive. For these devices, upon the detection or initiation of a bus reset, the generation field shall be modified if any portion of configuration ROM has changed since the prior bus reset. The updated value of the generation field shall not be equal to any values assumed by the field within the preceding 60 s. Configuration ROM includes not only the first 1024 bytes of ROM (quadlets in the address range FFFF F000 040016 through FFFF F000 07FC16, inclusive) but any directories or leaves that are indirectly addressed from the first 1024 bytes. The CRC in the first quadlet of configuration ROM shall be recalculated each time the generation field is updated. NOTE—The generation field is usually incremented upon a change to configuration ROM; the value wraps from F16 back to two. If an update would result in a value used within the last 60 s, the device should defer any changes to configuration ROM until the requisite 60 s have elapsed.
The link_spd field shall report the maximum speed capability of the node’s link layer; the encoding used is the same as for the PHY register port status field Max_port_speed defined in Table 15-3. Together the node_vendor_id, chip_id_hi, and chip_id_lo fields form a 64-bit node unique identifier. Because physical addresses on the serial bus may change after a bus reset, this unique identifier is the only secure method of node identification.
8.3.2.6.5 Root_Directory The configuration ROM for each serial bus node that implements the general ROM format shall contain a Root_Directory. The Root_Directory shall contain Module_Vendor_Id and Node_Capabilities entries.
Copyright © 2008 IEEE. All rights reserved.
227
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
8.3.2.6.5.1 Module_Vendor_Id entry The Module_Vendor_Id entry is an immediate entry in the Root_Directory that provides the OUI of the vendor that manufactured the module. Figure 8-22 shows the format of this entry.
Figure 8-22—Module_Vendor_Id entry format 0316 is the CSR architecture key_type and key_value for the Module_Vendor_Id entry. The IEEE Registration Authority uniquely assigns the 24-bit module_vendor_id to each module vendor, as defined in Section 8.7 of ISO/IEC 13213:1994.
8.3.2.6.5.2 Node_Capabilities entry The Node_Capabilities entry is an immediate entry in the Root_Directory that describes node capabilities. Figure 8-23 shows the format of this entry.
Figure 8-23—Node_Capabilities entry format 0C16 is the CSR architecture key_type and key_value for the Node_Capabilities entry. The 24-bit node_capabilities field contains subfields defined within Section 8.4.11 of ISO/IEC 13213:1994. Serial bus nodes shall implement the spt, 64, fix, 1st, and drq bits. Transaction-capable nodes shall set the spt bit to one to indicate that the SPLIT_TIMEOUT register is implemented. Transaction-capable nodes that initiate serial bus transactions shall set the drq bit to one. This indicates that the STATE_CLEAR.dreq bit is implemented. The STATE_CLEAR.dreq bit, if cleared by another node, inhibits the initiation of serial bus transactions, either asynchronous or isochronous. All serial bus nodes shall set the 64, fix, and 1st bits to one. These indicate that the node implements the 64bit fixed addressing scheme and that the STATE_CLEAR.lost bit is implemented.
8.3.2.6.6 Unit_Directories With the exception of the Unit_Power_Requirements entry, the format of Unit_Directories within a serial bus node that implements unit architectures is beyond the scope of this standard. The format of Unit_Directories are described in Section 8.4.5.1 of ISO/IEC 13213:1994. The Unit_Power_Requirements entry shall be implemented in the Unit_Directory of any unit that can consume bus power in excess of the level specified by the pwr field in the self-ID packet transmitted by the node. This entry shall not be implemented for any units that are locally powered. Figure 8-24 shows the format of this entry.
228
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 8-24—Unit_Power_Requirements entry format 3016 is the serial bus key_type and key_value for the Unit_Power_Requirements entry. The 24-bit power_requirements field specifies the maximum additional bus power requirements of the unit, in deciwatts, beyond the power consumption enabled by the receipt of a link-on packet. This entry shall apply to units whose architecture implements a unit-dependent means of enabling bus power consumption in addition to that indicated by the pwr field of the self-ID packet.
8.3.3 SBM variables Each node has a set of variables in the SBM layer that an application may query via serial bus services described in 8.2. Table 8-10 summarizes these variables.
Table 8-10—SBM variables Variable name
Comment
Incumbent
Used only if the node is bus manager capable. Set to TRUE if the node is the bus manager; FALSE if the node did not win the role of bus manager.
IRM ID
Used only if the node is IRM capable. Upon completion of the self-identify process, it shall be set to the physical_ID of the IRM.
NOTE—Other SBM variables, specifically Bus Time, Split-Transaction Timeout, Transaction Retry Limit, and Transaction Retry Timeout, are defined in 8.3.1.2.
8.4 SBM operations 8.4.1 Bus configuration procedures (backplane environment) The serial bus in the backplane environment requires no reconfiguration after a power reset, command reset, or the live insertion of a node. As soon as a reset event is complete, any node on the bus may begin to arbitrate for asynchronous access upon detection of an arbitration reset gap. It is only in the case of isochronous operations that serial bus configuration is necessary in the backplane environment. Although this standard places no requirement on a serial bus in a backplane environment as to how it implements the functions needed to support isochronous operations, this standard strongly recommends that analogs of the cable environment be used. That is, one of the nodes on the bus in the backplane environment should function as the cycle master and another, potentially the same node, should function as the IRM. Serial bus nodes in the backplane environment that wish to allocate or deallocate isochronous bandwidth or channel number resources should use the same procedures used in the cable environment, namely those described in 8.4.2.5. The subclauses that follow describe the procedures to be executed after a power reset in the backplane environment.
Copyright © 2008 IEEE. All rights reserved.
229
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
8.4.1.1 Unmanaged bus (backplane environment) If there are no nodes on the serial bus that are IRM capable, the serial bus is unmanaged and capable only of asynchronous transactions between nodes with enabled link layers upon completion of the power reset. The remainder of 8.3.2.6.6 is not applicable to an unmanaged serial bus.
8.4.1.2 Determination of the IRM (backplane environment) The process used in the backplane environment to select the IRM from the contending IRM-capable nodes is not specified by this standard. Since no procedures exist for the IRM-capable nodes to resolve this contention by themselves, the application element at each node shall communicate to the bus manager layer, via an SB_CONTROL.request, whether or not the IRM is to be enabled. Of necessity, the application elements at the IRM-capable nodes shall have either a priori knowledge as to which node is to be the IRM or else a procedure to select the IRM. Although a procedure for selecting an IRM is not specified, an example of such a procedure is given in Annex G. IRM-capable nodes are identifiable by the irmc bit in the Bus_Info_Block as described in 8.3.2.6.
8.4.1.3 Determination of the cycle master (backplane environment) As soon as the IRM is determined, it shall activate a cycle-master-capable node to become the cycle master. Cycle-master-capable nodes are identifiable by the cmc bit in the Bus_Info_Block, as described in 8.3.2.6.
8.4.2 Bus configuration procedures (cable environment) Since some node roles on the serial bus (e.g., root, IRM, and bus manager) may change whenever the bus topology changes, a bus reset is the trigger that causes a redetermination of which nodes are to perform these functions. It is also possible that a node, in its management role as either an IRM or bus manager, needs to change which nodes perform these functions. In this case, a bus reset initiated by the manager forces this process, even though the bus topology is unaltered. When a bus reset occurs, all asynchronous and isochronous traffic on the serial bus ceases. Asynchronous transfers may resume as soon as the self-identify process that follows a bus reset has completed. Previously established isochronous data streams, either talker or listener, are to resume as soon as possible after the selfidentify process completes. In general, the roles of cycle master, IRM, and bus manager shall be redetermined before new allocation of isochronous resources can be performed and before the new topology and speed maps can be made available. This subclause describes the interaction of serial bus nodes as they contend for the roles of IRM and bus manager after a bus reset. The resolution of these conflicts defines the points in time at which each successive serial bus facility becomes available. In order for this process to function properly, each serial bus node shall implement the appropriate state machines described in 8.4.5.1. These state machines describe specific, observable behavior from the vantage point of an imaginary, transaction-capable observer on the serial bus. The state machines also assume the existence of certain variables internal to each node implementation. However, the internal implementation of these state machines is beyond the scope of this standard.
8.4.2.1 Unmanaged bus (cable environment) If there are no nodes on the serial bus that are either IRM capable or bus manager capable, the serial bus is unmanaged and capable only of asynchronous transactions between nodes with already enabled link layers at the time of the bus reset. The remainder of 8.4.2 is not applicable to an unmanaged serial bus.
230
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
8.4.2.2 Prior isochronous traffic (cable environment) If the previous cycle master remains the root16 (as determined immediately upon completion of the selfidentify process), it shall resume cycle master operations. If the cycle master remains the root and therefore is able to resume broadcast of the cycle start packet, any isochronous talkers that had been enabled prior to the bus reset may resume isochronous operations as well. If the node that was cycle master before the bus reset is no longer the root,17 isochronous talkers are unable to resume isochronous operations until a new cycle master is selected at a later step in this process.
8.4.2.3 Determination of the IRM (cable environment) Subsequent to bus reset, each node participates in the self-identify process described in 16.4.7. The link and higher layers of all nodes that are contenders for the role of the IRM shall observe all self-ID packets to determine the identity of the single node selected as IRM. From all the nodes that are capable of becoming the IRM, one is selected as follows. An IRM-capable node that wishes to contend for the role of IRM shall, during the self-identify process, transmit its own self-ID packet with both the c bit (contender) and the L bit (link active) set to one. Each of these contenders shall also monitor all received self-ID packets in order to observe the largest physical_ID from a packet with both the c and L bits set. The candidate node with the largest physical_ID wins the role of the IRM. Contenders shall apply consistency checks to the observed self-ID packets to insure that —
The second quadlet of each self-ID packet is the logical inverse of the first quadlet.
—
The phy_ID fields of self-ID packet zero are in monotonically increasing sequence and the phy_ID fields of all self-ID packets other than packet zero are equal to the phy_ID field of the preceding selfID packet.
—
The set of self-ID packets for the node with the largest physical_ID indicates that all its active PHY ports are connected to children.
If any of these requirements is not met, the contender shall initiate a bus reset as soon as possible. A contender that becomes the IRM shall update its own BROADCAST_CHANNEL register by setting the valid bit to one; it may notify other nodes that channel 31 has been allocated as the default broadcast channel by updating their BROADCAST_CHANNEL register(s) with the contents of its own BROADCAST_CHANNEL register, by means of either a broadcast write request or write requests addressed to individual nodes. Because some nodes in older equipment that does not support Arbitration Compliance Level A or greater (see 15.1) do not implement the BROADCAST_CHANNEL register, contenders shall determine whether or not the current IRM is compliant with this standard by using at least one of the following tests: —
By the receipt of a write request addressed to the node’s own BROADCAST_CHANNEL register that sets the valid bit to one
—
By the successful completion of a read request addressed to the IRM’s BROADCAST_CHANNEL register and the return of response data that shows the MSB to be one
—
By the successful read of the IRM’s bus information block that shows the generation field to be nonzero
—
If an analysis of self-ID packets indicates that, subsequent to a bus reset, the prior IRM has continued as the IRM (but only if the prior IRM was known to be compliant with this standard)
16 In 17
normal operation, the previous cycle master will remain the root since it will have its force_root flag set. This condition is possible if two operating buses (both having cycle masters with their force_root flag set) are joined together.
Copyright © 2008 IEEE. All rights reserved.
231
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
If the current IRM is not compliant with this standard, a contender that additionally complies with the requirements of 8.4.2.6 shall set its own force_root variable to TRUE and initiate a bus reset in order to become the IRM. NOTE—A contender that is also bus manager capable may become the bus manager at a later step in the configuration process, whether or not it wins the role of the IRM.
8.4.2.4 Reallocation of prior isochronous resources (cable environment) In order to promote stability of serial bus configurations across a bus reset, the owners of isochronous resources established prior to the bus reset, i.e., channels and bandwidth, are required to reallocate these resources as soon as possible after a bus reset. As soon as the self-identify process has completed, the identity of the IRM is determined, and all the owners of prior isochronous resources shall access the BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers at the IRM in order to reallocate these resources. The procedures described in 8.4.2.5 shall be used. If an isochronous resource, either channel or bandwidth, cannot be reallocated, the serial bus node that owned the resources prior to the bus reset shall cause the corresponding isochronous talker to cease broadcast of isochronous packets.
8.4.2.5 Determination of the bus manager (cable environment) One of the goals of the resolution process described in 8.4.2 is to promote stability of the serial bus configuration across bus resets. To this end, a node that had the role of bus manager prior to the bus reset may attempt to reestablish its role earlier than new candidates for this role. Specifically, immediately upon completion of the self-identify process, the incumbent bus manager (if any) shall make a lock request with an extended transaction code of compare and swap to the BUS_MANAGER_ID register at the IRM node. The lock packet shall have an arg_value of 3F(16) and a data_value equal to the physical_ID of the incumbent bus manager. The incumbent bus manager shall issue this lock request until it obtains a Request Status of COMPLETE and a Response Code of resp_complete. If the old_value received in the lockresponse packet is 3F16 or the physical_ID of the incumbent bus manager, the incumbent bus manager has reestablished itself as the bus manager. If any other value is returned, it is the physical_ID of the node that has won the role of bus manager; the incumbent manager has lost and shall not perform any of the functions of the bus manager. Challengers for the role of bus manager shall follow a similar process. These are all the nodes on the serial bus that are bus manager capable but are not incumbent. These challengers shall wait a minimum of 125 ms before making a lock request with an extended transaction code of compare and swap to the BUS_MANAGER_ID register at the IRM node. Once the 125 ms delay period has elapsed, the challenger nodes shall implement the same procedure described for the incumbent bus manager node. At the earliest point in this process that a node is selected as the bus manager, it shall perform the power management procedure described in 8.4.4.4, shall make available the SPEED_MAP and TOPOLOGY_MAP registers described in and 8.3.2.5, respectively, and shall attempt to enable a cycle master as described in 8.4.2.6.
8.4.2.6 Determination of the cycle master (cable environment) As described in 8.4.1.2, a cycle master node that remains the root node of the serial bus shall resume the broadcast of cycle start packets as soon as the self-identify process has completed. When the prior cycle master is no longer the root node after a bus reset, it shall not broadcast cycle start packets. In this case, it is necessary to activate a new cycle master. If a bus manager is present on the serial bus, it shall select and activate a cycle master as described in the following paragraphs. If there is no bus manager, the IRM shall select and activate a cycle master as described in the following paragraphs.
232
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The bus manager or, if a bus manager is not present, the IRM shall examine the Bus_Info_Block of the root node of the serial bus. If this node is capable of becoming the cycle master, the bus manager or the IRM shall a)
If the bus has more than one node, set the force_root flag of the root node18 and clear the force_root flag of all other nodes. If the bus has only a single node, the force_root flag shall be cleared.19
b)
Set the cmstr bit in the STATE_CLEAR register of the root node.
If the root node does not have cycle master capabilities and the bus has more than one node, the bus manager or IRM shall select one of the nodes on the serial bus that has cycle master capabilities as a candidate to become the new cycle master. Because the selected node is not, at present, the root, it is necessary that another bus reset be initiated to modify the topology of the serial bus. Prior to the bus reset, the bus manager or IRM shall transmit a PHY configuration packet with the r bit set to one and the root_id field set to the physical_ID of the candidate cycle master node. Because of this, the candidate cycle master node is guaranteed to become the root of the new serial bus configuration. Another application of the procedures described in 8.4.1 will permit the resumption of isochronous traffic with the new cycle master.
8.4.2.7 Determination of the root (cable environment) A node’s force_root variable shall not be set to TRUE unless the node is more capable than the current root. This standard creates an ordering of root node capabilities, which may be extended by future IEEE standards. The most basic of root node capabilities is inherent in all nodes whether or not link and transaction layers are implemented (see 8.3.1.1). Additional capabilities may be implemented by transaction-capable nodes and are enumerated below in increasing order of capability as follows: a)
Cycle master capable. When an IRM or bus manager is present, the root shall be cycle master capable. A cycle-master-capable node may be positively identified by the cmc bit in the bus information block or its presence may be inferred by the observation of cycle start packets.
b)
Enhanced IRM capable. This standard defines new functionality for the IRM—the ability to allocate channel 31 as the default channel for asynchronous stream broadcast. Such a node may be positively identified by its implementation of the BROADCAST_CHANNEL register, by a nonzero generation field in its bus information block, or its presence may be inferred by the receipt of a write addressed to the BROADCAST_CHANNEL register.
In order for this scheme to be extensible, it is crucial that nodes compliant with this and future standards adhere to these requirements and not set their own force_root variable to TRUE unless they are more capable than the current root. This is particularly important in the case where the current root’s force_root variable is cleared to FALSE in order that another node become the root. The former root shall not attempt to reestablish itself as the root if the new root is at least as capable as the former root. It is likely that the new root is more capable and that the former root is unable to detect its enhanced capabilities. Subclause 8.4.2.3 conforms to these requirements; the only reason a candidate IRM is permitted to set its own force_root variable TRUE is because it implements all root node capabilities defined by this standard. If a future IEEE standard specifies new functionality for which it is desirable that a particular node be the root, that node shall be both cycle master and enhanced IRM capable in addition to its new capabilities. 18This guarantees that the root node will stay root after a bus reset, providing that two operating buses (each having a node with the force_root flag set) are not connected together. 19 Isolated nodes shall not set their force_root flag, since this might cause the root to shift in any operating bus to which the isolated node is attached.
Copyright © 2008 IEEE. All rights reserved.
233
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
8.4.2.8 Power management by the IRM (cable environment) Although the identity of the IRM is established as soon as the self-identify process has completed, the IRM shall not engage in power management operations until it has determined that no bus manager is present on the serial bus. In order to determine whether or not a bus manager is present, the IRM shall wait a minimum of 625 ms after the self-identify process completes. When this delay has elapsed, the IRM examines its own BUS_MANAGER_ID register. If the BUS_MANAGER_ID register is equal to 3F16, there is no bus manager present, and the IRM may transmit link-on packets to enable the link layer at other nodes. If the BUS_MANAGER_ID register contains a value other than 3F16, it is the physical_ID of the bus manager, and the IRM shall not engage in any power management activities.
8.4.2.9 Allocation of new isochronous resources (cable environment) Nodes that wish to acquire isochronous resources, either bandwidth or channels, not allocated prior to the bus reset shall wait a minimum of 1000 ms before attempting the allocation protocols described in 8.4.3. Note that an increase in bandwidth allocation by a node that owned bandwidth prior to a bus reset is also considered an allocation of new resources. In this case, the node that wishes to increase its bandwidth allocation may reestablish the original allocation immediately upon completion of the self-identify process but shall wait until 1000 ms have elapsed before making any attempt to gain additional bandwidth.
8.4.3 Isochronous resource allocation (cable environment) The IRM, through the means of the BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers, provides the means for the “owners” of isochronous resources to share the total isochronous resources available on the serial bus. Owners of isochronous resources, either bandwidth or channel assignments, gain ownership of these resources through the procedures described in 8.4.3.1 and 8.4.3.2. Note that the owner of an isochronous resource need be neither the talker nor a listener for the channel in question. In the cable environment, a serial bus node that wishes to acquire ownership of either bandwidth or a channel shall have the capability to monitor self-ID packets after a bus reset, as described in 8.4.2.3. This is essential in order that the node know the location of the IRM. Among the self-ID packets that have both the l and the c bits set, the one with the largest physical_ID specifies the IRM. NOTE—Subclause 8.4.1 recommends that isochronous management in the backplane environment occur in a manner similar to that described in this subclause. It is beyond the scope of this standard to specify a method for determining the location of the IRM in the backplane environment, although an example of such a method is given in Annex G
Once the physical ID of the IRM has been determined, the node may attempt the allocation of bandwidth or channels. An isochronous-capable node shall not transmit isochronous packets unless the required bandwidth and channel number have been allocated.
8.4.3.1 Bandwidth allocation The BANDWIDTH_AVAILABLE register, located at the IRM, reflects the aggregate amount of isochronous bandwidth available on the serial bus at a given point in time. Since more than one entity may wish to allocate bandwidth at essentially the same time, a compare and swap protocol shall be used to change the BANDWIDTH_AVAILABLE register. The use of compare and swap guarantees atomicity of access to the value of this register in the distributed environment of the serial bus. A transaction-capable node that wishes to allocate isochronous bandwidth shall perform the following actions:
234
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
a)
The bandwidth desired shall be calculated to include the bandwidth needed by the application plus all overhead associated with isochronous data transfer, e.g., isochronous gap, arbitration, data prefix and data end. The bandwidth desired shall not exceed the current bandwidth available. If a node desires more bandwidth than is available, the node shall either reduce its request for bandwidth or shall delay some period of time and retry the allocation later.
b)
The bandwidth allocation shall be attempted by a lock request with an extended transaction code of compare and swap to the BANDWIDTH_AVAILABLE register at the IRM. The lock packet shall have an arg_value equal to the value of the current bandwidth available and a data_value equal to the bandwidth available less the bandwidth desired.
c)
If the lock transaction fails to complete, i.e., the Request Status returned is not COMPLETE or the Response Code is not resp_complete, the node may retry the entire bandwidth allocation procedure.
d)
If the lock transaction is successful and the old_value received is equal to the arg_value transmitted in the lock request, the allocation of isochronous bandwidth is successful. In all other cases, the bandwidth allocation has failed and may be retried as appropriate. A subsequent read of the BANDWIDTH_AVAILABLE register is not necessary, since the old_value returned by the failing lock request reflects the current bandwidth available.
When the procedure described above succeeds, the requesting node becomes the owner of the isochronous bandwidth. Isochronous bandwidth shall not be deallocated by any node other than the owner of the bandwidth unless the owner of the bandwidth has requested, by means beyond the scope of this standard, another node to deallocate the bandwidth on behalf of the owner. Bandwidth deallocation is performed by an essentially similar protocol. The owner of the bandwidth shall use a lock transaction to attempt to increase the currently available bandwidth by the amount of bandwidth returned. Lock requests that fail should be retried until the bandwidth is successfully deallocated.
8.4.3.2 Channel allocation The CHANNELS_AVAILABLE register, located at the IRM, reflects (in the form of a bit map) which isochronous channels are in use on the serial bus at a given point in time. Since more than one entity may wish to allocate channels at essentially the same time, a compare and swap protocol shall be used to change this register. The use of compare and swap guarantees atomicity of access to these register values in the distributed environment of the serial bus. A transaction-capable node that wishes to allocate isochronous channels shall perform the following actions: a)
If unused channels are available, the request for a channel is made with a lock request with an extended transaction code of compare and swap to the CHANNELS_AVAILABLE register at the IRM. The lock packet shall have an arg_value equal to the bit mask that represents the current state of channel availability and a data_value equal to the same value except that the bit(s) that represents the desired channel(s) shall be cleared to zero. A node shall not attempt to allocate a channel that is in use; in such a circumstance, the node shall either select a different, unused channel or shall delay some period of time and retry the allocation later.
b)
If the lock transaction fails to complete, i.e., the Request Status returned is not COMPLETE or the Response Code is not resp_complete, the node may retry the entire channel allocation procedure.
c)
If the lock transaction is successful and the old_value received is equal to the arg_value transmitted in the lock request, the allocation of isochronous channel(s) is successful. In all other cases, the channel allocation has failed and may be retried as appropriate. A subsequent read of the CHANNELS_AVAILABLE register is not necessary, since the old_value returned by the failing lock request reflects the current availability of isochronous channels.
When the procedure described above succeeds, the requesting node becomes the owner of the isochronous channel(s). Isochronous channel(s) shall not be deallocated by any node other than the owner of the
Copyright © 2008 IEEE. All rights reserved.
235
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
channel(s) unless the owner of the channel(s) has requested, by means beyond the scope of this standard, another node to deallocate the channel(s) on behalf of the owner. Channel deallocation is performed by an essentially similar protocol. The owner of the channel shall first read the value of the CHANNELS_AVAILABLE register at the IRM in order to obtain an accurate picture of which channels are in use. A subsequent lock transaction shall be used to attempt to set the bit that corresponds to the channel being released. Lock requests that fail should be retried until the channel is successfully deallocated.
8.4.3.3 Bandwidth set-aside If the SB_CONTROL.request service has been used to communicate a nonzero value for the Bandwidth Setaside parameter to the bus manager, the bus manager shall use the bandwidth allocation procedure described in 8.4.2.6 to reduce the total amount of isochronous bandwidth by the set-aside amount. Note that it is possible for the bus manager to fail in the attempt to reduce the bandwidth available if other isochronous resource owners have already reduced the bandwidth available to an amount less than the Bandwidth Setaside. If this is the case, the bus manager shall set the bandwidth available to zero.
8.4.3.4 Isochronous requests with no cycle master Connecting and/or disconnecting nodes can result in a B_bus that has no active cycle master. When a node issues an isochronous request a timer is started to ensure that the request is granted in a timely manner. If there is no active cycle master and no other activity on the bus then the request times out after IDLE_ARB_STATE_TIMEOUT and the PHY initiates a bus reset. This can happen repeatedly. Note that a bus reset on an isolated node clears the root-holdoff bit (RHB) in the PHY, thus the root before a bus reset may well not be root after a bus reset, and a non-cycle-master-capable node (e.g. a hub) can become root. The IRM, if not root, should ensure that a cycle-master-capable node is elected root within IDLE_ARB_STATE_TIMEOUT after the end of a bus reset. An isolated node should preferably cease isochronous activity until after it is no longer an isolated node, alternatively, an isolated node acting as cycle master should set the root hold-off bit in the PHY by issuing a PHY configuration packet after every bus reset. Any node intending to start or restart isochronous activity should first ensure that there is an active cycle master on the bus. Future PHY implementations should not issue a bus reset on IDLE_ARB_STATE_TIMEOUT caused by an isochronous request but set the timeout bit and generate a PHY interrupt to the link layer. The isochronous request remains queued but the idle_arb_state_timer is deactivated.
8.4.4 Power management (cable environment) One of the benefits of the serial bus in the cable environment is that the cable itself can supply modest amounts of power to connected nodes. Along with this benefit comes the requirement that the distribution of power be managed, in either a sophisticated or a simple fashion. The bus manager shall implement a power management scheme that performs consistency checks and the IRM, in the absence of a bus manager, may implement an elementary power management scheme. Each node on the serial bus has at least three components that require power to function: the PHY, the link layer, and the SBM layer. There may be additional application components, visible as units, that also require power. The necessary power may originate from a power source associated with the node or it may be taken from the cable.
236
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
8.4.4.1 PHY power management It is a minimum requirement that the PHY of a node be powered and active while the node is connected to the serial bus. The self-ID packet generated by the PHY during the self-identify processes advertises whether the PHY consumes power from the bus or is self-powered. It is also a minimum requirement that any serial bus node with an active PHY shall have an active and powered node controller component within the SBM layer. This is necessary so that the PH_EVENT.indication with an event of LINK ON may be processed and in turn generate the appropriate LK_CONTROL.requests to initialize and activate the link layer. Nodes whose PHY is not active are effectively absent from the serial bus. If such a node is a leaf, no problems result; if power is subsequently available and the PHY becomes active, it generates a bus reset and the node identifies itself as part of the new topology. If such a node is in the middle of a serial bus, it effectively breaks the bus in two; the separate serial buses function normally. If power is subsequently supplied and the PHY becomes active, the two serial buses would be reconfigured as one after the bus reset.
8.4.4.2 Link power management The power source for the link layer determines the state of the link layer after a POR. If the link layer obtains its power from the cable, the link layer shall be inactive and unpowered after a POR until the receipt of a link-on packet. If the link layer is independently powered, it may be active or inactive after a POR, at the option of the SBM layer. An independently powered but inactive link layer may become active either through the receipt of a link-on packet or as the result of an action taken by the node controller.
8.4.4.3 Unit power management The power requirements of one or more units within a serial bus node are visible in two ways: the self-ID packet transmitted by the node during the self-identify process and the Unit_Power_Requirements entries in the configuration ROM. The self-ID packet describes the maximum power the node may consume once it is enabled by a link-on packet. If one or more units implement architectures that can consume additional power once they are enabled by unit-dependent means, these additional power requirements shall be specified by a Unit_Power_Requirements entry for each such unit. The maximum power consumption of a node may be calculated by adding the value of the power_requirements fields from all the Unit_Power_Requirements entries to the power requirements in the pwr field of the self-ID packet.
8.4.4.4 Power management by the bus manager When a bus manager is selected from among the candidate bus-manager-capable nodes, it shall perform power management functions as follows: a)
The total power requirements of the bus shall be calculated from the pwr z fields in the self-ID packets received during the self identify process.
b)
The total power available on the bus shall be calculated from the self-ID packets.
c)
If the power requirements exceed the power available, an SB_EVENT.indication with a parameter that indicates Insufficient Cable Power shall be provided to the application at the bus manager node.
d)
If the power requirements are less than or equal to the power available, link-on packets shall be transmitted to all nodes whose self-ID packet indicated an inactive link layer.
If there is insufficient power to activate the link layers of all nodes on the serial bus, it shall be the responsibility of an application at the bus manager node to determine which, if any, of the nodes should receive link-on packets. The application shall use the SB_CONTROL.request service to cause the bus manager to transmit the necessary link-on packets.
Copyright © 2008 IEEE. All rights reserved.
237
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
8.4.4.5 Power management by the IRM The IRM, in the absence of a bus manager, may issue link-on packets to all nodes whose self-ID packet indicated an inactive link layer. There is no requirement for the IRM to perform any power requirement calculations prior to the transmission of link-on packets.
8.4.5 Topology management (cable environment) The bus manager shall use topology information collected from self-ID packets received after a bus reset to construct the TOPOLOGY_MAP registers visible to other serial bus nodes. (See Annex for an efficient way to do the topology analysis.) As soon as a bus manager is selected from the candidates for this role, the bus manager shall compute the TOPOLOGY_MAP registers from the self-ID packets. The bus manager shall insure that the observed self-ID packets, including its own transmitted self-ID packet, meet the following requirement: —
The total of all connected ports that are connected to parents equals the total of all connected child ports.
If the observed self-ID packets are not consistent, the bus manager shall not make a topology map available, i.e., the bus manager shall set the length field of the TOPOLOGY_MAP registers to zero, but the bus manager shall not initiate a bus reset. The inconsistent condition shall be reported to the application layer by means of an SB_EVENT.indication that indicates Topology Error. The bus manager may use consistent topology information to optimize performance of the serial bus, as described in 8.4.5.2. Before the bus manager changes the topology map for any reason, it shall first set the length field of the TOPOLOGY_MAP registers to zero. After the changes are complete, the generation_number shall be incremented, a new CRC calculated, and the length field restored.
8.4.5.1 Accessing the topology map Applications at transaction-capable nodes that need to obtain accurate information from the TOPOLOGY_MAP registers shall use the following procedure: a)
b)
Read the first quadlet of the TOPOLOGY_MAP registers, which contains a length field that describes the data that follows and a CRC field whose value has been calculated over that data length 1)
If the length field is zero, the TOPOLOGY_MAP is not valid, and the application shall not utilize any data contained within the TOPOLOGY_MAP
2)
If the length field is nonzero, the application shall read the TOPOLOGY_MAP quadlets
Read the first quadlet of the TOPOLOGY_MAP registers once again and compare its value to the value obtained the first time that the length and CRC fields were read 1)
If they are identical, the values of the TOPOLOGY_MAP quadlets are accurate
2)
If the values are not identical, the values of the TOPOLOGY_MAP quadlets are not guaranteed to be accurate and shall not be used
If this procedure fails to return usable TOPOLOGY_MAP quadlets, either because the length field was zero or because the values of the length and CRC fields changed between the two read transactions, the entire procedure may be retried by the application.
238
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
8.4.5.2 Gap count optimization The value of gap_count shall not be reduced to a point where either a)
An asynchronous subaction is interrupted by node(s) other than the source and destination, or
b)
Where all nodes fail to consistently and identically detect both subaction and arbitration reset gaps.
Once a value for gap_count is selected, the remainder of this subclause specifies the procedures that shall be used to establish that value uniformly for all nodes on the bus. The bus manager20 may optimize serial bus performance by transmitting a PHY configuration packet (see 16.3.3.4) with the gap_cnt field set to a value less than 63 and the T bit set to 1. Nodes other than the bus manager may transmit a PHY configuration packet with the T bit set to 1 so long as the value of the gap_cnt field is equal to the node’s gap_count variable (obtained by a read of PHY register one). A node that transmits a PHY configuration packet with the T bit set to one shall initiate a bus reset as soon as possible after the PHY configuration has been sent. This is essential so that the gap_count_reset_disable variable at all node(s) is cleared to FALSE. Without this precaution, the subsequent addition of a new node to the bus could result in different values of gap_count at different nodes and resultant unpredictable arbitration behavior. Subsequent to a bus reset, the bus manager shall verify the self-ID packets generated as a result. If the gap_cnt field in all the self-ID packets is not identical, the bus manager shall initiate another bus reset. This additional bus reset should cause all nodes to have the same value for gap_count, 63. If a more optimal gap count value is desired, the bus manager may retransmit a PHY configuration packet prior to the bus reset. NOTE—Differences in the reset state machines between PHYs that do not support Arbitration Compliance Level A (see 15.1) or higher and those compliant with this standard may result in different gap counts (subsequent to a bus reset preceded by a PHY configuration packet) when a mixture of devices is present. The probability of this inconsistency may be reduced by asserting BUS_RESET for 166.6 µs instead of the arbitrated (short) bus reset specified by this standard—but this remedy should not be applied unless inconsistent gap counts have been observed subsequent to arbitrated (short) bus resets. This heuristic does not guarantee uniform values for gap_count at all nodes; nevertheless, because of the probabilistic nature of the problem, success is likely after a modest number of attempts.
8.4.6 Filtered packets on an asynchronous-only B_bus On an asynchronous-only B_bus it is possible for a sequence of concatenated asynchronous packets to last indefinitely. If such a sequence is speed-filtered, then a receiving PHY sees an arbitrary long DATA_NULL. If the duration of the DATA_NULL is longer than the PHY’s arb state timeout, then it generates a bus reset The problem is avoided if there is a gap in packet transmission or if a packet that is not speed filtered is transmitted. A way of guaranteeing this is to enable the cycle master. A bus manager should ensure that the cycle master is active, and only disable it if all the connections are operating at the same rate (thus avoiding packet speed filtering) and that it can determine that there is no requirement for isochronous traffic on the bus.
8.5 Bus configuration state machines (cable environment) The text provided in 8.4.2, which describes the bus configuration procedures that shall occur after a bus reset or power reset, can also be specified more precisely by state machines. The state machines described in the 20In
the absence of a bus manager, the IRM is permitted to assume some of the responsibilities of the bus manager, including gap count optimization. Throughout this subclause the phrase bus manager is understood to mean either the bus manager or the IRM in its role as limited bus manager.
Copyright © 2008 IEEE. All rights reserved.
239
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
remainder of this clause are assumed to be executing at all of the serial bus nodes that have the relevant capabilities: cycle master, IRM, or bus manager. Note that all of the state machines arrive at states such that there is one and only one node on the serial bus that has assumed each of these roles. A single node of course may assume more than one role, as permitted by the rules of the state machines. For example, the root node could become the cycle master, the IRM, and the bus manager.
8.5.1 Candidate cycle master states Each serial bus node that is cycle master capable shall execute the state machine described in Figure 8-25. If the node has other capabilities, other state machines may be executing concurrently. In this case, the SBM variables, described in 8.3.2.6.5, are the only means by which the state machines explicitly share information.
Figure 8-25—Candidate cycle master state machine
State CM0: Cycle master idle. The STATE_CLEAR.cmstr bit is clear and the node shall not broadcast any cycle start packets. Automatic updates of the CYCLE_TIME register by the hardware of the node shall be enabled, but the CYCLE_TIME register shall be synchronized to the time value contained in any cycle start packet received. Transition CM0:CM1. Another node, either the bus manager or the IRM, has enabled cycle master activity at this node by a write to STATE_SET.cmstr with a value of one. If this node is not the root, it shall ignore the write and STATE_CLEAR.cmstr shall retain a zero value. Otherwise, this node shall become an active cycle master. Transition CM0:CM0. The cycle master shall remain in the idle state if a bus reset is detected. State CM1: Cycle master active. The STATE_CLEAR.cmstr bit is set and automatic hardware update of the CYCLE_TIME register is enabled, as described in 8.3.2.2.8. A cycle start packet shall be broadcast each time the cycle_count field in the CYCLE_TIME register increments. The cycle master shall remain active until either a bus reset occurs or the STATE_CLEAR.cmstr bit is cleared. Transition CM1:CM0. Either the bus manager or the IRM has written a zero to the STATE_CLEAR.cmstr bit. The automatic hardware update of CYCLE_TIME shall be disabled. The cycle master shall not broadcast cycle start packets and shall transition to the idle state.
240
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition CM1:CM2. A bus reset has been detected, as notified by a PH_EVENT.indication. The automatic hardware update of CYCLE_TIME shall be disabled. The cycle master shall not broadcast cycle start packets and shall transition to the reset state. State CM2: Cycle master reset. The cycle master shall wait for the completion of the self-identify process that follows a bus reset. If the cycle master is still the root node, it shall revert to the active state. If the cycle master is no longer the root, it shall clear the STATE_CLEAR.cmstr bit and proceed to the idle state. Transition CM2:CM0. The cycle master is no longer the root and shall transition to the idle state after clearing the STATE_CLEAR.cmstr bit. Transition CM2:CM1. The cycle master is still the root and shall transition to the active state in order to resume the broadcast of cycle start packets.
8.5.2 Candidate IRM states Each serial bus node that is IRM capable shall execute the state machine described in Figure 8-26. If the node has other capabilities, other state machines may be executing concurrently. In this case, the SBM variables, described in 8.3.2.6.5, are the only means by which the state machines explicitly share information.
Figure 8-26—Candidate IRM state machine Transition All:IRM0. A bus reset detected in any state shall cause the candidate IRM to transition to the inactive state. All isochronous resources, the BANDWIDTH_AVAILABLE register, and the CHANNELS_AVAILABLE registers are reset to their initial values upon entry to this state. The BUS_MANAGER_ID register is also reset to its initial value, 3F16. Copyright © 2008 IEEE. All rights reserved.
241
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State IRM0: IRM inactive. The IRM is inactive, either as a result of a POR, a bus reset, or a determination that another candidate has become the IRM. The candidate IRM awaits the completion of the self-identify process that follows a bus reset. Read and lock (compare and swap) transactions to the BANDWIDTH_AVAILABLE, CHANNELS_AVAILABLE, and BUS_MANAGER_ID registers are accepted by IRM-capable nodes in this and all other states. Transition IRM0:IRM1. The candidate IRM has received a PH_CONTROL.indication with an event of SELF ID COMPLETE. The candidate IRM shall have stored all received self-ID packets, which at this time are available for inspection. State IRM1: Determine IRM. The candidate IRM shall examine the self-ID packets in order to determine the physical ID of the IRM, as described in 8.4.1.3. The SBM variable IRM ID is set to the value determined by this process. Transition IRM1:IRM0a. The self-ID packets observed by this node are inconsistent, as described in 8.3.3. The candidate IRM shall issue a PH_CONTROL.request with an action of Bus Reset and transition to the inactive state. Transition IRM1:IRM0b. The candidate IRM has determined that another candidate has assumed the role of IRM, as described in 8.4.1.3. The candidate IRM shall transition to the inactive state. Transition IRM1:IRM2. The candidate IRM has determined that it has assumed the role of IRM, as described in 8.4.1.3. The candidate IRM shall transition to the delay state. State IRM2: Delay. The IRM shall wait 625 ms before proceeding to the query bus manager state. Transition IRM2:IRM3. After 625 ms have elapsed, the IRM shall transition to the query bus manager state. State IRM3: Query bus manager. The IRM shall determine whether or not a bus manager is active on the serial bus, as described in 8.4.2.3. If the value of the BUS_MANAGER_ID register is 3F16, there is no bus manager, and the IRM shall continue to the active state. If the value of the BUS_MANAGER_ID register is other than 3F16, a bus manager is active, and the IRM shall not perform any bus management but shall proceed to the inactive state. Transition IRM3:IRM0. The BUS_MANAGER_ID register contains a value other than 3F16. A bus manager is active, and the IRM shall transition to the inactive state. Transition IRM3:IRM4. The BUS_MANAGER_ID register contains the value 3F16; the IRM shall transition to the active state. State IRM4: IRM active. The IRM shall determine whether or not a cycle master is active. If a cycle master is not active, the IRM shall select a cycle-master-capable node and make it active as the cycle master, as described in 8.4.2.6. The IRM may initialize the BUS_TIME and CYCLE_TIME registers by means of a broadcast write. The IRM may issue link-on packets to any nodes whose self-ID packets indicated an inactive link layer, as described in 8.4.4.5. The IRM may also optimize the gap_count setting.
8.5.3 Candidate bus manager states Each serial bus node that is bus manager capable shall execute the state machine described in Figure 8-27. If the node has other capabilities, other state machines may be executing concurrently. In this case, the SBM variables, described in 8.3.3, are the only means by which the state machines explicitly share information.
242
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 8-27—Candidate bus manager state machine Transition All:BM0. A bus reset detected in any state shall cause the bus manager or candidate bus manager to transition to the inactive state. State BM0: Bus manager inactive. The bus manager is inactive, either as a result of a POR or a bus reset. The candidate bus manager awaits the completion of the self-identify process that follows a bus reset. Transition BM0:BM1. The candidate bus manager has received a PH_CONTROL.indication with an event of SELF ID COMPLETE. The candidate bus manager shall have stored all received self-ID packets, which at this time are available for inspection. State BM1: Determine IRM. The candidate bus manager examines the self-ID packets in order to determine the physical ID of the IRM, as described in 8.4.2.3. The SBM variable IRM ID is set to the value determined by this process. Transition BM1:BM0. The self-ID packets observed by this node are inconsistent, as described in 8.4.2.3. The candidate bus manager shall issue a PH_CONTROL.request with an action of Bus Reset and transition to the inactive state. Transition BM1:BM2. The SBM variable Incumbent is FALSE. State BM2: Non-incumbent delay. This node was not the bus manager prior to the bus reset or power reset. The candidate bus manager shall wait 125 ms and then transition to the bus manager contention state. Transition BM1:BM3. The SBM variable Incumbent is TRUE. Transition BM2:BM3. After 125 ms have elapsed, the candidate bus manager shall transition to the bus manager contention state.
Copyright © 2008 IEEE. All rights reserved.
243
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State BM3: Bus manager contention. The candidate bus manager shall contend for the role of bus manager by means of the procedure described in 8.4.2.1. If the value of the BUS_MANAGER_ID register obtained from a lock (compare and swap) transaction to the IRM is 3F16, the candidate bus manager has won and is confirmed as the bus manager. Otherwise, another candidate for the role of bus manager has won, and the bus manager at this node shall return to the inactive state. Transition BM3:BM0. A value other than 3F16 has been returned by the lock (compare and swap) transaction to the BUS_MANAGER_ID register at the IRM. The SBM variable Incumbent shall be set to FALSE, and the candidate bus manager shall transition to the inactive state. Transition BM3:BM4. The lock (compare and swap) transaction to the BUS_MANAGER_ID register at the IRM has returned a value of 3F16. The node variable Incumbent shall be set to TRUE, and the bus manager shall transition to the active state. State BM4: Bus manager active. The candidate bus manager is now active and shall directly commence operations to ensure that, if any isochronous capable nodes are present, a cycle master is present and active; make the TOPOLOGY_MAP registers available; and make the SPEED_MAP registers available. In addition, the bus manager may optimize the arbitration gap characteristics of the serial bus. These procedures are described in 8.4.5.
8.5.4 Abdication by the bus manager A bus manager-capable node that wishes to assume the role of bus manager shall proceed as follows: a)
The candidate bus manager shall set the abdicate bit in the incumbent bus manager’s STATE_SET register.
b)
The candidate bus manager shall initiate a serial bus reset.
c)
Subsequent to the bus reset, the candidate bus manager shall attempt to become the bus manager in accordance with the procedures in this standard, with one exception. The candidate bus manager shall not wait 125 ms before making a lock transaction to the BUS_MANAGER_ID register at the IRM node, but shall attempt to become the bus manager immediately upon the completion of the self-identify process.
d)
If the candidate bus manager fails to become the bus manager, it may transmit a PHY configuration packet with the R bit set to one, and the root_ID field set to the value of the candidate’s own physical ID. The candidate bus manager shall not transmit such a PHY configuration packet unless it meets the requirements of 8.4.2.6. The effect of such a PHY configuration packet is to clear the force_root variable of other nodes to FALSE. The candidate bus manager shall insure that its own force_root variable is TRUE21, initiate a serial bus reset, and attempt to become the bus manager as described in item c).
NOTE—The last step is necessary to wrest control of the bus manager role from an incumbent bus manager that is the root and does not implement the abdicate bit. When the candidate bus manager becomes the root after the bus reset it has the highest arbitration priority of all the nodes on the bus and should be able to be the first to complete a lock transaction to the BUS_MANAGER_ID register.
The means by which a candidate bus manager determines that it is more capable than the incumbent bus manager are not specified by this standard. The candidate may interrogate the incumbent bus manager’s CSRs for the presence or absence of advanced features or the two nodes may engage in some negotiation to determine which is more capable.
21PHYs
that do not support Arbitration Level A or greater (see 15.1) may require a separate PHY register write to set the value of force_root.
244
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
9. Short-haul copper PMD electrical specification 9.1 Introduction This clause specifies the electrical signaling properties for the short-haul (4.5 m or less) copper PHY. Figure 9-1 highlights the architectural units discussed in this clause.
Link B PHY
port controller
request/grant, enable send LTP PHY packets
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
to other ports
Port
Betamode functions
Connection management
DS-mode functions
Betamode functions
Low-power signaling
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
Connection management
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD Short-haul copper electrical
Short-haul copper electrical
Figure 9-1—PHY master architecture (short-haul copper electrical PMD in context) 9.1.1 Short-haul copper PHY operation The operation of the short-haul copper PHY can best be understood with reference to the architectural diagram shown in Figure 9-2.
Copyright © 2008 IEEE. All rights reserved.
245
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 9-2—Short-haul copper PHY architecture The main controller of the PHY is the block labeled “arbitration control,” which responds to arbitration requests from the link layer (PH_ARB.request) and changes in the state of its ports. It provides the management and timing signals for transmitting, receiving, and repeating packets. It also provides the bus reset and configuration functions. The operation of this block is described in 16.4.2. The “data resync” block decodes the DS signal and retimes the received data to a local fixed frequency clock provided by the “local clock” block. Since the clocks of receiving and transmitting nodes can be up to 100 ppm different from the nominal, the data resync function shall be able to compensate for a difference of 200 ppm over the maximum packet length of 84.31 µs (1024 byte isochronous packet at S100). The operation of this block is described in 9.2.9.2. The “data & signal decode” block provides a common interface to the link layer for both packet data and arbitration signals (gaps and bus reset indicators). The “xmit selection & encode” block is the selector between repeated data and data sent by the link layer. It also generates the strobe signal for the transmitted data. Its operation is described in 9.2.9.1. Each port has an associated “port output control” that selects either the arbitration control signals or the DS pair for transmission. Subclauses 9.2 and 9.3, along with the C code in Clause 19, normatively specify the operation of the shorthaul copper PHY by means of state machine diagrams, C code, and expository text in the body of the standard (which includes the notes that accompany the state machine diagrams but excludes any text within
246
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
figures or tables). In case of conflict, precedence shall be given first to the state machine diagrams, second to the C code, and last to the expository text. Note that neither the C code nor the state machines are normative descriptions of implementations; they are normative descriptions of externally apparent PHY behaviors. Different implementations are possible.
9.1.2 Short-haul copper physical connection specification For the short-haul copper medium, the serial bus uses point-to-point (P2P) physical connections between nodes with a pair of differential signals TPA/TPA* and TPB/TPB* where the use of each pair is different depending on whether the node is arbitrating, transmitting data, or receiving data. Each physical connection consists of a port on each node and the cable between them. The actual cable assemblies use four-, six-, or nine-conductor cables with small and rugged connectors. The limitations on this system are set by the requirement of the arbitration protocol for a fixed round-trip time for signals. The default timing is set after at most two bus resets, and it is adequate for 32 cable hops, each of 4.5 m for a total of 144 m.22 In addition. the topology has to be “acyclic” (no closed loops). Any closed loops will prevent the tree identify process described in 16.4.7 from completing. See Figure 9-3.
Figure 9-3—Cable topology NOTE—Serial bus systems may be required to conform to (USA) FCC Part 15 rules for Class B operation. Because serial bus systems may be configured from equipment components and cables from more than one source, it is strongly recommended that the designs of individual cables and equipment follow the shielding and grounding practices required and/or suggested in this standard.
22
Annex A describes other possible configurations. Also see 16.4.9 for considerations involving large diameter networks.
Copyright © 2008 IEEE. All rights reserved.
247
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
9.1.3 Interfaces All interface specifications apply at the points of entry and exit from the equipment. The interface specifications may be valid at other places. These points are identified as points TP2 and TP3 as shown in Figure 9-4. The specifications assume that all measurements are made after a mated connector pair, relative to the source or destination, and that measurements will be adjusted by an allowance where appropriate for the connector or socket used to connect the test and/or measurement equipment to the interface. TP1 and TP4 are reference points for use by implementers to specify vendor components.
TP1
TP2
TP3
TP4
T+
TRANSMIT
RECEIVE
R+
T-
NETWORK
NETWORK
R-
PHY
PHY
Figure 9-4—Measurement points (half connection is shown) The reference points for all connections are the points TP2 and TP3 at the transitions between the socket and mating plug. If sections of transmission line exist before the socket, they are considered to be part of the associated transmit or receive network and not part of the cable plant. For both TP2 and TP3, the physical measurement point shall be as close as is practical to the mated connector pair. The measurement point shall be upstream of the mated connector pair for signals being applied to the UUT and downstream of the mated connector pair for signals emanating from the UUT. NOTE—Schematics in the diagrams in this clause are for illustration only and do not represent the only feasible implementation.
9.1.4 Modes of operation There are two modes of operation for the short-haul copper PMD: DS mode, which is specified in 9.2; and Beta mode, which is specified in 9.3. Table 9-1 gives an overview of the two modes.
Table 9-1—Short-haul copper PMD modes of operation Mode
Data rates
Coding
Connectors
Port type
DS
S100 to S400
NRZ data and Strobe
6-circuit (4.2) or 4-circuit (4.3)
Alpha
Beta (B)
S400 to S3200
8B/10B
9-circuit Beta or bilingual (4.4)
Beta
9.2 Data-strobe (DS) mode specification 9.2.1 Port interface A port consists of two twisted pair interfaces, TPA/TPA* and TPB/TPB*, and an optional power distribution pair, VP/VG. A node may have from one to sixteen such ports. Each port has associated
248
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
circuitry that provides separate signals for arbitration or for packet data reception and transmission, as shown in Figure 9-5. Twisted Pair A
Twisted Pair B
Connect_detect ICD
TpBias disable
+ -
Common-mode speed signal current
TpBias’ 0.3μF typical
VG TPA
S100 node UNUSED S200 node uses 0 and 3.5 mA S400 node uses 0, 3.5 and 10 mA
TPB
Driver
55Ω
55Ω
Strb_Tx
55Ω
Speed_Tx
TPA*
TPB*
Data_Tx
55Ω Data_Enable
Strb_Enable Receiver
Data_Rx
250pF
+
-
5kΩ
+
±5%
VG
Arbitration Comparators
Arbitration Comparators
(shared with TPA and other ports)
+
Strb_Rx
-
+
-
-
+
+
Arb_B_Rx
Arb_A_Rx
-
-
Speed_Rx
7kΩ
7kΩ
7kΩ
+
+
-
7kΩ
0.8V
TpBias’
-
Bias_Detect
TpBias detection comparator
S100 only node does not need this comparator S200 node needs one comparator S400 node needs two of these comparators
Figure 9-5—Port interface The TPA/TPA* pair transmit the Strb_Tx signal and receive the Data_Rx, Arb_A_Rx, and Speed_Rx signals. The TPB/TPB* pair transmits the Data_Tx and Speed_Tx signals and receives the Strb_Rx, Arb_B_Rx, and Bias_Detect signals. The Strb_Tx, Data_Tx, Strb_Enable, and Data_Enable signals are used together to generate the arbitration signals. The Arb_A_Rx and Arb_B_Rx signals are each generated by two comparators since they have three states—zero, one, or high impedance. A PHY (or a circuit board that includes a PHY) shall not assert voltages greater than 0.4 V on TPA/TPA* while unpowered. Care should be taken to insure this requirement is met in the case that the peer PHY is powered and generating TpBias. When enabled, the TPA/TPA* pair transmit TpBias while the TPB/TPB* pair receive the TpBias signal (this is used by the Bias_Detect comparator to determine presence or absence of TpBias). When TpBias is not generated, the connect detect circuit can detect the presence or absence of a peer PHY at the other end of a cable connection. Designers shall select appropriate threshold voltage and hysteresis values for the connect detect circuit so as to avoid erroneous detection of connection status changes while TpBias discharges.
Copyright © 2008 IEEE. All rights reserved.
249
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The bias generation circuit (including the external capacitor) shall be designed so that when TpBias is driven low for at least 0.5 ms, the capacitor shall be discharged and output bias shall be less than 0.1 V relative to VG. In contrast, when TpBias is generated, the capacitor shall be recharged, and the TPA/TPA* signals shall be within the specifications of Table 9-4 (in 9.2.1.2) (within 1.0 ms). NOTE—Designers should examine the interrelationships between these times and BIAS_HANDSHAKE in order to avoid a fault during resume operations.
The current source used by the connect detect circuit, ICD, shall not exceed 76 μA. This guarantees that the input to the peer PHY’s bias detection circuit does not exceed 0.4 V.
9.2.1.1 Signal amplitude For the test loads shown in Figure 9-6, the drivers for TPA and TPB shall provide the differential output signal amplitude given in Table 9-2 (an additional 10% is allowed for signal overshoot).
Figure 9-6—Differential output test loads
Table 9-2—Differential output signal amplitude Maximum
Minimum
Units
265
172
mV
The TPA differential output amplitude is measured between the and TPA* pins; the TPB differential output amplitude is measured between the TPB and TPB* pins. The magnitude of the TPA differential output voltage shall meet the limits of Table 9-2 for all values of the common mode current (Icm) as specified in Table 9-7 (in 9.2.1.3). The magnitude of the TPB differential output voltage shall meet the limits of Table 9-2 for all values of the common mode voltage (Vcm) as specified in Table 9-5 (in 9.2.1.2). At the receiving end of the cable, the signal amplitude detection limits shall be as given in Table 9-3.
250
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 9-3—Differential receive signal amplitude S100 (mV)
S200 (mV)
S400 (mV)
Signal Max
Min
Max
Min
Max
Min
During arbitration (Arb_A, Arb_B valid)
260
173
262
171
265
168
During clocked data reception (Data_Rx, Strb_Rx valid)
260
142
260
132
260
118
At the receiving end of the cable, the receivers and arbitration comparators shall operate with signals having amplitudes as specified in Table 9-3. The TPA receivers and arbitration comparators shall meet the input requirements for common mode voltages as specified in Table 9-4. The TPB receivers and arbitration comparators shall meet the input requirements for common mode voltages as specified in Table 9-5.
9.2.1.2 Common mode voltage TPA is the source of the common mode bias voltage (relative to the power ground pin, VG), and it shall meet the requirements of Table 9-4 when common mode signaling is on (speed signaling active) and off (no speed signaling).
Table 9-4—TPA common mode output voltage Condition Maximum Minimum
Limit (V) 2.015
Speed signaling off
1.665
S100 speed signaling
1.665
S200 speed signaling
1.438
S400 speed signaling
1.030
The test load is shown in Figure 9-6. The TPA common mode output voltage is measured as the average of the voltages on the TPA and TPA* pins. The value of this voltage shall meet the limits of Table 9-4 for all values of Icm as specified in Table 9-7 (in 9.2.1.3).
Copyright © 2008 IEEE. All rights reserved.
251
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The common mode input voltage received at the TPB pair shall remain within the limits shown in Table 9-5 relative to the power ground pin VG.
Table 9-5—TPB common mode input voltage Condition
Limit (V) 2.515 a
Maximum Minimum
Speed signaling off
1.165
S100 speed signaling
1.165
S200 speed signaling
0.935
S400 speed signaling
0.523
aFor an end-of-wire power-consuming device, the maximum will be 2.015 V since
there is no need to budget for the 0.5 V power supply drop possible, given the power pair resistance specified in 4.2.4.6 and the maximum power pair current specified in 9.2.1.7.
The common mode input voltage is also used to determine the connection status of the port as shown in Table 9-6.
Table 9-6—Port_Status signal condition Port_Status
Condition
DISCONNECTED
TPB common mode input ≤ 0.6 V
Undefined
0.6 V < TPB common mode input < 1.0 V
CONNECTED
TPB common mode input ≥ 1.0 V
This signal shall not be sampled when common mode signaling is active (speed signaling), so there is no danger of accidentally assuming that the port is disconnected.
9.2.1.3 Speed signaling When common mode signaling is on (speed signaling), the TPB common mode signal driver shall source the appropriate current to indicate the maximum data rate that can be received by this port. Similarly, the TPA common mode signal receiver shall use the levels in Table 9-7 to determine the maximum data rate that can be received by the attached port. NOTE—Since the link layer has a minimum packet size and the PHY imposes packet starting and ending times, the maximum pulse repetition frequency for speed signaling is 1.89 MHz.
The TPB common mode speed signaling output current is measured as one half of the algebraic total current flowing out the TPB and TPB* pins. The value of this current shall meet the limits of Table 9-7 for all values of Vcm as specified in Table 9-5. This current is measured for the test loads shown in Figure 9-7.
252
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 9-7—Common mode current test loads Table 9-7—TPB common mode output current and TPA common mode input current Data rate (mA) Signal
Speed_Tx = S100
Speed_Tx = S200
Speed_Tx = S400
Max
Min
Max
Min
Max
Min
Common mode signaling off (Speed_Tx = S100)
0.44
–0.81
0.44
–0.81
0.44
–0.81
Common mode signaling on
0.44
–0.81
–2.53
–4.84
–8.10
–12.40
9.2.1.4 Arbitration signal voltages During cable arbitration (including tree identify and self-identify as well as normal operation), the arbitration receive signals, Arb_A_Rx and Arb_B_Rx, will take three different values when TPA/TPB meet the requirements of Table 9-8.
Table 9-8—Arbitration signaling levels Arb_n_Rx a
Maximum (mV)
1
Minimum (mV)
168
Z
89
0
–168
–89
a
“n” is “A” or “B.”
NOTE—The minimum signal level for the 1 Arb_n_Rx value and maximum signal level for the 0 value correspond to the minimum differential receive amplitudes for all speeds in Table 9-3.
Copyright © 2008 IEEE. All rights reserved.
253
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
9.2.1.5 Input impedance Both TPA and TPB shall meet the input impedance requirements of Table 9-9.
Table 9-9—Differential input impedance Parameter
Test condition
Maximum
Minimum
Units
Rin
Receive mode
112
108
Ω
Rintx
Transmit mode
112
105
Ω
Cin
S100-only port
9
pF
S200-capable port
7
pF
S400-capable port
4
pF
If a node cannot be characterized as a point impedance, then the alternate requirement is that the amplitude of a reflection using a differential TDR with a 0.5 V and 1 ns rise time shall not exceed 240 mV for S100-only ports, 187 mV for a S200-capable port, and 107 mV for a S400-capable port.
9.2.1.6 Noise The maximum output common mode noise, Vcmout, shall be 200 mV peak-to-peak (pk-pk) during arbitration and 30 mV during data transmission, as measured in a 400 MHz bandwidth using the test loads shown in Figure 9-8.
Figure 9-8—Common mode output noise test loads The maximum input common mode noise shall be 225 mV pk-pk during arbitration and 55 mV pk-pk during packet reception. This shall be measured in a bandwidth of 20 MHz to 400 MHz. The maximum input differential noise shall be 8mV pk-pk.
254
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
9.2.1.7 Driver and receiver fault protection The drivers and receivers shall tolerate –0.5 V to +2.83 V without damage. NOTE—All transceivers will have the additional protection of the termination network.
9.2.2 Media signal timing 9.2.2.1 Data rate The DS cable media supports three different data rates. The lowest rate (98.304 Mbit/s) is required and is called the base rate. All ports that support a higher data rate shall also support all lower rates. See Table 9-10.
Table 9-10—DS media data rates Data rate Units S100 Data rate Nominal bit cell time aBit
a
S200
S400
98.304 ± 100 ppm
196.608 ± 100 ppm
393.216 ± 100 ppm
Mbit/s
10.17
5.09
2.54
ns
cell times are shown for reference. The standard is based on the data rate.
9.2.2.2 Data signal rise and fall times The output rise and fall times for data signals are measured from 10% to 90% and are dependent on the data rate as specified in Table 9-11.
Table 9-11—Output rise and fall times Rise or fall time Speed
Minimum (ns)
Maximum (ns)
S100
0.5
3.2
S200
0.5
2.2
S400
0.5
1.2
NOTE—The differential received signal amplitude specification in Table 9-3 is not a receiver sensitivity specification for PHY inputs. Designers should consider factors such as the worst-case received waveform (e.g., slow rise or fall times near the signal thresholds) and board design characteristics when choosing receiver sensitivity.
The input slope is measured at a differential offset of +25 mV for rising signals and –25 mV for falling signals and shall have a minimum value as shown in Table 9-12.
Copyright © 2008 IEEE. All rights reserved.
255
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-12—Input slope Speed
Minimum slope for data signals (mV/ns)
S100
60
S200
110
S400
175
9.2.2.3 Jitter and skew Table 9-13 gives the maximum jitter and skew limits for the three cable data rates. The complete jitter budget is given in E.2.
Table 9-13—DS jitter and skew (in ns) S100
S200
S400
Maximum transmitter skew
0.40
0.25
0.20
Maximum transmitter jitter
0.80
0.20
0.10
Maximum skew at receive pins
0.80
0.55
0.50
Maximum jitter at receive pins
1.08
0.50
0.315
9.2.3 Coding Attached peer PHY entities on the bus communicate via NRZ data. The NRZ data are transmitted and received as Data_Tx and Data_Rx and is accompanied by a strobe signal, Strb_Tx and Strb_Rx. This strobe signal changes state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on either Data or Strb. A clock that transitions every bit period can be extracted by performing an exclusive OR of Data_Rx and Strb_Rx, as shown in Figure 9-9. The primary rationale for use of this transmission code is to improve the transmission characteristics of information to be transferred across the serial bus. In particular, the code ensures that transitions occurring on Strb and Data are approximately one bit-period apart. This results in an increase in skew tolerance that could not be obtained with a clocked NRZ format. The procedure for encoding data during transmission is described in 9.2.9.1 and decoding during reception in 9.2.9.2.
9.2.4 DS PHY signals The DS PHY uses bidirectional dominant mode signaling during arbitration. The logical values are “1”, “0”, and “Z” and are generated by setting the drivers in 9.2.1.1 according to the rules in Table 9-14 and decoded using the rules in Table 9-15.
256
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure 9-9—DS coding
Table 9-14—Arbitration signal generation rules Drivers
Transmit arbitration signal A (Arb_A_Tx)
Strb_Tx
Strb_Enable
Z
—
0
TPA driver is disabled
0
0
1
TPA driver is enabled, strobe is low
1
1
1
TPA driver is enabled, strobe is high
Comment
Drivers
Transmit arbitration signal B (Arb_B_Tx)
Data_Tx
Data_Enable
Z
—
0
TPB driver is disabled
0
0
1
TPB driver is enabled, data are low
1
1
1
TPB driver is enabled, data are high
Comment
9.2.5 DS PHY line states The DS PHY encodes arbitration line states on the two transmit arbitration signals, Arb_A_Tx and Arb_B_Tx, using the rules in Table 9-16. Note that a particular encoding may have different meanings depending on whether it is sent to a parent or a child. The DS PHY decodes the interpreted arbitration signals (Arb_A and Arb_B) into line states using the rules in Table 9-17.
Copyright © 2008 IEEE. All rights reserved.
257
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-15—Arbitration signal decoding rules Received arbitration comparator value (Arb_na_Rx)
Transmitted arbitration signal for this port (Arb_n*_Tx)
Interpreted arbitration signal (Arb_n*)
Z
Z
Z
0
Z
0
1
Z
1
Z
0
1
If the comparator is receiving a Z while this port is sending a 0, then the other port must be sending a 1. This is the first half of the dominance rule for 1.
0
0
0
The other port is sending a 0 or a Z.
Z
1
1
The other port must be sending a 0. This is the other half of the dominance rule for 1.
1
1
1
The other port is sending a 1 or a Z.
a“n”
Comment
If this port is transmitting a Z, then the received signal will be the same as transmitted by the port on the other end of the cable.
is “A” or “B.” This table applies to both signal pairs.
Table 9-16—DS PHY transmitted arbitration line states Arbitration transmit Line state name
Comment
Arb_A_Tx
Arb_B_Tx
Z
Z
IDLE
Sent to indicate a gap
Z
1
TX_DISABLE_ NOTIFY
Request the peer PHY port to enter the suspended state. The transmitting port will be disabled.
Z
0
TX_REQUEST
Sent to parent to request the bus
TX_GRANT
Sent to child when bus is granted
258
0
Z
TX_PARENT_NOTIFY
Sent to parent candidate during the tree identify process
0
1
TX_DATA_PREFIX
Sent before any packet data and between blocks of packet data in the case of concatenated subactions
1
Z
TX_CHILD_NOTIFY
Sent to child to acknowledge the parent_notify
TX_IDENT_DONE
Sent to parent to indicate that the self-identify process is complete
0
0
TX_SUSPEND
Request the peer PHY to handshake TpBias and enter the suspended state. The request is also propagated by the peer PHY to its other active ports.
1
0
TX_DATA_END
Sent at the end of packet transmission
1
1
BUS_RESET
Sent to force a bus reconfiguration
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 9-17—DS PHY received arbitration line states Interpreted arbitration signals Arb_A
Line state name
Comment
Arb_B
Z
Z
IDLE
The attached peer PHY is inactive
Z
0
RX_PARENT_NOTIFY
The attached peer PHY wants to be a child
RX_REQUEST_CANCEL
The attached peer PHY has abandoned a request (this PHY is sending a grant)
Z
1
RX_IDENT_DONE
The child PHY has completed its selfidentify process
0
Z
RX_SELF_ID_GRANT
The parent PHY is granting the bus for a selfID packet
RX_REQUEST
A child PHY is requesting the bus
RX_ROOT_CONTENTION
The attached peer PHY and this PHY both want to be a child
RX_GRANT
The parent PHY is granting control of the bus
RX_PARENT_HANDSHAKE
The attached peer PHY acknowledges parent_notify
RX_DATA_END
The attached peer PHY has finished sending a block of data and is about to release the bus
0
0
0
1
1
Z
RX_CHILD_HANDSHAKE
The attached peer PHY acknowledges TX_CHILD_NOTIFY (the peer PHY is a child of this PHY)
1
0
RX_DATA_PREFIX
The attached peer PHY is about to send packet data or has finished sending a block of packet data and is about to send more
1
1
BUS_RESET
Sent to force a bus reconfiguration
0
0
RX_SUSPEND
Exchange TpBias handshake with the peer PHY and place the port into the suspended state. Also initiate suspend (i.e., propagate TX_SUSPEND) on all other active ports.
1
Z
RX_DISABLE_NOTIFY
Enter the suspended state and initiate short bus reset on all other active ports. The peer PHY port will be disabled.
NOTE—Some of the possible received values are unused by the arbitration protocols, and some of the above codes are “do not care” values for some of the states in the state machines of 16.4.8.
9.2.6 Cable PHY timing constants NOTE—This subclause defines new values and changes some previously defined constants from which the configuration and timing of the PHY in the cable environment may be derived.
Many of the values in Table 9-18 are required for hybrid bus operation. These values apply to buses where at least one of the connections between nodes is done with DS ports. In Table 9-18, Alpha packet means both Alpha packets on a Beta connection and any packet on a DS connection. A few constants are required only for border nodes.
Copyright © 2008 IEEE. All rights reserved.
259
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-18—Cable interface timing constants Timing constant
Minimum
Maximum
Comment
ARB_RESPONSE_DELAY
Maximum PHY_DELAY less 0.08 μs
See comment
Delay through a PHY from the start of reception of an arbitration line state to the start of transmission of the associated arbitration line state at all transmitting ports. Arbitration shall be repeated by the PHY at least as fast as clocked data. Applies to Alpha ports and to the control states at the start and end of packets.
ARB_SPEED_SIGNAL_START
–0.02 μs
—
(DS ports only.) Time delay between a DS transmitting port signalling TX_DATA_PREFIX and the same port transmitting a speed signal for either an unconcatenated packet or the first packet in a concatenated sequence.
BASE_RATE
98.294 Mb/s
98.314 Mb/s
Base bit rate (98.304 Mb/s ± 100 ppm)
BOSS_RESTART_TIME
10 μs
11 μs
Time allowed for a subaction to complete and to ensure that tokens are seen consistently on the bus (used only if a node does not use the Alpha gap count)
CM_MIN_IDLE_TIME
1.070 μs
—
Idle time not in the isochronous interval at proxy_root with an Alpha link.
CONCATENATION_PREFIX_ TIME
0.16 μs
—
For concatenated Alpha packets, the time a transmitting port shall signal DATA_PREFIX between the end of clocked data for one packet and the start of speed signaling time for the next.
CONFIG_TIMEOUT
166.6 μs
166.9 μs
Loop detect time. (~16384/BASE_RATE)
DATA_END_TIME
0.24 μs
0.26 μs
End of packet signal time for an Alpha packet. (~24/BASE_RATE)
DATA_PREFIX_HOLD
0.04 μs
—
At a transmitting port, the time between the end of speed signalling (when present) and the start of clocked data for an Alpha packet.
FORCE_ROOT_TIMEOUT
83.32 μs
83.34 μs
Time to wait in T0: Tree ID Start state (see Figure 16-17) before acknowledging RX_PARENT_NOTIFY. (~8192/BASE_RATE)
LONG_BOSS_RESTART_ TIME
83.32 μs
83.34 μs
Time allowed for a subaction to complete (used only if a node does not use the Alpha gap count and if large diameter networks are supported)
260
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 9-18—Cable interface timing constants (continued) Timing constant
Minimum
Maximum
Comment
LONG_ROOT_CONTEND_ FAST
3.58μs
3.59 μs
Time to wait in state T3: Root Contention if longContendTimer is selected and the random bit is zero, as described in 16.4.6. (~352/BASE_RATE)
LONG_ROOT_CONTEND_ SLOW
7.16 μs
7.18μs
Time to wait in state T3: Root Contention if longContendTimer is selected and the random bit is one, as described in 16.4.6. (~704/BASE_RATE).
MAX_ARB_STATE_TIME
200 μs
400 μs
Maximum time in any state (before a bus reset is initiated) except A0: Idle state (during the time that idleArbStateTimeout is false), T0: Tree ID Start state, or a state that exits after an explicit timeout.
MAX_BETA_TIME
83.324 μs
104.5
(Senior border node only.) Maximum time a senior border node shall wait after the beginning of any Beta traffic for an Alpha packet before sending a BORDER request. (When the BORDER request is granted, the senior border node shall send an Alpha packet if still required to free the various Alpha clouds. (Minimum is 8192/BASE_RATE.)
MAX_BUS_HOLD
—
1.63 μs
Maximum time an originating node may transmit DATA_PREFIX between concatenated packets. The link shall ensure that this time is not exceeded.
MAX_DATA_TIME
—
84.34 μs
Maximum time that clocked data may be transmitted continuously. If this limit is exceeded, unpredictable behavior may result.
MIN_DATA_PREFIX
0.14 μs
—
Time a port transmitting an Alpha packet is required to signal DATA_PREFIX prior to clocked data for either an unconcatenated packet or the first packet in a concatenated sequence.
MIN_DELETABLE_ SYMBOL_TIME
0.04 μs
—
Minimum time that an originating port is required to insert deletable symbols. (~4/BASE_RATE)
MIN_IDLE_TIME
0.04 μs
—
Minimum idle time (not including speed signalling on an Alpha port) after transmission of DATA_END for an Alpha packet at either an originating or repeating port. (~4/BASE_RATE)
MIN_PACKET_SEPARATION
0.34 μs
—
Minimum time that an originating port is required to signal DATA_PREFIX between concatenated Alpha packets. (~34/BASE_RATE)
Copyright © 2008 IEEE. All rights reserved.
261
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-18—Cable interface timing constants (continued) Timing constant
Minimum
Maximum
Comment
NOMINAL_CYCLE_TIME
124.988 μs
125.013 μs
Average time between the start of one isochronous period and the next. (125 μs ± 100 ppm)
PHY_DELAY
0.06 μs if PHY_DELAY = 144 ns
See PHY registers (Clause 15)
Measured from the receipt of the first data bit to its retransmission by the repeating port(s) for all combinations of ports and speeds. Best-case repeater data delay has a fixed minimum. If PHY_DELAY is reported in the PHY registers as being greater than 144 ns, then software may use the value (reported PHY_DELAY - reported JITTER) if this value is greater.
166.7 μs
Reset hold time. (~16384/BASE_RATE)
See comment
RESET_TIME
166.6 μs
RESET_WAIT
0.16 μs
RESPONSE_TIME
0.04 μs
PHY_DELAY + 0.1 μs
1) Idle time at all ports of the responding node, measured at the cable connector, from the end of DATA_END or DATA_END that follows a PHY packet or primary packet to the start of the next arbitration line state, DATA_PREFIX, DISABLE_NOTIFY, or SUSPEND. Applies to responding node. 2) Time between receipt of LTP value change and corresponding LTS transmit.
ROOT_CONTEND_FAST
1.62 μs
1.63 μs
Time to wait in state T3: Root Contention if the random bit is zero, as described in 16.4.6. (~160/BASE_RATE)
ROOT_CONTEND_SLOW
3.25 μs
3.26 μs
Time to wait in state T3: Root Contention if the random bit is one, as described in 16.4.6. (~320/BASE_RATE).
SHORT_RESET_TIME
1.26 μs
1.40 μs
Short reset hold time. (~128/BASE_RATE)
SID_SPEED_SIGNAL_START
–0.02 μs
0.02 μs
(DS ports only.) Time between a child DS port signalling TX_IDENT_DONE and the same port sending its speed capability signal.
SPEED_SIGNAL_LENGTH
0.10 μs
0.12 μs
Duration of a valid time that speed signal output is driven (~10/BASE_RATE) for Alpha packets.
Reset wait delta time. (~16/BASE_RATE)
Repeating ports are required to be designed to account for clock frequency and phase differences and still guarantee relevant times from Table 9-18.
262
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Some of the cable interface timing constants are more easily understood with the aid of diagrams. Figure 9-10 illustrates the relationship between data prefix and the concurrent speed signal at the start of packet transmission. The packet may be either an unconcatenated packet or the first packet of a concatenated sequence. Arbitration or Clocked data
TX_DATA_PREFIX
Speed signal
ARB_SPEED_SIGNAL_START
DATA_PREFIX_HOLD SPEED_SIGNAL_LENGTH MIN_DATA_PREFIX
Figure 9-10—Start of packet transmission Whether or not speed is explicitly signaled, TX_DATA_PREFIX shall be signaled by any transmitting port for at least the minimum time shown before clocked data are transmitted. For improved interoperability with legacy devices, TX_DATA_PREFIX should be signaled by the originating port(s) for a minimum of 180 ns prior to clocked data. Speed signaling occurs concurrently with data prefix but may commence up to 20 ns before the start of data prefix. This is difficult to show graphically and is represented by a negative value for ARB_SPEED_SIGNAL_START. Once speed signaling is initiated by a transmitting port, it shall be continued for SPEED_SIGNAL_LENGTH time. Speed signaling shall complete no less than DATA_PREFIX_HOLD time before the start of clocked data. Data prefix and speed signaling between two concatenated packets is similar to that for the first packet, but the speed signal is shifted later into the data prefix time as illustrated by Figure 9-11. Arbitration or Clocked data
TX_DATA_PREFIX
Speed signal
CONCATENTATION_PREFIX_TIME
DATA_PREFIX_HOLD SPEED_SIGNAL_LENGTH MIN_PACKET_SEPARATION
Figure 9-11—Concatenated packet transmission Originating ports shall guarantee MIN_PACKET_SEPARATION time between the clocked data of any two concatenated packets. Clock frequency and phase differences may cause a smaller separation at repeating ports, but in no case shall the minimum packet separation be less than the sum of CONCATENATION_PREFIX_TIME, SPEED_SIGNAL_LENGTH, and DATA_PREFIX_HOLD. After the end of clocked data for the previous packet, a transmitting port shall guarantee a delay of CONCATENATION_PREFIX_TIME before signaling the speed of the next packet. The requirements for SPEED_SIGNAL_LENGTH and DATA_PREFIX_HOLD are the same as for start of packet transmission.
Copyright © 2008 IEEE. All rights reserved.
263
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
When a packet ends and the serial bus returns to the Idle state prior to the next subaction, the relevant timings are illustrated by Figure 9-12. Arbitration or Clocked data
TX_DATA_END MIN_IDLE_TIME DATA_END_TIME
Figure 9-12—End of packet transmission A transmitting port shall transmit the data end indication at least DATA_END_TIME after either an unconcatenated packed or the last packet of a concatenated sequence. TX_DATA_END shall be followed by an idle gap of at least MIN_IDLE_TIME. When a subaction requires a response, the responding node shall guarantee the timings shown by Figure 9-13. The upper bound on the idle gap prevents other nodes from erroneously observing a subaction gap. Arbitration or Clocked data
RX_DATA_END RESPONSE_TIME
Figure 9-13—Subaction response The packets that require a response are any primary packet (except broadcast and stream packets), a “ping” packet, or a PHY remote access or remote command packet. The timing requirements are identical for all of these packets; only the data end arbitration line state that follows the packet is shown at the left of Figure 9-13. The arbitration line state that follows idle (shown at the right of the figure) shall be TX_DATA_PREFIX, TX_DISABLE_NOTIFY, or TX_SUSPEND. The responding node shall guarantee that the idle gap does not exceed RESPONSE_TIME at any transmitting port, not solely the port that received the packet that required the response. NOTE—For some subactions the link is responsible for guaranteeing RESPONSE_TIME while the PHY is responsible for others
9.2.7 Gap timing An interpacket gap is the period of time during which the received arbitration line state of the PHY is IDLE, as specified by 9.2.5. There are four types of gaps —
Acknowledge gap. Occurs between an asynchronous primary packet and its corresponding acknowledge packet.
—
Isochronous gap. Precedes an unconcatenated isochronous subaction.
—
Subaction gap. Precedes an unconcatenated asynchronous subaction within the current fairness interval.
—
Arbitration reset gap. Precedes an unconcatenated asynchronous subaction and indicates the start of a new fairness interval.
264
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Acknowledge and isochronous gaps are nominally 4 / BASE_RATE at the PHY that originated the acknowledgment or arbitrated for the isochronous subaction, respectively. They occur as a consequence of the design of the arbitration state machines specified in 16.4. A node may detect an arbitration reset or subaction gap as soon as the externally observable idle time at any port meets the minimum duration specified by Table 9-19. A node shall detect an arbitration reset or subaction gap no later than when the externally observable idle time at any port meets the maximum duration specified.
Table 9-19—Gap detection times Gap type
Minimum
Maximum
Subaction
( 27 + gap_count × 16 ) ------------------------------------------------------ – PHY_DELAY max BASE_RATE max
( 29 + gap_count × 16 ) ------------------------------------------------------ + PHY_DELAY max BASE_RATE min
Arbitration reset
( 51 + gap_count × 32 ) ------------------------------------------------------ – PHY_DELAY max BASE_RATE max
( 53 + gap_count × 32 ) ------------------------------------------------------ + PHY_DELAY max BASE_RATE min
A node that detects an arbitration reset or subaction gap and elects to arbitrate shall wait an additional time, gap_count × 4 ⁄ BASE_RATE ), before commencing arbitration. This delay arb_delay (defined as guarantees that if some node detects an arbitration reset or subaction gap then all nodes, no matter what their relative location in the bus topology, correctly detect the same gap. As a consequence, externally observable gap times at a node that originates arbitration conform to the times specified by Table 9-20.
Table 9-20—Gap times at originating node Gap type
Minimum
Maximum
Subaction
( 27 + gap_count × 20 ) -----------------------------------------------------BASE_RATE max
( 29 + gap_count × 20 ) ------------------------------------------------------ + RESPONSE_TIME max – MIN_IDLE_TIME BASE_RATE min
Arbitration reset
( 51 + gap_count × 36 ) -----------------------------------------------------BASE_RATE max
—
9.2.8 Speed signal sampling and filtering In DS-mode, speed signaling occurs during the self-identify phase of bus initialization and during packet transmission in the normal arbitration phase. In the self-identify phase, connected peer PHYs exchange speed signals to configure their maximum speed capabilities. In the normal arbitration phases, the speed of an acknowledge, PHY, or primary packet is signaled concurrently with the data prefix that precedes the packet. In either case, speed is signaled as common-mode current on TPB and is observed as a commonmode voltage drop (relative to TpBias) on TPA. A speed signal is a single-ended, common-mode signal of small amplitude that is detected on TPA by differential comparator(s). An S100 PHY requires no comparators, an S200 PHY requires one comparator, while an S400 PHY requires different comparators for the S200 and S400 signals. Each comparator has one side tied to an internally generated reference voltage and the other to the common-mode voltage of the twisted pair (referenced at the midpoint of a resistor/divider network between the twisted pair inputs).
Copyright © 2008 IEEE. All rights reserved.
265
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Reliable reception and detection of a speed signal may be hampered by several factors: —
Common-mode noise. Because the speed signal is a common-mode signal, it is more susceptible to noise than the differential arbitration and data signals. Spurious speed signals may be observed because of cross-talk, mismatches in differential signal transition times, or common-mode ground noise.
—
Receive comparator delay mismatch. The two sets of speed signal comparators may have different delays, which may vary with the input signal amplitude. For example, when receiving the leading edge of an S400 speed signal, the S200 comparator typically switches before the S400 comparator.
—
RC effects. The speed signal rise and fall times may be degraded because of the RC filtering effects of the cable and bias network.
For all of these reasons it is desirable to filter the outputs of the speed signal comparators to enhance the reliable detection of a speed signal. A speed signal should be continuously present for at least 20 ns before it is considered valid. One method is to monitor the comparator outputs and consider the speed signal valid only if the outputs remain stable for some number of consecutive samples. This is illustrated by the informative C code in Table 19-10. The sampling frequency is governed by the 50 MHz PHY clock and the code latches the fastest speed signal observed. The C code in Clause 19 is not intended to preclude other implementations. For example, some implementation may require that the outputs remain stable for three consecutive samples. Others might implement different sampling algorithms for S200 and S400. The behavior of any implementation shall conform to the signal and timing requirements of this standard.
9.2.9 Data transmission and reception Data transmission and reception are synchronized to a local clock that shall be accurate within 100 ppm. The nominal data rates are powers of two multiples of 98.304 Mbit/s for the cable environment.
9.2.9.1 Data transmission Data transmission (see Table 19-9 and Table 19-15) entails sending the data bits to the connected PHY along with the appropriately encoded strobe signal using the timing provided by the PHY transmit clock. If the connected port cannot accept data at the requested speed (indicated by the speedOK[i] flag being FALSE), then a null packet is transmitted, i.e., the drivers remain in the “01” data prefix condition. The edge rates and jitter specifications for the transmitted signal are given in 9.2.2. Starting data transmission requires sending a special data prefix signal and a speed code (see Table 19-26). The speedOK[i] flag for each port is TRUE if the connected PHY has the capabilities to receive the data. Except in the case of a null packet, ending a data transmission requires sending extra bits (known as “dribble bits”) that flush the last data bit through the receiving circuit. The number of dribble bits required varies with the transmission speed—one, three, or seven extra bits for S100, S200, and S400, respectively. An extra bit is required to put the two signals TPA and TPB into the correct state; the value of the bit depends upon whether the bus is being held (PH_DATA.request of DATA_PREFIX) or not (PH_DATA.request of DATA_END). The stopTXpacket() procedure is not invoked for null packets. NOTE—This algorithm works to force the ending port state to TX_DATA_PREFIX or TX_DATA_END and relies on two characteristics of packet transmission; there are an even number of bits between the beginning and the end of a packet and a packet starts with tx_strobe at 0 and tx_data at 1. Thus, when stopTXpacket() is called, the port state is either 01 or 10. If the desired port state is 01 (TX_DATA_PREFIX), this algorithm sets port state to 11 for one bit time and then to 01. If the desired ending state is 10 (TX_DATA_END), the port state sequence is 00 followed by 10.
266
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
9.2.9.2 Data reception and repeat DS-mode data reception has three major functions—decoding the DS signal to recover a clock, synchronizing the data to a local clock for use by the link layer, and repeating the synchronized data out all other connected ports (see Table 19-8, Table 19-16 and Table 19-27.) This process can be described as two routines communicating via a small FIFO. Starting data reception requires initializing the data resynchronizer and sampling the speed signal from the sender of the data. In the absence of a speed signal, the PHY interprets the speed as either S100 or else the speed of the immediately preceding concatenated packet. At the same time, the node starts the transmitting ports by sending a special data prefix signal and repeating the received speed code. As in the startTXpacket() function (Table 19-26), the node must do the speed signaling exchange for each transmitting port. The value of all dribble bits, except for the last dribble bit, is unspecified. A PHY shall not depend upon the value of any dribble bit except the last. The last dribble bit shall be zero when the preceding packet is terminated by DATA_END and one when terminated by DATA_PREFIX. NOTE—The description of the FIFO buffer in Table 19-8 and Table 19-9 assumes that the PHY strips dribble bits from incoming packets and regenerates them for repeated packets. Alternate implementations, e.g., one that repeats dribble bits, may be valid so long as no dribble bits are transferred to the link.
9.3 Beta mode specification 9.3.1 Transmitter electrical specifications Transmitters defined by this subclause are used in bilingual or Beta-only ports. Transmitters of bilingual ports shall be electrically compatible with DS-mode signals (see 9.2), supporting all the standard electrical operating modes. Bilingual and Beta-only ports shall not be connected to either Alpha 6-pin or 4-pin sockets. Additionally, bilingual and Beta-only transmitters shall support a new electrical specification for gigabit signaling and are required to support at least S400 Beta-mode signaling. The signal requirements for the transmit interface are listed in Table 9-21.
Table 9-21—Beta mode short-haul copper transmitter characteristics Parameter
S400β
S800β
S1600β
S3200β
Units
Signaling
8B/10B
8B/10B
8B/10B
8B/10B
Nominal data rate
393.22
786.43
1572.9
3145.73
Mb/s
Nominal baud rate
491.52
983.04
1966.1
3932.16
MBd
Tolerance
± 100
± 100
± 100
± 100
ppm
Maximum
800
800
800
800
mV
Minimum
300/475 (Note 4)
600
555
555
mV
20
20
20
20
mV
N/A
N/A
4
4
dB
Differential amplitude (Note 1)
Maximum (OFF) De-emphasized differential output voltage ratio (Note 5) Maximum
Copyright © 2008 IEEE. All rights reserved.
267
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-21—Beta mode short-haul copper transmitter characteristics (continued) Parameter
S400β
S800β
S1600β
S3200β
Units
N/A
N/A
3
1
dB
Maximum (Note 6)
400
350
175
175
ps
Minimum
80
80
80
80
ps
Differential skew (Note 3)
50
35
24
16
ps
10%
10%
20%
20%
actual rise time
Minimum Rise and fall time (10% to 90%)
Common-mode output impedance
< 55
Ω
Maximum common-mode voltage
2.415
V
NOTES 1—Measurements for differential voltages means |V2 – V1|, where V1 and V2 are the single-ended voltages. For S1600, the specification applies to non-deemphasized bits. 2—Transmitter characteristics measured at point TP2. 3—The differential skew may not exceed either the given absolute value or the value relative to the actual rise time. 4—300mV is the minimum requirement, but new designs are recommended to have a minimum differential amplitude of 475 mV at S400β. 5—This is the ratio of the differential amplitude of the second and following bits after a transition divided by the differential amplitude of the first bit after a transition. 6— At S1600 and S3200, the 175 ps maximum for rise and fall times is informative. The eye diagram (Figure 9-16) should be used for S1600 and S3200 compliance testing. 7—Measurements of rise and fall times for S1600 and S3200 are performed with de-emphasis disabled.
Example of differential voltage measurements—Assume that the transmitter transmits a differential signal around a bias voltage of 1.6V. If TPB+ is 2.0V and TPB- is 1.2V, then a logic "1" is being signaled, and the differential amplitude is TPB+ - TPB-, i.e. 0.8V (the maximum differential amplitude). If TPB+ is 1.2V and TPB- is 2.0V, then a logic "0" is being signaled, and the differential amplitude is -0.8V. NOTE—Care should be taken when comparing 1394 specifications to non-1394 standards, some of which specify voltage swings in terms of a pk-pk voltage specification (defined as modulus (Differential Amplitude for '1' Differential Amplitude for '0')) instead of a differential amplitude specification as used in 1394. In such non-1394 standards, the signal swings given in the example above would be defined as having a pk-pk voltage of 1.6V.
De-emphasis shall be implemented for S1600 and S3200 transmissions when multiple bits of the same polarity are output in succession. Subsequent bits shall be driven at a differential voltage level 3.5 dB (±0.5 dB) for S1600 and 2.5 dB (±1.5 dB) for S3200 below the first bit. Individual bits, and the first bit of a sequence in which all bits have the same polarity, are always be driven between the Min and Max values as specified for the Differential Amplitude in Table 9-21. An example waveform illustrating de-emphasis and representing the bit sequence (from left to right) of "1001000011" is shown in Figure 9-14. NOTES (on de-emphasis): 1—The specified amount of de-emphasis for S1600 allows for designs to optimize maximum interoperability while minimizing complexity of managing configurable de-emphasis values. Thus, the primary benefits of de-emphasis are targeted for worst-case loss budgets of 7.5 dB, while being slightly less optimal for lower loss systems. However, this tradeoff is more than offset by the fact that there is inherently more voltage margin in lower loss systems. 2—The specified amount of de-emphasis for S3200 does not provide sufficient correction for the degradation of cables and connectors. Equalization or other methods are required at the receiver to provide correction for reliable operation across variable lengths and qualities of cables. 3—De-emphasis levels for S3200 allow for a silicon implementation that is common with the S1600 levels. The deemphasis specification is measured at TP2, so S3200 will show more variance and less de-emphasis than S1600, even with the same launch amplitude, due to high frequency rolloff of the silicon package and PCB parameters.
268
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
Normalized Amplitude
HIGH-PERFORMANCE SERIAL BUS
1.000 0.668 0.000 -0.668 -1.000
1
0
0
1
0
0
0
0
1
1
Transmit Bit
NOTE—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 9-14—Example of S1600 and S3200 de-emphasis The output driver in 8B/10B signaling shall have output levels, measured at the input to the cable (point TP2), meeting the eye diagram requirements of Figure 9-16 and Figure 9-17 when terminated as shown in Figure 9-15. TP1
T+
TP2
TRANSMIT NETWORK
55 Ohms +- 1%
55 Ohms +- 1% TPHY 1M Ohms
270 pF
NOTE—Reprinted with permission from 1394 Trade Association TB2002001 [B2].
Figure 9-15—Balanced transmitter test circuit
The normalized amplitude limits in Figure 9-16 are set to allow signal overshoot of 10% and undershoot of 20% relative to the amplitudes determined to be a logic 1 and 0. NOTE—For the logic 1 case, a 20% undershoot corresponds to a +0.8 transmitted level. For the logic 0 case, a 20% undershoot corresponds to a +0.2 transmitted level.
Copyright © 2008 IEEE. All rights reserved.
269
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Normalized amplitude
1.1 1.0 0.8 0.5 0.2 0 –0.1 0 X1 X2 1-X2 1-X1 1 Normalized time (% of unit interval)
Figure 9-16—Normalized eye diagram mask at TP2 The absolute transmitter output timing and amplitude requirements are specified in Table 9-21, Table 9-22, and Figure 9-17. The masks of Figure 9-16 and Figure 9-17 shall be interpreted as graphical representations of the voltage and time limits. The time values between X1 and 1-X1 cover all but 10–12 of the jitter population. The random content of the total jitter population has a range of ±7 sigma. Current oscilloscope technology only supports approximately ±3 sigma; therefore the traditional method of using an oscilloscope to compare the signals against these masks to ascertain jitter compliance is invalid. The oscilloscope remains valid for determining rise/fall times, amplitude, and under and overshoots.
Differential amplitude
800 mV +Vmin 0V –Vmin
–800 mV 0 X1 X2 1-X2 1-X1 1 Normalized time (% of unit interval)
Figure 9-17—Absolute eye diagram mask at TP2
When the oscilloscope is used for this purpose edges are unlikely to be captured at the extremes of X1 and 1-X1, and the masks should thus be expanded horizontally, keeping X2-X1 constant, until points X1 and 1-X1 are just not touching the edges of the captured population. This avoids the possibility that signal distortions between X1 and X2 might appear to pass the mask, whereas at the maximum values of jitter they would not.
270
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 9-22—Normalized time intervals for TP2
Speed S400
S800
S1600
S3200
Symbol
Value
Units
Picosecond equivalent at nominal baud rate
X1
0.14
UI
278
X2
0.34
UI
685
X1
0.10
UI
100
X2
0.30
UI
303
X1
0.14
UI
70
X2
0.34
UI
141
X1
0.23
UI
58
X2
0.44
UI
110
NOTES 1—The relationship between Figure 9-16 and Figure 9-17 can best be explained by an example. If a transmitter outputs a nominal 600 mV amplitude logic level 1 with overshoot to 800 mV amplitude, it will pass the absolute mask of Figure 9-17, but will not pass the normalized mask of Figure 9-16. Normalized, this signal would have 33% overshoot, which exceeds the 10% overshoot limit defined by the normalized eye mask. 2—All specifications, unless specifically listed otherwise, are based upon differential measurements. 3—Vmin is speed dependent (see Table 9-21). 4—The transmit differential skew is the maximum allowed time difference (on both low-to-high and high-to-low transitions) as measured at TP2, between the true and complement signals. This time difference is measured at the midway point on the signal swing of the true and complement signals. These measurements are single ended. 5—The transmitter amplitude maximum specification identifies the maximum differential signal that can be delivered into a resistive load matching the load shown in Figure 9-15. 6—The transmitter amplitude minimum specification identifies the minimum allowed differential eye amplitude opening that can be delivered into a resistive load matching the load shown in Figure 9-15. 7—The normalized 1 is the amplitude determined to be the average amplitude when driving a logic 1. The normalized 0 is the amplitude determined to be the average amplitude when driving a logic 0. 8—Eye diagram assumes the presence of only high-frequency jitter components that are not tracked by the clock recovery circuit. For Beta mode signals, the lower cutoff frequencies for jitter are given in Table 9-32 (in 9.3.6). 9—The unit interval is the nominal amount of time 1 bit takes to transmit. 10—The maximum operable distance for a specific connection type is calculated by dividing the loss per meter of the cable plant at a frequency equal to 1/2 times the maximum connection baud rate into the available connection-loss budget. This loss budget is calculated as loss = 20 log 10( ( minOutputAmplitude ) ⁄ ( minInputAmplitude ) ) . 11—Normalized time intervals for S1600 and S3200 are measured with de-emphasis disabled.
Transmitters shall be designed to not be damaged if a case occurs where, through a cabling error, two transmitters are directly connected.
9.3.2 Receiver electrical specifications Receivers defined by this subclause are used in bilingual or Beta-only ports. Receivers on bilingual ports when operating in DS mode shall operate as specified in 9.2, supporting all the standard electrical operating modes. Additionally, bilingual and Beta-only receivers shall support Beta-mode signaling at a data rate of S400 and optionally at higher data rates. For all connections, the receiver shall be dc-coupled for DS signaling and for Beta signaling may be ac-coupled for 8B/10B signaling through a receive network located between TP3 and TP4 as shown in Figure 9-4. The signal requirements for the receiver interface are listed in Table 9-24.
Copyright © 2008 IEEE. All rights reserved.
271
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The receiver shall operate within the bit error ratio (BER) objective (10–12) when a transmitter meeting the requirements defined in Table 9-21, Table 9-22, Figure 9-16, and Figure 9-17 drives a short-haul Beta connection and the signal delivered to TP3, when terminated as shown in Figure 9-18, has the following properties: —
Jitter is no worse than that specified in Table 9-33, Table 9-35 and Table 9-37 (all in 9.3.6), as appropriate.
—
Skew is no worse than that specified in Table 9-24.
—
Rise and fall times (10% to 90%) are no greater than that specified in Table 9-24.
—
Rise and fall times (–200mV/+200mV) are no greater than that specified in Table 9-25 (in 9.3.3.7). TP3
T+ 55 Ohms +- 1%
270 pF 1M Ohms
55 Ohms +- 1% T-
TP3
Figure 9-18—TP3 test load Figure 9-19 shows a mask that would just fit inside the eye produced by a worst case transmitter and cable, and consequently the receiver should provide margin for robust operation. The mask of Figure 9-19 may be interpreted in two ways depending on the values assigned to X1 (see Table 9-23.) When X1 is set to the absolute mask values, the mask becomes a graphical representation of the voltage and time limits. In this case, the time values between X1 and 1-X1 cover all but 10-12 of the jitter population and the random content of the total jitter population has a range of ±7 sigma. Current oscilloscope technology only supports approximately ±3 sigma. When X1 is set to the scope mask values the mask becomes representative of what might be observed on an oscilloscope; under these conditions it is possible, though improbable for some hits to occur inside the mask. Eye diagrams assume the presence of only high-frequency jitter components that are not tracked by the clock recovery circuit. For Beta mode signals, the lower cutoff frequencies for jitter are given in Table 9-32 (in 9.3.6). NOTE—Measurements for differential voltages means (V2 – V1), where V1 and V2 are the single-ended voltages. See 9.3.1 for an example.
272
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Differential Amplitude
800mV
+Vmin
0V
-Vmin
-800mV 0
X1
X2
1-X2 1-X1
1
Normalized Time
Figure 9-19—Eye diagram mask at point TP3
Table 9-23—Eye values for Figure 9-19 Speed S400
S800
S1600
S3200
Symbol
Value
Units
X1
See note 2
UI
X2
X1 + 0.2
UI
X1
See note 2
UI
X2
X1 + 0.2
UI
X1
See note 2
UI
X2
X1 + 0.2
UI
X1
N/A
UI
X2
N/A
UI
Vmin
200
mV
NOTES 1—Eye diagram assumes the presence of only high-frequency jitter components that are not tracked by the clock recovery circuit. For Beta mode signals, the lower cutoff frequencies for jitter are given in Table 9-32 (in 9.3.6). 2—The value of X1 is calculated from the UI values of DJ and RJ RMS for TP3 in the jitter output Table 9-33, Table 9-35, and Table 9-37 (all in 9.3.6) as follows: X1scope_mask = 0.5(DJ) + 3 (RJ RMS) X1absolute_mask = 0.5(DJ) + 7(RJ RMS) 3—There is no eye diagram defined for S3200 as the eye would be totally closed without equalization.
Copyright © 2008 IEEE. All rights reserved.
273
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-24—Short-haul copper receiver characteristics when using Beta mode Parameter
S400β
S800β
S1600β
S3200β
Units
Signaling
8B/10B
8B/10B
8B/10B
8B/10B
N/A
Data rate
393.22
786.43
1572.9
3145.73
Mb/s
Nominal baud rate
491.52
983.04
1966.1
3932.16
MBd
Baud rate tolerance
± 100
± 100
± 100
± 100
ppm
TDR rise time
80
80
80
80
ps
Exception window (max)a
700
700
700
700
ps
Through connectionb
See Figure 4-59
See Figure 4-59
See Figure 4-59
See 4.4.4.2
Ω
PCB traces
See Figure 4-59
See Figure 4-59
110 ±10
110 ±10
Ω
N/A
N/A
110 ±10
110 ±10
Ω
110 ±10
110 ±10
110 ±10
110 ±10
Ω
Differential skew
5%
5%
5%
5%
unit interval
Maximum differential skew tolerance
120
122
104
85
ps
Input impedance test conditions:
Input impedance @ TP3:
Receiver pinsc At
terminationd
Common-mode input impedance
> 550
Ω
Maximum common-mode input voltage
2.915
V
Minimum common-mode input voltage
For future specification
V
Maximum ac common-mode voltage
For future specification
V
AC common-mode frequency range
For future specification
MHz
Fault voltage tolerance Rise/fall time tolerance
–0.9 to +3.315 690
660
400e
V 400e
ps
aWithin
the exception window, no single impedance excursion shall exceed the through-connection impedance tolerance for a period exceeding twice the TDR rise time specification. The exception window begins at the point where the measured impedance first exceeds the impedance tolerance limit for Through Connection. It ends at the point where the measured impedance subsequently remains within the limits for Through Connection impedance. bThrough-connection impedance describes the impedance tolerance through a mated connector. This tolerance is greater than the termination or cable impedance due to limits in the technology of the connectors. cAt the time point corresponding to the connection of the receiver to the transmission line, the input capacitance of the receiver and its connection to the transmission line may cause the measured impedance to fall below the minimum impedances specified in this table. The area of the dip caused by this capacitance is directly proportional to the capacitance. An approximate value for the area is given by the product of the amplitude of the dip (in units of rho) and its widthf (in ps) measured at the half amplitude point. The product calculated by this method shall not be greater than 150 ps. The amplitude is defined as being the difference in rho between the rho at the nominal impedance and the rho at the minimum impedance point dTermination impedance is the value at which the impedance stabilizes. It shall be recorded 4.0 ns following the electrical reference plane determined by the receptacle on the receiver bulkhead. Note that this puts a limit on the length of the board trace.
274
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS e S1600 f
and S3200 rise/fall time tolerance should be measured with de-emphasis enabled. All times indicated for TDR measurements are recorded times. Recorded times are twice the one-way transit times of the TDR signal.
9.3.2.1 S3200 equalization
Gain (dB)
For proper receiver operation, an equalizer or other method is required to correct the incoming bitstream to achieve the BER objective. A fixed equalizer with 16dB of gain at 3.7 GHz (as illustrated in Figure 9-20) has been shown to produce an eye opening of 0.40 UI under worst-case conditions. However, a fixed equalizer setting may degrade the eye under non worst case conditions. An adaptive equalizer is preferred and may be easier to realize in implementation for correct operation in all conditions. It must still be able to provide enough gain to correct for worst-case conditions. 16.0 14.0 12.0 10.0 8.0 6.0 4.0 2.0 0.0 10000.0
1000.0
100.0
Frequency (MHz) NOTE—Reprinted with permission from 1394 Trade Association TB2007010 [B6]
Figure 9-20—Example S3200 fixed equalizer function 9.3.3 Electrical measurements Electrical measurements shall be performed as described in this subclause.
9.3.3.1 Transmit rise and fall time Rise time is a differential measurement across the T+ and T– outputs with a load present (including test equipment) equivalent to the load shown in Figure 9-13. Both rising and falling edges are measured. The 100% and 0% levels are the normalized 1 and 0 levels present when sending an alternating K28.5 character stream (see 13.2.6.1.4.) Once the normalized amplitude is determined, the data pattern is changed to a continuous D21.5 character stream (see Table 13-8.) The rise time specification is the time interval between the normalized 10% and 90% amplitude levels.
9.3.3.2 Transmit skew The transmitter skew is the time difference between the T+ and T– outputs measured at the normalized 50% level with a load present (including test equipment) equivalent to the load shown in Figure 9-15. Both rising and falling edges are measured. The 100% and 0% levels are the normalized 1 and 0 levels of the pattern in use.
Copyright © 2008 IEEE. All rights reserved.
275
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The measurement is taken using two single-ended probes and the data averaged using an averaging scope. Skew in the test setup shall be calibrated out. Measure the delay from T+ rising edge to T– falling edge and from T+ falling edge to T– rising when transmitting continuous D21.5 characters or D28.7 characters. Negative and differing values are possible; the sign of the result shall be preserved. Skew is calculated as follows: Drf = delay from T+ rising edge to T- falling edge Dfr = delay from T+ falling edge to T- rising Min = min(Drf, Dfr) Max =max(Drf, Dfr) Diff = ¦Max - Min¦ Skew = ¦Min + (Diff/2)¦ Examples: 1. Drf = -2, Dfr = 1 Diff = ¦1-(-2)¦ =3 Skew = ¦-2 +1.5¦ = 0.5 2. Drf = 2, Dfr = -1 Diff = ¦2-(-1)¦ =3 Skew = ¦2 +1.5¦ = 0.5
9.3.3.3 Transmit eye (normalized and absolute) This transmit eye test is made as a differential measurement at the bulkhead socket. The scope trigger shall be either a recovered clock or a character clock internal to the equipment. The data pattern for this test is the alternating K28.5, i.e., alternating the two different disparity K28.5 characters. If a character trigger is used, the overshoot and undershoot percentages shall be measured at all 10-bit positions. The load for this test is the load shown in Figure 9-15.
9.3.3.4 Rise and fall time setting for receiver jitter tolerance test Rise time is a differential measurement between T+ and T– at the TP3 point of the idealized load in Figure 9-18. Both rising and falling edges are measured. The test pattern used shall be continuous D24.3 characters; the 100% and 0% levels are the normalized 1 and 0 levels. The rise time specification is the time interval between the normalized 10% and 90% amplitude levels.
9.3.3.5 Skew setting for receiver jitter tolerance test Skew is the time difference between the T+ and T– at the TP3 point of the idealized load in Figure 9-18 measured at the normalized 50% level. The 100% and 0% levels are the normalized 1 and 0 levels of the pattern in use. The measurement is taken using two single-ended probes and the data averaged using an averaging scope. Skew in the test setup shall be calibrated out.
276
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Skew is derived using the method and patterns detailed in 9.3.3.2.
9.3.3.6 Receiver jitter tolerance The receiver shall operate at a BER no worse than 10-12 when tested with a signal that has the worst case rise/fall times and worst case skew specified in Table 9-24, the maximum jitter specified in Table 9-34, Table 9-36, and Table 9-38 (all in 9.3.6) (as appropriate), the maximum ac common mode voltage in Table 9-24 and with its minimum amplitude set using the procedure detailed in 9.3.3.7. Test patterns used shall, as a minimum, consist of the test patterns specified in Annex N. The generating device shall have its parameters set whilst driving into the idealized load given by Figure 9-18; the measurement point is TP3. After setting the parameters the receiver under test shall be connected in place of the load. Rise and fall times are first set using the test patterns and method defined in 9.3.3.4, skew is then set using the test patterns and method of 9.3.3.5. Minimum amplitude is set next. Finally jitter is set using the test pattern to be used for the BER test.
9.3.3.7 Minimum amplitude for receiver jitter tolerance test Minimum amplitude is set by adjusting the amplitude until the rise and fall times measured between the values –Vmin and +Vmin (see Table 9-23) meet but do not exceed the values given in Table 9-25. The 10%to-90% rise and fall times must previously have been set as detailed in 9.3.3.4. The measurement is to be performed when driving into the idealized load given by Figure 9-21 (in 9.3.5.2); the measurement point is TP3. The 8b/10b character sequence of D12.0, D11.4, D12.0 and D11.3 is to be generated continuously. The above sequence results in the following bit sequence being transmitted; transmission order is left to right: 00110101001101001101001101010011010011000011011011110100001000110110111101000011 Set the DJ and Sinusoidal jitter to the maximum values given in Table 9-34, Table 9-36 and Table 9-38 (all in 9.3.6), as appropriate. RJ need not be applied while setting minimum amplitude. Measure the rise and fall times of the lowest amplitude “1” bit and the lowest amplitude “0” bit, these are usually the lone “1” bit in the 00001000 sequence (see the underscored bits in the bit sequence above) and lone “0” bit in the 1111010000 sequence (see the underscored bits in the bit sequence above). At least 1000 results of each measurement shall be obtained. The amplitude of the signal source is adjusted until the largest value of the 4000 results just meets the value specified in Table 9-25.
Table 9-25—Minimum amplitude for receiver jitter tolerance test
Copyright © 2008 IEEE. All rights reserved.
Data rate
Risetime ±Vmin (ps)
S400
814
S800
406
S1600
170
S3200
N/A
277
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
9.3.3.8 S3200 BER The S3200 receiver BER is a measure of the number of incorrect symbol decisions made by the receiver and clock recovery mechanism over a period of time. BER is measured using worst-case transmission conditions and is expressed in terms of number of incorrect bit decisions over the number of bits that were transmitted. The device shall employ a loopback mode that transmits received 10B characters such that the transmitted characters can be compared against the received characters. The test fixture shall initially provide a K28.5 character stream to allow the device to achieve character synchronization. The device will not begin to transmit the received data until it has achieved a reliable character synchronization. To accommodate frequency offset between the test fixture and the device, the test fixture shall transmit exactly four D28.2 characters every 1000 characters. The receiver shall employ a FIFO that initially holds four received characters before sending them to the transmitter. On receiving three D28.2 characters, the device will either insert an additional D28.2 character if its FIFO is depth is less than four characters, or remove the last received D28.2 character if its FIFO depth is four or more characters. Since D28.2 characters have even disparity, the disparity will remain unchanged when these characters are added or removed by the device. The measurement is performed at the connector of the device under test. The test may be done with worstcase cables and a real transmitter (with de-emphasis), or by directly applying a shaped waveform into the connector.
9.3.3.9 S3200 electrical test configuration The S3200 electrical tests are configured using a modified speed toning pattern. The actual speed tone encoding and negotiation sequence remain unchanged, but when the STOP bit (bit 8) is encoded as 1 the device is placed into electrical test mode, and the TS bits (bits 6 & 7) are used to determine the operation of the device transmitter (see 14.8.3.) The encoding of these tone bits is as shown in Table 9-26.
Table 9-26—S3200 electrical test selection TS1
TS2
Mode
De-emphasis
0
0
Transmit alternate K28.5
OFF
0
1
Transmit alternate K28.5
ON
1
0
Transmit D21.5
ON
1
1
BER
ON
When speed negotiation is complete, the test fixture will transmit a continuous tone to the device. In BER mode, the test fixture will switch to a random character stream after it detects that the receiver has achieved character synchronization. After the device enters an electrical test mode, it shall remain in that mode until it detects that it is no longer receiving either a valid 8B/10B stream (in BER mode) or a continuous tone (in other modes).
9.3.4 DC biasing Beta-capable ports can be connected to other devices in several ways, e.g., Alpha ports, bilingual ports, Beta-only ports, and electro-optical networks. Table 9-27 defines the bilingual port signals. For Alpha (DS) signaling, the transmitter on TPA generates TpBias. This is also used to signal to a bilingual port that its connection partner is only Alpha capable. For a
278
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Beta mode port, TpBias is not asserted. For this reason, Beta port is required to generate a bias for its own transmitter to enable signaling, e.g., toning.
Table 9-27—Electrical signal assignments Signal name
Beta-mode signal definition
TPB*
Differential transmit minus
TPB
Differential transmit plus
TPA*
Differential receive minus
TPA
Differential receive plus
DS signal definition Strobe on receive, data on transmit (differential pair)
Strobe on transmit, data on receive (differential pair)
A Beta-only receiver is required to be ac-coupled. A bilingual receiver is required to be dc-coupled to the socket pins. The transmitter on the other end of the connection may be ac- or dc-coupled to its socket pins. When the receiver is ac-coupled, the receiver shall self-bias. When the receiver is dc-coupled, the receiver shall have a high common-mode input impedance (see Table 9-24) and shall self-bias at this common-mode input impedance. The implication of a high common-mode input impedance is that a dc-coupled transmitter will set the receiver’s common-mode input bias voltage.
9.3.5 Toning and signal detect This connectivity management described in Clause 14 requires the intermittent transmission of a tone and a signal detect function. The parameters of the connection tone defined in this subclause are applicable to all physical media defined in this standard.
9.3.5.1 Connection tone The connection tone frequency is specified to allow simple derivation from either BASE_RATE or BASE_RATE * 10/8, which is approximately from 48 Mhz to 64 MHz. Each port has a PHY variable pmd_tone_on, which is used by the connectivity management state machine to control the transmission of the connection tone by the port. To allow for lowest power, a more relaxed initial tone frequency specification permits the tone to be generated during the startup phase of an internal oscillator, e.g., phase locked loop (PLL). See Table 9-28.
Table 9-28—Connection tone Parameter
Conditions
Minimum
Maximum
Units
Initial tone frequency
pmd_tone_on TRUE within last 100 μs
—
BASE_RATE * 10/8 * 0.5
MHz
Connection tone frequency
pmd_tone_on TRUE for more than 100 μs
BASE_RATE * 0.5
BASE_RATE * 10/8 * 0.5
MHz
40
60
%
Duty cycle
The amplitude parameters of the transmitted tone shall match the requirements for data signaling as applicable to the media. In the case of short-haul copper media, the electrical signaling amplitudes shall be as defined in 9.3.
Copyright © 2008 IEEE. All rights reserved.
279
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
9.3.5.2 PMD signal detect function Each port has a PHY variable signal_detect, which is used to indicate to the connectivity management state machine whether a valid input signal is being received. It is continuously monitored by appropriate code in the connectivity management state machine. The signal detect function shall set signal_detect to TRUE when the PMD circuitry receives a valid electrical signal. signal_detect shall be set to FALSE when the received differential amplitude is below 80 mV (the No Signal condition). Under all other conditions, the state of signal_detect is unspecified. These conditions are specified in Table 9-29.
Table 9-29—signal_detect value definition signal_detect
Receive conditions
value
Vinput Receiver < 80 mV differential amplitudea (No Signal)
FALSE
Receiving a tone or 8B/10B-encoded characters at a frequency within the operating range of the portb - AND Minimum differential sensitivity < V input Receiver < Maximum differential inputc (Valid signal)
TRUE
Other conditions Examples: 1) Receiving neither a tone nor a non-8B/10B encoded data stream 2) Other end of the connection undergoing POR transients 3) 80 mV differential amplitude < V input Receiver < Minimum differential sensitivity 4) One of the differential lines is open
Unspecified
aThis
condition implies that the connection is open or the transmitter on the other end of the connection is OFF (see Table 9-21 for the definition of OFF transmitter). See below for discussion on the No Signal budget. bThis condition implies the transmitter on the other end of the connection shall be transmitting 8B/10B-encoded characters from the port or is toning, and is functioning normally. cThis condition implies that the transmitter on the other end of the connection is operating within specifications and the connection is within specifications.
Under all valid operating conditions, no false positive TRUE indications occur. Although unspecified, this implies that adequate margin shall exist between the signal_detect trip point and the inherent noise level of the receiver due to crosstalk, power supply noise, etc. Under all valid operating conditions, an incoming signal at or above the minimum receive threshold (200 mV differential amplitude) shall not indicate FALSE. Although unspecified, this implies that adequate margin shall exist between the signal_detect trip point and the receiver minimum differential sensitivity. The parameters for the response times are defined in Figure 9-21 and specified in Table 9-30.
Table 9-30—signal_detect timing Symbol
Parameter
Minimum
Maximum
Units
t_sd_on
Delay from valid signal to assertion of signal_detect
—
100
μs
t_sd_off
Delay from no signal to negation of signal_detect
—
t_sd_on
μs
280
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Occurrence of valid signal Occurrence of no signal
signal_detect t_sd_off
t_sd_on
Figure 9-21—signal_detect timing parameters 9.3.5.3 Application note The signal detect mechanism needs to be designed so that the value of signal_detect does not rapidly change state with small variations in received power. Suppression of these changes may be accomplished by an implementation-dependent detection circuit that may use one or more of the following mechanisms: a)
Signal-level measurement hysteresis
b)
Signal-level measurement averaging over a sufficient period to remove pattern-dependent amplitude variations
c)
Analysis of the preferred state of the detection circuitry
d)
Other appropriate mechanisms
Examples of a No Signal condition are when the connection is unplugged or the transmitter to which it is attached is turned off. However, small levels of signal may be present under these conditions from various sources. The No Signal level is based on the budget given in Table 9-31.
Table 9-31—No Signal budget Parameter
Value
Units
OFF transmitter
20
mV
NEXT via connector and cable (5% of 800 mV)
40
mV
Noise
15
mV
Margin
5
mV
Total
80
mV
9.3.6 Jitter specifications Components shall be designed to not exceed the limits of output jitter and to tolerate at the least the input jitter specified in this subclause. Numbers in Table 9-33 through Table 9-40 represent high-frequency jitter, i.e., jitter frequency components above the corner frequencies in Table 9-32, and do not include low-frequency jitter or wander. Transmitters
Copyright © 2008 IEEE. All rights reserved.
281
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
and receivers shall meet the normative values highlighted in bold and underscored. All other values are . informative. Jitter shall be measured as defined in Annex N.
Table 9-32—High-frequency jitter corner frequency Speed
Corner frequency
Units
S400β
295
KHz
S800β
590
KHz
S1600β
1.179
MHz
S3200β
2.358
MHz
Table 9-33—S400β short-haul copper jitter output Jitter output
ps DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
203
22.38
313
516
TP1 to TP2
41
0.00
0
41
TP2
244
22.38
313
557
TP2 to TP3
224
0.00
0
224
TP3
468
22.38
313
781
TP3 to TP4
41
0.00
0
41
TP4
509
22.38
313
822
Compliance point
Table 9-34—S400β short-haul copper jitter tolerance Jitter tolerance
ps DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
TP2
244
22.38
313
203
760
TP3
468
22.38
313
203
984
TP4
509
22.38
313
203
1025
Compliance point
aThe frequency of sinusoidal jitter shall be above the corner frequency of the receiver being
tested.
The TP2 to TP3 channel (cable) contribution shall be compliant in a system with the Rx and Tx circuits of 9.3 and 9.3.2. Measurements taken in a resistive system that has been correlated to such a system are acceptable.
282
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 9-35—S800β short-haul copper jitter output Jitter output
ps DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
60
10.00
140
200
TP1 to TP2
0
0.00
0
0
TP2
60
10.00
140
200
TP2 to TP3
105
0.00
0
105
TP3
165
10.00
140
305
0
0.00
0
0
165
10.00
140
305
Compliance point
TP3 to TP4 TP4
Table 9-36—S800β short-haul copper jitter tolerance Jitter tolerance
ps DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
TP2
60
10.00
140
70
270
TP3
165
10.00
140
70
375
TP4
165
10.00
140
70
375
Compliance point
aThe frequency of sinusoidal jitter shall be above the corner frequency of the receiver being
tested.
Table 9-37—S1600β short-haul copper jitter output Jitter output
ps
Unit interval
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
60
4.00
56
116
0.12
0.008
0.11
0.23
TP1 to TP2
25
0.00
0
25
0.05
0.000
0.00
0.05
TP2
85
4.00
56
141
0.17
0.008
0.11
0.28
TP2 to TP3
69
0.00
0
69
0.14
0.000
0.00
0.14
TP3
155
4.00
56
211
0.30
0.008
0.11
0.41
TP3 to TP4
25
0.00
0
25
0.05
0.000
0.00
0.05
TP4
180
4.00
56
236
0.35
0.008
0.11
0.46
Compliance point
Copyright © 2008 IEEE. All rights reserved.
283
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-38—S1600β short-haul copper jitter tolerance Jitter tolerance
ps
Unit interval
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidal pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
TP2
85
4.00
56
102
243
0.17
0.008
0.11
0.2
0.48
TP3
155
4.00
56
102
313
0.30
0.008
0.11
0.2
0.61
TP4
180
4.00
56
102
338
0.35
0.008
0.11
0.2
0.66
Compliance point
a
The frequency of sinusoidal jitter shall be above the corner frequency of the receiver being tested.
Table 9-39—S3200β short-haul copper jitter output Jitter output
ps DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
33
3
42
75
TP1 to TP2
41
0
0
41
TP2
74
3
42
116
TP2 to TP3
149
0
0
149
TP3
223
3
42
268
TP3 to TP4
>65
0
0
>65
Compliance point
TP4
>330
Table 9-40—S3200β short-haul copper jitter tolerance Jitter tolerance
ps DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
TP2
74
3
42
30
146
TP3
219
3
42
30
298
TP4
N/A
N/A
N/A
N/A
N/A
Compliance point
aThe frequency
of sinusoidal jitter shall be above the corner frequency of the receiver
being tested.
284
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
9.3.7 Intrapair skew The intrapair skew budget is given in Table 9-41. Specifications in bold type are normative, the others are informative.
Table 9-41—Intrapair skew Intrapair skew (ps) Compliance point
S400
S800
S1600
S3200
Contribution
Cumulative
Contr
Cumul
Contr
Cumul
Contr
Cumul
TP1
14
14
16
16
8
8
8
8
TP1 to TP2
16
TP2 Tp2 to TP3
30 90
TP3 TP3 to TP4
16 32 90 120
16
TP4
16 24 80 122
16 136
16 24 25a 104
16 138
49a 16
120
65a
aIntrapair
skew from TP2 to TP3 for S3200 is defined by 4.4.4.5 and will change with frequency. The table entry of 25 ps is a nominal low-frequency value that is useful for measurement.
NOTE—The intrapair skew budget from TP1 to TP2 and TP3 to TP4 is based on a contribution of 8 ps each from the logic board and the connector (mated pair).
9.3.8 Termination and isolation This subclause provides information about the proper methods of terminating, isolating, and grounding ports that are connected to the Beta socket. These issues are joined in this subclause as the grounding requirements for a particular system influence the methods of terminating the line.
9.3.8.1 Bilingual port termination and isolation The termination schematics for a bilingual PHY are shown in Figure 9-22. Figure 9-22 reveals a couple of salient points about the connections to bilingual ports. First, because a bilingual port shall work with an Alpha port using DS signaling, a bilingual port shall be dc connected. Also, the PHY ground, signal ground, and VG from the socket should all be tied together. As illustrated in Figure 9-23, the overall shield of the cable may be tied to the chassis either through the isolation scheme shown or directly. The chassis may be either ac-coupled (as shown) or directly coupled to the PHY logic ground. If full isolation of the IEEE 1394 connection is required, then the shield-chassis and chassis-logic isolation should be included as shown, the PHY ground should be isolated from system logic ground, and the PHY and the link should use the capacitively coupled interface. The methods of isolating the PHY ground from the system logic ground are shown in later subclauses.
Copyright © 2008 IEEE. All rights reserved.
285
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
TPBias 0.3uF (typ)
Mandatory isolation on TPA Shield
TPA 55Ω TPA*
55Ω
To speed and arbitration comparators
1MΩ
0.1uF VG
5KΩ
55Ω
1MΩ
55Ω TPB*
0.1uF
Shield optionally may be attached directly to chassis.
1MΩ
TPB
0.1uF
Chassis optionally may be attached directly to logic ground.
270pF
-
To connection and arbitration comparators
NOTE—Resistor and capacitor values are typical.
Figure 9-22—Example of bilingual port termination In all Beta-capable nodes, the shield on the TPA (pin 5) shall be isolated from all local grounds as shown Figure 9-23. This isolation allows future versions of this standard to connect the status contact to the TPB shield ground to sense cable capabilities.
9.3.8.2 Beta-only port termination and isolation The termination and grounding schemes for a Beta-only device are shown in Figure 9-23. As with the bilingual socket, a Beta socket allows the chassis and PHY grounds to be either dc-isolated as shown in Figure 9-23 or directly connected. Also, isolation of the TPA (R) line is required. Figure 9-23 shows the preferred placement of the capacitive isolation devices that are required on the TPA pair for all Beta-only ports. This isolation prevents the bias of the TPA pair from being sensed as a TpBias on an Alpha-capable port.
286
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Mandatory isolation on TPA Shield
TPA*
55Ω
270pF
0.1uF
TPB
TPB* .04µF
1MΩ
110Ω
.04µF
0.1uF
Shield optionally may be attached directly to chassis.
1MΩ
Can be eliminated if decoupling capacitors are in receiver
1MΩ
55Ω
1MΩ
-
TPA
0.1uF
Chassis optionally may be attached directly to logic ground.
optional
55Ω
1MΩ
55Ω
270pF
Alternative termination for TPB
NOTE—Resistor and capacitor values are typical.
Figure 9-23—Beta-only connection to copper cable Multiple alternatives exist for terminating the TPB pair. A single 110 Ω resistor or a center-tapped pair may be used to provide source impedance matching. If full-isolation of the PHY from the cable is required, then the shield-chassis isolation, chassis-logic isolation, and 0.04 µF capacitors should be used as shown in Figure 9-23. The capacitors are sized to give less than 1% distortion of a worst-case run length of 10 S400 bits (i.e., a 20 ns pulse).
9.3.8.3 PIL-FOP termination and isolation The signal termination for interface between a PHY that is integrated into a link (PIL) and a fan-out PHY (FOP) (known as the PIL-FOP interface) is shown in the Figure 9-24. This termination scheme is used in all cases regardless of whether the PIL and the FOP share the same signal and logic ground. The 0.1 µF ground coupling capacitors and 1 MΩ resistor are not required if the ground is common.
Copyright © 2008 IEEE. All rights reserved.
287
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
110Ω
0.001µF
-
TPA
TPB
TPA*
TPB*
110Ω
0.1µF
0.001µF 0.1µF
TPB
TPA
TPB*
TPA*
0.001µF 110Ω
110Ω
0.001µF capacitors (4 places) can be eliminated if PIL and FOP operate on same ground reference or if receivers include decoupling capacitors.
0.001µF
0.1µF
1MΩ
NOTE—Resistor and capacitor values are typical.
Figure 9-24—Termination for PIL-FOP interface
9.4 Cable power and ground 9.4.1 Node power classes A node may be a power source, a power sink, or neither and may assume different roles at different times. The principal method by which a node identifies its power class is the self-ID packet transmitted subsequent to a bus reset (see 16.3.2.1). There may be other facilities, e.g., in a node’s configuration ROM, that identify the power characteristics of a node in more detail than is possible in the self-ID packet; these are beyond the scope of this standard. A serial bus may be unpowered or powered; in the latter case, there may be more than one power source. The possibility of multiple sources requires that cable power sources be manufactured such that current from a node providing higher voltage does not flow into sources of lower output voltage. Cable power sources, whether or not identified as such by their self-ID packets, shall not permit the inflow of power from a higher voltage source. Cable power sources that supply a minimum of 20 V shall identify themselves with POWER_CLASS one, two, or three in their self-ID packet(s) and shall implement, for each of their ports, a diode and current-limiting scheme whose behavior is equivalent to that illustrated by Figure 9-25. Different implementations are possible; the number or location of fuses or other current-limiting devices may vary to meet design needs or agency requirements. Devices that implement three or more ports and identify themselves with POWER_CLASS four in their self-ID packet(s) shall implement, for each of their ports, a current-limiting scheme whose behavior is equivalent to that illustrated by Figure 9-26. The components shown in the shaded block are necessary only in the case that the device is also a cable power source. Different implementations are possible; the number or location of fuses or other current-limiting devices may vary to meet design needs or agency requirements. All cable power sources shall meet the cable attenuation requirements of Clause 4.
288
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
diodes to protect against higher cable voltage
power for cable
fuse or current limit to protect against shorts
socket for port 0 VP VG TPA/B
4
socket for port 1
4
VP VG TPA/B
socket for port n
4
VP VG TPA/B
Figure 9-25—Node power interface for POWER_CLASS one, two, or three fuses or current limiters to protect against shorts
power for cable diode to protect against higher cable voltage
socket for port 0
4
VP VG TPA/B
socket for port 1
4
VP VG TPA/B
socket for port n
4
VP VG TPA/B
Figure 9-26—Node power interface for POWER_CLASS four (three or more ports) In addition, cable power sources shall provide over-voltage and short-circuit protection in compliance with the limited power source requirements in Section 2.5 of IEC 60950. Implementations might utilize impedance protection, such as polymer PTC devices, compliant with Table 2B of IEC 60950 or overcurrent protection, such as a fuses, in compliance with Table 2C of that standard. See Table 9-42. When cable power is available, it is in the nominal range 8–30 V. A PHY that detects cable power at the connector of at least 7.5 V shall set the PS bit (cable power active) in its registers to one. The PS bit shall be cleared to zero when detectable voltage falls below 4.5 V. When the PS bit transitions from one to zero, the PHY shall generate a PH_EVENT.indication of CABLE_POWER_FAIL. A cable powered PHY may not be operational if the voltage falls below 7.5 V. If a cable PHY remains operational at the reduced voltage, it shall report the loss of cable power as specified previously.
Copyright © 2008 IEEE. All rights reserved.
289
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 9-42—Cable power source requirements Condition
Limit
Units
Maximum output current per port
Specified by IEC 60950
Minimum output voltage (POWER_CLASS one, two, or three)
20
V dc
Minimum output voltage (POWER_CLASS four, if power is provided)
8
V dc
Maximum output voltage
30
V dc
Maximum output ripple (1 kHz to 400 MHz)
100
mV (pk-pk)
If a node uses cable power, it shall meet the following requirements: a)
It shall sink no more than 1.5 A of current.
b)
It shall consume no more than 3 W of power after a power reset or after being initially connected to the bus (transition from all ports unconnected to any port connected). The receipt of a PHY link-on packet enables the node to consume additional power up to the limit specified by the node’s self-ID packet(s).
c)
Inrush energy shall not exceed 18 mJ in 3 ms.
d)
The node’s current consumption, expressed as a function of the node’s maximum current requirements, Iload in A(s), shall meet the following requirements: 1)
The pk-pk ripple shall be less than or equal to (Iload / 1.5 A) × 100 mA.
2)
The slew rate (change in load current) shall be less than Iload in any 100 µs period.
The sum of the dc currents on VG and VP, for any node that consumes cable power, should be less than 50 μA. This does not imply a requirement for galvanic isolation but encourages good design (the return of power supply current via VG rather than an alternate path). When power is available from electric mains or from batteries, all nodes with two or more ports shall repeat bus signals on all ports that are both connected and enabled. When power is not available the node shall either —
Power its PHY from cable power, if available, and repeat bus signals on all ports that are both connected and enabled, or
—
In the case where the PHY is off, prevent cable power from flowing from any port to any other port.
Nodes may be part of a module that implements a “soft” power switch. When the module connected to the electric mains is powered off, the preferred method to power the PHY is a trickle source from the electric mains. For battery powered modules that are powered off or for other modules when trickle power is not feasible, the preferred alternative is to power the PHY from the cable. The last alternative, an inactive PHY and a break in the bus power distribution, is not recommended. A node that repeats cable power shall have a maximum resistance between any two connector sockets of 0.5 Ω. The measurement shall be made at the PCB side of the connector socket.
9.4.2 Ground isolation When a node provides power to the bus, it may do so with a power supply that is locally referenced (i.e., tied to local system logic ground) or floating (i.e., isolated from local logic ground). The means of providing power for locally referenced bus power is described in 9.2.1.7. Ways in which floating power is provided to the bus and to a bus referenced PHY or FOP are described in 9.4.2.1 and 9.4.2.2.
290
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
9.4.2.1 Primary power providers A primary power provider is a node that reports its power class as either 1, 2, or 3 in its first self-ID packet. This type of device provides 15 W, 30 W, or 45 W to the bus. This type of power provider is allowed, but not required, to draw power from the bus to power its PHY when local power is not available. Figure 9-27 shows how the PHY or FOP electronics can be powered from either local or bus power, while Figure 9-28 shows how the PHY or FOP power can be slightly simplified if powered only locally.
isolation and rectification
fuse or current limit to protect against shorts 20-30 V dc
socket for port 0 VP VG
system logic ground
PHY/FOP logic ground
6
TPA/B + R
socket for port 1 VP
IN 20-30 V dc input power supply
VG 6
TPA/B + R
OUT
PHY/FOP electronics
socket for port n VP VG 6
TPA/B + R
Figure 9-27—Providing power to a floating PHY or FOP, power class 1, 2, or 3
For a Beta-only node, the power supplied to the bus need not be tied to local PHY or FOP power. The bus power can be “floating” with respect to PHY or FOP if capacitive isolation is used for TPB and if the outer shield is isolated from chassis and logic ground. There is no need for a separate regulator for the PHY or FOP electronics and is a simple way in which a node without a separate PIL or FOP may provide power to the bus while preserving full isolation.
9.4.2.2 Secondary power provider A secondary power provider is allowed to pass power through the node. Where it does not pass power, its attachment to the bus is the same as for a primary power provider. If the node does pass power, then it is required to power its PHY from the bus (as shown in Figure 9-29) or to block power when the local PHY or FOP is not powered.
9.4.3 Protection against late VG A failure mode can occur when a power consumer is hot plugged into a power provider and the cable/connector system is faulty and allows VP and one or more of the TPx connections to be made before VG. This is called a late VG event and can cause VP return current to be routed through TPx, damaging one or both PHYs.
Copyright © 2008 IEEE. All rights reserved.
291
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
isolation and rectification
fuse or current limit to protect against shorts socket for port 0
20-30 V dc
VP VG
system logic ground
6
PHY/FOP logic ground
TPA/B + R
socket for port 1 VP
IN
VG
20-30 V dc input power supply
6
TPA/B + R
OUT socket for port n
PHY/FOP electronics
VP VG 6
TPA/B + R
Figure 9-28—Providing power to a floating PHY or FOP, power class 1, 2, or 3 (alternative)
isolation and rectification
fuse or current limit to protect against shorts 8-30 V dc
socket for port 0 VP VG
system logic ground
PHY/FOP logic ground
6
TPA/B + R
socket for port 1 VP
IN 20-30 V dc input power supply
VG 6
TPA/B + R
OUT
PHY/FOP electronics
socket for port n VP VG 6
TPA/B + R
Figure 9-29—Providing power to a floating PHY or FOP, power class 4
292
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
This can be alleviated if an alternative ground return is provided, for example if the shield on the cable is directly connected to chassis ground on all systems that provide or consume power from the serial bus, and that chassis ground and VG be directly connected on the same systems (possibly with a filter to prevent internal noise from getting onto the shield). However, this technique may not be appropriate on some systems. Other techniques are possible, for example using active power control components.
Copyright © 2008 IEEE. All rights reserved.
293
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
294
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
10. Glass optical fiber (GOF) PMD specification This clause specifies the optical signaling properties for an alternate PHY that uses short wavelength lasers [e.g., vertical cavity surface emitting lasers (VCSELs)] and GOFs for long-haul distances. This standard is for a low-cost fiber optical interconnect. Current specifications cover S400β, S800β, and S1600β optical connections. Figure 10-1 shows the relationship of this clause to the PHY master architecture.
Link B PHY
port controller
request/grant, enable
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables
to other ports
TX/RX symbol
Port
Port
Betamode functions
Connection management
DS-mode functions
Betamode functions
Low-power signaling
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
Connection management
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD Glass optical fiber (GOF)
Glass optical fiber (GOF)
Figure 10-1—PHY master architecture (GOF PMD in context)
Copyright © 2008 IEEE. All rights reserved.
295
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
10.1 PMD block diagram For system conformance, the PMD sublayer is standardized at the following points: —
The optical transmit signal is defined at the output end of a 5 m or less patch cord (i.e., TP2) of a type consistent with the connection type connected to the transmitter receptacle defined in 10.10.
—
The optical receive signal is defined at the output of the cable plant (i.e., TP3) connected to the receiver receptacle also defined in 10.10.
TP1 and TP4 are standardized reference points for use by implementers to certify component conformance. The electrical specifications of the PMD service interface (i.e., TP1 and TP4) are not system compliance points (as they may not be readily testable in a system implementation). See Figure 10-2.
MDI
MDI
TP2
TP1
T+
Optical PMD
T-
TP4
TP3
Transmitter
Optical
R+
PMD
Patch Cord
Receiver
R-
Optical Fiber Media Signal_Detect (Optional) System Bulkheads
Figure 10-2—PMD block diagram
10.2 PMD-to-MDI optical specifications The operating range is defined in Table 10-1. A compliant transceiver is capable of supporting the multimode fiber (MMF) media type listed in Table 10-1 (i.e., 50 μm) according to the specifications defined in this subclause. A transceiver that exceeds the operational range requirement while meeting all other optical specifications is considered compliant.
Table 10-1—Operating range for 50 μm MMF Signaling speed
296
Range
Units
S400β
2 to 100
m
S800β
2 to 100
m
S1600β
2 to 100
m
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
10.3 Transmitter optical specifications The optical transmitter shall meet the specifications defined in Table 10-2 per measurement techniques defined in 10.7. It shall also meet a transmit mask of the eye measurement as defined in 10.7.5.
Table 10-2—Optical transmit characteristics Description Transmitter type
50 μm MMF value
Units
Shortwave laser
Signaling rate
S400β S800β S1600β
Wavelength (λ, range)
830 to 860
nm
Trise/Tfall (maximum; 20%–80%)
0.26
ns
RMS spectral width (maximum)
2
nm
Average launch power (maximum)
a
dBm
Average launch power (minimum)
–10
dBm
Average launch power of OFF transmitter (maximum)b
–35
dBm
7
dB
–117
dB/Hz
9 < CPR
dB
Extinction ratio (minimum) Relative intensity noise (RIN) (maximum) Coupled power ratio
(CPR)c d
aThe
launch power shall be the lesser of the class 1 safety limit or the maximum receive power defined by Table 10-3. bExamples of an OFF transmitter are no power supplied to the PMD, laser shutdown for safety conditions, activation of a “transmit disable,” or other optional module laser shutdown conditions. During all conditions when the optical port is powered, the ac signal (data) into the transmit port will be valid 8B/10Bencoded patterns except for short durations during system POR or diagnostics when the optical port is placed in a loopback mode. c Radial overfilled launches (OFLs), as described in 10.11, while they may meet CPR ranges, should be avoided. dThe CPR provides sufficient mode volume so individual MMF modes do not dominate fiber performance. This reduces the effect of pk-pk differential-mode delay between the launched mode groups and diminishes the pulse-splitting nulls in the frequency response.
10.4 Receiver optical specifications The optical receiver shall meet the specifications defined in Table 10-3 and Table 10-4 per measurement techniques defined in 10.7.
Copyright © 2008 IEEE. All rights reserved.
297
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 10-3—Optical receive characteristics Description Signaling rate
Value
Units
S400β S800β S1600β
Wavelength (range) Average receive power (maximum) Receive sensitivity (minimum) Return loss (minimum)
830 to 860
nm
0
dBm
–16.5
dBm
12
dB
Table 10-4—Optical signal_detect thresholds Receive conditions
signal_detect value
Input_optical_power < –31 dBm (ave)
Negated
Input_optical_power > specified receiver sensitivity - AND Extinction ratio and other modulation parameters comply with specified limits
Asserted
All other conditions
Unspecified
10.5 Worst-case connection optical power budget and penalties The worst-case power budget and connection penalties for a connection are shown in Table 10-5.
Table 10-5—Worst-case connection optical power budget and penaltiesa Signaling rate Parameter
Units S400β
S800β
S1600β
Connection optical power budget
6.5
dB
Operating distance
100
m
1.87
dB
Connection insertion lossb Connection optical power
penaltiesb
Unallocated margin in connection optical power budgetb
0.81
0.92
4.52
dB
3.82
3.71
0.10
dB
aConnection
penalties are used for connection budget calculations. They are not requirements and are not meant to be tested. bA wavelength of 830 nm is used to calculate connection insertion loss, connection power penalties, and unallocated margin.
298
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
10.6 Optical jitter specifications Numbers in Table 10-7 through Table 10-12 represent high-frequency jitter, i.e., jitter frequency components above the corner frequencies in Table 10-6, and do not include low-frequency jitter or wander. Transmitters and receivers shall meet the normative values highlighted in bold and underscored. All other values are informative. Jitter shall be measured as defined in Annex N.
Table 10-6—High-frequency jitter corner frequency Speed
Corner frequency
Units
S400β
295
KHz
S800β
590
KHz
S1600β
1.179
MHz
Table 10-7—S400β MMF jitter output Jitter output
ps
Unit interval
Compliance point
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
203
17.40
244
447
0.10
0.009
0.12
0.22
TP1 to TP2
224
26.79
375
599
0.11
0.013
0.18
0.29
TP2
427
31.94
447
874
0.21
0.016
0.22
0.43
TP2 to TP3
61
8.92
125
186
0.03
0.004
0.06
0.09
TP3
488
33.16
464
952
0.24
0.016
0.23
0.47
TP3 to TP4
346
10.17
142
488
0.17
0.005
0.07
0.24
TP4
834
34.59
484
1318
0.41
0.017
0.24
0.65
Table 10-8—S400β MMF jitter tolerance Jitter tolerance
ps
Unit interval
Complianc e point
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidal pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidal pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
TP2
427
31.94
447
203
975
0.21
0.016
0.220
0.1
0.48
TP3
488
33.16
464
203
1053
0.24
0.016
0.228
0.1
0.52
TP4
834
34.59
484
203
1419
0.41
0.017
0.238
0.1
0.70
Copyright © 2008 IEEE. All rights reserved.
299
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 10-9—S800β MMF jitter output Jitter output
ps
Unit interval
Compliance point
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
102
8.70
122
224
0.10
0.009
0.12
0.22
TP1 to TP2
112
13.40
118
300
0.11
0.013
0.18
0.29
TP2
214
15.97
224
438
0.21
0.016
0.22
0.43
TP2 to TP3
31
4.46
62
93
0.03
0.004
0.06
0.09
TP3
244
16.58
232
476
0.24
0.016
0.23
0.47
TP3 to TP4
173
5.09
71
244
0.17
0.005
0.07
0.24
TP4
417
17.29
242
659
0.41
0.017
0.24
0.65
Table 10-10—S800β MMF jitter tolerance Jitter tolerance
ps
Unit interval
Complianc e point
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
TP2
214
15.97
224
102
489
0.21
0.016
0.220
0.1
0.48
TP3
244
16.58
232
102
527
0.24
0.016
0.228
0.1
0.52
TP4
417
17.29
242
102
710
0.41
0.017
0.238
0.1
0.70
aThe
applied sinusoidal shall be swept at a frequency of 637 KHz.
Table 10-11—S1600β MMF jitter output Jitter output
300
ps
Unit interval
Compliance point
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
66
4.32
61
127
0.13
0.009
0.12
0.25
TP1 to TP2
66
5.09
71
137
0.13
0.010
0.14
0.27
TP2
132
6.68
92
224
0.26
0.013
0.18
0.44
TP2 to TP3
15
1.53
20
36
0.03
0.003
0.04
0.07
TP3
148
6.87
97
244
0.29
0.014
0.19
0.48
TP3 to TP4
56
6.10
86
142
0.11
0.012
0.17
0.28
TP4
203
9.16
127
331
0.40
0.018
0.25
0.65
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 10-12—S1600β MMF jitter tolerance Jitter tolerance
ps
Unit interval
Complianc e point
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
TP2
132
6.68
92
51
249
0.26
0.013
0.180
0.1
0.49
TP3
148
6.87
97
51
270
0.29
0.014
0.190
0.1
0.53
TP4
203
9.16
127
51
356
0.40
0.018
0.250
0.1
0.70
a
The applied sinusoidal shall be swept at a frequency of 1275 KHz.
10.7 Optical measurement requirements All optical measurements shall be made through a short patch cable, between 2 m and 5 m long.
10.7.1 Center wavelength and spectral width measurements The center wavelength and spectral width (RMS) shall be measured using an optical spectrum analyzer per ANSI/TIA/EIA-455-127-91. Spectral width shall be measured under modulated conditions using a valid encoded 8B/10B pattern under full power conditions across nominal operating temperatures.
10.7.2 Optical power measurements Optical power shall be measured using the methods specified in ANSI/TIA/EIA-455-95A-00. This measurement may be made with the node transmitting any valid 8B/10B data stream.
10.7.3 Extinction ratio measurements Extinction ratio shall be measured using the methods specified in ANSI/TIA/EIA-526-14A-98. This measurement may be made with the node transmitting a repeating K28.7 data pattern (see 13.2.6.1.4). The extinction ratio is measured under fully modulated conditions with worst-case reflections. NOTE—K28.7 generates a 50 MHz, 100 MHZ, or 200 MHz square wave, depending on whether connection is operating at S400β, S800, or S1600, respectively.
10.7.4 Relative intensity noise (RIN) RIN shall be measured according to A.5 of ANSI X3.230-1994. According to that subclause, “this procedure describes a component test that may not be appropriate for a system level test depending on the implementation.”
10.7.5 Transmitter optical waveform (transmit eye) The required transmitter pulse shape characteristics are specified in the form of a mask of the transmitter eye diagram as shown in Figure 10-3. The transmit mask is not used for response time and jitter specification. Normalized amplitudes of 0.0 and 1.0 represent the amplitudes of logic 0 and 1, respectively.
Copyright © 2008 IEEE. All rights reserved.
301
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Normalized time (unit interval) 0.22 0.375 0.625 0.78
1.0
130
1.30
100
1.00
80
0.80
50
0.50
20
0.20
0
0.0
Normalized amplitude
Normalized amplitude (%)
0
–0.20
–20 0
100 22 37.5 62.5 78 Normalized time (% of unit interval)
Figure 10-3—Transmitter eye mask definition The eye shall be measured with respect to the mask of the eye using a fourth-order Bessel-Thompson filter with a transfer function given by 105 Hp = -------------------------------------------------------------------------2 3 4 105 + 105y + 45y + 10y + y
where y = 2.114p jω p = -----ωr
ωr = 2 π fr f r = 1.500 GHz
and where the filter response versus frequency range for this fourth-order Bessel-Thompson filter is defined in ITU-T G.957, along with the allowed tolerances for its physical implementation. NOTES 1—This Bessel-Thompson filter is not intended to represent the noise filter used within an optical receiver, but is intended to provide uniform measurement conditions at the transmitter. 2—The fourth-order Bessel-Thompson filter is reactive. To suppress reflections, a 6 dB attenuator may be required at the filter output.
10.7.6 Transmit rise and fall characteristics Optical response time specifications are based on unfiltered waveforms. Some lasers have overshoot and ringing on the optical waveforms that, if unfiltered, compromise the accuracy of the measured 20% to 80% response times. For standardizing the measurement method, measured waveforms shall conform to the mask defined in Figure 10-3. If a filter is needed to conform to the mask, the filter response should be removed using the equation:
302
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
T rise,fall =
2
( T rise,fall_measured ) – ( T rise,fall_filter )
2
where the filter may be different for rise and fall. Any filter should have an impulse response equivalent to a fourth-order Bessel-Thompson filter. The fourth-order Bessel-Thompson filter defined in 10.7.5 may be a convenient filter for this measurement; however, its low bandwidth adversely impacts the accuracy of the Trise,fall measurements.
10.7.7 Receiver sensitivity measurements The receive sensitivity (minimum) is measured using a laser with a particular extinction ratio while sampling at the eye center. The sensitivity penalty due to the laser extinction ratio is removed before reporting receiver sensitivity.
10.7.8 Jitter measurements Jitter shall be measured according to the methods in Annex N.
10.8 CPR measurement CPR is measured in accordance with ANSI/EIA/TIA-526-14A-98. Measured CPR values are time averaged to eliminate variation from speckle fluctuations. The CPR shall be measured for compliance with Table 10-2.
10.9 Optical connection cabling model The optical insertion loss for the connection is given in Table 10-13.
Table 10-13—50 μm MMF connection insertion loss at 850 nm wavelength Signaling rate
Connection insertion loss
Units
S400β
1.85
dB
S800β
1.85
dB
S1600β
1.85
dB
10.9.1 Characteristics of the fiber optic medium The fiber cable plant shall meet the specifications defined in Table 10-14. The fiber optic medium consists of one or more sections of fiber optic cable, with any intermediate connectors required to connect sections together, terminated at each end in the optical connector plug. The fiber optic medium spans from one media dependent interface (MDI) to another MDI.
Copyright © 2008 IEEE. All rights reserved.
303
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 10-14—50 μm MMF characteristics Description
Value
Units
Nominal fiber specification wavelength
850
nm
Fiber cable attenuation (maximum)
3.5
dB/km
Modal bandwidth (minimum, OFL)
500
MHz - km
Zero dispersion wavelength (l0)
1295 ≤ l0 ≤ 1320
nm
Dispersion slope (maximum) (S0)
0.11 for 1300 ≤ l0 ≤ 1320 and 0.001(l0 –1190) for 1295 ≤ l0 ≤ 1300
ps/nm2 - km
10.9.2 Optical fiber and cable The optical medium requirements are satisfied by the fiber specified in IEC 60793-2-10, Category A1a (50/125 μm graded-index MMF).
10.9.3 Multimode connector insertion loss The maximum connection distances for MMF are calculated based on an allocation of 1.5 dB total connection loss. This allocation supports a minimum of three connections with an average insertion loss equal to 0.5 dB (or less) per connection or two connections (as shown in Figure 10-4) with a maximum insertion loss of 0.75 dB. MDI
MDI
PMD
Optical Fiber Cabling (connection) Jumper Cable
Connection
Building Cable
Connection
Jumper Cable
PMD
Figure 10-4—Optical fiber cabling model 10.9.4 Optical connection return loss The return loss for multimode connections shall be greater than 20 dB.
10.10 Optical connection The optical connection (i.e., plug and receptacle) shall be the duplex LC, meeting the following requirements: a)
Performance complies to ANSI/TIA/EIA-568-C.3.
b)
The dimension and interface meet the specifications of the FOCIS 10 addendum of the ANSI/TIA/EIA-604-93.
c)
Polarity shall be maintained.
Sample drawings of a duplex LC connection (plug and receptacle) are provided in Figure 10-5 and Figure 10-6.
304
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure 10-5—Duplex receptacle interface
Figure 10-6—Duplex connection interface The optical transceiver transmits on the B receptacle interface and receives on the A receptacle interface. For a duplex fiber attached to duplex plugs on both ends, the fiber attached to the A plug on one end shall attach to the B plug on the other end. For a fiber with a plug on one end and a receptacle on the other, the fiber attached to the A plug shall be attached to the A receptacle.
10.11 Fiber launch conditions: OFL OFL, as described in IEC 60793-1-41 (ANSI/TIA/EIA-455-54B-98), is the standard launch used to define optical fiber bandwidth. This launch uniformly overfills the fiber both angularly and spatially. It excites both radial and azimuthal modes of the fiber equally and thus provides a reproducible bandwidth that is insensitive to small misalignments of the input fiber. It is also relatively insensitive to microbending and macrobending when they are not sufficient to affect power distribution carried by the fiber. A restricted launch gives a less reproducible bandwidth number and is dependent on an exact definition of the launch.
Copyright © 2008 IEEE. All rights reserved.
305
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
306
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
11. PMD specification of fiber media with PN connector Figure 11-1 shows the relationship of this clause to the PHY master architecture.
Link B PHY
port controller
request/grant, enable
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
to other ports
Port
Port Betamode functions
Connection management
DS-mode functions
Betamode functions
Connection management
Low-power signaling
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
Plastic optical fiber (POF) or Hard polymer clad fiber (HPCF)
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
Plastic optical fiber (POF) or Hard polymer clad fiber (HPCF)
Figure 11-1—PHY master architecture
11.1 Scope This clause specifies the PMD properties of plastic optical fiber (POF) and hard polymer clad fiber (HPCF) connections with 650 nm light emitting diode (LED) for the data rate of S100β and S200β. This PMD provides a very low-cost digital baseband P2P interconnection between IEEE 1394 Beta devices for distances of up to 50 m for POF and 100 m for HPCF.
Copyright © 2008 IEEE. All rights reserved.
307
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The PMD specified in this clause has the following general characteristics: —
Provides a means of converting the IEEE 1394 Beta PHY to the POF and HPCF connection segment.
—
Provides a means of transmitting and receiving the optical signal between two optical interfaces.
—
Provides S100β and S200β dual mode capability for interconnecting S200β interface to S100β interface over common optical cable and connectors during a startup mode.
11.2 PMD block diagram For system conformance, the PMD sublayer is standardized at the following points: —
The optical transmit signal is defined at the output end of a 5 m or less patch cord (i.e., TP2) of a type consistent with the connection type connected to the transmitter receptacle defined in 11.4.
—
The optical receive signal is defined at the output of the cable plant (i.e., TP3) connected to the receiver receptacle also defined in 11.4.
TP1 and TP4 are standardized reference points for use by implementers to certify component conformance. The electrical specifications of the PMD service interface (i.e., TP1 and TP4) are not system compliance points (as they may not be readily testable in a system implementation). See Figure 11-2. MDI
MDI
TP2
TP1
T+
Optical PMD
T-
TP4
TP3
Transmitter
Optical
R+
PMD
Patch Cord
Receiver
R-
Optical Fiber Media Signal_Detect (Optional) System Bulkheads
Figure 11-2—PMD block diagram
11.3 Cables The POF shall be 1000 μm step index multimode POF. The HPCF shall be 225 μm graded index multimode HPCF. POF shall have a minimum modal bandwidth of 10 MHz*km at 650 nm when measured in accordance with IEC 60793-1-41 (either method A or B.). HPCF shall have a minimum modal bandwidth of 25MHz*km at 650 nm when measured in accordance with IEC 60793-1-41 (either method A or B.) The specifications for fiber modal bandwidth include a variation in source numerical aperture and account for the effect of bandwidth degradation to ensure correct system operation. The maximum attenuation of 50 m POF under the condition of –20 °C to +70 °C and 95% relative humidity shall be 9.1 dB. The maximum attenuation of 100 m HPCF under the condition of –20 °C to +70 °C and 95% relative humidity shall be 2.6 dB. The attenuation shall be measured in accordance with IEC 60793-1-41 (either method A or B) using a nominal 650 nm narrow [< 5 nm full width at half maximum (FWHM)] spectral width light source.
308
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
In addition, the fiber loss due to environmental conditions and launch numerical aperture is included in the attenuation of 9.1 dB for POF and 2.6 dB for HPCF. The loss increments of 3.4 dB for POF and 0.1 dB for HPCF, shown in Table 11-1, account for both a source center wavelength shift to 660 nm or 640 nm and the difference between the < 5 nm spectral width of the test source and 40 nm worst-case source spectral width. Loss increments of 0.5 dB for POF and 0.1 dB for HPCF due to cable bends are also accounted for as shown in Table 11-1. For the condition shown in Table 11-1, the worst-case fiber attenuation for 50 m POF shall be 13 dB and the worst-case fiber attenuation for 100 m HPCF shall be 2.8 dB.
Table 11-1—Worst-case loss increments for 50m POF cable and 100m HPCF cable Parameters
Units
Minimum
Maximum
Source center wavelength
nm
640
660
Source spectral width (FWHM)
nm
Cable bend radius
mm
40 25.4
Loss increment POF: 3.4dB HPCF: 0.1dB POF: 0.5dB HPCF: 0.1dB
11.4 Connector The optical connector for POF and HPCF connections shall be the PN. The PN receptacle and the PN plug shall meet the interface standard, IEC 61754-16 and the performance standard, IEC 61753-1. The network polarity (transmit and receive) shall be managed in accordance with ANSI/TIA/EIA-568-C.3. The parent connector for type PN connector family is a duplex plug connector that is characterized by a 10.16 mm pitch, and 2.5 mm nominal ferrule diameter. Sample drawings of a PN connection (i.e., plug and receptacle) are provided in Figure 11-3 and Figure 11-4.
Figure 11-3—Plug connector interface
Figure 11-4—Receptacle connector interface
Copyright © 2008 IEEE. All rights reserved.
309
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
11.5 Connector and cable assembly performance criteria The worst-case connector insertion loss, including the effect of environmental conditions, shall be less than 2.0 dB for POF and 1.3 dB for HPCF.
11.6 Optical fiber interface This subclause specifies the optical parameters for the transceiver and media. The optical line coding shall be binary NRZ. Binary 1 shall be represented as a high light level condition. An interface receiver shall operate with a BER not to exceed 10–12 (1-bit error in 1012 bits) when presented with a transmitter signal as specified in Table 11-2 and Table 11-3 transmitted through a connection subject to the system budget constraints specified in this subclause. Proper system performance is ensured by considering the attenuation and modal bandwidth of the optical path and including them as part of the connection budget. In addition to these cable plant characteristics, a system power penalty is normally included in the connection budget. The power penalty includes the effects of eye closure due to transmitter characteristics (e.g., finite rise and fall times, random and deterministic jitter). This system power penalty is accounted for in the receiver sensitivity specification; therefore, the system budget is composed entirely of losses due to the cable plant and connectors. The attenuation range specification for the connections were defined based on the use of components meeting the requirements specified in 11.3 and operating up to 50 m for POF and up to 100 m for HPCF. The static attenuation in the optical path includes worst-case loss values for the fiber media and connectors. The attenuation range for POF connection is 13 dB, of which 13 dB is allocated for 50 m fiber. The attenuation range for HPCF connection is 4.0 dB, of which 2.8 dB is allocated for 100 m fiber. Both of attenuation range is independent of baud. The allowable connection number and transmission length have a trade-off as summarized in Table 11-9. The values prescribed in Table 11-2 are for worst-case operating conditions and end of life; they are to be met over the full range of standard operating conditions (i.e., voltage, temperature, and humidity) and include aging effects. The parameters listed in Table 11-2 are specified for the transmitter and receiver.
11.7 Optical jitter specifications Numbers in Table 11-5 through Table 11-8 represent high-frequency jitter, i.e., jitter frequency components above the corner frequencies in Table 11-4, and do not include low-frequency jitter or wander. Transmitters and receivers shall meet the normative values highlighted in bold and underscored. All other values are informative. Jitter shall be measured as defined in Annex N.
11.8 Permitted number of segments The maximum transmission distance depends on the number of fiber-to-fiber connections within the cable plant (i.e., excluding the connection at each end of the cable plant). Table 11-9 summarizes the trade-off between same types of media based on worst-case component attenuation as specified in 11.3, 11.5, and 11.6. Table 11-10 provides worst-case optical parameters of the transceiver and media when different types of media are interconnected (e.g., POF to HPCF or HPCF to POF). Maximum transmission distance of the case may be introduced based on the optical parameters in combination with connector insertion loss from POF to HPCF and HPCF to POF, respectively.
310
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 11-2—Optical parameters for POF-HPCF interface at S100β and S200β POF
HPCF
Parameters
Units S100β
S200β
S100β
S200β
640 to 660
640 to 660
640 to 660
640 to 660
nm
40
40
40
40
nm
Mean launched powera
–8 to –2
–8 to –2
–20 to –14
–20 to –14
dBm
Source numerical aperture
0.2 to 0.3
0.2 to 0.3
0.2 to 0.3
0.2 to 0.3
Minimum extinction ratio
10
10
10
10
dB
Maximum rise (fall) time, (10% to 90%)
4.5
3.0
4.5
3.0
ns
Maximum overshoot
25
25
25
25
%
Minimum receiver input powerb
–21
–21
–24
–24
dBm
Maximum overload
–2
–2
–14
–14
dBm
Maximum rise (fall) time, (10% to 90%)
5.0
3.5
5.0
3.5
ns
Transmitter interface characteristics Center wavelength (FWHM) Maximum spectral width (FWHM)
Receiver interface characteristics
aThe
interface point for the mean launched power specification is a short length of fiber (e.g., 50 cm) located immediately after the plug of the connector attached to the transmitter receptacle. The connector at this interface point is, therefore, considered to be part of the equipment and not part of the cable plant. bThe interface point for the minimum receiver input power specification is located between the plug of the connector and the receptacle.
Table 11-3—Optical signal_detect thresholds Receive conditions
signal_detect value
Input_optical_power < –38 dBm (average)
Negated
Input_optical_power > specified receiver sensitivity - AND Extinction ratio and other modulation parameters comply with specified limits
Asserted
All other conditions
Unspecified
Table 11-4—High-frequency jitter corner frequency Speed
Corner frequency
Units
S100β
74
KHz
S200β
147
KHz
Copyright © 2008 IEEE. All rights reserved.
311
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 11-5—S100β POF and HPCF jitter output Jitter output
ps
Compliance point
DJ pk-pk
TP1
814
TP1 to TP2
RJ RMS
Unit interval RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
86.27
1208
2022
0.10
0.011
0.15
0.25
895
86.37
1209
2104
0.11
0.011
0.15
0.26
TP2
1709
122.08
1709
3418
0.21
0.015
0.21
0.42
TP2 to TP3
163
24.54
344
507
0.02
0.003
0.04
0.06
TP3
1872
124.52
1743
3615
0.23
0.015
0.21
0.44
TP3 to TP4
1465
56.97
798
2263
0.18
0.007
0.10
0.28
TP4
3337
137.54
1926
5263
0.41
0.017
0.24
0.65
Table 11-6—S100β POF and HPCF jitter tolerance Jitter tolerance
ps
Complianc e point
DJ pk-pk
TP1
N/A
TP2
RJ RMS
Unit interval
RJ pk-pk
Sinusoidal pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidal pk-pk
TJ pk-pk
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
1709
122.08
1709
814
4232
0.21
0.015
0.210
0.1
0.52
TP3
1872
124.52
1743
814
4429
0.23
0.015
0.214
0.1
0.54
TP4
3337
137.54
1926
814
6077
0.41
0.017
0.237
0.1
0.75
Table 11-7—S200β POF and HPCF jitter output Jitter output
312
ps
Unit interval
Compliance point
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
TJ pk-pk
TP1
407
43.13
604
1011
0.10
0.011
0.15
0.25
TP1 to TP2
448
43.19
605
1053
0.11
0.011
0.15
0.26
TP2
855
61.04
855
1710
0.21
0.015
0.21
0.42
TP2 to TP3
81
12.27
172
253
0.02
0.003
0.04
0.06
TP3
936
62.26
872
1808
0.23
0.015
0.21
0.44
TP3 to TP4
732
28.48
399
1131
0.18
0.007
0.10
0.28
TP4
1668
68.77
963
2631
0.41
0.017
0.24
0.65
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 11-8—S200β POF and HPCF jitter tolerance Jitter tolerance
ps
Unit interval
Complianc e point
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
DJ pk-pk
RJ RMS
RJ pk-pk
Sinusoidala pk-pk
TJ pk-pk
TP1
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
TP2
855
61.04
855
407
2117
0.21
0.015
0.210
0.1
0.52
TP3
936
62.26
872
407
2215
0.23
0.015
0.214
0.1
0.54
TP4
1668
68.77
963
407
3038
0.41
0.017
0.237
0.1
0.75
Table 11-9—Trade-off for the number of connections and transmission length No. of connections
Total POF connection length
Total HPCF connection length
Units
0
50
100
m
1
42
96
m
2
34
50
m
3
26
4
m
Table 11-10—Optical parameters in case of POF and HPCF connection POF to HPCF
HPCF to POF
Parameters
Units S100β
S200β
S100β
S200β
640 to 660
640 to 660
640 to 660
640 to 660
nm
40
40
40
40
nm
Mean launched power
–8 to –2
–8 to –2
–20 to –14
–20 to –14
dBm
Source numerical aperture
0.2 to 0.3
0.2 to 0.3
0.2 to 0.3
0.2 to 0.3
Minimum extinction ratio
10
10
10
10
dB
Maximum rise (fall) time, (10% to 90%)
4.5
3.0
4.5
3.0
ns
Maximum overshoot
25
25
25
25
%
Minimum receiver input power
–24
–24
–21
–21
dBm
Maximum overload
–14
–14
–2
–2
dBm
Maximum rise (fall) time, (10% to 90%)
5.0
3.5
5.0
3.5
ns
Transmitter interface characteristics Center wavelength (FWHM) Maximum spectral width (FWHM)
Receiver interface characteristics
Copyright © 2008 IEEE. All rights reserved.
313
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
314
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
12. Unshielded twisted pair (UTP) PMD specification The alternative long-distance PHY specified by this clause enables Beta-mode signaling over UTP cable at the S100, S200, and S400 data rates. NOTE—S800 operation over UTP cabling is supported by T-mode ports as specified in Clause 20 and Clause 21.
Figure 12-1 shows the relationship of this clause to the PHY master architecture.
Link B PHY
port controller
request/grant, enable
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
to other ports
Port
Betamode functions
Connection management
DS-mode functions
Betamode functions
Low-power signaling
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
Connection management
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD UTP
UTP
Figure 12-1—PHY master architecture (UTP PMD in context)
Copyright © 2008 IEEE. All rights reserved.
315
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
12.1 Overview This clause specifies the PMD sublayer for UTP connections for data rates of S100, S200, and S400. The PMD provides all of the services required to transport a suitably coded digital bit stream across the connection segment. The PMD sublayer specified in this clause has the following general characteristics: —
Provides full-duplex line transmission of Beta-mode packets at S100, S200, and S400.
—
Supports operation over up to 100 m of UTP cabling.
—
Operates with a BER of less than or equal to 10–12.
12.2 PMD block diagram For system conformance, the PMD sublayer is standardized at the following points: —
The UTP PMD transmitter characteristics are specified at the media connector (i.e., TP2) as shown in Figure 12-2.
—
The received signal characteristics are specified at the output of the cable plant (i.e., TP3).
—
The specifications assume that all measurements are made after a mated connector pair, relative to the source or destination.
TP1 and TP4 are reference points for use by implementors to specify vendor components. TP1 and TP4 are used as reference points only in informative subclauses, as they may not be readily testable in a system implementation.
TP2
TP1
T+ T-
Transmit Network
TP3
media
TP4
Receive Network
media media connector connector
R+ R-
system bulkheads Figure 12-2—UTP PMD interfaces
12.3 Operation of UTP connections The UTP connections described in this standard employ full-duplex baseband transmission over two pairs of Category 5e (CAT-5e) or better UTP cabling. The signals are NRZ binary symbols sent at a nominal rate of S100, S200, or S400 according to the symbol encodings defined in Clause 13.
316
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
12.4 Media specification The UTP connection may consist of cable, end connections, and intermediate connection devices, such as patch panels and wall plates.
12.4.1 100 Ohm UTP connection segment specification For Category 6 (CAT-6) cabling, the connection and all its components shall meet or exceed the ISO/IEC 11801:2002 specifications for Class E balanced twisted pair cabling (which is equivalent to CAT-6 cabling as specified in ANSI/TIA/EIA-568-B.2-1). For CAT-5e cabling, the connection and all its components shall meet or exceed the ISO/IEC 11801:2002 specifications for Class D balanced twisted pair cabling (which is equivalent to CAT-5e cabling as specified in ANSI/TIA/EIA-568-B.2). Compliance with these specifications shall be verified using the procedures detailed in ANSI/TIA/EIA-568B.2-1 (for CAT-6) and ANSI/TIA/EIA-568-B.2 (for CAT-5e). The maximum transmission distance is a function of both the data rate and type of cable. The UTP PMD shall meet or exceed the maximum transmission distances specified in Table 12-1. Screened or shielded cabling meeting the CAT-6 or CAT-5e specifications may also be used. Note that these maximum distances may include up to 10 m of flexible cord and up to 4 mated connectors. .
Table 12-1—UTP transmission distances Maximum distance (m) Data Rate CAT-6 UTP
CAT-5e UTP
S100
100
100
S200
100
75
S400
75
50
CAT-6 cabling is recommended for S400 operation because S400 signals contain frequency components above the maximum frequency specified for CAT-5e cabling.
12.4.2 100 Ohm UTP cable specification The transmission medium for a UTP PMD connection shall be two-pair or four-pair 100 Ω balanced UTP meeting all the requirements for 100 Ω balanced CAT-6 cable specified by ISO/IEC 11801:2002. CAT-5e cable may also be used with reduced distances as specified in Table 12-1. NOTE—Four-pair cable is recommended so that dc power distribution can be supported.
12.4.3 Connecting hardware All connecting hardware used within a UTP PMD connection (including outlets, transition connections, patch panels, and cross connect fields) shall meet or exceed the requirements specified by ISO/IEC 11801:2002 for CAT-6 connecting hardware. CAT-5e connecting hardware may also be used with reduced distances as specified in Table 12-1.
Copyright © 2008 IEEE. All rights reserved.
317
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The procedures described in A.2 of ISO/IEC 11801:2002 shall be used to make all measurements verifying the compliance of connection hardware. The connector termination practices and UTP cable practices described in Section 10 of ANSI/TIA/EIA-568-B.1 shall be followed.
12.4.4 Media interface connector An 8-pin receptacle (jack), meeting the requirements of IEC 60603-7, shall be used as the mechanical interface between the PMD and the UTP connection segment. Figure 12-3 and Table 12-2 describe the pin assignment that shall be used for this connector. The connection segment shall be terminated at each end with an 8-pin plug, meeting the requirements of IEC 60603-7. A crossover, when provided, shall connect pin 1 and pin 2 of the media interface connection segment to pin 3 and pin 6, respectively, at the other end of the connection segment, and vice versa. When no crossover is provided, pin 1, pin 2, pin 3, and pin 6 of the media interface connection segment shall be connected to pin 1, pin 2, pin 3, and pin 6, respectively, at the other end of the connection segment.
1 2 3 4 5 6 7 8
Figure 12-3—Media interface connector socket Table 12-2—Standard media interface connector pin assignments Pin
Circuit
1
Twisted Pair B (TPB)
2
TPB*
3
Twisted Pair A (TPA)
4
See note
5
See note
6
TPA*
7
See note
8
See note
NOTE—Pins 4, 5, 7, and 8 are reserved for transmission of dc power per Clause 30 of IEEE Std 802.3-2005.
When the autocrossover function is not implemented (see 12.4.5), the modular jacks may be configured as in Table 12-2 and connected with cross-over cabling. Alternatively, some of the modular jacks may be configured with the alternate pinout of Table 12-3 that reverses the TPA and TPB pairs so that they may be connected with straight-through cabling to a jack using the standard pinouts of Table 12-2. Modular jacks that use the alternate pinout of Table 12-3 shall be clearly labeled.
318
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 12-3—Alternate media interface connector pin assignments Pin
Circuit
1
TPA
2
TPA*
3
TPB
4
See note
5
See note
6
TPB*
7
See note
8
See note
NOTE—Pins 4, 5, 7, and 8 are reserved for transmission of dc power per Clause 30 of IEEE Std 802.3-2005.
12.4.5 Autocrossover On power reset, the UTP PMD shall transmit on TPB and TPB* and shall receive on TPA and TPA* with media interface connector pins as specified in either Table 12-2 or Table 12-3. It is strongly recommended that the UTP PMD should support an autocrossover function, controlled by PMD_CONTROL_request. After receiving a PMD_CONTROL.request(PMD_NO_CROSSOVER) from the connection management function, UTP PMDs that support autocrossover functionality shall transmit on TPB and TPB* and shall receive on TPA and TPA*. After receiving a PMD_CONTROL.request(PMD_CROSSOVER) from the connection management function, UTP PMDs that support autocrossover functionality shall transmit on TPA and TPA* and shall receive on TPB and TPB*. PMDs that support autocrossover functionality shall report PH_AUTOCROSSOVER_SUPPORTED in response to a PMD_STATUS.request from the connection management function.
12.5 PMD electrical specifications 12.5.1 Galvanic isolation A coupling transformer is normally used within a UTP PMD to electrically isolate the PHY and the UTP cable plant. The UTP PMD shall provide electrical isolation according to at least one of the following electrical strength tests: a)
1500 V rms at 50 Hz to 60 Hz for 60 s, applied as specified in Section 5.3.2 of IEC 60950.
b)
2250 V dc for 60 s, applied as specified in Section 5.3.2 of IEC 60950.
c)
A sequence of ten 2400 V impulses of alternating polarity, applied at intervals of not less than 1 s. The shape of the impulses shall be 1.2/50 ms (1.2 ms virtual front time, 50 ms virtual time or half value) as defined in IEC 60060-2.
Copyright © 2008 IEEE. All rights reserved.
319
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
No insulation breakdown, as defined in Section 5.3.2 of IEC 60950, shall occur during the test. The resistance after the test shall be at least 2 MΩ, measured at 500 V dc.
12.5.2 Transmitter specifications The signal measured at the output of the UTP PMD media interface connector shall meet the requirements of Table 12-4.
Table 12-4—UTP transmitter electrical specifications Requirement Parameter
Units S100
S200
S400
Maximum
1050
1600
1600
mV
Minimum
950
950
950
mV
Maximum
525
800
800
mV
Minimum
475
475
475
mV
Maximum (OFF)
45
20
20
mV
Maximum
4.4
2.2
1.2
ns
Minimum
3.0
0.08
0.08
ns
Differential skew
200
50
50
ps
2
1
0.5
ns pk-pk
0.1–30 MHz
> 45
> 45
> 45
dB
30–60 MHz
> 40
> 40
> 40
dB
60–100 MHz
> 35
> 35
> 35
dB
100-250 MHz
N/A
>30
>30
dB
> 20
>6
>6
dB
Amplitude (pk-pk)
Amplitude (differential)
Rise/fall time (Note 2)
Jitter Output balance (Note 3)
Return loss NOTES
1—While this standard is intended to enable compliance with regulations concerning radio frequency (RF) emissions, it is not intended to ensure compliance with these regulations. The implementor should consider any applicable local, national, or international regulations. 2—Rise/fall time is 10% to 90% for S100 and 20% to 80% for S200 and S400. 3—Output balance is defined as the ratio of differential voltage to common-mode voltage at the output of the transmitter. 4—The S100 specifications are based on the TPPMD specification (ANSI X3.263-1995), while the S200 and S400 specifications are based on Clause 9 of this standard. This provides compatibility between most S200 and S400 short haul transmitters and the UTP PMD.
320
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
In addition, to meeting the requirements of Table 12-4, the transmit signal shall meet the applicable signal mask shown below. At S100, the signal shall satisfy the requirements of the signal mask shown in Figure 12-4 and calibrated in Table 12-5 while the PMD is transmitting a continuously repeating D0.0 character. This character contains a sequence of three consecutive one symbols. This sequence of 3 ones shall be compared with the signal mask shown in Figure 12-4.
Y5
Y4 Y3 Y2
Y1
X1 X2
X3
X4
X5
X6
X7
X8
Figure 12-4—S100 signal mask for transmitted signal Table 12-5—Coordinates for S100 signal mask X label
X value (ns)
Y label
Y value (V)
X1
0.00
Y1
–0.26
X2
1.75
Y2
–0.23
X3
3.50
Y3
–0.02
X4
6.00
Y4
0.02
X5
21.50
Y5
0.26
X6
24.00
—
—
X7
25.75
—
—
X8
27.50
—
—
NOTE—A sequence of repeating D0.0 characters is generated when the port has its transmit scrambler disabled and is generating a REQ(training) signal.
For S200 and S400, the transmit signal shall meet the normalized and absolute eye diagram masks shown in Figure 12-5 and Figure 12-6 for the normalized time intervals defined in Table 12-6.
Copyright © 2008 IEEE. All rights reserved.
321
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Normalized amplitude
1.1 1.0 0.8 0.5 0.2 0 –0.1 0 X1 X2 1-X2 1-X1 1 Normalized time (% of unit interval)
Figure 12-5—S200/S400 normalized eye diagram mask at TP2
Differential amplitude
800 mV +Vmin 0V –Vmin
–800 mV 0 X1 X2 1-X2 1-X1 1 Normalized time (% of unit interval)
Figure 12-6—S200/S400 absolute eye diagram mask at TP2
Table 12-6—S200/S400 normalized time intervals for TP2
322
Symbol
Value
Units
X1
0.14
Unit intervals
X2
0.44
Unit intervals
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
12.5.3 Receiver specifications 12.5.3.1 Receiver input signals A UTP PMD receiver shall be capable of recovering data with a BER of better than or equal to 1 in 1012 when receiving signals from the output of a minimally-compliant Class D or E connection segment as specified by ISO/IEC 11801:2002 scaled by the maximum length specified in Table 12-1. The receiver shall also be capable of recovering data with a BER of better than or equal to 1 in 1012 when receiving signals from the output of a connection segment comprising any length of UTP cable up to the maximum specified by Table 12-1 and any number of connections up to a maximum of four. In addition, the receiver shall comply with the requirements of Table 12-7.
Table 12-7—UTP receiver electrical specifications Parameter
Requirement
Units
Minimum sensitivity (pk-pk)
100
mV
Minimum sensitivity (differential amplitude)
50
mV
100 ± 15
Ω
2 <= f < 30 MHz
> 16
dB
30 <= f < 60 MHz
> 16 – 20*log(f/30),
dB
60 <= f < 100 MHz
> 10
dB
>6
dB
Input impedance Return loss:
100 <= f < 250 (S200 and S400 only)
NOTE—The receiver electrical specifications are to be measured at TP3, as shown in Figure 12-2.
12.5.3.2 PMD signal detect function All ports with a UTP PMD shall provide a signal_detect variable that indicates whether a valid input signal is being received. It is continuously monitored by appropriate code in the connectivity management state machine. The signal detect function continuously measures the time-averaged pk-pk- received signal. The signal detect function shall set signal_detect to TRUE when the PMD circuitry receives a valid electrical signal above the value SD_assert_threshold for sufficient time. signal_detect shall be set to FALSE when the received differential amplitude is below SD_deassertion_threshold (i.e., the NO Signal condition) for sufficient time. This mechanism is hysteretic. Under all other conditions, the state of signal_detect is unspecified. These conditions are specified in Table 12-8. Receivers that exceed the minimum sensitivity requirements of Table 12-7 may adjust the threshold voltages of Table 12-8 accordingly. Under all valid operating conditions, no false positive TRUE indications occur implying that adequate margin exists between the signal_detect trip point of the receiver and the inherent noise level of the receiver (noise caused by crosstalk, power supply noise, etc.) Under all valid operating conditions, an incoming signal at or above the minimum receive, differential threshold of 50 mV shall not indicate FALSE implying that adequate margin exists between the signal_detect trip point of the receiver and the minimum differential sensitivity of the receiver.
Copyright © 2008 IEEE. All rights reserved.
323
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 12-8—signal_detect value definition Receive conditions
signal_detect set to
V input Receiver < 100 mV time-averaged, pk-pk differential amplitudea (No Signal)
FALSE
Receiving a tone or 8B/10B-encoded characters at a frequency within the operating range of the portb - AND Vinput Receiver > 500 mV time-averaged, pk-pk differential amplitude - AND -
TRUE
V input Receiver < Maximum differential inputc (Valid signal) Other conditions Examples: 1) Receiving neither a tone nor a non-8B/10B-encoded data stream 2) Other end of the connection undergoing POR transients 3) One of the differential lines is open
Unspecified
aThis
condition implies that the connection is open or the transmitter on the other end of the connection is OFF (see Table 12-4 for the definition of OFF transmitter). bThis condition implies the transmitter on the other end of the connection shall be transmitting 8B/10B-encoded characters from the port or is toning, and the transmitter is functioning normally. cThis condition implies that the transmitter on the other end of the connection is operating within specifications and the connection is within specifications.
The parameters for the response times are defined in Figure 12-7 and specified in Table 12-9.
Occurrence of valid signal Occurrence of no signal
signal_detect t_sd_on
t_sd_off
Figure 12-7—signal_detect timing parameters Table 12-9—signal_detect timing Symbol
Parameter
Minimu m
Maximu m
Units
t_sd_on
Delay from valid signal to assertion of signal_detect
—
0.5
ms
t_sd_off
Delay from no signal to negation of signal_detect
—
t_sd_on
ms
324
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
12.6 PMD implementation The UTP PMD specification is similar to the specifications contained in other standards supporting 100 m of UTP cabling, such as ANSI X3.263-1995 and AF-PHY-0015.000 (Sept. 1994). While the UTP PMD is compatible with all the logical functions of the B PHY (e.g., 8B/10B coding, scrambling), implementation of the UTP PMD is likely to require further active components (such as line drivers, equalizer circuits, etc.) in addition to a Beta-capable PHY device that provides the standard electrical interface specified in 4.2. In this respect, it is envisaged that the UTP PMD may be implemented using technology similar to the technology developed for ANSI X3.263-1995 and AF-PHY-0015.000 (Sept. 1994). However, use of such technology is not necessary for compliance, nor does it guarantee compliance with this standard. Although this standard does not impose any particular implementation, the use of an adaptive equalizer is recommended to extend the distance at which IEEE 1394 signals may be transmitted over UTP cabling.
Copyright © 2008 IEEE. All rights reserved.
325
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
326
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
13. Beta mode port specification This clause specifies the functions and operation of a port when operating in Beta mode.
13.1 Overview The relationship and interfaces between the Beta mode port functions and the other functions and layers are illustrated in Figure 13-1:
Link B PHY
port controller
request/grant, enable
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control token machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
Port
Betamode functions
Connection management
DS-mode functions
Betamode functions
Low-power signaling
UTP - or GOF -orPlastic optical fiber -or Beta-only electrical -orBilingual electrical -or DS-only electrical
Connection management
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
to other ports
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
UTP - or GOF -orPlastic optical fiber -or Beta-only electrical -orBilingual electrical -or DS-only electrical
Figure 13-1—PHY master architecture (data routing, arbitration, and control interfaces in context) When operating in Beta mode, a port accepts data, control, and arbitration signals from the arbitration state machine (and also from the port’s connection management machine as the port transitions to and from the
Copyright © 2008 IEEE. All rights reserved.
327
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
On state), scrambles them, encodes them into 10-bit symbols for transmission and delivers the result as a bit stream to the PMD layer for onward transmission to the peer port. Simultaneously, the port accepts an incoming bit stream from the PMD layer (received from the peer port), deserializes it into 10-bit symbols, decodes and descrambles these symbols, and places the resulting data, control, and arbitration signal in the port’s receive FIFO, which is used to retime the incoming stream to the local clock. The incoming signals are in due course processed by the background process_requests function. The port carries out these functions when and for as long as the port’s bportOn signal is set to TRUE (i.e., set and reset by the connection management state machine). When bportOn is set to TRUE, the port engages in the symbol and scrambler synchronization of the encoded bit stream with its peer.
13.2 Port functions 13.2.1 Overview The port provides transmit and receive functions for formatting data as it passes between the arbitration state machine and the PMD. In the transmitting direction, data and control signals are both scrambled and mapped to characters that are in turn passed to the PMD layer, as illustrated in Figure 13-2. Each character comprises 10 bits. Transitions between data and control signals occur at the boundaries of these characters. Two distinct code tables are defined for mapping signals to characters. These two code tables are also used for decoding signals received from the PMD layer. control token
request
data byte (8 bits)
request mapping
control token mapping
request symbol ABCDEFGH
ABCDExxH
control symbol (4 bits) PQRS
scrambler 8
4
8
A’B’C’D’E’F’H’
A’B’C’D’E’00H’
P’Q’R’S’
8B/10B coder
8B/10B coder
control coder
Dx.y data character
10
abcdeifghj
Dx.0 or Dx.4 data character
10
abcdeifghj
Cz
10
control character
abcdeifghj
10 PMD
parallel to serial
Figure 13-2—Scrambling and coding functions
328
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Data are scrambled and then coded using an 8B/10B block code. The rate at which bits are passed to the PMD layer is, therefore, 1.25 times the data rate. Control tokens, which include packet delimiters, are mapped to 4-bit control symbols and then also scrambled. Each scrambled control symbol is transmitted as a 10-bit character. The time taken for a single 4-bit control symbol to be transmitted is equal to the time taken for a single byte of data to be transmitted. Requests are transmitted as data bytes and distinguished from data from their context. They are mapped to 6 bits of a data byte and then scrambled and coded in a similar way to data. The two remaining bits are set to 0 so that arbitration and control requests use only a subset of the data characters. Similar, but reciprocal, functions are provided by the port in the receiving direction. Data characters are identified as representing data or requests according to the context in which they are received, i.e., whether they are received within a packet.
13.2.2 Naming conventions This standard adopts the following definitions and conventions in defining data scrambling and coding: An unscrambled and un-encoded data byte contains 8 information bits (1 byte): A,B,C,D,E,F,G,H Bits A through H are the MSB through LSB of the byte. NOTE—The ordering of bits A through H as most significant through least significant is the opposite order from that adopted in some other standards that use the same encoding scheme.
A scrambled and un-encoded data byte has 8 information bits (1 byte): A’,B’,C’,D’,E’,F’,G’,H’ Bits A’ through H’ are the MSB through LSB of the byte. The scrambled and coded data character has 10 information bits: a, b, c, d, e, i, f, g, h, and j (NOTE—Not strictly alphabetical ordering) Bits are transmitted as listed above. (Bits a through j are transmitted first through last.) This standard adopts the following definitions and conventions in defining control scrambling and coding: An unscrambled and un-encoded control symbol contains 4 information bits: P,Q,R,S Bits P through S are the MSB through LSB. A scrambled and un-encoded control symbol has 4 information bits: P’,Q’,R’S’ Bits P’ through S’ are the MSB through LSB. The scrambled and coded control character has 10 information bits: a, b, c, d, e, i, f, g, h, and j (NOTE—Not strictly alphabetical ordering) Bits are transmitted as listed above. (Bits a through j are transmitted first through last.)
13.2.3 Control mapping Control tokens shall be mapped to 4-bit control symbols according to Table 13-1. In this table, rd represents the running digital sum at the end of the previous character.
Copyright © 2008 IEEE. All rights reserved.
329
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 13-1—Control mapping Control symbol PQRS
Control token rd<0
rd>0
Reserved
0000
CYCLE_START_EVEN
0001
CYCLE_START_ODD
0010
ATTACH_REQUEST/ARB_CONTEXT
0011
SPEEDa
0100
DATA_END
0101
DATA_NULL
0110
SPEEDb
0111
GRANT
1000
DATA_PREFIX
1010
1001
GRANT_ISOCH
1011
SPEEDc
1100
ASYNC_EVEN
1101
ASYNC_ODD
1110
BUS_RESET
1111
13.2.4 Request types Two types of request are defined: —
An arbitration request is used for bus owner/supervisor/selector (BOSS) arbitration and combines requests for both isochronous and asynchronous packet transmissions into a single symbol, which, after scrambling, is represented by a single data character. A variant of the arbitration request carries a request or a phase indication.
—
A configuration request is used for non-BOSS arbitration and conveys information pertaining to the configuration of the bus as a single symbol, which, after scrambling, is represented by a single data character.
13.2.4.1 BOSS arbitration request mapping A single arbitration request symbol carries both an asynchronous request and an isochronous request, or it carries a request or phase. Asynchronous and isochronous requests are independently mapped into the respective component parts of the symbol according to Table 13-2 and Table 13-3. Each BOSS asynchronous request shall be mapped to a symbol according to Table 13-2. Each BOSS isochronous request shall be mapped to a symbol according to Table 13-3.
330
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 13-2—Asynchronous request mapping Request
Request symbol component bits ABC
Reserved
000
CURRENT
001
NEXT_EVEN
010
CYCLE_START_REQ
011
NONE_ODD
100
NEXT_ODD
101
NONE_EVEN
110
BORDER
111
Table 13-3—Isochronous request mapping Request
Request symbol component bitsa DEFGH
Not usedb
00xx0
ISOCH_NONE
01xx0
ISOCH_EVEN
10xx0
ISOCH_ODD
11xx0
ISOCH_CURRENT
00xx1
usedc
01xx1
Reserved
10xx1
usedd
11xx1
Not
Not
aSymbol
component bits F and G (marked as having value x) are never used to carry request information. However, they have been included in the definition of the request mapping, as the 8-bit symbol is used as an input to the data scrambler and coder. bThe component bits 00xx0 are not used for an isochronous request as the resulting symbol would be indistinguishable from a configuration request. DEFGH = 00xx0 indicates a configuration request. cThe component bits 01xx1 are not used for an isochronous request, but are used to identify a request or phase. d The component bits 11xx1 are not used for an isochronous request as the resulting symbol would be indistinguishable from the use of requests used on the PIL-FOP interface. DEFGH = 11xx1 indicates a request used by the PIL-FOP interface (see 18.4).
A request or phase shall be mapped to a symbol according to Table 13-4. The request symbol component bits B and C (identified as pp in Table 13-4) shall carry the phase information, represented as a binary number modulo 4.
Copyright © 2008 IEEE. All rights reserved.
331
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 13-4—Request and phase mapping Request symbola ABCDEFGH
Request _REQUEST
0pp01xx1
_PHASE
1pp01xx1
a
Symbol component bits F and G (marked as having value x) are never used to carry request information. However, they have been included in the definition of the request mapping, as the 8-bit symbol is used as an input to the data scrambler and coder.
13.2.4.2 Configuration requests Each configuration request shall be mapped to a symbol according to Table 13-5.
Table 13-5—Configuration request mapping Request
Request symbola ABCDEFGH
TRAINING
00000xx0
DISABLE_NOTIFY
00100xx0
CHILD_NOTIFY/IDENT_DONE/PARENT_HANDSHAKE
01000xx0
OPERATION
01100xx0
STANDBY
10000xx0
SUSPEND
10100xx0
PARENT_NOTIFY
11000xx0
Reserved
11100xx0
aSymbol
component bits F and G (marked as having value x) are never used to carry request information. However, they have been included in the definition of the request mapping, as the 8-bit symbol is used as an input to the data scrambler and coder.
13.2.5 Scrambling Data bytes and control symbols are scrambled before 8B/10B coding to avoid the generation of repetitive sequences of identical 10-bit characters. Such repetitive sequences would otherwise be generated during long periods of transmitting a constant control state or during the transmission of repetitive data patterns (e.g., all zeros). Repetitive sequences may have large amounts of energy concentrated at discrete frequencies that can lead to electromagnetic compatibility problems. Scrambling causes the transmitted energy to be spread more uniformly across the transmission frequency band and hence minimizes these problems. Because data bytes and control symbols are scrambled before the 8B/10B block coding, the properties of the block code (i.e., dc balance, run length, comma characters) are not affected by the use of scrambling. Beta mode transmission employs a side stream scrambler. The same scrambler is used to scramble both data and control information. The scrambler uses the following generating polynomial:
332
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
G(x) = x11 + x9 + 1 The scrambler shall generate a continuous stream of output bits at the same rate as the port operating speed during both packet and control transmission. These output bits are represented as a sequence of bits Scr(k) where k = 0, 1, 2, 3, ..., so that Scr(k + 1) is the output bit immediately following Scr(k). The scrambler output at any point in time is defined as follows: Scr(k) = Scr(k – 9) XOR Scr(k – 11). Eight successive outputs of the scrambler are used to scramble a symbol, as described in 13.2.5.1. The next eight successive outputs of the scrambler are then used to scramble the next symbol. See Figure 13-3. XOR
x0
x1
x2
x3
x4
x5
x6
k
k+1
k+2
k+3
k+4
k+5
k+6
k+7
k
k+1
k+2
k+3
k+4
k+5
k+6
k+7
x7
x8
x9
x10
Operates at bit rate Operates at byte rate
scrambler output register, Scr
Byte clock
Figure 13-3—Representation of the scrambler as a serial bit-shift register with parallel output 13.2.5.1 Data scrambling During packet transmission, the data are scrambled using the output of the scrambler, and the scrambler generates 8 bits for each byte of data to be transmitted. The scrambled data stream is the result of an XOR operation on the data stream and the scrambler output. Any data byte shall be scrambled according to the following rule: [A’,B’,C’,D’,E’,F’,G’,H’]= [A,B,C,D,E,F,G,H] XOR [Scr(k:k + 7)] Thus the MSB of the data byte, A, is XORed with the Scr(k); and the LSB of the data byte, H, is XORed with the Scr(k + 7). For example, during a sequence of data, the scrambled data bytes would be calculated as follows: first scrambled data byte = [A,B,C,D,E,F,G,H] XOR [Scr(k:k + 7)], second scrambled data byte = [A,B,C,D,E,F,G,H] XOR [Scr(k + 8:k + 15)], etc. The scrambling procedure for data bytes is illustrated in Figure 13-4.
Copyright © 2008 IEEE. All rights reserved.
333
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
scrambler output register, Scr k
MSB
A
k+1
k+3
k+4
k+5
k+7
XOR
C
XOR
D
XOR
E
XOR
F
XOR
G lsb
k+6
XOR
B
data byte
k+2
XOR
H
XOR A’
B’
C’ D’ E’ F’ input to 8B/10B coder
G’
H’
Figure 13-4—Scrambler schematic (data) 13.2.5.2 Request symbol scrambling Request symbols are initially scrambled in the same way as data bytes. Then bits F’ and G’ of the scrambled request are set to 0. This has the effect of limiting the set of data characters used for the coding of the requests to a subset containing only Dx.0 and Dx.4 characters. This subset of data characters has the property that all characters within the set are separated from each other by a Hamming distance of two. Scrambling and coding requests in this way ensures that a single error in a request character will always be detected by a receiver. Any request symbol shall be scrambled according to the following rule: [A’,B’,C’,D’,E’,F’,G’,H’]= ([A,B,C,D,E,F,G,H] XOR [Scr(k:k + 7)]) AND (11111001) Thus the MSB of the request symbol, A, is XORed with the Scr(k); and the LSB of the request symbol, H, is XORed with the Scr(k + 7). The scrambling procedure for request symbols is illustrated in Figure 13-5.
334
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
scrambler output register, Scr k
MSB
A
k+1
k+3
k+4
k+5
k+6
k+7
XOR
B
XOR
C data byte
k+2
XOR
D
XOR
E
XOR
F G lsb
H
XOR A’
B’
C’ D’ E’ input to 8B/10B coder
H’
Figure 13-5—Scrambler schematic (request symbol) 13.2.5.3 Control symbol scrambling The scrambled control symbol shall be the result of an XOR operation on the control symbol and alternate bits of the scrambler generating polynomial. Any control symbol shall be scrambled according to the following rule: [P’,Q’,R’,S’]= [P,Q,R,S] XOR [Scr(k),Scr(k + 2),Scr(k + 4),Scr(k + 6)] The scrambling procedure for control symbols is illustrated in Figure 13-6.
Copyright © 2008 IEEE. All rights reserved.
335
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
scrambler output register, Scr k
P
k+1
k+2
k+3
k+4
k+5
k+6
k+7
XOR
Q
XOR
control symbol R
XOR
S
XOR
P’
Q’ R’ input to control coder
S’
Figure 13-6—Scrambler schematic (control) 13.2.6 Coding The symbol coding function defines and implements the character coding scheme employed by Beta mode. Scrambled data bytes, request symbols, and control symbols are encoded into characters for transmission by the PMD layer. Similarly, characters are received from the PHY are decoded into un-encoded bytes, request symbols, or control symbols and passed to the descrambler. A degree of error detection is built into this coding method, but the main advantage is the lack of dc frequency content in the electrical signals produced. Beta mode uses two distinct codes. The first code maps data and requests to a set of characters that are referred to as data characters. The second code maps control symbols to a second, smaller and distinct set of characters that are referred to as control characters.
13.2.6.1 8B/10B character coding for data and request types The 8B/10B transmission code of Widmer and Franaszek [B33] is used for coding the scrambled data and request symbols. This code provides a dc-balanced code with minimal run lengths. This code provides for 256 input symbols and produces sequences of characters with guaranteed ac transitions and no dc frequency component. The 8B/10B code features, the method of code construction, and the resulting code tables are given in 13.2.6.1.1 through 13.2.6.1.4.
336
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The following definitions and conventions are used in defining the 8B/10B coding rules: Each valid data character has a name Dx.y. where x = the 5-bit input value, base 10, for bits A’B’C’D’E’ y = the 3-bit input value, base 10, for bits F’G’H’ In Table 13-6 through Table 13-11, —
rd represents the running digital sum value at the end of the previous character.
—
rd1 represents the running digital sum value at the end of the current character.
The running digital sum of the transmitter and the receiver is initialized to –1 during the port initialization process on a new connection.
13.2.6.1.1 8B/10B run length and dc balance A sequence of valid 8B/10B characters has a maximum run length of 5 bits (i.e., 5 consecutive ones or 5 consecutive zeros before a mandatory bit transition). Consequently, ample transitions are provided to aid in clock extraction by the PHY’s receiving PLLs. Each valid 8B/10B character also has disparity of zero (i.e., same number of ones and zeros in the character), +2 or –2. To maintain dc balance, the coding protocol demands that each character have opposite disparity from the preceding character or zero disparity. Consequently, each nonzero disparity code character has an alternative coding with reversed disparity. The coder produces the correct alternating disparities with a running digital sum counter that controls which alternate output character is produced. When initialized to a value of –1, the running digital sum after any bit in a sequence of valid data characters is constrained to be between –3 and +3 inclusive. Furthermore, the mechanism of alternating output characters ensures that the running digital sum at the end of any code character is either –1 or +1. The transmitter and receiver shall both initialize their respective running digital sum to be –1 when the port is turned On or after exiting any implementation-dependent diagnostic modes and shall update it to be –1 (negative) or +1 (positive) as appropriate at the end of every code character.
13.2.6.1.2 8B/10B code construction The 8B/10B coding is defined in two stages. The first stage codes the first 5 bits of the un-encoded input byte into a 6-bit block. This 5B/6B coder produces the 6-bit block depending upon the input bit values and the running digital sum value. The second stage codes the last 3 bits of the un-encoded byte into a 4-bit block using a 3B/4B coder. The running digital sum value, as modified by the first coding stage, is also used for the second coding decision. Table 13-6 and Table 13-7 give the 5B/6B and 3B/4B coding tables, respectively, that are used for coding Dx.y characters.
13.2.6.1.3 8B/10B valid data characters Table 13-8 lists all of the valid data characters generated by passing the 256 possible input data bytes through the 5B/6B and 3B/4B coders. NOTE—The order of the entries in Table 13-8 is different from the order used in some other standards that use the same encoding scheme, because IEEE Std 1394 uses MSB-to-LSB order for A’ through H’.
Copyright © 2008 IEEE. All rights reserved.
337
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 13-6—5B/6B coding Inputs
abcdei outputs
Inputs
abcdei outputs
rd1 Symbol
A’B’C’D’E’
rd > 0
rd < 0
D0
00000
011000
100111
D1
10000
100010
D2
01000
010010
D3
11000
110001
D4
00100
001010
D5
10100
101001
D6
01100
011001
D7
11100
000111
111000
D8
00010
000110
111001
D9
10010
100101
D10
01010
D11
rd1 Symbol
A’B’C’D’E’
rd > 0
rd < 0
D16
00001
100100
011011
011101
D17
10001
100011
101101
D18
01001
010011
rd
D19
11001
110010
–rd
D20
00101
001011
rd
D21
10101
101010
D22
01101
011010
rd
D23
11101
000101
111010
–rd
D24
00011
001100
110011
rd
D25
10011
100110
010101
D26
01011
010110
11010
110100
D27
11011
001001
D12
00110
001101
D28
00111
001110
D13
10110
101100
D29
10111
010001
101110
D14
01110
011100
D30
01111
100001
011110
D15
11110
101000
D31
11111
010100
101011
110101
010111
–rd
–rd
–rd rd
–rd
rd
110110
–rd rd –rd
Table 13-7—3B/4B coding Inputs
fghj outputs rd1
Symbol
F’G’H’
rd > 0
rd < 0
Dx.0
000
0100
1011
–rd
Dx.1
100
1001
Dx.2
010
0101
Dx.3
110
0011
1100
rd
Dx.4
001
0010
1101
–rd
Dx.5
101
1010
Dx.6
011
0110
Dx.P7
111
0001
1110
Dx.A7
111
1000
0111
rd
rd
–rd
A7 replaces P7 if the following is true: (rd<0)? (e==1 && i==1): (e==0 && i==0)
338
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
Name i
data_table[i][0]
data_table[i][1]
00000 000
100111 0100
011000 1011
D4.0
00100 000
110101 0100
001010 1011
D0.4
00000 001
100111 0010
011000 1101
D4.4
00100 001
110101 0010
001010 1101
D0.2
00000 010
100111 0101
011000 0101
D4.2
00100 010
110101 0101
001010 0101
D0.6
00000 011
100111 0110
011000 0110
D4.6
00100 011
110101 0110
001010 0110
D0.1
00000 100
100111 1001
011000 1001
D4.1
00100 100
110101 1001
001010 1001
D0.5
00000 101
100111 1010
011000 1010
D4.5
00100 101
110101 1010
001010 1010
D0.3
00000 110
100111 0011
011000 1100
D4.3
00100 110
110101 0011
001010 1100
D0.7
00000 111
100111 0001
011000 1110
D4.7
00100 111
110101 0001
001010 1110
D16.0
00001 000
011011 0100
100100 1011
D20.0
00101 000
001011 1011
001011 0100
D16.4
00001 001
011011 0010
100100 1101
D20.4
00101 001
001011 1101
001011 0010
D16.2
00001 010
011011 0101
100100 0101
D20.2
00101 010
001011 0101
001011 0101
D16.6
00001 011
011011 0110
100100 0110
D20.6
00101 011
001011 0110
001011 0110
D16.1
00001 100
011011 1001
100100 1001
D20.1
00101 100
001011 1001
001011 1001
D16.5
00001 101
011011 1010
100100 1010
D20.5
00101 101
001011 1010
001011 1010
D16.3
00001 110
011011 0011
100100 1100
D20.3
00101 110
001011 1100
001011 0011
D16.7
00001 111
011011 0001
100100 1110
D20.7
00101 111
001011 0111
001011 0001
D8.0
00010 000
111001 0100
000110 1011
D12.0
00110 000
001101 1011
001101 0100
D8.4
00010 001
111001 0010
000110 1101
D12.4
00110 001
001101 1101
001101 0010
D8.2
00010 010
111001 0101
000110 0101
D12.2
00110 010
001101 0101
001101 0101
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
339
D0.0
HIGH-PERFORMANCE SERIAL BUS
Copyright © 2008 IEEE. All rights reserved.
Table 13-8—Valid data characters
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
IEEE Std 1394-2008
340
Table 13-8—Valid data characters (continued)
Name i
data_table[i][0]
data_table[i][1]
00010 011
111001 0110
000110 0110
D12.6
00110 011
001101 0110
001101 0110
D8.1
00010 100
111001 1001
000110 1001
D12.1
00110 100
001101 1001
001101 1001
D8.5
00010 101
111001 1010
000110 1010
D12.5
00110 101
001101 1010
001101 1010
D8.3
00010 110
111001 0011
000110 1100
D12.3
00110 110
001101 1100
001101 0011
D8.7
00010 111
111001 0001
000110 1110
D12.7
00110 111
001101 1110
001101 0001
D24.0
00011 000
110011 0100
001100 1011
D28.0
00111 000
001110 1011
001110 0100
D24.4
00011 001
110011 0010
001100 1101
D28.4
00111 001
001110 1101
001110 0010
D24.2
00011 010
110011 0101
001100 0101
D28.2
00111 010
001110 0101
001110 0101
D24.6
00011 011
110011 0110
001100 0110
D28.6
00111 011
001110 0110
001110 0110
D24.1
00011 100
110011 1001
001100 1001
D28.1
00111 100
001110 1001
001110 1001
D24.5
00011 101
110011 1010
001100 1010
D28.5
00111 101
001110 1010
001110 1010
D24.3
00011 110
110011 0011
001100 1100
D28.3
00111 110
001110 1100
001110 0011
D24.7
00011 111
110011 0001
001100 1110
D28.7
00111 111
001110 1110
001110 0001
D2.0
01000 000
101101 0100
010010 1011
D6.0
01100 000
011001 1011
011001 0100
D2.4
01000 001
101101 0010
010010 1101
D6.4
01100 001
011001 1101
011001 0010
D2.2
01000 010
101101 0101
010010 0101
D6.2
01100 010
011001 0101
011001 0101
D2.6
01000 011
101101 0110
010010 0110
D6.6
01100 011
011001 0110
011001 0110
D2.1
01000 100
101101 1001
010010 1001
D6.1
01100 100
011001 1001
011001 1001
D2.5
01000 101
101101 1010
010010 1010
D6.5
01100 101
011001 1010
011001 1010
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
D8.6
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
Name i
data_table[i][0]
data_table[i][1]
01000 110
101101 0011
010010 1100
D6.3
01100 110
011001 1100
011001 0011
D2.7
01000 111
101101 0001
010010 1110
D6.7
01100 111
011001 1110
011001 0001
D18.0
01001 000
010011 1011
010011 0100
D22.0
01101 000
011010 1011
011010 0100
D18.4
01001 001
010011 1101
010011 0010
D22.4
01101 001
011010 1101
011010 0010
D18.2
01001 010
010011 0101
010011 0101
D22.2
01101 010
011010 0101
011010 0101
D18.6
01001 011
010011 0110
010011 0110
D22.6
01101 011
011010 0110
011010 0110
D18.1
01001 100
010011 1001
010011 1001
D22.1
01101 100
011010 1001
011010 1001
D18.5
01001 101
010011 1010
010011 1010
D22.5
01101 101
011010 1010
011010 1010
D18.3
01001 110
010011 1100
010011 0011
D22.3
01101 110
011010 1100
011010 0011
D18.7
01001 111
010011 0111
010011 0001
D22.7
01101 111
011010 1110
011010 0001
D10.0
01010 000
010101 1011
010101 0100
D14.0
01110 000
011100 1011
011100 0100
D10.4
01010 001
010101 1101
010101 0010
D14.4
01110 001
011100 1101
011100 0010
D10.2
01010 010
010101 0101
010101 0101
D14.2
01110 010
011100 0101
011100 0101
D10.6
01010 011
010101 0110
010101 0110
D14.6
01110 011
011100 0110
011100 0110
D10.1
01010 100
010101 1001
010101 1001
D14.1
01110 100
011100 1001
011100 1001
D10.5
01010 101
010101 1010
010101 1010
D14.5
01110 101
011100 1010
011100 1010
D10.3
01010 110
010101 1100
010101 0011
D14.3
01110 110
011100 1100
011100 0011
D10.7
01010 111
010101 1110
010101 0001
D14.7
01110 111
011100 1110
011100 1000
D26.0
01011 000
010110 1011
010110 0100
D30.0
01111 000
011110 0100
100001 1011
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
341
D2.3
HIGH-PERFORMANCE SERIAL BUS
Copyright © 2008 IEEE. All rights reserved.
Table 13-8—Valid data characters (continued)
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
IEEE Std 1394-2008
342
Table 13-8—Valid data characters (continued)
Name i
data_table[i][0]
data_table[i][1]
01011 001
010110 1101
010110 0010
D30.4
01111 001
011110 0010
100001 1101
D26.2
01011 010
010110 0101
010110 0101
D30.2
01111 010
011110 0101
100001 0101
D26.6
01011 011
010110 0110
010110 0110
D30.6
01111 011
011110 0110
100001 0110
D26.1
01011 100
010110 1001
010110 1001
D30.1
01111 100
011110 1001
100001 1001
D26.5
01011 101
010110 1010
010110 1010
D30.5
01111 101
011110 1010
100001 1010
D26.3
01011 110
010110 1100
010110 0011
D30.3
01111 110
011110 0011
100001 1100
D26.7
01011 111
010110 1110
010110 0001
D30.7
01111 111
011110 0001
100001 1110
D1.0
10000 000
011101 0100
100010 1011
D5.0
10100 000
101001 1011
101001 0100
D1.4
10000 001
011101 0010
100010 1101
D5.4
10100 001
101001 1101
101001 0010
D1.2
10000 010
011101 0101
100010 0101
D5.2
10100 010
101001 0101
101001 0101
D1.6
10000 011
011101 0110
100010 0110
D5.6
10100 011
101001 0110
101001 0110
D1.1
10000 100
011101 1001
100010 1001
D5.1
10100 100
101001 1001
101001 1001
D1.5
10000 101
011101 1010
100010 1010
D5.5
10100 101
101001 1010
101001 1010
D1.3
10000 110
011101 0011
100010 1100
D5.3
10100 110
101001 1100
101001 0011
D1.7
10000 111
011101 0001
100010 1110
D5.7
10100 111
101001 1110
101001 0001
D17.0
10001 000
100011 1011
100011 0100
D21.0
10101 000
101010 1011
101010 0100
D17.4
10001 001
100011 1101
100011 0010
D21.4
10101 001
101010 1101
101010 0010
D17.2
10001 010
100011 0101
100011 0101
D21.2
10101 010
101010 0101
101010 0101
D17.6
10001 011
100011 0110
100011 0110
D21.6
10101 011
101010 0110
101010 0110
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
D26.4
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
Name i
data_table[i][0]
data_table[i][1]
10001 100
100011 1001
100011 1001
D21.1
10101 100
101010 1001
101010 1001
D17.5
10001 101
100011 1010
100011 1010
D21.5
10101 101
101010 1010
101010 1010
D17.3
10001 110
100011 1100
100011 0011
D21.3
10101 110
101010 1100
101010 0011
D17.7
10001 111
100011 0111
100011 0001
D21.7
10101 111
101010 1110
101010 0001
D9.0
10010 000
100101 1011
100101 0100
D13.0
10110 000
101100 1011
101100 0100
D9.4
10010 001
100101 1101
100101 0010
D13.4
10110 001
101100 1101
101100 0010
D9.2
10010 010
100101 0101
100101 0101
D13.2
10110 010
101100 0101
101100 0101
D9.6
10010 011
100101 0110
100101 0110
D13.6
10110 011
101100 0110
101100 0110
D9.1
10010 100
100101 1001
100101 1001
D13.1
10110 100
101100 1001
101100 1001
D9.5
10010 101
100101 1010
100101 1010
D13.5
10110 101
101100 1010
101100 1010
D9.3
10010 110
100101 1100
100101 0011
D13.3
10110 110
101100 1100
101100 0011
D9.7
10010 111
100101 1110
100101 0001
D13.7
10110 111
101100 1110
101100 1000
D25.0
10011 000
100110 1011
100110 0100
D29.0
10111 000
101110 0100
010001 1011
D25.4
10011 001
100110 1101
100110 0010
D29.4
10111 001
101110 0010
010001 1101
D25.2
10011 010
100110 0101
100110 0101
D29.2
10111 010
101110 0101
010001 0101
D25.6
10011 011
100110 0110
100110 0110
D29.6
10111 011
101110 0110
010001 0110
D25.1
10011 100
100110 1001
100110 1001
D29.1
10111 100
101110 1001
010001 1001
D25.5
10011 101
100110 1010
100110 1010
D29.5
10111 101
101110 1010
010001 1010
D25.3
10011 110
100110 1100
100110 0011
D29.3
10111 110
101110 0011
010001 1100
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
343
D17.1
HIGH-PERFORMANCE SERIAL BUS
Copyright © 2008 IEEE. All rights reserved.
Table 13-8—Valid data characters (continued)
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
IEEE Std 1394-2008
344
Table 13-8—Valid data characters (continued)
Name i
data_table[i][0]
data_table[i][1]
10011 111
100110 1110
100110 0001
D29.7
10111 111
101110 0001
010001 1110
D3.0
11000 000
110001 1011
110001 0100
D7.0
11100 000
111000 1011
000111 0100
D3.4
11000 001
110001 1101
110001 0010
D7.4
11100 001
111000 1101
000111 0010
D3.2
11000 010
110001 0101
110001 0101
D7.2
11100 010
111000 0101
000111 0101
D3.6
11000 011
110001 0110
110001 0110
D7.6
11100 011
111000 0110
000111 0110
D3.1
11000 100
110001 1001
110001 1001
D7.1
11100 100
111000 1001
000111 1001
D3.5
11000 101
110001 1010
110001 1010
D7.5
11100 101
111000 1010
000111 1010
D3.3
11000 110
110001 1100
110001 0011
D7.3
11100 110
111000 1100
000111 0011
D3.7
11000 111
110001 1110
110001 0001
D7.7
11100 111
111000 1110
000111 0001
D19.0
11001 000
110010 1011
110010 0100
D23.0
11101 000
111010 0100
000101 1011
D19.4
11001 001
110010 1101
110010 0010
D23.4
11101 001
111010 0010
000101 1101
D19.2
11001 010
110010 0101
110010 0101
D23.2
11101 010
111010 0101
000101 0101
D19.6
11001 011
110010 0110
110010 0110
D23.6
11101 011
111010 0110
000101 0110
D19.1
11001 100
110010 1001
110010 1001
D23.1
11101 100
111010 1001
000101 1001
D19.5
11001 101
110010 1010
110010 1010
D23.5
11101 101
111010 1010
000101 1010
D19.3
11001 110
110010 1100
110010 0011
D23.3
11101 110
111010 0011
000101 1100
D19.7
11001 111
110010 1110
110010 0001
D23.7
11101 111
111010 0001
000101 1110
D11.0
11010 000
110100 1011
110100 0100
D15.0
11110 000
010111 0100
101000 1011
D11.4
11010 001
110100 1101
110100 0010
D15.4
11110 001
010111 0010
101000 1101
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
D25.7
Input
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
Input
rd > 0
Name
abcdei fghj output
A’B’C’D’E’F’G’H’
rd < 0
rd > 0
i
data_table[i][0]
data_table[i][1]
Name i
data_table[i][0]
data_table[i][1]
D11.2
11010 010
110100 0101
110100 0101
D15.2
11110 010
010111 0101
101000 0101
D11.6
11010 011
110100 0110
110100 0110
D15.6
11110 011
010111 0110
101000 0110
D11.1
11010 100
110100 1001
110100 1001
D15.1
11110 100
010111 1001
101000 1001
D11.5
11010 101
110100 1010
110100 1010
D15.5
11110 101
010111 1010
101000 1010
D11.3
11010 110
110100 1100
110100 0011
D15.3
11110 110
010111 0011
101000 1100
D11.7
11010 111
110100 1110
110100 1000
D15.7
11110 111
010111 0001
101000 1110
D27.0
11011 000
110110 0100
001001 1011
D31.0
11111 000
101011 0100
010100 1011
D27.4
11011 001
110110 0010
001001 1101
D31.4
11111 001
101011 0010
010100 1101
D27.2
11011 010
110110 0101
001001 0101
D31.2
11111 010
101011 0101
010100 0101
D27.6
11011 011
110110 0110
001001 0110
D31.6
11111 011
101011 0110
010100 0110
D27.1
11011 100
110110 1001
001001 1001
D31.1
11111 100
101011 1001
010100 1001
D27.5
11011 101
110110 1010
001001 1010
D31.5
11111 101
101011 1010
010100 1010
D27.3
11011 110
110110 0011
001001 1100
D31.3
11111 110
101011 0011
010100 1100
D27.7
11011 111
110110 0001
001001 1110
D31.7
11111 111
101011 0001
010100 1110
HIGH-PERFORMANCE SERIAL BUS
Copyright © 2008 IEEE. All rights reserved.
Table 13-8—Valid data characters (continued)
IEEE Std 1394-2008
345 Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
13.2.6.1.4 8B/10B valid special characters The data code also provides a number of special characters beyond the 256 needed to encode a byte of data. These characters are named Kx.y. Two of these special characters, K28.5 and K28.7 are defined in Table 13-9.
Table 13-9—K28.x special characters abcdei fghj values Control character name
rd < 0
rd > 0
comma_table[0]
comma_table[1]
K28.5
001111 1010
110000 0101
K28.7
001111 1000
001111 1000
A comma sequence is singular and occurs with a uniform alignment relative to a character within the code. The K28.5 special character contains a sequence that is a comma with respect to the data code. In the absence of errors, the comma does not occur in any other bit positions, neither within characters nor through overlap between characters. The comma sequence for the 8B/10B data code is the 7-bit sequence “0011111” or “1100000.” The K28.5 special character is used during the Beta training procedure. While either a training request or an operation request is being transmitted, a K28.5 symbol is periodically inserted into the character stream to assist the receiving port in acquiring byte synchronization. Specifically, when a training request or operation request is transmitted, the port replaces each occurrence of a D28.0 character in the transmitted character stream with a K28.5 character. The cyclic nature of the scrambler guarantees a periodic D28.0 character when repeatedly transmitting a particular request. As the 7-bit sequence “0011111” or “1100000” is not a comma for the control code, the occurrence of a K28.5 comma character is a necessary, but not sufficient, condition for byte synchronization (see 13.3.2.1.2). The K28.7 special character is sometimes referred to as a low-frequency comma. It is often used during transmission testing because a series of K28.7 characters generates the lowest-frequency square-wave pattern in the data stream.
13.2.6.2 Control coding In addition to the Dx.y and Kx.y characters, Beta mode uses a set of characters for coding control symbols. Control coding also produces sequences of characters with guaranteed ac transitions and no dc frequency component. The control code features and the code table are given in 13.2.6.2.1 through 13.2.6.2.3. See Table 13-10.
346
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 13-10—Control coding abcdeifghj outputs Control character name
P’Q’R’S’ rd <0 i
rd > 0
control_table[i]
C0
0000
0000011111
C1
0001
0111110000
C2
0010
0010001111
C3
0011
1110110000
C4
0100
0000111110
C5
0101
0011111000
C6
0110
0100001111
C7
0111
1111010000
C8
1000
0000101111
C9
1001
1011110000
C10
1010
1100000111
C11
1011
1111000001
C12
1100
0001001111
C13
1101
1101110000
C14
1110
1000001111
C15
1111
1111100000
13.2.6.2.1 Valid control code characters Beta mode adopts the following definitions and conventions in defining the control code: Each valid control code character has a name Cz, where z = the 4-bit input value, base 10, for bits P’Q’R’S’
13.2.6.2.2 Control code run length and dc balance A sequence of valid 10-bit control code characters has a maximum run length of 10 bits (i.e., 10 consecutive ones or 10 consecutive zeros before a mandatory bit transition). Consequently, ample transitions are provided to aid in clock extraction by the receiving PHY. Each valid control code character also has zero disparity (i.e., same number of ones and zeros in the character). Consequently, the control coding maintains the dc balance of the transmitted signal. When the transmitter has been initialized according to 13.2.6.1.1, the running digital sum at the end of any control code character is either –1 or +1. More generally, the running digital sum after any bit in a sequence of valid 10-bit control code characters is constrained to be between –6 and +6 inclusive.
Copyright © 2008 IEEE. All rights reserved.
347
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
13.2.6.2.3 Control code error detection A valid control code character is separated from all valid Dx.y characters by Hamming distance 2. Consequently, a single bit error in any position will not change a control character representing control information into a character representing data or an arbitration request.
13.2.7 Character transmission Data and control characters shall be transmitted serially in the order a,b,c,d,e,i,f,g,h,j (i.e., bit a is transmitted first).
13.2.8 Decoding 13.2.8.1 Bit and character synchronization Before control and data characters can be correctly decoded, a receiver shall determine the correct time to sample bits received from the PMD. A receiver shall also determine the correct timing of the transitions between characters. The training request and operation request signals contain periodic occurrences of a K28.5 comma character that may be used to acquire character synchronization. See 13.3.2.1.2.
13.2.8.2 Data and control character decoding and error detection Data and control character decoding is performed according to Table 13-8 and Table 13-10. Based on the receiver’s running digital sum, the appropriate columns in these tables are searched for the received character. If found, the character is considered valid. If the character is not found in the appropriate columns, the character is considered to be invalid. NOTE—A received character not found in the appropriate column of a table and determined to be invalid may not actually contain transmission errors. The character may appear to be in error if a previously received erroneous character has corrupted the receiver’s running digital sum.
13.2.8.3 Special character decoding When a K28.5 special character is received, it shall be decoded according to Table 13-11. The result of decoding a K28.5 special character is the same as the result obtained from decoding a D28.0 character.
Table 13-11—Special character decoding abcdei fghj input Name
Output A’B’C’D’E’F’G’ H’
rd < 0
rd > 0
D28.0
001110 1011
001110 0100
00111 000
K28.5
001111 1010
110000 0101
00111 000
13.2.9 Receiver running disparity The running disparity is the receiver’s estimate of the peer port transmitter’s running digital sum at the same bit position. In the absence of transmission errors, the receiver’s running disparity is the same as the transmitter’s running digital sum. The port shall not update the running disparity when a Cz character is received. (However, if the Cz control character is subsequently decoded and found to be DATA_PREFIX,
348
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
the running disparity is forced to the value that corresponds to the encoding used; see 13.3.2.4.) When any other character is received, including an invalid character that is not found in Table 13-8, Table 13-9, or Table 13-10, the running disparity shall be updated according to the following rules: a)
The running disparity is updated at the end of each character subblock, where character subblocks are the 6 MSBs and 4 LSBs of the character, i.e., bits a,b,c,d,e,i and bits f,g,h,j.
b)
The running disparity is positive at the end of any subblock if that subblock contains more ones than zeros. The running disparity is also positive at the end of the six bit subblock 000111 and at the end of the four bit subblock 0011.
c)
The running disparity is negative at the end of any subblock if that subblock contains more zeros than ones. The running disparity is also negative at the end of the six bit subblock 111000 and at the end of the four bit subblock 1100.
d)
Otherwise, the running disparity at the end of any subblock is the same as at the start of that subblock.
NOTES 1—All subblocks with equal number of ones and zeros leave the running disparity unchanged apart from the particular cases of 6-bit subblocks 000111 and 111000 and 4-bit subblocks 0011 and 1100. 2—All Cz characters have equal number of ones and zeros and, therefore, do not change the running digital sum of the received signal. However, the rules listed in this subclause should not be used to update the running disparity when a Cz character is received.
13.2.10 Descrambling Control and data symbols shall be descrambled using the reverse of the scrambling procedures as described in 13.2.5. For successful operation, the state of a receiver’s descrambler should be synchronized with the state of the scrambler in the remote port’s transmitter. This synchronization requires that the receiver learn the state of the remote transmitter’s scrambler during port training. A receiver shall synchronize the state of its descrambler with the state of the remote transmitter’s scrambler while receiving sequences of valid TRAINING or OPERATION configuration request symbols. NOTE—A receiver may train its scrambler by using the fact that the LSB of all configuration requests (in particular TRAINING and OPERATION configuration requests) is zero, thus when the transmitter is transmitting configuration requests the LSb of the scrambled symbol before 8B/10B encoding will be the same as the LSb of the scrambler. This will be preserved through 8B/10B encoding, serial transmission, and 10B/8B decoding in the receiver (provided that no polarity inversion occurs). Hence the LSb of the received symbol after 10B/8B decoding will be the same value as the LSb of the state of the transmitter’s scrambler at the time the configuration request was scrambled. The design of the scrambler is such that forcing the LSb of the receiver’s scrambler to the value learned in this way results in scrambler synchronization within 11 symbols.
13.3 Beta mode port operation 13.3.1 Transmit operations 13.3.1.1 Control transmission When requested to transmit a control token, the port may need to stretch its duration to ensure that when the control token is subsequently forwarded through ports operating at a lower speed, those ports have sufficient time to transmit at least one control character. Stretching the duration is performed by transmitting the corresponding control character repeatedly. This stretching is controlled by an effective speed parameter that is passed to the port along with the control token. The number of characters transmitted for each control token is equal to the ratio of the port operating speed and this speed parameter, as shown in Table 13-12. For each control character that is transmitted, the Beta port shall first determine the control symbol for that control token according to Table 13-1. This control symbol shall be scrambled according to 13.2.5.3 and coded according to 13.2.6.2, and the resulting control character shall be transmitted according to 13.2.7.
Copyright © 2008 IEEE. All rights reserved.
349
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 13-12—Control stretching formats Port operating speed
Effective speed S100
S100
C
S200
CC
S200
S400
S800 S1600 S3200
C
S400
CCCC
CC
C
S800
CCCCCCCC
CCCC
CC
C
S1600
CCCCCCCCCCCCCCCC
CCCCCCCC
CCCC
CC
S3200
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC CCCCCCCC CCCC CC
C C
NOTES 1—For any particular effective speed, a stretched sequence has constant duration at all port speeds, equal to the time taken to transmit a single character on a port operating at the effective speed. 2—C represents a control character.
13.3.1.2 Request transmission For each Beta port request, the port shall first determine the request symbol according to Table 13-2, Table 13-3, and Table 13-5. This symbol shall be scrambled according to 13.2.5.2 and coded according to 13.2.6.1, and the resulting data characters shall be transmitted according to 13.2.7. When the port is transmitting either a TRAINING or OPERATION configuration request signal and the data character to be transmitted is a D28.0 character, the port shall replace this character with a K28.5 special character. NOTE—The insertion of K28.5 special characters assists a remote receiver in establishing character synchronization with the transmitting port.
At least four consecutive request symbols shall be transmitted for any given configuration request, as an aid to robustness.
13.3.1.3 Packet transmission A packet may be preceded by a number of DATA_PREFIX control tokens. Packet transmission begins with either a speed code or, in the case of some S100 packets where no speed code exists, the first data byte. During packet transmission, the port may still be required to transmit some control tokens, e.g., to complete a packet prefix. These control tokens and the packet data are referred to collectively as the packet payload. When the packet speed is less than the port operating speed, other characters are transmitted during the packet along with the payload characters. These characters are referred to as padding characters. This process is illustrated in Figure 13-7. In contrast to DS ports, the port transmission speed remains constant for all packet speeds.
350
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Asynchronous Request = NONE_ODD Isochronous Request = ISOCH_EVEN Request Symbol = 10010xx0 Scrambled Request Symbol = 01101xx1 (assume scrambler state = 1111 1111) control token = DATA_PREFIX Scrambled Request Symbol = 01101001 (D22.4 after forcing bits F & G to 0)
Control Symbol = 1010 (assume rd < 0)
Data Character = 0110101101 (assuming rd < 0)
Scrambled Control Symbol = 0101 (assume scrambler state = 1111 1111) Control Character = 0011111000
packet prefix
data prefix
speed signal
packet
packet end
data
data prefix
Dx.y
payload character
Cz
Cz
padding character
packet end symbols
Cz
Dx.y
payload character
Figure 13-7—Structure of packet, packet delimiters, and request types, with examples of coding process 13.3.1.4 Speed signaling A speed code comprises a sequence of SPEEDa, SPEEDb, and SPEEDc control tokens and is transmitted during the packet prefix. The combination of transmitted SPEEDa, SPEEDb, and SPEEDc control tokens indicates the packet speed relative to the port operating speed. In addition, the use of a SPEEDa or SPEEDb token indicates that the packet format is Alpha or Beta, respectively (see 16.3.4.1). When required to transmit a speed code, the port shall generate a sequence of speed control tokens appropriate for the packet
Copyright © 2008 IEEE. All rights reserved.
351
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
speed according to Table 13-13. Each speed control token shall be coded according to 13.2.6.2 and scrambled according to 13.2.5.3.
Table 13-13—Speed code formats Port operating speed
Packet speed S100
S200
S400
S800
S1600 S3200
S100
Sx
S200
S c Sx
Sx
S400
S c Sc S x Sc
Sc Sx
Sx
S800
S c Sc S cS x S cS cS cS c
Sc Sc S x S c
S cS x
Sb
S1600
S c Sc S cS cS x S cS cS cS c Sc S cS cS cS c Sc Sc
Sc Sc S cS x S cS cS cS c
S cS cS x S c
S cS b
S3200
S c Sc S cS cS cS x S cS cS c Sc S cS cS cS c Sc Sc S c Sc S cS cS cS cS c Sc S cS cS cS cS c Sc S cS c
Sc Sc S cS cS x S cS cS c Sc Sc S cS cS cS c Sc S c
S cS cS c Sx S c Sc S cS c
S cS cS b S c S c Sb
Sb
80
40
20
10
2.5
Speed signal duration (ns)
Sb
5
NOTES 1—Sc represents the SPEEDc control token. 2—Sx represents the SPEEDa control token when the Alpha packet format is used and represents the SPEEDb control token when the Beta packet format is used.
For any particular packet speed, the speed signal has constant duration at all port speeds. At all packet speeds the number of speed tokens used at a particular port operating speed is equal to the number of symbols transmitted per byte of packet data at that port operating speed. NOTE—A speed code is not transmitted for a Alpha format S100 packet originated by a border node with a Alpha link or for a forwarded packet where the received packet has no speed code. See 16.3.4.4.
13.3.1.5 Payload transmission If the packet speed is less than the port operating speed, then data payload is padded with SPEEDc symbols. Each data byte shall be scrambled according to 13.2.5.1, and the scrambled data shall be coded according to 13.2.6.1. The resulting character shall be transmitted immediately before any SPEEDc control symbols. The port compares the value of the packet speed parameter with the port operating speed and determines the number of SPEEDc control symbols to be transmitted according to Table 13-14. The port shall generate the appropriate number of SPEEDc control symbols. These control symbols shall be scrambled according to 13.2.5.3 and coded according to 13.2.6.2, and the resulting control characters shall be transmitted contiguously following the data character. If the packet speed is less than the port speed, then any payload control symbols are stretched as described in 13.3.1.1.
352
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 13-14—Data padding formats Port operating speed
Packet speed S100
S200
S400
S800
S1600 S3200
S100
D
S200
DP
D
S400
DPPP
DP
D
S800
DPPPPPPP
DPPP
DP
D
S1600
DPPPPPPPPPPPPPPP
DPPPPPPP
DPPP
DP
D
S3200
DPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
DPPPPPPPPPPPPPPP
DPPPPPPP
DPPP
DP
D
1—For any particular packet speed, a padded sequence has constant duration at all port speeds. 2—D represents a payload data byte. 3—P represents a SPEEDc control symbol. 4—Table entries represent the information stream prior to scrambling and coding.
13.3.2 Receive operations 13.3.2.1 Port training When a Beta port is initially activated, the port shall initiate a training procedure. During this procedure, the port transmits a sequence of training symbols to the remote port. The remote port also begins the training procedure and transmits a sequence of training symbols. While receiving a training sequence, the port synchronizes itself with the received character stream. The port acquires bit synchronization and also determines the boundary between characters (i.e., character synchronization). The port also synchronizes its descrambler with the scrambler of the peer port’s transmitter.
13.3.2.1.1 Loss of synchronization detection procedure The port determines that it has lost synchronization with the received character stream by monitoring the validity of received characters. The port shall maintain a count of the number of invalid characters received. When an invalid character is received, this count shall be incremented, to a maximum value of four. When two consecutive valid characters are received, the count shall be decremented (to a minimum value of zero). If the count reaches four, then the port shall give a loss of synchronization indication. For loss of synchronization detection, an invalid character shall be any character that does not appear in the appropriate disparity column of Table 13-8, Table 13-9, or Table 13-10. In addition, while in the Receive state (i.e., during normal operation), the port receiver shall consider the TRAINING configuration request to be an invalid signal, which provides a means for a remote port to force the receiving port to enter the synchronization procedure.
13.3.2.1.2 Resynchronization procedure When the port is initially activated and when the port determines that synchronization has been lost, it shall transmit a TRAINING configuration request and attempt to resynchronize with the incoming character stream. The TRAINING configuration request is treated in the same way as an INVALID symbol by the remote port and, therefore, causes the remote port to enter the synchronization procedure. The port shall initially attempt to acquire character synchronization. To verify that character synchronization is complete, the port shall receive a valid comma character (i.e., a K28.5 special character) preceded by at least two valid request type characters (i.e., Dx.0 or Dx.4).
Copyright © 2008 IEEE. All rights reserved.
353
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTE—When a port first begins resynchronization, it may not necessarily be receiving training signals from the remote port. The requirement for a K28.5 special character to be preceded by two valid request type characters is necessary to ensure that incorrect character synchronization cannot occur when signals other than the TRAINING or OPERATION configuration requests are received.
Once character synchronization is complete, the port shall train its descrambler. The port shall verify that descrambler training has been successful by checking for at least SYNC_CHECK consecutive occurrences of a TRAINING configuration request or SYNC_CHECK consecutive occurrences of a OPERATION configuration request. SYNC_CHECK has value 17. If during this check an arbitration request type is received that indicates an isochronous request type of ISOCH_ODD and an asynchronous request type of reserved with the value 111 (11111xx0) or that indicates an isochronous request type of ISOCH_ODD and an asynchronous request type of NONE_ODD (10011xx0), then a polarity inversion between the two sides of the differential signal may have occurred in the cable plant. The port shall subsequently invert all received characters and restart this check. NOTE—It is not necessary for the port to repeat the character synchronization and descrambler training if the polarity is found to be inverted.
Upon achieving synchronization, the port shall begin to transmit an OPERATION configuration request. The port shall continue to transmit OPERATION configuration requests until it has received and successfully decoded at least 2*SYNC_CHECK consecutive OPERATION configuration requests since the beginning of sending an OPERATION configuration request, or has received a control symbol, or is deactivated by the connection management function.
13.3.2.2 Control reception When any valid control character is received, the port shall determine the received control symbol by decoding the control character according to 13.2.8 and descrambling the result of the decoding operation according to 13.2.10. To be a valid control character, a received character shall appear in Table 13-10. For more details on control character reception, see rx_control_decode() in Table 19-11 (in 19.3.2). When control symbols are received at the packet end or outside of a packet, the port shall determine the received control token according to Table 13-1. When a change on the received control token is detected (including the beginning of control token reception), the port shall indicate the first occurrence of the new control token to the arbitration state machine. The port shall not indicate subsequent contiguous occurrences of the same control token to the arbitration state machine. NOTE—This requirement is intended to ensure that isolated occurrences of a control token are never deleted by the port, while allowing redundant control symbols to be deleted when necessary to compensate for any difference between the local port clock and remote port clock frequencies.
If an invalid character is received during control token reception, the port shall maintain the previous control token indication.
13.3.2.3 Request type reception Characters representing request types shall be distinguished from characters representing packet data by the fact that they are received outside of packet boundaries. To be a valid request character, a received character shall belong to the set of Dx.0 and Dx.4 characters (x = 0, 1, ... 31) and appear in the appropriate column of Table 13-8 as determined by the running disparity at the start of reception of the character. The port shall decode all valid request characters according to 13.2.8 and descramble the result of the decoding operation according to 13.2.10. The request type shall be determined from Table 13-2, Table 13-3, and Table 13-5.
354
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Any difference between the frequencies of the remote port clock and local port clock will result in the local port occasionally needing to either insert or delete request indications. When a request type is inserted, it shall be equal to the previously indicated request type. A configuration request shall be recognized only if two consecutive identical configuration request symbols are received. (At least four consecutive identical symbols will have been transmitted.) This rule provides protection against bit errors that may cause an arbitration request to be converted to a configuration request. If an invalid character is received during request type reception, the port shall maintain the previous request type indication.
13.3.2.4 DATA_PREFIX reception All packets received by a port are preceded by a number of DATA_PREFIX symbols. The DATA_PREFIX symbol indicates the state of the remote source port’s running digital sum at the start of the packet. Because the receiving port is required to check the running disparity during packet reception, it is necessary for the receiving port to have correct knowledge of the running digital sum at the start of a packet. The running disparity should be updated at the start of each received packet as information held over from previously received characters may be incorrect due to errors in the received signals. When a DATA_PREFIX symbol is received, the port shall update the running disparity value to the value indicated by the DATA_PREFIX symbol.
13.3.2.5 Speed code determination A Beta port shall receive a speed code (if any) and indicate the speed of the subsequent packet to the arbitration state machine. This indication shall not be generated before a SPEEDa or SPEEDb token or a data byte has been received. Valid speed signals shall be used to determine the speed of the subsequent packet according to Table 13-15.
Table 13-15—Speed code decoding Received speed code
Port operating speed S100
S200
S400
S800
S1600
S3200
None
S100
S100
S100
S100
S100
S100
Sx
S100
S200
S400
S800
S1600
S3200
S cS x
—
S100
S200
S400
S800
S1600
S cS cS x S c
—
—
S100
S200
S400
S800
S cS cS cS x S cS cS c Sc
—
—
—
S100
S200
S400
S cS cS cS cS x S cS c Sc S cS cS cS cS c Sc S cS c
—
—
—
—
S100
S200
ScScScScScSxScScScScScScScScScScScScScS cS cS cS cS c Sc S cS cS cS cS c Sc S c
—
—
—
—
—
S100
1—Sc represents the SPEEDc control token. 2—Sx represents either a SPEEDa or a SPEEDb token.
Copyright © 2008 IEEE. All rights reserved.
355
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
A speed code shall be considered valid only if it meets the following criteria: a)
All speed tokens are received consecutively.
b)
The pattern of SPEEDc and SPEEDx (x = a or b) tokens is found in Table 13-15.
If an invalid speed code is detected, the port shall pass the packet to the arbitration state machine as an Alpha S100 packet in a hybrid bus and a Beta S100 packet in a B bus. However, if an invalid speed code is detected during the self-identify phase, the PHY shall initiate a new bus reset.
13.3.2.6 Payload reception All characters, whether control or data, received following a speed code or the first byte of data are considered part of the packet, until the packet end is received. The packet speed may be used to determine the padding format of the packet. The port shall consider the first character received in a padded sequence to be the payload character. During packet reception the port shall discard all padding characters and indicate only payload characters to the arbitration state machine. During packet reception, the port shall determine whether a received payload character is a valid data character or a valid control character. To be a valid data character, a received character shall appear in the appropriate column of Table 13-8 as determined by the running disparity at the start of reception of the character. To be a valid control character, a received character shall appear in Table 13-10. The port shall decode all valid data payload characters according to 13.2.8 and descramble the result of the decoding operation according to 13.2.10. If a valid control payload character is received, the port shall determine the received control token by decoding the control character according to 13.2.8 and descrambling the result of the decoding operation according to 13.2.10. The port shall consider the first control character in a padded sequence to be the payload character. The port shall determine the format of the padded sequence for the packet speed according to Table 13-12. The port shall check that the format of the packet data sequence (padded or not) agrees with the format indicated by Table 13-14 for the packet speed. If no speed signal is received prior to the packet, then the packet speed should be S100, and the port shall check that the padding format is correct for an S100 packet. If at any point during packet reception a valid data character is received at a time when the padding format for the packet speed requires a padding symbol to be received, then an error has occurred and the port shall not report that data to the arbitration state machine. If during packet reception the port receives a payload character that is neither a valid data character nor a valid control character, it shall indicate to the arbitration state machine that a data byte of value [0000 0000] was received. NOTE—A data character is considered as being in error only if the invalid character is in a payload position. Errors in padding positions are ignored.
Data reception ends when a packet end symbol is received.
356
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
13.3.2.7 Error reporting When the port detects a coding error, it shall increment the value of the port_error register, to a maximum value of 255. The port_error register shall be an 8-bit read-only PHY register. This register is intended for use by a single buswide diagnostic program and shall be cleared when read. The port takes no action based on the value of this register. A coding error shall be detected if a character is received that a)
Does not belong to the set of data characters nor to the set of control characters, or
b)
Has incorrect disparity, or
c)
Is a valid data character, but not Dx.0 or Dx.4, and occurs outside the bounds of a packet, or
d)
Is a valid payload character, but is not received in the correct payload position within a padded packet, or
e)
Is a valid padding character, but is not received in a correct padding position within a padded packet.
13.4 Beta port state machines The operation of the port operating in Beta mode is specified in terms of a transmit state machine and a receive state machine, together with C code specifying the actions to be taken on entry to each state. The C code variables used in the Beta port state machines are described in Table 13-16.
Table 13-16—C code variables used in Beta port state machines Function or variable name
Description
bportOn
Set to TRUE to instruct the Beta port to commence operating, set to FALSE to instruct the Beta port to cease operating
bportSyncOk
Port has achieved synchronization with peer port
powerReset
TRUE during power reset, goes FALSE at the end of power reset
rxSyncError
TRUE if receiver failed to complete synchronization
scramblerSync
SYNC_CHECK consecutive occurrences of TRAINING or OPERATION received
scramblerSyncError
TRUE if unexpected request type is received during scrambler synchronization
syncErrorSignal
Receiver error monitor has detected loss of synchronization
syncLostSignal
Receiver is in a resynchronization state
Copyright © 2008 IEEE. All rights reserved.
357
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
13.4.1 Port transmit state machine Figure 13-8 illustrates the port transmit state machine, and following the figure are descriptions applicable to this state machine. PTX0:Off txOffActions()
PTX1:Sync Lost
PTX3:Transmit
txSyncLostActions();
bportTransmitActions();
PTX2:Local Sync txSyncActions();
bportOn PTX0:PTX1
!syncLostSignal PTX1:PTX2 !bportOn PTX1:PTX0
syncLostSignal PTX2:PTX1
bportSyncOk PTX2:PTX3
!bportOn
PTX2:PTX0
powerReset !bportOn || syncLostSignal
PTX3:PTX0
Figure 13-8—Port transmit state machine
State PTX0: Off. The port is not transmitting. Transition PTX0:PTX1. The Beta port is activated by the connection management function setting bportOn to TRUE. The first action after being activated is for the port to attempt to synchronize with the connected port. State PTX1: Sync Lost. While in the PTX1: Sync Lost state, the port transmits a training request signal to the connected port. Transition PTX1:PTX2. This transition is made when the receiver signals that it has acquired synchronization with the connected port. Transition PTX1:PTX0. If the connection management function sets bportOn to FALSE, then the port returns to the PTX0: Off state. This transition may happen if the connection management function decides that training has failed by timing out.
358
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
State PTX2: Local Sync. The port receiver is synchronized with the connected port, and the port transmits an operation request signal to indicate that it wishes to commence normal operation. Transition PTX2:PTX0. The connection management function may still cause the port to transition to the PTX0: Off state from the PTX2: Local Sync state by setting bportOn to FALSE. Transition PTX2:PTX1. If the port receiver signals that it has lost synchronization with the connected port, the transmitter returns to the PTX1: Sync Lost state. Transition PTX2:PTX3. However, if the port receiver determines that the connected port has also acquired synchronization, then the transmitter transitions to the PTX3: Transmit state. State PTX3: Transmit. The PTX3: Transmit state is the normal operating state for the transmitter. Transition PTX3:PTX0. The port returns to the PTX0: Off state if synchronization is lost or if the connection management function sets bportOn to FALSE.
13.4.2 Port receive state machine Figure 13-9 illustrates the port receive state machine, and following the figure are descriptions applicable to this state machine.
PRX0:Off
PRX1:Resync1
PRX4:Receive
rxOffActions()
rxSyncLostActions();
bportReceiveActions();
PRX3:Local Sync rxSyncActions();
powerReset rxSyncError
bportOn PRX0:PRX1
PRX3:PRX1
PRX2: Resync2 scramblerSyncActions();
!bportOn PRX1:PRX0
bportOn PRX1:PRX2 !syncErrorSignal scramblerSyncError PRX2:PRX1
!bportOn
PRX3:PRX4 scramblerSync PRX2:PRX3
PRX2:PRX0
!bportOn
PRX3:PRX0
!bportOn || syncErrorSignal
PRX4:PRX0
Figure 13-9—Port receive state machine
Copyright © 2008 IEEE. All rights reserved.
359
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State PRX0: Off. The port is not required to receive or decode any signals. The syncLostSignal is set in PRX0: Off state to force the transmit port into the PTX0: Off state. Transition PRX0:PRX1. When the connection management function sets bportOn to TRUE, the port shall enter the PRX1: Resync1 state and attempt to acquire bit and character synchronization. State PRX1: Resync1. While in the PRX1: Resync1 state, the receiver is attempting to acquire bit and character synchronization. The receiver also requests that the transmitter sends a training request signal. Transition PRX1:PRX0. If the connection management function sets bportOn to FALSE, then the port returns to the PRX0: Off state. Transition PRX1:PRX2. Character synchronization is considered complete when a comma character (K28.5) has been received, immediately preceded by at least two consecutive valid request type characters (Dx.0 or Dx.4). State PRX2: Resync2. In the PRX2: Resync2 state, the receiver trains its descrambler using the scrambler samples contained in the incoming character stream. Transition PRX2:PRX0. If the connection management function sets bportOn to FALSE, then the port returns to the PRX0: Off state. Transition PRX2:PRX1. If any invalid character is received, the receiver returns to the start of the synchronization procedure. Transition PRX2:PRX3. After the descrambler is trained and at least SYNC_CHECK consecutive training or operation requests have been received, the receiver is synchronized. State PRX3: Local Sync. Once the receiver is synchronized, it requests that the transmitter send a operation request signal and waits for the attached port to indicate that it also is synchronized. Transition PRX3:PRX0. If the connection management function sets bportOn to FALSE, then the port returns to the PRX0: Off state. Transition PRX3:PRX1. If any invalid character or any unexpected signal is received, then the receiver returns to the start of the synchronization procedure. Transition PRX3:PRX4. Once the receiver has received an operation request from the attached transmitter, it begins normal operation. State PRX4: Receiver. The PRX4: Receiver state is the normal operating state. Transition PRX4:PRX0. If the connection management function sets bportOn to FALSE or if the receiver loses synchronization, then the port returns to the PRX0: Off state.
360
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
14. Connection management 14.1 Overview Connection management is performed by a node-level connection monitor for the PHY and a port connection manager for each port, together with the communications used between these modules and the services provided by these modules. The relationship and interfaces between connection management and other functions and layers are illustrated in Figure 14-1:
Link B PHY
port controller
request/grant, enable
LTP RX flags
send LTP PHY packets
control
request\ grant
pack et data
port status
config control
PHY-link interface
BOSS arbitration and control state machines
packet control PH Y packets
packet transmit/receive TX/RX s ymb ol, port statu s
TX/RX s ymb ol, enables TX/RX sy mbol
Port
to other ports
Port
Connection managemen t
DS-mode Beta- mod e T-mode functions functions functions
Low-power sig naling
Connection managemen t Low-power sig naling
TX /RX data signals, PMD control/status , arb/connect control/status (D S only)
PMD
DS-mode Beta- mod e T-mode functions functions functions
UTP -orGOF -orPOF -orBeta-only electrical -orBiling ual electrical -orDS-only electrical
TX /RX data signals, PMD control/status , arb/connect control/status (D S only)
PMD
UTP -orGOF -orPOF -orBeta-only electrical -orBiling ual electrical -orDS-only electrical
Figure 14-1—PHY master architecture (connection management in context)
Copyright © 2008 IEEE. All rights reserved.
361
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Each connection manager interacts with the corresponding PMD layers, the Beta port functions, the DSmode functions, and the repeater functions by appropriate shared variables.
14.2 Port characteristics The port is the device that controls the flow of data bits through the serial bus connections. The port’s connection manager detects the presence or absence of its peer port, establishes reliable communications with the peer port in the most suitable mode of signaling, and manages low-power modes of operation, i.e., sleep modes.
14.2.1 Requirements A T-mode capable port —
Shall detect and manage all connect and disconnect events.
—
Shall be capable of operating in T-mode at S800.
—
Shall be brought out to a media interface connector as specified in 12.4.4.
—
Shall support suspend, resume, standby, restore, and low-power connection signalling.
—
May be capable of operating in Beta mode at S100, S200, or S400.
—
When operating in T-mode, shall support all speeds of packets at or below S800 through the use of padding.
A Beta port —
Shall detect and manage all connect and disconnect events.
—
Shall be capable of operating in Beta mode in a speed range compatible with the transmission medium (see Table 14-1); the lowest transmission rate in the port’s speed range shall be no higher than the required speed, and the highest transmission rate shall be no higher than the maximum allowed speed.
—
May be brought out to a Beta-only socket or a bilingual socket and shall not be brought out to an Alpha socket.
—
When brought out to a bilingual socket, shall be capable of operating in DS mode at S100, S100 to S200, or S100 to S400.
—
When brought out to a socket other than a media interface connector as specified in 12.4.4, shall report PMD_AUTOCROSSOVER_SUPPORTED as FALSE.
—
Shall start up in Beta mode if Beta capable at a speed compatible with the Beta mode capability of the connected port and shall start up and run (i.e., set the operational speed) at the fastest such speed.
—
In Beta mode, shall support all speeds of packets at or below its operational speed through the use of padding.
—
Shall start up in DS mode if Beta mode is not possible, if both the port and the port to which it is connected are capable of DS operation, and if a dc connection exists between the ports.
—
Shall support suspend, resume, standby, restore, and low-power connection signalling.
A DS port may be capable of operating at S100, S100 to S200, or S100 to S400. No requirement exists for the maximum speed of a port operating in DS mode to be related to the speed of the port or any other port in Beta mode.
362
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 14-1—Media-dependent Beta mode speed requirements Transmission medium
Required speed
Maximum allowed speed
Beta copper connector
S400β
S3200β
Media interface connector as specified in 12.4.4 and UTP cable
S100β
S400β
PN connector and POF fiber
S100β
S200β
Duplex LC connector and 50 μm MMF
S400β
S3200β
NOTE—When a port is designed to be capable of supporting more than one medium, then the maximum speed may be set by writing to the maxPortSpeed register or other implementation-dependent mechanism.
14.2.2 Properties A Beta port may be connected directly to a suitable transceiver for long-haul connection (thus also providing dc isolation). A Beta port may use dc isolation when operating in Beta mode.
14.3 Functions, variables, and constants Connection management is specified as a port connection manager state machine for each port and a number of continuously running C code machines, some of which operate at node level. The C code functions and variables used in the port connection manager state machine are described in Table 14-2.
Table 14-2—Variables and functions used in port connection manager state machine Variable
Description
active
Indicates that the port is in the P2: Active state (set by state machine transitions to and from P2).
betaMode
Is set if the port has determined that it is operating in Beta mode; is unset otherwise (i.e., when operating in DS mode or when in the P0: Disconnected state). Is maintained as a read-only bit in the port register map.
bportSyncOk
Variable shared with the Beta port. Indicates that the port has byte and scrambler synchronization with its peer.
connected
Indicates that a connection is established with a peer port and (Beta mode only) operating speed negotiation is completed. Is maintained as a read-only bit in the port register map.
connectionUnreliable
PHY register bit. Is set to TRUE if the Beta mode speed negotiation fails or synchronization fails while establishing the operating mode and speed of a connection. Is reset by software after appropriate higher level action has been taken.
disableRequest
Requests transmission of DISABLE_NOTIFY at the end of the next packet.
disabled
PHY register bit. Is set to disable a port under software control, and indicates that the port is in the P6: Disabled state.
Copyright © 2008 IEEE. All rights reserved.
363
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 14-2—Variables and functions used in port connection manager state machine (continued) Variable
Description
doStandby
Is true when the port has been commanded to be a standby initiator.
forceDisconnect
Is true to force disconnect and retest of a port after detecting a loop during reset.
inStandby
Indicates the port is in the P7: Standby Initiator, P8: Standby Target, P9: Standby, or P10: Restore state.
loopDisabled
Indicates the port is in the P12: Loop Disabled state.
loopToDetect
Is true during reset up to S1: Self-ID Grant or S2: Self-ID Receive state. (See Figure 16-18.)
receiveOk
In DS mode, indicates the reception of a debounced TpBias signal. In Beta mode, indicates the reception of a continuous electrically valid signal. Is set to FALSE during the time that only connection tones are detected in Beta mode. Is maintained as a read-only bit in the port register map (supersedes the Bias bit).
restore
Indicates that the port is restoring. Also causes a port in standby to restore.
resume
Indicates that the port is resuming. Also causes a suspended port to resume.
resumeFault
Is set when the peer port fails to complete resume.
rxDisabled
Indicates the reception of a DISABLE_NOTIFY token from the peer port.
rxStandb
Indicates the reception of a STANDBY token from the peer port.
rxSuspend
Indicates the reception of a SUSPEND token from the peer port.
signaled
Indicates the transmission of a DISABLE_NOTIFY, SUSPEND, or STANDBY token.
standbyFault
Is set when the peer port fails to complete standby.
suspendRequest
Requests the transmission of a SUSPEND token at the end of the next packet and/or indicates that the port is suspending.
suspendFault
Is set when the peer port fails to complete suspend.
tPort802Mode
Is true when Auto-Negotiation has selected IEEE 802.3 higher layers.
untested
Indicates the port is connected, but untested.
untestedState
Indicates the port is in the P11: Untested state.
The timing constants and related parameters used in the connection management descriptions are defined in Table 14-3.
Table 14-3—Connection management constants Timing constant BIAS_FILTER_TIME
364
Minimum
Maximum
41.6 μs
52.1 μs
Comment Time on a DS-capable port to filter biasDetect upon the detection of TpBias before updating the PHY register ReceiveOk bit (~4096/BASE_RATE).
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 14-3—Connection management constants (continued) Timing constant
Minimum
Maximum 7
COLLISION_LIMIT
Comment Number of times a collision condition occurs to conclude that a loop exists.
330 ms
350 ms
Connection debounce time.
DISCONNECTED_TONE_ INTERVAL
42.66 ms
48 ms
TONE_DURATION * 4 * TONE_INTERVAL (2**22/BASE_RATE).
MAX_OCCUPANCY_TIME
83.975 μs
83.993 μs
CONNECT_TIMEOUT
4
NUM_OF_TRIES
PORT_ENABLE_TIME
5.3 ms
RECEIVE_OK_HANDSHAKE
RECEIVER_INIT_TIME
RESET_DETECT
80.0 ms
Number of tries at toning before switching to trying TpBias. 1 ms
Time necessary for TpBias output to become valid when driven high. The minimum value is implementation-dependent and may incorporate other design timing requirements for port resumption.
16 ms
When used to detect a fault during a suspend or resume handshake on a port operating in DS mode, either the time a suspend initiator waits for the suspend target to remove bias (measured from the transmission of TX_SUSPEND) before a suspend fault exists or the time a resume initiator waits for the resume target to assert bias (measured from the generation of TpBias by the resume initiator) before a resume fault exists. Also the time a suspend target waits, measured from the time it drives TpBias low, before it suspends. Ports operating in Beta mode may also use this timing value instead of values based on Beta mode synchronization time.
1 ms
Time from first receipt of signal for a receiver to be operating within the BER objective of 10–12.
85.3 ms 65
RESUME_CHECKS
The duration of the maximum occupancy timer (the maximum time that the bus is held while performing loop-free build to allow a peer connection to issue a short bus reset) (~8256/BASE_RATE).
Time for an active port to confirm a reset signal. DISCONNECTED_TONE_INTERVAL/TONE_DURA TION + 1, the number of checks that are made
between connection tone intervals. SPEEDCODE_BIT_INTERVAL
1.998 ms
2.013 ms
TONE_DURATION * 3, the time between the end
of one tone position and the start of the next. SYNCHRONIZATION_LENGTH
16 384
(Maximum number of transmitted bits for scrambler synchronization + byte synchronization rounded up to a power of two). Time to allow a test value to be returned as a loop test symbol (LTS) (LONG_BOSS_RESTART_TIME/2).
TEST_INTERVAL
41.66 μs
41.67 μs
TONE_DURATION
666 μs
678 μs
TONE_GAP
8
2**16/BASE_RATE. TONE_INTERVAL/2, the number of tone units in
the gap before the start bit.
Copyright © 2008 IEEE. All rights reserved.
365
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 14-3—Connection management constants (continued) Timing constant
Minimum
Maximum 16
TONE_INTERVAL
Comment The number of tone units in a tone interval.
1.6 s
1.8 s
0.96 ms
1.26 ms
Time to wait for a SUSPEND, DISABLE or STANDBY token to propagate to a peer T-mode port.
TPORT_MIN_SUSPEND_TIME
96 ms
126 ms
Time to wait during entry to suspend, standby, or loop disabled to ensure a minimum time before exiting these states.
TPORT_SUSPEND_HANDSHAKE
1.6 s
1.8 s
TMODE_DISCONNECT_TIMEOUT
TPORT_MAX_LATENCY
Timeout for the detection of a disconnection after loss of synchronization causing entry to suspend on a T-mode port.
When used to detect a fault during a suspend or resume handshake on a port operating in T-mode, either the time a suspend initiator waits for the suspend target to remove normal signaling (measured from the transmission of TX_SUSPEND) before a suspend fault exists or the time a resume initiator waits for the resume target to resume signaling (measured from the command to resume signaling by the resume initiator) before a resume fault exists,
NOTE—The values of TEST_INTERVAL and COLLISION_LIMIT are chosen to ensure that the loop testing will complete much more than a test interval before the MAX_OCCUPANCY_TIME timer expires. This ensures that the final loop test packet (LTP) with ATTACH_IN_PROGRESS is seen by all controlling nodes on other buses before an attach is completed.
14.4 Node-level port controller One instantiation of the node-level port controller shall occur in a PHY. Its behavior is specified as continuously running C code and maintains a record of whether the node is an isolated or border node. It also contains routines called by the individual port connection managers providing a global view of the connection information for the other ports. Finally, it provides bias debounce for each port using a shared timer. It shares (by read-only access) one element of each of the array variables active[NPORT], connected[NPORT], disabled[NPORT], suspend[NPORT], resume[NPORT], bias[NPORT], proxy[NPORT], restore[NPORT], and betaMode[NPORT] and the array constants BETA_MODE_ ONLY_PORT[NPORT] and T_MODE_PORT[NPORT] with the respective port connection managers. Note that, in the C code relating to the port controller, these variables are subscripted; but in the C code relating to the individual port connection manager, the variables have the same name but are not subscripted.
14.5 Port connection manager state machine The port connection manager state machine operates independently for each port. A port may be capable of operation only in DS mode (4.2, 4.3, and 9.2), only in Beta mode (Clause 13), only in T-mode (Clause 20), in both DS mode and Beta mode (i.e., a bilingual port), or in both Beta mode and T-mode. In all cases, while a port is in the active state, its arbitration, data transmission, reception, and repeat behaviors are specified by the state machines in Clause 16. When a PHY port is in any state other than active, it is permissible for it to lower its power consumption; the only functional component of a PHY that shall be active in all states is the physical connection detect circuitry or toning circuitry, as appropriate. Figure 14-2 illustrates the port connection manager state machine, and following the figure are descriptions applicable to this state machine.
366
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
P11: Untested P0: Disconnected P0:P11
P2: Active
untestedActions() connected && betaMode
!loopDisabled
P11:P2
connectionUnreliable = FALSE;
active = TRUE;
P6:P11
P12: Loop Disabled loopDisabledActions() loopDisabled
P11:P12
(betaMode && loopToDetect && !bportSyncOk)||forceDisconnect P2:P11
!connected
P12:P0
loopDisabled = FALSE;
connected && (!loopDisabled || receiveOk) P12:P11 loopDisabled = FALSE;
active = FALSE; forceDisconnect = TRUE;
P1: Resuming resumeActions()
P0:P1
connected && !betaMode connectionUnreliable = FALSE;
P5: Suspended P13: 802Mode
suspendedActions() resumeFault
P1:P5 P1:P2
tPort802Mode P0:P13
connected && (resume || (!suspendFault && receiveOk))
!tPort802Mode P13:P0
!resumeFault active = TRUE;
P5:P1 resumeFault = suspendFault = FALSE;
!connected
P3: Suspend Initiator
P5:P0
suspendInitiatorAction
suspendFault = FALSE; resumeFault = FALSE;
P3:P5 !receiveOk && suspendFault
P5:P5
suspendFault = FALSE;
((!rxOk&&!suspendRequest&&!disableRequest)|| (suspendRequest && signaled))&& !(betaMode&&loopToDetect&&!bportSyncOk)&& !forceDisconnect P2:P3 active = FALSE;
P4: Suspend Target Power reset
suspendTargetActions()
portPower Reset()
P4:P5
P6: Disabled
(rxOk && ((portRArb == SUSPEND) || (portRArb==DISABLE_NOTIFY)))&&!forceDisconnect P2:P4 active = FALSE;
disabledActions() connected&&!disabled&& !betaMode && !802Mode
P6:P5
!disabled&&betaMode&&!802Mode P6:P11 connected = TRUE; !connected && !disabled && !betaMode && !802Mode
P6:P0
P6:P13
802Mode
(disabled && (!802Mode || hardDisable)) || (disableRequest && signaled) All:P6 active = FALSE; resumeFault = suspendFault = standbyFault = loopDisabled = FALSE;
P10: Restoring restoreActions() !connected
P10:P0
connected
P10:P2
active = TRUE;
P7: Standby Initiator standbyInitiatorActions()
P9: Standby standbyActions() connected && (restore || (!standbyFault && receiveOk)) P9:P10 standbyFault = FALSE;
P7:P9
rxOk&&doStandby&&signaled&&!forceDisconnect P2:P7 active = FALSE;
P8: Standby Target standbyTargetActions() P8:P9
!connected
P9:P0
standbyFault = inStandby = FALSE;
rxOk&&(portRArb==STANDBY)&&!forceDisconnect P2:P8 active = FALSE;
Figure 14-2—Port connection manager state machine
Copyright © 2008 IEEE. All rights reserved.
367
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Power reset. A power reset of the PHY initializes each port as disconnected. Transition All:P6. This transition applies to a port in any of the P states (other than P6) and takes priority over other available transitions. The local link may immediately disable a port in any state other than P13: 802Mode by setting the disabled bit to 1. A port in P13 shall remain in P13 until the tPort802Mode flag is cleared or both the disabled and hardDisable flags are set, and then the port shall take the transition into P6 if the disabled flag is set to 1. This transition may also be caused by a remote command packet, in which case the port, if active, shall transmit DISABLE_NOTIFY before the port is disabled. State P0: Disconnected. The generation of TpBias is disabled (DS mode), or continuous transmission is stopped (Beta mode); and the outputs are in a high-impedance state. The PHY may place most of the port’s circuitry in a low-power consumption state. A port shall transmit tones, and its signal detect and (if DS capable) connection detect mechanism shall be active even if other components of the PHY port are in a low-power state. If the port is a T_MODE_CAPABLE port and toning indicates that its peer PHY port is physically connected, it engages in Auto-Negotiation with the peer port to select either T-mode operation or 802_mode operation. Transition P0:P11. When toning signals that a port’s peer PHY port is physically connected, the PHY port transitions to the P11: Untested state. Transition P0:P13. When the result of Auto-Negotiation is that the port is to operate in 802_mode, the port transitions to the P13: 802Mode state. It appears as a disconnected port for the purpose of IEEE 1394 operation. State P1: Resuming. In Beta mode, the PHY commences transmission at the operating speed and attempts to synchronize its receiver. The PHY port tests both the connection status and the presence of receiveOk to determine whether normal operations may be resumed. If the port is connected, receiveOk is set, and no other ports are active, the PHY waits seven RESET_DETECT intervals before any state transitions. Otherwise, in the case of a border node with one or more active ports, the PHY waits three RESET_DETECT intervals before any state transitions. A detected bus reset overrides either of these waits; otherwise, when the wait elapses, the PHY initiates a bus reset. Transition P1:P2. If the PHY port did not fault during the resume handshake, it waits for bus reset to start and then transitions to the P2: Active state. Transition P1:P5. A resuming PHY port that faults during the resume handshake transitions to the P5: Suspended state. State P2: Active. The PHY port is fully operational and capable of transmitting or receiving and of repeating arbitration signals or clocked data. While the port remains active, it shall comply with the cable arbitration states specified in Clause 16. Transition P2:P3. Upon the loss of receiveOk or the receipt of a PHY remote command packet that sets the suspend variable to 1, the PHY port leaves the P2: Active state to start functioning as a suspend initiator. A loss of receiveOk is usually the result of a physical disconnection or the loss of power to the connected peer PHY port. If the transition is the result of a remote command packet, the PHY transmits a remote confirmation packet with the ok bit set to 1. In the meantime, the suspend initiator has signaled SUSPEND to its connected peer PHY. Transition P2:P4. If an active port observes an DISABLE_NOTIFY or SUSPEND signal, it becomes a suspend target and leaves the P2: Active state. Transition P2:P7. Upon the receipt of a PHY remote command packet that sets the doStandby variable to 1, the PHY port leaves the P2: Active state to start functioning as a standby initiator.
368
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition P2:P8. If an active port observes a STANDBY signal, it becomes a standby target and leaves the P2: Active state. State P3: Suspend Initiator. A suspend initiator waits for receiveOk to be zero. If RECEIVE_OK_ HANDSHAKE elapses and the connected peer PHY has not either driven TpBias low (DS mode) or ceased sending a valid signal (Beta mode), then the suspend operation has failed and the fault bit is set to 1. In either case, the suspend initiator first drives TpBias low for RECEIVE_OK_HANDSHAKE time if in DS mode and then places all outputs in a high-impedance state. When in T-mode, the suspend initiator ceases signaling after TPORT_MAX_LATENCY, waits for up to TPORT_SUSPEND_HANDSHAKE for the peer to withdraw signaling (setting the fault bit if the peer signaling is not withdrawn within this time), and waits for TPORT_MIN_SUSPEND_TIME to ensure that the port is not resumed immediately after being placed in the suspended state. Transition P3:P5. Upon completion of the actions associated with this state, the PHY port unconditionally transitions to the P5: Suspended state. State P4: Suspend Target. A suspend target sets the suspend variable for all the other active ports. This step in turn causes the other active ports to propagate the SUSPEND signal. In the meantime, the suspend target (if in DS mode) drives its TpBias outputs below 0.1 V or (if in Beta mode) ceases sending a valid signal in order to signal the suspend initiator that SUSPEND was detected. If in DS mode, the node waits a RECEIVE_OK_HANDSHAKE time to allow the connected peer PHY time to drive TpBias low, and then the suspend target disables the generation of TpBias. It then places the outputs in a high-impedance state. When in T-mode, the suspend target ceases signaling, waits for up to TPORT_SUSPEND_HANDSHAKE for the peer to withdraw signaling, and waits for TPORT_MIN_SUSPEND_TIME to ensure that the port is not resumed immediately after being placed in the suspended state. Transition P4:P5. Upon completion of the actions associated with the P4: Suspend Target state, the PHY port unconditionally transitions to the P5: Suspended state. State P5: Suspended. The PHY may place most of the port’s circuitry in a low-power consumption state. The port shall maintain connectivity status by (Beta mode) transmitting tones and using its signal detect circuitry or (DS mode) using its connection detect circuit even if other components of the PHY port are in a low-power state. Transition P5:P0. A suspended PHY port that loses its physical connection to its peer PHY port transitions to the P0: Disconnected state. Transition P5:P1. Either of two conditions cause a suspended PHY port to transition to the P1: Resuming state:
—
A nonzero value for the port’s resume variable.
—
The detection of receiveOk if the port’s suspendFault variable is zero.
A port’s resume variable may be set indirectly as the result of the resumption of other PHY ports. Transition P5:P5. If the port entered the P5: Suspended state in a faulted condition (i.e., receiveOk was still present), the fault is cleared if and when receiveOk is removed by the peer PHY. State P6: Disabled. While the port is in the P6: Disabled state, the PHY may place most of the port’s circuitry in a low-power consumption state. If the hardDisable flag is FALSE and the port was operating in DS mode, the connect detect circuit shall be active even if other components of the PHY port are in a lowpower state. If the hardDisable flag is FALSE and the port was operating in Beta mode, then it shall maintain connectivity information by toning. If the hardDisable flag is TRUE, then the port shall not engage in toning. If the port is T-mode capable and toning indicates that its peer PHY port is physically
Copyright © 2008 IEEE. All rights reserved.
369
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
connected, it engages in Auto-Negotiation with the peer port to select either T-mode operation or 802_mode operation. Transition P6:P0. If the disabled bit is zero and the PHY port is not physically connected to its peer PHY port, it transitions to the P0: Disconnected state. Transition P6:P5. If the disabled bit is zero and the PHY port is connected and operating in DS mode, it transitions to the P5: Suspended state. Transition P6:P11. If the disabled bit is zero and the PHY port is connected and operating in Beta mode, it transitions to the P11: Untested state. Transition P6:P13. If the result of Auto-Negotiation indicates that the port is to operate in 802_mode, it transitions to the P13: 802Mode state, regardless of the setting of the disabled bit. Transition P7:P9. Upon completion of the actions associated with the P7: Standby Initiator state, the PHY port unconditionally transitions to the P9: Standby state. State P7: Standby Initiator. A standby initiator waits for receiveOk to be zero. If RECEIVE_OK_HANDSHAKE elapses and the connected peer PHY has not ceased sending a valid signal, the standby operation has faulted and the standbyFault bit is set to 1. As soon as either receiveOk goes to zero or RECEIVE_OK_HANDSHAKE elapses, the standby initiator places all outputs in a highimpedance state. When in T-mode, the standby initiator ceases signaling after TPORT_MAX_LATENCY, waits for up to TPORT_SUSPEND_HANDSHAKE for the peer to withdraw signaling (setting the fault bit if the peer signaling is not withdrawn within this time), and waits for TPORT_MIN_SUSPEND_TIME to ensure that the port is not restored immediately after being placed in the suspended state. State P8: Standby Target. A standby target sets the proxy flag to indicate that it will proxy for the peer node. It ceases sending a valid signal in order to signal the standby initiator that STANDBY was detected. Then it places the outputs in a high-impedance state. When in T-mode, the standby target ceases signaling, waits for up to TPORT_SUSPEND_HANDSHAKE for the peer to withdraw signaling, and waits for TPORT_MIN_SUSPEND_TIME to ensure that the port is not restored immediately after being placed in standby. Transition P8:P9. Upon completion of the actions associated with the P8: Standby Target state, the PHY port unconditionally transitions to the P9: Standby state. State P9: Standby. The PHY may place most of the port’s circuitry in a low-power consumption state. The port shall maintain connectivity status by (Beta mode) transmitting tones and using its signal detect circuitry or (DS mode) using its connection detect circuit even if other components of the PHY port are in a lowpower state. Transition P9:P0. A PHY port in the P9: Standby state that loses its physical connection to its peer PHY port transitions to the P0: Disconnected state. Transition P9:P10. Either of two conditions causes a PHY port in the P9: Standby state to transition to the P10: Restoring state:
—
A nonzero value for the port’s restore variable.
— The detection of receiveOk if the port’s standbyFault variable is zero as a result of failure to complete the previous suspend handshake. A port’s restore variable may be set indirectly as the result of the resumption of other PHY ports.
370
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
State P10: Restoring. The PHY commences transmission at the operating speed and attempts to synchronize its receiver. The PHY port tests both the connection status and the presence of receiveOk to determine whether normal operations may be restored. If proxy is set, then the PHY arbitrates for the bus and sends a restore configuration packet on the port. When the peer PHY indicates that it is in phase (i.e., by receiving appropriate arbitration requests), the restore operation is complete. If proxy is not set, then the PHY (necessarily a leaf node) awaits reception of the configuration packet and sets its phase variables appropriately. Transition P10:P2. If the PHY port did not fault during the restore handshake, it transitions to the P2: Active state. Transition P10:P0. A restoring PHY port that faults during the restore handshake ceases transmission on the port, waits for an apparent disconnection to be detected, and then transitions to the P0: Disconnected state. State P11: Untested. In the P11: Untested state, the port is a candidate for testing to ensure that a loop would not be formed by completing the connection. The port starts up, synchronizes with its peer, and exchanges LTSs with its peer. It also transmits an ATTACH_REQUEST when required to do so by the node-level loop-free build mechanism and reports any incoming ATTACH_REQUEST. It completes any attachment by waiting for or generating a reset as appropriate. Transition P11:P2. On completion of an attachment, the port is marked as active. Transition P11:P12. If the node-level loop-free build mechanism determines that completing the connection would result in a loop or if synchronization is lost during the loop-free build process (untestedFault), then the port transitions to the P12: Loop Disabled state. State P12: Loop Disabled. The port is disabled, but continues to tone (Beta mode), to send LTP signals (T-mode), or to use its signal detect circuitry (DS mode) to maintain connectivity status. A port remains in this state until a bus reset is detected, a resume signal is received from the peer port, or a disconnection is detected. Transition P12:P11. A port in the P12: Loop Disabled state transitions to the P11: Untested state when a bus reset is detected or a resume signal is received from the peer port. Transition P12:P0. A port in the P12: Loop Disabled state transitions to the P0: Disconnected state when disconnection is detected. State P13: 802Mode. A port in the P13: 802Mode state appears as a disconnected port for IEEE 1394 operations. The disabled bit has no effect when the port is in the P13: 802Mode state unless the hardDisabled bit is also set. Transition P13:P0. Aport in the P13: 802Mode state transitions to the P0: Disconnected state when 802_mode operations cease.
14.6 Standby Standby is a term used to described a low-energy-consumption mode of operation for a port. Standby is a feature of Beta mode operation only. If a node has only one active port, then the connection on this port can be placed into standby; and, while the connection is in standby, the node does not participate in normal bus activity. Other nodes on the bus of which the node is a member are not aware of any status change of the node. A bus reset does not occur as part of entering or restoring from standby. The node is designated the
Copyright © 2008 IEEE. All rights reserved.
371
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
nephew, and its peer node the uncle. The uncle’s peer port is also placed in standby. Should a bus reset occur while the connection is in standby, the uncle node proxies a self-ID packet on behalf of the nephew node.
14.6.1 Nephew node characteristics A port shall enter into standby and the local node become a nephew when the port receives a standby packet containing the node_ID of the local node unless the local node is root, it has no active port, it has more than one connected port, it has an Alpha link, its enableStandby flag is zero, or the one active port is not operating in Beta mode. In any of these exception cases, the command shall be rejected. A node should not command another node to enter standby if the candidate node is performing bus management functions (e.g., bus manager, IRM, cycle master). A write to the ibr register on a nephew shall be ignored (the link is not able to initiate a bus reset). A port in standby on a nephew node shall restore from standby either on receipt of any bus request from the local link or on detecting a restore tone. It shall transmit a PH_Event.indication of PH_RESTORE_NO_ RESET to the link and shall establish synchronization with the uncle port. When a nephew port restores from standby, the time from the receipt of the link request or the restore tone until the port is ready to receive a restore packet shall not exceed 3 ms. The PHY shall assume (possibly incorrectly) a bus phase and, as soon as synchronization is achieved, shall transmit NONE_* requests of this phase on the port. A restoring port becomes active after receiving the following information from the first received restore packet: a)
Node ID
b)
Gap count
c)
Gap count reset disable status
d)
Bus phase
e)
Reset notify (bus reset occurred while the port was in standby)
The PHY shall update its internal values and flags with this information, except that if the reset notify (N) bit is not set, then the PHY shall not update its local copy of Node ID, but shall continue to use the previously determined value. The PHY shall not repeat this packet on the interface between the PHY and link or between the PHY that is integrated into a link (PIL) and fan-out PHY (FOP). As soon as the PHY has received the restore packet, it shall take control of the bus and transmit a S100 Beta mode null packet (DATA_PREFIX symbols). If the link or PIL interface is active, the PHY shall wait until it has completed the transfer of the status information to the attached link or PIL. It shall then terminate the null packet by performing the normal BOSS actions for end of subaction. A multiport node with one connected port in standby shall restore that port followed by a bus reset if it detects a new connection on any of its other ports.
14.6.2 Uncle node characteristics A PHY shall store sufficient information from each self-identification sequence for each port to allow it to proxy the self-ID packet for a nephew PHY attached to that port on a subsequent bus reset. When the node detects a standby symbol on a port, it assumes the role of uncle. It shall put the port into standby and shall proxy the self-ID packet of the nephew node on the occurrence of any bus reset that occurs while the port is in standby. A uncle node shall restore the nephew (i.e., assert a resume tone to the nephew) when it receives a Restore PHY command packet with the node_ID of the uncle node and the port address of the port connected to the nephew node or when it detects a restore tone from the nephew. NOTE—If errors occur in a self-identification sequence, then a candidate uncle node may not be able to store appropriate information to allow it to proxy. Software on any node that may invoke the standby mechanism should verify that each received self-identification sequence is valid and, if not valid, cause a bus reset.
372
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
When either detecting or generating a restore tone from or to a nephew node, the uncle node shall establish synchronization on the port connected to the nephew. As soon as synchronization is established, the uncle shall forward its favorite request to the nephew. As soon as synchronization is established, the uncle shall arbitrate for the bus and, when granted, shall generate a Restore PHY command packet, which it sends only to the nephew, and send a null packet to all active ports and the local link. The Restore PHY packet shall be terminated with DATA_END symbols to allow the nephew to assume the role of BOSS. It shall then mark the port as active. The uncle node shall service only one restoring nephew leaf at a time.
14.7 Loop prevention This standard provides a mechanism to allow the bus to continue to operate in the presence of physical loops in the bus topology. The mechanism works by not allowing connections to become active if activating the connection would create a loop. This mechanism is called a loop-free build because the topology is built one connection at a time. When a connection is made on a port, that port completes speed negotiation and training. After a port becomes trained, it is placed in the Untested state. A node with ports in the Untested state shall select one of its untested ports to become the test port. The node performs the loop test procedure on the test port to determine whether enabling the port will create a loop. If the node determines that enabling that port will not create loop, it places the port in the Active state. Otherwise, it places the port in the Loop Disabled state. Each node on a bus shall select from its untested ports a port to be tested; however, the loop test may be run on only one port on a bus at a time. To exclude other ports on the same bus from loop testing, a node wins arbitration to take control of the bus before testing for a loop. A node that has won arbitration to run a loop test is known as the controlling node; and, while it has control of the bus, it is the only node on that bus that may cause a port on the bus to be tested. To test for a loop, the controlling node sends a loop test packet (LTP) (see 16.3.3.5) on the active bus and compares the contents of the LTP with the LTPs of the LTS that is received on the port being tested. If they do not match, then a loop cannot exist and the port can be enabled. If they do match, the test is repeated several times with new test values to see if the match was due to a loop or if the match was just coincidental. After a number of trials, if the match persists, then a potential loop conditions exists and the port is placed in the Loop Disabled state; and the node may then begin testing other ports in the Untested state if any exist. The loop test procedure includes mechanisms to introduce asymmetry and prevent multiple connections from activating at the same time if a loop could result. For example, in Figure 14-3, if node A1 enabled its connection to node B1 at the same time as node B2 enabled its connection to node A2, then a loop would be created. This situation is prevented by creating a notion of dominance (i.e., the process of establishing dominance is described in 14.7.7). A node is not allowed to complete a connection to another node unless it is dominant over the other node. All nodes on a bus share the same level of dominance. In the figure, if node A1 is dominant to node B1 and able to complete a connection, then node A2 will be dominant over node B2 and prevent node B2 from trying to make a connection.
14.7.1 Test port Each node that has ports in the Untested state shall select one of the ports to be test port. The method of selecting the port is described in 14.7.7. When a test port is selected, the node shall arbitrate for control of the bus so that the loop-free build algorithm can be run on that port. Any node with an untested port can have a test port; but, on any single bus, only the test port on the controlling node is actually being tested.
Copyright © 2008 IEEE. All rights reserved.
373
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Subnet A Test value = 21 A1 (21)
controlling Node for subnet A
Subnet B Test value = 12
A1 connection to B1 allowed
B1 (12)
untested connections A2 (21)
B2 (12)
controlling Node for subnet A
B2 connection to A2 blocked
Figure 14-3—Example of dominant subnets 14.7.2 Loop test data (LTD) The LTD is an 8-bit value that is used in both the LTPs and the LTSs. The test data consists of a mode (M) bit, a 1-bit generation number (G), and a 6-bit test_value number. The LTD is used in the LTP that is sent on the bus by the controlling node and in the LTS that is sent on all ports that are in the Untested state. The LTD allows a node to determine whether activating a connection will create a loop (i.e., LTD in transmitted LTP is the same as the LTD in a received LTS) and to establish asymmetry in the protocol so that multiple connections will not be simultaneously activated to create a loop.
14.7.2.1 M bit The M bit has two states: ATTACH_IN_PROGRESS and TEST. A node shall set the M bit to the ATTACH_IN_ PROGRESS state only if it receives a LTP with this mode set or if the node is the controlling node and it has determined that placing the test port in the Active state will not create a loop. The M bit shall be set to TEST on power on, by receipt of a bus reset, by receipt of a LTP with the mode set to TEST, or by receipt of any non-LTP packet. If a node is testing a port and receives an LTS with the mode set to ATTACH_IN_PROGRESS, this event is an indication that a connection is about to be made active on the subnet at the other end of the connection that is being tested. If the controlling node continues with the test and completes a connection, then it is possible that this will result in two connections between the same pair of subnets and this cannot be allowed. For this reason, a node shall select a port to be the test port if the mode of the LTS being received on that port is ATTACH_IN_PROGRESS. Additionally, if an LTS is received on the test port with the mode set to ATTACH_IN_PROGRESS, then testing of that port shall be abandoned and no attach shall be attempted on the port as long as the mode of the received LTS is ATTACH_IN_PROGRESS.
14.7.2.2 G bit The G bit provides a simple way to ensure that consecutive test_value numbers chosen by the controlling node are not the same. Rather than have the controlling node continue to select test_value numbers until they are different, the node may simply select a random new test_value number and complement the G bit.
374
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The purpose of providing uniqueness for the consecutive LTD is that it accelerates the test process. Because the consecutive values are known to be unique, the controlling node can detect a collision without waiting for a fixed amount of time to ensure that the new test value has propagated through the network. Because it is guaranteed that the new LTD is different from the old LTD, the collision can be signaled as soon as the received LTS matches the value in the holding register (HR) (see 14.7.3). An implementation may have a 7-bit test_value number with no G bit as long as the implementation guarantees that consecutive test_value numbers differ by at least 1 bit.
14.7.2.3 test_value number The test_value number is a 6-bit (optionally 7-bit) value that is used to establish asymmetry in the loop test algorithm. The test_value number is changed by the controlling node when it determines that the LTD (all 8 bits) in the HR (see 14.7.3) matches the LTD in the LTS being received on the test port. The 6- or 7-bit test_value number in the LTD is generated by a random or pseudo-random number generator. If a pseudo-random number generator is used, it should contain at least 32 bits. The generator should run continuously while power is present on the PHY. While the PHY in is a low-power mode, the generator may change at a reduced rate. When a port is active or untested, the generator should run at a rate that is greater than or equal to the maximum symbol rate supported by the PHY.
14.7.3 Holding register (HR) When an LTP is received, the LTD in the LTP is copied to an 8-bit HR on the node. When a node sends an LTP, it uses the current values in the HR as the LTD in the LTP. The values in the HR are also used in the LTS that is being sent on each of the untested ports on a node. When a node is the controlling node, it may cause the values in the HR to change when a collision is detected or when the loop test is complete and a port is enabled. For a collision, the HR selects a new pseudo-random number for the test_value and complements the state of the G bit. These new values are then sent in a new LTP and in the LTS from the node. When a node is first powered up, the HR should be initialized with a random number chosen after the PHY completes its power-up sequence. The M bit shall be set to TEST.
14.7.4 Maximum occupancy timer The maximum occupancy timer limits the length of time that the controlling node has control of the bus. It is started when a node becomes the controlling node and runs as long as the node is holding the bus to run a test or complete a connection. Its duration shall be MAX_OCCUPANCY_TIME.
14.7.5 Loop test symbol (LTS) After a port becomes synchronized, it may begin to send an LTS to the other port. This LTS indicates that the sending node is ready to participate in the loop test protocol. A port may not be selected as the test port until an LTS has been sent and received on that port. To send an LTS, a node first sends one SPEEDb symbol followed by one or more DATA_PREFIX symbols followed by a continuous sequence of data symbols that contain the contents of the HR, properly scrambled and encoded. As the contents of the HR change, those changes are reflected in the LTS that is sent. Changes in the LTS are not delimited with any control symbols. A node accepts as an LTS any data symbol that follows a SPEEDb or one or more DATA_PREFIX symbols when the port is in the Disconnected state.
Copyright © 2008 IEEE. All rights reserved.
375
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTE—If the DATA_PREFIX symbols are not received, the receiving port continues to interpret the symbols on the bus using the rules for encoding arbitration tokens, which will cause symbol decode errors as the transmitting node is encoding with data encoding. After a short time, the receiving node accumulates a sufficient number of coding errors to cause it to lose synchronization and return to training.
14.7.6 Loop test packet (LTP) The LTP is sent by the controlling node using the format described in 16.3.3.5. The LTP is sent using Alpha format, at S100, ensuring that the LTP can be propagated through Alpha PHYs so that loops that contain at least one Beta connection can be broken. After sending an LTP, the controlling node holds the bus by sending DATA_PREFIX symbols. The controlling node may end its bus occupancy either by completing an attach and sending a bus reset or by abandoning the test and sending a null packet or a final LTP.
14.7.7 Test port selection If an LTS has not been received on a port in the Untested state, then that port shall not be selected as the test port. If an LTS has been received, then the port may be the test port if the received LTS has a value that is less than the value in the HR. When doing the comparison between the LTS and HR value, the M bit of the received LTS is checked first. If it is ATTACH_IN_PROGRESS, then this port may not be selected as the test port. If the mode is not ATTACH_IN_PROGRESS, then the LTS is compared against the HR with the generation number being the MSB followed by the test_value number. If no untested port has received an LTS that is lower than the HR, then a port with an equal value may be selected. A port with a received LTS that is greater than the HR shall not be selected as a test port. If a node is not the controlling node, then receipt of a new LTP may cause the node to choose a new test port.
14.7.8 Loop test When a node becomes the controlling node, it resets and starts its maximum occupancy timer and sends a first LTP. Each time it sends an LTP, it also resets and starts the test timer. The test timer times the test interval, which starts when an LTP is sent on the active bus and expires after TEST_INTERVAL. The duration of the test interval allows the LTP to propagate to the furthest extremes of the bus and for an LTS with the same loop test data (LTD) to be received on the test port. The test interval starts when an LTP is sent on the active bus. During the test interval, every node with untested ports compares the LTD in the LTS received on the test port to the values in the HR. As long as the LTD in the received LTS is not equal to the HR contents and the mode of the received LTS is not ATTACH_IN_PROGRESS, the test continues for the duration of the test interval. If, however, at any time during the test interval, the LTD in the LTS is equal to the HR, then a collision condition exists. Upon detecting a collision, the controlling node shall select a new test_value number, send a new LTP, and reset and restart the test interval timer. The controlling node shall repeat this process up to COLLISION_LIMIT times while continuing to hold the bus unless or until further testing might result in the node holding the bus for more than MAX_OCCUPANCY_TIME. If the controlling node detects COLLISION_LIMIT collisions in a row, then it shall place the test port in the loop disabled state and release the bus. If at any time during the test the mode of the received LTS is ATTACH_IN_PROGRESS, then the test of the port is abandoned (i.e., the controlling node sends a null packet and releases the bus). When a node has control of the bus in order to perform loop testing, has detected a possible collision, and is about to issue a new LTP, and if further testing might cause the node to hold the bus for more than MAX_OCCUPANCY TIME, then the node shall send a null packet, release the bus, and re-request the bus.
376
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
When it regains control of the bus, and provided that the test of the port has not been abandoned, it shall issue a new LTP and continue testing the port, using the count of collisions from the previous set of tests. See 16.4.9 for a description of the implications for large diameter networks. When the test interval expires without a collision being detected or without the mode of the received LTS being equal to ATTACH_IN_PROGRESS, the controlling node shall check to see whether it is still dominant over the node at the other end of the connection on the test port. If the HR in the controlling node is less than the HR of the LTS from the test port, then the other node is dominant and the test is abandoned (i.e., the controlling node sends a null packet and releases the bus). If the controlling node is dominant, then it shall attempt to complete the attach.
14.7.9 Completing the attach If the test interval expires, no collision condition exists, and the controlling node is dominant, then the controlling node shall begin the attach process. It starts the process by setting the M bit in the HR to ATTACH_IN_PROGRESS, updating the LTS sent on all ports (including the test port) to have the ATTACH_IN_PROGRESS flag set, and then sending an LTP. Once the LTP has been sent, an LTS with the same LTD is sent on all untested ports except for the test port. On the test port, the controlling node shall send a continuous sequence of ATTACH_REQUEST control symbols. Although the test timer is no longer used, when the LTP is sent the test timer may be reset and started. The ATTACH_REQUEST symbol indicates to the node connected to the test port (i.e., the attach node) that it is safe to make the port active. To attempt to minimize the overall disruption of completing an attach, the attach node is given the opportunity to win arbitration for its bus so that the buses can be joined with a single, short bus reset. However, the controlling node is not allowed to hold its bus for an arbitrary amount of time waiting for the attach node to win arbitration. After sending an ATTACH_REQUEST token, the node shall wait until the first of the following events occurs: a)
A bus reset (long or short) is received on the test port. This event usually indicates that the attach port has won arbitration and the two bus segments will be joined with a short but reset. In this case, the port shall be placed in the Active state, and the bus reset shall be propagated to all other active ports.
b)
The maximum occupancy timer expires. In this case, the controlling node shall place the test port in the Active state and then send a long bus reset to all ports that are in the Active state.
c)
The controlling node receives an ATTACH_REQUEST on the test port. This event usually indicates that the attach node is a leaf node. In this case, the controlling node shall place the test port in the Active state and send a short bus reset to all ports in the Active state.
d)
A long bus reset is received on another untested port on which an ATTACH_REQUEST has been received. In this case, the controlling node shall place the test port and the reset port into the Active state and propagate the reset to all active ports.
For the cases above, the controlling node may receive an ATTACH_REQUEST on one or more other untested ports that are not the test port before the bus reset or ATTACH_REQUEST is received on the test port. In such a case, the controlling node shall place those ports in the Active state before sending or repeating the bus reset. Also the controlling node may lose synchronization on the test port while waiting for a response to an ATTACH_REQUEST. In such a case, the controlling node shall place the test port in the Disconnected state, set the M bit to TEST, and send a new LTP. If no ATTACH_REQUEST had been received on any other port, the controlling node shall release the bus after sending the LTP. If, however, an ATTACH_REQUEST had been received, the controlling node shall place all ports on which an ATTACH_REQUEST was received into the Active state and send a short bus reset to all active ports.
Copyright © 2008 IEEE. All rights reserved.
377
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
14.7.10 Received ATTACH_REQUEST or bus reset When a node receives an ATTACH_REQUEST when it is not the controlling node, it shall begin arbitrating for its local bus. When it wins arbitration, all untested ports on which an ATTACH_REQUEST has been received shall be placed in the Active state; and a short bus reset shall then be sent on all active ports. If a node receives a bus reset on an untested port (either before or after receiving an ATTACH_REQUEST on the port), the port is placed in the Active state; and the bus reset is propagated as a long bus reset to all active ports. If an ATTACH_REQUEST had been received on any other ports, these ports are also placed in the Active state; and the reset is propagated on these ports.
14.7.11 Loop Disabled state While in the Loop Disabled state, the port maintains connectivity by toning (similar to suspend, standby, and disable). If a disconnection occurs, then the port reverts to the Disconnected state, without a bus reset or software notification. A port that is in the Loop Disabled state is placed in the Untested state when a bus reset occurs.
14.7.12 Connections to Alpha nodes When a port is connected to an Alpha node, LTPs are not exchanged. Instead, the connection is activated according to Alpha rules.
14.7.13 Loop detection during bus initialization Some loop conditions may be detected during bus initialization. Three conditions are explicitly treated: a)
Configuration timeout (in the T0: Tree ID Start state), which can occur if the node is on a loop and either that loop includes one or more Alpha nodes or the loop is formed as a result of a connection on the bus being resumed.
b)
Arbitration state timeout, which can occur up to the time when the port enters the S1: Self-ID Grant or S2: Self-ID Receive state if the node is connected to a network of Alpha nodes that are in a loop.
c)
Repeated resets, which can occur in similar circumstances to condition b with a loop on a network that includes IEEE 1394 nodes that use a shorter arbitration state timeout.
If any of these events occur, all Beta ports are forced to commence retraining by ceasing to signal for long enough to appear disconnected and then restarting as if a new connection had been made. They enter the P11: Untested state and a loop-free build is done. A peer port treats loss of synchronization prior to entering the S1: Self-ID Grant or S2: Self-ID Receive state as an indication to move into the P11: Untested state. In the case of condition a, it may now be possible for the tree identify process to complete normally (i.e., there is no need to restart the bus reset process). A Beta-only PHY may begin loop-free build on each port as it completes training. A border PHY, however, may not begin testing any of its Beta ports until the tree identify process completes on all Alpha ports. While waiting for the tree identify process to complete on active Alpha ports, the Beta ports on a border node shall complete training and enter the P11: Untested state, but shall not send an LTS. This prevents any attached Beta node from making its connection to this border node as a test port and trying to do an attach. The result is that the border node will not be attached to the Beta cloud until the tree identify process has successfully completed on the Alpha ports that are participating in tree identification. When the tree identify process on the Alpha ports has completed, LTS is sent on the Beta ports and a loop-free build is completed on the border node.
378
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
14.7.14 Minimal LTP support A PHY with only a single port (i.e., a leaf node) is not required to support the full loop-free build process. Such a PHY may send an ATTACH_REQUEST as soon as the port enters the Untested state and becomes its test port. After sending the ATTACH_REQUEST, it shall wait indefinitely for either an ATTACH_REQUEST or bus reset to be received on its test port. On receipt of an ATTACH_REQUEST, the node shall place the port in the Active state and send a short bus reset. On receipt of the bus reset, it shall place the port in the Active state.
14.7.15 Isolated node behavior A node with no active ports and no ports in standby is considered to be an isolated node. When an isolated node completes testing of a port and sends an ATTACH_REQUEST, it shall release its bus (i.e., it is the only node on its active bus, but it is required to release the bus to allow PHY-link or PIL-FOP communications). Unlike a nonisolated node, the isolated node need not time the interval waiting for the bus reset to return from the test port because it is not holding the bus. When the isolated node receives a bus reset, it shall make the port active. If it receives an ATTACH_REQUEST from another port, it shall arbitrate for its bus, make all ports active on which the ATTACH_REQUEST was sent or received, and send a bus reset on all active ports. If the node receives a bus reset (e.g., from software or an Alpha port), it shall make all ports active on which an ATTACH_REQUEST was sent or received and propagate the reset to all active ports.
14.8 Connection management 14.8.1 Connection detection When the port is disconnected, the procedure described in this subclause aims to detect a reconnection and to determine the appropriate mode of operation (i.e., DS mode or Beta mode) and, if Beta mode, the appropriate operating speed. The same underlying mechanisms are used during suspend to determine that a port has become disconnected. In both cases, the emphasis is to provide a very low power mechanism that meets all the appropriate constraints. A simplified algorithm applies if the port is Beta-only. NOTE—See Annex O for additional details.
A B PHY uses connect_detect_valid to drive a toning scheme. A tone is transmitted on TPB. A signal detect circuit listens on TPA. (The output on TPA is set to high impedance.) The signal_detect_OK function returns TRUE if an electrically valid signal has been detected on TPA since the last call of the function. The signal detect circuit and, therefore, the signal_detect_OK function do not provide any guarantee of quality of signal and do not imply scrambler synchronization or the reception of valid 8B/10B codes.
14.8.2 Connection detection and mode determination algorithm An eager Beta algorithm is used (provided that local_plug_present is true) following POR or at any time the PHY needs to determine a port’s connection status. The rationale for the algorithm is given in Annex O. A PHY shall apply the following algorithm for each port that is capable of operating in Beta mode: a)
Begin toning. If a tone is heard, then Beta mode is established and algorithm exits. If TpBias is detected, then go straight to step b). Otherwise, stay in this state until NUM_OF_TRIES tones (approximately 10) have been generated and neither TpBias nor a tone is detected and then go to step b). If a change in state of connect_detect from disconnected to connected occurs, then tone for at least two more times and then go to step b).
Copyright © 2008 IEEE. All rights reserved.
379
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
b)
IEEE STANDARD FOR A
Check connect_detect. If not set to connected, then go back to the start of step a), otherwise, check for TpBias. If TpBias is detected, wait for 16 * RESET_DETECT and then sample bias once again. Wait for it to go away so that toning can be tried again. 1)
If bias is still present DS mode is established. Assert TpBias and algorithm ends.
2)
If bias is not present, generate the startup tone. An attached Beta mode PHY will respond with the startup tone, and Beta mode will be established and algorithm ends. If a tone is not received, assert TpBias for 12 * RESET_DETECT. If bias is then detected, DS mode is established and algorithm ends. Otherwise, go back to step a).
A far-port that does not support Arbitration Compliance Level A or greater (see 15.1) will assert TpBias on its TPA, but will not see TpBias on its TPB and, therefore, will not think it is connected. A far-end port that supports Arbitration Compliance Level A will sense con_status and start its debounce timeouts. If an Arbitration Compliance Level A port is at the other end of the connection, and, if the local Beta port does not respond to TpBias before the far-end port times out, then the far-end port will enter into a resumefault condition; and because the Beta port did not receive a tone in reply to its last tone attempt, it will generate TpBias again causing the far-end port to wake and become a resume target. If the far-port does not support Arbitration Compliance Level A or greater, there will not ever be an issue because it will always be generating TpBias; and when the port finally generates TpBias, the B PHY will eventually generate a bus reset because of the resume process if a bus reset is not detected from somewhere else. The set of possible port connections that a bilingual port may be connected to are given in Table 14-4.
Table 14-4—Connect_status value in various connection scenarios connect_status
Tone exchange
Action
No connection
No
Fails
—
DC connection to Alpha
Yes
Fails
Set DS
DC connection to bilingual
Yes
Succeeds
Set Beta
DC connection to Beta only
Probably
Succeeds
Set Beta
AC connection to bilingual
No
Succeeds
Set Beta
AC connection to Beta only
No
Succeeds
Set Beta
DC connection to optical transceiver
Noa
Succeeds
Set Beta
AC connection to optical transceiver
No
Succeeds
Set Beta
NOTE—The tone transmission and detection continues through the debounce period. If a tone is detected during this time, then Beta mode is set. aA
dc connection to an optical transceiver shall be biased to not trigger the connect or bias detector.
14.8.3 Beta-mode speed negotiation Once a Beta-mode connection has been determined, the PHY shall carry out the following speed negotiating procedure that is described in this subclause. A single protocol is used to negotiate the speed anywhere in the range S100 to S3200. Upon connection, the only property of the connecting medium that can be relied upon is that it can support the exchange of tones at the selected frequency (between 48 and 61 MHz) provided they last at least 667 μs. This property is true until continuous operation is established (particularly, for example, because of the
380
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
startup latencies of the optical components). The aim is to establish continuous operation at the correct operating speed and to avoid any need for matching configuration options at “both” ends to determine what a “common denominator” operating speed should be. These aims are achieved by using the same tone as is used for connection detection, differentiating where necessary between the occasional tone to identify connect and disconnect events, a pattern of tones to negotiate the operating speed, and a continuous tone (in suspend) to indicate that it is time to resume. For the last case, the operating speed is indeed known, but making this indication any different from the tone used for connection detection apart from its duration seems unnecessary (i.e., it is necessary for a simple signal detect circuit to be alive only during suspend). Both ports transmit a speed code indicating their respective maximum speeds, while simultaneously listening for the speed codes from the peer port. The ports then transmit the minimum of the transmitted and received speeds, together with an acknowledge bit (to indicate that the agreed speed has been received). When a port receives the speed code with the acknowledge bit set, then it ceases to transmit speed codes, and the connection is established. The speed code timing and encoding for this purpose is shown in Figure 14-4. 42.67ms 21.33ms 2.67ms 666.67µs
666.67µs
ack
1 0 1 0 1 0 0
0 1 1 0 0 1 1
0 0 0 1 1 1 1
FOP FOP FOP FOP FOP FOP TS1
PIL PIL PIL PIL PIL PIL TS2
0 0 0 0 0 0 1
S100 Connection S200 Connection S400 Connection S800 Connection S1600 Connection S3200 Connection S3200 Electrical Test
NOTE—Reprinted with permission from 1394 Trade Association TB2007010 [B6]
Figure 14-4—Speed code timing diagram To recognize the start tone (i.e., the first tone in the sequence), the encoding of the speed and any other information is constrained to last for less than half DISCONNECTED_TONE_INTERVAL (i.e., less than 21.33 ms). Three further bits in the speed code are allocated to indicate whether the peer port is in Connection mode or electrical test mode, the PIL_Capable and FOP_Capable properties of the peer port, and the electrical test configuration requested by the peer port. Connection mode is indicated by a zero as the last bit in the sequence, while a one indicates that the device is to enter the S3200 electrical test mode. In Connection mode, a port that is not PIL_Capable shall not acknowledge a received speed code with the FOP_Capable bit set, and a port that is not FOP_Capable shall not acknowledge a received speed code with the PIL_Capable bit set. See Clause 18 for the behavior of PIL_Capable and FOP_Capable ports. In electrical test mode, the bits TS1 and TS2 define the electrical test configuration (see 9.3.3.9.) A sample speed negotiation between two ports is shown in Figure 14-5. The arrow tail represent the time of the start of the transmission of the speed code and the arrow head represents the time of the completion of
Copyright © 2008 IEEE. All rights reserved.
381
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
the reception of the speed code. PSx and PSy represent the speeds of ports x and y, respectively, (PSy > PSx), with a plus sign indicating transmission of the ACK bit. The values alongside the time lines give the value of the count variable at the end of the speed negotiation loop (i.e., immediately after transmitting the speed code).
Port y (PSy > PSx)
Port x PSy 8-2 = 6
PSx
PSx+ 6+1-2 = 7
8-2 = 6
PSx
PSx+ 7-2 = 5 Agreed
8-2 = 6
6-2 = 4 Agreed
PSx+
Figure 14-5—Example of speed negotiation 14.8.4 Disabled ports Two levels of disabled ports are provided. One has connectivity behavior that is as close to Arbitration Compliance Level A (see 15.1.1) as possible; and the second, termed hard disable, prevents a port from engaging in any form of signaling. When a port is disabled (but not hard disabled), the algorithms described in 14.8.2 and 14.8.3 are used to establish and maintain connectivity, including Beta-mode operation capability and operating speed. Care is taken to provide similar functionality to Arbitration Compliance Level A with respect to interrupts on change of port status. In particular, a port’s connected flag may be FALSE even though a physical connection has been established. A disconnected port advertises its presence with toning and, if hearing a tone, attempts to debounce and speed-exchange without regard to the disabled or int_enable flags. This behavior allows the far port to set connected if it so desires. After Beta mode is established, the local connected flag is set if !disabled||int_enable (as in Arbitration Compliance Level A), and a local port event occurs if disabled&&int_enable&&!port_event. A port that is disabled and disconnected is held in the Disabled state (even if it was in the Disconnected state when software instructed it to be disabled). A disabled (but not hard disabled) port operating in Beta mode shall maintain connectivity by toning. When re-enabled, a disabled port operating in Beta mode shall enter the Untested state.
382
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
14.9 T-mode connectivity and operation When instructed to negotiate by the port state machine, the PMD layer shall commence negotiation as described in 14.11 and shall continue with negotiation as described in 14.11 until the negotiation either succeeds or fails. If a status confirmation of PMD_TPORT_OK and PMD_TPORT_FW is received from the PMD layer at the completion of negotiation, then the port shall set both the betaMode and tMode flags. The port state machine functions are then followed as in 14.5. When instructed to start normal operation, the port shall use the encoding specified in Clause 20. From the point of view of the higher levels, there is no difference between Beta mode and T-mode operation, apart from latency, jitter, and behavior when a port is placed in hardDisable and the behavior when negotiation results in 802_mode.
14.10 Simultaneous support for Beta mode and T-mode A port may be capable of supporting both Beta mode and T-mode. Such a port may be connected to a peer port that can operate either as a port that supports S100 to S400 Beta mode only, another port that also supports both modes, or a port that supports T-mode only. In the first case, the port shall operate in Beta mode, and in the second two cases, the port shall operate in T-mode. When instructed to negotiate by the port state machine, the PMD layer shall commence negotiation as described in 14.11 and shall also enable its signal detect circuitry (it shall not commence toning at this stage). It shall cease negotiation upon detecting a toning signal compliant with 14.8.3 on pair 1 and 2 or pair 3 and 6, and it shall report a status of SIGNAL_DETECT. Otherwise, it shall continue with negotiation as described in 14.11 until the negotiation either succeeds or fails. On receiving a status of SIGNAL_DETECT, the port state machine shall set the port maximum and minimum speeds to S100 and shall commence Beta connectivity toning and speed negotiation as specified in 14.8, followed by synchronization and normal Beta mode operation. The PMD layer shall support autocrossover. Autocrossover shall be attempted if necessary as described in 12.4.5.
14.11 Negotiation When the PMD layer is instructed by the port state machine to negotiate (by means of the PMD_CONTROL_ request of PMD_START_NEGOTIATE), the port shall commence to seek a peer connection and negotiate the mode of operation. During the time that the PMD layer is seeking a connection or negotiating, it shall provide a confirmation to a PMD_STATUS_request of NEGOTIATION_ACTIVE. At the completion of negotiation, the PMD layer shall provide a confirmation of PMD_TPORT_OK and PMD_TPORT_FW, or PMD_TPORT_802, or none of these (no connection or negotiation failed).
14.11.1 Overview Devices using this standard are designed to coexist on the same UTP cables used by IEEE 802.3 10/100/1000Base-T Ethernet. A negotiation protocol is used to ensure that the following situations resolve appropriately: a)
T-mode only port connected to T-mode only port
b)
T-mode only port connected to T-mode + Ethernet twin-mode port
c)
T-mode + Ethernet twin-mode port connected to T-mode + Ethernet twin-mode port
d)
T-mode only port connected to Auto-Negotiation capable Ethernet only port
e)
T-mode only port connected to legacy Ethernet only port
Copyright © 2008 IEEE. All rights reserved.
383
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The negotiation scheme determines whether a common mode of operation exists and, if so, enables the best performing common mode. If no common mode of operation exists, the devices will not force bad packets into the network or otherwise interfere with a correctly functioning network. The negotiation scheme chosen borrows heavily from IEEE 802.3 Auto-Negotiation and extends it to T-mode ports. A T-mode port sends a simplified base page with a T-mode selector field. This is followed by Message Code 8 Next Pages. Then Message Code 5 Next Pages is sent containing the OUI for this standard (00-190D). These pages are sent and received on twisted pairs C and D while optionally allowing Ethernet negotiation to proceed in parallel on twisted pairs A and B. After each side’s capabilities are exchanged, the highest performance common technology is enabled automatically.
14.11.2 S100 Beta mode parallel negotiation A device that complies with Clause 12 and Clause 13 and supports Beta mode only on a port will transmit tones (per 14.8.3) on TPB, i.e., pins 1 and 2 on the media interface connector (as specified in 12.4.4) for that port, which will be received by the peer device on TPA (pins 3 and 6). A device compliant with this standard may support S100 to S400 Beta mode on the same port as it supports T-mode and IEEE 802.3 operation. Reception of these tones by a PHY that supports Beta mode will cause SIGNAL_DETECT to assert (per 14.8).
14.11.2.1 Clause 22 in IEEE Std 802.3-2005 The media independent interface (MII) register space as defined in 22.2.4 in IEEE Std 802.3-2005 is dedicated to IEEE 802.3 Auto-Negotiation. No bits are allocated for IEEE 1394 operation within the MII register space. An implementation may use an equivalent parallel set of registers to control T-mode negotiation as a method of implementing the negotiation services of PMD_START_NEGOTIATE (see 16.2.5.1) and PMD_STATUS_confirmations (see 16.2.5.2). An implementation may provide an implementation-dependent method of exposing direct access to the parallel set of registers for test purposes, e.g., by providing access via management data input/output at a different (nonzero) PHY address. Access to the IEEE 802.3 management registers has no effect on T-mode port operation. In particular, PHY reset (setting bit 0.15 to a logic one) shall not disrupt T-mode port operation.
14.11.3 Differences between T-mode and IEEE 802.3 negotiation With the exceptions described in 14.11.3.1 through 14.11.3.5, T-mode negotiation is Auto-Negotiation as defined in the following sections of IEEE Std 802.3-2005: —
Clause 28
—
Annex 28A
—
Annex 28B
—
Annex 28C
—
Annex 28D
—
Subclause 40.5
—
Annex 40C
384
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
14.11.3.1 Clause 28 in IEEE Std 802.3-2005 14.11.3.1.1 IEEE 802.3 (Clause 28) interface to MDI IEEE 802.3 operation relies on Auto-Negotiation using the standard 8-pin modular connector of IEC 60603-7 and its transmission and reception assignments as described in 14.5.1 in IEEE Std 802.3-2005. This requires transmission on pair A (contacts 1 and 2) and reception on pair B (contacts 3 and 6). To eliminate conflict and speed cross-standard negotiation, a T-mode port uses the alternate two pairs (pairs C and D) for transmission and reception. Table 40-12 in IEEE Std 802.3-2005 shows the full contact to pair mapping for all four pairs. For a T-mode port, transmission shall be done on MDI pair C (BI_DC±), and reception shall be done on MDI pair D (BI_DD±). Support for crossover cabling correction shall be provided by allowing pairs C and D to be swapped.
14.11.3.1.2 IEEE 802.3 (28.3) Auto-Negotiation arbitration state machine(s) Twin-mode ports supporting T-mode and Ethernet shall implement negotiation as described in this standard. A T-mode only port shall implement negotiation as described in this standard. This enhanced negotiation for twin-mode devices requires two concurrent negotiations: normal Ethernet Auto-Negotiation on copper cable pairs A and B and IEEE 1394 negotiation on pairs C and D. Therefore, two instances of the Auto-Negotiation arbitration state machine specified by Figure 28-16 in IEEE Std 802.3-2005 are required to operate at the same time. Since there are two instantiations, it is also required to provide an interlock between them. The two Auto-Negotiation state machines shall operate as specified in IEEE Std 802.3-2005, except as specified in the remainder of this clause. The results of the two parallel negotiations are evaluated as the state machines enter the respective FLP LINK GOOD CHECK states (see 28.3 of IEEE Std 802.3-2005), according to the modified priority resolution table (see 14.11.3.3). If T-mode is selected, then the Ethernet management registers shall be set to appear as if the (Ethernet) port is disconnected. If the negotiation parameters are changed on one of the pairs, negotiation shall restart on both pairs. As a matter of notation, each of the state machines accesses the variables of the other state machine by prepending o_ to the variable name.
14.11.3.1.3 Subclause 28.3.1 in IEEE Std 802.3-2005 A variable with “_[S100Beta]” appended to the end of the variable name indicates a variable or set of variables for which a IEEE 1394 S100 Beta mode physical medium attachment (PMA) is the signal source. For parallel detection of a S100 Beta mode only device, the assertion of SIGNAL_DETECT shall assert the link_status_[S100Beta]=READY primitive as defined in 28.2.6.1 in IEEE Std 802.3-2005, and the IEEE 802.3 Auto-Negotiation algorithm shall behave as specified in IEEE Std 802.3-2005 except as follows: The single_link_ready variable is a status variable indicating that flp_receive_idle = true and only one the of the following indications is being received: link_status_[NLP] = READY link_status_[TX] = READY link_status_[T4] = READY
Copyright © 2008 IEEE. All rights reserved.
385
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
link_status_[S100Beta] = READY Values: false: Either zero or more than one of the above indications are true, or flp_receive_idle = false. true: Exactly one of the above indications is true, and flp_receive_idle = true. The mr_parallel_detection_fault is an error condition indicating that while performing parallel detection, either flp_receive_idle = false, or zero or more than one of the following indications were present when the autoneg_wait_timer expired. This signal is cleared on read of the Auto-Negotiation expansion register. link_status_ [NLP] = READY link_status_[TX] = READY link_status_[T4] = READY link_status_[S100Beta] = READY Values: false: Exactly one of the above indications was true when the autoneg_wait_timer expired, and flp_receive_idle = true. true: Either zero or more than one of the above indications was true when the autoneg_wait_timer expired, or flp_receive_idle = false.
14.11.3.1.4 Figure 28-16 in IEEE Std 802.3-2005 In order to support parallel detection of S100 Beta mode, the following is added to the transition conditions from ABILITY DETECT to LINK STATUS CHECK: + link_status_[S100Beta]=READY
In order to provide an interlock between the two arbitration state machines, the following are added: a)
A new state SYNC WAIT -------------------waiting <= true
Waiting is true when in the SYNC WAIT state and cleared upon exit. b)
A state transition from COMPLETE ACKNOWLEDGE to SYNC WAIT with the following conditions: double_negotiation=true * {original COMPLETE ACKNOWLEDGE to FLP LINK GOOD CHECK conditions}
double_negotiation indicates whether two simultaneous Auto-Negotiations are occurring:
one on pair A and B and the other on pair C and D. It takes a value of true when two negotiations are being performed and false when only one negotiation is being performed. This variable is set by the configuration of the device. NOTE—This will put an upper bound on the number of extra Next Pages sent on one pair but not the other.
c)
An activity timer with an expiration period of 4 s and started in the ACKNOWLEDGE_DETECT state.
d)
A state transition from SYNC WAIT to LINK GOOD CHECK with the following conditions:
o_waiting + o_activity_timer_done * o_break_link_timer_done *o_autoneg_wait_timer_done
e)
The state transition from COMPLETE ACKNOWLEDGE to FLP LINK GOOD CHECK modified as follows: double_negotiation=false * {original COMPLETE ACKNOWLEDGE to FLP LINK GOOD CHECK conditions}
386
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
f)
IEEE Std 1394-2008
The ABILITY DETECT state with the following addition: PMD_Status_Request=NEGOTIATION_ACTIVE==true
g)
The FLP LINK GOOD state with the following addition: PMD_Status_Request=NEGOTIATION_ACTIVE==false
When negotiation is performed over pairs C and D, the arbitration state diagram states LINK STATUS CHECK and PARALLEL DETECTION FAULT are unused. It is not expected that legacy technologies would transmit on pairs C or D.
14.11.3.2 Annex 28A in IEEE Std 802.3-2005 Annex 28A in IEEE Std 802.3-2005 shall be used as is except that the selector value of 001002 shall be used for T-mode negotiation.
14.11.3.3 Annex 28B in IEEE Std 802.3-2005 Annex 28B in IEEE Std 802.3-2005 shall be used as is except for the following changes: a)
The Selector field S[4:0] = 00100.
b)
The Technology Ability field is reserved. It shall be transmitted as 0 and ignored on reception.
c)
The Extended Next Page bit is reserved. It shall be transmitted as 0 and ignored on reception.
d)
The Remote Fault bit in the T-mode base page shall be used as defined in 28.2.1.2.3 in IEEE Std 802.3-2005.
e)
The Ack bit in the T-mode base page shall be used as defined in 28.2.1.2.4 in IEEE Std 802.3-2005.
f)
The Next Page bit in the T-mode base page, defined in 28.2.1.2.4 in IEEE Std 802.3-2005, shall be always set to 1.
g)
T-mode takes priority above 1000Base-T in the priority resolution table.
h)
As part of the highest common denominator (HCD) selection process, PMD_TPORT_FW shall be set to true when T-mode is selected, and PMD_TPORT_802 shall be set to true when an IEEE 802.3 technology (e.g., 100BASE-T, 1000BASE-T) has been selected.
14.11.3.4 Annex 28C in IEEE Std 802.3-2005 Annex 28C in IEEE Std 802.3-2005 shall be used as is except for the following changes: a)
Message Codes 0–31 are as defined by IEEE Std 802.3-2005. All other codes are reserved.
b)
Message Code 5 is used to transmit OUIs. It shall be sent with the OUI for this standard (00-19-0D) as part of standard T-mode negotiation.
14.11.3.4.1 IEEE 802.3 (28C.6) Message Code 5 ( OUI tag code) For T-mode, the OUI tagged message shall consist of a single message code of 0000 0000 01012 followed by four user codes. The IEEE-assigned OUI value is 00-19-0D for this standard, and the manufacturer-selected extension identifier for T-mode is 00000000002 or 1000000000. The message code values generated from these two numbers is encoded into four message codes, as specified in Figure 14-6. For clarity, the position of the global broadcast g is illustrated. NOTE—Figure 14-6 shows the order in which Next Pages are transmitted, with the first transmitted Next Page shown in the leftmost position. The bits within each individual Next Page, however, are transmitted starting with bit D0 and finishing with bit D15.
Within this illustration, the a bit indicates whether T-mode is supported, as specified in Table 14-5. The r bits are reserved: these shall be transmitted as 0 and ignored on reception.
Copyright © 2008 IEEE. All rights reserved.
387
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
g OUI hexadecimal
dependent
19
00
0D
80
00
0
MSB LSB MSB LSB binary 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 1 1 0 1 a r r r r r r r r r r r r r r r r r r r
Unformatted Next Page
Unformatted Next Page
Fourth user code Unformatted Next Page
D0
Unformatted Next Page
Third user code
rr r r r r r r r r r
D0 D15
Message Next Page
Second user code D0 D15
First user code
D0 D15
Message code D0 D15
D15
00000000101 00000000000 11001000011 01a r r r r r r r r
T, Ack2, MP, Ack and NP bits
Figure 14-6—Message Code 5 sequence
Table 14-5—Serial bus Message Code 5, bit a Value
Name
Description
0
UNSUPPORTED
T-mode is not supported
1
SUPPORTED
T-mode is supported
14.11.3.4.2 IEEE 802.3 (28C.10) Message Code 8 (1000BASE-T technology message code) Message Code 8 is used for T-mode negotiation in the same way as IEEE 802.3 Auto-Negotiation with the modifications noted in 14.11.3.5.2.
14.11.3.5 Subclause 40.5 in IEEE Std 802.3-2005 14.11.3.5.1 Subclause 40.5.1.1 in IEEE Std 802.3-2005 No bits are allocated for T-mode within the MII register space. An implementation may use an equivalent parallel set of registers to control T-mode negotiation as described in 14.11.2.1.
14.11.3.5.2 IEEE 802.3 (40.5.1.2) next page usage T-mode negotiation shall send a base page followed by Message Code 8 Next Pages as specified in 40.5.1.2 in IEEE Std 802.3-2005 except that bits U3 and U4 shall be reserved. They shall be ignored on receipt and and sent as 0 on transmit.
388
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
15. PHY register map The material in this clause is normative for both discrete and integrated PHY and link implementations. In addition, link implementations shall provide a means for software or firmware to access the PHY registers defined throughout this clause.
15.1 Arbitration compliance levels This standard defines two levels of compliance, denoted as Level A and Level B, for arbitration. The compliance level supported by a particular device is declared in a read-only register in the PHY register map.
15.1.1 Arbitration Compliance Level A A device that supports Arbitration Compliance Level A shall provide one or more ports capable of operating in DS mode as specified in 9.2 and/or a PHY/Link interface capable of operating in Alpha mode as specified in 17.2.
15.1.2 Arbitration Compliance Level B A device that supports Arbitration Compliance Level B shall provide one or more ports capable of operating in Beta mode as specified in 13 and/or a PHY-link interface capable of operating in Beta or Beta Plus mode (see 17.3). This includes short-haul copper, GOF, POF, UTP, and T-mode ports (as specified in Clause 9, Clause 10, Clause 11, Clause 12, and Clause 20, respectively.) A device that can support both Arbitration Compliance Level A and Arbitration Compliance Level B shall declare itself as supporting Arbitration Compliance Level B in the PHY register map (Table 15-4).
15.2 PHY register map for the cable environment In the cable environment, the extended PHY register map illustrated by Figure 15-1 shall be implemented by all designs compliant with IEEE Std 1394. Reserved fields are shaded in grey. A reserved field shall return the value 0 when read and shall have no effect on write. Any write to a register that includes a reserved field shall write 0 to the reserved field. For ports operating in Beta mode, all fields in Figure 15-1 shall be implemented. For ports operating in Alpha mode, the following fields are not required and shall be reserved: —
Enable_standby
—
Max_legacy_path_speed
—
B_link
—
Bridge
The meaning, encoding, and usage of all the fields in the extended PHY register map are summarized by Table 15-1. Power reset values not specified, as well as all bus reset values, are resolved by the operation of the PHY state machines subsequent to the reset (see Clause 17).
Copyright © 2008 IEEE. All rights reserved.
389
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Contents 0
Address
1
2
3
4
5
Physical_ID
00002 RHB
00012
IBR Extended (7)
00112
(Max_speed)
Enable_ standby Jitter
LCtrl
Contender
01012
Watchdog
ISBR
7
R
PS
Gap_count
00102
01002
6
Total_ports
Loop
01102
Max_legacy_path_speed
01112
Page_select
Pwr_fail B_link
Delay Pwr_class Timeout
Port_event Enab_accel Enab_multi
Bridge Port_select
Register0page_select
10002
…
…
…
Register7page_select
11112
Figure 15-1—Extended PHY register map for the cable environment In the tables in this clause, the Type column uses the following abbreviations: —
r: Read only; permanent value
—
ru: Read only by software; hardware may change value when specified event(s) occur
—
rw: Read and write only by software
—
rwu: Read and write by software; hardware can change
—
rcu: Hardware can update; software can clear.
Table 15-1—PHY register fields for the cable environment Field
Power reset value
Size
Type
B-link
1
ru
Vendordependent
When set to 1, indicates that a B link is connected to the PHY. NOTE—This field shall be reserved by Alpha ports.
Bridge
2
rw
See description
Controls the value of the brdg field in self-ID packet. If hardware implementation-dependent means are not available to configure the power reset value of this field, the power reset value shall be zero. NOTE—This field shall be reserved by Alpha ports.
Contender
1
rw
See description
Is cleared or set by software to control the value of the C bit transmitted in the self-ID packet. If hardware implementation-dependent means are not available to configure the power reset value of this bit, the power reset value shall be zero.
390
Description
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 15-1—PHY register fields for the cable environment (continued) Field
Power reset value
Size
Type
Delay
4
r
Vendordependent
Is worst-case repeater delay, expressed as 144 + (delay * 20) ns.
Enab_accel
1
rw
0 (see description)
Is preserved for backwards compatibility. Used only for the implementation of Alpha link request cancellation rules as specified in Table 17-18. Arbitration Compliance Level A (15.1.1) accelerations and prevention of cycle start starvation are controlled by the PHY learning that the link issues PH_CYCLE_START_DUE (Beta link, 17.3) or decelerate (Alpha link, 17.2) requests. When the PHY is configured to use an Alpha link, the initial value follows the rules given in 9.2.
Enab_multi
1
rw
0 (see description)
Is preserved for backwards compatibility. If an Alphalink is used, then this bit shall obey the specification in 9.2.
Enable_standby
1
rwu
See description
Set to enable a port on a candidate nephew node to go into standby and cleared to prevent a port on a candidate nephew node from going into standby. If this bit is TRUE when the PHY-link interface is enabled, then this bit is set to its power reset value and any port that is in standby on a nephew is restored. If hardware implementation-dependent means are not available to configure the power reset value of this field, the power reset value shall be zero. NOTE—This field shall be reserved by Alpha ports.
Extended
3
r
7
Shall have a constant value of seven, which indicates the extended PHY register map.
Gap_count
6
rwu
3F16
Is used to configure the arbitration timer setting to optimize gap times according to the topology of the bus. See 16.3 for the encoding of this field.
IBR
1
rwu
0
Initiates bus reset. When set to 1, instructs the PHY to set ibr to TRUE and reset_time to RESET_TIME. These values in turn cause the PHY to initiate a bus reset without arbitration; the reset signal is asserted for 166 μs. This bit is self-clearing. Any attempt to set this bit on a nephew node with a port in standby is ignored.
ISBR
1
rwu
0
Initiates short (arbitrated) bus reset. A write of one to this bit instructs the PHY to set isbr to TRUE and reset_time to SHORT_RESET_TIME. These values in turn cause the PHY to arbitrate and issue a short bus reset. This bit is self-clearing.
Jitter
3
r
Vendordependent
Is the maximum variance of either arbitration or data repeat delay, expressed as 2 × (Jitter + 1)/BASE_RATE μs.
LCtrl
1
rw
See description
Indicates link is active. Cleared or set by software to control the value of the L bit transmitted in the node’s self-ID packet 0, which shall be the logical AND of this bit and active link power status (LPS). If hardware implementation-dependent means are not available to configure the power reset value of the LCtrl bit, the power reset value shall be one.
Copyright © 2008 IEEE. All rights reserved.
Description
391
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 15-1—PHY register fields for the cable environment (continued) Size
Type
Power reset value
Loop
1
rcu
0
Max_legacy_path_speed
3
ru
Max_speed
3
r
111b
(No longer used, see the fields in the Port Status page, 15.2.1)
Page_select
3
rw
Vendordependent
Selects which of eight possible PHY register pages are accessible through the window at PHY register addresses 10002 through 11112, inclusive.
Physical_ID
6
ru
Port_event
1
rcu
0
Indicates port event detect. The PHY sets this bit to 1 if any of Rx_ok (unless the port is disabled), connected, disabled, fault, standby, or standby_fault changes or if connection_unreliable goes TRUE for a port whose Int_enable bit is one. The PHY also sets this bit to 1 if resume or restore operations commence for any port and Watchdog is one. A write of one to this bit clears it to 0.
Port_select
4
rw
Vendordependent
If the page selected by Page_select presents per-port information, selects which port’s registers are accessible through the window at PHY register addresses 10002 through 11112, inclusive. Ports are numbered monotonically starting at zero, e.g., p0.
PS
1
ru
Vendordependent
Indicates cable power active
Pwr_class
3
rw
Vendordependent
Indicates power class. Controls the value of the pwr field transmitted in the self-ID packet. See 16.3.3.1 for the encoding of this field.
Pwr_fail
1
rcu
1
Indicates cable power failure detect. Set to 1 when the PS bit changes from one to zero or upon a PHY power reset. A write of one to this bit clears it to 0.
R
1
ru
RHB
1
rwu
0
Timeout
1
rcu
0
Field
Description Indicates loop detect. A write of one to this bit clears it to 0. Is the maximum speed observed during bus initialization from self-ID packets transmitted from or repeated by an Alpha node (i.e., with Alpha PHY or link, or both), or S100, whichever is faster. Encoding is S100 0002 0012 S200 0102 S400 All other values Reserved NOTE—This field shall be reserved by Alpha ports.
Is the address of this node determined during selfidentification. A value of 63 indicates a malconfigured bus; the link shall not transmit any packets.
When set to 1, indicates that this node is the root. Indicates root hold-off bit. When set to 1, the force_root variable is TRUE, which instructs the PHY to attempt to become the root during the next tree identify process. Indicates arbitration state machine timeout (see MAX_ARB_STATE_TIME). A write of one to this bit
clears it to 0.
392
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 15-1—PHY register fields for the cable environment (continued) Field
Power reset value
Size
Type
Total_ports
5
r
Vendordependent
Is the number of ports implemented by this PHY.
Watchdog
1
rw
0
Indicates Watchdog enable. Controls whether loop, power fail, and timeout interrupts are indicated to the link when the PHY-link interface is not operational. Also determines whether interrupts are indicated to the link when resume operations commence for any port (regardless of the value of Int_enable for the port).
Description
Because a write to the PHY register at address 00012 sets the PHY’s gap_count_reset_disable variable to TRUE regardless of whether the values of RHB, IBR, or Gap_count are altered, a write that sets Gap_count to any value other than 63 shall either set IBR to 1 in the same write or, as soon as possible thereafter, set ISBR to 1 to initiate a bus reset. See 8.4.5.2 for details. The RHB bit should be zero unless it is necessary to establish a particular node as the root; see 8.4.2.7 for details. The Watchdog bit serves two purposes. One is to determine whether an interrupt condition shall be indicated to the link. The other is to create an interrupt condition when resume operations commence for any port. An interrupt condition is created either when any of the Loop, Pwr_fail, Timeout, or Port_event bits transition from zero to one or when the PHY detects the absence of LPS and any of these same bits are one. Whether an interrupt condition shall be indicated to the link is determined by Table 15-2.
Table 15-2—PH_EVENT.indication(INTERRUPT) sources Interrupt source
LPS
Watchdog
Port_event
—
—
INTERRUPT
Loop Pwr_fail Timeout
0
0
—a
1
INTERRUPT
—
INTERRUPT
1
Action
aAlthough
the existence of the interrupt condition is not indicated to the link, the PHY register bits that describe the interrupt condition remain set until cleared by a PHY register write.
The second function of Watchdog affects the creation of an interrupt condition. If the Watchdog bit is one, Port_event shall be set to 1; and an interrupt condition shall be created when resume operations commence for any port. Once an interrupt condition has been created, the method used to indicate it to the link depends upon the operational state of the PHY-link interface. When the interface is operational, it is used to report the INTERRUPT event; otherwise, the INTERRUPT event causes the assertion of the LinkOn signal (see 17.3.4 for details).
Copyright © 2008 IEEE. All rights reserved.
393
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The Loop, Pwr_fail, Timeout, and Port_event bits are unaffected by PHY register writes if the corresponding bit position is zero. When the bit written to the PHY register is one, the corresponding bit is set to 0. The upper half of the PHY register space, addresses 10002 through 11112 inclusive provides a windows through which additional pages of PHY registers may be accessed. IEEE Std 1394 defines page 0, page 1, and page 7: the Port Status page, the Vendor Identification page, and a vendor-dependent page. Other pages are reserved.
15.2.1 Port Status page The Port Status page is used to access configuration and status information for each of the PHY’s ports. The port is selected by writing zero to Page_select and the desired port number to Port_select in the PHY register at address 01112. If the value of Port_select specifies an unimplemented port, all of the registers of the Port Status page shall be reserved. The format of the Port Status page is illustrated by Figure 15-2; reserved fields are shaded in grey.
Address 10002
0
1 AStat
10012
2
3 BStat
negotiatedSpeed
intEnable
4
5
5
7
child
connected
receiveOK
disabled
Fault
Standby Fault
disable Scrambler
Beta_Mode Only_Port
10102
dc Connected
IPP
10112
connection Unreliable
betaMode
11002 11012
cableSpeed tMode
802Mode
T_Mode Port
loop Disable
inStandby
hard Disable
portError De-emph. disable
sleep flag
sleep enabled
long Contend
11102 11112
Figure 15-2—PHY register page 0: Port Status page Beta ports shall implement all the fields shown in Figure 15-2. Alpha ports shall implement the fields from AStat through fault. The standby_Fault field and all fields with higher addresses are not required for Alpha ports and shall be reserved. The meanings of the register fields within the Port Status page are defined by Table 15-3.
394
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 15-3—PHY register Port Status page fields Size
Type
Power reset value
802Mode
1
rc
0
Set for a port if the result of Auto-Negotiation is that the port is operating in 802_mode.
AStat
2
ru
002
TPA line state for the port (only valid if a DS port): 002 = invalid 012 = 1 102 = 0 112 = Z
betaMode
1
ru
0
If equal to 1, the port is operating in Beta mode; equal to 0 otherwise (i.e., when operating in DS mode or when disconnected). If the connected field is 1 and the betaMode field is 0, then the port is operating in DS mode.
BETA_MODE_ ONLY_PORT
1
r
See description
Implementation-dependent constant. If equal to 1, the port is not capable of DS mode operation.
BStat
2
ru
002
cableSpeed
3
r
See description
child
1
ru
connected
1
ru
0
If equal to 1, the port is connected and (Beta mode only) operating speed negotiation completed.
connectionUnreliable
1
rcu
0
If equal to 1, a Beta mode speed negotiation has failed or synchronization has failed. A write of 1 to this field resets the value to 0.
dcConnected
1
ru
0
If equal to 1, the port has detected a dc connection to the peer port (by means of a dc connect detect circuit, if implemented).
De-emphasis disable
1
rw
0
Used by test software to control the use of de-emphasis during S1600 transmission. Always zero unless the port is capable of operating at S1600. May be set by software at any time for a port that is capable of operating at S1600 but has no effect unless the port is operating at S1600. When 1, the use of de-emphasis for the second and subsequent bits when transmitting a series of identical bits when the port is operating at S1600 is inhibited and all bits are transmitted at full amplitude. Intended for use as a test mode only, not used during normal operation.
Field
Copyright © 2008 IEEE. All rights reserved.
Description
TPB line state for the port (only valid if a DS port) (same encoding as the AStat field). Set by implementation-dependent means to the maximum speed at which the cable attached to the port is allowed to operate. If no cable-dependent speed indication is available, then the implementation shall set this variable to the maximum speed of which the port is capable. The encoding is the same as for the maxPortSpeed field. If equal to 0, the port is a parent; otherwise it is a child port (or disconnected or disabled). The meaning of this bit is undefined from the time a bus reset is detected until the PHY transitions to state T1: Child Handshake during the tree identify process (see 16.4.6).
395
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 15-3—PHY register Port Status page fields (continued) Size
Type
Power reset value
disableScrambler
1
rw
0
When equal to 1, the port inhibits the operation of the scrambler during transmission of a packet so that transmitted scrambled data are equal in value to unscrambled data. Note that control states and request types continue to be scrambled. Intended for use as a test mode only, not used during normal operation.
disabled
1
rwu
See description
If equal to 1, the port is disabled. The value of this bit subsequent to a power reset is implementationdependent. If a hardware configuration option is provided, a single option may control the power reset value for all ports. See also the hardDisable field.
fault
1
rcu
0
Set to 1 if an error is detected during a suspend or resume operation; cleared on exit from the suspended state. A write of one to this bit or receipt of the appropriate remote command packet (see 16.3.3.2 and 16.3.2.4.4) shall clear it to zero. When this bit is zeroed, both resume and suspend errors are cleared.
hardDisable
1
rw
0
No effect unless the port is disabled. If equal to 1, the port does not maintain connectivity status on an ac connection when disabled. The values of the connected and receiveOk fields are forced to 0. This flag can be used to force renegotiation of the speed of a connection.
intEnable
1
rw
0
Enables port event interrupts. When set to 1, the PHY shall set the portEvent field to one if any of this port’s Bias (unless the port is disabled), Connected, Disabled, Fault, Standby or standbyFault bits change state.
localPlugPresent (lPP in the map)
1
ru
See description
Indicates that an external implementation-dependent mechanism has determined that there is at least a physical connection from the local port (maybe not connected at the “far end”). If there is no such mechanism, then this flag shall be set permanently to 1.
longContendTimer
1
rw
See description
Indicates that long root contend times should be used on this port. Default is 1 for T-mode ports and 0 for all other ports. If software sets this value, then software shall ensure that the same value is used by a port and its peer.
loopDisable
1
ru
0
Set if the port has been placed in the loopDisable state as part of the loop-free build process (the PHYs at both ends of the connection are active; but if the connection itself were activated, then a loop would exist). Cleared on bus reset and on disconnection.
Field
396
Description
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 15-3—PHY register Port Status page fields (continued) Field
Power reset value
Size
Type
maxPortSpeed
3
rw
See description
The maximum speed at which a port is allowed to operate in Beta mode. The encoding is 0002 S100 0012 S200 0102 S400 0112 S800 1002 S1600 1012 S3200 1102 reserved 1112 DS_MODE_ONLY (port is not capable of operating in Beta mode) An attempt to write to the register with a value greater than the hardware capability of the port results in the maximum value that the port is capable of being stored in the register. The port uses this register only when a new connection is established in Beta mode. The power reset value is the maximum value that the port is capable of, or the read-only value of 1112 for a DS_MODE_ONLY port.
negotiatedSpeed
3
ru
0002
Indicates the maximum speed negotiated between this PHY port and its immediately connected port; the encoding is as for the maxPortSpeed field. Set to a speed corresponding to the value of the portSpeed variable. This field is set on connection when in Beta mode, or to value established during self-identification sequence when in DS mode.
portError
8
rcu
0
Incremented whenever the port receives an INVALID codeword, unless the value is already 255. Cleared when read (including being read by means of a remote access packet). Intended for use by a single bus-wide diagnostic program.
receiveOk
1
ru
0
In DS mode, indicates the reception of a debounced TpBias signal. In Beta mode, indicates the reception of a continuous electrically valid signal. Note that the receiveOk field is set to false during the time that only connection tones are detected in Beta mode.
sleep flag sleep enabled
2
inStandby
1
ru
0
Set to 1 if the port is in standby (in states P7–P10; see 14.5).
standbyFault
1
rcu
0
Set to 1 if an error is detected during a standby operation and cleared on exit from standby. A write of one to this bit or receipt of the appropriate remote command packet (see 16.3.3.2 and 16.3.2.4.4) shall clear it to zero. When this bit is zeroed, standby errors are cleared.
Description
The use of these bits is defined in IDB-1394 (see [B1] for details.)
Copyright © 2008 IEEE. All rights reserved.
397
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 15-3—PHY register Port Status page fields (continued) Size
Type
Power reset value
tMode
1
rc
0
Set for a T_MODE_CAPABLE_PORT or T_MODE_PORT if the result of Auto-Negotiation is that the port is operating in T-mode.
T_MODE_PORT
1
r
See description
Implementation-dependent constant. Set if the port is only capable of operating in T-mode (and, therefore, not in Beta mode or DS mode).
Field
Description
15.2.2 Vendor Identification page The Vendor Identification page is used to identify the PHY’s vendor and compliance level. The page is selected by writing one to Page_select in the PHY register at address 01112. The format of the Vendor Identification page is illustrated by Figure 15-3; reserved fields are shaded in grey.
Contents Address 10002
0
1
2
3
4
5
6
7
Compliance_level
10012 10102 10112
Vendor_ID
11002 11012 11102
Product_ID
11112
Figure 15-3—PHY register page 1: Vendor Identification page The meanings of the register fields within the Vendor Identification page are defined by Table 15-4.
398
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 15-4—PHY register Vendor Identification page fields Field
Size
Type
Description
Arbitration_compliance_ level
8
r
Indicates the Arbitration Compliance Level (see 15.1) of the PHY: 0 = Not specified 1 = Level A 2 = Level B All other values reserved for future standardization
Vendor_ID
24
r
Indicates the OUI of the manufacturer of the PHY. This number is obtained from the IEEE Registration Authority. The most significant byte of Vendor_ID appears at PHY register location 10102 and the least significant at 11002.
Product_ID
24
r
Is a number whose meaning is determined by the company or organization that has been granted Vendor_ID. The most significant byte of Product_ID appears at PHY register location 11012 and the least significant at 11112.
15.3 PHY register map for the backplane environment The PHY register map for the backplane environment is related to that of the cable environment; some fields are not present, while other fields changeable in the cable environment have a fixed value in the backplane environment, and vice versa. The PHY register map for the backplane environment is illustrated by Figure 15-4; reserved fields are shown shaded in gray.
Figure 15-4—PHY register map for the backplane environment
The meaning, encoding, and usage of all the fields in the backplane PHY register map are summarized by Table 15-5.
Copyright © 2008 IEEE. All rights reserved.
399
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 15-5—PHY register fields for the backplane environment Field
Size
Type
Description
Physical_ID
6
rw
The address of this node. Unlike the equivalent field in the cable environment, the physical ID in the backplane environment is writable.
CM
1
rwa
Cycle master. The value of this bit does not affect the operation of the PHY, it is present in the backplane PHY register map for the sake of compatibility with some link designs that do not operate as cycle master unless this bit is set to one.
TD
1
rw
Transceiver disable. When set to one the PHY shall set all bus outputs to a high-impedance state and ignore any link layer service actions that would require a change to this bus output state.
IBR
1
rw
Initiate bus reset. When set to one, instructs the PHY to initiate a bus reset immediately (without arbitration). This bit causes assertion of the reset signal for approximately 8 ìs and is self-clearing.
Data
2
r
Data line state (uses the same encoding as for cable).b
Strobe
2
r
Strobe line state (uses the same encoding as for cable).b
Priority
4
rw
This field shall contain the priority used in the urgent arbitration process and shall be transmitted as the pri field in the packet header.
aIt is permitted to implement CM as a read-only bit, in which case its value shall be zero. bThe implementation of the Data and Strobe fields is optional; if unimplemented, these fields
shall be zero.
15.4 Integrated link and PHY The register map described in 15.2 and 15.3 is specified to assure interoperability between discrete link and PHY implementations offered by different vendors. Because the PHY registers are the only means available to software to control or query the state of the PHY, these register definitions are also critical to software. An integrated link and PHY implementation, unless operating as a PIL, shall present the appropriate register map standardized in 15.2 and 15.3. The status that may be read from the registers and the behavior caused by a write to the registers shall be identical with the status and behavior of a discrete link and PHY combination. When an integrated link and PHY are operating as a PIL, the PIL shall present to software the registers from the attached FOP. The registers in the PIL’s integrated PHY are not visible to software.
400
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
16. Data routing, arbitration, and control This clause specifies the processes for gaining control of the bus and routing data between the various ports of a PHY (including any attached link). These PHY functions include bus initialization (i.e., reset, tree identify, and self-identify), normal arbitration, and packet transmission and reception (including PHY packets).
16.1 Overview The relationship and interfaces between the arbitration state machines and other functions and layers are illustrated in Figure 16-1:
link Beta PHY
port controller
request/grant, enable
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
Port
Betamode functions
Connection management
DS-mode functions
Betamode functions
Low-power signaling
UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
Connection management
DS-mode functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
to other ports
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
Figure 16-1—PHY master architecture (data routing, arbitration, and control interfaces in context)
Copyright © 2008 IEEE. All rights reserved.
401
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.2 PHY services PHY services are provided at the interface between the PHY and higher layers, specifically, the link layer and the node controller. The method by which these services are communicated between the layers is defined in Clause 17 and Clause 18. A PHY can provide services for either an Alpha link or one that meets the requirements of this standard. For that reason, each service interface may have unique entries for Alpha and Beta higher layers. See Table 16-1.
Table 16-1—Summary of PHY services Service
Direction of communication and corresponding layer
Purpose of service
PHY control request
From the node controller
Configures the PHY
PHY control confirmation
To the node controller
Confirms the PHY control request
PHY event indication
To the link layer
Alerts the link layer of events detected in the PHY
PHY event response
From the link layer
Acknowledges from the link layer that an event indication was received
PHY link type inquiry indication or response
To or from the link layer
Determines the types of link
PHY arbitration request
From the link layer
Causes the PHY to request control of the bus
PHY arbitration confirmation
To the link layer
Confirms the PHY arbitration request
PHY clock indication
To the link layer
Indicates when it is time for the link layer to make a PHY data request
PHY data request
From the link layer
Causes the PHY to send one clocked data symbol or to start or end a data packet
PHY data indication
To the link layer
Indicates the reception of one clocked data symbol or a bus status change
PMD control request
To the PMD layer
Configures the PMD for a port
PMD status request or confirmation
To or from the PMD layer
Determines the PMD status of the port
PMD data indication
From the PMD layer
Receives Beta-mode data from a Beta port
PMD data request
To the PMD layer
Sends Beta-mode data from a Beta port
PMD DS port receive signal request or confirmation
To or from the PMD layer
Determines the currently received data signal on a DS port
PMD DS port receive speed request or confirmation
To or from the PMD layer
Determines the currently received speed signal on a DS port
PMD DS port transmit data request
To the PMD layer
Sends a data bit from a DS port
PMD DS port transmit arbitration state request
To the PMD layer
Sends an arbitration state from a DS port
402
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 16-1—Summary of PHY services (continued) Service
Direction of communication and corresponding layer
Purpose of service
PMD DS port transmit speed request
To the PMD layer
Sends a speed signal from a DS port
PMD DS port TpBias request
To the PMD layer
Sets the transmitted bias for a DS port
PMD cable power status request or confirmation
To or from the PMD layer
Determines the cable power status
PMD cable speed request or confirmation
To or from the PMD layer
Determines the speed capabilities of the attached cable
16.2.1 Cable PHY bus management services for the management layer Cable PHY bus management services are used by the node controller component of the SBM layer to control the bus level actions of the PHY. The PHY uses these services to communicate changes of state within the PHY or on the bus.
16.2.1.1 PHY control request (PH_CONTROL.request) The node controller uses the PHY control request service to request the PHY to perform specific actions and to specify PHY parameters. It may also be used to request status about the PHY. The PHY shall service the request immediately upon receipt. This service is confirmed. The following parameters are communicated by this service (see Clause 15 for descriptions of the PHY register fields): —
PHY register address. The register number in the PHY to be accessed.
—
Write. True when the indicated PHY register is to be written.
—
PHY register value. (Valid only when the Write parameter is true.) An 8-bit value to be written to the indicated PHY register.
16.2.1.2 PHY control confirmation (PH_CONTROL.confirmation) The PHY uses the PHY control confirmation service to confirm the results of a PHY control request service. The PHY shall communicate this service to the node controller upon completion of a PHY control request. No actions are provided by this service. When the corresponding PHY control request Write parameter is false, the following parameter is communicated by this service: —
PHY register read value. The value of the indicated PHY register address in the corresponding PHY control request.
16.2.1.3 PHY event indication (PH_EVENT.indication) The PHY uses the PHY event indication service to indicate PHY-level events to the node controller. No actions are provided by this service. The PHY event response (see 16.2.1.4) is defined as an acknowledge for this indication. The following parameters are communicated via this service: —
Indication. The event detected by the PHY. The following values are defined for this parameter: PH_LINK_ON. The PHY has received a link-on packet addressed to this node or generated on power reset when the POWER_CLASS is 0 through 4.
Copyright © 2008 IEEE. All rights reserved.
403
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
PH_BUS_RESET_START. The PHY has detected a bus reset. Any outstanding requests (i.e., asynchronous, isochronous, or immediate) are cancelled. NOTE—More than one BUS_RESET_START can be generated before the PH_BUS_RESET_
COMPLETE event is generated.
PH_SELF_IDENTITY. Self-ID is given during bus initialization, after a bus reset, or after a restore. The Physical_ID and Root parameters shall also be valid for this indication (see the end of this list). PH_BUS_RESET_COMPLETE. The PHY has detected a subaction gap after the bus reset process has started. PH_INTERRUPT. The PHY has generated an interrupt. The reason for the interrupt can be determined by using a PHY control request. PH_CABLE_POWER_FAIL. The PHY has detected a loss of cable power. PH_CONFIG_TIMEOUT. The PHY has not completed the PHY initialization due to a timeout in the tree identify process. NOTE—The PH_CONFIG_TIMEOUT may indicate a loop in the topology that could not be broken (i.e., the loop consists entirely of connections between DS ports).
PH_MAX_ARB_STATE_TIMEOUT. The PHY has stayed in a state (except A0: Idle state during the time that idle_arb_state_timeout is false, T0: Tree ID Start state, or a state that has an explicit timeout) for longer than MAX_ARB_STATE_TIME. PH_RESTORE_RESET. The PHY has determined that a bus reset occurred on the bus while the port was in standby (e.g., may be generated in the nephew at the end of a restore operation). PH_RESTORE_NO_RESET. The PHY is reporting that the port that was in standby has commenced a restore operation and that the previous Physical_ID is invalid. The link shall not issue requests until it has sufficient information. This information includes having a valid Physical_ID before making any bus request, knowing the isochronous interval before making an isochronous request, and/or knowing the asynchronous interval before making a NEXT_EVEN/ODD asynchronous request. (However, it may make a CURRENT request.) This indication shall be generated only in the nephew. NOTE—Other nodes will not have completed their reset processing until the Indication of PH_BUS_RESET_COMPLETE has been received.
—
Physical_ID. (Conditional, valid only when the Indication parameter is PH_SELF_IDENTITY.) This parameter contains a unique 6-bit number, as determined by the self-identify process.
—
Root. (Conditional, valid only when the Indication parameter is PH_SELF_IDENTITY.) This boolean parameter is true only when this node is the root, as determined by the tree identify process.
16.2.1.4 PHY event response (PH_EVENT.response) The link layer synthesizes the PHY event response service to acknowledge the receipt of a PHY event indication of PH_BUS_RESET_START, PH_RESTORE_NO_RESET, and PH_RESTORE_RESET.
16.2.1.5 PHY link type inquiry indication (PH_LINK_TYPE.indication) and response (PH_LINK_TYPE.response) The PHY uses the PHY link type inquiry indication and response service pair to request the type of link attached to the PHY. No actions are provided by this service. The PHY link type inquiry response is defined as an acknowledge for this indication. The following parameters are communicated via the response service:
404
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
—
IEEE Std 1394-2008
linkType. This parameter contains the event detected by the PHY. The following values are defined for this parameter: B_LINK. The link attached to this PHY is a Beta link. LEGACY_LINK. The link attached to this PHY is an Alpha link. NOTE—The C code uses a unified PH_LINK_TYPE_response, which combines the functions of this indication and the corresponding response.
16.2.2 PHY arbitration services for the link layer PHY arbitration services are used to communicate arbitration requests between the PHY and the link layer.
16.2.2.1 PHY arbitration request (PH_ARB.request) The link layer uses the PHY arbitration request service to request the PHY to start arbitration for the bus. The PHY shall arbitrate for the bus using the method specified by the service parameters. The PHY shall service the request immediately upon receipt from the link layer. For Alpha link layers, this service shall be confirmed when the arbitration process completes. If a node loses arbitration (PH_ARB.confirmation with an arbitration request status of LOST), it shall reissue the arbitration request. For Beta link layers, the asynchronous (CURRENT, NEXT_EVEN, NEXT_ODD), cycle master, isochronous (ISOCH_ODD and ISOCH_EVEN), and immediate requests have independent confirmations. This allows one request of each type to be active at a time. The following parameters are communicated via this service: —
reqType. This parameter contains the method of arbitration performed by the PHY arbitration request. The method of arbitration shall be one of the following: PH_IMMED_REQ. A PHY arbitration confirmation with an arbitration request status of WON shall be communicated to the link layer as soon as the bus is idle. (The link layer uses this method to send an acknowledge packet.) PH_NEXT_EVEN (Beta). The PHY shall arbitrate as required for the next even fairness interval (or the current interval, if even). This supersedes any previously queued PH_NEXT_ODD or PH_NEXT_CURRENT request. PH_NEXT_ODD (Beta). The PHY shall arbitrate as required for the next odd fairness interval (or the current interval, if odd). This supersedes any previously queued PH_NEXT_EVEN or PH_NEXT_CURRENT request. PH_CURRENT (Beta). The PHY shall arbitrate as required for the current fairness interval. This supersedes any previously queued PH_NEXT_ODD or PH_NEXT_EVEN request. PH_ISOCH_REQ_EVEN (Beta). The PHY shall arbitrate as required for the next even isochronous interval (or the current interval, if even). This supersedes any previously queued PH_ISOCH_REQ_ODD request. PH_ISOCH_REQ_ODD (Beta). The PHY shall arbitrate as required for the next odd isochronous interval (or the current interval, if odd). This supersedes any previously queued PH_ISOCH_REQ_EVEN request. PH_CYC_START_REQ (Beta). The PHY shall arbitrate as required for the current fairness interval with higher priority than any other queued asynchronous request. PH_LPS_ACTIVE. The PHY shall report the L bit in any subsequent self_ID as true if lctrl is also true. PH_LPS_INACTIVE. The PHY shall report the L bit in any subsequent self_ID as false and shall give a PHY_Event of LINK_ON if it receives a link-on packet.
Copyright © 2008 IEEE. All rights reserved.
405
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
PH_ISOCH_PHASE_ODD (Beta). The PHY shall enter the isochronous interval (if not already in the isochronous interval) and set the phase to ODD. The link issues this indication on receipt of a cycle start packet if it intends to perform isochronous transfers. PH_ISOCH_PHASE_EVEN (Beta). The PHY shall enter the isochronous interval (if not already in the isochronous interval) and set the phase to EVEN. The link issues this indication on receipt of a cycle start packet if it intends to perform isochronous transfers. PH_CYCLE_START_DUE. The PHY shall refrain from using accelerations and arbitrations that could result in cycle start starvation (i.e., until it receives a PH_CYCLE_START_SEEN, PH_ISOCH_REQ, or PH_ISOCH_PHASE_* or until it receives or transmits a CYCLE_START_* token). This indication should be issued by cycle slaves once every isochronous period, as soon as possible after the local clock indicates the start of a new isochronous period. The PHY shall permanently refrain from using accelerations and arbitrations that could result in cycle start starvation from power reset or PHY-link interface disable until it receives this indication. PH_CYCLE_START_SEEN (Alpha). The PHY may use accelerations once again. (Used after accelerations are disabled by PH_CYCLE_START_DUE.) PH_ISOCH_REQ (Alpha). The PHY shall start arbitration as soon as the bus is idle. (The link layer uses this method to send an isochronous packet.) PH_PRIORITY_REQ (Alpha). The PHY shall arbitrate as required for the current fairness interval. PH_FAIR _REQ (Alpha). The PHY shall start arbitration for the current fairness interval if its arb_enable flag is set; otherwise, it shall start arbitration at the next arbitration reset gap. —
speed. (Conditional, valid only when reqType is PH_IMMED_REQ, PH_NEXT_EVEN, PH_NEXT_ODD, PH_CURRENT, PH_ISOCH_REQ_EVEN, PH_ISOCH_REQ_ODD, PH_PRIORITY_REQ, PH_CYC_START_ REQ, PH_ISOCH_REQ, or PH_FAIR_REQ.) This parameter indicates which data rate is to be used to generate all subsequent PHY clock indication events until the next PHY data request with a DATA_END parameter. The speed code shall be one of the speed codes listed in Table 16-2.
Table 16-2—Cable PHY speed codes Speed code
Comment
S100
Base rate. All nodes are required to be capable of transmitting and receiving packets at this rate.
S200
All nodes capable of the S200 data rate are also required to be capable of operating at the S100 data rate.a
S400
All nodes capable of the S400 data rate are also required to be capable of operating at the S100 and S200 data rates.a
S800
All nodes capable of the S800 data rate are also required to be capable of operating at the S100, S200, and S400 data rate.a
S1600
All nodes capable of the S1600 data rate are also required to be capable of operating at the S100, S200, S400, and S800 data rates.a
S3200
All nodes capable of the S3200 data rate are also required to be capable of operating at the S100, S200, S400, S800, and S1600 data rates.a
a
For ports operating in Beta mode, data rates lower than the negotiated rate are supported using the data padding technique described in Clause 13.
406
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
—
IEEE Std 1394-2008
beta_format. (Conditional, valid only when reqType is PH_IMMED_REQ (Beta), PH_NEXT_EVEN, PH_NEXT_ODD, PH_CURRENT, PH_ISOCH_REQ_EVEN, PH_ISOCH_REQ_ODD, or PH_CYC_START_REQ. Shall be assumed to be false if reqType is PH_IMMED_REQ for an Alpha link.) The following boolean values are defined for this parameter: True. The PHY shall transmit the packet in Beta format. False. The PHY shall transmit the packet in Alpha format unless it can determine that the packet will be delivered correctly if transmitted in Beta format.
16.2.2.2 PHY arbitration confirmation (PH_ARB.conf) The PHY uses the PHY arbitration confirmation service to confirm the results of a PHY arbitration request service. The PHY shall communicate this service to the link layer upon completion of a PHY arbitration request. No actions are provided by this service. The following parameters are communicated via this service: —
Confirmation. This parameter contains the result of a PHY arbitration request action. The following values are defined for this parameter: PH_WON (Alpha). The PHY has won arbitration as a result of the most recently issued PH_ARB.request or PH_DATA.request of PH_REQ_DATA_PREFIX. PH_LOST (Alpha). If a PH_ARB.request is outstanding, then the PHY has lost arbitration. Any outstanding request is cancelled. This confirmation is issued regardless of whether a request was issued to indicate start of cancellation period. Will be issued only for cancellation of asynchronous requests. PH_LOST shall always be followed immediately by PH_DATA_PREFIX (when enab_accel is false) or PH_DATA_BYTE or PH_DATA_END (when enab_accel is true).23,24 PH_WON_IMMED (Beta). The PHY has won arbitration as a result of the most recently issued PH_ARB.request of PH_IMMED_REQ. PH_WON_ISOCH (Beta). The PHY has won arbitration as a result of the most recently issued PH_ARB.request of PH_ISOCH_REQ_EVEN or PH_ISOCH_REQ_ODD. PH_WON_CYCLE_START (Beta).The PHY has won arbitration as a result of the most recently issued PH_ARB.request of PH_CYC_START_REQ. PH_WON_ASYNC (Beta). The PHY has won arbitration as a result of the most recently issued PH_ARB.request of PH_NEXT_EVEN, PH_NEXT_ODD, or PH_CURRENT.
—
Speed_Code. (Conditional, valid only when the Confirmation parameter is not PH_LOST or PH_WON.) Indicates the speed that is used for the packet using this arbitration opportunity. The values defined for this parameter are the same as the values in Table 16-2.
—
pkt_format. (Conditional, valid only when PH_ARB_indication is not PH_LOST or PH_WON.) This boolean parameter indicates the format that was requested for the packet using this arbitration opportunity.
16.2.3 PHY data services for the link layer PHY data services are used to communicate data symbols and control information between the PHY and the link layer.
23In
the absence of an explicit handshake and/or acknowledgement with the link layer, an actual implementation needs to ensure that all requests subject to cancellation (including requests possibly in flight to the PHY) issued by the link layer prior to reception of the PH_LOST at the link layer are cancelled appropriately by the PHY. 24 An implementation of the PHY-link interface need not implement PH_LOST as an explicit signal. A link may infer PH_LOST from PH_DATA_PREFIX (when enab_accel is false) or PHY_DATA_PREFIX followed by either more than one PH_DATA_BYTE or PH_DATA_END (when enab_accel is true).
Copyright © 2008 IEEE. All rights reserved.
407
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.2.3.1 PHY clock indication (PH_CLOCK.indication) The PHY uses the PHY clock indication service to indicate to the link layer that a data symbol transmission is about to occur. No actions are provided by this service. The link layer shall respond to this indication with a PHY data request. No parameters are communicated via this service. The PHY shall begin communicating this indication to the link layer after it has communicated a PHY arbitration confirmation other than PH_LOST. The PHY shall stop communicating this indication to the link layer after the link layer communicates a PH_DATA.request of PH_REQ_DATA_END, PH_REQ_DATA_PREFIX, or PH_REQ_SUBACTION_END. This indication occurs once for each symbol time as specified by the corresponding PHY arbitration request.
16.2.3.2 PHY data request (PH_DATA.request) The link layer uses the PHY data request service to control the PHY’s transmission of clocked data symbols. The link layer shall communicate one PHY data request for each PHY clock indication. The PHY shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameters are communicated via this service: —
reqType. This parameter contains the type of symbol to be transmitted on the bus. The following values are defined for this parameter: PH_REQ_DATA. The PHY shall transmit an 8-bit data byte. PH_REQ_DATA_PREFIX (Alpha). The PHY shall stop sending clocked data bytes and prepare to transmit a concatenated packet. When ready to transmit the concatenated packet, the PHY gives a PH_Confirmation of PH_WON. PH_REQ_DATA_END. The PHY shall stop sending clocked data bytes and terminate the packet appropriately. If, in the case of an Alpha link, the PHY can determine that the packet marks the end of a subaction, it shall behave as if it had received a PH_REQ_SUBACTION_END. PH_REQ_SUBACTION_END (Beta). The PHY shall stop sending clocked data bytes and terminate the packet appropriately. It may terminate the packet with a GRANT or GRANT_ISOCH token to satisfy a pipelined request from the link or a request received over the bus of the current phase, or it may end the interval if appropriate. The link shall give this indication in preference to PH_REQ_DATA_END when the packet marks the end of a subaction (i.e., broadcast packets, isochronous packets, asynchronous stream packets, and acknowledge packets). The link shall not issue a MORE_INFO cycle indicating the end of a subaction after originating a PHY packet. PH_REQ_HOLD. The PHY shall continue to transmit DATA_PREFIX. The link layer issues this request after receiving a confirmation other than PH_LOST and before it issues any other data request.
—
data. (Conditional, present only when the reqType is PH_DATA_BYTE.) This parameter shall contain the 8-bit value to be transmitted.
—
speed. (Conditional, present only when reqType is PH_REQ_DATA_PREFIX.) This parameter shall contain the speed code to be transmitted. The values defined for this parameter are S100, S200, and S400 (shown in Table 16-2).
Once the link layer starts sending a data byte, it shall transmit the entire packet. The link layer shall stop transmitting within a MAX_BUS_OCCUPANCY of receiving a confirmation other than PH_LOST.
408
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
16.2.3.3 PHY data indication (PH_DATA.indication) The PHY uses the PHY data indication service to indicate to the link layer changes in the state of the PHY. These changes can include received data, PHY-originated data (which is copied to the link layer), and other bus events. The PHY shall communicate this indication to the link layer for each data byte transferred to the link. If the PHY is not transferring data bytes to the link, it uses this indication to communicate indications needed by the link layer. No response is defined for this indication. The following parameters are communicated via this service: —
Indication. This parameter contains the information decoded by the PHY that is needed by the link layer. The following values are defined for this parameter: PH_DATA_START. Delivery of clocked data to the link is about to begin. PH_DATA_BYTE. An 8-bit data byte is delivered to the link. PH_DATA_PREFIX. The bus is busy. This indication is always given before a PH_DATA_START and may be given after the last data byte of a packet. PH_DATA_END. The last data byte of a packet has been delivered, and the bus is no longer busy. PH_SUBACTION_GAP (Alpha). A subaction gap event has been detected on the bus. Any outstanding isochronous request will be cancelled. PH_SUBACTION_GAP (Beta). An ASYNC_START token is delivered to the link. PH_ARBITRATION_RESET_GAP (Alpha). An arbitration reset gap event has been detected on the bus. PH_ARB_RESET_ODD (Beta). An ASYNC_ODD token is delivered to the link. PH_ARB_RESET_EVEN (Beta). An ASYNC_EVEN token is delivered to the link. PH_ISOCH_ODD (Beta). A CYCLE_START_ODD token is delivered to the link. PH_ISOCH_EVEN (Beta). A CYCLE_START_EVEN token is delivered to the link.
—
Speed_Code. (Conditional, present only when the Indication parameter is PH_DATA_START.) This parameter indicates which data rate (see Table 16-2) will be used during all subsequent PHY data indication services for the current packet.
—
Data_Byte. (Conditional, present only when the Indication parameter is PH_DATA_BYTE.) This parameter contains the 8-bit data value.
—
pkt_format. (Conditional, present only when the Indication parameter is PH_DATA_START.) This parameter shall be one of the following: ALPHA. The following packet was transmitted in Alpha format. BETA. The following packet was transmitted in Beta format.
16.2.4 PHY-link interface block This subclause is written in terms of an abstract PHY-link block, which implements the services specified in 16.2.1 through 16.2.3. In addition, it tracks the arbitration state machine, deals with link interface reset, and covers issues. On link-initiated interface resets (via LPS), the PHY-link block shall —
Ensure that no PH_ARB.request that was previously issued by the link (before the link issued the interface reset) is sent to the PHY for queueing.
—
Invoke cancel_requests() at the PHY by issuing PH_LPS_INACTIVE.
—
Handshake with the PHY to terminate the packet if transmitting when the interface reset commences.
—
Remember the last PH_SELF_IDENTITY and PH_ARB_RESET_ODD/EVEN issued by the arbitration state machine for possible transmission to the link during the completion of the interface reset.
Copyright © 2008 IEEE. All rights reserved.
409
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
—
Ensure that no partial packets or partial status transfers are sent to the link.
—
Issue a PH_DATA.request(PH_REQ_DATA_END) to handshake with the PHY if granted during the reset interval.
On PHY-initiated bus reset and restore on a nephew, the PHY-link block shall —
Handshake with PH_EVENT_response. (After that step, the arbitration state machine shall cancel requests.)
—
Ensure that no PH_ARB.request is sent to the PHY for queueing until the bus reset or restore event (as appropriate) has been received by the link layer and any in-flight requests have been flushed.
16.2.5 PMD services for the PHY An individual PMD layer exists for each port on a PHY; therefore, an instance of each of the service interfaces in 16.2.5.1 through 16.2.5.12 occurs for each port (except for PMD_PS.request, which is not port specific).
16.2.5.1 PMD control request (PMD_CONTROL.request) The PHY uses the PDM control request service to control the PMD layer. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameters are communicated via this service: —
control_request. This parameter contains the type of request to be made to the PMD layer. The following values are defined for this parameter: — — — — — — — — — —
—
PMD_CROSSOVER. A TPA-TPB crossover is implemented (see 12.4.5). PMD_NO_CROSSOVER. Any TPA-TPB crossover is removed (see 12.4.5). PMD_TONE_ON. Instructs the PMD to generate a tone (see 9.3.5.1). Infers PMD_UNSELECT_PORT. PMD_TONE_OFF. The PMD is instructed to cease generating a tone, remove the signalling bias voltage, and set the port transmitters to high impedance. PMD_SELECT_BPORT. The Beta port PMD is selected for Beta-mode input and output (I/O). PMD_SELECT_DS_PORT. The DS port PMD is selected for data, arbitration line states, and common-mode speed signals. PMD_UNSELECT_PORT. Control of port signalling is removed from the T-mode port, Beta port, or DS port (as appropriate). A T-mode port will maintain connectivity status. PMD_START_NEGOTIATE. The PMD layer is instructed to perform T-mode/Ethernet negotiation. PMD_SELECT_TPORT. The PMD layer is instructed to use the port for T-mode I/O (set only while tportOn is TRUE; unset during suspend, etc.) The port will synchronize with its peer and return the status of PMD_TPORT_OK when synchronization has been established. PMD_TPORT_OFF. The PMD layer is disabled.
speed. (Conditional, present only when the control_request parameter is PMD_SELECT_BPORT.) This parameter indicates the operating speed of the port.
16.2.5.2 PMD status request (PMD_STATUS.request) and confirmation (PMD_STATUS.confirmation) The PHY uses the PMD status request and confirmation service pair to request status from the PMD layer. The PMD layer shall service the request immediately upon receipt and respond with the PMD status confirmation. NOTE—The C code uses a unified PMD_STATUS_request, which combines the functions of this request and the corresponding confirmation.
410
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The following parameters are communicated by the PMD confirmation: —
PMD_BIAS_DETECT. This parameter contains the undebounced output of the PMD bias comparator.
—
PMD_CONNECT_DETECT. This parameter contains the undebounced PMD output of connect detect comparator.
—
PMD_LOCAL_PLUG_PRESENT. When ac-coupled (possibly via, e.g., an optical transceiver), this parameter indicates that an external implementation-dependent mechanism has determined that at least a physical connection exists from the local node to a cable (although a connection may not exist to the peer port). This parameter is used to avoid performing connection toning if no connection definitely exists. If no such mechanism exists, then this parameter shall be set permanently to TRUE.
—
PMD_SIGNAL_DETECT. The PMD sets this parameter if it detects a signal as specified by the signal detect specification of the specific PMD.
—
PMD_AUTOCROSSOVER_SUPPORTED. The PMD sets this parameter if the crossover control requests are supported.
—
PMD_NEGOTIATION_ACTIVE. The PMD sets this parameter while it is carrying out Tmode/Ethernet negotiation
—
PMD_TPORT_FW. The PMD sets this parameter if autonegotiation has established T-mode
—
PMD_TPORT_802. The PMD sets this parameter if autonegotiation has established operation according to IEEE 802.3 higher layer specifications
—
PMD_TPORT_OK. The PMD sets this parameter if the connection is synchronized (T-mode only) and ready for normal control symbol, arbitration symbol, and data exchange.
16.2.5.3 PMD Beta port data indication (PMD_DATA.indication) The PMD layer uses the PMD Beta port data indication service to indicate to the PHY the data originated by the PMD layer. (These data are copied to the PHY.) The following parameter is communicated via this service: —
data. This parameter contains the data bit to be received.
16.2.5.4 PMD Beta port transmit data request (PMD_DATA.request) The PHY uses the PMD Beta port transmit data request service to transmit a data bit on a port operating in Beta mode. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameter is communicated via this service: —
data. This parameter contains the data bit to be transmitted.
16.2.5.5 PMD DS port receive signal request (PMD_DSPORT_SIGNAL.request) and confirmation (PMD_DSPORT_SIGNAL.confirmation) The PHY uses the PMD DS port receive signal request and confirmation service pair to request the current signal being received from a PMD layer operating in DS mode. The PMD layer shall service the request immediately upon receipt and respond with a confirmation. NOTE—The C code uses a unified PMD_DSPORT_SIGNAL_request, which combines the functions of this request and the corresponding confirmation.
Copyright © 2008 IEEE. All rights reserved.
411
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The following parameters are communicated by the PMD confirmation: —
RX_arb. This parameter takes one of the values RX_IDLE, RX_PARENT_NOTIFY, RX_REQUEST_CANCEL, RX_IDENT_DONE, RX_SELF_ID_GRANT, RX_REQUEST, RX_ROOT_CONTENTION, RX_GRANT, RX_SUSPEND, RX_PARENT_HANDSHAKE, RX_ DATA_END, RX_CHILD_HANDSHAKE, RX_DISABLE_ NOTIFY, RX_DATA_PREFIX, or RX_BUS_RESET.
—
data. This parameter provides the values of TPA and TPB as interpreted by the data comparators.
16.2.5.6 PMD DS port receive speed request (PMD_DSPORT_RXSPEED.request) and confirmation (PMD_DSPORT_RXSPEED.confirmation) The PHY uses the PMD DS port receive speed request and confirmation service pair to request the current speed signal being received from a PMD layer operating in DS mode. The PMD layer shall service the request immediately upon receipt and respond with a confirmation. NOTE—The C code uses a unified PMD_DSPORT_RXSPEED_request, which combines the functions of this request and the corresponding confirmation.
The following parameters are communicated by the PMD confirmation: —
RX_S200. The PMD has detected a DS mode S200 speed signal.
—
RX_S400. The PMD has detected a DS mode S400 speed signal.
The value returned by this service shall be the minimum of the received speed signal and the speed capability of the port. Thus, if the local port is only S200 capable, but the peer port is sending a S400 speed signal, this service will report S200.
16.2.5.7 PMD DS port transmit data request (PMD_DSPORT_DATA.request) The PHY uses the PMD DS port transmit data request service to transmit a data bit on a port operating in DS mode. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameter is communicated via this service: —
pd. The port data to be transmitted are encoded as the values for TPA and TPB.
16.2.5.8 PMD DS port transmit arbitration state request (PMD_DSPORT_ARB.request) The PHY uses the PMD DS port transmit arbitration state request service to transmit an arbitration line state on a port operating in DS mode. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameter is communicated via this service: —
arb. This parameter takes one of the values TX_IDLE, TX_REQUEST, TX_GRANT, TX_DISABLE_NOTIFY, TX_PARENT_NOTIFY, TX_SUSPEND, TX_DATA_PREFIX, TX_CHILD_NOTIFY, TX_IDENT_DONE TX_DATA_END, or TX_BUS_RESET.
16.2.5.9 PMD DS port transmit speed request (PMD_DSPORT_TXSPEED.request) The PHY uses the PMD DS port transmit speed request service to transmit speed signal on a port operating in DS mode. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request.
412
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The following parameter is communicated via this service: —
speed. This parameter shall contain the speed code to be transmitted. The values defined for this parameter are S100, S200, and S400 (shown in Table 16-2).
16.2.5.10 PMD DS port TpBias request (PMD_DSPORT_TPBIAS.request) The PHY uses the PMD DS port TpBias request service to control TpBias on a port operating in DS mode. The PMD layer shall service the request immediately upon receipt. No confirmation is sent for this request. The following parameter is communicated via this service: —
sig. This parameter takes one of the following values: — — —
GND, which instructs the PMD to drive the common-mode voltage on TPA to VG. Bias_On, which instructs the PMD to generate the TpBias voltage on TPA. Z.Z, which instructs the PMD to cease generating TpBias and set TPA to high impedance.
16.2.5.11 PMD cable power status request (PMD_PS.request) and confirmation (PMD_PS.confirmation) The PHY uses the PMD cable power status request and confirmation service pair to obtain the node’s cable power status. The confirmation returns true if cable power is active on any of the PMD layers; otherwise, it returns false. NOTE—The C code uses a unified PMD_PS_request, which combines the functions of this request and the corresponding confirmation.
16.2.5.12 PMD cable speed request (PMD_CABLE_SPEED.request) and confirmation (PMD_CABLE_SPEED.confirmation) The PHY uses the PMD cable speed request and confirmation service pair to obtain the speed capability of the cable currently attached to the port. The confirmation returns true if cable power is active on any of the PMD layers; otherwise, it returns false. The following parameter is communicated via the confirmation service: —
speed. This parameter indicates the maximum data rate supported by the cable currently attached to the port. The speed code shall be one of the speed codes listed in Table 16-2.
NOTE—The C code uses a unified PMD_CABLE_SPEED_request, which combines the functions of this request and the corresponding confirmation.
16.3 PHY facilities PHY packet transmission rules are given in 16.3.1. The formats to be used for packets transmitted between ports are defined in 16.3.2 for ports operating in Alpha mode and in 16.3.3 for ports operating in Beta mode.
16.3.1 PHY packet overview 16.3.1.1 PHY packet transmission and reception PHY packets shall be transmitted according to the following rules: a)
All PHY packets shall be sent at S100.
b)
The PHY shall use Alpha format for all PHY packets issued during the self-identify process (because the existence of a Beta bus cannot be determined until the end of self-identification).
c)
The PHY may send a restore packet in either Alpha or Beta format.
Copyright © 2008 IEEE. All rights reserved.
413
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
d)
The link shall initiate PHY packets at S100. If the link does not know if the bus is a Beta bus, it shall not mark the packet as a Beta packet. (The PHY will upgrade if it can, i.e., if the bus is a Beta bus.)
e)
In a Beta bus, the PHY shall upgrade all link requests to Beta format, regardless of speed.
f)
In a hybrid bus, the PHY shall upgrade the format of any packet issued by the link if and only if the packet speed exceeds Max_legacy_path_speed.
The PHY shall be able to receive PHY packets in either Alpha or Beta format.
16.3.1.2 PHY packet identifier bits The first two bits in a PHY packet are the packet identifier bits, which are encoded as indicated in Table 16-3.
Table 16-3—PHY packet identifier bits Identifier bits
PHY packet type
00
PHY configuration packet
01
Link-on packet
10
Self-ID packet
11
Reserved for VersaPHY packets
16.3.2 Alpha packet formats Alpha nodes send and receive a small number of short packets, which are used for bus management. These PHY packets all consist of 64 bits, with the second 32 bits being the logical inverse of the first 32 bits; they are all sent at the S100 speed. If the first 32 bits of a received PHY packet do not match the complement of the second 32 bits, the PHY packet shall be ignored. All received PHY packets are transferred to the link; all transmitted PHY packets, except those originated by the link, are also transferred to the link. The cable PHY packet types are a)
The self-ID packet
b)
The link-on packet
c)
The PHY configuration packet
d)
The extended PHY packets
NOTE—The PHY packets can be distinguished from an isochronous packet with no data payload (the only primary packet with exactly two quadlets) since the latter uses a 32-bit CRC as the second quadlet, while the PHY packets use the bit inverse of the first quadlet as the second.
PHY packets originated by the link shall be transmitted only when the bus has been granted as the result of either fair or priority arbitration. Self-ID packets autonomously generated by the PHY shall also be transferred to the attached link. PHY packets originated by the attached link shall be processed by the PHY as if they were received from a serial bus.
414
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
16.3.2.1 Alpha self-ID packets The Alpha cable PHY sends one to three self-ID packets at the base rate during the self-identify phase of arbitration or in response to a “ping” packet. The number of self-ID packets sent depends on the maximum number of ports implemented. The cable PHY self-ID packets have the format shown in Figure 16-2. transmitted first 10 phy_ID
0 L
gap_cnt
sp
brdg c
pwr
p0
p1
p2
i m
logical inverse of first quadlet transmitted last
self-ID packet #0 transmitted first 10 phy_ID
1
n (0)
rsv
p3
p4
p5
p6
p7
p8
p9
p10
r m
logical inverse of first quadlet transmitted last
self-ID packet #1 transmitted first 10 phy_ID
1
n (1)
rsv p11 p12 p13 p14 p15
reserved
logical inverse of first quadlet transmitted last
self-ID packet #2 Figure 16-2—Alpha self-ID packet formats
Self-ID packets with sequence numbers, n, between 2 and 7, inclusive, are reserved for future standardization. The fields of the Alpha self-ID packet are defined in Table 16-4.
Table 16-4—Alpha self-ID packet fields Field
Derived from
Comment
phy_ID
physical_ID
Physical node identifier of the sender of this packet.
L
LPS LCtrl
If set, this node has active link and transaction layers. In discrete PHY implementations, this shall be the logical AND of LCtrl and LPS active.
gap_cnt
gap_count
Current value for this node’s PHY_CONFIGURATION.gap_count field.
sp
PHY_SPEED
Speed capabilities: 002 S100 012 S100 and S200 102 S100, S200, and S400 112 Reserved for future standardization See 4.2.3.1 for exact definitions in Mbit/s.
brdg
bridge
These bits are the bridge-capability field as specified in IEEE Std 1394.1
c
CONTENDER
If set and the L bit is set, this node is a contender for the bus or IRM as described in 8.4.2.
Copyright © 2008 IEEE. All rights reserved.
415
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-4—Alpha self-ID packet fields (continued) Field
Derived from
Comment
pwr
POWER_CLASS
Power consumption and source characteristics: 0002 Node does not need power and does not repeat power. 0012 Node is self-powered and provides a minimum of 15 W to the bus. Node is self-powered and provides a minimum of 30 W to the 0102 bus. 0112 Node is self-powered and provides a minimum of 45 W to the bus. 1002 Node may be powered from the bus and is using up to 3 W. No additional power is needed to enable the link.a 1012 Reserved for future standardization. 1102 Node is powered from the bus and is using up to 3 W. An additional 3 W is needed to enable the link.a 1112 Node is powered from the bus and is using up to 3 W. An additional 7 W is needed to enable the link.a
p0 … p15
NPORT, child[n], active[n]
Port connection status: 002 Not present on this PHY. 012 Not active (may be disabled, disconnected or suspended). 102 Active and connected to parent node. 112 Active and connected to child node.
i
initiated_reset
If set, this node initiated the current bus reset (i.e., it started sending a BUS_RESET signal before it received one).b Once set, it remains one through the bus reset and clears to zero upon a subsequent bus reset only if the node is not an initiator of that bus reset.
m
more_packets
If set, another self-ID packet for this node immediately follows (i.e., if this bit is set and the next self-ID packet received has a different phy_ID, then a self-ID packet was lost).
n
—
Extended self-ID packet sequence number.
—
Reserved for future standardization; set to zeros.
rsv aThe
link is enabled by the Alpha link-on packet described in 16.3.2.2; this packet may also enable application layers. bThere is no guarantee that exactly one node has this bit set. More than one node may request a bus reset at the same time.
Some of the information in the self-ID packets changes in accordance with the node’s operating mode. For example, a node that is initially a power consumer but subsequently supplies power would report a different value for the pwr field. Whenever any part of the node’s configuration described by the self-ID packets changes and there is no expectation that interested parties would otherwise discover the change(s), the node should initiate a bus reset in order to transmit updated self-ID packets.
416
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
16.3.2.2 Alpha Link-on packet The Alpha Link-on packet is defined in Figure 16-3 and Table 16-5. Reception of this packet shall cause a PH_EVENT.indication of LINK_ON if the phy_ID field matches the PHY’s physical_ID (See Clause 8 for more information). transmitted first 01 phy_ID
0000
0000
0000
0000
0000
0000
logical inverse of first quadlet transmitted last
Figure 16-3—Alpha Link-on packet format Table 16-5—Alpha Link-on packet fields Field
phy_ID
Derived from
Comment Physical node identifier of the destination of this packet.
physical_ID
NOTE—A link-on packet is advisory. A PHY that receives a link-on packet shall provide a PH_EVENT.indication of LINK_ON to its associated link but the link is not required to take any action. If a link does become functional in response to a link-on packet, there is no maximum time requirement.
16.3.2.3 Alpha PHY configuration packet It is possible to configure serial bus performance in the following ways: a)
Optimize the gap_count used by all nodes to a smaller value (appropriate to the actual worst-case round-trip delay between any two nodes), and
b)
Force a particular node to be the root after the next bus initialization (e.g., to insure that the root is cycle master capable).
Both of these actions shall be effected for all nodes (including the originator) by means of the PHY configuration packet shown in Figure 16-4 and Table 16-6. The PH_CONTROL.request service affects only the local node and is not recommended for changes to either gap_count or force_root. The procedures for using this PHY packet are described in Clause 8. transmitted first 00 root_ID
R T
gap_cnt
0000
0000
0000
0000
logical inverse of first quadlet transmitted last
Figure 16-4—Alpha PHY configuration packet format It is not valid to transmit a PHY configuration packet with both R and T bits set to zero. This would cause the packet to be interpreted as an extended PHY packet.
Copyright © 2008 IEEE. All rights reserved.
417
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-6—Alpha PHY configuration packet fields Field
Affects
Comment
root_ID
Physical_ID of node to have its force_root bit set (only meaningful if R bit set)
R
force_root
If one, then the node with its physical_ID equal to this packet’s root_ID shall have its force_root bit set, all other nodes shall clear their force_root bit. If cleared, the root_ID field shall be ignored.
T
gap_count_reset_ disable
If one, all nodes shall set their gap_count variable to the value in this packet’s gap_cnt field and set the gap_count_reset_disable variable to TRUE.
gap_cnt
gap_count
New value for all nodes’ gap_count variables. This value goes into effect immediately on receipt and remains valid through the next bus reset. A second bus reset without an intervening PHY configuration packet resets gap_count to 3F16, as described in reset_start_actions() in 16.4.5)
16.3.2.4 Alpha extended PHY packets A PHY configuration packet with R = 0 and T = 0 is utilized to define extended PHY packets according to the value in the gap_cnt field (this is renamed the type field in Figure 16-5 through Figure 16-10.) The extended PHY packets have no effect upon either the force_root or gap_count variables of any node.
16.3.2.4.1 Alpha ping packet The reception of the cable PHY packet shown in Figure 16-5 shall cause the node identified by phy_ID to transmit self-ID packet(s) that reflect the current configuration and status of the PHY. Because of other actions, such as the receipt of a PHY configuration packet, the self-ID packet(s) transmitted may differ from those of the most recent self-identify process. transmitted first phy_ID 00
00
type (0)
00
0000
0000
0000
0000
logical inverse of first quadlet transmitted last
Figure 16-5—Alpha ping packet format The fields of the Alpha ping packet are defined in Table 16-7. A PHY shall transmit a self-ID packet within RESPONSE_TIME after the receipt of a ping packet.
Table 16-7—Alpha ping packet fields Field
418
Comment
phy_ID
Physical node identifier of the destination of this packet.
type
Extended PHY packet type (zero indicates ping packet).
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
16.3.2.4.2 Alpha remote access packet The reception of the cable PHY packet shown in Figure 16-6 shall cause the node identified by phy_ID to read the selected PHY register and subsequently return a remote reply packet that contains the current value of the PHY register (see 16.3.2.4.3). transmitted first phy_ID 00
00
type
page
port
reg
reserved
logical inverse of first quadlet transmitted last
Figure 16-6—Alpha remote access packet format The fields of the Alpha remote access packet are defined in Table 16-8.
Table 16-8—Alpha remote access packet fields Field
Comment
phy_ID
Physical node identifier of the destination of this packet.
type
Extended PHY packet type: 1 Register read (base registers) 5 Register read (paged registers)
page
This field corresponds to the Page_select field in the PHY registers. The register read behaves as if Page_select was set to this value.
port
This field corresponds to the Port_select field in the PHY registers. The register read behaves as if Port_select was set to this value.
reg
This field, in combination with page and port, specifies the PHY register. If type indicates a read of the base PHY registers reg directly addresses one of the first eight PHY registers. Otherwise the PHY register address is 10002 + reg.
16.3.2.4.3 Alpha remote reply packet Subsequent to the reception of a remote access packet, the PHY shall transmit the Alpha remote reply packet, as shown in Figure 16-7. transmitted first phy_ID 00
00
type
page
port
reg
data
logical inverse of first quadlet transmitted last
Figure 16-7—Alpha remote reply packet format The fields of this packet are defined in Table 16-9. A PHY shall transmit a remote reply packet within RESPONSE_TIME after the receipt of a remote access packet.
Copyright © 2008 IEEE. All rights reserved.
419
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-9—Alpha remote reply packet fields Field
Comment
phy_ID
Physical node identifier of the source of this packet.
type
Extended PHY packet type: 3 Register contents (base registers) 7 Register contents (paged registers)
page
This field corresponds to the Page_select field in the PHY registers; in conjunction with port and reg, it identifies the register whose contents are returned in data.
port
This field corresponds to the Port_select field in the PHY registers; in conjunction with page and reg, it identifies the register whose contents are returned in data.
reg
This field, in combination with page and port, identifies the register whose contents are returned in data. If type indicates a base PHY register, reg directly addresses one of the first eight PHY registers. Otherwise the PHY register address is 10002 + reg.
data
The current value of the PHY register addressed by the immediately preceding remote access packet. If the register is reserved or unimplemented, data shall be zero.
16.3.2.4.4 Alpha remote command packet The reception of the cable PHY packet shown in Figure 16-8 shall request the node identified by phy_ID to perform the operation specified and subsequently return a remote confirmation packet (see 16.3.3.3). transmitted first phy_ID 00
00
type (8)
port
000
0000
0000
cmnd
logical inverse of first quadlet transmitted last
Figure 16-8—Alpha remote command packet format The fields of this packet are defined in Table 16-10.
Table 16-10—Alpha remote command packet fields Field
420
Comment
phy_ID
Physical node identifier of the destination of this packet.
type
Extended PHY packet type (8 indicates command packet).
port
This field selects one of the PHY’s ports.
cmnd
Command: 0 NOP 1 Transmit TX_DISABLE_NOTIFY then disable port 2 Initiate suspend (i.e., become a suspend initiator) 4 Clear the port’s Fault bit to zero 5 Enable port 6 Resume port
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Because a remote command packet may alter the power state of the addressed PHY, such a packet shall not be transmitted to any device unless the device has indicated, by means beyond the scope of this standard, that its power state may be managed by others. The absence of any such indication shall be interpreted as a refusal to grant power management privileges to others. NOTE—Although this standard does not define any method for a device to advertise whether or not it participates in power management protocols, configuration ROM may provide the necessary information. If that is the case, simple devices without link and transaction layers (such as power bricks) would be exempt from power management.
16.3.2.4.5 Alpha remote confirmation packet Subsequent to the reception of a remote command packet, the PHY shall transmit the packet shown in Figure 16-9; it reports current status for the port and confirms whether or not the PHY initiated the requested action. transmitted first phy_ID 00
00
type (A16)
000
port
000
f c b d ok cmnd
logical inverse of first quadlet transmitted last
Figure 16-9—Alpha remote confirmation packet format The fields of the Alpha remote confirmation packet are defined in Table 16-11.
Table 16-11—Alpha remote confirmation packet fields Field
Comment
phy_ID
Physical node identifier of the source of this packet.
type
Extended PHY packet type (A16 indicates remote confirmation packet).
port
This field shall specify the PHY port to which this packet pertains.
fault
Abbreviated as f in Figure 16-9, this bit is the current value of the Fault bit from PHY register 10012 for the addressed port.
connected
Abbreviated as c in Figure 16-9, this bit is the current value of the Connected bit from PHY register 10002 for the addressed port.
bias
Abbreviated as b in Figure 16-9, this bit is the current value of the Bias bit from PHY register 10002 for the addressed port.
disabled
Abbreviated as d in Figure 16-9, this bit is the current value of the Disabled bit from PHY register 10002 for the addressed port.
ok
One if the command was accepted by the PHY and zero otherwise.
cmnd
The cmnd value (from the preceding remote command packet) with which this confirmation packet is associated.
A PHY shall transmit a remote confirmation packet within RESPONSE_TIME after the receipt of a remote command packet. If the port is not implemented, the fault, connected, bias, disabled, and ok bits shall be zero.
Copyright © 2008 IEEE. All rights reserved.
421
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.3.2.4.6 Alpha resume packet The reception of the cable PHY packet shown in Figure 16-10 shall cause any node to commence resume operations for all PHY ports that are both connected and suspended. This is equivalent to setting the resume variable to TRUE for each of these ports. The resume packet is broadcast; there is no reply. transmitted first phy_ID 00
00
type (F16)
00
0000
0000
0000
0000
logical inverse of first quadlet transmitted last
Figure 16-10—Alpha resume packet format The fields of the Alpha resume packet are defined in Table 16-12.
Table 16-12—Alpha resume packet fields Field
Comment
phy_ID
Physical node identifier of the source of this packet.
type
Extended PHY packet type (F16 indicates resume packet).
16.3.3 Beta PHY packet formats 16.3.3.1 Beta self-ID packets The BetaPHY sends one to three self-ID packets at the base rate during the self-identify phase of arbitration or in response to a ping packet. The number of self-ID packets sent depends on the maximum number of ports implemented. The BetaPHY self-ID packets have the format shown in Figure 16-11. transmitted first 10 phy_ID
0 L
gap_cnt
sp
pwr
brdg c
p0
p1
p2
i m
logical inverse of first quadlet transmitted last
self-ID packet #0 transmitted first 10 phy_ID
1
n (0)
rsv
p3
p4
p5
p6
p7
p8
p9
p10
r m
logical inverse of first quadlet transmitted last
self-ID packet #1 transmitted first 10 phy_ID
1
n (1)
rsv p11 p12 p13 p14 p15
reserved
logical inverse of first quadlet transmitted last
self-ID packet #2 Figure 16-11—Beta self-ID packet formats
Self-ID packets with sequence numbers n between 2 and 7 inclusive are reserved for future standardization.
422
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
NOTE—Although this standard currently defines only three self-ID packets, link designers should accommodate the reception of up to 252 self-ID packets during the self-identify process. Such a link design permits future revisions of the serial bus standard to define an additional self-ID packets without adverse impact on contemporary links.
The fields in Figure 16-11 are defined in Table 16-13.
Table 16-13—Beta self-ID packet fields Field
Derived from
Comment
phy_ID
physical_ID
Physical node identifier of the sender of this packet.
L
LPS Link_active
If set, this node has active link and transaction layers. In discrete PHY implementations, this field is the logical AND of Link_active and active LPS.
gap_cnt
gap_count
Current value for this node’s PHY_CONFIGURATION.gap_count field.
sp
PHY_SPEED
Speed capabilities: 002 98.304 Mbit/s 012 98.304 Mbit/s and 196.608 Mbit/s 102 98.304 Mbit/s, 196.608 Mbit/s, and 393.216 Mbit/s 112 Speed capabilities reported in PHY port registers A Beta mode PHY shall always use value 112; however, the values 002, 012, and 102 may be received from Alpha nodes.
brdg c pwr
bridge
These bits are the bridge-capability field as specified in IEEE Std 1394.1
CONTENDER
If set and the link_active flag is set, this node is a contender for the bus or IRM as described in Clause 8.4.2.
POWER_CLASS
Power consumption and source characteristics: 0002 Node does not need power and does not repeat power. 0012 Node is self-powered and provides a minimum of 15 W to the bus. Node is self-powered and provides a minimum of 30 W to 0102 the bus. Node is self-powered and provides a minimum of 45 W to 0112 the bus. 1002 Node may be powered from the bus and is using up to 3 W. 1012 1102
No additional power is needed to enable the link.a Reserved for future standardization. Node is powered from the bus and is using up to 3 W. An
1112
additional 3 W is needed to enable the link.a Node is powered from the bus and is using up to 3 W. An additional 7 W is needed to enable the link.a
p0 … p15
i
NPORT, child[n], connected[n]
Port connection status: 112 Active or in standby and connected to child node. 102 Active or in standby and connected to parent node. 012 Not active (may be disabled, loop-disabled, disconnected, or suspended). Not present on this PHY. 002
initiated_reset
If set, this node initiated the current bus reset (i.e., it started sending a BUS_RESET signal before it received one)b (Optional. If not implemented, this bit shall be zero.)
Copyright © 2008 IEEE. All rights reserved.
423
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-13—Beta self-ID packet fields (continued) Field
Derived from
m
Comment If set, another self-ID packet for this node will immediately follow (i.e., if this bit is set and the next self-ID packet received has a different phy_ID, then a self-ID packet was lost).
more_packets
n
Extended self-ID packet sequence number.
r, rsv, reserved
Reserved for future standardization. Set to zeros.
a The b
link is enabled by the link-on packet described in 16.3.2.2; this packet may also enable application layers. No guarantee exists that exactly one node will have this bit set. More than one node may request a bus reset at the same time.
Some of the information in the self-ID packets changes in accordance with the node’s operating mode. For example, a node that is initially a power consumer, but subsequently supplies power, would report a different value for the pwr field. When any part of the node’s configuration described by the self-ID packets changes and interested parties would not be expected to otherwise discover the change(s), the node should initiate a bus reset to transmit updated self-ID packets.
16.3.3.2 Beta Remote command packet The reception of the Beta PHY packet shown in Figure 16-12 requests the node identified by the phy_ID field to perform the operation specified and subsequently return a remote confirmation packet (see 16.3.3.3). transmitted first phy_ID 00
00
type (8)
e_cmnd
port
0000
0000
cmnd
logical inverse of first quadlet transmitted last
Figure 16-12—Beta Remote command packet format The fields in Figure 16-12 are defined in Table 16-14.
Table 16-14—Beta Remote command packet fields Field
424
Comment
phy_ID
Physical node identifier of the destination of this packet.
type
Extended PHY packet type. (Type 8 indicates command packet.)
port
The selected PHY port (not used in the standby command).
cmnd
Command: 0: 1: 2: 4: 5: 6: 7:
NOP Transmit TX_DISABLE_NOTIFY; then disable port Initiate suspend (i.e., become a suspend initiator) Clear port’s Fault and Standby_fault bits to 0 Enable port Resume port Extended command (see e_cmnd)
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 16-14—Beta Remote command packet fields (continued) Field e_cmnd
Comment Extended command (cmnd = 7): 0: NOP 1: Initiate standby with connected peer port 2: Restore from standby with connected peer port 3–7: Reserved
Because a remote command packet may alter the power state of the addressed PHY, such a packet shall not be transmitted to any device unless the device has indicated, by means beyond the scope this standard, that its power state may be managed by others. The absence of any such indication shall be interpreted as a refusal to grant power management privileges to others. Although IEEE Std 1394 does not define any method for a device to advertise whether it participates in power management protocols, configuration ROM may provide the necessary information. In such cases, simple devices without link and transaction layers (e.g., power bricks) would be exempt from power management.
16.3.3.3 Beta Remote confirmation packet Subsequent to the reception of a remote command packet, the PHY transmits the packet shown in Figure 16-13. It reports current status for the port and confirms whether the PHY initiated the requested action. transmitted first phy_ID 00
00
type (A16)
e_cmnd
port
00
s f c b d ok
cmnd
logical inverse of first quadlet transmitted last
Figure 16-13—Beta Remote confirmation packet format The fields in Figure 16-13 are defined in Table 16-15.
Table 16-15—Beta Remote confirmation packet fields Field
Comment
phy_ID
Physical node identifier of the source of this packet.
type
Extended PHY packet type. (Type A16 indicates remote confirmation packet.)
port
The specified PHY port to which this packet pertains.
standby_fault (s in Figure 16-13)
The current value of the standby_fault bit from PHY register 10012 for the addressed port.
fault (f in Figure 16-13)
The current value of the fault bit from PHY register 10012 for the addressed port.
connected (c in Figure 16-13)
The current value of the connected bit from PHY register 10002 for the addressed port.
Copyright © 2008 IEEE. All rights reserved.
425
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-15—Beta Remote confirmation packet fields (continued) Field
Comment
bias (b in Figure 16-13)
The current value of the Receive_OK bit from PHY register 10002 for the addressed port.
disabled (d in Figure 16-13)
The current value of the disabled bit from PHY register 10002 for the addressed port.
ok
One if the command was accepted by the PHY; otherwise, zero.
cmnd
The cmnd value (from the preceding remote command packet) with which this confirmation packet is associated.
e_cmnd
The e_cmnd value (from the preceding remote command packet) with which this confirmation packet is associated.
A PHY shall transmit a remote confirmation packet within RESPONSE_TIME after the receipt of a remote command packet. If the port is not implemented, the standby_fault, fault, connected, bias, disabled, and ok bits shall be zero.
16.3.3.4 Beta PHY configuration packet The Beta PHY configuration packet is extended for use when restoring a connection. The format for a Beta PHY configuration packet is shown in Figure 16-14. transmitted first 00 root_ID
R T
gap_cnt
0000
0000
MLP L B Q P A N
logical inverse of first quadlet transmitted last
Figure 16-14—Beta PHY configuration packet format The fields in Figure 16-14 are defined in Table 16-16.
Table 16-16—Beta PHY configuration packet fields Field
Affects
root_ID
426
Comment Physical_ID of node to have its force_root bit set (meaningful only if R bit set). When restoring a connection, this field contains the physical_ID of the node being restored.
R
force_root
If one and not restoring a connection, then the node with its physical_ID equal to this packet’s root ID shall have its force_root bit set. All other nodes shall clear their force_root bit. If cleared, the root_ID field shall be ignored. This field is always one, but otherwise ignored, when restoring a connection.
T
gap_count_reset_ disable
If one, all nodes shall set their gap_count variable to the value in this packet’s gap_cnt field and set the gap_count_reset_disable variable to TRUE. When restoring a connection, this bit is a copy of the gap_count_reset_disable variable of the transmitting PHY.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 16-16—Beta PHY configuration packet fields (continued) Field gap_cnt
Affects
Comment
gap_count
New value for all nodes’ gap_count variable. This value goes into effect immediately on receipt and remains valid through the next bus reset. A second bus reset without an intervening PHY configuration packet resets gap_count to 3F16, as described in resetStartActions() in Table 19-21).
Max_legacy_path_speed
Zero unless restoring a connection. When restoring a connection, this field indicates the maximum speed on an Alpha connection detected during the most recent self-identification sequence: 002 98.304 Mbit/s 012 196.608 Mbit/s 102 393.216 Mbit/s
L
B_node_root
Zero unless restoring a connection. When restoring a connection, a value of one indicates that the root is in the local Beta cloud.
B
B_bus
Zero unless restoring a connection. When restoring a connection, a value of one indicates that no Alpha nodes exist (including Alpha links) on the bus.
MLP
Q
Zero unless restoring a connection. When restoring a connection, this bit is a copy of the R bit in PHY register 0 of the transmitting PHY.
P
Zero unless restoring a connection. When restoring a connection, this bit is a copy of the PS bit in PHY register 0 of the transmitting PHY.
A
Zero unless restoring a connection. When restoring a connection, a value of one indicates that the current asynchronous phase is odd.
odd_async_phase
N
Zero unless restoring a connection. When restoring a connection, a value of one indicates that a bus reset has occurred since the connection was placed in standby.
Transmitting a PHY configuration packet with both R and T bits set to 0 is not valid, as this would cause the packet to be interpreted as an extended PHY packet.
16.3.3.5 Loop test packet (LTP) A node with a connection in the P11: Untested state transmits an LTP, with the format shown in Figure 16-15. transmitted first 3F16 00
00
type (E16)
00
0000
0000
m G
test_value
logical inverse of first quadlet transmitted last
Figure 16-15—LTP format The fields shown in Figure 16-15 are defined in Table 16-17.
Copyright © 2008 IEEE. All rights reserved.
427
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-17—LTP fields Field
Comment
type
Extended PHY packet type. (Type E16 indicates LTP.)
mode (m in Figure 16-15)
LTP mode: 0: Test 1: Attach in progress
G
Generation number. Alternating value. When a new test_value number is chosen, the G value of the LTP sent on the bus is the inverse of the G value that was previously in the test_value HR.
test_value
LTP comparison value.
16.3.4 Data packet formats The formats to be used for data packets transmitted between ports are defined in 16.3.4.1 through 16.3.4.8.
16.3.4.1 Alpha and Beta packet formats Two formats are used for packets transmitted between ports operating in Beta mode: Alpha packets, which are capable of being repeated to ports operating in DS mode, and Beta packets, which offer overall higher bandwidth, but are not capable of being forwarded to ports operating in DS mode. The Beta format is always used for packet speeds of S800 and above. The maximum payload size for Beta packets is shown in Table 16-18.
Table 16-18—Maximum payload size for Beta data packets Data rate
Maximum asynchronous payload size (bytes)
Maximum isochronous payload (bytes)
S100
512
1024
S200
1024
2048
S400
2048
4096
S800
4096
8192
S1600
4096
16 384
S3200
4096
32 768
16.3.4.2 General packet format In general, an originating Beta mode port shall generate packets with the format shown below: .....<speed code>[DATA_PREFIX symbols]<padded data>[packet end]..... The angle bracket <> delimiters indicate elements of the packet that may be optional at some (or all) combination of operating speed and packet speed, as described below. The bracket [] delimiters indicate mandatory elements of the packet. The nomenclature [symbol]n indicates that the specified symbol is repeated n times. The nomenclature [symbol](m S400) indicates that the specified symbol is repeated for m
428
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
S400 symbol times. If the operating speed of the port is S200 or S100, then quantization may result in the number of actual symbols transmitted to be either of two different numbers: e.g., [DATA_PREFIX](6 s400) would mean that either one or two S100 DATA_PREFIX symbols or exactly three S200 DATA_PREFIX symbols are transmitted. The packet prefix is the speed code (if present) and the DATA_PREFIX symbol(s). The DATA_PREFIX symbol(s) indicate the polarity of the running disparity at the start of the packet data. NOTE—Due to withdrawn requests on the upstream path, multiple speed codes may be received.
The packet end consists of a minimum stream of packet end symbols, which are ARB_CONTEXT, DATA_END, DATA_PREFIX, DATA_NULL, GRANT, GRANT_ISOCH, or LEGACY_PHASE. For an Alpha packet terminating in DATA_END or an Alpha packet terminating in GRANT or GRANT_ISOCH on the senior port, the packet end sequence consists of the DATA_END, GRANT, or GRANT_ISOCH symbols followed by LEGACY_PHASE symbol(s). In all other cases, the packet end sequence consists of a stream of identical symbols. In some cases, the nominal duration during which symbols are repeated is not an integral multiple of the individual symbol time, which can lead to a quantization effect in which the number of symbols actually transmitted can vary by one. Error due to quantization does not accumulate over time. The notation [DATA_PREFIX symbol]e denotes symbols introduced for elasticity to compensate for clock frequency differences between PHYs on a bus. The requirements for elasticity symbols are described in 16.3.4.7.
16.3.4.3 Alpha format with speed code When an Alpha S200 or S400 packet is originated or repeated by the local node, a speed code shall be transmitted during the packet prefix. A speed code shall also be transmitted during the packet prefix of an Alpha S100 packet originating at the local node when the node does not have an Alpha link or when repeating an Alpha packet with speed code. The Alpha format with speed code shall be .....[speed code][DATA_PREFIX symbol]p[DATA_PREFIX symbol]e [padded data][packet end symbol](n s400).... At an originating or repeating node, the value of p shall be such that —
DATA_PREFIX shall be transmitted for one symbol time measured at the packet speed, and
—
The time, before quantization effects are taken into account, for the speed code and subsequent DATA_PREFIX symbols shall be at least MIN_DATA_PREFIX. For improved interoperability with Alpha devices, this time at originating nodes should be 180 ns.
To meet these rules, the value p shall be max(m, 7 * r – m) where r is the ratio of the port operating speed to S400 and m is the ratio of the port operating speed to the packet speed. For improved interoperability with Alpha devices, the value p at originating nodes should be max(m, 9 * r – m). When this timing is used for an S100 packet originated on a S200 port, the value p is 5/2, in which case the effect of quantization is that either two or three DATA_PREFIX symbols are transmitted. Error due to quantization does not accumulate over time. In several circumstances, if the packet is not null (i.e., it contains padded data), then the duration of the packet end symbols shall be increased to allow the generation of the appropriate number of dribble bits, as shown in Table 19-9. The two values for n are shown by the notation a:b. The duration of the packet end symbols shall be determined according to the specific symbol as follows:
Copyright © 2008 IEEE. All rights reserved.
429
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
a)
DATA_PREFIX or DATA_NULL: n = 8:9.
b)
GRANT or GRANT_ISOCH: If the grant is being made to the senior port, then n = 8, followed by LEGACY_PHASE with n = 4:5 (for a total of 12:13 symbols in the packet end sequence). Otherwise, n = 12:13 (with no LEGACY_PHASE following).
c)
DATA_END: n = 8, followed by LEGACY_PHASE with n = 4:5 (for a total of 12:13 symbols in the packet end sequence).
d)
ARB_CONTEXT. n = 2 (packet speed = S400), 4 (packet speed = S200), or 8 (packet speed = S100).
(When speed-filtering non-null packets on a DS port, the port shall extend DATA_PREFIX rather than extend DATA_END by 2/BASE_RATE to duplicate the dribble bit time without violating the maximum value for DATA_END_TIME.) These requirements ensure that, if the packet is subsequently forwarded to a DS port, the DS port will be able to generate a minimum length DATA_PREFIX, dribble bits, and DATA_END without excessive buffering of data. The requirements also ensure that, if the packet is subsequently forwarded to a Beta port operating at a lower speed, the Beta port will be able to maintain the duration of the packet prefix and packet end.
16.3.4.4 Alpha format for S100 packets without speed code An Alpha S100 packet originated by a border node with an Alpha link or repeated by a border node from a DS port onto a Beta port shall not include a speed code. If a node receives an Alpha S100 packet without a speed code, then it shall repeat the packet without a speed code. The packet format for as S100 packet without speed code shall be .....[DATA_PREFIX symbol]p[DATA_PREFIX symbol]e[padded data][packet end symbol](n s400) At an originating node, the value of p shall be such that —
DATA_PREFIX shall be transmitted for two symbol times measured at the packet speed, and
—
The time, before quantization effects are taken into account, for the DATA_PREFIX symbols shall be at least MIN_DATA_PREFIX. For improved interoperability with Alpha devices, this time should be 180 ns.
To meet these rules, the value p shall be max(2 * m, 7 * r) where r is the ratio of the port operating speed to S400 and m is the ratio of the port operating speed to the packet speed. For improved interoperability with Alpha devices, the value p should be max(2 * m, 9 * r). For an S100 packet originated on a S200 port, the value p is 7/2, and the effect of quantization is that either three or four DATA_PREFIX symbols are transmitted. Error due to quantization does not accumulate over time. At a repeating node, the value of p shall be such that the time, before quantization effects are taken into account, for the DATA_PREFIX symbols shall be at least MIN_DATA_PREFIX. To meet this rule, the value p shall be 7 * r where r is the ratio of the port operating speed to S400. For packets repeated on S100 or S200 ports, the value p is nonintegral, and the effect of quantization is that either three or four DATA_PREFIX symbols are transmitted (on S200 ports) or that either one or two DATA_PREFIX symbols are transmitted (on S100 ports). The duration of the packet end symbols shall be as defined in 16.3.4.3.
430
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
These requirements ensure that, if the packet is subsequently forwarded to a DS port, the DS port will be able to generate a minimum length DATA_PREFIX and DATA_END without excessive buffering of data.
16.3.4.5 Beta format for all packet speeds Packets transmitted using the Beta format shall never be forwarded on a DS port. The packet format rules for Beta packets are, therefore, different from the packet format rules for Alpha packets. The Beta packet format shall be .....[speed code][DATA_PREFIX symbol]m[DATA_PREFIX symbol]e [padded data][packet end symbol]n..... where m is equal to the ratio of the port operating speed and the packet speed. If a port on the node is being granted (i.e., transmitting the ending symbol GRANT or GRANT_ISOCH) and the port being granted has an operating speed less than the packet speed, then n is 2 * g, where g is the ratio of the port operating speed to the operating speed of the port being granted (i.e., the grant is stretched to ensure that two symbols are transmitted on the port being granted). Otherwise, n = 2 * m. These requirements ensure that, if the packet is subsequently forwarded to a Beta port operating at a lower speed, then the Beta port is able to transmit a speed code and packet end symbols without buffering data.
16.3.4.6 Minimum packet spacing For all packet formats except Alpha format without speed code, a packet has, at a minimum, two packet end symbols and two packet prefix symbols (before quantization effects); therefore, the minimum spacing between packet data is four symbols at the fastest speed supported by the node. A Alpha packet received on a DS port may be repeated with only one packet prefix symbol, but in this case shall be separated from the previous packet by sufficient ending symbols to also provide a minimum of four symbols of spacing between packet data at the fastest speed supported by the node. PHY packets are always sent at S100. Therefore, the spacing between the data bits of any two PHY packets is always at least 320 ns; in particular, two symbol times at S100 always exist at the end of a PHY packet. This spacing provides time for any extra time required by a link design for PHY packet processing.
16.3.4.7 Deletable symbols An originating node shall introduce deletable symbols, denoted in the descriptions in 16.3.4.3 through 16.3.4.5 as [DATA_PREFIX symbol]e so that —
The duration of the deletable symbols shall be at least MIN_DELETABLE_SYMBOL_TIME, and
—
At least two symbols at the packet speed shall be transmitted.
A repeating node may delete deletable symbols according to the following algorithm, which is described in terms of a FIFO with a watermark. Any equivalent implementation is compliant. —
Each port implements a FIFO for the reception of symbols. A single DATA_PREFIX symbol from the packet prefix is placed in the FIFO regardless of the number of DATA_PREFIX symbols received. Other symbols are placed into the FIFO as they are received on the port and are removed from the FIFO as they are repeated to the link and to the other ports. A count is maintained of the number of symbols in the FIFO at any moment in time.
—
A must_delete watermark is defined, set at a level equivalent to two S400 symbols (i.e., equivalent to MIN_DELETABLE_SYMBOL_TIME) or, for S100 and S200 packet speeds, two symbols at the packet symbol rate.
Copyright © 2008 IEEE. All rights reserved.
431
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
—
IEEE STANDARD FOR A
After the generation of mandatory packet prefix symbols, deletable symbols are generated and data are not repeated until the first of the following events occurs a) b)
The count of symbols in the FIFO reaches the must_delete watermark. Enough time has passed for 1) One packet symbol or one S400 symbol (whichever is greater), and 2) Data to be present in the FIFO for sufficient time to prevent FIFO underflow given possible clock frequency differences between the local receiving node and the adjacent transmitting node (implementation-dependent, but at least 17 ns for ± 100 ppm and the maximum packet size).
Requirement b)2) also takes care of the special case of an acknowledge packet, which contains just 1 data byte.
16.3.4.8 Packet transmission examples The examples of packet formats given 16.3.4.8.1 through 16.3.4.8.5 are for illustration only. The following nomenclature is used: represents the nth data byte of a packet; Bn DP represents a DATA_PREFIX symbol; DE represents a DATA_END symbol; LP represents a LEGACY_PHASE symbol; PE represents a packet end symbol; P represents a padding symbol (SPEEDc); y X indicates a sequence of y consecutive X symbols, e.g., PE{24,28} indicates a sequence of either 24 or 28 packet end symbols.
16.3.4.8.1 Alpha S100 packet originated on S800 port of node with an Alpha link The Alpha format without speed code is used. If the packet ends with DATA_END, then the format is DP16DP16B1 PPPPPPP B2 PPPPPPP B3........Bn PPPPPPP DE16LP10 For interoperability with early Alpha devices, DATA_PREFIX before deletable symbols should be generated for 180 ns. In this case, the format becomes DP18DP16B1 PPPPPPP B2 PPPPPPP B3........Bn PPPPPPP DE16LP10
16.3.4.8.2 Alpha S100 packet originated on S800 port of node with a Beta link The Alpha format with speed code is used. Assuming 180 ns of speed code and DATA_PREFIX before deletable symbols and assuming the packet ends with DATA_END, the format is Sc Sc Sc Sa Sc Sc Sc Sc DP10DP16B1 PPPPPPP B2 PPPPPPP B3........Bn PPPPPPP DE16LP10
16.3.4.8.3 Alpha S200 packet originated on S800 port The Alpha format with speed code is used. Assuming 180 ns of speed code and DATA_PREFIX before deletable symbols and assuming the packet ends with DATA_END, the format is Sc Sc Sa Sc DP14DP16B1 PPP B2 PPP B3.......Bn PPP DE16LP10
432
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
16.3.4.8.4 Beta S800 packet originated on S800 port The Beta format is used. Assuming that the packet ends with DATA_END, the format is Sb DP DP4 B1 B2 B3 B4.....Bn DE2
16.3.4.8.5 Beta S800 packet originated on S1600 port The Beta format is used. Assuming that the packet ends with DATA_END, the format is Sc Sb DP2 DP8 B1 P B2 P B3 P........Bn P DE4
16.3.5 Packet forwarding Packets received on a port are forwarded on all other ports that are capable of transmitting a packet at the necessary speed and are compatible with the packet format. Beta packets are not forwarded on DS ports.
16.3.5.1 Packets at speeds greater than the port operating speed When a packet is received whose speed exceeds the operating speed of a port or where the packet format is Beta, but the port is operating in DS mode, a speed code shall not be transmitted on that port. DATA_NULL symbols (Beta packet on a Beta port) or DATA_PREFIX (Alpha packet on a Beta port or either format on a DS port) shall be transmitted continuously on that port during the packet. By definition, DATA_NULL leaves the 8B/10B context in the arbitration request mode, allowing the DATA_NULL symbols to be deleted. It scales with operating speed as required.
16.3.5.2 Packet forwarding: DS port to Beta port A packet received on a DS port shall be forwarded on Beta ports as an Alpha packet. When a packet is received on a DS port and subsequently retransmitted on a Beta port, it may not be possible to maintain the exact duration of the received packet’s packet prefix, data, and packet end for the retransmitted packet, due to the quantization effect of the 8B/10B coding. For example, a period of DATA_END lasting 260 ns that is received on the DS port may be represented by three characters lasting a total of only 240 ns on the Beta port.
16.3.5.3 Packet forwarding: Beta port to DS port Correctly formatted packets received at a border node Beta port and transmitted on a DS port shall be retimed using the event information conveyed in the packet delimiters received on the Beta port. The border node is not required to reproduce the packet prefix and packet end signals for the same duration as received on the Beta port. Rather, the packet prefix and packet end durations shall be regenerated according to the DS mode requirements of Clause 4. Additionally, the border node should ensure that a period of idle satisfying the MIN_IDLE_TIME requirement of Clause 4 is transmitted between packets on the DS port. When a border node receives a DATA_NULL, it automatically repeats it into any attached Alpha clouds as a DATA_PREFIX. The DATA_PREFIX shall persist until the next Alpha packet is received from the Beta cloud. This is equivalent to operation in which a Beta packet causes a border node to source DATA_PREFIX into an Alpha cloud until a safe point to assert DATA_END was reached (as afforded by repeating an Alpha packet or as forced by the generation of an Alpha null packet by the last BOSS).
Copyright © 2008 IEEE. All rights reserved.
433
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.4 Cable PHY operation The cable PHY is defined in terms of state machines and C code definitions. The detailed operation is specified in terms of state machines given in 16.4.5 through 16.4.8 and a series of data structure definitions, constants, variables, and routines given in 19.
16.4.1 C code functions and variables The C code functions and variables used in the arbitration state machine are described in Table 16-19.
Table 16-19—C code functions and variables Function or variable name
Description
active[port]
Indicates that the port is in the P2: Active state
allChildPortsIdentified
Set if all child ports have been identified
arbOk()
True if OK to request the bus
arbPowerReset()
Power reset initialization routine
arbReset
True to request an arbitration reset token to be sent
arbTimer
Timer for arbitration state machines
betaMode[port]
Set if the port has determined that it is operating in Beta mode; otherwise, unset (i.e., when operating in DS mode or when in P0: Disconnected state). This variable is maintained as a read-only bit in the port register map.
betaPortRequest
True if a request on a port is to be granted
child[port]
True if the port is a child or not active
childHandshakeComplete()
True once all active children are in S0: Self-ID Start state
child_ID_complete[port]
True when self-identification sequence is complete on a specified child port
children
Number of child ports
concatenatedPacket
True if a concatenated packet is being received
contendTime
Amount of time to wait during root contention
convertedRequest
True if a request has been converted from a Beta request into an Alpha request to be forwarded on a DS port
dataComing()
True if DATA_PREFIX, SPEED, DATA_NULL, or CYCLE_START token is detected on a port
dataComingOn(port)
True if DATA_PREFIX, SPEED, DATA_NULL, or CYCLE_START token is detected on the specified port
endOfPacket
Set when reception of packet is complete
flyByOk
True when fly-by concatenation permitted
forceRoot
A value of TRUE modifies the PHY’s tree identify process behavior and increases the likelihood that the node becomes root (see 4.4.2.2). If only one node on a bus has forceRoot set to TRUE, that node is guaranteed to become the root.
434
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 16-19—C code functions and variables (continued) Function or variable name
Description
fromA0
True on entry to A2: Grant state if the previous arbitration state was A0: Idle state.
gapRepeatActions(outOf Packet)
Repeats gap tokens
grantSelf
True if can grant to self
ibr
Set when a long bus reset is needed
idleReceivePort
True if port goes idle after receiving self-ID packets
immediateRequest
True if immediate request from link
initiatedReset
True if this node initiated the bus reset in progress. The variable remains true through and after the bus reset and is cleared to false only by a subsequent bus reset not initiated by this node.
isbrOk
Set when asynchronous or immediate arbitration conditions permit an arbitrated (short) bus reset to be commenced
legacyGrant()
True if a GRANT or GRANT_ISOCH is being received on the senior port
legacyJuniorRequest()
True when a legacy request is on a junior Beta port or a request is on a junior DS port
legacyTime(n)
Returns the duration (in seconds) of n exact S400 byte times (each approximately 20 ns)
loop
True if configuration timeout occurs while in T0: Tree ID Start state. Reported in the PHY register map and cleared by software.
lowestUnidentifiedChild
Lowest numbered active child that has not sent its self-ID packets
maxArbStateTimeout()
True if the PHY stays in any state (except A0: Idle state, T0: Tree ID Start state, or a state that has an explicit timeout) for longer than MAX_ARB_STATE_TIME. This condition is not explicitly represented in the C code.
ownRequest
Latch the value of arbOk() at the time it is evaluated
parentPort
The port number that is connected to the parent node; this variable is meaningless if the node is root.
phyResponse
True to indicate that a PHY response packet is to be transmitted
pingResponse
Set if self-ID packet(s) needed in response to a ping
portSpeed[port]
Maximum speed at which port and its peer can operate
portRArb[port]
Most recently read arbitration state from FIFO for port
portRSpeed[port]
Filtered and latched receive speed for indicated port
portTSpeedRaw(port, speed)
Send speed indication on port (DS ports only)
powerReset
True during power reset; goes false at the end of power reset
proxyRoot
True if the node is proxy_root
receivePort
The port number that is receiving encoded data (determined by the arbitration states)
Copyright © 2008 IEEE. All rights reserved.
435
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-19—C code functions and variables (continued) Function or variable name
Description
requestingPort
Lowest numbered requesting port
resetComplete()
True when all ports are idle or in the tree identify process
resetDetected()
BUS_RESET qualified with port status and/or history
resetDuration
Duration to assert bus reset signal
root
True if the node is the root, as determined by the tree identify process
sendNullPacket
True when BOSS needs to send a null packet to terminate cleanly a DATA_PREFIX that is being sent on DS ports during Beta packet transmissions
seniorPort
Port number of the port pointing towards proxy_root
T0_timeout
True if the tree identify process detects a loop
16.4.2 Arbitration 16.4.2.1 DS-mode arbitration DS-mode arbitration supports the immediate, priority, isochronous, and fair arbitration classes. Immediate arbitration is used to transmit an acknowledge immediately after packet reception; the bus is expected to be available. Priority arbitration is used by the root for cycle start requests or may be used by any node to override fair arbitration. Isochronous arbitration is permitted between the time a cycle start is observed and the subaction gap that concludes an isochronous period; isochronous arbitration commences immediately after packet reception. Fair arbitration is a mechanism whereby a PHY succeeds in winning arbitration only once in the interval between arbitration reset gaps. Ack-accelerated arbitration permits a PHY to arbitrate immediately following an observed acknowledge packet; this enhancement can reduce the arbitration delay by a subaction gap time. Fly-by arbitration permits a transmitted packet to be concatenated to the end of a packet for which no acknowledge is permitted— acknowledge packets themselves or isochronous packets. A PHY shall not use fly-by arbitration to concatenate an S100 packet after any packet of a higher speed. Cable arbitration has two parts—a three-phase initialization process: bus reset (16.4.5); tree identify (16.4.6); and self-identify (16.4.7), followed by a normal operation phase (16.4.8). Each of these four phases is described using a state machine as well as C code in Clause 19.
16.4.2.2 Beta-mode arbitration A Beta node uses two different types of arbitration depending on whether a particular port is connected using Beta or DS mode. DS-mode arbitration is almost identical to Arbitration Compliance Level A, with the primary difference being the support for border functionality. Because border functionality is a superset of Beta-only operation, the detailed operations are described only for border nodes. The Beta-mode arbitration process takes advantage of the full-duplex PHY-to-PHY connections to send requests on the channels where data are not flowing. The request stream sent on each port is a continuously updated request state formed from incoming requests from other ports and from the link. Each request transmitted on any particular port shall be the highest priority request of the requests received on the other ports and the link. (Asynchronous requests and isochronous requests are prioritized independently.) Any
436
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
transmitting PHY receives incoming requests on all of its transmitting ports. After sending the last packet of a subaction, a transmitting PHY acts as BOSS and sends the grant to port where the highest priority request is received. If no requests are present, the grant is passed to the senior until it arrives at the proxy_root, which then remains BOSS until a request is received. The proxy_root becomes the BOSS after resets, timeouts, or periods of inactivity. NOTE—The C code (Clause 19) does not capture internal PHY arbitration timing issues (e.g., ARB_RESPONSE_DELAY, PHY_DELAY, RESPONSE_TIME.) PHY designers (particularly of S1600 and S3200 PHYs) are cautioned to ensure that a new packet transmission does not occur so quickly as to provoke the detection of a collision at proxy_root.
16.4.2.2.1 Beta-mode requests If a BOSS does not receive any requests for the current phase by the time it finishes transmitting data at the end of a subaction (but it has to be receiving requests, rather than other tokens, on all active ports), then it sends an arbitration reset token of the appropriate phase and a grant to its senior. The proxy_root node shall become the default BOSS in an idle bus. Fairness is implemented by using a variable priority/two-phase approach. As long as a node wishes to make requests for the current interval, it shall transmit CURRENT requests; otherwise, it shall transmit a lower priority NEXT_ODD/EVEN request, depending on whether the last arbitration reset token was ASYNC_EVEN/ODD. If it has no requests, it sends a NONE_ODD/EVEN depending on the last arbitration reset token received. If the BOSS last received an ASYNC_EVEN token, it shall issue grants first to NEXT_EVEN requests (left over from the last fairness cycle) and then to CURRENT requests. If it sees only NEXT_ODD or NONE_EVEN requests, it shall transmit an ASYNC_ODD and then a grant to one of the NEXT_ODD requests. The NONE_* of the opposite phase has a higher priority than the NEXT_* of the opposite phase to keep the fairness cycle from advancing until all the nodes have received the current phase arbitration reset. This process repeats for the “even” fairness cycle, with *_ODD and *_EVEN transposed. The priority of the NEXT_* requests with respect to the CURRENT request inverts on each cycle. Isochronous arbitration is similar to fairness. When in the odd isochronous interval, the current BOSS shall respond only to ISOCH_ODD or ISOCH_CURRENT requests. During the odd isochronous phase (which starts with the ASYNCH_START token that concluded the previous even isochronous interval), ISOCH_ODD and ISOCH_CURRENT requests have priority over ISOCH_EVEN requests. Once again, this process repeats for the even isochronous interval and phase, with *_ODD and *_EVEN transposed. Full details of isochronous arbitration are given in 16.4.4. The priority of the various requests are shown in Table 16-20 and Table 16-21.
Table 16-20—Asynchronous requests Request name
Priority level
Comment
BORDER
7 (highest)
CYCLE_START_REQ
6
NEXT_ODD
5 if the last arbitration reset token was ASYNC_ODD; otherwise, 2
This request is queued from the previous fairness cycle.
CURRENT
4
Used for all normal asynchronous requests by nodes that have not used up their fairness budget.
Copyright © 2008 IEEE. All rights reserved.
437
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 16-20—Asynchronous requests (continued) Request name
Priority level
Comment
NONE_EVEN
3 if the last arbitration reset token was ASYNC_ODD; otherwise, 1
Nodes that last saw an ASYNC_EVEN send this request when they have no requests. Having a higher priority than the out-of-phase request keeps the fairness cycle from advancing until all nodes receive the arb_reset of the current phase. This request has two uses: 1) removes the need for programming a specific minimum fairness interval, and 2) allows a border node to synchronize the fairness cycles of the Beta and Alpha domains.
NEXT_EVEN
2 if the last arbitration reset token was ASYNC_ODD; otherwise, 5
For queuing requests across the next fairness cycle.
NONE_ODD
1 (lowest) if the last arbitration reset token was ASYNC_ODD; otherwise, 3
Nodes that last saw an ASYNC_ODD send this request when they have no requests. Having a higher priority than the out-of-phase request keeps the fairness cycle from advancing until all nodes receive the arb_reset of the current phase. This request has two uses: 1) removes the need for programming a specific minimum fairness interval, and 2) allows a border node to synchronize the fairness cycles of the Beta and Alpha domains.
Table 16-21—Isochronous requests Request name
Priority level
Comment
ISOCH_CURRENT
5 (highest)
Used to request to transmit an isochronous packet in the current isochronous interval. When a PHY enters an even interval, it upgrades ISOCH_EVEN requests to ISOCH_CURRENT. When a PHY enters an odd interval, it upgrades ISOCH_ODD requests to ISOCH_CURRENT.
ISOCH_ODD
4 when in the odd isochronous phase; otherwise, 2
Used to request transmission of an isochronous packet in the upcoming odd isochronous interval. See 16.4.2.
ISOCH_EVEN
2 when in the odd isochronous phase; otherwise, 4
Used to request transmission of an isochronous packet in the upcoming even isochronous interval. See 16.4.2.
ISOCH_NONE
1 (lowest)
No isochronous transmission requested.
16.4.2.2.2 Beta-mode grants In Beta-mode operation, two primary types of grant exist: implicit and explicit. For implicit grants, the end of a subaction has not been confirmed (e.g., a nonbroadcast data packet has been sent). Therefore, the BOSS is not granting any node to use the bus. In this case, the BOSS terminates the packet with DATA_END on all ports, implicitly electing its senior node as BOSS. This implicit grant eventually percolates up to the proxy_root. If the receiving node needs to send an ACK, it becomes BOSS; otherwise, the proxy_root becomes BOSS.
438
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Explicit grants are used when the end of a subaction has been reached. Further, two types of explicit grants exist: grant-up and grant-down. In a grant-down, the BOSS is granting itself or a junior port. Ports not being granted see a continuous DATA_NULL indication as a form of DENY, which forces the receiving ports into the Receive state. A junior port (if any) being granted is issued a continuous GRANT indication. The continuous indications cease when the junior port or the local PHY begins packet transmission. This enables Beta-mode operation to achieve fly-by style arbitration to junior and/or children ports as well as senior and/or parent ports. A grant-down cannot be given if it would result in concatenating an Alpha S100 packet onto an Alpha S200 or S400 packet. Similarly, a grant-down cannot be given if a cycle start is expected. In a grant-up, the BOSS is granting the senior port, or the BOSS has no favorite in-phase request to grant and is returning control toward the proxy_root. The senior port issues GRANT tokens for a duration equal to two symbols at the rate of the slower of the port operating speed and the packet speed. Junior ports are issue DATA_END tokens for a duration equal to two symbols at the rate of the slower of the port operating speed and the packet speed. The significance of granting up versus granting down is that on grant-up (toward proxy_root) the end of packet is simply two symbols and then back to idle. On grant-down, it is accompanied by a deny to all other junior ports (i.e., deny is given as DATA_NULL), and the grant persists until a DATA_NULL/start of packet is detected from the granted junior port. Additionally, DATA_NULL is used as a DENY indication without fear of committing to an Alpha packet format. Initially, when a Beta request (received on a junior port) is denied, DATA_NULL is issued. A Betacapable node receiving the DATA_NULL shall repeat it from all ports at the individual port operation speeds. If an Alpha packet is eventually sourced by the winning node, the accompanying DATA_PREFIX alerts all Beta PHYs, which shall begin repeating the DATA_PREFIX indication. If the packet format turns out to be Beta, then it shall be repeated only on ports of capable speeds. All filtered ports see the continued DATA_NULL indication.
16.4.3 Hybrid bus operation Border PHY functionality is required in any PHY that has one or more ports operating in Beta mode (including any attached Beta link) and one or more ports operating in DS mode (including any attached Alpha link). The border PHY serves to synchronize arbitration events and packet transfers across the Beta and Alpha arbitration domains.
16.4.3.1 Hybrid bus initialization A PHY with at least one port operating in Beta mode shall send its self-ID packet at S100, in Alpha format and timing, and with a speed code except that a PHY with an Alpha link shall send out its self-ID packet at S100, in Alpha format and timing, without a speed code, even if the link is inactive and all the ports are operating in Beta mode. A border node repeats self-ID packets received from a DS port without a speed code. Self-ID packets are forwarded with or without speed code as received. A node shall use the receipt of self-ID packets without speed code to determine the maximum speed of Alpha connections (i.e., Max_legacy_path_speed) on the bus and, when originating packets on the bus, shall upgrade packets transmitted at speeds higher than Max_legacy_path_speed to Beta format. If a node has an Alpha link (regardless of whether active), it shall set Max_legacy_path_speed to S400. During the self-identify process, a border node shall assume that it is senior border if it is the last to transmit a self-ID packet without a speed code into the local Beta cloud (i.e., repeated from a DS port or generated because of an Alpha link). A border node will discover if it is not senior border after it has completed transmission of its self-identification sequence and entered the A0: Idle state. A senior border shall
Copyright © 2008 IEEE. All rights reserved.
439
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
determine that it is proxy_root if it is root or if its parent port is operating in Beta mode. This process guarantees that a proxy_root is always a border node if the root is in a Beta cloud. This process is necessary because a hybrid bus has gap timing considerations that are guaranteed only by a border or Alpha PHY.
16.4.3.2 Border node functions A border PHY by design addresses three important differences between Beta and Alpha arbitration: a)
Synchronization of gap events: Alpha arbitration marks the end of the isochronous period and the fairness period with periods of idle time known as subaction gaps and arbitration reset gaps, respectively. Beta-mode arbitration marks the same events with the appropriate usage of the ASYNC_EVEN/ODD tokens. A border node keeps the arbitration domains synchronized by forcing a 1:1 correspondence of elapsed gap times to gap tokens. This synchronization ensures that the programming model (e.g., isochronous batched before asynchronous) is consistent regardless of the bus access methods used on the physical media.
b)
Protection of Alpha quiet windows: Alpha arbitration has two quiet windows during which the bus is required to remain idle for consistent buswide detection of specific gap events. To mark the end of the isochronous interval or to indicate a missing acknowledge, asynchronous arbitration cannot begin sooner than a subaction_gap + arb_delay after the bus last went idle. To mark the end of a fairness interval, asynchronous arbitration is again prohibited until an arb_reset_gap + arb_delay after the bus last went idle. Border nodes act to enforce these quiet windows without requiring Beta-only nodes to implement gap based timers.
c)
Start of isochronous interval: All PHYs within the Beta cloud containing the cycle master can know the isochronous interval has begun when the cycle master transmits a CYCLE_START_ODD/EVEN token. However, in Beta clouds not containing the cycle master, not all PHYs are able to detect the start of the isochronous interval; only PHYs with isochronouscapable Beta links can track the isochronous interval and phase. The mechanism, therefore, has to allow other PHYs to forward requests and route grants correctly in the absence of CYCLE_START_ ODD/EVEN tokens from the cycle master.
16.4.3.2.1 Synchronization of gap events To synchronize Alpha gap indications with Beta token indications, the following rules apply: a)
Alpha clouds are prevented from timing gaps during Beta-only transmissions.
b)
Beta-only nodes are prevented from issuing gap tokens in a hybrid network (because they do not know about Alpha gap timings).
c)
Border PHYs shall guarantee a gap token is generated when a corresponding gap period has expired within the Alpha cloud and, by extension, in all Alpha clouds connected to the bus.
16.2.1.0.0.1 Preventing timing of gaps during packet transmission Particularly during Beta-only traffic, border nodes need to ensure that Alpha devices do not detect any gaps. For example, during isochronous transmission of Beta-only packets, an occurrence of a subaction gap in the Alpha cloud would cause Alpha nodes to fall into the asynchronous period too quickly and perhaps before their own isochronous transmissions occurred. Therefore, the following rules apply: a)
Alpha packets are repeated by a border PHY directly to any DS ports as normal (with DATA_PREFIX replacing the payload if the packet speed is greater than the peer’s capability).
b)
For Beta packets, a border node shall begin generating DATA_PREFIX on its DS ports. Because the border node meets minimum DATA_PREFIX/DATA_END timings and cannot predict when the next Alpha packet will arrive, it cannot safely release DATA_PREFIX until such a packet arrives. The Alpha packet is concatenated onto the DATA_PREFIX and is received normally by Alpha devices.
440
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
c)
IEEE Std 1394-2008
To prevent Alpha nodes from staying in RX: Receive state for longer than their arbitration state timeout, the BOSS in a Beta cloud shall issue an Alpha null packet when the end of a subaction has been reached, no more in-phase requests are pending, and the last packet sent was not an Alpha packet. In addition, the senior border shall issue a BORDER request if the bus has been generating Beta packets for MAX_BETA_TIME and, when granted, issue an Alpha null packet if still required.
16.2.1.0.0.2 Preventing Beta-only PHYs from issuing gap tokens Normally, a Beta-only PHY issues a gap token at the end of a subaction when no eligible in-phase requests remain to be granted. However, a Beta-only PHY shall not issue a gap token in a hybrid network (because Beta-only PHYs do not have gap counts and timers). To implement this, all PHYs detect the presence of a hybrid bus during the self-identify process. If, at the end of a subaction, the BOSS has no more in-phase requests to grant, it passes control toward the proxy_root (after transmitting any necessary null packet to free the border nodes stuck in DATA_PREFIX). No gap token is issued, and the bus will fall idle.
16.2.1.0.0.3 Guaranteeing Alpha gaps are matched with tokens The senior border in each Beta cloud is responsible for ensuring that the Alpha gap timings are observed and is the only PHY within the cloud allowed to issue ASYNC_EVEN/ODD tokens. To synchronize Alpha gap indications with BOSS token indications, the senior border shall issue an ASYNC_EVEN/ODD token of the current phase when it times a subaction idle gap and shall issue an ASYNC_EVEN/ODD token of the new phase when it times an arbitration reset idle gap. The senior border shall continue to issue tokens of the current phase so long as the bus is idle.
16.4.3.2.2 Protection of Alpha quiet windows In a hybrid bus, the subaction indication that follows at the end of an isochronous period or signifies a missing acknowledge is required to be consistently detected buswide. This requires observance of the quiet time in Alpha arbitration leading up to the subaction gap. The quiet period is at risk if acknowledge packets arrive late, if isochronous arbitration is granted late, or primary asynchronous packet arbitration starts too quickly. Similarly, the indication that follows at the end of a fairness interval is required to be consistently detected buswide. This requires observance of the second quiet time in Alpha arbitration, which begins an arb_delay following a subaction gap when arbitration is momentarily allowed and extends until after an arbitration reset gap is detected. This quiet period is at risk if a late arriving asynchronous request is granted or if arbitration for the next fairness interval is granted too soon. All nodes (including Beta-only) are required to meet RESPONSE_TIME and ARB_RESPONSE_DELAY. In other words, data prefix or arbitration is required to be initiated by a responding node and repeated by intermediate nodes within the limits defined by Arbitration Compliance Level A (see 15.1.1). The gap count analysis then applies and guarantees that acknowledge packets and isochronous arbitration will be seen by all nodes before the beginning of the first quiet interval. After transmitting a packet that marks the end of a subaction, the current BOSS shall grant the next PHY immediately. If no requests to grant are valid, control is passed toward the proxy_root. In response to Beta arbitration requests, the senior border shall begin arbitration for the bus in accordance with the Alpha rules for initiating arbitration to ensure consistent buswide detection of gaps. A grant may be issued (if proxy_root) or arbitration on the DS parent port may begin at any of the following times: a)
Up to arb_delay following the issuance of an ASYNC_EVEN/ODD token of the current phase provided the previous packet represented the end of a subaction (ACK-accelerated arbitration),
b)
At arb_delay following the issuance of an ASYNC_EVEN/ODD token of the current phase,
Copyright © 2008 IEEE. All rights reserved.
441
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
c)
Anytime after the arb_delay advance the phase, or
following the issuance of an ASYNC_EVEN/ODD token to
d)
Within ARB_RESPONSE_DELAY ISOCH_CURRENT26 request.
after
receiving
a
LEGACY_REQUEST25
or
In addition, a proxy_root can issue a grant within RESPONSE_TIME of becoming BOSS.
16.4.3.2.3 BOSS PHYs unaware of isochronous interval The BOSS PHY normally uses the current bus phase (asynchronous/isochronous) to determine which arbitration requests it is receiving are in phase and are eligible to be granted. However, in Beta clouds not containing the cycle master, not all PHYs are able to detect the start of the isochronous interval. Only PHYs with isochronous-capable Beta links can track the isochronous interval and phase. The tracking mechanism, therefore, allows other PHYs to forward requests and route grants correctly in the absence of CYCLE_START_ODD/EVEN tokens from the cycle master. To make sure that isochronous requests can be granted properly in the absence any interval information from the cycle master, LEGACY_REQUEST and ISOCH_CURRENT requests are used. The LEGACY_REQUEST and ISOCH_CURRENT requests have priority over other asynchronous or isochronous requests and communicate to the BOSS PHY that the originator of the request has enough information to determine that it would be appropriate and valid to immediately grant the request. To allow a node to route a grant unambiguously in the absence of bus interval information, a GRANT_ISOCH token is used.
16.4.3.3 BORDER request mapping 16.4.3.3.1 Alpha to Beta A RX_REQUEST from Alpha (only heard between active packet transfers) is mapped to a new Beta LEGACY_REQUEST immediately. The border PHY may not know the phase of the bus (i.e., isochronous or asynchronous); therefore, it cannot generally try to map RX_REQUEST to a Beta asynchronous or isochronous request. Unlike other BOSS request types, the LEGACY_REQUEST operates as in Arbitration Compliance Level A (see 15.1.1) and is expected to be withdrawn if denied.
16.4.3.3.2 Beta to Alpha A senior border always respects the Arbitration Compliance Level A quiet times when forwarding eligible Beta requests into the Alpha cloud (see 16.4.3.2.2). All requests are forwarded as TX_REQUESTs.
16.4.3.4 Discussion of root outside the Beta cloud Of special interest is when the root resides behind a border (i.e., the root is either an Alpha node or in a more senior Beta cloud). The senior border arbitrates for the bus on behalf of the Beta cloud. Once arbitration is won, the senior border is BOSS and can introduce a grant into the Beta cloud. After the first packet is sent, the current BOSS can grant the next PHY, grant the senior explicitly (indicating that the end of a subaction 25Border
nodes forward legacy requests as high-priority LEGACY_REQUESTs. Given that all Alpha nodes respect the quiet times when generating a LEGACY_REQUEST and given that Beta nodes repeat legacy requests within ARB_RESPONSE_DELAY, LEGACY_REQUESTs can be present only outside of quiet times. 26 ISOCH_CURRENT requests obey the same timing as IsoReq requests in Arbitration Compliance Level A and, therefore, can be present only outside quiet times.
442
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
was reached), or grant the senior implicitly (indicating that this may not be the end of a subaction). For as long as control can remain in the Beta cloud, the senior border shall drive DATA_PREFIX into the Alpha domain. If the end of a subaction is not reached, control naturally passes back to the senior border and into the Alpha domain. It is necessary to ensure that the Beta cloud concatenations do not risk cycle start starvation. Accordingly, the BOSS shall refrain from passing a grant received from a junior port to either a link or another junior port when all of the following conditions are present: a)
The bus is in asynchronous phase, and
b)
The cycle master is outside the Beta cloud, and
c)
A cycle start is expected. If cycle start indications are not available from the local link, then cycle start is permanently considered to be expected.
If the cycle master is an Alpha link, then on entry to the A0: Idle state, the PHY shall wait for CM_MIN_IDLE_TIME to allow sufficient idle time in case the link needs to request the bus and transmit a cycle start packet.
16.4.4 Isochronous intervals CYCLE_START_ODD/EVEN tokens are launched only once per interval by a Beta cycle master (if any) to confirm the phase (i.e., odd or even) of the upcoming isochronous interval and to help naked PHYs in the senior Beta cloud track pipelined phases. Beta PHYs enter the isochronous interval only when either the attached link (if any) indicates a cycle start packet has been received (e.g., Arbitration Compliance Level A) or a CYCLE_START token is received. Beta links intending to perform isochronous transactions always report cycle start packets to their PHYs as well as their interpreted phase of the interval. The isochronous interval at a given PHY-link pair concludes with receipt/generation of an ASYNC_EVEN/ODD. Isochronous phases (i.e., even and odd) increment with the ASYNC_EVEN/ODD concluding an isochronous interval. In senior Beta clouds (i.e., Beta clouds that contain the proxy_root and cycle master), isochronous phasing (i.e., even and odd) is synchronized between all links and PHYs in the cloud. In junior Beta clouds (i.e., Beta clouds that do not contain the proxy_root and cycle master), the phasing is maintained pairwise between links and PHYs. No attempt is made to keep the entire cloud synchronized to the same phase. ISOCH_ODD/EVEN requests are used between all links and PHYs and additionally on the serial bus in the senior Beta cloud. They are not used on the serial bus in junior Beta clouds. Their primary purpose is to speed up routing of isochronous grants after a cycle start packet has been launched. ISOCH_CURRENT is used in Beta buses as a robust way of recovering from phase synchronization errors. Additionally, ISOCH_CURRENT replaces CYCLE_START tokens in junior Beta clouds as the primary mechanism of forcing naked senior borders to request the bus on behalf of a Beta isochronous talker. GRANT_ISOCH is used to differentiate between grants intended for isochronous transmissions and grants intended for asynchronous transmissions. If GRANT_ISOCH arrives at the senior port of a PHY that cannot use it or forward it on, then a null packet with a quiet grant is generated as a way of releasing the bus. The following rules shall apply to isochronous intervals:
Copyright © 2008 IEEE. All rights reserved.
443
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
a)
A Beta cycle master (i.e., a cycle master with a Beta link and a Beta PHY) shall begin an isochronous interval by launching a CYCLE_START token, then a cycle start packet, and then either a GRANT_ISOCH or a DATA_NULL. An Alpha cycle master, of course, shall start the interval with only a cycle start packet. Only the cycle master can originate the CYCLE_START token and then only at the start of the interval. A second CYCLE_START token shall never be sent within the same interval under any circumstance. CYCLE_START tokens never appear in junior Beta clouds because no Beta cycle master exists in such clouds. The CYCLE_START token is launched for an S100 symbol time to make sure it can be delivered everywhere and safely repeated at the start of a packet.
b)
CYCLE_START tokens are repeated by Beta PHYs while in the RX: Receive state. At this time, they are also copied to a local Beta link, if any. A PHY that receives a CYCLE_START token in the A0: Idle state shall transition to the RX: Receive state (just as when receiving SPEED, DATA_PREFIX, or DATA_NULL).
c)
When a cycle start packet is decoded by a link capable of making an isochronous request, the link shall notify the PHY so that the PHY can launch an arbitration wavefront within RESPONSE_TIME. This notification is so that the arbitration request reaches the cycle master before a subaction gap appears anywhere. The cycle start notification (i.e., PH_CYCLE_START_ODD/EVEN) to the PHY also indicates which isochronous phase the link thinks has started with the arrival of the cycle start packet. Links that do not support isochronous or do not have any scheduled isochronous packets are not required to send the cycle start packet indication.
d)
A PHY first becomes aware of the isochronous interval at the first of two possible events: 1)
The arrival of a CYCLE_START token, or
2)
The cycle start notification from a local link.
e)
An arriving CYCLE_START token at a PHY is always used to update the isochronous phase to that indicated in the CYCLE_START token. If the isochronous interval begins in a PHY because of a cycle start notification from the link, then the PHY updates its isochronous phase to the phase indicated in that notification.
f)
When a PHY becomes aware that it is in the isochronous interval, it shall upgrade in-phase isochronous requests from its local link to ISOCH_CURRENT, which has the highest isochronous priority.
g)
A link first becomes aware of the isochronous interval at the first of two possible events: 1)
The arrival of a CYCLE_START token, or
2)
The arrival of a cycle start packet.
NOTE—The link can transmit isochronous packets without having received a valid cycle start packet.
h)
An arriving CYCLE_START token at the link is always used to update the isochronous phase to the phase indicated in the CYCLE_START token. If the isochronous interval began in the link because of item g)2, then the link infers the loss or lack of a CYCLE_START token as it enters the isochronous interval. The link’s perceived phase is always delivered to the PHY in the cycle start notification to help keep the link and PHY synchronized. In other words, the link is required to internally track isochronous phases.
i)
The isochronous interval ends at each PHY and link with arrival and/or generation of an ASYNC_EVEN/ODD.
j)
The isochronous phase (i.e., even or odd) is reset to the even phase with each bus reset. The phase is inverted with the ASYNC_EVEN/ODD that ends the isochronous interval. As such, the phase indication describes the phase of the upcoming isochronous interval or the current isochronous interval in progress. As noted above, the phase information in a CYCLE_START token or from a link’s indication of a cycle start packet when a CYCLE_START token is missing is used to confirm the phase. Both links and PHYs track the phase by observing the CYCLE_START token or cycle start packet and by observing the ASYNC_EVEN/ODD.
444
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
k)
The link makes either ISOCH_EVEN or ISOCH_ODD requests to its PHY in a pipelined fashion. ISOCH_EVEN requests for an even interval may be issued after the end of the previous even isochronous interval (marked with an ASYNC_EVEN/ODD as the phase changes to odd). If a request for the even interval is made before the even interval, the request shall be issued sufficiently early so that it is pending at the cycle master before the end of the cycle start packet for the even isochronous interval is sent. Any subsequent requests for the even interval made within the interval shall be issued within RESPONSE_TIME after the end of transmission of a previous isochronous packet for a hybrid bus and shall be issued using the MORE_INFO cycle for a Beta bus. Similar rules apply for the odd interval.
l)
When a given PHY is outside of its isochronous interval, the only valid isochronous requests it can generate are ISOCH_EVEN, ISOCH_ODD, and ISOCH_NONE. They are forwarded with the usual priority, based on the phase of the upcoming interval. For junior Beta clouds, ISOCH_EVEN and ISOCH_ODD requests are not used on the cable and expressly forbidden from appearing on the serial bus.
m)
A PHY shall unconditionally use a received GRANT_ISOCH to exit the A1: Legacy Request state (send TX_GRANT to junior DS port or grant Alpha link) or to service any in-phase isochronous requests received from the link or cable ports. If the PHY is unable to use the grant, the GRANT_ISOCH is first used to unlock DS ports in the network and then is forwarded or returned to the senior port. A request is considered to be in phase in this context if it is an ISOCH_CURRENT received in either the asynchronous or isochronous interval or if it is an ISOCH_EVEN or ISOCH_ODD received during the isochronous interval and the isochronous interval has a phase of even or odd. In a Beta bus, the lack of any other in-phase isochronous requests during the isochronous interval is itself considered to be an in-phase request to end the isochronous interval with an ASYNC_EVEN/ODD. To unlock DS ports, an Alpha null packet is sent (and concludes with an implicit grant to senior, DATA_END). This is done only if the bus is not a Beta bus and the last packet format was not Alpha. Finally, an unused GRANT_ISOCH can be forwarded to the senior port provided it was received from a junior or link port. The forwarding is accomplished as a normal packet ending with, namely, two GRANT_ISOCH symbols at the packet speed. An unused GRANT_ISOCH received from a senior port cannot be immediately returned (i.e., the senior port is in the A2: Grant state awaiting a DATA_NULL to exit). Consequently, a null packet is generated (i.e., Alpha format on hybrid bus to keep borders unlocked and Beta format on Beta bus) and concluded with an implicit grant (i.e., DATA_END). If a null packet had already been generated to unlock the DS ports, then the final step of forwarding or returning the GRANT_ISOCH is omitted because the null packet concluded with an implicit grant to senior.
n)
A PHY shall unconditionally use a received GRANT to exit the A1: Legacy Request state (send TX_GRANT to junior DS port or grant Alpha link) or to service any in-phase asynchronous requests received from the link or cable ports. If the PHY is unable to use the grant, the GRANT is first used to unlock DS ports in the network and then is forwarded or returned to the senior port. A request is considered to be in phase in this context if it is a BORDER, CYCLE_START_REQ, or CURRENT received during the asynchronous interval or if it is a NEXT_EVEN or NEXT_ODD received during the asynchronous interval and the asynchronous interval has a phase of even or odd. In a Beta bus, the lack of any other in-phase asynchronous requests during the asynchronous interval is itself considered to be an in-phase request to end the asynchronous fairness interval with an ASYNC_ODD/EVEN (if all nodes are reporting NONEs and NEXTs of the proper phase). To unlock DS ports, an Alpha null packet is sent (and concludes with an implicit grant to senior, DATA_END). This is done only if the bus is not a Beta bus and the last packet format was not Alpha. Finally, an unused GRANT can be forwarded to the senior port provided it was received from a junior or link port. The forwarding is accomplished as a normal packet ending with, namely, two GRANT symbols at the packet speed. An unused GRANT received from a senior port cannot be immediately returned (i.e., the senior port is in the A2: Grant state awaiting a DATA_NULL to exit). Consequently, a null packet is generated (i.e., Alpha format on hybrid bus to keep borders unlocked and Beta format on Beta bus) and concluded with an implicit grant (i.e., DATA_END). If a null
Copyright © 2008 IEEE. All rights reserved.
445
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
packet had already been generated to unlock the DS ports, then the final step of forwarding or returning the GRANT is omitted because the null packet concluded with an implicit grant to senior. o)
Implicit, or quiet, grants may be used only to grant ISOCH_CURRENT (with a GRANT_ISOCH) or LEGACY_REQUEST (with a GRANT). Upon receipt of a quiet grant, the senior borders and the proxy_root shall begin a timeout for BOSS_RESTART_TIME or subaction_gap time and issue ASYNC_EVEN/ODD tokens if no LEGACY_REQUEST or ISOCH_CURRENT requests are received before the timeout occurs. (The C code has an exception for receipt of an ACK terminated by a quiet grant. In this case, the quiet grant is actually converted to an explicit GRANT before processing.)
p)
Senior borders convert ISOCH_CURRENT to TX_LEGACY and, upon receiving an RX_GRANT, introduce a GRANT_ISOCH into the junior Beta cloud. If the ISOCH_CURRENT is no longer present when the RX_GRANT arrives, a null packet or quiet grant is issued.
16.4.5 Bus reset state machine Figure 16-16 illustrates the bus reset state machine, and following the figure are descriptions applicable to this state machine. R0: Reset Start resetStartActions()
R1: Reset Wait resetWaitActions()
powerReset arbPowerReset() R0:R1
arbTimer >= resetDuration
resetDetected()
All:R0a
R1:T0
arbTimer >= resetDuration + RESET_WAIT
initiatedReset = FALSE
resetComplete() arbTimer = 0;
to T0: Tree ID Start page 448
R1:R0 resetDuration = RESET_TIME
ibr&& !(phyResponse || immediatePhyRequest)
All:R0b
initiatedReset = TRUE resetDuration = RESET_TIME All:R0c
maxArbStateTimeout()
initiatedReset = TRUE; resetDuration = RESET_TIME; if (!timeout) {timeout = TRUE; PH_EVENT_indication( PH_MAX_ARB_STATE_TIMEOUT, 0, 0)}
from TX: Transmit TX:R0 page 453
Figure 16-16—Bus reset state machine On power reset, PHY register values and internal variables are set as specified in this subclause; in particular, all ports are marked disconnected. A solitary node transitions through the reset, tree identification, and self-identification states and enters the A0: Idle state as the root and proxy_root node. Transition All:R0a. The All:R0a transition is the entry point to the bus reset process if the PHY senses BUS_RESET on any active or resuming port or port waiting to attach. This transition shall be made in preference to any other transition that might be simultaneously eligible. The initiation of a bus reset cannot occur until a state’s actions have been completed.
446
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition All:R0b. The All:R0b transition is the entry point to the bus reset process if this node is initiating the process. This transition occurs under either of the following conditions:
a)
SBM makes a PH_CONTROL.request that specifies a long reset.
b)
The PHY detects a disconnect on its senior port.
The initiation of a bus reset does not occur until the current state’s actions have been completed and any PHY-initiated requests have been serviced. Transition All:R0c. The All:R0c transition is the entry point to the bus reset process if the PHY stays in any state (except A0: Idle state during the time that idleArbStateTimeout is false, T0: Tree ID Start state, or a state that has an explicit timeout) for longer than MAX_ARB_STATE_TIME. This condition is not explicitly represented in either the state diagrams or the C code. When a local request is pending (from either the link or the PHY), then idleArbStateTimeout is set to TRUE. This transition is taken if the PHY stays in the A0: Idle state for MAX_ARB_STATE_TIME after idleArbStateTimeout is set to TRUE. The arbitration state timer shall be reset on exit from all states including exits that transition to the same state, e.g., Transition RX:RX. Transition TX:R0. The TX:R0 transition is the entry point to the bus reset process if this node is initiating an arbitrated (short) reset. If arbitration succeeded and the isbrOk variable is set, no packet exists to transmit; and the short bus reset commences immediately. State R0:Reset Start. The node sends a BUS_RESET signal whose length is governed by resetDuration. For a standard bus reset, this interval is long enough for all other bus activity to settle down (RESET_TIME is longer than the worst-case packet transmission plus the worst-case bus turnaround time). SHORT_RESET_TIME for an arbitrated (short) bus reset is significantly shorter because the bus is already in a known state following arbitration. Transition R0:R1. The node has been sending a BUS_RESET signal long enough for all its connected neighbors to detect it. State R1:Reset Wait. The node sends out IDLE signals and waits for all its active ports to receive an IDLE or PARENT_NOTIFY signal. (Either condition indicates that the connected PHYs have left the R0: Reset Start state.) Transition R1:R0. The node has been waiting for its ports to go idle for too long (e.g., the interval can be a transient condition caused by multiple nodes being reset at the same time) and returns to the R0: Reset Start state again. This timeout period is a bit longer than the R0:R1 timeout to avoid a theoretically possible oscillation between two nodes in R0: Reset Start and R1: Reset Wait states. Transition R1:T0. All the connected ports are receiving an IDLE or PARENT_NOTIFY signal. This condition indicates that the connected PHYs are in R1: Reset Wait state or starting the tree identify process (see 16.4.6).
Copyright © 2008 IEEE. All rights reserved.
447
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.4.6 Tree identification state machine Figure 16-17 illustrates the tree identification state machine, and following the figure are descriptions applicable to this state machine. T0: Tree ID Start
T1: Child Handshake
tree_ID_startActions()
childHandshakeActions() R1:T0
T0:T1 T0:T0
from R1: Reset Wait page 446
((!forceRoot || arbTimer >= FORCE_ROOT_TIMEOUT) && children == NPORT - 1) || children == NPORT !T0_timeout && (arbTimer == configTimeout) T0_timeout = TRUE; if (loop == 0) { loop = 1; PH_EVENT_indication(PH_CONFIG_TIMEOUT, 0, 0)}
T2: Parent Handshake T2:T3
T3: Root Contention rootContendActions()
!root && portRArb[parentPort] == ROOT_CONTENTION arbTimer > contendTime && portRArb[parentPort] == IDLE
arbTimer > contendTime && portRArb[parentPort] == PARENT_NOTIFY T3:T1 child[parentPort] = TRUE T3:T2
portTArb(parentPort,PARENT_NOTIFY) childHandshakeComplete()
T2:S0
root || portRArb[parentPort] == PARENT_HANDSHAKE
T1:T2
to S0: Self-ID Start page 450
Figure 16-17—Tree identification state machine
State T0: Tree ID Start. In the T0: Tree ID Start state, a node waits up to a CONFIG_TIMEOUT period to receive the PARENT_NOTIFY signal from at least all but one of its active ports. When PARENT_NOTIFY is observed, that port is marked as a child port. Transition T0:T0. If a loop of active ports exists on the bus, then a configuration timeout occurs and sets the T0_timeout flag. All active ports operating in Beta mode are forced back into the P11: Untested state. This transition may directly result in the completion of the bus initialization or may allow the loop-free build process to set appropriate Beta ports into the P12: Loop Disabled state and to allow a fresh bus reset to complete. Transition T0:T1. If a node detects the PARENT_NOTIFY signal on all of its ports or on all but one of its ports, it knows it is either the root or a branch; it can start the handshake process with its children. Leaf nodes (i.e., nodes with only one connected port) or root nodes (i.e., PARENT_NOTIFY signals on all ports) take this transition immediately. If the forceRoot flag is set, the test for the all-but-one-port condition is delayed long enough so that all other nodes on the bus will have transitioned at least to the T1: Child Handshake state, and all the ports should then be receiving the PARENT_NOTIFY signal. (This extra delay is the FORCE_ROOT_TIMEOUT value.)
448
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
State T1: Child Handshake. All ports that have been labeled as child ports transmit the CHILD_NOTIFY signal. Receipt of the CHILD_NOTIFY signal allows the nodes attached to this node’s child port(s) to transition from the T2: Parent Handshake state to the S0: Self-ID Start state. Leaf nodes have no children; therefore, they exit this state immediately via the T1:T2 transition. If all ports are labeled child ports, then the node knows it is the root. Transition T1:T2. When all of a node’s children stop sending PARENT_NOTIFY signals, the node then waits until it sees the CHILD_HANDSHAKE signal on all of its child ports. It then knows they have all transitioned to the S0: Self-ID Start state, and the node can now handshake with its own parent. State T2: Parent Handshake. In this state, a node is waiting to receive a PARENT_HANDSHAKE signal (for DS connections, this is the result of the node’s sending a PARENT_NOTIFY signal and its parent’s sending a CHILD_NOTIFY signal). This step is bypassed if the node is root (i.e., receiving PARENT_NOTIFY signals on all connected ports). Another way this state can be exited is if the node receives the ROOT_CONTENTION signal from its parent. Transition T2:S0. When the node receives the PARENT_HANDSHAKE signal, it starts the self-identify process by sending the IDLE signal (see S0: Self-ID Start state in 16.4.7). It also takes this transition if it is root because it does not have a parent. Transition T2:T3. If a node receives a PARENT_NOTIFY signal on the same port that it is sending a PARENT_NOTIFY signal, the merged signal is interpreted as ROOT_CONTENTION. This can happen for a single pair of nodes only if each bids to make the other node its parent. State T3: Root Contention. In this state, both nodes back off by sending an IDLE signal, starting a timer, and picking a random bit. If the random bit is one, the node waits longer than if it is zero. When the timer has expired, the node samples the contention port once again. Transition T3:T2. If a node receives an IDLE signal on its proposed parent port at the end of the delay, it once again sends the PARENT_NOTIFY signal. If the other node is taking longer, it takes the T3:T1 transition and allows this node to exit the T2: Parent Handshake state via the Self-ID Start path. Otherwise the two nodes again see the ROOT_CONTENTION signal and repeat the root contention process with a new set of random bits Transition T3:T1. If a node receives a PARENT_NOTIFY signal on the proposed parent port at the end of the delay, the other node has already transitioned to the T2: Parent Handshake state; and the first node returns to the T1: Child Handshake state and becomes the root.
Copyright © 2008 IEEE. All rights reserved.
449
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
16.4.7 Self-identification state machine Figure 16-18 illustrates the self-identification state machine, and following the figure are descriptions applicable to this state machine. S0: Self-ID Start
S4: Self-ID Transmit
self_ID_startActions()
self_ID_transmitActions()
T2:S0
to A0: Idle
pingResponse
to A0: Idle page 453
from T2: Parent Handshake page 448
S4:A0a
pingResponse = FALSE;
!pingResponse && (root || dataComingOn(parentPort))
S4:A0b
if (!root && !betaMode[parentPort]) portSpeed[parentPort] = portRSpeed[parentPort];
S1: Self-ID Grant
from A0: Idle page 453
self_ID_grantActions()
A0:S4
allChildPortsIdentified
S1:S4
if (!root && !betaMode[parentPort]) portSpeed[parentPort] = S100;
S0:S1
S2: Self-ID Receive
root || portRArb[parentPort] == SELF_ID_GRANT
idleReceivePort
self_ID_receiveActions()
S1:S0 S1:S2
S0:S2
dataComingOn(lowestUnidentifiedChild) receivePort = lowestUnidentifiedChild;
!root && dataComingOn(parentPort) receivePort = parentPort; portRArb[receivePort] == IDLE || portRArb[receivePort] == SELF_ID_GRANT || dataComingOn(receivePort) S2:S0
S3: Send Speed Capabilities
arbTimer >= legacyTime(SPEED_SIGNAL_LENGTH) S3:S0 portTSpeedRaw(receivePort, S100); if (!betaMode[receivePort]) portSpeed[receivePort]=portRSpeed[receivePort];
portRArb[receivePort] == IDENT_DONE
S2:S3
child_ID_complete[receivePort] = TRUE; portTSpeedRaw(receivePort, dsPortSpeed[receivePort]) arbTimer = 0;
Figure 16-18—Self-identification state machine
State S0: Self-ID Start. At the start of the self-identify process, the PHY is waiting for a grant from its parent or the start of a self-ID packet from another node. This state is also entered when a node is finished receiving a self-ID packet and all its children have not yet finished their self-identify process. Transition S0:S1. If a node is the root or if it receives a SELF_ID_GRANT signal from its parent, it enters the S1: Self-ID Grant state.
450
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition S0:S2. If a node starts to receive a self-ID packet from its parent, it knows that a self-ID packet is coming from a node in another branch in the tree. State S1: Self-ID Grant. The S1: Self-ID Grant state is entered when a node is given permission to send a self-ID packet. If it has any unidentified children, it sends a GRANT signal to the lowest numbered of those children, unless it is an uncle acting as the proxy for that port, in which case it transmits the proxy self-ID packet. All other connected ports are sent a DATA_PREFIX signal to warn them of the start of a self-ID packet. Transition S1:S2. When the PHY starts to receive a self-ID packet from its lowest numbered unidentified child, the PHY enters the S2: Self-ID Receive state. Transition S1:S0. If the PHY transmitted a proxy self-ID packet, then the PHY transitions back to the S0: Self-ID Start state. Transition S1:S4. If no more children are unidentified, the PHY immediately transitions to the S4: Self-ID Transmit state. State S2: Self-ID Receive. As data symbols are received from the bus, they are passed on to the link layer as PHY data indications. Multiple self-ID packets may be received in this state. The parent PHY is required to also monitor the received speed signal when an IDENT_DONE signal is received from the child. Because of resynchronization delays in repeating the packet, the parent PHY may not complete retransmission of the packet data and data end signal for up to 144 ns or more (as specified by PHY_DELAY) after the start of the IDENT_DONE signal. Because the child sends its speed signal for no more than 120 ns from the start of the IDENT_DONE signal, the parent could miss the speed signal from the child if it entered the S3: Send Speed Capabilities state before completing a speed signal sample. If the PHY gets an IDENT_DONE signal from the receiving port, it flags that port as identified and, if the port is operating in DS mode, starts sending the speed capabilities signal. It also starts the speed signaling timer. Transition S2:S0. When the receive port goes idle, receives a SELF_ID_GRANT signal, or observes the start of a new self-ID packet, it then enters the S0: Self-ID Start state to continue the self-identify process for the next child. The last case guards against a possible failure to observe an IDLE signal. Transition S2:S3. The port has received an IDENT_DONE signal from the child. State S3: Send Speed Capabilities. If a node is capable of sending data at a higher rate than S100 and the receiving port is operating in DS mode, it transmits on the receiving child port its speed capability signals for a fixed duration SPEED_SIGNAL_LENGTH. The parent PHY is required to also monitor the received speed signal when an IDENT_DONE signal is received from the child. Transition S3:S0. When the speed signaling timer expires and the receive port is operating in DS mode, any signals sent by the child have been latched so it is safe to continue with the next child port. This point is also when the negotiatedSpeed field in the port register map is set for DS-mode operation.
Copyright © 2008 IEEE. All rights reserved.
451
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State S4: Self-ID Transmit. The S4: Self-ID Transmit state may be entered either as part of the selfidentify process or as the result of the receipt of a PHY ping packet. In the latter case, any pending Alpha link requests are cancelled, and the set of self-ID packets is transmitted.
When the S4: Self-ID Transmit state is entered as part of the self-identify process, the actions are more complex. At this point, all child ports have been flagged as identified so the PHY can now send its own selfID packet. When a nonroot node is finished, it sends an IDENT_DONE signal while simultaneously transmitting a speed capability signal to its parent and an IDLE signal to its children. The speed capability signal is transmitted for a fixed time duration of SPEED_SIGNAL_LENGTH. Simultaneously it monitors the bus for a speed capability transmission from the parent. The highest indicated speed is recorded as the speed capability of the parent. The root node sends only an IDLE signal to its children. The children then enter the A0: Idle state (see 16.4.8), but children on DS ports never start arbitration because an adequate arbitration gap never opens up until the self-identify process is completed for all nodes. While transmitting the IDENT_DONE signal in the S4: Self-ID Transmit state, the child monitors the received speed signal from the parent. The child PHY then transitions to the A0: Idle state when it receives a DATA_PREFIX signal from its parent. The parent PHY is in the S2: Self-ID Receive state to receive the self-ID packet(s) from the child. When the parent PHY receives an IDENT_DONE signal from the child PHY, the parent transitions to the S3: Send Speed Capabilities state. In the S3: Send Speed Capabilities state, the parent transmits a speed signal for 100 ns to 120 ns to indicate its own speed capability and monitors the received speed signal from the child. The highest indicated speed is recorded as the speed capability of the child. After transmitting its own speed signal, the parent PHY transitions to the S0: Self-ID Start state. Transition S4:A0a. The PHY then enters the A0: Idle state when it has transmitted a self-ID packet as a response to a ping packet. Transition S4:A0b. The PHY then enters the A0: Idle state when the self-ID packet has been transmitted, when this is not a ping response, and if either of the following conditions is met: a) The node is the root. When the root enters the A0: Idle state, all nodes are now sending IDLE signals; and the gap timers will eventually get large enough to allow normal arbitration to start. b) The node starts to receive a new self-ID packet. This packet will be the self-ID packet for the parent node or another child of the parent. This event shall cause the PHY to transition immediately out of the A0: Idle state into the RX: Receive state (see 16.4.8).
When the parent port will be operating in DS mode, the negotiatedSpeed field in the port register map for the parent port is set.
452
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
16.4.8 Arbitration state machine Figure 16-19 illustrates the arbitration state machine, and following the figure are descriptions applicable to this state machine. A0: Idle
A2: Grant
idleActions()
grantActions()
A0:A2
(proxyRoot && (legacyJuniorRequest ) && !arbOk) || betaPortRequest fromA0 = TRUE;
!active[requestingPort] || portRArb[requestingPort] == REQUEST_CANCEL
to TX:Transmit
A1: Legacy Request
TX:A2
legacyRequestActions()
A0:A1
A2:TX
sendNullPacket = TRUE;
!immediateRequest && !proxyRoot && (JuniorRequest || arbOk)
A1:A2
legacyGrant() && !ownRequest && (legacyJuniorRequest || convertedRequest) dataComingOn(requestingPort);
A2:RX
receivePort = requestingPort Grant() && ownRequest
A1:TX
// Arbitration WON
RX: Receive gapToken(seniorPort);
receiveActions()
A1:A1
requestingPort != NPORT
RX:A2
dataComingOn(seniorPort);
A1:RX
receivePort = seniorPort // Arbitration LOST or deferred
TX: Transmit transmitActions()
A0:TX
!concatenatedPacket && (flyByOk || grantSelf) && requestingPort == NPORT RX:TX // Arbitration WON
immediateRequest || (proxyRoot && arbOk) || grantSelf // Arbitration WON
endOfPacket && grantSelf endOfPacket && !grantSelf && requestingPort == NPORT
TX:TX // Reinvokes transmitActions()
TX:A0
A2:TX isbrOk
TX:R0 A0:S4
pingResponse
initiatedReset = TRUE resetDuration = SHORT_RESET_TIME
to S4: Self-ID Transmit page 450
S4:A0a
from S4: Self-ID Transmit
TX:A2
endOfPacket && !grantSelf && requestingPort != NPORT
to R0: Reset Start page 446
to A2: Grant
S4:A0b
PH: PHY Response phyResponseActions()
A0:PH
phyResponse // Transmit a PHY packet concatenatedPacket PH:A0
RX:RX
// Reinvokes receiveActions()
dataComing()
A0:RX
// Arbitration LOST or deferred !concatenatedPacket && !(flyByOk || grantSelf) && requestingPort == NPORT
RX:A0
Figure 16-19—Border arbitration state machine
Copyright © 2008 IEEE. All rights reserved.
453
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
State A0: Idle. All inactive nodes stay in the A0: Idle state until an internal or external event. All DS ports transmit the IDLE arbitration signal or DATA_PREFIX (if the dsStuck flag is set) while Beta ports follow the Beta-mode request repeating rules (see 16.4.2.2.1). Transition A0:A1. If the PHY is not the proxy_root and
a)
Receives a LEGACY_REQUEST signal from one of its junior ports, or
b)
It has a nonimmediate queued request from its own Alpha link and it meets the Alpha timing requirements (arbOk()), or
c)
It is a senior border, it has a nonimmediate queued request from its own link or a BOSS arbitration request from one of its junior ports, and it meets the Alpha timing requirements (arbOk()),
then it passes the request on to its senior port. The arbOk() function qualifies asynchronous requests according to the time elapsed since the A0: Idle state was last entered. In particular, the test for a subaction gap is performed for a single value (equality), not a greater-than comparison. If arbitration were to be initiated at other times between the detection of a subaction gap and an arbitration reset gap, some nodes could mistakenly observe an arbitration reset gap. NOTE—The intent is that any legacy-launched requests are forwarded immediately up the tree, regardless of whether the senior port is DS or Beta (see situation a). Also, any request from a legacy link gets launched on the bus and forwarded up the tree as a LEGACY_REQUEST signal after timings have been met regardless of the senior port’s type (see situation b). Finally, any Beta cloud that does not contain the proxy_root has to convert all requests to LEGACY_REQUEST signals and forward them, via DS, to the proxy_root’s cloud. This responsibility belongs to the senior border in each Beta cloud: hence situation c.
Transition A0:A2. If the PHY receives a LEGACY_REQUEST signal from one of its junior ports, has no queued requests from its own Alpha link, and is the proxy_root, then it starts the bus grant process. If no LEGACY_REQUEST signal has been received, it shall also start the bus grant process if a request is received on a Beta port (but not its attached link). Transition A0:PH. If an extended PHY packet (other than the ping packet) has been received, a response is required. Transition A0:TX. If the PHY has a queued request from its own Alpha link and it is the proxy_root, or if the PHY has a queued request from its own Beta link and it either receives a GRANT token or is BOSS with the last subaction completed, or if the PHY has a queued immediate request (generated during packet reception if the link layer needs to send an acknowledge), then the PHY notifies the link layer that it is ready to transmit and enters the TX: Transmit state. Transition A0:S4. In response to the receipt of a PHY ping packet, the variable pingResponse is set to TRUE; and a transition is made to the S4: Self-ID Transmit state to send the self-ID packet(s). Transition A0:RX. If a PHY starts receiving a packet, it immediately enters the RX: Receive state. State A1: Legacy Request. A PHY wishes to send a legacy request and is required to forward that request toward the proxy_root. The PHY sends a LEGACY_REQUEST signal to its senior port and a DATA_NULL signal to all its nonrequesting junior ports (data prefix for DS ports). Transition A1:A1. If the PHY receives an asynchronous start or arbitration reset token on a Beta port while waiting to be granted for a LEGACY_REQUEST signal, then it sets a flag to cause the token to be repeated. Transition A1:A2. If the PHY receives a GRANT signal from its senior port, if it does not have a pending request from its attached link, and if either a legacy request or (for a senior border) a converted Beta request is active on a junior port, then the PHY grants the bus to that port.
454
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Transition A1:RX. If the PHY sees that the dataComingOn variable has become asserted on its senior port, then it knows that it has lost the arbitration process and prepares to receive a packet. If the link layer was making the request, it is notified. Transition A1:TX. If the PHY receives a GRANT signal from its senior port and the link layer has an outstanding request (i.e., asynchronous or isochronous), the PHY enters the TX: Transmit state. State A2: Grant. During the grant process, the requesting junior port is sent a GRANT signal and the other junior ports are sent DATA_NULL signals so that they prepare to receive a packet. Transition A2:RX. If the PHY sees that the dataComingOn variable has become asserted on the requesting junior port, the grant handshake is complete; and the node goes into the RX: Receive state. Transition A2:TX. If the requesting junior port withdraws its request (i.e., the granting PHY sees a REQUEST_CANCEL signal) or is no longer active, the PHY goes directly to the TX: Transmit state to send a null packet. State PH: PHY Response. When the node has received an extended PHY packet (other than the ping packet) that requires a response, this state takes the appropriate actions, builds a remote reply or remote confirmation packet, and transmits the packet from all active ports. Transition PH:A0. After transmitting the PHY response packet, the node returns unconditionally to idle. State RX: Receive. When the node starts the receive process, it notifies the link layer that the bus is busy and starts the packet receive process. Outstanding fair and priority requests from an Alpha link are cancelled (immediately if arbitration enhancements are globally disabled; otherwise, by the receipt of any packet other than an acknowledgement), and the link may reissue them later. Requests by Beta links are not cancelled. The packet received could be a PHY packet (e.g., self-ID, link-on, or PHY configuration), acknowledge, or normal data packet. PHY configuration and link-on packets are interpreted by the PHY and passed on to the link layer. Transition RX:A0. If the transmitting node stops sending a packet and no additional packet is concatenated to it (i.e., the received signal is DATA_END or IDLE) and the PHY cannot concatenate a queued packet of its own (e.g., fly-by arbitration is disabled or no packet is queued), then the bus is released and the PHY returns to the A0: Idle state. Transition RX:A2. If a transmitting node finishes sending a packet, if active requests are coming from its junior ports, and if no packet is concatenated, the PHY goes to the A2: Grant state. Transition RX:RX. If a packet ends, but another packet is concatenated to it, the receive process is restarted. The arbitration state timer is reset. Transition RX:TX. If fly-by arbitration is enabled and an acknowledge or isochronous packet ends (and another packet is not concatenated to it), or if a subaction has explicitly ended, a queued request may be granted. State TX: Transmit. Unless an arbitrated (short) bus reset has been requested, the transmission of a packet starts by the node sending SPEED and DATA_PREFIX signals (as appropriate) and then sending PHY clock indications to the link layer. For each clock indication, the link sends a PHY data request. The clock indication-data request sequence repeats until the link sends a PH_REQ_DATA_PREFIX, PH_REQ_DATA_END, or PH_REQ_SUBACTION_END signal. Concatenated packets are handled within this state when the link sends a PH_REQ_DATA_PREFIX signal. The arbEnable flag is cleared if this Alpha request was fair.
Copyright © 2008 IEEE. All rights reserved.
455
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Transition TX:A0. If the node has finished sending a packet, if the link layer is not requesting concatenation of another packet, and if the node cannot grant any pending Beta requests (i.e., the node is not at the end of a subaction), the PHY returns to the A0: Idle state. Transition TX:A2. If the link layer has finished sending a packet and is not requesting concatenation of another packet, if no request is queued from its own Beta link, and if the PHY can grant a request from one of its Beta ports (i.e., the previous packet was the end of a subaction), then the PHY transitions to the A2: Grant state to send a GRANT signal to a requesting Beta port. Transition TX:R0. If arbitration succeeded and the isbrOk variable is set, no packet exists to transmit. The PHY transitions to the R0: Reset Start state to commence a short bus reset. Transition TX:TX. If the node has finished sending a packet and the link layer is requesting concatenation of another packet or if the node can grant a pending Beta request from its own link (i.e., the PHY is BOSS and the previous packet was the end of a subaction), then the PHY returns to the TX: Transmit state to send the new packet.
16.4.9 Large diameter networks There is a need for large diameter networks with many nodes. Typical applications for large networks are public address systems or industrial automation. The timeouts BOSS_RESTART_TIME and TEST_INTERVAL need to be modified and the loop prevention algorithms updated in order to utilize IEEE Std 1394 for large diameter networks. Extending network diameter in this way is applicable only for networks utilizing Beta signaling and implementing the BOSS arbitration scheme. Neither hybrid network size nor the size of networks using DS signaling is extended. Support for large diameter networks is optional.
16.4.9.1 BOSS_RESTART_TIME BOSS_RESTART_TIME is the time allowed for a subaction to complete and is used only if a node does not use the legacy gap count. BOSS_RESTART_TIME is used only at the root/proxy_root of a B_bus, and then only if the node does not store gap_count (permitted for nodes that do not support legacy interfaces or a legacy link). This timeout limits the network diameter in terms of hops and cable length between the nodes. BOSS_RESTART_TIME affects the network behavior only in case of failures and causes the proxy_root to initiate an ack_missing condition and to take BOSS-ship. A main contributor to the delays building the time measured by the arbitration timer up to the BOSS_RESTART_TIME are the PHY repeater delays of the involved nodes. Due to the fact that the PHY repeater delay of PHYs with ports implementing Clause 20 will be noticeably higher than those not so doing, the problem of restricted network diameters will become more critical for PHYs implementing Clause 20. The impacts of enlarging the value for BOSS_RESTART_TIME are as follows: a)
BOSS_RESTART_TIME is used for ACK-missing recovery. An increased value for BOSS_RESTART_TIME will delay the time for this recovery, but this is a robustness issue.
b)
BOSS_RESTART_TIME is used in circumstances when a packet is transmitted that is not marked as “End of Subaction.” This happens with PHY packets. An increased value for BOSS_RESTART_TIME will delay the time for the detection of end of subaction, but this happens only rarely (PHY packets are used rarely).
456
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
c)
BOSS_RESTART_TIME is used to delay the start the continuous transmission of tokens after the end of the isochronous interval or after End of Subaction in the asynchronous phase on an idle bus. This is to compensate for the accumulated difference in repeat times for data and arbitration tokens, and provides a good worst-case estimate. This effect is related to hop count, rather than network diameter. This is also a robustness issue, and the longer wait is completely benign except when error recovery is needed (i.e., when a node fails to see the ASYNC_EVEN/ODD token at the end of an ACK packet). A longer value would impact performance unnecessarily.
d)
BOSS_RESTART_TIME is used as a robustness mechanism when the bus is “stuck.” Again, the longer wait is benign except when error recovery is needed.
In order to use the longer timeout only when necessary to support a large diameter network [cases a), b) and d) above], a new constant, LONG_BOSS_RESTART_TIME, is introduced with a nominal value of 80 µs. The C code also defines the implementation flag USE_LONG_BOSS_RESTART_TIME. A PHY shall implement this flag as follows: —
As a power-reset configuration option (typically a configuration pin) so that the system designer may chose whether the system can be used in a large diameter network, and only use the longer timeouts in necessary applications; or
—
Always TRUE so that the PHY can be used in a large diameter network, but timed detection of a subaction gap (e.g., after a PHY packet) and token error recovery will be slower than necessary in networks with diameter up to 10 µs; or
—
Always FALSE so that timings are based on BOSS_RESTART_TIME and so that the PHY is not suitable for use in large diameter networks.
16.4.9.2 TEST_INTERVAL TEST_INTERVAL is used during the loop test procedure and is defined as the time to allow a test value to be returned as an LTS. When large diameter networks are not supported, the TEST_INTERVAL is calculated as ~768/BASE_RATE (7.8 µs nominal). In a large diameter network, using LONG_BOSS_RESTART_TIME, the loop test procedure may fail to detect a loop within this 7.8 µs interval. Therefore, in a large diameter network, the value of TEST_INTERVAL is defined to be LONG_BOSS_RESTART_TIME/2, i.e., 40 µs nominal. For networks other than large diameter networks, the loop test on a single port is repeated 7 times (COLLISION_LIMIT) in case of a detected collision, which may result in an overall time frame of the loop test procedure on a single port of 54 887 µs. This value needs to be significantly smaller than the MAX_OCCUPANCY_TIME (nominally 84 µs) to ensure that the final LTP with ATTACH_IN_PROGRESS is seen by all controlling nodes on other buses before an attach is completed. Due to the retry mechanism used by the loop test procedure, the maximum duration to test one port could now be up to COLLISION_LIMIT * TEST_INTERVAL = 287 µs. This requires a change in the loop test procedure to avoid violating MAX_OCCUPANCY_TIME. Therefore, for large diameter networks, the loop test procedure is modified to last longer than 84 µs over several arbitration phases.
Copyright © 2008 IEEE. All rights reserved.
457
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
458
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17. Parallel PHY-link interface This clause specifies the signaling, protocol, and electrical characteristics of the interface between a discrete PHY and a link at data rates up to S3200. The interface is described independently of other operational characteristics of either PHY or link.
17.1 Introduction This clause defines three different variants of the parallel PHY-link interface. They are known as the Alpha (A), Beta (B), and Beta Plus (B Plus) interfaces. The characteristics of the three interfaces are compared in Table 17-1.
Table 17-1—Comparison of Alpha, Beta, and Beta Plus PHY-link interfaces Interface
Maximum data rate
Data bus width
Clock rate (MHz)
Alpha (A)
S400
2 bits at S100 4 bits at S200 8 bits at S400
49.152
Beta (B)
S800
8 bits
98.304
Beta Plus (B Plus)
S3200
8 bits at S1600 and below 16 bits at S3200
196.608
The signals comprising the Link-PHY interfaces are summarized in Table 17-2. These signals are defined in the remainder of this clause.
Table 17-2—Summary of PHY-link interface signals Interface type Signal Alpha
Beta
Beta Plus
D[0:7]
Required
Required
Required
D[8:15]
N/A
N/A
Optional
Ctl[0:1]
Required
Required
Required
LReq
Required
Required
Required
SClk / PClk
Required
Required
Required
LClk
N/A
Required
Required
LPS
Required
Required
Required
LinkOn
Required
Required
Required
PInt
N/A
Required
Required
Beta_Mode_Link
N/A
Optional
Optional
Beta_Plus_Link
N/A
N/A
Optional
Copyright © 2008 IEEE. All rights reserved.
459
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-2—Summary of PHY-link interface signals (continued) Interface type Signal Alpha
Beta
Beta Plus
Data_High_Valid
N/A
N/A
Optional
Direct
Optional
Optional
Optional
Backplane
Optional
N/A
N/A
Clk25
Optional
N/A
N/A
The Alpha interface is specified in 17.2. The Beta and Beta Plus interfaces are specified in 17.3. Subclause 17.4 provides information about isolation barriers that is applicable to all three types of PHY-link interface.
17.2 Alpha (A) PHY-link interface specification This subclause specifies the protocol and signal timing for the Alpha (A) PHY-link interface. It does not describe specific operation of the PHY except for behavior with respect to this interface. The interface specified in this subclause is a scalable method to connect one serial bus link chip to one serial bus PHY chip. It supports data rates of S25 and S50 in the backplane environment and S100, S200, and S400 in the cable environment. The width of the data bus scales with serial bus speed—two signals support speeds up to 100 Mbit/s while at faster speeds a total of two signals per 100 Mbit/s are necessary. The clock rate of the signals at this interface remains constant, independent of serial bus speed. The interface permits isolation for implementations where it is desirable. The interface may be used by the link to transmit data, receive data or status, or issue requests. The link makes requests of the PHY via the dedicated LReq signal in order to read or write a PHY register, to ask the PHY to initiate a transmit operation, or to control arbitration acceleration. In response, the PHY may transfer control of the bidirectional signals to the link. At all other times the PHY controls the bidirectional signals and may autonomously transfer data to the link, for either a receive operation (when a packet is received from a serial bus) or a status transfer. Discrete PHY implementations shall support all of the PHY signals shown in Figure 17-1. Discrete link implementations shall support D[0:n], Ctl[0:1], LReq, and SClk; link support for the other signals is optional. For both PHY and link, the number of data bits implemented, n, depends upon the maximum speed supported by the device. The PHY/link interface signals are described in Table 17-3.
460
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
D[0:n] Ctl[0:1] LReq SClk LPS LinkOn
Link
Direct Backplane Clk25
PHY
Direct
Figure 17-1—Alpha PHY-link interface logical signaling
Table 17-3—Alpha PHY-link interface signal descriptions Name
Driven by
Description
D[0:n]
Link or PHY
Data
Ctl[0:1]
Link or PHY
Control
LReq
Link
Link request
SClk
PHY
12.288 MHz, 24.576 MHz, or 49.152 MHz clock (synchronized to the PHY transmit clock)
LPS
Link
Link power status—indicates that the link is powered and functional
LinkOn
PHY
Occurrence of a link-on event
Direct
—a
Set high to disable differentiator outputs for the Ctl[0:1], D[0:n], and LReq signals
Backplane
—a
Set high if backplane PHY
Clk25 a
—
a
Meaningful only if Backplane is high—set high to indicate a 24.576 MHz SClk; otherwise 12.288 MHz
Usually determined by design or system configuration options (such as hardware strapping).
Data are transferred between the PHY and link on D[0:n]. The implemented width of D[0:n] depends on the maximum speed of the device—two bits for S100 or slower, four bits for S200, and eight bits for S400. At S100 or slower, packet data are transferred on D[0:1], at S200 on D[0:3], and at S400 on D[0:7]. Implemented but unused D[0:n] signals shall be driven low by the device that has control of the interface. The PHY or the link may drive Ctl[0:1] to indicate the type of data transfer on D[0:n]. The encoding of the control bus signals is specified by Table 17-4 and Table 17-5. The LReq signal is used by the link to request access to a serial bus for packet transmission, to read or write PHY registers, or to control arbitration acceleration. The presence of a stable SClk signal generated by the PHY is necessary for the PHY/link interface to be operational. When SClk is not shown in the timing diagrams in this subclause, each Ctl[0:1], D[0:n] or LReq bit cell represents a single clock sample time. The specific timing relationships are described in 17.2.8.2 and 17.2.8.3.
Copyright © 2008 IEEE. All rights reserved.
461
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-4—Ctl[0:1] when PHY is driving Ctl[0:1]
Name
Meaning
002
Idle
No activity
012
Status
The PHY is sending status information to the link
102
Receive
A packet is being transferred from the PHY to the link
112
Grant
The link is granted the bus to send a packet
Table 17-5—Ctl[0:1] when the link is driving (upon a grant from the PHY) Ctl[0:1]
Name
Meaning
002
Idle
Transmission complete, release bus
012
Hold
The link is holding the bus while preparing data or indicating that it wishes to reacquire the bus without arbitrating to send another packet
102
Transmit
The link is sending a packet to the PHY
112
—
Unused
NOTE—In cases where the PHY and link are powered independently of each other, the link implementation should be able to detect the loss of SClk from an otherwise initialized and operational PHY/link interface.
The LPS signal may be used by the link to disable SClk or reset the interface, as specified in 17.2.1. The LinkOn signal permits the PHY to indicate an interrupt to the link when LPS is logically false. The details are specified in 17.2.2. The Direct input controls digital differentiators on the D[0:n], Ctl[0:1], and LReq signals. When set high, the Direct input shall disable differentiator outputs on these signals (which shall be otherwise enabled). In the case that the link does not implement Direct, the link shall be configured so that output on these signals, differentiated or not, conforms to the value of Direct provided to the PHY. NOTE—Differentiators may be required when the PHY and link are connected through an optional isolation barrier; see annex A for a discussion of electrical isolation in the cable environment. A digital differentiator drives its output signal for one clock period whenever the input signal changes, but places the output signal in a high-impedance state so long as the input signal remains constant. Figure 17-2 illustrates this signal transformation.
Input
Output
0
1
1
0
0
0
1
0
0
0
1
Z
0
Z
Z
1
0
Z
Figure 17-2—Digital differentiator signal transformation
462
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
When a backplane PHY is connected to a link, the Backplane input shall be strapped high. The Clk25 input is meaningful only to indicate the SClk frequency generated by a backplane PHY. In the backplane environment, data transfers use D[0:1]. SClk is used to clock the transfers at either 12.288 MHz (for TTL applications) or 24.576 MHz (for BTL and ECL applications). This yields PHY data rates at the backplane of S25 and S50, respectively.
17.2.1 Initialization and reset The LPS input requests the PHY to disable or enable the PHY/link interface. The output characteristics of LPS, if provided by the link, depend upon the interface mode, differentiated or undifferentiated. When the interface mode is differentiated, LPS shall be a pulsed output while logically asserted. When logically deasserted, LPS shall be driven low in either interface mode. The characteristics of LPS are specified by Figure 17-3 and Table 17-6.
LPS TLPSH
TLPSL
Figure 17-3—LPS waveform when differentiated Table 17-6—LPS timing parameters Parameter
Unit
Minimum
Maximum
TLPSL
LPS low time (when pulsed)
μs
0.09
1.00
TLPSH
LPS high time (when pulsed)
μs
0.09
1.00
Duty cycle (when pulsed)
%
20
60
TLPS_RESET
Time for PHY to recognize LPS logically deasserted and reset the interface
μs
1.2
2.75
TLPS_DISAB
Time for PHY to recognize LPS logically deasserted and disable the interface
μs
25
30
Time to permit the optional differentiator and isolation circuits to restore during an interface reset
μs
15
20a
LE
TRESTORE
a
Description
This maximum does not apply when the PHY-link interface is disabled (see Figure 17-5), in which case an indefinite time may elapse before LPS is reasserted. Otherwise, in order to reset but not disable the interface, it is necessary that the link insure that LPS is logically deasserted for less than TLPS_DISABLE.
The link requests the PHY to reset the interface by deasserting LPS. Within 1.0 µs after it deasserts LPS, the link shall place Ctl[0:1] and D[0:n] in a high-impedance state and condition LReq according to the interface mode; if undifferentiated, LReq shall be driven zero. Otherwise, it shall be placed in a high-impedance state. If the PHY observes LPS logically deasserted for TLPS_RESET, it shall reset the interface. The voltage levels shown in Figure 17-4 for Ctl[0:1], D[0:n], and LReq while LPS is logically deasserted are accurate only for an undifferentiated interface, but the timing relationships remain accurate for both modes. When the interface is undifferentiated, the PHY drives Ctl[0:1] and D[0:n] to zero. Otherwise, the PHY places the Ctl[0:1] and D[0:n] signals in a high-impedance state.
Copyright © 2008 IEEE. All rights reserved.
463
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Ctl D LReq LPS LPS (pulsed) SClk TLPS_RESET
TRESTORE
Figure 17-4—Alpha PHY-link interface reset via LPS If the link continuously deasserts LPS for a longer period, it requests the PHY not only to reset, but also to disable the interface (see Figure 9-5). The link shall condition its outputs as already described for reset. If the PHY observes LPS logically deasserted for TLPS_DISABLE, it shall disable the interface. The PHY has already reset the interface as described previously; it now disables the interface by stopping SClk. The voltage levels shown in Figure 17-5 for Ctl[0:1], D[0:n], LReq, and SClk, while LPS is logically deasserted, are accurate only for an undifferentiated interface, but the timing relationships remain accurate for both modes. When the interface is undifferentiated, the PHY disables the interface by driving SClk to zero while continuing to drive Ctl[0:1] and D[0:n] to zero. Otherwise, the PHY disables the interface by placing SClk in a high-impedance state while continuing to maintain the Ctl[0:1] and D[0:n] signals in a high-impedance state. Ctl D LReq LPS LPS (pulsed) SClk TLPS_DISABLE
TRESTORE
Figure 17-5—Alpha PHY-link interface disable via LPS NOTE—When the PHY-link interface is disabled and none of the PHY’s ports are active or in a transitional state, the PHY may place most of its circuitry in a low-power state.
When the PHY-link interface is reset, the PHY shall cancel any outstanding bus request or register read request. Although the cancellation of bus requests may affect PHY arbitration states in ways not described in Clause 16, the PHY’s behaviors (as observable from a serial bus) shall be consistent with that clause. For example, the PHY may have initiated arbitration in response to a bus request but reset of the PHY/link interface might cancel the request before it is granted. Appropriate PHY behavior would be the transmission of a null packet. The state machines and C code (in Clause 16 and Clause 19, respectively) describe the PHY’s operation as if the interface to the link is always operational. If the PHY/link interface is reset while the link is transmitting
464
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
a packet, the PHY shall behave as if the link had signaled Idle and terminated the packet. Similarly, any S[0:3] status bit information generated by the PHY while the interface is not operational (whether reset, disabled, or in the process of initialization) shall be zeroed and shall not cause a status transfer upon restoration of the interface. The handshake just described either resets or resets and then disables the interface when the link deasserts LPS for a minimum of 2.75 µs or 30 µs, respectively. In either case (or after power reset), normal operations may be restored if the link asserts LPS. After observing LPS, if SClk is not already provided by the PHY, it shall resume SClk as soon as possible, but no earlier than 10 µs since the PHY’s most recent power reset. If the PHY/link interface is differentiated and SClk is resumed, the PHY shall commence by driving SClk low for a minimum of 5 ns. In either mode, the PHY shall ensure that duty cycle and period requirements of Table 17-53 are met from the first rising edge of SClk onwards. Once SClk is available, the PHY and link shall condition their Ctl[0:1] and D[0:n] outputs in accordance with Table 17-7. The reference point is the first rising edge of SClk after LPS is asserted.
Table 17-7—Initialization of the Alpha PHY-link interface Interface mode Device Differentiated
Undifferentiated
PHY
For one and only one of the first six cycles of SClk after the reference point, drive Ctl[0:1] and D[0:n] to zero and otherwise, for these cycles and the seventh, place them in a high-impedance state.
Continue to drive Ctl[0:1] and D[0:n] to zero for the first seven cycles of SClk after the reference point.
Link
For one and only one of the first six cycles of SClk after the reference point, drive Ctl[0:1], D[0:n], and LReq to zero and otherwise place them in a high-impedance state.
For one and only one of the first six cycles of SClk
after the reference point, drive Ctl[0:1] and
D[0:n] to zero; prior to this place them in a highimpedance state. Once these signals have been driven low, return them to a high-impedance state until after the reset completes. LReq shall be driven low once the operating mode of the interface is determined and shall continue to be driven low until after the reset completes.
The PHY may not be able to determine its appropriate interface mode, differentiated or undifferentiated, immediately after a power reset. While the mode is indeterminate, the PHY shall place its outputs in a highimpedance state. Upon the eighth SClk cycle, the PHY shall assert Receive on Ctl[0:1] while simultaneously providing data prefix indication on D[0:n] for at least one SClk cycle. Upon the subsequent SClk cycles, the PHY shall drive Ctl[0:1] and D[0:n] as follows: —
The PHY shall continue to indicate data prefix while it is in a state in which (if initialization of the PHY/link interface were complete) it would normally assert other than Idle on Ctl[0:1], and
—
Subsequently it shall assert Idle on Ctl[0:1] for at least one cycle in order to indicate the completion of PHY/link interface initialization and the resumption of normal operations.
The link may examine Ctl[0:1] once it has driven Ctl[0:1], D[0:n], and LReq to zero for one cycle subsequent to the SClk reference point. When the link simultaneously observes Receive on Ctl[0:1] and data prefix on D[0:n], and subsequently observes Idle on Ctl[0:1], the reset of the PHY/link interface is complete. The PHY shall insure that no more than 10 ms elapse from the reassertion of LPS until the interface is reset. The link shall not assert LReq until the reset is complete.
Copyright © 2008 IEEE. All rights reserved.
465
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Once initialization of the PHY/link interface completes successfully, the link shall not issue an isochronous request until a cycle start packet is either observed or generated by the link.
17.2.2 Link-on and interrupt indications The PHY LinkOn output provides a method to signal the link at times when the PHY-link interface is not operational. The PHY/link interface is not operational when the LPS signal is logically deasserted (see 17.2.1). The characteristics of the LinkOn signal, specified by Table 17-8, permit the link to detect LinkOn in the absence of SClk and also permit the signal to cross an optional isolation barrier. When LinkOn is logically deasserted it shall be driven low.
Table 17-8—LinkOn timing parameters Description
Unit
Minimum
Maximum
Frequency
MHz
4
8
Duty cycle
%
30
60
Persistence—time, measured from the point at which both LPS is active and LCtrl is one, after which the PHY shall not signal LinkOn
ns
—
500
When necessary to communicate a PH_EVENT.indication of LINK_ON or INTERRUPT, the PHY shall assert LinkOn if LPS is logically deasserted and may assert LinkOn if the PHY register LCtrl bit is zero.27 NOTE—While the PHY/link interface is operational, all link-on packets are transferred to the link. When the phy_ID field matches the PHY’s physical ID, this transfer is an implicit PH_EVENT.indication of LINK_ON; the PHY need not assert LinkOn in this case.
Once asserted, the LinkOn signal shall persist so long as the LPS signal is logically deasserted and may persist so long as the PHY register LCtrl bit is zero, with one exception. A bus reset shall clear the LinkOn signal unless a)
The PHY register Port_event bit is one, or
b)
The PHY register Watchdog bit is one and a loop, power failure, or time-out condition exists.
17.2.3 Link requests To request the bus, access a PHY register, or control arbitration acceleration, the link sends a bit sequence (request) to the PHY on the LReq signal. The link always signals all bits of the request. The information sent includes the type of request and parameters that depend upon the type of request. Examples of parameters are packet transmission speed, priority, PHY register address, or data. With the exception of the bus request, each request is terminated by a stop bit of zero. The size of the request, inclusive of the stop bit, varies between 6 bits and 17 bits. When the link transmits zeros on LReq, the request interface is Idle.
27Although the PHY should determine whether or not to signal LinkOn solely on the status of the PHY/link interface, some implementations assert LinkOn if the PHY register LCtrl bit is zero. This is redundant but harmless; software may simply set the LCtrl bit to one in acknowledgment.
466
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The timing for this signal and the definition of the bits in the transfer are shown in Figure 17-6. LR0
LReq
Ctl[0:1]
CA
LR1
LR2
LR3
LR(n-2)
LR(n-1)
CB
Figure 17-6—LReq and Ctl timings If the LReq transfer is a bus request in the cable environment, it is 7 bits or 8 bits long and has the format given in Table 17-9. Links compliant with this standard shall send all 8 bits.
Table 17-9—Bus request format for cable environment Bit(s)
Name
Description
0
Start Bit
1–3
Request Type
Indicates type of bus request—immediate, isochronous, priority, or fair. See Table 17-14 for the encoding of this field.
4–6
Request Speed
The speed at which the PHY is to transmit the packet on a serial bus. This field has the same encoding as the speed code from the first symbol of the receive packet. See Table 17-15 for the encoding of this field.
7
Stop Bit
Indicates start of request. Always one.
Indicates end of transfer. Always zero. If bit 6 is zero, this bit may be omitted.
If the LReq transfer is a bus request in the backplane environment, it is 11 bits long and has the format given in Table 17-10.
Table 17-10—Bus request format for backplane environment Bit(s)
Name
0
Start Bit
1–3
Request Type
4–5
—
6–9
Request Priority
10
Stop Bit
Description Indicates start of request. Always one. Indicates type of bus request—immediate, isochronous, priority, or fair. See Table 17-14 for the encoding of this field. Reserved. Indicates priority of urgent requests. (Only used with FairReq request type.) All zeros indicates fair request. All ones is reserved (this priority is implied by a PriReq). Other values are used to indicate the priority of an urgent request. Indicates end of transfer. Always zero.
If the transfer is a register read request, it is 9 bits long and has the format given in Table 17-11.
Copyright © 2008 IEEE. All rights reserved.
467
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-11—Register read request format Bit(s)
Name
Description
0
Start Bit
1–3
Request Type
4–7
Address
The internal PHY address to be read.
8
Stop Bit
Indicates end of transfer. Always zero.
Indicates start of request. Always one. Indicates that this is a register read. See Table 17-14 for the encoding of this field.
If the transfer is a register write request, it is 17 bits long and has the format given in Table 17-12.
Table 17-12—Register write request format Bit(s)
Name
0
Start Bit
1–3
Request Type
4–7
Address
8–15
Data
16
Stop Bit
Description Indicates start of request. Always one. Indicates that this is a register write. See Table 17-14 for the encoding of this field. The internal PHY address to be written. For a write transfer, the data to be written to the specified address. Indicates end of transfer. Always zero.
If the transfer is an acceleration control request, it is 6 bits long and has the format given in Table 17-13.
Table 17-13—Acceleration control request format Bit(s)
Name
Description
0
Start Bit
1–3
Request Type
Indicates that this is an acceleration control request. See Table 17-14 for the encoding of this field.
4
Accelerate
When zero, instructs the PHY to disable arbitration accelerations. A value of one requests the PHY to enable arbitration accelerations.
5
Stop Bit
Indicates start of request. Always one.
Indicates end of transfer. Always zero.
The request type field is encoded as shown in Table 17-14. The request speed field is encoded as shown in Table 17-15. The actual data rates for the S100, S200, and S400 speed codes are specified in Table 9-10. Although encoding for speeds up to S3200 is specified in Table 17-15, the Alpha PHY/link interface does not support speeds in excess of S400.
468
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-14—Request type field Request Type
Name
Meaning
0002
ImmReq
Take control of the bus immediately upon detecting Idle; do not arbitrate. Used for acknowledge packets.
0012
IsoReq
Arbitrate for the bus after an isochronous gap. Used for isochronous stream packets.
0102
PriReq
Ignore the PHY’s fairness protocol and, unless accelerating, arbitrate after a subaction gap. Used for cycle master or other packets for which the link need not wait for a fairness interval.
0112
FairReq
Arbitrate within the current fairness interval if permitted by the PHY’s fairness interval. Otherwise, arbitrate after an arbitration reset gap.
1002
RdReg
Return specified register contents through status transfer.
1012
WrReg
Write to specified register.
1102
AccCtrl
Disable or enable PHY arbitration accelerations.
1112
—
Reserved for future standardization.
Table 17-15—Request speed field LR[4:6]
Data rate
0002
S100
0012
S1600
0102
S200
0112
S3200
1002
S400
1102
S800
All other values
Reserved
The PHY continuously monitors LReq for link requests and sets internal variables in response to the parameters of the request. These actions occur independently of the state of the PHY arbitration control; the effects upon PHY arbitration, if any, are a consequence of the values of the internal variables, as specified in 16.4. Table 17-16 summarizes the effects of the various link requests.
Table 17-16—Link request effects on PHY variables Request
PHY variables affected
Note
ImmReq, IsoReq, PriReq, FairReq
breq, speed accelerating (see note)
The breq variable is set to IMMED_REQ, ISOCH_REQ, PRIORITY_REQ, or FAIR_REQ according to the type of request. The speed variable is set to S100, S200, etc., according to the encodings specified by Table 17-15. The accelerating variable is affected only by an IsoReq, which sets it to TRUE.
Copyright © 2008 IEEE. All rights reserved.
469
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-16—Link request effects on PHY variables (continued) Request
PHY variables affected
Note
RdReg
—
The values returned in response to a register read are an instantaneous snapshot. Asynchronous events, such as bus reset, may cause the PHY to autonomously change the values of PHY register(s).
WrReg
—
The PHY updates the addressed register with the data field value from the request and sets the value of any PHY variables that correspond to register bits or fields.
AccCtrl
accelerating
If the Accelerate bit in the request is zero, accelerating is cleared to FALSE; otherwise it is set to TRUE.
To request the bus for fair or priority access, the link sends a FairReq or PriReq after the interface has been Idle for at least one clock. The expected response to a bus request is Grant on Ctl[0:1], which the PHY asserts after it has won arbitration. Under other circumstances, the PHY may cancel the bus request or retain it, pending the completion of other PHY activity (see Table 17-18 in 17.2.3.1). The link may reissue a cancelled request when the interface is subsequently Idle. The cycle master link uses a priority request (PriReq) to send the cycle start packet. To request the bus to send isochronous data, the link issues an IsoReq while sending or receiving a cycle start or, during the same isochronous period, while sending or receiving an isochronous packet. The PHY cancels an isochronous request when a subaction gap or bus reset is observed. In order to meet timing requirements, a link may issue an isochronous request after observing tcode 8 in a putative cycle start packet but before verifying the CRC. If the CRC fails, the link shall not transmit isochronous packet(s) but shall cancel any isochronous request as soon as possible. It is not necessary for the link to issue an AccCtrl request with a zero Accelerate bit after the invalid CRC is detected. To send an acknowledge, the link issues an ImmReq during or immediately after packet reception. This ensures that the ACK_RESPONSE_TIME requirement is met and that other nodes do not detect a subaction gap. After the packet ends, the PHY immediately takes control of the serial bus and asserts Grant on Ctl[0:1]. If the packet header CRC passed, the link transmits an acknowledge. Otherwise, the link asserts Idle on Ctl[0:1] for three SClk cycles after observing Grant on Ctl[0:1]. NOTE—Although unlikely, more than one node may perceive (one correctly, the others mistakenly) that a packet is intended for it and issue an immediate request before checking the CRC. The PHYs of all such nodes would grab control of the bus immediately after the packet is complete. This condition would cause a temporary, localized collision of DATA_PREFIX somewhere between the PHYs intending to acknowledge while all the other PHYs on the bus would see DATA_PREFIX. This collision would appear as “ZZ” line state and would not be interpreted as a bus reset. The mistaken node(s) should drop their request(s) as soon as they check the CRC; the spurious “ZZ” line state would vanish. The only side effect of such a collision might be the loss of the intended acknowledge packet, which would be handled by the higher layer protocol.
A bus reset causes the PHY to cancel any pending bus request. In response to register write requests, the PHY takes the value from the data field of the transfer and updates the addressed register. For register read requests, the PHY returns the contents of the addressed register at the next opportunity through a status transfer. If the status transfer is interrupted by a packet received or generated by the PHY, the PHY restarts the status transfer at the next opportunity. Once the link issues a request for access to the bus, it shall not issue another bus request until the request is either granted or cancelled. The PHY shall ignore bus requests issued while a previous request is pending.
470
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.2.3.1 LReq rules In general, the link issues requests asynchronously with respect to activities on a serial bus. However, certain requests are allowed only at specific times. Even when a request is issued at a valid time, serial bus activity may cause the PHY to cancel the request or to defer the request until the other activity has been completed. This subclause specifies when a link may issue a request and the corresponding PHY behavior; these rules permit the link to unambiguously determine the state—satisfied, cancelled, or deferred—of a request. For the purpose of these rules, two specific cycles are defined—labeled CA and CB in Figure 17-6. The rules are specified in terms of the values of the Ctl[0:1] lines during these cycles. The sample point at which the link decides whether or not to initiate a request is CA, which is one or more SClk cycles before CB, the cycle in which the link sends the request’s start bit. The disposition of the request is determined by the value of Ctl[0:1] from CB onward. General rules that govern link and PHY use of the request interface are as follows: —
The link shall not initiate a bus request (fair, priority, immediate, or isochronous) or use the Hold protocol to concatenate a packet until any outstanding request (whether the result of a bus request or the Hold protocol) has been granted or the link has been able to determine that it has been cancelled.
—
The link should not issue a register read or write request when a previous register read request is outstanding. PHY behavior in this case is undefined.
—
All pending bus requests (but not register read requests) are cancelled on a bus reset.
Additional rules for issuing a request are given in Table 17-17.
Table 17-17—Link rules to initiate a request on LReq
Request
Permitted when PHY has control of the interface and Ctl[0:1] at CA is
Permitted when link controls the interface
Additional requirements
Fair, Priority
Idle, Status
No
No fair or priority request shall be issued until any outstanding bus request completes.
Immediate
Receive, Idle
No
Sent after destination_ID decode during packet reception when the link is ready to transmit an acknowledge packet. The start bit of an immediate request shall be transmitted no later than the fourth cycle subsequent to that in which Ctl[0:1] went Idle following packet reception.
Isochronous
Any
Yes
Sent during an isochronous period when the link is ready to transmit an isochronous packet. The start bit of an isochronous request shall be transmitted no later than a) The eighth cycle subsequent to that in which Ctl[0:1] went from Transmit to Idle, or b) The fourth cycle subsequent to that in which Ctl[0:1] went from Receive to Idle. The link shall not issue an isochronous request if it intends to concatenate a packet after the current transmission.
Copyright © 2008 IEEE. All rights reserved.
471
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-17—Link rules to initiate a request on LReq (continued) Permitted when PHY has control of the interface and Ctl[0:1] at CA is
Permitted when link controls the interface
Register read, Register write
Any
Yes
Shall not be issued while there are pending register read requests.
AccCtrl
Any
Yes
Accelerate bit is zero. Issued by cycle slaves if enab_accel is TRUE and shall be issued once every isochronous period, as soon as possible after the local clock indicates the start of a new isochronous period. Accelerate bit is one. May only be issued by cycle slaves once every isochronous period, after a cycle start packet has been recognized and after all of the link’s isochronous requests (if any).
Request
Additional requirements
In general, the PHY behavior varies dependent on whether another serial bus packet is detected before it has successfully completed processing the LReq. The link may determine the PHY disposition of the LReq by monitoring the value of Ctl[0:1] from CB onward, as shown in Table 17-18.
Table 17-18—PHY disposition of link request Request
Ctl[0:1] (at CB or later)
Fair, Priority
Grant Receive
Status, Idle Immediate
Link action
Arbitration won.
Transmit packet.
If arbitration acceleration is enabled, and the packet transferred by the PHY is exactly 8 bits, then request is retained. Otherwise, request is discarded as soon as the PHY determines that the packet has other than 8 bits. Request is always discarded if arbitration acceleration is not enabled.
Continue to monitor for the next change on Ctl[0:1] if request is retained. Once the link starts shifting out the fair or priority LReq, both the link and the PHY monitor the Ctl[0:1] lines to determine if the LReq is to be cancelled. On every rising edge of SClk from CB onwards, if Receive is asserted on Ctl[0:1] and enab_accel is FALSE, the request is cancelled. Otherwise, if arbitration accelerations are globally enabled for the PHY, the request is cancelled only if the packet transferred by the PHY is not 8 bits in length.
Retain the request unless a bus reset was reported in the status.
Unless there was a bus reset, monitor Ctl[0:1] in anticipation of Grant.
Grant
—
Receive
PHY is still transferring a packet; the request is retained.
Continue to receive packet, then monitor Ctl[0:1] in anticipation of Grant.
Retain the request unless a bus reset was reported in the status.
Unless there was a bus reset, monitor Ctl[0:1] in anticipation of Grant.
Status, Idle
472
PHY behavior
Transmit the acknowledge packet.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-18—PHY disposition of link request (continued) Request Isochronous
Ctl[0:1] (at CB or later) Transmit, Idle (driven by link) Grant Receive Status
Register read
PHY behavior Request retained by PHY.
Monitor Ctl[0:1] after releasing the interface.
Arbitration won.
Transmit packet.
Request retained by PHY.
Monitor Ctl[0:1].
Request discarded if status indicates subaction gap (this is an error condition and should not occur). Otherwise, request is retained unless status reports a bus reset.
Continue to monitor for the next change on Ctl[0:1] if request is retained.
Idle
—
Continue to monitor for the next change on Ctl[0:1].
Any (driven by link)
—
Wait until link releases the interface then monitor for the next change on Ctl[0:1].
Grant Receive Status
Request retained. Bus request LReq was previously issued, and now takes priority.
Service previous bus request, then monitor for next change on Ctl[0:1].
Request retained.
Receive packet, then monitor for next change on Ctl [0:1].
Request is retained by the PHY until corresponding register data are returned.
If unrelated status is received or the desired status is interrupted, monitor Ctl[0:1] for desired status.
Idle Register write, Acceleration control
Link action
—
Any
Monitor Ctl[0:1].
Request completed.
—
NOTE—When a PHY autonomously generates packets, e.g., during the self-identify phase or in the transmission of a PHY response packet, it cancels all outstanding bus requests. This behavior is not described because, at such times, a link does not have any outstanding isochronous or priority requests.
In addition to the preceding rules for the use of the PHY/link interface, the timing constants, in units of SClk cycles, of Table 17-19 shall apply. Measurements of serial bus arbitration line states are taken at the cable connector while those of PHY/link interface states are taken at the PHY. The reference point for the latter is the first SClk edge that occurs while Ctl[0:1] are in the indicated state.
Table 17-19—Alpha PHY-link interface timing constants Timing constant
Minimu m
BUS_TO_LINK_DELAY
2
9
DATA_PREFIX_TO_GRAN T
—
25
Copyright © 2008 IEEE. All rights reserved.
Maximu m
Comment Time from the start of RX_DATA_PREFIX to the assertion of Receive on Ctl[0:1]. When a node originates a packet, the time from the start of TX_DATA_PREFIX at the parent port (or if the root, any port) to the PHY’s assertion of Grant on Ctl[0:1].
473
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-19—Alpha PHY-link interface timing constants (continued) Timing constant
Minimu m
Maximu m
LINK_TO_BUS_DELAY
2
5
MAX_HOLD
—
47
Comment At the end of packet transmission by the link, the time from the assertion of Idle on Ctl[0:1] to the start of TX_DATA_END on all transmitting ports. Maximum time that the link may continuously assert Hold on Ctl[0:1] after observing Grant.
17.2.3.2 Acceleration control The ack-accelerated and fly-by arbitration enhancements specified in 16.4 can have adverse effects on the isochronous period if continuously enabled. A serial bus relies upon the natural priority of the cycle master (root) to win arbitration and transmit the cycle start packet as soon as possible after cycle synchronization. Ack-accelerated arbitration or fly-by concatenation by node(s) other than the root can prolong asynchronous traffic on the bus indefinitely and disrupt isochronous operations. The link avoids this problem by selectively disabling and enabling these arbitration enhancements. The acceleration control request permits the link to disable and enable ack-accelerated and fly-by arbitration enhancements, while leaving the other arbitration enhancements unaffected. The cycle master does not issue the acceleration control request. The time period in which ack-accelerated and fly-by arbitration enhancements shall not be used extends from the time of the local cycle synchronization event until a cycle start packet is observed. During this period, the link at any node that is not the cycle master shall use the acceleration control request as follows: a)
If accelerations have been globally enabled, the link shall not make a fair or priority request unless an acceleration control request with a zero Accelerate bit has been transmitted since the most recent local cycle synchronization event.
b)
The link shall not use the Hold protocol to concatenate an asynchronous primary packet after an acknowledge packet, except after its own ack_pending in order to complete a split transaction with a concatenated subaction.
c)
Upon conclusion of this time period, the link may reenable ack-accelerated and fly-by acceleration by transmitting an acceleration control request whose Accelerate bit is set to one.
A link that makes one or more bus requests to transmit an isochronous packet need not use the acceleration control request to reenable fly-by accelerations, since the isochronous request sets the accelerating variable to TRUE. For a bus that does not have an active cycle master, it is not necessary to use the acceleration control request. So long as arbitration enhancements are enabled by Enab_accel in the PHY registers, the fly-by accelerations are also enabled by the default value of accelerating after a power reset.
17.2.4 Status When the PHY has status information to transfer to the link, it initiates a status transfer. The PHY waits until the interface is Idle before performing the transfer. The PHY initiates the transfer by asserting Status on Ctl[0:1] while simultaneously presenting the first 2 bits of status information on D[0:1]. The PHY continues to assert Status on Ctl[0:1] for the duration of the status transfer but may prematurely end the transfer by asserting something other than Status on Ctl[0:1]. This may be done in the event that a packet arrives before the status transfer completes. There shall be at least one Idle cycle in between consecutive status transfers.
474
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The PHY sends 16 bits of status in the following two cases: a)
In response to a register read request, or
b)
After a bus reset, to indicate the node’s new physical_ID.
The latter is the only condition for which the PHY sends a register to the link without a corresponding register read request. In the case of event indications initiated by the PHY, 4 bits of status are sent to the link. The timing for a status transfer is shown in Figure 17-7.
PHY Ctl[0:1]
00
PHY D[0:1]
00
01
01
S[0,1] S[2,3]
01
00
00
S[14,15]
00
00
Figure 17-7—Alpha PHY-link interface status timing The structure of the status data is specified by Table 17-20.
Table 17-20—Alpha PHY-link interface status bits Bit(s)
Name
Description
0
ARB_RESET_GAP
The PHY has detected that a serial bus has been Idle for an arbitration reset gap time.
1
SUBACTION_GAP
The PHY has detected that a serial bus has been Idle for a subaction gap time.
2
BUS_RESET_STAR T
The PHY has entered bus reset state.
3
INTERRUPT
4–7
Address
Register number
8–15
Data
Register contents
This indicates one or more of the following interrupt conditions: — Loop detect interrupt — Cable power fail interrupt — Arbitration state machine time-out — Port event interrupt
Upon successful completion of status transfer to the link, status bits S[0:3] shall be zeroed. The PHY shall also clear ARB_RESET_GAP and SUBACTION_GAP whenever it asserts Grant or Receive on Ctl[0:1], whether or not this status information has been successfully transferred to the link.
The PHY may truncate a status transfer by removing the status indication on Ctl[0:1]. In this event, the PHY shall set to zero whichever of the four status bits that have been successfully transferred to the link. That is, if only S[0:1] have been transferred, only S[0:1] shall be zeroed, while if S[0:3] have been transferred, all of S[0:3] shall be zeroed. The PHY shall reinitiate the status transfer at the earliest opportunity if either a)
At least one of the four status bits S[0:3] is nonzero, or
b)
The truncated status transfer was intended to include PHY register data.
Status transfers shall commence with S[0:1] in all cases.
The PHY shall guarantee that neither subaction nor arbitration reset gap status information is lost because of a response to a register read request. During some period prior to the anticipated detection of a gap, it may be
Copyright © 2008 IEEE. All rights reserved.
475
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
necessary for the PHY to defer completion of a register read request in order to avoid the loss of status information.
17.2.5 Transmit When the link requests access to a serial bus through the LReq signal, the PHY arbitrates for access to the serial bus. If the PHY wins the arbitration, it grants the bus to the link by asserting Grant on Ctl[0:1] for one SClk cycle, followed by Idle for one cycle. After observing Grant on Ctl[0:1], the link takes control of the interface by asserting Idle, Hold, or Transmit on Ctl[0:1] one cycle after sampling Grant from the PHY. The link should assert Idle for one cycle before changing the state of Ctl[0:1] to either Hold or Transmit, but shall not assert Idle for more than one cycle. PHY implementations shall tolerate Idle for one cycle prior to Hold or Transmit. The link asserts Hold to keep ownership of the bus while preparing data but shall not assert Hold on Ctl[0:1] for more than MAX_HOLD cycles subsequent to observing Grant on Ctl[0:1]. The PHY asserts DATA_PREFIX on the serial bus during this time. When it is ready to begin transmitting a packet, the link asserts Transmit on Ctl[0:1] along with the first bits of the packet. After sending the last bits of the packet, the link asserts either Idle or Hold on Ctl[0:1] for one cycle, and then it asserts Idle for one additional cycle before placing those signals in a high-impedance state. Whenever control of the bidirectional signals is transferred between the PHY and link, the device relinquishing control shall drive Ctl[0:1] and D[0:n] to logic zero levels for one clock before releasing the interface. This permits both devices to act upon registered versions of the interface signals while allowing the new owner a clock cycle in which to sample and respond. Note that when the link transfers control to the PHY without a Hold request, an additional clock with logic zero on the control and data signals is necessary so as not to place the signal lines in a high-impedance state before the PHY takes control. An assertion of Hold after the last bits of a packet indicates to the PHY that the link needs to send another packet without releasing the bus. This function is used by the link to concatenate a packet after an acknowledge or to concatenate isochronous packets. With this assertion of Hold, the link simultaneously signals the speed of the next packet on the data lines, as encoded by Table 17-21. Once Hold is asserted, the PHY waits a MIN_PACKET_SEPARATION time and then asserts Grant as before. After observing Grant on Ctl[0:1], the link resumes control of the interface by asserting Idle, Hold, or Transmit on Ctl[0:1]. The link should assert Idle for one SClk cycle, but shall not assert Idle for more than one cycle before changing Ctl[0:1] to Hold or Transmit. In preparation for transmission of a concatenated packet, the link shall not assert Hold on Ctl[0:1] for more than MAX_HOLD cycles subsequent to observing Grant on Ctl[0:1].
Table 17-21—Speed code signaling D[0:n] Data rate
a
476
Transmitted
Observed
000000002
00xxxxxx2a
S100
010000002
0100xxxx2
S200
010100002
010100002
S400
010100012
010100012
S800
010100102
010100102
S1600
010100112
010100112
S3200
111111112
11xxxxxx2
Data prefix indication
An “x” indicates ignored on received.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The link may transmit concatenated packets at different speeds, with one exception—the link shall not concatenate an S100 packet after any packet of a higher speed. When the link wishes to send an S100 packet after any packet of a higher speed, it shall make a separate request. If the multi-speed capabilities of the PHY have not been enabled (see Table 15-1), all concatenated packets shall be transmitted at the speed originally specified as part of the bus request. This requirement provides for backward compatibility when a PHY compliant with this standard is interfaced to a link that is not aware of the necessity to signal speed for each packet. As noted above, when the link has finished sending the last packet, it releases the bus by asserting Idle on Ctl[0:1] for two SClk cycles. The PHY begins asserting Idle on Ctl[0:1] one cycle after sampling Idle from the link. The timings for both a single and a concatenated packet transmit operation are illustrated in Figure 17-8. In the diagram, D0 through Dn are the data symbols of the packet, SP represents the speed code for the packet (encoded according to the values specified in Table 17-21), and ZZ represents high-impedance state. The link should assert the signals indicated by the shaded SClk cycles (this may be necessary in the presence of an isolation barrier).
Single Packet PHY Ctl[0:1]
00
11
00
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
00
PHY D[0:n]
00
00
00
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
00
Link Ctl[0:1]
ZZ
ZZ
ZZ
00
01
01
10
10
10
10
00
00
ZZ
Link D[0:n]
ZZ
ZZ
ZZ
00
00
00
D0
D1
D2
Dn
00
00
ZZ
Concatenated Packet PHY Ctl[0:1]
ZZ
ZZ
ZZ
ZZ
00
00
11
00
ZZ
ZZ
ZZ
ZZ
ZZ
PHY D[0:n]
ZZ
ZZ
ZZ
ZZ
00
00
00
00
ZZ
ZZ
ZZ
ZZ
ZZ
Link Ctl[0:1]
10
10
01
00
ZZ
ZZ
ZZ
ZZ
00
01
01
10
10
Dn-1 Dn
SP
00
ZZ
ZZ
ZZ
ZZ
00
00
00
D0
D1
Link D[0:n]
Figure 17-8—Alpha PHY-link interface transmit timing NOTE—It is not required that the link assert Hold on Ctl[0:1] before sending a packet if the implementation permits the link to be ready to transmit as soon as bus ownership is granted.
Copyright © 2008 IEEE. All rights reserved.
477
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
17.2.6 Cancel The link may relinquish control of the PHY/link interface after a bus requested has been granted if data are not to be transmitted. This causes a null packet to appear on the serial bus and effectively cancels the bus request. If the link cancels a request prior to the transmission of data, it shall use one of the two protocols described in the following paragraphs. After observing Grant on Ctl[0:1], the link takes control of the interface by asserting Idle, Hold, or Transmit on Ctl[0:1] one cycle after sampling Grant from the PHY (as already described in 17.2.5). If the link asserts Idle on Ctl[0:1], it shall continue to assert Idle for two additional cycles before placing those signals in a high-impedance state. This is illustrated by Figure 17-9.
PHY Ctl[0:1]
00
11
00
ZZ
ZZ
ZZ
00
PHY D[0:n]
00
00
00
ZZ
ZZ
ZZ
00
Link Ctl[0:1]
ZZ
ZZ
ZZ
00
00
00
ZZ
Link D[0:n]
ZZ
ZZ
ZZ
00
00
00
ZZ
Figure 17-9—Link cancel timing (after Grant) The PHY shall recognize the cancel on the second Idle cycle; the additional assertion of Idle by the link guarantees that Ctl[0:1] are not left in a high-impedance state before the PHY takes control of the interface. Otherwise, if the link had assumed or maintained control of the interface by asserting Hold on Ctl[0:1] and wishes to relinquish control of the interface, subsequent to the last Hold cycle it shall assert Idle on Ctl[0:1] for two cycles before placing those signals in a high-impedance state. This method may be used either after the initial Grant or to cancel the transmission of concatenated packet. The interface signaling is illustrated by Figure 17-10; the link should assert the signals indicated by the shaded SClk cycles (this may be necessary in the presence of an isolation barrier).
PHY Ctl[0:1]
00
11
00
ZZ
ZZ
ZZ
ZZ
ZZ
00
PHY D[0:n]
00
00
00
ZZ
ZZ
ZZ
ZZ
ZZ
00
Link Ctl[0:1]
ZZ
ZZ
ZZ
00
01
01
00
00
ZZ
Link D[0:n]
ZZ
ZZ
ZZ
00
00
00
00
00
ZZ
Figure 17-10—Link cancel timing (after Hold) The PHY shall recognize the cancel on the first Idle cycle subsequent to Hold. The extra Idle cycle provided by the link avoids the problem of a high-impedance state on Ctl[0:1].
478
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.2.7 Receive Whenever the PHY sees data prefix on a serial bus, it initiates a receive operation by asserting Receive on Ctl[0:1] and ones on D[0:n]. The PHY indicates the start of a packet by placing the speed code (encoding shown in Table 17-21) on D[0:n], followed by the contents of the packet. The PHY holds Ctl[0:1] in Receive until the last symbol of the packet has been transferred. The PHY indicates the end of the packet by asserting Idle on Ctl[0:1]. Note that signaling the speed code is a PHY/link protocol and not a data symbol to be included in the calculation of the CRC. It is possible that a PHY can see data prefix appear and then disappear on a serial bus without seeing a packet. This is the case when a packet of a higher speed than the PHY can receive is being transmitted. In this case, the PHY ends the packet by asserting Idle when data prefix goes away. If the PHY is capable of a higher data rate than the link, the link detects the speed code as such and ignores the packet until it sees the Idle state again. The timing for the receive operation is shown in Figure 17-11. In the diagram, SP refers to the speed code and D0 through Dn are the data symbols of the packet.
Phy Ctl[0:1] (binary)
00
10
10
10
10
10
10
00
00
Phy D[0:7](hex)
00
FF
FF
SP
D0
D1
Dn
00
00
Figure 17-11—Receive timing The speed code for the receive operation is defined as shown in Table 17-21. This is also the same speed encoding used by the link to signal speed to the PHY during concatenated packet transmission. NOTE—The speed code is only applicable for cable applications. For backplane applications, the speed code is set to 00xxxxxx2.
17.2.8 Electrical characteristics (cable environment) This subclause specifies the signal and timing characteristics of the interface between a discrete PHY and a link.
17.2.8.1 DC signal levels and waveforms DC parametric attributes of the Alpha PHY/link interface signals are specified by Table 17-22. Input levels may be greater than the power supply level (e.g., a 5 V output driving the undifferentiated output high voltage [VOH] into a 3.3 V input); tolerance of mismatched input levels is optional. Devices not tolerant of mismatched input levels, but that otherwise meet the requirements in Table 17-22, are compliant with this standard. VDD is obtained from the vendor’s specifications.
Copyright © 2008 IEEE. All rights reserved.
479
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-22—DC specifications for the Alpha PHY-link interface Name
Description
Conditions
Unit
Minimum
Maximum
VOH
Output high voltage (undifferentiated)
IOH = –4 mA
V
2.8
—
VOHD
Output high voltage (differentiated)
IOH = –9 mA at VDD = 3 V IOH = –11 mA at VDD = 4.5 V
V
VDD – 0.4
—
VOL
Output low voltage (undifferentiated)
IOL = 4 mA
V
—
0.4
VOLD
Output low voltage (differentiated)
IOL = 9 mA at VDD = 3 V IOL = 11 mA at VDD = 4.5 V
V
—
0.4
VIH
Input high voltage (undifferentiated)
—
V
2.6
VDDa+10
VIL
Input low voltage (undifferentiated)
—
V
—
0.7
VLIT+
Input rising threshold (LinkOn and LPS)
—
V
—
VLREF + 1b
VLIT–
Input falling threshold (LinkOn and LPS)
—
V
VLREF + 0.2b
—
VIT+
Hysteresis input rising threshold (differentiated)c
—
V
VREF + 0.3
VREF + 0.9d
VIT–
Hysteresis input falling threshold (differentiated)c
—
V
VREF – 0.9c
VREF – 0.3
VREF
Reference voltagee
—
V
VLRE
Reference voltagef (LinkOn and LPS inputs)
—
V
0.5
1.6
Input capacitance
—
pF
—
7.5
F
CIN
%
(VDD/2) ± 1%
aRefers
to driving device’s power supply. LinkOn and LPS receiver parameters are based on a swing of 2.4 V for the received signal. Links that only depend on receiving the initial edge of LinkOn may be capable of operating with less constrained values. cWhen the PHY-link interface is in differentiated mode, the SClk input shall meet the V IT+ and VITrequirements. dWhen designing a device capable of both undifferentiated and differentiated operation, V IH and VIL effectively constrain these VIT+ and VIT- values to VREF + 0.8 V and VREF – 0.8 V, respectively. bThe
eFor
some applications, a device can be compliant with these dc specifications even if a different VREF is chosen. fFor a particular application, there is a single value for each device’s nominal bias point, V LREF, that shall be within the range specified. VLREF should be chosen in conjunction with the receiver parameters so that a loss of power by the transmitting device is perceived as zero by the receiving device.
480
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.2.8.2 AC timing The rise and fall time measurement definitions, tR and tF, for SClk, Ctl[0:1], D[0:n], and LReq are shown in Figure 17-12.
90%
90%
10%
10% tR
tF Figure 17-12—Signal levels for rise and fall times
Other signal characteristics of the Alpha PHY/link interface are specified by Table 17-23. If an isolation barrier is implemented it shall cause neither delay nor skew in excess of the values specified. AC measurements shall be taken from the 1.575 V level of SClk to the input or output Ctl[0:1], D[0:n], or LReq levels and shall assume an output load of 10 pF.
Table 17-23—AC timing parameters for the Alpha PHY-link interface Na me
Description
Unit
Minimum
Maximum
SClk frequency
MHz
SClk duty cycle
%
45
55
tR
Rise time
ns
0.7
2.4
tF
Fall time
ns
0.7
2.4
Delay through isolation barrier
ns
0
2
Skew through isolation barrier
ns
0
0.5
Isolation barrier recovery time
µs
0
10
idel
49.152 ± 100 ppm
Figure 17-13 and Figure 17-14 illustrate the transfer waveforms as observed at the PHY. A PHY shall implement values for tpd1, tpd2, and tpd3 within the limits specified in Table 17-24 and shall not depend upon values for tpsu and tph greater than the minimums specified.
SClk D[0:n] Ctl[0:1]
tpd1
tpd2
tpd3
Figure 17-13—PHY to link transfer waveform at the PHY
Copyright © 2008 IEEE. All rights reserved.
481
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
SClk
tpsu
tph
D[0:n] Ctl[0:1] LReq Figure 17-14—Link to PHY transfer waveform at the PHY The values for the timing parameters illustrated in Figure 17-13 and Figure 17-14 are specified in Table 17-24.
Table 17-24—AC timing parameters at the PHY Name
Description
Unit
Minimum
Maximum
tpd1
Delay time, SClk input high to initial instance of D[0:n] and Ctl[0:1] outputs valid
ns
0.5
13.5
tpd2
Delay time, SClk input high to subsequent instance(s) of D[0:n] and Ctl[0:1] outputs valid
ns
0.5
13.5
tpd3
Delay time, SClk input high to D[0:n]] and Ctl[0:1] invalid (high-impedance)
ns
0.5
13.5
tpsu
Setup time D[0:n], Ctl[0:1] and LReq inputs before SClk
ns
6
—
Hold time
ns
0
—
tph
D[0:n], Ctl[0:1] and LReq inputs after SClk
Figure 17-15 and Figure 17-16 illustrate the transfer waveforms as observed at the link. A link shall implement values for tld1, tld2, and tld3 within the limits specified in Table 17-25 and shall not depend upon values for tlsu and tlh greater than the minimums specified.
SClk
tlsu
tlh
D[0:n] Ctl[0:1] Figure 17-15—PHY to link transfer waveform at the link
SClk D[0:n] Ctl[0:1] LReq
tld1
tld2
tld3
Figure 17-16—Link to PHY transfer waveform at the link
482
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The values for the timing parameters illustrated in Figure 17-15 and Figure 17-16 are specified in Table 17-25.
Table 17-25—AC timing parameters at the link Name
Description
Unit
Minimum
Maximum
tld1
Delay time, SClk input high to initial instance of D[0:n], Ctl[0:1], and LReq outputs valid
ns
1
10
tld2
Delay time, SClk input high to subsequent instance(s) of D[0:n], Ctl[0:1], and LReq outputs valid
ns
1
10
tld3
Delay time, SClk input high to D[0:n], Ctl[0:1], and LReq invalid (high-impedance)
ns
1
10
tlsu
Setup time, D[0:n] and Ctl[0:1] inputs before SClk
ns
6
—
tlh
Hold time, D[0:n] and Ctl[0:1] inputs after SClk
ns
0
—
17.2.8.3 AC timing The protocol of this interface is designed so that all inputs and outputs at this interface can be registered immediately before or after the I/O pad and buffer. No state transitions need be made that depend directly on the chip inputs; chip outputs can come directly from registers without combinational delay or additional loading. This configuration provides generous margins on setup and hold time. In the direction from the PHY to the link, timing follows normal source-clocked signal conventions. A 0.5 ns allowance is made for skew through an (optional) isolation barrier. In the direction from the link to the PHY, the data are timed at the PHY in reference to SClk, whose frequency allows a nominal budget of 20 ns for delay, inclusive of the PHY input setup time. Possible sources of delay are an isolation barrier or internal SClk delay at the link caused by a clock tree. Figure 1717 illustrates the relationship among these delays. Note that the maximum round-trip delay of 14 ns (calculated as tdrt1max = idelmax + tld1max + idelmax) provides generous delays for both the link and the PHY. The link, after the receipt of SClk, has 10 ns to assert valid data, while at the PHY, the minimum input setup for the subsequent SClk cycle is 6 ns (calculated as tpsumin = 20 ns – tdrt1max). Also note that the minimum round-trip delay until the next change in data of 21 ns (calculated as tdrt2min = 20 ns + idelmin + tld2min + idelmin) limits the hold time at the PHY to 1 ns (calculated as tphmin = tdrt2min – 20 ns); the hold time is further reduced to zero to provide a guard band of 1 ns. The values for the delays illustrated in Figure 17-17 are given in Table 17-26.
Copyright © 2008 IEEE. All rights reserved.
483
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
20 ns SClk out from PHY idel SClk in to link tld1
tld2
C, D, LReq out from link idel
idel tdrt1
tdrt2 tph
tpsu C, D, LReq in to PHY
Figure 17-17—Alpha link to PHY delay timing Table 17-26—Alpha link to PHY delay timing parameters Name
Description
Unit
Minimum
Maximum
tdrt1
Round-trip delay from SClk output at the PHY to valid Ctl[0:1], D:[0:7] and LReq at the PHY
ns
1
14
tdrt2
Round-trip delay from SClk output at the PHY to changed or invalid Ctl[0:1], D:[0:7] and LReq at the PHY
ns
21
34
17.3 Beta (B) and Beta Plus (B Plus) PHY-link interface specification The Beta PHY-link interface provides mechanisms to support communication between a discrete PHY and link at speeds of S100, S200, S400, and S800 with a data path that is 8 bits wide. Implementation of the PHY-link interface at speeds up to S3200 may be achieved using a 16-bit parallel interface. The Beta Plus PHY-link interface provides mechanisms to support communication between a discrete PHY and link at speeds of S100, S200, S400, S800, S1600, and S3200. For S1600 and below, the
484
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
width of the data path is 8 bits, while for S3200, the data path is 16 bits. Transfer speeds lower than S1600 are accommodated by data padding and repetition. This standard does not preclude implementation of PHYs that are capable of supporting links compliant with Beta and Beta Plus links specified in this subclause and the A link specified in 17.2. When attached to a link that provides Level A functionality, the PHY shall follow specifications of 17.2. When attached to a link that provides Level B functionality, the PHY shall follow the Beta Link specification in this subclause. When attached to a link compliant with the Beta Plus Link, the PHY shall follow the Beta Plus Link specifications contained in this subclause.
17.3.1 Beta (B) and Beta Plus (B Plus) PHY-link interface characteristics The following are the characteristics of the Beta and Beta Plus PHY-link interface: a)
Provides for bidirectional packet data transfer at speeds of S100, S200, S400, and S800;
b)
Provides for bidirectional packet data transfer at speeds of S1600 and S3200 (Beta Plus only).
c)
Provides a mechanism for status information transfer from the PHY to the link;
d)
Provides a mechanism for the link to access a register space within the PHY;
e)
Provides a means for the link to request services from the PHY; and
f)
Provides a means for the PHY to interrupt the link during an operation.
17.3.2 PHY-link interface signals The signals used for the PHY-link interface and connection between the PHY and link are shown in Figure 17-18. The signals of the Beta and Beta Plus PHY-link interface are divided into mandatory and optional signals for the PHY and link.
17.3.2.1 PHY signals For both Beta and Beta Plus interfaces, the following signals are mandatory for a PHY: D[0:7], PInt, LReq, Ctl[0:1], PClk, LClk, LinkOn, and LPS. For both Beta and Beta Plus interfaces, the following signals are optional for a PHY: Direct and Beta_Mode_link. For a Beta Plus interface, the following signals are also optional for a PHY: Beta_Plus_link, D[8:15], and DATA_HIGH_VALID. The propagation delay for the signals from the PHY to the link shall be less than 1.5 ns including any delays caused by isolation barriers.
17.3.2.2 Link signals For both Beta and Beta Plus interfaces, the following signals are mandatory for a Link: D[0:7], PInt, LReq, Ctl[0:1], PClk, and LClk. For both Beta and Beta Plus interfaces, the following signals are optional for a Link: Link_On, LPS, andDirect. For a Beta Plus interface, the following signals are also optional for a Link: D[8:15] and DATA_HIGH_VALID. The propagation delay for the signals from the link to the PHY shall be less than 1.5 ns including any delays caused by isolation barriers.
Copyright © 2008 IEEE. All rights reserved.
485
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Beta Plus PHY D[0:7] (B Plus only) D[8:15]
Beta Plus Link 8 8
DATA_HIGH_VALID (B Plus only)
D[8:15] (B Plus only) DATA_HIGH_VALID (B Plus only) PInt LReq
PInt LReq Ctl[0:1]
D[0:7]
2
PClk
Ctl[0:1] PClk LClk
LClk LinkOn LPS
LinkOn LPS
Direct
Direct
Beta_Mode_link Beta_Plus_link (B Plus only) NOTES 1—This diagram indicates the logical signalling required between the PHY and link and does not imply a dc connection between the two devices. 2—The Beta Link is the same as above except that it does not include the D[8:15], DATA_HIGH_VALID, and Beta_Plus_link signals.
Figure 17-18—Beta and Beta Plus PHY-link interface logical signalling
17.3.2.3 PHY-Link signal descriptions Table 17-27 summarizes the PHY-link interface signals.
Table 17-27— Beta and Beta Plus PHY-link interface signal descriptions Signal name
Direction
Required
Description
D[0:7]
Bidirectional
Mandatory
PHY-link interface data bus. 8-bit data bus for a Beta PHY and link.
D[8:15]
Bidirectional
Optional
Second 8-bit data bus for a 16-bit Beta Plus PHY and link at S3200.
DATA_VALID_HIG H
Bidirectional
Optional
Valid indication for second 8-bit data bus for a 16-bit Beta Plus PHY and link at S3200.
PInt
PHY drives
Mandatory
PHY interrupt. PHY-to-link interrupt and status indication.
486
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-27— Beta and Beta Plus PHY-link interface signal descriptions (continued) Signal name
Direction
Required
Description
LReq
Link drives
Mandatory
Link request. Link-to-PHY request; see 17.3.5.
Ctl[0:1]
Bidirectional
Mandatory
PHY-link control bus. 2-bit control bus for a Beta PHY or link.
PClk
PHY drives
Mandatory
PHY sourced clock. PHY-to-link interface clock.
LClk
Link drives
Mandatory
Link sourced clock. Link-to-PHY interface clock.
LinkOn
PHY drives
PHY-Mandatory Link-Optional
Link on; see 17.3.4.
LPS
Link drives
PHY-Mandatory Link-Optional
Link power status; see 17.3.3.
Direct
Externally driven
Optional
Direct. External indication of the interface mode between PHY and link.
Beta_Mode_link
Externally driven
Optional
Beta link interface mode indication.
Beta_Plus_link
Externally driven
Optional
Beta_Plus interface mode indication
17.3.2.4 Detailed signal descriptions Detailed descriptions of the interface signals are as follows: a)
D[0:7]. The bidirectional data bus is used to carry IEEE 1394 packet data, packet speed, and grant type information between the PHY and the link. Upon a reset of the interface, this bus is driven by the PHY. When driven by the PHY, data on this bus is synchronous to PClk. When driven by the link, data on this bus is synchronous to LClk.
b)
D[8:15] The second 8-bit bidirectional data bus of the 16-bit Beta Plus PHY and link device supporting transfers up to S3200. This second 8-bit bidirectional data bus is not provided unless the Beta Plus device supports S3200. Upon a reset of the interface, this bus is driven by the PHY. When driven by the PHY, data on this bus is synchronous to PClk. When driven by the link, data on this bus is synchronous to LClk
c)
DATA_HIGH_VALID. When the Beta Plus interface is operating at S3200, the DATA_HIGH_VALID signal shall be asserted when D[8:15] contain valid data and shall be deasserted when D[8:15] do not contain valid data. For single-byte transfers at S3200, this signal shall be deasserted.
d)
PInt. The PHY interrupt signal is always driven by the PHY. The serial information on this signal is used by the PHY to transfer status, register, interrupt, and other information to the link. The data on this signal is synchronous to PClk.
e)
LReq. The link request signal is always driven by the link. The serial information on this signal is used by the link to request packet transmission, to read from and write to PHY registers, and to indicate the occurrence of certain link events that are relevant to the PHY. The data on this signal is synchronous to LClk.
f)
Ctl[0:1]. The bidirectional control bus is used to indicate the phase of operation of the interface. Upon a reset of the interface, this bus is driven by the PHY. When driven by the PHY, information on this bus is synchronous to PClk. When driven by the link, information on this bus is synchronous to LClk.
Copyright © 2008 IEEE. All rights reserved.
487
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
g)
PClk. The PHY clock signal is an output from the PHY. When drive, this signal shall have a nominal 50% duty cycle and a nominal frequency of 98.304 MHz clock for the Beta interface and 196.608 MHz for the Beta Plus interface. The PHY shall be an original provider of this interface source clock, i.e., the PHY shall not derive its PClk signal from the incoming LClk signal. Where the PHY and the link are powered independently, the link implementation should detect the loss of PClk.
h)
LClk. The link clock signal is an output from the link. The link shall derive its LClk from the incoming PClk signal. In this way, PClk and LClk are frequency-locked.
i)
LinkOn. The link-on event notification signal is an output from the PHY. This signal is used to provide notification to a link of a received link-on PHY packet.
j)
LPS. The LPS notification signal is an output from the link. When this signal is active, it indicates that the link is powered and that the link is capable of maintaining communications over the PHYlink interface. When this signal is inactive, it indicates that the link is not powered or that no link is present.
k)
Direct. The direct connection notification signal pin is present on a PHY or a link if it supports the differentiated interface. When present, it is set high to disable the differentiator outputs for the Ctl[0:1], D[0:n], LReq, and PInt signals.
l)
Beta_Mode_link. If the Beta_mode_link indication is not provided or if it is provided and asserted, the PHY-link interface complies with the Beta specification of this subclause. When the PHY-link mode indication is provided but deasserted, the PHY-link interface complies with the Alpha PHYlink interface specification (see 17.2.)
m)
Beta_Plus_link. This signal, in combination with the Beta_Mode_link signal, shall control the operating mode of the PHY-link interface, as shown in Table 17-28.
Table 17-28— Beta Plus PHY-link interface operating modes
State of Beta_Mode_link
State of Beta_Plus_link Low
Not present
High
Low
A
Not allowed for Beta Plus device
Beta Plus
Not present
Beta
Beta Plus
Beta Plus
High
Beta
Not allowed for Beta Plus device
Beta Plus
17.3.2.5 Differentiated signals The Direct input controls digital differentiators on the D[0:n], Ctl[0:1], PInt, and LReq signals. When set high, it shall disable differentiator outputs on these signals (which shall be otherwise enabled). If the link does not implement Direct, the link shall be configured so that output on these signals, differentiated or not, conforms to the value of Direct provided to the PHY. NOTE—Differentiators may be required when the PHY and link are connected through an optional isolation barrier. A digital differentiator drives its output signal for one clock period when the input signal changes, but places the output signal in a high-impedance state so long as the input signal remains constant. Figure 17-19 illustrates this signal transformation.
488
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Input
Output
0
1
1
0
0
0
1
0
0
0
1
Z
0
Z
Z
1
0
Z
Figure 17-19—Digital differentiator signal transformation
17.3.3 Interface initialization, reset, and disable LPS is used to indicate the powered status of the link to the PHY and is also used to indicate that the PHY is to reset, disable, or enable the PHY-link interface. When the interface is not differentiated, then LPS may be driven high while logically asserted. LPS should be pulsed when logically asserted, and it shall be pulsed when the interface is differentiated. When logically deasserted, LPS shall be driven low in either interface mode.
17.3.3.1 LPS signal characteristics The characteristics of LPS are specified by Figure 17-20, Table 17-29, and Table 17-30.
LPS
TLPSH
TLPSL
Figure 17-20—LPS waveform when differentiated Table 17-29—Timing parameters specified in terms of absolute time Parameter
Description
Minimum
Maximum
Units
TLPSL
LPS low time (when pulsed)
0.09
1.00
μs
TLPSH
LPS high time (when pulsed)
0.09
1.00
μs
Duty cycle (when pulsed)
20
60
%
Time for PHY to recognize LPS logically deasserted and reset the interface
1.2
2.75
μs
TLPS_RESET
Copyright © 2008 IEEE. All rights reserved.
489
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-29—Timing parameters specified in terms of absolute time (continued) Parameter
a
Description
Minimum
Maximum
Units
TLPS_DISABLE
Time for PHY to recognize LPS logically deasserted and disable the interface
25
30
μs
TRESTORE
Time to permit the optional differentiator and isolation circuits to restore during an interface reset
15
20a
μs
This maximum does not apply when the PHY-link interface is disabled (see Figure 17-22), in which case an indefinite time may elapse before LPS is reasserted. Otherwise, to reset, but not disable, the interface, the link shall ensure that LPS is logically deasserted for less than TLPS_DISABLE.
Table 17-30—Timing parameters specified in terms of number of PClk or LClk Device
Description
PHY
Drive Ctl[0:1], D[0:7] (and D[8:15], see note a), and PInt to zero for the first seven cycles of PClk after the reference point
link
For one and only one of the first six cycles of PClk after the reference point, drive Ctl[0:1] and D[0:7] (and D[8:15], note a) to zero; prior to this place them in a high-impedance state. Once these signals have been driven low, return them to a high-impedance state until after the reset completes.
NOTE—In case that D[8:15] is present for a PHY or Link device that supports the operation speed up to S3200 mode, the behavior of D[8:15] will be exactly same as D[0:7].
17.3.3.2 Interface reset The link requests the PHY to reset the interface by deasserting LPS. Within 1.0 μs after deasserting LPS, the link shall place Ctl[0:1] and D[0:7] in a high-impedance state and condition LReq according to the interface mode. (If undifferentiated, LReq shall be driven low; otherwise, it shall be placed in a high-impedance state.) If the PHY observes LPS logically deasserted for TLPS_RESET, it shall first complete any PHY status transfers or notifications (see 17.3.8.2) in progress and then reset the PHY-link interface. The signal levels shown in Figure 17-21 for Ctl[0:1], D[0:7], PInt, and LReq while LPS is logically deasserted are shown for an undifferentiated interface, but the timing relationships remain accurate for both interface modes. When the interface is undifferentiated, the PHY drives Ctl[0:1], D[0:7], and PInt to zero. Otherwise, the PHY places the Ctl[0:1], D[0:7], and PInt signals in a high-impedance state. During an interface reset, the PHY continues to provide PClk and the link continues to provide LClk. When the PHY-link interface is reset, the PHY shall cancel any outstanding bus or register read requests. Although the cancellation of bus requests may affect PHY arbitration status in ways not described in other parts of this standard, the PHY’s behavior (as observable from a serial bus) shall be consistent with those subclauses. For example, the PHY may have initiated arbitration in response to a bus request, but reset of the PHY-link interface might cancel the request before it is granted. If the PHY receives a grant when no data transfer link request is pending, appropriate PHY behavior is the transmission of a null packet.
490
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Ctl D, PInt, LReq LPS (non-pulsed) LPS (pulsed) PClk/ LClk TLPS_RESET
TRESTORE
Figure 17-21—Beta and Beta Plus PHY-link interface reset This standard describes the PHY’s operation as if the interface to the link is always operational. If the PHYlink interface is reset while the link is transmitting a packet, the PHY shall behave as if the link had signaled IDLE and terminated the packet. Similarly, any status bit information generated by the PHY while the interface is not operational (whether reset, disabled, or in the process of initialization) shall be zeroed and shall not cause a status transfer upon restoration of the interface.
17.3.3.3 Interface disable If the link continuously deasserts LPS for a longer period, it requests the PHY not only to reset but also to disable the PHY-link interface. The link shall condition its outputs as described for reset in 17.3.3.2. If the PHY observes LPS logically deasserted for TLPS_DISABLE, it shall disable the interface. The PHY will have already reset the interface as described in 17.3.3.2; it now disables the interface by stopping PClk. The signal levels shown in Figure 17-22 for Ctl[0:1], D[0:7], PInt, LReq, and PClk while LPS is logically deasserted are shown for an undifferentiated interface, but the timing relationships remain accurate for both modes. When the interface is undifferentiated, the PHY disables the interface by driving PClk to zero while continuing to drive Ctl[0:1], D[0:7], and PInt to zero. Otherwise, the PHY disables the interface by placing PClk in a high-impedance state while continuing to maintain the Ctl[0:1], D[0:7], and PInt signals in a highimpedance state. NOTE—When the PHY-link interface is disabled and none of the PHY’s ports is active or in a transitional state, the PHY may place most of its circuitry in a low-power state.
Ctl D, PInt, LReq LPS LPS (pulsed) PClk/ LClk TLPS_DISABLE
TRESTORE
Figure 17-22—Beta and Beta Plus PHY-link interface disable
Copyright © 2008 IEEE. All rights reserved.
491
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
17.3.3.4 Restoration and initialization The handshake described in 17.3.3.3 either resets, or resets and then disables, the interface when the link deasserts LPS for a minimum of TLPS_RESET(max) or TLPS_DISABLE(max) , respectively. In either case (or after power reset), normal operations may be restored if the link asserts LPS. After observing LPS, if PClk is not already provided, the PHY shall resume PClk as soon as possible, but no earlier then 10 μs since the PHY’s most recent power reset. If the PHY-link interface is differentiated and PClk is resumed, the PHY shall commence by driving PClk low for a minimum of 2.5 ns. In either mode, the PHY shall ensure that clock duty cycle and period requirements are met from the first rising edge of PClk onward. Once PClk is available, the PHY and link shall condition their Ctl[0:1] and D[0:7] outputs in accordance with Table 17-31. The reference point is one of the first four rising edges of PClk after LPS is asserted.
Table 17-31—Initialization of the Beta and Beta Plus PHY-link interface Interface mode Device Differentiated
Undifferentiated
PHY
For one and only one of the first six cycles of PClk after the reference point, drive Ctl[0:1], D[0:7], and PInt to zero. Otherwise, place signals in a high-impedance state for these and subsequent cycles until Receive is asserted by the PHY.
Drive Ctl[0:1], D[0:7], and PInt to zero for the first seven cycles of PClk after the reference point, and for subsequent cycles until Receive is asserted by the PHY.
link
For one and only one of the first six cycles of PClk after the reference point, drive Ctl[0:1], D[0:7], and LReq to zero. Otherwise, place signals in a high-impedance state.
For one and only one of the first six cycles of PClk after the reference point, drive Ctl[0:1] and D[0:7] to zero; prior to this place them in a highimpedance state. Once these signals have been driven low, return them to a high-impedance state until after the reset completes. LReq shall be driven low once the operating mode of the interface is determined and shall continue to be driven low until the first PHY Status Transfer (see 17.3.8.2) is received.
The PHY may not be able to determine its operating mode (i.e., differentiated or undifferentiated), immediately after a power reset. While the operating mode is indeterminate, the PHY shall place its outputs in a high-impedance state. Within 5 μs after LPS is asserted, the PHY shall assert RECEIVE on Ctl[0:1] while simultaneously providing DATA_ON indication on D[0:7] for at least one PClk cycle. On a subsequent PClk cycle, the PHY shall continue with the initialization completion sequence defined in 17.3.3.5. The link may not issue any LReq until the first PHY Status Transfer is received. The PHY shall ensure that no more than 10 ms elapses from the reassertion of LPS until the first DATA_ON indication is sent by the PHY.
17.3.3.5 Initialization completion sequence The following sequence of events occurs when the PHY-link interface comes up or is reset or when a nephew PHY brings a port out of the Standby state. The conditions and events of the completion sequence are as follows:
492
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
a)
No packet transfer requests to the PHY shall be outstanding; and if the interface is being initialized or reset, no outstanding register transfer requests shall be pending in the PHY.
b)
The PHY shall send a PH_RESTORE_RESET PHY Status Transfer if needed to properly indicate the reset status; and if the PH_RESTORE_RESET is not sent, the PHY may send a PH_RESTORE_NO_RESET.
c)
The PHY shall notify the link of its node_ID by sending an unsolicited PHY register 0 PHY Status Transfer.
d)
The PHY shall establish the fairness interval phase by issuing a Bus Status Transfer indicating PH_ARB_RESET_ EVEN or PH_ARB_RESET_ODD.
The link may assume no fixed timing relationship between the status transfers on the PInt line and the Bus Status Transfers on the data bus. After the PHY sends the PH_ARB_RESET_*, it may send additional Bus Status Transfers, IDLE, or DATA_ON. If the first DATA_ON following a Bus Status Transfer occurs while the PHY is in the middle of a data packet transfer (i.e., any of the packet start symbols has been received, but no data ending symbols have been received), the PHY shall continue to send DATA_ON until the end of the packet. When the initialization completion sequence is started, the PHY shall not queue any packet transfer requests other than Cycle Start until the PHY has sent the last bit of the unsolicited PHY register 0 status transfer; and the link shall make no packet transfer requests other than Cycle Start requests until the link has received the last bit of the unsolicited register 0. The PHY shall be able to accept and queue any transfer request that starts after the last bit of the PHY register 0 PHY Status Transfer has been sent. After the initialization completion sequence is started, the link shall not issue an isochronous request until a cycle start packet is either observed or generated by the link. The PHY shall not grant a cycle start unless the node is root.
17.3.4 LinkOn signal characteristics The LinkOn signal provides a method for the PHY to signal or interrupt the link at times when the PHY-link interface is not operational. The PHY-link interface is not operational when the LPS signal is logically deasserted (see 17.3.3). The characteristics of the LinkOn signal, specified by Figure 17-23 and Table 17-32, permit the link to detect LinkOn in the absence of PClk and also permit the signal to cross an optional isolation barrier. When LinkOn is logically deasserted, it shall be driven low.
LinkOn
Figure 17-23—LinkOn waveform When necessary to communicate a PH_EVENT.indication of PH_LINK_ON or one of the PHY interrupt conditions (see Table 17-48), the PHY shall assert LinkOn if LPS is logically deasserted and may assert LinkOn if the PHY register LCtrl bit is zero. NOTE—While the PHY-link interface is operational, all link-on packets are transferred to the link. When the phy_ID field matches the PHY’s physical_ID, this transfer is an implicit PH_EVENT.indication of PH_LINK_ON; the PHY need not assert LinkOn in this case.
Copyright © 2008 IEEE. All rights reserved.
493
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-32—LinkOn timing parameters Description
Minimum
Maximum
Units
Frequency
4
8
MHz
Duty cycle
30
60
%
Persistence time, measured from the point at which both LPS is active and LCtrl is one, after which the PHY shall not signal LinkOn
—
500
ns
Once asserted, the LinkOn signal shall persist so long as the LPS signal is logically deasserted and may persist so long as the PHY register LCtrl bit is zero or until a bus reset clears the LinkOn. A bus reset shall cause LinkOn to be deasserted unless —
The PHY register Port_event bit is one or
—
The PHY register Watchdog bit is one and a loop, power failure, or timeout condition exists (i.e., conditions indicated by the Loop, Pwr_fail, and Timeout fields in the PHY register map).
When the PHY power cycles, the PHY shall check its power class and assert LinkOn if the power class is 0 through 4 inclusive. This LinkOn due to power-on shall be asserted until the first of the following events occurs: —
A minimum of 16 384 PClk intervals (maximum is implementation-dependent) has occurred, or
—
Both LPS is active and LCTRL is one (the parameter Persistence_time applies).
17.3.5 Link requests and notifications The link uses LReq or the data bus (i.e., D[0:7]) to issue requests to the PHY to gain control of the interface and send packets. The link also uses LReq to issue requests to read data from or write data to the PHY registers. The types of requests sent from the link to the PHY are summarized in Table 17-33.
Table 17-33—Link request types to PHY Request type
Service
Asynchronous
Request an asynchronous packet transmit other than cycle start and immediate
Cycle Start
Request a cycle start packet transmit
Immediate
Request an immediate packet transmit
Isochronous
Request an isochronous packet transmit
Register Access
Request PHY register read and/or write operations
The link issues notifications to the PHY to inform it of link events that are relevant to its operation: a)
The link has received a cycle start packet along with an indication of the isochronous phase of the link.
b)
A cycle start packet is now expected.
For packet transmit requests (i.e., Asynchronous, Isochronous, Cycle Start, and Immediate), the PHY shall arbitrate for control of the bus and, when it gains control, the PHY shall use the PHY-link data bus to send a
494
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
GRANT to the link to indicate the type of request that is being granted. For a Register Access read request, the PHY shall return the requested data on PInt.
17.3.5.1 Link request characteristics The PHY is required to queue one of each type of request at one time. The PHY shall not maintain a queue deeper than one entry for each request type. Thus, only a single access of each type may be pending within the PHY at any point in time. For Asynchronous or Isochronous packet transmit requests, the link is expected to pipeline requests for the next fairness interval or cycle, respectively. If an additional request is sent to the PHY when one of the same type is already queued in the PHY, then the new request shall cause the previous request to be cancelled. Because GRANT is sent from the PHY to the link over the data bus (D[0:7]), reception of a GRANT by the link is not synchronized to the transmission of requests from the link. This may cause a race condition to exist in which the GRANT from the PHY may be for a previously or just queued request. Because of this ambiguity, the link shall use the speed and packet format information in the GRANT to determine which request is being granted. If the speed and format of the GRANT matches two requests, then the link shall use the GRANT for the higher priority request. The PHY is allowed to change a request for which the link specifies no format into a Beta request if the PHY knows that the packet will travel only over Beta connections. The PHY may determine this by noting that the speed of the request is faster than the maximum Alpha path speed (determined during self-identify phase of the bus). If the PHY does upgrade the request, it shall remember that the format of the original request was unspecified and return this indication in the GRANT so that the link may use this information to help resolve any ambiguity in the GRANT. If a GRANT is given to the link for any type of packet transfer request, no requests of the same type shall be queued in the PHY until the end of the packet transmission by the link. At the end of the packet, the link has the opportunity of immediately queuing another request, including one of the same type, by using the MORE_INFO cycle (see 17.3.6.3.5). Until the first cycle in which the link releases the data bus, the PHY shall not queue a request that is received on LReq if that request is the same as the current GRANT type. For example, if the link is transmitting an asynchronous data packet, the PHY shall not queue an Asynchronous packet transmit request sent over LReq if that LReq is sent during the asynchronous data packet transmission. The PHY shall not check the request type until the stop bit is received at the end of the LReq. When the PHY-link interface is reset, or initialized, or when the PHY sends a Bus Status Transfer indicating that a serial bus reset has occurred, all pending transfer requests are cancelled in the PHY. The PHY also cancels all requests when a PH_RESTORE_NO_RESET is sent to indicate that a restore process has started on a PHY port. For all of these events, the PHY shall not queue any transfer request from the link except for Cycle Start packet transmit requests until the PHY has completed the operation and sent an unsolicited register 0 status transfer to the link.
17.3.5.1.1 Asynchronous packet transmit requests The link issues an Asynchronous packet transmit request to transmit any asynchronous primary packet or PHY packet. The link uses the request format described in 17.3.5.3 to issue an Asynchronous packet transmit request. Both links and PHYs observe the current fairness interval phase, either odd or even. The fairness interval phase is used to allow the link to pipeline Asynchronous packet transmit requests to the PHY. If the current fairness interval phase is even, the link may issue a CURRENT or NEXT_ODD Asynchronous packet transmit request. Similarly, if the current fairness interval phase is odd, the link may issue either a CURRENT or NEXT_EVEN.
Copyright © 2008 IEEE. All rights reserved.
495
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The link may issue a NEXT_EVEN request on or about the time that the bus phase changes from odd to even. In this case, the PHY shall interpret the request as a CURRENT request. Behavior for NEXT_ODD request is similar. However, if the link issues a NEXT_EVEN or NEXT_ODD request when the link is in the even or odd phase, respectively, the phase may change as the request is being sent to the PHY. This timing will prevent the PHY from converting the request to CURRENT, and the request will not be serviced until the next time the bus enters the respective even or odd phase. For this reason the link should use CURRENT request to issue an even request in the even phase or an odd request during the odd phase rather than by issuing NEXT_EVEN requests in the even phase and NEXT_ODD requests in the odd phase. The PHY provides notification of a fairness interval phase change via the appropriate Arbitration Reset Bus Status Transfer (see Table 17-47). Upon receipt of this status transfer, the link updates its awareness of the current fairness interval phase. The link may have only one Asynchronous packet transmit request pending in the PHY at any time. If a new Asynchronous packet transmit request is issued by the link, it shall take precedence over the previous request. In this way, if a link has issued a request for the next fairness interval (either even or odd) and then determines that it has an additional Asynchronous packet transmit request that may be issued within the current fairness interval, it may issue a new Asynchronous packet transmit request for the current phase. This new current request cancels the request for the next fairness interval, which can be reissued by the link if appropriate. The link may issue a NEXT_EVEN or NEXT_ODD request and, before a matching GRANT is received, subsequently issue a CURRENT request. In such cases, if the asynchronous GRANT, when received, matches the speed and format of the CURRENT request, the link shall use the GRANT for the packet associated with the CURRENT request even if the GRANT also matches the speed and format of the NEXT_* request. The link may then reissue the request associated with the previous NEXT_* request in the MORE_INFO cycle at the end of the packet transmission.
17.3.5.1.2 Cycle Start packet transmit requests The link issues a Cycle Start packet transmit request (i.e., PH_CYC_START_REQ) to transmit a cycle start primary packet. The link uses the request format described in 17.3.5.3 to issue a PH_CYC_START_REQ request. The PHY shall not grant this request if the node is not root. The request may remain pending in the PHY until the next bus reset.
17.3.5.1.3 Immediate packet transmit requests The link issues an Immediate packet transmit request (i.e., PH_IMMED_REQ) to transmit a packet without waiting for the normal arbitration process. This request type is normally used by the link to transmit an acknowledge packet in response to a received packet that was addressed to this node. The link shall start sending the PH_IMMED_REQ to the PHY within 8 LClk cycles after it receives the first quadlet of an asynchronous packet that is addressed to the node or immediately after completing any LReq that may be in progress at that time. If a subsequent header cyclic redundancy code (CRC) error is detected, the link shall not drive the D[0:7] lines when the PHY grants the link for the immediate request. After several cycles of inactivity, the PHY will regain control of the interface. To avoid excessive delays in sending the PH_IMMED_REQ to the PHY, the link shall not start any request other than a PH_IMMED_REQ after receiving the packet format byte of a received packet. After determining that a PH_IMMED_ REQ is not needed or after it is sent, then other LReq requests are allowed. The link is not allowed to send an acknowledge if the immediately preceding packet on the bus is not an asynchronous packet addressed to the node. In some error conditions the PHY may grant the link’s immediate request when the link is not allowed to send an acknowledge. This condition may occur when the
496
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
node receives a packet with a CRC error in the header or if another node erroneously concatenates a packet to the primary packet addressed to the node. In such case, the link shall not drive the data bus. After several cycles of no activity on the data bus, the PHY will regain control of the interface and send a null packet on the serial bus. This error condition may result in multiple asynchronous packets being lost on the bus (i.e., no acknowledgement).
17.3.5.1.4 Isochronous packet transmit requests The link issues an Isochronous packet transmit request to transmit any isochronous primary packet. The link may have only one Isochronous packet transmit request outstanding at any point in time. The link uses the request format described in 17.3.5.3 to issue an Isochronous packet transmit request. The link issues Isochronous packet transmit requests explicitly for either the odd or even isochronous phase. The operation of the isochronous phase is similar to the operation of the fairness interval phase. As with Asynchronous packet transmit requests, only one Isochronous packet transmit request from the link is stored by the PHY. Any new Isochronous packet transmit request shall cancel any previous Isochronous packet transmit request. The isochronous GRANT issued by the PHY to the link has sufficient information for the link to determine which request is being granted by the PHY. If the GRANT matches two requests, then the link shall use the GRANT for the higher priority request. It may then use a MORE_INFO cycle to reissue the other request at the end of the packet. To ensure that it generates the request in time, the link shall issue an Isochronous packet transmit request for the next interval so that it is pending at the cycle master before the end of the cycle start packet is sent. This requirement may be met in several ways, two of which are by sending the request at least 10 μs before the link’s cycle timer indicates the start of the next isochronous period or by always appending an Isochronous packet transmit request for the next interval to the end of the last isochronous packet sent in an interval. After sending a first isochronous packet within an isochronous interval, all requests for subsequent isochronous packet transmission within that same interval shall be made in the MORE_INFO cycle at the end of each isochronous packet. Following a bus reset, the cycle master may issue a cycle start packet transmit request. If, after a bus reset, a node issues an Isochronous packet transmit request within 1 μs of receiving the unsolicited register 0, then the Isochronous packet transmit request is propagated to the cycle master in time to be recognized in that first isochronous interval.
17.3.5.1.5 Register Access read or write requests The link issues Register Access read or write requests (i.e., PHY register read or write requests) to gain access to the PHY’s internal register space. The PHY address space is addressable via a 4-bit address, allowing for 16 directly addressable register locations, each a single byte. The link issues PHY register read and write requests using the request format described in 17.3.5.3. The link issues a PHY register read request to instruct the PHY to return the contents of one of its internal registers via a status transfer. The link specifies the PHY address as part of the request. The link shall not issue a further PHY register read request until the first has been completed via a status transfer. The PHY shall ignore further PHY register read requests until the first has been completed. PHY register reads may be initiated at any time. The link issues a PHY register write request to write new contents to one of the PHY’s internal registers. The link supplies the PHY register address and the write data as part of the request. The PHY shall write the data content immediately to the appropriate PHY register. PHY register writes shall not be initiated by the
Copyright © 2008 IEEE. All rights reserved.
497
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
link while a PHY register read is pending. Any PHY register write request that is issued while a PHY register read request is pending shall be ignored by the PHY.
17.3.5.1.6 Restore When a port on the PHY of a nephew node is in the Standby state, the link may initiate a restore operation on that port by issuing any packet transfer request to the PHY. A restore may also be initiated by the uncle. When the PHY begins the restore operation on the port, it shall send a PH_RESTORE_NO_RESET indication to the link and cancel all pending packet transfer requests. Later, when the PHY receives the Restore PHY packet from the uncle, it shall send a PH_RESTORE_RESET if the Restore PHY packet indicates that a reset occurred while the PHY was in standby. The PHY shall complete the restore operation with the initialization completion sequence defined in 17.3.3.5. If a Bus Reset indication is received in a Bus Status Transfer before the restore completes, then the PHY and link shall follow the sequence described in 17.3.8.1.1.
17.3.5.2 Link notifications The link issues notifications to the PHY to inform it of events that have been observed or detected that are relevant to the PHY’s operation. Link notifications take place as soon as possible following the link’s detection of the relevant event. Link notifications are issued using the same format as requests, described in 17.3.5.3.
17.3.5.2.1 Cycle start received notification Any link that is capable of making an Isochronous packet transmit request shall issue a link request to notify the PHY when the link has received a cycle start packet. This notification shall be in the form of a link request of either PH_ISOCH_PHASE_EVEN or PH_ISOCH_PHASE_ODD, ensuring that the PHY knows the isochronous phase that the link is using and protects against problems should the CYCLE_START token not be received by the PHY. The link notification is issued using the format described in 17.3.5.3. The link shall start sending the notification of a received cycle start no later than eight LClk cycles after the quadlet containing the CRC of the cycle start packet is received. The CRC of this packet need not be verified before this notification is sent. However, the link shall check that the packet has a Tcode of 0x8 and is more that two quadlets long before sending the PH_ISOCH_PHASE_* notification. The simplified qualification of the cycle start packet allowed in this subclause is not sufficient for the link to fully qualify the start of an isochronous interval. The CRC of the cycle start packet shall be verified or the link shall receive a Bus Status Transfer indicating a cycle start before the link may use a grant to send an isochronous packet.
17.3.5.2.2 Cycle start due notification The link may issue a cycle start due notification (i.e., PH_CYCLE_START_DUE) when it has determined that a cycle start packet is due to be received over the serial bus. This information is useful to the PHY to allow correct operation of border-related functionality. If provided, the link notification is issued using the format described in 17.3.5.3. NOTE—It is preferred, but not required, that the cycle start due notification be provided by all Beta mode links.
498
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.3.5.3 Link request and notification format Link requests and notifications are issued serially over the LReq interface pin. The LReq signal is always driven by the link. The link is responsible for ensuring that all information transferred using the LReq signal follows the format outlined in this subclause. If the link issues a request or notification outside of this defined specification, such a request shall be ignored by the PHY. If LClk has been stopped, the link may not issue any requests or notifications on LReq until at least 5 LClk cycles have been sent. The link uses the following signalling format (see also Figure 17-24) to issue requests and notifications to the PHY: —
The link request begins with a START bit (always a one), followed by a mandatory 4-bit link Request Type field, RT[0:3].
—
An optional 1-bit Request Format field, RFMT, then follows.
—
Depending on the link request type, a 4 bit Register Address field, RA[0:3], and an 8-bit Register Data field, RD[0:7], may follow.
—
The link request is completed with a mandatory END bit (always a zero). Following the END bit, another link request may be issued immediately.
LReq
RT[0]
.....
RT[3] RFMT
RS[0] / RA[0]
.....
RS[3] / RA[3]
RD[0]
.....
RD[7]
START
LINK REQUEST
REQUEST
LINK REQUEST SPEED or
PHY REGISTER
BIT
TYPE
FORMAT
PHY REGISTER ADDRESS
DATA
(as required)
(as required)
(as required)
END BIT
NOTE—Each cell in the link request format represents one LClk cycle time.
Figure 17-24—Link request format The RT[0:3] field specifies the type of link request or notification that follows. The RT[0:3] field is mandatory for all link requests. Most link requests require additional information to be transferred in the form of request parameters. The PHY determines from the RT[0:3] value if such parameters will follow in accordance with Table 17-34. For requests to use the serial bus for transfer of data, the RT[0:3] field is followed by the RFMT field and the Request Speed field, RS[0:3]. For requests that access PHY registers, the RT[0:3] field is followed immediately by the RA[0:3] field, which for a PHY register write request is followed immediately by the RD[0:7] field.
Table 17-34—RT[0:3] field encoding RT[0:3] value
Name
Meaning
Required fields
0000
Reserved.
The link shall not transmit a request using this value.
None
0001
PH_IMMED_REQ
Used by the link to request immediate access to the serial bus (generally used for transmission of an acknowledge packet).
Request Format, Request Speed
Copyright © 2008 IEEE. All rights reserved.
499
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-34—RT[0:3] field encoding (continued) RT[0:3] value
500
Name
Meaning
Required fields
0010
PH_NEXT_EVEN
Used by the link to request transmission of an asynchronous packet in the even fairness interval phase.
Request Format, Request Speed
0011
PH_NEXT_ODD
Used by the link to request transmission of an asynchronous packet in the odd fairness interval phase.
Request Format, Request Speed
0100
PH_CURRENT
Used by the link to request transmission of an asynchronous packet in the current fairness interval.
Request Format, Request Speed
0101
Reserved
The link shall not transmit a request using this value.
None
0110
PH_ISOCH_REQ_EVEN
Used by the link to request transmission of an isochronous packet in the even isochronous period.
Request Format, Request Speed
0111
PH_ISOCH_REQ_ODD
Used by the link to request transmission of an isochronous packet in the odd isochronous period.
Request Format, Request Speed
1000
PH_CYC_START_REQ
Used by the link to request transmission of a cycle start packet.
Request Format, Request Speed
1001
Reserved
The link shall not transmit a request using this value.
None
1010
PH_REG_READ
Used by the link to request the contents of one of the PHY’s internal registers.
Register Address
1011
PH_REG_WRITE
Used by the link to write new contents to one of the PHY’s internal registers.
Register Address, Register Data
1100
PH_ISOCH_PHASE_EVEN
Used by the link (other than the cycle master) to tell the PHY that a cycle start packet has been received and indicates that the link has set its isochronous phase to EVEN. This ensures that the link and PHY remain in phase synchronization if a CYCLE_ START token had not been received by the PHY and delivered to the link.
None
1101
PH_ISOCH_PHASE_ODD
Used by the link (other than the cycle master) to tell the PHY that a cycle start packet has been received and indicates that the link has set its isochronous phase to ODD. This ensures that the link and PHY remain in phase synchronization if a CYCLE_ START token had not been received by the PHY and delivered to the link
None
1110
PH_CYCLE_START_DUE
Used by the link (other than the cycle master) to indicate to the PHY that a cycle start notification is now due to be received.
None
1111
Reserved
The link shall not transmit a request using this value.
None
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
If the link has prior knowledge that the entire packet transmission path from source to destination is operating in Beta mode (including the PHY-link interface of the destination), it may issue a transmit request requesting the PHY to use the Beta packet format. This request is accomplished by setting the RFMT field to 1”b1 as part of the LReq request stream (see Table 17-35).
Table 17-35—Request format values RFMT value
Meaning
0
The link is not explicitly requesting that the PHY use either Beta or Alpha packet format for packet transmission.
1
The link is explicitly requesting that the PHY use the Beta packet format for packet transmission.
NOTE—The PHY may have determined for itself that the transmission path involves only Beta connections, in which case it may use the Beta packet format. This determination may be made by several means one of which is by the PHY keeping track of the maximum speed of all Alpha nodes. Packets that are sent at speeds faster than the fastest Alpha node may use the Beta packet format regardless of the format indicated in the request from the link.
The RS[0:3] field is used by the link to indicate the transmission speed to be used for a particular packet (see Table 17-36). The PHY explicitly grants the link for that speed. The PHY and link then use the appropriate padding format from the formats specified in 17.3.7.
Table 17-36—Beta and Beta Plus speed encodings RS[0:3] value
Meaning
RS[0:3] value
Meaning
0000
S100
1000
Reserved
0001
Reserved
1001
Reserved
0010
S200
1010
Reserved
0011
Reserved
1011
Reserved
0100
S400
1100
Reserved
0101
Reserved
1101
Reserved
0110
S800
1110
S3200 Beta Plus
0111
Reserved
1111
S1600 Beta Plus
For PHY register read and write operations, the RA[0:3] value represents a PHY register to be accessed. For a PHY register read, the link specifies the PHY register address as part of the request and the PHY returns the register contents in a status transfer. For a PHY register write, the link specifies the target register address for the write operation. For PHY register write operations, the RD[0:7] value represents the data to be written to the PHY register. The link issues notifications to the PHY by sending the appropriate request type as part of a link request. No further parameters are required for link notifications.
Copyright © 2008 IEEE. All rights reserved.
501
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
17.3.6 Interface data transfers The PHY-link interface specifies a number of phases of operation to complete packet data transfers from the PHY to the link and vice versa. These phases are readily identifiable from the state of the Ctl[0:1] signal lines. The discrete PHY-link interface supports data transfers at data rates from S100 to S3200. A mechanism is specified that allows the direction of data transfer to change depending on whether the PHY is sending serial bus data to the link or receiving data from the link for transmission over the serial bus. The data transfer operations that are carried out over the PHY-link interface are a)
Packet transmit (data transferred from link to PHY)
b)
Packet receive (data transferred from PHY to link)
Status information transfers from PHY to link are accomplished using the PInt signal.
17.3.6.1 Interface phases The current phase of the PHY-link interface is indicated by the state of the Ctl[0:1] signal lines. Depending on the current usage of the interface, either the PHY or the link may be driving the Ctl[0:1] lines. The interpretation of the Ctl[0:1] signals depends on which of the two devices is currently in control. The encoding of the interface state on the Ctl[0:1] signals is intended to make it clear which device is in control within a small number of interface cycles.
17.3.6.2 Packet reception The PHY uses the D[0:7] and D[8:15] data interface to send the following information to the link: a)
Data on indication
b)
Packet speed information
c)
Packet data
d)
Packet grant and interface handover information
e)
Bus status information
The link distinguishes these pieces of information from each other using the state of the Ctl[0:1] lines and its current knowledge of the PHY-link interface context. The Ctl[0:1] lines are encoded as shown in Table 17-37 when the PHY is in control of the PHY-link interface.
Table 17-37—Ctl[0:1] state encoding when the PHY controls the PHY-link interface Ctl[0]
Ctl[1]
Interface phase
0
0
IDLE
0
1
STATUS
1
0
RECEIVE
The PHY is transferring DATA_ON, packet speed, packet data to the link.
1
1
GRANT
The PHY is transferring grant information to the link and indicating that it is handing control of the interface over to the link.
502
Phase description The PHY has no information to transfer to the link (i.e., the default state of the PHY-link interface). Bus Status Transfer from the PHY to the link.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
NOTE—Weak pull-downs are present on the Ctl[0:1] and D[0:7] lines of the PHY-link interface when dc-coupled so that the Ctl[0:1] and D[0:7] lines assume and hold an IDLE phase at any point when neither PHY nor link is actively driving the interface.
17.3.6.2.1 Packet reception operation When the PHY receives a packet from the serial bus, it initiates a packet receive operation to the link. The PHY does not perform any packet filtering on the received information. Any PHY packets originated by the PHY as part of bus initialization are sent to its local link in the same manner as packets received from other nodes. The link is required to be ready to receive a serial bus packet at any time when the PHY-link interface is operational. When the PHY has started to send a packet to the link, it may send a holding pattern until it has actual packet data to send. Once the PHY has started to send actual packet data, it shall send packet data information in consecutive PHY-link interface bus cycles until transmission is complete. NOTE—The PHY can issue status information to the link at any point in the packet receive operation where DATA_ON would otherwise be sent.
17.3.6.2.2 Packet reception timing Packet reception timing for the Beta interface is illustrated in Figure 17-25.
Ctl[0:1] D[0:7]
.. 00 10 .. 01 .. 10 10 10 10 ..... 10 00 00 .. .. 00 FF .. ST .. FF SPD B B ..... B 00 00 .. 0 1 N DATA_ON INDICATION (WITH STATUS INDICATION AS REQUIRED) RECEIVE SPEED
RECEIVE PACKET DATA
NOTE—B0–BN represent the information bytes transferred from the PHY to the link. See 17.3.7 for a data format description.
Figure 17-25—Beta interface PHY-link packet receive operation 17.3.6.2.2.1 Beta Plus packet reception timing at S3200 The ways of handling single- and multi-byte traffic are different in S3200 mode. For example, Data On, Packet Speed, Packet Grant, More Info and Interface Handover are single byte control traffic. Bus Status and Acknowledge are single byte data traffic while all other data traffic are quadlets. In S3200 mode, all single byte control traffic and data traffic are expanded to dual byte with the second byte set to 00. For control traffic, D[8:15] are set to 00 when CTL[0:1] are in the 00,01, or 11 phases. For single byte data traffic, D[8:15] are set to 00 when the current cycle is used to send Data On and Packet speed when CTL[0:1] is in the 10 phase. For multi-byte data traffic, both D[0:7] and D[8:15] are used to send packet data when CTL[0:1] are in the 10 phase. At other occasions, D8:15] shall be placed in high-impedance if D[0:7] is placed in high-impedance when interface is being handed over. DATA_HIGH_VALID is always high-impedance whenever D[8:15] is high-impedance. DATA_HIGH_VALID is always 0 when D [8:15] is not carrying actual data. DATA_HIGH_VALID is 1 for all cycles where packet data are transferred except in the case where the number of bytes transferred is odd, in which case it is 0 for the last cycle of the transfer.
Copyright © 2008 IEEE. All rights reserved.
503
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure 17-26 illustrates the packet receive operation at S3200.
Ctl[0:1]
00 10
01
10 10 10 10 10
D[0:7]
00 FF
S
F
D[8:15]
00 00
00
0
0
0
DATA_HIGH_VALID
0
10 10 00 00 ZZ Bx-3 Bx-1
00 00 ZZ
00 00 B2 B4 B6
Bx-2
Bx
00
1
1
0/1
0
SPD
0
B1 B3 B5
1
1
00 Z 0
Z
PClk DATA ON INDICATION WITH STATUS INDICATION AS REQUIRED
RECEIVE SPEED
IDLE
RECEIVE PACKET DATA
NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-26—Beta Plus PHY-Link packet receive operation in S3200 mode
17.3.6.2.2.2 Beta Plus packet reception timing at S1600 and below All single- and multi-byte control and data traffic shall use the D[0:7] data interface to send information to the link at S1600 mode and below. If present, the D[8:15] signals shall be placed in a high-impedance state. Figure 17-27 illustrates the packet receive operation at speeds of S1600 and below.
Ctl[0:1]
00 10
01
10 10 10 10 10
D[0:7]
00 FF
S
F
SPD
D[8:15]
B1 B2 B3
10 10 00 00 ZZ Bx-1
Bx
00 00 ZZ
ZZ
DATA_HIGH_VALID
Z
PClk DATA ON INDICATION WITH STATUS INDICATION AS REQUIRED
RECEIVE SPEED
RECEIVE PACKET DATA
IDLE
NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-27—Beta Plus PHY-Link packet receive operation in S1600 mode 17.3.6.2.3 Packet reception description The steps for packet reception are as follows: a)
504
The PHY indicates that it has packet information to send to the link by asserting RECEIVE on the Ctl[0:1] lines. If no packet data are ready for transfer to the link at that time, the PHY shall indicate this status to the link by asserting DATA_ON encoding on the D[0:7] lines. The PHY shall maintain this condition until data are available. The PHY will indicate DATA_ON for at least one cycle and may continue indicating DATA_ON for an unlimited period
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
b)
The PHY indicates the speed and format of the packet data by indicating the format and speed of the received packet. This is asserted on D[0:7] for one cycle while RECEIVE is asserted on the Ctl[0:1] lines.
c)
The PHY transfers packet information to the link on the D[0:7] lines during successive cycles while continuing to assert RECEIVE on the Ctl[0:1] lines until the transfer is complete.
d)
The PHY asserts idle on the Ctl[0:1] lines and drives the D[0:7] lines to zero to indicate the completion of the packet receive operation.
For a Beta interface, if the speed of the received packet exceeds S800, the PHY shall send DATA_ON indications for the duration of the packet. When DATA_NULL is sent on the serial bus, the PHY shall send a DATA_ON indication on the PHY-link interface. The SPD field indicated in Figure 17-27 is encoded as indicated in Table 17-38.
Table 17-38—Receive packet SPD interval encoding D[0:7] during SPD cycle
Receive packet speed and format
0000 0000
S100 Alpha
0000 0001
S100 Beta
0000 0100
S200 Alpha
0000 0101
S200 Beta
0000 1000
S400 Alpha
0000 1001
S400 Beta
0000 1101
S800 Beta
0000 1111
S1600 Beta Plus
0000 1011
S3200 Beta Plus
1111 1111
DATA_ON
Other values
Reserved
17.3.6.2.4 Interpacket spacing for received packets Between any two received primary packets or PHY packets there shall be at least four PClk signals of nonpacket data time on the PHY-link interface.
17.3.6.3 Packet transmission The link uses the D[0:7] and D[8:15] data interface to send the following information to the PHY: a)
Interface Hold indication
b)
Packet data
c)
Link requests
d)
Interface handover information
Copyright © 2008 IEEE. All rights reserved.
505
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The PHY distinguishes these pieces of information using the state of Ctl[0:1] and its current knowledge of the PHY-link interface context. Ctl[0:1] is encoded as shown in Table 17-39 when the link is in control of the PHY-link interface.
Table 17-39—Ctl[0:1] state encoding when the link controls the PHY-link interface Ctl[0]
Ctl[1]
Interface phase
0
0
IDLE
0
1
TRANSMIT
1
0
Reserved
1
1
HOLD/ MORE_INFO
Phase description The link has completed packet transmission and is handing the interface back to the PHY. The link is transmitting packet information to the PHY. Reserved. The link shall not generate this Ctl pattern. When asserted at the start of a packet transmission, this pattern indicates that the link is holding the PHY-link interface while it is preparing data for transmission. When asserted at the end of a packet transmission, it indicates that D[0:7] contains information on the packet being completed and an embedded link request for another packet transmission.
NOTE—Weak pull-downs are present on Ctl[0:1] and D[0:7] of the PHY-link interface when dc-coupled so that Ctl[0:1] and D[0:7] assume and hold an IDLE phase at any point when neither PHY nor link is actively driving the interface.
17.3.6.3.1 Packet transmit operation When the link requests packet transmit services from the PHY, the PHY performs a serial bus arbitration. When access to the serial bus is granted to the PHY, the PHY propagates this grant to the link. The link then assumes ownership of the PHY-link interface data and control buses. The link may transmit bus holding symbols while it prepares data for transmission. The link then transmits the serial bus packet data until it has completed its packet transmit operation. Once the link has commenced transmitting the serial bus packet information, it shall continue to do so in consecutive PHY-link interface bus cycles until transmission is complete. When the link has completed its packet transmission, it may optionally provide a further link request on the data bus, and shall then hand the PHY-link interface back to the PHY. The PHY may not immediately grant a request made in a MORE_INFO cycle.
17.3.6.3.2 PHY-link packet transmit timing The packet transmission timing is described in Figure 17-28.
17.3.6.3.2.1 Beta Plus packet reception timing at S3200 In S3200 mode, all single byte control and data traffic is expanded to dual-byte with the second byte set to 00. For control traffic, D[8:15] shall be set to 00 when CTL[0:1] is in the 00 and 11 phases. For data traffic, both D[0:7] and D[8:15] shall be used to send packet data when CTL[0:1] is in the 10 phase. At other occasions, D[8:15] shall be placed in high-impedance state as well as when D[0:7] is placed in a high-impedance state when the interface is being handed over.
506
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
INTERFACE GRANT and RELEASE
PHY Ctl[0:1] PHY D[0:7]
00 11 00 ZZ ..... ZZ ZZ ... ZZ ZZ ZZ ... 00 GT 00 ZZ ..... ZZ ZZ ... ZZ ZZ ZZ ...
LINK Ctl[0:1]
ZZ ZZ ZZ ZZ ..... ZZ 11 ... 11 01 01 ...
LINK D[0:7]
ZZ ZZ ZZ ZZ ..... ZZ 00 ... 00 INTERFACE HOLD
B0
B1
...
DATA TRANSFER
INTERFACE IDLE
PHY Ctl[0:1]
..... ZZ ZZ ZZ ZZ ZZ ..... ZZ 00 00 00
PHY D[0:7]
..... ZZ ZZ ZZ ZZ ZZ ..... ZZ 00 00 00
LINK Ctl[0:1]
..... 01 01 11 00 ZZ ..... ZZ ZZ ZZ ZZ
LINK D[0:7]
..... BN-1 BN DATA TRANSFER
AI 00 ZZ ..... ZZ ZZ ZZ ZZ INTERFACE RELEASE
OPTIONAL ADDITIONAL INFORMATION
NOTE—B0–BN represent the information bytes transferred from the link to the PHY. See 17.3.7 for a data format description.
Figure 17-28—Beta and Beta Plus PHY-link packet transmit operation, including optional HOLD cycles DATA_HIGH_VALID shall be held in a high-impedance state whenever D[8:15] is in a high-impedance state. DATA_HIGH_VALID shall be 0 when D[8:15] is not carrying actual data. DATA_HIGH_VALID shall be 1 for all cycles where packet data are transferred except in the case where the number of bytes transferred is odd, in which case it shall be 0 for the last cycle of the transfer. Figure 17-29 illustrates the PHY-link packet transmit operation at S3200, including an optional HOLD cycle.
17.3.6.3.2.2 Beta Plus packet transmission timing at S1600 and below All single byte and multi-byte control traffic and data traffic shall be transmitted over the D[0:7] data interface at speeds of S1600 and below. If present, the D[8:15] bus is placed shall be in a high-impedance state for operation at S1600 and lower speeds. Figure 17-30 illustrates the PHY-link packet transmit operation at S1600 and below, including an optional HOLD cycle.
Copyright © 2008 IEEE. All rights reserved.
507
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
INTERFACE GRANT AND RELEASE
PHY
00 11 00 ZZ
ZZ ZZ
PHY
00 G 00
Z
Z
Z
Z
Z
ZZ
PHY D[8:15]
00 00 00
Z
Z
Z
Z
Z
Z
LINK
Z
LINK
ZZ ZZ Z
LINK DATA_HIGH_VALID
ZZ ZZ
ZZ ZZ ZZ
ZZ 11
11 01 01
Z
Z
00
00 B1 B3
Z ZZ Z
Z
Z
00
00 B2 B4
Z
Z
Z
0
Z
Z
Z
0
INTERFACE HOLD
1
1
DATA TRANSFER
INTERFACE HOLD
PHY
Z
PHY
ZZ ZZ Z
Z
Z
Z
00 00 00
PHY
Z ZZ Z
Z
Z
Z
00 00 00
LINK
01 01 11 00 ZZ
ZZ ZZ ZZ ZZ
LINK
Bx- Bx- AI 00
Z
Z
Z
Z
ZZ
LINK
Bx- Bx 00 00
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
DATA_HIGH_VALID
1
Z
0/
DATA TRANSFER
ZZ ZZ ZZ
0
0
ZZ 00 00 00
INTERFACE REALSE
OPTIONAL ADDTION INFOMATION
P/LCLK NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-29—Beta Plus PHY-Link packet transmit operation in S3200 mode
508
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
INTERFACE GRANT AND RELEASE
PHY
00 11 00 ZZ
ZZ ZZ
PHY
00 G 00
Z
LINK
Z
LINK
ZZ ZZ Z
PHY/LINK DATA_HIGH_VALID
Z
Z
ZZ ZZ
ZZ ZZ ZZ Z
Z
Z
ZZ
ZZ 11
11 01 01
Z
Z
00
00 B1 B2
Z ZZ Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
INTERFACE HOLD
DATA TRANSFER
INTERFACE HOLD
PHY
Z
PHY
ZZ ZZ Z
LINK
01 01 11 00 ZZ
LINK
Bx-
PHY/LINK
ZZ ZZ Z Z
DATA_HIGH_VALID
Z
Z
ZZ ZZ ZZ Z
Bx AI 00
Z
DATA TRANSFER
Z
ZZ 00 00 00 Z
00 00 00
ZZ ZZ ZZ ZZ
Z
Z
Z
Z
ZZ
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
INTERFACE REALSE
OPTIONAL ADDTION INFOMATION
P/LCLK NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-30—Beta Plus PHY-Link packet transmit operation in S1600 mode 17.3.6.3.3 PHY-link packet transmission description The steps for packet transmission are as follows: a)
After at least one cycle of IDLE or STATUS, the PHY indicates that it is transferring ownership of the interface to the link by asserting GRANT on the Ctl[0:1] lines for one cycle while driving the appropriate GRANT value on the D[0:7] lines (see Table 17-41). The PHY then preconditions Ctl[0:1] and D[0:7] by driving them to zero for one cycle followed by releasing Ctl[0:1] and D[0:7] to a high-impedance state.
b)
After the link observes one cycle of zeros on Ctl[0:1], it shall wait one additional cycle (as measured by the LClk) before driving the Ctl and Data buses. It shall indicate that it has packet data to transmit by asserting HOLD or TRANSMIT on Ctl[0:1]. If the link drives HOLD on Ctl[0:1] while it prepares data for transmission, it shall drive D[0:7] to zero. The link shall drive HOLD for no more that MAX_HOLD. If the link does not have any data to transmit or wishes to abdicate its transmit opportunity, it shall not drive any value on Ctl[0:1] or D[0:7].
Copyright © 2008 IEEE. All rights reserved.
509
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
c)
The PHY monitors Ctl[0:1] to determine whether the link has completed the interface handover. If the PHY has not detected either HOLD or TRANSMIT phases within 8 PClk cycles, the PHY shall assume that the link has abdicated its transmission opportunity and shall assume control of the interface by driving Ctl[0:1] to IDLE and D[0:7] to zero.
d)
The link asserts TRANSMIT on Ctl[0:1] when it is transmitting packet data on the D[0:7] lines.
e)
After the last byte of the packet being transmitted, the link may provide additional information to the PHY, by asserting MORE_INFO (see Table 17-43 through Table 17-46 for values) Ctl[0:1] while driving the relevant packet information on D[0:7].
f)
The link terminates a packet transmission by asserting IDLE on the Ctl[0:1] lines for one cycle while driving zero on D[0:7]. The link then releases Ctl[0:1] and D[0:7] to a high-impedance state. The link may release the interface without sending any data.
g)
When the PHY detects the IDLE cycle from the link, it shall regain ownership of the interface by driving IDLE on Ctl[0:1] and zero on D[0:7].
NOTE—If the link does not provide any additional information at the end of packet transmission, the MORE_INFO phase is skipped; the link drives IDLE on Ctl[0:1] and zero on D[0:7] for one cycle before releasing the signals to a highimpedance state.
17.3.6.3.4 Transmit grant types The PHY indicates to the link during the GRANT cycle which type of grant is being issued. This indication includes the grant type as well as the grant speed. The link shall use the bus grant only for transmitting the granted packet type. The link shall transmit a granted packet type only if its request type exactly matches the granted speed and the granted format. The format, grant, and speed types during GRANT cycles are specified in Table 17-40, Table 17-41, and Table 17-42, respectively.
Table 17-40—Format type during GRANT cycle D[0] value during GRANT cycle
Format
0
Unspecified
1
Beta
Table 17-41—Grant Type values during GRANT cycle D[1:3] value during GRANT cycle
510
Grant type
000
Reserved
001
Reserved
010
Isochronous
011
Reserved
100
Reserved
101
Asynchronous
110
Cycle Start
111
Immediate
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-42—Speed types during GRANT cycle D[4:6] value during GRANT cycle
Speed type
D[4:6] value during GRANT cycle
Speed type
000
S100
100
S1600 Beta Plus
001
S200
101
S3200 Beta Plus
010
S400
110
Reserved
011
S800
111
Reserved
During the GRANT cycle, D7 shall be reserved for device- or implementation-specific usage. If the PHY upgrades an unspecified request to Beta, the PHY shall set the Format field (D[0]) to Unspecified in the GRANT associated with that request, to ensure that the link can properly associate the grant with the request.
17.3.6.3.5 Additional information encoding At the end of transmitting a packet, the link may provide packet information and a further link request before releasing the PHY-link interface back to the PHY. The link accomplishes this by driving MORE_INFO on Ctl[0:1] for a single cycle following packet data transmission, while driving D[0:7] as described in 17.3.6.3.5.1 and 17.3.6.3.5.2.
17.3.6.3.5.1 Subaction end notification If the packet that the link is transmitting represents the end of a subaction, then the link shall indicate this fact to the PHY using the value of D[4] during the MORE_INFO cycle at the end of packet transmission (see Table 17-43) Refer to 16.2.3.2 for additional information.
Table 17-43—Subaction end notification during the MORE_INFO cycle D[4] value during MORE_INFO phase
Meaning
0
The packet that has been transmitted does not represent the end of a subaction.
1
The packet that has been transmitted represents the end of a subaction.
17.3.6.3.5.2 Additional link requests If the link wishes to send another request to the PHY without using the LReq request format, it may do so by issuing the request during the MORE_INFO cycle. To issue a request, the link shall provide the Request Type, Request Speed, and Beta-mode indication, as described in Table 17-44, Table 17-45, and Table 17-46. Most of data packets transmitted and received are quadlets, while the some data packets are single byte data packets. The single byte data traffic and control traffic are expanded to dual byte traffic at S3200 mode. Both expanded dual byte data traffic and expanded dual byte control traffic, such as ACK Packet Speed, DATA_ON, GRANT, SPD, ST and MORE_INFO occupy one cycle of PClk or LClk. When transmitting or receiving the expanded dual byte data traffic and dual byte control traffic at S3200 mode, the FSM in PHY
Copyright © 2008 IEEE. All rights reserved.
511
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-44—Link request type during MORE_INFO cycle D[1:3] value during MORE_INFO cycle
Request type
000
No request
001
PH_ISOCH_REQ_ODD
010
PH_ISOCH_REQ_EVEN
011
PH_CURRENT
100
PH_NEXT_EVEN
101
PH_NEXT_ODD
110
PH_CYC_START_REQ
111
Reserved
Table 17-45—Link request speed during MORE_INFO cycle D[5:7] value during MORE_INFO cycle
Request speed
D[5:7] value during MORE_INFO cycle
Request speed
000
S100
001
Reserved
010
S200
011
S3200 Beta Plus
100
S400
101
Reserved
110
S800
111
S1600 Beta Plus
Table 17-46—Link request format during MORE_INFO cycle D[0] value during MORE_INFO cycle
Request format
0
The link is not explicitly requesting that the PHY use either Beta or Alpha packet format for packet transmission.
1
The link is explicitly requesting that the PHY use the Beta packet format for packet transmission.
and link shall be designed to know when they shall ignore the expanded "00" byte latched from D[8:15] through its current knowledge at S3200 mode. When transmitting or receiving the expanded dual byte data at S3200, the DATA_HIGH_VALID signal is held low on the last transfer of the packet if and only if the packet contains an odd number of bytes.
17.3.7 Format of received and transmitted data This standard allows the PHY and link to transfer data to each other at S100, S200, S400, S800, S1600, and S3200 on the parallel PHY-link interface. The discrete PHY-link interface operates in a single clocking mode, which is 98.304 MHz PClk/LClk with single-edge clocking for the Beta interface and 196.608 for the Beta Plus interface.
512
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Data transfers between the PHY and link are accomplished by appropriate padding of the lower rate data as described in 17.3.7.1 through 17.3.7.4. Data on D[0:7] should be latched by the receiving device at the end of the first cycle in a repeating series for data transfers at S400 and below. The transmitting device should drive the same data on D[0:7] for all cycles of a repeating series. PClk and LClk both run at 98.304 MHz ± 100 ppm for the Beta interface and 196.608 MHz ± 100 ppm. for the Beta Plus interface. Data transfers take place on the rising edge of PClk and LClk. LReq requests and PInt status notifications are transferred only on the rising edge of LClk and PClk, respectively. At S800 and below, data transfers between the PHY and link are accomplished by appropriate padding of the lower rate data. Data on D[0:7] should be latched by the receiving device at the end of the first cycle in a repeating series for data transfers at S800 and below. The transmitting device should drive the same data on D [0:7] for all cycles of a repeating series in above modes. At S1600 and below, D[8:15] are and shall be held in a high-impedance state if present. Subclauses 17.3.7.1 through 17.3.7.6 provide illustrations of data transfer at every data rate from S100 through S3200.
17.3.7.1 S100 data For packet data transmitted or received at S100, the data delivery format used to transfer the data to or from the PHY or link is shown in Figure 17-31 and Figure 17-32 for the Beta and Beta Plus interfaces, respectively.
(P)/(L)CLK Ctl[0:1]
10/01
D[0:7]
10/01
BYTE[N-1]
10/01
BYTE[N]
BYTE[N+1]
Figure 17-31—Format of Beta interface data transfers in S100 mode
Ctl[0:1]
00/11
D[0:7]
Control T ffi
D[8:15]
01/10 B1
00/11 BX
Control Traffic
ZZ
P/LClk 16 PClk /LClk cycles NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-32—Format of Beta Plus interface data transfers in S100 mode
Copyright © 2008 IEEE. All rights reserved.
513
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
NOTE—The subscript x of Bx is integer times 4, e.g., 4, 8, 12 and so on. This reflects that most of data packets transmitted and received are quadlets.
17.3.7.2 S200 data For packet data transmitted or received at S200, the data delivery format used to transfer the data to or from the PHY or link is shown in Figure 17-33 and Figure 17-34 for the Beta and Beta Plus interfaces, respectively.
(P)/(L)CLK Ctl[0:1]
10/01
D[0:7]
10/01
BYTE[N-1]
BYTE[N]
10/01 BYTE[N+1]
BYTE[N+2]
Figure 17-33—Format of Beta interface data transfers in S200 mode
Ctl[0:1]
00/11
D[0:7]
Control T ffi
D[8:15]
01/10
00/11
B1
BX
Control Traffic
ZZ
P/LClk 8 PClk/LClk cycles NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-34—Format of Beta Plus interface data transfers in S200 mode
17.3.7.3 S400 data For packet data transmitted or received at S400, the data delivery format used to transfer the data to or from the PHY or link is shown in Figure 17-35 and Figure 17-36 for the Beta and Beta Plus interfaces, respectively.
(P)/(L)CLK Ctl[0:1] D[0:7]
10/01 BYTE[N-2]
10/01 BYTE[N-1]
BYTE[N]
10/01
BYTE[N+1]
BYTE[N+2]
BYTE[N+3]
Figure 17-35—Format of Beta interface data transfers in S400 mode
514
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Ctl[0:1]
00/11
D[0:7]
Control T ffi
D[8:15]
01/10
00/11
B1
BX
Control Traffic
ZZ
P/LClk 4 PClk/LClk cycles NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-36—Format of Beta Plus interface data transfers in S400 mode
17.3.7.4 S800 data For packet data transmitted or received at S800, the data delivery format used to transfer the data to or from the PHY or link is shown in Figure 17-37 and Figure 17-38 for the Beta and Beta Plus interfaces, respectively.
(P)/(L)CLK Ctl[0:1]
10/01
D[0:7]
B[N-5]
10/01 B[N-4]
B[N-3]
B[N-2]
B[N-1]
B[N]
10/01 B[N+1]
B[N+2]
B[N+3]
B[N+4]
B[N+5]
Figure 17-37—Format of Beta interface data transfers in S800 mode
Ctl[0:1]
00/11
D[0:7]
Control T ffi
D[8:15]
01/10 B1
B2
00/11 B X-1
BX
Control Traffic
ZZ
P/LClk NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-38—Format of Beta Plus interface data transfers in S800 mode
Copyright © 2008 IEEE. All rights reserved.
515
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
17.3.7.5 S1600 Data For packet data transmitted or received at S1600, the data delivery format in Figure 17-39 is used to transfer the data to or from the PHY or link.
Ctl[0:1]
00/11
D[0:7]
Control T ffi
D[8:15]
01/10 B1
B2
B3
B4
00/11 B X- B X- B X-
BX Control Traffic
ZZ
P/LClk NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-39—Format of Beta Plus interface data transfers in S1600 mode 17.3.7.6 S3200 Data In S3200 mode, both D [0:7] and D [8:15] are transmitted or received by PHY and Link. D[8:15] will be valid and only be valid at Data Traffic. The S3200 data transfer format is illustrated in Figure 17-40.
Ctl[0:1]
00/11
D[0:7]
Control T ffi 00
D[8:15]
01/10
00/11
B1
B3
B5
B7
B X- B X- B X- BX- Control Traffic
B2
B4
B6
B8
B X- B X- B X-
BX
00
P/ LClk NOTE—Reprinted with permission from 1394 Trade Association TS2006002 [B5].
Figure 17-40—Format of Beta Plus interface data transfers in S3200 mode 17.3.8 Status transfers and notifications from the PHY The PHY issues status transfers and notifications to the link to a)
Notify the link of serial bus packet-related events relevant to its operation
b)
Notify the link of PHY events relevant to its operation
c)
Return PHY register read data requested by the link
d)
Transfer the serial bus node_ID to the link during the tree identify phase
Status transfers from the PHY to the link take place using one of two mechanisms. The first mechanism transfers packet-related status information over the D[0:7] signal lines. This mechanism is used when the status information relies on its position relative to the packet traffic for context. This status transfer mechanism is called Bus Status Transfer. The second status transfer mechanism is used when the status does
516
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
not depend on a position relative to the serial bus packet traffic. This status transfer mechanism is called PHY Status Transfer. In both cases, the PHY shall complete the status transfer, even if it detects the withdrawal of LPS after it has commenced sending the status transfer.
17.3.8.1 Bus Status Transfers Bus Status Transfers are used to transfer the following packet-related status information from the PHY to the link on D[0:7]: a)
Bus Reset indication
b)
Arbitration Reset Gap indication (both even and odd)
c)
Subaction Gap indication
d)
Cycle Start indication (both even and odd)
The format for a Bus Status Transfer is specified in 17.3.8.1.2. When one of the serial bus events listed in this subclause occurs, the PHY shall report this event in a Bus Status Transfer with the appropriate status bit(s) set (see Table 17-47). If the event occurs at a time when the PHY-link interface is not operational, the status indication(s) are lost and are not generated or repeated when the PHY-link interface is next operational.
17.3.8.1.1 Serial bus reset indications When a bus reset occurs on the serial bus, the PHY shall send a Bus Status Transfer indicating a bus reset if the PHY-link interface is operational. When a Bus Reset indication is sent, the following actions occur: a)
The PHY shall cancel all packet transfer requests,
b)
The isochronous and asynchronous phases are set to even,
c)
The PHY shall forward self-ID packets to the link as they are received or transmitted on the serial bus, and
d)
The PHY shall notify the link of its node_ID by sending an unsolicited PHY register 0 status transfer before releasing control of the serial bus.
The PHY shall not queue any packet transmit request other than a Cycle Start until the last bit of the unsolicited register 0 is sent to the link. The link shall make no packet transfer requests other than a Cycle Start until the link has received the last bit of the unsolicited register 0. If the link is cycle master capable, it may send a Cycle Start request immediately after receiving a Bus Reset indication. The PHY shall not grant the cycle start unless the node is root. If the PHY-link interface is not operational when a reset occurs on the serial bus, the Bus Reset indication shall be communicated as outlined in 17.3.3.5 when the PHY-link interface does become operational. The PHY may not send a Bus Reset indication while it is in the process of sending an unsolicited register 0 PHY Status Transfer. The Bus Reset indication will be queued by the PHY and sent no sooner than the first PClk after sending the end bit of the register 0 PHY Status Transfer.
Copyright © 2008 IEEE. All rights reserved.
517
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
17.3.8.1.2 Bus Status Transfer format Bus Status Transfers take place over the D[0:7] signal lines. The format shown in Figure 17-41 is used to transfer status information in a single PClk clock cycle over D[0:7].
Ctl[0:1]
.....
XX
01
XX
.....
D[0:7]
.....
XX
ST
XX
.....
STATUS BITS
Figure 17-41—Bus Status Transfer format During a Bus Status Transfer, D[0:7] is encoded in accordance with Table 17-47. If a particular bit is set during a status transfer, then the indicated event has occurred. Only one status bit shall be set by the PHY in any single Bus Status Transfer. Bus Status Transfers may occur on consecutive data bus cycles.
Table 17-47—Bit encoding for Bus Status Transfers Status bit
Meaning
D[0]
Bus Reset. Corresponds directly to PH_EVENT.indication of PH_BUS_RESET_START.
D[1]
Arbitration Reset Gap—Odd. Corresponds to PH_DATA.indication of PH_ARB_RESET_ODD.
D[2]
Arbitration Reset Gap— Even. Corresponds to PH_DATA.indication of PH_ARB_RESET_EVEN.
D[3]
Cycle Start—Odd. Corresponds to PH_DATA.indication of PH_ISOCH_ODD.
D[4]
Cycle Start—Even. Corresponds to PH_DATA.indication of PH_ISOCH_EVEN.
D[5]
Subaction Gap. Corresponds to PH_DATA.indication of PH_SUBACTION_GAP. After a bus reset, this is an implicit PH_EVENT.indication PH_BUS_RESET_COMPLETE.
D[6]
Reserved.
D[7]
Reserved.
17.3.8.2 PHY Status Transfers PHY Status Transfers are used to convey from the PHY to the link any status information that is not related to serial bus packet activity. The following information is conveyed from the PHY to the link in a PHY Status Transfer: a)
PHY Interrupt indication
b)
PHY Register Read indications (both solicited and unsolicited)
c)
Bus Initialization indications (including serial bus reset or not)
PHY Status Transfers take place using a format that allows a variety of types of information of various lengths to be communicated from the PHY to the link. This format is specified in 17.3.8.2.4.
518
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
17.3.8.2.1 PHY Interrupt indications When an event occurs that requires the PHY to interrupt the link, the PHY initiates a PHY Status Transfer with Interrupt status indication set. This instructs the link to read the PHY’s register set to determine the cause of the interrupt. If the PHY is required to interrupt the link when the PHY-link interface is not operational, the PHY shall use the LinkOn mechanism, which is also an implied PHY interrupt. In such a case, when the PHY-link interface becomes operational again, the PHY shall not issue a PHY Interrupt status indication.
17.3.8.2.2 PHY Register Read indications When the PHY has register information that it needs to transfer to the link, it issues a PHY Status Transfer containing PHY register data. The register data can be either solicited or unsolicited. The data are solicited if the link has explicitly asked for the PHY to return register contents via a PHY register read. The data are unsolicited if the PHY is autonomously sending PHY register information to the link. In both cases, the PHY returns the PHY register data with the address of the PHY register from which the data are taken. If the PHY has register data to send PHY register information to the link when the PHY-link interface is not operational, no data are transferred; and the data shall not be sent when the PHY-link interface is next operational. The PHY issues an unsolicited PHY Register Status Transfer to transfer the PHY’s node_ID value to the link as part of the PHY-link initialization phase. The PHY issues an unsolicited register 0 transfer that contains the node_ID value. Following the unsolicited register 0 transfer, the link should be immediately capable of receiving serial bus packets that are addressed to it. The link should ignore, and not respond to or take any action as a result of, any received bus traffic until it has received a valid node_ID value during interface initialization.
17.3.8.2.3 Bus Initialization indications At the end of the PHY-link interface initialization phase, the PHY shall initiate a PHY Status Transfer that indicates whether a serial bus reset occurred when the PHY was active but the PHY-link interface was not operational. If this PHY Status Transfer indicates that no serial bus reset occurred, then no change in serial bus topology occurred while the PHY-link interface was inactive. This indication (i.e., PH_RESTORE_NO_RESET or PH_RESTORE_RESET) shall be transferred to the link only once each time the PHY-link interface is initialized. PH_RESTORE_NO_RESET and PH_RESTORE_RESET indications shall also be sent when a PHY port comes out of standby.
17.3.8.2.4 PHY Status Transfer format PHY Status Transfers take place serially over the PInt signal. The format of the status transfer depends on the information that is to be transferred (see Figure 17-42). PHY Status Transfers begin when the PHY asserts PInt for one cycle. This START bit is always a one. The PHY then issues a 3-bit serial field over PInt. This field indicates the PHY status type and is used by the link to determine whether further information is expected as part of the status transfer. If the PHY Status Transfer type indicates that further information exists, this information follows the Status Type field directly. The PHY Status Transfer is completed by an END bit, which is always zero. A new PHY Status Transfer can begin immediately with a new START bit. PHY Status Transfers can occur concurrently with link requests and packet transmission and reception operations. Multiple status events are indicated by multiple status transfers. The ordering of status transfers is determined by the PHY.
Copyright © 2008 IEEE. All rights reserved.
519
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
PInt
ST[0]
START BIT
ST[1]
ST[2]
STATUS TYPE
RA[0]
.....
RA[3] RD[0]
REGISTER ADDRESS (if required)
.....
RD[7]
REGISTER DATA (if required)
END BIT
NOTE—Each cell in the PHY Status Transfer format represents one PClk cycle time.
Figure 17-42—Beta and Beta Plus PHY Status Transfer format The encoding of the PHY Status Transfer is specified in Table 17-48.
Table 17-48—Beta and Beta Plus PHY Status Transfer encoding ST[0:2] value
Name
Additional fields
Meaning
000
NOP
No Status indication
None
001
PHY_INTERRUPT
The PHY requires the link to read its internal register set to determine the cause of the interrupt. The causes of this indication can be: PH_CONFIG_TIMEOUT (loop detect), PH_CABLE_POWER_FAIL, PH_INTERRUPT (a port event), or An arbitration state machine timeout
None
010
PHY_REGISTER_SOL
The PHY is returning the contents of one of its internal registers as a result of the link’s having explicitly requested such a read.
PHY Address, PHY Data
011
PHY_REGISTER_UNSOL
The PHY is returning the contents of one of its internal registers without having been requested by the link to do so.
PHY Address, PHY Data
100
PH_RESTORE_NO_RESET
The PHY-link interface has been initialized, and the link is informed that there is no unreported serial bus reset to now report or that a PHY port has started the restore process.
None
101
PH_RESTORE_RESET
The PHY-link interface has been initialized, and the link is informed that there is an unreported serial bus reset to now report or that a PHY port has completed the restore process and a serial bus reset occurred while the port was in standby.
None
110
Not available
This code is not available. A PHY is permitted to send this code, but the link shall ignore any status transfer using this code.
None
111
Reserved
Reserved
Reserved
520
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.3.9 Delays affecting interoperability of PHYs and links This standard places limits on the response times of a node. Some of the actions that affect these response times require interaction between the PHY and the link. To ensure that the PHY and link interoperate, limits are placed on the delays that each may contribute to the overall delay. These delays are summarized in Table 17-49.
Table 17-49—Beta and Beta Plus PHY-link critical delays Name BUS_TO_LINK_DELAY
Min
Max
Units
Description
4
24
PClk cycles
Time from the start of a RX_DATA_PREFIX, DATA_NULL, or packet prefix to the assertion of Receive on Ctl[0:1] at the link side of the interface.
63
PClk cycles
When a node originates a packet, the time from the start of the TX_DATA_ PREFIX or the packet prefix at the senior port (or any port on the proxy_root) to the PHY’s assertion of Grant on Ctl[0:1] as measured at the link side of the interface.
DATA_PREFIX_TO_GRANT
LINK_TO_BUS_DELAY
4
14
LClk cycles
At the end of packet transmission by the link, the time from the assertion of Idle on Ctl[0:1] at the link side of the interface to the start of the TX_DATA_ END or the packet end on any transmitting port.
LREQ_TO_BUS_DELAY
11
20
LClk cycles
Time from the start bit of a bus request on LREQ at the link side of the interface to the start of a corresponding TX_REQUEST or BOSS request symbol at the senior port (or any port on the proxy_root) assuming an idle serial bus with no higher priority requests present at the PHY.
63
LClk cycles
Maximum time that the link may continuously assert Hold on Ctl[0:1] after observing Grant.
MAX_HOLD
17.3.10 Alpha link support The Beta PHY-link interface is a superset of the Alpha signals. This standard does not preclude building a PHY that supports both Alpha and Beta styles of link. Beta PHYs are not required to support Alpha links. If the optional Beta_Mode_link input to the PHY is connected to logical 0, the Beta PHY shall operate its PHY-link interface in accordance with the PHY-link interface specification detailed in the Alpha specification in 17.2. In this mode, the PHY sources an interface clock of 49.152 MHz in accordance with the Alpha specifications. In this case, the Beta PHY-link interface signals are used as shown in Table 17-50. In this mode of operation, link requests, link and PHY packet transfers, and PHY status transfers take place in the manner defined by the Alpha specifications. No Beta specific features, such as request for next cycle, are available. The Alpha LReq cancellation rules also take effect (see 17.2.3.1). Data transfers at S100, S200, and S400 only are supported by the PHY-link interface in this mode. In this mode of operation, the LClk input to the PHY shall be held to logical 0 by the PHY. The PHY PInt signal output shall be driven to logical 0 by the PHY and should not be used.
Copyright © 2008 IEEE. All rights reserved.
521
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-50—Mapping of Beta PHY-link signals to Alpha signals Beta PHY-link interface pin
Alpha PHY-link interface pin
Ctl[0:1]
Ctl[0:1]
D[0:7]
D[0:7]
PClk
SCLK
LReq
LReq
LinkOn
LinkOn
LPS
LPS
LClk
Not used by Alpha; PHY holds to logical 0
PInt
Not used by Alpha; PHY drives logical 0
Beta_Mode
System drives logical 0
A PHY that is compliant with this standard may also be designed to operate with Alpha links. It is recommended that PHYs that offer this capability be compliant with the Alpha PHY-link interface specification contained in 17.2. When operating in Alpha mode, self-ID packets sent by the PHY shall be sent without a speed code to identify the PHY as being a connection to a hybrid bus (i.e., a border node). In the case of an Alpha Link, Beta Link or Beta Plus Link at S1600 and below, when D[8:15] is present, D[8:15] shall be held in a high-impedance state. If the PHY design allows the mode of the PHY-link interface to be changed while the PHY is powered and if the mode is changed, the PHY shall place all ports in the Disconnected state and begin initialization as if the PHY had just been powered on.
17.3.11 Electrical characteristics This subclause specifies the signal and timing characteristics of the Beta and Beta Plus interface between a discrete PHY and link.
17.3.11.1 DC signal levels and waveforms The basic assumptions in this subclause are that all interfaces are 3.3 V I/O compliant. The signal levels are targeted to be CMOS signals that swing rail to rail. All inputs shall be tolerant of 3.3 V signals when they are powered down and shall not cause either permanent damage or inconsistent behavior when powered while inputs are driven. A link that is compliant to the Alpha specification (see 17.2) may be connected to a PHY that is compliant with the Beta specification. In such cases, the signaling shall conform to the Alpha PHY-link specification. DC parametric attributes of the Beta and Beta Plus PHY-link interface signals are specified in Table 17-51 and Table 17-52, respectively. Devices not tolerant of mismatched input levels, but that otherwise meet the requirements in the table, are compliant with IEEE Std 1394. VDD is obtained from the vendor’s specifications.
522
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-51—DC specifications for the Beta PHY-link interface Name
Description
Conditions
Minimum
Maximum
Units
VOH
Output high voltage (undifferentiated)
IOH = –4 mA
2.8
V
VOHD
Output high voltage (differentiated)
IOH = –9 mA at VDD = 3 V IOH = –11 mA at VDD = 4.5 V
VDD – 0.4
V
VOL
Output low voltage (undifferentiated)
IOL = 4 mA
0.4
V
VOLD
Output low voltage (differentiated)
IOL = 9 mA at VDD = 3 V
0.4
V
VIH
Input high voltage (undifferentiated)
VDDa + 10%
V
VIL
Input low voltage (undifferentiated)
0.7
V
VLREF + 1b
V
2.6
VLIT+
Input rising threshold (LinkOn and LPS)
VLIT-
Input falling threshold (LinkOn and LPS)
VLREF + 0.2b
VIT+
Hysteresis input rising threshold (differentiated)c
VREF + 0.3
VREF + 0.9d
V
VIT-
Hysteresis input falling threshold (differentiated)c
VREF – 0.9c
VREF – 0.3
V
VREF
Reference voltagee
VLREF
Reference voltagef (LinkOn and LPS inputs)
CIN
Input capacitance
V
VDD/2 ± 1% 0.5
V 1.6
V
5.0
pF
aRefers
to driving device’s power supply. LinkOn and LPS receiver parameters are based on a swing of 2.4 V for the received signal. Links that depend only on receiving the initial edge of LinkOn may be capable of operating with less constrained values. cWhen the PHY-link interface is in differentiated mode, the PClk and LClk inputs shall meet the V IT+ and VIT– requirements. d When designing a device capable of both undifferentiated and differentiated operation, VIH and VIL effectively constrain these VIT+ and VIT– values to VREF + 0.8 V and VREF – 0.8 V, respectively. bThe
eFor f
some applications, a device can be compliant with these dc specifications even if a different VREF is chosen.
For a particular application, a single value exists for each device’s nominal bias point, VLREF, which shall be within the range specified. VLREF should be chosen in conjunction with the receiver parameters so that a loss of power by the transmitting device is perceived as zero by the receiving device.
Copyright © 2008 IEEE. All rights reserved.
523
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-52—DC specifications for the Beta Plus PHY-link interface Name
Description
Conditions
Minimum 2.8
VOH
Output high voltage
IOH = –16 mA
VOL
Output low voltage
IOL =16 mA
VIH
Input high voltage
VIL
Input low voltage
Maximum
V
2.6
VLIT+
Input rising threshold (LinkOn and LPS)
VLIT-
Input falling threshold (LinkOn and LPS)
VLREF + 0.2b
VLREF
Reference voltage (LinkOn and LPS inputs)
0.5
CIN
Units
Input capacitance
0.4
V
VDDa + 10%
V
0.7
V
VLREF + 1b
V V
1.6
V
5.0
pF
aRefers
to driving device’s power supply. LinkOn and LPS receiver parameters are based on a swing of 2.4 V for the received signal. Links that depend only on receiving the initial edge of LinkOn may be capable of operating with less constrained value
bThe
17.3.11.2 AC timing The protocol of this interface is designed so that all inputs and outputs at this interface can be registered immediately before or after the I/O pad and buffer. No state transitions need be made that depend directly on the chip inputs; chip out-puts can come directly from registers without combinational delay or additional loading. This configuration provides generous margins on setup and hold time. Timing follows normal source-clocked signal conventions. A 0.5 ns allowance is made for skew through an (optional) isolation barrier. The rise and fall time measurement definitions, tR and tF, for PClk, LClk, Ctl[0:1], D[0:n], PInt, and LReq are shown in Figure 17-43.
90%
90%
10%
10% tR
tF Figure 17-43—Signal levels for rise and fall times
Other signal characteristics of the PHY-link interface are specified in Table 17-53 (Beta) and Table 17-54 (Beta Plus.) If an isolation barrier is implemented, it shall cause neither delay nor skew in excess of the values specified. AC measurements shall be taken from the 1.575 V level of PClk or LClk to the input or output Ctl[0:1], D[0:n], or LReq levels and shall assume an output load of 10 pF.
524
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 17-53—Beta interface ac timing parameters Name
Description
Minimum
Maximum
Units
PClk or LClk frequency
98.304 ± 100 ppm
MHz
DCP
PClk duty cycle
35
65
%
DCL
LClk duty cyclea
DCP – 5
DCP + 5
%
jL
LClk jitter (pk-pk)b
tR
Rise time
—
3.5
ns
tF
Fall time
—
3.5
ns
tPL
Delay from rising edge of PClk into the link to the rising edge of LClk from the link
—
5
ns
tSK
Skew through isolation barrier
0
0.5
ns
tBR
Isolation barrier recovery time
0
10
μs
tpdPL
Signal propagation delay from PHY to link
—
1.5
ns
tpdLP
Signal propagation delay from link to PHY
—
1.5
ns
tpd1
Delay time. PClk/LClk input high to initial instance of D[0:n], Ctl[0:1], PInt/LReq outputs valid.
0.5
7.0
ns
tpd2
Delay time. PClk/LClk input high to subsequent instance(s) of D[0:n], Ctl[0:1], PInt/LReq outputs valid.
0.5
7.0
ns
tpd3
Delay time. PClk/LClk input high to D[0:n]] and Ctl[0:1] invalid (high impedance).
0.5
7.0
ns
tsu
Setup time. D[0:n], Ctl[0:1], and PInt/LReq inputs before PClk/LClk.
2.5
—
ns
thld
Hold time. D[0:n], Ctl[0:1,], and PInt/LReq inputs after PClk/LClk.
0.0
—
ns
Maximum
Units
jP + 0.50
ns
aThe bj
LClk duty cycle is determined by the actual duty cycle of PClk. denotes the PClk pk-pk jitter. P
Table 17-54—Beta Plus interface ac timing parameters Name
DCP DCL
Description
Minimum
PClk or LClk frequency
196.608 ± 100 ppm
PClk duty cycle
45
55
%
DCP – 5
DCP + 5
%
LClk duty
cyclea
MHz
jL
LClk jitter (pk-pk)b
tR
Rise time
—
2.0
ns
tF
Fall time
—
2.0
ns
tPL
Delay from rising edge of PClk into the link to the rising edge of LClk from the link
—
4.0
ns
Copyright © 2008 IEEE. All rights reserved.
jP + 0.50
ns
525
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 17-54—Beta Plus interface ac timing parameters (continued) Name
Description
Minimum
Maximum
Units
tpdPL
Signal propagation delay from PHY to link
—
1.0
ns
tpdLP
Signal propagation delay from link to PHY
—
1.0
ns
tpd1
Delay time. PClk/LClk input high to initial instance of D[0:n], Ctl[0:1], PInt/LReq outputs valid.
0.5
2.5
ns
tpd2
Delay time. PClk/LClk input high to subsequent instance(s) of D[0:n], Ctl[0:1], PInt/LReq outputs valid.
0.5
3.5
ns
tpd3
Delay time. PClk/LClk input high to D[0:n]] and Ctl[0:1] invalid (high impedance).
0.5
3.5
ns
tsu
Setup time. D[0:n], Ctl[0:1], and PInt/LReq inputs before PClk/LClk.
1.5
—
ns
thld
Hold time. D[0:n], Ctl[0:1,], and PInt/LReq inputs after PClk/LClk.
0.0
—
ns
aThe bj
LClk duty cycle is determined by the actual duty cycle of PClk. denotes the PClk pk-pk jitter. P
Figure 17-44 and Figure 17-45 illustrate the transfer waveforms as observed at the PHY. A PHY shall implement values for tpd1, tpd2, and tpd3 within the limits specified in Table 17-53 and Table 17-54 shall not depend upon values for tsu and thld greater than the minimums specified.
Source Clock
tpd1
tpd2
tpd3
Output LR
Figure 17-44—Transfer waveform at the source
Source Clock
tsu
thld
Input Figure 17-45—Transfer waveform at the destination The ac timing parameters shall meet the values given in Table 17-53 and Table 17-54 for the Beta and Beta Plus interfaces, respectively.
526
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
17.4 Isolation barrier 17.4.1 Introduction The sample circuits shown in this subclause demonstrate how to achieve galvanic isolation between a discrete PHY and link by means of a capacitive isolation barrier. For applications that require isolation, other methods may be used.
17.4.2 Capacitive isolation barrier When capacitive isolation is used between the PHY and the link, the grounds of both devices shall be coupled as shown in Figure 17-46. The details of this ground coupling are omitted from Figure 17-47 through Figure 17-51.
0.1μF
1M Ω
several places 0.001μF PHY ground
link ground
Capacitor and resistor values are nominal
Figure 17-46—Example of ground coupling circuit The isolation design in the circuits in Figure 17-47 through Figure 17-51 have a signal sag of approximately 0.3% per nanosecond. The sag may cause a signal to exceed the power supply on the input during the next transition. Depending on the longest duration of a one or zeros, a problem may occur at the next transition of a signal. The resulting overshoot could impact the RF interference. In addition, inputs should be specified to be tolerant of signals that exceed the power supply rail. CAUTION
Caution should be exercised because capacitive isolation will pass any high-frequency transients such as electrostatic discharge events at the PHY cable interface. The inputs on both sides of the PHY-link interface should have robust electrostatic discharge performance. The ability to match the center of the hysteresis for the inputs and the nominal bias voltage from the resistive dividers is critical.
Copyright © 2008 IEEE. All rights reserved.
527
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The sample circuits in Figure 17-47 through Figure 17-51 illustrate different requirements of the various signals of the PHY-link interface. power
power
Device B
5KΩ
5KΩ
0.001μF
300Ω
0.001μF
5KΩ
5KΩ
Device A
to Device A or Device B ground
Figure 17-47—Example of capacitive isolation barrier circuit for Ctl[0:1] and D[0:n]
PHY 0.01 μ F
5KΩ
power Optional current limiting resistor
link
1.6KΩ
100 Ω
Figure 17-48—Example of capacitive isolation barrier circuit for LinkOn
528
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
5KΩ
power
link 0.033 μ F
Optional current limiting resistor
PHY
1.6KΩ
100 Ω
Figure 17-49—Example of capacitive isolation barrier circuit for LPS NOTE—In Figure 17-48 and Figure 17-49, the values of the resistors between signal and ground or signal and power should be chosen to suit the implemented value of VLREF. The values shown are appropriate when VLREF is nominally 0.8 V.
5KΩ
0.001μF
300Ω
0.001μF
5KΩ
power
5KΩ
5KΩ
power
Figure 17-50—Example of capacitive isolation barrier circuit for LReq and PInt
Copyright © 2008 IEEE. All rights reserved.
529
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
power
0.001μF
5KΩ
5KΩ
power
Optional current limiting resistor
5KΩ
5KΩ
100 Ω
Figure 17-51—Example of capacitive isolation barrier circuit for LClk and PClk 17.4.3 Alternative isolation barrier This subclause describes an alternative method of isolation for the PHY-link interface signals. For this method, a bus-holder circuit is added to some of the input lines. The bus holder circuit (see Figure 17-52 and Figure 17-53) consists of a CMOS-buffer stage with a high-resistance feedback path between its output and its input. The feedback path through the buffer stage keeps the signal at the last valid logic state. When the output node switches states, the signal propagates through the isolation capacitor and overdrives the feedback circuit causing the input to switch to the level imposed by the output. The feedback driver then changes state to provide a dc path to overcome any loss of charge in the isolation capacitor. This holds the input level at or near the voltage of the output until the output makes another transition. The feedback buffer(s) and resistor(s) may be internal or external to the PHY or link component.
10KΩ
Resistor value is illustrative.
0.001μF
Figure 17-52—Example of bus holder isolation circuit for LReq, PInt, PClk, and LClk
530
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Device A
Device B
10KΩ
10KΩ
Capacitor and resistor values are illustrative.
0.001μF
Figure 17-53—Example of bus holder isolation circuit for Ctl[0:1] and D[0:n] When bus holders are present on both the PHY and the link, the isolation circuit consists of a single capacitor in each line. Bus holders may be used on CTL[0:1], D[0:7], LReq, PInt, PClk, and LClk signals. For bidirectional signals (i.e., D[0:7] and Ctl[0:1]), bus holders are present on both the PHY and the link. The threshold levels on LinkOn and LPS make it more difficult to ensure that a clocked signal will eventually cause the input to switch to the correct state if a bus holder is driving the line, however weakly, to the wrong state. For these reasons, the standard isolation circuits for LinkOn and LPS (as shown in Figure 17-48 and Figure 17-49, respectively) are recommended. If bus holders are present on both the PHY and the link and if LPS is implemented only as a pulsed signal (preferred), then the Direct pin, if present, on the link may be tied either high or low as required by the link vendor. If LPS is not pulsed when Direct is tied high on the link, then the Direct pin on the link shall be tied low when bus holders are used. If bus holders are present on both the PHY and link, then the Direct pin on the PHY, if present, may be tied either high or low as required by the vendor. The presence of bus holders within a device may change the observed output voltage levels so that they may appear to be not operating in differentiated mode even though the Direct pin is tied low. External bus holders may be added on to a PHY or link that does not have the bus holders integrated. When external bus holders are present, the Direct pins on the PHY and link are set according to vendor instructions.
Copyright © 2008 IEEE. All rights reserved.
531
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
532
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
18. PIL-FOP serial interface This clause describes an interface between a link and a discrete PHY that may be used for all serial bus speeds from S100 to S3200. This interface provides a less costly means of isolation than does the PHY-link interface. Additionally, this interface allows the two components using this interface to be physically separated (for example, across a backplane or in different enclosures). For this interface, a PHY with a single Beta port is integrated into a link. This combination is referred to as the PIL. The PIL is then connected to a Beta-capable port on the FOP as illustrated in Figure 18-1. The connection between the PIL and the FOP may optionally include series blocking capacitors to provide galvanic isolation. The PIL and the FOP may be in different power domains. NOTE—Because the PIL-FOP interface is a Beta copper connection, the required speed is S400β; and the maximum allowed speed is S3200β as specified in Table 14-1.
18.1 Operating model The operating model is that the PIL effectively serves the role of a traditional link, while the FOP operates as the effective PHY in the system. In this arrangement, the combination of PIL and FOP operates as a single node on the network. A special packet protocol is used on the PIL-FOP serial interface to allow read and write access to the PHY registers in the FOP and for the FOP to signal various events to the PIL, ensuring that a PIL and FOP are indistinguishable from a PHY and link to system software. See Figure 18-1.
LinkOn Internal or External Serial Bus Connections
Beta LINK
Beta B-ONLY PHY
Beta Serial Bus Connection 4
B ‘FAN-OUT’ PHY
4 4 4
INTEGRATED PHY and LINK
IEEE 1394-ENABLED DEVICE e.g., PC, Set top box, etc. Figure 18-1—Possible system configuration using a FOP device A PHY that is designed to be used as a FOP may also be designed to allow the PIL port to be used as a standard, Beta-only, or bilingual port. For such a PHY, the highest number port shall be the one that is used as the PIL port. When the port is attached to a PIL, the self-ID packet for the FOP indicates that the PIL port is not implemented and any PHY packet access to the registers associated with the PIL port on the FOP indicates that the port is not implemented. For example, if a PHY has six ports, the PIL may be attached only to port number 5 (i.e., the sixth port); and if a PIL is attached, then in its self-ID packets, the FOP will report that only five ports are present. As with the link connection on a PHY, the PIL connection on the FOP is not considered to be an active port on the FOP when determining whether a port on the FOP can be placed into standby. If the FOP receives a
Copyright © 2008 IEEE. All rights reserved.
533
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
standby PHY command, then the FOP honors the request if the addressed port is the only active port on the FOP other than the PIL port. The FOP shall provide a LinkOn signal. This signal has identical electrical characteristics and logical behavior as the LinkOn signal of the PHY-link interface defined in Clause 17.
18.2 PIL-FOP connection management The PIL-FOP interface behavior is similar to a connection between any other two Beta ports. The connection management state machines for the PIL and FOP are simplified versions of the standard Beta port connection management state machine. The PIL uses the following states from the port connection manager state machine in 14.5: P0: Disconnected, P2: Active; P7: Standby Initiator, P9: Standby, and P10: Restoring. The FOP uses the following states from that state machine: P0: Disconnected, P2: Active, P8: Standby Target, P9: Standby, and P10: Restoring. Both PIL and FOP transition from the P0: Disconnected state to the P9: Standby state when connected (i.e., normally the P0:P11 transition). Variables and functions needed for the other states are not required for this interface. The configuration requests that are used to support transitions to unimplemented states are not allowed on the PIL-FOP interface.
18.2.1 Power-on When the PIL or FOP powers on, it begins toning. When both detect toning, they exchange speed codes. When they compete the exchange of speed codes, they transition to the Standby state. The negotiated speed between the PIL and the FOP and the speed reported in the link_spd field of the Bus_Info_Block shall be consistent.
18.2.2 PIL-FOP negotiation The PIL-FOP negotiation protocol allows a PHY that is PIL capable to be used with a PHY that is FOP capable and have them establish the proper relationship without requiring strapping or other means of setting the mode. It is possible to use the PIL-FOP negotiation protocol to have two connected devices, in separate enclosures, establish a PIL-FOP relationship. When the PIL and FOP begin exchanging speed codes, a PIL-capable PHY sets the PIL_capable field in the speed negotiation code. A FOP sets the FOP_capable field in its speed negotiation code. When a PILcapable PHY receives a speed code with the FOP_capable field set, it selects a compatible speed and sends the speed code with the PIL_capable field set and with the ACK field set. Otherwise, it clears the PIL_capable field when it sends the acknowledgement. A FOP_capable PHY sends its speed code with the FOP_capable field set. If it receives a speed code with the PIL_capable field set, it sets the FOP_capable field when it acknowledges the speed. Otherwise, it clears the field. A PIL may be designed so that it may be used only with a FOP. A PIL may also be designed so that it can be used as a single-port PHY. When a PIL-capable PHY is used in a system with a FOP, the PIL implementation may rely on vendor-dependent means to cause the PHY to behave as a PIL, or the PHY may use the PIL-FOP negotiation protocol in order to select the correct mode of operation. A PIL that is designed to operate only as a PIL may support the PIL-FOP negotiation protocol. A FOP may be designed so that a port may be connected only to a PIL. A FOP may also be designed so that the highest numbered port may be connected to a PIL or operate as a normal PHY port. For such a dual-role PHY, a vendor-specific means may be used to cause the PHY to act as a FOP, or the PHY may use the
534
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
PIL-FOP negotiation protocol to select the correct mode of operation. A FOP that is designed so that one port shall be connected to a PIL may support the PIL-FOP negotiation protocol on that port. The system implementer is responsible for ensuring that the PIL and FOP components are compatible. If the intent is to use the PIL-FOP negotiation protocol, then both devices shall support the protocol. A device that is capable of operating only as a PIL and not also as a single-port PHY shall not be connected to a user-accessible socket.
18.2.3 PIL-FOP restore Either the PIL or FOP may initiate an exit from standby by sending a training sequence. When training is complete, the FOP arbitrates for and wins control of the serial bus and then sends a restore packet to the PIL. This packet contains the phy_ID for the PIL and FOP, the current setting of the root (R) bit, the current gap count, the gap count sticky bit, and an indication of whether a bus reset has occurred since the interface was in standby. If no port is in the Active or Standby state when the FOP sends the restore packet, then the R bit is set to 1, the gap count reset disable (T) bit is set to 0, the phy_ID is set to 0, the gap count is set to 63, the asynchronous phase (A) bit is set to 0, and the reset notify (N) bit is set to 1. If a port on the FOP is in the Standby state when the restore packet is sent, the FOP shall use the previously received values for phy_ID, T, A, N, and gap count. If the FOP is root, then the R bit of the restore packet is set to 1.
18.2.4 Port restore A port on a FOP may be restored due to action of the PIL or of the uncle. If the PIL-FOP interface is active, the PIL may initiate the restore process by sending anything other than a NONE_* asynchronous request or isochronous request. When the FOP receives the request, it responds by sending a Restore_Notify P2P packet to the PIL and starts the restore process on the port in standby. When the PIL receives the Restore_Notify P2P packet, it should withdraw the request (i.e., start sending NONE requests) until the FOP sends a restore packet or until the FOP sends a serial bus reset. When the FOP competes the Restore operation, it receives a restore packet from the uncle that is forwarded to the PIL. The uncle may initiate the restore operation to the FOP with the PIL-FOP interface active, in standby, or off. If the interface is in standby or off, then no indication is sent to the PIL unless the Int_Enable bit in the FOP is set to 1. If Int_Enable is set, the FOP asserts LinkOn. Additionally, if the interface is in standby, the FOP sends a training sequence. If the PIL-FOP interface is active when the resume sequence starts, the FOP sends a Restore_Notify P2P packet. When the uncle sends the restore packet to complete the restore sequence, the PIL-FOP interface may or may not be active at that time. If it is active, then the restore packet is repeated to the PIL. Otherwise, the initialization of the PIL-FOP interface completes as described in 18.2.3.
18.2.5 Loss of synchronization If either the PIL or FOP loses synchronization, it does not return to the P0: Disconnected state; and no bus reset is generated. Instead, it transitions to the P10: Restoring state and retrains. When either the PIL or FOP detects the training sequence, it transitions to the P10: Restoring state.
18.2.6 Loss of power When either the PIL or FOP loses power or experiences any other condition that causes it to lose state, the device shall place its port in the P0: Disconnected state and shall not tone for at least 12 toning intervals.
Copyright © 2008 IEEE. All rights reserved.
535
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
This period of time with no bus activity ensures that the other device has placed itself in the P0: Disconnected state.
18.2.7 LPS The logical equivalent of active LPS from the PIL to the FOP is when the PIL-FOP interface is not in the P0: Disconnected or P9: Standby state. When LPS, or its logical equivalent in the PIL, goes inactive, the PIL becomes a standby initiator and sends a STANDBY configuration request to the FOP. The PIL and FOP then transitions to the P9: Standby state. When logical LPS goes active in the PIL, the PIL initiates the restore process as described in 18.2.3.
18.2.8 Serial bus reset When a reset is signaled on the serial bus, the PIL shall reset its asynchronous phase to 0 and shall not make any request until the completion of the self-identify phase of the bus. The PIL does not participate in the tree identify or self-identify phases following a serial bus reset. During the self-identify phase, when the FOP gains control of the bus to send its self-ID packets, the FOP holds the serial bus while it sends an unsolicited register 0 P2P packet to the PIL. The FOP shall then send its self-ID packets to all active ports and to the PIL.
18.3 Serial bus configuration request types not carried over the PIL-FOP interface The following configuration requests types are not sent on the PIL-FOP interface by either the PIL or the FOP: a)
CHILD_NOTIFY
b)
IDENT_DONE
c)
PARENT_NOTIFY
d)
DISABLE_NOTIFY
e)
SUSPEND
The ATTACH_REQUEST control token is not carried over the PIL-FOP interface; however, the ARB_CONTEXT token, which uses the same coding, is sent on the interface when required. The STANDBY configuration request is sent only by the PIL to the FOP and never from the FOP to the PIL.
18.4 P2P packet protocol This subclause defines a new P2P packet type that is used only on the PIL-FOP interface (see Figure 18-2). This new packet type carries the information that is sent on the LReq and PInt lines of the PHY-link interface described in the Clause 15. The information sent in these packets includes the read and write operation of FOP registers and includes interrupt notifications from the FOP. The characteristics of this P2P packet are as follows: a)
The packet may be started anytime an arbitration request type is allowed to be sent on the serial interface;
b)
The packet can be interrupted at any point if a received packet needs to be communicated; and
c)
The packet can be easily distinguished from any other serial bus communication.
536
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
SERIAL BUS
......
any
PP1
PP2
PACKET PREFIX
D1
D2*
DE
DATA BYTE 1 and 2
DE
any
......
DATA END
*presence of D2 depends on value of D1
Figure 18-2—P2P packet format At any point, this packet format may be interrupted by any Data_Prefix or Speed control symbols that indicate the start of a serial bus packet. If the P2P packet is interrupted before the first DATA_END control character is sent, it is retransmitted by the FOP or PIL at its next opportunity. If the packet is interrupted before the first DATA_END is received, then the packet is discarded by the recipient. If a first DATA_END is received, then the packet is not discarded. PP1 and PP2 are PIL-FOP requests types (see 13.2.5.1). They are encoded as shown in Table 18-1.
Table 18-1—Packet prefix Data Byte 1 encoding Request type
Encoding
PP1
00011xx1
PP2
00111xx1
The format of Data Byte 1 is given in Table 18-2.
Table 18-2—Data Byte 1 encoding Data Byte 1[0:7]
Meaning
0000xxxx
No operation. Data Byte 2 is not sent.
0001aaaa
FOP register write operation. Data Byte 2 contains the value to write to FOP register aaaa.
0010aaaa
FOP register read operation from FOP register aaaa. Data Byte 2 is not sent.
0011aaaa
Unsolicited FOP register read that returns the value of a FOP register without a register read operation from the PIL. Data Byte 2 contains data from FOP register aaaa.
0100aaaa
Solicited FOP register read that returns the contents of FOP register aaaa. Data Byte 2 contains the register data.
0101i3i2i1i0
FOP interrupt notification. Interrupt bits i3i2i1i0 are encoded as in Table 18-3. Data Byte 2 is not sent.
0110xxxx
Cycle start due. If the enab_accel bit is set in the FOP, then the PIL sends this notification once every isochronous period after the local clock in the PIL indicates the start of an new isochronous period. Data Byte 2 is not sent.
0111xxxx
Restore_Notify. This is sent when the PIL-FOP connection is active and the FOP begins to restore a connection as a nephew. Data Byte 2 is not sent.
10000000 – 11111111
Reserved.
Copyright © 2008 IEEE. All rights reserved.
537
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 18-3—Interrupt encoding Interrupt bit
538
Interrupt meaning
i0
PHY_INTERRUPT
i1
Reserved
i2
Reserved
i3
Reserved
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
19. PHY C code This clause contains the C code specifying the operation of the PHY, including the port state machines and the arbitration state machine.
19.1 Common declarations and functions Table 19-1 through Table 19-3 list the C code declarations and common functions used in the detailed operational descriptions.
Table 19-1—C code definitions // 1394.h - declarations to allow compilation of the C code #define fork #define join typedef typedef typedef typedef
// fork removed from compiled C code // join removed from compiled C code
unsigned long quadlet; unsigned char byte; unsigned long eventVar; int dataBit;
// event type, allows 32 events
void signal(int event); // Sets event status to the value specified eventVar waitEvent(eventVar event_mask); // Await the indicated event(s), return events signaled void waitTime(float time); void waitPosEdge(int clock); void waitNegEdge(int clock); // C code assumes that the phase relationships of the clocks is constant #define PH_BIT_CLOCK #define PH_DS_BIT_CLOCK
0x20000000 0x40000000
// derived from PHY_SPEED // derived from DS_PHY_SPEED
Table 19-2—Data structures and enumerated types // data_structures.h #define BASE_RATE 98.304
// units of Mbits/sec
// constants used in the main arbitration state machine enum legacyWaitTimes {
// set to values corresponding to the tables in text, // in legacyTime units (2/BASE_RATE)
SPEED_SIGNAL_LENGTH = 5, DATA_PREFIX_HOLD = 2, DATA_END_TIME = 12, MIN_IDLE_TIME = 2, CONCATENATION_PREFIX_TIME = 8, MIN_DELETABLE_SYMBOL_TIME = 2}; enum waitTimes { // set to values corresponding to the tables in text, scaled to seconds SHORT_RESET_TIME, RESET_TIME, RESET_WAIT, ROOT_CONTEND_SLOW, ROOT_CONTEND_FAST, LONG_ROOT_CONTEND_SLOW, LONG_ROOT_CONTEND_FAST, FORCE_ROOT_TIMEOUT, CONFIG_TIMEOUT, CM_MIN_IDLE_TIME, MAX_ARB_STATE_TIME}; enum betaTimes {BOSS_RESTART_TIME, LONG_BOSS_RESTART_TIME};
Copyright © 2008 IEEE. All rights reserved.
539
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-2—Data structures and enumerated types (continued) #define TMODE_SYMBOL_JITTER 9 from insertion
// number of 10-bit “no symbol” symbol times resulting // of 8-bit idles between data bursts on 802.3 Clause 40 encoding
// constant used in background processing enum backgroundBetaTimes {MAX_BETA_TIME}; // constants used in node-level connection management - times are given in Table 11-3 enum nodeWaitTimes {BIAS_FILTER_TIME, BIAS_LOSS_FILTER_TIME}; // BIAS_LOSS_FILTER_TIME is not a 1394 constant, recommend 200-300ns for bias loss // filtering, see 4.4.4, but experience says that a bigger value is required (1-2 usec?). // Note that the RC constant to decay will be // somewhere between 1.5 usec and 6 usec depending on the peer cap value, so this will // double the latency to detect loss of bias // Note also that loss of bias will not, in general, be detected while the local TPB drivers are // enabled, and also the time taken to discharge the local cap will take typically up to 2 usec // (depends on local analog design and TpBias level at time of disconnection). // So loss of bias will only be detected after an arb gap has been on the bus for 2usec. // Min arb reset gap is not much longer than this. So there is not enough time to guarantee this, // In general we’ll have to rely on longer arb gaps occurring (either because of large gapCount // or because of no traffic on the bus) enum betaNodeWaitTimes {TEST_INTERVAL}; // constants used in port-level connection management - times are given in Table 11-3 enum port_wait_times {DISCONNECTED_TONE_INTERVAL, TONE_DURATION, SPEEDCODE_BIT_INTERVAL, RECEIVER_INIT_TIME, RESET_DETECT, CONNECT_TIMEOUT, RECEIVE_OK_HANDSHAKE, PORT_ENABLE_TIME, MAX_OCCUPANCY_TIME, TPORT_SUSPEND_HANDSHAKE, TMODE_DISCONNECT_TIMEOUT, TPORT_MAX_LATENCY, TPORT_MIN_SUSPEND_TIME}; #define TONE_GAP 8 #define TONE_INTERVAL 16 #define NUM_OF_TRIES 4 #define RESUME_CHECKS 73 #define SYNCHRONIZATION_LENGTH 16384 #define TMODE_RESUME_CHECKS ((GMII_LINK_PULSE_INTERVAL/10)+1) // number of pulse times per interval // data structures typedef enum { S100 = 0, S200 = 1, S400 = 2, S800 = 3, S1600 = 4, S3200 = 5, NO_SPEED = 6, DEFAULT = 7} speedCode; typedef enum { // Types of bus requests made by link across PHY/link interface // the boolean “immediateRequest” replaces use of IMMED_REQ NO_REQ, ISOCH_REQ, PRIORITY_REQ, FAIR_REQ} breqType; typedef enum { // Tracks the PHY state (names per state diagrams) R0, R1, T0, T1, T2, T3, S0, S1, S2, S3, S4, A0, A1, A2, RX, TX, PH} phyStateType; typedef enum {P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12, P13} portStateType; typedef enum {L, H} tpSig; // Differential signal on twisted pair typedef enum {GND, BIAS_ON, ZZ} tpBiasSig; typedef struct {tpSig tpA; tpSig tpB;} portData; // Port data structure typedef enum {RX_IDLE = 0, RX_PARENT_NOTIFY = 1, RX_REQUEST_CANCEL = 1, RX_IDENT_DONE = 2, RX_SELF_ID_GRANT = 3, RX_REQUEST = 3,
540
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-2—Data structures and enumerated types (continued) RX_ROOT_CONTENTION = 4, RX_GRANT = 4, RX_SUSPEND = 4, RX_PARENT_HANDSHAKE = 5, RX_DATA_END = 5, RX_CHILD_HANDSHAKE = 6, RX_DISABLE_NOTIFY = 6, RX_DATA_PREFIX = 7, RX_BUS_RESET = 8} rxArbState; typedef enum {TX_IDLE = 0, TX_REQUEST = 1, TX_GRANT = 1, TX_DISABLE_NOTIFY = 2, TX_PARENT_NOTIFY = 3, TX_SUSPEND = 4, TX_DATA_PREFIX = 5, TX_CHILD_NOTIFY = 6, TX_IDENT_DONE = 6, TX_DATA_END = 7, TX_BUS_RESET = 8} txArbState; typedef struct {rxArbState rxArb; portData data;} rxSignal; typedef enum {LTP_TEST = 0, ATTACH_IN_PROGRESS = 1} ltpModeType; #define COLLISION_LIMIT 7 typedef enum {B_LINK, LEGACY_Link} linkType; typedef enum {GRANT_SENIOR, GRANT_LINK, GRANT_NULL, GRANT_JUNIOR, BOSS_MANAGEMENT_ACTIONS} bossEopStatus; // CTRL, CONFIG_REQUEST and INVALID are used internally within the port machines // DATA, ARB_STATE and LEGACY_ARB are used for communicating to the arb state machine // DS_RAW_ARB is used to pass the overloaded received legacy arb states to the process_request block // for filtering based on the current PHY state typedef enum { DATA, CTRL, ARB_REQUEST, CONFIG_REQUEST, INVALID, ARB_STATE, DS_RAW_ARB, LEGACY_ARB} portTag; typedef enum { LEGACY, BETA, UNSPECIFIED } pktType; typedef enum { // first the arb-states corresponding to CTRL symbols // SPEEDa, SPEEDb and SPEEDc are used only internally in the port CYCLE_START_EVEN = 1, CYCLE_START_ODD = 2, ATTACH_REQUEST = 3, ARB_CONTEXT = 3, SPEEDa = 4, DATA_END = 5, DATA_NULL = 6, SPEEDb = 7, // note GRANT and SELF_ID_GRANT are the same code GRANT = 8, SELF_ID_GRANT = 8, DATA_PREFIX = 9, GRANT_ISOCH = 10, SPEEDc = 11, ASYNC_EVEN = 12, ASYNC_ODD = 13, BUS_RESET = 14, IDLE = 15, SPEED = 16, SPEED_RAW = 17, // then the arb-states corresponding to CONFIG_REQUEST symbols // note, CHILD_NOTIFY, PARENT_HANDSHAKE and IDENT_DONE are the same code // note TRAINING is the lowest value of these enum types TRAINING = 18, STANDBY = 19, CHILD_NOTIFY = 20, IDENT_DONE = 20, PARENT_HANDSHAKE = 20, // note PARENT_NOTIFY and ROOT_CONTENTION are the same code PARENT_NOTIFY = 21, ROOT_CONTENTION = 21, DISABLE_NOTIFY = 22, SUSPEND = 23, OPERATION = 24, CHILD_HANDSHAKE = 25, REQUEST_CANCEL = 26, LEGACY_REQUEST = 27, LEGACY_PHASE = 28, // DATA_BYTE is only used in the arb state machine DATA_BYTE = 29, // used in the T_port state machine SKIP_INVALID = 30, COUNT_INVALID = 31 } arbState; // encode the two types of priority as two nibbles, high order for odd phase typedef enum { A_NONE = 0, NONE_ODD = 0x13, NEXT_EVEN = 0x25, NONE_EVEN = 0x31, CURRENT = 0x44, NEXT_ODD = 0x52, CYCLE_START_REQ = 0x66, BORDER = 0x77} asyncReqType;
Copyright © 2008 IEEE. All rights reserved.
541
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-2—Data structures and enumerated types (continued) typedef enum { I_NONE = 0, ISOCH_NONE = 0x11, ISOCH_ODD = 0x42, ISOCH_EVEN = 0x24, ISOCH_IN_PHASE = 0x33, ISOCH_CURRENT = 0x55} isochReqType; // Note, ISOCH_IN_PHASE is defined for simple comparisons to determine // if a particular request is for the current phase. Is does not appear // on the serial bus typedef enum { NEGATIVE_RD = 0, POSITIVE_RD = 1
} disparityType;
// Tport symbol position state typedef enum {A, B, C, D } symbolPosition; typedef struct { asyncReqType async; isochReqType isoch; } betaRequestCode; typedef struct { portTag tag; arbState arb; ARB_STATE union { byte data; rxArbState rxDSArb; betaRequestCode req; in the port) }; speedCode speed; pktType pkt; } portSymbol;
// This type holds any port symbol // The type of symbol // valid if tag is CTRL, CONFIG_REQUEST, LEGACY_ARB or // // // //
symbol data DATA or LEGACY_ARB DS_RAW_ARB ARB_REQUEST (only used internally
// the effective speed at which the current info is to be sent // valid if arb is SPEED
typedef struct { union { byte dataBytes[8]; struct { union { quadlet dataQuadlet; struct { quadlet phyPacketType:2; quadlet phy_ID:6; quadlet :1; quadlet L:1; quadlet gapCnt:6; quadlet sp:2; quadlet brdg:2; quadlet c:1; quadlet pwr:3; quadlet p0:2; quadlet p1:2; quadlet p2:2; quadlet i:1; quadlet m:1; } ; struct { quadlet :8; quadlet ext:1; quadlet n:3; quadlet :2;
542
This part holds valid if tag is valid if tag is valid if tag is
// First self_ID packet // Physical_ID // Always 0 for first self_ID packet // Link active // Gap count // Speed code // Bridge field for use by 1394.1 // IRM contender // Power class // Port 0 connection status // Port 1 connection status // Port 2 connection status // Initiated reset // More self_ID packets... //self_ID_first // Subsequent self_ID packets // Nonzero for second and subsequent self_ID packets // Sequence number
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-2—Data structures and enumerated types (continued) quadlet pa:2; // Port connection status... quadlet pb:2; // pa pb pc pd pe pf pg ph quadlet pc:2; // self_ID packet 2 P3 P4 P5 P6 P7 P8 P9 P10 quadlet pd:2; // self_ID packet 3 P11 P12 P13 P14 P15 --- --- --quadlet pe:2; quadlet pf:2; quadlet pg:2; quadlet ph:2; quadlet :2; } ; // self_ID; struct { // PHY configuration packet, also used as restore packet quadlet :2; quadlet root_ID:6; // Intended root quadlet R:1; // If set, root_ID field is valid quadlet T:1; // If set, gapCnt field is valid quadlet gapCount:6; // Gap count union { struct { // for a restore packet quadlet:8; quadlet notifyLegacySpeed:2; quadlet notifyBNodeRoot:1; quadlet notifyBBus:1; quadlet Q:1; quadlet P:1; quadlet notifyOddAsyncPhase:1; quadlet notifyReset:1; }; quadlet :16; }; } ; // phy_config; struct { // Extended PHY packets (ping and other remote packets) quadlet :2; quadlet :6; // Physical_ID quadlet :2; // Always 0, identifies Exended PHY packet quadlet extType:4; // Extended type union { struct { union { quadlet page:3; // Page_select quadlet eCmnd:3; // Extended command }; quadlet portNum:4; // Port_select union { struct { quadlet reg:3; // Register address (add 0b1000 if paged register) quadlet data:8; // Register data (remote reply) }; struct { // Remote confirmation quadlet :2; quadlet standbyFault:1; // Copies of equivalent PHY register bits... quadlet fault:1; quadlet connected:1; quadlet bias:1; quadlet disabled:1; quadlet ok:1; // Confirm command accepted or not quadlet cmnd:3; // Remote command } ; // remote_cnfrm;
Copyright © 2008 IEEE. All rights reserved.
543
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-2—Data structures and enumerated types (continued) }; }; struct { quadlet quadlet quadlet quadlet };
// fields for LTP :10; mode:1; G:1; testValue:6;
}; } ;
// LTP mode // Generation number // LTP comparison value
// ext_phy;
}; quadlet checkQuadlet; }; }; } PHY_pkt; typedef struct { int TXD; int TX_EN; int TX_ER; int GTX_CLK; int COL; int int int int
RXD; RX_ER; RX_CLK; RX_DV;
int CRS; } gmiiType; int GTX_REF_CLK;
// Clock for transmitting on the GMII - 125 MHz
// implementation dependent constants #define POWER_CLASS 0x0 // IMPLEMENTATION DEPENDENT #define NPORT 4 #define ENABLE_STANDBY_DEFAULT 0
// number of ports - IMPLEMENTATION DEPENDENT // IMPLEMENTATION DEPENDENT
#define PHY_SPEED S800 #define DS_PHY_SPEED S400
// PHY speed - IMPLEMENTATION DEPENDENT // PHY speed for DS ports - IMPLEMENTATION DEPENDENT
const speedCode dsPortSpeed[NPORT]; DEPENDENT
// Speed of each DS capable port - IMPLEMENTATION
544
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-3—PHY services // phy_services.h // PMD services which apply on a per-port basis, the port is implicit // as these are referenced from the per-port code (except for bias_detect) typedef enum { PMD_CROSSOVER, PMD_NO_CROSSOVER, PMD_TONE_ON, PMD_TONE_OFF,
PMD_SELECT_BPORT, PMD_SELECT_DS_PORT, signals
// instructs the PMD to generate a tone (see 6.8.1) // instructs the PMD to cease generating a tone, // remove the signalling bias voltage and set the // port transmitters to high impedance // PMD uses bport for beta mode I/O - only set while // bportOn is TRUE, unset during suspend etc // PMD uses dsport for data, arb states and speed // remains set during suspend etc // note, this does not affect use of bias or dc connect
PMD_UNSELECT_PORT, // T-mode specific PMD_START_NEGOTIATE, autonegotiation PMD_SELECT_TPORT, PMD_DISCONNECT_TPORT, PMD_TPORT_OFF
// instructs the PMD to perform T-mode/Ethernet // PMD uses bport for t mode I/O - only set while // tportOn is TRUE, unset during suspend etc // Stops 802.3 Clause 40 PHY operating as a Tport PHY. // Clears operating mode status bits //
} pmdControlRequestType; void PMD_CONTROL_request(pmdControlRequestType control_request, speedCode speed);
// PMD status flags - one set per port #define PMD_BIAS_DETECT 0x00000001 // undebounced output of the PMD bias comparator #define PMD_CONNECT_DETECT 0x00000002 // undebounced PMD output of connect_detect comparator #define PMD_LOCAL_PLUG_PRESENT 0x00000004 // When ac coupled (possibly via, say, an optical transceiver) // indicates that an external implementation dependent mechanism has determined that // there is at least a physical connection from the local node to a cable // (although there may not be a connection to the peer port). Used to avoid // performing connection toning if there is definitely no connection. If there // is no such mechanism, then this flag shall be set permanently to TRUE. // This is a read-only bit in the port register map. #define PMD_SIGNAL_DETECT 0x00000008 // set by PMD if a valid signal is being received #define PMD_AUTOCROSSOVER_SUPPORTED 0x00000010 // Implementation dependent. Set by hardware. // When true, indicates that the implementation supports crossover function // (transmit on TPA, receive and signal detect on TPB). // Only required to be true for ports which support UTP-5.
Copyright © 2008 IEEE. All rights reserved.
545
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-3—PHY services (continued) // T-mode #define PMD_NEGOTIATION_ACTIVE 0x00000080 #define PMD_TPORT_FW 0x00000100 // autonegotiation has established FW mode #define PMD_TPORT_802 0x00000200 // autonegotiation has established GE mode #define PMD_TPORT_OK 0x00000400 // 802.3 Clause 40 connection is synchronized (FW mode only) #ifdef unsubscripted eventVar PMD_STATUS_request(); #else eventVar PMD_STATUS_request(int i); #endif
// returns bit map of the above
// Beta PMD typedef struct { dataBit data; } pmdDataIndicationService; // for data from PMD pmdDataIndicationService waitPMD_DATA_indication(); void PMD_DATA_request(dataBit data); speedCode PMD_CABLE_SPEED_request(); // Set by implementation-dependent means to the maximum speed // at which the cable attached to the port is allowed to operate. If no // cable-dependent speed indication is available, then the implementation // shall return the maximum speed that the port is capable of. // The encoding is the same as maxPortSpeed. This value is also // maintained as a read-only register in the port register map. // DS PMD rxSignal PMD_DSPORT_SIGNAL_request(); // Return current signal from port // DS PMD speed event flags #define RX_S200 0x00000001 #define RX_S400 0x00000002 eventVar PMD_DSPORT_RXSPEED_request(); void PMD_DSPORT_DATA_request(portData pd); // Transmit the data/strobe encoded data on the DS port void PMD_DSPORT_ARB_request(txArbState arb); // Transmit the specified arbitration state on the DS port void PMD_DSPORT_TXSPEED_request(speedCode speed); // Transmit the specified analog speed signal on the // DS port void PMD_DSPORT_TPBIAS_request(tpBiasSig sig); // sig = BIAS_ON instructs the PMD to generate TpBias on TPA // (as defined in 9.2) // sig = GND instructs the PMD to drive the common mode voltage on TPA to VG // sig = ZZ instructs the PMD to cease generating TpBias and set TPA to high impedance // PHY level PMD service boolean PMD_PS_request();
// TRUE if cable power active // value is maintained in Register 0
// Link typedef enum {
546
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-3—PHY services (continued) PH_IMMED_REQ=1, PH_NEXT_EVEN=2, PH_NEXT_ODD=3, PH_CURRENT=4, PH_ISOCH_REQ_EVEN=6, PH_ISOCH_REQ_ODD=7, PH_CYC_START_REQ=8, PH_LPS_ACTIVE=10, PH_LPS_INACTIVE=11, PH_ISOCH_PHASE_ODD=12, PH_ISOCH_PHASE_EVEN=13, PH_CYCLE_START_DUE=14, PH_CYCLE_START_SEEN=16, PH_ISOCH_REQ=17, PH_PRIORITY_REQ=18, PH_FAIR_REQ=19 } phyArbReqType; typedef struct { phyArbReqType reqType; speedCode speed; boolean betaFormat; } PhyArbReqService;
// request signal from link // The type of request // speed of request, valid if reqType is PH_IMMED_REQ, // PH_CURRENT, PH_NEXT, PH_CYC_START_REQ, PH_ISOCH_REQ // Set true when the link selected Beta-Only
PhyArbReqService waitPH_ARB_request(); typedef enum { PH_REQ_DATA, PH_REQ_DATA_PREFIX, PH_REQ_DATA_END, PH_REQ_SUBACTION_END, PH_REQ_HOLD } phyDataReqType; typedef struct { phyDataReqType reqType; union { byte data; speedCode speed; concatenated packets }; } phyDataReqService;
// data from link
// valid if reqType is PH_REQ_DATA // valid if reqType is PH_REQ_DATA_PREFIX for
phyDataReqService waitPH_DATA_request(); typedef enum {PH_WON, PH_LOST, PH_WON_IMMED, PH_WON_ISOCH, PH_WON_CYCLE_START, PH_WON_ASYNC} phyArbConfirmations; void PH_ARB_confirmation(phyArbConfirmations confirmation, speedCode speed, pktType pkt_format); typedef enum {PH_DATA_START, PH_DATA_BYTE, PH_DATA_PREFIX, PH_DATA_END, PH_SUBACTION_GAP, PH_ARBITRATION_RESET_GAP, PH_ARB_RESET_ODD, PH_ARB_RESET_EVEN, PH_ISOCH_ODD, PH_ISOCH_EVEN} phyDataIndications; void PH_DATA_indication(phyDataIndications indication, speedCode speed, byte data, pktType pkt_format);
Copyright © 2008 IEEE. All rights reserved.
547
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-3—PHY services (continued) typedef enum {PH_LINK_ON, PH_BUS_RESET_START, PH_SELF_IDENTITY, PH_BUS_RESET_COMPLETE, PH_INTERRUPT, PH_CABLE_POWER_FAIL, PH_CONFIG_TIMEOUT, PH_RESTORE_RESET, PH_RESTORE_NO_RESET, PH_MAX_ARB_STATE_TIMEOUT} phyEventIndications; void PH_EVENT_indication(phyEventIndications indication, int physical_ID, boolean root); void waitPH_EVENT_response(); void PH_CLOCK_indication(); linkType PH_LINK_TYPE_response();
The variables that are used internally within one file only are declared at the head of that file. Variables that are used only within the main arbitration state machine are defined in Table 19-4
Table 19-4—Arbitration state machine internal variables // arb.h - arbitration code declarations // // // //
variables used in the main arbitration state machine beta_arb_functions.c, decodePhyPacket.c, ds_arb_functions.c, grantActions.c idleActions.c, receiveActions.c, receive_functions.c, reset.c, selfid.c, transmitActions.c, transmit_functions.c, treeid.c
boolean ack; boolean allChildPortsIdentified; int arbDelay; boolean arbEnable; subaction gap boolean arbOk; int arbResetGap; timer arbTimer; boolean arbTimerMax; arbitration
// // // //
Set if last packet observed Set if all child ports have Arbitration delay time (4 * Set if a node may arbitrate
// // // // //
TRUE when legacy arbitration permitted Duration of an arbitration reset gap ((52 + 32 * gapCount) / BASE_RATE) Timer for arbitration state machines Set true when arb timer has first reached maximum
// time in A0:Idle.
was exactly 8 bits been identified gapCount / BASE_RATE) upon detection of a
Allows arbTimer to be reused for
token recovery // without falsely disabling arbitration in a new fairness interval int bridge; boolean betaPortRequest; boolean child_ID_complete[NPORT]; boolean child[NPORT]; int children; boolean concatenatedPacket; int contendTime; boolean contender; boolean convertedRequest; request into pktType currentFormat; speedCode currentSpeed; boolean dataNullPacket; not contain DP boolean deferGrant; proxyRoot
548
// Two-bit field in PHY register map // TRUE if there’s a request on a port to be granted
// // // // //
Number of child ports TRUE if a concatenated packet is being received Amount of time to wait during root contention Single-bit field in PHY register map TRUE if a request has been converted from a Beta
// a legacy request in order to be forwarded on a DS port // format for the packet currently being transmitted // Current packet speed // TRUE if the packet starts with DATA_NULL and does // or data // TRUE if the end of a subaction was detected, but the
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-4—Arbitration state machine internal variables (continued) // will temporarily defer issuing a grant in Idle to a beta request // to allow a legacy link timer to make a bus request for a cycle // start packet boolean enabAccel; boolean endOfPacket; boolean flyByOk; boolean forceRoot; boolean formatCommitted; (repeated) boolean fromA0; boolean goodPhyPacket; boolean grantSelf; arbState grantToGive; to issue boolean idleReceivePort; boolean initiatedReset; int lctrl; boolean legacyJuniorRequest; junior port boolean linkConcatenation; packet boolean loop; int lowestUnidentifiedChild; self_ID boolean okToGrant; only in the
// Set when reception of packet is complete // TRUE when fly-by concatenation permitted // Set to delay start of tree identify process for this node // TRUE if format of received packet has been committed // // // //
TRUE when A2 is entered from A0 TRUE if received packet is a good PHY packet TRUE if can grant to self Specifies which grant type (GRANT or GRANT_ISOCH)
// in grantActions // TRUE to simulate idle after sending proxy self_ID
// TRUE when a LEGACY_REQUEST has been received from a // TRUE if a legacy link intends to transmit a concatenated // TRUE if config timeout occurs while in T0. Reported in the // PHY register map and cleared by software // Lowest numbered active child that has not sent its // TRUE if a request can be granted when in Idle (valid // proxyRoot). Gap times may need to be respected // and so PHY cannot always grant a favorite request
instantaneously boolean ownRequest; evaluated int parentPort; boolean phyResponse; be transmitted boolean pingResponse; boolean receivedSpeedSignal; received int requestingPort; standards) int resetDuration; boolean resolveCollisionRequest; int rootContendCount; PHY_pkt self_ID_pkt; boolean sendNullPacket;
boolean sendingTokens; boolean speedOk[NPORT]; int standby_c[NPORT]; int standby_L[NPORT];
Copyright © 2008 IEEE. All rights reserved.
// Latch the value of arbPermitted() at the time it is
// TRUE to indicate that a PHY response packet is to // Set if self_ID packet(s) needed in response to a ping // TRUE if saw a speed signal in the packet (being) // Lowest numbered requesting port (child in legacy // Duration to assert bus reset signal // set to make a legacy ISO priority request to keep the // bus busy and send a null packet // count of the number of times phy enters T3 in a single // tree identify phase // temporary storage during self_ID // TRUE when boss needs to send a null packet in order to // terminate cleanly a DATA_PREFIX which is being sent on DS // ports during Beta packet transmissions
// restored from standby
549
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-4—Arbitration state machine internal variables (continued) int standby_NPORT[NPORT]; // NPORT for the nephew PHY int standbyPacketCount[NPORT]; int standbyParent[NPORT]; int standby_pwr[NPORT]; #define STORES_GAP_COUNT TRUE // a B only PHY may implement this FALSE #define USE_LONG_BOSS_RESTART_TIME TRUE // strap option or PHY design parameter - must be // set TRUE for large diameter networks int subactionGap; // Duration of a subaction gap ((28 + 16 * gapCount) / BASE_RATE) timer timeOutOfIdle; // timer to ensure one symbol on every port after exit from idle boolean timeout; // PHY register flag, set to 1 on maxArbStateTimeout
Variables that are shared between the architectural elements are defined in Table 19-5. Each grouping of architectural elements lists the variables shared by that grouping
Table 19-5—Variables shared between architectural elements // shared.h - shared variables and constants // shared between bport_tx.c and bport_rx.c int commaTable[2]; int controlTable[16]; characters
// table of K28.5 characters (see table 10-8) // table mapping scrambled control values to control // (see table 10-9) // table of data characters (see table 10-7)
int dataTable[256][2]; #ifdef unsubscripted boolean syncErrorSignal; synchronization boolean syncLostSignal; #else boolean syncErrorSignal[NPORT]; boolean syncLostSignal[NPORT]; #endif
// receiver error monitor has detected loss of // receiver is in a resynchronization state
// shared between tport_tx.c and tport_rx.c #ifdef unsubscripted gmiiType gmii; #else gmiiType gmii[NPORT]; #endif
// TPORT data transfer interface
// shared between speed.c and dsport_rx.c speedCode dsPortRSpeed;
// Filtered and latched receive speed for indicated port
// shared between port.c for all ports timer connectTimer;
// Timer for connection status monitor
// shared between port.c and node.c #ifdef unsubscripted const boolean BETA_MODE_ONLY_PORT; indicate
// TRUE if the port does not support DS mode, used to // functions which may be omitted on Beta-only port
implementations
550
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-5—Variables shared between architectural elements (continued) const boolean T_MODE_CAPABLE_PORT; const boolean T_MODE_ONLY_PORT; but is boolean forceDisconnect;
boolean inStandby; boolean portUnderTest; portStateType portState; boolean rxOk; TpBias signal
// TRUE if the port is capable of operating in tMode // TRUE if the port is not capable of Betamode S100 UTP // Tmode_capable // if a restore attempt fails, set true in P10 to force // connectionStatus to cause a disconnection // also if a loop in a legacy cloud is detected // Port is in State P9:Standby or P10:Restore // port currently being tested to ensure no loop // In DS mode indicates the reception of a debounced
// In Beta mode, indicates synchronization with the peer port boolean sendingTone; // true whilst a tone is being transmitted boolean untested; // port is connected but untested #else const boolean BETA_MODE_ONLY_PORT[NPORT]; const boolean T_MODE_CAPABLE_PORT[NPORT]; boolean forceDisconnect[NPORT]; boolean inStandby[NPORT]; boolean portUnderTest[NPORT]; portStateType portState[NPORT]; boolean rxOk[NPORT]; boolean sendingTone[NPORT]; boolean untested[NPORT]; #endif boolean allPortsSuspended; boolean foundLoop;
// TRUE if suspended ports > 0 and active ports == 0 // Flag used by the loop tester to force the tested port into // the Loop Disabled state
// shared between port.c, node.c and bport_rx.c #ifdef unsubscripted boolean untestedState; #else boolean untestedState[NPORT]; #endif
// port is in state P11:Untested
// shared between port.c, node.c and bport_tx.c #ifdef unsubscripted boolean bportSyncOk; Management
// Port machine sets this to indicate to Connection // that a port has achieved synchronization with peer port.
#else boolean bportSyncOk[NPORT]; #endif // shared between port.c, bport_rx.c and bport_tx.c #ifdef unsubscripted boolean bportOn; operating
// Set to true to instruct the Beta port to commence // Set to false to instruct the Beta port to cease operating
#else boolean bportOn[NPORT]; #endif
Copyright © 2008 IEEE. All rights reserved.
551
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-5—Variables shared between architectural elements (continued) // shared between port.c, tport_rx.c and tport_tx.c #ifdef unsubscripted boolean tportOn;
// Set to true to instruct the T port to commence operating // Set to false to instruct the T port to cease operating
#else boolean tportOn[NPORT]; #endif // shared between port.c, dsport_rx.c and dsport_tx.c #ifdef unsubscripted boolean dsportOn;
// Set to true to instruct the DS port to commence operating // Set to false to instruct the DS port to cease operating
#else boolean dsportOn[NPORT]; #endif // shared between the main arb state machine and dsport_tx.c boolean nonNullPacket; therefore
// TRUE if current packet contains a data payload and // requires the ending sequence of a legacy packet to
include time // for dribble bits // shared between the main arb state machine and node.c int gapCount; boolean gapCountResetDisable; the maximum boolean isochConcatOk; camcorders boolean maxArbStateTimeout(); speedCode minOperatingSpeed; boolean needNewLTP; this round of boolean nephew; register map int physical_ID; int resetCount; int standbyPhy_ID[NPORT]; boolean T0_timeout; int testPort;
// If set, a bus reset will not force the gapCount to // TRUE when isoc concatenation will not upset legacy // See definition // implicitly set // min port speed // TRUE if need to
of All:R0c in Clause 13 by main arb state machine of all active Beta mode ports send a new LTP packet either during
// testing or at the start of the next round // maintained by node.c, used to ensure ibr is zero in
// count resets during this time // information to be saved in case the peer port // TRUE if Tree_ID detects a loop
// shared between the main arb state machine and port.c #ifdef unsubscripted boolean disableRequest; // Requests transmission of TX_DISABLE at the end of the next packet boolean fault; // port register map (suspendFault || resumeFault) boolean longContendTimer; // port register map - port uses long contend times boolean receiveOk; // In DS_mode indicates the reception of a debounced TpBias signal // In betaMode, indicates the reception of a continuous electrically valid signal.
552
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-5—Variables shared between architectural elements (continued) // Note, is set to false during the time that only connection tones are detected in Beta mode. // This is maintained as a read-only bit in the port register map (supersedes the Bias bit in // legacy standards). boolean resetNotify; boolean resumeFault; // Set when peer port fails to complete resume boolean standbyFault; boolean suspendFault; // Set when peer port fails to complete suspend #else boolean disableRequest[NPORT]; boolean fault[NPORT]; boolean longContendTimer[NPORT]; boolean receiveOk[NPORT]; boolean resetNotify[NPORT]; boolean resumeFault[NPORT]; boolean standbyFault[NPORT]; boolean suspendFault[NPORT]; #endif timer maxOccupancyTimer; the bus boolean okToDetectReset; BUS RESET boolean randomBool(); FALSE value boolean resumptionDone; to be done int seniorPort; boolean signaled;
// for a timeout on how long loop free build can hold // TRUE if a resuming port is permitted to monitor for // Not defined in C code - returns a random TRUE or // Resumption by at least one resuming port forces all // port number of the port pointing towards proxyRoot // Indicate transmission of TX_DISABLE_NOTIFY, TX_SUSPEND // or TX_STANDBY
// shared between the main arb state machine, port.c and bport_rx.c boolean ibr;
// Set when a long bus reset is needed
// shared between the main arb state machine, node.c and port.c #ifdef unsubscripted boolean attach; attach with the boolean connected; mode only)
// Indicates that the untested beta port is ready to // next bus reset // Connection established with a peer port, and (Beta // operating speed negotiation completed. // This is maintained as a read-only bit in the port
register map. boolean disabled; control, boolean doStandby; initiator boolean loopDisabled; port loses boolean proxy; a proxy
// PHY register bit, set to disable a port under software // and indicates that the port is in state P6:Disabled // TRUE when the port has been commanded to be a standby // Port is in State P12: Loop_disabled - set when the // synchronization during loop testing or a loop is detected // When true, instructs the arb state machine to generate // self_ID for the peer node on this port // (which can only be a leaf node).
Copyright © 2008 IEEE. All rights reserved.
553
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-5—Variables shared between architectural elements (continued) boolean resume; suspended port boolean suspendRequest; #else boolean attach[NPORT]; boolean connected[NPORT]; boolean disabled[NPORT]; boolean doStandby[NPORT]; boolean loopDisabled[NPORT]; boolean proxy[NPORT]; boolean resume[NPORT]; boolean suspendRequest[NPORT]; #endif boolean borderNode; boolean boundaryNode; int HR_G; ltpModeType HR_mode; int HR_testValue; boolean inControl; boolean releaseControl; MAX_OCCUPANCY_TIME boolean isbrOk; conditions permit boolean isolatedNode; boolean loopToDetect; boolean sendAttach; timer testIntervalTimer;
// Indicates that the port is resuming, also causes a // to resume. // Set when PHY port is requested to suspend
// TRUE if any active DS ports or legacy link // with at least one active port and at least one suspended // Generation - alternates between 0 and 1 // mode of the packet to be transmitted // test value to be transmitted // TRUE if won arbitration // TRUE to release control so as not to violate // Set when asynchronous or immediate arbitration // // // // //
an arbitrated (short) bus reset to be commenced Set if no ports active TRUE during reset up to S1 or S2 TRUE to request the port to send attach requests for a timeout on test pattern return
// shared between the main arb state machine, port.c, node.c, bport_rx.c and bport_tx.c #ifdef unsubscripted speedCode portSpeed; maxPortSpeed.
// Negotiated operating speed of the port. Encoding as // The value of Negotiated_speed in the port register
map is set to // this value. Value established on connection in betaMode, or // during self_ID when in DS mode. #else speedCode portSpeed[NPORT]; #endif // shared between the main arb state machine, port.c, node.c, speed.c and dsport_rx.c #ifdef unsubscripted boolean bias; #else boolean bias[NPORT]; #endif
// If equal to one, debounced incoming TpBias is detected.
// shared between the main arb state machine, port.c, node.c, bport_tx.c and dsport_tx.c #ifdef unsubscripted portSymbol portT; whenever
// symbol to be sent - port sends the current contents // it is ready to transmit a symbol
#else
554
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-5—Variables shared between architectural elements (continued) portSymbol portT[NPORT]; #endif // shared between the main arb state machine and process_req.c pktType aFormat; pktType aLinkFormat; speedCode aSpeed; boolean accelerating; boolean advanceOk[NPORT]; boolean arbReset; boolean asyncPending; int asyncPendingPort; (Beta) link) boolean collision[NPORT]; pktType currentPkt[NPORT]; boolean currentRequest; pktType cycStartFormat; pktType cycStartLinkFormat; speedCode cycStartSpeed; boolean cycleStartRequest; boolean didArbrst; boolean DS_stuck; on the bus boolean enableStandby; port into standby boolean filterAsyncEven; boolean filterAsyncOdd; pktType iFormat; pktType iLinkFormat; speedCode iSpeed; boolean ignorePort[NPORT];
// no imminent cycle start, so no danger of starving it // TRUE if can advance to the next arb state in the FIFO
// port for pending request (NPORT if from the local // set TRUE when there’s a colliding packet from the port // cleared when the collision is resolved by TX of a null packet // most recently read packet type from fifo for port
a packet) pktType immFormat; pktType immLinkFormat; speedCode immSpeed; boolean immediateLinkRequest; boolean immediateRequest; boolean isoCycle; boolean tooLateForIsoch; boolean isochEvenRequest; boolean isochOddRequest; boolean isochPending; int isochPendingPort; (Beta) link) boolean legacyPhaseExpected; int legacyRequestPhase; boolean linkCsIndications; or decelerate
// TRUE if cycle start request from link // TRUE if already did arb reset, set false on async packet // TRUE if there might be a DS port stuck in DP somewhere // PHY reg map flag, TRUE to allow a nephew to put a
// information about the current link request; // TRUE if temporarily ignoring a packet from a port due to // a collision (packet received while already receiving
// TRUE if immediate request from link // TRUE if immediate request from either PHY or link // TRUE if the bus is in the isochronous period // TRUE if PHY already in async interval before link tells // PHY about isoch
// port for pending request (NPORT if from the local // TRUE if seen DE or GRANT on legacy format packet // stores current legacy request phase // TRUE if link gives indications of cycle start due // (legacy link) - set to FALSE on PHY/Link interface
reset or disable timer maxBetaTimer; boolean LPS_pin;
Copyright © 2008 IEEE. All rights reserved.
// to prevent driving DP into a DS cloud provoking an arb // state timeout - needed only in border nodes // tracks state of LPS_pin
555
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-5—Variables shared between architectural elements (continued) boolean nextArb[NPORT]; local port boolean nextEvenRequest; boolean nextOddRequest; boolean oddIsochPhase; began with
// arb state machine requests next symbol from fifo for
// TRUE if the last fully completed isochronous interval // CYCLE_START_EVEN.
will be ODD.) betaRequestCode ownReq; boolean packetEnding[NPORT]; FIFO control phyStateType phyState; boolean proxyRoot; root in a B-bus speedCode portRSpeed[NPORT]; port int receivePort;
(Upcoming or current interval
// current arb state terminates the packet - used for
// TRUE if seniorBorder in cloud containing root, or // most recently read speed code from the fifo for the
speedCode reqSpeed; boolean sendAsyncStartToken; boolean seniorBorder; B cloud boolean SID_complete; concludes
// Speed signaled by the link across the PHY/link interface // TRUE if this node is the senior border for the local // TRUE immediately after self_ID packet transmission // in state S4 prior to the transmission of IDENT_DONE // suppress requests before a short GRANT
boolean suppressRequests;
// shared between the main arb state machine, port.c and process_req.c boolean immediatePhyRequest; boolean oddAsyncPhase;
// TRUE if immediate request from the PHY // TRUE if last received arb reset was ARB_RESET_ODD
// shared between the main arb state machine, port.c, node.c and process_req.c boolean immediateRestoreRequest; boolean isbr; attempted boolean restoreRequest; port restore #ifdef unsubscripted boolean active; boolean betaMode; in Beta mode,
// TRUE if immediate request to restore on the nephew // Set when an arbitrated (short) bus reset should be // TRUE if requested the bus in order to complete a
// Indicates that the port is in state P2:Active // (set by state machine transitions to/from P2) // Set if the port has determined that it is operating
// unset otherwise (i.e. when operating in DS-Mode or T-mode, // or when in P0:disconnected). // This is maintained as a read-only bit in the port register map. boolean tPort802Mode; boolean tMode; tPort802Mode) arbState portRArb; boolean restore; #else boolean active[NPORT]; boolean betaMode[NPORT+1]; boolean tMode[NPORT+1];
556
// Set if the port is operating in tPort802Mode // (and we can’t get at it!) // Set if the port is operating in T mode, // unset otherwise (i.e. when in P0:disconnected or in // most recently read arb state from fifo for port
// betaMode[NPORT] always false
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-5—Variables shared between architectural elements (continued) arbState portRArb[NPORT]; boolean restore[NPORT]; #endif // shared between the main arb state machine, port.c, node.c and bport_rx.c boolean busInitializeActive;
// Set while the PHY is initializing the bus
// shared between the main arb state machine, node.c and process_req.c #ifdef unsubscripted byte currentData; #else byte currentData[NPORT]; #endif
// most recently read data from the fifo for the port
boolean bNodeRoot; breqType breq; linkType link;
// TRUE if the root is in the local B cloud // (NB, FALSE if root has a legacy link) // global status variable set by the PHY/Link interface // note, this does not change during normal operation // if this changes, then the PHY is “power reset” // Note also that changes to LPS_pin do NOT affect this variable
speedCode maxLegacyPathSpeed; betaRequestCode receiveReq[NPORT]; boolean root;
// track latest requests received on each port // TRUE if root node
// shared between node.c and process_req.c boolean loopTestRequest;
// TRUE if requested the bus in order to test for loops
// shared between the main arb state machine, bport_rx.c, and process_req.c #define FIFO_DEPTH (10+TMODE_SYMBOL_JITTER+2) // depth of receive FIFO - 10 normally, add extra for tports // add two extra symbols for quantization effects // shared between the main arb state machine, bport_rx.c, node.c, and process_req.c boolean bBus;
// TRUE if no legacy nodes (including legacy Links) on bus
// shared between the main arb state machine, bport_rx.c, dsport_rx.c and process_req.c #ifdef unsubscripted int fifoRdPtr; int fifoWrPtr; #else int fifoRdPtr[NPORT]; int fifoWrPtr[NPORT]; #endif
// pointer to received character in fifo // only updated by the appropriate port
// shared between bport_rx.c, dsport_rx.c and process_req.c #ifdef unsubscripted portSymbol portR[FIFO_DEPTH]; #else
Copyright © 2008 IEEE. All rights reserved.
// symbol received by port machine
557
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-5—Variables shared between architectural elements (continued) portSymbol portR[NPORT][FIFO_DEPTH]; #endif // shared between bport_tx.c, port.c and process_req.c #ifdef unsubscripted betaRequestCode arbReqT; #else betaRequestCode arbReqT[NPORT]; #endif
// arbitration request to send
// shared between all modules boolean powerReset; power reset #include “proto.h” purposes
// TRUE during power reset, goes false at the end of
// last header, get the prototypes for C code checking
19.2 Connection management routines 19.2.1 Node-level connection monitor Table 19-6 specifies the operation of node-level connection monitor functions, such as suspend, resume, standby, restore, loop testing, etc.
Table 19-6—Node-level connection monitor functions and routines // node.c #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
timer biasTimer;
// Timer for bias filter
int loopTestRandom();
// not defined by C code, see spec for requirements
void nodeStatusMonitor() { // Continuously monitor node status in all states int activePorts = 0; // count of active ports, including ports in standby int i, suspendedPorts = 0; boolean border = link == LEGACY_Link; // starting assumption boolean isolatedNodeVal = TRUE; speedCode minOperatingSpeedVal = PHY_SPEED; // starting assumption boolean nephewVal = FALSE; // starting assumption if (!powerReset) { for (i = 0; i < NPORT; i++) { if ((active[i] || suspendRequest[i] || doStandby[i]) && betaMode[i] && (portSpeed[i] < minOperatingSpeedVal)) minOperatingSpeedVal = portSpeed[i]; if (active[i] || inStandby[i]) { activePorts++; // Necessary to deduce boundary node status isolatedNodeVal = FALSE; if (!betaMode[i]) // active port is operating in legacy mode border = TRUE; } else if (connected[i] && !disabled[i] && !inStandby[i] &&
558
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-6—Node-level connection monitor functions and routines (continued) !loopDisabled[i] && !untestedState[i]) suspendedPorts++; // Other part of boundary node definition if (inStandby[i] && connected[i] && !proxy[i]) nephewVal = TRUE; } } borderNode = border; // the node is a border or otherwise boundaryNode = (activePorts > 0 && suspendedPorts > 0); allPortsSuspended = (activePorts == 0) && (suspendedPorts > 0); isolatedNode = isolatedNodeVal ; // Remains TRUE if no active port(s) found minOperatingSpeed = minOperatingSpeedVal; nephew = nephewVal; } boolean suspendInProgress() { int i; for (i = 0; i < NPORT; i++) if (suspendRequest[i]) return(TRUE); return(FALSE); }
// TRUE if any port suspending
boolean resumeInProgress() { int i; for (i = 0; i < NPORT; i++) if (resume[i]) return(TRUE); return(FALSE); }
// TRUE if any port resuming
void suspendAllActivePorts() { int j; for (j = 0; j < NPORT; j++) if (active[j]) suspendRequest[j] = TRUE; }
// Otherwise all active ports become suspend initiators
void resumeAllPorts() { int j; for (j = 0; j < NPORT; j++) if ((portState[j] == P1) || (portState[j] == P3) || (portState[j] == P4) || (portState[j] == P5)) resume[j] = TRUE; // Resume all suspended ports } boolean resumeRxOk() { int j; boolean resumeRxOkValue = TRUE; // Assume this is true until proven false for (j=0; j < NPORT; j++) resumeRxOkValue &= (!resume[j] || rxOk[j]); // Note that for resuming Beta ports presence of receiveOk is not // enough, need to allow sufficient time for port sync also. For // DS ports, rxOk indicates state of detected bias return (resumeRxOkValue); }
Copyright © 2008 IEEE. All rights reserved.
559
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-6—Node-level connection monitor functions and routines (continued) boolean restoreInProgress() { int i; for (i = 0; i < NPORT; i++) if (restore[i]) return(TRUE); return(FALSE); }
// TRUE if any port restoring
void restorePort() { int j; for (j = 0; j < NPORT; j++) if (inStandby[j] && connected[j] && !proxy[j]) restore[j] = TRUE; // Restore port in standby (if any) if on leaf }
void biasStatus() { // Continuously running bias update code static boolean biasFilter[NPORT]; // TRUE when applying hysteresis to bias_detect circuit int i; if (powerReset) { for (i = 0; i < NPORT; i++) bias[i] = biasFilter[i] = FALSE; while (powerReset) ; return; } for (i = 0; i < NPORT; i++) { if (!(BETA_MODE_ONLY_PORT[i] || T_MODE_CAPABLE_PORT[i])) { if (sendingTone[i]) { biasFilter[i] = FALSE; // abandon bias filtering on this port whilst sending a tone continue; // and move on to next port } if ((PMD_STATUS_request(i) & PMD_BIAS_DETECT) != bias[i]) { // detected and reported bias differ on enabled port? if (biasFilter[i]) { if (bias[i]) { // filtering for loss of bias if (biasTimer == BIAS_LOSS_FILTER_TIME) { biasFilter[i] = FALSE; // Done filtering bias[i] = FALSE; // Confirm new value in PHY register bit } } else { // filtering for bias detected if (biasTimer == BIAS_FILTER_TIME) { biasFilter[i] = FALSE; // Done filtering bias[i] = TRUE; // Confirm new value in PHY register bit } } } else if (!disabled[i] || bias[i]) { // change, but not filtering, // always take note of loss of bias, ignore new bias if disabled biasFilter[i] = TRUE; // so start a filtering period biasTimer = 0; } } else biasFilter[i] = FALSE; // stop filtering if we were } // round the loop to the next port } } void sendLTP() {
560
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-6—Node-level connection monitor functions and routines (continued) PHY_pkt txPhyPkt; txPhyPkt.dataQuadlet = 0; txPhyPkt.phy_ID = 0x3F; txPhyPkt.extType = 0xE; // LTP packet; txPhyPkt.mode = HR_mode; txPhyPkt.G = HR_G; txPhyPkt.testValue = HR_testValue; PH_DATA_indication(PH_DATA_START, S100, 0, LEGACY); txQuadlet(txPhyPkt.dataQuadlet); txQuadlet(~txPhyPkt.dataQuadlet); // Keep bus for concatenation PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); stopTxPacket(DATA_PREFIX, NPORT); startTxPacket(S100, LEGACY, FALSE); // Send data prefix & speed signal } void txPhyPacket(PHY_pkt packetToSend, int portNum) { int i; PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity fork { { // Send null packet on active ports startTxPacket(S100, BETA, FALSE); } { // Send the special configuration packet on the restoring port portT[portNum].pkt = BETA; portT[portNum].arb = SPEED; portT[portNum].speed = S100; portT[portNum].tag = ARB_STATE; waitSymbolTime(S100); portT[portNum].arb = DATA_PREFIX; portT[portNum].speed = DEFAULT; portT[portNum].tag = ARB_STATE; waitSymbolTime(S100); for (i = 0; i < 4; i++) { // ...a byte at a time portT[portNum].speed = S100; portT[portNum].data = (byte)((packetToSend.dataQuadlet >> 8*(3-i)) & 0xFF); portT[portNum].tag = DATA; waitSymbolTime(S100); } for (i = 0; i < 4; i++) { // ...a byte at a time portT[portNum].speed = S100; portT[portNum].data = (byte)(((~packetToSend.dataQuadlet) >> 8*(3-i)) & 0xFF); portT[portNum].tag = DATA; waitSymbolTime(S100); } // Now prepare ending state for restoring port portT[portNum].arb = DATA_END; portT[portNum].speed = DEFAULT; portT[portNum].tag = ARB_STATE; } }
Copyright © 2008 IEEE. All rights reserved.
561
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-6—Node-level connection monitor functions and routines (continued) join // Send and time ending state for active ports, time ending state for restoring port as well restore[portNum] = FALSE; // this lets the port transition to active stopTxPacket(DATA_END, NPORT); // packet ends with a quiet grant to nephew PH_DATA_indication(PH_DATA_END, 0, 0, 0); } PHY_pkt rxPhyPacket(int portNum) { PHY_pkt packetReceived; int byteCount; arbState rxArbState; byte rxDataByte; byteCount = 0; rxArbState = portRArb[portNum]; // wait for start of packet while (connected[portNum] && !((rxArbState == SPEED) || (rxArbState == DATA_PREFIX))) rxArbState = portRArb[portNum]; while (connected[portNum] && (rxArbState != DATA_BYTE)) rxArbState = portRNextArb(portNum); // skip DATA_PREFIXes while (rxArbState == DATA_BYTE) { rxDataByte = currentData[portNum]; if (byteCount < 8) packetReceived.dataBytes[byteCount] = rxDataByte; byteCount++; rxArbState = portRNextArb(portNum); } restore[portNum] = FALSE; // this lets the port transition to active waitSymbolTime(S100); waitSymbolTime(S100); if ((byteCount != 8) || (packetReceived.dataQuadlet != ~packetReceived.checkQuadlet)) packetReceived.dataQuadlet = 0; // kill bad packets return (packetReceived); } void conMgmntGranted() { // called from tx_actions once arbitration has been won int i; PHY_pkt configPkt; if (restoreRequest) { for (i = 0; i < NPORT; i++) { if (restore[i] && bportSyncOk[i]) { // find a restoring port (do restores one at a time) if (proxy[i]) { // uncle actions // send updated information to peer port configPkt.dataQuadlet = 0; configPkt.root_ID = standbyPhy_ID[i]; configPkt.R = 1; // to avoid both R and T being zero configPkt.T = gapCountResetDisable ? 1: 0; configPkt.gapCount = gapCount; configPkt.notifyLegacySpeed = maxLegacyPathSpeed; configPkt.notifyBNodeRoot = bNodeRoot ? 1: 0; configPkt.notifyBBus = bBus ? 1: 0; configPkt.Q = (quadlet)(root ? 1: 0); // included for use by PIL_FOP configPkt.P = (quadlet)(PMD_PS_request() ? 1: 0); // included for use by PIL_FOP configPkt.notifyOddAsyncPhase = oddAsyncPhase ? 1: 0; configPkt.notifyReset = resetNotify[i] ? 1: 0; txPhyPacket(configPkt, i); // and the special configuration packet on this port
562
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-6—Node-level connection monitor functions and routines (continued) // and set the port active proxy[i] = FALSE; } else { // nephew actions // restored leaf node - receive updated information from peer port configPkt = rxPhyPacket(i); // and set the port active if (configPkt.dataQuadlet == 0) { // bad restore packet isbrOk = TRUE; immediateRestoreRequest = FALSE; break; } if (configPkt.notifyReset == 1) physical_ID = configPkt.root_ID; gapCountResetDisable = configPkt.T == 1; gapCount = configPkt.gapCount; maxLegacyPathSpeed = configPkt.notifyLegacySpeed; bNodeRoot = configPkt.notifyBNodeRoot == 1; bBus = configPkt.notifyBBus == 1; isochConcatOk = bBus; // for legacy camcorder problem oddAsyncPhase = configPkt.notifyOddAsyncPhase == 1; startTxPacket(S100, BETA, FALSE); // send null packet if (configPkt.notifyReset == 1) { // inform nephew of a previous reset on the uncle’s bus PH_EVENT_indication(PH_RESTORE_RESET, 0, 0); waitPH_EVENT_response(); } PH_EVENT_indication(PH_SELF_IDENTITY, physical_ID, root); // Unsolicited Register 0 PH_DATA_indication(oddAsyncPhase ? PH_ARB_RESET_ODD : PH_ARB_RESET_EVEN, 0, 0, 0); immediateRestoreRequest = FALSE; bossEndPacketActions(FALSE, GRANT); // not in iso cycle } break;
// done this port, don’t do any more
} } restoreRequest = FALSE; for (i = 0; i < NPORT; i++) // check if any more to do if (restore[i] && bportSyncOk[i]) restoreRequest = TRUE; } else { // request for loop test maxOccupancyTimer = 0; // Start the occupancy timer. inControl = TRUE; releaseControl = FALSE; PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity startTxPacket(S100, LEGACY, FALSE); // Send data prefix & speed signal while (loopTestRequest && !releaseControl) { if (needNewLTP) { sendLTP(); testIntervalTimer = 0; needNewLTP = FALSE; } } inControl = FALSE; // then release the bus. while (releaseControl)
Copyright © 2008 IEEE. All rights reserved.
563
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-6—Node-level connection monitor functions and routines (continued) ; isbrOk = isbr;
// While the local node was a controlling node, any port that // received an attach request or a test port that // received a bus reset will have set isbr
if (!isbrOk) { PH_DATA_indication(PH_DATA_END, 0, 0, 0); stopTxPacket(DATA_END, NPORT); } } } void loopDetector() { int i; if (powerReset) { while (powerReset) ; return; } while (loopToDetect) { only after
// continuously running
// exit from here if tree_ID is successful, possibly
// the local beta ports have been put into the untested state if (T0_timeout || (maxArbStateTimeout()) || (resetCount > 3)) { // tree_ID has detected a loop for (i = 0; i < NPORT; i++) if (betaMode[i] && active[i]) { // note that the transition out of active might now allow an exit from T0 forceDisconnect[i] = TRUE; } while (loopToDetect) // only force disconnect once per each loop detection ; } } } boolean attachPending() { int i; for (i = 0; i < NPORT; i++) if (attach[i]) return(TRUE); return(FALSE); } int newTestValue() { return (loopTestRandom()); } void loopTestIntervalActions() { static int collisionCount; byte receivedLTS = 0; int i; if (powerReset) { collisionCount = 0; HR_testValue = newTestValue(); for (i = 0; i < NPORT; i++) portUnderTest[i] = FALSE; sendAttach = FALSE; foundLoop = FALSE;
564
// TRUE if any port set to attach
// see specification for requirements
// continuously running // error if used before being set
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-6—Node-level connection monitor functions and routines (continued) loopTestRequest = FALSE; while (powerReset) ; return; } if (NPORT==1) return;
// single port phy doesn’t require loop testing
testPort = NPORT;
// no port is selected (yet) for testing
// First, complete any unfinished attaches, caused by reception of ATTACH_REQUEST // during a period when no local port was eligible for testing. Also, wait for any // controlling node on the local segment to complete it’s ATTACH attempt. while (attachPending() || (HR_mode == ATTACH_IN_PROGRESS)) ; // Now select a unique port to test // First try to find a port that is receiving an LTS lower than the test value // If unsuccessful, then choose a port that is receiving an LTS equal to the test value // Never select a port that is receiving an LTS higher than the test value for (i = 0; i < NPORT; i++) if (untested[i] && (portRArb[i] == DATA_BYTE)) { if (((HR_mode << 7) | (HR_G << 6) | HR_testValue) > currentData[i]) { testPort = i; // found a port to test with an LTS lower than the break; // test value, so test immediately } else if (((HR_mode << 7) | (HR_G << 6) | HR_testValue) == currentData[i]) testPort = i; // found a colliding port, remember for testing in case // another preferred port is not found } if (testPort != NPORT) { collisionCount = 0; // Clear any old collisions portUnderTest[testPort] = TRUE; loopTestRequest = TRUE; // and request the bus while (portUnderTest[testPort]) { // First, get the latest LTS received on the test port if (portRArb[testPort] == DATA_BYTE) receivedLTS = currentData[testPort]; // Check if need to release bus to complete ATTACH_REQUESTS received on other ports // Also check if another controlling node on the local segment has initiated an attach // in which case an immediate abort is appropriate so that a new test port can be selected if (attachPending() || (HR_mode == ATTACH_IN_PROGRESS)) { portUnderTest[testPort] = FALSE; } else if (!untested[testPort]) { // Loss of sync? portUnderTest[testPort] = FALSE; } // Check if the test-port is receiving a dominant LTS from its peer port. else if (((receivedLTS & 0x80) != 0) || // Attach in progress, immediate abort ... (!needNewLTP && testIntervalTimer >= TEST_INTERVAL && receivedLTS > ((HR_mode << 7) | (HR_G << 6) | HR_testValue))) { // ... or the node has waited long enough for the last xmitted LTP to reach all
Copyright © 2008 IEEE. All rights reserved.
565
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-6—Node-level connection monitor functions and routines (continued) // nodes in the network, and the received LTS is dominant, so abort // testing on this port (go to next). portUnderTest[testPort] = FALSE; } // Check if there’s a collision between the xmitted LTS and the rcv’d LTS else if (inControl && !needNewLTP && (receivedLTS == ((HR_mode << 7) | (HR_G << 6) | HR_testValue))) { // There’s a collision between xmitted LTS and received LTS. collisionCount++; if (collisionCount == COLLISION_LIMIT) { foundLoop = TRUE; // flag to send portUnderTest to loop disabled state while (untested[testPort]) ; // Wait for port to acknowledge command to enter loopDisabled state portUnderTest[testPort] = FALSE; } else { // release the bus and reacquire control of the bus to test again // this allows loop testing of large diameter networks without // violating MAX_OCCUPANCY_TIME, and in particular gives time for // a non-loop connection to be completed using isbr on the peer bus // (unless the peer bus is very busy) releaseControl = TRUE; while (inControl) // wait for the bus to be released ; // handshake releaseControl = FALSE; while (!inControl) // wait for the bus to be accessed again ; HR_testValue = newTestValue(); HR_G = (HR_G == 0) ? 1 : 0; needNewLTP = TRUE; } } // Check if the test-port can be attached. else if (inControl && testIntervalTimer >= TEST_INTERVAL && !needNewLTP) { // Test interval has expired, and the local node is in control, without a collision HR_mode = ATTACH_IN_PROGRESS; // Should not receive new attach-requests // on any port once this is set. needNewLTP = TRUE; while (needNewLTP) ; sendAttach = TRUE; // Flag for the test port to attempt attach while (!attach[testPort] && untested[testPort]) ; // Wait for port to prepare for bus reset (attach) or // to “complete” testing due to loss of sync if (!untested[testPort]) { // did the port lose sync? HR_mode = LTP_TEST; // need to flush out the ATTACH_IN_PROGRESS needNewLTP = TRUE; while (needNewLTP) ; } portUnderTest[testPort] = FALSE; } } // end of while portUnderTest loop loopTestRequest = FALSE; // stop requesting the bus and release if necessary while (inControl || attachPending()) ; // Wait until controlling node has released the bus and any outstanding attaches
566
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-6—Node-level connection monitor functions and routines (continued) // (including any on the testPort) have completed if (HR_mode != LTP_TEST) { // On an isolated node, an attach request sent to a test port that subsequently // loses synchronization can leave HR_mode set to ATTACH_IN_PROGRESS after clearing // the attach flag. As such, the mode needs to be reset as if a bus_reset had occured, // but does not need to be sent immediately in an LTP since the node is isolated HR_mode = LTP_TEST; needNewLTP = TRUE; } foundLoop = FALSE; sendAttach = FALSE; // No longer waiting for an attach, okay to move onto another port } // finished with current testPort, allow next testPort to be selected }
19.2.2 Port connection manager actions and conditions Table 19-7 specifies connection manager actions on a per-port basis, such as toning.
Table 19-7—Port connection manager actions and conditions // port.c #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
// Per port code // Note that unsubscripted references to active, connected, disabled, suspend, resume, // proxy, restore, bias, betaMode and BETA_MODE_ONLY_PORT are to be interpreted as references // to active[i] etc, where i is the number of the particular port // The EVT_X_Y constants are to be considered distinct for each port and distinct from the // values used in the arbitration state machine. Thus the use of waitEvent within the per port code // depends only on signals sent within the port. #define EVT_SENT_SPEED 0x00000001 #define EVT_SENT_ACK 0x00000002 #define EVT_RECEIVED_SPEED 0x00000004 const int PORTNUM;
// port number for this port
timer biasDelayTimer; boolean connectDetectValid; comparator
// used for timing out Bias delays // When true, indicates that the dc connect detect
boolean connectionUnreliable; negotiation
// will give a valid indication of the connection status // PHY register bit, set true if the Beta mode speed // fails or synchronization fails whilst establishing the // operating mode and speed of a connection. Reset by
software after boolean dcConnected;
// appropriate higher level action has been taken. // latches PMD’s connect_detect // TRUE if the port has detected a dc connection to the peer port.
Copyright © 2008 IEEE. All rights reserved.
567
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) // This is maintained as a read-only bit in the port register map. boolean hardDisable; completely boolean intEnable; boolean listeningForSpeed; speedCode maxPortSpeed; in Beta mode speedCode minPortSpeed; in Beta mode
// port register map flag to turn a disabled port off
// turns on/off the receiveSpeedIndication routine // maximum speed at which a port is allowed to connect // minimum speed at which a port is allowed to connect // This per-port value is the minimum speed at which a
port is capable // of connecting in Beta mode. The speed is encoded as in maxPortSpeed // The port uses this value only when a new connection is established // in Beta mode. An attempt by a peer port to negotiate Beta mode // connection at a speed lower than this speed will be rejected. // Set to one of two values for Tport and Betamode UTP operation. boolean portEvent; speedCode receivedSpeed; maxPortSpeed boolean sdDetected; boolean sendSpeed; boolean speedAck; boolean syncFail; timer toneTestTimer; boolean tonerActive; boolean toning; boolean watchdog; boolean weAgree; is agreed
// Last speed received from peer PHY. Encoding as // latches the PMD’s signal_detect // speedAck says that the other end received OUR speed // true if suspend initiator due to loss of sync // to avoid contention on drivers // turns on/off the toner // Indicates to the toner to signal the peer that speed // (the transmitted ACK bit in a speed code should be set to 1)
// // // // // //
the following supplements the legacy definition enum speedCode {S100, S200, S400, S800, S1600, S3200}; speed codes are encoded 000 001 010 011 100 101 Speed codes exchanged during speed negotiation are encoded as 001 010 011 100 101 110
void activateConnectDetect(int delay) { PMD_CONTROL_request(PMD_UNSELECT_PORT, 0); bportOn = dsportOn = tportOn = FALSE; if (!betaMode && !(BETA_MODE_ONLY_PORT || T_MODE_CAPABLE_PORT)) PMD_DSPORT_TPBIAS_request(GND); // Drive TpBias low if (delay != 0) { connectTimer = 0; while (connectTimer < delay) // Enforce minimum hold time for TpBias low ; // also ensures handshake times for both modes } if (!betaMode && !(BETA_MODE_ONLY_PORT || T_MODE_CAPABLE_PORT)) { while (!(PMD_STATUS_request() & PMD_CONNECT_DETECT)) ; // Wait for connect_detect circuit to stabilize // (this assumes sufficient hysteresis in analog circuit) PMD_DSPORT_TPBIAS_request(ZZ); // Release TpBias } connectDetectValid = TRUE; // Signal OK to connectionStatus()
568
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) } void portPowerReset() { active = suspendRequest = disableRequest = resume = doStandby = inStandby = loopDisabled = hardDisable = suspendFault = resumeFault = standbyFault = connectionUnreliable = proxy = syncFail = attach = untested = untestedState = forceDisconnect = FALSE; // the variables disabled, maxPortSpeed and T_MODE_CAPABLE_PORT // are set to their implementation-dependent power-reset values longContendTimer = (boolean) T_MODE_CAPABLE_PORT; activateConnectDetect(0); while (powerReset) // wait for power reset to be released ; } void dcConnectionDetector() { // Continuously running static boolean connectionInProgress; // TRUE when debouncing a new connection if (powerReset) { dcConnected = connectionInProgress = FALSE; while (powerReset) ; return; } if (!(BETA_MODE_ONLY_PORT || T_MODE_CAPABLE_PORT)) { // dc connection detection and debouncing is not implemented in a BETA_MODE_ONLY_PORT // Note that an incoming tone may cause connect_detect to give a false “disconnect” indication if (connectionInProgress) { if (!(PMD_STATUS_request() & PMD_CONNECT_DETECT)) connectionInProgress = FALSE; // Lost attempted connection // or possibly set false because a tone came in else if (connectTimer >= CONNECT_TIMEOUT) { connectionInProgress = FALSE; dcConnected = TRUE; // Confirmed connection } } else if ( !dcConnected // Recognize connection if port or interrupts enabled && (!disabled || intEnable)) { if (PMD_STATUS_request() & PMD_CONNECT_DETECT) { // Possible new connection? connectTimer = 0; // Start connect timer connectionInProgress = TRUE; } } else if (connectDetectValid && !(PMD_STATUS_request() & PMD_CONNECT_DETECT)) { dcConnected = FALSE; // Detect disconnect fairly instantaneously } } } void portEventMonitor() { // continuously running boolean lastRxOk, lastConnected, lastDisabled, lastFault, lastInStandby, lastStandbyFault, lastConnectionUnreliable; boolean setPortEvent; while (powerReset) { lastRxOk = lastConnected = lastDisabled = lastFault = lastInStandby = lastStandbyFault = lastConnectionUnreliable = FALSE; }
Copyright © 2008 IEEE. All rights reserved.
569
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) fault = suspendFault || resumeFault; setPortEvent = (((rxOk != lastRxOk) && !disabled) || (connected != lastConnected) || (disabled != lastDisabled) || (fault != lastFault) || (inStandby != lastInStandby) || (standbyFault != lastStandbyFault) || (connectionUnreliable && !lastConnectionUnreliable)); if (setPortEvent && intEnable && !portEvent) { portEvent = TRUE; PH_EVENT_indication(PH_INTERRUPT, 0, 0); } lastRxOk = rxOk; lastConnected = connected; lastDisabled = disabled; lastFault = fault; lastInStandby = inStandby; lastStandbyFault = standbyFault; lastConnectionUnreliable = connectionUnreliable; } void sendTone() { if (!BETA_MODE_ONLY_PORT && ((PMD_STATUS_request() & PMD_BIAS_DETECT))) { // avoid toning into incoming TpBias but a BETA_MODE_ONLY_PORT is not // required to support a Bias detector waitTime(TONE_DURATION); return; } sendingTone = TRUE; PMD_CONTROL_request(PMD_TONE_ON, 0); waitTime(TONE_DURATION); PMD_CONTROL_request(PMD_TONE_OFF, 0); sendingTone = FALSE; } void signalDetectMonitor() { // continuously running - latches signal_detect if (powerReset) { sdDetected = FALSE; while (powerReset) ; } else { if (PMD_STATUS_request() & PMD_SIGNAL_DETECT) sdDetected = TRUE; } } boolean signalDetectOk() { boolean x; x = sdDetected; waitTime(TONE_DURATION); if (x) {
// true if signal_detect set since last looked
// to make sure that don’t see the same tone twice
// clear the latch once seen a tone, // but don’t bother if the next tone is already present sdDetected = (boolean)(PMD_STATUS_request() & PMD_SIGNAL_DETECT); } return(x); }
570
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-7—Port connection manager actions and conditions (continued) void receiveOkMonitor() { // continuously running timer receiveOkTimer = 0; if (powerReset) { receiveOk = rxOk = FALSE; receiveOkTimer = 0; while (powerReset) ; } // Evaluate receiveOk if (tMode) { receiveOk = (PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK; } else if (betaMode) { if (!(PMD_STATUS_request() & PMD_SIGNAL_DETECT)) { receiveOk = FALSE; receiveOkTimer = 0; } else if (receiveOkTimer == TONE_DURATION * 5 / 4) // Signal detect currently true, is it continuous? receiveOk = TRUE; } else if (BETA_MODE_ONLY_PORT || T_MODE_CAPABLE_PORT) { receiveOk = FALSE; receiveOkTimer = 0; } else { receiveOk = bias; receiveOkTimer = 0; } // Assign rxOk rxOk = (boolean)((tMode || T_MODE_ONLY_PORT) ? (PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK : betaMode ? bportSyncOk: bias); } void toner() { boolean tAck = FALSE; int i, tSpeed = 0;
// // // //
continuously running assert error if used before being set tSpeed latches value of speed to send, assert error if used before being set
if (powerReset) { sendingTone = FALSE; PMD_CONTROL_request(PMD_TONE_OFF, 0); while (powerReset) ; return; } while (toning || sendSpeed) { tonerActive = TRUE; for (i = 0; i < TONE_INTERVAL; i++) { if (!(toning || sendSpeed)) // allow early exit, particularly to set break; // tonerActive to FALSE when toning stops if (i == 1) tAck = weAgree && sendSpeed; // latch latest status of weAgree just before // the ack bit is sent if (i == 2) tSpeed = sendSpeed ? portSpeed + 1 : 0; // latch latest speed just before // the first speed bit is sent if ((i == 0) || // start bit (i == 1 && tAck) || // ack bit (i >= 2 && i <= 4 && (tSpeed & (1 << (i - 2))) != 0)) // speed bits
Copyright © 2008 IEEE. All rights reserved.
571
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) sendTone(); else waitTime(TONE_DURATION); waitTime(SPEEDCODE_BIT_INTERVAL); // inter-bit gap if (i == 7) { if (tSpeed != 0) signal(EVT_SENT_SPEED); if (tAck) signal(EVT_SENT_ACK); }
// speed code bits sent // ack bit sent
} } tonerActive = FALSE; } void receiveSpeedIndication() { // continuously running boolean found; int count, i; int rs; // accumulate the received speed while (listeningForSpeed && !powerReset) { rs = 0; // first find the gap count = (TONE_GAP - 1)*4; // maximum gap (specified in samples separated by // TONE_DURATION that can occur within a valid speed // code including possible future codings) while (count >= 0) { if (signalDetectOk()) { // saw a bit, so start looking for the gap again count = (TONE_GAP - 1)*4; } else count = count - 1; } count = (TONE_INTERVAL - TONE_GAP + 1)*4; // the maximum time (specified in // samples separated by TONE_DURATION) for a start // bit to appear after a previous gap was detected found = FALSE; while (count > 0 && !found) { count = count - 1; found = signalDetectOk(); // seen the start bit for a new speed code } waitTime(SPEEDCODE_BIT_INTERVAL + TONE_DURATION/2); // for centering if (found) { speedAck = signalDetectOk(); // next bit is the ack bit for (i = 0; i < 6; i++) { // now look for six speed code bits waitTime(SPEEDCODE_BIT_INTERVAL); // this standard only uses first three, but this allows if (signalDetectOk()) rs = rs | (1 << i); // negotiation with other standards } if (rs > 0) { receivedSpeed = (speedCode)(rs - 1); // decode signal(EVT_RECEIVED_SPEED); } } } } boolean startResumePort() {
572
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) while (suspendInProgress()) // Let any other suspensions complete ; // (node may resume those ports later) okToDetectReset = resumptionDone = FALSE; connectDetectValid = FALSE; // Bias renders connect detect circuit useless, if (!resume && !boundaryNode) resumeAllPorts(); else resume = TRUE; // Guarantee resumeInProgress() returns TRUE // initialize the arb/port interface so that the right thing is transmitted once training is done while (tonerActive) // wait for toning to stop ; connectTimer = 0; portT.speed = DEFAULT; portT.tag = ARB_STATE; portT.arb = IDLE; if (betaMode) { arbReqT.isoch = ISOCH_NONE; arbReqT.async = oddAsyncPhase ? NONE_ODD: NONE_EVEN; if (tMode) { PMD_CONTROL_request(PMD_SELECT_TPORT, portSpeed); tportOn = TRUE; // start up and train the port } else { PMD_CONTROL_request(PMD_SELECT_BPORT, portSpeed); bportOn = TRUE; // start up and train the port } } else { PMD_CONTROL_request(PMD_SELECT_DS_PORT, 0); dsportOn = TRUE; PMD_DSPORT_TPBIAS_request(BIAS_ON); // DS mode, Generate TpBias } // Need to wait till resumption is OK on all resuming ports while ((connectTimer < (tMode ? TPORT_SUSPEND_HANDSHAKE : RECEIVE_OK_HANDSHAKE)) && !resumeRxOk()) ; // betaMode only requires DISCONNECTED_TONE_INTERVAL/4 + // 4 * TONE_DURATION + RECEIVER_INIT_TIME + // (SYNCHRONIZATION_LENGTH/(BASE_RATE*(1<<(portSpeed-1)))) return (rxOk); } boolean startPort() { // for restore and loop free build okToDetectReset = resumptionDone = FALSE; connectDetectValid = FALSE; // Bias renders connect detect circuit useless // initialize the arb/port interface so that the right thing is transmitted once // training is done while (tonerActive) // wait for toning to stop ; connectTimer = 0; portT.speed = DEFAULT; arbReqT.isoch = ISOCH_NONE; arbReqT.async = oddAsyncPhase ? NONE_ODD: NONE_EVEN; portT.tag = ARB_STATE; portT.arb = IDLE; if (tMode) { PMD_CONTROL_request(PMD_SELECT_TPORT, portSpeed); tportOn = TRUE; // start up and train the port
Copyright © 2008 IEEE. All rights reserved.
573
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) } else { PMD_CONTROL_request(PMD_SELECT_BPORT, portSpeed); bportOn = TRUE; // start up and train the port } // strictly, the requirement is (DISCONNECTED_TONE_INTERVAL/4 + 4 * TONE_DURATION + // RECEIVER_INIT_TIME + (SYNCHRONIZATION_LENGTH/(BASE_RATE*(1<<(portSpeed-1))))) // for a tMode port, the startup time can be very much longer while ((connectTimer < (tMode ? TPORT_SUSPEND_HANDSHAKE : DISCONNECTED_TONE_INTERVAL/2)) && !rxOk && connected) ; return (rxOk); } boolean setBeta() {
// set Beta mode and exchange speed codes to establish // operating speed, returns FALSE if the speed negotiation failed boolean speedAgreed, sentAck; int count; eventVar event; speedCode cableSpeed; cableSpeed = PMD_CABLE_SPEED_request(); portSpeed = (cableSpeed < maxPortSpeed) ? cableSpeed : maxPortSpeed; // our starting point if (portSpeed < minPortSpeed) return(FALSE); count = 20; // ten tries speedAgreed = weAgree = sentAck = FALSE; sendSpeed = TRUE; // start the autonomous speed sender going with // the updated portSpeed listeningForSpeed = TRUE; // set the autonomous speed listener going; while (((count > 0) && !speedAgreed) || (speedAgreed && !sentAck)) { event = waitEvent(EVT_SENT_SPEED | EVT_RECEIVED_SPEED | EVT_SENT_ACK); if (event & EVT_RECEIVED_SPEED) { if (receivedSpeed < minPortSpeed) { listeningForSpeed = FALSE; sendSpeed = FALSE; return(FALSE); } if (receivedSpeed == portSpeed) { weAgree = TRUE; speedAgreed = speedAck; // all agreed when port has the acknowledge from other end } else { if (receivedSpeed < portSpeed) { portSpeed = receivedSpeed; // set Negotiated_speed in port register map to portSpeed weAgree = TRUE; count = 20; // and try again with a lower speed } else count++; // received speed > portSpeed, so allow another go, but // not too many times; also allows a future standard product to // negotiate down to what can be achieved } } if (event & EVT_SENT_SPEED) count = count - 2; if (event & EVT_SENT_ACK) sentAck = TRUE; } listeningForSpeed = FALSE; // turn off the autonomous listner (may take some time) sendSpeed = FALSE; // turn off sending of speed code (may take some time) if (speedAgreed) { // and set Negotiated_speed in port register map to portSpeed toning = FALSE;
574
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) betaMode = TRUE; longContendTimer = FALSE; } return (speedAgreed); } void setDS() { toning = FALSE; connectDetectValid = FALSE; longContendTimer = FALSE; connected = TRUE; }
// set DS mode (implied by betaMode remaining false)
void setTMode() { betaMode = TRUE; tMode = TRUE; longContendTimer = TRUE; portSpeed = S800; } void set802Mode() { tPort802Mode = TRUE; } void connectionStatus() { int i; eventVar pmdStatus; boolean crossover = FALSE; to receive
// continuously running code for each port
// When true, instructs the PMD to transmit on TPA and // and perform signal detect on TPB (only required for
UTP-5 ports) boolean knowStillBetaMode; boolean newConnectionDetected; boolean triedBias; TpBias just
// maintains knowledge of connection if suspended // indicates that the local port has tried sending // in case the far end port was a suspended legacy port
initialized // to false on POR, which is the only time this can occur if (powerReset) { betaMode = bportOn = connected = connectionUnreliable = crossover = dsportOn = listeningForSpeed = sendSpeed = tMode = tPort802Mode = tportOn = toning = triedBias = FALSE; PMD_CONTROL_request(PMD_UNSELECT_PORT, 0); PMD_CONTROL_request(PMD_NO_CROSSOVER, 0); waitTime(2 * DISCONNECTED_TONE_INTERVAL); // ensure that there is more than one tone interval since a signal // was transmitted so that the peer port moves into disconnected while (powerReset) ; return; } if (!(PMD_STATUS_request() & PMD_LOCAL_PLUG_PRESENT) || (disabled && hardDisable)) { // give up if no plug or hard disable toning = FALSE; // don’t signal presence connected = FALSE; betaMode = FALSE;
Copyright © 2008 IEEE. All rights reserved.
575
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) tMode = FALSE; if (hardDisable) { PMD_CONTROL_request(PMD_TPORT_OFF, NO_SPEED); tPort802Mode = FALSE; } waitTime(2 * DISCONNECTED_TONE_INTERVAL); // ensure far end sees a disconnect, only need to do the above line // “first time around”, but it’s not worth the extra flag to control // this return; // give up, i.e. to start the routine again } // note that the connected variable may be false even though a physical connection has been established // connected // 0 // 0 // 0 // 1 // 1 // 1
betaMode 0 1 1 0 1 1
tMode 0 0 1 0 0 1
operating mode not determined or tPort802Mode Beta mode, may be disabled and connection not reported T mode, may be disabled and connection not reported DS mode Beta mode T mode
// first case:- port has not established whether there is a connection, nor the operating mode // here if in P0, or P6 with the connected flag set to false if (!connected && !betaMode) { // look for new connection and determine operating mode if (tPort802Mode) { if ((PMD_STATUS_request() & PMD_TPORT_802) == PMD_TPORT_802) return; // here if lost 802 connection tPort802Mode = FALSE; activateConnectDetect(0); // and continue on to seeking a new connection } while (!connected && !betaMode) { if ((hardDisable && disabled) || !(PMD_STATUS_request() & PMD_LOCAL_PLUG_PRESENT)) return; // good to return immediately if this becomes // TRUE anywhere from here in if (T_MODE_CAPABLE_PORT) { // set autonegotiate // wait for Tmode or 802mode or autonegotiated failure minPortSpeed = T_MODE_ONLY_PORT ? S800 : S100; // values not used by hardware for a T_MODE_ONLY_PORT maxPortSpeed = S800; // but set to a consistent value for the sake of software PMD_CONTROL_request(PMD_START_NEGOTIATE, NO_SPEED); // ensures that the far end sees a disconnect // if necessary pmdStatus = PMD_STATUS_request(); while (((pmdStatus & PMD_NEGOTIATION_ACTIVE) == PMD_NEGOTIATION_ACTIVE) && !((pmdStatus & PMD_SIGNAL_DETECT) == PMD_SIGNAL_DETECT)) { pmdStatus = PMD_STATUS_request();
576
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) } if (!((pmdStatus & PMD_SIGNAL_DETECT) == PMD_SIGNAL_DETECT)) { if ((pmdStatus & PMD_TPORT_FW) == PMD_TPORT_FW) { setTMode(); if (disabled && !intEnable) return; // (compatible with legacy) connected = TRUE; while (!(untestedState || disabled)) // wait till in untestedState ; } else if ((pmdStatus & PMD_TPORT_802) == PMD_TPORT_802) { set802Mode(); } // here if autonegotiation failed return; } // sdDetected // here on signal_detect, must be a S100 UTP node at the other end, // so drop down to Beta negotiation if we can if (T_MODE_ONLY_PORT) return; // with a negotiation failure maxPortSpeed = S100; // the only option!!
}
//T_MODE_CAPABLE_PORT
toning = TRUE; // set the autonomous toner going (for the peer’s benefit) signalDetectOk(); // clear out any stale value (no need to wait) newConnectionDetected = FALSE; for (i = 0; i < NUM_OF_TRIES; i++) { // only needed if bi-lingual port if (bias) break; // don’t try to send tones if detect TpBias // so break out of the trying to tone loop if (!dcConnected) { toning = TRUE; // might have been waiting for dcConnected peer to wake us up triedBias = FALSE; // for legacy camcorder } if (dcConnected && !newConnectionDetected) { // try toning for at least two more times on a new connection newConnectionDetected = TRUE; i = NUM_OF_TRIES - 2; } toneTestTimer = 0; while ((toneTestTimer < DISCONNECTED_TONE_INTERVAL) && !sdDetected) ; if (signalDetectOk()) { // heard tone, now debounce toneTestTimer = 0; while ((toneTestTimer < CONNECT_TIMEOUT) && !bias) // interval to ignore bouncing ; if (bias) break; if (setBeta()) { // try Beta mode if (disabled && !intEnable) return; // (compatible with legacy) connected = TRUE; while (!(untestedState || disabled)) // wait till in untestedState ; return; } if (bias) break; // here if failed to negotiate speed, connection seems unreliable
Copyright © 2008 IEEE. All rights reserved.
577
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) if ((PMD_STATUS_request() & PMD_AUTOCROSSOVER_SUPPORTED) == 0) { // (random backoff if it is) if (!connectionUnreliable) { // already reported? connectionUnreliable = TRUE; } return; // to continue trying to connect } } // here if failed to hear a tone if (((PMD_STATUS_request() & PMD_AUTOCROSSOVER_SUPPORTED) != 0) && !dcConnected) { if (randomBool()) { // try a crossover at random while (sendingTone) // but delay if sending tone ; if (!sdDetected) { // final check just in case don’t need to crossover = !crossover; PMD_CONTROL_request(crossover ? PMD_CROSSOVER : PMD_NO_CROSSOVER, 0); } } } // note that the time to do signalDetectOk means that the listening loop // is guaranteed to be longer than the toning loop on the peer connection } // end of trying to tone loop // here if (1) tried toning 4 times without detecting a tone; // (2) detected a connection and tried toning twice without detecting a tone; // (3) detected incoming TpBias if (dcConnected) { toning = FALSE; while (tonerActive) ; if (bias) { biasDelayTimer = 0; while ((biasDelayTimer < 16*RESET_DETECT) && bias) ; // longer than a port operating in legacy or Beta mode will // generate it if (bias) { // incoming TpBias persists setDS(); // peer is a 1394-1995 port if (disabled) activateConnectDetect(0); // ensure port can detect loss of dc connection return; } triedBias = FALSE; // necessary to try bias after seeing bias, // as the peer port may be a legacy port that was resuming // and then went into suspend with a resume fault, toning = TRUE; // now need to try toning again in case node/port // powered up just when a peer bilingual port was generating bias } else if (!(triedBias || disabled)) { // Bias not present // try sending Bias just once, in case port has just powered up // whilst the connected legacy PHY was in suspend triedBias = TRUE; while (sendingTone) // but delay if sending tone ; connectDetectValid = FALSE; PMD_DSPORT_TPBIAS_request(BIAS_ON); biasDelayTimer = 0; while ((biasDelayTimer < 12*RESET_DETECT) && !bias) ;
578
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) if (bias) { setDS(); if (disabled) activateConnectDetect(0); // ensure port turns off bias and can detect loss of dc connection return; } activateConnectDetect(0); // includes taking TpBias away // the dc connected peer port is disabled // or powered off, either way it’ll wake us } // end of trying bias } // end of dc connected actions when toning has failed or bias detected } // main loop whilst not connected return; } // end of look for new connection and determine operating mode // here if connected, or Beta mode // check for continuous signaling or bias in relevant port states if (portState == P1 || portState == P2 || portState == P3 || portState == P4 || portState == P7 || portState == P8 || portState == P10 || portState == P11) { if (betaMode && !tMode) { // turn on toning if going into a suspend-type state if (!receiveOk && ((portState == P3) || (portState == P4) || (portState == P7) || (portState == P8))) toning = TRUE; // turn on toning as soon as possible else toning = FALSE; } if (forceDisconnect) { // caused by failure to startup while in P10 // or if a legacy loop is detected activateConnectDetect(0); connected = FALSE; betaMode = FALSE; if (!tMode) waitTime(2 * DISCONNECTED_TONE_INTERVAL); // ensure the far end sees a “disconnection” tMode = FALSE; // necessary wait will be performed by START_NEGOTIATE forceDisconnect = FALSE; } return; } // here if P5, P6, P9 or P12 and connectivity established // look for disconnect or report bias/continuous tone if (betaMode && !tMode) { // Beta mode - send a tone at periodic intervals knowStillBetaMode = FALSE; toning = TRUE; // turn on the autonomous toner signalDetectOk(); // flush any stale values (no need to wait) for (i = 0; i < RESUME_CHECKS; i++) { if (syncFail) break; // no need to continue checks if about to force a disconnect if (signalDetectOk()) { if (portState == P1 || portState == P10 || portState == P11) { toning = FALSE; // port changed state, so stop toning return; // this will also turn on receive_OK } else { knowStillBetaMode = TRUE; if (signalDetectOk()) { // still true - continuous tone if (!disabled) { // in P5:suspended state
Copyright © 2008 IEEE. All rights reserved.
579
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) if (!suspendFault) toning = FALSE;
// turn off the autonomous toner
} return; } break;
// connected, but no continuous tone
} } } betaMode = knowStillBetaMode; // loss of sync or entry into disabled forces disconnection, reset betaMode as well if (!betaMode || syncFail) { // new disconnection when in Beta mode connected = FALSE; betaMode = FALSE; toning = FALSE; // ensure the far end sees a “disconnection” syncFail = FALSE; waitTime(2 * DISCONNECTED_TONE_INTERVAL); } } else if (tMode) { // loss of sync or entry into disabled forces disconnection, reset betaMode as well if (!((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) || syncFail) { connected = FALSE; betaMode = FALSE; tMode = FALSE; } } else { // DS mode if (!disabled) { // in P5:suspended state if (receiveOk) return; } connected = dcConnected; // see if still connected } } void disabledActions() { if (betaMode) syncFail = TRUE; if (disableRequest) disableRequest = signaled = FALSE; disabled = TRUE; activateConnectDetect(0); // Enable the connect detect circuit inStandby = FALSE; while (syncFail) // if syncFail is set, wait for background processing ; // (connectionStatus) to clear it } void resumeActions() { if (startResumePort()) { restorePort(); // restore port on nephew while (restoreInProgress()) ; // ok to continue with resume if receiveOk is present in DS ports, // but for Beta ports bportSyncOk should also be set if (watchdog && !portEvent) { portEvent = TRUE; PH_EVENT_indication(PH_INTERRUPT, 0, 0); } while (rxOk && !(resumptionDone && busInitializeActive)) { // Defer bus reset until ready
580
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) if (busInitializeActive && !resumptionDone) // Do nothing if reset commences but we didn’t start it ; else if ((connectTimer >= PORT_ENABLE_TIME) && !okToDetectReset) okToDetectReset = TRUE; // Now safe to detect reset on all resuming ports else if (boundaryNode && (connectTimer >= 3 * RESET_DETECT)) isbr = resumptionDone = TRUE; // NOW, short reset, if node can arb else if (connectTimer >= 7 * RESET_DETECT) ibr = resumptionDone = TRUE; // Sigh! Have to use long reset } } resumeFault = !rxOk; if (betaMode && !rxOk) syncFail = TRUE; // Resume attempt failed if sync lost (for Beta port) or receiveOk is // de-asserted resume = FALSE; // Resume attempt complete if (!resumeInProgress()) // Last resuming port does cleanup okToDetectReset = resumptionDone = FALSE; }
void suspendInitiatorActions() { connectTimer = 0; // Used to debounce receiveOk or for receiveOk handshake doStandby = FALSE; // Port went into suspend during entry to standby if (!suspendRequest) { // Unexpected loss of rxOk? if (betaMode) syncFail = !rxOk; // suspend initiator because of loss of sync? suspendRequest = TRUE; // Ensure suspendInProgress() returns TRUE if (PORTNUM != seniorPort) // Yes, senior still connected? isbr = TRUE; // Arbitrate for short reset else ibr = TRUE; // Transition to R0 for reset activateConnectDetect(0); while (connected && connectTimer < (tMode ? TMODE_DISCONNECT_TIMEOUT : CONNECT_TIMEOUT / 2)) ; // see if rxOk lost because of physical disconnection } else { // Instructed to suspend signaled = FALSE; if (tMode) { while ((connectTimer < TPORT_MAX_LATENCY) && receiveOk) ; // Wait for SUSPEND to reach the target, might get through quickly activateConnectDetect(0); // no wait at this point, just stop transmitting while ((connectTimer < TPORT_SUSPEND_HANDSHAKE) && receiveOk) ; suspendFault = receiveOk; connectTimer = 0; while (connectTimer < TPORT_MIN_SUSPEND_TIME) ; // min time before attempting a resume } else { while ((connectTimer < RECEIVE_OK_HANDSHAKE) && receiveOk) ; suspendFault = receiveOk; // Suspend handshake refused by target? activateConnectDetect(RECEIVE_OK_HANDSHAKE); // Also guarantees min time in suspend for
Copyright © 2008 IEEE. All rights reserved.
581
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) // handshake timing } } } void suspendTargetActions() { if (resumeInProgress()) // Other ports resuming? resume = TRUE; // OK, do suspend handshake but resume afterwards suspendRequest = TRUE; // Ensure suspendInProgress() returns TRUE if (portRArb == DISABLE_NOTIFY) { // Is our peer PHY going away? immediatePhyRequest = TRUE; // Topology change! Reset on other (active) ports isbr = isbrOk = TRUE; if (betaMode) syncFail = TRUE; // force disconnection if other end going into disabled } else if (portRArb == SUSPEND && !resume) { // Don’t propagate if resume in progress suspendAllActivePorts(); immediatePhyRequest = TRUE; // Invoke transmitter to propagate TX_SUSPEND isbr = isbrOk = TRUE; // Alert link that node is now isolated } if (!betaMode) while ((portRArb == DISABLE_NOTIFY) || (portRArb == SUSPEND)) ; // Let signals complete before receiveOk handshake if (tMode) { activateConnectDetect(0); // no wait at while ((connectTimer < TPORT_SUSPEND_HANDSHAKE) ; connectTimer = 0; while (connectTimer < TPORT_MIN_SUSPEND_TIME) ; // min time before attempting a resume } else { activateConnectDetect(RECEIVE_OK_HANDSHAKE); // // }
this point, just stop transmitting && receiveOk)
signal to background process to start connection detection
} void suspendedActions() { suspendRequest = FALSE; while (syncFail) // if syncFail is set, wait for background processing ; // (connectionStatus) to clear it if (resumeFault) { // here because failed to receive Bias or to synchronize if (!connected) { // due to Beta resumeFault activateConnectDetect(0); } else { while (connected && !rxOk && (connectTimer < 12 * RESET_DETECT)) ; // wait longer to see if the resume fault condition clears; wait while // no bias (DS mode only) if (!rxOk) activateConnectDetect(0); } } } void restoreActions() { restore = TRUE; // ensure that node and connectionStatus know we’re restoring if (!proxy) { // Inform nephew link immediately when a restore begins PH_EVENT_indication(PH_RESTORE_NO_RESET, 0, 0); waitPH_EVENT_response(); cancelRequests();
582
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) } if (!startPort()) { // Resume attempt failed if failed to synchronize restore = FALSE; forceDisconnect = TRUE; while (connected) ; if (proxy) isbr = TRUE; // bus reset on disconnection, arbitrated for uncle, else ibr = TRUE; // immediate for nephew proxy = FALSE; // uncle no longer proxies for nephew inStandby = FALSE; activateConnectDetect(0); // signal to background process to start connection detection return; // restore attempt failed } restoreRequest = TRUE; // arbitrate for the bus if (!proxy) immediateRestoreRequest = TRUE; // on nephew while (restore && rxOk) // node level action clears this ; if (!rxOk) { // sync fail while sending/receiving restore packet restore = FALSE; forceDisconnect = TRUE; while (connected) ; if (proxy) isbr = TRUE; // bus reset on disconnection, arbitrated for uncle, else ibr = TRUE; // immediate for nephew proxy = FALSE; // uncle no longer proxies for nephew inStandby = FALSE; activateConnectDetect(0); // signal to background process to start connection detection return; // restore attempt failed } // Connection restored to active state if (watchdog && !portEvent) { portEvent = TRUE; PH_EVENT_indication(PH_INTERRUPT, 0, 0); } inStandby = FALSE; } void standbyInitiatorActions() { inStandby = TRUE; connectTimer = 0; signaled = FALSE;
// for the purpose of port status accounting // Used to debounce receiveOk or for receiveOk handshake
if (tMode) { while ((connectTimer < TPORT_MAX_LATENCY) && receiveOk) ; // Wait for STANDBY to reach the target, might get through quickly activateConnectDetect(0); // no wait at this point, just stop transmitting while ((connectTimer < TPORT_SUSPEND_HANDSHAKE) && receiveOk) ; standbyFault = receiveOk; connectTimer = 0; while (connectTimer < TPORT_MIN_SUSPEND_TIME) ; // min time before attempting a resume } else { while ((connectTimer < RECEIVE_OK_HANDSHAKE) && receiveOk)
Copyright © 2008 IEEE. All rights reserved.
583
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) ; // Wait for suspend target to deassert receiveOk standbyFault = receiveOk; // Standby handshake refused by target? activateConnectDetect(RECEIVE_OK_HANDSHAKE); // Also guarantees handshake timing } } void standbyTargetActions() { inStandby = TRUE; // for the purpose of port status accounting resetNotify = FALSE; // gone into standby since the last reset (note, now a per-port bit) proxy = TRUE; // tell the arb state machine to proxy for this port if (tMode) { activateConnectDetect(0); // no wait at this point, just stop transmitting while ((connectTimer < TPORT_SUSPEND_HANDSHAKE) && receiveOk) ; connectTimer = 0; while (connectTimer < TPORT_MIN_SUSPEND_TIME) ; // min time before attempting a restore } else { activateConnectDetect(RECEIVE_OK_HANDSHAKE); // signal to background process to start // connection detection } } void standbyActions() { doStandby = FALSE; while (!((restore || (!standbyFault disabled)) { if (!connected) { if (proxy) isbr = TRUE; else ibr = TRUE; break; } } } void untestedActions() { untestedState = TRUE; if (!forceDisconnect) { if (startPort()) { if (allPortsSuspended) { resumeAllPorts(); while (resumeInProgress()) ; }
&& receiveOk)) || // exit condition to restore // exit condition to disabled // bus reset on disconnection, arbitrated for uncle, // immediate for nephew
// port is currently sending _NONE arb requests // new connection on a suspended node
// the following needs to be done if this is a new connection restorePort(); // if not a proxying port, then restore the standby while (restoreInProgress()) // port first (if any) and wait for it to restore ; if (NPORT==1) { portT.arb = ATTACH_REQUEST; // single port PHY’s can blindly request an attach portT.speed = DEFAULT; portT.tag = ARB_STATE; while (rxOk && !attach) { if (busInitializeActive) // Don’t allow attach to start in the middle of an existing reset
584
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) ; else if ((portRArb == BUS_RESET) || (portRArb == ATTACH_REQUEST)) isbr = attach = TRUE; // Peer port initiated, // arm resetDetected and attempt a short reset } while (rxOk && !busInitializeActive) ;
// wait for bus reset to start
} else { // not a single port phy portT.arb = SPEED; // start LTS with normal packet start at the port speed portT.speed = DEFAULT; portT.pkt = BETA; portT.tag = ARB_STATE; waitSymbolTime(portSpeed); // send speed signal (single SPEEDb) portT.arb = DATA_PREFIX; waitSymbolTime(portSpeed); // send DATA_PREFIX if (borderNode) // strictly the following test is required to remain true until // tree_ID completes on all legacy ports while (busInitializeActive) ; portT.data = (byte)(HR_mode << 7 | HR_G << 6 | HR_testValue); // Loop test symbol portT.tag = DATA; // send the LTS continuously // now make sure that this won’t create a bus topology loop while (rxOk && !((portRArb == DATA_BYTE) || (portRArb == ATTACH_REQUEST))) ; // wait for LTS coming in (ignoring the DP that will precede it and set in-packet context) or // the ATTACH_REQUEST which can be immediately sent by a single-port PHY untested = rxOk; // Mark port as ready for testing while (rxOk && untested && !(portUnderTest && foundLoop)) { if (portUnderTest && sendAttach) { // second phase - attach the port then activate it portT.arb = ATTACH_REQUEST; // note, can only get here if in control of the bus portT.speed = DEFAULT; portT.tag = ARB_STATE; // wait for reset, attach_request, or timer to expire if (isolatedNode) { attach = TRUE; // release bus and prepare to attach with next bus reset // Note that a bus reset is not scheduled. // Instead, wait as long as possible for resetDetected to hear an inbound reset on this port while (rxOk && !busInitializeActive) { if (portRArb == ATTACH_REQUEST) isbr = TRUE; // Peer port initiated and a short reset can be attempted if (maxOccupancyTimer >= 7*RESET_DETECT) ibr = TRUE; // Peer port failed to initiate, so need to use long reset } untested = FALSE; } else { while (rxOk && !attach) { if (portRArb == BUS_RESET) isbr = attach = TRUE; // Peer port initiated, signal node controller // to release bus and attempt a short reset else if (maxOccupancyTimer >= MAX_OCCUPANCY_TIME) ibr = attach = TRUE; // Peer port failed to initiate, so need to use long reset else if (ibr)
Copyright © 2008 IEEE. All rights reserved.
585
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-7—Port connection manager actions and conditions (continued) attach = TRUE;
// Another port’s untested peer has gotten impatient // and initiated a long bus reset in order to attach, // so release the bus and use reset for attach
} while (rxOk && !busInitializeActive) // wait for bus reset to start ; untested = FALSE; // as its now tested!!! } } else { portT.data = (byte)(HR_mode << 7 | HR_G << 6 | HR_testValue); // Loop test symbol portT.tag = DATA; // send the LTS continuously if (portRArb == ATTACH_REQUEST) { // takes the port out of packet context while (rxOk && busInitializeActive) // Defer bus reset until any current reset completes ; if (bportSyncOk) // If still synchronized, mark port to be attached. isbr = attach = TRUE; // Note that although a short bus reset is scheduled, // it will have no effect if the node has scheduled // an ATTACH_REQUEST of it’s own on another port and // has retained control of the bus (isolated nodes // are the exception). In such a case, the node // awaits an ATTACH_REQUEST, BUS_RESET, or timeout // on the testPort, or for this port to get // impatient and set the ibr flag below. while (rxOk && !busInitializeActive) // wait for bus reset to start if (portRArb == BUS_RESET) // Peer port has gotten impatient. Signal ibr = TRUE; // portUnderTest, if any, to release bus untested = FALSE; // as its now tested!!! } else if (portRArb == BUS_RESET) { // takes the port out of packet context while (rxOk && busInitializeActive) // Defer bus reset until any current reset completes ; if (rxOk) // If still synchronized, mark port to be attached. ibr = attach = TRUE; // Use a long bus reset since the far end has initiated. while (rxOk && !busInitializeActive) // wait for bus reset to start ; untested = FALSE; // as its now tested!!! } } } // end of loop while untested } // end of if NPORT==1 else ... statement } // end of if startPort() } loopDisabled = (portUnderTest && foundLoop); if (!rxOk || forceDisconnect) loopDisabled = TRUE; untested = FALSE; // as its now tested!!! attach = FALSE; // Attach attempt complete untestedState = FALSE; // will always take one of the transitions immediately } void loopDisabledActions() { if (tMode) { activateConnectDetect(0); // no wait at this point, just stop transmitting while ((connectTimer < TPORT_SUSPEND_HANDSHAKE) && receiveOk)
586
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-7—Port connection manager actions and conditions (continued) ; connectTimer = 0; while (connectTimer < TPORT_MIN_SUSPEND_TIME) ; // min time before attempting transit to untested } else { activateConnectDetect(RECEIVE_OK_HANDSHAKE); // signal to background process to start // connection detection } while ((PMD_STATUS_request() & PMD_SIGNAL_DETECT) && !(forceDisconnect && !connected)) ; // Wait til peer becomes inactive or local port ready // to transition to P0 because of forceDisconnect event }
19.3 Port state machine actions This subclause specifies port state machine actions for DS, Beta, and T-mode ports.
Copyright © 2008 IEEE. All rights reserved.
587
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
19.3.1 DS port The operation of DS ports (see 9.2) is specified in this subclause. Table 19-8 covers the DS receive port operation, Table 19-9 covers the DS transmit port operation, and Table 19-10 covers DS speed filtering.
Table 19-8—DS receive port //dsport_rx.c #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
tpSig oldData, oldStrobe; byte currentByte; int currentBit; boolean pkt; boolean foundClock;
// Memory of last signal received
// when true, port is receiving a packet // shared signal to detect loss of recovered clock
// Decode DS stream and load FIFO -- this routine is always running // (speed code recording is also done here) void decodeBit() { rxSignal newSignal; tpSig newData, newStrobe; portSymbol last; portSymbol symbol; boolean biasIsOn ; boolean okToReportSpeed; boolean pktPrefix; // when true, port is receiving packet prefix while (powerReset || !dsportOn) { last.tag = DS_RAW_ARB; last.rxDSArb = RX_IDLE; last.speed = S100; biasIsOn = FALSE; okToReportSpeed = TRUE; if (powerReset) fifoWrPtr = 0; pktPrefix = FALSE; } if (bias) { biasIsOn = TRUE; if (dsPortRSpeed > S100) { // Look for speed signal received if (okToReportSpeed) { last.tag = symbol.tag=ARB_STATE; last.arb = symbol.arb=SPEED; last.speed = symbol.speed=dsPortRSpeed; symbol.pkt=LEGACY; push(symbol); okToReportSpeed = FALSE; // avoid multiple reports of this speed } } else okToReportSpeed = TRUE; // when the speed detection has gone back to S100 levels newSignal = PMD_DSPORT_SIGNAL_request(); // Get signal if (pkt || pktPrefix) { // expecting data, process data and strobe receivers newData = newSignal.data.tpA; // Received data is on TPA newStrobe = newSignal.data.tpB; // Received strobe is on TPB if ((newStrobe != oldStrobe) || (newData != oldData)) {
588
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-8—DS receive port (continued) // Either data or strobe changed pktPrefix = FALSE; // found a recoverd clock edge, so prefix has ended pkt = TRUE; // and data has nominally begun foundClock = TRUE; // tell stopped clock detector that an edge was found if (currentBit == 8) { // if already got a byte then it can’t be a byte of dribble bits, so last.tag = symbol.tag = DATA; symbol.data=currentByte; push(symbol); // Advance or wrap FIFO pointer currentBit = 0; currentByte = 0; } currentByte |= (byte)(((newData == H)?1:0) << (7-currentBit)); currentBit++; } oldStrobe = newStrobe; oldData = newData; } else { // not expecting data, process arb comparators // Note : While the local port is transmitting serial data, the arbitration // comparators are presumed to be disabled or ignored to prevent false queuing of // data patterns as received arbitration indications. While not explicitly // described in the C code, such operation is presumed by this implementation. switch (newSignal.rxArb) { case RX_DATA_PREFIX: // Note: Short periods of RX_DATA_PREFIX normally occur during tree-ID // (while in T1:Child_Handshake waiting for the peer port to transition to // the S0:Self_ID_Start state) and at the end of packet transmission when // the outbound TX_DATA_END is interpreted as an inbound RX_DATA_PREFIX. // Implementations are encouraged to implement filtering designed to // remove such false indications. The method of such filtering is // beyond the scope of this C code but its presence is presumed by this // code to prevent the false arming of the clock extraction logic and to // prevent the false reporting of RX_DATA_PREFIX to processRequests() pktPrefix = TRUE; // Possible start of packet, enable recovered clock last.tag = symbol.tag = DS_RAW_ARB; last.rxDSArb = symbol.rxDSArb = RX_DATA_PREFIX; push(symbol); oldData = 1; oldStrobe = 0; currentBit = 0; currentByte = 0; break; case RX_DATA_END: // aka RX_PARENT_HANDSHAKE case RX_IDENT_DONE: case RX_IDLE: case RX_BUS_RESET: case RX_REQUEST: // aka RX_SELF_ID_GRANT case RX_GRANT: // aka RX_ROOT_CONTENTION, aka RX_SUSPEND case RX_PARENT_NOTIFY: // aka RX_REQUEST_CANCEL case RX_CHILD_HANDSHAKE: // aka RX_DISABLE_NOTIFY if (!((last.tag == DS_RAW_ARB) && (last.rxDSArb == newSignal.rxArb))) { last.tag = symbol.tag = DS_RAW_ARB; last.rxDSArb = symbol.rxDSArb = newSignal.rxArb; push(symbol); } break;
Copyright © 2008 IEEE. All rights reserved.
589
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-8—DS receive port (continued) } } } else { // no bias if (biasIsOn ) { // detect falling edge of bias last.tag = symbol.tag = DS_RAW_ARB; last.rxDSArb = symbol.rxDSArb = RX_IDLE; push(symbol); // ensure that FIFO is not stuck } biasIsOn = FALSE; okToReportSpeed = TRUE; } } // Detect the absence of a recovered clock to determine when receipt of the data // payload has concluded. This implementation is behavioral only as many alternative // methods for detecting the end of a packet are possible void stoppedClockDetector() { int i; if (powerReset || !dsportOn) { foundClock = FALSE; pkt = FALSE; } else if (pkt) { foundClock = FALSE;
// clear indication of a recovered clock, // and wait to see if another appears for (i = 0; i < (2<
} }
590
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-9—DS transmit port // dsport_tx.c #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
dataBit txData, txStrobe; speedCode dataSpeed;
// Memory of last signal sent on DS ports
txArbState encode(arbState arbState) { switch (arbState) { case DATA_END: return(TX_DATA_END); case GRANT: return(TX_GRANT); case DATA_PREFIX: return(TX_DATA_PREFIX); case BUS_RESET: return(TX_BUS_RESET); case CHILD_NOTIFY: return(TX_CHILD_NOTIFY); // case IDENT_DONE: return(TX_IDENT_DONE); // identical to CHILD_NOTIFY case PARENT_NOTIFY: return(TX_PARENT_NOTIFY); case DISABLE_NOTIFY: return(TX_DISABLE_NOTIFY); case SUSPEND: return(TX_SUSPEND); case LEGACY_REQUEST: return(TX_REQUEST); case IDLE: return(TX_IDLE); case SPEED_RAW: return(TX_IDLE); default: return(TX_IDLE); // assert error - cannot occur } } void dsTxBit(dataBit bitToSend) { // Transmit a bit on all transmitting DS ports int i; portData pd; if (bitToSend == txData) // If no change in data txStrobe = txStrobe == 0 ? 1 : 0; // Invert strobe txData = bitToSend; pd.tpA = (txStrobe == 1)? H:L; pd.tpB = (txData == 1)? H:L; PMD_DSPORT_DATA_request(pd); //wait for next port bit time for (i=0; i < (1 << (DS_PHY_SPEED-dataSpeed));i++) waitEvent(PH_DS_BIT_CLOCK); } void dsTxByte(byte dataByte) { // Transmit a byte int i; for (i = 0; i < 8; i++ ) dsTxBit((dataByte >> (7-i)) & 0x1); } void txDribbleBits(txArbState endingStatus, boolean inPacket) { int i; if (inPacket) { // Local port has sent data bits and is required to send real // dribble bits switch (dataSpeed) { // Bit width of PHY/link interface may require pad bits case S400: // Pad with six extra (dribble) bits, 8 total dsTxBit(1);
Copyright © 2008 IEEE. All rights reserved.
591
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-9—DS transmit port (continued) dsTxBit(1); dsTxBit(1); dsTxBit(1); dsTxBit(1); dsTxBit(1); break; case S200: dsTxBit(1); dsTxBit(1); break; default: break;
// Pad with two extra (dribble) bits, 4 total
// No need for extra (dribble) bits } dsTxBit(endingStatus == TX_DATA_PREFIX ? 1 : 0); PMD_DSPORT_ARB_request(endingStatus); // ...and the last dribble bit } else { // Local port hasn’t sent any data bits, so continue DATA_PREFIX // for the dribble bit duration (equal to 2 S100 bit times) for (i=0; i < (2 << (DS_PHY_SPEED-S100));i++) waitEvent(PH_DS_BIT_CLOCK); PMD_DSPORT_ARB_request(endingStatus); } } void dsportTransmitActions() { // continuously running boolean inPacket; // tracks whether local port has sent actual data bits while (powerReset || !dsportOn) { inPacket = FALSE; dataSpeed = S100; } if(portT.tag==DATA) { inPacket = TRUE; dsTxByte(portT.data); } else { // tag == ARB_STATE switch(portT.arb) { case DATA_PREFIX: case DATA_NULL: if (nonNullPacket) // DP or DN at the end of a packet txDribbleBits(TX_DATA_PREFIX, inPacket); inPacket = FALSE; // dataSpeed is carried over from previous packet if not // already set by a speed signal on this packet PMD_DSPORT_TXSPEED_request(S100); // turn off speed signaling if going txData = 1; // Initialize the memory of last signal sent on DS ports txStrobe = 0; PMD_DSPORT_ARB_request(TX_DATA_PREFIX); break; case SPEED: inPacket = FALSE; dataSpeed = portT.speed; // start tx of speed and memorize it PMD_DSPORT_ARB_request(TX_DATA_PREFIX); PMD_DSPORT_TXSPEED_request(dataSpeed); break; case IDENT_DONE: // control speed signal drivers directly (for self_ID) case SPEED_RAW: PMD_DSPORT_ARB_request(encode(portT.arb)); switch (portT.speed) { case S100:
592
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-9—DS transmit port (continued) case S200: case S400: PMD_DSPORT_TXSPEED_request(portT.speed); break; default: // ignore speed codes other than S100, S200, or S400 PMD_DSPORT_TXSPEED_request(S100); break; } break; case DATA_END: if (nonNullPacket) // add dribble bits unless a NULL packet txDribbleBits(TX_DATA_END, inPacket); inPacket = FALSE; dataSpeed = S100; // ready for next packet PMD_DSPORT_ARB_request(TX_DATA_END); break; case IDLE: case ARB_CONTEXT: inPacket = FALSE; dataSpeed = S100; PMD_DSPORT_ARB_request(TX_IDLE); break; default: PMD_DSPORT_ARB_request(encode(portT.arb)); break; } waitEvent(PH_DS_BIT_CLOCK); } }
Table 19-10—DS speed signaling filter // speed.c #define unsubscripted #include “1394.h” #include “data_structures.h” #include “phy_services.h” #include “shared.h” void speedFilter() { int i; boolean okToSample; speedCode rawSpeed[2]; rxSignal newSignal; rawSpeed[0] = S100;
// Continuously sample speed signals
// Unfiltered speed (moving window of two samples) // error if used before being set (by lack of bias)
while (TRUE) { if (!bias) rawSpeed[0] = S100; // reset when no bias for (i = 0; i < (2<
Copyright © 2008 IEEE. All rights reserved.
593
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-10—DS speed signaling filter (continued) } else if (PMD_DSPORT_RXSPEED_request() & RX_S200) // S200 observed? rawSpeed[0] = S200; else rawSpeed[0] = S100; // No to both: default S100 okToSample = newSignal.rxArb == RX_CHILD_HANDSHAKE // transmitting TX_IDENT_DONE || newSignal.rxArb == RX_IDENT_DONE || newSignal.rxArb == RX_DATA_PREFIX; if (!okToSample) dsPortRSpeed = S100; // Reset to S100 whenever it’s not OK to sample else if (rawSpeed[0] == rawSpeed[1]) { // Consecutive identical samples? if (rawSpeed[0] == S200 && dsPortRSpeed < S400) dsPortRSpeed = S200; // Latch S200 only if S400 not yet confirmed else if (rawSpeed[0] == S400) dsPortRSpeed = S400; else dsPortRSpeed = S100; } } }
594
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
19.3.2 Beta port The operation of Beta ports (see 9.3) is specified in this subclause. Table 19-11 covers the Beta receive port operation and Table 19-12 covers the Beta transmit port operation.
Table 19-11—Beta port receive actions and conditions // bport_rx.c #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
// variables global to two or more routines in the receive state machine int charCheck; int characterIn; int descram; int descramOld; #define DESCRAM_TRAIN_CYCLES 22 disparityType disparityIndicator; delimiter int invalidCount; boolean invalidSpeedCode; int lastCharacterIn; portSymbol lastLocalR; portSymbol localR; boolean newSpeedCode; int padRatio; boolean pkt; boolean pktPrefix; int polarity; int portErrorReg; boolean rxComma; speedCode rxPktSpeed; pktType rxPktType; disparityType rxRd; int rxReq; boolean rxReqCode; a Dx.0 or Dx.4 int rxScramReq; int rxSpeedDiff; boolean rxSyncError; boolean scramblerSync; boolean scramblerSyncError;
// rightmost 8 bits of descrambler state // represents present state of descrambler // disparity indicated by a received DATA_PREFIX packet
// record of last localR // record of decoded received symbol // TRUE until SPEEDa or SPEEDb in speed code
// when true, port is receiving a packet // when true, port is receiving packet prefix // when 1, the polarity of received character stream is // deliberately inverted by port. // record of number of coding errors detected // true when the most recently received character was a K28.5 // speed of received packet // type of packet format received // disparity of received character stream, takes values // NEGATIVE_RD and POSITIVE_RD (encoded as 0 and 1 respectively) // request type value // true when the most recently received character was
boolean speedKnown; #define SYNC_CHECK 17 boolean trainDescrambler;
// scrambled request type value // TRUE if failed to complete synchronization // TRUE if unexpected request type is received // during scrambler synchronization // true after Sa or Sb has been received or first byte of // packet withouta speed signal (S100 legacy packet only) // when true receiver should train scrambler // using samples from received signals
int validCount; // first, useful functions and routines
Copyright © 2008 IEEE. All rights reserved.
595
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) // shared between bport_rx and bport_tx disparityType updateRd(int character, disparityType rd) { int i, noOfOnes=0; for (i=0; i<6; i++) if (((character <
3 || (character & 0x3F0)==0x070) rd = POSITIVE_RD; // rd is positive if 6 MSBs are 000111 else if (noOfOnes<3 || (character & 0x3F0)==0x380) rd = NEGATIVE_RD; // rd is negative if 6 MSBs are 111000 noOfOnes=0; for (i=6; i<10; i++) if (((character <2 || (character & 0xF)==0x3) rd = POSITIVE_RD; // rd is positive if 4 lsb’s are 0011 else if (noOfOnes<2 || (character & 0xF)==0xC) rd = NEGATIVE_RD;// rd is negative if 4 lsb’s are 1100 return (rd); } // shared between Beta and DS receive ports void push(portSymbol symbolToPush) { // Regardless of whether the FIFO is full, always write the latest symbol to FIFO // (overwriting the last written element, if necessary) so that a final packet ending // state is guaranteed to be pushed into the FIFO. Take care, however, to prevent the // write pointer from advancing to become equal to the read pointer which would // signify an empty FIFO. int newPointer = (fifoWrPtr + 1) % FIFO_DEPTH; if (newPointer != fifoRdPtr) fifoWrPtr = newPointer; portR[fifoWrPtr]=symbolToPush; } // Called whenever a data byte was expected, but not received. To prevent // the fifo unloading side from experiencing an underrun due to 8b/10b bit // errors, some data are pushed into the fifo for every byte at the packet // rate. When an expected data byte isn’t found, this routine synthesizes // a valid data byte by way of example. This implementation isn’t intended // to preclude the selection of other synthesized symbols including other // data values or other characters. void pushDataZero() { portSymbol dataSymbol; dataSymbol.tag=DATA; dataSymbol.data=0x00; push(dataSymbol); } boolean portErrorMonitor() { if(localR.tag==INVALID) { invalidCount=(invalidCount==4? 4:invalidCount+1); validCount=0; } else { if(invalidCount>0) { validCount++; if(validCount>1) { invalidCount=invalidCount-1; // If second consecutive valid then decrement invalid counter validCount=0;
596
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-11—Beta port receive actions and conditions (continued) } } } return (invalidCount==4); // Sync lost on reaching threshold of four, causing receiver to enter rx sync lost state } void rxControlMap(int rxCtrl) { switch(rxCtrl) { case 0x0: localR.tag=INVALID; break; case 0x1: localR.tag=ARB_STATE; localR.arb=CYCLE_START_EVEN; break; case 0x2: localR.tag=ARB_STATE; localR.arb=CYCLE_START_ODD; break; case 0x3: localR.tag=ARB_STATE; localR.arb=ATTACH_REQUEST; break; case 0x4: localR.tag=ARB_STATE; localR.arb=SPEEDa; break; case 0x5: localR.tag=ARB_STATE; localR.arb=DATA_END; break; case 0x6: localR.tag=ARB_STATE; localR.arb=DATA_NULL; break; case 0x7: localR.tag=ARB_STATE; localR.arb=SPEEDb; break; case 0x8: localR.tag=ARB_STATE; localR.arb=GRANT; break; case 0x9: localR.tag=ARB_STATE; localR.arb=DATA_PREFIX; disparityIndicator=POSITIVE_RD;break; case 0xa: localR.tag=ARB_STATE; localR.arb=DATA_PREFIX; disparityIndicator=NEGATIVE_RD;break; case 0xb: localR.tag=ARB_STATE; localR.arb=GRANT_ISOCH; break; case 0xc: localR.tag=ARB_STATE; localR.arb=SPEEDc; break; case 0xd: localR.tag=ARB_STATE; localR.arb=ASYNC_EVEN; break; case 0xe: localR.tag=ARB_STATE; localR.arb=ASYNC_ODD; break; case 0xf: localR.tag=ARB_STATE; localR.arb=BUS_RESET; break; } } void requestTypeMap(int request) { int asyncPart; // numerical representation of the asynchronous request type int isochPart; // numerical representation of the isochronous request type betaRequestCode rxrequest; asyncPart = (request & 0xE0) >> 5; isochPart = (request & 0x1) | ((request & 0x18) >> 2); if(isochPart==0) { // configuration request type switch(asyncPart) { case 0x0: localR.tag=CONFIG_REQUEST; localR.arb=TRAINING; break; case 0x1: localR.tag=CONFIG_REQUEST; localR.arb=DISABLE_NOTIFY; break; case 0x2: localR.tag=CONFIG_REQUEST; localR.arb=CHILD_NOTIFY | IDENT_DONE ; break; case 0x3: localR.tag=CONFIG_REQUEST; localR.arb=OPERATION; break; case 0x4: localR.tag=CONFIG_REQUEST; localR.arb=STANDBY; break; case 0x5: localR.tag=CONFIG_REQUEST; localR.arb=SUSPEND; break; case 0x6: localR.tag=CONFIG_REQUEST; localR.arb=PARENT_NOTIFY; break; case 0x7: localR.tag=INVALID; break; } } else if (isochPart==0x3) { // LEGACY_REQUEST or LEGACY_PHASE localR.tag=LEGACY_ARB; localR.arb=((asyncPart & 0x4) == 0x4) ? LEGACY_PHASE : LEGACY_REQUEST; localR.data= (byte) (asyncPart & 0x3); // phase information } else { rxrequest.async = A_NONE; // initialize to keep compiler happy in the case of INVALID tag rxrequest.isoch = I_NONE; switch(asyncPart) {
Copyright © 2008 IEEE. All rights reserved.
597
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) case case case case case case case case
0x0: 0x1: 0x2: 0x3: 0x4: 0x5: 0x6: 0x7:
localR.tag=INVALID; break; localR.tag=ARB_REQUEST; rxrequest.async=CURRENT; break; localR.tag=ARB_REQUEST; rxrequest.async=NEXT_EVEN; break; localR.tag=ARB_REQUEST; rxrequest.async=CYCLE_START_REQ; break; localR.tag=ARB_REQUEST; rxrequest.async=NONE_ODD; break; localR.tag=ARB_REQUEST; rxrequest.async=NEXT_ODD; break; localR.tag=ARB_REQUEST; rxrequest.async=NONE_EVEN; break; localR.tag=ARB_REQUEST; rxrequest.async=BORDER; break;
} if (localR.tag != INVALID) { switch(isochPart) { case 0x0: localR.tag=INVALID; break; case 0x1: localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_CURRENT; break; case 0x2: localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_NONE; break; case 0x3: localR.tag=INVALID; break; case 0x4: localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_EVEN; break; case 0x5: localR.tag=INVALID; break; case 0x6: localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_ODD; break; case 0x7: localR.tag=INVALID; break; } } localR.req=rxrequest; } } int rxControlDecode(int characterIn) { int i; for (i=0; i<16; i++) { if (characterIn==controlTable[i]) return(i); // check for a Cz } return(-1); } int rxReqtypeDecode(int characterIn, disparityType rd) { int i; for (i=0; i<256; i++) { if (characterIn==dataTable[i][rd]) return((i & 0x6) == 0 ? i: -1); // check Dx.0’s and Dx.4’s } return(-1); } int rxDataDecode(int characterIn, disparityType rd) { int i; for (i=0; i<256; i++) { if (characterIn==dataTable[i][rd]) return(i); // check all Dx.y’s } return(-1); } int rxCommaDecode(int characterIn, disparityType rd) { if (characterIn==commaTable[rd]) return(0x38); // check for a K28.5, and, if so, // decode as if D28.0 (NB bits reversed)
598
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-11—Beta port receive actions and conditions (continued) else return(-1); } void updateDescrambler() { int i; int descramNew;
// next state
if (trainDescrambler && (rxScramReq >= 0)) descramOld = (descramOld & 0x7FE) | (rxScramReq & 0x001); // replacing rxScramReq bit 0 (from the right) into descramOld when training descrambler descramNew = descramOld; for (i=0; i<8; i++) { descramNew = descramNew << 1; descramNew = descramNew | (((descramOld & 0x400) >> 10) ^ ((descramOld & 0x100) >> 8)); descramOld = descramNew; } descram = descramOld & 0x0FF;
// used for XORing with input byte
} boolean rxCharacter() { int i; pmdDataIndicationService pmdData; dataBit receivedBit; int rx_scram_data; int rx_scram_ctrl; int rx_control; lastLocalR=localR; lastCharacterIn=characterIn; rxComma=FALSE; rxReqCode=FALSE; characterIn=0; for (i=0;i<10;i++) { pmdData = waitPMD_DATA_indication(); receivedBit = pmdData.data; characterIn = (characterIn << 1) | (receivedBit ^ polarity); } rx_scram_ctrl = rxScramReq = rx_scram_data = -1; // Reset remaining result from last character if((rx_scram_ctrl=rxControlDecode(characterIn))>=0) { rx_control=(rx_scram_ctrl^(((descram&0x80)>>4) | ((descram&0x20)>>3) | ((descram&0x8)>>2) | ((descram&0x2)>>1))); rxControlMap(rx_control); } else if(((rxScramReq=rxReqtypeDecode(characterIn,rxRd)) >=0) && !pkt && !pktPrefix){ rxReqCode=TRUE; rxReq=(rxScramReq ^ descram) & 0xF9; requestTypeMap(rxReq); } else if(((rx_scram_data=rxDataDecode(characterIn,rxRd))>=0) && (pkt || pktPrefix) ) { localR.tag=DATA; localR.data=(byte)(rx_scram_data ^ descram); } else if(((rxScramReq=rxCommaDecode(characterIn, rxRd))>=0) && !pkt && !pktPrefix) { rxComma=TRUE;
Copyright © 2008 IEEE. All rights reserved.
599
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) rxReqCode=TRUE; rxReq=(rxScramReq ^ descram) & 0xF9; requestTypeMap(rxReq); } else localR.tag=INVALID; updateDescrambler(); if (rx_scram_ctrl < 0) rxRd=updateRd(characterIn, rxRd); // control characters are all neutral disparity. // updateRd() should never be used for control characters. if (localR.tag == ARB_STATE && localR.arb==DATA_PREFIX) rxRd=disparityIndicator; // rd is always reset when a data prefix symbol is received. return(portErrorMonitor()); // check that synchronization is OK } boolean characterSync() { rxCharacter(); if (rxReqCode) charCheck = charCheck == 3 ? 3 : charCheck + 1; else charCheck=0; return (rxComma && (charCheck == 3)); }
boolean bspeedFilter() { if (pkt) return(FALSE); if (localR.tag==ARB_STATE && (localR.arb==SPEEDa || localR.arb==SPEEDb || localR.arb==SPEEDc) && newSpeedCode && (lastLocalR.tag == INVALID)) { // bad symbol either immediately before speed code invalidSpeedCode = TRUE; // or before the speed and format is determined speedKnown = FALSE; // invalidate memory of previous speed code } else if (localR.tag==ARB_STATE && localR.arb==SPEEDc) { rxSpeedDiff++; // for every SPEEDc increase the speed ratio... } else if (!invalidSpeedCode && localR.tag==ARB_STATE && localR.arb==SPEEDa) { rxPktSpeed=(speedCode)(portSpeed-rxSpeedDiff); // actual speed is a function of the port speed padRatio = (1 << rxSpeedDiff); rxSpeedDiff = 0; // ready for reading the next speed code rxPktType=LEGACY; // SPEEDa indicates a legacy packet. speedKnown=TRUE; newSpeedCode = FALSE; return(TRUE); } else if (!invalidSpeedCode && localR.tag==ARB_STATE && localR.arb==SPEEDb) { rxPktSpeed=(speedCode)(portSpeed-rxSpeedDiff); // actual speed is a function of the port speed padRatio = (1 << rxSpeedDiff); rxSpeedDiff = 0; // ready for reading the next speed code rxPktType=BETA; // SPEEDb indicates a Beta packet. speedKnown=TRUE; newSpeedCode = FALSE; return(TRUE); }
600
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-11—Beta port receive actions and conditions (continued) return(FALSE); } void trainCharacterSync() { standard.
// behavioral only: method is beyond scope of this
int i, j; pmdDataIndicationService pmdData; dataBit receivedBit; int rxBits; // holds serial bit history for comma detection // Only 16 bits are needed since the comma is 7 bits in length rxBits=(lastCharacterIn << 6) | (characterIn >> 4); j = 0; for (i=0; i<10; i++) { if((rxBits>>9 == 0x1f) || (rxBits>>9 == 0x60)) { j = i; break; } rxBits = (rxBits << 1) & 0xFFFF; } // if a comma was found and it was not properly aligned, j will be non// zero and will represent the distance from the comma to the next // symbol boundary. for (i=1; i<=j; i++) { pmdData = waitPMD_DATA_indication(); receivedBit = pmdData.data; characterIn = (characterIn << 1) | (receivedBit ^ polarity); } } // and now the main actions void rxOffActions() { while (powerReset) { fifoWrPtr = 0; } syncLostSignal=TRUE; until the syncErrorSignal=TRUE;
// Ensures transmit state machine will stay in PTX1 // receive state machine has achieved character sync // Ensures transmit state machine will stay in PTX2 after // character sync until the receive state machine has // detected remote synchronization // count of invalid symbols - used in a monitor with
validCount = invalidCount = 0; hysteresis // invalidCount will increase to 4 during synchronization, and // then decrease to 0 during PRX3: Local Sync polarity = 0; // reset polarity to “not inverting” characterIn = lastCharacterIn = 0; descram = descramOld = 0; localR.tag = lastLocalR.tag = INVALID; pkt = pktPrefix = FALSE; trainDescrambler = FALSE; } void rxSyncLostActions() {
Copyright © 2008 IEEE. All rights reserved.
601
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) syncLostSignal=TRUE; // rxRd=NEGATIVE_RD; // charCheck = 0; // while (!characterSync() && bportOn) trainCharacterSync(); //
signal transmit channel to send training request. initialization of rd initialize charCheck count acquire character synchronization
} void scramblerSyncActions() { int i; int syncCounter; syncCounter=0; scramblerSync=FALSE; scramblerSyncError=FALSE; trainDescrambler=TRUE; i=0; while(bportOn && i
602
// condition for transition to rx_sync_done state.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-11—Beta port receive actions and conditions (continued) syncCounter=0; } } } void rxSyncActions() { int syncCounter; boolean remote_sync_lost; syncLostSignal = FALSE; remote_sync_lost=TRUE;
// // // //
causes transmitter to send OPERATION request and indicates to receiver that lock has been achieved receiver does not assume peer node is synchronized until following checks are complete
rxSyncError=FALSE; // Following routine checks for a sequence of valid OPERATION request // symbols. This indicates that the connected port is also synchronized and // the check is required to occur before receiver transitions to receive state. syncCounter=0; while(bportOn && !rxSyncError && remote_sync_lost) { rxCharacter(); if(localR.tag==CONFIG_REQUEST && localR.arb==TRAINING) syncCounter=0; else if(localR.tag==CONFIG_REQUEST && localR.arb==OPERATION) { if ((lastLocalR.tag==CONFIG_REQUEST) && (lastLocalR.arb==OPERATION)) syncCounter++; else syncCounter=0; } else rxSyncError=TRUE; if(syncCounter==SYNC_CHECK) remote_sync_lost=FALSE; } // Once connected port is seen to be synchronized, allow some extra time for remote // port to receive sufficient operation requests to know local sync is done. // If remote port sends a control signal then it knows local sync is done. // At same time, local port may determine context of signals. if (bportOn && !rxSyncError) { syncCounter=0; while(bportOn && syncCounter<SYNC_CHECK && (localR.tag==CONFIG_REQUEST)) { syncCounter++; rxCharacter(); } syncErrorSignal = FALSE; // This causes transmitter to resume normal operation and receiver transitions to receive state. } } void bportReceiveActions() { // Equivalent mostly to 1394-1995 decodeBit routine. int padCount=0; // keeps track of padding boolean pushedConfigRequest = FALSE; boolean pushedSpeed = FALSE; portSymbol speedSymbol; pkt=speedKnown=FALSE; newSpeedCode = TRUE; invalidSpeedCode = FALSE; rxSpeedDiff=0; pktPrefix=FALSE;
Copyright © 2008 IEEE. All rights reserved.
603
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) while(bportOn && !syncErrorSignal) { // rxCharacter() has been called at end of rxSyncActions() // If received character completes a valid speed signal, then a packet prefix is arriving. // Speed signal is placed in fifo, and fifo update is turned on. if (bspeedFilter()) { speedSymbol.tag=ARB_STATE; speedSymbol.arb=SPEED; speedSymbol.speed=rxPktSpeed; speedSymbol.pkt=rxPktType; push(speedSymbol); pktPrefix=TRUE; // in case no data prefix was already received } else { if (invalidSpeedCode && busInitializeActive) ibr = TRUE; // error recovery if (localR.tag == ARB_STATE && (localR.arb==SPEEDa || localR.arb==SPEEDb || localR.arb==SPEEDc)) { // ignore unless in position of expected data if (pkt && padCount==0) pushDataZero(); // Padding in wrong place } else if (localR.tag==INVALID) { if (portErrorReg < 255) portErrorReg++; // increment error counter if (pkt && padCount==0) pushDataZero(); // if a packet payload character, substitute 0x00 } // If data are received then the packet has started, and packet prefix is done. // Position of data relative to padding is checked. // Fifo update is turned on (if not already). else if (localR.tag==DATA) { if (padCount==0) { pushedSpeed = FALSE; if (!speedKnown) { // Normally S100 legacy packet without speed code! if (!busInitializeActive && bBus) { // For error recovery on a bBus, force Beta format speedSymbol.tag=ARB_STATE; speedSymbol.arb=SPEED; speedSymbol.speed=S100; speedSymbol.pkt=BETA; push(speedSymbol); pushedSpeed = TRUE; // flag to squash the data symbol } padRatio = (1 << portSpeed); // 0 for S100, 1 for S200, 2 for S400 . . . speedKnown = TRUE; } pkt=TRUE; pktPrefix=FALSE; newSpeedCode = TRUE; // ready for next speed code invalidSpeedCode = FALSE; // If receiving an LTS, only buffer first occurence of each new data byte.
For all
other // packet sequences, buffer each received byte if (!(pushedSpeed || (untestedState && (lastLocalR.tag == DATA) && (lastLocalR.data == localR.data)))) push(localR); } } else if(localR.tag==ARB_STATE) { // any arb state except SPEEDa, SPEEDb or SPEEDc if(localR.arb==DATA_PREFIX) { if ((lastLocalR.tag==INVALID) && busInitializeActive)
604
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-11—Beta port receive actions and conditions (continued) // might have missed a single speed symbol ibr = TRUE; if(pkt) { pktPrefix=TRUE; pkt=FALSE;
// concatenated packet // speedKnown remains true to allow for concatenated // packet without speed code at the same speed } else if(!pktPrefix) pktPrefix=TRUE; } else { pktPrefix=FALSE; pkt=speedKnown=FALSE; } rxSpeedDiff=padCount=0; // Buffer first occurence of each new arbitration state.... if (!((lastLocalR.tag == ARB_STATE) && (lastLocalR.arb == localR.arb))) push(localR); newSpeedCode = TRUE; // ready for next speed code invalidSpeedCode = FALSE; } if(localR.tag==ARB_REQUEST) { // Buffer first occurence of each new arbitration request.... if (!((lastLocalR.tag == ARB_REQUEST) && (lastLocalR.req.isoch == localR.req.isoch) && (lastLocalR.req.async == localR.req.async))) push(localR); } if(localR.tag==LEGACY_ARB) { // Buffer first occurence of each new LEGACY request or indication.... if (!((lastLocalR.tag == LEGACY_ARB) && (lastLocalR.arb == localR.arb) && (lastLocalR.data == localR.data))) push(localR); } if(localR.tag==CONFIG_REQUEST) { // Filter Config Requests // required that two consecutive identical config requests are received // before one is pushed // but only push one for any consecutive sequence of identical requests if ((lastLocalR.tag == CONFIG_REQUEST) && (lastLocalR.arb == localR.arb)) { if (!pushedConfigRequest) { localR.tag = ARB_STATE; // convert to arb state push(localR); localR.tag = CONFIG_REQUEST; // ready for comparison with the next one pushedConfigRequest = TRUE; } // pushed config_request always TRUE at this point } else pushedConfigRequest = FALSE; // on non-matching config request } else pushedConfigRequest = FALSE; // or on anything that is not a config request if (pkt) { padCount = (padCount+1) % padRatio; }
Copyright © 2008 IEEE. All rights reserved.
605
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-11—Beta port receive actions and conditions (continued) } syncErrorSignal=rxCharacter(); } localR.tag = ARB_STATE; localR.arb = IDLE; push(localR); pkt=speedKnown=FALSE; rxSpeedDiff=padCount=0; pktPrefix=FALSE;
// ensure that the FIFO is not stuck
}
Table 19-12—Beta port transmit actions and conditions // bport_tx.c #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
boolean disable_scrambler; disables use
portSymbol localT; int scram; int scramOld; disparityType txRd;
// value of disable_scrambler register, when TRUE, // of the scrambler outputs for scrambling packet data // maintained as a bit in the port’s register map // variable that indicates signal to be sent on port // represents the rightmost 8 bits of scrambler state // represents present state of scrambler // disparity of transmitted character stream, takes values // NEGATIVE_RD and POSITIVE_RD (encoded as 0 and 1 respectively)
// first, useful functions and routines int controlSymbolMap(arbState txCtrl, disparityType rd) { // Returns a numerical representation for a control token switch(txCtrl) { case CYCLE_START_EVEN: return(0x1); break; case CYCLE_START_ODD: return(0x2); break; case ATTACH_REQUEST: return (0x3); break; // ARB_CONTEXT overloaded here case SPEEDa: return(0x4); break; case DATA_END: return(0x5) ; break; case DATA_NULL: return(0x6); break; case SPEEDb: return(0x7); break; case GRANT: return(0x8); break; case DATA_PREFIX: if(rd==POSITIVE_RD) return(0x9); else return(0xa); break; case GRANT_ISOCH: return(0xb); break; case SPEEDc: return(0xc); break; case ASYNC_EVEN: return(0xd); break; case ASYNC_ODD: return(0xe); break; case BUS_RESET: return(0xf); break; default: return(0x0); break; // assert error - cannot occur } } int arbReqSymbolMap(betaRequestCode txRequest) { int asyncPart = 0x0; // numerical representation of the asynchronous request type int isochPart = 0x0; // numerical representation of the isochronous request type
606
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-12—Beta port transmit actions and conditions (continued) switch(txRequest.async) { case CURRENT: asyncPart=0x1; break; case NEXT_EVEN: asyncPart=0x2; break; case CYCLE_START_REQ: asyncPart=0x3; break; case NONE_ODD: asyncPart=0x4; break; case NEXT_ODD: asyncPart=0x5; break; case NONE_EVEN: asyncPart=0x6; break; case BORDER: asyncPart=0x7; break; default: asyncPart=0x0; break; // assert error - cannot occur } switch(txRequest.isoch) { case ISOCH_CURRENT: isochPart=0x1; break; case ISOCH_EVEN: isochPart=0x4; break; case ISOCH_NONE: isochPart=0x2; break; case ISOCH_ODD: isochPart=0x6; break; default: isochPart=0x0; break; // assert error - cannot occur } return((isochPart&0x1)|((isochPart&0x6)<<2) | (asyncPart<<5)); } int configReqSymbolMap(arbState txRequest) { // Returns a numerical representation for a configuration request switch(txRequest) { case TRAINING: return(0x00); break; case DISABLE_NOTIFY: return(0x20); break; case CHILD_NOTIFY | IDENT_DONE : return(0x40); break; case OPERATION: return(0x60); break; case STANDBY: return(0x80); break; case SUSPEND: return(0xa0); break; case PARENT_NOTIFY: return(0xc0); break; default: return(0x0); break; // to keep the compiler happy } } void updateScrambler() { // updates the state of the transmitter scrambler, performing 8 shift register operations int i; int scramNew; // represents next state scramNew = scramOld; // LSB is the newest bit in the scrambler for (i=0; i<8; i++) { scramNew = scramNew << 1; scramNew = scramNew | (((scramOld & 0x400) >> 10) ^ ((scramOld & 0x100) >> 8)); scramOld = scramNew; } scram = scramOld & 0x0FF;
// used for XORing with input byte
} void txCharacter(portSymbol tx) { int i, j; int txCtrl; int txReq; int txScramCtrl;
Copyright © 2008 IEEE. All rights reserved.
// 4-bit representation of control state // 8-bit request symbol // scrambled control symbol
607
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-12—Beta port transmit actions and conditions (continued) int txScramData; int txScramReq; int characterOut; dataBit bitToSend;
// scrambled data byte // scrambled request type // 10-bit character
if (tx.tag==DATA) { if (disable_scrambler) txScramData = tx.data; // test mode for TX jitter test pattern else txScramData=tx.data^scram; //scramble the data byte characterOut=dataTable[txScramData][txRd]; //lookup character } else if(tx.tag==CTRL) { txCtrl=controlSymbolMap(tx.arb, txRd); txScramCtrl=txCtrl^((scram&0x80)>>4 | (scram&0x20)>>3 | (scram&0x8)>>2 | (scram&0x2)>>1); characterOut=controlTable[txScramCtrl]; } else { if(tx.tag==ARB_REQUEST) txReq=arbReqSymbolMap(tx.req); else if(tx.tag==CONFIG_REQUEST) txReq=configReqSymbolMap(tx.arb); else if(tx.tag==LEGACY_ARB) txReq = (((tx.data & 0x3) | (tx.arb==LEGACY_PHASE ? 0x4 : 0)) << 5) | 0x09; else { txReq = 0x0; // assert error - cannot occur } txScramReq=(txReq^scram) & 0xF9; if(tx.tag==CONFIG_REQUEST && (tx.arb==TRAINING || tx.arb==OPERATION) && txScramReq==0x38) // D28.0 characterOut=commaTable[txRd]; else characterOut=dataTable[txScramReq][txRd]; //lookup character } updateScrambler(); if (tx.tag!=CTRL) txRd=updateRd(characterOut, txRd); for(i=0;i<10;i++) { bitToSend = 0; if ((characterOut & 0x200) != 0) bitToSend = 1; //send MSB first PMD_DATA_request(bitToSend); characterOut = characterOut << 1; //wait for next port bit time for (j=0; j < (1 << (PHY_SPEED-portSpeed));j++) waitEvent(PH_BIT_CLOCK); } } void txSpeedSignal(speedCode txSpeed, pktType pktType) { int i; int j; j=portSpeed - txSpeed; localT.tag=CTRL; for(i=0; i < 1<<(portSpeed - txSpeed); i++) { if(i==j && pktType==LEGACY) localT.arb=SPEEDa; // SPEEDa denotes packet is legacy format else if(i==j && pktType==BETA) localT.arb=SPEEDb; // SPEEDb denotes packet is Beta format else localT.arb=SPEEDc; txCharacter(localT); } }
608
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-12—Beta port transmit actions and conditions (continued) void txOffActions() { while (powerReset) // scramOld shall be initialized to any value other than zero on power up scramOld = 0x7FF; scram = scramOld & 0x0FF; bportSyncOk=FALSE; } void txSyncLostActions() { txRd=NEGATIVE_RD; while(bportOn && syncLostSignal) { bportSyncOk=FALSE; localT.tag=CONFIG_REQUEST; localT.arb=TRAINING; txCharacter(localT); }
// initialization of rd
} void txSyncActions() { while(bportOn && syncErrorSignal && !syncLostSignal) { localT.tag=CONFIG_REQUEST; localT.arb=OPERATION; txCharacter(localT); } bportSyncOk=!syncErrorSignal; } void bportTransmitActions() { speedCode txSpeed; int txSpeedRatio; portSpeed int i;
// speed of each packet. // number of symbols per byte for given pktSpeed and
while(!syncLostSignal && bportOn) { if(portT.speed == DEFAULT) txSpeed = portSpeed; else txSpeed = portT.speed; txSpeedRatio = 1<<(portSpeed - txSpeed); if((portT.tag==ARB_STATE) && (portT.arb == SPEED)) //port always sends a speed signal if requested // to do so txSpeedSignal(txSpeed, portT.pkt); else if(portT.tag==DATA) { txCharacter(portT); localT.tag=CTRL; localT.arb=SPEEDc; for(i=1; i
Copyright © 2008 IEEE. All rights reserved.
609
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-12—Beta port transmit actions and conditions (continued) if (localT.tag==ARB_STATE) // decode arbstates into control and config requests localT.tag = localT.arb < TRAINING ? CTRL : CONFIG_REQUEST; if ((localT.tag==CTRL) && (localT.arb == IDLE)) { localT.tag = ARB_REQUEST; localT.req = arbReqT; // send the symbol defined by the background processing } txCharacter(localT); } } }
610
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
19.3.3 T-mode port The operation of T-mode ports (see Clause 20) is specified in this subclause. Table 19-13 covers the T-mode receive port operation and Table 19-14 covers the T-mode transmit port operation.
Table 19-13—T port receive actions // tport_rx #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
// variables global to two or more routines in the receive state machine boolean syncErrorSignal; synchronization
// receiver error monitor has detected loss of
// variables global to two or more routines in the receive state machine int invalidCount; int gmiiErrorCount; boolean invalidSpeedCode; int symbol; int lastSymbol; boolean error; boolean lastError; int characterIn; symbolPosition symPos; portSymbol lastLocalR; portSymbol localR; boolean newSpeedCode; int padRatio; boolean pkt; boolean pktPrefix; boolean pktEnding; int portErrorReg;
// // // // // //
used to assist diagnostics 10-bit symbol position relative to a sequence of five 802.3 Clause 40 bytes record of last localR record of sym_decoded received symbol TRUE until SPEEDa or SPEEDb in speed code
// when true, port is receiving a packet // when true, port is receiving packet prefix // when true, port is receiving packet ending (DATA_END) // record of number of coding errors detected
speedCode rxPktSpeed; pktType rxPktType;
// speed of received packet // type of packet format received
boolean rxReqCode; a Dx.0 or Dx.4 int rxSpeedDiff; int rxTrailingScCount; boolean speedKnown;
// true when the most recently received character was
// count of trailing Sc’s expected in a speed symbol // true after Sa or Sb has been received or first byte of // packet withouta speed signal (S100 legacy packet only)
int validCount; boolean allowInvalid; // first, useful functions and routines // Called whenever a data byte was expected, but not received. To prevent // the fifo unloading side from experiencing an underrun due to 8b/10b bit // errors, some data are pushed into the fifo for every byte at the packet
Copyright © 2008 IEEE. All rights reserved.
611
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) // // // //
rate. When an expected data byte isn’t found, this routine synthesizes a valid data byte by way of example. This implementation isn’t intended to preclude the selection of other synthesized symbols including other data values or other characters.
speedCode ratioedSpeed(int speedDiff) { speedCode rSpeed = S100; // assert error if not set in this function switch (portSpeed) { case S3200: { switch (speedDiff) { case 0: rSpeed = S3200; break; case 1: rSpeed = S1600; break; case 2: rSpeed = S800; break; case 3: rSpeed = S400; break; case 4: rSpeed = S200; break; case 5: rSpeed = S100; break; } break; } case S1600: { switch (speedDiff) { case 0: rSpeed = S1600; break; case 1: rSpeed = S800; break; case 2: rSpeed = S400; break; case 3: rSpeed = S200; break; case 4: rSpeed = S100; break; } break; } case S800: { switch (speedDiff) { case 0: rSpeed = S800; break; case 1: rSpeed = S400; break; case 2: rSpeed = S200; break; case 3: rSpeed = S100; break; } break; } case S400: { switch (speedDiff) { case 0: rSpeed = S400; break; case 1: rSpeed = S200; break; case 2: rSpeed = S100; break; } break; } case S200: { switch (speedDiff) { case 0: rSpeed = S200; break; case 1: rSpeed = S100; break; } break; } case S100: rSpeed = S100; break; default: rSpeed = S100; break; // assert error - cannot occur } return(rSpeed);
612
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-13—T port receive actions (continued) } void gmiiErrorMonitor(int gmiiError) { if (gmiiError == 1) { if (gmiiErrorCount == 0) { // new run of errors // increment the invalid count, but let normal symbol decode // decrement the invalid count as normal invalidCount=(invalidCount==4? 4:invalidCount + 1); validCount=0; } gmiiErrorCount = (gmiiErrorCount + 1) % 64; // start a new “run” if a run of 64 errored symbols } else { gmiiErrorCount = 0; } } boolean tportErrorMonitor() { if((localR.tag==INVALID) && (localR.arb==COUNT_INVALID)) { invalidCount=(invalidCount==4? 4:invalidCount + 1); validCount=0; } else { if(invalidCount>0) { validCount=validCount+1; if(validCount>1) { invalidCount=invalidCount-1; // If second consecutive valid then decrement invalid counter validCount=0; } } } return(invalidCount==4); // Sync lost on reaching threshold of four, // causing receiver to restart } void tportRxControlMap(int rxCtrl) { switch (rxCtrl) { case 0x0: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0x1: { localR.tag=ARB_STATE; localR.arb=CYCLE_START_EVEN; break;} case 0x2: { localR.tag=ARB_STATE; localR.arb=CYCLE_START_ODD; break;} case 0x3: { localR.tag=ARB_STATE; localR.arb=ATTACH_REQUEST; break;} case 0x4: { localR.tag=ARB_STATE; localR.arb=SPEEDa; break;} case 0x5: { localR.tag=ARB_STATE; localR.arb=DATA_END; break;} case 0x6: { localR.tag=ARB_STATE; localR.arb=DATA_NULL; break;} case 0x7: { localR.tag=ARB_STATE; localR.arb=SPEEDb; break;} case 0x8: { localR.tag=ARB_STATE; localR.arb=GRANT; break;} case 0x9: { localR.tag=ARB_STATE; localR.arb=DATA_PREFIX; break;} case 0xa: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0xb: { localR.tag=ARB_STATE; localR.arb=GRANT_ISOCH; break;} case 0xc: { localR.tag=ARB_STATE; localR.arb=SPEEDc; break;} case 0xd: { localR.tag=ARB_STATE; localR.arb=ASYNC_EVEN; break;} case 0xe: { localR.tag=ARB_STATE; localR.arb=ASYNC_ODD; break;} case 0xf: { localR.tag=ARB_STATE; localR.arb=BUS_RESET; break;} } } void tportRequestTypeMap(int request) {
Copyright © 2008 IEEE. All rights reserved.
613
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) int asyncPart; int isochPart; betaRequestCode rxrequest;
// numerical representation of the asynchronous request type // numerical representation of the isochronous request type
asyncPart = request >> 3; isochPart = request & 0x7; if (isochPart==0) { // configuration request type switch (asyncPart) { case 0x0: { localR.tag=CONFIG_REQUEST; localR.arb=TRAINING; } case 0x1: { localR.tag=CONFIG_REQUEST; localR.arb=DISABLE_NOTIFY; } case 0x2: { localR.tag=CONFIG_REQUEST; localR.arb=CHILD_NOTIFY; } // | IDENT_DONE case 0x3: { localR.tag=CONFIG_REQUEST; localR.arb=OPERATION; } case 0x4: { localR.tag=CONFIG_REQUEST; localR.arb=STANDBY; } case 0x5: { localR.tag=CONFIG_REQUEST; localR.arb=SUSPEND; } case 0x6: { localR.tag=CONFIG_REQUEST; localR.arb=PARENT_NOTIFY; } case 0x7: { localR.tag=INVALID; localR.arb=COUNT_INVALID; } } } else if (isochPart==0x3) { // LEGACY_REQUEST or LEGACY_PHASE localR.tag=LEGACY_ARB; localR.arb=((asyncPart & 0x4) == 0x4) ? LEGACY_PHASE : LEGACY_REQUEST; localR.data=(byte)(asyncPart & 0x3); // phase information } else { rxrequest.async = A_NONE; // dummy values to be returned in the case of tag = INVALID rxrequest.isoch = I_NONE; switch (asyncPart) { case 0x0: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0x1: { localR.tag=ARB_REQUEST; rxrequest.async=CURRENT; break;} case 0x2: { localR.tag=ARB_REQUEST; rxrequest.async=NEXT_EVEN; break;} case 0x3: { localR.tag=ARB_REQUEST; rxrequest.async=CYCLE_START_REQ; break;} case 0x4: { localR.tag=ARB_REQUEST; rxrequest.async=NONE_ODD; break;} case 0x5: { localR.tag=ARB_REQUEST; rxrequest.async=NEXT_ODD; break;} case 0x6: { localR.tag=ARB_REQUEST; rxrequest.async=NONE_EVEN; break;} case 0x7: { localR.tag=ARB_REQUEST; rxrequest.async=BORDER; break;} } if (localR.tag != INVALID) { switch (isochPart) { case 0x0: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0x1: { localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_CURRENT; break;} case 0x2: { localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_NONE; break;} case 0x3: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0x4: { localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_EVEN; break;} case 0x5: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} case 0x6: { localR.tag=ARB_REQUEST; rxrequest.isoch=ISOCH_ODD; break;} case 0x7: { localR.tag=INVALID; localR.arb=COUNT_INVALID; break;} } } localR.req.async=rxrequest.async; localR.req.isoch=rxrequest.isoch; } } // // // // //
See Symbol Decode Rules table in the spec. This void could be coded using table lookup, and even without that could be condensed considerably with a few more “ifs”. But it is coded to walk through the table in the spec line by line. References are to the line numbers in the spec table.
614
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-13—T port receive actions (continued) void symDecode(int tbSym, symbolPosition sPos, boolean leftErrored, boolean rightErrored) { // symDecode a 10-bit symbol int T0 = (tbSym & 0x200) >> 9; int T9 = tbSym & 0x1; int S1 = (tbSym & 0x100) >> 8; int S8 = (tbSym & 0x2) >> 1; boolean inPacket = pkt || pktPrefix || pktEnding; boolean AB = (sPos == A) || (sPos == B); int controlField = (((tbSym & 0xFC) >> 2) >> (AB ? 2 : 0)) & 0xF; if (!leftErrored && !rightErrored) { // deal with the cases of no explicitly errored bytes if ((T0 == 0) && (T9 == 0)) { // DATA if (inPacket) { // #2 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #1 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else if (!(T0 == T9)) { // #3 opposite values localR.tag = INVALID; localR.arb = COUNT_INVALID; } else { // T0 == T9 == 1 if ((S1 == 0) && (S8 == 0)) { // request tportRequestTypeMap((tbSym & 0xFC) >> 2); // #4 and 5 if (inPacket && !(localR.tag == INVALID)) { // #5 valid arb request etc pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } else if (!(S1 == S8)) { // #6 localR.tag = INVALID; localR.arb = COUNT_INVALID; } else { // #7 and #8 S1 == S8 == 1 - control symbol // check that zero bits are still zero if ((AB ? (tbSym & 0xC) >> 2 : (tbSym & 0xC0) >> 6) != 0x0 ) { localR.tag = INVALID; localR.arb = COUNT_INVALID; } else { tportRxControlMap(controlField); // #7 and 8 if (!inPacket && (localR.tag == ARB_STATE) && (localR.arb == DATA_END)) { // #8 localR.arb = DATA_NULL; } } } // control symbol } // T0 == T9 == 1 return; } // deal with the cases of no explicitly errored bytes if (leftErrored && rightErrored) { // #14, 26, 39, 51 - no useful information, just have to ignore localR.tag = INVALID; localR.arb = SKIP_INVALID; return; } // some information is good, some is bad switch (sPos) {
Copyright © 2008 IEEE. All rights reserved.
615
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) case A: { if (leftErrored) { // errored byte is a if (T9 == 0 ) { if (inPacket) { // #9 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #10 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // #11, 12 and 13 T9 == 1 localR.tag = INVALID; localR.arb = SKIP_INVALID; if ((S8 == 0) && (inPacket)) { // #12 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } // T9 == 1 } else { // errored byte is b if (T0 == 0) { if (inPacket) { // #16 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #15 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // T0 == 1 if (S1 == 0) { // #17 and 18 - candidate arbitration request tportRequestTypeMap((tbSym & 0xFC) >> 2); if (inPacket) { // #18 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } else { // #19 and 20 (per #7 and 8) S1 == 1 if (((tbSym & 0xC) >> 2) != 0x0 ) { // check that zero bits are still zero localR.tag = INVALID; localR.arb = COUNT_INVALID; } else { tportRxControlMap(controlField); if (!inPacket && (localR.tag == ARB_STATE) && (localR.arb == DATA_END)) { // #20 (per #8) localR.arb = DATA_NULL; } } } // S1 == 1 } // T0 == 1 } // errored byte is b break; } // A case B: { if (leftErrored) { // errored byte is b if (T9 == 0 ) { if (inPacket) { // #22
616
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-13—T port receive actions (continued) localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #21 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // #23, 24 and 25 T9 == 1 localR.tag = INVALID; localR.arb = SKIP_INVALID; if ((S8 == 0) && (inPacket)) { // #24 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } // T9 == 1 } else { // errored byte is c if (T0 == 0) { if (inPacket) { // #28 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #27 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // T0 == 1 if (S1 == 0) { // #29 and 30 candidate arbitration request localR.tag = INVALID; localR.arb = SKIP_INVALID; if (inPacket) { // #30 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } else { // #31 and 32 (per #7 and 8) S1 == 1 tportRxControlMap(controlField); if (!inPacket && (localR.tag == ARB_STATE) && (localR.arb == DATA_END)) { // #32 (per #8) localR.arb = DATA_NULL; } } // S1 == 1 } // T0 == 1 } // errored byte is c break; } // B case C: { if (leftErrored) { // errored byte is c if (T9 == 0 ) { if (inPacket) { // #34 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #33 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // T9 == 1 if (S8 == 0) { // #35 and 36 localR.tag = INVALID;
Copyright © 2008 IEEE. All rights reserved.
617
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) localR.arb = SKIP_INVALID; if (inPacket) { // #36 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } else { // #37 and 38 (per #7 and 8) S8 == 1 tportRxControlMap(controlField); if (!inPacket && (localR.tag == ARB_STATE) && (localR.arb == DATA_END)) { // #32 (per #8) localR.arb = DATA_NULL; } } // S8 == 1 } // T9 == 1 } else { // errored byte is d if (T0 == 0) { if (inPacket) { // #41 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #40 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // #42, 43 and 44 T0 == 1 localR.tag = INVALID; localR.arb = SKIP_INVALID; if (S8 == 0) { // #42 and 43 candidate arbitration request if (inPacket) { // #43 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } // S8 == 0 } // T0 == 1 } // errored byte is d break; } // C case D: { if (leftErrored) { // errored byte is d if (T9 == 0 ) { if (inPacket) { // #46 localR.tag = DATA; localR.data = (byte)((tbSym & 0x1FE) >> 1); } else { // #45 replace with DATA_NULL localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // T9 == 1 if (S8 == 0) { // #47 and 48 tportRequestTypeMap((tbSym & 0xFC) >> 2); if (inPacket) { // #48 pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } else { // #49 and 50 (per #7 and #8) S8 == 1 - control symbol if (((tbSym & 0xC0) >> 6) != 0x0 ) { // check that zero bits are still zero
618
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-13—T port receive actions (continued) localR.tag = INVALID; localR.arb = COUNT_INVALID; } else { tportRxControlMap(controlField); if (!inPacket && (localR.tag == ARB_STATE) && (localR.arb == DATA_END)) { // #50 (per #8) localR.arb = DATA_NULL; } } } // S8 == 1 } // T9 == 1 } else { // if (T0 == 0) { if (inPacket) { // localR.tag = DATA; localR.data = (byte)((tbSym } else { // localR.tag = ARB_STATE; localR.arb = DATA_NULL; } } else { // localR.tag = INVALID; localR.arb = SKIP_INVALID; if (S8 == 0) { // if (inPacket) { // pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; } } // S8 == 0 } // T0 == 1 } // errored byte is d break; } // D } // case sPos
errored byte is e #53 & 0x1FE) >> 1); #52 replace with DATA_NULL
#54, 55 and 56 T0 == 1
#54 and 55 candidate arbitration request #43
} boolean tportRxCharacter() { lastLocalR.tag=localR.tag; lastLocalR.arb=localR.arb; lastLocalR.data=localR.data; lastLocalR.rxDSArb=localR.rxDSArb; lastLocalR.req.async=localR.req.async; lastLocalR.req.isoch=localR.req.isoch; lastLocalR.pkt=localR.pkt; lastSymbol = symbol; lastError = error; rxReqCode=FALSE; characterIn=0; // //
get a 10-bit symbol from as many GMII cycles as necessary . . . . two bits symbol type, 8 bits of symbol if ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) waitPosEdge(gmii.RX_CLK); while (!gmii.RX_DV && ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK))
Copyright © 2008 IEEE. All rights reserved.
619
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) ; if (!((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK)) { localR.tag=INVALID; localR.arb=SKIP_INVALID; } else { // RX_DV is true, got a new 8-bit symbol symbol = gmii.RXD; error = (boolean)gmii.RX_ER; gmiiErrorMonitor(gmii.RX_ER); switch (symPos) { case A: { lastSymbol = symbol; lastError = error; if ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) waitPosEdge(gmii.RX_CLK); while (!gmii.RX_DV && ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK)) waitPosEdge(gmii.RX_CLK); if (!((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK)) { localR.tag=INVALID; localR.arb=SKIP_INVALID; } else { symbol = gmii.RXD; error = (boolean)gmii.RX_ER; gmiiErrorMonitor(gmii.RX_ER); characterIn = ((lastSymbol & 0xFF) << 2) | ((symbol & 0xC0) >> 6); symDecode(characterIn, A, lastError, error); symPos = B; } break; } case B: { characterIn = ((lastSymbol & 0x3F) << 4) | ((symbol & 0xF0) >> 4); symDecode(characterIn, B, lastError, error); symPos = C; break; } case C: { characterIn = ((lastSymbol & 0xF) << 6) | ((symbol & 0xFC) >> 2); symDecode(characterIn, C, lastError, error); symPos = D; break; } case D: { characterIn = ((lastSymbol & 0x3) << 8) | ((symbol & 0xFF)); symDecode(characterIn, D, lastError, error); symPos = A; break; } } lastSymbol = symbol; lastError = error; } return(tportErrorMonitor()); // check that synchronization is OK } boolean tportBspeedFilter() { if (pkt) { return(FALSE);
620
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-13—T port receive actions (continued) } if (localR.tag==ARB_STATE && (localR.arb==SPEEDa || localR.arb==SPEEDb || localR.arb==SPEEDc) && newSpeedCode && (lastLocalR.tag == INVALID)) { // bad symbol either immediately before speed code invalidSpeedCode = TRUE; // or before the speed and format is determined speedKnown = FALSE; // invalidate memory of previous speed code } else if (localR.tag==ARB_STATE && localR.arb==SPEEDc) { if (rxTrailingScCount > 0) { // ignore trailing Sc’s rxTrailingScCount = rxTrailingScCount-1; } else { rxSpeedDiff=rxSpeedDiff+1; // for every SPEEDc increase the speed ratio... } } else if (!invalidSpeedCode && localR.tag==ARB_STATE && localR.arb==SPEEDa) { rxPktSpeed=ratioedSpeed(rxSpeedDiff); // actual speed is a function of the port speed padRatio = (1 << rxSpeedDiff); rxTrailingScCount = padRatio - rxSpeedDiff - 1; rxSpeedDiff = 0; // ready for reading the next speed code rxPktType=LEGACY; // SPEEDa indicates a legacy packet. speedKnown=TRUE; newSpeedCode = FALSE; return(TRUE); } else if (!invalidSpeedCode && localR.tag==ARB_STATE && localR.arb==SPEEDb) { rxPktSpeed=ratioedSpeed(rxSpeedDiff); // actual speed is a function of the port speed padRatio = (1 << rxSpeedDiff); rxTrailingScCount = padRatio - rxSpeedDiff - 1; rxSpeedDiff = 0; // ready for reading the next speed code rxPktType=BETA; // SPEEDb indicates a Beta packet. speedKnown=TRUE; newSpeedCode = FALSE; return(TRUE); } return(FALSE); } void tportReceiveActions() { // continuously running int padCount=0; // keeps track of padding boolean pushedConfigRequest = FALSE; boolean pushedSpeed = FALSE; portSymbol speedSymbol; while (TRUE) { while (powerReset) { ; } if (!(tportOn && ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK))) { validCount = 0; invalidCount = 0; // count of invalid symbols - used in a monitor with hysteresis gmiiErrorCount = 0; symbol = 0; lastSymbol = 0; error = 0; lastError = 0; symPos = A; localR.tag = INVALID; lastLocalR.tag = INVALID; localR.arb = SKIP_INVALID;
Copyright © 2008 IEEE. All rights reserved.
621
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) lastLocalR.arb = SKIP_INVALID; pkt = FALSE; pktPrefix = FALSE; pktEnding = FALSE; speedKnown = FALSE; newSpeedCode = TRUE; invalidSpeedCode = FALSE; rxSpeedDiff = 0; rxTrailingScCount=0; padCount=0; pushedConfigRequest = FALSE; pushedSpeed = FALSE; } else {
// keeps track of padding
syncErrorSignal = tportRxCharacter(); while(tportOn && ((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) && !syncErrorSignal) { // If received character completes a valid speed signal, then a packet prefix is arriving. // Speed signal is placed in fifo, and fifo update is turned on. if (tportBspeedFilter()) { speedSymbol.tag=ARB_STATE; speedSymbol.arb=SPEED; speedSymbol.speed=rxPktSpeed; speedSymbol.pkt=rxPktType; push(speedSymbol); pktPrefix=TRUE; // in case no data prefix was already received } else { if (invalidSpeedCode && busInitializeActive) ibr = TRUE; // error recovery if (localR.tag == ARB_STATE && (localR.arb==SPEEDa || localR.arb==SPEEDb || localR.arb==SPEEDc)) { // ignore unless in position of expected data if (pkt && padCount==0) pushDataZero(); // Padding in wrong place } else if ((localR.tag==INVALID) && (localR.arb == COUNT_INVALID)) { if (portErrorReg < 255) portErrorReg++; // increment error counter if (pkt && padCount==0) { pushDataZero(); // if a packet payload character, substitute 0x00 } } // If data are received then the packet has started, and packet prefix is done. // Position of data relative to padding is checked. // Fifo update is turned on (if not already). else if (localR.tag==DATA) { if (padCount==0) { pushedSpeed = FALSE; if (!speedKnown) { // Normally S100 legacy packet without speed code! if (!busInitializeActive && bBus) { // For error recovery on a bBus, force Beta format speedSymbol.tag=ARB_STATE; speedSymbol.arb=SPEED; speedSymbol.speed=S100; speedSymbol.pkt=BETA; push(speedSymbol); pushedSpeed = TRUE; // flag to squash the data symbol }
622
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-13—T port receive actions (continued) padRatio = (1 << portSpeed); // 0 for S100, 1 for S200, 2 for S400 . . . speedKnown = TRUE; } pkt=TRUE; pktPrefix=FALSE; newSpeedCode = TRUE; // ready for next speed code invalidSpeedCode = FALSE; // If receiving an LTS, only buffer first occurence of each new data byte.
For
all other // packet sequences, buffer each received byte if (!(pushedSpeed || (untestedState && (lastLocalR.tag == DATA) && (lastLocalR.data == localR.data)))) push(localR); } } else if(localR.tag==ARB_STATE) { // any arb state except SPEEDa, SPEEDb or SPEEDc if(localR.arb==DATA_PREFIX) { if ((lastLocalR.tag==INVALID) && busInitializeActive) // might have missed a single speed symbol ibr = TRUE; if(pkt) { pktPrefix=TRUE; // concatenated packet pkt=FALSE; // speedKnown remains true to allow for concatenated // packet without speed code at the same speed } else if(!pktPrefix) pktPrefix=TRUE; } else { if ((pktPrefix || pkt || pktEnding) && (localR.arb == DATA_END)) { pktEnding = TRUE; } else pktEnding = FALSE; pktPrefix=FALSE; pkt=FALSE; speedKnown=FALSE; } rxSpeedDiff=0; padCount=0; rxTrailingScCount=0; // Buffer first occurence of each new arbitration state.... if (!((lastLocalR.tag == ARB_STATE) && (lastLocalR.arb == localR.arb))) push(localR); newSpeedCode = TRUE; // ready for next speed code invalidSpeedCode = FALSE; } if(localR.tag==ARB_REQUEST) { // Buffer first occurence of each new arbitration request.... if (!((lastLocalR.tag == ARB_REQUEST) && (lastLocalR.req.isoch == localR.req.isoch) && (lastLocalR.req.async == localR.req.async))) push(localR); } if(localR.tag==LEGACY_ARB) { pktEnding = FALSE; // normally comes after DATA_END // Buffer first occurence of each new LEGACY request or indication.... if (!((lastLocalR.tag == LEGACY_ARB) && (lastLocalR.arb == localR.arb) && (lastLocalR.data == localR.data))) push(localR); }
Copyright © 2008 IEEE. All rights reserved.
623
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-13—T port receive actions (continued) if(localR.tag==CONFIG_REQUEST) { // Filter Config Requests // required that two consecutive identical config requests are received // before one is pushed // but only push one for any consecutive sequence of identical requests if ((lastLocalR.tag == CONFIG_REQUEST) && (lastLocalR.arb == localR.arb)) { if (!pushedConfigRequest) { localR.tag = ARB_STATE; // convert to arb state push(localR); localR.tag = CONFIG_REQUEST; // ready for comparison with the next one pushedConfigRequest = TRUE; } // pushed config_request always TRUE at this point } else pushedConfigRequest = FALSE; // on non-matching config request } else pushedConfigRequest = FALSE; // or on anything that is not a config request if (pkt) { padCount = (padCount+1) % padRatio; } } syncErrorSignal=tportRxCharacter(); } // here after a sync error - closing down . . . localR.tag = ARB_STATE; localR.arb = IDLE; push(localR); // ensure that the FIFO is not stuck pkt=FALSE; speedKnown=FALSE; rxSpeedDiff=0; rxTrailingScCount=0; padCount=0; pktPrefix=FALSE; pktEnding=FALSE; symPos = A; } } }
Table 19-14—T port transmit actions // tport_tx #define unsubscripted #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
// variables global to two or more routines in the receive state machine #define TX_FIFO_SIZE (TMODE_SYMBOL_JITTER+3) plus one spare portSymbol localT;
// for 9 symbols, plus two for quantization,
// variable that indicates signal to be sent on port
// FIFO to model 802ab PHY and cable delays
624
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-14—T port transmit actions (continued) int txFifo[TX_FIFO_SIZE]; int txTypeFifo[TX_FIFO_SIZE]; int txFifoWrPtr; int txFifoRdPtr; int txDelay; int txFifoOffset; boolean fifoFilling;
// into the current 10-bit fifoRdPtr position
int txBitError; boolean txErroredSpeed; boolean persistTxErroredSpeed;
void tportPush(int symbolTypeToPush, int symbolToPush) { int newPointer = (txFifoWrPtr + 1) % TX_FIFO_SIZE; int ptr = txFifoWrPtr; // may overwrite last symbol if (!((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) && tportOn) { ; // Error: Attempt to transmit a symbol when port is not synchronized } if (newPointer == txFifoRdPtr) { ; // Error: tx_FIFO overflow } if (newPointer != txFifoRdPtr) ptr = newPointer; // next position in the FIFO txFifo[ptr]=symbolToPush; txTypeFifo[ptr]=symbolTypeToPush; txFifoWrPtr = ptr; // now see if enough has been accumulated to kick off the FIFO // requirement is to accumulate 9 symbols (strictly, 88 bits) if (((txFifoWrPtr - txFifoRdPtr + TX_FIFO_SIZE) % TX_FIFO_SIZE) == (TX_FIFO_SIZE - 2)) fifoFilling = FALSE; } int tportEncode(int sType, int sSymb, boolean AB) { switch (sType) { case 0x0 : { // DATA return(sSymb << 1); // data value with zero in T0 and T9 } case 0x1 : { // Request return(0x201 | (sSymb << 2)); // 1 in T0 and T9, zero in S1 and S8 } case 0x2 : { // Control return(0x303 | (sSymb << (AB ? 4 : 2))); // 1 in T0 and T9, 1 in S1 and S8, // control symbol left or right justified } default: { // error return(0); } } } // read from the FIFO and present to GMII TX in a timely manner void fifoMaintain() { int newSymb = 0; // assert error if used before being set int tempSymb1; int tempSymb2 = 0; // assert error if used before being set
Copyright © 2008 IEEE. All rights reserved.
625
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-14—T port transmit actions (continued) int tempType1; int tempType2 = 0; // assert error if used before being set while (TRUE) { // present to RX interface while (powerReset || !(((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) && tportOn)) { // power reset or no sync txFifoWrPtr = 0; txFifoRdPtr = 0; txFifoOffset = 0; tempType2 = 0; tempSymb2 = 0; fifoFilling = TRUE; gmii.TXD = 0; gmii.TX_EN = 0; gmii.TX_ER = 0; gmii.GTX_CLK = 0; waitPosEdge(GTX_REF_CLK); } if (!fifoFilling) { // i.e. already accumulated enough to start transmission tempType1 = tempType2; tempSymb1 = tempSymb2; if (txFifoOffset != 8) txFifoRdPtr = (txFifoRdPtr + 1) % TX_FIFO_SIZE; tempType2 = txTypeFifo[txFifoRdPtr]; tempSymb2 = txFifo[txFifoRdPtr]; switch (txFifoOffset) { case 0: { newSymb = tportEncode(tempType2, tempSymb2, TRUE) >> 2; txFifoOffset = 2; break; } case 2: { newSymb = ((tportEncode(tempType1, tempSymb1, TRUE) & 0x003 ) << 6) | (tportEncode(tempType2, tempSymb2, TRUE) >> 4); txFifoOffset = 4; break; } case 4: { newSymb = ((tportEncode(tempType1, tempSymb1, TRUE) & 0x00F ) << 4) | (tportEncode(tempType2, tempSymb2, FALSE) >> 6); txFifoOffset = 6; break; } case 6: { newSymb = ((tportEncode(tempType1, tempSymb1, FALSE) & 0x03F ) << 2) | (tportEncode(tempType2, tempSymb2, FALSE) >> 8); txFifoOffset = 8; break; } case 8: { newSymb = tportEncode(tempType1, tempSymb1, FALSE) & 0x0FF; // also happens to be equal to tempSymb2[7:0] txFifoOffset = 0; break; } } gmii.TXD = newSymb;
626
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-14—T port transmit actions (continued) gmii.TX_EN = 1; if ((txFifoOffset != 8) && (txFifoRdPtr == txFifoWrPtr)) { // FIFO now drained, so refil it fifoFilling = TRUE; } } else { gmii.TX_EN = 0; } gmii.GTX_CLK = 1; waitNegEdge(GTX_REF_CLK); gmii.GTX_CLK = 0; waitPosEdge(GTX_REF_CLK); } } int tportControlSymbolMap(arbState txCtrl) { // Returns a numerical representation for a control token switch (txCtrl) { case CYCLE_START_EVEN: { return(0x1); } case CYCLE_START_ODD: { return(0x2); } case ATTACH_REQUEST: { return (0x3); } // ARB_CONTEXT overloaded here case SPEEDa: { return(0x4); } case DATA_END: { return(0x5); } case DATA_NULL: { return(0x6); } case SPEEDb: { return(0x7); } case GRANT: { return(0x8); } case DATA_PREFIX: { return(0x9); } case GRANT_ISOCH: { return(0xb); } case SPEEDc: { return(0xc); } case ASYNC_EVEN: { return(0xd); } case ASYNC_ODD: { return(0xe); } case BUS_RESET: { return(0xf); } default: { return(0x0); } // assert error - cannot occur } } int tportArbReqSymbolMap(betaRequestCode txRequest) { int asyncPart; // numerical representation of the asynchronous request type int isochPart; // numerical representation of the isochronous request type switch (txRequest.async) { case CURRENT: { asyncPart=0x1; break; } case NEXT_EVEN: { asyncPart=0x2; break; } case CYCLE_START_REQ: { asyncPart=0x3; break; } case NONE_ODD: { asyncPart=0x4; break; } case NEXT_ODD: { asyncPart=0x5; break; } case NONE_EVEN: { asyncPart=0x6; break; } case BORDER: { asyncPart=0x7; break; } default: { // Error: Invalid async request asyncPart = 0; break; } } switch (txRequest.isoch) { case ISOCH_CURRENT: { isochPart=0x1; break; } case ISOCH_EVEN: { isochPart=0x4; break; }
Copyright © 2008 IEEE. All rights reserved.
627
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-14—T port transmit actions (continued) case ISOCH_NONE: { isochPart=0x2; break; } case ISOCH_ODD: { isochPart=0x6; break; } default: { // Error: Invalid isoch request isochPart = 0; break; } } return(isochPart | (asyncPart << 3)); } int tportConfigReqSymbolMap(arbState txRequest) { // Returns a numerical representation for a configuration request switch (txRequest) { case TRAINING: { return(0x00); } case DISABLE_NOTIFY: { return(0x08); } case CHILD_NOTIFY: { return(0x10); } // and IDENT_DONE case OPERATION: { return(0x18); } case STANDBY: { return(0x20); } case SUSPEND: { return(0x28); } case PARENT_NOTIFY: { return(0x30); } default: { return(0x00); } // assert error - cannot occur } } int tportArbTagSymbolMap(portTag tag) { // returns a numerical representation of the symbol tag switch (tag) { case DATA: return(0x0); case CTRL: return(0x2); case ARB_REQUEST: case CONFIG_REQUEST: case LEGACY_ARB: return(0x1); case ARB_STATE: case INVALID: case DS_RAW_ARB: return(0x3); } return(0x0);
// Error: Invalid portTag // to keep compiler happy
} void tportTxCharacter(portSymbol tx) { int characterOut; // 10-bit character if (tx.tag==DATA) { characterOut=tx.data; } else if(tx.tag==INVALID) { // send “INVALID” Control (control 0) tx.tag=CTRL; characterOut=0; } else if(tx.tag==CTRL) { characterOut=tportControlSymbolMap(tx.arb); } else { if(tx.tag==ARB_REQUEST) characterOut=tportArbReqSymbolMap(tx.req); else if(tx.tag==CONFIG_REQUEST) characterOut=configReqSymbolMap(tx.arb); else if(tx.tag==LEGACY_ARB) characterOut = (((tx.data & 0x3) | ((tx.arb==LEGACY_PHASE) ? 0x4 : 0)) << 3) | 0x3; else characterOut = 0; // assert error - cannot occur }
628
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-14—T port transmit actions (continued) if (txBitError != 0) { characterOut = characterOut ^ txBitError; // invert requested bits } //////// place char in FIFO, place char_type in char_type FIFO tportPush(tportArbTagSymbolMap(tx.tag), characterOut); } void tportTxSpeedSignal(speedCode txSpeed, pktType packetType) { int i; int j; j=portSpeed - txSpeed; localT.tag=CTRL; for(i=0; i < (1<<(portSpeed - txSpeed)); i++) { if ((i == 0) && txErroredSpeed) { localT.tag = INVALID; txErroredSpeed = persistTxErroredSpeed; } else if((i==j) && (packetType==LEGACY)) localT.arb=SPEEDa; // SPEEDa denotes packet is legacy format else if((i==j) && (packetType==BETA)) localT.arb=SPEEDb; // SPEEDb denotes packet is Beta format else localT.arb=SPEEDc; tportTxCharacter(localT); } } void tportTransmitActions() { speedCode txSpeed; int txSpeedRatio; portSpeed int i;
// speed of each packet. // number of symbols per byte for given pktSpeed and
while (TRUE) { // present to RX interface while (powerReset) { ; } while (((PMD_STATUS_request() & PMD_TPORT_OK) == PMD_TPORT_OK) && tportOn) { if (portT.speed == DEFAULT) txSpeed = S800; else txSpeed = portT.speed; txSpeedRatio = 1<<(portSpeed - txSpeed); if ((portT.tag==ARB_STATE) && (portT.arb == SPEED)) { //port always sends a speed signal if requested to do so tportTxSpeedSignal(txSpeed, portT.pkt); } else if (portT.tag==DATA) { tportTxCharacter(portT); localT.tag=CTRL; localT.arb=SPEEDc; for(i=1; i
Copyright © 2008 IEEE. All rights reserved.
629
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-14—T port transmit actions (continued) localT.arb=portT.arb; localT.data=portT.data; localT.rxDSArb=portT.rxDSArb; localT.pkt=portT.pkt; if (localT.tag == ARB_REQUEST) { localT.req.async = arbReqT.async; // send the symbol defined by the background processing localT.req.isoch = arbReqT.isoch; // send the symbol defined by the background processing } if (localT.tag==ARB_STATE) // decode arbstates into control and config requests localT.tag = (localT.arb < TRAINING) ? CTRL : CONFIG_REQUEST; if ((localT.tag==CTRL) && (localT.arb == IDLE)) { localT.tag = ARB_REQUEST; localT.req.async = arbReqT.async; // send the symbol defined by the background processing localT.req.isoch = arbReqT.isoch; // send the symbol defined by the background processing } tportTxCharacter(localT); } } } }
19.4 Border arbitration actions and conditions 19.4.1 Border arbitration functions This subclause consists of five tables that specify the border arbitration functions. Table 19-15 and Table 19-16 cover the border transmit and receive functions, respectively. Table 19-17 covers PHY packet processing. Table 19-18 covers legacy arbitration functions and Table 19-19 covers border arbitration functions.
630
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-15—Border transmit functions // transmit_functions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void txByte(byte dataByte) { // int i; nonNullPacket = TRUE; // Set for (i = 0; i < NPORT; i++) { if (active[i] && (i != receivePort)) if (speedOk[i]) { portT[i].speed = currentSpeed; portT[i].data = dataByte; portT[i].tag = DATA; } // if not OK, then already sending } } waitSymbolTime(currentSpeed); }
Transmit a byte data packet indicator as actual data payload is sent {
Data Prefix or Data Null
void txQuadlet(quadlet quadData) { // Send a quadlet... int i; byte dataByte; for (i = 0; i < 4; i++) { // ...a byte at a time dataByte = (byte)(quadData >> 8*(3-i)); PH_DATA_indication(PH_DATA_BYTE, 0, dataByte, 0); // Copy our own self_ID packet to the link txByte(dataByte); } } void portTArbAtSpeed(int if (active[portNum]) { portT[portNum].arb = portT[portNum].speed portT[portNum].tag = } }
portNum, arbState arb, speedCode speed) { arb; = speed; ARB_STATE;
void portTArb(int portNum, arbState arb) { // suitable for both DS and Beta ports portTArbAtSpeed(portNum, arb, DEFAULT); } void sendControl(arbState control, int notToPort) { int i; for (i = 0; i < NPORT; i++) { // send in parallel to all ports if (i != notToPort) { if (betaMode[i]) portTArb(i, control); } }
Copyright © 2008 IEEE. All rights reserved.
631
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-15—Border transmit functions (continued) waitSymbolTime(S100); } void portTSpeed(int portNum, speedCode pktSpeed, pktType packetFormat) { portT[portNum].pkt = packetFormat; // LEGACY or BETA portTArbAtSpeed(portNum, SPEED, pktSpeed); } void portTSpeedRaw(int portNum, speedCode speed) { if (!betaMode[portNum]) portTArbAtSpeed(portNum, SPEED_RAW, speed); } // Send data prefix and do speed signaling void startTxPacket(speedCode pktSpeed, pktType pkt, boolean sendCycleStart) { int signalPort = NPORT, i; int deletableSymbolTime; // time for two symbols if (!DS_stuck) { maxBetaTimer = 0; nodes DS_stuck = TRUE; } currentSpeed = pktSpeed; currentFormat = pkt; legacyPhaseExpected = FALSE; nonNullPacket = FALSE; new packet dataNullPacket = FALSE;
// timer
only needs to be implemented in border capable
// and note that this will have to be released by sending // a legacy format packet // Remember speed and format of packet to transmit // set for check in stopTxPacket // Reset data payload indicator at beginning of each // not transmitting one
// if granting a cycle start request, first send the appropriate cycle start token if (sendCycleStart) { if (link == B_LINK) // Alert link PH_DATA_indication(oddIsochPhase ? PH_ISOCH_ODD: PH_ISOCH_EVEN, 0, 0, 0); for (i = 0; i < NPORT; i++) // Cycle start tokens are not sent on DS ports, if (!betaMode[i]) portTArb(i, DATA_PREFIX); // send DATA_PREFIX instead to prevent idle gap sendControl(oddIsochPhase ? CYCLE_START_ODD: CYCLE_START_EVEN, NPORT); isoCycle = TRUE; } for (i = 0; i < NPORT; i++) { if (active[i]) { if (disableRequest[i] && !phyResponse) portTArb(signalPort = i, DISABLE_NOTIFY); else if (suspendRequest[i] && !phyResponse) portTArb(signalPort = i, SUSPEND); else if (doStandby[i] && !phyResponse) portTArb(signalPort = i, STANDBY); } } if (signalPort != NPORT) currentSpeed = S100; for (i = 0; i < NPORT; i++) { if (!active[i]) speedOk[i] = FALSE;
632
// slow down to ensure four S100 symbols on // any signaling port // deal with inactive ports
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-15—Border transmit functions (continued) else if (!(disableRequest[i] || suspendRequest[i] || doStandby[i]) || phyResponse) { // normal packet speedOk[i] = (currentSpeed <= portSpeed[i]) && (betaMode[i] || pkt == LEGACY); if ((pkt == LEGACY) && (link == LEGACY_Link) && (currentSpeed == S100)) portTArb(i, DATA_PREFIX); // suppress speedCode, send data prefix else if (speedOk[i]) { // send speed code portTSpeed(i, currentSpeed, pkt); } else portTArb(i, pkt == LEGACY ? DATA_PREFIX : DATA_NULL); } } waitSymbolTime(currentSpeed);
// Wait till speed-sig symbol completed.
for (i = 0; i < NPORT; i++) if (!(disableRequest[i] || suspendRequest[i] || doStandby[i]) || phyResponse) // Now send the next symbol on the Beta mode ports. if (betaMode[i]) portTArb(i, speedOk[i] || pkt == LEGACY ? DATA_PREFIX : DATA_NULL); // ensure timing for starting packet format, plus timing for deletable symbols // The requirement is that the originating node shall insert two symbols // (one “can delete” and one “must delete”, and shall insert more symbols if // necessary to ensure that there is (approx) 40ns of deletable symbol time. deletableSymbolTime = MIN_DELETABLE_SYMBOL_TIME; if ((currentSpeed < S800) && (legacySymbolCount(currentSpeed) * 2 > MIN_DELETABLE_SYMBOL_TIME)) deletableSymbolTime = legacySymbolCount(currentSpeed) * 2; // or two symbol times if (pkt == LEGACY) { // therefore currentSpeed < S800 // Leave the speed signal for longer, send the next symbol on the DS ports. // waited 1, 2 or 4 legacyTime units waitLegacyTime(SPEED_SIGNAL_LENGTH - legacySymbolCount(currentSpeed)); for (i = 0; i < NPORT; i++) if (!(disableRequest[i] || suspendRequest[i] || doStandby[i]) || phyResponse) // Harmless writing this to the beta mode ports as well! portTArb(i, speedOk[i] || pkt == LEGACY ? DATA_PREFIX : DATA_NULL); waitLegacyTime(DATA_PREFIX_HOLD); // finish Data_Prefix // for S100 packets, must round up to two S100 symbol times // not used if a longer value of DATA_PREFIX_HOLD is used for legacy interoperability // (see text) i.e. if the time to wait is <= 0 if (currentSpeed == S100) waitLegacyTime (2*legacySymbolCount(S100) - (SPEED_SIGNAL_LENGTH+DATA_PREFIX_HOLD)); } else waitSymbolTime(currentSpeed); waitLegacyTime (deletableSymbolTime); if (signalPort != NPORT) { // now waited a total of at least four symbol times when sending SUSPEND etc for (i = 0; i < NPORT; i++) // turn off signaled port(s) if ((disableRequest[i] || suspendRequest[i] || doStandby[i]) && !phyResponse) portTArb(i, IDLE); } signaled = (signalPort != NPORT); if (signalPort != NPORT) { for (i = 0; i < NPORT; i++) // wait for signal port(s) to exit active if ((disableRequest[i] || suspendRequest[i] || doStandby[i]) && !phyResponse) while (active[i]) ;
Copyright © 2008 IEEE. All rights reserved.
633
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-15—Border transmit functions (continued) } } void stopTxPacket(arbState endingStatus, int portToGrant) { int i; int holdTime = 0; // assert error if used without being set arbState txArb; switch (endingStatus) { case DATA_PREFIX: // current talker is holding onto case DATA_NULL: // the bus to form a concatenation holdTime = CONCATENATION_PREFIX_TIME; txArb = endingStatus; break; case GRANT: case GRANT_ISOCH: if (portToGrant == seniorPort) { // grant to senior releases bus holdTime = DATA_END_TIME; txArb = dataNullPacket ? IDLE : DATA_END; DS_stuck = (currentFormat != LEGACY); } else if ((receivePort == NPORT) && (portToGrant == NPORT)) { // grant to link for concatenation without fear of overwriting IDLE on receive port holdTime = CONCATENATION_PREFIX_TIME; txArb = DATA_NULL; } else { // grant to junior/link taking care not to overwrite IDLE on receive port holdTime = DATA_END_TIME; txArb = DATA_NULL; } break; case DATA_END: holdTime = DATA_END_TIME; txArb = DATA_END; DS_stuck = (currentFormat != LEGACY); break; case IDLE: case ARB_CONTEXT: txArb = endingStatus; DS_stuck = (currentFormat != LEGACY); break; case BUS_RESET: txArb = BUS_RESET; DS_stuck = FALSE; break; default: txArb = endingStatus; // assert error - cannot occur break; } if ((txArb == BUS_RESET) || (txArb == IDLE)) return; // Immediate exit to R0 or A0 for (i = 0; i < NPORT; i++) { if (!(betaMode[i] && portToGrant == i) && (i != receivePort)) // leave DATA_NULL on stuck DS or speed_filtered ports for Beta packet formats if (currentFormat == LEGACY || (betaMode[i] && speedOk[i])) portTArb(i, txArb); }
634
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-15—Border transmit functions (continued) if ((portToGrant < NPORT) && betaMode[portToGrant]) { // granting a betaMode cable port? if (portToGrant == seniorPort) // ensure that at least one symbol has been sent while (timeOutOfIdle < symbolTime(portSpeed[portToGrant])) ; if ((endingStatus != DATA_END) || speedOk[portToGrant] || currentFormat == LEGACY) portTArb(portToGrant, endingStatus); // leave DATA_NULL on speed filtered Beta format packet } if ((currentFormat == LEGACY) && (txArb != ARB_CONTEXT)) { // For LEGACY format packets, ensure all legacy timings. ARB_CONTEXT indicates a // sudden end of a packet prefix; consequently, legacy timings are not preserved. if (txArb == DATA_END) { // also replace the last 80ns of grant if grant going to senior waitLegacyTime(holdTime - 4); if ((receivePort == NPORT) || !betaMode[receivePort]) // originating the packet into the cloud legacyRequestPhase = (legacyRequestPhase + 1) % 4; // increment modulo phase else if (legacyPhaseExpected) { // repeating packet inside cloud // and didn’t receive expected phase indication legacyRequestPhase = (legacyRequestPhase + 1) % 4; // increment modulo phase isbr = TRUE; } for (i = 0; i < NPORT; i++) if (active [i] && betaMode[i] && (i != receivePort)) { portT[i].arb = LEGACY_PHASE; portT[i].speed = DEFAULT; portT[i].data = (byte)legacyRequestPhase; portT[i].tag = LEGACY_ARB; } waitLegacyTime(4); // ensure at least one symbol of LEGACY_PHASE } else waitLegacyTime(holdTime); if (nonNullPacket) waitLegacyTime(1); // allow for 20 ns of dribble bit time on non null // legacy format packets } else if ((portToGrant != NPORT) && (portToGrant != NPORT+1) && (currentSpeed > portSpeed[portToGrant])) { // stretch the GRANT if its going to a slower external port waitSymbolTime(portSpeed[portToGrant]); waitSymbolTime(portSpeed[portToGrant]); } else { waitSymbolTime(currentSpeed); waitSymbolTime(currentSpeed); } if ((txArb == DATA_END) && isoCycle) isochConcatOk = TRUE; // OK to concat now for legacy camcorder }
Copyright © 2008 IEEE. All rights reserved.
635
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-16—Border receive functions // receive_functions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
arbState portRNextArb(int portNum) { arbState arb; nextArb[portNum] = FALSE; advanceOk[portNum] = TRUE; while (!nextArb[portNum]) ; arb = portRArb[portNum]; if (packetEnding[portNum]) { nextArb[portNum] = FALSE; advanceOk[portNum] = TRUE; } return (arb); }
// return next arb state (only called in packet context)
// OK to get the next symbol from the FIFO // port has not advanced to the next item yet
// does this arb state terminate the packet? // if so, then let the FIFO advance to the next // arb state and then advance eagerly
int legacySymbolCount(speedCode spd) { // Legacy_wait units (2/BASE_RATE) return(spd == S400 ? 1: spd == S200 ? 2 : 4); } float legacyTime(int n) {
// returns the duration (in seconds) of a specified number // of _exact_ S400 byte times (each approx 20ns) return((float)((2 * n)/(BASE_RATE * 1000000)));
} void waitLegacyTime(int n) {
// waits a specified number of _exact_ S400 byte times // (each approx 20ns)
waitTime(legacyTime(n)); } float symbolTime(speedCode symbolSpeed) { // returns the _exact_ duration (in seconds) // of a symbol at the specified speed // i.e. approx 80ns for S100, 40ns for S200, etc. return((float)(8/(BASE_RATE * 1000000 * (1 << symbolSpeed)))); } void waitSymbolTime(speedCode symbolSpeed) { // waits the _exact_ duration of a symbol at the specified speed // i.e. approx 80ns for S100, 40ns for S200, etc. waitTime(symbolTime(symbolSpeed)); } void txControl(arbState control, int rPort) { // Transmit a control symbol, but not on r.port int i; for (i = 0; i < NPORT; i++) { if (i != rPort) portTArb(i, control); // timing will be ensured by context } }
636
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-16—Border receive functions (continued) void startRxPacket(arbState *endingArb) { // Send data prefix and do speed signaling // receive on DS or Beta, repeat to both int i; arbState arb, previousArb; boolean prefixComplete; // TRUE if no longer receiving valid packet starting symbols: // DATA_PREFIX, DATA_NULL, or SPEED int fifoBacklog; // Current number of symbols queued in the receive FIFO int mustDelete; // High level watermark allowing data repeating to begin // without the insertion of additional deletable symbols float nonDeletableTime; // Duration of mandatory symbols in a packet prefix (in seconds) float deletableTime; // Duration of deletable symbols to be inserted after the packet // prefix, assuming the FIFO isn’t critically behind (in seconds) arbTimer = 0; nonDeletableTime = 0; deletableTime = 0; mustDelete = 0; nonNullPacket = FALSE; // Reset data payload indicator at beginning of each new packet dataNullPacket = FALSE; if (!DS_stuck) { maxBetaTimer = 0; DS_stuck = TRUE;
// timer only needs to be implemented in border capable nodes // and note that this will have to be released by sending // a legacy format packet
} portTArb(receivePort, IDLE); port prefixComplete = FALSE; formatCommitted = FALSE; currentFormat = BETA; legacyPhaseExpected = FALSE; arb = portRArb[receivePort]; previousArb = IDLE;
// Immediately begin sending requests on a beta receive // // // // // //
and remove grant, if any, on a legacy receive port still in valid packet beginning sequence start out not knowing received packet format Assume Beta format until proven otherwise. for Beta format packets arb state on entry
// Wait for incoming packet prefix to complete. While waiting, process any speed-signaling // received, cycle start tokens received, or any gap events (subaction gap or arb-reset gap) // that occur. Upon entry into startRxPacket, the incoming arb state on the receivePort // will be either DATA_PREFIX, DATA_NULL, SPEED, CYCLE_START_ODD, or CYCLE_START_EVEN. // Furthermore, requests to process gap events are initially FALSE as they are processed with // priority in idleActions(). // Also ensure that the min packet prefix requirements are met for all packets formats and // insert the requisite number of deletable symbols prior to repeating data payloads while (!prefixComplete || (arbTimer < nonDeletableTime) || ((arbTimer < nonDeletableTime + deletableTime) && !(fifoBacklog > mustDelete))) { switch (arb) { // Process DATA_PREFIX and DATA_NULL states first, partly to ensure // legacy ports are busied as soon as possible case DATA_PREFIX: didArbrst = FALSE; // allow arb reset tokens again after bus activity dataNullPacket = FALSE;
Copyright © 2008 IEEE. All rights reserved.
637
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-16—Border receive functions (continued) if (!formatCommitted) {
// DATA_PREFIX before any speed code signifies legacy
format currentFormat = LEGACY; legacyPhaseExpected = TRUE; formatCommitted = TRUE; arbTimer = 0; // in case it comes after a long DATA_NULL receivedSpeedSignal = FALSE; for (i = 0; i < NPORT; i++) speedOk[i] = TRUE; nonDeletableTime = legacyTime(SPEED_SIGNAL_LENGTH + DATA_PREFIX_HOLD); txControl(arb, receivePort); // Repeat the arb state } else { // DP after speed for (i = 0; i < NPORT; i++) if (i != receivePort) portTArb(i, (speedOk[i] || currentFormat == LEGACY) ? DATA_PREFIX: DATA_NULL); } break; case DATA_NULL: didArbrst = FALSE; // allow arb reset tokens again after bus activity if (!formatCommitted) { // DATA_NULL’s received before the format are considered txControl(arb, receivePort); // starting symbols and are repeated dataNullPacket = TRUE; } else // DATA_NULL after the format has been repeated indicates prefixComplete = TRUE; // a packet ending state and is treated as such to break; // guarantee packet timings for concatenations case SPEED: didArbrst = FALSE; // allow arb reset tokens again after bus activity currentSpeed = portRSpeed[receivePort]; currentFormat = currentPkt[receivePort]; legacyPhaseExpected = (currentFormat == LEGACY); formatCommitted = TRUE; dataNullPacket = FALSE; receivedSpeedSignal = TRUE; arbTimer = 0; // case of long DP or DN followed by real packet prefix // reset so that deletable symbols are inserted properly // common code for signaling speed on both port types for (i = 0; i < NPORT; i++) if (i != receivePort) { // Repeat the speed signal speedOk[i] = (currentSpeed <= portSpeed[i]) && (betaMode[i] || currentFormat == LEGACY); if (speedOk[i]) portTSpeed(i, currentSpeed, currentFormat); // format only needed for Beta mode ports else portTArb(i, currentFormat == LEGACY ? DATA_PREFIX : DATA_NULL); } waitSymbolTime(currentSpeed); for (i = 0; i < NPORT; i++) // now send the next symbol on the Beta mode ports if (i != receivePort && betaMode[i]) portTArb(i, speedOk[i] || currentFormat == LEGACY ? DATA_PREFIX: DATA_NULL); if (currentFormat == LEGACY) { // therefore currentSpeed < S800 // extend the speed signal // waited 1, 2 or 4 legacyTime units waitLegacyTime(SPEED_SIGNAL_LENGTH - legacySymbolCount(currentSpeed)); // now send the next symbol on the DS ports for (i = 0; i < NPORT; i++) if (i != receivePort)
638
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-16—Border receive functions (continued) // harmless writing this to the beta mode ports as well portTArb(i, speedOk[i] || currentFormat == LEGACY ? DATA_PREFIX: DATA_NULL); // ensure entire packet prefix time consumes 2 symbol times or // (SPEED_SIGNAL_LENGTH+DATA_PREFIX_HOLD), whichever is longer if (2*legacySymbolCount(currentSpeed) > SPEED_SIGNAL_LENGTH+DATA_PREFIX_HOLD) nonDeletableTime = legacyTime(2*legacySymbolCount(currentSpeed)); else nonDeletableTime = legacyTime(SPEED_SIGNAL_LENGTH + DATA_PREFIX_HOLD); } else // not legacy format nonDeletableTime = 2*symbolTime(currentSpeed); break; case CYCLE_START_ODD: case CYCLE_START_EVEN: didArbrst = FALSE; // allow arb reset tokens again after bus activity if (!formatCommitted) { // always expect cycle start token before format indication oddIsochPhase = (arb == CYCLE_START_ODD); if (link == B_LINK) // Alert link PH_DATA_indication(oddIsochPhase ? PH_ISOCH_ODD: PH_ISOCH_EVEN, 0, 0, 0); for (i = 0; i < NPORT; i++) // Cycle start tokens are not sent on DS ports, if (!betaMode[i]) portTArb(i, DATA_PREFIX); // send DATA_PREFIX instead to prevent idle gap sendControl(oddIsochPhase ? CYCLE_START_ODD: CYCLE_START_EVEN, receivePort); isoCycle = TRUE; // After repeating cycle start token, treat as if a DATA_NULL had been received txControl(DATA_NULL, receivePort); arbTimer = 0; // so that CST symbols are not treated as packet prefix symbols } else // error case, token received after packet formatting prefixComplete = TRUE; // treat as ending symbol of mal-formed packet break; case DATA_BYTE: didArbrst = FALSE; // allow arb reset tokens again after bus activity prefixComplete = TRUE; dataNullPacket = FALSE; tooLateForIsoch = FALSE; // now OK for isoch indications from the Link // When sending data, requirement is to send deletable symbols for at least one packet symbol // or 20 ns, whichever is greater (provided the FIFO isn’t in a critical state). Since, the // underflow prevention logic used to center the FIFO unconditionally inserts 20ns of time, // additional time is only provided within this loop for packet symbol times that are larger // than 20 ns: namely, S100 and S200 speeds. if ((currentSpeed == S100) || (currentSpeed == S200)) deletableTime = legacyTime(legacySymbolCount(currentSpeed) legacySymbolCount(S400)); mustDelete = currentSpeed == S3200 ? 16 : currentSpeed == S1600 ? 8 : currentSpeed == S800 ? 4 : 2; // nominal 40 ns, or two symbol for S200 and S100 break; case ASYNC_EVEN: case ASYNC_ODD: // Process each distinct gap token received within a packet prefix by ensuring that filters // applied in gapToken() are disabled filterAsyncEven = FALSE; filterAsyncOdd = FALSE;
Copyright © 2008 IEEE. All rights reserved.
639
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-16—Border receive functions (continued) if (gapToken(receivePort)) { // always returns true since filters have been cleared gapRepeatActions(receivePort); portTArb(receivePort, IDLE); // restore the ports to previous state arb = previousArb; // and prevent the code below picking up the token txControl(arb, receivePort); } break; default: // any other arb signal indicates packet prefix has concluded, prefixComplete = TRUE; // exit loop after prefix timings have been met // leave mustDelete as zero if no data byte break; } // if still in the packet prefix, advance the FIFO to the next arbitration indication if (!prefixComplete) { previousArb = arb; // arb has been backed off if a token arb = portRNextArb(receivePort); } fifoBacklog = (FIFO_DEPTH + fifoWrPtr[receivePort] - fifoRdPtr[receivePort]) % FIFO_DEPTH; } if (dataNullPacket) { if (proxyRoot) currentSpeed = S100; for (i = 0; i < NPORT; i++) speedOk[i] = TRUE; } if (arb == DATA_BYTE || arb == DATA_END) { // Actually receiving a packet or at packet end? // wait on DE in order not to miss a possible LEGACY_PHASE arbTimer = 0; while (!(fifoBacklog > mustDelete) && (arbTimer < legacyTime(legacySymbolCount(S400)))) { // Allow time for the FIFO to load, but start repeat immediately if critical fifoBacklog = (FIFO_DEPTH + fifoWrPtr[receivePort] - fifoRdPtr[receivePort]) % FIFO_DEPTH; } if (tMode[receivePort]) { arbTimer = 0; while ((fifoBacklog < (FIFO_DEPTH/2)) && (arbTimer < TMODE_SYMBOL_JITTER)) { // Allow time for the FIFO to load, but start repeat immediately if critical fifoBacklog = (FIFO_DEPTH + fifoWrPtr[receivePort] - fifoRdPtr[receivePort]) % FIFO_DEPTH; } } } *endingArb = arb; // final arb that was read }
640
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-17—PHY packet processing // decode_phy_packet.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
PHY_pkt phyRespPkt; // Create remote confirmation or reply packet here byte readPhyReg(int page, int portNum, int reg, boolean base_reg); // Not defined in C code // Return current value of specified PHY register void remoteAccess(int page, int portNumVal, int reg, int extTypeVal) { // Current value of remotely read register phyRespPkt.dataQuadlet = 0; phyRespPkt.phy_ID = physical_ID; phyRespPkt.extType = (extTypeVal == 1) ? 3 : 7; phyRespPkt.page = page; phyRespPkt.portNum = portNumVal; phyRespPkt.reg = reg; phyRespPkt.data = readPhyReg(page, portNumVal, reg, extTypeVal == 1); phyResponse = TRUE; } void remoteCommand(int cmnd, int eCmndVal, int portNumVal) { // Conditionally execute requested command int i, numConnectedPorts = 0; int standbyPort = NPORT; phyRespPkt.dataQuadlet = 0; phyRespPkt.phy_ID = physical_ID; phyRespPkt.extType = 0x0A; phyRespPkt.portNum = portNumVal; phyRespPkt.ok = TRUE; if (portNumVal >= NPORT) phyRespPkt.ok = FALSE; // port out of range? else if (cmnd == 1) // Disable port if (portNumVal == receivePort) // What? Disable the port that received the packet? phyRespPkt.ok = FALSE; // No, node is not going to lock itself out... else if (active[portNumVal]) // Active, DISABLE_NOTIFY to peer PHY first disableRequest[portNumVal] = TRUE; else // Otherwise (inactive), just mark disabled disabled[portNumVal] = TRUE; else if (cmnd == 2) // Suspend port if (!active[portNumVal] || resumeInProgress() || suspendInProgress()) phyRespPkt.ok = FALSE; else suspendRequest[portNumVal] = TRUE; else if (cmnd == 4) // Clear fault conditions resumeFault[portNumVal] = suspendFault[portNumVal] = standbyFault[portNumVal] = FALSE; else if (cmnd == 5) // Enable port disabled[portNumVal] = FALSE; else if (cmnd == 6) // Resume port if (active[portNumVal] || !connected[portNumVal] || disabled[portNumVal] || resumeInProgress() || suspendInProgress()) phyRespPkt.ok = FALSE; else
Copyright © 2008 IEEE. All rights reserved.
641
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-17—PHY packet processing (continued) resume[portNumVal] = TRUE; else if (cmnd == 7) { // Extended command if (eCmndVal == 1) { // Standby the one active port for (i = 0; i < NPORT; i++) { if (connected[i]) numConnectedPorts++; if (active[i]) standbyPort = i; // find an active port } if (!enableStandby || (standbyPort == NPORT) || (numConnectedPorts > 1) || !betaMode[standbyPort] || root || (link == LEGACY_Link)) // accept if Beta or no link phyRespPkt.ok = FALSE; else doStandby[standbyPort] = TRUE; } if (eCmndVal == 2) // Restore port if (active[portNumVal] || !connected[portNumVal] || disabled[portNumVal]) phyRespPkt.ok = FALSE; else restore[portNumVal] = TRUE; } if (!((cmnd == 7) && (eCmndVal == 1))) { // fields ignored on standby command phyRespPkt.standbyFault = standbyFault[portNumVal]; phyRespPkt.fault = fault[portNumVal]; phyRespPkt.connected = connected[portNumVal]; phyRespPkt.bias = receiveOk[portNumVal]; phyRespPkt.disabled = disabled[portNumVal]; } phyRespPkt.cmnd = cmnd; phyRespPkt.eCmnd = eCmndVal; phyResponse = TRUE; } void decodePhyPacket(PHY_pkt phyPacket) { int i; boolean LTP_packet; LTP_packet = FALSE; if (phyPacket.phyPacketType == 0x2) { // self_ID packet? self_ID_pkt = phyPacket; if (busInitializeActive) { // note, can’t do this processing in self_ID receiveActions, // as self_ID’s from the parental side are received in normal arbitration // look for PHY speed to set maxLegacyPathSpeed bNodeRoot = receivedSpeedSignal; // finally set by the last self_ID received if ((self_ID_pkt.ext == 0) && (!betaMode[receivePort] || !receivedSpeedSignal)) { // originated from node with legacy link or DS node bBus = FALSE; isochConcatOk = FALSE; // For legacy camcorder interoperability switch (self_ID_pkt.sp) { case 0x0: break; case 0x1: maxLegacyPathSpeed = (maxLegacyPathSpeed == S100) ? S200: maxLegacyPathSpeed; break; default: maxLegacyPathSpeed = S400; break; } // Last node to originate a self-ID packet without speed-code into the local // B cloud (i.e., repeated from a DS-mode port or generated because of a
642
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-17—PHY packet processing (continued) // legacy link) becomes the seniorBorder. // If repeating a self-ID from a DS-mode child port, then also become // proxyRoot; but if the port is the parent port, then must be seniorBorder in a junior B cloud. seniorBorder = !betaMode[receivePort]; proxyRoot = (!betaMode[receivePort] && child[receivePort]); seniorPort = (!betaMode[receivePort] && child[receivePort]) ? NPORT+1 : receivePort; } } } else if (phyPacket.phyPacketType == 0x1) { // Link-on packet? if (phyPacket.phy_ID == physical_ID) PH_EVENT_indication(PH_LINK_ON, 0, 0); // LinkOn asserted only if either LPS_pin or LCtrl FALSE } else if (phyPacket.R != 0 || phyPacket.T != 0) { // PHY configuration packet? if (phyPacket.R == 1) // Set forceRoot if address matches forceRoot = (phyPacket.root_ID == physical_ID); if (phyPacket.T == 1) { // Set gapCount regardless of physical_ID gapCount = phyPacket.gapCount; gapCountResetDisable = TRUE; } } else if (phyPacket.extType == 0) // Ping packet? pingResponse = (phyPacket.phy_ID == physical_ID); else if ((phyPacket.extType == 1 || phyPacket.extType == 5) && phyPacket.phy_ID == physical_ID) remoteAccess(phyPacket.page, phyPacket.portNum, phyPacket.reg, phyPacket.extType); else if (phyPacket.extType == 8 && phyPacket.phy_ID == physical_ID) remoteCommand(phyPacket.cmnd, phyPacket.eCmnd, phyPacket.portNum); else if (phyPacket.extType == 0xF) { // Resume packet? for (i = 0; i < NPORT; i++) if (!active[i] && !disabled[i] && connected[i]) resume[i] = TRUE; // Resume all suspended/suspending ports } else if (phyPacket.extType == 0xE) { // LTP packet? HR_mode = phyPacket.mode; HR_G = phyPacket.G; HR_testValue = (int)(phyPacket.testValue); needNewLTP = FALSE; testIntervalTimer = 0; LTP_packet = TRUE; } if (!LTP_packet) HR_mode = LTP_TEST; // reset on all PHY packets except LTP packets } void phyResponseActions() { receivePort = NPORT; // local node is transmitting (no port has this number) PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity startTxPacket(S100, LEGACY, FALSE); // send data prefix and 98.304 Mbit/sec speed code PH_DATA_indication(PH_DATA_START, S100, 0, LEGACY); // cc the link (always) txQuadlet(phyRespPkt.dataQuadlet); txQuadlet(~phyRespPkt.dataQuadlet); // not able to call bossEndPacketActions here, as then the node would have to allow // for concatenating another packet, and there’s complications with the possible // isbr below, also cannot mark a PHY response packet from a suspend or disable
Copyright © 2008 IEEE. All rights reserved.
643
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-17—PHY packet processing (continued) // as being the end of subaction, so give an implicit grant and return to Idle PH_DATA_indication(PH_DATA_END, 0, 0, 0); stopTxPacket(DATA_END, NPORT); if ((phyRespPkt.extType == 0x0A) && (phyRespPkt.ok == 1)) { if (disableRequest[phyRespPkt.portNum] || phyRespPkt.cmnd == 2) { isbr = isbrOk = TRUE; // Bus reset active ports if disable or suspend immediatePhyRequest = TRUE; // To keep control to send the SUSPEND or DISABLE } if ((phyRespPkt.cmnd == 7) && (phyRespPkt.eCmnd == 1)) immediatePhyRequest = TRUE; // To keep control to send the STANDBY } phyResponse = FALSE; }
644
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-18—Legacy arbitration functions // ds_arb_functions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
boolean flyByPermitted() { // TRUE if fly-by acceleration OK if (!(linkCsIndications || root)) // legacy links at root don’t provide indications return(FALSE); else if (receivePort == seniorPort) return(FALSE); else if (reqSpeed == S100 && currentSpeed != S100) return(FALSE); else if (isoCycle && !isochConcatOk) // legacy camcorder problem return (FALSE); else if (breq == ISOCH_REQ) return(TRUE); else if (ack && (accelerating || root)) return(breq == PRIORITY_REQ || (breq == FAIR_REQ && arbEnable)); else return(FALSE); } boolean legacyJuniorRequesting() { int i; for (i=0; i< NPORT; i++) { if (i != seniorPort) if (portRArb[i] == LEGACY_REQUEST) { requestingPort = i; // Found a junior that is requesting the bus grantToGive = GRANT; return(TRUE); } } return (FALSE); } boolean legacyJuniorRequestPresent() { int i; for (i=0; i< NPORT; i++) { if (i != seniorPort) if (portRArb[i] == LEGACY_REQUEST) { return(TRUE); } } return (FALSE); }
// Found a junior that is requesting the bus
boolean dataComingOn(int port) { return (active[port] && ((portRArb[port] == DATA_PREFIX) || (portRArb[port] == DATA_NULL) || (portRArb[port] == SPEED) || (portRArb[port] == CYCLE_START_ODD) || (portRArb[port] == CYCLE_START_EVEN)));
Copyright © 2008 IEEE. All rights reserved.
645
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-18—Legacy arbitration functions (continued) } boolean dataComing() { int i; for (i = 0; i < NPORT; i++) if (dataComingOn(i)) { receivePort = i; return(TRUE); } return(FALSE); } void legacyRequestActions() { int i; if (!DS_stuck) { maxBetaTimer = 0; nodes DS_stuck = TRUE;
// Remember port for later...
// LEGACY_ARB request
// timer
only needs to be implemented in border capable
// and note that this will have to be released by sending // a legacy format packet
} nonNullPacket = FALSE; // following used when node re-enters A1 to do gap repeat actions if (sendAsyncStartToken || arbReset) { gapRepeatActions(seniorPort); if (requestingPort != NPORT) portTArb(requestingPort, IDLE); } for (i = 0; i < NPORT; i++) { // Send data null to all non-requesting juniors if ((i != seniorPort) && (i != requestingPort)) portTArb(i, DATA_NULL); } portT[seniorPort].arb = LEGACY_REQUEST; portT[seniorPort].speed = DEFAULT; portT[seniorPort].data = (byte)legacyRequestPhase; portT[seniorPort].tag = LEGACY_ARB; } boolean arbPermitted() { boolean asyncArbOk = FALSE; if (DS_stuck) return (FALSE); in receive
// TRUE if OK to request the bus // Timing window OK for asynchronous arbitration? // Don’t grant to or arbitrate for legacy devices stuck
if (arbTimerMax) asyncArbOk = TRUE; // Arb timer previously saturated else { if (arbTimer < subactionGap + arbDelay) // Only window for accelerations asyncArbOk = ((linkCsIndications && accelerating) || root) && ack; if (arbTimer >= subactionGap) { if (legacyJuniorRequesting()) asyncArbOk = TRUE; // Small window for stealing a child’s request else if (arbTimer == subactionGap + arbDelay) asyncArbOk = TRUE; // Window for first fair request and priority requests else if (arbTimer >= arbResetGap + arbDelay) asyncArbOk = TRUE; // Window for all requests (new fairness interval) } }
646
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-18—Legacy arbitration functions (continued) if (breq == ISOCH_REQ || resolveCollisionRequest) { convertedRequest = FALSE; ownRequest = TRUE; requestingPort = NPORT; grantToGive = GRANT_ISOCH; } else if (isochPending && !proxyRoot) { // pipelined Beta isoch request to be forwarded convertedRequest = TRUE; // isochPending and asyncPending used only at seniorBorder ownRequest = (isochPendingPort == NPORT); // if at proxyRoot, use okToGrant mechanism (see idleActions) requestingPort = isochPendingPort; grantToGive = GRANT_ISOCH; } else if ((breq == PRIORITY_REQ) && asyncArbOk) { convertedRequest = FALSE; ownRequest = TRUE; requestingPort = NPORT; grantToGive = GRANT; } else if ((breq == FAIR_REQ) && asyncArbOk && arbEnable) { convertedRequest = FALSE; ownRequest = TRUE; requestingPort = NPORT; grantToGive = GRANT; } else if (asyncPending && asyncArbOk && !proxyRoot) { convertedRequest = TRUE; ownRequest = (asyncPendingPort == NPORT); requestingPort = asyncPendingPort; grantToGive = GRANT; } else { convertedRequest = FALSE; ownRequest = FALSE; } return(ownRequest || convertedRequest); } boolean legacyGrant() { return ((portRArb[seniorPort] == GRANT) || (portRArb[seniorPort] == GRANT_ISOCH)); }
Table 19-19—Border arbitration functions // beta_arb_functions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
betaRequestCode bestRequest(byte *apm, byte *ipm, int *bap, int *bip, boolean *inPhaseIsochRequest, boolean *inPhaseAsyncRequest, boolean *iAdvanceInterval, boolean *aAdvanceInterval) { betaRequestCode bestReq; boolean requestsUnknown; int i; bestReq.async = ownReq.async; bestReq.isoch = ownReq.isoch; requestsUnknown = FALSE; *apm = (byte) (oddAsyncPhase ? 0xf0 : 0x0f); // select async priority mask
Copyright © 2008 IEEE. All rights reserved.
647
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-19—Border arbitration functions (continued) *ipm = (byte) (oddIsochPhase ? 0xf0 : 0x0f); // select isoch priority mask *bap = *bip = NPORT; // prefer own link for (i = 0; i < NPORT; i++) { // find the best request and associated port if (i != seniorPort) { // then prefer junior ports first bestReq.async = (active[i] && betaMode[i] && ((receiveReq[i].async & *apm) > (bestReq.async & *apm)) ? receiveReq[*bap = i].async : bestReq.async); bestReq.isoch = (active[i] && betaMode[i] && ((receiveReq[i].isoch & *ipm) > (bestReq.isoch & *ipm)) ? receiveReq[*bip = i].isoch : bestReq.isoch); } if (active[i] && betaMode[i] && (((receiveReq[i].async & *apm) == A_NONE) || ((receiveReq[i].isoch & *ipm) == I_NONE))) { requestsUnknown = TRUE; // at least one active port hasn’t received an updated request } } if (!proxyRoot) { // finally prefer senior port bestReq.async = (active[seniorPort] && betaMode[seniorPort] && ((receiveReq[seniorPort].async & *apm) > (bestReq.async & *apm)) ? receiveReq[*bap = seniorPort].async : bestReq.async); bestReq.isoch = (active[seniorPort] && betaMode[seniorPort] && ((receiveReq[seniorPort].isoch & *ipm) > (bestReq.isoch & *ipm)) ? receiveReq[*bip = seniorPort].isoch : bestReq.isoch); } // inPhaseIsochRequest returns true anytime an ISOCH_CURRENT is present or // during the isoCycle when an in-phase isoch request is present // inPhaseAsyncRequest returns true only during the asynchronous interval // when an in-phase asynch request is present *inPhaseIsochRequest = ((isoCycle && ((bestReq.isoch & *ipm) >= (ISOCH_IN_PHASE & *ipm))) || (!isoCycle && ((bestReq.isoch & *ipm) == (ISOCH_CURRENT & *ipm)))); *inPhaseAsyncRequest = (!isoCycle && ((bestReq.async & *apm) >= (CURRENT & *apm))); // iAdvanceInterval returns true if all inbound isoch requests are known and no requests // remain for the current isoch interval // aAdvanceInterval returns true if all inbound async requests are known and no requests // remain for the current async interval (including NONE_EVEN/ODD requests used to throttle // progression of fairness intervals *iAdvanceInterval = (!requestsUnknown && ((bestReq.isoch & *ipm) < (ISOCH_IN_PHASE & *ipm))); *aAdvanceInterval = (!requestsUnknown && ((bestReq.async & *apm) < (oddAsyncPhase ? NONE_EVEN & *apm : NONE_ODD & *apm))); return (bestReq); } bossEopStatus testRequests(int *bestPort, boolean grantReceivedFromSenior, arbState *receivedGrant) { int i; int bip = NPORT; int bap = NPORT;
648
// best isochronous request port number // best asynchronous request port number
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-19—Border arbitration functions (continued) byte apm; // mask to select the in-phase async requests byte ipm; // mask to select the in-phase isoch requests boolean inPhaseIsochRequest, inPhaseAsyncRequest; boolean iAdvanceInterval, aAdvanceInterval; betaRequestCode bestReq; pktType nextFormat; // holds format and speed of next packet PHY speedCode nextSpeed; // will transmit if it GRANTs itself boolean requestToService; *bestPort = NPORT; bestReq = bestRequest(&apm, &ipm, &bap, &bip, &inPhaseIsochRequest, &inPhaseAsyncRequest, &iAdvanceInterval, &aAdvanceInterval); // find best request // // // // //
Refrain from passing a grant received from a junior port to either a link or another junior port when (a) the bus is in async phase, and (b) the cycle master is outside the beta cloud (!bNodeRoot), and (c) a cycle start is expected
if (!grantReceivedFromSenior && !isoCycle && !bNodeRoot && !(linkCsIndications && accelerating)) { // kill all async BOSS requests // Note that a priority request from a legacy cycle master to send the cycle start packet // will be picked up in A0:Idle by the arbPermitted() test. inPhaseAsyncRequest = FALSE; } requestToService = TRUE; // Until proven otherwise if (ownReq.async == BORDER) // only when senior border requestToService = FALSE; else if ((*receivedGrant == GRANT_ISOCH) && inPhaseIsochRequest) *bestPort = bip; else if ((*receivedGrant == GRANT) && inPhaseAsyncRequest) *bestPort = bap; else if ((*receivedGrant == DATA_END) && (bestReq.isoch == ISOCH_CURRENT) && isochConcatOk) { // don’t encourage another node to concatenate // for legacy camcorder problem *bestPort = bip; *receivedGrant = GRANT_ISOCH; // upgrade to an explicit isoch grant } else requestToService = FALSE; if (requestToService) { // normally PHY can go ahead and grant the best port or the link at this stage // however, need to take care to prevent the possibility of // concatenating a legacy S100 packet onto a legacy >S100 packet // In this case, PHY needs to give a grant to the senior port, who also // has to ensure that this situation cannot happen if (*bestPort == NPORT) // Since PHY prefers to grant itself, determine what format and speed packet // would be sent next if (link == LEGACY_Link) { // Actual requests from legacy link aren’t processed in bestReq, so only
Copyright © 2008 IEEE. All rights reserved.
649
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-19—Border arbitration functions (continued) // need to consider PHY initiated requests if (isbr) { nextFormat = LEGACY; nextSpeed = S100; } else if (restoreRequest) { nextFormat = BETA; nextSpeed = S100; } else { // a loopTestRequest nextFormat = LEGACY; nextSpeed = S100; } } else { // not a LEGACY_Link if (*receivedGrant == GRANT_ISOCH) { nextFormat = iFormat; nextSpeed = iSpeed; } else if (cycleStartRequest && root) { nextFormat = cycStartFormat; nextSpeed = cycStartSpeed; } else if (isbr) { // Assume format used for a non bBus since rule won’t apply to a bBus nextFormat = LEGACY; nextSpeed = S100; } else if (restoreRequest) { nextFormat = BETA; nextSpeed = S100; } else if (loopTestRequest) { nextFormat = LEGACY; nextSpeed = S100; } else { // an async request nextFormat = aFormat; nextSpeed = aSpeed; } } else { // Best port isn’t the local PHY, so have to assume the worst and that // the next packet might ultimately result in a legacy S100 packet nextFormat = LEGACY; nextSpeed = S100; } if (!bBus && (currentFormat == LEGACY) && (currentSpeed != S100) && (nextFormat == BETA || nextSpeed == S100)) // just finishing a non-S100 legacy packet and the next packet could // ultimately appear as an S100 legacy packet. return(GRANT_SENIOR); else { if (*bestPort == NPORT) return(GRANT_LINK); if (*bestPort == seniorPort) return(GRANT_SENIOR); else { for (i = 0; i < NPORT; i++) // don’t prolong collision situation
650
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-19—Border arbitration functions (continued) if (collision[i]) return (GRANT_SENIOR); return(GRANT_JUNIOR); } } } // nothing to service if (*receivedGrant == DATA_END) // implicit grant, pass on return(GRANT_SENIOR); else if (bBus) { // Check for safe end of intervals, taking care never to // end the interval if out of sync with the bus or the grant came from // a senior port (indicates a cancelled request that can temporarily // block other in-phase requests) if (isoCycle && iAdvanceInterval && (*receivedGrant == GRANT_ISOCH) && !grantReceivedFromSenior) { // end of isoch interval sendAsyncStartToken = TRUE; *receivedGrant = GRANT; // change to async grant, so that async req’s can be checked } if ((!isoCycle || sendAsyncStartToken) && aAdvanceInterval && !didArbrst && (*receivedGrant == GRANT) && !grantReceivedFromSenior) { // create arb reset if no current phase or left over previous phase requests oddAsyncPhase = !oddAsyncPhase; arbReset = TRUE; didArbrst = TRUE; // after repeating an arb reset token, disallow further phase // advancements in a B bus until non IDLE traffic occurs } return((arbReset || sendAsyncStartToken) ? BOSS_MANAGEMENT_ACTIONS : GRANT_SENIOR); } else { // hybrid bus with explicit grant, free stuck DS ports if necessary if (currentFormat != LEGACY) return(GRANT_NULL); else return(GRANT_SENIOR); } } void bossEndPacketActions(boolean grantReceivedFromSenior, arbState grantType) { // // // //
make sure that any legacy packet that is non-s100 is terminated with DATA_END otherwise it is possible to generate a legacy >s100 concatenated by a S100 legacy, which is prohibited. cannot terminate with DATA_NULL
// End of packet, determine if the local node is boss and should grant a pending request // If so, the grant_port = favorite in-phase request // // // // // //
If granting senior port, don’t deny junior ports. If granting a junior port send GNT GNT on grant port, or nothing if granting the link (grant port = NPORT) send data_null on other Beta ports send DP on DS ports wait 2 x max (grant port time or packet time)
// if granting the link or a PHY action (grant port is NPORT) then set grantSelf // in order to // loop back on exit from TX actions to get the next packet from the link.
Copyright © 2008 IEEE. All rights reserved.
651
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-19—Border arbitration functions (continued) // if BOSS and no port to grant, and hybrid bus, then pass a grant to senior port if suitable // otherwise send a token if possible int i; bossEopStatus reqStatus; // find best isoch and async request reqStatus = testRequests(&requestingPort, grantReceivedFromSenior, &grantType); switch (reqStatus) { case GRANT_SENIOR: if (grantReceivedFromSenior) { // can’t grant back to senior, stopTxPacket(grantType, NPORT); // so grant self and sendNullPacket = TRUE; // schedule TX of a null packet grantSelf = TRUE; } else { stopTxPacket(grantType, seniorPort); requestingPort = NPORT; // Set okToGrant for proxyRoot’s use in A0:Idle if end of subaction detected // and the grant type communicated matches the local PHY’s interval (async vs isoch) // Special care is taken at the cycle master if attached to a legacy link to ensure // that a priority bus request for the cycle start packet can be issued if required if (((grantType == GRANT_ISOCH) && isoCycle) || ((grantType == GRANT) && !isoCycle)) { // explicit grant received that matches PHY’s interval if (root && (link == LEGACY_Link)) { // await possible PriReq for cycle start okToGrant = FALSE; deferGrant = TRUE; } else { // explicit end of subaction, no need to defer grant in A0:Idle okToGrant = TRUE; deferGrant = FALSE; } } else { // still expecting end of subaction or non-matching grant type okToGrant = FALSE; deferGrant = FALSE; } } return; case GRANT_LINK: stopTxPacket(grantType, NPORT); grantToGive = grantType; grantSelf = TRUE; return; case GRANT_NULL: stopTxPacket(grantType, NPORT); sendNullPacket = TRUE; // schedule TX of a null packet grantSelf = TRUE; return; case GRANT_JUNIOR: stopTxPacket(grantType, requestingPort); grantToGive = grantType; return; case BOSS_MANAGEMENT_ACTIONS: stopTxPacket(grantType, NPORT); gapRepeatActions(NPORT); // having advanced the gap, now look for a favorite request again grantType = GRANT; reqStatus = testRequests(&requestingPort, grantReceivedFromSenior, &grantType);
652
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-19—Border arbitration functions (continued) switch (reqStatus) { case GRANT_SENIOR: for (i = 0; i < NPORT; i++) if (i != seniorPort) portTArb(i, IDLE); // while snr port gets GRANT if (proxyRoot) { waitSymbolTime(S100); waitSymbolTime(S100); } else { portTArb(seniorPort, GRANT); waitSymbolTime(portSpeed[seniorPort]); waitSymbolTime(portSpeed[seniorPort]); } okToGrant = TRUE; // for proxyRoot’s use in A0:Idle deferGrant = FALSE; requestingPort = NPORT; // so that node goes to Idle return; case GRANT_LINK: grantToGive = grantType; grantSelf = TRUE; didArbrst = FALSE; // only relevant to a bBus return; case GRANT_NULL: sendNullPacket = TRUE; // schedule TX of a null packet grantSelf = TRUE; didArbrst = FALSE; // only relevant to a bBus return; case GRANT_JUNIOR: grantToGive = grantType; didArbrst = FALSE; // only relevant to a bBus return; case BOSS_MANAGEMENT_ACTIONS: // this should now never happen again!! return; } } } void gapRepeatActions(int tokenReceivePort) { // // // // //
Calling gapRepeatActions will send ASYNC_EVEN/ODD tokens (for at least one S100 symbol time), indicating either a subaction gap (in a hybrid bus), async-start (i.e., end of isoch period, in a bBus), or arbReset (i.e., change of async phase, in any bus). Ports on which the token was transmitted continue to transmit the token symbol.
// first, send appropriate indications to link. if (link == B_LINK) { if (sendAsyncStartToken || isoCycle) // either token ends the isoch interval PH_DATA_indication(PH_SUBACTION_GAP, 0, 0, 0); if (arbReset) PH_DATA_indication(oddAsyncPhase ? PH_ARB_RESET_ODD : PH_ARB_RESET_EVEN, 0, 0, 0); if (busInitializeActive) { // end of self_ID process for whole bus? PH_EVENT_indication(PH_BUS_RESET_COMPLETE, 0, 0); busInitializeActive = FALSE; } } if (isoCycle) {
Copyright © 2008 IEEE. All rights reserved.
// either token ends the isoch interval
653
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-19—Border arbitration functions (continued) isoCycle = FALSE; oddIsochPhase = !oddIsochPhase; isochConcatOk = bBus; tooLateForIsoch = TRUE;
// advance phase at end of isoch interval // for legacy camcorder interoperability
} // now, send the async gap token sendControl(oddAsyncPhase ? ASYNC_ODD : ASYNC_EVEN, tokenReceivePort); if (arbReset) arbEnable = TRUE; // re-enable fair arbitration for legacy links arbReset = sendAsyncStartToken = FALSE; }
19.4.2 Request processing Table 19-20 specifies the background processing of requests.
Table 19-20—Background request processing // process_req.c #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “shared.h”
// common routine to cancel outstanding link requests, invoked // whenever the link is notified of a restore or bus reset void cancelRequests(){ breq = NO_REQ; immediateLinkRequest = FALSE; currentRequest = FALSE; nextOddRequest = FALSE; nextEvenRequest = FALSE; isochOddRequest = FALSE; isochEvenRequest = FALSE; cycleStartRequest = FALSE; } // continuously running routine to capture link requests and set appropriate shared variables // all updates made in each cycle of this routine are assumed to be atomic void captureLinkRequests() { PhyArbReqService phyArbReq; // latest request from a link (if any) if (powerReset) { cancelRequests(); // also on PHY/Link reset and disable linkCsIndications = FALSE; enableStandby = FALSE; while (powerReset) ; // assume an indication after power reset link = PH_LINK_TYPE_response(); // link type determined on powerReset } phyArbReq = waitPH_ARB_request(); // wait for next link request switch (phyArbReq.reqType) { case PH_IMMED_REQ: // from Beta link or legacy link restorePort(); // restore if on nephew
654
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-20—Background request processing (continued) immediateLinkRequest = TRUE; if (link == LEGACY_Link) { reqSpeed = phyArbReq.speed; } else { immSpeed = phyArbReq.speed; immLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; immFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (immSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; } break; // The PHY can hold only one async request at a time (current or next_*) case PH_CURRENT: restorePort(); // restore if on nephew currentRequest = TRUE; nextOddRequest = nextEvenRequest = FALSE; aSpeed = phyArbReq.speed; aLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; aFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (aSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_NEXT_ODD: restorePort(); // restore if on nephew if (!oddAsyncPhase) { nextOddRequest = TRUE; nextEvenRequest = currentRequest = FALSE; } else { currentRequest = TRUE; nextOddRequest = nextEvenRequest = FALSE; } aSpeed = phyArbReq.speed; aLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; aFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (aSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_NEXT_EVEN: restorePort(); // restore if on nephew if (oddAsyncPhase) { nextEvenRequest = TRUE; nextOddRequest = currentRequest = FALSE; } else { currentRequest = TRUE; nextOddRequest = nextEvenRequest = FALSE; } aSpeed = phyArbReq.speed; aLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; aFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (aSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_CYC_START_REQ: // to send a cycle start packet, preceded by a cycle_start_token // Note that cycle start requests are the only bus requests from a beta link // that are queued after a bus reset or restore before the register 0 transfer restorePort(); // restore if on nephew cycleStartRequest = TRUE; cycStartSpeed = phyArbReq.speed;
Copyright © 2008 IEEE. All rights reserved.
655
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-20—Background request processing (continued) cycStartLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; cycStartFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (cycStartSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_ISOCH_REQ_EVEN: restorePort(); // restore if on nephew isochEvenRequest = TRUE; isochOddRequest = FALSE; iSpeed = phyArbReq.speed; iLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; iFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (iSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_ISOCH_REQ_ODD: restorePort(); // restore if on nephew isochOddRequest = TRUE; isochEvenRequest = FALSE; iSpeed = phyArbReq.speed; iLinkFormat = phyArbReq.betaFormat ? BETA: UNSPECIFIED; iFormat = ((phyArbReq.betaFormat) || (!busInitializeActive && (bBus || (iSpeed > maxLegacyPathSpeed))))? BETA: LEGACY; break; case PH_ISOCH_PHASE_ODD: // link has received a cycle start packet if (!tooLateForIsoch) { oddIsochPhase = TRUE; // keeps link and PHY in phase in junior beta isoCycle = TRUE; // in case cycle start token wasn’t received } else { oddIsochPhase = FALSE; // keeps link and PHY in phase in junior beta } accelerating = TRUE; break; case PH_ISOCH_PHASE_EVEN: // link has received a cycle start packet if (!tooLateForIsoch) { oddIsochPhase = FALSE; // keeps link and PHY in phase in junior beta isoCycle = TRUE; // in case cycle start token wasn’t received } else { oddIsochPhase = TRUE; // keeps link and PHY in phase in junior beta } accelerating = TRUE; break; case PH_LPS_ACTIVE: LPS_pin = TRUE; if (enableStandby) { enableStandby = ENABLE_STANDBY_DEFAULT; restorePort(); } break; case PH_LPS_INACTIVE: LPS_pin = FALSE; cancelRequests(); linkCsIndications = FALSE; break; case PH_CYCLE_START_DUE: linkCsIndications = TRUE; accelerating = FALSE; break; // finally requests from a legacy link
656
clouds
clouds
clouds
clouds
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-20—Background request processing (continued) case PH_CYCLE_START_SEEN: accelerating = TRUE; break; case PH_ISOCH_REQ: accelerating = TRUE; breq = ISOCH_REQ; reqSpeed = phyArbReq.speed; break; case PH_PRIORITY_REQ: breq = PRIORITY_REQ; reqSpeed = phyArbReq.speed; break; case PH_FAIR_REQ: breq = FAIR_REQ; reqSpeed = phyArbReq.speed; break; } } // continuously running routine to process request signals received on Beta ports and link void processRequests(){ boolean idleArbStateTimeout; // TRUE if node has an ungranted request from the link or // local PHY, see description of Arb state timeout in text betaRequestCode bestReq; byte apm, ipm; int bip, bap; // best isoch and async ports portSymbol portCurrent; boolean inPacket[NPORT]; boolean reqUnknownVect[NPORT]; // effectively per port int i,j; if (powerReset) { for (i = 0; i < NPORT; i++) { advanceOk[i] = TRUE; inPacket[i] = FALSE; ignorePort[i] = FALSE; collision[i] = FALSE; fifoRdPtr[i] = 0; reqUnknownVect[i] = FALSE; } while (powerReset) ; } // update ownReq with request from link or internal PHY request // set own async req immediateRequest = immediateLinkRequest || immediatePhyRequest || immediateRestoreRequest; if ((seniorBorder) && // the timer only runs on the senior border (maxBetaTimer > MAX_BETA_TIME) && DS_stuck) ownReq.async = BORDER; else if (cycleStartRequest && root) ownReq.async = CYCLE_START_REQ; else if (currentRequest || (restoreRequest && !immediateRestoreRequest) || loopTestRequest || isbr) // connection management requests for restoring and loop free build // as well as short bus reset requests look like current requests
Copyright © 2008 IEEE. All rights reserved.
657
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-20—Background request processing (continued) ownReq.async = CURRENT; else if (nextOddRequest) ownReq.async = NEXT_ODD; else if (nextEvenRequest) ownReq.async = NEXT_EVEN; else if (oddAsyncPhase) ownReq.async = NONE_ODD; else ownReq.async = NONE_EVEN;
// previously checked for async phase
// // // if
Set own isoch req remembering to upgrade any in-phase isoch request to ISOCH_CURRENT during the isochronous interval. Also, only ISOCH_CURRENT and ISOCH_NONE are allowed in junior beta clouds. (isoCycle && ((isochOddRequest && oddIsochPhase) || // in-phase odd request? (isochEvenRequest && !oddIsochPhase))) // in-phase even request? ownReq.isoch = ISOCH_CURRENT; else if (bNodeRoot && isochOddRequest) ownReq.isoch = ISOCH_ODD; // never present in junior beta cloud else if (bNodeRoot && isochEvenRequest) ownReq.isoch = ISOCH_EVEN; // never present in junior beta cloud else ownReq.isoch = ISOCH_NONE; idleArbStateTimeout = (!((ownReq.async == NONE_ODD || ownReq.async == NONE_EVEN) && ownReq.isoch == ISOCH_NONE)); // link or local PHY is requesting, so ensure that // Arbitration state timeout occurs when in Idle for MAX_ARB_STATE_TIME after this is set TRUE // gather incoming requests from ports, remember/forget past requests // set flags, portRArb and portRSpeed for (i = 0; i < NPORT; i++) { reqUnknownVect[i] = FALSE; // check for collisions, given that only the receivePort should be inPacket for receive states, // and no ports should be inPacket for transmit, bus reset, and tree identification states if (active[i] && inPacket[i] && (((phyState == RX) && (receivePort != i)) || ((phyState == S2) && (receivePort != i)) || ((phyState == S4) && !SID_complete) || (phyState == TX) || (phyState == PH) || (phyState < S0))) { collision[i] = TRUE; // data collision, need to keep the rest of the bus // busy until this packet completes ignorePort[i] = TRUE; // flag to ignore the rest of the packet and dequeue fifo portRArb[i] = IDLE; // clear colliding arbitration state } // invalidate stale GRANTs and LEGACY_REQUESTs if (active[i] && ((portRArb[i] == GRANT) || (portRArb[i] == GRANT_ISOCH) || (portRArb[i] == LEGACY_REQUEST)) && ((phyState == TX) || (phyState == RX) || (phyState == PH)) && (receivePort != i)) // necessary to protect GRANTs at end of packets portRArb[i] = IDLE;
658
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-20—Background request processing (continued) if (!(active[i] || restore[i]) || // always dequeue the fifo unless in active or restore !inPacket[i] || advanceOk[i] || ignorePort[i]) { if (packetEnding[i]) { inPacket[i] = FALSE; // last symbol terminated a packet ignorePort[i] = FALSE; // no longer need to ignore packetEnding[i] = FALSE; // and with the new arb state, now past the end of the packet } // OK to process next item, if there’s anything to process! if (fifoRdPtr[i] != fifoWrPtr[i]) { fifoRdPtr[i] = ++fifoRdPtr[i] % FIFO_DEPTH; portCurrent = portR[i][fifoRdPtr[i]]; advanceOk[i] = FALSE; if (portCurrent.tag == DS_RAW_ARB) { // Raw arb states received from a legacy port require filtering to resolve many of the // overloaded states. This segment of code illustrates use of the current PHY state // to perform the filtering and is not intended to preclude alternate methods portCurrent.tag = ARB_STATE; switch (portCurrent.rxDSArb) { case RX_IDLE : portCurrent.arb = IDLE; break; case RX_PARENT_NOTIFY | RX_REQUEST_CANCEL : portCurrent.arb = (phyState < A0 ? PARENT_NOTIFY : REQUEST_CANCEL); break; case RX_IDENT_DONE : portCurrent.arb = IDENT_DONE; break; case RX_SELF_ID_GRANT | RX_REQUEST : portCurrent.arb = (phyState < A0 ? SELF_ID_GRANT : LEGACY_REQUEST); break; case RX_ROOT_CONTENTION | RX_GRANT | RX_SUSPEND : portCurrent.arb = (phyState < A0 ? ROOT_CONTENTION : (phyState == A0 ? SUSPEND : GRANT)); break; case RX_PARENT_HANDSHAKE | RX_DATA_END : portCurrent.arb = (phyState < S0 ? PARENT_HANDSHAKE : DATA_END); break; case RX_CHILD_HANDSHAKE | RX_DISABLE_NOTIFY : portCurrent.arb = (phyState < A0 ? CHILD_HANDSHAKE : DISABLE_NOTIFY); break; case RX_DATA_PREFIX : portCurrent.arb = (phyState < S0 ? portCurrent.arb : DATA_PREFIX); break; case RX_BUS_RESET : portCurrent.arb = BUS_RESET; break; } } switch (portCurrent.tag) { case LEGACY_ARB: if (portCurrent.arb == LEGACY_REQUEST) { // from a junior port if (!ignorePort[i] && (bBus || ((portCurrent.data == legacyRequestPhase) && !DS_stuck)))
Copyright © 2008 IEEE. All rights reserved.
659
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-20—Background request processing (continued) portRArb[i] = LEGACY_REQUEST; // pass in-phase legacy requests to arb state machine else ; // ignore out-of-phase requests } else { // LEGACY_PHASE legacyRequestPhase = portCurrent.data; // update phase legacyPhaseExpected = FALSE; if (inPacket[i]) // must have missed the preceding DATA_END, advanceOk[i] = TRUE; // so allow the FIFO to proceed to the next token } break; case ARB_REQUEST: receiveReq[i] = portCurrent.req; portRArb[i] = IDLE; // ARB_STATE is IDLE when ARB REQUESTS are received if (inPacket[i]) { // sudden end of packet nextArb[i] = TRUE; packetEnding[i] = TRUE; } break; case ARB_STATE: if (portCurrent.arb == SPEED) { if (!betaMode[i] && !(phyState == S4 || // filter out speeds received at phyState == S2 || phyState == S3 || // inappropriate times on DS ports phyState == A0 || phyState == A1 || phyState == A2 || phyState == RX )) break; // from dealing with current FIFO item portRSpeed[i] = portCurrent.speed; if (!betaMode[i] && (phyState == S2 || phyState == S3 || phyState == S4)) { break; // DS mode speed exchanges - don’t treat as start of packet } currentPkt[i] = portCurrent.pkt; }
switch (portCurrent.arb) { // deal with all the cases where the fifo is read // one item at a time for the arb state machine // and advance the fifo automatically for all the others case DATA_PREFIX: case DATA_NULL: case SPEED: case CYCLE_START_ODD: case CYCLE_START_EVEN: receiveReq[i].async = A_NONE; // forget the latest received arb state receiveReq[i].isoch = I_NONE; if (ignorePort[i]) { // dealing with a collision collision[i] = TRUE; break; } if (!inPacket[i]) inPacket[i] = TRUE; // throttle the FIFO else nextArb[i] = TRUE; // signal that this is the latest break; case GRANT: // may terminate a packet or occur in isolation case GRANT_ISOCH: // may terminate a packet or occur in isolation if (ignorePort[i]) { // dealing with a collision collision[i] = TRUE;
660
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-20—Background request processing (continued) break; } if (inPacket[i]) { nextArb[i] = TRUE; packetEnding[i] = TRUE; } break; case DATA_END: if (ignorePort[i]) { // dealing with a collision collision[i] = TRUE; packetEnding[i] = TRUE; break; } nextArb[i] = TRUE; packetEnding[i] = TRUE; break; case IDLE: // may also cause sudden packet termination case BUS_RESET: case ARB_CONTEXT: receiveReq[i].async = A_NONE; // forget the latest received arb state receiveReq[i].isoch = I_NONE; if (inPacket[i]) { nextArb[i] = TRUE; packetEnding[i] = TRUE; portRSpeed[i] = S100; // and erase memory of speed signal } if (portCurrent.arb == BUS_RESET) { // never ignore bus reset ignorePort[i] = FALSE; inPacket[i] = FALSE; packetEnding[i] = FALSE; collision[i] = FALSE; } break; case ASYNC_EVEN: case ASYNC_ODD: if (ignorePort[i]) { // dealing with a collision collision[i] = TRUE; break; } if (inPacket[i]) { nextArb[i] = TRUE; } break; default: break; // assert error - cannot occur } if (!ignorePort[i]) portRArb[i] = portCurrent.arb; // set the current arb state break; // finished dealing with ARB states case DATA: if (ignorePort[i]) { // dealing with a collision collision[i] = TRUE; break; } currentData[i] = portCurrent.data; portRArb[i] = DATA_BYTE; nextArb[i] = TRUE; portRSpeed[i] = S100; // and erase memory of speed signal
Copyright © 2008 IEEE. All rights reserved.
661
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-20—Background request processing (continued) break; default: break;
// assert error if CTRL, CONFIG_REQUEST, INVALID or
DS_RAW_ARB }
// are seen // end of dealing with the latest in the fifo
} } //combine best async and isoch request from other ports and own request if (active[i]){ bestReq.async = ownReq.async; // prefer link first bestReq.isoch = ownReq.isoch; apm = (byte)(oddAsyncPhase ? 0xf0 : 0x0f); // select async priority mask ipm = (byte)(oddIsochPhase ? 0xf0 : 0x0f); // select isoch priority mask bip = bap = NPORT; reqUnknownVect[i] = FALSE; for (j = 0; j < NPORT; j++) { // then prefer junior ports if (active[j] && betaMode[j] && (((receiveReq[j].async & apm) == A_NONE) // possibly redundant? || ((receiveReq[j].isoch & ipm) == I_NONE))) { // if at least one OTHER active port hasn’t received an updated request if (j != i) reqUnknownVect[i] = TRUE; } if (j != i && (j != seniorPort)) { // careful to avoid requests on a restoring port bestReq.async = active[j] && betaMode[j] && ((receiveReq[j].async & apm) > (bestReq.async & apm)) ? receiveReq[bap = j].async : bestReq.async; bestReq.isoch = active[j] && betaMode[j] && ((receiveReq[j].isoch & ipm) > (bestReq.isoch & ipm)) ? receiveReq[bip = j].isoch : bestReq.isoch; } } if (!proxyRoot && (i != seniorPort)) { // finally prefer senior port on other ports bestReq.async = active[seniorPort] && betaMode[seniorPort] && ((receiveReq[seniorPort].async & apm) > (bestReq.async & apm)) ? receiveReq[bap = seniorPort].async : bestReq.async; bestReq.isoch = active[seniorPort] && betaMode[seniorPort] && ((receiveReq[seniorPort].isoch & ipm) > (bestReq.isoch & ipm)) ? receiveReq[bip = seniorPort].isoch : bestReq.isoch; } if (suppressRequests) { arbReqT[i].async = oddAsyncPhase ? NONE_ODD : NONE_EVEN; arbReqT[i].isoch = ISOCH_NONE; } else if (reqUnknownVect[i] && isoCycle && (i != seniorPort)) { arbReqT[i].async = bestReq.async; //different for each port arbReqT[i].isoch = ISOCH_CURRENT; // to prevent termination of the iso cycle } else { arbReqT[i] = bestReq; // different for each port } if (seniorBorder && (i == seniorPort)) { // need to convert to legacy and pass any // request up to DS parent asyncPendingPort = bap; // meaningless unless asyncPending is TRUE isochPendingPort = bip; // meaningless unless isochPending is TRUE isochPending = ((isoCycle && ((bestReq.isoch & ipm) >= (ISOCH_IN_PHASE & ipm))) || (!isoCycle && ((bestReq.isoch & ipm) == (ISOCH_CURRENT & ipm))));
662
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-20—Background request processing (continued) asyncPending = (!isoCycle && ((bestReq.async & apm) >= (CURRENT & apm))); } } } if (!seniorBorder || bNodeRoot)
// if no longer a senior border in a junior cloud // clear pending flags used by arbPermitted isochPending = asyncPending = FALSE;
} boolean gapToken(int port) { // check for a new gap token on the specified port boolean foundNewToken = FALSE; if (portRArb[port] == ASYNC_ODD) { if (!oddAsyncPhase) { foundNewToken = TRUE; arbReset = TRUE; didArbrst = TRUE; // After repeating an arb reset token, disallow further phase // advancements in a B bus until non IDLE traffic occurs } else if (!filterAsyncOdd) { foundNewToken = TRUE; sendAsyncStartToken = TRUE; } oddAsyncPhase = TRUE; filterAsyncOdd = TRUE; filterAsyncEven = FALSE; } else if (portRArb[port] == ASYNC_EVEN) { if (oddAsyncPhase) { foundNewToken = TRUE; arbReset = TRUE; didArbrst = TRUE; // After repeating an arb reset token, disallow further phase // advancements in a B bus until non IDLE traffic occurs } else if (!filterAsyncEven) { foundNewToken = TRUE; sendAsyncStartToken = TRUE; } oddAsyncPhase = FALSE; filterAsyncOdd = FALSE; filterAsyncEven = TRUE; } else { filterAsyncOdd = FALSE; filterAsyncEven = FALSE; } return (foundNewToken); }
Copyright © 2008 IEEE. All rights reserved.
663
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
19.4.3 Bus reset Table 19-21 specifies the actions to be performed during a bus reset (see 16.4.5.)
Table 19-21—Bus reset actions // reset.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void arbPowerReset() { arbReset = FALSE; accelerating = TRUE; initiatedReset = TRUE; resetDuration = RESET_TIME; loopToDetect = FALSE; busInitializeActive = FALSE; restoreRequest = FALSE; immediatePhyRequest = immediateRestoreRequest = FALSE; timeOutOfIdle = 0; // misc registers in the PHY reg map gapCountResetDisable = ibr = isbr = loop = timeout = FALSE; fromA0 = FALSE; while (powerReset) ; PH_EVENT_indication(PH_LINK_ON, 0, 0); // only for power classes 0-4 // for a min of 166 usecs (16384 PClk cycles). // see Clause 14.4 for full requirements } boolean resetDetected() { // Qualify BUS_RESET with port status / history int i; if ( phyState == R0 || phyState == R1 // Ignore during (or just before) reset... || isbrOk || phyResponse) // ...or if busy with a PHY command return(FALSE); for (i = 0; i < NPORT; i++) if (disabled[i]) // Ignore completely if disabled continue; else if ((betaMode[i] || bias[i]) && (portRArb[i] == BUS_RESET)) if (active[i]) { resetDuration = (phyState == RX) ? SHORT_RESET_TIME : RESET_TIME; return(TRUE); } else if (resume[i] && okToDetectReset && !busInitializeActive) { resumptionDone = TRUE; resetDuration = (boundaryNode) ? RESET_TIME : SHORT_RESET_TIME; return(TRUE); } else if (attach[i] && ((NPORT==1) || ((i == testPort) && sendAttach))) { resetDuration = SHORT_RESET_TIME; // Found a reset returned in response to an ATTACH_REQUEST, // so attempt a short reset. Note well: this should only test true // on a single port phy or an isolated node as any other node retains // control of the bus while awaiting the return reset
664
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-21—Bus reset actions (continued) return(TRUE); } return(FALSE); } void resetStartActions() { int i; if (!busInitializeActive) { busInitializeActive = TRUE; if (gapCountResetDisable) gapCountResetDisable = FALSE; else gapCount = 0x3F; }
// Transmit BUS_RESET for resetDuration on all ports
// First reset since setting gapCount? // If so, leave it as is and arm it for next // Otherwise, set it to the maximum
PH_EVENT_indication(PH_BUS_RESET_START, 0, 0); // Optional upon reentry to R0 from R1 waitPH_EVENT_response(); // flush out all queued requests from the link and set even async and isoc phases cancelRequests(); oddIsochPhase = FALSE; oddAsyncPhase = FALSE; isoCycle = FALSE; tooLateForIsoch = FALSE; didArbrst = FALSE; arbReset = FALSE; sendAsyncStartToken = FALSE; // note that arbEnable is NOT reset (just like legacy standards) okToGrant = deferGrant = grantSelf = FALSE; bBus = TRUE; isochConcatOk = TRUE; root = FALSE; seniorBorder = FALSE;
// initially an isolated node! // for legacy camcorder problem
receivePort = NPORT+1; linkConcatenation = FALSE; sendNullPacket = FALSE; DS_stuck = FALSE;
// not receiving, not transmitting
ibr = isbr = isbrOk = FALSE; // Don’t replicate resets! phyResponse = pingResponse = FALSE; // Invalidate stale information arbTimer = 0; // not important, just good practice T0_timeout = FALSE; children = physical_ID = 0; SID_complete = FALSE; maxLegacyPathSpeed = (link == LEGACY_Link) ? S400: S100; if (!loopToDetect) { // loop timout detect, while its true, look for // config timeout, arbState timeout, more than 2 resets // or loss of sync on a port loopToDetect = TRUE; // set false once node gets to S1 or S2 resetCount = 0; // count the resets that never make it that far } else resetCount++; needNewLTP = TRUE; HR_G = 0; // value not important HR_mode = LTP_TEST; inControl = FALSE;
Copyright © 2008 IEEE. All rights reserved.
665
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-21—Bus reset actions (continued) legacyRequestPhase = 0; // reset phase for (i = 0; i < NPORT; i++) { // check for untested ports if (loopDisabled[i]) loopDisabled[i] = FALSE; child[i] = FALSE; child_ID_complete[i] = FALSE; if (!betaMode[i] && (active[i] || (resume[i] && resumptionDone))) portSpeed[i] = S100; // Reset default speed for all active or resuming DS ports } for (i = 0; i < NPORT; i++) { if (betaMode[i]) { resetNotify[i] = TRUE; // have to notify all stood-by ports that a reset has occurred } if (!betaMode[i] || (portRArb[i] != BUS_RESET) || (resetDuration == RESET_TIME)) { // don’t propagate back if receiving a short BUS_RESET portTArb(i, BUS_RESET); // propagate on active ports, if (!disabled[i] && ((resume[i] && resumptionDone) || attach[i])) { portT[i].arb = BUS_RESET; // Also propagate on resuming or attaching ports portT[i].speed = DEFAULT; portT[i].tag = ARB_STATE; } } else { // on a port receiving the short bus reset, propagate IDLE portTArb(i, IDLE); // propagate on active ports, if ((resume[i] && resumptionDone) || attach[i]) { portT[i].arb = IDLE; // Also propagate on resuming or attaching ports portT[i].speed = DEFAULT; portT[i].tag = ARB_STATE; } } } } void resetWaitActions() { int i; for (i = 0; i < NPORT; i++) { portTArb(i, IDLE); if ((resume[i] && resumptionDone) portT[i].arb = IDLE; portT[i].speed = DEFAULT; portT[i].tag = ARB_STATE; } } arbTimer = 0; } boolean resetComplete() {
666
// Transmit IDLE
|| attach[i]) { // Also propagate on resuming or attaching ports
// Restart timer
// TRUE when all ports idle or in tree identification state
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-21—Bus reset actions (continued) int i; for (i = 0; i < NPORT; i ++) { if (active[i]) { if (ignorePort[i] || ((portRArb[i] != IDLE) && (portRArb[i] != PARENT_NOTIFY))) return(FALSE); collision[i] = FALSE; // no longer any collision if no longer ignoring the port } } return(TRUE); // Transition to tree identify }
19.4.4 Tree identification Table 19-22 specifies the operation of the tree identify process (see 16.4.6.)
Table 19-22—Tree identify actions // treeid.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void tree_ID_startActions() { int i; if (isolatedNode) forceRoot = FALSE;
// No point in waiting to become root if isolated
rootContendCount = 0; do { children = 0; // Count the kids afresh on each loop for (i = 0; i < NPORT; i++) if (!active[i] || portRArb[i] == PARENT_NOTIFY) { child[i] = TRUE; // Child if disabled, disconnected or suspended children++; // or if other PHY asks us to be the parent } if (children == NPORT - 1 && (!forceRoot || arbTimer >= FORCE_ROOT_TIMEOUT)) return; // Only one port left as the parent else if (children == NPORT) return; // node is the root } while (!(resetDetected() || ibr || isbr|| (!T0_timeout && (arbTimer == CONFIG_TIMEOUT)))); } void childHandshakeActions() { int i; seniorPort = parentPort = NPORT+1; proxyRoot = root = TRUE; for (i = 0; i < NPORT; i++) if (active[i]) if (child[i]) portTArb(i, CHILD_NOTIFY); else { if (betaMode[i])
Copyright © 2008 IEEE. All rights reserved.
// No parent port (in case node becomes root) // Remains TRUE if all the ports are child ports // Only the connected, active ports participate // Tell peer PHY, “You are my child”
667
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-22—Tree identify actions (continued) portTArb(i, PARENT_NOTIFY); else portTArb(i, IDLE); // notify yet! seniorPort = parentPort = i; proxyRoot = root = FALSE; } }
// Ask peer PHY, “Please be my parent” For compatibility with legacy PHYs, don’t send parent// Only one parent port possible // Tentative---see root contention
boolean childHandshakeComplete() { // TRUE once all active children are in S0: Self ID Start int i; for (i = 0; i < NPORT; i++) if (active[i] && child[i] && !((portRArb[i] == CHILD_HANDSHAKE) || // DS ports (portRArb[i] == IDLE))) // Beta ports return(FALSE); for (i = 0; i < NPORT; i++) if (active[i] && !child[i]) portTArb(i, PARENT_NOTIFY); // Ask peer PHY, “Please be my parent” return(TRUE); // All child ports have finished their handshakes } void rootContendActions() { int i; rootContendCount = rootContendCount + 1; for (i = 0; i < NPORT; i++) if (child[i]) // Only the connected, active ports matter portTArb(i, CHILD_NOTIFY); // Continue to tell peer PHY, “You are my child” else { portTArb(i, IDLE); // Withdraw “Please be my parent” request contendTime = (randomBool() ? (longContendTimer[i] ? LONG_ROOT_CONTEND_SLOW : ROOT_CONTEND_SLOW) : (longContendTimer[i] ? LONG_ROOT_CONTEND_FAST : ROOT_CONTEND_FAST)); if (rootContendCount > 15) longContendTimer[i] = TRUE; // try with long contend times } arbTimer = 0; // Restart arbitration timer }
19.4.5 Self-identification Table 19-23 specifies the operation of the self-identify process (see 16.4.7.)
Table 19-23—Self-identify actions // selfid.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void self_ID_startActions() { int i; allChildPortsIdentified = TRUE; concatenatedPacket = FALSE; arbTimer = 0;
668
// Will be reset if any active children are unidentified // Prepare in case of multiple self_ID packets
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-23—Self-identify actions (continued) for (i = 0; i < NPORT; i++) portTArb(i, IDLE);
// Allow parent to finish
// ensure that MIN_IDLE_TIME is preserved waitLegacyTime(MIN_IDLE_TIME); for (i = 0; i < NPORT; i++) if (child_ID_complete[i]) // Tell identified children to prepare to receive data portTArb(i, DATA_NULL); else { if (child[i] && (active[i] || proxy[i])) { if (allChildPortsIdentified) lowestUnidentifiedChild = i; allChildPortsIdentified = FALSE; } } } void self_ID_grantActions() { int i; int SID_pktNumber; int portStat; int portNumber = 0; PHY_pkt self_ID; loopToDetect = FALSE; // no longer looking for loop timeout detect conditions, resetCount = 0; // so clear all loop indications T0_timeout = FALSE; for (i = 0; i < NPORT; i++) { if (!allChildPortsIdentified && (i == lowestUnidentifiedChild)) { if (!proxy[i]) portTArb(i, GRANT); // Send grant to lowest unidentified child (if any) } else portTArb(i, DATA_NULL); // Otherwise, tell others to prepare for packet } if (!allChildPortsIdentified && proxy[lowestUnidentifiedChild]) { receivePort = NPORT; // Indicate that node is transmitting (no port has this number) PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity for (SID_pktNumber = 0; SID_pktNumber < standbyPacketCount[lowestUnidentifiedChild]; SID_pktNumber++) { startTxPacket(S100, LEGACY, FALSE); // Send data prefix and S100 speed code (always legacy format) PH_DATA_indication(PH_DATA_START, S100, 0, LEGACY); self_ID.dataQuadlet = 0; // Clear all zero fields in self_ID packet self_ID.phyPacketType = 0x2; self_ID.phy_ID = physical_ID; standbyPhy_ID[lowestUnidentifiedChild] = physical_ID; // and remember the new PHY_ID if (SID_pktNumber == 0) { // First self ID packet? self_ID.L = standby_L[lowestUnidentifiedChild]; // Link active or not? self_ID.gapCnt = gapCount; self_ID.sp = 0x3; // “PHY_SPEED” always “11” (unlike legacy) self_ID.c = standby_c[lowestUnidentifiedChild]; self_ID.pwr = standby_pwr[lowestUnidentifiedChild]; } else {
Copyright © 2008 IEEE. All rights reserved.
669
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-23—Self-identify actions (continued) self_ID.ext = 1; // Indicates second and subsequent packets self_ID.n = SID_pktNumber - 1; // Sequence number } portStat = 0; // Initialize for fresh group of ports while (portNumber < ((SID_pktNumber + 1) * 8 - 5)) { // Concatenate port status if (portNumber >= standby_NPORT[lowestUnidentifiedChild]) ; // Unimplemented else if (standbyParent[lowestUnidentifiedChild] == portNumber) portStat |= 0x2; // Active parent else portStat |= 0x1; // Disabled, disconnected or suspended portNumber++; portStat <<= 2; // Make room for next port’s status } self_ID.dataQuadlet |= (quadlet)portStat; if (SID_pktNumber == standbyPacketCount[lowestUnidentifiedChild] - 1) { // Last packet? txQuadlet(self_ID.dataQuadlet); txQuadlet(~self_ID.dataQuadlet); // Yes, signal data end PH_DATA_indication(PH_DATA_END, 0, 0, 0); stopTxPacket(DATA_END, NPORT); } else { self_ID.m = 1; // Other packets follow, set ‘more’ bit txQuadlet(self_ID.dataQuadlet); txQuadlet(~self_ID.dataQuadlet); // Keep bus for concatenation PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); stopTxPacket(DATA_PREFIX, NPORT); } } child_ID_complete[lowestUnidentifiedChild] = TRUE; if (physical_ID < 63) // Stop at 63 if malconfigured bus physical_ID = physical_ID + 1; // Otherwise, take next PHY address idleReceivePort = TRUE; // to exit back to self_ID start } else { idleReceivePort = FALSE; } } void self_ID_receiveActions() { int i; int SID_pktNumber = 0; int portNumber = 0; int portStat; boolean goodSID_sequence = TRUE; arbTimer = 0; loopToDetect = FALSE; resetCount = 0; T0_timeout = FALSE; portTArb(receivePort, IDLE); do { receiveActions(); if (goodPhyPacket) { if (SID_pktNumber == 0) {
670
// until a bad phy packet is received // no longer looking for loop timeout detect conditions, // so clear all loop indications // Turn off grant, get ready to receive
// Receive (and repeat) packet // Only do this on the first self_ID packet
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-23—Self-identify actions (continued) // get the self ID info ready for restore from standby standbyPhy_ID[receivePort] = self_ID_pkt.phy_ID; standby_L[receivePort] = self_ID_pkt.L; standby_c[receivePort] = self_ID_pkt.c; standby_pwr[receivePort] = self_ID_pkt.pwr; } while (portNumber < ((SID_pktNumber +1)*8 -5)) { // find which port the peer is using as parent portStat = (int)((self_ID_pkt.dataQuadlet>>(((SID_pktNumber +1)*8 -5 -portNumber)*2)) & 0x3); if (portStat == 0x2) standbyParent[receivePort] = portNumber; // TRUE exactly once portNumber++; if (portStat != 0x0) standby_NPORT[receivePort] = portNumber; // eventually save the highest value } } else goodSID_sequence = FALSE; SID_pktNumber++; } while (concatenatedPacket); standbyPacketCount[receivePort] = SID_pktNumber; if (!goodSID_sequence) { // construct substitute self_ID information for uncle to remember standbyPhy_ID[receivePort] = 63; standbyParent[receivePort] = 0; standby_NPORT[receivePort] = 1; standbyPacketCount[receivePort] = 1; } if (physical_ID < 63) physical_ID = physical_ID + 1; for (i = 0; i < NPORT; i++) portTArb(i, IDLE);
// Stop at 63 if malconfigured bus // Otherwise, take next PHY address // Turn off all transmitters
} void self_ID_transmitActions() { int i; int lastSID_packet = (NPORT + 4) / 8; int SID_pktNumber; // Packet number counter int portNumber = 0; // Port number counter PHY_pkt self_ID; int portStat; arbTimer = 0; receivePort = NPORT; // Indicate that node is transmitting (no port has this number) PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } if (!pingResponse) { // set bNodeRoot and max legacy path speed (done here to be symmetric with // self_ID processing which is done in decode_pky_pkt) if (link == LEGACY_Link) { bNodeRoot = FALSE; bBus = FALSE; isochConcatOk = FALSE; // For legacy camcorder interoperability problem proxyRoot = TRUE; // Assume this node to be seniorBorder and
Copyright © 2008 IEEE. All rights reserved.
671
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-23—Self-identify actions (continued) seniorBorder = TRUE; seniorPort = NPORT+1; } else bNodeRoot = TRUE;
// proxyRoot, may change later
// Inform link of new node number as early as possible PH_EVENT_indication(PH_SELF_IDENTITY, physical_ID, root); // Unsolicited Register 0 } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity for (SID_pktNumber = 0; SID_pktNumber <= lastSID_packet; SID_pktNumber++) { startTxPacket(S100, LEGACY, FALSE); // Send data prefix and 98.304 Mbit/sec speed code // always legacy format, no speed code if legacy link PH_DATA_indication(PH_DATA_START, S100, 0, LEGACY); self_ID.dataQuadlet = 0; // Clear all zero fields in self_ID packet self_ID.phyPacketType = 0x2; self_ID.phy_ID = physical_ID; if (SID_pktNumber == 0) { // First self ID packet? self_ID.L = LPS_pin && lctrl; // Link active or not? self_ID.gapCnt = gapCount; self_ID.sp = 0x3; // “PHY_SPEED” always “11” (unlike legacy) self_ID.brdg = bridge; // field from PHY register map self_ID.c = contender; // field from PHY register map self_ID.pwr = POWER_CLASS; self_ID.i = initiatedReset; } else { self_ID.ext = 1; // Indicates second and subsequent packets self_ID.n = SID_pktNumber - 1; // Sequence number } portStat = 0; // Initialize for fresh group of ports while (portNumber < ((SID_pktNumber + 1) * 8 - 5)) { // Concatenate port status if (portNumber >= NPORT) ; // Unimplemented else if (!active[portNumber] && !proxy[portNumber]) portStat |= 0x1; // Disabled, disconnected or suspended else if (child[portNumber]) portStat |= 0x3; // Active child else portStat |= 0x2; // Active parent portNumber++; portStat <<= 2; // Make room for next port’s status } self_ID.dataQuadlet |= (quadlet)portStat; if (SID_pktNumber == lastSID_packet) { // Last packet? txQuadlet(self_ID.dataQuadlet); txQuadlet(~self_ID.dataQuadlet); // Yes, signal data end PH_DATA_indication(PH_DATA_END, 0, 0, 0); stopTxPacket(DATA_END, NPORT); } else { self_ID.m = 1; // Other packets follow, set ‘more’ bit txQuadlet(self_ID.dataQuadlet); txQuadlet(~self_ID.dataQuadlet); // Keep bus for concatenation PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); stopTxPacket(DATA_PREFIX, NPORT); } }
672
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-23—Self-identify actions (continued) if (!pingResponse) { // Skip if self_ID packet was in response to a ping SID_complete = TRUE; for (i = 0; i < NPORT; i++) { if (root || i != parentPort) portTArb(i, IDLE); // Turn off transmitters to children else // Notify parent that self_ID is complete and exhange speed portTArbAtSpeed(i, IDENT_DONE, dsPortSpeed[i]); } if (!root) { // If node has a parent... // Continue sending speed signal (if any) waitLegacyTime(SPEED_SIGNAL_LENGTH); // Stop sending speed signal portTArbAtSpeed(parentPort, IDENT_DONE, S100); } if (root && bBus) { sendAsyncStartToken = TRUE; // to get everyone in phase gapRepeatActions(NPORT); sendingTokens = TRUE; okToGrant = TRUE; deferGrant = FALSE; } else sendingTokens = FALSE; } }
19.5 Border arbitration Idle actions may need to find a favorite request from among the requests processed in the background. Idle actions (see Table 19-24) also deal with advancing the phase.
Table 19-24—Idle actions // idle_actions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void idleActions() { int i; boolean grantOnlyAtAsyncStart = FALSE; boolean exitIdle = FALSE; boolean checkArbrst = FALSE; // TRUE after timeout to recover from lost arb reset token boolean unstick; // TRUE to unstick after missing ACK boolean reachedSubaction; boolean reachedArbReset; int bip; // best isochronous request port number int bap; // best asynchronous request port number int bestPort; // over all best request port number byte apm; // mask to select the in-phase async requests byte ipm; // mask to select the in-phase isoch requests boolean inPhaseIsochRequest, inPhaseAsyncRequest; boolean iAdvanceInterval, aAdvanceInterval; betaRequestCode bestReq; arbState receivedGrant; boolean repeatGap = FALSE;
Copyright © 2008 IEEE. All rights reserved.
673
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-24—Idle actions (continued) arbOk = FALSE; legacyJuniorRequest = FALSE; betaPortRequest = FALSE; unstick = FALSE; filterAsyncOdd = FALSE; filterAsyncEven = FALSE; currentSpeed = S100; currentFormat = LEGACY; accidentally
// reset gap token filters on entry into IDLE
// Default in anticipation of no explicit receive speed code // and to ensure S100 “downshift” tests in TX don’t // trigger on the first packet out of Idle
arbTimer = 0; arbTimerMax = FALSE; fork { // The duration of A0:Idle is divided into two periods // (a) during the isochronous interval or before the conclusion of a subaction // in the asynchronous interval, in which DATA_NULL continues on any port for a symbol time, // and otherwise all ports transmit requests; // (b) after the conclusion of a subaction in the asynchronous interval. // During this period, asynchronous phase tokens are issued or repeated continuously. // (sendingTokens is TRUE during this period) // In a bBus, this second period begins at the proxyRoot when okToGrant is set and not // isoCycle, and starts at a non-proxy root when it receives tokens from its senior. // // In a hybrid bus, this period begins at a seniorBorder (including the proxyRoot) when a // subaction gap is timed, and starts at every other node when it receives tokens from its senior. do { for (i = 0; i
674
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-24—Idle actions (continued) if (gapToken(seniorPort)) { repeatGap = TRUE; // initiate concurrent gap repeat, for the sake of the // timing test on arbPermitted() below sendingTokens = TRUE; } } } // proxyRoot or seniorBorder generated token if (!repeatGap && (sendAsyncStartToken || arbReset)) { if (isoCycle && !bBus) okToGrant = FALSE; // as we’re now entering the async interval gapRepeatActions(NPORT); // send continuously once a token is sent; any gap token // always indicates end-of-subaction sendingTokens = TRUE; } if (proxyRoot) { // introduce explicit grant if okToGrant, else no grant if (okToGrant && isoCycle) receivedGrant = GRANT_ISOCH; else if (okToGrant && !isoCycle) receivedGrant = GRANT; else receivedGrant = IDLE; } else { // !proxyRoot if (portRArb[seniorPort] == GRANT) receivedGrant = GRANT; else if (portRArb[seniorPort] == GRANT_ISOCH) receivedGrant = GRANT_ISOCH; else receivedGrant = IDLE; // no grant } // Find favorite BOSS requests bap = bip = NPORT; bestPort = NPORT+1; // NPORT means the link, // NPORT+1 means no suitable request bestReq = bestRequest(&apm, &ipm, &bap, &bip, // find best request &inPhaseIsochRequest, &inPhaseAsyncRequest, &iAdvanceInterval, &aAdvanceInterval); if ((receivedGrant == GRANT_ISOCH) && inPhaseIsochRequest) bestPort = bip; else if ((receivedGrant == GRANT) && inPhaseAsyncRequest) bestPort = bap; else if (proxyRoot && (bestReq.isoch == ISOCH_CURRENT)) { // Deal with corner case of late-arriving ISOCH_CURRENT request // (proxyRoot always willing to grant ISOCH_CURRENT regardless of okToGrant) bestPort = bip; receivedGrant = GRANT_ISOCH; // upgrade to an explicit isoch grant } // Determine next action to take based on prioritized requests and timing considerations // In general, unarbitrated requests/responses are serviced first, followed by requests // for the local link and ending with requests from a junior port. Within each priority // level, legacy requests are preferred over BOSS requests. if (!bBus && !DS_stuck && !arbTimerMax && (arbTimer < legacyTime(MIN_IDLE_TIME))) { ; // Take no action until legacy MIN_IDLE_TIME is met } else if (powerReset || resetDetected() || ibr || immediateRequest || pingResponse || phyResponse) { // Immediate and unconditional exits from A0:Idle grantToGive = DATA_END; // Marks entry into TX as unarbitrated exitIdle = TRUE; } else if (dataComing()) {
Copyright © 2008 IEEE. All rights reserved.
675
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-24—Idle actions (continued) exitIdle = TRUE; } else if ((receivedGrant == GRANT) && (bestReq.async == CYCLE_START_REQ) && (bestPort != seniorPort)) { // Grant CYCLE_START if in async phase, but take care not to grant back to senior // (GRANT always comes from senior port except at proxyRoot) // May want to grant a parent (but junior) between root and proxyRoot requestingPort = bestPort; if (bestPort == NPORT) { grantSelf = TRUE; } else { betaPortRequest = TRUE; // schedule the grant } grantToGive = GRANT; exitIdle = TRUE; } else if (!root && (portRArb[parentPort] == LEGACY_REQUEST)) { // legacy request from parent requestingPort = parentPort; // only applies to nodes between proxyRoot and parent grantToGive = GRANT; legacyJuniorRequest = TRUE; exitIdle = TRUE; } else if ((resolveCollisionRequest || (root && ((breq == PRIORITY_REQ) || (breq == FAIR_REQ)))) && arbPermitted()) { // legacy link request, might be for cycle start // note, call of arbPermitted() conditional on short-circuit // evaluation not processing ISOCH_REQ at this point // is optional arbOk = TRUE; exitIdle = TRUE; } else if (unstick) { // only at a senior border to clean up missing Beta ACK // DS ports stuck somewhere (not necessarily on this node) sendNullPacket = TRUE; grantSelf = TRUE; // schedule TX of a null packet unstick = FALSE; exitIdle = TRUE; } else if ((receivedGrant != IDLE) && (bestPort == NPORT)) { // best is the local link grantToGive = receivedGrant; grantSelf = TRUE; exitIdle = TRUE; } else if ((receivedGrant != IDLE) && (bestPort < NPORT) && (bestPort != seniorPort)) { // grant the best port provided it is not the senior port // this may optionally be performed after legacyJuniorRequesting below requestingPort = bestPort; grantToGive = receivedGrant; betaPortRequest = TRUE; // schedule the grant exitIdle = TRUE; } else if (arbPermitted()) { // legacy link request and converted Beta request processing // for other than PRI requests, if not performed above arbOk = TRUE; exitIdle = TRUE; } else if (legacyJuniorRequesting()) { legacyJuniorRequest = TRUE; if (!proxyRoot) { // always forward a legacy request in preference to any Beta request // but possibly prepare to steal an incoming grant to a legacy request // to grant a CSR
676
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-24—Idle actions (continued) if (!isoCycle && (bestReq.async == CYCLE_START_REQ) && !(bap == seniorPort)) { // prime A1 so that the grant goes to the thief requestingPort = bap; if (requestingPort == NPORT) { // legacy junior requesting, preparing to steal to give to Beta link cycle start request ownRequest = TRUE; } else { ; // legacy junior requesting, preparing to steal to give to Beta port // cycle start request } } else { ; // legacy junior requesting } } exitIdle = TRUE; } else if ((receivedGrant != IDLE) && !proxyRoot) { // Explicit grant from senior going unused sendNullPacket = TRUE; grantSelf = TRUE; // schedule TX of a null packet exitIdle = TRUE; } else if ((receivedGrant != IDLE) || checkArbrst) { // here if a) a proxy root with okToGrant and no in phase requests pending or // b) proxy root or a senior border with checkArbrst set to perform error detection and recovery if (bBus || checkArbrst) { // schedule tokens as necessary // end of isoch interval? if (isoCycle && iAdvanceInterval && (receivedGrant == GRANT_ISOCH) && (checkArbrst || (arbTimer >= (STORES_GAP_COUNT ? subactionGap: BOSS_RESTART_TIME)))) { sendAsyncStartToken = TRUE; } // send arb reset if in the async interval AND any of the following are TRUE: // (1) Normal end of fairness interval: At the end of a subaction, no asynchronous // requests remain for the current fairness interval on a bBus and an arb reset // token has not yet been sent. Advance the phase and introduce a new token. // Same condition as at the end of testRequests(). // (2) Error recovery: An idle timeout has occured, all asynchronous requests // agree on the current interval’s phase, and the highest priority // request is non-null and for the next fairness interval. Advance the // phase and introduce a new token to recover. if (((bBus && // Case (1) !isoCycle && aAdvanceInterval && !didArbrst && (receivedGrant == GRANT)) || (checkArbrst && // Case (2) aAdvanceInterval && ((bestReq.async & apm) == (oddAsyncPhase ? NEXT_EVEN & apm : NEXT_ODD & apm)))) && (checkArbrst || sendingTokens || (arbTimer >= (STORES_GAP_COUNT ? subactionGap: BOSS_RESTART_TIME)))) { if (aAdvanceInterval) oddAsyncPhase = !oddAsyncPhase; arbReset = TRUE; didArbrst = TRUE; // After repeating an arb reset token, disallow further phase
Copyright © 2008 IEEE. All rights reserved.
677
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-24—Idle actions (continued) // advancements in a B bus until non IDLE traffic occurs } checkArbrst = FALSE; } else { // proxy root at hybrid bus if (grantOnlyAtAsyncStart) okToGrant = FALSE; // only one chance } // end of hybrid bus actions } } while (!exitIdle); } {
// Boss proxyRoot timer etc reachedSubaction = FALSE; // Reset flags used for timing edge triggers reachedArbReset = FALSE; do { // bBus case // introduces gap tokens at proxyRoot when bBus enters idle after end-of-subaction in // asynch interval once a suitable idle period has expired if (bBus && proxyRoot && !isoCycle && okToGrant && !sendingTokens && (arbTimer == (STORES_GAP_COUNT ? subactionGap: BOSS_RESTART_TIME))) { sendAsyncStartToken = TRUE; } if (bBus && !okToGrant) { // deal with possible missing end of subaction if (proxyRoot && (arbTimer == (USE_LONG_BOSS_RESTART_TIME ? LONG_BOSS_RESTART_TIME : (STORES_GAP_COUNT ? subactionGap: BOSS_RESTART_TIME)))) { sendAsyncStartToken = TRUE; okToGrant = TRUE; deferGrant = FALSE; arbTimerMax = TRUE; // effectively marks arbTimer as saturated arbTimer = 0; // reset timer for next timeout // also only allows block to execute once per instant in time }
// hybrid bus case } else if (!bBus && !arbTimerMax) {
// normal gap initiation in hybrid bus
if (seniorBorder && !reachedSubaction && (arbTimer == subactionGap) && DS_stuck) { // ACK missing when the packet was beta format sendAsyncStartToken = TRUE; // send indication on Beta ports unstick = TRUE; reachedSubaction = TRUE; // only allow block to execute once per instant in time } if ((seniorBorder || (link == LEGACY_Link)) && !DS_stuck) { // At a legacy cycle master, check if grant has been defered and reintroduce if // sufficient idle time has been met for the Link to request the bus // and for arbPermitted to return TRUE if (root && (link == LEGACY_Link) && deferGrant && ack && ((breq != NO_REQ) || (arbTimer == CM_MIN_IDLE_TIME))) { okToGrant = TRUE; deferGrant = FALSE; // also only allows block to execute once per instant in time } // on legacy links, the arb timer will expire before we receive a corresponding token // but use the receipt of token (unless senior border) to advance the phase etc if (!reachedSubaction && (arbTimer == subactionGap)) { if (link == LEGACY_Link) { PH_DATA_indication(PH_SUBACTION_GAP, 0, 0, 0);
678
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-24—Idle actions (continued) if (breq == ISOCH_REQ) breq = NO_REQ;
// Cancel late arriving isochronous
request that // may have been in-flight during PH_SUBACTION_GAP if (busInitializeActive) { // End of self_ID process for whole bus? PH_EVENT_indication(PH_BUS_RESET_COMPLETE, 0, 0); busInitializeActive = FALSE; } } if (seniorBorder) { sendAsyncStartToken = TRUE; // send indication on Beta ports and maybe end iso cycle } reachedSubaction = TRUE; // only allow block to execute once per instant in time } if (!reachedArbReset && (arbTimer == arbResetGap)) { // End of fairness interval? if (link == LEGACY_Link) PH_DATA_indication(PH_ARBITRATION_RESET_GAP, 0, 0, 0); // Alert link if (seniorBorder) { // send indication on Beta ports and advance interval phase oddAsyncPhase = !oddAsyncPhase; arbReset = TRUE; } reachedArbReset = TRUE; // only allow block to execute once per instant in time } // next three groups only have effect at proxy root if (arbTimer >= subactionGap) { // Small window for stealing a child’s request if (legacyJuniorRequestPresent()) { okToGrant = TRUE; deferGrant = FALSE; } } if (!grantOnlyAtAsyncStart && arbTimer == subactionGap + arbDelay) { okToGrant = TRUE; // Window for first fair request and priority requests deferGrant = FALSE; grantOnlyAtAsyncStart = TRUE; // also only allows block to execute once per instant in time } if (arbTimer >= arbResetGap + arbDelay) { okToGrant = TRUE; // Window for all requests (new fairness interval) deferGrant = FALSE; grantOnlyAtAsyncStart = FALSE; arbTimerMax = TRUE; // effectively marks arbTimer as saturated arbTimer = 0; // reset timer for next timeout // also only allows block to execute once per instant in time } } // // // // // // //
end hybrid case !(bBus && !okToGrant) && !(!bBus && !arbTimerMax) (!bBus || okToGrant) && (bBus || arbTimerMax) ((!bBus || okToGrant) && bBus) || ((!bBus || okToGrant) && arbTimerMax) bBus && okToGrant || ((!bBus || okToGrant) && arbTimerMax) bBus && okToGrant || ((!bBus && arbTimerMax) || (okToGrant) && arbTimerMax bBus && okToGrant || (!bBus && arbTimerMax)
} else // normal ack missing and gap indications have been processed, now perform token recovery if ((proxyRoot || seniorBorder) &&
Copyright © 2008 IEEE. All rights reserved.
679
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-24—Idle actions (continued) (arbTimer == (USE_LONG_BOSS_RESTART_TIME ? LONG_BOSS_RESTART_TIME : (STORES_GAP_COUNT ? subactionGap: BOSS_RESTART_TIME)))) { checkArbrst = TRUE; // recover from lost or corrupt arb reset token if necessary arbTimerMax = TRUE; // effectively marks arbTimer as saturated arbTimer = 0; // reset timer for next timeout // also only allows block to execute once per instant in time } } while (!exitIdle); } { while (!exitIdle){ if (repeatGap) { gapRepeatActions(seniorPort); repeatGap = FALSE; } } } join okToGrant = FALSE; deferGrant = FALSE; didArbrst = FALSE; sendAsyncStartToken = FALSE; sendingTokens = FALSE; arbReset = FALSE; timeOutOfIdle = 0;
// only relevant to a bBus
// start timer
}
Grant actions are specified in Table 19-25.
Table 19-25—Grant actions // grant_actions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void grantActions() { int i; if (!DS_stuck) { maxBetaTimer = 0; nodes DS_stuck = TRUE; } for (i = 0; i < NPORT; i++) { if (i != requestingPort) {
// called to send a grant to the requesting junior
// timer
only needs to be implemented in border capable
// and note that this will have to be released by sending // a legacy format packet
// send DATA_PREFIX/DATA_NULL to all non_requesting ports // including the seniorPort // sendNullPacket cleans up the case of starting a packet // for a request which is subsequently canceled
portTArb(i,DATA_NULL); } } while (fromA0 && (arbTimer < 30)) {
680
// suppress for 30 ns from entry to A0
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-25—Grant actions (continued) suppressRequests = TRUE; } portTArb(requestingPort, grantToGive); // Send grant to requesting junior suppressRequests = FALSE; if (betaMode[requestingPort]) { for (i = 0; i < 14; i++) waitSymbolTime(S800); portTArb(requestingPort, IDLE); } fromA0 = FALSE; }
Transmit actions are covered in Table 19-26.
Table 19-26—Transmit actions // transmit_actions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void transmitActions() { int byteCount = 0, i; phyDataReqService dataToTransmit; PHY_pkt txPhyPkt; arbState grantType; pktType link_format = UNSPECIFIED; without being set pktType nextFormat; speedCode nextSpeed; boolean phyOriginatedPkt; serviced boolean grantConMgmnt; phyArbConfirmations linkGrant;
// Send a packet as link transfers it to the PHY
// holds link-requested format, assert error if used // actual format, and speed of packet PHY // is preparing to transmit // TRUE if PHY rather than link transmission will be // TRUE to service restoreRequest or loopTestRequest // Specific grant confirmation to deliver to a B_LINK
ack = endOfPacket = grantSelf = didArbrst = FALSE; requestingPort = NPORT; receivePort = NPORT; // Impossible port number == > PHY transmitting for (i = 0; i < NPORT; i++) collision[i] = FALSE; // may be set true again immediately if collision // condition persists // Determine which request(s) either caused entry to TX or are permissible to grant based on // current bus interval and phase. After a preferred request is selected, memorize the requested // formats and speed. Since some link requests can be canceled and some internal PHY requests // can be asynchronously withdrawn, it is possible that no requests will test true at this instant. // In such a case, a null packet shall be transmitted to terminate cleanly. // Set default transmission to optimized PHY initiated null packet if (bBus) { nextFormat = BETA; nextSpeed = PHY_SPEED; } else {
Copyright © 2008 IEEE. All rights reserved.
681
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-26—Transmit actions (continued) nextFormat = LEGACY; nextSpeed = S100; } linkGrant = PH_LOST; grantConMgmnt = FALSE; phyOriginatedPkt = TRUE; // Consider requests that do not require arbitration if (isbrOk) { ; } else if ((link == LEGACY_Link) && linkConcatenation) { nextFormat = LEGACY; nextSpeed = reqSpeed; phyOriginatedPkt = FALSE; } else if (immediatePhyRequest) { // here for nephew to send STANDBY on active port ; } else if (immediateRestoreRequest) { // here for nephew to await restore packet from uncle grantConMgmnt = TRUE; } else if (immediateLinkRequest) { if (link == LEGACY_Link) { nextFormat = LEGACY; nextSpeed = reqSpeed; } else { link_format = immLinkFormat; nextFormat = immFormat; nextSpeed = immSpeed; linkGrant = PH_WON_IMMED; } phyOriginatedPkt = FALSE; } else if (resolveCollisionRequest) { ; } else if (sendNullPacket) { ; } else if (grantToGive == GRANT_ISOCH) { // PHY has won arbitration in the isochronous interval, consider isochronous requests if ((link == LEGACY_Link) && (breq == ISOCH_REQ)) { nextFormat = LEGACY; nextSpeed = reqSpeed; phyOriginatedPkt = FALSE; } else if ((link == B_LINK) && ((oddIsochPhase && isochOddRequest) || (!oddIsochPhase && isochEvenRequest))) { link_format = iLinkFormat; nextFormat = iFormat; nextSpeed = iSpeed; linkGrant = PH_WON_ISOCH; phyOriginatedPkt = FALSE; } else { // No suitable isochronous requests pending, clean up with a null packet. ; } } else if (grantToGive == GRANT) { // PHY has won arbitration in the asynchronous interval, consider asynchronous requests // Note that cycle start requests are preferred over arbitrated short bus resets if ((link == B_LINK) && cycleStartRequest && root) { link_format = cycStartLinkFormat; nextFormat = cycStartFormat;
682
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-26—Transmit actions (continued) nextSpeed = cycStartSpeed; linkGrant = PH_WON_CYCLE_START; phyOriginatedPkt = FALSE; } else if (isbr) { isbrOk = TRUE; } else if (restoreRequest || loopTestRequest) { grantConMgmnt = TRUE; } else if ((link == LEGACY_Link) && ((breq == PRIORITY_REQ) || (breq == FAIR_REQ && arbEnable))) { nextFormat = LEGACY; nextSpeed = reqSpeed; phyOriginatedPkt = FALSE; } else if ((link == B_LINK) && (currentRequest || (oddAsyncPhase && nextOddRequest) || (!oddAsyncPhase && nextEvenRequest))) { link_format = aLinkFormat; nextFormat = aFormat; nextSpeed = aSpeed; linkGrant = PH_WON_ASYNC; phyOriginatedPkt = FALSE; } else { // No suitable asynchronous requests pending, clean up with a null packet. ; } } else { // Reason for entering TX:Transmit state is no longer true, possibly // due to a canceled immediate request. Clean up with a null packet. ; } // // // if
normally PHY can go ahead and grant the preferred request at this stage however, need to take care to prevent the possibility of concatenating a legacy S100 packet onto a legacy >S100 packet (!bBus && (currentFormat == LEGACY) && (currentSpeed != S100) && (nextFormat == BETA || nextSpeed == S100)) { // just finishing a non-S100 legacy packet and the next packet to transmit could // ultimately appear as an S100 legacy packet. Send a null packet (or bus reset) // instead nextFormat = LEGACY; nextSpeed = S100; grantConMgmnt = FALSE; phyOriginatedPkt = TRUE; linkGrant = PH_LOST;
} immediatePhyRequest = FALSE; resolveCollisionRequest = FALSE; sendNullPacket = FALSE; if (grantConMgmnt) { // selected packet requires connection management service conMgmntGranted(); endOfPacket = TRUE; } else { // Begin packet transmission by informing the link as required and by preparing // the serial bus with the selected packet prefix if (phyOriginatedPkt) { PH_ARB_confirmation(PH_LOST, 0, if ((breq == FAIR_REQ) || (breq breq = NO_REQ;
Copyright © 2008 IEEE. All rights reserved.
// PHY originated packet, prepare to repeat to link 0); // Inform link of upcoming cancellation period == PRIORITY_REQ)) { // Cancel any asynchronous request
683
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-26—Transmit actions (continued) } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity } startTxPacket(nextSpeed, nextFormat, linkGrant == PH_WON_CYCLE_START); // Send data prefix and // speed signal if (isbrOk) { ; // note, endOfPacket not set to ensure mutual exclusion on exit } else if (phyOriginatedPkt) { // Empty packet, usually requested by boss in order to clean up DATA_PREFIX on // DS ports after sending a series of Beta format packets PH_DATA_indication(PH_DATA_END, 0, 0, 0); bossEndPacketActions(FALSE, DATA_END); // check for isoch to do endOfPacket = TRUE; } else { // It is time to pass grant to the link. In the event that the granted link request is no // longer pending, it is the responsibility of the PHY/link Interface block described in // 13.2.4 to respond to the grant with a null packet transmission sequence. if (link == LEGACY_Link) { PH_ARB_confirmation(PH_WON, 0, 0); // Signal grant if (breq == FAIR_REQ) // Exhausted one fair request per fairness interval? arbEnable = FALSE; // Yes, clear permission (set again on next reset gap) breq = NO_REQ; immediateLinkRequest = FALSE; linkConcatenation = FALSE; } else { // not a LEGACY_Link PH_ARB_confirmation(linkGrant, currentSpeed, link_format); // assert error if link_format not set switch (linkGrant) { case PH_WON_IMMED: immediateLinkRequest = FALSE; break; case PH_WON_ISOCH: isochOddRequest = isochEvenRequest = FALSE; break; case PH_WON_CYCLE_START: cycleStartRequest = FALSE; break; case PH_WON_ASYNC: currentRequest = nextOddRequest = nextEvenRequest = FALSE; break; default: break; // assert error - cannot occur } } while (!endOfPacket) { do { // Wait for data or release from the link PH_CLOCK_indication(); dataToTransmit = waitPH_DATA_request(); } while (dataToTransmit.reqType == PH_REQ_HOLD); // Hold only valid before data starts if (dataToTransmit.reqType == PH_REQ_DATA) { txByte(dataToTransmit.data); // Send DATA on all ports if (byteCount < 8) // Accumulate possible PHY packet txPhyPkt.dataBytes[byteCount] = dataToTransmit.data; byteCount++; ack = (byteCount == 1); // For acceleration, any 8-bit packet is an ack } else if (dataToTransmit.reqType == PH_REQ_DATA_PREFIX) { // concatenated packets from legacy link endOfPacket = linkConcatenation = TRUE; // End of packet indicator grantSelf = TRUE; // Force TX:TX transition stopTxPacket(DATA_NULL, NPORT); // MIN_PACKET_SEPARATION
684
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 19-26—Transmit actions (continued) reqSpeed = dataToTransmit.speed; } else { if (isoCycle) // Implicit or explicit subaction end grantType = isochConcatOk ? GRANT_ISOCH : DATA_END; // Force to DE for legacy camcorder else if (ack || (dataToTransmit.reqType == PH_REQ_SUBACTION_END)) // ACK packet can always be grantType = GRANT; // converted to an explicit asynchronous grant else grantType = DATA_END; // quiet grant bossEndPacketActions(FALSE, grantType); endOfPacket = TRUE; // End of packet indicator } } } } if (!phyOriginatedPkt && (byteCount == 8) && (txPhyPkt.dataQuadlet == ~txPhyPkt.checkQuadlet)) // Check PHY packet for good format decodePhyPacket(txPhyPkt); // Parse valid phy packets transmitted by the link if (!grantSelf) currentSpeed = S100; // for the case of transit to A2 and thence to RX }
Receive actions are covered in Table 19-27.
Table 19-27—Receive actions // receive_actions.c #include #include #include #include #include
“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”
void receiveActions() { int byteCount = 0, i; PHY_pkt rxPhyPkt; boolean endOfData = FALSE; arbState rxArbState; ack = concatenatedPacket = isbrOk = flyByOk = FALSE; requestingPort = NPORT; for (i = 0; i < NPORT; i++) collision[i] = FALSE;
// may be set true again immediately if collision // condition persists
resolveCollisionRequest = FALSE; if (!enabAccel) { PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } } PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Send notification of bus activity
Copyright © 2008 IEEE. All rights reserved.
685
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-27—Receive actions (continued) startRxPacket(&rxArbState);
// Start up receiver and repeater and repeat data prefix // requests on receivePort
if (rxArbState == DATA_BYTE) { if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Filter Beta formats from legacy link PH_DATA_indication(PH_DATA_START, currentSpeed, 0, currentFormat); // Send speed indication } do { if (rxArbState == DATA_BYTE) { //get data byte and repeat out other ports if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Filter Beta formats from legacy link PH_DATA_indication(PH_DATA_BYTE, 0, currentData[receivePort], 0); txByte(currentData[receivePort]); if (byteCount < 8) // Accumulate first 8 bytes rxPhyPkt.dataBytes[byteCount] = currentData[receivePort]; byteCount++; ack = (byteCount == 1); // For acceleration, any 8-bit packet is an ack if ((currentFormat == LEGACY) && (byteCount > 1)) { // Fly-by impossible so cancel requests, but only if link isn’t filtered and can // recognize cancellation // Let the link know (immediately) on 2nd byte (or 9th bit!) PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } } if (fifoRdPtr[receivePort] == fifoWrPtr[receivePort]) { // FIFO underrun // - just emptied the FIFO, and a new byte has not come in!! endOfData = TRUE; rxArbState = IDLE; // assume packetEnding[receivePort] = TRUE; // inform processRequests() that packet has concluded nextArb[receivePort] = FALSE; // and let the FIFO advance eagerly advanceOk[receivePort] = TRUE; } else rxArbState=portRNextArb(receivePort); } else endOfData = TRUE; } while (!endOfData); if ((currentFormat == LEGACY) && !ack) { // Fly-by impossible so cancel requests, but only if link isn’t filtered and can // recognize cancellation PH_ARB_confirmation(PH_LOST, 0, 0); // Inform link of upcoming cancellation period if ((breq == FAIR_REQ) || (breq == PRIORITY_REQ)) { breq = NO_REQ; // Cancel any asynchronous request } } // send packet ending, depends on the received packet ending switch (rxArbState) { case DATA_PREFIX: case DATA_NULL: concatenatedPacket = TRUE; if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Don’t send redundant indication if PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // legacy link is already in DATA_PREFIX stopTxPacket(rxArbState, NPORT); break;
686
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Table 19-27—Receive actions (continued) case GRANT: case GRANT_ISOCH: case DATA_END: if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Filter Beta formats from legacy link PH_DATA_indication(PH_DATA_END, 0, 0, 0); // Test for fly-by possibility for legacy link requests, remembering not to attempt fly-by // if the link is currently being filtered from reception of a BETA format packet flyByOk = (currentFormat == LEGACY) && flyByPermitted(); if (flyByOk) { grantToGive = (breq == ISOCH_REQ ? GRANT_ISOCH : GRANT); stopTxPacket(grantToGive, NPORT); } else { if (ack && (receivePort != seniorPort)) rxArbState = GRANT; // ACK packet from a junior port can always be // converted to an explicit asynchronous grant if ((rxArbState == GRANT) || (rxArbState == GRANT_ISOCH) || // explicit grants ((rxArbState == DATA_END) && (receivePort != seniorPort))) // implicit grant bossEndPacketActions(receivePort == seniorPort, rxArbState); else // not BOSS, repeat end of packet normally stopTxPacket(DATA_END, NPORT); } break; case BUS_RESET: PH_DATA_indication(PH_DATA_END, 0, 0, 0); stopTxPacket(BUS_RESET, NPORT); break; case IDLE: // DP directly to IDLE from a legacy PHY case ARB_CONTEXT: if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Filter Beta formats from legacy link PH_DATA_indication(PH_DATA_END, 0, 0, 0); // clean up for the link if (nonNullPacket) { // Unexpected end of data... stopTxPacket(DATA_END, NPORT); // and try to clean up gracefully } else if (formatCommitted) // Already in packet context? stopTxPacket(ARB_CONTEXT, NPORT); // If so, set arb context before heading to IDLE else stopTxPacket(IDLE, NPORT); ack = FALSE; // Disable fly-by acceleration break; default: // Unexpected end of data... if ((link != LEGACY_Link) || (currentFormat == LEGACY)) // Filter Beta formats from legacy link PH_DATA_indication(PH_DATA_END, 0, 0, 0); // clean up for the link nonNullPacket = FALSE; // With unexpected end of data, don’t add dribble bits stopTxPacket(DATA_END, NPORT); // and try to clean up gracefully ack = FALSE; // Disable fly-by acceleration break; } goodPhyPacket = FALSE; if (byteCount == 8) { if (rxPhyPkt.dataQuadlet == ~rxPhyPkt.checkQuadlet) { // Check PHY packet for good format decodePhyPacket(rxPhyPkt); // Parse valid phy packets goodPhyPacket = TRUE;
Copyright © 2008 IEEE. All rights reserved.
687
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 19-27—Receive actions (continued) } } else { HR_mode = LTP_TEST; // for all non-PHY packets } if (!(concatenatedPacket || // RX:RX or RX:TX transitions ((!concatenatedPacket) && (flyByOk || grantSelf) && (requestingPort == NPORT)))) { currentSpeed = S100; // remember current speed for // concatenated (legacy) packets } }
688
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
20. T-mode port specification This clause specifies the functions and operation of a port when operating in T-mode.
20.1 Overview The relationship and interfaces between the T-mode port functions and other functions and layers are illustrated in Figure 20-1: Link B PHY
request/grant, enable
port controller
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
Port
Connection management
DS-mode Beta- mode T-mode functions functions functions
Low-power signaling
Connection management
DS-mode Beta- mode T-mode functions functions functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
to other ports
UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
Figure 20-1—PHY master architecture (T-mode functions in context) When operating in T-mode, a port accepts data symbols and control and arbitration request signals from the arbitration state machine (and also from the port’s connection management machine as the port transitions to and from the On state), encodes the control or arbitration request symbols, adapts the resulting symbol sequence to a sequence of 8-bit symbols on a four-to-five basis (generating five 8-bit symbols for every four
Copyright © 2008 IEEE. All rights reserved.
689
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
control, request, or data symbols), and delivers the result via an IEEE 802.3 (Clause 35) gigabit media independent interface (GMII) to the PMD layer for encoding according to Clause 40 in IEEE Std 802.32005 for onward transmission to the peer port. Simultaneously, the port accepts an incoming stream of 8-bit symbols across a GMII from the PMD layer (received from the peer port); adapts and decodes these symbols; and places the resulting data, control, and arbitration signal in the port’s receive FIFO, which is used to retime the incoming stream to the local clock. The incoming signals are in due course processed by the background processRequests function. The port carries out these functions whenever and for as long as the port’s tportOn signal is set to TRUE (set and reset by the connection management state machine).
20.2 Port functions 20.2.1 Port functions overview The port provides transmit and receive functions for formatting data as it passes between the arbitration state machine and the PMD layer. In the transmitting direction, a stream of data bytes, arbitration requests, and control signals is mapped to a stream of bytes, which is in turn passed to the PMD layer, as illustrated in Figure 20-2. The adaptation layer encodes data bytes, requests, and control tokens into 10-bit symbols. The resulting 10-bit symbol stream is then transmitted as a stream of IEEE 802.3 (Clause 40) 8-bit bytes, on a five-to-four basis, i.e., five 8-bit bytes are transmitted for every four 10-bit T-mode symbols. The time taken to transmit a data byte, arbitration request, or control symbol is identical to a symbol time on a Beta mode port operating at S800. data byte (8 bits)
control token
request
request mapping
control token mapping
request symbol (6 bits)
control symbol (4 bits)
10-bit symbols adaptation layer 8-bit bytes IEEE 802.3 PHY - PMD LAYER
Figure 20-2—T-mode coding functions 20.2.2 Adaptation Each data byte, request token, or control token shall be encoded as a 10-bit symbol, and the resulting stream of 10-bit symbols shall be transmitted via the GMII on a five-to-four basis. The encoding of each data byte, arbitration request token, or control token shall depend on the position of the corresponding 10-bit symbol in the adaptation sequence. The position is denoted as A, B, C, or D. The position of the corresponding data bytes is denoted as a, b, c, d, or e. The 8 MSBs of the symbol in position A shall be transmitted as byte a,
690
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
with the MSB of the symbol in position A transmitted as the MSB of byte a. The remaining two bits of the symbol in position A shall be transmitted as the 2 MSBs of byte b. The 6 MSBs of the symbol in position B shall be transmitted as the 6 LSBs of byte b, etc. The symbol adaptation is shown in Figure 20-3. T-mode 10-bit symbols IEEE 802.3 (Clause 40) 8-bit bytes
A
B
a
b
C c
D d
e
Figure 20-3—T-mode adaptation NOTE—The MSB of each of the data bytes a, b, c, d, and e is transmitted on the GMII as TXD<7> and received on the GMII as TXD<7>.
20.2.2.1 Rate adaptation The T-mode port adaptation layer shall maintain an overall rate of transmission of 98.304 10-bit symbols per microsecond. It shall provide bytes in bursts, separated by periods of no data. Each period of no data shall last for 11 GTX_CLK periods. The T-mode port shall assert TX_EN when transmitting data bytes and deassert TX_EN during periods of no data. The clock frequency difference between 10-bit symbols being available on a nominal 98.304 MHz clock and 8-bit symbols being transmitted on a nominal 125 MHz clock results in byte bursts lasting between 643 and 655 bytes (depending on the permitted tolerances on the respective clock frequencies). The T-mode port transmitter shall include appropriate buffering to support this behavior (typically buffering up to nine 10-bit symbols during periods of no data). A period of no data may commence on an arbitrary byte boundary and, in particular, is not limited by the relative position of the 10-bit symbols and 8-bit bytes in the adaptation layer. The T-mode port receiver shall be able to tolerate periods of no data on arbitrary byte boundaries. The receive FIFO(s) shall be sized to tolerate intervals of no received data lasting up to nine 10-bit symbol times. The receiver adaptation layer may adapt the received 8-bit bytes to 10-bit symbols in the clock domain of the recovered IEEE 802.3 (Clause 40) transmit clock and push the resulting symbols into the arbitration layer receive FIFO in this clock domain. This avoids the necessity of recovering the 10-bit symbol transmit clock. The adaptation layer shall provide bytes for transmission or periods of no data whenever the PHY PMD_STATUS_request service reports PMD_TPORT_OK as TRUE. The T-mode port transmitter shall provide a period of no data for at least 11 GTX_CLK periods when PMD_TPORT_OK becomes TRUE, and all subsequent periods of no data shall last for exactly 11 GTX_CLK periods. The adaptation layer shall receive and adapt bytes whenever the PHY PMD_STATUS_request service reports PMD_TPORT_OK and either the GMII signal RX_DV is TRUE or the GMII signal RX_ER is TRUE. The adaptation layer shall generate the GTX_CLK compliant to Clause 35 in IEEE Std 802.3-2005. In the C code, this is modeled using a transmit reference clock GTX_REF_CLK.
20.2.2.2 Clause 40 in IEEE Std 802.3-2005 Data presented to the GMII shall be transmitted on the MDI, and data received from the MDI shall be presented to the GMII as specified in Clause 40 in IEEE Std 802.3-2005 with the following exception.
Copyright © 2008 IEEE. All rights reserved.
691
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
When in T-mode, the Ethernet PHY does not send valid Ethernet packets, but transfers all data presented on the GMII unaltered. In particular, it does not treat any data as preamble, nor does it generate SSD and ESD symbols. The PHY shall transmit data contained in TXD on the MDI when TXEN is high, independent of the actual data contained in TXD. The five-level pulse amplitude modulation (PAM5) encoding requires two convolution reset symbols in the symbol stream before sending IDLE symbols in order to guarantee that the trellis decoder transitions to state 0 to correctly receive IDLE symbols. Accordingly, when TXEN becomes deasserted, the PHY shall transmit two csreset symbols followed by IDLE symbols. The PHY shall also receive data from the MDI, present it on RXD, and activate RXDV whenever data are present, independent of the data contained in RXD, and deactivate RXDV whenever data are not present.
20.2.3 Coding 20.2.3.1 Main properties One benefit of the IEEE 802.3 (Clause 40) signaling scheme is that errored bytes are flagged as such. Thus, one element of robustness can take advantage of this feature: the receiving port can take special action on receipt of an errored byte. The encoding seeks first to protect the symbol type by —
Using only two symbol types, DATA or NON_DATA
—
Replicating the symbol type bit
—
Placing the two replicated bits at either end of the symbol
Thus, a single byte error may affect a type bit in two consecutive symbols and will affect one or the other of the type bits in a single symbol. However, it will never affect both type bits in a single symbol. Having protected the symbol type, the new encoding seeks to protect at least one of a pair of control symbols by using alternate encodings for symbols in positions A and B and for symbols in positions C and D (see Figure 20-3). This exploits the fact that there are only 16 control symbols values required (actually, only 14). Thus, a control symbol can be distinguished from a request symbol, and a full decode provided, in 5 bits. In the case of positions A and B, the control encoding can be distinguished from request encoding and be completely determined from the more significant 5 bits after the most significant Type bit and, in the case of positions C and D, from the less significant 5 bits before the least significant Type bit (see Figure 20-4). Similarly, the new encoding further seeks to protect the distinction between control symbols and arbitration requests by —
Replicating the bit that distinguishes between control symbols and arbitration request symbols
—
Placing the two replicated bits at either end of the subsymbol
This allows further robustness from knowledge of whether the symbol is a control symbol or an arbitration request, even though the particular control or request information may have been lost. Thus, in the case of errored byte a, symbol A is lost. In the case of errored byte b, symbol B is lost, but symbol A is still decoded correctly if a control symbol. In the case of errored byte c, both symbols B and C are still decoded correctly if they are control symbols. In the case of errored byte d, symbol C is lost, but symbol D is decoded correctly if a control symbol.
692
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
In the case of errored byte e, symbol D is lost. In all the above cases, some robustness can be provided on the basis of still being able to distinguish whether the lost symbol is a data symbol, a control symbol, or an arbitration request. The encoding also permits arbitration requests to be received correctly despite the symbol being affected by an errored byte in some situations.
20.2.4 Symbol types The encoding for each 10-bit symbol is specified in terms of a symbol type and an encoded request symbol. The symbol type information is replicated on transmission, being present in both the MSB and LSB positions of the 10-bit symbol. The coding is defined in terms of a letter denoting symbol type or symbol, followed by bit position, as illustrated in Figure 20-4. T0
S1
S2
S3
type
S4
S5
S6
S7
S8
symbol
0 1
T9 type
data value control symbol or arbitration request (encoded)
0 1
Figure 20-4—T-mode symbol type encoding 20.2.5 Data symbols Data symbols shall be encoded with T0 and T9 set to 0 and with S1 to S8 containing the data value.
20.2.6 Arbitration requests Arbitration requests shall be encoded with T0 and T9 set to 1, S1 and S8 set to 0, and S2 to S7 set to a value specifying the arbitration request, denoted as aaaiii as illustrated in Figure 20-5. T0
S1
S2
S3
S4
S5
S6
S7
S8
T9
1
0
a
a
a
i
i
i
0
1
Figure 20-5—Arbitration request encoding A single arbitration request symbol carries both an asynchronous request and an isochronous request, or it carries a legacy request or legacy phase. Asynchronous and isochronous requests are independently mapped into the respective component parts of the symbol according to Table 20-1 and Table 20-2. Each BOSS asynchronous request shall be mapped according to Table 20-1. Each BOSS isochronous request shall be mapped according to Table 20-2. A legacy request or phase shall be mapped according to Table 20-3.
Copyright © 2008 IEEE. All rights reserved.
693
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 20-1—Asynchronous request mapping Request
Request symbol component bits aaa
Reserved
000
CURRENT
001
NEXT_EVEN
010
CYCLE_START_REQ
011
NONE_ODD
100
NEXT_ODD
101
NONE_EVEN
110
BORDER
111
Table 20-2—Isochronous request mapping Request
Request symbol component bits iii
Not useda
000
ISOCH_NONE
010
ISOCH_EVEN
100
ISOCH_ODD
110
ISOCH_CURRENT
001
Not usedb
011
Reserved
101
Not usedc
111
aThe
component bits 000 are not used for an isochronous request as the resulting symbol would be indistinguishable from a configuration request. iii = 000 indicates a configuration request. bThe component bits 011 are not used for an isochronous request, but are used to identify a legacy request or phase. cThe component bits 111 are not used for an isochronous request as the resulting symbol would be indistinguishable from the requests used on the PIL-FOP interface. iii = 111 indicates a request used by the PIL-FOP interface (see 18.4).
Table 20-3—Legacy request and phase mapping Request
Request symbol aaaiii
LEGACY_REQUEST
0pp011
LEGACY_PHASE
1pp011
The request symbol component identified as pp in Table 20-3 shall carry the phase information, represented as a binary number modulo 4.
694
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
20.2.7 Configuration requests Each configuration request shall be mapped according to Table 20-4.
Table 20-4—Configuration request mapping Request symbol aaaiii
Request Reserved
000000
DISABLE_NOTIFY
001000
CHILD_NOTIFY/IDENT_DONE/PARENT_HANDSHAKE
010000
Reserved
011000
STANDBY
100000
SUSPEND
101000
PARENT_NOTIFY
110000
Reserved
111000
20.2.8 Control symbols in symbol positions A and B Control symbols in symbol positions A and B shall be encoded with T0 and T9 set to 1, S1 and S8 set to 1, S6 and S7 set to 0, and S2 to S5 set to a value specifying the control token, denoted as cccc as illustrated in Figure 20-6. T0
S1
S2
S3
S4
S5
S6
S7
S8
T9
1
1
c
c
c
c
0
0
1
1
Figure 20-6—Control symbol encoding in positions A and B Control tokens shall be mapped to 4-bit designators denoted as cccc according to Table 20-5, which in turn shall be used to provide bits S2–S5 of the control symbol.
20.2.9 Control symbols in symbol positions C and D Control symbols in symbol positions C and D shall be encoded with T0 and T9 set to 1, S1 and S8 set to 1, S2 and S3 set to 0, and S4 to S7 set to a value specifying the control token, denoted as cccc as illustrated in Figure 20-7. T0
S1
S2
S3
S4
S5
S6
S7
S8
T9
1
1
0
0
c
c
c
c
1
1
Figure 20-7—Control symbol encoding in positions C and D Control tokens shall be mapped to 4-bit designators denoted as cccc according to Table 20-5, which in turn shall be used to provide bits S4–S7 of the control symbol.
Copyright © 2008 IEEE. All rights reserved.
695
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 20-5—Control token mapping Control token
Control symbol designator cccc
Reserved
0000
CYCLE_START_EVEN
0001
CYCLE_START_ODD
0010
ATTACH_REQUEST/ARB_CONTEXT
0011
SPEEDa
0100
DATA_END
0101
DATA_NULL
0110
SPEEDb
0111
GRANT
1000
DATA_PREFIX
1001
Reserved
1010
GRANT_ISOCH
1011
SPEEDc
1100
ASYNC_EVEN
1101
ASYNC_ODD
1110
BUS_RESET
1111
20.3 T-mode port operation The port shall encode symbols for transmission via the adaptation layer and shall be prepared to receive and decode symbols from the adaptation layer whenever the flag tportOn is set. It shall not transmit symbols when tportOn is not set, and it shall ignore all received symbols when tportOn is not set.
20.3.1 Transmit operations 20.3.1.1 Control transmission When requested to transmit a control token, the port may need to stretch its duration to ensure that when the control token is subsequently forwarded through ports operating at a lower speed, those ports have sufficient time to transmit at least one control symbol. Stretching the duration is performed by transmitting the corresponding control symbol repeatedly. It is controlled by an effective speed parameter that is passed to the port along with the control token. The number of symbols transmitted for each control token is equal to the ratio of the port operating speed and this speed parameter, as shown in Table 20-6. For each control character that is transmitted, the T-mode port shall determine the control symbol for that control token according to 20.2.8 or 20.2.9 depending on the symbol position.
696
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 20-6—Control stretching formats Effective speed
Port operating speed S800
S100
S200
S400
S800
CCCCCCCC
CCCC
CC
C
NOTES 1—For any particular effective speed, a stretched sequence has constant duration at all port speeds, equal to the time taken to transmit a single character on a port operating at the effective speed. 2—C represents a control symbol.
20.3.1.2 Request transmission For each T-mode port request, the port shall determine the request symbol according to 20.2.6. At least four consecutive request symbols shall be transmitted for any given configuration request, as an aid to robustness.
20.3.1.3 Packet transmission A packet may be preceded by a number of DATA_PREFIX control tokens. Packet transmission begins with either a speed code or, in the case of some S100 packets where there is no speed code, the first data byte. During packet transmission, the port may still be required to transmit some control tokens, e.g., to complete a packet prefix. These control tokens and the packet data are referred to collectively as the packet payload. When the packet speed is less than the port operating speed, other characters are transmitted during the packet along with the payload characters. These characters are referred to as padding characters. This process is illustrated in Figure 20-8. In contrast to legacy DS ports, the port transmission speed remains constant for all packet speeds.
20.3.1.4 Speed signaling A speed code comprises a sequence of SPEEDa, SPEEDb, and SPEEDc control tokens and is transmitted during the packet prefix. The combination of SPEEDa, SPEEDb, and SPEEDc control tokens transmitted indicates the packet speed relative to the port operating speed. In addition, the use of a SPEEDa or SPEEDb token indicates that the packet format is Alpha or Beta, respectively (see 17.3.1.1). When required to transmit a speed code, the port shall generate a sequence of speed control tokens appropriate for the packet speed according to Table 20-7. Each speed control token shall be coded according to 20.2.3. NOTE—A speed code is not transmitted for a Alpha format S100 packet originated by a border node with a Alpha link or for a forwarded packet where the received packet has no speed code. See 17.3.10.
20.3.1.5 Payload transmission If the packet speed is less than the port operating speed, then data payload is padded with SPEEDc symbols. Each data byte shall be embedded in a 10-bit code as specified in 20.2.3. The resulting character shall be transmitted immediately before any SPEEDc control symbols. The port compares the value of the packet speed parameter with the port operating speed and determines the number of SPEEDc control symbols to be transmitted according to Table 20-8. The port shall generate the appropriate number of SPEEDc control symbols. These shall be coded according to 20.2.8 or 20.2.9 depending on the symbol position. If the packet speed is less than the port speed, then any payload control symbols are stretched as described in 20.3.1.1.
Copyright © 2008 IEEE. All rights reserved.
697
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Control token = DATA_PREFIX
Asynchronous Request = NONE_ODD Isochronous Request = ISOCH_EVEN
Control Symbol Component = 1001
Request Symbol component = 100100
Control Symbol = 1110010011 (assume symbol position AB)
Request Symbol = 1010010001 (assume symbol position CD)
packet prefix
data prefix
speed signal
packet
packet end
data
data prefix
D
payload character
Sc
packet end symbols
Sc
Sc
padding character
D
payload character
Figure 20-8—Structure of packet, packet delimiters, and request types with examples of coding process
Table 20-7—Speed code formats Packet speed Port operating speed S100
S200
S400
S800
S800
S cS c Sc S x Sc S cS cS c
S cS cS x S c
S cS x
Sb
speed signal duration (ns)
80
40
20
10
NOTES 1—Sc represents the SPEEDc control token. 2—Sx represents the SPEEDa control token when the Alpha packet format is used and represents the SPEEDb control token when the Beta packet format is used.
698
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 20-8—Data padding formats Packet speed
Port operating speed S800
S100
S200
S400
S800
DPPPPPPP
DPPP
DP
D
NOTES 1—For any particular packet speed, a padded sequence has constant duration at all port speeds. 2—D represents a payload data byte. 3—P represents a SPEEDc control symbol. 4—Table entries represent the information stream prior to coding.
20.3.2 Receive operations 20.3.2.1 Symbol decode rules NOTE—In the T-mode port state machine C code, the distinction is made between pktPrefix and pkt. Both of these are represented here as “in packet.”
The symbol decode rules are divided into two groups. The first group deals with symbols where the bytes contributing to the symbol have been received correctly, but some previous error may have led to some form of inconsistency. These rules are defined in Table 20-9.
Table 20-9—Symbol decode rules for nonerrored symbols #
T0
T9
S1
S8
In packet?
1
0
0
x
x
N
Replace with DATA_NULL.
2
0
0
x
x
Y
Accept as data.
3
opposite values
x
x
x
Ignore, increment invalid count.
4
1
1
0
0
N
Accept arbitration request.
5
1
1
0
0
Y
Accept arbitration request if valid (missed packet ending) and clear “in packet”; otherwise, ignore and increment invalid count.
6
1
1
opposite values
x
Errored arbitration or control request; ignore and increment invalid count.
7
1
1
1
1
N
If invalid control symbol, ignore and increment invalid count. Set “in packet” if DATA_PREFIX, SPEEDa, or SPEEDb. Replace DATA_END by DATA_NULL.
8
1
1
1
1
Y
If invalid control symbol, ignore and increment invalid count. Clear “in packet” unless DATA_PREFIX, SPEEDa, SPEEDb, SPEEDc, or DATA_END.
Result
The second group deals with symbols where one or both of the bytes contributing to the symbol have been received marked as erroneous by the IEEE 802-compatible PMD layer. These rules are defined in Table 20-10.
Copyright © 2008 IEEE. All rights reserved.
699
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table 20-10—Symbol decode rules for errored symbols #
Symbol position
Errored byte(s)
T0
T9
S1
S8
In packet?
9
A
a
x
0
x
x
Y
Accept as data.
10
A
a
x
0
x
x
N
Replace with DATA_NULL.
11
A
a
x
1
x
0
N
Ignore.
12
A
a
x
1
x
0
Y
Ignore; clear “in packet.”
13
A
a
x
1
x
1
x
Ignore.
14
A
ab
x
x
x
x
x
Ignore.
15
A
b
0
x
x
x
N
Replace with DATA_NULL.
16
A
b
0
x
x
x
Y
Accept as data.
17
A
b
1
x
0
x
N
Accept as arbitration request.
18
A
b
1
x
0
x
Y
Accept as arbitration request; clear “in packet.”
19
A
b
1
x
1
x
N
Accept (per row 7 above).
20
A
b
1
x
1
x
Y
Accept (per row 8 above).
21
B
b
x
0
x
x
N
Replace with DATA_NULL.
22
B
b
x
0
x
x
Y
Accept as data.
23
B
b
x
1
x
0
N
Ignore.
24
B
b
x
1
x
0
Y
Ignore; clear “in packet.”
25
B
b
x
1
x
1
x
Ignore.
26
B
bc
x
x
x
x
x
Ignore.
27
B
c
0
x
x
x
N
Replace with DATA_NULL.
28
B
c
0
x
x
x
Y
Accept as data.
29
B
c
1
x
0
x
N
Ignore.
30
B
c
1
x
0
x
Y
Ignore; clear “in packet.”
31
B
c
1
x
1
x
N
Accept (per row 7 above, but interpreting the control value purely on S2–S5).
32
B
c
1
x
1
x
Y
Accept (per row 8 above, but interpreting the control value purely on S2–S5).
33
C
c
x
0
x
x
N
Replace with DATA_NULL.
34
C
c
x
0
x
x
Y
Accept as data.
35
C
c
x
1
x
0
N
Ignore.
36
C
c
x
1
x
0
Y
Ignore; clear “in packet.”
37
C
c
x
1
x
1
N
Accept (per row 7 above, but interpreting the control value purely on S4–S7).
38
C
c
x
1
x
1
Y
Accept (per row 8 above, but interpreting the control value purely on S4–S7).
700
Result
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 20-10—Symbol decode rules for errored symbols (continued) #
Symbol position
Errored byte(s)
T0
T9
S1
S8
In packet?
39
C
cd
x
x
x
x
x
Ignore.
40
C
d
0
x
x
x
N
Replace with DATA_NULL.
41
C
d
0
x
x
x
Y
Accept as data.
42
C
d
1
x
0
x
N
Ignore.
43
C
d
1
x
0
x
Y
Ignore; clear “in packet.”
44
C
d
1
x
1
x
x
Ignore.
45
D
d
x
0
x
x
N
Replace with DATA_NULL.
46
D
d
x
0
x
x
Y
Accept as data.
47
D
d
x
1
x
0
N
Accept as arbitration request.
48
D
d
x
1
x
0
Y
Accept as arbitration request; clear “in packet.”
49
D
d
x
1
x
1
N
Accept (per row 7 above).
50
D
d
x
1
x
1
Y
Accept (per row 8 above).
51
D
de
x
x
x
x
x
Ignore.
52
D
e
0
x
x
x
N
Replace with DATA_NULL.
53
D
e
0
x
x
x
Y
Accept as data.
54
D
e
1
x
0
x
N
Ignore.
55
D
e
1
x
0
x
Y
Ignore; clear “in packet.”
56
D
e
1
x
1
x
x
Ignore.
Result
If a received control symbol or arbitration request can be fully decoded according to Table 20-9 or Table 20-10 (as appropriate), is specified in the table as “Accepted,” but does not correspond to a valid symbol or arbitration request, then it is ignored, and the invalid count is incremented (possibly as part of being incremented due to receipt of an errored byte or burst of bytes). Other actions noted in the appropriate table are still taken. The port will also maintain a register of the maximum errored byte burst length.
20.3.2.1.1 Loss of synchronization detection procedure The port determines that it has lost synchronization with the received character stream by monitoring the validity of received characters. The port shall maintain a count of the number of separate bursts of invalid characters received. Whenever a new burst of invalid characters is received, this count shall be incremented, to a maximum value of four. As IEEE 802.3 (Clause 40) errors may well occur in bursts of multiple bytes, the invalid count shall be incremented only on the first error in a burst of 64 bytes or less. The invalid count shall be incremented for every 64 bytes errored in a burst. Whenever two consecutive valid characters are received, the count shall be decremented (to a minimum value of zero). If the count reaches four, then the port shall give a loss of synchronization indication.
Copyright © 2008 IEEE. All rights reserved.
701
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
20.3.2.2 Control reception When any valid control character is received, the port shall determine the received control symbol by decoding the control character according to 20.2.8 or 20.2.9, as appropriate. In order to be a valid control character, a received character shall appear in Table 20-5. When a change on the received control token is detected (including the beginning of control token reception), the port shall indicate the first occurrence of the new control token to the arbitration state machine. The port shall not indicate subsequent contiguous occurrences of the same control token to the arbitration state machine. NOTE—This requirement is intended to ensure that isolated occurrences of a control token are never deleted by the port, while allowing redundant control symbols to be deleted when necessary to compensate for any difference between the local port clock and remote port clock frequencies.
If an invalid character is received during control token reception, the port shall maintain the previous control token indication.
20.3.2.3 Request type reception The port shall decode all valid request characters according to 20.2.6. The request type shall be determined from Table 20-1, Table 20-2, and Table 20-4. A configuration request shall be recognized only if two consecutive identical configuration request symbols are received (note that at least four consecutive identical symbols will have been transmitted). This provides protection against bit errors that may cause an arbitration request to be converted to a configuration request. If an invalid character is received during request type reception, the port shall maintain the previous request type indication.
20.3.2.4 Speed code determination A T-mode port shall receive a speed code (if any) and indicate the speed of the subsequent packet to the arbitration state machine. This indication shall not be generated before a SPEEDa or SPEEDb token or a data byte has been received. Valid speed signals shall be used to determine the speed of the subsequent packet according to Table 20-11.
Table 20-11—Speed code decoding Port operating speed Received speed code S800 none
S100
Sx
S800
ScSx
S400
ScScSxSc
S200
ScScScSxScScScSc
S100
NOTES 1—Sc represents the SPEEDc control token. 2—Sx represents either the SPEEDa or SPEEDb control token.
702
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
A speed code shall be considered valid only if it meets the following criteria: a)
All speed tokens are received consecutively.
b)
The pattern of SPEEDc and SPEEDx (x = a or b) tokens is found in Table 20-11.
If an invalid speed code is detected, the port shall pass the packet to the arbitration state machine as an Alpha format S100 packet in a hybrid bus and a Beta format S100 packet in a B-bus. However, if an invalid speed code is detected during the self-identify phase, the PHY shall initiate a new bus reset.
20.3.2.5 Payload reception All characters, whether control or data, received following a speed code or the first byte of data are considered part of the packet until the packet end is received. The packet speed may be used to determine the padding format of the packet. The port shall consider the first character received in a padded sequence to be the payload character. During packet reception, the port shall discard all padding characters and only indicate payload characters to the arbitration state machine. During packet reception, the port shall determine whether a received payload character is a data character or a valid control character. In order to be a valid control character, a received character shall appear in Table 20-5. The port shall decode all data payload characters according to 20.2.3. If a valid control payload character is received, the port shall determine the received control token by decoding the control character according to 20.2.8 or 20.2.9 depending on the symbol position. The port shall consider the first control character in a padded sequence to be the payload character. The port shall determine the format of the padded sequence for the packet speed according to Table 20-11. The port shall check that the format of the packet data sequence (padded or not) agrees with the format indicated by Table 20-8 for the packet speed. If no speed signal is received prior to the packet, then the packet speed should be S100, and the port shall check that the padding format is correct for an S100 packet. If at any point during packet reception a valid data character is received at a time when the padding format for the packet speed requires a padding symbol to be received, then an error has occurred, and the port shall not report those data to the arbitration state machine. If during packet reception the port receives a payload character that is neither a valid data character nor a valid control character, it shall indicate to the arbitration state machine that a data byte of value [0000 0000] was received. NOTE—A data character is considered as being in error only if the invalid character is in a payload position. Errors in padding positions are ignored.
Data reception ends when a packet end symbol is received.
20.3.2.6 Further robustness measures If a data symbol is encountered when not in packet context, then it and all succeeding data symbols are replaced by DATA_NULL. This includes the packet ending symbol DATA_END, but not the symbol GRANT or DATA_PREFIX. The packet remnant is turned into a NULL packet as the speed of the packet is unknown and also the speed at which to send the DATA_END is unknown. It should be noted that if an unexpected end of packet occurs (e.g., on the reception of a sudden IDLE signal or an arbitration request) when in packet context, then the arbitration state machine terminates the packet with DATA_END if sufficient time is available. Otherwise, it terminates the packet with an ARB_CONTEXT control symbol. This already provides robustness against dropped end of packet control symbols.
Copyright © 2008 IEEE. All rights reserved.
703
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
20.3.2.7 Error reporting Whenever the port detects a coding error, it shall increment the value of the portError register, to a maximum value of 255. The portError register shall be an 8-bit read-only PHY register. This register is intended for use by a single bus-wide diagnostic program and shall be cleared when read. The port takes no action based on the value of this register. A coding error shall be detected if a character is received that a)
Results in the port invalid count being incremented, or
b)
Is a valid payload character but is not received in the correct payload position within a padded packet, or
c)
Is a valid padding character but is not received in a correct padding position within a padded packet.
The port will also maintain a register of the maximum errored byte burst length. The maxErroredBurst register shall be an 8-bit read-only PHY register. This register is intended for use by a single bus-wide diagnostic program and shall be cleared when read. The port takes no action based on the value of this register.
704
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
21. S800 UTP (T-mode) PMD electrical specification This clause specifies the electrical signaling properties for the long-haul (up to 100m) UTP PHY when operating at S800. The relationship and interfaces between the T-mode PMD functions and other functions and layers are illustrated in Figure 21-1: Link B PHY
request/grant, enable
port controller
control
request\ grant
packet data
port status
config control
PHY-link interface
LTP RX flags
send LTP PHY packets
BOSS arbitration and control state machines
packet control PHY packets
packet transmit/receive TX/RX symbol, port status
TX/RX symbol, enables TX/RX symbol
Port
to other ports
Port
Connection management
DS-mode Beta- mode T-mode functions functions functions
Low-power signaling
Connection management
DS-mode Beta- mode T-mode functions functions functions
Low-power signaling
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
TX/RX data signals, PMD control/status, arb/connect control/status (DS only)
PMD
PMD UTP
UTP
Figure 21-1—PHY master architecture (S800 cat-5 UTP PMD in context) When operating in T-mode, a port accepts data symbols and control and arbitration request signals from the arbitration state machine (and also from the port’s connection management machine as the port transitions to and from the On state), encodes the control or arbitration request symbols, adapts the resulting symbol sequence to a sequence of 8-bit bytes on a five-to-four basis (generating five 8-bit bytes for every four control, request, or data symbols) and delivers the result via an IEEE 802.3 (Clause 35) GMII to the PMD layer for encoding according to Clause 40 in IEEE Std 802.3-2005 for onward transmission to the peer port.
Copyright © 2008 IEEE. All rights reserved.
705
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Simultaneously, the port accepts an incoming stream of 8-bit symbols across a GMII from the PMD layer (received from the peer port); adapts and decodes these symbols; and places the resulting data, control, and arbitration signal in the port’s receive FIFO, which is used to retime the incoming stream to the local clock. The incoming signals are in due course processed by the background processRequests function. The port carries out these functions whenever and for as long as the port’s tportOn signal is set to TRUE (set and reset by the connection management state machine).
21.1 T-mode PMD specification The encoding. decoding, electrical signaling and operating speed of the T-mode PMD layer shall be as specified in Clause 40 in IEEE Std 802.3-2005.
21.2 T-mode PMD initialization The T-mode PMD layer shall start normal signaling and attempt synchronization with its peer when the PMD_CONTROL_request SELECT_TPORT is made. On achieving synchronization, it shall assert the status signal PMD_TPORT_OK in any PMD_STATUS_request. On loss of synchronization, it shall deassert the status signal PMD_TPORT_OK. NOTES 1—GMII station management is not used in this standard. Equivalent functions are provided by the abstract PMD_CONTROL_request and PMD_STATUS_request services. 2—The implementation should map link_control[HCD]=enable to the service interface so that the higher layers will respond with PMD_SELECT_TPORT to enable the port.
21.3 Gigabit media independent interface (GMII) Data transfers between the T-mode port and the T-mode PMD layer are specified in terms of the IEEE 802.3 (Clause 35) GMII. Equivalent behavior for internal implementations (both functions on the same chip) are compliant. The GMII shall operate at a nominal clock frequency of 125 MHz. The transmit and receive clocks shall be as specified in Clause 35 in IEEE Std 802.3-2005. GMII signals are used as specified in Table 21-1.
Table 21-1—GMII signal usage GMII signal
706
Usage
TXD<7:0>
Byte to be transmitted
TX_EN
Set by T-mode port when a valid byte is present on TXD to be transmitted
TX_ER
Not used, held low
GTX_CLK
125 MHz transmit clock
RXD<7:0>
Received byte
RX_DV
Valid data present on RXD<7:0>
RX_ER
Errored data present on RXD<7:0>
RX_CLK
125 MHz receive clock
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table 21-1—GMII signal usage (continued) GMII signal
Usage
CRS
Not used, ignored
COL
Not used, ignored
NOTE—TXD<7> is the MSB of the byte to be transmitted and RXD<7> is the MSB of the byte received.
21.4 T-mode suspend and resume T-mode provides a new PMD mechanism to signal and power down devices on a link segment.
21.4.1 Alternative link pulse (ALP) The ALP is used to signal suspend information between two devices. The ALP is a fast link pulse burst (FLP burst) (as defined in 28.2.1.1.1 in IEEE Std 802.3-2005) where there are two defined 16-bit values: SUSPEND = 0000 0000 0000 0000 RESUME = 1111 1111 1111 1111
21.4.2 Suspend An initiator device that wishes to suspend transmission on a link segment sends a high-level SUSPEND token repeatedly for TPORT_MAX_LATENCY and then enters suspend mode and sends a PMD_UNSELECT_PORT request to the PMD layer. The PMD layer shall transmit ALPs with the SUSPEND value (all zeros). The target on reception of the suspend token will send a PMD_UNSELECT_PORT request to the PMD layer. The PMD layer shall transmit ALPs with the SUSPEND value (all zeros). While waiting for the initiator to transmit an ALP with the SUSPEND value, the target will still continue to receive suspend tokens even though it will not be transmitting normal signaling. Both initiator and target shall clear PMD_TPORT_OK on detection of loss of normal signaling. Both initiator and target shall wait for TPORT_MIN_SUSPEND_TIME before allowing a resume operation to proceed. This allows time for both ports to go down and for ALP signaling to be established. While in the suspended state, if the PMD layer detects loss of ALPs, then it shall clear PMD_TPORT_FW. While in the suspended state, the PMD layer may power down the transceivers on the twisted pairs not involved in the exchange of ALPs.
21.4.3 Resume A device that wishes to resume from suspend mode sends a PMD_SELECT_TPORT request to the PMD layer. The PMD layer shall then switch from sending ALPs with the SUSPEND value to sending ALPs with the RESUME value. Upon reception of an ALP with the RESUME value, the peer device shall switch from sending ALPs with the SUSPEND value to sending ALPs with the RESUME value and shall prepare to receive PAM5 codes on all four pairs.
Copyright © 2008 IEEE. All rights reserved.
707
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Upon reception of an ALP with the RESUME value, the first device shall cease transmitting ALPs, shall start transmitting PAM5 IDLE symbols, and shall prepare to receive PAM5 codes on all four pairs. Upon reception of IDLE symbols, the peer device shall cease transmitting ALPs and shall start transmitting PAM5 IDLE symbols. Both devices shall synchronize on the received IDLE symbols. Resynchronization shall occur within TPORT_ENABLE_TIME of 760 ms; and when synchronization is complete, each PMD layer shall assert a status of PMD_TPORT_OK.
21.5 UTP cable power Devices conforming to this standard may provide or use power on UTP cabling as described in IEEE Std 802.3-2005. Management of the power system when the T-mode port runs in IEEE 802.3 mode shall be as described in Clause 30 in IEEE Std 802.3-2005.
708
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Annex A (normative)
Cable environment electrical isolation A.1 Grounding characteristics of ac-powered devices AC-powered devices whose power cords provide for a connection to ground are typically wired as shown in Figure A.1.
hot
AC supply
neutral
Device
ground
Chassis (metal) Figure A.1—AC power supply with ground The ground wire is electrically connected to the metal chassis and does not carry power current to or from the powered device. The neutral wire is connected to earth ground but must also carry the full current used by the powered device; neutral wires exhibit significant voltages due to IR drops across them. In the event of an internal short-circuit of the hot wire to the chassis, significant current flows through the ground wire to ground and causes the activation of a current-limiting device in the hot wire circuit. This arrangement is intended to reduce the user’s risk of electrocution. NOTE—Many consumer electronic products have power cords with only two conductors, hot and neutral, but they typically have insulated cases that protect against shock hazards.
A consequence of the grounding scheme illustrated above is that the device chassis potential floats to the local ground voltage level. For a number of reasons, e.g., the return of large currents to earth by nearby, unrelated equipment, lightning strikes, or as the result of different power transformer supply domains, earth ground potential may vary by many volts. System designers are cautioned not to assume that the ground wire from different pieces of equipment connects to the same earth ground at the same voltage.
A.2 Electrical isolation The cables and connectors specified by this standard provide three ways in which chassis-to-chassis ground currents may flow —
The ground wire returns ground current to a chassis with a nonisolated power supply that provides cable power.
—
The ground wire returns ground current to the chassis via the logic circuits of the receiving PHY in the case where the PHY is not electrically isolated from the rest of the logic circuitry in a node (e.g., the link or other ICs).
Copyright © 2008 IEEE. All rights reserved.
709
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
—
IEEE STANDARD FOR A
The outer shield of the cable makes electrical connection, through the connector shield, to all connected chassis. Although this blocks RF emissions, it introduces another problem—a dc connection that forms a direct ground loop. The secondary problem may be solved by the use of RC circuits between the shield and the chassis that limit power line frequency currents while passing RF frequency currents.
A.3 Agency requirements The following information provides guidance for safety aspects relating to the interconnection and power distribution for serial bus devices. Because this standard permits cable power distribution at voltages greater than 24 V, international safety standards apply. The cabling and interconnection requirements are applicable to installations of information-processing or business equipment intended for, or capable of, permanent or cord connection (during operation) to 600 V or lower potential branch circuits when such equipment is intended for installations covered under the National Electric Code® (NEC®) (NFPA 70-1999) [B31].28 The equipment may also be installed according to NFPA 75-1999. Examples of the types of equipment covered by these recommendations include but are not limited to accounting and calculating machines; cash registers; copiers; data-processing equipment; dictating and transcribing machines; duplicators; erasers; modems and other data-communication equipment; motordriven filing cabinets, including cassette, CD, and tape accessing equipment; printers; staplers; tabulating machines; postal machines; typewriters; and other electrically operated equipment that separately, or assembled in systems, accumulate, process, and store data. Specifically not covered by these guidelines are equipment covered by other safety standards, including but not limited to the following: —
HVAC systems
—
Sensors
—
Alarms
—
Other equipment for the detection and signaling of conditions capable of causing damage or injury to persons
—
Fire extinguishing systems
—
Electrical power-supply equipment, such as motor-generator sets
—
Branch-circuit supply wiring
Separate safety standards apply to this kind of equipment, and the cabling and distribution must be modified in accordance to the specifications covering that kind of equipment, in force in the location of the installed equipment. Reference documents applicable in the United States include the following: —
UL 478-1984
—
The NEC
—
NFPA 75-1999
28National Electrical Code and NEC are both registered trademarks of the National Fire Protection Association, Inc. This information is
given for the convenience of users of this standard and does not constitute an endorsement by the IEEE of these products. Equivalent products may be used if they can be shown to lead to the same results.
710
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Reference documents applicable in Japan include the following: —
Electronic Equipment Technology Criteria by the Ministry of Trading and Industry (Similar to the NEC)
—
Wired Electric Communication Detailed Law 17 by the Ministry of Posts and Telecom Law for Electric Equipment
—
Dentori law made by the Ministry of Trading and Industry
—
Fire law made by the Ministry of Construction
Reference documents applicable in Europe include materials to secure the European Union CE marking as follows: —
Telecommunications Terminal Equipment (91/263/EEC)
—
EMC Directive (89/339/EEC)
—
CE Marking Directive (93/68/EEC)
—
LOW Voltage Directive (73/23/EEC) as amended by the CE Marking Directive (The CE Marking Directive is recommended as the basis for compliance)
The documents cited above provide reference information for selection and installation of cabling in walls, temporary partitions, under floors, in overhead or suspended ceilings, or in adverse atmospheres.
Copyright © 2008 IEEE. All rights reserved.
711
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
712
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex B (normative)
External connector positive retention The external shielded serial bus connection may be made using a positive retention scheme in addition to the detent passive retention that is built into the external connector itself. Positive retention is used where the external cable has to be held securely in place unless released by an intentional unlocking action. The standard 6-circuit Alpha external connector socket (see 4.2) has features already built in that are intended as anchor points for a hook type latch on the external plug cable assembly. The use of positive retention does not require different connectors. The flanges on the narrow sides of the socket as detailed in Figure 4-3 are used as the anchor points. Note that one of the flanges is considerably more narrow than the other. In order to retain maximum flexibility in implementation, the detailed dimensioning of the actual latching mechanism on the plug side is not specified in this standard. For implementations using positive retention, an exclusion zone on the socket side is defined that is reserved for positive retention mechanisms on the plug side (see Figure B.1).
Figure B.1—Exclusion zone for positive retention mechanism
Copyright © 2008 IEEE. All rights reserved.
713
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure B.2 shows a suggested shuttle latch mechanism that releases the hooks on the latch arms from the flanges on the socket connector by simply pulling on the outer housing of the external plug cable assembly. In this design, the arms of the shuttle latch will occupy part of the exclusion zone around the socket when the system is mated.
Figure B.2—Three views of plug with shuttle type latch The retention forces on the socket side may be considerably higher when using positive retention than when using passive retention. It is recommended that a suitable mounting means be used to distribute the force onto the enclosure wall when using positive retention. Any latching mechanism should withstand at least 44.5 N of axial force without demating and should nondestructively release at forces above 89 N. The exclusion zones increase the bulkhead space required for an external connection. See Figure I.2 through Figure I.5 for minimum mounting intervals. For example, if one wants to use positive retention on a common EISA/ISA/PCI external panel and the exclusion zone penetrates the panel, it requires horizontal cutouts to accommodate the positive retention. This is shown in Figure B.3.
Figure B.3—Cutouts in a typical personal computer option panel
714
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex C (normative)
Internal device physical interface C.1 Overview The cable media attachment specification in Clause 4 is suitable for external, box-to-box applications. (An example would be a computer, printer, and video camera connected via a serial bus; the computer and printer are powered from different ac outlets while the camera takes power from the serial bus cable.) The external cable also provides power to all PHYs on the bus so that they can maintain their bus repeater capability even when their local power is off. When necessary to accommodate different power domains (i.e., from different ac power sources), each node provides isolation between the its local ac power and external cable power. The external environment requires mechanically strong shielded cables and connectors. Internal devices may not have the same design criteria as external, box-to-box applications; they may be optimized for low-cost, low-power, minimum components and minimum package size (e.g., mass storage devices). Internal devices usually share a common power domain with other devices packaged within the enclosure and may not require mechanically strong or shielded connectors and cables. Internal devices may require other packaging options, such as hot-plug, auto-dock, and blind-mate; they may need various connector methodologies, such as cable or board attachment, with such connector systems as surface mount or card edge. A goal of the internal device interface is to allow implementation options for both the device vendor and the system integrator. These options enable serial bus internal devices to accommodate a wide range of applications in a cost-effective manner. Device options include a second port that can be configured as either as a repeater (bus) or as a second independent port (dual path). Packaging options include cable attachment, board attachment, or a combination of the two. Pins are allocated in the internal device connector to support these options.
C.2 Electrical interface for internal devices C.2.1 Power requirements It is assumed that a single external node will support multiple internal devices. The external node will provide the power isolation for the box with respect to other external nodes. The internal devices will share a common power domain within the box, eliminating the need for power isolation for each internal device. Internal device power is regulated +12 V, +5 V, and +3 V at 1.5 A. Connector pins are assigned for all three voltage levels (see Table C.1), but it is a box option to select which voltage levels will be provided. (Note that most devices use only one or two of the specified voltage levels.) Providing regulated voltage to the devices eliminates the need for a voltage regulator as described for the external box interface. It is assumed that fewer ground pins are needed than voltage pins. This is based upon the assumption that not all voltage pins will be utilized by any single device.
Copyright © 2008 IEEE. All rights reserved.
715
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table C.1—Internal device power connector pin allocation Pin #s
Signal name
1
+12 V CHG (long)
2
+5 V CHG (long)
3, 7, 8, 12, 15, 16
GND (long)
4, 5, 6
+12 V
9, 10
+5 V
11
PWRFAILa
13, 14
+3.3 V
a
See Table C.5.
Since devices are not required to implement power isolation, separate power domains within the device are not required. This allows a higher level of device electronic integration. Note that devices with different power requirements only need to implement a subset of these pins. See Table C.2.
Table C.2—Internal device power connector configurations Configuration
Signal pins used
Usage
2×3
11 through 16
3.3 V device
2×4
9 through 16
3.3 V and 5 V device
2×5
7 through 16
3.3 V and 5 V device with extra grounding
2×6
5 through 16
3.3 V, 5 V, and medium-power 12 V device
2×7
3 through 16
3.3 V, 5 V, and high-power 12 V device
2×8
1 through 16
3.3 V, 5 V, high-power 12 V, and capacitive charge device
C.2.2 Bus signal requirements Every serial bus device shall implement at least one port, referred to as the primary port. A device may optionally implement a second port, referred to as the secondary port. The secondary port may be configured as a bus repeater (as defined for the cable environment), or as a second independent serial bus (used for high-availability dual path support). The DUAL_BUS* signal provides the mode selection capability. Pin allocations for primary and secondary ports are shown in Table C.3. When the device is configured as a repeater, it shall maintain PHY functionality (signal repeat, etc.) while PWRFAIL is active and the appropriate power supply (either +3.3 V or +5 V depending on the implementation) is available. Each port is made up of six signals, consisting of the pair of differential signals defined to the cable environment and two signal grounds.
716
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table C.3—Internal device primary and secondary port pin allocation Pin #s
Signal name
1
TPA
2
TPA*
3
VG (long)
4
VG (long)
5
TPB*
6
TPB
To support hot-plugging of devices, the ground pin shall connect before the signal pins.
C.2.3 Miscellaneous signals A set of option signals are defined for the option connector, as shown in Table C.4.
Table C.4—Internal device option connector pin allocation Pin #s
Signal name
1
MTM*
2
AUTOSTART*
3
SYNC
4
DUAL_BUS*
5
GND
6
DEV_ACTIVE*
7, 8
RESERVED (OUT)
9, 10
RESERVED (I/O)
C.2.4 Signal descriptions Table C.5 provides descriptions of the internal device signals, and Table C.6 gives electrical specifications.
Table C.5—Internal device signal description Name MTM*
Usage input
Copyright © 2008 IEEE. All rights reserved.
Function Active low input places device in manufacturing test mode. The device will use a pullup resistor. When in this mode, all the options pins may be defined for custom use during manufacturing test.
717
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table C.5—Internal device signal description (continued) Name
Usage
Function
AUTOSTART*
input
Active low input pin will start the motor when power is applied. This device will provide a pullup resistor.
SYNC
input/output
This I/O pin is used to synchronize spindles of multiple devices. This output should change to a high-impedance state when power is removed.
DUAL_BUS*
input
Active low input forces device to treat secondary port as a separate serial bus. If inactive, the secondary port and primary port are treated as the same serial bus, and signals on one port are repeated to the other. The device will provide a pullup resistor.
DEV_ACTIVE*
open drain output
This open-drain active low output pin is used to indicate device activity. It may be used to control an LED. This output should be high impedance with no power.
RESERVED
These are reserved for future standardization. Two types are used: Output and Input/Output.
PWRFAIL
input
Connected to a power supply output power fail signal that goes active a minimum of 4 ms prior to the power supply output falling below 2.5% of 3.3 V or 5 V. The signal shall stay active a minimum of 2 ms after reaching the threshold level. The output signal (from the power supply) should have the following properties: VOL = 0.5 V max VOH = 2.4 V min IOL = 48 mA min (open drain)
Table C.6—Electrical interface specifications Signals
Specification
Input signals: MTM*, SYNC, AUTOSTART*, DUAL_BUS*, PWRFAIL
VIL = 0.8 V max VIH = 2.0 V min IIL = -0.6 mA max (includes 10 kΩ pullup resistor for PWRFAIL only) IIH = 40 μA max
Output signals: SYNC, DEV_ACTIVE*
VOL = 0.6 V max IOL = 24 mA min (open drain)
General requirements: a)
All ground pins shall be longer than other pins.
b)
All option pins not tied to ground shall go to a high-impedance state when device power is removed.
c)
All active low inputs require a pullup resistor on the device.
d)
All inputs shall be TTL compatible.
Functions for the options pins for serial storage architecture (SSA) devices and fibre channel devices are shown in Table C.7. The source standard for these non-serial-bus devices should be consulted for the latest description of the details.
718
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table C.7—Options pin comparison Pin number
Serial bus
SSA
Fibre channel
1
MTM*
MTM*
AUTOSTART2*
2
AUTOSTART*
AUTOSTART*
AUTOSTART1*
3
SYNC
SYNC
SYNC
4
DUAL_BUS*
EXT_FAULT*
RESERVED (IN)
5
GND (long)
GND (long)
GND (long)
6
DEV_ACTIVE*
DEV_ACTIVE*
DEV_ACTIVE*
7
RESERVED (OUT)
+5 V (OUT)
RESERVED (OUT)
8
RESERVED (OUT)
DEV_FAULT*
LRC
9
RESERVED (I/O)
RESERVED (I/O)
RESERVED (I/O)
10
RESERVED (I/O)
RESERVED (I/O)
RESERVED (l/O)
C.3 Internal unitized device connectors The internal connectors include a 4-bay, unitized plug connector with a 16-contact power bay, a 10-contact options bay, and two 6-contact bus bays mating to the unitized 4-bay backpanel receptacle. This makes a total of 38 contacts per each half of the mating PCB connectors. Also, 3 cable connectors are specified for reference: a 16-contact power receptacle, a 10-contact options receptacle, and a 6-contact bus receptacle. These cable receptacles mate with the corresponding bays on the unitized plug connector. All connector contacts shall be rated to carry 1.5 A with a maximum temperature rise of 20 °C. Within this annex, all dimensions and tolerances, and descriptions of those features that affect the intermateability of the plug and the receptacle, are given and are mandatory. No features are shown, however, for the termination side of any of the connectors, since the termination method and hardware are entirely optional. It is likely that there will be numerous variations of the unitized plug and receptacle to meet the design and production process requirements of different pieces of serial bus equipment. These requirements may require wave-soldered, through-hole mounted, or reflow-soldered SMT plugs and/or receptacles to a printed wiring board. Different hole and/or pad patterns may also be required on the board. Other variations may need a different mounting orientation of the connector relative to the board. Since these factors do not affect the intermateability of the connectors, they are not specified in this standard. However, a recommendation for the hole and/or pad pattern for the mounting of the unitized plug and receptacle to the PCB is suggested in Figure C.1 and Figure C.2. All other features of the connectors that do not affect the intermateability are not described and may vary. They are controlled only by the performance requirements described in C.3.5.1.
Copyright © 2008 IEEE. All rights reserved.
719
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.1—Recommended SMT PCB layout (connector mounting to the PC board in the device)
Figure C.2—Recommended PCB layout (connector mounting side)
720
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
C.3.1 Internal unitized plug The mating features of the connector plug are illustrated in Figure C.3. They will assure the intermateability of the plug with standardized receptacles.
Figure C.3—Internal unitized plug features
Figure C.4 through Figure C.9 describe a plug with a wafer that is segmented to form four separate bays. Each bay has solid, nonflexing contacts recessed within the wafer for protection against damage. Specified contacts in each bay are extended toward the mating face to provide “first-make, last-break” capability on designated power contacts. Each bay also contains a number of recessed detents to provide detent retention between the plug and receptacle connectors.
Copyright © 2008 IEEE. All rights reserved.
721
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.4—Internal unitized plug
722
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.5—Internal unitized plug retention (detent detail)
Figure C.6—Internal unitized plug header
Copyright © 2008 IEEE. All rights reserved.
723
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.7—Internal unitized plug bus (bay detail)
Figure C.8—Internal unitized plug options (bay detail)
724
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.9—Internal unitized plug power (bay detail)
Copyright © 2008 IEEE. All rights reserved.
725
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.10 and Figure C.11 describe separate plug headers used for controllers, power supplies, and other applications. These headers are individual versions of the internal unitized plug for bus and power. The bus is shown as a dual bay in Figure C.10 and the power as a single in Figure C.11.
Figure C.10—Internal unitized plug dual bus (bay detail)
726
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.11—Internal unitized plug discrete power (bay detail)
C.3.2 Internal unitized receptacles The mating features of the connector backpanel receptacle are illustrated in Figure C.12. They will assure the intermateability of the backpanel receptacle with a unitized plug.
Figure C.12—Internal unitized receptacle features
Copyright © 2008 IEEE. All rights reserved.
727
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.13 through Figure C.17 describe the outer plastic profile, which prevents mechanical damage to the flexing contact members. This assures adequate lead-in for the plug wafers and provides proper contact registration with the contact blades in the plug. Figure C.14 illustrates the contact typically used in the receptacles. Each bay in the plastic shell also provides detents that mate with the recesses on each wafer.
Figure C.13—Internal unitized receptacle
728
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.14—Internal unitized receptacle contact detail
Figure C.15—Internal unitized receptacle bus (bay detail)
Copyright © 2008 IEEE. All rights reserved.
729
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.16—Internal unitized receptacle option (bay detail)
Figure C.17—Internal unitized receptacle power (bay detail)
730
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.18 shows the necessary contact information to assure an adequate contact wipe distance. It also describes the force to be exerted by the plug contact at the point “Fn” as the “hertz normal force” and the plug contact as the “hertz mating surface.” Interface performance criteria are found in C.3.8.2 through C.3.8.8.
Figure C.18—Internal unitized device connector contact (wipe detail) The mating interface is a leaf-style design. The receptacle contacts are compliant, with a coined contact area. The plug contact is fixed and mates with the compliant receptacle contact, thus forming the complete electrical interface.
C.3.3 Connector cable receptacles The mating features and the face-view dimensions of the cable receptacles are shown in Figure C.19 and Figure C.20 for reference. They will assure the side-to-side stacking and intermateability of the cable receptacles with the corresponding bays of a standardized unitized plug.
Copyright © 2008 IEEE. All rights reserved.
731
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure C.19—Internal cable receptacle bus (bay detail)
732
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure C.20—Internal cable receptacle option and power (bay detail)
Copyright © 2008 IEEE. All rights reserved.
733
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The overall terminated size of a power cable receptacle is shown in Figure C.21 for reference only. Corresponding bus and optional cable receptacles will be proportionate. All other dimensions can be found in Figure C.19 and Figure C.20.
Figure C.21—Overall terminated size of a power cable receptacle
C.3.4 Cable receptacle termination The termination of discrete stranded wire or ribbon cable to the cable receptacles may be varied to suit the manufacturing process needs of the cable assembler. Since the plug termination does not affect the intermateability of the connector/cable assembly, any termination technique may be used, provided it meets the performance requirements in C.3.5.1 and the overall dimensions given in this annex. For reference, the following acceptable methods are listed: a)
Crimp
b)
Insulation displacement (IDC)
c)
Insulation piercing
d)
Welding
e)
Soldering
C.3.5 Cable It is recommended that one of the discrete wire or cables mentioned in the following subclauses be used in conjunction with the cable receptacles.
C.3.5.1 Flat ribbon cable 0.635mm pitch, #30 AWG solid or stranded copper conductor with PVC, TPE, or polypropylene insulation should be used.
734
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
C.3.5.2 Discrete wire #28 or #30 stranded copper conductor with PVC, TPE, or polypropylene insulation should be used. Please note that the insulation diameter of discrete wire has to fit the cable cover profile.
C.3.6 Contact finish on mating surfaces of plug and receptacle contacts It is necessary to standardize the electroplated finish on the mating surfaces to assure the compatibility of plugs and sockets from different sources. The following standardized electroplatings are compatible and may be used on mating surfaces of contacts: a)
0.76 μm (30 μin), minimum, gold, over 1.27 μm (50 μin), minimum, nickel.
b)
0.05 μm (2 μin), minimum, 0.127 μm (5 μin), maximum, gold, over 0.76 μm (30 μin) minimum, palladium, over 1.27 μm (50 μin), minimum, nickel.
c)
0.05 μm (2 μin), minimum, 0.127 μm (5 μin), maximum, gold, over 0.76 μm (30 μin) minimum, palladium-nickel alloy (80% Pd–20% Ni), over 1.27 μm (50 μin), minimum, nickel.
NOTES 1—Selective plating on contacts is acceptable. In that case, one of the electroplatings in the preceding list shall cover the complete area of contact, including the entire contact wipe area. 2—A copper strike is acceptable under the nickel electroplate. 3—A palladium strike is acceptable over the nickel electroplate.
C.3.7 Termination finish on plug and receptacle contact It is acceptable to use an electroplate of tin-lead with a minimum thickness of 3.04 μm (120 μin) over 1.27 μm (50 μin), minimum, nickel. A copper strike is acceptable under the nickel. The recommended platings shall assure a minimum of durability of 500 cycles minimum.
C.3.8 Connector performance criteria To verify the performance requirements, performance testing is specified according to the recommendations, test sequences, and test procedures of ANSI/EIA 364-B-90. Table 1 of ANSI/EIA 364-B90 shows operating class definitions for different end-use applications. These serial bus internal unitized device connector test specifications follow the recommendations for environmental class 1.3, which is defined as follows: “No air conditioning or humidity control with normal heating and ventilation.” The equipment operating environmental conditions shown for class 1.3 in Table 2 of ANSI/EIA 364-B-90 are —
Temperature: +15 °C to +85 °C
—
Humidity: 95% maximum
Class 1.3 is further described as operating in a “harsh environmental” state, but with no marine atmosphere. Accordingly, the performance groupings, sequences within each group, and the test procedures will follow the recommendations of ANSI/EIA 364-B-90, except where the unique requirements of the serial bus internal unitized device connector may call for tests that are not covered in ANSI/EIA 364-B-90 or where the requirements deviate substantially from those in that standard. In those cases, test procedures of other recognized authorities will be cited. Unitized plugs and receptacles shall pass all the following tests in the groups and sequences shown.
Copyright © 2008 IEEE. All rights reserved.
735
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
C.3.8.1 Test sample preparation The unitized plug and receptacle shall be tested unassembled for those tests that require it. They shall be tested assembled to randomly selected production printed wiring boards, typical of those used in serial bus equipment, for those tests that require assembled connectors. The cable receptacles shall be tested unassembled for those tests that require it. They shall be tested with any of the cables specified in C.3.1 for those tests that require assembled connectors. a)
All performance testing is to be done with cable material that conforms to this standard. In order to test to these performance groups, ANSI/EIA tests require that the cable construction used be specified.
b)
All resistance values shown in the following performance groups are for connectors only, including their terminations to the wire and/or PC board but excluding the resistance of the wire. Resistance measurements shall be performed in an environment of temperature, pressure, and humidity specified by ANSI/EIA 364-B-90.
c)
The numbers of units to be tested is a recommended minimum; the actual sample size is to be determined by requirements of users. This is not a qualification program.
d)
See Figure C.22 for vibration and shock fixturing method.
e)
See Figure C.23 for contact resistance measurement points.
C.3.8.2 Performance group A: Basic mechanical conformance and electrical functionality when subjected to mechanical shock and vibration Number of samples: [2] 38 contact unitized plugs, unassembled to PCB used for Phase 1, A1, and A2 (one each) [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 each] 16-contact, 10-contact, and 6-contact cable receptacles, assembled to cable, 200 mm long See Table C.8 for testing of performance group A.
Table C.8—Performance group A Measurements to be performed
Test Phase Title
ID number
A1
Visual and dimensional inspection
ANSI/EIA 364-18A-84
A2
Plating thickness measurement
736
Severity or conditions Unmated connectors
Title Dimensional inspection
Requirements for performance level
ID number Per Figure C.4 through Figure C.11, Figure C.13 through Figure C.21
No defects that would impair normal operations. No deviation from dimensional tolerances.
Record thickness; see C.3.1 and C.3.4.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table C.8—Performance group A (continued) Measurements to be performed
Test
Requirements for performance level
Phase Title A3
None
A4
Vibration
A5
None
A6
Mechanical shock (specified pulse)
A7
None
ID number
ANSI/EIA 364-28A-83
ANSI/EIA 364-27A-83
Severity or conditions
Title
ID number
See Figure C.23
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
Condition III (See note and Figure C.22)
Continuity
ANSI/EIA 364-46-84
No discontinuity at 1 μs or longer. (Each contact
Same as A3
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Condition G (See note and Figure C.22)
Continuity
ANSI/EIA 364-46-84
No discontinuity at 1 μs or longer. (Each contact)
Same as A3
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
NOTE—Connectors are to be mounted on a fixture that simulates typical usage. The PCB shall also be permanently affixed to the fixture. The PCB layout used will be in accordance with ones found in this annex. The cable receptacle shall be mated with the plug, and the other end of the cable shall be permanently clamped to the fixture. See Figure C.22 for details.
Figure C.22—Shock and vibration fixturing diagram
Copyright © 2008 IEEE. All rights reserved.
737
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
C.3.8.3 Performance group B: Low-level contact resistance when subjected to thermal shock and humidity stress Number of samples: [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 each] 16-contact, 10-contact, and 6-contact cable receptacles, assembled to cable, 200 mm long See Table C.9 for testing of performance group B.
Table C.9—Performance group B Measurements to be performed
Test Phase Title
ID number
Severity or conditions
Requirements for performance level
Title
ID number
See Figure C.23
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
B1
None
B2
Thermal Shock
ANSI/EIA 364-32B-92
Condition 1 10 cycles (mated). See Figure C.23.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
B3
Humidity
ANSI/EIA 364-31A-83
Condition C (504 h). Method III (cycling) nonenergized. Omit steps 7a and 7b (mated).
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
Figure C.23—Contact resistance measuring points
738
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
C.3.8.4 Performance group C: Insulator integrity when subjected to thermal shock and humidity stress Number of samples: [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 each] 16-contact, 10-contact, and 6-contact cable receptacles, unassembled See Table C.10 for testing of performance group C.
Table C.10—Performance group C Measurements to be performed
Test Phase Severity or conditions
Title
ID number
C1
Withstanding voltage
ANSI/EIA 364-20A-83
Test voltage 500 Vdc ± 50 Vdc. Method C (unmated and unmounted).
Withstanding voltage
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
C2
Thermal shock
ANSI/EIA 364-32B-92
Condition 1 10 cycles (unmated).
Withstanding voltage (same condition as C1)
ANSI/EIA 364-20A-83
No flashover. No sparkover. No excess leakage. No breakdown.
C3
Insulation resistance
ANSI/EIA 364-21B-96
Test voltage 500 Vdc ± 50 Vdc (unmated and unmounted).
Insulation resistance
ANSI/EIA 364-21B-96
100 MΩ, minimum, between adjacent contacts.
C4
Humidity cyclical
ANSI/EIA 364-31A-83
Condition A (96 h). Method III nonenergized. Omit steps 7a and 7b.
Insulation resistance (same conditions as C3)
ANSI/EIA 364-21B-96
100 MΩ, minimum, between adjacent contacts.
Copyright © 2008 IEEE. All rights reserved.
Title
Requirements for performance level
ID number
739
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
C.3.8.5 Performance group D: Contact life and durability when subjected to mechanical cycling and corrosive gas exposure Number of samples: [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 each] 16-contact, 10-contact, and 6-contact cable receptacles, assembled to cable, 200 mm long See Table C.11 for testing of performance group D.
Table C.11—Performance group D Measurements to be performed
Test Phase Title D1
None
D2
Durability
D3
None
D4
Mixed flowing gas
740
ID number
Severity or conditions
Title
ID number
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact
See Figure C.23.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure C.23. a) 2 mated pairs—unmated for 1 day. (b) 2 mated pairs—mated for 10 days.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
See Figure C.23. ANSI/EIA 364-09B-91
ANSI/EIA 364-65-92
Requirements for performance level
a) 2 mated pairs, 5 cycles. b) 2 mated pairs, automatic cycles to 250 cycles, rate 500 cycles/ h ± 50 cycles.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
C.3.8.6 Performance group E: Contact resistance and mating and unmating force when subjected to temperature life stress Number of samples: [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 each] 16-contact, 10-contact, and 6-contact cable receptacles, assembled to cable, 200 mm long See Table C.12 for testing of performance group E.
Table C.12—Performance group E Measurements to be performed
Test Phase Title E1
Mating and unmating
ID number ANSI/EIA 364-13A-83
Severity or conditions
Title
Requirements for performance level
ID number
Mount plug rigidly. Insert receptacle by hand.
Mating only
Auto rate: 25 mm/min
Unmating only
ANSI/EIA 364-13A-83
Unmating force: 9.8 N minimum 39.2 N maximum
See Figure C.23.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ, maximum, initial per mated contact.
E2
None
E3
Temperature life
ANSI/EIA 364-17A-87
Condition 4 (105 °C) 250 h. Method A (mated). See Figure C.23.
Low-level contact resistance
ANSI/EIA 364-23C-06
30 mΩ maximum change from initial per mated contact.
E4
Mating and unmating forces
ANSI/EIA 364-13A-83
Same as E1.
Mating and unmating forces
ANSI/EIA 364-13A-83
Same as E1.
C.3.8.7 Performance group F: Mechanical retention and durability Number of samples: [4] 38 contact unitized plugs, assembled to PCB [2] 38 contact unitized receptacles, assembled to PCB [2 of each] 16-contact, 10-contact, and 6-contact cable receptacles, assembled to cable 254 mm long minimum See Table C.13 for testing of performance group F.
Copyright © 2008 IEEE. All rights reserved.
741
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table C.13—Performance group F Measurements to be performed
Test
Requirements for performance level
Phase Title
ID number
Severity or conditions
F1
Mating and unmating forces
ANSI/EIA 364-13A-83
Mount plug rigidly by hand.
F2
Mating and unmating forces
ANSI/EIA 364-13A-83
F3
Durability
ANSI/EIA 364-09B-91
Title
ID number
Auto cycle: 100 cycles, 25 mm/min
Unmating forces
ANSI/EIA 364-13A-83
Unmating force: 9.8 N minimum 39.2 N maximum
Automatic cycling to 500 cycles
Unmating only
ANSI/EIA 364-13A-83
Unmating force at end of durability cycling: 9.8 N minimum 39.2 N maximum
C.3.8.8 Performance group G: General tests Suggested procedures to test miscellaneous, but important aspects of the connectors. NOTE—Since the tests listed below may be destructive, separate samples have to be used for each test. The number of samples to be used is listed under the test title.
See Table C.14 for testing of performance group G.
Table C.14—Performance group G Measurements to be performed
Test Phase Title G2
Cable axial pull test [2 plugs]
G3
Cable flexing [2 plugs]
742
ID number
ANSI/EIA 364-41B-89
Severity or conditions
Requirements for performance level
Title
ID number
Fix plug housing and apply a 98 N load for 1 min on cable axis.
Continuity, Visual
ANSI/EIA 364-46-84
No discontinuity greater than 1 μs. No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.
Condition I: dimension x = 3.7 × cable diameter or thickness; 100 cycles, in each of two planes.
a) Withstanding voltage
Per C1.
Per C1.
b) Insulation resistance
Per C3.
Per C3.
c) Continuity of all contacts
Per A4.
Per A4.
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex D (normative)
Backplane PHY timing formulas This annex contains the formulas used to derive the serial bus timing requirements for the backplane PHY. The information in the annex is not required for the design of the serial bus PHY. It is intended to serve as a guide for understanding the timing requirements contained within the backplane PHY specifications defined in Clause 5. This annex may be useful for the configuration of nonstandard topologies of the serial bus as well as for future enhancements to the serial bus standard.
D.1 Backplane propagation delay The propagation delay of serial bus signals on a “host” parallel backplane limits the speed of the arbitration process and packet transmission. In order to specify requirements for arbitration timing, gap timing, and skew tolerances, it is necessary to define a maximum propagation delay for serial bus signals. The one-way propagation delay (Tpd) of a backplane can be calculated with the following equations: T pd = T pl ⋅ L
T pd = T po ⋅ 1 + ( Cl ⋅ N ⁄ C ) ⋅ L
T pd = T po ⋅ ( 1 + ( Cl ⋅ M ) ⁄ ( L ⋅ C ) ⋅ L
where M L N Cl C Tpo Tpl Tpd
is the number of cards on backplane is the length of the backplane is the electrical pitch of cards on the backplane is the capacitive loading per card is the capacitive loading per unit length on unloaded backplane is the propagation delay per unit length on unloaded backplane is the propagation delay per unit length on loaded backplane is the one-way propagation delay on loaded backplane
Table D-1 indicates the “worst-case” one-way propagation delay (Tpd) and the round-trip propagation delay (Trt) for a number of standard backplanes. Although this table addresses IEEE 896 (Futurebus+), ANSI VME64, and IEEE 1296 (MULTIBUS II), the application of a serial bus is not limited to these backplanes. In order to accommodate all of these buses with a margin of error, the one-way propagation is specified (in 5.2.4.2) to be a maximum of 18 ns.
Copyright © 2008 IEEE. All rights reserved.
743
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table D-1—Backplane propagation delay Bus name
M
L
Cl
C
Tpo
Futurebus+
14 cards
0.421 m (1.38 ft)
10 pF/card
66 pF/m (20 pF/ft)
5.68 ns/m (1.73 ns/ft)
Folded Futurebus+
31 cards
1.259 m (4.13 ft)
10 pF/card
66 pF/m (20 pF/ft)
VME64
21 cards
0.500 m (1.64 ft)
20 pF/card
MULTIBUS II
21 cards
0.427 m (1.40 ft)
20 pF/card
Tpl
Tpd
Trt
13.98 ns/m (4.26 ns/ft)
5.88 ns
11.77 ns
5.68 ns/m (1.73 ns/ft)
12.37 ns/m (3.77 ns/ft)
15.58 ns
31.16 ns
66 pF/m (20 pF/ft)
5.81 ns/m (1.77 ns/ft)
21.59 ns/m (6.58 ns/ft)
10.79 ns
21.57 ns
66 pF/m (20 pF/ft)
5.81 ns/m (1.77 ns/ft)
23.23 ns/m (7.08 ns/ft)
9.91 ns
19.82 ns
NOTE—“Folded Futurebus+” indicates a 31-slot Futurebus+ backplane that uses a special signal distribution to minimize capacitance between adjacent modules. This results in an electrical length (L) that is twice the physical length of the backplane. Although the length of VME64 backplanes is the same as MULTIBUS II backplanes, VME64 backplanes allow for the use of offboard terminators, which can increase the electrical length. This results in a slight increase in the maximum round-trip propagation delay for VME64 backplanes.
D.2 Backplane arbitration timing Because the arbitration process does not use any form of acknowledgment or handshaking, proper operation of the arbitration process can only occur if all arbitrating nodes adhere to the same arbitration timing. Because the configuration of a given backplane is unknown (e.g., propagation delay of the backplane), it is necessary to specify for an absolute worst case. The following subclauses use the physical parameters of a worst-case scenario in order to calculate the arbitration timing. NOTE—It is possible to determine automatically the physical parameters of a given backplane. This would allow for dynamic configuration of “optimal” values for arbitration timing. This, however, would require a level of complexity that is beyond the scope of the backplane environment.
D.2.1 Synchronization timing The arbitration process requires participating nodes to be synchronized with each other, rather than with a distributed clock. This assumes that the arbitration state machines of any two nodes on the serial bus must be “out of sync” within a maximum “sync delay” in order for the arbitration process to occur properly. This “sync delay” takes into account the time required for a signal to be asserted on the bus, the time required for the bus to settle, and the amount of time required to detect a change on the bus. The time required for a signal to be asserted on the bus is equal to the clock-to-output delay of the decision logic (FFco), plus the propagation delay through the bus driver (TXpd). It is assumed that a round-trip bus propagation delay (Trt) is required for the bus to settle during arbitration. This is assumed because TTL backplanes require reflections to operate properly and because BTL backplanes require time for glitches to settle. The time required for a signal to be detected on the bus is equal to the propagation delay through the bus receiver (RXpd), plus the setup time for the sample circuitry (FFsu). To greatly reduce the possibility for metastability, the incoming arbitration sequence is synchronized to an internal clock before it is sampled. This process adds up to one arbitration clock time (Tclk = 20.345 ns) to the “sync delay.”
744
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Consequently, the “sync delay” is equal to T sync = FF co + TX pd + T rt + RX pd + FF su + T clk
where FFco TXpd Trt RXpd FFsu Tclk
is the clock to output delay of decision circuitry = 15 ns is the propagation delay through bus driver = 8 ns is the round trip bus delay = 36 ns is the propagation delay through bus receiver = 8 ns is the setup time of sample circuitry = 15 ns is the period of clock used to sample STRB and DATA (20.345 ns)
so that Tsync = FFco + TXpd + Trt + RXpd + FFsu + Tclk = 15 ns + 8 ns + 36 ns + 8 ns + 15 ns + 20.345 ns = 102.345 ns
D.2.2 Arbitration sample timing Before a node can begin arbitration, it has to sample the bus to determine if the bus is busy. If the bus is not busy, the node may begin the arbitration process by asserting the bus. It is possible, however, for one node to begin asserting the bus just as another node begins sampling the bus in order to begin the arbitration process. This second node will not detect activity on the bus because a finite amount of time is required for the asserted signal from the first node to reach the second node. Consequently, the second node will begin arbitrating as the first node continues arbitrating. In order to ensure that the bus has settled, the first node has to wait a certain amount of time (a “sample delay”) before it begins sampling the arbitration data on the bus. The “sample delay,” Tsmpl, is an integral number of arbitration clock times, which is greater than the sum of the “sync delay” and the round-trip bus propagation delay, as well as the logic delay required by the PHY sampling/decision circuitry. T smpl = int ( ( T sync + FF co + TX pd + T rt + RX pd + FF su ) ⁄ T clk ) + 1
= int ( ( 102.345 ns + 15 ns + 8 ns + 36 ns + 8 ns + 15 ns ) ⁄ 20.345 ns ) + 1 = int ( 184.345 ns ⁄ 20.345 ns ) + 1 = 9+1
= 10 bits
D.2.3 Arbitration hold timing In order to ensure that all nodes have had a chance to sample the arbitration data on the bus, an arbitrating node shall not change the state of the bus until it has waited a “hold delay” after sampling the bus.
Copyright © 2008 IEEE. All rights reserved.
745
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The “hold delay” is equal to the integral number of arbitration clock times, which is greater than the sync delay. T hold = int ( T sync ⁄ T clk ) + 1 = int ( 102.345 ns ⁄ 20.345 ns ) + 1 = 5+1 = 6 bits
D.2.4 Arbitration bit timing The timing required (Tarb) to complete one bit of the arbitration sequence can be calculated with the following equation: T arb = T smpl + T hold
= 10 bits + 6 bits
= 16 bits
This arbitration bit timing is specified in 5.2.4.3.
D.3 Backplane gap timing An interpacket gap occurs when the bus signals (both STRB and DATA) are unasserted for a certain duration. The bus signals are sampled to determine the length of a gap (at 49.152 MHz). Depending upon the duration of the gap, a backplane PHY may or may not be allowed to perform certain actions (either on the bus or internal to the PHY). The bus becomes idle once two data bit periods have occurred during which neither DATA nor STRB are unasserted. Because an incoming transmission may be at 49.152 Mbit/s or 24.576 Mbit/s, an idle bus is detected after four arbitration clock times (at 49.152 MHz, or approximately 20.345 ns) have occurred without a transition on either STRB or DATA. Upon detecting an idle bus, a node may begin the arbitration process. It has to wait a certain number of clock periods (depending upon the type of access being used), while sampling the bus to determine that it has remained idle during this time, before it can enter the arbitration contest. As is indicated in Table D-2, the type of access requested by a node determines the type of gap that has to be detected by the node, as well as the resulting action taken by the node. In order for a node to be able to distinguish between different types of gaps, it is necessary that each gap be of a different duration.
746
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table D-2—Gap types Gap type
Access type
Acknowledge gap
Action
Acknowledge
(send acknowledge)
Isochronous
(begin arbitrating)
Subaction gap
Fair or Urgent
(begin arbitrating)
Arbitration reset gap
Fair or Urgent
(reset flags, begin arbitrating)
D.3.1 Acknowledge gap D.3.1.1 Occurrence of acknowledge gap Acknowledge Transfers—During the time a node sends an acknowledge, it is assured ownership of the bus. There can be no other node transmitting on the bus or contending for the bus (assuming that the acknowledge is transmitted in a timely manner). Theoretically, it is only necessary for the acknowledging node to begin transmission of the acknowledge once it determines that the bus is idle (after four arbitration clock times have occurred without the bus being asserted). However, in order to simplify the circuitry required for this process, access for the bus for an acknowledge transmission is treated in the same manner as that for an isochronous access. Isochronous Transfers—When a node is attempting an isochronous access, it is not assured ownership of the bus. Just as with fair and urgent transfers, isochronous transfers first require a node to arbitrate for the bus (acknowledge transfers do not require arbitration for the bus).
D.3.1.2 Acknowledge gap timing Since arbitration is a synchronous process, it is necessary for arbitrating nodes to obey certain timing rules. This allows two nodes to arbitrate simultaneously for the bus. If a node wishing to obtain isochronous access to the bus were to begin arbitrating as soon as it detected an idle bus, it is possible that other nodes would not be able to detect the idle bus (because it has already been asserted by the first node) and consequently not get a chance to join the arbitration contest. If a node wishes to obtain access for an acknowledge or an isochronous transfer, it has to wait for an idle bus to occur. This occurs after a “sample time” equal to four arbitration clock times. Once the node detects that four arbitration clock times have occurred without an assertion on the bus, it is allowed to begin the arbitration contest. In order to allow other nodes to detect the idle bus, this node has to then wait a “hold time” before asserting the bus. This “hold time” is the integral number of clock periods greater than the maximum synchronization delay between nodes. The “sample time” is equal to the value in Table D-3.
Table D-3—Acknowledge gap sample time Parameter 4 Tclk
Value 81.38 ns
Notes Equal to two TTL bit periods (four clock periods)
Copyright © 2008 IEEE. All rights reserved.
747
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The “hold time” is the sum of the values in Table D-4.
Table D-4—Acknowledge gap hold time Parameter
Value
Notes
Trt
36 ns
Some node has just released the bus signals, and the transition has just reached the bus. It is assumed that node A detects this transition immediately, but that node B requires a reflected wave.
B-RXpd
8 ns
Even though this signal has to go through the RX and meet the setup time in both nodes, it has to be assumed that these values are minimum (0) for node A and maximum for node B (worst case)
B-FFsu
15 ns
B-Tclk
20.345 ns
For synchronization (node B is one clock period behind node A)
TOTAL
79.345 ns
3.90 clock periods
NOTE—When considering bus delay, Trt (round trip bus delay) has to be used when one or more nodes are releasing the bus. This is because reflections may be required on a TTL backplane and because glitches may occur on a BTL backplane (if two nodes release the bus at the same time). Tpd (one-way bus delay) can only be used if it is certain that one or more nodes are asserting the bus.
Since the sample time needs to be four clock periods and the hold time needs to be four clock periods, the acknowledge gap must be 4 + 4 clks = 8 clks. Consequently, if a node is to transmit an acknowledge on the bus, it first has to detect that the bus is unasserted for four clock periods and then wait four more clock periods before it can begin transmitting the acknowledge. If a node is to arbitrate for isochronous access, it first has to detect that the bus is unasserted for four clock periods and then wait four more clock periods before it can begin arbitrating for the bus.
D.3.2 Subaction gap and arbitration reset gap D.3.2.1 Occurrence of subaction and arbitration reset gaps Fair or Urgent Transfers—When a node is attempting a fair or urgent access, it is not assured ownership of the bus. Consequently, these transfers first require a node to arbitrate for the bus. Depending upon the state of the urgent_count or arbitration_enable_flag for a node, arbitration can occur after a subaction gap or an arbitration reset gap.
D.3.2.2 Subaction gap and arbitration reset gap timing In order for a node to be able to distinguish between an acknowledge gap and a subaction gap, as well as between a subaction gap and an arbitration reset gap, it is necessary that each gap be of a different duration. Assume node B is one sync time behind node A, that node A is waiting to begin arbitrating after a subaction gap (e.g., for a fair transfer), and that node B is waiting to begin arbitrating after an acknowledge gap (e.g., for an isochronous transfer). Node A has to wait long enough so that it can detect that node B has begun arbitrating, as shown in Table D-5.
748
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table D-5—Difference in gap times Parameter
Value
Notes
Trt
36 ns
Some node has just released the bus signals, and the transition has just reached the bus. It is assumed that node A detects this transition immediately, but that node B requires a reflected wave.
B-RXpd
8 ns
B-FFsu
15 ns
Even though this signal has to go through the RX and meet the setup time in both nodes, it has to be assumed that these values are minimum (0) for node A and maximum for node B (worst case).
B-Tclk
20.345 ns
For synchronization (B is one clock period behind node A)
B-FFco
15 ns
B has just asserted the bus to begin arbitration
B-TXpd
8 ns
Tpd
18 ns
Use Tpd because node B is asserting the bus.
A-RXpd
8 ns
It has to be assumed that these values are now at their maximum for node A (worst case).
A-FFsu
15 ns
TOTAL
143.345 ns
7.05 clock periods
Consequently, the sample time for a subaction gap has to be eight clock periods longer than an acknowledge gap. Since other nodes may also be sampling for the occurrence of a subaction gap (and they may be “lagging” by a maximum of four clock periods), a node has to wait four more clock periods after detecting a subaction gap before it can begin arbitrating for the bus. The same calculations can be made to determine the length of an arbitration reset gap. The sample time for an arbitration reset gap has to be eight clock periods longer than a subaction gap. Since other nodes may also be sampling for the occurrence of an arbitration reset gap, a node has to wait four more clock periods after detecting an arbitration reset gap, before it can begin arbitrating for the bus. Therefore, a node has to sample the bus at the time indicated in Table D-6 and cannot assert the bus until the time indicated in Table D-6.
Table D-6—Gap timing Gap type
Sample bus after
Do not assert until
Acknowledge gap
4 clocks
8 clocks
Subaction gap
16 clocks
20 clocks
Arbitration reset gap
28 clocks
32 clocks
This arbitration gap timing is reflected in 5.3.3.
D.3.3 Arbitration gap scenarios The following scenarios are the “worst-case” examples used to determine the gap times.
Copyright © 2008 IEEE. All rights reserved.
749
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
D.3.3.1 Scenario 1: acknowledge gap There are three nodes on the end of a bus. Node 1 (in slot 1) has just finished the transmission of a packet and releases the bus. Node 2 (in slot 2) is waiting to begin arbitration for isochronous access and is waiting for an ack gap to occur. It detects that Node 1 has released the bus at the incident wave; moreover, it has very fast RX and sample circuitry and has a clock that happens to be “in phase” with Node 1. Therefore, this detection occurs almost immediately. Node 3 (in slot 3) is also waiting to begin arbitration for isochronous access and is waiting for an ack gap to occur. It detects that Node 1 has released the bus at the reflected wave; moreover, it has very slow RX and sample circuitry and has a clock that is out of phase with Node 1. Therefore, this detection occurs at a time equal to the maximum sync delay, which is equal to Trt + RXpa + FFsu +Tclk. Substituting for these values yields a delay of 36 ns + 8 ns + 15 ns + 20.345 ns = 79.345 ns, or four clock periods. Node 2 now has counted four unasserted clock periods and wants to begin arbitration. It cannot do so, however, because if it asserts the bus, this action can and will be immediately detected by Node 3 (assume that Node 3 is able to detect the assertion at the incident wave for Node 2, and that the detection occurs immediately). In order to ensure that Node 3 has had enough time to detect that Node 1 has released the bus, Node 2 has to wait one max sync time (Trt + RXpd + FFsu + Tclk, or four clock periods) before it can assert the bus. Therefore, in order for both Node 2 and Node 3 to have the opportunity to arbitrate, both nodes have to wait one sample time (four clocks) before sampling the bus, and then one hold time (four clocks) before asserting the bus. This is a total of 4 + 4 = 8 clock periods.
D.3.3.2 Scenario 2: subaction gap There are three nodes at the end of a bus. Node 1 (in slot 1) has just finished the transmission of a packet and releases the bus. Node 2 (in slot 2) is waiting to begin arbitration for fair access and is waiting for a subaction gap to occur. It detects that Node 1 has released the bus at the incident wave; moreover, it has very fast RX and sample circuitry and has a clock that happens to be “in phase” with Node 1. Therefore, this detection occurs almost immediately. Node 3 (in slot 3) is also waiting to begin arbitration for fair access and is waiting for a subaction gap to occur. It detects that Node 1 has released the bus at the reflected wave; moreover, it has very slow RX and sample circuitry and has a clock that is out of phase with Node 1. Therefore, this detection occurs at a time equal to the maximum sync delay (Trt + RXpd + FFsu +Tclk, or four clock periods). Node 2 now has counted four unasserted clock periods, but it does not know if there are other nodes that are waiting for an ack gap to obtain access (for an acknowledge or isochronous access). It knows that such a node would assert the bus after detecting a total of eight unasserted clock periods. Moreover, this node could be one max sync delay out of phase (Trt + RXpd + FFsu + Tclk), and if it were to assert the bus, Node 2 might not detect this until some time later (FFco + TXpd + Tpd + RXpd + FFsu). The sum of these two delays is 79.345 ns + 64 ns = 143.345 ns, or eight clock periods. Therefore, Node 2 has to count the first four clock periods, plus four additional clocks (to complete the ack gap), plus eight more clocks (to all another node to detect the ack gap and assert the bus) before Node 2 can sample the bus. This is a total of 4 + 4 + 8 = 16 clocks.
750
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Node 2 now has counted 16 unasserted clocks and wants to begin arbitration. Node 3, however, is one max sync time (Trt + RXpd + FFsu + Tclk, or four clock periods) behind Node 2 and has only counted 12 unasserted clock periods. If it is to join in the arbitration process, it must be allowed to detect four more clock periods. Consequently, Node 2 cannot immediately assert the bus after sampling 16 clock periods. If it asserts the bus, this action can and will be immediately detected by Node 3 (assuming that Node 3 is able to detect the assertion by Node 2 at the incident wave, and that this detection occurs immediately). In order to ensure that Node 3 has had enough time to detect that Node 1 has released the bus, Node 2 has to wait one max sync time (Trt + RXpd + FFsu + Tclk, or four clock periods) before it can assert the bus. Therefore, in order for both Node 2 and Node 3 to have the opportunity to arbitrate, both nodes have to wait one sample time (16 clock periods) before sampling the bus, and then one hold time (four clock periods) before asserting the bus. This is a total of 16 + 4 = 20 clock periods.
D.3.3.3 Scenario 3: arbitration reset gap There are three nodes at the end of a bus. Node 1 (in slot 1) has just finished the transmission of a packet and releases the bus. Node 2 (in slot 2) is waiting to begin arbitration for fair access and is waiting for an arbitration reset gap to occur. It detects that Node 1 has released the bus at the incident wave; moreover, it has very fast RX and sample circuitry and has a clock that happens to be “in phase” with Node 1. Therefore, this detection occurs almost immediately. Node 3 (in slot 3) is also waiting to begin arbitration for fair access and is waiting for an arbitration reset gap to occur. It detects that Node 1 has released the bus at the reflected wave; moreover, it has very slow RX and sample circuitry and has a clock that is out of phase with Node 1. Therefore, this detection occurs at a time equal to the maximum sync delay (Trt + RXpd + FFsu +Tclk, or four clock periods). Node 2 now has counted four unasserted clock periods, but it does not know if there are other nodes that are waiting for a subaction gap to get access (for fair or urgent access). It knows that such a node would assert the bus after detecting a total of 20 unasserted clock periods. Moreover, this node could be one max sync delay out of phase (Trt + RXpd + FFsu + Tclk), and that if it were to assert the bus, Node 2 might not detect this until some time later (FFco + TXpd + Tpd + RXpd + FFsu). The sum of these two delays is: 79.345 ns + 64 ns = 143.345 ns, or eight clock periods. Therefore, Node 2 has to count the first four clock periods, plus 16 additional clock periods (to complete the subaction gap), plus eight more clocks (to allow another node to detect the subaction gap and assert the bus) before Node 2 can sample the bus. This is a total of 4 + 16 + 8 = 28 clock periods. Node 2 now has counted 28 unasserted clock periods and wants to begin arbitration. Node 3, however, is one max sync time (Trt + RXpd + FFsu + Tclk, or four clock periods) behind Node 2 and has only counted 24 unasserted clock periods. If it is to join in the arbitration process, it has to be allowed to detect four more clock periods. Consequently, Node 2 cannot immediately assert the bus after sampling 28 clock periods. If it asserts the bus, this action can and will be immediately detected by Node 3 (assuming that Node 3 is able to detect the assertion by Node 2 at the incident wave, and that this detection occurs immediately). In order to ensure that Node 3 has had enough time to detect that Node 1 has released the bus, Node 2 has to wait one max sync time (Trt + RXpd + FFsu + Tclk, or four clock periods) before it can assert the bus. Copyright © 2008 IEEE. All rights reserved.
751
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Therefore, in order for both Node 2 and Node 3 to have the opportunity to arbitrate, both nodes have to wait one sample time (28 clock periods) before sampling the bus, and then one hold time (four clock periods) before asserting the bus. This is a total of 28 + 4 = 32 clock periods.
D.4 Backplane environment skew Table D-7 gives the maximum allowable skew for various backplane technologies.
Table D-7—Backplane environment skew analysis TTL
BTL
ECL
Bit cell period
1/(24.576 MHz ± 100 ppm) ≈ 40.690 ns
1/(49.152 MHz ± 100 ppm) ≈ 20.345 ns
1/(49.152 MHz ± 100 ppm) ≈ 20.345 ns
TX package skew
5.0 ns
3.0 ns
3.0 ns
Spatial skew
1.0 ns
0.5 ns
0.5 ns
Logic skew
1.690 ns
1.845 ns
1.845 ns
Total TX skew
7.690 ns
5.345 ns
5.345 ns
Backplane skew
7.0 ns
6.0 ns
6.0 ns
RX package skew
5.0 ns
3.0 ns
3.0 ns
Spatial skew
1.0 ns
0.5 ns
0.5 ns
RX setup/hold
5.0 ns
3.0 ns
3.0 ns
Total RX skew
11.0 ns
6.5 ns
6.5 ns
Margin
15.0 ns
2.5 ns
2.5 ns
This table can be used to compute the TX edge separation, the RX edge separation, and the skew margin for each technology using the following formulas: TX edge separation = bit cell period − total TX skew RX edge separation = TX edge separation − backplane skew margin = RX edge separation − total RX skew More simply: margin = (bit cell period − (total TX skew + backplane skew + total RX skew)) The results of this analysis are reflected in Table 5-4.
752
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex E (normative)
Cable operation and implementation examples E.1 Performance optimization Three of the simplest ways to improve the performance of a serial bus configuration are to — Rearrange the devices to minimize the longest round-trip delay between any two leaf nodes. This may involve either minimizing the number of hops (cable connections) between the farthest devices, reducing cable lengths, or both. — Group devices with identical speed capabilities next to one another. This avoids the creation of a “speed trap” when a slower device lies along the path between two faster devices. — Set the PHY gap_count parameter to the lowest workable value for a particular topology. The first two methods likely yield the most dramatic results, but they depend upon the designer of the topology (in those cases, such as inside an equipment enclosure, where it is fixed) or else upon the user’s willingness to reconfigure the bus. An application that analyzes the self-ID packets and offers suggestions for better arrangements likely would be of great value to naive users. The third method may be employed with or without changes to bus topology. The bus manager or, in the absence of a bus manager, the IRM, should optimize performance by setting the gap count according to the recommendations of this annex. Note that failure to optimize the gap count nullifies the benefit of a topology chosen to minimize round-trip delays. Because of cable and PHY propagation delays, it is highly unlikely that any two nodes observe Idle gaps between packets of precisely the same duration. A node that completes data transmission and releases the bus observes Idle sooner than a node farther away. However, for different nodes’ arbitration state machines to interact correctly it is necessary for all nodes to observe the same type of gap, either an arbitration reset gap or a subaction gap. Each type of gap has a minimum and maximum time that is derived from gap_count, as specified by 9.2.7. The Idle time occupied by arbitration reset and subaction gaps is not available for either arbitration or data transfer, so it is reasonable to minimize this wasted time by choosing the smallest workable gap_count. The only constraint is that gap_count never be reduced to a value where either —
An asynchronous subaction is interrupted by node(s) other than the source and destination, or
—
Where all nodes fail to consistently and identically detect subaction gaps (at the end of the selfidentify process or the isochronous period and, at other times, if not interrupted by ack-accelerated arbitration) and arbitration reset gaps.
The worst disparity between observed Idle times occurs in one of the following two cases: —
Between whichever two nodes have the greatest round-trip delay for data transmission between them.
—
Between whichever two nodes have the greatest accumulated disparity of one-way arbitration vs. data repeat delays of the PHYs on the path between them.
Dependent upon bus topology and cable lengths, either round-trip delay or one-way repeater disparity will dominate. The disparity between arbitration and data repeat delays for a PHY is 80 ns, as specified by ARB_RESPONSE_DELAY. Consequently, the accumulated disparity between any two nodes is simply
Copyright © 2008 IEEE. All rights reserved.
753
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
80 ns multiplied by the number of intervening PHYs between the nodes. Although it relies on informative assumptions, this standard suggests that round-trip delay may be obtained from the following formula Round-trip delay = 2 × ( Hops – 1 ) × ( Cable delay + PHY delay ) + 2 × Cable delay With knowledge of the topology and individual PHY delays derived from the self-ID packets (and an assumed value for cable delay), the bus manager may use the preceding formula to calculate round-trip delay between all possible combinations of leaf nodes. The maximum round-trip delay may in turn be used to derive an optimal gap count. This method is approximate and may be improved by actually measuring the round-trip delays. Subclause 16.3.2.4.1 defines the “ping” packet, which permits direct measurement of round-trip delay. The bus manager may measure all leaf-to-leaf delays even if it is not itself a leaf. The possible topologies resolve into one of the following three categories: a)
The bus manager is a leaf and the round-trip delay is to be measured to another leaf.
b)
The bus manager is not a leaf but is on the path that connects two leaves whose round-trip delay is to be measured.
c)
The bus manager is neither a leaf nor on the path that connects two leaves whose round-trip delay is to be measured.
In all cases, the bus manager first measures propagation time(s) between itself and target node(s), then calculates the desired round-trip delay from the separately measured propagation times. The bus manager measures propagation time by transmitting a ping packet and timing the return of the first self-ID packet transmitted in response. This presupposes that the bus manager link hardware has a timer of sufficient accuracy and granularity to autonomously time the interval. The minimum and maximum propagation times may be calculated as follows: Propagation time min = Ping time – ( DATA_END_TIME max + LINK_TO_BUS_DELAY max + RESPONSE_TIME max + BUS_TO_LINK_DELAY max ) – 2 × ∑ ( PHY jitter ) Propagation time max = Ping time – ( DATA_END_TIME min + LINK_TO_BUS_DELAY min + RESPONSE_TIME min + BUS_TO_LINK_DELAY min ) + 2 × ∑ ( PHY jitter )
Propagation time is the aggregate cable and PHY delay adjusted for jitter (which is obtained by PHY register reads of each node on the path); delay caused by arbitration or the PHY/link interface is subtracted out. The ping time, measured by link hardware, starts when the last (least significant) bit of the ping packet is transferred from the link to the PHY and ends when a data prefix indication is signaled by the PHY. The constants are obtained from Table 9-18 and Table 17-49. The term for PHY jitter is the sum of individual PHY jitter for each of the repeating PHYs on the path between the bus manager and the pinged node (exclusive of the terminal nodes themselves); this can be obtained by a remote read of the PHY registers (see 15.2 and 16.3.2.4.2). The resultant round-trip delay is expressed in units of microseconds; convert all values appropriately. NOTE—The propagation time may be measured for any PHY packet that provokes a response from the addressed PHY, not only the ping packet. For example, a remote access packet may be used both to obtain PHY jitter from another PHY and measure the propagation time in the same step.
754
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The three different cases for the derivation of leaf-to-leaf round-trip delays are illustrated by Figure E.1; the bus manager is labeled M.
γ M
α
β
δ Figure E.1—PHY pinging and round-trip times
In the first case, imagine that nodes β, γ, and δ are not present, i.e., that the bus manager and node α are both leaf nodes. The round-trip delay is the propagation time measured from the bus manager to node α, as already described. For the second case, assume that the round-trip delay is to be calculated between nodes α and γ. The bus manager first measures the propagation time from itself to node α and then from itself to node γ. The roundtrip delay between the two leaf nodes also needs to account for the bus manager’s PHY delay and is expressed by Round-trip delay (α,γ) = Propagation time α + Propagation time γ + 2 × PHY delay M In the formula above, all of the times are maxima; the bus manager’s PHY delay is obtained from its own PHY registers. The third and final case, for which the round-trip delay between nodes γ and δ is derived, is the most involved because the bus manager is not on the path between the two leaf nodes. First the bus manager measures propagation times to both nodes γ and δ. Then the bus manager measures the propagation time to the node closest to the bus manager that is also on the path between the leaf nodes—node β in this example. These measurements can be combined to eliminate the propagation time from the bus manager to node β and the excess PHY delay for node β (measured twice in the propagation times for nodes γ and δ) as follow: Round-trip delay (γ,δ) = Propagation time γ + Propagation time δ – 2 × ( Propagation time β – PHY delay β ) – 240 ns
In this final case, the propagation times measured for nodes γ and δ are maxima while the propagation time measured to node β is a minimum. The PHY delay for node β is a maximum and is obtained by remote access to that node’s PHY registers. In order to calculate an optimal gap count for a particular topology, two values are required for each possible leaf-to-leaf pair, the round-trip delay between them, and the accumulated disparity of arbitration vs. data repeat delays of their intervening PHYs. Use the methods described above to measure the round-trip delays and calculate the accumulated repeat delay disparity from a knowledge of the bus topology. For a particular pair of nodes, select the largest value yielded by the following formulas:
Copyright © 2008 IEEE. All rights reserved.
755
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
BASE_RATE max ⎛ Round-trip delay max + RESPONSE_TIME j, max ⎞ BASE_RATE max × ⎜ ⎟ + 29 × ------------------------------------------ – 51 BASE_RATE min ⎝ – MIN_IDLE_TIME + PHY_DELAY i, max ⎠ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------BASE_RATE max 32 – 20 × -----------------------------------------BASE_RATE min BASE_RATE max BASE_RATE max × ( Accumulated repeat delay disparity max + PHY_DELAY j, max ) + 53 × ------------------------------------------ – 51 BASE_RATE min --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------BASE_RATE max 36 – 32 × -----------------------------------------BASE_RATE min
Note that although the round-trip delay measurement is not dependent upon the ordering of the two nodes, it is necessary to apply the preceding formulas twice for each pair of leaf nodes, since the results may be dominated by different timing constants for the two PHYs, designated i and j. Repeat these measurements and calculations for all possible leaf-to-leaf node combinations and retain the largest value obtained from the formulas. After all combinations have been examined, the optimal gap_count for the topology is obtained by rounding the retained value up to the next larger integer. The bus manager or, in the absence of a bus manager, the IRM may transmit gap_count in a PHY configuration packet to optimize serial bus performance. If the bus manager does not have the link timer necessary to measure propagation delays, it may be appropriate to optimize the gap count in a more approximate fashion. If, by means beyond the scope of this standard, the bus manager knows that the maximum cable length used in the topology is 4.5 m and that the maximum PHY delay is 0.144 μs, the gap count may be obtained from Table E.1.
Table E.1—Gap count as a function of hops
756
Hops
Gap count
1
5
2
7
3
8
4
10
5
13
6
16
7
18
8
21
9
24
10
26
11
29
12
32
13
35
14
37
15
40
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Table E.1—Gap count as a function of hops (continued) Hops
Gap count
16
43
17
46
18
48
19
51
20
54
21
57
22
59
23
62
E.2 Cable environment jitter budget Table E.2, Table E.3, and Table E.4 give the jitter budget for the three cable PHY data rates. These can be used to compute the jitter margin for each data rate using the following formula: Jitter margin = (Bit cell time − (Data jitter + Strobe jitter + Skew)) The jitter margin for the S100 rate is equal to (10.17− (3.08 + 3.08 + 1.0)) = 3.01 ns.
Table E.2—S100 jitter budget (ns) Data jitter
Strobe jitter
Transmitter skew
Skew 0.4
Transmitter jitter
0.80
0.80
Cable reflections
0.13
0.13
Cable intersymbol
0.1
0.1
Cable delay mismatch
0.4
Channel margin
0.05
0.05
Jitter at receive pins
1.08
1.08
0.8
Receiver offset
0.5
0.5
0.2
Receiver intersymbol and power supply rejection
0.5
0.5
Flip flop setup and hold
1.0
1.0
Total
3.08
3.08
Copyright © 2008 IEEE. All rights reserved.
1.0
757
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The jitter margin for the S200 rate is equal to (5.08 − (1.45 + 1.45 + 0.75)) = 1.43 ns.
Table E.3—S200 jitter budget (ns) Data jitter
Strobe jitter
Transmitter skew
Skew 0.25
Transmitter jitter
0.2
0.2
Cable reflections
0.08
0.08
Cable intersymbol
0.12
0.12
Cable delay mismatch
0.4
Channel margin
0.05
0.05
Jitter at receive pins
0.45
0.45
0.65
Receiver offset
0.25
0.25
0.1
Receiver intersymbol and power supply rejection
0.25
0.25
Flip flop setup and hold
0.5
0.5
Total
1.45
1.45
0.75
The jitter margin for the S400 rate is equal to (2.54 − (0.705 + 0.705 + 0.65)) = 0.48 ns.
Table E.4—S400 jitter budget (ns) Data jitter
Strobe jitter
Transmitter skew
0.2
Transmitter jitter
0.1
0.1
Cable reflections
0.035
0.035
Cable intersymbol
0.13
0.13
Cable delay mismatch Channel margin
0.4 0
0
Jitter at receive pins
0.265
0.265
0.60
Receiver offset
0.14
0.14
0.05
Receiver intersymbol and power supply rejection
0.1
0.1
Flip flop setup and hold
0.2
0.2
0.705
0.705
Total
758
Skew
0.65
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
E.3 Cable PHY configuration example This subclause gives a detailed example of the three phases of configuring a cable environment: bus initialize, tree identify, and self-identify. Note—Annex describes a method to efficiently determine the bus topology after a bus reset.
E.3.1 Bus initialization process Whenever a node joins the bus, a signal forces all nodes into a special state that clears all topology information and starts the next phase. During this phase, the connection status of each port is latched internally by the PHY. If the connection status of any port changes after the bus initialization phase (i.e., an adjacent device is removed or added), the PHY will automatically drop back to the bus initialization phase. Nodes with no connected ports are isolated; nodes with a single connected port are “leaves”; nodes with two or more connected ports are “branches.” The eventual root (next section) may be either a branch or a leaf. An example configuration after the bus initialization process is complete is shown in Figure E.2.
Figure E.2—Example cable state after bus initialization process NOTE—In Figure E.2 through Figure E.19, the two arrows representing the physical connection between the nodes are just an abstract representation of line state signaling. They do not imply that the signaling uses different wire pairs for the two directions; in fact, both directions use both pairs, and the received signal is the result of the dominance of “1” over “0” over “Z.”
Note that each port of the node is individually numbered. There is no particular order to the numbering. It is just a way to give each port a unique label.
E.3.2 Tree identify process After a bus initialization process, the tree identify process translates the general network topology into a tree, where one node is designated a root and all of the physical connections have a direction associated with them pointing towards the root node. The direction is set by labeling each connected port as a “parent” (connected to a node closer to the root) or “child” port (connected to a node further from the root). Any
Copyright © 2008 IEEE. All rights reserved.
759
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
unconnected ports are labeled “off” and do not participate in further arbitration processes. Any loop in the topology is detected by a timeout in the tree identify process. a)
The first step is for all leaf nodes (those with a single connected port) to notify their probable parents. In this example, nodes A, C, and E send a parent_notify to their single connected port. This is the start of the parent-child handshake process. See Figure E.3.
Figure E.3—Tree identify process start, beginning of child handshake b)
At this point, nodes B and D internally recognize the parent_notify signals and mark the ports receiving parent_notify as child ports. Thus, B and D now each have one port remaining that is connected but not yet identified as child or parent. They each now send parent_notify up to their probable parents, and at the same time they send down child_notify signals to their child ports.
c)
If a node has been selected by software to be the root, this is the point of intervention. The selected node (i.e., the node with force_root set) will wait before sending the parent_notify signal for a 160 μs timeout period. Unless another node in the network also has its force_root set, this insures that the selected node will receive parent_notify on all its connected ports and thus mark them all child ports. See Figure E.4.
Figure E.4—End of child handshake
760
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
d)
IEEE Std 1394-2008
When the leaf nodes receive the child_notify, they know that port is truly their parent port and that their part of the tree identify process is complete. They then withdraw their parent_notify as a parent handshake. At the same time, both nodes B and D discover that they are receiving the parent_notify port from their proposed parent. Since one of the two nodes has to become the parent of the other, this collision of intentions starts a process called “root contention.” This starts with both nodes withdrawing their parent_notify signals, as shown in Figure E.5.
Figure E.5—Parent handshake and start of root contention e)
Each competing node then starts a timer, with the time being one of two values chosen randomly. When the timer expires, each node checks the status of its contending port; the contending port will now either be idle or receiving a parent_notification signal. If the port is idle, it then sends the parent_notify signal to that port again. If the port is already receiving parent_notification, then the node will respond with child_notify. See Figure E.6.
Figure E.6—End of root contention, and new child handshake start If both nodes happen to pick the same timeout value (both long or both short), then the outcome may be another contention cycle; the two nodes can both see idle, and both again send the parent_notify
Copyright © 2008 IEEE. All rights reserved.
761
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
signal to the unresolved port. The two dueling nodes may continue cycling through the contention state until eventually one times out sooner than the other. In this example, Node D uses the shorter timeout while node B uses the longer timeout, so that Node D sends parent_notify while Node B is still waiting for its timer to expire. f)
g)
When the timer for node B expires, node B samples its proposed parent port and finds that it is receiving the parent_notify, so it labels that port as a child and ends the child handshake process (sending down the child_notify). In addition, since node B has labeled all ports as children, it takes the root function for itself. See Figure E.7.
Figure E.7—End of final child handshake and root selection When node D receives the child_notify on its parent port, it drops the child_notify being sent to its children and the parent_notify to node B, ending its parent handshake. See Figure E.8.
Figure E.8—Final parent handshake
762
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
h)
IEEE Std 1394-2008
When node B, the root, stops receiving the parent_notify, it finishes the tree identify process by withdrawing the child notify signals sent to its children. See Figure E.9.
Figure E.9—Tree identify process complete Note that the selection of the root node is not topology dependent. It is completely acceptable that the root node also be a leaf. The only requirement is that the cycle master (the isochronous cycle master described in Q.6.4) also has to be the root, since the root has the highest natural priority. The node that waits the longest after the bus reset to start participating in the tree identify process becomes the root. If, for example, node A in the previous example waited a long enough time to start the tree identify process, node B would end up sending the parent_notify to node A after step b). This would cause node A to become the root. A particular node can be forced to wait a longer time by setting its force_root bit (see 16.3.3.4).
E.3.3 Self identify process The next step is to give each node an opportunity to select a unique physical_ID and identify itself to any management entity attached to the bus. This is needed to allow low-level power management and the building of a system topology map. Subclause 7.3.3.2.1 discusses this process. Sending the self-ID information is done by transmitting one to three 8-byte packets onto the cable that includes the physical_ID and other management information as described in 16.3.3.1. The physical_ID is simply the count of the number of times a node passes through the state of receiving self-ID information before having its own opportunity to do so, i.e., the first node sending self-ID packet(s) chooses zero as its physical_ID, the second chooses one, and so on. Note that a node is not required to decode the self-ID packet; it merely has to count the number of self-identification sequences since the bus reset. The management information included in the self-ID packet includes codes for the power needed to turn on the attached link layer, the state of the various ports (unconnected, connected to child, connected to parent), and data rate limitations. The self-identify process uses a deterministic selection process, where the root node passes control of the media to the node attached to its lowest numbered connected port and waits for that node to signal that it and
Copyright © 2008 IEEE. All rights reserved.
763
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
all of its children have identified themselves. The root then passes control to its next highest port and waits for that node to finish. When the nodes attached to all the ports of the root are finished, the root itself does a self-identify process. The child nodes use the same process in a recursive manner, as is illustrated in the following example. a)
In this example, there are five nodes; one with a single port, two with two ports, one with three ports, and one with seven. In Figure E.10, the system has just finished the tree identify process. At this point, the “self_ID_count” values of all nodes are 0. The root starts the process by sending a grant to its lowest numbered unidentified port and a data_prefix to all other ports. Note that an unconnected port is automatically flagged as self-identified.
Figure E.10—Start of self-identify process b)
When a node receives the grant, it propagates it to its lowest numbered unidentified child port or, if there is no requesting child, takes the current value of the self_ID_count as its node_ID and starts sending its self-ID information (node A in Figure E.11). The start of this information is indicated by a data_prefix.
Figure E.11—First node sends self-ID information
764
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
When node B sees the data_prefix, it withdraws its grant. Meanwhile, node D has seen the data_prefix sent by node B, so it propagates the data_prefix to its children, nodes C and E. At this point the data prefixes are all pointed away from node A (Figure E.11), so it can start sending the self-ID information. This is encoded in small 32-bit packets, with the first packet containing power requirements, performance capabilities, and the status of the first four ports. Since in this example node A has 7 ports, it needs to send a second self-ID packet to identify itself fully. The first packet is terminated with the data_prefix, which holds the bus until the second packet is sent. The second packet terminates normally with a data_end. All other nodes see the normal packet termination and use that event to increment their self_ID_count. Note that the bus-holding termination of the first ID packet does not cause the self_ID_count to be incremented. Note also that all self-ID packets are sent at the base rate (98.304 Mbit/s). c)
When node A finishes sending its self-ID packets, it sends an ident_done to its parent. The parent (node B) flags that port as identified, sends a data_prefix to that port, and continues to send idle to its other ports. When node A sees data_prefix, it leaves self-ID mode and could start normal arbitration, but as long as the self-identify process continues, there will never be an idle period long enough for the PHY to request the bus. Nodes C, D, and E respond to the idle by incrementing self_ID_count. See Figure E.12.
Figure E.12—First node finishes self-identify
Copyright © 2008 IEEE. All rights reserved.
765
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
d)
IEEE STANDARD FOR A
Node B, the root, then sends a grant to its lowest numbered unidentified child port, the one connected to node D. It also sends a data_prefix to its other ports (the one connected to node A). See Figure E.13.
Figure E.13—Start of bus grant for second node self-identify e)
Node D has unidentified child ports, so it passes the grant to its lowest numbered one (node C) and sends a data_prefix to the other child ports. See Figure E.14.
Figure E.14—Finish of bus grant for second node self-identify
766
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
f)
IEEE Std 1394-2008
Node C does not have any unidentified children, so it responds by taking the value of self_ID_count as its node_ID, sending a data_prefix and a single self-ID packet as shown in Figure E.15. Only a single self-ID packet is needed since node C only has a pair of ports. As the other participating nodes see the normal termination line state at the end of the self-ID packet, they all increment their self-ID counters. Node A has already left the self-identify process; it sees all successive self-ID packets as normal receive packets.
Figure E.15—Second node self-identify g)
Node C then sends an ident_done to its parent (node D). Node D responds by labelling that port as identified, sending data_prefix on the newly identified port, and continuing to send idle on each of its other ports. See Figure E.16.
Figure E.16—Second node finishes self-identify
Copyright © 2008 IEEE. All rights reserved.
767
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
h)
IEEE STANDARD FOR A
When node B (the root) receives the idle, it sends a grant to its lowest numbered unidentified child port, the one connected to node D. It also sends a data_prefix to its other ports. This is the same process as step d) since node D has not yet signaled self-identification completion. See Figure E.17.
Figure E.17—Start of grant for third self-identify i)
When node D gets the grant, it propagates it to its lowest numbered unidentified child port (#3), which is connected to node E (see Figure E.18). Node E then gets its opportunity to send self-ID information. When it is finished, it will signal node D, which will label its port #3 as identified. Node B will send a grant down its port #2 a third time, which will finally allow node D to send its self-ID information, since all its child ports are now labeled as identified. When finished, node D will send the ident_done to node B, the root.
Figure E.18—Completion of grant for third self-identify
768
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
j)
The root will be the last node to send its self-ID information, and when it is finished, it leaves the self_ID process itself and sends idle out to all its child ports. All nodes exit the self_ID process with their fair bits cleared, so the bus will generally stay idle for the duration of an arbitration reset gap, unless an overeager node initiates a higher priority bus request. At this point (Figure E.19), each node has a unique node number and the self-ID information has been broadcast.
Figure E.19—Example cable state after self-identify phase
E.3.4 Topology construction A higher level software entity can deduce the network topology from the self-ID packets. Each port is assigned two bits of the self-ID packet; the significance of those bits is given in Table E.5.
Table E.5—Port status encoding Port status
Meaning
11
child port
10
parent port
01
unconnected port (unconn)
00
unimplemented port - i.e., port 4 of a 3 port device (noport)
Note that whether a port is “implemented” or not is a function of the PHY. For example, if a card designer provides only two connectors for a PHY IC that has three ports, then three ports will show up in the topology map, even though the user has no way of using the connectorless port. A node with more than four ports has to append a second self-ID packet; a node with more than 13 ports has to append a third; and so on. Reflecting back on the example network in the previous subclause, the pertinent data from the self-ID packets is given in Table E.6.
Copyright © 2008 IEEE. All rights reserved.
769
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table E.6—Example self-ID packet port status values phy_ID
port 1
port 2
port 3
port 4
port 5
port 6
port 7
ports 8:16
00
parent
unconn
unconn
unconn
unconn
unconn
unconn
noport
01
unconn
parent
noport
—
—
—
—
—
02
parent
noport
noport
—
—
—
—
—
03
parent
child
child
—
—
—
—
—
04
child
child
noport
—
—
—
—
—
a)
The node A (phy_ID 0) packet represents a seven-port PHY, with a parent connection on port 1 and no other connections. Thus, it is a leaf node.
b)
The node C (phy_ID 1) packet represents a two-port PHY, with a parent connection on port 2 and no other connections. This is also a leaf node.
c)
The node E (phy_ID 2) packet represents a single-port PHY, which by definition must be a leaf node. Its sole connection is a parent connection. At this point, any node receiving the self-ID packets will have complete information on the three leaves, nodes A, D, and E, as shown in Figure E.20.
Figure E.20—Topology information after identification of leaf nodes d)
The node C (phy_ID 3) packet represents a three-port node with all three ports connected. Port 1 is the parent port; ports 2 and 3 are child ports. Which of the previous branches and/or leaves connect to these child ports? Remember that during the self-identify process, a node receiving a bus grant passes the grant down to its highest numbered child port last. So port 3 must connect to node E (phy_ID 2), and port 2 must connect to node D (phy_ID 1). This is shown in Figure E.21.
Figure E.21—Topology information after identification of first branch node
770
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
In general, as the reconstruction process proceeds, there will always be a supply of branches and/or leaves. These pieces can be ranked according to the node-IDs of the node having the “open” parent port (“open” meaning not yet reconstructed by the topology mapping software). The highest ranking branch and/or leaf, i.e., the one with the highest node-ID numbered parent port, is the one that must be connected to the highest numbered next-available child port. e)
The node B (phy_ID 4) packet represents a two-port PHY with both ports being child ports. So this must be the root, and it must be the last self-ID packet. Again, the higher numbered port must be connected to higher ranked branch and/or leaf; port 2 must connect to node C (phy_ID 3), and port 1 must connect to node A (phy_ID 0). The final topology would look like Figure E.22.
Figure E.22—Topology information after identification of root node
Copyright © 2008 IEEE. All rights reserved.
771
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
772
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex F (normative)
Backplane physical implementation example This annex describes how the PHY of the serial bus may be implemented in the backplane environment. These descriptions illustrate possible implementations of the serial bus within given application environments, and are intended to be informative. F.1 addresses the media signal interface between the parallel backplane and the serial bus. This description includes signal and pin assignments that may be used to implement a serial bus on certain standard backplanes. F.2 describes an interface between the serial bus PHY and link layers, as well as the logical components within the PHY layer. It is intended as a guide for the design of the logic required to implement the PHY layer.
F.1 Standardized parallel bus implementations An example of a serial bus implementation within the backplane environment is shown in Figure F.1. In this example, the two signals used for the serial bus accompany a number of signals that make up a standardized parallel backplane bus.
Figure F.1—Typical application of serial bus in the backplane environment
Copyright © 2008 IEEE. All rights reserved.
773
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The media signal interface of the serial bus is similar to that of the parallel bus. Transceivers, terminations, connectors, and other components of the media signal interface are the same as those used for the control lines of the host parallel bus. The host bus provides the requirements for signal transmission, mechanical arrangement of modules, and the environmental conditions over which operation of the bus is guaranteed. In order to minimize the single points of failure between the two buses in this example, the serial bus is kept functionally separate (and logically distinct) from the host bus. In such an implementation, a serial bus node may have a different address than a node on the host bus even though they exist on the same physical module. Also, nodes on the serial bus may not respond to the system reset or bus initialization process signals of the host. Nonetheless, design requirements may make it advantageous to have the serial bus node directly access the CSRs of the host bus, and vice versa. A serial bus may be used to interface to an IEEE 1149.1 (JTAG) test access port or other test control logic on a module. This implementation of a serial bus as a test and maintenance (TM) bus provides a path for failure data to be captured via a module stress/error history log. It can also be used to initiate extended diagnostics, either internally or from a remote source, and can be used to download the stress/error log to facilitate repair. As a result, faults on the host bus can be isolated to the module or the bus level. Table F.1 describes how a serial bus may be implemented on certain backplanes. Although this table only addresses IEEE 896 (Futurebus+) and ANSI VME64, other potential applications include (but are not limited to) IEEE 960 (Fastbus), IEEE 1196 (NuBus®),29 and IEEE 1296 (MULTIBUS II). Each of these parallel buses reserves two backplane signals for the implementation of a serial bus. Table F.1 assigns these lines to the two signals used for a serial bus: DATA and STRB.
Table F.1—Serial bus signal mapping and pin assignment Futurebus+ Profiles A, B, F, M, and T
Serial bus Signal
Signal
Pin assignment
VME64 Signal
Pin assignment
DATA
SB0
B a 15
SERB
P1/J1 b22
STRB
SB1
B c 15
SERA
P1/J1 b21
NOTE—Futurebus+ Profile M uses this pin assignment for MIL-12SU modules. MIL-10SU and MIL-Format E modules assign SB0 to “C a 39” and SB 1 to “C d 39.”
It should be noted that at the time this standard was approved, Futurebus+ profiles M and T require that SB0 and SB1 be reserved for the implementation of IEEE 1394 serial bus. Futurebus+ profiles A, B, and F reserve these Dines for an optional serial bus, but do not require IEEE 1394 serial bus specifically (i.e., they merely indicate a preference for IEEE 1394 serial bus). VME64 reserves the SERA and SERB lines (formerly referred to as SERCLK and SERDAT*, respectively, in the IEEE 1014 VME Specification) for a serial bus, but it does not require IEEE 1394 serial bus specifically.
29NuBus is a registered trademark of Texas Instruments, Inc. This information is given for the convenience of users of this standard and
does not constitute an endorsement by the IEEE of these products. Equivalent products may be used if they can be shown to lead to the same results.
774
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
F.2 PHY implementation F.2.1 PHY layer overview The serial bus backplane PHY layer has three primary functions: transmission and reception of packets, arbitration, and provision for an electrical/mechanical interface. Figure F.2 describes the interaction between the PHY layer, the link layer, and other components within a node implementing a serial bus. These components are described in the following subclauses. Functions of the link layer are performed by “link logic.” Functions of the PHY layer (except for the clock and transceivers) are performed by “PHY logic.”
Figure F.2—Link/PHY interface F.2.1.1 Serial bus PHY logic The transceivers and the bus to which they are connected make up the electrical/mechanical interface of the serial bus. Other functions of the PHY layer (e.g., arbitration and packet transmission/reception) are performed within the backplane PHY logic and are described in F.2.2.
F.2.1.2 Serial bus link logic The serial bus link layer provides acknowledged one-way data transfer services. It responds to read/write/ lock requests from the upper layers of a serial bus node, and it prepares packets for transmission through the PHY layer and onto the serial bus. The link layer also responds to changes in the state of the serial bus (i.e., received data) as indicated by the PHY logic. The functions of the link logic include addressing, error checking, and data framing (i.e., within a packet).
F.2.1.3 Backplane transceivers Transceivers may be packaged separately from the PHY logic so that transceivers implementing different technologies can be used. Bidirectional signals, DATA and STRB, go to and from the transceivers and into the PHY logic as unidirectional signals. The type of transceiver that is used determines the packet transmission rate on the serial bus. Transceivers using BTL or ECL transmit and receive at 49.152 MB/s. Transceivers using enhanced transceiver logic (ETL) operate at 24.576 MB/s.
Copyright © 2008 IEEE. All rights reserved.
775
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
F.2.1.4 Local clock A local clock (Clk) is used for the sychronization of state machines within the PHY logic. The frequency of this clock is 49.152 MHz (± 100 ppm), regardless if data are transmitted at 49.152 MB/s or 24.576 MB/s.
F.2.2 High-level PHY logic description Figure F.3 provides a high-level description of the backplane PHY logic. The components within this diagram are described in the following subclauses.
Figure F.3—PHY logic block diagram F.2.2.1 LINK/PHY interface controller This module provides much on the interface between the backplane PHY and the upper layers within the node, particularly the link layer. The protocol used in this interface is defined within Clause 17. Information is transmitted bidirectionally between the link and the PHY on Data[0:l] and Ctl[0:l]. In addition, LReq is used to transmit requests unidirectionally from the link to the PHY. There are four basic operations that can occur between the link and the PHY: request, status, transmit, and receive. All but requests are initiated by the PHY. The link uses the request operation to read or write an internal PHY register or to request the PHY to initiate a transmit action. The PHY initiates a receive action whenever a packet is received from the serial bus. The PHY initiates a status action when the status of the serial bus changes. To request the bus or access a PHY register, the link sends a short serial stream to the PHY on the LReq line. The information sent includes the type of request (read/write register or transmit packet). If the request is to
776
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
read or write a register within the PHY, this serial stream also includes the address of the register and the data to be written to the register (for a write action). If the request is to transmit a packet, this serial stream also includes the type (fair, urgent, isochronous, cycle master, or acknowledge) and priority of the request (a 4-bit field used for urgent requests). The format of this serial bit stream is described within Clause 17. The data and control buses are both 2-bit bidirectional buses. The control bus (Ctl[0:l]) indicates the status of the data bus, as it is defined in Clause 17. The data bus (Data[0: 1]) is used to transmit packet data between the link and the PHY, or to transmit register information from the PHY to the link (allowing access to registers that are used within the PHY layer). The interface module regulates the transfer rate of these buses using Serial Clock (SCLK) indications. For packet data transfers, the rate at which SCLK indications are given to the link layer determines the transmission rate on the serial bus. Since PHY-link transfers occur two bits at a time, SCLK is used to clock the transfer rate at one-half of the bus data rate. Therefore, for backplanes with a bus data rate of 49.152 MHz, SCLK would be used to clock PHY-link transfers at 24.756 MHz. For backplanes with a bus data rate of 24.756 MHz, SCLK would be used to clock PHY-link transfers at 12.288 MHz. The state of TxSpeed could be used to determine the rate of SCLK, allowing the PHY layer to be configured for a particular transmission rate.
F.2.2.2 Arbitration controller This module controls access onto the serial bus. It performs the arbitration process and enables packet transmission onto the serial bus. Requests for a transmit action on the serial bus are received from the PHY-link interface. These requests are received on one of the following lines: Fair/UrgReq, IsoReq, CycleReq, or AckReq. When a request is received on Fair/UrgReq, the type of request, as well as the priority, is indicated by the status of the priority lines, Pri[0:3]. If the status of the priority lines is all zeros, then the request is fair. If the priority lines are not all zero, then these lines indicate the priority level of an urgent transfer. The priority level of all ones (the highest priority) is reserved for cycle start requests, which are requested with CycleReq. Requests on IsoReq and AckReq indicate requests for isochronous transfers or acknowledges, respectively. When one of these requests occur, arbitration begins after an appropriate “gap time.” Different requests allow arbitration to begin after different “gap times” have occurred (e.g., an ArbResGap, a SubactGap, or an AckGap), allowing nodes with particular requests to begin arbitrating for the bus before other nodes. When a request for a transmit action is received, the controller samples the bus (RxStrb and RxData) in order to determine if the bus is idle and when the appropriate time to begin the arbitration sequence will be. The arbitration controller then asserts ArbStrb while transmitting the arbitration sequence on ArbData. The arbitration sequence incorporates the physical_ID and, if appropriate, the priority level indicated by Pri[0:3]. Timing for transmission and sampling of the arbitration sequence during the arbitration process is also controlled by the arbitration controller. Once a bit of the arbitration sequence has been put on the bus for a certain amount of time, the controller samples the bus to determine if another node with a greater arbitration sequence is also arbitrating for the bus. If so, the controller backs out of the arbitration contest until the next opportunity. If the arbitration controller is able to complete its entire arbitration sequence successfully, it controls the bus. The controller asserts ArbWon or ArbLost to indicate the outcome of the contest. Once the arbitration controller successfully completes an arbitration contest, it immediately asserts the data_prefix symbol on DataTx and StrbTx. After data_prefix is transmitted for a certain amount of time (see 5.4.2.1), the arbitration controller asserts ArbWon. The data_prefix symbol is transmitted long enough so that the data resync/decode modules on other nodes can distinguish the arbitration sequence from the beginning of a data packet.
Copyright © 2008 IEEE. All rights reserved.
777
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
F.2.2.3 Data encode The data encode module encodes the bits to be transmitted, one at a time, using a Data/Strobe encoding mechanism. Data propagates from the data encode module as DataTx. It is accompanied by a strobe signal, StrbTx. The data encode module causes the strobe signal to change state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on one of the two signals. At the end of a packet, the data encode module receives a data_end symbol from the PHY-link interface controller. This causes the data encode module to assert the data_end symbol on DataTx and StrbTx for a certain amount of time (see 5.4.2.1) before releasing the bus. The transitions used to release the bus are described in 5.4.2.1. The receipt of a data end symbol also indicates that SCLK shall no longer be generated.
F.2.2.4 Arb/data multiplexer This module receives the DataTx and StrbTx signals from the data encode module and the ArbData and ArbStrb signals from the arbitration controller module. The arb/data mux module essentially combines the output from these other modules, allowing either module to assert the backplane.
F.2.2.5 Data resync/decode Once DataRx and StrbRx signals are received from the bus, they are synchronized to the local clock and decoded by the data resync/decode module. As a packet is received, a clock that transitions every bit period can be extracted by performing an exclusive OR or of DataRx and StrbRx. The rationale for using this “DS” bit-level encoding mechanism is to improve the transmission characteristics of data packets across the serial bus. In particular, the code ensures that transitions occurring on DataRx and StrbRx are approximately one bit period apart. This results in an increase in skew tolerance that could not be obtained with a clocked NRZ format.
778
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex G (normative)
Backplane IRM selection G.1 Backplane configuration management In a basic backplane application, an IRM is not required. Upon power-up, all nodes on the bus are ready to arbitrate for asynchronous transfers. If isochronous services are to be supported, it is necessary (in most cases) that a node on the bus perform the function of IRM. It is also necessary that some node perform the function of cycle master.
G.2 IRM selection process Although an example of an IRM selection process is described in G.3, a particular selection process is not specified within this standard. The IRM selection process is to be defined by the application environment. NOTE—One example for this reasoning is as follows: a particular parallel bus that supports the serial bus as a test/ maintenance bus may require all of the SBM functions to exist on the module that is responsible for the monarch functions on the parallel bus. Yet another parallel bus that supports the serial bus as an alternate access path may require, for survivability reasons, that a module shall never perform management functions for both the serial bus and the host bus.
It is recommended that the selection mechanism support the following two criteria: that there can only be one IRM and that the selection process should be deterministic (i.e., repeatable, for debugging purposes).
G.3 Example of an IRM selection process This subclause describes examples of processes that may be used to select the IRM on a serial bus in the backplane environment. These examples are intended to be informative. The first assumes that an IRM is to be selected from one or more nodes on a bus. The second assumes that an IRM is not to be designated at all.
G.3.1 IRM-capable node environment This example designates one node to be the IRM and establishes this node as the “well-known” address of the BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers. It requires that such a node be capable of functioning as cycle master. a)
After a reset event, all nodes that have the irmc (isochronous resource manager capable) and the cmc (cycle master capable) bits set within their Bus_info_Block shall set their BUS_MANAGER_ID.bus_mngr_id field to 3F16.
b)
Each of these nodes shall examine the irmc and cmc bits within the Bus_info_Block of other nodes on the bus, beginning at the location with the largest physical_ID (this may be 62 if the largest “occupied” location is not known).
c)
If a node is present at a location that has a physical_ID larger than that of the requesting node, and if the irmc and cmc (cycle master capable) bits are set within the Bus_Info_Block of this node, then the requesting node shall recognize this node to be the IRM and exit from the IRM selection process.
Copyright © 2008 IEEE. All rights reserved.
779
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
d)
IEEE STANDARD FOR A
If the physical_ID of the addressed node is equal to that of the requesting node, then the node recognizes itself to be the IRM and sets the BUS_MANAGER_ID.bus_mngr_id field to its own physical_ID.
Note that in a fault-tolerant environment, a mechanism has to exist to exclude a failed IRM-capable node from the selection process.
G.3.2 Non-IRM environment It is possible that an environment may allow for isochronous resources to be allocated without the use of an IRM. In such a case, each node on the bus may have “a priori” knowledge of its own isochronous bandwidth and channel allocations. NOTE—Such a scenario would still require the presence of a cycle master (whose identity could be “pre-ordained” as well).
780
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex H (normative)
Serial bus configuration in the cable environment This annex provides examples of typical serial bus configuration procedures. The operations described in this annex are intended to assist the reader in understanding the formal definitions of SBM present in Clause 8.
H.1 Bus configuration timeline Subclause 8.4.2 gives a step-by-step narration of the events necessary to reconfigure a serial bus in the cable environment after a bus reset. The description that follows attempts to show the time relationships between these phases of bus configuration, many of which can proceed concurrently with other phases. In Figure H.1, time commences at the left at the time the bus reset is initiated.
Figure H.1—Bus configuration timeline In Figure H.1, both the tree identify and the self-identify processes must complete before any of the other reconfiguration steps. At point A, all the self-ID packets have been generated and observed, and the following statements are true: a)
Asynchronous transactions may commence
b)
The identity of the IRM (if any) is known
c)
The previous cycle master, if still the root, may resume broadcast of cycle start packets
d)
Isochronous data streams may resume as soon as a cycle start packet is observed
e)
The incumbent bus manager (if any) may reestablish itself as the bus manager
f)
All owners of bus resources prior to the bus reset are required to reallocate the resources
At 125 ms after the self-identify process has completed, candidates for bus manager that were not incumbent may attempt to establish themselves as the bus manager. Very shortly after this point in time, a bus manager is active, whether or not it was the incumbent.
Copyright © 2008 IEEE. All rights reserved.
781
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
At point B, the IRM may examine its own BUS_MANAGER_ID register to determine whether or not a bus manager is active. At this point in time, the following are true: — All prior isochronous resources have been reallocated — The bus manager has made the TOPOLOGY_MAP registers available If the IRM discovered, at point B, that no bus manager is active, it is permitted to engage in some forms of bus management, e.g., the activation of a cycle master, transmission of link-on packets to unpowered nodes and, optionally, a rudimentary form of gap count optimization. Lastly, at point C a second has elapsed, and nodes that wish to allocate new isochronous resources are permitted to do so.
H.2 Bus configuration scenarios Subclause 8.5 describes state machines that shall be implemented at bus-manager-capable, cycle-mastercapable, and IRM-capable nodes. These state machines are sufficient to govern the process of selection of a bus manager, cycle master, or IRM after a serial bus reset in the cable environment. However, the overall picture of bus configuration is difficult to perceive from the limited vantage point of the state machines of a single node. This subclause remedies the problem through scenarios that illustrate typical serial bus configuration procedures. The salient points are —
Selection of a root
—
Selection of an IRM
—
Selection of a bus manager
—
Designation of a new root (in order to activate a cycle master)
—
Reconfiguration after a second bus reset (in order to confirm the new root)
—
Allocation of isochronous resources and commencement of isochronous operations
—
Insertion of a new node (and the bus reconfiguration it forces)
—
Resumption of isochronous operations
H.2.1 Bus configuration with a bus manager and an IRM Figure H.2 shows the configuration determined after a bus reset for an arbitrary serial bus configuration. The physical_ID assigned to each node is shown at the top of the box that represents the node. The node capabilities are shown abbreviated to the right, e.g., irmc represents isochronous resource manager capable. Each of the PHY ports of the node are arbitrarily numbered. In addition, each node has a description, such as DVCR, printer, or SBP Disk 1, which is not essential to the example but helps anchor the scenario as a possible real-life example. After a bus reset, the root is first determined by the tree identify process described in E.3.2. Note that the resolution of node five versus node six as the root is arbitrary. Both nodes would have attempted to send a parent_notify signal at the same point in time. After detection of the collision, the node that prevails as the root is dependent upon the random back-off timers used to resolve the impasse.
782
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure H.2—Bus configuration example (after power-on) The node selected as the root in this example has its link layer powered off. This does not prevent its function as the root, but it does make any other capabilities that might reside in the inactive link and transaction layers (bus manager, cycle master, or IRM) unavailable. Because a cycle master is needed for isochronous operations, the fact that the link layer of the root is inactive eventually precipitates another bus reset, as described in the following paragraphs. The self-identify process that immediately follows the tree identify process assigns physical_IDs to all nodes and determines which node becomes the IRM. Nodes 2 and 5 transmit self-ID packets with both the l and the c bits set. This indicates that both are contenders for the role of IRM. Node 5 has the highest physical_ID and is confirmed as the IRM. Assume that this is the first bus reset after the serial bus nodes have been powered, i.e., there is no incumbent bus manager. As soon as the self-identify process is complete, bus-manager-capable nodes whose Incumbent variable is TRUE are eligible to contend for that role. Since none are incumbent, 125 ms shall elapse before node 2 attempts a compare and swap transaction to place its own physical_ID into the BUS_MANAGER_ID register at node 5, the IRM. Node 2 succeeds and obtains the role of bus manager. One of the first obligations of a bus manager is to activate a cycle master if a serial bus is configured for isochronous operations. The serial bus standard places no explicit requirements on the bus manager as to what circumstances require a cycle master, but it is expected that the bus manager shall activate a cycle master if it detects at least two isochronous-capable nodes. The bus manager is expected to examine the isc bit in the Bus_Info_Block of all nodes to determine how many isochronous-capable nodes are present. In this case, nodes 2, 3, 4, and 5 are isochronous capable.
Copyright © 2008 IEEE. All rights reserved.
783
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The bus manager cannot activate the root as the cycle master since the link layer is inactive. The bus manager might transmit a link-on packet to activate the link layer of the root and then examine the Bus_Info_Block, but the simple, expected solution is to transmit a PHY configuration packet to cause node 5 to set its Force Root variable to TRUE. The bus manager resets the bus after the PHY configuration packet is broadcast. NOTE—The bus manager may optionally set a new gap count in the PHY configuration packet in order to optimize performance on the bus. This shortcut may be taken since no topology change is expected in connection with this bus reset.
Figure H.3 shows the resultant serial bus configuration after the reset.
Figure H.3—Bus configuration example (after force root and reset) Because its Force Root variable was TRUE, node 6 has become the root. The same node that was the IRM before the bus reset remains the IRM, although its physical_ID has changed. Similarly, node 2, the incumbent bus manager, remains the bus manager. However, because node 2 is incumbent before the bus reset it need not wait 125 ms after the self-identify process before it attempts a compare and swap transaction to the BUS_MANAGER_ID register. Assume that an application at the computer wishes to record video data from the camera on the digital VCR. First, the application allocates the necessary bandwidth and a channel from the BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers at the IRM. Although the application is not to be either the talker or the listener, it is now the owner of these isochronous resources. At this point, the application may write the appropriate series of commands to the camera CSRs to cause it to start talking on the selected channel and another series of commands to the digital VCR CSRs to cause it
784
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
to listen. Isochronous operations continue from this point without further intervention by the application at the computer. As soon as the bus manager is selected, it sets the cmstr bit in the STATE_CLEAR register of the root, node 6. This permits isochronous operations to commence with the first broadcast of a cycle start packet by the cycle master. Subsequent to the activation of the cycle master, the bus manager analyzes the self-ID packets received during the self-identify process and makes the SPEED_MAP and TOPOLOGY_MAP registers available. The bus manager may also perform gap count optimization (not described for this example) or power management. In this example, the power requirements of node 6 are less than the power available on the serial bus; therefore, the bus manager transmits a link-on packet to node 6. This reveals node 3 to be a television monitor, another isochronous-capable device. The last part of this example shows the effects of a node insertion on the bus. The preceding figure shows a not-yet-connected device, a second digital DVCR, available to be added to the unused PHY port of the digital TV. The new serial bus configuration that results is shown in Figure H.4.
Figure H.4—Bus configuration example (after new node insertion and reset) Very little of significance changes after the bus reset caused by the insertion of the new node. Physical_IDs are reassigned, of course, but the same devices that were the bus manager, cycle master, and IRM prior to the bus reset retain their functions. The cycle master resumes broadcast of cycle start packets immediately upon completion of the self-identify process. This permits the resumption of isochronous data flow from the digital camera (the talker) to the digital VCR (the listener) as soon as possible. The owner of the isochronous
Copyright © 2008 IEEE. All rights reserved.
785
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
resources (the computer) reallocates both bandwidth and channel number at the IRM BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers as soon as the self-identify process completes. If any new isochronous operations were to commence, e.g., playback from the second digital VCR to the TV monitor, 1 s would have to elapse before these new isochronous resources could be allocated. This completes the example of serial bus configuration when both a bus manager and IRM are present. H.2.2 gives an example of another topology without any bus-manager-capable nodes.
H.2.2 Bus configuration with only an IRM Figure H.5 shows the configuration determined after a bus reset for an arbitrary serial bus configuration without any bus-manager-capable nodes. The physical_ID assigned to each node is shown at the top of the box that represents the node. The node capabilities are shown abbreviated to the right, e.g., irmc represents isochronous resource manager capable. Each of the PHY ports of the node are arbitrarily numbered. In addition, each node has a description, such as DVCR, printer, or camcorder, which is not essential to the example but helps anchor the scenario as a possible real-life example.
Figure H.5—IRM-only bus configuration example (after power-on) After a bus reset, the root is first determined by the tree identify process described in E.3.2. Note that the resolution of node 1 versus node 3 as the root is arbitrary. Both nodes would have attempted to send a parent_notify signal at the same point in time. After detection of the collision, the node that prevails as the root is dependent upon the random back-off timers used to resolve the impasse. The self-identify process that immediately follows the tree identify process assigns physical_IDs to all nodes and determines which node becomes the IRM. Nodes 1 and 3 transmit self-ID packets with both the l and the c bits set. This indicates that both are contenders for the role of IRM. Node 3 has the highest physical_ID and is confirmed as the IRM.
786
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Because no bus-manager-capable nodes are present, the isochronous resource assumes some of the functions that would otherwise be the province of the bus manager. The IRM shall wait 625 ms before it examines its own BUS_MANAGER_ID register to determine that no bus manager is present. At this point, the IRM shall activate a cycle master. The expected, simple implementation is that the IRM activates itself as the cycle master if it is the root. The IRM may also transmit link-on packets to any serial bus nodes with unpowered link layers. Figure H.6 shows the resultant serial bus configuration after the IRM has transmitted a link-on packet to node 0. This reveals the node to be another isochronous capable node, a digital TV.
Figure H.6—IRM-only bus configuration example (after link-on to node 0) Assume that a user wishes to play video data from the camcorder on the digital TV by means of external controls on both devices. In simple consumer applications such as this, the devices may assume that a fixed isochronous channel is always used. If this is the case, there might be no allocation of isochronous resources, the camcorder starts talking in response to external controls and the TV starts listening in the same fashion. This completes the example of serial bus configuration when no bus manager is present.
H.3 Combined bus manager and IRM Although the examples of H.2.1 and H.2.2 show the bus manager and IRM as distinct nodes on the serial bus, there is no prohibition of a node assuming both roles. The functions of bus manager and IRM are distinct, and any node that is both bus manager capable and IRM capable shall implement both sets of state machines described in 8.5.2 and 8.5.3. The state machines shall operate independently but shall share information by means of the node variables described in 8.3.3. In practice, it is a simple matter for a single node to become both the bus manager and the IRM. If a busmanager-capable node becomes the bus manager but it is not the IRM, it need only set the Force Root
Copyright © 2008 IEEE. All rights reserved.
787
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
variable to TRUE and issue a bus reset. Since the bus manager is both the incumbent and is destined to become the root (the node with the highest physical_ID), it therefore will assume the roles of both the bus manager and the IRM in the configuration process that follows the bus reset. NOTE—It is not required but it is likely that many bus manager implementations choose, for the sake of their own simplicity, to assume the role of IRM as well as bus manager.
H.4 Abdication by the bus manager In a serial bus configuration that includes more than one bus-manager-capable node, it may be the case that the node that is confirmed as the bus manager is, for some reason, not the most suitable choice. Whatever the means are that are used to determine the “most suitable choice” for bus manager are beyond the scope of this standard. The existence of some higher level protocol that bus-manager-capable nodes or bus management applications use to determine the most suitable bus manager is simply assumed to exist. However, once it is determined, by whatever means, that the role of bus manager shall be shifted from the current bus manager to some other bus-manager-capable node, there shall be an orderly way to transfer bus management responsibility. One method is for the current bus manager to communicate to the favored bus manager candidate that it should “cheat” in the next bus configuration process. That is, the favored candidate is informed that it may set its Incumbent variable to TRUE even though it is not the incumbent. The bus manager that is to abdicate shall, of course, set its own Incumbent variable to FALSE even though it is the incumbent. If the bus manager then initiates a bus reset, the favored candidate shall become the new bus manager, since it will be the first to attempt a compare and swap transaction to the BUS_MANAGER_ID register.
788
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Annex I (normative)
Socket PCB terminal patterns and mounting I.1 Socket orientation A socket may be mounted in a variety of ways to suit the application. It is recommended that the socket orientation relative to the normal positioning of the unit be standardized according to Figure I.1.
Figure I.1—Socket orientations
I.2 PCB mounting 0 A socket may be attached to a PCB in a variety of ways to suit the application. Table I.1 illustrates a number of possibilities. The first column shows how the socket may be mounted on either side of, or straddling, the PCB. The second column designates the style of mounting. Column 3 designates the figure that describes, in detail, the hole and pad pattern for each mounting designation for use with through-hole soldering to the PCB. Column 4 designates the figure that describes, in detail, the hole and pad pattern for each mounting designation for use with SMT, reflow-soldered socket terminals. The dimension “h” has a nominal tolerance of ± 0.20 mm, and the PC board thickness is presumed to be 1.6 mm nominal unless otherwise specified in the specific pattern figure.
Copyright © 2008 IEEE. All rights reserved.
789
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table I.1—Table of socket PCB mounting styles and footprint figures Mounting orientation
Mounting designation
Through-hole mounting
Right-angle upright
Figure I.2 h = 6.25 mm
Right-angle upright inverted
Figure I.3 h = 6.25 mm
Surface mounting
Right-angle flat
Figure I.4 h = 4.50 mm or h = 6.35 mm
Right-angle flat inverted
Figure I.5 h = 4.50 mm or h = 6.35 mm
Right-angle flat straddle
Straight (perpendicular)
790
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure I.2—Right-angle upright through-hole mount
Copyright © 2008 IEEE. All rights reserved.
791
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure I.3—Right-angle upright through-hole mount (inverted)
792
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure I.4—Right-angle flat surface mount
Copyright © 2008 IEEE. All rights reserved.
793
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure I.5—Right-angle flat surface mount (inverted)
794
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex J (normative)
Transaction integrity safeguards Because a serial bus may be connected to external gateways (such as cable network interface units) that may be reprogrammable from a remote location, there is a desire to provide building blocks upon which more tamper-resistant systems may be constructed. In particular it is important for serial bus modules to possess unforgeable identities and to not be able to snoop asynchronous request or response packets addressed to other nodes. A module compliant with this standard shall meet the following requirements at the time of manufacture: a)
If a node’s unique ID, EUI-64, is read from the configuration ROM bus information block by quadlet read requests, the value returned shall be the EUI-64 assigned by the manufacturer. In particular, the EUI-64 so returned shall not be alterable by software.
b)
A node shall not originate an asynchronous request or response packet with a source_ID field that is not equal to either
c)
1)
The 16 MSBs of the node’s NODE_IDS register, or
2)
The concatenation of 3FF16 and the physical_ID assigned to the node’s PHY during the selfidentify process.
A node’s link shall not receive nor make available to the transaction layer or any other application layer an asynchronous request or response packet unless the destination_ID field is equal to either 1)
The concatenation of the 10 MSBs of the node’s NODE_IDS register and either the physical_ID assigned to the node’s PHY during the self-identify process or 3F16, or
2)
The concatenation of 3FF16 and either the physical_ID assigned to the node’s PHY during the self-identify process or 3F16.
Devices that implement IEEE Std 1394.1 are exempt from item b) and item c) above.
Copyright © 2008 IEEE. All rights reserved.
795
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
796
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex K (normative)
Serial bus cable assembly test procedures K.1 Scope This annex describes a set of test procedures that attempts to characterize completely the electrical performance of the serial bus cable assembly. The tests are intended to provide results of maximum relevance to the system implementor. Toward this goal, the procedures presented in this annex provide an “end to end” characterization of the serial bus cable and connector system. This includes the cable itself, two cable assembled plugs, two PCB assembled sockets, and a length of controlled impedance PCB traces relevant for practical applications. While the device under test is only the cable assembly itself, the sockets and the PCB traces are included in the test fixtures. The limit specifications and the test procedures described in this annex apply to complete cable assemblies of any length. The measuring equipment listed in the following text or shown in the figures is shown for completeness and to guarantee maximum repeatability of measurements. Equipment of equal capabilities may be used, although the procedures described in this annex may have to be modified accordingly.
K.2 Test fixtures The test procedures described in this annex utilize two test fixtures -- a cable test fixture and a differential test fixture, which are described in the following subclauses.
K.2.1 Cable test fixture The cable test fixture provides the transition between a serial bus board-mounted socket (which can receive the cable assembly under test) and six 50 Ω SMA connectors (which can be connected to standard 50 Ω coaxial test equipment). The electrical diagram of such a test fixture is shown in Figure K.1. The fixture shall be constructed using a multilayer board enclosed in a metal case. The case is electrically connected to the shield of the serial bus socket and to the shield of the six SMA connectors. The serial bus socket shall be surface-mounted to the board. The four signal pins of the socket (TPA, TPA*, TPB, and TPB*) are connected to the four SMA connectors using microstrip lines with a characteristic impedance of 55Ω ± 3 Ω. The length of the connections shall be less than 50 mm. The length mismatch between any two of the four connections shall be less than 2 mm. It is important to minimize crosstalk within the fixture by using the ground plane to isolate the connections corresponding to different signal pairs. The two power pins on the serial bus socket (VP and VG) are connected to the two SMA connectors using traces with a characteristic impedance of less than 30 Ω. These traces shall be designed such as to minimize their dc resistance. The uniformity of their characteristic impedance is of a lesser significance so via holes can be used along the connection traces.
Copyright © 2008 IEEE. All rights reserved.
797
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure K.1—Cable test fixture schematic Two test fixtures are used for every cable assembly test, and their electrical performance becomes an integral part of the test results. The effect of the test fixtures upon the test results is not calibrated out during the test setup calibration. Thus, the test fixtures should be maintained in conditions representative for reasonable practical system usage. The socket shall be replaced at least every 1000 connections. The schematic diagram of the test fixture used in all the following test configuration diagrams is shown in Figure K.2.
TpA
TpA*
VP
cable test fixture
TpB
TpB*
IEEE 1394 socket
VG
Figure K.2—Test fixture graphic symbol
798
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The construction of the test fixture raises the issue of impedance matching between a pair of single-ended 50 Ω coaxial connectors and the differential mode 110 Ω serial bus signal lines. The connection traces for the signal lines located inside the test fixture are single-ended 55 Ω matched electrical length; thus, it can be assumed that there is a reasonable differential mode matching between them and the serial bus socket and cable assembly. The impedance matching problem is therefore shifted to the level of the SMA connectors, where matching circuits can be added. In order to improve accuracy, some of the tests use a minimum loss-resistive matching pad. The schematic diagram of such a pad is shown in Figure K.3.
Figure K.3—100 Ω to 110 Ω matching pad The test configurations contain also precision 20 dB attenuators, which are used to isolate the test equipment from the cable/connector mismatch. Due to the relative low level of mismatch and the isolation of the attenuator, the matching pads may be omitted at the expense of a slight increase in the frequency domain ripple. This effect can be removed by the data filtering algorithms provided by the suggested test equipment. The impedance matching pads, if utilized, are always included in the test calibration setup to eliminate their effect upon the final test result.
K.2.2 Differential test fixture The test procedures utilize two different test fixtures, one described in K.2.1 and one described in this subclause. Each provides a transition between a serial bus board-mounted socket (which may receive the cable assembly under test) and 50 Ω SMA connectors (which may be connected to standard 50 Ω coaxial test equipment). The cable test fixture specified by Figure K.1 provides an SMA connector to interface the serial bus socket pin (VG) to test equipment but does not isolate the socket shield from the fixture ground plane. A total of six SMA connectors port all socket pins to the test equipment. The differential test fixture, illustrated by Figure K.4, provides a controlled RC shunt between the socket shield and the fixture ground plane while isolating them. The equivalent RC circuit values were chosen in accordance with those depicted by Figure Q.30. Construct the fixture using a multilayer board enclosed in a metal case. Isolate the case and the five SMA connector shields from direct contact to the shield of the serial bus socket but interface through a distributed RC shunt.
Copyright © 2008 IEEE. All rights reserved.
799
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure K.4—Differential test fixture schematic The serial bus socket is surface-mounted to the board. Connect the four signal pins of the socket (TPA, TPA*, TPB, and TPB*) to the four SMA connectors using microstrip lines with a characteristic impedance of (55 ± 3) Ω. It is important that the length of the connections be less than 50 mm and that the length mismatch between any two of the four connections be less than 2 mm. Minimize crosstalk within the fixture by using the ground plane to isolate the connections corresponding to different signal pairs. Connect only one power pin on the serial bus socket (VP) to an SMA connector via a trace with a characteristic impedance of less than 30 Ω. Other power pin trace considerations remain the same as in the test fixture specified by in K.2. The differential test fixture is optimized for non-power pair crosstalk measurements and true differential impedance measurements (see the updated test procedures in K.3 and K.8). Two test fixtures of the same type are used for every cable assembly test; their electrical performance becomes an integral part of the test results. The effect of the test fixtures upon the test results is not calibrated out during the test setup. Consequently, the test fixtures should be maintained in conditions representative of reasonable practical system usage. The socket should be replaced at least every 1000 connections. The graphic symbol of the differential test fixture used in the test configuration diagrams contained in this annex is shown in Figure K.5. The construction of the test fixture raises the issue of impedance matching between a pair of single-ended 50 Ω coaxial connectors and the differential mode 110 Ω serial bus signal lines. In order to assume there is reasonable differential mode matching between the connectors and the serial bus socket and cable assembly, it is necessary for the signal line connection traces within the fixture to be single-ended 55 Ω and have matched electrical lengths. This shifts the impedance matching problem to the level of the SMA connectors, where matching circuits may be added.
800
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
TpA
TpA *
VP
differential test fixture
TpB
IEEE 1394 socket
TpB * Figure K.5—Differential test fixture graphic symbol In order to improve accuracy, some of the tests use a minimum loss-resistive matching pad. The schematic diagram of such a pad is shown by Figure K.3. The test configurations may contain precision 20 dB attenuators, which isolate the test equipment from the cable/connector mismatch. Due to the relative low level of mismatch and the isolation of the attenuator, the matching pads may be omitted at the expense of a slight increase in the frequency domain ripple. This effect may be removed by data filtering algorithms available with the suggested test equipment. If impedance matching pads are utilized, always include them in the test calibration setup to eliminate their effect upon the final test result.
K.3 Signal pairs characteristic and discrete impedance Although a complete cable assembly, including both cable and connector parts is specified, individual impedance evaluations select either cable or connector parts as a consequence of time-of-flight into the assembly. Measure the differential mode characteristic impedance for the cable section in the time domain using a single-ended TDR with an edge rate of less than 0.2 ns. The differential mode impedance value is calculated from the single-ended measurements described in K.3.1 through K.3.3. Calculate the result of each single-ended measurement as the average of the impedance measured at two points along the cable. Select these points at 1 ns and 2.5 ns along the cable from the plug closest to the launching connector. Because the TDR displays the round-trip propagation delay, make the measurements at 2 ns and 5 ns from the plug closest to the launching connector as measured by the TDR instrument. Repeat this test for both signal pairs. The differential mode discrete impedance, through the connector section, is measured in the time domain using a differential TDR with an equivalent edge rate of 0.5 ns. A differential TDR may establish an equivalent edge rate by means of a filter algorithm within its data processing software, which may permit a wide range of equivalent rise times to be evaluated.30 30 Representative TDRs of this type include the HP 54750A and Tektronix 11801B, both configured with TDR sampling heads. Selection of a 0.5 ns filter algorithm causes the differential mode impedance to be displayed directly. This information is given for the convenience of users of this standard and does not constitute an endorsement by the IEEE of these products. Equivalent products may be used if they can be shown to lead to the same results.
Copyright © 2008 IEEE. All rights reserved.
801
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Measure true differential mode impedance at three discrete points beyond the plane of signal insertion into the serial bus socket. Select these points at 50 ps, 100 ps, and 150 ps into the connector. Again, since the TDR displays the round-trip propagation delay, take the measurements at 100 ps, 200 ps, and 300 ps beyond the plane of signal insertion. Evaluate each of the three connector section impedance values individually against the range of differential impedance allowed over the defined 100 ps exception window (50–150 ps). Repeat this for both signal pairs.
K.3.1 Signal pairs impedance setup calibration—short and load This calibration should be performed as shown in Figure K.6 using the calibration algorithms built into the TDR equipment suggested (HP 54120B and HP 54121A or equivalent). External short and load calibration is not necessary for some differential TDR equipment. The appropriate equipment setup procedure should be conducted as defined by the equipment manufacturer.
Figure K.6—Signal pairs impedance measurement configuration (connector)
K.3.2 Signal pairs impedance test procedure (connector) Using the test configuration described in Figure K.6 and the connection matrix shown in Table K.1, measure the discrete differential impedances of the signal wires through the connector section at three points and compare the results to the allowed limits through the exception window.
Table K.1—Connection matrix for signal pairs impedance tests (connector)
Measured value
Fixture 1 (differential) TPA
TPA*
TPB
TPB*
Differential mode TPA (ZTPAconn)
TDR
TDR*
50 Ω
Differential mode TPB (ZTPBconn)
50 Ω
50 Ω
TDR
Fixture 2 (differential) VP
TPA
TPA*
TPB
TPB*
VP
50 Ω
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
TDR *
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
The true differential mode discrete impedance of connector signal pair TPAconn is displayed as ZTPAconn. The true differential mode discrete impedance of connector signal pair TPBconn is displayed directly as ZTPBconn. See Figure K.7.
802
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
T e k tro n ix 1 1 8 0 1 B TD R , 50 Ω , tr = 0 .5 n s
TDR
VP
T pA
TpB*
TDR* TpA* TpB
te s t fix tu re 2 d iff
te s t fix tu re 1 d iff
TpB*
DUT
VP
TpB TpA*
T pA
Figure K.7—Signal pairs impedance measurement configuration (connector)
K.3.3 Signal pairs impedance limits (connector) The test limits, for the 100 ps exception window, are ZTPAconn = (110 ± 25) Ω ZTPBconn = (110 ± 25) Ω
K.3.4 IEEE 1394 bulk serial bus cable test methodology K.3.4.1 Equipment a)
Tektronix 11802 differential TDR with SD24 sampling head or equivalent
b)
Adapters: Tektronix SIU 800 static isolation unit or equivalent
c)
Two 300 mm lengths of 50 Ω RG405 cable terminated with a four-socket computer interface
K.3.4.2 Sample 4.5 m length of cable with one end stripped back 12 mm
K.3.4.3 Method The calibration is checked to 50 Ω ± 1 Ω. The TDR delta delay is adjusted to electrically match the end of the adapter. The differential-mode characteristic impedance is checked by connecting one pair to M1 and M2 of the TDR with shield foil connected to ground. The entire cable length is displayed on the main trace, M1–M2, which displays any impedance variation in the pair. The window displays approximately the first 1.5 ns of the pair closest to the launching connector and after the connector mismatch. An average is taken using measurement mean and represented with a horizontal cursor set in Ro. This test is repeated for both signal pairs. The signal pair characteristic impedance (common mode) is measured as described in the previous paragraph, but with one pair connected to M1 and ground and the other pair connected to M2 and ground. The shields should be left floating. The entire cable length is displayed on main trace, M1–M2. The window displays first M1 then M2 with the measurement taken same as described in the previous paragraph.
K.3.4.4 Results To comply with this standard, the results of the tests in K.3.4.3 should be in accordance with 4.4.4.2.
Copyright © 2008 IEEE. All rights reserved.
803
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
K.4 Signal pairs attenuation The differential mode attenuation of the signal pairs shall be measured in the frequency domain using a network analyzer in the frequency range of 1 MHz to 500 MHz. The three frequency points (100 MHz, 200 MHz, and 400 MHz) at which the cable is measured are only coincidentally the same approximate numbers at the three bit rates. These numbers were chosen because a)
In fact, only one point is adequate in characterizing the cable. For reasonable accuracy, this test frequency point should be higher than the maximum fundamental frequency component that will be transmitted through the cable, which in this case is about 200 MHz for an S400 (393.216 Mbit/s) transmission. For relatively simple and repeatable cable measurements, this test frequency should not be too high. 400 MHz was selected because it is about double the maximum frequency and the multiplication factor becomes 2 . A higher number will make the measurements more difficult (many RF test fixtures have a 500 MHz maximum frequency limit), while a lower number will make computations more difficult (for example, if 300 MHz is chosen, calculations will need to be made using 1.5 ).
b)
The selection of the attenuation value at 400 MHz is such that the proposed cable construction will be adequate at 4.5 m under worst-case circumstances.
c)
The additional two data points (at 100 MHz and 200 MHz) are just a means of assistance. If pure skin effect cable attenuation is assumed, the attenuation numbers would be higher at 200 MHz (4.1 dB) and 100 MHz (2.9 dB), which will make the transceiver design harder. In reality, the cable attenuation is specified for the cable assembly. It contains not only the attenuation of the cable itself (the skin effect) but also the attenuation of the connectors, the effect of the wire termination, etc. These numbers change faster than the square root of frequency, and this is the reason the attenuation values are more optimistic at 100 MHz and 200 MHz.
In order to perform this measurement using a single-ended test instrument, a differential excitation is generated using a 180° splitter. The output is reconverted to single ended using a 180° combiner. It is very important for the accuracy of this measurement to maintain identical electrical length for the two branches of the differential signal path (in Figure K.8 the electrical length of the segments a, b, c, d, and e shall match the electrical length of the corresponding segments a′, b′, c′, d′, and e′; in Figure K.9 the electrical length of the segments a, b, d, e, f, and g shall match the electrical length of the corresponding segments a′, b′, d′, e′, f′, and g′). This test shall be repeated for both signal pairs. Because of the cross-connection of the two signal pairs at the two plugs, a simple way of accomplishing this goal is to maintain the test setup and to reverse the two ends of the cable. In order to represent this procedure, one plug of the assembly under test is arbitrarily labeled as “A” while the other plug is labeled as “B” in the following diagrams. The test consists of four distinct steps to be performed in the order described in the following subclauses.
K.4.1 Signal pairs attenuation setup calibration The “through” calibration shall be performed as shown in Figure K.8. The electrical characteristics of the two interconnects (labeled c and c′) between the two match pads are essential for the accuracy of this calibration. Their length shall be kept to a minimum, and the difference between their length shall be less than 1 mm. Practically, they can be implemented using two identical SMA female-to-female adaptors.
804
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure K.8—Signal pairs attenuation and velocity setup calibration The network analyzer shall use the following setup: Format
Log Mag
Sweep
Log Freq
Averaging
16
Power
6 dBm
Start
1 MHz
Stop
500 MHz
Measure
A/B
Display
Data
Move data into memory
K.4.2 ATPA The signal pair A attenuation variation with frequency shall be tested as shown in Figure K.9. Three data points shall be measured as follows: ATPA(100) is measured at 100 MHz, ATPA(200) is measured at 200 MHz, and ATPA(400) is measured at 400 MHz.
Copyright © 2008 IEEE. All rights reserved.
805
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure K.9—Signal pair attenuation and velocity measurement
K.4.3 ATPB The signal pair B attenuation variation with frequency shall be tested as shown in Figure K.9 using the reversed cable position (“TPB tests”). Three data points shall be measured as follows: ATPB(100) is measured at 100 MHz, ATPB(200) is measured at 200 MHz, and ATPB(400) is measured at 400 MHz.
806
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
K.4.4 Signal pairs attenuation limits The absolute maximum attenuation limit for the two signal twisted pairs is verified by the following relations: ATPA(100) ≤ 2.3 dB ATPA(200) ≤ 3.2 dB ATPA(400) ≤ 5.8 dB ATPB(100) ≤ 2.3 dB ATPB(200) ≤ 3.2 dB ATPB(400) ≤ 5.8 dB
K.4.5 IEEE 1394 bulk serial bus cable test methodology K.4.5.1 Equipment a)
Wiltron 610 network analyzer or equivalent
b)
Adapters: two 180° differential pulse splitters
c)
Four matching pads and four 150 mm lengths of 50 Ω RG405 cable terminated with a quick-release dip socket
K.4.5.2 Sample 4.5 m length of cable with both ends stripped back 12 mm
K.4.5.3 Method The calibration is checked from 40 MHz to 3200 MHz to the end of the matching pads. The through-line is zeroed to the socket. The differential-mode attenuation is checked by connecting one end of a pair to port 1 and the other end to port 2 (of the network analyzer) with the shield foil connected to the minus terminal. The pair is displayed using S21 in log magnitude at 5% smoothing, with markers set at 100 MHz, 200 MHz, 400 MHz, 800 MHz, 1600 MHz, and 3200 MHz. This test is repeated for both signal pairs.
K.4.5.4 Results To comply with this standard, the results of the tests in K.4.5.3 should be in accordance with 4.4.4.3.
K.5 Signal pairs velocity of propagation The differential mode velocity of propagation of the signal pairs shall be measured in the frequency domain using a vector network analyzer in the frequency range of 1 MHz to 500 MHz. The calibration and measurement setup is identical to that used for signal pairs attenuation, with exception of the network analyzer setup.
Copyright © 2008 IEEE. All rights reserved.
807
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The result of this test is directly dependent upon the length of the cable assembly under test. This length in meters is represented by “L” in the following test descriptions. This test shall be repeated for both signal pairs. Because of the cross-connection of the two signal pairs at the two plugs, a simple way of accomplishing this goal is to maintain the test setup and to reverse the two ends of the cable. In order to represent this procedure, one plug of the assembly under test is arbitrarily labeled as “A” while the other plug is labeled as “B” in the following diagrams. The test consists of four distinct steps to be performed in the order described in the following subclauses.
K.5.1 Signal pairs velocity of propagation setup calibration The “through” calibration shall be performed as shown in Figure K.8. The electrical characteristics of the two interconnects (labeled c and c′) between the two match pads are essential for the accuracy of this calibration. Their length shall be kept to a minimum, and the difference between their electrical length shall be less than 1 mm. The DUT interconnect segments labeled f, f′, g, and g′ in Figure K.8 and Figure K.9 are included in the calibration interconnects c and c′. Practically, they can be implemented using identical SMA adaptors. The network analyzer shall use the following setup (items different from the attenuation test are shown in bold type): Format
Delay
Sweep
Log Freq
Averaging
32
Smoothing aperture
5%
Power
6 dBm
Start
1 MHz
Stop
500 MHz
Measure
A/B
Display
Data
Move data into memory
K.5.2 VTPA The signal pair A velocity of propagation variation with frequency shall be tested as shown in Figure K.9. Three data points shall be measured as follows: VTPA(50) is measured at 50 MHz, VTPA(100) is measured at 100 MHz, and VTPA(200) is measured at 200 MHz. The average velocity of propagation for the signal pair A is calculated as VTPA = ( VTPA ( 50 ) + VTPA ( 100 ) + VTPA ( 200 ) ) ⁄ ( 3 ⋅ L )
808
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
K.5.3 VTPB The signal pair B velocity of propagation variation with frequency shall be tested as shown in Figure K.9 using the reversed cable position (“TPB tests”). Three data points shall be measured as follows: ATPB(50) is measured at 50 MHz, ATPB(100) is measured at 100 MHz, and ATPB(200) is measured at 200 MHz. The average velocity of propagation for the signal pair B is calculated as VTPB = ( VTPB ( 50 ) + VTPB ( 100 ) + VTPB ( 200 ) ) ⁄ ( 3 ⋅ L )
K.5.4 Signal pairs velocity of propagation limits The absolute minimum velocity of propagation limit for the two signal twisted pairs is verified by the following relations: VTPA ≤ 5.05 ns/m VTPB ≤ 5.05 ns/m
K.5.5 IEEE 1394 bulk serial bus cable test methodology (TDR) K.5.5.1 Equipment a)
Tektronix 11802 differential TDR with SD24 sampling head or equivalent
b)
Adapters: Tektronix SIU 800 static isolation unit or equivalent
c)
Two 300 mm lengths of 50 Ω RG405 cable terminated with a four-socket computer interface
K.5.5.2 Sample 4.5 m length of cable with one end stripped back 12 mm
K.5.5.3 Method The calibration is checked to 50 Ω ± 1 Ω. The TDR delta delay is adjusted to electrically match the end of the adapter. The differential-mode propagation delay is checked by connecting one pair to M1 and M2 of the TDR with shield foil connected to ground. The entire cable length is displayed on the main trace, M1–M2. The window is first set to display the launching connector, and a cursor is set at the last rise of the connector mismatch and zeroed. The window is then moved to the end of the pair, and the cursor is set directly before the first rise. This test is repeated for both signal pairs.
K.5.5.4 Results To comply with this standard, the results of the tests in K.5.5.3 should be in accordance with 4.4.4.4 and 4.4.4.5.
Copyright © 2008 IEEE. All rights reserved.
809
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
K.5.6 IEEE 1394 bulk serial bus cable test methodology (frequency sweep) K.5.6.1 Equipment a)
Wiltron 610 network analyzer or equivalent
b)
Adapters: two 180° differential pulse splitters
c)
Four matching pads and four 150 mm lengths of 50 Ω RG405 cable terminated with a quick-release dip socket
K.5.6.2 Sample 4.5 m length of cable with both ends stripped back 12 mm
K.5.6.3 Method The calibration is checked from 40 MHz to 3200 MHz to the end of the matching pads. The through-line is zeroed to the socket. The differential-mode propagation delay is checked by connecting one end of a pair to port 1 and the other end to port 2 with the shield foil connected to the minus terminal. The pair is displayed using S21 in time bandpass mode with a marker set at the end of the pair directly before the first rise. This test is repeated for both signal pairs at 100 MHz, 200 MHz, 400 MHz, 800 MHz, 1600 MHz, and 3200 MHz.
K.5.6.4 Results To comply with this standard, the results of the tests in K.5.6.3 should be in accordance with 4.4.4.4.
K.5.7 Rise and fall time Bulk cable test methodology.
K.5.7.1 Equipment a)
Tektronix 11801B differential TDR with SD24 sampling head or equivalent
b)
Hewlett Packard HP 8133A pulse generator or equivalent
c)
Adapters: two 150 Ω lengths of 50 Ω RG402 cable terminated with DB9F connectors
K.5.7.2 Sample 4.5 m length of cable with both ends stripped back 12 mm
K.5.7.3 Method The calibration is checked to 50 Ω ± 1 Ω. The TDR delta delay is adjusted to electrically match the end of the adapter. The pulse generator is set at 600 mV amplitude, 0.0 V offset, 500 MHz frequency, 31 ns pulse width, Square mode. The trigger output of the pulse generator is connected to the TDR. The rise and fall times are measured by connecting one end of the pair to output 2 of the pulse generator and the other end of pair to M1 and M2 with shield foil grounded. The first square wave is displayed in color graduated mode on the main trace, M1–M2. The vertical size should be set to fill all 10 graticules, i.e., 100%. The vertical cursors should be set to 20% and 80% so that the rise and fall times can be easily measured as the time interval between the trace moving between the 20% and 80% points and vice versa. The test is repeated for both pairs at 1000 MHz, 2000 MHz, and 3000 MHz.
810
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
K.5.7.4 .Results For consistency with this standard, the results of the tests in K.5.7.3 should be as follows: Trise < 100ps Tfall < 100ps
K.5.8 Static shield isolation (insulation resistance) Bulk cable test methodology.
K.5.8.1 Equipment a)
QuadTech 1865 insulation resistance tester or equivalent
b)
Adapters: two connecting wires, insulated to 500 V and terminated with standard banana clips
K.5.8.2 Sample 4.5 m length of cable with one end stripped back 12 mm
K.5.8.3 Method This test should be made on a well-insulated workbench. The meter is calibrated to zero. The insulation resistance is checked by three measurements wire to wire and individual wire to shield. The measurement is taken at 500 V for 1 min. This test is repeated for both signal pairs.
K.5.8.4 Results To comply with this standard, the results of the tests in K.5.8.3 should be in accordance with 4.4.4.
K.6 Signal pairs relative propagation skew The difference between the differential mode propagation delay of the two signal twisted pairs shall be measured in the frequency domain using a vector network analyzer in the frequency range of 1 MHz to 500 MHz. While the signal pairs relative skew can be calculated from the velocity of propagation measurement described in K.5, the very high accuracy required by the intended application of this cable assembly demands a separate, high-resolution test. In order to perform this measurement using a single-ended test instrument, a differential excitation is generated using a 180° splitter. The output is reconverted to single ended using a 180° combiner. It is very important for the accuracy of this measurement to maintain identical electrical length for the two branches of the differential signal path (in Figure K.10, the electrical length of the segments b1, b3, c1, c3, f1, f3, g1, and g3 shall match the electrical length of the corresponding segments b2, b4, c2, c4, f2, f4, g2, and g4; the electrical length of the segments b1, b3, c1, c3, d1, d3, e1, e3, f1, f3, g1, and g3 shall match the electrical length of the corresponding segments b2, b4, c2, c4, d2, d4, e2, e4, f2, f4, g2, and g4). The test consists of three distinct steps to be performed in the order described in the following subclauses.
Copyright © 2008 IEEE. All rights reserved.
811
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
K.6.1 Signal pairs skew setup calibration The “through” calibration shall be performed as shown in Figure K.10. The electrical characteristics of the four calibration interconnects (labeled i1, i2, i3, and i4) between the match pads are essential for the accuracy of this procedure. Their length shall be kept to a minimum, and the difference between their electrical length shall be less than 1 mm. The DUT interconnect segments labeled d1, d2, d3, d4, e1, e2, e3, and e4 in Figure K.11 are included in the calibration interconnects i1, i2, i3, and i4. Practically, they can be implemented using identical SMA adaptors.
Figure K.10—Skew setup calibration The skew is measured by comparing the signal propagation delay on the two twisted pairs. The calibration process attempts to remove the difference in electrical length between the two measurement paths. A close matching of these two paths by construction will help the setup accuracy. Accordingly, in Figure K.10, the electrical length of the connection segments marked a1, b1, b2, c1, c2, f1, f2, g1, g2, and h1 shall match the electrical length of the corresponding segments a2, b3, b4, c3, c4, f3, f4, g3, g4, and h2. Similarly, in Figure K.11, the electrical length of the connection segments marked a1, b1, b2, c1, c2, d1, d2, e1, e2, f1, f2, g1, g2, and h1 shall match the electrical length of the corresponding segments a2, b3, b4, c3, c4, d3, d4, e3, e4, f3, f4, g3, g4, and h2.
812
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The network analyzer shall use the following setup: Format Delay Sweep
Log Freq
Averaging
32
Smoothing aperture
10%
Power
6 dBm
Start
1 MHz
Stop
500 MHz
Measure
A/B
Display
Data/Memory
K.6.2 Signal pairs skew test procedure The signal pairs relative propagation skew shall be tested as shown in Figure K.11. Three data points shall be measured as follows: S(50) is measured at 50 MHz, S(100) is measured at 100 MHz, and S(200) is measured at 200 MHz. The average value for the signal pairs relative propagation skew is calculated as S = ( S ( 50 ) + S ( 100 ) + S ( 200 ) ) ⁄ 3
K.6.3 Signal pairs skew limits The absolute maximum relative propagation skew of the two signal pairs is verified by the following relation: S ≤ 400 ps
Copyright © 2008 IEEE. All rights reserved.
813
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure K.11—Skew measurement
K.7 Power pair characteristic impedance The differential mode characteristic impedance shall be measured in the time domain using a single-ended TDR with an edge rate of less than 0.1 ns. The differential mode impedance value is calculated from the three single-ended measurements described in the following subclauses. The result of each single-ended measurement is calculated as the average of the impedance measured at two points along the cable. These points are selected at 1 ns and at 2.5 ns along the cable from the plug closest to the launching connector. It should be noted that, because the TDR displays the round-trip propagation delay, the measurements shall be made at 2 ns and 5 ns from the plug closest to the launching connector as measured by the TDR instrument. This test procedure uses the same test setup described in K.3, only with a different connection matrix.
814
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
K.7.1 Power pair impedance setup calibration—short and load This calibration should be performed as shown in Figure K.6 using the calibration algorithms built into the TDR equipment.
K.7.2 Power pair impedance test procedure Using the test configuration described in Figure K.7 and the connection matrix shown in Table K-2, the various characteristic impedances of the power pair shall be measured in two points and the results averaged.
Table K-2—Connection matrix for power pair impedance tests Fixture 1
Fixture 2
Measured value VP
TPA
TPA*
TPB
TPB*
VG
Single-ended VP (ZVP)
TDR
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
Single-ended VG (ZVG)
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
Common-mode power pair (ZVPG)
TDR
50 Ω
50 Ω
50 Ω
50 Ω
VP
TPA
TPA*
TPB
TPB*
VG
•
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
TDR
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
•
TDR
•
50 Ω
50 Ω
50 Ω
50 Ω
•
ZVn(2) is measured along the cable at 2 ns from the plug connected to test fixture 1. ZVn(5) is measured along the cable at 5 ns from the plug connected to test fixture 1. ZVn is calculated as Z Vn = ( Z Vn ( 2 ) + Z Vn ( 5 ) ) ⁄ 2 “Vn” is VP, VG, or VPG. The differential mode characteristic impedance of the power pair is calculated as Z V = 4 ⋅ Z VPG ⋅ ( Z VP + Z VG ) ⁄ ( 8 ⋅ Z VPG – Z VP – Z VG ) The test limit is ZTPA ≤ 65 Ω
K.7.3 Power pair dc resistance The dc resistance of the power wires is measured with a milliohmmeter capable of “four-wire” resistance measurements. The accuracy of this measurement depends upon the connection segments labeled “a” and “b” in Figure K.12. Their length and their dc resistance shall be kept to a minimum. In a noisy environment, the
Copyright © 2008 IEEE. All rights reserved.
815
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
accuracy of this measurement can be improved by connecting the Guard terminal of the test instrument to the shield of one of the cable test fixtures. The test consists of four steps to be performed in the order described in the following subclauses.
K.7.4 DC resistance setup calibration Previous to the start of the measurement, the test instrument shall be warmed up for at least 1 h followed by a resistance auto calibration procedure (ACAL OHM). The setup calibration resistance (RCAL) shall be measured as shown in Figure K.12. It is essential to maintain a very low-resistance contact between the connection segments a and b during this measurement.
Figure K.12—Power pair dc resistance setup calibration
816
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
K.7.5 DC resistance test procedure Using the test configuration described in Figure K.13 and the connection matrix shown in Table K-3, the dc resistance of the power pair shall be measured.
Figure K.13—Power pair resistance measurement
Table K-3—Connection matrix for power pair resistance tests Fixture 1
Fixture 2
Measured value VP
TPA
TPA*
TPB
TPB*
VG
VP
TPA
TPA*
Power wire resistance (RVP)
a
•
•
•
•
•
a
•
•
Ground wire resistance (RVG)
•
•
•
•
•
b
•
•
•
TPB
TPB*
VG
•
•
•
•
•
b
K.7.6 DC resistance limits The test limits are RPV − RCAL ≤ 0.333 Ω RPG − RCAL ≤ 0.333 Ω
Copyright © 2008 IEEE. All rights reserved.
817
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
K.8 Crosstalk Measure pair-to-pair crosstalk in the frequency domain using a network analyzer in the frequency range of 1–75 MHz. NOTE—Although described as a measurement of pair-to-pair crosstalk, the test configurations are single-ended. The phrase pair-to-pair refers only to the location of the designated driven line and quiet line.
K.8.1 Crosstalk setup calibration The through calibration can be performed as shown in Figure K.14. The attenuation introduced by the calibration interconnect that replaces the DUT shall be kept to a minimum. Practically, it can be implemented using an SMA adaptor.
Figure K.14—Crosstalk setup calibration The network analyzer shall use the following setup: Format Log Mag Sweep
Log Freq
Averaging
16
Smoothing aperture
10%
Power
25 dBm
Start
1 MHz
Stop
500 MHz
Measure
A/B
Display
Data
Move data into memory
818
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
K.8.2 Crosstalk test procedure (between power and signal pairs) Using the test configuration described in Figure K.15 and the connection matrix shown in Table K-2, the crosstalk between signal pairs and between a signal pair and the power pair shall be measured.
Figure K.15—Crosstalk measurement The test fixtures referenced in Table K-4 are specified by Figure K.1.
Table K-4—Connection matrix for crosstalk tests between power and signal pairs Fixture 1
Fixture 2
Measured value VP
TPA
TPA*
TPB
TPB*
VG
VP
TPA
TPA*
TPB
TPB*
VG
Crosstalk between VP and TPA (XPA)
Out
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
50 Ω
In
50 Ω
50 Ω
50 Ω
0Ω
Crosstalk between VP and TPA* (XPA*)
Out
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
50 Ω
50 Ω
In
50 Ω
50 Ω
0Ω
Crosstalk between VP and TPB (XPB)
Out
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
50 Ω
50 Ω
50 Ω
In
50 Ω
0Ω
Copyright © 2008 IEEE. All rights reserved.
819
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table K-4—Connection matrix for crosstalk tests between power and signal pairs (continued) Fixture 1
Fixture 2
Measured value VP
TPA
TPA*
TPB
TPB*
VG
VP
TPA
TPA*
TPB
TPB*
VG
Crosstalk between VP and TPB* (XPB*)
Out
50 Ω
50 Ω
50 Ω
50 Ω
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
In
0Ω
Crosstalk between VG and TPA (XPA)
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
Out
0Ω
In
50 Ω
50 Ω
50 Ω
50 Ω
Crosstalk between VG and TPA* (XPA*)
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
Out
0Ω
50 Ω
In
50 Ω
50 Ω
50 Ω
Crosstalk between VG and TPB (XPB)
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
Out
0Ω
50 Ω
50 Ω
In
50 Ω
50 Ω
Crosstalk between VG and TPB* (XPB*)
0Ω
50 Ω
50 Ω
50 Ω
50 Ω
Out
0Ω
50 Ω
50 Ω
50 Ω
In
50 Ω
K.8.3 Crosstalk test procedure (between signal pairs) To evaluate crosstalk between the signal pairs, use the differential test fixture specified by Figure K.5. Then perform the tests described by K.8.2 but use the connection matrix shown in Table K-5.
Table K-5—Connection matrix for crosstalk tests between signal pairs Fixture 1
Fixture 2
Measured value VP
TPA
TPA*
TPB
TPB*
VP
TPA
TPA*
TPB
TPB*
Crosstalk between TPA and TPB (XAB)
0Ω
Out
50 Ω
50 Ω
50 Ω
0Ω
In
50 Ω
50 Ω
50 Ω
Crosstalk between TPA and TPB* (XAB*)
0Ω
Out
50 Ω
50 Ω
50 Ω
0Ω
50 Ω
In
50 Ω
50 Ω
Crosstalk between TPA* and TPB (XA*B)
0Ω
50 Ω
Out
50 Ω
50 Ω
0Ω
In
50 Ω
50 Ω
50 Ω
Crosstalk between TPA* and TPB* (XA*B*)
0Ω
50 Ω
Out
50 Ω
50 Ω
0Ω
50 Ω
In
50 Ω
50 Ω
K.8.4 Crosstalk limits The test limits are XAB ≤ –26 dB XAB* ≤ –26 dB XA*B ≤ –26 dB
820
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
XA*B* ≤ –26 dB XPA ≤ –26 dB XPA* ≤ –26 dB XPB ≤ –26 dB XPB* ≤ –26 dB XGA ≤ –26 dB XGA* ≤ –26 dB XGB ≤ –26 dB XGB* ≤ –26 dB
K.8.5 Crosstalk limits (between signal pairs) The test limits for crosstalk between the signal pairs are XAB ≤ –26 dB XAB* ≤ –26 dB XA*B ≤ –26 dB XA*B* ≤ –26 dB
Copyright © 2008 IEEE. All rights reserved.
821
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
822
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex L (normative)
Shielding effectiveness and transfer impedance testing L.1 Content This annex allows the transfer impedance (Zt) of electrical connectors to be determined from dc to 500 MHz. It measures the leakage of connector assemblies located between a bulkhead panel and a shielded cable.
L.2 Definitions L.2.1 connector transfer impedance (Zt): The ratio of the longitudinal voltage that appears on the outside of the connector under test to a known common-mode current impressed on the inside conductors.
L.3 Test equipment A vector or scaler network analyzer shall be used. A spectrum analyzer and tracking generator may be used if provision has been made for dividing the magnitudes of two traces (subtracting in decibels). Equipment shall be capable of generating plots directly or from magnetic media, if used. Measured results shall be reported in decibels from 1 Ω (dB=20log(Zt/(1 Ω))). More negative values represent better performance. Zero decibels is 1 Ω. Positive results represent insignificant shielding. Each 20 dB represents a ten-fold change in transfer impedance. See Figure L.1
Figure L.1—Equipment block diagram
Copyright © 2008 IEEE. All rights reserved.
823
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
L.4 Theory L.4.1 Reference measurement This technique relies on comparing two measurements that differ only in where the drive energy is placed. In the reference measurement (see Figure L.2), the RF current flows through the 1 Ω standard. The resulting voltage drives the sample on the outside, and the resulting power is measured at port 2 [or this can be measured as S21(reference)]. This voltage is equal to the voltage that would be generated if the sample had a 1 Ω transfer impedance at all frequencies. This simple resistance is made to mimic a transfer impedance. Thus, the reference measurement only includes the fixturing response when the sample is mounted in it.
Figure L.2—Reference measurement fixturing
L.4.2 Sample measurement The second measurement (sample measurement, Figure L.3) applies the same amount of incident RF power to the inside of the sample. The fixturing has exactly the same dimensions. The current from this incident power passes through the connector under test transfer impedance, producing a voltage along the length of the sample. The resulting power is measured at port 2 of Figure L.3 [or this can be measured as S21(sample)]. This measurement includes the fixturing response previously measured times the transfer impedance of the sample.
824
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure L.3—Sample measurement fixturing
L.4.3 Calculations The transfer impedance can be derived from these two measurements. The sample measurement results are divided by the reference results at each frequency (subtract decibels), leaving just the sample transfer impedance. Finally, the results are multiplied by a frequency independent correction factor. Even with identical RF drive levels, the current through the 1 Ω standard of the reference measurement will differ from the inside current of the sample measurement.
L.5 Sample preparation L.5.1 Panel-mounted connector sample The connector shall be mounted in the center of a bulkhead mounting plate (see Figure L.3). Connect all contacts as close to the bulkhead as possible. A 1-in wide copper strap shall be soldered to the bulkhead mounting plate close to the CUT. The free end should be very close to the bused panel mount connector conductors. The shield of a short probe cable shall be soldered to the strap to form a low-inductance path to the bulkhead, not the panel-mount connector shield. This connection has to be as short as possible. The center conductor shall be soldered to the bused panel-mount connector conductors. This connection should be as short as possible. The fixturing of Figure L.3 shall be assembled. Ensure that joined metal surfaces are clean for a good connection.
Copyright © 2008 IEEE. All rights reserved.
825
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
L.5.2 Measure sample Zo with TDR A sample connector shall be mounted on several inches of shielded cable. All conductors in this connector shall terminate a conductor in the cable. Mate to panel mounted connector sample fixtures in L.5.1. Use TDR to determine the voltage reflection coefficient of the mated pair. Estimate an average value if necessary. This will be used to calculate a correction factor.
L.5.3 Cable-mounted connector sample The cable on each sample shall be cut about 1 in from the rear. The outer jacket shall be removed without nicking the braid, leaving 0.2 in of outer jacket. The back braid shall be folded over the remaining outer jacket. The second foil shield shall be removed, if present. Take care to avoid stressing the connector shield braid capture region. All internal conductors shall be stripped as close to the braid as practical. All internal conductors and solder shall be twisted together. Soldered wires shall be cut to 0.1 in. A noninductive (metal film) termination resistor shall be soldered to this. This joint shall be wrapped with high-temperature insulating tape. The termination resistor shall be chosen to give a voltage reflection coefficient close to that measured in L.5.2. The joint and termination resistor shall be wrapped with copper tape. The braid shall be dressed up over the copper tape. The braid and copper tape shall be wrapped up to the free resistor lead with small-gauge hook-up wire. These shall be soldered together to prevent any RF leakage.
L.6 Procedure a)
Do a full two-port calibration if using a vector network analyzer for improved accuracy.
b)
Get a noise floor plot (L.7).
c)
Prepare panel-mounted connector sample(s) (L.5.1).
d)
Measure sample Zo (L.5.2). Note the reflection coefficient (p) for use in step h).
e)
Prepare cable-mounted samples (L.5.3).
f)
Do a reference measurement (L.4.1). Solder the electrical connection at the right so that pressure is applied at the mechanical connection at the left (the fixture connection to the mating interface). Measure S21(reference) expressed in decibels, or measure the power at the spectrum analyzer in decibels per minute. The frequency range shall include 30 MHz to 500 MHz, but may include more.
g)
Do the sample measurements (L.4.2). With the same cables, substitute the sample measurement fixturing of Figure L.2 for the reference measurement fixturing of step f) (Figure L.2). Mate the connectors under test and connect to the type “N” connector at the right. Measure S21(sample) expressed in decibels, or measure the power at the spectrum analyzer in decibels per minute while driving the sample with the same forward power (into fixture port 1, Figure L.2) as used in step f).
h)
Calculate the correction factor (CF). In decibels, it would be CF ( dB ) = 20 log ( 2 ⁄ ( 1 – p ) ) where p is the voltage reflection coefficient of the termination resistor, determined in step e) (see L.5.3)
i)
The vertical axis of the trace can now be labeled (in units of decibels-ohm): Zt (dB-Ω) = dBm (sample) − dBm (reference) + CF (dB) = S21 (sample) − S21 (reference) + CF (dB) where S21 is expressed in decibels
826
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
NOTE—The subtraction above can be done by many instruments real time. If so, the reference gradicule of the subtracted results can be assigned a value of (–1)CF(dB), which would make it equal to 0 dB Ω. A controller may do these calculations.
j)
Plot transfer impedance in log format, save plot file, and record single frequency results.
k)
Check that all points on the transfer impedance plot (trace) exceed the noise floor plot (see L.7) by at least 10 dB. Note invalid regions in the plot data.
L.7 “Noise floor” plot If the samples have very good shielding, the fixturing shielding may be inadequate or the receiver may be picking up ambient signals. Before samples are measured, some idea of this level has to be available. This shall be obtained with the noise floor plot fixturing of Figure L.4.
Figure L.4—Noise floor check fixturing The noise floor plot is obtained just like a transfer impedance measurement but with a solid panel and no connector under test. A reference measurement is first made using a wire instead of a cable-mounted sample. The sample measurement is made as in Figure L.4. The sample measurement is then divided by the reference measurement (subtract decibels). All transfer impedance data that does not exceed this ratio by at least 10 dB shall be reported as inaccurate data.
L.8 Documentation L.8.1 Plots and magnetic files a)
Company name
b)
Test number
c)
Date
Copyright © 2008 IEEE. All rights reserved.
827
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
d)
Sample identification and test conditions
e)
Correction factor in decibels, or termination resistance used
L.8.2 Test report a)
Plots, if requested (log format, including 30–500 MHz data)
b)
Single-frequency results (30 MHz and 159 MHz recommended)
c)
Noise floor plot (note any data that fails the noise floor requirement)
d)
Equipment used
e)
Termination resistor values used
L.9 Performance For the serial bus external connector, the transfer impedance values shown in Table L.1 are needed.
Table L.1—Transfer impedance performance requirements
828
Frequency
Value
30 MHz
–25 dBΩ
159 MHz
–16 dBΩ
500 MHz
–10 dBΩ
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex M (informative)
Serial bus topology considerations for power distribution (cable environment) This annex provides recommendations for the practical management of serial bus topologies with respect to power distribution. The capabilities of serial bus devices, cables used to interconnect them, and the topology of their arrangement can all affect a cable-powered device’s ability to obtain and use power. —
The path between a cable-powered device and a power source cannot be blocked by devices that do not repeat power.
—
The electrical resistance of the path cannot be so large as to reduce voltage to unusable levels.
—
A correlation between power user(s) and power provider(s) is necessary in order to budget available power.
Analysis of power distribution for a particular bus topology is based upon the electrical characteristics of the cables, connectors, and devices. These characteristics are normatively specified by this standard; for convenience of reference they are summarized as follows: a)
Power pair dc resistance. Subclause 4.2.4.6 specifies that the dc resistance of the power wires, VP and VG, is less than or equal to 0.333 Ω. This annex assumes that connector plug to socket resistance is less than or equal to 0.06 Ω for the assembly (both connectors) and that this is included in the 0.333 Ω total.
b)
Output current per port. Subclause 9.2.1.7 limits output current to a maximum of 1.5 A.
c)
Voltage drop through cable assembly. The product of 1.5 A and 0.333 Ω yields a maximum voltage drop of 0.5 V for a mated cable assembly.
d)
Voltage drop through node. Subclause 9.2.1.7 limits the resistance between any two of a node’s connector sockets to a maximum of 0.5 Ω. In combination with 1.5 A current per port, the maximum voltage drop through a node is 0.75 V.
e)
Device power requirements. The minimum power needed on VP for a cable-powered PHY to be operable is 3 W at 8 V.
The cable material performance requirements can be met by the reference design illustrated in 4.2.1.2.1. The reference design assumes a maximum cable assembly length of 4.5 m and the use of 22 AWG (7 × 30) for power and ground. It may be possible to construct longer cables with a larger wire gauge, so long as the power pair dc resistance criterion of 0.333 Ω for the cable assembly is met. NOTE—Cable assembly requirements of 4.2.1.2.2 that specify the connection of VG to the inner cable shields at both ends effectively lower the resistance of VG to 0.167 Ω.
Ground difference potential was not addressed previously, but may be of concern for safety reasons. Ground difference potential is measured in the same way as power—through a mated cable assembly with the measurements taken at the PCB side of the connector sockets. Ground difference potential in excess of 0.5 V may be reason for concern. Table M.1 is derived based upon the preceding characteristics. For each of the three common classes of power provider (as identified by POWER_CLASS in the self-ID packets), the table shows the greatest hop count at which a minimum of 3 W are available at a minimum of 8 V (assuming that there are no other power consumers on the path from the power provider to the intended power consumer). The last column in the table shows the maximum current available to the power consuming device at the wattage provided by the power source.
Copyright © 2008 IEEE. All rights reserved.
829
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table M.1—Power provider ranges by POWER_CLASS and launch voltage POWER_CLASS 0012 (15 W)
0102 (30 W)
0112 (45 W)
Launch voltage (V)
Maximum hops
Maximum current available (A)
20
19
0.750
24
23
0.625
26
0.577
30
0.500
20
9
1.500
24
15
1.250
26
18
1.150
30
23
1.000
30
17
1.500
The maximum hops in Table M.1 are limited to 23 because this is the largest bus topology that can operate within a maximum gap count of 63, if 4.5 m cables and a PHY delay of 0.144 μs are assumed. Given the characteristics of a particular power provider, wattage, and launch voltage, it is possible to calculate the power available to a power consumer according to the number of hops that separate the two. The aggregate resistance, R, between the power provider and consumer may be calculated as follows: R = ( Hops × 0.833 – 0.5 )Ω
and the result used in the following equations: 2
P = I R E = IR
where E
is the voltage drop
I
is the current
R
is the resistance of the wire and connector
P
is the power available
An example power analysis is provided for the configuration illustrated by Figure M.1, which shows a power provider separated by three hops from the power consumer. Kirchoff’s law is used to determine the voltage available at VP for each node. Assume the power provider is POWER_CLASS two (30 W) with a launch voltage of 26 V The VP measurements are taken at the PCB side of the connector socket. All the cables are assumed to be 4.5 m and constructed per the reference designs in this standard. The power consumer is assumed to draw 1.15 A.
830
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure M.1—Power distribution example The voltage drop across VP in the cable that connects nodes P and A is equal to the current multiplied by the resistance of the wire and connector (). Given a current of 1.15 A, a mated cable assembly resistance of 0.33 Ω, the voltage drop across this cable is 0.383 V. After the cable, the current passes through node A. The maximum port to port resistance of node A, or X, yields a voltage drop of 0.575 V. The voltage drops in the remaining cables, from node A to node B and from node B to node C, are identical to the voltage drop in the first cable. The voltage drop through node B is also the same as through node A. The aggregate voltage drop for these two cables and node B is 1.341 V. The cumulative voltage drop from the power provider to the power consumer is 2.299 V. Thus, the net voltage available to the power consumer at the PCB side of the connector socket is the launch voltage, 26 V, less all of the intermediate voltage drops, 2.299 V. In other words, 23.7 V. It is left to the designer to calculate the losses in PCB traces within the power consumer and arrive at the net usable voltage available to the device’s circuitry.
Copyright © 2008 IEEE. All rights reserved.
831
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
In a like fashion, the power available to the power consumer may be obtained from P = I2R. Calculate the power drop for each cable assembly and for each node through which the power passes. Subtract the aggregate power loss from the power provided by the source to yield 27.4 W available to the power consumer.
832
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex N (normative)
Jitter measurements This annex provides specific transmitter test patterns to facilitate jitter measurements. Jitter measurements shall be made using an appropriate test method as described in NCITS TR-25-1999 for fibre channel, referred to as the “Methodologies for Jitter Specification” (MJS) report. In particular, it is recommended that time interval analysis be used to measure jitter output.
N.1 Test patterns The test patterns recommended in the MJS report are specific to fibre channel encoding and frame format. Similar patterns are specified in this annex. Although the MJS report provides different patterns for measuring jitter output and jitter tolerance and a third pattern for measuring supply noise, experience has shown that all three patterns may reveal failure modes when used for measuring both jitter output and jitter tolerance. Therefore, all three patterns described in N.2 through N.4 shall be used for both jitter output and jitter tolerance tests. The jitter test patterns have been devised so that they may be generated by test software, but run on a normal IEEE 1394 node with no special hardware modification or test modes (apart from the required ability to disable the transmit scrambler during packet payload transmission). A test configuration shall comprise the device under test and a second device to provide a working bus. Each port on the device under test is tested independently. The port used on the second device shall be capable of operating at the maximum operating speed of the port under test on the device under test. For jitter tolerance tests, the second device generates the test pattern as described in N.3. The connection between the two devices will contain extra circuitry and/or test equipment appropriate to the test method being used. The packet format used is a compliant asynchronous packet (with normal header and checksum). The packets shall be addressed to node 2 (thus, even when not scrambled, they will be ignored by the receiving node’s link layer).
N.2 Random pattern (SB_RPAT) Unlike fibre channel, IEEE Std 1394 has an excellent built-in random pattern generator in the form of the Beta-mode scrambler. Thus the random pattern shall be an indefinitely repeated sequence of maximum size asynchronous packets (depending on transmission speed; see 19.1), which shall be transmitted continuously (e.g., by using CURRENT_ASYNC requests, by ignoring fairness). The packet payload should be all zeros, which are scrambled by the transmitting PHY into a random pattern. A TIA should be primed to capture each packet.
N.3 Receive jitter tolerance pattern (SB_JTPAT) The receive jitter tolerance pattern comprises sequence of symbols providing a low-density pattern followed by a sequence of symbols providing a high-density pattern. Using these two patterns together tests the tolerance to phase jumps caused by systematic pattern jitter. The run length of these two patterns is related to
Copyright © 2008 IEEE. All rights reserved.
833
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
the time constants of the PLL. For the fibre channel jitter tolerance pattern, the following assumptions were made: —
Average traffic transition density for fibre channel is approximately 50%.
—
CDR time constant is inversely proportional to transition density.
—
To obtain at least 95% settling, a pattern duration needs to be greater than three time constants.
—
The PLL’s minimum bandwidth for fibre channel transceivers is 637 kHz.
A pattern of one hundred 10-bit characters at 50% transition density meets these assumptions. For fibre channel, the repeating D21.5 symbol is used as it has a 100% transition density, and the repeating D30.3 symbol is used as it has a 30% transition density. Because of the above assumptions, the duration of the high transition density pattern needs to be at least fifty 10-bit characters. As for the low transition density pattern, it needs to be at least one hundred sixty-seven 10 bit characters. For Beta mode transmission, the control symbols provide approximately a 30% transition density when scrambled. However, the scrambled data characters will provide only 50%. If the transmit scrambler is disabled, then 100% transition density can be achieved by using D21.5 symbols. For this test, the transmitter data scrambler shall be disabled once synchronization has been achieved, and the port_error register of the receive port shall be read in order to clear it. Error rate shall be computed from the values obtained by regularly reading the port_error register. The test pattern shall comprise a sequence of at least 42 null packets followed by a packet containing at least 50 bytes of consecutive D21.5 symbols (8-bit data value AD16). This pattern (42 null packets followed by a packet with D21.5 data) is repeated indefinitely. Best results when measuring output jitter are normally found if the TIA is armed to start at the beginning of a packet (for this purpose, it is sufficient to arm the TIA to start on a sequence of 5 zeros or 5 ones, which will capture between 80% and 90% of all packets), and the transitions are captured for the duration of one period of the repeating cycle. The sequence of 42 null packets may be generated by repeatedly issuing CURRENT_ASYNC requests and providing a zero-length PHY packet (and thus generating a repeating sequence of DATA_PREFIX DATA_PREFIX DATA_END DATA_END). As it is not required that link devices support the transmission of zero-length null packets, an acceptable alternative is to transmit single quadlet or two quadlet PHY packets containing the repeated data byte D30.3 (8-bit data value 0x7E). The total length of this part of the test pattern, comprising the repeated PHY packets, shall be at least 167 symbols. The length of the two parts of the test pattern may need adjustment (following the guidelines given above and the test guidelines given in the MJS report) according to the cutoff frequency of the receiver PLL, particularly for transmission at speeds other than S800.
N.4 Supply noise test sequence (SB_SPAT) The aim of the supply noise test sequence is to maximize supply noise by changing all lines on a parallel PHY-link interface. It shall comprise a maximum length asynchronous packet containing alternate 0016 and FF16 bytes, which shall be transmitted repeatedly. The scrambler shall be enabled for this test sequence. If no parallel PHY-link interface exists or a serial PHY-link interface is used, then a system-dependent method of maximizing supply noise should be used, e.g., by transmitting data across an electrically proximate system bus that alternates between all ones and all zeros on successive clocks.
834
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex O (informative)
Connection status change The design of the algorithm that is used during disconnection and during suspend to detect a change in port status (see 14.8) is based on the following fundamental properties of TpBias, toning, and the connect detect circuitry, given with the reasoning on each property: a)
A port cannot tone and drive TpBias simultaneously. Alpha PHYs would attempt to interpret the tone if TpBias were present. The only safe way to tone into an Alpha port is when TpBias is deasserted.
b)
A port cannot wait for the remote port on the peer PHY to initiate TpBias. An Alpha node with a suspended port will not initiate TpBias as long as the dc connection status is continually active. Consider am Alpha PHY and a B PHY that are connected via a suspended link. Subsequently, if the B PHY experiences a POR (device powered off for a while and then turned back on), it needs to reestablish connectivity with the Alpha node. If the eager Beta algorithm waited for the Alpha device to initiate TpBias, it would never come. Consequently, at least one step in eager Beta has to lead to the initiation of a TpBias handshake.
c)
A port cannot assume that the initial receipt of TpBias means an Alpha device is attached. If Beta port X tries toning first and hears nothing, then according to property b, it will have to initiate TpBias. If connected Beta port Y on a peer PHY then powers up, it will detect TpBias without a tone. Thus, assuming that the presence of TpBias always indicates an Alpha port leads to a false detection of the remote peer. To avoid this, port Y should tone first even if it sees TpBias. Port X, which is still driving TpBias, has to turn TpBias off first (see property e) and then still listen for a tone. After detecting the tone from Port Y, Port X will revert to toning; and the Beta-mode handshake can commence.
d)
During upstarting, a port needs to initiate toning with some frequency. Assume an ac path between two Beta ports and allow that the ac path can have passive connection points (e.g., RJ-45 jack on the wall or in the patch panel, a optical wall socket). If the passive connection is not in place, the two B nodes at POR attempt to initiate a handshake. Both progress to the TpBias assertion phase mandated in property b without ever detecting the remote port. If the eager Beta scheme stopped at this point with the continuous assertion of TpBias, a later connection at the passive point will not be detected by either node. For this reason, the eager Beta procedure attempts toning with some frequency to allow for passive connections. (A local_plug_present feature at the PHY does not handle the case of passive connection points in between the attached ports.) This suggests that the eager Beta sequence would need to generate TpBias. After a single phase of TpBias, the procedure then reverts to continuously toning.
e)
A port cannot listen for a tone when generating TpBias. When generating TpBias, the remote node may be a DS port. Such a node interprets the TpBias signal as a connection and starts sending arbitration signals (e.g., reset). These signals trip the signal detect mechanism, which operates by looking for a differential signal on TPA. Corollary to property e: A Beta PHY does not need to send a tone when receiving TpBias because the Beta PHY on the other end of the cable that is generating TpBias cannot listen for the tone anyway.
f)
A port cannot listen for TpBias while generating a tone. When generating a tone, the local PHY is providing an internally generated bias level on TPB around which to send the signal. This will, in general, be detected by the local TpBias detector. The
Copyright © 2008 IEEE. All rights reserved.
835
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
TpBias detector has no filter to sense loss of TpBias, and it is assumed that the bias bit will report zero as soon as the transmission of the tone ceases NOTE—In general, generating a tone while the peer is generating bias may cause level shifts in the peer’s TpBias and, for PHYs with a single TpBias generator, may corrupt traffic being repeated through that PHY. Therefore, a B PHY should avoid generating a tone when incoming bias is present (see corollary to property e). In practice, this is unavoidable as a corollary to property f. However, if a B PHY checks for bias immediately before generating a tone, then the problem is limited to the rising edge of bias, which can occur only when the peer PHY is powering up, and hence no traffic will be corrupted. It is also important to ensure that the bias comparator is stable before generating tones.
g)
DC low-current connect detect mechanism may give false negative. An incoming tone on a dc-coupled connection is centered around a common-mode bias, which may raise the voltage higher than the connect detect threshold. (Low voltage implies connection.) Corollary #1 to property g: A port cannot use the dc comparator at all as soon as a tone is heard. This is because the tone interval is 41 ms, but CONNECT_TIMEOUT is 330 ms. Corollary #2 to property g: A port should not try to maintain dc-connected status in Beta mode. NOTE—The dc connect detect comparator has an RC constant for discharging the capacitor for the Connected state of the order of 1.5 ms. Once in this state, the RC constant for charging the capacitor (depending on the circuit in the local PHY) to transition into the Disconnected state is of the order of 100 ms. Thus short disconnects due, e.g., to connection bounce or scrape will not be reported to the connection_status() logic, which, therefore, does not restart the timer for such short disconnects. In effect, CONNECT_TIMEOUT is simply a time to allow the connector bouncing to settle down. The connection debounce algorithm is, therefore, simply to tone during a CONNECT_TIMEOUT interval and not to check that every tone is received.
h)
A port cannot support autocrossover on a dc connection. Sending a tone on TPA (which will occur at a random interval if PMD_AUTOCROSSOVER_SUPPORTED reports TRUE) results in the dc connect detector’s reporting a possibly false negative.
836
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Annex P (informative)
Deriving bus topology from self-ID packets P.1 Bus topology analysis Subsequent to a bus reset, the topology of the network must be reestablished (see 8.4.5.) An early step in determining whether a net topology change occurred is an analysis of the bus topology and unique identity of the connected nodes before and after the bus reset. The simplest method is to assume that the identity of all nodes could have changed and therefore to read the configuration ROM bus information block of each node to reestablish its unique identity (as determined by its EUI-64). This is inefficient and time-consuming; each node will arbitrate for the bus in attempts to read configuration ROM from all the other nodes. This flurry of activity occupies bus bandwidth needed for other time critical tasks, such as the reallocation of isochronous resources or net update. A superior method exists, one based upon topology information retained from conditions prior to the bus reset combined with an intelligent examination of the information contained in the set of self-ID packets. NOTE—Because the algorithm relies on knowledge of the bus topology just prior to bus reset and compares it to the information in the self-ID packets, it is the essential that each set of self-ID packets associated with a bus reset be processed in the same order as the bus resets. If bus resets occur in rapid succession or interfere with completion of the self-identify phase, an implementation might lose part or all of one or more sets of self-ID packets, in which case there is no recourse except to read configuration ROM for all nodes on the bus.
This annex describes a method to perform intelligent analysis of self-ID packets to reestablish the EUI-64 identity of nodes connected before and after the bus reset. A node that uses this method derives a bus topology viewed from its own perspective, as if it were the root and all of its connections were child connections. The self-ID packets contain all the information necessary to derive such a normalized topology. The second step is the comparison of a saved copy of a normalized topology accurate before the bus reset with the newly derived normalized topology. When a child connection exists in the new map and a valid connection—either child or parent—existed in the prior map, the EUI-64 identity of the node is unchanged. Otherwise, when a new child connection is discovered, the EUI-64 identities of all nodes subsidiary to that connection are unknown and can be determined only by an examination of configuration ROM. NOTE—Although this annex was originally developed for use in IEEE 1394.1 bridges, the method described here may be implemented separately by any node. Because these methods reduce the asynchronous traffic load on the bus subsequent to a bus reset, it is recommended that all nodes implement topology analysis based upon self-ID packets.
The methods of self-ID packet analysis are discussed with reference to an example topology, illustrated by Figure P.1. 5
2
0
U
4
R
P
1
Q
Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
T
3
S
Figure P.1—Reference topology (with self-ID packets)
Copyright © 2008 IEEE. All rights reserved.
837
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
In Figure P.1, nodes are represented by circles that contain their physical_IDs. The root (physical_ID 5 in this figure) is at the top. For the sake of brevity, a single letter shown to the right of each node represents its EUI-64. Although the PHY ports at each node are not explicitly numbered, this information can be deduced from the assigned physical_IDs. The examples that follow assume that node identified by the letter T collects and analyzes the self-ID packets. The table to the right of Figure P.1 contains pertinent details from the set of self-ID packets generated for this topology; child and parent connections on a PHY port are abbreviated as C and P, respectively.
P.2 Topology analysis after power reset For obvious reasons, a node that has just completed power reset has no knowledge of bus topology; from its perspective, the EUI-64 identity of all nodes is unknown. Part of the information the node requires is contained in any consistent set of self-ID packets collected after bus reset; these completely describe bus topology but they are not in a format useful for topology comparison subsequent to future bus resets. The first task is to reorganize this information into a normalized topology. The data structure that represents each node in the tree is represented graphically by Figure P.2.
EUI-64
Physical_ID
Port 0
Port 1
Port 2
Figure P.2—Node data structure for normalized topology The graphic representation shown above is used in the figures that follow, which describe steps in the analysis of self-ID packets. The EUI-64 field represents the node’s unique identifier (ultimately obtained from configuration ROM). The port fields are overloaded in the figures to represent either the port status reported in the self-ID packet (disconnected, child or parent) or a link to another node data structure in the normalized topology.31 The overloading of these fields is more apparent in the C pseudocode definition of the data structure type (see Table P.1), in which they are separated from each other. The first phase in the process is to analyze the self-ID packets in order to determine which nodes are connected to each other and by which numbered ports. The algorithm starts with the self-ID packets for the node with physical_ID zero and concludes with the root. As each node’s self-ID packets are encountered, transfer the port status into the corresponding node data structure. If the node is childless, also push the node’s physical_ID onto a stack; this information is used later in the process when the node’s parent is encountered in the self-ID packets. In Figure P.3, the two self-ID packets that have been processed are shown shaded. Since both are childless, their physical_IDs have been pushed onto the stack in the order they were encountered. Self-ID packets P – – 0 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
Stack 1 0 –
?
0
P
–
–
?
1
P
–
–
Figure P.3—Self-ID packet topology analysis (nodes zero and one) 31Although PHYs may implement up to sixteen ports, the examples assume uniform use of three-port PHYs.
838
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Whenever self-ID packets for a node indicate connected child ports, the processing is different. As before, copy the port status information from the self-ID packets to the node data structure—but do not push the node’s physical_ID onto the stack just yet. For each connected child port, pop a physical_ID from the stack and establish a link between this node’s data structure and the node data structure identified by the physical_ID obtained from the stack As the stack values are popped, the connections are made to this node’s connected child ports in decreasing order. Upon completion, if the node has an unresolved parent connection, push the node’s physical_ID onto the stack. Figure P.4 shows the results of processing the self-ID packets for node two (shaded); links have been created to its children and its physical_ID has been pushed onto the stack. Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
?
?
0
–
2
Stack 2 – –
P
–
?
1
–
–
Figure P.4—Self-ID packet topology analysis (node two) This process continues as the physical_ID of nodes with unresolved parent links are pushed onto the stack. Figure P.5 shows the result after processing another childless node. Stack 3 2 –
Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
?
0
?
–
2
P
–
?
1
–
–
?
3
P
–
–
Figure P.5—Self-ID packet topology analysis (node three) Each time a node with connected child ports is encountered, corresponding physical_ID entries are popped from the stack and links established in the topology that is under construction, as already described in association with Figure P.4. In the case of the node with physical_ID four, the results are illustrated by Figure P.6. Stack 4 2 –
Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
?
0
?
–
2
–
P
?
?
11
–
–
4
–
P
?
3
–
–
Figure P.6—Self-ID packet topology analysis (node four)
Copyright © 2008 IEEE. All rights reserved.
839
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Eventually the process comes to an end when the root node is encountered. All of its connected child ports are processed and links created in the topology. Since the root, by definition, has no connected parent, its physical_ID is not pushed onto the stack. At this time, a complete topology from the perspective of the root has been derived from the self-ID packets, with the results shown by Figure P.7. Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
?
0
?
?
–
5
Stack – – –
–
2
?
–
?
1
–
4
–
–
?
3
–
–
Figure P.7—Self-ID packet topology analysis (node five) Although Figure P.7 illustrates an accurate and complete bus topology, it is presented from the viewpoint of the root. In order to be useful for future comparisons with potentially changed topologies, the viewpoint is normalized to present the bus as if the node collecting the self-ID packets were the root. This is shown by Figure P.8, which assumes that node four is the observer. ?
?
3
–
–
?
?
0
–
4
–
–
?
5
?
1
–
2
–
–
Figure P.8—Normalized topology (relative to node four) The normalized topology shown above is in a form suitable for comparison to the last known topology (prior to the bus reset). However, since this example assumes that the node has completed a power reset, there is no previous topology information and the only means to associate an EUI-64 identity with each node is to read its configuration ROM. In order to reduce asynchronous traffic congestion on the bus, read requests for configuration ROM should be deferred until one second after the most recent bus reset. Once configuration ROM has been read for all the unidentified nodes, the normalized topology is complete, as shown by Figure P.9.
840
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
T
S
3
–
–
R
P
0
–
4
–
U
5
Q
1
–
2
–
–
–
Figure P.9—Normalized topology with EUI-64 information All of the steps described above are presented more formally in the C pseudocode excerpt in Table P.1. The algorithm, as embodied in the normalize_topology() procedure, assumes that a consistent set of self-ID packets has been observed and that their physical_ID and port connection status have been transferred to an array in memory—the format of entries in this array is not identical to the self-ID packets themselves. Note that the code assumes that self-ID information is present for the node executing the algorithm; this may have been obtained from the node’s PHY registers instead of directly from a self-ID packet.
Table P.1—Topology analysis of self-ID packets #include “csr.h” #include “global.h” typedef enum {DISCONNECTED=0, CHILD, PARENT} PORT; typedef struct _NODE { OCTLET eui64; /* Zero indicates unknown EUI-64 */ PORT port[16]; struct _NODE *link[16]; } NODE; NODE node[63]; INT rootID; struct { PORT port[16]; } selfID[63];
/* /* /* /*
Normalized topology derived from self-ID */ Set to root’s physical_ID after bus reset*/ Port connection status information */ Copied from each node’s self-ID packets */
VOID normalize_topology() { INT i, j, m, n; memset(node, 0, sizeof(node)); for (i = 0; i <= rootID; i++) { for (m = 16; m >= 0; --m) { node[i].port[m] = selfID[i].port[m]; if (selfID[i].port[m] == CHILD) { j = pop(); for (n = 0; n < 16; n++)
Copyright © 2008 IEEE. All rights reserved.
/* Clear the topology at the start */
/* Copy port connection status */ /* Found a child connection? */ /* Yes, set j to child PHY ID */ /* Scan for parent port */
841
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Table P.1—Topology analysis of self-ID packets (continued) if (selfID[j].port[n] == PARENT) { node[i].link[m] = &node[j]; node[j].link[n] = &node[i]; break; } } } if (i < rootID) push(i);
/* Link from parent to child ... */ /* ... and from child to parent */ /* Only one parent port per PHY */
/* Remember this node for later parent link resolution */
} }
The normalized topology derived by this code should be saved for comparison with potentially changed topologies after future bus resets.
P.3 Topology analysis when the root changes Even in cases where bus topology is unchanged before and after bus reset it is possible for the self-ID packets to differ. A common example occurs when the location of root changes, as when a node other than the current root has its root hold-off bit set prior to the bus reset. Figure P.10 illustrates the topologies (seen from the perspective of the root) and the self-ID packets generated when the root changes from node U to node T. 5 5
U
0 2
4
R
S
P
1
Q
3
U
2
Q
R
S
1 Self-ID packets 0 P – – 1 P – – 2 C C P 3 P – – 4 – C P 5 C C –
4
T
3 0
T
P
Self-ID packets 0 P – – 1 P – – 2 P – – 3 C C P 4 C P – 5 – C C
Figure P.10—Reference topology (changed root)
842
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
A simple comparison of the self-ID packets fails to discern that the topologies are, in fact identical, but if the normalized topologies (derived as described in P.2) are compared it is apparent that the topologies are unchanged. First, the new set of self-ID packets is analyzed to produce the normalized topology illustrated by Figure P.11. At this point in the process, the only EUI-64 known with certainty is that of the node that observed the self-ID packets—in this case, the same node T used in the first example. Note that the new normalized topology reflects a changed physical_ID for node T. T
?
0
–
–
?
?
1
–
5
–
–
?
4
?
2
–
3
–
–
Figure P.11—Normalized topology (relative to node five) The next step is to compare the normalized topologies before and after bus reset in order to transfer as much EUI-64 information as possible from the saved information. The algorithm recursively traverses the two trees, starting from the position of the observing node. If a port is disconnected in the new topology, there is no need for any analysis. If the same port was connected to a child both before and after bus reset, the EUI-64 identity of the child is unchanged. The C pseudocode in Table P.2 describes the details of the algorithm.
Table P.2—Normalized topology comparison VOID updateEUI64(NODE *new, NODE *prior, NODE *parent) { int i; for (i = 0; i <= 16; i++) { /* Compare old and new connection status on all ports */ if (new->port[i] == DISCONNECTED) continue; /* Nothing to explore down this branch ... */ if (new->link[i] == parent) /* Does connection point to our parent? */ continue; /* Been there, done that! */ if (prior->port[i] != DISCONNECTED) { /* Was same port connected in the prior topology? */ new->link[i]->eui64 = prior->link[i]->eui64; /* OK! We know it has the same EUI-64 */ updateEUI64(new->link[i], prior->link[i], new); /* Recurse down this branch of the tree */ } } }
Copyright © 2008 IEEE. All rights reserved.
843
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
The recursive process is started with a call to updateEUI64() with the parameters shown below: updateEUI64(&node[phy_IDnew], prior[phy_IDprior], NULL);
In the code excerpt above, prior and new are arrays of normalized topology information, the one from before the bus reset and the other current, while phy_IDprior and phy_IDnew are the observing node’s physical_ID before and after the bus reset. Since the topologies are compared from the perspective of the observing node as if it were the root, there is no parent node and its parameter is null. Upon completion of the algorithm, the normalized topology is updated with EUI-64 identity information from the prior topology, as shown by Figure P.12. Although the physical_IDs of all the nodes have changed, their EUI-64 identities have been reestablished without recourse to reading configuration ROM. T
S
0
–
–
R
P
1
–
5
–
–
U
4
Q
2
–
3
–
–
Figure P.12—Normalized topology with EUI-64 information (changed root)
P.4 Topology analysis when a node is inserted The methods already described in the context of detecting unchanged topologies are equally useful when a node is inserted. Consider the reference topology illustrated in the right half of Figure P.10. If a new node, with an EUI-64 represented by the letter X, is inserted, the topology is altered and a different set of self-ID packets is generated as shown by Figure P.13. By the methods already described in P.2 and P.3, a normalized topology is derived and compared to the topology retained from before the node insertion. Figure P.14 illustrates the normalized topology with the addition of a new node. At the completion of the recursive application of updateEUI64(), the nodes whose EUI-64 identity could not be deduced from topological analysis are left with zero for their EUI-64s. This is an invalid value for an EUI-64; it is necessary to read configuration ROM to obtain the EUI-64s for these nodes. Configuration ROM reads for newly inserted nodes should be deferred until at least one second since the most recent bus reset.
844
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
5
0
4
S
3
1
6
T
0
U
5
S
3
R
2
P
T
1
Q
4
R
2
P
Self-ID packets 0 P – – 1 P – – 2 P – – 3 C C P 4 C P – 5 – C C
U
X
Q
Self-ID packets 0 P – – 1 P – – 2 P – – 3 C C P 4 P – – 5 C P C 6 – C C
Figure P.13—Reference topology (inserted node)
T
S
0
–
–
1
–
–
U
R
P
6
–
5
3
?
Q
2
–
4
–
–
–
Figure P.14—Normalized topology with EUI-64 information (inserted node)
Copyright © 2008 IEEE. All rights reserved.
845
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
846
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Annex Q (informative)
Summary description This annex describes the form and function of the serial bus in a general way and provides useful background information to aid the understanding and implementation of the specification. Additionally, this clause provides a historical perspective of the development of the IEEE 1394 standards. Subclauses Q.1 through Q.8 provide an overview of the original standard, IEEE Std 1394-1995. Subclauses Q.9, Q.10, and Q.11 summarize the new features added in IEEE Std 1394a-2000, IEEE Std 1394b-2002, and IEEE Std 1394c-2006, respectively. Q.12 summarizes the new features of IEEE Std 1394-2008.
Q.1 Node and module architectures The serial bus architecture is defined in terms of nodes. A node is an addressable entity, which can be independently reset and identified. More than one node may reside on a single module, and more than one unit may reside in a single node, as illustrated in Figure Q.1.
Figure Q.1—Module architecture Each module consists of one or more nodes, which are independently initialized and configured. Note that modules are a physical packaging concept and nodes are a logical addressing concept. A module is a physical device, consisting of one or more nodes that share a physical interface. In normal operation, a module is not visible to software. Of course, this is not true when the module is replaced, when the shared bus interface fails, or when specialized module-specific diagnostic software is invoked. A node is a logical entity with a unique address. It provides an identification ROM and a standardized set of control registers, and it can be reset independently. The address space provided by a node can be directly mapped to one or more units. A unit is a logical entity, such as a disk controller, which corresponds to unique I/O driver software. On a multifunction node, for example, the processor and I/O interfaces could be different units on the same node. Unless the node is reset or reconfigured, the I/O driver software for each unit can operate independently. A unit may be defined by a unit architecture that describes the format and function of the software-visible registers of the unit. SCSI-3 SBP is a typical unit architecture.
Copyright © 2008 IEEE. All rights reserved.
847
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Within a unit there may be multiple subunits, which can be accessed through independent control registers or uniquely addressed direct memory access (DMA)-command sequences. Although unit architectures should use the subunit concept to simplify I/O driver software, the definition of subunit architectures is beyond the scope of this standard.
Q.2 Topology The physical topology of the serial bus is divided into two “environments,” as shown in Figure Q.2. One is called the backplane environment and is defined in this standard, although implementations may require additional physical-layer descriptions contained within other backplane bus standards. The other part is the cable environment and is completely specified in this standard. Interconnected nodes may reside in either environment without restriction.
Figure Q.2—Serial bus physical topology Note that Figure Q.2 shows several logically separate buses. A bus bridge is required to connect buses with different environments. The full implementation of multiple bus systems using bus bridges is not defined in this standard: only the addressing and transactions are specified.
Q.2.1 Cable environment The physical topology for the cable environment is a noncyclic network with finite branches and extent. “Noncyclic” means that closed loops are unsupported. The medium consists of two conductor pairs for signals and one pair for power and ground that connect together ports on different nodes. Each port consists of terminators, transceivers, and simple logic. The cable and ports act as bus repeaters between the nodes to simulate a single logical bus. Since each node has to continuously repeat bus signals, the separate power and ground wires within the cable enable the PHY of each node to remain operational even if node local power is off. The pair can even power an entire node if its requirements are modest. The serial bus cable provides 8–40 VDC at up to 1.5 A. The actual current available is system dependent.
848
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Q.2.2 Backplane environment The physical topology of the backplane environment is a multidrop bus. The media consists of two singleended conductors running the length of the backplane. Connectors distributed along the bus allow nodes to “plug into” the bus. Dominant mode (or “wired-OR”) logic allows all nodes to assert the bus. When in the backplane environment, the serial bus typically accompanies a standard parallel bus within an equipment chassis. In such an environment, the serial bus is extended from the backplane into each physical device using two pins reserved for a serial bus by the various IEEE bus standards. Drivers and receivers for serial bus signals follow the conventions established by the appropriate parallel bus standard: e.g., Futurebus+ using BTL, VME using TTL, and Fastbus and SCI using ECL. Power and ground are distributed as specified for the parallel bus. Examples of backplane implementations are given in Annex F.
Q.3 Addressing The serial bus follows the CSR architecture for 64-bit fixed addressing, where the upper 16 bits of each address represent the node_ID. This provides address space for up to 64 k nodes. The serial bus divides the node_ID into two smaller fields: the higher order 10 bits specify a bus_ID and lower order 6 bits specify a physical_ID. Each of the fields reserves the value of all “l”s for special purposes, so this addressing scheme provides for 1023 buses, each with 63 independently addressable nodes. This standardization is continued within the node, with 248 bytes (256 tebibytes) divided between initial register space (2048 bytes reserved for core CSR architecture resources, registers specific to the serial bus, and the first 1024 bytes of a ROM ID area), initial units space (area reserved for node-specific resources), private space (area reserved for nodelocal uses), and initial memory space. Section 4 of ISO/IEC 13213:1994 defines these terms in more detail. Figure Q.3 illustrates the address structure of the serial bus.
Figure Q.3—Serial bus addressing
Copyright © 2008 IEEE. All rights reserved.
849
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
When practical, the node should use only the first 2048 bytes of the initial units space. This simplifies the design of heterogeneous-bus systems, since the 2048 bytes of standard CSRs and ROM and first 2048 bytes of the initial units space use up the 4096 bytes allocated to CSR space on buses using the CSR-architecturedefined 32-bit extended addressing (Futurebus+ has several profiles that use 32-bit extended addressing). Note, however, that nodes intended solely for serial bus systems (or mixed with other 64-bit fixed interconnects, such as SCI) may take full advantage of the 256 megabytes of CSR address space provided by this addressing architecture.
Q.4 Protocol architecture and data transfer services Q.4.1 SBP architecture The SBPs are described as a set of three stacked layers, as shown in Figure Q.4. a)
The transaction layer defines a complete request-response protocol to perform the bus transactions required to support the CSR architecture (the operations of read, write, and lock). Note that the transaction layer does not add any services for isochronous data, although it does provide a path for isochronous management data to get to the SBM via reads from and compare-swaps with the isochronous control CSRs.
b)
The link layer provides an acknowledged datagram (a one-way data transfer with confirmation of request) service to the transaction layer. It provides addressing, data checking, and data framing for packet transmission and reception. The link layer also provides an isochronous data transfer service directly to the application, including the generation of a “cycle” signal used for timing and synchronization. One link layer transfer is called a “subaction.”
c)
The PHY has three major functions: 1)
It translates the logical symbols used by the link layer into electrical signals on the different serial bus media.
2)
It guarantees that only one node at a time is sending data by providing an arbitration service.
3)
It defines the mechanical interfaces for the serial bus.
4)
There is a different PHY for each environment: cable and backplane. The cable PHY also provides a data resync and repeat service and automatic bus initialization.
The SBPs also include SBM, which provides the basic control functions and standard CSRs needed to control nodes or to manage bus resources. The bus manager component is only active at a single node that exercises management responsibilities over the entire bus. At the nodes being managed (all those that are not the bus manager), the SBM consists solely of the node controller component. An additional component, the IRM, centralizes the services needed to allocate bandwidth and other isochronous resources.
Q.4.2 Data transfer services This standard supports two basic data transfer services: a)
Asynchronous data transfer
b)
Isochronous data transfer
The asynchronous (asyn = any, chronous = time) data transfer service provides a packet delivery protocol for variable-length packets to an explicit address and return of an acknowledgment. The isochronous (iso = same, chronous = time) data transfer service provides a broadcast packet delivery protocol for variablelength packets that are transferred at regular intervals. As shown in Figure Q.4, the asynchronous data transfer service uses the transaction layer, whereas isochronous data transfer service is application driven.
850
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure Q.4—SBP stack
Q.5 Transaction layer Data are transferred between nodes on the serial bus by three different transaction types: a)
Read—Data at a particular address within a responder are transferred back to a requester.
b)
Write—Data are transferred from a requester to an address within one or more responders.
c)
Lock—Data are transferred from a requester to a responder, processed with data at a particular address within the responder, and then transferred back to the requester.
Transactions are multithreaded, in that more than one transaction can be started by a requester before the corresponding response is returned. These are called a split-response transactions.
Copyright © 2008 IEEE. All rights reserved.
851
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Q.5.1 Transaction layer services Transactions consist of four service primitives: a)
Request—The primitive used by a requester to start the transaction.
b)
Indication—The primitive used to notify the responder of an incoming request.
c)
Response—The primitive used by the responder to return status and possibly data to the requestor.
d)
Confirmation—The primitive used to notify the requestor of the arrival of the corresponding response.
These primitives and their relation to data flow is shown in Figure Q.5.
Figure Q.5—Transaction services The serial bus architecture limits the maximum number of data bytes in a transaction to the largest power-oftwo such that the whole asynchronous link-layer packet transmission takes less than 62 μs (this is half the isochronous cycle time, and restricting asynchronous subaction to this value helps minimize buffer requirements). This means that the data payload of asynchronous packets is limited to 512 bytes at the cable base rate of 98.304 Mbit/s. Longer packets can be sent at higher data rates and shorter packets at lower data rates (see Table 6-4). Implementations, however, can impose further restrictions. The only required transactions are quadlet write/read on quadlet aligned addresses (these are the transactions necessary to access the standard CSR resources). In addition, nodes that wish to contend for bus management resources shall also implement the quadlet “compare_swap” request and confirmation (see Clause 4) and the nodes that own those resources shall implement the quadlet “compare_swap” indication and response.
Q.5.2 Lock subcommands Since the serial bus supports split transactions, it cannot be easily locked while transaction sequences implement indivisible test-and-set operations. Therefore, special lock transactions are defined that communicate the intent from the requester to the responder, thus allowing the indivisible updates to be performed at the responder. There is one standard lock transaction format, but several different subcommands define conditional and unconditional update actions. Lock subcommands follow the CSR architecture and are based on the model necessary to implement the fetch and add and compare and swap primitives (the CSR architecture calls them “add_big” and “compare_swap”). The other subcommands define other update actions that can be easily performed with minimal additions to the basic lock-operation hardware. In the lock implementation model, there is a data
852
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
storage element at the destination (memory_data), two data values (request_data and request_arg) that are sent in the lock request, and one data value (response_data) that is returned in the lock response. A block diagram of this model is illustrated in Figure Q.6.
Figure Q.6—Simplified lock model The compare_swap lock transaction compares the value of request_arg and memory_data. If these values are the same, then memory_data is loaded with the value of request_data. However, if these values are different, then memory_data remains unchanged. In either case, response_data returns the initial value of memory_data. The mask_swap lock transaction performs a bitwise operation. For each request_arg mask bit that is set to 1, the corresponding memory_data bit is set to the corresponding request_data bit value. For each request_arg mast bit that is cleared, the corresponding memory_data bit is unchanged. In either case, response_data returns the initial value of memory_data. The add_big lock transaction adds the value of request_data to memory_data. The request_arg value is ignored. The response_data returns the initial value of memory_data. The four data values (memory_data, request_arg, request_data, and response_data) are all the same size, either 32 bits or 64 bits. All lock transactions are optional, but if any are implemented, then the “mask_swap” and “compare_swap” operations shall also be implemented. The C-language coding for these transactions is listed in Table 7-1.
Q.5.3 Subaction queue independence For the split-response serial bus design model, separate and (effectively) independent queues exist for incoming and outgoing transaction requests and responses. For a simple responder that never explicitly generated read, write, or lock transactions, two queues are sufficient: one for incoming transaction requests and one for outgoing transaction responses, as illustrated in Figure Q.7. These queues are independent, in the sense that the sending of response-queue subactions is not affected by the retry state of transaction request-queue packets (see Q.6.2.4 for a discussion of retries).
Copyright © 2008 IEEE. All rights reserved.
853
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure Q.7—Transaction request and response subaction queues A complex transaction requester/responder node (typically a node with asynchronous DMA capabilities) has two sets of queues. As a transaction requester, an outbound request queue holds the transaction requests waiting to be sent; the inbound response queue holds the transaction responses that are returned. As a responder, an inbound request queue holds the transaction requests addressed to this node; the outbound response queue holds the transaction responses being returned. As a central processing unit (CPU) or other initiator of higher layer protocols, these queues have to be processed independently: to avoid deadlock, sending of a transaction request never blocks the sending of a transaction response; to avoid starvation, sending of a transaction response never blocks sending of a transaction request. In a similar fashion, the DMA device queues also have to operate independently: to avoid deadlock, acceptance of previous transaction requests never blocks the acceptance of a transaction response; to avoid starvation, acceptance of a previous transaction response never blocks the acceptance of a following transaction request. A bridge has separate queues for transaction requests and responses travelling in each direction, so that transactions initiated from serial bus nodes and transactions initiated from the other bus nodes can be processed independently. The queue independence has an impact on the retry protocols of the node, in that the transaction request and response queues have to be serviced independently. When retry protocols described in Q.6.2.4 are used, requests and responses are retried in a sequential fashion (one per fairness interval as described in Q.7.2), and the retries from the transaction request and response queues have to be interleaved, so that each is retried at least once within four fairness intervals. The four-fairness-interval restriction provides the flexibility to be concurrently processing one retry_A/retry_B and one retry_X from each of the transaction request and response queues.
Q.6 Link layer The link layer provides a half-duplex data packet delivery service. The process of delivering a single packet is called a “subaction,” and there are two types used in the serial bus link layer: —
An asynchronous subaction—a variable amount of data and several bytes of transaction layer information are transferred to an explicit address and an acknowledge is returned.
—
An isochronous subaction or “channel”—a variable amount of data is transferred on regular intervals with simplified addressing and no acknowledge.
854
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The subaction has three possible pans: a)
Arbitration sequence—a node that wishes to transmit a packet requests the PHY to gain control of the bus. The PHY may respond immediately if the node already controls the bus (as it would be if the subaction is the transaction response corresponding to the immediately preceding acknowledge).
b)
Data packet transmission—for asynchronous subactions, the source node sends a data prefix signal (including a speed code, if needed), addresses of the source and destination nodes, a transaction code, a transaction label, a retry code, data, one or two cyclic redundancy checks (CRCs) and a packet termination (either another data prefix or a data end signal). Isochronous subactions include a short channel identifier rather than source or destination addresses and do not have the transaction label or retry code.
c)
Acknowledgment—uniquely addressed destination returns a code indicating the action taken by the packet receiver. Isochronous packets and asynchronous broadcast packets do not have acknowledgments. Acknowledgments are also preceded by a data prefix and terminated by another data prefix or a data end.
All asynchronous subactions are normally separated by periods of idle bus called “subaction gaps,” as shown in Figure Q.8. Note that a gap opens up on the bus between the packet transmission and acknowledgment reception. This “ack gap” is of varying lengths depending on where the receiver is on the bus with respect to the senders of the link request and acknowledgment (ack). However, the maximum length of the ack gap is sufficiently shorter than a subaction gap to ensure that other nodes on the bus will not begin arbitration before the acknowledge has been received.
Figure Q.8—Example asynchronous subactions Similarly, isochronous subactions are separated by periods of idle bus called “isoch gaps,” as shown in Figure Q.9.
Figure Q.9—Example isochronous subactions
Q.6.1 Link layer services Link layer services also have the request, indication, response, and confirmation service primitives: a)
Request—the primitive used by a link requester to transmit a packet to a link responder.
b)
Indication—the reception of a packet by a link responder.
c)
Response—the transmission of an acknowledgment by a link responder.
d)
Confirmation—the reception of the acknowledgment by the link requester.
Copyright © 2008 IEEE. All rights reserved.
855
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
See Figure Q.10.
Figure Q.10—Link layer services
Q.6.2 Link and transaction layer interactions The transaction layer and link layer interact in a way that optimizes the use of the bus. In particular: a)
Write transactions can be implemented in two different ways: unified or split
b)
Split transactions and isochronous subactions can be concatenated under certain circumstances
c)
A busy transaction layer can impose limited flow control on its peers
Q.6.2.1 Unified transactions If the responding transaction layer and link layer are fast enough, an entire write transaction takes a single link layer subaction: the transmission of a data packet and the corresponding acknowledgment as shown in Figure Q.11.
Figure Q.11—Unified transaction example
856
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.6.2.2 Split transactions When the responding layers are slow, a split transaction is required with separate link layer subactions for request and response. Note that other link layer subactions may use the bus between the request and response of a single transaction. See Figure Q.12.
Figure Q.12—Split transaction example Q.6.2.3 Subaction concatenation Split transactions are always used for read and lock transaction types since data must go both directions. If, however, the read or lock response is fast enough, the two subactions will be directly concatenated by skipping the data end, subaction gap, and arbitration for the response, as shown in Figure Q.8 and Figure Q.12, to produce the concatenated asynchronous subactions as shown in Figure Q.13 and Figure Q.14. Since the arbitration for the response is skipped, the fairness process described in Q.7.2 does not apply to the response.
Copyright © 2008 IEEE. All rights reserved.
857
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure Q.13—Split transaction using concatenated subactions
Note that the data prefix signal is used as a packet terminator for the request acknowledge to indicate the response packet is concatenated. See Figure Q.14.
Figure Q.14—Example of concatenated asynchronous subactions Similarly, isochronous subactions sent by the same node may be concatenated together, as shown in Figure Q.15.
Figure Q.15—Example of concatenated isochronous subactions
858
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.6.2.4 Retries On an idle bus, the resources of all devices are always available. On a congested multiple-bus system, however, device queues fill, and subactions have to be busied at the destination node. Two methods of reporting busy to an inbound primary packet and attempting to retry the packet are defined. Note that both transaction request packets and response packets may be retried. The acknowledge code is used by the destination node to notify the sending node that it is busy and should try back later. The acknowledge code also indicates the phase of the retry, which is used by the destination node to manage the retry process. The retry code (in the primary packet header) is used by the sending node to indicate the retry phase of the packet to the destination node. The first method is known as “single-phase” retry. This is a simple retry scheme. The transaction layer on a node that implements only single-phase retry will respond with an acknowledge code of ack_busy_X to any primary packet it receives (via the link data indication) when the node is busy. The sending node sends and retries the subaction using a retry code (rt; see 6.2.5.4) of retry_X until the subaction succeeds or its retry limit is exceeded. The transaction layer has the option of requeuing the pending retry and servicing other queued requests as long as the retry limit is not exceeded. The second method is known as “dual-phase” retry, as specified by the state machine in 7.3.3.2.2. When the transaction layer becomes busy, it responds with an acknowledge code of ack_busy_A or ack_busy_B (A or B). When the subaction is retried, the retry_A is used if the ack_busy_A was previously returned or the retry_B is used if the ack_busy_B was previously returned. While the destination node is accepting retry_A retries, other subactions are marked ack_busy_B. Once all retry_A retries have been accepted, the destination node accepts retry_B retries, and other subactions are marked retry_A. This process continues in a “ping-pong” fashion, ensuring forward progress by the batch processing of A and B groups. A timeout is used to determine when all retry_A retries have completed. Source nodes using the dual-phase retry shall retry the subaction during every four fairness intervals until their retry timeout expires. Destination nodes assume all retry_A subactions have been sent when four fairness intervals pass with no retry_A subactions having been busied; the same kind of timeout is also applied to retry_B. Higher performance destination nodes may count the number of retry_l packets busied with retry_A to avoid the timeout when the last of the previously-busied ack_busy_A subactions have been retried. Note that separate retry_A/retry_B state machines are assumed for the transaction request and response queues of the destination node, so that the acceptance of transaction requests is not affected by the retry-state of transaction responses (and vice versa). Due to the tight timing constraints on the pending retry (measured in fairness intervals, which can be quite short), these retries are expected to be performed by hardware. If a source node that only implements single-phase retry receives any of the ack_busy_X, ack_busy_A, or ack_busy_B acknowledge codes, it shall retry using a retry code of retry_X. The dual-phase destination node will accept the retry_X when it has completed the current retry phase.
Q.6.3 Asynchronous arbitration Asynchronous arbitration is used whenever a link layer wants to send data packets “as soon as possible.” There are two types of asynchronous arbitration: a)
“Fair” arbitration, which guarantees equal access to the bus for all participating nodes. This prevents nodes that have a higher natural priority from dominating traffic on the bus.
Copyright © 2008 IEEE. All rights reserved.
859
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
b)
IEEE STANDARD FOR A
“Urgent” arbitration (only available on the backplane environment) to support nodes that need to use the bus more frequently with less latency. This has to be used with care, since multiple nodes using urgent arbitration can interfere with each other.
Q.6.4 Isochronous arbitration Asynchronous arbitration is adequate for nodes that do not require a guaranteed high bandwidth or low latency or a precise timing reference (less than 1 μs, for instance). However, data such as that related to digital sound or instrumentation are more efficiently handled with isochronous arbitration. Isochronous services can be provided without upsetting the basic arbitration protocol by giving the highest priority access to a “cycle master” that maintains a common clock source.32 The cycle master tries to transmit a special timing request called a “cycle start” at specific intervals set by a “cycle sync” source (nominally 8 kHz ± 100 ppm, or 125 μs ± 12.5 ns). If a transfer is in progress when the cycle sync occurs, then the cycle start will be delayed, causing significant jitter in the start time of the transfer. Since this jitter is frequently unacceptable, the amount of time that the cycle start was delayed is encoded within the packet as a transaction layer quadlet write request broadcast to the “cycle timer register” of each node. Each node with isochronous service has a 32-bit cycle timer register. The low-order 12 bits of the register are a modulo 3072 count, which increments once each 24.576 MHz clock period. The next 13 higher order bits are a count of 8 kHz cycles, and the highest order 7 bits count seconds. The cycle master copies its cycle timer register to all isochronous nodes with the cycle start request, synchronizing all nodes within a constant phase difference. Nodes sending isochronous data respond to cycle starts by immediately arbitrating for the bus without waiting for a subaction gap and sending an isochronous packet as soon as arbitration succeeds. This leads to a smaller minimum gap between isochronous packets than is needed for asynchronous arbitration to start. (The timing for gaps between isochronous packets is the same as for asynchronous acknowledges.) Only when all the nodes sending isochronous data have won arbitration and finished sending their data will the bus stay idle long enough for a subaction gap to appear. It is the subaction gap that will allow normal asynchronous arbitration to resume. Figure Q.16 illustrates the basic isochronous arbitration system.
Figure Q.16—Cycle structure 32 In the cable environment, the highest priority node is the root, so the cycle master must be the root. In the backplane environment, the cycle master uses the highest possible arbitration number (all ones).
860
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
The isochronous packets are labeled with 6-bit “channel” numbers, which have been previously assigned using the channel management protocol described in Clause 8. Since nodes sending isochronous packets still arbitrate for the bus and the natural priority of a node is not related to channel number, the order of packet transmission is also not related with channel number. When a node has been assigned a channel, it can send a variable amount of data up to a maximum specified during the bandwidth allocation protocol described in 8.3.2.3.8. This protocol will guarantee that the time consumed by all nodes sending isochronous data will not exceed the 125 μs in a cycle.
Q.7 Physical layer (PHY) The PHY has three primary functions: transmission and reception of data bits, arbitration, and provision for the electrical and mechanical interface. The cable and backplane environments have different PHYs. Nonetheless, both PHYs share two fundamental concepts: “DS” encoding for data bits, and a simple method for ensuring fair access to the bus. These similar concepts are described in Q.7.1 and Q.7.2 respectively. Concepts unique to the cable environment are described in Q.7.3, and those for the backplane environment are described in Q.7.4.
Q.7.1 Data bit transmission and reception During packet transmission, there is only a single node transmitting on the bus, so the entire media can operate in a half-duplex mode using two signals: Data and Strb. NRZ data are transmitted on Data and is accompanied by the Strb signal, which changes state whenever two consecutive NRZ data bits are the same, ensuring that a transition occurs on either Data or Strb for each data bit. A clock that transitions each bit period can be derived from the exclusive-or of Data with Strb as shown in Figure Q.17.
Figure Q.17—DS encoding The primary rationale for use of this transmission code is to improve the skew tolerance of information to be transferred across the serial bus. In particular, the code ensures that transitions occurring on Strb and Data are approximately one bit period apart.
Copyright © 2008 IEEE. All rights reserved.
861
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
An example circuit for decoding data is shown in Figure Q.18.
Figure Q.18—DS encoder and decoder example
Q.7.2 Fair arbitration The normal cable and backplane arbitration methods guarantee that only one node will be transmitting at the end of the arbitration period. As described below, these methods only provide a strict priority access; the node with the highest natural priority (highest arbitration number on a backplane, closest to the root on a cable) will always win. The normal asynchronous arbitration for the serial bus adds a simple scheme that splits the access opportunities evenly among competing nodes. The fairness protocol is based on the concept of a fairness interval. A fairness interval consists of one or more periods of bus activity separated by short idle periods called subaction gaps and is followed by a longer idle period known as an arbitration reset gap. At the end of each subaction gap, bus arbitration is used to determine the next node to transmit an asynchronous packet. This concept is shown in Figure Q.19.
Figure Q.19—Fairness interval The implementation of the fair arbitration protocol is defined in terms of these fairness intervals, as is discussed in the following subclauses. When using fair arbitration, an active node can initiate sending an asynchronous packet exactly once in each fairness interval. An active node can arbitrate only if its arb_enable signal is set. The arb_enable signal is set
862
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
to one by an arb_reset_gap and is cleared when the node wins arbitration. This disables further arbitration requests for the remainder of the fairness interval. A fairness interval ends when arbitration by the final fair node is successful; this generates an arb_reset_gap since all nodes now have their arb_enable signals reset and cannot drive the bus. The arb_reset_gap reenables arbitration on all cards and starts the next fairness interval. This process is illustrated in Figure Q.20.
Figure Q.20—Fair arbitration Note that a node sending a concatenated subaction (see Q.6.2.3) does not reset its arb_enable bit.
Q.7.3 Cable PHY The cable environment is a network of nodes connected by point-to-point links called physical connections. The physical connection consists of a port on the PHY of each node and the cable between them. A PHY can have multiple ports, which allows a branching multihop interconnect as shown in Figure Q.2. The primary restriction is that nodes have to be connected together as an acyclic graph (no loops). The cable PHY translates this physical point-to-point topology into the virtual broadcast bus expected by higher layers. The cable PHY does this by taking all data received on one port, resynchronizing it to a local clock, and repeating it out all of its other ports. The cable PHY logically consists of four major components, as shown in Figure Q.21: a)
Ports, which provide the cable media interface.
b)
Arbitration logic, which provides access to the bus.
c)
The resynchronizer, which takes received DS encoded data bits and generates data bits synchonized to a local clock.
d)
The encoder, which takes either the data being transmitted by the node (if the node has won arbitration) or the data received by the resynchronizer and encodes it in DS format.
The cable arbitration takes advantage of the point-to-point (non-bused) nature of the cable environment by having each node handshake with its immediate neighbors to determine ownership of the media. There are four phases to this scheme, three to initialize the cable configuration and one for normal arbitration.
Copyright © 2008 IEEE. All rights reserved.
863
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Figure Q.21—Cable PHY Q.7.3.1 Cable configuration Cable configuration is done in three phases: bus initialize, tree identify, and self-identify. During this process, a treelike topology is built; each node is assigned a physical node number and also sends nodespecific information that is used by the management layer.33
Q.7.3.1.1 Bus initialization process Whenever a node joins the bus, a bus reset signal forces all nodes into a special state that clears all topology information and starts the next phase. After the bus initialization process, the only information known to a node is whether it is a branch (more than one directly connected neighbor), a leaf (only a single neighbor), or isolated (unconnected). A network of leaf and branch nodes is illustrated in Figure Q.22. NOTE—In Figure Q.22 through Figure Q.29, the two arrows representing the physical connection between the nodes are just an abstract representation of line state signaling. They do not imply that the signaling uses different wire pairs for the two directions; in fact, both directions use both pairs, and the received signal is the result of the dominance of “1” over “0” over “Z.” 33
This process is illustrated in more detail in E.3.
864
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Figure Q.22—Example cable state after bus initialization process Note that each port of the node is individually numbered. There is no particular order to the numbering, it is just a way to give each port a unique label.
Q.7.3.1.2 Tree identify process After a bus initialization process, the tree identify process translates the general network topology into a tree, where one node is designated a root and all of the physical connections have a direction associated with them pointing towards the root node. The direction is set by labeling each connected port as a “parent” (connected to a node closer to the root) or “child” port (connected to a node further from the root). Any unconnected ports are labeled “off” and do not participate in further arbitration processes. Any loop in the topology is detected by a configuration time-out in the tree identify process. When the tree identify process is complete, the example configuration will have each connected port labeled child (pointing to a child node) or parent (pointing to its parent node), as shown in Figure Q.23.
Figure Q.23—Tree identify process complete
Copyright © 2008 IEEE. All rights reserved.
865
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Note that the selection of the root node is not topology dependent. It is completely acceptable that the root node also be a leaf. The only requirement is that the cycle master (the isochronous cycle master described in Q.6.4) also has to be the root, since the root has the highest natural priority. The node that has all of its connected ports identified as children becomes the root. A particular node can bias itself toward becoming the root by delaying participation in the tree identify process. Usually, the node that waits the longest time34 becomes the root. A particular node can be forced to wait a longer time by using a special PHY configuration packet (described in 16.3.2.3).
Q.7.3.1.3 Self-identify process The next step is to give each node an opportunity to select a unique physical_ID and identify itself to any management entity attached to the bus. This is needed to allow low-level power management and the building of a system topology map needed to determine the speed capabilities of each data path. The self-identify process uses a deterministic selection process, where the root node passes control of the media to the node attached to its lowest numbered connected port and waits for that node to send an “ident_done” signal, indicating that it and all of its children have identified themselves. The root then passes control to its next highest port and waits for that node to finish. When the nodes attached to all the ports of the root are finished, the root itself does a self-identify process. The child nodes use the same process in a recursive manner: the completion of the self-identify process is indicated by the bus going idle for a subaction gap period. Sending the self-ID information is done by transmitting one to four very short packets at the base rate onto the cable that include the physical_ID and some management information. The physical_ID is simply the count of the number of times a node passes through the state of receiving self-ID information before having its own opportunity to send self-ID information, i.e., the first node sending self-ID packet(s) chooses zero as its physical_ID, the second chooses one, and so on. Note that a node is not required to decode the self-ID packet; it merely has to count the number of self-identification sequences since the bus reset (this is the number of times the Self-ID Receive state described in 16.4.7 is entered). The management information included in the self-ID packet includes codes for the gap timer settings, the power needed to turn on the attached link layer, the state of the various ports (unconnected, connected to child, connected to parent), and data rate limitations.
34
Longer than a worst-case unrestricted tree identify process.
866
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure Q.24 illustrates the state of the bus after the self-identify process is complete. Note that each child port is labeled “ch-i”, meaning that the node attached to that port is identified.
Figure Q.24—Example cable state after self-identify phase
Q.7.3.2 Normal arbitration Once the self-identify process is complete, nodes can use the normal arbitration method to send packets. This process is illustrated by the following example: a)
Node A and node E begin arbitrating at the same time by sending a request to their parents. See Figure Q.25.
Figure Q.25—Arbitration request
Copyright © 2008 IEEE. All rights reserved.
867
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
b)
IEEE STANDARD FOR A
The parent of node E (node D) forwards the request to its parent (node B) and denies access to its other children (node C) by sending a data_prefix, while simultaneously the parent of node A (node B) denies access to its other children (node D). Since node B is root, it does not have to forward the request any further. See Figure Q.26.
Figure Q.26—Arbitration request (continued) c)
Instead, the root grants access to the first request (node A), while the other parent (node D) acknowledges the denial by withdrawing its request and passing on the denial. See Figure Q.27.
Figure Q.27—Arbitration grant
868
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
d)
This causes node E to withdraw its request. Simultaneously, node A receives the grant and, since it was the original requesting node,35 sends a data_prefix signal to warn all nodes that data are about to be sent. See Figure Q.28.
Figure Q.28—Data prefix e)
The parent of node A (the root in this case) sees the data prefix and withdraws the grant. At this point, the physical connections between all the nodes are now in the same state and pointed away from the node that won the arbitration. This allows the unused second signal to be turned around and used as a strobe to time the transmission of data. See Figure Q.29.
Figure Q.29—Start of data transmission Subclause 9.2 specifies the detailed algorithms of the cable environment arbitration. 35 If node A had children, they would have received a data_prefix when A started arbitration. If, however, one of the children of node A had requested the bus first, node A would have done an internal deny and passed on the request to the root, and later on the grant when it received it.
Copyright © 2008 IEEE. All rights reserved.
869
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Q.7.3.3 Speed signaling The cable environment supports multiple data rates of 98.304 Mbit/s, 196.608 Mbit/s, and 393.216 Mbit/s. (The lowest speed is known as the “base rate.”) If a higher rate is supported, then all lower rates are also required. Each node broadcasts its speed capabilities as part of the self-ID packet, and, in addition, each higher speed PHY (one capable of data rates greater than the base rate) exchanges speed information with its parent during the “ident_done” signaling at the end of the self-identify process of a node. This speed capability is recorded by both nodes for later use during normal arbitration. Since a node has already processed the “ident_done” of each of its children before passing on the “ident_done” to its parent, it then has a complete record of the speed capabilities of the nodes attached to each connected port. In normal packet transmission, a speed code is sent during the data_prefix phase of arbitration. If a directly attached node is incapable of receiving high-speed data, then it is not sent any clocked data; instead, the data_prefix is continually sent on that port until the packet is complete. This will keep the slower attached node from arbitrating while the high-speed data are sent out through the other port(s). Since the slower node propagates the data_prefix to its other ports, all devices “downstream” from that node will also be kept from arbitrating. Although this process guarantees that all nodes will arbitrate correctly, it is still possible for slower PHYs to act as blocking points for higher speed packets. To prevent this, the initiator of a transaction has to know the speed capabilities of the path between it and a responding node. On fully managed buses, this information is available from the bus manager based on data gathered from the self-ID packets.
Q.7.3.4 Cable media interface The cable media interface is the implementation of a physical connection. There are three major parts of the cable media interface: a)
The electrical interface to the cable, which consists of 1)
TPA and TPB: two low-voltage, low-current, bidirectional differential signals to carry data bits or arbitration signals.
2)
VP and VG: a power pair that provides the current needed by the PHY to repeat signals. Nodes can either source or sink current, and there can be multiple power sources on a bus.
b)
The cable connectors, which are small and rugged and provide six electrical contacts plus a shield.
c)
The cable media itself, which has two well-shielded36 signal pairs with relatively high impedance (meaning that little power is needed to drive an adequate signal), and one relatively low-impedance pair for the power.
The two signals TPA and TPB have three values: “1”, “0” and “Z”, where the “Z” value represents an undriven or idle condition. Normally there is only one node driving a “1” or a “0” on a pair at a time, but the bus reset condition is an exception: a node forcing a bus reset drives both pairs with a “1” signal. Connected nodes can detect this condition because they will detect a different signal on the pair than they expect: i.e., if one node is driving a “0” on the pair and the other is driving a “1”, then the actual received signal will be a “Z” (the positive and negative currents cancel out). The node driving the “0” shall interpret the received “Z” as a “1”, while the node driving the “1” shall always assume the received signal is a “1”. This gives the cable PHY a “l's dominant” signal mode. See Figure Q.30.
36 Shielding is actually optional, although a cable has to be very carefully constructed to avoid common-mode signal crosstalk between the pairs.
870
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Figure Q.30—Cable interface
Q.7.4 Backplane PHY The backplane environment is that of a multidrop bus. There are two signals, Data and Strb, which are shared among all of the nodes on a broadcast bus. Typically, parameters of the bus have to be tightly controlled in order to ensure proper transmission characteristics.
Q.7.4.1 Backplane arbitration The backplane environment does not have the initialization requirements of the cable environment since the topology is fixed as a broadcast bus (no repeaters) and physical addresses may be set by the host backplane (e.g., with a built-in slot identifier mechanism). The backplane arbitration scheme is bitwise comparison of an arbitration number on a dominant-mode medium. It depends on two assumptions: a)
If any node asserts the bus, then all nodes perceive the bus as asserted after a certain length of time (“wired-or” and “open-collector” are other names for this).
b)
Each node has a guaranteed unique arbitration number.
The procedure followed by competing nodes is START wait for DATA and STRB to remain unasserted for a fixed period (a gap); assert STRB;
Copyright © 2008 IEEE. All rights reserved.
871
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
for each bit in the arbitration sequence { if the arbitration bit is a one { assert DATA; wait one arbitration symbol period (sixteen arbitration clock times); } else { release DATA; wait one sample time (ten arbitration clock times); sample DATA; if DATA is asserted { lost arbitration, wait one hold time (six arbitration clock times); release STRB and go back to START } } } won arbitration, release DATA and continue to assert STRB; begin packet transmission STRB is asserted to ensure that long strings of “0” arbitration bits (when DATA is not asserted) are not interpreted as gaps between packets. The minimum time required to sample the bus after the transmission of each bit is dependent upon the length and signal propagation speed of the bus. This amount varies between the different backplane environments, but it is assumed to be less than one “sample time.” The sample time is defined to be a constant value, regardless of the interface technology, and is measured in terms of arbitration clock times. One arbitration clock time is approximately 20.345 ns (1/49.152 MHz ± 100 ppm). Once an arbitration bit is put on the bus, the transmission of the next bit in the arbitration sequence cannot begin for a sample time plus an additional “hold time.” The hold time ensures that enough time has elapsed for the bit to be sampled along the length of the bus. It is also defined as a constant value measure in terms of arbitration clock times. Because the sample time and the hold time are independent of the interface technology, the arbitration bit period (equal to the sample time plus the hold time) is the same for all backplane buses. More information on arbitration bit timing is included in Annex D.
Q.7.4.2 Urgent arbitration The backplane environment enhances the fair algorithm by splitting access opportunities among nodes based on two priority classes: “fair” and “urgent.” Nodes using an “urgent” priority may use up to three-fourths of the access opportunities, with the remaining equally shared among nodes using the “fair” priority. All nodes are required to implement the fair priority class, while the urgent priority class is optional. Packets are labeled as “urgent” if that priority class was used. The fair/urgent allocation uses the same fairness interval described in Q.7.2, but it accompanies the arbitration_enable flag with an “urgent_count.” The fair/urgent method works as follows: a)
If the bus is idle for longer than an arbitration reset gap, a fairness interval begins and all nodes shall set their “arbitration_enable” flags, while nodes implementing urgent priority shall set their “urgent_count” to three.
b)
A node that is waiting to send a packet using the fair priority class shall begin arbitrating after detecting a subaction gap as long as its arbitration_enable flag is set. If its arbitration_enable flag is cleared, it shall wait for an arbitration reset gap before it begins arbitrating. When such a node wins an arbitration contest, it sends a packet without the “urgent” label and its arbitration_enable flag is cleared.
c)
A node that is waiting to send a packet with urgent priority shall begin arbitrating after detecting a subaction gap if its urgent_count is nonzero. If its urgent_count is zero, it shall wait for an
872
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
arbitration reset gap before it begins arbitrating. Whenever such a node wins an arbitration contest, it sends a packet with the “urgent” label. d)
A node implementing urgent priority shall set its urgent_count to three whenever an unlabeled (i.e., fair) packet is transmitted or received. This includes received packets that are addressed to other nodes.
e)
A node shall decrement its urgent_count whenever a packet with the “urgent” label is transmitted or received. This includes received packets that are addressed to other nodes. This ensures that there will be at most three “urgent” packets for every “fair” packet. (This does not ensure that every node using urgent priority will obtain the bus three times each fairness interval. The node arbitrating with the highest priority will always obtain the bus before other nodes arbitrating with an urgent, but lower, priority.)
In the presence of urgent nodes, a fairness interval ends after the final fair node and up to three remaining urgent nodes have successfully accessed the bus. Since all fair nodes now have their arbitration_enable signals reset and all urgent nodes have their urgent_count decremented to zero, none of the nodes can access the bus. The bus remains idle until an arbitration_reset_gap has occurred, re-enabling arbitration on all nodes and starting the next fairness interval. This process is illustrated in Figure Q.31, which illustrates a situation where there are three nodes arbitrating for the bus with physical_IDs such that A has the highest, B is in the middle, and C has the lowest, with nodes A and C using fair priority and B using urgent.
Figure Q.31—Fair/urgent arbitration example In the backplane environment, the natural priority is the concatenation of the 4-bit urgent priority level with the physical_ID. This results in the following: —
A node using the urgent priority will always win an arbitration contest over all nodes using the fair priority.
—
The node using the highest priority level will win the arbitration contest.
—
If more than one node uses the highest priority level, then the one with the highest physical_ID will win.
Q.7.4.3 Backplane media interface The backplane media interface provides the mechanical and electrical interface that allows nodes to communicate. This includes the physical media, which consists of two single-ended conductors running the
Copyright © 2008 IEEE. All rights reserved.
873
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
length of the backplane, as well as connectors distributed along the bus, which allow nodes to “plug into” the bus. The backplane media interface also includes transceivers for the transmission and reception of signals on the physical media. Dominant mode (or “wired-or”) drivers allow all nodes to assert the bus. When in the backplane environment, the serial bus typically accompanies a standard parallel bus within an equipment chassis. In such an environment, the serial bus is extended from the backplane into each physical device using two pins reserved for a serial bus by the various IEEE bus standards. Drivers and receivers for serial bus signals follow the conventions established by the appropriate parallel bus standard: e.g., Futurebus+ using BTL, VME using TTL, and Fastbus and SCI using ECL. Power and ground are distributed as specified for the parallel bus. Example implementations of the backplane environment serial bus are included in Annex F.
Q.8 Bus management SBM describes the protocols, services, and operating procedures whereby one node exercising management level control is able to govern the operation of the remaining nodes on the bus. Within all environments the node controller component as well as CSR and configuration ROM facilities are used to configure and manage the activities at an individual node. Within the cable environment, there are two management entities defined, the isochronous resources manager and the bus manager. These two management entities may reside at different nodes or on the same node. A valid combination for management purposes is the presence of the IRM entity and the absence of the bus manager entity. In this circumstance, the isochronous resources manager exercises a subset of the management responsibilities normally assumed by the bus manager. Another valid combination is the absence of any bus manager entity, in which case no isochronous traffic is allowed. The bus manager provides the services of —
Advanced bus power management
—
Maintenance of the speed map
—
Maintenance of the topological map
—
Bus optimization based on information obtained from the topological map
The isochronous resources manager provides facilities for —
Allocation of isochronous bandwidth
—
Allocation of channel numbers
—
Selection of the cycle master
Within the backplane environment, significantly more elements are determined by the host backplane, so there is a much reduced need for any centralized level of control. The principal backplane area potentially needing management support occurs when the optional facility of isochronous data is supported.
Q.9 New features of IEEE Std 1394a-2000 The changes to IEEE Std 1394-1995 contained in IEEE Std 1394a-2000 were related to each other only in that they were incremental enhancements or extension to the base standard. This clause provides an informative description of some of these new features; the clause is intended as a foundation for the reader’s better understanding of the changes introduced by IEEE Std 1394a-2000.
874
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.9.1 Connection debounce In the cable environment, a serial bus configures itself and assigns a unique 6-bit physical_ID to each of the 63 devices that may be interconnected within a single arbitration domain. The bus initialization and configuration process is triggered by a change in connection status at any PHY port—one or more devices have been added or removed and the connection topology has changed. IEEE Std 1394-1995 specified that a change in detected bias voltage causes an instantaneous connection status change and commences bus initialization. Unfortunately, this idealized model fails to account for two aspects of the physical world: —
The connection process is asymmetric. When two nodes are connected, it is extraordinary for bias to be detected by both at the same time. The node that detects bias first immediately commences a bus reset but is unable to complete bus initialization until the other node detects bias and also commences a bus reset. During this interval, which may be on the order of tens of milliseconds, the first node is unable to send or receive packets. If that node is connected to others, that entire serial bus is unable to operate normally; and
—
The connection process is not smooth. As the plug and connector scrape together, electrical contact is made and broken many times. Bus initialization requires no more than approximately 200 µs, but the completion of the insertion proceeds at a human pace. What appears to the user as one new connection may generate a storm of connections and disconnections.
All of this occurs quickly by human standards but the disruption caused to normal bus operations is particularly serious for isochronous data. The problem of contact scrape is fairly simple to resolve—implement a connection time-out before new connections are confirmed. Disconnections may be detected immediately. There is no need to measure the connection time-out with great precision. An n-stage counter could derive a clock tick from the PHY’s 24.576 MHz clock on the order of 5 ms; an overall time-out in the vicinity of 340 ms is adequate to debounce the contact scrape. The problem of connection asymmetry is not solved by the connection timer. The first step in its solution is to require that all arbitration line states (except BUS_RESET) be ignored during the connection time-out interval. If BUS_RESET is observed, skip the remaining connection time-out interval and commence a bus reset. This works well when the connection is between two IEEE 1394a PHYs or between an isolated node with a new PHY connected to an old PHY (i.e., per IEEE Std 1394-1995) of an operational bus. In the case where an isolated node with an old PHY is connected to a new PHY of an operational bus, the old PHY generates a storm of bus resets that are propagated by the new PHY. This may be avoided if the new PHY implements an additional “reset detect” time-out of approximately 80 ms before it responds to BUS_RESET.
Q.9.2 Cable arbitration enhancements At the time IEEE Std 1394-1995 was in the final steps toward becoming a standard, a number of valuable performance enhancements had been identified. Their overall effect is to reclaim serial bus bandwidth used unnecessarily in arbitration and make it available for data transmission. This both increases the throughput of the bus as a whole and reduces the latency of individual transactions.
Q.9.2.1 Arbitrated (short) bus reset The addition of connection debounce, described in Q.9.1, does much to reduce the time the bus is unusable during bus initialization. However, even under ideal circumstances, e.g., a bus reset initiated by software, that involve no physical connection changes, bus initialization as specified by IEEE Std 1394-1995 is still
Copyright © 2008 IEEE. All rights reserved.
875
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
more time consuming than it needs to be. Bus initialization is composed of three phases—reset, tree identify, and self-identify. The last phase, self-identify, requires approximately 1 µs per node or about 70 µs worst case when there are 63 nodes. The tree identify phase is also quite rapid and takes less than 10 µs. The longest phase is bus reset, and it lasts about 167 µs while the BUS_RESET signal is propagated. The total duration of bus initialization is longer than the nominal isochronous cycle time, 125 µs, and may disrupt two isochronous periods. This compels device designers to add additional buffer depth to preserve the smooth flow of isochronous data from the perspective of their application. If sufficient time could be trimmed from bus initialization, the necessity for larger buffers could be reduced. The reason for the long duration of BUS_RESET is that a transmitting node is unable to detect this arbitration line state. It is only after packet transmission is complete that the node observes the reset. Hence, BUS_RESET must be asserted longer than the longest possible packet transmission. This guarantees the success of bus reset regardless of the bus activity in progress. Suppose a node arbitrates for and is granted control of a serial bus; then all the other nodes are in the receive state. If BUS_RESET is transmitted, all the nodes will detect it. In this case, the bus reset duration can be shortened to approximately 1.3 µs. The worst-case bus initialization time is improved from roughly 250 µs to 80 µs for a bus fully populated by 63 devices.37 Typical bus initialization times would be shorter, e.g., approximately 20 µs for a bus with 16 devices. The concept is simple, but requires analysis for the following particular cases: a)
Parent port disconnection. A prerequisite for arbitrated (short) bus reset is the ability to arbitrate. Since there is no longer a connection to the root, the long bus reset defined by IEEE Std 1394-1995 is all that is available.
b)
Child port disconnection. The node requests the bus and, if granted control of the bus, initiates a short reset. If the arbitration request ultimately fails because of an arbitration state time-out, a long bus reset is initiated.
c)
New connection (root node or a node with a parent port). After the connection time-out, the node requests the bus and, if granted control of the bus, initiates a short reset. If the arbitration request ultimately fails because of an arbitration state time-out, a long bus reset is initiated.
d)
New connection (isolated node). The isolated node should defer bus reset in anticipation that the other node, after its connection time-out, successfully arbitrates and initiates a short reset. If the isolated node fails to observe BUS_RESET within 1 s, it initiates a long bus reset.
When two buses are connected, it is extremely unlikely that timings align to produce a short bus reset. Both nodes that sense the new connection are behaving as in item c), and one likely wins arbitration before the other. When the slower node observes BUS_RESET, it initiates a long reset. Even in the event that the slower node fails to sense the reset, the other node’s bus initialization process times-out and a long bus reset results.
Q.9.2.2 Ack-accelerated arbitration The timing strategy for asynchronous arbitration specified by IEEE Std 1394-1995 is straightforward— arbitration cannot start until the bus is idle for a subaction gap time. For a bus with few hops between nodes, the subaction gap might be little more than 1 µs, while for the worst case topology, it could be slightly in excess of 13 µs. This design was adopted when simplicity, proof of concept, and time to market were of greater importance to a serial bus than the extraction of the last possible bit of bandwidth. However, the penalty of wasted bus idle time becomes increasingly onerous as transmission rates and the number of connected nodes increase. 37 The calculation is based on the assumption that worst-case PHY repeater delay and cable delay together are less than 500 ns. This would permit up to 100 m of cable.
876
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The duration of a subaction gap is determined by bus topology; it is necessary for it to be greater than the worst case round-trip propagation time between any two nodes on the bus. This ensures that, after the transmission of an asynchronous primary packet, no node starts arbitration before the acknowledge packet has been transmitted and received. Unfortunately this makes no distinction between acknowledge packets and primary packets—an acknowledge packet never follows another acknowledge packet. Arbitration can start immediately after an acknowledge packet is observed. NOTE—In a sense, this is not a new form of arbitration but exactly the form of arbitration used for isochronous packets. Since there are no acknowledge packets during the isochronous period, isochronous arbitration starts as soon as an idle gap is detected after a packet.
Q.9.2.3 Fly-by concatenation IEEE Std 1394-1995 defines one arbitration enhancement—concatenated subactions. This is a method of completing a split transaction without relinquishing the bus in between the acknowledge packet and the response packet. From the standpoint of the link that receives both the acknowledge packet and the response packet, it is impossible to distinguish between concatenated subactions and closely spaced subactions separated by an intervening arbitration. This provides an opportunity to reclaim more serial bus bandwidth for data transmission. Suppose a node has a packet ready for transmission when an unrelated packet addressed to the same node is received and acknowledged. Are there any consequences if the node concatenated the packet awaiting transmission to the acknowledge packet? This sequence of received packet, acknowledge packet and transmitted packet is indistinguishable from the concatenated subactions permitted by IEEE Std 1394-1995, except for the content of the transmitted packet. Provided that fair arbitration is observed and some timing and topology issues are considered, the serial bus operates as before. One consideration is that fly-by concatenation may be used only when the candidate packet is received on a child port or is originated by the node’s link. When a packet is received on a parent port it is likely that other nodes are simultaneously receiving the packet. If more than one node attempted fly-by concatenation, their transmitted packets would collide. When a packet is originated by the node’s link or received on a child port, packet reception is unique—it is not possible for any other node to receive the same packet on a child port at the same time. When a packet is received on a child port or is originated by the node’s link, there are two opportunities for fly-by concatenation a)
After an acknowledge packet, an unrelated asynchronous primary packet may be concatenated, or
b)
After a cycle start packet or isochronous packet, an isochronous packet may be concatenated.
Fly-by concatenation is illustrated by Figure Q.32. The transmitted packet appears concatenated on the repeating ports, but as a separate packet transmitted by the child port. The figure shows a two-port PHY with a child port at the left. At the outset, a packet is about to be received by the child port. Moving down Figure Q.32, the succeeding snapshots of serial bus state for both ports of the PHY are shown. As the received packet is repeated by the other port, it is seen to emerge, first the data prefix (now signaled as TX_DATA_PREFIX by the repeating port), then the clocked data of the packet. The packet retransmission is nearly complete as trailing TX_DATA_PREFIX is signaled by the repeating port; the use of data prefix instead of data end on retransmission signals concatenation. In the last snapshots, the concatenated packet is seen to emerge from both ports of the PHY; on the original receiving port the new packet appears as a single, unconcatenated packet.
Copyright © 2008 IEEE. All rights reserved.
877
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
RX_DATA_END
RX_DATA_PREFIX
RX_DATA_END
PHY
RX_DATA_PREFIX PHY
RX_DATA_END
RX_DATA_END
PHY PHY
TX_DATA_PREFIX
TX_DATA_PREFIX
TX_DATA_PREFIX PHY
TX_DATA_PREFIX
TX_DATA_PREFIX
TX_DATA_PREFIX
PHY
TX_DATA_PREFIX
TX_DATA_PREFIX
TX_DATA_PREFIX
PHY
TX_DATA_END
PHY
TX_DATA_PREFIX
TX_DATA_END
TX_DATA_PREFIX
Figure Q.32—Fly-by concatenation Q.9.2.4 Multi-speed packet concatenation IEEE Std 1394-1995 was published before 200 Mbit/s and faster PHYs were available. As a consequence, the details of operation at speeds other than S100 are sketchy and in some cases susceptible to multiple interpretations, each of which is arguably reasonable. As an example, IEEE Std 1394-1995 contains a contradictory requirement that PHYs signal speed only for the first packet of a multiple packet sequence but expect to observe a separate speed signal for each received packet. Apart from the interoperability problems, multi-speed packet concatenation is an essential building block for the enhancements specified by IEEE Std 1394a-2000 because it permits the following: —
Concatenation of a read response of arbitrary speed after an acknowledge packet
—
Concatenation of isochronous packets without regard to the speed of each
—
Fly-by concatenation without regard to the speed of the concatenated packet
The deficiencies of IEEE Std 1394-1995, with respect to multi-speed packet concatenation, are corrected in both the PHY/link interface specified in 9.2 and the PHY state machines and C language code in Clause 5A38. Complete interoperability with older PHYs cannot be guaranteed but is promoted by a requirement that S100 packets cannot be concatenated after faster packets.
Q.9.2.5 Arbitration enhancements and cycle start There are interoperability problems created by the enhancements described in Q.9.2.4 when utilized by nodes other than the cycle master (root). The problem arises when the cycle master needs to transmit a cycle start packet. Existing nodes give precedence to arbitration requests from child ports over their own requests. When none of the nodes implement arbitration enhancements, this is not a problem; a subaction gap appears at the end of any transaction in progress and the root, by virtue of its natural arbitration priority, wins arbitration and is able to send the cycle start packet. If some or all of the child nodes are employing arbitration enhancements, the root may be unable to win arbitration for a protracted period. IEEE Std 13941995 is designed to accommodate a delayed cycle start packet, but only up to the extent of the longest 38
Note—Clause 5A of IEEE Std 1394a-2000 was replaced by Clause 17 of IEEE Std 1394b-2002.
878
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
asynchronous primary packet. The delay caused by the root’s children could violate isochronous timing assumptions and disrupt the flow of isochronous data. The solution is to define new requests over the interface between the link and PHY so that the link may selectively disable and enable ack-accelerated and fly-by concatenation enhancements when a cycle start is due to be transmitted. All nodes except the cycle master are required to disable these accelerations from the time of their local cycle synchronization event until a cycle start packet is observed. Once the cycle start packet is observed, it is safe to reenable acceleration.
Q.9.3 Performance optimization via PHY “pinging” The simplest performance improvement that a bus manager can make is to tune the “gap count” to the topology of a serial bus. The gap count determines the value of two fundamental time intervals—the subaction gap and the arbitration reset gap. The smaller the gap count, the less idle bus time consumed by these gaps. IEEE Std 1394-1995 contains recommendations that permit the bus manager to reduce the gap count from the default 3F16 in effect after bus reset. The bus manager39 calculates the worst case round-trip propagation delay between any two nodes on the bus. The calculation should be based upon the greatest hop count between any two nodes (as determined from the self-ID packets) and an assumption that cable lengths do not exceed 4.5 m. Some implementations do not analyze the self-ID packets to determine the greatest hop count, but assume a maximum hop count of 16. Approximate as they are, neither the cable length nor maximum hop count assumption is reliable, since they are not normative requirements of IEEE Std 1394-1995. IEEE Std 1394a-2000 provides an alternate method for the bus manager to optimize gap count—the PHY “ping” packet. This is a packet that is addressed to any one of the 63 local nodes on a bus. In response, the addressed PHY returns a set of self-ID packets. The originator of the ping packet may time the transaction and calculate a round-trip time between itself and the targeted PHY. With these tools, the bus manager can readily calculate the round-trip time between any two leaf nodes, as explained in more detail in Annex M. NOTE—For the purpose of calculating the round-trip time, the contents of the packet returned by the PHY are unimportant. The return of the self-ID packet(s) permit some additional diagnostic utility in the bus manager. Alternatively, the bus manager could address some other packet, such as the remote access packets defined for the suspend / resume facility, and time the packet sent in response.
Q.9.4 Priority arbitration A fundamental part of IEEE Std 1394-1995 is the concept of fairness, which ensures that all nodes on the bus are each able to arbitrate within a bounded time period; no node may starve another node’s arbitration requests. Within any particular period (called a fairness interval) the order in which nodes are granted the bus is arbitrary, but each node is guaranteed fair access. This mechanism is useful to promote equal access to the bus, but individual nodes may consume bus time awaiting their chance to arbitrate. These inefficiencies can be significant, particularly in cases where there are few nodes attached to the bus. One opportunity to improve efficiency concerns response subactions. Since each response subaction is originally triggered by a request subaction, it is arguably true that fair arbitration for requests inherently limits the number of responses. Hence the new provision of IEEE Std 1394a-2000 that responses are always permitted to use priority arbitration. 39
In the absence of a bus manager, the IRM is permitted to optimize the gap count.
Copyright © 2008 IEEE. All rights reserved.
879
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
In the case where there are fewer nodes than the maximum of 63, the number of fair arbitration opportunities may be divided amongst them. For example, the system disk for a computer might be granted permission to use additional priority arbitration requests within a fairness interval. This would reduce the latency and increase the throughput for the transfer of data to and from the disk. Finally, for reasons of simplicity, some infrequent subactions, such as the transmission of a PHY packet, are granted exemption from the normal requirements of fair arbitration.
Q.9.5 Port disable, suspend, and resume The cable PHY arbitration state machines in IEEE Std 1394-1995 describe the behavior of connected, fully functional ports in the four bus phases—reset, tree identify, self-identify, and normal arbitration. The only other port state is disconnected; it requires little or no description. IEEE Std 1394a-2000 defines additional port states, disabled and suspended, and the protocols for orderly transition between port states. Each PHY port may independently be in one of the following four states: —
Disabled. The port generates no signals and is not capable of detecting signals. From the standpoint of a connected peer PHY, there is no observable difference between a disabled port and an unpowered PHY.
—
Disconnected. There is no physical cable connection between the port and a peer PHY.
—
Suspended. No bias is generated by this port but a physical connection exists with a peer PHY (which may or may not be generating bias). The absence of bias generated by this port permits a connection detect circuit to monitor the physical connection.
—
Active. A physical connection exists with a peer PHY and bias is both generated and observed by this port. The active state is called connected in IEEE Std 1394-1995, but IEEE Std 1394a-2000 redefines connected to mean only the detection of a peer PHY, powered or unpowered, at the other end of a cable.
The preceding four states are fundamental; additional, transitional states are defined in the state diagrams in order to accurately describe PHY behavior. An important motivation for the definition of these new states is to permit power savings in PHY implementations. In all states except active, many PHY components may be left unpowered. When all the ports of a PHY are either disabled, disconnected, or suspended, there are opportunities for substantial savings.
Q.9.5.1 Connection detect circuit Additional circuitry is required to detect the presence or absence of a physical connection. The circuit produces meaningful output only while the port itself is not generating bias.
Q.9.5.2 Suspended connection A suspended connection exists between two connected peer PHYs if the port at each end of the connection is suspended. The suspended connection is established by a protocol between the two ports, one of which is the suspend initiator and the other is the suspend target. A port becomes a suspend initiator because of the receipt of a remote command packet that sets the port’s suspend variable to one. The remote command packet may have been transmitted by the PHY’s local link or by some other node. In either case, the originating PHY arbitrated for the bus; consequently the suspend initiator has ownership of the bus to transmit a remote response packet. Subsequent to the transmission of
880
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
the remote response packet, the suspend initiator asserts the TX_SUSPEND signal for a period equal to MIN_DATA_PREFIX. A port becomes a suspend target when it observes RX_SUSPEND while in the Idle state. In response to RX_SUSPEND, the suspend target drives TpBias low and starts a timer. In the meantime, the suspend initiator idles its transmitters after signaling TX_SUSPEND for the required time. The suspend initiator then starts a timer and monitors bias. If the suspend initiator detects that bias has been removed by the suspend target, the suspend initiator in turn drives TpBias low and continues to do so for a fixed time, after which the suspend initiator enters the suspended state. If the suspend initiator’s timer expires and bias is still present, the suspend initiator enters the suspended state in a faulted condition. While the suspend target drives TpBias low it also monitors bias. If bias is removed by the suspend initiator, the handshake is complete and the suspend target enters the suspended state. Otherwise, the suspend target waits until its timer expires and then suspends even though bias is still observed. Entry into the suspended state necessitates activation of the port’s connection detect circuitry, which is usable only if the port itself does not generate bias. Each port, suspend initiator, or target delays entry into the suspended state until the output of the connection detect circuit becomes stable and indicates a physical connection. Once a port is suspended it is capable of detecting either of the following two events: a)
Physical disconnection
b)
The presence of bias
Physical disconnection causes the port to transition to the disconnected state. The effects of bias depend upon the fault state of the port. If the port completed the suspend initiator/target handshake normally and bias was removed, the presence of bias causes the port to resume normal operations. Otherwise, if the port entered the suspended state in a faulted condition (because bias was not removed by the connected peer PHY), the presence of bias has no effect until software clears the fault. Once the faulted condition is cleared, the port attempts to resume normal operations if bias is present.
Q.9.5.3 Suspended domain A suspended domain is a set of one or more suspended nodes that are physically connected through suspended nodes via suspended connections. A node without active ports and at least one suspended port is a suspended node. In order for two suspended nodes to be part of the same suspended domain, a path of suspended connections exists between them. It is possible for connected but disabled ports to split a group of physically connected suspended nodes into separate suspended domains. A suspended domain propagates as the result of suspend target behavior. When a port becomes a suspend target (as a consequence of observing RX_SUSPEND), it not only suspends the connection with its peer suspend initiator but also requests that all other active ports on the same PHY become suspend initiators. That is, during the same time that the suspend target observes RX_SUSPEND, the formerly active ports transmit TX_SUSPEND. Unless blocked, the TX_SUSPEND signal transmitted by a suspend initiator propagates until it reaches a leaf node. The propagation of the suspended domain may be blocked by a PHY compliant with IEEE Std 1394-1995 (but unmodified by IEEE Std 1394a-2000), a disabled port, or a suspended port. It is possible to control the extent of a suspended domain by disabling selected PHY ports prior to the activation of the suspend initiator. NOTE—A serial bus configuration that includes nodes compliant with IEEE Std 1394-1995 (unmodified by IEEE Std 1394a-2000) as well as nodes capable of suspension requires careful analysis by a power manager or other
Copyright © 2008 IEEE. All rights reserved.
881
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
application prior to the creation of a suspended domain. For example, if a remote PHY command packet is used to create a suspended domain and a legacy node lies on the path between the sender of the packet and the initiator of the suspended domain, the legacy node blocks the spread of the suspended domain from the suspend initiator toward the sender of the packet. In addition, the original sender of the packet subsequently has no means to cause the suspended domain to resume; it is unreachable because the legacy node perceives the connection to the suspended domain as disconnected.
Q.9.5.4 Resumption Any one of a number of events may cause a suspended port to attempt to resume normal operations —
Bias is detected and there is no fault condition.
—
Except at a boundary node, another suspended (but unfaulted) port detects bias.
—
A resume packet is received or transmitted by the PHY. The originator of the resume packet may be either the PHY’s local link or another node.
—
A remote command packet that sets the resume variable to one is addressed to the suspended port.
—
At an isolated node, another disconnected (but enabled) port detects a new connection.
If a port is in the process of suspending, any of the previous events causes the port to resume after the completion of the suspend handshake. Except for boundary nodes or the resumption of a single port by means of its resume variable, a resumption by one suspended port causes all of a PHY’s other suspended ports to initiate resumption. A suspended port initiates the resume process by generating TpBias and then waits to observe bias. Once bias is present at both ends of the cable, an active connection has been restored. Because topology changes may have occurred while connections were suspended, resumption of a connection always generates a bus reset. Heuristics are employed to minimize any proliferation of bus resets—delay a short time before initiating a bus reset, attempt to perform an arbitrated (short) bus reset if a boundary node, else delay a short while longer if not a boundary node—and in all cases defer to a detected bus reset.
Q.9.5.5 Boundary nodes Boundary nodes, on the border between an active serial bus and a suspended domain, behave differently than suspended nodes during resumption. The boundary node acts to minimize disruption of the active bus while the suspended domain resumes. After a resume event on one of its suspended ports, a boundary node waits for three RESET_DETECT intervals before it initiates an arbitrated (short) bus reset on the active bus. The delay is intended to permit all nodes in the suspended domain to resume before the active bus is made aware of their presence. If the boundary node experiences a resume event on more than one of its suspended ports, the delay is measured from the most recent resume event. If a boundary node detects BUS_RESET on any of its resumed ports during this interval, it initiates a long bus reset on the active bus. This is necessary because there is no time to arbitrate on the active bus and issue a short bus reset; bus reset is already underway on the resumed segment and must be propagated without delay.
882
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The suspended nodes that have resumed wait seven RESET_DETECT intervals before they initiate bus reset. This longer interval permits the entire suspended domain to resume and then allows time for the boundary node(s) to arbitrate on the active bus. When a suspended domain that adjoins more than one boundary node is resumed, one of the boundary nodes likely arbitrates on its active bus before the other(s) and transmits BUS_RESET into the resumed domain. When the bus reset is observed by the other boundary node(s), they respond by converting it to a long bus reset.
Q.10 New features of IEEE Std 1394b-2002 IEEE Std 1394b-2002 was an amendment to IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000. IEEE Std 1394b-2002 defined mechanisms that increase the data rate and the transmission distance for IEEE 1394 buses.
Q.10.1 The relationship to IEEE Std 1394a-2000 IEEE Std 1394a-2000 improved many areas of IEEE Std 1394-1995. Of particular note is the improvement in bus efficiency. IEEE Std 1394a-2000 provided arbitration acceleration, improved the speed of bus resets, and added suspend and resume power management capabilities to the bus. IEEE Std 1394b-2002 was fully interoperable with IEEE Std 1394a-2000 and IEEE Std 1394-1995 at the signaling level of their 6-pin and 4-pin connectors. IEEE Std 1394b-2002 supported the DS form of signaling used in IEEE Std 1394a-2000 and IEEE Std 1394-1995 while adding a new form of signaling capable of much higher data rates between Beta ports. IEEE Std 1394b-2002 also supported new media, such as CAT-5 unshielded twisted pairs (UTPs), glass optical fiber (GOF), and plastic optical fiber (POF).
Q.10.2 Faster and further IEEE Std 1394b-2002 supported the regular DS signaling modes and speeds of IEEE Std 1394-1995. Additionally, IEEE Std 1394b-2002 extended bus speeds to S800 and S1600 and had architectural support for S3200—although insufficient technical data were available when IEEE Std 1394b-2002 was prepared to specify the signaling parameters for S3200. Silicon devices that operate in both the DS signaling mode and the Beta signaling mode are called border nodes because they are at the border of the two different signaling bus segments. IEEE Std 1394-1995 recommended a maximum cable length of 4.5 m. Many applications find this length too short a cable run for their needs. IEEE Std 1394b-2002 supported optical cable lengths of 50 m for POF and 100 m for GOF. Additionally, IEEE Std 1394b-2002 supported S100 operation over lengths of CAT-5 up to 100 m. This extra run length permits new applications for IEEE 1394 buses, such as home networking.
Copyright © 2008 IEEE. All rights reserved.
883
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
Q.10.3 Nomenclature Figure Q.33 illustrates the PHY architectural framework and architectural elements possible within a Betacapable PHY. This figure is referenced by many other subclauses in this standard; when reproduced in other subclauses, the context of the subclause within the architectural framework is shown by bold lines around functional components.
Link B PHY
connection monitor
req uest/gra nt, ena bl e
L TP RX fla gs
send LTP PH Y pa ckets
con tro l
req ue st\ gra nt
pa cket da ta
po rt status
con fi g con tro l
PHY-link interface
BOSS arbitration and control state machines
p acke t contro l PHY p acke ts
packet transmit/receive TX/RX symb ol , p ort status
TX/RX symb ol , en ab les
to other ports
TX/RX symb ol
Port
Port
Betamode func tions
Connection management
DS-mode functions
Betamode functions
Connection management
Low-power signaling
Low-power signaling
TX/RX d ata si gn als, PMD con tr ol/status, a rb/co nne ct contro l/sta tus (D S onl y)
PMD
DS-mode functions
CAT-5 UTP -orG OF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
TX/RX d ata si gn als, PMD con tr ol/status, a rb/co nne ct contro l/sta tus (D S onl y)
PMD
CAT-5 UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical
Figure Q.33—Master architecture
884
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.10.4 Media—common properties All media that are used in Beta mode use the same encoding scheme (i.e., a modified version of 8B/10B), which is a form of NRZ binary signaling. Two parallel physical connections (i.e., two twisted pairs or two optical fibers) continuously send data symbols in opposite directions for full-duplex operation. Symbols are scrambled before encoding to minimize emissions. The 8B/10B encoding enforces dc balance and limits the run length of the transmitted bits that permits ac coupling and excellent control of signal integrity. All media forms are specified with the goal of having the BER less than 10–12. All media types have the same connection management. This allows the use of the same PHY for different media (with the use of a PMD module, e.g., a vertical cavity surface emitting laser (VCSEL) and photodiode for optical fiber). Thus, connecting an optical transceiver to a standard PHY is a simple matter. The dc balance feature of the symbol encoding permits the use of capacitors on the signal leads to achieve galvanic isolation.
Q.10.4.1 Short-haul shielded twisted pair (STP) cabling IEEE Std 1394b-2002 defined a new connector and its associated cable providing a roadmap to S3200. A device that will run only in Beta mode shall use the new Beta connector. DS-mode connection is achieved by using a cable with a legacy plug on one side and a bilingual plug on the other. A bilingual or Beta-only PHY port shall not be connected to either the 4- or 6-circuit sockets defined by IEEE Std 1394-1995 or IEEE Std 1394a-2000. The Beta connector is a small connector only slightly larger than the 4-circuit IEEE 1394a connector. The Beta connector includes power pins and can be keyed to indicate bilingual capability. The keying is arranged so that a bilingual plug will not mate with a Beta-only socket. The maximum cable length remains 4.5 m, as recommended by IEEE Std 1394-1995. Longer copper lengths are possible with special cables (e.g., thicker gauge wires), but are not specified in IEEE Std 1394b-2002 and require special care in complying with all the requirements of emissions and electrical interoperation.
Q.10.4.2 CAT-5 UTP cable (see Chapter 7 of ISO/IEC 11801:2002) CAT-5 UTP cable is low cost, easily installed, and readily available. CAT-5 is well known because of its use in the Ethernet standard. IEEE Std 1394b-2002 used CAT-5 in a way that is compatible with typical 100BASE-T2 Ethernet cable plant. Data are transmitted out on pin 1 and pin 2 and received on pin 7 and pin 8. This wiring matrix avoids erroneous connection to Ethernet equipment. Inputs and outputs to CAT-5 are transformer isolated. IEEE Std 1394b-2002 supported autocrossover for UTP. The electrical specifications were as other standards using CAT-5, e.g., 1 V pk-pk binary signaling. By requiring adaptive equalization in the receiver, IEEE Std 1394b-2002 achieved a maximum CAT-5 operating length of 100 m at S100. Higher speeds were not defined by IEEE Std 1394b-2002.
Q.10.4.3 Plastic optic fiber (POF) and hard polymer clad fiber (HPCF) POF consists of 1000 μm step index multimode plastic optic fiber. The optical power budget in IEEE Std 1394b-2002 permits operation up to 50 m at speeds of up to S200. HPCF consists of 225 μm graded index multimode hard polymer clad fiber and is suitable for operation up to 100 m at speeds up to S200. The same transceiver specification is used for both kinds of plastic fiber.
Copyright © 2008 IEEE. All rights reserved.
885
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
POF and HPCF are low cost and easy to install. Fiber alleviates emissions and interference problems. A simple PN style connector is specified.
Q.10.4.4 Glass fiber The GOF specification leverages VCSEL technology. IEEE Std 1394b-2002 followed the fibre channel and gigabit Ethernet specifications closely. The GOF specification uses 50 μm multimode fiber (MMF), and the optical power budget gives a media roadmap of up to S3200 at 100 m. The GOF connector is the LC connector as defined in the FOCIS 10 addendum of the ANSI/TIA/ EIA-604-93.
Q.10.4.5 Media summary for Beta-mode operation Table Q.1 summarizes the usage of various media that are defined in this standard. Entries with an “X” indicate the allowed media type and speed combinations
Table Q.1—Beta-mode media summary Media
Reach (m)
S100
CAT-5 UTP
100
X
POF
50
X
X
HPCF
100
X
X
MMF STP
S200
S400
S800
S1600
100
X
X
X
4.5
X
X
X
Q.10.5 Arbitration improvements IEEE Std 1394b-2002 made use of the continuous full-duplex nature of Beta-mode signaling to reduce the inefficiencies of arbitration idle gaps that are integral to the arbitration methods specified by IEEE Std 13941995. The gap time is a function of bus topology, dependent upon PHY repeater delays, cable lengths, and hop counts for a particular bus, and is invariant for all transmission speeds. Thus, as transmission speed increases, the idle time occupied by the gap accounts for a larger percentage of total bus occupancy time for a packet. These inefficiencies were addressed somewhat by the enhanced arbitration mechanisms in IEEE Std 1394a-2000, which also scaled well into the speed range defined by IEEE Std 1394b-2002. IEEE Std 1394b-2002 further reduced these inefficiencies using a new arbitration mechanism that allows arbitration request signaling to be pipelined and overlapped with data transmission on the full-duplex bus. This new mechanism eliminates idle gaps in a B bus as long as data exist to transmit.
Q.10.5.1 Legacy arbitration Legacy arbitration for the bus involved the following steps: —
Wait for the bus to go idle for some minimum gap time,
—
Signal to arbitrate for the bus,
—
Upon receiving a grant signal, send the data packet, and
—
Wait for the responding node to return an acknowledge packet (for asynchronous subactions).
886
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Idle time occurs between each of these steps. For asynchronous arbitration as defined by IEEE Std 1394-1995, the subaction gap time is greater than the round-trip delay time for the most distance pair of nodes on the bus. Waiting for a subaction gap time after passage of the last packet before the start of new arbitration ensures that new arbitration will not interfere with an acknowledge packet. This method of bus control is acceptable for large packets where bus efficiencies can remain above 80% on a large bus. For small packets (e.g., 64 byte data payload), the overhead time can reduce the bus efficiency to around 20% on a large bus running at S100 speeds. Increasing the bus speed to S400 reduces the large data packet efficiency to perhaps 50% and the small data packet efficiency to perhaps 10%. Thus, increasing the bus speed does not yield a proportionate increase in throughput. To increase bus efficiency, IEEE Std 1394a-2000 defined several arbitration enhancements and acceleration mechanisms: a)
ACK-accelerated arbitration. This enhancement allows a node to begin arbitration for the bus at any time following detection of an acknowledge packet (indicating the completion of a subaction) without first waiting for a subaction idle gap to occur.
b)
Fly-by concatenation. This enhancement allows a node to concatenate a packet onto the end of an acknowledge packet or isochronous packet received on a child port without first arbitrating for the bus.
c)
Multispeed concatenated packets. This enhancement allows a node to transmit concatenated packets of differing speeds, within certain criteria, without arbitrating again each time transmission speed is changed.
d)
Priority arbitration for PHY and response packets. This enhancement permits transmission of PHY packets or response packets using priority arbitration instead of fair arbitration and thereby eliminates the additional idle time required for an arbitration reset gap.
e)
Priority budget (fairness optimization). This enhancement permits the transmission of multiple asynchronous request packets by the same node within a single fairness interval as determined by a priority budget set implicitly or explicitly by the bus manager and thereby eliminates the additional idle time required for an arbitration reset gap.
Although these arbitration enhancements and accelerations can result in increased bus efficiency, they do not entirely eliminate idle gaps and their resultant inefficiency; e.g., a subaction gap is still required to indicate the end of the isochronous transmission interval, a subaction gap still occurs after an asynchronous broadcast packet or PHY packet that does not require an acknowledge, and arbitration reset gaps are still required to delimit fairness intervals. Furthermore, as data transmission rates become higher and/or interconnect distances become longer, the time required for arbitration request and grant signaling becomes greater relative to the packet data transmission time and again reduces bus efficiency. When transmission rates extend into the gigabit-per-second range and interconnect distances approach 100 m, as defined in IEEE Std 1394b-2002, the bus efficiency attainable with the legacy arbitration mechanisms becomes unacceptably low.
Q.10.5.2 New arbitration method—bus owner/supervisor/selector (BOSS) IEEE Std 1394b-2002 retained the arbitration enhancements and accelerations of IEEE Std 1394a-2000, but further improved bus efficiency by taking advantage of the full-duplex nature of Beta-mode signaling to implement a new arbitration method referred to as BOSS. In BOSS operation, arbitration request signaling is overlapped with data transmission on the full-duplex bus, and both isochronous and asynchronous requests may be pipelined for servicing in the succeeding isochronous interval or fairness interval, respectively. The BOSS arbitration scheme can work either in a bus where all nodes are compliant to this standard (i.e., a B bus) or in a bus with any mixture and configuration of nodes compliant to IEEE Std 1394b-2002 and
Copyright © 2008 IEEE. All rights reserved.
887
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
legacy nodes (i.e., a hybrid bus). This subclause introduces the concepts of BOSS operation as it works in a B bus and then describes the extensions to BOSS arbitration to support hybrid buses (see Q.10.5.2.4). Figure Q.34 illustrates the general concept of BOSS operation and shows how arbitration signaling is overlapped with data transmission on the full-duplex bus. root node # 4
Last node to send in a subaction is the “BOSS”
ch
Requests go in opposite direction to the data flow
ch
request
reques t
packet data
pack et data
p node # 0 BOSS
p node # 3 ch packet data request
ch request packet data
p node # 1
p node # 2
Figure Q.34—BOSS pipelined, overlapping arbitration
In general, a PHY transmits arbitration requests on any active port that is not transmitting packet data. The PHY that is the last to transmit packet data in a subaction (i.e., the PHY transmitting an acknowledge to a directed nonbroadcast asynchronous packet, or the primary packet originator in all other cases) becomes the “BOSS” and is responsible for taking the next arbitration decision. During packet transmission, the originator is the only PHY in the bus that can be receiving arbitration requests on every active port and is, therefore, in the best position to observe arbitration requests and to decide which node gets the bus next.
Q.10.5.2.1 Establishing the BOSS A PHY that originates packet transmission becomes BOSS immediately. Thus, transmission of an acknowledge or PHY response packet establishes a PHY as BOSS. A PHY that receives an explicit or implicit grant becomes BOSS. An explicit grant occurs when a PHY receives GRANT or GRANT_ISOCH symbols as the terminator of a received packet or in response to an arbitration request. An implicit grant occurs when a receiving PHY can independently determine that the subaction has concluded (e.g., the bus is in the isochronous interval or the last packet was an acknowledge packet in the asynchronous interval).
888
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The root in a B bus assumes the role of BOSS after any extended period of inactivity (i.e., it assumes that an acknowledge packet was missing or some other error occurred). A PHY ceases to be BOSS when it receives or when it issues an explicit or implicit grant. Q.10.5.2.2 Tokens and bus intervals
In contrast to legacy arbitration, where idle gaps are used to mark the end of the self-identify phase of bus initialization, to terminate the isochronous interval, to indicate the end of a subaction in the asynchronous interval, and to indicate a fairness interval boundary, tokens are used in BOSS operation for these purposes. A token is a specially designated Beta control symbol that is transmitted by the current BOSS for a specified minimum time to ensure reception throughout the bus. Tokens can be transmitted by the BOSS when the bus is otherwise idle or being held by transmission of DATA_NULL symbols (i.e., the token is embedded within the DATA_NULL symbol stream). As in legacy operation, packet transmission in BOSS operation is divided into isochronous and asynchronous intervals. In a B bus, the isochronous interval begins when a CYCLE_START_EVEN/ODD token and cycle start packet are transmitted by the cycle master. The isochronous interval ends when the current BOSS has no in-phase isochronous requests pending either from its link or at any active Beta port, whereupon it transmits an ASYNC_EVEN/ODD token to begin the asynchronous interval. Additionally, an ASYNC_EVEN token is transmitted by the root in a B bus to indicate the end of the self-identify phase (i.e., the last phase of bus initialization) and the start of normal arbitration. The asynchronous interval is active when the bus is not in the isochronous interval. As in legacy operation, the asynchronous interval is further divided into fairness intervals. In a B bus, the fairness interval boundary is marked by the current BOSS’s transmitting an ASYNC_EVEN/ODD token as appropriate for the new phase when it has no in-phase asynchronous requests pending either from its attached link or at any active Beta port. It is possible for the BOSS to terminate both an isochronous interval and a fairness interval using a single transmission of an ASYNC_EVEN/ODD token. To increase robustness against dropped tokens, the root in a B bus transmits ASYNC_EVEN/ODD tokens continuously when the bus is idle. Q.10.5.2.3 Arbitration requests, pipelining, and phasing
In BOSS mode, arbitration is performed with 8B/10B Beta symbols. Unlike legacy arbitration, which has only one line state to signal an arbitration request, these arbitration request symbols incorporate both an asynchronous and isochronous request code and allow multiple request types and priorities to be implemented. The availability of multiple request types and priorities, in turn, facilitates arbitration pipelining, which is a mechanism whereby requests meant to be serviced in the next isochronous interval or asynchronous fairness interval are transmitted and available to the BOSS far in advance of the BOSS’s having to make an arbitration decision on them. To fully facilitate pipelining, the concept of arbitration phase is introduced, where the arbitration phase alternates between even and odd. Both the isochronous and asynchronous intervals have phase, each of which are independent of one another. The isochronous phase advances at the end of the isochronous period (as indicated by the transmission of an ASYNC_EVEN/ODD token), and the asynchronous phase advances at each fairness interval boundary (as indicated by the transmission of an ASYNC_EVEN/ODD token corresponding to the new phase). Following bus reset, both the isochronous and asynchronous phases are defined to be even. An arbitration request may be designated for the current phase (either even or odd) or the next or opposite phase (i.e., pipelined). Beta PHYs constantly forward the highest priority asynchronous and isochronous requests (combined into a single request symbol) received from either its attached link or any active Beta
Copyright © 2008 IEEE. All rights reserved.
889
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
ports towards the current BOSS. The priority of arbitration requests is dependent upon the current bus interval and phase. Following the transmission of a packet at the end of a subaction, the current BOSS immediately grants the highest priority pending request for the current interval and phase, if any. However, if at this time the BOSS is receiving no valid in-phase requests, it transmits one or more tokens to advance the bus interval and/or phase: a)
If the bus is in the isochronous interval at the end of packet transmission and no in-phase isochronous requests are being received, the BOSS transmits an ASYNC_EVEN/ODD token to terminate the isochronous interval and advance to the asynchronous interval (but without changing the current asynchronous phase).
b)
If the bus is in the asynchronous interval at the end of packet transmission at the end of a subaction, or has entered the asynchronous interval by item a, and no in-phase asynchronous requests are being received, the BOSS transmits an ASYNC_EVEN/ODD token to advance the asynchronous phase and begin a new fairness interval.
c)
If no in-phase requests are pending for the new asynchronous phase, the BOSS grants control of the bus to its senior (i.e., the peer PHY closest to the root) so that the root eventually assumes control in an idle B bus. Once an ASYNC_EVEN/ODD token has been issued to change the phase, another token to change the phase again will not be issued until after some asynchronous packet transmission has occurred in that phase.
In the asynchronous interval, a node can make a request for the current phase only if it has any priority budget remaining for the current fairness interval, and nodes can make requests for the next asynchronous phase when they have no budget remaining. Thus, this mechanism allows fairness to be implemented in a B bus without the use of idle gaps; the bus phase is advanced only when all nodes that have data to transmit in the current fairness interval have done so. Q.10.5.2.4 Hybrid bus operation
The discussion of BOSS arbitration in Q.10.5.2.3 is specifically concerned with operation in a B bus (consisting entirely of B nodes). In a hybrid bus, this operation is modified to maintain interoperability and compatibility with legacy devices. In particular, idle gaps must be maintained as required for the legacy arbitration mechanisms. Each B cloud in a hybrid bus contains only one senior border PHY, which is the last node to originate a selfID packet without a speed code into the cloud (i.e., repeated from a DS port or generated because of a legacy link). The senior border PHY in the B cloud that contains the root is referred to as the proxy_root and acts as the default arbiter when no other PHY is acting as BOSS. (It is possible that no proxy_root exists, as the root may be a legacy PHY and, therefore, not part of any B cloud.) The parent port of a senior border (other than the proxy_root) is necessarily a DS port. The senior border in each B cloud is responsible for ensuring that the legacy gap timings are observed and is the only PHY within the cloud allowed to issue ASYNC_EVEN/ODD tokens. To synchronize legacy gap indications with BOSS token indications, the senior border issues an ASYNC_EVEN/ODD token of the current phase when it times a subaction idle gap and issues an ASYNC_EVEN/ODD token of the new phase when it times an arbitration reset idle gap. It continues to issue the tokens for the current phase so long as the bus is idle. In response to Beta arbitration requests, the senior border begins arbitration for the bus, but does so in accordance with the legacy rules for initiating arbitration to ensure consistent buswide detection of gaps. A grant can be issued (if proxy_root), or arbitration on the DS parent port can begin a)
890
Up to arb_delay following the issuance of an ASYNC_EVEN/ODD token indicating a subaction gap, provided the previous packet represented the end of a subaction (ACK-accelerated arbitration),
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
b)
At arb_delay following the issuance of an ASYNC_EVEN/ODD token indicating a subaction gap,
c)
Anytime after the arb_delay following the issuance of an ASYNC_EVEN/ODD token indicating a new fairness interval, or
d)
Within ARB_RESPONSE_DELAY after receiving a LEGACY_REQUEST or ISOCH_CURRENT request.
When the senior border wins arbitration, it begins BOSS arbitration and Beta traffic can begin. Once Beta traffic begins in a B cloud, BOSS arbitration persists until the end of a subaction has been reached and no more in-phase requests are pending from any of the nodes in the cloud. During this period of Beta traffic, legacy devices shall be prevented from detecting any idle gaps. Legacy packets are repeated by a border PHY directly to any DS ports as normal (with DATA_PREFIX replacing the payload if the packet speed is greater than the peer’s capability). For Beta packets, a border begins generating DATA_PREFIX on its DS ports. Because the border node meets minimum DATA_PREFIX/ DATA_END timings and cannot predict when the next legacy packet will arrive, it cannot safely release DATA_PREFIX until such a packet arrives. Instead, it must hold DATA_ PREFIX on the DS ports until a legacy packet arrives. The legacy packet is concatenated onto the DATA_PREFIX and is received normally by legacy devices. To ensure that border PHYs do not remain in a mode that causes them to send DATA_PREFIX indefinitely on their DS ports, the BOSS in a B cloud is required to issue a legacy null packet when the end of a subaction has been reached, no more in-phase requests are pending, and the last packet sent was not a legacy packet. At the end of Beta traffic, the current BOSS does not transmit any tokens, but instead simply grants control of the bus to its senior. Control is eventually transferred to the senior border, which begins timing the idle gap. In a hybrid bus, CYCLE_START tokens can exist only in the B cloud that contains a cycle master operating in B mode. This B cloud, if one exists, is referred to as the senior B cloud. (It is possible that no senior B cloud exists, as the cycle master may not be in a B cloud.) Any B cloud that is not the senior B cloud is referred to as a junior B cloud. Tokens cannot be transmitted across the DS connections between B clouds, and reproducing the CYCLE_START tokens in the junior B clouds is problematic. Therefore, a PHY in a junior B cloud becomes aware of the start of the isochronous interval when it receives a PH_ISOCH_PHASE_EVEN/ODD notification from an attached isochronous-capable link. This notification also informs the PHY of the isochronous phase. Upon receiving this notification, the PHY begins sending ISOCH_CURRENT arbitration requests if it has an in-phase isochronous request pending from its link. The ISOCH_CURRENT request is the highest priority isochronous request and is eventually received by the senior border; ISOCH_EVEN/ODD requests are never generated within a junior B cloud. The senior border responds to an ISOCH_CURRENT request by immediately arbitrating for the bus. Q.10.5.2.5 Legacy request phasing
A legacy node arbitrates for control of the bus by sending a TX_REQUEST signal on its parent port and sending TX_DATA_PREFIX on its child ports to deny them access to the bus. In response to this arbitration request, it receives either a RX_GRANT or RX_DATA_PREFIX signal on its parent port. If RX_GRANT is received, control of the bus has been won, and the node can begin packet transmission. If RX_DATA_PREFIX is received, arbitration has been lost, and another node has been granted control of the bus to transmit a packet. The node must withdraw the TX_REQUEST on its parent port and prepare to receive the impending packet. This signaling handshake must occur before the start of clocked packet data to avoid signal contention and interference with the packet data on the twisted pair. Various legacy packet timing constants (e.g., MIN_DATA_PREFIX, ARB_RESPONSE_DELAY) were defined so that this
Copyright © 2008 IEEE. All rights reserved.
891
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
signaling handshake would complete in time, but assumed a maximum round-trip delay of about 45 ns on the cable connection (corresponding to 4.5 m of copper twisted pair). A border node converts a received RX_REQUEST signal on a DS port to Beta LEGACY_REQUEST symbols, and arbitration proceeds in a fashion similar to a legacy node. Junior ports are denied by sending DATA_NULL on them, and LEGACY_REQUEST is sent on the senior port. If arbitration is won, a GRANT or GRANT_ISOCH is returned. If arbitration is lost, a DATA_PREFIX or DATA_NULL is returned. IEEE Std 1394b-2002 allowed Beta-mode connections of up to 100 m on CAT-5 UTP, HPCF, or MMF media, with corresponding round-trip cable delays of well over 1 μs. Such long cable delays present a problem for legacy arbitration in that the signaling handshake may not complete in time If a node is sending a LEGACY_REQUEST on its senior port and arbitration is lost, the LEGACY_REQUEST at the senior node will not be withdrawn before packet transmission begins. Because of the full-duplex nature of a Betamode connection, no danger of signal contention exists as on a DS-mode connection, but stale requests are possible. A stale request can occur when a junior node begins sending LEGACY_REQUEST at about the same time that its senior node begins transmitting a packet. If the packet is short and the cable long, the senior can complete transmission of the entire packet before receiving the first indication of LEGACY_REQUEST from the junior, which will be withdrawn as soon as the junior receives the packet. Without a mechanism for recognizing this request as stale, the senior would otherwise act on the LEGACY_REQUEST, perhaps interfering with an impending ACK. To resolve the problem of a stale LEGACY_REQUEST, the concept of legacy request phase is introduced. Each LEGACY_REQUEST symbol incorporates a 2-bit field containing a legacy request phase number, which ranges from 0 to 3. A received LEGACY_REQUEST is considered valid only if its legacy request phase number is equal to the node’s own stored value for legacy request phase. Otherwise, it is considered a stale request. (The legacy request phase does not affect requests received at a DS port; a RX_REQUEST signal received on a DS port is always considered valid and is immediately acted upon.) When a node originates a legacy packet into a Beta cloud (either as original transmitter of the packet or when repeating a packet into a Beta cloud from a DS port) and the packet is terminated with DATA_END or with GRANT or GRANT_ISOCH on the senior port, it increments its legacy request phase number. The new legacy request phase number is then communicated to all other nodes in the local Beta cloud via a LEGACY_PHASE token that completes the legacy packet’s ending symbol sequence. Receiving nodes update their own legacy request phase number with the new value contained in the LEGACY_PHASE token. If the LEGACY_PHASE token is corrupted or otherwise not received when it is expected, a receiving node increments its own legacy request phase number and uses this value when repeating the packet. Upon bus reset, the legacy request phase is set to 0.
Q.10.6 PHY-link interface This standard contains two new definitions for the PHY-link interface. The first of these interface definitions represents an evolutionary change from the legacy PHY-link interface specification. The second interface is an adaptation of the high-speed, Beta-mode serial interface that offers greater flexibility in system implementation and allows higher speeds and longer distances between the PHY and the link. Q.10.6.1 Evolutionary PHY-link interface
The evolutionary PHY-link interface is an 8-bit, parallel data interface that has been enhanced to allow data transfers at speeds of up to S800 and to support the additional request types required by IEEE Std 1394b-2002.
892
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
The evolutionary interface is specified as being more symmetrical, to avoid any deadlock or long latency situations where the link or PHY device is prevented from communicating with the other while a lengthy operation is taking place. This enhancement was made possible by inclusion of a unidirectional signaling line from the PHY to the link over which status information can be sent while the data bus is busy with packet data. Additionally, a clock is added at the link that is used when the data lines are carrying data from the link to the PHY. This additional clock allows source synchronous transfers in both directions and greatly simplifies the problems associate with moving data at high speeds. In general, the PHY device is the owner of the PHY-link interface. All serial bus packets are transferred to the link device as they are received. The link requests the use of the serial bus via the PHY device. The PHY interprets and queues the link transmit requests as appropriate. When the PHY is granted access to the bus, the PHY passes that grant to the link, which then transmits data as required. From a functional point of view, the PHY-link interface can be viewed as a master-slave interface. At any point in time, either the PHY or the link is the current owner of the interface, and a handoff mechanism to pass ownership from one to the other is defined. Q.10.6.2 Serial PHY-link interface
During the development of this standard, a great deal of effort was spent on trying to extend the capabilities of the legacy PHY-link interface. It was evident that continuing to increase the transfer speeds without making the interface wider would be difficult. It would compromise the system design not only because of the increased pin counts on the PHY and the link devices, but also because of the implications to circuit board designs, especially designs that incorporated galvanic isolation between the PHY and the link. Additional problems were encountered in trying to accommodate future voltage scaling that might cause the PHY and the link to run on different supply voltages with different signal swings. Because of these problems, a second PHY-link interface has been defined in this standard. This interface uses the standard Beta-mode signaling between the link and a fan-out PHY (FOP). The link, therefore, contains what is nearly the functional equivalent of a Beta-mode PHY. The PHY integrated into the link arbitrates directly for the serial bus by using standard BOSS arbitration, which eliminates the need for any additional signals (e.g., LREQ) between the PHY and the link. The PHY that is integrated into the link (PIL) can be a simplified version of a standard Beta-only PHY because this PHY does not participate in the tree identify or self-identify process. Additionally, because this PHY is always a leaf node, this PHY does not need to participate in the loop-free build process. To preserve software compatibility with the legacy model of the PHY-link interface, the PIL shares the node ID of the FOP. Additionally, a special packet format allows the link to transmit and receive PHY register data to and from the FOP over the two signaling pairs. This special format allows software to access the FOP as if it were attached through the legacy PHY-link interface. The new interface continues to have a LinkOn signal.
Q.10.7 Miscellaneous features Q.10.7.1 Autonegotiation
IEEE Std 1394b-2002 greatly enhanced the PHY state machines to use autonegotiation to determine the speed and mode of signaling to be used between nodes. Because nodes may be connected through optical media, there can be no assurance of seeing dc bias changes to indicate connection changes. IEEE Std 1394b2002 solved the connection change problem by the use of tones, which are detected and acted upon in an handshake manner. Autonegotiation supports dc copper connections, ac-coupled copper, and purely optical
Copyright © 2008 IEEE. All rights reserved.
893
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
connections. Beta mode is used if at all possible. DS mode is used for bilingual ports when a DS-only node is detected on the other side of the connection. Autonegotiation takes place before bus reset, tree identification, and self-identification occur. Q.10.7.2 Loop breaking
A new feature is loop breaking. Loops are automatically removed during initialization. Q.10.7.3 Power conservation improvements
IEEE Std 1394b-2002 added standby and restore features for power conservation beyond the suspend and resume features of IEEE Std 1394a-2000. Standby state is restricted to leaf nodes, and bus resets do not occur when a port enters and comes out of the Standby state. When the PHY’s port is in the Standby state, it may enter a low-power mode with power consumption similar to the consumption attained when in the suspended state. Q.10.7.3.1 Standby state
Standby state is a feature only of Beta-mode operation. The term nephew is used to label a leaf node that has a port in the Standby state. The active node connected to a nephew node is an uncle. Although a nephew does not participate in normal bus activity, the active bus, of which the nephew is a member, is not aware of a change in status of a node as it becomes a nephew, i.e., a bus reset does not occur. If a bus reset occurs while a nephew has a port in standby, then the uncle proxies self-ID packet(s) on behalf of a nephew. A node becomes nephew when it detects a standby command packet containing its node_ID and port address. A root node, a node with more than one active port, or a node that has another port already in standby cannot become a nephew. Q.10.7.3.2 Restore
The port in standby on the nephew restores from the Standby state upon detecting a restore tone from its uncle. A nephew restores its port from standby when it receives any arbitration request from its link, i.e., the nephew’s port asserts a restore tone to its uncle. Upon detecting or generating a restore tone, a nephew begins monitoring for a PHY packet. The PHY packet contains information used by the nephew to restore context, i.e., bus phase, node_ID, gap count, and gap count sticky bit status. A multiport node with one connected port in standby restores that port followed by a bus reset if, on any of its other ports, it detects a resume or a new connection.
Q.11 New features of IEEE Std 1394c-2006 Q.11.1 Scope IEEE Std 1394c-2006 was a full-use standard that amended the base IEEE 1394 document set (i.e., IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000 and IEEE Std 1394b-2002) to specify alternate PHY(s) that provide greater than S100 data rate over Category 5 (CAT-5) or better cable. This PHY is capable of negotiating with a peer device to select the appropriate next higher protocol layer.
894
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.11.2 Purpose Technology advances made gigabit signaling over UTP cables a feasible and attractive extension to IEEE Std 1394. This extension allowed S800 (and possibly higher) video and audio networks to be built with a CAT-5 (or better) UTP cable plant instead of optical fiber. A negotiation method was defined to allow peer devices to select the appropriate connection supported at both ends
Q.11.3 T-mode features IEEE Std 1394c-2006 defined mechanisms that allow S800 IEEE 1394 connections over CAT-5e or better UTP cables and supported negotiation between peer devices to allow either a IEEE 1394 connection or an IEEE 802.3 connection. The amendment also provided a mode of port operation known as T-mode. A port operating in T-mode transmits control, arbitration, and data as specified for Beta mode over UTP at S800 speeds. This amendment also updated some timing constants and algorithms in order to support larger diameter networks (up to 80 µs round-trip time between any two nodes).
Q.11.4 The relationship of T-mode to Beta mode A T-mode port uses the arbitration tokens, control tokens, and packet formats defined for use in Beta mode unchanged. The encoding translates these into 10-bit symbols, using an encoding specific to T-mode. In particular, this encoding is unrelated to the 8B10B encoding used for Beta mode ports. BOSS arbitration as specified for Beta mode is used unchanged. A PHY may have any number of ports operating in DS mode, Beta mode, or T-mode. The T-mode ports always operate at S800.
Q.11.5 The relationship to IEEE Std 802.3-2005 A T-mode port uses the PHY encoding/decoding defined in Clause 40 of IEEE Std 802.3-2005 to transmit Beta mode control, arbitration, and data over UTP. A T-mode port uses connection negotiation similar to IEEE 802.3 Auto-Negotiation, as defined in Clause 28, Annex 28A, Annex 28B, Annex 28C, Annex 28D, Annex 40.5, and Annex 40C of IEEE Std 802.3-2005. On a new connection, T-mode port negotiation and IEEE 802.3 Auto-Negotiation run in parallel using distinct twisted pairs to determine the operating mode for the connection.
Q.11.6 S800 over UTP In the transmitting direction, a stream of data bytes, arbitration requests, and control signals is mapped to a stream of bytes that is in turn passed to the PMD layer, as illustrated in Figure Q.35. The adaptation layer encodes data bytes, requests, and control tokens into 10-bit symbols. The resulting 10-bit symbol stream is then transmitted as a stream of IEEE 802.3 (Clause 40) 8-bit bytes, on a five-to-four basis, i.e., five 8-bit bytes are transmitted for every four 10-bit symbols. In the receiving direction, a stream of data bytes is received from the PMD layer and converted back to the original sequence of data bytes, arbitration requests, and control signals. The encoding scheme allows a robust decode that can recover essential arbitration and control signaling in the presence of data byte errors. The time taken to transmit a data byte, arbitration request, or control symbol is identical to a symbol time on a port operating according to Clause 13 at S800.
Copyright © 2008 IEEE. All rights reserved.
895
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
data byte (8 bits)
control token
request
request mapping
control token mapping
request symbol (6 bits)
control symbol (4 bits)
10-bit symbols adaptation layer 8-bit bytes IEEE 802.3 PHY - PMD LAYER Figure Q.35—T-mode coding functions
Q.11.7 Twin-mode ports IEEE Std 1394c-2006 allowed for a port interfacing through a single media interface connector as specified in 12.4.4 to support both operation in T-mode and operation in 802_mode. Such a port is known as a twinmode port. T-mode negotiation and IEEE 802.3 Auto-Negotiation take place in parallel, and the port selects the mode of operation appropriate to the peer port. 802_mode is selected if the peer device supports only the IEEE 802.3 specification; T-mode is selected if the peer port also supports T-mode.
Q.12 New features of IEEE Std 1394-2008 IEEE Std 1394-2008 is a full-use standard that incorporates the contents of IEEE Std 1394-1995 as revised by IEEE Std 1394a-2000, IEEE Std 1394b-2002, and IEEE Std 1394c-2006. In addition, the following new features have been added:
Q.12.1 Errata Over 100 errata have been corrected (per 1394 Trade Association TB2002001 [B2] and TB0002 [B3].)
Q.12.2 Enhanced UTP PMD The UTP PMD specification (Clause 12) has been enhanced to include operation over UTP connections at the S200 and S400 data rates as well as S100.
896
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Q.12.3 Beta PMD electrical specification A number of corrections have been made to the Beta PMD electrical specification (see 9.3), particularly at the S1600 data rate. Specifications for S3200 operation have also been incorporated.
Q.12.4 Beta Plus PHY-link interface Specifications for the Beta Plus PHY-link interface, which specifies operation at S1600 and S3200, have been added in Clause 17.
Q.12.5 Bus topology determination A new annex entitled “Deriving Bus Topology from Self-ID Packets” has been added (Annex P.) This annex, which was adapted from IEEE Std 1394.1, gives a more efficient procedure for reestablishing the network topology after a bus reset.
Q.12.6 Document organization Where necessary, editorial restructuring has been done to improve the organization and readability of the document. The major changes are as follows: —
To simplify the terminology used to describe ports that are compliant with IEEE Std 1394a-2000, the concept of an Alpha port has been introduced.
—
Clause 4, which formerly had specifications for all the short-haul copper connectors and cables as well as most of the DS-mode specifications, has been simplified to include only the specifications for the 6-circuit, 4-circuit, and 9-circuit (Beta and bilingual) connectors and cables.
—
Clause 9, which formerly contained only the Beta mode short-haul copper specifications has been expanded to include the DS mode specification as well.
—
Clause 17, which formerly contained the Beta PHY-link specification, has been expanded to include the Alpha and Beta Plus PHY-link specifications as well.
—
All of the PHY-related C code has been consolidated in Clause 19. NOTE—There is still a small amount of C code in Clause 6, Clause 7, and Clause 8 that is concerned with the link, transaction, and management layers, respectively.
—
Definitions of terms that are either new or changed are provided in Clause 3. Definitions of terms that are included in the IEEE Authoritative Dictionary of Standards Terms [B22] have been moved to the glossary (Annex R.)
—
The summary description has been moved from Clause 3 to this annex. The list of normative references has been moved from Clause 1 to Clause 2.
Copyright © 2008 IEEE. All rights reserved.
897
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
898
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
Annex R (informative)
Glossary This annex contains material that is also included in The Authoritative Dictionary of IEEE Standards Terms [B22].
R.1 Conformance The IEEE Standards Style Manual defines several keywords to differentiate between different levels of requirements and optionality, as follows: expected: A keyword used to describe the behavior of the hardware or software in the design models assumed by this standard. Other hardware and software design models may also be implemented. ignored: A keyword that describes bits, bytes, quadlets, octlets, or fields whose values are not checked by the recipient. may: A keyword that indicates flexibility of choice with no implied preference. reserved: A keyword used to describe objects—bits, bytes, quadlets, octlets, and fields—or the code values assigned to these objects where either the object or the code value is set aside for future standardization. Usage and interpretation may be specified by future extensions to this or other standards. A reserved object shall be zeroed or, upon development of a future standard, set to a value specified by such a standard. The recipient of a reserved object shall not check its value. The recipient of a defined object shall check its value and reject reserved code values. shall: A keyword indicating a mandatory requirement. Designers are required to implement all such mandatory requirements to ensure interoperability with other products conforming to this standard. should: A keyword indicating flexibility of choice with a strongly preferred alternative. Equivalent to the phrase “is recommended.”
R.2 Definitions R.2.1 acknowledge gap: The period of idle bus between the end of a packet and the start of an acknowledge. R.2.2 acknowledge: An acknowledge packet. R.2.3 acronym: A contrived reduction of nomenclature yielding mnemonics (ACRONYM). R.2.4 active port: A connected, enabled port that is capable of detecting all serial bus signal states and participating in the reset, tree identify, self-identify, and normal arbitration phases. R.2.5 application environment: The physical environment of a backplane serial bus. This includes the bus itself, the modules, and the system that contains them. This environment may be a standardized host
Copyright © 2008 IEEE. All rights reserved.
899
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
backplane (e.g., a Futurebus+® profile) that describes signal requirements, transceivers, mechanical arrangement of the modules, and temperature range over which operation is guaranteed. R.2.6 arbitration clock rate: The rate used to define a number of timing requirements within the backplane physical layer (PHY). It is 49.152 MHz ± 100 ppm, regardless of the backplane interface technology. R.2.7 arbitration sequence: For the backplane environment, a set of bits transmitted by nodes that wish to transmit packets that is used to determine which node will be able to transmit next. R.2.8 arbitration signal: Bidirectional signal exchanged between nodes during arbitration. One of the protocol data units (PDUs) for the physical layer (PHY) (the other is the data bit). R.2.9 arbitration signaling: In an Alpha cloud, a protocol for the exchange of bidirectional, unclocked signals between nodes during arbitration. In a B cloud, the exchange of arbitration tokens. R.2.10 arbitration: The process by which nodes compete for control of the bus. Upon completion of arbitration, the winning node is able to transmit a packet or initiate a short bus reset. R.2.11 attached peer physical layer (PHY): A peer cable PHY at the other end of a particular physical connection from the local PHY. R.2.12 backplane physical layer (PHY): The version of the PHY applicable to the serial bus backplane environment. R.2.13 broadcast_physical_ID: A physical_ID with a value of 1111112. R.2.14 byte: Eight bits of data. R.2.15 cable physical layer (PHY): The version of the PHY applicable to the serial bus cable environment. R.2.16 connected physical layer (PHY): A peer cable PHY at the other end of a particular physical connection from the local PHY. R.2.17 CSR architecture: ISO/IEC 13213:1994 [IEEE Std 1212, 1994 Edition], Information technology— Micro-processor systems—Control and Status Registers (CSR) Architecture for microcomputer buses. R.2.18 cycle master: The node that generates the periodic cycle start packet 8000 times a second. R.2.19 destination: A node that is addressed by a packet. If the destination is individually addressed by a source, then it has to return an acknowledge packet. R.2.20 disabled port: A port configured to not transmit, receive, or repeat serial bus signals. A disabled port shall be reported as disconnected in a physical layer’s (PHY’s) self-identifier (self-ID) packet(s). R.2.21 dispersion slope: The rate of change of the chromatic dispersion of a fiber with wavelength. R.2.22 doublet: Two bytes, or 16 bits, of data. R.2.23 dribble bits: Extra bits added to the end of a packet that allow extra synchronization in implementations. R.2.24 gap: A period of idle bus.
900
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
R.2.25 initial units space: A portion of initial node space with a base address of FFFF F000 80016. Initial units space is adjacent to and above initial register space. The command and status registers (CSRs) and other facilities defined by unit architectures are expected to lie within this space. R.2.26 isochronous channel: A relationship between a talker and one or more listeners, identified by a channel number. One packet for each channel is sent during each isochronous cycle. Channel numbers are assigned using the isochronous resource management facilities. R.2.27 isochronous cycle: An operating mode of the bus that begins after a cycle start is sent and ends when a subaction gap is detected. During an isochronous cycle, only isochronous subactions may occur. An isochronous cycle begins every 125 μs, on average. R.2.28 isochronous gap: For an isochronous subaction, the period of idle bus that precedes arbitration. R.2.29 isochronous period: A period that begins after a cycle start packet is sent and ends when a subaction gap is detected. During an isochronous period, only isochronous subactions may occur. An isochronous period begins, on average, every 125 µs. R.2.30 isolated node: A node without active ports; the node’s ports may be disabled, disconnected, or suspended in any combination. R.2.31 listener: An application at a node that receives a stream packet. R.2.32 local_bus_ID: A bus_ID with a value of 11111111112. R.2.33 natural priority: The order of packet transmission of a node given that all nodes start arbitration at the same instant using the same priority level. For the cable environment, the closer a node is to the root, the higher its natural priority. For the backplane environment, the priority level and node_offset are concatenated to give its natural priority. R.2.34 nibble: Four bits of data. R.2.35 node controller: A component within a node that provides a coordination point for management functions exclusively local to a given node and involving the application, transaction, link, and physical elements located at that node. R.2.36 node identifier (ID): A 16-bit number that uniquely differentiates a node from all other nodes within a group of interconnected buses. The 10 most significant bits (MSBs) of node_ID are the same for all nodes on the same bus; this number is the bus_ID. The 6 least significant bits (LSBs) of node_ID are unique for each node on the same bus; this number is called the physical_ID. The physical_ID is assigned as a consequence of bus initialization. R.2.37 nonreturn to zero (NRZ): A signaling technique in which a polarity level high represents a logical “1” (one) and a polarity level low represents a logical level “0” (zero). R.2.38 path: The concatenation of all the physical links between the link layers of two nodes. R.2.39 payload: The portion of a primary packet that contains data defined by an application. R.2.40 peer: Service layer on a remote node at the same level. For instance, a “peer link layer” is the link layer on a different node. R.2.41 physical connection: The full-duplex physical layer (PHY) association between directly connected nodes. In the case of the cable PHY, this is a pair of physical links running in opposite directions.
Copyright © 2008 IEEE. All rights reserved.
901
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
R.2.42 protocol data unit (PDU): Information delivered as a unit between peer entities that may contain control information, address information, and data. R.2.43 quadlet aligned address: An address with zeros in the 2 least significant bits (LSBs). R.2.44 quadlet: Four bytes, or 32 bits, of data. R.2.45 radial overfilled launch (OFL): A launch condition created when a multimode fiber (MMF) is illuminated by the coherent optical output of a source operating in its lowest order transverse mode in a manner that excites predominantly the radial modes of the MMF. R.2.46 relative intensity noise (RIN): The ratio of the variance in the optical power to the average optical power. R.2.47 repeating port: A transmitting port on a physical layer (PHY) that is repeating a packet from the PHY’s receiving port. R.2.48 resuming port: A previously suspended port that has observed signaling other than the connection tone or has been instructed to resume. In either case, the resuming port engages in a protocol with its connected peer physical layer (PHY) to reestablish normal operations and become active. R.2.49 rms spectral width: The optical wavelength range as measured by ANSI/TIA/EIA-455-127-91. R.2.50 serial bus management (SBM): The set of protocols, services, and operating procedures that monitors and controls the various serial bus layers: physical, link, and transaction. NOTE—See Figure Q.4 for the relation of SBM to the Serial Bus Protocol (SBP) stack.
R.2.51 service primitive: A specific service provided by a particular protocol layer entity. R.2.52 source: A node that initiates a bus transfer. R.2.53 speed code: The code used to indicate bit rates for serial bus. R.2.54 suspend initiator: An active port that transmits the TX_SUSPEND signal and engages in a protocol with its connected peer physical layer (PHY) to suspend the connection. R.2.55 suspend target: An active port that receives the SUSPEND configuration request or observes the RX_SUSPEND signal. A suspend target requests that all of the other active ports on the physical layer (PHY) become suspend initiators while the suspend target port engages in a protocol with its connected peer PHY to suspend the connection. R.2.56 suspended domain: One or more suspended nodes linked by suspended connection(s). Two nodes are part of the same suspended domain if there is a physical connection between them and all ports on the path are suspended. A boundary node is adjacent to one or more suspended domain(s) but not part of the suspended domain(s). R.2.57 suspended node: An isolated node with at least one port that is suspended. R.2.58 suspended port: A connected port not operational for normal serial bus arbitration, but otherwise capable of detecting either a physical cable disconnection or a resume signal. R.2.59 talker: An application at a node that transmits a stream packet.
902
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
HIGH-PERFORMANCE SERIAL BUS
IEEE Std 1394-2008
R.2.60 transaction layer: The Serial Bus Protocol (SBP) layer that defines a request-response protocol for read, write, and lock operations. R.2.61 transaction: A request and the optional, corresponding response. R.2.62 unified transaction: A transaction that is completed in a single subaction. R.2.63 zero dispersion wavelength: The wavelength where the chromatic dispersion of a fiber is at its minimum.
Copyright © 2008 IEEE. All rights reserved.
903
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
904
IEEE STANDARD FOR A
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
HIGH-PERFORMANCE SERIAL BUS
Annex S (informative)
Bibliography [B1] 1394 Trade Association Document 2001018, IDB-1394 Automotive Specification 1.0,” Mar. 18, 2003.40 [B2] 1394 Trade Association Technical Bulletin TB2002001, “1394 Clarifications and Errata 2.0,” updated Dec. 14, 2006. [B3] 1394 Trade Association Technical Bulletin TB0002, “1394a-2000 Connector Socket and Plug,” Feb. 26, 2001. [B4] 1394 Trade Association Technical Specification TS2006001, “Enhanced UTP PMD for IEEE 1394b,” Dec. 17, 2006. [B5] 1394 Trade Association Technical Specification TS2006002, “1394 Beta Plus PHY-Link Interface,” Feb. 8, 2007. [B6] 1394 Trade Association Technical Specification TS2007010, “S3200 Electrical Specification,” Apr. 15, 2008. [B7] ANSI/EIA 364-06B-00, Contact Resistance Test Procedure for Electrical Connectors.41 [B8] ANSI/EIA 364-18-84, Visual and Dimensional Inspection Procedure for Electrical Connectors. [B9] ANSI/EIA 364-21C-00, Insulation Resistance Test Procedure for Electrical Connectors, Sockets and Coaxial Contacts. [B10] ANSI/EIA 364-31B-00, Humidity Test Procedure for Electrical Connectors and Sockets. [B11] ANSI/EIA 364-32C-00, Thermal Shock (Temperature Cycling) Test Procedure for Electrical Connectors and Sockets. [B12] ANSI/EIA 364-38B-99, Cable Pull-Out Test Procedure for Electrical Connectors. [B13] ANSI/EIA 364-D-7-01, Classifications.
Electrical
Connector
Test
Procedures
Including
Environmental
[B14] ASME Y14.2M-2003, Line conventions & lettering.42 [B15] ASME Y14.5M-2004, Dimensioning and tolerancing.
40 1394 Trade Association publications are available from the 1394 Trade Association, 150 East Southlake Boulevard, Suite 220, Southlake, TX 76092 USA (http://www.1394ta.org/). 41EIA publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com). 42 ASME publications are available from the American Society of Mechanical Engineers, 3 Park Avenue, New York, NY 10016-5990, USA (http://www.asme.org/).
Copyright © 2008 IEEE. All rights reserved.
905
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 1394-2008
IEEE STANDARD FOR A
[B16] The EEC CE Marking Directive.43 [B17] The EEC EMC Directive. [B18] The EEC Low Voltage Directive (as amended by the CE Marking Directive). [B19] The EEC Telecommunications Terminal Equipment Directive. [B20] IEC 60793-1-1, Optical fibres—Part 1-1: Measurement methods and test procedures—General and guidance.44 [B21] IEC 60793-2, Optical fibres—Part 2: Product specifications—General. [B22] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.45 [B23] IEEE Std 896.2™-1991, IEEE Standard for Futurebus+®—Physical Layer and Profile Specification. [B24] IEEE Std 896.5™-1993, IEEE Standard for Futurebus+®—Profile M (Military). [B25] IEEE Std 1596™, IEEE Standard for Scalable Coherent Interface (SCI). [B26] ISO/IEC 10857:1994 [IEEE Std 896.1, 1994 Edition], Information technology — Microprocessor systems-Futurebus+® — Logical Protocol Specification.46 [B27] Japanese Ministry of Posts and Telecom Law for Electric Equipment, Wired Electric Communication Detailed Law 17. [B28] Japanese Ministry of Trading and Industry, Dentori Law. [B29] Japanese Ministry of Construction, Fire Law. [B30] JEIDA-37, Japanese Ministry of Trading and Industry, Electronic Equipment Technology Criteria. [B31] NFPA 70-2005, National Electric Code® (NEC®).47 [B32] NFPA 75-2003, Standard for the Protection of Information Technology Equipment. [B33] Widmer, A. X., and Franaszek, P. A., “A DC-Balanced, Partitioned-Block, 8B/10B Transmission Code,” IBM Journal of Research and Development, vol. 27, no. 5, pp. 440-451, Sept. 1983.” 43EEC publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com). 44 IEC publications are available from the Sales Department of the International Electrotechnical Commission, Case Postale 131, 3, rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse (http://www.iec.ch/). IEC publications are also available in the United States from the Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http:// www.ansi.org/). 45 IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/). 46ISO/IEC publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse (http://www.iso.ch/). ISO/IEC publications are also available in the United States from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA (http://global.ihs.com/). Electronic copies are available in the United States from the American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http:// www.ansi.org/). 47 NFPA publications are available from Publications Sales, National Fire Protection Association, 1 Batterymarch Park, P.O. Box 9101, Quincy, MA 02269-9101, USA (http://www.nfpa.org/).
906
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: University of Wisconsin. Downloaded on October 02,2012 at 09:19:22 UTC from IEEE Xplore. Restrictions apply.
