 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| TSB12LV32 EP IEEE 1394 1995 and P1394a Compliant General Purpose Link Layer Controller Data Manual October 2002 Mixed-Signal Products SGLS139 IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI's terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI's standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third-party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. Mailing Address: Texas Instruments Post Office Box 655303 Dallas, Texas 75265 Copyright 2002, Texas Instruments Incorporated Contents Section 1 Title Page 1-1 1-1 1-2 1-3 1-4 1-5 1-8 1-8 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 TSB12LV32 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 TSB12LV32-EP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Terminal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Terminal Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 STAT0, STAT1, and STAT2 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Internal Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.1 TSB12LV32 Configuration Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.2 Configuration Register Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2.2.1 Version Register at 00h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2.2.2 Data Mover Control Register at 04h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2.2.3 Control Register at 08h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 2.2.4 Interrupt/Interrupt Mask Register at 0Ch and 10h . . . . . . . . . . . . . . . . . . . . . 2-9 2.2.5 Cycle Timer Register at 14h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 2.2.6 Isochronous Port Register at 18h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2.2.7 Maint_Control Register at 1Ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13 2.2.8 Diagnostic Register at 20h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 2.2.9 Phy Access Register at 24h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 2.2.10 Reserved Registers at 28h - 2Ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 2.2.11 FIFO Status Register at 30h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16 2.2.12 Bus Reset Register at 34h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17 2.2.13 Header0 Register at 38h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 2.2.14 Header1 Register at 3Ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19 2.2.15 Header2 Register at 40h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19 2.2.16 Header3 Register at 44h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19 2.2.17 Trailer Register at 48h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20 2.2.18 Asynchronous Retry Register at 4Ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 2.2.19 Asynchronous Retry Register at 4Ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Microcontroller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.1 Microcontroller Byte Stack (Write) Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3.2 Microcontroller Byte Unstack (Read) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 3.3 Microcontroller Interface Read/Write Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 3.3.1 Microcontroller Handshake Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 3.3.2 Microcontroller Fixed-Timing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 3.3.3 Microcontroller ColdFire Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.3.4 Microcontroller Critical TIming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.3.5 Endian Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 iii 3 Section 4 Title Page 4-1 4-1 4-1 4-1 4-2 4-2 4-2 4-2 Link Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Cycle Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Cycle Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Cyclic Redundancy Check (CRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Packet Routing Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Data Mover Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.1 Data Mover Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 5.1.1 Isochronous Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 5.1.2 Isochronous Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 5.1.3 Asynchronous Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 5.1.4 Asynchronous Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 5.2 Data Mover Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 5.2.1 Isochronous Transmit With Automatic Header Insertion . . . . . . . . . . . . . . 5-11 5.2.2 Isochronous Transmit Without Automatic Header Insertion . . . . . . . . . . . 5-12 5.2.3 Isochronous Packet Receive Without Header and Trailer . . . . . . . . . . . . . 5-13 5.2.4 Isochronous Packet Receive With Header and Trailer . . . . . . . . . . . . . . . 5-13 5.2.5 Asynchronous Packet Transmit With Automatic Header Insertion . . . . . . 5-14 5.2.6 Asynchronous Packet Transmit Without Automatic Header Insertion . . . 5-15 5.2.7 Asynchronous Packet Receive With Headers and Trailer . . . . . . . . . . . . . 5-16 5.2.8 Asynchronous Packet Receive Without Headers and Trailer . . . . . . . . . . 5-16 5.3 Data Mover Byte Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 5.4 Data Mover Endian Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 5.5 Data Mover Handshake Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 5.6 Data Mover Critical Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 FIFO Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 ATF Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 ATF Burst Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 General-Receive-FIFO (GRF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 GRF Stored Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 6-1 6-1 6-2 6-2 6-3 6 7 TSB12LV32 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 7.1 Asynchronous Transmit (Host Bus to TSB12LV32) . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 7.1.1 Quadlet Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 7.1.2 Block Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 7.1.3 Quadlet Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 7.1.4 Block Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 7.2 Isochronous Transmit (Host Bus to TSB12LV32) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7.2.1 Isochronous Receive (TSB12LV32 to Host Bus) . . . . . . . . . . . . . . . . . . . . . 7-7 7.3 Phy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9 7.3.1 Extended Phy Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 7.4 Receive Self-ID Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13 iv Section 8 Title Page TSB12LV32/Phy Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 8.1 Principles of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 8.2 TSB12LV32 Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8.3 Status Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 8.4 Receive Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 8.5 Transmit Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 8.6 TSB12LV32/Phy Interface Critical Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Absolute Maximum Ratings Over Operating Free-Air Temperature Range . . . . . 9.2 Recommended Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Electrical Characteristics Over Recommended Ranges of Supply Voltage and Operating Free-Air Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 9-1 9-1 9-2 9 10 Mechanical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 v List of Illustrations Figure Title Page 1-1 TSB12LV32 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 3-1 Microcontroller Byte Stack Operation (Write) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3-2 Microcontroller Byte Unstack Operation (Read) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 3-3 Byte Handshake Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 3-4 Word Handshake Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 3-5 Byte Handshake Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 3-6 Word Handshake Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 3-7 Byte Fixed-Timing Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 3-8 Word Fixed-Timing Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3-9 Byte Fixed-Timing Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3-10 Word Fixed-Timing Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3-11 GRF Read Access (Byte Fixed-Timing Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3-12 GRF Read Access (Word Fixed-Timing Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3-13 ColdFire Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3-14 ColdFire Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3-15 Big Endian Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3-16 Little Endian Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3-17 Little-Endian Data Invariance Illustration Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 3-18 Little-Endian Address Invariance Illustration Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 4-1 Link Core Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 5-1 A Typical System Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5-2 Isochronous DM Flow Control (TSB12LV32 Transmit) . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 5-3 Transmit Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 5-4 Asychronous DM Flow Control (TSB12LV32 Transmit) . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 5-5 Isochronous Receive Without Header and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 5-6 Isochronous Receive With Header and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 5-7 Isochronous Transmit With Auto Header Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 5-8 Isochronous Transmit Without Auto Header Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 5-9 Asynchronous Receive Without Headers and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 5-10 Asynchronous Receive With Headers and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 5-11 Asynchronous Transmit With Auto Header Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 5-12 Asynchronous Transmit Without Auto Header Insertion . . . . . . . . . . . . . . . . . . . . . . . 5-10 5-13 Isochronous Transmit With Auto Header Insertion at 400 Mbps . . . . . . . . . . . . . . . . 5-11 5-14 Isochronous Transmit With Auto Header Insertion at 200 Mbps . . . . . . . . . . . . . . . . 5-11 5-15 Isochronous Transmit With Auto Header Insertion at 100 Mbps . . . . . . . . . . . . . . . . 5-12 5-16 Isochronous Transmit Without Auto Header Insertion . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 5-17 Isochronous Receive Without Header and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 5-18 Isochronous Receive With Header and Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 5-19 Isochronous Receive With Header and Trailer at 200 Mbps . . . . . . . . . . . . . . . . . . . . 5-14 5-20 Asynchronous Quadlet Transmit With Automatic Header Insertion . . . . . . . . . . . . . . 5-14 5-21 Asynchronous Block Transmit With Automatic Header Insertion at 200 Mbps . . . . 5-14 vi 5-22 Asynchronous Block Transmit With Automatic Header Insertion at 400 Mbps . . . . 5-15 5-23 Asynchronous Quadlet Transmit Without Automatic Header Insertion at 400 Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15 5-24 Asynchronous Block Transmit Without Automatic Header Insertion at 400 Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15 5-25 Asynchronous Quadlet Receive With Headers and Trailer at 400 Mbps . . . . . . . . . 5-16 5-26 Asynchronous Block Receive With Headers and Trailer at 400 Mbps . . . . . . . . . . . 5-16 5-27 Asynchronous Quadlet Receive Without Headers and Trailer at 400 Mbps . . . . . . 5-17 5-28 Asynchronous Block Receive Without Headers and Trailer at 400 Mbps . . . . . . . . . 5-17 5-29 Endian Swapping in Byte Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 5-30 Endian Swapping in Word Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 5-31 Data Mover Handshake Mode (GPLynx mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 5-32 Clock to Output Timing With Respect to DMCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 6-1 TSB12LV32 Controller-FIFO-Access Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 6-2 Asynchronous Packet With N Quadlets (ATV Loading Operation) . . . . . . . . . . . . . . . . 6-1 7-1 Quadlet-Transmit Format (Write Request) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 7-2 Quadlet-Transmit Format (Read Response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 7-3 Block-Transmit Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 7-4 FIFO Quadlet-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 7-5 Data Mover Quadlet-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 7-6 FIFO Block-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 7-7 Data Mover Block-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 7-8 Isochronous-Transmit Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7-9 Data Mover Isochronous-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7-10 GRF Isochronous-Receive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 7-11 Phy Configuration Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9 7-12 Received Phy Configuration Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 7-13 Ping Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 7-14 Remote Access Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 7-15 Remote Command Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 7-16 Resume Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 7-17 Receive Self-ID Packet Format (RXSID=1, FULLSID=1) . . . . . . . . . . . . . . . . . . . . . . 7-13 7-18 Receive Self-ID Packet Format (RXSID=1, FULLSID=0) . . . . . . . . . . . . . . . . . . . . . . 7-13 7-19 Phy Self-ID Packet #0 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 7-20 Phy Self-ID Packet #1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 7-21 Phy Self-ID Packet #2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 8-1 Phy-LLC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 8-2 LREQ Request Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8-3 Status Transfer Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 8-4 Normal Packet Reception Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 8-5 Null Packet Reception Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 8-6 Normal Packet Transmission Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9 8-7 Critical Timing for the TSB12LV32/Phy Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 vii List of Tables Table Title Page 1-1 Terminal Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 1-2 STAT Terminals Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8 2-1 Configuration Register (CFR) Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2-2 Header Usage for CFRs 38h-44h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 3-1 Microcontroller Interface Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3-2 TSB12LV32 MP/MC Interface Terminal Function Matrix . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3-3 Endian Swapping Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 4-1 Receiver Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 5-1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 5-2 CLK to Output Timing With Respect to DMCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 6-1 Packet Token Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 7-1 Quadlet-Transmit Format Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 7-2 Block-Transmit Format Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 7-3 Quadlet-Receive Format Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 7-4 Block-Receive Format Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 7-5 Isochronous-Transmit Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7-6 Isochronous-Receive Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 7-7 Phy Configuration Packet Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9 7-8 Receive Phy-Configuration Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 7-9 Ping Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 7-10 Remote Access Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 7-11 Remote Command Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 7-12 Resume Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 7-13 GRF Receive Self-ID Setup Using Control Register Bits (RXSID and FULLSID) . . 7-13 7-14 Receive Self-ID Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13 7-15 Phy Self-ID Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15 8-1 CTL Encoding When the Phy Has Control of the Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 8-2 CTL Encoding When the TSB12LV32 Has Control of the Bus . . . . . . . . . . . . . . . . . . . . 8-2 8-3 Request Stream Bit Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8-4 Request Type Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8-5 Bus Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8-6 Bus Request Speed Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 8-7 Read Register Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 8-8 Write Register Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 8-9 Acceleration Control Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 8-10 Status Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 8-11 Receive Speed Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 viii 1 Overview 1.1 TSB12LV32 Description The TSB12LV32 (GP2Lynx) is a high-performance general-purpose IEEE P1394a link-layer controller (LLC) with the capability of transferring data between a host controller, the 1394 Phy-link interface, and external devices connected to the data mover port (local bus interface). The 1394 Phy-link interface provides the connection to the 1394 physical layer device and is supported by the LLC. The LLC provides the control for transmitting and receiving 1394 packet data between the microcontroller interface and the Phy-link interface via internal 2K byte FIFOs at rates up to 400 Mbit/s. The TSB12LV32 transmits and receives correctly formatted 1394 packets, generates and detects the 1394 cycle start packets, communicates transaction layer transmit requests to the Phy, and generates and inspects the 32-bit cyclic redundancy check (CRC). The TSB12LV32 is capable of being cycle master (CM), isochronous resource manager (IRM), bus manager, and supports reception of isochronous data on two channels. The TSB12LV32 supports a direct interface to many microprocessors/microcontrollers including programmable endian swapping. TSB12LV32 has a generic 16/8-bit host bus interface which includes support for the ColdFire microcontroller mode at rates up to 60 MHz. The microinterface may operate in byte or word (16 bit) accesses. The data mover block in GP2Lynx is meant to handle an external memory interface of large data blocks. The port can be configured to either transmit or receive data packets. The packets can be either asynchronous, isochronous, or streaming data packets. Asynchronous or isochronous receive packets will be routed to the DM port or the GRF via the receiver routing control logic. The internal FIFO is separated into a transmit FIFO and a receive FIFO each of 517 quadlets (2 Kbytes). Asynchronous packets may be transmitted from the DM port or the internal FIFO. If there is contention the FIFO has priority and will be transmitted first. The LLC also provides the capability to receive status information from the physical layer device and to access the physical layer control and status registers by the application software. ColdFire is a trademark of Motorola, Inc. 1-1 1.2 TSB12LV32-EP Features * * * * * * * * * * * * * * * * * * * * Controlled Baseline One Assembly/Test Site, One Fabrication Site Extended Temperature Performance of -40C to 110C Enhanced Diminishing Manufacturing Sources (DMS) Support Enhanced Product Change Notification Qualification Pedigree Compliant With IEEE 1394-1995 Standards and P1394a Supplement for High Performance Serial Bus Supports Transfer Rates of 400, 200, or 100 Mbit/s Compatible With Texas Instruments Physical Layer Controllers (Phys) Supports the Texas Instruments Bus Holder Galvanic Isolation Barrier Glueless Interface to 68000 and ColdFire Microcontrollers/Microprocessors Supports ColdFire Burst Transfers 2K-Byte General Receive FIFO (GRF) Accessed Through Microcontroller Interface Supports Asynchronous and Isochronous Receive 2K-Byte Asynchronous Transmit FIFO (ATF) Accessed Through Microcontroller Interface Supports Asynchronous Transmissions Programmable Microcontroller Interface With 8-Bit or 16-Bit Data Bus, Multiple Modes of Operation Including Burst Mode, and Clock Frequency to 60 MHz. 8-Bit or 16-Bit Data Mover Port (DM Port) Supports Isochronous, Asynchronous, and Streaming Transmit/Receive From an Unbuffered Port at a Clock Frequency of 25 MHz. Backward Compatible With All TSB12LV31(GPLynx) Microcontroller and Data Mover Functionality in Hardware. Four-Channel Support for Isochronous Transmit From Unbufferred 8/16 Bit Data Mover Port. Single 3.3-V Supply Operation With 5-V Tolerance Using 5-V Bias Terminals. High Performance 100-Pin PZ Package Component qualification in accordance with JEDEC and industry standards to ensure reliable operation over an extended temperature range. This includes, but is not limited to, Highly Accelerated Stress Test (HAST) or biased 85/85, temperature cycle, autoclave or unbiased HAST, electromigration, bond intermetallic life, and mold compound life. Such qualification testing should not be viewed as justifying use of this component beyond specified performance and environmental limits. Implements technology covered by one or more patents of Apple Computer, Incorporated and SGS Thomson, Limited. 1-2 1.3 Functional Block Diagram Microcontroller Interface MA0 - MA6 7 16 7 Host Interface Byte Stacker 8-/16-to-32 32 bits Address 7 Data 32 CFR Status CTL[0:1] D[0:7] LREQ LPS LinkOn Physical Layer Chip (PHY) ATF FIFO GRF 2K ATF 2K GRF 16 Data Mover DM 32 32 DM IR/IR DM IT/AT Packet Router Control ATF 32 ARF 32 IRF 32 Link Core Control MD0 - MD15 MCA MCS MRW BCLK Data Mover Port DM D0-D15 DM Control DMCLK /2 SCLK Figure 1-1. TSB12LV32 Functional Block Diagram 1-3 1.4 Terminal Assignments PZ PACKAGE (TOP VIEW) 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 GND MD0 MD1 MD2 MD3 VDD MD4 MD5 MD6 MD7 GND MD8 MD9 MD10 MD11 VDD 5V MD12 MD13 MD14 MD15 VDD DIRECT GND DMREADY CYCLEIN INT CYSTART TEA MCA GND BCLK MCS MWR RESET VDD5V MDINV COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 VDD TESTMODE MA6 MA5 MA4 VDD MA3 MA2 MA1 MA0 GND 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 TSB12LV32 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 LENDIAN LREQ GND SCLK VDD CTL0 CTL1 VDD D0 D1 CONTNDR LINKON D2 D3 D4 D5 D6 D7 GND STAT2 STAT1 STAT0 LPS DMERROR PKTFLAG 1-4 DMD0 DMD1 DMD2 DMD3 GND DMD4 DMD5 DMD6 DMD7 VDD 5V DMD8 DMD9 DMD10 DMD11 VDD DMD12 DMD13 DMD14 DMD15 GND DMCLK VDD DMPRE DMRW DMDONE 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 1.5 Terminal Functions Table 1-1. Terminal Functions TERMINAL The terminal functions are described in Table 1-1. NAME BCLK COLDFIRE LENDIAN NO. 6 12 75 I/O DESCRIPTION Microcontroller/Microprocessor Interface I I I Microinterface clock. Maximum frequency is 60 MHz. In the ColdFire mode, BCLK is the same as CLK, which is the clock-input signal to the ColdFire. ColdFire mode. To operate in this mode, COLDFIRE must be asserted high. Little-endian mode for the microinterface. When this terminal is pulled up, the data on MD0-MD15 will be byte-swapped to little endian byte format before it is written to the CFR or FIFO and after it is read from the CFR or FIFO. Microcontroller address bus. MA0 is the most significant bit (MSB) of these 7 bits. Configuration bit for microinterface. If the microinterface is 8 bits wide, this terminal must be pulled up to the supply voltage. In ColdFire mode, this terminal represents burst SIZ0. Mode bit for microinterface. If the microinterface wants to communicate in a handshake manner this terminal must be pulled up to the supply voltage. When the ColdFire mode terminal (12) is high, this terminal represents burst SIZ1. Microinterface cycle acknowledge. When asserted low, MCA signals an acknowledge of the microcontroller cycle from the TSB12LV32. Microinterface cycle start. When asserted low, MCS signals the beginning of a microcontroller operation to the TSB12LV32. Microinterface data invariant mode. This terminal is meaningful only when LENDIAN (75) is high. When asserted high, the microinterface operates in the data invariant mode. When low, the microinterface operates in address invariant mode. Microinterface bidirectional data bus. MD0 is the most significant bit. However, byte significance is dependent on the state of the LENDIAN and MDINV terminals. Microcontroller read/write indicator. When asserted high, MWR indicates a read access from the TSB12LV32. When asserted low, MWR indicates a write access to the TSB12LV32. Transfer error acknowledge. This active-low signal is asserted low for one BCLK cycle whenever there is an illegal transfer request by the microcontroller (i.e., requested data transfer size is unsupported or MCS is asserted low for more than one BCLK cycle in ColdFire mode). MA0 - MA6 M8BIT/SIZ0 24 - 21 19 - 17 13 I I MCMODE/SIZ1 14 I MCA MCS MDINV 4 7 11 O I I MD0 - MD15 99 - 96 94 - 91 89 - 86 84 - 81 8 I/O MWR I TEA 3 O 1-5 Table 1-1. Terminal Functions (Continued) TERMINAL NAME DMD0-DMD15 NO. 26 - 29 31 - 34 36 - 39 41 - 44 46 50 I/O DESCRIPTION Data-Mover Port Interface I/O Data mover (DM) bidirectional data port. DMD0 is the MSB of these 16 bits. DMCLK DMDONE O O Data mover clock at (SCLK/2) MHz Data mover done. For transmit, this will be activated when the packet per block counter in the CFR counts down to zero. For receive, this terminal will pulse for one DMCLK prior to the first byte/word available to the DM interface. Data mover error. DMERROR is asserted high when there is an error in the received packet or an illegal transmit speed was attempted. Data mover predata indicator. In transmit mode, DMPRE pulses for one DMCLK prior to sending the first quadlet. In isochronous receive mode, DMPRE will pulse for one DMCLK when the sync bit in the header matches a bit set in the isochronous register. DMPRE is not used in asynchronous receive mode. Data mover ready. Must be asserted high by the external logic controlling the DM interface when it is ready to supply data for transmit. DMREADY must be set low when the data mover is in receive mode. Data mover read/write indicator. When data is being moved from 1394 to the DM port (receive) this signal will go active high to indicate data is available on DMD[0:15]. When data is being moved from DM to 1394 bus (transmit) this signal will go active high to indicate that data must be supplied to the DMD[0:15] port for transmission. Packet flag. When set, PKTFLAG is asserted high to indicate the first (header) or last (trailer) quadlet of a received packet on the DM interface. PKTFLAG is not valid in transmit mode. Phy/Link Interface Phy-link interface control lines. Phy-link interface data lines. Data is only expected on D0 and D1 at 100 Mbit/s, D0-D3 at 200 Mbit/s, and D0-D7 at 400 Mbit/s. D0 is the MSB bit. Link-on from the Phy is a 4 MHz - 8 MHz clock. This signal will be activated when the link is inactive and the Phy has detected a link-on packet or a Phy interrupt. This clock will persist for no more than 500 ns. When the link detects this terminal as active, it will turn on and drive LPS. Link power status. LPS is used to drive the LPS input to the Phy. It indicates to the Phy that the link is powered up and active. LPS toggles at a rate = 1/16 of BCLK. Link request to Phy. LREQ makes bus requests and register access requests to the Phy. System clock. SCLK is a 49.152 MHz clock supplied by the Phy. DMCLK is generated from SCLK. DMERROR DMPRE 52 48 O O DMREADY 77 I DMRW 49 O PKTFLAG 51 O CTL0, CTL1 D0-D7 LINKON 70, 69 67, 66, 63-58 64 I/O I/O I LPS LREQ SCLK 53 74 72 O O I 1-6 Table 1-1. Terminal Functions (Continued) TERMINAL NAME CONTNDR NO. 65 I/O DESCRIPTION Miscellaneous Functions I/O Contender. When asserted high, this terminal tells the link that this node is a contender for isochronous resource manager (IRM) or bus manager functions. The state of the CONTNDR must match the state of the Phy contender terminal for 1394-1995 compliant Phys, and the Phy register bit for 1394.A compliant Phys. This terminal defaults to being an input on power up. After power up, the value of this terminal may be driven internally by the CTNDRSTAT bit (bit#12 at 08h) Cycle in. This input is an optional external 8-kHz clock used as the isochronous cycle clock. It should only be used if attached to the cycle-master node. It is enabled by the cycle source bit and should be tied high when not used. Isochronous cycle start indicator. CYSTART signals the beginning an isochronous cycle by pulsing for one DMCLK period. Isolation terminal. When this terminal is asserted high, no isolation is present between the TSB12LV32 and the Phy. When low, bus holder isolation becomes active. Ground reference CYCLEIN 76 I CYSTART DIRECT 2 79 O I GND 5, 25, 30, 45, 57, 73, 78, 90, 100 1 9 54 - 56 16 10, 35, 85 O I O I INT RESET STAT0-STAT2 TESTMODE VDD5V Interrupt. NOR of all internal interrupts. System reset. This active low signal is asynchronous to the TSB12LV32. General status outputs. STATn is the output signal selected with the CFR at address 20h. This terminal is used to place the TSB12LV32 in the test mode. In normal operation, this terminal must be tied to ground. 5 V ( 0.5V) supply voltage for 5-V tolerant inputs. Only the Phy/link interface side of the TSB12LV32 is not 5-V tolerant. Tie this terminal to the 3.3-V supply voltage if the TSB12LV32 is not connected to any devices driving 5-V signals. Tie this terminal to the 5-V supply voltage if the TSB12LV32 is connected to any devices driving 5-V signals. This terminal is only used to make inputs 5-V tolerant, it is not used for any outputs. 3.3 V ( 0.3 V) supply voltage VDD 15, 20, 40, 47, 68, 71, 80, 95 1-7 1.5.1 STAT0, STAT1, and STAT2 Programming STAT0, STAT1 and STAT2 terminals can be independently programmed to show one of fourteen possible internal hardware status. The controls for the STAT terminals are in the Diagnostic register at address 20h of the CFR register. STAT0 is controlled by STATSEL0(bits 16-19), STAT1 is controlled by bits STATSEL1(bits 20-23), and STAT2 is controlled by STATSEL2 (bits 24-27). Refer to Table 1-2 for programming the STAT terminals. Table 1-2. STAT Terminals Programming STATSEL0, STATSEL1, or STATSEL2 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 STAT0/STAT1/STAT2 Reserved ATFFULL Bus Reset Arbitration reset gap CYCLEOUT RXDMPKT RXGRFPKT BX_BUSY SUBGP CYCLE_DONE ATSTARTED (default setting for STAT1) DMACKERR DMEN GRFEMPTY (default setting for STAT2) Reserved Reserved Reserved ATF is full. Bit 12 in CFR at 30h. 1394 Bus reset. Bit 3 in CFR at 0Ch Bit 26 in CFR at 0Ch Cycle out. This is the link's cycle clock. It is based on the timer controls and the received cycle-start messages. Packet received to DM interrupt. Activated at the end of a received packet. Bit 9 in CFR at 0Ch Packet received to GRF interrupt. Activated at the end of a received packet. . Bit 6 of CFR at 0Ch Byte busy. This represents the OR of bits 0 - 3 of CFR at 20h Subaction gap. Activated upon detection of a subaction gap. Bit 27 in CFR at 0Ch Cycle done. Indicates the end of the isochronous period. This happens when a subaction gap has been detected. Activated when an asynchronous packet transfer has started from the ATF. Bit 5 in CFR at 0Ch DM acknowledge was not Complete. Bit 17 in CFR at 0Ch DM enable. Bit 26 in CFR at 04h GRF is empty. Bit 15 in CFR at 30h. Reserved Reserved DESCRIPTION 1.6 Ordering Information TEMPERATURE -40C to 110C ORDERING NUMBER TSB12LV32TPZEP TOP-SIDE MARKING TSB12LV32TEP PACKAGE 100-Terminal PQFP 1-8 2 Internal Registers 2.1 TSB12LV32 Configuration Registers 2-1 Table 2-1. Configuration Register (CFR) Map MSB 01 00h 0 1 2 1 34 10 5 0 6 0 7 1 8 0 LSB 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 1 0 ENDSWAP 1 BYTEMODE 0 HANDSHK 1 AUTOUP 0 0 1 1 1 0 0 SPEED 0 1 CHNLCNT 0 1 DMEN 0 DMHDR 0 AR0 0 AR1 0 DMASYNC 0 DMRX IARBFL IARBFL MONTAG LPS_OFF VERSION (711538A0h) 04h PACKET PER BLOCK DMACK DM Control ENA_INSERT_IDLE CLSIDER CMAUTO FULLSID BSYCTL IRP1EN SID ERROR CODE IRP2EN CYMAS CYSRC RXSLD RSTRX CYTEN RSTTX BDIV0 BDIV1 RXEN TXEN 08h FIFOACKCOMP PHY_PKT_ENA ENA_CONCAT DMACKCOMP ENA_ACCEL CTNDRSTAT CTNDRISIN BUSNRST FLSHERR Control ATSTARTED ATSTARTED SELFIDEND SELFIDEND DMACKERR ATFEMPTY DMERROR RXDMPKT MCERROR RXGRFPKT SELFIDER LINKON ATSTK CMDRST HDRERR FIFOACK PHRRX CARBFL TCERR CYDNE PHRST SNTRJ CYSEC PHINT 0Ch ARBGP SUBGP CYLST CYST INT Interrupt DMACKERR ATFEMPTY DMERROR RXDMPKT MCERROR RXGRFPKT SELFIDER LINKON ATSTK CMDRST HDRERR FIFOACK PHRRX CARBFL TCERR CYDNE PHRST SNTRJ CYSEC PHINT ARBGP SUBGP CYLST CYST INT 10h Interrupt Mask Cycle Timer 14h 18h SECONDS COUNT TAG1 IRPORT1 F_ACK B2_BUSY NO_PKT B0_PND NO_ACK TAG2 CYCLE COUNT IRPORT2 CYCLE OFFSET IRCVALL ISYNCRCVN Isochronous Port B0_BUSY E_HCRC WRPHY B1_BUSY E_DCRC 1Ch ACK RAM_TEST PING VALUE Maint_Control B3_BUSY B1_PND B2_PND B3_PND 20h REGRW STATSEL0 STATSEL1 STATSEL2 Diagnostic 24h 28h-2Ch RDPHY PHYRGAD PHYRGDATA PHYRXAD PHYRXDATA Phy Access Reserved ATFWBMTY GRFEMPTY ATFFULL GRFCLR ATFCLR 30h CD ATFAVAIL CONTENDER ATACK GRFUSED FIFO Status NRIDVAL ROOT 34h 38h 3Ch 40h 44h NODECNT IRMNODEID BUS NUMBER NODE NUMBER Bus Reset Header0 Header1 Header2 Header3 LPS_RESET 48h NUMBER OF QUADLETS ACKCODE SPD Trailer 4Ch ASYNC RETRY COUNT RETRY INTERVAL Asynchronous Retry NOTES: A. All dark gray areas (bits) are reserved bits. B. All light gray areas are read-only bits. All remaining are read/write bits. 2-2 Table 2-2. Header Usage for CFRs 38h-44h DIRECTION OF DM DATA TRANSFER PACKET TYPE AUTO HEADER INSERT/ EXTRACT YES Isochronous NO TRANSMIT (to 1394 Bus) Asynchronous/ asynchronous streaming HEADER REGISTER Header 0 CFR formatted for isochronous transmission. Header1 - Header3 are used for additional channels. Isochronous header supplied by DM interface. Header0 CFR is automatically written with extracted (from transmitted packet) isochronous header. Header0-Header3 CFRs formatted for asynchronous transmission. Asynchronous header supplied by DM interface. Header0 - Header3 CFRs are automatically written with extracted (from transmitted packet) header. Header0 - Header3 are always automatically updated. The isochronous header is streamed through the DM port. The trailer quadlet is always appended to the data stream. Header0 - Header3 are always automatically updated. The isochronous header is streamed through the DM port along with the payload data. The trailer quadlet is always appended to the data stream. Header0 - Header3 are always automatically updated. Asynchronous headers are not streamed through the DM port. The trailer quadlet is always appended to the data stream. Header0 - Header3 are always automatically updated. Asynchronous headers are streamed through the DM port along with data. The trailer quadlet is always appended to the data stream. YES NO YES Isochronous/ asynchronous streaming RECEIVE (from 1394 Bus) NO YES Asynchronous NO 2-3 2.2 2.2.1 Configuration Register Definitions Version Register at 00h 1 0 1 0 10 0 1 1 1 0 0 0 1 0 1 0 0 0 00 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0111000100 0 This register uniquely identifies this device to the software. The value is fixed at 7115_38A0'h. This register is read only. 2.2.2 Data Mover Control Register at 04h BYTEMODE HANDSHK ENDSWAP CHNLCNT DMASYNC AUTOUP SPEED DMHDR 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 DMEN PACKET PER BLOCK DMACK DMRX AR0 AR1 This register controls the Data Mover port and must be set up before using the port. The power-up reset value of this register = 0000_0000'h BIT NUMBER 0-11 BIT NAME PACKET PERBLOCK FUNCTION Packets per Block DIR R/W DESCRIPTION Number of packets per block. A packet is the size of the data payload and is specified as part of the header. The data mover logic uses this value to deactivate DMDONE. This field is only used in transmit mode. Swap endian. When this bit is set, the quadlet formed by stacking the DM data will be byte reversed, (i.e. the quadlet formed by fetching doublet AB01 then `CD02' will be 02CD-01AB instead of AB01CD02). In byte mode the quadlet formed by fetching AB, 01, CD, 0 will be 02CD01AB instead of AB01CD02. Byte mode. When this bit is set the DM port will only look at DM0-DM7. DM8-DM15 will be ignored for transmit and will not be driven on receive. In this mode, the maximum speed allowed is 200 Mbps. Handshake. When this bit is 1 DMREADY and DMDONE are in strict handshake mode (i.e., TSB12LV31 compatible mode). DMREADY must not be deactivated until DMDONE activates. When this bit is set to 0, DMREADY may be deactivated before DMDONE activates. Automatic update offset address. Valid only for asynchronous transmit using header insert mode (bit 27 DMHDR set to 1). For write request asynchronous packets, header quadlet 2 contains the destination offset low address for the write. When this bit is set, header quadlet 2 will be updated by the value of the payload size (rounded up to the nearest quadlet boundary). DM acknowledge. This is the ack received from the receiving node. This is updated only when the transfer is from the DM port. RESERVED DM Speed Code R/W Speed code. This is valid for isochronous transmit and asynchronous transmit through the DM port. The DM logic uses this field to specify to the Phy the speed of the isochronous transfer. 12 ENDSWAP Endian Swap R/W 13 BYTEMODE Byte Mode R/W 14 HANDSHK Handshake Mode (CPLynx Mode) R/W 15 AUTOUP Automatic Address Update R/W 16-20 DMACK DM Acknowledge R 21 22-23 RESERVED SPEED 2-4 BIT NUMBER 24-25 BIT NAME CHNLCNT FUNCTION Channel Count DIR R/W DESCRIPTION Channel count. This field is valid only in isochronous transmit. This field allows the node to transmit multiple packets during a single isochronous period. Each packet must have a different channel number, however, hardware does not check this. When the isochronous transmit header is supplied by the DM interface or automatically inserted by the hardware, a maximum of four different channels may be accessed in one isochronous period. In isochronous transmit with automatic header insert, Header0-Header3 CFRs are used as the isochronous header registers. DMEN controls the transmission of packets from the DM port. If this bit is 0, transmission through from the DM port is inhibited. This is used for asynchronous flow control. In normal operation, if an asynchronous packet transmitted from the DM port receives an acknowledge from the receiving node other than ack complete, this bit will be set to 0 and DMERROR is asserted high. Software will need to set this bit to allow further transmission of asynchronous packets from the DM port. The default and power-up value is 0. DM header insert bit. When set to 0, the hardware will automatically insert the header(s) into the DM transmit data. In receive, setting this bit to 0 will strip off the header(s) before routing packet to the DM. Header(s) are always written to the CFR header registers regardless of the value of DMHDR. Receive packet routing control encoded bits. These bits in conjunction with DMASYNC and DMRX bits in the DM control register controls the routing of the received packet to either the data mover port or to the GRF. Refer to Table 4-1. If this bit is set to 1 the DM port is configured for asynchronous traffic only. The DM port can not accept both asynchronous and isochronous traffic. It must be configured for asynchronous (DMASYNC = 1) or isochronous (DMASYNC = 0). If this bit is set to 1 the DM port is configured to receive. The DM port cannot both transmit and receive data at the same time, it must be configured for either transmit or receive. 26 DMEN DM Enable R/W 27 DMHDR DM Header Insert Control R/W 28-29 AR0, AR1 Receive Control Routing R/W 30 DMASYNC DM Asynchronous R/W 31 DMRX DM Receive R/W 2-5 2.2.3 Control Register at 08h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ENA_INSERT_IDLE FIFOACKCOMP PHY_PKT_ENA ENA_CONCAT DMACKCOMP ENA_ACCEL CTNDRSTAT CTNDRISIN BUSNRST FLSHERR BSYCTRL CLSIDER CMAUTO FULLSID IRP1EN CYMAS SIDERCODE The control register dictates the basic operation of the TSB12LV32. The power-up reset value of this register equals E004_0200'h BIT NUMBER 0 BIT NAME FLSHERR FUNCTION Flush GRF on error DIR R/W DESCRIPTION This bit controls the flushing of the GRF when a packet with a data CRC error is detected. The power-up value is 1, which means flush the GRF when a data CRC error is detected. If set, the self-identification (SID) packets generated by Phy devices during the bus initialization are received and placed into the GRF as a single packet. The default setting of this bit is 1. When set to 0, the SIDs are not placed into the GRF. Save the full self-ID packets.When this bit is 1 the self-ID data quadlet and its inverse quadlet are saved in the GRF. When this bit is 0 only the self-ID data quadlet is saved in the GRF. Phy packet enable allows reception of all Phy packets. If this bit is reset to 0, all Phy packets, except for self-IDs, will be rejected and interrupt HDERR (if not masked) will be generated. One HDERR interrupt will be generated for every Phy packet received. BSYCTRL controls which busy status the chip returns to incoming packets. When this bit is 0 the chip follows normal busy/retry protocol, only send busy when necessary. When this bit is 1 the chip sends a busy acknowledge to all incoming packets following the normal busy/retry protocol. When TXEN is cleared, the transmitter does not arbitrate or send packets. TXEN bit is cleared following a bus reset, and all traffic through the DM port will be interrupted. TXEN must be set before packet transmit can resume. Power-on reset value of TXEN is 0 When RXEN is cleared, the receiver does not receive any packets. This bit is not affected by a bus reset and is set to 0 after a power-on reset. Enable acceleration. When this bit is set, fly-by acceleration and accelerated arbitration are enabled. This bit cannot be set while TXEN and RXEN are set. This bit must only be used with a 1394a capable Phy. Enable concatenation. When this bit is set it allows the link to concatenate multiple isochronous or asynchronous packets. This bit must only be used with a 1394a capable Phy. 1 RXSID Received Self-ID packets Save full Self-ID Packet in GRF Phy Packets Receive Enable R/W 2 FULLSID R/W 3 PHY_PKT_ENA R/W 4 BSYCTRL Busy Control R/W 5 TXEN Transmit Enable R/W 6 RXEN Receive Enable Acceleration Enable R/W 7 ENA_ACCEL R/W 8 ENA_CONCAT Concatenation Enable R/W 2-6 IRP2EN CYSRC RSTRX CYTEN RSTTX RXSID BDIV0 BDIV1 RXEN TXEN BIT NUMBER 9 BIT NAME ENA_ INSERT_IDLE FUNCTION Insert Idle Enable DIR R/W DESCRIPTION Per P1394a, the link is required to insert an idle state on the control lines after the Phy grants the link control of the Phy/link interface. If using a P1394a Phy, this bit should be set to 1 in order for the link to drive an idle state following the grant state from the Phy. For 1394-1995 Phys this bit must remain low. When RSTTX is set, the entire transmitter resets synchronously. This bit clears itself. When RSTRX is set, the entire receiver resets synchronously. This bit clears itself. Contender status. On power up, this bit reflects the status of the CONTNDR pin. When bit 13, CTNDRISIN, is 0 this bit will be driven out to the CONTNDR pin. If CTNDRISIN is 1 this bit is not used. (Only use on 1394-1995 Phys, or P1394a Phys when using hardware reset, otherwise, use the 1394a Phy registers to set the nodes contender status). Driver enable for the CONTNDR pin. On power up this bit is set to 1 which disables the driver and allows reading of the state of the CONTNDR pin. Writing a 0 to this bit will enable the driver and will drive bit 12, CTNDRSTAT, to the CONTNDR pin. Reserved 10 11 12 RSTTX RSTRX CTNDRSTAT Transmitter Reset Receiver Reset Contenter status R/W R/W R/W 13 CTNDRISIN Contender Driver Enable R/W 14 15 16-17 RESERVED BUSNRST BDIV0, BDIV1 Bus number reset enable BCLK divisor encode bits R/W R/W When this enable is set to high, the bus number field clears to 3FFh when a local bus reset is received. BCLK divisors encode bits. Used to divide down the BCLK to generate the link power status (LPS) clock to the Phy. BDIV0 0 BDIV1 0 DESCRIPTION Divide by 16. Default power on value. Recommended for BCLK frequencies in the range of 8 - 88 MHz. Divide by 2. Recommended for BCLK frequencies in the range of 1 - 11 MHz. Divide by 4. Recommended for BCLK frequencies in the range of 2 - 22 MHz. Divide by 32. Recommended for BCLK frequencies in the range of 16 - 176 MHz 0 1 1 1 0 1 18 DMACKCOMP Data Mover Acknowledge Complete R/W Data mover acknowledge complete. This bit controls the acknowledge response to an asynchronous packet received and routed to the DM port. The default and power on value is 0 which means to respond with ack pending. A 1 means to respond with an ack complete for write request packets. FIFO acknowledge complete. This bit controls the acknowledge response to an asynchronous packet received and routed to the GRF. The default and power on value is 0 which means to respond with ack pending. A 1 means to respond with ack complete. 2-7 19 FIFOACKCOMP FIFO Acknowledge Complete R/W BIT NUMBER 20 BIT NAME CYMAS FUNCTION Cycle Master DIR R/W DESCRIPTION When CYMAS is set and the TSB12LV32 is attached to the root Phy, the cyclemaster function is enabled. When the cycle_count field of the cycle timer register increments, the transmitter sends a cycle-start packet. When CYSRC is set, the cycle_count field increments and the cycle_offset field resets for each positive transition of CYCLEIN. When CYSRC is cleared, the cycle_count field increments when the cycle_offset field rolls over. When CYTEN is set, the cycle_offset field increments. When CLRSIDER is set, the SIDERCODE field (bits 24-27) is cleared.This bit clears itself. SIDERCODE contains the error code of the first Self-ID Error. The error code is as follows: 0000 0001 0010 0011 0100 0101 0110 0111 1000 No error Last self-ID received was not all child ports Received Phy ID in self-ID not as expected Quadlet not inverted (phase error) Phy ID sequence error (two or more gaps in IDs) Phy ID sequence error (large gap in IDs) Phy ID error within packet Quadlet not the inversion of the prior quadlet Reserved 21 CYSRC Cycle Source R/W 22 23 CYTEN CLRSIDER Cycle timer enable Self-ID error-code clear Self-ID error code R/W W 24-27 SIDERCODE R 28 CMAUTO Auto set cycle master IR port 1 enable IR port 2 enable R/W When CMAUTO is high, the TSB12LV32 automatically enables CYMAS when the this node becomes the root following a bus reset. When IRP1EN is set, the receiver accepts isochronous packets when the channel number matches the value in the IR port1 field at18h When IRP2EN is set, the receiver accepts isochronous packets when the channel number matches the value in the IR Port2 field at18h Reserved 29 IRP1EN R/W 30 IRP2EN R/W 31 RESERVED 2-8 2.2.4 Interrupt/Interrupt Mask Register at 0Ch and 10h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ATSTARTED SELFIDEND DMERROR ATFEMPTY RXDMPKT SELFIDER DMACKERR MCERROR RXGRFPKT CMDRST HDRERR LINKON FIFOACK CYDNE CARBFL PHRRX ATSTK ARBGP SUBGP TCERR The interrupt and interrupt mask register work in tandem to inform the host bus interface when the state of the TSB12LV32 changes. The interrupt register is at 0Ch, the interrupt mask register is at 10h. The interrupt register powers up all 0s, however, the interrupt mask register powers up with the INT and the MCERROR bit set, i.e. 8000_1000h. The mask bits allows individual control for each interrupt. A 1 in the mask bit field allows the corresponding interrupt in the interrupt register to be generated. Once an interrupt is generated it must be cleared by writing a 1 to the bit in the interrupt register. For testing, each interrupt bit can be set manually. This is done by first setting the REGRW bit at20h and then setting the individual interrupt bit. This is also true for bit 0 at0Ch. In this test mode, the interrupt mask register is not used and has no effect. BIT NUMBER 0 1 2 BIT NAME INT PHINT PHRRX FUNCTION Interrupt Phy chip interrupt Phy register information received Phy reset started Self-ID validated Asynchronous transfer started GRF packet received CSR register reset request Data Mover error DIR R/W R/W R/W DESCRIPTION INT contains the value of all interrupt and interrupt mask bits ORed together When PHINT is set, the Phy has signalled an interrupt through the Phy interface When PHRRX is set, a register value has been transferred to the Phy access register (offset 24h) from the Phy interface When PHRST is set, a Phy-LLC reconfiguration has started (1394 bus reset) Self-ID end. This bit is set at the end of the self-ID reporting process. When this bit is set, the contentF of the bus reset CFR at34h is valid. Asynchronous transfer started. Activated when the bus has been granted and the first quadlet from the FIFO is about to be popped from the ATF. Receive packet to GRF. This bit is set whenever a complete packet has been confirmed into the GRF (asynchronous or isochronous). If CMDRST is set, the receiver has been sent a quadlet write request to the Reset_Start CSR register(target address is FFFF_F000_000Ch) DM error. This bit will be set whenever there is an error in the DM stream. For transmit, if the DM port is configured for byte access and the speed code in the DM control register or the asynchronous header register is set for 400 Mbps then this bit will be set. Under this condition DMEN will be reset to 0 preventing further transmit. For receive this bit will be set if there is a header or data CRC error or if the DM port is configured for byte access and the data is received at 400 Mbps. Receive packet to DM. This bit is set whenever a packet is received to the DM port. Set if an error in the self-ID quadlet/packet has been detected. 2-9 3 4 PHRST SELFIDEND R/W R/W 5 ATSTARTED R/W 6 RXGRFPKT R/W 7 CMDRST R/W 8 DMERROR R/W 9 10 RXDMPKT SELFIDER Data Mover packet receive Self-ID packet error R/W R/W IARBFL PHINT CYSEC PHRST SNTRJ CYLST CYST INT BIT NUMBER 11 BIT NAME LINKON FUNCTION Link-ON detect DIR R/W DESCRIPTION Set if a link-on pulse is detected on the LINKON input terminal. This bit should be used by software to reactivate the LPS output to the Phy. When ATSTK is set, the transmitter has detected invalid data at the asynchronous transmit-FIFO interface. If the first quadlet of a packet is not written to the ATF_First or ATF_First&Update, the underflow of the ATF also causes an ATStuck interrupt. When this state is entered, no asynchronous packets can be sent until the ATF is cleared by way of the CLR ATF control bit. Isochronous packets can be sent while in this state. ATFEMPTY. This bit is set to 1 when the ATF is empty. When SNTRJ is set, the receiver is forced to send a busy acknowledge to a packet addressed to this node because the GRF overflowed. When HDRERR is set, the receiver detected a header CRC error on an incoming packet that may have been addressed to this node. When TCERR is set, the transmitter detected an invalid transaction code in the data at the transmit-FIFO interface. DM acknowledge error. Set to 1 when the acknowledge received is not ack complete. When this occurs, DMEN(bit 26) of the DM Control CFR at04h will be reset to 0 and no more asynchronous transmit from the DM port will be allowed to take place until DMEN is set to 1. FIFO ack interrupt. This bit will be set when an acknowledge from a previous ATF transmit has been received. Micro-interface error. Set whenever the microcontroller write protocol is violated. When CYSEC is set, the cycle-second field in the cycle timer register has incremented. This occurs about every second when the cycle timer is enabled. When CYST is set, the transmitter has sent or the receiver has received a cycle-start packet. When CYDNE is set, an arbitration gap has been detected on the bus after the transmission or reception of a cycle-start packet. This indicates that the isochronous cycle is over. RESERVED 12 ATSTK Transmitter is stuck (AT) R/W 13 14 ATFEMPTY SNTRJ ATF empty interrupt Busy acknowledge sent by receiver Header error R/W R/W 15 HDRERR R/W 16 17 TCERR DMACKERR Transaction code error Data Mover acknowledge error R/W R/W 18 FIFOACK FIFO acknowledge interrupt Micro-interface error Cycle second incremented Cycle started Cycle done R/W 19 20 MCERROR CYSEC R/W R/W 21 22 CYST CYDNE R/W R/W 23 24 RESERVED CYLST Cycle lost R/W When CYLST is set, the cycle timer has rolled over twice without the reception of a cycle-start packet. This occurs only when this node is not the cycle master. All isochronous traffic stop once CYLST is set. However, asynchronous and asynchronous streaming traffic will not be affected. When CARBFL is set, the arbitration to send a cycle-start packet has failed. When ARBGP is set, the serial bus has been idle for an arbitration reset gap. 25 26 CARBFL ARBGP Cycle arbitration failed Arbitration gap R/W R/W 2-10 BIT NUMBER 27 BIT NAME SUBGP FUNCTION Subaction gap DIR R/W DESCRIPTION When SUBGP is set, the serial bus has been idle for a subaction gap time (fair-gap). This bit can be set only when the REGRW bit has been set in the diagnostics register at 20h. RESERVED 28-30 31 RESERVED IARBFL Isochronous arbitration failed R/W When IARFL is set, the arbitration to send an isochronous packet has failed. 2.2.5 Cycle Timer Register at 14h CYCLE COUNT CYCLE OFFSET 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 SECOND COUNT This register must be written to as a quadlet. The power-up reset value of this register = 0000_0000'h BIT NUMBER 0-6 7-19 20-31 BIT NAME Seconds_count Cycle_count Cycle_offset FUNCTION NAME Seconds count Cycle count Cycle offset DIR R/W R/W R/W DESCRIPTION 1-Hz cycle timer counter 8,000-Hz cycle timer counter 24.576-MHz cycle timer counter 2-11 2.2.6 TAG1 Isochronous Port Register at 18h IRCVALL MONTAG TAG2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 IRPORT1 IRPORT2 ISYNCRCVN The power-up reset value of this register = 0000_0000h BIT NUMBER 0-1 2-7 BIT NAME TAG1 IRPORT1 FUNCTION Tag Field 1 Isochronous receive port 1 channel number Tag Field 2 Isochronous receive port 2 channel number Synchronous Enable DIR R/W R/W DESCRIPTION The TAG1 field can further qualify the isochronous reception for isochronous Receive PORT1 when the MONTAG bit is set. IR port1 contains the channel number of the isochronous packets that the receiver accepts. The receiver accepts isochronous packets with this channel number when the IRP1EN is set. The TAG2 field can further qualify the isochronous reception for isochronous Receive PORT2 when the MONTAG bit is set. IR port2 contains the channel number of the isochronous packets that the receiver accepts. The receiver accepts isochronous packets with this channel number when the IRP2EN is set. Reserved R/W In isochronous receive mode to the DM port, when the ISYNCRCVN enable bits are high, the DMPRE terminal pulses when an isochronous packet is received whose SYNC bit field in its header matches the bit pattern in this field. The default is 0000b. When the IRCVALL bit is set high, the TSB12LV32 receives all isochronous packets regardless of the channel number or tag number. The default is off. Reserved Match on tag R/W MONTAG is set when the user wants to only accept isochronous packets that match both the tag field and the channel number field. When set, MONTAG indicates that isochronous receive data is accepted. The default is off. 8-9 10-15 TAG2 IRPORT2 R/W R/W 16-23 24-27 RESERVED ISYNCRCVN 28 IRCVALL Receive all isochronous packets R/W 29-30 31 RESERVED MONTAG 2-12 2.2.7 E_HCRC E_DCRC NO_PKT Maint_Control Register at 1Ch NO_ACK 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 F_ACK ACK PING VALUE This register is used to generate test conditions. The control bits in this register allow errors to be inserted into various places in the packets generated by this node. After the completion of error insertion, enabled error-insertion controls are disabled. The power-up reset value of this register = 0000_0000'h BIT NUMBER 0 BIT NAME E_HCRC FUNCTION Header CRC Error DIR R/W DESCRIPTION If E_HCRC is set, the packet header CRC component of the next primary packet generated by this node shall be in error or shall be invalid; otherwise, this bit has no effect. After the next packet for this node is generated, this bit will be cleared. If E_DCRC is set, the packet data CRC component of the next primary packet generated by this node shall be in error or shall be invalid; otherwise, this bit has no effect. After the next packet for this node is generated, this bit will be cleared to zero immediately upon transmission of the erroneous CRC. If NO_PKT is set, the next primary packet to be generated by this node shall be discarded. This bit will be cleared to zero immediately after the next packet for this node is discarded. If F_ACK is set, the ack field shall be used within the next acknowledge packet generated by this node. This bit will be cleared to zero immediately after the next acknowledge packet for this node is generated. If NO_ACK is set, the next acknowledge packet (that would normally have been generated by this node) is not sent. This bit will be immediately cleared to zero when the next acknowledge packet for this node is discarded. Reserved R/W The 8-bit ACK field contains the 8-bit acknowledge packet (ack_code and ack_parity) to be supplied when the F_ACK bit indicates a modified acknowledge packet is to be generated. Reserved Ping timer value R/W Ping timer value. This value reflects the time it takes a node to respond to a ping packet. The granularity of this timer is 40 ns. 1 E_DCRC Data CRC Error R/W 2 NO_PKT No Packet R/W 3 F_ACK Ack Field R/W 4 NO_ACK R/W 5-7 8-15 RESERVED ACK 16-23 24-31 RESERVED PINGVALUE 2-13 2.2.8 B0_BUSY B1_BUSY B2_BUSY Diagnostic Register at 20h B3_BUSY RAMTEST 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 B1_PND B2_PND B0_PND B3_PND REGRW STATESEL0 STATESEL1 STATESEL2 The power-up reset value of this register = 0000_4AD0'h BIT NUMBER 0 BIT NAME B0_BUSY FUNCTION Byte 0 busy DIR R DESCRIPTION Byte 0 busy. When this bit is set, no microinterface write to byte 0 of any CFRs is allowed. The microinterface must first poll this bit before writing to byte 0. Byte 1 busy. When this bit is set, no microinterface write to byte 1 of any CFRs is allowed. The microinterface must first poll this bit before writing to byte 1. Byte 2 busy. When this bit is set, no microinterface write to byte 2 of any CFRs is allowed. The microinterface must first poll this bit before writing to byte 2. Byte 3 busy. When this bit is set, no microinterface write to byte 3 of any CFRs is allowed. The microinterface must first poll this bit before writing to byte 3. Byte 0 pending. When this bit is set, it indicates that byte 0 of a word or quadlet write has been accepted and the hardware is waiting for the remaining bytes to be written. When the full write is complete, this bit will be cleared. Byte 1 pending. When this bit is set, it indicates that byte 1 of a word or quadlet write has been accepted and the hardware is waiting for the remaining bytes to be written. When the full write is complete, this bit will be cleared. Byte 2 pending. When this bit is set, it indicates that byte 2 of a word or quadlet write has been accepted and the hardware is waiting for the remaining bytes to be written. When the full write is complete, this bit will be cleared. Byte 3 pending. When this bit is set, it indicates that byte 3 of a word or quadlet write has been accepted and the hardware is waiting for the remaining bytes to be written. When the full write is complete this bit will be cleared. This bit can be set only when TESTMODE is high. When this bit is set, the built in self test(BIST) for the FIFOs (transmit and receive) will be run. On completion of the test hardware will reset this bit to 0 and simultaneously set bit 30 and 31. When REGRW is set, write-protected bits in various registers can be written to. Reserved State0 select State1 select State2 select R/W R/W R/W Status output select bits. Used to program the output of STAT0 terminal. See table in Operation section. Status output select bits. Used to program the output of STAT1 terminal. See table in Operation section. Status output select bits. Used to program the output of STAT2 terminal. See table in Operation section. Reserved 1 B1_BUSY Byte 1 busy R 2 B2_BUSY Byte 2 busy R 3 B3_BUSY Byte 3 busy R 4 B0_PND Byte 0 pending R 5 B1_PND Byte 1 pending R 6 B2_PND Byte 2 pending R 7 B3_PND Byte 3 pending R 8 RAM_TEST R/W 9 REGRW Register read/write access R/W 10-15 16-19 20-23 24-27 28-31 2-14 RESERVED STATSEL0 STATSEL1 STATSEL2 RESERVED 2.2.9 WRPHY RDPHY Phy Access Register at 24h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 PHYRGAD PHYRGDATA PHYRXAD PHYRXDATA The Phy access register allows access to the registers in the attached Phy. The most significant 16 bits send read and write requests to the Phy registers. The least significant 16 bits are for the Phy to respond to a read request sent by the TSB12LV32. The Phy access register also allows the Phy interface to send information back to the TSB12LV32. When the Phy interface sends new information to the TSB12LV32, the Phy register-information-receive (PhyRRx) interrupt is set. The Phy acess register is at address 24h and is a read/write register. The power-up reset value of this register = 0000_0000'h. BIT NUMBER 0 BIT NAME RDPHY FUNCTION Read Phy register Write Phy register DIR R/W DESCRIPTION When RDPHY is set, the TSB12LV32 sends a read register request with the address equal to the PHYRGAD field to the Phy interface. This bit is cleared when the request is sent. When WRPHY is set, the TSB12LV32 sends a write register request with the address equal to the PHYRGAD field to the Phy interface. This bit is cleared when the request is sent. RESERVED Phy-register address Phy-register data R/W R/W PHYRGAD is the address of the Phy register that is to be accessed. PHYRGDATA is the data to be written to the Phy register indicated in PHYRGAD. RESERVED Phy-register received address Phy-register received data R/W PHYRXAD is the address of the register from which PHYRXDATA came. For testing, these bits can be set only when the REGRW bit has been set in the diagnostics register at20h. PHYRXDATA contains the data from the register addressed by PHYRXAD. For testing, these bits can be set only when the REGRW bit has been set in the diagnostics register at20h. 1 WRPHY R/W 2-3 4-7 8-15 16-19 20-23 RESERVED PHYRGAD PHYRGDATA RESERVED PHYRXAD 24-31 PHYRXDATA R/W 2.2.10 Reserved Registers at 28h - 2Ch These registers are reserved for future use. 2-15 2.2.11 ATFWBMTY FIFO Status Register at 30h GRFEMPTY ATFFULL GRFCLR 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ATFCLR CD ATFAVAIL ATACK GRFUSED The power-up reset value of this register = 6083_0000'h BIT NUMBER 0 1 2-11 12 13 14 15 16 17-21 22-31 BIT NAME ATFCLR ATFWBMTY ATFAVAIL ATFFULL GRFCLR RESERVED GRFEMPTY CD ATACK GRFUSED GRF empty Check 33rd bit (GRF read) ATF acknowledge GRF space used R R R R FUNCTION ATF clear ATF write buffer empty ATF space available ATF full bit GRF clear bit DIR R/W R R R R/W DESCRIPTION ATF clear. When set to 1 will clear the ATF. This bit clears itself. ATF write buffer empty. Set when the 4-quadlet FIFO write buffer is empty. Size of ATF available, in quadlets. The power-on value of this field is 1000001000 (520 quadlets) When the ATF is full, this bit will be set. GRF clear bit. Set to 1 to clear the contents of the GRF. Reserved GRF empty. GRFEMPTY is set when the four-quadlet GRF read buffer is empty. This bit is set to 1 when the quadlet pointed to by the GRF read pointer is the first quadlet or the packet trailer. The acknowledge received in response to a packet sent via the ATF. GRF space used, in quadlets. This value is the amount of used up quadlets in the GRF. 2-16 2.2.12 NRIDVAL Bus Reset Register at 34h CONTENDER 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ROOT NODECNT IRMNODEID BUS NUMBER NODE NUMBER The power-up reset value of this register = 81BF_FFC0'h. NOTE: The power-up reset value shown above assumes one node on the bus only. A P1394a compliant Phy is assumed to be attached to the TSB12LV32. If a 1394-1995 Phy is attached to the TSB12LV32 link, the NODECNT filed will be 0. This is due to the fact that a 1394-1995 compliant Phy does not report its self-ID packet back to the local link. BIT NUMBER 0 BIT NAME NRIDVAL FUNCTION Valid DIR R DESCRIPTION When set, NRIDVAL indicates that the Node ID, IRM Node ID, Node Count, and Root information are valid. This bit is read only. Reserved Node count R NODECNT contains the number of nodes detected in the system. This field is loaded with 1 following a power-on reset. The NODECNT field is read only. Root is set when the current node is the root node. This bit is read only. Contender contains the status of the TSB12LV32 CONTNDR terminal. This bit is read only. IRMNODEID is the isochronous resource manager node identification. If there is no IRM node present on the bus, these bits will be equal to 3Fh. These bits are read only. BUSNUMBER is the 10-bit IEEE-1212 bus number. These bits are set to 3FFh when RBUSNUM is set and there is a bus reset. NODENUMBER is the node number of the current node. These bits are automatically updated following a bus reset. To change the node number of this node (spoofing), the TESTMODE terminal must be set high. 1 2-7 RESERVED NODECNT 8 9 10-15 ROOT CONTENDER IRMNODEID Root Contender IRM node identification Bus number R R R 16-25 BUSNUMBER R/W 26-31 NODENUMBER Node number R/W 2-17 2.2.13 Header0 Register at 38h Header0 register must contain the isochronous header or the first quadlet of an asynchronous header if in header insert mode. If not in header insert mode or if in receive mode, this register will be updated with the received header. This register is write protected such that it cannot be written to unless automatic header insert mode is enabled and DM is in transmit mode(i.e.,DMHDR=0 and DMRX=0). The power-up reset value of this register = 0000_0000'h ISOCHRONOUS HEADER FOR QUADLET 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 PACKET DATA LENGTH TAG CHANNEL NUMBER Tcode Sync Bits BIT NUMBER 0-15 16-17 18-23 24-27 28-31 BIT NAME PacketDataLength TAG ChannelNumber Tcode Syncbits FUNCTION Packet data length Tag field Channel number Transmission code Synchronization code DIR R/W R/W R/W R/W R/W DESCRIPTION Packet data length in bytes. The tag field provides a high-level label for the format of the data carried by the isochronous packet. Channel number field Packet transaction code An application-specific control field ASYNCHRONOUS HEADER FOR QUADLET 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Speed Tlabel Rt Tcode Priority BIT NUMBER 0-13 14-15 BIT NAME RESERVED Speed FUNCTION DIR RESERVED DESCRIPTION Speed R/W Speed at which the Phy is to transmit a packet: 00 => S100 01 => S200 10 => S400 Transaction label The retry code specifies whether this packet is a retry attempt and the retry protocol to be followed by the destination node. The transaction code specifies the packet format and the type of transaction that is to be performed. Priority code (applies only to the backplane Phy) 16-21 22-23 Tlabel Rt Transaction label Retry code R/W R/W 24-27 28-31 Tcode Priority Transaction code Priority field R/W R/W 2-18 2.2.14 Header1 Register at 3Ch 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Destination ID Header1 register must contain the isochronous header or the second quadlet of an asynchronous header if in header insert mode. If not in header insert mode or if in receive mode, this register will be updated with the received header. This register powers up with all bits reset to 0. For multiple isochronous packets (within the same isochronous cycle), this register would contain the isochronous header of the second isochronous packet in the same format as the header0 register, if in header insert mode. This register is write protected such that it cannot be written to unless automatic header insert mode is enabled and DM is in transmit mode (i.e., DMHDR=0 and DMRX=0). BIT NUMBER 0-15 16-31 BIT NAME DestinationID RESERVED FUNCTION Destination ID DIR R/W DESCRIPTION For asynchronous packets this field contains the destination nodes ID. Reserved 2.2.15 Header2 Register at 40h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 HEADER2 Header2 register must contain the isochronous header or the third quadlet of a asynchronous header if in header insert mode. If not in header insert mode or if in receive mode, this register will be updated with the received header. This register powers up with all bits reset to 0. For multiple isochronous packets (within the same isochronous cycle), this register would contain the isochronous header of the third isochronous packet in the same format as the header0 register, if in header insert mode. This register is write protected such that it cannot be written to unless automatic header insert mode is enabled and in transmit mode (i.e., DMHDR=0 and DMRX=0). BIT NUMBER 0-31 BIT NAME Header2 DIR R/W DESCRIPTION Header quadlet for asynchronous or isochronous packet. 2.2.16 Header3 Register at 44h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 HEADER3 Header3 register must contain the isochronous header or the fourth quadlet of an asynchronous header if in header insert mode. If not in header insert mode or if in receive mode, this register will be updated with the received header. This register powers up with all bits reset to 0. For multiple isochronous packets (within the same isochronous cycle), this register would contain the isochronous header of the fourth isochronous packet in the same format as the header0 register, if in header insert mode. This register is write protected such that it cannot be written to unless automatic header insert mode is enabled and DM is in transmit mode (i.e., DMHDR=0 and DMRX=0). BIT NUMBER 0-31 BIT NAME Header3 DIR R/W DESCRIPTION Header quadlet for asynchronous or isochronous packet. 2-19 2.2.17 Trailer Register at 48h 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 LPS_RESET NUMBER OF QUADLETS ACKCODE SPD LPS_OFF The power-up reset value of this register = 0000_0000'h. BIT NUMBER 0-1 2-15 16-18 19-23 BIT NAME RESERVED numofQuadlets RESERVED AckCode Acknowledge Code R/W Number of Quadlets R/W FUNCTION NAME DIR RESERVED Total number of quadlets in the current packet (data payload and header quadlets only) RESERVED This 5-bit field holds the acknowledge code sent by the receiver for the current packet (see Note following the table): Ack Code 00000 00001 00010 00011 00100 00101 00110 00111 - 01100 01101 01110 01111 10000 10001 10010 10011 - 11111 24-25 26-27 RESERVED SPD Speed Code R/W RESERVED The spd field indicates the speed at which the current packet was sent. 00 => 100 Mbit/s, 10 = > 400 Mbits/s, 01 => 200 Mbit/s, 11 is undefined. RESERVED Name Reserved Ack_complete Ack_pending Reserved Ack_busy_X Ack_busy_A Ack_busy_B Reserved Ack_data_error Ack_type_error Reserved No ack received Ack too long Ack too short Reserved These codes are addd by h link layer ed b the li k l and are not part of the 1394-1995 IEEE 1394 1995 specification. DESCRIPTION 28 - 29 RESERVED NOTE: The acknowledge code specified by the IEEE 1394-1995 specification is a 4-bit field. The AckCode field in this register is a 5-bit field. The TSB12LV32 logic core is able to provide (specifiy) three additional ack codes, which are not part of the original specification. The ack codes are 10000, 10001, and 10010. 2-20 BIT NUMBER 30 BIT NAME LPS_RESET FUNCTION NAME LPS Reset DIR R/W DESCRIPTION Link power status reset. This bit is set by software and is reset by hardware. When this bit is set, hardware will deactivate LPS for a fixed period to ensure that the Phy has reset the interface. It will then reactivate LPS. When this bit is cleared by hardware, a PHRST interrupt will also be generated. Link power status off. If set to 1, this bit will turn off the LPS pulsed output to the Phy. This bit can also be turned off from the Phy. Upon detection of the LINKON pulsed input signal, this bit will be turned off allowing LPS to be driven to the Phy which will, in turn, activate SCLK and power up the link. 31 LPS_OFF LPS Off R/W 2.2.18 Asynchronous Retry Register at 4Ch 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ASYNC RETRY COUNT RETRY INTERVAL 2.2.19 Asynchronous Retry Register at 4Ch FUNCTION NAME Retry count The power-up reset value of this register = 0000_0000'h. BIT NUMBER 0-7 BIT NAME ASYNC RETRY COUNT DIR R/W DESCRIPTION Asynchronous retry count, specifies the number of times to automatically retry sending asynchronous packets from the ATF before giving up. After the retry count is exhausted FIFOACK interrupt will be generated and the ATACK field in CFR 30h will be updated to reflect the timeout. Asynchronous retry interval, is the time in increments of isochronous cycles, between asynchronous retries. RESERVED 8-15 16-31 RETRY INTERVAL RESERVED Retry interval R/W 2-21 3 Microcontroller Interface The microcontroller interface allows the local microcontroller/microprocessor to communicate with the internal control and configuration registers (CFR), asynchronous transfer FIFO (ATF) and general receive FIFO (GRF). All microcontroller reads/writes are initiated by the microcontroller. The micro interface supports read transactions from the CFR or GRF, and write transactions to the CFR or ATF. The micro interface can operate in byte (8 bits) or word (16 bits) accesses. Each CFR, with the exception of the cycle timer register at 14h and the Phy access register at 24h, can be addressed on byte or word boundaries. The possible configurations for the interface are shown in Table 3-1. The TSB12LV32 can also be directly connected to the Motorola 68000 and ColdFire line of MC/MP. Table 3-2 defines the mapping of the micro interface pins between the TSB12LV32, the Motorola 68000 and the ColdFire microprocessor. Table 3-1. Microcontroller Interface Modes of Operation TSB12LV32 Mode-CONFIGURATION TERMINALS COLDFIRE 0 0 0 0 1 1 1 1 M8BIT_SIZ0 0 0 1 1 0 0 1 1 MCMODE_SIZ1 0 1 0 1 0 1 0 1 MODE OF OPERATION 16-bit fixed timing mode. 16-bit MCS-MCA handshake mode. 8-bit fixed timing mode. 8-bit MCS-MCA handshake mode ColdFire 4-byte (2-word) burst mode ColdFire 2-byte (1-word) mode ColdFire 1-byte mode (not supported) ColdFire 16-byte (8-word) burst mode Table 3-2. TSB12LV32 MP/MC Interface Terminal Function Matrix TSB12LV32 TERMINAL NAME MA0 - MA6 MD0 - MD15 MCA MCS MWR MCMODE/SIZ1, M8BIT/SIZ0 TEA BCLK USAGE Input I/O Output Input Input Input Output Input Motorola 68000/ColdFire MICROCONTROLLER TERMINAL NAME A[6:0] D[31:16] TAZ TSZ R/WZ SIZ1, SIZ0 TEAZ SCLK / CLK USAGE Output I/O Input Output Output Output Input Input The Byte stacker allows the TSB12LV32 to be easily connected to most processors. The byte stacker consists of a programmable 8-/16-bit data bus and a 7-bit address bus. The TSB12LV32 uses cycle-start and cycle-acknowledge handshake signals to allow the local bus clock and the 1394 clock to be asynchronous to one another. The TSB12LV32 is an interrupt driver to reduce cycling. All bus signal labeling on the TSB12LV32 microcontroller interface use bit #0 to denote the most significant bit (MSB). ColdFire is a trademark of Motorola, Inc. 3-1 3.1 Microcontroller Byte Stack (Write) Operation The microcontroller byte stack (write) protocol is shown in Figure 3-1. TSB12LV32 Write No Yes Yes No M8BIT/SIZ0 = 1 Microcontroller Writes MSByte (Byte 0) to TSB12LV32 Yes No No Microcontroller Writes MSDoublet (Doublet0) to TSB12LV32 Yes Microcontroller Writes Byte 1 to TSB12LV32 Yes No No Microcontroller Writes LSDoublet (Doublet1) to TSB12LV32 Yes Microcontroller Writes Byte 2 to TSB12LV32 Yes No TSB12LV32 Rejects Quadlet Write and Issues a MCERROR Interrupt Microcontroller Writes Byte 3 to TSB12LV32 Yes No TSB12LV32 Accepts Quadlet Write Figure 3-1. Microcontroller Byte Stack Operation (Write) 3-2 3.2 Microcontroller Byte Unstack (Read) The microcontroller byte unstack (read) protocol is shown in Figure 3-2. TSB12LV32 Read No Yes Microcontroller Reads Same Quadlet As Before Yes No Microcontroller Reads Same Byte/Doublet As Before Yes No TSB12LV32 Provides Updated Byte/Doublet Data TSB12LV32 Provides Updated Byte/Doublet Data TSB12LV32 Provides Held Byte/Doublet Data Figure 3-2. Microcontroller Byte Unstack Operation (Read) 3-3 3.3 Microcontroller Interface Read/Write Timing The micro interface can be configured to operate in one of the following modes: handshake, fixed-timing, or ColdFire mode. Burst transfers are only supported in the latter two modes. 3.3.1 Microcontroller Handshake Mode Byte handshake read and word handshake read are shown in Figure 3-3 and Figure 3-4, respectively. The MCS, MCA handshake timing sequence for a read transaction can be summarized as follows: 1. The host takes MCS low to signal the start of access. When the rising edge of BCLK samples MCS low and MWR high, the MD[0:15] lines are enabled and driven with the read value. For an 8-bit data bus, MD[0:7] lines are not used. Following the next rising edge of BCLK, the TSB12LV32 takes MCA low to signal that the requested operation is complete. This is ensured to take place after two BCLK cycles. MCA remains low with the MD lines containing valid read data until the micro interface releases MCS (high state) The host takes MCS high to signal the end of the process. The TSB12LV32 takes MCA high to acknowledge the end of the access. This 3-states the MD lines. 2. 3. 4. Another read or write transaction can begin after the next rising edge of BCLK. Note that data size is determined by the MCMODE/SIZ1 and M8BIT/SIZ0 signals. The ColdFire signal is only asserted high when the micro interface is operating in ColdFire mode. BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MCADR[0:6] A1 A2 MD[0:7] MD[8:15] D1 D2 Figure 3-3. Byte Handshake Read Figure 3-4 shows a word handshake read transaction. In this case, all 16 bits of the MD lines are used. Note that MD[0] contains the MSB and MD[15] contains the LSB. As in the byte read case, another read or write transaction can begin after the next rising edge of BCLK. 3-4 BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] D1 D3 MD[8:15] D2 D4 Figure 3-4. Word Handshake Read Byte handshake write and word handshake write are shown in Figure 3-5 and Figure 3-6. In this case, the micro interface asserts MCA low immediately after MCS is sampled low. The micro interface keeps MCA low until it samples MCS high. For 8-bit accesses, the MD[0:7] lines are not used. If a transfer error condition occurs, TEA will be asserted low for one BCLK cycle. An error condition can occur if the MCMODE/SIZ1 or M8BIT/SIZ0 line changes state during the access cycle. 3-5 BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] MD[8:15] D1 D2 Figure 3-5. Byte Handshake Write BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] D1 D3 MD[8:15] D2 D4 Figure 3-6. Word Handshake Write 3-6 3.3.2 Microcontroller Fixed-Timing Mode Byte and word fixed-timing reads shown in Figure 3-7 and Figure 3-8. Fixed-timing mode supports burst transfers. If MCS is asserted low for more than one BCLK cycle, burst mode is enabled. The fixed-timing burst mode does not have a limit on the maximum burst size allowed. The timing sequence in the fixed-timing a read transaction can be summarized as follows: 1. The host pulses MCS low to signal the start of access. Pulsing MCS low for more than once clock cycle will enable burst mode. The number of BCLK cycles during which MCS is asserted low determines the burst size. When the rising edge of BCLK samples MCS low and MWR high, the register value or GRF data pointed to by MA is latched onto the MD lines. The MD lines will latch on every rising edge of BCLK if MCS is asserted low. After 2 BCLK cycles, the TSB12LV32 pulses MCA low for one clock cycle to signal the completion of the requested operation. If MCS is pulsed low for n BCLK cycles, MCA will also be pulsed low for n cycles. Note that MA needs only contain valid data during the first cycle in which MCS is low. Except for the first one, every data transfer takes only one BCLK cycle. If a read transaction is accessing the CFR, it may not cross any register boundary. 2. 3. Another read or write transaction can begin after the next rising edge of BCLK. Note that data size is determined by the MCMODE/SIZ1 and M8BIT/SIZ0 signals. The ColdFire signal is only asserted high when the micro interface is operating in ColdFire mode. BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] MD[8:15] D1 D2 D3 D4 D5 Figure 3-7. Byte Fixed-Timing Read 3-7 BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] D1 D3 D5 D7 D9 MD[8:15] D2 D4 D6 D8 D10 Figure 3-8. Word Fixed-Timing Read Byte fixed timing write and word fixed timing write are shown in Figure 3-9 and Figure 3-10. The first data transfer takes one extra wait cycle. All subsequent data transfers take only one BCLK cycle. For an 8-bit data bus, MD[0:7] is not used (don't care) and is driven with zeros. If the write transaction is accessing the CFR register, it may not cross any register boundary. First write data for each ATF quadlet must start at byte0. Write accesses to the ATF must be quadlet aligned. The micro interface will wait for all bytes of each quadlet to be available before creating a write request to the ATF. If a transfer error condition occurs, TEA will be asserted low for one BCLK cycle. An error condition can occur if the MCMODE/SIZ1 or M8BIT/SIZ0 lines transition during the access cycle. 3-8 BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MD[0:7] MD[8:15] D2 D2 D3 D4 D5 Figure 3-9. Byte Fixed-Timing Write BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] A1 A2 MCD[0:7] D1 D3 D5 D7 D9 MD[8:15] D2 D4 D6 D8 D10 Figure 3-10. Word Fixed-Timing Write 3-9 3.3.2.1 GRF READ The timing requirements when performing a GRF read access in fixed-timing mode are different from other access modes. In fixed-timing mode, the GRF must be accessed only on a quadlet boundary. In other words, only quadlet fetches are legal. If the microinterface is configured for a byte access, this means that MCSZ must be asserted low for 4 BCLK cycles, as shown in Figure 3-11. If configured for word access, then MCSZ must only be asserted for 2 BCLK cycles, as shown in Figure 3-12. BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] XX GRF ADDRESS XX MD[0:7] ZZ XX ZZ MD[8:15] ZZ D1 D2 D3 D4 ZZ Figure 3-11. GRF Read Access (Byte Fixed-Timing Mode) 3-10 BCLK COLDFIRE M8BIT/SIZ0 MCMODE/SIZ1 MWR MCS MCA MA[0:6] XX GRF ADDRESS XX MD[0:7] ZZ D1 D3 ZZ MD[8:15] ZZ D2 D4 ZZ Figure 3-12. GRF Read Access (Word Fixed-Timing Mode) 3-11 3.3.3 Microcontroller ColdFire Mode The TSB12LV32 supports a glueless interface to the ColdFire family of microcontrollers. To enable this mode, the ColdFire pin must be asserted and kept high for the entire access cycle. The timing diagram for a ColdFire read operation is shown in Figure 3-13. The timing sequence for a ColdFire read access can be summarized as follows: 1. 2. The ColdFire pulses MCS low for one BCLK cycle to signal the start of access.MCS must only be asserted for one clock cycle. When the rising edge of BCLK samples MCS low and MWR high, MD lines are enabled, but do not yet contain valid data. The MA lines should contain the address information at this point. MA is only required to be available for one BCLK cycle. The data transfer size is determined by the state of the MCMODE/SIZ1 and M8BIT/SIZ0 lines. The TSB12LV32 pulses MCA low for n clock cycles to signal the requested operation is complete. The number n depends on the data transfer size specified by the MCMODE/SIZ1 and M8BIT/SIZ0 lines. The CFR register value or GRF memory data pointed to by the MA lines is latched onto the MD lines. MCA will pulse for one clock cycle on every word (2-Bytes) transfer. 3. The microinterface does burst transfers if the MCMODE/SIZ1 and M8BIT/SIZ0 lines indicate more than 2-bytes (1 word) of data. The TSB12LV32 does not support 1-byte transfers in the ColdFire mode. If a transfer error condition occurs, TEA will be asserted low for one BCLK cycle. An error condition can occur if the MCMODE/SIZ1 and M8BIT/SIZ0 lines specify a transfer size of 1-byte or if their state changes during the access cycle. Note that all 16-bits of the MD lines are always used in this mode. BCLK COLDFIRE MCMODE/SIZ1 M8BIT/SIZ0 MWR MCS MCA MA[0:6] A1 A2 A3 MD[0:7] D1 D3 D5 MD[8:15] D2 D4 D6 Figure 3-13. ColdFire Read The ColdFire write transaction is shown in Figure 3-14. Unlike the handshake and fixed-timing write modes, the ColdFire write operation requires the data on the MD lines be available one BCLK cycle after the address on the MA lines is sampled. Violating this timing requirement may result in a transfer error, causing TEA to be asserted low for one BCLK cycle. 3-12 BCLK COLDFIRE MCMODE/SIZ1 M8BIT/SIZ0 MWR MCS MCA MA[0:6] A1 A2 A3 MD[0:7] D1 D3 D5 MD[8:15] D2 D4 D6 TEA Figure 3-14. ColdFire Write 3.3.4 td0 td1 td2 tsu0 tsu1 tsu2 tsu3 tsu4 tsu5 th0 th1 th2 th3 th4 Microcontroller Critical TIming PARAMETER TERMINAL NAME MCA Delay time (BCLK to Q) TEA MD[0:15] MWR MCS MA[0:6] Setup time to BCLK M8BIT/SIZ0 MCMODE/SIZ1 MD[0:15] MWR MCS Hold time from BCLK MA[0:6] M8BIT/SIZ0 MCMODE/SIZ1 ACCESS TYPE Read/Write Read/Write Read Read/Write Read/Write Read/Write Read/Write Read/Write Write Read/Write Read/Write Read/Write Read/Write Read/Write Write MIN 3.75 3.75 2.5 4.5 6.5 6.5 5 3.5 3 1.75 1.5 2 1.5 1.75 1.5 ns ns MAX 9.5 9.5 10.5 ns UNIT th5 MD[0:15] All parameters are referenced to the rising edge of BCLK. 3-13 S4 S3 S2 S1 S0 BCLK MWR MCS D0 MCA MA[0:6] XX D2 MD[0:15] XXXX D1 TEA M8BIT/ SIZ0 MCMODE/ SIZ1 DATA XXXX DATA XXXX ADDRESS XX ADDRESS XX H1 H0 H4 H3 H2 S5 H5 3.3.5 Endian Swapping The term endianness refers to the way data is referenced and stored in a processor's memory. For example, consider a 32-bit processor; any 32-word consists of four bytes which may be stored in memory in one of two ways. Of the four bytes, either byte 3 will be considered the most significant byte and byte 0 the least significant byte, or vice versa (see Figures 3-15 and 3-16). A little endian type memory considers byte 0 the least significant byte, whereas a big endian type memory considers byte 3 to be the least significant byte. Byte #0 (Most Significant Byte) Byte #1 Byte #2 Byte #3 (Least Significant Byte) Figure 3-15. Big Endian Format Byte #3 (Most Significant Byte) Byte #2 Byte #1 Byte #0 (Least Significant Byte) Figure 3-16. Little Endian Format The TSB12LV32 configuration register space (CFR) and FIFO memory, both of which are 32-bits wide, use a big endian architecture. The TSB12LV32 uses the same endianness as the internal P1394 link core. This means that the most significant byte is the left-most byte (byte 0) and the least significant byte is the right most byte (byte 3). 3.3.5.1 Data and Address Invariance for Little Endian Processors For little-endian processors, there are two modes of byte swapping, address invariant and data invariant. Address invariance preserves byte ordering between the internal system (GP2Lynx registers and FIFO) and external system (microcontroller/processor). Data invariance preserves the bit significance of the data, but changes the byte significance between the internal and external systems. The MDINV pin controls how the write/read data is swapped at the data bus (i.e., determines how the received bytes from the microcontroller are mapped into the TSB12LV32 internal registers and memory space). Note that when the COLDFIRE pin is high, the MDINV pin has no affect and data is always interpreted in as big endian. Refer to Literature 3-14 Number SLLA021.pdf ENDIANNESS AND THE TSB12LV41 (MPEG2LYNX) MICROPROCESSOR INTERFACE for a detailed description of endianness. The pin settings for all the swapping operation are shown in Table 3-3. Note that in performing the byte swapping operation in the little-endian mode, only the two least significant bits of the 32-bit address inside are involved. This is because there is a total of four bytes associated with the swapping operation. Table 3-3. Endian Swapping Operation LENDIAN 0 1 M8BIT/SIZ0 X 1 (8-bits wide) MDINV X 1 DESCRIPTION Big endian mode, no manipulation on byte address and data bytes Little endian data invariance mode, swap the low order 2 bit address: External low order 2-bit address Internal low order 2-bit address Byte Address 00 Byte Address 11 Byte Address 01 Byte Address 10 Byte Address 00 Byte Address 11 Byte Address 00 Byte Address 11 Little endian data invariance mode, swap the low order 2 bit address: External low order 2-bit address Internal low order 2-bit address Word Address 00 Word Address 10 Word Address 10 Word Address 00 16-bit little endian address invariance mode, swap data between MD[0:7] and MD[8:15]. 8-bit little endian address invariance mode, no manipulation on byte address and data bytes. 1 01 (16-bits wide) 1 1 1 1 1 0 0 Since the TSB12LV32's microprocessor interface is either 8 bits or 16 bits wide, but the internal configuration registers are 32 bits wide, a byte stacking (for writes) and a byte unstacking (for reads) operation must be performed on the data bus. For little endian processors, the TSB12LV32 can perform the swapping of bytes on the data bus required to allow both the processor and the TSB12LV42 to interpret the data the same. There are two methods of swapping the data bytes, address invariant and data invariant. Both of these methods are described below. NOTE: For the host processor to work correctly with the TSB12LV32, users must correctly connect the address and data busses of their microprocessor to the TSB12LV32's microprocessor port. Users must connect the MSB (most significant bit) of their address/data bus to the address/data MSB of the TSB12LV32. This must be done regardless of bit number labeling or which type of endianness their microprocessor uses. 3.3.5.2 Data Invariant System Design Figure 3-17 shows a little endian data invariant system design example. In this system, the actual value of the data as it was stored in the processor's memory is preserved. Data invariant designs do not preserve the addresses when mapping between endian domains. If the data represents an integer, it is interpreted the same by both systems. If the data represents a string, an array, or some other type of byte indexed structure, it is interpreted differently by both systems. 3-15 Byte 3 (MSByte) Little Endian Processor Memory aa Byte 2 Byte 1 Byte 0 (LSByte) dd bb cc TSB12LV32 CFR/Memory dd (MSByte) Byte 0 cc bb aa (LSByte) Byte 3 Byte 1 Byte 2 Figure 3-17. Little-Endian Data Invariance Illustration Chart Byte 3 (MSByte) Little Endian Processor Memory aa Byte 2 Byte 1 Byte 0 (LSByte) dd bb cc TSB12LV32 CFR/Memory dd (MSByte) Byte 0 cc bb aa (LSByte) Byte 3 Byte 1 Byte 2 Figure 3-18. Little-Endian Address Invariance Illustration Chart 3.3.5.3 Address Invariant System Design Figure 3-18 shows a little-endian address invariant system design example. In this case, the byte ordering between both systems is preserved (i.e., byte address is preserved). For example, byte 3 in the little endian processor memory is also byte 3 in the TSB12LV32 CFR space. As Figure 3-18 shows, the byte ordering is automatically maintained by the TSB12LV32 when in the address-invariance mode by swapping the order in which the incoming bytes on the microprocessor are written to the CFRs. 3-16 4 Link Core This section describes the link core components and operations. Figure 4-1 shows the link core components. Transmitter Cycle Timer CRC Cycle Monitor Receiver Figure 4-1. Link Core Components 4.1 Physical Interface The physical (Phy) interface provides Phy-level services to the transmitter and receiver. This includes gaining access to the serial bus, sending packets, receiving packets, and sending and receiving acknowledge packets. The Phy interface module also interfaces to the Phy chip and implements Texas Instruments patent-pending bus-holder galvanic isolation. 4.2 Transmitter The transmitter retrieves data from either the asynchronous transmit FIFO (ATF) or the data mover (DM) port and creates correctly formatted serial-bus packets to be transmitted through the Phy interface. When data is present at the ATF interface to the transmitter, the TSB12LV32 Phy interface arbitrates for the serial bus and sends a packet. When data is present at the DM Port, the TSB12LV32 arbitrates for the serial bus during the next isochronous cycle. The transmitter autonomously sends the cycle-start packets when the chip is a cycle master. 4.3 Receiver The receiver takes incoming data from the Phy interface and determines if the incoming data is addressed to this node. When the incoming packet is addressed to this node, the CRC of the packet is checked. If the header CRC is good, the header is confirmed in the general-receive FIFO (GRF). For block and isochronous packets, the remainder of the packet is confirmed one quadlet at a time. The receiver places a status quadlet in the GRF after the last quadlet of the packet is confirmed in the GRF. The status quadlet contains the error code for the packet. In the case of asynchronous packets, the error code is the acknowledge code that is sent (returned) for that packet. For isochronous and broadcast packets that do not need acknowledge packets, the error code is the acknowledge code that would have been sent. This acknowledge code tells the transaction layer whether or not the data CRC is good or bad. If the header CRC is bad, the header is flushed and the rest of the packet is ignored. When a cycle-start packet is received, it is detected and the cycle-start packet data is sent to the cycle timer. Cycle-start packets are not placed in the GRF like other quadlet packets. 4-1 Physical Interface 4.4 Cycle Timer The cycle timer is only used by nodes that support isochronous data transfer. The cycle timer is a 32-bit cycle-timer register. Each node with isochronous data-transfer capability has a cycle-timer register as defined by the IEEE 1394-1995 specification. In the TSB12LV32, the cycle-timer register is implemented in the cycle timer located in the IEEE-1212 initial register space at location 200h and can also be accessed through the local bus at TSB12LV32 CFR address 14h. The low-order 12 bits of the timer are a modulo 3072 counter, which increments once every 24.576-MHz clock periods (or 40.69 ns). The next 13 higher-order bits are a count of 8,000-Hz (or 125-s) cycles, and the highest 7 bits count seconds. The cycle timer contains the cycle-timer register. The cycle-timer register consists of three fields: cycle offset, cycle count, and seconds count. The cycle timer has two possible sources. First, when the cycle source (CYSRC) bit in the configuration register (bit 21 at 08h) is set, then the CYCLEIN input causes the cycle count field to increment for each positive transition of the CYCLEIN input (8 kHz) and the cycle offset resets to all zeros. CYCLEIN should only be the source when the node is the cycle master. The timer can also be disabled using the cycle-timer-enable bit (CYTEN) in the control register. The second cycle-source option is when the CYSRC bit is cleared. In this state, the cycle-offset field of the cycle-timer register is incremented by the internal 24.576-MHz clock. The cycle timer is updated by the reception of the cycle-start packet for the non-cycle master nodes. The cycle-offset field in the cycle-start packet is used by the cycle-master node to keep all nodes in phase and running with a nominal isochronous cycle of 125 s. The cycle-start bit is set when the cycle-start packet is sent from the cycle master node or received by a noncycle master node. 4.5 Cycle Monitor The cycle monitor is only used by nodes that support isochronous data transfer. The cycle monitor observes chip activity and handles scheduling of isochronous activity. When a cycle-start message is received or sent, the cycle monitor sets the cycle-started interrupt bit. It also detects missing cycle-start packets and sets the cycle-lost interrupt bit when this occurs. When the isochronous cycle is complete, the cycle monitor sets the cycle-done-interrupt bit. The cycle monitor instructs the transmitter to send a cycle-start message when the cyclemaster bit (CYMAS) is set in the control register. 4.6 Cyclic Redundancy Check (CRC) The CRC module generates a 32-bit CRC for error detection. This is done for both the header and the data. The CRC module generates the header and data CRC for transmitting packets and checks the header and data CRC for received packets (see the IEEE-1394-1995 standard for details on the generation of the CRC). 4.7 Packet Routing Control Logic Asynchronous and Isochronous receive packets will be routed to the DM port or the GRF via the receiver routing control logic. Any asynchronous packet addressed in the range of 0 to 0000_FFFF_FFFF and is of the write request type will be routed to the DM port according to Table 4-1. When bit IRCVALL (at 18h) is set, all isochronous data will be routed according to Table 4-1. Note that self-ID packets and Phy packets are always received by the GRF regardless of the routing control settings. 4-2 Table 4-1. Receiver Routing AR0 0 AR1 0 DMASYNC X 1 0 1 1 X 0 DMRX 0 1 1 0 1 DATA MOVER (DM) Receives no data; Power-on default Receives Read Response Packets with a tlabel of 11XXXX Receives asynchronous data only Receives no data Receives isochronous/ asynchronous streaming data only Receives no data Receive no data Receives addressed write request asynchronous packets in the address range of 0000_0000_0000 0000_FFFF_FFFFh GENERAL-RECEIVE FIFO (GRF) Receives all data (asynchronous and isochronous); power-on default Receives all other asynchronous packets and isochronous packets Receives isochronous/asynchronous streaming data only Receives all data Receives asynchronous data 1 0 X 0 1 0 1 1 Receives all data Receives all data Receives addressed asynchronous packets in the address range of 0001_0000_0000-FFFF_FFFF_FFFFh. Also receives any asynchronous packets not going to the DM port regardless of the address. Receives isochronous packets too. Receives all data Receives no data 1 1 X X 0 1 Receives no data Receive all data (asynchronous and isochronous) 4-3 5 Data Mover Port Interface The data mover (DM) port in the TSB12LV32 is the physical medium by which autonomous streams of different types are piped to/from an application that uses the TSB12LV32. The DM port is meant to handle an external memory interface of large data packets. The DM port can support three types of packets: * * * Asynchronous Isochronous Asynchronous Streaming (1394a supported format) The port can be configured to either transmit or receive data packets at one time (half duplex). A typical system diagram is shown in Figure 5-1: Application Stream Process (External Memory Interface) Data Mover I/F Phy/Link I/F TSB12LV32 Phy Processor/Controller (ColdFire) Microcontroller Interface Figure 5-1. A Typical System Diagram The DM port will perform all operations synchronously, utilizing a 24.576 MHz output clock called DMCLK. DMCLK is essentially SCLK/2. There is no asynchronous logic within the DM block. All data transfers are synchronized to the DMCLK output. The DM operates by setting the DM control register at 04h and the control register at 08h of the CFR. The DM interfaces internally with the configuration register (CFR) block and the link core (Link) block and interfaces externally with the data mover external interface. The advantages of the DM port can be summarized as follows: * * * Transmits or receives large blocks of data at speeds up to 400 Mbits/s. Allows for a large external FIFO specific to an individual application. Handles asynchronous, isochronous, or asynchronous streaming packets. 5-1 No Isochronous DM Idle (DMDONE is high) DMEN is 1, DMASYNC is 0 DMREADY is High? Yes No Isochronous DM Go (DMDONE is low) New Isochronous Cycle Started? Yes Isochronous Arbitrate/Xmit (DMDONE is low) Arbitrate for Isochronous Transmit and Send One Isochronous Packet Yes No All Channels Done (DMDONE is low) End of All Channels? Yes No Data Block Done (DMDONE is low) End of All Packets For This Data Block? Yes Handshake Mode? Yes Handshake (DMDONE is high) DMREADY is Low? No Yes No NOTE A: DMEN and DMASYNC are configuration register bits, DMREADY is an input terminal, and DMDONE is an output terminal. Figure 5-2. Isochronous DM Flow Control (TSB12LV32 Transmit) 5-2 MSB LSB Data Mover Data DMD0 - DMD15 Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 Bit 9 Bit 10 Bit 11 Bit 12 Bit 13 Bit 14 Bit 15 1394 Packet Data Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 Bit 9 Bit 10 Bit 11 Bit 12 Bit 13 Bit 14 Bit 15 . . .Bit 31 Figure 5-3. Transmit Data Path The DM isochronous transmit reads data from the DM interface (DMD[0-15] lines) and passes it to the 1394 isochronous transmit interface in accordance with Figure 5-2. The data path is shown in Figure 5-3. The asynchronous header registers will contain the latest extracted header from the asynchronous stream when the header is supplied via the DM port. For automatic header insertion, the datalength field in the header register will be automatically updated by the payload size of the previous asynchronous transmit packet. This option can be turned off by setting the appropriate bits in the DM control registers. The DM asynchronous transmit reads data from the DM interface (DMD[0:15] lines) and passes it to the 1394 asynchronous interface in accordance with Figure 5-4 Asynchronous DM Idle (DMDONE is high) DMEN is 1, DMASYNC is 0 DMREADY is High? Yes Asynchronous Arbitrate/Xmit (DMDONE is low) Arbitrate for Asynchronous Transmit and Send Asynchronous Packet Yes Wait for Acknowledge Ack Complete received? Yes No Data Block Done (DMDONE is low) End of All Packets For This Data Block? Yes No No DM Disabled Re-enable via Software NOTE: DMEN and DMASYNC are configuration register bits, DMREADY is an input terminal, and DMDONE is an output terminal. Figure 5-4. Asychronous DM Flow Control (TSB12LV32 Transmit) The DM Interfaces to the configuration register (CFR), the link core (Link), and the external data mover interface (DMI). 5-3 5.1 Data Mover Data Flow Diagram The data mover has eight modes of operation. There are four modes for transmit and four modes for receive. Definitions * Data mover port configured to operate in transmit mode means that the packet data is received through the data mover port and forwarded (unbuffered) to the link core transmit logic to be sent to the physical layer device (Phy), which will, in turn, transmit the data onto the 1394 bus. Data mover port configured to operate in receive mode means that the packet data is received by the link core receive logic from the 1394 bus through the Phy. The data is then routed by the link core to the data mover port without any internal buffering. * 5.1.1 Isochronous Receive In all the isochronous receive modes, the packet header information is always loaded into the header registers. The packet header quadlet is loaded into the Header0 register at 38h and the packet trailer quadlet is loaded into the trailer register at 48h. 5.1.1.1 Isochronous Packet Receive Without Header and Trailer Isochronous packet is received through the receiver logic of the link core The packet header is stripped off from the packet and loaded into the header0 register at 38h. Packet data (payload only) is routed directly to the DM port without any buffering. Trailer quadlet is loaded into the trailer register at 48h CFR REGISTER Step 1: Step 2: Step 3: Step 4: Header0 Register at 38h Step 2 Trailer Register at 48h LINK CORE Transmitter Data Mover Port Step 4 Receiver Step 3 (Packet Data) Step 1 Packet received from 1394 bus through the Phy Figure 5-5. Isochronous Receive Without Header and Trailer 5.1.1.2 Isochronous Packet Receive With Header and Trailer Isochronous packet is received through the receiver block of the link core. The header quadlet is both loaded into the header0 register at 38h and routed to the DM port without any buffering. Packet data (payload only) is sent directly through the DM port only. Trailer quadlet is loaded into the trailer register at 48h. It is also forwarded to the DM port. Step 1: Step 2: Step 3: Step 4: 5-4 CFR REGISTER Header0 Register at 38h Step 2 LINK CORE Step 4 Trailer Register at 48h Transmitter Data Mover Port Step 4 (trailer quadlet) Step 3 (packet data) Step 2 (header quadlet) Step 1 Receiver Packet received from 1394 bus through the Phy Figure 5-6. Isochronous Receive With Header and Trailer 5.1.2 * * Isochronous Transmit Isochronous packet transmit with automatic header insertion. Isochronous packet transmit without automatic header insertion. There are two ways (modes of operation) to transmit isochronous data through the data mover: The difference between the two modes lies in the mechanism in which the header information is inserted into the data stream. However, in both cases the header information is always loaded into the link core transmitter from the header register. 5.1.2.1 Isochronous Packet Transmit With Automatic Header Insertion In this mode, the header information is first loaded into the header0 register through the microcontroller interface. The header will subsequently be automatically inserted into the data once the data mover starts streaming it through to the link core transmitter logic. The following steps further illustrate the process: CFR REGISTER LINK CORE Step 1 Write Header Information Microcontroller Interface Step 1 Header loaded Header0 Register at 38h Step 2 Step 4 Transmitter Packet sent to 1394 bus through the Phy Step 3 Step 3 (Packet Data) Data Mover Port (packet data) Receiver Figure 5-7. Isochronous Transmit With Auto Header Insertion 5-5 Step 1: Step 2: Step 3: Step 4: Isochronous header quadlet is loaded into header0 register at 38h through a write operation from the microcontroller interface. Header quadlet is forwarded to the transmitter of the link core. Packet data (payload only) is transmitted through the data mover directly to the transmitter of the link core. Isochronous packet is sent to the 1394 bus through the Phy. NOTE: The data coming through the data mover port is typically supplied by an external fast memory block (i.e., FIFO, DRAM). This external memory logic may begin transmitting data through to the data mover port exactly one DMCLK cycle after the DMPRE output pin on the GP2Lynx is asserted high. 5.1.2.2 Isochronous Packet Transmit Without Automatic Header Insertion In this mode, the packet header and data information is loaded through the data mover port. This mode is sometimes called isochronous packet transmit with manual header insertion. This is because the header quadlet is not preloaded into the header0 register via the microcontroller interface. Instead, it is inserted manually into the data stream at the same time as the rest of the packet. The following steps further illustrate the process: Step 1: Step 2: Step 3: Step 4: Isochronous header information (only one header quadlet in this case) is fetched into the header0 register at 38h through the data mover port. Header quadlet is forwarded to the transmitter of the link core. Packet data (payload only) is transmitted through the data mover directly to the transmitter of the link core. Isochronous packet is sent to the 1394 bus through the Phy. CFR REGISTER Step 1 (header fetched) Header0 Register at 38h Step 2 LINK CORE Step 4 Transmitter Step 3 (Packet Data) Step 1 (header supplied) Step 3 (packet data) Packet sent to 1394 bus through the Phy Receiver Data Mover Port Figure 5-8. Isochronous Transmit Without Auto Header Insertion 5-6 5.1.3 Asynchronous Receive In all the asynchronous receive modes, the packet header information is always loaded into the header registers. In quadlet receive mode, the first three header quadlets are loaded into the header0at 38h, header1at 3Ch, and header2at 40h registers, respectively. The trailer quadlet is loaded into the trailer register at 48h. In block receive mode, the only additional step performed is loading the fourth header quadlet received into the header3 register at 44h. 5.1.3.1 Asynchronous Packet Receive Without Headers and Trailer Asynchronous packet is received through the receiver logic of the link core The packet headers are stripped off from the packet and loaded into the header registers: a) b) If in quadlet receive mode, the three header quadlets are loaded into the header0- header2 registers. If in block receive mode, the four header quadlets are loaded into the header0- header3 registers. Step 1: Step 2: Step 3: Step 4: Packet data (payload only) is routed directly to the DM port without any buffering. Trailer quadlet is loaded into the trailer register at 48h CFR REGISTER Quadlet#0 Quadlet#1 Quadlet#2 Quadlet#3 Step 2 Trailer Register at 48h Step 4 LINK CORE Header0 Register at 38h Loaded only in Block Receive Header1 Register at 3Ch Header2 Register at 40h Header3 Register at 42h Transmitter Step 1 Data Mover Port Step 3 (packet data) Receiver Packet received from 1394 bus through the Phy Figure 5-9. Asynchronous Receive Without Headers and Trailer 5-7 5.1.3.2 Asynchronous Packet Receive With Headers and Trailer Asynchronous packet is received through the receiver logic of the link core. The header quadlets are loaded into their respective header registers AND routed to the DM port without any buffering. Packet data is routed directly to the DM port (no buffering performed). Trailer quadlet is loaded into the trailer register at 48h. CFR REGISTER Step 1: Step 2: Step 3: Step 4: Header0 Register at 38h Loaded only in Block Receive Header1 Register at 3Ch Header2 Register at 40h Header3 Register at 42h Quadlet#0 Quadlet#1 Quadlet#2 Quadlet#3 Trailer Register at 48h LINK CORE Transmitter Data Mover Port Step 4 (trailer quadlet) Step 3 (packet data) Step 2 (header quadlet) Step 1 Receiver Packet received from 1394 bus through the Phy Figure 5-10. Asynchronous Receive With Headers and Trailer 5.1.4 * * Asynchronous Transmit Asynchronous packet transmit with automatic header insertion. Asynchronous packet transmit without automatic header insertion. There are two ways (modes of operation) to transmit asynchronous data through the data mover: The difference between the two modes lies in the mechanism in which the header information is inserted into the data stream. However, in both cases, the header information is always loaded into the link core transmitter from the header registers. 5-8 5.1.4.1 Asynchronous Packet Transmit With Automatic Header Insertion In this mode, the header information is first loaded into the header0-header3 registers through the microcontroller interface. The headers will subsequently be automatically inserted into the data once the data mover starts streaming it through to the link core transmitter logic. The following steps further illustrate the process: Step 1: Asynchronous header quadlets (3 quadlets in quadlet receive mode and 4 quadlets in block receive mode) are loaded into header0-header3 registers through a write operation from the microcontroller interface. Loading one header requires a single write operation. Header quadlets are forwarded to the transmitter of the link core. Packet data (payload only) is transmitted through the data mover directly to the transmitter of the link core. Asynchronous packet is sent to the 1394 bus through the Phy. Step 2: Step 3: Step 4: NOTE: The data coming through the data mover port is typically supplied by an external fast memory block (i.e., FIFO, DRAM). This external memory logic may begin transmitting data through to the data mover port exactly one DMCLK cycle after the DMPRE output pin on the GP2Lynx is asserted high. CFR REGISTER Header0 Register at 38h MicroStep 1 Step 1 controller Headers Write Interface loaded Header Quadlets Header1 Register at 3Ch Header2 Register at 40h Header3 Register at 42h Quadlet#0 Quadlet#1 Quadlet#2 Quadlet#3 Step 2 Loaded only in Block Receive LINK CORE Step 4 Transmitter Step 3 Packet sent to 1394 bus through the Phy Step 3 (packet data) Data Mover Port Receiver Figure 5-11. Asynchronous Transmit With Auto Header Insertion 5-9 5.1.4.2 Asynchronous Packet Transmit Without Automatic Header Insertion In this mode, the packet headers and data information are loaded through the data mover port. This mode is sometimes called asynchronous packet transmit with manual header insertion. This is because the header quadlets are not preloaded into the header registers via the microcontroller interface. Instead, they are inserted manually into the data stream at the same time as the rest of the packet. The following steps further illustrate the process: Step 1: Step 2: Step 3: Step 4: Asynchronous header quadlets (3 quadlets in quadlet receive mode and 4 quadlets in block receive mode) are fetched into the header registers through the data mover port. The header quadlets are then forwarded to the transmitter of the link core. Packet data (payload only) is transmitted through the data mover directly to the transmitter of the link core. Asynchronous packet is sent to the 1394 bus through the Phy. CFR REGISTER Header0 Register at 38h Header1 Register at 3Ch Step 1 (headers fetched) Header2 Register at 40h Header3 Register at 42h Quadlet#0 Quadlet#1 Quadlet#2 Quadlet#3 LINK CORE Step 2 Step 4 Transmitter Step 3 (package data) Step 1 (Headers supplied) Step 3 (packet data) Data Mover Port Receiver Packet sent to 1394 bus through the Phy Figure 5-12. Asynchronous Transmit Without Auto Header Insertion 5.2 Data Mover Modes of Operation The data mover (DM) port in the GP2Lynx is meant to handle an external memory interface of large data packets. The port can be configured to either transmit or receive data packets. The data can be either asynchronous or isochronous packets. All traffic through the data mover is synchronous to the rising edge of DMCLK. DMCLK is an output signal at 25 MHz. The data mover operates by setting the DM control registers. If the DM is configured for transmit mode, it waits for DMREADY to be asserted before it can drive DMDONE low and fetch the entire block of data one packet at a time. Upon transmitting the last packet in the block, the DM will drive DMDONE high for a minimum of one DMCLK cycle (~ 40 ns). The next DMCLK cycle in which DMDONE finds DMREADY high, the process will be restarted. The data mover has eight modes of operation which are specified by the DMASYNC, DMHDR, and DMRX bits in the DM control register at 04h. Table 5-1 shows all the DM modes of operation. 5-10 Table 5-1. Modes of Operation DMASYNC 0 0 0 0 1 1 1 1 DMHDR 0 0 1 1 0 0 1 1 DMRX 0 1 0 1 0 1 0 1 MODE OF OPERATION Isochronous packet transmit with auto header insertion Isochronous packet receive without header and trailer Isochronous packet transmit without header insertion Isochronous packet receive with header and trailer Asynchronous packet transmit with auto header insertion Asynchronous packet receive without headers and trailer Asynchronous packet transmit without header insertion Asynchronous packet receive with headers and trailer 5.2.1 Isochronous Transmit With Automatic Header Insertion Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: DMDONE will be asserted low (deactivated) at the next DMCLK cycle. The data mover will take the header that has been loaded into the header0 register at 38h and request the link core to transmit the data onto the 1394 bus. The link core will fetch the header from the header0 register. DMPRE will pulse for one DMCLK cycle before the first data quadlet is sent. The data mover will then begin to fetch the data payload by asserting DMRW high. When the link core has fetched the last data quadlet, the data mover checks if the number of channels specified by the control registers have been sent. If all channels have been sent the data mover waits for a subaction gap to occur before asserting DMDONE high to indicate the end of the cycle. Otherwise the data mover will provide the header in the next header register and then begin fetching the data payload until all channels are complete. Upon receiving a high on DMREADY, the following sequence of operations is performed: The timing diagrams in Figures 5-13 to 5-15 illustrate this mode of operation at different transmit speeds. For simplification, these diagrams show three quadlets of data payload. DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-13. Isochronous Transmit With Auto Header Insertion at 400 Mbps DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-14. Isochronous Transmit With Auto Header Insertion at 200 Mbps 5-11 DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-15. Isochronous Transmit With Auto Header Insertion at 100 Mbps 5.2.2 Isochronous Transmit Without Automatic Header Insertion Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: Step 7: Step 8: DMDONE will be asserted low (deactivated) at the next DMCLK cycle. DMPRE will pulse for one DMCLK cycle before the first header quadlet is sent. The data mover will fetch the header by asserting DMRW high. The data mover will then load the header into the header0 register and request the data to be transmitted out on the 1394 bus by the link core. The link will fetch the header. DMPRE will pulse for one DMCLK cycle before the first data quadlet is sent. The data mover will then begin to fetch the data payload by asserting DMRW high. When the last data quadlet has been fetched by the link, the data mover will check if the number of channels specified by the control registers have been sent. If all channels have been sent the data mover will wait for a subaction gap to occur before asserting DMDONE high to indicate the end of the cycle. Otherwise the DM will fetch the next header and load it into the next header register and then begin fetching the data payload until all channels are complete. Upon receiving a high on DMREADY, the following sequence of operations is performed: Figure 5-16 shows the timing diagram for this mode at a data transmit rate of 400 Mbps. The dashed sections indicate repetitive behaviour (when the payload is more than two quadlets long). DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-16. Isochronous Transmit Without Auto Header Insertion 5-12 5.2.3 Isochronous Packet Receive Without Header and Trailer In this mode, when the link receives an isochronous packet that is addressed to it, the following sequence of operations are performed: The packet router control logic will route the packet to the data mover. If the sync bit field in the header quadlet matches a bit pattern in the ISYNCRCVN field of the isochronous port register at 18h, DMPRE will be asserted high for one DMCLK cycle. Step 2: After the header is sent through, DMDONE will be asserted high for one DMCLK cycle. DMRW is then asserted high as the data payload comes through. Step 3: After all data has been received on the DMD[0:15] lines, DMRW will be asserted low and the trailer quadlet will then come out on the DMD[0:15] lines. PKTFLAG is never asserted high in this mode. Figure 5-17 shows the timing diagram for this mode at 400 Mbps. Figure 5-17 shows the case where DMPRE is asserted high for one DMCLK cycle to indicate that the sync bits of the received isochronous header matches the contents of the ISYNCRCVN field. DMCLK DMRW DMD[0:15] PKTFLAG DMDONE DMPRE Header quadlet Trailer quadlet Step 1: Figure 5-17. Isochronous Receive Without Header and Trailer 5.2.4 Isochronous Packet Receive With Header and Trailer In this mode, when the link receives an isochronous packet that is addressed to it, the following sequence of operations are performed: The packet router control logic will route the packet to the data mover. If the sync bit field in the header quadlet matches a bit pattern in the ISYNCRCVN field of the isochronous port register at 18h, DMPRE will be asserted high for one DMCLK cycle. At the same time DMDONE will be asserted high for one DMCLK cycle. Step 2: This is followed by DMRW asserted high as the packet comes through. PKTFLAG is only asserted high when the header quadlet is being received. Step 3: After all the data payload has been received on the DMD[0:15] lines, PKTFLAG will be asserted high again as the trailer quadlet is being received. Once the entire packet is received, the DMRW line will be asserted low. Figure 5-18 shows the timing diagram for this mode at 400 Mbps. Also, Figure 5-18 shows the case where DMPRE is asserted high for one DMCLK cycle to indicate that the sync bits of the received isochronous header matches the contents of the ISYNCRCVN field. DMCLK DMRW DMD[0:15] Header quadlet Trailer quadlet Step 1: PKTFLAG DMDONE DMPRE Figure 5-18. Isochronous Receive With Header and Trailer 5-13 Figure 5-19 shows the timing diagram at 200 Mbps when the received packet contains only one quadlet of payload. DMCLK DMRW DMD[0:15] 0000 Header quadlet 0000 Packet payload Trailer quadlet PKTFLAG DMDONE DMPRE Figure 5-19. Isochronous Receive With Header and Trailer at 200 Mbps 5.2.5 Asynchronous Packet Transmit With Automatic Header Insertion Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: DMDONE will be asserted low (deactivated) at the next DMCLK cycle. The data mover will take the headers that have been loaded into the header0-header3 registers and request the link core to transmit the data onto the 1394 bus. The link core will fetch the headers from the header0-header3 registers. DMPRE will pulse for one DMCLK cycle before the first data quadlet is sent. The data mover will then begin to fetch the data payload by asserting DMRW high. When the link core has fetched the last data quadlet, the data mover waits until the destination node returns an ack_complete immediate response. If an ack_complete is not received, the data mover will assert DMERROR high and become disabled. Upon receiving a high on DMREADY, the following sequence of operations are performed: Figure 5-20 and Figure 5-21 show the timing diagram for this mode for the quadlet transmit and the block transmit cases, respectively. For simplicity, a data block size of three quadlets was selected in Figure 5-20. Figure 5-22 shows the block transmit case at 400 Mbps. DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-20. Asynchronous Quadlet Transmit With Automatic Header Insertion DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-21. Asynchronous Block Transmit With Automatic Header Insertion at 200 Mbps 5-14 DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-22. Asynchronous Block Transmit With Automatic Header Insertion at 400 Mbps 5.2.6 Asynchronous Packet Transmit Without Automatic Header Insertion Upon receiving a high on DMREADY, the following sequence of operations are performed: Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: Step 7: Step 8: DMDONE will be asserted low (deactivated) at the next DMCLK cycle. DMPRE will pulse for one DMCLK cycle before the header quadlets are sent. The data mover will fetch the headers by asserting DMRW high. The data mover will then load the headers into the header0-header3 registers and request the data to be transmitted out on the 1394 bus by the link core. The link will fetch the headers. DMPRE will pulse for one DMCLK cycle before the first data quadlet is sent. The data mover will then begin to fetch the data payload by asserting DMRW high. When the link core has fetched the last data quadlet, the data mover waits until the destination node returns an ack_complete immediate response. If an ack_complete is not received, the data mover will assert DMERROR high and become disabled. Figure 5-23 and Figure 5-24 show the timing diagram for this mode for the quadlet transmit and the block transmit cases, respectively. For simplicity, a data block size of three quadlets was selected in Figure 5-24. DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Header Quadlets Data Quadlet Figure 5-23. Asynchronous Quadlet Transmit Without Automatic Header Insertion at 400 Mbps DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Header Quadlets Data Quadlets Figure 5-24. Asynchronous Block Transmit Without Automatic Header Insertion at 400 Mbps 5-15 5.2.7 Asynchronous Packet Receive With Headers and Trailer In this mode, when the link receives an isochronous packet that is addressed to it, the following sequence of operations is performed: Step 1: Step 2: Step 3: The packet router control logic will route the packet to the data mover. At the same time DMDONE will be asserted high for one DMCLK cycle. This is followed by DMRW asserted high as the packet comes through. PKTFLAG is only asserted high when the header quadlets are being received. After all the data payload has been received on the DMD[0:15] lines, PKTFLAG will be asserted high again as the trailer quadlet is being received. Once the entire packet is received, the DMRW line will be asserted low. Figure 5-25 and Figure 5-26 show the timing diagram for this mode for the quadlet receive and the block receive cases, respectively. For simplicity, a data block size of three quadlets was selected in Figure 5-26 DMCLK DMRW DMD[0:15] PKTFLAG DMDONE Figure 5-25. Asynchronous Quadlet Receive With Headers and Trailer at 400 Mbps DMCLK DMRW DMD[0:15] PKTFLAG DMDONE Figure 5-26. Asynchronous Block Receive With Headers and Trailer at 400 Mbps 5.2.8 Asynchronous Packet Receive Without Headers and Trailer In this mode, when the link receives an isochronous packet that is addressed to it, the following sequence of operations are performed: Step 1: Step 2: Step 3: The packet router control logic will route the packet to the data mover. After the headers are sent through, DMDONE will be asserted high for one DMCLK cycle. DMRW is then asserted high as the data payload comes through. After all data has been received on the DMD[0:15] lines, DMRW will be asserted low and the trailer quadlet will then come out on the DMD[0:15] lines. 5-16 Figure 5-27 and Figure 5-28 show the timing diagram for this mode for the quadlet receive and the block receive cases, respectively. For simplicity, a data block size of three quadlets was selected in Figure 5-28 DMCLK DMRW DMD[0:15] PKTFLAG DMDONE Figure 5-27. Asynchronous Quadlet Receive Without Headers and Trailer at 400 Mbps DMCLK DMRW DMD[0:15] PKTFLAG DMDONE Figure 5-28. Asynchronous Block Receive Without Headers and Trailer at 400 Mbps 5.3 Data Mover Byte Mode In this mode the DMD lines are only 1 byte wide => the maximum speed is only 200 Mbit/sec. Only bits 0-7 will be used for the data bus. DMERROR will be asserted if transmission of a 400 Mbit/sec packet is attempted. 5.4 Data Mover Endian Swapping In this mode the DMD[0:15] bytes are swapped. If the data mover is in byte mode, the least significant byte is fetched first (Figure 5-29). If the data mover is not in byte mode, the least significant word is fetched first and the byte order is then swapped (Figure 5-30). DMCLK DMRW DMD[0:15] NORM_LINK_DATA SWAP_LINK_DATA 01 02 03 04 A1 B2 C3 D4 A1B2C3D4 D4C3B2A1 01020304 04030201 Figure 5-29. Endian Swapping in Byte Mode DMCLK DMRW DMD[0:15] NORM_LINK_DATA SWAP_LINK_DATA 0102 0304 A1B2 C3D4 A1B2C3D4 D4C3B2A1 01020304 04030201 Figure 5-30. Endian Swapping in Word Mode 5-17 5.5 Data Mover Handshake Mode In this mode, when DMDONE is asserted high it will check for DMREADY low as an acknowledge. This is equivalent to the mode used in the TSB12LV31 (GPLynx), as shown in Figure 5-31. DMCLK DMRW DMD[0:15] DMREADY DMPRE DMDONE Figure 5-31. Data Mover Handshake Mode (GPLynx mode) 5.6 Data Mover Critical Timing Table 5-2. CLK to Output Timing With Respect to DMCLK PARAMETER TERMINAL NAME DMDONE DMRW Delay time (DMCLK to Q) DMPRE DMERROR PKTFLAG DMD[0:15] DMREADY Setup time to DMCLK Hold time from DMCLK DMD[0:15] DMREADY DMD[0:15] MIN 1.75 1.75 1.75 1.5 1.75 0.5 14 14 -1 -0.75 ns ns MAX 8.5 7.5 14.5 11.5 8.5 9 ns UNIT td0 td1 td2 td3 td4 td5 tsu0 tsu1 th0 th1 NOTE: All timing parameters are with respect to the rising edge of DMCLK 5-18 H0 S0 DMCLK S1 H1 D0 DMDONE D1 DMRW D2 DMPRE D3 DMERROR D4 PKTFLAG DMREADY D5 DMD[0:15] XXXX DATA XXXX DATA Figure 5-32. Clock to Output Timing With Respect to DMCLK 5-19 6 FIFO Memory Access Access to all FIFO memories is fundamentally the same, only the addresses to where the write is made changes. Figure 6-1 shows the FIFO-address access map. The FIFO is separated into an asynchronous transmit FIFO (ATF) and a general receive FIFO (GRF), each of 517 quadlets (2 Kbytes). Since asynchronous packets may also be transmitted through the data mover port and the ATF always has priority and its data wil be transmitted first. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 50h 54h 58h 5Ch 60h 64h 68h ATF_First ATF_Continue ATF_Continue & Update ATF_Burst_Write GRF Data Reserved ATF_First_Update Figure 6-1. TSB12LV32 Controller-FIFO-Access Address Map 6.1 General The suffix _First denotes a write to the FIFO location where the first quadlet of a packet should be written when the writer wants to transmit the packet. The first quadlet is held in the FIFO until a quadlet is written to an update location. The suffix _Continue denotes a write to the FIFO location where the second through n-1 quadlets of a packet should be written. The second through n-1 quadlets are held in the FIFO until a quadlet is written to an update location. The suffix_Continue & Update denotes a write to the FIFO location where the last quadlet of a multiple quadlet packet should be written. 6.2 ATF Access The procedure for accessing the ATF for a quadlet write operation is accomplished in three successive steps. To ensure that an ATF underflow condition does not occur, loading of the ATF in the following manner is highly recommended: First Quadlet of the Packet Successive (N-1) Quadlets of the Packet * * * Last (Nth) Quadlet of the Packet Figure 6-2. Asynchronous Packet With N Quadlets (ATV Loading Operation) Each quadlet can be written into the ATF register on byte (8-bit) boundary or word (16-bit) boundary. To write to the ATF in a byte fashion, the following steps should be followed: Step 1: Writing the first quadlet of the packet: a) Write the first 8-bits of the quadlet to ATF location 50h. b) Write the second 8-bits of the quadlet to ATF location 51h. c) Write the third 8-bits of the quadlet to ATF location 52h. d) Write the fourth 8-bits of the quadlet to ATF location 53h. The data is not yet confirmed for transmission. 6-1 Step 2: Writing the next (n-1) quadlets of the packet: a) Write the first 8-bits of each quadlet to ATF location 54h. b) Write the second 8-bits of each quadlet to ATF location 55h. c) Write the third 8-bits of each quadlet to ATF location 56h. d) Write the fourth 8-bits of each quadlet to ATF location 57h. The data is not yet confirmed for transmission. Last (Nth) quadlet of the packet: a) Write the first 8-bits of the quadlet to ATF location 58h. b) Write the second 8-bits of the quadlet to ATF location 59h. c) Write the third 8-bits of the quadlet to ATF location 5Ah. d) Write the fourth 8-bits of the quadlet to ATF location 5Bh. The data is now confirmed for transmission. Writing the first quadlet of the packet: a) Write the first 16-bits of the quadlet to ATF location 50h. b) Write the second 16-bits of the quadlet to ATF location 52h. The data is not yet confirmed for transmission. Writing the next (n-1) quadlets of the packet: a) Write the first 16-bits of each quadlet to ATF location 54h. b) Write the second 16-bits of each quadlet to ATF location 56h. The data is not yet confirmed for transmission. Last (Nth) quadlet of the packet: a) Write the first 16-bits of the quadlet to ATF location 58h. b) Write the second 16-bits of the quadlet to ATF location 5Ah. The data is now confirmed for transmission. Step 3: To write to the ATF in a word fashion, the following steps should be followed: Step 1: Step 2: Step 3: All writes to the ATF must be quadlet aligned (i.e., only an even number of write accesses is allowed). If the first quadlet of a packet is not written to the ATF_First location, the transmitter enters a state denoted by an ATStuck interrupt. An underflow of the ATF also causes an ATSTK interrupt. When this state is entered, no asynchronous packets can be sent until the ATF is cleared by way of the ATFCLR control bit (bit 0 at CFR 30h). However isochronous packets may still be sent while the ATF is in this state. 6.3 ATF Burst Access It is allowable to perform a burst write into location 54h (ATF_Continue), which allows multiple quadlets to load into ATF, but the data is not confirmed for transmission. It is also allowable to perform burst write to location 58h (ATF_Continue & Update), which allows multiple quadlets to load into ATF, and the data is confirmed for transmission. Write accesses to address 5Ch (ATF_Burst Write) writes the whole packet into the ATF. The first quadlet written into ATF has the control bit set to 1 to indicate this is the first quadlet of the packet, and the rest of the quadlets have the CD bit set to 0. The last quadlet written into ATF confirms the packet for transmission. To do a burst write operation the host bus master must continually drive MCS low. The TSB12LV32 loads MD0-MD15 to the ATF during each rising edge of BCLK while MCS is low. At the same time it asserts MCA (MCA is always one cycle behind MCS) low. The CD bit is 0 for ATF_Continue and ATF_Continue & Update. The ATF_First_Update is a unique address location optimised for transmitting zero length isochronous packets (including asynchronous streaming packets). A zero-length packet contains no data payload, and only the packet header and header CRC are transmitted. 6.4 General-Receive-FIFO (GRF) Access to the GRF is done with a read from the GRF, which requires a read from address 60h. The GRF will accumulate self-ID packets upon bus-reset. All quadlets of a self-ID packet are saved in the GRF after 6-2 power up. Hardware will check to insure the second quadlet is indeed the complement (logical inverse) of the first quadlet. If there are any errors associated with the self-ID process, a self-ID interrupt will be generated and the self-ID check register at 38h will be updated to reflect the error(s). This option can be turned off by setting the FULLSID bit in the control register at 08h to 0. 6.5 GRF Stored Data Format Each quadlet in the GRF is internally 33-bits wide. The most significant bit (extra bit) is used to indicate whether it is a packet token or a regular received quadlet (received header CRC and data CRC are checked and not stored in GRF). This bit is called the CD bit, which value is reflected in bit #16 of the FIFO status register. If CD bit is 1, the next quadlet read from the GRF is a packet token. If the CD bit is 0, the next quadlet read from the GRF is a regular received quadlet. A packet token is stored as the first quadlet for each received confirmed packet. The definition for packet token is shown in Table 6-1. Bit 0 is most significant bit and bit 32 is the least significant bit. Table 6-1. Packet Token Definition BITS 0 1-2 3-16 17-19 20-24 NAME CD Reserved QUADLET_COUNT Reserved ackCode DESCRIPTION CD bit is 1 for packet token. This bit should only be read from the FIFO status Register at 30h Reserved Expected quadlet count after packet token for this received packet. Reserved If bit 20 is 0, bits[21:24] are used as the Ack code that was sent back to the transmitting node. If bit 20 is 1, it is an error condition and an error Ack code is sent to the transmitting node. Reserved The speed code for the received packet. 00 - 100 Mb/s 01 - 200 Mb/s 10 - 400 Mb/s Reserved 25-26 27-28 Reserved SPEED 29-32 Reserved 6-3 7 TSB12LV32 Data Formats The data formats for transmission and reception of data are shown in the following sections. The transmit format describes the expected organization of data presented to the TSB12LV32 at the host-bus interface. The receive formats describe the data format that the TSB12LV32 presents to the host-bus interface. 7.1 Asynchronous Transmit (Host Bus to TSB12LV32) Asynchronous transmit refers to the use of the asynchronous-transmit FIFO (ATF) interface. The general-receive FIFO (GRF) is shared by asynchronous data and isochronous data. There are two basic formats for data to be transmitted and received. The first is for quadlet packets, and the second is for block packets. For transmits, the FIFO address indicates the beginning, middle, and end of a packet. For receives, the data length, which is found in the header of the packet, determines the number of bytes in a block packet. 7.1.1 Quadlet Transmit The quadlet-transmit format is shown in Figure 7-1 and 7-2, are described in Table 7-1. The first quadlet contains packet control information. The second and third quadlets contain the 64-bit, quadlet-aligned address. The fourth quadlet is data used only for write requests and read responses. For read requests and write responses, the quadlet data field is omitted. 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 spd destinationID desinationOffsetLow quadlet data tLabel rt tCode prioity desinationOffsetHigh Figure 7-1. Quadlet-Transmit Format (Write Request) 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 spd destinationID tLabel rCode rt tCode prioity quadlet data Figure 7-2. Quadlet-Transmit Format (Read Response) 7-1 Table 7-1. Quadlet-Transmit Format Functions FIELD NAME spd tLabel DESCRIPTION The spd field indicates the speed at which the current packet is to be sent. 00 = 100 Mb/s, 01 = 200 Mb/s, and 10 = 400 Mb/s, and 11 is undefined for this implementation. The tLabel field is the transaction label, which is a unique tag for each outstanding transaction between two nodes. This field is used to pair up a response packet with its corresponding request packet. The rt field is the retry code for the current packet is: 00 = new, 01 = retry_X, 10 = retryA, and 11 = retryB. The tCode field is the transaction code for the current packet (see Table 6-10 of IEEE-1394 standard). The priority field contains the priority level for the current packet. For cable implementation, the value of the bits must be zero (for backplane implementation, see clause 5.4.1.3 and 5.4.2.1 of the IEEE-1394 standard). The destinationID field is the concatenation of the 10-bit bus number and the 6-bit node number that forms the destination node address of the current packet. The concatenation of these two fields addresses a quadlet in the destination node address space. This address must be quadlet aligned (modulo 4). For write requests and read responses, the quadlet data field holds the data to be transferred. For write responses and read requests, this field is not used and should not be written into the FIFO. Specifies the result of the read request transaction. The response codes that may be returned to the requesting agent are defined as follows: Response Code 0 1-3 4 5 6 7 8-Fh Name resp_complete reserved resp_conflict_error resp_data_error resp_type_error resp_address_error reserved Description Node successfully completed requested operation rt tCode priority destinationID destination OffsetHigh, destination OffsetLow quadlet data rcode Resource conflict detected by responding agent. Request may be retried. Hardware error. Data not available. Field within request packet header contains un supported or invalid vallue. Address location within specified node not accessible 7.1.2 Block Transmit The block-transmit format is shown in Figure 7-3 and is described in Table 7-2. The first quadlet contains packet-control information. The second and third quadlets contain the 64-bit address. The first 16 bits of the fourth quadlet contains the dataLength field. This is the number of bytes of data in the packet. The remaining 16 bits represent the extended_tCode field (see Table 6-11 of the IEEE-1394 standard for more information on extended_tCodes). The block data, if any, follows the extended_tCode. 7-2 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 spd tLabel rt tCode prioity destinationID destinationOffsetLow dataLength block data destinationOffsetHigh extended_tCode Figure 7-3. Block-Transmit Format Table 7-2. Block-Transmit Format Functions FIELD NAME Spd TLabel DESCRIPTION The spd field indicates the speed at which the current packet is to be sent. 00 = 100 Mb/s, 01 = 200 Mb/s, and 10 = 400 Mb/s, and 11 is undefined for this implementation. The tLabel field is the transaction label, which is a unique tag for each outstanding transaction between two nodes. This field is used to pair up a response packet with its corresponding request packet. The rt field is the retry code for the current packet is 00 = new, 01 = retry_X, 10 = retryA, and 11 = retryB. tCode is the transaction code for the current packet (see Table 6-10 of IEEE-1394 standard). The priority level for the current packet. For cable implementation, the value of the bits must be zero. For backplane implementation, see clause 5.4.1.3 and 5.4.2.1 of the IEEE-1394 standard. The destinationID field is the concatenation of the 10-bit bus number and the 6-bit node number that forms the node address to which the current packet is being sent. The concatenation of the destination OffsetHigh and the destination OffsetLow fields addresses a quadlet in the destination node address space. This address must be quadlet aligned (modulo 4). The upper 4 bits of the destination OffsetHigh field are used as the response code for lock-response packets and the remaining bits are reserved. The dataLength filed contains the number of bytes of data to be transmitted in the packet. The block extended_tCode to be performed on the data in the current packet (see Table 6-11 of the IEEE-1394 standard). The block data field contains the data to be sent. If dataLength is 0, no data should be written into the FIFO for this field. Regardless of the destination or source alignment of the data, the first byte of the block must appear in byte 0 of the first quadlet. Rt TCode priority destinationID destination OffsetHigh, destination OffsetLow dataLength extended_tCode block data 7.1.3 Quadlet Receive The quadlet-receive format through the FIFO is shown in Figure 7-4 and is described in Table 7-3. The first quadlet (trailer) contains the packet-reception status that is added by the TSB12LV32. The first 16 bits of the second quadlet contain the destination node and bus ID, and the remaining 16 bits contain packet-control information. The first 16 bits of the third quadlet contain the node and bus ID of the source, and the remaining 16 bits of the third quadlet and the fourth quadlet contain the 48-bit, quadlet-aligned destination offset address. The last quadlet contains data that is used by write requests and read responses. For read requests and write responses, the quadlet data field is omitted. 7-3 01 00 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 00 0 tLabel ackCode rt 0 0 spd tCode 00 0 0 numofQuadlets destinationID sourceID prioity destinationOffsetHigh destinationOffsetLow quadlet data (for write request and read response) Figure 7-4. FIFO Quadlet-Receive Format The quadlet-receive format through the DM is shown in Figure 7-5 and is described in Table 7-3. This format is similar to the quadlet receive format for the TSB12LV31(GPLynx). The first 16 bits of the first quadlet contain the destination node and bus ID, and the remaining 16 bits contain packet-control information. The first 16 bits of the second quadlet contain the node and bus ID of the source, and the remaining 16 bits of the second and third quadlets contain the 48-bit, quadlet-aligned destination offset address. The fourth quadlet contains data that is used by write requests and read responses. For read requests and write responses, the quadlet data field is omitted. The last quadlet (trailer) contains the packet-reception status that is added by the TSB12LV32. 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 tLabel rt tCode prioity destinationID sourceID destinationOffsetHigh destinationOffsetLow quadlet data (for write request and read response) 00 numofQuadlets 00 0 ackCode 0 0 spd 00 0 0 Figure 7-5. Data Mover Quadlet-Receive Format 7-4 Table 7-3. Quadlet-Receive Format Functions FIELD NAME numofQuadlets ackCode Spd destinationID tLabel DESCRIPTION Total number of quadlets in the current packet (payload and header quadlets only). This 5-bit field holds the acknowledge code sent by the receiver for the current packet (see Table 6-13 in the draft standard). The spd field indicates the speed at which the current packet was sent. 00 = 100 Mbits/s, 01 =200 Mbits/s, 10 = 400 Mbits/s, and 11 is undefined for this implementation. The destinationID field contains the concatenation of the 10-bit bus number and the 6-bit node number that forms the node address to which the current packet is being sent. The tLabel field is the transaction label, which is a unique tag for each outstanding transaction between two nodes. This field is used to pair up a response packet with its corresponding request packet. The rt field is the retry code for the current packet is 00 = new, 01 = retry_X, 10 = retryA, and 11 = retryB. The tCode field is the transaction code for the current packet (see Table 6-10 of the IEEE-1394 standard). The priority field contains the priority level for the current packet. For cable implementation, the value of the bits must be zero (for backplane implementation, see clause 5.4.1.3 and 5.4.2.1 of the IEEE-1394 standard). The sourceID field contains the node ID of the sender of the current packet. The concatenation of the destination OffsetHigh and the destination OffsetLow fields addresses a quadlet in the destination nodes address space. This address must be quadlet aligned (modulo 4). (The upper four bits of the destination OffsetHigh field are used as the response code for lock-response packets, and the remaining bits are reserved.) For write requests and read responses, the quadlet data field holds the transferred data. For write responses and read requests, this field is not present. rt tCode priority sourceID destination OffsetHigh, destination OffsetLow quadlet data 7.1.4 Block Receive The block-receive format through the FIFO is shown in Figure 7-6 and is described in Table 7-5. The first 16 bits of the first quadlet contain the node and bus ID of the destination node, and the last 16 bits contain packet-control information. The first 16 bits of the second quadlet contain the node and bus ID of the source node, and the last 16 bits of the second quadlet and all of the third quadlet contain the 48-bit, quadlet-aligned destination offset address. All remaining quadlets, except for the last one, contain data that is used only for write requests and read responses. For block read requests and block write responses, the data field is omitted. The last quadlet contains packet-reception status. 01 00 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 00 0 tLabel ackCode rt 0 0 spd tCode 00 0 0 numofQuadlets destinationID sourceID prioity destinationOffsetHigh destinationOffsetLow dataLength block data (if any) extended_tCode Figure 7-6. FIFO Block-Receive Format 7-5 The block-receive format through the FIFO is shown in Figure 7-7. 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 tLabel rt tCode prioity destinationID sourceID destinationOffsetHigh destinationOffsetLow dataLength block data (if any) 00 numofQuadlets 00 0 extended_tCode ackCode 0 0 spd 00 0 0 Figure 7-7. Data Mover Block-Receive Format Table 7-4. Block-Receive Format Functions FIELD NAME numofQuadlets ackCode destinationID tLabel DESCRIPTION Total number of quadlets in the current packet (payload and header quadlets only) This 5-bit field holds the acknowledge code sent by the receiver for the current packet (see Table 6-13 in the draft standard). The destinationID field is the concatenation of the 10-bit bus number and the 6-bit node number that forms the node address to which the current packet is being sent. The tLabel field is the transaction label, which is a unique tag for each outstanding transaction between two nodes. This field is used to pair up a response packet with its corresponding request packet. The rt field contains the retry code for the current packet is 00 = new, 01 = retry_X, 10 = retryA, and 11 = retryB. The tCode field is the transaction code for the current packet (see Table 6-10 of the IEEE-1394 standard). The priority field contains the priority level for the current packet. For cable implementation, the value of the bits must be zero (for backplane implementation, see clause 5.4.1.3 and 5.4.2.1 of the IEEE-1394 standard). The sourceID field contains the node ID of the sender of the current packet. The concatenation of the destination OffsetHigh and the destination OffsetLow fields addresses a quadlet in the destination nodes address space. This address must be quadlet aligned (modulo 4). The upper 4 bits of the destination OffsetHigh field are used as the response code for lock-response packets and the remaining bits are reserved. For write request, read responses, and locks, the dataLength field indicates the number of bytes being transferred. For read requests, the dataLength field indicates the number of bytes of data to be read. A write-response packet does not use this field. Note that the number of bytes does not include the head, only the bytes of block data. The extended_tCode field contains the block extended_tCode to be performed on the data in the current packet (see Table 6-11 of the IEEE-1394 standard). The block data field contains any data being transferred for the current packet. Regardless of the destination address or memory alignment, the first byte of the data appears in byte 0 of the first quadlet of this field. The last quadlet of the field is padded with zeros out to four bytes, if necessary. The spd field indicates the speed at which the current packet was sent. 00 = 100 Mb/s, 01 = 200 Mb/s, 10 = 400 Mb/s, and 11 is undefined for this implementation. rt tCode priority sourceID destination OffsetHigh, destination OffsetLow dataLength extended_tCode block data spd 7-6 7.2 Isochronous Transmit (Host Bus to TSB12LV32) The format of the isochronous-transmit packet is shown in Figure 7-8 and is described in Table 7-5. The data for each channel must be presented to the isochronous-transmit FIFO interface in this format in the order that packets are to be sent. The transmitter sends any packets available at the isochronous-transmit interface immediately following reception or transmission of the cycle-start message. The speed at which the current packet is sent is determined by the speed field in the DM control register (bits 22-23) 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 TAG chanNum tCode 10 10 sy dataLength isochronous data Figure 7-8. Isochronous-Transmit Format Table 7-5. Isochronous-Transmit Functions FIELD NAME dataLength TAG chanNum tCode sy isochronous data DESCRIPTION The dataLength field indicates the number of bytes in the current packet The TAG field indicates the format of data carried by the isochronous packet (00 = formatted, 01 - 11 are reserved). The chanNum field carries the channel number with which the current data is associated. The transaction code for the current packet (tCode=Ah). The sy field carries the transaction layer-specific synchronization bits. The isochronous data field contains the data to be sent with the current packet. The first byte of data must appear in byte 0 of the first quadlet of this field. If the last quadlet does not contain four bytes of data, the unused bytes should be padded with zeros. 7.2.1 Isochronous Receive (TSB12LV32 to Host Bus) The format of the iscohronous-receive data through the DM is shown in Figure 7-8 and is described in Table 7-6. The data length, which is found in the header of the packet, determines the number of bytes in an isochronous packet. For iscohronous-receive through the FIFO, the last quadlet will be inserted as the first quadlet in the receive data, as shown in Figure 7-9. 01 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 TAG chanNum tCode 10 10 sy dataLength isochronous data 00 numofQuadlets 00 0 errCode 0 0 spd 00 0 0 Figure 7-9. Data Mover Isochronous-Receive Format 7-7 01 00 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 00 0 errCode 0 0 spd 00 0 0 numofQuadlets isochronous data dataLength TAG chanNum tCode 10 10 sy Figure 7-10. GRF Isochronous-Receive Format Table 7-6. Isochronous-Receive Functions FIELD NAME dataLength TAG chanNum tCode sy isochronous data spd numofQuadlets errCode DESCRIPTION The dataLength field indicates the number of bytes in the current packet. The TAG field indicates the format of data carried by isochronous packet (00 = formatted, 01 -- 11 are reserved). The chanNum field contains the channel number with which this data is associated. The tCode field carries the transaction code for the current packet (tCode = Ah). The sy field carries the transaction layer-specific synchronization bits. The isochronous data field has the data to be sent with the current packet. The first byte of data must appear in byte 0 of the first quadlet of this field. The last quadlet should be padded with zeros. The spd field indicates the speed at which the current packet was sent. Total number of quadlets in the current packet (payload and header quadlets only). The errCode field indicates whether the current packet has been received correctly. The possibilities are Complete, DataErr, or CRCErr, and have the same encoding as the corresponding acknowledge codes. 7-8 7.3 Phy Configuration The format of the Phy configuration packet is shown in Figure 7-12 and is described in Table 7-8. The Phy configuration packet transmit contains two quadlets, which are loaded into the ATF. The first quadlet is written to address 50h. The second quadlet is written to address 58h. The 00E0h in the first quadlet (bits 16-31) tells the TSB12LV32 that this quadlet is the Phy configuration packet. The Eh is then replaced with 0h before the packet is transmitted to the Phy interface. 01 00 2 345 root_ID 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 RT gap_cnt 0 0 00 00 tcode = 'E' 0011 1 000 00 Logical inverse of first 16 bits of first quadlet 1 1 11 11 111 1 1 111 11 Figure 7-11. Phy Configuration Packet Format The Phy configuration packet can perform the following functions: * * Set the gap count field of all nodes on the bus to a new value. The gap count, if set intelligently, can optimize bus performance. Force a particular node to be the bus root after the next bus reset. It is not valid to transmit a Phy configuration packet with both the R bit and T bit set to zero. This would cause the packet to be interpreted as an extended Phy packet. Table 7-7. Phy Configuration Packet Functions FIELD NAME 00 root_ID R T gap_cnt DESCRIPTION The 00 field is the Phy configuration packet identifier. The root_ID field is the physical_ID of the node to have its force_root bit set (only meaningful when R is set). When R is set, the force-root bit of the node identified in root_ID is set and the force_root bit of all other nodes are cleared. When R is cleared, root_ID is ignored. When T is set, the PHY_CONFIGURATION.gap_count field of all the nodes is set to the value in the gap_cnt field. The gap_cnt field contains the new value for PHY_CONFIGURATION.gap_count for all nodes. This value goes into effect immediately upon receipt and remains valid after the next bus reset. After the second reset, gap_cnt is set to 63h unless a new Phy configuration packet is received. The format of a received Phy-configuration packet is shown in Figure 7-12 and is described in Table 7-8. When PHY_PKT_ENA (bit 3 of the control register @08h) is set, all Phy packets will be received in the GRF. One HDRERR interrupt will be generated for every Phy packet received. 7-9 01 00 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 0 ackCode 0 0 spd 00 00 Number of quadlets Phy Configuration Quadlet Logical inverse of the Phy Configuration Quadlet Figure 7-12. Received Phy Configuration Packet Format Table 7-8. Receive Phy-Configuration Packet FIELD NAME numofQuadlets ackCode spd DESCRIPTION Total number of quadlets in the packet. This field is equal to 2 in this case. This 5-bit field holds the acknowledge code sent by the receiver for the current packet. In this case, the ackCode is equal to 1 (ack_complete) The spd field indicates the speed at which the current packet was sent. In this case, the spd field is equal to `00' (S100) 7.3.1 7.3.1.1 Extended Phy Packets Ping Packets The reception of a Phy ping packet causes the node identified by Phy_ID to transmit Self-ID packet(s) that reflect the current configuration and status of the Phy. The ping packet provides a method of measuring the round-trip delay of packets between two nodes on the bus that are farthest from one another in terms of cable hops. The format of this packet is shown in Figure 7-13 and described in Table 7-9. transmitted first 00 Phy_ID 00 type (0) 0 0 00 00 00 0 00 0 0 000 00 Logical inverse of the first quadlet transmitted last Figure 7-13. Ping Packet Format Table 7-9. Ping Packet Fields FIELD NAME Phy_ID type DESCRIPTION Physical node identifier of the destination of this packet Extended Phy packet type (zero identifies ping packet) 7-10 7.3.1.2 Remote Access Packets The remote access packet provides a method for a node to access the Phy registers of another node on the bus. The reception of a remote access packet causes the node identified by the Phy_ID field to read the selected Phy register and subsequntly return a remote reply packet that contains the current value of the Phy register. The format of this packet is shown in Figure 7-14 and described in Table 7-10. transmitted first 00 Phy_ID 00 type (8) 000 port 000 1 1 1 00 cmmd Logical inverse of the first quadlet transmitted last Figure 7-14. Remote Access Packet Format Table 7-10. Remote Access Packet Fields FIELD NAME Phy_ID type port cmmd DESCRIPTION Physical node identifier of the destination of this packet Extended Phy packet type ( 8 identifies command packet) This field selects one of the Phy's ports Command: 0 = NOP (No operation) 1 = Transmit TX_DISABLE_NOTIFY then disable port 2 = Initiate suspend (i.e., become a suspend initiator) 4 = Clear the port's Fault bit to zero 5 = Enable port 6 = Resume port 7.3.1.3 Remote Command Packets The remote command packet provides a method for one node to issue a number of Phy-specific commands to the selected port within the target Phy. The reception of a remote command packet shall request the node identified by the Phy_ID field to perform the operation specified in the cmnd field and subsequently return a remote confirmation packet. The format of this packet is shown in Figure 7-15 and described in Table 7-11. transmitted first 00 Phy_ID 00 type (8) 0 00 port 0 00 1 1 1 00 cmnd Logical inverse of the first quadlet transmitted last Figure 7-15. Remote Command Packet Format 7-11 Table 7-11. Remote Command Packet Fields FIELD NAME Phy_ID type port cmnd DESCRIPTION Physical node identifier of the destination of this packet Extended Phy packet type (8 identifies command packet) This field selects one of the Phy's ports Command: 0 = NOP (No operation) 1 = Transmit TX_DISABLE_NOTIFY then disable port 2 = Initiate suspend (i.e., become a suspend initiator) 4 = Clear the port's Fault bit to zero 5 = Enable port 6 = Resume port 7.3.1.4 Resume Packets The resume packet is a broadcast packet to all the Phys on the bus. It commands all suspended ports on the bus to resume normal operation. The reception of the resume packet causes any node to commence resume operations for all Phy ports that are both connected and suspended. A resume packet requires no reply. The format of this packet is shown in Figure 7-16 and described in Table 7-12. transmitted first 00 Phy_ID 00 type (F16) 0 00 0 00 0 0 11 1 0 0 000 Logical inverse of the first quadlet transmitted last Figure 7-16. Resume Packet Format Table 7-12. Resume Packet Fields FIELD NAME Phy_ID type DESCRIPTION Physical node identifier of the source of this packet Extended Phy packet type (F identifies resume packet) 7-12 7.4 Receive Self-ID Packet Based on the settings of the RXSID and FULLSID bits in the control register @08h, the self-ID packets can be either ignored or received into the GRF. Refer to Table 7-13. Table 7-13. GRF Receive Self-ID Setup Using Control Register Bits (RXSID and FULLSID) RXSID (bit 1) 0 1 1 FULLSID (bit 2) X 0 1 OPERATION Self-ID packets are not received by the link. Only the data quadlet (first quadlet) of the self-ID packets are received into the GRF. soth the data quadlet (first quadlet) and the logical inverse quadlet (second quadlet) of all Self-ID packets are received into the GRF. Figures 7-17 and 7-18 show the format of a received self-ID packet. For completeness, the figures assume the cable Phy on the bus implements the maximum number of ports allowed by the P1394a specification. Both figures show one received self-ID packet. The contents are described in Table 7-14. 01 00 2 345 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 LPS_RESET numofQuadlets 0 0 0 ackCode 0 0 spd 00 Self-ID Data Quadlet #0 Logical Inverse of the Self-ID Quadlet #0 Self-ID Data Quadlet #1 Logical Inverse of the Self-ID Quadlet #1 Self-ID Data Quadlet #2 Logical Inverse of theSelf-ID Quadlet #2 Figure 7-17. Receive Self-ID Packet Format (RXSID=1, FULLSID=1) Figure 7-18 shows the format of the received self-ID packet when the FULLSID is cleared. In this case, only the first quadlet of each self-ID packet is received in the GRF. 01 0 0 2 0 345 0 0 0 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 00 1 11 0 000 0 Self-ID Data Quadlet #0 Self-ID Data Quadlet #1 Self-ID Data Quadlet #2 Figure 7-18. Receive Self-ID Packet Format (RXSID=1, FULLSID=0) Table 7-14. Receive Self-ID Function FIELD NAME Self-ID Data Quadlet First 32-bits of the first self-ID packet DESCRIPTION Logical Inverse of the Second 32-bits of the first self-ID packet Self-ID Quadlet ACK When the ACK field is set (0001), the data in the Self-ID packet is correct. When ACK is 0001, the data in the self-ID packet is incorrect. 7-13 LPS_OFF The cable Phy sends one to three self-ID packets at the base rate (100 Mbits/s) during the self-ID phase of arbitration or in response to a ping packet. The number of self-ID packets sent depends on the number of ports. Figures 7-19, 7-20, and 7-21 show the format of the cable Phy self-ID packets. Inside the GRF, the first received quadlet of a self-ID packet is always 0000_00E0h, and the final quadlet is always the quadlet containing the acknowledgement code. 01 10 2 345 Phy_ID 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0L gap_cnt sp rsv c pwr p0 p1 p2 im Logical inverse of first quadlet Figure 7-19. Phy Self-ID Packet #0 Format 01 10 2 345 Phy_ID 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 n(0) rsv p3 p4 p5 p6 p7 p8 p9 p10 rm Logical inverse of first quadlet Figure 7-20. Phy Self-ID Packet #1 Format 01 10 2 345 Phy_ID 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 n(1) rsv p11 p12 p13 p14 p15 reserved Logical inverse of first quadlet Figure 7-21. Phy Self-ID Packet #2 Format When there is only one node (i.e., one Phy/link pair) on the bus, following a bus reset, the GRF contains 0000_00E0h and the acknowledge quadlet only. Example: If there are three 1394.a compliant nodes on the bus, each with a Phy containing three or less ports, the GRF of any one of the links is shown below. The FULLSID bit is assumed to be set in this example. GRF CONTENTS 0000_00E0h Self-ID1 Self-ID1 (inverse) Self-ID2 Self-ID2 (inverse) Self-ID3 Self-ID3 (inverse) 0000_000_ACK DESCRIPTION Header quadlet for Self-ID Phy packet Self_ID quadlet for Phy #1 Logical inverse quadlet for Self_ID of Phy #1 Self_ID quadlet for Phy #2 Logical inverse quadlet for Self_ID of Phy #2 Self_ID quadlet for Phy #3 Logical inverse quadlet for Self_ID of Phy #3 Trailing acknowledgement quadlet GRF contents (following a bus reset) with three nodes on the bus 7-14 Table 7-15. Phy Self-ID Packet Fields FIELD NAME 10 L gap_cnt sp The 10 field is the self-ID packet identifier. If set, this node has an active link and transaction layers. In discrete Phy implementations, this shall be the logical AND of Link_active and LPS active. The gap_cnt field contains the current value for the current node PHY_CONFIGURATION.gap_count field. The sp field contains the Phy speed capability. The code is: 00 01 10 11 c pwr 98.304 Mbits/s 98.304 Mbits/s and 196.608 Mbits/s 98.304 Mbits/s 196.608 Mbits/s, and 393.216 Mbits/s Extended speed capabilities reported in Phy register 3 DESCRIPTION If set and the link_active flag is set, this node is contender for the bus or isochronous resource manager as described in clause 8.4.2 of IEEE Std 1394-1995. Power consumption and source characteristics: 000 001 010 011 100 101 110 111 Node does not need power and does not repeat power. Node is self-powered and provides a minimum of 15W to the bus. Node is self-powered and provides a minimum of 30W to the bus. Node is self-powered and provides a minimum of 45W to the bus. Node may be powered from the bus and is using up to 3W. No additional power is needed to enable the link. Reserved for future standaraization. Node is powered from the bus and is using up to 3W. An additional 3W is needed to enable the link. Node is powered from the bus and is using up to 3W. An additional 7W is needed to enable the link. Not present on the current Phy Not connected to any other Phy Connected to the parent node Connected to the child node p0 - p15 The p0 - p15 field indicates the port connection status. The code is: 00 01 10 11 i m n If set, this node initiated the current bus reset (i.e., it started sending a bus_reset signal before it received one). If set, another self-ID packet for this node will immediately follow (i.e., if this bit is set and the next Self-ID packet received has a different Phy_ID, the a self-ID packet was lost) Extended self-ID packet sequence number rsv Reserved and set to all zeros There is no way to ensure that exactly one node has this bit set. More than one node can be requesting a bus reset at the same time. The link is enabled by the link-on Phy packet described in clause 7.5.2 of the IEEE 1394.a spec.; this packet may also enable application layers. 7-15 8 TSB12LV32/Phy Interface This section provides an overview of the digital interface between a TSB12LV32 and a physical layer device (Phy). The information that follows can be used as a guide through the process of connecting the TSB12LV32 to a 1394 Phy. The part numbers referenced, the TSB41LV03A and the TSB12LV32, represent the Texas Instruments implementation of the Phy (TSB41LV03A) and link (TSB12LV32) layers of the IEEE 1394-1995 and P1394a standards. The specific details of how the TSB41LV03A device operates are not discussed in this document. Only those parts that relate to the TSB12LV32 Phy interface are mentioned. 8.1 Principles of Operation The TSB12LV32 is designed to operate with a Texas Instruments physical-layer device. The following paragraphs describe the operation of the Phy-LLC interface assuming a TSB41LV03A Phy. The TSB41LV03A is an IEEE 1394a three port cable transceiver/arbiter Phy capable of 400 Mbits/s speeds. The interface to the Phy consists of the SCLK, CTL0-CTL1, D0-D7, LREQ, LPS, LINKON, and DIRECT terminals on the TSB12LV32, as shown in Figure 8-1. Refer to Texas Instruments Application Report SLLA044 for a detailed description of the electrical interface between the TSB12LV32 and TSB41LV03. TSB12LV32 Link-Layer Controller SCLK CTL0-CTL1 D0-D7 LREQ LPS LINKON DIRECT DIRECT ISO Phy/LLC Interface TSB41LV03A Physical-Layer Device SYSCLK CTL0-CTL1 D0-D7 LREQ LPS C/LKON ISO Figure 8-1. Phy-LLC Interface The SYSCLK from the Phy terminal provides a 49.152 MHz interface clock. All control and data signals are synchronized to, and sampled on, the rising edge of SYSCLK. The CTL0 and CTL1 terminals form a bidirectional control bus, which controls the flow of information and data between the TSB41LV03A and TSB12LV32. The D0-D7 terminals form a bidirectional data bus, which is used to transfer status information, control information, or packet data between the devices. The TSB41LV03A supports S100, S200, and S400 data transfers over the D0-D7 data bus. In S100 operation only the D0 and D1 terminals are used; in S200 operation only the D0-D3 terminals are used; and in S400 operation all D0-D7 terminals are used for data 8-1 transfer. When the TSB41LV03A is in control of the D0-D7 bus, unused Dn terminals are driven low during S100 and S200 operations. When the TSB12LV32 is in control of the D0-D7 bus, unused Dn terminals are ignored by the TSB41LV03A. The LREQ terminal is controlled by the TSB12LV32 to send serial service requests to the Phy in order to request access to the serial-bus for packet transmission, read or write Phy registers, or control arbitration acceleration. The LPS and LINKON terminals are used for power management of the Phy and TSB12LV32. The LPS terminal indicates the power status of the TSB12LV32, and may be used to reset the Phy-LLC interface or to disable SYSCLK. The C/LKON terminal is used to send a wake-up notification to the TSB12LV32 and to indicate an interrupt to the TSB12LV32 when either LPS is inactive or the Phy register LCtrl bit is zero. The DIRECT and ISO terminals are used to enable the output differentiation logic on the CTL0-CTL1 and D0-D7 terminals. Output differentiation is required when an Annex J type isolation barrier is implemented between the Phy and TSB12LV32. The TSB41LV03A normally controls the CTL0-CTL1 and D0-D7 bidirectional buses. The TSB12LV32 is allowed to drive these buses only after the TSB12LV32 has been granted permission to do so by the Phy. There are four operations that may occur on the Phy-LLC interface: link service request, status transfer, data transmit, and data receive. The TSB12LV32 issues a service request to read or write a Phy register, to request the Phy to gain control of the serial-bus in order to transmit a packet, or to control arbitration acceleration. The Phy may initiate a status transfer either autonomously or in response to a register read request from the TSB12LV32. The Phy initiates a receive operation whenever a packet is received from the serial-bus. The Phy initiates a transmit operation after winning control of the serial-bus following a bus-request by the TSB12LV32. The transmit operation is initiated when the Phy grants control of the interface to the TSB12LV32. The encoding of the CTL0-CTL1 bus is shown in Table 8-1 and Table 8-2. Table 8-1. CTL Encoding When the Phy Has Control of the Bus CTL0 0 0 1 1 CTL1 0 1 0 1 NAME Idle Status Receive Grant DESCRIPTION No activity (this is the default mode) Status information is being sent from the Phy to the TSB12LV32. An incoming packet is being sent from the Phy to the TSB12LV32. The TSB12LV32 has been given control of the bus to send an outgoing packet. Table 8-2. CTL Encoding When the TSB12LV32 Has Control of the Bus CTL0 0 0 1 1 CTL1 0 1 0 1 NAME Idle Hold Transmit Reserved DESCRIPTION The TSB12LV32 releases the bus (transmission has been completed) The TSB12LV32 is holding the bus while data is being prepared for transmission, or indicating that another packet is to be transmitted (concatenated) without arbitrating An outgoing packet is being sent from the TSB12LV32 to the Phy. Reserved 8-2 8.2 TSB12LV32 Service Request To request access to the bus, to read or write a Phy register, or to control arbitration acceleration, the TSB12LV32 sends a serial bit stream on the LREQ terminal as shown in Figure 8-2. LR0 LR1 LR2 LR3 ...... LR(n-2) LR(n-1) NOTE: Each cell represents one clock sample time, and n is the number of bits in the request stream. Figure 8-2. LREQ Request Stream The length of the stream will vary depending on the type of request as shown in Table 8-3. Table 8-3. Request Stream Bit Length REQUEST TYPE Bus Request Read Register Request Write Register Request Acceleration Control Request NUMBER OF BITS 7 or 8 9 17 6 Regardless of the type of request, a start-bit of 1 is required at the beginning of the stream, and a stop-bit of 0 is required at the end of the stream. The second through fourth bits of the request stream indicate the type of the request. In the descriptions below, bit 0 is the most significant and is transmitted first in the request bit stream. The LREQ terminal is normally low. Encoding for the request type is shown in Table 8-4. Table 8-4. Request Type Encoding LR1-LR3 000 001 010 011 100 101 110 111 NAME ImmReq IsoReq PriReq FairReq RdReg WrReg AccelCtl Reserved DESCRIPTION Immediate bus request. Upon detection of idle, the Phy takes control of the bus immediately without arbitration. Isochronous bus request. Upon detection of idle, the Phy arbitrates for the bus without waiting for a subaction gap. Priority bus request. The Phy arbitrates for the bus after a subaction gap, ignores the fair protocol. Fair bus request. The Phy arbitrates for the bus after a subaction gap, follows the fair protocol. The Phy returns the specified register contents through a status transfer. Write to the specified register. Enable or disable asynchronous arbitration acceleration. Reserved. For a bus request the length of the LREQ bit stream is 7 or 8 bits as shown in Table 8-5. Table 8-5. Bus Request BIT(S) 0 1-3 4-6 7 NAME Start Bit Request Type Request Speed Stop Bit DESCRIPTION Indicates the beginning of the transfer (always 1). Indicates the type of bus request (see Table 8-4). Indicates the speed at which the Phy will send the data for this request (see Table 8-6) for the encoding of this field. Indicates the end of the transfer (always 0). If bit 6 is 0, this bit may be omitted. The 3-bit request speed field used in bus requests is shown in Table 8-6. 8-3 Table 8-6. Bus Request Speed Encoding LR4-LR6 000 010 100 All Others DATA RATE S100 S200 S400 Invalid NOTE: The TSB41LV03A will accept a bus request with an invalid speed code and process the bus request normally. However, during packet transmission for such a request, the TSB41LV03A will ignore any data presented by the TSB12LV32 and will transmit a null packet. For a read register request the length of the LREQ bit stream is 9 bits as shown in Table 8-7. Table 8-7. Read Register Request BIT(S) 0 1-3 4-7 8 NAME Start Bit Request Type Address Stop Bit DESCRIPTION Indicates the beginning of the transfer (always 1). A 100 indicating this is a read register request. Identifies the address of the Phy register to be read. Indicates the end of the transfer (always 0). For a write register request the length of the LREQ bit stream is 17 bits as shown in Table 8-8. Table 8-8. Write Register Request BIT(S) 0 1-3 4-7 8-15 16 NAME Start Bit Request Type Address Data Stop Bit DESCRIPTION Indicates the beginning of the transfer (always 1). A 101 indicating this is a write register request. Identifies the address of the Phy register to be written to. Gives the data that is to be written to the specified register address. Indicates the end of the transfer (always 0). For an acceleration control request the length of the LREQ bit stream is 6 bits as shown in Table 8-9. Table 8-9. Acceleration Control Request BIT(S) 0 1-3 4 5 NAME Start Bit Request Type Control Stop Bit DESCRIPTION Indicates the beginning of the transfer (always 1). A 110 indicating this is a acceleration control request. Asynchronous period arbitration acceleration is enabled if 1, and disabled if 0. Indicates the end of the transfer (always 0). For fair or priority access, the TSB12LV32 sends the bus request (FairReq or PriReq) at least one clock after the Phy-LLC interface becomes idle. If the CTL terminals are asserted to the receive state ('b10) by the Phy, then any pending fair or priority request is lost (cleared). Additionally, the Phy ignores any fair or priority requests if the receive state is asserted while the TSB12LV32 is sending the request. The TSB12LV32 may then reissue the request one clock after the next interface idle. The cycle master node uses a priority bus request (PriReq) to send a cycle start message. After receiving or transmitting a cycle start message, the TSB12LV32 can issue an isochronous bus request (IsoReq). The Phy will clear an isochronous request only when the serial bus has been won. 8-4 To send an acknowledge packet, the TSB12LV32 must issue an immediate bus request (ImmReq) during the reception of the packet addressed to it. This is required in order to minimize the idle gap between the end of the received packet and the start of the transmitted acknowledge packet. As soon as the receive packet ends, the Phy immediately grants control of the bus to the TSB12LV32. The TSB12LV32 sends an acknowledgment to the sender unless the header CRC of the received packet is corrupted. In this case, the TSB12LV32 does not transmit an acknowledge, but instead cancels the transmit operation and releases the interface immediately; the TSB12LV32 must not use this grant to send another type of packet. After the interface is released the TSB12LV32 may proceed with another request. The TSB12LV32 may make only one bus request at a time. Once the TSB12LV32 issues any request for bus access (ImmReq, IsoReq, FairReq, or PriReq), it cannot issue another bus request until the Phy indicates that the bus request was lost (bus arbitration lost and another packet received), or won (bus arbitration won and the TSB12LV32 granted control). The Phy ignores new bus requests while a previous bus request is pending. All bus requests are cleared upon a bus reset. For write register requests, the Phy loads the specified data into the addressed register as soon as the request transfer is complete. For read register requests, the Phy returns the contents of the addressed register to the TSB12LV32 at the next opportunity through a status transfer. If a received packet interrupts the status transfer, then the Phy continues to attempt the transfer of the requested register until it is successful. A write or read register request may be made at any time, including while a bus request is pending. Once a read register request is made, the Phy ignores further read register requests until the register contents are successfully transferred to the TSB12LV32. A bus reset does not clear a pending read register request. The TSB41LV03A includes several arbitration acceleration enhancements, which allow the Phy to improve bus performance and throughput by reducing the number and length of interpacket gaps. These enhancements include autonomous (fly-by) isochronous packet concatenation, autonomous fair and priority packet concatenation onto acknowledge packets, and accelerated fair and priority request arbitration following acknowledge packets. The enhancements are enabled when the EAA bit in Phy register 5 is set. The arbitration acceleration enhancements may interfere with the ability of the cycle master node to transmit the cycle start message under certain circumstances. The acceleration control request is therefore provided to allow the TSB12LV32 to temporarily enable or disable the arbitration acceleration enhancements of the TSB41LV03A during the asynchronous period. The TSB12LV32 typically disables the enhancements when its internal cycle counter rolls over indicating that a cycle start message is imminent, and then re-enables the enhancements when it receives a cycle start message. The acceleration control request may be made at any time, however, and is immediately serviced by the Phy. Additionally, a bus reset or isochronous bus request will cause the enhancements to be re-enabled, if the EAA bit is set. 8.3 Status Transfer A status transfer is initiated by the Phy when there is status information to be transferred to the TSB12LV32. The Phy waits until the interface is idle before starting the transfer. The transfer is initiated by the Phy asserting status (`b01) on the CTL terminals, along with the first two bits of status information on the D[0:1] terminals. The Phy maintains CTL = status for the duration of the status transfer. The Phy may prematurely end a status transfer by asserting something other than status on the CTL terminals. This occurs if a packet is received before the status transfer completes. The Phy continues to attempt to complete the transfer until all status information has been successfully transmitted. There is at least one idle cycle between consecutive status transfers. The Phy normally sends just the first four bits of status to the TSB12LV32. These bits are status flags that are needed by the TSB12LV32 state machines. The Phy sends an entire 16-bit status packet to the TSB12LV32 after a read register request, or when the Phy has pertinent information to send to the TSB12LV32 or transaction layers. The only defined condition where the Phy automatically sends a register to the TSB12LV32 is after self-ID, where the Phy sends the physical-ID register that contains the new node 8-5 address. All status transfers are either 4 or 16 bits unless interrupted by a received packet. The status flags are considered to have been successfully transmitted to the TSB12LV32 immediately upon being sent, even if a received packet subsequently interrupts the status transfer. Register contents are considered to have been successfully transmitted only when all 8 bits of the register have been sent. A status transfer is retried after being interrupted only if any status flags remain to be sent, or if a register transfer has not yet completed. The definition of the bits in the status transfer are shown in Table 8-9 and the timing is shown in Figure 8-3. Table 8-10. Status Bits BIT(S) 0 NAME Arbitration Reset Gap DESCRIPTION Indicates that the Phy has detected that the bus has been idle for an arbitration reset gap time (as defined in IEEE Std 1394-1995). This bit is used by the TSB12LV32 in the busy/retry state machine. Indicates that the Phy has detected that the bus has been idle for a subaction gap time (as defined in IEEE Std 1394-1995). This bit is used by the TSB12LV32 to detect the completion of an isochronous cycle. Indicates that the Phy has entered the bus reset start state. Indicates that a Phy interrupt event has occurred. An interrupt event may be a configuration time-out, cable-power voltage falling too low, a state time-out, or a port status change. This field holds the address of the Phy register whose contents are being transferred to the TSB12LV32. This field holds the register contents. 1 Subaction Gap 2 3 Bus Reset Interrupt 4-7 8-15 Address Data SYSCLK (a) CTL0, CTL1 00 01 (b) 00 D0, D1 00 S[0:1] S[14:15] 00 Figure 8-3. Status Transfer Timing The sequence of events for a status transfer is as follows: * Status transfer initiated. The Phy indicates a status transfer by asserting status on the CTL lines along with the status data on the D0 and D1 lines (only 2 bits of status are transferred per cycle). Normally (unless interrupted by a receive operation), a status transfer will be either 2 or 8 cycles long. A 2-cycle (4-bit) transfer occurs when only status information is to be sent. An 8-cycle (16-bit) transfer occurs when register data is to be sent in addition to any status information. Status transfer terminated. The Phy normally terminates a status transfer by asserting idle on the CTL lines. The Phy may also interrupt a status transfer at any cycle by asserting receive on the CTL lines to begin a receive operation. The Phy shall assert at least one cycle of idle between consecutive status transfers. * 8.4 Receive Operation Whenever the Phy detects the data-prefix state on the serial bus, it initiates a receive operation by asserting Receive on the CTL terminals and a logic 1 on each of the D terminals (data-on indication). The Phy indicates the start of a packet by placing the speed code (encoded as shown in Table 8-11 on the D terminals, followed by packet data. The Phy holds the CTL terminals in the receive state until the last symbol of the packet has 8-6 been transferred. The Phy indicates the end of packet data by asserting idle on the CTL terminals. All received packets are transferred to the TSB12LV32. Note that the speed code is part of the Phy-LLC protocol and is not included in the calculation of CRC or any other data protection mechanisms. It is possible for the Phy to receive a null packet, which consists of the data-prefix state on the serial bus followed by the data-end state, without any packet data. A null packet is transmitted whenever the packet speed exceeds the capability of the receiving Phy, or whenever the TSB12LV32 immediately releases the bus without transmitting any data. In this case, the Phy will assert receive on the CTL terminals with the data-on indication (all 1s) on the D terminals, followed by idle on the CTL terminals, without any speed code or data being transferred. In all cases, the TSB41LV03A sends at least one data-on indication before sending the speed code or terminating the receive operation. The TSB41LV03A also transfers its own self-ID packet, transmitted during the self-ID phase of bus initialization, to the TSB12LV32. This packet it transferred to the TSB12LV32 just as any other received self-ID packet. SYSCLK (a) CTL0, CTL1 00 01 (b) D0-D7 XX FF ("data-on") 10 (c) SPD (d) d0 dn 00 (e) 00 Figure 8-4. Normal Packet Reception Timing The sequence of events for a normal packet reception is as follows: * Receive operation initiated. The Phy indicates a receive operation by asserting receive on the CTL lines. Normally, the interface is idle when receive is asserted. However, the receive operation may interrupt a status transfer operation that is in progress so that the CTL lines may change from status to receive without an intervening idle. Data-on indication. The Phy asserts the data-on indication code on the D lines for one or more cycles preceding the speed-code. Speed-code. The Phy indicates the speed of the received packet by asserting a speed-code on the D lines for one cycle immediately preceding packet data. The link decodes the speed-code on the first receive cycle for which the D lines are not the data-on code. If the speed-code is invalid, or indicates a speed higher than that which the link is capable of handling, the link should ignore the subsequent data. Receive data. Following the data-on indication (if any) and the speed-code, the Phy asserts packet data on the D lines with receive on the CTL lines for the remainder of the receive operation. Receive operation terminated. The Phy terminates the receive operation by asserting idle on the CTL lines. The Phy asserts at least one cycle of idle following a receive operation. * * * * 8-7 SYSCLK (a) CTL0, CTL1 00 01 (b) D0-D7 XX FF ("data-on") 10 (c) SPD (d) d0 dn 00 (e) 00 Figure 8-5. Null Packet Reception Timing The sequence of events for a null packet reception is as follows: * Receive operation initiated. The Phy indicates a receive operation by asserting receive on the CTL lines. Normally, the interface is idle when receive is asserted. However, the receive operation may interrupt a status transfer operation that is in progress so that the CTL lines may change from status to receive without an intervening idle. Data-on indication. The Phy asserts the data-on indication code on the D lines for one or more cycles. Receive operation terminated. The Phy terminates the receive operation by asserting idle on the CTL lines. The Phy asserts at least one cycle of idle following a receive operation. Table 8-11. Receive Speed Codes D0-D7 00XX XXXX 0100 XXXX 0101 0000 1YYY YYYY DATA RATE S100 S200 S400 Data-on indication * * NOTE: X = Output as 0 by Phy, ignored by TSB12LV32. Y = Output as 1 by Phy, ignored by TSB12LV3 8.5 Transmit Operation When the TSB12LV32 issues a bus request through the LREQ terminal, the Phy arbitrates to gain control of the bus. If the Phy wins arbitration for the serial bus, the Phy-LLC interface bus is granted to the TSB12LV32 by asserting the grant state ('b11) on the CTL terminals for one SYSCLK cycle, followed by idle for one clock cycle. The TSB12LV32 then takes control of the bus by asserting either idle ('b00), hold ('b01) or transmit ('b10) on the CTL terminals. Unless the TSB12LV32 is immediately releasing the interface, the TSB12LV32 may assert the idle state for at most one clock before it must assert either hold or transmit on the CTL terminals. The hold state is used by the TSB12LV32 to retain control of the bus while it prepares data for transmission. The TSB12LV32 may assert hold for zero or more clock cycles (i.e., the TSB12LV32 need not assert hold before transmit). The Phy asserts data-prefix on the serial bus during this time. When the TSB12LV32 is ready to send data, the TSB12LV32 asserts transmit on the CTL terminals as well as sending the first bits of packet data on the D lines. The transmit state is held on the CTL terminals until the last bits of data have been sent. The TSB12LV32 then asserts either hold or idle on the CTL terminals for one clock cycle, and then asserts idle for one additional cycle before releasing the interface bus and placing its CTL and D terminals in high impedance. The Phy then regains control of the interface bus. The hold state asserted at the end of packet transmission indicates to the Phy that the TSB12LV32 requests to send another packet (concatenated packet) without releasing the serial bus. The Phy responds to this concatenation request by waiting the required minimum packet separation time and then asserting grant as before. This function may be used to send a unified response after sending an acknowledge, or to send 8-8 consecutive isochronous packets during a single isochronous period. Unless multispeed concatenation is enabled, all packets transmitted during a single bus ownership must be of the same speed (since the speed of the packet is set before the first packet). If multispeed concatenation is enabled (when the EMSC bit of Phy register 5 is set), the TSB12LV32 must specify the speed code of the next concatenated packet on the D terminals when it asserts hold on the CTL terminals at the end of a packet. The encoding for this speed code is the same as the speed code that precedes received packet data as given in Table 8-11. After sending the last packet for the current bus ownership, the TSB12LV32 releases the bus by asserting Idle on the CTL terminals for two clock cycles. The Phy begins asserting Idle on the CTL terminals one clock after sampling Idle from the link. Note that whenever the D and CTL terminals change direction between the Phy and the TSB12LV32, there is an extra clock period allowed so that both sides of the interface can operate on registered versions of the interface signals. SYSCLK (a) CTL0, CTL1 00 11 00 (b) 00 (c) 01 (d) 10 (e) 01 00 (f) D0-D7 00 00 d0 dn SPD 00 00 00 00 (g) 00 Link controls CTL and D Phy CTL and D outputs are High Impedance NOTE: SPD = Speed code, see Table 8-11, d0-dn = Packet data Figure 8-6. Normal Packet Transmission Timing The sequence of events for a normal packet transmission is as follows: * Transmit operation initiated. The Phy asserts grant on the CTL lines followed by Idle to hand over control of the interface to the link so that the link may transmit a packet. The Phy releases control of the interface (i.e., it places its CTL and D outputs in a high-impedance state) following the idle cycle. Optional idle cycle. The link may assert at most one Idle cycle preceding assertion of either hold or transmit. This idle cycle is optional; the link is not required to assert Idle preceding either hold or transmit. Optional hold cycles. The link may assert hold for up to 47 cycles preceding assertion of transmit. These hold cycle(s) are optional; the link is not required to assert hold preceding transmit. * * 8-9 8.6 TSB12LV32/Phy Interface Critical Timing PARAMETER PIN NAME(S) LREQ CTL[0:1] D[0:7] CYCLEIN CONTNDR CTL[0:1] D[0:7] CYCLEIN CONTNDR CTL[0:1] MIN 3 3 3.5 2 3 3 3 2 2 0 0 MAX 21 21 21 UNIT ns ns ns ns ns ns ns ns ns ns ns td0, delay time (SCLK to Q) td1, delay time (SCLK to Q) td2, delay time (SCLK to Q) tsu0, setup time to SCLK tsu1, setup time to SCLK tsu2, setup time to SCLK tsu3, setup time to SCLK th0, hold time from SCLK th1, hold time from SCLK th2, hold time from SCLK th3, hold time from SCLK D[0:7] All timing parameters are referenced to the rising edge of SCLK on the TSB12LV32 side. S1 S2 S3 SCLK S0 H2 H0 H3 H1 D0 LREQ CYCLEIN CONTNDR D1 CTL[0:1] X CONTROL X CONTROL D2 D[0:7] XX DATA XX DATA Figure 8-7. Critical Timing for the TSB12LV32/Phy Interface 8-10 9 Electrical Characteristics 9.1 Absolute Maximum Ratings Over Operating Free-Air Temperature Range (Unless Otherwise Noted) Supply voltage range, VCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -0.5 V to 3.6 V Supply voltage range, VCC5V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -0.5 V to 5.5 V Input voltage range, VI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -0.5 V to VCC5V + 0.5 V Output voltage range, VO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -0.5 V to VCC5V + 0.5 V Input clamp current, IIK (VI < 0 or VI > VCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 mA Output clamp current, IOK (VO < 0 or VO > VCC . . . . . . . . . . . . . . . . . . . . . . . . . . 20 mA Operating free-air temperature range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -40C to 110C Storage temperature range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -65C to 150C Stresses beyond those listed under "absolute maximum ratings" may cause permanent damage to the device. These are stress ratings only, and functional operation of the device at these or any other conditions beyond those indicated under "recommended operating conditions" is not implied. Exposure to absolute-maximum-rated conditions for extended periods may affect device reliability. NOTES: 1. This applies to external input and bidirectional buffers. For 5-V tolerant terminals, use VI > VCC5V. 2. This applies to external output and bidirectional buffers. For 5-V tolerant terminals, use VI > VCC5V. DISSIPATION RATING TABLE PACKAGE PZ TA 25 C 25C POWER RATING 1500 mW DERATING FACTOR ABOVE TA = 25C 16.9 mW/C TA = 70 C 70C POWER RATING 737 mW TA = 85 C 85C POWER RATING 482 mW TA = 110C 110 C POWER RATING 63.5 mW 9.2 Recommended Operating Conditions MIN NOM 3.3 4.5 MAX 3.6 5.5 VCC5V VCC VCC5V 0.7 25 25 110 UNIT V V V V V V ns C 3 3 0 0 2.2 0 0 -40 Supply voltage, VCC Supply voltage, VCC5V Input voltage, VI Output voltage, VO High-level input voltage, VIH Low-level input voltage, VIL Input transition time, tf and tr (10% to 90%) Operating free-air temperature, TA This applies to external output buffers. 9-1 9.3 Electrical Characteristics Over Recommended Ranges of Supply Voltage and Operating Free-Air Temperature (Unless Otherwise Noted) PARAMETER VOH VOL IIL IIH High-level output voltage Low-level output voltage Low-level input current High-level input current TEST CONDITIONS IOH = - 8 mA IOL = 8 mA VI = VIL VI = VIH 10 MIN VCC-0.6 0.5 -20 20 20 TYP MAX UNIT V V A A A A IOZ High-impedance output current VO = VCC or GND ICC(Q) Static supply current IO = 0 All typical characteristics are measured at VCC = 3.3 V and TA = 25C. 9-2 10 Mechanical Information The TSB12LV32 is packaged in a high-performance 100-pin PZ package. The following shows the mechanical dimensions of the PZ package. PZ (S-PQFP-G100) 0,27 0,17 51 PLASTIC QUAD FLATPACK 0,50 75 0,08 M 76 50 100 26 0,13 NOM 1 12,00 TYP 14,20 SQ 13,80 16,20 SQ 15,80 0,05 MIN 1,45 1,35 0,25 0- 7 Gage Plane 25 0,75 0,45 Seating Plane 1,60 MAX 0,08 4040149 / B 11/96 NOTES: A. All linear dimensions are in millimeters. B. This drawing is subject to change without notice. C. Falls within JEDEC MS-026 10-1 |
Price & Availability of TSB12LV32-EP
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |