Holding Address & Control

Chapter 6.3 established the manager's general discipline during a wait: hold outputs, act on HREADY high. This chapter zooms into the address and control half of that contract with precision — exactly which signals, what "held" means (bit-stable, no glitch), and for how long. It also surfaces a pipeline subtlety that catches many engineers: because AHB overlaps transfers, the address and control the manager holds during a wait belong to the next transfer (its address phase is being extended), while the write data it holds belongs to the current transfer (its data phase is being extended). One wait state freezes two transfers at once — and the address bus and data bus carry different ones.

1. What Is It?

The address/control hold contract is the requirement that, while HREADY is low, the manager keeps the address and every control signal at exactly their current value — bit-stable, no change, no glitch — for every wait cycle, until HREADY goes high.

The signals covered by this contract are the entire address-phase group:

• HADDR — the address
• HTRANS — the transfer type (NONSEQ/SEQ/IDLE/BUSY)
• HWRITE — the direction (read/write)
• HSIZE — the transfer width
• HBURST — the burst type
• HPROT, HMASTLOCK (and the rest of the control group)

The word that matters in this contract is bit-stable. It is not enough for the address to be "roughly the same" or to settle to the right value eventually within the cycle — it must hold its exact value, every bit, every cycle, glitch-free. The reason is that these signals are continuously decoded (HADDR drives the address decoder, chapter 3.9) and interpreted; a transient change on even one bit could momentarily re-decode the transfer to a different subordinate or re-interpret its type. So the contract is strict: same value, bit-exact, until HREADY high.

2. Why Does It Exist?

This contract exists because the address and control are continuously interpreted throughout the wait — the decoder, the selected subordinate, and the bus logic all act on them every cycle — so they must stay valid every cycle, not just at the start.

Unlike a value that is sampled once at a known edge, the address and control are combinationally consumed across the whole wait: the address decoder is continuously decoding HADDR to select a subordinate (HSEL); the selected subordinate is continuously reading the control signals to know what transfer it is handling; the bus fabric is routing based on them. So at every cycle of the wait, these signals must carry the correct, stable transfer description. If they changed mid-wait, the decode and interpretation would change mid-transfer — the wrong subordinate selected, the wrong size or direction applied. The contract exists because the signals are live every cycle, so they must be stable every cycle.

The reason glitches specifically matter (not just deliberate changes) is that the decoder responds to the instantaneous value: a brief glitch on a HADDR bit can momentarily assert a different HSEL, transiently selecting the wrong subordinate — which can cause spurious side effects (a glitched address hitting a read-sensitive or write-sensitive register). So "stable" must mean glitch-free, not merely "the right value at the sampling edge." The contract demands bit-exact stability because the address is decoded continuously, and a glitch is a momentary wrong address. This is stricter than a simple setup/hold-at-an-edge requirement.

The contract also exists to keep the pipeline coherent: the next transfer's address phase is held during the wait precisely so it does not advance into its data phase prematurely (chapter 6.5). The held address/control is the next transfer waiting at the gate — holding it stable keeps that transfer well-defined and ready to advance the instant HREADY goes high. So the hold contract is what keeps the next transfer correctly queued during the wait, ready to proceed cleanly. Without it, the transfer waiting in the address phase would be corrupted before it ever reached its data phase.

3. Mental Model

Model the held address/control as a label held up to a sorting machine — it must stay perfectly readable the whole time the machine is looking, because the machine reads it continuously, not once.

A sorting machine (the decoder + subordinate) reads a label (HADDR + control) to route and handle a package (the transfer). The machine doesn't glance at the label once — it reads it continuously the whole time the package sits there (every wait cycle). So you must hold the label perfectly still and readable: no smudging, no swapping, no flicker (no glitch). If the label flickered to a different address even for an instant, the machine might route the package to the wrong bin (re-decode to a different subordinate) in that instant. You hold the label rock-steady until the machine says "done" (HREADY high) and takes the package on.

This captures the contract's strictness: the machine reading continuously is why the label must be bit-stable every cycle (not just right at one moment), and the flicker routing wrong is why glitches matter (a momentary wrong value is a momentary wrong decode). The label held steady until "done" is the address/control held until HREADY high.

Watch which transfer owns the address vs the data during a wait:

The model's lesson: the held address is the next transfer's label kept perfectly readable; the held write data is the current transfer's payload kept ready to accept. In the waveform, A2 (next transfer T2) is held on the address bus while D1 (current transfer T1) is held on the data bus — one wait, two transfers, each frozen on its own bus.

4. Real Hardware Perspective

In hardware, the address/control hold falls out of gating the manager's address-phase output registers with HREADY — but the bit-stable, glitch-free requirement adds a constraint on how those outputs are driven.

As with chapter 6.3, the manager's address and control outputs come from registers enabled by HREADY: they advance to the next transfer only on HREADY high, so they naturally hold during a wait. So the basic hold is automatic from HREADY-gating the address-phase registers. But the glitch-free part is a combinational-path concern: the held value must not glitch, which means the path from the (stable) register to the bus output must be clean. Since the register value is stable during the hold and the path is typically direct, this is usually satisfied — but any combinational logic between the register and the bus (e.g., muxing for multi-master, chapter 3.11) must not introduce glitches on the held address. So in hardware, the hold is a registered, HREADY-gated output, and the glitch-freedom comes from keeping the output path clean while the register holds.

The continuous decode is the hardware reason for the strictness: the address decoder (chapter 3.9) is combinational — it continuously maps HADDR to HSEL. So whatever HADDR carries instantaneously, the decoder reflects in HSEL. A stable held HADDR produces a stable HSEL (the right subordinate selected throughout the wait); a glitched HADDR would produce a glitched HSEL (a momentary wrong selection). This is why the held address must be bit-stable: the combinational decoder has no memory, it just tracks HADDR, so HADDR must stay correct every instant. The decoder's continuous nature is the hardware root of the bit-stable contract.

The pipeline ownership is a concrete hardware fact: during a wait, the address bus physically carries the next transfer's address (it was driven there in that transfer's address phase and held), while the data bus carries the current transfer's data. These are two different buses carrying two different transfers, frozen together. The manager's address-phase registers hold the next transfer; its (or the subordinate's) data-phase logic holds the current transfer's data. So in hardware, "holding during a wait" is two distinct holds on two distinct buses, for two distinct transfers — the pipeline made physical. Recognizing this is key to reading a waveform correctly: at any wait cycle, decode the address bus as the next transfer and the data bus as the current one.

A hardware nuance on the control group: all control signals must hold together with the address — HTRANS, HWRITE, HSIZE, HBURST, HPROT — because they jointly define the transfer the subordinate is handling. Holding HADDR but letting HSIZE change, for instance, would tell the subordinate a different transfer width mid-transfer. So the hold is on the whole address-phase group as a unit, all gated by the same HREADY, all advancing together on completion. The control signals are not separable from the address in this contract.

5. System Architecture Perspective

At the system level, the address/control hold contract is what keeps decode and routing stable across a wait — it ensures the interconnect keeps routing the transfer to the same subordinate for the whole wait, which is essential for correct operation in a multi-subordinate system.

In a system with many subordinates behind a decoder/interconnect (chapters 3.9–3.11), the held address is what keeps the routing fixed during a wait: as long as HADDR is stable, the decoder keeps selecting the same subordinate, and the interconnect keeps routing to it. So the hold contract guarantees routing stability across the wait — the transfer stays connected to its target subordinate the whole time. This matters because a wait can span several cycles; without a stable address, the routing could wander mid-transfer, which would be catastrophic in a multi-subordinate fabric. The hold contract is thus a routing-stability guarantee at the system level.

The pipeline-ownership insight has system-level weight for anyone building or verifying an interconnect: the fabric must correctly hold both the next transfer's address routing and the current transfer's data routing during a wait, simultaneously. A correct interconnect freezes both the address-phase routing (next transfer) and the data-phase routing (current transfer) when HREADY is low. So interconnect designers must handle the two-transfers-frozen-together reality — it is not enough to hold "the transfer"; the address path and data path carry different transfers and both must hold. This is a common source of interconnect bugs, which is why understanding the ownership precisely (Figure 2) matters for system design.

For verification, the hold contract is a prime assertion target (foreshadowing the protocol-checker mindset of later modules): a monitor checks that HADDR and the control group do not change while HREADY is low. This is one of the most common AHB protocol assertions, because a hold violation is a real and damaging bug (wrong subordinate selected, wrong transfer applied). So at the system/verification level, the hold contract is encoded as an assertion ("address and control stable while HREADY low") that guards every transfer. The contract is not just a design rule but a checkable property — which is how systems ensure managers honor it.

6. Engineering Tradeoffs

The hold contract reflects AHB's continuous-decode, address-phase-holds-too design.

• Continuous decode vs sampled decode. AHB decodes the address combinationally and continuously, which is simple and low-latency but demands a bit-stable held address (glitches matter). A design that sampled the address once at an edge could tolerate glitches between edges but would add latency and complexity. AHB chooses continuous decode — simple and fast — and pays with the strict stability contract.
• Holding the whole control group vs holding only the address. AHB holds the entire address-phase group together, which is uniform and unambiguous (the whole transfer description is frozen). Holding only some signals would be ambiguous and bug-prone. AHB holds them as a unit — all or nothing, gated by the same HREADY.
• Address-phase-holds vs address-phase-free-runs. Because AHB pipelines, the next transfer's address phase is held during the current transfer's wait — the manager cannot advance the next address until the current data completes. This couples the next transfer to the current one's wait (the manager can't "run ahead"), at the benefit of a simple, in-order pipeline. A decoupled protocol would let the manager issue ahead, at the cost of complexity. AHB's coupling is simpler.
• Bit-exact stability vs approximate. Demanding bit-exact, glitch-free stability is strict but unambiguous and verifiable. A looser requirement would be cheaper to meet but unsafe with a continuous decoder. AHB requires bit-exact — the decoder leaves no room for approximation.

The throughline: the address/control hold contract is strict (bit-stable, glitch-free, whole-group, every cycle) because AHB decodes continuously and pipelines transfers. The cost is that the manager must hold the next transfer's full address-phase description rock-steady through arbitrary waits and cannot run ahead — accepted because it keeps decode, routing, and the pipeline correct with a simple combinational fabric.

7. Industry Example

Trace the hold contract through a multi-wait transfer in a multi-subordinate system.

A processor reads a slow flash that sits among several subordinates behind a decoder/interconnect, and the flash inserts several wait states.

• The address phase presents and holds. The processor presents the flash address and control (HWRITE=0 read, HSIZE=word, HTRANS=NONSEQ). The decoder decodes the address to select the flash (HSEL_flash). The processor must now hold all of this stable.
• The decoder keeps selecting flash throughout the wait. As the flash inserts wait states (HREADY low), the processor holds HADDR and control bit-stable. Because HADDR is stable, the decoder continuously keeps HSEL_flash asserted — the transfer stays routed to the flash the whole wait. Routing is stable because the address is stable.
• The pipeline ownership. During these wait cycles, the address bus carries the next transfer's address (the processor's following access, held in its address phase), while the data bus is where the flash's read data will appear when ready. So the address bus and the data activity belong to different transfers — the next one and the current one. The processor holds the next transfer's address steady while waiting for the current one's data.
• A glitch bug, hypothetically. Suppose a glitch hit a high-order HADDR bit during the wait. For that instant, the decoder might assert HSEL for a different subordinate — say a peripheral with a read-sensitive status register. The transient selection could pop that peripheral's FIFO or clear a status bit — a real corruption, from a momentary glitch. This is exactly what the bit-stable contract prevents, and what a hold assertion would catch.
• Completion. When the flash asserts HREADY high, the read completes; the next transfer (whose address the processor was holding) advances into its data phase, and the processor presents the following address. The hold ends cleanly, and the pipeline steps forward.

The example shows the hold contract doing its job: keeping the routing stable (decoder keeps selecting flash), keeping the next transfer well-defined (its address held), and preventing wrong-subordinate glitches. The pipeline ownership — address bus = next transfer, data = current — is visible throughout, and the glitch scenario shows why bit-exact stability is not optional.

8. Common Mistakes

9. Interview Insight

The hold contract — especially the pipeline-ownership subtlety — is a discriminating interview topic.

The answer that lands states the contract precisely and surfaces the pipeline subtlety: "While HREADY is low, the manager holds the address and the entire control group — HTRANS, HWRITE, HSIZE, HBURST, HPROT — bit-stable, glitch-free, every cycle until HREADY high. And there's a subtlety from the pipeline: the address it's holding belongs to the next transfer, whose address phase is being extended, while the write data it's holding belongs to the current transfer, whose data phase is being extended. One wait freezes two transfers — the address bus and data bus carry different ones. The stability has to be bit-exact because the decoder is combinational: a glitch on the held address could momentarily select a different subordinate." The pipeline-ownership point and the combinational-decoder reasoning are the senior signals.

10. Practice Challenge

Reason from the hold contract.

1. List the contract. State which signals the manager holds during a wait and what "stable" means precisely.
2. Pipeline ownership. From Figure 2, identify which transfer owns the address bus and which owns the data bus during the wait.
3. Explain the strictness. Why must the held address be bit-stable and glitch-free, not just correct at an edge?
4. Diagnose a glitch. Describe a concrete bug a glitch on the held address could cause in a multi-subordinate system.
5. Verification. State the protocol assertion that checks the hold contract.

11. Key Takeaways

• While HREADY is low, the manager holds the address and the entire control group bit-stable — no change, no glitch — every cycle until HREADY high.
• "Stable" is bit-exact and glitch-free because the decoder is combinational and decodes continuously; a glitch can momentarily select a different subordinate.
• One wait freezes two transfers: the held address belongs to the next transfer (address phase extended); the held write data belongs to the current transfer (data phase extended). Different buses, different transfers.
• The whole control group holds together as a unit (HTRANS, HWRITE, HSIZE, HBURST, HPROT) — they jointly define the transfer and advance together on HREADY high.
• The contract keeps decode and routing stable across the wait — the transfer stays routed to the same subordinate — and is a standard protocol assertion target.
• A glitch on the held address is a real bug, not cosmetic — it can cause a spurious access to a wrong, access-sensitive subordinate.

12. What Comes Next

You now know the address/control hold contract in detail. The next chapter takes the timing view:

• 6.5 — Data Phase Extension (coming next) — how a wait extends the data phase (and the concurrent next address phase) in lockstep, stretching the pipeline uniformly while preserving the address-leads-data relationship.

To revisit the foundations, see Master Behavior During Wait (the general discipline), What HREADY Means, and Slave-Inserted Wait States. For the decode this contract keeps stable, see Address & Control Phase and the two-phase pipeline in The Two-Phase Pipeline. For the broader protocol map, see the AMBA family overview.