AHB-Lite

In short: AHB-Lite is the single-master subset of AMBA AHB that keeps high-bandwidth pipelined bursts and the HREADY/HTRANS handshake while dropping arbitration and retry/split responses, making it the practical, low-overhead on-chip backbone that stitches a CPU to memory and high-speed peripherals in almost every modern SoC.

If you have ever traced a boot sequence on a Cortex-M microcontroller or opened a block diagram of a mid-range SoC, you have already met AHB-Lite even if you did not see the name. It is the bus that carries instruction fetches and data loads from the processor to on-chip SRAM, flash, and the high-throughput slaves, before a bridge hands quieter traffic down to APB. Understanding it well is one of the fastest ways to sound credible in a VLSI or SoC-integration interview, because the protocol is small enough to hold in your head yet rich enough to expose how pipelining, wait states, and address decoding really work.

Why AHB needed a "Lite" version

The full AMBA 2/3 AHB specification supports multiple masters. That means it carries machinery most designs never use: an arbiter that grants the bus, HBUSREQ/HGRANT signals, and two-cycle SPLIT and RETRY responses that let a slow slave release the bus and ask the arbiter to re-run a transfer later. All of that adds gates, verification states, and latency corner cases.

In reality a huge fraction of SoC subsystems have exactly one master on a given bus segment — the CPU, or a single DMA engine. ARM's answer was AHB-Lite: strip out arbitration, SPLIT and RETRY, and keep only what a single master needs. The result is simpler to design, far simpler to verify, and loses nothing on the critical path. When a design later needs several masters, you place an AHB-Lite-to-multilayer interconnect (or a bus matrix) in front of the slaves rather than burdening every slave with multi-master logic.

⚡ AHB-Lite assumes exactly one master. There is no arbiter and no bus request. Every slave must still drive HREADY and HRESP, but the only legal error response is the two-cycle ERROR — SPLIT and RETRY are gone.

The pipeline: address phase and data phase

The single most important idea in AHB-Lite is that it is pipelined: the address phase of one transfer overlaps the data phase of the previous one. In cycle N the master drives the address and control signals (HADDR, HWRITE, HSIZE, HBURST, HTRANS); in cycle N+1 that transfer's data moves on HWDATA (write) or HRDATA (read), while the master simultaneously issues the next address. This overlap is what gives AHB its throughput: back-to-back with zero wait states, a slave can accept one 32-bit word every clock, so a 100 MHz AHB bus delivers 400 MB/s of sustained bandwidth.

HTRANS: telling the slave what kind of transfer this is

Because the bus is always clocked, the master must announce whether the current address phase carries a real transfer or just idle cycles. That is the job of the 2-bit HTRANS field:

A typical INCR4 read burst therefore looks like one NONSEQ followed by three SEQ transfers, with the slave free to insert BUSY beats if, say, a FIFO it is draining momentarily backs up.

HREADY: the handshake that makes wait states possible

Real slaves are not always ready in one cycle. Flash wants wait states; an SRAM behind a clock-domain crossing may need a couple. AHB-Lite handles this with a single signal, HREADY. The slave holds HREADY low to extend the current data phase; when it finally drives HREADY high, the transfer completes on that rising edge and the pipeline advances.

The subtlety that trips up newcomers: HREADY gates both phases. While a slave stretches a data phase, the master must keep its next address and control stable, because the address phase cannot advance until the data phase closes. This is exactly why AHB-Lite interconnects route HREADY back to the master and use HREADYOUT from each slave through the decoder/multiplexer — the selected slave's readiness, combined through the mux, becomes the master's HREADY.

? Interview tip: a slave must never wait for its own inputs before asserting the address-phase decode; wait states are legal only in the data phase via HREADY. Stalling in the address phase deadlocks the pipeline.

Bursts, address decoding, and the SoC backbone

AHB-Lite's HBURST field supports single transfers, incrementing bursts of undefined length (INCR), and fixed wrapping/incrementing bursts of 4, 8, and 16 beats (WRAP4, INCR8, etc.). Wrapping bursts matter for cache line fills: a WRAP4 fetch of a 16-byte line starting at a non-aligned word wraps within the line boundary so the critical word arrives first.

At the system level, a central address decoder watches HADDR and asserts the appropriate HSEL to exactly one slave, while a read-data multiplexer selects that slave's HRDATA and HREADYOUT. This decoder-plus-mux fabric is the AHB backbone. For multi-master systems, vendors ship a multilayer AHB interconnect where each master gets its own layer and slaves are shared through per-slave arbitration — giving you concurrency without the SPLIT/RETRY complexity. Our deeper comparison in AHB vs APB: bridging the SoC bus hierarchy shows where you hand traffic down to the low-power APB domain, and the AXI4 channel protocol explains how modern high-end SoCs move beyond AHB's single-pipeline model to independent read/write channels with outstanding transactions.

Verifying AHB-Lite in practice

In industry flows you rarely hand-check waveforms for compliance. A UVM VIP — Synopsys VC Verification IP, Cadence's AMBA VIP, or Siemens Questa VIP — drives constrained-random bursts and runs a protocol checker that flags illegal moves like an address-phase stall, a BUSY on a non-burst transfer, or an ERROR response that is not held for the required two cycles. Teams such as the design-services group at Avecas pair these VIPs with coverage on every HTRANS/HBURST/HSIZE combination so that corner cases — a WRAP16 with wait states hitting a slave boundary — are provably exercised before tape-out.

Want to design, code, and verify a real AHB-Lite slave and interconnect in SystemVerilog? CourseTron's SoC Protocols & Bus Architecture track walks you from the HREADY handshake to a full UVM testbench, with lab access and interview prep.

Frequently asked questions

Is AHB-Lite a different bus from AHB?

No — it is a protocol-compatible subset. AHB-Lite slaves plug straight into an AHB system; the difference is that AHB-Lite masters assume single ownership and never emit bus-request or respond to SPLIT/RETRY, so the surrounding logic is lighter.

Why only two HRESP values in AHB-Lite?

AHB-Lite keeps OKAY and ERROR only. SPLIT and RETRY exist to release a shared bus for other masters; with a single master there is no one to hand the bus to, so they serve no purpose and were removed.

How does AHB-Lite differ from APB?

APB is unpipelined, single-cycle-addressed, and low-bandwidth — ideal for registers on slow peripherals. AHB-Lite is pipelined and burst-capable for memory and high-speed blocks. Most SoCs use both, bridged. See our AHB vs APB article.

Can AHB-Lite support multiple masters at all?

Not directly on one segment. You add a multilayer AHB interconnect or bus matrix that presents each master its own AHB-Lite layer and arbitrates per slave, keeping the per-slave logic simple.