A driver reads a register in a peripheral that has just been powered down. The read never returns. The processor's load instruction waits, the core waits behind it, and the whole system stops with no error message anywhere. The bug was not in the peripheral. It was in a protocol rule the system had not enforced: every request gets exactly one response.
What must a request carry, what must a response carry, and why is "exactly one response" the rule that keeps a system alive?
The obvious model is that a request asks for data and the response is the data. That covers the case where everything works. It says nothing about the other cases: the address is wrong, the target is powered down, the data is corrupted, the target is busy. If the only possible response is "here is your data", a target that cannot supply data has two bad choices: send something that looks like data but is not, or send nothing, and leave the requester waiting for ever.
Carries | Why | |
|---|---|---|
Request | Operation (read, write, …), address, size or length, an ID or tag, attributes; for a write, the data | Everything the target needs to act, and everything the requester needs to match the answer later |
Response | The ID, a status, and for a read, the data | The requester must know which request this answers and whether it succeeded |
The status turns failure into an ordinary answer. A target that cannot do the job still answers, with an error status instead of data, and the requester (or its software) decides what to do. Together, a request and its response are often called a transaction; the response is often called a completion.
Two rules make this safe:
Exactly one response per request (for every request that expects one). Zero responses hangs the requester; two responses confuse it, or are matched to the wrong request.
The response identifies its request. With one request outstanding that is implicit. With many, the response carries the request's ID or tag (lesson 6.4).
Protocols differ in detail, but the useful statuses fall into a few kinds:
Kind | Meaning | Who usually sends it |
|---|---|---|
Success | Done as asked | The target |
Target error | The address is real, but the target could not do it (busy, powered down, illegal access) | The target |
Decode error | Nothing lives at this address | The interconnect's default target (lesson 5.3) |
Special success | Done, with extra meaning (for example, an exclusive access succeeded) | The target (lesson 5.13) |
Protocol | Response status |
|---|---|
AXI | OKAY, EXOKAY (exclusive access succeeded), SLVERR (target error), DECERR (decode error, usually from the interconnect when no target matches). |
APB | PSLVERR (from APB3) marks a transfer that failed. |
PCI Express | Non-posted requests get a completion with a status; posted writes get none (lesson 5.7). |
No response: the opening hang. A target that ignores requests in some state (powered down, in reset, clock-gated) leaves its requester waiting for ever. The fixes are a default responder, a power-aware wrapper that answers on the target's behalf, and a timeout in the requester as a last line of defence.
Two responses: a target that sends an error and then, later, the data (illustrative) makes the requester complete the transaction twice. With IDs, the second response may be matched to a newer request that reused the ID, delivering wrong data silently.
A silent error: a target that returns zeros instead of an error status hides the failure. Software reads a plausible value and carries on.
Because the requester is waiting for exactly one response. Without it, the requester (and whatever waits behind it) hangs for ever; with an error status it can carry on and report the failure.
The requester completes the transaction twice, or matches the extra response to a later request that reused the same ID, delivering wrong data with no error.
A request carries what the target needs and an ID; a response carries the ID, a status and, for reads, the data.
A status makes failure an ordinary answer instead of a hang or a silent wrong value.
Every request that expects a response gets exactly one: assert it, including in reset and power-down.