CS4210VJG

CS4210 Geode CS4210 IEEE 1394 OHCI Controller Literature Number: SNOS923A Geode™ CS4210 IEEE 1394 OHCI Controller General Description

















Eight isochronous transmit contexts Eight isochronous receive contexts Capable of reading a 128-byte descriptor in one burst 128 byte, zero wait state bursting Dynamically re-prioritize services 2 KB of isochronous transmit FIFO 2 KB of asynchronous transmit FIFO ol e The CS4210 is an implementation of the link layer protocol of the IEEE 1394 high speed serial bus, with additional features to support the transaction and bus management layers. The CS4210 also includes DMA engines for high speed performance data transfer and a host PCI bus interface. Perfect for use in PC, set-top box, thin client, and WebPAD™ system applications. 1394-1995 version and P1394a Draft 2.0 Physical Layer devices te The National Semiconductor® Geode™ CS4210 is a PCIbased IEEE 1394 OHCI (Open Host Controller Interface) controller. The CS4210 provides an implementation of the IEEE 1394 Link Layer functionality according to the programming model defined by 1394 OHCI Specification Version 1.0. It supports high speed serial communication up to 400 Mbits per second. The CS4210 supports two types of data transfers: asynchronous and isochronous. bs The CS4210 provides an external IEEE 1394 physical layer device interface. The CS4210’s physical layer interface (PHY-Link) is compatible with the Geode™ CS4103 and other IEEE 1394 physical layer devices. Features
Supports 100, 200, and 400 Mbit/sec data transfer rates
Compliant with 1394 OHCI Specification Version 1.0
Compatible interface with the Geode CS4103 IEEE Per-packet FIFO thresholding Four concurrent posted writes Eight pending physical responses National specific configuration registers I2C interface support for an optional serial EEPROM Accepts and generates external 8 kHz reference clock 5V tolerant PCI rev 2.1 I/O interface 0.25µ CMOS 100-pin LQFP (Low-profile Quad Flat Pack) package NAND tree for test purposes O P1394a Physical Layer (PHY) device and other IEEE 4 KB of receiver FIFO System Block Diagram PCI Bus I2C Interface EEPROM PCI Interface Geode™ CS4210 IEEE 1394 OHCI Controller PHY-Link Interface Geode™ CS4103 P1394a Physical Layer IEEE 1394 Cable Connectors National Semiconductor is a registered trademark of National Semiconductor Corporation. Geode and WebPAD are trademarks of National Semiconductor Corporation. For a complete listing of National Semiconductor trademarks, please visit www.national.com/trademarks. © 2000 National Semiconductor Corporation www.national.com Geode™ CS4210 IEEE 1394 OHCI Controller July 2000 Architectural Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2.0 Signal Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 2.2 3.0 PCI INTERFACE MODULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 DMA ENGINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1 Transfer Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.2 Host Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.3 ATDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.4 ITDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.5 RDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 TRANSMIT DRAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 RECEIVE FILL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 LINK LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 PHYSICAL LAYER INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 REGISTER SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 RELATED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 te 1.0 PIN ASSIGNMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 SIGNAL DESCRIPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 PCI Bus Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 PHY-Link Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.3 Miscellaneous Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.4 Power Supplies and Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 ol e Geode™ CS4210 Table of Contents Operational Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Asynchronous Data Transfer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.2 Isochronous Data Transfer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.3 Miscellaneous Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 SOFTWARE INTERFACE OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 DMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 bs 3.1 3.2 3.2.2.1 3.2.2.2 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 O 3.2.3 3.2.3.1 3.2.3.2 3.2.3.3 3.3 www.national.com Asynchronous Transmit Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Asynchronous Receive Interrupts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Isoch Tx and Rx Context Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 COMMON DMA CONTROLLER FEATURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1 Context Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2 ContextControl.event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2.1 3.3.2.2 3.3.2.3 3.3.2.4 3.3.2.5 3.4 DMA Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Physical Response DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ContextControl.run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ContextControl.wake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ContextControl.active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ContextControl.dead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 CommandPtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 LIST MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.1 Context Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.2 Appending to Running List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.3 Stopping a Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.4 Hardware Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2 Revision 1.0 3.6 3.7 ASYNCHRONOUS RECEIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5.1 Unrecoverable Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5.2 Ack Codes for Write Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5.3 Posted Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5.4 Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5.5 DMA Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 PHYSICAL REQUESTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6.1 Filtering Physical Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6.2 Posted Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6.3 Physical Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6.4 Physical Response Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6.5 Interrupt Considerations for Physical Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6.6 Bus Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 HOST BUS ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7.1 Causes of Host Bus Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7.2 CS4210 Actions When Host Bus Error Occurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 te 3.5 3.7.2.1 3.7.2.2 3.7.2.3 3.9 4.0 ol e 3.7.3 Isochronous Transmit Data Write Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.4 Asynchronous Receive DMA Data Write Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.5 Isochronous Receive Data Write Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.6 Physical Read Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.7 Posted Write Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 BUS RESETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8.1 Asynchronous Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8.2 Asynchronous Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8.3 Isochronous Transmit and Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 SERIAL EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.9.1 Serial EEPROM Cyclic Redundancy Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 bs 3.8 Descriptor Read Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 xferStatus Write Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Transmit Data Read Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Register Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 PCI CONFIGURATION SPACE ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 REGISTER SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 PCI CONFIGURATION REGISTERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 OHCI CONFIGURATION REGISTERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.1 Version Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.2 GUIDROM Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.3 ATRetries Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Autonomous CSR Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.5 Configuration ROM Header Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.6 Bus Identification Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.7 Bus Options Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.8 Global Unique ID Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.9 Configuration ROM Mapping Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.10 PostedWriteAddress Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.11 Vendor ID Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.12 HCControl Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 O 4.1 4.2 4.3 4.4 4.4.12.1 noByteSwapData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.12.2 programPhyEnable and aPhyEnhanceEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.12.3 LPS and linkEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Revision 1.0 3 www.national.com Geode™ CS4210 Table of Contents (Continued) 4.4.13 4.4.14 4.4.15 4.4.16 Self-ID Buffer Pointer Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Self-ID Count Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 IRMultiChanMask Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.16.1 4.4.16.2 4.4.16.3 4.4.16.4 4.4.16.5 4.4.16.6 4.4.16.7 4.4.17 4.4.18 4.4.19 4.4.20 4.4.21 4.4.22 4.4.23 4.4.24 Fairness Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 LinkControl Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Node ID and Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 PHYControl Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 IsochCycleTimer Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Asynchronous Request Filter Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Physical Request Filter Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Asynchronous Request/Response Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Asynchronous Request/Response Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.4.25.1 4.4.25.2 4.4.25.3 4.4.25.4 4.4.26 Async Request Transmit Context Control Register. . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Async Request Transmit Command Pointer Register. . . . . . . . . . . . . . . . . . . . . . . . . 80 Async Response Transmit Context Control Register . . . . . . . . . . . . . . . . . . . . . . . . . 81 Async Response Transmit Command Pointer Register . . . . . . . . . . . . . . . . . . . . . . . 81 ol e 4.4.24.1 4.4.24.2 4.4.24.3 4.4.24.4 4.4.25 IntEvent Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Bus Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 IntMask Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 IsochTxIntEvent Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 IsochTxIntMask Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 IsochRxIntEvent Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 IsochRxIntMask Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 te Geode™ CS4210 Table of Contents (Continued) Async Request Receive Context Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Async Request Receive Command Pointer Register . . . . . . . . . . . . . . . . . . . . . . . . . 82 Async Response Receive Context Control Register . . . . . . . . . . . . . . . . . . . . . . . . . 83 Async Response Receive Command Pointer Register. . . . . . . . . . . . . . . . . . . . . . . . 83 Isochronous Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 bs 4.4.26.1 Isoch Transmit Context Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.4.26.2 Isoch Transmit Command Pointer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.4.27 Isochronous Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.27.1 Isoch Receive Context Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.27.2 Isoch Receive Command Pointer Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.4.27.3 Isoch Receive Context Match Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 NATIONAL (NSC) SPECIFIC CONFIGURATION REGISTERS . . . . . . . . . . . . . . . . . . . . . . . 89 4.5.1 nscControl Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.5.2 nscEventSet/Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.5.3 nscMaskSet/Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.5.4 nscRAMBist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.5.5 nscCmcControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.5.6 nscTxThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.5.7 nscSubSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.5.8 nscPhysReadCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.9 nscPhysWriteCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.10 nscPhysLockCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.11 nscBusmgrID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.5.12 nscBandwAvail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.5.13 nscChanAvailHi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.5.14 nscChanAvailLo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 O 4.5 www.national.com 4 Revision 1.0 5.0 Electrical Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.1 5.2 5.3 5.4 5.5 Physical Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 O bs ol e te 6.0 NAND TREE TEST MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 ABSOLUTE MAXIMUM RATINGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 OPERATING CONDITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 DC CHARACTERISTICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 AC SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Revision 1.0 5 www.national.com Geode™ CS4210 Table of Contents (Continued) Geode™ CS4210 1.0 Architectural Description The CS4210 device implements an IEEE 1394 serial bus host controller as specified by the OHCI Specification Version 1.0. It is organized as a collection of reusable modules as illustrated in Figure 1-1. • TE: Transfer Engine — Provides generic data movement services to the rest of the DMA engine logic. • The interface to the 1394 bus is organized into three clock domains: PCI, SCLK, and SCLK/2. The PCI clock domain can operate at up to 33 MHz. The PCI clock can also be stopped. The SCLK clock domain operates at 49.152 MHz. The SCLK/2 clock domain operates at 24.576 MHz. 1.1 • ITDMA: Isochronous Transmit DMA — Controls the transmission of all isochronous packets. • RDMA: Receive DMA — Processes all received packets (asynchronous, isochronous and physical) and transmit status. PCI INTERFACE MODULE The PCI interface module provides a full function bus mastering interface to the PCI bus. 1.2 A single port SRAM is shared by the DMA logic for caching control information and descriptor blocks fetched from the host memory. This RAM is used for capturing entire descriptor blocks in a single PCI bus tenure. DMA ENGINE te The DMA engine is decomposed into four functional modules: ol e PCI Interface FM_Bus (Master) FM_Bus (Slave) Arbiter DMA Engine Register Set RDMA O bs I2C Bus ATDMA: Asynchronous Transmit DMA — Controls the transmission of all asynchronous packets. ITDMA ATDMA Tx FIFO (SRAM) Tx FIFO (SRAM) AR IR Phys Scratchpad (SRAM) Tx Drain Clock Generator and Power Management TE Rx FIFO (SRAM) Rx Fill Link Layer Physical Layer Interface (49.152 MHz) SCLK LNKON LPS LREQ DATA[0:7] CTRL[0:1] DIRECT Figure 1-1. Functional Block Diagram www.national.com 6 Revision 1.0 1.3 1.2.1 Transfer Engine The transfer engine performs data movement between different sources/sinks: 1) Host memory (TxFIFOs/RxFIFO, Scratchpad SRAM) 2) DMA modules (ATDMA, ITDMA, or RDMA) TRANSMIT DRAIN The transmit drain module accepts packets from the TxFIFOs (asynchronous and isochronous) and interfaces with the link layer module to transmit these packets. It also places transmit completion status in the TxFIFO. 1.4 All byte alignment and byte swapping tasks are also performed by the transfer engine. RECEIVE FILL The receive fill module accepts packets from the link layer and places them into the RxFIFO. It performs packet filtering and routing. It also determines which handshake, if any, to return for each received packet. 1.2.2 Host Memory Organization The 1394 OHCI specification allows for many different data FIFO implementations. This CS4210 implements two transmit FIFOs (asynchronous and isochronous) and a single receive FIFO. The transmit FIFOs share a single embedded dual-port SRAM (36x1024). The receive FIFO uses a single embedded dual-port SRAM (36x1024). A small transmit FIFO is also implemented using latches and some decoding logic. 1.5 LINK LAYER te The link layer module implements a 1394 link layer function developed for this host controller application. It includes support for the CRC32 generation/checking, link state machine, transmit/receive data paths and the generation/ reception of cycle start packets. This module includes support for features defined in the P1394a supplement. All FIFOs may be tested using an embedded RAM BIST controller. See Section 4.5.4 "nscRAMBist" on page 94 for more details. PHYSICAL LAYER INTERFACE ol e 1.6 The physical layer interface module implements the external interface to connect to the Geode CS4103 P1394a physical layer device. It includes support for features defined in revision 2.0 of the P1394a specification. 1.2.3 ATDMA The ATDMA module controls the transmission of all asynchronous packets. This includes AT (Asynchronous Transmit) Request context packets, AT Response context packets and all physical DMA transmit request and response packets. The ATDMA module also controls retransmission of packets as required by the OHCI specification. 1.7 bs 1.2.4 ITDMA The ITDMA module controls the transmission of all isochronous packets. Annex E of the OHCI specification describes the operation of the ITDMA module. This annex was contributed by National Semiconductor. O 1.2.5 RDMA The RDMA module processes all received packets and transmit status. This includes packets destined for the AR (Asynchronous Receive) Request context, AR Response context, all IR (Isochronous Receive) contexts, the Self-ID buffer, and all physical DMA requests (including CSR accesses). It also examines the transmit status to manage the collection of currently active physical DMA requests. Revision 1.0 REGISTER SET The register set module coordinates slave accesses to the host controller registers. It fields read/write requests from the PCI interface module. It can also read configuration data from a serial EEPROM device via an I2C interface. 1.8 RELATED DOCUMENTS The following documents may be useful in understanding the terms and concepts used in this publication. • 1394 Open Host Controller Interface Specification Release 1.0 • IEEE 1394-1995 High Performance Serial Bus, 1995 • ISO/IEC 13213:1994 Control and Status Register Architecture for Microcomputer Buses International Standards Organization, 1994 • IEEE P1394a Standard for a High Performance Serial bus (Supplement) 7 www.national.com Geode™ CS4210 Architectural Description (Continued) Geode™ CS4210 2.0 Signal Definitions Table 2-1. Pin Type Definitions This section defines the signals and external interface of the CS4210. Figure 2-1 shows the pins organized by their functional groupings (internal test and electrical pins are not shown). 2.1 Mnemonic I PIN ASSIGNMENT The tables in this section use several common abbreviations. Table 2-1 lists the mnemonics and their meanings. Input Pin I/O Bidirectional Pin O Output t/s TRI-STATE Signal VDD Figure 2-2 on page 9 shows the pin assignment for the CS4210 with Tables 2-2 and 2-3, on pages 10 and 11, listing the pin assignments sorted by pin number and alphabetically by signal name. Definition VDDIO VSS 2.5V Core Power Supply 3.3V I/O Power Supply Ground Connection DATA[0:7] CTRL[0:1] LREQ SCLK LPS LNKON DIRECT PHY-Link Interface EECLK EEDATA I2C Interface CCLKO CCLKI 8 kHz Reference Clock Interface CMC CMCL Contender Master Control Interface ol e Geode™ CS4210 bs PCI Bus Interface AD[31:0] C/BE[3:0]# FRAME# IRDY# TRDY# STOP# DEVSEL# IDSEL PERR# SERR# PAR PREQ# PGNT# INTA# RST# PCLK PME# te Section 2.2 "Signal Descriptions" starting on page 12 provides a description for each signal within its associated functional group. O Figure 2-1. Signal Groups www.national.com 8 Revision 1.0 Geode™ CS4210 VSS AD0 AD1 AD2 AD3 VDD AD4 AD5 AD6 AD7 C/BE0# AD8 VDDIO AD9 AD10 VSS AD11 AD12 AD13 AD14 VDD AD15 C/BE1# PAR SERR# te 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 Geode™ CS4210 Top View ol e 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 bs AD25 AD24 C/BE3# IDSEL VSS AD23 AD22 AD21 AD20 VDD AD19 AD18 AD17 VDDIO AD16 C/BE2# VSS FRAME# IRDY# TRDY# VDD DEVSEL# STOP# PERR# VSS 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 VSS CMC CMCL EECLK EEDATA VDDIO TESTO INTA# VDD RST# VSS PCLK VDD PGNT# PREQ# VDDIO PME# AD31 AD30 VDD AD29 AD28 AD27 VSS AD26 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 VSS LPS LNKON LREQ VDD SCLK VSS CTRL0 CTRL1 VDD DATA0 DATA1 DATA2 VDDIO DATA3 DATA4 DATA5 VSS DATA6 DATA7 VDD DIRECT CCLKI CCLKO TESTEN# Signal Definitions (Continued) O Figure 2-2. Pin Assignment Diagram Order Number: CS4210VJG Revision 1.0 9 www.national.com Table 2-2. Pin Assignment - Sorted by Pin Number Pin No. Signal Type Pin No. Signal Type Pin No. Signal Type VSS GND 35 VDD PWR 69 AD4 I/O 2 CMC O 36 AD19 I/O 70 VDD PWR 3 CMCL O 37 AD18 I/O 71 AD3 I/O 4 EECLK O 38 AD17 I/O 72 AD2 I/O 5 EEDATA I 39 VDDIO PWR 73 AD1 I/O 6 VDDIO PWR 40 AD16 I/O 74 AD0 I/O 7 TESTO O 41 C/BE2# I/O 75 VSS GND 8 INTA# O 42 VSS GND 76 TESTEN# I 9 VDD PWR 43 FRAME# I/O 77 CCLKO O 10 RST# O 44 IRDY# I/O 78 CCLKI I 11 VSS GND 45 TRDY# I/O 79 DIRECT I 12 PCLK I 46 VDD PWR 80 VDD 13 VDD PWR 47 DEVSEL# I/O 81 DATA7 I/O 14 PGNT# I I/O 15 PREQ# 16 ol e te 1 PWR STOP# I/O 82 DATA6 O 49 PERR# I/O 83 VSS VDDIO PWR 50 VSS GND 84 DATA5 I/O 17 PME# O 51 SERR# I/O 85 DATA4 I/O 18 AD31 I/O 52 PAR I/O 86 DATA3 I/O 19 AD30 I/O 53 C/BE1# I/O 87 VDDIO PWR 20 VDD PWR 54 AD15 I/O 88 DATA2 I/O 21 AD29 I/O 55 VDD PWR 89 DATA1 I/O 22 AD28 I/O 56 AD14 I/O 90 DATA0 I/O 23 AD27 I/O 57 AD13 I/O 91 VDD 24 VSS GND 58 AD12 I/O 92 CTRL1 I/O 25 AD26 I/O 59 AD11 I/O 93 CTRL0 I/O 26 AD25 I/O 60 VSS GND 94 VSS 27 AD24 I/O 61 AD10 I/O 95 SCLK I 28 C/BE3# I/O 62 AD9 I/O 96 VDD PWR 29 IDSEL I 63 VDDIO PWR 97 LREQ O 30 VSS GND 64 AD8 I/O 98 LNKON I 31 AD23 I/O 65 C/BE0# I/O 99 LPS O 32 AD22 I/O 66 AD7 I/O 100 VSS GND 33 AD21 I/O 67 AD6 I/O 34 AD20 I/O 68 AD5 I/O bs 48 O Geode™ CS4210 Signal Definitions (Continued) www.national.com 10 GND PWR GND Revision 1.0 Table 2-3. Pin Assignment - Sorted Alphabetically Type Pin No. C/BE2# I/O 41 SCLK 73 C/BE3# I/O 28 I/O 61 CCLKI I AD11 I/O 59 CCLKO AD12 I/O 58 AD13 I/O AD14 Type Pin No. I 95 SERR# I/O 51 78 STOP# I/O 48 O 77 TESTEN# I 76 CMC O 2 TESTO O 7 57 CMCL O 3 TRDY# I/O 45 I/O 56 CTRL0 I/O 93 VDD PWR 9 AD15 I/O 54 CTRL1 I/O 92 VDD PWR 13 AD16 I/O 40 DATA0 I/O 90 VDD PWR 20 AD17 I/O 38 DATA1 I/O 89 VDD PWR 35 AD18 I/O 37 DATA2 I/O 88 VDD PWR 46 AD19 I/O 36 DATA3 I/O 86 VDD PWR 55 AD2 I/O 72 DATA4 I/O 85 VDD PWR 70 AD20 I/O 34 DATA5 I/O 84 VDD PWR 80 AD21 I/O 33 DATA6 I/O 82 VDD PWR 91 AD22 I/O 32 DATA7 I/O 81 VDD PWR 96 AD23 I/O 31 DEVSEL# I/O 47 VDDIO PWR 6 AD24 I/O 27 DIRECT I 79 VDDIO PWR 16 AD25 I/O 26 EECLK O 4 VDDIO PWR 39 AD26 I/O 25 EEDATA I 5 VDDIO PWR 63 I/O 43 VDDIO PWR 87 AD0 I/O 74 AD1 I/O AD10 bs AD27 Signal Signal te Pin No. ol e Type Signal I/O 23 FRAME# I/O 22 IDSEL I 29 VSS GND 1 I/O 21 INTA# O 8 VSS GND 11 I/O 71 IRDY# I/O 44 VSS GND 24 I/O 19 LNKON I 98 VSS GND 30 I/O 18 LPS O 99 VSS GND 42 AD4 I/O 69 LREQ O 97 VSS GND 50 AD5 I/O 68 PAR I/O 52 VSS GND 60 AD6 I/O 67 PCLK I 12 VSS GND 75 AD7 I/O 66 PERR# I/O 49 VSS GND 83 AD8 I/O 64 PGNT# I 14 VSS GND 94 AD9 I/O 62 PME# O 17 VSS GND 100 C/BE0# I/O 65 PREQ# O 15 C/BE1# I/O 53 RST# O 10 AD28 AD29 AD3 AD30 O AD31 Revision 1.0 11 www.national.com Geode™ CS4210 Signal Definitions (Continued) Geode™ CS4210 Signal Definitions (Continued) 2.2 SIGNAL DESCRIPTIONS 2.2.1 PCI Bus Interface Signals Signal Name AD[31:0] Pin No. Type Refer to Table 2-3 I/O Description Multiplexed Address and Data AD[31:0] is a physical address during the first clock of a PCI transaction; it is the data during subsequent clocks. When the CS4210 is a PCI master, AD[31:0] are outputs during the address and write data phases, and are inputs during the read data phase of a transaction. C/BE[3:0]# FRAME# 65, 53, 41, 28 I/O 43 I/O te When the CS4210 is a PCI slave, AD[31:0] are inputs during the address and write data phases, and are outputs during the read data phase of a transaction. Bus Command and Byte Enables Multiplexed bus command and byte enables. Cycle Frame Driven by the initiator to indicate the beginning and duration of an access. 44 I/O Initiator Ready ol e IRDY# Indicates that the initiator is ready to complete the current data phase of the transaction. TRDY# 45 I/O Target Ready Indicates that the current data phase of the transaction is ready to be completed. STOP# 48 I/O Stop bs Indicates that the current target is requesting the initiator to stop the current transaction. DEVSEL# 47 I/O Device Select When actively driven, DEVSEL# indicates the driving device has decoded its address as the target of the current access. IDSEL 29 I Initialization Device Select Used as a chip select during configuration read and write transactions. 49 O PERR# SERR# PAR 51 52 I/O Parity Error Used for reporting data parity errors during all PCI transactions except a Special Cycle. I/O System Error Used for reporting address parity errors, data parity errors on the Special Cycle command, or any other system error where the result will be catastrophic. I/O Parity PAR is even parity across AD[31:0] and C/BE[3:0]. PAR is an input when AD[31:0] are inputs and is an output when AD[31:0] are outputs. PREQ# 15 O PCI Bus Request PCI bus request to PCI bus arbiter. PGNT# 14 I PCI Bus Grant PCI bus grant from PCI bus arbiter. INTA# 8 O Interrupt A 1394 OpenHCI PCI interrupt. www.national.com 12 Revision 1.0 Geode™ CS4210 Signal Definitions (Continued) 2.2.1 PCI Bus Interface Signals (Continued) Signal Name RST# Pin No. Type 10 I Description PCI Reset RST# is driven low to reset the device. PCLK 12 I Clock 0-33 MHz PCI clock. PME# 17 O Power Management Event PCI power management pin as defined in the PCI Bus Power Management Specification Revision 1.1. Signal Name DATA[0:7] Pin No. I/O Description 81, 82, 84, 85, 86, 88, 89, 90 I/O PHY Data Bidirectional data lines driven by both the Link and PHY layer modules. The width of the data bus depends on the speed of data transfer rate. Packet rate for 100 Mbit/sec transfers use DATA[0:1], 200 Mbit/sec transfers use DATA[0:3], 400 Mbit/sec transfers use DATA[0:7]. Note: CTRL[0:1] 93, 92 te PHY-Link Interface Signals ol e 2.2.2 I/O DATA0 is considered the MSB (most significant bit) based upon the IEEE 1394-1995 specification. Control bits 1 and 0 LREQ bs Bidirectional handshaking signals driven by both the Link and PHY layer modules. The CS4210 and CS4103 use these signals to arbitrate the control of the PHY-Link interface. The control bits also indicate the type of transfer communicating between the two layers namely idle, status, receive, and transmit. 97 O Link Request Used by the CS4210 to request access of the 1394 bus and to read/write the internal registers of the CS4103. 95 O SCLK LPS LNKON 99 98 I Sync Clock The 49.152 MHz clock input driven by the CS4103’s PLL block synchronized to the 1394 bus clock. This clock is also used to synchronize the LREQ, CTRL[0:1], and DATA[0:7] communication protocol between the CS4210 and CS4103. O Link Power Status Indicates the power status of the CS4210. If LPS is low indicating the CS4210 is not powered, the signals CTRL[0:1], DATA[0:7], and SCLK connected to the CS4210 are disabled. I Link On Indicates to the CS4210 that the CS4103 has received a Link-On packet addressed to this node. DIRECT 79 I Direct High indicates direct connection. Low indicates isolation barrier. Set high when using the single capacitor bus hold isolation. Revision 1.0 13 www.national.com Geode™ CS4210 Signal Definitions (Continued) 2.2.3 Miscellaneous Interface Signals Signal Name EECLK Pin No. Type 4 O Description Serial EEPROM Clock The I2C bus clock signal. EEDATA 5 I Serial EEPROM Data The I2C data signal. CCLKO 77 O Cycle Clock Output The 8 kHz reference clock output. CCLKI 78 I Cycle Clock Input CMC 2 O te The 8 kHz reference clock input. Contender Master Control This output is set via the nscCMCControl.CMC bit (BAR1+Offset 18h[0]). The value placed on the bit is directly reflected on this pin. CMCL 3 O Contender Master Control Link Enabled TESTO 7 ol e This output is set via the nscCMCControl.CMCL bit (BAR1+Offset 18h[1]). The value of the bit is reflected on the output when HCControl.linkEnable (BAR0+Offset 50h[17]) is set. Otherwise it is 0. O Test Out National internal test pin, user must float. TESTEN# 76 I Test Enable 2.2.4 bs National internal test pin, user must tie high. Power Supplies and Ground Connections Signal Name VDD VDDIO Type Description 9, 13, 20, 35, 46, 55, 70, 80, 91, 96 PWR 2.5V Core Power Supply Connections (Total of 10) 6, 16, 39, 63, 87 PWR 3.3V I/O Power Supply Connections (Total of 5) 1, 11, 24, 30, 42, 50, 60, 75, 83, 94, 100 GND Ground Connections (Total of 11) O VSS Pin No. www.national.com 14 Revision 1.0 3.1 Operational Description OVERVIEW The CS4210 is an implementation of the link layer protocol of the 1394 serial bus, with additional features to support the transaction and bus management layers. The CS4210 also includes DMA engines for high-performance data transfer and a PCI host bus interface. IEEE 1394 serial bus (and 1394 OpenHCI) protocols support two types of data transfer: asynchronous and isochronous. nous receive. The CS4210 provides eight isochronous transmit contexts. The isochronous transmit DMA controller can transmit from each context during each cycle. Each context can transmit data for a single isochronous channel. The CS4210 provides eight isochronous receive contexts. The isochronous receive DMA controller can receive data for each context during each cycle. Each context can be configured to receive data from a single isochronous channel. Additionally, one context can be configured to receive data from multiple isochronous channels (see bit 28, multiChanMode, in Table 4-53 on page 87 for programming details). • Asynchronous data transfer puts the emphasis on guaranteed delivery of data, with less emphasis on guaranteed timing. ol e 3.1.1 Asynchronous Data Transfer Functions The CS4210 can transmit and receive all of the defined 1394 packet formats. Packets to be transmitted are read out of host memory and received packets are written into host memory, both using DMA. The CS4210 can also be programmed to act as a bus bridge between the host bus and 1394 devices by directly executing 1394 read and write requests as reads and writes to the host bus memory space. 3.1.3 Miscellaneous Functions Upon detecting a bus reset, the CS4210 automatically flushes all packets queued for asynchronous transmission. Asynchronous packet reception continues without interruption, and a token appears in the received request packet stream to indicate the occurrence of the bus reset. When the CS4103 provides the new local node ID, the CS4210 loads this value into its Node ID register, see Table 3-1. Asynchronous packet transmit will not resume until directed to by software. Because target node ID values may have changed during the bus reset, software will not generally be able to re-issue old asynchronous requests until software has determined the new target node IDs. Isochronous transmit and receive functions are not halted by a bus reset, instead they restart as soon as the bus initialization process is complete. A number of management functions are also implemented by the CS4210. A global unique ID register, shown in Table 3-2, can only be written once. For full compliance with higher level standards, this register must be written before the boot block is read. To make this implementation simpler, the CS4210 has an interface to an external serial I2C EEPROM such as the Fairchild Semiconductor NM24C02. The CS4210 also supports four registers that implement the compare-swap operation needed for isochronous resource management. te • Isochronous data transfer is the opposite, with the emphasis on the guaranteed timing of the data, and less emphasis on delivery. bs 3.1.2 Isochronous Data Transfer Functions The CS4210 is capable of performing the cycle master function as defined by the IEEE 1394 OHCI specification. This means it contains a cycle timer and counter, and can queue the transmission of a special packet called a “cycle start” after every rising edge of the 8 kHz cycle clock. The CS4210 can generate the cycle clock internally or use an external reference connected to the CCLKI input (pin 78). When not the cycle master, the CS4210 keeps its internal cycle timer synchronized with the cycle master node by correcting its own cycle timer with the reload value from the cycle start packet. Conceptually, the CS4210 supports one DMA controller each for isochronous transmit and isochro- O Table 3-1. BAR0+Offset E8h: Note ID and Status Register Map RSVD CPS root iDValid 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 RSVD 9 8 7 6 5 busNumber 4 3 2 1 0 nodeNumber Table 3-2. GUID Register Map 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 BAR0+Offset 24h-27h BAR0+Offset 28h-2Bh 9 8 7 6 5 4 3 2 1 0 GUIDHi Register GUIDLo Register node_vendor_ID chip_ID_Hi chip_ID_Lo Revision 1.0 15 www.national.com Geode™ CS4210 3.0 Geode™ CS4210 Operational Description (Continued) 3.2 SOFTWARE INTERFACE OVERVIEW sources which correspond to each DMA context completion, there is also a set of interrupts which correspond to other CS4210 functions/units. For example, one of these interrupts could be sent when a Self-ID packet stream has been received. The processor interrupt line is controlled by the IntEvent and IntMask registers. The IntEvent register indicates which interrupt events have occurred, and the IntMask register is used to enable selected interrupts. Software writes to the IntEventClear register to clear interrupt conditions in IntEvent. In addition, there are registers used by the isochronous transmit and isochronous receive controllers to indicate interrupt conditions for each context. There are three basic means by which software communicates with the CS4210: registers, DMA, and interrupts. 3.2.1 Registers The host architecture (PCI, for example) is responsible for mapping the CS4210’s registers into a portion of the host’s address space. 3.2.2 DMA Operation DMA transfers in the CS4210 are accomplished through one of two methods: DMA memory and physical response DMA. Table 3-3 shows a map of the IntEvent and IntMask Set/ Clear registers. Refer to Section 4.4.16.1 "IntEvent Register" on page 70 and Section 4.4.16.3 "IntMask Register" on page 72 for further information details. te 3.2.2.1 DMA Memory DMA memory resident data structures are used to describe lists of data buffers. The CS4210 automatically sequences through this buffer descriptor list. This data structure also contains status information regarding the transfers. Upon completion of each data transfer, the DMA controller conditionally updates the corresponding DMA context command and conditionally interrupts the processor so it can observe the status of the transaction. A set of registers within the CS4210 is used to initialize each DMA context and to perform control actions such as starting the transfer. ol e 3.2.3.1 Asynchronous Transmit Interrupts Each asynchronous DMA context has one interrupt indication bit in the IntEvent register. For requests, it is the reqTxComplete bit and for responses it is the respTxComplete bit. This interrupt indication bit is set to one if a completed OUTPUT_LAST command has the “i” field set to 11b, or if the “i” field is set to 01b and transmission of the packet did not yield an ack_complete or an ack_pending. bs 3.2.2.2 Physical Response DMA The CS4210 can be programmed to accept 1394 read and write transactions as reads and writes to host memory space. In this mode, the CS4210 acts as a bus bridge from the 1394 bus into host memory. The formats for the data sent and received in all these modes are specified in the 1394 Open Host Controller Interface Specification Release 1.00. 3.2.3 Interrupts When any DMA transfer completes (or aborts), an interrupt may be sent to the host system. In addition to the interrupt 3.2.3.2 Asynchronous Receive Interrupts There are two interrupts for each context (request and response) that software can use to gauge the usage of the receive buffers. If software needs to be informed of the arrival of each packet being sent to the context buffers, it can use the RQPkt or RSPkt interrupts in the IntEvent register. If software needs to be informed of the completion of a buffer, it can set the descriptor i field to 11b, which triggers either the ARRQ or ARRS interrupt in the IntEvent register. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 7 6 5 4 3 2 1 0 ARRS ARRS reqTxComplete RQPkt RQPkt reqTxComplete RSPkt RSPkt ARRQ isochTx isochTx respTxComplete isochRx isochRx ARRQ postedWriteErr postedWriteErr respTxComplete lockRespErr selfIDcomplete busReset RSVD phy cycleSynch cycle64Seconds RSVD selfIDcomplete busReset RSVD phy cycleSynch cycle64Seconds cycleLost cycleInconsistent phyRegRcvd RSVD unrecoverableError IntMask Set Register IntMask Clear Register cycleTooLong masterIntEnable BAR0+Offset 88h BAR0+Offset 8Ch www.national.com 8 IntEvent Set Register IntEvent Clear Register cycleLost cycleInconsistent phyRegRcvd cycleTooLong RSVD unrecoverableError BAR0+Offset 80h BAR0+Offset 84h 9 lockRespErr O Table 3-3. IntEvent and IntMask Register Map 16 RSVD Revision 1.0 3.2.3.3 Isoch Tx and Rx Context Interrupts Each of the eight implemented isochronous transmit and each of the eight implemented isochronous receive contexts can generate an interrupt. Software can enable interrupts on a per-context basis by setting the corresponding IsochTxnContextIntMask or IsochRxnContextIntMask bit to one. To efficiently handle interrupts which could conceivably be generated from eight different contexts in close proximity to one another, there is a single bit for all IT DMA contexts and another for all IR DMA contexts in the CS4210 IntEvent register. These bits signify that at least one but potentially several IT or IR DMA contexts attempted to generate an interrupt. Software can read the isochTxIntEvent register to find out which isochronous transmit context(s) are involved. Software can read the Iso- chRxIntEvent register to find out which isochronous receive context(s) are involved. Table 3-4 shows a map of the IsochTx/Rx Context Interrupt Event and Mask Set/Clear registers. Refer to Section 4.4.16.4 on page 73 through Section 4.4.16.7 on page 74 for further register information. te The number of supported isochronous DMA contexts varies for 1394 OHCI implementations from a minimum of four to a maximum of 32. Software can determine the number of supported IT or IR DMA contexts by writing FFFF_FFFFh to IsochTxIntMask register for IT and IsochRxIntMask register for IR, and then reading it back. Bits returned as 1’s indicate supported contexts, and bits returned as 0’s indicate unsupported/unimplemented contexts. Table 3-4. IsochTx and IsochRx Context Interrupt Related Registers 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 5 4 3 2 1 0 isochTxInt0 isochTxInt1 isochTxInt2 isochTxInt3 isochTxInt4 isochTxInt5 isochTxInt6 isochTxInt7 isochTxIntMask0 isochTxIntMask1 isochTxIntMask2 isochTxIntMask3 isochTxIntMask4 isochTxIntMask5 isochTxIntMask6 isochRxInt7 isochRxInt6 isochRxInt5 isochRxInt4 isochRxInt3 isochRxInt2 isochRxInt1 isochRxInt0 isochRxIntMask7 isochRxIntMask6 isochRxIntMask5 isochRxIntMask4 isochRxIntMask3 isochRxIntMask2 isochRxIntMask1 isochRxIntMask0 IsochRxIntEvent Set Register IsochRxIntEvent Clear Register RSVD O isochTxIntMask7 bs BAR0+Offset A0h BAR0+Offset A4h Revision 1.0 6 IsochTxIntMask Set Register IsochTxIntMask Clear Register RSVD BAR0+Offset A8h BAR0+Offset ACh 7 IsochTxIntEvent Set Register IsochTxIntEvent Clear Register RSVD BAR0+Offset 98h BAR0+Offset 9Ch 8 ol e BAR0+Offset 90h BAR0+Offset 94h 9 IsochRxIntMaskSet Register IsochRxIntMaskClear Register RSVD 17 www.national.com Geode™ CS4210 Operational Description (Continued) Geode™ CS4210 Operational Description (Continued) When the IntEvent.cycleInconsistent condition occurs, the IT and IR DMA controllers continue processing running contexts normally, except that contexts with the ContextControl.cycleMatchEnable bit set remain inactive and cycleMatch processing is, in effect, disabled. To re-enable cycleMatch processing, software must first stop the IT and/ or IR contexts for which cycleMatch is enabled (by clearing ContextControl.run and waiting for ContextControl.active to clear, then clearing the IntEvent.cycleInconsistent interrupt (read BAR0+Offset 84h[23]). The stopped IR contexts may then be started. The stopped IT contexts may also be started, but software should not schedule any transmits to occur for these contexts for at least two cycles immediately following the clearing of the interrupt condition. Table 3-5 is a register format for the eight Isochronous Transmit Context Control Set/Clear registers. Refer to Section 4.4.26.1 "Isoch Transmit Context Control Register" on page 84 for further register information. Table 3-5. IsochTx[7:0]ContextControl Set/Clear Register Formats 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 te event code O bs ol e dead RSVD active RSVD run cycleMatch wake cycleMatchEnable IsochTxnContextControl Set Register IsochTxnContextControl Clear Register www.national.com 18 Revision 1.0 3.3 COMMON DMA CONTROLLER FEATURES page 80 through Section 4.4.27 for further register information. The CS4210 provides several types of DMA functionality: • General-purpose DMA handling asynchronous transmit and receive packets and isochronous transmit and receive packets. 3.3.2 ContextControl.event The packet event codes shown in Table 3-7 on page 20 are possible values for the five-bit ContextControl.event field. This field may contain either a 1394 defined ack code or an OpenHCI generated event code. Bits [15:0] of the ContextControl register may be written into host memory to indicate packet and/or DMA descriptor status. However, all possible event codes which may appear in a particular context’s ContextControl register may not necessarily ever be written into host memory for a packet or DMA descriptor status, depending on circumstances and the functionality of the context. The list of ack codes provided in Table 3-7 is informative not normative (i.e., for asynchronous packets the event code may be set to any ack code specified in current and future 1394 standards). OpenHCI generated event codes have an “evt_” prefix and are denoted by a code with the high (fifth) bit equal to 0. In some cases for isochronous I/O OpenHCI may generate a 1394 style ack code for ContextControl.event. • An inbound bus bridge function that allows 1394 devices to directly access system memory called “physical DMA.” • A separate write buffer for the received Self-ID packets. • A mapping between a 1 KB block in system memory and the first 1K of configuration ROM. te 3.3.1 Context Registers A context provides the basic information to the CS4210 to allow it to fetch and process descriptors for one of the several DMA controllers. All contexts (except for Self-ID) have a ContextControl register and a CommandPtr register. The format of the ContextControl Registers is DMA controller specific. ol e Table 3-6 is a register format of the Contex.Control and CommandPtr registers. Refer to Section 4.4.24 starting on Table 3-6. ContextControl and CommandPtr Registers Formats 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 bs dead RSVD active run RSVD wake AsyncReqTxContextControl Set/Clear Registers AsyncRespTxContextControl Set/Clear Registers RSVD event code dead RSVD active run RSVD wake AsyncReqRxContextControl Set/Clear Registers AsyncRespRxContextControl Set/Clear Registers RSVD spd event code dead run event code active RSVD wake RSVD IsochRxnContextControl Set/Clear Registers RSVD dead RSVD spd event code active RSVD run multiChanMode CycleMatchEnable bufferFill isochheader O cycleMatch wake cycleMatchEnable IsochTxnContextControl Set/Clear Registers CommandPtr Register descriptorAddress Revision 1.0 19 Z www.national.com Geode™ CS4210 Operational Description (Continued) Table 3-7. Packet Event Codes Code 00h Name evt_no_status DMA AT, AR, IT, IR Description No event status. 001h Reserved -- Reserved 02h evt_long_packet IR The received data length was greater than the buffer’s data_length. 03h evt_missing_ack AT A subaction gap was detected before an ack arrived or the received ack had a parity error. 04h evt_underrun 05h evt_overrun 06h evt_descriptor_read 07h evt_data_read AT, IT 08h evt_data_write AR, IR, IT 09h evt_bus_reset AR Identifies a CS4103 packet in the receive buffer as being the synthesized bus reset packet. (See Section 3.8 "Bus Resets" on page 30.) 0Ah evt_timeout AT Indicates that the asynchronous transmit response packet expired and was not transmitted. evt_tcode_err Reserved 0Eh evt_unknown 0Fh evt_flushed 10h Reserved 11h ack_complete 12h Underrun on the corresponding FIFO. The packet was truncated. A receive FIFO overflowed during the reception of an isochronous packet. An unrecoverable error occurred while the CS4210 was reading a descriptor block. An error occurred while the CS4210 was attempting to read from host memory in the data stage of descriptor processing. te AT, AR, IT, IR AT, IT -- An error occurred while the CS4210 was attempting to write to host memory either in the data stage of descriptor processing (AR, IR), or when processing a single 16-bit host memory write (IT). A bad tCode is associated with this packet. The packet was flushed. Reserved AT, AR, IT, IR An error condition has occurred that cannot be represented by any other event codes defined herein. AT Sent by the link side of the output FIFO when asynchronous packets are being flushed due to a bus reset. --- AT, AR, IT, IR ack_pending AT, AR Reserved for definition by future 1394 standards. For asynchronous request and response packets, this event indicates the destination node has successfully accepted the packet. If the packet was a request subaction, the destination node has successfully completed the transaction and no response subaction follows. The event code for transmitted CS4103, isochronous, asynchronous stream and broadcast packets, none of which yields a 1394 ack code, are set by hardware to ack_complete unless an event occurs. Reserved The destination node has successfully accepted the packet. If the packet was a request subaction, a response subaction follows at a later time. This code is not returned for a response subaction. --- Reserved for definition by future 1394 standards. 14h ack_busy_X AT The packet could not be accepted after max ATRetries (see Section 4.4.3 "ATRetries Register" on page 59) attempts, and the last ack received was ack_busy_X. 15h ack_busy_A AT The packet could not be accepted after max ATRetries (see Section 4.4.3 "ATRetries Register" on page 59) attempts, and the last ack received was ack_busy_A. 16h ack_busy_B AT The packet could not be accepted after max AT Retries (see Section 4.4.3 "ATRetries Register" on page 59) attempts, and the last ack received was ack_busy_B. O 13h IR ol e 0Bh 0Ch-0Dh AT, IT bs Geode™ CS4210 Operational Description (Continued) 17h-1Ah Reserved 1Bh ack_tardy AT The destination node could not accept the packet because the link and higher layers are in a suspended state. 1Ch Reserved --- Reserved for definition by future 1394 standards. 1Dh ack_data_error AT, IR The destination node could not accept the block packet because the data field failed the CRC check, or because the length of the data block payload did not match the length contained in the data_length field. This code is not returned for any packet that does not have a data block payload. 1Eh ack_type_error AT, AR A field in the request packet header was set to an unsupported or incorrect value, or an invalid transaction was attempted (e.g., a write to a read-only address). 1Fh Reserved www.national.com Reserved for definition by future 1394 standards. --- Reserved for definition by future 1394 standards. 20 Revision 1.0 For asynchronous contexts, the CS4210 returns the appropriate ack_busy* code. In addition, the CS4210 “backs out” the packet by not updating the buffer’s byte count (resCount), and flushes the packet from the FIFO. The CS4210 does not go inactive, as there is still buffer space available and software is attempting to provide more buffer space. For both transmit and receive contexts, if the Z value is now non-zero, the CS4210 continues processing. In order to ensure that a wake condition is not missed, the CS4210 clears ContextControl.wake before it reads or rereads a descriptor. ContextControl.wake is ignored when ContextControl.run is zero. te 3.3.2.3 ContextControl.active ContextControl.active is set and cleared only by the CS4210. It is set when the CS4210 receives an indication from software that a valid descriptor is available for processing. This indication occurs as a result of software setting the ContextControl.run or by software setting ContextControl.wake while ContextControl.run is set. There are four cases in which the CS4210 clears ContextControl.active: 1) When a branch is indicated by a descriptor but the Z value of the branch address is 0. 2) When software clears ContextControl.run and the CS4210 has reached a safe stopping point. 3) While ContextControl.dead is set. 4) After a hardware or software reset of the CS4210. bs ol e 3.3.2.1 ContextControl.run The ContextControl.run bit is set by software when the CS4210 is to begin processing descriptors for the context. Before software sets ContextControl.run, ContextControl.active must not be set, and the CommandPtr register for the context must contain a valid descriptor block address and a Z value that is appropriate for the descriptor block address. Software may stop the CS4210 from further processing of a context by clearing ContextControl.run. When a ContextControl.run is cleared, the CS4210 will stop processing of the context in a manner that will not impact the operation of any other context or DMA controller. The CS4210 may require a significant amount of time to safely stop processing for a context but when the CS4210 does stop, it clears ContextControl.active. If software clears a ContextControl.run for an isochronous context while the CS4210 is processing a packet for the context, the CS4210 continues to receive or transmit the packet and update descriptor status. The CS4210 does, however, stop at the conclusion of that packet. If ContextControl.run is cleared for a non-isochronous context, the CS4210 may stop processing at any convenient point as long as the context and descriptors end up in a consistent state (e.g., status updated if a packet was sent and acknowledged). Clearing ContextControl.run may have other side effects that are DMA controller dependent. These effects are described in the subsections of Section 4.4 "OHCI Configuration Registers" starting on page 48 that cover each of the DMA controllers. When software clears ContextControl.run and the CS4210 has stopped, the CS4210 is not necessarily in a state that can be restarted simply by setting ContextControl.run. Software should always ensure that CommandPtr.descriptorAddress and CommandPtr.Z are set to valid values before setting ContextControl.run. O 3.3.2.2 ContextControl.wake When software adds to a list of descriptors for a context, the CS4210 may have already read the descriptor that was at the end of the list before it was updated. The value that the CS4210 read may contain a Z value of zero indicating the end of the descriptor list. The ContextControl.wake bit provides a simple semaphore to the hardware to indicate that the list may have changed since the last time the CS4210 read a descriptor. Therefore, if the CS4210 had fetched a descriptor and the indicated branch address had a Z value of zero, then the CS4210 rereads the pointer value. For transmit contexts and receive contexts in buffer-fill mode (a mode in which a context can receive multiple packets into one data buffer), if the Z value is still zero, then the end of the list was reached and the CS4210 clears ContextControl.active. For receive contexts in buffer-fill mode, if the Z value is still zero on the reread, then the packet cannot be accepted. Revision 1.0 21 Additionally, for the asynchronous transmit contexts (request and response), the CS4210 clears ContextControl.active when a bus reset occurs. When ContextControl.active is cleared and ContextControl.run is already clear, the CS4210 sets the IntEvent bit for the context. This interrupt is the same interrupt that would have been generated by the context if a completed descriptor had indicated that an interrupt should be generated. 3.3.2.4 ContextControl.dead ContextControl.dead is used to indicate a fatal error in processing a descriptor. When ContextControl.dead is set by the CS4210, ContextControl.active is immediately cleared but ContextControl.run remains set. In addition, setting ContextControl.dead causes an unrecoverableError interrupt event and blocks a normal context event interrupt from being set. ContextControl.dead is immediately cleared when software clears ContextControl.run or by either a hardware or software reset of the CS4210. Software can determine the cause of a context going dead by checking the ContextControl.event code. The defined reasons for the CS4210 to set ContextControl.dead are described in Section 3.7 "Host Bus Errors" on page 28. www.national.com Geode™ CS4210 Operational Description (Continued) 3.3.2.5 CommandPtr Software initializes CommandPtr.descriptorAddress to contain the address of the first descriptor block that the CS4210 accesses when software enables the context by setting ContextControl.run. Software also initializes CommandPtr.Z to indicate the number of descriptors in the first descriptor block. Software only writes to this register when both ContextControl.run and ContextControl.active are zero. The CS4210’s behavior when this rule is violated is undefined. Since the CS4210 utilizes the CommandPtr register while processing a context, there is a set of guidelines by which software may safely and deterministically read CommandPtr. These guidelines are based on the ContextControl bits as listed in Table 3-8 (X = don’t care). If ContextControl.run is set and ContextControl.dead is not set, then the contents of CommandPtr are only specified if both ContextControl.active and ContextControl.wake are clear. In this instance, CommandPtr.descriptorAddress contains the address of a descriptor within the last descriptor block that was executed. If ContextControl.run and ContextControl.dead are both set, then descriptorAddress points to a descriptor within the descriptor block in which an unrecoverable error occurred. Except for the case where software initializes CommandPtr, the value of CommandPtr.Z is undefined and Z may contain a value that is implementation dependent. The value of CommandPtr is undefined after a hardware or software reset of the CS4210. When software sets ContextControl.run to 1 and CommandPtr.Z contains an invalid value for the controller and context, or if a Z value is invalid for a fetched descriptor block in a running context, the CS4210: sets ContextControl.dead to 1 and sets ContextControl.event to evt_unknown and will not process any descriptors in that context. te Geode™ CS4210 Operational Description (Continued) Table 3-8. CommandPtr Read Values CommandPtr.descriptor Address Value ol e ContextControl Bits dead active wake 0 0 0 X A descriptor block address. Either last written or last executed. 0 0 1 X Contents unspecified. 1 0 0 0 Refers to the descriptor block that contains the Z = 0 that caused the CS4210 to set active to 0. 1 0 0 1 Contents unspecified. 1 0 1 0 Contents unspecified. 1 0 1 1 Contents unspecified. 1 0 X Points to the descriptor block in which a fatal error occurred. O 1 bs run www.national.com 22 Revision 1.0 3.4 LIST MANAGEMENT 3.5 All contexts use an identical method for controlling the processing of descriptors associated with the context. This presents a uniform interface to controlling software and allows reuse of hardware on the CS4210. Physical Requests - Physical requests, including physical read, physical write, and lock requests to some CSR registers (see Section 4.4.4 "Autonomous CSR Resources" on page 60) are handled directly by the CS4210 and are not made visible to system software. The CS4210 uses a dedicated physical response unit to handle these requests. This unit will not block processing of other transaction types while dealing with physical requests. Section 3.6 "Physical Requests" on page 26 provides details on which requests can be processed as physical. 3.4.1 Context Initialization Software initializes the context by first checking to see that ContextControl.run, ContextControl.active, and ContextControl.dead are all 0. Then, CommandPtr.descriptorAddress is written to point to a valid descriptor block and CommandPtr.Z is set to a value that is consistent with the descriptor block. Then ContextControl.run can be set. te Self-ID Packets - CS4103 packets with the Self-ID format can be received at any time. However, only those packets that are received during the Self-ID phase of bus initialization which immediately follows a bus reset are considered to be Self-ID packets. Others are considered simply to be PHY packets which are handled like asynchronous requests. The CS4210 can be programmed to accept or ignore Self-ID packets. When Self-ID packets are accepted, they are stored in a special memory buffer which has a dedicated controller and context. Because of this special memory buffer, Self-ID packets can never get ‘stuck’ in a FIFO. ol e 3.4.2 Appending to Running List Software may append to a list of descriptors at any time. Software may append either a single descriptor or a linked list of descriptors. When the to-be-appended list is properly formatted, software updates the branch address and Z value of the descriptor that was at the end of the list being processed by the CS4210. When software completes the linking process it must set ContextControl.wake for the context. This ensures that the CS4210 resumes operation if it had previously reached the end of the list and gone inactive. ASYNCHRONOUS RECEIVE The CS4210 accepts 1394 transactions and groups them as follows: bs 3.4.3 Stopping a Context Software can stop a running context by clearing ContextControl.run. The context might not stop immediately. To ensure that the context has stopped, software must wait for ContextControl.active to be cleared by the CS4210. This indicates that the CS4210 has completed all processing associated with the context. O 3.4.4 Hardware Behavior The CS4210 has several DMA controllers each of which has one or more contexts. Each DMA controller is expected to examine each of its contexts on a periodic basis and make operational decisions based on the context state as contained in ContextControl. The DMA controller examines the state of the active, run, wake, and dead bits to govern descriptor processing. This process is executed once each time a context is ‘scheduled’. Scheduling of a context is dependent on the DMA controller. For example, an isochronous transmit context is scheduled once per cycle while an asynchronous request transmit context is only scheduled once per fairness interval. Revision 1.0 23 Asynchronous Responses - When the host system initiates a request through the asynchronous transmit request context, the response is handled by the asynchronous receive response context. The fact that host system software initiates the process and the fact that the CS4210 has a separate context for responses, allows system software to budget for all responses which ensures that the CS4210 always has a place in system memory to store a response when it arrives. In the unlikely event that the CS4210 does not have a place for the response it is allowed to drop the response when it arrives. This causes a split-transaction time-out which is an error condition with which the software is already able to deal. Asynchronous Requests - A request may arrive at the CS4210 at any time. Additionally, a request can be of any size up to the limits imposed by the max_rec field in the Bus_Info_Block (see Section 4.4.7 "Bus Options Register" on page 62). Due to the unpredictable nature of this transaction type, it is impractical for the system software to ensure that there is always sufficient buffer space defined in the asynchronous request receive buffers. If the FIFO which is receiving requests becomes full, all subsequent requests are busied until there is room to receive them. www.national.com Geode™ CS4210 Operational Description (Continued) 3.5.1 Unrecoverable Error If an unrecoverable error occurs when the CS4210 is writing to the AR DMA request buffer, a fail indication is sent to the link side of the FIFO. This indicates that the link side should set its count to zero which will busy further read requests and write requests that are destined for the AR DMA request buffer. If the AR DMA request context has an unrecoverable error, the system side of the FIFO continues to unload the FIFO even though the AR DMA request context is dead. All asynchronous requests that would have been sent to the AR DMA request queue are dropped and no responses for them are sent to the initiating node. Dropping requests destined for the AR DMA request queue is acceptable because: AR DMA read requests are always split transactions (ack_pended), 2) write requests within the physical range have been ack_pended and 3) write requests above the physical range which have been posted (ack_completed) are by definition permitted to fail. te 1) successfully written to the addressed location in physical memory. If posting of physical writes is enabled, then the CS4210 is allowed to return ack_complete to a physical write request with certain restrictions. This CS4210 supports four posted writes. However, for error reporting purposes a posted write is considered pending until the write is actually completed to the offset address. For each pending posted write, there is an error reporting register to hold the request’s source node ID and 48-bit offset address should that posted write fail. If the maximum allowed posted writes are pending, the CS4210 must return either ack_pending or ack_busy* for subsequent posted write request candidates and only return resp_complete when those writes have actually been performed. Read and write requests within the Asynchronous Request FIFO do not pass any posted writes, whether posted in the Physical or Asynchronous Request FIFOs. Within the Physical Request FIFO, read requests may coherently pass posted writes, but write requests and posted writes do not pass other writes posted in the Physical Request FIFO. Physical read and write requests may pass writes posted to the Asynchronous Request FIFO. In conjunction with the ordering rules, the following protocol restrictions are adhered to so that proper ordering and therefore data integrity is maintained. The term “visible side-effect” is used to mean an indirect action caused by a request or response which results in the alteration of the contents or usage of host memory outside the address scope of the request or response. ol e Geode™ CS4210 Operational Description (Continued) bs 3.5.2 Ack Codes for Write Requests For write requests that are handled by the physical request controller, the CS4210 may send an ack_complete before the data is actually written to system memory. For a full description of which requests are candidates for physical requests, refer to Section 3.6 "Physical Requests" on page 26. The ack_code sent for write requests to offsets in the range of 0000_FFFF_FFFFh to FFFE_FFFF_FFFFh when not busied is always ack_complete. The ack_code sent for requests to offsets in the range FFFF_0000_0000h to FFFF_FFFF_FFFFh and for block requests with a non-zero extended tcode is always ack_pending. O 3.5.3 Posted Writes As described above, a write request that is handled by the physical request controller or which is in the address range 0000_FFFF_FFFFh to FFFE_FFFF_FFFFh to be handled by the asynchronous request unit, may generate an ack_complete before the data is actually written to the designated system memory location. These writes are referred to as posted writes. Write requests to the physical memory range of the host may be posted if software has enabled posted writes (see Section 4.4.10 "PostedWriteAddress Register" on page 64). If posting is not enabled, the CS4210 will not return a complete indication (ack_complete or resp_complete) until the data has been www.national.com 24 1) Write requests within the range 0000_FFFF_FFFFh to FFFE_FFFF_FFFFh do not have 1394 visible side effects. 2) Read or write requests within the range 0h to 0_FFFF_FFFEh, whether handled by the Physical Request controller or not, do not have 1394 visible side-effects. 3) Read requests to CSR addresses which are processed autonomously by the CS4210 (Section 4.4.4 "Autonomous CSR Resources" on page 60) do not have 1394 visible side-effects. 4) If an error occurs in writing the posted data packet, the CS4210 sets an interrupt event to notify software and provides information about the failed write in an error reporting register. For more information about error handling of posted writes, refer to Section 3.7.7 "Posted Write Error" on page 29. Revision 1.0 3.5.4 Retries For asynchronous receive, the CS4210 supports dualphase retry for packets that must be busied. For asynchronous transmit, CS4210 supports the single-phase retry protocol. The retry mechanism is managed by hardware and invisible to software. 3.5.5 DMA Summary Table 3-9 is a summary of DMA information for reference purposes. Table 3-9. DMA Summary DMA Contexts Per Context Registers Asynchronous Transmit 1 Request ContextControl CommandPtr reqTxComplete 1 Response ContextControl CommandPtr respTxComplete 1 Request ContextControl CommandPtr ARRQ RQPkt 1 Response ContextControl CommandPtr ARRS RSPkt Isochronous Transmit 8 ContextControl CommandPtr IsochTx IsochTxIntEventn IsochTxIntMaskn Isochronous Receive 8 ContextControl CommandPtr ContextMatch IsochRx IsochRxIntEventn IsochRxIntMaskn Self-ID 1 SelfIDBuffer SelfIDCount SelfIDComplete Buffer-fill Receive Mode DMA Commands te OUTPUT_MORE OUTPUT_MORE-Immediate OUTPUT_LAST OUTPUT_LAST-Immediate Buffer-fill INPUT_MORE Z tcodes 2-8 0, 1, 4, 5, 9, A, E 2, 6, 7, B 1 0, 1, 4, 5, 9, E* 2, 6, 7, B 1-8 A Packet-perbuffer INPUT_MORE INPUT_LAST 1-8 A Buffer-fill INPUT_MORE 1 ol e OUTPUT_MORE OUTPUT_MORE-Immediate OUTPUT_LAST OUTPUT_LAST-Immediate STORE_VALUE N/A O bs Asynchronous Receive Per Context Interrupts Revision 1.0 25 www.national.com Geode™ CS4210 Operational Description (Continued) 3.6 PHYSICAL REQUESTS When a block or quadlet read or write request is received, the CS4210 handles the operation automatically without involving software if the offset address in the request packet header meets a specific set of criteria listed below. Requests that do not meet these criteria are directed to the AR DMA Request context unless otherwise specified. CS4210 registers which are written via physical access to the CS4210 yield unspecified results. The CS4210 checks to see if the offset address in the request packet header is one of the following. If the offset falls within the physical range, then the offset address is used as the memory address for the block or quadlet transaction. Physical range is defined by offsets inclusively between a lower bound of 0h and an upper bound of 0000_FFFF_FFFFh. If the high order 16-bits of the offset address is 0000h, then the lower 32 bits of the offset address are used as the memory address for the block or quadlet transaction. 1) Config ROM header (1st quadlet of the Config ROM) (FFFFF0000400h): Local register is ConfigROMheader (see Section 4.4.5 "Configuration ROM Header Register" on page 61). 2) Bus ID (1st quadlet of the Bus_Info_Block) (FFFFF0000404h): Local register is BusID (see Section 4.4.6 "Bus Identification Register" on page 61). 3) Bus options (2nd quadlet of the Bus_Info_Block) (FFFFF0000408h): Local register is BusOptions (see Section 4.4.7 "Bus Options Register" on page 62). 4) Global unique ID (3rd and 4th quadlets of the Bus_Info_Block) (FFFFF000040Ch and FFFFF0000410h): Local registers are GlobalIDHi and GlobalIDLo (see Section 4.4.8 "Global Unique ID Register" on page 63). 5) Configuration ROM (FFFFF0000414h to FFFFF00007FFh). Mapped by the ConfigROMmapping register to a 1 KB block of system memory (see Section 4.4.9 "Configuration ROM Mapping Register" on page 63) ol e Lock transactions and block transactions with a non-zero extended tcode are not supported in this address space, instead they are diverted to the AR DMA Request context. For read requests, the information needed to formulate the response packet is passed to the Physical Response Unit. Requests are only accepted if the source node ID of the request has a corresponding bit in the Asynchronous Request Filter registers and Physical Request Filter registers (see Section 4.4.23 "Physical Request Filter Registers" on page 79). If the offset address is one of the following addresses, the Physical Request controller directly handles quadlet reads. Other requests shall be sent an ack_type_error. te Geode™ CS4210 Operational Description (Continued) For information about ack codes for write requests, see Section 3.5.2 "Ack Codes for Write Requests" on page 24. bs If the offset address selects one of the following addresses, the physical request unit directly handles quadlet compareswaps and quadlet reads. Other requests are sent an ack_type_error (see Table 3-7 on page 20.) BUS_MANAGER_ID (FFFFF000021Ch): Local register is nscBusmgrID (BAR1+Offset 60h). 2) BANDWIDTH_AVAILABLE (FFFFF0000220h): Local register is nscBandwAvai (BAR1+Offset 64h). 3) CHANNELS_AVAILABLE_HI (FFFFF0000224h): Local register is nscChanAvailHi (BAR1+Offset 68h). 4) CHANNELS_AVAILABLE_LO (FFFFF0000228h): Local register is nscChanAvailLo (BAR1+Offset 6Ch). O 1) www.national.com 26 3.6.1 Filtering Physical Requests Software can control which nodes it receives packets from by utilizing the asynchronous filter registers. There are two registers, one for filtering out all requests from a specified set of nodes (AsynchronousRequestFilter register) and one for filtering out physical requests from a specified set of nodes (PhysicalRequestFilter register). The settings in both registers have a direct impact on how the AR DMA Request context is used (e.g., disabling only physical receives from a node causes all request packets from that node to be routed to the AR DMA Request context). The usage and interrelationship between these registers is described in Section 4.4.22 "Asynchronous Request Filter Registers" on page 78.” Revision 1.0 3.6.2 Posted Writes For write requests handled by the Physical Request controller, the CS4210 may send an ack_complete before the data is actually written to system memory. These writes are referred to as posted writes since posted writes impact the Physical Request controller and the Asynchronous Receive Request DMA context. Further information about posted writes is located in Section 3.5.3 "Posted Writes" on page 24. Information on host bus error handling of posted writes is provided in Section 3.7.7 "Posted Write Error" on page 29.” te 3.6.6 Bus Reset On a bus reset, all pending physical requests (those for which ack_pending was sent) are discarded. Following a bus reset, only physical requests to the autonomous CSR resources (see Section 4.4.4 "Autonomous CSR Resources" on page 60) can be handled immediately. Other physical requests are processed after software initializes the filter registers (see Section 4.4.22 "Asynchronous Request Filter Registers" on page 78 and Section 4.4.23 "Physical Request Filter Registers" on page 79). ol e 3.6.3 Physical Responses The response packet generated for a physical read, nonposted write, and lock request contains the transaction label as it appeared in the request, the destination_ID as provided in the request’s source_ID, and are transmitted at the speed at which the request was received. The source bus ID in the response packet is equal to the destination bus ID from the original request. Note that this is not necessarily the same as the contents of the busNumber field in the Node ID register (BAR0+Offset E8h[15:6]). Unlike AR Response packets, physical responses do not track a SPLIT_TIMEOUT expiration time. 3.6.5 Interrupt Considerations for Physical Requests Physical read request handling does not cause an interrupt to be generated under any circumstances. Physical write requests generate an interrupt when posted write processing yields an error. Lock requests to the serial bus registers generate an interrupt when the CS4210 is unable to deliver a lock response packet. O bs 3.6.4 Physical Response Retries There is a separate nibble-wide MaxPhysRespRetries field in the ATRetries Register (BAR0+Offset 08h[15:11]) that tells the Physical Response Unit how many times to attempt to retry the transmit operation for the response packet when an ack_busy* or ack_data_error is received from the target node. If the retry count expires, the packet is dropped and software is not notified. Refer to Section 4.4.3 "ATRetries Register" on page 59 for register details. Revision 1.0 27 www.national.com Geode™ CS4210 Operational Description (Continued) Geode™ CS4210 Operational Description (Continued) 3.7 HOST BUS ERRORS 3.7.2.2 xferStatus Write Error For any type of context, when the CS4210 encounters an error writing the status to a descriptor, it sets ContextControl.dead. The values that would have been written to xferStatus of a descriptor are retained in ContextControl for inspection by system software. The unrecoverable error IntEvent is generated and the context’s IntEvent is not set regardless of the setting of the interrupt (i) field in the descriptor. Additionally, CommandPtr is set to point to a descriptor within the descriptor block in which the error occurred. The CS4210 has three primary goals when dealing with host bus error conditions: 1) Continue transmission and/or reception on all contexts not involved in the error. 2) Provide information to software which is sufficient to allow recovery from the error when possible. 3) Provide a means of error recovery on a context other than a general chip reset. 3.7.1 Causes of Host Bus Errors Host bus errors can generally be classified as one of the following: • Operation error (e.g., attempt to write to read-only memory) • Data transfer error (e.g., parity or unrecoverable ECC) ol e • Time-out error (e.g., reply on split transaction bus was not received in time) te • Addressing error (e.g., non-existent memory location) Each of these errors can occur at three identifiable stages in the processing of a descriptor: • Descriptor fetch • Data transfer (read or write) • Optional descriptor status update. bs In general, the nature of the bus error is not as significant as the stage of descriptor processing in which it occurs. For example, the difference between an addressing error and a data parity error is not significant to the error processing. O 3.7.2 CS4210 Actions When Host Bus Error Occurs When a host bus error occurs, the CS4210 performs a defined set of actions for all context types. Additionally, there is a set of actions that is performed depending on the context type. The following subsections outline these actions. 3.7.2.1 Descriptor Read Error When an error occurs during the reading of a descriptor or descriptor block, the behavior of the CS4210 is the same regardless of the context type. The CS4210 sets ContextControl.dead and sets ContextControl.event to evt_descriptor_read to indicate that the descriptor fetch failed. The unrecoverable error IntEvent is generated and the context’s IntEvent is not set. Additionally, CommandPtr is set to point to a descriptor within the descriptor block in which the error occurred. Since the descriptor could not be read, its xferStatus and resCount are not written with current values, and software must refer to ContextControl.event for the status. www.national.com 3.7.2.3 Transmit Data Read Error For asynchronous request transmit, asynchronous response transmit, and isochronous transmit, the CS4210 handles system data read errors in a similar manner. The CS4210 does not stop processing for the context. Instead, the event code in the status of the OUTPUT_LAST* descriptor is set to indicate that there was an error and the nature of the error. The indicated errors are evt_data_read or evt_underrun. If the error occurs before a packet’s header is placed in the output FIFO, the CS4210 can immediately abort the packet transfer, optionally set the descriptor status to evt_data_read or evt_underrun, and move on to the next descriptor block. If the error occurs after the header has been placed in the output FIFO, the CS4210 stops placing data in the output FIFO. This causes the CS4210 to send a packet with a length that does not agree with the data_length field of the header. If the CS4210 receives an ack_data_error from the addressed node, then the CS4210 substitutes evt_data_read or evt_underrun as appropriate. If the device returns anything other than ack_data_error, then the CS4210 stores that value in the status for the packet. This means that if the addressed node returns an ack_pending on a block write, the error indication is lost. If the packet was a broadcast write, an isochronous packet, or an asynchronous stream packet, no ack code is received from any node. In this case, the CS4210 assumes that ack_data_error was received and proceeds as outlined above. Note: 28 Underruns which occur due to host bus latency are not construed to be host bus data errors, and as a result such asynchronous request and response packets are retried as described in Section 4.4.3 "ATRetries Register" on page 59. Revision 1.0 3.7.6 Physical Read Error When an external node does a physical access and the CS4210’s read of system memory fails, the CS4210 returns an error indication to the requester by forming a response containing a response code of resp_data_error. If the device replies with ack_busy or ack_data_error the host retries the packet. If the error was caused by a FIFO underrun, the CS4210 retries with the same response. If the error was a host bus error, the response packet is changed to resp_data_error. 3.7.4 Asynchronous Receive DMA Data Write Error When a host bus error occurs while the CS4210 is attempting to write to either the request or response buffer, the CS4210 sets the corresponding ContextControl.dead and set ContextControl.event to evt_data_write. The unrecoverable error IntEvent is generated and the context’s IntEvent is not set regardless of the setting of the interrupt (i) field in the descriptor. CommandPtr.descriptorAddress points to the descriptor that contained the buffer descriptor for the memory address at which the error occurred. Any data in the input FIFO for the context is discarded. 3.7.7 Posted Write Error Whether to be handled by the Physical Request controller or by the Asynchronous Receive Request context, write requests to certain address ranges (see Section 3.6 "Physical Requests" on page 26) may be acked with ack_complete before the data is actually written to system memory. Since the sending node has been notified that the action is complete, when the CS4210 cannot complete a posted write operation due to a host bus error the system must be notified so that software can recover. te 3.7.3 Isochronous Transmit Data Write Error A data write error can occur when the CS4210 attempts to write to the address indicated in a STORE_VALUE descriptor. This error is handled like a data read error with the exception that the event code is set to evt_data_write. The CS4210 does not begin placing the packet associated with a STORE_VALUE into the output FIFO until the STORE_VALUE operation is complete. This is to prevent the possibility of having multiple errors that cannot be properly reported to system software. ol e If an error occurs in writing the posted data packet, then the CS4210 sets the IntEvent.PostedWriteErr bit (BAR0+Offset 80h[8]) to indicate that an error has occurred and the write remains pending. Software can then read the source node ID and offset address from the PostedWriteAddress register and then clear IntEvent.PostedWriteErr. When software clears IntEvent.PostedWriteErr, that write is no longer pending. O bs 3.7.5 Isochronous Receive Data Write Error If a data write error occurs for a context that is in packetper-buffer mode, the CS4210 sets ContextControl.event to evt_data_write or evt_overrun and conditionally updates xferStatus of the descriptor in which the error occurred. Any remaining data in the input FIFO for the packet is discarded. The resCount value in a descriptor that has an error will not necessarily reflect the correct number of data bytes successfully written to memory. If a FIFO overrun occurs for a context that is in buffer-fill mode, the packet is treated as if a data length error had occurred and is ‘backed out’ of the receive buffer (xferStatus and resCount not updated) and the remainder of the packet is discarded from the input FIFO. If a host bus error occurs for a context in buffer-fill mode, the CS4210 sets ContextControl.dead and sets ContextControl.event to evt_data_write. The unrecoverable error IntEvent is generated and the context’s IntEvent is not set regardless of the setting of the interrupt (i) field in the descriptor. CommandPtr.descriptorAddress points to the descriptor that contained the buffer descriptor for the memory address at which the error occurred. Any data in the input FIFO for the context is discarded. Although the CS4210 allows four pending writes, error reporting is through a single pair of software visible registers. If multiple posted write failures have occurred, software accesses them one at a time through the PostedWriteAddress register. When software clears IntEvent.PostedWriteErr, this is a signal to the CS4210 that software has completed reading of the current contents of PostedWriteAddress and that the CS4210 can report another error by again setting IntEvent.PostedWriteErr and presenting a new set of values when software reads PostedWriteAddress. Table 3-10 provides a map of the PostedWriteAddress register. Refer to Section 4.4.10 "PostedWriteAddress Register" on page 64 for further register information. If the CS4210 has four pending physical writes, additional physical writes may not be posted. Instead the CS4210 returns ack_pending and only returns a complete indication when the write is actually done. Table 3-10. BAR0+Offset 38h: PostedWriteAddress Register Map 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 sourceID 9 8 7 6 5 4 3 2 1 0 offsetHi offsetLo Revision 1.0 29 www.national.com Geode™ CS4210 Operational Description (Continued) Geode™ CS4210 Operational Description (Continued) 3.8 BUS RESETS 3.8.2 Asynchronous Receive To assist software in determining which asynchronous request packets arrived before and after a bus reset, this is necessary since node numbers may have changed, the CS4210 inserts a synthesized CS4103 packet into the AR DMA Request Context buffer (if active) as soon as a bus reset condition is detected. The format of the packet can be found in the 1394 OHCI specification. When a 1394 bus reset occurs, certain actions must be taken by software for proper operation of the DMA contexts. These actions and the behavior of the CS4210 are described in the following subsections. 3.8.1 Asynchronous Transmit Upon detection of a bus reset, the CS4210 ceases transmission of asynchronous transmit packets. When this occurs there are two possibilities for AT packets that are left in the FIFO. • Case 2 is when a bus reset occurs after the packet is placed in the FIFO but before it is transmitted. For this category, the link side of the CS4210 returns evt_flushed. ol e When each context becomes stable (all data transfers have been halted and status writes have been completed), the CS4210 clears the corresponding ContextControl.active bit. te • Case 1 is when a bus reset occurs after the packet was transmitted but before an ack was received. For this category, the link side of the CS4210 returns evt_missing_ack. Software can distinguish the bus-reset packet from authentic CS4103 packets by the value of eventCode which is set to evt_bus_reset. Software can further interpret and coordinate received asynchronous packets across multiple bus resets by using the selfIDGeneration number provided in the bus-reset packet. Since the bus-reset packet is fabricated when a bus reset is initially detected, the selfIDGeneration number is for the new (not previous) generation and is the same as the selfIDGeneration number in the SelfIDCount register as well as in the selfID buffer. If more than one bus reset has occurred without any intervening packets, then only the “last” one is required to result in a synthesized bus-reset packet. If the input FIFO is full when a bus reset occurs, the link side of the FIFO inserts the bus-reset packet when space becomes available. If the AR DMA request context does not have enough buffer space for the bus-reset packet, the packet is synthesized once buffer space becomes available. The bus reset interrupt (IntEvent.busReset) is independent on the time when this packet goes from the FIFO into a host buffer. This interrupt shall occur as soon as possible after a bus reset has been detected. The bus-reset packet is no different from any other packet going into the AR Request buffer in that IntEvent.RQPkt is generated like it is for other packets. When a bus reset occurs, the link side flushes the asynchronous transmit FIFO(s) until the IntEvent.busReset condition is cleared. Software must make sure that IntEvent.busReset is not cleared until: software has cleared the ContextControl.run bits for both Asynchronous Transmit contexts, and 2) both Asynchronous Transmit contexts have acquiesced and both ContextControl.active fields are zero. This is to ensure that all queued asynchronous packets (with potentially stale node numbers) are flushed. bs 1) 3.8.3 Isochronous Transmit and Receive Bus reset does not affect isochronous contexts. O Once the contexts are no longer active, software may clear the busReset interrupt condition, and hardware stops flushing the asynchronous transmit FIFO(s). Before setting ContextControl.run for either context following a bus reset, software must ensure that NodeID.iDValid is set and that NodeID.nodeNumber (Section 4.4.19 "Node ID and Status Register" on page 76) does not equal 63. www.national.com 30 Revision 1.0 3.9 SERIAL EEPROM Table 3-11. Serial EEPROM Map A serial EEPROM may be used to configure the CS4210. If a serial EEPROM device is connected, the CS4210 detects the pull-up resistor on the EEDATA pin (pin 5) and considers the EEPROM present. Immediately after RST# is deasserted, the serial EEPROM is scanned via EEDATA and EECLK (pin 4). The CS4210 reads configuration information from the first 34 bytes of the EEPROM. Offset subsystem[7:0] 01h subsystem[15:8] 02h subsystem[23:16] 03h subsystem[31:24] 04h configROMheader[7:0] 05h configROMheader[15:8] 06h configROMheader[23:16] 07h configROMheader[31:24] 08h busOptions[7:0] 09h busOptions[15:8] 0Ah busOptions[23:16] 0Bh busOptions[31:24] 0Ch guidHi[7:0] 0Dh guidHi[15:8] 0Eh guidHi[23:16] 0Fh guidHi[31:24] 10h guidLo[7:0] 11h guidLo[15:8] 12h guidLo[23:16] 13h guidLo[31:24] 14h nscControl[7:0] 15h nscControl[15:8] 16h nscControl[23:16] 17h nscControl[31:24] 18h nscTxThrsh[7:0] 19h nscTxThrsh[15:8] 1Ah nscTxThrsh[23:16] 1Bh nscTxThrsh[31:24] 1Ch cmcControl[7:0] 1Dh cmcControl[15:8] 1Eh cmcControl[23:16] 1fh cmcControl[31:24] 20h CRC1 21h CRC2 O bs ol e 3.9.1 Serial EEPROM Cyclic Redundancy Check The serial EEPROM uses a Cyclical Redundancy Check (CRC) to insure the data in the EEPROM is valid. If the CRC check fails, the data from the EEPROM is not loaded into the mapped registers listed in Table 3-11. The CRC1 and CRC2 values may be computed using the sample code in Figure 3-1 "CRC1 and CRC2 Sample Code" on page 32. This code accepts hexadecimal data from STDIN and writes data plus CRC to STDOUT. As a check, this code should produce the results as shown in Figure 3-1. 00h te If the presence of the serial EEPROM was not detected, the CS4210 will not attempt to load configuration data via the EEDATA/EECLK pins. It will instead allow software to write to the guidHi and guidLo bit fields of the GUID register once after each hardware reset (RST#). Revision 1.0 Description 31 www.national.com Geode™ CS4210 Operational Description (Continued) ff ff ff ff ff ff ff ff -> CRC1 = feh, CRC2 = 70h 01 23 45 67 89 ab cd ef -> CRC1 = 19h, CRC2 = 07h 00 00 00 00 00 00 00 00 -> CRC1 = bfh, CRC2 = f4h #include typedef unsigned char uchar_t; typedef unsigned short ushort_t; typedef unsigned long long_t; ol e ushort_t calc_crc(ushort_t r, uchar_t d); ushort_t rev16(ushort_t src); /* main routine */ int main(int argc, char *argv[]) { ushort_t residual = 0xffff; int din; uchar_t byte; uchar_t crc1, crc2; while(scanf("%2x", &din ) != EOF ) { byte = din; printf("%2.2x ", byte); residual = calc_crc(residual, byte); }; printf("\n"); residual = rev16(residual); crc1 = ~(residual & 0x00ff); crc2 = ~(residual>>8); printf("CRC1 = %2.2hxh\n", crc1); printf("CRC2 = %2.2hxh\n", crc2); te Geode™ CS4210 Operational Description (Continued) return(0); /* calc_crc - apply a byte of data to the 16-bit CRC */ } ushort_t calc_crc(ushort_t r, uchar_t d) { ushort_t bit_in; int i; } bs for(i=0;i>i) & 0x0001; if((r>>15) ^ bit_in) r = (((r15 ^ ((r>>14)&0x0001) ^ bit_in) >15 ^ ((r>>1)&0x0001) ^ bit_in)