Module 1: Why ACE4 Exists

ACE4 Overview and Mental Model

Learning objectives

Explain the core mental model behind ACE4 Overview and Mental Model
Apply ACE4 Overview and Mental Model within Why ACE4 Exists
Identify important boundaries, trade-offs, and failure modes
Produce concrete evidence from the practice exercise

Related: ACE4 Cache States and Line Ownership | ACE4 Channels and Signals | ACE4 Transaction Types | ACE4 ACE Lite

What ACE4 Is

ACE4 is the AXI Coherency Extensions built on top of AXI4. AXI4 already gives you fast ordered or unordered reads and writes between masters, interconnect, and slaves. ACE4 adds the extra signaling and extra channels needed so that masters with caches can share memory while keeping those caches coherent.

In plain language: ACE4 lets multiple coherent agents behave as if they are looking at one consistent memory system, even though some of the freshest data might be sitting inside a cache rather than in main memory.

The Core Problem It Solves

Without coherency, one master can update a cache line while another master still holds an old copy. Software then has to manually clean and invalidate at the right times. That is slow, error-prone, and hard to scale.

ACE4 solves this by letting:

an initiating master tell the system what kind of coherent access it wants
the interconnect snoop other caches when needed
snooped caches return data or invalidate or downgrade their local copies
the interconnect return a final response that tells the initiator what ownership it received

The Main Actors

Actor	Role
Initiating master	Issues the original read, write, maintenance, barrier, or DVM transaction
Interconnect	Routes traffic, issues snoops, collects snoop responses, updates memory when required, and synthesizes the final response
Snooped master	Another coherent cache that might currently hold the cache line
Main memory	Backing store that might or might not contain the freshest copy at the instant a coherent transaction starts

The Mental Model

Think of each cache line as having two questions attached to it:

Who has a copy?
Who is responsible for the up-to-date value?

ACE4 spends most of its complexity answering those two questions correctly on every transaction.

The protocol therefore needs to know:

whether the access is shareable or not
whether the initiator wants a shared copy or a unique copy
whether another cache currently has dirty data
whether a snooped cache keeps a copy after the transaction

That is why responses such as IsShared and PassDirty matter so much.

What ACE4 Adds Beyond AXI4

At a high level, ACE4 adds:

address-channel qualifiers such as ARSNOOP, AWSNOOP, ARDOMAIN, AWDOMAIN, and barrier signaling
three snoop channels: AC, CR, and CD
transaction-completion acknowledges: RACK and WACK
extra read-response meaning on RRESP[3:2]
the notion of cache line states and ownership transfer

AXI4 tells you "a read happened." ACE4 tells you "a coherent read happened, peers were snooped, dirty data might have moved from cache to cache, and the initiator ended up shared or unique."

Transaction Categories

Category	Purpose
Non-snoop transactions	Access non-shareable or device memory without coherency actions
Coherent read transactions	Obtain data from a shareable location while respecting other cached copies
Coherent write transactions	Gain the required ownership and update data safely
Cache maintenance transactions	Clean or invalidate caches so software-visible effects become correct
Barrier transactions	Order visibility and observation of earlier traffic
DVM transactions	Maintain distributed virtual-memory structures such as TLBs and instruction caches

See ACE4 Transaction Types for the full breakdown.

A Simple Example

Suppose Core A holds a line in UniqueDirty, and Core B issues ReadShared.

Typical system behavior:

Core B issues a coherent read.
The interconnect snoops Core A.
Core A provides the up-to-date data.
Because Core B only wants a shared copy, Core A does not keep unique ownership.
The final system state becomes shared rather than unique.

This is the key ACE idea: the freshest data does not need to come from DRAM if a coherent cache already has it.

Practical Heuristics

If the memory is not shareable, you are usually not in the interesting ACE path.
If the initiator wants to write only part of a cache line, ownership matters before bytes matter.
If a snooped cache is dirty, the system must decide whether to pass that dirty responsibility or write the line back.
If software needs ordering guarantees across agents, barriers matter even when no payload data is returned.

Common Beginner Traps

Trap	Better way to think
"ACE is just AXI plus snoops"	ACE is AXI plus ownership, state movement, and system-visible ordering rules
"Memory always has the latest copy"	In a coherent system, the freshest copy can live in a cache
"Shared means harmless"	Shared still matters because dirty vs clean and who retains a copy changes later behavior
"Barriers are just software concepts"	ACE barriers are real protocol transactions with explicit rules

Summary

ACE4 is a system protocol for maintaining a coherent view of shareable memory across cached masters. The easiest way to understand it is to track cache-line ownership, dirtiness, and whether other copies exist. Once that mental model is solid, the channel rules and transaction names stop feeling arbitrary.

Practice lab

Draw or encode one legal transaction trace for ACE4 Overview and Mental Model. Annotate fields, channel events, ordering points, and completion conditions; then construct one illegal or adversarial trace and define the checker that should catch it.

Review questions

What problem does ACE4 Overview and Mental Model solve, and what assumptions does it rely on?
Which boundary or failure case is easiest to miss, and how would you expose it?
What alternative design would you consider, and what trade-off would change the decision?
What artifact, trace, test, or metric proves that your implementation is correct?

Completion evidence

A working artifact, annotated trace, or reproducible experiment
At least one normal case and one deliberately failing or boundary case
A concise explanation of the design choice and its trade-offs
Saved output showing how correctness was evaluated