Introduction to AMBA APB

📋 What is APB?

The Advanced Peripheral Bus (APB) is the simplest member of the ARM AMBA (Advanced Microcontroller Bus Architecture) family. It is a low-bandwidth, low-cost interface designed specifically for accessing the programmable control registers of peripheral devices — things like UARTs, timers, GPIO controllers, interrupt controllers, and SPI/I2C controllers.

APB is not designed for high-throughput data movement. It has no support for bursts, no pipelining, no out-of-order transactions, and no concurrent read/write capability. Every transfer takes at minimum two clock cycles. This simplicity is intentional — it makes peripherals cheap to implement, easy to verify, and power-efficient.

Every APB transfer is initiated by an APB bridge (the Requester) and answered by a peripheral (the Completer). The bridge sits between the high-performance system bus (AXI or AHB) and the collection of slow peripherals, translating fast complex transactions into simple APB register accesses.

📋 Why APB — Design Philosophy

In any SoC, the system bus (AXI or AHB) is wide, fast, and expensive to implement. Connecting every small peripheral directly to AXI would mean each peripheral needs a full AXI subordinate interface — complex handshaking, burst support, multiple outstanding transactions, and wide data buses. This is overkill for a UART that just needs a few 32-bit registers written once during initialisation.

APB solves this through the principle of appropriate interface complexity:

• Minimal power consumption — signals change only during a transfer. No continuous handshake activity between transfers.
• Reduced interface complexity — every transfer is a simple two-phase (Setup + Access) sequence. No burst capability, no interleaving, no out-of-order.
• Small gate count — an APB peripheral typically needs only a few hundred gates for its bus interface, compared to thousands for an AXI interface.
• Easy to time-close — the simple two-cycle protocol means timing closure is straightforward even at high clock frequencies.

📋 APB in the AMBA Hierarchy

AMBA defines a family of bus protocols for different bandwidth and complexity requirements. APB sits at the bottom of this hierarchy — the lowest bandwidth, lowest complexity interface — serving as the final hop from the high-performance interconnect to individual peripheral registers.

📋 The APB Bridge

The APB bridge (also called the Requester) is the central component of every APB system. It translates transactions from the system bus (AXI or AHB) into APB transfers targeting the correct peripheral. Every APB transfer must be initiated by the bridge — peripherals never initiate transactions.

The bridge performs several functions:

• Address decoding — maps system bus addresses to individual APB peripheral select signals (PSELx). Each peripheral has its own PSELx; only one is asserted at a time.
• Protocol translation — converts the source bus protocol (AXI burst, AHB single) into the two-phase APB Setup + Access sequence.
• Wait state management — monitors PREADY from the peripheral and stalls the source bus (by holding HREADY or inserting AXI response delay) until the APB transfer completes.
• Error mapping — translates PSLVERR from the peripheral back to the source bus error response (RRESP/BRESP on AXI, HRESP on AHB).

📋 Requester and Completer Model

The APB5 specification standardised the terminology used to describe the two sides of every APB transfer. Earlier versions of the specification used the terms “master” and “slave” — these are deprecated in APB4/APB5 and replaced with:

📋 APB Versions — APB2 to APB5

The APB specification has evolved through five issues, each adding features for more complex SoC requirements. All versions are backward-compatible — an APB5 Requester can drive an APB2 Completer, though the new signals have no effect on the older peripheral.

📋 Key Protocol Properties

The APB protocol has several fundamental properties that apply to every version:

Synchronous

All APB signals are sampled at the rising edge of PCLK. There are no asynchronous signals in the APB protocol (PWAKEUP must be glitch-free and synchronous to PCLK even though it is consumed in a different clock domain). This makes APB simple to implement and verify in synchronous digital design flows.

Non-pipelined

APB does not support pipelining. The address and control signals for the next transfer cannot be issued until the current transfer completes (PREADY asserted). This means APB cannot hide latency by overlapping address phases — every transfer adds its full latency to the total access time.

Minimum two cycles per transfer

Every APB transfer takes at least two clock cycles: one Setup cycle (PSEL=1, PENABLE=0) followed by at least one Access cycle (PSEL=1, PENABLE=1). If PREADY is deasserted during the Access phase, additional cycles are added. There is no minimum or maximum on the number of additional wait state cycles.

Single outstanding transfer

Only one APB transfer can be in progress at any time. The bridge must complete (or abandon) the current transfer before initiating a new one. This eliminates the need for transaction IDs or out-of-order completion logic in peripherals.

No concurrent read/write

The read data bus (PRDATA) and write data bus (PWDATA) are separate, but they cannot be used simultaneously because there is only one address bus and one direction signal (PWRITE). A read and a write cannot occur in the same clock cycle to the same or different peripherals.

📋 Quick Reference