Intel® Arria® 10 Hard Processor System Technical Reference Manual

Download PDF
ID 683711
Date 1/10/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. Intel® Arria® 10 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. SoC Security 8. System Interconnect 9. HPS-FPGA Bridges 10. Cortex*-A9 Microprocessor Unit Subsystem 11. CoreSight* Debug and Trace 12. Error Checking and Correction Controller 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. Hard Processor System I/O Pin Multiplexing 27. Introduction to the HPS Component 28. Instantiating the HPS Component 29. HPS Component Interfaces 30. Simulating the HPS Component 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.10. Hard Processor System I/O Pin Multiplexing
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. Arria 10 HPS SDRAM L3 Interconnect
2.2.4.1. Arria 10 HPS SDRAM L3 Interconnect x
2.2.4.1.1. SDRAM Adapter 2.2.4.1.2. SDRAM Scheduler
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. Security Manager 2.2.7.4. System Manager 2.2.7.5. System Timers 2.2.7.6. System Watchdog Timers 2.2.7.7. DMA Controller 2.2.7.8. FPGA Manager 2.2.7.9. Error Checking and Correction Controller
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. SPI Master Controllers 2.2.8.6. SPI Slave Controllers 2.2.8.7. 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. FPGA Slaves Address Space 2.4.1.4. LWFPGA Slaves Address Space 2.4.1.5. 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.2.2. Boot Clock
3.2.2. Boot Clock x
3.2.2.1. Updating PLL Settings without a System Reset 3.2.2.2. MPU Clock Scaling
3.3. Functional Description of the Clock Manager x
3.3.1. Clock Manager Building Blocks 3.3.2. PLL Integration 3.3.3. Hardware-Managed and Software-Managed Clocks 3.3.4. Hardware Sequenced Clock Groups 3.3.5. Software Sequenced Clocks 3.3.6. Resets 3.3.7. Security 3.3.8. Interrupts
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. Clock Gating
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. Reset Controller 4.1.2. Security Reset Functions 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. 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 Configuration 5.3.2. FPGA Status 5.3.3. Error Message Extraction 5.3.4. Data AES Decryption 5.3.5. Boot Handshake 5.3.6. General Purpose I/O 5.3.7. Clock 5.3.8. Reset
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. EMAC 6.3.2.4. USB 2.0 OTG Controller 6.3.2.5. SD/MMC Controller 6.3.2.6. Watchdog Timer
6.3.3. Boot ROM Code x
6.3.3.1. Controlling the Boot Memory Map Through the System Interconnect
9. HPS-FPGA Bridges x
9.1. Features of the HPS-FPGA Bridges 9.2. Arria 10 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 for Arria 10
9.3. Functional Description of the HPS-FPGA Bridges x
9.3.1. Functional Description of the FPGA-to-HPS Bridge 9.3.2. Functional Description of the HPS-to-FPGA Bridge 9.3.3. Functional Description of the Lightweight HPS-to-FPGA Bridge 9.3.4. Clocks and Resets 9.3.5. Data Width Sizing
9.3.1. Functional Description of the FPGA-to-HPS Bridge x
9.3.1.1. FPGA-to-HPS Access to ACP 9.3.1.2. FPGA-to-HPS Bridge Slave Signals
9.3.2. Functional Description of the HPS-to-FPGA Bridge x
9.3.2.1. HPS-to-FPGA Bridge Master Signals
9.3.3. Functional Description of the Lightweight HPS-to-FPGA Bridge x
9.3.3.1. Lightweight HPS-to-FPGA Bridge Master Signals
9.3.4. Clocks and Resets x
9.3.4.1. FPGA-to-HPS Bridge Clocks and Resets 9.3.4.2. HPS-to-FPGA Bridge Clocks and Resets 9.3.4.3. Lightweight HPS-to-FPGA Bridge Clocks and Resets 9.3.4.4. Taking HPS-FPGA Bridges Out of Reset
9.3.5. Data Width Sizing x
9.3.5.1. Ready Latency Support
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. L2 Cache 10.5. CPU Prefetch 10.6. TrustZone* 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 Arria 10 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. AxPROT Attributes 10.3.15.3. Cache Coherency for ACP Shared Requests 10.3.15.4. AXI Master Configuration for ACP Access 10.3.15.5. Burst Sizes and Byte Strobes 10.3.15.6. Exclusive and Locked Accesses 10.3.15.7. Avoiding ACP Dependency Lockup
10.3.15.4. AXI Master Configuration for ACP Access x
10.3.15.4.1. Configuring AxCACHE[3:0] Sideband Signals for Coherent Accesses 10.3.15.4.2. Configuring AxUSER[4:0] Sideband Signals 10.3.15.4.3. Configuring AxPROT[2:0] Sideband Signals for Coherent Accesses
10.3.15.5. Burst Sizes and Byte Strobes x
10.3.15.5.1. Recommended Burst Types
10.4. L2 Cache x
10.4.1. Functional Description
10.4.1. Functional Description x
10.4.1.1. Cache Controller Configuration 10.4.1.2. Single Event Upset Protection 10.4.1.3. L2 Cache Parity 10.4.1.4. L2 Cache Lockdown Capabilities 10.4.1.5. L2 Cache Event Monitoring 10.4.1.6. L2 Cache Address Filtering 10.4.1.7. Cache Latency
10.4.1.1. Cache Controller Configuration x
10.4.1.1.1. Implementation Details
10.4.1.1.1. Implementation Details x
10.4.1.1.1.1. L2 Cache Event Monitoring
10.6. TrustZone* x
10.6.1. Secure Partitioning 10.6.2. Virtual Processor Operation 10.6.3. Secure Debug
10.6.1. Secure Partitioning x
10.6.1.1. Secure Bus Accesses 10.6.1.2. Secure Cache Accesses
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 for Arria 10 10.9.2. L2 Cache Controller Address Map for Arria 10
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.1. Debug Access Port x
11.4.1.1. JTAG Connection
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. CTI-NoC 11.4.10.5. 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. CTI 11.5.3.2. FPGA-CTI 11.5.3.3. L3-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
11.6. CoreSight Debug and Trace Address Map and Register Definitions x
11.6.1. stm Address Map 11.6.2. dap Address Map
12. Error Checking and Correction Controller x
12.1. ECC Controller Features 12.2. ECC Supported Memories 12.3. ECC Controller Block Diagram and System Integration 12.4. ECC Controller Functional Description 12.5. ECC Controller Address Map and Register Descriptions
12.4. ECC Controller Functional Description x
12.4.1. Overview 12.4.2. ECC Structure 12.4.3. Memory Data Initialization 12.4.4. Indirect Memory Access 12.4.5. Error Logging 12.4.6. ECC Controller Interrupts 12.4.7. ECC Controller Initialization and Configuration 12.4.8. ECC Controller Clocks 12.4.9. ECC Controller Reset
12.4.2. ECC Structure x
12.4.2.1. RAM and ECC Memory Organization Example
12.4.4. Indirect Memory Access x
12.4.4.1. Watchdog Timer 12.4.4.2. Data Correction 12.4.4.3. Error Injection 12.4.4.4. Memory Testing 12.4.4.5. Error Checking and Correction Algorithm
12.4.4.4. Memory Testing x
12.4.4.4.1. Peripheral Slave Interface Tests 12.4.4.4.2. Register Interface Tests
12.4.5. Error Logging x
12.4.5.1. Recent Error Address Registers 12.4.5.2. Single-Bit Error Occurrence 12.4.5.3. Single-Bit Error Look-Up Table
12.4.6. ECC Controller Interrupts x
12.4.6.1. Single-Bit Error Interrupts 12.4.6.2. Double-Bit Error Interrupt 12.4.6.3. Interrupt Testing
12.4.6.1. Single-Bit Error Interrupts x
12.4.6.1.1. All Single-Bit Error Interrupt 12.4.6.1.2. LUT Overflow Interrupt 12.4.6.1.3. Counter Match Interrupt
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.1.3.4. On-Chip RAM Firewall 13.1.3.5. ECC Protection
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. Quad SPI Flash Controller Signal Description 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.12. Clocks x
16.4.12.1. Clock Gating
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. DMA Controller 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.4.3. System Manager Configuration 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.3. Clocks x
19.4.3.1. Clock Gating
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
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. Clock Gating 20.4.9.2. 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. I 2 C 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. Abort Transfer 21.5.5. 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.1.5. Slave Programming Model
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.2.4. Master Programming Model
21.5.5. DMA Controller Operation x
21.5.5.1. Transmit FIFO Underflow 21.5.5.2. Transmit Watermark Level 21.5.5.3. Transmit FIFO Overflow 21.5.5.4. Receive FIFO Overflow 21.5.5.5. Receive Watermark Level 21.5.5.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. RTC Flow Control Trigger 22.4.3.2. Automatic RTS mode 22.4.3.3. 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
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.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.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. Hard Processor System I/O Pin Multiplexing x
26.1. Features of the HPS I/O Block 26.2. HPS I/O Block Diagram and System Integration 26.3. Functional Description of the HPS I/O 26.4. Test Considerations 26.5. I/O Pin MUX Address Map and Register Definitions for Arria 10
26.3. Functional Description of the HPS I/O x
26.3.1. Dedicated I/O Pins 26.3.2. Shared I/O Pins 26.3.3. FPGA Access 26.3.4. Control Registers 26.3.5. Configuring HPS I/O Multiplexing
26.3.1. Dedicated I/O Pins x
26.3.1.1. Warm Reset Pin 26.3.1.2. Boot Pins
26.3.4. Control Registers x
26.3.4.1. Dedicated Pin MUX Registers 26.3.4.2. Dedicated Configuration Registers 26.3.4.3. Shared Pin MUX Registers 26.3.4.4. FPGA Access MUX Registers
26.3.5. Configuring HPS I/O Multiplexing x
26.3.5.1. Configuring Multiplexing at System Generation 26.3.5.2. Configuring Multiplexing at Boot Time
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
27.5. Memory Controllers x
27.5.1. HPS SDRAM Controller
27.5.1. HPS SDRAM Controller x
27.5.1.1. HMC and HPS Connectivity 27.5.1.2. Clocks 27.5.1.3. Resets
28. Instantiating the HPS Component x
28.1. Using the HPS Parameter Editor 28.2. FPGA Interfaces 28.3. Configuring HPS Clocks and Resets 28.4. Configuring Peripheral Pin Multiplexing 28.5. Configuring the External Memory Interface 28.6. Using the Address Span Extender Component 28.7. Generating and Compiling the HPS Component
28.2. FPGA Interfaces x
28.2.1. General Interfaces 28.2.2. FPGA-to-HPS SDRAM Interface 28.2.3. DMA Peripheral Request 28.2.4. Security Manager 28.2.5. Interrupts 28.2.6. AXI Bridges
28.3. Configuring HPS Clocks and Resets x
28.3.1. Alternate Clock Source from FPGA 28.3.2. User Clocks 28.3.3. Reset Interfaces 28.3.4. Peripheral FPGA Clocks
28.3.2. User Clocks x
28.3.2.1. User Clock Parameters 28.3.2.2. Clock Frequency Usage
28.4. Configuring Peripheral Pin Multiplexing x
28.4.1. Configuring Peripherals 28.4.2. Connecting Unassigned Pins to GPIO 28.4.3. Peripheral Signals Routed to FPGA
28.4.1. Configuring Peripherals x
28.4.1.1. Boot Source
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.4. EMIF Conduit
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. FPGA System Trace Macrocell Events Interface 29.4.2. FPGA Cross Trigger Interface 29.4.3. Debug APB* Interface
29.5. Peripheral Signal Interfaces x
29.5.1. Platform Designer (Standard) Peripheral Port Interface Mapping 29.5.2. DMA Controller Interface
29.5.1. Platform Designer (Standard) Peripheral Port Interface Mapping x
29.5.1.1. NAND Flash Controller Interface 29.5.1.2. SD/MMC Controller Interface 29.5.1.3. Quad SPI Flash Controller Interface 29.5.1.4. Ethernet Media Access Controller Interface 29.5.1.5. USB 2.0 OTG Controller Interface 29.5.1.6. SPI Controller Interface 29.5.1.7. I2C Controller Interface 29.5.1.8. UART 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. Security Manager
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. HPS-to-FPGA MPU Event Interface 30.7. Interrupts Interface 30.8. HPS-to-FPGA Debug APB* Interface 30.9. FPGA-to-HPS System Trace Macrocell Hardware Event Interface 30.10. HPS-to-FPGA Cross-Trigger Interface 30.11. FPGA-to-HPS DMA Handshake Interface 30.12. Boot from FPGA Interface 30.13. Security Manager Anti-Tamper Signals Interface 30.14. EMIF Conduit 30.15. Pin MUX and Peripherals
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.15. Pin MUX and Peripherals x
30.15.1. HPS Conduit Interfaces Connecting to the HPS I/O 30.15.2. HPS Conduit Interfaces Connecting to the FPGA
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. Second-Stage Boot Flow A.7. FPGA Configuration A.8. FPGA Reconfiguration
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. Second-Stage Boot Loader A.4.9. Secure Boot
A.4.3. Boot Select x
A.4.3.1. Boot Source I/O Pins A.4.3.2. Boot Fuses
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.4.6. I/O Configuration x
A.4.6.1. I/O State
A.6. Second-Stage Boot Flow x
A.6.1. Typical Boot Flow (Non-Secure) A.6.2. Secure Boot Flow A.6.3. HPS State on Entry to the Second-Stage Boot Loader A.6.4. Loading the Second-Stage Boot Loader Image
A.7. FPGA Configuration x
A.7.1. Full FPGA Configuration Flow Through HPS A.7.2. Early I/O Release FPGA Configuration Flow Through HPS A.7.3. Arria 10 SoC FPGA Configuration Sequence Through FPGA Manager
A.7.2. Early I/O Release FPGA Configuration Flow Through HPS x
A.7.2.1. Handling an FPGA Configuration Failure after Early I/O Release
A.8. FPGA Reconfiguration x
A.8.1. Full FPGA Reconfiguration A.8.2. Arria 10 SoC FPGA Partial Reconfiguration Sequence Through FPGA Manager
1. Intel® Arria® 10 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. SoC Security
8. System Interconnect
9. HPS-FPGA Bridges
10. Cortex*-A9 Microprocessor Unit Subsystem
11. CoreSight* Debug and Trace
12. Error Checking and Correction Controller
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. Hard Processor System I/O Pin Multiplexing
27. Introduction to the HPS Component
28. Instantiating the HPS Component
29. HPS Component Interfaces
30. Simulating the HPS Component
A. Booting and Configuration

7. SoC Security

Note: For a complete NDA version of the entire Security SoC chapter, address map and register definitions, contact your local field sales office.

The Intel® Arria® 10 SoC provides the framework for implementing secure systems by offering a layered hardware and software solution. A dedicated Security Manager module in the Hard Processor System (HPS) supervises secure initialization of the SoC and manages system response during tamper events. User fuses offer secure boot options and registers within the Security Manager provide further enhancement of secure states. Using Elliptical Curve Digital Signal Algorithm (ECDSA256) with Secure Hash Algorithm (SHA256) and Advanced Encryption Standard (AES) algorithms in the FPGA's Configuration Subsystem (CSS), boot images can be authenticated and decrypted. The integration of the Arm* TrustZone* technology and security firewalls within the Intel® Arria® 10 system interconnect provides defined partitioning in the device for secure and non-secure accesses. Protection mechanisms are integrated into debug components of the SoC to allow varying levels of visibility for debug.

Figure 16.  Intel® Arria® 10 Layered Security Solution
Related Information

Security Manager

The Security Manager module is integrated in the Hard Processor System (HPS) and provides the overall management of security within the SoC, including:

  • Recognition of secure fuse configuration
  • Secure state control and status check of security features
  • Secure boot options
  • Varying levels of debug visibility
  • Anti-Tamper support

Security Manager Block Diagram

Figure 17. Security Manager Block Diagram

Functional Overview

The Security Manager integrates several functions that support the TrustZone* technology, manage security states in the device, and hold secure fuse information.

The main components of the Security Manager architecture include:

  • Fuse Control (TEST):

    When the HPS is powered, the Security Manager ensures reliable and verified receipt of the fuse information from the Configuration Subsystem (CSS) in the FPGA, stores it in fuse shadow registers and can request further fuse information.

  • Security State and Status Check:

    This sub-module holds the security state of the system, which is controlled by the fuse bits, hardware and software programming. This sub-module also has the ability to check and raise the level of security.

  • Encryption Data Port:

    This interface receives authenticated and decrypted boot images from the CSS.

    • Support for ECDSA256 (SHA256) authenticated boot.
    • Support for AES-based encrypted boot.
  • Registers:
    • Control Registers configure security state and debug options for the device.
    • Status and Error Registers flag transmission errors and interrupts.
    • Fuse Shadow Registers hold a copy of the user fuse information.
  • Anti-Tamper Control:

    On a tamper event, this module sends a signal to the Reset Manager to initiate the scrambling and clearing of all memories, including on-chip RAM, peripheral memories, L1 cache and L2 cache. Upon completion, the Security Manager sends a signal to the FPGA to indicate that the anti-tamper event has been handled.

Functional Description

Secure Initialization Overview

Secure initialization allows the device to boot and configure in a secured state.

Secure initialization begins with the CSS module. On FPGA power-up, the Configuration Subsystem (CSS) powers, initializes and loads the fuse bits. The CSS sends the FPGA its fuse configuration information. If the HPS is powered, the CSS sends the HPS fuse information to the Security Manager. This information is held in the HPS_fusesec shadow register in the Security Manager.

When the Security Manager is released from reset, it requests configuration information from the CSS and performs security checks. At this point, the rest of the HPS is still in reset. The security checks validate whether the state of each security option is valid. The Security Manager decodes the fuse bits and brings the rest of the HPS out of reset.

If there are errors in the initial transmission of the secure fuse information, the HPS stays in reset and no automatic retry occurs. Only an FPGA re-configuration causes a retry.

When the HPS is released from reset, the Security Manager sends signals to initialize the system blocks, such as the Clock Manager, FPGA Manager, System Manager. The clock control fuse information is automatically sent to the Clock Manager, the memory control fuse information is automatically sent to the Reset Manager and all other fuse functions (authentication, encryption, and public key source and length) are stored in a memory-mapped location for the boot ROM code to read. After these tasks are successfully completed, CPU0 comes out of reset in a secure state.

After CPU0 is released from reset, the boot ROM begins executing. At this time, the HPS is in a trusted state and the boot ROM code is guaranteed to execute as expected. For both secure and non-secure boot, all slave peripherals are brought out of reset in a secure state.

After initial security controls have been set, the boot ROM determines the second-stage boot loader source from the bootinfo register in the System Manager. The boot source can be from external memory through the HPS or through the FPGA. If the second-stage boot loader code comes from HPS external memory, then the boot ROM configures the clock and the interface to external memory.

When the boot ROM attempts to read from the flash, it looks for one of four images in external memory. Initially, it looks for image 0. If it is found, the image is authenticated, decrypted, or both depending on the requirements of the current security state. If these steps are successful, then the image is executed. However, if any of these steps fail, then the boot ROM moves onto the next image until it runs out of images.

For example, during a secure boot, the second-stage boot loader header includes an authentication key and the incoming image is authenticated. If indicated from the current security state, the image may be decrypted as well. The boot ROM contains functions to establish transitive trust to the second-stage boot code loaded from external flash or from the FPGA into on-chip RAM. If trust cannot be established in a secure boot, the HPS does not come out of reset and can attempt to load a different second-stage boot image.

For comprehensive information on the booting and boot image partitioning refer to the Booting and Configuration appendix of the Arria 10 Hard Processor Technical Reference Manual.

If all the images fail, it attempts to locate an image from the FPGA fabric and boot from there. If the FPGA boot fails, then it halts.

If the HPS receives its second-stage boot loader code from the FPGA, it waits for the FPGA to finish configuration before it obtains the image from FPGA RAM.

If required, a portion of the second-stage boot loader header can be used to raise security states of security features in the device that are currently in non-secure mode.

Secure Fuses
During initialization of the device, the Configuration Subsystem (CSS) sends the value of the HPS secure fuses to the HPS and holds a copy of the FPGA secure fuses. The HPS and FPGA each hold their own fuse values. However, a copy of these fuse values is held in the HPS_fusesec and fpga_fusesec registers within the Security Manager.

The following table details the HPS security fuse bits sent by the CSS to the Security Manager and contained within the HPS_fusesec register. A "blown" fuse state is represented by a 1 in the HPS_fusesec register and a "not blown" fuse state is represented by a 0.

Table 31.   HPS_fusesec Register Description

Bits

 Name

Description
31:27 Reserved

Bit values in this field are undefined.

26:23 csel_f

This field indicates the value of the clock select fuses that are available for configuring the clock for the boot interface and for the PLLs. Refer to the Clock Configuration section for more information on CSEL encodings.

22 dbg_access_f This fuse determines the initial state of the debug access domains.
21 dbg_lock_JTAG This field indicates if the HPS JTAG access level can be changed through software when the HPS is released from reset.
  • 0x0= HPS JTAG access level can be changed through the sec_jtagdbg register.
  • 0x1= HPS JTAG access level cannot be changed (locked).
20 dbg_lock_DAP This field indicates if the DAP access level can be changed through software when the HPS is released from reset.
  • 0x0= The DAP access level can be changed through the sec_dapdbg register.
  • 0x1= The DAP access level cannot be changed (locked).
19 dbg_lock_CPU0 This field indicates if the CPU0 debug access level can be changed through software when the HPS is released from reset.
  • 0x0= CPU0 debug access level can be changed through the sec_cpu0dbg register.
  • 0x1= CPU0 debug access level cannot be changed (locked).
18 dbg_lock_CPU1 This field indicates if the CPU1 debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The CPU1 debug access level can be changed through the sec_cpu1dbg register.
  • 0x1= The CPU1 debug access level cannot be changed (locked).
17 dbg_lock_CS This field indicates if the CoreSight debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The CoreSight debug access level can be changed through the sec_csdbg register.
  • 0x1= The CoreSight debug access level cannot be changed (locked).
16 dbg_lock_FPGA This field indicates if the FPGA debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The FPGA debug access level can be changed through the sec_fpgadbg register.
  • 0x1= The FPGA debug access level cannot be changed (locked).
15:12 Reserved

Bit values in this field are undefined.

11 clr_ram_order_f

This fuse value determines how RAMs are cleared during a tamper event.

  • 0x0= All RAMs are cleared in parallel.
  • 0x1= All RAMs are cleared in series.
10 clr_ram_cold_f

This fuse value indicates what happens to the RAM on a cold reset.

  • 0x0= All RAMs are not cleared on a cold reset.
  • 0x1= All RAMs are cleared on a cold reset.
9 clr_ram_warm_f

This fuse value indicates what happens to the RAMs on a warm reset.

  • 0x0= All RAMs are not cleared on a warm reset.
  • 0x1= All RAMs are cleared on a warm reset.
8 oc_boot_f

This fuse value determines if the second-stage boot code is allowed to boot from on-chip RAM.

  • 0x0= Second-stage boot can be from on-chip RAM if enabled by the System Manager.
  • 0x1= Second-stage boot is not from on-chip RAM.
7 hps_clk_f

This fuse value selects the clock used for the boot process and in the case of a tamper event, memory scrambling.

  • 0x0= The external oscillator, HPS_CLK1, is used for boot.
  • 0x1= The internal oscillator, cb_intosc_ls_clk, is used for boot.
6 fpga_boot_f

If blown, this fuse value allows the FPGA to configure independently and allows the HPS to boot from an encrypted next-stage boot source that was decrypted into the FPGA.

  • 0x0= Booting is dependent on the BSEL pins.
  • 0x1= HPS only boots from the FPGA; BSEL options are ignored and CSEL fuse options are ignored.
5 aes_en_f

This fuse value indicates if a decryption of the flash image is always performed.

  • 0x0= An AES decryption of the flash image is determined from the second stage boot loader header.
  • 0x1= An AES decryption of the flash image is always performed.
4:2 kak_src_f

This bit field indicates the source of the Key Authorization Key (KAK) which can be in:

  • Proprietary ROM
  • FPGA logic elements
  • User fuses
1 kak_len_f

This fuse value indicates the Key Authorization Key (KAK) length:

  • 0x0= 256 bits
  • 0x1= 384 bits
0 authen_en_f

This fuse value determines whether authentication of flash images is required prior to execution.

  • 0x0= No authentication of the flash image is required prior to execution.
  • 0x1= HPS authentication of all flash images is required prior to execution.

At initialization, the FPGA also receives fuse information that is pertinent to its configuration. The HPS can read this information through a secure serial interface, which shifts the FPGA fuse values into the fpga_fusesec register in the Security Manager. The CSS shifts in a 32-bit value although some of the bits are considered reserved.

Security State

The security state of the entire device is defined by the combination of the security state of the HPS and the FPGA. The initial security state of the device is determined by the fuse settings in the SoC. The values of these fuses are written to two shadow registers within the Security Manager: the hps_fusesec and the fpga_fusesec registers.

Each feature's security level can be increased from its initial fuse level through software, and for debug, through hardware as well. Changes to security level can only increase security and can never lower security. Both the HPS and FPGA have a mechanism to load security option bits as part of the second-stage boot loader and POF file, respectively, which can perform a check of the current security state and raise the security level.

Security Check

The Security Manager has the capability to perform security checks to identify discrepancies between the actual and expected security level so that measured actions can be taken through software and hardware if required.

There are three types of security checks that can be performed by the Security Manager:
  • A fuse security level check
  • A hardware access security level check
  • A software access security level check
Secure Serial Interface

The HPS and FPGA communicate through a secure serial interface. The interface allows security of the HPS to be separate from the security of the FPGA. Software can initiate a request of the serial fuse interface via the Security Manager register.

Secure Debug

Debug logic in the Security Manager controls whether to enable or disable the JTAG, CPUs, Debug Access Port (DAP) and CoreSight* domains. Debug access is determined by a combination of debug fuses, option bits, and registers that change the default state and set the functional state of debug peripherals.

During a power-on reset, access to all debug domains are prevented. During a warm reset, access to all debug domains except JTAG are prevented. Once a cold or warm reset is exited, the default debug access is defined by the value of the dbg_disable_access fuse and the dbg_lock* fuses. When the dbg_disable_access fuse is blown, HPS debug accesses to all domains are disabled by default out of reset. If the fuse is not blown, then the initial HPS debug state out of reset is enabled. To ensure that the device is brought up in a secure state, the dbg_disable_access fuse must be blown.

MPU

The MPU supports invasive and non-invasive debug. Invasive debug allows the user to control and observe the processor. Non-invasive debug allows you to observe the processor but not control it and is always available as part of invasive debug. The NIDEN and SPNIDEN signals are used for non-invasive debug in the MPU.

JTAG

The HPS and FPGA share a common set of JTAG pins and each have their own TAP controller which are chained together inside the device.

In the default JTAG configuration, the FPGA and HPS JTAG controllers are daisy-chained and controlled by an external JTAG port. The HPS JTAG controller is also referred to as the Debug Access Port.

Figure 18. JTAG Chaining
During power-on-reset, the JTAG and all debug domains are disabled. After the device is released from reset, the debug fuses are read by the Configuration Subsystem to determine if the external JTAG port or the JTAG controller to the FPGA or HPS is bypassed. Bypass can additionally be enabled through option bits in the Security Option registers discussed in the Security State section.
Figure 19. HPS JTAG Bypass

Reset Manager

To avoid unsecure snooping of RAM contents, the Security Manager can send signals to the Reset Manager to clear all RAM on a cold or warm reset.

These signals are the result of fuse programming combined with the configuration bits found in the HPS_Swoptset and HPS_secopt1 register in the Security Manager.

In addition, the fuse information that determines whether the RAMs are cleared in series or parallel is also sent to the Reset Manager. Clearing the memory in series prevents a power spike that could occur with parallel clearing of RAM. The policies for how or when security states take affect can be programmed in the HPS_secopt1 register. Refer to the "Security State" section for more information.

The RAM instances that are cleared during a warm or cold reset are:

  • On-chip RAM
  • USB0
  • USB1
  • SD/MMC
  • EMAC0 RX and TX buffer
  • EMAC1 RX and TX buffer
  • EMAC2 RX and TX buffer
  • DMA
  • NAND read data, write data, and ECC RAMs
  • QSPI
  • MPU RAM

If a tamper event occurs, the Security Manager notifies the Reset Manager and the following sequence occurs:

  1. All domain resets are asserted.
  2. All RAMs are cleared.
  3. The Reset Manager enters a dead state waiting for a POR release from Security Manager. All cold reset sources except Security Manager are ignored.

When FPGA POR and HPS POR are asserted, the Security Manager goes into reset.

Clock Configuration

Security Manager is driven by an internal oscillator, cb_intosc_hs_clk, in the Configuration Subsystem. This clock has wide variation across process and temperature. Once the Security Manager reads the fuse information, it drives the boot clock configuration to the Clock Manager. The Clock Manager samples the clock configuration on a cold and warm reset. If the hps_clk_f fuse is blown, the internal oscillator divided by 2, cb_intosc_hs_div2_clk, is used as the boot clock. If the fuse is not blown, an external oscillator is used. During boot ROM execution, the boot code configures the device clock based on the CSEL fuse settings or software code. The cb_intosc_hs_div2_clk can be considered the secure reference clock option.

The CSEL fuse settings have different meanings depending on how the hps_clk_f fuse is configured. When the hps_clk_f fuse is not blown, the external oscillator is the boot clock input.

Table 32.  CSEL Encodings for hps_clk_f = 0

CSEL[3:0] Fuse Value

Description

 MPU Clock Value
0x0 When no fuses are blown, the boot ROM returns clocks back to their default (bypass) boot mode and the CPU is driven by the external oscillator (HPS_CLK1), which must be in the range of 10 to 50 MHz. No PLL is enabled. External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x1

This encoding is typically used during a warm reset if you have already configured your clocks or PLL in the clock manager and would like to continue to use this configuration. If this is encoding is selected, no changes are made to these settings and the clock configuration is essentially user selected.

If this is encoding is used during a power-on reset, then whatever the default reset values of the clocks are used.

User-selected clock source. Refer to the Clock Manager chapter for clock register settings.
0x2 Reserved External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x3 Reserved External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x4 Reserved External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x5 Reserved External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x6 Reserved External Oscillator, HPS_CLK1 (10 to 50 MHz)
0x7 External oscillator input clock, HPS_CLK1, is in the range of 10 to 15 MHz 533 to 800Mhz
0x8 External oscillator input clock, HPS_CLK1, is in the range 15 to 20 MHz. 600 to 800Mhz
0x9 External oscillator input clock, HPS_CLK1, is in the range 20 to 25 MHz. 640 to 800Mhz
0xA External oscillator input clock, HPS_CLK1, is in the range 25 to 30 MHz. 666 to 800Mhz
0xB External oscillator input clock, HPS_CLK1, is in the range 30 to 35 MHz. 685 to 800Mhz
0xC External oscillator input clock, HPS_CLK1, is in the range 35 to 40 MHz. 700 to 800Mhz
0xD External oscillator input clock, HPS_CLK1, is in the range 40 to 45 MHz. 711 to 800Mhz
0xE External oscillator input clock, HPS_CLK1, is in the range 45 to 50 MHz. 720 to 800Mhz
0xF The boot ROM returns clocks back to their default (bypass) boot mode and the CPU is driven by the external oscillator (HPS_CLK1). No PLL is enabled. External Oscillator, HPS_CLK1 (10 to 50 MHz)
Table 33.  CSEL Encodings for hps_clk_f = 1

CSEL[3:0] Fuse Value

Description

 MPU Clock Value
0x0 Bypass mode; in this mode all clocks are reset and boot mode is ensured active; cb_intosc_hs_div2_clk (cb_intosc_hs clock divided by 2) is used. cb_intosc_hs_div2_clk (60 to 200 MHz)
0x1

This encoding is typically used during a warm reset if you have already configured your clocks or PLL in the Clock Manager and would like to continue to use this configuration. If this is encoding is selected, no changes are made to these settings and the clock configuration is essentially user selected.

If this is encoding is used during a power-on reset, then whatever the default reset values of the clocks are used.

User-selected clock source. Refer to the Clock Manager chapter for clock register settings.
0x2 PLL is used with the internal oscillator (30 to 100 MHz) 120 to 800 MHz
0x3 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x4 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x5 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x6 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x7 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x8 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0x9 Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xA Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xB Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xC Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xD Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xE Reserved cb_intosc_hs_div2_clk (60 to 200 MHz)
0xF Bypass mode; reset all clocks and ensure boot mode is active; cb_intosc_hs_div2_clk is used. cb_intosc_hs_div2_clk (60 to 200 MHz)

For more information regarding the CSEL encodings and descriptions, please refer to the Booting and Configuration Appendix.

FPGA Security Features

The FPGA has several security fuses which can control the following functions:

  • Limiting acceptance of only encrypted and authenticated POFs
  • Disabling partial reconfiguration and scrubbing
  • Disabling test access
  • Disabling external configuration
  • Limiting JTAG access
  • Bypassing HPS or FPGA JTAG
  • Locking or disabling the battery-backed volatile key
  • Disabling the OTP key

Note that there is a fuse sent to the FPGA CSS, called hps_jtag_bypass, which performs the same function of removing the HPS from the JTAG chain. However, this fuse is a permanent disable, whereas using software to program the sec_jtagdbg register has the same affect, but may be changed later by software.

Secure Boot

No ordering of boot or FPGA configuration is required because the FPGA and HPS may be brought up in any order, and they can both raise the security level of the entire device at any time before user code is loaded to execute.

The SoC may securely boot in one of three ways:

  1. The HPS boot and FPGA configuration occur separately.
  2. The HPS boots from the FPGA after the FPGA is configured
  3. The HPS boots first and configures the FPGA.
Note: The device has the capability to execute standard non-secure boot in any of these three ways, as well. In this section, only secure booting mechanisms are reviewed.
Note: The FPGA must be powered on for the HPS to come out of reset properly.
Boot Configuration

Booting configuration is provided from a combination of the BSEL pins and the boot mode fuses. The BSEL pins indicate if the boot source is the FPGA or one of the HPS flash interfaces. If the fpga_boot_f fuse is blown, it overrides these pin values. The fpga_boot_f fuse value can be read from the hps_fusesec register.

Table 34.  BOOTSEL Field Values and Flash Device Selection

BOOTSEL Field Value

Flash Device

0x0

Reserved

0x1

FPGA (HPS-to-FPGA bridge)

0x2

1.8 V NAND flash memory

0x3

3.0 V NAND flash memory

0x4

1.8 V SD/MMC flash memory with external transceiver

0x5

3.0 V SD/MMC flash memory with internal transceiver

0x6

1.8 V quad SPI flash memory

0x7

3.0 V quad SPI flash memory

Within the device, there are fuses that provide some of the boot mode configuration information. The fuse values can be read through the HPS_fusesec register:

Table 35.   HPS_fusesec Register Description

Bits

 Name

Description
31:27 Reserved

Bit values in this field are undefined.

26:23 csel_f

This field indicates the value of the clock select fuses that are available for configuring the clock for the boot interface and for the PLLs. Refer to the Clock Configuration section for more information on CSEL encodings.

22 dbg_access_f This fuse determines the initial state of the debug access domains.
21 dbg_lock_JTAG This field indicates if the HPS JTAG access level can be changed through software when the HPS is released from reset.
  • 0x0= HPS JTAG access level can be changed through the sec_jtagdbg register.
  • 0x1= HPS JTAG access level cannot be changed (locked).
20 dbg_lock_DAP This field indicates if the DAP access level can be changed through software when the HPS is released from reset.
  • 0x0= The DAP access level can be changed through the sec_dapdbg register.
  • 0x1= The DAP access level cannot be changed (locked).
19 dbg_lock_CPU0 This field indicates if the CPU0 debug access level can be changed through software when the HPS is released from reset.
  • 0x0= CPU0 debug access level can be changed through the sec_cpu0dbg register.
  • 0x1= CPU0 debug access level cannot be changed (locked).
18 dbg_lock_CPU1 This field indicates if the CPU1 debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The CPU1 debug access level can be changed through the sec_cpu1dbg register.
  • 0x1= The CPU1 debug access level cannot be changed (locked).
17 dbg_lock_CS This field indicates if the CoreSight debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The CoreSight debug access level can be changed through the sec_csdbg register.
  • 0x1= The CoreSight debug access level cannot be changed (locked).
16 dbg_lock_FPGA This field indicates if the FPGA debug access level can be changed through software when the HPS is released from reset.
  • 0x0= The FPGA debug access level can be changed through the sec_fpgadbg register.
  • 0x1= The FPGA debug access level cannot be changed (locked).
15:12 Reserved

Bit values in this field are undefined.

11 clr_ram_order_f

This fuse value determines how RAMs are cleared during a tamper event.

  • 0x0= All RAMs are cleared in parallel.
  • 0x1= All RAMs are cleared in series.
10 clr_ram_cold_f

This fuse value indicates what happens to the RAM on a cold reset.

  • 0x0= All RAMs are not cleared on a cold reset.
  • 0x1= All RAMs are cleared on a cold reset.
9 clr_ram_warm_f

This fuse value indicates what happens to the RAMs on a warm reset.

  • 0x0= All RAMs are not cleared on a warm reset.
  • 0x1= All RAMs are cleared on a warm reset.
8 oc_boot_f

This fuse value determines if the second-stage boot code is allowed to boot from on-chip RAM.

  • 0x0= Second-stage boot can be from on-chip RAM if enabled by the System Manager.
  • 0x1= Second-stage boot is not from on-chip RAM.
7 hps_clk_f

This fuse value selects the clock used for the boot process and in the case of a tamper event, memory scrambling.

  • 0x0= The external oscillator, HPS_CLK1, is used for boot.
  • 0x1= The internal oscillator, cb_intosc_ls_clk, is used for boot.
6 fpga_boot_f

If blown, this fuse value allows the FPGA to configure independently and allows the HPS to boot from an encrypted next-stage boot source that was decrypted into the FPGA.

  • 0x0= Booting is dependent on the BSEL pins.
  • 0x1= HPS only boots from the FPGA; BSEL options are ignored and CSEL fuse options are ignored.
5 aes_en_f

This fuse value indicates if a decryption of the flash image is always performed.

  • 0x0= An AES decryption of the flash image is determined from the second stage boot loader header.
  • 0x1= An AES decryption of the flash image is always performed.
4:2 kak_src_f

This bit field indicates the source of the Key Authorization Key (KAK) which can be in:

  • Proprietary ROM
  • FPGA logic elements
  • User fuses
1 kak_len_f

This fuse value indicates the Key Authorization Key (KAK) length:

  • 0x0= 256 bits
  • 0x1= 384 bits
0 authen_en_f

This fuse value determines whether authentication of flash images is required prior to execution.

  • 0x0= No authentication of the flash image is required prior to execution.
  • 0x1= HPS authentication of all flash images is required prior to execution.
Secure Boot Process

Secure boot allows the HPS to release from reset into a known state and then validate the authenticity and integrity of the second-stage boot loader code prior to executing it. Secure boot ensures that only authorized code is executed on the system. In addition, the system has the option to configure the FPGA from the HPS, which provides a secure boot mechanism for the FPGA portion of the SoC. In this mode, the HPS boot code can authenticate the FPGA POF prior to loading it.

The HPS and FPGA can also be booted securely but independently, with the HPS executing authenticated and decrypted user code out of external RAM and the FPGA receiving an encrypted FOP configuration file by enabling an FPGA configuration source through the MSEL pins.

Boot ROM code runs on CPU0 and CPU1 is held in reset. Once control passes to the second-stage boot loader, CPU1 can be released from reset.

Authentication and Decryption

Authentication is provided for the second-stage boot loader code and both the HPS and FPGA can utilize the AES algorithms in the Configuration Subsystem (CSS) to decrypt boot images and POF files, respectively.

Three levels of boot are available to the device:

  • Authentication only: The second-stage boot loader code is not encrypted, but there are public key signatures attached to the image and the code only executes if all of the signatures pass. ECDSA256 (SHA 256) is used for authenticated boot.
  • Decryption only: The user boot code is encrypted and must be decrypted before execution. AES-based algorithms in the FPGA are used for decryption.
  • Authentication and Decryption: The user boot code is encrypted and signed.

If authentication and decryption are enabled, the data is first authenticated and then decrypted using the AES algorithms. Authentication is performed using the public key authorization key (KAK) held in the user fuses. The KAK can be 256 bits. The KAK public key authentication fuses are lockable by the user in groups of 64 bits or less.

The Security Manager's hps_fusesec register can be read to identify the source of the public (root) key used for authentication of the second-stage boot loader. The source of the public (root) key can be one of the following:

  • External software
  • ROM
  • FPGA logic elements
  • User Access Fuses (UAF)

AES decryption algorithms are available through the FPGA CSS and are enabled prior to decryption through a combination of user fuses and software programming. Elliptic curve cryptographic algorithms are used in an authenticated boot. Decrypted data is sent to the Security Manager to be read by the CPU or DMA.

The FPGA has higher priority in the CSS, and the FPGA AES algorithms abort decryption and authentication of data if the FPGA starts configuration or reconfiguration.

Anti-Tamper

The Security Manager receives a tamper detection signal when a tamper event is detected in the device.

Anti-tamper logic can be implemented in the FPGA soft logic to detect a tamper event. No tamper detection is available until the FPGA is configured. The user must define the anti-tamper design. Some examples of tamper detection that could be implemented are:

  • Using the FPGA voltage sensor to detect any IR drops across the device.
  • Using an A/D controller to detect temperature changes in the device due to tamper.
  • Assigning loaner I/O as dedicated tamper pins to detect package break-away.

The tamper detection signal sent to the Security Manager, anti_tamper_in, is an active low signal. When there is no tamper event, it is driven to 1. The Security Manager also provides a tamper acknowledge signal to the FPGA interface. The tamper event input to the HPS is gated with a signal indicating the completion of FPGA configuration. This prevents an inadvertent tamper event assertion or tamper response from the HPS to the rest of the system.

When the Security Manager receives a tamper detection assertion, it prepares the system to go into reset and notifies the Reset Manager of the event. When the Reset Manager receives the tamper event assertion from the Security Manager, it drives all the peripherals and MPU into reset. It asserts a request and enables all peripherals memories to initiate a memory scramble and a memory clear, either in series or parallel, depending on the information sent from the Security Manager. The memory clearing includes the on-chip RAM, L1 caches, and L2 cache and RAM for the peripherals listed below:
  • Ethernet MAC 0/1/2
  • USB OTG 0/1
  • QSPI flash controller
  • NAND flash controller
  • SD/MMC controller
  • DMA controller
Once the memory scramble and clear completes, each module sends an acknowledgment back to the Reset Manager.

Upon completion of memory scrambling of all IPs, the Security Manager sends a response to the FPGA indicating that a tamper event has been handled in the HPS. This response is followed by HPS entering into a cold reset without exiting until another power cycle occurs. Both Security Manager and Reset Manager enter reset. Other resets, such as warm reset or cold reset, do not affect the state of the Security Manager or the Reset Manager.

If the FPGA POR is de-asserted while the HPS is in a tamper event reset, then the Security Manager goes back to the reset state.

Security System Extensions

Beyond the Security Manager module, other secure features can be implemented at a system level within the SoC.

TrustZone

The Cortex*-A9 MPU subsystem has integrated TrustZone* technology, which provides a system solution to protect application platforms from malicious attack. The TrustZone* hardware and supporting software are designed to provide a strong security solution regardless of the operating environment. TrustZone* creates a separation between the secure and non-secure areas of the SoC and allows the designer to choose which assets in a design are designated as secure and non-secure.

TrustZone* security is implemented in the Cortex*-A9 MPU subsystem in three ways:

  • Hardware partitioning through the implementation of firewalls: Resources can be assigned and identified as secure or non-secure.
  • Virtual processor execution: Each core can context switch between secure and non-secure operation.
  • Secure debug control: Both secure and non-secure hardware debug exist and the type of debug allowed can be configured by the user.

Secure Partitioning

System interconnect and cache accesses as well as processor execution can be securely partitioned using the TrustZone* infrastructure.

Secure Bus Accesses

The Cortex* -A9 MPCore and other masters that utilize the system interconnect can be configured for secure or non-secure accesses.

Master accesses drive a protection signal, AxPROT[1], to communicate the security level of the attempted transaction. The Cortex* -A9 drives this signal low for secure accesses and high for non-secure accesses. The secure firewalls determine whether the access is allowed or not. A slave access type defaults to secure if no other configuration is programmed. Users can define whether a bus error is generated or if a bus failure occurs when a secure access is violated.

Note: Secure processor configuration is programmed through the CP15 register.
Secure Cache Accesses

Secure and non-secure partitioning also extends to the L1 and L2 caches.

There is a 32-bit physical address space for secure and non-secure transactions and a 33rd bit is provided to indicate security. The cache is able to store both secure and non-secure lines.

The Accelerator Coherency Port (ACP) in the Arm* Cortex* -A9 MPCore can be used with TrustZone* technology. The security state of the masters using the ACP must be the same as the Cortex-A9 processor.

Virtual Processor Operation

Two virtual processors (secure and non-secure) with context switch capability (monitor mode) exist for each Cortex*-A9 processor core. The secure virtual processor only accesses secure resources and the non-secure virtual processor only accesses non-secure resources.

Figure 20. Virtual Processor Environment with Monitor Mode

Exception Vector Tables

A context switch to secure operation is achieved through a secure monitor call (SMC) instruction or the following hardware exceptions (if configured to do so):

  • IRQ interrupt
  • Faster Interrupt Request (FIQ) interrupt
  • External data abort
  • External prefetch abort

When a context switch occurs, the state of the current mode is saved and restored on the next context switch or on a return from exception.

Three exception vector tables are provided for the MPU with TrustZone* :

  1. Non-secure
  2. Secure
  3. Monitor mode

Typically IRQs are used for non-secure interrupts and FIQs are used for secure interrupts. The location of each of the three vector tables can be moved at runtime.

The Generic Interrupt Controller (GIC) can handle secure and non-secure interrupts and prevent non-secure accesses from reading or modifying the configuration of a secure interrupt. An interrupt can be made secure by programming the appropriate bits in the Interrupt Security Register. Secure interrupts are always given a higher priority than non-secure interrupts.

Arria 10 HPS Secure Firewalls

You can use the system interconnect firewalls to enforce security policies for slave and memory regions in the system interconnect.

The firewalls support the following features:

  • Secure or non-secure access configurable per peripheral
  • Privileged or user access configurable for some peripherals
  • Per-transaction security
Each firewall contains the security configuration registers (SCRs) that set security policies and define which transactions are allowed to go through the firewall. If you want to generate an error any time a transaction is blocked in the firewall, then you must set the error_response bit in the global register of the noc_fw_ddr_l3_ddr_scr module at base address 0xFFD13400. If this bit is clear, transactions blocked by the firewall return random data.
Note: Future devices may not support the return of random data and may only support an error response for blocked firewall transactions. For designs that may be ported to future devices, Intel recommends you to set the error_response bit in the global register.

There are five main firewalls in the HPS:

  • Peripheral
  • System
  • HPS-to-FPGA
  • On-Chip RAM
  • SDRAM (which includes DDR and DDR L3 firewalls)

Firewall Diagrams

The system interconnect firewalls filter access to components on various buses.

Table 36.  System Interconnect Firewalls

Name

Function

Peripherals

The peripherals firewall filters access to slave peripherals in the following buses:

  • L4 main bus
  • L4 master peripheral bus
  • L4 AHB* bus
  • L4 slave peripherals bus
System

The system firewall filters access to system peripherals in the following components:

  • L4 system bus
  • L4 ECC bus
  • DAP
HPS-to-FPGA

The HPS-to-FPGA firewall filters access to FPGA through the following bridges:

  • HPS-to-FPGA bridge
  • Lightweight HPS-to-FPGA bridge
On-Chip RAM

The on-chip RAM firewall filters secure access to on-chip RAM
SDRAM

The SDRAM firewall filters access to DDR SDRAM
Figure 21. Peripheral FirewallSecurity Configuration Registers (SCRs) within the noc_fw_l4_per register group can be programmed to mark the security status of all available masters.
Table 37.  Peripheral Firewall

Bus Behind Firewall

 Bus Slaves Behind Firewall Masters That Can Access Bus

L4 Main

DMA (secure/non-secure registers)

SPI 0/1/2/3

MPU

DAP

DMA

FPGA-to-HPS

L4 Master Peripheral Bus

EMAC 0/1/2

SD/MMC

QSPI

MPU

DAP

DMA

FPGA-to-HPS

L4 AHB* Bus

QSPI Data

NAND Data

USB OTG 0/1

MPU

DAP

DMA

FPGA-to-HPS

L4 Slave Peripheral Bus

UART 0/1

I2C 0/1/2/3/4

SP Timer 0/1

GPIO 0/1/2

MPU

DAP

DMA

FPGA-to-HPS
Figure 22. System FirewallThe system firewall filters accesses to all system peripherals. The system firewall policies can be programmed through the SCRs of the noc_fw_soc2fpga register group.
Table 38.  System Firewall

Bus Behind Firewall

 Bus Slaves Behind Firewall Masters That Can Access Bus

L4 ECC

SD/MMC ECC

DMA ECC

QSPI ECC

NAND ECC

USB 0/1 ECC

On-Chip RAM ECC

EMAC 0/1/2 Rx ECC

EMAC 0/1/2 Tx ECC

NAND Read/Write ECC

MPU

FPGA-to-HPS

DAP

L4 System

FPGA Manager Data and Registers

OSC Timer 0/1

Watchdog 0/1

System Manager

L3 Interconnect Control and Status Registers (CSR)

L4 Interconnect firewall Security Control Registers (SCR)

MPU

FPGA-to-HPS

DAP

DMA

L4 DAP Bus

STM

DAP

MPU

FPGA-to-HPS

DAP
Figure 23. HPS-to-FPGA FirewallSCRs within the noc_fw_soc2fpga register group can be programmed to configure the security policy for the master-to-bridge pairs.
Table 39.  System Firewall

Bus Behind Firewall

 Bus Slaves Masters that can Access Bus

L3

SD/MMC ECC

DMA ECC

QSPI ECC

NAND ECC

USB 0/1 ECC

On-Chip RAM ECC

EMAC 0/1/2 Rx ECC

EMAC 0/1/2 Tx ECC

NAND Read/Write ECC

MPU

FPGA-to-HPS

DAP

L4 System

FPGA Manager Data and Registers

OSC Timer 0/1

Watchdog 0/1

System Manager

L3 Interconnect CSR

L4 Interconnect firewall SCR

MPU

FPGA-to-HPS

DAP

DMA

L4 DAP Bus

STM

DAP

MPU

FPGA-to-HPS

DAP
Figure 24. On-Chip RAM FirewallUp to six regions of the on-chip RAM can be partitioned for non-secure accesses.
Figure 25. SDRAM firewallTransactions from the DMA, ETR, DAP, FPGA-to-HPS masters or HPS masters (USB, SD/MMC, EMAC, NAND) are routed to either the ACP or the SDRAM scheduler depending on the cacheable bit. Only cacheable transactions are routed to the ACP, with non-cacheable transactions being routed directly to the SDRAM scheduler. If an access to the ACP results in a cache miss in the L1 and L2 cache systems, then the MPU master M1 issues a transaction to the SDRAM scheduler. Only cacheable transactions go through to the ACP. If a cache miss occurs on the ACP cycle, then the MPU masters a new transaction to the SDRAM scheduler. Accesses from the MPU or FPGA-to-SOC masters that are tightly coupled to the MPU go through the DDR firewall only.
Note: The dotted line in the diagram represents the path taken when an ACP access occurs and misses in the L1 and L2 cache.

Secure Transaction Protection

The interconnect provides two levels of transaction protection.

The two levels of transaction protection are:
  • Security Firewalls:

    Security firewalls enforce the Secure World read and write transactions. The term "security firewall" and "firewall" may be used interchangeably within the context of this section.

  • Privilege filter

    The privilege filter leverages the firewall mechanism and provides additional filtering by allowing control of the privilege level of L4 slave transactions. The privilege filter applies to writes only.

All slaves on the SoC are placed behind a security firewall. A subset of slaves are also placed behind a privilege filter. Transactions to these slaves pass through two firewall structures as shown in the figure below. The transaction packet must pass both a security firewall and the privilege filter to reach the slave. A transaction error causes random data or a slave error depending on where the transaction failed and how the error_response bit in the global register of the noc_fw_ddr_l3_ddr_scr module is programmed.

Note: Future devices may not support the return of random data and may only support an error response for blocked firewall transactions. For designs that may be ported to future devices, Intel recommends you to set the error_response bit in the global register.
Figure 26. Successful Secure Transaction Path

Each firewall has an associated firewall register which can be programmed by the DAP, FPGA fabric or MPU in secure mode only. A subset of the L4 slaves can additionally be programmed to configure their privilege filter policy.

Peripheral and System Firewalls

The peripheral and system firewalls each have a group of Security Configuration Registers (SCRs) that can be programmed by the DAP, FPGA fabric or MPU only in secure mode.

The peripheral and system firewalls can be configured by programming the security bits in the SCR blocks. Each slave has an SCR containing a security bit for each available master, which enables a different security access level to be programmed for each master-slave pair. At reset, all accesses are configured to be secure. When a master-slave security bit is 0, only secure packets are allowed to pass the firewall and reach the intended target. When the master-slave security bit is 1, the firewall passes the transaction.
Table 40.  Security Bit Value
Secure Flag Value Access
0 Only secure packets are allowed to pass the firewall.
1 Transaction packets are allowed to pass the firewall.

When a transaction packet is sent from a master, the master also drives a secure flag signal on the bus. This flag indicates whether the attempted transaction from the master is secure or non-secure. For AXI master accesses, this flag is the ~AxPROT[1] signal.

For L4 ECC, L4 system or L4 DDR master accesses, this flag is the MSecure[0] signal.

When the flag signal is driven high, it indicates a secure access. When the flag signal is low, it indicates a non-secure access.

Secure Transaction Example

A successful secure access attempt by a master, depends on the security bit configuration in the Security Control Register and the value of the master secure flag sent by the master.

All SoC transactions are set to secure out of reset with a return of random data when transactions are blocked. If you want an error response returned for blocked transactions, you must set the error_response bit in the global register of the noc_fw_ddr_l3_ddr_scr module at base address 0xFFD13400. If this bit is clear, transactions blocked by the firewall return random data.

Note: Future devices may not support the return of random data and may only support an error response for blocked firewall transactions. For designs that may be ported to future devices, Intel recommends you to set the error_response bit in the global register.

To initiate a secure transaction:

  1. The master drives the address of the slave as well as the master secure flag signal, indicating that the access is intended to be secure.
  2. The firewall compares the programmed security bit of the master-slave peripheral pair to the master secure flag signal to determine if the access is valid.
  3. If the access is valid, the transaction passes to the next level. If the access is not valid, random data is fed back to the master.
Table 41.  Peripheral and System Transaction Results

Security Bit in Firewall Register

Master Secure Flag

 Transaction Pass/Fail Transaction Type

0

0

No None (Blocked transaction)

0

1

 Yes Secure

1

0

 Yes Non-secure

1

1

 Yes Secure
Non-secure Transaction Configuration

When the SoC is released from reset, only secure transactions are allowed through the firewalls. The user must configure any master-slave pairs that are required to be non-secure.

The SCR registers must be accessed in secure mode to configure the firewall access to non-secure.
  1. After the SoC is released from reset, the MPU, FPGA2SOC masters or the DAP accesses the required Security Configuration Register (SCR) by executing a secure write. The peripheral firewall SCR registers are within the soc_noc_fw_l4_per register group and the system firewall SCR registers are found within the soc_noc_fw_l4_sys register group.
  2. To configure the slave to allow a non-secure access by a master, set the corresponding security bit to 1.
The configured master is able to successfully execute a non-secure read or write to the configured slave.
HPS-to-FPGA Firewall

The HPS-to-FPGA firewall is used to filter access to all the FPGA, including the HPS-to-FPGA bridge and the lightweight HPS-to-FPGA bridge.

The secure firewall for the HPS-to-FPGA can be disabled by programming the lwsoc2fpga register and soc2fpga register within the noc_fw_soc2fpga group.
On-Chip RAM Firewall

At reset all memories are secure. Out of reset, regions of memories can be configured for non-secure accesses.

The on-chip RAM is divided into six regions, where the granularity of the address boundary is 4 KB. Within each region, a non-secure or shared memory region can be assigned by programming a base and limit value in the corresponding regionNaddr register, with N denoting the region number. Each of these regions can be enabled by writing to the enable register or setting the corresponding bit in the enable_set register.

When an incoming transaction falls within any enabled non-secure regions, the firewall allows both secure and non-secure packets. When the transaction is outside of any enabled regions, the firewall only allows secure packets.

When a transaction packet is sent from a master, the master also drives a secure master flag signal on the bus. This flag indicates whether the attempted transaction from the master is for a secure or non-secure memory region. When the flag signal is driven high, it indicates a secure access. When the flag signal is low it indicates a non-secure access.

On-Chip RAM Transaction Configuration

Because all memories are secure when they exit reset, the on-chip RAM Security Control Register block must be configured by a secure master before non-secure or shared memory accesses are allowed.

  1. Configure the base and limit fields of the regionNaddr register, where N denotes the region number.
  2. Enable the non-secure memory region by setting the corresponding regionNenable bit in the enable_set register, where N denotes the region number.
SDRAM Firewall

Two SDRAM firewalls are implemented to allow a different security policy depending on the master.

One firewall filters accesses from the MPU and the FPGA-to-SDRAM interface. The other firewall filters accesses from all other masters on the HPS and applies the same security policy to both coherent and non-coherent accesses. Both firewalls are logically and physically split within the interconnect.

The SDRAM Firewall supports a minimum region size of 64 KB. Each master is allowed a different number of firewall regions:

  • The MPU can have up to four firewall regions.
  • The FPGA-to-SDRAM interface can have up to twelve firewall regions.
  • Any HPS bus master can have up to eight firewall regions.

Privilege Filter

If a transaction packet has passed the security firewall, it may pass through a privilege filter. The privilege filter only applies to writes. All reads are passed without exception.

The privilege filter decodes the incoming user or privilege accesses and determines whether to pass or fail the transaction. It is separate from the security firewall and transactions generally carry both privilege and secure bits. The privilege filters are configured in the interconnect by executing a read-modify-write to the l4_priv register or setting individual bits in the l4_set register. If a privilege bit is set, both privilege and user mode transactions are allowed to the slave. If a privilege bit is cleared using the l4_clear register, then only privileged transactions are allowed to the slave.

The following slaves can be programmed using the privilege registers in the interconnect module:

  • HPS-to-FPGA bridge
  • Lightweight HPS-to-FPGA bridge
  • UARTs
  • SP Timers
  • I2C Modules
  • GPIO
  • SD/MMC
  • QSPI
  • EMAC Modules
  • SPI
  • Secure and non-secure DMA
  • USB
  • NAND Controller
The following table shows the result of privileged and user master accesses based on the value of the programmed privilege bit for a particular slave.
Note: All read accesses pass regardless of the privilege bit value.
Table 42.  Privilege Filter Transaction

Read/Write

Privilege Signal

 Privilege bit Transaction Pass/Fail

Read

0

 0 Pass

0

 1 Pass

1

 0 Pass

1

 1 Pass

Write

0

 0 Fail

0

 1 Pass

1

 0 Pass

1

 1 Pass

Master Security Policy

Each master has an inherent security transaction capability.

Masters accessing slaves can be configured to one of three different security policies:

  • Per transaction: The master is capable of generating secure and non-secure transactions.
  • Secure: The master only supplies secure transactions.
  • Non-secure: The master only generates non-secure transactions.
At reset, all accesses default to secure transactions. The table below details the transaction capability of each master within the SoC. Some masters are only capable of non-secure transactions.
Table 43.  Master Transaction Capability

Master

 Transaction Capability

DMA

 Secure/Non-secure

DAP

 Secure/Non-secure

USB OTG 0/1

 Non-secure

SD/MMC

 Non-secure

EMAC0/1/2

 Secure/Non-secure

NAND

 Non-secure

FPGA-to HPS Bridge

 Secure/Non-secure

ETR

 Secure/Non-secure

MPU

 Secure/Non-secure

FPGA-to-SDRAM

 Secure/Non-secure

Security policies are based on secure and privilege attributes. For instance, if CPU0 is configured to access NAND registers in both secure and non-secure mode and CPU0 attempts an access when the core is in secure or non-secure mode, no error occurs. However, if CPU0 is allowed to access NAND registers only in secure mode and CPU0 is operating in non-secure mode, then CPU0 receives an error response when accessing the NAND registers. If both the security firewall and privilege firewall are implemented, security firewall filters all of the accesses. If an access fails, random data or an error response is sent to the master, depending on how the error_response bit in the global register of the noc_fw_ddr_l3_ddr_scr module is programmed. If access is granted by the security firewall, then the transaction enters the privilege firewall. If access is granted, the request enters the peripheral IP.

Note: Future devices may not support the return of random data and may only support an error response for blocked firewall transactions. For designs that may be ported to future devices, Intel recommends you to set the error_response bit in the global register.

Secure Interconnect Reset

When the SoC is released from reset, every slave on the interconnect is in the secure state (boot secure).

The only masters capable of secure accesses out of reset are:

  • MPU
  • DAP
  • HPS-to-FPGA fabric
Level Two Title