APB Interview Questions

Every APB transfer starts with one SETUP cycle. In it PSEL is high, PENABLE is low, and the address, direction and write data are valid. One or more ACCESS cycles follow, with PENABLE high. The transfer completes at the edge where PSEL, PENABLE and PREADY are all high. So the minimum is two cycles, and each cycle of PREADY low adds one. Afterwards the bus returns to IDLE, or goes straight to SETUP for the next transfer, with PENABLE low again.

SETUP gives the completer a full cycle with a stable address and select. Then PENABLE marks the cycle that counts. The completer can decode in SETUP and act on a single edge with very little logic. APB trades speed for that simplicity. It is not pipelined and every transfer costs at least two cycles, which is fine for occasional register traffic.

Nothing it set in SETUP: PADDR, PWRITE, PSEL, PENABLE and PPROT stay unchanged. So do PWDATA and PSTRB for a write, and any user request signals. The hold lasts from the SETUP-to-ACCESS transition until PREADY is high. The only free signal in that window is the completer's own PREADY. Any number of wait states is legal, from zero upwards.

It is not a protocol violation, because APB allows any number of wait states. "Too long" is a system property, so a protocol checker cannot call it wrong. The bench uses a watchdog instead, with a limit taken from the peripheral's documented maximum. The watchdog reports a hang when the wait reaches that limit. In formal, the same requirement is a bounded response property, or a liveness property with fairness assumptions on the completer's inputs.

A timeout is system policy, not protocol. After a programmed limit, the bridge returns SLVERR so the CPU is not stuck forever. The risk is on the APB side: the requester must hold the transfer until PREADY, so the bridge cannot legally abandon it. It either keeps that segment blocked and fails every later access, or resets the completer. Specify which, raise an interrupt, and verify that recovery path.

Every bug that keeps the wires legal can remain, because a wire checker only proves the protocol. A completer that acts in every selected cycle still obeys the handshake. So does one that returns read data one transfer late, ignores PSTRB, acts without its PSEL, or raises PSLVERR a cycle early. A register model or scoreboard that predicts data and responses catches the rest. But it needs traffic with wait states, back-to-back transfers, sparse strobes and errors.

Register traffic is rare, small and tolerant of latency, so APB's simplicity wins. It runs one transfer at a time, with no bursts and no IDs. Each peripheral needs only a tiny state machine, and there are few wires to route. One bridge pays the AXI cost once for many peripherals. The price is throughput: at least two cycles per transfer, and one slow completer stalls the whole APB segment. So blocks that move real data stay on AXI or AHB.

APB3 added wait states and errors, through PREADY and PSLVERR. APB4 added protection and sparse writes, through PPROT and PSTRB. APB5 added wake-up signalling, user signals and parity protection. The current issue also adds Realm Management Extension support as an option. An APB2 completer has neither PREADY nor PSLVERR, so a bridge ties them off for it.

Every access behind that bridge waits, because APB carries one transfer at a time and nothing starts until the waiting one completes. One fix is to give the slow peripheral its own APB segment or bridge. Another is to make it answer at once with a busy bit that software polls. A third is posted writes: the bridge answers before APB finishes, so it loses PSLVERR for those writes. Pick by the latency budget of the time-critical peripherals.

The bridge is the AXI subordinate and the APB requester. It decodes PSELx and makes one APB transfer per AXI beat. Each transfer uses the aligned address, with WSTRB on PSTRB and AxPROT on PPROT. It maps PSLVERR to SLVERR: per beat in RRESP, and merged into the single BRESP. Your decisions are read/write arbitration, DECERR for unmapped addresses, a timeout policy and posted writes. Verify it with checkers on both sides and an end-to-end scoreboard.

Decode first, and answer DECERR without starting any APB transfer, because APB itself defines no decode error. With no PSELx asserted, nobody drives PREADY. So a transfer started to a hole never completes, unless a default responder answers it. DECERR also tells software that the address was wrong. SLVERR would instead suggest that a peripheral refused it.

The bridge maps PSLVERR to SLVERR, in the RRESP of the failing beat for a read and in BRESP for a write. A write has one completion response for the whole transaction. So the bridge must merge four APB results into one BRESP. Reporting SLVERR if any beat failed is the usual choice. The remaining beats still run: AXI never shortens a burst, and every read beat is returned whatever its response.

Protocol checkers on both ports catch rule breaks. An end-to-end scoreboard predicts the APB transfers (one per beat, with address, PSTRB and PPROT) and the AXI responses. Done means every check passes and the coverage model is closed. That model crosses burst type, length and size with unaligned and narrow beats and wait states. It also covers PSLVERR on the first, middle and last beat, unmapped addresses, and reads racing writes.

Check that each refused access errors: a write to read-only, an unmapped offset, or a wrong size or protection. Check that PSLVERR is read only at completion, and that register state after a failed write matches the documented policy. Cover read and write, crossed with error or not, crossed with zero, one and many wait states. Also cover an error followed straight by a good transfer to the same completer. Then check the error reaches software through the bridge.

At the edge where the read data is taken. PRDATA needs to be valid only at the completion edge, where PSEL, PENABLE and PREADY are all high. So a sampler at the first ACCESS edge reads data that is not ready yet. Zero-wait peripherals hide the bug, because their first ACCESS edge is the completion edge. Capture only when PREADY is high too, and run every regression with wait states.

It publishes once per transfer, at the edge where PSEL, PENABLE and PREADY are all high. Only then are PRDATA and PSLVERR valid. The item carries the address, direction, PPROT, PWDATA and PSTRB, all stable since SETUP. It also carries PRDATA or the error at completion, and the wait count: the ACCESS cycles with PREADY low. Sampling through a clocking block keeps the monitor free of races with the DUT.

PSLVERR counts only in the last cycle of the transfer, where PSEL, PENABLE and PREADY are all high. Elsewhere it is ignored, and driving it low there is only a recommendation. It says the transfer failed, not what happened inside. A failed write may or may not have changed the register. A failed read may return data that the requester still uses. PSLVERR is optional; without it the requester's input is tied low.

Completers differ, and the specification keeps them cheap. Some decide the error only after part of the access has taken effect; others refuse cleanly. Forcing "no side effect on error" would add buffering to every peripheral. So the error reports failure only. The register's behaviour on error belongs in the peripheral's documentation and its register model.

Then the mirror holds a value the register may not have. The next read check fails on a correct design, or passes on a wrong one. The adapter should return UVM_NOT_OK, so the model skips predicting that access. Then read the register back to learn what the peripheral really did.