Module 1: Why ACE4 Exists
ACE4 Cache States and Line Ownership
Learning objectives
- Explain the core mental model behind ACE4 Cache States and Line Ownership
- Apply ACE4 Cache States and Line Ownership within Why ACE4 Exists
- Identify important boundaries, trade-offs, and failure modes
- Produce concrete evidence from the practice exercise
Related: ACE4 Overview and Mental Model | ACE4 Read and Write Transactions | ACE4 Snoop Transactions and Responses
Why the State Model Matters
Almost every ACE4 rule becomes easier if you stop memorizing transaction tables and instead reason from cache-line state. The state tells you:
- whether the cache has a valid copy
- whether the line is unique or shared
- whether the cache or memory is responsible for the freshest value
The Five Practical States
| State | Meaning |
|---|---|
I - Invalid | The cache does not hold a usable copy of the line |
UC - UniqueClean | Only this cache holds the line, and memory is already up to date |
UD - UniqueDirty | Only this cache holds the line, and this cache has the freshest data |
SC - SharedClean | More than one cache can hold the line, and memory is up to date |
SD - SharedDirty | More than one cache can hold the line, but one cache still carries dirty responsibility |
Intuition for Each State
Invalid
You have nothing locally. Any future access must fetch or reconstruct the line through memory or a coherent peer.
UniqueClean
You are the only cache with the line, but memory already matches you. This is a good state for future writes because no peer invalidation is needed first.
UniqueDirty
You alone have the line and memory is stale. If someone else needs the line, the system must either pass your dirty data onward or write it back.
SharedClean
Multiple caches can read the line safely because memory is also current.
SharedDirty
Multiple caches have the line, but memory is stale and one cache effectively carries ownership of the latest data. This is why dirtiness and sharing are separate concerns.
Ownership Questions to Ask
For any transaction, ask:
- Does the initiator end up with a copy?
- Is that copy shared or unique?
- If data was dirty before the transaction, who owns responsibility afterward?
- Is memory current at the end?
If you answer those four questions, most ACE outcomes become predictable.
How Response Bits Map to State
| Signal | Practical meaning |
|---|---|
IsShared | After the transaction, the line should be treated as shared rather than unique |
PassDirty | Dirty responsibility moved with the data instead of being pushed back to memory first |
WasUnique | A snooped cache previously held the line uniquely before responding |
Typical initiator-side interpretation:
IsShared=0,PassDirty=0often means unique clean ownershipIsShared=0,PassDirty=1often means unique dirty ownershipIsShared=1,PassDirty=0often means shared cleanIsShared=1,PassDirty=1often means shared dirty
The exact legal combinations depend on the transaction. See ACE4 Snoop Transactions and Responses.
State Transitions You Should Know Cold
| Situation | Typical result |
|---|---|
ReadShared from I | Initiator usually gets a shared or unique clean copy depending on whether peers also hold it |
| ReadUnique against peer copies | Other caches lose ownership so the initiator can write safely |
| CleanUnique when initiator already has the line | Peers are cleaned out so the initiator can become unique |
WriteBack from UD | Memory is updated and the cache typically gives up or downgrades ownership |
| CleanInvalid | Any surviving copy in the target caches must be invalid |
| MakeInvalid | Copies are invalidated without the operation being a data-returning read |
Practical Debugging View
When debugging ACE traffic, the single most useful question is:
"At this point, who believes they own the authoritative value of this line?"
If two places think they do, coherency is broken.
If nobody does, the interconnect probably dropped a required state transition or failed to account for dirty responsibility correctly.
Common Mistakes
| Mistake | Why it is wrong |
|---|---|
| Treating "dirty" as equivalent to "unique" | A line can be SharedDirty |
| Assuming shared lines are always clean | Shared does not imply memory is current |
| Ignoring memory state after a snoop | Whether memory is current changes which later transactions are legal or cheap |
| Focusing only on initiator state | ACE correctness depends on peer and interconnect state too |
Summary
ACE4 state is really about copy count and freshness responsibility. Unique versus Shared answers who else might have the line. Clean versus Dirty answers whether memory is already correct. Keep those axes separate and the protocol becomes much easier to reason about.
Practice lab
Draw or encode one legal transaction trace for ACE4 Cache States and Line Ownership. 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 Cache States and Line Ownership 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