AMBA APB · Module 3

PSLVERR — The Subordinate Error

PSLVERR, the APB3 error response — what it means, the completion edge it is sampled on, what causes a subordinate to assert it, and why it is a status report, not a retry.

Module 2 told you that APB3 added PSLVERR as the protocol's error signal — the version that introduced a way for a subordinate to say "that access failed." That placed the signal in history; it did not give you its contract. To use PSLVERR in real RTL you need to know exactly when it is meaningful, what it means, and — most importantly — what it does not do. PSLVERR is a single optional bit that a subordinate drives at the completion edge to label a transfer as failed, and the transfer still completes normally either way. The single idea to carry: PSLVERR is a status report, not an abort and not a retry — it tells you the access failed, then leaves what to do about it entirely to software.

1. What problem is being solved?

The problem is giving a subordinate a standard way to say "I could not honour that access" — without changing how the access finishes.

The original APB had no error path at all. A subordinate that was written at a read-only register, or addressed at an offset it did not implement, had only bad options: complete silently with garbage, or hang the bus. Neither is acceptable in a real SoC, where firmware needs to know when a register access was illegal so it can log a fault or raise an exception. APB3 closes this gap with one extra bit:

PSLVERR low at completion means the access succeeded — read data is valid, the write took effect.
PSLVERR high at completion means the access failed — the subordinate is telling the manager (and ultimately software) that something was wrong with this access.

That one bit is the entire error mechanism. It is deliberately minimal: it does not say why the access failed, it does not undo it, and it does not ask for a retry. It simply qualifies the transfer that just finished, so that the layer above can decide what the failure means.

2. Why the lifecycle view is not enough

Module 2 named PSLVERR as the error signal APB3 added — a version-history fact: "newer APB can report errors." That is true, but knowing a signal exists is not knowing its contract. To drive PSLVERR in a subordinate or check it in a manager, the version view leaves three things unstated:

Exactly when it is sampled. PSLVERR is only meaningful at the completion edge — the cycle where PSEL, PENABLE, and PREADY are all high. Its value during setup or during wait states is don't-care; the manager reads it exactly when it reads completion, and nowhere else.
What it does to the transfer. Nothing structural. A failed transfer completes on the same edge a successful one does. PSLVERR does not stretch, abort, or restart the access — it only attaches a pass/fail label to a transfer that is finishing normally.
Whose job the recovery is. The hardware does nothing further. PSLVERR is a status report handed up to software, which decides whether to log, retry in firmware, or fault. There is no protocol-level retry.

Knowing APB3 "added errors" tells you the capability exists; knowing the contract tells you the one cycle it lives in and the fact that it changes the result, not the shape, of the transfer — which is what you need to build or debug one.

3. The signal's mental model

The model: PSLVERR is a receipt stamp — it marks a completed transaction as OK or FAILED, after the transaction is already done.

Think of a cashier handing back a receipt. The purchase has gone through; the transaction is complete. The stamp on the receipt — "PAID" or "DECLINED" — does not undo the transaction or replay it. It is a record of the outcome that you, the customer, act on afterward. PSLVERR is that stamp: at the completion edge the transfer is finishing regardless, and PSLVERR is simply the stamp that says whether the result was good. The cashier does not re-ring the order; you decide what to do with a declined receipt.

Three refinements make the model precise:

The stamp is only read at the till. PSLVERR is valid only at the completion edge (PSEL, PENABLE, PREADY all high). Reading it at any other cycle is reading a blank stamp — meaningless.
A stamped receipt is still a completed receipt. The transfer completes normally whether PSLVERR is high or low. "Failed" is the outcome, not a cancellation; the bus has already moved on.
The cashier does not retry — you do. PSLVERR carries no retry semantics. Acting on a failure is software's job entirely; the hardware's contribution ends at raising the bit. If a subordinate never errors, PSLVERR is simply tied low.

4. Real SoC / hardware context

In hardware, PSLVERR is an optional output of the subordinate. A subordinate that can never fail an access — many simple, fully-mapped peripherals — does not implement it at all and ties the line low. A subordinate that can fail drives PSLVERR combinationally or registered so that it is valid in the completion cycle, alongside PREADY high.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// PSLVERR generation in an APB subordinate (teaching sketch — not a full slave).
// Drive PSLVERR high *at completion* when the access is illegal, else low.
// Completion is the cycle where PSEL & PENABLE & PREADY are all high.
 
localparam STATUS_ADDR = 8'h04;  // a read-only status register
localparam MAX_OFFSET  = 8'h0F;  // highest mapped offset
 
wire access      = psel && penable;          // in the ACCESS phase
wire bad_offset  = paddr[7:0] > MAX_OFFSET;  // out-of-range / unmapped
wire write_to_ro = pwrite && (paddr[7:0] == STATUS_ADDR);  // write to read-only
 
// This subordinate is always ready, so it completes the cycle PENABLE is high.
assign pready  = 1'b1;
// PSLVERR qualifies the completing access; it must be valid when PREADY is high.
assign pslverr = access && pready && (bad_offset || write_to_ro);

Two things fall out of that. First, pslverr is gated by access && pready — it asserts only in the completion cycle, never during setup or a wait state, which is exactly when the manager will sample it. Second, the conditions are pure access-validity checks (out-of-range offset, write to a read-only register); a protection violation or an internal parity error would be additional terms in the same OR. The subordinate raises the flag and is done — it does not roll back the write or signal a retry, because APB has no such mechanism.

On the manager side, the bridge samples PSLVERR on the same completion edge it already watches for PREADY. If it is high, the bridge typically captures the error into a status register or propagates it upstream (for example to the register-access layer or the fabric that bridged the request down), so that software sees a failed access. The transfer itself still completes; the manager does not re-issue it.

Figure 1 — PSLVERR sampled at the completion edge across two transfers, against PCLK. Both transfers walk the same SETUP then ACCESS path and both complete on a cycle where PSEL, PENABLE, and PREADY are all high. In transfer 1, PSLVERR is low at that completion cycle — the access succeeded. In transfer 2, the completion edge is structurally identical, but PSLVERR is high — the access failed. The diagram shows that PSLVERR is only read at the completion edge (with PREADY high) and that it qualifies the result without changing how the transfer finishes: both complete normally, PSLVERR just labels them OK or FAIL.

Figure 2 — what makes a subordinate assert PSLVERR. Common causes: an access to a reserved or unmapped offset, a write to a read-only register, a protection or security violation, and an internal or parity error. In every case the transfer still completes normally at its completion edge with PSLVERR high — it is a status report, not an abort or a retry — and handling the error (logging it, faulting, retrying in software) is the responsibility of software above the bus, not the bus itself.

5. Engineering tradeoff table

PSLVERR is a one-bit signal by design. Each property trades a capability APB chose not to carry for the simplicity that keeps APB cheap.

`PSLVERR` property	What it gives up	What it buys	Why it is correct for APB
A single pass/fail bit	A reason / error code	The cheapest possible error channel	Software can read the cause from its own register map
Sampled only at completion	A mid-transfer error path	One sampling edge, shared with `PREADY`	The manager already watches that edge — zero extra cost
Transfer completes anyway	A hardware abort	A uniform, simple completion model	No special "cancelled transfer" state to handle
No retry semantics	A protocol-level redo	A clean status-only contract	Retry policy belongs to software, not the bus
Optional (tied low if unused)	Mandatory error support	Simple subordinates stay simple	Many peripherals genuinely cannot fail an access

The throughline: PSLVERR reports that an access failed and stops there. It does not say why, does not undo, and does not retry — every richer capability is deliberately pushed up to software, which keeps the bus signal to a single bit on an edge that already exists.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PSLVERR high aborts or cancels the transfer." No. The transfer completes normally on the same edge it always would. PSLVERR is a label on a finished transfer, not a cancellation. The bus has already moved on.
"PSLVERR triggers a hardware retry." No. APB has no retry mechanism. PSLVERR is a status report; whether to retry is entirely software's decision, done from firmware, not by the bus.
"The manager should sample PSLVERR whenever it is high." No. PSLVERR is only valid at the completion edge — PSEL, PENABLE, and PREADY all high. Its value during setup or wait states is don't-care; sampling it then reads noise.
"PSLVERR carries an error code telling software what went wrong." No. It is a single bit — pass or fail. Any reason (which register, which fault) must be read from the subordinate's own status registers, not from the bus.
"Every APB subordinate must drive PSLVERR." No. It is optional. A subordinate that cannot fail an access ties PSLVERR low. And PSLVERR is APB3 — pre-APB3 designs had no error response at all.
"PSLVERR can be high while PREADY is still low to signal an early error." No. There is no early-error path. The subordinate holds the access (PREADY low) until it is ready to complete, and PSLVERR only becomes meaningful when it finally drives PREADY high.

7. Interview framing

PSLVERR is a sharp filter in interviews because the wrong instinct — "it's the error signal, so it aborts the transfer" — is so common. A precise answer proves you understand that APB's error handling is status reporting, not transaction control.

The strong answer states the contract and the non-behaviour together: PSLVERR is APB3's optional one-bit error response, sampled at the completion edge (PSEL, PENABLE, PREADY all high), where high means the access failed and low means it succeeded; if unused it is tied low. Then deliver the two depth points that separate you: the transfer completes normally whether or not PSLVERR is high — it qualifies the result, it does not abort or retry — and handling the error is software's job, because the bus carries only one bit and no reason code. Name a couple of real causes (write to a read-only register, reserved/unmapped offset, protection violation, internal error) to show you know what actually drives it. That framing — error as status, not retry — is exactly what an interviewer is listening for.

8. Q&A

9. Practice

Draw the waveform. Draw two back-to-back transfers — one successful, one failed — and mark the exact cycle where PSLVERR is sampled, confirming both complete on the same kind of edge.
Write the assertion. Write the one-line condition a subordinate uses to drive PSLVERR, gated so it is only valid at completion, for a write to a read-only register or an out-of-range offset.
State the non-behaviour. In one sentence each, explain why PSLVERR does not abort the transfer and does not trigger a hardware retry.
List the causes. Name four distinct reasons a subordinate might assert PSLVERR, and for each say whether it is an address, direction, protection, or internal issue.
Find the bug. A manager samples PSLVERR during a wait state (PREADY low) and reports an error. State which rule is broken and what the correct sampling condition is.

10. Key takeaways

PSLVERR is APB3's optional one-bit error response — high at completion means the access failed, low means it succeeded; if unused, it is tied low.
It is sampled only at the completion edge — PSEL, PENABLE, and PREADY all high — the same edge the manager already watches for PREADY, so it costs nothing structurally.
The transfer completes normally either way. PSLVERR qualifies the result; it never aborts, cancels, or stretches the transfer. "Failed" is an outcome, not a cancellation.
It is status, not retry. APB has no retry mechanism — handling a failed access (log, fault, retry in firmware) is entirely software's job, and the bus carries no reason code.
Common causes are access-validity issues: write to a read-only register, reserved/unmapped offset, protection violation, or an internal/parity error inside the subordinate.
It arrived in APB3. The original APB had no error path; PSLVERR is the single optional bit that gave the protocol a standard way to report a failed access without changing the lifecycle.