AHB-Lite Slave Design

This chapter is the constructive payoff of Module 12: how to build a correct AHB-Lite slave. The slave is where the protocol's two-phase pipeline meets real logic, and there are a handful of rules that must be right. A correct AHB-Lite slave: qualifies its select (act only when HSEL is high AND HTRANS is a real transfer — NONSEQ/SEQ — never on IDLE/BUSY); registers the address-phase controls (the qualified select, HADDR, HWRITE, HSIZE) so it can act in the data phase (the pipeline demands this one-cycle offset); drives the response — HREADYOUT (held low to insert wait states) and HRESP (only OKAY or the two-cycle ERROR); and handles read/write correctly (capture HWDATA in the data phase for writes, mux the register onto HRDATA for reads). It must also understand the HREADYOUT-vs-HREADY relationship in a multi-slave system. This chapter walks the slave's structure, its FSM, and the subtle rules that separate a working slave from a buggy one.

1. What Is It?

An AHB-Lite slave is a bus endpoint that responds to transfers addressed to it. Building one correctly means getting these elements right:

• Qualify the select — respond only when HSEL is high and HTRANS is a real transfer (NONSEQ/SEQ), not IDLE/BUSY (chapter 11.2).
• Register address-phase → data-phase — latch the qualified select, HADDR, HWRITE, HSIZE at the clock edge ending the address phase, to act on them in the data phase.
• Drive the response — HREADYOUT (low for wait states, high to complete) and HRESP (OKAY, or the two-cycle ERROR).
• Handle data — for writes, capture HWDATA (data phase) into the register file; for reads, mux the addressed register onto HRDATA (data phase).

So an AHB-Lite slave is a two-phase machine matching the AHB pipeline: an address-phase front end that samples and qualifies the access and registers it, and a data-phase back end that acts (read/write) and responds (HREADYOUT/HRESP/HRDATA). The discipline is in the details: qualify with HTRANS (or suffer spurious accesses on IDLE/BUSY), register correctly (or misalign with the pipeline), drive a defined HREADYOUT/HRESP every cycle (or hang/confuse the master), and use the two-cycle ERROR (or break the master's follow-on cancellation). Get these right and you have a correct, simple AHB-Lite slave. So slave design is the constructive application of the protocol — the place where the pipeline, HSEL qualification, wait states, and responses all come together.

2. Why Does It Exist?

The AHB-Lite slave's structure exists because it must correctly participate in the two-phase pipeline — which forces the qualify-register-respond pattern — and because each rule prevents a specific failure (spurious accesses, pipeline misalignment, master hangs, broken error handling).

The two-phase pipeline forces the structure: AHB's transfer has an address phase (HADDR, HWRITE, HTRANS, HSEL valid) one cycle before the data phase (where the slave drives/accepts data and the response). So the slave is told about the transfer in the address phase but must act and respond in the data phase — a one-cycle offset. This forces a register: the slave must latch the address-phase information to use it in the next cycle (the data phase). So the qualify-then-register-then-respond structure is a direct consequence of the pipeline — the slave can't respond in the address phase (it doesn't have the data-phase context yet) nor act on stale address-phase signals in the data phase (HADDR has moved on to the next transfer). So the slave registers the address-phase controls to align its action/response to the data phase. So the structure exists to match the pipeline.

The qualification rule prevents spurious accesses (chapter 11.2): HSEL alone can be high during IDLE/BUSY (HADDR still decodes to the slave's region). If the slave acted on HSEL alone, it would perform spurious reads/writes on non-transfers — a read with side effects (popping a FIFO, clearing a flag), an acknowledged non-write. So the slave must qualify: act only when HSEL is high and HTRANS is NONSEQ/SEQ. So the qualification rule exists to prevent the spurious-access bug. So it's a correctness necessity, not optional.

The response rules prevent hangs and broken handshakes: the slave must drive a defined HREADYOUT and HRESP every data-phase cycle. If it left HREADYOUT undefined or never asserted it high, the master would hang (waiting for completion). If it signaled ERROR in one cycle (HRESP = ERROR with HREADYOUT already high) instead of the two-cycle sequence, the master couldn't cancel a pipelined follow-on transfer (chapter 12.4) — a protocol violation. So the response rules (defined HREADYOUT/HRESP, wait via HREADYOUT low, two-cycle ERROR) exist to keep the master correctly synchronized. So each rule prevents a specific failure. So the AHB-Lite slave's structure and rules exist because the slave must correctly participate in the pipeline (forcing qualify-register-respond) and because each rule averts a concrete bug: qualification (spurious accesses), registering (pipeline alignment), defined/two-cycle responses (master hangs and broken follow-on cancellation). The slave is simple (AHB-Lite removed SPLIT/RETRY, so no complex bus-release logic), but it must be correct in these specific ways. So slave design exists as the disciplined construction that makes a bus endpoint correctly pipeline-compliant.

3. Mental Model

Model the AHB-Lite slave as an order counter at a deli with a "take a number, prepare, then serve" flow — when a customer's number is both called and it's a real order (not someone just browsing), the clerk writes down the order details on a ticket (registers the address phase), then in the next step prepares and hands over the food (the data phase), keeping a "please wait" light on if it's not ready yet (HREADYOUT low), and only ever says "here you go" (OKAY) or "sorry, we're out of that" (ERROR).

A deli order counter (the slave) has a disciplined flow. First, the clerk acts on a customer only when their number is called and they actually have an order — not when someone's just browsing the menu (HSEL high but HTRANS = IDLE/BUSY — selected, but no real transfer). That's the qualification: called and a real order. When both hold, the clerk writes the order on a ticket — the items, whether it's pickup or delivery, the quantity (registering HADDR, HWRITE, HSIZE in the address phase) — because they'll prepare it in the next step, not instantly. Then, in the preparation step (the data phase), the clerk makes the order (reads/writes the register file) using the ticket (the registered info, not whatever the next customer is now saying). If it's not ready, they keep a "please wait" light on (HREADYOUT low) — the customer waits — and flip it off when done. And they only ever say "here you go" (OKAY) or, if they can't fulfill it, "sorry, we're out of that" (ERROR) — with a moment's warning before the final "sorry" so the customer behind can adjust (the two-cycle ERROR). Disciplined: qualify, ticket, prepare, serve.

This captures the slave: the deli counter = the slave; number called AND a real order = HSEL high AND real HTRANS (qualify); writing the ticket = registering address-phase controls; preparing in the next step = acting in the data phase; using the ticket not the next customer's words = using registered values (the pipeline offset); the "please wait" light = HREADYOUT low (wait states); "here you go" / "sorry, we're out" = OKAY / ERROR; the warning before "sorry" = the two-cycle ERROR. Qualify, ticket, prepare, serve — the disciplined slave flow.

Watch a read with one wait state — qualify, register, respond:

The model's lesson: qualify (called AND a real order), ticket (register), prepare (data phase), serve (OKAY/ERROR) with a "please wait" light (HREADYOUT). In the waveform, the slave registers the qualified address-phase access, inserts a wait state, then returns the data with OKAY.

4. Real Hardware Perspective

In hardware, the slave is the address-phase sample-and-register logic, the data-phase read/write and response logic, and — crucially in a multi-slave system — the HREADYOUT-vs-HREADY handling that keeps slaves synchronized.

The address-phase front end samples and qualifies: at the rising clock edge ending the address phase, the slave latches sel_q = HSEL && (HTRANS == NONSEQ || HTRANS == SEQ), along with the address (the relevant low bits / register index), HWRITE, and HSIZE, into registers. These registered values (sel_q, the address, write/size) are what the data-phase logic uses. So the front end is a set of flops capturing the qualified, address-phase context. So in hardware, the front end is a qualify-and-latch stage.

The data-phase back end acts and responds: using the registered context, for a write it captures HWDATA (which the master drives in the data phase) into the addressed register/memory location; for a read it muxes the addressed register onto HRDATA. It drives HREADYOUT — high if the access completes this cycle, low to insert wait states (if it needs more time, e.g. a slow memory) — and HRESP — OKAY normally, or the two-cycle ERROR on failure (HRESP = ERROR with HREADYOUT low, then high). A simple slave is often a small FSM (Figure 3): IDLE → ACCESS (→ WAIT if needed) → respond. So in hardware, the back end is the read/write datapath plus the HREADYOUT/HRESP drivers. So the slave is front-end flops + back-end response logic + register file.

The HREADYOUT vs HREADY relationship is the subtle multi-slave point: each slave drives its own HREADYOUT (its readiness). But the master needs a single HREADY (is the current transfer — to whichever slave — done?). So the interconnect combines the slaves' HREADYOUT signals — selecting the active slave's HREADYOUT (and accounting for the pipeline) — into the shared HREADY that goes to the master and back to all slaves. Why back to all slaves? Because a slave needs HREADY as an input to know when the previous transfer (possibly to another slave) has completed, so it knows when its own address-phase sample is valid (it should sample its address phase only when HREADY is high — i.e. the previous transfer finished). So a slave both drives HREADYOUT (its readiness) and observes HREADY (the system's readiness) — using HREADY to time its address-phase sampling. So in hardware, the slave drives HREADYOUT and observes HREADY, and the interconnect maps between them. So a correct slave must handle this: sample the address phase when HREADY is high, register, then drive HREADYOUT/HRESP/HRDATA in the data phase. Getting the HREADYOUT/HREADY timing right is the subtle part of multi-slave AHB-Lite slave design.

5. System Architecture Perspective

At the system level, the AHB-Lite slave's design discipline is what makes a library of interoperable, reusable slaves possible — and the simplicity (vs full AHB) is what makes correct slaves easy to build, which is a major reason AHB-Lite is attractive.

The interoperability through discipline point: AHB-Lite works as a system because every slave follows the same rules — qualify with HTRANS, register address-phase, drive defined HREADYOUT/HRESP, use the two-cycle ERROR. This shared discipline is the contract that lets any compliant master and any compliant slaves interoperate. A slave that violates the contract (responds on HSEL alone, drives undefined HREADYOUT, one-cycle ERROR) would break the system even if it "works" in isolation. So slave-design correctness is a system property — the slave must be a good protocol citizen. So at the system level, the design rules are the interoperability contract; following them is what makes a slave usable in any AHB-Lite system. This is why slave design is taught as a set of rules, not just "make it do reads and writes."

The simplicity enables a rich slave ecosystem: because AHB-Lite slaves are simple (no SPLIT/RETRY, no arbitration interaction — chapter 12.4), they're easy to design correctly and verify. A reusable slave (a memory controller, a peripheral) needs only the qualify-register-respond logic and OKAY/ERROR responses — a small, well-understood pattern. So there's a rich ecosystem of AHB-Lite slave IP (memories, peripherals, bridges) that's cheap to build and integrate. So at the system level, the slave's simplicity (a consequence of AHB-Lite's reductions) enables the many-slave systems that microcontrollers are — you can attach a dozen simple, correct slaves easily. So the slave simplicity is a system enabler, not just a per-slave nicety.

The verification leverage rounds it out: a simple, rule-following slave is verifiable — the rules (qualify, register, respond, two-cycle ERROR) map directly to checkable properties (assertions: "never act on HSEL without real HTRANS", "always drive defined HREADYOUT", "ERROR is always two cycles", "read data valid when HREADYOUT high on a read"). So slave verification is tractable and largely reusable across slaves (the protocol-compliance checks are common; only the slave-specific function differs). Protocol-checker IP (assertion-based VIP) encodes exactly these rules. So at the system level, the slave's rule-based design makes verification systematic and reusable — you verify protocol compliance once (via shared assertions) and the slave's specific function separately. So AHB-Lite slave design's system value is threefold: the design rules form the interoperability contract (any compliant slave works with any master), the simplicity enables a rich, cheap slave ecosystem (many-slave MCU systems), and the rule-based structure makes verification systematic and reusable. The disciplined-but-simple slave is the building block that makes AHB-Lite systems practical to assemble and verify — which, with the other AHB-Lite simplifications, is why it dominates single-master design. So slave design is where AHB-Lite's simplicity pays off most concretely: simple, correct, interoperable, verifiable endpoints.

6. Engineering Tradeoffs

AHB-Lite slave design embodies the disciplined-but-simple endpoint.

• Qualify (HSEL + HTRANS) vs HSEL-only. Qualifying prevents spurious accesses on IDLE/BUSY at the cost of a little logic (the HTRANS check). HSEL-only is simpler but buggy (spurious reads/writes). Always qualify.
• Register address-phase vs combinational response. Registering aligns the response to the data phase (pipeline-correct) at the cost of the registers. A combinational (address-phase) response would be a phase early — wrong. Always register.
• HREADYOUT wait states vs always-ready. Driving HREADYOUT low lets a slow slave take the time it needs (correct) at the cost of stalling the master. An always-ready slave is simpler but only works if it's genuinely single-cycle. Use wait states when needed.
• Two-cycle ERROR vs one-cycle. The two-cycle ERROR lets the master cancel a pipelined follow-on (protocol-correct) at the cost of the two-cycle sequence logic. A one-cycle ERROR is simpler but violates the protocol. Always use two-cycle.

The throughline: a correct AHB-Lite slave qualifies its select (HSEL AND real HTRANS — never IDLE/BUSY), registers the address-phase controls (select, address, write, size) to act in the data phase (matching the pipeline), and drives the response — HREADYOUT (low for wait states, high to complete) and HRESP (OKAY or the two-cycle ERROR) — handling reads (mux register → HRDATA) and writes (capture HWDATA) in the data phase. It observes HREADY (to time its address-phase sampling) while driving HREADYOUT (its readiness), with the interconnect mapping between them. Each rule prevents a specific bug; the slave is simple (no SPLIT/RETRY) but must be correct in these ways — the disciplined endpoint that makes AHB-Lite systems interoperable and verifiable.

7. Industry Example

Build a simple AHB-Lite register-block slave (a small peripheral).

A peripheral has a few registers: a control register, a status register, and a data register.

• Address-phase sampling. When HREADY is high (the previous transfer completed), the slave samples HSEL, HTRANS, HADDR (the register-index bits), HWRITE, and HSIZE. It computes sel_q = HSEL && (HTRANS == NONSEQ || HTRANS == SEQ) and registers sel_q, the register index, and HWRITE.
• Ignoring IDLE. Between accesses, the master drives HTRANS = IDLE while HADDR may still point into the peripheral's region (HSEL high). Because sel_q requires a real transfer, the slave does not act — no spurious read of the status register (which might be read-to-clear), no spurious write. Qualification prevents the bug.
• A register read. For a read (registered sel_q = 1, HWRITE = 0), in the data phase the slave muxes the addressed register (say the status register) onto HRDATA, drives HREADYOUT high and HRESP = OKAY. The master captures the data. (If the register access needed an extra cycle, the slave would hold HREADYOUT low for a wait state first.)
• A register write. For a write (sel_q = 1, HWRITE = 1), in the data phase the slave captures HWDATA (which the master drives in the data phase) into the addressed register (say the control register), drives HREADYOUT high, HRESP = OKAY. The write lands.
• An illegal access. A write to the read-only status register: the slave detects the read-only violation and returns the two-cycle ERROR — HRESP = ERROR with HREADYOUT low, then HREADYOUT high. The master faults (chapter 11.5). The slave never silently drops the write.
• HREADY observation. Throughout, the slave watches the shared HREADY to know when each transfer completes (when to advance) — it samples its address phase only when HREADY is high, ensuring it aligns with the system pipeline even when a previous transfer (to another slave) inserted wait states.

The example shows the slave's discipline end-to-end: qualify (ignore IDLE), register the address phase, act in the data phase (read muxes a register, write captures HWDATA), respond with HREADYOUT/OKAY (or two-cycle ERROR for the illegal write), and observe HREADY for timing. This is the template for any AHB-Lite register-block or memory slave.

8. Common Mistakes

9. Interview Insight

AHB-Lite slave design is a hands-on interview topic — the four rules (qualify, register, respond, two-cycle ERROR) and the HREADYOUT/HREADY distinction are the signals.

The answer that lands gives the rules and the pipeline reasoning: "A correct AHB-Lite slave follows four rules. First, qualify the select: act only when HSEL is high and HTRANS is a real transfer — NONSEQ or SEQ — not IDLE or BUSY, because HSEL can be high during IDLE and responding then would cause spurious reads or writes. Second, register the address-phase controls — the qualified select, the address, HWRITE, HSIZE — at the clock edge, because the AHB pipeline puts the data phase one cycle after the address phase, so the slave must latch the address-phase context to act on it in the data phase; using the live HADDR in the data phase would read the next transfer's address. Third, in the data phase, perform the access — for a write, capture HWDATA, which the master drives in the data phase, into the register; for a read, mux the addressed register onto HRDATA — and drive the response: HREADYOUT, holding it low to insert wait states if the slave needs more time, high to complete. Fourth, drive HRESP as only OKAY or the two-cycle ERROR — ERROR with HREADYOUT low, then high — never a one-cycle ERROR, so the master can cancel a pipelined follow-on. There's also the HREADYOUT-versus-HREADY point: the slave drives its own HREADYOUT, but observes the shared HREADY — which the interconnect builds from the active slave's HREADYOUT — to time when it samples its address phase." The four rules, the pipeline-forces-registering reasoning, and the HREADYOUT/HREADY distinction are the senior signals.

10. Practice Challenge

Build and reason from an AHB-Lite slave.

1. The four rules. State the four rules a correct AHB-Lite slave must follow.
2. Qualify. Explain why the slave qualifies HSEL with HTRANS and what bug it prevents.
3. Read the waveform. From Figure 2, identify the address-phase sampling, the wait state, and the data-phase response.
4. HREADYOUT vs HREADY. Explain the difference and why the slave needs both.
5. Two-cycle ERROR. Explain how the slave signals an error and why it takes two cycles.

11. Key Takeaways

• A correct AHB-Lite slave follows four rules: qualify the select (HSEL AND real HTRANS), register the address-phase controls into the data phase, drive a defined HREADYOUT/HRESP every cycle, and use the two-cycle ERROR.
• Qualify with HTRANS — act only on NONSEQ/SEQ, never IDLE/BUSY — or suffer spurious reads/writes with side effects.
• Register address-phase → data-phase — the pipeline puts the data phase one cycle after the address phase, so latch the select/address/write/size; using live HADDR in the data phase is an off-by-one-phase bug.
• Respond in the data phase — capture HWDATA (writes) or mux the register onto HRDATA (reads); drive HREADYOUT (low = wait states, the only delay mechanism), and HRESP = OKAY or the two-cycle ERROR.
• HREADYOUT ≠ HREADY — the slave drives HREADYOUT (its readiness); it observes HREADY (system readiness, built by the interconnect from the active slave's HREADYOUT) to time its address-phase sampling.
• The rules are the interoperability contract — following them makes the slave work with any compliant master/system, simple to build, and systematically verifiable (the rules map to assertions).

12. What Comes Next

You can now build a correct AHB-Lite slave. The final chapter of Module 12 ties the module together:

• AHB-Lite vs Full AHB (next) — a precise tabulation of exactly what AHB-Lite keeps and drops, consolidating the module.

To revisit the pieces this slave design uses, see HSEL Generation (qualification), Simplified Responses (OKAY/ERROR), and Slave-Inserted Wait States (HREADY).