Firewire System Architecture, Second Edition

world-class technical training

Are your company’s technical training needs being addressed in the most effective manner?

MindShare has over 25 years experience in conducting technical training on cutting-edge technologies. We understand the challenges companies have when searching for quality, effective training which reduces the students’ time away from work and provides cost-effective alternatives. MindShare offers many ﬂ exible solutions to meet those needs. Our courses are taught by highly-skilled, enthusiastic, knowledgeable and experienced instructors. We bring life to knowledge through a wide variety of learning methods and delivery options.

training that ﬁ ts your needs MindShare recognizes and addresses your company’s technical training issues with:

• Scalable cost training • Customizable training options • Reducing time away from work • Just-in-time training • Overview and advanced topic courses • Training delivered effectively globally • Training in a classroom, at your cubicle or home ofﬁ ce • Concurrently delivered multiple-site training

MindShare training courses expand your technical skillset

2 PCI Express 2.0 ® 2 Serial Attached SCSI (SAS) 2 Intel Core 2 Processor Architecture 2 DDR2/DDR3 DRAM Technology 2 AMD Opteron Processor Architecture 2 PC BIOS Firmware 2 Intel 64 and IA-32 Software Architecture 2 High-Speed Design 2 Intel PC and Chipset Architecture 2 Windows Internals and Drivers 2 PC Virtualization 2 Linux Fundamentals 2 USB 2.0 ... and many more. 2 Wireless USB All courses can be customized to meet your 2 Serial ATA (SATA) group’s needs. Detailed course outlines can be found at www.mindshare.com

bringing life to knowledge. real-world tech training put into practice worldwide

*PCI Express ® is a registered trademark of the PCISIG MindShare Learning Options

MindShare MindShare MindShare MindShare Classroom Virtual Classroom eLearning Press

Intro eLearning In-House Training Virtual In-House Training Books Modules

Comprehensive Public Training Virtual Public Training eLearning Modules eBooks

Classroom Training Virtual Classroom Training eLearning Module Training MindShare Press Invite MindShare to train The majority of our courses MindShare is also an eLearning Purchase our books and you in-house, or sign-up to live over the web in an inter- company. Our growing list of eBooks or publish your attend one of our many public active environment with WebEx interactive eLearning modules own content through us. classes held throughout the and a phone bridge. We deliver include: MindShare has authored year and around the world. training cost-effectively across • Intro to Virtualization over 25 books and the list No more boring classes, the multiple sites and time zones. Technology is growing. Let us help ‘MindShare Experience‘ is Imagine being trained in your • Intro to IO Virtualization make your book project sure to keep you engaged. cubicle or home ofﬁ ce and • Intro to PCI Express 2.0 a successful one. avoiding the hassle of travel. Updates Contact us to attend one of • PCI Express 2.0 our public virtual classes. • USB 2.0 • AMD Opteron Processor Architecture • Virtualization Technology ...and more

Engage MindShare Have knowledge that you want to bring to life? MindShare will work with you to “Bring Your Knowledge to Life.” Engage us to transform your knowledge and design courses that can be delivered in classroom or virtual classroom settings, create online eLearning modules, or publish a book that you author.

We are proud to be the preferred training provider at an extensive list of clients that include: ADAPTEC • AMD • AGILENT TECHNOLOGIES • APPLE • BROADCOM • CADENCE • CRAY • CISCO • DELL • FREESCALE GENERAL DYNAMICS • HP • IBM • KODAK • LSI LOGIC • MOTOROLA • MICROSOFT • NASA • NATIONAL SEMICONDUCTOR NETAPP • NOKIA • NVIDIA • PLX TECHNOLOGY • QLOGIC • SIEMENS • SUN MICROSYSTEMS SYNOPSYS • TI • UNISYS

4285 SLASH PINE DRIVE COLORADO SPRINGS, CO 80908 USA M 1.602.617.1123 O 1.800.633.1440 [email protected] www.mindshare.com FireWire® System Architecture, Second Edition Firewire® System Architecture, Second Edition IEEE 1394a MINDSHARE, INC.

Don Anderson

ADDISON-WESLEY

Reading, Massachusetts • Menlo Park, California • New York Don Mills, Ontario • Harlow, England • Amsterdam Bonn • Sydney • Singapore • Tokyo • Madrid • San Juan Paris • Seoul • Milan • Mexico City • Taipei Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designators appear in this book, and Addi- son-Wesley was aware of the trademark claim, the designations have been printed in initial capital letters or all capital letters.

The authors and publisher have taken care in preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for special sales.

For more information, please contact: Corporate, Government and Special Sales Group Addison Wesley Longman, Inc. One Jacob Way Reading, Massachusetts 01867 (781) 944-3700

Library of Congress Cataloging-in-Publication Data

Anderson, Don, 1953- FireWire systems architecture: IEEE 1394a / MindShare, Inc.; Don Anderson. — 2nd ed. p. cm. Includes bibliographical references and index. ISBN 0-201-48535-4 1. IEEE 1394 (Standard) I. MindShare, Inc. II. Title. TK7895.B87 A52 1998 621.39’81 — dc21 98-43465 CIP

ISBN: 0-201-48535-4 Copyright ©1999 by MindShare, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy- ing, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Published simultaneously in Canada.

Sponsoring Editor: Karen Gettman Production Coordinator: Jacquelyn Young Set in 10 point Palatino by MindShare, Inc.

1 2 3 4 5 6 7 8 9-MA-0201009998 First Printing, December 1998 Contents

About This Book The MindShare Architecture Series ...... 1 Cautionary Note ...... 2 Organization of This Book...... 2 Part One: Introduction to FireWire (IEEE 1394) ...... 2 Chapter 1: Why FireWire? ...... 2 Chapter 2: Overview of the FireWire Architecture...... 2 Part Two: Serial Bus Communications ...... 3 Chapter 3: Communication Model...... 3 Chapter 4: Communications Services ...... 3 Chapter 5: Cables & Connectors...... 3 Chapter 6: The Electrical Interface ...... 3 Chapter 7: Arbitration...... 3 Chapter 8: Asynchronous Packets...... 3 Chapter 9: Isochronous Packets...... 3 Chapter 10: PHY Packet Format...... 4 Chapter 11: Link to PHY Interface ...... 4 Chapter 12: Transaction Retry ...... 4 Part Three: Serial Bus Configuration ...... 4 Chapter 13: Configuration Process...... 4 Chapter 14: Bus Reset (Initialization)...... 4 Chapter 15: Tree Identification ...... 4 Chapter 16: Self Identification...... 4 Part Four: Serial Bus Management...... 5 Chapter 17: Cycle Master...... 5 Chapter 18: Isochronous Resource Manager ...... 5 Chapter 19: Bus Manager...... 5 Chapter 20: Bus Management Services...... 5 Part Five: Registers and Configuration ROM ...... 5 Chapter 21: CSR Architecture ...... 5 Chapter 22: PHY Registers ...... 5 Chapter 23: Configuration ROM ...... 5 Part Six: Power Management ...... 6 Chapter 24: Introduction to Power Management ...... 6 Chapter 25: Cable Power Distribution...... 6 Chapter 26: Suspend & Resume ...... 6 Chapter 27: Power State Management...... 6 Appendix...... 6 Example 1394 Chip Solutions ...... 6 Target Audience ...... 7 Prerequisite Knowledge ...... 7

vii Contents

Documentation Conventions...... 7 Labels for Multi-byte Blocks...... 7 Hexadecimal Notation ...... 8 Binary Notation...... 8 Decimal Notation ...... 8 Bit Versus Byte Notation...... 9 Identification of Bit Fields (logical groups of bits or signals) ...... 9 Visit Our Web Page ...... 10 We Want Your Feedback...... 10

Part One Introduction to FireWire (IEEE 1394a)

Chapter 1: Why FireWire? Overview...... 13 Motivations Behind FireWire Development ...... 13 Inexpensive Alternate to Parallel Buses ...... 14 Plug and Play Support ...... 14 Eliminate Host Processor/Memory Bottleneck...... 14 High Speed Bus with Scalable Performance ...... 15 Support for Isochronous Applications...... 15 BackPlane and Cable Environments ...... 15 Bus Bridge ...... 15 1394 Applications ...... 16 IEEE 1394 Refinements ...... 16 Primary Features...... 17

Chapter 2: Overview of the IEEE 1394 Architecture IEEE 1394 Overview...... 19 Specifications and Related Documents ...... 20 IEEE 1394-1995 and the IEEE 1394a Supplement...... 20 IEEE 1394.B ...... 21 Unit Architecture Specifications ...... 21 IEEE 1394 Topology ...... 23 Multiport Nodes and Repeaters ...... 23 Configuration ...... 23 Peer-To-Peer Transfers...... 24 Device Bay...... 24

viii Contents

The ISO/IEC 13213 Specification ...... 24 Node Architecture ...... 25 Address Space ...... 28 Transfers and Transactions...... 30 Asynchronous Transfers...... 30 Isochronous Transfers...... 32 Control and Status Registers (CSRs) ...... 33 Configuration ROM...... 33 Message Broadcast...... 34 Interrupt Broadcast...... 34 Automatic Configuration...... 34

Part Two Serial Bus Communications

Chapter 3: Communications Model Overview...... 37 Transfer Types ...... 39 Asynchronous...... 40 Isochronous...... 41 The Protocol Layers ...... 42 Bus Management Layer ...... 44 Transaction Layer...... 45 Transaction Layer Services...... 45 Link Layer ...... 47 Split Transactions...... 49 Concatenated Transactions ...... 51 Unified Transactions ...... 52 Physical Layer...... 53 Twisted Pair Signaling ...... 54 Bus Configuration ...... 55 Arbitration ...... 55 Data Transmission...... 56 Power Pair...... 56 Packet-Based Transactions ...... 56 Asynchronous Packets...... 56 Isochronous Packet...... 58 Port Repeater ...... 59

ix Contents

A Sample Asynchronous Transaction...... 60 The Request...... 61 The Response...... 61 An Example Isochronous Transaction ...... 63

Chapter 4: Communications Services Overview...... 65 Anatomy of Asynchronous Transactions ...... 66 The Request Subaction ...... 66 Initiating the Transaction (The Request) ...... 69 Transaction Layer...... 69 The Link Layer...... 69 The PHY Layer...... 70 Receiving the Request (The Indication)...... 71 Physical Layer ...... 71 Link Layer ...... 71 Transaction Layer...... 72 The Acknowledgment ...... 72 Response Subaction ...... 73 Reporting the Results (The Response)...... 74 Transaction Layer Response...... 74 Link Layer Response...... 75 PHY Layer Response ...... 75 Response Reception...... 76 Physical Layer ...... 76 Link Layer ...... 76 Transaction Layer...... 77 The Acknowledgment ...... 77 Transaction Label...... 78 Anatomy of Isochronous Transactions ...... 78 Setting Up Isochronous Transactions ...... 79 Maintaining Synchronization...... 79 Isochronous Transactions ...... 80 Isochronous Transaction Initiation & Reception...... 80 Initiating the Transaction...... 81 Link Layer ...... 81 The PHY Layer...... 81 Transaction Reception...... 82 Physical Layer ...... 83 Link Layer ...... 83

x Contents

Chapter 5: Cables & Connectors Cable and Connector Types ...... 85 6-pin Connector (1394-1995)...... 86 Make First/Break Last Power Pins...... 87 Optional 4-pin Connector (1394a supplement) ...... 87 Positive Retention ...... 88 Cable Characteristics ...... 89 6-Conductor Cables ...... 89 4-Conductor Cables ...... 90 Device Bay ...... 92

Chapter 6: The Electrical Interface Overview...... 95 Common Mode Signaling...... 96 Differential Signaling ...... 96 Recognition of Device Attachment and Detachment...... 97 IEEE 1394-1995 Device Attachment/Detachment...... 97 IEEE 1394a Device Attachment/Detachment...... 99 Bus Idle State ...... 100 The Port Interface...... 101 Differential Signal Specifications ...... 104 Arbitration Signaling ...... 105 Line State Signaling (1, 0, and Z) ...... 105 Line State Detection...... 107 Reset Signaling...... 110 Line States During Configuration ...... 110 Line States During Normal Arbitration...... 112 Starting and Ending Packet Transmission...... 114 Dribble Bits...... 116 Port State Control ...... 116 Speed Signaling...... 117 High Speed Devices Slowed Due to Topology...... 118 Devices of Like Speed Directly Connected ...... 118 Speed Signaling Circuitry...... 119 Data/Strobe Signaling ...... 122 NRZ Encoding...... 123 Data-Strobe Encoding...... 124 Gap Timing ...... 125 Cable Interface Timing Constants ...... 128 Suspend/Resume...... 133

xi Contents

Cable Power ...... 133 Cable Power Requirements ...... 134 Power Class...... 135 Power Distribution ...... 137 Bus Powered Nodes...... 138

Chapter 7: Arbitration Overview...... 141 Arbitration Signaling ...... 142 Arbitration Services...... 145 Asynchronous Arbitration...... 147 Fairness Interval...... 147 Arbitration Enable Bit ...... 147 Fair Arbitration Service...... 148 Arbitration Reset Gap ...... 148 The Acknowledge Packet and Immediate Arbitration Service...... 150 Isochronous Arbitration...... 150 Cycle Start and Priority Arbitration...... 152 Combined Isochronous and Asynchronous Arbitration...... 152 Cycle Start Skew...... 152 1394a Arbitration Enhancements ...... 157 Acknowledge Accelerated Arbitration...... 157 Fly-by Arbitration ...... 158 Acceleration Control...... 159 Priority Arbitration Service ...... 161 Summary of Arbitration Types ...... 163

Chapter 8: Asynchronous Packets Asynchronous Packets ...... 165 Data Size...... 167 Write Packets ...... 168 Asynchronous Stream Packet ...... 174 Read Packets...... 175 Lock Operations ...... 183 Lock Request Packet ...... 183 Lock Transaction Types (Extended t_code Field) ...... 186 Data Block Length During Lock Request...... 187 Lock Response Packet ...... 188 Response Codes...... 190 Acknowledge Packet ...... 191 Asynchronous Transaction Summary...... 193

xii Contents

Write Transactions ...... 193 Summary of Read and Lock Transactions...... 194 Cycle Start Packet...... 195

Chapter 9: Isochronous Packet Stream Data Packet ...... 199 Isochronous Data Packet Size...... 201 Isochronous Transaction Summary...... 202

Chapter 10: PHY Packet Format Overview...... 205 PHY Packet Format ...... 206 Self-ID Packets ...... 207 Self-ID Packet Zero ...... 207 Self-ID Packets One, Two, and Three (1394-1995)...... 210 Self-ID Packets One and Two (1394a) ...... 211 Link-on Packet ...... 212 PHY Configuration Packet ...... 213 Force Root Node...... 213 Gap Count Optimization ...... 214 Extended PHY Packets ...... 214 Ping Packet...... 214 Remote Access Packet ...... 215 Remote Reply Packet...... 216 Remote Command Packet ...... 217 Remote Confirmation Packet ...... 218 Resume Packet...... 219

Chapter 11: Link to PHY Interface Overview...... 221 The Interface Signals...... 222 Sharing the Interface ...... 224 PHY Initiated Transfers...... 224 Idle State...... 225 Status State...... 225 Receive State ...... 225 Grant State ...... 225 Link Initiated Transfers...... 226 Determining Transfer Rate Between Link and PHY...... 227 Powering the Link...... 228 Packet Transmission...... 228

xiii Contents

Link Issues Request ...... 228 Request Types ...... 231 Speed of Link to PHY Data Transmission...... 231 When Can the Link Issue a Request?...... 232 PHY Behavior When a Packet Request is Received...... 234 Receiving Packets...... 236 Speed of PHY to Link Data Transmission...... 237 PHY Reports Status...... 238 ARB_RESET_GAP...... 239 SUBACTION_GAP...... 239 BUS_RESET_START...... 239 PHY_INTERRUPT ...... 240 Accelerated Arbitration Control...... 240 Accessing the PHY Registers ...... 241 PHY Register Reads...... 242 When Can a Register Read Request Be Issued? ...... 243 PHY Behavior When a Register Read Request is Received...... 243 Register Contents Returned by PHY ...... 243 PHY Register Writes...... 244 When Can a PHY Register Write Request Be Issued?...... 244 PHY Behavior When a Register Write Request is Received...... 245 Electrical Isolation Between PHY and Link...... 245

Chapter 12: Transaction Retry Overview...... 247 Busy Retry...... 248 The First Packet Transmission Attempt ...... 248 Single Phase Retry...... 249 Sending-Node Retry Behavior (Outbound Retry) ...... 249 Receiving-Node Retry Behavior (Inbound Retry) ...... 250 Dual Phase Retry...... 251 Sending-Node Retry Behavior (Outbound Retry) ...... 252 Receiving-Node Retry Behavior (Inbound Retry) ...... 255 Transactions Errors ...... 259 Packet Transmission Errors...... 259 Packet Error Handling Summary ...... 262

xiv Contents

Part Three Serial Bus Configuration

Chapter 13: Configuration Process Overview...... 265 Bus Initialization (Bus Reset) ...... 267 Tree Identification (The Family Tree)...... 268 Self Identification ...... 270 Bus Management...... 272

Chapter 14: Bus Reset (Initialization) Overview...... 273 Sources of Bus Reset...... 274 Power Status Change...... 274 Bus Reset Signaled by Attached Node...... 274 Node Attachment or Removal ...... 275 MAX_ARB_STATE_TIME Expires...... 275 Software Initiated Bus Reset...... 275 Bus Reset Signaling...... 275 Effects of Bus Reset...... 277 Topology Information Cleared ...... 277 PHY Register Changes ...... 277 Port Bias and Connected Bits ...... 278 Port_Event Bit...... 278 Initiate Bus Reset (IBR) and Initiate Short Bus Reset (ISBR) ...... 278 Physical_ID Field ...... 278 Gap_Count...... 278 CSR Register Changes ...... 279 1394-1995 and Reset Runaway ...... 279 Problem One: The Reset Storm ...... 279 The 1394a Solution: Debounce Port Status Signal...... 280 Problem Two: Recognition of Connection Change Not Symmetric...... 282 The Solution: Slow Node Accepts Fast Node’s Reset Signaling ...... 282 Problem Three: Reset Signaled During Packet Transmission...... 282 1394a Solution: Arbitrated Bus Reset...... 283

xv Contents

Chapter 15: Tree Identification Overview...... 285 Tree ID Signaling...... 286 The Tree ID Process...... 286 Leaf Nodes Try to Find Their Parents...... 287 Parents Identify Their Children...... 288 Three Example Scenarios...... 290 Scenario One ...... 290 Leaf Nodes Signal Parent_Notify ...... 290 Branch Nodes Locate Their Parents ...... 292 Scenario Two...... 293 Leaf Nodes Locate Their Parents...... 294 Root Contention ...... 295 Scenario Three ...... 298 Force Root Delay ...... 299 Leaf Nodes Attempt to Locate Their Parents...... 300 Branch Nodes Attempt to Locate Their Parents...... 300 Looped Topology Detection...... 304

Chapter 16: Self Identification Overview...... 305 Self-Identification Signaling ...... 306 Physical ID Selection...... 306 First Physical ID is Assigned...... 306 Self-ID Count...... 307 Branch Nodes Signal Arbitration Grant & Data Prefix ...... 308 Node A Broadcasts Its Self-ID Packet...... 310 Node A Signals Self-Identification Done ...... 311 Nodes Exchange Speed Information...... 312 Second and Subsequent Physical ID Assignment...... 313 Second Self-ID Assignment...... 314 Third Physical ID Assignment...... 316 Fourth Physical ID Assignment...... 318 Fifth Physical ID Assignment ...... 320 Final Physical ID Always Belongs to Root Node...... 322 Self-ID Packets ...... 323 Self-ID Packet Zero ...... 323 Self-ID Packets One and Two (1394a) ...... 325 Who Uses the Self-ID Packet Information...... 326

xvi Contents

Part Four Serial Bus Management

Chapter 17: Cycle Master Overview...... 329 Determining and Enabling the Cycle Master...... 329 Cycle Start Packet...... 330

Chapter 18: Isochronous Resource Manager Overview...... 333 Determining the Isochronous Resource Manager...... 334 Minimum Requirements of Isochronous Resource Managers ...... 335 Enabling the Cycle Master ...... 335 Resource Allocation Registers ...... 336 Channel Allocation ...... 337 Channels Available Register Format ...... 337 Accessing the Channels Available Register...... 337 Bus Bandwidth Allocation...... 339 Bandwidth Available Register Format ...... 340 Accessing the Bandwidth Available Register...... 340 Bus Bandwidth Set-Aside for Asynchronous Transactions ...... 341 Reallocation of Isochronous Resources...... 342 Power Management ...... 342

Chapter 19: Bus Manager Overview...... 343 Determining the Bus Manager ...... 344 Power Management ...... 345 Power Management by Bus Manager Node ...... 345 Power Management by IRM Node...... 346 The Topology Map...... 346 Accessing the Topology Map ...... 347 Gap Count Optimization ...... 348 The Speed Map...... 349 Accessing the Speed Map ...... 349 Bus Bandwidth Set-Aside...... 350

xvii Contents

Chapter 20: Bus Management Services Overview...... 351 Serial Bus Control Requests ...... 353 Bus Reset Control Request...... 353 Initialize Control Request ...... 354 Link-On Control Request...... 354 Present Status...... 354 PHY Configuration Request...... 354 Set Force Root and Set Gap Count ...... 355 Extended PHY Packets...... 355 Serial Bus Control Confirmations ...... 356 Serial Bus Event Indication...... 357

Part Five Registers & ROM

Chapter 21: CSR Architecture Overview...... 361 Core Registers ...... 362 Effect of Reset on the CSRs...... 364 State Register (State_Clear & State_Set)...... 364 State_Clear Register...... 365 State_Set Register...... 366 Bus Depend Field...... 366 Cycle Master Enable...... 367 Abdicate...... 369 Node_IDS Register...... 369 Reset_Start Register ...... 373 Indirect_Address and Indirect_Data Registers...... 373 Split_Timeout Register...... 373 Argument, Test_Start, and Test_Status Registers ...... 375 Units_Base, Units_Bound, Memory_Base, and Memory_Bound Registers ...... 375 Interrupt_Target and Interrupt_Mask Registers...... 375 Clock_Value, Clock_Tick_Period, Clock_Strobe_Arrived, and Clock_Info Registers ...... 376 Message_Request & Message_Response Registers...... 376 Serial Bus Dependent Registers...... 376 Cycle_Time & Bus_Time Registers...... 377 Power_Fail_Imminent & Power_Source Registers ...... 380 Busy_Timeout Register ...... 382 xviii Contents

Bus_Manager_ID Register ...... 383 Bandwidth_Available Register ...... 384 Channels_Available Register ...... 384 Maint_Control Register...... 386 Maint_Utility Register...... 386 Unit Registers...... 388 Topology Map ...... 389 Speed Map...... 390

Chapter 22: PHY Registers Overview...... 393 1394-1995 PHY Register Map ...... 394 Port Status Registers...... 397 PHY Configuration Packet ...... 397 Root Hold Off ...... 397 Gap Count Optimization ...... 397 1394a PHY Register Map...... 398 Page Select...... 402 Port Status Register Page...... 403 Vendor Identification Register Page ...... 407 Vendor-dependent Page ...... 408

Chapter 23: Configuration ROM Overview...... 409 Minimal ROM Format...... 410 General ROM Format...... 410 Header Information...... 411 Info_Length...... 411 CRC_Length ...... 412 CRC_Value...... 412 Bus_Info_Block (1394-1995)...... 412 Bus_Name Field ...... 413 Bus Characteristics Fields...... 413 Node_Vendor_ID Field...... 414 Chip_ID Fields ...... 415 Bus Info Block (1394a) ...... 415 Power Management Capable...... 415 Generation Field...... 416 Link Speed ...... 416 Root_Directory ...... 416 Required Root Directory Entries ...... 419

xix Contents

Module_Vendor_Id ...... 419 Node_Capabilities ...... 419 Node_Unique_Id ...... 420 Unit_Directory & Unit_Power_Requirements...... 422 Optional Root Directory Entries...... 422 Bus_Dependent_Info...... 422 Module_Hw_Version ...... 422 Module_Spec_Id...... 422 Module_Sw_Version...... 422 Company ID Value Administration...... 423

Part Six Power Management

Chapter 24: Introduction to Power Management Overview...... 427 Review of 1394-1995 Power-Related Issues...... 428 Goals of the 1394a Power Extensions ...... 429

Chapter 25: Cable Power Distribution Power Distribution ...... 431 Power Class Codes...... 432 Power Providers...... 433 Power Provider Classes ...... 434 Alternate Power Providers...... 436 Maximum Voltage <20vdc...... 436 Maximum Voltage >20vdc...... 436 Power Consumer...... 437 Self-Powered Nodes (Non Power Providers) ...... 438 Self-Powered Class Zero Nodes ...... 439 Self-Powered Class Four Nodes ...... 440 Two port node — no cable power used...... 440 Three ports or more — no cable power used ...... 441 Two ports or more — cable power used when power is lost ...... 441 Two ports or more — cable-powered PHY...... 442 Local Power Down Summary ...... 443

xx Contents

Chapter 26: Suspend & Resume Overview...... 445 Suspending a Port ...... 448 Suspending Via the Suspend Command Packet ...... 449 Suspending Via RX_SUSPEND ...... 451 The BIAS Handshake...... 451 Suspending Via Port Disable...... 451 Disable Via Disable Port Command Packet (local or remote)...... 452 Port Suspend Via Unexpected Loss of Bias...... 453 Resuming Full Operation ...... 454 Resuming Via Resume Packet...... 454 Resuming Via Resume Port Command Packet ...... 454 Resuming Via Port Events ...... 455

Chapter 27: Power State Management Power Management ...... 459 Power States...... 460 Node Power States...... 460 Node Power State Zero (N0) ...... 461 Node Power State One (N1)...... 461 Node Power State Two (N2) ...... 461 Node Power State Three (N3) ...... 461 Unit Power States...... 461 New CSRs...... 463 Node Power Control Register...... 464 Notification Address Register...... 466 Cable Power Source State Register...... 466 Cable Power Source Control Register...... 467 Power Change Register...... 468 Unit Power State Register...... 469 Unit Power Control Register...... 470 Battery State Register ...... 471 New ROM Entries...... 472 Node Power Directory Entry ...... 473 Node Power Level Entry ...... 474 Cable Power Source Level Entry ...... 475 Node Power Management Entry...... 475 Battery Group Entry (Node) ...... 476 Battery State Entry...... 476 Unit Power Directory Entry ...... 477

xxi Contents

Unit Power Level Entry ...... 477 Unit Power Management Entry...... 477 Battery Group Entry (Unit) ...... 478

Appendix: Example 1394 Chip Solutions Overview...... 479 1394 in the PC...... 479 TSB12LV22 / OHCI-Lynx...... 480 Features ...... 480 Overview...... 481 Block Diagram...... 482 TSB41LV03 ...... 482 Features ...... 483 TSB41LV03 Overview ...... 483 Block Diagram...... 487 Putting it all Together...... 488 1394 in the Digital Camera ...... 489 TSB12LV31 – GPLynx...... 489 Features ...... 489 Overview...... 490 Block Diagram...... 491 TSB21LV03A ...... 492 Features ...... 492 Block Diagram...... 493 Putting it all Together...... 494 For More Information...... 494

Appendix: Glossary ...... 495 Index ...... 503

xxii 1 Why FireWire?

This Chapter

This chapter provides a brief history of FireWire (IEEE 1394). It also discusses the need for FireWire and reviews the applications for which it is well suited. The Next Chapter

The next chapter describes the primary features of the FireWire serial bus implementation. The chapter also reviews the IEEE 1394 standards (IEEE 1394-1995 & IEEE 1394.A) and IEEE ISO/IEC 13213 (ANSI/IEEE 1212) standard that the FireWire serial bus is based upon.

Overview

Development of FireWire began in the mid 1980s by Apple Computer. In fact, the term FireWire is a registered trademark of Apple Computer Corporation. As other manufacturers gained interest in FireWire, a working committee was formed to create a formal standard on the architecture. The resulting specification was submitted to IEEE and IEEE 1394-1995 was adopted.

Motivations Behind FireWire Development

FireWire provides a serial bus interconnect that allows a wide range of high performance devices to be attached. A variety of issues led to the development of FireWire. The primary characteristics of this serial bus include: • Ease of use • Low cost device implementations • High speed application support • Scalable performance • Support for isochronous applications • Huge amount of memory mapped address space supported (16 exabytes) • Operation independent of host system

13 FireWire System Architecture

Inexpensive Alternate to Parallel Buses

The IEEE 1394 serial bus provides an alternative to more expensive parallel bus designs. Benefits of the serial bus over most parallel bus implementations are listed below. • Reduced cost compared with many parallel bus implementations. • Peripherals in current personal computer systems reside on a variety of buses (e.g. PCI and ISA buses). Communication between such devices can be problematic due to bus protocol and speed differences, thus slowing overall performance. FireWire provides an opportunity to locate a wide variety of peripheral devices that connect to the same serial bus, resulting in performance gains. Up to 63 nodes can be attached to a single serial bus. • Many parallel buses are confined to a small physical area; however, serial bus has much greater flexibility (4.5 meters between devices). • FireWire supports direct attachment of remote peripherals. • The 1394 bus can be implemented in conjunction with the parallel bus to provide fault tolerance.

Plug and Play Support

Devices attached to the IEEE 1394 serial bus support automatic configuration. Unlike USB devices, each 1394 node that attaches to the bus automatically par- ticipates in the configuration process without intervention from the host system. Each time a new device is added to or removed from the bus, the 1394 bus is re-enumerated. This occurs whether or not the bus is attached to a host system.

Eliminate Host Processor/Memory Bottleneck

Like any bus that supports bus mastering, the 1394 bus has the ability to increase overall system performance. In a PC environment the 1394 bus can reduce traffic across PCI and reduce accesses to the memory subsystem. This can be accomplished by locating devices on the 1394 bus that communicate with each other frequently. This eliminates the need for the processor and memory subsystems to be involved in the transfer of data between devices.

14 Chapter 1: Why FireWire?

High Speed Bus with Scalable Performance

Many peripheral devices such as hard drives and video cameras require high throughput. The 1394 bus accommodates these types of devices with a 400Mb/s transfer rate. This yields a theoretical throughput of 50MB/s in contrast to the throughput of ISA (8MB/s) and PCI (132MB/s). The 1394 serial bus provides scalable performance by supporting transfer rates of 400Mb/s, 200Mb/s, and 100Mb/s.

Support for Isochronous Applications

The serial bus supports isochronous transfers to support applications such as audio and video which require constant transfer rates. The isochronous transfer support reduces the amount of buffering required by isochronous applications, thereby reducing cost.

BackPlane and Cable Environments

1394 supports both a backplane and cable implementation, permitting flexibility of implementation. The backplane environment provides the ability of establishing a redundant serial bus communications channel in conjunction with a parallel bus implementation. The cable environment allows the remote attachment of peripheral devices with the possibility of supporting peripherals spread over a distance of greater than 250 meters. The capability makes the serial bus an attractive option for small network applications.

Bus Bridge

The huge amount of memory address space supported, high transfer rates, and low costs make the 1394 bus an attractive means of bridging between different host systems and between multiple serial bus implementations. • Serial bus implementations can be used to bridge other buses together. The serial bus provides the ability to bridge between host systems of varying sizes and types, including PCs, mini-computers, and mainframes. • A single serial bus supports 63 nodes but can supports up to 1024 serial buses, making the total number of nodes supported at nearly 64k.

15 FireWire System Architecture

1394 Applications

The scalable performance and support for both asynchronous and isochronous transfers makes FireWire an alternative for connecting a wide variety of peripherals including: • Mass storage • Video teleconferencing • Video production • Small networks • High speed printers • Entertainment equipment • Set top box

IEEE 1394 Refinements

Early implementations based on different interpretations of the 1995 release of the specification resulted in some interoperability problems between different vendor parts. A supplement to the 1394-1995 specification is referred to as the 1394a supplement, and is designed to eliminate these problems. In addition to clarifying portions of the 1394-1995 specification, the 1394a supplement fixes problems, specifies enhancements that are designed to improve performance, and adds new functionality. This book covers the 1394a supplement (2.0 draft version) as it existed at the time of writing. Power management support and a specification for designing 1394 bridges were also in development at the time of this writing. Portions of the preliminary Power Management specification are included in this text, while the state of the bridge specification was not mature enough to be included. Yet another version of 1394 being developed is called the IEEE 1394.B specification. This specification defines even higher throughput including 800Mb/s, 1.6Gb/s, and 3.2Gb/s. This specification is being designed for backward com- patibility to 1394-1995 and 1394a.

16 Chapter 1: Why FireWire?

Primary Features

The primary features of FireWire’s cable environment are summarized in Table 1-1 on page 17. The next chapter provides a more detailed overview of the FireWire architecture.

Table 1-1: FireWire Key Features

Scalable Performance Speeds of 100, 200, and 400 Mb/s supported.

Hot Insertion & Removal Devices can be attached or removed from the bus dynamically without powering the system down.

Plug and Play Each time a device is attached or detached the bus is re- enumerated. Nodes on the bus are to a large degree self-configuring, and configuration does not require intervention from a host system (such as a PC).

Support for two types of Support for isochronous and asynchronous transfers. transactions

Layered hardware and Communications based on a transaction layer, link software model layer, and physical layer protocols.

Support for 64 nodes Supports 64 node addresses (0-63) on a single serial bus implementation. Node address 63 is used as a broadcast address that all nodes recognize, permitting attachment of up to 63 physical nodes on the bus.

Address space of 16 Each of the 64 nodes has 256TB of address space, mak- petabytes per bus ing the total address space of 16 petabytes.

Support for 1024 buses The CSR architecture supports up to 1024 buses for a total address space of 16 exabytes.

Peer-to-Peer transfer sup- Serial bus devices have the ability to perform transac- port tions between themselves, without the intervention of a host CPU.

17 2 Overview of the IEEE 1394 Architecture

The Previous Chapter

The previous chapter discussed the need for FireWire and reviewed the applications for which it is well suited. This Chapter

This chapter describes the primary features of the FireWire serial bus implementation. The chapter also overviews the IEEE 1394 standards (IEEE 1394-1995 & IEEE 1394a) and ISO/IEC 13213 (ANSI/IEEE 1212) standard that the FireWire serial bus is based upon. The Next Chapter

The next chapter provides an overview of the IEEE 1394 communications model. It defines the basic transfer types and introduces the communication layers defined by the serial bus specification.

IEEE 1394 Overview

The IEEE 1394 specification defines the serial bus architecture known as FireWire. Originated by Apple Computer, FireWire is based on the internation- ally adopted ISO/IEC 13213 (ANSI/IEEE 1212) specification. This specification, formally named “Information technology—Microprocessor systems—Control and Status Registers (CSR) Architecture for microcomputer buses,” defines a common set of core features that can be implemented by a variety of buses. IEEE 1394 defines serial bus specific extensions to the CSR Architecture.

19 FireWire System Architecture

IEEE 1394-1995 provides support for a backplane environment and a cable environment. This book focuses only on the cable environment.

Specifications and Related Documents

This book is based on a variety of specifications and documents, some of which are completed and approved, while others are in varying stages of completion and approval. To distinguish information based on approved specifications versus information based on pre-approved specifications and documents, a symbol is used to alert the reader to pre-approved references that might otherwise not be obvious. The following bulleted list includes the specifications and documents used as references when writing this book. The symbol previously men- tioned is used to highlight those specifications and documents that are not approved at the time of this writing.

The following documents were used during the development of this book:

• CSR Architecture Specification — ISO/IEC 13213 (ANSI/IEEE 1212) • IEEE 1394-1995 Serial Bus Specification •IEEE 1394a Supplement •Power Distribution Specification •Power Management Specification •Suspend/Resume Specification •Open Host Controller Interface (OHCI) for 1394 Specification •Device Bay Specification •1394.1 Bridge Specification •IEEE 1394.B Specification

The author strongly urges the reader to obtain the latest (and hopefully approved) versions of these specifications. Also please check MindShare’s web site (www.mindshare.com) to check for errata, clarifications, and additions to this book. Due to the evolving nature of this topic, many changes are inevitable. Some of these specifications may be available on the IEEE 1394 Trade Associa- tion web site at: www.firewire.org.

IEEE 1394-1995 and the IEEE 1394a Supplement

The IEEE 1394 specification was released in 1995, hence the name IEEE 1394- 1995. Different interpretations of the 1995 specification have led to interoperability problems. To clarify the specification a supplement to the 1995 specifica-

20 Chapter 2: Overview of the IEEE 1394 Architecture

tion has been developed, called 1394a. This supplement also adds additional features and makes improvements intended to increase performance or usabil- ity. This text incorporates the changes defined by 1394a. However, at the time of this writing 1394a was not an officially released document from IEEE.

IEEE 1394.B

A higher speed 1394 serial bus called the “B” version was also being developed, when this book was being written. This specification will define serial bus extensions for running the serial bus at speeds into the gigabit per second range. This specification is intended to be backwardly compatible with the 1394-1995 and 1394a implementations. Note that another solution has been proposed that also increases the serial bus speed, and is known as the 1394.2 version. This proposed solution, however, is not backwardly compatible with earlier 1394 versions, causing considerable opposition.

Unit Architecture Specifications

A wide variety of functional devices (e.g. hard drives, video cameras, and CD- ROMs) can be implemented as 1394 nodes. Functional devices are termed units by the 1394 specification. Certain types of devices may have related specifications called “unit architectures” that define implementation details such as protocols, ROM entries, control and status registers, etc. Two specifications of this type are:

• Serial Bus Protocol 2 (SBP2) Architecture — used for SCSI-based mass storage functions. • A/V unit Architecture — used for audio/visual functions.

Check the 1394 Trade Association web site (www.firewire.org) for information regarding Unit Architecture documentation.

21 FireWire System Architecture

Figure 2-1: PC with IEEE 1394 Bus Attached to the PCI Bus.

Video Main Frame Memory Buffer

Host/PCI CPU Cache/ Bridge

Graphics Adapter

3&, %XV

SCSI Host LAN PCI to Bus Adapter IEEE 1394 Adapter Adapter

6 /$1 & 6 , Laser CD-ROM Desktop Digital Set-top Printer Camera VCR Box % 8 Disk 6

Disk

Tape

22 Chapter 2: Overview of the IEEE 1394 Architecture

IEEE 1394 Topology

Figure 2-1 on page 22 represents a typical PC that incorporates an IEEE 1394 serial bus attached to the PCI bus. A PCI to 1394 bridge (Open Host Controller Interface, or OHCI) interfaces the computer to the serial bus. The serial bus allows attachment of high speed peripheral devices that would otherwise require a relatively expensive bus solution such as PCI or SCSI. As shown in Figure 2-1, a wide variety of peripheral devices can be attached and supported.

Multiport Nodes and Repeaters

1394 nodes may have one or more ports. A single port node discontinues the bus along a given branch of the bus, whereas nodes with two or more ports allow continuation of the bus, as illustrated in Figure 2-2 on page 23. Nodes with multiple ports permit the bus topology to be extended. Note that the signaling environment is point-to-point. That is, when a multiport node receives a packet, it is detected, received, resynchronized to the repeaters local clock and retransmitted over the other node ports.

Figure 2-2: IEEE 1394 Nodes May Extend the Bus Via Additional Ports

Configuration

Configuration is performed dynamically as new devices are attached and/or removed from the bus. The configuration process does not require intervention from the computer system.

23 3 Communications Model

The Previous Chapter The previous chapter described the primary features of the IEEE 1394 serial bus implementation. The chapter also reviewed the IEEE 1394 standards (IEEE 1394-1995 & IEEE 1394a) and the ISO/IEC 13213 (ANSI/IEEE 1212) standard that the FireWire serial bus is based upon. This Chapter This chapter provides an overview of the serial bus communications model. It defines the basic transfer types and introduces the communication layers defined by the specification. The Next Chapter The next chapter describes the services defined by the specification that are used to pass parameters between layers during the execution of each transaction.

Overview

Since the IEEE 1394 serial bus supports peer-to-peer transactions, arbitration must be performed to determine which node will obtain ownership of the serial bus. This arbitration mechanism supports a fairness algorithm that ensures that all transfers obtain fair access to the bus. Serial bus arbitration is discussed in detail in Chapter 7.

The serial bus supports two data transfer types:

• asynchronous transfers that do not require delivery at a constant data rate. Asynchronous transfers target a particular node based on a unique address. These transfers do not require a constant bus bandwidth and therefore do

37 FireWire System Architecture

not need regular use of the bus, but must get fair access over time. • isochronous transfers that require data delivery at constant intervals. These transfers define a channel number rather than a unique address, permitting the isochronous data stream to be broadcast to one or more nodes responding to the channel number. These transfers require regular bus access and therefore have higher bus priority than asynchronous transfers.

Serial bus data transactions take place via a series of data and information packet transmissions. Each transaction is initiated by a “requester” and the request is received by a target device, called a “responder.”

Asynchronous transactions require a response from the target node, which results in an additional transaction. The responding node either accepts or returns data as illustrated in Figure 3-1.

Figure 3-1: Request/Response Protocol

Request

R R Address & Transaction Type

F F

e e (plus data if write or lock)

u u

n n

c c

t t

i i

o o

n n

e Status e

r (plus data if read or lock) r Response

This basic communications model is defined by the CSR architecture. The serial bus provides further granularity in the transaction process, which includes verification of packet delivery, three protocol layers, and related services that perform specific functions during the process of transferring data between the requester and responder. These layers are described later in this chapter.

38 Chapter 3: Communications Model

Isochronous transactions complete following the request as illustrated in Figure 3-2. Note that rather than an address, isochronous transactions use a channel number to identify target nodes. Additionally no response is returned from the target node.

Figure 3-2: Isochronous Transaction that Consists Only of a Request Transaction

F F

u u

n n

u Isochronous Request

c c

t t

i i

o o

d t Channel Number,

n n

r Transaction Type, & Data r

The actual transfer of data across the cable is done serially using data-strobe encoding (See page 122). Data can be transmitted at one of three speeds:

• 100 Mb/s (98.304 Mb/s) • 200 Mb/s (196.608 Mb/s) • 400 Mb/s (393.216 Mb/s)

Prior to transferring data, the transmitting node must obtain ownership of the 1394 bus via an arbitration mechanism. This ensures that only one node at a time is transmitting data over the wire.

Transfer Types

As illustrated in Figure 3-3, a mix of isochronous and asynchronous transactions may be performed across the serial bus by sharing the overall bus bandwidth. Notice that bus bandwidth allocation is based on 125µs intervals, called cycles. Details regarding these transaction types and their bandwidth allocation are discussed below.

39 FireWire System Architecture

Figure 3-3: Isochronous and Asynchronous Transactions Share Bus Bandwidth

Cycle n-1 Cycle n Cycle n+1

A A

c c c Cycle Start Cycle Start

k k Packet A k data=x Ch B Ch C Ch DCh N Packet B Packet C data=y Ch B

cycle period = 125µs

C C = Isochronous Transactions

S S = Asynchronous Transactions

Asynchronous

Asynchronous transfers target a particular node by using an explicit 64-bit address. Asynchronous transfers (collectively) are guaranteed 20% (minimum) of the overall bus bandwidth. Thus, the amount of data transferred depends on the transmission speed. A given node is not guaranteed any particular bus bandwidth, but rather is guaranteed fair access to the bus via a fairness interval, in which each node wishing to perform an asynchronous transaction gets access to the bus exactly one time during a single fairness interval. Maximum packet size for asynchronous transfers is limited as specified in Table 3-1. Note that higher cable speeds have been specified by the 1394a supplement, but the maximum speed and maximum data payload supported remains at 400Mb/s.

Asynchronous transfers also verify data delivery via CRC checks and response codes, and in the event that errors occur during transmission, retries may be attempted under software control.

40 Chapter 3: Communications Model

Table 3-1: Maximum Data Block Size for Asynchronous Transfers

Cable Speed Maximum Data Payload Size (Bytes)

100Mb/s 512 200Mb/s 1024

400Mb/s 2048

800Mb/s 4096 1.6Gb/s 8192

3.2Gb/s 16384

Isochronous

Isochronous transfers target one or more (multi-cast transactions) devices based on a 6-bit channel number associated with the transfer. Channel numbers are used by the isochronous listeners to access a memory buffer within the application layer. This memory buffer may or may not reside within the node’s 256TB of address space.

Each isochronous application must also obtain the necessary bus bandwidth that it requires for its transfer. To ensure that sufficient bus bandwidth is available, applications wishing to perform isochronous transfers must request the needed bandwidth from the isochronous resource manager node. Bus bandwidth is allocated on a per cycle basis.

Once bus bandwidth has been acquired for an isochronous transfer, that channel receive a guaranteed time-slice during each 125µs cycle. Up to 80% (100µs) of each bus cycle can be allocated to isochronous transfers. The maximum packet size supported for a given isochronous transfer is limited to the available bus bandwidth, and must not exceed the maximum packet size specified in Table 3-2 on page 42. The maximum packet size limit for isochronous transactions has been added by the 1394a specification. The isochronous bus bandwidth available is maintained by the isochronous resource manager node. Each node wishing to perform isochronous transfers must request its desired bus bandwidth from the isochronous resource manager based of the number of desired allocation units. The maximum packet size may be limited by the

41 4 Communications Services

The Previous Chapter

The previous chapter provided an overview of the serial bus communications model. It defined the basic transfer types and introduced the communication layers defined by the specification. This Chapter

This chapter describes the services defined by the specification that are used to pass parameters between layers during the execution of each transaction. The Next Chapter

The next chapter discusses the cable characteristics and connectors used by the IEEE 1394 cable environment. It also discusses the Device Bay implementation being specified in PC environments.

Overview

The IEEE 1394 specification defines services that are used to pass parameters between each layer within the communications model. These services are used to initiate transactions or to respond to a transaction that has been received. The following sections describe the services used when performing asynchronous and isochronous transactions.

65 FireWire System Architecture

Anatomy of Asynchronous Transactions

Three primary types of asynchronous transactions are defined by the 1394 specification:

• reads • writes • lock

The following discussion reviews each of these transaction types and defines the protocol layers and services calls used to initiate and respond to asynchronous transactions. It also defines the packet types used and details the possible responses.

The following sections describe the steps involved in completing asynchronous transactions. The three basic asynchronous transaction types are described from initiation to response completion with the role of each layer in the protocol detailed.

The Request Subaction

The request subaction involves sending the request phase of an asynchronous transaction to a target node. Both the request and the response agent are involved in the request subaction as discussed below. The specification defines the protocol layers used during the request phase of an asynchronous transaction. The services used in performing a request subaction are listed in Table 4-1. These services are listed in order of reoccurrence during successful request subaction transmission. Note that the shaded entries indicate actions that take place within the responding node. These services are represented graphically in Fig- ure 4-1 on page 68.

Table 4-1: Service Used During Asynchronous Request Subactions

Direction of Service Name Purpose of Service Communication

Transaction Data From the Application Causes transaction layer to initiate Request an asynchronous transaction.

Link Data Request From Transaction Layer Causes link layer to initiate an asynchronous transaction.

66 Chapter 4: Communications Services

Table 4-1: Service Used During Asynchronous Request Subactions (Continued)

Direction of Service Name Purpose of Service Communication

PHY Arbitration Request From Link Layer Causes the PHY to arbitrate for control of the serial bus.

PHY Arbitration From PHY Reports results of arbitration Confirmation request back to link.

PHY Clock Indication From PHY Following successful arbitration, the PHY notifies the link that it is ready to accept clocked data.

PHY Data Request From Link Layer Controls clocked transmission of the request packet onto the serial bus.

PHY Data Indication To Link Layer Notifies link of the receipt of data bits of the packet.

Link Data Indication To Transaction Layer Indicates the reception of a transaction request.

Transaction Data To Application Indicates the reception of a transac- Indication tion request.

Link Data Response From Transaction Layer Initiates return of acknowledge packet to the requesting node.

PHY Data Request From Link Layer Controls clocked transmission of the acknowledge packet onto the serial bus.

PHY Data Indication To Link Layer Notifies link of the receipt of the acknowledgment packet.

Link Data Confirmation To Transaction Layer Notifies transaction layer whether the request was successfully received.

67 FireWire System Architecture

Figure 4-1: Example Asynchronous Read Transaction

Application Application Asynchronous Asynchronous Transfer Transfer Interface Interface

Transaction Transaction Transaction Transaction Data Data Data Data Request Confirmation Indication Response

Transaction Transaction Layer Layer

Link Data Link Data Link Data Link Data Request Confirmation Indication Response

Link Layer Link Layer

Physical Data Physical Data Physical Data Physical Data Requests Indications Indications Requests

Physical Layer Physical Layer Port 0 Port 1

Serial Bus

Read Request Read Request Acknowledgment (repeated) Node A Acknowledgment Node B (Requester) (Responder) Read Response Read Response (repeated) Acknowledgment Acknowledgment (repeated)

68 Chapter 4: Communications Services

Initiating the Transaction (The Request)

Transaction Layer. Applications initiate asynchronous transactions via the “transaction data request” service. Transaction layer services can be thought of as calls to low level routines that insulate the application programmer from the programming interface associated with the link layer controller chip. The transaction layer also provides verification of packet delivery and initiates the acknowledge packet. The “transaction data request” service, communicates the following parameters:

• Transaction Type Code - Write - Read - Lock • Extended transaction code (only defined for lock transaction) • Destination Address • Data Length • Data (Data to be transferred during a write or lock transaction) • Speed of transmission

The Link Layer. The transaction data request calls a link layer service rou- tine that passes the transaction parameters specified by the application onto the link layer controller in the form that it understands. In addition, the retry code and transaction label parameters are added as the data request is passed onto the link layer controller. The actual mechanism for sending commands to the link layer controller is not defined by the specification. Parameters passed by the “link data request” service include:

• Destination Address • Transaction Type Code - Write - Read - Lock • Extended transaction code (only defined for lock transaction) • Data Length • Data (Data to be transferred during a write or lock transaction) • Speed of transmission • Retry code • Transaction Label

69 5 Cables & Connectors

The Previous Chapter

The previous chapter described the services defined by the specification that are used to pass parameters between layers during the execution of each transaction. This Chapter

This chapter discusses the cable characteristics and connectors used by the IEEE 1394 cable environment. It also discusses the Device Bay implementation being specified in PC environments. The Next Chapter

Next, the serial bus signaling environment is discussed. This includes recognition of device attachment and removal, arbitration signaling, speed signaling, and data/strobe signaling.

Cable and Connector Types

Two types of cables are supported by 1394. The original IEEE 1394-1995 specification defines a single 6-pin connector type and cable. The connectors are identical at both ends of the cable and can be plugged in either direction, between nodes.

The 1394a supplement defines an alternate 4-pin connector and cable that eliminates the power pins. Cables using this connector may have a 4-pin connector on one end of the cable and a 6-pin connector on the other end, or may have 4-pin connectors on each end. The specification places limits on the types of devices allowed to use 4-pin connectors.

85 FireWire System Architecture

6-pin Connector (1394-1995)

The original 1394-1995 specification defines a 6-pin plug and socket that is illustrated in Figure 5-1. The contact signal assignments are listed in Table 5-1 on page 87. Cable assemblies based on the 1995 version of the specification have mechanically-identical plugs at each end of the cable and all 1394 devices employed the standard 6-pin socket.

Figure 5-1: 6-Pin Plug and Socket

11 mm

VP TPB* TPA*

1 3 5

2 4 6 VG TPB TPA Plug

Contacts

11.3 mm

VG TPB TPA

2 4 6

1 3 5 VP TPB* TPA* Socket

86 Chapter 5: Cables & Connectors

Table 5-1: Contact Signal Assignments and Numbers

Contact Signal Description Number Name

1 VP Cable Power (voltage may range from 8 - 40 vdc).

2VGCable Ground.

3TPB*Twisted pair B — differential data transmitted on TPB and differential strobe received on TPB. 4TPB

5TPA*Twisted pair A — differential strobe transmitted on TPA and differential data received on TPA. 6TPA

The socket dimensions are relatively small (11.3mm X 6.2mm) when compared to standard connectors used by many computer peripheral devices. The socket consists of a shell and contact wafer. The plug body fits into the socket shell and the contacts within the plug body slide over the socket’s contact wafer as the plug is inserted.

Make First/Break Last Power Pins

The 6-pin socket has longer contact power and ground contact pins. This ensures that the power pins make contact prior to the data pair pins when the plug is inserted into the socket; and conversely, when a plug is removed the data pins break contact prior to the power pins. The separation between the power and data pins is specified to be a minimum of 0.8mm.

Optional 4-pin Connector (1394a supplement)

The 4-pin connector is defined by the 1394a supplement for use in 1394 applications where the standard 6-pin connector is too large. Figure 5-2 illustrates the 4-pin plug and socket. The connector was originally designed by Sony and included in their video cameras. The 1394a supplement adopted the Sony design. The specification defines two categories of 1394 devices that may benefit from a smaller connector:

• Battery operated devices — Since these nodes do not draw power from the cable, a less expensive cable and connector are possible and desirable. Fur-

87 FireWire System Architecture

thermore, the power conductors can be a source of unwanted analog noise, which is a major concern for applications that include audio. • Hand-held devices — The standard connector may be relatively bulky when implemented into small hand-held devices such as video camcorders.

Figure 5-2: 4-Pin Plug and Socket

5.35 mm

m 4 3 2 1

Plug

5.45 mm

m 1 2 3 4

Socket

Positive Retention

Both connector types employ positive retention via a detent. Applying sufficient force releases the plug when removing the cable. The specification permits stronger retention features to be implemented. However, these additional retention features must not interfere with the ability to mate the plug or connector using the standard detent retention mechanism.

88 Chapter 5: Cables & Connectors

Cable Characteristics

Cable electrical characteristics are the same for the 4-conductor and 6-conductor cable, with the exception that the 4-conductor cable does not include the power wires. Standard electrical characteristics of the cables have the following parameters and characteristics. Test and measurement procedures are described in the specification.

• Suggested maximum cable length = 4.5 meters (with signal velocity = 5.05ns/meter) • 110 ohms characteristic impedance — differential mode • 33 ohms characteristic impedance — common mode • Signal velocity equal to or less than 5.05ns/meter • Signal pair attenuation: - 100MHz = <2.3dB - 200MHz = <3.2dB - 400MHz = <5.8dB • Relative propagation skew ≤ 400ps @ 100MHz and ≤ 100ps @ 400MHz (the difference between the differential mode propagation delay of the two twisted pair conductors that must be measured in the frequency domain). • TPA to TPB Crosstalk ≤ -26 dB (within 1MHz to 500MHz range).

6-Conductor Cables

Figure 5-3 illustrates the cross-section of a 6-conductor cable including the wires and insulation required.

Figure 5-3: Cross-section of 6-Conductor Cable

Power Wires Outer Jacket

Outer Shield

Signal Pair Shield

Twisted Signal Pairs

89 6 The Electrical Interface

The Previous Chapter

The previous chapter discussed the cable characteristics and connectors used by the IEEE 1394 cable environment. It also discussed the Device Bay implementation being specified in PC environments. This Chapter

This chapter details the serial bus signaling environment. This includes recognition of device attachment and removal, arbitration signaling, speed signaling, and data/strobe signaling. The Next Chapter

The next chapter discusses the arbitration process. It defines the various types of arbitration including isochronous and asynchronous arbitration, as well as the newer arbitration types defined by the 1394a supplement.

Overview

The IEEE 1394 serial bus employs two twisted pairs of signal wires (Twisted Pair A, or TPA and Twisted Pair B, or TPB). Additionally, a single pair of wires may be used to provide power for nodes. TPA and TPB provide both differential and common mode signaling to support the following functions.

• Recognition of device attachment/detachment • Reset • Arbitration • Packet transmission • Automatic configuration • Speed signaling

95 FireWire System Architecture

The twisted pair signals are crosswired within the cable, such that TPA and TPB of one node connects respectively to TPB and TPA of the other. The individual twisted pair signals are referred to as TPA/TPA* and TPB/TPB*. Either node may initiate a transaction and therefore use identical signaling interfaces. The following sections discuss the functional aspects of the 1394 signaling environment.

Common Mode Signaling

Common mode signaling is used for the following functions:

• Device attachment/detachment detection • Speed signaling • Suspend/resume signaling

These signaling environments utilize DC signals to accomplish the required functionality. The characteristic impedance of the signal pairs is 33±6Ω. Since the signaling is based on DC signaling, there is no concern regarding unwanted reflections. Common mode values are specified as the average voltage on the twisted pair A or B (e.g. Average voltage of TPA and TPA*).

Differential Signaling

Differential signaling is used for the following functions:

• Reset • Arbitration • Configuration • Packet transmission

Differential signaling can occur at speeds of 100, 200, or 400MHz. The goal of the 1394 differential signaling environment is to eliminate signal reflections from occurring over the cable. This is accomplished by terminating the differential pairs to obtain a reflection coefficient of zero. The characteristic impedance of each signal is 110±6Ω, therefore 110Ω termination resistors (two 55Ω resistors in series) are employed to eliminate reflections on each signal line. See “Differ- ential Signal Specifications” on page 104 for details regarding the differential signaling environment.

96 Chapter 6: The Electrical Interface

Differential signaling has two major advantages that are used by the 1394 bus:

• Noise immunity • Three signaling states: differential 1, differential 0, and Hi Z

The three signaling states are used to define a variety of bus conditions and are detailed later in this chapter.

Recognition of Device Attachment and Detachment

Recognition of whether a device is attached to a given port or not differs between the 1394-1995 specification and the 1394a supplement. Both mechanisms are described in the following sections.

IEEE 1394-1995 Device Attachment/Detachment

Each node provides an offset voltage on its TPA signal lines by driving a TpBias voltage in the range of 1.665v to 2.015v. This voltage is driven by a twisted pair bias voltage source driver as illustrated in Figure 6-1. On the other end of the cable, TpBias is detected by the attached node’s port status receiver via TPB. Accounting for signal attenuation across the wire, the receiver senses a voltage between 1.165v and 2.015v.

97 FireWire System Architecture

Figure 6-1: Bias Voltage Applied to the Cable Permits Detection of Node Attachment/ Detachment.

3RUWÃ6WDWXV 7ZLVWHGÃ3DLU + TpBias + Port_Status 5HFHLYHU %LDVÃ6RXUFH 0.8V (Common to all ports) &DEOH 0.3 µf for 7ΚΩ 7ΚΩ 3 port node 6HJPHQW 55Ω

TPA ` TPB 7ZLVWHGÃ3DLUÃ$ 7ZLVWHGÃ3DLUÃ% TPA* TPB*

55Ω

5ΚΩ

+ 3RUWÃ6WDWXV + Port_Status TpBias 7ZLVWHGÃ3DLU 5HFHLYHU 0.8V %LDVÃ6RXUFH &DEOH 7ΚΩ 7ΚΩ 0.3 µf for (Common to all ports) 6HJPHQW 3 port node 55Ω

TPB ` TPA 7ZLVWHGÃ3DLUÃ% TPB* TPA* 7ZLVWHGÃ3DLUÃ$

55Ω

5ΚΩ

Note that both signaling pairs have the bias voltage permanently applied once another node is attached. Each node detects the bias voltage being applied by the node on the opposite end of the cable. A port status receiver continuously compares 0.8vdc reference voltage to the voltage on the cable. When a node is attached to a given port, the bias voltage causes the cable voltage to rise above 0.8vdc, thereby signifying the attachment of a node. Table 6-1 gives the thresh- old voltages for the port receiver. When a previously attached node is removed from the network, the bias voltage will be also removed, causing the port status receivers to detect node removal.

98 Chapter 6: The Electrical Interface

Table 6-1: Port Status Voltage States

Port_Status Common Mode Input Signal State (vdc)

Node Detached TPB input ≤ 0.6v

Indeterminate 0.6v < TPB input < 1.0v

Node Attached TPB input ≥ 1.0v

IEEE 1394a Device Attachment/Detachment

The port suspend feature introduced by the 1394a supplement permits port circuitry to enter a low power state. In this state only TpBias and port connect status monitoring takes place. A suspended port is required to remove TpBias to confirm that it has entered the suspended state. A 1394-1995 node connected to the suspended port would detect the removal of TpBias and assume that the node had been detached, when in fact it is still connected but suspended. To dif- ferentiate between a suspended port and a detached node, new circuitry has been added to 1394a compliant nodes.

When a port enters the suspend state it must activate its port connection detect circuit (new to 1394a). This circuit monitors the physical connection between suspended ports. Figure 6-2 illustrates the connection detect circuitry. In the absence of TpBias, the connect_detect receiver will recognize detachment of a node. The current source ICD must not exceed 76µA to ensure that the Port_Status receiver of the attached node does not exceed 0.4 vdc. If the attached node is removed, the input voltage at the connection detect circuit will rise above 0.4 vdc because the current path to ground will have been removed. This permits the port to recognize that the previously attached node has been disconnected.

Note that the connection_detect receiver is only valid when TpBias has been disabled. TpBias is removed when a port is either suspended, disabled, or disconnected.

99 7 Arbitration

The Previous Chapter

In the previous chapter, the serial bus signaling environment was detailed. The chapter covered recognition of device attachment and removal, arbitration signaling, speed signaling, and data/strobe signaling. This Chapter

This chapter details the arbitration process. It defines the various types of arbitration including isochronous and asynchronous arbitration, as well as the newer arbitration types defined by the 1394a supplement. The Next Chapter

Asynchronous transactions exist in three basic forms: reads, writes, and locks. The next chapter details the asynchronous packets that are transmitted over the bus.

Overview

Arbitration is based on guaranteed bus bandwidth for isochronous channels and a fairness interval for asynchronous channels. Arbitration begins when a node recognizes a period of bus idle time, thereby indicating the end of the previous transmission. The period of bus idle time, or gap timing, varies between isochronous and asynchronous transactions as follows:

• isochronous gap — the period of bus idle time during isochronous data transmission that must be observed prior to the arbitration for the next isochronous transaction. The isochronous gap detection must be between 0.04µs and 0.05µs.

141 FireWire System Architecture

• subaction gap — the period of bus idle time during asynchronous data transmission that must be observed prior to arbitration starting for the next asynchronous transaction. This gap can be tuned so that arbitration can begin as early as possible without interfering with the normal completion of a subaction and its subsequent acknowledgment.

The first discussion in this chapter focuses on arbitration signaling because the arbitration signaling protocol is identical for both isochronous and asynchronous transactions. Next, the arbitration services are reviewed that are used by the link layer to request ownership of the bus via the physical layer. Since the arbitration process for asynchronous transactions is distinctly different from the arbitration process used for isochronous transactions, each topic is discussed separately. Finally, the two arbitration processes are discusses in light of the effect each has on the other. This occurs when a mix of isochronous and asynchronous transactions are being performed at the same time.

Arbitration Signaling

When any node on the bus wishes to perform a transaction it must arbitrate for use of the bus. Arbitration priority is based on which node requesting bus ownership receives grant from the root node. All nodes wishing to obtain bus ownership signal TX_REQUEST toward the root node. Any node that detects the arbitration request on one of its ports must forward the request on toward the root unless it is already signaling request either for itself or another node. Ulti- mately an arbitration request will reach the root node. The root then signals TX_GRANT to the first port on which it detects a RX_REQUEST. When RX_REQUEST from two nodes vying for control of the bus happen to reach the root at the same time, the root signals TX_GRANT on the requesting port that is designated with the lower port number.

Table 7-1 reviews the arbitration line states used during arbitration.

142 Chapter 7: Arbitration

Table 7-1: Arbitration Line States During Normal Arbitration

Line State Line State Line State Name Transmitted Line State Name Received/decoded Transmitted Received Arb_A Arb_B Arb_A Arb_B

TX_REQUEST Z 0 RX_REQUEST 0Z (child node) (parent node)

TX_GRANT (parent Z 0 RX_GRANT (child node) 0 0 node)

TX_REQUEST removed Z Z RX_REQUEST_CANCEL Z0 by child node (parent node detects its own TX_GRANT)

TX_DATA_PREFIX 01RX_DATA_PREFIX10 (parent node) (child node)

Figure 7-1 illustrates a community of nodes residing on the serial bus with two nodes attempting to win use of the bus. Nodes A and E both signal an arbitration request (TX_REQUEST) to their parent nodes. Node A’s TX_REQUEST is detected by node B, whose job it is to forward the request on to its parent. At the same time node E also signals TX_REQUEST to its parent (the root). Since Node E connects directly to the root node, its request reaches the root before Node E’s request. When the root detects the request, it recognizes that a node is requesting use of the bus.

This example highlights the natural priority that exists due to the topology of the serial bus. Since the root is the source of the arbitration grant, it has the highest priority, followed by the nodes that connect directly to the root (lowest numbered ports first), etc. Natural arbitration priority for a given node then is based on the distance from the root node relative to other nodes. Note however, that nodes may not send TX_REQUEST at the same time; thus, natural priority does not guarantee that a node closer to the root will necessarily win arbitration over one further away from the root.

143 FireWire System Architecture

Figure 7-1: Two Nodes Start Arbitration by Signaling an Arbitration Request

Root Node D 12

idle

4 1 Branch Node C Leaf Node E 123

idle idle

2 1 Node B Branch L eaf Node F 1 2

1 Nodes A and E signal Node A TX_REQUEST to their L eaf parent nodes

Upon detecting a request on its port number two, the root immediately returns TX_GRANT (to node E). The root also signals a DATA_PREFIX to all other ports (just port 1 in this case) to notify all nodes downstream from the root that it has granted the buses to a node and that a packet can be expected (See Figure 7-2).

When node E recognizes the TX_GRANT, it removes its request and begins packet transmission. Note that node C forwards the DATA_PREFIX that it receives from the root to all of its children. Node B detects this DATA_PREFIX from node C at the same time that it signals TX_REQUEST to node C. The DATA_PREFIX causes node B to stop signaling TX_REQUEST and to forward the DATA_PREFIX to its child port (node A). Node A detects the DATA_PREFIX and removes its TX_REQUEST, and recognizes that another node has won control of the bus.

144 Chapter 7: Arbitration

Figure 7-2: Arbitration Signaling Reaches Root Node and TX_GRANT Returned

Root Node D 12

4 1 Branch Node C L eaf Node E 123

2 1 Node B Branch Leaf Node F 1 2 Nodes A and E signal TX_REQUEST to their parent nodes

1 Node D (the root) signals TX_GRANT to Node E L eaf Node A Node D (the root) and Node C signal data_prefix to its other port

Figure 7-3 illustrates the state of the bus once the arbitration has been com- pletely resolved. For a review of arbitration signaling line states, see “Line States During Normal Arbitration” on page 112.

Arbitration Services

When a link wishes to transmit a packet it must first request the PHY to obtain ownership of the bus. The type of packet to be transmitted determines the type of request that the LINK will make. The link layer must use one of four arbitration services when requesting bus ownership:

• Fair arbitration service (used when transmitting an asynchronous packet) • Priority arbitration service (used when transmitting a cycle start packet or an asynchronous packet of high priority)

145 8 Asynchronous Packets

The Previous Chapter

The previous chapter detailed the arbitration process. It defined the various types of arbitration including isochronous and asynchronous arbitration, as well as the newer arbitration types defined by the 1394a supplement. This Chapter

Asynchronous transactions exist in three basic forms: reads, writes, and locks. This chapter details the packets that are transmitted over the bus during asynchronous transfers. The Next Chapter

The next chapter discusses isochronous transactions. These transactions are scheduled so that they occur at 125µs intervals. The chapter discusses the role of the application, link, and PHY in initiating and performing isochronous transactions. Format of the packet used during isochronous transactions is also detailed.

Asynchronous Packets

The link layer controller (Link) is responsible for constructing the 1394 packets required to transmit data over the 1394 serial bus. Packet contents vary depending upon the transaction type (See Table 8-1 on page 167 for transaction type codes). Data comprising the packet is transferred to the physical layer controller (PHY) via an interface defined by the specification. The link to physical layer interface is defined in Chapter 11.

165 FireWire System Architecture

Figure 8-1 on page 166 illustrates the basic construct of primary request packets that are used during asynchronous packet transactions. Primary packets have a standard header format and an optional data block, whose presence depends on the amount of data to be transferred.

Figure 8-1: Primary Asynchronous Packet Format

10-bits 6-bits 48-bits Bus Node Address location within target node

msb (transmitted first) destination_ID tl rt tcode pri

l source_ID destination_offset

u destination_offset

s t Packet type-specific data

header_CRC

e data block

o r last quadlet of data block (padded if necessary)

e data_CRC

lsb (transmitted last)

166 Chapter 8: Asynchronous

Table 8-1: Asynchronous Transaction Codes

Transaction Name Code (Hex)

Write Request for data quadlet 0

Write Request for data block 1

Write Response 2

Reserved 3

Read request for data quadlet 4

Read request for data block 5

Read response for data quadlet 6

Read response for data block 7

Cycle start 8

Lock request 9

Asynchronous Streaming Packet A

Lock response B

Reserved C

Reserved D

Used internally by some link E designs. Will not be standardized

Reserved F

Data Size

The data payload of asynchronous packets is limited to minimize the possible overrun of asynchronous transaction time into the isochronous transaction time. Recall that during a 125µs cycle a mix of isochronous and asynchronous transactions may be performed. The data payload limit corresponds to transmission speed as listed in Table 8-2 on page 168.

167 FireWire System Architecture

Table 8-2: Maximum Data Payload for Asynchronous Packets

Cable Maximum Data Payload Size Speed (Bytes)

100Mb/s 512

200Mb/s 1024

400Mb/s 2048

800Mb/s 4096

1.6Gb/s 8192

3.2Gb/s 16384

Write Packets

Three packets are defined for performing write transactions, including two forms of write request packets. Each of the following packet types is illustrated in the following pages and each field within the packet is defined: • Write Quadlet Request packet (Figure 8-2 on page 169 & Table 8-3 on page 169). • Write Data Block Request packet (Figure 8-3 on page 171 & Table 8-4 on page 172). • Write Response packet (Figure 8-4 on page 173 & Table 8-5 on page 173).

168 Chapter 8: Asynchronous

Figure 8-2: Write Request — Quadlet Format

msb (transmitted first) destination_ID tl rt tcode pri source_ID destination_offset destination_offset quadlet_data

header_CRC

lsb (transmitted last)

Table 8-3: Write Request — Quadlet Packet Components

Name Abbrev. Description

Destination destination_ID Combination of the bus address and Identifier physical ID of the node. Contains the address of the requesting node.

Transaction label tl A label specified by the requester that identifies this transaction. This value, if used, is returned in the response packet.

Retry code rt This code specifies whether this packet is an attempted retry and defines the retry protocol to be followed by the target node. 00 = Retry_1 (first attempt) 01 = Retry_X 10 = Retry_A 11 = Retry_B

169 9 Isochronous Packet

The Previous Chapter

Asynchronous transactions exist in three basic forms: reads, writes, and locks. The previous chapter discussed the asynchronous transaction types and related packets that are transmitted over the bus. This Chapter

Isochronous transactions are scheduled so that they occur at 125µs intervals. This chapter discusses isochronous transaction issues and the format of the packet used during isochronous transactions. The Next Chapter

Next, the various types of PHY packet are discussed. The role of each PHY packet is included, packet format is specified, and the fields within each packet are detailed.

Stream Data Packet

Isochronous transactions use a single data packet to perform a multicast or broadcast operation to one or more nodes. Target nodes are identified by a channel number rather than by a node ID and destination offset address. An isochronous transaction contains only a request phase with no acknowledgment and no response. An isochronous transaction uses a streaming data packet. The packet format is illustrated in Figure 9-1 on page 200 and each field is defined in Table 9-1 on page 201.

199 FireWire System Architecture

The stream data packet (know as the isochronous data block packet in the IEEE 1394-1995 specification) was supported solely for the isochronous bus period by the 1995 specification. The data stream packet has now been specified to occur during either the isochronous or asynchronous time by the 1394a supplement.

Prior to using an isochronous stream packet, the application must first obtain a channel number from the isochronous resource manager node. When a stream data packet is performed during the isochronous time, the application must all obtain the necessary bus bandwidth from the isochronous resource manager.

Figure 9-1: Format of an Isochronous Stream Packet

msb (transmitted first) data_length tag channel tcode sy

header_CRC

data block

last quadlet of data block (padded if necessary)

data_CRC

lsb (transmitted last)

200 Chapter 9: Isochronous Packet

Table 9-1: Isochronous Stream Packet Components

Component Name Abbreviation Description

Data Length data_length Length can be any value from zero to all ones (FFFFh). When the data length is not a multiple of four bytes, then the talker must pad the last quadlet field with zeros.

Isoch Data Format Tag tag The value of 00b indicates that the isochronous data is unformatted. All other values are reserved.

Isoch Channel Number Channel Specifies the isochronous channel number assigned to this packet. Channel numbers are a simplified means of addressing. Channel numbers are assigned to a node for talking or listening.

Transaction code tcode The transaction code for an isochronous data block transaction is Ah.

Synchronization Code sy Application specific.

Header CRC header_CRC CRC value for header.

Data Block Payload data_field Data to be transferred by the talker. Last quadlet of data field must be padded with zeros if necessary.

Data Block CRC data_CRC CRC value for the data field.

Isochronous Data Packet Size

The maximum size of an isochronous transaction based on the 1394-1995 specification was limited to the maximum isochronous bus time, or 100µs. The 1394a supplement further constrains the maximum data block size to the values shown in Table 9-2 on page 202.

The specification describes a null isochronous stream packet. This packet has a data_length value of zero, making the size of this packet only 64-bit, or 2 quadlets. This is the only packet other than PHY packets with a length of 64-bits.

201 FireWire System Architecture

Table 9-2: Maximum Data Payload for Isochronous Packets

Cable Maximum Data Payload Size Speed (Bytes)

100Mb/s 1024

200Mb/s 2048

400Mb/s 4096

800Mb/s 8192

1.6Gb/s 16384

3.2Gb/s 32768

Isochronous Transaction Summary

The following illustrations summarize the standard and concatenated forms of isochronous transactions:

Figure 9-2: Non-Concatenated Isochronous Transactions

First Channel Second Channel Third Channel

isoch isoch arbpacket gap arb packetgap arb packet

Data Prefix Data End

202 Chapter 9: Isochronous Packet

Figure 9-3: Concatenated Isochronous Transactions - If Sent by Same Node

First Channel Second Channel Third Channel Fourth Channel

arb packet packet packet packet

Data Prefix Data End

203 10 PHY Packet Format

The Previous Chapter

Isochronous transactions are scheduled so that they occur at 125µs intervals. The previous chapter discussed isochronous transaction issues and the format of the packet used during isochronous transactions. This Chapter

This chapter discusses the various types of PHY packets. The role of each PHY packet is discussed, packet format is specified, the fields within each packet are detailed. The Next Chapter

The next chapter details the signaling interface between the link and PHY layer controller chips.

Overview

Transactions discussed to this point target memory-mapped address locations within the node or access a memory buffer identified by a channel number. These address locations reside physically in the link layer, transaction layer, or application layer. The PHY contains no memory-mapped address locations. Some packets however, are designed to access registers within the PHY. These register locations are not mapped within the 256TB of address space allocation to each node and can only be accessed by the local application or via a PHY packet. The PHY packet types defined by the IEEE 1394-1995 specification include: • Self Identification (Self-ID) packet • Link-On packet • PHY Configuration packet

205 FireWire System Architecture

The 1394a supplement defines extended PHY packet types that include:

• Ping packet • Remote Access packet • Remote Reply packet • Remote Command packet • Remote Confirmation packet • Resume packet

All PHY packets are transmitted at the base rate of 100Mb/s. This is to ensure that all PHYs are able to receive PHY packet regardless of the maximum transmission speed that they support.

PHY packets are used for various bus management functions the following sections discuss each packet type and describes the bus management functions controlled or affected by each packet.

PHY Packet Format

The general format of a PHY packet is illustrated in Figure 10-1. A PHY packet is eight bytes in length (one octlet). The first four bytes (one quadlet) contain the PHY packet information. They are followed by four more bytes used for error checking. The second quadlet contains the 1’s complement (logical inverse) of the first quadlet.

Figure 10-1: General Format of PHY Packet

Packet Identifier

00b phy_ID Packet-specific information

logical inverse of first quadlet

206 Chapter 10: PHY Packet Format

A PHY recognizes a PHY packet if the total packet length is 64-bits. No other packet has a size of 64-bits except for the possibility of a steam packet that contains no data. A PHY recognizes the difference between a null stream packet and a PHY packet because the stream packet uses a 32-bit CRC, whereas, a PHY packet uses a 32-bit 1’s complement of the first quadlet.

The PHY packet types are differentiated by the first two bits of the packet as follows:

• 00 = PHY Configuration packet • 01 = Link-on packet • 10 = Self-ID packet

The extended packets are identified using the gap_count field of the PHY configuration packet format (“Extended PHY Packets” on page 214).

Self-ID Packets

During bus configuration each node must assign itself a node ID and notify other nodes of its serial bus capabilities. These actions take place during the self-identification process that occurs following a bus reset and tree identification. Each node broadcasts from one to three self-ID packets during the self- identification process. Note that this packet is created within the PHY layer.

Self-ID Packet Zero

Self-ID packet zero is illustrated in Figure 10-2. The format of self-ID packet zero is the same for 1394-1995 and the 1394a supplement. However power class fields within Self-ID packet zero are defined differently. Table 10-1 defines the fields for 1394-1995 and Table 10-2 on page 209 lists the new power class field definitions for 1394a. Note that self-ID packet zero permits identification of only three node ports (ports 0-2). If additional ports are implemented, then one or more self-ID packets is required.

The 1394a specification redefines the port status information within the self-ID packets. The four new states are defined as:

• 00b = port not present • 01b = port not active (may be either suspended, disabled, or disconnected) • 10b = port active and connected to parent node • 11b = port active and connected to child node

207 FireWire System Architecture

Figure 10-2: Format of Self-ID Packet Zero

PVE 7UDQVPLWWHGÃILUVW TrysD9Qhpxrar ufD9 G thfp r p ! v

Gtvphyvr rssv "!iv 7UDQVPLWWHGÃODVW OVE

Table 10-1: Contents of the Self-ID Packet Zero — 1394-1995

Field Field Name Comments Code

10 Packet identifier Transmitted at the beginning of the packet to identify this packet as a self-ID packet.

Phy_ID Physical ID Physical Identifier of the node sending this packet.

L Link active Set to indicate that Link and Transaction layers are active.

gap_cnt Gap count Current value of PHY_CONFIGURATION.gap_count field within the PHY register.

sp PHY speed Nodes speed capabilities: 00 = 98.304 Mb/s 01 = 98.304 Mb/s and 196.608 Mb/s 10 = 98.304 Mb/s,196.608 Mb/s and 393.216Mb/s 11 = Reserved

del PHY delay Specifies the maximum repeater delay across this node. 00 = <= 144ns (~14/BASE_RATE) 01 = Reserved 10 = Reserved 11 = Reserved Note: This field is reserved in the 1394a specification. PHY delay is obtained by reading the PHY delay and PHY jitter fields within the 1394a PHY registers.

c Contender When set and Link active is set, this node is a contender for the role of bus or isochronous resource manager.

208 Chapter 10: PHY Packet Format

Table 10-1: Contents of the Self-ID Packet Zero — 1394-1995 (Continued)

Field Field Name Comments Code pwr Power class Specifies power consumption and source characteristics: 000 = Node does need bus power and does not repeat power 001 = Self powered & provides 15W (minimum) to bus. 010 = Self powered & provides 30W (minimum to bus. 011 = Self powered & provides 45W (minimum to bus 100 = May be powered by bus and uses up to 1W. 101 = Powered by bus & uses 1W. Additional 2W needed to power link layer higher layers. 110 = Powered by bus & uses 1W. Additional 5W needed to power link layer higher layers. 111 = Powered by bus & uses 1W. Additional 9W needed to power link layer higher layers. p0.. p2 Port number Specifies port status:

00 = Port not present 01 = No connection to other node 10 = Connected to parent node 11 = Connected to child node i Initiated reset This node initiated the current bus reset before receiving reset signaling. (Optional, if not used returns zero) m More packets More packets follow this one to report additional port status.

Table 10-2: Definition of Power Class Values Within “Pwr” Field of Self-ID Packet—1394a

POWER_CLASS Power Consumption and Source Characteristics Code (binary)

000 Node does not require bus power nor repeat bus power.

001 Node is self-powered and provides 15W (minimum) to the bus.

010 Node is self-powered and provides 30W (minimum) to the bus.

209 11 Link to PHY Interface

The Previous Chapter

The previous chapter discussed the various types of PHY packet. The role of each PHY packet was discussed, the PHY packet formats was specified, and the fields within each packet were detailed. This Chapter

This chapter details the signaling interface between the link and PHY layer controller chips. The Next Chapter

The next chapter discusses the transaction retries that can occur when the recipient of a packet is busy (e.g. has a buffer full condition). Two retry mechanisms are defined by the 1394 specification: single and dual phase. Each type of mechanism is discussed.

Overview

The IEEE 1394-1995 specification describes the interface between the Link and PHY chips. This interface definition is included in the 1394-1995 Appendix and is labeled as informative (not a required implementation). However, the 1394a supplement requires that this interface be used if the node is implemented with separate PHY and Link layer components. Note that there is no requirement that a node be designed with separate Link and PHY chips. These functions could be integrated within the same silicon, in which case the interface between these functions is implementation specific. The motivation for requiring the standard interface is to promote interoperability between PHY and Link layer chips from different manufacturers.

221 FireWire System Architecture

The Interface Signals

Figure 11-1 on page 222 illustrates the synchronous interface between the link and PHY. The interface is used by both the link and PHY. The link layer chip initiates transactions by sending requests to the PHY to send a packet, and the PHY forwards packets that it receives from the 1394 cable to the link via the interface. The function of each Link/PHY interface signal is defined in Table 11- 1 on page 223.

Figure 11-1: Interface Between the Link and PHY

Link Layer Chip

B D

L L S L C D

i P R

t [

l 0

S [

O q 7

]

Physical Layer Chip (PHY)

TPA TPB

222 Chapter 11: Link to PHY Interface

Table 11-1: Link/PHY Signal Interface

Name Driven by Description

D[0:7] Link or PHY Data — packet data is delivered via the data lines. The number of data lines used depends on the speed supported as follows: D[0:1] = 100Mb/s D[0:3] = 200Mb/s D[0:7] = 400Mb/s

Ctl[0:1] Link or PHY Control — defines the state of the interface when being driven by the Link or PHY (e.g. idle, sending status, transmitting or receiving a packet).

LReq Link Link Request — this serial interface is used by the link to initiate a request. Is also used to request access to local PHY registers.

SClk PHY 49.152MHz clock — the clock used to clock data between the PHY and Link.

LPS Link Link power status — indicates whether the link is powered or not.

Link On PHY Link has been powered-on via a link-on packet.

Direct Neither Direct connection between Link and PHY interface signals is implemented when this pin is asserted. When deasserted an isolation barrier is implemented.

Backplane Neither Pulled high for backplane PHY implementation.

Clk25 Neither Pulled high if SClk is 24.576. (backplane environment only).

223 FireWire System Architecture

Sharing the Interface

The bi-directional control signals specify the type of transmission being made via the data lines. The type of transmission depends in part on whether the link or PHY is transmitting the data. The default owner of the PHY/link interface is the PHY. The link gains ownership of the interface via the LReq lines to transfer a packet to the PHY, which then transmits the packet over the cable. Ownership of the interface returns to the PHY after the link has completed sending the packet. The current state of the interface is defined by the control signals.

PHY Initiated Transfers

The PHY uses the interface to transfer information to the node’s link layer controller. The information transferred includes: • packets received from the serial bus that are forwarded to the link layer controller. • contents of local PHY registers that have been requested by the link. • status information which is reported to the link.

When the PHY owns the interface, one of four conditions may exist on the interface. The current state of the interface defines these conditions, which can be determined by monitoring the interface control lines (Ctl[0:1]. Table 11-2 lists the control signal definitions when the PHY owns the bus.

Table 11-2: Control Signal Definition with PHY Driving

Ctl[0:1]b Type Description

00 idle No activity.

01 status PHY is sending status information to link.

10 receive Incoming packet is being transferred from PHY to link via data lines, or PHY generated data being sent to the cable and also to the link via the data lines (e.g. self-ID packets, remote command and reply packets).

11 grant PHY is granting use of the bus to the link so that it can send a packet.

224 Chapter 11: Link to PHY Interface

Idle State

Interface is idle indicating that neither the link nor the PHY currently have data to transfer. Status State

When the PHY signals status via the control lines, it is sending status information across the data lines. Status transmission occurs when one of several PHY or cable events have occurred. These events include: • An arbitration reset gap has been detected • A subaction gap has been detected • A cable reset has been detected • Cable power failure • Looped topology has been detected during the Bus ID procedure • Arbitration state machine has timed out • Bias change at a disabled port has been detected

Also, PHY register data is returned to the link in response to a PHY register read request. Receive State

When the receive state is being signaled, the PHY is transferring an incoming data packet from the 1394 bus to the link for decoding, or is forwarding PHY generated packets to both the cable and the link. PHY packets include self-ID packets, configuration packet, link-on packet, and all extended PHY packets. Grant State

Grant is signaled to the link to notify it that it can begin transmitting a packet. This is done only after the link has issued a packet request via the LReq line and the PHY has obtained ownership of the 1394 bus.

225 12 Transaction Retry

The Previous Chapter

The previous chapter detailed the signaling interface between the link and PHY layer controller chips. This interface is now required by 1394a implementations of a PHY or link controller chip. This Chapter

This chapter discusses transaction retries that occur when the recipient of a packet is busy (e.g. has a buffer full condition). Two retry mechanisms are defined by the 1394 specification: single and dual phase. Each type of mechanism is discussed. Software may also initiate retries for transactions that fail. The Next Chapter

The next chapter overviews the configuration process comprising the initialization, tree ID, and self-ID phases. Once self-ID completes, additional configuration may optionally take place in the form of bus management activities that are also reviewed in this chapter.

Overview

Asynchronous transaction retry is supported by 1394 and may occur under three circumstances:

• Node is Busy • Failed Packet Transfer • Node is Locked

The specification defines a retry protocol to be used when the recipient of a packet is temporarily busy (e.g. due to a buffer full condition or a locked transaction is being performed). This form of retry is handled by hardware. When packet transmission fails due to an error condition, the requesting node may re- initiate the transaction under software control.

247 FireWire System Architecture

Busy Retry

Serial bus nodes employ separate request and response queues. When a node has a queue full condition (busy), the link layer must return an acknowledge packet that specifies the status of the packet just transferred. The acknowledge codes returned indicate if the node was busy, and if so which type of retry that the target node supports. Table 12-1 lists the retry codes that can be returned in the acknowledge packet. Note that retries may be performed for both request and response packet transfers.

Table 12-1: Retry Codes Returned by Busy Node

Code Name Description

4 ack_busy_x The packet was not accepted by the target node, but may be accepted when retried.

5 ack_busy_A The packet was not accepted by the target node because the node was busy. The node will accept the data when not busy during the next retry phase A.

6 ack_busy_B The packet was not accepted by the target node because the node was busy. The target node will accept the packet when not busy during the next occurrence of a retry B.

The First Packet Transmission Attempt

When the application wishes to initiate an asynchronous request or a response, it uses the “transaction data request” service or the “transaction data response” service, respectively. The transaction layer generates a “link data request” in response and specifies a retry code of retry_1 for the first attempt of sending a subaction. When the target node receives the packet, it may be able to accept the packet or it may initiate a retry in the event of a full queue. The retry behavior is described in the following sections.

248 Chapter 12: Transaction Retry

Single Phase Retry

A node that receives a packet for the first time will detect a retry code of retry_1. If the node is busy, it returns an acknowledge code of ack_busy_x indicating that it supports single phase retries. The transmitting node will send the packet again but this time it will return the retry_x code that it received in the acknowledgment packet. Each time the transaction is retried a retry code of retry_x is used. The transaction is retried until it is successful or until the retry limit is exceeded. The retry limit is specified in the BUSY_TIMEOUT register (offset 210h in CSR space) illustrated in Figure 12-1. Note that the maximum number of single phase retries is limited to sixteen by the 4-bit retry_limit field.

Single phase retry provides no scheduling mechanism to handle older transactions that may have been retried many times prior to handling newer ones.

Figure 12-1: BUSY_TIMEOUT Register Showing Single Phase Retry Count

reserved second_limit cycle_limit reserved retry_limit

Sending-Node Retry Behavior (Outbound Retry)

The state machine diagram in Figure 12-2 illustrates the actions taken by the transaction layer of a node that is sending packets to a sometimes-busy node. Two states are defined in the state diagram Outbound Single Retry zero (OSR0): “Ready to Send” and Outbound Single Retry one (OSR1): “Pending Retry.” The following list describes each of the state transitions.

• OSR0 — The initial entry into the Ready to Send state occurs when the link issues an initialization or reset control request to the transaction layer. • OSR0 to OSR0 — This transition occurs when the subaction that has been just sent receives a normal acknowledgment (i.e. an acknowledgment other than any type of ack_busy). • OSR0 to OSR1 — The subaction just sent receives an ack_busy acknowledgment of any type. • OSR1 to OSR1 — The subaction that was just retried receives one of the three forms of ack_busy. The retry count has not been exceeded. And the transaction layer has not chosen to requeue the pending retry.

249 FireWire System Architecture

• OSR1 to OSR0 — This transition may be taken as a result of three separate conditions: 1. The transaction layer receives an acknowledge code other than ack_busy. And the packet has been sent successfully. 2. The retry count has been exceeded and the transaction layer terminates further retries of this packet. The failed transaction is reported to the application. 3. The transaction layer receives one of the forms of ack_busy in response to the packet just retried. The retry count has not yet expired. And the transaction layer chooses to requeue to pending retry.

Figure 12-2: Outbound Retry State Machine — Single Phase

Normal ack ack_busy_X Received Received ack_busy_A/B/X received

OSR0: OSR1: Ready to Send Pending Retry

1. ack other than busy received, or 2. retry count exceeded, or 3. ack_busy_A/B/X received, retry count not exceeded, and pending retry requeued.

Receiving-Node Retry Behavior (Inbound Retry)

The state machine diagram in Figure 12-3 illustrates the actions taken by the transaction layer of a sometimes-busy node when it receives packets from other nodes. Two states are defined by the state diagram: Inbound Single Phase Retry zero (ISR0): Accept All and Inbound Single Phase Retry (ISR1): Busy All. The state transitions are described below.

• ISR0: This state is entered when the link layer sends an initialization or reset control request to the transaction layer. In this state the node is ready to

250 Chapter 12: Transaction Retry

accept primary packets from other nodes. • ISR0 to ISR0 — This transition occurs when the node receives a primary packet and the transaction layer resources are available to accept this packet. The transaction layer returns a data response to the link and specifies the appropriate acknowledge code (not busy). • ISR0 to ISR1 — The transaction layer resources are no longer available (i.e. the transaction layer is now busy). • ISR1 to ISR1 — The transaction layer receives a primary packet and the resources are not available; thus, a link data response is issued to return an acknowledge packet set to ack_busy_X. • ISR1 to ISR0 — The transaction resources have become available (i.e. the transaction layer is no longer busy).

Figure 12-3: Inbound Retry State Machine — Single Phase

Packet received Packet received Normal ack returned ack_busy_X returned ction resources not nsa avail tra able

ISR0 ISR1 Accept All Busy All

t ble rans ai la action resources av

Dual Phase Retry

Just as with single phase retry, the initial access sends a retry code of retry_1. However, nodes that support dual phase retries return a retry acknowledge code of either ack_busy_A or ack_busy_B. When the initiator of the packet attempts packet transmission again, it specifies the same retry code as it received in the acknowledge packet.

To explain the actions of the target node, assume that it just received a packet that must be retried. The busy node returns an ack_busy_A code and waits for the retry to occur. However, if other packets target this same node with retry codes of retry_1, the target returns ack_busy_B retry codes. Since the A packet

251 13 Configuration Process

The Previous Chapter

The previous chapter discussed transaction retries that occur when the recipient of a packet is busy (e.g. has a buffer full condition). Two retry mechanisms are defined by the 1394 specification: single and dual phase. Each type of mechanism is discussed. This Chapter

This chapter overviews the configuration process comprising the initialization, tree ID, and self-ID phases. Once self-ID completes additional configuration may optionally take place in the form of bus management activities that are also reviewed in this chapter. The Next Chapter

The next chapter details the bus reset phase of the cable configuration process.

Overview

1394 device configuration occurs locally on the serial bus without the intervention of a host processor. Each time a new device, or node, is attached or removed from the serial bus, the entire bus is reset and reconfigured. This chapter overviews the cable configuration process and subsequent chapters detail each step in the procedure.

Three primary procedures must be performed during cable configuration:

• Bus initialization • Tree identification • Self identification

265 FireWire System Architecture

Since cable configuration does not require interaction with the host processor, no single node can be identified as a root node based simply on the serial bus physical topology. Rather, a single node on the serial bus must be identified, via the Tree ID process, as the root node. The root node performs certain bus management functions for all devices residing on the bus. For example, the root node must take responsibility for establishing the intervals at which isochronous transactions are to be performed across the bus.

Since it is unknown at configuration time whether a given node supports 100, 200, or 400Mb/s transfers, all configuration transfers take place at the base rate of 100Mb/s.

During cable configuration the bus is reset and all 1394 bus traffic stops while the new topology is determined (during tree-ID) and while all nodes assign themselves a node ID (during Self-ID). All asynchronous transactions that are pending completion when cable configuration begins must be discarded and requeued by the local application once configuration completes. This is necessary because the node ID values used to target a given node may change due to a topology change. Consequently, all asynchronous transactions pending prior to reset may target the wrong node following a reset. Since isochronous transfers identify target(s) based on channel numbers (which are not affected by cable configuration), they can resume where they left off after configuration completes.

The speed at which the cable configuration process completes is obviously important since all pending transactions stopped during configuration. Figure 13-1 illustrates reset, tree-ID, and self-ID timing for the 1394-1995 environment. The following chapters detail each phase of the cable configuration process.

Figure 13-1: Overall Cable Configuration Time

8hiyr8svt hvUvvt 8 vivsrhpuuhrr hyypsvt hvvr 7hrq%"Iqr

1RGHÃ$GGHG 6HOIÃ,' RUÃ5HPRYHGÃ 7UHHÃ,' 6WDUWV IURPÃ%XV 6WDUWV PV aVÃÃV V

%XVÃ5HVHWÃ7LPH 7UHHÃ,'Ã7LPH 6HOIÃ,'Ã7LPH

266 Chapter 13: Configuration Process

Bus Initialization (Bus Reset)

Reset occurs when power is applied to (e.g. initial power up) or removed from a node or when a node is attached to or removed from the 1394 bus. This forces all nodes to return to their initialized states. If the bus has been configured previously, then the topology will have been established. However, reset also clears all topology information from the nodes. Figure 13-2 illustrates a family of 1394 nodes with topology established and a subsequent view of the topology immediately following reset. Note that after reset all topology information is cleared, leaving each node at the same hierarchy in the topology. Reset initializes the bus and prepares each node to begin the tree identification process.

Figure 13-2 also illustrates that some nodes connect to only one other node, while others connect to one or more nodes. Nodes having a single port are termed leaf nodes (nodes A and E), and nodes with two or more ports are termed branches (nodes B, C, and D). The node labels A-E are provided for reference purposes only. Each node assigns a number to each of its ports, thereby providing a unique label for port identification. Port numbers are used during the self_ID process to determine the order (lowest to highest number) that ports are identified and also during normal arbitration as a tie breaker.

Reset signaling is sensed by the PHY layer of each node via the arbitration signal lines. Each node receiving RESET propagates reset signaling to the other nodes that it attaches to (if any), thereby ensuring that all nodes are reset. After each node is reset it enters the idle state and waits for a sufficient period of time to ensure all nodes have received a RESET and have entered their idle states. From the idle state all nodes begin the tree identification process.

267 FireWire System Architecture

Figure 13-2: Example of Bus Topology after Bus Reset

B Branch

1, c 2, c

1, p 1, p A C Leaf Branch 22,33, c c4

1 2, p 1, p D E Leaf Leaf

Family of Nodes Before Reset

1 2 3 12 12 3 4 12 1 AB C DE

Family of Nodes After Reset

Tree Identification (The Family Tree)

The tree identification process defines the topology of the bus based on the new family of devices that now reside there. After tree identification, one node will have gained status as the root node. Prior to tree identification, each node knows whether it connects to a single 1394 node (when it is a single leaf on the bus) or more than one node (when it is a branch on the bus). Any node, a leaf or a branch, may become the root node. Figure 13-3 illustrates a series of nodes (branches and leaves) connected to the bus.

268 Chapter 13: Configuration Process

Figure 13-3: Example of Bus after New Device Is Attached and Bus Is Reset

1 12123412 1 1 2 AB C DE F

The tree identification process results in each port being identified as either a parent or a child. A node having a parent port designation means that the node at the other end of the cable is closer to the root, and that node will have identified its port as a child. A port identified as a child node points to a child node that is further away from the root. Any node having all of its ports identified as child ports becomes the root hub. A node can become the root node regardless of where it connects into the network of nodes.

Figure 13-4 illustrates the same family of nodes pictured in Figure 13-3, but after tree identification has completed. In this example, it is assumed that node D has been identified as the root node, thus both of its ports are identified as child ports. All other nodes have a least one of their ports identified as a parent port, meaning that there is another node higher in the topology hierarchy. Once tree identification has completed, the root node initiates the self-identification process.

Chapter 15 details the tree identification process and defines how the root node is selected.

269 14 Bus Reset (Initialization)

The Previous Chapter

The previous chapter provided an overview of the configuration process. The process comprises Initialization, Tree ID, Self-ID phases, and bus management activities. This Chapter

This chapter details the bus reset phase of the cable configuration process. Ini- tialization begins with the assertion of a bus reset by a given node on the bus. This chapter discusses the reset enhancements introduced by the 1394a supplement; debouncing the bias change detection, arbitration (short) bus reset, and new timing parameters. The Next Chapter

Following bus initialization, the tree ID process begins to determine which node will become the root. The next chapter details the protocol used in determining the topology of the nodes.

Overview

Bus reset forces all nodes into their initialization state, thereby initiating the configuration process. Bus reset is initiated under software control or as a result of hardware events as discussed below. Note that assertion of reset signaling by a node does not terminate a transaction currently being performed. When the transaction ends, all other nodes will have their drivers disabled, thus the reset signaling will be detected by all nodes.

273 FireWire System Architecture

When each node receives reset it clears all information related to the bus topology. However, the PHY of each port latches and saves connection status associated with each of its ports (i.e. whether a device is currently attached to each port or not). If a device is removed or attached to a port during reset, the change will be detected at the end of the initialization phase, thereby causing the node to signal reset again, forcing all nodes back into reset.

Sources of Bus Reset

Bus reset is initiated under the following circumstances:

• Bus reset is signaled when power status changes at the PHY. • Bus reset signaled by an attached node. • Node attachment or removal. • PHY detects MAX_ARB_STATE time-out. That is, a PHY stays in any state (except Idle, Tree ID Start, or other state that has an explicit time-out defined) for longer than the MAX_ARB_STATE_TIME. • PHY receives a bus reset request initiated by software.

The following sections describe each type of reset.

Power Status Change

When a locally powered PHY receives a power reset or detects a change in its power state, it must signal a bus reset. No bus reset is required if only the link layer power state changes.

Bus Reset Signaled by Attached Node

When a port detects reset signaled by an attached node it must repeat reset signaling to its other connected ports. This node may be in the process of repeating a packet when the reset is detected at one of its ports. Even if a packet is currently being repeated to that port, the arbitration comparators will detect reset signaling due to 1’s dominance decoding of the arbitration comparator outputs.

274 Chapter 14: Bus Reset (Initialization)

Node Attachment or Removal

If a node’s PHY recognizes that another node has been attached to or removed from one of its ports, it must signal reset to all of its active ports. The PHY must also signal the bus reset event to the link. Node attachment or detachment is detected by a port receiver when it detects a change in the bias voltage. A variety of conditions exist that determines the exact behavior of a node, after it has detected a bias change. These conditions and behaviors are discussed in “Effects of Bus Reset” on page 277.

MAX_ARB_STATE_TIME Expires

The MAX_ARB_STATE_TIME parameter applies to all states within the PHY with the exception of those listed below. When the PHY remains in a given state long enough for the MAX_ARB_STATE_TIME to be detected (200µs min. to 400µs max.), it must signal reset. The PHY states excluded from the MAX_ARB_STATE_TIME limit include:

• Bus Idle • Tree ID Start • Any state that has an explicit time-out value defined

Software Initiated Bus Reset

An application can initiate a bus reset by making a control_request to the node controller software, which in turn issues the request to the link and PHY. In response, the PHY sets its IBR (initiate bus reset) bit, causing the reset to be signaled. When reset signaling ends a reset_complete confirmation is returned to the link and forwarded on to the local application via the transaction layer application.

Bus Reset Signaling

When the PHY receives a reset request, it drives 1s on TPA and TPB for each of its ports. All other nodes receiving reset propagate, or repeat, reset signaling to their other ports. This action ensures that all nodes receive RESET. Figure 14-1 on page 276 illustrates reset being signaled and detected by two attached nodes. Note that even though a child node is currently signaling a TX_REQUEST in an

275 FireWire System Architecture

attempt to gain bus ownership, the reset (1,1) prevails due to 1’s dominate decoding of the received signals.

The duration of reset must be sufficiently long to permit a transaction being performed to complete. The longest reset timing requirement is a minimum reset duration of 167µs.

Figure 14-1: Reset Signaling and Detection

Qh rIqr 8uvyqIqr Sry 6WUREH 73$ 73% 'DWD $UEB$B7[ $UEB%B7[ 'ULYHU 73$ a 73% 'ULYHU

$UELWUDWLRQ Child node $UELWUDWLRQ &RPSDUDWRUV sends TX_Request &RPSDUDWRUV (Z0) = = 5HFHLYHG $UEB$B5[ Parent node $UEB%B5[ sends Bus_RESET 5HFHLYHG (11)

Parent node Child node detects Bus_Reset detects Bus_Reset (Z1) (1Z) Sry 'DWD 73% 73$ $UEB%B7[ $UEB$B7[ 6WUREH 'ULYHU 73% 73$ a 'ULYHU

$UELWUDWLRQ $UELWUDWLRQ &RPSDUDWRUV &RPSDUDWRUV

5HFHLYHG $UEB%B5[ $UEB$B5[ 5HFHLYHG

276 Chapter 14: Bus Reset (Initialization)

Effects of Bus Reset

Bus reset results in a variety of actions being taken within nodes. The primary effects include:

• Topology information is cleared at each port • Some PHY register values return to defaults • CSR register values affected

The effects of bus reset also depends on the source of the reset. For example, when power is cycled, a bus reset is performed and all register values within the PHY and link are cleared or returned to their initial values. Bus reset for any other reason has a less drastic effect, resulting in some register fields being preserved. The following discussion describes the effects of a bus reset not resulting from power being cycled.

Topology Information Cleared

Figure 14-2 illustrates how each node would view itself following RESET. Note that all nodes have the same peer relationship to each other. Following the completion of bus reset, all nodes enter their tree ID state and the topology is re- established.

Figure 14-2: Nodes After Reset Have No Sense of Bus Topology

1 12123412 1 1 2 AB C DE F

PHY Register Changes

Some fields within the port and PHY registers either lead to the generation of bus reset or are directly affected by a bus reset while others remain unaffected. Following is a description of the fields related to bus reset.

277 15 Tree Identification

The Previous Chapter

The previous chapter detailed the initialization phase of the configuration process. Initialization begins with the assertion of a bus reset by a given node on the bus. This Chapter

Following bus initialization, the tree ID process begins to determine which node will become the root. This chapter details the protocol used in determining the topology of the serial bus. The Next Chapter

The next chapter focuses on the self-ID process. During self-ID all nodes are assigned addresses and specify their capabilities by broadcasting self-ID packets.

Overview

Following bus initialization, nodes begin the tree identify phase to identify the root node and the topology of all attached nodes. The tree ID process results in all ports being designated as either child or parent ports. A child port connects to a node further away from the root, while a parent port connects to a node closer to the root.

285 FireWire System Architecture

Tree ID Signaling

Before discussing the tree ID process a review of the tree ID signaling may be helpful. All connected nodes perform Tree ID signaling via the strobe and data drivers and their respective arbitration comparators as illustrated in Figure 15- 1. The strobe is delivered via TPA and is received by the attached node on TPB, while the state driven on the data is delivered via TPB and is received on TPA.

All nodes use the arbitration mechanism to communicate with other nodes that are attached directly to their ports. The tree ID process uses two of the arbitration line states defined as:

• Parent_Notify • Child_Notify

These signal states are used to determine if a given node is closer to or further from the root node. The line states that are driven are listed in Table 15-1.

A Parent_Notify is signalled by driving a “0” onto the TPA, while leaving TPB in the idle or undriven state (Z). Child_Notify is signaled by driving a “1” on TPA and leaving TPB in the “Z” state. As illustrated in Figure 15-1 on page 287, the signals driven onto TPA are received and detected on TPB of the attached node’s arbitration comparators, and signals driven on TPB are received and detected on TPA by the arbitration comparators. The following discussion details the Tree ID process.

Table 15-1: Line States that Signal Parent- and Child-Notify

Parent_Notify Child_Notify

TPA 0 (Strobe) 1 (Strobe)

TPB Z (Data) Z (Data)

The Tree ID Process

The Tree ID process begins with one or more nodes signaling Parent_Notify to their probable parents. Only those nodes that have received a Parent_Notify on all but one of their ports can signal a Parent_Notify. Immediately following reset this is true of only leaf nodes, since they have a single port. Thus, all leaf nodes immediately signal Parent_Notify to the attached nodes. Branch nodes that

286 Chapter 15: Tree Identification

receive a Parent_Notify on one of their ports mark that port as a “child” port to signify that the attached node is further away from the root node. In response to the Parent_Notify, branch nodes also return a Child_Notify to the attached leaf node. However, a branch node will not signal the Child_Notify until all but one of its ports have received Parent_Notify. A leaf node that receives a Child_Notify marks its port as a parent port which signifies that the attached node is closer to the root node. Once all nodes have identified all other attached nodes as either children or parents, the Tree ID process is complete.

Figure 15-1: Strobe and Data Lines Used During Tree ID

Leaf Node Branch Node Cable TPA TPB Strobe Strb_Tx Data_Tx Data Driver TPA* TPB* Driver Enable Enable

Arbitration Arbitration Arb_A_Rx Arb_B_Rx Comparators Comparators

TPB Cable TPA Data Data_Tx Strb_Tx Strobe Driver TPB* TPA* Driver Enable Enable

Arbitration Arbitration Arb_B_Rx Arb_A_Rx Comparators Comparators

Leaf Nodes Try to Find Their Parents

The following discussion details the handshake performed between a pair of leaf and branch nodes during the Tree_ID process. Note that all leaf and branch nodes that connect to each other perform the same handshake. Immediately following Bus Initialization, all leaf nodes signal Parent_Notify via TPA=0 and

287 FireWire System Architecture

TPB=Z as pictured in Figure 15-2 on page 288. At this time, the branch node is not signaling any line state, thus its data and strobe drivers are in a high impedance (Z) state and the line states driven by the leaf node are unaffected by the branch node. Since the twisted pair signal lines are cross-wired between attached nodes, the branch node observes the Parent_Notify at its arbitration comparators as TPA=Z and TPB=0. At the same time, the leaf node’s arbitration comparators observe the line states that its own drivers are signaling (TPA=0 and TPB=Z).

Figure 15-2: Leaf Node Signaling Parent_Notify

Leaf Node Branch Node Result Strobe TPA TPB Data Strb_Tx Data_Tx Driver TPA* 0 TPB* = Driver Enable Enable

Arbitration Branch node Arbitration Comparators has drivers disabled Comparators (ZZ) 0 0 Arb_A_Rx Leaf node Arb_B_Rx Received sends Parent_Notify Received (0Z)

Leaf node Branch node detects own detects Parent_Notify Parent_Notify (0Z) (Z0) Result TPB TPA Data Data_Tx Strb_Tx Strobe == Driver TPB* Z TPA* Driver Enable Enable

Arbitration Arbitration Comparators Comparators Z Z Arb_B_Rx Arb_A_Rx Received Received

Parents Identify Their Children

The branch node, having received a Parent_Notify on one of its ports, recognizes that a leaf is attached to this port and marks the port as a child port. In

288 Chapter 15: Tree Identification

response, the branch node signals a Child_Notify via TPA=1 and TPB=Z when it recognizes that all of its ports or all but one of its ports have received Parent_Notify. While the Child_Notify is being signaled by the branch node, the leaf continues to signal Parent_Notify. Figure 15-3 on page 289 illustrates the states driven by both nodes and the resulting line states. The resulting line states observed at the leaf’s arbitration comparators are TPA=0 and TPB=1. The branch node also detects the Child_Notify as TPA=1 and TPB=0.

Upon detecting the Child_Notify, the leaf node marks its port as a parent port (i.e. it attaches to a node that is closer to the root). Having been identified as a child port, the node withdraws its Parent_Notify, which is viewed by the branch node as confirmation that the Child_Notify was received and accepted by the leaf node (i.e. the branch node observes the line state change from TPA=1 and TPB=0 to TPA=1 and TPB=Z). The leaf node’s role in the Tree ID process is now finished and the first phase of the Tree ID process is complete.

Figure 15-3: Branch Node Signaling Child_Notify

Leaf Node Branch Node Result TPA TPB Strobe Strb_Tx Data_Tx Data Driver 0 TPA* 0 TPB* Z Driver Enable Enable

Arbitration Branch node Arbitration Comparators sends Child_Notify Comparators (1Z) 0 0 Arb_A_Rx Leaf node Arb_B_Rx Received continues Parent_Notify Received (0Z)

Leaf node Branch node detects Child_Notify detects result of its (01) Child_Notify (10) Result TPB TPA Data Data_Tx Strb_Tx Strobe Driver Z1TPB* 1 TPA* Driver Enable Enable

Arbitration Arbitration Comparators Comparators 1 1 Arb_B_Rx Arb_A_Rx Received Received

289 16 Self Identification

The Previous Chapter

Following bus initialization, the tree ID process begins to determine which node will become the root. The previous chapter detailed the protocol used in determining the topology of the serial bus. This Chapter

This chapter focuses on the self-ID process. During self-ID all nodes are assigned addresses and specify their capabilities by broadcasting self-ID packets. The Next Chapter

The next chapter describes the role of the cycle master node and defines how the cycle master is identified and enabled.

Overview

During the self-identification process configuration of the nodes begins. The following actions are performed during self-ID:

• Physical IDs are assigned to each node. • Neighboring nodes exchange transmission speed capabilities. • The topology defined during tree identification is broadcast.

During self-ID the root hub issues one self-ID grant signal for each node within the network. As each node receives its arbitration grant, it performs self-identification by assigning itself a physical ID and returning one or more self-identification packets. This process uses arbitrary port numbers that were assigned to each node during design time. These numbers are used to specify the order in which nodes attached to these ports will be assigned their physical IDs.

305 FireWire System Architecture

All signaling and packet transmission is done at the base rate (100Mb/s) since the speed capabilities of each node is unknown until the self-ID process has completed.

Self-Identification Signaling

Arbitration signaling states are used during the self-ID process. The signal states transmitted as listed in Table 16-1.

Table 16-1: Line States that Signal Parent- and Child-Notify

SELF_ID_GRANT DATA_PREFIX IDENTIFICATION_DONE

TPA (Strobe) Z 0 1

TPB (Data) 0 1 Z

Self-ID begins with the root signaling arbitration grant to its lowest numbered port and data prefix to its other ports. The following sections describe the entire self-ID process.

Physical ID Selection

At the start of the self-ID process, each node has identified whether each port points to a child or parent port as illustrated in Figure 16-1 on page 307. At this time no knowledge exists within any given node regarding the capabilities of its neighboring nodes or regarding the topology. The root node must determine how many nodes exist in the network and ensure that each is assigned a unique physical identifier. The following sections detail the process of assigning a physical ID to each node. First Physical ID is Assigned

The self-ID process begins with the root port issuing an arbitration grant (TPA=Z and TPB=0) to its lowest numbered port and data prefix to its other ports. Arbitration grant is signaled by each branch node to its lowest numbered port until a leaf node is reached. Figure 16-2 illustrates the propagation of arbitration grant. In this example, when leaf node A receives the arbitration grant, it assigns itself a physical ID of zero (Phy 0). The physical ID assigned comes from the current self-ID count.

306 Chapter 16: Self Identification

Figure 16-1: Example Node Network at Start of Self-ID

Root Node D 1,c 2,c

4,p 1,p Branch Node C Leaf Node E 1,n 2,c 3,c

2,p 1,p Node B Branch Leaf Node F 1,c 2,n

1,p Leaf Node A

Self-ID Count

Each node tracks the number of self-ID packets that are broadcast during the self-ID process. The self-ID count within all nodes is initialized to zero after reset. Nodes increment their self-ID count after each self-ID packet is broadcast.

307 FireWire System Architecture

Figure 16-2: First Arbitration Grant Issued During Self-ID Process

Root node signals arb_grant Root to its lowest numbered port Count = 0 Node D & signals data_prefix to its other port. 1,c 2,c Arb_Grant Data_Prefix

4,p 1,p Node C forwards arb_grant to its lowest numbered port Branch Node C Node E Count = 0 Leaf & signals data_prefix to its other ports. 1,n 2,c 3,c Count = 0

2,p 1,p Node B forwards arb_grant Branch Leaf to its lowest numbered port Node B Node F & signals data_prefix to its Count = 0 Count = 0 other ports. 1,c 2,n

1,p Node A recognizes that it is being targeted with the Leaf Node A arb_grant & assigns itself a physical ID of zero. Node A Phy 0 then returns a data_prefix to Node B .

Arb_Grant Data_Prefix

Branch Nodes Signal Arbitration Grant & Data Prefix

Refer to Figure 16-2 on page 308. Note that as each branch node receives the arbitration grant, it checks its ports to determine which have been identified, if any. Since the self-ID process has just begun none of the ports have been identified yet. Each branch node (nodes C and B in this example) signals arbitration grant to its lowest numbered unidentified port. Each branch node also signals data prefix to its other ports, including back upstream to the node signaling the arbitration grant.

308 Chapter 16: Self Identification

When branch nodes signal data prefix upstream toward the root node, the upstream node continues to signal arbitration grant downstream. Consider the action taken by branch Node C when it receives arbitration grant from the root node. Figure 16-3 on page 309 illustrates the arbitration grant line state being signaled by the root node (TPA=Z and TPB=0) and the data prefix being signaled by node C (TPA=0 and TPB=1). The root node’s arbitration comparators will detect the arbitration grant that it is signaling; thus, when the data prefix is driven at the opposite end of the cable, the root node detects a change in the line state. The resulting line state (TPA=1 and TPB=0) observed by the root, is interpreted as receipt of a data prefix (Rx_DATA_PREFIX). When the root node detects the data prefix it removes arbitration grant signaling and leaves only the data prefix being driven on the cable.

Figure 16-3: Identified Node Starts Self-ID Packet Transmission with Data Prefix

Upstream Node Downstream Node (Signaling Arb_Grant) (Signaling Data_Prefix) Result Strobe TPA TPB 'DWDB7[ Data Strb_Tx Driver = TPA* TPB* Driver Enable Enable

Arbitration Arbitration Arb_A_Rx $UEB%B5[ Comparators Comparators

Result Data Data_Tx TPB TPA 6WUEB7[ Strobe Driver TPB* TPA* Driver Enable Enable

Arbitration $UEB$B5[ Arbitration Arb_B_Rx Comparators Comparators

309 17 Cycle Master

The Previous Chapter

The previous chapter focused on the self-ID process. During self-ID all nodes are assigned addresses and specify their capabilities by broadcasting self-ID packets. This Chapter

This chapter describes the role of the cycle master node, and defines how the cycle master is identified and enabled. The Next Chapter

Next, the isochronous resource manager is discussed: how it is identified and enabled, and the nature of its role in the serial bus environment.

Overview

Isochronous transfers are guaranteed a constant bus bandwidth based on allocation of the number of bytes to be transferred during 125µs intervals. The root node is responsible for specifying the 125µs interval and marks the beginning of the next series of isochronous transactions by broadcasting a cycle start packet as illustrated in Figure 17-1.

Determining and Enabling the Cycle Master

A node that is cycle master capable must:

• be isochronous capable • implement the BUS_TIME register • be able to generate cycle start events based on an 8KHz clock that is synchronized to the CYCLE_TIME register and broadcast cycle start packets. • set the cmc bit in the BUS_INFO_BLOCK

329 FireWire System Architecture

Figure 17-1: Isochronous Transactions Performed Every 125µs

Cycle n-1 Cycle n Cycle n+1

A A

c c c Cycle Start Cycle Start

k k Packet A k data=x Ch B Ch C Ch DCh N Packet B Packet C data=y Ch B

cycle period = 125µs

C C = Isochronous Transactions

S S = Asynchronous Transactions

The cycle master must be the root node. Following the self-ID process, the root node and the isochronous resource manager will be known. If a bus manager is present it will verify that the root node is cycle master capable and, if so, enable it; otherwise, the isochronous resource manager will perform this function. To determine if the root is cycle master capable, the cmc bit within the root node’s BUS_INFO_BLOCK register will be set. If so, the root node is enabled to perform the cycle start by setting the cmstr bit in the STATE_SET register.

If the root node is not cycle master capable, other nodes are checked for cycle master capability. When a capable node is found it is selected to become the new root node. This is accomplished by broadcasting a PHY configuration packet with the force root bit “R” set to 1 and the root ID value set to the node ID of the target node. The selected node will set its root holdoff bit (RHB), while all other nodes (those not selected by the root ID value) will clear their RHB bit.

Cycle Start Packet

The cycle start packet format is illustrated in Figure 17-2 on page 331. For a description of the fields within the cycle start packet see Table 8-16 on page 196. This packet is broadcast by the cycle master at the beginning of each new cycle (nominally 125µs). The start of each cycle is synchronized to the cycle master’s CYCLE_TIME register. The cycle master delivers the contents of its cycle time register in the cycle start packet. As a result, if the cycle start packet is delayed due to the previous cycle stretching beyond the nominal 125µs cycle time, the timing variation will be visible to all isochronous nodes as illustrated in Figure 17-3 on page 331.

330 Chapter 17: Cycle Master

Figure 17-2: Cycle Start Packet Contains Value of Cycle Master’s CYCLE_TIME Register msb (transmitted first) destination_ID tl rt tcode pri source_ID destination_offset destination_offset

cycle_time_data (from CYCLE_TIME register)

header_CRC lsb (transmitted last)

Figure 17-3: Cycle Time Variation Included in Cycle Start Packet

Cycle n-1 Cycle n Cycle n+1

A A

c c c Cycle Start Cycle Start

k k Packet A k data=x Ch B Ch C Ch DCh N Packet B Packet C data=y Ch B

nominal cycle period = 125µs delay=x delay=y

C C

y y

c c

l l

e e

S S

t t

a a

r r

c t = Isochronous Transactions t

= Asynchronous Transactions

331

18 Isochronous Resource Manager

The Previous Chapter

The previous chapter described the role of the cycle master node, and defined how the cycle master is identified and enabled. This Chapter

This chapter describes the role of the isochronous resource manager: how it is identified and enabled, and how other nodes interact with it. The Next Chapter

Next, the bus manager function is described including topology map generation and access, speed map generation and access, and power management.

Overview

Following a bus reset, all traffic on the bus is terminated and all nodes perform the initialization sequence consisting of reset, tree-ID, and self-ID procedures. If this is the initial Reset due to power on, each node wishing to perform isochronous transfers must obtain an isochronous channel number and request the amount of bus bandwidth that it requires. The isochronous resource manager fulfills the role of keeping track of channel numbers and bus bandwidth that have been allocated.

If the reset occurs after isochronous traffic has started (e.g. due to attachment of new node), all bus traffic resumes as quickly as possible. Asynchronous transactions can resume immediately upon completion of the self-ID process, as well as isochronous transactions in most instances. However, isochronous transactions are delayed if the root node changes. In this case, isochronous transactions cannot start again until isochronous resources are verified and a cycle master is selected to re-initiate isochronous traffic.

333 FireWire System Architecture

Determining the Isochronous Resource Manager

Any node residing on the bus may have the ability to perform the role of isochronous resource manager (IRM). Nodes capable of becoming the isochronous resource manager must indicate their ability to fulfill this role by setting the “l” (link active) and “c” (contender) bits in packet zero of their self-ID register. This makes a given node a contender for the role of IRM. See Figure 18-1.

Figure 18-1: Contender Nodes Must Set Bits l and c in Their Self-ID Packets

G88ivirrs qr prqvts ur yrs vpu r prhtr U hvrqsv

i / /LQNOD\HUÃDFWLYH & &RQWHQGHU yi ufD9thfpqryp G !v Gtvphyvr rssv "!iv

U hvrqyh

334 Chapter 18: Isochronous Resource Manager

All nodes contending for the role of IRM must monitor all self-ID packets to determine if another node is also vying for the position of IRM. The competition is won by the contender having the highest value physical ID. During the self- ID process, a physical ID of zero is assigned first followed by consecutively higher IDs. Thus, a node contending for the role of IRM recognizes that it is out of the running if, after sending its own self-ID packet, it recognizes that a later self-ID packet specifies another node as a contender. Note that the highest value physical ID always belongs to the root node and its self-ID packet is always sent last. Thus, in many instances, the root node will become the IRM (i.e. when it is IRM capable).

Minimum Requirements of Isochronous Resource Managers

To be a contender for the role of IRM, a node must fulfill a set of minimum requirements:

• Support Isochronous transactions as either talker or listener. • Link and Transaction layers must be active during configuration process. • Implement General ROM to support Bus_Info_Block with IRMC bit set. • Implement the Bus Manager ID register. • Implement bus bandwidth allocation register. • Implement channel allocation register.

The isochronous resource manager provides allocation registers whose locations are known to all nodes needing to perform isochronous transactions. Nodes wishing to perform isochronous transfers must access these registers to acquire a channel number and bus bandwidth prior to performing any isochronous transfers.

Enabling the Cycle Master

The isochronous resource manager (IRM) may also be required to enable the cycle master so that it can begin transmitting cycle start packets. Following a power reset, the “cmstr” bit within the bus_depend field of the STATE register (See Figure 21-3 on page 367) will be cleared, which disables cycle master functionality. The IRM, in the absence of the bus manager, is responsible for enabling the root to perform the cycle master functions. The IRM determines that the bus manager is absent if the value of the BUS_MANAGER_ID register remains at 3Fh for greater than 625ms after bus reset.

335 FireWire System Architecture

In the event that a bus or command reset occurs, the cycle master should keep the “cmstr” bit set so that it can automatically resume broadcast of cycle start packets. However, if the cycle master recognizes that following a bus reset and tree ID process that it is no longer the root, it must clear the “cmstr” bit. Conse- quently, the new root node must be enabled as the cycle master so it can start generating cycle start packets.

Resource Allocation Registers

Figure 18-2 on page 336 shows the location of the CHANNELS_AVAILABLE and BANDWIDTH_AVAILABLE register within the node space of the Isochro- nous Resource Manager. The BANDWIDTH_AVAILABLE register is mapped at offset 224h from the beginning of the Serial-Bus dependent address space, and the CHANNELS_AVAILABLE register is mapped beginning at offset 220h. When a node accesses these registers to obtain isochronous resources, it must perform the access using lock transactions.

Figure 18-2: Location of CHANNEL_ALLOCATION & BUS_BANDWIDTH Registers.

Initial Node Serial Bus Space (2KB) Space (512B)

0 512 CSR Architecture BUS_Manager_ID 540 (21Ch) 512 BUS_BW 544 (220h) Serial CHANNEL_AVAIL 548 (224h) Bus

1KB

ROM Space (1st 1KB) 1KB-1 2KB-1

336 Chapter 18: Isochronous Resource Manager

Channel Allocation

Nodes wishing to perform isochronous transfers must first obtain an isochronous channel number via the CHANNELS_AVAILABLE register. Channels Available Register Format

This 64-bit register provides a bit map where each bit corresponds to one of the 64 possible isochronous channels supported by the serial bus as illustrated in Figure 18-3 on page 337. All bits are initialized to a value of one, thus indicating that none of the channels has been allocated. Accessing the Channels Available Register

A node wishing to obtain an isochronous channel must first read the current register value to determine the next consecutive channel available. Note that the CHANNELS_AVAILABLE register is initialized to all ones, indicating that all channels are available. Next, the lock (compare and swap) transaction is used to request the next available channel. The lock transaction is used since more than one node may simultaneously attempt to request a channel. If no other node claims a channel number between the initial register read and the subsequent lock operation, then the lock transfer for this node will be successful; otherwise, the lock transfer will not succeed.

Figure 18-3: Format of the CHANNELS_AVAILABLE Register

channels_available_hi format msb lsb ch 31 channel bit assignment ch 0 "!

channels_available_lo format msb lsb ch 63 channel bit assignment ch 32 "!

337 19 Bus Manager

The Previous Chapter

The previous chapter described the role of the isochronous resource manager: how it is identified and enabled, and how other nodes interact with it. This Chapter

In this chapter, the bus manager function is described including topology map generation and access, speed map generation and access, and power management. The Next Chapter

The next chapter discusses the bus management services that are used by the bus manager and isochronous resource manager to perform their bus management roles.

Overview

One node residing on the serial bus may be selected to provide serial bus services for the benefit of the community of all nodes residing on the bus. Whether bus management is performed and the extent to which it is performed varies depending on the capability of nodes residing on the bus. Several possibilities exist:

• Bus is fully managed — at least one node on the bus is bus manager capable, thereby providing complete bus management facilities. • Bus is partially managed — no bus management capable node is present on the bus, but at least one node is isochronous resource manager capable. Par- tial bus management capability is performed by isochronous resources management capable nodes. • Bus is unmanaged — none of the nodes residing on the bus is bus manager capable or isochronous resource manager capable.

343 FireWire System Architecture

The bus management services that may be provided include:

• publishing a topology map that can be accessed by other nodes. • publishing a speed map that can be read to find the maximum speed for each cable segment that is attached between two nodes. • enabling the cycle master. • power management control. • optimizing bus traffic.

The node that performs bus management duties may reside anywhere on the serial bus. It collects information during the self-identification sequence as each node broadcasts its self-ID packet. The bus manager node uses this information to build topology and speed maps that other nodes can access. More than one node may be a candidate for the role of bus manager and these nodes must also monitor self-ID packets in the event they are selected to handle the role of bus manager. Furthermore, any node wishing to access the topology or speed maps must also monitor the self-ID packets so it can determine which node will perform the role of bus manager, and knowing its physical ID it will be able to access the topology and speed maps.

Determining the Bus Manager

At the conclusion of the Self-ID stage of bus configuration, the isochronous resource manager will have been identified. The last node to send its self-ID packets with the “L” and “C” bits set (the last contender) wins the role of isochronous resource manager. An isochronous resource manager may optionally be bus manager capable. A bus manager capable node differentiates itself from isochronous resource manager only nodes by performing a locked compare and swap transaction to the BUS_MANAGER_ID register within the IRM. The first node that successfully updates the BUS_MANAGER_ID register with its own physical ID wins the role of bus manager.

Other nodes read the BUS_MANAGER_ID register to obtain the node ID of the bus manager. If the value in the register is 3Fh, then no bus manager has claimed the role.

344 Chapter 19: Bus Manager

Power Management

Some nodes may require bus power to operate. If bus power is available, it is supplied by one or more nodes. When nodes are attached they must have their PHY powered in order for the node to function. Other node components may also require bus power such as the link layer, node controller, and unit related hardware. Any node hardware other than the PHY and node controller must remain powered off until configuration completes. The PHY and node controller functionality must be powered so that the PHY can power up the rest of the node under direction from the bus manager or isochronous resource manager (in the absence of a bus manager node). The following discussion is based on the 1394-1995 specification. The 1394a supplement extends the definition of power management and is discussed in the next chapter.

Power Management by Bus Manager Node

The bus manager obtains power class information from each node when the PHY sends self-ID packets during bus configuration. A node may require bus power for its link and other unit hardware associated with the node. The bus manager, having monitored all self-ID packets, can calculate the total bus power sourced by nodes on the bus, as well as the total bus power required by nodes. Based on this information, the bus manager can determine if sufficient power is available to support all nodes requiring bus power. Obviously, two possibilities exist and the actions that the bus manager must take are:

• Power required exceeds power available — the bus manager must notify its application by reporting an insufficient cable power event to the link layer, which is passed to the application at the bus manager node. The actual bus manager service used is an SB_EVENT indication with the insufficient bus power parameter set. The application at the bus management node must be prepared to handle this situation. The application is responsible for determining the appropriate action. Selected nodes may be chosen to receive power (via a link-on packet), or all nodes requiring bus power may be left powered off and the user notified. • Power required is equal to or less than power available — in this instance, all nodes that have inactive link layer are powered via the link-on packet. The application uses the SB_CONTROL service to cause the link-on packet to be transmitted.

345 FireWire System Architecture

Format of the link-on packet is shown in Figure 19-1. The two most significant bits (01b) of the packet identify it as a link-on packet. The next six bits specify the node address that this packet is targeting. When the PHY receives this packet it initiates and passes an SB_EVENT indication to the node controller, which, in turn, switches bus power to the link.

Figure 19-1: Format of the Link-On Packet Used to Apply Bus Power to a Node’s Link Layer

msb (transmitted first)

01b phy_ID 000000h

logical inverse of first quadlet

lsb (transmitted last)

Power Management by IRM Node

The Isochronous Resource Manager (IRM) can provide a minimal level of power management by issuing link-on packets to these nodes that have an inactive link layer. The IRM recognizes those nodes that don’t have their link layer powered by observing the self-ID packets that have the “L” bit cleared (0). Note that the IRM need not verify that sufficient power is available before issuing the link-on packet.

The Topology Map

Knowledge of the bus topology can be used to optimize serial bus performance. This can be accomplished by:

• Reconfiguring the topology to reduce the number of cable hops. The specification doesn’t say how this should be accomplished, but user intervention is clearly required. One can envision an elaborate animated graphic to guide the user in reconfiguring the connections, or the entire issue may simply be ignored. We’ll see! • Reconfiguring the topology so that devices with the same speed capability are arranged adjacent to each other. Once again the user must assist.

346 Chapter 19: Bus Manager

All bus manager capable nodes capture self-ID packets as they are sent by each node during bus configuration. Once a node is selected as bus manager, it con- structs a topology map and makes it available to all nodes. (The topology map format is shown in Figure 19-2 on page 347.) The bus manager must also perform consistency checks to ensure that the total number of ports connected to parents equals the number of ports connected to children. If the self-ID information received is inconsistent, then the length field must be cleared to zero and the topology error reported to the application via an SB_EVENT indication.

Figure 19-2: Topology Map Format

length CRC % % generation_number "! node_count self_id_count % % self_id_packet [0] "!

self_id_packet [self_id_count - 1] "!

Accessing the Topology Map

An application associated with a given node that requires information from the topology map registers must perform the access using the following procedures:

1. Read the length field at offset 1000h within the initial units’ address space of the bus manager node. (Location of the bus manager is found by reading the BUS_MANAGER_ID register located at the isochronous resource manager node.) If the field contains a value of zero, then the topology is invalid. Otherwise, the topology information can be read. 2. Read the quadlet entries of interest.

347 20 Bus Management Services

The Previous Chapter

In the previous chapter, the bus manager function was described including topology map generation and access, speed map generation and access, and power management functions. This Chapter

This chapter discusses the bus management services that are used by the bus manager and isochronous resource manager to perform their bus management roles. The Next Chapter

The next chapter discusses the CSR registers defined by the ISO/IEC 13213 specification with particular focus on the registers that are required by the 1394- 1995 and 1394a specifications.

Overview

A variety of bus management activities must be performed by the isochronous resource manager and the bus manager nodes as described in the two previous chapters. The local application at the node must be designed to support bus management activities if it is bus manager or isochronous manager capable. Bus management services are defined by the specification which provides the interface between the application and the bus management layer. The bus management layer passes messages and status information to the application regarding the state of the bus or management layer itself. The application also uses the interface to direct the bus management layer to take action regarding certain bus management issues. Figure 20-1 on page 352 illustrates the relationship between the bus management layer and the rest of the node.

351 FireWire System Architecture

Figure 20-1: Relationship Between Bus Management Layer and the Rest of the Node

Software Driver

Bus Asynchronous Isochronous Management Transfer Transfer Interface Interface Interface Management Transaction Layer Services Layer Services

Bus Manager

Isochronous Transaction Resource Manager Layer

Cycle Master Link Layer Services

Link Layer

Node Controller Physical Layer Services

Physical Layer

Serial Bus Management Layer Serial Bus

352 Chapter 20: Bus Management Services

Three services are defined for the serial bus management layer:

• Serial Bus control request (SB_CONTROL.request) • Serial Bus control confirmation (SB_CONTROL.confirmation) • Serial Bus event indication (SB_EVENT.indication)

The Serial Bus control services are used by the application to direct the bus management layer to take some action (the request) and once the bus management layer has performed the requested operation’s verification is sent back to the application (the confirmation). Status information is passed to the application by the bus management layer using the Serial Bus event indication. Each service is defined in the following sections.

Serial Bus Control Requests

The Serial Bus control request service can be used not only to specify that some action be taken related to serial bus management but also to request status information. The following list specifies the actions that can be requested by an application using the Serial Bus control request:

• Reset the bus • Initialize the node • Transmit a Link-on packet • Present Status • Transmit a PHY configuration packet

Each action is detailed below.

Bus Reset Control Request

When this request is issued by the application layer, the PHY layer is directed to signal a bus reset and initialize itself. The reset request also directs the link and transaction layer to discard all pending transactions and subactions.

The bandwidth set-aside for isochronous transactions is also passed by the bus manager application to specify the amount of bus bandwidth that should be reserved for asynchronous transactions. The bus manager application (or isochronous resource manager if no bus manager exists on the bus) specifies the number of allocation units to be subtracted from the bus BANDWIDTH_AVAILABLE register that resides within the link layer of the isochronous resource manager. The bus manager must then update the

353 FireWire System Architecture

BANDWIDTH_AVAILABLE register to reflect the bandwidth that remains for isochronous transfers. Note that this requires generation of a lock compare and swap transaction targeting the BANDWIDTH_AVAILABLE register.

Initialize Control Request

The initialize control request is used to reinitialize the node and prepare it to transmit and receive packets. Specifically, this request directs the link and transaction layers to discard all pending transactions and subactions and enable the link to receive packets and also enable the transaction layer to accept transaction requests from the application.

Link-On Control Request

This request is made only by the bus manager (required) or isochronous resource manager (optional) applications. This request directs the PHY to generate a Link-on packet to notify the target node to attempt the application of power to its link layer controller. This service also passes the physical ID of the node to whichever power is to be applied.

Present Status

This request is issued to request status information be returned to the application from the bus management layer. The SB_CONTROL.confirmation returns the status information as listed on “Serial Bus Control Confirmations” on page 356.

PHY Configuration Request

The bus manager or isochronous resource manager node are the only nodes that issue the PHY configuration request. This request causes the generation of a PHY configuration packet or one of the extended PHY packets.

354 Chapter 20: Bus Management Services

Set Force Root and Set Gap Count

This broadcast packet provides the ability to change the gap count variable and to force the Root Hold Off (RHB) in the specified PHY, while forcing all other nodes to clear the RHB. The parameters passed with this request include:

• Set force root — this flag when set indicates that the “physical ID” parameter is valid and that the “R” bit in the PHY configuration packet must be set. • Physical ID — This parameter specifies the target node that must set its force root bit, making it the root following the next bus reset. This parameter is valid if the “set force root” parameter is set. • Set gap count — this parameter when set indicates that the gap count field contains a valid gap count value and that the “T” bit in the PHY configuration packet must be set. • Gap count — this parameter specifies the value of the gap count field that will be sent via the PHY configuration packet. This parameter is valid when the “set gap count” parameter is set.

Extended PHY Packets

The 1394a supplement defines extended PHY packets that can be generated via the PHY configuration request. The extended packets use the PHY configuration packet format with the gap_count field specifying the extended packet type. When the PHY configuration request is issued with the “set force” and “set gap count” parameters both cleared, the gap count parameter specifies the extended packet type. Depending on the extended packet type, the physical ID parameter may define extended packet specific information. (See Chapter 10 for details regarding extended PHY packets. Parameter data are specified below for extended PHY configuration packet generation.

• Set force root — this parameter must be cleared. • Set gap count — this parameter must be cleared. • Gap count — this parameter defines one of the following types of extended PHY packets: - Ping packet - Remote access packet - Remote reply packet - Remote command packet - Remote confirmation packet - Resume packet • Physical ID — physical ID of the target node.

355 21 CSR Architecture

The Previous Chapter

The previous chapter discussed the bus management services that are used by the bus manager and isochronous resource manager to perform their bus management roles. This Chapter

This chapter discusses the CSR registers defined by the ISO/IEC 13213 specification with particular focus on the registers that are required by the 1394 specification. The Next Chapter

The following chapter details the contents of configuration ROM required by the ISO/IEC 13213 specification. The serial bus also defines ROM entries that are required by some nodes, depending on the capabilities.

Overview

Firewire is based on the ISO/IEC 13213 specification, commonly referred to as the Control and Status Registers (CSR) Architecture for microcomputer buses. This specification defines a common set of core features that can be implemented by a variety of buses that adhere to this standard. A group of core registers support functions common to CSR architecture buses and provide standardized offset locations within the initial register address space where these registers can be accessed. The start address location of the initial register space is at offset FFFF F000 0000h (the top 256MB block of address space) from the beginning of the node’s address space as illustrated in Figure 21-1 on page 362. Note that the CSR architecture also defines configuration ROM, which is discussed in the following chapter.

361 FireWire System Architecture

The IEEE 1394 specification defines the subset of CSR architecture features that must be supported for serial bus compliance, and also defines specific serial bus dependent extensions to the CSRs.

Figure 21-1: Location of CSRs Within the Node’s Address Space

Node Address Node’s Register Initial Node Space (256TB) Space (256MB) Space (2KB) 0 0 0 CSR Architecture Initial Node Space Serial 512 Initial Bus Memory 2KB 1KB Space ROM 256TB-512MB Space (1st 1KB) 2KB-1 Initial Units Space

Private Space 256MB Reg. Space 256MB 256TB-1 256MB-1

Core Registers

Table 21-1 on page 363 lists the core CSR registers defined by the CSR architecture and specifies the location of the serial bus dependent registers. The CSR architecture registers required in serial bus nodes are shaded in Table 21-1. The lighter shaded entry indicates that the register is conditionally required. The definition of each register and related register fields are specified in the following sections.

362 Chapter 21: CSR Architecture

Table 21-1: Core CSR Locations and Definition

Offset Register Name Description (h)

000 STATE_CLEAR State & control information

004 STATE_SET Sets STATE_CLEAR bits

008 NODE_IDS Specifies 16-bit node ID value

00C RESET_START Resets state of node

010-014 INDIRECT_ADDRESS, Indirectly access ROMs > 1KB INDIRECT_DATA

018-01C SPLIT_TIMEOUT_HI, Split-request timeout SPLIT_TIMEOUT_LO

020-02C ARGUMENT_HI, ARGUMENT_LO, Optional diagnostic-test inter- TEST_START, TEST_STATUS face

030-04C UNITS_BASE, UNITS_BOUND, Never implemented MEMORY_BASE, MEMORY_BOUND

050-054 INTERRUPT_TARGET, Optional broadcast/nodecast INTERRUPT_MASK interrupt

058-07C CLOCK_VALUE, Synchronized time-of-day CLOCK_TICK_PERIOD, value and control CLOCK_STROBE_ARRIVED, CLOCK_INFO

080-0FC MESSAGE_REQUEST, Optional message passing reg- MESSAGE_RESPONSE ister

100-17C RESERVED Reserved for CSR architecture

180-1FC ERROR_LOG_BUFFER Reserved for Serial Bus

200-3FC SERIAL BUS DEPENDENT See Table 21-5 on page 376

Required Conditionally Required

363 FireWire System Architecture

Effect of Reset on the CSRs

Three types of Reset are supported by the serial bus:

• Power reset—defined by the CSR architecture, it occurs when power is applied to the link, PHY, and bus management functions. This causes all CSR registers to return to their initial values. The PHY layer is also reset and a bus reset is initiated. • Command reset—defined by the CSR architecture and caused by a write to the RESET_START register. This reset does not result in the PHY being reset nor does it cause a bus reset. • Bus reset—defined by the IEEE 1394 specification and caused by the addition or removal of a node or by a change in the powered state of the PHY layer of a node. • Software initiated bus reset—a bus reset caused by the local node application writing to either the IBR (initiated bus reset) or ISBR (initiated short bus reset) bit in the PHY register space.

A power reset forces all CSR registers to the initial values. When a command or bus reset occurs, CSR registers are sometimes also returned to their initial values, while in other instances particular fields may remain unchanged as discussed in the following sections.

State Register (State_Clear & State_Set)

The STATE register is defined by the CSR architecture and provides support for status and control features. Although these registers are defined as optional within the CSR architecture specification, they are required by the serial bus specification. The STATE_CLEAR register is used to clear state bits, while the STATE_SET register provides a way to set state bits.

The STATE register format is illustrated in Figure 21-2, and the definition and usage of each field is specified in Table 21-2 on page 365. Note also that Figure 21-2 on page 365 defines the values of the individual state bits following initialization and reset, and shows the read values returned and the effects of writes on each field. The bus_dependent field is defined by the IEEE 1394 specification. Its format is illustrated in Figure 21-3 on page 367 and field definitions are listed in Table 21-3 on page 368.

364 Chapter 21: CSR Architecture

State_Clear Register

Writing a value of one to a writable bit within the STATE_CLEAR register location forces that bit to be cleared to zero. Writing a zero to a bit position has no effect on the current value. This is implemented by ANDing the complement of the write-data value to the current state-bit value.

Figure 21-2: Format of the STATE Register

Field Definition unit_depend bus_depend Lost dreq res elog atn off state % ' !

Table 21-2: Field Definitions for Register

Field Name Description unit_dependent Bits within this field are intended for use by the unit architecture. Definition of these bits, if defined, are provided by a unit architecture specification. bus_dependent These bits are defined by the appropriate bus standard. The IEEE 1394 specification defines usage of these bits. See Figure 21-3 on page 367 and Table 21-3 on page 368 for details. lost This bit must be implemented by serial bus nodes. This bit is set when a power reset occurs or the node has transitioned to the dead state (due to an error). This bit is not directly affected by a bus reset. Software is expected to clear the lost bit after the node has been initialized and the I/O driver has been notified of the reset or a fatal error in the event of a node transition to the dead state. dreq Dreq must be implemented by serial bus nodes that are capable of initiating transaction requests. The dreq (disable request) bit is intended to be set by software to disable request generation from unreliable nodes. Nodes may provide a “back door” access to this bit so that the bit may be cleared by special-purpose processors (e.g. via a remote diagnostic interface). Nodes that cannot initiate transaction requests but can respond to such requests must have this bit permanently set (1). res Reserved

365 22 PHY Registers

The Previous Chapter

The previous chapter discussed the CSR registers defined by the ISO 13213 specification with particular focus on the registers that are required by the 1394 specification. This Chapter

This chapter introduces PHY register maps and port registers for the 1394-1995 specification and for the 1394a supplement. The Next Chapter

The next chapter details the contents of configuration ROM required by the ISO/IEC 13213 specification. The serial bus also defines ROM entries that are required by some nodes, depending on the capabilities.

Overview

Each 1394 PHY provides the interface to the bus and performs key functions in the communications process. These functions include:

• Bus configuration • Arbitrating for control of the 1394 bus • Repeating transactions to other ports • Performing NRZ encoding/decoding • Performing data strobe encoding/decoding • Speed signaling and detecting transfer speed • Detecting device attachment/detachment

The PHY registers support the functions performed by the PHY layer. These registers are mapped as offsets within the PHY and are not mapped into the 1394 node address space. The PHY registers can be read from or written to by the application residing at node and can be read by a remote node using a remote access packet. Additionally, another node can use the PHY configura-

393 FireWire System Architecture

tion and link-on packets to change certain bits within the PHY registers of other nodes. This function is reserved for the node that performs bus management functions. These packets affect register fields related to force root, gap count, and link power features.

The section entitled, “1394-1995 PHY Register Map” details the PHY register map used by 1394-1995 compliant nodes. The 1394a supplement defines an extended PHY register map format that contains additional information needed to support new features, and is discussed in the section entitled, “1394a PHY Register Map” on page 398.

1394-1995 PHY Register Map

Figure 22-1 illustrates the PHY register map for the 1995 version of the specification. The register map contains global information that pertains to the entire node, as well as port specific registers that reflect the state and condition of each port interface. A description of each field within the PHY register map is pre- sented in Table 22-1.

Figure 22-1: 1394-1995 PHY Register Format

0000 Physical_ID R PS

0001 RHB IBR Gap_count

0010 SPD E #ports

0011 AStat0 BStat0 Ch0 Con0 reserved

0100 AStat1 BStat1 Ch1 Con1 reserved

0101 AStat2 BStat2 Ch2 Con2 reserved

Ch Con #Ports + 0011 AStat BStat reserved #Ports + 0100 ENV Register_count

#Ports + 0101

394 Chapter 22: PHY Registers

Table 22-1: Description of the PHY Register Map For 1394-1995

Size Name Description (bits)

Physical_ID 6 This field is updated during bus configuration (self-ID) to reflect the node ID of this device.

R1Root — Designates whether this node is the root node. When set to one this node is the root.

PS 1 Power status — The PHY sets this bit when it detects valid power (i.e. in the range of 7.5 - 33vdc).

RHB 1 Root Hold Off Bit — This field is set when the PHY detects a PHY Configuration packet whose Root_ID field matches the Physical_ID of this node and whose R bit is set. When RHB is set this node delays its participation in the tree-ID process.

IBR 1 Initiate Bus Reset — When set to one this bit causes the PHY to signal bus reset immediately. Reset is asserted for 166 microseconds after which the IBR bit is self cleared.

Gap_count 6 This register contains an initial default value of 63 following reset. This value can be updated later by the bus manager or isochronous manager nodes via the PHY configuration packet. The gap_count field value of the PHY configuration packet updates the PHY gap_count register when the “T” bit is set.

SPD 2 Indicates the top speed that this PHY can accept and transmit packets. 00=100Mb/s 01=200Mb/s 10=400Mb/s 11=Reserved

E 1 Enhanced bit: 1=enhanced register map is used (registers beyond #ports+0100 are defined.

#Ports 5 The number of ports supported by this PHY. This field determines the number of port status registers that directly follow this register field.

395 FireWire System Architecture

Table 22-1: Description of the PHY Register Map For 1394-1995

Size Name Description (bits)

AStat 2 TPA line state on port n (0-max Port#) encoded as follows: 11=ZZ 01=1 10=0 00=invalid

BStat 2 TPB line state on port n (0-max Port#) encoded as follows: 11=ZZ 01=1 10=0 00=invalid

Ch 1 If Ch=1, port n is a child. If Ch=0, port n is a parent.

Con 1 If Con=1, port n is connected. If Con=0, port n is disconnected.

ENV 2 Used with enhanced register. Indicates the type of environment: 00=backplane 01=cable 10 & 11=reserved

Reg_count 6 Defines number of registers that follow in the enhanced space.

396 Chapter 22: PHY Registers

Port Status Registers

The port status registers contain information regarding the connection status of each port and, if a node is attached, whether the port connects to a child or to a parent node. This information is delivered as part of the self_ID packet as port specific information.

PHY Configuration Packet

Figure 22-2 illustrates the PHY configuration packet contents. Two PHY register fields may be affected by the configuration packet:

1. Root Hold Off Bit (RHB) field 2. Gap_count field

Root Hold Off

When a PHY configuration packet is broadcast with the R bit set, then the node must compare its physical_ID to the root_ID field in the configuration packet. If the two values match, then this root must set its RHB field. If the two values do not match, then the PHY must clear the RHB. When RHB is set, this PHY will delay its participation in the tree-ID process for approximately 167µs. This ensures that this node will become the root during the next tree-ID process. Refer to “Force Root Delay” on page 299 for details regarding the tree_ID process and the force root feature. Gap Count Optimization

The gap count field configures the gap timing employed by this PHY (e.g. when arbitrating for control of the bus and when detecting time-out conditions). The bus manager or isochronous resource manager can optimize bus performance by tuning the gap count value. The default gap count of 63 can be shortened to reduce idle time between packets. When the PHY configuration packet is delivered, all nodes check the “T” bit. If set, the “T” bit indicates that the gap_count value contained in the configuration packet should replace the current value within the PHY register’s gap_count field. Since the PHY configuration packet is a broadcast packet, all nodes will update their gap_count register field to the same value.

397 23 Configuration ROM

The Previous Chapter

The previous chapter discussed the CSR registers defined by the IEEE 1212 specification with particular focus on the registers that are required by the 1394 specification. Additional bus-specific registers are also defined by the 1394 specification and are discussed. This Chapter

This chapter details the contents of configuration ROM required by the ISO/ IEC 13213 specification. The serial bus also defines ROM entries that are required by some nodes, depending on the capabilities. The Next Chapter

The next chapter provides a brief introduction to the power management environment introduced by the 1394a specification. The chapter introduces the three documents that further define the power management specification: Cable Power Distribution, Suspend/Resume Mechanisms, and Power State Manage- ment.

Overview

IEEE 1394 serial devices must include a ROM directory structure that provides critical information needed to configure and diagnose problems associated with the device. Information included within the ROM includes information for:

• identifying the software driver for this device • identifying diagnostic software • specifying bus-related capabilities of the device (e.g. whether it is bus manager capable) • specifying optional module, node, and unit characteristics and parameters

409 FireWire System Architecture

The specification defines two ROM formats: minimal and general. The minimal format only identifies the company that manufactured the device, but it may also include vendor-defined data structures. The general ROM format defines a bus information block and root directory containing entries that may specifiy pointers to other directories and data structures.

Minimal ROM Format

Figure 23-1 illustrates the minimal ROM format that consists only of a 24-bit Vendor-ID value. The most significant 8 bits contain a value of 01h, which identifies the ROM format as minimal. Any other value will be interpreted as a general ROM format. The vendor may optionally define and implement other ROM

Figure 23-1: Minimal ROM Format

01h vendor_id ' !#

entries. These additional entries are entirely vendor-defined and not a part of the CSR architecture or the serial bus standard and can only be interpreted by vendor software.

General ROM Format

Major entries within the general ROM format consist of a bus information block and root directory. The bus information block specifies a variety of bus-related capabilities, while the root directory provides values that identify the software driver and diagnostic software along with optional pointers to other directories and data structures. Figure 23-2 illustrates the general ROM format, with the entries required by the CSR architecture shaded. Note that these shaded structures always start at the same address locations within ROM. Whether the other directories and data structures are present is bus- and vendor-dependent.

410 Chapter 23: Configuration ROM

Figure 23-2: General ROM Format

info_length crc_length rom_crc_value

bus_info_block

root_directory

unit_directories root and unit leaves vendor_dependent_information

Header Information

The first quadlet of the general ROM format consists of three fields:

• info_length • crc_length • rom_crc_value

Info_Length

This field specifies the length of the bus_info_block field in quadlets. This value must be a value greater than 01h so that software can correctly identify the ROM format as “general” rather than “minimal.”

411 FireWire System Architecture

CRC_Length

The crc_length field specifies that the total length of the general ROM quadlets are covered by the crc value. The field size of the crc_length values restricts the maximum number of quadlets that can be covered by the crc_value to 255 (1020 bytes). Note that these values cover the entire ROM up to the maximum size. However, other data structures within the general ROM also contain crc values that can be used to isolate an error that has been detected within the ROM. If the ROM is larger than the maximum size covered by the ROM_crc_value, then CRC checks should be performed on directories not covered by the ROM crc. CRC_Value

Software performs a crc check on two byte groups that are covered by the crc. The calculated crc matches the crc_value when no errors are detected.

Bus_Info_Block (1394-1995)

The Bus_Info_Block provides critical information about bus related capabilities of this node. Only the bus_name field (the first quadlet) is specifically defined by the CSR architecture. The remainder of the Bus_Info_Block is defined by the serial bus standard. The format of the Bus_Info_Block content and format is illustrated in Figure 23-3. See page 415 for changes to the bus information block introduced by the 1394a supplement.

Figure 23-3: Format of the Bus_Info_Block

info_length CRC_length rom_crc_value bus_name 31h ("1") 33h ("3") 39h ("9") 34h ("4") bus_info_block irmc cmc isc bmc reserved cyc_clk_acc max_rec reserved node_vendor_id chip_id_hi root_directory chip_id_lo unit_directories root and unit leaves vendor_dependent_information

412 Chapter 23: Configuration ROM

Bus_Name Field

The CSR architecture defines the bus_name field that identifies the bus that this node supports based on four ASCII characters that represent the IEEE PAR number assigned to the corresponding bus standard. The serial bus specification defines this quadlet as “1394.” Bus Characteristics Fields

A variety of bus characteristics associated with this node are defined in the second quadlet of the Bus_Info_Block. The fields illustrated in the second quadlet of Figure 23-3 define the following node characteristics:

• irmc (isochronous resource manager capable) — When set (1) this node is isochronous resource manager capable, otherwise the bit must be cleared (0). • cmc (cycle master capable) — When set (1), this node is cycle master capable, otherwise the bit must be cleared (0). • isc (isochronous capable) — When set (1), this node supports isochronous transfers, otherwise the bit must be cleared (0). • bmc (bus manager capable) — When set (1), this node is bus manager capable, otherwise the bit must be cleared (0). • cyc_clk_acc (cycle clock accuracy) — This 8-bit field contains a value that defines the accuracy of this node’s cycle master clock in parts per million. This field is only valid for nodes that also have the cmc bit set. Valid values are between zero and 100d. If cmc is cleared, then this field must contain all ones. • max_rec (maximum data record size) — This 4-bit field indirectly specifies the maximum data payload size of asynchronous write and asynchronous stream packets that this node is capable of accepting. The max_rec value is used to calculate the maximum data payload value, which is an even power of two (max packet size = 2max_rec+1). The valid max_rec values and corresponding maximum data payload sizes are listed in Table 23-1. The shaded table entries reflect new max_rec values that correspond with the faster transmission speeds defined by the 1394a supplement. Note that these faster speeds and maximum payload sizes are currently not supported.

413 24 Introduction to Power Management

The Previous Chapter

The previous chapter detailed the contents of configuration ROM required by the ISO/IEC 13213 specification. The serial bus also defines ROM entries that are required by some nodes, depending on the capabilities. This Chapter

This chapter provides a brief introduction to the power management environment introduced by the 1394a specification. The chapter introduces the three documents that further define the power management specification: Cable Power Distribution, Suspend/Resume Mechanisms, and Power State Manage- ment. The Next Chapter

The next chapter discusses power distribution in the cable environment. It discusses the four power type designations for nodes: power providers, alternate power providers, power consumers, and self-powered devices. Details regarding the power implementation of nodes are also included.

Overview

The 1394-1995 specification defines a variety of power-related issues that have been discussed in previous chapters. The 1394a supplement provides additional definition and capability regarding generation, distribution, and management of power in the 1394 environment. These additions are the focus of this chapter. Regrettably, the 1394a supplement and the associated Power Specification were

427 FireWire System Architecture

still in development at the time of this writing. The reader is strongly cautioned that some of the information contained in this chapter will likely change before final approval by the 1394 Trade Association and additional information may be added. Subsequent editions of the book will include information from the final specification.

Review of 1394-1995 Power-Related Issues

The 1394-1995 specification includes a variety of features related to powering 1394 devices. In general, the specification allows nodes to be powered either by their own local power supply or from the cable. However, it also requires that the physical layer of each node must be capable of repeating serial bus traffic whether or not local power is available. This means that all nodes must be able to power their PHY layer interface with cable power, in the event that local power is off. Additionally, the specification requires that there is sufficient cable power available to power all nodes.

Other power-related requirements include:

• A single connector type is defined that includes VP and VG pins. • Nodes may (not required) supply unregulated power to the bus. (from 8vdc - 40vdc). • Nodes must isolate cable power from local power. • Nodes may consume no more than 1 w of power from the bus after reset. Additional power may be consumed if sufficient bus power is available. This is under the control of the node that provides power management support. • All nodes must report their power class in the self-ID packet during bus configuration. If the total power required by the node (including power required by internal units) exceeds the amount that can be reported in the self-ID packet (10W total), it must report the additional power that it requires in configuration ROM. • The bus manager node must calculate the total power available on the bus and determine if sufficient power is available to power all nodes that need cable power. If sufficient power is available, the bus manager must generate a link-on packet for each device that requires cable power. • In the absence of a bus manager node, the isochronous resource manager node is responsible for issuing the link-on packets to apply power to nodes that require bus power. Note that the isochronous resource manager is not required to validate power availability prior to sending the link-on packets.

428 Chapter 24: Introduction to Power Management

Goals of the 1394a Power Extensions

Members of the personal computer industry involved in implementing the 1394 serial bus have concluded that the 1995 version of the specification requires additional clarification and enhancement. To this end, the 1394 Trade Associa- tion has drafted a three part specification to further define power-related issues for the 1394 serial bus. These documents contain the following information:

• Part 1 — defines power distribution on the serial bus, including the voltage levels, types of power providers, power consumers, self-powered devices, and power down behavior. • Part 2 — defines power states, CSR registers, and configuration ROM entries used to control and manage power. • Part 3 — defines power conservation mechanisms (suspend and resume) for implementing low power bus states. Note, however, that the suspend and resume features were still being debated when this book was published, and have not been included here. Check MindShare’s web site for later information.

The state of the power management documentation at the time of writing was:

Part 1: Cable Power Distribution (Revision 0.93)

Part 2: Suspend/Resume (Revision 0.73)

Part 3: Power State Management (Revision 0.71)

429

25 Cable Power Distribution

The Previous Chapter

The previous chapter provided a brief introduction to the power management environment introduced by the 1394a specification. It also discussed the state of the power specifications at the time of writing: Cable Power Distribution, Sus- pend/Resume Mechanisms, and Power State Management. This Chapter

This chapter discusses power distribution in the cable environment. It discusses the four power type designations for nodes: power providers, alternate power providers, power consumers, and self-powered devices. Details regarding the power implementation of nodes is also included. The Next Chapter

Next, the suspend and resume mechanism is defined. This capability allows the PHY layer within a node to enter a low power state under software control (either local node software or from another node). The mechanisms implemented for suspend and resume are detailed including: command and confirmation packets, suspend initiator actions, suspend target actions, and related suspend and resume signaling. The impact on PHY and port register definition is also discussed.

Power Distribution

The power distribution document provides additional definition for node power classes and introduces new terminology to describe nodes that supply power to the bus. In addition it defines the power functionality of each node in terms of four power configuration groups:

431 FireWire System Architecture

1. Power Providers 2. Alternate Power Providers 3. Power Consumers 4. Self-Powered nodes

Each of these configuration groups is described in the following sections.

Power Class Codes

The power class code definition for power providers, power consumers, and self-powered nodes is listed in Table 25-1 on page 432. Note that the class code may vary depending on whether the node is a single- or multi-port implementation. The definition of each code value is stated in Table 25-2 on page 432.

Table 25-1: Node Power Class Code Assignments For Each Power Configuration

Self-ID Packet Power Class Node Power Configuration Single Port Multiple Ports

Power Provider 1, 2, 3 1, 2, 3

Alternate 44 Power Provider

Power Consumer 4, 6, 7 NA

Self-Power 0 0, 4

Table 25-2: Definition of Power Class Values Within “Pwr” Field of Self-ID Packets

POWER_CLASS Power Consumption and Source Characteristics Code (binary)

000 Node does not require bus power nor repeat bus power.

001 Node is self-powered and provides 15W (minimum) to the bus.

010 Node is self-powered and provides 30W (minimum) to the bus.

011 Node is self-powered and provides 45W (minimum) to the bus.

432 Chapter 25: Cable Power Distribution

Table 25-2: Definition of Power Class Values Within “Pwr” Field of Self-ID Packets (Continued)

POWER_CLASS Power Consumption and Source Characteristics Code (binary)

100 Node may be powered from the bus and is using up to 3W and no additional bus power is needed to enable the link.

101 Reserved for future implementations.

110 Node is powered from the bus and consumes 3W maximum. An additional 3W maximum is needed to enable the link.

111 Node is powered from the bus and consumes 3W maximum. An additional 7W maximum is needed to enable the link.

Power Providers

Nodes that source power to the bus are termed power providers. Two classes of power providers are defined by the Power specification:

• Power Providers • Alternate Power Providers

As shown in Table 25-2 on page 432, the amount of power that a node provides to the cable can vary. A power provider may be a single- or multi-port implementation and must use the 6-pin port connectors.

The cable power requirements are specified in Table 25-3. Note that these values differ from the 1394-1995 values.

Table 25-3: Cable Power Requirements

Condition Limit

Maximum output current per port 1.5 amps

Minimum output voltage (power class 1,2&3) 20 vdc

Minimum output voltage (all other classes) 8 vdc

Maximum output voltage 33 vdc

Maximum output ripple (1 kHz to 400 MHz) 100 mv peak-to-peak

433 FireWire System Architecture

Any power provider must place a diode in the output line going to each port as illustrated in Figure 25-1 on page 434, versus a single diode for all ports for the 1995 version of the specification. This prevents current from flowing from the cable to the power supply when the cable voltage is higher than the power supply’s voltage.

Figure 25-1: Power Providers Must Place Diodes in Each Port VG Line

Power Supply

Current Current Limit Limit

VG VP VG VP

Power Provider Classes

The minimum amount of power supplied by a power provider is 15, 30, or 45W and must declare a power class of 1, 2, or 3 via its self-ID packet. The unregulated output voltage at each port must be in the range from 20vdc to 33vdc under full load conditions. Figure 25-2 on page 435 illustrates the configuration of a power provider. Power providers always deliver bus power as long as their local power source (battery or AC) remains enabled. The bus power output is not disrupted due to any action on the bus.

434 Chapter 25: Cable Power Distribution

A power provider should not use bus power for its PHY in the event that local power is off. When the primary system power is lost a power provide may trickle power its PHY from another power source provided by the system. In this event, multi-port power providers must continue to repeat serial bus traffic to preserve the bus topology. A power provider whose PHY is not powered cannot repeat bus traffic, and consequently will have the effect of segmenting the bus. When trickle powering its PHY, a power provider must report its power class as 000b.

Since the power provider must have diodes on each port, it is also unable to pass power. The diodes provide a means of creating power domains. Domains provide a low-cost solution for adding power incrementally to the cable.

Current limiting must also be employed by all power providers to meet regula- tory requirements and must not exceed 1.5A.

Figure 25-2: Configuration of Power Provider

- Internal PHY Power +

Voltage PHY Regulator

Current Current Limit Limit

VG VP VG VP

435 26 Suspend & Resume

The Previous Chapter

The previous chapter discussed power distribution in the cable environment. It discussed the four power type designations for nodes: power providers, alternate power providers, power consumers, and self-powered devices. Details regarding the power implementation of nodes was also included. This Chapter

This chapter introduces the suspend and resume mechanisms. This capability allows the PHY layer within a node to enter a low power state under software control (either local node software or from another node). The mechanisms implemented for suspend and resume are detailed including: command and confirmation packets, suspend initiator actions, suspend target actions, and related suspend and resume signaling. The impact on PHY and port register definition is also discussed. The Next Chapter

The next chapter describes the CSR registers and ROM entries that define power management capabilities and provide the mechanisms for controlling the power states of a node and of local units within a node.

Overview

Due to the incomplete status of the suspend/resume documentation, this chapter provides only an overview of the suspend and resume capabilities and does not attempt to detail specific consideration and corner conditions that exist.

445 FireWire System Architecture

The goal of suspend and resume is to allow a pair of attached PHY ports to enter a low power state in which recovery to full power and operation is possible. In this way, a segment of the bus may be placed into a low power state. When a port is suspended it is no longer able to receive or transmit packets. However, suspended ports can detect whether a node is attached or detached.

To help understand the suspend capabilities consider the following example. Figure 26-1 on page 446 illustrates a 1394a only topology (i.e. all nodes are 1394a compliant) that interfaces to a PCI bus. Note that the node at the PCI bus has transferred a suspend command packet that target port 2 within the VCR node. In response, the VCR transmits a confirmation packet to confirm that the suspend command has been accepted. The command packet identifies the suspend initiator (the port responsible for signaling suspend).

Figure 26-1: PCI to 1394 Bridge Node Sends Suspend Command to VCR Node, Port 2

3&, %XV

PCI to IEEE 1394 Adapter

Suspend Confirmation

Suspend Command (targeting port 2)

123 Laser CD-ROM Desktop Set-top Video Printer Digital Camera VCR Box Camera

Refer to Figure 26-2. Immediately following the confirmation packet (after detecting the acknowledge gap), the suspend initiator (port 2 of the VCR node) signals suspend (TX_SUSPEND=00) to the node connected to port 2 (video camera), which detects the suspend (RX_SUSPEND=00). The video camera is

446 Chapter 26: Suspend & Resume

referred to as the suspend target. The node containing the suspend initiator also signals data prefix to its other ports followed by a short bus reset. Bus reset is then repeated to all nodes in the system except the node or nodes attached to the suspend initiator port.

The suspend initiator and suspend target perform a handshake and both enter a low power, or suspended state. When the tree ID process is performed following the short bus reset, the VCR node will report its port 2 as inactive, making all nodes attached to the inactive port invisible to the rest of the network.

Figure 26-2: Actions Taken by the Suspend Initiator

3&, %XV

PCI to IEEE 1394 Adapter DATA_PREFIX followed by DATA_PREFIX short bus reset followed by Repeated to all short bus reset other Ports

TX_SUSPEND RX_SUSPEND

123 Laser CD-ROM Desktop Set-top Video Printer Digital Camera VCR Box Camera Suspend Suspend Initator Target (port 2)

Once the bus is reset and the suspended port handshake completes, the new topology eliminates the video camera. No packets are transferred to the suspended ports and they are unable to transmit packets. (See Figure 26-3 on page 448).

447 FireWire System Architecture

If the video camera is activated by the user, it can signal resume causing a port event indication that can serve to notify the link and application. Further the video camera can signal the VCR of the event. The bus can again be reset to cause bus reconfiguration with the VCR and video camera ports once again active. Similarly, the PCI node may cause a resume operation by sending a resume command packet to the VCR. This would cause the VCR and video camera port to transition to the active state. Reset would be signaled and the bus reconfigured.

Figure 26-3: State of Network Following Bus Reset

3&, %XV

PCI to IEEE 1394 Adapter

Following bus reset and configuration the video camera will not be present in the topology

Suspended Ports (cannot transmit or receive packets)

123 Laser CD-ROM Desktop Set-top Video Printer Digital Camera VCR Box Camera

Suspending a Port

An active port may enter a suspended state under a variety of conditions:

• When a suspend command packet is received. The port number is specified in the address field of a suspend command packet. The command may be issued by another node or by the local link layer. • When the port detects suspend signaling (RX_SUSPEND) via its arbitration

448 Chapter 26: Suspend & Resume

comparators. • When the port resides within the same node as another port that has detected RX_SUSPEND. • When the port receives disable notify (RX_DISABLE_NOTIFY). • When TpBias is no longer detected.

Suspending via the Suspend Command Packet

Figure 26-4 on page 449 illustrates the format of the command packet that specifies “initiate suspend.” The port number field specifies the specific port within the target PHY that will become the suspend initiator. The target node responds to the command packet with a confirmation packet, illustrated in Figure 26-5. This packet contains the initiate suspend command to tie this confirmation to the previous command. The phy_ID field contains the phy ID of the confirming node.

Figure 26-4: “Initiate Suspend” Command Packet Format msb (transmitted first) Type cmnd 00b phy_ID 00b (8) zeros port zeros (2)

logical inverse of first quadlet

lsb (transmitted last)

Figure 26-5: Suspend Confirmation Packet Format msb (transmitted first) Type cmnd 00b phy_ID 00b(Ah) zeros port zeros f cbdok (2)

logical inverse of first quadlet

lsb (transmitted last)

449 27 Power State Management

The Previous Chapter

The previous chapter introduced the suspend and resume mechanisms. This capability allows the PHY layer within a node to enter a low power state under software control (either local node software or from another node). The mechanisms implemented for suspend and resume were detailed including: command and confirmation packets, suspend initiator actions, suspend target actions, and related suspend and resume signaling. The impact on PHY and port register definition were also discussed. This Chapter

This chapter describes the CSR registers and ROM entries that define power management capabilities and provide the mechanisms for controlling the power states of a node and of local units within a node.

Power Management

Power management involves the control of the power states of individual nodes or units within nodes. Four power states are defined that permit control over the node and individual units. To support power management, additional CSR registers and ROM entries are also defined.

The goal of power management is to enable applications to control transitions in the power states, so that power can be managed efficiently. This capability includes the following:

• A mechanism to allow applications at one node to determine the power- related abilities of a remote node or functional units within a node, and to determine its current power state. • A mechanism to permit a remote application to enable a power feature and control the power state.

459 FireWire System Architecture

• A mechanism to allow a remote node to notify the power manager node of changes in its power state that affect bus operation. • A mechanism to notify a node that has entered a low power state that a remote event has occurred that should wake the node up. • Ability of the power manager node to facilitate the actions and capabilities required by the power management model, to determine the abilities of a power provider node, and to control the level of power that a power provider supplies to the bus.

Note that some of the power management features are controlled directly by the power manager node (i.e. the bus manager node), while other management features at the functional unit level are implementation specific and are intended to be controlled by the related application.

Power States

Four power states provide the ability to control power within each node and a functional unit within nodes. The definition of the node power states are defined for global power management control, while unit power states are specific to a given functional unit. Node Power States

Node power states provide the operational states of the PHY and link. Table 27-1 lists the node power states. New CSR registers are defined that control the transition between states. Each state is summarized below.

Table 27-1: Node Power States

Node Power State Link Power PHY Power Node Context

N0 On (or standby) On Preserved

N1 Off On Unspecified

N2 Off Suspend Unspecified

N3 Off Off Lost

460 Chapter 27: Power State Management

Node Power State Zero (N0). This state represents the full-on power state in which the PHY and link (via a link-on packet) are both powered.

Note that N0 may include an optional standby feature, in which the link may be partially suspended and the transaction and higher layers may be in a fully suspended state, thus reducing power consumption. If a transaction targets a node that is in standby, the link must be able to decode the address and return an ACK_TARDY acknowledge code (See Table 8-15 on page 192). The link must also return to its fully functional state and initiate a wake up to the higher layers. Once the node has recovered from the standby condition, it can service the request when it is retried by the requesting node.

The amount of power consumed by the node in the N0 state is required to be less than the value reported in the self-ID packet. Actual power consumption may be reported in a new configuration ROM entry called the Node_Power_Level entry. There may exist multiple Node_Power_Level entries, one for each state.

Node Power State One (N1). The N1 state reflects the condition of the node prior to receiving the link-on packet. This state exists between bus reset and receipt of the link-on packet.

Node Power State Two (N2). N2 is the suspend state during which the link has been powered off and the PHY is in a low power condition. Conse- quently, the PHY is unable to perform any of its normal functions (i.e. it cannot repeat, receive, or transmit packets). The only action supported by the PHY in the N2 state is that it can detect a remote wakeup signal, causing it to return to the N0 state.

Node Power State Three (N3). N3 represents the full off condition in which the link and PHY are not powered. In this condition the node context is lost. Unit Power States

Four power states are also defined for functional units within the node. These states are defined in Table 27-2. The unit power states have an implied relationship with an application or software driver that utilizes the functional unit.

The relationship between the node and unit power states must also be maintained to ensure sufficient power is available to support the level of power required by the unit. The node power state must always provide equal (same state value) or greater (lower state value) capability than the unit. For example,

461 FireWire System Architecture

if one or more units within the node are currently running at a power state of D1, it is the responsibility of the node to not place the node into a power state lower than N1 (i.e. any request to place the node into the N2 or N3 power state would only result in a transition to N1).

Table 27-2: Unit Power States

Node Power Operational Description State Condition

D0 Fully operational All unit context is maintained and full function- (required) ality is available. This state is required by all units.

D1 Unit dependent Power consumption is this state is less than D0. (optional) The time required to transition from D1 to D0 is less than the time to transition from D0 to D2. Unit context is preserved, but some functionality may be lost.

D2 Unit dependent Power consumption is this state is less than D1. (optional) The time required to transition from D2 to D0 or D1 is less than the time required to transition from D3 to either D0 or D1. Unit context may not be preserved.

D3 Not operational No power is consumed by the unit and external (optional power may be removed.

462 Chapter 27: Power State Management

New CSRs

A variety of new CSR registers are required to support the power management functions. Nodes that support the new power management capability must implement some of the power-related CSRs; these nodes include:

• Power management capable nodes • Nodes that support power management or implement one or more units that support power management. • Nodes that implement batteries • Units that support power management • Power providers

The power-related CSRs are mapped within a node’s initial units address space at location FFFF F001 0000h or higher. Two groups of registers are defined:

• node-specific CSRs — the start address of this register block is specified by the Node_Power_Management entry within configuration ROM. Each power-related CSR occupies a specific offset within the block as illustrated in Table 27-3. • unit-specific CSRs — the location of the base address is specified by the node’s Unit_Power_Management entry within configuration ROM. Each power-related unit CSR occupies a specific offset, illustrated in Table 27-4.

Table 27-3: Node-Specific Power-Related CSRs

Relative Name Required Description Offset

00h NODE_POWER_STATE Mandatory Reports the node’s power state.

04h NODE_POWER_CONTROL Mandatory Permits the node’s power state to be managed.

08h NOTIFICATION_ADDRESS Optional Destination address for power status change notification or request.

Ch CABLE_POWER_SOURCE_STATE Optional Reports the node’s current power provider status.

10h CABLE_POWER_SOURCE_CONTROL Optional Permits the node’s power provider status to change.

463 Index

Numerics asynchronous arbitration 147 1394-1995 210, 279 asynchronous bus bandwidth 40, 152 1394a 211 asynchronous packet 56 1394a supplement 16, 20, 87 asynchronous request receipt 71 4-conductor cable 90 asynchronous response generation 73 4-pin connector 85, 87 asynchronous stream packet 174 64-bit fixed addressing 28 asynchronous transaction summary 193 6-conductor cable 89 asynchronous transaction, example 60 6-pin connector 85, 86 asynchronous transactions 38, 40, 56 A asynchronous transfers 30, 37 acceleration control 159 attachment/detachment 275 ack_busy_A 251, 256 AX_ARB_STATE_TIME 275 ack_busy_B 251, 257, 258 B ack_busy_x 249 bandwidth set aside 341, 353, 356 ack_data_err 260 BANDWIDTH_AVAILABLE ack_data_error 259 register 79, 336, 339, 350, 353, 384 ack_type_err 260 BANDWIDTH_AVAILABLE ack_type_error 259 register, accessing 340 ack-accelerated arbitration 157 Battery_Group entry 476 acknowledge accelerated arbitration 157 Battery_State entry 476 acknowledge codes 57, 72, 192, 248 BATTERY_STATE register 471 acknowledge Gap 125 bias change 282 acknowledge packet 57, 191 bias handshake 451 acknowledge packet generation 72 bias voltage 98 acknowledge packet parity error 259, 261 broadcast interrupts 34 acknowledge packet time-out 259 broadcast messages 34 acknowledge time-out 260 broadcast packet 46 active domains 452 bus bandwidth 79 address space 17, 28 bus bandwidth allocation 39, 44 ARB_RESET_GAP 257 bus bandwidth available register 353 arbitrated (short) bus reset 283 Bus bandwidth set-aside 353 arbitrated bus reset 283 bus bandwidth set-aside 341, 350 arbitration 54, 112 bus configuration 55 arbitration enable bit 148 bus idle 100 arbitration enhancements 157 bus information block 412 arbitration line states 112 bus initialization 273 arbitration receiver decoding 108 bus initialization overview 267 arbitration receivers 107 bus management 343 arbitration reset gap 126 bus management layer 42, 44, 351 arbitration signaling 142 bus management overview 272 arbitration timeout 304 bus management services 344, 351 asymmetric connection change 282 bus manager 44, 344, 353

503 Index bus manager ID 356 common mode signaling 96 bus manager, identifying 344 communications model 38 bus powered nodes 138 company_ID value 423 Bus reset 278 compare and swap 338 bus reset 110, 273, 274, 277, 353, 364 concatenated transactions 159 bus reset signaling 275 configuration 23, 34, 110 bus reset, effects of 277 configuration overview 266 bus reset, sources of 274 configuration ROM 33, 409 Bus_Info_Block 412 confirmation packet 449 BUS_MANAGER_ID register 344, 347, Confirmation service 45 383 connect change 455 BUS_TIME register 329, 377 connect detect 451, 453 busy retry 248 connect_timeout 280 BUSY_TIMEOUT registe 249 connection change 278, 282 BUSY_TIMEOUT register 252, 382 connection detection 280 C constant current source 121 cable assembly 90, 91, 92 Control and Status Registers (CSR) Archi- cable cross section, 4-conductor 90 tecture 361 cable cross section, 6-conductor 89 CRC 57 cable electrical characteristics 89 CRC checks 40 cable length 89 CRC error 259 cable power 56, 133 CSR 33 Cable Power Distribution Specification CSR achitecture - 1394 specific 376 (Revision 0.93) 429 CSR architecture 25, 33, 46, 361 cable, 4-conductor 90 CSR register summary - 1394 specific 376 cable, characteristic impedance 89 CSR register summary - Core regs 363 cable, signal velocity 89 CSRs, power-related 463 CABLE_POWER_SOURCE_CONTROL cycle master 44, 329 Register 467 cycle master enable (cmstr) 368 Cable_Power_Source_Level entry 475 cycle master ID 356 Cable_Power_Source_State register 466 cycle master, enabling 329 channel number 44, 58, 79 cycle start jitter 154 CHANNELS_AVAILABLE register 79, cycle start packet 152, 330, 379 336, 337, 384 cycle start skew 152 CHANNELS_AVAILABLE register, ac- cycle synchronization event 79 cessing 337 CYCLE_TIME register 161, 377 characteristic cable impedance 89 cyclic redundancy check 57 Child_Notify 286 chip_id 415 cmstr (cycle master enable) 368 command packet 449, 452, 454 command reset 364

504 Index

D gap timing 127 data drivers 106 gap_count 278, 356 data end 114 gaps 125 data prefix signaling 114 general ROM format 33, 410 DATA_PREFIX 144 H data-stobe encoding 124 hot plug connector 87 data-strobe encoding 39, 122 I debounce time-out 280 IBR (initiate bus reset) 275 debouncing connection detect 280 IBR bit 278 definition 446, 451 IDENT_DONE 311 device bay 24, 93 identification done (IDENT_DONE) 311 Device Bay specification 20 IEEE 1212 2, 13, 19, 20, 24, 37 differential input voltages 104 IEEE 1394 25 differential output voltages 104 IEEE 1394.B specification 20 differential signaling 96 IEEE 1394-1995 specification 20 disable port command 452 IEEE 1596 25 disabled change 455 IEEE896 25 dominance rule for one 108, 109 immediate arbitration service 150 dribble bits 116 inactive domain 451 dual phase retry 251 Indication service 45 dual phase retry state machine 252, 255 initial memory space 28 E initial register space 28 error detection 18 initial unit address space 388 error handling 259, 262 initial units space 28 Example asynchronous request 69 initialization state 273 extended PHY packets 214, 355 interrupt broadcast 34, 375 extended type field 186 interrupt enable 456 F ISBR bit 278 fair arbitration 18 ISO/IEC 13213 2, 13, 19, 20, 24, 25, 37, 361 fairness interval 147, 148 isochronous arbitration 150 FAIRNESS_BUDGET register 161 isochronous bus bandwidth 152 fault 455 isochronous data packet size 201 features of 1394 17 isochronous gap 125, 141, 150 fly-by arbitration 157, 158 isochronous packet 46, 58 force root 213, 298 isochronous resource manager 44, 79, 333, force root delay 299 353, 356 fully managed bus 343 isochronous resource manager (IRM) 346 Futurebus+ 25 isochronous resource manager, G enabling 335 gap count 348 isochronous resource manager, gap count field in PHY registers 278 identifing 334 gap count optimization 348, 397

505 Index isochronous resource manager, max_rec 413 power management 342 maximum packet size 40 isochronous resource manager, message broadcasts 34 requirements 335 minimal ROM format 33 isochronous resources, reallocation of 342 module 25 isochronous stream packet 199 Module_Vendor_Id entry 419 isochronous transaction layer services 80 multiple buses 17 isochronous transaction summary 202 multi-speed concatenation 159 isochronous transaction, example 63 N isochronous transactions 39, 44 node 25 isochronous transfers 15, 32, 38, 41, 78 node attachment detect 97 K node attachment/detachment 275 key_type 418 node state 366 key_value 418 Node_Capabilities entry 419 L NODE_IDS register 369 line state decode 108 NODE_POWER_CONTROL register 464 line states 105 Node_Power_Directory entry 473 link layer 42, 47 Node_Power_Level entry 474 Link/PHY interface 222 Node_Power_Management Entry 475 Link/PHY interface, PHY reg access 241 Node_Unique_Id 414 Link/PHY interface, PHY status 238 Node_Unique_Id entry 419, 420 Link/PHY interface, receiving packets node_vendor_id 414 236 nodecast 375 linkoff 368 non-return to zero 56, 123 link-on packet 205, 212, 346, 354 NOTIFICATION_ADDRESS register 466 lock packet 183 NRZ 56, 123 lock request packet 184 null isochronous packet 201 lock response packet 189 O lock transactions 183 OHCI specification 20 lock types 186 Organizationally Unique Identifier (OUI) lock, compare and swap 338 423 locked transaction 30, 31 P long reset 279 packet acknowledgment 52 looped topology 304 packet error handling 259 looped topology detection 304 packet errors 259 lost 365 packet size 40 M packet transmission errors 259 MAINT_CONTROL register 386 Parent_Notify 286 MAINT_UTILITY register 386 partially managed bus 343 make first/break last pins 87 peer-to-peer transactions 17, 24 MAX_ARB_STATE_TIME 274, 283 PHY configuration packet 205, 213, 354, MAX_DATA_TIME 357 397

506 Index

PHY packet format 206 power reset 364 PHY register map - 1394a 398 power state changes 274 PHY register map - 1995 394 power states 460 PHY register reads 242 power states, nodes 460 PHY register writes 244 power states, units 461 PHY registers 393 Power Statue Management PHY registers, accessing 241 Specification (Revision 0.71) 429 PHY/link interface, POWER_CHANGE register 468 packet transmission 228 POWER_FAIL_IMMINENT register 380 Physical ID 278 Power_Level entry 477 physical ID 306, 356 POWER_SOURCE register 380 physical ID, selection of 306 primary power providers 434 physical layer 42, 53 priority arbitration 152, 161 ping packet 206, 214, 348, 355 PRIORITY_BUDGET register 161 port disable 452 Private space 28 port registers - 1394a 403 protocol layers 17, 42, 66 port repeater 59 R port status receiver 98 read packets 175 port status registers - 1995 397 read request - block packet 179 port suspend via loss of bias 453 read request - quadlet packet 176 Port_event bit 278 read response - block packet 181 power class 135 read response - quadlet packet 177 power class codes 432 read transaction 30 power consumers 437 remote access packet 206, 215, 355 power consumption remote command packet 206, 217, 355 requirements-1995 138 remote confirmation packet 206, 218, 355 power distribution 137, 431 remote reply packet 206, 216, 355 Power Distribution specification 20 repeater 23, 59 power management Request service 45 specification 20, 427, 429 request subaction 30 power management, 1394-1995 428 requester 30 power management, 1394a 428, 429, 459 reset duration 276 power management, 1995 345 reset signaling 110, 282 power management, by bus manager 345 reset storm 279 power management, by IRM 342, 346 reset, sources of 274 power management, RESET_START register 364, 373 CSR register summary 463 RESET_TIME 283 power management, CSR regs 461 responder 30 power management, response code 56, 191 review of 1995 specification 428 response packet errors 260 power management, ROM entries 472 response packet time-out 259, 261 power providers 433 Response service 45

507 Index response subaction 30 self-ID packet zero, 1394-1995 207 response transmission error 259 self-ID packet zero, 1394a 209 resume 454 self-ID packets 1 & 2 211 resume packet 206, 219, 355, 454 self-ID packets, contents 323 resuming via port events 455 self-ID signaling 306 resuming via resume packet 454 self-identification overview 270 resuming via resume self-identification process 305 port command packet 454 self-powered nodes 438 retry 247 serial bus control services 353 retry codes 248 short (or arbitrated) bus reset 283 retry limit 249, 252 short bus reset 283, 450 retry protocol 247 signal interface 102 retry_1 248, 251 signal velocity 89 retry_A 255, 256 single phase retry 249 retry_B 256, 257, 258 single phase retry state machine 249, 250 retry_busy_A 252 single retry state transitions 249 retry_busy_B 252 speed exchange 312 retry_X 255, 257 speed map 349, 390 retry_x 249 speed map, accessing 349 root contention 295 speed of transmission 17 root dependent directories 416 speed signaling 117, 118, 119 root directory 416 SPEED_MAP 388 root directory entries - required 419 Split transaction 49 Root Hold Off (RHB) 355 SPLIT_TIMEOUT register 373 root hold off bit (RHB) 356, 397 STATE register 364 root holdoff bit 213 STATE_CLEAR register 364, 365 root ID 356 STATE_SET register 364, 366 root leaf entries 416 storm of resets 279 ROOT_CONTEND_FAST 295 Stream packet 200 ROOT_CONTEND_SLOW 295 strobe drivers 106 RX_DISABLE_NOTIFY 452 subaction 30 RX_REQUEST 109, 142 subaction gap 126, 142, 147, 157 RX_SUSPEND 446 suspend command packet 448 S suspend initiator 446, 447, 450, 451 Scalable Coherent Interface 25 suspend signaling 448 SClk signal 227 suspend target 447, 451 self Identification (Self-ID) packet 205 suspend via command packet 449 self_ID packets 1-3 210, 325 suspend/resume 445 self-ID count 307 Suspend/Resume Specification self-ID packet 135, 307 (Revision 0.73) 429 self-ID packet one, two, & three 210 suspended port handshake 447 self-ID packet zero 207, 323 suspending port via loss of bias 453

508 Index suspending via port disable 451 Unit_Power_Requirements entry 422 suspending via RX_SUSPEND 451 UNIT_POWER_STATE register 469 T unmanaged bus 343 topology 23 V topology map 346, 389 vendor identification registers 407 topology map, accessing 347 vendor-ID 410 TOPOLOGY_MAP registers 388 W TPA 54 write request - block packet 171 TPB 54 write request - quadlet packet 169 TpBias 451 write response packet 173 transaction 30 write transaction 30 transaction codes - asynchronous 167 transaction label 78 transaction layer 42, 45 transaction layer services 45 transaction layers 17 transaction retry 247 transaction type, packet field 56 transaction types 45 transactions 30 Transfer Speed 39 transfer types 39 tree ID process 285, 286 tree ID signaling 286 tree identification overview 268 tree-ID state 277 twisted pair signaling 54 twisted pairs 95 TX_DISABLE_NOTIFY 452 TX_GRANT 142, 144 TX_REQUEST 109, 142, 143, 275 TX_SUSPEND 446, 450 U Unified transaction 50 unified transactions 52 unit 25 unit dependent directories 417 unit directory entries 416 unit leaf entries 417 UNIT_POWER_CONTROL Register 470 Unit_Power_Directory Entry 477 Unit_Power_Management entry 477

509