A driver reads a status register and gets an error. Is the device broken, or was the address wrong? The fix for one is to reset the device; the fix for the other is to correct the driver. If both failures come back as the same "error", software can only guess. Protocols separate the two because the response to each is different.
What kinds of failure should a response report, who reports each, and how do they get back to the requester?
The obvious response status is a single bit: worked, or did not. It is enough to stop a requester using bad data, but not enough to tell anyone what to do next. Was there nothing at that address (a software bug)? Was the target there but unable to do it (a device problem, or an access it does not allow)? Did the data get corrupted on the way (a hardware fault)? Each points to a different fix.
Error | Means | Generated by | Usual fix |
|---|---|---|---|
Decode error | No target owns this address | The interconnect's default target (lesson 5.3) | Software bug or bad pointer |
Target (slave) error | The target exists but could not do the access: illegal access, internal fault, unsupported size, powered down | The target itself | Driver or device fault; may need a reset |
Data integrity error | The data was corrupted (an uncorrectable ECC error, a failed end-to-end check) | Whoever detects it: a memory controller, a receiver | Hardware fault; contain it (lesson 10.8) |
Timeout | No answer arrived in time | The requester or an interconnect monitor (lesson 9.9) | Target hung or lost; reset it |
Each hop translates. A bridge maps the far side's error codes to the near side's closest equivalent (lesson 5.17). Where there is no equivalent, it uses the more severe one, never success.
Bursts and split transactions combine. One response for a whole burst must report an error if any beat failed; a read with data per beat can mark each beat.
Posted writes cannot report back (lesson 5.7): their errors must be logged and signalled elsewhere (lesson 10.15).
Requesters must act on errors. A processor typically turns a bus error into an exception at the faulting instruction; a DMA engine stops and reports in a status register.
Protocol | Error responses |
|---|---|
AXI | SLVERR (the target could not complete the access) and DECERR (no target at the address, usually from the interconnect's default target); read data carries a response per beat, a write gets one for the whole burst. |
APB | PSLVERR (from APB3) marks a failed transfer. |
PCI Express | Completions carry a status (for example Unsupported Request, Completer Abort); errors on posted requests are reported through error messages and logs. |
A bridge (illustrative) translated every downstream error into the upstream protocol's "OK", because its designer could not decide which error code to use. For two years, failed peripheral accesses looked like successes, returning zeros. When a sensor's interface failed in the field, the system read zeros for its temperature and kept running hot. Mapping every downstream error to a target error would have made the failure visible on the first read.
A decode error, from the interconnect's default target.
The closest, or more severe, error, never success.
Responses distinguish decode errors (no target), target errors (target could not do it), data errors and timeouts.
Decode errors come from the interconnect's default target; target errors from the target itself.
Every hop must translate errors, bursts must merge them, and posted writes must log them.