2.4.2 AMBA support

Certain behavior applies to how the MMU-600 implements its ACE-Lite interfaces.

TBU support for ACE-Lite transactions

The MMU-600 TBU supports many ACE-Lite transaction types, and handles these transactions in certain ways. Typically, when propagating downstream transactions on the TBU TBM interface, the MMU-600 uses the same transaction type that the upstream master presents to the TBU TBS interface.

If the shareability domain of a downstream WriteLineUnique transaction is not Inner Shareable or Outer Shareable, the MMU-600 outputs the transaction as WriteNoSnoop. That is, AWSNOOP = 0b0000. The AWDOMAIN signal indicates the shareability domain of write transactions.

Transactions that can result in a translation fault

In an MMU-600 system, some transactions can result in a translation fault, and certain behavior is associated with such transactions.

The MMU-600 treats the following transactions as ordinary reads when calculating translation faults:

  • CleanShared.
  • CleanInvalid.
  • MakeInvalid.
  • CleanSharedPersist.
  • ReadOnceMakeInvalid.
  • ReadOnceCleanInvalid.

Therefore, these transactions might require either read permission or execute permission at the appropriate privilege level.

The MMU-600 treats the following transactions as ordinary writes when calculating translation faults:

  • WriteUniquePtlStash.
  • WriteUniqueFullStash.

Therefore, these transactions require write permission at the appropriate privilege level.

CleanShared, CleanInvalid, MakeInvalid, and CleanSharedPersist transactions do not have a memory type. The input transaction and output transaction memory type and allocation hints are ignored and replaced by Normal, Inner Write-Back, Outer Write-Back, Read Allocate, Write Allocate. This behavior means that the ARDOMAIN output on the TBM interface is never System Shareable for these transactions, because they are never Non-cacheable or Device.

The MMU-600 treats transactions that pass the translation fault check as follows:

MakeInvalid transactions
The MMU-600 converts MakeInvalid transactions to CleanInvalid transactions, unless the translation also grants write permission and Destructive Read Enable (DRE) permission.
ReadOnceMakeInvalid and ReadOnceCleanInvalid transactions
The MMU-600 outputs ReadOnceMakeInvalid transactions as ReadOnceCleanInvalid transactions, unless the translation also granted write permission and DRE permission.
If the final transaction attributes on the TBU TBM interface are not Inner Shareable Write-Back or Outer Shareable Write-Back, the MMU-600 converts ReadOnceMakeInvalid and ReadOnceCleanInvalid transactions into ordinary reads.
WriteUniquePtlStash and WriteUniqueFullStash transactions
If they pass the translation fault check, the MMU-600 converts WriteUniquePtlStash and WriteUniqueFullStash transactions to ordinary write transactions if either:
  • The translation did not grant Directed Cache Prefetch (DCP) permission.
  • The final transaction attributes on the TBU TBM interface are not Inner Shareable or Outer Shareable Write-Back.
If such a conversion occurs, AWSTASH* is driven as 0.

Transactions that cannot result in a translation fault

In an MMU-600 system, certain transactions cannot result in a translation fault, and certain behavior is associated with such transactions.

The following transactions never result in a translation fault:

  • StashOnceShared.
  • StashOnceUnique.
  • StashTranslation.

If any of these transactions require a translation request to the TCU, the MMU-600 issues a speculative translation request on the DTI interconnect. StashOnceShared and StashOnceUnique transactions are terminated in the TBU, with a BRESP value of OKAY, when any of the following cases apply:

  • The translation did not grant Directed Cache Prefetch (DCP) permission.
  • The final transaction attributes on the TBM interface are not Inner Shareable or Outer Shareable Write-Back.
  • The translation did not grant any of read, write, or execute permission at the appropriate privilege level.

    Note:

    Only one of these permissions is required for the stash transaction to be permitted.

Note:

A BRESP value of OKAY indicates transaction success. The MMU-600 always generates this value when a StashOnceShared or a StashOnceUnique transaction is terminated in the TBU. This behavior applies even when a StreamDisable or GlobalDisable translation response causes the transaction to be terminated.

The MMU-600 never propagates StashTranslation transactions downstream, and uses StashTranslation only to prefetch TLB contents. The MMU-600 always terminates StashTranslation transactions with a BRESP value of OKAY, even if no translation could be stored in the TLB.

The TBU ignores AWPROT[0] and AWPROT[2] for StashTranslation transactions, because they do not affect speculative translation requests.

AXI5 support

The AXI5 protocol includes extensions that are not included in previous AXI versions. The Arm® AMBA® AXI and ACE Protocol Specification, AXI3, AXI4, AXI5, ACE and ACE5 defines these extensions.

The following table shows whether individual TCU and TBU interfaces support the AXI5 extensions.

Table 2-19 TCU and TBU interface support for AXI5 extensions

AXI5 extension

QTW/DVM

TBU TBS

TBU TBM

DVM_v8.1

Yes

-

-

Wakeup_Signals

Yes

Yes

Yes

Atomic_Transactions

-

-

-

Coherency_Connection_Signals Yes - -

Cache_Stash_Transactions

-

Yes

Yes

DeAllocation_Transactions

-

Yes

Yes

Untranslated_Transactions

-

Yes

Yes

Poison

-

-

-

Check_Type

-

-

-

QoS_Accept

-

-

-

Trace_Signals

-

-

-

Loopback_Signals

-

-

-

NSAccess_Identifiers

-

-

-

Persist_CMO

-

Yes

Yes

Upstream ACE master restrictions

The ACE5 protocol places requirements on upstream ACE masters that support the Untranslated_Transactions extension.

For the ACE TBU configuration to be used with an upstream master that implements ACE5, the following requirements apply:

  • Snoop transactions return an invalid cache state response unless they correspond to a Shareable cache line that has previously been modified with a successful ReadClean, ReadNotSharedDirty, ReadShared, ReadUnique, CleanUnique, or MakeUnique transaction. In particular:
    • Data that a ReadNoSnoop or ReadOnce transaction returns is either not cached, or cached in such a way that snoops of that cache line return an invalid cache state response.
    • If cache lines are allocated silently due to non-shared writes, then snoops to those lines also return an invalid cache state response.
  • Shareable Write-Back, WriteClean, WriteEvict and Evict transactions always correspond to a Shareable cache line that has previously been modified with a successful ReadClean, ReadNotSharedDirty, ReadShared, ReadUnique, CleanUnique, or MakeUnique transaction. In particular, data that a ReadNoSnoop or ReadOnce transaction returns is either not cached, or written back with a WriteNoSnoop, WriteUnique, or WriteLineUnique transaction.

In addition, cache maintenance operations are not supported for upstream ACE masters.

Avoiding deadlock when using fully coherent ACE masters

You can take certain steps to prevent deadlock in systems where an ACE TBU configuration is used with a fully coherent ACE master.

The ACE protocol requires that certain write transactions, including WriteNoSnoop, must progress to any address without requiring any pending snoop transactions to progress. If a TBU is used with a fully coherent ACE master, WriteNoSnoop transactions might require the TCU to issue translation table walks. If these table walks depend on snoop transactions, then this ACE protocol requirement is not met. You can ensure that this requirement is met by ensuring that TCU transactions do not pass through a coherent interconnect.

Alternatively, you might be able to use a coherent interconnect such as the Arm CoreLink™ CCI-500 or CCI-550. Both of these interconnects ensure that interfaces that never issue snoop transactions are never blocked by snoop transactions. You can use CCI-500 or CCI-550 provided:

  • All the TCU transactions are configured to use Device or Non-cacheable memory types, so that the TCU transactions never result in snoop transactions being performed.
  • The TCU does not share an interconnect interface with any masters that can cause snoop transactions, so that the TCU transactions cannot be blocked by snoop transactions.
Non-ConfidentialPDF file icon PDF version100310_0100_00_en
Copyright © 2016–2018 Arm Limited or its affiliates. All rights reserved.