Arria V Hard Processor System Technical Reference Manual
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.1 |
1. Arria V Hard Processor System Technical Reference Manual Revision History
Chapter | Date of Last Update |
---|---|
October 28, 2016 | |
Clock Manager | November 2, 2015 |
Reset Manager | November 2, 2015 |
FPGA Manager | June 14, 2019 |
System Manager | July 17, 2018 |
Scan Manager | May 3, 2016 |
System Interconnect | May 4, 2015 |
HPS-FPGA Bridges | September 3, 2020 |
Cortex®-A9 Microprocessor Unit Subsystem | September 3, 2020 |
CoreSight* Debug and Trace | July 31, 2014 |
SDRAM Controller Subsystem Controller | February 28, 2020 |
On-Chip Memory | January 26, 2018 |
NAND Flash Controller | January 26, 2018 |
SD/MMC Controller | January 26, 2018 |
Quad SPI Flash Controller | September 3, 2020 |
DMA Controller | January 26, 2018 |
Ethernet Media Access Controller | June 14, 2019 |
USB 2.0 OTG Controller | January 26, 2018 |
SPI Controller | January 26, 2018 |
I2C Controller | May 4, 2015 |
UART Controller | November 2, 2015 |
General-Purpose I/O Interface | September 3, 2020 |
Timer | June 30, 2014 |
Watchdog Timer | November 2, 2015 |
Introduction to the HPS Component | December 30, 2013 |
Instantiating the HPS Component | November 2, 2015 |
HPS Component Interfaces | May 4, 2015 |
Simulating the HPS Component | May 3, 2016 |
Booting and Configuration | September 3, 2020 |
Document Version |
Changes |
---|---|
2016.10.28 |
|
2016.05.03 |
Maintenance release. |
2015.11.02 | Updated the link to the Memory Maps. |
2015.05.04 | Corrected the base address for NANDDATA in the "Peripheral Region Address Map" table. |
2014.12.15 | Maintenance release |
2014.07.31 | Updated address maps and register descriptions |
2014.06.30 | Maintenance release |
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.3 |
Minor updates. |
1.2 |
Updated address spaces section. |
1.1 |
Added peripheral region address map. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2020.01.13 | Correct typical sdmmc_clk frequencies in Flash Controller Clocks |
2015.11.02 | Minor formatting updates. |
2015.05.04 | Minor formatting updates. |
2014.12.15 |
FREF, FVCO, and FOUT Equations section updated. More information added about vco register, M and N equations. Reference Clock information added to Clock Groups section. |
2014.06.30 |
E0SC1 changed to HPS_CLK1 E0SC2 changed to HPS_CLK2 Added Address Map and Register Descriptions |
2014.02.28 |
Updated content in the "Peripheral Clock Group" section |
2013.12.30 |
Minor formatting updates. |
1.2 |
Minor updates. |
1.1 |
|
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2015.11.02 | Updated "Reset Pins" section |
2015.05.04 | Updated:
|
2014.12.15 |
|
2014.06.30 |
|
2014.02.28 |
Updated sections:
|
2013.12.30 |
Minor formatting issues. |
1.2 |
|
1.1 |
Added reset controller, functional description, and address map and register definitions sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2019.06.14 | Corrected the msel descriptions for encodings 0x0 through 0x2 and 0x4 to 0x6 in the stat register. |
2015.11.02 | Provided more information for the configuration schemes for the dedicated pins. |
2015.05.04 | Added information about FPPx32. |
2014.12.15 | Maintenance release |
2014.06.30 | Added address maps and register definitions |
2014.02.28 | Maintenance release |
2013.12.30 | Minor updates. |
1.3 |
Minor updates. |
1.2 |
Updated the FPGA configuration section. |
1.1 |
|
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2018.11.03 | Modified mode register bitfield descriptions for clarity. |
2018.07.17 | Made the following changes to the
Pin Mux Control Group register block:
|
2014.06.30 |
|
2014.02.28 | Maintenance release |
2013.12.30 |
Maintenance release. |
1.2 |
Minor updates. |
1.1 |
Added functional description, address map and register definitions sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2016.05.03 | Added a list of the HPS I/O pins that do not support boundary scan tests in the Arm* JTAG-AP Scan Chains section. |
2015.11.02 | Maintenance release |
2015.05.04 | Maintenance release |
2014.12.15 | Maintenance release |
2014.06.30 |
|
2014.02.28 | Update to "Scan Manager Block Diagram and System Integration" section |
2013.12.30 |
Minor formatting issues |
1.2 |
Added JTAG-AP descriptions. |
1.1 |
Added block diagram and system integration, functional description, and address map and register definitions sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2015.05.04 |
|
2014.12.15 |
|
2014.06.30 |
|
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.2 |
Minor updates. |
1.1 |
|
1.0 |
Initial release. |
Document Version | Changes |
---|---|
2020.09.03 | Updated Taking HPS-FPGA Bridges Out of Reset with clarification on the state of the HPS GPIO during cold reset. |
2014.06.30 | Added address maps and register definitions |
2014.02.28 | Maintenance release |
2013.12.30 |
Maintenance release |
1.1 |
Described GPV |
1.0 |
Initial release |
Document Version |
Changes |
---|---|
2020.09.03 | Added Interconnect Master (L2M0) to the "HPS Peripheral Master Input IDs" table in HPS Peripheral Master Input IDs. |
2020.01.13 | Added new section Avoiding ACP Dependency Lockup |
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.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 | Clarified EMAC0 and EMAC1 ACP Mapper IDs in the "HPS Peripheral Master Input IDs" table in the "HPS Peripheral Master Input IDs" section. |
2014.12.15 |
|
2014.06.30 |
|
2014.02.28 | Maintenance release |
2013.12.30 |
Correct SDRAM region address in Arm* Cortex®-A9 MPCore* Address Map |
1.2 |
Minor updates. |
1.1 |
|
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2014.07.31 |
Updated the address map and register definitions. |
2014.06.30 |
Added address map and register definitions. |
2014.02.28 |
Maintenance release. |
2013.12.30 |
Maintenance release. |
1.2 |
Minor updates. |
1.1 |
Added functional description, programming model, and address map and register definition sections. |
1.0 |
Initial release. |
Document Version | Changes |
---|---|
2020.02.28 | In the Memory Protection section - Corrected the "Protection" field definition in the "Fields for Rules in Memory Protection Table". |
2018.07.17 | Modified text to clarify that there is support for up to 4 Gb external memory device per chip select. |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.6.30 |
|
2013.12.30 |
|
1.1 | Added address map and register definitions section. |
1.0 | Initial release. |
Document Version |
Changes |
---|---|
2018.01.26 | Updated "On-Chip RAM Initialization" section with steps to enable ECC. |
2016.10.28 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 | Maintenance release |
2015.05.04 | Maintenance release |
2014.12.15 | Maintenance release |
2014.06.30 | Added address maps and register definitions |
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.1 |
Added address map section |
1.0 |
Initial release |
Document Version |
Changes |
---|---|
2018.01.26 | Updated "ECC Enabling" section with steps to enable ECC. |
2016.10.28 | Added content about the local memory buffer |
2016.05.27 | Added a link to the Supported Flash Devices for Cyclone V and Arria V 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.07.31 |
Updated address map and register definitions. |
2014.06.30 |
|
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.2 |
|
1.1 |
Added programming model section. |
1.0 |
Initial release |
Document Version | Changes |
---|---|
2018.01.26 | Added "Enabling ECC" section. |
2017.12.27 | Added 8-bit support for eMMC in the "Features of SD/MMC Controller" section. (FB320076) |
2016.10.28 |
|
2016.05.27 | Added a link to the Supported Flash Devices for Cyclone V and Arria V 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.06.30 | Added address maps and register definitions |
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.1 |
|
1.0 | Initial release. |
Document Version | Changes |
---|---|
2020.09.03 | Updated the definition for the QSPI register: indaddrtrig in the Quad SPI Flash Controller Address Map and Register Definitions section |
2019.07.09 |
Added a new section, Write Request, with WREN and RDSR information |
2019.06.14 |
Maintenance release |
2018.01.26 | Updated "Local Memory Buffer" section with steps to enable ECC. |
2016.10.28 | Maintenance release |
2016.05.27 |
|
2016.05.03 |
|
2015.11.02 |
|
2015.05.04 | Added information about clearing out the ECC before the feature is enabled |
2014.12.15 | Maintenance release |
2014.07.31 | Updated address maps and register descriptions |
2014.06.30 |
Added address maps and register definitions |
2014.02.28 | Maintenance release |
2013.12.30 | Maintenance release |
1.2 | Minor updates. |
1.1 | Added block diagram and system integration, functional description, programming model, and address map and register definitions sections. |
1.0 | Initial release. |
Document Version |
Changes |
---|---|
2018.01.26 | Updated "Initializing and Clearing of Memory before Enabling ECC" section with steps to enable ECC. |
2016.10.28 | Maintenance release |
2016.05.03 | Maintenance release |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 | Maintenance release |
2014.07.31 | Updated address maps and register descriptions |
2014.06.30 | Added address maps and register definitions |
2014.02.28 |
ECC updates |
1.2 |
Maintenance release |
1.1 |
Minor updates |
1.0 |
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 | Claified the PCF bit description for encoding value
0x2 in the MAC_Frame_Filter
register.
|
2016.10.28 |
|
2016.05.03 | Maintenance release. |
2015.11.02 |
|
2015.05.04 |
|
2014.12.15 |
|
2014.06.30 |
Updated EMAC to RGMII Interface table with EMAC Port names Updated EMAC to FPGA PHY Interface table with Signal names Updated EMAC to FPGA IEEE1588 Timestamp Interface with Signal names Added Address Map and Register Descriptions |
2014.02.28 | ECC updates. |
1.4 | Maintenance release. |
1.3 |
|
1.2 | Updated the HPS boot and FPGA configuration sections. |
Document Version |
Changes |
---|---|
2018.01.26 | Added steps for enabling ECC. |
2016.10.28 | Maintenance release. |
2016.05.03 | Maintenance release. |
2015.11.02 | Renamed "ULPI PHY Interface" section to "USB 2.0 ULPI PHY Signal Description" and moved it after the "USB OTG Controller Block Diagram and System Integration" section. |
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.07.31 |
Updated address map and register definitions. |
2014.06.30 |
Added USB OTG Controller address map and register definitions. |
2014.02.28 |
Maintenance release. |
2013.12.30 |
Maintenance release. |
1.2 |
|
1.1 |
Added information about ECCs. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2017.01.26 | Corrected the support information for continuous data transfers in SPI Serial Format. |
2016.10.28 | Maintenance release. |
2016.05.03 | Maintenance release. |
2015.11.02 |
|
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.06.30 |
|
2014.02.28 | Maintenance release. |
2013.12.30 |
Minor formatting updates. |
1.2 |
Minor updates. |
1.1 |
Added programming model, address map and register definitions, clocks, and reset sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2015.05.04 |
|
2014.12.15 |
|
2014.06.30 |
HPS I2C Signals for FPGA Routing table updated I2C interface in FPGA Fabric diagram added Added Address Map and Register Descriptions |
2014.02.28 | Maintenance release. |
2013.12.30 |
Added HPS I2c Signals for FPGA routing to "Interface Pins" section. |
1.2 |
Minor updates. |
1.1 |
Added programming model, address map and register definitions, clocks, reset, and interface pins sections. |
1.0 |
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.06.30 |
|
2014.02.28 | Maintenance release |
2013.12.30 |
Minor formatting updates. |
1.2 |
Minor updates. |
1.1 |
Added programming model, address map and register definitions, and reset sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2020.09.03 | Added information about the state of HPS GPIO during cold reset in the Taking the GPIO Interface Out of Reset section. |
2019.06.14 | Added GPIO State During Reset section. |
2014.12.15 |
|
2014.06.30 |
Added Address Map and Register Descriptions |
2014.02.28 |
Updated content in sections:
|
2013.12.30 |
Minor formatting updates Updated GPIO interface block diagram and GPIO interface pin table |
1.2 |
Minor updates. |
1.1 |
Added programming model section. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2014.06.30 |
|
2014.02.28 | Maintenance release. |
2013.12.30 |
Minor formatting updates. |
1.2 |
Minor updates. |
1.1 |
Added programming model and address map and register definitions sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2015.11.02 | Added note to "Watchdog Timer Counter" section. |
2015.05.04 | Maintenance release. |
2014.12.15 |
|
2014.06.30 |
|
2014.02.28 | Maintenance release. |
2013.12.30 |
Minor formatting updates. |
1.2 |
Minor updates. |
1.1 |
Added programming model and address map and register definitions sections. |
1.0 |
Initial release. |
Document Version |
Changes |
---|---|
2013.12.30 |
Maintenance release |
1.0 |
Maintenance release. |
0.1 |
Preliminary draft. |
Document Version |
Changes |
---|---|
2015.11.02 | Updated Sections:
|
2015.05.04 | Maintenance release. |
2014.12.15 | Maintenance release. |
2014.06.30 |
|
2014.02.28 |
|
1.2 |
Maintenance release. |
1.1 |
• Added debug interfaces • Added boot options • Corrected slave address width • Corrected SDRAM interface widths • Added TPIU peripheral • Added .sdc file generation • Added .tcl script for memory assignments |
1.0 |
Initial release. |
0.1 |
Preliminary draft. |
Document Version |
Changes |
---|---|
2015.05.04 |
|
2014.12.15 |
User Clock 2 has been removed |
2014.06.30 |
Added address map and register descriptions |
2014.02.28 |
Added sections:
Removed section:
Updated sections:
|
2013.12.30 |
Minor formatting issues |
1.1 |
|
1.0 |
Initial release. |
0.1 |
Preliminary draft. |
Document Version |
Changes |
---|---|
2016.05.03 | Removed references to FPGA to HPS SDRAM simulation. |
2015.11.02 | Maintenance release |
2015.05.04 | Maintenance release |
2014.12.15 | Maintenance release |
2014.11.14 |
|
2014.02.28 |
Added new sections:
Updated content in sections:
|
2013.12.30 | Maintenance release |
1.1 |
|
1.0 |
Initial release. |
0.1 |
Preliminary draft. |
Document Version |
Changes |
---|---|
2020.09.03 | Added information about where the HPS IO Configuration is contained in the Typical Preloader Boot Flow section. |
2018.07.17 |
|
2016.05.27 | Changed the name of the internal QSPI reference clock from qspi_clk to qspi_ref_clk; and the external QSPI output clock, from sclk_out to qspi_clk. |
2016.05.03 |
|
2015.11.02 | Maintenance Release |
2015.05.04 |
|
2014.12.15 |
|
2014.06.30 |
Maintenance release |
2014.02.28 | Correction to "Leading the Preloader" section |
2013.12.30 |
|
1.3 |
|
1.2 |
Updated the HPS boot and FPGA configuration sections. |
1.1 |
|
1.0 |
Initial release. |
2. Introduction to the Hard Processor System
The Arria® V 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.
The SoC features the FPGA I/O, which is I/O pins dedicated to the FPGA fabric.
- Microprocessor unit (MPU) subsystem with a dual Arm* Cortex®-A9 MPCore* processor
- Flash memory controllers
- SDRAM controller subsystem
- 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
- Control block (CB)
- 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. Pins are not freely shared between the HPS and the FPGA fabric. The HPS I/O pins are configured by boot software executed by the MPU in the HPS. Software executing on the HPS accesses control registers in the system manager to assign HPS I/O pins to the available HPS modules. The FPGA I/O pins are configured by an FPGA configuration image through the HPS or any external source supported by the device.
The MPU subsystem can boot from flash devices connected to the HPS pins. When the FPGA portion is configured by an external source, the MPU subsystem can boot from flash memory devices available to the FPGA portion of the device.
HPS | FPGA | Valid? |
---|---|---|
Off | Off | Yes |
Off | On | No |
On | Off | Yes |
On | On | Yes |
2.1. Features of the HPS
The main modules of the HPS are:
- MPU subsystem featuring a dual-core Arm* Cortex®-A9 MPCore processor
- General-purpose direct memory access (DMA) controller
- Two Ethernet media access controllers (EMACs)
- Two USB 2.0 on-the-go (OTG) controllers
- NAND flash controller
- Quad SPI flash controller
- Secure digital/multimedia card (SD/MMC) controller
- Two serial peripheral interface (SPI) master controllers
- Two SPI slave controllers
- Four inter-integrated circuit (I2C) controllers1
- 64 KB on-chip RAM
- 64 KB on-chip boot ROM
- Two UARTs
- Four 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
- Scan manager
- FPGA manager
- SDRAM controller subsystem
2.2. HPS Block Diagram and System Integration
2.2.1. HPS Block Diagram
2.2.2. Cortex-A9 MPCore
The MPU subsystem 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
- 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
- ACP ID mapper
- Maps the 12-bit ID from the level 3 (L3) interconnect to the 3-bit ID supported by the ACP
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 location
- 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. This lower–bandwidth interface is useful for accessing the control and status registers of soft peripherals
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
- FPGA clocks and resets
- HPS–to–FPGA JTAG—allows the HPS to master the FPGA JTAG chain
2.2.4. System Interconnect
The system interconnect consists of the main L3 interconnect and level 4 (L4) buses. The L3 interconnect is an Arm* NIC-301 module composed of the following switches:
- L3 main switch
- Connects the master, slaves, and other subswitches
- Provides 64-bit switching capabilities
- L3 master peripheral
switch
- Connects master ports of peripherals with integrated DMA controllers to the L3 main switch
- L3 slave peripheral
switch
- Connects slave ports of peripherals to the L3 main switch
2.2.4.1. SDRAM Controller Subsystem
HPS and FPGA fabric masters have access to the SDRAM controller subsystem.
The SDRAM controller subsystem implements the following high‑level features:
- Support for double data rate 2 (DDR2), DDR3, and low-power double data rate 2 (LPDDR2) devices
- 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 accesses
- FPGA fabric interface with up to six ports that can be combined for a data width up to 256-bits wide using Avalon-MM and AXI interfaces.
The SDRAM controller subsystem is composed of the SDRAM controller, DDR PHY, control and status registers and their associated interfaces.
2.2.4.1.1. SDRAM Controller
The SDRAM controller offers the following features:
- Up to 4 GB address range
- 8-, 16-, and 32-bit data widths
- Optional ECC support
- Low‑voltage 1.35V DDR3L and 1.2V DDR3U support
- Full memory device power management support
- Two chip selects (DDR2 and DDR3)
The SDRAM controller provides the following features to maximize memory performance:
- Command reordering (look-ahead bank management)
- Data reordering (out of order transactions)
- Priority arbitration and deficit round-robin arbitration for ports with the same priority
- High‑priority bypass for latency sensitive traffic
2.2.4.1.2. DDR PHY
The DDR PHY interfaces the single port memory controller to the HPS memory I/O.
2.2.5. On-Chip Memory
2.2.5.1. On-Chip RAM
The on-chip RAM offers the following features:
- 64 KB size
- 64-bit slave interface
- High performance for all burst lengths
2.2.5.2. Boot ROM
The boot ROM offers the following features:
- 64 KB size
- Contains the code required to support 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 one x8 NAND flash device
- Supports Open NAND Flash Interface (ONFI) 1.0
- Supports NAND flash memories from Hynix, Samsung, Toshiba, Micron, and ST Micro
- Supports programmable 512 byte (4-, 8-, or 16-bit correction) or 1024 byte (24-bit correction) ECC sector size
- Supports pipeline read-ahead and write commands for enhanced read/write throughput
- Supports devices with 32, 64, 128, 256, 384, or 512 pages per block
- Supports multiplane devices
- Supports page sizes of 512 bytes, 2 kilobytes (KB), 4 KB, or 8 KB
- Supports single-level cell (SLC) and multi-level cell (MLC) devices with programmable correction capabilities
- Provides internal DMA
- Provides programmable access timing
2.2.6.2. Quad SPI Flash Controller
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
- MMCPlus: 1-bit, 4-bit, and 8-bit data bus
- Default speed and high speed
- Supports embedded MMC
(eMMC) version 4.415
- 1-bit, 4-bit and 8-bit data bus
2.2.7. Support Peripherals
2.2.7.1. Clock Manager
The clock manager offers the following features:
- Manages clocks for HPS
- Supports dynamic clock tuning
2.2.7.2. Reset Manager
The reset manager manages both hardware and software reset sources in the HPS. Reset status is also provided. Reset types include cold, warm, and debug. Reset behavior depends on the type.
2.2.7.3. System Manager
- ECC monitoring and control
- Low-level control of peripheral features not accessible through the control and status registers (CSRs)
- Freeze controller that places I/O elements into a safe state for configuration
2.2.7.4. Scan Manager
The scan manager is used to configure and manage HPS I/O pins and to communicate with the FPGA JTAG.
2.2.7.5. Timers
- 32-bit timer resolution
- Free-running timer mode
- Supports a time-out period of up to 43 seconds when the timer clock frequency is 100 MHz
- Interrupt generation
2.2.7.6. 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)
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 31 peripheral handshake interfaces
- Software can schedule up to 16 outstanding read and 16 outstanding write instructions
- Supports nine interrupt lines: one for DMA thread abort and eight for external events
2.2.7.8. FPGA Manager
The FPGA manager offers the following features:
- Manages configuration of the FPGA portion of the device
- 32-bit fast passive parallel configuration interface to the FPGA CSS block
- Partial reconfiguration
- Compressed FPGA configuration images
- Advanced Encryption Standard (AES) encrypted FPGA configuration images
- Monitors configuration-related signals in FPGA
- Provides 32 general-purpose inputs and 32 general-purpose outputs to the FPGA fabric
2.2.8. Interface Peripherals
2.2.8.1. EMACs
The two EMACs are based on the Synopsys* DesignWare* 3504‑0 Universal 10/100/1000 Ethernet MAC and offer the following features:
- Supports 10, 100, and 1000 Mbps standard
- Supports RGMII external
PHY interface
- Media independent interface (MII)
- Gigabit media independent interface (GMII)
- Reduced gigabit media independent interface (RGMII)
- Serial gigabit media independent interface (SGMII) with additional external conversion logic
- Provides full GMII interface when using FPGA interface
- 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 VLAN tag detection for reception frames
- Supports a variety of address filtering modes
- Management of PHY through Management data input/output (MDIO) interface or optionally, I2C interface
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
The four I2C controllers are based on Synopsys* DesignWare* APB* I2C controller which offer the following features:
- Two controllers support I2C management interfaces for use by the EMAC controllers
- 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
2.2.8.5. SPI Master Controllers
- Choice of Motorola* SPI, Texas Instruments* Synchronous Serial Protocol or National Semiconductor* Microwire protocol
- Programmable data frame size from 4 bits to 16 bits
- Supports full- and half-duplex modes
- Supports up to four chip selects
- 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
2.2.8.6. SPI Slave Controllers
- Programmable data frame size from 4 bits to 16 bits
- Supports full- and half-duplex moces
- 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
The HPS provides three GPIO interfaces that are based on Synopsys* DesignWare* APB* General Purpose Programming I/O peripheral and offer the following features:
- Supports digital de-bounce
- Configurable interrupt mode
- Supports up to 71 I/O pins and 14 input-only pins, based on device variant
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.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.
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 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). For example, accesses to the ACP window in the L3 address space map to a 1 GB region of the MPU address space.
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”.
The ACP window can be mapped to any 1 GB region in the MPU address space (blue vertical bidirectional arrow), on gigabyte-aligned boundaries.
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‑HPS SDRAM interface from the FPGA fabric. The total amount of SDRAM addressable from the other address spaces can be configured at runtime.
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. 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 |
Space Trace Macrocell |
0xFC000000 |
48 MB |
DAP |
Debug Access Port |
0xFF000000 |
2 MB |
LWFPGASLAVES |
FPGA slaves accessed with lightweight HPS-to-FPGA bridge |
0xFF200000 |
2 MB |
LWHPS2FPGAREGS |
Lightweight HPS-to-FPGA bridge global programmer's view (GPV) registers |
0xFF400000 |
1 MB |
HPS2FPGAREGS |
HPS-to-FPGA bridge GPV registers |
0xFF500000 |
1 MB |
FPGA2HPSREGS |
FPGA-to-HPS bridge GPV registers |
0xFF600000 |
1 MB |
EMAC0 |
Ethernet MAC 0 |
0xFF700000 |
8 KB |
EMAC1 |
Ethernet MAC 1 |
0xFF702000 |
8 KB |
SDMMC |
SD/MMC |
0xFF704000 |
4 KB |
QSPIREGS |
Quad SPI flash controller registers |
0xFF705000 |
4 KB |
FPGAMGRREGS |
FPGA manager registers |
0xFF706000 |
4 KB |
ACPIDMAP |
ACP ID mapper registers |
0xFF707000 |
4 KB |
GPIO0 |
GPIO 0 |
0xFF708000 |
4 KB |
GPIO1 |
GPIO 1 |
0xFF709000 |
4 KB |
GPIO2 |
GPIO 2 |
0xFF70A000 |
4 KB |
L3REGS |
L3 interconnect GPV |
0xFF800000 |
1 MB |
NANDDATA |
NAND flash controller data |
0xFF900000 |
64 KB |
QSPIDATA |
Quad SPI flash data |
0xFFA00000 |
1 MB |
USB0 |
USB 2.0 OTG 0 controller registers |
0xFFB00000 |
256 KB |
USB1 |
USB 2.0 OTG 1 controller registers |
0xFFB40000 |
256 KB |
NANDREGS |
NAND flash controller registers |
0xFFB80000 |
64 KB |
FPGAMGRDATA |
FPGA manager configuration data |
0xFFB90000 |
4 KB |
UART0 |
UART 0 |
0xFFC02000 |
4 KB |
UART1 |
UART 1 |
0xFFC03000 |
4 KB |
I2C0 |
I2C controller 0 |
0xFFC04000 |
4 KB |
I2C1 |
I2C controller 1 |
0xFFC05000 |
4 KB |
I2C2 |
I2C controller 2 |
0xFFC06000 |
4 KB |
I2C3 |
I2C controller 3 |
0xFFC07000 |
4 KB |
SPTIMER0 |
SP Timer 0 |
0xFFC08000 |
4 KB |
SPTIMER1 |
SP Timer 1 |
0xFFC09000 |
4 KB |
SDRREGS |
SDRAM controller subsystem registers |
0xFFC20000 |
128 KB |
OSC1TIMER0 |
OSC1 Timer 0 |
0xFFD00000 |
4 KB |
OSC1TIMER1 |
OSC1 Timer 1 |
0xFFD01000 |
4 KB |
L4WD0 |
Watchdog Timer 0 |
0xFFD02000 |
4 KB |
L4WD1 |
Watchdog Timer 1 |
0xFFD03000 |
4 KB |
CLKMGR |
Clock manager |
0xFFD04000 |
4 KB |
RSTMGR |
Reset manager |
0xFFD05000 |
4 KB |
SYSMGR |
System manager |
0xFFD08000 |
16 KB |
DMANONSECURE |
DMA nonsecure registers |
0xFFE00000 |
4 KB |
DMASECURE |
DMA secure registers |
0xFFE01000 |
4 KB |
SPIS0 |
SPI slave 0 |
0xFFE02000 |
4 KB |
SPIS1 |
SPI slave 1 |
0xFFE03000 |
4 KB |
SPIM0 |
SPI master 0 |
0xFFF00000 |
4 KB |
SPIM1 |
SPI master 1 |
0xFFF01000 |
4 KB |
SCANMGR |
Scan manager registers |
0xFFF02000 |
4 KB |
ROM |
Boot ROM |
0xFFFD0000 |
64 KB |
MPU |
MPU registers |
0xFFFEC000 |
8 KB |
MPUL2 |
MPU L2 cache controller registers |
0xFFFEF000 |
4 KB |
OCRAM |
On-chip RAM |
0xFFFF0000 |
64 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 PLL
clock groups:
- PLL 0 (Main)—contains clocks for the Arm* Cortex®-A9 microprocessor unit (MPU) subsystem, level 3 (L3) interconnect, level 4 (L4) peripheral bus, and debug
- PLL 1 (Peripheral)—contains clocks for PLL-driven peripherals
- SDRAM—contains clocks for the SDRAM subsystem
- Allows scaling of the MPU subsystem clocks without disabling peripheral and SDRAM clock groups
- Generates clock gate controls for enabling and disabling most clocks
- Initializes and sequences
clocks for the following events:
- Cold reset
- Safe mode request from reset manager on warm reset
- Allows software to program
clock characteristics, such as the following items discussed later in this
chapter:
- Input clock source for SDRAM and peripheral PLLs
- Multiplier range, divider range, and six post-scale counters for each PLL
- Output phases for SDRAM PLL outputs
- VCO enable for each PLL
- Bypass modes for each PLL
- Gate off individual clocks in all PLL clock groups
- Clear loss of lock status for each PLL
- Safe 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
The following figure shows the major components of the clock manager and its integration in the HPS.
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 | 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.3. Functional Description of the Clock Manager
3.3.1. Clock Manager Building Blocks
3.3.1.1. PLLs
The clock manager contains three PLLs: PLL 0 (main), PLL 1 (peripherals), and SDRAM. These PLLs generate the majority of clocks in the HPS. There is no phase control between the clocks generated by the three PLLs.
Each PLL has the following features:
- Phase detector and output lock signal generation
- Registers to set VCO
frequency
- (M) Multiplier range is 1 to 4096
- (N) Divider range is 1 to 64
- Six post-scale counters (C0-C5) with a range of 1 to 512
- PLL can be enabled to bypass all outputs to the osc1_clk clock for glitch-free transitions
The SDRAM PLL has the following additional feature:
- Phase shift of 1/8 per
step
- Phase shift range is 0 to 7
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 × K) = FREF × M/ (Ci× K) = (FIN × M)/ (N × Ci × K)
Variable | Value | Description |
---|---|---|
FVC | = VCO frequency | - |
FIN | = Input frequency | - |
FREF | = Reference frequency | - |
Ci |
= Post-scale counter | i is 0-5 for each of the six counters |
K | = Internal post-scale counter in main PLL | reset values are K = 2 for C0 K=4 for C1 and C2 |
M | = numer + 1 | Part of clock feedback path. VCO register is used to program M value.
(Range 1 to 4096) |
N | = denom + 1 | Part of input clock path. VCO register is used to program N value.
(Range 0 to 64) |
The vco register is used to program the M and N values. In the table below you can see which sections of the vco bit field are used to set the values of M and N.
Name | Bit | Reset | Range | Description |
---|---|---|---|---|
numer | 3:15 | 0x1 | 0 to 4095 | Numerator in VCO output frequency equation. Note: Bit 15 reserved.
|
denom | 16:21 | 0x1 | 0 to 63 | Denominator in VCO output frequency equation. |
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. Dividers
Dividers subdivide the C0-C15 clocks produced by the PLL to lower frequencies. The main PLL C0-C2 clocks have an additional internal post-scale counter.
3.3.1.4. 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.1.5. Control and Status Registers
The Clock Manager contains registers used to configure and observe the clock manager.
3.3.2. Hardware-Managed and Software-Managed Clocks
When changing values on clocks, the terms hardware-managed and software-managed define who is responsible for successful transitions. Software-managed clocks require that software manually gate any clock affected by the change, wait for any PLL lock if required, then ungate the clocks. Hardware-managed clocks use hardware to ensure that a glitch-free transition to a new clock value occurs. There are three hardware-managed sets of clocks in the HPS, namely, clocks generated from the main PLL outputs C0, C1, and C2. All other clocks in the HPS are software-managed clocks.
3.3.3. Clock Groups
The clock manager contains one clock group for each PLL and one clock group for the HPS_CLK1 pin.
HPS_CLK1 and HPS_CLK2 are powered by the HPS reset and clock input pins power supply (VCCRSTCLK_HPS). For more information on VCCRSTCLK_HPS refer to the Arria V Device Datasheet.
3.3.3.1. OSC1 Clock Group
The clock in the OSC1 clock group is derived directly from the HPS_CLK1 pin. This clock is never gated or divided.
HPS_clk1 is used as a PLL input and also by HPS logic that does not operate on a clock output from a PLL.
Name |
Frequency |
Clock Source |
Destination |
---|---|---|---|
osc1_clk |
0 to 100 MHz |
HPS_CLK1 pin |
OSC1-driven peripherals. Refer to "Main Clock Group Clocks". |
3.3.3.2. Main Clock Group
The main clock group consists of a PLL, dividers, and clock gating. The clocks in the main clock group are derived from the main PLL. The main PLL is always sourced from the HPS_CLK1 pin of the device.
PLL |
Output Counter |
Clock Name |
Frequency |
Phase Shift Control |
---|---|---|---|---|
Main |
C0 |
mpu_base_clk |
osc1_clk to varies 7 |
No |
C1 |
main_base_clk |
osc1_clk to varies 7 |
No |
|
C2 |
dbg_base_clk |
osc1_clk/4 to mpu_base_clk/2 |
No |
|
C3 |
main_qspi_base_clk |
Up to 432 MHz |
No |
|
C4 |
main_nand_sdmmc_base_clk |
Up to 250 MHz for the NAND flash controller and up to 200 MHz for the SD/MMC controller |
No |
|
C5 |
cfg_h2f_user0_base_clk |
osc1_clk to 125 MHz for driving configuration and 100 MHz for the user clock |
No |
The counter outputs from the main PLL can have their frequency further divided by programmable dividers external to the PLL. Transitions to a different divide value occur on the fastest output clock, one clock cycle prior to the slowest clock’s rising edge. For example the clock transitions on cycle 15 of the divide‑by‑16 divider for the main C2 output and cycle 3 of the divide‑by‑4 divider for the main C0 output.
The following figure shows how each counter output from the main PLL can have its frequency further divided by programmable post‑PLL dividers. Green-colored clock gating logic is directly controlled by software writing to a register. Orange-colored clock gating logic is controlled by hardware. Orange-colored clock gating logic allows hardware to seamlessly transition a synchronous set of clocks, for example, all the MPU subsystem clocks.
The clocks derived from main PLL C0-C2 outputs are hardware-managed, meaning hardware ensures that a clean transition occurs, and can have the following control values changed dynamically by software write accesses to the control registers:
- PLL bypass
- PLL numerator, denominator, and counters
- External dividers
For these registers, hardware detects that the write has occurred and performs the correct sequence to ensure that a glitch-free transition to the new clock value occurs. These clocks can pause during the transition.
System Clock Name |
Frequency |
Constraints and Notes |
---|---|---|
mpu_clk |
Main PLL C0 |
Clock for MPU subsystem, including CPU0 and CPU1 |
mpu_l2_ram_clk |
mpu_clk/2 |
Clock for MPU level 2 (L2) RAM |
mpu_periph_clk |
mpu_clk/4 |
Clock for MPU snoop control unit (SCU) peripherals, such as the general interrupt controller (GIC) |
l3_main_clk |
Main PLL C1 |
Clock for L3 main switch |
l3_mp_clk |
l3_main_clk/2 |
Clock for L3 master peripherals (MP) switch |
l3_sp_clk |
l3_mp_clk or l3_mp_clk/2 |
Clock for L3 slave peripherals (SP) switch |
l4_main_clk |
Main PLL C1 |
Clock for L4 main bus |
l4_mp_clk |
osc1_clk/16 to 100 MHz divided from main PLL C1 or peripheral PLL C4 |
Clock for L4 MP bus |
l4_sp_clk |
osc1_clk/16 to 100 MHz divided from main PLL C1 or peripheral PLL C4 |
Clock for L4 SP bus |
dbg_at_clk |
osc1_clk/4 to main PLL C2/2 |
Clock for CoreSight™ debug trace bus |
dbg_trace_clk |
osc1_clk/16 to main PLL C2 |
Clock for CoreSight™ debug Trace Port Interface Unit (TPIU) |
dbg_timer_clk |
osc1_clk to main PLL C2 |
Clock for the trace timestamp generator |
dbg_clk8 |
dbg_at_clk/2 or dbg_at_clk/4 |
Clock for Debug Access Port (DAP) and debug peripheral bus |
main_qspi_clk |
Main PLL C3 |
Quad SPI flash internal logic clock |
main_nand_sdmmc_clk |
Main PLL C4 |
Input clock to flash controller clocks block |
cfg_clk |
osc1_clk to 100_MHz divided from main PLL C5 |
FPGA manager configuration clock |
h2f_user0_clock |
osc1_clk to 100_MHz divided from main PLL C5 |
Auxiliary user clock to the FPGA fabric |
3.3.3.2.1. Changing Values That Affect Main Clock Group PLL Lock
To change any value that affects the VCO lock of the main clock group PLL including the hardware-managed clocks, software must put the main PLL in bypass mode, which causes all the main PLL output clocks to be driven by the osc1_clk clock. Software must detect PLL lock by reading the lock status register prior to taking the main PLL out of bypass mode.
Once a PLL is locked, changes to any PLL VCO frequency that are 20 percent or less do not cause the PLL to lose lock. Iteratively changing the VCO frequency in increments of 20 percent or less allow a slow ramp of the VCO base frequency without loss of lock. For example, to change a VCO frequency by 40% without losing lock, change the frequency by 20%, then change it again by 16.7%.
3.3.3.3. Peripheral Clock Group
The peripheral clock group consists of a PLL, dividers, and clock gating. The clocks in the peripheral clock group are derived from the peripheral PLL. The peripheral PLL can be programmed to be sourced from the HPS_CLK1 pin, the HPS_CLK2 pin, or the f2h_periph_ref_clk clock provided by the FPGA fabric.
The FPGA fabric must be configured with an image that provides the f2h_periph_ref_clk before selecting it as the clock source. If the FPGA must be reconfigured and f2h_periph_ref_clk is being used by modules in the HPS, an alternate clock source must be selected prior to reconfiguring the FPGA.
Clocks that always use the peripheral PLL output clocks as the clocks source are:
- emac0_clk
- emac1_clk
- usb_mp_clk
- spi_m_clk
- gpio_db_clk
- h2f_user1_clk
In addition, clocks that may use the peripheral PLL output clocks as the clock source are:
- sdmmc_clk
- nand_clk
- qspi_clk
- l4_mp_clk
- l4_sp_clk
The counter outputs from the main PLL can have their frequency further divided by external dividers. Transitions to a different divide value occur on the fastest output clock, one clock cycle prior to the slowest clock’s rising edge. For example, the clock transitions on cycle 15 of the divide‑by‑16 divider for the main C2 output and cycle 3 of the divide‑by‑4 divider for the C1 output.
PLL |
Output Counter |
Clock Name |
Frequency |
Phase Shift Control |
---|---|---|---|---|
Peripheral |
C0 |
emac0_base_clk |
Up to 250 MHz |
No |
C1 |
emac1_base_clk |
Up to 250 MHz |
No |
|
C2 |
periph_qspi_base_clk |
Up to 432 MHz |
No |
|
C3 |
periph_nand_sdmmc_base_clk |
Up to 250 MHz for the NAND flash controller and up to 200 MHz for the SD/MMC controller |
No |
|
C4 |
periph_base_base_clk |
Up to 240 MHz for the SPI masters and up to 200 MHz for the scan manager |
No |
|
C5 |
h2f_user1_base_clk |
osc1_clk to 100 MHz |
No |
The following figure shows programmable post-PLL dividers and clock gating for the peripheral clock group. Clock gate blocks in the diagram indicate clocks that may be gated off under software control. Software is expected to gate these clocks off prior to changing any PLL or divider settings that might create incorrect behavior on these clocks.
System Clock Name |
Frequency |
Divided From |
Constraints and Notes |
---|---|---|---|
usb_mp_clk |
Up to 200 MHz |
Peripheral PLL C4 |
Clock for USB |
spi_m_clk |
Up to 240 MHz for the SPI masters and up to 200 MHz for the scan manager |
Peripheral PLL C4 |
Clock for L4 SPI master bus and scan manager |
emac0_clk |
Up to 250 MHz |
Peripheral PLL C0 |
EMAC0 clock. The 250 MHz clock is divided internally by the EMAC into the typical 125/25/2.5 MHz speeds for 1000/100/10 Mbps operation. |
emac1_clk |
Up to 250 MHz |
Peripheral PLL C1 |
EMAC1 clock The 250 MHz clock is divided internally by the EMAC into the typical 125/25/2.5 MHz speeds for 1000/100/10 Mbps operation. |
l4_mp_clk |
Up to 100 MHz |
Main PLL C1 or peripheral PLL C4 |
Clock for L4 master peripheral bus |
l4_sp_clk |
Up to 100 MHz |
Main PLL C1 or peripheral PLL C4 |
Clock for L4 slave peripheral bus |
gpio_db_clk |
Up to 1 MHz |
Peripheral PLL C4 |
Used to debounce GPIO0, GPIO1, and GPIO2 |
h2f_user1_clock |
Peripheral PLL C5 |
Peripheral PLL C5 |
Auxiliary user clock to the FPGA fabric |
3.3.3.3.1. Flash Controller Clocks
Flash memory peripherals can be driven by the main PLL, the peripheral PLL, or from clocks provided by the FPGA fabric.
System Clock Name |
Freq uency |
Divided From |
Constraints and Notes |
---|---|---|---|
qspi_clk |
Up to 432 MHz |
Peripheral PLL C2, main PLL C3, or f2h_periph_ref_clk |
Clock for quad SPI, typically 108 and 80 MHz |
nand_x_clk |
Up to 250 MHz |
Peripheral PLL C3, main PLL C4, or f2h_periph_ref_clk |
NAND flash controller master and slave clock |
nand_clk |
nand_x_clk/4 |
Peripheral PLL C3, main PLL C4, or f2h_periph_ref_clk |
Main clock for NAND flash controller, sets base frequency for NAND transactions |
sdmmc_clk |
Up to 200 MHz |
Peripheral PLL C3, main PLL C4, or f2h_periph_ref_clk |
|
3.3.3.3.2. SDRAM Clock Group
The SDRAM clock group consists of a PLL and clock gating. The clocks in the SDRAM clock group are derived from the SDRAM PLL. The SDRAM PLL can be programmed to be sourced from the HPS_CLK1 pin, the HPS_CLK2 pin, or the f2h_sdram_ref_clk clock provided by the FPGA fabric.
The FPGA fabric must be configured with an image that provides the f2h_sdram_ref_clk before selecting it as the clock source. If the FPGA must be reconfigured and the f2h_sdram_ref_clk is the clock source for the SDRAM clock group, an alternate clock source must be selected prior to reconfiguring the FPGA.
The counter outputs from the SDRAM PLL can be gated off directly under software control. The divider values for each clock are set by registers in the clock manager.
PLL | Output Counter | Clock Name | Frequency | Phase Shift Control |
---|---|---|---|---|
SDRAM | C0 |
ddr_dqs_base_clk |
Varies 9 |
Yes |
C1 |
ddr_2x_dqs_base_clk |
ddr_dqs_base_clk x 2 | Yes | |
C2 |
ddr_dq_base_clk |
ddr_dqs_base_clk | Yes | |
C5 |
h2f_user2_base_clk |
osc1_clk to varies9 | Yes |
The following figure shows clock gating for SDRAM PLL clock group. Clock gate blocks in the diagram indicate clocks which may be gated off under software control. Software is expected to gate these clocks off prior to changing any PLL or divider settings that might create incorrect behavior on these clocks.
The SDRAM PLL output clocks can be phase shifted in real time in increments of 1/8 the VCO frequency. Maximum number of phase shift increments is 4096.
Name |
Frequency |
Constraints and Notes |
---|---|---|
ddr_dqs_clk |
SDRAM PLL C0 |
Clock for MPFE, single-port controller, CSR access, and PHY |
ddr_2x_dqs_clk |
SDRAM PLL C1 |
Clock for PHY |
ddr_dq_clk |
SDRAM PLL C2 |
Clock for PHY |
h2f_user2_clock |
SDRAM PLL C5 |
Auxiliary user clock to the FPGA fabric |
3.3.4. Resets
3.3.4.1. Cold Reset
Cold reset places the hardware-managed clocks into safe mode, the software-managed clocks into their default state, and asynchronously resets all registers in the clock manager.
3.3.4.2. Warm Reset
Registers in the clock manager control how the clock manager responds to warm reset. Typically, software places the clock manager into a safe state in order to generate a known set of clocks for the ROM code to boot the system. The behavior of the system on warm reset as a whole, including how the FPGA fabric, boot code, and debug systems are configured to behave, must be carefully considered when choosing how the clock manager responds to warm reset.
The reset manager can request that the clock manager go into safe mode as part of the reset manager’s warm reset sequence. Before asserting safe mode to the clock manager, the reset manager ensures that the reset signal is asserted to all modules that receive warm reset.
3.3.5. Safe Mode
Safe mode is enabled in the HPS by a cold reset. Also, if the ensfmdwr bit in the ctrl register is set, clock manager responds to the Safe Mode request from Reset Manager on a warm reset and sets the Safe Mode bit. No other control register bits are affected by the safe mode request from the Reset Manager.
When safe mode is enabled, the main PLL hardware-managed clocks (C0-C2) are bypassed to osc1_clk clock and are directly generated from osc1_clk. While in safe mode, clock manager register settings, which control clock behavior, are not changed. However, the hardware bypasses these settings and uses safe, default settings.
The hardware-managed clocks are forced to their safe mode values such that the following conditions occur:
- The hardware-managed clocks are bypassed to osc1_clk, including counters in the main PLL.
- Programmable dividers select the reset default values.
- The flash controller clocks multiplexer selects the output from the peripheral PLL.
- All clocks are enabled.
A write by software is the only way to clear the safe mode bit (safemode) of the ctrl register.
3.3.6. Interrupts
The clock manager provides one interrupt output which is enabled using the interrupt enable register (intren). The interrupt is the OR of the bits in the interrupt status register (inter) that indicate lock and loss of lock for each of the three PLLs.
3.3.7. Clock Usage By Module
The following table lists every clock input generated by the clock manager to all modules in the HPS. System clock names are global for the entire HPS and system clocks with the same name are phase-aligned at all endpoints.
Module Name |
System Clock Name |
Use |
---|---|---|
MPU subsystem |
mpu_clk |
Main clock for the MPU subsystem |
mpu_periph_clk |
Peripherals inside the MPU subsystem |
|
dbg_at_clk |
Trace bus |
|
dbg_clk |
Debug |
|
mpu_l2_ram_clk |
L2 cache and Accelerator Coherency Port (ACP) ID mapper |
|
l4_mp_clk |
ACP ID mapper control slave |
|
Interconnect |
l3_main_clk |
L3 main switch |
dbg_at_clk |
System Trace Macrocell (STM) slave and Embedded Trace Router (ETR) master connections |
|
dbg_clk |
DAP master connection |
|
l3_mp_clk |
L3 master peripheral switch |
|
l4_mp_clk |
L4 MP bus, Secure Digital (SD) / MultiMediaCard (MMC) master, and EMAC masters |
|
usb_mp_clk |
USB masters and slaves |
|
nand_x_clk |
NAND master |
|
cfg_clk |
FPGA manager configuration data slave |
|
l3_sp_clk |
L3 slave peripheral switch |
|
l3_main_clk |
L4 SPIS bus master |
|
mpu_l2_ram_clk |
ACP ID mapper slave and L2 master connections |
|
osc1_clk |
L4 OSC1 bus master |
|
spi_m_clk |
L4 SPIM bus master |
|
l4_sp_clk |
L4 SP bus master |
|
l4_mp_clk |
Quad SPI bus slave |
|
Boot ROM |
l3_main_clk |
Boot ROM |
On-chip RAM |
l3_main_clk |
On-chip RAM |
DMA controller |
l4_main_clk |
DMA |
dbg_at_clk |
Synchronous to the STM module |
|
l4_mp_clk |
Synchronous to the quad SPI flash |
|
FPGA manager |
cfg_clk |
Control block (CB) data interface and configuration data slave |
l4_mp_clk |
Control slave |
|
HPS‑to‑FPGA bridge |
l3_main_clk |
Data slave |
l4_mp_clk |
Global programmer's view (GPV) slave |
|
FPGA‑to‑HPS bridge |
l3_main_clk |
Data master |
l4_mp_clk |
GPV slave |
|
Lightweight HPS‑to‑FPGA bridge |
l4_mp_clk |
GPV masters and the data and GPV slave |
Quad SPI flash controller |
l4_mp_clk |
Control slave |
qspi_clk |
Reference for serialization |
|
SD/MMC controller |
l4_mp_clk |
Master and slave |
sdmmc_clk |
SD/MMC internal logic |
|
EMAC 0 |
l4_mp_clk |
Master |
emac0_clk |
EMAC 0 internal logic |
|
osc1_clk |
IEEE 1588 timestamp |
|
EMAC 1 |
l4_mp_clk |
Master |
emac1_clk |
EMAC 1 internal logic |
|
osc1_clk |
IEEE 1588 timestamp |
|
USB 0 |
usb_mp_clk |
Master and Slave |
USB 1 |
usb_mp_clk |
Master and Slave |
NAND flash controller |
nand_x_clk |
NAND high-speed master and slave |
nand_clk |
NAND flash |
|
OSC1 timer 0 |
osc1_clk |
OSC1 timer 0 |
OSC1 timer 1 |
osc1_clk |
OSC1 timer 1 |
SP timer 0 |
l4_sp_clk |
SP timer 0 |
SP timer 1 |
l4_sp_clk |
SP timer 1 |
I2C controller 0 |
l4_sp_clk |
I2C 0 |
I2C controller 1 |
l4_sp_clk |
I2C 1 |
I2C controller 2 |
l4_sp_clk |
I2C 2 |
I2C controller 3 |
l4_sp_clk |
I2C 3 |
UART controller 0 |
l4_sp_clk |
UART 0 |
UART controller 1 |
l4_sp_clk |
UART 1 |
GPIO interface 0 |
l4_mp_clk |
Slave |
gpio_db_clk |
Debounce |
|
GPIO interface 1 |
l4_mp_clk |
Slave |
gpio_db_clk |
Debounce |
|
GPIO interface 2 |
l4_mp_clk |
Slave |
gpio_db_clk |
Debounce |
|
System manager |
osc1_clk |
System manager |
SDRAM subsystem |
l4_sp_clk |
Control slave |
ddr_dq_clk |
Off-chip data |
|
ddr_dqs_clk |
MPFE, single-port controller, CSRs, and PHY |
|
ddr_2x_dqs_clk |
Off-chip strobe data |
|
mpu_l2_ram_clk |
Slave connected to MPU subsystem L2 cache |
|
l3_main_clk |
Slave connected to L3 interconnect |
|
L4 watchdog timer 0 |
osc1_clk |
L4 watchdog timer 0 |
L4 watchdog timer 1 |
osc1_clk |
L4 watchdog timer 1 |
SPI master controller 0 |
spi_m_clk |
SPI master 0 |
SPI master controller 1 |
spi_m_clk |
SPI master 1 |
SPI slave controller 0 |
l4_main_clk |
SPI slave 0 |
SPI slave controller 1 |
l4_main_clk |
SPI slave 1 |
Debug subsystem |
l4_mp_clk |
System bus |
dbg_clk |
Debug |
|
dbg_at_clk |
Trace bus |
|
dbg_trace_clk |
Trace port |
|
Reset manager |
osc1_clk |
Reset manager |
l4_sp_clk |
Slave |
|
Scan manager |
spi_m_clk |
Scan manager |
Timestamp generator |
dbg_timer_clk |
Timestamp generator |
3.4. Clock Manager Address Map and Register Definitions
The address map and register definitions for the HPS-FPGA bridge consist of the following regions:
- Clock Manager Module
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.
Domain Name |
Domain Logic |
---|---|
TAP |
JTAG test access port (TAP) controller, which is used by the debug access port (DAP). |
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. |
System |
All HPS logic except what is in the TAP and debug reset domains. Includes non-debug logic in the FPGA fabric connected to the HPS reset signals. |
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
- Occurs after HPS has already completed a cold reset
- 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
- Debug reset
- Used to recover debug logic from a non-responsive condition
- Only affects the debug reset domain
4.1. Reset Manager Block Diagram and System Integration
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. HPS External Reset Sources
The following table lists the reset sources external to the HPS. All signals are synchronous to the osc1_clk clock. The reset signals from the HPS to the FPGA fabric must be synchronized to your user logic clock domain.
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) |
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) |
load_csr |
Cold-only reset from FPGA control block (CB) and scan manager |
nPOR |
Power-on reset pin (active low) |
nRST |
Warm reset pin (active low) |
nRST and nPOR are powered by the HPS reset and clock input pins power supply (VCCRSTCLK_HPS). For more information on VCCRSTCLK_HPS, refer to the Arria V Device Datasheet.
4.1.2. Reset Controller
The reset controller performs the following functions:
- Accepts reset requests from the FPGA 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:
- Power-on reset (POR) voltage monitor
- Cold reset request pin (nPOR)
- FPGA fabric
- FPGA CB and scan manager
- 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.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 | ||
mpu_l2_rst_n |
Level 2 (L2) cache reset |
System |
X | X |
Module Reset Signal |
Description |
Reset Domain |
Cold Reset |
Warm Reset |
Debug Reset |
Software Deassert |
---|---|---|---|---|---|---|
emac_rst_n[1:0] |
Resets each EMAC |
System |
X |
X |
X | |
usb_rst_n[1:0] |
Resets each 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 | |
watchdog_rst_n[1:0] |
Resets each system watchdog timer |
System |
X |
X |
X | |
osc1_timer_rst_n[1:0] |
Resets each OSC1 timer |
System |
X |
X |
X | |
sp_timer_rst_n[1:0] |
Resets each SP timer |
System |
X |
X |
X | |
i2c_rst_n[3:0] |
Resets each I2C controller |
System |
X |
X |
X | |
uart_rst_n[1:0] |
Resets each UART |
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 | |
gpio_rst_n[2:0] |
Resets each GPIO interface |
System |
X |
X |
X | |
dma_rst_n |
Resets DMA controller |
System |
X |
X |
X | |
sdram_rst_n |
Resets SDRAM subsystem (resets logic associated with cold or warm reset) |
System |
X |
X |
X |
Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|
dma_periph_if_rst_n[7:0] | DMA controller request interface from FPGA fabric to DMA controller | System | X | 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 |
Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|
boot_rom_rst_n | Resets boot ROM | System | X | X | ||
onchip_ram_rst_n | Resets on-chip RAM | System | X | X | ||
sys_manager_rst_n | Resets system manager (resets logic associated with cold or warm reset) | System | X | X | ||
sys_manager_cold_rst_n | Resets system manager (resets logic associated with cold reset only) | System | X | |||
fpga_manager_rst_n | Resets FPGA manager | System | X | X | ||
acp_id_mapper_rst_n | Resets ACP ID mapper | System | X | X | ||
h2f_rst_n | Resets user logic in FPGA fabric (resets logic associated with cold or warm reset) | System | X | X | ||
h2f_cold_rst_n | Resets user logic in FPGA fabric (resets logic associated with cold reset only) | System | X | |||
rst_pin_rst_n | Pulls nRST pin low | System | 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 | |||
scan_manager_rst_n | Resets scan manager | System | X | X | ||
frz_ctrl_cold_rst_n | Resets freeze controller (resets logic associated with cold reset only) | System | X | |||
sys_dbg_rst_n | Resets debug masters and slaves connected to L3 interconnect and level 4 (L4) buses | System | X | X | ||
dbg_rst_n | Resets debug components including DAP, trace, MPU debug logic, and any user debug logic in the FPGA fabric | Debug | X | X | ||
tap_cold_rst_n | Resets portion of TAP controller in the DAP that must be reset on a cold reset | TAP | X | |||
sdram_cold_rst_n | Resets SDRAM subsystem (resets logic associated with cold reset only) | System | X |
Module Reset Signal | Description | Reset Domain | Cold Reset | Warm Reset | Debug Reset | Software Deassert |
---|---|---|---|---|---|---|
l3_rst_n | 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 |
Ethernet MAC | permodrst | emac_rst_n[1:0] | PER |
USB 2.0 OTG | permodrst | usb_rst_n[1:0] | PER |
NAND | permodrst | nand_flash_rst_n | PER |
Quad SPI | permodrst | qspi_flash_rst_n | PER |
Watchdog | permodrst | watchdog_rst_n[1:0] | PER |
Timer | permodrst | osc1_timer_rst_n[1:0] | PER |
Timer | permodrst | sp_timer_rst_n[1:0] | PER |
I2C | permodrst | i2c_rst_n[3:0] | PER |
UART | permodrst | uart_rst_n[1:0] | PER |
SPI Master | permodrst | spim_rst_n[1:0] | PER |
SPI Slave | permodrst | spis_rst_n[1:0] | PER |
SD/MMC | permodrst | sdmmc_rst_n | PER |
GPIO | permodrst | gpio_rst_n[2:0] | PER |
DMA | permodrst | dma_rst_n | PER |
SDRAM | permodrst | sdram_rst_n | PER |
DMA Peripheral Interfaces | per2modrst | dma_periph_if_rst_n[7:0] | PER2 |
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 |
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 "Shared Memory" 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, permodrst, per2modrst, brgmodrst, or miscmodrst 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.
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 osc1_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 safe mode request to the clock manager to put the clock manager in safe mode, which creates a fixed and known relationship between the osc1_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 the MPU Group and Generated Module Resets table. Software deasserts resets by writing the mpumodrst, permodrst, per2modrst, brgmodrst, and miscmodrst 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 safe 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 |
6 osc1_clk cycles |
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 module resets
- Wait for 32 cycles. Deassert clock manager cold reset.
- Wait for 96 cycles (so clocks can stabilize).
- Proceed to the “Cold and Warm Reset Deassertion Sequence” section using the following link.
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:
- Optionally, handshake with the embedded trace router (ETR) and wait for acknowledge.
- Optionally, handshake with the FPGA fabric and wait for acknowledge.
- Optionally, handshake with the SDRAM controller, scan manager, and FPGA manager, and wait for acknowledges.
- Assert module resets (except the MPU watchdog timer resets when the MPU watchdog timers are the only request sources).
- Wait for 8 cycles and send a safe mode request to the clock manager.
- Wait for the greater of the nRST pin count + 256 stretch count, or the warm reset counter, or the clock manager safe mode acknowledge, then deassert all handshakes except warm reset ETR handshake (which is deasserted by software).
- Proceed to the “Cold and Warm Reset Deassertion Sequence” section using the following link.
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:
- Deassert L3 reset.
- Wait for 100 cycles. Deassert resets for miscellaneous-type and debug (cold only) modules.
- Wait for 200 cycles. Assert mpu_clkoff for CPU0 and CPU1.
- Wait for 32 cycles. Deassert resets for MPU modules.
- Wait for 32 cycles. Deassert mpu_clkoff for CPU0 and CPU1.
- Peripherals remain held in reset until software brings them out of reset.
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 open drain output as well. A warm reset 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). 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:
- The TAP reset domain ignores warm reset.
- The debug reset domain ignores warm reset.
- System reset domain cold resets ignore warm reset.
- Each module defines reset behavior individually.
4.2.4. Altering Warm Reset System Response
Registers in the clock manager, system manager, and reset manager control how warm reset affects the HPS. You can control the impact of a warm reset on the clocks and I/O elements.
Intel strongly recommends using provided libraries to configure and control this functionality.
The default warm reset behavior takes all clocks and I/O elements through a cold reset response. As your software becomes more stable or for debug purposes, you can alter the system response to a warm reset. The following suggestions provide ways to alter the system response to a warm reset. None of the register bits that control these items are affected by warm reset.
- Boot from on‑chip RAM—enables warm boot from on‑chip RAM instead of the boot ROM. When enabled, the boot ROM code validates the RAM code and jumps to it, making no changes to clocks or any other system settings prior to executing user code from on‑chip RAM.
- Disable safe mode on warm reset—allows software to transition through a warm reset without affecting the clocks. Because the boot ROM code indirectly configures the clock settings after warm reset, Intel recommends that safe mode should only be disabled when the HPS is not booting from a flash device.
- Disable safe mode on warm reset for the debug clocks—keeps the debug clocks from being affected by the assertion of safe mode request on a warm reset. This technique allows fast debug clocks, such as trace, to continue running through a warm reset. When enabled, the clock manager configures the debug clocks to their safe frequencies to respond to a safe mode request from the reset manager on a warm reset. Disable safe mode on warm reset for the debug clocks only when you are running the debug clocks off the main PLL VCO and you are certain the main PLL cannot be impacted by the event which caused the warm reset.
- Use the osc1_clk clock for debug control—keeps the debug base clock (main PLL C2 output) always bypassed to the osc1_clk external clock, independent of other clock manager settings. When implemented, disabling safe mode on warm reset for the debug clocks has no effect.
4.2.5. 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
- Scan manager stops generating JTAG and I/O configuration clocks
- 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
The address map and register definitions for the HPS-FPGA bridge consist of the following regions:
- Reset Manager Module
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 of the FPGA portion of the SoC device
- Drives 32 general-purpose output signals to the FPGA fabric
- Receives 32 general-purpose input signals from the FPGA fabric
- Receives two boot handshaking input signals from the FPGA fabric (used when the HPS boots from the FPGA)
- Monitors the FPGA configuration and power status
- Generates interrupts based on the FPGA status changes
- Can reset the FPGA
5.2. FPGA Manager Block Diagram and System Integration
The register slave interface connects to the level 4 (L4) master peripheral bus for control and status register (CSR) access. The configuration slave interface connects to the level 3 (L3) interconnect for the microprocessor unit (MPU) subsystem or other masters to write the FPGA configuration image to the FPGA control block (CB) when configuring the FPGA portion of the SoC device.
The general-purpose I/O and boot handshake input interfaces connect to the FPGA fabric. The FPGA manager also connects to the FPGA CB signals to monitor and control the FPGA portion of the device.
The FPGA manager consists of the following blocks:
- Configuration slave interface—accepts and transfers the configuration image to the data interface.
- Register slave interface—accesses the CSRs in the FPGA manager.
- Data—accepts the FPGA configuration image from the configuration slave interface and sends it to the FPGA CB.
- Control—controls the FPGA CB.
- Monitor—monitors the configuration signals in the FPGA CB and sends interrupts to the MPU subsystem.
- Fabric I/O—reads and writes signals from or to the FPGA fabric.
5.3. Functional Description of the FPGA Manager
5.3.1. FPGA Manager Building Blocks
The FPGA manager has the two blocks - fabric I/O and monitor.
5.3.1.1. Fabric I/O
The fabric I/O block contains the following registers to allow simple low-latency communication between the HPS and the FPGA fabric:
- General-purpose input register (gpi)
- General-purpose output register (gpo)
- Boot handshaking input register (misci)
These registers are only valid when the FPGA is in user mode. Reading from these registers while the FPGA is not in user mode provides undefined data.
The 32 general-purpose input signals from the FPGA fabric are read by reading the gpi register using the register slave interface. The 32 general-purpose output signals to the FPGA fabric are generated from writes to the gpo register. For more information about FPGA manager registers, refer to FPGA Manager Address Map and Register Definitions.
The boot handshake input signals from the FPGA fabric are read by reading the misci register. The f2h_boot_from_fpga_ready signal indicates that the FPGA fabric is ready to send preloader information to the boot ROM. The f2h_boot_from_fpga_on_failure signal serves as a fallback in the event that the boot ROM code fails to boot from the primary boot flash device. In this case, the boot ROM code checks these two handshaking signals to determine if it should use the boot code hosted in the FPGA memory as the next stage in the boot process.
There is no interrupt support for this block.
5.3.1.2. Monitor
The monitor block is an instance of the Synopsys* GPIO IP (DW_apb_gpio), which is a separate instance of the IP that comprises the three HPS GPIO interfaces. The monitor block connects to the configuration signals in the FPGA. This block monitors key signals related to FPGA configuration such as INIT_DON E, CRC_ERROR, and PR_DONE. Software configures the monitor block through the register slave interface, and can either poll FPGA signals or be interrupted. The mon address map within the FPGA manager register address map contains the monitor registers. For more information about FPGA manager registers, refer to FPGA Manager Address Map and Register Definitions
You can program the FPGA manager to treat any of the monitor signals as interrupt sources. Independent of the interrupt source type, the monitor block always drives an active-high level interrupt to the MPU. Each interrupt source can be of the following types:
- Active-high level
- Active-low level
- Rising edge
- Falling edge
5.3.2. 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 CB uses the FPGA mode select (MSEL) pins to determine which configuration scheme to use. The MSEL pins must be tied to the appropriate values for the configuration scheme. The table below lists supported MSEL values when the FPGA is configured by the HPS.
Configuration Scheme |
Compression Feature |
Design Security Feature |
POR Delay10 |
MSEL[4..0] 11 |
cfgwdth |
cdratio |
Supports Partial Reconfiguration |
---|---|---|---|---|---|---|---|
FPP ×16 |
Disabled |
AES Disabled |
Fast |
00000 |
0 |
1 |
Yes |
Standard |
00100 |
0 |
1 |
Yes |
|||
Disabled |
AES Enabled |
Fast |
00001 |
0 |
2 |
Yes |
|
Standard |
00101 |
0 |
2 |
Yes |
|||
Enabled |
Optional |
Fast |
00010 |
0 |
4 |
Yes |
|
Standard |
00110 |
0 |
4 |
Yes |
|||
FPP ×3213 |
Disabled |
AES Disabled |
Fast |
01000 |
1 |
1 |
No |
Standard |
01100 |
1 |
1 |
No |
|||
Disabled |
AES Enabled |
Fast |
01001 |
1 |
4 |
No |
|
Standard |
01101 |
1 |
4 |
No |
|||
Enabled |
Optional12 |
Fast |
01010 |
1 |
8 |
No |
|
Standard |
01110 |
1 |
8 |
No |
HPS software sets the clock-to-data ratio field (cdratio) and configuration data width bit (cfgwdth) in the control register (ctrl) to match the MSEL pins. The cdratio field and cfgwdth bit must be set before the start of configuration.
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
- FPGA I/O configuration, followed by PCI Express® (PCIe®) configuration of the remainder of FPGA
- External single event upset (SEU) scrubbing
- Decompression
- Advanced Encryption Standard (AES) encryption
- FPGA DCLK clock used for initialization phase clock
Configuring the FPGA portion of the SoC device comprises the following phases:
- Power up phase
- Reset phase
- Configuration phase
- Initialization phase
- User mode
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. The L4 interconnect allocates a 4 KB region for image data. It is not necessary to increment the address when writing the image data because all accesses within the 4 KB image data region is transferred to the configuration logic.
5.3.2.1. Power Up Phase
In this phase, the VCC is ramping up and has yet to reach normal levels. This phase completes when the on-chip voltage detector determines that the VCC has reached normal levels.
5.3.2.2. Reset Phase
The FPGA manager resets the FPGA portion of the SoC device when the FPGA configuration signal (nCONFIG) is driven low. The HPS configures the FPGA by writing a 1 to the nconfigpull bit of the ctrl register. This action causes the FPGA portion of the device to reset and perform the following actions:
- Clear the FPGA configuration RAM bits
- Tri-state all FPGA user I/O pins
- Pull the nSTATUS and CONF_DONE pins low
- Use the FPGA CB to read the values of the MSEL pins to determine the configuration scheme
The nconfigpull bit of the ctrl register needs to be set to 0 when the FPGA has successfully entered the reset phase. Setting the bit releases the FPGA from the reset phase and transitions to the configuration phase.
5.3.2.3. Configuration Phase
To configure the FPGA using the HPS, software sets the axicfgen bit of the ctrl register to 1. Software then sends configuration data to the FPGA by writing data to the write data register (data) in the FPGA manager module configuration data address map. Software polls the CONF_DONE pin by reading the gpio_instatus register to determine if the FPGA configuration is successful. When configuration is successful, software sets the axicfgen bit of the ctrl register to 0. The FPGA user I/O pins are still tri-stated in this phase.
After successfully completing the configuration phase, the FPGA transitions to the initialization phase. To delay configuring the FPGA, set the confdonepull bit of the ctrl register to 1.
5.3.2.4. Initialization Phase
In this phase, the FPGA prepares to enter user mode. The internal oscillator in the FPGA portion of the device is the default clock source for the initialization phase. Alternatively, the configuration image can specify the CLKUSR or the DCLK pins as the clock source. The alternate clock source controls when the FPGA enters user mode.
If DCLK is selected as the clock source, software uses the DCLK count (dclkcnt) register to drive DCLK pulses to the FPGA. Writing to the cnt field of the dclkcnt register triggers the FPGA manager to generate the specified number of DCLK pulses. When all of the DCLK pulses have been sent, the dcntdone bit of the DCLK status (dclkstat) register is set to 1. Software polls the dcntdone bit to know when all of the DCLK pulses have been sent.
The FPGA user I/O pins are still tri-stated in this phase. When the initialization phase completes, the FPGA releases the optional INIT_DONE pin and an external resistor pulls the pin high.
5.3.2.5. User Mode
The FPGA enters the user mode after exiting the initialization phase. The FPGA user I/O pins are no longer tri-stated in this phase and the configured soft logic in the FPGA becomes active.
The FPGA remains in user mode until the nCONFIG pin is driven low. If the nCONFIG pin is driven low, the FPGA reenters the reset phase. The internal oscillator is disabled in user mode, but is enabled as soon as the nCONFIG pin is driven low.
5.3.3. FPGA Status
Configuration signals from the FPGA CB 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.4. 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.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 preloader image is available in the FPGA on-chip RAM at memory location 0x0. The fallback preloader image is used only if the HPS boot ROM does not find a valid preloader image in the selected flash memory device. It is an active high signal which the bootrom polls when all the preloaders fail to load. This signal is driven low when the FPGA is not configured and it is up to you to drive it high in your user design. |
f2h_boot_from_fpga_ready |
Indicates a preloader image is available in an FPGA on-chip RAM at memory location 0x0 and it is ready to be accessed. It is an active high signal which the bootrom polls to determine when the FPGA is configured and the memory located at offset 0x0 from the F2H bridge is ready to be written to. When the FPGA is not configured the hardware drives this signal low and it is up to you to drive it high when the memory in the FPGA is ready to accept memory mapped transactions. |
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
The address map and register definitions for the FPGA Manager consist of the following regions:
- FPGA Manager Module
- FPGA Manager Module Configuration Data
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 and EMAC1)
- 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 level 3 (L3) master signal options.
- Freezes the I/O pins after the HPS comes out of cold reset and during serial configuration.
- Selects the SD/MMC controller clock options and L3 master signal options.
- Selects the NAND flash controller bootstrap options and L3 master signal options.
- Selects USB controller L3 master signal options.
- Provides control over the DMA security settings when the HPS exits from reset.
- Provides boot source and clock source information that can be read during the boot process.
- Provides the capability to enable or disable an interface to the FPGA.
- Routes parity failure interrupts from the L1 caches to the Global Interrupt Controller.
- Sends error correction code (ECC) enable signals to all HPS modules with ECC-protected RAM.
- 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 the BSEL pins.
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.
When CPU1 is released from reset and the boot ROM code is located at the CPU1 reset exception address (for a typical case), the boot ROM reset handler code reads the address stored in the CPU1 start address register (cpu1startaddr) and passes control to software at that address.
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 offset |
Contains a 16-bit offset into the on-chip RAM that the boot code jumps to if the CRC validation succeeds. The boot ROM appends 0xFFFF to the upper 16-bits of this 32-bit register value when it is read. |
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. L3 Interconnect
The System Manager provides remap bits to the L3 interconnect. These bits can remap the Boot ROM and the On-chip RAM.
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 enable or disable ECC for 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 and EMAC1) 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
The address map and register definitions for the HPS-FPGA bridges consist of the following regions:
- System Manager Module
7. Scan Manager
The scan manager is used to configure and manage the HPS I/O pins, and communicate with the FPGA JTAG test access port (TAP) controller. The scan manager drives the HPS I/O scan chains to configure the I/O bank properties before the pins are used by the peripherals in HPS. The scan manager can also optionally communicate with the FPGA JTAG TAP controller to send commands for purposes such as managing cyclic redundancy check (CRC) errors detected by the FPGA control block. When the scan manager communicates with the FPGA JTAG TAP controller, input on the FPGA JTAG pins is ignored.
The scan manager contains an Arm* JTAG Access Port (JTAG-AP). The JTAG-AP implements a multiple scan-chain JTAG master interface. One scan chain connects to the FPGA JTAG and uses the standard JTAG signals. Four other scan chains connect to the HPS I/O banks, using the JTAG clock and data outputs as a parallel-to-serial converter.
7.1. Features of the Scan Manager
- Drives all the I/O scan chains for HPS I/O banks
- Allows the HPS to access the FPGA JTAG TAP controller
7.2. Scan Manager Block Diagram and System Integration
The processor accesses the scan manager through the register slave interface connected to the level 4 (L4) peripheral bus.
7.2.1. Arm JTAG-AP Signal Use in the Scan Manager
Signal |
Direction |
Implementation |
---|---|---|
SRSTCONNECTED[7:0] |
Input |
Tied to 0. The read-only SRSTCONNECTED field in the CSW register always reads as 0. |
PORTCONNECTED[7:0] |
Input |
Tied to 0x8F, which connects only ports 0-3 and 7. The read-only PORTCONNECTED field in the CSW register reads as 1 when the PORTSEL register is written with a value that enables one of the connected ports, and reads as 0 otherwise. |
PORTENABLED[7:0] |
Input |
Tied to 0x8F, so all connected ports are always considered powered on. The Arm* JTAG AP PSTA register is not supported. Software does not need to monitor the status of ports 0-3 because they are always on. For port 7, software can read the mode field of the stat register in the FPGA manager to determine the FPGA power status. |
nSRSTOUT[7:0] |
Output |
Not connected. Writing to the SRST_OUT field of the CSW register has no effect. |
nTRST*[7:0] |
Output |
nTRST*[7] is connected to the FPGA JTAG TAP controller and nTRST*[6:0] are not connected. Writing to the TRST_OUT field of the CSW register (the trst bit of the stat register in the scan manager) has an effect only when port 7 is enabled by software. For details, refer to “Communicating with the JTAG TAP Controller". |
7.2.2. Arm JTAG-AP Scan Chains
Scan chain 7 of the JTAG-AP connects to FPGA JTAG TAP controller. When the system manager undergoes a cold reset, this connection is disabled and the FPGA JTAG pins are connected to the FPGA JTAG TAP controller. You can configure the system manager to enable the connection, which allows software running on the HPS to communicate with the FPGA JTAG TAP controller. In this case, software can send JTAG commands (such as the SHIFT_EDERROR_REG JTAG instruction) to the FPGA JTAG and get responses to determine details about CRC errors detected by the control block when the FPGA fabric is in user mode. Through the FPGA manager, software can determine that a CRC error was detected. For more information about the TAP controller, refer to the Communicating with the JTAG TAP Controller section of this chapter.
Scan chains 0 to 3 of the JTAG-AP connect to the configuration information in the HPS I/O scan chain banks through the I/O configuration shift register (IOCSR) multiplexer. For more information, refer to the Configuring HPS I/O Scan Chains section of this chapter.
The HPS I/O pins are divided into six banks. Each I/O bank is either a vertical (VIO) or horizontal (HIO) I/O, based on its location on the die.
IOCSR Scan Chain |
Bank Type |
HPS I/O Bank |
Usage |
---|---|---|---|
0 |
VIO |
I/O bank 7D and I/O bank 7E |
EMAC |
1 |
VIO |
I/O bank 7B and I/O bank 7C |
SD/MMC, NAND, and quad SPI |
2 |
VIO |
I/O bank 7A |
Trace, SPI, UART, and I2C |
3 |
HIO |
I/O bank 6 |
SDRAM DDR |
When the FPGA JTAG TAP controller is in CONFIG_IO mode, the controller can override the scan manager JTAG-AP and configure the HPS I/O pins. For more information, refer to the Configuring HPS I/O Scan Chains section of this chapter.
- DDR SDRAM
- OSC1/2
- Warm/Cold reset
7.3. Functional Description of the Scan Manager
The scan manager serves the following purposes:
- Configuring HPS I/O scan chains
- Communicating with the JTAG TAP controller
7.3.1. Configuring HPS I/O Scan Chains
The HPS I/O pins are configured through a series of scan chains.
I/O pin configuration involves such steps as setting the I/O standard and drive strength for each I/O bank. After a cold reset, all the I/O scan chains in the HPS must be configured prior to being used to communicate with external devices.
Software uses the scan manager to write configuration data to the scan chains. Separate I/O configuration data files for FPGA and HPS are generated by the Quartus® Prime software when the configuration image for the FPGA portion of the system-on-a-chip (SoC) device is assembled. The HPS configuration data is written to the scan manager by software.
Before configuring a specific I/O bank, the corresponding scan chain must be enabled by writing to the bits in the en register. The scan manager must not be active during this process. Software reads the active bit of the stat register to determine the scan manager state.
Alternatively, when the FPGA JTAG TAP controller receives the CONFIG_IO JTAG instruction, the control block enters CONFIG_IO mode. When the control block is in CONFIG_IO mode, the controller can override the scan manager JTAG-AP and configure the HPS I/O pins. The CONFIG_IO instruction configures all configurable I/O pins in the SoC device including the FPGA I/O pins and the HPS I/O pins. The FPGA and HPS portions of the device must both be powered on to execute the CONFIG_IO instruction. External logic connected to the FPGA JTAG pins sends the CONFIG_IO instruction, which provides I/O configuration data for all FPGA and HPS I/O pins. While CONFIG_IO mode is active, the HPS is held in cold reset to prevent software from potentially interfering with the I/O configuration.
7.3.2. Communicating with the JTAG TAP Controller
After the system manager undergoes a cold reset, access to the JTAG TAP controller in the FPGA control block is through the dedicated FPGA JTAG I/O pins. If necessary, you can configure your system to use the scan manager to provide the HPS processor access to the JTAG TAP controller, instead. This feature allows the processor to send JTAG instructions to the FPGA portion of the device.
To connect scan chain 7 between the scan manager and the FPGA JTAG TAP controller, the following features must be enabled:
- The scan chain for the FPGA JTAG TAP controller—To enable scan chain 7, set the fpgajtag field of the en register in the scan manager. For more information, refer to "Scan Manager Address Map and Register Definitions".
- The FPGA JTAG logic source select—This source select determines whether the scan manager or the dedicated FPGA JTAG pins are connected to the FPGA JTAG TAP controller in the FPGA portion of the device. On system manager cold reset, the dedicated FPGA JTAG pins are selected. The source select is configured through the fpgajtagen bit of the ctrl register in the scanmgrgrp group of the system manager. The FPGA JTAG pins and scan manager connection to the TAP controller must both be inactive when switching between them. The mechanism to ensure both are inactive is user-defined.
7.3.3. JTAG-AP FIFO Buffer Access and Byte Command Protocol
The JTAG-AP contains FIFO buffers for byte commands and responses. The buffers are accessed through the fifosinglebyte, fifodoublebyte, fifotriplebyte, and fifoquadbyte registers. The JTAG-AP stalls processor access to the registers when the buffer does not contain enough data for read access, or when the buffer does not contain enough free space to accept data for write access.
JTAG-AP scan chains 0, 1, 2 and 3 are write-only ports connected to the HPS IOCSRs and JTAG-AP scan chain 7 is a read-write port connected to the FPGA JTAG TAP controller. The processor can send data to scan chains 0-3, and send and receive data from scan chain 7 by accessing the command and response FIFO buffers in the JTAG-AP.
The JTAG commands and TDI data must be sent to the JTAG-AP using an encoded byte protocol. Similarly, the TDO data received from JTAG-AP is encoded. All commands are 8 bits wide in the byte command protocol.
Bits of the Command Byte | Opcode | |||||||
---|---|---|---|---|---|---|---|---|
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
0 | Opcode Payload | TMS | ||||||
1 | 0 | 0 | Opcode Payload | TDI_TDO | ||||
1 | 0 | 1 | X | X | X | X | X | Reserved |
1 | 1 | 0 | X | X | X | X | X | Reserved |
1 | 1 | 1 | X | X | X | X | X | Reserved |
7.3.4. Clocks
The scan manager is connected to the spi_m_clk clock generated by the clock manager.
The scan manager generates two clocks. One clock routes to the control block of the FPGA portion of the SoC device with a frequency of spi_m_clk / 6 and runs at a maximum of 33 MHz. The other clock routes to the HPS I/O scan chains with a frequency of sp i_m_clk / 2 and runs at a maximum frequency of 100 MHz.
7.3.5. Resets
The reset manager provides the scan_manager_rst_n reset signal to the scan manager for both cold and warm resets.
Because glitches can happen on the output clocks during a warm reset, the scan manager temporarily stops generation of the JTAG-AP and I/O configuration clocks. This action ensures that a warm reset does not cause output clock glitches.
Before asserting warm reset, the reset manager sends a request to the scan manager. The scan manager stops the output clock generation and acknowledges the reset manager. The reset manager then issues the warm reset. To enable this warm reset handshake, configure the scanmgrhsen bit of the reset manager ctrl register.
7.4. Scan Manager Address Map and Register Definitions
This section lists the scan manager register address map and describes the registers.
7.4.1. JTAG-AP Register Name Cross Reference Table
To clarify how Altera uses the JTAG-AP, the Arm* registers are renamed in the SoC device. The following table cross references the Arm* and Altera register names.
Altera Register Name |
Arm* Register Name |
---|---|
stat | CSW (control/status word) |
en | PSEL |
fifosinglebyte | BWFIFO1 for writes, BRFIFO1 for reads |
fifodoublebyte | BWFIFO2 for writes, BRFIFO2 for reads |
fifotriplebyte | BWFIFO3 for writes, BRFIFO3 for reads |
fifoquadbyte | BWFIFO4 for writes, BRFIFO4 for reads |
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 level 4 (L4) buses
The system interconnect is implemented with the Arm* CoreLink* Network Interconnect (NIC-301). The NIC-301 provides a foundation for a high-performance HPS system interconnect based on the Arm* Advanced Microcontroller Bus Architecture ( AMBA* ) Advanced eXtensible Interface ( AXI* ), Advanced High-Performance Bus ( AHB* ), and Advanced Peripheral Bus ( APB* ) protocols. The system interconnect implements a multilayer, nonblocking architecture that supports multiple simultaneous transactions between masters and slaves, including the Cortex®-A9 microprocessor unit (MPU) subsystem. The system interconnect provides five independent L4 buses to access control and status registers (CSRs) of peripherals, managers, and memory controllers.
8.1. Features of the System Interconnect
The system interconnect supports high-throughput peripheral devices. The system interconnect has the following characteristics:
- Main internal data width of 64 bits
- Programmable master priority with single-cycle arbitration
- Full pipelining to prevent master stalls
- Programmable control for FIFO buffer transaction release
- Arm* TrustZone* compliant, with additional security features configurable per master
- Multiple independent L4 buses
8.2. System Interconnect Block Diagram and System Integration
8.2.1. Interconnect Block Diagram
8.2.2. System Interconnect Architecture
Internally, the L3 interconnect is partitioned into the following subswitches:
- L3 interconnect
- Interconnect used to transfer high-throughput 64-bit data
- Operates at up to half the MPU main clock frequency
- Provides masters with low-latency connectivity to AXI bridges, on-chip memories, SDRAM, and FPGA manager
- L3 master peripheral switch
- Used to connect memory-mastering peripherals to the interconnect
- 32-bit data width
- Operates at up to half the interconnect clock frequency
- L3 slave peripheral switch
- Used to provide access to level 3 and 4 slave interfaces for masters of the master peripheral and interconnects
- 32-bit data width
- Five independent L4 buses
The L3 master and slave peripheral switches are fully-connected crossbars. The L3 interconnect is a partially-connected crossbar. The following table shows the connectivity matrix of all the master and slave interfaces of the L3 interconnect.
8.2.3. Main Connectivity Matrix
8.3. Functional Description of the Interconnect
8.3.1. Master to Slave Connectivity Matrix
The interconnect is a partially-connected crossbar. The following table shows the connectivity matrix of all the master and slave interfaces of the interconnect.
8.3.2. 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.3.2.1. Available Address Maps
The following figure shows the default system interconnect address maps for all masters. The figure is not to scale.
Notes on Address Maps
(1) Transactions on these addresses are directly decoded by the SCU and L2 cache.
(2) This region can be configured to access slaves on the lightweight HPS-to-FPGA bridge, by using the remap register.
(3) This region can be configured to access slaves on the HPS-to-FPGA bridge, by using the remap register.
(4) The MPU accesses SDRAM through a dedicated port.
(5) This region can be configured to access on-chip RAM, by using the remap register.
(6) The following peripherals can master the interconnect:
- Ethernet MACs
- USB-2 OTG controllers
- NAND controllers
- ETR
- SD/MMC controller
For the MPU master, either the boot ROM or on-chip RAM maps to address 0x0 and obscures the lowest 64 KB of SDRAM.
At boot time, the MPU does not have access to the SDRAM address space from 0x00010000 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 64 KB of SDRAM for non-MPU masters.
8.3.2.2. L3 Address Space
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) | When remap.nonmpuzero 14 is clear | 0x00000000 | 0xBFFFFFFF | 3 GB |
On-chip RAM | When remap.nonmpuzero 14 is set | 0x00000000 | 0x0000FFFF | 64 KB |
SDRAM window (with on-chip RAM) | When remap.nonmpuzero 14 is set | 0x00010000 | 0xBFFFFFFF | 3145664 KB = 3 GB - 64 KB |
ACP window | Always visible | 0x80000000 | 0xBFFFFFFF | 1 GB |
HPS-to-FPGA | When remap.hps2fpga 14 is set. 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. Visible to other masters when remap.hps2fpga 14 is set. | 0xFF200000 | 0xFF3FFFFF | 2 MB |
Peripherals | Not visible to master peripherals. Always visible to other masters. | 0xFF400000 | 0xFFFCFFFF | 12096 KB |
On-chip RAM | Always visible | 0xFFFF0000 | 0xFFFFFFFF | 64 KB |
SDRAM Window Region
The SDRAM window region is 3 GB and provides access to the bottom 3 GB of the SDRAM address space. Any L3 master can access a cache-coherent view of SDRAM by performing a cacheable access through the ACP.On-Chip RAM Region
The system interconnect remap register, in the l3regs group, determines if the 64 KB starting at address 0x0 is mapped to the on-chip RAM or the SDRAM. The SDRAM is mapped to address 0x0 on reset.ACP Window Region
The ACP window region is 1 GB and provides access to a configurable gigabyte-aligned region of the MPU address space. Registers in the ACP ID mapper control which gigabyte-aligned region of the MPU address space is accessed by the ACP window region. The ACP window region is used by L3 masters to perform coherent accesses into the MPU address space. For more information about the ACP ID mapper, refer to the Cortex-A9 Microprocessor Unit Subsystem chapter.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
The on-chip RAM is always mapped (independent of the boot region contents).8.3.2.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 (0xFFFEC000 to 0xFFFF0000) 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 system interconnect and a master connected to the SDRAM.
The MPU address space contains the following regions:
Description | Condition |
Base Address |
End Address |
Size |
---|---|---|---|---|
Boot ROM | Always visible |
0x00000000 |
0x000FFFFF |
1 MB |
SDRAM window | Always visible |
0x00100000 |
0xBFFFFFFF |
3047 MB (3 GB – 1 MB) |
HPS-to-FPGA | When remap.hps2fpga 15 is set. | 0xC0000000 | 0xFBFFFFFF | 348 KB |
System trace macrocell | Always visible | 0xFC000000 | 0xFFEFFFFF | 48 KB |
Debug access port | Always visible | 0xFF000000 | 0xFF1FFFFF | 2 MB |
Lightweight HPS-to-FPGA | Visible when remap.hps2fpga 15 is set. | 0xFF200000 | 0xFF3FFFFF | 2 MB |
Peripherals | Always visible | 0xFF400000 | 0xFFFCFFFF | 12096 KB |
Boot ROM | Always visible | 0xFFFD0000 | 0xFFFEBFFF | 112 KB |
SCU and L2 registers | Always visible | 0xFFFEC000 | 0xFFFEFFFF | 16 KB |
On-chip RAM | Always visible | 0xFFFF0000 | 0xFFFFFFFF | 64 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 remap 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 64 KB of the boot region are legal addresses because the on-chip RAM and boot ROM are only 64 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 map to the SDRAM controller, which queues the read and write transactions for execution. Addresses that fall outside the boundaries route to the system interconnect, to access peripherals, bridges, and other HPS resources.
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 peripheral region includes slaves connected to the L3 interconnect and L4 buses.
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).
On-Chip RAM Region
The on-chip RAM is always mapped near the top of the address space, independent of the boot region contents.
8.3.2.4. SDRAM Address Space
8.3.2.5. Address Remapping
The system interconnect supports address remapping through the remap register in the l3regs group. Remapping allows software to control which memory device (SDRAM, on-chip RAM, or boot ROM) is accessible at address 0x0 and the accessibility of the HPS-to-FPGA and lightweight HPS-to-FPGA bridges. The remap register is one of the NIC-301 Global Programmers View (GPV) registers. The following L3 masters can manipulate remap, because it maps into their address space:
- MPU
- FPGA-to-HPS bridge
- DAP
The remapping bits in the remap register are not mutually exclusive. The lowest order remap bit has higher priority when multiple slaves are remapped to the same address. Each bit allows different combinations of address maps to be formed. There is only one remapping register available in the GPV, so modifying the remap register affects all memory maps of all the masters of the system interconnect.
The effects of the remap bits can be categorized in the following groups:
- 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.3.2.5.1. Bit Fields for Modifying the Memory Map
Bit Name |
Bit Offset |
Description |
||||||
---|---|---|---|---|---|---|---|---|
mpuzero |
0 |
Note: Regardless
of this setting, the boot ROM also always maps to address
0xFFFF0000
and the on-chip RAM also always maps to address
0xFFFD0000
for the MPU L3 master.
|
||||||
nonmpuzero |
1 |
Note that regardless of this setting, the on-chip RAM also always maps to address 0xFFFD0000 for the non-MPU L3 masters. |
||||||
Reserved |
2 |
Must always be 0. |
||||||
hps2fpga |
3 |
|
||||||
lwhp2fpga |
4 |
|
||||||
Reserved |
31:5 |
Must always be 0. |
8.3.3. Master Caching and Buffering Overrides
Some of the peripheral masters connected to the system interconnect 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 Register Group | Register |
---|---|---|
EMAC0 and EMAC1 | emacgrp | l3master |
USB OTG 0 and USB OTG 1 | usbgrp | l3master |
NAND flash | nandgrp | l3master |
SD/MMC | sdmmcgrp | 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 system interconnect, so avoid changing these settings when any of the masters are active.
8.3.4. Security
8.3.4.1. Slave Security
The interconnect enforces security through the slave settings. The slave settings are controlled by the address region control registers accessible through the GPV registers. Each L3 and L4 slave has its own security check and programmable security settings. After reset, every slave of the interconnect is set to a secure state (referred to as boot secure). The only accesses allowed to secure slaves are by secure masters.
The GPV can only be accessed by secure masters. The security state of the interconnect is not accessible through the GPV as the security registers are write-only. Any nonsecure accesses to the GPV receive a DECERR response, and no register access is provided. Updates to the security settings through the GPV do not take effect until all transactions to the affected slave have completed.
8.3.4.2. Master Security
Masters of the system interconnect are either secure, nonsecure, or the security is set on a per transaction basis. The DAP and Ethernet masters only perform secure accesses. The L2 cache master 0, FPGA-to-HPS-bridge, and DMA perform secure and nonsecure accesses on a per transaction basis. All other system interconnect masters perform nonsecure accesses.
Accesses to secure slaves by unsecure masters result in a response of DECERR and the transaction does not reach the slave.
All masters are secure at reset.
8.3.5. Configuring the Quality of Service Logic
8.3.6. Cyclic Dependency Avoidance Schemes
The AXI protocol permits re-ordering of transactions. As a result, when routing concurrent multiple transactions from a single point of divergence to multiple slaves, the interconnect might need to enforce rules to prevent deadlock.
Each master of the interconnect is configured with one of three possible cyclic dependency avoidance schemes (CDAS). The same CDAS scheme is configured for both read and write transactions, but they operate independently.
8.3.6.1. Single Slave
Single slave (SS) ensures the following conditions at a slave interface of a switch:
- All outstanding read transactions are to a single end destination.
- All outstanding write transactions are to a single end destination.
If a master issues another transaction to a different destination than the current destination for that transaction type (read or write), the network stalls the transactions until all the outstanding transactions of that type have completed.
8.3.6.2. Single Slave Per ID
Single slave per ID (SSPID) ensures the following conditions at a slave interface of a switch:
- All outstanding read transactions with the same ID go the same destination.
- All outstanding write transactions with the same ID go the same destination.
When a master issues a transaction, the following situations can occur:
- If the transaction has an ID that does not match any outstanding transactions, it passes the CDAS.
- If the transaction has an ID that matches the ID of an outstanding transaction, and the destinations also match, it passes the CDAS.
- If the transaction has an ID that matches the ID of an outstanding transaction, and the destinations do not match, the transaction fails the CDAS check and stalls.
8.3.6.3. Single Active Slave
Single active slave (SAS) is the same as the SSPID scheme, with an added check for write transactions. SAS ensures that a master cannot issue a new write address until all of the data from the previous write transaction has been sent.
8.3.7. System Interconnect Master Properties
The system interconnect connects to various slave interfaces through the L3 interconnect and L3 slave peripheral switch.
Master | Width | Clock | Switch | TrustZone Security | GPV Access | CDAS | Issuance | FIFO Buffer Depth16 | Type |
---|---|---|---|---|---|---|---|---|---|
L2 cache M0 |
64 |
mpu_l2_ram_clk |
L3 interconnect |
Per Transaction |
Yes |
SSPID |
7, 12, 19 |
2, 2, 2, 2, 2 |
AXI |
FPGA-to-HPS bridge |
64 |
l3_main_clk |
L3 interconnect |
Per Transaction |
Yes |
SAS |
16, 16, 32 |
2, 2, 6, 6, 2 |
AXI |
DMA |
64 |
l4_main_clk |
L3 interconnect |
Per Transaction |
No |
SSPID |
8, 8, 8 |
2, 2, 2, 2, 2 |
AXI |
EMAC 0/1 |
32 |
l4_main_clk |
L3 master peripheral switch |
Secure |
No |
SSPID |
16, 16, 32 |
2, 2, 2, 2, 2 |
AXI |
USB OTG 0/1 |
32 |
usb_mp_clk |
L3 master peripheral switch |
Nonsecure |
No |
SSPID |
2, 2, 4 |
2, 2, 2 |
AHB |
NAND |
32 |
nand_x_clk |
L3 master peripheral switch |
Nonsecure |
No |
SSPID |
1, 8, 9 |
2, 2, 2, 2, 2 |
AXI |
SD/MMC |
32 |
l4_mp_clk |
L3 master peripheral switch |
Nonsecure |
No |
SSPID |
2, 2, 4 |
2, 2, 2 |
AHB |
ETR |
32 |
dbg_at_clk |
L3 master peripheral switch |
Per Transaction |
No |
SSPID |
32, 1, 32 |
2, 2, 2, 2, 2 |
AXI |
DAP |
32 |
dbg_clk |
L3 interconnect |
Secure |
Yes |
SS |
1, 1, 1 |
2, 2, 2 |
AHB |
The AXI IDs of the HPS peripheral masters identify transactions from the HPS to soft logic over the HPS-to-FPGA bridge. Soft logic in the FPGA can monitor the AXI IDs to determine which master issued each transaction. For HPS peripheral AXI IDs, refer to "HPS Peripheral Master Input IDs".
8.3.8. Interconnect Slave Properties
The interconnect connects to various slave interfaces through the L3 interconnect, L3 slave peripheral switch, and the five L4 peripheral buses. After reset, all slave interfaces are set to the secure state.
The interconnect provides FIFO buffers with clock crossing adapters. Refer to "FIFO Buffers and Clock Crossing" for details.
Slave |
I/F Width |
Clock |
Mastered By |
Acceptance 17 |
Buffer Depth 18 |
Type |
---|---|---|---|---|---|---|
SDRAM subsystem CSR |
32 |
l4_sp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
SP timer 0/1 |
32 |
l4_sp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
I2C 0/1/2/3 |
32 |
l4_sp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
UART 0/1 |
32 |
l4_sp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
GPIO 0/1/2 |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
ACP ID mapper CSR |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
FPGA manager CSR |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
DAP CSR |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Quad SPI flash CSR |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
SD/MMC CSR |
32 |
l4_mp_clk |
L4 SP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
EMAC 0/1 CSR |
32 |
l4_mp_clk |
L4 MP bus master |
1, 1, 1 |
2, 2, 2 |
APB |
System manager |
32 |
osc1_clk |
L4 OSC1 bus master |
1, 1, 1 |
2, 2, 2 |
APB |
OSC1 timer 0/1 |
32 |
osc1_clk |
L4 OSC1 bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Watchdog 0/1 |
32 |
osc1_clk |
L4 OSC1 bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Clock manager |
32 |
osc1_clk |
L4 OSC1 bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Reset manager |
32 |
osc1_clk |
L4 OSC1 bus master |
1, 1, 1 |
2, 2, 2 |
APB |
DMA secure CSR |
32 |
l4_main_clk |
L4 main bus master |
1, 1, 1 |
2, 2, 2 |
APB |
DMA nonsecure CSR |
32 |
l4_main_clk |
L4 main bus master |
1, 1, 1 |
2, 2, 2 |
APB |
SPI slave 0/1 |
32 |
l4_main_clk |
L4 main bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Scan manager |
32 |
spi_m_clk |
L4 main bus master |
1, 1, 1 |
2, 2, 2 |
APB |
SPI master 0/1 |
32 |
spi_m_clk |
L4 main bus master |
1, 1, 1 |
2, 2, 2 |
APB |
Lightweight HPS-to-FPGA bridge |
32 |
l4_main_clk |
L3 slave peripheral switch |
16, 16, 32 |
2, 2, 2, 2, 2 |
AXI |
USB OTG 0/1 |
32 |
usb_mp_clk |
L3 slave peripheral switch |
1, 1, 1 |
2, 2, 2 |
AHB |
NAND CSR |
32 |
nand_x_clk |
L3 slave peripheral switch |
1, 1, 1 |
2, 2, 2 |
AXI |
NAND command and data |
32 |
nand_x_clk |
L3 slave peripheral switch |
1, 1, 1 |
2, 2, 2 |
AXI |
Quad SPI flash data |
32 |
l4_mp_clk |
L3 slave peripheral switch |
1, 1, 1 |
2, 2, 2 |
AHB |
FPGA manager data |
32 |
cfg_clk |
L3 interconnect |
1, 2, 3 |
2, 2, 2, 32, 2 |
AXI |
HPS-to-FPGA bridge |
64 |
l3_main_clk |
L3 interconnect |
16, 16, 32 |
2, 2, 6, 6, 2 |
AXI |
ACP ID mapper data |
64 |
mpu_l2_ram_clk |
L3 interconnect |
13, 5, 18 |
2, 2, 2, 2, 2 |
AXI |
STM |
32 |
dbg_at_clk |
L3 interconnect |
1, 2, 2 |
2, 2, 2, 2, 2 |
AXI |
On-chip boot ROM |
32 |
l3_main_clk |
L3 interconnect |
1, 1, 2 |
0, 0, 0, 0, 0 |
AXI |
On-chip RAM |
64 |
l3_main_clk |
L3 interconnect |
2, 2, 2 |
0, 0, 0, 8, 0 |
AXI |
SDRAM subsystem L3 data |
32 |
l3_main_clk |
L3 interconnect |
16, 16, 16 |
2, 2, 2, 2, 2 |
AXI |
8.3.9. Upsizing Data Width Function
The upsizing function combines narrow transactions into wider transactions to increase the overall system bandwidth. Upsizing only packs data for read or write transactions that are cacheable. If the interconnect splits input-exclusive transactions into more than one output bus transaction, it removes the exclusive information from the multiple transactions it creates.
The upsizing function can expand the data width by the following ratios:
- 1:2
- 1:4
If multiple responses from created transactions are combined into one response, then the following order of priority applies:
- DECERR is the highest priority
- SLVERR is the next highest priority
- OKAY is the lowest priority.
8.3.9.1. Incrementing Bursts
The interconnect converts all input INCR bursts that complete within a single output data width to an INCR1 burst of the minimum SIZE possible, and packs all INCR bursts into INCR bursts of the optimal size possible for maximum data throughout.
8.3.9.2. Wrapping Bursts
All WRAP bursts are either passed through unconverted as WRAP bursts, or converted to one or two INCR bursts of the output bus. The interconnect converts input WRAP bursts that have a total payload less than the output data width to a single INCR burst.
8.3.9.3. Fixed Bursts
All FIXED bursts pass through unconverted.
8.3.9.4. Bypass Merge
Bypass merge is accessible through the GPV registers and is only accessible to secure masters. If the programmable bit bypass_merge is enabled, the interconnect does not alter any transactions that could pass through legally without alteration.
8.3.10. Downsizing Data Width Function
The downsizing function reduces the data width of a transaction to match the optimal data width at the destination. Downsizing does not merge multiple-transaction data narrower than the destination bus if the transactions are marked as noncacheable.
The downsizing function reduces the data width by the following ratios:
- 2:1
- 4:1
8.3.10.1. Incrementing Bursts
The interconnect converts INCR bursts that fall within the maximum payload size of the output data bus to a single INCR burst. It converts INCR bursts that are greater than the maximum payload size of the output data bus to multiple INCR bursts.
INCR bursts with a size that matches the output data width pass through unconverted.
The interconnect packs INCR bursts with a SIZE smaller than the output data width to match the output width whenever possible, using the upsizing function.
8.3.10.2. Wrapping Bursts
The interconnect always converts WRAP bursts to WRAP bursts of twice the length, up to the output data width maximum size of WRAP16, and treats the WRAP burst as two INCR bursts that can each be converted into one or more INCR bursts.
8.3.10.3. Fixed Bursts
The interconnect converts FIXED bursts to one or more INCR1 or INCRn bursts depending on the downsize ratio.
8.3.10.4. Bypass Merge
Bypass merge is accessible through the GPV registers and is only accessible to secure masters. If the programmable bit bypass_merge in the fn_mod2 register is enabled, the interconnect does not perform any packing of beats to match the optimal size for maximum throughput, up to the output data width size.
If an exclusive transaction is split into multiple transactions at the output of the downsizing function, the exclusive flag is removed and the master never receives an EXOKAY response. Response priority is the same as for the upsizing function.
8.3.11. Lock Support
Lock is not supported by the interconnect. For atomic accesses, masters can perform exclusive accesses when sharing data located in the HPS SDRAM.
8.3.12. FIFO Buffers and Clock Crossing
The interconnect provides FIFO buffers in the following locations:
- On interfaces to all HPS master and slaves except onchip RAM and boot ROM
- Between subswitches
In addition to buffering, these FIFOs also provide clock domain crossing where masters and slaves operate at a different clock frequency from the switch they connect to.
8.3.12.1. Data Release Mechanism
For system interconnect ports with data FIFO buffers whose depth is greater than zero, you can set a write tidemark function, wr_tidemark. This tidemark level stalls the release of the transaction until one of the following situations occurs:
- The system interconnect receives the WLAST beat of a burst.
- The write data FIFO buffer becomes full.
- The number of occupied slots in the write data FIFO buffer exceeds the write tidemark.
8.3.13. System Interconnect Resets
The system interconnect has one reset signal. The reset manager drives this signal to the system interconnect on a cold or warm reset.
8.4. System Interconnect Address Map and Register Definitions
This section lists the system interconnect register address map and describes the registers.
9. HPS-FPGA Bridges
This chapter describes the bridges in the hard processor system (HPS) used to communicate data between the FPGA fabric and HPS logic. The bridges use the Advanced Microcontroller Bus Architecture ( AMBA* ) Advanced eXtensible Interface ( AXI* ) protocol, and are based on the AMBA* Network Interconnect (NIC-301).
The HPS contains the following HPS-FPGA bridges:
- FPGA-to-HPS Bridge
- HPS-to-FPGA Bridge
- Lightweight HPS-to-FPGA Bridge
9.1. Features of the HPS-FPGA Bridges
Feature |
FPGA-to-HPS Bridge |
HPS-to-FPGA Bridge |
Lightweight HPS-to-FPGA Bridge |
---|---|---|---|
Supports the AMBA* AXI3 interface protocol |
Y | Y | Y |
Implements clock crossing and manages the transfer of data across the clock domains in the HPS logic and the FPGA fabric |
Y | Y | Y |
Performs data width conversion between the HPS logic and the FPGA fabric |
Y | Y | Y |
Allows configuration of FPGA interface widths at instantiation time |
Y | Y | N |
Each bridge consists of a master-slave pair with one interface exposed to the FPGA fabric and the other exposed to the HPS logic. The FPGA-to-HPS bridge exposes an AXI* slave interface that you can connect to AXI* master or Avalon-MM interfaces in the FPGA fabric. The HPS-to-FPGA and lightweight HPS-to-FPGA bridges expose an AXI* master interface that you can connect to AXI* or Avalon-MM slave interfaces in the FPGA fabric.