Cyclone® V Hard Processor System Technical Reference Manual

Download PDF
ID 683126
Date 8/28/2023
Public
Document Table of Contents
Document Table of Contents x
1. Cyclone® V Hard Processor System Technical Reference Manual Revision History 2. Introduction to the Hard Processor System 3. Clock Manager 4. Reset Manager 5. FPGA Manager 6. System Manager 7. Scan Manager 8. System Interconnect 9. HPS-FPGA Bridges 10. Cortex®-A9 Microprocessor Unit Subsystem 11. CoreSight* Debug and Trace 12. SDRAM Controller Subsystem 13. On-Chip Memory 14. NAND Flash Controller 15. SD/MMC Controller 16. Quad SPI Flash Controller 17. DMA Controller 18. Ethernet Media Access Controller 19. USB 2.0 OTG Controller 20. SPI Controller 21. I2C Controller 22. UART Controller 23. General-Purpose I/O Interface 24. Timer 25. Watchdog Timer 26. CAN Controller 27. Introduction to the HPS Component 28. Instantiating the HPS Component 29. HPS Component Interfaces 30. Simulating the HPS Component 31. Register Address Map for Cyclone V HPS A. Booting and Configuration
2. Introduction to the Hard Processor System x
2.1. Features of the HPS 2.2. HPS Block Diagram and System Integration 2.3. Endian Support 2.4. Introduction to the Hard Processor System Address Map
2.2. HPS Block Diagram and System Integration x
2.2.1. HPS Block Diagram 2.2.2. Cortex-A9 MPCore 2.2.3. HPS Interfaces 2.2.4. System Interconnect 2.2.5. On-Chip Memory 2.2.6. Flash Memory Controllers 2.2.7. Support Peripherals 2.2.8. Interface Peripherals 2.2.9. CoreSight Debug and Trace
2.2.3. HPS Interfaces x
2.2.3.1. HPS–FPGA Memory-Mapped Interfaces 2.2.3.2. Other HPS Interfaces
2.2.4. System Interconnect x
2.2.4.1. SDRAM Controller Subsystem
2.2.4.1. SDRAM Controller Subsystem x
2.2.4.1.1. SDRAM Controller 2.2.4.1.2. DDR PHY
2.2.5. On-Chip Memory x
2.2.5.1. On-Chip RAM 2.2.5.2. Boot ROM
2.2.6. Flash Memory Controllers x
2.2.6.1. NAND Flash Controller 2.2.6.2. Quad SPI Flash Controller 2.2.6.3. SD/MMC Controller
2.2.7. Support Peripherals x
2.2.7.1. Clock Manager 2.2.7.2. Reset Manager 2.2.7.3. System Manager 2.2.7.4. Scan Manager 2.2.7.5. Timers 2.2.7.6. Watchdog Timers 2.2.7.7. DMA Controller 2.2.7.8. FPGA Manager
2.2.8. Interface Peripherals x
2.2.8.1. EMACs 2.2.8.2. USB Controllers 2.2.8.3. I2C Controllers 2.2.8.4. UARTs 2.2.8.5. CAN Controllers 2.2.8.6. SPI Master Controllers 2.2.8.7. SPI Slave Controllers 2.2.8.8. GPIO Interfaces
2.4. Introduction to the Hard Processor System Address Map x
2.4.1. HPS Address Spaces 2.4.2. HPS Peripheral Region Address Map
2.4.1. HPS Address Spaces x
2.4.1.1. SDRAM Address Space 2.4.1.2. MPU Address Space 2.4.1.3. L3 Address Space
3. Clock Manager x
3.1. Features of the Clock Manager 3.2. Clock Manager Block Diagram and System Integration 3.3. Functional Description of the Clock Manager 3.4. Clock Manager Address Map and Register Definitions
3.2. Clock Manager Block Diagram and System Integration x
3.2.1. L4 Peripheral Clocks
3.3. Functional Description of the Clock Manager x
3.3.1. Clock Manager Building Blocks 3.3.2. Hardware-Managed and Software-Managed Clocks 3.3.3. Clock Groups 3.3.4. Resets 3.3.5. Safe Mode 3.3.6. Interrupts 3.3.7. Clock Usage By Module
3.3.1. Clock Manager Building Blocks x
3.3.1.1. PLLs 3.3.1.2. FREF, FVCO, and FOUT Equations 3.3.1.3. Dividers 3.3.1.4. Clock Gating 3.3.1.5. Control and Status Registers
3.3.3. Clock Groups x
3.3.3.1. OSC1 Clock Group 3.3.3.2. Main Clock Group 3.3.3.3. Peripheral Clock Group
3.3.3.2. Main Clock Group x
3.3.3.2.1. Changing Values That Affect Main Clock Group PLL Lock
3.3.3.3. Peripheral Clock Group x
3.3.3.3.1. Flash Controller Clocks 3.3.3.3.2. SDRAM Clock Group
3.3.4. Resets x
3.3.4.1. Cold Reset 3.3.4.2. Warm Reset
4. Reset Manager x
4.1. Reset Manager Block Diagram and System Integration 4.2. Functional Description of the Reset Manager 4.3. Reset Manager Address Map and Register Definitions
4.1. Reset Manager Block Diagram and System Integration x
4.1.1. HPS External Reset Sources 4.1.2. Reset Controller 4.1.3. Module Reset Signals 4.1.4. Slave Interface and Status Register
4.1.3. Module Reset Signals x
4.1.3.1. Modules Requiring Software Deassert
4.2. Functional Description of the Reset Manager x
4.2.1. Reset Sequencing 4.2.2. Reset Pins 4.2.3. Reset Effects 4.2.4. Altering Warm Reset System Response 4.2.5. Reset Handshaking
4.2.1. Reset Sequencing x
4.2.1.1. Cold Reset Assertion Sequence 4.2.1.2. Warm Reset Assertion Sequence 4.2.1.3. Cold and Warm Reset Deassertion Sequence
5. FPGA Manager x
5.1. Features of the FPGA Manager 5.2. FPGA Manager Block Diagram and System Integration 5.3. Functional Description of the FPGA Manager 5.4. FPGA Manager Address Map and Register Definitions
5.3. Functional Description of the FPGA Manager x
5.3.1. FPGA Manager Building Blocks 5.3.2. FPGA Configuration 5.3.3. FPGA Status 5.3.4. Error Message Extraction 5.3.5. Boot Handshake 5.3.6. General Purpose I/O 5.3.7. Clock 5.3.8. Reset
5.3.1. FPGA Manager Building Blocks x
5.3.1.1. Fabric I/O 5.3.1.2. Monitor
5.3.2. FPGA Configuration x
5.3.2.1. Power Up Phase 5.3.2.2. Reset Phase 5.3.2.3. Configuration Phase 5.3.2.4. Initialization Phase 5.3.2.5. User Mode
6. System Manager x
6.1. Features of the System Manager 6.2. System Manager Block Diagram and System Integration 6.3. Functional Description of the System Manager 6.4. System Manager Address Map and Register Definitions
6.3. Functional Description of the System Manager x
6.3.1. Boot Configuration and System Information 6.3.2. Additional Module Control 6.3.3. Boot ROM Code 6.3.4. FPGA Interface Enables 6.3.5. ECC and Parity Control 6.3.6. Preloader Handoff Information 6.3.7. Clocks 6.3.8. Resets
6.3.2. Additional Module Control x
6.3.2.1. DMA Controller 6.3.2.2. NAND Flash Controller 6.3.2.3. CAN Controller 6.3.2.4. EMAC 6.3.2.5. USB 2.0 OTG Controller 6.3.2.6. SD/MMC Controller 6.3.2.7. Watchdog Timer
6.3.3. Boot ROM Code x
6.3.3.1. L3 Interconnect
7. Scan Manager x
7.1. Features of the Scan Manager 7.2. Scan Manager Block Diagram and System Integration 7.3. Functional Description of the Scan Manager 7.4. Scan Manager Address Map and Register Definitions
7.2. Scan Manager Block Diagram and System Integration x
7.2.1. Arm* JTAG-AP Signal Use in the Scan Manager 7.2.2. Arm* JTAG-AP Scan Chains
7.3. Functional Description of the Scan Manager x
7.3.1. Configuring HPS I/O Scan Chains 7.3.2. Communicating with the JTAG TAP Controller 7.3.3. JTAG-AP FIFO Buffer Access and Byte Command Protocol 7.3.4. Clocks 7.3.5. Resets
7.4. Scan Manager Address Map and Register Definitions x
7.4.1. JTAG-AP Register Name Cross Reference Table
8. System Interconnect x
8.1. Features of the System Interconnect 8.2. System Interconnect Block Diagram and System Integration 8.3. Functional Description of the Interconnect 8.4. System Interconnect Address Map and Register Definitions
8.2. System Interconnect Block Diagram and System Integration x
8.2.1. Interconnect Block Diagram 8.2.2. System Interconnect Architecture 8.2.3. Main Connectivity Matrix
8.3. Functional Description of the Interconnect x
8.3.1. Master to Slave Connectivity Matrix 8.3.2. System Interconnect Address Spaces 8.3.3. Master Caching and Buffering Overrides 8.3.4. Security 8.3.5. Configuring the Quality of Service Logic 8.3.6. Cyclic Dependency Avoidance Schemes 8.3.7. System Interconnect Master Properties 8.3.8. Interconnect Slave Properties 8.3.9. Upsizing Data Width Function 8.3.10. Downsizing Data Width Function 8.3.11. Lock Support 8.3.12. FIFO Buffers and Clock Crossing 8.3.13. System Interconnect Resets
8.3.2. System Interconnect Address Spaces x
8.3.2.1. Available Address Maps 8.3.2.2. L3 Address Space 8.3.2.3. MPU Address Space 8.3.2.4. SDRAM Address Space 8.3.2.5. Address Remapping
8.3.2.5. Address Remapping x
8.3.2.5.1. Bit Fields for Modifying the Memory Map
8.3.4. Security x
8.3.4.1. Slave Security 8.3.4.2. Master Security
8.3.6. Cyclic Dependency Avoidance Schemes x
8.3.6.1. Single Slave 8.3.6.2. Single Slave Per ID 8.3.6.3. Single Active Slave
8.3.9. Upsizing Data Width Function x
8.3.9.1. Incrementing Bursts 8.3.9.2. Wrapping Bursts 8.3.9.3. Fixed Bursts 8.3.9.4. Bypass Merge
8.3.10. Downsizing Data Width Function x
8.3.10.1. Incrementing Bursts 8.3.10.2. Wrapping Bursts 8.3.10.3. Fixed Bursts 8.3.10.4. Bypass Merge
8.3.12. FIFO Buffers and Clock Crossing x
8.3.12.1. Data Release Mechanism
9. HPS-FPGA Bridges x
9.1. Features of the HPS-FPGA Bridges 9.2. HPS-FPGA Bridges Block Diagram and System Integration 9.3. Functional Description of the HPS-FPGA Bridges 9.4. HPS-FPGA Bridges Address Map and Register Definitions
9.3. Functional Description of the HPS-FPGA Bridges x
9.3.1. The Global Programmers View 9.3.2. Functional Description of the FPGA-to-HPS Bridge 9.3.3. Functional Description of the HPS-to-FPGA Bridge 9.3.4. Functional Description of the Lightweight HPS-to-FPGA Bridge 9.3.5. Clocks and Resets 9.3.6. Data Width Sizing
9.3.2. Functional Description of the FPGA-to-HPS Bridge x
9.3.2.1. FPGA-to-HPS Access to ACP 9.3.2.2. FPGA-to-HPS Bridge Slave Signals
9.3.3. Functional Description of the HPS-to-FPGA Bridge x
9.3.3.1. HPS-to-FPGA Bridge Master Signals
9.3.4. Functional Description of the Lightweight HPS-to-FPGA Bridge x
9.3.4.1. Lightweight HPS-to-FPGA Bridge Master Signals
9.3.5. Clocks and Resets x
9.3.5.1. FPGA-to-HPS Bridge Clocks and Resets 9.3.5.2. HPS-to-FPGA Bridge Clocks and Resets 9.3.5.3. Lightweight HPS-to-FPGA Bridge Clocks and Resets 9.3.5.4. Taking HPS-FPGA Bridges Out of Reset 9.3.5.5. GPV Clocks
10. Cortex®-A9 Microprocessor Unit Subsystem x
10.1. Features of the Cortex-A9 MPU Subsystem 10.2. Cortex®-A9 MPU Subsystem Block Diagram and System Integration 10.3. Cortex®-A9 MPCore 10.4. ACP ID Mapper 10.5. L2 Cache 10.6. CPU Prefetch 10.7. Debugging Modules 10.8. Clocks 10.9. Cortex®-A9 MPU Subsystem Register Implementation
10.2. Cortex®-A9 MPU Subsystem Block Diagram and System Integration x
10.2.1. Cortex®-A9 MPU Subsystem with System Interconnect 10.2.2. Cortex®-A9 MPU Subsystem Internals
10.3. Cortex®-A9 MPCore x
10.3.1. Functional Description 10.3.2. Implementation Details 10.3.3. Cortex®-A9 Processor 10.3.4. Interactive Debugging Features 10.3.5. L1 Caches 10.3.6. Preload Engine 10.3.7. Floating Point Unit 10.3.8. NEON* Multimedia Processing Engine 10.3.9. Memory Management Unit 10.3.10. Performance Monitoring Unit 10.3.11. Arm* Cortex* -A9 MPCore* Timers 10.3.12. Generic Interrupt Controller 10.3.13. Global Timer 10.3.14. Snoop Control Unit 10.3.15. Accelerator Coherency Port
10.3.3. Cortex®-A9 Processor x
10.3.3.1. Reset
10.3.5. L1 Caches x
10.3.5.1. Cache Latency
10.3.8. NEON* Multimedia Processing Engine x
10.3.8.1. Single Instruction, Multiple Data (SIMD) Processing 10.3.8.2. Features of the NEON* MPE
10.3.9. Memory Management Unit x
10.3.9.1. TLBs Supported By the MMU 10.3.9.2. TLB Features 10.3.9.3. The Boot Region 10.3.9.4. The SDRAM Region 10.3.9.5. The FPGA Slaves Region 10.3.9.6. The HPS Peripherals Region
10.3.9.3. The Boot Region x
10.3.9.3.1. Boot ROM Mapping
10.3.11. Arm* Cortex* -A9 MPCore* Timers x
10.3.11.1. Functional Description 10.3.11.2. Implementation Details
10.3.12. Generic Interrupt Controller x
10.3.12.1. Functional Description 10.3.12.2. Implementation Details
10.3.12.2. Implementation Details x
10.3.12.2.1. GIC Interrupt Map for the Cyclone V SoC HPS
10.3.13. Global Timer x
10.3.13.1. Functional Description 10.3.13.2. Implementation Details
10.3.14. Snoop Control Unit x
10.3.14.1. Functional Description 10.3.14.2. Implementation Details
10.3.14.1. Functional Description x
10.3.14.1.1. Coherent Memory, Snoop Control Unit, and Accelerator Coherency Port
10.3.15. Accelerator Coherency Port x
10.3.15.1. AxUSER and AxCACHE Attributes 10.3.15.2. Cache Coherency for ACP Shared Requests 10.3.15.3. AXI Master Configuration for ACP Access 10.3.15.4. Burst Sizes and Byte Strobes 10.3.15.5. Exclusive and Locked Accesses 10.3.15.6. Avoiding ACP Dependency Lockup
10.3.15.3. AXI Master Configuration for ACP Access x
10.3.15.3.1. Configuring AxCACHE[3:0] Sideband Signals for Coherent Accesses 10.3.15.3.2. Configuring AxUSER[4:0] Sideband Signals 10.3.15.3.3. Configuring AxPROT[2:0] Sideband Signals for Coherent Accesses
10.3.15.4. Burst Sizes and Byte Strobes x
10.3.15.4.1. Recommended Burst Types
10.4. ACP ID Mapper x
10.4.1. Functional Description 10.4.2. Implementation Details 10.4.3. ACP ID Mapper Address Map and Register Definitions
10.4.2. Implementation Details x
10.4.2.1. ID Intended Usage 10.4.2.2. AXI User Sideband Override 10.4.2.3. Transaction Capabilities 10.4.2.4. Dynamic Mapping Mode 10.4.2.5. Fixed Mapping Mode 10.4.2.6. Control of the AXI User Sideband Signals 10.4.2.7. Memory Region Remap
10.4.2.5. Fixed Mapping Mode x
10.4.2.5.1. HPS Peripheral Master Input IDs
10.5. L2 Cache x
10.5.1. Functional Description
10.5.1. Functional Description x
10.5.1.1. Cache Controller Configuration 10.5.1.2. Single Event Upset Protection 10.5.1.3. L2 Cache Parity 10.5.1.4. L2 Cache Lockdown Capabilities 10.5.1.5. L2 Cache Event Monitoring 10.5.1.6. L2 Cache Address Filtering 10.5.1.7. Cache Latency
10.5.1.1. Cache Controller Configuration x
10.5.1.1.1. Implementation Details
10.5.1.1.1. Implementation Details x
10.5.1.1.1.1. L2 Cache Event Monitoring
10.7. Debugging Modules x
10.7.1. Program Trace 10.7.2. Event Trace 10.7.3. Cross-Triggering
10.9. Cortex®-A9 MPU Subsystem Register Implementation x
10.9.1. Cortex-A9 MPU Subsystem Address Map 10.9.2. L2 Cache Controller Address Map
11. CoreSight* Debug and Trace x
11.1. Features of CoreSight* Debug and Trace 11.2. Arm* CoreSight* Documentation 11.3. CoreSight Debug and Trace Block Diagram and System Integration 11.4. Functional Description of CoreSight Debug and Trace 11.5. CoreSight* Debug and Trace Programming Model 11.6. CoreSight Debug and Trace Address Map and Register Definitions
11.4. Functional Description of CoreSight Debug and Trace x
11.4.1. Debug Access Port 11.4.2. System Trace Macrocell 11.4.3. Trace Funnel 11.4.4. CoreSight Trace Memory Controller 11.4.5. AMBA* Trace Bus Replicator 11.4.6. Trace Port Interface Unit 11.4.7. Embedded Cross Trigger System 11.4.8. Program Trace Macrocell 11.4.9. HPS Debug APB* Interface 11.4.10. FPGA Interface 11.4.11. Debug Clocks 11.4.12. Debug Resets
11.4.4. CoreSight Trace Memory Controller x
11.4.4.1. Embedded Trace FIFO 11.4.4.2. Embedded Trace Router
11.4.7. Embedded Cross Trigger System x
11.4.7.1. Cross Trigger Interface 11.4.7.2. Cross Trigger Matrix
11.4.10. FPGA Interface x
11.4.10.1. DAP 11.4.10.2. STM 11.4.10.3. FPGA-CTI 11.4.10.4. TPIU
11.5. CoreSight* Debug and Trace Programming Model x
11.5.1. Coresight Component Address 11.5.2. STM Channels 11.5.3. CTI Trigger Connections to Outside the Debug System 11.5.4. Configuring Embedded Cross-Trigger Connections
11.5.3. CTI Trigger Connections to Outside the Debug System x
11.5.3.1. csCTI 11.5.3.2. FPGA-CTI
11.5.4. Configuring Embedded Cross-Trigger Connections x
11.5.4.1. Configuring Trigger Input 0 11.5.4.2. Triggering a Flush of Trace Data to the TPIU 11.5.4.3. Triggering an STM message 11.5.4.4. Triggering a Breakpoint on CPU 1
12. SDRAM Controller Subsystem x
12.1. Features of the SDRAM Controller Subsystem 12.2. SDRAM Controller Subsystem Block Diagram 12.3. SDRAM Controller Memory Options 12.4. SDRAM Controller Subsystem Interfaces 12.5. Memory Controller Architecture 12.6. Functional Description of the SDRAM Controller Subsystem 12.7. SDRAM Power Management 12.8. DDR PHY 12.9. Clocks 12.10. Resets 12.11. Port Mappings 12.12. Initialization 12.13. SDRAM Controller Subsystem Programming Model 12.14. Debugging HPS SDRAM in the Preloader 12.15. SDRAM Controller Address Map and Register Definitions
12.4. SDRAM Controller Subsystem Interfaces x
12.4.1. MPU Subsystem Interface 12.4.2. L3 Interconnect Interface 12.4.3. CSR Interface 12.4.4. FPGA-to-HPS SDRAM Interface
12.5. Memory Controller Architecture x
12.5.1. Multi-Port Front End 12.5.2. Single-Port Controller
12.5.2. Single-Port Controller x
12.5.2.1. Command Generator 12.5.2.2. Timer Bank Pool 12.5.2.3. Arbiter 12.5.2.4. Rank Timer 12.5.2.5. Write Data Buffer 12.5.2.6. ECC Block 12.5.2.7. AFI Interface 12.5.2.8. CSR Interface
12.6. Functional Description of the SDRAM Controller Subsystem x
12.6.1. MPFE Operation Ordering 12.6.2. MPFE Multi-Port Arbitration 12.6.3. MPFE SDRAM Burst Scheduling 12.6.4. Single-Port Controller Operation
12.6.4. Single-Port Controller Operation x
12.6.4.1. Command and Data Reordering 12.6.4.2. Bank Policy 12.6.4.3. Write Combining 12.6.4.4. Burst Length Support 12.6.4.5. ECC 12.6.4.6. Interleaving Options 12.6.4.7. AXI-Exclusive Support 12.6.4.8. Memory Protection 12.6.4.9. Example of Configuration for TrustZone
12.6.4.5. ECC x
12.6.4.5.1. Byte Writes 12.6.4.5.2. ECC Write Backs 12.6.4.5.3. User Notification of ECC Errors
12.8. DDR PHY x
12.8.1. DDR Calibration
12.10. Resets x
12.10.1. Taking the SDRAM Controller Subsystem Out of Reset
12.12. Initialization x
12.12.1. FPGA-to-SDRAM Protocol Details
12.12.1. FPGA-to-SDRAM Protocol Details x
12.12.1.1. Avalon-MM Bidirectional Port 12.12.1.2. Avalon-MM Write-Only Port 12.12.1.3. Avalon-MM Read Port 12.12.1.4. AXI Port
12.13. SDRAM Controller Subsystem Programming Model x
12.13.1. HPS Memory Interface Architecture 12.13.2. HPS Memory Interface Configuration 12.13.3. HPS Memory Interface Simulation 12.13.4. Generating a Preloader Image for HPS with EMIF
12.13.4. Generating a Preloader Image for HPS with EMIF x
12.13.4.1. Creating a Project in Platform Designer (Standard) 12.13.4.2. Creating a Top-Level File and Adding Constraints
12.14. Debugging HPS SDRAM in the Preloader x
12.14.1. Enabling UART or Semihosting Printout 12.14.2. Enabling Simple Memory Test 12.14.3. Enabling the Debug Report 12.14.4. Writing a Predefined Data Pattern to SDRAM in the Preloader
12.14.3. Enabling the Debug Report x
12.14.3.1. Analysis of Debug Report
13. On-Chip Memory x
13.1. On-Chip RAM 13.2. Boot ROM 13.3. On-Chip Memory Address Map and Register Definitions
13.1. On-Chip RAM x
13.1.1. Features of the On-Chip RAM 13.1.2. On-Chip RAM Block Diagram and System Integration 13.1.3. Functional Description of the On-Chip RAM
13.1.3. Functional Description of the On-Chip RAM x
13.1.3.1. On-Chip RAM Clocks 13.1.3.2. On-Chip RAM Resets 13.1.3.3. On-Chip RAM Initialization
13.2. Boot ROM x
13.2.1. Features of the Boot ROM 13.2.2. Boot ROM Block Diagram and System Integration 13.2.3. Functional Description of the Boot ROM
13.2.3. Functional Description of the Boot ROM x
13.2.3.1. Boot ROM Clocks 13.2.3.2. Boot ROM Resets
14. NAND Flash Controller x
14.1. NAND Flash Controller Features 14.2. NAND Flash Controller Block Diagram and System Integration 14.3. NAND Flash Controller Signal Descriptions 14.4. Functional Description of the NAND Flash Controller 14.5. NAND Flash Controller Programming Model 14.6. NAND Flash Controller Address Map and Register Definitions
14.4. Functional Description of the NAND Flash Controller x
14.4.1. Discovery and Initialization 14.4.2. Bootstrap Interface 14.4.3. Configuration by Host 14.4.4. Local Memory Buffer 14.4.5. Clocks 14.4.6. Resets 14.4.7. Indexed Addressing 14.4.8. Command Mapping 14.4.9. Data DMA 14.4.10. ECC
14.4.2. Bootstrap Interface x
14.4.2.1. Bootstrap Setting Bits
14.4.3. Configuration by Host x
14.4.3.1. Recommended Bootstrap Settings for 512-Byte Page Device 14.4.3.2. NAND Page Main and Spare Areas
14.4.5. Clocks x
14.4.5.1. Clock Generation 14.4.5.2. Clock Enable 14.4.5.3. Clock Switching
14.4.6. Resets x
14.4.6.1. Taking the NAND Flash Controller Out of Reset
14.4.7. Indexed Addressing x
14.4.7.1. Register Map for Indexed Addressing 14.4.7.2. Indexed Addressing Host Usage
14.4.8. Command Mapping x
14.4.8.1. MAP00 Commands 14.4.8.2. MAP01 Commands 14.4.8.3. MAP10 Commands 14.4.8.4. MAP11 Commands
14.4.8.1. MAP00 Commands x
14.4.8.1.1. MAP00 Command Format 14.4.8.1.2. MAP00 Usage Limitations
14.4.8.2. MAP01 Commands x
14.4.8.2.1. MAP01 Command Format 14.4.8.2.2. MAP01 Usage Limitations
14.4.8.3. MAP10 Commands x
14.4.8.3.1. MAP10 Command Format 14.4.8.3.2. MAP10 Operations 14.4.8.3.3. MAP10 Usage Limitations
14.4.8.4. MAP11 Commands x
14.4.8.4.1. MAP11 Control Format 14.4.8.4.2. MAP11 Usage Limitations
14.4.9. Data DMA x
14.4.9.1. Multi-Transaction DMA Command 14.4.9.2. Burst DMA Command
14.4.9.1. Multi-Transaction DMA Command x
14.4.9.1.1. Command-Data Pair Formats 14.4.9.1.2. Using Multi-Transaction DMA Commands
14.4.10. ECC x
14.4.10.1. Correction Capability, Sector Size, and Check Bit Size 14.4.10.2. ECC Programming Modes 14.4.10.3. Preserving Bad Block Markers 14.4.10.4. Error Correction Status
14.4.10.2. ECC Programming Modes x
14.4.10.2.1. Main Area Transfer Mode 14.4.10.2.2. Spare Area Transfer Mode 14.4.10.2.3. Main+Spare Area Transfer Mode
15. SD/MMC Controller x
15.1. Features of the SD/MMC Controller 15.2. SD/MMC Controller Block Diagram and System Integration 15.3. SD/MMC Controller Signal Description 15.4. Functional Description of the SD/MMC Controller 15.5. SD/MMC Controller Programming Model 15.6. SD/MMC Controller Address Map and Register Definitions
15.1. Features of the SD/MMC Controller x
15.1.1. SD Card Support Matrix 15.1.2. MMC Support Matrix
16. Quad SPI Flash Controller x
16.1. Features of the Quad SPI Flash Controller 16.2. Quad SPI Flash Controller Block Diagram and System Integration 16.3. Interface Signals 16.4. Functional Description of the Quad SPI Flash Controller 16.5. Quad SPI Flash Controller Programming Model 16.6. Quad SPI Flash Controller Address Map and Register Definitions
16.4. Functional Description of the Quad SPI Flash Controller x
16.4.1. Overview 16.4.2. Data Slave Interface 16.4.3. SPI Legacy Mode 16.4.4. Register Slave Interface 16.4.5. Local Memory Buffer 16.4.6. DMA Peripheral Request Controller 16.4.7. Arbitration between Direct/Indirect Access Controller and STIG 16.4.8. Configuring the Flash Device 16.4.9. XIP Mode 16.4.10. Write Protection 16.4.11. Data Slave Sequential Access Detection 16.4.12. Clocks 16.4.13. Resets 16.4.14. Interrupts
16.4.2. Data Slave Interface x
16.4.2.1. Direct Access Mode 16.4.2.2. Indirect Access Mode
16.4.2.1. Direct Access Mode x
16.4.2.1.1. Data Slave Remapping Example 16.4.2.1.2. AHB*
16.4.2.2. Indirect Access Mode x
16.4.2.2.1. Indirect Read Operation 16.4.2.2.2. Indirect Write Operation 16.4.2.2.3. Consecutive Reads and Writes
16.4.4. Register Slave Interface x
16.4.4.1. STIG Operation
16.4.8. Configuring the Flash Device x
16.4.8.1. Write Request
16.4.13. Resets x
16.4.13.1. Taking the Quad SPI Flash Controller Out of Reset 16.4.13.2. SRAM Initialization Procedure with ECC Enabled
16.5. Quad SPI Flash Controller Programming Model x
16.5.1. Setting Up the Quad SPI Flash Controller 16.5.2. Indirect Read Operation with DMA Disabled 16.5.3. Indirect Read Operation with DMA Enabled 16.5.4. Indirect Write Operation with DMA Disabled 16.5.5. Indirect Write Operation with DMA Enabled 16.5.6. XIP Mode Operations
16.5.6. XIP Mode Operations x
16.5.6.1. Entering XIP Mode 16.5.6.2. Exiting XIP Mode 16.5.6.3. XIP Mode at Power on Reset
16.5.6.1. Entering XIP Mode x
16.5.6.1.1. Micron Quad SPI Flash Devices with Support for Basic-XIP 16.5.6.1.2. Micron Quad SPI Flash Devices without Support for Basic-XIP 16.5.6.1.3. Winbond Quad SPI Flash Devices 16.5.6.1.4. Spansion Quad SPI Flash Devices
17. DMA Controller x
17.1. Features of the DMA Controller 17.2. DMA Controller Block Diagram and System Integration 17.3. Functional Description of the DMA Controller 17.4. DMA Controller Address Map and Register Definitions
17.3. Functional Description of the DMA Controller x
17.3.1. Peripheral Request Interface
17.3.1. Peripheral Request Interface x
17.3.1.1. Peripheral Request Interface Mapping
17.4. DMA Controller Address Map and Register Definitions x
17.4.1. Address Map and Register Definitions
18. Ethernet Media Access Controller x
18.1. Features of the Ethernet MAC 18.2. EMAC Block Diagram and System Integration 18.3. EMAC Signal Description 18.4. EMAC Internal Interfaces 18.5. Functional Description of the EMAC 18.6. Ethernet MAC Programming Model 18.7. Ethernet MAC Address Map and Register Definitions
18.1. Features of the Ethernet MAC x
18.1.1. MAC 18.1.2. DMA 18.1.3. Management Interface 18.1.4. Acceleration 18.1.5. PHY Interface
18.3. EMAC Signal Description x
18.3.1. HPS EMAC I/O Signals 18.3.2. FPGA EMAC I/O Signals 18.3.3. PHY Management Interface
18.3.3. PHY Management Interface x
18.3.3.1. MDIO Interface 18.3.3.2. I2C External PHY Management Interface
18.4. EMAC Internal Interfaces x
18.4.1. DMA Master Interface 18.4.2. Timestamp Interface
18.6. Ethernet MAC Programming Model x
18.6.1. System Level EMAC Configuration Registers 18.6.2. EMAC FPGA Interface Initialization 18.6.3. EMAC HPS Interface Initialization 18.6.4. DMA Initialization 18.6.5. EMAC Initialization and Configuration 18.6.6. Performing Normal Receive and Transmit Operation 18.6.7. Stopping and Starting Transmission 18.6.8. Programming Guidelines for Energy Efficient Ethernet 18.6.9. Programming Guidelines for Flexible Pulse-Per-Second (PPS) Output
18.6.8. Programming Guidelines for Energy Efficient Ethernet x
18.6.8.1. Entering and Exiting the TX LPI Mode 18.6.8.2. Gating Off the CSR Clock in the LPI Mode
18.6.8.2. Gating Off the CSR Clock in the LPI Mode x
18.6.8.2.1. Gating Off the CSR Clock in the RX LPI Mode 18.6.8.2.2. Gating Off the CSR Clock in the TX LPI Mode
18.6.9. Programming Guidelines for Flexible Pulse-Per-Second (PPS) Output x
18.6.9.1. Generating a Single Pulse on PPS 18.6.9.2. Generating a Pulse Train on PPS 18.6.9.3. Generating an Interrupt without Affecting the PPS
19. USB 2.0 OTG Controller x
19.1. Features of the USB OTG Controller 19.2. USB OTG Controller Block Diagram and System Integration 19.3. USB 2.0 ULPI PHY Signal Description 19.4. Functional Description of the USB OTG Controller 19.5. USB OTG Controller Programming Model 19.6. USB 2.0 OTG Controller Address Map and Register Definitions
19.1. Features of the USB OTG Controller x
19.1.1. Supported PHYS
19.4. Functional Description of the USB OTG Controller x
19.4.1. USB OTG Controller Block Description 19.4.2. Local Memory Buffer 19.4.3. Clocks 19.4.4. Resets 19.4.5. Interrupts
19.4.1. USB OTG Controller Block Description x
19.4.1.1. Master Interface 19.4.1.2. Slave Interface 19.4.1.3. Application Interface Unit 19.4.1.4. Packet FIFO Controller 19.4.1.5. SPRAM 19.4.1.6. MAC 19.4.1.7. Wakeup and Power Control 19.4.1.8. PHY Interface Unit 19.4.1.9. DMA
19.4.1.2. Slave Interface x
19.4.1.2.1. Slave Interface CSR Unit
19.4.1.6. MAC x
19.4.1.6.1. USB Transactions 19.4.1.6.2. Host Protocol 19.4.1.6.3. Device Protocol 19.4.1.6.4. OTG Protocol
19.4.4. Resets x
19.4.4.1. Reset Requirements 19.4.4.2. Hardware Reset 19.4.4.3. Software Reset 19.4.4.4. Taking the USB 2.0 OTG Controller Out of Reset
19.5. USB OTG Controller Programming Model x
19.5.1. Enabling ECC 19.5.2. Enabling SPRAM ECCs 19.5.3. Host Operation 19.5.4. Device Operation
19.5.3. Host Operation x
19.5.3.1. Host Initialization 19.5.3.2. Host Transaction
19.5.4. Device Operation x
19.5.4.1. Device Initialization 19.5.4.2. Device Transaction
19.5.4.2. Device Transaction x
19.5.4.2.1. IN Transactions 19.5.4.2.2. OUT Transactions 19.5.4.2.3. Control Transfers
19.6. USB 2.0 OTG Controller Address Map and Register Definitions x
19.6.131.1.1. USB OTG Controller Module Registers Address Map19.6.131.1.1. USB OTG Controller Module Registers Address Map
19.6.131.1.1. USB OTG Controller Module Registers Address Map19.6.131.1.1. USB OTG Controller Module Registers Address Map x
19.6.1.1. USB Data FIFO Address Map 19.6.1.2. USB Direct Access FIFO RAM Address Map
20. SPI Controller x
20.1. Features of the SPI Controller 20.2. SPI Block Diagram and System Integration 20.3. SPI Controller Signal Description 20.4. Functional Description of the SPI Controller 20.5. SPI Programming Model 20.6. SPI Controller Address Map and Register Definitions
20.2. SPI Block Diagram and System Integration x
20.2.1. SPI Block Diagram
20.3. SPI Controller Signal Description x
20.3.1. Interface to HPS I/O 20.3.2. FPGA Routing
20.4. Functional Description of the SPI Controller x
20.4.1. Protocol Details and Standards Compliance 20.4.2. SPI Controller Overview 20.4.3. Transfer Modes 20.4.4. SPI Master 20.4.5. SPI Slave 20.4.6. Partner Connection Interfaces 20.4.7. DMA Controller Interface 20.4.8. Slave Interface 20.4.9. Clocks and Resets
20.4.2. SPI Controller Overview x
20.4.2.1. Serial Bit-Rate Clocks 20.4.2.2. Transmit and Receive FIFO Buffers 20.4.2.3. SPI Interrupts
20.4.2.1. Serial Bit-Rate Clocks x
20.4.2.1.1. SPI Master Bit-Rate Clock 20.4.2.1.2. SPI Slave Bit-Rate Clock
20.4.3. Transfer Modes x
20.4.3.1. Transmit and Receive 20.4.3.2. Transmit Only 20.4.3.3. Receive Only 20.4.3.4. EEPROM Read
20.4.4. SPI Master x
20.4.4.1. RXD Sample Delay 20.4.4.2. Data Transfers 20.4.4.3. Master SPI and SSP Serial Transfers 20.4.4.4. Master Microwire Serial Transfers
20.4.5. SPI Slave x
20.4.5.1. Slave SPI and SSP Serial Transfers  20.4.5.2. Serial Transfers 20.4.5.3. Glue Logic for Master Port ss_in_n
20.4.6. Partner Connection Interfaces x
20.4.6.1. Motorola SPI Protocol 20.4.6.2. Texas Instruments Synchronous Serial Protocol (SSP) 20.4.6.3. National Semiconductor Microwire Protocol
20.4.8. Slave Interface x
20.4.8.1. Control and Status Register Access 20.4.8.2. Data Register Access
20.4.9. Clocks and Resets x
20.4.9.1. Taking the SPI Controller Out of Reset
20.5. SPI Programming Model x
20.5.1. Master SPI and SSP Serial Transfers 20.5.2. Master Microwire Serial Transfers 20.5.3. Slave SPI and SSP Serial Transfers 20.5.4. Slave Microwire Serial Transfers 20.5.5. Software Control for Slave Selection 20.5.6. DMA Controller Operation
20.5.5. Software Control for Slave Selection x
20.5.5.1. Example: Slave Selection Software Flow for SPI Master 20.5.5.2. Example: Slave Selection Software Flow for SPI Slave
20.5.6. DMA Controller Operation x
20.5.6.1. Transmit FIFO Buffer Underflow 20.5.6.2. Transmit FIFO Watermark 20.5.6.3. Transmit FIFO Buffer Overflow 20.5.6.4. Receive FIFO Buffer Overflow 20.5.6.5. Choosing Receive Watermark Level 20.5.6.6. Receive FIFO Buffer Underflow
20.5.6.2. Transmit FIFO Watermark x
20.5.6.2.1. Example 1: Transmit FIFO Watermark Level = 64 20.5.6.2.2. Example 2: Transmit FIFO Watermark Level = 192
21. I2C Controller x
21.1. Features of the I2C Controller 21.2. I2C Controller Block Diagram and System Integration 21.3. I2C Controller Signal Description 21.4. Functional Description of the I2C Controller 21.5. I2C Controller Programming Model 21.6. I2C Controller Address Map and Register Definitions
21.4. Functional Description of the I2C Controller x
21.4.1. Feature Usage 21.4.2. Behavior 21.4.3. Protocol Details 21.4.4. Multiple Master Arbitration 21.4.5. Clock Frequency Configuration 21.4.6. SDA Hold Time 21.4.7. DMA Controller Interface 21.4.8. Clocks 21.4.9. Resets
21.4.2. Behavior x
21.4.2.1. START and STOP Generation 21.4.2.2. Combined Formats
21.4.3. Protocol Details x
21.4.3.1. START and STOP Conditions 21.4.3.2. Addressing Slave Protocol 21.4.3.3. Transmitting and Receiving Protocol 21.4.3.4. START BYTE Transfer Protocol
21.4.3.2. Addressing Slave Protocol x
21.4.3.2.1. 7-Bit Address Format 21.4.3.2.2. 10-Bit Address Format
21.4.3.3. Transmitting and Receiving Protocol x
21.4.3.3.1. Master-Transmitter and Slave-Receiver 21.4.3.3.2. Master-Receiver and Slave-Transmitter
21.4.4. Multiple Master Arbitration x
21.4.4.1. Clock Synchronization
21.4.5. Clock Frequency Configuration x
21.4.5.1. Minimum High and Low Counts
21.4.5.1. Minimum High and Low Counts x
21.4.5.1.1. Calculating High and Low Counts
21.4.9. Resets x
21.4.9.1. Taking the I2C Controller Out of Reset
21.5. I2C Controller Programming Model x
21.5.1. Slave Mode Operation 21.5.2. Master Mode Operation 21.5.3. Disabling the I2C Controller 21.5.4. DMA Controller Operation
21.5.1. Slave Mode Operation x
21.5.1.1. Initial Configuration 21.5.1.2. Slave-Transmitter Operation for a Single Byte 21.5.1.3. Slave-Receiver Operation for a Single Byte 21.5.1.4. Slave-Transfer Operation for Bulk Transfers
21.5.2. Master Mode Operation x
21.5.2.1. Initial Configuration 21.5.2.2. Dynamic IC_TAR or IC_10BITADDR_MASTER Update 21.5.2.3. Master Transmit and Master Receive
21.5.4. DMA Controller Operation x
21.5.4.1. Transmit FIFO Underflow 21.5.4.2. Transmit Watermark Level 21.5.4.3. Transmit FIFO Overflow 21.5.4.4. Receive FIFO Overflow 21.5.4.5. Receive Watermark Level 21.5.4.6. Receive FIFO Underflow
22. UART Controller x
22.1. UART Controller Features 22.2. UART Controller Block Diagram and System Integration 22.3. UART Controller Signal Description 22.4. Functional Description of the UART Controller 22.5. DMA Controller Operation 22.6. UART Controller Address Map and Register Definitions
22.3. UART Controller Signal Description x
22.3.1. HPS I/O Pins 22.3.2. FPGA Routing
22.4. Functional Description of the UART Controller x
22.4.1. FIFO Buffer Support 22.4.2. UART(RS232) Serial Protocol 22.4.3. Automatic Flow Control 22.4.4. Clocks 22.4.5. Resets 22.4.6. Interrupts
22.4.3. Automatic Flow Control x
22.4.3.1. Automatic RTS mode 22.4.3.2. Automatic CTS mode
22.4.5. Resets x
22.4.5.1. Taking the UART Controller Out of Reset
22.4.6. Interrupts x
22.4.6.1. Programmable THRE Interrupt
22.5. DMA Controller Operation x
22.5.1. Transmit FIFO Underflow 22.5.2. Transmit Watermark Level 22.5.3. Transmit FIFO Overflow 22.5.4. Receive FIFO Overflow 22.5.5. Receive Watermark Level 22.5.6. Receive FIFO Underflow
22.5.2. Transmit Watermark Level x
22.5.2.1. IIR_FCR.TET = 1 22.5.2.2. IIR_FCR.TET = 3
23. General-Purpose I/O Interface x
23.1. Features of the GPIO Interface 23.2. GPIO Interface Block Diagram and System Integration 23.3. Functional Description of the GPIO Interface 23.4. GPIO Interface Programming Model 23.5. General-Purpose I/O Interface Address Map and Register Definitions
23.3. Functional Description of the GPIO Interface x
23.3.1. Debounce Operation 23.3.2. Pin Directions 23.3.3. Taking the GPIO Interface Out of Reset 23.3.4. GPIO Pin State During Reset
24. Timer x
24.1. Features of the Timer 24.2. Timer Block Diagram and System Integration 24.3. Functional Description of the Timer 24.4. Timer Programming Model 24.5. Timer Address Map and Register Definitions
24.3. Functional Description of the Timer x
24.3.1. Clocks 24.3.2. Resets 24.3.3. Interrupts 24.3.4. FPGA Interface
24.4. Timer Programming Model x
24.4.1. Initialization 24.4.2. Enabling the Timer 24.4.3. Disabling the Timer 24.4.4. Loading the Timer Countdown Value 24.4.5. Servicing Interrupts
24.4.5. Servicing Interrupts x
24.4.5.1. Clearing the Interrupt 24.4.5.2. Checking the Interrupt Status 24.4.5.3. Masking the Interrupt
25. Watchdog Timer x
25.1. Features of the Watchdog Timer 25.2. Watchdog Timer Block Diagram and System Integration 25.3. Functional Description of the Watchdog Timer 25.4. Watchdog Timer Programming Model 25.5. Watchdog Timer Address Map and Register Definitions
25.3. Functional Description of the Watchdog Timer x
25.3.1. Watchdog Timer Counter 25.3.2. Watchdog Timer Pause Mode 25.3.3. Watchdog Timer Clocks 25.3.4. Watchdog Timer Resets 25.3.5. FPGA Interface
25.3.4. Watchdog Timer Resets x
25.3.4.1. Taking the Watchdog Timer Out of Reset
25.4. Watchdog Timer Programming Model x
25.4.1. Setting the Timeout Period Values 25.4.2. Selecting the Output Response Mode 25.4.3. Enabling and Initially Starting a Watchdog Timer 25.4.4. Reloading a Watchdog Counter 25.4.5. Pausing a Watchdog Timer 25.4.6. Disabling and Stopping a Watchdog Timer 25.4.7. Watchdog Timer State Machine
26. CAN Controller x
26.1. Features of the CAN Controller 26.2. CAN Controller Block Diagram and System Integration 26.3. Functional Description of the CAN Controller 26.4. CAN Controller Programming Model 26.5. CAN Controller Address Map and Register Definitions
26.3. Functional Description of the CAN Controller x
26.3.1. Message Object 26.3.2. Message Interface Registers 26.3.3. DMA Mode 26.3.4. Automatic Retransmission 26.3.5. Test Mode 26.3.6. L4 Slave Interface 26.3.7. Clocks 26.3.8. Software Reset 26.3.9. Hardware Reset 26.3.10. Interrupts
26.3.1. Message Object x
26.3.1.1. Message Object Control Flags 26.3.1.2. Message Object Mask Bits 26.3.1.3. CAN Message Bits
26.3.1.1. Message Object Control Flags x
26.3.1.1.1. Message Valid (MsgVal) 26.3.1.1.2. New Data (NewDat) 26.3.1.1.3. Message Lost (MsgLst) 26.3.1.1.4. Interrupt Pending (IntPnd) 26.3.1.1.5. Transmit Interrupt Enable (TxIE) 26.3.1.1.6. Receive Interrupt Enable (RxIE) 26.3.1.1.7. Remote Enable (RmtEn) 26.3.1.1.8. Transmit Request (TxRqst) 26.3.1.1.9. End of Block (EoB)
26.3.1.2. Message Object Mask Bits x
26.3.1.2.1. Use Acceptance Mask (UMask) 26.3.1.2.2. Identifier Mask (Msk[28:0]) 26.3.1.2.3. Extended Identifier Mask (MXtd) 26.3.1.2.4. Mask Message Direction (MDir)
26.3.1.3. CAN Message Bits x
26.3.1.3.1. Message Identifier (ID[28:0]) 26.3.1.3.2. Extended Frame Identifier (Xtd) 26.3.1.3.3. Message Direction (Dir) 26.3.1.3.4. Data Length Code (DLC[3:0]) 26.3.1.3.5. Data Bytes 0-7 (Data 0[7:0] - Data 7[7:0])
26.3.5. Test Mode x
26.3.5.1. Silent Mode 26.3.5.2. Loopback Mode 26.3.5.3. Combined Mode
26.3.9. Hardware Reset x
26.3.9.1. Taking the CAN Controller Out of Reset
26.3.10. Interrupts x
26.3.10.1. Error Interrupts 26.3.10.2. Status Interrupts 26.3.10.3. Message Object Interrupts
26.4. CAN Controller Programming Model x
26.4.1. Software Initialization 26.4.2. CAN Message Transfer 26.4.3. Message Object Reconfiguration for Frame Reception 26.4.4. Message Object Reconfiguration for Frame Transmission
27. Introduction to the HPS Component x
27.1. MPU Subsystem 27.2. Arm* CoreSight* Debug Components 27.3. Interconnect 27.4. HPS-to-FPGA Interfaces 27.5. Memory Controllers 27.6. Support Peripherals 27.7. Interface Peripherals 27.8. On-Chip Memories
28. Instantiating the HPS Component x
28.1. FPGA Interfaces 28.2. Configuring HPS Clocks and Resets 28.3. Configuring Peripheral Pin Multiplexing 28.4. Configuring the External Memory Interface 28.5. Using the Address Span Extender Component 28.6. Generating and Compiling the HPS Component
28.1. FPGA Interfaces x
28.1.1. General Interfaces 28.1.2. FPGA-to-HPS SDRAM Interface 28.1.3. DMA Peripheral Request 28.1.4. Interrupts 28.1.5. AXI Bridges
28.2. Configuring HPS Clocks and Resets x
28.2.1. User Clocks 28.2.2. Reset Interfaces 28.2.3. PLL Reference Clocks 28.2.4. Peripheral FPGA Clocks
28.2.1. User Clocks x
28.2.1.1. User Clock Parameters 28.2.1.2. Clock Frequency Usage
28.3. Configuring Peripheral Pin Multiplexing x
28.3.1. Configuring Peripherals 28.3.2. Connecting Unassigned Pins to GPIO 28.3.3. Using Unassigned IO as LoanIO 28.3.4. Resolving Pin Multiplexing Conflicts 28.3.5. Peripheral Signals Routed to FPGA
28.4. Configuring the External Memory Interface x
28.4.1. Selecting PLL Output Frequency and Phase
29. HPS Component Interfaces x
29.1. Memory-Mapped Interfaces 29.2. Clocks 29.3. Resets 29.4. Debug and Trace Interfaces 29.5. Peripheral Signal Interfaces 29.6. Other Interfaces
29.1. Memory-Mapped Interfaces x
29.1.1. FPGA-to-HPS Bridge 29.1.2. HPS-to-FPGA and Lightweight HPS-to-FPGA Bridges 29.1.3. FPGA-to-HPS SDRAM Interface
29.1.1. FPGA-to-HPS Bridge x
29.1.1.1. ACP Sideband Signals
29.2. Clocks x
29.2.1. Alternative Clock Inputs to HPS PLLs 29.2.2. User Clocks 29.2.3. AXI Bridge FPGA Interface Clocks 29.2.4. SDRAM Clocks 29.2.5. Peripheral FPGA Clocks
29.3. Resets x
29.3.1. HPS-to-FPGA Reset Interfaces 29.3.2. HPS External Reset Request 29.3.3. Peripheral Reset Interfaces
29.4. Debug and Trace Interfaces x
29.4.1. Trace Port Interface Unit 29.4.2. FPGA System Trace Macrocell Events Interface 29.4.3. FPGA Cross Trigger Interface 29.4.4. Debug APB* Interface
29.5. Peripheral Signal Interfaces x
29.5.1. DMA Controller Interface
29.6. Other Interfaces x
29.6.1. MPU Standby and Event Interfaces 29.6.2. General Purpose Signals 29.6.3. FPGA-to-HPS Interrupts 29.6.4. Boot from FPGA Interface 29.6.5. Input-only General Purpose Interface
30. Simulating the HPS Component x
30.1. Simulation Flows 30.2. Clock and Reset Interfaces 30.3. FPGA-to-HPS AXI Slave Interface 30.4. HPS-to-FPGA AXI Master Interface 30.5. Lightweight HPS-to-FPGA AXI Master Interface 30.6. FPGA-to-HPS SDRAM Interface 30.7. HPS-to-FPGA MPU Event Interface 30.8. Interrupts Interface 30.9. HPS-to-FPGA Debug APB* Interface 30.10. FPGA-to-HPS System Trace Macrocell Hardware Event Interface 30.11. HPS-to-FPGA Cross-Trigger Interface 30.12. HPS-to-FPGA Trace Port Interface 30.13. FPGA-to-HPS DMA Handshake Interface 30.14. Boot from FPGA Interface 30.15. General Purpose Input Interface
30.1. Simulation Flows x
30.1.1. Setting Up the HPS Component for Simulation 30.1.2. Generating the HPS Simulation Model in Platform Designer (Standard) 30.1.3. Running the Simulations
30.1.1. Setting Up the HPS Component for Simulation x
30.1.1.1. HPS Conduit Interfaces Connecting to the FPGA
30.1.1.1. HPS Conduit Interfaces Connecting to the FPGA x
30.1.1.1.1. Setting Up the HPS Component for Simulation
30.1.3. Running the Simulations x
30.1.3.1. Running HPS RTL Simulation 30.1.3.2. Running HPS Post-Fit Simulation
30.1.3.2. Running HPS Post-Fit Simulation x
30.1.3.2.1. Post-Fit Simulation Files 30.1.3.2.2. BFM API Hierarchy Format
30.2. Clock and Reset Interfaces x
30.2.1. Clock Interface 30.2.2. Reset Interface
30.6. FPGA-to-HPS SDRAM Interface x
30.6.1. HPS Memory Interface Simulation
31. Register Address Map for Cyclone V HPS x
31.1. HPS
31.1. HPS x
19.6.131.1.1. USB OTG Controller Module Registers Address Map19.6.131.1.1. USB OTG Controller Module Registers Address Map
19.6.131.1.1. USB OTG Controller Module Registers Address Map19.6.131.1.1. USB OTG Controller Module Registers Address Map x
31.1.1.1. USB Data FIFO Address Map 31.1.1.2. USB Direct Access FIFO RAM Address Map
A. Booting and Configuration x
A.1. Boot Overview A.2. FPGA Configuration Overview A.3. Booting and Configuration Options A.4. Boot Definitions A.5. Boot ROM Flow A.6. Typical Preloader Boot Flow A.7. FPGA Configuration
A.4. Boot Definitions x
A.4.1. Reset A.4.2. Boot ROM A.4.3. Boot Select A.4.4. Flash Memory Devices for Booting A.4.5. Clock Select A.4.6. I/O Configuration A.4.7. L4 Watchdog 0 Timer A.4.8. Preloader A.4.9. U-Boot Loader
A.4.3. Boot Select x
A.4.3.1. Boot Source I/O Mapping
A.4.3.1. Boot Source I/O Mapping x
A.4.3.1.1. Boot Source I/O Configuration
A.4.4. Flash Memory Devices for Booting x
A.4.4.1. SD/MMC Flash Devices A.4.4.2. NAND Flash Devices A.4.4.3. Quad SPI Flash Devices
A.4.4.1. SD/MMC Flash Devices x
A.4.4.1.1. Default Settings of the SD/MMC Controller A.4.4.1.2. CSEL Settings for the SD/MMC Controller
A.4.4.2. NAND Flash Devices x
A.4.4.2.1. NAND Flash Driver Features Supported in the Boot ROM Code A.4.4.2.2. CSEL Settings for the NAND Controller
A.4.4.3. Quad SPI Flash Devices x
A.4.4.3.1. Quad SPI Controller Default Settings A.4.4.3.2. Quad SPI Flash Delay Configuration A.4.4.3.3. Quad SPI Controller CSEL Settings
A.6. Typical Preloader Boot Flow x
A.6.1. HPS State on Entry to the Preloader A.6.2. Shared Memory A.6.3. Loading the Preloader Image
A.7. FPGA Configuration x
A.7.1. Full Configuration A.7.2. Partial Reconfiguration
1. Cyclone® V Hard Processor System Technical Reference Manual Revision History
2. Introduction to the Hard Processor System
3. Clock Manager
4. Reset Manager
5. FPGA Manager
6. System Manager
7. Scan Manager
8. System Interconnect
9. HPS-FPGA Bridges
10. Cortex®-A9 Microprocessor Unit Subsystem
11. CoreSight* Debug and Trace
12. SDRAM Controller Subsystem
13. On-Chip Memory
14. NAND Flash Controller
15. SD/MMC Controller
16. Quad SPI Flash Controller
17. DMA Controller
18. Ethernet Media Access Controller
19. USB 2.0 OTG Controller
20. SPI Controller
21. I2C Controller
22. UART Controller
23. General-Purpose I/O Interface
24. Timer
25. Watchdog Timer
26. CAN Controller
27. Introduction to the HPS Component
28. Instantiating the HPS Component
29. HPS Component Interfaces
30. Simulating the HPS Component
31. Register Address Map for Cyclone V HPS
A. Booting and Configuration

15.5. SD/MMC Controller Programming Model

Software and Hardware Restrictions†

Only one data transfer command should be issued at one time. For CE-ATA devices, if CE-ATA device interrupts are enabled (nIEN=0), only one RW_MULTIPLE_BLOCK command (RW_BLK) should be issued; no other commands (including a new RW_BLK) should be issued before the Data Transfer Over status is set for the outstanding RW_BLK.†

Before issuing a new data transfer command, the software should ensure that the card is not busy due to any previous data transfer command. Before changing the card clock frequency, the software must ensure that there are no data or command transfers in progress.†

If the card is enumerated in SDR12 or SDR25 mode, the application must program the use_hold_reg bit[29] in the CMD register to 1’b1.†

This programming should be done for all data transfer commands and non-data commands that are sent to the card. When the use_hold_reg bit is programmed to 1’b0, the SD/MMC controller bypasses the Hold Registers in the transmit path. The value of this bit should not be changed when a Command or Data Transfer is in progress.†

For more information on using the use_hold_reg and the implementation requirements for meeting the card input hold time, refer to the latest version of the Synopsys® DesignWare® Cores Mobile Storage Host Databook.

Avoiding Glitches in the Card Clock Outputs†

To avoid glitches in the card clock outputs (sdmmc_cclk_out), the software should use the following steps when changing the card clock frequency:†

  1. Before disabling the clocks, ensure that the card is not busy due to any previous data command. To determine this, check for 0 in bit 9 of the STATUS register.†
  2. Update the Clock Enable register to disable all clocks. To ensure completion of any previous command before this update, send a command to the CIU to update the clock registers by setting:†
    • start_cmd bit†
    • "update clock registers only" bits†
    • "wait_previous data complete"†
      Note: Wait for the CIU to take the command by polling for 0 on the start_cmd bit.†
  3. Set the start_cmd bit to update the Clock Divider or Clock Source register, or both, Send a command to the CIU to update the clock registers. Wait for the CIU to take the command.
  4. Set start_cmd to update the Clock Enable register in order to enable the required clocks and send a command to the CIU to update the clock registers; wait for the CIU to take the command.†

Reading from a Card in Non-DMA Mode†

When a card is read in non-DMA mode, the Data Transfer Over (RINTSTS[3]) interrupt occurs as soon as the data transfer from the card is over. There still could be some data left in the FIFO, and the RX_WMark interrupt may or may not occur, depending on the remaining bytes in the FIFO. Software should read any remaining bytes upon seeing the Data Transfer Over (DTO) interrupt. While using the external DMA interface for reading from a card, the DTO interrupt occurs only after all the data is flushed to memory by the DMA Interface unit.†

Writing to a Card in External DMA Mode†

While writing to a card in external DMA mode, if an undefined-length transfer is selected by setting the Byte Count register to 0, the DMA logic may request more data than it sends to the card, since it has no way of knowing at which point the software stops the transfer. The DMA request stops as soon as the DTO is set by the CIU.†

Software Issues a Controller_Reset Command†

If the software issues a controller_reset command by setting control register bit[0] to 1, all the CIU state machines are reset; the FIFO is not cleared. The DMA sends all remaining bytes to the host. In addition to a card-reset, if a FIFO reset is also issued, then:†

  • Any pending DMA transfer on the bus completes correctly†
  • DMA data read is ignored†
  • Write data is unknown (x)†

Additionally, if dma_reset is also issued, any pending DMA transfer is abruptly terminated. When the DW-DMA/Non-DW-DMA is used, the DMA controller channel should also be reset and reprogrammed.†

If any of the previous data commands do not properly terminate, then the software should issue the FIFO reset in order to remove any residual data, if any, in the FIFO. After asserting the FIFO reset, you should wait until this bit is cleared.†

Data-Transfer Requirement Between the FIFO and Host†

One data-transfer requirement between the FIFO and host is that the number of transfers should be a multiple of the FIFO data width (F_DATA_WIDTH). For example, if F_DATA_WIDTH = 32 and you want to write only 15 bytes to an SD_MMC_CEATA card (BYTCNT), the host should write 16 bytes to the FIFO or program the DMA to do 16-byte transfers, if external DMA mode is enabled. The software can still program the Byte Count register to only 15, at which point only 15 bytes are transferred to the card. Similarly, when 15 bytes are read from a card, the host should still read all 16 bytes from the FIFO.†

It is recommended that you not change the FIFO threshold register in the middle of data transfers when DW-DMA/Non-DW-DMA mode is chosen.†

Initialization†

After the power and clock to the controller are stable, the controller active‑low reset is asserted. The reset sequence initializes the registers, FIFO buffer pointers, DMA interface controls, and state machines in the controller.†
Figure 62. SD/MMC Controller Initialization Sequence†

Power-On Reset Sequence

Software must perform the following steps after the power‑on‑reset:
  1. Before enabling power to the card, confirm that the voltage setting to the voltage regulator is correct. †
  2. Enable power to the card by setting the power enable bit (power_enable) in the power enable register (pwren) to 1. Wait for the power ramp‑up time before proceeding to the next step.†
  3. Set the interrupt masks by resetting the appropriate bits to 0 in the intmask register.†
  4. Set the int_enable bit of the ctrl register to 1.†
    Note: Intel recommends that you write 0xFFFFFFFF to the rintsts register to clear any pending interrupts before setting the int_enable bit to 1.†
  5. Discover the card stack according to the card type. For discovery, you must restrict the clock frequency to 400 kHz in accordance with SD/MMC/CE‑ATA standards. For more information, refer to Enumerated Card Stack.†
  6. Set the clock source assignments. Set the card frequency using the clkdiv and clksrc registers of the controller. For more information, refer to Clock Setup.†
  7. The following common registers and fields can be set during initialization process:†
    • The response timeout field (response_timeout) of the tmout register. A typical value is 0x40.†
    • The data timeout field (data_timeout) of the tmout register, highest of the following:†

      • 10 * NAC †

        NAC = card device total access time†

        = 10 * ((TAAC * FOP) + (100 * NSAC))†

        where:†

        TAAC = Time‑dependent factor of the data access time†

        FOP = The card clock frequency used for the card operation†

        NSAC = Worst‑case clock rate‑dependent factor of the data access time†

      • Host FIFO buffer latency†

        On read: Time elapsed before host starts reading from a full FIFO buffer†

        On write: Time elapsed before host starts writing to an empty FIFO buffer†

    • Debounce counter register (debnce). A typical debounce value is 25 ms.†
    • TX watermark field (tx_wmark) of the FIFO threshold watermark register (fifoth). Typically, the threshold value is set to 512, which is half the FIFO buffer depth.†
    • RX watermark field (rx_wmark) of the fifoth register. Typically, the threshold value is set to 511.†

These registers do not need to be changed with every SD/MMC/CE‑ATA command. Set them to a typical value according to the SD/MMC/CE‑ATA specifications.

Enumerated Card Stack

The card stack performs the following tasks:
  • Discovers the connected card †
  • Sets the relative Card Address Register (RCA) in the connected card†
  • Reads the card specific information†
  • Stores the card specific information locally†

The card connected to the controller can be an MMC, CE‑ATA, SD or SDIO (including IO ONLY, MEM ONLY and COMBO) card.

Identifying the Connected Card Type

To identify the connected card type, the following discovery sequence is needed:
  1. Reset the card width 1 or 4 bit (card_width2) and card width 8 bit (card_width1) fields in the ctype register to 0.
  2. Identify the card type as SD, MMC, SDIO or SDIO-COMBO:
    1. Send an SD/SDIO IO_SEND_OP_COND (CMD5) command with argument 0 to the card.
    2. Read resp0 on the controller. The response to the IO_SEND_OP_COND command gives the voltage that the card supports.
    3. Send the IO_SEND_OP_COND command, with the desired voltage window in the arguments. This command sets the voltage window and makes the card exit the initialization state.
    4. Check bit 27 in resp0:
      • If bit 27 is 0, the SDIO card is IO ONLY. In this case, proceed to step 5.
      • If bit 27 is 1, the card type is SDIO COMBO. Continue with the following steps.
  3. Go to unresolvable-reference.html#lro1415721966101.
  4. Go to unresolvable-reference.html#lro1415730606426.
  5. At this point, the software has determined the card type as SD/SDHC, SDIO or SDIO-COMBO. Now it must enumerate the card stack according to the type that has been discovered.
  6. Set the card clock source frequency to the frequency of identification clock rate, 400 KHz. Use one of the following discovery command sequences:
    • For an SD card or an SDIO memory section, send the following SD/SDIO command sequence:
      • GO_IDLE_STATE
      • SEND_IF_COND
      • SD_SEND_OP_COND (ACMD41)
      • ALL_SEND_CID (CMD2)
      • SEND_RELATIVE_ADDR (CMD3)
    • For an SDIO card, send the following command sequence:
      • IO_SEND_OP_COND
      • If the function count is valid, send the SEND_RELATIVE_ADDR command.
    • For an MMC, send the following command sequence:
      • GO_IDLE_STATE
      • SEND_OP_COND (CMD1)
      • ALL_SEND_CID
      • SEND_RELATIVE_ADDR
  7. You can change the card clock frequency after discovery by writing a value to the clkdiv register that divides down the sdmmc_clk clock.

    The following list shows typical clock frequencies for various types of cards:

    • SD memory card, 25 MHz†
    • MMC card device, 12.5 MHz†
    • Full speed SDIO, 25 MHz†
    • Low speed SDIO, 400 kHz†
Card Type is Either SDIO COMBO or Still in Initialization

Only continue with this step if the SDIO card type is COMBO or there is no response received from the previous IO_SEND_OP_COND command. Otherwise, skip to Step 5 in the Identifying the Connected Card Type section.

  1. Send the SD/SDIO SEND_IF_COND (CMD8) command with the following arguments:
    • Bit[31:12] = 0x0 (reserved bits)†
    • Bit[11:8] = 0x1 (supply voltage value)†
    • Bit[7:0] = 0xAA (preferred check pattern by SD memory cards compliant with SDIO Simplified Specification Version 2.00 and later.)†

    Refer to SDIO Simplified Specification Version 2.00 as described on the SD Association website.

    • If a response is received to the previous SEND_IF_COND command, the card supports SD High-Capacity, compliant with SD Specifications, Part 1, Physical Layer Simplified Specification Version 2.00.
    • If no response is received, proceed to the next decision statement.
  2. Send the SD_SEND_OP_COND (ACMD41) command with the following arguments:
    • Bit[31] = 0x0 (reserved bits)†
    • Bit[30] = 0x1 (high capacity status)†
    • Bit[29:25] = 0x0 (reserved bits)†
    • Bit[24] = 0x1 (S18R ‑‑supports voltage switching for 1.8V)†
    • Bit[23:0] = supported voltage range†
    • If the previous SD_SEND_OP_COND command receives a response, then the card type is SDHC. Otherwise, the card is MMC or CE-ATA. In either case, skip the following steps and proceed to Step 5 in the Identifying the Connected Card Type section.
    • If the initial SEND_IF_COND command does not receive a response, then the card does not support High Capacity SD2.0. Now, proceed to step 3.
  3. Next, issue the GO_IDLE_STATE command followed by the SD_SEND_OP_COND command with the following arguments:
    • Bit[31] = 0x0 (reserved bits)†
    • Bit[30] = 0x0 (high capacity status)†
    • Bit[29:24] = 0x0 (reserved bits)†
    • Bit[23:0] = supported voltage range†

    If a response is received to the previous SD_SEND_OP_COND command, the card is SD type. Otherwise, the card is MMC or CE-ATA.

    Note: You must issue the SEND_IF_COND command prior to the first SD_SEND_OP_COND command, to initialize the High Capacity SD memory card. The card returns busy as a response to the SD_SEND_OP_COND command when any of the following conditions are true:
    • The card executes its internal initialization process.
    • A SEND_IF_COND command is not issued before the SD_SEND_OP_COND command.
    • The ACMD41 command is issued. In the command argument, the Host Capacity Support (HCS) bit is set to 0, for a high capacity SD card.
Determine if Card is a CE-ATA 1.1, CE-ATA 1.0, or MMC Device

Use the following sequence to determine whether the card is a CE-ATA 1.1, CE-ATA 1.0, or MMC device:

Determine whether the card is a CE-ATA v1.1 card device by attempting to select ATA mode.

  1. Send the SD/SDIO SEND_IF_COND command, querying byte 504 (S_CMD_SET) of the EXT_CSD register block in the external card.

    If bit 4 is set to 1, the card device supports ATA mode.

  2. Send the SWITCH_FUNC (CMD6) command, setting the ATA bit (bit 4) of the EXT_CSD register slice 191 (CMD_SET) to 1.

    This command selects ATA mode and activates the ATA command set.

  3. You can verify the currently selected mode by reading it back from byte 191 of the EXT_CSD register.

  4. Skip to Step 5 in the Identifying the Connected Card Type section.

    If the card device does not support ATA mode, it might be an MMC card or a CE-ATA v1.0 card. Proceed to the next section to determine whether the card is a CE-ATA 1.0 card device or an MMC card device.

Determine whether the card is a CE-ATA 1.0 card device or an MMC card device by sending the RW_REG command.

If a response is received and the response data contains the CE-ATA signature, the card is a CE-ATA 1.0 card device. Otherwise, the card is an MMC card device.

Clock Setup

The following registers of the SD/MMC controller allow software to select the desired clock frequency for the card:
  • clksrc
  • clkdiv
  • clkena

The controller loads these registers when it receives an update clocks command.

Changing the Card Clock Frequency

To change the card clock frequency, perform the following steps:
  1. Before disabling the clocks, ensure that the card is not busy with any previous data command. To do so, verify that the data_busy bit of the status register (status) is 0.
  2. Reset the cclk_enable bit of the clkena register to 0, to disable the card clock generation.
  3. Reset the clksrc register to 0.
  4. Set the following bits in the cmd register to 1:
    • update_clk_regs_only—Specifies the update clocks command†
    • wait_prvdata_complete—Ensures that clock parameters do not change until any ongoing data transfer is complete†
    • start_cmd—Initiates the command†
  5. Wait until the start_cmd bit changes to 0. There is no interrupt when the clock modification completes. The controller does not set the command_done bit in the rintsts register upon command completion. The controller might signal a hardware lock error if it already has another command in the queue. In this case, return to Step 4.

    For information about hardware lock errors, refer to the "Interrupt and Error Handling" chapter.

  6. Reset the sdmmc_clk_enable bit to 0 in the enable register of the clock manager peripheral PLL group (perpllgrp).
  7. In the control register (ctrl) of the SDMMC controller group (sdmmcgrp) in the system manager, set the drive clock phase shift select (drvsel) and sample clock phase shift select (smplsel) bits to specify the required phase shift value.
  8. Set the sdmmc_clk_enable bit in the Enable register of the clock manager perpllgrp group to 1.
  9. Set the clkdiv register of the controller to the correct divider value for the required clock frequency.
  10. Set the cclk_enable bit of the clkena register to 1, to enable the card clock generation.

    You can also use the clkena register to enable low‑power mode, which automatically stops the sdmmc_cclk_out clock when the card is idle for more than eight clock cycles.

Controller/DMA/FIFO Buffer Reset Usage

The following list shows the effect of reset on various parts in the SD/MMC controller:†
  • Controller reset—resets the controller by setting the controller_reset bit in the ctrl register to 1. Controller reset resets the CIU and state machines, and also resets the BIU‑to‑CIU interface. Because this reset bit is self‑clearing, after issuing the reset, wait until this bit changes to 0.†
  • FIFO buffer reset—resets the FIFO buffer by setting the FIFO reset bit (fifo_reset) in the ctrl register to 1. FIFO buffer reset resets the FIFO buffer pointers and counters in the FIFO buffer. Because this reset bit is self‑clearing, after issuing the reset, wait until this bit changes to 0.†
  • DMA reset—resets the internal DMA controller logic by setting the DMA reset bit (dma_reset) in the ctrl register to 1, which immediately terminates any DMA transfer in progress. Because this reset bit is self‑clearing, after issuing the reset, wait until this bit changes to 0.†
Note: Ensure that the DMA is idle before performing a DMA reset. Otherwise, the L3 interconnect might be left in an indeterminate state.†

Intel recommends setting the controller_reset, fifo_reset, and dma_reset bits in the ctrl register to 1 first, and then resetting the rintsts register to 0 using another write, to clear any resultant interrupt.

Enabling ECC

  1. Turn on the ECC hardware, but disable the interrupts.
  2. Initialize the SRAM in the peripheral.50
  3. Clear the ECC event bits, because these bits may have become asserted after Step 1.
  4. Enable the ECC interrupts now that the ECC bits have been set.

Enabling FIFO Buffer ECC

To protect the FIFO buffer data with ECC, you must enable the ECC feature before performing any operations with the SD/MMC controller. Perform the following steps to enable the FIFO buffer ECC feature:
  1. Verify there are no commands committed to the controller.
  2. Ensure that the FIFO buffer is initialized. Initialize the FIFO buffer by writing 0 to all 1024 FIFO buffer locations. A FIFO buffer write to any address from 0x200 to the maximum FIFO buffer size is valid.
  3. Set the SDMMC RAM ECC single and double, correctable error interrupt status bits (serrporta, derrporta, serrportb, and derrportb) to 1 in the sdmmc register in the eccgrp group of the system manager, to clear any previously-detected ECC errors.
  4. Reset the FIFO buffer by setting the fifo_reset bit to 1 in the ctrl register. This action resets pointers and counters in the FIFO buffer. This reset bit is self-clearing, so after issuing the reset, wait until the bit changes to 0.
  5. Set the en bit in sdmmc register in eccgrp group of the system manager to 1, to enable ECC for the FIFO buffer in SD/MMC controller.

Non-Data Transfer Commands

To send any non‑data transfer command, the software needs to write the cmd register and the cmdarg register with appropriate parameters. Using these two registers, the controller forms the command and sends it to the CMD pin. The controller reports errors in the command response through the error bits of the rintsts register.†

When a response is received—either erroneous or valid—the controller sets the command_done bit in the rintsts register to 1. A short response is copied to resp0, while a long response is copied to all four response registers (resp0, resp1, resp2, and resp3).† For long responses, bit 31 of resp3 represents the MSB and bit 0 of resp0 represents the LSB.†

For basic and non‑data transfer commands, perform the following steps:

  1. Write the cmdarg register with the appropriate command argument parameter.†
  2. Write the cmd register with the settings in Register Settings for Non-Data Transfer Command.†
  3. Wait for the controller to accept the command. The start_cmd bit changes to 0 when the command is accepted.†

    The following actions occur when the command is loaded into the controller:†

    • If no previous command is being processed, the controller accepts the command for execution and resets the start_cmd bit in the cmd register to 0. If a previous command is being processed, the controller loads the new command in the command buffer.†
    • If the controller is unable to load the new command—that is, a command is already in progress, a second command is in the buffer, and a third command is attempted—the controller generates a hardware lock error.†
  4. Check if there is a hardware lock error.†
  5. Wait for command execution to complete. After receiving either a response from a card or response timeout, the controller sets the command_done bit in the rintsts register to 1. Software can either poll for this bit or respond to a generated interrupt (if enabled).†
  6. Check if the response timeout boot acknowledge received (bar), rcrc, or re bit is set to 1. Software can either respond to an interrupt raised by these errors or poll the re, rcrc, and bar bits of the rintsts register. If no response error is received, the response is valid. If required, software can copy the response from the response registers.†
Note: Software cannot modify clock parameters while a command is being executed.†

cmd Register Settings for Non-Data Transfer Command†

Table 143.  Default
Parameter Value Comment
start_cmd

1

This bit resets itself to 0 after the command is committed.

use_hold_reg

1 or 0

Choose the value based on the speed mode used.

update_clk_regs_only

0

Indicates that the command is not a clock update command

data_expected

0

Indicates that the command is not a data command

card_number

1

For one card

cmd_index

Command Index

Set this parameter to the command number. For example, set to 8 for the SD/SDIO SEND_IF_COND (CMD8) command.

send_initialization

0 or 1

1 for card reset commands such as the SD/SDIO GO_IDLE_STATE command

0 otherwise

stop_abort_cmd

0 or 1

1 for a command to stop data transfer, such as the SD/SDIO STOP_TRANSMISSION command

0 otherwise

response_length

0 or 1

1 for R2 (long) response

0 for short response

response_expect

0 or 1

0 for commands with no response, such as SD/SDIO GO_IDLE_STATE, SET_DSR (CMD4), or GO_INACTIVE_STATE (CMD15).

1 otherwise

Table 144.  User Selectable
Parameter Value Comment
wait_prvdata_complete

1

Before sending a command on the command line, the host must wait for completion of any data command already in process. Intel recommends that you set this bit to 1, unless the current command is to query status or stop data transfer when transfer is in progress.

check_response_crc

1 or 0

1 if the response includes a valid CRC, and the software is required to crosscheck the response CRC bits.

0 otherwise

Data Transfer Commands

Data transfer commands transfer data between the memory card and the controller. To issue a data command, the controller requires a command argument, total data size, and block size. Data transferred to or from the memory card is buffered by the controller FIFO buffer.†

Confirming Transfer State

Before issuing a data transfer command, software must confirm that the card is not busy and is in a transfer state, by performing the following steps:†
  1. Issue an SD/SDIO SEND_STATUS (CMD13) command. The controller sends the status of the card as the response to the command.†
  2. Check the card’s busy status.†
  3. Wait until the card is not busy.†
  4. Check the card’s transfer status. If the card is in the stand‑by state, issue an SD/SDIO SELECT/DESELECT_CARD (CMD7) command to place it in the transfer state.†

Busy Signal After CE-ATA RW_BLK Write Transfer

During CE‑ATA RW_BLK write transfers, the MMC busy signal might be asserted after the last block. If the CE‑ATA card device interrupt is disabled (the nIEN bit in the card device’s ATA control register is set to 1), the dto bit in the rintsts register is set to 1 even though the card sends MMC BUSY. The host cannot issue the CMD60 command to check the ATA busy status after a CMD61 command. Instead, the host must perform one of the following actions:†
  • Issue the SEND_STATUS command and check the MMC busy status before issuing a new CMD60 command†
  • Issue the CMD39 command and check the ATA busy status before issuing a new CMD60 command†

For the data transfer commands, software must set the ctype register to the bus width that is programmed in the card.†

Data Transfer Interrupts

The controller generates an interrupt for different conditions during data transfer, which are reflected in the following rintsts register bits:†
  1. dto—Data transfer is over or terminated. If there is a response timeout error, the controller does not attempt any data transfer and the Data Transfer Over bit is never set.†
  2. Transmit FIFO data request bit (txdr)—The FIFO buffer threshold for transmitting data is reached; software is expected to write data, if available, into the FIFO buffer.†
  3. Receive FIFO data request bit (rxdr)—The FIFO buffer threshold for receiving data is reached; software is expected to read data from the FIFO buffer.†
  4. hto—The FIFO buffer is empty during transmission or is full during reception. Unless software corrects this condition by writing data for empty condition, or reading data for full condition, the controller cannot continue with data transfer. The clock to the card is stopped.†
  5. bds—The card has not sent data within the timeout period.†
  6. dcrc—A CRC error occurred during data reception.†
  7. sbe—The start bit is not received during data reception.†
  8. ebe—The end bit is not received during data reception, or for a write operation. A CRC error is indicated by the card.†

dcrc, sbe, and ebe indicate that the received data might have errors. If there is a response timeout, no data transfer occurs.†

Single-Block or Multiple-Block Read

To implement a single‑block or multiple‑block read, the software performs the following steps:†
  1. Write the data size in bytes to the bytcnt register. For a multi‑block read, bytcnt must be a multiple of the block size.†
  2. Write the block size in bytes to the blksiz register. The controller expects data to return from the card in blocks of size blksiz.†
  3. If the read round trip delay, including the card delay, is greater than half of sdmmc_clk_divided, write to the card threshold control register (cardthrctl) to ensure that the card clock does not stop in the middle of a block of data being transferred from the card to the host. For more information, refer to Card Read Threshold.†
    Note: If the card read threshold enable bit (cardrdthren) is 0, the host system must ensure that the RX FIFO buffer does not become full during a read data transfer by ensuring that the RX FIFO buffer is read at a rate faster than that at which data is written into the FIFO buffer. Otherwise, an overflow might occur.†
  4. Write the cmdarg register with the beginning data address for the data read.†
  5. Write the cmd register with the parameters listed in cmd Register Settings for Single-Block and Multiple-Block Reads. For SD and MMC cards, use the SD/SDIO READ_SINGLE_BLOCK (CMD17) command for a single‑block read and the READ_MULTIPLE_BLOCK (CMD18) command for a multiple‑block read. For SDIO cards, use the IO_RW_EXTENDED (CMD53) command for both single‑block and multiple‑block transfers. The command argument for (CMD53) is shown in the figure, below. After writing to the cmd register, the controller starts executing the command. When the command is sent to the bus, the Command Done interrupt is generated.†
  6. Software must check for data error interrupts, reported in the dcrc, bds, sbe, and ebe bits of the rintsts register. If required, software can terminate the data transfer by sending an SD/SDIO STOP command.†
  7. Software must check for host timeout conditions in the rintsts register:†
    • Receive FIFO buffer data request†
    • Data starvation from host—the host is not reading from the FIFO buffer fast enough to keep up with data from the card. To correct this condition, software must perform the following steps:†
      • Read the fifo_count field of the status register†
      • Read the corresponding amount of data out of the FIFO buffer†

    In both cases, the software must read data from the FIFO buffer and make space in the FIFO buffer for receiving more data.†

  8. When a DTO interrupt is received, the software must read the remaining data from the FIFO buffer.†
Figure 63. Command Argument for IO_RW_EXTENDED (CMD53)†

cmd Register Settings for Single-Block and Multiple-Block Reads†

Table 145.  cmd Register Settings for Single-Block and Multiple-Block Reads (Default)
Parameter Value Comment
start_cmd 1 This bit resets itself to 0 after the command is committed.
use_hold_reg 1 or 0 Choose the value based on speed mode used.
update_clk_regs_only 0 Does not need to update clock parameters
data_expected 1 Data command
card_number 1 For one card
transfer_mode 0 Block transfer
send_initialization 0

1 for a card reset command such as the SD/SDIO GO_IDLE_STATE command

0 otherwise

stop_abort_cmd 0

1 for a command to stop data transfer such as the SD/SDIO STOP_TRANSMISSION command

0 otherwise

send_auto_stop 0 or 1 Refer to Auto Stop for information about how to set this parameter.
read_write 0 Read from card
response_length 0

1 for R2 (long) response

0 for short response

response_expect 1 or 0

0 for commands with no response, such as SD/SDIO GO_IDLE_STATE, SET_DSR, and GO_INACTIVE_STATE.

1 otherwise

Table 146.  cmd Register Settings for Single-Block and Multiple-Block Reads (User Selectable)
Parameter Value Comment
wait_prvdata_complete 1 or 0

0 - sends command to CIU immediately

1 - sends command after previous data transfer ends

check_response_crc 1 or 0

0 - Controller must not check response CRC

1 - Controller must check response CRC

cmd_index Command Index Set this parameter to the command number. For example, set to 17 or 18 for SD/SDIO READ_SINGLE_BLOCK (CMS17) or READ_MULTIPLE_BLOCK (CMD18)

Single-Block or Multiple-Block Write

The following steps comprise a single‑block or multiple‑block write:
  1. Write the data size in bytes to the bytcnt register. For a multi‑block write, bytcnt must be a multiple of the block size.†
  2. Write the block size in bytes to the blksiz register. The controller sends data in blocks of size blksiz each.†
  3. Write the cmdarg register with the data address to which data must be written.†
  4. Write data into the FIFO buffer. For best performance, the host software should write data continuously until the FIFO buffer is full.†
  5. Write the cmd register with the parameters listed in cmd Register Settings for Single-Block and Multiple-Block Write. For SD and MMC cards, use the SD/SDIO WRITE_BLOCK (CMD24) command for a single‑block write and the WRITE_MULTIPLE_BLOCK (CMD25) command for a multiple‑block writes. For SDIO cards, use the IO_RW_EXTENDED command for both single‑block and multiple‑block transfers.†

    After writing to the cmd register, the controller starts executing a command if there is no other command already being processed. When the command is sent to the bus, a Command Done interrupt is generated.†

  6. Software must check for data error interrupts; that is, for dcrc, bds, and ebe bits of the rintsts register. If required, software can terminate the data transfer early by sending the SD/SDIO STOP command.†
  7. Software must check for host timeout conditions in the rintsts register: †
    • Transmit FIFO buffer data request.†
    • Data starvation by the host—the controller wrote data to the card faster than the host could supply the data.†

    In both cases, the software must write data into the FIFO buffer.†

    There are two types of transfers: open‑ended and fixed length.†

    • Open‑ended transfers—For an open‑ended block transfer, the byte count is 0. At the end of the data transfer, software must send the STOP_TRANSMISSION command (CMD12).†
    • Fixed‑length transfers—The byte count is nonzero. You must already have written the number of bytes to the bytcnt register. The controller issues the STOP command for you if you set the send_auto_stop bit of the cmd register to 1. After completion of a transfer of a given number of bytes, the controller sends the STOP command. Completion of the AUTO_STOP command is reflected by the Auto Command Done interrupt. A response to the AUTO_STOP command is written to the resp1 register. If software does not set the send_auto_stop bit in the cmd register to 1, software must issue the STOP command just like in the open‑ended case.†

When the dto bit of the rintsts register is set, the data command is complete.†

cmd Register Settings for Single-Block and Multiple-Block Write

Table 147.  cmd Register Settings for Single-Block and Multiple-Block Write (Default)†
Parameter Value Comment
start_cmd

1

This bit resets itself to 0 after the command is committed (accepted by the BIU).

use_hold_reg

1 or 0

Choose the value based on speed mode used.

update_clk_regs_only

0

Does not need to update clock parameters

data_expected

1

Data command

card_number

1

For one card

transfer_mode

0

Block transfer

send_initialization

0

Can be 1, but only for card reset commands such as SD/SDIO GO_IDLE_STATE

stop_abort_cmd

0

Can be 1 for commands to stop data transfer such as SD/SDIO STOP_TRANSMISSION

send_auto_stop

0 or 1

Refer to Auto Stop for information about how to set this parameter.

read_write

1

Write to card

response_length

0

Can be 1 for R2 (long) responses

response_expect

1

Can be 0 for commands with no response. For example, SD/SDIO GO_IDLE_STATE, SET_DSR, GO_INACTIVE_STATE etc.

Table 148.  cmd Register Settings for Single-Block and Multiple-Block Write (User Selectable)†
Parameter Value Comment
wait_prvdata_complete

1

0—Sends command to the CIU immediately

1—Sends command after previous data transfer ends

check_response_crc

1

0—Controller must not check response CRC

1—Controller must check response CRC

cmd_index

Command Index

Set this parameter to the command number. For example, set to 24 for SD/SDIO WRITE_BLOCK (CMD24) or 25 for WRITE_MULTIPLE_BLOCK (CMD25).

Stream Read and Write

In a stream transfer, if the byte count is equal to 0, the software must also send the SD/SDIO STOP command. If the byte count is not 0, when a given number of bytes completes a transfer, the controller sends the STOP command automatically. Completion of this AUTO_STOP command is reflected by the Auto_command_done interrupt. A response to an AUTO_STOP command is written to the resp1 register. A stream transfer is allowed only for card interfaces with a 1‑bit data bus.†

A stream read requires the same steps as the block read described in Single‑Block or Multiple‑Block Read, except for the following bits in the cmd register:†

  • transfer_mode = 0x1 (for stream transfer)†
  • cmd_index = 20 (SD/SDIO CMD20)†

A stream write requires the same steps as the block write mentioned in Single‑Block or Multiple‑Block Write, except for the following bits in the cmd register:†

  • transfer_mode = 0x1 (for stream transfer)†
  • cmd_index = 11 (SD/SDIO CMD11)†

Packed Commands

To reduce overhead, read and write commands can be packed in groups of commands—either all read or all write—that transfer the data for all commands in the group in one transfer on the bus. Use the SD/SDIO SET_BLOCK_COUNT (CMD23) command to state ahead of time how many blocks are transferred. Then issue a single READ_MULTIPLE_BLOCK or WRITE_MULTIPLE_BLOCK command to read or write multiple blocks.†
  • SET_BLOCK_COUNT—set block count (number of blocks transferred using the READ_MULTIPLE_BLOCK or WRITE_MULTIPLE_BLOCK command) †
  • READ_MULTIPLE_BLOCK—multiple-block read command †
  • WRITE_MULTIPLE_BLOCK—multiple-block write command†

Packed commands are organized in packets by the application software and are transparent to the controller.†

Transfer Stop and Abort Commands

This section describes stop and abort commands. The SD/SDIO STOP_TRANSMISSION command can terminate a data transfer between a memory card and the controller. The ABORT command can terminate an I/O data transfer for only an SDIO card. †

STOP_TRANSMISSION (CMD12)

The host can send the STOP_TRANSMISSION (CMD12) command on the CMD pin at any time while a data transfer is in progress. Perform the following steps to send the STOP_TRANSMISSION command to the SD/SDIO card device:†
  1. Set the wait_prvdata_complete bit of the cmd register to 0.†
  2. Set the stop_abort_cmd in the cmd register to 1, which ensures that the CIU stops.†

The STOP_TRANSMISSION command is a non‑data transfer command.†

ABORT

The ABORT command can only be used with SDIO cards. To abort the function that is transferring data, program the ABORT function number in the ASx[2:0] bits at address 0x06 of the card common control register (CCCR) in the card device, using the IO_RW_DIRECT (CMD52) command. The CCCR is located at the base of the card space 0x00 – 0xFF.†

Note: The ABORT command is a non‑data transfer command.†

Sending the ABORT Command

Perform the following steps to send the ABORT command to the SDIO card device:†

  1. Set the cmdarg register to include the appropriate command argument parameters listed in cmdarg Register Settings for SD/SDIO ABORT Command.†
  2. Send the IO_RW_DIRECT command by setting the following fields of the cmd register:†
    • Set the command index to 0x52 (IO_RW_DIRECT).†
    • Set the stop_abort_cmd bit of the cmd register to 1 to inform the controller that the host aborted the data transfer.†
    • Set the wait_prvdata_complete bit of the cmd register to 0.†
  3. Wait for the cmd bit in the rintsts register to change to 1.†
  4. Read the response to the IO_RW_DIRECT command (R5) in the response registers for any errors.†

For more information about response values, refer to the Physical Layer Simplified Specification, Version 3.01, available on the SD Association website.

cmdarg Register Settings for SD/SDIO ABORT Command†

Table 149.  cmdarg Register Settings for SD/SDIO ABORT Command
Bits Contents Value

31

R/W flag

1

30:28

Function number

0, for access to the CCCR in the card device

27

RAW flag

1, if needed to read after write

26

Don't care

-

25:9

Register address

0x06

8

Don't care

-

7:0

Write data

Function number to abort

Internal DMA Controller Operations

For better performance, you can use the internal DMA controller to transfer data between the host and the controller. This section describes the internal DMA controller’s initialization process, and transmission sequence, and reception sequence.

Internal DMA Controller Initialization

To initialize the internal DMA controller, perform the following steps:†
  1. Set the required bmod register bits: †
    • If the internal DMA controller enable bit (de) of the bmod register is set to 0 during the middle of a DMA transfer, the change has no effect. Disabling only takes effect for a new data transfer command.†
    • Issuing a software reset immediately terminates the transfer. Prior to issuing a software reset, Intel recommends the host reset the DMA interface by setting the dma_reset bit of the ctrl register to 1.†
    • The pbl field of the bmod register is read‑only and a direct reflection of the contents of the DMA multiple transaction size field (dw_dma_multiple_transaction_size) in the fifoth register.†
    • The fb bit of the bmod register has to be set appropriately for system performance.†
  2. Write to the idinten register to mask unnecessary interrupt causes according to the following guidelines:†
    • When a Descriptor Unavailable interrupt is asserted, the software needs to form the descriptor, appropriately set its own bit, and then write to the poll demand register (pldmnd) for the internal DMA controller to re‑fetch the descriptor.†
    • It is always appropriate for the software to enable abnormal interrupts because any errors related to the transfer are reported to the software.†
  3. Populate either a transmit or receive descriptor list in memory. Then write the base address of the first descriptor in the list to the internal DMA controller’s descriptor list base address register (dbaddr). The DMA controller then proceeds to load the descriptor list from memory. Internal DMA Controller Transmission Sequences and Internal DMA Controller Reception Sequences describe this step in detail. †

Internal DMA Controller Transmission Sequences

To use the internal DMA controller to transmit data, perform the following steps:
  1. The host sets up the Descriptor fields (DES0—DES3) for transmission and sets the OWN bit (DES0[31]) to 1. The host also loads the data buffer in system memory with the data to be written to the SD card.†
  2. The host writes the appropriate write data command (SD/SDIO WRITE_BLOCK or WRITE_MULTIPLE_BLOCK) to the cmd register. The internal DMA controller determines that a write data transfer needs to be performed.†
  3. The host sets the required transmit threshold level in the tx_wmark field in the fifoth register.†
  4. The internal DMA controller engine fetches the descriptor and checks the OWN bit. If the OWN bit is set to 0, the host owns the descriptor. In this case, the internal DMA controller enters the suspend state and asserts the Descriptor Unable interrupt. The host then needs to set the descriptor OWN bit to 1 and release the DMA controller by writing any value to the pldmnd register.†
  5. The host must write the descriptor base address to the dbaddr register.†
  6. The internal DMA controller waits for the Command Done (CD) bit in the rintsts register to be set to 1, with no errors from the BIU. This condition indicates that a transfer can be done.†
  7. The internal DMA controller engine waits for a DMA interface request from BIU. The BIU divides each transfer into smaller chunks. Each chunk is an internal request to the DMA. This request is generated based on the transmit threshold value.†
  8. The internal DMA controller fetches the transmit data from the data buffer in the system memory and transfers the data to the FIFO buffer in preparation for transmission to the card.†
  9. When data spans across multiple descriptors, the internal DMA controller fetches the next descriptor and continues with its operation with the next descriptor. The Last Descriptor bit in the descriptor DES0 field indicates whether the data spans multiple descriptors or not.†
  10. When data transmission is complete, status information is updated in the idsts register by setting the ti bit to 1, if enabled. Also, the OWN bit is set to 0 by the DMA controller by updating the DES0 field of the descriptor.†

Internal DMA Controller Reception Sequences

To use the internal DMA controller to receive data, perform the following steps:
  1. The host sets up the descriptor fields (DES0—DES3) for reception and sets the OWN (DES0 [31]) to 1.†
  2. The host writes the read data command to the cmd register in BIU. The internal DMA controller determines that a read data transfer needs to be performed.†
  3. The host sets the required receive threshold level in the rx_wmark field in the fifoth register.†
  4. The internal DMA controller engine fetches the descriptor and checks the OWN bit. If the OWN bit is set to 0, the host owns the descriptor. In this case, the internal DMA controller enters suspend state and asserts the Descriptor Unable interrupt. The host then must set the descriptor OWN bit to 1 and release the DMA controller by writing any value to the pldmnd register.†
  5. The host must write the descriptor base address to the dbaddr register.†
  6. The internal DMA controller waits for the CD bit in the rintsts register to be set to 1, with no errors from the BIU. This condition indicates that a transfer can be done.†
  7. The internal DMA controller engine waits for a DMA interface request from the BIU. The BIU divides each transfer into smaller chunks. Each chunk is an internal request to the DMA. This request is generated based on the receive threshold value.†
  8. The internal DMA controller fetches the data from the FIFO buffer and transfers the data to system memory.†
  9. When data spans across multiple descriptors, the internal DMA controller fetches the next descriptor and continues with its operation with the next descriptor. The Last Descriptor bit in the descriptor indicates whether the data spans multiple descriptors or not.†
  10. When data reception is complete, status information is updated in the idsts register by setting the ri bit to 1, if enabled. Also, the OWN bit is set to 0 by the DMA controller by updating the DES0 field of the descriptor.†

Commands for SDIO Card Devices

This section describes the commands to temporarily halt the transfers between the controller and SDIO card device.

Suspend and Resume Sequence

For SDIO cards, a data transfer between an I/O function and the controller can be temporarily halted using the SUSPEND command. This capability might be required to perform a high‑priority data transfer with another function. When desired, the suspended data transfer can be resumed using the RESUME command.†

The SUSPEND and RESUME operations are implemented by writing to the appropriate bits in the CCCR (Function 0) of the SDIO card. To read from or write to the CCCR, use the controller’s IO_RW_DIRECT command.†

Suspend

To suspend data transfer, perform the following steps:†
  1. Check if the SDIO card supports the SUSPEND/RESUME protocol by reading the SBS bit in the CCCR at offset 0x08 of the card.†
  2. Check if the data transfer for the required function number is in process. The function number that is currently active is reflected in the function select bits (FSx) of the CCCR, bits 3:0 at offset 0x0D of the card.†
    Note: If the bus status bit (BS), bit 0 at address 0xC, is 1, only the function number given by the FSx bits is valid.†
  3. To suspend the transfer, set the bus release bit (BR), bit 2 at address 0xC, to 1.†
  4. Poll the BR and BS bits of the CCCR at offset 0x0C of the card until they are set to 0. The BS bit is 1 when the currently‑selected function is using the data bus. The BR bit remains 1 until the bus release is complete. When the BR and BS bits are 0, the data transfer from the selected function is suspended.†
  5. During a read‑data transfer, the controller can be waiting for the data from the card. If the data transfer is a read from a card, the controller must be informed after the successful completion of the SUSPEND command. The controller then resets the data state machine and comes out of the wait state. To accomplish this, set the abort read data bit (abort_read_data) in the ctrl register to 1.†
  6. Wait for data completion, by polling until the dto bit is set to 1 in the rintsts register. To determine the number of pending bytes to transfer, read the transferred CIU card byte count (tcbcnt) register of the controller. Subtract this value from the total transfer size. You use this number to resume the transfer properly.†

Resume

To resume the data transfer, perform the following steps:†
  1. Check that the card is not in a transfer state, which confirms that the bus is free for data transfer.†
  2. If the card is in a disconnect state, select it using the SD/SDIO SELECT/DESELECT_CARD command. The card status can be retrieved in response to an IO_RW_DIRECT or IO_RW_EXTENDED command.†
  3. Check that a function to be resumed is ready for data transfer. Determine this state by reading the corresponding RF<n> flag in CCCR at offset 0x0F of the card. If RF<n> = 1, the function is ready for data transfer.†
    Note: For detailed information about the RF<n> flags, refer to SDIO Simplified Specification Version 2.00, available on the SD Association website.†
  4. To resume transfer, use the IO_RW_DIRECT command to write the function number at the FSx bits in the CCCR, bits 3:0 at offset 0x0D of the card. Form the command argument for the IO_RW_DIRECT command and write it to the cmdarg register. Bit values are listed in the following table.†
    Table 150.  cmdarg Bit Values for RESUME Command†
    Bits Content Value

    31

    R/W flag

    1

    30:28

    Function number

    0, for CCCR access

    27

    RAW flag

    1, read after write

    26

    Don't care

    		-

    25:9

    Register address

    0x0D

    8

    Don't care

    		-

    7:0

    Write data

    Function number that is to be resumed

  5. Write the block size value to the blksiz register. Data is transferred in units of this block size.†
  6. Write the byte count value to the bytcnt register. Specify the total size of the data that is the remaining bytes to be transferred. It is the responsibility of the software to handle the data.†

    To determine the number of pending bytes to transfer, read the transferred CIU card byte count register (tcbcnt). Subtract this value from the total transfer size to calculate the number of remaining bytes to transfer.†

  7. Write to the cmd register similar to a block transfer operation. When the cmd register is written, the command is sent and the function resumes data transfer. For more information, refer to Single‑Block or Multiple‑Block Read and Single‑Block or Multiple‑Block Write.†
  8. Read the resume data flag (DF) of the SDIO card device. Interpret the DF flag as follows:†
    • DF=1—The function has data for the transfer and begins a data transfer as soon as the function or memory is resumed.†
    • DF=0—The function has no data for the transfer. If the data transfer is a read, the controller waits for data. After the data timeout period, it issues a data timeout error.†

Read-Wait Sequence

Read_wait is used with SDIO cards only. It temporarily stalls the data transfer, either from functions or memory, and allows the host to send commands to any function within the SDIO card device. The host can stall this transfer for as long as required. The controller provides the facility to signal this stall transfer to the card.†

Signaling a Stall

To signal the stall, perform the following steps:†
  1. Check if the card supports the read_wait facility by reading the SDIO card’s SRW bit, bit 2 at offset 0x8 in the CCCR.†
  2. If this bit is 1, all functions in the card support the read_wait facility. Use the SD/SDIO IO_RW_DIRECT command to read this bit.†
  3. If the card supports the read_wait signal, assert it by setting the read wait bit (read_wait) in the ctrl register to 1.†
  4. Reset the read_wait bit to 0 in the ctrl register.†

CE-ATA Data Transfer Commands

This section describes CE‑ATA data transfer commands.

ATA Task File Transfer Overview

ATA task file registers are mapped to addresses 0x00h through 0x10h in the MMC register space. The RW_REG command is used to issue the ATA command, and the ATA task file is transmitted in a single RW_REG MMC command sequence.†

The host software stack must write the task file image to the FIFO buffer before setting the cmdarg and cmd registers in the controller. The host processor then writes the address and byte count to the cmdarg register before setting the cmd register bits.†

For the RW_REG command, there is no CCS from the CE‑ATA card device. †

ATA Task File Transfer Using the RW_MULTIPLE_REGISTER (RW_REG) Command

This command involves data transfer between the CE‑ATA card device and the controller. To send a data command, the controller needs a command argument, total data size, and block size. Software receives or sends data through the FIFO buffer.†

Implementing ATA Task File Transfer

To implement an ATA task file transfer (read or write), perform the following steps:†
  1. Write the data size in bytes to the bytcnt register. bytcnt must equal the block size, because the controller expects a single block transfer.†
  2. Write the block size in bytes to the blksiz register.†
  3. Write the cmdarg register with the beginning register address.†

You must set the cmdarg, cmd, blksiz, and bytcnt registers according to the tables in Register Settings for ATA Task File Transfer.†

Register Settings for ATA Task File Transfer

Table 151.  cmdarg Register Settings for ATA Task File Transfer†
Bit Value Comment

31

1 or 0

Set to 0 for read operation or set to 1 for write operation

30:24

0

Reserved (bits set to 0 by host processor)

23:18

0

Starting register address for read or write (DWORD aligned)

17:16

0

Register address (DWORD aligned)

15:8

0

Reserved (bits set to 0 by host processor)

7:2

16

Number of bytes to read or write (integral number of DWORD)

1:0

0

Byte count in integral number of DWORD

Table 152.  cmd Register Settings for ATA Task File Transfer†
Bit Value Comment
start_cmd

1

 
ccs_expected

0

CCS is not expected

read_ceata_device

0 or 1

Set to 1 if RW_BLK or RW_REG read

update_clk_regs_only

0

No clock parameters update command

card_num

0

 
send_initialization

0

No initialization sequence

stop_abort_cmd

0

 
send_auto_stop

0

 
transfer_mode

0

Block transfer mode. Block size and byte count must match number of bytes to read or write

read_write

1 or 0

1 for write and 0 for read

data_expected

1

Data is expected

response_length

0

 
response_expect

1

 
cmd_index

Command index

Set this parameter to the command number. For example, set to 24 for SD/SDIO WRITE_BLOCK (CMD24) or 25 for WRITE_MULTIPLE_BLOCK (CMD25).

wait_prvdata_complete

1

  • 0 for send command immediately
  • 1 for send command after previous DTO interrupt
check_response_crc

1

  • 0 for not checking response CRC
  • 1 for checking response CRC
Table 153.  blksiz Register Settings for ATA Task File Transfer†
Bit Value Comment

31:16

0

Reserved bits set to 0

15:0 (block_size)

16

For accessing entire task file (16, 8‑bit registers). Block size of 16 bytes

Table 154.  bytcnt Register Settings for ATA Task File Transfer
Bit Value Comment

31:0

16

For accessing entire task file (16, 8‑bit registers). Byte count value of 16 is used with the block size set to 16.

Reset and Card Device Discovery Overview

Before starting any CE‑ATA operations, the host must perform a MMC reset and initialization procedure. The host and card device must negotiate the MMC transfer (MMC TRAN) state before the card enters the MMC TRAN state.†

The host must follow the existing MMC discovery procedure to negotiate the MMC TRAN state. After completing normal MMC reset and initialization procedures, the host must query the initial ATA task file values using the RW_REG or CMD39 command.†

By default, the MMC block size is 512 bytes—indicated by bits 1:0 of the srcControl register inside the CE‑ATA card device. The host can negotiate the use of a 1 KB or 4 KB MMC block sizes. The card indicates MMC block sizes that it can support through the srcCapabilities register in the MMC; the host reads this register to negotiate the MMC block size. Negotiation is complete when the host controller writes the MMC block size into the srcControl register bits 1:0 of the card.†

ATA Payload Transfer Using the RW_MULTIPLE_BLOCK (RW_BLK) Command

This command involves data transfer between the CE‑ATA card device and the controller. To send a data command, the controller needs a command argument, total data size, and block size. Software receives or sends data through the FIFO buffer. †

Implementing ATA Payload Transfer

To implement an ATA payload transfer (read or write), perform the following steps:†
  1. Write the data size in bytes to the bytcnt register.†
  2. Write the block size in bytes to the blksiz register. The controller expects a single/multiple block transfer.†
  3. Write to the cmdarg register to indicate the data unit count.†

Register Settings for ATA Payload Transfer

You must set the cmdarg, cmd, blksiz, and bytcnt registers according to the following tables.†
Table 155.  cmdarg Register Settings for ATA Payload Transfer†
Bits Value Comment

31

1 or 0

Set to 0 for read operation or set to 1 for write operation

30:24

0

Reserved (bits set to 0 by host processor)

23:16

0

Reserved (bits set to 0 by host processor)

15:8

Data count

Data Count Unit [15:8]

7:0

Data count

Data Count Unit [7:0]

Table 156.  cmd Register Settings for ATA Payload Transfer†
Bits Value Comment
start_cmd

1

-
ccs_expected

1

CCS is expected. Set to 1 for the RW_BLK command if interrupts are enabled in CE‑ATA card device (the nIEN bit is set to 0 in the ATA control register)

read_ceata_device

0 or 1

Set to 1 for a RW_BLK or RW_REG read command

update_clk_regs_only

0

No clock parameters update command

card_num

0

-
send_initialization

0

No initialization sequence

stop_abort_cmd

0

-
send_auto_stop

0

-
transfer_mode

0

Block transfer mode. Byte count must be integer multiple of 4kB. Block size can be 512, 1k or 4k bytes

read_write

1 or 0

1 for write and 0 for read

data_expected

1

Data is expected

response_length

0

-
response_expect

1

-
cmd_index

Command index

Set this parameter to the command number. For example, set to 24 for SD/SDIO WRITE_BLOCK (CMD24) or 25 for WRITE_MULTIPLE_BLOCK (CMD25).

wait_prvdata_complete

1

  • 0 for send command immediately
  • 1 for send command after previous DTO interrupt
check_response_crc

1

  • 0 for not checking response CRC
  • 1 for checking response CRC
Table 157.  blksiz Register Settings for ATA Payload Transfer†
Bits Value Comment

31:16

0

Reserved bits set to 0

15:0 (block_size)

512, 1024 or 4096

MMC block size can be 512, 1024 or 4096 bytes as negotiated by host

Table 158.  bytcnt Register Settings for ATA Payload Transfer
Bits Value Comment

31:0

<n>*block_size

Byte count must be an integer multiple of the block size. For ATA media access commands, byte count must be a multiple of 4 KB.

(<n>*block_size = <x>*4 KB, where <n> and <x> are integers)

CE-ATA CCS

This section describes disabling the CCS, recovery after CCS timeout, and recovery after I/O read transmission delay (NACIO) timeout. †

Disabling the CCS

While waiting for the CCS for an outstanding RW_BLK command, the host can disable the CCS by sending a CCSD command:†
  • Send a CCSD command—the controller sends the CCSD command to the CE‑ATA card device if the send_ccsd bit is set to 1 in the ctrl register of the controller. This bit can be set only after a response is received for the RW_BLK command.†
  • Send an internal stop command—send an internally-generated SD/SDIO STOP_TRANSMISSION (CMD12) command after sending the CCSD pattern. If the send_auto_stop_ccsd bit of the ctrl register is also set to 1 when the controller is set to send the CCSD pattern, the controller sends the internally-generated STOP command to the CMD pin. After sending the STOP command, the controller sets the acd bit in the rintsts register to 1.†

Recovery after CCS Timeout

If a timeout occurs while waiting for the CCS, the host needs to send the CCSD command followed by a STOP command to abort the pending ATA command. The host can set up the controller to send an internally-generated STOP command after sending the CCSD pattern:†
  • Send CCSD command—set the send_ccsd bit in the ctrl register to 1.†
  • Send external STOP command—terminate the data transfer between the CE‑ATA card device and the controller. For more information about sending the STOP command, refer to Transfer Stop and Abort Commands.†
  • Send internal STOP command—set the send_auto_stop_ccsd bit in the ctrl register to 1, which tells the controller to send the internally-generated STOP command. After sending the STOP command, the controller sets the acd bit in the rintsts register to 1. The send_auto_stop_ccsd bit must be set to 1 along with setting the send_ccsd bit.†

Recovery after I/O Read Transmission Delay (NACIO) Timeout

If the I/O read transmission delay (NACIO) timeout occurs for the CE‑ATA card device, perform one of the following steps to recover from the timeout:†
  • If the CCS is expected from the CE‑ATA card device (that is, the ccs_expected bit is set to 1 in the cmd register), follow the steps in Recovery after CCS Timeout.†
  • If the CCS is not expected from the CE‑ATA card device, perform the following steps: †
    1. Send an external STOP command. †
    2. Terminate the data transfer between the controller and CE‑ATA card device. †

Reduced ATA Command Set

It is necessary for the CE‑ATA card device to support the reduced ATA command subset. This section describes the reduced command set.†

The IDENTIFY DEVICE Command

The IDENTIFY DEVICE command returns a 512‑byte data structure to the host that describes device‑specific information and capabilities. The host issues the IDENTIFY DEVICE command only if the MMC block size is set to 512 bytes. Any other MMC block size has indeterminate results.†

The host issues a RW_REG command for the ATA command, and the data is retrieved with the RW_BLK command.†

The host controller uses the following settings while sending a RW_REG command for the IDENTIFY DEVICE ATA command. The following list shows the primary bit settings:†

  • cmd register setting: data_expected bit set to 0†
  • cmdarg register settings: †
    • Bit [31] set to 0†
    • Bits [7:2] set to 128 †
    • All other bits set to 0†
  • Task file settings: †
    • Command field of the ATA task file set to 0xEC†
    • Reserved fields of the task file set to 0†
  • bytcnt register and block_size field of the blksiz register: set to 16†

The host controller uses the following settings for data retrieval (RW_BLK command):†

  • cmd register settings:†
    • ccs_expected set to 1†
    • data_expected set to 1†
  • cmdarg register settings: †
    • Bit [31] set to 0 (read operation) †
    • Bits [15:0] set to 1 (data unit count = 1)†
    • All other bits set to 0†
  • bytcnt register and block_size field of the blksiz register: set to 512†

The READ DMA EXT Command

The READ DMA EXT command reads a number of logical blocks of data from the card device using the Data‑In data transfer protocol. The host uses a RW_REG command to issue the ATA command and the RW_BLK command for the data transfer.†

The WRITE DMA EXT Command

The WRITE DMA EXT command writes a number of logical blocks of data to the card device using the Data‑Out data transfer protocol. The host uses a RW_REG command to issue the ATA command and the RW_BLK command for the data transfer.†

The STANDBY IMMEDIATE Command

This ATA command causes the card device to immediately enter the most aggressive power management mode that still retains internal device context. No data transfer (RW_BLK) is expected for this command.†

For card devices that do not provide a power savings mode, the STANDBY IMMEDIATE command returns a successful status indication. The host issues a RW_REG command for the ATA command, and the status is retrieved with the SD/SDIO CMD39 or RW_REG command. Only the status field of the ATA task file contains the success status; there is no error status.†

The host controller uses the following settings while sending the RW_REG command for the STANDBY IMMEDIATE ATA command: †

  • cmd register setting: data_expected bit set to 0†
  • cmdarg register settings: †
    • Bit [31] set to 1 †
    • Bits [7:2] set to 4 †
    • All other bits set to 0 †
  • Task file settings: †
    • Command field of the ATA task file set to 0xE0†
    • Reserved fields of the task file set to 0†
  • bytcnt register and block_size field of the blksiz register: set to 16 †

The FLUSH CACHE EXT Command

For card devices that buffer/cache written data, the FLUSH CACHE EXT command ensures that buffered data is written to the card media. For cards that do not buffer written data, the FLUSH CACHE EXT command returns a success status. No data transfer (RW_BLK) is expected for this ATA command. †

The host issues a RW_REG command for the ATA command, and the status is retrieved with the SD/SDIO CMD39 or RW_REG command. There can be error status for this ATA command, in which case fields other than the status field of the ATA task file are valid.†

The host controller uses the following settings while sending the RW_REG command for the STANDBY IMMEDIATE ATA command:†

  • cmd register setting: data_expected bit set to 0 †
  • cmdarg register settings: †
    • Bit [31] set to 1 †
    • Bits [7:2] set to 4†
    • All other bits set to 0†
  • Task file settings: †
    • Command field of the ATA task file set to 0xEA †
    • Reserved fields of the task file set to 0†
  • bytcnt register and block_size field of the blksiz register: set to 16 †

Card Read Threshold

When an application needs to perform a single or multiple block read command, the application must set the cardthrctl register with the appropriate card read threshold size in the card read threshold field (cardrdthreshold) and set the cardrdthren bit to 1. This additional information specified in the controller ensures that the controller sends a read command only if there is space equal to the card read threshold available in the RX FIFO buffer. This in turn ensures that the card clock is not stopped in the middle a block of data being transmitted from the card. Set the card read threshold to the block size of the transfer to guarantee there is a minimum of one block size of space in the RX FIFO buffer before the controller enables the card clock. †

The card read threshold is required when the round trip delay is greater than half of sdmmc_clk_divided.†

Table 159.  Card Read Threshold Guidelines†
Bus Speed Modes Round Trip Delay (Delay_R) 51 Is Stopping of Card Clock Allowed? Card Read Threshold Required?

SDR25

Delay_R > 0.5 * (sdmmc_clk/4)

Delay_R < 0.5 * (sdmmc_clk/4)

No

Yes

Yes

No

SDR12

Delay_R > 0.5 * (sdmmc_clk/4)

Delay_R < 0.5 * (sdmmc_clk/4)

No

Yes

Yes

No

Recommended Usage Guidelines for Card Read Threshold

  1. The cardthrctl register must be set before setting the cmd register for a data read command.†
  2. The cardthrctl register must not be set while a data transfer command is in progress.†
  3. The cardrdthreshold field of the cardthrctl register must be set to at the least the block size of a single or multiblock transfer. A cardrdthreshold field setting greater than or equal to the block size of the read transfer ensures that the card clock does not stop in the middle of a block of data.†
  4. If the round trip delay is greater than half of the card clock period, card read threshold must be enabled and the card threshold must be set as per guideline 3 to guarantee that the card clock does not stop in the middle of a block of data.†
  5. If the cardrdthreshold field is set to less than the block size of the transfer, the host must ensure that the receive FIFO buffer never overflows during the read transfer. Overflow can cause the card clock from the controller to stop. The controller is not able to guarantee that the card clock does not stop during a read transfer.†
Note: If the cardrdthreshold field of the cardthrctl register, and the rx_wmark and dw_dma_multiple_transaction_size fields of the fifoth register are set incorrectly, the card clock might stop indefinitely, with no interrupts generated by the controller.†

Card Read Threshold Programming Sequence

Most cards, such as SDHC or SDXC, support block sizes that are either specified in the card or are fixed to 512 bytes. For SDIO, MMC, and standard capacity SD cards that support partial block read (READ_BL_PARTIAL set to 1 in the CSD register of the card device), the block size is variable and can be chosen by the application.†

To use the card read threshold feature effectively and to guarantee that the card clock does not stop because of a FIFO Full condition in the middle of a block of data being read from the card, follow these steps:†

  1. Choose a block size that is a multiple of four bytes.†
  2. Enable card read threshold feature. The card read threshold can be enabled only if the block size for the given transfer is less than or equal to the total depth of the FIFO buffer:†

    (block size / 4) ≤ 1024†

  3. Choose the card read threshold value: †
    • If (block size / 4) ≥ 512, choose cardrdthreshold such that:†
      • cardrdthreshold ≤ (block size / 4) in bytes†
    • If (block size / 4) < 512, choose cardrdthreshold such that:†
      • cardrdthreshold = (block size / 4) in bytes†
  4. Set the dw_dma_multiple_transaction_size field in the fifoth register to the number of transfers that make up a DMA transaction. For example, size = 1 means 4 bytes are moved. The possible values for the size are 1, 4, 8, 16, 32, 64, 128, and 256 transfers. Select the size so that the value (block size / 4) is evenly divided by the size.†
  5. Set the rx_wmark field in the fifoth register to the size – 1.†

For example, if your block size is 512 bytes, legal values of dw_dma_multiple_transaction_size and rx_wmark are listed in the following table.

Table 160.  Legal Values of dw_dma_multiple_transaction_size and rx_wmark for Block Size = 512†
Block Size dw_dma_multiple_transaction_size rx_wmark

512

1

0

512

4

3

512

8

7

512

16

15

512

32

31

512

64

63

512

128

127

Card Read Threshold Programming Examples

This section shows examples of how to program the card read threshold.†
  • Choose a block size that is a multiple of 4 (the number of bytes per FIFO location), and less than 4096 (1024 FIFO locations). For example, a block size of 3072 bytes is legal, because 3072 / 4 = 768 FIFO locations.†
  • For DMA mode, choose the size so that block size is a multiple of the size. For example size = 128, where block size%size = 0.†
  • Set the rx_wmark field = size – 1. For example, the rx_wmark field = 128 – 1 = 127.†
  • Because block size > ½ FifoDepth, set the cardrdthreshold field to the block size. For example, the cardrdthreshold field = 3072 bytes.†
Figure 64. FIFO Buffer content when Card Read Threshold is set to 768†

Interrupt and Error Handling

This section describes how to use interrupts to handle errors. On power‑on or reset, interrupts are disabled (the int_enable bit in the ctrl register is set to 0), and all the interrupts are masked (the intmask register default is 0). The controller error handling includes the following types of errors:
  • Response and data timeout errors—For response time‑outs, the host software can retry the command. For data time‑outs, the controller has not received the data start bit from the card, so software can either retry the whole data transfer again or retry from a specified block onwards. By reading the contents of the tcbcnt register later, the software can decide how many bytes remain to be copied (read). †
  • Response errors—Set to 1 when an error is received during response reception. If the response received is invalid, the software can retry the command. †
  • Data errors—Set to 1 when a data receive error occurs. Examples of data receive errors: †
    • Data CRC†
    • Start bit not found †
    • End bit not found †

    These errors can be occur on any block. On receipt of an error, the software can issue an SD/SDIO STOP or SEND_IF_COND command, and retry the command for either the whole data or partial data.†

  • Hardware locked error—Set to 1 when the controller cannot load a command issued by software. When software sets the start_cmd bit in the cmd register to 1, the controller tries to load the command. If the command buffer already contains a command, this error is raised, and the new command is discarded, requiring the software to reload the command.†
  • FIFO buffer underrun/overrun error—If the FIFO buffer is full and software tries to write data to the FIFO buffer, an overrun error is set. Conversely, if the FIFO buffer is empty and the software tries to read data from the FIFO buffer, an underrun error is set. Before reading or writing data in the FIFO buffer, the software must read the FIFO buffer empty bit (fifo_empty) or FIFO buffer full bit (fifo_full) in the status register.†
  • Data starvation by host timeout—This condition occurs when software does not service the FIFO buffer fast enough to keep up with the controller. Under this condition and when a read transfer is in process, the software must read data from the FIFO buffer, which creates space for further data reception. When a transmit operation is in process, the software must write data to fill the FIFO buffer so that the controller can write the data to the card.†
  • CE‑ATA errors†
  • CRC error on command—If a CRC error is detected for a command, the CE‑ATA card device does not send a response, and a response timeout is expected from the controller. The ATA layer is notified that an MMC transport layer error occurred.
  • CRC error on command—If a CRC error is detected for a command, the CE‑ATA card device does not send a response, and a response timeout is expected from the controller. The ATA layer is notified that an MMC transport layer error occurred.†
  • Write operation—Any MMC transport layer error known to the card device causes an outstanding ATA command to be terminated. The ERR bits are set in the ATA status registers and the appropriate error code is sent to the Error Register (Error) on the ATA card device.†

    If the device interrupt bit of the CE‑ATA card (the nIEN bit in the ATA control register) is set to 0, the CCS is sent to the host.†

    If the device interrupt bit is set to 1, the card device completes the entire data unit count if the host controller does not abort the ongoing transfer.†

    Note: During a multiple‑block data transfer, if a negative CRC status is received from the card device, the data path signals a data CRC error to the BIU by setting the dcrc bit in the rintsts register to 1. It then continues further data transmission until all the bytes are transmitted.†
  • Read operation—If MMC transport layer errors are detected by the host controller, the host completes the ATA command with an error status. The host controller can issue a CCSD command followed by a STOP_TRANSMISSION (CMD12) command to abort the read transfer. The host can also transfer the entire data unit count bytes without aborting the data transfer.†

Booting Operation for eMMC and MMC

This section describes how to set up the controller for eMMC and MMC boot operation.

Note: The BootROM and initial software do not use the boot partitions that are in the MMC card. This means that there is no boot partition support of the SD/MMC controller.

Boot Operation by Holding Down the CMD Line

The controller can boot from MMC4.3, MMC4.4, and MMC4.41 cards by holding down the CMD line.

For information about this boot method, refer to the following specifications, available on the JEDEC website:

  • JEDEC Standard No. 84‑A441
  • JEDEC Standard No. 84‑A44
  • JEDEC Standard No. JESD84‑A43

Boot Operation for eMMC Card Device

The following figure illustrates the steps to perform the boot process for eMMC card devices. The detailed steps are described following the flow chart.
Figure 65. Flow for eMMC Boot Operation†
  1. The software driver performs the following checks: †
    • If the eMMC card device supports boot operation (the BOOT_PARTITION_ENABLE bit is set to 1 in the EXT_CSD register of the eMMC card).†
    • The BOOT_SIZE_MULT and BOOT_BUS_WIDTH values in the EXT_CSD register, to be used during the boot process.†
  2. The software sets the following bits: †
    • Sets masks for interrupts, by setting the appropriate bits to 0 in the intmask register.†
    • Sets the global int_enable bit of the ctrl register to 1. Other bits in the ctrl register must be set to 0. †
      Note: Intel recommends that you write 0xFFFFFFFF to the rintsts and idsts registers to clear any pending interrupts before setting the int_enable bit. For internal DMA controller mode, the software driver needs to unmask all the relevant fields in the idinten register.†
  3. If the software driver needs to use the internal DMA controller to transfer the boot data received, it must perform the following steps: †
    • Set up the descriptors as described in Internal DMA Controller Transmission Sequences and Internal DMA Controller Reception Sequences”. †
    • Set the use_internal_dmac bit of the ctrl register to 1.†
  4. Set the card device frequency to 400 kHz using the clkdiv registers. For more information, refer to Clock Setup.†
  5. Set the data_timeout field of the tmout register equal to the card device total access time, NAC. †
  6. Set the blksiz register to 0x200 (512 bytes). †
  7. Set the bytcnt register to a multiple of 128 KB, as indicated by the BOOT_SIZE_MULT value in the card device.†
  8. Set the rx_wmark field in the fifoth register. Typically, the threshold value can be set to 512, which is half the FIFO buffer depth.†
  9. Set the following fields in the cmd register:†
    • Initiate the command by setting start_cmd = 1†
    • Enable boot (enable_boot) = 1†
    • Expect boot acknowledge (expect_boot_ack): †
      • If a start‑acknowledge pattern is expected from the card device, set expect_boot_ack to 1.†
      • If a start‑acknowledge pattern is not expected from the card device, set expect_boot_ack to 0.†
    • Card number (card_number) = 0†
    • data_expected = 1†
    • Reset the remainder of cmd register bits to 0†
  10. If no start‑acknowledge pattern is expected from the card device (expect_boot_ack set to 0) proceed to step 12.†
  11. This step handles the case where a start‑acknowledge pattern is expected (expect_boot_ack was set to 1 in step 9).†
    1. If the Boot ACK Received interrupt is not received from the controller within 50 ms of initiating the command (step 9), the software driver must set the following cmd register fields: †
      • start_cmd = 1†
      • Disable boot (disable_boot)= 1†
      • card_number = 0 †
      • All other fields = 0†

      The controller generates a Command Done interrupt after deasserting the CMD pin of the card interface.†

      If internal DMA controller mode is used for the boot process, the controller performs the following steps after the Boot ACK Received timeout:†

      • The DMA descriptor is closed.†
      • The ces bit in the idsts register is set, indicating the Boot ACK Received timeout.†
      • The ri bit of the idsts register is not set.†
    2. If the Boot ACK Received interrupt is received, the software driver must clear this interrupt by writing 1 to the ces bit in the idsts register.†

      Within 0.95 seconds of the Boot ACK Received interrupt, the Boot Data Start interrupt must be received from the controller. If this does not occur, the software driver must write the following cmd register fields:†

      • start_cmd = 1†
      • disable_boot = 1†
      • card_number = 0†
      • All other fields = 0†

      The controller generates a Command Done interrupt after deasserting the CMD pin of the card interface.†

      If internal DMA controller mode is used for the boot process, the controller performs the following steps after the Boot ACK Received timeout:†

      • The DMA descriptor is closed†
      • The ces bit in the idsts register is set, indicating Boot Data Start timeout†
      • The ri bit of the idsts register is not set†
    3. If the Boot Data Start interrupt is received, it indicates that the boot data is being received from the card device. When the DMA engine is not in internal DMA controller mode, the software driver can then initiate a data read from the controller based on the rxdr interrupt bit in the rintsts register.†

      In internal DMA controller mode, the DMA engine starts transferring the data from the FIFO buffer to the system memory as soon as the level set in the rx_wmark field of the fifoth register is reached.†

      At the end of a successful boot data transfer from the card, the following interrupts are generated:†

      • The cmd bit and dto bit in the rintsts register†
      • The ri bit in the idsts register, in internal DMA controller mode only†
    4. If an error occurs in the boot ACK pattern (0b010) or an EBE occurs: †
      • The controller automatically aborts the boot process by pulling the CMD line high†
      • The controller generates a Command Done interrupt†
      • The controller does not generate a Boot ACK Received interrupt†
      • The application aborts the boot transfer†
    5. In internal DMA controller mode:†
      • If the software driver creates more descriptors than required by the received boot data, the extra descriptors are not closed by the controller. Software cannot reuse the descriptors until they are closed.†
      • If the software driver creates fewer descriptors than required by the received boot data, the controller generates a Descriptor Unavailable interrupt and does not transfer any further data to system memory.†
    6. If NAC is violated between data block transfers, the DRTO interrupt is asserted. In addition, if there is an error associated with the start or end bit, the SBE or EBE interrupt is also generated.†

    The boot operation for eMMC card devices is complete. Do not execute the remaining (step 12).†

  12. This step handles the case where no start‑acknowledge pattern is expected (expect_boot_ack was set to 0 in step 9).†
    1. If the Boot Data Start interrupt is not received from the controller within 1 second of initiating the command (step 9), the software driver must write the cmd register with the following fields:†
      • start_cmd = 1†
      • disable_boot = 1†
      • card_number = 0†
      • All other fields = 0†

      The controller generates a Command Done interrupt after deasserting the CMD line of the card. In internal DMA controller mode, the descriptor is closed and the ces bit in the idsts register is set to 1, indicating a Boot Data Start timeout.†

    2. If a Boot Data Start interrupt is received, it indicates that the boot data is being received from the card device. When the DMA engine is not in internal DMA controller mode, the software driver can then initiate a data read from the controller based on the rxdr interrupt bit in the rintsts register.†

      In internal DMA controller mode, the DMA engine starts transferring the data from the FIFO buffer to the system memory as soon as the level specified in the rx_wmark field of the fifoth register is reached.†

      At the end of a successful boot data transfer from the card, the following interrupts are generated:†

      • The cmd bit and dto bit in the rintsts register†
      • The ri bit in the idsts register, in internal DMA controller mode only†
    3. In internal DMA controller mode:†
      • If the software driver creates more descriptors than required by the received boot data, the extra descriptors are not closed by the controller.†
      • If the software driver creates fewer descriptors than required by the received boot data, the controller generates a Descriptor Unavailable interrupt and does not transfer any further data to system memory.†

    The boot operation for eMMC card devices is complete.†

Boot Operation for Removable MMC4.3, MMC4.4 and MMC4.41 Cards

Removable MMC4.3, MMC4.4, and MMC4.41 Differences

Removable MMC4.3, MMC4.4, and MMC4.41 cards differ with respect to eMMC in that the controller is not aware whether these cards support the boot mode of operation when plugged in. Thus, the controller must: †
  1. Discover these cards as it would discover MMC4.0/4.1/4.2 cards for the first time†
  2. Know the card characteristics †
  3. Decide whether to perform a boot operation or not†

Booting Removable MMC4.3, MMC4.4 and MMC4.41 Cards

For removable MMC4.3, MMC4.4 and MMC4.41 cards, the software driver must perform the following steps:†
  1. Discover the card as described in Enumerated Card Stack.†
  2. Read the EXT_CSD register of the card and examine the following fields: †
    • BOOT_PARTITION_ENABLE †
    • BOOT_SIZE_MULT†
    • BOOT_INFO †
  3. If necessary, the software can manipulate the boot information in the card. †
    Note: For more information, refer to “Access to Boot Partition” in the following specifications available on the JEDEC website:
    • JEDEC Standard No. 84‑A441
    • JEDEC Standard No. 84‑A44
    • JEDEC Standard No. JESD84‑A43
  4. If the host processor needs to perform a boot operation at the next power‑up cycle, it can manipulate the EXT_CSD register contents by using a SWITCH_FUNC command. †
  5. After this step, the software driver must power down the card by writing to the pwren register. †
  6. From here on, use the same steps as in Alternative Boot Operation for eMMC Card Devices.†

Alternative Boot Operation

The alternative boot operation differs from the previous boot operation in that software uses the SD/SDIO GO_IDLE_STATE command to boot the card, rather than holding down the CMD line of the card. The alternative boot operation can be performed only if bit 0 in the BOOT_INFO register is set to 1. BOOT_INFO is located at offset 228 in the EXT_CSD registers. †

For detailed information about alternative boot operation, refer to the following specifications available on the JEDEC website:

  • JEDEC Standard No. 84‑A441
  • JEDEC Standard No. 84‑A44
  • JEDEC Standard No. JESD84‑A43

Alternative Boot Operation for eMMC Card Devices

The following figure illustrates the sequence of steps required to perform the alternative boot operation for eMMC card devices. The detailed steps are described following the flow chart.
Figure 66. Flow for eMMC Alternative Boot Operation†
  1. The software driver checks:†
    • If the eMMC card device supports alternative boot operation (the BOOT_INFO bit is set to 1 in the eMMC card).†
    • The BOOT_SIZE_MULT and BOOT_BUS_WIDTH values in the card device to use during the boot process.†
  2. The software sets the following bits: †
    • Sets masks for interrupts by resetting the appropriate bits to 0 in the intmask register.†
    • Sets the int_enable bit of the ctrl register to 1. Other bits in the ctrl register must be set to 0. †
      Note: Intel recommends writing 0xFFFFFFFF to the rintsts register and idsts register to clear any pending interrupts before setting the int_enable bit. For internal DMA controller mode, the software driver needs to unmask all the relevant fields in the idinten register.†
  3. If the software driver needs to use the internal DMA controller to transfer the boot data received, it must perform the following actions: †
    • Set up the descriptors as described in Internal DMA Controller Transmission Sequences and Internal DMA Controller Reception Sequences. †
    • Set the use internal DMAC bit (use_internal_dmac) of the ctrl register to 1. †
  4. Set the card device frequency to 400 kHz using the clkdiv registers. For more information, refer to Clock Setup. Ensure that the card clock is running.†
  5. Wait for a time that ensures that at least 74 card clock cycles have occurred on the card interface.†
  6. Set the data_timeout field of the tmout register equal to the card device total access time, NAC. †
  7. Set the blksiz register to 0x200 (512 bytes).†
  8. Set the bytcnt register to multiples of 128K bytes, as indicated by the BOOT_SIZE_MULT value in the card device.†
  9. Set the rx_wmark field in the fifoth register. Typically, the threshold value can be set to 512, which is half the FIFO buffer depth.†
  10. Set the cmdarg register to 0xFFFFFFFA. †
  11. Initiate the command, by setting the cmd register with the following fields: †
    • start_cmd = 1†
    • enable_boot = 1†
    • expect_boot_ack:†
      • If a start‑acknowledge pattern is expected from the card device, set expect_boot_ack to 1.†
      • If a start‑acknowledge pattern is not expected from the card device, set expect_boot_ack to 0. †
    • card_number = 0 †
    • data_expected = 1†
    • cmd_index = 0†
    • Set the remainder of cmd register bits to 0.†
  12. If no start‑acknowledge pattern is expected from the card device (expect_boot_ack set to 0) jump to step 15. †
  13. Wait for the Command Done interrupt.†
  14. This step handles the case where a start‑acknowledge pattern is expected (expect_boot_ack was set to 1 in step 11).†
    1. If the Boot ACK Received interrupt is not received from the controller within 50 ms of initiating the command (step 11), the start pattern was not received. The software driver must discontinue the boot process and start with normal discovery. †

      If internal DMA controller mode is used for the boot process, the controller performs the following steps after the Boot ACK Received timeout:†

      • The DMA descriptor is closed.†
      • The ces bit in the idsts register is set to 1, indicating the Boot ACK Received timeout.†
      • The ri bit of the idsts register is not set.†
    2. If the Boot ACK Received interrupt is received, the software driver must clear this interrupt by writing 1 to it. †

      Within 0.95 seconds of the Boot ACK Received interrupt, the Boot Data Start interrupt must be received from the controller. If this does not occur, the software driver must discontinue the boot process and start with normal discovery.†

      If internal DMA controller mode is used for the boot process, the controller performs the following steps after the Boot ACK Received timeout: †

      • The DMA descriptor is closed.†
      • The ces bit in the idsts register is set to 1, indicating Boot Data Start timeout.†
      • The ri bit of the idsts register is not set.†
    3. If the Boot Data Start interrupt is received, it indicates that the boot data is being received from the card device. When the DMA engine is not in internal DMA controller mode, the software driver can then initiate a data read from the controller based on the rxdr interrupt bit in the rintsts register.†

      In internal DMA controller mode, the DMA engine starts transferring the data from the FIFO buffer to the system memory as soon as the level specified in the rx_wmark field of the fifoth register is reached. †

    4. The software driver must terminate the boot process by instructing the controller to send the SD/SDIO GO_IDLE_STATE command:†
      • Reset the cmdarg register to 0.†
      • Set the start_cmd bit of the cmd register to 1, and all other bits to 0.†
    5. At the end of a successful boot data transfer from the card, the following interrupts are generated: †
      • The cmd bit and dto bit in the rintsts register†
      • The ri bit in the idsts register, in internal DMA controller mode only†
    6. If an error occurs in the boot ACK pattern (0b010) or an EBE occurs: †
      • The controller does not generate a Boot ACK Received interrupt. †
      • The controller detects Boot Data Start and generates a Boot Data Start interrupt. †
      • The controller continues to receive boot data. †
      • The application must abort the boot process after receiving a Boot Data Start interrupt.†
    7. In internal DMA controller mode: †
      • If the software driver creates more descriptors than required by the received boot data, the extra descriptors are not closed by the controller. †
      • If the software driver creates fewer descriptors than required by the received boot data, the controller generates a Descriptor Unavailable interrupt and does not transfer any further data to system memory.†
    8. If NAC is violated between data block transfers, a DRTO interrupt is asserted. Apart from this, if there is an error associated with the start or end bit, the SBE or EBE interrupt is also generated.†

    The alternative boot operation for eMMC card devices is complete. Do not execute the remaining steps (15 and 16). †

  15. Wait for the Command Done interrupt.†
  16. This step handles the case where a start‑acknowledge pattern is not expected (expect_boot_ack was set to 0 in step 11). †
    1. If the Boot Data Start interrupt is not received from the controller within 1 second of initiating the command (step 11), the software driver must discontinue the boot process and start with normal discovery. † In internal DMA controller mode:†
      • The DMA descriptor is closed.†
      • The ces bit in the idsts register is set to 1, indicating Boot Data Start timeout.†
      • The ri bit of the idsts register is not set.†
    2. If a Boot Data Start interrupt is received, the boot data is being received from the card device. When the DMA engine is not in internal DMA controller mode, the software driver can then initiate a data read from the controller based on the rxdr interrupt bit in the rintsts register.†

      In internal DMA controller mode, the DMA engine starts transferring the data from the FIFO buffer to the system memory as soon as the level specified in the rx_wmark field of the fifoth register is reached.†

    3. The software driver must terminate the boot process by instructing the controller to send the SD/SDIO GO_IDLE_STATE (CMD0) command: †
      • Reset the cmdarg register to 0.†
      • Set the start_cmd bit in the cmd register to 1, and all other bits to 0.†
    4. At the end of a successful boot data transfer from the card, the following interrupts are generated: †
      • The cmd bit and dto bit in the rintsts register†
      • The ri bit in the idsts register, in internal DMA controller mode only †
    5. In internal DMA controller mode: †
      • If the software driver creates more descriptors than required by the received boot data, the extra descriptors are not closed by the controller. †
      • If the software driver creates fewer descriptors than required by the received boot data, the controller generates a Descriptor Unavailable interrupt and does not transfer any further data to system memory.†

The alternative boot operation for eMMC card devices is complete.†

Alternative Boot Operation for MMC4.3 Cards

Removable MMC4.3 Boot Mode Support

Removable MMC4.3 cards differ with respect to eMMC in that the controller is not aware whether these cards support the boot mode of operation. Thus, the controller must: †
  1. Discover these cards as it would discover MMC4.0/4.1/4.2 cards for the first time †
  2. Know the card characteristics †
  3. Decide whether to perform a boot operation or not†

Discovering Removable MMC4.3 Boot Mode Support

For removable MMC4.3 cards, the software driver must perform the following steps: †
  1. Discover the card as described in Enumerated Card Stack.†
  2. Read the MMC card device’s EXT_CSD registers and examine the following fields: †
    • BOOT_PARTITION_ENABLE †
    • BOOT_SIZE_MULT †
    • BOOT_INFO †
    Note: For more information, refer to "Access to Boot Partition” in JEDEC Standard No. JESD84‑A43, available on the JEDEC website.†
  3. If the host processor needs to perform a boot operation at the next power‑up cycle, it can manipulate the contents of the EXT_CSD registers in the MMC card device, by using a SWITCH_FUNC command. †
  4. After this step, the software driver must power down the card by writing to the pwren register. †
  5. From here on, use the same steps as in Alternative Boot Operation for eMMC Card Devices. †
    Note: Ignore the EBE if it is generated during an abort scenario.

    If a boot acknowledge error occurs, the boot acknowledge received interrupt times out. †

    In internal DMA controller mode, the application needs to depend on the descriptor close interrupt instead of the data done interrupt. †

50 This is the case for the following peripherals: SD/MMC, NAND, On-Chip, DMA, USB, and EMAC.
51

Delay_R = Delay_O + tODLY + Delay_I †

Where: †

Delay_O = sdmmc_clk to sdmmc_cclk_out delay (including I/O pin delay) †

Delay_I = Input I/O pin delay + routing delay to the input register †

tODLY = sdmmc_cclk_out to card output delay (varies across card manufactures and speed modes) †

For the delay numbers needed for above calculation, refer to Cyclone V Datasheet. †

Level Two Title