The security manager module is integrated in the HPS and provides the overall management of security within the SoC, including:

• Recognition of secure fuse configuration, preventing non-secure device startup
• State control and check of the security features
• Secure boot options
• Secure debug options
• Anti-tamper support

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‑SDRAM interface from the FPGA fabric. The total amount of SDRAM addressable from the other address spaces can be configured at runtime.

There are cacheable and non-cacheable views into the SDRAM space. When a master of the L3 SDRAM interconnect performs a cacheable access to the SDRAM, the transaction is performed through the ACP port of the MPU subsystem. When a master of the SDRAM L3 interconnect performs a non-cacheable access to the SDRAM, the transaction is performed through the 64-bit L3 interconnect master of the SDRAM L3 interconnect.

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 clock groups:
  • Main—contains clocks for the Cortex*-A9 microprocessor unit (MPU) subsystem, level 3 (L3) interconnect, level 4 (L4) peripheral bus, and debug
  • Peripheral—contains clocks for PLL-driven peripherals
• Contains two identical 16-output PLL blocks:
  • PLL 0
  • PLL 1
• Generates clock gate controls for enabling and disabling most clocks
• Initializes and sequences clocks
• Allows software to program clock characteristics, such as the following items discussed later in this chapter:
  • Input clock source for the two PLLs
  • Multiplier range, divider range, and 16 post-scale counters for each PLL
  • VCO enable for each PLL
  • Bypass modes for each PLL
  • Gate of individual clocks in all PLL clock groups
  • Clear loss of lock status for each PLL
  • Boot mode for hardware-managed clocks
  • General-purpose I/O (GPIO) debounce clock divide
• Allows software to observe the status of all writable registers
• Supports interrupting the MPU subsystem on PLL‑lock and loss‑of‑lock
• Supports clock gating at the signal level

The clock manager is not responsible for the following functional behaviors:

• Selection or management of the clocks for the FPGA-to-HPS and HPS-to-FPGA interfaces. The FPGA logic designer is responsible for selecting and managing these clocks.

• Software must not program the clock manager with illegal values. If it does, the behavior of the clock manager is undefined and could stop the operation of the HPS. The only guaranteed means for recovery from an illegal clock setting is a cold reset.
• When re-programming clock settings, there are no automatic glitch-free clock transitions. Software must follow a specific sequence to ensure glitch-free clock transitions. Refer to Hardware-Managed and Software-Managed Clocks section of this chapter.

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 two PLLs contain exactly the same set of output clocks. PLL0 is intended to be used for the MPU and the NOC clocks. PLL1 is intended to be used as the 250 MHz Ethernet clock reference.

When changing values on clocks, the terms hardware-managed and software-managed define how clock transitions are implemented. When changing a software-managed clock, software is responsible for gating off the clock, waiting for a PLL lock if required, and gating the clock back on. Clocks that are hardware-managed are automatically transitioned by the hardware to ensure glitch-free operation.

• mpu_periph_clk
• mpu_l2_ram_clk
• mpu_clk

• l3_main_free_clk
• l4_sys_free_clk
• l4_sys_free_div4_clk
• l4_main_clk
• l4_mp_clk
• l4_sp_clk

• cs_timer_clk
• cs_at_clk
• cs_pdbg_clk
• cs_trace_clk

All other clocks in the HPS are software-managed clocks.

The hardware sequenced clock groups consists of the MPU clocks and the NOC clocks. The following diagram shows the external bypass muxes, hardware-managed external counters and dividers, and clock gates. For hardware-managed clocks, the group of clocks has only one software enable for the clock gate. As a result, the group of clocks are all enabled or disabled together. The slight exception is the NOC has two software enables, one for the l3/l4 clocks and one for the CoreSight clocks.

The software sequenced clock groups include additional clocks for peripherals not covered by the NOC clocks. The main purpose is to have a second PLL for the Ethernet 250 MHz clock reference. The following diagram shows the external bypass muxes, hardware-managed external counters and dividers, and clock gates.

There are 3 EMAC cores that have a very strict requirement of either a 250 MHz or 50 MHz clock reference. If the PLL0 frequency is a multiple of 250 MHz (for example 1.5 GHz), driving the EMAC clocks from PLL0 provides PLL1 with more flexibility in VCO clock frequency. In addition, to minimize the PLL clock outputs required, emac_clka can be 250 MHz and emac_clkb can be 50 MHz, allowing each EMAC core to be software configured to select 250 MHz or 50 MHz.

Power-On-Reset (POR) Reset

The security manager handles clocking during POR. Depending on the status of one of the security fuses, the device is initially clocked using either the secure cb_intosc_hs_div2_clk or the unsecure external oscillator.

Cold Reset

The reset manager brings the clock manager out of cold reset first in order to provide clocks to the rest of the blocks. After POR is de-asserted, clock manager enables boot_clk to the rest of the system before the module resets are de-asserted.

Warm Reset

During a Warm Rest, the clock manager module is not reset. The following steps are taken during a warm reset:

1. Reset manager puts all modules affected by Warm Reset into reset. Reset manager issues a Boot Mode request to clock manager.
2. Based on the status of the hps_clk_f fuse during POR, security manager indicates if the boot clock should be secure.
   1. If secure clocks are enabled, boot_clk transitions gracefully to cb_intosc_hs_div2_clk.
   2. If secure clocks are not enabled, boot_clk transitions gracefully to the external oscillator input, HPS_CLK1.
   Note: The security fuse is only sampled during cold reset and warm reset. The security fuse hps_clk_f allows the user to enable secure clocks. If clearing RAM on a Cold or Warm reset, the user should enable secure clocks (cb_intosc_hs_clk divide by 2).
3. The Clock Manager gracefully transitions Hardware-Managed and Software Managed clocks into Boot Mode as follows:
   1. Disable all output clocks including Hardware and Software-Managed clocks.
   2. Wait for all clocks to be disabled, and do the following two things:
      1. Bypass all external Hardware and Software-Managed clocks.
      2. Update Hardware-Managed external counters/dividers to Boot Mode settings.
   3. Wait for all bypasses to switch, and then synchronously reset the CSR registers.
   4. Enable all clocks.
4. After Hardware Managed Clocks have transitioned, the Clock Manager acknowledges the Reset Manager.
5. Reset Manager continues with Warm Reset de-assertion sequence.

The clock manager creates a boot clock as the clock reference for boot mode and external bypass. The clock configuration is based on security features in the security manager.

Security Input Clocks

The following table defines the boot clock sources.

Boot Clock

The status of the hps_clk_f security fuse in the Security Manager determines if boot_clk should be secure:

• If set, then boot_clk is cb_intosc_hs_clk divided by 2.
• If clear, then boot_clk comes from the external oscillator input pin HPS_CLK1.

The above setting is reported by the security manager before the chip is brought out of cold reset. Also the security status may be updated by security option registers in the security manager.

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

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

The Reset domains and sequences include security features. The security manager works with Power On Reset (POR) and brings the reset manager out of reset only when the secure fuses have been loaded and validated. Once this process is complete, the reset manager brings the rest of the HPS out of reset.

The HPS supports the following reset types:

• System cold reset
  • Used to ensure the HPS is placed in a default state sufficient for software to boot
  • Triggered by a power-on reset and other sources
  • Resets all HPS logic that can be reset
  • Affects all reset domains
• System warm reset
  • Used to recover system from a non-responsive condition
  • Does not reset the Debug or TAP reset domain, allowing debug functions including trace to operate through out a warm reset
  • Masks allow software to exclude modules from warm reset. Exceptions for masks:
    • To maintain security, there is no mask for security manager
    • The MPU cannot be masked
  • RAM Clearing domain (if not masked) logic is reset
• Debug reset
  • Used to recover debug logic from a non-responsive condition
  • Only affects the debug reset domain
• TAP Reset
  • JTAG TAP controller is reset
  • Software may trigger TAP reset

The reset manager accepts reset requests from the security manager, FPGA control block, FPGA core, modules in the HPS, and reset pins and generates module reset signals. The reset manager receives security status from the security manager. The reset manager also has warm reset handshaking signals to support system reset behavior, clock manager interfaces, and the Anti-Tamper interface with security manager. The Boot clock (boot_clk) is used as the default clock for both cold or warm reset. When the device is configured to operate in secure mode, boot_clk is cb_intosc_hs_div2_clk. When the device is not in secure mode, boot_clk is sourced from the external oscillator input pin, HPS_CLK1.

The following figure shows a block diagram of the reset manager in the SoC device. For clarity, reset-related handshaking signals to other HPS modules and to the clock manager module are omitted.

In secure mode, all signals are synchronous to boot_clk. In non-secure mode, all signals are synchronous to the clock signal osc1_clk which is sourced from the external oscillator input pin, HPS_CLK1. The following table lists the reset sources external to the HPS.

The reset controller performs the following functions:

• Accepts reset requests from the FPGA control block (CB), FPGA fabric, modules in the HPS, and reset pins
• Generates an individual reset signal for each module instance for all modules in the HPS
• Provides reset handshaking signals to support system reset behavior

The reset controller generates module reset signals from external reset requests and internal reset requests. External reset requests originate from sources external to the reset manager. Internal reset requests originate from control registers in the reset manager.

The reset controller supports the following cold reset requests:

• Security manager reset
• Cold reset request pin (nPOR)
• FPGA fabric
• FPGA CB
• Software cold reset request bit (swcoldrstreq) of the control register (ctrl)

The reset controller supports the following warm reset requests:

• Warm reset request pin (nRST)
• FPGA fabric
• Software warm reset request bit (swwarmrstreq) of the ctrl register
• MPU watchdog reset requests for CPU0 and CPU1
• System watchdog timer 0 and 1 reset requests

The reset controller supports the following debug reset requests:

• CDBGRSTREQ from DAP
• FPGA fabric

When secure mode is enabled on the device, reset manager performs some additional functions. To avoid unsecure snooping of existing RAM contents, the HPS can be configured to clear all RAM, both general-purpose RAM and dedicated RAM that is integrated into modules. The list of RAMs on the HPS is:

• Onchip RAM
• USB0
• USB1
• SDMMC
• EMAC0 - EMAC2 RX and TX buffers
• DMA
• NAND Read, Write and ECC RAMs
• QSPI
• MPU RAM

RAMs can be cleared on cold reset, warm reset or both as there are separate fuses that control behavior for cold and warm resets. When the corresponding fuse is blown, all RAMs are cleared for the indicated reset type. If an additional fuse is blown, the various RAM contents are cleared sequentially; otherwise, the contents of all of the RAMs are cleared simultaneously. Even if all security RAM clearing is disabled, the reset manager always invalidates the MPU L1 Cache.

The HPS also supports an Anti-Tamper interface from the FPGA fabric to security manager. If an Anti-Tamper event occurs, the HPS clears all RAMs and becomes unresponsive. The HPS only recovers from this state by a POR. Anti-Tamper logic, such as voltage detection, may reside in the FPGA.

The reset manager slave interface is used to control and monitor the reset states.

The status register (stat) in the reset manager contains the status of the reset requester. The register contains a bit for each monitored reset request. The stat register captures all reset requests that have occurred. Software is responsible for clearing the bits.

During the boot process, the Boot ROM copies the stat register value into memory before clearing it. After booting, you can read the value of the reset status register at memory address (r0 + 0x0038). For more information, refer to the "HPS State on Entry to the Second-Stage Boot Loader" section of the Booting and Configuration appendix.

The reset manager generates reset signals to modules in the HPS and to the FPGA fabric. The following actions generate reset signals:

• Software writing a 1 to the swcoldrstreq or swwarmrstreq bits in the ctrl register. Writing either bit causes the reset controller to perform a reset sequence.
• Software writing to the mpumodrst, per0modrst, per1modrst, brgmodrst, sysmodrst, coldmodrst, nrstmodrst or dbgmodrst module reset control registers.
• Asserting reset request signals triggers the reset controller. All external reset requests cause the reset controller to perform a reset sequence.

Multiple reset requests can be driven to the reset manager at the same time. Cold reset requests take priority over warm and debug reset requests. Higher priority reset requests preempt lower priority reset requests. There is no priority difference among reset requests within the same domain.

If a cold reset request is issued while another cold reset is already underway, the reset manager extends the reset period for all the module reset outputs until all cold reset requests are removed. If a cold reset request is issued while the reset manager is removing other modules out of the reset state, the reset manager returns those modules back to the reset state.

If a warm reset request is issued while another warm reset is already underway, the first warm reset completes before the second warm reset begins. If the second warm reset request is removed before the first warm reset completes, the warm first reset is extended to meet the timing requirements of the second warm reset request.

The nPOR pin can be used to extend the cold reset beyond what the POR voltage monitor automatically provides. The use of the nPOR pin is optional and can be tied high when it is not required.

The nRST pin can be used to extend a warm reset. The nRST pin is tri-stated, and the Reset Manager stretches a warm reset by the count programed in the CSR (RSTMGR.COUNTS.NRSTCNT) [doc however you usually do registers and bits] After the count has elapsed, 256 additional clocks cycles elapse before the nRST input is sampled again.

The reset manager contains the stat register that indicates which reset source caused a reset as well as the ramstat register that indicates which RAM modules were cleared during the last reset. After a cold reset is complete, all bits are cleared except for the bit(s) that indicate the source of the cold reset. If multiple cold reset requests overlap with each other, the bit corresponding to the source that de-asserts its request last is set. If more than one source is de-asserted in the same cycle, the value of the bit corresponding to each source is set.

After a warm reset is complete, the bit(s) that indicate the source of the warm reset are set to 1. A warm reset doesn't clear any bits in the stat register, so bits corresponding to any reset source that has caused a warm reset since the last cold reset or since the bits were last cleared are set. Any bit can be manually cleared by writing a 1 to it.

If RAM memory is cleared during a Cold or Warm reset, then the ramstat register indicates which RAMs during the reset. Bits are cleared manually by writing a 1.

The hard memory controller (HMC) in the FPGA is reset by the reset manager using a GPIO. The HMC is reset only through software; resetting the HMC is not part of the operation of any reset sources.

The reset controller sequences resets without software assistance. Module reset signals are asserted asynchronously and synchronously. The reset manager deasserts the module reset signals synchronous to the boot_clk clock. Module reset signals are deasserted in groups in a fixed sequence. All module reset signals in a group are deasserted at the same time.

The reset manager sends a request to the clock manager to put the clocks in boot mode, which creates a fixed and known relationship between the boot_clk clock and all other clocks generated by the clock manager.

After the reset manager releases the MPU subsystem from reset, CPU1 is left in reset and CPU0 begins executing code from the reset vector address. Software is responsible for deasserting CPU1 and other resets, as shown in MPU Group, Generated Module Resets Table. Software deasserts resets by writing the mpumodrst, per0modrst, per1modrst, brgmodrst, sysmodrst, coldmodrst, nrstmodrst, and dbgmodrst module-reset control registers.

Software can also bypass the reset controller and generate reset signals directly through the module-reset control registers. In this case, software is responsible for asserting module reset signals, driving them for the appropriate duration, and deasserting them in the correct order. The clock manager is not typically in boot mode during this time, so software is responsible for knowing the relationship between the clocks generated by the clock manager. Software must not assert a module reset signal that would prevent software from deasserting the module reset signal. For example, software should not assert the module reset to the processor executing the software.

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 output as well. Any warm reset request causes the reset manager to drive the rst_pin_oe_rst output enable high, which drives the nRST pin low. The amount of time the reset manager pulls nRST low is controlled by the nRST pin count field (nrstcnt) of the reset cycles count register (counts); the default is 2048 clocks. This technique can be used to reset external devices (such as external memories) connected to the HPS.

The following list describes how reset affects HPS logic:

• In the security manager domain, some status bits are cleared differently for cold and warm reset.
• The TAP reset domain ignores warm reset
• The Debug reset domain ignores warm reset
• The Clock Manager module is reset only by cold reset. After warm reset, the Clock Manager is put into Boot Mode.
• Each peripheral module and System Manager define reset behavior differently. See the appropriate control register for details.
• In the MPU module, the Watchdog Reset Status Registers are reset if an MPU Watchdog triggered the warm reset
• The Pin MUX is reset only by cold reset.

The reset manager participates in several reset handshaking protocols to ensure other modules are safely reset.

Before issuing a warm reset, the reset manager performs a handshake with several modules to allow them to prepare for a warm reset. The handshake logic ensures the following conditions:

• Optionally the ETR master has no pending master transactions to the L3 interconnect
• Optionally preserve SDRAM contents during warm reset by issuing self-refresh mode request
• FPGA manager stops generating configuration clock
• Warns the FPGA fabric of the forthcoming warm reset

Similarly, the handshake logic associated with ETR also occurs during the debug reset to ensure that the ETR master has no pending master transactions to the L3 interconnect before the debug reset is issued. This action ensures that when ETR undergoes a debug reset, the reset has no adverse effects on the system domain portion of the ETR.

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
• CRC error message extraction
• General purpose I/O signals to the FPGA
• Boot from FPGA control
• Generation of interrupts based on FPGA status changes

The FPGA Manager consists of the following blocks:

• Configuration Data Interface - Accepts and transfers the configuration and decryption data to the FPGA configuration sub system (CSS)
• Register Slave Interface - Accesses the control and status registers in the FPGA Manager
• CSS Control - Controls full and partial configuration of the FPGA
• CSS Monitor - Monitors the status of the FPGA during a full or partial configuration of the device
• Error Message Register (EMR) Interface - Error message extraction, in case of CRC errors in the FPGA
• General Purpose I/O Interface - Receives and drives 32 bits of general purpose I/O to and from the FPGA
• Miscellaneous Core Input Interface - Receives control input signals from the FPGA to support booting the HPS from the FPGA

You can configure the FPGA using an external device or through the HPS. This section highlights configuring the FPGA through the HPS.

The FPGA manager connects to the configuration logic in the FPGA portion of the device using a mode similar to how external logic (for example, MAX II or an intelligent host) configures the FPGA in fast passive parallel (FPP) mode. FPGA configuration through the HPS supports all the capabilities of FPP mode, including the following items:

• FPGA configuration
• Partial FPGA reconfiguration
• Decompression
• Advanced Encryption Standard (AES) encryption

The FPGA Manager can be configured to accept configuration data directly from the MPU or the DMA engine. Either the processor or the DMA engine moves data from memory to the FPGA Manager data image register space img_data_w.

Configuration data is buffered in a 64 deep x 32 bits wide FIFO in the FPGA Manager. Status information such as FIFO empty/full and remaining depth can be accessed through a status register imgcfg_stat. FIFO empty/full conditions can also be enabled to generate an interrupt.

If using the DMA engine to move FPGA configuration data to the FPGA Manager, a FIFO threshold value can be set in the dma_config register. This value is used to control the assertion of a DMA transfer request from the FPGA Manager to the DMA engine.

Before sending FPGA configuration data to the FPGA Manager HPS, software sets the clock-to-data ratio field (CDRATIO) and configuration data width bit (CFGWIDTH) in the image control 2 register (imgcfg_ctrl_02).

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, EMAC1, and EMAC2)
• Error Checking and Correction Controller (ECC) for RAMs
• Microprocessor unit (MPU) subsystem
• NAND flash controller
• Secure Digital/MultiMediaCard (SD/MMC) controller
• Quad serial peripheral interface (SPI) flash controller
• USB 2.0 On-The-Go (OTG) controllers (USB0 and USB1)
• Watchdog timers

Software accesses the CSRs in the system manager to control and monitor various functions in other HPS modules that require external control signals. The system manager connects to these modules to perform the following functions:

• Sends pause signals to pause the watchdog timers when the processors in the MPU subsystem are in debug mode
• Selects the EMAC system interconnect master access options and other EMAC clock and interface options.
• Selects the SD/MMC controller clock options and system interconnect master access options.
• Selects the NAND flash controller bootstrap options and system interconnect master access option.
• Selects USB controller system interconnect master access option.
• Provides control over the DMA security settings when the HPS exits from reset.
• Provides boot source information that can be read during the boot process.
• Provides the capability to enable or disable an interface to the FPGA.
• Provides combined ECC status and interrupts from other HPS modules with ECC-protected RAM.
• Routes parity failure interrupts from the L1 caches to the Global Interrupt Controller.
• Provides the capability to inject errors during testing in the MPU L2 ECC-protected RAM.

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 a combination of the BSEL pins and a fuse bit that can bypass the BSELpins.

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.

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 contains a register, noc_addr_remap_value, that controls how the system interconnect maps memory addresses starting at 0x00000000. This register remaps the bottom of the memory map to either boot ROM or on-chip RAM.

Refer to "Address Remapping" in the System Interconnect chapter for details about using the noc_addr_remap_value register.

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 mask the ECC interrupts from each of the following HPS modules with ECC-protected RAM:

• MPU L2 cache data RAM
• On-chip RAM
• USB 2.0 OTG controller (USB0 and USB1) RAM
• EMAC (EMAC0, EMAC1, and EMAC2) RAM
• DMA controller RAM
• NAND flash controller RAM
• Quad SPI flash controller RAM
• SD/MMC controller RAM
• DDR interfaces

The system manager can inject single-bit or double-bit errors into the MPU L2 ECC memories for testing purposes. Set the bits in the appropriate memory enable register to inject errors. For example, to inject a single bit ECC error, set the injs bit of the mpu_ctrl_l2_eccregister.

The system manager can also inject parity failures into the parity-protected RAM in the MPU L1 to test the parity failure interrupt handler. Set the bits of the parity fail injection register (parityinj) to inject parity failures.

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 Security Manager module is integrated in the Hard Processor System (HPS) and provides the overall management of security within the SoC, including:

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

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

The main components of the Security Manager architecture include:

• Fuse Control (TEST):

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

• Security State and Status Check:

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

• Encryption Data Port:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figure 19. HPS JTAG Bypass

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The SoC may securely boot in one of three ways:

1. The HPS boot and FPGA configuration occur separately.
2. The HPS boots from the FPGA after the FPGA is configured
3. The HPS boots first and configures the FPGA.

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

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

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

Three levels of boot are available to the device:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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