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.

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.

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.

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).

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.

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.

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.

The Clock Manager contains registers used to configure and observe the clock manager.

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.

The clock manager contains one clock group for each PLL and one clock group for the HPS_CLK1 pin.

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%.

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.

ddr_dqs_base_clk

ddr_2x_dqs_base_clk

ddr_dq_base_clk

h2f_user2_base_clk

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.

ddr_dqs_clk

ddr_2x_dqs_clk

ddr_dq_clk

h2f_user2_clock

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.

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.

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.

The reset manager generates module reset signals based on reset requests from the various sources in the HPS and FPGA fabric, and software writing to the module-reset control registers. The reset manager ensures that a reset request from the FPGA fabric can occur only after the FPGA portion of the system-on-a-chip (SoC) device is configured.

The HPS contains multiple reset domains. Each reset domain can be reset independently. A reset may be initiated externally, internally or through software.

The 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

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.

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

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.

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.

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.

The cold and warm reset sequences consist of different reset assertion sequences and the same deassertion sequence. The following sections describe the sequences.

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.

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.

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.

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.

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.

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

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.

The FPGA manager has the two blocks - fabric I/O and monitor.

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.

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

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.

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:

1. Power up phase
2. Reset phase
3. Configuration phase
4. Initialization phase
5. 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.

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.

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:

1. Clear the FPGA configuration RAM bits
2. Tri-state all FPGA user I/O pins
3. Pull the nSTATUS and CONF_DONE pins low
4. 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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

enable

datastart

length

execution

crc

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.

The System Manager provides remap bits to the L3 interconnect. These bits can remap the Boot ROM and the On-chip RAM.

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

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.

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.

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.

• Drives all the I/O scan chains for HPS I/O banks
• Allows the HPS to access the FPGA JTAG TAP controller

The processor accesses the scan manager through the register slave interface connected to the level 4 (L4) peripheral bus.

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.

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.

The scan manager serves the following purposes:

• Configuring HPS I/O scan chains
• Communicating with the JTAG TAP controller

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.

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.

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.