AMBA AXI · Module 10

Register Access with AXI4-Lite

A step-by-step walkthrough of a control/status-register write and read over AXI4-Lite — the single-beat write (AW+W→B) and read (AR→R) sequences, address decode to a register map, WSTRB for byte fields, and response codes.

Chapter 10.1 explained why AXI4-Lite exists; this chapter shows it in action — the concrete sequences for reading and writing a peripheral's control/status registers (CSRs). This is the bread-and-butter of the control plane: software does a memory-mapped load or store, which becomes a single-beat AXI4-Lite read or write to a register address. We'll walk the write path (AW + W → B), the read path (AR → R), how the slave decodes the address to a register, how WSTRB handles byte fields, and what the response codes mean. Everything is single-beat, in-order — the simplicity 10.1 promised, made concrete.

1. The Write Sequence (AW + W → B)

A register write uses three channels. The master presents the address on AW and the data on W; the slave accepts both (in either order, or together), performs the write, and returns a single response on B:

Master drives AWADDR (the register's address) with AWVALID; slave accepts with AWREADY.
Master drives WDATA and WSTRB with WVALID; slave accepts with WREADY.
Once both AW and W are accepted, the slave writes the register and drives BVALID with BRESP (OKAY on success); master accepts with BREADY.

It's one beat each — no WLAST needed (single beat), no burst, no ID. The B response confirms the write landed.

Figure 1 — AXI4-Lite write (AW+W→B) and read (AR→R) sequences. A write presents the address on AW and data on W (accepted in any order), then the slave returns one B response. A read presents the address on AR, then the slave returns data and a response on R. Single beat each — the core single-transaction shape of Lite.

2. The Read Sequence (AR → R)

A register read uses two channels. The master presents the address on AR; the slave decodes it, fetches the register value, and returns the data plus response on R:

Master drives ARADDR with ARVALID; slave accepts with ARREADY.
Slave returns RDATA (the register value) and RRESP (OKAY) with RVALID; master accepts with RREADY.

One address, one data beat. No RLAST distinction matters for a single beat; no burst. The read is complete when the master captures the R beat.

3. On the Wire

A write of 0xABCD to register 0x10, followed by a read back of 0x10:

lite-rw — write 0x10 = 0xABCD, then read 0x10

8 cycles

Figure 2 — lite-rw: a register write then read. The write presents AWADDR=0x10 and WDATA=0xABCD; the slave returns BRESP=OKAY. The read presents ARADDR=0x10; the slave returns RDATA=0xABCD with RRESP=OKAY — confirming the value was stored. Each is a single-beat transaction with no burst signals.

4. Address Decode and the Register Map

The slave's job is to map the address to a register. A register block exposes a register map — each register at a fixed address offset within the block's address window (e.g., 0x00 = control, 0x04 = status, 0x08 = data, …). When AWADDR/ARADDR arrives, the slave decodes it to select the target register, then reads or writes it.

Software sees this as memory-mapped I/O: a store to the register's address becomes an AXI4-Lite write; a load becomes a read. WSTRB lets software update a byte field of a register without disturbing the rest (e.g., writing one byte of a packed config register), and the slave honors the strobes byte-by-byte (Chapter 6.7). Invalid accesses get error responses: writing a read-only register or hitting a reserved offset typically returns SLVERR; an unmapped address returns DECERR (from the interconnect's default slave).

Figure 3 — address decode to a register map. The slave decodes AWADDR/ARADDR to select a register at its offset (control/status/data/…). Software's memory-mapped load/store becomes an AXI4-Lite read/write; WSTRB updates byte fields; read-only or reserved accesses return SLVERR, unmapped addresses DECERR.

5. The Software View — MMIO

From software, register access is just load and store to the peripheral's address window, which the system turns into AXI4-Lite transactions:

Figure 4 — the memory-mapped I/O flow. A software store to a register address becomes an AXI4-Lite write (AW+W→B); a load becomes a read (AR→R). The driver reads/writes register offsets; the bus carries single-beat transactions; the slave decodes and accesses the register. This is how device drivers configure and poll peripherals.

A driver typically: writes config registers to set up the peripheral, writes a "start" bit, then polls a status register (repeated reads) until a "done" bit is set — every one of those a single AXI4-Lite transaction. Because it's the control plane, latency per access is fine; what matters is correctness and simplicity.

6. Common Misconceptions

Myths to unlearn

"AW must come before W." No — on a write, AW and W are independent channels and may arrive in any order (or the same cycle). The slave waits until both are accepted before performing the write and returning B.
"The write is done when W is accepted." Not necessarily — the write is confirmed by the B response. A driver that needs the write to have landed (before a dependent read) must wait for B (the RAW rule, 9.2).
"You can't byte-write a register over Lite." You can — WSTRB is retained, so a master can update a single byte field of a register; the slave honors the strobes.
"A read-only register write is silently ignored." It should return SLVERR (or be defined behavior) — a well-designed register block reports the illegal write rather than silently dropping it.
"Register reads can be reordered for speed." AXI4-Lite is in-order with no IDs — register accesses complete in order; there's no reordering to exploit.

7. Debugging Insight

🔍 Debugging insight — register access bugs are decode, strobe, and response issues

CSR-access bugs over AXI4-Lite are usually one of a few patterns:

Write to a register has no effect? Check the B response — if it's SLVERR, the register may be read-only or the offset reserved; if DECERR, the address is unmapped (wrong base/offset, or interconnect decode). A missing or wrong address decode silently writes nothing.
A byte-field write corrupts the rest of the register? The slave isn't honoring WSTRB — it's doing a full-word write instead of byte-masked. Check the slave commits only strobed bytes (Chapter 6.7).
A dependent read returns the old register value? A RAW ordering issue — the read was issued before the write's B returned. The driver must wait for B before the dependent read (9.2).
A write hangs (no B)? The slave may be waiting for both AW and W and only one arrived (or BREADY isn't asserted). Check both write channels handshook and BREADY is driven.
Status polling never sees 'done'? Either the read address is wrong (decode) or a read/write ordering issue around the start bit — verify the addresses and that the start write completed (B) before polling.

The triage: no-effect/error → response code (SLVERR/DECERR) and decode; field corruption → WSTRB; stale read → RAW (wait for B); hang → incomplete write handshake. The B/R response codes are your first diagnostic.

8. Verification Insight

✅ Verification insight — exercise the register map, strobes, and error responses

AXI4-Lite register verification is single-transaction-focused but must cover the register map thoroughly. A register-model scoreboard checks that each write updates the addressed register (honoring WSTRB byte-by-byte) and each read returns the current value; cover every register offset, read and write. Critically, verify the access-policy behavior: writes to read-only registers return SLVERR (and don't change state); reads of write-only registers behave as specified; reserved/unmapped offsets return DECERR/SLVERR; and reset values are correct. Exercise byte-strobe writes for each field of multi-field registers, confirming only the targeted bytes change.

Coverage should include: single read and write to every register; all WSTRB patterns on writable registers; error responses for read-only/reserved/unmapped accesses; reset/default values; and back-to-back accesses confirming in-order, correct handshaking (including AW/W arriving in both orders and same-cycle). The highest-value checks are the register-map completeness (every register, every access type, correct policy) and WSTRB byte-field correctness — the two places register blocks most often have bugs. Since Lite is single-beat and in-order, none of the burst/outstanding/ordering verification applies; the effort concentrates on the register semantics.

9. Interview Questions

10. Summary

AXI4-Lite register access is the control plane made concrete. A write uses three channels — AW (address) + W (data + WSTRB) → B (response) — where AW and W arrive in any order and the B response confirms the write landed. A read uses two — AR (address) → R (data + response). Both are single-beat, in-order. The slave decodes the address against its register map (each register at an offset), software sees it as memory-mapped load/store, WSTRB enables byte-field writes, and response codes report status (OKAY; SLVERR for read-only/reserved; DECERR for unmapped).

The recurring care points carry over from the core protocol: honor WSTRB for byte fields, and respect read-after-write ordering (wait for B before a dependent read-back — the only ordering discipline a driver needs, since Lite is in-order single-beat). Bugs are decode/response (SLVERR/DECERR), strobe (field corruption), and RAW (stale read-back) issues. Verification concentrates on register-map completeness, access policy, reset values, and byte-strobe correctness — the semantics unique to register blocks. Next: a direct comparison of the two low-bandwidth control interconnects — APB vs AXI4-Lite.

11. What Comes Next

You've seen Lite register access; next, the comparison with the other control interconnect:

10.3 — APB vs AXI4-Lite (coming next) — contrasting APB and AXI4-Lite for low-bandwidth control, and when to use each.

Previous: 10.1 — Why AXI4-Lite Exists. Related: 6.7 — WSTRB Write Strobes for byte fields, 6.8 — RESP & LAST Signals for response codes, and 9.2 — Read/Write Independence for the read-after-write rule. For the broader protocol catalog, see the AMBA family overview doc.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.