The Cortex^® -A53 MPCore™ supports high-performance applications and provides the capability for secure processing and virtualization. Each CPU in the processor has the following features:

• Support for 32- and 64-bit instruction sets
• In-order pipeline with symmetric dual-issue of most instructions
• Arm^® NEON™ single instruction, multiple data (SIMD) coprocessor with a floating point unit (FPU)
  • Single- and double-precision IEEE-754 floating point math support
  • Integer and polynomial math support
• Symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) modes
• Arm^® v8 Cryptography Extension
• Level 1 (L1) cache
  • 32 KB two-way set associative instruction cache
  • Single Error Detect (SED) and parity checking support for L1 instruction cache
  • 32 KB four-way set associative data cache
  • Error checking and correction (ECC), Single Error Correct, Double Error Detect (SECDED) protection for L1 data cache
• Memory Management Unit (MMU) that communicates with the system MMU (SMMU)
• Generic timer
• Governor module that controls clock and reset
• Debug modules
  • Performance Monitor Unit
  • Embedded Trace Macrocell (ETMv4)
  • CoreSight cross trigger interface

The four CPUs share a 1 MB L2 cache with ECC, SECDED protection. A snoop control unit (SCU) maintains coherency between the CPUs and communicates with the system cache coherency unit (CCU).

At a system level, the Cortex^® -A53 MPCore™ interfaces to a generic interrupt controller (GIC), CCU, and system memory management unit (SMMU).

The system MMU features include:

• A central TCU that supports five distributed TBUs for the following masters:
  • FPGA
  • DMA
  • EMAC0-2, collectively
  • USB0-1, NAND, SD/MMC, ETR, collectively
  • Secure Device Manager (SDM)
• Caches for storing page table entries and intermediate table walk data:
  • 512-entry macro translation lookaside buffer ( TLB) page table entry cache in the TCU
  • 128-entry micro TLB for table walk data in the FPGA TBU and 32-entry micro TLB for all other distributed TBUs
  • Single-bit error detection and invalidation on error detection for caches
• Communication with the MMU of the Arm^® Cortex^® -A53 MPCore™
• System-wide address translation
• Address virtualization
• Support for 32 contexts
• Two stages of translation or combined (stage 1 and stage 2) translation
• Support for up to 49-bit virtual addresses and up to 48-bit physical and intermediate physical addresses
• Programmable QoS to support page table walk arbitration
• Fault handling, logging and interrupts for translation errors
• Debug support

The Intel^® Stratix^® 10 SoC has a total of 48 flexible I/O pins that are used for HPS operation, external flash memories, and external peripheral communication. A pin multiplexing mechanism allows the SoC to use the flexible I/O pins in a wide range of configurations.

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 DMA controller is software configurable to perform byte lane swapping during a transfer.

The Arm^® Cortex^® -A53 MPCore™ is composed of four Arm^® v8-A architecture central processing units (CPUs), a level 2 (L2) cache, and debugging modules. Advanced functions, such as floating point operations and cryptographic extensions, are supported.

The Arm^® Cortex^® -A53 MPCore™ Processor contains four CPUs that implement the Arm^® v8-A architecture instruction set. Each CPU has identical integration.

• Support for 32- and 64-bit instruction sets
• In-order pipeline with symmetric dual-issue of most instructions
• Arm^® NEON™ single instruction, multiple data (SIMD) coprocessor with a floating point unit (FPU)
  • Single- and double-precision IEEE-754 floating point math support
  • Integer and polynomial math support
• Symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) modes
• Arm^® v8 Cryptography Extension
• Level 1 (L1) cache
  • 32 KB two-way set associative instruction cache
  • Single Error Detect (SED) and parity checking support for L1 instruction cache
  • 32 KB four-way set associative data cache
  • ECC, Single Error Correct, Double Error Detect (SECDED) protection for L1 data cache
• Memory Management Unit (MMU) that communicates with system MMU (SMMU)
  • 10-entry fully-associative instruction micro translation lookaside buffer (TLB)
  • 10-entry fully-associative data micro TLB
  • 512‑entry unified TLB
• Generic timer
• Governor module that controls clock and reset
• Debug modules
  • Performance Monitor Unit
  • Embedded Trace Macrocell (ETMv4)
  • CoreSight cross trigger interface

Some integration is also shared among the four CPUs in the Cortex^® -A53 MPCore processor.

• 1 MB Arm^® L2 cache controller with ECC, SECDED protection
• Snoop Control Unit (SCU) that maintains coherency between CPUs and communicates with the system CCU
• Global timer

The Cortex^® -A53 MPCore™ processor seamlessly supports 32-bit and 64-bit instruction sets. It implements the full Arm^® v8-A architecture and has a highly efficient 8-stage in-order pipeline enhanced with advanced fetch and data access techniques that provide high performance and low power.

• Stage 1 maps the virtual address (VA) to an intermediate physical address (IPA). This translation is managed at EL1, usually by a guest OS. The guest OS believes that the IPA is the physical address (PA).
• Stage 2 maps the IPA to the PA. This translation is managed at EL2. The guest OS might be completely unaware of this stage. For more information on the translation regimes, see the System Memory Management Unit chapter.

The Cortex-A53 MPCore™ processor contains virtualization registers that allow you to configure translation tables, hypervisor operations, exception levels, and virtual interrupts, For more information, please refer to the Arm^® Cortex-A53 MPCore™ Processor Technical Reference Manual.

When a virtual interrupt is enabled, its corresponding physical exception is taken to EL2, unless EL3 has configured that physical exception to be taken to EL3.

Software executing in EL2 can use virtual interrupts to signal physical interrupts to non-secure EL1 and non-secure EL0.

The MMUs support 40-bit physical address size and two stages of translation. You can enable or disable each stage of address translation independently.

The Cortex^® -A53 MPCore™ communicates with the system memory management unit (SMMU) when pages are invalidated in a CPU's MMU.

For more information regarding the SMMU, refer to the System Memory Management Unit chapter.

The micro TLBs are the first level of caching for the translation table information. The unified main TLB handles misses from the micro TLBs.

When the main TLB performs maintenance operations it flushes both the instruction and data micro TLBs.

The ARMv8-A architecture supports multiple mappings of the virtual address space, which are translated differently. The TLB entries store all the required context information to facilitate a match and avoid a TLB flush or a context or virtual machine switch.

Each TLB entry contains a virtual address, block size, physical address, and a set of memory properties that include the memory type and access permissions. Each entry is associated with a particular application space ID (ASID), or is global for all application spaces.

The TLB entry also contains a field to store the virtual memory ID (VMID) for accesses made from the non-secure EL0 and EL1. A memory space identifier in the TLB entry records whether the request occurred at the:

• EL3, if EL3 is in the AArch64 execution state
• Non-secure EL2 exception level
• Secure and non-secure EL0 or EL1 and EL3, when EL3 is in AArch32 execution state

The prefetcher is enabled by default at reset. You may configure the sequence length that triggers the prefetcher or the number of outstanding requests the prefetcher can make by programming the CPU Auxiliary Control (CPUACTLR) register.

• When the processors are set to SMP mode, the SCU maintains data cache coherency between the processors.
  Note: The SCU does not maintain coherency of the instruction caches.
• The SCU reduces latency by using buffers to execute cache-to-cache transfers between CPUs without accessing external memory.
• The SCU can accept up to eight requests from the system.

The SCU communicates with the system-level cache coherency unit (CCU) to maintain coherency between the two modules.

When the processor writes to any coherent memory location, the SCU ensures that the relevant data is coherent (updated, tagged or invalidated). Similarly, the SCU monitors read operations from a coherent memory location. If the required data is already stored within the other processor’s L1 cache, the data is returned directly to the requesting processor. If the data is not in L1 cache, the SCU issues a read to the L2 cache. If the data is not in the L2 cache memory, the read is finally forwarded to main memory. The primary goal is to maximize overall memory performance and minimize power consumption.

The SCU maintains bidirectional coherency between the L1 data caches belonging to the processors. When one processor performs a cacheable write, if the same location is cached in the other L1 cache, the SCU updates it.

Non‑coherent data passes through as a standard read or write operation.

If multiple CPUs attempt simultaneous access to the L2 cache, the SCU arbitrates among them.

Cryptographic functions are an extension of the SIMD support and operate on the vector register file. This extension provides instructions for the acceleration of encryption and decryption to support:

The cryptographic extension also provides multiply instructions that operate on long polynomials.

The NEON™ processing engine accelerates multimedia and signal processing algorithms such as video encoding and decoding, 2‑D and 3‑D graphics, audio and speech processing, image processing, telephony, and sound synthesis.

The Cortex^® -A53 MPCore NEON MPE performs the following types of operations:

• SIMD and scalar single-precision floating-point computations
• Scalar double-precision floating-point computation
• SIMD and scalar half-precision floating-point conversion
• 8‑, 16‑, 32‑, and 64‑bit signed and unsigned integer SIMD computation
• 8‑bit or 16‑bit polynomial computation for single‑bit coefficients

The following operations are available:

• Addition and subtraction
• Multiplication with optional accumulation (MAC)
• Maximum- or minimum-value driven lane selection operations
• Inverse square root approximation
• Comprehensive data-structure load instructions, including register-bank-resident table lookup

The ACE bus interface operates in the mpu_ccu_clk domain, which is mpu_clk/2. This bus provides an AXI3 compatibility mode with support for privilege level accesses through the ARPROTM[0] and AWPROTM[0] signals.

The Cortex^® -A53 MPCore™ processor does not generate any FIXED bursts and all WRAP bursts fetch a complete cache line starting with the critical word first. A burst does not cross a cache line boundary. The cache linefill fetch length is always 64 bytes. The Cortex^® -A53 generates only a subset of all possible AXI transactions on the master interface.

For WriteBack transfers the supported transfers are:

• WRAP 4 128-bit for read transfers (linefills).
• INCR 4 128-bit for write transfers (evictions).
• INCR N (N:1, 2, or 4) 128-bit write transfers (read allocate).

For non-cacheable transactions:

• INCR N (N:1, 2, or 4) 128-bit for write transfers.
• INCR N (N:1, 2, or 4) 128-bit for read transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit for read transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit for write transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit for exclusive write transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit for exclusive read transfers.

For Device transactions:

• INCR N (N:1, 2, or 4) 128-bit read transfers.
• INCR N (N:1, 2, or 4) 128-bit write transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit read transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit write transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit exclusive read transfers.
• INCR 1 8-bit, 16-bit, 32-bit, 64-bit, and 128-bit exclusive write transfers.

For translation table walk transactions INCR 1 32-bit, and 64-bit read transfers.

The following characteristics apply to AXI transactions:

• WRAP bursts are only 128-bit.
• INCR 1 can be any size for read or write.
• INCR burst, more than one transfer, are only 128-bit.
• No transaction is marked as FIXED.
• Write transfers with all, some or no byte strobes HIGH can occur.

The L1 instruction cache provides parity checking with single error detection (SED). Double bit errors are not detected or corrected.

The L1 data cache and L2 cache provide single error correction and double error detection (SECDED). If a single-bit error is detected, the access that caused the error is stalled while the correction takes place. After correction, the access that was stalled continues or is retried.

Detected errors are reported in the CPUMERRSR or L2MERRSR registers and also signaled on the PMUEVENT bus. Detected errors include errors that are successfully corrected, and those that cannot be corrected. If multiple errors occur on the same clock cycle then only one of them is reported.

Errors that cannot be corrected, and therefore might result in data corruption, also cause an abort. Your software can register this error and can either attempt to recover or can restart the system.

When an L1 data or L2 dirty cache line with an error on the data RAMs is evicted from the processor, the write on the master interface still takes place. However, if the error is uncorrectable, then the incorrect data is not written externally.

The Arm^® Generic Interrupt Controller (GIC-400) resides within the system complex outside of the Cortex^® -A53 processor. The GIC is shared by all of the Cortex^® -A53 CPUs.

The GIC has software-configurable settings to detect, manage and distribute interrupts in the SoC.

• Interrupts are enabled or disabled and prioritized through control registers.
• Interrupts can be prioritized and signaled to different processors.
• You can configure interrupts as secure or non-secure by assigning them to group 0 or group1, respectively.
• Virtualization extensions within the GIC allow you to manage virtualized interrupts.

Each CPU generates a signal for every private peripheral interrupt ID (PPI ID). There is only one input signal for each SPI interrupt ID shared among the four CPUs. The GIC supports virtual interrupts as well.

The GIC notifies each CPU of an interrupt or virtual interrupt through output signals sent to the Cortex^® -A53 MPCore™ .

The configuration and control for the GIC is memory-mapped and accessed through the cache coherency unit (CCU).

The GIC operates in the mpu_periph_clk domain which is mpu_clk/4.

The GIC is reset on a cold or warm reset. All interrupt configurations are cleared upon a cold or warm reset.

The generic timer of each CPU contains a set of timer registers to capture a variety of events:

• non-secure physical events
• secure physical events
• physical events
• virtual events

The four timers provided in each CPU are:

• EL1 non-secure physical timer register
• EL1 secure physical timer register
• EL2 virtual physical timer register
• Hypervisor timer register

You can configure the generic timers as count-up or count-down timers and they can operate in real-time and during virtual memory operation. You can also program a starting value for each generic timer.

Each of these timers has a 64‑bit comparator that generates a private interrupt when the counter reaches the specified value. These interrupts are sent as a private peripheral interrupt with separate PPI ID.

For more information about the generic timers, please refer to the Arm^® Cortex^® -A53 MPCore Processor Technical Reference Manual, and the Arm^® Architecture Reference Manual ARMv8, for ARMv8-A Architecture.

This system counter measures the passing of time in real-time. A 64-bit bus interface carries the system timer value to each CPU and this value is used as a basis for the four generic timers. The system timer operates in the mpu_periph_clk domain, which is mpu_clk/4.

The Cortex^® -A53 MPCore™ provides the following assistance for debug:

• Support for JTAG interface
• Embedded trace interface, which includes program and event trace
• Cross-trigger interface (CTI) that communicates between processors and other HPS debug modules

Each of the four CPUs in the Arm^® Cortex^® -A53 MPCore™ supports self-hosted debug and external debug. When you use self-hosted debug, you can use debug instructions to move the CPU into a debug state. When you use external debug, you can configure debug events to trigger the CPU to enter a debug state that is controlled by an external debugger.

Each Cortex^® -A53 MPCore™ CPU has built-in debugging capabilities, including six hardware breakpoints (two with Context ID comparison capability) and four watchpoints. The interactive debugging features can be controlled by external JTAG tools or by processor-based monitor code.

Each Arm^® v8-A CPU has a Performance Monitoring Unit (PMU) that enables events such as cache misses and executed instructions to be counted over a period of time. The PMU supports 58 events to gather statistics on the operation of the processor and memory system. You can use up to six counters in the PMU to count and record events in real time. The PMU counters are 32-bit and are enabled based on events.

You can access each CPU's PMU counters through the system interface or from an external debugger. The events are also supplied to the Embedded Trace Macrocell (ETM) and can be used for trigger or trace.

Each processor has an independent program trace monitor (PTM) that provides real-time instruction flow trace. The PTM is compatible with a number of third-party debugging tools.

The PTM provides trace data in a highly compressed format. The trace data includes tags for specific points in the program execution flow, called waypoints. Waypoints are specific events or changes in the program flow.

The PTM recognizes and tags the waypoints listed in Table 36.

The PTM optionally provides additional information for waypoints, including the following:

• Processor cycle count between waypoints
• Global timestamp values
• Target addresses for direct branches

Events from each processor can be used as inputs to the PTM. The PTM can use these events as trace and trigger conditions.

The Cortex^® -A53 processor has a cross trigger interface (CTI) that communicates with ARM's CoreSight module. The CTI enables debug logic, ETM and PMU to interact with each other and with other HPS debugging components including the FPGA fabric. The ETM can export trigger events and perform actions on trigger inputs. Also, a breakpoint in one CPU can trigger a break in the other.

The Cache Coherency Unit (CCU) resides outside of the Cortex^® -A53 MPCore™ processor and maintains data coherency within the SoC system. Masters in the system, including HPS peripheral and user logic in the FPGA, can access coherent memory through the CCU. The FPGA interfaces to the CCU through the FPGA-to-HPS bridge.

The CCU provides I/O coherency. I/O coherency, also called one-way coherency, allows a CCU master to see the coherent memory visible to the Cortex^® -A53 processor but does not allow the Cortex^® -A53 processor to see memory changes outside of its cache.

The masters that communicate with the CCU can read coherent memory from the L1 and L2 caches, but cannot write directly to the L1 cache. If a master performs a cacheable write to the CCU, the L2 cache updates. Any of the cacheable write locations that reside in the L1 data cache are invalidated because the L2 cache has the latest copy of those addresses.

The CCU communicates with the SCU within the Cortex^® -A53 MPCore™ to provide coherency with the SCU.

For more information, please refer to the Cache Controller Unit Chapter.

The CCU comprises a coherency interconnect, cache coherency controller (CCC), an I/O coherency bridge (IOCB) and support for distributed virtual memory (DVM).

The Intel^® Stratix^® 10 Hard Processor System (HPS) cache coherency unit (CCU) ensures consistency of shared data. Dedicated master peripherals in the HPS and those built in FPGA logic access coherent memory through the CCU. Cacheable transactions from the system interconnect route to the CCU.

The CCU provides I/O coherency with the Arm^® Cortex^® -A53 MPCore™ cache subsystem. I/O coherency, also called one-way coherency, allows HPS peripheral and FPGA masters (I/O masters) to see the same coherent view of system memory as the Cortex^® -A53 MPCore™ processor cores, but does not allow the Cortex^® -A53 MPCore™ processor cores to be coherent with any caches residing in I/O masters. The CCU also contains error protection logic and logic for optimal performance during coherent accesses. The CCU forwards non-coherent accesses directly to the addressed slave port.

The following master ports interface to the CCU:

• Cortex^® -A53 MPCore™ processor
• FPGA-to-HPS bridge
• Translation Control Unit (TCU) located in the SMMU
• HPS peripheral master ports interfacing to the system interconnect:
  • EMAC0/1/2
  • USB0/1
  • DMA
  • SD/MMC
  • NAND
  • Embedded Trace Router (ETR)

• Coherency directory to track the state of the 1 MB L2 cache in the Arm^® Cortex^® -A53 MPCore™
• Snoop filter support
• Speculative fetch support for lower latency accesses
• Single-bit error correction and double-bit error detection (SECDED) in the coherency directory
• Support for distributed virtual memory (DVM) using the Arm^® Advanced Microcontroller Bus Architecture ( AMBA^® ) Advanced eXtensible Interface ( AXI^® ) Coherency Extensions, also known as the ACE protocol. The CCU sends distributed virtual memory broadcast messages to the Cortex^® -A53 MPCore™ and the TCU in the SMMU.
• Quality of service (QoS) support for transaction prioritization using a weight bandwidth allocation
• Flexible address range programming for each master-to-slave connection
• Interconnect debug capability through master and slave bridge status registers
• Interrupt support for CCU transaction and counter events

The CCU's coherency interconnect routes master agent transactions to the cache coherency components within the interconnect and ultimately, to the slave agents.

The CCU manages one-way coherency with the Cortex^® -A53 MPCore™ . The CCU allows the master agents (masters connected to the CCU) to see the coherent memory of the Cortex^® -A53 MPCore™ processor cores but does not allow the processor cores to be coherent with any caches external to the Cortex^® -A53 MPCore™ processor.

The "CCU Block Diagram" shows the master agents of the CCU, the CCU components and the slaves that connect to it. The following master agent ports interface to the CCU:

• The Cortex^® -A53 MPCore™ port:
  • Connects the Cortex^® -A53 MPCore™ subsystem to the CCU
  • Supports memory read and write requests, as well as I/O memory-mapped read and write requests
  • Includes read and write channels and their corresponding response channels
  • Supports channels for snoop requests, snoop responses and signals used as part of the coherency protocol to indicate response arrival.
• The FPGA-to-HPS ACE-lite port connects the FPGA-to-HPS bridge to the CCU and supports I/O coherent requests to the CCU.
• The peripheral master port supports I/O coherent and non-coherent requests to the CCU from masters connected to the level 3 (L3) interconnect.
• The TCU port provides a page table walk interface to transfer I/O coherent requests to the CCU. This interface includes a DVM interface to send translation look-aside buffer (TLB) control information between the Cortex^® -A53 MPCore™ and the system MMU.

The coherency bridge accepts requests from the ACE, ACE-lite + DVM and ACE-lite buses of the master agent ports. The coherency bridge sends these requests to the cache coherency controller.

The CCU directory tracks the state of the 1 MB L2 cache in the Arm^® Cortex^® -A53 MPCore™ .

The bridges control address range and QoS, and track the transmitting logic and FIFO status. You can control and view these features through registers in the CCU.

Routers within the CCU coherency interconnect send transactions to the appropriate coherency components within the CCU or to the appropriate slave port bridge where they are de-packetized and converted to the appropriate slave agent bus protocol.

Cacheable accesses from the Cortex^® -A53 MPCore™ processor route directly to the CCU where the coherency directory is updated. The CCU forwards non-cacheable accesses directly to the slave.

Master agents with ACE-lite and ACE-lite + DVM bus interfaces send transactions to the I/O coherency bridge (IOCB). The IOCB sends coherent requests to the cache coherency controller (CCC) where a directory lookup determines if the address resides within a cache line of the MPU L2 cache. The coherency directory tracks the state of the 1 MB L2 cache.

The distributed virtual memory (DVM) controller supports the AMBA^® ACE DVM protocol. The DVM controller broadcasts and synchronizes control packets for TLB invalidations, cache invalidations and similar requests.

The coherency interconnect in the CCU accepts both coherent and non-coherent transactions from masters in the system. The coherency interconnect routes non-coherent transactions to the appropriate agent target. Coherent transactions are initially routed to either the CCC or the IOCB in the CCU.

All accesses from the Cortex^® -A53 MPCore™ are routed through the CCU so the coherency directory can be updated. TCU and FPGA-to-HPS bridge accesses and peripheral master accesses coming from the L3 interconnect are routed to the CCU if they are cacheable. Non-cacheable accesses route directly to the slave.

For more information about TBUs and distributed virtual memory support, refer to the "Distributed Virtual Memory Controller" section.

The CCU interfaces with the L3 interconnect and the SDRAM L3 interconnect. The SDRAM L3 interconnect provides a 64-bit register bus interface to the CCU for accessing the L3 SDRAM adapter, L3 SDRAM scheduler and hard memory controller registers. The CCU accesses external memory through a 128-bit interface to the SDRAM L3 interconnect.

Each bridge has a set of corresponding registers that you can configure. All of the registers for a bridge configuration begin with a specific bridge register prefix.

The coherency directory acts as a snoop filter and allows the CCC to locally determine the state of the cache line without sending snoops to the L2 cache.

The cache coherency unit uses a directory-based coherency protocol. The CCU has a memory structure that tracks the state of the L2 cache lines.

The coherency directory stores cache line addresses and state information about each address. The directory does not store cache line data. It is not a cache. The coherency directory only contains address and state information that other master agents snoop when making coherent accesses. The directory acts as a snoop-filter and assists the cache coherency controller in locally determining the state of a cache line without sending snoops to the L2 cache.

The directory-based protocol provides lower latency accesses, reduced network bandwidth, reduced snoop traffic for the Cortex^® -A53 MPCore™ , and higher peak bandwidth of the system.

When the Cortex^® -A53 MPCore™ replaces a cache line, it sends an evict request to the coherency directory for any clean lines it is dropping. The directory no longer tracks those addresses after the eviction request completes.

The data RAM provides 8-bits for ECC. You can program registers to directly access the directory RAM, including the ECC check bits. The hardware supports multiple ways to test ECC logic within the system, including taking an existing directory entry and flipping one or more bits before writing the entry back into the array.

You can disable ECC detection and correction through the ECC Disable Register (agent_ccc0_ccc_ecc_disable) at offset 0x30028 in the CCU.

Speculative fetching can reduce the latency of the request but may expend memory bandwidth with unnecessary memory reads. It is recommended that you enable speculative fetch for latency sensitive requests. Disable this feature for requests that are less latency sensitive.

Speculative fetching for the Cortex^® -A53 MPCore™ processor is enabled when the HPS is released from reset. To disable speculative fetch, clear the corresponding bit in the Speculative Fetch register (agent_ccc0_ccc_spec_fetch_0).

These masters send both non-coherent and I/O coherent traffic to the IOCB. If a master issues a WriteUnique or WriteLineUnique ACE protocol request and that address corresponds to a cache line, the IOCB notifies the Cortex^® -A53 MPCore™ processor to invalidate that data. The IOCB prefetches coherent permissions for requests from the coherency directory so that it can execute these requests in parallel with non-coherent requests and maintain high bandwidth.

DVM protocol broadcasts and synchronizes control packets for TLB invalidations, instruction cache invalidations, and similar requests.

As part of the SMMU, TBUs sit between the master peripherals and the L3 interconnect. The FPGA-to-HPS interface also passes through a TBU before interfacing with the CCU.

Each TBU contains a micro translation look-aside buffer (TLB) that holds cached page table walk results from the translation control unit (TCU). For every virtual memory transaction that a master initiates, its TBU compares the virtual address against the translations stored in its buffer to see if a physical translation exists. If a translation does not exist, the TCU performs a page table walk. This SMMU integration allows the master peripheral's driver to pass virtual addresses directly to the master peripheral without having to perform virtual to physical address translations through the operating system.

For more information about distributed virtual memory support and the SMMU, refer to the System Memory Management Unit chapter.

You can enable the ECC error or event counter overflow interrupts in the CCC by programming the CCC Interrupt Mask register (agent_ccc0_ccc_interrupt_mask) at offset 0x30190. You can track the interrupt status by reading the CCC Interrupt Status register (agent_ccc0_ccc_interrupt_err) at offset 0x30198.

You can enable read, write or counter overflow error interrupts in a specific bridge by programming the bridge's Interrupt Mask register (*am_intm*). You can track error status by reading the bridge's Status and Error register (*am_err*).

The system memory management unit (SMMU) provides memory management services to system bus masters. The SMMU translates input addresses to output addresses based on address mapping and memory attribute information in the SMMU registers and translation tables. The SMMU also provides caching attributes for physical pages. A single translation control unit (TCU) manages distributed translation buffer units (TBUs) and performs page table walks (PTWs) on translation misses.

The SMMU conforms to the Arm^® SMMU v2 Specification.

• Central TCU that supports five distributed TBUs for the following masters:
  • FPGA
  • DMA
  • EMAC0-2, collectively
  • USB0-1, NAND, SD/MMC, ETR, collectively
  • Secure Device Manager (SDM)
• Integrates caches for storing page table entries and intermediate table walk data
  • 512-entry macro TLB page table entry cache in the TCU
  • 128-entry micro TLB for table walk data in the FPGA TBU and 32-entry micro TLB for all other distributed TBUs
  • Single-bit error detection and invalidation on error detection for caches
• Communicates with the MMU of Arm^® Cortex^® -A53 MPCore™
• System-wide address translation
• Address virtualization
• Support for 32 contexts
• Allows two stages of translation or combined (stage 1 and stage 2) translation
  • Secure or non-secure translation capability in stage 1
  • Support for modifying attributes from stage 1 to stage 2 translation
  • Capable of multiple levels of address lookup
  • Allows bypassing or disabling stages
• Supports up to 49-bit virtual addresses and up to 48-bit physical and intermediate physical addresses
• Provides programmable Quality of Service (QoS) to support page table walk arbitration
• Provides fault handling, logging and interrupts for translation errors
• Supports debug

The TBUs interface to the following masters:

• FPGA
• DMA
• EMAC0-2, collectively
• USB0-1, NAND controller, SD/MMC controller, Arm^® Embedded Trace Router (ETR), collectively
• Secure Device Manager (SDM)

Each of the TLBs within the TBUs cache frequently used address ranges. By having multiple TBUs, the frequently cached addresses in the TLBs are localized to the masters connected to them. The TCU performs the page table walks on address misses.

The Cortex^® -A53 MPCore™ has its own main and micro translation lookaside buffers (TLBs) for address translation but communicates with the SMMU so that its translation tables remain coherent. For more information about the Cortex^® -A53 MPCore™ MMU, refer to the Cortex^® -A53 MPCore™ chapter.

• In stage 1 translations, the virtual address (VA) input is translated to a physical address (PA) or intermediate physical address (IPA) output. Both secure and non-secure translation contexts use stage 1 translations. Typically, an OS defines translations tables in memory for the stage 1 translations of a given security state. The OS also configures the SMMU for the stage 1 translations before enabling the SMMU to accept transactions.

  An example of a stage 1 translation could be a guest OS that translates addresses on a system that supports multiple OSs. In this case, the translation from virtual address to physical address is really a translation from virtual address to intermediate physical address that is managed along with other OS IPAs by a virtual machine manager.

• In stage 2 translations, an IPA input is translated to a PA output. Only non-secure translation contexts can use stage 2 translations. An example of stage 2 translation could be a hypervisor translating a particular guest OS IPA to a PA.
• Stage 1 and stage 2 translations may be combined so that a VA input is translated to an IPA output and then an IPA input is translated to a PA output. The translation control unit (TCU) of the SMMU performs translation table walks for each stage of translation. An example of a combined translation could be:
  • A non-secure operating system defines the stage 1 translations for application level and operating system level operation. It does this assignment assuming it is mapping from the VAs used by the processors to the PAs in the physical memory system. However, it actually maps from VAs to IPAs.
  • The hypervisor defines the stage 2 address translations that map the IPAs to PAs. It does this as part of its virtualization of one or more non-secure guest operating systems.

Each stage of translation can require multiple translation table lookups or levels of address lookups. The SMMU can also modify memory attributes from stage 1 to stage 2 translation. You can also program the SMMU to disable or bypass a stage translation and modify the memory attributes of that disabled or bypassed stage.

Depending on the security state, only certain exception levels are allowed.

The figure below shows the supported translation regimes when EL3 is using AArch64. The non-secure EL1and EL0 translation regime comprises two stages of translation. All other translation regimes shown below comprise only a single stage of translation.

The FPGA TBU caches page table walk results for FPGA-issued accesses to the FPGA-to-HPS bridge. Details of the FPGA TBU configuration are shown in the table below.

The Cortex^® -A53 MPCore™ has its own TBU configuration. Details on this TBU can be found in the Cortex^® -A53 MPCore™ chapter.

The TCU cache consists of macro TLB, prefetch buffers, IPA to PA support and PTW caches.

The prefetch buffer fetches pages up to 16 KB in size. The prefetch buffer is a single four-way associative cache that you can enable or disable depending on the context.

• A transaction is either secure or non-secure depending on the value of the APROT[1] signal.
• The stream has an assigned SSD security state that determines whether secure or non-secure software controls the stream.

Each transaction is classified through a security state determination (SSD) as either SSD secure or SSD non-secure. The current bus transaction provides an SSD_index that points to a bit in the smmu_ssd_reg_* registers. For a given transaction, the device is either SSD secure or SSD non-secure. This bit determines the SSD security state.

For an SSD secure transaction, the APROT[1] signal can indicate whether it is secure or non-secure and the information is generally passed downstream. However, an SSD non-secure transaction is forced by the SMMU to indicate non-secure transaction in the APROT[1] signal on the downstream. For each SSD security state, set the SMMU_SCR0.CLIENTPD bit field if you want all transactions to bypass the translation process of the SMMU.

Each transaction is also classified by a 10-bit stream ID. The stream ID represents a set or stream of transactions from a particularmaster device. All transactions in a stream are subject to the same translation process. For example, the DMA controller may have multiple independent threads of execution that each form a different stream and can be subject to different translations. Alternatively, the peripheral masters on the system interconnect may share a single stream ID. Transactions from these devices can only be translated as a single entity. The TCU matches the stream ID against a set of stream match registers, SMMU_SMRx. The SSD security state determines the set of registers that are used. The secure software can partition the set into a non-secure set for use by SSD non-secure transactions and a secure set for use by SSD secure transactions. The stream matching process results in the following possible outcomes:

• No matches: If no matches are found, you can select whether transactions bypass the SMMU.
• Multiple match: If multiple SMMU_SMRn matches are found, the SMMU faults the transactions. The fault detection for these transactions is imprecise.
• Single match: If only a single match is found, the corresponding SMMU_S2CRn for the SMMU_SMRn that matched is used to determine the required additional processing steps.

For each SMMU_SMRn, there is a corresponding SMMU_S2CRn that is used when only a single SMMU_SMRn matches. The SMMU_S2CRn.TYPE bit field determines one of the following results:

• Fault All transactions generate a fault. A client device receives a bus abort if SMMU_sCR0.GFRE == 1, otherwise the transaction acts as read-as-zero/write-ignored (RAZ/WI).
• Bypass transactions bypass the SMMU.
• Translate transactions are mapped to a context bank for additional processing. The SMMU_S2CRn.CBNDX bit field specifies the context bank to be used by the SMMU.

The second stage boot loader configures the stream ID for the SDM-to-HPS TBU interface. The FPGA-to-HPS interface provides its stream ID. You can specify the FPGA-to-HPS stream ID value in Intel^® Quartus^® Prime.

You can configure the stream ID for each HPS peripheral master through registers in the System Manager. The table below lists the peripheral masters, the corresponding System Manager register used to configure the stream ID and the specific bitfields that represent the stream ID. During a master access the stream ID source is provided as a part of the AxUSER[12:3] signals.

The TCU generates page table walks for all the TBUs. If there are multiple outstanding transactions in the TCU, the TBU with the highest quality of service (QoS) is given priority. For individual prefetch accesses, the SMMU uses the QoS value of the hit transaction. For transactions with the same QoS value, the SMMU translates the transactions in the order they occur. The QoS for each TBU is programmed in the System MMU TBU Quality of Service 0 (SMMU_TBUQOS0) register at offset 0x2100.

The SMMU resets on a power-on, cold, or warm reset. On any one of these resets:

• TCU caches are cleared
• TLB entries are invalidated
• System configuration registers return to their reset state, which may by undefined
  Note: You must reconfigure the SMMU for each transaction client after reset.

The system interconnect has the following characteristics:

• Arm^® TrustZone^® -compliant security firewalls
  • For each peripheral, implements secure or nonsecure access
  • Optionally configures individual transactions as secure or nonsecure at the initiating master
  • For certain peripherals, optionally implements two levels of access: privileged or user
• Three tiers of connectivity:
  • The main level 3 (L3) interconnect—Provides high-bandwidth routing between masters and slaves in the HPS.
  • The SDRAM L3 interconnect—Provides access to a hard memory controller in the FPGA fabric. A multiport front end (MPFE) scheduler enables multiple masters in the SoC device to share the external SDRAM.
  • The level 4 (L4) buses—Independent buses handling:
    • Data traffic for low- to mid-level bandwidth slave peripherals
    • Accesses to peripheral control and status registers throughout the address map
    The L4 buses are divided among several clock domains.
• Quality of service (QoS) with three programmable levels of service on a per-master basis.
• Byte oriented address handling.
• Data bus width up to 128 bits.

Each system interconnect packet carries a transaction between a master and a slave. The interconnect provides interface widths up to 128 bits, connecting to the L4 slave buses and to HPS and FPGA masters and slaves.

The system interconnect provides low-latency connectivity to the following interfaces:

• HPS-to-FPGA bridge
• Lightweight HPS-to-FPGA bridge
• FPGA-to-HPS bridge
• Three FPGA-to-SDRAM ports

The SDRAM L3 interconnect is part of the system interconnect, and includes these components:

• SDRAM scheduler
• SDRAM adapter

The SDRAM L3 interconnect operates in a clock domain that is 1/2 the speed of the external SDRAM interface clock frequency.

The SDRAM L3 Interconnect contains an SDRAM scheduler and an SDRAM adapter. The SDRAM scheduler functions as a multi-port front end (MPFE) for multiple HPS masters. The SDRAM adapter is responsible for connecting the HPS to the SDRAM hard memory controller in the FPGA portion of the device. The SDRAM L3 interconnect is part of the system interconnect.

• Connectivity to the SDRAM hard memory controller supporting:
  • DDR4-SDRAM
  • DDR3-SDRAM
  • LPDDR3-SDRAM
• Integrated SDRAM scheduler, functioning as a multi-port front end (MPFE)
• Configurable external SDRAM interface data widths
  • 16-bit, with or without 8-bit error-correcting code (ECC)
  • 32-bit, with or without 8-bit ECC
  • 64-bit, with or without 8-bit ECC
• High-performance ports
  • CCU port supporting coherent accesses for MPU L2 Cache master, HPS peripheral DMA masters, and FPGA masters through the FPGA-to-HPS Bridge
  • Three 32-, 64-, or 128-bit FPGA ports
  • Per-port firewall security support
• 8-bit Single Error Correction, Double Error Detection (SECDED) ECC

The SDRAM adapter is responsible for bridging the SDRAM scheduler to the hard memory controller (in the FPGA portion of the device). The adapter is also responsible for ECC generation and checking.

The ECC register interface provides control to perform memory and ECC logic diagnostics.

The SDRAM scheduler is a multi-port front end (MPFE) responsible for arbitrating collisions and optimizing performance in traffic to the SDRAM controller in the FPGA portion of the device.

The SDRAM L3 interconnect exposes three ARM Advanced Microcontroller Bus Architecture (AMBA^®) Advanced eXtensible Interface (AXI™) ports to the FPGA fabric, allowing soft logic masters to access the SDRAM controller through the same scheduler unit as the MPU system complex and other masters within the HPS. The MPU has access to the SDRAM adapter's control interface to the hard memory controller.

The SDRAM L3 interconnect has a dedicated connection to the hard memory controller in the FPGA portion of the device. This connection allows the hard memory controller to become operational before the rest of the FPGA has been configured.

Arbitration and QoS logic work together to enable optimal performance in your system. For example, by setting QoS parameters, you can prevent one master from using up the interconnect's bandwidth at the expense of other masters.

The system interconnect supports QoS optimization through programmable QoS generators. The QoS generators are located on interconnect initiators, which correspond to master interfaces. The initiators insert packets into the interconnect, with each packet carrying a transaction between a master and a slave. Each QoS generator creates control signals that prioritize the handling of individual transactions to meet performance requirements.

Arbitration and QoS in the HPS system interconnect are based on the following concepts:

• Priority—Each packet has a priority value. The arbitration logic generally gives resources to packets with higher priorities.
• Urgency—Each master has an urgency value. When it initiates a packet, it assigns a priority equal to its urgency.
• Pressure—Each data path has a pressure value. If the pressure is raised, packets on that path are treated as if their priority was also raised.
• Hurry—Each master has a hurry value. If the hurry is raised, all packets from that master are treated as if their priority was also raised.

Proper QoS settings depend on your performance requirements for each component and peripheral, and for system performance as a whole. Intel recommends that you become familiar with QoS optimization techniques before you try to change the QoS settings in the HPS system interconnect.

Through the service network, you can perform these tasks:

• Access internal interconnect registers
• Update master and slave peripheral security features

The observation network connects probes to the observer, which is a port in the CoreSight™ trace funnel. Through the observation network, you can perform these tasks:

• Enable error logging
• Selectively trace transactions in the system interconnect
• Collect HPS transaction statistics and profiling data

The observation network consists of probes in key locations in the interconnect, plus connections to observers. The observation network works across multiple clock domains, and implements its own clock crossing and pipelining where needed.

The observation network sends probe data to the CoreSight subsystem through the AMBA^® Trace Bus (ATB) interface. Software can enable probes and retrieve probe data through the interconnect observation registers.

The system interconnect, in conjunction with the system MMU (SMMU), provides access to a 132-GB address space.

Address spaces are divided into one or more regions.

The following figure shows the relationships between the HPS address spaces. The figure is not to scale.

The table below shows the HPS address spaces and the masters that access those address spaces.

Each address space uses some or all of a 132-GB address range. Depending on the configuration, different address spaces are visible in different regions for each master.

There are several address spaces that overlap each other, giving masters access to common space such as shared memory or CSRs. Within a given address map, the space is contiguous and non-overlapping. No peripheral mappings overlap makes it unnecessary to segment the space.

The MPU address space is 132 GB, and applies to addresses generated by the MPU. MPU private registers (SCU and L2) and the GIC are visible only to the MPU. The MPU address map covers the entire HPS address map.

The MPU address space contains the following regions:

• The boot region, starting at 0x_FFE0_0000 in RAM
• The FPGA slaves window region, including the HPS-to-FPGA and lightweight HPS-to-FPGA regions
• The peripheral region

The FPGA-to-HPS bridge sees the same address space as the MPU, except for private registers (SCU and L2) and the GIC, which are visible only to the MPU.

The SDRAM address space is 128 GB. It is accessed through the FPGA-to-SDRAM interface from the FPGA. Note that the FPGA-to-SDRAM interface provides the only address map that can access the entire 128 GB memory range without gaps.

There are cacheable and non-cacheable views into the SDRAM space. Both views are managed by the CCU.

Some of the peripheral masters connected to the system interconnect do not have the ability to drive the caching and buffering signals of their interfaces. The system manager provides registers so that you can enable cacheable and bufferable transactions for these masters.