Intel Arria 10 Hard Processor System Technical Reference Manual
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.2 |
1. Intel Arria 10 Hard Processor System Technical Reference Manual Revision History
Document Version |
Changes |
---|---|
2017.05.31 | Removed HMCREGS row from HPS Peripheral Region Map table. Accesses to this address block are not supported. |
2016.10.28 | Renamed MPU Subsystem to Cortex*-A9 MPCore* |
2016.05.27 | Corrected the HPS-FPGA powering scheme. |
2016.05.03 |
Removed low-power double data rate 3 (LPDDR3) as a supported device. |
2015.11.02 | Updated the link to the Memory Maps. |
2015.05.04 | Corrected HPS-FPGA powering scheme. |
2014.12.15 | Maintenance release |
2014.08.18 |
Initial release |
Document Version | Changes |
---|---|
2017.07.22 |
|
2016.10.28 |
|
2016.05.27 |
Removed references to PLL counter outputs C9-C15
from the following topics:
|
2016.05.03 | Added a section titled "L4 Peripheral Clocks". |
2015.11.02 | Updated Sections:
Added Sections:
Updates:
|
2015.05.04 |
|
2014.12.15 |
Clock Manager Block Diagram. Updated mux output route. NOC clock added. Peripheral Clocks block update C15 input for PLL1 has been removed throughout document. |
2014.08.18 | Initial release. |
Document Version | Changes |
---|---|
2017.07.22 |
|
2016.10.28 | Maintenance release. |
2016.05.03 | Maintenance release. |
2015.11.02 | Updated "Reset Pins" section. |
2015.05.04 | "Slave Interface" and "Status Register" sections updated. |
2014.12.15 | Maintenance release. |
2014.08.18 | Initial release. |
Document Version |
Changes |
---|---|
2015.11.02 |
|
2015.05.04 | Maintenance release |
2014.12.15 | Maintenance release |
2014.08.18 | Initial release |
Document Version | Changes |
---|---|
2016.10.28 | Maintenance release. |
2016.05.27 | Removed the following references to the Ethernet
application interface:
|
2016.05.03 | Maintenance release. |
2015.11.02 | Maintenance release. |
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.08.18 | Initial release. |
Date | Version | Changes |
---|---|---|
July 2017 | 2017.07.21 |
|
October 2016 | 2016.10.28 | Maintenance release |
May 2016 | 2016.05.27 | Maintenance release |
May 2016 | 2016.05.03 |
|
November 2015 | 2015.11.02 | Clarified initialization steps in "Secure Initialization Overview" section |
May 2015 | 2015.05.04 | Added Address Map and Register information. |
December 2014 | 2014.12.15 |
|
August 2014 | 2014.08.18 | Initial Release |
Document Version |
Changes |
---|---|
2021.01.21 | Updated Arria 10 HPS Available Address Maps to explain how to access the registers that are connected to the HPS-to-FPGA AXI* Master Bridge. |
2019.01.01 | Updated ddrConf bitfield description in the ddr_T_main_Scheduler_Ddrconf register to include encodings. |
2018.09.24 | Updated the following section:
|
2017.05.31 |
|
2016.10.28 |
|
2016.05.27 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.08.18 | Initial release |
Document Version | Changes |
---|---|
2017.07.22 | Added note about bridge transaction timeout to "HPS-to-FPGA Bridge Clocks and Resets" and "Lightweight HPS-to-FPGA Bridge Clocks and Resets". |
2016.10.28 |
|
2016.05.27 | Maintenance release |
2015.11.02 | Maintenance release |
2015.05.04 | Added address maps and register definitions |
2014.12.15 | Maintenance release |
2014.08.18 |
Initial release. |
Document Version |
Changes |
---|---|
2020.08.18 | Added information about maintaining cache coherency in the Accelerator Coherency Port |
2019.06.14 | Added details about arbitration behavior in the SCU when the ACP is not being used in the Implementation Details of the Snoop Control Unit section, |
2016.10.28 |
|
2016.05.27 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.08.18 |
Initial Release |
Document Version |
Changes |
---|---|
2017.07.29 | Added reset requirement for BST |
2016.10.28 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 | Added a description on how the 2 TAP controllers are connected and supporting figures. |
2014.05.04 | Maintenance release. |
2014.12.15 | Maintenance release. |
2014.08.18 |
Initial release. |
Date | Version | Changes |
---|---|---|
October 2016 | 2016.10.28 | Maintenance Release |
May 2016 | 2016.05.27 | Maintenance Release |
May 2016 | 2016.05.03 | Maintenance Release |
November 2015 | 2015.11.02 |
|
May 2015 | 2015.05.04 |
|
December 2014 | 2014.12.15 |
Added the "RAM and ECC Memory Organization Example" subsection to the "ECC Structure" section Added the following subsections in the "Indirect Memory Access" section:
|
August 2014 | 2014.08.18 | Initial Release |
Document Version |
Changes |
---|---|
2014.08.18 | Initial release |
Document Version |
Changes |
---|---|
2016.05.27 | Added a link to the Supported Flash Devices for Arria 10 SoC webpage. |
2016.05.03 |
Added information about determining how many CE/RB signals are available based on the selected pins. |
2015.11.02 |
|
2015.05.04 | Added information about clearing out the ECC before the feature is enabled |
2014.12.15 | Maintenance release |
2014.08.18 |
Initial release |
Document Version | Changes |
---|---|
2017.07.22 | Corrected the MMC Support Matrix table in the "MMC Support Matrix" section. |
2016.10.28 | Removed SPI support in tables in the Features section. |
2016.05.27 | Added a link to the Supported Flash Devices for Arria 10 SoC webpage. |
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 | Added information about clearing out the ECC before the feature is enabled |
2014.12.15 | Maintenance release |
2014.08.18 | Initial release |
Document Version | Changes |
---|---|
2020.08.18 | Added clarification to the description of the QSPI register, indaddrtrig |
2019.07.09 | Added a new section, Write Request, with WREN and RDSR information |
2019.06.14 | Maintenance release |
2016.10.28 | Maintenance release |
2016.05.27 |
|
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 | Added information about clearing out the ECC before the feature is enabled |
2014.12.15 | Maintenance release |
2014.08.18 | Initial release |
Document Version |
Changes |
---|---|
2017.07.22 | Added information about DMA requiring that caches need to be enabled |
2016.10.28 | Maintenance release |
2016.05.27 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
Maintenance release |
2014.08.18 | Initial release |
Document Version | Changes |
---|---|
2020.08.18 | Updated EMAC HPS Interface Initialization to clarify how to verify RX PHY clocks after bringing the Ethernet PHY out of reset. |
2019.06.14 |
|
2016.10.28 |
|
2016.05.27 | Removed references to the Application Interface (also known as the switch interface). This feature is not supported in this device. |
2016.05.03 | Maintenance release. |
2015.11.02 |
|
2015.05.04 |
|
2014.12.06 |
|
2014.08.18 | Initial release. |
Document Version |
Changes |
---|---|
2018.01.26 | Added steps for enabling ECC. |
2016.10.28 | Maintenance release. |
2016.05.03 | Maintenance release. |
2015.11.02 |
|
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.08.18 |
Initial release. |
Document Version | Changes |
---|---|
2015.11.02 |
|
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.08.18 | Initial release. |
Document Version | Changes |
---|---|
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.08.18 | Initial release. |
Document Version | Changes |
---|---|
2015.11.02 | Renamed Interface Pins section to HPS I/O Pins and moved this section and FPGA Routing under UART Controller Signal Description |
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.08.18 | Initial release. |
Document Version | Changes |
---|---|
2014.12.15 |
|
2014.08.18 | Initial release. |
Version | Changes |
---|---|
2014.08.18 | Initial release. |
Document Version | Changes |
---|---|
2015.11.02 | Added note to "Watchdog Timer Counter" section. |
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.08.18 | Initial release |
Document Version |
Changes |
---|---|
2019.06.14 | Updated the PU_DRV_STRG and PD_DRV_STRG fields in the pinmux_dedicated_io_1 through pinmux_dedicated_io_17 registers in the io48_pin_mux_dedicated_io_grp. |
2018.09.24 | Updated the following section:
|
2016.10.28 | Maintenance release |
2016.05.27 | Maintenance release. |
2016.05.03 | Maintenance release |
2015.11.02 | Maintenance release |
2015.05.04 | Added address maps and register definitions |
2014.08.18 | Initial release |
Document Version |
Changes |
---|---|
2016.05.03 | Removed FPGA‑to‑HPS SDRAM interface |
2015.11.02 | Maintenance release |
2015.05.04 | Maintenance release |
2014.12.15 | Maintenance release |
2014.08.18 | Initial release |
Document Version |
Changes |
---|---|
2016.05.27 | Removed FPGA EMAC Switch Interface section. The application interface (also called the switch interface) is not supported. |
2016.05.03 |
Maintenance release. |
2015.11.02 | Added content regarding peripheral pin placmement in HPS shared and dedicated I/O to the "Configuring Peripherals" section. |
2015.05.04 |
|
2014.12.15 |
Initial release. |
Document Version | Changes |
---|---|
2016.05.27 | Removed FPGA EMAC Switch Interface section. The application interface (also called the switch interface) is not supported. |
2016.05.03 | Maintenance release. |
2015.11.02 |
|
2015.05.04 | Maintenance release. |
2014.12.15 | Initial release. |
Document Version |
Changes |
---|---|
2016.05.27 | Removed FPGA EMAC Switch Interface section. The application interface (also called the switch interface) is not supported. |
2016.05.03 | Removed references to FPGA to HPS SDRAM simulation. |
2015.11.02 | Added information about the signals on the "Advanced FPGA Placement" tab. |
2015.05.04 | Maintenance release. |
2014.12.15 |
Maintenance release. |
2014.08.15 |
Initial release. |
Document Version | Changes |
---|---|
2018.11.02 | Added note regarding SD card image partitioning in the SD/MMC Flash Devices section. |
2017.12.15 | Removed CM_PLL_CLK* signals from "Boot Source MUX Selects" table in Boot Source I/O Pins section |
2017.07.22 |
|
2017.07.10 |
|
2017.05.31 |
|
2016.10.28 | Modified the "Remapping the On-Chip RAM" diagram in the "Typical Boot Flow (Non-secure)" section |
2016.05.27 |
|
2016.05.03 |
|
2015.12.11 | Updated the Full FPGA Reconfiguration section with the supported reconfiguration options. |
2015.11.02 | Added Intel® Quartus® Prime setting information to "Early I/O Release FPGA Configuration Through HPS" section |
2015.06.12 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.08.18 |
Initial release |
2. Introduction to the Hard Processor System
The Intel® Arria® 10 system-on-a-chip (SoC) is composed of two distinct portions- a dual-core Arm* Cortex*-A9 hard processor system (HPS) and an FPGA. The HPS architecture integrates a wide set of peripherals that reduce board size and increase performance within a system. A dedicated security manager within the HPS supports secure boot with the ability to authenticate, decrypt and provide tamper event response.
Figure 1 shows a high-level block diagram of the Intel® Arria® 10 SoC device. Blocks connected to device pins have symbols (square with an X) adjacent to them in the figure.
- Dedicated I/O - I/O that is dedicated to an external non-volatile storage device (for boot ROM), HPS clock and resets.
- Shared I/O - I/O that can be assigned to peripherals in the HPS or FPGA logic.
- FPGA I/O - I/O that is dedicated to the FPGA fabric.
- Microprocessor unit (MPU) subsystem with a dual Arm* Cortex*-A9 MPCore* processors
- Flash memory controllers
- SDRAM L3 interconnect
- System interconnect
- On-chip memories
- Support peripherals
- Interface peripherals
- Debug components
- Phase-locked loops (PLLs)
The HPS incorporates third-party intellectual property (IP) from several vendors.
The dual-processor HPS supports symmetric (SMP) and asymmetric (AMP) multiprocessing.
- FPGA fabric
- Configuration sub-system (CSS)
- PLLs
- High-speed serial interface (HSSI) transceivers, depending on the device variant
- Hard PCI Express* (PCI-e) controllers
- Hard memory controllers
The HPS and FPGA communicate with each other through bus interfaces that bridge the two distinct portions. On a power-on reset, the HPS can boot from multiple sources, including the FPGA fabric and external flash. The FPGA can be configured through the HPS or an externally supported device.
The HPS and FPGA portions of the device each have their own pins. The HPS has dedicated I/O pins and can also share some FPGA I/O pins. Pin assignments are configured when the HPS component is instantiated in Platform Designer (Standard). At boot time, software executing on the HPS assigns the I/O pins to the available HPS modules and configures the I/O pins through I/O control registers. For more information, refer to the "Hard Processor System I/O Pin Multiplexing" chapter. The FPGA I/O pins are configured by an FPGA configuration image through the HPS or any external source supported by the device.
- You can boot the HPS independently. After the HPS is running, the HPS can fully or partially reconfigure the FPGA fabric at any time under software control. The HPS can also configure other FPGAs on the board through the FPGA configuration controller.
- You can configure the FPGA fabric first, and then boot the HPS from the memory accessible to the FPGA fabric.
2.1. Features of the HPS
The main modules of the HPS are:
- MPU subsystem featuring a dual-core Arm* Cortex*-A9 MPCore* processor
- System interconnect that includes
three memory-mapped interfaces between the HPS and FPGA:
- HPS-to-FPGA: 32-, 64-, or 128-bit wide AXI-4
- Lightweight HPS-to-FPGA: 32-bit wide AXI-4
- FPGA-to-HPS: 32-, 64-, or 128-bit wide ACE
- General-purpose direct memory access (DMA) controller
- Security manager
- Supports peripheral memories with single-error correction and double-error detection (SECDED)
- Three Ethernet media access controllers (EMACs)
- Two USB 2.0 on-the-go (OTG) controllers
- NAND flash controller
- Quad serial peripheral interface (QSPI) flash controller
- Secure digital/multimedia card (SD/MMC) controller
- Two serial peripheral interface (SPI) master controllers
- Two SPI slave controllers
- Five inter-integrated circuit (I2C) controllers1
- 256 KB on-chip RAM
- 128 KB on-chip boot ROM
- Two UARTs
- Four system timers
- Two watchdog timers
- Three general-purpose I/O (GPIO) interfaces
-
Arm*
CoreSight*
debug components:
- Debug access port (DAP)
- Trace port interface unit (TPIU)
- System trace macrocell (STM)
- Program trace macrocell (PTM)
- Embedded trace router (ETR)
- Embedded cross trigger (ECT)
- System manager
- Clock manager
- Reset manager
- FPGA manager
2.2. HPS Block Diagram and System Integration
2.2.1. HPS Block Diagram
2.2.2. Cortex-A9 MPCore
The MPU subsystem is a stand-alone, full-featured Arm* Cortex*-A9 MPCore* dual-core 32-bit application processor. It provides the following functionality:
-
Arm*
Cortex*-A9
MPCore*
- Two Arm* Cortex*-A9 processors
- NEON* single instruction, multiple data (SIMD) coprocessor and vector floating-point v3 (VFPv3) per processor
- Snoop control unit (SCU) to ensure coherency between processors
- Accelerator coherency port (ACP) that accepts coherency memory access requests
- Interrupt controller
- One general-purpose timer and one watchdog timer per processor
- Debug and trace features
- 32 KB instruction and 32 KB data level 1 (L1) caches per processor
- Memory management unit (MMU) per processor
-
Arm*
L2-310 level 2
(L2) cache
- Shared 512 KB L2 cache
As shown in the "HPS Block Diagram", the L2 cache has one 64-bit master port that is connected to the main L3 interconnect and one 64-bit master port connected to the SDRAM L3 interconnect. A programmable address filter in the L2 cache controls which portions of the 32-bit physical address space can be accessed by each master.
2.2.3. HPS Interfaces
2.2.3.1. HPS–FPGA Memory-Mapped Interfaces
The HPS–FPGA memory-mapped interfaces provide the major communication channels between the HPS and the FPGA fabric. The HPS–FPGA memory-mapped interfaces include:
- FPGA–to–HPS bridge—a high–performance bus with a configurable data width of 32, 64, or 128 bits, allowing the FPGA fabric to master transactions to the slaves in the HPS. This interface allows the FPGA fabric to have full visibility into the HPS address space. This interface also provides access to the coherent memory interface
- HPS–to–FPGA bridge—a high–performance interface with a configurable data width of 32, 64, or 128 bits, allowing the HPS to master transactions to slaves in the FPGA fabric
- Lightweight HPS–to–FPGA bridge—an interface with a 32–bit fixed data width, allowing the HPS to master transactions to slaves in the FPGA fabric
2.2.3.2. Other HPS Interfaces
- TPIU trace—sends trace data created in the HPS to the FPGA fabric
- FPGA System Trace Macrocell (STM)—an interface that allows the FPGA fabric to send hardware events to be stored in the HPS trace data
- FPGA cross–trigger—an interface that allows the CoreSight* trigger system to send triggers to IP cores in the FPGA, and vise versa
- DMA peripheral interface—multiple peripheral–request channels
- FPGA manager interface—signals that communicate with the FPGA fabric for boot and configuration
- Interrupts—allow soft IP cores to supply interrupts directly to the MPU interrupt controller
- MPU standby and events—signals that notify the FPGA fabric that the MPU is in standby mode and signals that wake up Cortex*-A9 processors from a wait for event (WFE) state
- HPS debug interface – an interface that allows the HPS debug control domain (debug APB* ) to extend into FPGA
Another HPS–FPGA communications channel is FPGA clocks and resets.
2.2.4. System Interconnect
The system interconnect consists of the main L3 interconnect, SDRAM L3 interconnect, and level 4 (L4) buses. The system interconnect is based on the Arteris* FlexNoC* network-on-chip (NoC) interconnect module. The system interconnect incorporates configurable secure firewalls protecting each peripheral.
The L4 buses are each connected to a master in the main L3 interconnect. Each L4 bus is 32 bits wide and is connected to multiple slaves. Each L4 bus operates on a separate clock source.
The SDRAM L3 interconnect consists of the SDRAM adapter and the SDRAM scheduler. SDRAM is protected by firewalls in the SDRAM L3 interconnect.
2.2.4.1. Arria 10 HPS SDRAM L3 Interconnect
The SDRAM L3 interconnect is part of the system interconnect and connects the HPS to the hard memory controller that is located in the FPGA fabric. The SDRAM L3 interconnect is composed of the SDRAM adapter and the SDRAM scheduler, which are secured by firewalls. It supports Arm* Advanced Microcontroller Bus Architecture ( AMBA* ) Advanced eXtensible Interface ( AXI* ) quality of service (QoS) for the fabric interfaces
The hard memory controller implements the following high-level features:
- Support for double data rate 3 (DDR3) and DDR4 devices
- Software-configurable priority scheduling on individual SDRAM bursts
- Error correction code (ECC) support, including calculation, single‑bit error correction and write-back, and error counters
- Fully-programmable timing parameter support for all JEDEC‑specified timing parameters
- All ports support memory protection and mutual-exclusive accesses
- FPGA-to-SDRAM interface—a configurable interface to the SDRAM
scheduler in the SDRAM L3 interconnect You can configure the following
parameters:
- Up to three bridges
- Up to 288 bits across all three ports
2.2.4.1.1. SDRAM Adapter
2.2.4.1.2. SDRAM Scheduler
2.2.5. On-Chip Memory
2.2.5.1. On-Chip RAM
The on-chip RAM offers the following features:
- 256 KB size
- 64-bit slave interface
- High performance for all burst lengths
- ECC support provides detection of single–bit and double–bit errors and correction for single-bit errors
- Can clear the on-chip RAM on reset
2.2.5.2. Boot ROM
The boot ROM offers the following features:
- 32-bit interface
- Capable of data transfers for every clock cycle
- 128 KB size
- Contains the code required to support both secure and non-secure HPS boot from cold or warm reset
- Used exclusively for booting the HPS
2.2.6. Flash Memory Controllers
2.2.6.1. NAND Flash Controller
The NAND flash controller is based on the Cadence® Design IP® NAND Flash Memory Controller and offers the following functionality and features:
- Supports up to four chip selects. One chip select is connected to an HPS I/O pin and the rest can be connected to the FPGA I/O pins.
- Integrated descriptor-based DMA controller
- 8-bit and 16-bit ONFI 1.0 NAND flash devices
- Programmable page sizes of 512 bytes, 2 KB, 4 KB, and 8 KB
- Supports 32, 64, 128, 256, 384, and 512 pages per block
- Programmable hardware ECC for single-level cell (SLC) and multi-level cell (MLC) devices
- 512-byte ECC sector size with 4-, 8-, or 16-bit correction
- 1 KB ECC sector size with 24-bit correction
2.2.6.2. Quad SPI Flash Controller
The quad SPI flash controller is used for access to serial NOR flash devices. It supports standard SPI flash devices as well as high-performance dual and quad SPI flash devices. The Quad SPI flash controller is based on the Cadence Quad SPI Flash Controller and offers the following features:
- Supports SPIx1, SPIx2, or SPIx4 (Quad SPI) serial NOR flash devices
- Supports direct access and indirect access modes
- Supports single, dual, and quad I/O instructions
- Support up to four chip selects
- Programmable write-protected regions
- Programmable delays between transactions
- Programmable device sizes
- Support eXecute-In-Place (XIP) mode
- Programmable baud rate generator to generate device clocks
2.2.6.3. SD/MMC Controller
The Secure Digital (SD), Multimedia Card (MMC), (SD/MMC) and CE-ATA host controller is based on the Synopsys* DesignWare* Mobile Storage Host controller and offers the following features:
- Integrated descriptor-based DMA
- Supports CE-ATA digital protocol commands
- Supports single card
- Single data rate (SDR) mode only
- Programmable card width: 1-, 4-, and 8-bit
- Programmable card types: SD, SDIO, or MMC
- Up to 64 KB programmable block size
- Supports the following standards and card types:
- Supports various types
of multimedia cards, MMC version 4.414
- MMC: 1-bit data bus
- Reduced-size MMC (RSMMC): 1-bit and 4-bit data bus
- MMCMobile: 1-bit data bus
- Supports embedded MMC
(eMMC) version 4.55
- 1-bit, 4-bit, and 8-bit data bus
2.2.7. Support Peripherals
2.2.7.1. Clock Manager
- Manages clocks for HPS
- Supports clock gating at the signal level
- Supports dynamic clock tuning
2.2.7.2. Reset Manager
The reset domains and sequences support several security features. The security manager brings the reset manager out of reset only when device security is confirmed. Afterwards, the reset manager brings the rest of the HPS system out of reset. The reset manager performs the following functions:
- Manages resets for HPS
- Controls the resets for cold, warm, debug, and TAP reset domains
- Controls the RAM clearing domain separately
2.2.7.3. Security Manager
The security manager module is integrated in the HPS and provides the overall management of security within the SoC, including:
- Recognition of secure fuse configuration, preventing non-secure device startup
- State control and check of the security features
- Secure boot options
- Secure debug options
- Anti-tamper support
2.2.7.4. System Manager
The system manager contains logic to control system functions and logic to control other modules that need external control signals provided as part of system integration. The system manager offers the following features:
- Provides combined ECC status and interrupts from other HPS modules with ECC-protected RAM
- Low-level control of peripheral features not accessible through the control and status registers (CSRs)
2.2.7.5. System Timers
The HPS provides four 32-bit general-purpose timers connected to the level 4 (L4) peripheral bus. The four system timers are based on the Synopsys DesignWare Advanced Peripheral Bus (APB) Timers peripheral and offer the following features:
- 32-bit timer resolution
- Free-running timer mode
- Programmable time-out period up to approximately 86 seconds (assuming a 50 MHz input clock frequency)
- Interrupt generation
2.2.7.6. System Watchdog Timers
- 32-bit timer resolution
- Interrupt request
- Reset request
- Programmable time-out period up to approximately 86 seconds
(assuming a 50 MHz input clock frequency) Note: Countdown can be paused when the MPU is in debug mode.
2.2.7.7. DMA Controller
The DMA controller provides high-bandwidth data transfers for modules without integrated DMA controllers. The DMA controller is based on the Arm* Corelink* DMA Controller (DMA‑330) and offers the following features:
- Micro-coded to support
flexible transfer types
- Memory-to-memory
- Memory-to-peripheral
- Peripheral-to-memory
- Scatter-gather
- Supports up to eight channels
- Supports flow control with 32 peripheral handshake interfaces
2.2.7.8. FPGA Manager
The FPGA manager manages and monitors the FPGA portion of the SoC device. The FPGA manager can configure the FPGA fabric from the HPS, monitor the state of the FPGA, and drive or sample signals to or from the FPGA fabric.
2.2.7.9. Error Checking and Correction Controller
ECC controllers provide single- and double-bit error memory protection for integrated on-chip RAM and peripheral RAMs within the HPS.
- USB OTG 0 - 1
- SD/MMC Controller
- EMAC 0 - 2
- DMA controller
- NAND flash controller
- QSPI flash controller
- Single-bit error detection and correction
- Double-bit error detection
- Interrupts generated on single- and double-bit errors
2.2.8. Interface Peripherals
2.2.8.1. EMACs
- Supports 10, 100, and 1000 Mbps standard
- PHY interfaces
supported through the HPS I/O pins:
- Reduced media independent interface (RMII) and Reduced gigabit media independent interface (RGMII) through the HPS I/O pins
- PHY interfaces supported using adapter logic to route
signals to the FPGA I/O pins:
- Media independent interface (MII), Gigabit media independent interface (GMII), RMII, RGMII, and Serial gigabit media independent interface (SGMII) (with external conversion logic) through the FPGA pins
- Integrated DMA controller
- Supports IEEE 1588-2002 and IEEE 1588-2008 standards for precision networked clock synchronization
- IEEE 802.3-az, version D2.0 of Energy Efficient Ethernet
- Supports IEEE 802.1Q Virtual local area network (VLAN) tag detection for reception frames
- PHY Management control through Management data input/output (MDIO) interface or I2C interface
- 4 KB TX FIFO and 16 KB RX FIFO RAM
- Supports a variety of address filtering modes
2.2.8.2. USB Controllers
The HPS provides two USB 2.0 Hi-Speed On-the-Go (OTG) controllers from Synopsys DesignWare. The USB controller signals cannot be routed to the FPGA like those of other peripherals; instead they are routed to the dedicated I/O.
Each of the USB controllers offers the following features:
- Complies with the
following specifications:
- USB OTG Revision 1.3
- USB OTG Revision 2.0
- Embedded Host Supplement to the USB Revision 2.0 Specification
- Supports software-configurable modes of operation between OTG 1.3 and OTG 2.0
- Supports all USB 2.0
speeds:
- High speed (HS, 480-Mbps)
- Full speed (FS, 12-Mbps)
- Low speed (LS,
1.5-Mbps) Note: In host mode, all speeds are supported; however, in device mode, only high speed and full speed are supported.
- Local buffering with Error Correction Code (ECC) support Note:The USB 2.0 OTG controller does not support the following interface standards:
- Enhanced Host Controller Interface (EHCI)
- Open Host Controller Interface (OHCI)
- Universal Host Controller Interface (UHCI)
- Supports USB 2.0 Transceiver Macrocell Interface Plus (UTMI+) Low Pin Interface (ULPI) PHYs (SDR mode only)
- Supports up to 16 bidirectional endpoints, including control
endpoint 0 Note: Only seven periodic device IN endpoints are supported.
- Supports up to 16 host channels Note: In host mode, when the number of device endpoints is greater than the number of host channels, software can reprogram the channels to support up to 127 devices, each having 32 endpoints (IN + OUT), for a maximum of 4,064 endpoints.
- Supports generic root hub
- Supports automatic ping capability
2.2.8.3. I2C Controllers
- Three controllers optionally can be used as a control
interface for Ethernet PHY communication Note: When an I2C controller is used for Ethernet, it will take the place of the MDIO pins.
- Support both 100 KBps and 400 KBps modes
- Support both 7-bit and 10-bit addressing modes
- Support master and slave operating mode
- Direct access for host processor
- DMA controller may be used for large transfers
2.2.8.4. UARTs
The HPS provides two UART controllers to provide asynchronous serial communications. The two UART modules are based on Synopsys* DesignWare* APB* Universal Asynchronous Receiver/ Transmitter peripheral and offer the following features:
- 16550-compatible UART
- Support automatic flow control as specified in 16750 standard
- Programmable baud rate up to 6.25 MBaud (with 100MHz reference clock)
- Direct access for host processor
- DMA controller may be used for large transfers
- 128-byte transmit and receive FIFO buffers
- Separate thresholds for DMA request and handshake signals to maximize throughput
2.2.8.5. SPI Master Controllers
- Programmable data frame size from 4 bits to 16 bits
- Supports full- and half-duplex modes
- Supports two chip selects connected to HPS I/O
- Supports four chip selects connected to the FPGA fabric
- Direct access for host processor
- DMA controller may be used for large transfers
- Programmable master serial bit rate
- Support for rxd sample delay
- Transmit and receive FIFO buffers are 256 words deep
- Choice of Motorola® SPI, Texas Instruments® Synchronous Serial Protocol or National Semiconductor® Microwire protocol
2.2.8.6. SPI Slave Controllers
- Programmable data frame size from 4 bits to 16 bits
- Supports full- and half-duplex modes
- Direct access for host processor
- DMA controller may be used for large transfers
- Transmit and receive FIFO buffers are 256 words deep
2.2.8.7. GPIO Interfaces
- Supports digital de-bounce
- Configurable interrupt mode
- Supports up to 17 dedicated 1.8 V and 3.0 V HPS I/O pins used for clock, reset, and external flash devices
- Supports up to 48 shared 3.0 V I/O pins that can be used by either the HPS or the FPGA. These pins are useful for Ethernet, USB, and other communication functions
2.2.9. CoreSight Debug and Trace
- Real-time program flow instruction trace through a separate PTM for each processor
- Host debugger JTAG interface
- Connections for cross-trigger and STM-to-FPGA interfaces, which enable soft IP cores to generate of triggers and system trace messages
- Custom message injection through STM into trace stream for delivery to host debugger
- Capability to route trace data to any slave accessible to the ETR master, which is connected to the level 3 (L3) interconnect
2.2.10. Hard Processor System I/O Pin Multiplexing
The SoC has a total of 48 flexible I/O pins that are used for hard processor system (HPS) operation, external flash memories, and external peripheral communication. All of the 48 HPS I/O pins can also act as loaner I/O from the FPGA fabric. A pin multiplexing mechanism allows the SoC to use the flexible I/O pins in a wide range of configurations.
2.3. Endian Support
The HPS is natively a little–endian system. All HPS slaves are little endian.
The processor masters are software configurable to interpret data as little endian, big endian, or byte–invariant (BE8). All other masters, including the USB 2.0 interface, are little endian. Registers in the MPU and L2 cache are little endian regardless of the endian mode of the CPUs.
The FPGA–to–HPS, HPS–to–FPGA, FPGA–to–SDRAM, and lightweight HPS–to–FPGA interfaces are little endian.
If a processor is set to BE8 mode, software must convert endianness for accesses to peripherals and DMA linked lists in memory. The processor provides instructions to swap byte lanes for various sizes of data.
The Arm* Cortex*-A9 MPU supports a single instruction to change the endianness of the processor and provides the REV and REV16 instructions to swap the endianness of bytes or half–words respectively. The MMU page tables are software configurable to be organized as little–endian or BE8.
The Arm* DMA controller is software configurable to perform byte lane swapping during a transfer.
2.4. Introduction to the Hard Processor System Address Map
The address map specifies the addresses of slaves, such as memory and peripherals, as viewed by the MPU and other masters. The HPS has multiple address spaces, defined in the following section.
2.4.1. HPS Address Spaces
The following table shows the HPS address spaces and their sizes.
Name |
Description |
Size |
---|---|---|
MPU |
MPU subsystem |
4 GB |
L3 |
System interconnect |
4 GB |
SDRAM |
SDRAM region |
4 GB |
Address spaces are divided into one or more nonoverlapping regions. For example, the MPU address space has the peripheral, FPGA slaves, SDRAM window, and boot regions.
The following figure shows the relationships between the HPS address spaces. The figure is not to scale.
The SDRAM window in the MPU address space can grow and shrink at the top and bottom (short, blue vertical arrows) at the expense of the FPGA slaves and boot regions. For specific details, refer to “MPU Address Space”.
Region Name |
Base Address |
Size |
---|---|---|
FPGA slaves |
0xC0000000 |
960 MB |
Peripheral |
0xFC000000 |
64 MB |
Lightweight FPGA slaves |
0xFF200000 |
2 MB |
2.4.1.1. SDRAM Address Space
The SDRAM address space is up to 4 GB. The entire address space can be accessed through the FPGA‑to‑SDRAM interface from the FPGA fabric. The total amount of SDRAM addressable from the other address spaces can be configured at runtime.
There are cacheable and non-cacheable views into the SDRAM space. When a master of the L3 SDRAM interconnect performs a cacheable access to the SDRAM, the transaction is performed through the ACP port of the MPU subsystem. When a master of the SDRAM L3 interconnect performs a non-cacheable access to the SDRAM, the transaction is performed through the 64-bit L3 interconnect master of the SDRAM L3 interconnect.
2.4.1.2. MPU Address Space
The MPU address space is 4 GB and applies to addresses generated inside the MPU.
- The SDRAM window region provides access to a large, configurable portion of the 4 GB SDRAM address space.
The address filtering start and end registers in the L2 cache controller define the SDRAM window boundaries. The boundaries are megabyte-aligned. Addresses within the boundaries route to the SDRAM master. Addresses outside the boundaries route to the system interconnect master.
2.4.1.3. FPGA Slaves Address Space
The FPGA Slaves address space is located in the FPGA core and accessed from the HPS through the HPS2FPGA AXI Bridge. The FPGA Slaves address space in the FPGA core is of unlimited size (soft logic in the FPGA performs address decoding). The L3 and MPU regions provide a window of nearly 1GB (actually 1GB less 64MB) into the FPGA Slaves address space. The base address of the FPGA Slaves Window is mapped to address 0x0 in the FPGA Slaves address space.
The HPS is able to boot from offset 0x0 into the FPGA Slaves address space (BSELselection).
2.4.1.4. LWFPGA Slaves Address Space
The Lightweight (LW) FPGA Slaves address space is located in the FPGA core and accessed from the HPS through the LWHPS2FPGA Bridge. The LWFPGA Slaves address space in the FPGA core is of unlimited size (soft logic in the FPGA performs address decoding). A portion of the Peripheral region provides a window of 2MB into the LWFPGA Slaves address space. The base address of the LWFPGA Slaves window is mapped to address 0x0 in the LWFPGA Slaves address space.
The HPS is not able to boot from the LWFPGA Slaves address space.
2.4.1.5. L3 Address Space
The L3 address space is 4 GB and applies to all L3 masters except the MPU. The L3 address space has more configuration options than the other address spaces.
2.4.2. HPS Peripheral Region Address Map
Each peripheral slave interface has a dedicated address range in the peripheral region. The table below lists the base address and address range size for each slave.
Slave Identifier | Description | Base Address | Size |
---|---|---|---|
STM | STM module | 0xFC000000 | 48 MB |
DAP | DAP module | 0xFF000000 | 2 MB |
LWFPGASLAVES | FPGA slaves accessed through lightweight HPS2FPGA bridge module | 0xFF200000 | 2 MB |
EMAC0 | EMAC0 module | 0xFF800000 | 8 KB |
EMAC1 | EMAC1 module | 0xFF802000 | 8 KB |
EMAC2 | EMAC2 module | 0xFF804000 | 8 KB |
SDMMC | SD/MMC module | 0xFF808000 | 4 KB |
QSPIREGS | QSPI flash controller module registers | 0xFF809000 | 4 KB |
EMAC0RXECC | Receive ECC, Ethernet MAC0 | 0xFF8C0800 | 1 KB |
EMAC0TXECC | Transmit ECC, Ethernet MAC0 | 0xFF8C0C00 | 1 KB |
EMAC1RXECC | Receive ECC, Ethernet MAC1 | 0xFF8C1000 | 1 KB |
EMAC1TXECC | Transmit ECC, Ethernet MAC1 | 0xFF8C1400 | 1 KB |
EMAC2RXECC | Receive ECC, Ethernet MAC2 | 0xFF8C1800 | 1 KB |
EMAC2TXECC | Transmit ECC, Ethernet MAC2 | 0xFF8C1C00 | 1 KB |
NANDECC | NAND ECC | 0xFF8C2000 | 1 KB |
NANDREADECC | NAND read ECC | 0xFF8C2400 | 1 KB |
NANDWRITEECC | NAND write ECC | 0xFF8C2800 | 1 KB |
SDMMCECC | SD/MMC ECC | 0xFF8C2C00 | 1 KB |
OCRAMECC | On-chip RAM ECC | 0xFF8C3000 | 1 KB |
DMAECC | DMA ECC | 0xFF8C8000 | 1 KB |
QSPIECC | QSPI ECC | 0xFF8C8400 | 1 KB |
USB0ECC | USB 2.0 OTG 0 ECC | 0xFF8C8800 | 1 KB |
USB1ECC | USB 2.0 OTG 1 ECC | 0xFF8C8C00 | 1 KB |
QSPIDATA | QSPI flash module data | 0xFFA00000 | 1 MB |
USB0 | USB 2.0 OTG 0 controller module registers | 0xFFB00000 | 256 KB |
USB1 | USB 2.0 OTG 1 controller module registers | 0xFFB40000 | 256 KB |
NANDREGS | NAND controller module registers | 0xFFB80000 | 64 KB |
NANDDATA | NAND controller module data | 0xFFB90000 | 64 KB |
UART0 | UART0 module | 0xFFC02000 | 256 B |
UART1 | UART1 module | 0xFFC02100 | 256 B |
I2C0 | I2C0 module | 0xFFC02200 | 256 B |
I2C1 | I2C1 module | 0xFFC02300 | 256 B |
I2C2 | I2C2 module (can be used with EMAC0) | 0xFFC02400 | 256 B |
I2C3 | I2C3 module (can be used with EMAC1) | 0xFFC02500 | 256 B |
I2C4 | I2C4 module (can be used with EMAC2) | 0xFFC02600 | 256 B |
SPTIMER0 | SP Timer0 module | 0xFFC02700 | 256 B |
SPTIMER1 | SP Timer1 module | 0xFFC02800 | 256 B |
GPIO0 | GPIO0 module | 0xFFC02900 | 256 B |
GPIO1 | GPIO1 module | 0xFFC02A00 | 256 B |
GPIO2 | GPIO2 module | 0xFFC02B00 | 256 B |
HMCAREGS | Hard memory controller adapter control registers | 0xFFCFB000 | 4 KB |
SECMGRDATA | Security manager module data | 0xFFCFE000 | 1 KB |
FPGAMGRDATA | FPGA manager module configuration data | 0xFFCFE400 | 1 KB |
OSC1TIMER0 | OSC1 Timer0 module | 0xFFD00000 | 256B |
OSC1TIMER1 | OSC1 Timer1 module | 0xFFD00100 | 256B |
L4WD0 | Watchdog0 module | 0xFFD00200 | 256B |
L4WD1 | Watchdog1 module | 0xFFD00300 | 256B |
SECMGRREGS | Security manager module control and status registers | 0xFFD02000 | 4 KB |
FPGAMGRREGS | FPGA manager module control and status registers | 0xFFD03000 | 4 KB |
CLKMGR | Clock manager module | 0xFFD04000 | 4 KB |
RSTMGR | Reset manager module | 0xFFD05000 | 4 KB |
SYSMGR | System manager module | 0xFFD06000 | 4 KB |
IOMGR | I/O manager module | 0xFFD07000 | 4 KB |
FWL4PRIV | L4 privilege firewall registers | 0xFFD11000 | 256 B |
MPURADAPTER | MPU rate adapter registers | 0xFFD11100 | 3.84 KB |
DDRPRB | DDR probe registers | 0xFFD12000 | 1 KB |
SCHREGS | DDR scheduler control registers | 0xFFD12400 | 128 B |
FWL4PER | L4 peripheral firewall registers |
0xFFD13000 |
256 B |
FWL4SYS | L4 system firewall registers |
0xFFD13100 |
256 B |
FWOCRAM | On-chip RAM firewall registers |
0xFFD13200 |
256 B |
FWFPGA2SDRAM | DDR firewall registers for FPGA-to-SDRAM |
0xFFD13300 |
256 B |
FWDDRL3 | DDR L3 firewall registers |
0xFFD13400 |
256 B |
FWHPS2FPGA | HPS-to-FPGA firewall registers |
0xFFD13500 |
256 B |
L4PRB | L4 bus probe registers | 0xFFD14000 | 4 KB |
MPUPRB | MPU probe and test registers | 0xFFD15000 | 4 KB |
L4QOS | L4 bus QoS | 0xFFD16000 | 4 KB (estimated) |
EMACTSF | EMAC transaction status filter registers | 0xFFD1 7080 | 44 B |
DMANONSECURE | DMA non-secure module registers | 0xFFDA0000 | 4 KB |
DMASECURE | DMA secure module registers | 0xFFDA1000 | 4 KB |
SPI0 | SPI module 0 slave | 0xFFDA2000 | 4 KB |
SPI1 | SPI module 1 slave | 0xFFDA3000 | 4 KB |
SPI2 | SPI module 0 master | 0xFFDA4000 | 4 KB |
SPI3 | SPI module 1 master | 0xFFDA5000 | 4 KB |
OCRAM | On-chip RAM module | 0xFFE00000 | 1 MB (256 KB used) |
ROM | Boot ROM Module | 0xFFFC0000 | 128 KB |
MPU | MPU Module Registers | 0xFFFFC000 | 8 KB |
MPUL2 | MPU L2 Cache Controller Module Registers | 0xFFFFF000 | 4 KB |
3. Clock Manager
The hard processor system (HPS) clock generation is centralized in the clock manager. The clock manager is responsible for providing software-programmable clock control to configure all clocks generated in the HPS. Clocks are organized in clock groups. A clock group is a set of clock signals that originate from the same clock source. A phase-locked loop (PLL) clock group is a clock group where the clock source is a common PLL voltage-controlled oscillator (VCO).
3.1. Features of the Clock Manager
The Clock Manager offers the following features:
- Generates and manages clocks in the HPS
- Contains the following
clock groups:
- Main—contains clocks for the Cortex*-A9 microprocessor unit (MPU) subsystem, level 3 (L3) interconnect, level 4 (L4) peripheral bus, and debug
- Peripheral—contains clocks for PLL-driven peripherals
- Contains two identical
16-output PLL blocks:
- PLL 0
- PLL 1
- Generates clock gate controls for enabling and disabling most clocks
- Initializes and sequences clocks
- Allows software to program
clock characteristics, such as the following items discussed later in this chapter:
- Input clock source for the two PLLs
- Multiplier range, divider range, and 16 post-scale counters for each PLL
- VCO enable for each PLL
- Bypass modes for each PLL
- Gate of individual clocks in all PLL clock groups
- Clear loss of lock status for each PLL
- Boot mode for hardware-managed clocks
- General-purpose I/O (GPIO) debounce clock divide
- Allows software to observe the status of all writable registers
- Supports interrupting the MPU subsystem on PLL‑lock and loss‑of‑lock
- Supports clock gating at the signal level
The clock manager is not responsible for the following functional behaviors:
- Selection or management of the clocks for the FPGA-to-HPS and HPS-to-FPGA interfaces. The FPGA logic designer is responsible for selecting and managing these clocks.
- Software must not program the clock manager with illegal values. If it does, the behavior of the clock manager is undefined and could stop the operation of the HPS. The only guaranteed means for recovery from an illegal clock setting is a cold reset.
- When re-programming clock settings, there are no automatic glitch-free clock transitions. Software must follow a specific sequence to ensure glitch-free clock transitions. Refer to Hardware-Managed and Software-Managed Clocks section of this chapter.
3.2. Clock Manager Block Diagram and System Integration
Clock Name | Source/Destination | Description |
---|---|---|
mpu_free_clk | Clock manager To MPU complex | Source clock from clock manager for both MPU clock groups. |
mpu_clk | Internal to MPU complex | MPU main clock |
mpu_l2ram_clk | Internal to MPU complex and HMC switch in NOC. | MPU L2 RAM clock and HMC switch in NOC. Fixed at ½ mpu_clk. |
mpu_periph_clk | Internal to MPU complex | MPU peripherals clock for interrupts, timers, and watchdogs. Fixed at ¼ mpu_clk. |
l3_main_free_clk | Clock manager to NOC/Peripherals | Interconnect L3 main switch clock. Always free running. |
l4_sys_free_clk | Clock manager to NOC/Peripherals | Interconnect L4 system clock. Always free running. |
l4_main_clk | Clock manager to NOC/Peripherals | L4 Interconnect clock for fast peripherals including DMA, SPIM, SPIS and TCM. |
l4_mp_clk | Clock manager to NOC/Peripherals | Interconnect L4 peripheral clock. |
l4_sp_clk | Clock manager to NOC/Peripherals | Interconnect L4 slow peripheral clock. |
cs_at_clk | Clock manager to CoreSight* /NOC | CoreSight* Trace clock and debug time stamp clock. |
cs_pdbg_clk | Clock manager to CoreSight* | CoreSight* bus clock |
cs_trace_clk | Clock manager to CoreSight* |
CoreSight* Trace I/O clock. This is independent and defaults to a low frequency (25 MHz) for lower speed debuggers. Not required to be sync. to other clocks (but keep in clock group as hardware managed) |
cs_timer_clk | Clock manager to CoreSight* /NOC |
CoreSight* timer clock. Same as cs_at_clk with different software enable to ensure MPU clock running. Not required to be sync. to other clocks (but still hardware managed). |
fpga2soc_clk | FPGA fabric to NOC | FPGA to SoC interface clock from the FPGA. |
soc2fpga_clk | FPGA fabric to NOC | SoC to FPGA interface clock from the FPGA. |
lws2f_clk | FPGA fabric to NOC | LWHPS to FPGA interface clock from FPGA. |
hmc_free_clk | From HMC to HMC switch in NOC | HMC interface clock from HMC (Hard Memory Controller) in FPGA. |
f2h_sdram0_clk f2s_sdram1_clk f2h_sdram2_clk |
FPGA fabric to HMC switch in NOC | FPGA fabric SDRAM write interfaces clocks. |
f2h_pclkdbg | FPGA fabric to CoreSight* bridge | CoreSight* FPGA fabric APB* debug port clock |
usb[0,1]_ulpi_clk | I/O to USB | ULPI clock for PHY. |
3.2.1. L4 Peripheral Clocks
The L4 peripheral clocks, denoted by l4_mp_clk, range up to 200 MHz.
Peripheral | Clock Name | Description |
---|---|---|
USB OTG 0/16 | hclk | AHB* clock |
pmu_hclk | PMU
AHB*
clock. pmu_hclk is the scan clock for the PMU's
AHB*
domain. Note: Select it as a test clock.
|
|
utmi_clk | Always used as the PHY domain clock during
DFT Scan mode. Note: Select utmi_clk as a test clock even when the core is
configured for a non-UTMI PHY.
|
|
Quad SPI Flash Controller6 | pclk | APB* clock |
hclk | AHB* clock | |
NAND Flash Controller (Locally gated nand_mp_clk.)6 | ACLK | AHB* Data port clock |
mACLK | AXI* Master port clock | |
regACLK | AHB* Register port clock | |
ecc_clk | ECC circuitry clock | |
clk_x | Bus Interface Clock | |
EMAC 0/1/2 | aclk | Application clock for DMA AXI* bus and CSR APB* bus. |
SD/MMC Controller | sdmmc_clk | All registers reside in the BIU clock domain. |
For more information about the specific peripheral clocks, refer to their respective chapters.
3.2.2. Boot Clock
The Boot Clock (boot_clk) is used as the default clock for both cold or warm reset (Boot Mode), the Hardware Sequencer local clock and the external bypass clock reference.
The boot_clk is generated from the secure cb_intosc_hs_div2_clk or the unsecure external oscillator. boot_clk is only updated coming out of cold reset or a warm reset (boot mode request) and is not sampled at any other time.
The source of every output clock block comes from the following:
- Bypass source: boot_clock configured through fuses and security manager: registers at cold or warm reset
- Non-External Bypass: Each Clock may come from 1 of 5 sources:
Source | Description |
---|---|
OSC1 | Pin for external oscillator |
f2h_free_clk | FPGA fabric PLL clock reference |
cb_intosc_hs_div2_clk | FPGA CSS (Control Block) high speed internal oscillator divided by 2 (200 MHz maximum) |
PLL0 Counter Output | Main PLL counter outputs 0 to 8 |
PLL1 Counter Output | Peripheral PLL counter outputs 0 to 8 |
Clock Output Blocks have the following features:
- Each clock output block contains an external bypass multiplexer
- Some clock output blocks contain additional dividers
- Clock gates controlled by either hardware or software are used to disable the clocks
- The MPU and NOC (includes debug clocks) blocks contain enable outputs to define clock frequency ratios to the MPU, NOC and CoreSight logic
The CSR Register logic uses an independent clock, l4_sys_free_clk, to allow the clock to be changed by software.
3.2.2.1. Updating PLL Settings without a System Reset
Updating the PLL settings without a system reset will not reset the clock manager. All clocks will transition gracefully to their boot safe dividers. You can go in and out of boot mode and force the PLLs into bypass without doing a system reset. Software may reset the PLLs and reconfigure the VCO and bring it out of reset. By doing this you can safely update the PLL settings.
3.2.2.2. MPU Clock Scaling
You can dynamically slow down the MPU clock without touching the PLL by modifying the MPU external counter register (MAINPLLGRP.MPUCLK.CNT) to slow down the MPU frequency.
3.3. Functional Description of the Clock Manager
3.3.1. Clock Manager Building Blocks
3.3.1.1. PLLs
The two PLLs in the clock manager generate the majority of clocks in the HPS. There is no phase control between the clocks generated by the two PLLs.
Each PLL has the following features:
- Phase detector and output lock signal generation
- Registers to set VCO
frequency
- Multiplier range is 1 to 4096
- Divider range is 1 to 64
- 16 post-scale counters (C0-C8) with a range of 1 to 2048 to further subdivide the clock
- A PLL can be enabled to bypass all outputs to the input clock for glitch-free transitions
3.3.1.2. FREF, FVCO, and FOUT Equations
Values listed for M, N, and C are actually one greater than the values stored in the CSRs.
FREF = FIN / N FVCO = FREF × M = FIN × M/N FOUT = FVCO /Ci = FREF × M/Ci = (FIN × M)/ (N × Ci)
where:
- FVCO = VCO frequency
- FIN = input frequency
- FREF = reference frequency
- FOUT = output frequency
- M = numerator, part of the clock feedback path
- N = denominator, part of the input clock reference path
- Ci = post-scale counter, where i is 0-8
The Ci dividers are used to derive lower frequencies from the PLLs. The M and N dividers can be dynamically updated without losing the PLL lock if the VCO frequency changes less than 20%. If changes greater than 20% are needed, iteratively changing the frequency in increments of less than 20% allows a slow ramp of the VCO frequency without loss of clock.
To minimize jitter, use the following guidelines:
- The VCO should be as close to maximum as possible
- It is better to use the Ci dividers than the N divider. The N divider should be kept as small as possible.
- The M divider should be minimized, but should be greater than 32.
When making any changes that affect the VCO frequency, software must put the PLL into external bypass. After changing the VCO frequency, software must wait for the PLL lock, as indicated by the intrs register or enabled interrupt, before taking the PLL out of bypass.
As shown in the "Hardware Clock Groups" and "Peripheral Clocks" figures, every clock has five possible sources. When switching between clock sources:
- Put PLL into bypass mode
- Change the mux select
- Switch back out of
bypass mode Note: The new clock source must be active and locked before exiting bypass mode.
As shown in the "PLL Integration in Clock Manager" figure, each PLL has multiple input sources. If the input source is changed, the PLL loses VCO lock and all output clocks are not reliable. Before switching the PLL input source, software must select the boot_clk bypass for all PLL0 and PLL1 clocks. After the PLL output clocks are bypassed, software can change the PLL source and reinitialize the PLL.
Unused clock outputs should be set to a safe frequency such as 50 MHz to reduce power consumption and improve system stability.
3.3.1.3. Clock Gating
Clock gating enables and disables clock signals. Refer to the Peripheral PLL Group Enable Register (en) for more information on what clocks can be gated.
3.3.2. PLL Integration
The two PLLs contain exactly the same set of output clocks. PLL0 is intended to be used for the MPU and the NOC clocks. PLL1 is intended to be used as the 250 MHz Ethernet clock reference.
Output Counter | Clock Name | Frequency | Boot Frequency |
---|---|---|---|
C0 | mpu_base_clk | Up to varies | 10 MHz to 200 MHz |
C1 | noc_base_clk | Up to C0/3 | 10 MHz to 200 MHz |
C2 | emaca_clk | 50 to 250 MHz | 10 MHz to 200 MHz |
C3 | emacb_clk | 50 to 250 MHz | 10 MHz to 200 MHz |
C4 | emac_ptp_clk | Up to 100 MHz | 10 MHz to 200 MHz |
C5 | gpio_db_clk | Up to 200 MHz | 10 MHz to 200 MHz |
C6 | sdmmc_clk | Up to 200 MHz | 10 MHz to 200 MHz |
C7 | h2f_user0_clk | Up to 400 MHz | 10 MHz to 200 MHz |
C8 | h2f_user1_clk | Up to 400 MHz | 10 MHz to 200 MHz |
3.3.3. Hardware-Managed and Software-Managed Clocks
When changing values on clocks, the terms hardware-managed and software-managed define how clock transitions are implemented. When changing a software-managed clock, software is responsible for gating off the clock, waiting for a PLL lock if required, and gating the clock back on. Clocks that are hardware-managed are automatically transitioned by the hardware to ensure glitch-free operation.
- mpu_periph_clk
- mpu_l2_ram_clk
- mpu_clk
- l3_main_free_clk
- l4_sys_free_clk
- l4_sys_free_div4_clk
- l4_main_clk
- l4_mp_clk
- l4_sp_clk
- cs_timer_clk
- cs_at_clk
- cs_pdbg_clk
- cs_trace_clk
All other clocks in the HPS are software-managed clocks.
3.3.4. Hardware Sequenced Clock Groups
The hardware sequenced clock groups consists of the MPU clocks and the NOC clocks. The following diagram shows the external bypass muxes, hardware-managed external counters and dividers, and clock gates. For hardware-managed clocks, the group of clocks has only one software enable for the clock gate. As a result, the group of clocks are all enabled or disabled together. The slight exception is the NOC has two software enables, one for the l3/l4 clocks and one for the CoreSight clocks.
Clock Output Group | System Clock Name | Frequency | Boot Frequency | Uses |
---|---|---|---|---|
MPU | mpu_clk | PLL C0 | boot_clk | MPU subsystem, including CPU0 and CPU1 |
mpu_I2_ram_clk | mpu_clk/2 | boot_clk | MPU level 2 (L2) RAM | |
mpu_periph_clk | mpu_clk/4 | boot_clk | MPU snoop control unit (SCU) peripherals, such as the general interrupt controller (GIC) | |
NOC | l3_main_free_clk | PLL C1 | boot_clk | L3 interconnect |
l4_sys_free_clk | l3_main_free_clk/4 | boot_clk/2 | L4 interconnect | |
l4_sys_free_div4_clk | l4_sys_free_clk/4 | l4_sys_free_clk/4 | L4 interconnect timer reference | |
l4_main_clk | l3_main_free_clk/{1,2,4,8} | boot_clk | L4 main bus | |
l4_mp_clk | l3_main_free_clk/{1,2,4,8} | boot_clk | L4 MP bus | |
l4_sp_clk | l3_main_free_clk/{1,4,8} | boot_clk/2 | L4 SP bus | |
cs_timer_clk | l3_main_free_clk/{1,2,4,8} | boot_clk | Trace timestamp generator | |
cs_at_clk | l3_main_free_clk/{1,2,4,8} | boot_clk | CoreSight debug trace bus | |
cs_pdbg_clk | cs_at_clk/{1,4} | cs_at_clk/2 | Debug Access Port (DAP) and debug peripheral bus | |
cs_trace_clk | cs_at_clk/{1,2,8} | cs_at_clk/4 | Coresight debug Trace Port Interface Unit (TPIU) | |
Main FPGA Reference | h2f_user0_clk | h2f_user0_free_clk | boot_clk | FPGA |
3.3.5. Software Sequenced Clocks
The software sequenced clock groups include additional clocks for peripherals not covered by the NOC clocks. The main purpose is to have a second PLL for the Ethernet 250 MHz clock reference. The following diagram shows the external bypass muxes, hardware-managed external counters and dividers, and clock gates.
There are 3 EMAC cores that have a very strict requirement of either a 250 MHz or 50 MHz clock reference. If the PLL0 frequency is a multiple of 250 MHz (for example 1.5 GHz), driving the EMAC clocks from PLL0 provides PLL1 with more flexibility in VCO clock frequency. In addition, to minimize the PLL clock outputs required, emac_clka can be 250 MHz and emac_clkb can be 50 MHz, allowing each EMAC core to be software configured to select 250 MHz or 50 MHz.
System Clock Name | Frequency | Boot Frequency | Descriptions |
---|---|---|---|
emac{0,1,2}_clk | PLL C2 or PLL C3 | boot_clk | Clock for EMAC. Fixed at 250 MHz or 250 MHz emac_clk and 50 MHz emacb_clk |
emac_ptp_clk | PLL C4 | boot_clk | Clock for EMAC PTP timestamp clock |
gpio_db_clk | 125 Hz to PLL C5 | boot_clk | Clock for GPIO debounce clock |
sdmmc_clk | PLL C6 | boot_clk | Clock for SDMMC |
h2f_user0_clk | PLL C7 | boot_clk | Clock reference for FPGA |
h2f_user1_clk | PLL C8 | boot_clk | Clock reference for FPGA |
3.3.6. Resets
Power-On-Reset (POR) Reset
The security manager handles clocking during POR. Depending on the status of one of the security fuses, the device is initially clocked using either the secure cb_intosc_hs_div2_clk or the unsecure external oscillator.
Cold Reset
The reset manager brings the clock manager out of cold reset first in order to provide clocks to the rest of the blocks. After POR is de-asserted, clock manager enables boot_clk to the rest of the system before the module resets are de-asserted.
Warm Reset
During a Warm Rest, the clock manager module is not reset. The following steps are taken during a warm reset:
- Reset manager puts all modules affected by Warm Reset into reset. Reset manager issues a Boot Mode request to clock manager.
- Based on the status of the hps_clk_f fuse during POR, security manager indicates
if the boot clock should be secure.
- If secure clocks are enabled, boot_clk transitions gracefully to cb_intosc_hs_div2_clk.
- If secure clocks are not enabled, boot_clk transitions gracefully to the external oscillator input, HPS_CLK1.
Note: The security fuse is only sampled during cold reset and warm reset. The security fuse hps_clk_f allows the user to enable secure clocks. If clearing RAM on a Cold or Warm reset, the user should enable secure clocks (cb_intosc_hs_clk divide by 2). - The Clock
Manager gracefully transitions Hardware-Managed and Software Managed clocks
into Boot Mode as follows:
- Disable all output clocks including Hardware and Software-Managed clocks.
- Wait for all clocks to be
disabled, and do the following two things:
- Bypass all external Hardware and Software-Managed clocks.
- Update Hardware-Managed external counters/dividers to Boot Mode settings.
- Wait for all bypasses to switch, and then synchronously reset the CSR registers.
- Enable all clocks.
- After Hardware Managed Clocks have transitioned, the Clock Manager acknowledges the Reset Manager.
- Reset Manager continues with Warm Reset de-assertion sequence.
3.3.7. Security
The clock manager creates a boot clock as the clock reference for boot mode and external bypass. The clock configuration is based on security features in the security manager.
Security Input Clocks
The following table defines the boot clock sources.
Clock Name | Max | Min | Source/Dest | Description |
---|---|---|---|---|
HPS_CLK1 | 50 | 10 | Pin | External Oscillator Clock Reference. Non-secure clock reference. Named osc1_clk signal inside device. |
cb_intosc_hs_clk | 400 | 120 | FPGA Control Block |
Control Block high speed internal ring oscillator. This clock has wide variation across process/temperature. This clock is used as the secure reference for Boot Mode. Because the range/jitter of the clock is low quality, the clock is divided by 2. |
cb_intosc_ls_clk | 100 | 30 | FPGA Control Block |
Control Block low speed internal ring oscillator. This clock has wide variation across process/temperature. This clock is used by Security Manager as the Power on Reset Domain secure clock. This clock is also provided as an input to the Clock Manager PLLs. However, because of the low quality of the clock, it is not recommended to use this clock as the PLL reference. |
Boot Clock
The status of the hps_clk_f security fuse in the Security Manager determines if boot_clk should be secure:
- If set, then boot_clk is cb_intosc_hs_clk divided by 2.
- If clear, then boot_clk comes from the external oscillator input pin HPS_CLK1.
The above setting is reported by the security manager before the chip is brought out of cold reset. Also the security status may be updated by security option registers in the security manager.
3.3.8. Interrupts
The clock manager provides one interrupt output, which is enabled through the interrupt enable register (intren). The interrupt can be programmed to trigger twhen either the PLL achieves or loses its lock.
3.4. Clock Manager Address Map and Register Definitions
For complete HPS address map and register definitions, refer to the Intel Arria 10 HPS Register Address Map and Definitions.
4. Reset Manager
The reset manager generates module reset signals based on reset requests from the various sources in the HPS and FPGA fabric, and software writing to the module-reset control registers. The reset manager ensures that a reset request from the FPGA fabric can occur only after the FPGA portion of the system-on-a-chip (SoC) device is configured.
The HPS contains multiple reset domains. Each reset domain can be reset independently. A reset may be initiated externally, internally or through software.
The Reset domains and sequences include security features. The security manager works with Power On Reset (POR) and brings the reset manager out of reset only when the secure fuses have been loaded and validated. Once this process is complete, the reset manager brings the rest of the HPS out of reset.
Domain Name |
Domain Logic |
Module Master |
Description |
---|---|---|---|
POR |
Power on Reset. The entire HPS is reset. |
Security Manager |
After POR, the security manager comes out of reset and validates the security fuses. After validation, the reset manager is released from reset and proceeds to perform a cold reset on the HPS. |
System Cold |
Cold Reset. All of the HPS except security manager and POR fuse logic. |
Reset Manager |
Using the known security state, the HPS is placed in the default state, allowing software to boot. Cold reset is triggered by POR as well as other sources. |
System Warm |
System Warm (SW) is a warm reset. All of the HPS except security manager, POR, Fuse Logic, and test access port (TAP), and Debug domains are reset. |
Reset Manager |
Used to recover system from a non-responsive condition. Resets a subset of the HPS state reset by a cold reset. Only affects the system reset domain, which allows debugging (including trace) to operate through the warm reset. It is possible to mask a warm reset for some modules such that they are not affected. |
Debug |
All debug logic including most of the DAP, CoreSight* ™ components connected to the debug peripheral bus, trace, the microprocessor unit (MPU) subsystem, and the FPGA fabric. |
Reset Manager |
May be asserted by cold reset, the debugger or software. Used to recover debug logic from a non-responsive condition. |
TAP |
JTAG test access port (TAP) controller, which is used by the debug access port (DAP). |
Reset Manager |
Asserted by cold reset or by Software. |
RAM Clear |
The on-chip memories are cleared |
Reset Manager |
Memories may be cleared on cold or warm as indicated by the corresponding bits in the ramstat register. |
The HPS supports the following reset types:
- System cold reset
- Used to ensure the HPS is placed in a default state sufficient for software to boot
- Triggered by a power-on reset and other sources
- Resets all HPS logic that can be reset
- Affects all reset domains
- System
warm reset
- Used to recover system from a non-responsive condition
- Does not reset the Debug or TAP reset domain, allowing debug functions including trace to operate through out a warm reset
- Masks allow software to exclude
modules from warm reset. Exceptions for masks:
- To maintain security, there is no mask for security manager
- The MPU cannot be masked
- RAM Clearing domain (if not masked) logic is reset
- Debug reset
- Used to recover debug logic from a non-responsive condition
- Only affects the debug reset domain
- TAP
Reset
- JTAG TAP controller is reset
- Software may trigger TAP reset
4.1. Reset Manager Block Diagram and System Integration
The reset manager accepts reset requests from the security manager, FPGA control block, FPGA core, modules in the HPS, and reset pins and generates module reset signals. The reset manager receives security status from the security manager. The reset manager also has warm reset handshaking signals to support system reset behavior, clock manager interfaces, and the Anti-Tamper interface with security manager. The Boot clock (boot_clk) is used as the default clock for both cold or warm reset. When the device is configured to operate in secure mode, boot_clk is cb_intosc_hs_div2_clk. When the device is not in secure mode, boot_clk is sourced from the external oscillator input pin, HPS_CLK1.
The following figure shows a block diagram of the reset manager in the SoC device. For clarity, reset-related handshaking signals to other HPS modules and to the clock manager module are omitted.
4.1.1. Reset Controller
In secure mode, all signals are synchronous to boot_clk. In non-secure mode, all signals are synchronous to the clock signal osc1_clk which is sourced from the external oscillator input pin, HPS_CLK1. The following table lists the reset sources external to the HPS.
Source |
Description |
---|---|
f2h_cold_rst_req_n |
Cold reset request from FPGA fabric (active low) |
f2h_warm_rst_req_n |
Warm reset request from FPGA fabric (active low) |
f2h_dbg_rst_req_n |
Debug reset request from FPGA fabric (active low) |
load_csr_filt |
Cold-only reset from FPGA control block (CB) |
nPOR |
Power-on reset pin (active low) |
nRST |
Warm reset pin (active low) |
Source |
Description |
---|---|
h2f_cold_rst_n |
Cold-only reset to FPGA fabric (active low) |
h2f_rst_n |
Cold or warm reset to FPGA fabric (active low) |
h2f_dbg_rst_n |
Debug reset (dbg_rst_n) to FPGA fabric (active low) |
The reset controller performs the following functions:
- Accepts reset requests from the FPGA control block (CB), FPGA fabric, modules in the HPS, and reset pins
- Generates an individual reset signal for each module instance for all modules in the HPS
- Provides reset handshaking signals to support system reset behavior
The reset controller generates module reset signals from external reset requests and internal reset requests. External reset requests originate from sources external to the reset manager. Internal reset requests originate from control registers in the reset manager.
The reset controller supports the following cold reset requests:
- Security manager reset
- Cold reset request pin (nPOR)
- FPGA fabric
- FPGA CB
- Software cold reset request bit (swcoldrstreq) of the control register (ctrl)
The reset controller supports the following warm reset requests:
- Warm reset request pin (nRST)
- FPGA fabric
- Software warm reset request bit (swwarmrstreq) of the ctrl register
- MPU watchdog reset requests for CPU0 and CPU1
- System watchdog timer 0 and 1 reset requests
The reset controller supports the following debug reset requests:
- CDBGRSTREQ from DAP
- FPGA fabric
4.1.2. Security Reset Functions
When secure mode is enabled on the device, reset manager performs some additional functions. To avoid unsecure snooping of existing RAM contents, the HPS can be configured to clear all RAM, both general-purpose RAM and dedicated RAM that is integrated into modules. The list of RAMs on the HPS is:
- Onchip RAM
- USB0
- USB1
- SDMMC
- EMAC0 - EMAC2 RX and TX buffers
- DMA
- NAND Read, Write and ECC RAMs
- QSPI
- MPU RAM
RAMs can be cleared on cold reset, warm reset or both as there are separate fuses that control behavior for cold and warm resets. When the corresponding fuse is blown, all RAMs are cleared for the indicated reset type. If an additional fuse is blown, the various RAM contents are cleared sequentially; otherwise, the contents of all of the RAMs are cleared simultaneously. Even if all security RAM clearing is disabled, the reset manager always invalidates the MPU L1 Cache.
The HPS also supports an Anti-Tamper interface from the FPGA fabric to security manager. If an Anti-Tamper event occurs, the HPS clears all RAMs and becomes unresponsive. The HPS only recovers from this state by a POR. Anti-Tamper logic, such as voltage detection, may reside in the FPGA.
4.1.3. Module Reset Signals
The following tables list the module reset signals. The module reset signals are organized in groups for the MPU, peripherals, bridges.
In the following tables, columns marked for Cold Reset, Warm Reset, and Debug Reset denote reset signals asserted by each type of reset. For example, writing a 1 to the swwarmrstreq bit in the ctrl register resets all the modules that have a checkmark in the Warm Reset column.
The column marked for Software Deassert denotes reset signals that are left asserted by the reset manager.
Module Reset Signal |
Description |
Reset Domain |
Cold Reset |
Warm Reset |
Debug Reset |
Software Deassert |
---|---|---|---|---|---|---|
mpu_cpu_rst_n[0] | Resets each processor in the MPU | System | X | X | ||
mpu_cpu_rst_n[1] |
Resets each processor in the MPU |
System |
X | X | X | |
mpu_wd_rst_n |
Resets both per-processor watchdogs in the MPU |
System |
X | X | ||
mpu_scu_periph_rst_n |
Resets Snoop Control Unit (SCU) and peripherals |
System |
X | X |
Module Reset Signal |
Description |
Reset Domain |
Cold Reset |
Warm Reset |
Debug Reset |
Software Deassert |
---|---|---|---|---|---|---|
watchdog_rst_n[1:0] |
Resets corresponding system watchdog timer |
System |
X |
X |
X | |
l4sys_timer_rst_n[1:0] |
Resets corresponding OSC1 timer |
System |
X |
X |
X | |
sp_timer_rst_n[1:0] |
Resets corresponding SP timer |
System |
X |
X |
X | |
i2c_rst_n[4:0] |
Resets corresponding I2C controller |
System |
X |
X |
X | |
uart_rst_n[1:0] |
Resets corresponding UART |
System |
X |
X |
X | |
gpio_rst_n[2:0] |
Resets corresponding GPIO interface |
System |
X |
X |
X | |
dma_periph_if_rst_n[7:0] | DMA controller request interface from FPGA fabric to DMA controller | System |
X |
X |
X |
|
emac_ptp_rst_n [1:0] | Resets corresponding EMAC precision time protocol |
System |
X |
X |
||
emac_ecc_rst_n [2:0] | Resets corresponding to EMAC ECC |
System |
X |
X |
||
usb_ecc_rst_n [1:0] | Resets corresponding to USB ECC |
System |
X |
X |
||
nand_flash_ecc_rst_n | Resets corresponding to NAND Flash ECC |
System |
X |
X |
||
qspi_flash_ecc_rst_n | Resets corresponding to QSPI Flash ECC |
System |
X |
X |
||
sdmmc_ecc_rst_n | Resets corresponding to SDMMC ECC |
System |
X |
X |
Module Reset Signal |
Description |
Reset Domain |
Cold Reset |
Warm Reset |
Debug Reset |
Software Deassert |
---|---|---|---|---|---|---|
emac_rst_n[2:0] |
Resets corresponding EMAC |
System |
X |
X |
X | |
usb_rst_n[1:0] |
Resets corresponding USB |
System |
X |
X |
X | |
nand_flash_rst_n |
Resets NAND flash controller |
System |
X |
X |
X | |
qspi_flash_rst_n |
Resets quad SPI flash controller |
System |
X |
X |
X | |
spim_rst_n[1:0] |
Resets SPI master controller |
System |
X |
X |
X | |
spis_rst_n[1:0] |
Resets SPI slave controller |
System |
X |
X |
X | |
sdmmc_rst_n |
Resets SD/MMC controller |
System |
X |
X |
X | |
dma_rst_n |
Resets DMA controller |
System |
X |
X |
X | |
dma_ecc_rst_n |
Resets DMA ECC |
System |
X |
X |
Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|
hps2fpga_bridge_rst_n | Resets HPS-to-FPGA AMBA* Advanced eXtensible Interface ( AXI* ) bridge | System | X | X | X | |
fpga2hps_bridge_rst_n | Resets FPGA-to-HPS AXI* bridge | System | X | X | X | |
lwhps2fpga_bridge_rst_n | Resets lightweight HPS-to-FPGA AXI* bridge | System | X | X | X | |
f2h_sdram_bridge0_rst_n | Resets SDRAM bridge 0 | System | X | X | X | |
f2h_sdram_bridge1_rst_n | Resets SDRAM bridge 1 | System | X | X | X | |
f2h_sdram_bridge2_rst_n | Resets SDRAM bridge 2 | System | X | X | X | |
ddr_scheduler_rst_n | Resets DDR scheduler | System | X | X | X |
Group | Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|---|
SYSMOD | boot_rom_rst_n | Resets boot ROM | System | X | X | ||
onchip_ram_rst_nsy | Resets on-chip RAM | System | X | X | |||
sys_manager_rst_n | Resets system manager (resets logic associated with cold or warm reset) | System | X | ||||
fpga_manager_rst_n | Resets FPGA manager | System | X | X | |||
sys_dbg_rst_n | Resets debug masters and slaves connected to L3 interconnect and level 4 (L4) buses | System | X | X | |||
onchip_ram_ecc_rst_n | Onchip RAM ECC reset | System | X | X | |||
h2f_rst_n | System | X | X | ||||
sec_rst_n | Security reset | System | X | ||||
COLD | sys_manager_cold_rst_n | Resets system manager (resets logic associated with cold reset only) | System | X | |||
rst_pin_oe_rst | Pulls nRST pin low | System | X | X | |||
timestamp_cold_rst_n | Resets debug timestamp to 0x0 | System | X | ||||
clk_manager_cold_rst_n | Resets clock manager (resets logic associated with cold reset only) | System | X | ||||
tap_cold_rst_n | Resets portion of TAP controller in the DAP that must be reset on a cold reset | TAP | X | ||||
sec_cold_rst_n | Security cold reset | System | X | ||||
hmc_cold_rst_n | HMC cold reset | System | X | X | |||
io_manager_cold_rst_n | I/O manager cold reset | System | X | X | |||
DBUG | dbg_rst_n | Resets debug components including DAP, trace, MPU debug logic, and any user debug logic in the FPGA fabric | Debug | X | X | ||
L3 | l3_rst_n | Resets L3 Interconnect and L4 buses | System | X | X |
Module Reset Signal | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|
onchip_sec_ram_rst_n | X | X | X | ||
otg0_sec_ram_rst_n | X | X | |||
otg1_sec_ram_rst_n | X | X | |||
sdmmc_sec_ram_rst_n | X | X | |||
emac0rx_sec_ram_rst_n | X | X | |||
emac0tx_sec_ram_rst_n | X | X | |||
emac1rx_sec_ram_rst_n | X | X | |||
emac1tx_sec_ram_rst_n | X | X | |||
emac2rx_sec_ram_rst_n | X | X | |||
emac2tx_sec_ram_rst_n | X | X | |||
dma_sec_ram_rst_n | X | X | |||
nandw_sec_ram_rst_n | X | X | |||
nandr_sec_ram_rst_n | X | X | |||
nande_sec_ram_rst_n | X | X | |||
qspi_sec_ram_rst_n | X | X | |||
mwp_sec_ram_rst_n | X | X |
Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|
misc | Resets L3 interconnect and L4 buses | System | X | X |
4.1.3.1. Modules Requiring Software Deassert
When a module that has been held in reset is ready to start running, software can deassert the reset signal by writing to the appropriate register, shown in the following table.
HPS Peripheral | Reset Register | Module Reset Signal | Reset Group |
---|---|---|---|
MPU | mpumodrst | mpu_cpu_rst_n[1] | MPU |
Watchdog | per1modrst | watchdog_rst_n[1:0] | PER1 |
Timer | per1modrst | l4sys_timer_rst_n[1:0] | PER1 |
Timer | per1modrst | sp_timer_rst_n[1:0] | PER1 |
I2C | per1modrst | i2c_rst_n[4:0] | PER1 |
UART | per1modrst | uart_rst_n[1:0] | PER1 |
GPIO | per1modrst | gpio_rst_n[2:0] | PER1 |
DMA | per1modrst | dma_periph_if_rst_n[7:0] | PER1 |
Ethernet MAC | per0modrst | emac_rst_n[2:0] | PER0 |
USB 2.0 OTG | per0modrst | usb_rst_n[1:0] | PER0 |
NAND | per0modrst | nand_flash_rst_n | PER0 |
Quad SPI | per0modrst | qspi_flash_rst_n | PER0 |
SPI Master | per0modrst | spim_rst_n[1:0] | PER0 |
SPI Slave | per0modrst | spis_rst_n[1:0] | PER0 |
SD/MMC | per0modrst | sdmmc_rst_n | PER0 |
DMA | per0modrst | dma_rst_n | PER0 |
HPS-to-FPGA Bridge | brgmodrst | hps2fpga_bridge_rst_n | Bridge |
FPGA-to-HPS Bridge | brgmodrst | fpga2hps_bridge_rst_n | Bridge |
Lightweight HPS-to-FPGA Bridge | brgmodrst | lwhps2fpga_bridge_rst_n | Bridge |
FPGA-to-SDRAM port 0 | brgmodrst | f2s_sdram_bridge0_rst_n | Bridge |
FPGA-to-SDRAM port 1 | brgmodrst | f2s_sdram_bridge1_rst_n | Bridge |
FPGA-to-SDRAM port 2 | brgmodrst | f2s_sdram_bridge2_rst_n | Bridge |
SDRAM Scheduler | brgmodrst | ddr_scheduler_rst_n | Bridge |
4.1.4. Slave Interface and Status Register
The reset manager slave interface is used to control and monitor the reset states.
The status register (stat) in the reset manager contains the status of the reset requester. The register contains a bit for each monitored reset request. The stat register captures all reset requests that have occurred. Software is responsible for clearing the bits.
During the boot process, the Boot ROM copies the stat register value into memory before clearing it. After booting, you can read the value of the reset status register at memory address (r0 + 0x0038). For more information, refer to the "HPS State on Entry to the Second-Stage Boot Loader" section of the Booting and Configuration appendix.
4.2. Functional Description of the Reset Manager
The reset manager generates reset signals to modules in the HPS and to the FPGA fabric. The following actions generate reset signals:
- Software writing a 1 to the swcoldrstreq or swwarmrstreq bits in the ctrl register. Writing either bit causes the reset controller to perform a reset sequence.
- Software writing to the mpumodrst, per0modrst, per1modrst, brgmodrst, sysmodrst, coldmodrst, nrstmodrst or dbgmodrst module reset control registers.
- Asserting reset request signals triggers the reset controller. All external reset requests cause the reset controller to perform a reset sequence.
Multiple reset requests can be driven to the reset manager at the same time. Cold reset requests take priority over warm and debug reset requests. Higher priority reset requests preempt lower priority reset requests. There is no priority difference among reset requests within the same domain.
If a cold reset request is issued while another cold reset is already underway, the reset manager extends the reset period for all the module reset outputs until all cold reset requests are removed. If a cold reset request is issued while the reset manager is removing other modules out of the reset state, the reset manager returns those modules back to the reset state.
If a warm reset request is issued while another warm reset is already underway, the first warm reset completes before the second warm reset begins. If the second warm reset request is removed before the first warm reset completes, the warm first reset is extended to meet the timing requirements of the second warm reset request.
The nPOR pin can be used to extend the cold reset beyond what the POR voltage monitor automatically provides. The use of the nPOR pin is optional and can be tied high when it is not required.
The nRST pin can be used to extend a warm reset. The nRST pin is tri-stated, and the Reset Manager stretches a warm reset by the count programed in the CSR (RSTMGR.COUNTS.NRSTCNT) [doc however you usually do registers and bits] After the count has elapsed, 256 additional clocks cycles elapse before the nRST input is sampled again.
The reset manager contains the stat register that indicates which reset source caused a reset as well as the ramstat register that indicates which RAM modules were cleared during the last reset. After a cold reset is complete, all bits are cleared except for the bit(s) that indicate the source of the cold reset. If multiple cold reset requests overlap with each other, the bit corresponding to the source that de-asserts its request last is set. If more than one source is de-asserted in the same cycle, the value of the bit corresponding to each source is set.
After a warm reset is complete, the bit(s) that indicate the source of the warm reset are set to 1. A warm reset doesn't clear any bits in the stat register, so bits corresponding to any reset source that has caused a warm reset since the last cold reset or since the bits were last cleared are set. Any bit can be manually cleared by writing a 1 to it.
If RAM memory is cleared during a Cold or Warm reset, then the ramstat register indicates which RAMs during the reset. Bits are cleared manually by writing a 1.
The hard memory controller (HMC) in the FPGA is reset by the reset manager using a GPIO. The HMC is reset only through software; resetting the HMC is not part of the operation of any reset sources.
4.2.1. Reset Sequencing
The reset controller sequences resets without software assistance. Module reset signals are asserted asynchronously and synchronously. The reset manager deasserts the module reset signals synchronous to the boot_clk clock. Module reset signals are deasserted in groups in a fixed sequence. All module reset signals in a group are deasserted at the same time.
The reset manager sends a request to the clock manager to put the clocks in boot mode, which creates a fixed and known relationship between the boot_clk clock and all other clocks generated by the clock manager.
After the reset manager releases the MPU subsystem from reset, CPU1 is left in reset and CPU0 begins executing code from the reset vector address. Software is responsible for deasserting CPU1 and other resets, as shown in MPU Group, Generated Module Resets Table. Software deasserts resets by writing the mpumodrst, per0modrst, per1modrst, brgmodrst, sysmodrst, coldmodrst, nrstmodrst, and dbgmodrst module-reset control registers.
Software can also bypass the reset controller and generate reset signals directly through the module-reset control registers. In this case, software is responsible for asserting module reset signals, driving them for the appropriate duration, and deasserting them in the correct order. The clock manager is not typically in boot mode during this time, so software is responsible for knowing the relationship between the clocks generated by the clock manager. Software must not assert a module reset signal that would prevent software from deasserting the module reset signal. For example, software should not assert the module reset to the processor executing the software.
Reset Type |
Value |
---|---|
Warm Reset |
200 ns |
Cold Reset |
6 osc1_clk cycles |
The cold and warm reset sequences consist of different reset assertion sequences and the same deassertion sequence. The following sections describe the sequences.
4.2.1.1. Cold Reset Assertion Sequence
The following list describes the assertion steps for cold reset shown in the Cold Reset timing diagram:
- Assert all module resets.
- Wait for level cold reset requests to de-assert
- Wait for 32 cycles, de-asserts clock manager cold reset
- Wait the nRST count (default is 2048). De-assert NRST Output Enable.
-
Wait 256 clocks to allow the nRST pin to stabilize. Start sampling nRST input pin.
-
Wait for level warm reset requests to all de-assert.
- Go to de-assertion sequence.
4.2.1.2. Warm Reset Assertion Sequence
The following list describes the assertion steps for warm reset shown in the Warm Reset Timing Diagram:
- Reset manager performs optional handshake configured by SW with debug ETR. Wait for acknowledge.
- Reset manager performs optional handshake configured by SW handshake with FPGA core. Wait for acknowledge.
- Reset manager performs optional handshakes configured by SW with SDRAM and FPGA manager. Wait for acknowledges.
- Reset manager asserts module resets except for MPU watchdogs if the watchdogs were the source of the warm reset.
- Wait for 8 cycles, then reset manger sends rm_cm_boot_mode_req to clock manager. Wait until the Clock Manager acknowledges.
- Start nRST count if non-zero and a fixed counter to 128 (COUNTS.WARMRSCYCLES).
- If nRST count non-zero, start 256 stretch counter after nRST count is done to allow the nRST pin to stabilize. After 256 clocks, sample input pin nRST.
- Wait for level warm reset requests to de-assert, the nRST count to be zero and the fixed 128 count to be zero.
- Go to de-assertion sequence.
4.2.1.3. Cold and Warm Reset Deassertion Sequence
The following list describes the deassertion steps for both cold and warm reset shown in the Cold Reset Timing Diagram and Warm Reset Timing Diagram:
- De-assert all RAM CLEAR resets. Reset Manager Initiates Clock Manager MPU clocks stop request.
- Clock manager stops the MPU clocks and then waits 16 MPU clocks.
- Clock manager asserts Clock stop acknowledge to Reset Manager.
- Reset manager sees acknowledge and de-asserts L2 (mpu_l2_rst_n) reset only. Reset Manager de-asserts MPU stop request.
- Clock manger sees request de-asserted. Wait 16 MPU clocks. Start MPU clocks, and Clock Manager de-asserts Clock stop acknowledge.
- Reset manager sees de-assertion of acknowledge. Wait 16 cycles.
- Reset manager asserts CPU0/1 CLKOFF signals and waits 32 cycles.
- Reset manager de-asserts CPU0, CPU1, and SCU MPU resets (not WD). Wait 32 additional cycles.
- De-assert CPU0/1 CLKOFF signals. Wait 16 cycles
- Reset manager checks the Security fuse setting, and if the appropriate cold or warm reset fuse is set, do full RAM clearing sequence. Otherwise, clear only the MPU L1 RAM.
- Wait for Security RAM Sequence to complete.
- Assert again the CPU0, CPU1 and SCU MPU resets. Wait 16 cycles.
- De-assert L3 reset, and if Cold Reset, de-assert DBG and COLD groups of resets. Wait for 100 cycles
- De-assert SYS group module resets. Wait for 200 cycles.
- Reset manager Initiates Clock Manager MPU clocks stop request.
- Clock manager stops the MPU clocks and then waits 16 MPU clocks.
- Clock manager asserts Clock stop acknowledge to Reset Manager.
- Reset manager sees acknowledge and de-asserts L2 (mpu_l2_rst_n) reset only. Reset Manager de-asserts MPU stop request.
- Clock manger sees request de-asserted. Wait 16 MPU clocks. Start MPU clocks, and Clock Manager de-asserts Clock stop acknowledge.
- Reset manager sees de-assertion of acknowledge. Wait 16 cycles.
- Reset manager asserts CPU0 CLKOFF signal(s) and waits 32 cycles.
- Reset manager de-asserts remaining CPU0, SCU, and WD resets (no CPU1). Wait 32 additional cycles.
- De-assert CPU0 CLKOFF signal(s). De-assertion sequence is finished.
- Now SW should start running. SW to de-assert FPER/PER/SPER/BRIDGE/MPU2 resets.
4.2.2. Reset Pins
The test reset (nTRST), test mode select (TMS), and test clock (TCK) pins are associated with the TAP reset domain and are used to reset the TAP controller in the DAP. These pins are not connected to the reset manager.
The nPOR and nRST pins are used to request cold and warm resets respectively. The nRST pin is an output as well. Any warm reset request causes the reset manager to drive the rst_pin_oe_rst output enable high, which drives the nRST pin low. The amount of time the reset manager pulls nRST low is controlled by the nRST pin count field (nrstcnt) of the reset cycles count register (counts); the default is 2048 clocks. This technique can be used to reset external devices (such as external memories) connected to the HPS.
4.2.3. Reset Effects
The following list describes how reset affects HPS logic:
- In the security manager domain, some status bits are cleared differently for cold and warm reset.
- The TAP reset domain ignores warm reset
- The Debug reset domain ignores warm reset
- The Clock Manager module is reset only by cold reset. After warm reset, the Clock Manager is put into Boot Mode.
- Each peripheral module and System Manager define reset behavior differently. See the appropriate control register for details.
- In the MPU module, the Watchdog Reset Status Registers are reset if an MPU Watchdog triggered the warm reset
- The Pin MUX is reset only by cold reset.
4.2.4. Reset Handshaking
The reset manager participates in several reset handshaking protocols to ensure other modules are safely reset.
Before issuing a warm reset, the reset manager performs a handshake with several modules to allow them to prepare for a warm reset. The handshake logic ensures the following conditions:
- Optionally the ETR master has no pending master transactions to the L3 interconnect
- Optionally preserve SDRAM contents during warm reset by issuing self-refresh mode request
- FPGA manager stops generating configuration clock
- Warns the FPGA fabric of the forthcoming warm reset
Similarly, the handshake logic associated with ETR also occurs during the debug reset to ensure that the ETR master has no pending master transactions to the L3 interconnect before the debug reset is issued. This action ensures that when ETR undergoes a debug reset, the reset has no adverse effects on the system domain portion of the ETR.
4.3. Reset Manager Address Map and Register Definitions
For complete HPS address map and register definitions, refer to the Intel Arria 10 HPS Register Address Map and Definitions.
5. FPGA Manager
The FPGA manager in the hard processor system (HPS) manages and monitors the FPGA portion of the system on a chip (SoC) device. The FPGA manager can configure the FPGA fabric from the HPS, monitor the state of the FPGA, and drive or sample signals to or from the FPGA fabric.
5.1. Features of the FPGA Manager
The FPGA manager provides the following functionality and features:
- Full configuration and partial reconfiguration
- CRC error message extraction
- General purpose I/O signals to the FPGA
- Boot from FPGA control
- Generation of interrupts based on FPGA status changes
5.2. FPGA Manager Block Diagram and System Integration
The FPGA Manager consists of the following blocks:
- Configuration Data Interface - Accepts and transfers the configuration and decryption data to the FPGA configuration sub system (CSS)
- Register Slave Interface - Accesses the control and status registers in the FPGA Manager
- CSS Control - Controls full and partial configuration of the FPGA
- CSS Monitor - Monitors the status of the FPGA during a full or partial configuration of the device
- Error Message Register (EMR) Interface - Error message extraction, in case of CRC errors in the FPGA
- General Purpose I/O Interface - Receives and drives 32 bits of general purpose I/O to and from the FPGA
- Miscellaneous Core Input Interface - Receives control input signals from the FPGA to support booting the HPS from the FPGA
5.3. Functional Description of the FPGA Manager
5.3.1. FPGA Configuration
You can configure the FPGA using an external device or through the HPS. This section highlights configuring the FPGA through the HPS.
The FPGA manager connects to the configuration logic in the FPGA portion of the device using a mode similar to how external logic (for example, MAX II or an intelligent host) configures the FPGA in fast passive parallel (FPP) mode. FPGA configuration through the HPS supports all the capabilities of FPP mode, including the following items:
- FPGA configuration
- Partial FPGA reconfiguration
- Decompression
- Advanced Encryption Standard (AES) encryption
Configuration Scheme | VCCPGM(V) | Power-On Reset (POR) Delay | Valid MSEL[2:0] |
---|---|---|---|
FPP (x16 and x32) | 1.8 | Fast | 000 |
Standard | 001 |
The FPGA Manager can be configured to accept configuration data directly from the MPU or the DMA engine. Either the processor or the DMA engine moves data from memory to the FPGA Manager data image register space img_data_w.
Configuration data is buffered in a 64 deep x 32 bits wide FIFO in the FPGA Manager. Status information such as FIFO empty/full and remaining depth can be accessed through a status register imgcfg_stat. FIFO empty/full conditions can also be enabled to generate an interrupt.
If using the DMA engine to move FPGA configuration data to the FPGA Manager, a FIFO threshold value can be set in the dma_config register. This value is used to control the assertion of a DMA transfer request from the FPGA Manager to the DMA engine.
Before sending FPGA configuration data to the FPGA Manager HPS, software sets the clock-to-data ratio field (CDRATIO) and configuration data width bit (CFGWIDTH) in the image control 2 register (imgcfg_ctrl_02).
5.3.2. FPGA Status
Configuration signals from the FPGA CSS such as INIT_DONE, CRC_ERROR and PR_DONE are monitored by the FPGA Manager. Software configures the monitor block through the register slave interface, and can either poll FPGA signals or be interrupted. Monitored signals can be read through the imgcfg_stat register as well as the intr_masked_status register. Each of the monitored signals can generate an interrupt to the MPU global interrupt controller. Each interrupt source can be enabled and the polarity of the signals generating the interrupt can also be selected through the intr_mask and intr_polarity registers in the FPGA Manager.
5.3.3. Error Message Extraction
Cyclic redundancy check (CRC) errors from the FPGA fabric are monitored by the FPGA Manager. Upon assertion of a CRC error signal from the FPGA, the FPGA Manager extracts information about the error including:
- Error syndrome
- Error location
- Error type
A CRC error interrupt from the FPGA manager can be enabled through software. Software can then extract the CRC error information from the error message register (EMR) data interface. The number of valid error information bits in the EMR data registers depends on the specific FPGA device.
5.3.4. Data AES Decryption
The configuration data interface can also be used to transmit data from the HPS to the FPGA CSS Advanced Encryption Standard (AES) decryption engine. Software should sample the status registers in FPGA manager before switching modes between FPGA configuration and AES decryption. The FPGA manager does not do anything specific to handle a situation where software starts an AES decryption while in the middle of an FPGA configuration initiated by HPS, and the end result in this case is undefined.
5.3.5. Boot Handshake
There are two input signals from the FPGA to control HPS boot from the FPGA. Both are synchronized within the FPGA Manager. Boot software reads these signals before accessing a boot image in the FPGA. The following table describes the functionality of these signals.
Signal | Description |
---|---|
f2h_boot_from_fpga_on_failure |
Indicates whether a fallback second-stage boot loader image is available in the FPGA on-chip RAM at memory location 0x0. The fallback second-stage boot loader image is used only if the HPS boot ROM does not find a valid second-stage boot loader image in the selected flash memory device. |
f2h_boot_from_fpga_ready |
The f2h_boot_from_fpga_ready signal is used by the Boot ROM when accessing the public key stored in the FPGA. The Boot ROM only uses the signal if asserted to boot with the public key. Indicates a second-stage boot loader image is available in an FPGA on-chip RAM at memory location 0x0 and it is ready to be accessed. |
5.3.6. General Purpose I/O
Thirty-two general purpose inputs and thirty-two general purpose outputs are provided to the FPGA and are controlled through registers in the FPGA Manager.
No interrupts are generated through the input pins. All inputs are synchronized within the FPGA Manager. Output signals should be synchronized in the FPGA.
5.3.7. Clock
The FPGA manager has two clock input signals which are asynchronous to each other. The clock manager generates these two clocks:
- cfg_clk—the configuration slave interface clock input and also the DCLK output reference for FPGA configuration. Enable this clock in the clock manager only when configuration is active or when the configuration slave interface needs to respond to master requests.
- l4_mp_clk—the register slave interface clock.
5.3.8. Reset
5.4. FPGA Manager Address Map and Register Definitions
For complete HPS address map and register definitions, refer to the Intel Arria 10 HPS Register Address Map and Definitions.
6. System Manager
The system manager in the hard processor system (HPS) contains memory-mapped control and status registers (CSRs) and logic to control system level functions as well as other modules in the HPS.
The system manager connects to the following modules in the HPS:
- Direct memory access (DMA) controller
- Ethernet media access controllers (EMAC0, EMAC1, and EMAC2)
- Error Checking and Correction Controller (ECC) for RAMs
- Microprocessor unit (MPU) subsystem
- NAND flash controller
- Secure Digital/MultiMediaCard (SD/MMC) controller
- Quad serial peripheral interface (SPI) flash controller
- USB 2.0 On-The-Go (OTG) controllers (USB0 and USB1)
- Watchdog timers
6.1. Features of the System Manager
Software accesses the CSRs in the system manager to control and monitor various functions in other HPS modules that require external control signals. The system manager connects to these modules to perform the following functions:
- Sends pause signals to pause the watchdog timers when the processors in the MPU subsystem are in debug mode
- Selects the EMAC system interconnect master access options and other EMAC clock and interface options.
- Selects the SD/MMC controller clock options and system interconnect master access options.
- Selects the NAND flash controller bootstrap options and system interconnect master access option.
- Selects USB controller system interconnect master access option.
- Provides control over the DMA security settings when the HPS exits from reset.
- Provides boot source information that can be read during the boot process.
- Provides the capability to enable or disable an interface to the FPGA.
- Provides combined ECC status and interrupts from other HPS modules with ECC-protected RAM.
- Routes parity failure interrupts from the L1 caches to the Global Interrupt Controller.
- Provides the capability to inject errors during testing in the MPU L2 ECC-protected RAM.
6.2. System Manager Block Diagram and System Integration
The system manager connects to the level 4 (L4) bus through a slave interface. The CSRs connect to signals in the FPGA and other HPS modules.
The system manager consists of the following:
- CSRs—Provide memory-mapped
access to control signals and status for the following HPS modules:
- EMACs
- Debug core
- SD/MMC controller
- NAND controller
- USB controllers
- DMA controller
- System interconnect
- ECC memory
interfaces
for the following peripherals:
- USB controllers
- SD/MMC controller
- Ethernet MACs
- DMA controller
- NAND flash controller
- On-chip RAM
- Slave port interface—provides access to system manager CSRs for connected masters.
- Watchdog debug pause—accepts the debug mode status from the MPU subsystem and pauses the L4 watchdog timers.
- Reset Manager— system manager receives the reset signals from reset manager.
6.3. Functional Description of the System Manager
The system manager serves the following purposes:
- Provides software access to boot configuration and system information
- Provides software access to control and status signals in other HPS modules
- Provides combined ECC status and interrupt from other HPS modules with ECC-protected RAM
- Enables and disables HPS peripheral interfaces to the FPGA
- Provides eight registers that software can use to pass information between boot stages
6.3.1. Boot Configuration and System Information
The system manager provides boot configuration information through the bootinfo register. Sampled value of the HPS boot select (BSEL) pins are available to the Boot ROM software.
The boot source is determined by a combination of the BSEL pins and a fuse bit that can bypass the BSELpins.
6.3.2. Additional Module Control
Each module in the HPS has its own CSRs, providing access to the internal state of the module. The system manager provides registers for additional module control and monitoring. To fully control each module, you must program both the peripheral's CSR and its corresponding CSR in the System Manager. This section describes how to configure the system manager CS for each module.
6.3.2.1. DMA Controller
The security state of the DMA controller is controlled by the manager thread security (mgr_ns) and interrupt security (irq_ns) bits of the DMA register.
The periph_ns register bits determine if a peripheral request interface is secure or non-secure.
6.3.2.2. NAND Flash Controller
The bootstrap control register (nand_bootstrap) modifies the default behavior of the NAND flash controller after reset. The NAND flash controller samples the bootstrap control register bits when it comes out of reset.
The following nand_bootstrap register bits control configuration of the NAND flash controller:
- Bootstrap inhibit initialization bit (noinit)—inhibits the NAND flash controller from initializing when coming out of reset, and allows software to program all registers pertaining to device parameters such as page size and width.
- Bootstrap 512-byte device bit (page512)—informs the NAND flash controller that a NAND flash device with a 512-byte page size is connected to the system.
- Bootstrap inhibit load block 0 page 0 bit (noloadb0p0)—inhibits the NAND flash controller from loading page 0 of block 0 of the NAND flash device during the initialization procedure.
- Bootstrap two row address cycles bit (tworowaddr)—informs the NAND flash controller that only two row address cycles are required instead of the default three row address cycles.
You can use the system manager's nanad_l3master register to control the following signals:
- ARPROT
- AWPROT
- ARDOMAIN
- AWDOMAIN
- ARCACHE
- AWCACHE
These bits define the cache attributes for the master transactions of the DMA engine in the NAND controller.
6.3.2.3. EMAC
You can program the emac_global register to select either emac_ptp_clk from the Clock Manager or f2s_ptp_ref_clk from the FPGA fabric as the source of the IEEE 1588 reference clock for each EMAC.
You can use the system manager's l3master register to control the EMAC's ARCACHE and AWCACHE signals, by setting or clearing the (arcache, awcache) bits. These bits define the cache attributes for the master transactions of the DMA engine in the EMAC controllers.
Register bits must be accessed only when the master interface is guaranteed to be in an inactive state.
The phy_intf_sel bit is programmed to select between a GMII (MII), RGMII or RMII PHY interface when the peripheral is released from reset. The ptp_ref_sel bit selects if the timestamp reference is internally or externally generated. The ptp_ref_sel bit must be set to the correct value before the EMAC core is pulled out of reset.
6.3.2.4. USB 2.0 OTG Controller
The usb*_l3master registers in the system manager control the HPROT and HAUSER fields of the USB master port of the USB 2.0 OTG Controller.
6.3.2.5. SD/MMC Controller
The sdmmc_l3master register in the system manager controls the HPROT and HAUSER fields of the SD/MMC master port.
You can program software to select the clock’s phase shift for cclk_in_drv and cclk_in_sample by setting the drive clock phase shift select (drvsel) and sample clock phase shift select (smplsel) bits of the sdmmc register in the system manager.
6.3.2.6. Watchdog Timer
The system manager controls the watchdog timer behavior when the CPUs are in debug mode. The system manager sends a pause signal to the watchdog timers depending on the setting of the debug mode bits of the L4 watchdog debug register (wddbg). Each watchdog timer built into the MPU subsystem is paused when its associated CPU enters debug mode.
6.3.3. Boot ROM Code
Registers in the system manager control whether the boot ROM code configures the pin multiplexing for boot pins after a warm reset. Set the warm-reset-configure-pin-multiplex for boot pins bit (warmrstcfgpinmux) of the boot ROM code register to enable or disable this control.
Registers in the system manager also control whether the boot ROM code configures the I/O pins used during the boot process after a warm reset. Set the warm reset configure I/Os for boot pins bit (warmrstcfgio) of the ctrl register to enable or disable this control.
There can be up to four preloader images stored in flash memory. The (initswlastld) register contains the index of the preloader's last image that is loaded in the on‑chip RAM.
The boot ROM software state register (bootromswstate) is a 32-bit general‑purpose register reserved for the boot ROM.
The following warmram related registers are used to configure the warm reset from on-chip RAM feature and must be written by software prior to the warm reset occurring.
Register |
Name |
Purpose |
---|---|---|
enable |
Enable |
Controls whether the boot ROM attempts to boot from the contents of the on-chip RAM on a warm reset. |
datastart |
Data start |
Contains the byte offset of the warm boot CRC validation region in the on-chip RAM. The offset must be word-aligned to an integer multiple of four. |
length |
Length |
Contains the length in bytes of the region in the on-chip RAM available for warm boot CRC validation. |
execution |
Execution address |
Contains the global address the boot code jumps to in the on-chip RAM if the CRC validation succeeds. |
crc |
Expected CRC |
Contains the expected CRC of the region in the on-chip RAM. |
The number of wait states applied to the boot ROM's read operation is determined by the wait state bit (waitstate) of the ctrl register. After the boot process, software might require reading the code in the boot ROM. If software has changed the clock frequency of the l3_main_clk after reset, an additional wait state is necessary to access the boot ROM. Set the waitstate bit to add an additional wait state to the read access of the boot ROM. The enable safe mode warm reset update bit controls whether the wait state bit is updated during a warm reset.
6.3.3.1. Controlling the Boot Memory Map Through the System Interconnect
The System Manager contains a register, noc_addr_remap_value, that controls how the system interconnect maps memory addresses starting at 0x00000000. This register remaps the bottom of the memory map to either boot ROM or on-chip RAM.
Refer to "Address Remapping" in the System Interconnect chapter for details about using the noc_addr_remap_value register.
6.3.4. FPGA Interface Enables
The system manager can enable or disable interfaces between the FPGA and HPS.
The global interface bit (intf) of the global disable register (gbl) disables all interfaces between the FPGA and HPS.
You can program the individual disable register (indiv) to disable the following interfaces between the FPGA and HPS:
You can program the FPGA interface enable registers (fpgaintf_en_*) to disable the following interfaces between the FPGA and HPS:
- Reset request interface
- JTAG enable interface
- I/O configuration interface
- Boundary scan interface
- Debug interface
- Trace interface
- System Trace Macrocell (STM) interface
- Cross-trigger interface (CTI)
- QSPI interface
- SD/MMC interface
- SPI Master interface
- SPI Slave interface
- EMAC interface
- UART interface
6.3.5. ECC and Parity Control
The system manager can mask the ECC interrupts from each of the following HPS modules with ECC-protected RAM:
- MPU L2 cache data RAM
- On-chip RAM
- USB 2.0 OTG controller (USB0 and USB1) RAM
- EMAC (EMAC0, EMAC1, and EMAC2) RAM
- DMA controller RAM
- NAND flash controller RAM
- Quad SPI flash controller RAM
- SD/MMC controller RAM
- DDR interfaces
The system manager can inject single-bit or double-bit errors into the MPU L2 ECC memories for testing purposes. Set the bits in the appropriate memory enable register to inject errors. For example, to inject a single bit ECC error, set the injs bit of the mpu_ctrl_l2_eccregister.
The system manager can also inject parity failures into the parity-protected RAM in the MPU L1 to test the parity failure interrupt handler. Set the bits of the parity fail injection register (parityinj) to inject parity failures.
6.3.6. Preloader Handoff Information
The system manager provides eight 32-bit registers to store handoff information between the preloader and the operating system. The preloader can store any information in these registers. These register contents have no impact on the state of the HPS hardware. When the operating system kernel boots, it retrieves the information by reading the preloader to OS handoff information register array. These registers are reset only by a cold reset.
6.3.7. Clocks
The system manager is driven by a clock generated by the clock manager.
6.3.8. Resets
The system manager receives two reset signals from the reset manager. The sys_manager_rst_n signal is driven on a cold or warm reset and the sys_manager_cold_rst_n signal is driven only on a cold reset. This function allows the system manager to reset some CSR fields on either a cold or warm reset and others only on a cold reset.
6.4. System Manager Address Map and Register Definitions
For complete HPS address map and register definitions, refer to the Intel Arria 10 HPS Register Address Map and Definitions.
7. SoC Security
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.
7.1. 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
7.1.1. Security Manager Block Diagram
7.1.2. 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.
7.1.3. Functional Description
7.1.3.1. 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.
7.1.3.1.1. Secure Fuses
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.
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.
|
20 | dbg_lock_DAP | This field indicates if the DAP access level can be
changed through software when the HPS is released from reset.
|
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.
|
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.
|
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.
|
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.
|
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.
|
10 | clr_ram_cold_f |
This fuse value indicates what happens to the RAM on a cold reset.
|
9 | clr_ram_warm_f |
This fuse value indicates what happens to the RAMs 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.
|
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.
|
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.
|
5 | aes_en_f |
This fuse value indicates if a 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:
|
1 | kak_len_f |
This fuse value indicates the Key Authorization Key (KAK) length:
|
0 | authen_en_f |
This fuse value determines whether authentication of 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.
7.1.3.2. Security State
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.
7.1.3.2.1. 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.
- A fuse security level check
- A hardware access security level check
- A software access security level check
7.1.3.2.2. 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.
7.1.3.3. 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.
7.1.3.3.1. 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.
7.1.3.3.2. 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.

7.1.3.4. 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:
- All domain resets are asserted.
- All RAMs are cleared.
- 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.
7.1.3.5. 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.
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) |
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.
7.1.3.6. 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.
7.1.3.7. 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:
- The HPS boot and FPGA configuration occur separately.
- The HPS boots from the FPGA after the FPGA is configured
- The HPS boots first and configures the FPGA.
7.1.3.7.1. 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.
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:
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.
|
20 | dbg_lock_DAP | This field indicates if the DAP access level can be
changed through software when the HPS is released from reset.
|
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.
|
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.
|
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.
|
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.
|
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.
|
10 | clr_ram_cold_f |
This fuse value indicates what happens to the RAM on a cold reset.
|
9 | clr_ram_warm_f |
This fuse value indicates what happens to the RAMs 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.
|
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.
|
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.
|
5 | aes_en_f |
This fuse value indicates if a 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:
|
1 | kak_len_f |
This fuse value indicates the Key Authorization Key (KAK) length:
|
0 | authen_en_f |
This fuse value determines whether authentication of flash images is required prior to execution.
|
7.1.3.7.2. 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.
7.1.3.7.3. 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.
7.1.3.8. 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.
- Ethernet MAC 0/1/2
- USB OTG 0/1
- QSPI flash controller
- NAND flash controller
- SD/MMC controller
- DMA controller
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.
7.2. Security System Extensions
Beyond the Security Manager module, other secure features can be implemented at a system level within the SoC.
7.2.1. TrustZone
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.
7.2.1.1. Secure Partitioning
System interconnect and cache accesses as well as processor execution can be securely partitioned using the TrustZone* infrastructure.
7.2.1.1.1. 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.
7.2.1.1.2. 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.
7.2.1.2. 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.
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* :
- Non-secure
- Secure
- 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.
7.2.2. 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
There are five main firewalls in the HPS:
- Peripheral
- System
- HPS-to-FPGA
- On-Chip RAM
- SDRAM (which includes DDR and DDR L3 firewalls)
7.2.2.1. Firewall Diagrams
The system interconnect firewalls filter access to components on various buses.
Name |
Function |
---|---|
Peripherals |
The peripherals firewall filters access to slave peripherals in the following buses:
|
System |
The system firewall filters access to system peripherals in the following components:
|
HPS-to-FPGA |
The HPS-to-FPGA firewall filters access to FPGA through the following bridges:
|
On-Chip RAM |
The on-chip RAM firewall filters secure access to on-chip RAM |
SDRAM |
The SDRAM firewall filters access to DDR SDRAM |
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 |
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 |
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 |
7.2.2.2. Secure Transaction Protection
The interconnect provides two levels of transaction protection.
- 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.
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.
7.2.2.2.1. 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.
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.
7.2.2.2.2. 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.
7.2.2.2.3. 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.
7.2.2.2.4. 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.
7.2.2.3. 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 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
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 |
7.2.2.4. 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.
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.
7.2.2.5. 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
8. System Interconnect
The components of the hard processor system (HPS) communicate with one another, and with other portions of the SoC device, through the system interconnect. The system interconnect consists of the following blocks:
- The main level 3 (L3) interconnect
- The SDRAM L3 interconnect
- The level 4 (L4) buses
The system interconnect is the main communication bus for the MPU and all IPs in the SoC device.
The system interconnect is implemented by the Arteris® FlexNoC™ network-on-chip (NoC) interconnect module.
The system interconnect supports the following features:
- An L3 interconnect that provides high-bandwidth routing between masters and slaves in the HPS
- SDRAM L3 interconnect, providing access to a hard memory controller in the FPGA fabric through a multiport front end (MPFE) scheduler for sharing the external SDRAM between multiple masters in the SoC device
- Independent L4 buses running in several clock domains. These buses handle data traffic for low- to mid-level bandwidth slave peripherals and accesses to peripheral control and status registers throughout the address map.
- On-chip debugging and tracing capabilities
- Security firewalls with
the following capabilities:
- Secure or nonsecure access configured per peripheral
- Privileged or user access configured per peripheral (for some peripherals)
- Security optionally configured per transaction at the master
- Quality of service (QoS) with three programmable levels of service on a per-master basis
8.1. About the System Interconnect
8.1.1. Features of the System Interconnect
The system interconnect supports high-throughput peripheral devices. The system interconnect has the following characteristics:
- Byte oriented address handling
- Data bus width up to 128 bits
- Arm* TrustZone* -compliant firewall and security support, with additional security features configurable per master
- Programmable quality-of-service (QoS) optimization
- Dedicated SDRAM L3 interconnect, providing access and scheduling for the hard memory controller in the FPGA portion of the SoC device
- On-chip debug and tracing capabilities
- Multiple independent L4 buses with
independent clock domains and protocols
The L4 buses are each connected to a master in the main L3 interconnect for control and status register access. Each L4 bus is 32 bits wide and is connected to multiple slaves. The L4 buses also provide a low- to mid-level tier of the system interconnect for lower-bandwidth slave peripherals. Each L4 bus is 32 bits wide and operates in a separate clock domain.
8.1.2. Block Diagram and System Integration
8.1.2.1. System Interconnect Block Diagram
8.1.2.2. Connectivity
8.1.2.2.1. Arria 10 HPS Master-to-Slave Connectivity Matrix
Each system interconnect packet carries a transaction between a master and a slave. The following figure shows the connectivity of all the master and slave interfaces in the system interconnect.
8.1.2.2.2. On-Chip RAM
8.1.2.2.3. Peripherals Connections
8.1.2.2.4. System Connections
8.1.2.2.5. HPS-to-FPGA Bridge
8.1.2.2.6. SDRAM Connections
8.1.2.3. System Interconnect Architecture
The system interconnect is a packet-oriented network on chip (NoC), in which each packet carries a transaction between a master and a slave. The interconnect provides interface widths up to 128 bits, connecting to the L4 slave buses and to HPS and FPGA masters and slaves.
The system interconnect provides low-latency connectivity to the following bridges:
- HPS-to-FPGA bridge
- Lightweight HPS-to-FPGA bridge
- FPGA-to-HPS bridge
- Three FPGA-to-SDRAM ports
8.1.2.3.1. SDRAM L3 Interconnect Architecture
The SDRAM L3 interconnect is part of the system interconnect, and includes these components:
- SDRAM scheduler
- SDRAM adapter
The SDRAM L3 interconnect operates in a clock domain that is 1/2 the speed of the hard memory controller clock.
8.1.3. 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
There are five main firewalls in the HPS:
- Peripheral
- System
- HPS-to-FPGA
- On-Chip RAM
- SDRAM (which includes DDR and DDR L3 firewalls)
8.1.4. About the Rate Adapters
8.1.5. About the SDRAM L3 Interconnect
The SDRAM L3 Interconnect contains an SDRAM scheduler and an SDRAM adapter. The SDRAM scheduler functions as a multi-port front end (MPFE) for multiple HPS masters. The SDRAM adapter is responsible for connecting the HPS to the SDRAM hard memory controller in the FPGA portion of the device. The SDRAM L3 interconnect is part of the system interconnect.
8.1.5.1. Features of the SDRAM L3 Interconnect
- Connectivity to the SDRAM
hard
memory controller supporting:
- DDR4-SDRAM
- DDR3-SDRAM
- Integrated SDRAM scheduler, functioning as a multi-port front end (MPFE)
- Configurable SDRAM device
data widths
- 16-bit, with or without 8-bit error-correcting code (ECC)
- 32-bit, with or without 8-bit ECC
- 64-bit, with or without 8-bit ECC
- High-performance ports
- MPU subsystem port
- Main L3 interconnect port
- Three
FPGA ports
- Two 32-, 64-, or 128-bit ports
- One 32- or 64-bit port
- Firewall and security support port
8.1.5.2. SDRAM L3 Interconnect Block Diagram and System Integration
The SDRAM adapter is responsible for bridging the hard memory controller in the FPGA fabric to the SDRAM scheduler. The adapter is also responsible for ECC generation and checking.
The ECC register interface provides control to perform memory and ECC logic diagnostics.
The SDRAM scheduler is an MPFE, responsible for arbitrating collisions and optimizing performance in traffic to the SDRAM controller in the FPGA portion of the device.
Three Arm* Advanced Microcontroller Bus Architecture ( AMBA* ) Advanced eXtensible Interface ( AXI* ) ports are exposed to the FPGA fabric, allowing soft logic masters to access the SDRAM controller through the same scheduler unit as the MPU subsystem and other masters within the HPS. The MPU has access to the SDRAM adapter's control interface to the hard memory controller.
The hard memory controller in the FPGA portion of the device has a dedicated connection to the SDRAM L3 interconnecct. This connection allows the hard memory controller to become operational before the rest of the FPGA has been configured.
8.1.5.3. About the SDRAM Scheduler
The SDRAM scheduler supports the following masters:
- The MPU
- The L3 system interconnect
- The FPGA-to-SDRAM bridges
The SDRAM scheduler arbitrates among transactions initiated by the masters, and determines the order of operations. The scheduler arbitrates among the masters, ensuring optimal interconnect performance based on configurable quality-of-service settings.
The SDRAM scheduler can be configured through the registers.
8.1.6. About Arbitration and Quality of Service
Arbitration and QoS logic work together to enable optimal performance in your system. For example, by setting QoS parameters, you can prevent one master from using up the interconnect's bandwidth at the expense of other masters.
The system interconnect supports QoS optimization through programmable QoS generators. The QoS generators are located on interconnect initiators, which correspond to master interfaces. The initiators insert packets into the interconnect, with each packet carrying a transaction between a master and a slave. Each QoS generator creates control signals that prioritize the handling of individual transactions to meet performance requirements.
Arbitration and QoS in the HPS system interconnect are based on the following concepts:
- Priority—Each packet has a priority value. The arbitration logic generally gives resources to packets with higher priorities.
- Urgency—Each master has an urgency value. When it initiates a packet, it assigns a priority equal to its urgency.
- Pressure—Each data path has a pressure value. If the pressure is raised, packets on that path are treated as if their priority was also raised.
- Hurry—Each master has a hurry value. If the hurry is raised, all packets from that master are treated as if their priority was also raised.
Proper QoS settings depend on your performance requirements for each component and peripheral, and for system performance as a whole. Intel recommends that you become familiar with QoS optimization techniques before you try to change the QoS settings in the HPS system interconnect.
8.1.7. About the Service Network
Through the service network, you can perform these tasks:
- Access internal interconnect registers
- Update master and slave peripheral security features
8.1.8. About the Observation Network
The observation network connects probes to the observer, which is a port in the CoreSight* trace funnel. Through the observation network, you can perform these tasks:
- Enable error logging
- Selectively trace transactions in the system interconnect
- Collect HPS transaction statistics and profiling data
The observation network consists of probes in key locations in the interconnect, plus connections to observers. The observation network works across multiple clock domains, and implements its own clock crossing and pipelining where needed.
The observation network sends probe data to the CoreSight subsystem through the ATB interface. Software can enable probes and retrieve probe data through the interconnect observation registers.
8.2. Functional Description of the System Interconnect
The system interconnect provides access to a 4 GB address space.
Address spaces are divided into one or more nonoverlapping contiguous regions.
The window regions provide access to other address spaces. The thin black arrows indicate which address space is accessed by a window region (arrows point to accessed address space).
The following table shows the base address and size of each region that is common to the L3 and MPU address spaces.
Region Name | Description | Base Address | Size |
---|---|---|---|
FPGASLAVES | FPGA slaves | 0xC0000000 | 960 MB |
PERIPH | Peripheral | 0xFC000000 | 64 MB |
LWFPGASLAVES 8 | Lightweight FPGA slaves | 0xFF200000 | 2 MB |
8.2.1. System Interconnect Address Spaces
Each address space uses some or all of the 4 GB address range. The address spaces overlap. Depending on the configuration, different address spaces are visible in different regions for each master.
The following address spaces are available:
- The L3 address space
- The MPU address space
- The SDRAM address space
8.2.1.1. Arria 10 HPS Available Address Maps
Notes on Address Maps
(1) Transactions on these addresses are directly decoded by the SCU and L2 cache.
(2) The MPU accesses SDRAM through a dedicated port to the SDRAM scheduler. The SDRAM window size also depends on L2 cache filtering.
(3) This region can be configured to access on-chip RAM, by using the noc_addr_remap_value, noc_addr_remap_set, and noc_addr_remap_clear registers, in the system manager.
(4) The following peripherals can master the interconnect:
- Ethernet MACs
- USB-2.0 OTG controllers
- NAND controller
- ETR
- SD/MMC controller
4To access registers that are connected to the HPS-to-FPGA AXI* master bridge, you need to set the base address of your slave interface starting from 0xC0000000. The HPS-to-FPGA AXI* master bridge can be connected to any type of slave interface such as APB* and Avalon® .
For the MPU L3 master, either the boot ROM or on-chip RAM can map to address 0x0 and obscure the lowest 128 KB or 256 KB of SDRAM.
At boot time, the MPU does not have access to the SDRAM address space from the top of ROM or on-chip RAM to 0x00100000. This is because the MPU's SDRAM access is controlled by the MPU L2 filter registers, which only have a granularity of 1 MB. After booting completes, the MPU can change address filtering to use the lowest 1 MB of SDRAM.
For non-MPU masters, either the on-chip RAM or the SDRAM maps to address 0x0. When mapped to address 0x0, the on-chip RAM obscures the lowest 256 KB of SDRAM for non-MPU masters.
8.2.1.2. Arria 10 HPS L3 Address Space
The Arria 10 HPS L3 address space is 4 GB and applies to all L3 masters except the MPU subsystem.
The system interconnect noc_addr_remap_value, noc_addr_remap_set, and noc_addr_remap_clear registers, in the System Manager, determine if the address space starting at address 0x0 is mapped to the on-chip RAM (256 KB) or the SDRAM. SDRAM is mapped to address 0x0 on reset.
The L3 address space configurations contain the regions shown in the following table:
Description | Condition | Base Address | End Address | Size |
---|---|---|---|---|
SDRAM window (without on-chip RAM) | remap0 set, remap1 clear 9 | 0x00000000 | 0xBFFFFFFF | 3 GB |
On-chip RAM (low mapping) | remap0 set, remap1 set 9 | 0x00000000 | 0x0003FFFF | 256 KB |
SDRAM window (with on-chip RAM) | remap0 set, remap1 set 9 | 0x00040000 | 0xBFFFFFFF | 3145471 KB = 3 GB - 256 KB |
HPS-to-FPGA | Not visible to FPGA-to-HPS bridge. | 0xC0000000 | 0xFBFFFFFF | 960 MB |
System trace macrocell | Always visible to DMA and FPGA-to-HPS | 0xFC000000 | 0xFEFFFFFF | 48 KB |
Debug access port | Not visible to master peripherals. Always visible to other masters. | 0xFF000000 | 0xFF1FFFFF | 2 MB |
Lightweight HPS-to-FPGA | Not visible to master peripherals. Always visible to other masters. | 0xFF200000 | 0xFF3FFFFF | 2 MB |
Peripherals | Not visible to master peripherals. Always visible to other masters. | 0xFF800000 | 0xFFFDFFFF | 8064 KB |
On-chip RAM (high mapping) | Always visible | 0xFFE00000 | 0xFFFE3FFF | 256 KB |
Cache coherent memory accesses have the same view of memory as the MPU.
SDRAM Window Region
The SDRAM window region is 3 GB and provides access to the bottom 3 GB of the SDRAM address space.On-Chip RAM Region, Low Mapping
The system interconnect noc_addr_remap_value register determines if the 256 KB starting at address 0x0 is mapped to the on-chip RAM or the SDRAM. The SDRAM is mapped to address 0x0 on reset.HPS-to-FPGA Slaves Region
The HPS-to-FPGA slaves region provides access to 960 MB of slaves in the FPGA fabric through the HPS-to-FPGA bridge.Lightweight HPS-to-FPGA Slaves Region
The lightweight HPS-to-FPGA slaves provide access to slaves in the FPGA fabric through the lightweight HPS-to-FPGA bridge.Peripherals Region
The peripherals region includes slaves connected to the L3 interconnect and L4 buses.On-Chip RAM Region, High Mapping
The on-chip RAM is always mapped (independent of the boot region contents).8.2.1.3. MPU Address Space
Addresses generated by the MPU are decoded in three ways:
- By default, MPU accesses to locations between 0x100000 (1 MB) to 0xC0000000 (3 GB) are made to the SDRAM controller.
- Addresses in the SCU and L2 register region (0xFFFFC000 to 0xFFFFFFFF) are the SCU and L2 bus.
- Accesses to all other locations are made to the L3 interconnect.
The MPU L2 cache controller contains a master connected to the main L3 interconnect and a master connected to the SDRAM L3 interconnect.
The system interconnect noc_addr_remap_value, noc_addr_remap_set, and noc_addr_remap_clear registers, in the System Manager, determine if the address space starting at address 0x0 is mapped to the on-chip RAM (256 KB) or the ROM (128 KB). The ROM is mapped to address 0x0 on reset.
The MPU address space contains the following regions:
Description | Condition |
Base Address |
End Address |
Size |
---|---|---|---|---|
Boot ROM | remap0 clear, remap1 clear 10 |
0x00000000 |
0x0001FFFF |
128 KB |
SDRAM window | Always visible |
0x00100000 |
0xBFFFFFFF | 3071 MB (3 GB – 1 MB) |
HPS-to-FPGA | Always visible | 0xC0000000 | 0xFBFFFFFF | 960 MB (1 GB – 64 MB) |
System trace macrocell | Always visible | 0xFC000000 | 0xFFEFFFFF | 48 KB |
Debug access port | Always visible | 0xFF000000 | 0xFF1FFFFF | 2 MB |
Lightweight HPS-to-FPGA | Always visible | 0xFF200000 | 0xFF3FFFFF | 2 MB |
Peripherals | Always visible | 0xFF800000 | 0xFFDFFFFF | 6 MB |
On-chip RAM | Always visible | 0xFFE00000 | 0xFFFE3FFF | 256 KB |
Boot ROM | Always visible | 0xFFFC0000 | 0xFFFDFFFF | 128 KB |
SCU and L2 registers | Always visible | 0xFFFFC000 | 0xFFFFFFFF | 16 KB |
Boot Region
The boot region is 1 MB, based at address 0x0. The boot region is visible to the MPU only when the L2 address filter start register is set to 0x100000. The L3 noc_addr_remap_value control register determines if the boot region is mapped to the on-chip RAM or the boot ROM.
The boot region is mapped to the boot ROM on reset. Only the lowest 128 KB of the boot region are legal addresses because the boot ROM is only 128 KB.
When the L2 address filter start register is set to 0, SDRAM obscures access to the boot region. This technique can be used to gain access to the lowest SDRAM addresses after booting completes.
SDRAM Window Region
The SDRAM window region provides access to a large, configurable portion of the 4 GB SDRAM address space. The address filtering start and end registers in the L2 cache controller define the SDRAM window boundaries.
The boundaries are megabyte-aligned. Addresses within the boundaries route to the SDRAM master, while addresses outside the boundaries route to the system interconnect master.
Addresses in the SDRAM window match addresses in the SDRAM address space. Thus, the lowest 1 MB of the SDRAM is not visible to the MPU unless the L2 address filter start register is set to 0.
HPS-to-FPGA Slaves Region
The HPS-to-FPGA slaves region provides access to slaves in the FPGA fabric through the HPS-to-FPGA bridge. Software can move the top of the SDRAM window by writing to the L2 address filter end register. If higher addresses are made available in the SDRAM window, part of the FPGA slaves region might be inaccessible to the MPU.
Lightweight HPS-to-FPGA Slaves Region
The lightweight FPGA slaves provide access to slaves in the FPGA fabric through the lightweight HPS-to-FPGA bridge.
Peripherals Region
The peripherals region is near the top of the address space. The peripherals region includes slaves connected to the L3 interconnect and L4 buses.
On-Chip RAM Region
The on-chip RAM is always mapped near the top of the address space, independent of the boot region contents.
Boot ROM Region
The boot ROM is always mapped near the top of the address space, independent of the boot region contents.
SCU and L2 Registers Region
The SCU and L2 registers region provides access to internally-decoded MPU registers (SCU and L2).
8.2.1.4. SDRAM Address Space
The SDRAM address space is up to 4 GB. The entire address space can be accessed through the FPGA‑to‑SDRAM interface from the FPGA fabric. The total amount of SDRAM addressable from the other address spaces varies.
There are cacheable and non-cacheable views into the SDRAM space. When a master of the performs a cacheable access to the SDRAM, the transaction is performed through the ACP port of the MPU subsystem. When a master of the performs a non-cacheable access to the SDRAM, the transaction is performed through the 32-bit master of the .
8.2.1.5. Address Remapping
The system interconnect supports address remapping through the noc_addr_remap_value, noc_addr_remap_set, and noc_addr_remap_clear registers in the system manager. Remapping allows software to control which memory device (on-chip RAM or boot ROM) is accessible at address 0x0. The remap registers can be modified by the MPU and the FPGA-to-HPS bridge.
The following master interfaces are affected by the remap bits:
- MPU master interface
- L2 cache master 0 interface
- Non-MPU master interfaces
- DMA master interface
- Master peripheral interfaces
- Debug Access Port (DAP) master interface
- FPGA-to-HPS bridge master interface
8.2.1.5.1. Memory Map Remap Bits
remap0 | remap1 | 0x00000000 (MPU Master Interface) | 0x00000000 (Non-MPU Master Interfaces) | 0xFFE00000 (All Maps) | 0xFFFC0000 (MPU & DAP) |
---|---|---|---|---|---|
0 | 0 | Boot ROM | SDRAM | On-Chip RAM | Boot ROM |
0 | 1 | Invalid setting | |||
1 | 0 | SDRAM | SDRAM | On-Chip RAM | Boot ROM |
1 | 1 | On-Chip RAM | On-Chip RAM | On-Chip RAM | Boot ROM |
L2 filter registers in the MPU subsystem, not the interconnect, allow the SDRAM to be remapped to address 0x0 for the MPU.
8.2.2. Secure Transaction Protection
The system interconnect provides two levels of secure transaction protection:
- Security firewalls—Enforce secure read and write transactions.
- Privilege filter—Leverages the firewall mechanism and provides additional security by filtering 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 must pass both a security firewall and the privilege filter to reach the slave.
8.2.3. System Interconnect Master Properties
The system interconnect connects to slave interfaces through the main L3 interconnect and SDRAM L3 interconnect.
Master | Interface Width | Clock | Security | SCR11 Access | Privilege | Issuance (Read/Write/Total) | Type |
---|---|---|---|---|---|---|---|
MPU Subsystem L2 cache M0/1 | 64 | mpu_l2ram_clk | Per Transaction | Yes | Transaction based | 7/12/23 | AXI* |
FPGA-to-HPS Bridge 12 | 32/64/128 | fpga2hps_clk | Per Transaction | Yes | Transaction based | 8/8/8 | AXI* |
FPGA-to-SDRAM Ports 12 | 32/64/128 | f2h_sdram_clk[2:0] | Per Transaction | No | Transaction based | 8/8/8 | AXI* |
DMA | 64 | l4_main_clk | Per Transaction | No | User mode | 8/8/8 | AXI* |
EMAC 0/1/2 | 32 | l4_mp_clk | Secure/Non-Secure | No | User mode | 16/16/32 | AXI* |
USB OTG 0/1 | 32 | l4_mp_clk | Nonsecure | No | User mode | 2/2/4 | AHB* |
NAND | 32 | l4_mp_clk | Nonsecure | No | User mode | 1/1/2 | AXI* |
SD/MMC | 32 | l4_mp_clk | Nonsecure | No | User mode | 2/2/4 | AHB* |
ETR | 32 | cs_at_clk | Per Transaction | No | Transaction based | 32/1/32 | AXI* |
AHB* -AP | 32 | l4_mp_clk | Per Transaction | Yes | Transaction based | 1/1/1 | AHB* |
8.2.3.1. Master Caching and Buffering Overrides
Some of the peripheral masters connected to the do not have the ability to drive the caching and buffering signals of their interfaces. The system manager provides registers so that you can enable cacheable and bufferable transactions for these masters. The system manager drives the caching and buffering signals of the following masters:
Master Peripheral | System Manager Registers |
---|---|
EMAC0, EMAC1, and EMAC2 | emac0, emac1, and emac2 |
USB OTG 0 and USB OTG 1 | usb0_l3master and usb1_l3master |
NAND flash | nand_l3master |
SD/MMC | sdmmc_l3master |
At reset time, the system manager drives the cache and buffering signals for these masters low. In other words, the masters listed do not support cacheable or bufferable accesses until you enable them after reset. There is no synchronization between the system manager and the , so avoid changing these settings when any of the masters are active.
8.2.4. System Interconnect Slave Properties
The system interconnect connects to various slave interfaces through the main L3 interconnect, the SDRAM L3 interconnect, and the L4 peripheral buses. After reset, all slave interfaces are set to the secure state.
Slave |
Interface Width |
Clock |
Acceptance (Read/Write/Total)13 |
Security |
Privilege |
Interface Type |
---|---|---|---|---|---|---|
SP Timer 0/1/2/3 |
32 |
l4_sp_clk |
1/1/1 |
Boot Secure 14 |
User Mode |
APB* 15 |
I2C 0/1/2/3/4 |
32 |
l4_sp_clk |
1/1/1 |
Boot Secure |
User Mode |
APB* 15 |
UART 0/1 |
32 |
l4_sp_clk |
1/1/1 |
Boot Secure |
User Mode |
APB* 15 |
GPIO 0/1/2 |
32 |
l4_sp_clk |
1/1/1 |
Boot Secure |
User Mode |
APB* 15 |
SD/MMC CSR |
32 |
l4_mp_clk |
1/1/1 |
Boot Secure |
User Mode |
APB* 15 |
EMAC 0/1/2 |
32 |
l4_mp_clk |
1/1/1 |
Boot Secure |