APB does have an error channel — it is called PSLVERR, it has existed since APB3, and the belief that "APB can't report errors" is a stale memory of APB2. The myth is not baseless: the APB2 baseline genuinely had no error signal, so a slave that could not honour an access had no way on the bus to say so. APB3 fixed exactly that, adding a single-bit error qualifier — PSLVERR — that a slave drives high, aligned to PREADY on the completing access edge, to stamp a transfer as failed. A bridge samples that bit and maps it into its upstream fabric's error response (AHB HRESP=ERROR, AXI RRESP/BRESP=SLVERR), so the fault propagates all the way to the CPU. The single idea to carry: the error path is real and complete from APB3 onward — the dangerous bug is not that the protocol lacks reporting, it is a manager or bridge that ignores PSLVERR and turns a genuine fault into a silent success.

1. Problem statement

The problem the myth obscures is how a deliberately minimal bus reports "this access failed" without an abort, a retry, or an error channel — and why believing it cannot leads directly to silent data corruption.

APB was designed as the low-power, low-complexity leaf of the AMBA family: no pipelining, no split transactions, no out-of-order completion. It is tempting to conclude from that minimalism that APB also has no error reporting — and for APB2 that conclusion was correct. But minimal is not the same as absent. APB3 added exactly one mechanism, and understanding it means separating three facts the myth conflates:

• There is a signal, and it is spec-defined. PSLVERR is part of the AMBA APB protocol from APB3 (AMBA IHI 0024C section 2.1). It is not a vendor extension or a sideband hack — it is a first-class bus wire that any slave with an address map, protection policy, or a failable resource is expected to drive.
• The report is a one-cycle verdict, not a transaction outcome. Because APB has no error channel to hold, PSLVERR is qualified: it is only meaningful on the completing edge where psel, penable, and pready are all high. The transfer still completes on that edge; PSLVERR merely colours it pass or fail. That is a narrower contract than AHB's two-cycle error response or AXI's response fields, but it is a genuine report.
• The report must be consumed to become a fault. APB itself does nothing with PSLVERR — no retry, no interrupt, no rollback. The manager or bridge must map it to an upstream error response or a status bit. An unconsumed PSLVERR is a report that no one hears, which is functionally identical to the myth's "no reporting at all."

So the engineering problem is not "does APB report errors" — from APB3 it plainly does — but "what exactly is the report, when is it valid, and what must the integrator do so the report reaches software instead of silently disappearing."

2. Why previous knowledge is insufficient

The PSLVERR domain chapters taught the signal in depth; this chapter uses that knowledge to kill a specific false belief and to trace the report end to end across the fabric boundary — which the single-signal chapters did not do.

• pslverr-behavior taught the contract, not the myth's origin. That chapter pinned what PSLVERR means — a verdict sampled on the completing edge, not an abort — and how a mis-timed one is lost. It assumed you already accept that the signal exists. This chapter attacks the prior belief that it does not, and shows precisely why engineers still think APB is error-blind: they are remembering apb2-baseline, the version that genuinely lacked it.
• pslverr-generation built the slave side, not the mapping. It built the generator that gathers error sources and drives PSLVERR aligned to pready. But a PSLVERR that fires perfectly and is then dropped at the bridge is still a silent failure. The missing half is what the bridge does with the bit — the mapping to HRESP/RRESP/BRESP — which is what actually makes the error reach the CPU.
• The single-signal view never crosses the fabric boundary. Knowing PSLVERR toggles correctly says nothing about whether a bus-fault exception fires in the processor. The report only becomes a reported error when the bridge translates it into the upstream protocol's error semantics. That translation — and the failure modes when it is missing — is the new model, and it is where the myth does real damage: people who "know PSLVERR exists" still ship SoCs where it is never mapped.

So the knowledge to add is not the signal — you have that from Module 9 — it is the end-to-end path: APB2 had none, APB3 added PSLVERR, the slave asserts it with pready, and the bridge maps it upstream. That full chain, and where each link breaks, is this chapter. The comparison across the whole AMBA family lives in apb-vs-ahb-vs-axi; the version history lives in apb-version-evolution.

3. Mental model

The model: PSLVERR is a courier's "delivery failed" stamp that only becomes a real complaint when the depot files it upstream. The slave is the courier; it always completes the delivery (the transfer finishes on the pready edge) but on a bad address, a protection violation, or a peripheral fault it stamps the receipt FAILED — that stamp is PSLVERR, applied on the exact edge of delivery. The bridge is the depot: it reads the stamp and files a formal complaint in the parent company's system — AHB HRESP=ERROR, AXI RRESP/BRESP=SLVERR. Only then does the manager or CPU act on it. The myth is believing the courier has no stamp at all — true for the APB2 courier, false for every courier since APB3.

Three refinements make it precise:

• The stamp exists and is edge-locked. PSLVERR is a real APB3 wire, and it is only the verdict on the completing edge (psel && penable && pready). Its value elsewhere is don't-care. So "APB reports errors" is true, but narrowly — the report is a one-cycle qualifier, not a held channel, which is precisely why a minimal bus could afford it.
• The filing is the bridge's job, and it is where the myth bites. A slave can stamp perfectly and the error still vanish if the depot never files it. The bridge must map PSLVERR into the upstream error response; a bridge that hardwires HRESP=OKAY regardless of PSLVERR recreates the exact "silent failure" the myth predicts — not because APB lacks reporting, but because the integrator threw the report away.
• The version boundary is the whole origin of the myth. APB2 had no PSLVERR; a slave there truly could not report an error on the bus. APB3 added it (section 2.1). Anyone whose mental model froze at APB2 — or who read legacy RTL — will "know" APB is error-blind. Dating your knowledge to the version dissolves the myth: it was true, then it was fixed.

4. Real SoC implementation

The full path is two pieces of RTL: the slave asserts PSLVERR with PREADY on the completing edge for a bad access, and the bridge maps that sampled bit into its upstream error response. Both are short; the correctness is in the alignment (slave side) and the faithful translation (bridge side).

// ============================================================
// SLAVE SIDE — assert PSLVERR with PREADY on the completing edge
// for a bad access (bad address / protection / peripheral fault).
// APB3, AMBA IHI 0024C section 2.1. APB2 had NO such wire.
// ============================================================
// err is the slave's "I cannot honour THIS access" term, qualified to
// the current access so a stale condition can't leak into a clean one.
wire access_phase = psel && penable;
wire err = access_phase &
           (decode_err     |   // paddr in-window but unmapped (bad address)
            prot_err        |   // PPROT fails this register's policy
            internal_err);      // peripheral/HW fault for this access
 
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn) begin
    pready  <= 1'b0;
    pslverr <= 1'b0;
  end else if (access_phase && access_done) begin
    pready  <= 1'b1;          // complete the transfer THIS cycle...
    pslverr <= err;           // ...and stamp the verdict on the SAME edge
  end else begin
    pready  <= 1'b0;
    pslverr <= 1'b0;          // not completing -> defined 0, never float/X
  end
end
// PSLVERR is a flag, not an abort: PREADY still rises, the transfer
// completes. A correct slave also suppresses the write side effect on err.
 
// ============================================================
// BRIDGE SIDE — map the sampled PSLVERR to the UPSTREAM error response.
// This is the half the myth ignores: without it, PSLVERR vanishes.
// ============================================================
// The bridge samples PSLVERR on the completing APB edge and drives the
// upstream fabric's error code. Clean access -> OKAY; PSLVERR -> ERROR/SLVERR.
wire apb_complete = psel && penable && pready;   // the sampling instant
 
// --- AHB upstream (2-bit HRESP): OKAY=2'b00, ERROR=2'b01 ---
localparam HRESP_OKAY = 2'b00, HRESP_ERROR = 2'b01;
assign hresp = (apb_complete && pslverr) ? HRESP_ERROR : HRESP_OKAY;
 
// --- AXI upstream (2-bit response): OKAY=2'b00, SLVERR=2'b10 ---
localparam AXI_OKAY = 2'b00, AXI_SLVERR = 2'b10;
// a read maps PSLVERR -> rresp, a write maps it -> bresp
assign rresp = (apb_complete && pslverr && !pwrite) ? AXI_SLVERR : AXI_OKAY;
assign bresp = (apb_complete && pslverr &&  pwrite) ? AXI_SLVERR : AXI_OKAY;

Three facts make this the right structure. First, the slave stamps and completes on the same edge — pready and pslverr are registered together, so the verdict is valid exactly where the bridge samples it, and PREADY is never held low on an error (that would hang the bus). Second, the bridge is the translator, not a bystander — it samples PSLVERR at apb_complete and maps it to the upstream fabric's own error semantics: AHB's HRESP=ERROR, AXI's RRESP=SLVERR on a read or BRESP=SLVERR on a write. This mapping is the load-bearing half of "APB reports errors" — the slave's report only reaches the CPU because the bridge translates it. Third, the non-obvious insight: the error path's weakest link is not the slave and not the wire — it is a bridge that hardwires HRESP=OKAY (or leaves RRESP/BRESP at OKAY) and never reads PSLVERR. That bridge makes a fully-spec-compliant APB3 slave behave exactly like the myth's error-blind APB2 slave, which is why "APB has no error reporting" survives in codebases where the reporting was simply never wired through.

5. Engineering tradeoffs

The design judgment is not "should APB report errors" — from APB3 it can and should — but what counts as an error, how faithfully the bridge maps it, and what the manager does with it. The table is the myth-to-reality map, version by version and layer by layer.

The throughline: the error channel is real, but it is only as good as its weakest layer. The version boundary (APB2 vs APB3) settles whether the signal exists; the timing (aligned to pready) settles whether the slave's report is sampled correctly; the bridge mapping settles whether the report crosses into the upstream fabric; and the manager's consumption settles whether software ever learns of it. A believer in the myth typically fails at the bridge or manager layer — not because APB lacks a report, but because they never built the consumer, so the report they "know exists" is thrown away. That is the practical difference between "APB has no error reporting" (false since APB3) and "this SoC's APB errors are not reported" (true whenever any layer drops the bit). The tradeoff work — which conditions are errors at all, whether an unmapped write is a PSLVERR or a silent drop — is a policy choice covered in read-error-responses and write-error-handling.

6. Common RTL mistakes

7. Debugging scenario

The signature myth-driven bug is a genuine fault that never reaches software because the report was dropped somewhere in the chain — the slave, the bridge, or the manager — and the team concludes "well, APB can't report errors anyway."

• Observed symptom: firmware reads an unmapped register behind an APB slave and gets clean data with no bus fault, no error interrupt, nothing logged. The slave is an APB3 slave that generates PSLVERR. The team's first hypothesis is the myth itself — "APB has no error reporting, so this is expected." It is not expected; the report is being dropped.
• Waveform clue: on the completing APB edge (psel && penable && pready), PSLVERR is high — the slave stamped the fault correctly. But the upstream HRESP (AHB) is OKAY on that same cycle, or the AXI RRESP is OKAY. The report existed on the APB side and was thrown away at the bridge. In a second variant, PSLVERR pulses high one cycle early (during a wait) and is low by completion — a slave-side alignment bug that also loses the report (error-response-timing).
• Root cause: the bridge's response logic hardwired HRESP = HRESP_OKAY (or left RRESP/BRESP at OKAY) and never sampled PSLVERR at all. A fully-compliant APB3 slave was reporting the error; the bridge dropped it, recreating APB2 behaviour in an APB3 system. The team's "APB can't report errors" belief let the bug hide in plain sight because it matched their (wrong) mental model.
• Correct RTL: map the sampled PSLVERR into the upstream error response on the completing edge:

wire apb_complete = psel && penable && pready;
assign hresp = (apb_complete && pslverr) ? 2'b01 /*ERROR*/ : 2'b00 /*OKAY*/;
// or, for an AXI upstream:
assign rresp = (apb_complete && pslverr && !pwrite) ? 2'b10 /*SLVERR*/ : 2'b00;
assign bresp = (apb_complete && pslverr &&  pwrite) ? 2'b10 /*SLVERR*/ : 2'b00;

• Verification assertion: prove the report actually crosses the bridge — a PSLVERR at completion must produce an upstream error response, and a clean completion must not:

// every completing PSLVERR maps to an upstream error (AHB example)
ap_pslverr_to_hresp: assert property (@(posedge pclk) disable iff (!presetn)
  (psel && penable && pready && pslverr) |-> (hresp == 2'b01));
 
// a clean completion never fabricates an upstream error
ap_clean_no_error: assert property (@(posedge pclk) disable iff (!presetn)
  (psel && penable && pready && !pslverr) |-> (hresp == 2'b00));

• Debug habit: when an APB error is "lost," do not accept "APB can't report errors" — trace the bit through all three layers. Put a marker on the completing edge and check PSLVERR there (slave stamped it?), then check the upstream HRESP/RRESP/BRESP on the same cycle (bridge mapped it?), then check the fault handler (manager consumed it?). The report is real; find the layer that drops it. This is the practical debug side of error-propagation.

8. Verification perspective

Because the myth's damage is a dropped report, verification must prove the report survives every layer — the signal exists and aligns (slave), it maps to the upstream response (bridge), and a clean access never fabricates one — with coverage that an error was actually injected on both a read and a write.

• The report exists and aligns at the slave. Assert PSLVERR is high only on a completing edge (pslverr |-> psel && penable && pready) and never X there. This catches the alignment variant of the silent-failure bug — a PSLVERR that pulses during a wait and is gone by completion is a lost report, indistinguishable to software from "no reporting." A bad-address stimulus must produce PSLVERR at completion: assert property (@(posedge pclk) disable iff(!presetn) (psel && penable && pready && decode_err) |-> pslverr);.
• The report crosses the bridge — the central property against the myth. Assert that a completing PSLVERR maps to the upstream error code ((apb_complete && pslverr) |-> hresp == ERROR, or RRESP/BRESP == SLVERR split by direction) and, symmetrically, that a clean completion never produces an upstream error. This pair is what proves the SoC does not behave like error-blind APB2 — the exact failure a myth-believing integrator ships. It is a bridge-level check that single-slave PSLVERR tests cannot see.
• Cover the injection matrix, read and write. Functional coverage must show an error was injected on a read and on a write (they map to different upstream fields — RRESP vs BRESP — and the write path additionally must suppress the side effect), across zero-wait and multi-wait completions (the verdict must align to the actual completing edge in both), and for each source — bad address, protection, peripheral fault. A suite that only ever errors a zero-wait read leaves the wait-aligned and write-error corners — exactly where the report gets dropped — uncovered.

The point: verifying against this myth is verifying end to end. Prove the slave stamps and aligns, prove the bridge maps and never fabricates, and cover read/write, wait-count, and source — so a real fault can be shown to reach the CPU, not just that PSLVERR toggled on the APB side.

9. Interview discussion

"Does APB have any error reporting?" is a deceptively sharp screening question: a candidate who answers a flat "no" reveals their APB knowledge is frozen at APB2, while a strong answer dates the belief, names the signal, and traces the report to the CPU.

Frame it as a version story with an end-to-end path: the myth is true for APB2 — that baseline had no error signal — but APB3 (AMBA IHI 0024C §2.1) added PSLVERR, so the correct answer is "APB2 could not, APB3 and later can." Then deliver the mechanism: the slave asserts PSLVERR high with PREADY on the completing edge — it is a flag, not an abort, so the transfer still completes — for a bad address, a protection violation, or a peripheral fault. The bridge then maps PSLVERR into its upstream fabric's error response: AHB HRESP=ERROR, AXI RRESP=SLVERR on a read or BRESP=SLVERR on a write, because there is no PSLVERR wire upstream and the report must be translated. Land the depth point that separates spec-readers from silicon debuggers: the real bug is not that APB lacks reporting — it is a bridge or manager that ignores PSLVERR and turns a genuine fault into a silent success, which recreates APB2 behaviour in an APB3 system. Closing with "so when someone says APB can't report errors, they're either remembering APB2 or describing a bridge that never mapped PSLVERR — the protocol has had the channel since APB3" signals you know the history and the failure mode, not just the table. If you want to go further, note the read/write asymmetry (RRESP vs BRESP, plus the slave must suppress the write side effect on error) and contrast APB's one-cycle qualifier with AHB's two-cycle error response — the full comparison is apb-vs-ahb-vs-axi.

10. Practice

1. Date the myth. State in which APB version "APB has no error reporting" is true and in which it is false, name the signal that fixed it, and cite the AMBA reference that defines it.
2. Stamp the verdict. From memory, write the registered slave block that asserts PSLVERR with PREADY on the completing edge for a bad access and drives 0 otherwise; explain why PREADY must not be held low on an error.
3. Map it upstream. Write the bridge assignments that map a sampled PSLVERR to AHB HRESP and to AXI RRESP/BRESP, and explain why the read and write cases target different fields.
4. Find the dropped report. Given a waveform where PSLVERR is high at the completing edge but HRESP is OKAY, name the layer that dropped the report and give the one-line fix.
5. Cover the matrix. List the coverage bins that prove an APB3 SoC does not behave like error-blind APB2 — across read/write, wait-count, and error source — and state which single assertion proves the bridge mapped the error.

11. Q&A

12. Key takeaways

• The myth is an APB2 memory. "APB has no error reporting" was true for the apb2-baseline and false from APB3 onward, which added PSLVERR (AMBA IHI 0024C §2.1). Date your knowledge to the version and the myth dissolves.
• PSLVERR is a real, spec-defined error verdict. The slave asserts it high with PREADY on the completing edge for a bad address, protection violation, or peripheral fault — a flag, not an abort, so the transfer still completes and the write side effect is suppressed.
• The bridge makes the report reach the CPU. It samples PSLVERR and translates it into the upstream fabric's error response — AHB HRESP=ERROR, AXI RRESP=SLVERR on a read, BRESP=SLVERR on a write — because there is no PSLVERR wire upstream (error-propagation).
• The real bug is an ignored PSLVERR, not a missing channel. A bridge that hardwires HRESP=OKAY, or a manager that never consumes the response, recreates error-blind APB2 behaviour in an APB3 system — a silent failure caused by a dropped report, not by the protocol.
• Verify end to end. Prove the slave stamps and aligns PSLVERR, prove the bridge maps it and never fabricates one, and cover read vs write, wait-count, and error source — so a genuine fault is shown to reach the CPU, not just to toggle PSLVERR on the APB side.