2.1.3 AMBAPVACE protocol

This protocol defines behaviors for bus transactions. This covers ARM® AMBA® ACE and DVM bus protocol families, all at the PV level.

In addition, this protocol provides support for AMBA protocol additional extension information:

  • Secure and privileged accesses.
  • Atomic operations.
  • System-level caching and buffering control.
  • Cache coherency transactions (ACE-Lite).
  • Bi-directional cache coherency transactions (ACE).
  • Distributed virtual memory transactions (DVM).

The behaviors of the protocol are:

b_transport()

This slave behavior implements the TLM blocking transport interface. An amba_pv::amba_pv_extension object must be added to the transaction before calling this behavior. The socket_id parameter must be set to 0 in this context.

b_transport(int socket_id,  amba_pv::amba_pv_transaction &trans, sc_core::sctime &t)
transport_dbg()

This optional slave behavior implements the TLM debug transport interface. You must add an amba_pv::amba_pv_extension object to the transaction before calling this behavior, setting the socket_id parameter to 0 in this context.

transport_dbg(int socket_id,  amba_pv::amba_pv_transaction &trans, sc_core::sctime &t):  unsigned int
get_direct_mem_ptr()

This optional slave behavior is for requesting a DMI access to a given address. It returns a reference to a DMI descriptor that contains the bounds of the granted DMI region. Returns true if a DMI region is granted, false otherwise. You must add an amba_pv::amba_pv_extension object to the transaction before calling this behavior, setting the socket_id parameter to 0 in this context.

get_direct_mem_ptr(int socket_id,  amba_pv::amba_pv_transaction &trans,  tlm::tlm_dmi &dmi_data):  bool
b_snoop()

This master behavior implements an upstream snooping TLM blocking transport interface. You must add an amba_pv::amba_pv_extension object to the transaction before calling this behavior, setting the socket_id parameter to 0 in this context.

b_snoop(int socket_id,  amba_pv::amba_pv_transaction &trans, sc_core::sctime &t)
snoop_dbg()

This optional master behavior implements an upstream snooping TLM debug transport interface. You must add an amba_pv::amba_pv_extension object to the transaction before calling this behavior, setting the socket_id parameter to 0 in this context.

snoop_dbg(int socket_id,  amba_pv::amba_pv_transaction &trans, sc_core::sctime &t):  unsigned int
invalidate_direct_mem_ptr()

Use this optional master behavior to invalidate a DMI request. It invalidates DMI pointers that were previously established for the given DMI region. The socket_id parameter is 0 in this context.

invalidate_direct_mem_ptr(int socket_id,  sc_dt::uint64 start_range, sc_dt::uint64 end_range)

The generic payload data is in the format of an array of bytes in order of ascending bus address. This means that irrespective of the host machine endianness or modeled bus width, a little endian master must write the bytes of a word in increasing significance as the array index increases and a big endian master must write the bytes of a word in decreasing significance as the array index increases. A master or slave whose endianness does not match the endianness of the host machine must endian swap any access to the payload data that is wider than one byte. The same byte ordering rule applies to memory accesses using DMI pointers.

Special considerations for ACE and cache coherent interconnects

To maintain memory coherency, apply these rules for debug transactions.

An ACE interconnect model must be able to cope with concurrent transactions in accordance with the hazard avoidance and prioritization rules in the ACE specification. Any external bus request, downstream transaction or upstream snoop transaction, can potentially cause a transaction to stall and the calling thread to be blocked, resulting in any number of other threads being scheduled.

To maintain memory coherency, apply these rules for debug transactions:

debug reads
The bus must return data that represents the values that the bus master expects to observe if it issues a bus read. This must not modify the state of any bus components.
debug writes
must modify the contents of all copies of the location being accessed, so that a subsequent read from this location returns the data in the debug-write request. The debug write must not modify any other state, for example such as cache tags, clean/dirty/shared/unique MOESI state.

The implications for a coherent interconnect are that incoming debug transactions must be broadcast back upstream as debug snoop transactions to all ports other than the one the request came in on. Incoming debug snoops must propagate upwards. Debug reads can terminate as soon as they hit a cache. Debug writes must continue until they propagate to all possible copies of the location, including downstream to main memory.

For cases where a debug transaction hazards with non-debug transactions that are in-flight, the debug transaction must observe a weak memory-order model. Any component that can block a thread whilst responsible for the payload of an in-flight transaction must take particular care. In these cases, the debug transaction must be hazarded against the in-flight payload to ensure that debug reads do not return stale data and debug writes do not cause cache incoherency.

Only use DMI when you can guarantee that subsequent transactions do not result in any state transitions. This means, in general, do not use DMI for ACE coherent cacheable transactions.

Non-ConfidentialPDF file icon PDF version100964_1142_00_en
Copyright © 2014–2018 Arm Limited or its affiliates. All rights reserved.