Transaction response

Every AXI transaction reports a result. Write transactions report on the B channel, and read transactions report on the R channel. Atomic transactions can have both write and read responses because they use both response paths.

Write response

Write responses are carried on the B channel using BRESP. A normal write transaction has one Completion response, which reports the result of the transaction after the write request and required write data have been accepted. Some optional features can add a second write response, so BCOMP is used when the interface must identify which response is the Completion response.

Signal	Width	Default	Purpose
`BRESP`	`BRESP_WIDTH`	`OKAY`	Reports the result of a transaction that uses the write channels.
`BCOMP`	1	HIGH	Marks the Completion response when an interface can return more than one write response.

Property	Values	Default	Notes
`BRESP_WIDTH`	0, 2, 3	2	`0` means `BRESP` is absent and treated as `OKAY`. A 3-bit response is required for `Untranslated_Transactions` v2/v3 or `WriteDeferrable_Transaction = True`.

BCOMP appears only when a feature can produce two write responses, such as persistence-related cache maintenance behavior or Memory Tagging Extension behavior. If BCOMP is present, one response transfer for every write-channel transaction must assert it.

`BRESP`	Label	Meaning
`0b000`	`OKAY`	Non-exclusive write succeeded. For an exclusive write, `OKAY` means the exclusive update failed.
`0b001`	`EXOKAY`	Exclusive write succeeded. Only legal for an exclusive write.
`0b010`	`SLVERR`	Request reached an endpoint, but the endpoint could not complete it successfully. The location might not be fully updated.
`0b011`	`DECERR`	Request did not reach a valid writable endpoint, commonly because the address decoded to an invalid target.
`0b100`	`DEFER`	WriteDeferrable transaction could not be serviced now. The location is not updated.
`0b101`	`TRANSFAULT`	Translation fault for a request using PRI flow.
`0b110`	Reserved	Do not use.
`0b111`	`UNSUPPORTED`	WriteDeferrable transaction type is not supported by the target. The location is not updated.

For a beginner, the main rule is: BRESP is one response for the write transaction, not one response per write data beat. If a burst has four W transfers, the transaction still normally completes with one B response.

Read response

Read responses are carried on RRESP with every read data transfer. This is different from writes: there is no separate read-response-only channel. Each accepted R beat carries both data and response status.

Signal	Width	Default	Purpose
`RRESP`	`RRESP_WIDTH`	`OKAY`	Reports the result of the read transfer. It must be valid whenever `RVALID` is asserted.

Property	Values	Default	Notes
`RRESP_WIDTH`	0, 2, 3	2	`0` means `RRESP` is absent and treated as `OKAY`. A 3-bit response is required for Prefetch, Untranslated v2/v3, or Shareable cache response support.

`RRESP`	Label	Data validity and meaning
`0b000`	`OKAY`	Non-exclusive read completed and read data is valid. For an exclusive read, this means the Subordinate does not support exclusive accesses.
`0b001`	`EXOKAY`	Exclusive read succeeded. Only legal for an exclusive read.
`0b010`	`SLVERR`	Contained error for this location, such as unsupported size, FIFO overrun, or powered-down function. Read data is not valid.
`0b011`	`DECERR`	Non-contained decode error, commonly an invalid address. Read data is not valid.
`0b100`	`PREFETCHED`	Read data is valid and came from a prefetched source.
`0b101`	`TRANSFAULT`	Translation fault for a request using PRI flow. Read data is not valid.
`0b110`	`OKAYDIRTY`	Read data is valid and Dirty with respect to memory. Only legal for a `ReadShared` response.
`0b111`	Reserved	Do not use.

The RRESP value can differ from beat to beat in the same read transaction. Even if one beat reports an error, the Subordinate must still return all read data transfers indicated by Length. For response values where read data is not valid, the Manager might still sample RDATA, so a Subordinate must not rely on the response code to hide sensitive data.

DECERR has an extra consistency property because Managers might inspect only one beat to detect a decode error.

`Consistent_DECERR`	Default	Meaning
`True`	No	`DECERR` is returned for every read data transfer, or for no read data transfers, in each cache line of data.
`False`	Yes	`DECERR` can appear on any number of read data transfers.

Manager `Consistent_DECERR`	Subordinate `False`	Subordinate `True`
`False`	Compatible	Compatible
`True`	Not compatible; a `DECERR` beat could be missed	Compatible

Subordinate Busy indicator

The optional Busy indicator lets a Subordinate report its current activity level while returning a transaction response. It is not a replacement for READY, and it does not cancel the response. It is feedback to help the Manager tune future behavior, such as issuing fewer speculative requests when a shared resource is becoming full.

Busy is useful when a Subordinate contains a shared resource, such as a memory controller, last-level cache, request queue, or internal scheduling structure. The value can represent queue depth, read-side pressure, write-side pressure, or whether a component is using more or less than its allocated share. The exact meaning is implementation-defined, but the encoding always follows the idea that larger values mean busier.

Property	Default	Meaning
`Busy_Support = True`	No	The interface includes Busy indicator signals.
`Busy_Support = False`	Yes	Busy is not supported.

Signal	Width	Default	Used with	Meaning
`BBUSY`	2	`0b00`	`B` channel response	Current Subordinate activity level for a write response.
`RBUSY`	2	`0b00`	`R` channel response	Current Subordinate activity level for a read response.

For a multi-beat read, RBUSY must be valid on every read data transfer and can change from beat to beat. For a write transaction with multiple write responses, BBUSY is meaningful on the response where BCOMP is asserted. For other write responses, Busy is not applicable. For Atomic transactions that produce both write and read responses, BBUSY and RBUSY are expected, but not required, to carry the same value.

One typical interpretation is:

Busy value	Meaning	Possible Manager behavior
`0b00`	Not busy	Manager can increase speculative requests.
`0b01`	Optimally busy	Manager can keep the current issue rate.
`0b10`	Quite busy	Manager can reduce speculative requests.
`0b11`	Very busy	Manager can heavily reduce speculative requests.

Busy support is interoperable even when only one side implements it, because the signal can be left unused or tied to the default value.

Manager `Busy_Support`	Subordinate `False`	Subordinate `True`
`False`	Compatible	Compatible; Busy outputs are left unconnected.
`True`	Compatible; Busy inputs are tied to the default value.	Compatible

AXI Protocol