Stratix® 10 Hard Processor System Technical Reference Manual

ID 683222
Date 8/15/2024
Public
Document Table of Contents

4.6. Cache Coherency Unit Transactions

The coherency interconnect in the CCU accepts both coherent and non-coherent transactions. These transactions are routed to the IOCB .

The CCU handles transactions from the FPGA-to-HPS interface, TCU, and peripheral masters in the L3 interconnect as follows:

  • Coherent read: The IOCB sends the read to the coherency directory in the CCC to perform a lookup and issue a snoop to the Cortex* -A53 MPCore processor if required.
    • If the access is a cache hit, data is routed from the cache.
    • If the access is a cache miss, data is routed from the appropriate slave agent after cache operations have completed.
  • Coherent write: The IOCB sends the write to the coherency directory in the CCC to perform a lookup and issue a snoop.
    • If the access is a cache hit, the cache is updated with the new data and the coherency directory continues to track the cache line.
    • If the access is a cache miss, then the new data is written to the appropriate slave agent.
Note: You must configure the FPGA and I/O master TBUs to prevent coherent master transactions from accessing the Lightweight HPS-to-FPGA mailbox address range. Please refer to the System Memory Management Unit chapter for more details.
  • Non-coherent transactions are handled differently depending on the master agent issuing the transaction.
    • If the FPGA or TCU send a non-coherent access to the CCU, the IOCB routes the access directly to the slave agent.
    • If an HPS peripheral master issues a non-cacheable memory access to on-chip RAM or SDRAM, then the L3 interconnect routes the access to the IOCB of the CCU. In turn, the CCU routes the access directly to the corresponding memory.
    • If an HPS peripheral master issues a non-cacheable memory access to a peripheral slave agent, then the L3 interconnect routes the access directly to the slave, bypassing the CCU.
Some key points to remember about CCU transactions:
  • A master agent issues a read or write address to access a slave. This address is compared against the address ranges programmed in the Address Mask Register (*am_admask*) and Base Address Register (*am_adbase*) to identify the targeted slave device. A slave device can have multiple address ranges assigned to it, each from a different master. Address ranges can be non-continuous.
  • You can program address ranges to be disabled, read-only, or write-only. During address decode, the CCU compares the transaction ARPROT or AWPROT with the access privilege programmed for an address range. A failed access check results in a decode error response for the transaction.
  • Each address range can also be associated with hash functions that are used in the route lookup process.
  • Master agents have no predefined priority. A master's L3 interconnect QoS level determines the associated coherency interconnect QoS priority for the L3 masters and slaves, as well as the SDRAM memory interface. The Cortex*-A53 MPCore and FPGA-to-HPS interface priorities are configured in the System Manager and FPGA, respectively. You can configure the coherency interconnect QoS weights through the QoS Profile Data Register (p_0) registers.
  • Fixed transactions are split into multiple single beat increments (INCRs).
  • The CCU only accepts 16-, 32- or 64-byte WRAP transactions. All other cache line sizes generate a fatal error interrupt.
  • Master and slave ports queue outstanding requests. The table below shows the maximum number of outstanding requests each agent supports.
    Table 46.  Maximum Outstanding Request Support
    Agent Outstanding Reads Outstanding Writes
    Cortex* -A53 MPCore processor 33 21
    FPGA-to-HPS Interface 8 8
    TCU 16 1
    Peripheral masters 16 16
    External SDRAM Memory 32 32
    On-chip RAM 2 2
    GIC 1 1
    Peripheral slaves 16 16
    SDRAM register group 2 2
Certain errors or stalls can occur when unsupported accesses occur:
  • An unknown address or access privilege violation on the AR or AW channels causes a decode error. This error stalls the command channels until the decode error (DECERR) response can be issued on the R or B channel, respectively.
  • Changing the QoS level while commands are outstanding can momentarily stall a channel if the change reorders the command to a slave over the network.