Standard Ieee 1394 Firewire

IEEE Standards IEEE Std 1394b™-2002 (Amendment to IEEE Std 1394™-1995) 1394b TM IEEE Standard for a High-Performance...

Author: Wasim Ahmed Khan | Abdul Raouf S.I.

69 downloads 1329 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

IEEE Standards

IEEE Std 1394b™-2002 (Amendment to IEEE Std 1394™-1995)

1394b

TM

IEEE Standard for a High-Performance Serial Bus—Amendment 2

IEEE Computer Society Sponsored by the Microprocessor and Microcomputer Standards Committee

Published by The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA 14 December 2002

Print: SH94986 PDF: SS94986

Recognized as an American National Standard (ANSI)

IEEE Std 1394b™-2002 (Amendment to IEEE Std 1394™-1995)

IEEE Standard for a High-Performance Serial Bus—Amendment 2

Sponsor

Microprocessor and Microcomputer Standards Committee of the IEEE Computer Society Approved 1 August 2002

American National Standards Institute Approved 20 March 2002

IEEE-SA Standards Board

Abstract: Supplemental information for a high-speed serial bus that integrates well with most IEEE standard 32-bit and 64-bit parallel buses is specified. It is intended to extend the usefulness of a low-cost interconnect between external peripherals. This standard follows the IEEE Std 1212™-2001 Command and Status Register (CSR) architecture. Keywords: bus, computers, high-speed serial bus, interconnect

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2002 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 14 December 2002. Printed in the United States of America. IEEE is a trademark in the U.S. Patent and Trademark Office owned by the Institute of Electrical and Electronics Engineers, Incorporated.

Print: PDF:

ISBN 0-7381-3253-5 ISBN 0-7381-3254-3

SH94986 SS94986

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.

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 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. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA Note: Attention is called to the possibility that implementation of this standard may require use of subject 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. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. 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.

Introduction (This introduction is not part of IEEE Std 1394b-2002, IEEE Standard for a High-Performance Serial Bus—Amendment 2.)

Work on IEEE Std 1394b-2002 was begun in the winter of 1997 at a meeting of the 1394TA in Eindhoven. By that time, it had become evident that IEEE Std 1394-1995 was going to be widely deployed and that many devices, especially new, digital consumer products, were going to have IEEE 1394 as the primary external interface. In the first meetings of this group, considerable sentiment existed for broadening the number and types of devices that would be able to use the IEEE 1394 interface and thereby making the interface more valuable to the end user. While attempting to broaden the scope of the IEEE 1394 interface, two barriers were discovered that made wider deployment difficult: the interface was constrained to operate over a fairly short distance and it could not handle higher data rates. After some preliminary investigations, the group concluded that these problems were best solved by a change in coding. While the data-strobe (DS) coding used in IEEE Std 1394-1995 was a simple, selfclocking scheme, the fact that it is not dc balanced made it impractical to use over longer distances. Furthermore, accumulated skew on a long-distance connection makes it hard to maintain the timing relationships between the data and the strobe lines, especially at higher data rates. The group rapidly converged on the notion of using a variant of 8B/10B coding developed by IBM for the longer distances and higher speeds defined in IEEE Std 1394b-2002. Where the connection between devices was copper cable of 5 m or less, some or all of the ports on a new physical layer (PHY) developed to support this standard could be able to signal using either DS or the new signaling scheme (dubbed Beta mode). These bilingual ports would be able to select the optimum signaling method for the connection and thereby be able to fully interoperate with existing devices that are compliant with IEEE Std 1394-1995 and IEEE Std 1394a™-2000. The new signalling system provided a route to solving a second major problem, i.e., the lack of scalability of the IEEE 1394 arbitration scheme as signaling rates are increased. The use of 8B/10B encoding allows the transmission of data to be overlapped with the transmission of arbitration signals in the reverse direction. The use of overlapped arbitration is extended by one level of pipelining, with the result that in a purely IEEE 1394b bus the need for arbitration gaps is entirely eliminated. In fact, on a bus with all connections operating in Beta mode, the setting of gap count has no utility as the bus is completely self-timed. As work progressed, the group became interested in applying the new coding scheme to a large variety of interconnect media including plastic optical fiber (POF), glass optical fiber (GOF), and Category 5 (CAT-5) unshielded twisted pair (UTP). This goal greatly expanded the scope of the work and made it necessary to divide the IEEE P1394b Working Group into various task groups. The leaders of these groups were largely responsible for the development of IEEE Std 1394b-2002. Because of the length of the project, some of the task groups had more than one leader. The task groups, their leaders, and their contributions are as follows: — Glass Fiber. Colin Whitby-Strevens. This group adopted the work from the Fibre Channel specification for use in IEEE Std 1394b-2002. The jitter work done in this group was adapted for use in all the media. — Plastic Fiber. Taka Fujimori, Shuntaro Yamazaki, Victoria K. M. Teng, and Kazuki Nakamura. This group actually developed a standard around a single connector that allowed interoperation and intermating of both plastic fiber or large-diameter hard polymer clad fiber (HPCF). This connector can be used at a speed of S100. — UTP5. Colin Whitby-Strevens and Alistair Coles. This group built on work done in the 100BaseT standard with extensive changes to simplify the coding and transmission over CAT-5 UTP.

Copyright © 2002 IEEE. All rights reserved.

iii

— Standard Electrical. Eric Hannah. This group provided the electrical characteristics for the baseline PHY. This required a great deal of simulation work by Eric Hannah in support of the Cable & Connector task group. — Start-up Protocol. Colin Whitby-Strevens. This group created the mechanisms that allow a B PHY to determine whether it is attached to another B PHY and to select the signaling frequency before the connection is completed. Peng Zhang and Jim Nave proposed the speed signaling scheme using a toning mechanism. This was enhanced by Colin Whitby-Strevens to deal with all the connectivity aspects of B ports. The loop-breaking protocol was developed by Jerry Hauck and David Wooten. — Cable & Connector. Max Bassler. This group originally tried to characterize the 4- and 6-circuit connectors used in IEEE Std 1394-1995 and IEEE Std 1394a-2000 for use at the higher speeds defined in IEEE Std 1394b-2002. This work was abandoned after two years, and a new, small form-factor connector was developed by Dave Brunker for use on devices capable of Beta-mode signaling. — Protocol Accelerations. David LaFollette, Alistair Coles, and Mike Teener. This group developed the bus owner/supervisor/selector (BOSS) arbitration scheme that is the basis for all of the arbitration and control. The original concepts were proposed by David LaFollette and Jerry Hauck. Their work was supplemented by contributions from Alistair Coles, Mike Teener, Jim Skidmore, and David Wooten. — Port Logic. Alistair Coles. This group developed the coding and scrambling methods used for Beta ports. Alistair Coles and Eric Deliot developed the single character control codes and arbitration tokens. This group also selected the scrambling method for the symbols. The method of dealing with deletable symbols was adapted from the Fibre Channel specification by Jerry Hauck and Mike Teener. — Simulation. Jerry Hauck. This group did computer simulations of the various pieces of the B PHY, but most of the simulation was mental and took place in Jerry Hauck’s mind. This turned out to be a much more efficient method of finding problems than a computer simulation. — Low-power. Richard Churchill and Steve Bard. This group developed the standby-restore protocol. — PHY-link/PIL-FOP. Martin Sodos, Sean Killeen, and David Wooten. This group developed the source synchronous version of the PHY-link interface and the PIL-FOP interface. The point-topoint (P2P) packet protocol for sending in-band status and register information between the PHY that is integrated into the link (PIL) and the fan-out PHY (FOP) was developed by Jerry Hauck and David Wooten. — C code. Colin Whitby-Strevens. Although not done as a formal task group, the work that Colin Whitby-Strevens did in developing and maintaining the C code for the standard bears special recognition. The IEEE P1394b Working Group first met under the chairmanship of Mike Teener in January 1997. David Wooten became chair within a few months, and the working group continued to meet approximately every month until the editorial work was completed in October of 1999 at which time the working group voted to go to ballot. The proposed standard was balloted in March and April of 2000 with over 80% of the votes in favor. A Ballot Response Committee (BRC) was formed to review the comments. Those comments pointed out many significant omissions and errors in the draft that the BRC corrected over the next seven months of meetings. The BRC completed its work on this standard in February of 2001. The ballot for the February 2001 version of the standard passed but with comments that pointed out some flaws that would need to be corrected before the standard could be released. The BRC met several times from June to September and completed work on a new version of the standard in September of 2001.

iv


Patent notice 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. The IEEE shall not be responsible for identifying all patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. The patent holder has, however, filed a statement of assurance that it will grant a license under these rights without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to all applicants desiring to obtain such a license. The IEEE makes no representation as to the reasonableness of rates and/or terms and conditions of the license agreement offered by the patent holder. Contact information may be obtained from the IEEE Standards Department.

Participants The following is a list of major participants in the IEEE P1394b working group (those that attended at least three working group meetings.) David R. Wooten, Chair Michael Johas Teener, Vice Chair Steve Bard, Secretary Eric Hannah, Editor Bill Anderson Tatsuya Arai Oleg Awsienko Richard Baker David Barnum Max Bassler Charles Brill Dave Brown Mike Brown Dave Brunker Jim Busse Don Chambers Dao-Long Chen Richard Churchill Dan Colegrove Alistair Coles Mike Coletta Eric Deliot Chris Dorsey Firooz Farhoomand Stephen Finch Mike Fogg Tony Foster John Fuller Nobuo Furuya Dave Gampell Bob Gannon Mike Gardner Jerry Hauck Keith Heilmann John Hill Daisuke Hiraoka Jack Hollins Derek Imschweiler


Tatsuo Inoue David Instone David James David Johnson Tom Jones Prashant Kanhere Marcus Kellerman Al Kelley Sean Killeen Akihito Kuwabara Dave LaFollette Farrukh Latif Thang Le Paul Levy Francesco Liburdi Robert Liu John Lopata Gerald Marazas Jun-ichi Matsuda Edward McDonnell Daniel Meirsman Jack Merrow Takatoshi Mizoguchi Reza Moattar Palanisamy Mohanraj Cyrus Momeni Karl Nakamura James Nave Jim Nelson Richard Nesin Bill Northey Takayuki Nyu Ozay Oktay Bijit Patel

James Piccione Bill Prouty Dennis Rehm Kyozo Saito Tomoki Saito Brad Saunders Dick Scheel D. C. Sessions Masood Shariff Robbie Shergill Jim Skidmore David Smith Michael Smith John Smolka Ron Soderstrom Martin Sodos John Ta Ju-Ching Tang Ken Taylor Peter Teng Victoria Teng Tom Thatcher David Thompson Toru Ueda Sushant Verman Hirosha Wakai Kenji Watanabe Yuji Watanabe Colin Whitby-Strevens Shuntaro Yamazaki Niwa Yoshikatsu Len Young Patrick Yu Peng Zhang

v

The following members of the balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. Eric Anderson Steven R. Bard Brian D. Batchelder David Brearley Keith Chow Robert S. Cram James R. Davis Dante Del Corso Chris S. Dorsey Sourav K. Dutta Roger D. Edwards Firooz Farhoomand Gordon Force John Fuller Eric Hannah Jerry Hauck Burke Henehan Clay E. Hudgins

Peter Johansson David K. Johnson Sean Killeen Thomas M. Kurihara Lawrence Lamers Steven Larky Gerald A. Marazas Joseph R. Marshall Gene E. Milligan Kiyoshi Miura Robert Mortonson Klaus-Dieter Mueller Atsushi Nakamura William A. Northey Farrell Ostler Dan Paley Gary S. Robinson Gordon Robinson

John Rynearson Bradley N. Saunders Thomas J. Schaal Larry Sheu James M. Skidmore Larry Stein Junichi Takeuchi Joseph Tardo Michael D. Teener David W. Thompson Clarence M. Weaver, Jr. Colin Whitby-Strevens David R. Wooten Don Wright Roy Yasoshima Tadahiro Yoshida Patrick W. Yu Oren Yuen

When the IEEE-SA Standards Board approved this standard on 20 March 2002, it had the following membership: James T. Carlo, Chair James H. Gurney, Vice Chair Judith Gorman, Secretary Sid Bennett H. Stephen Berger Clyde R. Camp Richard DeBlasio Harold E. Epstein Julian Forster* Howard M. Frazier Toshio Fukuda

Peter H. Lips Nader Mehravari Daleep C. Mohla Willaim J. Moylan Malcolm V. Thaden Geoffrey O. Thompson Howard L. Wolfman Don Wright

Arnold M. Greenspan James H. Gurney Raymond Hapeman Donald M. Heirman Richard H. Hulett Lowell G. Johnson Joseph L. Koepfinger*

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons: Alan Cookson, NIST Representative Satish K. Aggarwal, NRC Representative

Catherine Berger IEEE Standards Project Editor

vi


Contents 0. Overview .............................................................................................................................................1 0.1 Scope......................................................................................................................................1 0.2 Purpose...................................................................................................................................2 0.3 Document organization ..........................................................................................................2 1. Overview..............................................................................................................................................3 1.2 References ..............................................................................................................................3 1.5 Service model.........................................................................................................................4 1.6 Document notation .................................................................................................................5 2. Definitions and abbreviations.............................................................................................................13 2.1 Conformance ........................................................................................................................13 2.2 Technical .............................................................................................................................13 2.3 Acronyms and abbreviations.................................................................................................21 3. Summary description .........................................................................................................................23 3.10 New features of IEEE Std 1394b-2002...............................................................................23 4. Cable PHY specification ....................................................................................................................35 9. Short-haul copper PMD electrical specification.................................................................................77 9.1 Interfaces ..............................................................................................................................78 9.2 Transmitter electrical specifications .....................................................................................78 9.3 Receiver electrical specifications..........................................................................................81 9.4 Electrical measurements.......................................................................................................82 9.5 DC biasing............................................................................................................................83 9.6 Toning and signal detect .......................................................................................................83 9.7 Jitter......................................................................................................................................86 10. GOF PMD specification...................................................................................................................89 10.1 PMD block diagram ...........................................................................................................89 10.2 PMD to MDI optical specifications ....................................................................................90 10.3 Transmitter optical specifications .......................................................................................91 10.4 Receiver optical specifications ...........................................................................................91 10.5 Worst-case connection optical power budget and penalties (informative) ..........................92 10.6 Optical jitter specifications .................................................................................................92 10.7 Optical measurement requirements ....................................................................................94 10.8 CPR measurement ..............................................................................................................96 10.9 Optical connection cabling model ......................................................................................96 10.10 Optical connection............................................................................................................97 10.11 Fiber launch conditions: overfilled launch (OLF).............................................................98 11. PMD specification of fiber media with PN connector ......................................................................99 11.1 Scope ..................................................................................................................................99 11.2 PMD block diagram .........................................................................................................100


vii

11.3 Cables...............................................................................................................................100 11.4 Connector .........................................................................................................................101 11.5 Connector and cable assembly performance criteria ........................................................101 11.6 Optical fiber interface .......................................................................................................102 11.7 Optical jitter specifications ...............................................................................................103 11.8 Permitted number of segments (informative) ...................................................................104 12. Cat-5 UTP PMD specification .......................................................................................................107 12.1 Overview ..........................................................................................................................107 12.2 PMD block diagram .........................................................................................................108 12.3 Operation of CAT-5 connections ......................................................................................108 12.4 Media specification...........................................................................................................108 12.5 PMD electrical specifications ...........................................................................................110 12.6 PMD implementation (informative) .................................................................................114 13. Beta port specification....................................................................................................................115 13.1 Overview ..........................................................................................................................115 13.2 Port functions ...................................................................................................................116 13.3 Beta port operation ...........................................................................................................133 13.4 Beta port state machines...................................................................................................140 14. Connection management................................................................................................................145 14.1 Overview ..........................................................................................................................145 14.2 Port characteristics ...........................................................................................................146 14.3 Functions, variables, and constants ..................................................................................147 14.4 Port controller...................................................................................................................149 14.5 Port connection manager state machine............................................................................149 14.6 Standby.............................................................................................................................154 14.7 Loop prevention................................................................................................................155 14.8 Connection management ..................................................................................................161 15. PHY register map...........................................................................................................................165 15.1 PHY register map for the cable environment....................................................................165 15.2 Integrated link and PHY ...................................................................................................172 16. Data routing, arbitration, and control .............................................................................................173 16.1 Overview ..........................................................................................................................173 16.2 PHY services ....................................................................................................................174 16.3 PHY facilities ...................................................................................................................184 16.4 Cable PHY operation........................................................................................................196 17. B PHY- link interface (parallel) .....................................................................................................217 17.1 B PHY-link interface characteristics.................................................................................217 17.2 PHY-link interface signals ................................................................................................218 17.3 Interface initialization, reset, and disable .........................................................................220 17.4 Link-on and interrupt indications .....................................................................................224 17.5 Link requests and notifications .........................................................................................225 17.6 Interface data transfers .....................................................................................................231

viii


17.7 Format of received and transmitted data...........................................................................238 17.8 Status transfers and notifications from the PHY ...............................................................240 17.9 Delays affecting interoperability of PHYs and links ........................................................243 17.10 Legacy link support ........................................................................................................244 17.11 Electrical characteristics.................................................................................................245 18. PIL-FOP serial interface ................................................................................................................253 18.1 Operating model ...............................................................................................................253 18.2 PIL-FOP connection management....................................................................................254 18.3 Serial Bus configuration request types not carried over the PIL-FOP interface................256 18.4 P2P packet protocol..........................................................................................................256 19. C code ............................................................................................................................................259 19.1 Common declarations and functions.................................................................................259 19.2 Connection management routines.....................................................................................273 19.3 Port state machine actions ................................................................................................295 19.4 Border arbitration actions and conditions .........................................................................314 19.5 Border arbitration .............................................................................................................349 Annex K (informative) Serial Bus cable test procedures .....................................................................361 Annex O (normative) Jitter measurements ...........................................................................................365 Annex P (informative) Connection status change ................................................................................367 Annex Q (informative) Bibliography ...................................................................................................369


ix

IEEE Standard for a High-Performance Serial Bus—Amendment 2 EDITORIAL NOTE—IEEE Std 1394b™-2002 is based on the current edition of IEEE Std 1394™-1995 and the approved amendment IEEE Std 1394a™-2000. The editing instructions define how to merge the material contained here into this base document set to form the new comprehensive standard as created by the addition of IEEE Std 1394b-2002. Editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace. Change is used to make small corrections in existing text or tables. The editing instruction specifies the location of the change and describes what is being changed either by using strikethrough (to remove old material) or underscore (to add new material). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make large changes in existing text, subclauses, tables, or figures by removing existing material and replacing it with new material. Editorial notes will not be carried over into future editions because the changes will be incorporated into the base standard.

0. Overview 0.1 Scope IEEE Std 1394b-2002 is a full-use standard whose scope is to provide an amendment to IEEE Std 1394-1995 and a companion to IEEE Std 1394a-2000. This amendment defines features and mechanisms that provide gigabit speed extensions in a backwards compatible fashion and the ability to signal over single hop distances of up to 100 m. The following are included in IEEE Std 1394b-2002: a) b) c) d) e) f) g) h) i)

Cables and connectors for gigabit signaling and long distance (up to 100 m); Detection of physical loops in the bus topology and their subsequent resolution by selective disabling of physical layer (PHY) port(s); The same circuits may be used to transmit either data-strobe (DS) signals or 8B/10B-encoded signals; Extension of the PHY-link interface to higher data rates over an 8 bit parallel bus; Extension of the PHY-link interface to higher data rates over a bit-serial bus; Definition of high-speed bit protocols to handle various bus arbitration signals and the transport of slower data packets by bit-stuffed, high-speed packets; Protocols for signal speed matching at connect time; Port initialization protocols suitable for use over ac-coupled connections; and Various informative annexes to discuss testing and compliance procedures for gigabit connections.

The preceding are arranged in no particular order. Copyright © 2002 IEEE. All rights reserved.

1

IEEE Std 1394b-2002

IEEE STANDARD FOR A HIGH-PERFORMANCE

0.2 Purpose Technology advances have made gigabit signaling a feasible and attractive extension to the baseline standard, IEEE Std 1394-1995. In particular, the needs of data storage and home backbones dictate a higher speed and longer distance interconnect bus than can be provided by IEEE Std 1394-1995 and IEEE Std 1394a-2000.

0.3 Document organization IEEE Std 1394b-2002 contains this overview, a list of definitions, an informative summary description, clauses of technical specification, and application annexes. The new reader should read the informative summary and the clauses that precede it before the remainder of the document.

2


SERIAL BUS—AMENDMENT 2

IEEE Std 1394b-2002

1. Overview 1.2 References Insert the following references into 1.2 in IEEE Std 1394-1995, in alphabetical order, and renumber the footnotes: The standards named in this clause contain provisions that, through reference in this text, constitute provisions of IEEE Std 1394b-2002. At the time of publication, the editions indicated were valid. All standards are subject to revision; parties to agreements based on IEEE Std 1394b-2002 are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. AF-PHY-0015.000 (September, 1994), ATM Physical Medium Dependent Interface Specification for 155 Mb/s over Twisted Pair Cable.1 ANSI X3.230-1994 (Reaff 2001), American National Standard for Information Technology—Fibre Channel—Physical and Signaling Interface (FC-PH).2 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 Y14.2M-1992 (Reaff 1998), Line Conventions and Lettering. ANSI Y14.5M-1994 (Reaff 1999), Dimensioning and Tolerancing. ANSI/EIA 364-D-7-01, Electrical Connector Test Procedures Including Environmental Classifications.3 ANSI/EIA 364-06B-00, Contact Resistance Test Procedure for Electrical Connectors. ANSI/EIA 364-09C-99, Durability Test Procedure for Electrical Connectors and Contacts. 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-21C-00, Insulation Resistance Test Procedure for Electrical Connectors, Sockets and Coaxial Contacts. ANSI/EIA 364-23A-85, 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. ANSI/EIA 364-28D-99, Vibration Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-31B-00, Humidity Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-32C-00, Thermal Shock (Temperature Cycling) Test Procedure for Electrical Connectors and Sockets. ANSI/EIA 364-38B-99, Cable Pull-Out 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/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/TIA/EIA-455-54B-01, Mode Scrambler Requirements for Overfilled Launching Conditions to Multimode Fibers. 1ATM Forum publications are available from the ATM Forum, 2570 West El Camino Real, Suite 304, Mountain View, CA 94040-1313. They may also be down-

loaded from http://www.atmforum.com. 2ANSI publications are available from Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036-8002,

USA. 3EIA publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA

(http://global.ihs.com/). Copyright © 2002 IEEE. All rights reserved.

3

IEEE Std 1394b-2002


ANSI/TIA/EIA-455-95A-00, Absolute Optical Power Test for Optical Fibers and Cables. ANSI/TIA/EIA-455-127-91, Spectral Characterization of Multimode Laser Diodes. ANSI/TIA/EIA-526-14A-98, Optical Power Loss Measurement of Installed Multimode Fiber Cable Plant. ANSI/TIA/EIA-568-A-00, Commercial Building Telecommunications Cabling Standard. ANSI/TIA/EIA-604-93 (Reaff 2000), Fiber Optic Connector Intermateability Standards (FOCIS). ANSI/TIA/EIA TSB67-1995, Transmission Performance Specifications for Field Testing of Unshielded Twisted-Pair Cabling Systems. IEC 60603-7 (1996-11), 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.4 IEC 60793-1-1 (1999-02), Optical fibres—Part 1-1: Generic specification—General. IEC 60793-1-41 (2001-07), Optical fibres—Part 1-41: Measurement methods and test procedures—Bandwidth. IEC 60793-2 (2001-10), Optical fibres—Part 2: Product specifications. IEC 61000-4-2 (2001) Edition 1.2, Electromagnetic compatibility (EMC)—Part 4-2: Testing and measurement techniques— Electrostatic discharge immunity test. ISO/IEC 11801:2000, Information technology—Generic cabling for customer premises.5 IEEE Std 1394b-2002 shall also be used in conjunction with the following publications under development. When approved as a standard, the approved version shall apply. IEEE Std 1212™-2001, IEEE Standard for a Control and Status Registers (CSR) Architecture for Microcomputer Buses.6 NCITS TR-25-1999, Information Technology—Fibre Channel—Methodologies for Jitter Specification.7 Replace 1.5 in IEEE Std 1394-1995 with the following:

1.5 Service model IEEE Std 1394-1995 and this amendment both use a protocol model with multiple layers. Each layer provides services to the next higher layer and to Serial Bus management. 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 amendment. Four types of service are defined by IEEE this standard. They are as follows:

4IEC

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, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA. 5ISO/IEC publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse. ISO publications are also available in the United States from the American National Standards Institute. 6IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA (http://standards.ieee.org/). 7NCITS T11.2 working documents are available at http://www.t11.org.

4


IEEE Std 1394b-2002


a)

b)

c)

d)

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 Serial Bus, it is possible for the request to trigger a corresponding indication on multiple nodes.) 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. 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. 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 Replace 1.6 in IEEE Std 1394-1995 with the following:

1.6 Document notation 1.6.1 Mechanical notation All mechanical drawings in this standard use millimeters as the standard unit and follow ANSI Y14.2M-19928 and ANSI Y14.5M-1994 formats. 1.6.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.

8Information on normative references can be found in 1.2.


5

IEEE Std 1394b-2002


1.6.3 Size notation This document 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 command and status register (CSR) architecture] are used. These terms are illustrated in Table 1-1. 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

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

lsb

30

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 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.6.4 Numerical values Decimal, hexadecimal, and binary numbers are used within this document. 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. 6


IEEE Std 1394b-2002


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.6.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.6.3, the most significant bit of each field defined in IEEE Std 1394b-2002 is sent first. 1.6.6 Register formats All Serial Bus registers are documented in the style used by the CSR architecture. 1.6.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 +, -, * and / % >, >=, < and 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 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

8


IEEE Std 1394b-2002


1.6.8 State machine notation All state machines in IEEE Std 1394b-2002 use the style shown in Figure 1-5.

state label

S0: State Zero

S1: State One

actions started on entry to S0

actions started on entry to S1

condition for transition from S1 to S0

condition for transition from S0 back to itself 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


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, so the only actions taken during a transition are setting flags and variables and sending signals. These actions complete before the next state is entered; and 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.6.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 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

Register name

Description

0

STATE_CLEAR

First CSR location

4-12

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. Copyright © 2002 IEEE. All rights reserved.

9

IEEE Std 1394b-2002


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.

1.6.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

sig

16

resv why

not

1

1

1

1

1

0

0

0

w

0

u

u

s

i

i

e

initial value unit_dependent

zeros

read value last write

last update

write effect stored

ignored Figure 1-6—Example of CSR format specification

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) 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.

10


IEEE Std 1394b-2002


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.6.11 Reserved registers and fields Reserved fields within a CSR conform to the requirements of the conformance glossary in this standard (see 2.1). Within a CSR, such a field is labeled reserved (sometimes abbreviated as lowercase r or resv). 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


11

IEEE Std 1394b-2002


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 IEEE Std 1394a-2000 for details. 1.6.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 state machine notes).

12



IEEE Std 1394b-2002

2. Definitions and abbreviations Replace 2.1 in IEEE Std 1394-1995 with the following:

2.1 Conformance Several keywords are used to differentiate between different levels of requirements and optionality, as follows: 2.1.1 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. 2.1.2 ignored: A keyword that describes bits, bytes, quadlets, octlets, or fields whose values are not checked by the recipient. 2.1.3 may: A keyword that indicates flexibility of choice with no implied preference. 2.1.4 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. 2.1.5 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. 2.1.6 should: A keyword indicating flexibility of choice with a strongly preferred alternative. Equivalent to the phrase “is recommended.” Change the head for 2.2 in IEEE Std 1394-1995 as follows:

2.2 Technical glossary Replace the following in 2.2 in IEEE Std 1394-1995, in alphabetical order. Replace the “x” in 2.2.x with the appropriate numbers: 2.2.x 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. 2.2.x 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. 2.2.x arbitration reset gap: The period of time on a Legacy bus that indicates the start of a new asynchronous arbitration fairness interval. An arbitration reset gap is longer than a subaction gap. 2.2.x asynchronous packet: A primary packet transmitted in accordance with asynchronous arbitration rules (outside of the isochronous period). 2.2.x base rate: A data rate of 98.304 Mbit/s ± 100 ppm. In a cable environment, all Legacy-capable nodes are capable of communicating at this rate, and all B-capable nodes are capable of communicating at 4 * base rate. 2.2.x concatenated transaction: A split transaction comprising concatenated subactions. 2.2.x cycle master: The node that generates the periodic cycle start packet 8000 times a second.


13

IEEE Std 1394b-2002


2.2.x cycle start or cycle start packet: A primary packet sent by the cycle master that indicates the start of an isochronous interval. 2.2.x data bit: The smallest signaling element used by the physical layer (PHY) for transmission of packet data on the medium. 2.2.x 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. 2.2.x initial register space: A 2048 byte portion of initial node space with a base address of FFFF F00016. This address space is reserved for resources accessible immediately after a bus reset. Core registers defined by ISO/IEC 13213:1994 for CSR architecture are located within initial register space as are Serial Bus-dependent registers defined by IEEE Std 1394-1995. 2.2.x isochronous: Uniform in time (i.e., having equal duration) and recurring at regular intervals. 2.2.x isochronous resource manager: 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 isochronous resource manager is selected from all nodes capable of this function. 2.2.x isochronous subaction: Within the isochronous interval, either a concatenated packet or a packet and the gap that preceded it. 2.2.x link layer or link: The Serial Bus protocol layer that provides confirmed and unconfirmed transmission or reception of primary packets. 2.2.x node: A Serial Bus device that may be addressed independently of other nodes. A minimal node consists of only a PHY without an enabled link. If the link and other layers are present and enabled they are considered part of the node. 2.2.x packet: A sequence of zero or more bits transmitted on Serial Bus and delimited by a packet start symbol and a packet end symbol. 2.2.x physical layer (PHY): The Serial Bus protocol 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. 2.2.x 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). 2.2.x port: The part of the physical layer (PHY) that allows connection to one other node. 2.2.x response: A primary packet (with optional data) sent in response to a request subaction. 2.2.x 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. 2.2.x unit architecture: The document that specifies the interface to, and the behaviors of, a unit implemented within a node. Insert the following in 2.2 in IEEE Std 1394-1995, in alphabetical order. Replace the “x” in 2.2.x with the appropriate numbers: 2.2.x 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. 14



IEEE Std 1394b-2002

2.2.x 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. 2.2.x 8B/10B: A line code that maps 8 bit symbols to 10 bit symbols to achieve dc balance and bounded disparity. 2.2.x 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. 2.2.x 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. 2.2.x 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 a Legacy cloud, the reset is signaled by arbitration reset gap. In a B cloud, the reset is signaled by an arbitration reset token. 2.2.x arbitration reset indication: An arbitration reset gap in a Legacy cloud or an arbitration reset token in a B cloud. 2.2.x 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. 2.2.x arbitration signaling: In a Legacy cloud, a protocol for the exchange of bidirectional, unclocked signals between nodes during arbitration. In a B cloud, the exchange of arbitration tokens. 2.2.x B bus: An operating bus in which all nodes are operating as B physical layers (PHYs). 2.2.x B cloud: A collection of B nodes and/or border nodes in which all internode connections are made through Beta ports. 2.2.x Beta mode: The mode in which a port is operating according to the specifications given in Clause 13, Clause 14, and Clause 16 and, in particular, is using the 8B/10B symbol coding and obeying the bus owner/supervisor/selector (BOSS) arbitration protocols. The speed of a port sending in Beta mode is denoted by the β suffix (e.g., S400β). 2.2.x Beta-only port: A port that is capable of operating only as a Beta port. 2.2.x Beta port: A port that is operating in Beta mode. 2.2.x 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. 2.2.x B link: A link that is capable of operating according to the specifications given in Clause 17 or Clause 18, and, in particular, issues requests appropriate to bus owner/supervisor/selector (BOSS) arbitration. 2.2.x B node. A node whose physical layer (PHY) is operating as a B PHY. 2.2.x 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). 2.2.x border node: A node with both (i) either its link operating as a B link or at least one Beta port or both, and (ii) either its link operating as a Legacy link or at least one data-strobe (DS) port or both. 2.2.x 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.


15

IEEE Std 1394b-2002


2.2.x 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 Legacy PHY-link mode. 2.2.x bus identifier (ID): A 10 bit number uniquely specifying a particular bus within a system of multiple interconnected buses. 2.2.x 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. 2.2.x bus owner/supervisor/selector (BOSS) arbitration: The arbitration scheme defined by IEEE Std 1394b-2002. 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. 2.2.x character: A 10 bit sequence of data sent on a connection that is operating in B mode. 2.2.x comma character or comma sequence: A bit sequence that defines boundaries for byte synchronization. 2.2.x 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. 2.2.x connection: Two ports that can communicate with each other and the media between those two ports. 2.2.x connection attenuation: The static loss of a connection between a transmitter and receiver. It includes the loss of the fiber, connectors, and splices. 2.2.x connection penalties: The power penalties of a connection not attributed to connection attenuation. It includes modal noise, relative intensity noise (RIN), inter-symbol interface (ISI), mode partition noise, extinction ratio, and eye opening penalties. 2.2.x 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 mode capable ports. 2.2.x 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. 2.2.x data character: A character used by the 8B/10B code. 2.2.x data-strobe (DS): A signaling method using two signals in which one signal (data) always indicates the binary value of the data (0 or 1) and the other signal (strobe) changes if the data stays the same during successive bit cells. This signaling method is used in IEEE Std 1394-1995 and IEEE Std 1394a-2000. 2.2.x data-strobe (DS) mode: The form of electrical signaling and handshaking that is compatible with IEEE Std 13941995 and IEEE Std 1394a-2000. 2.2.x data-strobe- (DS-) only port: A port capable of operating only as a DS port. 2.2.x data-strobe (DS) port: A port that is operating according to Legacy 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. 2.2.x dc balance: The requirement that over long runs of binary symbols no net disparity shall exist. 16



IEEE Std 1394b-2002

2.2.x 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-ID packet(s). 2.2.x disconnected port: A port whose connection detect circuitry detects no peer physical layer (PHY) at the other end of a cable. 2.2.x disparity: The number of ones in a transmission character minus the number of zeros in a character. 2.2.x dispersion slope: The rate of change of the chromatic dispersion of a fiber with wavelength. 2.2.x 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. 2.2.x 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. 2.2.x fan-out PHY (FOP): A multiported physical layer (PHY) that is attached to a PHY that is integrated into the link (PIL) using the serial interface defined in Clause 18. 2.2.x fiber attenuation: The static loss per unit length of the fiber at a particular wavelength, usually expressed in decibels per kilometer. 2.2.x galvanic isolation: A mechanism to avoid low-frequency ground loop currents. 2.2.x hybrid bus: An operating bus that contains at least one border node. 2.2.x initial node space: The 256 terabytes of Serial Bus address space that is 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. See either ISO/IEC 13213:1994 or IEEE Std 1394-1995 for more information on address spaces. 2.2.x 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. 2.2.x 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. NOTE—This term appeared in IEEE Std 1394a-2000 as “isochronous period.”

2.2.x isolated node: A node without active ports; the node’s ports may be disabled, disconnected, or suspended in any combination. 2.2.x jitter: Any variation in the zero-crossing time from the ideal bit pattern. 2.2.x junior border: Any border node in a B cloud except the senior border. 2.2.x K-code: An 8B/10B symbol that represents control information. 2.2.x Legacy: Characteristics or behavior of a link, node, physical layer (PHY), cable, or connector defined by IEEE Std 1394-1995 and IEEE Std 1394a-2000. 2.2.x Legacy cloud: A collection of Legacy nodes and/or border nodes in which all internode connections are made through Legacy ports. 2.2.x Legacy request: A request type defined by this specification that is originated by a border node on behalf of a Legacy link or a data-strobe (DS) port. Copyright © 2002 IEEE. All rights reserved.

17

IEEE Std 1394b-2002


2.2.x link: Link layer. Also, the physical entity that implements the link layer. Also, one of the components connected to the PHY-link interface. 2.2.x 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. 2.2.x 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. 2.2.x modal bandwidth: The bandwidth of a multimode fiber (MMF) due to dispersion caused by variations in speed of the propagating modes. 2.2.x 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. 2.2.x 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 TPB pair can cause NEXT on the TPA pair of a port. 2.2.x 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. 2.2.x 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. 2.2.x null packet: A packet in which no data are transmitted. 2.2.x 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). 2.2.x 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). 2.2.x 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. 2.2.x overfilled launch (OFL): The condition that excites both radial and azimuthal modes defined in TIA/EIA 455-54B. 2.2.x packet delimiter: Sequence of control symbols that delineate the beginning and ending of a data packet. 2.2.x 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). 2.2.x padding: Symbols inserted between data symbols in a packet to allow slower speed data to be transmitted on a higher speed connection. 2.2.x physical identifier (ID): The 6 least significant bits (lsbs) of the node ID. On a particular bus, each node’s physical ID is unique. 2.2.x physical layer (PHY) integrated link (PIL): A link that uses a modified Beta port to attach to a fan-out PHY (FOP) using the protocols defined in Clause 18.

18



IEEE Std 1394b-2002

2.2.x physical media dependent (PMD) interface: The part of an interface that is specific to single kind of interconnect. 2.2.x ping: A term used to describe the transmission of a physical layer (PHY) packet to a particular node in order to time the response packet(s) provoked. 2.2.x point-to-point (P2P) packet: Special packet type that is sent on the PIL-FOP interface. This packet is used to carry data that cannot be sent as part of a normal Serial Bus packets. 2.2.x port state machine: The logic that controls the functioning of a port. 2.2.x 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 a Legacy node, then no proxy_root exists. 2.2.x radial overfilled launch (OFL): A launch condition created when a multimode optical 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. 2.2.x random jitter: Jitter that comes from random sources. Characterized by Gaussian statistics and unbounded variation according to the Gaussian distribution function. 2.2.x 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). 2.2.x register: A term used to describe addresses that may be read or written by Serial Bus transactions. In the context of IEEE Std 1394b-2002, 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. 2.2.x relative intensity noise (RIN): The ratio of the variance in the optical power to the average optical power. 2.2.x repeating port: A transmitting port on a physical layer (PHY) that is repeating a packet from the PHY’s receiving port. 2.2.x request type: An 8B/10B data character that connotes either an arbitration or configuration request. 2.2.x restore: The process of causing a connection in standby to return to the active state. 2.2.x resume signal: A signal requiring the port to resume normal operations. 2.2.x 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. 2.2.x rms spectral width: The optical wavelength range as measured by ANSI/TIA/EIA-455-127-91. 2.2.x run length: The length of a sequence of bits that have the same value, e.g., ones or zeros. 2.2.x running digital sum: The number of ones in a character stream minus the number of zeros in a character stream. 2.2.x 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.


19

IEEE Std 1394b-2002


2.2.x 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. Used to average out the spectral content of the transmitted signal to avoid strong spectral lines. 2.2.x senior border: A unique border node in a B cloud. The senior border is the last node to originate a self-ID packet without a speed code into the cloud (i.e., repeated from a data-strobe (DS) port or generated because of a Legacy link) and is responsible for ensuring that certain Legacy gap timings are observed. 2.2.x 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. 2.2.x 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. 2.2.x subaction gap: In a Legacy cloud, the period of idle bus that precedes arbitration for an asynchronous subaction. 2.2.x subaction indication: A subaction gap or, in a B cloud, an ASYNC_EVEN/ODD control token of the current phase. 2.2.x 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. 2.2.x suspended node: An isolated node with at least one port that is suspended. 2.2.x 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. 2.2.x suspend initiator: An active port that transmits the SUSPEND configuration request or the TX_SUSPEND signal and engages in a protocol with its connected peer physical layer (PHY) to place the connection in the Suspended state. 2.2.x 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. 2.2.x synchronization: The process of aligning the receiver's circuits to properly detect received bits and to properly detect symbol boundaries. 2.2.x transaction layer: The Serial Bus protocol layer that defines a request-response protocol for read, write, and lock operations. 2.2.x transmitting port: Any port transmitting clocked data or an arbitration state. A transmitting port is further characterized as either originating or repeating. 2.2.x uncle node: A node that proxies for a peer nephew node while the connection between the two is in Standby state. 2.2.x 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. 2.2.x unit interval: The nominal amount of time 1 bit takes to transmit. 2.2.x zero dispersion wavelength: The wavelength where the chromatic dispersion of a fiber is at its minimum.

20



IEEE Std 1394b-2002

Add the following new subclause at the end of Clause 2 in IEEE Std 1394-1995:

2.3 Acronyms and abbreviations A bit ACK AWG BER CAT-5 CPR CRC DMD FIFO FOP FWHM G bit GOF HPCF HR LED LPS LTD LTP LTS M bit MMF NA N bit NEXT NRZ OFL PCB PIL pk-pk PLL PMD POF POR R bit RIN SMF STP T bit TDR UTP VCSEL

asynchronous phase bit acknowledge or acknowledgment American Wire Gauge bit error ratio Category 5 coupled power ratio

cyclic redundancy code differential-mode delay first in, first out buffer fan-out PHY full width at half maximum generation number bit glass optical fiber hard polymer clad fiber holding register light-emitting diode link power status loop test data loop test packet loop test symbol mode bit multimode fiber numerical aperture reset notify bit near end crosstalk nonreturn to zero overfilled launch printed circuit board PHY that is integrated into a link peak-to-peak phase locked loop physical media dependent plastic optical fiber power-on reset root bit relative intensity noise single-mode fiber shielded twisted pair gap count reset disable bit time domain reflectometry unshielded twisted pair vertical cavity surface emitting laser


21


IEEE Std 1394b-2002

3. Summary description Insert the following after 3.9, which was added to IEEE Std 1394-1995 by IEEE Std 1394a-2000:

3.10 New features of IEEE Std 1394b-2002 IEEE Std 1394b-2002 is an amendment to IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000. IEEE Std 1394b2002 defines mechanisms that increase the data rate and the transmission distance for IEEE 1394 buses. 3.10.1 The relationship to IEEE Std 1394a-2000 IEEE Std 1394a-2000 improves many areas of IEEE Std 1394-1995. Of particular note is the improvement in bus efficiency. IEEE Std 1394a-2000 provides arbitration acceleration, improves the speed of bus resets, and adds suspend and resume power management capabilities to the bus. IEEE Std 1394b-2002 is 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 supports 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 supports new media, such as Category 5 (CAT5) unshielded twisted pairs (UTPs), glass optical fiber (GOF), and plastic optical fiber (POF). 3.10.2 Faster and further IEEE Std 1394b-2002 supports the regular DS signaling modes and speeds of IEEE Std 1394-1995. Additionally, IEEE Std 1394b-2002 extends bus speeds to S800 and S1600 and has 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 recommends 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 supports optical cable lengths of 50 m for POF and 100 m for GOF. Additionally, IEEE Std 1394b-2002 supports 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.


23

IEEE Std 1394b-2002


3.10.3 Nomenclature Figure 3-33 illustrates the PHY architectural framework and architectural elements possible within a Beta-capable PHY. This figure is referenced by many other subclauses in IEEE Std 1394b-2002; 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

request/grant, enable

connection monitor

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

Low-power signaling

TX/RX data signals, PMD control/status, arb/connect control/status (DS only)

PMD

DS-mode functions

CAT-5 UTP -orGOF -orPOF -orBeta-only electrical -orBilingual electrical -orDS-only electrical


PMD


Figure 3-33 — Master architecture

3.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 nonreturn to zero (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 24



IEEE Std 1394b-2002

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 bit error ratio (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 physical media dependent (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. 3.10.4.1 Short-haul shielded twisted pair (STP) cabling IEEE Std 1394b-2002 defines 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 Std 1394a-2000 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. 3.10.4.2 CAT-5 UTP cable (see Chapter 7 of ISO/IEC 11801:2000) 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 uses 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 supports autocrossover for UTP. The electrical specifications are as other standards using CAT-5, e.g., 1 V peak-to-peak (pk-pk) binary signaling. By requiring adaptive equalization in the receiver, IEEE Std 1394b-2002 achieves a maximum CAT-5 operating length of 100 m at S100. Higher speeds are not defined by IEEE Std 1394b-2002. 3.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. Hard polymer clad fiber (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. POF and HPCF are low cost and easy to install. Fiber alleviates emissions and interference problems. A simple PN style connector is specified. 3.10.4.4 Glass fiber The GOF specification leverages VCSEL technology. IEEE Std 1394b-2002 follows 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.


25

IEEE Std 1394b-2002


The GOF connector is the LC connector as defined in the FOCIS 10 addendum of the TIA/EIA-604-93. 3.10.4.5 Media summary for Beta-mode operation Table 3-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 3-1—Beta-mode media summary Media CAT-5 UTP POF

Reach (m)

S100

100

X

S200

50

X

X

HPCF

100

X

X

MMF

100

STP

4.5

S400

S800

S1600

X

X

X

X

X

X

3.10.5 Arbitration improvements IEEE Std 1394b-2002 makes 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 1394-1995. 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 are addressed somewhat by the enhanced arbitration mechanisms in IEEE Std 1394a-2000, which also scale well into the speed range defined by IEEE Std 1394b2002. IEEE Std 1394b-2002 further reduces 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. 3.10.5.1 Legacy arbitration In Legacy IEEE 1394, 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).

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 defines several arbitration enhancements and acceleration mechanisms: a)

26

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. Copyright © 2002 IEEE. All rights reserved.


b) c) d)

e)

IEEE Std 1394b-2002

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. 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. 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. 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. 3.10.5.2 New arbitration method—bus owner/supervisor/selector (BOSS) IEEE Std 1394b-2002 retains the arbitration enhancements and accelerations of IEEE Std 1394a-2000, but further improves bus efficiency by taking advantage of the full-duplex nature of Beta-mode signaling to implement a new arbitration method referred to as bus owner/supervisor/selector (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 specification (i.e., a B bus) or in a bus with any mixture and configuration of nodes compliant to IEEE Std 1394b-2002 and 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 3.10.5.2.4). Figure 3-34 illustrates the general concept of BOSS operation and shows how arbitration signaling is overlapped with data transmission on the full-duplex bus.


27

IEEE Std 1394b-2002


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

request

packet data

packet data

p node # 0 BOSS

p node # 3 ch

ch

packet data request

request packet data

p node # 1

p node # 2

Figure 3-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. 3.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). 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.

28



IEEE Std 1394b-2002

3.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. 3.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 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).


29

IEEE Std 1394b-2002

b)

c)


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. 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. 3.10.5.2.4 Hybrid bus operation The discussion of BOSS arbitration in 3.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 self-ID 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) b) c) d)

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), At arb_delay following the issuance of an ASYNC_EVEN/ODD token indicating a subaction gap, Anytime after the arb_delay following the issuance of an ASYNC_EVEN/ODD token indicating a new fairness interval, or 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

30



IEEE Std 1394b-2002

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. 3.10.5.2.5 Legacy request phasing In Legacy IEEE 1394, a 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. In Legacy IEEE 1394, the various packet timing constants (e.g., MIN_DATA_PREFIX, ARB_RESPONSE_DELAY) were defined so that this 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 Legacy IEEE 1394. 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 allows 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 Beta-mode 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 Copyright © 2002 IEEE. All rights reserved.

31

IEEE Std 1394b-2002


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. 3.10.6 PHY-link interface This specification 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. 3.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. 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. 3.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 specification. 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. 32



IEEE Std 1394b-2002

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-ID or self-ID 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. 3.10.7 Miscellaneous features 3.10.7.1 Autonegotiation IEEE Std 1394b-2002 has 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 1394b-2002 solves 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 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. 3.10.7.2 Loop breaking A new feature is loop breaking. Loops are automatically removed during initialization. 3.10.7.3 Power conservation improvements IEEE Std 1394b-2002 adds 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. 3.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 state, 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 state cannot become a nephew.


33

IEEE Std 1394b-2002


3.10.7.3.2 Restore The port in Standby state on the nephew restores from Standby state upon detecting a restore tone from its uncle. A nephew restores its port from Standby state 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 state restores that port followed by a bus reset if, on any of its other ports, it detects a resume or a new connection.

34



IEEE Std 1394b-2002

4. Cable PHY specification Insert the following after 4.2.1A, which was inserted into IEEE Std 1394-1995 by IEEE Std 1394a-2000: 4.2.1B Copper PMD cable media attachment This specification defines a new media and connector to support the higher data rates defined in IEEE Std 1394b-2002. This media and connector are known as the Beta interface. This interface is usable at speeds up to the maximum defined by IEEE Std 1394b-2002, S1600. To enable interoperability with Legacy 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 Legacy ports from being attached to Beta-only ports. An interconnect matrix is provided in Table 4-11J and Table 411K of this subclause. 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 IEEE Std 1394-1995 and IEEE Std 1394a-2000 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 (< 5 m) copper connections on a Beta-capable port. 4.2.1B.1 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.2.1B.3. Information about the recommended planar mounting footprints of the sockets is found in Figure 4-11AE and Figure 411AF. Compliance to these footprints is optional, but performance of alternative footprints should be comparable to the footprints shown in this specification. 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. IEEE Std 1394b-2002 defines the copper Beta and bilingual cables and their mating printed circuit board (PCB) socket interfaces. 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.2.1B.3. The mating features of the Beta plug and overmold features are specified in Figure 4-11N. The bilingual plug and overmold features are shown in Figure 4-11O. The interface, unmated plug cross-section, and detent common to both the Beta and bilingual plugs are found in Figure 4-11P, Figure 4-11Q, and Figure 4-11R. Adherence to these details helps ensure mating integrity by multiple manufacturers of these cable plugs.


35

IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Theoretical sharp corner, chamfer profile tolerance excludes radii.

Figure 4-11N—Beta plug body with overmold

36


IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4]


Figure 4-11O—Bilingual plug body with overmold


37

IEEE Std 1394b-2002


NOTES: [1] [2] [3]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994.

Figure 4-11P—Beta and bilingual plug interface: Detail A

NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Contact shape is manufacturer’s option.

Figure 4-11Q—Beta and bilingual plug section Z-Z (unmated) 38


IEEE Std 1394b-2002


Figure 4-11R—Beta and bilingual detent cross-section S-S 4.2.1B.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.2.1B.1.2 Socket The mating features of the Beta socket are described in Figure 4-11S and Figure 4-11T. The detail assures the intermateability of the socket with the plugs specified by IEEE Std 1394b-2002. The mating features of the bilingual socket are described in Figure 4-11U and Figure 4-11V. In Figure 4-11W through Figure 4-11AB, the interface details common to both Beta and bilingual sockets are shown. Figure 4-11AC shows mated detent cross-sections common to both Beta and bilingual plugs and sockets. The detent feature details assure the intermateability of the socket with the plugs specified by IEEE Std 1394b-2002. Materials utilized in the fabrication of the Beta and bilingual sockets shall be capable of withstanding IR reflow temperatures. Contact assignment for either PCB socket is found in Table 4-11I. Table 4-11I—Socket contact assignment Contact number

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)


39

IEEE Std 1394b-2002


Table 4-11I—Socket contact assignment (continued) Contact number

Signal name

Comment

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 Outer Shield

Socket Inner Shell

11

Cable Outer Shield

Socket Inner Shell

12

Chassis Ground

Socket Outer Shell

13

Chassis Ground

Socket Outer Shell

NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Solderable standoff feature is an option of the manufacturer.

Figure 4-11S—Beta socket body

40


IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4] [5]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Theoretical sharp corner, chamfer profile tolerance excludes radii. 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-11T—Beta socket outer shell profile

NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Solderable standoff feature is an option of the manufacturer.

Figure 4-11U—Bilingual socket body Copyright © 2002 IEEE. All rights reserved.

41

IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4] [5]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Theoretical sharp corner, chamfer profile tolerance excludes radii. 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-11V—Bilingual socket outer shell profile

NOTES: [1] [2] [3] [4]


Figure 4-11W—Beta and bilingual socket section X-X 42


IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Contact shape is the manufacturer’s option, but should be a spring member.

Figure 4-11X—Beta and bilingual socket section Y-Y

NOTES: [1] [2] [3]


Figure 4-11Y—Beta and bilingual socket section V-V Copyright © 2002 IEEE. All rights reserved.

43

IEEE Std 1394b-2002


NOTES: [1] [2] [3]


Figure 4-11Z—Beta and bilingual socket section Z-Z

NOTES: [1] [2] [3]


Figure 4-11AA—Beta and bilingual socket section W-W

44


IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Contact shape is manufacturer’s option, but shall be a spring member.

Figure 4-11AB—Beta and bilingual socket interface


45

IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4] [5]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Socket detent features shall retain standard plug shape and contacts in reliable contact position under cable tension up to the minimum retention force. Detent shape is the manufacturer’s option, but should be a spring member.

Figure 4-11AC—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-11AD.

NOTES: [1] [2] [3] [4] [5]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Minimum mounting interval. Datum -C- of PCB sockets.

Figure 4-11AD—Socket positions when mounted on a PCB 46



IEEE Std 1394b-2002

4.2.1B.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) b)

0.76 µm, minimum, gold, over 1.27 µm, minimum, nickel, or 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.2.1B.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.2.1B.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.2.1B.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, IEEE Std 1394b-2002 specifies minimum performance criteria of 1000 mating cycles. 4.2.1B.1.7 Socket PCB termination footprints and PHY trace routing The dimensional specifications recommended for the footprint of a surface-mount Beta PCB socket are illustrated in Figure 4-11AE.


47

IEEE Std 1394b-2002


NOTES: [1] [2] [3] [4]

[5] [6] [7]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Datum J - PCB top surface. Datum K - orientation hole closest to pad matrix. Datum L - remaining orientation hole. Minimum mounting interval is 14.5 mm. Phantom outline of Beta socket. Thru holes are optional for true flat surface-mounted (SMT) sockets.

Figure 4-11AE—Beta PCB socket footprint

48


IEEE Std 1394b-2002


The dimensional specifications recommended for the footprint of a surface-mount bilingual PCB socket are illustrated in Figure 4-11AF.

NOTES: [1] [2] [3] [4]

[5] [6] [7]

All linear dimensions are in millimeters. Unless otherwise specified, tolerances are linear ± 0.15 and angular ± 5°. Interpret dimensions and tolerances per ANSI Y14.5M-1994. Datum J - PCB top surface. Datum K - orientation hole closest to pad matrix. Datum L - remaining orientation hole. Minimum mounting interval is 14.5 mm. Phantom outline of bilingual socket. Thru holes are optional for true flat SMT sockets.

Figure 4-11AF—Bilingual PCB socket footprint


49

IEEE Std 1394b-2002


Figure 4-11AG illustrates the layout of PCB traces from a Beta or bilingual socket. This information is useful for both PHY IC and PCB layout designers.

VP Socket outer shield

Socket inner shield

TPB(R) TPB*

TPB

VG TPA(R)

SC

TPA*

TPA

Socket inner shield

Socket outer shield

PCB edge

Figure 4-11AG—PHY trace routing 4.2.1B.1.8 Plug overmold A simple half-round radius shall be included for the overmold on the pin 4/5 side of the plug as shown in Figure 4-11N and Figure 4-11O. 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.2.1B.1.9 Socket orientation preference The 4/5 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 horizontal plane, while the 4/5 side of the socket should be down if the socket has the long axis in the vertical orientation. 4.2.1B.2 Cables All cables and cable assemblies shall meet assembly criteria and test performance found in this subclause.

50


IEEE Std 1394b-2002


4.2.1B.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-11AH and Figure 4-11AI 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) b) c)

The designation 1394b Number of signal pairs/American Wire Gauge (AWG) Number of power conductors/AWG

For example, the 4.5 m reference construction illustrated in Figure 4-11AH would have the cable jacket printing of “1394b 2PR/25AWG 2C/22AWG,” and the 2.0 m reference construction illustrated in Figure 4-11AI would have the cable jacket printing of “1394b 2PR/30AWG 2C/26AWG.”

Tape: metal outside (toward braid)

Signal pair #1: red & green

Power wire #1: white Power wire #2: black

Tape: insulating Tape: metal inside toward drains

Dual drains Signal pair #2: blue & orange

Power wires: 22 AWG stranded / Ø 1.08 insulation Signal pair shield: metal tape over 2 uninsulated drains, metal inside (2 pairs) Signal twisted pair wires: 25 AWG stranded / Ø 1.22 insulation, twist 60 / meter

Ø 6.9 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.50 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-11AH—Example of cable construction—4.5 m maximum (for reference only)


51

IEEE Std 1394b-2002


Tape: metal outside (toward braid)

Signal pair #1: red & green

Power wire #1: white Power wire #2: black

Tape: insulating Tape: metal inside toward drains

Dual drains Signal pair #2: blue & orange

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-11AI—Example of cable construction—2 m maximum (for reference only)

4.2.1B.2.2 Reference cable material for bilingual-to-Legacy cable assemblies Legacy cables are specified in IEEE Std 1394-1995 and IEEE Std 1394a-2000. 4.2.1B.2.3 Cable assemblies The only allowable cable assemblies for connecting to Beta and bilingual ports shall consist of three types and have a maximum length of 4.5 m (see Table 4-11J). The type 2 and type 3 cables are the only permissible methods to connect from the bilingual plug to Legacy plugs. Table 4-11J—Cable assembly components Cable type

52

Plug 1

Plug 2

Cable reference

1

Beta

Beta

IEEE Std 1394b-2002

2

IEEE Std 1394a-2000 4-circuit

Bilingual

IEEE Std 1394a-2000

3

IEEE Std 1394-1995 6-circuit

Bilingual

IEEE Std 1394-1995


IEEE Std 1394b-2002


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-11AJ—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-11K shows the various interfaces. Table 4-11K—Interface speed matrix Socket or plug

S100-S400 IEEE Std 1394-1995 IEEE Std 1394a-2000

IEEE Std 1394-1995 6-circuit

X

IEEE Std 1394a-2000 4-circuit

X

S400β

S800β

S1600β

Bilingual

X

X

X

Beta

X

X

X

All three types of cable assembly constructions are shown in Figure 4-11AK through Figure 4-11AM along with cable assembly wiring charts in Table 4-11L through Table 4-11N.


53

IEEE Std 1394b-2002


plug 2

2 1

6

7

7

4 3

6

8 9

2 1

5

5

4 3

8 9

plug 1

NOTE—Cable as defined in IEEE Std 1394b-2002. Connectors are viewed as looking at the front plug face.

Figure 4-11AK—Type 1 cable assembly and schematic (Beta plug to Beta plug) Table 4-11L—Type 1 cable assembly Plug 1: Beta plug contact number

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

SC (Status

Contact)a

7 (no connection)

8

VP (Power Voltage)

8

9

TPB (R) (Twisted Pair B Ground Reference)

5

plug shield

54

Plug 2: Beta plug contact number

1

7 (no connection)

aReserved

Signal name at plug 1 end: Cable as defined in IEEE Std 1394b-2002

Cable Outer Shield

plug shield

for future use; no plug-to-plug connection exists for status contact through the cable.


IEEE Std 1394b-2002


plug 2

3

5

2

4

6

7

1

5 6

4 3

plug 1

8 9

2 1

NOTE—Cable (reference) as defined in IEEE Std 1394-1995. Connectors are viewed as looking at the front plug face.

Figure 4-11AL—Type 2 cable assembly and schematic (IEEE Std 1394-1995 6-circuit plug to bilingual plug) Table 4-11M—Type 2 cable assembly Plug 1: IEEE Std 1394-1995 6-circuit plug contact number

Plug 2: Bilingual plug contact number

5


1

6


2

3


3

4


4

2


5

2

VG (Power Ground)

6

no connection

SC (Status

Contact)a

7 (no connection)

1

VP (Power Voltage)

8

2


9

plug shield aReserved

Signal name at plug 2 end: IEEE Std 1394-1995 cable reference

Cable Outer Shield

plug shield



55

IEEE Std 1394b-2002


plug 2

5 6

4 3 7

8 9

2 1

plug 1

4 3 2 1 NOTE—Cable (reference) as defined in IEEE Std 1394a-2000. Connectors are viewed as looking at the front plug face.

Figure 4-11AM—Type 3 cable assembly and schematic (IEEE Std 1394a-2000 4-circuit plug to bilingual plug) Table 4-11N—Type 3 cable assembly Plug 1: IEEE Std 1394a-2000 4-circuit plug contact number

Plug 2: Bilingual plug contact number

3


1

4


2

1


3

2


4


5

no connection

VG (Power Ground)

6

no connection

SC (Status Contact)a

no connection

VP (Power Voltage)

plug shield

plug shield no connection aReserved

Signal name at plug 2 end: IEEE Std 1394a-2000 cable reference

7 (no connection) 8


9

Cable Outer Shield

plug Shield


4.2.1B.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 IEEE Std 1394b-2002, 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, and humidity, 95% maximum. Class 1.3 is further described as operating in a “harsh environmental” state, but with no marine atmosphere.

56


IEEE Std 1394b-2002


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 specification 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.2.1B.3.1 through 4.2.1B.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 specification. 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.2.1B.3.1 through 4.2.1B.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.2.1B.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-11O for testing of performance group A. Table 4-11O—Performance group A Test Phase

Title

A1

Visual and dimensional inspection

A2

Plating thickness measurement

A3

None

A4

Vibration

A5

None

ID No. ANSI/EIA 364-18A-84

ANSI/EIA 364-28D-99


Measurements to be performed Severity or conditions Unmated connectors

Condition Ia

Title Dimensional inspection

ID No.

Requirements for performance level

Figure 4-11N No defects that would impair through normal operations. No deviation Figure 4from dimensional tolerances. 11AD 4.2.1B.1.3, 4.2.1B.1.4, and 4.2.1B.1.5

Record thickness.

Low-level contact resistance

ANSI/EIA 364-23A-85

50 mΩ maximum initial per mated pair.

Continuity

ANSI/EIA 364-46A-98

No discontinuity at 1 µs or longer (each contact).


ANSI/EIA 364-23A-85

30 mΩ maximum change from initial per mated contact.

57

IEEE Std 1394b-2002


Table 4-11O—Performance group A (continued) Test Phase

Title

A6

Mechanical shock (specified pulse)

A7

None

Measurements to be performed Severity or conditions

ID No. ANSI/EIA 364-27B-96

Condition Aa or Condition E

ID No.


Continuity

ANSI/EIA 364-46A-98

No discontinuity at 1 µs or longer (each contact).


ANSI/EIA 364-23A-85


Title

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-11AE or Figure 4-11AF 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 in IEEE Std 1394-1995 for details. 4.2.1B.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-11P for testing of performance group B. Table 4-11P—Performance group B Test Phase

Title

B1

None

B2

Thermal shock

B3

Humidity (Steady state)

ID No.


Title

ID No.



ANSI/EIA 364-23A-85

50 mΩ maximum initial per mated contact.

ANSI/EIA 364-32B-92

Low-level con10 cycles tact resistance (mated) Test Condition I

ANSI/EIA 364-23A-85


ANSI/EIA 364-31A-83 (R90)

Condition A (96 h) Method II nonenergized


ANSI/EIA 364-23A-85


4.2.1B.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 58


IEEE Std 1394b-2002


See Table 4-11Q for testing of performance group C. Table 4-11Q—Performance group C Test Phase

Title


ID No.

Title

ID No.


C1

Withstanding voltage

ANSI/EIA 364-20A-83 (R90)

Test voltage 100 V dc ± 10 V dc Method C (unmated and unmounted)

Withstanding voltage

ANSI/EIA 364-20A-83 (R90)

No flashover. No sparkover. No excess leakage. No breakdown.

C2

Thermal shock

ANSI/EIA 364-32B-92

Withstanding 10 cycles voltage (same (unmated) Test Condition I conditions as Phase C1)

ANSI/EIA 364-20A-83 (R90)

No flashover. No sparkover. No excess leakage. No breakdown.

C3

Insulation resistance

ANSI/EIA 364-21B-95

Test voltage 100 V dc ± 10 V dc (unmated and unmounted)

Insulation resistance

ANSI/EIA 364-21B-95

100 ΜΩ minimum, between adjacent contacts and contacts and shell.

C4

Humidity (cyclic)

ANSI/EIA 364-31A-83 (R90)

Condition A (96 h.) Method III nonenergized Omit steps 7a and 7b

Insulation resistance (same conditions as Phase C3)

ANSI/EIA 364-21B-95

100 ΜΩ minimum.

4.2.1B.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-11R for testing of performance group D. Table 4-11R—Performance group D Test Phase

Title

D1

None

D2

Continuityhousing (shell)

ID No.



See Figure 4-11AN for measurement points

Title

ID No.



ANSI/EIA 364-23A-85


Contact resistance, braid to socket shell

ANSI/EIA 364-06A-83 (R90)

50 mΩ maximum initial from braid to socket shell at 100 mA, 5 V dc open circuit maximum.

59

IEEE Std 1394b-2002


Table 4-11R—Performance group D (continued) Test Phase

Title

D3

Durability

D4

None

D5


D6

Mixed flowing gas

D7

ID No. ANSI/EIA 364-09B91


Title

ID No.


(a) 2 mated pairs, 5 cycles (b) 2 mated pairs, automatic cycling to 500 cycles, rate 500 cycles/h ± 50 cycles. Low-level contact resistance

ANSI/EIA 364-23A-85



Contact resistance

ANSI/EIA 364-06A-83 (R90)

50 mΩ maximum change from initial from braid to socket shell. 100 mA, 5V dc open circuit maximum.

ANSI/EIA 364-65A97

Class II Exposures: (a) 2 mated pairs, unmated for 1 day (b) 2 mated pairs, mated 10 days


ANSI/EIA 364-23A-85


Durability

ANSI/EIA 364-09B91

(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-65A97

Class II Exposures: Expose mated for 10 days

Low-level contact resistance at end of exposure

ANSI/EIA 364-23A-85


D9



Contact resistance

ANSI/EIA 364-06A-83 (R90)

50 mΩ maximum change from initial from braid to socket shell. 100 mA, 5 V dc open circuit maximum.

60


IEEE Std 1394b-2002


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-11AN—Shield and contact resistance measurement points

4.2.1B.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-11S for testing of performance group E.


61

IEEE Std 1394b-2002


Table 4-11S—Performance group E Test Phase E1

Title Mating and unmating forces

ID No. ANSI/EIA 364-13A-83 (R90)


None

E3


E4

Temperature life

E5


E6

Mating and unmating forces

ANSI/EIA 364-13A-83 (R90)


Unmating only

ANSI/EIA 364-13A-83 (R90)

Unmating force: 10.0 N minimum 39.0 N maximum


ANSI/EIA 364-23A-85


Contact resistance

ANSI/EIA 364-06A-83 (R90)

50 mΩ maximum initial from braid to socket shell. 100 mA, 5 V dc open circuit maximum.

Condition 2 Low-level (79° C) contact 96 hours resistance Method A (mated)

ANSI/EIA 364-23A-85


Contact resistance

ANSI/EIA 364-06A-83 (R90)

50 mΩ maximum change from initial from braid to socket shell.

ANSI/EIA 364-13A-83 (R90)


See Figure 4-11AN ANSI/EIA 364-17B-99

ID No.

Mount socket rig- Mating only idly. Insert receptacle by hand. Auto Rate: 25 mm/min

E2

Title

Mount socket rig- Mating only idly. Insert plug by hand. Unmating only

4.2.1B.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-11T for testing of performance group F.

62


IEEE Std 1394b-2002


Table 4-11T—Performance group F Test Phase

Title

ID No.


Title

ID No.


F1


ANSI/EIA 364-13A-83 (R90)

Mount socket rigidly. Insert plug by hand.

Mating only

F2


ANSI/EIA 364-13A-83 (R90)

Auto rate: 25 mm/min

Unmating only

ANSI/EIA 364-13A-83 (R90)


F3

Durability

ANSI/EIA 364-09C-99

Automatic cycling to 1000 cycles. 500 cycles/h ± 50 cycles

Unmating only

ANSI/EIA 364-13A-83 (R90)

Unmating force at end of durability cycles: 10.0 N minimum 39.0 N maximum

4.2.1B.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-11U 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-11U—Performance group G Test Phase G1

Title Electrostatic Discharge

ID No. IEC 610004-2 (1999-05)

[1 plug] [1 socket] G2

Cable axial pull ANSI/EIA test. 364-38A-85 [2 plugs]

G3

Cable flexing

ANSI/EIA 364-41B-89

[2 plugs]



Title

ID No.


1 kV to 8 kV in Evidence of 1 kV steps. Use discharge 8 mm ball probe. Test unmated.

No evidence of discharge to any of the nine contacts; discharge to shield is acceptable.

Fix plug housing Continuity, visual ANSI/EIA and apply a 364-46A-98 50.0 N load for 1 min on cable axis.

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.

Condition I, dimension X=5.5 ∞ cable diameter; 100 cycles in each of two planes. See Figure 411AO.

(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.

(d) Visual

No jacket tears or visual exposure of shield. No jacket movement greater than 1.5 mm at point of exit.

63

IEEE Std 1394b-2002


To suit cable dia.

Fixed cable holding fixt

45° (25.4 mm) rollers

203.2 mm min.

X

Figure 4-11AO—Fixture for cable flex test

4.2.1B.4 Signal propagation performance criteria The test procedures for all parameters listed in this subclause are described in Annex K of IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000, in ANSI/EIA 364-102-98, and in ANSI/EIA 364-103-99 with the exceptions in test hardware described in 4.2.1B.4.1. Any test condition exceptions are noted in association with each parametric requirement. 4.2.1B.4.1 Test hardware The test fixturing described in this subclause should be used in place of fixtures described in Annex K of IEEE Std 13941995 as amended by IEEE Std 1394a-2000. 4.2.1B.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-11AP). The FR4 relative permittivity should be 4.3 ± 0.2.

0.25 mm +/– 0.025 mm FR4

Layer

Material

Top

17.0 µm Cu

Bottom

17.0 µm Cu

Figure 4-11AP—PCB stack-up for connector-only differential test fixture

64


IEEE Std 1394b-2002


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-11AQ). A through CAL duplicate of all footprint features is provided for time domain CAL. Additional short and open frequency domain test features are also provided.

TEST

CAL CAL

Figure 4-11AQ—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-11AR is an inverse image with light regions representing copper.

Figure 4-11AR—PCB ground layer for connector-only differential test fixture


65

IEEE Std 1394b-2002


4.2.1B.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-11AS). The FR4 relative permittivity should be 4.3 ± 0.2.

0.25 mm ± 0/025 mm 0.25 mm ± 0/025 mm

0.94 mm ± 0.127 mm FR4

0.25 mm ± 0/025 mm

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-11AS—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-11AT). All functions other than signal and signal ground reference are brought through the recommended RC components to ground. A through CAL duplicate of all footprint features is provided for time domain CAL. This includes a mirror-imaged far-end pattern to duplicate the hardware burden of a complete link.

CAL

TEST

Figure 4-11AT—PCB top layer for cable assembly differential test fixture

66


IEEE Std 1394b-2002


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-11AU is an inverse image with light regions representing copper.

Figure 4-11AU—PCB ground layer for cable assembly differential test fixture

4.2.1B.4.1.3 Test fixture schematic The component values shown in Figure 4-11AV 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.

PCB EDGE

#13

33

33

33

1

1M

#12

#11 #4 #5 #3 #6 #7 #8 #2 #9 #1 #10

1

0.05µF

1M A+

A-

B+

0.05µF

B-

Figure 4-11AV—Test fixture schematic Copyright © 2002 IEEE. All rights reserved.

67

IEEE Std 1394b-2002


4.2.1B.4.1.4 Pad position to PHY function map The PCB pad positions shown in the test fixture schematic in Figure 4-11AV would be routed to the functions shown in Table 4-11V in an actual application. Table 4-11V—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

Socket Inner Shield

12, 13

Socket Outer Shield

4.2.1B.4.2 Signal impedance The differential-mode characteristic impedance of the signal pairs within the cable section shall be measured by time domain reflectometry (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 of IEEE Std 1394-1995, as amended by IEEE Std 1394a-2000. 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 of IEEE Std 1394-1995, as amended by IEEE Std 1394a-2000. 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 section shall be measured by TDR with the connector-only differential test fixture at an 80 ps rise time. The recommended procedure is described in B.2 of IEEE Std 1394a-2000 with the following exception in test condition: evaluate differential impedance over a 150 ps exception window with test points at — — — — —

Connector insertion plane – 25 ps Connector insertion plane (reference point, so offset will be 0 ps) Connector insertion plane + 50 ps Connector insertion plane + 100 ps Connector insertion plane + 125 ps

The exception window is extended ± 25 ps beyond the beginning and end of a typical mated connector to evaluate settling performance. Also, in making time domain measurements, multiply all real time values by two to account for the round trip. Impedance in the exception window shall be 68


IEEE Std 1394b-2002


ZTPACONN = (110 ± 20) Ω (differential) ZTPBCONN = (110 ± 20) Ω (differential) 4.2.1B.4.3 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 K.4 of IEEE Std 1394-1995. 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-11W 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-11W with the stop frequency at 1000 MHz. Curves shall be smooth with no anomalous behavior. Table 4-11W—Signal pairs attenuation Frequency

Cable attenuation

Connector allowance

Total allowance

250 MHz

≤ 2.30 dB

1.00 dB

≤ 3.30 dB

400 MHz

≤ 2.90 dB

1.20 dB

≤ 4.10 dB

500 MHz

≤ 3.50 dB

1.35 dB

≤ 4.85 dB

800 MHz

≤ 4.60 dB

1.60 dB

≤ 6.20 dB

1000 MHz

≤ 5.50 dB

2.00 dB

≤ 7.50 dB

4.2.1B.4.4 Signal pairs velocity of propagation 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 of IEEE Std 1394-1995. 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 procedure is described for this measurement in Annex K of IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000. Expected propagation velocity for common-mode signals is VTPACM ≤ 5.05 ns/m VTPBCM ≤ 5.05 ns/m 4.2.1B.4.5 Signal pairs rise time degradation The differential rise time degradation shall be measured through the mated connector section using a differential TDT with an injected rise time of 70 ps or less to establish sufficient measurement resolution. The recommended procedure is described in ANSI/EIA 364-102-98 using the connector-only differential test fixture. Measured rise times shall be trise TPA ≤ 100 ps trise TPB ≤ 100 ps


69

IEEE Std 1394b-2002


4.2.1B.4.6 Signal pairs intrapair propagation skew The maximum difference between the differential-mode propagation delay within the differential twisted pairs shall be measured in the time domain with injected rise time of 70 ps or less through the connector and cable assembly for a 4.5 m length. The recommended procedure is described in ANSI/EIA 364-103-99 using the cable assembly differential test fixture. Measured skew shall be SIP assembly ≤ 160 ps The connector-only skew measured with the connector-only differential test fixture with an injected rise time of 70 ps or less shall be Intrapaircon < 10 ps Interpaircon < 15 ps 4.2.1B.4.7 Crosstalk 4.2.1B.4.7.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%–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 shall be XNEXT, XFEXT ≤ 3% 4.2.1B.4.7.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%–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.2.1B.4.8 Power The power pair conductor within the two specified Beta or bilingual cable assemblies shall be capable of operating at 30 V dc maximum and maintaining 1.5 A maximum operation continuously. 4.2.1B.5 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.

70


IEEE Std 1394b-2002


4.2.1B.5.1 Bilingual port termination and isolation The termination schematics for a bilingual PHY are shown in Figure 4-11AW.

Note: IEEE Std 1394a-2000 sets an upper value on this capacitor.

TPBias

0.3uF (typ)

Mandatory isolation on TPA Shield TPA 55Ω TPA*

55Ω

To speed and arbitration comparators

1MΩ

0.1uF VG

5KΩ

55Ω

-

To connection and arbitration comparators

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

NOTE—Resistor and capacitor values are typical.

Figure 4-11AW—Example of bilingual port termination

Figure 4-11AW reveals a couple of salient points about the connections to bilingual ports. First, because a bilingual port shall work with a Legacy 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 4-11AX, 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 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. In all Beta-capable nodes, the shield on the TPA (pin 5) shall be isolated from all local grounds as shown Figure 4-11AX. This isolation allows future versions of this specification to connect the status contact to the TPB shield ground to sense cable capabilities.


71

IEEE Std 1394b-2002


4.2.1B.5.2 Beta-only port termination and isolation The termination and grounding schemes for a Beta-only device are shown in Figure 4-11AX.

Mandatory isolation on TPA Shield

TPA*

55Ω

Can be eliminated if decoupling capacitors are in receiver

1MΩ

55Ω

270pF

1MΩ

-

TPA

0.1uF

.04µF

.04µF

1MΩ

TPB*

0.1uF

Shield optionally may be attached directly to chassis.

1MΩ

110Ω

TPB

0.1uF

Chassis optionally may be attached directly to logic ground.

optional

55Ω

1MΩ

55Ω

270pF

Alternative termination for TPB


Figure 4-11AX—Beta-only connection to copper cable

As with the bilingual socket, a Beta socket allows the chassis and PHY grounds to be either dc-isolated as shown in Figure 411AX or directly connected. Also, isolation of the TPA (R) line is required. Figure 4-11AX 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 a Legacy-capable port. 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 4-11AX. 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).

72


IEEE Std 1394b-2002


4.2.1B.5.3 PIL-FOP termination and isolation The signal termination for the PIL-FOP interface is shown in the Figure 4-11AY.

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Ω


Figure 4-11AY—Termination for PIL-FOP interface

This termination scheme is used in all cases regardless of whether the 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. 4.2.1B.6 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 illustrated in IEEE Std 1394-1995 and IEEE Std 1394a-2000. Ways in which floating power is provided to the bus and to a bus referenced PHY or FOP are described in 4.2.1B.6.1 and 4.2.1B.6.2. 4.2.1B.6.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.


73

IEEE Std 1394b-2002


Figure 4-11AZ shows how the PHY or FOP electronics can be powered from either local or bus power, while Figure 4-11BA shows how the PHY or FOP power can be slightly simplified if powered only locally.

fuse or current limit to protect against shorts isolation and rectification

20-30 V dc

socket for port 0 VP VG TPA/B + R

system logic ground

PHY/FOP logic ground

6 socket for port 1 VP VG

IN 20-30 V dc input power supply

TPA/B + R 6

OUT socket for port n

PHY/FOP electronics

VP VG TPA/B + R 6

Figure 4-11AZ—Providing power to a floating PHY or FOP, power class 1, 2, or 3

fuse or current limit to protect against shorts isolation and rectification

20-30 V dc


system logic ground




TPA/B + R 6

OUT

PHY/FOP electronics

socket for port n VP VG TPA/B + R 6

Figure 4-11BA—Providing power to a floating PHY or FOP, power class 1, 2, or 3 (alternative)

74


IEEE Std 1394b-2002


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. 4.2.1B.6.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 4-11BB) or to block power when the local PHY or FOP is not powered.

isolation and rectification

fuse or current limit to protect against shorts 8-30 V dc


system logic ground




TPA/B + R 6

OUT

PHY/FOP electronics

socket for port n VP VG TPA/B + R 6

Figure 4-11BB—Providing power to a floating PHY or FOP, power class 4

4.3.5 Cable PHY timing constants Background IEEE Std 1394b-2002 defines new values and changes some existing constants from which the configuration and timing of the PHY in the cable environment may be derived. Delete 4.3.5 in IEEE Std 1394-1995 in its entirety and use 13.3.4 for the requirements for cable interface timing constants for cables that are compliant with IEEE Std 1394b-2002. NOTE—The cable interface timing constants for IEEE 1394a cables should still comply with 4.3.5 in IEEE Std 1394a-2000.


75

IEEE Std 1394b-2002


Add the following clauses to the end of IEEE Std 1394-1995:

9. Short-haul copper PMD electrical specification This clause specifies the electrical signaling properties for the short-haul (4.5 m or less) copper PHY when operating in Beta mode. Figure 9-1 highlights the architectural units discussed in this clause.

Link B PHY


port controller


control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags





to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling

DS-mode functions

Low-power signaling


PMD



PMD Short-haul copper electrical

Short-haul copper electrical

Figure 9-1—PHY master architecture (short-haul copper electrical PMD in context)


77

IEEE Std 1394b-2002


9.1 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-2. 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 implementers to specify vendor components. The reference points for all connections are the points TP2 and TP3 at the transitions between the cabinet and the cable shield. If sections of transmission line exist within the cabinet shield, they are considered to be part of the associated transmit or receive network and not part of the cable plant.

TP1

T+

TP2

TP3

TP4

TRANSMIT

RECEIVE

NETWORK

NETWORK

R+ RPHY

TPHY Figure 9-2—Measurement points (half connection is shown)

NOTE—Schematics in the diagrams in this clause are for illustration only and do not represent the only feasible implementation.

9.2 Transmitter electrical specifications Transmitters defined by this standard are used in bilingual or Beta-only ports. Transmitters of bilingual ports shall be electrically compatible at the signal level with IEEE Std 1394-1995 signals, supporting all the standard electrical operating modes. Bilingual and Beta-only ports shall not be connected to either Legacy 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-1. Table 9-1—Short-haul copper transmitter characteristics when using Beta mode Parameter Signaling

S400β

S800β

S1600β

8B/10B

8B/10B

8B/10B

Units

Nominal data rate

393.22

786.43

1572.9

Mb/s

Nominal baud rate

491.52

983.04

1966.1

MBd

Tolerance

± 100

± 100

± 100

ppm

Maximum

800

800

800

mV

Minimum

300

350

475

mV

Maximum (OFF)

20

20

20

mV

Maximum

800

400

200

ps

Minimum

80

80

80

ps

Differential skew

50

35

12

ps

Differential amplitude

Rise and fall time (10%–90%)

78

Common-mode output impedance

< 55

Ω

Maximum common-mode voltage

2.415

V


IEEE Std 1394b-2002


NOTES 1—Measurements for differential voltages means |V2 – V1|, where V1 and V2 are the single-ended voltages. Differential voltages are defined exactly as in IEEE Std 1394-1995. 2—Transmitter characteristics measured at point TP2.

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-4 and Figure 9-5 when terminated as shown in Figure 9-3.

TP2

TP1

T+

55 Ω ± 1%

TRANSMIT NETWORK TRANSMIT

55 Ω ± 1%

TPHY Figure 9-3—Balanced transmitter test circuit

The normalized amplitude limits in Figure 9-4 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.

The absolute transmitter output timing and amplitude requirements are specified in Table 9-1, Table 9-2, and Figure 9-5. The transmit masks of Figure 9-4 and Figure 9-5 are not used for response time and jitter specifications. .

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-4—Normalized eye diagram mask at TP2 Copyright © 2002 IEEE. All rights reserved.

79

IEEE Std 1394b-2002



800 mV +Vmin 0V –Vmin

–800 mV 0 X1 X2 1-X2 1-X1 1 Normalized time (% of unit interval) Figure 9-5—Absolute eye diagram mask at TP2 Table 9-2—Normalized time intervals for TP2 Symbol

Value

Units

X1

0.14

unit intervals

X2

0.34

unit intervals

NOTES 1—The relationship between Figure 9-4 and Figure 9-5 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-5, but will not pass the normalized mask of Figure 9-4. 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-1). 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-3. 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-3. 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 IEEE Std 1394b-2002, the lower cutoff frequencies for jitter are given in Table 9-9. 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 ) ) .

80


IEEE Std 1394b-2002


Transmitters shall be designed to not be damaged if a case occurs where, through a cabling error, two transmitters are directly connected.

9.3 Receiver electrical specifications Receivers defined by this standard are used in bilingual or Beta-only ports. Receivers on bilingual ports when operating in DS mode shall operate as specified by IEEE Std 1394-1995 and IEEE Std 1304a-2000, supporting all the standard electrical operating modes. Additionally, bilingual and Beta-only receivers shall support a new electrical specification for gigabit signaling and at least S400 Beta-mode signaling. In this higher speed mode of operation, the input is assumed to have new voltage levels, such as measured at TP3. For all connections, the receiver shall be dc-coupled for DS signaling and may be ac-coupled for 8B/10B signaling through a receive network located between TP3 and TP4 as shown in Figure 9-2. The signal requirements for the receiver interface are listed in Table 9-3. The receiver shall operate within the BER objective (10–12) when a short-haul copper data connection is driven by a transmitter meeting the requirements defined in Table 91, Table 9-2, Figure 9-4, and Figure 9-5, and a signal delivered to the receiver meeting the eye diagram requirements specified in Figure 9-6.

.


800mV

200mV 0V –200mV

–800mV 0

0.3 0.5 0.7 Normalized time

1

Figure 9-6—Eye diagram mask at point TP3 Table 9-3—Short-haul copper receiver characteristics when using Beta mode Parameter Signaling

S400β

S800β

S1600β

Units

8B/10B

8B/10B

8B/10B

N/A

Data rate

393.22

786.43

1572.9

Mb/s

Nominal baud rate

491.52

983.04

1966.1

MBd

Baud rate tolerance

± 100

± 100

± 100

ppm

200

200

200

mV

TDR rise time

100

100

50

ps

Exception windowa

700

700

700

ps

110 ±20

110 ±20

110 ±20

Ω

Minimum differential sensitivity Input impedance test conditions:

Input impedance @ TP3: Through connectionb


81

IEEE Std 1394b-2002


Table 9-3—Short-haul copper receiver characteristics when using Beta mode (continued) Parameter At

terminationc

Differential skew Common-mode input impedance Maximum common-mode input voltage Fault voltage tolerance

S400β

S800β

S1600β

Units

110 ±10

110 ±10

110 ±10

Ω

5%

5%

5%

unit interval

> 550

Ω

2.915

V

–0.9 to +3.315

V

aWithin

the exception window, no single impedance excursion shall exceed the through connection impedance tolerance for a period of twice the TDR rise time specification. 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. cThe input impedance at TP3, for the termination, shall be recorded 4.0 ns following the electrical reference plane determined by the receptacle on the receiver bulkhead.

NOTES 1—Measurements for differential voltages means (V2 – V1), where V1 and V2 are the single-ended voltages. Differential voltages are defined exactly as in IEEE Std 1394-1995. 2—The minimum input amplitude to the receiver listed in Table 9-3 and Figure 9-6 is a worst-case specification across all environmental conditions. Restricted environments may allow operation at lower minimum differential voltages, allowing significantly longer operating distances. 3—The receiver sensitivity identifies the minimum eye amplitude at point TP3 to meet the BER objective. 4—Eye diagrams assume the presence of only high-frequency jitter components that are not tracked by the clock recovery circuit. For IEEE Std 1394b-2002, the lower cutoff frequencies for jitter are given in Table 9-9. 5—All times indicated for TDR measurements are recorded times. Recorded times are twice the one-way transit times of the TDR signal.

9.4 Electrical measurements Electrical measurements shall be performed as described in this subclause. 9.4.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-3. 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. Once the normalized amplitude is determined, the data pattern is changed to a continuous D21.5 character stream. The rise time specification is the time interval between the normalized 10% and 90% amplitude levels. 9.4.2 Transmit skew measurement The transmitter skew is the time difference between the T+ and T– outputs measured at the normalized 50% crossover point with a load present (including test equipment) equivalent to the load shown in Figure 9-3. This measurement is taken using two single-ended probes. Skew in the test setup shall be calibrated out. Normalized amplitudes can be determined using the method described in 9.4.1. A continuous D21.5 or K28.7 data pattern is transmitted by the device under test. The data are averaged using an averaging scope. An easy method to view and measure the skew between these signals is to invert one.

82


IEEE Std 1394b-2002


9.4.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-3.

9.5 DC biasing Beta-capable ports can be connected to other devices in several ways, e.g., Legacy ports, bilingual ports, Beta-only ports, and electro-optical networks. Table 9-4 defines the bilingual port signals. For Legacy (DS) signaling, the transmitter on TPA generates TpBias. This is also used to signal to a bilingual port that its connection partner is only Legacy capable. For a 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-4—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)

9.5.1 Beta-mode receiver bias requirements 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-3) and shall self-bias at this common-mode input impedance. The implication of a high commonmode input impedance is that a dc-coupled transmitter will set the receiver’s common-mode input bias voltage.

9.6 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 specification.


83

IEEE Std 1394b-2002


9.6.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). Table 9-5—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.2. 9.6.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-6. Table 9-6—signal_detect value definition Receive conditions Vinput Receiver < 80 mV differential

amplitudea

signal_detect value

FALSE

(No Signal)

Receiving a tone or 8B/10B-encoded characters at a frequency within the operating range of the portb TRUE - AND Minimum differential sensitivity < 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 power-on reset (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-1 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 shall 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. 84


IEEE Std 1394b-2002


The parameters for the response times are defined in Figure 9-7 and specified in Table 9-7.

Occurrence of valid signal Occurrence of no signal

signal_detect t_sd_off

t_sd_on Figure 9-7—signal_detect timing parameters Table 9-7—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

9.6.2.1 Application note (informative) 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) b) c) d)

Signal-level measurement hysteresis Signal-level measurement averaging over a sufficient period to remove pattern-dependent amplitude variations Analysis of the preferred state of the detection circuitry 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-8. Table 9-8—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


85

IEEE Std 1394b-2002


9.7 Jitter 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. 9.7.1 Jitter specifications Numbers in Table 9-10 through Table 9-15 represent high-frequency jitter, i.e., jitter frequency components above the corner frequencies in Table 9-9, 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 O. . Table 9-9—High-frequency jitter corner frequency Speed

Corner frequency

Units

S400β

295

KHz

S800β

590

KHz

S1600β

1.179

MHz

Table 9-10—S400β short-haul copper 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

41

10.55

148

189

0.02

0.005

0.07

0.09

TP2

244

20.35

285

529

0.12

0.010

0.14

0.26

TP2 to TP3

529

16.90

237

766

0.26

0.008

0.11

0.37

TP3

773

26.45

370

1143

0.38

0.013

0.18

0.56

TP3 to TP4

41

10.17

142

183

0.02

0.005

0.07

0.09

TP4

814

28.48

399

1213

0.40

0.014

0.2

0.60

β short-haul copper jitter tolerance Table 9-11—S400β Jitter tolerance Compliance point

86

ps DJ pk-pk

RJ RMS

RJ pk-pk

Unit interval Sinusoidala pk-pk

TJ pk-pk

DJ pk-pk

RJ RMS

RJ pk-pk

Sinusoidala pk-pk

TJ pk-pk

TP1

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

TP2

244

20.35

285

203

732

0.12

0.010

0.140

0.1

0.36

TP3

773

26.45

370

203

1346

0.38

0.013

0.182

0.1

0.66

TP4

814

28.48

399

203

1416

0.40

0.014

0.196

0.1

0.70


IEEE Std 1394b-2002


β short-haul copper jitter output Table 9-12—S800β 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

20

5.28

74

94

0.02

0.005

0.07

0.09

TP2

122

10.17

142

264

0.12

0.010

0.14

0.26

TP2 to TP3

264

8.45

118

382

0.26

0.008

0.11

0.37

TP3

387

13.22

185

572

0.38

0.013

0.18

0.56

TP3 to TP4

20

5.09

71

91

0.02

0.005

0.07

0.09

TP4

407

14.24

199

606

0.40

0.014

0.2

0.60

β short-haul copper jitter tolerance Table 9-13—S800β Jitter tolerance

ps

Unit interval

Compliance 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

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

TP2

122

10.17

142

102

366

0.12

0.010

0.140

0.1

0.36

TP3

387

13.22

185

102

674

0.38

0.013

0.182

0.1

0.66

TP4

407

14.24

199

102

708

0.40

0.014

0.196

0.1

0.70

β short-haul copper jitter output Table 9-14—S1600β 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

66

4.32

61.04

127

0.13

0.009

0.12

0.25

TP1 to TP2

15

2.54

35.61

51

0.03

0.005

0.07

0.10

TP2

81

5.09

71.21

153

0.16

0.010

0.14

0.30

TP2 to TP3

107

5.09

71.21

178

0.21

0.010

0.14

0.35

TP3

188

7.12

101.7

290

0.37

0.014

0.2

0.57

TP3 to TP4

15

0.00

0

15

0.03

0.000

0

0.03

TP4

203

7.12

101.7

305

0.40

0.014

0.2

0.60

β short-haul copper jitter tolerance Table 9-15—S1600β Jitter tolerance

ps

Unit interval

Compliance 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

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

TP2

81

5.09

71

51

204

0.16

0.010

0.140

0.1

0.40

TP3

188

7.12

102

51

341

0.37

0.014

0.200

0.1

0.67

TP4

203

7.12

102

51

356

0.40

0.014

0.200

0.1

0.70


87

IEEE Std 1394b-2002


10. Glass optical fiber physical medium dependent specification This clause specifies the optical signaling properties for an alternate PHY. The focus is on short wavelength lasers (e.g., VCSELs) and glass fibers for long-haul distances. This specification 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

control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags






to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling

DS-mode functions

Low-power signaling


PMD



PMD Glass optical fiber (GOF)

Glass optical fiber (GOF)

Figure 10-1—PHY master architecture (GOF PMD in context)

10.1 PMD block diagram For system conformance, the PMD sublayer is standardized at the following points:


89

IEEE Std 1394b-2002


—

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).

MDI

MDI

TP2

TP1

T+

Optical

Optical

PMD T-

TP4

TP3

PMD

Patch Cord

Transmitter

R+

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 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

90

Signaling speed

Range

Units

S400β

2 to 100

m

S800β

2 to 100

m

S1600β

2 to 100

m


IEEE Std 1394b-2002


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 50 µm MMF value

Description Transmitter type

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

–10

dBm

–35

dBm

7

dB

–117

dB/Hz

9 < CPR

dB

Average launch power (minimum) Average launch power of OFF transmitter

(maximum)b

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/10B-encoded patterns except for short durations during system POR or diagnostics when the optical port is placed in a loopback mode. cRadial 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 (DMD) 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 per measurement techniques defined in 10.7. Table 10-3—Optical receive characteristics Description Signaling rate

Wavelength (range) Average receive power (maximum) Receive sensitivity (minimum) Return loss (minimum)


Value

Units

S400β S800β S1600β 830 to 860

nm

0

dBm

–16.5

dBm

12

dB

91

IEEE Std 1394b-2002


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 Asserted - AND Extinction ratio and other modulation parameters comply with specified limits All other conditions

Unspecified

10.5 Worst-case connection optical power budget and penalties (informative) 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

β S400β

β S800β

β S1600β

Units

Connection optical power budget

6.5

dB

Operating distance

100

m

1.87

dB

Connection insertion

lossb

Connection optical power penaltiesb

0.81

0.92

4.52

dB

Unallocated margin in connection optical power budgetb

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. wavelength of 830 nm is used to calculate connection insertion loss, connection power penalties, and unallocated margin.

bA

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 O. Table 10-6—High-frequency jitter corner frequency

92

Speed

Corner frequency

Units

S400β

295

KHz

S800β

590

KHz

S1600β

1.179

MHz


IEEE Std 1394b-2002


β MMF jitter output Table 10-7—S400β 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

β MMF jitter tolerance Table 10-8—S400β Jitter tolerance

ps

Unit interval

Compliance 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

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

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


ps

Compliance point

DJ pk-pk

Unit interval

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


ps

Unit interval

Compliance point

DJ pk-pk

RJ RMS

RJ pk-pk

Sinusoidala

TP1

NA

NA

NA

aThe

pk-pk

TJ pk-pk

DJ pk-pk

RJ RMS

RJ pk-pk

Sinusoidala pk-pk

TJ pk-pk

NA

NA

NA

NA

NA

NA

NA

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

applied sinusoidal shall be swept at a frequency of 637 KHz.


93

IEEE Std 1394b-2002



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

.


ps

Unit interval

Compliance point

DJ pk-pk

RJ RMS

RJ pk-pk

Sinusoidala

TP1

NA

NA

TP2

132

6.68

TP3

148

TP4

203

aThe

pk-pk

TJ pk-pk

DJ pk-pk

RJ RMS

RJ pk-pk

Sinusoidala pk-pk

TJ pk-pk

NA

NA

NA

NA

NA

NA

NA

NA

92

51

249

0.26

0.013

0.180

0.1

0.49

6.87

97

51

270

0.29

0.014

0.190

0.1

0.53

9.16

127

51

356

0.40

0.018

0.250

0.1

0.70

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. 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.

94


IEEE Std 1394b-2002


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 which 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.

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

Normalized time (unit interval) 0.22 0.375 0.625 0.78

–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.114 p ; jω p = ------ ; ωr ω r = 2π f r ; 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 [B1]9, along with the allowed tolerances for its physical implementation. 9Numbers in brackets correspond to the numbers in the bibliography in Annex


Q.

95

IEEE Std 1394b-2002


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%–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:

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 O.

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

96

Signaling rate

Connection insertion loss

Units

S400β

1.85

dB

S800β

1.85

dB

S1600β

1.85

dB


IEEE Std 1394b-2002


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 MDI to another MDI. Table 10-14—50 µm MMF characteristics Value

Units

Nominal fiber specification wavelength

Description

850

nm

Fiber cable attenuation (maximum)

3.5

dB/km

Modal bandwidth (minimum, OFL)

500

MHz - km

1295 ≤ l0 ≤ 1320

nm

0.11 for 1300 ≤ l0 ≤ 1320

ps/nm2 - km

Zero dispersion wavelength (l0) Dispersion slope (maximum) (S0)

and 0.001(l0 –1190) for 1295 ≤ l0 ≤ 1300

10.9.2 Optical fiber and cable The optical medium requirements are satisfied by the fiber specified in IEC 60793-2 (2001-10). Type A1a (50/125 µm multimode). 10.9.3 Multimode connector insertion loss The maximum connection distances for multimode fiber (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 Optical Fiber Cabling (connection) Jumper Cable PMD

Jumper Cable

Building Cable Connection

Connection

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) b) c)

Performance complies to ANSI/TIA/EIA-568A-00. The dimension and interface meet the specifications of the FOCIS 10 addendum of the TIA/EIA-604-93. Polarity shall be maintained.

Sample drawings of a duplex LC connection (plug and receptacle) are provided in Figure 10-5 and Figure 10-6. Copyright © 2002 IEEE. All rights reserved.

97

IEEE Std 1394b-2002


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: OLF OFL, as described in IEC 60793-1-41 (2001-07) (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.

98


IEEE Std 1394b-2002


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

control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags






to other ports

TX/RX symbol

Port

Port Betamode functions


DS-mode functions

Betamode functions


Low-power signaling

DS-mode functions

Low-power signaling


PMD


PMD

Plastic optical fiber (POF) or Hard polymer clad fiber (HPCF)

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 POF and 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 point-to-point (P2P) interconnection between IEEE 1394b Beta devices for distances of up to 50 m for POF and 100 m for HPCF.


99

IEEE Std 1394b-2002


The PMD specified in this clause has the following general characteristics: — — —

Provides a means of converting the IEEE 1394b 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).

MDI

MDI

TP2

TP1

T+

Optical PMD

T-

Transmitter

TP4

TP3

Optical Patch Cord

R+

PMD 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-C2A or IEC 60793-1-C2B. HPCF shall have a minimum modal bandwidth of 25MHz*km at 650 nm when measured in accordance with IEC 60793-1-C2A or IEC 60793-1-C2B. 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-C1A or IEC 60793-1-C1B using a nominal 650 nm narrow [< 5 nm full width at half maximum (FWHM)] spectral width light source.

100


IEEE Std 1394b-2002


In addition, the fiber loss due to environmental conditions and launch NA 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 Units

Minimum

Maximum

Loss increment

Source center wavelength

Parameters

nm

640

660

Source spectral width (FWHM)

nm

POF: 3.4dB HPCF: 0.1dB

Cable bend radius

mm

40 25.4

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-AA. The network polarity (transmit and receive) shall be managed in accordance with ANSI/TIA/EIA-568-A-95. 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

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.


101

IEEE Std 1394b-2002


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 clause. 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-5. 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. β and S200β β Table 11-2—Optical parameters for POF-HPCF interface at S100β Parameters

POF

HPCF

S100β

S200β

S100β

S200β

640 to 660

640 to 660

640 to 660

640 to 660

Units

Transmitter interface characteristics Center wavelength (FWHM) Maximum spectral width (FWHM) Mean launched

powera

Source numerical aperture (NA)

nm

40

40

40

40

nm

–8 to –2

–8 to –2

–20 to –14

–20 to –14

dBm

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%–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


5.0

3.5

5.0

3.5

ns

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.

102


IEEE Std 1394b-2002


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 Asserted - AND Extinction ratio and other modulation parameters comply with specified limits All other conditions

Unspecified

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 O. Table 11-4 — High-frequency jitter corner frequency Speed

Corner frequency

Units

S100β

74

KHz

S200β

147

KHz

Table 11-5—S100β POF and HPCF 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

814

86.27

1208

2022

0.10

0.011

0.15

0.25

TP1 to TP2

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

Unit interval

Compliance 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

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

TP2

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


103

IEEE Std 1394b-2002


Table 11-7—S200β POF and HPCF 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

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

Table 11-8—S200β POF and HPCF jitter tolerance Jitter tolerance

ps

Unit interval

Compliance 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

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

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

11.8 Permitted number of segments (informative) 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. Table 11-9—Trade-off for the number of connections and transmission length

104

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


IEEE Std 1394b-2002


Table 11-10—Optical parameters in case of POF and HPCF connection Parameters

POF to HPCF

HPCF to POF

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 NA

Transmitter interface characteristics Center wavelength (FWHM) Maximum spectral width (FWHM)

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


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


5.0

3.5

5.0

3.5

ns

Receiver interface characteristics


105

IEEE Std 1394b-2002


12. CAT-5 UTP PMD specification The alternative long-distance PHY specified by this clause enables signaling over CAT-5 UTP cable at the S100β data rate. Figure 12-1 shows the relationship of this clause to the PHY master architecture.

Link B PHY


port controller

control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags






to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling

DS-mode functions

Low-power signaling


PMD



PMD CAT-5 UTP

CAT-5 UTP

Figure 12-1—PHY master architecture (CAT-5 UTP PMD in context)

12.1 Overview This clause specifies the PMD sublayer for CAT-5 UTP connections for the data rate of S100β. The PMD provides all of the services required to transport a suitably coded digital bit stream across the connection segment.


107

IEEE Std 1394b-2002


The PMD sublayer specified in this clause has the following general characteristics: — — —

Provides full-duplex line transmission of Beta-mode packets at S100β. Supports operation over the length of up to 100 m of CAT-5 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 CAT-5 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 in IEEE Std 1394b-2002 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—CAT-5 UTP PMD interfaces

12.3 Operation of CAT-5 connections The CAT-5 connections described in this standard employ full-duplex baseband transmission over two pairs of CAT-5 UTP wiring. The signals are NRZ binary symbols sent at the nominal rate of S100β according to the symbol encodings defined in IEEE Std 1394b-2002.

12.4 Media specification The UTP connection may consist of cable, end connections, and intermediate connection devices, such as patch panels and wall plates.

108


IEEE Std 1394b-2002


12.4.1 100 Ω UTP connection segment specification All components of a connection segment shall meet the requirements specified by ISO/IEC 11801:2000 for CAT-5 compliance. In addition, the connection shall meet the requirements specified by Chapter 7 of ISO/IEC 11801:2000 for a 100 Ω balanced class D connection. Compliance with this specification shall be verified using the procedures detailed in EIA/TIA TSB67. A connection segment containing a combination of no more than 90 m of CAT-5 UTP, no more than 10 m of CAT-5 flexible cord, and no more than four CAT-5 connections is compliant with this specification. 12.4.2 100 Ω 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-5 cables specified by Chapter 8 of ISO/IEC 11801:2000. 12.4.3 Connection 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 in Chapter 9 of ISO/IEC 11801:2000 for CAT-5 100 Ω balanced cabling. The procedures described in A.2 of ISO/IEC 11801:2000 shall be used to make all measurements verifying the compliance of connection hardware. The connector termination practices and UTP cable practices described in Chapter 10 of . ANSI/TIA/EIA-568-A-95 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-1 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 7 and pin 8, respectively, at the other end of the connection segment, and vice versa. When no crossover is provided, pin 1, pin 2, pin 7, and pin 8 of the media interface connection segment shall be connected to pin 1, pin 2, pin 7, and pin 8, 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-1—Media interface connector pin assignments Pin

Circuit

1

TPB

2

TPB*

3 Copyright © 2002 IEEE. All rights reserved.

109

IEEE Std 1394b-2002


Table 12-1—Media interface connector pin assignments (continued) Pin

Circuit

4 5 6 7

TPA

8

TPA*

12.4.5 Autocrossover The PMD shall support an autocrossover function, controlled by PMD_CONTROL_request. On power reset and after a PMD_CONTROL.request(PMD_NO_CROSSOVER) from the connection management function, the PMD shall transmit on TPB and TPB* (pin 1 and pin 2, respectively, on the media interface connector) and shall receive on TPA and TPA* (pin 7 and pin 8, respectively, on the media interface connector). After a PMD_CONTROL.request(PMD_CROSSOVER) from the connection management function, the PMD shall transmit on TPA and TPA* (pin 7 and pin 8, respectively, on the media interface connector) and shall receive on TPB and TPB* (pin 1 and pin 2, respectively, on the media interface connector). The PMD 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) b) c)

1500 V rms at 50 Hz to 60 Hz for 60 s, applied as specified in Section 5.3.2 of IEC 60950 (1999-04). 2250 V dc for 60 s, applied as specified in Section 5.3.2 of IEC 60950 (1999-04)). 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 Publication 60.

No insulation breakdown, as defined in Section 5.3.2 of IEC 60950 (1999-04), 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-2. In addition, the signal shall satisfy the requirements of the signal mask shown in Figure 12-4 and calibrated in Table 12-3 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. 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.

110


IEEE Std 1394b-2002


Table 12-2—UTP transmitter electrical specifications Parameter

Requirement

Units

Maximum

1050

mV

Minimum

950

mV

Maximum

525

mV

Minimum

475

mV

Maximum (OFF)

45

mV

Maximum

4.4

ns

Minimum

3.0

ns

Differential skew

200

ps

2

ns pk-pk

0.1–30 MHz

> 45

dB

30–60 MHz

> 40

dB

60–100 MHz

> 35

dB

> 20

dB

Amplitude (pk-pk)

Amplitude (differential)

Rise/fall time

Jitter Output balance

Return loss

NOTES 1—While this specification is intended to enable compliance with regulations concerning RF emissions, it is not intended to ensure compliance with these regulations. The implementor should consider any applicable local, national, or international regulations. 2—Output balance is defined as the ratio of differential voltage to common-mode voltage at the output of the transmitter. 3—The rise and fall time specification numbers are drawn from the ANSI X3.263-1995.


111

IEEE Std 1394b-2002


Y5

Y4 Y3

Y2

Y1

X1 X2

X3

X4

X5

X6

X7

X8

Figure 12-4—Signal mask for transmitted signal Table 12-3—Coordinates for 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

—

—

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 worst-case connection segment. The worst-case connection segment shall consist of an appropriate length of cable and number of connections, so that the connection attenuation is equivalent to the connection attenuation specified by Chapter 7 in ISO/IEC 11801:2000 for a 100 Ω balanced class D connection. 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 CAT-5 UTP cable up to 100 m and any number of connections up to a maximum of four.

112


IEEE Std 1394b-2002


In addition, the receiver shall comply with the requirements of Table 12-4. Table 12-4—UTP receiver electrical specifications Requirement

Units

Minimum sensitivity (pk-pk)

Parameter

100

mV

Minimum sensitivity (differential amplitude)

50

mV

100 ± 15

Ω

2–30 MHz

> 16

dB

30–60 MHz

> 16 – 20*log(f/30), f is frequency in MHz

dB

60–100 MHz

> 10

dB

Input impedance Return loss:

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 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 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-5. Table 12-5—signal_detect value definition Receive conditions V input Receiver < 100 mV time-averaged, pk-pk differential

signal_detect set to

amplitudea

(No Signal)

FALSE

Receiving a tone or 8B/10B-encoded characters at a frequency within the operating range TRUE of the portb - AND V input Receiver > 500 mV time-averaged, pk-pk differential amplitude - AND 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-2 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.


113

IEEE Std 1394b-2002


Under all valid operating conditions, no false positive TRUE indications shall 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. The parameters for the response times are defined in Figure 12-5 and specified in Table 12-6.

Occurrence of valid signal Occurrence of no signal

signal_detect t_sd_off

t_sd_on

Figure 12-5

signal_detect timing parameters

Table 12-6—signal_detect timing Symbol

Minimum

Maximum

Units

t_sd_on

Delay from valid signal to assertion of signal_detect

Parameter

—

0.5

ms

t_sd_off

Delay from no signal to negation of signal_detect

—

t_sd_on

ms

12.6 PMD implementation (informative) The CAT-5 UTP PMD has a specification that is similar to the specifications contained in other standards supporting 100 m of CAT-5 UTP, such as ANSI X3.263-1995 and AF-PHY-0015.000. While the CAT-5 UTP PMD is compatible with all the logical functions of the B PHY (e.g., 8B/10B coding, scrambling), implementation of the CAT-5 UTP PMD is likely to require further active components (e.g., line drivers, equalizer circuits) in addition to a Beta-capable PHY device that provides the standard electrical interface specified in 4.2.1B. In this respect, it is envisaged that the CAT-5 UTP PMD may be implemented using technology similar to the technology developed for ANSI X3.263-1995 and AF-PHY0015.000. However, use of such technology is not necessary for compliance with IEEE Std 1394b-2002, nor does it guarantee compliance with this standard.

114


IEEE Std 1394b-2002


13. Beta-mode port specification IEEE Std 1394b-2002 leaves all specifications related to DS mode operation unchanged from IEEE Std 1394-1995 (as amended by IEEE Std 1394a-2000). 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

control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags


BOSS arbitration and control token machines




to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling

Cat. 5 UTP - or Glass optical fiber -orPlastic optical fiber -or Beta-only electrical -orBilingual electrical -or DS-only electrical

DS-mode functions

Low-power signaling


PMD



PMD

Cat. 5 UTP - or Glass optical fiber -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)


115

IEEE Std 1394b-2002


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 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 first in, first out (FIFO) buffer, 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 bport_on signal is TRUE (i.e., this signal is set and reset by the connection management state machine). When bport_on is 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. 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 or not they are received within a packet.

116


IEEE Std 1394b-2002


data byte (8 bits)

control token

request

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

Dx.0 or Dx.4 10 data character

abcdeifghj

abcdeifghj

Cz

10

control character

abcdeifghj

10 PMD

parallel to serial Figure 13-2—Scrambling and coding functions (informative)

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 most- through least-significant bits 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 most- through least-significant bits 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.) Copyright © 2002 IEEE. All rights reserved.

117

IEEE Std 1394b-2002


IEEE Std 1394b-2002 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 most- through least-significant bits. A scrambled and un-encoded control symbol has 4 information bits: P’,Q’,R’S’ Bits P’ through S’ are the most- through least-significant bits. 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. Table 13-1—Control mapping Control symbol PQRS

Control token rd0

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: —

—

118

An arbitration request is used for 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 Legacy request or a Legacy 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.


IEEE Std 1394b-2002


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 Legacy request or Legacy 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. 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

Each BOSS isochronous request shall be mapped to a symbol according to Table 13-3. 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 Legacy request or phase. dThe 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).


119

IEEE Std 1394b-2002


A Legacy request or phase shall be mapped to a symbol according to Table 13-4. Table 13-4—Legacy request and phase mapping Request symbola ABCDEFGH

Request LEGACY_REQUEST

0pp01xx1

LEGACY_PHASE

1pp01xx1

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.

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. 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 and this 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. IEEE Std 1394b-2002 employs a side stream scrambler. The same scrambler is used to scramble both data and control information. The scrambler uses the following generating polynomial: G(x) = x11 + x9 + 1

120


IEEE Std 1394b-2002


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, 13.2.5.2, and 13.2.5.3. The next eight successive outputs of the scrambler are then used to scramble the next symbol.

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 most significant bit of the data byte, A, is XORed with the Scr(k); and the least significant bit 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.


121

IEEE Std 1394b-2002


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) (informative)

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 most-significant bit of the request symbol, A, is XORed with the Scr(k); and the least significant bit of the request symbol, H, is XORed with the Scr(k + 7). The scrambling procedure for request symbols is illustrated in Figure 13-5.

122


IEEE Std 1394b-2002



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) (informative)

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.


123

IEEE Std 1394b-2002



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) (informative)

13.2.6 Coding The symbol coding function defines and implements the character coding scheme employed by IEEE Std 1394b-2002. 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. IEEE Std 1394b-2002 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 [B2] 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.

124


IEEE Std 1394b-2002


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. Table 13-6—5B/6B coding Inputs

abcdei outputs

Symbol

A’B’C’D’E’

rd > 0

rd < 0

D0

00000

011000

100111

D1

10000

100010

011101

D2

01000

010010

101101

D3

11000

D4

00100

D5

10100

101001

D6

01100

011001

110001 001010


110101

rd1 –rd

Inputs

abcdei outputs

Symbol


rd > 0

rd < 0

D16

00001

100100

011011

D17

10001

100011

D18

01001

010011

rd

D19

11001

110010

–rd

D20

00101

001011

rd

D21

10101

101010

D22

01101

011010

rd1 –rd rd

125

IEEE Std 1394b-2002


Table 13-6—5B/6B coding (continued) Inputs

abcdei outputs

Symbol


rd > 0

rd < 0

D7

11100

000111

111000

D8

00010

000110

111001

D9

10010

100101

D10

01010

D11 D12

rd1

Inputs

abcdei outputs

Symbol


rd > 0

rd < 0

rd

D23

11101

000101

111010

–rd

D24

00011

001100

110011

rd

D25

10011

100110

010101

D26

01011

010110

11010

110100

D27

11011

00110

001101

D28

00111

D13

10110

101100

D29

10111

010001

101110

D14

01110

011100

D30

01111

100001

011110

D15

11110

D31

11111

010100

101011

101000

010111

–rd

001001

110110

001110

rd1 –rd rd –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

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 –rd

A7 replaces P7 if the following is true: (rd 0 i data_table[i][0] data_table[i][1] 00000 000 100111 0100 011000 1011 00000 001 100111 0010 011000 1101 00000 010 100111 0101 011000 0101 00000 011 100111 0110 011000 0110 00000 100 100111 1001 011000 1001 00000 101 100111 1010 011000 1010 00000 110 100111 0011 011000 1100 00000 111 100111 0001 011000 1110 00001 000 011011 0100 100100 1011 00001 001 011011 0010 100100 1101 00001 010 011011 0101 100100 0101 00001 011 011011 0110 100100 0110 00001 100 011011 1001 100100 1001 00001 101 011011 1010 100100 1010 00001 110 011011 0011 100100 1100 00001 111 011011 0001 100100 1110 00010 000 111001 0100 000110 1011 00010 001 111001 0010 000110 1101 00010 010 111001 0101 000110 0101 00010 011 111001 0110 000110 0110 00010 100 111001 1001 000110 1001 00010 101 111001 1010 000110 1010 00010 110 111001 0011 000110 1100 00010 111 111001 0001 000110 1110 00011 000 110011 0100 001100 1011 00011 001 110011 0010 001100 1101 00011 010 110011 0101 001100 0101 00011 011 110011 0110 001100 0110 00011 100 110011 1001 001100 1001 00011 101 110011 1010 001100 1010 00011 110 110011 0011 001100 1100 00011 111 110011 0001 001100 1110


Name D4.0 D4.4 D4.2 D4.6 D4.1 D4.5 D4.3 D4.7 D20.0 D20.4 D20.2 D20.6 D20.1 D20.5 D20.3 D20.7 D12.0 D12.4 D12.2 D12.6 D12.1 D12.5 D12.3 D12.7 D28.0 D28.4 D28.2 D28.6 D28.1 D28.5 D28.3 D28.7

Input abcdei fghj output A’B’C’D’E’F’G’H’ rd < 0 rd > 0 i data_table[i][0] data_table[i][1] 00100 000 110101 0100 001010 1011 00100 001 110101 0010 001010 1101 00100 010 110101 0101 001010 0101 00100 011 110101 0110 001010 0110 00100 100 110101 1001 001010 1001 00100 101 110101 1010 001010 1010 00100 110 110101 0011 001010 1100 00100 111 110101 0001 001010 1110 00101 000 001011 1011 001011 0100 00101 001 001011 1101 001011 0010 00101 010 001011 0101 001011 0101 00101 011 001011 0110 001011 0110 00101 100 001011 1001 001011 1001 00101 101 001011 1010 001011 1010 00101 110 001011 1100 001011 0011 00101 111 001011 0111 001011 0001 00110 000 001101 1011 001101 0100 00110 001 001101 1101 001101 0010 00110 010 001101 0101 001101 0101 00110 011 001101 0110 001101 0110 00110 100 001101 1001 001101 1001 00110 101 001101 1010 001101 1010 00110 110 001101 1100 001101 0011 00110 111 001101 1110 001101 0001 00111 000 001110 1011 001110 0100 00111 001 001110 1101 001110 0010 00111 010 001110 0101 001110 0101 00111 011 001110 0110 001110 0110 00111 100 001110 1001 001110 1001 00111 101 001110 1010 001110 1010 00111 110 001110 1100 001110 0011 00111 111 001110 1110 001110 0001

127

IEEE Std 1394b-2002


Table 13-8—Valid data characters (continued)


128





IEEE Std 1394b-2002








129

IEEE Std 1394b-2002







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. One of these special characters, K28.5, is used during synchronization and training. This character is defined in Table 13-9. Table 13-9—K28.5 special character Control character name K28.5

130

abcdei fghj values rd < 0

rd > 0

comma_table[0] comma_table[1] 001111 1010

110000 0101


IEEE Std 1394b-2002


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). 13.2.6.2 Control coding In addition to the Dx.y and Kx.y characters, IEEE Std 1394b-2002 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. 13.2.6.2.1 Valid control code characters IEEE Std 1394b-2002 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’. Table 13-10—Control coding abcdeifghj outputs

Control character name

P’Q’R’S’ i

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


rd 0

131

IEEE Std 1394b-2002


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. 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

132

Output

Name

rd < 0

rd > 0

A’B’C’D’E’F’G’H’

D28.0

001110 1011

001110 0100

00111 000

K28.5

001111 1010

110000 0101

00111 000



IEEE Std 1394b-2002

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, 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) b)

c)

d)

The running disparity is updated at the end of each character subblock, where character subblocks are the six most-significant bits and four least-significant bits of the character, i.e., bits a,b,c,d,e,i and bits f,g,h,j. 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. 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. 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 six-bit subblocks 000111 and 111000 and four-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, rule a) through rule d) (listed above) 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 least significant bit (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 there is no polarity inversion). 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, and 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.


133

IEEE Std 1394b-2002


Table 13-12—Control stretching formats Effective speed

Port operating speed

S100

S200

S400

S800 S1600 S3200

S100

C

S200

CC

S400

CCCC

CC

C

S800

CCCCCCCC

CCCC

CC

C

S1600

CCCCCCCCCCCCCCCC

CCCCCCCC

CCCC

CC

S3200

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC CCCCCCCC CCCC CC

C

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.

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. 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.

134


IEEE Std 1394b-2002


. 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 In contrast to DS ports, the port transmission speed remains constant for all packet speeds. 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 Legacy or Beta, respectively (see 16.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 13-13. Each speed control token shall be coded according to 13.2.6.2 and scrambled according to 13.2.5.3. Copyright © 2002 IEEE. All rights reserved.

135

IEEE Std 1394b-2002


Table 13-13—Speed code formats Port operating speed

Packet speed S100

S200

S400

S800

S1600 S3200

S100

Sx

S200

S cS x

Sx

S400

S cS cS xS c

S cS x

Sx

S800

S cS cS cS xS cS cS cS c

S cS cS xS c

S cS x

Sb

S1600

S cS cS cS cS xS cS cS cS cS cS cS cS cS cS cS c


S cS cS xS c

S cS b

S3200

S cS cS cS cS cS xS cS cS cS cS cS cS cS cS cS c S cS cS cS cS cS cS cS cS cS cS cS cS cS cS cS c

S cS cS cS cS xS cS cS c S cS cS cS cS cS cS cS c


S cS cS bS c S cS b

Sb

Speed signal duration (ns)

80

40

20

10

2.5

Sb

5

NOTES 1—Sc represents the SPEEDc control token. 2—Sx represents the SPEEDa control token when the Legacy 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 Legacy format S100 packet originated by a border node with a Legacy link or for a forwarded packet where the received packet has no speed code. See 16.3.1.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. Table 13-14—Data padding formats Packet speed

Port operating speed

S100

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

S200

S400

S800

S1600 S3200

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 scrambling and coding.

136



IEEE Std 1394b-2002

If the packet speed is less than the port speed, then any payload control symbols are stretched as described in 13.3.1.1. 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). 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.


137

IEEE Std 1394b-2002


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. When control symbols are received within a packet prefix (i.e., DATA_PREFIX symbols between the speed signal and the packet data), the port shall determine the stretching format of the control symbols from the packet speed and port operating speed according to Table 13-12. For the first control character in each stretched sequence, the port shall determine the received control token according to Table 13-1 and indicate this to the arbitration state machine. Other control symbols in the stretched sequence shall not be indicated to the arbitration state machine (i.e., the port shall indicate only the control symbol received in the payload position). 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. 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

138


IEEE Std 1394b-2002


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 xS c

—

—

S100

S200

S400

S800


—

—

—

S100

S200

S400

S cS cS cS cS xS cS cS cS cS cS cS cS cS cS cS c

—

—

—

—

S100

S200

ScScScScScSxScScScScScScScScScScScScScS cS cS cS cS cS cS cS cS cS cS cS cS c

—

—

—

—

—

S100

NOTES 1—Sc represents the SPEEDc control token. 2—Sx represents either a SPEEDa or a SPEEDb token.

A speed code shall be considered valid only if it meets the following criteria: a) b)

All speed tokens are received consecutively. 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 a Legacy 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.


139

IEEE Std 1394b-2002


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. 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) b) c) d) e)

Does not belong to the set of data characters nor to the set of control characters, or Has incorrect disparity, or Is a valid data character, but not Dx.0 or Dx.4, and occurs outside the bounds of a packet, or Is a valid payload character, but is not received in the correct payload position within a padded packet, or 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

bport_on

Set to TRUE to instruct the Beta port to commence operating, set to FALSE to instruct the Beta port to cease operating

bport_sync_ok

Port has achieved synchronization with peer port

power_reset

TRUE during power reset, goes FALSE at the end of power reset

rx_sync_error

TRUE if receiver failed to complete synchronization

scrambler_sync

SYNC_CHECK consecutive occurrences of TRAINING or OPERATION received

scrambler_sync_error

TRUE if unexpected request type is received during scrambler synchronization

sync_error_signal

Receiver error monitor has detected loss of synchronization

sync_lost_signal

Receiver is in a resynchronization state

140


IEEE Std 1394b-2002


13.4.1 Port transmit state machine Figure 13-8 specifies the port transmit state machine, and following the figure are notes applicable to this state machine.

PTX0:Off tx_off_actions()

PTX1:Sync Lost

PTX3:Transmit

tx_sync_lost_actions();

bport_transmit_actions();

PTX2:Local Sync tx_sync_actions();

bport_on PTX0:PTX1

!sync_lost_signal PTX1:PTX2 !bport_on PTX1:PTX0

sync_lost_signal PTX2:PTX1

bport_sync_ok PTX2:PTX3

!bport_on

PTX2:PTX0

power_reset !bport_on || sync_lost_signal 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 bport_on 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 bport_on to FALSE, (e.g., if it determines that training has failed by timing out), then the port returns to the PTX0: Off state. 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 bport_on to FALSE. Copyright © 2002 IEEE. All rights reserved.

141

IEEE Std 1394b-2002


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 bport_on to FALSE. 13.4.2 Port receive state machine Figure 13-9 specifies the port receive state machine, and following the figure are notes applicable to this state machine.

PRX0:Off

PRX1:Resync1

PRX4:Receive

rx_off_actions()

rx_sync_lost_actions();

bport_receive_actions();

PRX3:Local Sync rx_sync_actions();

power_reset rx_sync_error

bport_on PRX0:PRX1

PRX3:PRX1

PRX2: Resync2 scrambler_sync_actions();

!bport_on PRX1:PRX0

bport_on PRX1:PRX2 !sync_error_signal scrambler_sync_error PRX2:PRX1

!bport_on

PRX3:PRX4 scrambler_sync PRX2:PRX3

PRX2:PRX0

!bport_on PRX3:PRX0

!bport_on || sync_error_signal

PRX4:PRX0

Figure 13-9—Port receive state machine State PRX0: Off. The port is not required to receive or decode any signals. The sync_lost_signal 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 bport_on to TRUE, the port shall enter the PRX1: Resync1 state and attempt to acquire bit and character synchronization. 142



IEEE Std 1394b-2002

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 bport_on 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 bport_on 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 bport_on 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 bport_on to FALSE or if the receiver loses synchronization, then the port returns to the PRX0: Off state.


143

IEEE Std 1394b-2002


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


control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags





to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling


DS-mode functions

Low-power signaling


PMD



PMD


Figure 14-1—PHY master architecture (data routing, arbitration, and control interfaces in context) Each connection manager interacts with the corresponding PMD layers, the Beta port functions, the DS-mode functions, and the repeater functions by appropriate shared variables.


145

IEEE Std 1394b-2002

IEEE STANDARD FOR A HIGH PERFORMANCE

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 Beta port a) b)

c) d) e) f) g) h) i)

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 bought out to a Legacy 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 RJ-45 socket, 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. Table 14-1—Media-dependent Beta-mode speed requirements Transmission medium

Required speed

Maximum allowed speed

Beta copper connector

S400β

S3200β

RJ-45 connector and CAT-5 UTP cable

S100β

S100β

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 max_port_speed register or other implementation-dependent mechanism.

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. 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.

146


IEEE Std 1394b-2002


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 the port connection manager state machine Variable

Description

active

Indicates that the port is in P2: Active state (set by state machine transitions to and from P2).

Beta_mode

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). This is maintained as a read-only bit in the port register map.

bport_sync_ok

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.This is maintained as a read-only bit in the port register map.

connection_unreliable

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. Reset by software after appropriate higher level action has been taken.

disable_request

Requests transmission of DISABLE_NOTIFY at the end of the next packet.

disabled

PHY register bit. Set to disable a port under software control, and indicates that the port is in the P6: Disabled state.

do_standby

Is true when the port has been commanded to be a standby initiator.

force_disconnect

Is true to force disconnect and retest of a port after detecting a loop during reset.

in_standby

Indicates the port is in the P7: Standby Initiator, P8: Standby Target, P9: Standby, or P10: Restore state.

loop_disabled

Indicates the port is in the P12: Loop Disabled state.

loop_to_detect

Is true during reset up to S1: Self-ID Grant or S2: Self-ID Receive state.(See Figure 16-9)

receive_ok

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. This is maintained as a read-only bit in the port register map (supersedes the Bias bit in IEEE Std 1394a-2000).

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.

resume_fault

Is set when the peer port fails to complete resume.

rx_disabled

Indicates the reception of a DISABLE_NOTIFY token from the peer port.

rx_standby

Indicates the reception of a STANDBY token from the peer port.

rx_suspend

Indicates the reception of a SUSPEND token from the peer port.

signaled

Indicates the transmission of a DISABLE_NOTIFY, SUSPEND, or STANDBY token.

standby_fault

Is set when the peer port fails to complete standby.

suspend_request

Requests the transmission of a SUSPEND at the end of the next packet and/or indicates that the port is suspending.

suspend_fault

Is set when the peer port fails to complete suspend.

untested

Indicated the port is connected, but untested.

untested_state

Indicates the port is in the P11: Untested state.


147

IEEE Std 1394b-2002


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

Minimum

Maximum

Comment

41.6 µs

52.1 µs

Time on a DS-capable port to filter bias_detect upon the detection of TpBias before updating the PHY register Receive_OK bit (~4096/BASE_RATE)

Number of times a collision condition occurs to conclude that a loop exists

7

COLLISION_LIMIT

Connection debounce time

330 ms

350 ms

DISCONNECTED_TONE_ INTERVAL

42.66 ms

48 ms

MAX_OCCUPANCY_TIME

83.975 µs 83.993 µs 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)

CONNECT_TIMEOUT

TONE_DURATION * 4 * TONE_INTERVAL (2**22/BASE_RATE)

(~8256/BASE_RATE)

PORT_ENABLE_TIME

RECEIVE_OK_HANDSHAKE

5.3 ms

80.0 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.

85.3 ms

Time from first receipt of signal for a receiver to be operating within the BER objective of 10–12 Time for an active port to confirm a reset signal DISCONNECTED_TONE_INTERVAL/TONE_DURATION + 1, the number of checks that are made between connection tone intervals

65

RESUME_CHECKS

SPEEDCODE_BIT_INTERVAL

1 ms

1 ms

RECEIVER_INIT_TIME RESET_DETECT

Number of tries at toning before switching to trying TpBias

4

NUM_OF_TRIES

1.9998 ms 2.0002 ms TONE_DURATION * 3, the time between the end of one tone position and the start of the next 16384

SYNCHRONIZATION_LENGTH

(Maximum number of transmitted bits for scrambler synchronization + byte synchronization rounded up to a power of two)

TEST_INTERVAL

7.811 µs

7.814 µs

Time to allow a test value to be returned as a loop test symbol (LTS) (~768/BASE_RATE)

TONE_DURATION

666.6 µs

666.7 µs

2**16/BASE_RATE

TONE_GAP TONE_INTERVAL

8 16

TONE_INTERVAL / 2, the number of tone units in the gap before the start bit The number of tone units in a tone interval

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 LTP with ATTACH_IN_PROGRESS is seen by all controlling nodes on other buses before an attach is completed.

148



IEEE Std 1394b-2002

14.4 Port controller A PHY shall include a single port controller. Its behavior is specified as continuously running C code and it maintains a record of whether the node is an isolated, boundary, border, or nephew 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 Beta_mode[NPORT] and the array constant Beta_mode_only_port[NPORT] with the connection manager for the respective port. Note that in this C code, the variables are subscripted, whereas in the port connection manager and C code, the same variables are unsubscripted.

14.5 Port connection manager state machine The port connection manager state machine operates independently for each port. A port that is capable of operation only in DS mode shall behave as specified in 4.4.4 of IEEE Std 1394a-2000. A port that is capable of operation in Beta mode or in both DS mode and Beta mode (i.e., a bilingual port) shall behave as specified in this subclause. In all cases, while a port is in the P2: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 P2:Active, it is permissible for it to lower its power consumption; the only functional component of a PHY port that shall be active in all states is the physical connection detect circuitry or toning circuitry, as appropriate. Figure 14-2 specifies the port connection manager state machine, and following the figure are notes applicable to this state machine.


149

IEEE Std 1394b-2002


P11: Untested P0: Disconnected P0:P11

P2: Active

untested_actions() connected && Beta_mode

!loop_disabled

P11:P2

connection_unreliable = FALSE;

active = TRUE;

P6:P11

P12: Loop Disabled loop_disabled_actions() loop_disabled !connected

P12:P0

loop_disabled = FALSE;

(Beta_mode && loop_to_detect && !bport_sync_OK) || force_disconnect P2:P11 active = FALSE; force_disconnect = TRUE;

P11:P12

connected && (!loop_disabled || receive_ok) P12:P11

loop_disabled = FALSE;

P1: Resuming resume_actions()

P0:P1

connected && !Beta_mode connection_unreliable = FALSE;

P5: Suspended suspended_actions() resume_fault

P1:P5 P1:P2

connected && (resume || (!suspend_fault && receive_ok))

!resume_fault active = TRUE;

P5:P1 resume_fault = suspend_fault = FALSE; !connected

!receive_ok && suspend_fault suspend_fault = FALSE;

P3: Suspend Initiator

P5:P0

suspend_fault = FALSE; resume_fault = FALSE;

suspend_initiator_actions() P3:P5

P5:P5

(!rx_ok || (suspend_request && signaled)) && !(Beta_mode && loop_to_detect && !bport_sync_ok) && !force_disconnect P2:P3 active = FALSE;

P4: Suspend Target Power reset

suspend_target_actions()

port_power_ reset()

P4:P5

P6: Disabled

(rx_ok && ((portR_arb == SUSPEND) || (portR_arb == DISABLE_NOTIFY))) && !force_disconnect P2:P4 active = FALSE;

disabled_actions() connected && !disabled && !Beta_mode P6:P5 connected && !disabled && Beta_mode P6:P11 !connected && !disabled

P6:P0

disabled || (disable_request && signaled) active = FALSE; resume_fault = suspend_fault = standby_fault = loop_disabled = FALSE;

All:P6

P10: Restoring restore_actions() !connected

P10:P0

connected

P10:P2

active = TRUE;

P7: Standby Initiator standby_initiator_actions()

P9: Standby standby_actions() connected && (restore || (!standby_fault && receive_ok)) P9:P10 standby_fault = FALSE;

!connected standby_fault = in_standby = FALSE;

P7:P9

P8: Standby Target standby_target_actions() P8:P9

P9:P0

rx_ok && do_standby && signaled && !force_disconnect P2:P7 active = FALSE;

rx_ok && (portR_arb == STANDBY) && !force_disconnect P2:P8 active = FALSE;

Figure 14-2—Port connection manager state machine 150



IEEE Std 1394b-2002

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 by setting the disabled bit 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. Transition P0:P11. When a port’s connection detect circuitry signals that its peer PHY port is physically connected, the PHY port transitions to the P11: Untested state. 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 receive_ok to determine whether normal operations may be resumed. If the port is connected, receive_ok 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 boundary 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 repeating arbitration signals or clocked data. While the port remains active, the behavior of this port and the remainder of the PHY are subject to the cable arbitration states specified in Clause 16. Transition P2:P3. Upon the loss of receive_ok 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 receive_ok 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 do_standby variable to 1, the PHY port leaves the P2: Active state to start functioning as a standby initiator. 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 receive_ok to be zero. If RECEIVE_OK_HANDSHAKE elapses and the connected peer PHY has not driven TpBias low (DS mode) or ceased sending a valid signal (Beta mode), the suspend operation has faulted 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. Transition P3:P5. Upon completion of the actions associated with this state, the PHY port unconditionally transitions to the P5: Suspended state.


151

IEEE Std 1394b-2002


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. 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) b)

A nonzero value for the port’s resume variable or The detection of receive_ok if the port’s suspend_fault 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., receive_ok was still present), the fault is cleared if and when receive_ok 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 lowpower consumption state. If the hard_disable 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 low-power state. If the hard-disable flag is FALSE and the port was operating in Beta mode, then it shall maintain connectivity information by toning. If the hard_disable flag is TRUE, then the port shall not engage in toning. 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. State P7:Standby Initiator. A standby initiator waits for receive_ok 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 standby_fault bit is set to 1. As soon as either receive_ok goes to zero or RECEIVE_OK_HANDSHAKE elapses, the standby initiator places all outputs in a high-impedance state. 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 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.

152



IEEE Std 1394b-2002

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. Transition P9:P0. If the port loses its physical connection to its peer port, then it 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) b)

A nonzero value for the port’s restore variable or The detection of receive_ok if the port’s standby_fault variable is zero.

A port’s restore variable may be set indirectly as the result of the resumption of other PHY ports. 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 receive_ok 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 (this is inferred when the local port starts to receive 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. 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 (untested_fault), then the port transitions to the P12: Loop Disabled state. State P12: Loop Disabled. The port is disabled, but continues to tone and to use its signal detect circuitry 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. If a bus reset is detected or a resume signal is received from the peer port, the port transitions to the P11: Loop Disabled state. Transition P12:P0. If a disconnection is detected, then the port transitions to the P12: Loop Disabled state.


153

IEEE Std 1394b-2002


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 Betamode operation only. If a node has only one active port, then the connection on this port can be placed into Standby. 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 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 a Legacy link, its enable_standby flag is zero, or its 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, isochronous resource manager, 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) b) c) d) e)

Node ID Gap count Gap count reset disable status Bus phase Reset notify (bus reset occurred while the port was in Standby)

The PHY shall not repeat this packet on the PHY-link or PIL-FOP interface. 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-identify 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 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-identify 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 the validity of each received self-identify sequence and, if not valid, cause a bus reset.

154



IEEE Std 1394b-2002

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 amendment (IEEE Std 1394b-2002) 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 a 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 contents 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. (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.


155

IEEE Std 1394b-2002


controlling Node for subnet A

Subnet A

Subnet B

Test value number= 21

Test value number= 12

A1 (21)

A1 connection to B1 allowed

B1 (12)

untested connections A2 (21)

controlling Node for subnet B

B2 (12) B2 connection to A2 blocked

Figure 14-3—Example of dominant subnet

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. 14.7.2 Loop test data (LTD) The loop test data (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: TEST and ATTACH_IN_PROGRESS. 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. 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. 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 not 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

156



IEEE Std 1394b-2002

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. 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 (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 is in 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 HR When an LTP is received, the LTD in the LTP is copied to an 8 bit holding register, denoted as 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. Copyright © 2002 IEEE. All rights reserved.

157

IEEE Std 1394b-2002


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. 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 using 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 Legacy format, at S100, ensuring that the LTP can be propagated through Legacy 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 most significant bit 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 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. 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).

158



IEEE Std 1394b-2002

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 and then sending an LTP. 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)

b) c)

d)

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. 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. 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. A long bus reset is received on another untested port on which an ATTACH_REQUEST has been received (the reset port). 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. 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. 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.


159

IEEE Std 1394b-2002


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 Legacy nodes When a port is connected to Legacy node, LTPs are not exchanged. Instead, the Legacy connection is activated according to Legacy rules. 14.7.13 Loop detection during bus initialization Some loop conditions may be detected during bus initialization. Three conditions are explicitly treated: a) b) c)

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 Legacy nodes or the loop is formed as a result of a connection on the bus being resumed. Arbitration state timeout, which can occur up to the time at which the port enters the S1: Self-ID Grant or S2: Self-ID Receive state if the node is connected to a network of Legacy nodes that are in a loop. Repeated resets, which can occur in similar circumstances to condition b with a loop on a network that includes IEEE Std 1394-1995 nodes, which 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 a 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 Legacy ports. While waiting for the tree identify process to complete on active Legacy 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 Legacy ports that are participating in tree identification. When the tree identify process on the Legacy ports has completed, LTS is sent on the Beta ports and a loop-free build is completed on the border node. 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. (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

160



IEEE Std 1394b-2002

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 a Legacy 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. 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 P. A PHY shall apply the following algorithm for each port that is capable of operating in Beta mode: a)

b)

Begin toning. If a tone is heard, then Beta mode is established and the algorithm exits. If TpBias is detected, then go straight to step b). Otherwise, stay in this state until 10 tones 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). 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. — If bias is still present DS mode is established. Assert TpBias and the algorithm exits. — If bias is not present, generate the startup tone. An attached PHY compliant with IEEE Std 1394b-2002 will respond with the startup tone, and Beta mode will be established and algorithm exits. If a tone is not received, assert TpBias for 12 * RESET_DETECT. If bias is then detected, DS mode is established and algorithm exits. Otherwise, go back to step a).

An IEEE Std 1394-1995 port at the far end will assert TpBias on its TPA, but will not see TpBias on its TPB and, therefore, will not think it is connected. An IEEE 1394a node on the other end will sense con_status and start its debounce timeouts. If an IEEE 1394a port is at the other end of the connection, and, if the local Beta port does not respond to TpBias before the IEEE 1394a port times out, then the IEEE 1394a port will enter into a resume-fault 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 IEEE 1394a port to wake and become a resume target. If the far port is an IEEE Std 1394-1995 port, 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.


161

IEEE Std 1394b-2002


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 Legacy

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

No

a

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 not to 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 speed negotiating procedure that is described in this clause. 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 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.

162


IEEE Std 1394b-2002


42.67ms 21.33ms

2.67ms 666.67µs

666.67µs

ack

1 0 1 0 1 0

0 1 1 0 0 1

0 0 0 1 1 1

X X X X X X

X X X X X X

0 0 0 0 0 0

S100 S200 S400 S800 S1600 S3200 PIL_Capable FOP_Capable

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). Two further bits in the speed code are allocated to indicate the PIL_Capable and FOP_Capable properties of the peer port. 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. 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 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).


163

IEEE Std 1394b-2002


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 IEEE Std 1394a-2000 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 algorithm described 14.8.2 and 14.8.3 is used to establish and maintain connectivity, including Beta-mode operation capability and operating speed. Care is taken to provide similar functionality to IEEE Std 1394a-2000 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 IEEE Std 1394a-2000), 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. This is equivalent to the Legacy “connect detect” hardware comparator being active. When re-enabled, a disabled port operating in Beta mode shall enter the Untested state.

164


IEEE Std 1394b-2002


15. PHY register map Although Annex J of IEEE Std 1394-1995, from which this clause is derived, originally described an interface to a discrete PHY, 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 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 1394b-2002. 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.

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 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). 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


165

IEEE Std 1394b-2002


. Table 15-1—PHY register fields for the cable environment Field

Power reset value

Size

Type

B-link

1

ru

Vendordependent

PHY holds this to 1 when a B Link is connected to the PHY.

Bridge

2

rw

See description

This field 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.

Contender

1

rw

See description

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.

Delay

4

r

Vendordependent

Worst-case repeater delay, expressed as 144 + (delay * 20) ns.

Enab_accel

1

rw

0 (see description)

Preserved for backwards compatibility. Used only for the implementation of Legacy link request cancellation rules as specified in Table 5A-16 of IEEE Std 1394a-2000. IEEE 1394a accelerations and prevention of cycle start starvation are controlled by the PHY learning that the link issues PH_CYCLE_START_DUE (B link) or decelerate (Legacy link) requests. When the PHY is configured to use a Legacy link, the initial value follows the rules given in IEEE Std 1394a-2000.

Enab_multi

1

rw

0 (see description)

Preserved for backwards compatibility. If a Legacy link is used, then this bit shall obey the specification in IEEE Std 1394a-2000.

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. Is cleared by the PHY when the PHY-link interface is enabled. If a nephew has a port in Standby when the PHY clears this bit, then the port 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.

Extended

3

r

7

Gap_count

6

rwu

3F16

Used to configure the arbitration timer setting to optimize gap times according to the topology of the bus. See 4.3.6 of IEEE Std 1394-1995 for the encoding of this field.

IBR

1

rwu

0

Used to initiate 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

Used to initiate short (arbitrated) bus reset. When set to 1, 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 selfclearing.

Jitter

3

r

Vendordependent

The maximum variance of either arbitration or data repeat delay, expressed as 2 × (Jitter + 1)/BASE_RATE µs.

LCtrl

1

rw

See description

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.

Loop

1

rcu

0

166

Description

This field shall have a constant value of seven, which indicates the extended PHY register map.

Indicates loop detect. A write of 1 to this bit clears it to 0.


IEEE Std 1394b-2002


PHY register fields for the cable environment (continued)

Table 15-1

Power reset value

Description

Field

Size

Type

Max_legacy_path_speed

3

ru

Max_speed

3

r

111b

Page_select

3

rw

Vendordependent

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 (see 4.2.2.7 of IEEE Std 1394a-2000).

Pwr_class

3

rw

Vendordependent

Power class. Controls the value of the pwr field transmitted in the self-ID packet. See 4.3.4.1 of IEEE Std 1394a-2000 for the encoding of this field.

Pwr_fail

1

rcu

1

R

1

ru

RHB

1

rwu

0

Used by software to control and observe the force_root variable. When TRUE, the force_root variable instructs the PHY to attempt to become the root during the next tree identify process.

Timeout

1

rcu

0

Indicates arbitration state machine timeout (see MAX_ARB_STATE_TIME). A write of one to this bit clears it to 0.

Total_ports

5

r

Vendordependent

Watchdog

1

rw

0

Maximum speed observed during bus initialization from self-ID packets transmitted from or repeated by a Legacy node (i.e., with Legacy PHY or link, or both), or S100, whichever is faster. Encoding is 0002 S100 S200 0012 S400 0102 All other values Reserved (No longer used, see the fields in the port register map.) Selects which of eight possible PHY register pages are accessible through the window at PHY register addresses 10002 through 11112, inclusive. The address of this node determined during self-identification. A value of 63 indicates a malconfigured bus; the link shall not transmit any packets.

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. PHY holds this to 1 when this node is the root.

The number of ports implemented by this PHY. Used by software to enable the watchdog function. When this function is enabled, loop interrupts, power fail interrupts and timeout interrupts are indicated to the link when the PHY-link interface is not operational, and interrupts are indicated to the link when resume operations commence for any port (regardless of the value of Int_enable for the port).

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.6.2 of IEEE Std 1394a-2000 for details. The RHB bit should be zero unless it is necessary to establish a particular node as the root; see 8.4.2.6A of IEEE Std 1394a-2000 for details.


167

IEEE Std 1394b-2002


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. 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 clause 17.4 for details). Table 15-2—PH_EVENT.indication(INTERRUPT) sources Interrupt source

LPS

Watchdog

Action

Port_event

—

—

INTERRUPT

Loop Pwr_fail Timeout

0 0

—a

1

INTERRUPT

—

INTERRUPT

1

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 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 window through which additional pages of PHY registers may be accessed. IEEE Std 1394a-2000 (supplemented by IEEE Std 1394b-2002) 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.1.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.

168


IEEE Std 1394b-2002


Contents Address

0

1 AStat

10002 10012

2 BStat

Negotiated_speed

10102

DC_ connected

10112

Connection _unreliable

3

Int_enable

Max_port_speed

4

5

Child

Connected

Fault LPP

6

7

Receive_ Disabled OK Standby_ Disable_ Beta_mode scrambler _only_port fault Cable_speed

Beta_ mode Port_error

11002

Loop_

11012

disable

In_standby

Hard_ disable

11102 11112

Figure 15-2—PHY register page 0: Port Status page

The meanings of the register fields with the Port Status page are defined by Table 15-3. Table 15-3—PHY register Port Status page fields Size

Type

Power reset value

AStat

2

ru

002

Beta_mode

1

ru

0

Beta_mode_only_port

1

r

BStat

2

ru

Cable_speed

3

r

See Set by implementation-dependent means to the maximum speed at which the description 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 that the port is capable of. The encoding is the same as for Max_port_speed.

Child

1

ru

If equal to 0, the port is a parent; otherwise, the port 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 T1: Child Handshake state during the tree identify process (see 4.4.2.2 in IEEE Std 1394-1995).

Connected

1

ru

0

If equal to 1, the port is connected and (Beta mode only) operating speed negotiation completed.

Connection_unreliable

1

rcu

0

If equal to 1, a Beta-mode speed negotiation has failed or synchronization has failed. A write of one to this field resets the value to 0.

DC_connected

1

ru

0

If equal to 1, the port has detected a dc connection to the peer port (by means of an IEEE 1394a connect detect circuit, if implemented).

Field


Description TPA line state for the port (valid only if a DS port): 002 = Invalid 012 = 1 102 = 0 112 = Z If equal to 1, the port is operating in Beta mode; otherwise, is equal to 0 (i.e., when operating in DS mode or when disconnected). If Connected is one and Beta_mode is zero, indicates the port is operating in DS mode.

See Implementation-dependent constant. Is one if the port is not capable of DSdescription mode operation. 002

TPB line state for the port (valid only if a DS port) (same encoding as AStat).

169

IEEE Std 1394b-2002


Table 15-3

PHY register Port Status page fields (continued)

Size

Type

Power reset value

Disable_scrambler

1

rw

0

Disabled

1

rwu

Fault

1

rcu

0

Set to 1 if an error is detected during a suspend or resume operation. Is cleared on exit from the Suspended state or (suspend error) the peer port ceases normal signaling. A write of one to this bit or receipt of the appropriate remote command packet (see 16.3.3.2) shall clear it to 0. When this bit is zeroed, both resume and suspend errors are cleared.

Hard_disable

1

rw

0

Used by software to prevent the port from maintaining connection status on an ac connection when disabled. Has no effect unless the port is disabled. The values of Connected and Receive_OK are forced to 0.This flag can be used to force renegotiation of the speed of a connection.

Int_Enable

1

rw

0

Used by software to enable port event interrupts. The PHY shall set Port_event to 1 if any of this port’s bias (unless the port is disabled), connected, disabled, fault, standby, or standby_fault bits changes state while Int_Enable is 1.

Local_plug_present (LPP in Figure 15-2)

1

ru

Loop_disable

1

ru

Max_port_speed

3

rw

Field

Description Used by test software to control the transmission scrambler. When 1, the operation of the scrambler during transmission of a packet is inhibited, so that transmitted scrambled data are equal in value to unscrambled data. (Control states and request types continue to be scrambled.) Intended for use as a test mode only, not used during normal operation.

See If equal to 1, the port is disabled. The value of this bit subsequent to a power description reset is implementation-dependent. If a hardware configuration option is provided, a single option may control the power reset value for all ports. See also Hard_disable.

See Indicates that an external implementation-dependent mechanism has deterdescription mined that at least a physical connection exists from the local port (maybe not connected at the far end). If no such mechanism exists, then this flag shall be set permanently to 1. 0

Is set if the port has been placed in the Loop Disabled state as part of the loopfree build process (i.e., the PHYs at both ends of the connection are active, but if the connection itself were activated, then a loop would exist). Is cleared on bus reset and on disconnection.

See The maximum speed at which a port is allowed to operate in Beta mode. The description encoding is 0002 S100 0012

S200

0102

S400

0112

S800

1002

S1600

1012

S3200

1102

Reserved

1112

DS-only port (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-only port. Negotiated_speed

170

3

ru

0002

Indicates the maximum speed negotiated between this PHY port and its immediately connected port; the encoding is as for Max_port_speed. Is set to a speed corresponding to the value of Port_speed (i.e., set on connection when in Beta mode or to value established during the self-identify process when in DS mode).


IEEE Std 1394b-2002


Table 15-3

PHY register Port Status page fields (continued)

Size

Type

Power reset value

Port_error

8

rcu

0

Is incremented when the port receives an INVALID codeword, unless the value is already 255. Cleared when read (including being read by a remote access packet). Intended for use by a single buswide diagnostic program.

Receive_OK

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. (Receive_OK is set to FALSE during the time that only connection tones are detected in Beta mode.)

In_Standby

1

ru

0

Is set to 1 if the port is in Standby (i.e., P7: Standby Initiator, P8: Standby Target, P9: Standby, and P10: Restoring; see 14.5).

Standby_fault

1

rcu

0

Is set to 1 if an error is detected during a standby operation; is cleared on exit from the Standby state. A write of one to this bit or receipt of the appropriate remote command packet (see 16.3.3.2) shall clear it to 0. When this bit is zeroed, standby errors are cleared.

Field

Description

15.1.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

0

1

2

3

4

5

6

7

Compliance_level

10002 10012 10102

Vendor_ID

10112 11002 11012

Product_ID

11102 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.


171

IEEE Std 1394b-2002


Table 15-4—PHY register Vendor Identification page fields Field

Size

Type

Description

Compliance_level

8

r

Indicates the standard to which the PHY implementation complies: 0 = Not specified 1 = IEEE Std 1394a-2000 2 = IEEE Std 1394b-2002 All other values reserved for future standardization

Vendor_ID

24

r

Indicates the company ID or organizationally unique identifier (OUI) of the manufacturer of the PHY. This number is obtained from the IEEE Registration Authority Committee (RAC). 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.2 Integrated link and PHY The register map described in 15.1 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.1. 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.

172


IEEE Std 1394b-2002


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-ID, and self-ID), 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 B PHY


port controller

control

request\ grant

packet data

port status

config control

PHY-link interface

LTP RX flags


arbitration and control state machines




to other ports

TX/RX symbol

Port

Port

Betamode functions


DS-mode functions

Betamode functions

Low-power signaling

CAT-5 UTP -orGOF -orPOF -orB-only electrical -orBilingual electrical -orDS-only electrical

DS-mode functions

Low-power signaling


PMD



PMD

CAT-5 UTP -orGOF -orPOF -orB-only electrical -orBilingual electrical -orDS-only electrical

Figure 16-1—PHY master architecture (data routing, arbitration, and control interfaces in context)


173

IEEE Std 1394b-2002


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 compliant with IEEE Std 1394b-2002 can provide services for either a Legacy link or one that meets the requirements of this specification. For that reason, each service interface may have unique entries for Legacy and Beta higher layers. Table 16-1—Summary of PHY services Service PHY control request

Direction of communication and corresponding layer From the node controller

Purpose of service 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 To or from the link layer response

Determines the types of link

PHY arbitration request

Causes the PHY to request control of the bus

From the link layer

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 to a Beta port

PMD DS port receive signal request To or from the PMD layer or confirmation

Determines the currently received data signal on a DS port

PMD DS port receive speed request To or from the PMD layer or confirmation

Determines the currently received speed signal on a DS port

PMD DS port transmit data request To the PMD layer

Sends a data bit to a DS port

PMD DS port transmit arbitration state request

To the PMD layer

Sends an arbitration state to a DS port

PMD DS port transmit speed request

To the PMD layer

Sends a speed signal to 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 To or from the PMD layer confirmation

Determines the cable power status

PMD cable speed request or confirmation

Determines the speed capabilities of the attached cable

To or from the PMD layer

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 Serial Bus management 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. 174



IEEE Std 1394b-2002

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. 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).


175

IEEE Std 1394b-2002


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: —

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 B link. LEGACY_LINK. The link attached to this PHY is a Legacy 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 Legacy 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: —

176

reqType. This parameter contains the method of arbitration performed by the PHY arbitration request. The method of arbitration shall be one of the following:


IEEE Std 1394b-2002


—

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. 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 (Legacy). The PHY may use accelerations once again. (Used after accelerations are disabled by PH_CYCLE_START_DUE.) PH_ISOCH_REQ (Legacy). 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 (Legacy). The PHY shall arbitrate as required for the current fairness interval. PH_FAIR _REQ (Legacy). 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


177

IEEE Std 1394b-2002


Table 16-2—Cable PHY speed codes (continued) Speed code

Comment

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

aFor

ports operating in Beta mode, data rates lower than the negotiated rate are supported using the data padding technique described in Clause 13.

—

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 a Legacy 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 Legacy 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 (Legacy). 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 (Legacy). 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).10,11 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.

10In 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. 11An 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).

178



—

—

IEEE Std 1394b-2002

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. 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 (Legacy). 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 a Legacy 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 (e.g., broadcast packets, isochronous packets, asynchronous stream packets, and acknowledge packets). 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.


179

IEEE Std 1394b-2002


The link layer shall stop transmitting within a MAX_BUS_OCCUPANCY of receiving a confirmation other than PH_LOST. 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 (Legacy). 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 (Legacy). 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: LEGACY. The following packet was transmitted in Legacy 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 — — — — — —

180

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. 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.



IEEE Std 1394b-2002

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. The PMD is instructed to generate a tone (see 9.6.1). 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 Beta port or DS port (as appropriate). — 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.

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.


181

IEEE Std 1394b-2002


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.

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. 182



IEEE Std 1394b-2002

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. 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.


183

IEEE Std 1394b-2002


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 16.3.1 Packet formats The formats to be used for packets transmitted between ports operating in Beta mode are defined 16.3.1.1 through 16.3.1.8. Packets transmitted in DS mode are defined in IEEE Std 1394a-2000. 16.3.1.1 Legacy and Beta packet formats Two formats are used for packets transmitted between ports operating in Beta mode: Legacy 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-3. Table 16-3—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

16384

S3200

4096

32768

16.3.1.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 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 a Legacy packet terminating in DATA_END or a Legacy 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.

184



IEEE Std 1394b-2002

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.1.7. 16.3.1.3 Legacy format with speed code When a Legacy 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 a Legacy S100 packet originating at the local node when the node does not have a Legacy link or when repeating a Legacy packet with speed code. The Legacy 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 Legacy 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 Legacy 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 specified in IEEE Std 1394a2000. 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: a) b)

c) d)

DATA_PREFIX or DATA_NULL: n = 8:9. GRANT or GRANT_ISOCH: If the grant is being made to the senior port, then n = 8:9, followed by LEGACY_PHASE with n = 4 (for a total of 12:13 symbols in the packet end sequence). Otherwise, n = 12:13 (with no LEGACY_PHASE following). DATA_END: n = 8:9, followed by LEGACY_PHASE with n = 4 (for a total of 12:13 symbols in the packet end sequence). 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.


185

IEEE Std 1394b-2002


16.3.1.4 Legacy format for S100 packets without speed code A Legacy S100 packet originated by a border node with a Legacy 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 a Legacy S100 packet without a speed code, then it shall repeat the packet without a speed code. The packet format for a 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 Legacy 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 Legacy 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.1.3. 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.1.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 Legacy 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.

186



IEEE Std 1394b-2002

16.3.1.6 Minimum packet spacing For all packet formats except Legacy 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 Legacy 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.1.7 Deletable symbols An originating node shall introduce deletable symbols, denoted in the descriptions in 16.3.1.3 through 16.3.1.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. — 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) The count of symbols in the FIFO reaches the must_delete watermark. b) 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.1.8 Packet transmission examples (informative only) The examples of packet formats given 16.3.1.8.1 through 16.3.1.8.5 are for illustration only. The following nomenclature is used: Bn DP DE LP PE P Xy

represents the nth data byte of a packet; represents a DATA_PREFIX symbol; represents a DATA_END symbol; represents a LEGACY_PHASE symbol; represents a packet end symbol; represents a padding symbol (SPEEDc); indicates a sequence of y consecutive X symbols, e.g., PE{24,28} indicates a sequence of either 24 or 28 packet end symbols.


187

IEEE Std 1394b-2002


16.3.1.8.1 Legacy S100 packet originated on S800 port of node with IEEE 1394a link The Legacy format without speed code is used. If the packet ends with DATA_END, then the format is DP16DP16B1 PPPPPPP B2 PPPPPPP B3........Bn PPPPPPP DE18LP8 For interoperability with early Legacy 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 DE18LP8 16.3.1.8.2 Legacy S100 packet originated on S800 port of node with B link The Legacy 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 DE18LP8 16.3.1.8.3 Legacy S200 packet originated on S800 port The Legacy 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 DE18LP8 16.3.1.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.1.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.2 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.2.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 (Legacy 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.2.2 Packet forwarding: DS port to Beta port A packet received on a DS port shall be forwarded on Beta ports as a Legacy packet. 188


IEEE Std 1394b-2002


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.2.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 requirements of IEEE Std 1394a-2000. Additionally, the border node should ensure that a period of idle satisfying the MIN_IDLE_TIME requirement of IEEE Std 1394a-2000 is transmitted between packets on the DS port. When a border node receives a DATA_NULL, it automatically repeats it into any attached Legacy clouds as a DATA_PREFIX. The DATA_PREFIX shall persist until the next Legacy 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 a Legacy cloud until a safe point to assert DATA_END was reached (as afforded by repeating a Legacy packet or as forced by the generation of a Legacy null packet by the last BOSS). 16.3.3 Cable PHY packets 16.3.3.1 Self-ID packets The 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

self-ID packet #1 transmitted first 10 phy_ID

1

n (1)

rsv p11 p12 p13 p14 p15

transmitted last

reserved

logical inverse of first quadlet

self-ID packet #2

transmitted last

Figure 16-2 — Self-ID packet formats Self-ID packets with sequence numbers n between 2 and 7 inclusive are reserved for future standardization. NOTE—IEEE Std 1394-1995 defines self-ID packet formats that permit a maximum of four self-ID packets to be generated by a PHY. Although IEEE Std 1394b-2002 defines only three self-ID packets, link designers should accommodate the reception of up to 252 selfID packets during the self-identify process. Such a link design both supports IEEE Std 1394-1995 and permits future Serial Bus standards to define an additional self-ID packet without adverse impact on contemporary links.


189

IEEE Std 1394b-2002


The fields in Figure 16-2 are defined in Table 16-4. Table 16-4—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 PHY compliant with IEEE Std 1394b-2002 shall always use value 112; however, the values 002, 012, and 102 may be received from Legacy nodes.

c

CONTENDER

If set and the link_active flag is set, this node is a contender for the bus or isochronous resource manager as described in 8.4.2 of IEEE Std 1394-1995.

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. 0102 Node is self-powered and provides a minimum of 30 W to the 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 1012 1102

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 additional 3 W is

1112

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

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). 002 Not present on this PHY.

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 (Optional. If not implemented, this bit shall be zero.)

m

more_packets

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).

n brdg r, rsv, reserved

Extended self-ID packet sequence number. bridge

Reserved for specification by IEEE 1394.1. Reserved for future standardization. Set to zeros.

aThe

link is enabled by the link-on packet described in 4.3.4.2 of IEEE Std 1394a-2000; this packet may also enable application layers. bNo 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.

190


IEEE Std 1394b-2002


16.3.3.2 Remote command packet The reception of the cable PHY packet shown in Figure 16-3 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


Figure 16-3—Remote command packet format The fields in Figure 16-3 are defined in Table 16-5. Table 16-5—Remote command packet fields Field

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:

e_cmnd

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)

Extended command (cmnd = 7): 0: NOP 1: Initiate standby with connected peer port 2: Restore from Standby state 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 of IEEE Std 1394b-2002, 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 1394b-2002 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 Remote confirmation packet Subsequent to the reception of a remote command packet, the PHY transmits the packet shown in Figure 16-4. It reports current status for the port and confirms whether the PHY initiated the requested action.


191

IEEE Std 1394b-2002


transmitted first phy_ID 00

00

type (A16)

e_cmnd

port

00

s f c b d ok

cmnd


Figure 16-4—Remote confirmation packet format The fields in Figure 16-4 are defined in Table 16-6. Table 16-6—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-4)

The current value of the standby_fault bit from PHY register 10012 for the addressed port.

fault (f in Figure 16-4)

The current value of the fault bit from PHY register 10012 for the addressed port.

connected (c in Figure 16-4)

The current value of the connected bit from PHY register 10002 for the addressed port.

bias (b in Figure 16-4)

The current value of the Receive_OK bit from PHY register 10002 for the addressed port.

disabled (d in Figure 16-4)

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 PHY configuration packet The PHY configuration packet defined in IEEE Std 1394a-2000 is extended for use when restoring a connection. The format for a PHY configuration packet is shown in Figure 16-5.

transmitted first 00 root_ID

R T

gap_cnt

0000

0000

MLP L B Q P A N


Figure 16-5—PHY configuration packet format

192


IEEE Std 1394b-2002


The fields in Figure 16-5 are defined in Table 16-7. Table 16-7—PHY configuration packet fields Field

Affects

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.

root_ID

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.

gap_cnt

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 reset_start_actions() in Figure 19-19).

MLP

max_Legacy_path_speed

Zero unless restoring a connection. When restoring a connection, this field indicates the maximum speed on a Legacy connection detected during the most recent selfidentify 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 B cloud.

B

B_bus

Zero unless restoring a connection. When restoring a connection, a value of one indicates that no Legacy nodes exist (including Legacy links) on the bus.

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-6.

transmitted first 3F16 00

00

type (E16)

00

0000

0000

m G

test_value


Figure 16-6—LTP format


193

IEEE Std 1394b-2002


The fields shown in Figure 16-6 are defined in Table 16-8. Table 16-8—LTP fields Field

Comment

type

Extended PHY packet type. (Type E16 indicates LTP.)

mode (m in Figure 16-6)

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.3.6 PHY packet transmission and reception PHY packets shall be transmitted according to the following rules: a) b) c) d) e) f)

All PHY packets shall be sent at S100. The PHY shall use Legacy format for all PHY packets issued during the self-identify process (because the existence of a B bus cannot be determined until the end of self-identification). The PHY may send a restore packet in either Legacy or Beta format. The link shall initiate PHY packets at S100. If the link does not know if the bus is a B 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 B bus.) In a B bus, the PHY shall upgrade all link requests to Beta format, regardless of speed. 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 Legacy or Beta format. 16.3.4 Cable interface timing constants NOTE—This clause defines new values and changes some existing constants from which the configuration and timing of the physical layer in the cable environment may be derived.

Many of the values in Table 16-9 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 16-9, Legacy packet means both Legacy packets on a Beta connection and any packet on a DS connection. A few constants are required only for border nodes. Repeating ports are required to be designed to account for clock frequency and phase differences and still guarantee relevant times from Table 16-9. Table 16-9—Cable interface timing constants Timing constant

ARB_RESPONSE_DELAY

ARB_SPEED_SIGNAL_START

194

Minimum

Maximum

Comment

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 Legacy ports and to the control states at the start and end of packets.

–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. Copyright © 2002 IEEE. All rights reserved.

IEEE Std 1394b-2002


Table 16-9—Cable interface timing constants (continued) Timing constant

BASE_RATE

Minimum

Maximum

98.294 Mbit/s

98.314 Mbit/s

10 µs

11 µs

BOSS_RESTART_TIME

Comment Base bit rate (98.304 Mbit/s ± 100 ppm) Time allowed for a subaction to complete (used only if a node does not use the Legacy gap count)

CM_MIN_IDLE_TIME

1.070 µs

Idle time not in the isochronous interval at proxy_root with a Legacy link.

CONCATENATION_PREFIX_ TIME

0.16 µs

For concatenated Legacy 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 a Legacy packet. (~24/BASE_RATE)

DATA_PREFIX_HOLD

0.04 µs

FORCE_ROOT_TIMEOUT

83.32 µs

83.34 µs

Time to wait in T0: Tree ID Start state (see Figure 16-8) before acknowledging RX_PARENT_NOTIFY. (~8192/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 idle_arb_ state_timeout is false), T0: Tree ID Start state, or a state that exits after an explicit timeout.

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 a Legacy packet before sending a BORDER request. (When the BORDER request is granted, the senior border node shall send a Legacy packet if still required to free the various Legacy 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.

MAX_BETA_TIME

At a transmitting port, the time between the end of speed signalling (when present) and the start of clocked data for a Legacy packet.

MIN_DATA_PREFIX

0.14 µs

Time a port transmitting a Legacy 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 a Legacy port) after transmission of DATA_END for a Legacy 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 Legacy packets. (~34/BASE_RATE)

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)

195

IEEE Std 1394b-2002


Table 16-9—Cable interface timing constants (continued) Timing constant

PHY_DELAY

Minimum

Maximum

Comment

0.06 µs if

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.

PHY_DELAY =

144 ns See comment

RESET_TIME

166.6 µs

166.7 µs 0.16 µs

RESET_WAIT

Reset hold time. (~16384/BASE_RATE) Reset wait delta time. (~16/BASE_RATE)

RESPONSE_TIME

0.04 µs

PHY_DELAY

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.60 µs

1.61 µ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.20 µs

3.22 µ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 Legacy packets.

+ 0.1 µs

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 Clause 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-10. Table 16-10—C code functions and variables Function or variable name

Description

active[port]

Indicates that the port is in the P2: Active state

all_child_ports_identified

Set if all child ports have been identified

arb_OK()

True if OK to request the bus

arb_power_reset()

Power reset initialization routine

arb_reset

True to request an arbitration reset token to be sent

arb_timer

Timer for arbitration state machines

Beta_mode[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.

Beta_port_request

True if a request on a port is to be granted

196


IEEE Std 1394b-2002


Table 16-10—C code functions and variables (continued) Function or variable name

Description

child[port]

True if the port is a child or not active

child_handshake_complete()

True once all active children are in S0: Self-ID Start state

child_ID_complete[port]

True when self-identification is complete on a specified child port

children

Number of child ports

concatenated_packet

True if a concatenated packet is being received

contend_time

Amount of time to wait during root contention

converted_request

True if a request has been converted from a Beta request into a Legacy request to be forwarded on a DS port

data_coming()

True if DATA_PREFIX, SPEED, DATA_NULL, or CYCLE_START token is detected on a port

data_coming_on(port)

True if DATA_PREFIX, SPEED, DATA_NULL, or CYCLE_START token is detected on the specified port

end_of_packet

Set when reception of packet is complete

fly_by_OK

True when fly-by concatenation permitted

force_root

When true, this modifies the PHY’s tree identification behavior and increases the likelihood that the node becomes root (see 4.4.2.2 of IEEE Std 1394-1995). If only one node on a bus has force_root set to TRUE, that node is guaranteed to become the root.

gap_repeat_actions(out_of_ packet)

Repeats gap tokens

grant_self

True if can grant to self

ibr

Set when a long bus reset is needed

idle_receive_port

True if port goes idle after receiving self-ID packets

immediate_request

True if immediate request from link

initiated_reset

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.

isbr_OK

Set when asynchronous or immediate arbitration conditions permit an arbitrated (short) bus reset to be commenced

LEGACY_GRANT()

True if a GRANT or GRANT_ISOCH is being received on the senior port

legacy_junior_request()

True when a Legacy request is on a junior Beta port or a request is on a junior DS port

Legacy_time(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.

lowest_unidentified_child

Lowest numbered active child that has not sent its self-ID packets

max_arb_state_timeout()

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.

own_request

Latch the value of arb_OK() at the time it is evaluated

parent_port

The port number that is connected to the parent node; this variable is meaningless if the node is root.

phy_response

True to indicate that a PHY response packet is to be transmitted

ping_response

Set if self-ID packet(s) needed in response to a ping

port_speed[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

portTspeed_raw(port, speed)

Send speed indication on port (DS ports only)

power_reset

True during power reset; goes false at the end of power reset


197

IEEE Std 1394b-2002


Table 16-10—C code functions and variables (continued) Function or variable name

Description

proxy_root

True if the node is proxy_root

receive_port

The port number that is receiving encoded data (determined by the arbitration states)

requesting_port

Lowest numbered requesting port (child in IEEE Std 1394a-2000)

reset_complete()

True when all ports are idle or in the tree identify process

reset_detected()

BUS_RESET qualified with port status and/or history

reset_duration

Duration to assert bus reset signal

root

True if the node is the root, as determined by the tree identify process

send_null_packet

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

senior_port

Port number of the port pointing towards proxy_root

T0_timeout

True if the tree identify process detects a loop

A B node uses two different types of arbitration depending on whether a particular port is connected using Beta or DS mode. DS-mode arbitration (for this standard or for a Beta node) is almost identical to the arbitration used in IEEE Std 1934-1995 and IEEE Std 1394a-2000, 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. 16.4.2 Beta-mode arbitration 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 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. 16.4.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.

198


IEEE Std 1394b-2002


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-11 and Table 16-12. Table 16-11—Asynchronous requests Request name

Priority level

Comment

BORDER

7 (highest)

CYCLE_START_REQ

6

NEXT_ODD

5 if the last arbitration reset This request is queued from the previous fairness cycle. token was ASYNC_ODD; otherwise, 2

CURRENT

4

NONE_EVEN

3 if the last arbitration reset Nodes that last saw an ASYNC_EVEN send this request when they have no token was ASYNC_ODD; requests. Having a higher priority than the out-of-phase request keeps the otherwise, 1 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 B and Legacy domains.

NEXT_EVEN

2 if the last arbitration reset For queuing requests across the next fairness cycle. token was ASYNC_ODD; otherwise, 5

NONE_ODD

1 (lowest) if the last arbitration reset token was ASYNC_ODD; otherwise, 3

Used for all normal asynchronous requests by nodes that have not used up their fairness budget.

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 B and Legacy domains.

Table 16-12—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.4.1.

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.4.1.

ISOCH_NONE

1 (lowest)

No isochronous transmission requested.

16.4.2.2 Beta-mode grants In Beta-mode operation, two primary types of grant exist: implicit and explicit.


199

IEEE Std 1394b-2002


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. Explicit grants are used when the end of a subaction has been reached. Further, two types of explicit grants exist: grantup 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 a Legacy S100 packet onto a Legacy 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 a Legacy packet format. Initially, when a Beta request (received on a junior port) is denied, DATA_NULL is issued. A Beta-capable node receiving the DATA_NULL shall repeat it from all ports at the individual port operation speeds. If a Legacy 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 B link) and one or more ports operating in DS mode (including any attached IEEE 1394, IEEE 1394a, or IEEE 1394b link). The border PHY serves to synchronize arbitration events and packet transfers across the B and Legacy arbitration domains. 16.4.3.1 Hybrid bus initialization A B PHY shall send its self-ID packet at S100, in Legacy format and timing, and with a speed code. (A PHY with a Legacy link shall send out its self-ID packet at S100, in Legacy 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 Legacy 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 a Legacy 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 originate a self-ID packet without a speed code into the local B cloud (i.e., repeated from a DS port or generated because of a Legacy link). A border node will discover if it is not senior border after it has completed transmission of its self-identify sequence and

200



IEEE Std 1394b-2002

entered the A0: Idle state. A senior border shall 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 B cloud. This process is necessary because a hybrid bus has gap timing considerations that are guaranteed only by a border or Legacy PHY. 16.4.3.2 Border node functions A border PHY by design addresses three important differences between Beta and Legacy arbitration: a)

b)

c)

Synchronization of gap events: Legacy 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. Protection of Legacy quiet windows: Legacy 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 B-only nodes to implement gap based timers. Start of isochronous interval: All PHYs within the B 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 B 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 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 Legacy gap indications with Beta token indications, the following rules apply: a) b) c)

Legacy clouds are prevented from timing gaps during Beta-only transmissions. B-only nodes are prevented from issuing gap tokens in a hybrid network (because they do not know about Legacy gap timings). Border PHYs shall guarantee a gap token is generated when a corresponding gap period has expired within the Legacy cloud and, by extension, in all Legacy clouds connected to the bus.

16.4.3.2.1.1 Preventing timing of gaps during packet transmission Particularly during Beta-only traffic, border nodes need to ensure that Legacy devices do not detect any gaps. For example, during isochronous transmission of Beta-only packets, an occurrence of a subaction gap in the Legacy cloud would cause Legacy nodes to fall into the asynchronous period too quickly and perhaps before their own isochronous transmissions occurred. Therefore, the following rules apply: a) b)

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 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 Legacy packet will arrive, it cannot safely release DATA_PREFIX until such a packet arrives. The Legacy packet is concatenated onto the DATA_PREFIX and is received normally by Legacy devices.


201

IEEE Std 1394b-2002

c)


To prevent Legacy nodes from staying in RX: Receive state for longer than their arbitration state timeout, the BOSS in a B cloud shall issue a Legacy null packet when the end of a subaction has been reached, no more inphase requests are pending, and the last packet sent was not a Legacy 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 a Legacy null packet if still required.

16.4.3.2.1.2 Preventing B-only PHYs from issuing gap tokens Normally, a B-only PHY issues a gap token at the end of a subaction when no eligible in-phase requests remain to be granted. However, a B-only PHY shall not issue a gap token in a hybrid network (because B-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.4.3.2.1.3 Guaranteeing Legacy gaps are matched with tokens 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 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 Legacy 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 Legacy 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 Legacy 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 B-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 IEEE Std 1394a-2000. The IEEE 1394a 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 Legacy 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) b)

202

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), At arb_delay following the issuance of an ASYNC_EVEN/ODD token of the current phase,



c) d)

IEEE Std 1394b-2002

Anytime after the arb_delay following the issuance of an ASYNC_EVEN/ODD token to advance the phase, or Within ARB_RESPONSE_DELAY after receiving a LEGACY_REQUEST12 or ISOCH_CURRENT13 request.

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 B 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 Legacy to Beta A RX_REQUEST from Legacy (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 IEEE Std 1394a-2000 and is expected to be withdrawn if denied. 16.4.3.3.2 Beta to Legacy A senior border always respects the IEEE 1394a quiet times when forwarding eligible Beta requests into the Legacy cloud (see 16.4.3.2.2). All requests are forwarded as TX_REQUESTs. 16.4.3.4 Discussion of root outside the B cloud Of special interest is when the root resides behind a border (i.e., the root is either a Legacy node or in a more senior B cloud). The senior border arbitrates for the bus on behalf of the B cloud. Once arbitration is won, the senior border is BOSS and can introduce a grant into the B 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 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 B cloud, the senior border shall drive DATA_PREFIX into the Legacy domain. If the end of a subaction is not reached, control naturally passes back to the senior border and into the Legacy domain.

12Border nodes forward Legacy requests as high-priority LEGACY_REQUESTs. Given that all Legacy nodes respect the quiet times when generating a LEGACY_REQUEST and given that B nodes repeat Legacy requests within ARB_RESPONSE_DELAY, LEGACY_REQUESTs can be present only outside of quiet times. 13ISOCH_CURRENT requests obey the same timing as IsoReq requests in IEEE Std 1394a-2000 and, therefore, can be present only outside quiet times.


203

IEEE Std 1394b-2002


It is necessary to ensure that the B 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) b) c)

The bus is in asynchronous phase, and The cycle master is outside the Beta cloud, and 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 a Legacy 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. B PHYs enter the isochronous interval only when either the attached link (if any) indicates a cycle start packet has been received (e.g., IEEE 1394a) or a CYCLE_START token is received. B 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., B 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 B clouds (i.e., B 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 B cloud. They are not used on the Serial Bus in junior B 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 B buses as a robust way of recovering from phase synchronization errors. Additionally, ISOCH_CURRENT replaces CYCLE_START tokens in junior B 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. 16.4.4.1 Isochronous interval rules a)

204

A Beta cycle master (i.e., a cycle master with a B link and a B 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. A Legacy 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 B 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)

c)

d)

e)

f) g)

IEEE Std 1394b-2002

CYCLE_START tokens are repeated by B PHYs while in the RX: Receive state. At this time, they are also copied to a local B 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). 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. 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. 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. 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. 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)

i) j)

k)

l)

m)

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. The isochronous interval ends at each PHY and link with arrival and/or generation of an ASYNC_EVEN/ODD. 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. 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 B bus. Similar rules apply for the odd interval. 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 B clouds, ISOCH_EVEN and ISOCH_ODD requests are not used on the cable and expressly forbidden from appearing on the serial bus. 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 Legacy 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


205

IEEE Std 1394b-2002

n)

o)

p)

206


of even or odd. In a B 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, a Legacy null packet is sent (and concludes with an implicit grant to senior, DATA_END). This is done only if the bus is not a B bus and the last packet format was not Legacy. 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., Legacy format on hybrid bus to keep borders unlocked and Beta format on B 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. A PHY shall unconditionally use a received GRANT to exit the A1: Legacy Request state (send TX_GRANT to junior DS port or grant Legacy 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 B 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, a Legacy null packet is sent (and concludes with an implicit grant to senior, DATA_END). This is done only if the bus is not a B bus and the last packet format was not Legacy. 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., Legacy format on hybrid bus to keep borders unlocked and Beta format on B 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 is omitted because the null packet concluded with an implicit grant to senior. 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.) Senior borders convert ISOCH_CURRENT to TX_LEGACY and, upon receiving an RX_GRANT, introduce a GRANT_ISOCH into the junior B cloud. If the ISOCH_CURRENT is no longer present when the RX_GRANT arrives, a null packet or quiet grant is issued.


IEEE Std 1394b-2002


16.4.5 Bus reset state machine Figure 16-7 specifies the bus reset state machine, and following the figure are notes applicable to this state machine.

R0: Reset Start reset_start_actions()

R1: Reset Wait reset_wait_actions()

Power reset arb_power_reset() R0:R1 All:R0a

reset_detected() initiated_reset = FALSE ibr&& !(phy_response || immediate_phy_request)

All:R0b

All:R0c

arb_timer >= reset_duration

R1:T0 arb_timer >= reset_duration + RESET_WAIT R1:R0 reset_duration = RESET_TIME

reset_complete() arb_timer = 0;

to T0: Tree ID Start page 208

initiated_reset = TRUE reset_duration = RESET_TIME max_arb_state_timeout()

initiated_reset = TRUE; reset_duration = RESET_TIME; if (!Timeout) {Timeout = TRUE; PH_EVENT_indication( PH_MAX_ARB_STATE_TIMEOUT, 0, 0)}

from TX: Transmit TX:R0 page 213

Figure 16-7—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 identify, and self-identify 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. 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 the following conditions: a) b)

Serial Bus management makes a PH_CONTROL.request that specifies a long reset or 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 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. 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 idle_arb_state_timeout is set to TRUE. This transition is taken if the PHY stays in the A0: Idle state for MAX_ARB_STATE_TIME after idle_arb_state_timeout 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. on page 215).


207

IEEE Std 1394b-2002


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 isbr_OK 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 reset_duration. 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 IDLEs, waiting for all its active ports to receive IDLE or PARENT_NOTIFY. (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 IDLE or PARENT_NOTIFY. This condition indicates that the connected PHYs are in R1: Reset Wait state or starting the tree identify process (see 16.4.6). 16.4.6 Tree identification state machine Figure 16-8 specifies the tree identification state machine, and following the figure are notes applicable to this state machine.

T0: Tree ID Start

T1: Child Handshake

tree_ID_start_actions()

child_handshake_actions()

from R1: Reset Wait R1:T0 page 207 T0:T1 T0:T0

((!force_root || arb_timer >= FORCE_ROOT_TIMEOUT) && children == NPORT - 1) || children == NPORT !T0_timeout && (arb_timer == config_timeout) T0_timeout = TRUE; if (loop == 0) { loop = 1; PH_EVENT_indication(PH_CONFIG_TIMEOUT, 0, 0)}

T3: Root Contention T2: Parent Handshake

root_contend_actions()

!root && portRarb[parent_port] == ROOT_CONTENTION T2:T3

arb_timer > contend_time && portRarb[parent_port] == PARENT_NOTIFY arb_timer > contend_time && portRarb[parent_port] == IDLE

T3:T1

portTarb(parent_port, PARENT_NOTIFY)

child[parent_port] = TRUE

T3:T2

child_handshake_complete()

T2:S0

root || portRarb[parent_port] == PARENT_HANDSHAKE

T1:T2

to S0: Self-ID Start page 210

Figure 16-8—Tree identification state machine

208



IEEE Std 1394b-2002

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 force_root 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.) 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 this node returns to the T1: Child Handshake state and becomes the root.


209

IEEE Std 1394b-2002


16.4.7 Self-identification state machine Figure 16-9 specifies the self-identification state machine, and following the figure are notes applicable to this state machine.

S0: Self-ID Start

S4: Self-ID Transmit

self_ID_start_actions()

self_ID_transmit_actions()

T2:S0

from T2: Parent Handshake page 208

to A0: Idle page 213

to A0: Idle page 213

from A0: Idle page 213

S1: Self-ID Grant

if (!root && !Beta_mode[parent_port]) port_speed[parent_port] = S100;

S2: Self-ID Receive

root || portRarb[parent_port] == SELF_ID_GRANT

idle_receive_port

A0:S4

all_child_ports_identified

S1:S4

self_ID_receive_actions()

S1:S0

data_coming_on(lowest_unidentified_child)

S1:S2

S0:S2

S4:A0a

!ping_response && (root || data_coming_on(parent_port)) S4:A0b if (!root && !Beta_mode[parent_port]) port_speed[parent_port] = portRspeed[parent_port];

self_ID_grant_actions()

S0:S1

ping_response ping_response = FALSE;

receive_port = lowest_unidentified_child;

!root && data_coming_on(parent_port) receive_port = parent_port;

portRarb[receive_port] == IDLE || portRarb[receive_port] == SELF_ID_GRANT || data_coming_on(receive_port) S2:S0

S3: Send Speed Capabilities

arb_timer >= Legacy_time(SPEED_SIGNAL_LENGTH) portTspeed_raw(receive_port, S100); if (!Beta_mode[receive_port]) port_speed[receive_port] = portRspeed[receive_port];

S3:S0 portRarb[receive_port] == IDENT_DONE

S2:S3 child_ID_complete[receive_port] = TRUE; portTspeed_raw(receive_port, DS_port_speed[receive_port]) arb_timer = 0;

Figure 16-9—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-identification. 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: SelfID Grant state. 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. 210



IEEE Std 1394b-2002

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, gets a SELF_ID_GRANT, 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 IDLE. 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 that 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 negotiated_speed field in the port register map is set for DS-mode operation. State S4: Self-ID Transmit. The S4: Self-ID Transmit state may be entered either as part of the self-identify process or as the result of the receipt of a PHY ping packet. In the latter case, any pending Legacy 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 self-ID 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 an 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 Copyright © 2002 IEEE. All rights reserved.

211

IEEE Std 1394b-2002


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) b)

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. 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 negotiated_speed field in the port register map for the parent port is set.

212


IEEE Std 1394b-2002


16.4.8 Arbitration state machine Figure 16-10 specifies the arbitration state machine, and following the figure are notes applicable to this state machine.

A0: Idle

A2: Grant

idle_actions()

grant_actions()

A0:A2

(proxy_root && (Legacy_junior_request ) && !arb_OK) || Beta_port_request

!active[requesting_port] || portRarb[requesting_port] == REQUEST_CANCEL

to TX:Transmit

send_null_packet = TRUE;

A1: Legacy Request

TX:A2

Legacy_request_actions() !immediate_request && !proxy_root && (Legacy_junior_request || arb_OK) A0:A1

LEGACY_GRANT() && !own_request && (Legacy_junior_request || converted_request)

A1:A2

data_coming_on(requesting_port); receive_port = requesting_port LEGACY_GRANT() && own_request

A2:TX

A2:RX

A1:TX

// Arbitration WON

RX: Receive gap_token(senior_port);

receive_actions() A1:A1

requesting_port != NPORT

RX:A2

data_coming_on(senior_port);

A1:RX

receive_port = senior_port // Arbitration LOST or deferred

TX: Transmit transmit_actions() !concatenated_packet && (fly_by_OK || grant_self) && requesting_port == NPORT

immediate_request || (proxy_root && arb_OK) || grant_self A0:TX

// Arbitration WON

end_of_packet && grant_self

end_of_packet && !grant_self && requesting_port == NPORT

TX:TX TX:A0

// Reinvokes transmit_actions()

A2:TX

isbr_OK

TX:R0

A0:S4

initiated_reset = TRUE reset_duration = SHORT_RESET_TIME

to S4: Self-ID Transmit page 210

ping_response

S4:A0a

RX:TX

// Arbitration WON

from S4: Self-ID Transmit page 210

to R0: Reset Start page 207

end_of_packet && !grant_self && requesting_port != NPORT TX:A2

to A2: Grant

S4:A0b

PH: PHY Response phy_response_actions()

A0:PH

phy_response // Transmit a PHY packet

concatenated_packet PH:A0

// Reinvokes receive_actions()

RX:RX

data_coming()

A0:RX

// Arbitration LOST or deferred !concatenated_packet && !(fly_by_OK || grant_self) && requesting_port == NPORT

RX:A0

Figure 16-10—Border arbitration state machine Copyright © 2002 IEEE. All rights reserved.

213

IEEE Std 1394b-2002


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 ds_stuck flag is set) while Beta ports follow the Beta-mode request repeating rules (see 16.4.2.1). Transition A0:A1. If the PHY is not the proxy_root and a) b) c)

Receives a LEGACY_REQUEST signal from one of its junior ports, or It has a nonimmediate queued request from its own Legacy link and it meets the Legacy timing requirements (arb_OK()), or 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 Legacy timing requirements (arb_OK()),

then it passes the request on to its senior port. The arb_OK() 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 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 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_REQUESTs 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 from one of its junior ports, has no queued requests from its own Legacy link, and is the proxy_root, then it starts the bus grant process. If no LEGACY_REQUEST 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 Legacy 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 ping_response 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, 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. Transition A1:RX. If the PHY sees data_coming_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. 214



IEEE Std 1394b-2002

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 data_coming_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 described below. Outstanding fair and priority requests from a Legacy 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. Concatenated packets are handled within this state when the link sends a PH_REQ_DATA_PREFIX. The arb_enable flag is cleared if this Legacy request was fair. 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 isbr_OK 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. Copyright © 2002 IEEE. All rights reserved.

215


IEEE Std 1394b-2002

17. B PHY- link interface (parallel) This clause specifies the signalling, protocol, and electrical characteristics of the interface between a discrete PHY and a link. The interface is described independently of other operational characteristics of either PHY or link. The PHY-link interface specifies a P2P communications mechanism between a single B link and PHY to transfer IEEE 1394 packet and status information between these two devices. Implementation of the PHY-link interface at speeds up to S800 may be achieved using an 8 bit parallel interface that is closely modeled on the PHY-link interface defined in IEEE Std 1394a-2000. The PHY-link interface provides mechanisms to support communication between a discrete PHY and link at speeds of S100, S200, S400, and S800. For all of these speeds, the width of the data path is 8 bits. Transfer speeds lower than the maximum are accommodated by data padding and repetition. This specification does not preclude implementation of PHYs that are capable of supporting links compliant with IEEE Std 1394b-2002 and with IEEE Std 1394a-2000. When attached to a link that is compliant with IEEE Std 1394a-2000, the PHY shall follow all the link specifications of that standard. When attached to a link compliant with IEEE Std 1394b2002, the PHY shall follow the link specification contained in this clause.

17.1 B PHY-link interface characteristics The following are the characteristics of the B PHY-link interface: a) b) c) d) e) f)

Provides for bidirectional packet data transfer at speeds of S100, S200, S400, and S800; Provides a mechanism for status information transfer from the PHY to the link; Provides a mechanism for the link to access a register space within the PHY; Provides a means for the link to request services from the PHY; Provides a means for the PHY to interrupt the link during an operation; and Supports an optional isolation interface to allow separate PHY and link power supply domains.


217

IEEE Std 1394b-2002


17.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-1.

B PHY

B link D[0:7]

8

PInt LReq

PInt LReq Ctl[0:1] PClk LClk

D[0:7]

2

Ctl[0:1] PClk LClk

LinkOn LPS

LinkOn LPS

Direct

Direct

Beta_Mode_link NOTE—This diagram indicates the logical signalling required between the PHY and link and does not imply a dc connection between the two devices.

Figure 17-1—PHY-link interface logical signalling 17.2.1 Interface signal descriptions The signals of the B PHY-link interface are divided into mandatory and optional signals for the PHY and link. 17.2.1.1 PHY signals The mandatory signals for a PHY are D[0:7], PInt, LReq, Ctl[0:1], PClk, LClk, LinkOn, and LPS. The Direct and Beta_Mode_link signals are optional for a PHY. 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.2.1.2 Link signals The mandatory signals for a link are D[0:7], PInt, LReq, Ctl[0:1], PClk, and LClk. The LinkOn, LPS, and Direct signals are optional for a link. 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.

218


IEEE Std 1394b-2002


Table 17-1 summarizes the PHY-link interface signals. Table 17-1— PHY-link interface signal descriptions Signal name

Direction

Description

D[0:7]

Bidirectional

PHY-link interface data bus. Mandatory 8 bit data bus for a B PHY and link.

PInt

PHY drives

PHY interrupt. Mandatory PHY-to-link interrupt and status indication.

LReq

Link drives

Link request. Mandatory link-to-PHY request.

Ctl[0:1]

Bidirectional

PHY-link control bus. Mandatory 2 bit control bus for a B PHY or link.

PClk

PHY drives

PHY sourced clock. Mandatory PHY-to-link interface clock.

LClk

Link drives

Link sourced clock. Mandatory link-to-PHY interface clock.

LinkOn

PHY drives

Link on. Mandatory for the PHY, optional for the link.

LPS

Link drives

LPS. Mandatory for the PHY, optional for the consistent link.

Direct

Externally driven

Direct. Optional external indication of the interface mode between PHY and link.

Beta_Mode_link

Externally driven

PHY-link interface mode. Optional external indication of the PHY-link interface mode.

17.2.1.3 Detailed signal descriptions Detailed descriptions of the interface signals are as follows: a)

b)

c)

d)

e)

f) g) h)

i)

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. 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. 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. 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. PClk. The PHY clock signal is an output from the PHY. When driven, this signal shall be a nominal 98.304 MHz clock with a nominal 50% duty cycle. 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. 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. 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. 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 PHY-link interface as specified in IEEE Std 1394b-2002. When this signal is inactive, it indicates that the link is not powered or that no link is present. 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.


219

IEEE Std 1394b-2002

j)


Beta_Mode_link. If the PHY-link mode indication is not provided or if it is provided and asserted, the PHY-link interface complies with IEEE Std 1394b-2002. When the PHY-link mode indication is provided but deasserted, the PHY-link interface complies with the PHY-link interface as specified in IEEE Std 1394a-2000.

17.2.1.4 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 highimpedance state so long as the input signal remains constant. Figure 17-2 illustrates this signal transformation.

Input 0

1

1

0

0

0

1

0

0

0

1

Z

0

Z

Z

1

0

Z

Output

Figure 17-2—Digital differentiator signal transformation

17.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.1 LPS signal characteristics The characteristics of LPS are specified by Figure 17-3 and Table 17-2.

LPS

TLPSH

TLPSL

Figure 17-3—LPS waveform when differentiated

220


IEEE Std 1394b-2002


Table 17-2—LPS timing parameters Description

Parameter

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

%

TLPS_RESET

Time for PHY to recognize LPS logically deasserted and reset the interface

1.2

2.75

µs

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

aThis

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, to reset, but not disable, the interface, the link shall ensure that LPS is logically deasserted for less than TLPS_DISABLE.

17.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.8.2) in progress and then reset the PHY-link interface. The signal levels shown in Figure 17-4 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.

Ctl D, PInt, LReq LPS (non-pulsed) LPS (pulsed) PClk/ LClk TLPS_RESET

TRESTORE

Figure 17-4—PHY-link interface reset 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 specification, the PHY’s behavior (as observable from 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.


221

IEEE Std 1394b-2002


This specification describes 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 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 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.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.2; it now disables the interface by stopping PClk. The signal levels shown in Figure 17-5 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 high-impedance 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-5—PHY-link interface disable

17.3.4 Restoration and initialization The handshake described in 17.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-3. The reference point is the first rising edge of PClk after LPS is asserted.

222


IEEE Std 1394b-2002


Table 17-3—Initialization of the PHY-link interface Device

Interface mode Differentiated

Undifferentiated

PHY

For one and only one of the first six cycles of PClk Drive Ctl[0:1], D[0:7], and PInt to zero for the first seven after the reference point, drive Ctl[0:1], D[0:7], and cycles of PClk after the reference point. PInt to zero. Otherwise, for these cycles and the seventh, place signals in a high-impedance state.

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 highimpedance 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 high-impedance 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.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. Upon the ninth PClk cycle, 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.4.1. 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.4.1 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: a) b) c) d)

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. 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. The PHY shall notify the link of its node ID by sending an unsolicited PHY register 0 PHY Status Transfer. 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 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. Copyright © 2002 IEEE. All rights reserved.

223

IEEE Std 1394b-2002


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.

17.4 Link-on and interrupt indications 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). 17.4.1 LinkOn signal characteristics The characteristics of the LinkOn signal, specified by Figure 17-6 and Table 17-4, 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-6—LinkOn waveform Table 17-4—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

When necessary to communicate a PH_EVENT.indication of PH_LINK_ON or one of the PHY interrupt conditions (see Table 17-20), 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.

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: — —

224

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).


IEEE Std 1394b-2002


17.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-5. Table 17-5—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) b)

The link has received a cycle start packet along with an indication of the isochronous phase of the link. 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 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.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 Legacy 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.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.


225

IEEE Std 1394b-2002


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.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.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. 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-19). 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.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.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.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.

226



IEEE Std 1394b-2002

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 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.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.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.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.5.3.


227

IEEE Std 1394b-2002


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 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.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.4.1. 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.8.1.1. 17.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.5.3. 17.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.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 clause 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.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.5.3. NOTE—It is preferred, but not required, that the cycle start due notification be provided by all links that are compliant with IEEE Std 1394b-2002.

228


IEEE Std 1394b-2002


17.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-7) 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-7—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-6. 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-6—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

0010

PH_NEXT_EVEN

Used by the link to request transmission of an asynchronous packet in the even fairness interval phase.


0011

PH_NEXT_ODD

Used by the link to request transmission of an asynchronous packet in the odd fairness interval phase.


0100

PH_CURRENT

Used by the link to request transmission of an asynchronous packet in the current fairness interval.


0101

Reserved


None


229

IEEE Std 1394b-2002


Table 17-6—RT[0:3] field encoding (continued) RT[0:3] value

Name

Meaning

Required fields

0110

PH_ISOCH_REQ_EVEN

Used by the link to request transmission of an isochronous packet in the even isochronous period.


0111

PH_ISOCH_REQ_ODD

Used by the link to request transmission of an isochronous packet in the odd isochronous period.


1000

PH_CYC_START_REQ

Used by the link to request transmission of a cycle start packet. Request Format, Request Speed

1001

Reserved


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 inter- Register Address, nal registers. Register Data

1100

PH_ISOCH_PHASE_EVEN

None 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.

1101

PH_ISOCH_PHASE_ODD

None 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

1110

PH_CYCLE_START_DUE

Used by the link (other than the cycle master) to indicate to the None PHY that a cycle start notification is now due to be received.

1111

Reserved


None

If the link has prior knowledge that the entire packet transmission path from source to destination is operating in B 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-7). NOTE—The PHY may have determined for itself that the transmission path involves only B 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 Legacy nodes. Packets that are sent at speeds faster than the fastest Legacy node may use the Beta packet format regardless of the format indicated in the request from the link.

Table 17-7—Request format values RFMT value

Meaning

0

The link is not explicitly requesting that the PHY use either Beta or Legacy packet format for packet transmission.

1

The link is explicitly requesting that the PHY use the Beta packet format for packet transmission.

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-8). 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.7.

230


IEEE Std 1394b-2002


Table 17-8—Speed encodings RS[0:3] value

Meaning

RS[0:3] value

Meaning

0000

S100

0100

S400

0001

Reserved

0101

Reserved

0010

S200

0110

S800

0011

Reserved

0111–1111

Reserved

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.

17.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 of S100, S200, S400, and S800. 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) b)

Packet transmit (data transferred from link to PHY) Packet receive (data transferred from PHY to link)

Status information transfers from PHY to link are accomplished using the PInt signal. 17.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.6.2 Packet reception The PHY uses the D[0:7] data interface to send the following information to the link: a) b) c) d) e)

Data on indication Packet speed information Packet data Packet grant and interface handover information Bus status information


231

IEEE Std 1394b-2002


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-9 when the PHY is in control of the PHY-link interface. Table 17-9—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

1

1

GRANT

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. The PHY is transferring DATA_ON, packet speed or packet data to the link. The PHY is transferring grant information to the link and indicating that it is handing control of the interface over to the link.

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.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.6.2.2 Packet reception timing Packet reception timing is illustrated in Figure 17-8.

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.7 for a data format description.

Figure 17-8—PHY-link packet receive operation

232


IEEE Std 1394b-2002


17.6.2.3 Packet reception description The steps for packet reception are as follows: a)

b) c) d)

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 may indicate DATA_ON for an unlimited period. 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. 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. 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.

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-8 is encoded as indicated in Table 17-10. Table 17-10—Receive packet SPD interval encoding D[0:7] during SPD cycle

Receive packet speed and format

0000 0000

S100 Legacy

0000 0001

S100 Beta

0000 0100

S200 Legacy

0000 0101

S200 Beta

0000 1000

S400 Legacy

0000 1001

S400 Beta

0000 1101

S800 Beta

1111 1111

DATA_ON

Other values

Reserved

NOTE — These encodings supersede the encodings specified in IEEE Std 1394a-2000.

17.6.2.4 Interpacket spacing for received packets Between any two received primary packets or PHY packets shall be at least four PClk signals of nonpacket data time on the PHY-link interface. 17.6.3 Packet transmission The link uses the D[0:7] data interface to send the following information to the PHY: a) b) c) d)

Interface Hold indication Packet data Link requests Interface handover information


233

IEEE Std 1394b-2002


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-11 when the link is in control of the PHY-link interface. Table 17-11—Ctl[0:1] state encoding when the link controls the PHY-link interface Ctl[0]

Ctl[1]

Interface phase

Phase description

0

0

IDLE

The link has completed packet transmission and is handing the interface back to the PHY.

0

1

TRANSMIT

1

0

Reserved

1

1

HOLD/ MORE_INFO

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.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.

234


IEEE Std 1394b-2002


17.6.3.2 PHY-link packet transmit timing The packet transmission timing is described in Figure 17-9.

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

AI 00 ZZ ..... ZZ ZZ ZZ ZZ

DATA TRANSFER

INTERFACE RELEASE

OPTIONAL ADDITIONAL INFORMATION

NOTE—B0–BN represent the information bytes transferred from the link to the PHY. See 17.7 for a data format description.

Figure 17-9—PHY-link packet transmit operation, including optional HOLD cycles

17.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-13). 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.


235

IEEE Std 1394b-2002

b)

c)

d) e)

f)

g)


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]. 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. The link asserts TRANSMIT on Ctl[0:1] when it is transmitting packet data on the D[0:7] lines. 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-15 through Table 17-18 for values) Ctl[0:1] while driving the relevant packet information on D[0:7]. 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. 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.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. Table 17-12—Format type during GRANT cycle D[0] value during GRANT cycle

Format

0

Unspecified

1

Beta

Table 17-13—Grant Type values during GRANT cycle D[1:3] value during GRANT cycle

236

Grant type

000

Reserved

001

Reserved

010

Isochronous

011

Reserved

100

Reserved

101

Asynchronous

110

Cycle Start

111

Immediate


IEEE Std 1394b-2002


Table 17-14—Speed types during GRANT cycle D[5:6] value during GRANT cycle

Speed type

00

S100

01

S200

10

S400

11

S800

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.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.6.3.5.1 and 17.6.3.5.2. 17.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-15). Table 17-15—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.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-16 through Table 17-18. Table 17-16—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

237

IEEE Std 1394b-2002


Table 17-17—Link request speed during MORE_INFO cycle D[5:6] value during MORE_INFO cycle

Request speed

00

S100

01

S200

10

S400

11

S800

Table 17-18—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 Legacy packet format for packet transmission.

1

The link is explicitly requesting that the PHY use the Beta packet format for packet transmission.

17.7 Format of received and transmitted data This specification allows the PHY and link to transfer data to each other at S100, S200, S400, and S800 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. Data transfers between the PHY and link are accomplished by appropriate padding of the lower rate data as described in 17.7.1 through 17.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. 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. NOTE—In Figure 17-10 through Figure 17-13, the values shown on D[0:7] are the values that would be seen on an undifferentiated interface. For a differentiated interface, the transmitting device drives D[0:7] for only the first cycle of a repeated series, and D[0:7] are not driven for the remainder of the byte time.

17.7.1 S100 data For packet data transmitted or received at S100, the data delivery format in Figure 17-10 is used to transfer the data to or from the PHY or link.

(P)/(L)CLK Ctl[0:1] D[0:7]

10/01 BYTE[N-1]

10/01

10/01

BYTE[N]

BYTE[N+1]

Figure 17-10—S100 data transferred over 100 MHz; single-edge clocking 238


IEEE Std 1394b-2002



(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-11—S200 data transferred over 100 MHz; single-edge clocking


(P)/(L)CLK 10/01

Ctl[0:1] D[0:7]

10/01

BYTE[N-2]

BYTE[N-1]

BYTE[N]

10/01

BYTE[N+1]

BYTE[N+2]

BYTE[N+3]



(P)/(L)CLK Ctl[0:1] D[0:7]

10/01 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]



239

IEEE Std 1394b-2002


17.8 Status transfers and notifications from the PHY The PHY issues status transfers and notifications to the link to a) b) c) d)

Notify the link of Serial Bus packet-related events relevant to its operation Notify the link of PHY events relevant to its operation Return PHY register read data requested by the link 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 packetrelated 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 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.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) b) c) d)

Bus Reset indication Arbitration Reset Gap indication (both even and odd) Subaction Gap indication Cycle Start indication (both even and odd)

The format for a Bus Status Transfer is specified in 17.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-19). 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.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 PHYlink interface is operational. When a Bus Reset indication is sent, the following actions occur: a) b) c) d)

The PHY shall cancel all packet transfer requests, The isochronous and asynchronous phases are set to even, The PHY shall forward self-ID packets to the link as they are received or transmitted on the Serial Bus, and 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.4.1 when the PHY-link interface does become operational.

240


IEEE Std 1394b-2002


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. 17.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-14 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-14—Bus Status Transfer format During a Bus Status Transfer, D[0:7] is encoded in accordance with Table 17-19. 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-19—Bit encoding for Bus Status Transfers Status bit D[0]

Meaning 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.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) b) c)

PHY Interrupt indication PHY Register Read indications (both solicited and unsolicited) 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.8.2.4.


241

IEEE Std 1394b-2002


17.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.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 is solicited if the link has explicitly asked for the PHY to return register contents via a PHY register read. The data is 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.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.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-15).

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-15—PHY Status Transfer format

242


IEEE Std 1394b-2002


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. Table 17-20 ST[0:2] value

PHY Status Transfer encoding

Name

Additional fields

Meaning

000

NOP

No Status indication

001

PHY_INTERRUPT

The PHY requires the link to read its internal register set to determine the None cause of the interrupt. As in IEEE Std 1394a-2000, 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

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.

011

PHY_REGISTER_UNSOL

The PHY is returning the contents of one of its internal registers without PHY Address, having been requested by the link to do so. PHY Data

100

PH_RESTORE_NO_RESET

The PHY-link interface has been initialized, and the link is informed that None there is no unreported Serial Bus reset to now report or that a PHY port has started the restore process.

101

PH_RESTORE_RESET

The PHY-link interface has been initialized, and the link is informed that None 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.

110

Not available

This code is not available. A PHY is permitted to send this code, but the None link shall ignore any status transfer using this code.

111

Reserved

Reserved

None

PHY Address, PHY Data

Reserved

17.9 Delays affecting interoperability of PHYs and links This specification 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-21. Table 17-21—PHY-link critical delays Name BUS_TO_LINK_DELAY

Mini- Maximum mum 4

DATA_PREFIX_TO_GRANT


Units

Description

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.

243

IEEE Std 1394b-2002


Table 17-21—PHY-link critical delays Name

Mini- Maximum mum

Units

Description

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.10 Legacy link support The B PHY-link interface is a superset of the Legacy signals. This specification does not preclude building a PHY that supports both Legacy and B styles of link. B PHYs are not required to support Legacy links. If the optional Beta_Mode input to the PHY is connected to logical 0, the B PHY shall operate its PHY-link interface in accordance with the PHY-link interface specification detailed in the Legacy specification. In this mode, the PHY sources an interface clock of 49.152 MHz in accordance with the Legacy specifications. In this case, the B PHY-link interface signals are used as shown in Table 17-22. Table 17-22—Mapping of B PHY-link signals to Legacy signals B PHY-link interface pin

Legacy 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 Legacy; PHY holds to logical 0

PInt

Not used by Legacy; PHY drives logical 0

Beta_Mode

System drives logical 0

In this mode of operation, link requests, link and PHY packet transfers, and PHY status transfers take place in the manner defined by the Legacy specifications. No B specific features, such as request for next cycle, are available. The Legacy LReq cancellation rules also take effect. 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. A PHY that is compliant with this specification may also be designed to operate with Legacy links. It is recommended that PHYs that offer this capability be compliant with the PHY-link interface definition contained in IEEE Std 1394a2000.

244


IEEE Std 1394b-2002


When operating in Legacy 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). 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.11 Electrical characteristics This subclause specifies the signal and timing characteristics of the interface between a discrete PHY and link. 17.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 IEEE Std 1394a-2000 may be connected to a PHY that is compliant with IEEE Std 1394b2002. In such cases, the signaling shall conform to IEEE Std 1394a-2000. DC parametric attributes of the PHY-link interface signals are specified by Table 17-23. Devices not tolerant of mismatched input levels, but that otherwise meet the requirements in the table, are compliant with IEEE Std 1394b-2002. VDD is obtained from the vendor’s specifications. Table 17-23—DC specifications for PHY-link interface Name

Description

VOH

Output high voltage (undifferentiated)

VOHD

Output high voltage (differentiated)

VOL

Output low voltage (undifferentiated)

VOLD

Output low voltage (differentiated)

VIH

Input high voltage (undifferentiated)

VIL

Input low voltage (undifferentiated)

Conditions

Minimum

Maximum

Units

IOH = –4 mA

2.8

V

IOH = –9 mA at VDD = 3 V IOH = –11 mA at VDD = 4.5 V

VDD – 0.4

V

IOL = 4 mA

0.4

V

IOL = 9 mA at VDD = 3 V

0.4

V

VDDa + 10%

V

0.7

V

VLREF + 1b

V

2.6

VLIT+

Input rising threshold (LinkOn and LPS)

VLIT-

Input falling threshold (LinkOn and LPS)

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

VLREF + 0.2b

VDD/2 ± 1% 0.5

V

1.6

V

5.0

pF

aRefers to driving device s power supply. bThe 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. dWhen designing a device capable of both undifferentiated and differentiated operation, V and V effectively constrain these IH IL VIT+ and VIT—values to VREF + 0.8 V and VREF — 0.8 V, respectively.


245

IEEE Std 1394b-2002


eFor some applications, a device can be compliant with these dc specifications even if a different V REF is chosen. fFor a particular application, a single value exists for each device s nominal bias point, V LREF, 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.

17.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 outputs 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-16.

90%

90%

10%

10% tR

tF Figure 17-16—Signal levels for rise and fall times

Other signal characteristics of the PHY-link interface are specified in Table 17-24. 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. Table 17-24—AC timing parameters Name

246

Description

Minimum

Maximum

Units

PClk or LClk frequency

98.304 ± 100 ppm

DCP

PClk duty cycle

35

65

MHz %

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

jP + 0.50

ns


IEEE Std 1394b-2002


Table 17-24—AC timing parameters (continued) Name

Description

Minimum

Maximum

Units

tpdPL Signal propagation delay from PHY to link

—

1.5

ns

tpdLP Signal propagation delay from link to PHY

—

1.5

ns

aThe LClk duty cycle is determined bj denotes the PClk pk-pk jitter. P

by the actual duty cycle of PClk.

Figure 17-17 and Figure 17-18 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-25 and shall not depend upon values for tsu and thld greater than the minimums specified.

Source Clock

tpd1

tpd2

tpd3

Output LR

Figure 17-17—Transfer waveform at the source

Source Clock

tsu

thld

Input Figure 17-18—Transfer waveform at the destination

The values for the timing parameters illustrated in Figure 17-17 and Figure 17-18 are specified in Table 17-25. Table 17-25—AC timing parameters Description

Name

Minimum

Maximum

Units

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


247

IEEE Std 1394b-2002


17.11.3 Isolation barrier (informative) 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. When capacitive isolation is used between the PHY and the link, the grounds of both devices shall be coupled as shown in Figure 17-19. The details of this ground coupling are omitted from Figure 17-20 through Figure 17-24. 0.1µF

1M Ω

several places 0.001µF PHY ground

link ground

Capacitor and resistor values are nominal

Figure 17-19—Example of ground coupling circuit The isolation design in the circuits in Figure 17-20 through Figure 17-24 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 radio frequency interference. In addition, inputs should be specified to be tolerant of signals that exceed the power supply rail. 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. The sample circuits in Figure 17-20 through Figure 17-24 illustrate different requirements of the various signals of the PHY-link interface. power

0.001µF

5KΩ

0.001µF

Device B

5KΩ

power

300Ω

5KΩ

5KΩ

Device A

to Device A or Device B ground

Figure 17-20—Example of capacitive isolation barrier circuit for Ctl[0:1] and D[0:n] 248


IEEE Std 1394b-2002


PHY 0.01µ F

5KΩ

power Optional current limiting resistor

link

1.6KΩ

100Ω

Figure 17-21—Example of capacitive isolation barrier circuit for LinkOn

5KΩ

power

link

Optional current limiting resistor

PHY

0.033µF

1.6KΩ

100Ω

Figure 17-22—Example of capacitive isolation barrier circuit for LPS

NOTE—In Figure 17-21 and Figure 17-22, 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.


249

IEEE Std 1394b-2002


0.001µF

5KΩ

300Ω

0.001µF

5KΩ

power

5KΩ

5KΩ

power

Figure 17-23—Example of capacitive isolation barrier circuit for LReq and PInt

5KΩ

0.001µF

5KΩ

power

power

Optional current limiting resistor

5KΩ

5KΩ

100 Ω

Figure 17-24—Example of capacitive isolation barrier circuit for LClk and PClk

17.11.4 Alternative isolation barrier (informative) This subclause describes an alternative method of isolation for the PHY-link interface signals. For this method, a busholder circuit is added to some of the input lines. The bus holder circuit (see Figure 17-25 and Figure 17-26) 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 250


IEEE Std 1394b-2002


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-25—Example of bus holder isolation circuit for LReq, PInt, PClk, and LClk 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.

Device A

Device B

10KΩ

10KΩ

Capacitor and resistor values are illustrative.

0.001µF

Figure 17-26—Example of bus holder isolation circuit for Ctl[0:1] and D[0:n] 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-21 and Figure 17-22, 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. Copyright © 2002 IEEE. All rights reserved.

251

IEEE Std 1394b-2002


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.

252


IEEE Std 1394b-2002


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 (i.e., S100, S200, S400, S800, and S1600). 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 either across a planar 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.

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, Betaonly, 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. Copyright © 2002 IEEE. All rights reserved.

253

IEEE Std 1394b-2002


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 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 PIL-capable 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 vendordependent 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 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. 254



IEEE Std 1394b-2002

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 useraccessible 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. 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.


255

IEEE Std 1394b-2002


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) b) c) d) e)

CHILD_NOTIFY IDENT_DONE PARENT_NOTIFY DISABLE_NOTIFY 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 IEEE Std 1394b-2002 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) b) c)

The packet may be started anytime an arbitration request type is allowed to be sent on the serial interface; The packet can be interrupted at any point if a received packet needs to be communicated; and The packet can be easily distinguished from any other Serial Bus communication.

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

256


IEEE Std 1394b-2002


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.

Table 18-3—Interrupt encoding Interrupt bit


Interrupt meaning

i0

PHY_INTERRUPT

i1

Reserved

i2

Reserved

i3

Reserved

257

IEEE Std 1394b-2002


19. C code This clause contains the C code specifying the actions of the port state machines and the arbitration state machine.

19.1 Common declarations and functions Figure 19-1 through Figure 19-3 list the C code declarations and common functions used in the detailed operational descriptions. Figure 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; long eventVar; int dataBit;

// event type, allows 32 events

void signal(int event); eventVar wait_event(eventVar event_mask); void wait_time(float time);

// Sets event status to the value specified // Await the indicated event(s), return events signaled

// 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

Figure 19-2—Data structures and enumerated types // data_structures.h #define BASE_RATE 98.304

// units of Mbit/s

// constants used in the main arbitration state machine enum Legacy_wait_times { // set to values corresponding to the tables in text, in Legacy_time 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 wait_times { // 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, FORCE_ROOT_TIMEOUT, CONFIG_TIMEOUT, CM_MIN_IDLE_TIME, MAX_ARB_STATE_TIME}; enum Beta_times {BOSS_RESTART_TIME}; // constant used in background processing enum Background_Beta_times {MAX_BETA_TIME}; // constants used in node-level connection management - times are given in Table 11-3 enum node_wait_times {BIAS_FILTER_TIME}; enum Beta_node_wait_times {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}; Copyright © 2002 IEEE. All rights reserved.

259

IEEE Std 1394b-2002


Figure 19-2—Data structures and enumerated types (continued) #define #define #define #define #define

TONE_GAP 8 TONE_INTERVAL 16 NUM_OF_TRIES 4 RESUME_CHECKS 65 SYNCHRONIZATION_LENGTH 16384

// 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 “immediate_request” replaces use of IMMED_REQ NO_REQ, ISOCH_REQ, PRIORITY_REQ, FAIR_REQ} breq_type; 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} PHY_state_type; typedef enum {P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12} port_state_type; 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, 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} RX_arbstate; 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} TX_arbstate; typedef struct {RX_arbstate RX_arb; portData data;} RX_signal; typedef enum {LTP_TEST = 0, ATTACH_IN_PROGRESS = 1} LTP_mode_type; #define COLLISION_LIMIT 7 typedef enum {B_Link, Legacy_Link} linkType; typedef enum {grant_senior, grant_link, grant_null, grant_junior, boss_management_actions} boss_eop_status; // 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,

260


IEEE Std 1394b-2002


Figure 19-2—Data structures and enumerated types (continued) // DATA_BYTE is only used in the arb state machine DATA_BYTE = 29 } 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; 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;

typedef struct { asyncReqType async; isochReqType isoch; } BetaRequestCode; typedef struct { // This type holds any port symbol portTag tag; // The type of symbol ArbState arb; // valid if tag is CTRL, CONFIG_REQUEST, LEGACY_ARB or ARB_STATE union { // This part holds symbol data byte data; // valid if tag is DATA or LEGACY_ARB RX_arbstate rx_dsarb; // valid if tag is DS_RAW_ARB BetaRequestCode req; // valid if tag is ARB_REQUEST (only used internally in the port) }; speedCode speed; // the effective speed at which the current info is to be sent pktType pkt; // valid if arb is SPEED } portSymbol; typedef struct { union { byte dataBytes[8]; struct { union { quadlet dataQuadlet; struct { // First self_ID packet quadlet phy_pktType:2; quadlet phy_ID:6; // Physical_ID quadlet :1; // Always 0 for first self_ID packet quadlet L:1; // Link active quadlet gap_cnt:6; // Gap count quadlet sp:2; // Speed code quadlet :2; quadlet c:1; // Isochronous resource manager contender quadlet pwr:3; // Power class quadlet p0:2; // Port 0 connection status quadlet p1:2; // Port 1 connection status quadlet p2:2; // Port 2 connection status quadlet i:1; // Initiated reset quadlet m:1; // More self_ID packets... } ; //self_ID_first struct { // Subsequent self_ID packets quadlet :8; quadlet ext:1; // Nonzero for second and subsequent self_ID packets quadlet n:3; // Sequence number quadlet :2; 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 --- --- --Copyright © 2002 IEEE. All rights reserved.

261

IEEE Std 1394b-2002


Figure 19-2—Data structures and enumerated types (continued) 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, gap_cnt field is valid quadlet gap_count:6; // Gap count union { struct { // for a restore packet quadlet:8; quadlet notify_Legacy_speed:2; quadlet notify_B_node_root:1; quadlet notify_B_bus:1; quadlet Q; quadlet P; quadlet notify_odd_async_phase:1; quadlet notify_reset: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 ext_type:4; // Extended type union { struct { union { quadlet page:3; // Page_select quadlet e_cmnd:3; // Extended command }; quadlet port_num: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 standby_fault: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; }; }; struct { // fields for LTP quadlet :10; quadlet mode:1; // LTP mode quadlet G:1; // Generation number quadlet test_value:6; // LTP comparison value }; }; } ; // ext_phy; }; quadlet checkQuadlet;

262


IEEE Std 1394b-2002


Figure 19-2—Data structures and enumerated types (continued) }; }; } PHY_PKT; // implementation dependent constants #define CONTENDER 1 #define POWER_CLASS 0b000

// IMPLEMENTATION DEPENDENT // IMPLEMENTATION DEPENDENT

#define NPORT 4

// number of ports - IMPLEMENTATION DEPENDENT

#define PHY_SPEED S800 #define DS_PHY_SPEED S400

// PHY speed - IMPLEMENTATION DEPENDENT // PHY speed for DS ports - IMPLEMENTATION DEPENDENT

const speedCode DS_port_speed[NPORT];

// Speed of each DS capable port - IMPLEMENTATION DEPENDENT

Figure 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,

// // // // // // // // //

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 bport_on is TRUE, unset during suspend etc PMD uses dsport for data, arb states and speed signals remains set during suspend etc note, this does not affect use of bias or dc connect

PMD_UNSELECT_PORT } PMD_control_request_type; PMD_CONTROL_request(PMD_control_request_type 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. #ifdef unsubscripted eventVar PMD_STATUS_request(); #else eventVar PMD_STATUS_request(int i); #endif


// returns bit map of the above

263

IEEE Std 1394b-2002


Figure 19-3—PHY services (continued) // Beta PMD typedef struct { dataBit data; } PMD_data_ind_service; // for data from PMD PMD_data_ind_service 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 max_port_speed. This value is also // maintained as a read-only register in the port register map. // DS PMD RX_signal 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(TX_arbstate 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 IEEE 1394-1995) // 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 { 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 Beta_format; } PH_arb_req_service;

264

// // // // //

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


IEEE Std 1394b-2002


Figure 19-3—PHY services (continued) PH_arb_req_service 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; }; } PH_data_req_service;

// data from link

// valid if reqType is PH_REQ_DATA // valid if reqType is PH_REQ_DATA_PREFIX for concatenated packets

PH_data_req_service waitPH_DATA_request(); typedef enum {PH_WON, PH_LOST, PH_WON_IMMED, PH_WON_ISOCH, PH_WON_CYCLE_START, PH_WON_ASYNC} PH_arb_confirmations; void PH_ARB_confirmation(PH_arb_confirmations Confirmation, speedCode Speed_Code, 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} PH_data_indications; void PH_DATA_indication(PH_data_indications Indication, speedCode Speed_Code, byte Data_Byte, pktType pkt_format); 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} PH_event_indications; void PH_EVENT_indication(PH_event_indications 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 Figure 19-4. Figure 19-4—Arbitration state machine internal variables // arb.h - arbitration code declarations // // // //

variables used in the main arbitration state machine beta_arb_functions.c, decode_phy_packet.c, ds_arb_functions.c, grant_actions.c idle_actions.c, receive_actions.c, receive_functions.c, reset.c, selfid.c, transmit_actions.c, transmit_functions.c, treeid.c

boolean ack; boolean all_child_ports_identified; int arb_delay; boolean arb_enable; boolean arb_OK; int arb_reset_gap; timer arb_timer; boolean arb_timer_max;

boolean Beta_port_request; boolean child_ID_complete[NPORT]; boolean child[NPORT]; int children; Copyright © 2002 IEEE. All rights reserved.

// Set if last packet observed was exactly 8 bits // Set if all child ports have been identified // Arbitration delay time (4 * gap_count / BASE_RATE) // Set if a node may arbitrate upon detection of a subaction gap // TRUE when Legacy arbitration permitted // Duration of an arbitration reset gap // ((52 + 32 * gap_count) / BASE_RATE) // Timer for arbitration state machines // Set true when arb timer has first reached maximum arbitration // time in A0:Idle. Allows arb_timer to be reused for token // recovery without falsely disabling arbitration in a new fairness // interval // TRUE if there’s a request on a port to be granted

// Number of child ports

265

IEEE Std 1394b-2002


Figure 19-4—Arbitration state machine internal variables (continued) boolean concatenated_packet; int contend_time; boolean converted_request; pktType cur_format; speedCode cur_speed; boolean defer_grant;

// TRUE if a concatenated packet is being received // Amount of time to wait during root contention // TRUE if a request has been converted from a Beta request into // 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 end of a subaction was detected, but the proxy_root // 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 enab_accel; boolean end_of_packet; boolean fly_by_OK; boolean force_root; boolean format_committed; boolean good_phy_packet; boolean grant_self; ArbState grant_to_give; boolean idle_receive_port; boolean initiated_reset; int lctrl; boolean Legacy_junior_request; boolean link_concatenation; boolean loop; int lowest_unidentified_child; boolean OK_to_grant;

// Set when reception of packet is complete // TRUE when fly-by concatenation permitted // Set to delay start of tree-ID process for this node // TRUE if format of received packet has been committed (repeated) // TRUE if received packet is a good PHY packet // TRUE if can grant to self // Specifies which grant type (GRANT or GRANT_ISOCH) to issue // in grant_actions // TRUE to simulate idle after sending proxy self_ID

// TRUE when a LEGACY_REQUEST has been received from a junior port // TRUE if a Legacy link intends to transmit a concatenated packet // 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 self_ID // TRUE if a request can be granted when in Idle (valid only in the // proxy_root). Gap times may need to be respected // and so PHY cannot always grant a favorite request instantaneously // Latch the value of arb_permitted() at the time it is evaluated

boolean own_request; int parent_port; boolean phy_response; // TRUE to indicate that a PHY response packet is to be transmitted boolean ping_response; // Set if self_ID packet(s) needed in response to a ping boolean received_speed_signal; // TRUE if saw a speed signal in the packet (being) received int requesting_port; // Lowest numbered requesting port (child in Legacy standards) int reset_duration; // Duration to assert bus reset signal boolean resolve_collision_request; // set to make a Legacy ISO priority request to keep the // bus busy and send a null packet PHY_PKT self_ID_pkt; // temporary storage during self_ID boolean send_null_packet; // 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 boolean speed_OK[NPORT]; int standby_c[NPORT]; int standby_L[NPORT]; // restored from standby int standby_NPORT[NPORT]; int standby_packet_count[NPORT]; int standby_parent[NPORT]; int standby_pwr[NPORT]; #define STORES_GAP_COUNT TRUE // a B only PHY may set this FALSE int subaction_gap; // Duration of a subaction gap ((28 + 16 * gap_count) / BASE_RATE) timer time_out_of_idle; // timer to ensure one symbol on every port after exit from idle boolean Timeout; // PHY register flag, set to 1 on max_arb_state_timeout

266


IEEE Std 1394b-2002


Variables that are shared between the architectural elements are defined in Figure 19-5. Each grouping of architectural elements lists the variables shared by that grouping. Figure 19-5—Variables shared between architectural elements // shared.h - shared variables and constants // shared between bport_tx.c and bport_rx.c int comma_table[2]; //table of K28.5 characters (see table 10-8) int control_table[16]; //table mapping scrambled control values to control characters (see table 10-9) int data_table[256][2]; //table of data characters (see table 10-7) #ifdef unsubscripted boolean sync_error_signal; // receiver error monitor has detected loss of synchronization boolean sync_lost_signal; // receiver is in a resynchronization state #else boolean sync_error_signal[NPORT]; boolean sync_lost_signal[NPORT]; #endif // shared between speed.c and dsport_rx.c speedCode ds_portRspeed;

// Filtered and latched receive speed for indicated port

// shared between port.c and node.c #ifdef unsubscripted const Beta_mode_only_port; boolean force_disconnect;

// // // // // // //

TRUE if the port does not support DS mode, used to indicate functions which may be omitted on Beta-only port implementations if a restore attempt fails, set true in P10 to force connection_status 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

boolean in_standby; boolean port_under_test; port_state_type port_state; boolean rx_ok; // In DS mode indicates the reception of a debounced TpBias signal // In Beta mode, indicates synchronization with the peer port boolean sending_tone; // true while a tone is being transmitted boolean untested; // port is connected but untested #else const Beta_mode_only_port[NPORT]; boolean force_disconnect[NPORT]; boolean in_standby[NPORT]; boolean port_under_test[NPORT]; port_state_type port_state[NPORT]; boolean rx_ok[NPORT]; boolean sending_tone[NPORT]; boolean untested[NPORT]; #endif boolean all_ports_suspended; // TRUE if suspended ports > 0 and active ports == 0 boolean found_loop; // 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 untested_state; // port is in state P11:Untested #else boolean untested_state[NPORT]; #endif // shared between port.c, node.c and bport_tx.c #ifdef unsubscripted Copyright © 2002 IEEE. All rights reserved.

267

IEEE Std 1394b-2002


Figure 19-5—Variables shared between architectural elements (continued) boolean bport_sync_ok;

// Port machine sets this to indicate to Connection Management // that a port has achieved synchronization with peer port.

#else boolean bport_sync_ok[NPORT]; #endif // shared between port.c, bport_rx.c and bport_tx.c #ifdef unsubscripted boolean bport_on;

// Set to true to instruct the Beta port to commence operating // Set to false to instruct the Beta port to cease operating

#else boolean bport_on[NPORT]; #endif // shared between port.c, dsport_rx.c and dsport_tx.c #ifdef unsubscripted boolean dsport_on;

// Set to true to instruct the DS port to commence operating // Set to false to instruct the DS port to cease operating

#else boolean dsport_on[NPORT]; #endif // shared between the main arb state machine and dsport_tx.c boolean non_null_packet; the

// TRUE if current packet contains a data payload and therefore requires // ending sequence of a legacy packet to include time for dribble bits

// shared between the main arb state machine and node.c int gap_count; boolean gap_count_reset_disable; // If set, a bus reset will not force the gap_count to the maximum boolean max_arb_state_timeout(); // See definition of All:R0c in Clause 13 // implicitly set by main arb state machine speedCode min_operating_speed; // min port speed of all active Beta mode ports boolean need_new_LTP; // TRUE if need to send a new LTP packet either during this round of testing // or at the start of the next round boolean nephew; // maintained by node.c, used to ensure ibr is zero in register map int physical_ID; int reset_count; // count resets during this time int standby_phy_ID[NPORT]; // information to be saved in case the peer port boolean T0_timeout; // TRUE if Tree_ID detects a loop int test_port; // shared between the main arb state machine and port.c #ifdef unsubscripted boolean disable_request; // Requests transmission of TX_DISABLE at the end of the next packet boolean fault; // port register map (suspend_fault || resume_fault) boolean receive_ok; // In DS_mode indicates the reception of a debounced TpBias signal // In Beta_mode, indicates the reception of a continuous electrically valid signal. // 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 reset_notify; boolean resume_fault; // Set when peer port fails to complete resume boolean standby_fault; boolean suspend_fault; // Set when peer port fails to complete suspend #else boolean disable_request[NPORT]; boolean fault[NPORT]; boolean receive_ok[NPORT];

268


IEEE Std 1394b-2002


Figure 19-5—Variables shared between architectural elements (continued) boolean boolean boolean boolean #endif

reset_notify[NPORT]; resume_fault[NPORT]; standby_fault[NPORT]; suspend_fault[NPORT];

timer max_occupancy_timer; boolean OK_to_detect_reset; boolean random_bool(); boolean resumption_done; int senior_port; boolean signaled;

// // // // // //

for a timeout on how long loop-free build can hold the bus TRUE if a resuming port is permitted to monitor for BUS RESET Not defined in C code - returns a random TRUE or FALSE value Resumption by at least one resuming port forces all to be done port number of the port pointing towards proxy_root 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; boolean connected;

boolean disabled; boolean do_standby; boolean loop_disabled; synchronization boolean proxy; boolean resume;

// // // // // // // // //

Indicates that the untested Beta port is ready to attach with the next bus reset Connection established with a peer port, and (Beta mode only) operating speed negotiation completed. This is maintained as a read-only bit in the port register map. PHY register bit, set to disable a port under software control, and indicates that the port is in state P6:Disabled TRUE when the port has been commanded to be a standby initiator Port is in State P12: Loop_disabled - set when the port loses

// during loop testing or a loop is detected // When true, instructs the arb state machine to generate a proxy self_ID // for the peer node on this port (which can only be a leaf node). // Indicates that the port is resuming, also causes a suspended port // to resume. // Set when PHY port is requested to suspend

boolean suspend_request; #else boolean attach[NPORT]; boolean connected[NPORT]; boolean disabled[NPORT]; boolean do_standby[NPORT]; boolean loop_disabled[NPORT]; boolean proxy[NPORT]; boolean resume[NPORT]; boolean suspend_request[NPORT]; #endif boolean border_node; // TRUE if any active DS ports or Legacy link boolean boundary_node; // with at least one active port and at least one suspended int HR_G; // Generation - alternates between 0 and 1 LTP_mode_type HR_mode; // mode of the packet to be transmitted int HR_test_value; // test value to be transmitted boolean in_control; // TRUE if won arbitration boolean isbr_OK; // Set when asynchronous or immediate arbitration conditions permit // an arbitrated (short) bus reset to be commenced boolean isolated_node; // Set if no ports active boolean loop_to_detect; // TRUE during reset up to S1 or S2 boolean send_attach; // TRUE to request the port to send attach requests timer test_interval_timer; // 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 port_speed;

// Negotiated operating speed of the port. Encoding as max_port_speed. // The value of Negotiated_speed in the port register map is set to // this value. Value established on connection in Beta_mode, or


269

IEEE Std 1394b-2002


Figure 19-5—Variables shared between architectural elements (continued) // during self_ID when in DS mode. #else speedCode port_speed[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;

// symbol to be sent - port sends the current contents when // it is ready to transmit a symbol

#else portSymbol portT[NPORT]; #endif // shared between the main arb state machine and process_req.c pktType a_format; pktType a_link_format; speedCode a_speed; boolean accelerating; boolean advance_OK[NPORT]; boolean arb_reset; boolean async_pending; boolean collision[NPORT];

// no imminent cycle start, so no danger of starving it // TRUE if can advance to the next arb state in the FIFO

// set TRUE when there’s a colliding packet from the port // cleared when the collision is resolved by TX of a null packet pktType current_pkt[NPORT]; // most recently read packet type from fifo for port boolean current_request; pktType cyc_start_format; pktType cyc_start_link_format; speedCode cyc_start_speed; boolean cycle_start_request; // TRUE if cycle start request from link boolean did_arbrst; // TRUE if already did arb reset, set false on async packet boolean enable_standby; // PHY reg map flag - TRUE to allow a nephew to put a port into standby boolean filter_async_even; boolean filter_async_odd; pktType i_format; pktType i_link_format; speedCode i_speed; // information about the current link request; pktType imm_format; pktType imm_link_format; speedCode imm_speed; boolean immediate_link_request; // TRUE if immediate request from link boolean immediate_request; // TRUE if immediate request from either PHY or link boolean iso_cycle; // TRUE if the bus is in the isochronous period boolean isoch_even_request; boolean isoch_odd_request; boolean isoch_pending; boolean legacy_phase_expected; // TRUE if seen DE or GRANT on legacy format packet int legacy_request_phase; // stores current legacy request phase boolean link_CS_indications; // TRUE if link gives indications of cycle start due or decelerate // (Legacy link) - set to FALSE on PHY-link interface reset or disable timer max_beta_timer; // to prevent driving DP into a DS cloud provoking an arb state timeout // needed only in border nodes boolean LPS; // tracks state of LPS boolean next_arb[NPORT]; // arb state machine requests next symbol from fifo for local port boolean next_even_request; boolean next_odd_request;

270


IEEE Std 1394b-2002


Figure 19-5—Variables shared between architectural elements (continued) boolean odd_isoch_phase;

// TRUE if the last fully completed isochronous interval began with // CYCLE_START_EVEN. (Upcoming or current interval will be ODD.)

BetaRequestCode own_req; boolean packet_ending[NPORT]; // current arb state terminates the packet - used for FIFO control int pending_port; // port for pending request (NPORT if from the local (Beta) link) PHY_state_type PHY_state; boolean proxy_root; // TRUE if senior_border in the cloud containing root or root in a B-bus speedCode portRspeed[NPORT]; // most recently read speed code from the fifo for the port int receive_port; speedCode req_speed; // Speed signaled by the link across the PHY-link interface boolean send_async_start_token; boolean senior_border; // TRUE if this node is the senior border for the local B cloud boolean SID_complete; // TRUE immediately after self_ID packet transmission concludes // in state S4 prior to the transmission of IDENT_DONE // shared between the main arb state machine, port.c and process_req.c boolean immediate_phy_request; // TRUE if immediate request from the PHY boolean odd_async_phase; // 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 immediate_restore_request; // TRUE if immediate request to restore on the nephew boolean isbr; // Set when an arbitrated (short) bus reset should be attempted boolean restore_request; // TRUE if requested the bus in order to complete a port restore #ifdef unsubscripted boolean active; // Indicates that the port is in state P2:Active // (set by state machine transitions to/from P2) boolean Beta_mode; // Set if the port has determined that it is operating in Beta mode, // unset otherwise (i.e., when operating in DS-Mode, // or when in P0:disconnected). // This is maintained as a read-only bit in the port register map. ArbState portRarb; // most recently read arb state from fifo for port boolean restore; #else boolean active[NPORT]; boolean Beta_mode[NPORT+1]; // Beta_mode[NPORT] always false ArbState portRarb[NPORT]; boolean restore[NPORT]; #endif // shared between the main arb state machine, port.c, node.c and bport_rx.c boolean bus_initialize_active; // Set while the PHY is initializing the bus // shared between the main arb state machine, node.c and process_req.c #ifdef unsubscripted byte current_data; #else byte current_data[NPORT]; #endif boolean B_node_root;

// most recently read data from the fifo for the port

// TRUE if the root is in the local B cloud // (NB, FALSE if root has a Legacy link)

breq_type breq; linkType 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 do NOT affect this variable speedCode max_Legacy_path_speed; BetaRequestCode receive_req[NPORT]; //track latest requests received on each port boolean root; // TRUE if root node Copyright © 2002 IEEE. All rights reserved.

271

IEEE Std 1394b-2002


Figure 19-5—Variables shared between architectural elements (continued) // shared between node.c and process_req.c boolean loop_test_request;

// 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 5

// depth of receive FIFO

// shared between the main arb state machine, bport_rx.c, node.c, and process_req.c boolean B_bus;

// 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 fifo_rd_ptr; int fifo_wr_ptr; #else int fifo_rd_ptr[NPORT]; int fifo_wr_ptr[NPORT]; #endif

// pointer to received character in fifo // only updated by the appropriate port

// shared between the main arb state machine, dsport_tx.c, and process_req.c boolean DS_stuck;

// TRUE if there might be a DS port stuck in DP somewhere on the bus

// shared between bport_rx.c, dsport_rx.c and process_req.c #ifdef unsubscripted portSymbol portR[FIFO_DEPTH]; // symbol received by port machine #else portSymbol portR[NPORT][FIFO_DEPTH]; #endif // shared between bport_tx.c, port.c and process_req.c #ifdef unsubscripted BetaRequestCode arbreqT; // arbitration request to send #else BetaRequestCode arbreqT[NPORT]; #endif // shared between all modules boolean power_reset;

// TRUE during power reset, goes false at the end of power reset

#include “proto.h”

// last header, get the prototypes for C code checking purposes

272


IEEE Std 1394b-2002


19.2 Connection management routines 19.2.1 Node-level connection monitor Figure 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 bias_timer;

// Timer for bias filter

int loop_test_random();

// not defined by C code, see spec for requirements

void node_status_monitor() { // Continuously monitor node status in all states int active_ports = 0; // count of active ports, including ports in standby int i, suspended_ports = 0; boolean border = link == Legacy_Link; // starting assumption boolean l_isolated_node = TRUE; speedCode l_min_operating_speed = PHY_SPEED; // starting assumption boolean l_nephew = FALSE; // starting assumption if (!power_reset) { for (i = 0; i < NPORT; i++) { if ((active[i] || suspend_request[i] || do_standby[i]) && Beta_mode[i] && (port_speed[i] < l_min_operating_speed)) l_min_operating_speed = port_speed[i]; if (active[i] || in_standby[i]) { active_ports++; // Necessary to deduce border node status l_isolated_node = FALSE; if (!Beta_mode[i]) // active port is operating in Legacy mode border = TRUE; } else if (connected[i] && !disabled[i] && !in_standby[i] && !loop_disabled[i] && !untested_state[i]) suspended_ports++; // Other part of border node definition if (in_standby[i] && connected[i] && !proxy[i]) l_nephew = TRUE; } } border_node = border; // the node is a border or otherwise boundary_node = (active_ports > 0 && suspended_ports > 0); all_ports_suspended = (active_ports == 0) && (suspended_ports > 0); isolated_node = l_isolated_node ; // Remains TRUE if no active port(s) found min_operating_speed = l_min_operating_speed; nephew = l_nephew; } boolean suspend_in_progress() { int i; for (i = 0; i < NPORT; i++) if (suspend_request[i]) return(TRUE); return(FALSE); }

// TRUE if any port suspending

boolean resume_in_progress() { int i; for (i = 0; i < NPORT; i++) if (resume[i]) return(TRUE); return(FALSE); }

// TRUE if any port resuming

void suspend_all_active_ports() { Copyright © 2002 IEEE. All rights reserved.

273

IEEE Std 1394b-2002


Figure 19-6—Node-level connection monitor functions and routines (continued) int j; for (j = 0; j < NPORT; j++) if (active[j]) suspend_request[j] = TRUE;

// Otherwise all active ports become suspend initiators

} void resume_all_ports() { int j; for (j = 0; j < NPORT; j++) if ((port_state[j] == P1) || (port_state[j] == P3) || (port_state[j] == P4) || (port_state[j] == P5)) resume[j] = TRUE; // Resume all suspended ports } boolean resume_rx_OK() { int j; boolean resume_rx_OK_val = TRUE; // Assume this is true until proven false for (j=0; j < NPORT; j++) resume_rx_OK_val &= (!resume[j] || rx_ok[j]); // Note that for resuming Beta ports presence of receive_ok is not // enough, need to allow sufficient time for port sync also. For // DS ports, rx_ok indicates state of detected bias return (resume_rx_OK_val); } boolean restore_in_progress() { int i; for (i = 0; i < NPORT; i++) if (restore[i]) return(TRUE); return(FALSE); }

// TRUE if any port restoring

void restore_port() { int j; for (j = 0; j < NPORT; j++) if (in_standby[j] && connected[j] && !proxy[j]) restore[j] = TRUE; // Restore port in standby (if any) if on leaf }

void bias_status() { // Continuously running bias update code static boolean bias_filter[NPORT]; // TRUE when applying hysteresis to bias_detect circuit int i; if (power_reset) { for (i = 0; i < NPORT; i++) bias[i] = bias_filter[i] = FALSE; while (power_reset) ; return; } for (i = 0; i < NPORT; i++) { if (!Beta_mode_only_port[i]) { if (sending_tone[i]) { bias_filter[i] = FALSE; // abandon bias filtering on this port while sending a tone continue; // and move on to next port } if (!(PMD_STATUS_request(i) & PMD_BIAS_DETECT)) { // 200 - 300 ns hysteresis recommended // see 4.4.4 of 1394a for requirements bias_filter[i] = FALSE; bias[i] = FALSE ; // Report immediately } else if (bias_filter[i]) { // Filtering positive bias transition? if (bias_timer >= BIAS_FILTER_TIME) { bias_filter[i] = FALSE; // Done filtering

274



IEEE Std 1394b-2002

Figure 19-6—Node-level connection monitor functions and routines (continued) bias[i] = TRUE; // Confirm new value in PHY register bit } } else if ( !disabled[i] // detected and reported bias differ on enabled port? && (PMD_STATUS_request(i) & PMD_BIAS_DETECT) != bias[i]) { bias_filter[i] = TRUE; // Yes, start a filtering period bias_timer = 0; } } } } void send_LTP() { PHY_PKT tx_phy_pkt; tx_phy_pkt.dataQuadlet = 0; tx_phy_pkt.phy_ID = 0x3F; tx_phy_pkt.ext_type = 0xE; // LTP packet; tx_phy_pkt.mode = HR_mode; tx_phy_pkt.G = HR_G; tx_phy_pkt.test_value = HR_test_value; PH_DATA_indication(PH_DATA_START, S100, 0, LEGACY); tx_quadlet(tx_phy_pkt.dataQuadlet); tx_quadlet(~tx_phy_pkt.dataQuadlet); // Keep bus for concatenation PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); stop_tx_packet(DATA_PREFIX, NPORT); start_tx_packet(S100, LEGACY, FALSE); // Send data prefix & speed signal } void tx_PHY_packet(PHY_PKT packet_to_send, int port_num) { 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 start_tx_packet(S100, BETA, FALSE); } { // Send the special configuration packet on the restoring port portT[port_num].pkt = BETA; portT[port_num].arb = SPEED; portT[port_num].speed = S100; portT[port_num].tag = ARB_STATE; wait_symbol_time(S100); portT[port_num].arb = DATA_PREFIX; portT[port_num].speed = DEFAULT; portT[port_num].tag = ARB_STATE; wait_symbol_time(S100); for (i = 0; i < 4; i++) { // ...a byte at a time portT[port_num].speed = S100; portT[port_num].data = (packet_to_send.dataQuadlet >> 8*(3-i)) & 0xFF; portT[port_num].tag = DATA; wait_symbol_time(S100); } for (i = 0; i < 4; i++) { // ...a byte at a time portT[port_num].speed = S100; portT[port_num].data = ((~packet_to_send.dataQuadlet) >> 8*(3-i)) & 0xFF; portT[port_num].tag = DATA; wait_symbol_time(S100); } // Now prepare ending state for restoring port portT[port_num].arb = DATA_END; Copyright © 2002 IEEE. All rights reserved.

275

IEEE Std 1394b-2002


Figure 19-6—Node-level connection monitor functions and routines (continued) portT[port_num].speed = DEFAULT; portT[port_num].tag = ARB_STATE; } } join // Send and time ending state for active ports, time ending state for restoring port as well restore[port_num] = FALSE; // this lets the port transition to active stop_tx_packet(DATA_END, NPORT); // packet ends with a quiet grant to nephew PH_DATA_indication(PH_DATA_END, 0, 0, 0); } PHY_PKT rx_PHY_packet(int port_num) { PHY_PKT packet_received; int byte_count; ArbState rx_arb_state; byte rx_data_byte; byte_count = 0; rx_arb_state = portRarb[port_num]; // wait for start of packet while (connected[port_num] && !((rx_arb_state == SPEED) || (rx_arb_state == DATA_PREFIX))) rx_arb_state = portRarb[port_num]; while (connected[port_num] && (rx_arb_state != DATA_BYTE)) rx_arb_state = portR_next_arb(port_num); // skip DATA_PREFIXes while (rx_arb_state == DATA_BYTE) { rx_data_byte = current_data[port_num]; if (byte_count < 8) packet_received.dataBytes[byte_count] = rx_data_byte; byte_count++; rx_arb_state = portR_next_arb(port_num); } restore[port_num] = FALSE; // this lets the port transition to active wait_symbol_time(S100); wait_symbol_time(S100); if ((byte_count != 8) || (packet_received.dataQuadlet != ~packet_received.checkQuadlet)) packet_received.dataQuadlet = 0; // kill bad packets return (packet_received); } void con_mgmnt_granted() { // called from tx_actions once arbitration has been won int i; PHY_PKT config_pkt; if (restore_request) { for (i = 0; i < NPORT; i++) { if (restore[i] && bport_sync_ok[i]) { // find a restoring port (do restores one at a time) if (proxy[i]) { // uncle actions // send updated information to peer port config_pkt.dataQuadlet = 0; config_pkt.root_ID = standby_phy_ID[i]; config_pkt.R = 1; // to avoid both R and T being zero config_pkt.T = gap_count_reset_disable ? 1: 0; config_pkt.gap_count = gap_count; config_pkt.notify_Legacy_speed = max_Legacy_path_speed; config_pkt.notify_B_node_root = B_node_root ? 1: 0; config_pkt.notify_B_bus = B_bus ? 1: 0; config_pkt.Q = root ? 1: 0; // included for use by PIL_FOP config_pkt.P = PMD_PS_request() ? 1: 0; // included for use by PIL_FOP config_pkt.notify_odd_async_phase = odd_async_phase ? 1: 0; config_pkt.notify_reset = reset_notify[i] ? 1: 0; tx_PHY_packet(config_pkt, i); // and the special configuration packet on this port // and set the port active proxy[i] = FALSE; } else { // nephew actions // restored leaf node - receive updated information from peer port

276


IEEE Std 1394b-2002


Figure 19-6—Node-level connection monitor functions and routines (continued) config_pkt = rx_PHY_packet(i); // and set the port active start_tx_packet(S100, BETA, FALSE); // send null packet physical_ID = config_pkt.root_ID; gap_count_reset_disable = config_pkt.T == 1; gap_count = config_pkt.gap_count; max_Legacy_path_speed = config_pkt.notify_Legacy_speed; B_node_root = config_pkt.notify_B_node_root == 1; B_bus = config_pkt.notify_B_bus == 1; odd_async_phase = config_pkt.notify_odd_async_phase == 1; if (config_pkt.notify_reset == 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(odd_async_phase ? PH_ARB_RESET_ODD : PH_ARB_RESET_EVEN, 0, 0, 0); immediate_restore_request = FALSE; boss_end_packet_actions(FALSE, GRANT); // not in iso cycle } break;

// done this port, don’t do any more

} } restore_request = FALSE; for (i = 0; i < NPORT; i++) // check if any more to do if (restore[i] && bport_sync_ok[i]) restore_request = TRUE; } else { // request for loop test max_occupancy_timer = 0; // Start the occupancy timer. in_control = TRUE; 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 start_tx_packet(S100, LEGACY, FALSE); // Send data prefix & speed signal while (loop_test_request) if (need_new_LTP) { send_LTP(); test_interval_timer = 0; need_new_LTP = FALSE; } in_control = FALSE; // then release the bus. isbr_OK = isbr; // While the local node was a controlling node, any port which // received an attach request or a test port which // received a bus reset will have set isbr if (!isbr_OK) { PH_DATA_indication(PH_DATA_END, 0, 0, 0); stop_tx_packet(DATA_END, NPORT); } } } void loop_detector() { int i; if (power_reset) { while (power_reset) ; return; } while (loop_to_detect) {

// continuously running

// exit from here if tree_ID is successful, possibly only after // the local Beta ports have been put into the untested state if (T0_timeout || (max_arb_state_timeout()) || (reset_count > 3)) { // tree_ID has detected a loop for (i = 0; i < NPORT; i++)


277

IEEE Std 1394b-2002


Figure 19-6—Node-level connection monitor functions and routines (continued) if (Beta_mode[i] && active[i]) { // note that the transition out of active might now allow an exit from T0 force_disconnect[i] = TRUE; } while (loop_to_detect) // only force disconnect once per each loop detection ; } } } boolean attach_pending() { int i; for (i = 0; i < NPORT; i++) if (attach[i]) return(TRUE); return(FALSE); } int new_test_value() { return (loop_test_random()); }

// TRUE if any port set to attach

// see specification for requirements

void loop_test_interval_actions() { // continuously running static int collision_count; byte received_LTS; int i; if (power_reset) { collision_count = 0; HR_test_value = new_test_value(); for (i = 0; i < NPORT; i++) port_under_test[i] = FALSE; send_attach = FALSE; found_loop = FALSE; loop_test_request = FALSE; while (power_reset) ; return; } if (NPORT==1) return;

// single port phy doesn’t require loop testing

test_port = 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 (attach_pending() || (HR_mode == ATTACH_IN_PROGRESS)) ; // Now select a unique port to test // First try to find a port which is receiving an LTS lower than the test value // If unsuccessful, then choose a port which is receiving an LTS equal to the test value // Never select a port which 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 1))); rx_control_map(rx_control); } else if(((rx_scram_req=rx_reqtype_decode(character_in,rx_rd)) >=0) && !pkt && !pkt_prefix){ rx_req_code=TRUE; rx_req=(rx_scram_req ^ descram) & 0xF9; request_type_map(rx_req); } else if(((rx_scram_data=rx_data_decode(character_in,rx_rd))>=0) && (pkt || pkt_prefix) ) { localR.tag=DATA; localR.data=rx_scram_data ^ descram; } else if(((rx_scram_req=rx_comma_decode(character_in, rx_rd))>=0) && !pkt && !pkt_prefix) { rx_comma=TRUE; rx_req_code=TRUE; rx_req=(rx_scram_req ^ descram) & 0xF9; request_type_map(rx_req); } else localR.tag=INVALID; update_descrambler(); if (rx_scram_ctrl < 0) rx_rd=update_rd(character_in, rx_rd); // control characters are all neutral disparity. // update_rd() should never be used for control characters. if (localR.tag == ARB_STATE && localR.arb==DATA_PREFIX) rx_rd=disparity_indicator; // rd is always reset when a data prefix symbol is received. return(port_error_monitor()); // check that synchronization is OK } boolean character_sync() { rx_character(); if (rx_req_code) char_check=(char_check==3? 3:char_check++); else char_check=0; return (rx_comma && (char_check==3)); }

boolean bspeed_filter() { if (pkt) return(FALSE); if (localR.tag==ARB_STATE && (localR.arb==SPEEDa || localR.arb==SPEEDb || localR.arb==SPEEDc) && new_speed_code && (last_localR.tag == INVALID)) { // bad symbol either immediately before speed code invalid_speed_code = TRUE; // or before the speed and format is determined speed_known = FALSE; // invalidate memory of previous speed code } else if (localR.tag==ARB_STATE && localR.arb==SPEEDc) { rx_speed_diff=rx_speed_diff++; // for every SPEEDc increase the speed ratio... } else if (!invalid_speed_code && localR.tag==ARB_STATE && localR.arb==SPEEDa) { rx_pkt_speed=port_speed-rx_speed_diff; // actual speed is a function of the port speed pad_ratio = (1 9 == 0b0011111) || (rx_bits>>9 == 0b1100000)) { j = i; break; } rx_bits = (rx_bits >1); character_out=control_table[tx_scram_ctrl]; } else { if(tx.tag==ARB_REQUEST) tx_req=arb_req_symbol_map(tx.req); else if(tx.tag==CONFIG_REQUEST) tx_req=config_req_symbol_map(tx.arb); else if(tx.tag==LEGACY_ARB) tx_req = (((tx.data & 0b011) | (tx.arb==LEGACY_PHASE ? 0b100 : 0)) (best_req.isoch & *ipm)) ? receive_req[*bip = i].isoch : best_req.isoch); } if (active[i] && Beta_mode[i] && (((receive_req[i].async & *apm) == A_NONE) || ((receive_req[i].isoch & *ipm) == I_NONE))) { requests_unknown = TRUE; // at least one active port hasn’t received an updated request } } if (!proxy_root) { // finally prefer senior port best_req.async = (active[senior_port] && Beta_mode[senior_port] && ((receive_req[senior_port].async & *apm) > (best_req.async & *apm)) ? receive_req[*bap = senior_port].async : best_req.async); best_req.isoch = (active[senior_port] && Beta_mode[senior_port] && ((receive_req[senior_port].isoch & *ipm) > (best_req.isoch & *ipm)) ? receive_req[*bip = senior_port].isoch : best_req.isoch); } // in_phase_isoch_request returns true anytime an ISOCH_CURRENT is present or // during the iso_cycle when an in-phase isoch request is present // in_phase_async_request returns true only during the asynchronous interval // when an in-phase asynch request is present *in_phase_isoch_request = ((iso_cycle && ((best_req.isoch & *ipm) >= (ISOCH_IN_PHASE & *ipm))) || Copyright © 2002 IEEE. All rights reserved.

327

IEEE Std 1394b-2002


Figure 19-17—Border arbitration functions (continued) (!iso_cycle && ((best_req.isoch & *ipm) == (ISOCH_CURRENT & *ipm)))); *in_phase_async_request = (!iso_cycle && ((best_req.async & *apm) >= (CURRENT & *apm))); // i_advance_interval returns true if all inbound isoch requests are known and no requests // remain for the current isoch interval // a_advance_interval 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 *i_advance_interval = (!requests_unknown && ((best_req.isoch & *ipm) < (ISOCH_IN_PHASE & *ipm))); *a_advance_interval = (!requests_unknown && ((best_req.async & *apm) < (odd_async_phase ? NONE_EVEN & *apm : NONE_ODD & *apm))); return (best_req); } boss_eop_status test_requests(int *best_port, boolean grant_received_from_senior, ArbState *received_grant) { int i; int bip = NPORT; // best isochronous request port number int bap = NPORT; // best asynchronous request port number byte apm; // mask to select the in-phase async requests byte ipm; // mask to select the in-phase isoch requests boolean in_phase_isoch_request, in_phase_async_request; boolean i_advance_interval, a_advance_interval; BetaRequestCode best_req; pktType next_format; // holds format and speed of next packet PHY speedCode next_speed; // will transmit if it GRANTs itself boolean request_to_service; *best_port = NPORT; best_req = bestReq (&apm, &ipm, &bap, &bip, &in_phase_isoch_request, &in_phase_async_request, &i_advance_interval, &a_advance_interval); // 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 (!B_node_root), and (c) a cycle start is expected

if (!grant_received_from_senior && !iso_cycle && !B_node_root && !(link_CS_indications && 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 arb_permitted() test. in_phase_async_request = FALSE; } request_to_service = TRUE; // Until proven otherwise if (own_req.async == BORDER) // only when senior border request_to_service = FALSE; else if ((*received_grant == GRANT_ISOCH) && in_phase_isoch_request) *best_port = bip; else if ((*received_grant == GRANT) && in_phase_async_request) *best_port = bap; else if ((*received_grant == DATA_END) && (best_req.isoch == ISOCH_CURRENT)) { *best_port = bip; *received_grant = GRANT_ISOCH; // upgrade to an explicit isoch grant } else request_to_service = FALSE;

328


IEEE Std 1394b-2002


Figure 19-17—Border arbitration functions (continued) if (request_to_service) { // 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 (*best_port == 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 // need to consider PHY initiated requests if (isbr) { next_format = LEGACY; next_speed = S100; } else if (restore_request) { next_format = BETA; next_speed = S100; } else { // a loop_test_request next_format = LEGACY; next_speed = S100; } } else { // not a Legacy_Link if (*received_grant == GRANT_ISOCH) { next_format = i_format; next_speed = i_speed; } else if (cycle_start_request && root) { next_format = cyc_start_format; next_speed = cyc_start_speed; } else if (isbr) { // Assume format used for a non B_bus since rule won’t apply to a B_bus next_format = LEGACY; next_speed = S100; } else if (restore_request) { next_format = BETA; next_speed = S100; } else if (loop_test_request) { next_format = LEGACY; next_speed = S100; } else { // an async request next_format = a_format; next_speed = a_speed; } } 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 next_format = LEGACY; next_speed = S100; } if (!B_bus && (cur_format == LEGACY) && (cur_speed != S100) && (next_format == BETA || next_speed == S100)) // just finishing a non-S100 Legacy packet and the next packet could // ultimately appear as an S100 Legacy packet. return(grant_senior); Copyright © 2002 IEEE. All rights reserved.

329

IEEE Std 1394b-2002


Figure 19-17—Border arbitration functions (continued) else { if (*best_port == NPORT) return(grant_link); if (*best_port == senior_port) return(grant_senior); else { for (i = 0; i < NPORT; i++) // don’t prolong collision situation if (collision[i]) return (grant_senior); return(grant_junior); } } } // nothing to service if (*received_grant == DATA_END) // implicit grant, pass on return(grant_senior); else if (B_bus) { // 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 which can temporarily // block other in-phase requests) if (iso_cycle && i_advance_interval && (*received_grant == GRANT_ISOCH) && !grant_received_from_senior) { // end of isoch interval send_async_start_token = TRUE; *received_grant = GRANT; // change to async grant, so that async req’s can be checked } if ((!iso_cycle || send_async_start_token) && a_advance_interval && !did_arbrst && (*received_grant == GRANT) && !grant_received_from_senior) { // create arb reset if no current phase or left over previous phase requests odd_async_phase = !odd_async_phase; arb_reset = TRUE; did_arbrst = TRUE; // after repeating an arb reset token, disallow further phase // advancements in a B bus until non IDLE traffic occurs } return((arb_reset || send_async_start_token) ? boss_management_actions : grant_senior); } else //hybrid bus with explicit grant, free stuck DS ports if necessary if (cur_format != LEGACY) return(grant_null); else return(grant_senior); } void boss_end_packet_actions(boolean grant_received_from_senior, ArbState grant_type) { // // // //

make sure that any Legacy packet which 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 grant_self // in order to // loop back on exit from TX actions to get the next packet from the link. // 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; boss_eop_status req_status;

330


IEEE Std 1394b-2002


Figure 19-17—Border arbitration functions (continued) // find best isoch and async request req_status = test_requests(&requesting_port, grant_received_from_senior, &grant_type); switch (req_status) { case grant_senior: if (grant_received_from_senior) { // can’t grant back to senior, stop_tx_packet(grant_type, NPORT); // so grant self and send_null_packet = TRUE; // schedule TX of a null packet grant_self = TRUE; } else { stop_tx_packet(grant_type, senior_port); requesting_port = NPORT; // // // // if

Set OK_to_grant for proxy_root’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 (((grant_type == GRANT_ISOCH) && iso_cycle) || ((grant_type == GRANT) && !iso_cycle)) { // explicit grant received which matches PHY’s interval if (root && (link == Legacy_Link)) { // await possible PriReq for cycle start OK_to_grant = FALSE; defer_grant = TRUE; } else { // explicit end of subaction, no need to defer grant in A0:Idle OK_to_grant = TRUE; defer_grant = FALSE; } } else { // still expecting end of subaction or non-matching grant type OK_to_grant = FALSE; defer_grant = FALSE; } } return; case grant_link: stop_tx_packet(grant_type, NPORT); grant_to_give = grant_type; grant_self = TRUE; return; case grant_null: stop_tx_packet(grant_type, NPORT); send_null_packet = TRUE; // schedule TX of a null packet grant_self = TRUE; return; case grant_junior: stop_tx_packet(grant_type, requesting_port); grant_to_give = grant_type; return; case boss_management_actions: stop_tx_packet(grant_type, NPORT); gap_repeat_actions(NPORT); // having advanced the gap, now look for a favorite request again grant_type = GRANT; req_status = test_requests(&requesting_port, grant_received_from_senior, &grant_type); switch (req_status) { case grant_senior: for (i = 0; i < NPORT; i++) if (i != senior_port) portTarb(i, IDLE); // while snr port gets GRANT if (!proxy_root) { portTarb(senior_port, GRANT); wait_symbol_time(port_speed[senior_port]); wait_symbol_time(port_speed[senior_port]); } OK_to_grant = TRUE; // for proxy_root’s use in A0:Idle defer_grant = FALSE; requesting_port = NPORT; // so that node goes to Idle return; Copyright © 2002 IEEE. All rights reserved.

331

IEEE Std 1394b-2002


Figure 19-17—Border arbitration functions (continued) case grant_link: grant_to_give = grant_type; grant_self = TRUE; did_arbrst = FALSE; return; case grant_null: send_null_packet = TRUE; grant_self = TRUE; did_arbrst = FALSE; return; case grant_junior: grant_to_give = grant_type; did_arbrst = FALSE; return; case boss_management_actions: return;

// only relevant to a B_bus

// schedule TX of a null packet // only relevant to a B_bus

// only relevant to a B_bus // this should now never happen again!!

} } } void gap_repeat_actions(int token_receive_port) { // // // // //

Calling gap_repeat_actions 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 B_bus), or arb_reset (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 (send_async_start_token || iso_cycle) // either token ends the isoch interval PH_DATA_indication(PH_SUBACTION_GAP, 0, 0, 0); if (arb_reset) PH_DATA_indication(odd_async_phase ? PH_ARB_RESET_ODD : PH_ARB_RESET_EVEN, 0, 0, 0); if (bus_initialize_active) { // end of self_ID process for whole bus? PH_EVENT_indication(PH_BUS_RESET_COMPLETE, 0, 0); bus_initialize_active = FALSE; } } if (iso_cycle) { // either token ends the isoch interval iso_cycle = FALSE; odd_isoch_phase = !odd_isoch_phase; // advance phase at end of isoch interval } // now, send the async gap token send_control(odd_async_phase ? ASYNC_ODD : ASYNC_EVEN, token_receive_port); if (arb_reset) arb_enable = TRUE; // re-enable fair arbitration for Legacy links arb_reset = send_async_start_token = FALSE; }

332


IEEE Std 1394b-2002


19.4.2 Request processing Figure 19-18—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 // when the link is notified of a restore or bus reset void cancel_requests(){ breq = NO_REQ; immediate_link_request = FALSE; current_request = FALSE; next_odd_request = FALSE; next_even_request = FALSE; isoch_odd_request = FALSE; isoch_even_request = FALSE; cycle_start_request = 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 capture_link_requests() { PH_arb_req_service phyArbReq; // latest request from a link (if any) if (power_reset) { cancel_requests(); // also on PHY-link reset and disable link_CS_indications = FALSE; enable_standby = FALSE; while (power_reset) ; // assume an indication after power reset link = PH_LINK_TYPE_response(); // link type determined on power_reset } phyArbReq = waitPH_ARB_request(); // wait for next link request switch (phyArbReq.reqType) { case PH_IMMED_REQ: // from Beta link or Legacy link restore_port(); // restore if on nephew immediate_link_request = TRUE; if (link == Legacy_Link) { req_speed = phyArbReq.speed; } else { imm_speed = phyArbReq.speed; imm_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; imm_format = ((phyArbReq.Beta_format) || B_bus || (imm_speed > max_Legacy_path_speed))? BETA: LEGACY; break; } // The PHY can hold only one async request at a time (current or next_*) case PH_CURRENT: restore_port(); // restore if on nephew current_request = TRUE; next_odd_request = next_even_request = FALSE; a_speed = phyArbReq.speed; a_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; a_format = ((phyArbReq.Beta_format) || B_bus || (a_speed > max_Legacy_path_speed))? BETA: LEGACY; break; case PH_NEXT_ODD: restore_port(); // restore if on nephew if (!odd_async_phase) { next_odd_request = TRUE; next_even_request = current_request = FALSE; Copyright © 2002 IEEE. All rights reserved.

333

IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) } else { current_request = TRUE; next_odd_request = next_even_request = FALSE; } a_speed = phyArbReq.speed; a_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; a_format = ((phyArbReq.Beta_format) || B_bus || (a_speed > max_Legacy_path_speed))? BETA: LEGACY; break; case PH_NEXT_EVEN: restore_port(); // restore if on nephew if (odd_async_phase) { next_even_request = TRUE; next_odd_request = current_request = FALSE; } else { current_request = TRUE; next_odd_request = next_even_request = FALSE; } a_speed = phyArbReq.speed; a_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; a_format = ((phyArbReq.Beta_format) || B_bus || (a_speed > max_Legacy_path_speed))? 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 restore_port(); // restore if on nephew cycle_start_request = TRUE; cyc_start_speed = phyArbReq.speed; cyc_start_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; cyc_start_format = ((phyArbReq.Beta_format) || B_bus || (cyc_start_speed > max_Legacy_path_speed))? BETA: LEGACY; break; case PH_ISOCH_REQ_EVEN: restore_port(); // restore if on nephew isoch_even_request = TRUE; isoch_odd_request = FALSE; i_speed = phyArbReq.speed; i_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; i_format = ((phyArbReq.Beta_format) || B_bus || (i_speed > max_Legacy_path_speed))? BETA: LEGACY; break; case PH_ISOCH_REQ_ODD: restore_port(); // restore if on nephew isoch_odd_request = TRUE; isoch_even_request = FALSE; i_speed = phyArbReq.speed; i_link_format = phyArbReq.Beta_format ? BETA: UNSPECIFIED; i_format = ((phyArbReq.Beta_format) || B_bus || (i_speed > max_Legacy_path_speed))? BETA: LEGACY; break; case PH_ISOCH_PHASE_ODD: // link has received a cycle start packet odd_isoch_phase = TRUE; // keeps link and PHY in phase in junior Beta clouds iso_cycle = TRUE; // in case cycle start token wasn’t received accelerating = TRUE; break; case PH_ISOCH_PHASE_EVEN: // link has received a cycle start packet odd_isoch_phase = FALSE; // keeps link and PHY in phase in junior Beta clouds iso_cycle = TRUE; // in case cycle start token wasn’t received accelerating = TRUE; break; case PH_LPS_ACTIVE: LPS = TRUE; if (enable_standby) {

334



IEEE Std 1394b-2002

Figure 19-18—Background request processing (continued) enable_standby = FALSE; restore_port(); } break; case PH_LPS_INACTIVE: LPS = FALSE; cancel_requests(); link_CS_indications = FALSE; break; case PH_CYCLE_START_DUE: link_CS_indications = TRUE; accelerating = FALSE; break; // finally requests from a Legacy link case PH_CYCLE_START_SEEN: accelerating = TRUE; break; case PH_ISOCH_REQ: accelerating = TRUE; breq = ISOCH_REQ; req_speed = phyArbReq.speed; break; case PH_PRIORITY_REQ: breq = PRIORITY_REQ; req_speed = phyArbReq.speed; break; case PH_FAIR_REQ: breq = FAIR_REQ; req_speed = phyArbReq.speed; break; } } // continuously running routine to process request signals received on Beta ports and link void process_requests(){ boolean idle_arb_state_timeout; // TRUE if node has an ungranted request from the link or // local PHY, see description of Arb state timeout in text BetaRequestCode best_req; byte apm, ipm; int bip, bap; // best isoch and async ports portSymbol portCurrent; boolean in_packet[NPORT]; boolean ignore_port[NPORT]; // TRUE if temporarily ignoring a packet from a port due to // a collision (packet received while already receiving a packet) int i,j; if (power_reset) { for (i = 0; i < NPORT; i++) { advance_OK[i] = TRUE; in_packet[i] = FALSE; ignore_port[i] = FALSE; collision[i] = FALSE; fifo_rd_ptr[i] = 0; } while (power_reset) ; } // update own_req with request from link or internal PHY request // set own async req immediate_request = immediate_link_request || immediate_phy_request || immediate_restore_request; if ((senior_border) && // the timer only runs on the senior border (max_beta_timer > MAX_BETA_TIME) && DS_stuck) own_req.async = BORDER; Copyright © 2002 IEEE. All rights reserved.

335

IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) else if (cycle_start_request && root) own_req.async = CYCLE_START_REQ; else if (current_request || (restore_request && !immediate_restore_request) || loop_test_request || isbr) // connection management requests for restoring and loop-free build // as well as short bus reset requests look like current requests own_req.async = CURRENT; else if (next_odd_request) // previously checked for async phase own_req.async = NEXT_ODD; else if (next_even_request) own_req.async = NEXT_EVEN; else if (odd_async_phase) own_req.async = NONE_ODD; else own_req.async = NONE_EVEN;

// // // 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. (iso_cycle && ((isoch_odd_request && odd_isoch_phase) || // in-phase odd request? (isoch_even_request && !odd_isoch_phase))) // in-phase even request? own_req.isoch = ISOCH_CURRENT; else if (B_node_root && isoch_odd_request) own_req.isoch = ISOCH_ODD; // never present in junior Beta cloud else if (B_node_root && isoch_even_request) own_req.isoch = ISOCH_EVEN; // never present in junior Beta cloud else own_req.isoch = ISOCH_NONE; idle_arb_state_timeout = (!((own_req.async == NONE_ODD || own_req.async == NONE_EVEN) && own_req.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++) { // check for collisions, given that only the receive_port should be in_packet for receive states, // and no ports should be in_packet for transmit, bus reset, and tree ID states if (active[i] && in_packet[i] && (((PHY_state == RX) && (receive_port != i)) || ((PHY_state == S2) && (receive_port != i)) || ((PHY_state == S4) && !SID_complete) || (PHY_state == TX) || (PHY_state == PH) || (PHY_state < S0))) { collision[i] = TRUE; // data collision, need to keep the rest of the bus // busy until this packet completes ignore_port[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)) && ((PHY_state == TX) || (PHY_state == RX) || (PHY_state == PH)) && (receive_port != i)) // necessary to protect GRANTs at end of packets portRarb[i] = IDLE; if (!(active[i] || restore[i]) || // always dequeue the fifo unless in active or restore !in_packet[i] || advance_OK[i] || ignore_port[i]) { if (packet_ending[i]) { in_packet[i] = FALSE; // last symbol terminated a packet ignore_port[i] = FALSE; // no longer need to ignore

336


IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) packet_ending[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 (fifo_rd_ptr[i] != fifo_wr_ptr[i]) { fifo_rd_ptr[i] = ++fifo_rd_ptr[i] % FIFO_DEPTH; portCurrent = portR[i][fifo_rd_ptr[i]]; advance_OK[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.rx_dsarb) { case RX_IDLE : portCurrent.arb = IDLE; break; case RX_PARENT_NOTIFY | RX_REQUEST_CANCEL : portCurrent.arb = (PHY_state < A0 ? PARENT_NOTIFY : REQUEST_CANCEL); break; case RX_IDENT_DONE : portCurrent.arb = IDENT_DONE; break; case RX_SELF_ID_GRANT | RX_REQUEST : portCurrent.arb = (PHY_state < A0 ? SELF_ID_GRANT : LEGACY_REQUEST); break; case RX_ROOT_CONTENTION | RX_GRANT | RX_SUSPEND : portCurrent.arb = (PHY_state < A0 ? ROOT_CONTENTION : (PHY_state == A0 ? SUSPEND : GRANT)); break; case RX_PARENT_HANDSHAKE | RX_DATA_END : portCurrent.arb = (PHY_state < S0 ? PARENT_HANDSHAKE : DATA_END); break; case RX_CHILD_HANDSHAKE | RX_DISABLE_NOTIFY : portCurrent.arb = (PHY_state < A0 ? CHILD_HANDSHAKE : DISABLE_NOTIFY); break; case RX_DATA_PREFIX : portCurrent.arb = (PHY_state < 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 ((portCurrent.data == legacy_request_phase) && !ignore_port[i] && !DS_stuck) portRarb[i] = LEGACY_REQUEST; // pass in-phase legacy requests to arb state machine else ; // ignore out-of-phase requests } else { // LEGACY_PHASE legacy_request_phase = portCurrent.data; // update phase legacy_phase_expected = FALSE; } break; case ARB_REQUEST: receive_req[i] = portCurrent.req; portRarb[i] = IDLE; // ARB_STATE is IDLE when ARB REQUESTS are received if (in_packet[i]) { // sudden end of packet next_arb[i] = TRUE; packet_ending[i] = TRUE; } break; Copyright © 2002 IEEE. All rights reserved.

337

IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) case ARB_STATE: if (portCurrent.arb == SPEED) { if (!Beta_mode[i] && !(PHY_state == S4 || // filter out speeds received at PHY_state == S2 || PHY_state == S3 || // inappropriate times on DS ports PHY_state == A0 || PHY_state == A1 || PHY_state == A2 || PHY_state == RX )) break; // from dealing with current FIFO item portRspeed[i] = portCurrent.speed; if (!Beta_mode[i] && (PHY_state == S2 || PHY_state == S3 || PHY_state == S4)) { break; // DS mode speed exchanges - don’t treat as start of packet } current_pkt[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: receive_req[i].async = A_NONE; // forget the latest received arb state receive_req[i].isoch = I_NONE; if (ignore_port[i]) { // dealing with a collision collision[i] = TRUE; break; } if (!in_packet[i]) in_packet[i] = TRUE; // throttle the FIFO else next_arb[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 (ignore_port[i]) { // dealing with a collision collision[i] = TRUE; break; } if (in_packet[i]) { next_arb[i] = TRUE; packet_ending[i] = TRUE; } break; case DATA_END: if (ignore_port[i]) { // dealing with a collision collision[i] = TRUE; packet_ending[i] = TRUE; break; } next_arb[i] = TRUE; packet_ending[i] = TRUE; break; case IDLE: // may also cause sudden packet termination case BUS_RESET: case ARB_CONTEXT: receive_req[i].async = A_NONE; // forget the latest received arb state receive_req[i].isoch = I_NONE; if (in_packet[i]) { next_arb[i] = TRUE; packet_ending[i] = TRUE; portRspeed[i] = S100; // and erase memory of speed signal } break; case ASYNC_EVEN:

338


IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) case ASYNC_ODD: if (ignore_port[i]) { collision[i] = TRUE; break; } if (in_packet[i]) { next_arb[i] = TRUE; } break;

// dealing with a collision

} if (!ignore_port[i]) portRarb[i] = portCurrent.arb; // set the current arb state break; // finished dealing with ARB states case DATA: if (ignore_port[i]) { // dealing with a collision collision[i] = TRUE; break; } current_data[i] = portCurrent.data; portRarb[i] = DATA_BYTE; next_arb[i] = TRUE; portRspeed[i] = S100; // and erase memory of speed signal break; } // end of dealing with the latest in the fifo } } //combine best async and isoch request from other ports and own request if (active[i] && Beta_mode[i]){ best_req.async = own_req.async; // prefer link first best_req.isoch = own_req.isoch; apm = (odd_async_phase ? 0xf0 : 0x0f); // select async priority mask ipm = (odd_isoch_phase ? 0xf0 : 0x0f); // select isoch priority mask bip = bap = NPORT; for (j = 0; j < NPORT; j++) { // then prefer junior ports if (j != i && (j != senior_port)) { // careful to avoid requests on a restoring port best_req.async = active[j] && Beta_mode[j] && ((receive_req[j].async & apm) > (best_req.async & apm)) ? receive_req[bap = j].async : best_req.async; best_req.isoch = active[j] && Beta_mode[j] && ((receive_req[j].isoch & ipm) > (best_req.isoch & ipm)) ? receive_req[bip = j].isoch : best_req.isoch; } } if (!proxy_root && (i != senior_port)) { // finally prefer senior port on other ports best_req.async = active[senior_port] && Beta_mode[senior_port] && ((receive_req[senior_port].async & apm) > (best_req.async & apm)) ? receive_req[bap = senior_port].async : best_req.async; best_req.isoch = active[senior_port] && Beta_mode[senior_port] && ((receive_req[senior_port].isoch & ipm) > (best_req.isoch & ipm)) ? receive_req[bip = senior_port].isoch : best_req.isoch; } arbreqT[i] = best_req; //different for each port if (senior_border && (i == senior_port)) { // need to convert to Legacy and pass any // request up to DS parent isoch_pending = ((iso_cycle && ((best_req.isoch & ipm) >= (ISOCH_IN_PHASE & ipm))) || (!iso_cycle && ((best_req.isoch & ipm) == (ISOCH_CURRENT & ipm)))); async_pending = (!iso_cycle && ((best_req.async & apm) >= (CURRENT & apm))); pending_port = isoch_pending ? bip: bap; // pending_port is meaningless unless either // isoch_pending or async_pending is TRUE } } } Copyright © 2002 IEEE. All rights reserved.

339

IEEE Std 1394b-2002


Figure 19-18—Background request processing (continued) if (!senior_border || B_node_root) // if no longer a senior border in a junior cloud // clear pending flags used by arb_permitted isoch_pending = async_pending = FALSE; } boolean gap_token(int port) { // check for a new boolean found_new_token = FALSE; if (portRarb[port] == ASYNC_ODD) { if (!odd_async_phase) { found_new_token = TRUE; arb_reset = TRUE; did_arbrst = TRUE; // After repeating // advancements in } else if (!filter_async_odd) { found_new_token = TRUE; send_async_start_token = TRUE; } odd_async_phase = TRUE; filter_async_odd = TRUE; filter_async_even = FALSE; } else if (portRarb[port] == ASYNC_EVEN) { if (odd_async_phase) { found_new_token = TRUE; arb_reset = TRUE; did_arbrst = TRUE; // After repeating // advancements in } else if (!filter_async_even) { found_new_token = TRUE; send_async_start_token = TRUE; } odd_async_phase = FALSE; filter_async_odd = FALSE; filter_async_even = TRUE; } else { filter_async_odd = FALSE; filter_async_even = FALSE; } return (found_new_token); }

340

gap token on the specified port

an arb reset token, disallow further phase a B bus until non IDLE traffic occurs

an arb reset token, disallow further phase a B bus until non IDLE traffic occurs


IEEE Std 1394b-2002


19.4.3 Bus reset Figure 19-19—Bus reset actions // reset.c #include #include #include #include #include

“1394.h” “data_structures.h” “phy_services.h” “arb.h” “shared.h”

void arb_power_reset() { arb_reset = FALSE; accelerating = TRUE; initiated_reset = TRUE; reset_duration = RESET_TIME; loop_to_detect = FALSE; bus_initialize_active = FALSE; restore_request = FALSE; immediate_phy_request = immediate_restore_request = FALSE; time_out_of_idle = 0; // misc registers in the PHY reg map gap_count_reset_disable = ibr = isbr = loop = Timeout = FALSE; while (power_reset) ; PH_EVENT_indication(PH_LINK_ON, 0, 0); // only for power classes 0-4 // for a min of 166 us (16384 PClk cycles). // see Clause 14.4 for full requirements } boolean reset_detected() { // Qualify BUS_RESET with port status / history int i; if ( PHY_state == R0 || PHY_state == R1 // Ignore during (or just before) reset... || isbr_OK || phy_response) // ...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 ((Beta_mode[i] || bias[i]) && (portRarb[i] == BUS_RESET)) if (active[i]) { reset_duration = (PHY_state == RX) ? SHORT_RESET_TIME : RESET_TIME; return(TRUE); } else if (resume[i] && OK_to_detect_reset && !bus_initialize_active) { resumption_done = TRUE; reset_duration = (boundary_node) ? RESET_TIME : SHORT_RESET_TIME; return(TRUE); } else if (attach[i] && ((NPORT==1) || ((i == test_port) && send_attach))) { reset_duration = SHORT_RESET_TIME; // Found a reset returned in response to // an ATTACH_REQUEST issued, 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 return(TRUE); } return(FALSE); } void reset_start_actions() { int i; if (!bus_initialize_active) { bus_initialize_active = TRUE; if (gap_count_reset_disable) Copyright © 2002 IEEE. All rights reserved.

// Transmit BUS_RESET for reset_duration on all ports

// First reset since setting gap_count?

341

IEEE Std 1394b-2002


Figure 19-19—Bus reset actions (continued) gap_count_reset_disable = FALSE; else gap_count = 0x3F; } if (isolated_node) force_root = FALSE;

// If so, leave it as is and arm it for next // Otherwise, set it to the maximum

// No point in waiting to become root if isolated

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 cancel_requests(); odd_isoch_phase = FALSE; odd_async_phase = FALSE; iso_cycle = FALSE; did_arbrst = FALSE; // note that arb_enable is NOT reset (just like Legacy standards) OK_to_grant = defer_grant = grant_self = FALSE; B_bus = TRUE; root = FALSE; senior_border = FALSE;

// initially an isolated node!

receive_port = NPORT+1; link_concatenation = FALSE; send_null_packet = FALSE; DS_stuck = FALSE;

// not receiving, not transmitting

ibr = isbr = isbr_OK = FALSE; // Don’t replicate resets! phy_response = ping_response = FALSE; // Invalidate stale information arb_timer = 0; // not important, just good practice T0_timeout = FALSE; children = physical_ID = 0; SID_complete = FALSE; max_Legacy_path_speed = (link == Legacy_Link) ? S400: S100; if (!loop_to_detect) { // loop timout detect, while its true, look for // config timeout, arb_state timeout, more than 2 resets // or loss of sync on a port loop_to_detect = TRUE; // set false once node gets to S1 or S2 reset_count = 0; // count the resets that never make it that far } else reset_count++; need_new_LTP = TRUE; HR_G = 0; // value not important HR_mode = LTP_TEST; in_control = FALSE; legacy_request_phase = 0; // reset phase for (i = 0; i < NPORT; i++) { // check for untested ports if (loop_disabled[i]) loop_disabled[i] = FALSE; child[i] = FALSE; child_ID_complete[i] = FALSE; if (!Beta_mode[i] && (active[i] || (resume[i] && resumption_done))) port_speed[i] = S100; // Reset default speed for all active or resuming DS ports } for (i = 0; i < NPORT; i++) { if (Beta_mode[i]) { reset_notify[i] = TRUE; // have to notify all stood-by ports that a reset has occurred } if (!Beta_mode[i] || (portRarb[i] != BUS_RESET) || (reset_duration == RESET_TIME)) { // don’t propagate back if receiving a short BUS_RESET portTarb(i, BUS_RESET); // propagate on active ports, if ((resume[i] && resumption_done) || attach[i]) { portT[i].arb = BUS_RESET; // Also propagate on resuming or attaching ports portT[i].speed = DEFAULT;

342


IEEE Std 1394b-2002


Figure 19-19—Bus reset actions (continued) 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] && resumption_done) || attach[i]) { portT[i].arb = IDLE; // Also propagate on resuming or attaching ports portT[i].speed = DEFAULT; portT[i].tag = ARB_STATE; } } } } void reset_wait_actions() { // Transmit IDLE int i; for (i = 0; i < NPORT; i++) { portTarb(i, IDLE); if ((resume[i] && resumption_done) || attach[i]) { portT[i].arb = IDLE; // Also propagate on resuming or attaching ports portT[i].speed = DEFAULT; portT[i].tag = ARB_STATE; } } arb_timer = 0; // Restart timer } boolean reset_complete() { // TRUE when all ports idle or in tree-ID int i; for (i = 0; i < NPORT; i ++) { if (active[i]) if ((portRarb[i] != IDLE) && (portRarb[i] != PARENT_NOTIFY)) return(FALSE); } return(TRUE); // Transition to tree identify }


343

IEEE Std 1394b-2002


19.4.4 Tree identification Figure 19-20—Tree identify actions // treeid.c #include #include #include #include #include


void tree_ID_start_actions() { int i; 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 && (!force_root || arb_timer >= FORCE_ROOT_TIMEOUT)) return; // Only one port left as the parent else if (children == NPORT) return; // node is the root } while (!(reset_detected() || ibr || isbr|| (!T0_timeout && (arb_timer == CONFIG_TIMEOUT)))); } void child_handshake_actions() { int i; senior_port = parent_port = NPORT+1; proxy_root = root = TRUE; for (i = 0; i < NPORT; i++) if (active[i]) if (child[i]) portTarb(i, CHILD_NOTIFY); else { portTarb(i, PARENT_NOTIFY); senior_port = parent_port = i; proxy_root = root = FALSE; } }

// 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” // Ask peer PHY, “Please be my parent” // Only one parent port possible // Tentative---see root contention

boolean child_handshake_complete() { // 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); // One as yet uncompleted handshake... return(TRUE); // All child ports have finished their handshakes } void root_contend_actions() { int i; contend_time = (random_bool() ? ROOT_CONTEND_SLOW : ROOT_CONTEND_FAST); 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 arb_timer = 0; // Restart arbitration timer }

344


IEEE Std 1394b-2002


19.4.5 Self-identification Figure 19-21—Self-identify actions // selfid.c #include #include #include #include #include


void self_ID_start_actions() { int i; all_child_ports_identified = TRUE; concatenated_packet = FALSE; arb_timer = 0;

// Will be reset if any active children are unidentified // Prepare in case of multiple self_ID packets

// ensure that MIN_IDLE_TIME is preserved wait_Legacy_time(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 { portTarb(i, IDLE); // Allow parent to finish if (child[i] && (active[i] || proxy[i])) { if (all_child_ports_identified) lowest_unidentified_child = i; all_child_ports_identified = FALSE; } } } void self_ID_grant_actions() { int i; int SID_pkt_number; int port_stat; int port_number = 0; PHY_PKT self_ID; loop_to_detect = FALSE; // no longer looking for loop timeout detect conditions, reset_count = 0; // so clear all loop indications T0_timeout = FALSE; for (i = 0; i < NPORT; i++) { if (!all_child_ports_identified && (i == lowest_unidentified_child)) { 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 (!all_child_ports_identified && proxy[lowest_unidentified_child]) { 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_pkt_number = 0; SID_pkt_number < standby_packet_count[lowest_unidentified_child]; SID_pkt_number++) { start_tx_packet(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.phy_pktType = 0b10; self_ID.phy_ID = physical_ID; standby_phy_ID[lowest_unidentified_child] = physical_ID; // and remember the new PHY_ID if (SID_pkt_number == 0) { // First self-ID packet? self_ID.L = standby_L[lowest_unidentified_child]; // Link active or not? self_ID.gap_cnt = gap_count; Copyright © 2002 IEEE. All rights reserved.

345

IEEE Std 1394b-2002


Figure 19-21—Self-identify actions (continued) self_ID.sp = 0b11; // “PHY_SPEED” always “11” (unlike Legacy) self_ID.c = standby_c[lowest_unidentified_child]; self_ID.pwr = standby_pwr[lowest_unidentified_child]; } else { self_ID.ext = 1; // Indicates second and subsequent packets self_ID.n = SID_pkt_number - 1; // Sequence number } port_stat = 0; // Initialize for fresh group of ports while (port_number < ((SID_pkt_number + 1) * 8 - 5)) { // Concatenate port status if (port_number >= standby_NPORT[lowest_unidentified_child]) ; // Unimplemented else if (standby_parent[lowest_unidentified_child] == port_number) port_stat |= 0b10; // Active parent else port_stat |= 0b01; // Disabled, disconnected or suspended port_number++; port_stat (((SID_pkt_number +1)*8 -5 -port_number)*2)) & 0b11; if (port_stat == 0b10) standby_parent[receive_port] = port_number; // TRUE exactly once port_number++; if (port_stat != 0b00) standby_NPORT[receive_port] = port_number; // eventually save the highest value } } else good_self_ID_sequence = FALSE; SID_pkt_number++; } while (concatenated_packet); standby_packet_count[receive_port] = SID_pkt_number; if (!good_self_ID_sequence) { // construct substitute self_ID information for uncle to remember standby_phy_ID[receive_port] = 63; standby_parent[receive_port] = 0; standby_NPORT[receive_port] = 1; standby_packet_count[receive_port] = 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_transmit_actions() { int i; int last_SID_pkt = (NPORT + 4) / 8; int SID_pkt_number; int port_number = 0; PHY_PKT self_ID; int port_stat;

// Packet number counter // Port number counter

arb_timer = 0; receive_port = 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 (!ping_response) { // set B_node_root 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) { B_node_root = FALSE; B_bus = FALSE; proxy_root = TRUE; // Assume this node to be senior_border and senior_border = TRUE; // proxy_root, may change later senior_port = NPORT+1; } else B_node_root = TRUE; // 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_pkt_number = 0; SID_pkt_number = NPORT) ; // Unimplemented else if (!active[port_number] && !proxy[port_number]) port_stat |= 0b01; // Disabled, disconnected or suspended else if (child[port_number]) port_stat |= 0b11; // Active child else port_stat |= 0b10; // Active parent port_number++; port_stat S100 packet (!B_bus && (cur_format == LEGACY) && (cur_speed != S100) && (next_format == BETA || next_speed == 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 next_format = LEGACY; next_speed = S100; grant_con_mgmnt = FALSE; phy_originated_pkt = TRUE;

} immediate_phy_request = FALSE; resolve_collision_request = FALSE; send_null_packet = FALSE; if (grant_con_mgmnt) { // selected packet requires connection management service con_mgmnt_granted(); end_of_packet = TRUE; } else { // Begin packet transmission by informing the link as required and by preparing // the Serial Bus with the selected packet prefix if (phy_originated_pkt) { // PHY originated packet, prepare to repeat to link 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 } start_tx_packet(next_speed, next_format, link_grant == PH_WON_CYCLE_START); // Send data prefix & speed signal if (isbr_OK) { ; // note, end_of_packet not set to ensure mutual exclusion on exit } else if (phy_originated_pkt) { // Empty packet, usually requested by boss in order to clean up DATA_PREFIX on

356


IEEE Std 1394b-2002


Figure 19-24—Transmit actions (continued) // DS ports after sending a series of Beta format packets PH_DATA_indication(PH_DATA_END, 0, 0, 0); boss_end_packet_actions(FALSE, DATA_END); // check for isoch to do end_of_packet = 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 // Clause 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? arb_enable = FALSE; // Yes, clear permission (set again on next reset gap) breq = NO_REQ; immediate_link_request = FALSE; link_concatenation = FALSE; } else { // not a Legacy_Link PH_ARB_confirmation(link_grant, cur_speed, link_format); switch (link_grant) { case PH_WON_IMMED: immediate_link_request = FALSE; break; case PH_WON_ISOCH: isoch_odd_request = isoch_even_request = FALSE; break; case PH_WON_CYCLE_START: cycle_start_request = FALSE; break; case PH_WON_ASYNC: current_request = next_odd_request = next_even_request = FALSE; break; } } while (!end_of_packet) { do { // Wait for data or release from the link PH_CLOCK_indication(); data_to_transmit = waitPH_DATA_request(); } while (data_to_transmit.reqType == PH_REQ_HOLD); // Hold only valid before data starts if (data_to_transmit.reqType == PH_REQ_DATA) { tx_byte(data_to_transmit.data); // Send DATA on all ports if (byte_count < 8) // Accumulate possible PHY packet tx_phy_pkt.dataBytes[byte_count] = data_to_transmit.data; byte_count++; ack = (byte_count == 1); // For acceleration, any 8 bit packet is an ack } else if (data_to_transmit.reqType == PH_REQ_DATA_PREFIX) { // concatenated packets from Legacy link end_of_packet = link_concatenation = TRUE; // End of packet indicator grant_self = TRUE; // Force TX:TX transition stop_tx_packet(DATA_NULL, NPORT); // MIN_PACKET_SEPARATION req_speed = data_to_transmit.speed; } else { if (iso_cycle) // Implicit or explicit subaction end grant_type = GRANT_ISOCH; else if (ack || (data_to_transmit.reqType == PH_REQ_SUBACTION_END)) // acknowledge packet can always be grant_type = GRANT; // converted to an explicit asynchronous grant else grant_type = DATA_END; // quiet grant boss_end_packet_actions(FALSE, grant_type); end_of_packet = TRUE; // End of packet indicator } } } } if (!phy_originated_pkt && (byte_count == 8) && (tx_phy_pkt.dataQuadlet == ~tx_phy_pkt.checkQuadlet)) // Check PHY packet for good format decode_phy_packet(tx_phy_pkt); // Parse valid phy packets transmitted by the link if (!grant_self) cur_speed = S100; // for the case of transit to A2 and thence to RX } Copyright © 2002 IEEE. All rights reserved.

357

IEEE Std 1394b-2002


Figure 19-25—Receive actions // receive_actions.c #include #include #include #include #include


void receive_actions() { int byte_count = 0, i; PHY_PKT rx_phy_pkt; boolean end_of_data = FALSE; ArbState rx_arb_state; ack = concatenated_packet = isbr_OK = fly_by_OK = FALSE; requesting_port = NPORT; for (i = 0; i < NPORT; i++) collision[i] = FALSE;

// may be set true again immediately if collision // condition persists

resolve_collision_request = FALSE; if (!enab_accel) { 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 start_rx_packet(&rx_arb_state);

// Start up receiver and repeater and repeat data prefix // requests on receive_port

if (rx_arb_state == DATA_BYTE) { if ((link != Legacy_Link) || (cur_format == LEGACY)) // Filter Beta formats from Legacy link PH_DATA_indication(PH_DATA_START, cur_speed, 0, cur_format); // Send speed indication } do { if (rx_arb_state == DATA_BYTE) { //get data byte and repeat out other ports if ((link != Legacy_Link) || (cur_format == LEGACY)) // Filter Beta formats from Legacy link PH_DATA_indication(PH_DATA_BYTE, 0, current_data[receive_port], 0); tx_byte(current_data[receive_port]); if (byte_count < 8) // Accumulate first 8 bytes rx_phy_pkt.dataBytes[byte_count] = current_data[receive_port]; byte_count++; ack = (byte_count == 1); // For acceleration, any 8 bit packet is an ack if ((cur_format == LEGACY) && (byte_count > 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 (fifo_rd_ptr[receive_port] == fifo_wr_ptr[receive_port]) { // FIFO underrun // - just emptied the FIFO, and a new byte has not come in!! end_of_data = TRUE; rx_arb_state = IDLE; // assume packet_ending[receive_port] = TRUE; // inform process_requests() that packet has concluded next_arb[receive_port] = FALSE; // and let the FIFO advance eagerly

358


IEEE Std 1394b-2002


Figure 19-25—Receive actions (continued) advance_OK[receive_port] = TRUE; } else rx_arb_state=portR_next_arb(receive_port); } else end_of_data = TRUE; } while (!end_of_data); if ((cur_format == 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 (rx_arb_state) { case DATA_PREFIX: case DATA_NULL: concatenated_packet = TRUE; if ((link != Legacy_Link) || (cur_format == LEGACY)) // Don’t send redundant indication if PH_DATA_indication(PH_DATA_PREFIX, 0, 0, 0); // Legacy link is already in DATA_PREFIX stop_tx_packet(rx_arb_state, NPORT); break; case GRANT: case GRANT_ISOCH: case DATA_END: if ((link != Legacy_Link) || (cur_format == 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 fly_by_OK = (cur_format == LEGACY) && fly_by_permitted(); if (fly_by_OK) { grant_to_give = (breq == ISOCH_REQ ? GRANT_ISOCH : GRANT); stop_tx_packet(grant_to_give, NPORT); } else { if (ack && (receive_port != senior_port)) rx_arb_state = GRANT; // acknowledge packet from a junior port can always be // converted to an explicit asynchronous grant if ((rx_arb_state == GRANT) || (rx_arb_state == GRANT_ISOCH) || // explicit grants ((rx_arb_state == DATA_END) && (receive_port != senior_port))) // implicit grant boss_end_packet_actions(receive_port == senior_port, rx_arb_state); else // not BOSS, repeat end of packet normally stop_tx_packet(DATA_END, NPORT); } break; case BUS_RESET: PH_DATA_indication(PH_DATA_END, 0, 0, 0); stop_tx_packet(BUS_RESET, NPORT); break; case IDLE: // DP directly to IDLE from a Legacy PHY case ARB_CONTEXT: if ((link != Legacy_Link) || (cur_format == LEGACY)) // Filter Beta formats from Legacy link PH_DATA_indication(PH_DATA_END, 0, 0, 0); // clean up for the link if (non_null_packet) { // Unexpected end of data... stop_tx_packet(DATA_END, NPORT); // and try to clean up gracefully } else if (format_committed) // Already in packet context? stop_tx_packet(ARB_CONTEXT, NPORT); // If so, set arb context before heading to IDLE else stop_tx_packet(IDLE, NPORT); ack = FALSE; // Disable fly-by acceleration break; default: // Unexpected end of data... if ((link != Legacy_Link) || (cur_format == LEGACY)) // Filter Beta formats from Legacy link PH_DATA_indication(PH_DATA_END, 0, 0, 0); // clean up for the link non_null_packet = FALSE; // With unexpected end of data, don’t add dribble bits stop_tx_packet(DATA_END, NPORT); // and try to clean up gracefully Copyright © 2002 IEEE. All rights reserved.

359

IEEE Std 1394b-2002


Figure 19-25—Receive actions (continued) ack = FALSE; break;

// Disable fly-by acceleration

} good_phy_packet = FALSE; if (byte_count == 8) { if (rx_phy_pkt.dataQuadlet == ~rx_phy_pkt.checkQuadlet) { // Check PHY packet for good format decode_phy_packet(rx_phy_pkt); // Parse valid phy packets good_phy_packet = TRUE; } } else { HR_mode = LTP_TEST; // for all non-PHY packets } if (!concatenated_packet) cur_speed = S100; // remember current speed for // concatenated (Legacy) packets }

360



IEEE Std 1394b-2002

Annex K (informative)

Serial Bus cable test procedures Insert the following after K.3.3 in IEEE Std 1394-1995, as amended by IEEE Std 1394a-2000:

K.3 Signal pair characteristic and discrete impedance K.3.4 IEEE 1394 bulk Serial Bus cable test methodology K.3.4.1 Equipment a) b) c)

Tektronix 11802 differential TDR with SD24 sampling head or equivalent Adapters: Tektronix SIU 800 static isolation unit or equivalent 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 specification, the results of the tests in K.3.4.3 should be in accordance with 4.2.1B.4.2.

K.4 Signal pairs attenuation Insert the following after K.4.4 in IEEE Std 1394-1995:

K.4.5 IEEE 1394 bulk Serial Bus cable test methodology K.4.5.1 Equipment a) b) c)

Wiltron 610 network analyzer or equivalent Adapters: two 180° differential pulse splitters Four matching pads and four 150 mm lengths of 50 Ω RG405 cable terminated with a quick-release dip socket


361

IEEE Std 1394b-2002


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 specification, the results of the tests in K.4.5.3 should be in accordance with 4.2.1B.4.3.

K.5 Signal pairs velocity of propagation Insert the following after K.5.4 in IEEE Std 1394-1995:

K.5.5 IEEE 1394 bulk Serial Bus cable test methodology (TDR) K.5.5.1 Equipment a) b) c)

Tektronix 11802 differential TDR with SD24 sampling head or equivalent Adapters: Tektronix SIU 800 static isolation unit or equivalent 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 specification, the results of the tests in K.5.5.3 should be in accordance with 4.2.1B.4.4 and 4.2.1B.4.6.

K.5.6 IEEE 1394 bulk Serial Bus cable test methodology (frequency sweep) K.5.6.1 Equipment a) b) c) 362

Wiltron 610 network analyzer or equivalent Adapters: two 180° differential pulse splitters Four matching pads and four 150 mm lengths of 50 Ω RG405 cable terminated with a quick-release dip socket Copyright © 2002 IEEE. All rights reserved.


IEEE Std 1394b-2002

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 specification, the results of the tests in K.5.6.3 should be in accordance with 4.2.1B.4.4.

K.5.7 Rise and fall time Bulk cable test methodology. K.5.7.1 Equipment a) b) c)

Tektronix 11801 differential TDR with SD24 sampling head or equivalent Hewlett Packard HP 8133A pulse generator or equivalent 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. K.5.7.4 Results To comply with this specification, the results of the tests in K.5.7.3 should be in accordance with 4.2.1B.4.5.

K.5.8 Static shield isolation (insulation resistance) Bulk cable test methodology.


363

IEEE Std 1394b-2002


K.5.8.1 Equipment a) b)

Quad Tech 1865 insulation resistance tester or equivalent 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 specification, the results of the tests in K.5.8.3 should be in accordance with 4.2.1B.4.

364



IEEE Std 1394b-2002

Insert the following in IEEE Std 1394-1995 after Annex N, which was added by IEEE Std 1394a-2000:

Annex O (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.

O.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 O.2 through O.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 1394b 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 O.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).

O.2 Random pattern (SB_RPAT) Unlike Fibre Channel, IEEE Std 1394b-2002 has an excellent built-in random pattern generator in the form of the 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 time interval analysis analyzer (TIA) should be primed to capture each packet.

O.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 the time constants of the PLL. For the Fibre Channel jitter tolerance pattern, the following assumptions were made:


365

IEEE Std 1394b-2002

— — — —


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 IEEE Std 1394b-2002, 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.

O.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.

366



IEEE Std 1394b-2002

Annex P (informative)

Connection status change The design of the algorithm that is used during disconnection and during suspend to detect a change in port status is based on the following fundamental properties of TpBias, toning, and the connect detect circuitry, given with the reasoning on each property: a)

b)

c)

d)

e)

f)

A port cannot tone and drive TpBias simultaneously. Legacy PHYs would attempt to interpret the tone if TpBias were present. The only safe way to tone into a Legacy port is when TpBias is deasserted. A port cannot wait for the remote port on the peer PHY to initiate TpBias. A Legacy node with a suspended port will not initiate TpBias as long as the dc connection status is continually active. Consider a Legacy 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 Legacy node. If the eager Beta algorithm waited for the Legacy 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. A port cannot assume that the initial receipt of TpBias means a Legacy 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 a Legacy 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. 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., RJ45 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. A port cannot listen for a tone when generating TpBias. When generating TpBias, the remote node may be an IEEE 1394 node (or indeed an IEEE 1394a node). 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. 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 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


367

IEEE Std 1394b-2002


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 behavior of the dc connect detect comparator, as defined in IEEE Std 1394a-2000, 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)

368

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.



IEEE Std 1394b-2002

Annex Q (informative)

Bibliography [B1] ITU-T G.957-1999, 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. [B2] Widmer, A. X., and Franaszek, P. A., IBM Journal of Research and Development, vol. 27, no. 5, p. 440, Sept. 1983.


369

Standard Ieee 1394 Firewire

IEEE Std 1394 -2008 Standard for a High-Performance Serial Bus (FireWire)

FireWire (R) System Architecture: IEEE 1394A

Улугбек. 1394-1449

ieee

IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation

IEEE Standard Glossary of Data Management Terminology (Ansi)

IEEE Standard for a High Performance Serial Bus

Norma ANSI IEEE Std 4 1978 An American National Standard IEEE Standard Techniques for High-Voltage Testing

IEEE Std 1028-2008 Standard for Software Reviews and Audits

Emerging Wireless LANs, Wireless PANs, and Wireless MANs: IEEE 802.11, IEEE 802.15, 802.16 Wireless Standard Family

Ieee Std c57.12.70-2000 (Ieee Standard Terminal Markings And Connections For Distribution And Power Transformers)

IEEE Guide for Measurement of Environmental Sensitivities of Standard Frequency Generators. IEEE Std 1193 - 2003

IEEE standard for radix-independent floating-point arithmetic

1076-2008 IEEE Standard VHDL. Language Reference Manual

IEEE Standard Glossary Of Modeling And Simulation Terminology

1076-2002 IEEE Standard VHDL Language Reference Manual

1850-2010 IEEE Standard for Property Specification Language (PSL)

1076-2000 IEEE Standard VHDL Language Reference Manual

IEEE-802.11a

IEEE Wireless Dictionary (IEEE Standards Wireless Networks)

Шины PCI, USB и FireWire. Энциклопедия

Liaden 1394 - Lord of the Dance

Jtag (Ieee Std-1149.1)

IEEE Trial Use Standard for Application and Management of the Systems Engineering Process (IEEE Std 1220 1994)

Standard Candles

Double Standard

Standard Codecs

Standard Chemistry

Standard Candles

IEEE 802.15.4 y ZIGBEE

Standard Ieee 1394 Firewire

IEEE Std 1394 -2008 Standard for a High-Performance Serial Bus (FireWire)

FireWire (R) System Architecture: IEEE 1394A

Улугбек. 1394-1449

ieee

IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation

IEEE Standard Glossary of Data Management Terminology (Ansi)

IEEE Standard for a High Performance Serial Bus

Norma ANSI IEEE Std 4 1978 An American National Standard IEEE Standard Techniques for High-Voltage Testing

IEEE Std 1028-2008 Standard for Software Reviews and Audits

Emerging Wireless LANs, Wireless PANs, and Wireless MANs: IEEE 802.11, IEEE 802.15, 802.16 Wireless Standard Family

Ieee Std c57.12.70-2000 (Ieee Standard Terminal Markings And Connections For Distribution And Power Transformers)

IEEE Guide for Measurement of Environmental Sensitivities of Standard Frequency Generators. IEEE Std 1193 - 2003

IEEE standard for radix-independent floating-point arithmetic

1076-2008 IEEE Standard VHDL. Language Reference Manual

IEEE Standard Glossary Of Modeling And Simulation Terminology

1076-2002 IEEE Standard VHDL Language Reference Manual

1850-2010 IEEE Standard for Property Specification Language (PSL)

1076-2000 IEEE Standard VHDL Language Reference Manual

IEEE-802.11a

IEEE Wireless Dictionary (IEEE Standards Wireless Networks)

Шины PCI, USB и FireWire. Энциклопедия

Liaden 1394 - Lord of the Dance

Jtag (Ieee Std-1149.1)

IEEE Trial Use Standard for Application and Management of the Systems Engineering Process (IEEE Std 1220 1994)

Standard Candles

Double Standard

Standard Codecs

Standard Chemistry

Standard Candles

IEEE 802.15.4 y ZIGBEE

Recommend Documents