5.3.2. AMBA-PV component protocols

The AMBA-PV component protocols are:

AMBAPV protocol

The AMBAPV protocol defines behaviors for single read and single write transactions. This covers AMBA AXI4, AXI3, AHB and APB bus protocol families, all at the PV level. In addition, the AMBAPV protocol provides support for AMBA protocol additional control information, including:

  • protection units

  • exclusive access and locked access mechanisms

  • system-level caches.

The behaviors of the protocol are:

read()

Completes a single read transaction at the given address for the given size in bytes. Additional AMBA protocol control information can be specified using the ctrl parameter. The socket_id parameter must be set to 0 in this context.

read(int socket_id, const sc_dt::uint64 & addr,
    unsigned char * data, unsigned int size,
    const amba_pv::amba_pv_control * ctrl,
    sc_core::sc_time & t):
    amba_pv::amba_pv_resp_t
write()

Completes a single write transaction at the given address with specified data and write strobes. The size of the data is specified in bytes. Additional AMBA protocol control information can be specified using the ctrl parameter. The socket_id parameter must be set to 0 in this context.

write(int socket_id, const sc_dt::uint64 & addr,
    unsigned char * data, unsigned int size,
    const amba_pv::amba_pv_control * ctrl,
    unsigned char * strb, sc_core::sc_time & t): 
    amba_pv::amba_pv_resp_t
debug_read()

Completes a debug read transaction from a given address without causing any side effects. Specify the number of bytes to read in the length parameter. The number of successfully read values is returned. Additional AMBA protocol control information can be specified in the ctrl parameter. The socket_id parameter must be set to 0 in this context. This behavior is empty by default and returns 0.

debug_read(int socket_id, const sc_dt::uint64 & addr,
    unsigned char * data, unsigned int length,
    const amba_pv::amba_pv_control * ctrl): 
    unsigned int
debug_write()

Completes a debug write transaction to a given address without causing any side effects. Specify the number of bytes to write in the length parameter. The number of successfully written values is returned. Additional AMBA protocol control information can be specified in the ctrl parameter. The socket_id parameter must be set to 0 in this context. This behavior is empty by default and returns 0.

debug_write(int socket_id, const sc_dt::uint64 & addr,
    unsigned char * data, unsigned int length,
    const amba_pv::amba_pv_control * ctrl): 
    unsigned int
b_transport()

This is an optional slave behavior for blocking transport. It completes a single transaction using the blocking transport interface. The amba_pv::amba_pv_extension 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. 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.

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

This is an optional slave behavior 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.

The amba_pv::amba_pv_extension must be added to the transaction before calling this behavior. The socket_id parameter must be set to 0 in this context.

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

This is an 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)

For more information about the SystemC/TLM amba_pv::amba_pv_control and amba_pv::amba_pv_status classes, see the AMBA-PV Extensions to OSCI TLM 2.0 Developer Guide.

The contents of the generic payload data is formatted as 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 should write the bytes of a word in increasing significance as the array index increases and a big endian master should 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.

AMBAPVACE protocol

The AMBAPVACE protocol defines behaviors for bus transactions. This covers AMBA ACE and DVM bus protocol families, all at the PV level. In addition, the AMBAPV protocol provides support for AMBA protocol additional extension information, including:

  • 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. 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.

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. 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.

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. 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_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. 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.

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

This optional master behavior is used 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)

For more information about the SystemC/TLM amba_pv::amba_pv_extension class, see the AMBA-PV Extensions to OSCI TLM 2.0 Developer Guide.

The contents of the generic payload data is formatted as 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 should write the bytes of a word in increasing significance as the array index increases and a big endian master should 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

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 ensure that memory coherency is maintained, the following rules must be applied 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 should be broadcast back upstream as debug snoop transactions to all ports other than the one the request came in on. Incoming debug snoops should propagate upwards. Debug reads can terminate as soon as they hit a cache. Debug writes must continue until they have propagated 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 should observe a weak memory-order model. Particular care, however, must be taken by any component that can cause a thread to be blocked whilst that component is responsible for the payload of an in-flight transaction. 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.

DMI should only be used when it can be guaranteed that subsequent transactions do not result in any state transitions. This means that in the general case DMI should not be used for ACE coherent cacheable transactions.

AMBAPVSignal protocol

The AMBAPVSignal protocol defines a single behavior to permit masters to change the state changes of signals such as interrupt. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const bool &state): void

Transfers a signal state. The export_id parameter must be set to 0 in this context.

AMBAPVSignalState protocol

The AMBAPVSignalState protocol defines two behaviors that permit a master to change the state of signals such as interrupt and to retrieve the state of such signals from slaves. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const bool &state): void

Transfers a signal state. The export_id parameter must be set to 0 in this context.

get_state(int export_id, tlm::tlm_tag<bool> * t): bool

Retrieves a signal state. The export_id parameter must be set to 0, and the t parameter must be set to NULL, in this context.

AMBAPVValue protocol

The AMBAPVValue protocol models propagation of 32 bit integer values between components. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const uint32_t & value): void

Transfers a value. The export_id parameter must be set to 0 in this context.

AMBAPVValue64 protocol

The AMBAPVValue64 protocol models propagation of 64 bit integer values between components. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const uint64_t & value): void

Transfers a value. The export_id parameter must be set to 0 in this context.

AMBAPVValueState protocol

The AMBAPVValueState protocol defines two behaviors that permit propagation of 32 bit integer values between components and to retrieve such values from slaves. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const uint32_t & value):void

Transfers a value. The export_id parameter must be set to 0 in this context.

get_state(unsigned int export_id, tlm::tlm_tag<uint32_t> * t): uint32_t

Retrieves a value. The export_id parameter must be set to 0, and the t parameter must be set to NULL, in this context.

AMBAPVValueState64 protocol

The AMBAPVValueState64 protocol defines two behaviors that permit propagation of 64 bit integer values between components and to retrieve such values from slaves. Strictly speaking this behavior is not covered by AMBA3, but is provided with the AMBA-PV Components.

set_state(int export_id, const uint64_t & value): void

Transfers a value. The export_id parameter must be set to 0 in this context.

get_state(int export_id, tlm::tlm_tag<uint64_t> * t): uint64_t

Retrieves a value. The export_id parameter must be set to 0, and the t parameter must be set to NULL, in this context.

Copyright © 2008-2013 ARM. All rights reserved.ARM DUI 0423O
Non-ConfidentialID060613