AMBA APB PSLVERR Explained – Your VLSI Journey Starts Here

📋 What PSLVERR Is

PSLVERR (Peripheral Slave Error, or Transfer Error in APB5 terminology) is an optional 1-bit signal driven by the Completer. When asserted HIGH at the completion of a transfer, it signals that the transfer completed with an error condition — the Completer could not successfully execute the requested read or write.

PSLVERR is an APB3 feature. APB2 has no error reporting mechanism — any error is silently discarded and the initiating system bus receives a normal (success) response. APB3 and later allow peripherals to propagate errors back to the system.

PSLVERR = 1 does not mean the transfer was aborted. The transfer completed — it ran through the full Setup + Access cycle and PREADY was asserted. PSLVERR is sampled at exactly the same moment as the data (PRDATA on a read). It is an outcome indicator, not an abort signal.

Common causes of PSLVERR:

Write to a read-only register
Access to an unimplemented or reserved address within the peripheral’s range
Access that violates protection rules (e.g. non-secure access to a secure register, indicated via PPROT)
Peripheral in a state where the access is illegal (e.g. writing to a locked register while a DMA is running)
Internal peripheral hardware error detected during the access

⏱ The Validity Window

PSLVERR has a very precise validity rule in the spec:

PSLVERR is only valid when PSELx=1, PENABLE=1, and PREADY=1 simultaneously. Its value at any other time must be completely ignored by the Requester.

Figure 1 — PSLVERR is only valid at the transfer completion cycle, when all three conditions are simultaneously true. On all other cycles its value is undefined and must be ignored.

The spec also recommends (but does not require) that PSLVERR is driven LOW when PSELx, PENABLE, or PREADY are LOW. This makes simulation traces cleaner and prevents misleading PSLVERR glitches from being confused with error conditions. Peripherals without PSLVERR support tie the signal permanently LOW — the Requester sees a constant “no error” indication.

⏱ Failing Write Transfer

A write transfer that completes with PSLVERR=1 proceeds through exactly the same phases as a successful write — Setup, then Access (with any number of wait states). The only difference is that PSLVERR is asserted at the completion cycle alongside PREADY.

Figure 2 — Failing write transfer. The transfer proceeds normally through Setup and Access phases (with one wait state). At T4, PREADY and PSLVERR are both asserted simultaneously — the transfer completes with an error. The Requester notes the error and maps it to the system bus error response.

Key observations from the failing write timing:

The transfer still goes through the full Setup and Access cycle — there is no early termination
PWDATA is presented and driven stably throughout — the peripheral may or may not have used it
PSLVERR and PREADY are asserted in the same cycle — PSLVERR is only meaningful alongside PREADY=1
After T4, PSELx and PENABLE are deasserted exactly as in a successful transfer
PSLVERR returns to LOW after the completion cycle (recommended behaviour)

⏱ Failing Read Transfer

A read error follows the same pattern as a write error. PSLVERR is asserted alongside PREADY at the completion cycle. Additionally, PRDATA is driven by the Completer at completion — but on an error, that data is invalid.

Figure 3 — Failing read transfer. PRDATA is driven but contains invalid data (hatched region). PSLVERR is asserted at T4 alongside PREADY. The Requester samples PRDATA at T4 but the PSLVERR flag tells the system bus that the data is not valid — the AXI/AHB bridge will return an error response to the initiator.

On a read error, PRDATA may contain anything. The spec explicitly states: “Read transactions that receive an error can return invalid data. There is no requirement for the peripheral to drive the data bus to all 0s for a read error.” The Requester must not use PRDATA if PSLVERR=1 — but the spec also notes the Requester may still use it. The Completer cannot rely on PSLVERR to prevent the Requester from reading PRDATA.

📋 Register Update Behaviour on Error

One of the most important — and most misunderstood — aspects of PSLVERR is what happens to the peripheral’s internal state when an error occurs.

Write error — was the register updated?

The spec states: “Transactions that receive an error might or might not have changed the state of the peripheral. This is peripheral-specific and either state is acceptable.”

This means:

A write that returns PSLVERR=1 may have written the data to the register (the peripheral accepted then flagged an error)
A write that returns PSLVERR=1 may not have written the data (the peripheral rejected the write before updating)
The initiating software cannot assume either outcome without reading back the register

Furthermore: “When a write transaction receives an error, this does not mean that the register within the peripheral has not been updated.” This is counterintuitive — many developers assume an error means the write failed. With APB, that assumption is wrong.

Always read back after a write error if state correctness matters. If your driver handles PSLVERR=1 on a write and needs to know the actual register state, it must issue a follow-up read. Do not assume the write either succeeded or failed.

Read error — is the data valid?

Similarly: a read error does not guarantee the data is invalid. The spec says the Requester may still use PRDATA from a read that received PSLVERR=1. The peripheral cannot prevent the Requester from using the data by asserting PSLVERR — that flag is purely informational for the higher-level bus protocol.

In practice, most system designs treat any PSLVERR=1 as a fatal error for that transfer and do not use the returned PRDATA. But this is a software convention, not an APB protocol requirement.

Figure 4 — PSLVERR behaviour guarantees for write and read errors. Note that in both cases the transfer technically completed — PSLVERR is an outcome indicator, not an abort mechanism.

📋 Mapping to AXI and AHB

The APB bridge translates PSLVERR to the appropriate error response on the system bus side. The spec defines these mappings explicitly:

Source bus	Transfer type	APB error signal	System bus response	Response value
AXI to APB bridge	Read	`PSLVERR=1`	`RRESP[1:0]`	`2'b10` = SLVERR
AXI to APB bridge	Write	`PSLVERR=1`	`BRESP[1:0]`	`2'b10` = SLVERR
AHB to APB bridge	Read or Write	`PSLVERR=1`	`HRESP`	`1'b1` = ERROR

The bridge must:

Sample PSLVERR on the APB completion cycle (PSELx=1, PENABLE=1, PREADY=1)
If PSLVERR=1, hold the system bus in an error response state for the required number of cycles per that bus’s protocol
For AXI: return RRESP=SLVERR (2’b10) with the read data channel, or BRESP=SLVERR (2’b10) on the write response channel
For AHB: assert HRESP=1 (ERROR) for two cycles as required by the AHB protocol, then return OKAY

AXI DECERR vs SLVERR. AXI defines two error types: DECERR (decode error — the address doesn’t map to any peripheral) and SLVERR (slave error — the peripheral signalled an error). APB PSLVERR maps to SLVERR, not DECERR. If the bridge itself cannot decode the address (no PSELx asserted), that maps to DECERR and PSLVERR is never involved.

📋 Implementation Notes

Peripherals that do not implement PSLVERR

PSLVERR is optional. A peripheral that has no error reporting capability simply does not have the signal on its port. The APB bridge ties the PSLVERR input for that slot to 1’b0 (logic LOW). This means the bridge always sees “no error” for that peripheral — which is correct since the peripheral has no way to detect or report errors.

When to assert PSLVERR

PSLVERR is asserted simultaneously with PREADY on the transfer completion cycle. The peripheral cannot signal a “deferred” error — once PREADY is asserted, the transfer is done. If the peripheral needs to report an error it must do so in the same cycle as PREADY.

The recommended (not required) behaviour is to drive PSLVERR LOW when PSELx, PENABLE, or PREADY are LOW. This means:

PSLVERR is LOW during IDLE (no transfer)
PSLVERR is LOW during the Setup phase
PSLVERR is LOW during wait state cycles (PREADY=0)
PSLVERR is asserted only in the completion cycle if there is an error

Detecting unimplemented address ranges

A common use of PSLVERR is for address decode errors within a peripheral. When a peripheral has a 4 KB address window but only implements 16 registers, accesses to the unimplemented portion of its window should return PSLVERR=1. This is better than silently returning garbage data, which would be indistinguishable from a valid register value.

Typical peripheral implementation pattern:
assign PSLVERR = PSELx & PENABLE & PREADY & addr_decode_error;
where addr_decode_error is HIGH when PADDR falls outside the implemented register range. This ensures PSLVERR is only asserted at completion and only for invalid addresses.

📋 Quick Reference

Item	Rule
PSLVERR introduced in	APB3 — not available in APB2
Source	Completer (peripheral) — driven to Requester (bridge)
Width	1 bit
Valid when	PSELx=1 AND PENABLE=1 AND PREADY=1 — the completion cycle only
Ignored when	Any of PSELx, PENABLE, PREADY are LOW — value is undefined and must be ignored
Recommended drive when not valid	Drive LOW (not required, but strongly recommended)
Peripheral without PSLVERR	Tie PSLVERR input at bridge to 1’b0
Write + PSLVERR=1	Register may or may not have been updated — peripheral-specific, either is allowed
Read + PSLVERR=1	PRDATA is invalid — no requirement to drive 0 on error
AXI write error mapping	BRESP = 2’b10 (SLVERR)
AXI read error mapping	RRESP = 2’b10 (SLVERR)
AHB error mapping	HRESP = 1’b1 (ERROR) for two cycles
PSLVERR vs DECERR	PSLVERR → SLVERR. Address decode failures at the bridge → DECERR. They are different.
Typical use cases	Write to read-only register, access to unimplemented address, protection violation, peripheral internal error
Driver advice on write error	Read back the register if state correctness matters — do not assume the write failed or succeeded