In the AMBA4 ACE/ACE-Lite model of Arm IHI 0022H Part D, a full ACE caching requester can receive snoops and provide responses/data. ACE-Lite supports an I/O-coherent requester without the incoming cache-snoop interface of full ACE. The interconnect can still snoop participating CPU caches on its behalf. ACE-Lite is not simply AXI4-Lite: Lite refers to a different reduction in each name.
Start with a device that does not retain CPU cache lines. Its read needs the latest value from the coherent system, but there is no device cache copy to invalidate later. This is why the port choice follows the agent’s storage behaviour, not just its throughput.
ACE versus ACE-Lite: which side can be snooped? — worked trace
Illustrative isolated example; not measured silicon behaviour.
Milestone | Full ACE CPU cache | ACE-Lite device |
|---|---|---|
CPU has dirty X=7; memory has 0 | Can answer an incoming snoop with the required response/data | Has no local cache copy in this example |
Device requests a coherent read | Interconnect may snoop the CPU copy | Device initiates the access through its supported transaction type |
Data returns | CPU’s 7 is the newest source | Device receives 7 through its read-data path |
Later software shares a result | Still needs the software ordering contract | Hardware coherence does not publish an ownership flag by itself |
No. The interconnect handles snoops to the participating CPU caches. Full ACE is needed when the requester’s own caching behaviour requires the full snoop-participation contract, not merely because a peer held dirty data.
Read first: Cache states and permission transfers
Read first: Specialist course: explicit coherence model
Scope: AMBA4 ACE as described in Arm IHI 0022H, Part D. This is a transaction survey, not a complete ACE controller or an ACE5 feature catalogue. The isolated examples add two caching agents C0 and C1 and an interconnect IC; they do not silently add caches or a coherent DMA path to the core AXI teaching system.
ACE adds three snoop channels to AXI: AC (snoop address from interconnect to caches), CR (snoop response), and CD (snoop data). A coherent transaction can require snoop and/or memory actions according to its type, shareability domain and the interconnect's tracked state; this need not mean broadcasting every transaction to every cache.
AxDOMAIN identifies the transaction's shareability domain, while other attributes and transaction type complete the contract. A Non-shareable transaction is outside shared-cache coherence for that access; it is not inherently faster. A Shareable attribute alone does not prove that every required agent, region mapping and software ownership rule is configured correctly.
What to notice
CD terminates at the interconnect; the reader receives data on its own R interface.
CR reports a response obligation and cannot substitute for promised CD bytes.
The peer-to-IC CD path remains unresolved. The reader's R result cannot be replaced by the fact that a snoop response indication already arrived.
R on the requesting reader's ACE interface. CD is the peer-to-interconnect snoop-data path, not the reader's read-data channel.
ReadShared requests a readable copy and permits sharing; it does not promise a particular shared end state in every case. ReadUnique requests data with unique permission and removes conflicting copies. WriteUnique is a write propagated to memory or a downstream cache, not a request to allocate a Modified line in the writer. WriteBack returns dirty data downstream and deallocates the writing cache's line. See IHI 0022H D4, especially D4.8.2 and D4.8.4.
If a dirty peer supplies a requested line, the interconnect obtains that peer's data through CD and delivers the read result through the requester's R channel. Whether memory also updates and which cache keeps dirty responsibility depend on the selected transaction and responses. Do not transplant plain MESI state names into an ACE trace without defining their mapping.
ACE barrier transactions/fields have defined domain and completion semantics; map them to the selected architecture/software ordering contract rather than calling them a universal fence.
DVM (Distributed Virtual Memory), IHI 0022H D13, carries defined virtual-memory maintenance and synchronisation messages, including TLB and instruction-cache invalidation. It is not a generic data-cache flush operation; supported message capabilities must be established.
Incorrect shareability can change coherence participation or traffic; demonstrate the resulting outcome with the complete region and software contract.
Initially C0 has the only valid copy of line L, with X=7 and dirty responsibility; C1 has no copy, and backing memory still has X=0. There are no other writes, no reset and no errors. C1 requests ReadUnique. Assume the interconnect serialises this line and chooses a peer-data path; all accepted snoops, data and responses are eventually serviced. Rows are causal milestones, not bus cycles or a complete ACE signalling trace.
ReadUnique from C1 with a dirty C0 copy
Milestone | Observed path | Permission / data evidence |
|---|---|---|
Request accepted | C1 AR → IC | C1 has requested L; it cannot yet use a completed unique copy. |
Peer snooped | IC AC → C0 | C0 must resolve its existing copy and provide the required response. |
Response and data accepted | C0 CR and CD → IC | Response identifies the peer-data obligation; the data for X is 7. Track both obligations, without assuming CR/CD arrival order. |
Conflicts resolved | IC has collected the required evidence | C0's conflicting copy is removed; the response to C1 must not substitute memory's stale 0. |
Reader receives data | IC R → C1 | C1 receives X=7 with the response attributes required by this transaction. |
Read acknowledged | C1 RACK → IC | Complete the ACE read-acknowledgement obligation; do not release all tracking at AR acceptance. |
What to notice
A dirty copy makes memory an unsafe default data source until the coherence protocol has resolved it.
CR, CD and R are separate obligations. A response without its promised data cannot complete this read correctly.
No. Under the stated initial state and absence of later writes, 7 is the newest value. AR acceptance admits work; it does not authorise bypassing the dirty peer's response/data obligations. The requester must receive 7 and unique permission only after conflicts have been resolved.
AC requests a snoop; CR reports its result; CD carries data when required. The requesting reader receives its data on R.
An accepted address is not a completed coherent access, and memory need not hold the newest dirty value.
Transaction type, region attributes and the actual participating path form the coherence contract; shareability alone is insufficient.