AMBA AHB · Module 16

Register Bank Slave

Extending the simple AHB-Lite slave into a parameterised register bank — the same capture-then-act structure, but the registers are an indexed array (by addr_q): a write decoder selects which register receives HWDATA (if writable), a read mux selects the indexed register onto HRDATA. Each register has access attributes (RW / RO / write-1-to-clear / read-to-clear / reserved-reads-0). Read-to-clear especially needs the qualified select. The workhorse peripheral interface, typically generated from a register map.

Chapter 16.1 built a slave with a few fixed registers; this chapter generalizes it into a parameterised register bank — a configurable array of registers, the workhorse interface of nearly every peripheral. The structure keeps the same capture-then-act backbone (16.1): capture the address-phase context (sel_q, write_q, the register index from addr_q), then act in the data phase. But now the registers are an indexed array: a write decoder uses the index to select which register receives HWDATA (and only registers that are writable accept it), and a read mux uses the index to select the addressed register onto HRDATA. The key new dimension is per-register access attributes: registers aren't all plain read-write — some are read-only (RO, e.g. STATUS — ignore writes), some have write-one-to-clear (W1C, e.g. interrupt flags — hardware sets, software clears by writing 1), some are read-to-clear (RC — clears on read), and reserved indices read as 0 (and ignore writes). The bank is parameterised by register count and width. A subtle point: read-to-clear registers especially need the qualified select (chapter 16.1) — so an idle cycle doesn't spuriously clear them. This chapter builds the parameterised register bank with its per-register access rules.

1. What Is It?

A register bank slave is a parameterised AHB-Lite slave whose storage is an indexed array of registers with per-register access attributes. Its parts:

Same capture-then-act — capture the address-phase context (sel_q, write_q, the register index from addr_q), act in the data phase (16.1's structure).
Indexed array — the registers are a parameterised array (count, width); the index selects one.
Write decoder — the index selects which register receives HWDATA (only writable registers accept it).
Read mux — the index selects the addressed register onto HRDATA.
Per-register attributes — RW / RO / W1C / RC / reserved-reads-0 govern each register's behavior.

Figure 1 — a register-bank slave: an indexed array + decoder + mux. The captured address bits form the register index. On a write, a decoder selects which register in the array receives HWDATA (only if writable). On a read, a mux selects the indexed register onto HRDATA. Per-register attributes govern behavior: reg[0] RW, reg[1] RO (read-only), reg[2] W1C bits, reg[3] RW, reserved → reads 0. Same capture-then-act; the registers are a parameterised array with per-register access rules.

So a register bank slave is the simple slave (16.1) scaled and parameterised: the structure (capture-then-act, qualified select, registered context) is identical, but the storage becomes a configurable indexed array, and each register gains access attributes (it's not all plain RW). The write path becomes a decoder (index → which writable register), the read path a mux (index → which register's value). The attributes are where the peripheral semantics live — RO status, W1C flags, RC registers, reserved holes. The bank is parameterised (register count, data width) so it's reusable across peripherals. So a register bank slave is the standard parameterised register-array interface — the simple slave generalized with per-register access rules. So it's the workhorse peripheral interface.

Register bank = simple slave + indexed array (write decoder, read mux) + per-register attributes (RW/RO/W1C/RC/reserved); parameterised

A register bank slave in one frame: the simple slave (16.1) generalized — the same capture-then-act structure (capture sel_q, write_q, the register index from addr_q; act in the data phase), but the registers are a parameterised indexed array. A write decoder selects which register receives HWDATA (only if writable); a read mux selects the indexed register onto HRDATA. The key addition is per-register access attributes: RW (plain read-write), RO (read-only — ignore writes, e.g. STATUS), W1C (write-one-to-clear — HW sets, SW clears by writing 1, e.g. interrupt flags), RC (read-to-clear — clears on read), and reserved (reads 0, ignores writes). The bank is parameterised (count, width) for reuse. A subtlety: read-to-clear registers especially need the qualified select — so an idle cycle doesn't spuriously clear them.

2. Why Does It Exist?

The register bank slave exists because peripherals are controlled through registers — and they need many registers with varied semantics (control, status, flags, data), so a parameterised array with per-register attributes is the standard, reusable way to build that interface.

The register-based peripheral control is the root: a peripheral (UART, timer, GPIO, etc.) is controlled by software writing/reading its registers — a control register to configure it, a status register to read its state, data registers to send/receive, flag registers for interrupts. So every peripheral needs a register interface — a set of registers the CPU accesses over the bus. So the register bank slave exists to provide that interface. So it's the peripheral's control surface. So registers are how peripherals are controlled.

The many registers, varied semantics drives the array + attributes: a peripheral has many registers (often dozens), and they have different semantics — control (RW — software sets), status (RO — hardware-driven, software reads), interrupt flags (W1C — hardware sets, software clears), FIFOs (RC or special), reserved (holes). So a single uniform "register" isn't enough — you need an array (for the many) with per-register attributes (for the varied semantics). So the bank exists as an indexed array with attributes to handle the many, varied registers. So it's array + attributes. So peripherals need this structure.

The parameterised reusability is why it's parameterised: every peripheral needs a register bank, with different counts, widths, and attributes. So building a parameterised register bank (configurable count/width/attributes) means the same RTL is reused across peripherals — you instantiate and configure it, rather than writing each from scratch. So the bank is parameterised for reuse (a register-bank generator is common). So it's reusable IP. So the register bank slave exists because: peripherals are controlled through registers (the why); they need many registers with varied semantics — control/status/flags/data (driving the indexed array with per-register attributes); and a parameterised bank is reusable across peripherals (the generalization). So the register bank slave is the standard, parameterised, reusable register-array interface that every peripheral uses — the simple slave generalized to the real peripheral need. So this chapter builds the workhorse interface. (The per-register attributes are where the peripheral's specific behavior lives, often generated from a register-map description — chapter 11.4 / IP-XACT/SystemRDL.)

3. Mental Model

Model the register bank as a wall of labeled mailboxes with different rules per box — most are normal boxes you can put mail in and take mail out (RW); some are "outgoing only" display boxes showing a notice you can read but not change (RO status); some are alarm boxes that light up when triggered and you reset by flipping their switch (W1C flags); some dispense a ticket that's consumed when you take it (RC); and some slots are just blanks in the wall (reserved — nothing there).

A wall of labeled mailboxes (the register array), each at a numbered slot (the index). You access them with a slot number (the captured address index). But the boxes have different rules. Most are normal mailboxes — you can put mail in (write) and take mail out (read), and what you put is what you get (RW registers). Some are "display only" boxes — they show a notice posted by the building (the hardware), which you can read but can't change — trying to "mail" something to them does nothing (RO status registers — ignore writes, read the hardware value). Some are alarm boxes that light up when an event triggers them (hardware sets the flag), and you reset the alarm by flipping its switch — specifically by writing a "1" to acknowledge it (W1C interrupt flags — hardware sets, software clears by writing 1). Some dispense a ticket that's consumed the moment you take it — reading it removes it (RC read-to-clear — clears on read, so you must be careful not to "peek" accidentally, which is why the qualified select matters — an idle glance shouldn't consume the ticket). And some slots are just blanks in the wall — nothing there (reserved — reads 0, ignores writes). So the wall is an array of slots with per-slot rules — and you access each by its number, respecting its rule.

This captures the register bank: the wall of numbered mailboxes = the indexed register array; the slot number = the captured address index (addr_q); normal put-in/take-out boxes = RW registers; display-only notice boxes = RO status (ignore writes); alarm boxes reset by flipping the switch = W1C flags (write 1 to clear); tickets consumed when taken = RC read-to-clear (clears on read); being careful not to peek-consume = qualifying the read so an idle cycle doesn't clear it; blank slots = reserved (reads 0). An array of slots with per-slot rules, accessed by number.

Watch a write to a RW register and a write-1-to-clear of a flag:

RW write, then W1C clear of a flag

4 cycles

Figure 2 — a write to a RW register, then a W1C clear of a flag. Cycle 0: write address phase, index = reg[0] (RW). Cycle 1: data phase — HWDATA=D written to reg[0] (it's writable); meanwhile, write address phase to reg[2] (W1C flags). Cycle 2: data phase — HWDATA=0x1 to reg[2] clears bit 0 of the flag (write-1-to-clear: the written 1 clears the set bit). The 'reg[2]' row shows the flag bit going from 1 (set by HW) to 0 (cleared by the W1C write). Per-register attributes govern each access.

The model's lesson: an array of slots with per-slot rules, accessed by number. In the waveform, the RW register stores the write, and the W1C flag is cleared by writing a 1 — each register obeys its own attribute.

4. Real Hardware Perspective

In hardware, the register bank is a parameterised array of register flops, a write decoder (generating per-register write-enables, respecting writability), a read mux (selecting by index), and per-register attribute logic — often generated from a register-map description.

The parameterised array: the registers are declared as a parameterised array (e.g. reg [WIDTH-1:0] regs [0:COUNT-1], with WIDTH and COUNT as parameters). So the same RTL handles any count/width by setting the parameters. So in hardware, the storage is a parameterised array of flops. So it scales by parameter.

Figure 3 — per-register access attributes. RW (read-write): stores writes, returns on read — a plain register. RO (read-only): ignores writes, reads the hardware value (e.g. STATUS). W1C (write-1-to-clear): hardware sets, writing a 1 clears the bit (e.g. interrupt flags). RC (read-to-clear): clears itself when read — beware spurious reads, so qualify reads carefully (HSEL && a real HTRANS). Reserved/unmapped: reads as 0, ignores writes (or returns ERROR in a robust bank).

The write decoder and read mux: the write path is a decoder — in the data phase, if (sel_q && write_q), the index (addr_q) is decoded to a per-register write-enable: we[i] = (addr_q == i) && (register i is writable). Each register flop updates if (we[i]) regs[i] <= HWDATA (or, for W1C, the appropriate clear logic). The read path is a mux — HRDATA = regs[addr_q] (or the attribute-specific read value, e.g. 0 for reserved). So in hardware, the write is a decoder generating write-enables, the read a mux on the index. So those are the paths.

The per-register attribute logic: each register's attribute shapes its logic. RW: plain — write-enable updates it, read returns it. RO: no write-enable (writes ignored); read returns the hardware-driven value (not a stored flop). W1C: hardware sets bits; a write with a 1 in a bit position clears that bit (if (we && HWDATA[b]) regs[i][b] <= 0); hardware-set otherwise. RC: cleared on read (the read access, qualified, triggers a clear — must qualify so an idle cycle doesn't clear it). Reserved: read returns 0, no write-enable. So in hardware, each register's logic implements its attribute. So the attributes are RTL behaviors. So in hardware, the register bank is a parameterised flop array + a write decoder (per-register write-enables, respecting writability) + a read mux (by index) + per-register attribute logic (RW/RO/W1C/RC/reserved). Crucially, this is often generated — from a register-map description (IP-XACT, SystemRDL — chapter 11.4), a generator produces the bank RTL (with the right count/width/attributes) and the software headers, ensuring consistency. So in hardware, register banks are typically generated (not hand-written) for consistency and productivity. So the hardware reality: a parameterised, often-generated array with per-register attribute logic. So building one is configuring/generating the standard structure.

5. System Architecture Perspective

At the system level, the register bank is the standard control/status interface between software and hardware — and its per-register attributes and single-source generation (from a register map) are what make the hardware/software interface consistent and maintainable.

The software/hardware control interface: the register bank is the interface through which software controls and observes hardware. Software writes control registers to configure a peripheral, reads status registers to observe it, writes W1C flags to acknowledge interrupts, reads/writes data registers to transfer. So the register bank is the contract between the software (driver) and the hardware (peripheral). So at the system level, the register bank is the control/status interface — the boundary where software meets hardware. So it's the driver's view of the peripheral. So registers are the SW/HW boundary.

The attributes encode the contract: the per-register attributes (RW/RO/W1C/RC/reserved) encode the semantics of that contract — what each register means and how it behaves. RW = software-controllable setting; RO = hardware-reported status; W1C = interrupt acknowledge; RC = consume-on-read; reserved = don't-touch. So the attributes are the semantic specification of the interface — they tell the software how to use each register. So at the system level, the attributes are the documented behavior of the control interface. So they define the contract's semantics. So the attributes are the interface spec.

The single-source generation: because the register bank is the SW/HW contract, consistency between the hardware (the bank RTL) and the software (the driver's register definitions) is critical (chapter 11.4) — a mismatch (wrong attribute, wrong address) is a bug. So register banks are typically generated from a single register-map description (IP-XACT, SystemRDL): the generator produces the bank RTL (correct attributes/addresses), the software headers (matching addresses/fields), and the documentation — all from one source, guaranteeing consistency. So at the system level, the register bank (and its software interface) is generated from a single source for consistency and maintainability — a key SoC-design discipline. So at the system level, the register bank is the standard control/status interface between software and hardware (the SW/HW contract — the driver's view of the peripheral), its per-register attributes encode the semantic specification of that contract (RW/RO/W1C/RC/reserved — how to use each register), and it's typically generated from a single register-map source (consistency between RTL, headers, docs — chapter 11.4). So the register bank is where the bus's slave RTL meets the software interface — the most consequential slave type, because it's the control surface of every peripheral, and its correctness (attributes, addresses, generation) is foundational to a working, maintainable SoC. So it's the workhorse, generated, contract-defining interface. So get the register map right and generate from it.

6. Engineering Tradeoffs

The register bank embodies the indexed-array, per-register-attribute, parameterised-generated design.

Parameterised array vs fixed registers. A parameterised array (configurable count/width) is reusable across peripherals at the cost of the parameterization; fixed registers (16.1) are simpler but not reusable. Parameterise for reuse.
Per-register attributes vs uniform RW. Per-register attributes (RO/W1C/RC/reserved) match the peripheral's real semantics at the cost of attribute logic; treating all as RW is simpler but wrong (e.g. a status register isn't writable). Implement the attributes.
Generated vs hand-written. Generating the bank (and headers) from a register-map description guarantees HW/SW consistency at the cost of the generation tooling; hand-writing risks mismatch bugs. Generate from a single source.
Qualify reads (for RC) vs not. Qualifying reads (HSEL && real HTRANS) prevents read-to-clear registers being spuriously cleared by idle cycles (correct) at the cost of the qualification; not qualifying corrupts RC registers. Always qualify (especially for RC).

The throughline: a register bank slave generalizes the simple slave (16.1) into a parameterised indexed array of registers — the same capture-then-act structure (capture sel_q, write_q, the index from addr_q; act in the data phase), with a write decoder (index → which writable register receives HWDATA) and a read mux (index → the addressed register onto HRDATA). Each register has per-register access attributes — RW / RO / W1C / RC / reserved-reads-0 — encoding the peripheral's semantics. The bank is parameterised (count, width) and typically generated from a single register-map source (HW/SW consistency, chapter 11.4). Read-to-clear registers especially need the qualified select (so idle cycles don't spuriously clear them). It's the standard control/status interface — the SW/HW contract of every peripheral.

Read-to-clear (and side-effecting) registers MUST use the qualified select — an unqualified read on an IDLE cycle would spuriously clear/trigger them

A correctness rule that's especially critical for register banks: registers with read side effects — read-to-clear (RC), or reads that pop a FIFO, advance a pointer, or trigger an action — must use the qualified select (sel_q = HSEL && (real HTRANS)); an unqualified read (triggering on HSEL alone) would spuriously clear/trigger them on IDLE/BUSY cycles, corrupting state. This is the slave-design qualification rule (chapter 16.1 / 12.6) at its most consequential. Recall that HSEL can be high during IDLE/BUSY transfers (the master drives HADDR, which may decode to this slave's region, even on non-transfers). For a plain RW or RO register, an unqualified read on an IDLE is mostly harmless (it reads a value nobody uses — wasteful but not corrupting). But for a register with a read side effect, an unqualified read on an IDLE is destructive: a read-to-clear register would clear (losing the flag/data that was there); a FIFO read would pop (consuming/losing an entry); a read-to-acknowledge would acknowledge (clearing an interrupt that wasn't handled). So an unqualified read of a side-effecting register spuriously triggers the side effect on every IDLE cycle where HSEL happens to be high — corrupting the peripheral's state (lost flags, popped FIFO entries, cleared interrupts) without any real software read. The symptom is nasty: the peripheral loses status/data intermittently (whenever an IDLE coincides with HSEL high) — a subtle bug that passes simple directed tests (which often have no IDLEs) but fails under realistic traffic (IDLEs between transactions). The fix is the qualified select: the side effect (the clear, the pop, the acknowledge) triggers only when sel_q = HSEL && (HTRANS == NONSEQ || HTRANS == SEQ) — a real read transfer — never on an IDLE/BUSY. So always qualify reads of side-effecting registers (RC, FIFO, read-acknowledge) — the read side effect must fire only on a real read, not a spurious idle-cycle selection. (Plain RW/RO registers should also qualify, but the consequence there is only a wasted read, not corruption — so the rule is most critical for side-effecting registers.) This is a classic register-bank bug: forgetting to qualify a read-to-clear register's clear, then debugging mysterious lost interrupts/data under load. Always qualify side effects.

7. Industry Example

Build a register bank for a UART peripheral.

A UART has registers: CTRL (RW), STATUS (RO), TXDATA (W), RXDATA (RC — read pops the RX FIFO), IRQFLAGS (W1C), and reserved holes.

The indexed array. The registers are an indexed array (by addr_q, the captured address bits). CTRL at index 0, STATUS at 1, TXDATA at 2, RXDATA at 3, IRQFLAGS at 4, reserved elsewhere.
CTRL (RW). Writing CTRL configures the UART (baud, parity, enables) — a plain RW register: write-enable updates it, read returns it.
STATUS (RO). STATUS reflects hardware state (TX empty, RX full, busy) — read-only: it has no write-enable (writes ignored), and reads return the hardware-driven value (not a stored flop). A write to STATUS does nothing (a robust bank might ERROR — chapter 16.6).
RXDATA (RC, FIFO pop). Reading RXDATA returns the next received byte and pops the RX FIFO (a read side effect). Crucially, this pop is qualified: it triggers only on sel_q = HSEL && real HTRANS (a real read). If it triggered on HSEL alone, an IDLE cycle (with HSEL high) would spuriously pop the FIFO — losing received data. The qualification prevents this.
IRQFLAGS (W1C). IRQFLAGS bits are set by hardware (on interrupt events). Software clears a flag by writing a 1 to it (write-1-to-clear): if (we && HWDATA[b]) IRQFLAGS[b] <= 0 (and hardware-set otherwise). So writing 0x04 to IRQFLAGS clears bit 2.
Reserved. Accessing a reserved index reads 0 and ignores writes (or ERRORs in a robust bank).
Generated from a register map. The whole bank is generated from the UART's register-map description (SystemRDL/IP-XACT) — producing the bank RTL (with the right attributes), the software header (matching addresses/fields), and the docs — all consistent.

The example shows the register bank in action: an indexed array with per-register attributes (CTRL RW, STATUS RO, RXDATA RC with a qualified pop, IRQFLAGS W1C, reserved), built on the simple slave's capture-then-act, parameterised and generated from a single source. The qualified read protecting RXDATA's FIFO-pop is the critical detail. This is how a peripheral's register interface is built. This is the workhorse slave.

8. Common Mistakes

"All registers are plain read-write." No — registers have attributes: RO (status — ignore writes), W1C (flags — write 1 to clear), RC (read-to-clear), reserved (reads 0). Implement each.
"A read-to-clear register can use HSEL alone." No — it must use the qualified select (HSEL && real HTRANS), or an idle cycle spuriously clears it. Critical for side-effecting registers.
"Writing a status (RO) register sets it." No — RO registers ignore writes; reads return the hardware value. (A robust bank might ERROR on the write.)
"W1C clears by writing 0." No — write-1-to-clear: writing a 1 to a bit clears it; writing 0 leaves it. (Hardware sets the bit.)
"Build each peripheral's bank by hand." Usually generated from a register-map description (single source → consistent RTL + headers + docs). Hand-writing risks HW/SW mismatch.
"Reserved registers can be anything." They should read 0 and ignore writes (a defined, safe behavior) — not random. (Or ERROR.)

9. Interview Insight

Register bank design is a practical RTL interview topic — the indexed-array structure, the per-register attributes, and the qualify-reads-for-RC point are the signals.

Figure 4 — a strong answer in one card: same capture-then-act, but the registers are a parameterised array indexed by addr_q; a write decoder selects which (writable) register gets HWDATA, a read mux selects the indexed register onto HRDATA; per-register attributes — RW / RO / W1C / RC (qualify reads!) / reserved → 0. The senior point: same capture-then-act, an indexed register array with per-register access attributes, parameterised.

The answer that lands gives the structure and the attributes: "A register bank slave is the simple slave generalized into a parameterised array of registers, indexed by the captured address bits. It keeps the same capture-then-act structure — capture the qualified select, the write flag, and the register index in the address phase, then act in the data phase — but now the write path is a decoder, generating a per-register write-enable from the index, and the read path is a mux selecting the indexed register onto HRDATA. The key thing is that registers have per-register access attributes, not all plain read-write. A read-write register stores writes and returns them. A read-only register, like a status register, ignores writes and returns the hardware-driven value. A write-one-to-clear register, like interrupt flags, is set by hardware and cleared when software writes a 1 to the bit. A read-to-clear register clears itself when read. And reserved indices read as 0 and ignore writes. The bank is parameterised by register count and width for reuse, and it's usually generated from a register-map description like SystemRDL or IP-XACT, which produces the RTL, the software headers, and the docs from one source, keeping hardware and software consistent. One critical detail: registers with read side effects — read-to-clear, or reads that pop a FIFO — must use the qualified select, HSEL AND a real HTRANS, because if you triggered the side effect on HSEL alone, an idle cycle with HSEL high would spuriously clear or pop them, corrupting state. That's a classic bug — mysterious lost interrupts or data under load." The indexed-array structure, the per-register attributes, and the qualify-reads-for-RC point are the senior signals.

🔍 The discriminator: per-register attributes (RW/RO/W1C/RC) — and read-to-clear/side-effecting registers MUST use the qualified select (else idle cycles corrupt them)

The discriminator on register banks is whether you handle per-register attributes (not all RW) — and specifically that read-to-clear/side-effecting registers must use the qualified select. A weak answer says "a bank is an array of registers." A solid answer adds the indexed array with a write decoder and read mux (the simple slave generalized). But the senior answer details the per-register attributes — RW (plain), RO (status — ignore writes, read hardware value), W1C (flags — hardware sets, write 1 clears), RC (read-to-clear), reserved (reads 0) — recognizing that treating all registers as plain RW is wrong (a status register isn't writable; a W1C flag clears specially). The standout senior detail: registers with read side effects (RC, FIFO-pop, read-acknowledge) must use the qualified select (HSEL && real HTRANS) — because an unqualified read (triggering on HSEL alone) would spuriously fire the side effect on IDLE/BUSY cycles (where HSEL can be high), corrupting state (clearing flags, popping FIFO entries, acknowledging interrupts that weren't handled) — a classic bug that passes simple tests (no IDLEs) but fails under realistic traffic (mysterious lost data/interrupts). For plain RW/RO, an unqualified read is only wasteful; for side-effecting registers, it's destructive — so the rule is most critical there. The framing that impresses: the register bank is the SW/HW control contract (the driver's view of the peripheral), the attributes encode the contract's semantics, and it's typically generated from a single register-map source (SystemRDL/IP-XACT → consistent RTL + headers + docs, chapter 11.4) for HW/SW consistency. A candidate who details the per-register attributes, insists side-effecting reads use the qualified select, and frames it as a generated SW/HW contract demonstrates real peripheral-RTL experience — not just "an array of registers".

10. Practice Challenge

Build and reason from the register bank.

The structure. Describe the register bank: indexed array, write decoder, read mux, on the simple slave's capture-then-act.
Attributes. Describe the per-register attributes (RW/RO/W1C/RC/reserved) and a register example of each.
Read the waveform. From Figure 2, explain the RW write and the W1C clear.
Qualify for RC. Explain why read-to-clear registers must use the qualified select and the bug otherwise.
Generation. Explain why register banks are generated from a register-map description.

11. Key Takeaways

A register bank slave generalizes the simple slave into a parameterised indexed array of registers — same capture-then-act, but a write decoder (index → which writable register gets HWDATA) and a read mux (index → the addressed register onto HRDATA).
Per-register access attributes encode the peripheral's semantics: RW (plain), RO (status — ignore writes, read HW value), W1C (flags — HW sets, write 1 clears), RC (read-to-clear), reserved (reads 0).
Read-to-clear / side-effecting registers MUST use the qualified select — an unqualified read spuriously clears/pops them on IDLE cycles (corrupting state — lost flags/data). Critical bug to avoid.
It's parameterised (count, width) for reuse across peripherals — and typically generated from a single register-map source (SystemRDL/IP-XACT → consistent RTL + headers + docs, chapter 11.4).
It's the SW/HW control contract — the standard control/status interface, the driver's view of every peripheral; the attributes are the interface's semantic spec.
Reserved registers read 0 and ignore writes (a defined, safe behavior) — not random (or ERROR in a robust bank).

12. What Comes Next

You now can build a parameterised register bank. The next chapter adds wait states for larger/slower storage:

Memory Slave (next) — an AHB SRAM/memory slave with wait states.
HREADYOUT Generation, HRDATA Muxing, HRESP Generation, and the rest — the richer slave RTL.

To revisit the simple slave this extends, see A Simple AHB-Lite Slave; for the register map driving generation, see The Address Map.