Module 1: Signal Encoding and Completion Rules
ACE4 Channels and Signals
Learning objectives
- Explain the core mental model behind ACE4 Channels and Signals
- Apply ACE4 Channels and Signals within Signal Encoding and Completion Rules
- Identify important boundaries, trade-offs, and failure modes
- Produce concrete evidence from the practice exercise
Related: ACE4 Overview and Mental Model | ACE4 Snoop Transactions and Responses | ACE4 Barrier Transactions | Interfaces
Big Picture
ACE4 keeps the five familiar AXI4 channels and extends them with coherency metadata. It also adds three snoop channels and two completion acknowledges so the system can manage peer-cache interactions explicitly.
Existing AXI4 Channels with ACE Meaning
| Channel | ACE additions |
|---|---|
AR read address | ARSNOOP, ARDOMAIN, barrier meaning on ARBAR, DVM usage |
AW write address | AWSNOOP, AWDOMAIN, barrier meaning on AWBAR |
R read data | Additional response meaning in RRESP[3:2], plus completion via RACK |
B write response | Standard response, plus completion via WACK |
W write data | Used by coherent write transactions just as in AXI4, but with extra transaction-specific constraints |
Additional ACE Channels
| Channel | Direction | Purpose |
|---|---|---|
AC snoop address | Interconnect -> master | Tells a coherent cache to perform a snoop for a given address and snoop type |
CR snoop response | Master -> interconnect | Returns snoop outcome bits such as DataTransfer, PassDirty, IsShared, WasUnique |
CD snoop data | Master -> interconnect | Returns cache-line data when the snooped cache provides it |
Key Read and Write Address Signals
| Signal | Meaning |
|---|---|
ARSNOOP[3:0] | Read transaction type for shareable reads, such as ReadShared or ReadUnique |
AWSNOOP[2:0] | Write transaction type for shareable writes, such as WriteUnique or WriteBack |
ARDOMAIN[1:0] | Shareability domain of the read transaction |
AWDOMAIN[1:0] | Shareability domain of the write transaction |
ARBAR / AWBAR | Indicates barrier behavior and whether the transaction respects barrier ordering |
The domain tells ACE where the coherency conversation is supposed to happen. The snoop fields tell ACE what kind of coherency conversation it is.
Common Transaction Encodings You Should Remember
Read-side transaction names
| Transaction | Notes |
|---|---|
ReadOnce | Obtain a snapshot without necessarily caching it |
ReadShared | Cached load that can accept shared ownership |
ReadClean | Read that only accepts clean data responsibility |
ReadNotSharedDirty | Read that cannot accept a shared dirty result |
ReadUnique | Read to prepare for a later partial write with unique ownership |
CleanUnique | Clean out peer copies when the initiator already has the line |
CleanShared / CleanInvalid / MakeInvalid | Cache maintenance operations |
DVM Message / DVM Complete | Distributed virtual memory operations |
Write-side transaction names
| Transaction | Notes |
|---|---|
WriteUnique | Coherent write that can be partial-line |
WriteLineUnique | Coherent write of a full line with stricter requirements |
WriteBack | Write dirty data back to memory and give up dirty responsibility |
WriteClean | Update memory while retaining a clean copy |
Evict | Indicate a line has been evicted with no data transfer |
See ACE4 Read and Write Transactions for the decision logic.
Extra Completion Signals
| Signal | Sent by | Meaning |
|---|---|---|
RACK | Master | The read transaction is complete from the master's point of view |
WACK | Master | The write transaction is complete from the master's point of view |
These are important because ACE completion is not just "last data beat arrived." The interconnect needs an explicit indication that the master has completed the transaction.
Practical rules:
RACKis used for all read-side transactions, including coherent reads, barriers, and DVM.WACKis used for all write-side transactions, including write barriers.- The interconnect must be able to accept them without stalling.
Extra Response Meaning on the Read Path
ACE extends RRESP with two coherency outcome bits:
| Bit | Meaning |
|---|---|
RRESP[2] | PassDirty |
RRESP[3] | IsShared |
This means the read response is not only telling you success or failure. It is also telling you what kind of line ownership the initiator ended up with.
Snoop Response Bits
| CRRESP bit | Meaning |
|---|---|
CRRESP[0] | DataTransfer - this snoop response includes data on the CD channel |
CRRESP[1] | Error |
CRRESP[2] | PassDirty |
CRRESP[3] | IsShared |
CRRESP[4] | WasUnique |
Important legality rule:
PassDirty=1withDataTransfer=0is illegal.
Practical Handshake View
| Channel | Handshake rule to remember |
|---|---|
AC | Snoop address and control must remain stable while valid is asserted and ready is low |
CR | Snoop response must remain stable until accepted |
CD | Snoop data is transferred only when a snooped cache is providing data |
RACK / WACK | Acknowledge must not be delayed waiting on unrelated transactions |
Verification Checklist
- Check that
ARSNOOP,AWSNOOP, and domain fields are legal for the transaction class. - Check that
RACKandWACKhappen for all applicable ACE transactions. - Check that barrier and DVM transactions force the correct response-bit behavior.
- Check that
CRRESPcombinations are legal for the snoop type. - Check that
CDtransfers only occur whenDataTransferindicates they should.
Summary
ACE4 signaling extends AXI4 in two directions: initiator intent on the address channels, and peer-cache interaction on the snoop channels. If you can read ARSNOOP/AWSNOOP, interpret CRRESP, and understand the role of RACK/WACK, you can already follow most ACE traces.
Practice lab
Draw or encode one legal transaction trace for ACE4 Channels and Signals. Annotate fields, channel events, ordering points, and completion conditions; then construct one illegal or adversarial trace and define the checker that should catch it. Add an operational constraint such as concurrency, recovery, security, latency, or cost, and defend the resulting design trade-off.
Review questions
- What problem does ACE4 Channels and Signals 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