AMBA AHB · Module 16

Reusable AHB RTL Templates

Packaging the whole module into a small library of drop-in, parameterised AHB RTL building blocks — a HREADY-gated capture block, output blocks (HREADYOUT generation, HRDATA muxing, HRESP generation), leaf slaves (simple slave, register bank, memory slave), and a bridge skeleton control FSM. A new slave is assembled by instantiating and parameterising these verified blocks (WIDTH, DEPTH, ATTRS, WAITS, registered-read) rather than re-deriving the subtle pipeline and wait-state logic each time — fewer bugs, faster, consistent, often generated from a single register-map description.

This module built a slave piece by piece — capture (16.7), HREADYOUT (16.4), HRDATA muxing (16.5), HRESP (16.6), the write/read FSMs (16.8/16.9), and the bridge (16.10), across the simple/register/memory slaves (16.1–16.3). This final chapter does the engineering move that makes all of it pay off repeatedly: package the blocks into a small library of drop-in, parameterised RTL templates. The realization is that every slave you'll ever build is the same blocks, composed. At the base is a capture block (the HREADY-gated address/control register — 16.7). On it sit the output blocks — HREADYOUT generation (16.4), HRDATA muxing (16.5), HRESP generation (16.6). Combining these gives the leaf slaves — a simple register slave (16.1), a parameterised register bank (16.2), a memory slave (16.3). And a bridge skeleton (16.10) sequences the same blocks across cycles. The value: the subtle, correctness-critical logic — the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR — is written and verified once, inside the templates; a new slave is assembled by instantiating and parameterising (WIDTH, DEPTH, ATTRS, WAITS, registered-read), not re-deriving the tricky logic. This chapter shows how to turn slave design from bespoke RTL into composition of trusted building blocks.

1. What Is It?

Reusable AHB RTL templates are a parameterised library of slave building blocks that compose into any slave by instantiation and configuration. Its parts:

Capture block — the HREADY-gated address/control register (16.7) producing sel_q, write_q, addr_q, size_q — the foundation every slave instantiates.
Output blocks — HREADYOUT generation (16.4), HRDATA muxing (16.5), HRESP generation (16.6) — the slave's standard outputs.
Leaf slaves — simple slave (16.1), register bank (16.2), memory slave (16.3) — built from capture + output blocks, parameterised.
Bridge skeleton — a control FSM (16.10) sequencing the blocks across cycles for a multi-cycle downstream resource.

Figure 1 — a library of reusable AHB RTL building blocks. At the base, a CAPTURE block registers the address-phase control (HREADY-gated). The output blocks — HREADYOUT generation, HRDATA muxing, HRESP generation — sit on it. The leaf slaves (simple slave, register bank, memory slave) are built from capture + output blocks, parameterised. A bridge skeleton is a control FSM that sequences the same blocks across multiple cycles. A new slave is assembled by instantiating and parameterising these verified blocks — not re-deriving the subtle pipeline/wait-state logic each time. Leaf slaves and the bridge all sit on the shared capture + output blocks; parameters (width, depth, attributes, wait cycles) configure each.

So reusable AHB RTL templates are the productization of the module — the recognition that slave design is composition, not re-derivation. Every slave shares the same skeleton: capture the address-phase control (the HREADY-gated register), act in the data phase (write commit / read production, gated to completion), pace with HREADYOUT, respond with HRESP. The differences between slaves are parameters — how many registers (a bank), how big the memory, which access attributes, how many wait states, whether the read is registered — not fundamentally different logic. So the engineering move is to write the skeleton once, parameterised, verify it thoroughly, and instantiate it for each slave. The subtle parts — the HREADY-gated capture (16.7), the completion-gated commit (16.8/16.9), the two-cycle ERROR (16.6), the data-phase-aligned mux (16.5) — the parts that are error-prone when hand-coded — live inside the verified templates, so they're never re-derived. So reusable templates turn slave design from bespoke, bug-prone RTL into configuration of trusted blocks. So it's the module's payoff. So slaves become composition.

Reusable templates = a parameterised library (capture block + HREADYOUT/HRDATA/HRESP output blocks + leaf slaves + bridge skeleton); assemble a new slave by INSTANTIATING + PARAMETERISING verified blocks (WIDTH/DEPTH/ATTRS/WAITS), not re-deriving the subtle pipeline/wait-state logic

Reusable AHB RTL templates in one frame: the whole module factors into a small library of drop-in, parameterised RTL building blocks that compose into any slave. At the base: a capture block (the HREADY-gated address/control register — 16.7) producing sel_q/write_q/addr_q/size_q. The output blocks: HREADYOUT generation (16.4), HRDATA muxing (16.5), HRESP generation (16.6). The leaf slaves — simple slave (16.1), parameterised register bank (16.2), memory slave (16.3) — are built from capture + output blocks. A bridge skeleton (16.10) is a control FSM that sequences the same blocks across cycles. A new slave is assembled by instantiating and parameterising — WIDTH, DEPTH/register count, per-register ATTRS, WAITS, registered-read — not by re-deriving the subtle, correctness-critical logic (the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR, the data-phase-aligned mux). That tricky logic is written and verified once, inside the templates. The benefits: fewer bugs (the error-prone logic isn't re-derived), faster development (instantiate, don't write), and consistency across the SoC's slaves. Often the parameters and register map come from a single machine-readable description (SystemRDL/IP-XACT — chapter 11.4) that generates the instances. So slave design becomes composition of trusted, parameterised blocks.

2. Why Does It Exist?

Reusable templates exist because every slave shares the same error-prone skeleton, so re-deriving it per slave is wasteful and bug-prone — factoring it into verified, parameterised blocks gives fewer bugs, faster development, and SoC-wide consistency.

The every slave is the same skeleton is the root: across 16.1–16.10, every slave did the same things — capture the address-phase control (16.7), act in the data phase gated to completion (16.8/16.9), pace with HREADYOUT (16.4), return read data (16.5), respond with HRESP (16.6). The differences were parameters (register count, memory size, attributes, waits), not different logic. So there's a common skeleton underlying all slaves. So re-writing it each time is redundant. So a template exists to capture the common skeleton once. So it's de-duplication. So the commonality invites factoring.

The the subtle logic is error-prone drives the verify-once value: the slave skeleton has several subtle, correctness-critical points — the HREADY-gated capture (a free-running capture corrupts waited transfers — 16.7), the completion-gated commit (omitting HREADYOUT corrupts side-effecting writes/reads — 16.8/16.9), the two-cycle ERROR (a one-cycle error breaks the pipeline — 16.6), the data-phase-aligned mux (the wrong select returns wrong-slave data — 16.5). These are exactly the points hand-coded slaves get wrong, and the bugs hide in simple tests. So writing the skeleton once, verifying it thoroughly, and reusing it means those subtle points are never re-derived (and re-bugged). So the template exists to capture correctness once. So it's bug-reduction. So verify-once is the value.

The consistency and productivity is the system benefit: with a template library, all the SoC's slaves are built the same way — consistent behavior (the same wait-state handling, error responses, capture timing), easier to review/verify (one block to trust), and faster to develop (instantiate, don't write). And the templates integrate with generation (chapter 11.4) — the register map generates the bank instances (and software headers), so HW/SW stay consistent. So at the system level, templates give consistency and productivity. So reusable templates exist because: every slave shares the same skeleton (capture / act / pace / respond — the commonality, inviting factoring); the skeleton's subtle logic is error-prone (the HREADY-gate, completion-gate, two-cycle ERROR, data-phase mux — verify once to avoid re-bugging); and factoring gives consistency and productivity (one trusted block, instantiated SoC-wide, often generated). So reusable AHB RTL templates exist to turn slave design from bespoke, bug-prone re-derivation into composition of trusted, parameterised, verified blocks — the engineering discipline that makes the module's lessons scale across a whole SoC. So this chapter is where the module pays off. So build once, reuse everywhere.

3. Mental Model

Model the template library as a professional kitchen's set of mother sauces and prepped components, versus cooking every dish from raw scratch. A great kitchen doesn't re-invent béchamel for every dish that needs it — it makes a perfect base once, and builds the lasagna, the gratin, and the croque-monsieur from it (plus a few prepped components). A new dish is assembled from trusted bases and components, tuned with parameters (more cheese, less salt), not cooked from raw ingredients re-deriving every technique each time. The tricky technique — the emulsion that can break — is mastered once, in the base.

A professional kitchen (the SoC design team) that must produce many dishes (slaves). The amateur approach is to cook every dish from raw scratch — re-deriving every technique (the tricky emulsion, the roux) each time, risking the same mistakes repeatedly (a broken sauce). The professional approach uses mother sauces and prepped components: a perfect base (the capture block — the HREADY-gated foundation) made once and trusted, plus a few prepped components (the output blocks — HREADYOUT, HRDATA, HRESP). A new dish (a new slave) is assembled from these trusted bases and components — the lasagna (a register bank), the gratin (a memory slave), the croque (a simple slave) — tuned with parameters (more cheese = more registers, less salt = fewer wait states), not cooked from raw, re-deriving every technique. The tricky technique — the emulsion that can break (the HREADY-gated capture, the completion-gated commit — the parts that break when done wrong) — is mastered once, in the base, and never re-attempted from scratch. And a complex dish (a bridge) is composed of the same bases and components, plated by a multi-step recipe (the control FSM). The menu (the register map) can even auto-generate the prep list (the instances). So the kitchen assembles dishes from trusted, tuned components — fewer broken sauces, faster service, consistent quality.

This captures the template library: the amateur cooking from raw scratch = hand-coding each slave, re-deriving the subtle logic; the mother sauce / perfect base = the HREADY-gated capture block; the prepped components = the HREADYOUT/HRDATA/HRESP output blocks; assembling dishes from bases = composing slaves from the blocks; tuning with parameters = parameterising (WIDTH/DEPTH/ATTRS/WAITS); mastering the tricky emulsion once in the base = verifying the error-prone logic once in the template; the multi-step recipe for a complex dish = the bridge skeleton FSM; the menu auto-generating the prep list = generating instances from the register map. Make the bases once, assemble and tune, master the tricky parts once.

Watch the same template produce different slaves by parameter:

One template, three parameterised instances

3 cycles

Figure 2 — the same parameterised template, instantiated with different parameters, produces different slaves. The 'param' rows show three instantiations of one verified slave template: instance A (WIDTH=32, DEPTH=8, WAITS=0, registered-read=no) yields a 32-bit zero-wait register bank; instance B (WIDTH=64, DEPTH=4K, WAITS=3, registered-read=yes) yields a 64-bit wait-stated memory slave; instance C (WIDTH=32, DEPTH=16, WAITS=1) yields another peripheral. The 'logic' row is identical across all three — the same verified RTL (HREADY-gated capture, completion-gated commit, two-cycle ERROR) — only the parameters differ. This is the template's value: write/verify the tricky logic once, configure per instance.

The model's lesson: make the bases once, assemble and tune, master the tricky parts once. In the figure, the template logic is identical across all three instances — only the parameters differ, producing different slaves from the same verified RTL.

4. Real Hardware Perspective

In hardware, the templates are parameterised modules (Verilog/SystemVerilog parameters, generate blocks) with the subtle logic inside; the leaf slaves instantiate the capture and output sub-modules; and a generator can emit instances from a register-map description.

The parameterised modules: each block is a parameterised module. The capture block: module ahb_capture #(parameter AW=32) (...) — instantiated with the address width. The register bank: module ahb_regbank #(parameter DW=32, N=8, ATTR=...) (...) — the data width, register count, and per-register attributes as parameters; a generate loop builds the N registers with their ATTR-specific logic. The memory slave: module ahb_mem #(parameter DW=32, DEPTH=4096, WAITS=0, REG_READ=0) (...). So in hardware, the templates are parameterised modules — parameters and generate blocks configuring the structure. So it's parameterised RTL. So one module, many configs.

Figure 3 — one verified template, many instances, configured by parameters. A slave template has its correctness-critical logic (the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR) written and verified once, with parameters for WIDTH, DEPTH, ATTRS, WAITS, registered-read. Instantiating it with different parameter values yields a 32-bit, 8-register, zero-wait, RW/RO/W1C UART register bank; a 64-bit, 4 KB, 3-wait-state, registered-read memory slave; a bridge instance from the FSM skeleton plus downstream parameters. The tricky logic is written once, so each new slave only sets parameters — fewer bugs, faster, consistent. Parameters and the register map often come from a single generated description.

The leaf slaves instantiate the blocks: a leaf slave instantiates the shared sub-modules. The register bank instantiates the capture block (ahb_capture), drives a register array (the generated flops with attribute logic), instantiates the HRDATA mux (selecting by addr_q), the HREADYOUT generation (zero-wait or counter), and the HRESP generation (the error checks + two-cycle FSM). So the leaf slave's RTL is mostly instantiation + wiring — the subtle logic is inside the sub-modules. So in hardware, a leaf slave composes the blocks. So it's structural composition. So slaves are wiring.

The generation from a register map: the parameters (and the register array's attributes/addresses) often come from a register-map description (SystemRDL/IP-XACT — chapter 11.4). A generator reads the map and emits the parameterised instance (the bank RTL with the right N, DW, per-register ATTR) and the software headers — consistent by construction. So in hardware, the templates integrate with generation — the map drives the instances. So in hardware, reusable AHB RTL is parameterised modules (the subtle logic inside, parameter/generate configuring), composed by leaf slaves (instantiation + wiring), and generated from a register map (consistent HW/SW). The parameterisation and the verified-once subtle logic are the essence. So in hardware, write parameterised, verify once, instantiate. So that's the reusable form.

5. System Architecture Perspective

At the system level, the template library is a design-discipline multiplier — it makes the SoC's many slaves consistent, correct, and fast to build, and it's the natural home for the module's hard-won correctness lessons; it's also where slave RTL meets the generation flow that keeps hardware and software in sync.

The consistency multiplier: an SoC has many slaves (dozens of peripherals, several memories, bridges). With a template library, they're all built from the same verified blocks — so they behave consistently (the same wait-state, error, capture semantics), are easier to verify (trust the block once), and are faster to develop. So at the system level, the library multiplies the design discipline across all slaves — one correct skeleton, many instances. So it's a consistency multiplier. So the SoC benefits at scale.

The correctness home: the module's hard-won lessons — the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR, the data-phase-aligned mux — are exactly the subtle points that must be right. The template library is their home: encoded once, verified, reused. So instead of every slave designer re-learning (and re-bugging) these, the library embodies them. So at the system level, the library is where the module's correctness knowledge lives — institutionalized, not re-derived. So it's the correctness repository. So lessons are captured.

The generation integration: the library is where slave RTL meets the single-source generation flow (chapter 11.4). The register map (SystemRDL/IP-XACT) parameterises the templates and generates the instances and the software headers — so the hardware (template instances) and software (headers) stay consistent from one source. So at the system level, the library integrates with generation for HW/SW consistency. So at the system level, the template library is a design-discipline multiplier (consistent, correct, fast slaves across the whole SoC — one skeleton, many instances), the home for the module's correctness lessons (the subtle pipeline/wait-state/error logic, institutionalized once rather than re-derived), and the integration point with single-source generation (the register map parameterising and generating instances + headers for HW/SW consistency). So reusable templates are how the module's lessons scale from one correct slave to a whole correct SoC — the engineering discipline that turns knowledge into leverage. So institutionalize the blocks, and every slave inherits the correctness.

6. Engineering Tradeoffs

Reusable AHB RTL templates embody the compose-don't-rederive, parameterise, verify-once design.

Reusable templates vs bespoke per-slave RTL. Templates give consistency, fewer bugs, and speed (verify once, instantiate); bespoke RTL re-derives the subtle logic each time (slower, bug-prone). Use templates for the common slave skeleton.
Parameterised vs fixed. Parameterising (WIDTH/DEPTH/ATTRS/WAITS) makes one template serve many slaves at the cost of parameter/generate complexity; fixed modules are simpler but not reusable. Parameterise the dimensions that vary.
Generated vs hand-instantiated. Generating instances (and headers) from a register map guarantees HW/SW consistency at the cost of the generator tooling; hand-instantiating risks mismatch. Generate for register-heavy slaves.
General template vs specialized. A general template covers most slaves but may carry unused logic; a specialized one is leaner but less reusable. Balance generality against area for the common cases.

The throughline: reusable AHB RTL templates package the whole module into a parameterised library — a HREADY-gated capture block (16.7), the output blocks (HREADYOUT 16.4, HRDATA 16.5, HRESP 16.6), the leaf slaves (simple 16.1, register bank 16.2, memory 16.3), and a bridge skeleton control FSM (16.10). A new slave is assembled by instantiating and parameterising (WIDTH/DEPTH/ATTRS/WAITS/registered-read), not re-deriving the subtle, correctness-critical logic (the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR, the data-phase-aligned mux — written and verified once, inside the templates). The benefits: fewer bugs (no re-derivation), faster development, SoC-wide consistency — and integration with generation (the register map parameterises/generates instances + headers for HW/SW consistency — chapter 11.4). It's the design-discipline multiplier that scales the module's correctness from one slave to a whole SoC.

The value of templates is that the SUBTLE logic is verified ONCE and never re-derived — so the templates must actually encapsulate the correctness-critical points (HREADY-gated capture, completion-gated commit, two-cycle ERROR, data-phase mux), and parameterisation must not let an instance bypass them

The point of reusable templates is correctness leverage — so the discipline that makes them worth it is that the subtle, correctness-critical logic is genuinely encapsulated inside the verified template and cannot be bypassed or re-derived by an instance. The whole value proposition is "verify once, reuse everywhere" — which only holds if the error-prone points (the ones that hide in simple tests) are inside the template, covered by its verification, and not something each instantiation re-implements. Two failure modes undermine this: (1) Leaky encapsulation. If a template exposes the subtle logic to the instance — e.g. it requires the instantiator to wire up the HREADY-gated capture enable, or to add the HREADYOUT term to the commit, or to sequence the two-cycle ERROR themselves — then each instance can get it wrong, and the "verified once" guarantee is lost. The template must fully own these: the capture block internally gates on HREADY; the commit logic internally includes HREADYOUT && !error; the HRESP block internally runs the two-cycle sequence. The instance just sets parameters and connects buses — it can't break the invariants. (2) Parameterisation that bypasses correctness. A parameter must configure behavior, not disable a correctness invariant. E.g. a WAITS parameter changes how many wait states, but the completion-gating of the commit must hold for any WAITS value; a REG_READ parameter adds a pipeline stage, but the data-phase alignment must hold either way. A parameter that (mis)lets an instance, say, commit during a wait or skip the two-cycle ERROR would defeat the template. So parameters vary the configuration within the correct envelope — they never expose a path out of it. The verification must cover the parameter space (the corner cases — zero/many waits, all attribute types, registered/combinational read, slave-switching traffic) so any legal instantiation is trusted. The discipline, stated cleanly: encapsulate the subtle logic fully (the instance can't re-derive or bypass it), parameterise within the correct envelope (parameters configure, never disable invariants), and verify across the parameter space (so every instance inherits the correctness). Otherwise you have templates in name but re-derivation in practice — the bugs (16.5–16.9) creep back in per instance. So make the templates genuinely own the correctness, and the library delivers the leverage. (See Address / Control Capture, Write FSM, and HRESP Generation.)

7. Industry Example

Build an SoC's slave set from a template library — the productivity and consistency in action.

An SoC has a dozen peripherals (UART, timers, GPIO, SPI), two memories (SRAM, ROM), and a peripheral bridge — all built from the template library.

The peripherals (register banks). Each peripheral is a register bank instance: the UART is ahb_regbank #(DW=32, N=8, ATTR={CTRL:RW, STATUS:RO, ...}); the timer is ahb_regbank #(DW=32, N=6, ATTR=...); etc. The same verified register-bank template, parameterised per peripheral. The subtle logic (the HREADY-gated capture, the W1C/RC attribute logic, the qualified-select for read-to-clear, the two-cycle ERROR on illegal writes) is inside the template — each peripheral just sets parameters.
The memories. The SRAM is ahb_mem #(DW=64, DEPTH=8K, WAITS=0) (fast, zero-wait); the ROM is ahb_mem #(DW=32, DEPTH=4K, WAITS=2, REG_READ=1) (slower, registered read). The same memory template, parameterised — the wait-state generation and completion-gating are inside.
The bridge. The peripheral bridge is the bridge skeleton (the control FSM — 16.10) instantiated with the downstream parameters. The hold-the-upstream discipline is inside the skeleton.
Generation from the register map. The peripherals' register banks are generated from a register-map description (SystemRDL): the generator emits the ahb_regbank instances (correct N, ATTR, addresses) and the software headers (matching addresses/fields) — HW and SW consistent by construction.
The payoff. All slaves behave consistently (same wait-state/error/capture semantics), the subtle logic was verified once (not re-derived a dozen times), development was fast (instantiate + parameterise), and HW/SW are consistent (generated). A bug found and fixed once in the template fixes all instances.

The example shows the template library's leverage: a dozen peripherals, two memories, and a bridge — all from a handful of verified, parameterised templates, instantiated and configured (and generated from the register map). The subtle correctness lives once, in the templates; the slaves are composition. This is slave design at SoC scale. This is the module's payoff.

8. Common Mistakes

Reusable-template misconceptions

"Hand-code each slave from scratch." No — compose from the verified, parameterised templates. Re-deriving the subtle logic (capture/commit/ERROR/mux) per slave re-introduces the bugs (16.5–16.9).
"The template can expose the subtle logic to the instance." No — encapsulate it fully (the HREADY-gate, completion-gate, two-cycle ERROR live inside). A leaky template loses the "verify once" guarantee.
"A parameter can disable a correctness invariant." No — parameters configure within the correct envelope (WAITS count, REG_READ, attributes); they must never let an instance bypass the completion-gating or two-cycle ERROR.
"Verifying one instance is enough." No — verify across the parameter space (zero/many waits, all attributes, registered/combinational read, slave-switching traffic), so every legal instance is trusted.
"Templates are just copy-paste." No — they're parameterised modules (parameter/generate), instantiated — not duplicated code (which drifts and re-bugs).
"Generation is unrelated to templates." No — the register map parameterises/generates the instances and headers (chapter 11.4), keeping HW/SW consistent — a key integration.

9. Interview Insight

Reusable RTL is a senior design-judgment interview topic — the slave-is-composition insight, the verify-once-encapsulate value, and the parameterise-within-the-envelope discipline are the signals.

Figure 4 — a strong answer in one card: a library of building blocks (capture + HREADYOUT/HRDATA/HRESP output blocks + leaf slaves + bridge skeleton); assemble a new slave by instantiating and parameterising verified blocks, not re-deriving the tricky logic; params configure WIDTH/DEPTH/ATTRS/WAITS/registered-read; benefits are fewer bugs (correctness verified once), faster, consistent, often generated. The senior point: slave design becomes composition of trusted, parameterised blocks, with the hard pipeline/wait-state correctness captured once.

The answer that lands gives the composition insight and the verify-once value: "The realization across building a bunch of slaves is that they're all the same skeleton — capture the address-phase control, act in the data phase gated to completion, pace with HREADYOUT, respond with HRESP — and the differences between slaves are parameters, not different logic: how many registers, how big the memory, which attributes, how many wait states. So the engineering move is to factor that skeleton into a small library of parameterised, verified building blocks: a HREADY-gated capture block at the base, output blocks for HREADYOUT, HRDATA, and HRESP, leaf slaves for the simple slave, register bank, and memory, and a bridge skeleton control FSM. A new slave is assembled by instantiating and parameterising these blocks, not by re-deriving the logic. The value is that the subtle, correctness-critical parts — the HREADY-gated capture, the completion-gated commit, the two-cycle ERROR, the data-phase-aligned mux — the parts that hide bugs in simple tests — are written and verified once, inside the templates, and never re-derived. So you get fewer bugs, faster development, and consistency across all the SoC's slaves. The key discipline is that the templates must genuinely encapsulate the subtle logic — the instance can only set parameters and connect buses, it can't bypass the invariants — and the parameters configure within the correct envelope, they never disable a correctness invariant. And you verify across the parameter space, so every legal instance is trusted. Often the parameters and the register map come from a single description that generates the instances and the software headers, keeping hardware and software consistent. So slave design becomes composition of trusted blocks rather than bespoke RTL." The slave-is-composition insight, the verify-once-encapsulate value, and the parameterise-within-the-envelope discipline are the senior signals.

🔍 The discriminator: slaves are the SAME skeleton differing by parameters, so factor it into verified, parameterised blocks — the subtle logic (HREADY-gate, completion-gate, two-cycle ERROR, data-phase mux) is verified ONCE, fully encapsulated, and parameters configure within the correct envelope (never bypassing invariants)

The discriminator on reusable RTL is whether you see slaves as composition and understand the verify-once value with its encapsulation discipline. A weak answer says "make the slave configurable with parameters." A solid answer adds the library (capture block, output blocks, leaf slaves, bridge skeleton) and that a new slave is instantiated, not rewritten. But the senior answer is about where the correctness lives: the subtle, error-prone logic — the HREADY-gated capture (16.7), the completion-gated commit (16.8/16.9), the two-cycle ERROR (16.6), the data-phase-aligned mux (16.5) — is written and verified once, fully encapsulated inside the templates, so it's never re-derived (and re-bugged) per slave. The discipline that makes this real is the signal: (1) the encapsulation must be non-leaky — the instance can only set parameters and connect buses; it can't be required to wire the HREADY-gate or add the HREADYOUT term itself (or the guarantee is lost); (2) parameters configure within the correct envelope (WAITS, REG_READ, ATTRS) and never let an instance bypass an invariant (no committing during a wait, no skipping the two-cycle ERROR); (3) verification covers the parameter space (zero/many waits, all attributes, registered/combinational read, slave-switching traffic), so every legal instance is trusted. The framing that impresses: this is the engineering discipline that scales the module's correctness lessons from one slave to a whole SoC — a design-discipline multiplier, the institutional home for the hard-won subtle-logic knowledge, and the integration point with single-source generation (the register map parameterising/generating instances + headers — chapter 11.4 — for HW/SW consistency). A bug fixed once in the template fixes all instances. A candidate who frames slaves as composition, locates the correctness inside verified-once encapsulated templates, insists parameters configure within the correct envelope, and ties it to generation demonstrates senior design judgment — the capacity to turn knowledge into reusable leverage, which is what distinguishes an architect from a coder.

10. Practice Challenge

Build and reason from reusable AHB RTL templates.

The library. List the building blocks (capture block, output blocks, leaf slaves, bridge skeleton) and how they layer.
Composition. Explain how a new slave is assembled by instantiating and parameterising the blocks, not re-deriving the logic.
Read the figure. From Figure 2, explain how the same template logic produces different slaves by parameter (WIDTH/DEPTH/WAITS).
Encapsulation. Explain why the templates must fully encapsulate the subtle logic, and the failure mode if it leaks.
Generation. Explain how the templates integrate with register-map generation for HW/SW consistency.

11. Key Takeaways

Every slave is the same skeleton — capture, act (gated to completion), pace (HREADYOUT), respond (HRESP) — differing by parameters, not logic. So slave design is composition, not re-derivation.
The library: a HREADY-gated capture block (16.7), output blocks (HREADYOUT 16.4, HRDATA 16.5, HRESP 16.6), leaf slaves (simple 16.1, register bank 16.2, memory 16.3), and a bridge skeleton control FSM (16.10).
Assemble by instantiating + parameterising (WIDTH/DEPTH/ATTRS/WAITS/registered-read) — not re-deriving the subtle logic; the templates are parameterised modules (parameter/generate).
The subtle logic is verified once, fully encapsulated — the HREADY-gate, completion-gate, two-cycle ERROR, data-phase mux live inside the templates; the instance only sets parameters and connects buses (can't bypass the invariants).
Parameters configure within the correct envelope — never disabling an invariant; verify across the parameter space so every legal instance is trusted.
Benefits: fewer bugs, faster, consistent — a bug fixed once fixes all instances; integrates with single-source generation (register map → instances + headers — chapter 11.4) for HW/SW consistency. The design-discipline multiplier that scales correctness from one slave to a whole SoC.

12. What Comes Next

This completes Module 16 — AHB Slave RTL Design: you can now build a correct AHB slave from the ground up — the capture, the outputs (HREADYOUT, HRDATA, HRESP), the write/read FSMs, the bridge control FSM, and the reusable template library that scales it across an SoC. The next module turns from building slaves to verifying them:

Module 17 — AHB Verification (next) — the protocol-checker mindset, SVA assertions, scoreboards, coverage, and how to prove a slave (or interconnect) is correct.

To revisit the blocks this library packages, see A Simple AHB-Lite Slave, Register Bank Slave, Memory Slave, Address / Control Capture, and Bridge FSM (RTL).