Read first: Read the mechanism and worked trace first
An accelerator reads CPU-produced buffers but retains no coherent cache lines. A later redesign adds a reusable coherent local cache. The port review must change when that storage contract changes, even if bandwidth stays constant.
Choose the port from the agent’s storage contract — decision record
Apply the stated local assumptions; record actual platform values before using this as an implementation checklist.
Decision / observation | Required evidence | Consequence |
|---|---|---|
No retained coherent lines | Supported I/O-coherent access and participating CPU region | An ACE-Lite-style requester can be appropriate |
Coherent cache added | Incoming snoop, response and data obligations | The old no-cache port assumption must be revisited |
Software publishes a buffer | Ownership and platform synchronisation sequence | Coherent data access alone is insufficient |
No. A retained coherent copy creates snoop-participation and permission obligations that the old no-cache requester did not have. Revisit the interface and software contract.
Define which CPU clusters, accelerators and device paths participate in hardware coherence for each region. A non-coherent path needs an explicit software ownership and cache-maintenance contract; it is not inherently faster. Coherence concerns values at each location, while the memory consistency model constrains ordering across locations.
DMA buffers that cross coherent and non-coherent views need an explicit platform ownership/mapping contract. Use the platform DMA interfaces for allocation, mapping and synchronisation so any required maintenance and barriers match direction and lifecycle.
Map every memory region to a shareability domain in the address map.
Distinguish device registers from DMA data buffers; use the platform's specified memory type and shareability for each.
Use the platform DMA and synchronisation interfaces; hardware coherence does not replace software ordering or ownership rules.