Valid Transfer Identification

This is the Critical chapter the whole module has been building toward. Every previous chapter touched it; now we state it precisely: how does a subordinate know it has a real transfer to perform this cycle? The answer is a three-condition rule — HTRANS (NONSEQ or SEQ) AND HSEL AND HREADY, all high on the same cycle. Get this rule right and a subordinate behaves correctly; get it wrong, in any of three ways, and you get one of the classic AHB bugs (phantom accesses, wrong-subordinate responses, mis-timed accesses). This rule is the single most important thing an AHB subordinate designer must internalize, which is why it is rated Critical. It unifies HTRANS (Module 4), HSEL (3.10), and HREADY (3.8).

1. What Is It?

A subordinate has a committed transfer to act on — an access it must actually perform this cycle — only when three conditions hold together:

• HTRANS is a real transfer — NONSEQ or SEQ (not IDLE or BUSY). Is this a real access at all?
• HSEL is high — this subordinate is the one selected by the decoder. Is it for me?
• HREADY is high — the bus is advancing, so the current transfer is completing this cycle. Is it happening now?

All three must be true on the same cycle. If any one is false, there is no committed transfer for this subordinate this cycle, and it must do nothing (respond OKAY).

The essence: a committed transfer is the conjunction of three independent questions — real?, for me?, now? — each answered by one signal. This is the rule a subordinate's access logic must implement, and it is the rule you apply when reading a waveform to find where real accesses happen. The three conditions are independent because they are genuinely different questions, which is why all three are needed and why each, when missing, produces a different kind of bug.

2. Why Does It Exist?

The three-condition rule exists because "should I perform an access this cycle?" genuinely is three independent questions on a pipelined, multi-subordinate, wait-state-capable bus — and a subordinate must answer all three correctly.

Consider each question and why it is needed:

• Real? (HTRANS). The bus has some address and control every cycle, but most cycles are not real transfers — they are IDLE (resting) or BUSY (mid-burst pauses). A subordinate must not act on a non-transfer cycle, or it performs a phantom access on stale signals (chapter 4.2). So it needs HTRANS to know the cycle is a real transfer (NONSEQ/SEQ). This is the activity condition.
• For me? (HSEL). On a shared bus reaching many subordinates, an access is for exactly one of them. A subordinate must not act on an access aimed at a different subordinate, or two subordinates would respond (bus contention). So it needs HSEL to know it is the selected one (chapter 3.10). This is the selection condition.
• Now? (HREADY). Because the bus is pipelined, a real transfer aimed at this subordinate may not be live yet — a previous transfer might still be completing (HREADY low, a wait state). A subordinate must not start its access until the bus has advanced to it, or it acts too early, while the previous transfer is still on the bus (chapter 3.8). So it needs HREADY to know the transfer is completing now. This is the timing condition.

These three are independent — a cycle can be a real transfer (HTRANS) for a different subordinate (HSEL low), or for this subordinate (HSEL) but not yet live (HREADY low), and so on. No single signal captures all three, because they answer different questions about different aspects (activity, selection, timing). So the rule exists as a conjunction of three conditions precisely because correctly identifying a committed transfer requires answering all three independent questions, and each is carried by its own signal. The rule is the minimal, correct way to know "perform an access now" on a bus with non-transfer cycles, multiple subordinates, and wait states — which is exactly what AHB is.

3. Mental Model

Model the rule as three locks on a door that must all be open to enter.

A subordinate's "perform the access" door has three locks, each opened by a different key:

• The activity lock (HTRANS): opens only on a real transfer (NONSEQ/SEQ). On IDLE/BUSY it stays locked — no real access.
• The selection lock (HSEL): opens only when this subordinate is selected. For an access aimed elsewhere, it stays locked.
• The timing lock (HREADY): opens only when the bus is advancing (HREADY high). During a wait state (HREADY low), it stays locked.

The door opens — the subordinate performs the access — only when all three locks are open at once. If even one is locked, the door stays shut and the subordinate does nothing. Three independent locks, all required.

Watch a transfer become committed only when all three align:

The model's lesson: three locks, all must be open. In the waveform, T1 has two conditions (real, selected) but not the third (HREADY low) — so it is not committed, even though it looks like a transfer aimed at B. Only T2, with all three, is committed. Reading the "committed?" row, you see a real access happens only at the conjunction. This is the rule that separates "an access is being attempted" from "this subordinate performs it now."

4. Real Hardware Perspective

In hardware, the rule is a subordinate's access-enable logic, and each condition guards against a specific failure.

A correct subordinate computes its access-enable as the AND of the three conditions: roughly, access_enable = (HTRANS is NONSEQ or SEQ) AND HSEL AND HREADY. When this is true, the subordinate performs the access (reads or writes, drives the response); otherwise it does nothing and responds OKAY. This single AND condition is the heart of correct subordinate design — it is small, cheap logic, but it must be exactly right, because each term guards against a distinct bug:

• Omitting the HTRANS term → the subordinate acts on IDLE/BUSY cycles → phantom accesses (chapter 4.2), catastrophic on side-effect registers.
• Omitting the HSEL term → the subordinate acts on accesses aimed at other subordinates → it responds when it should be silent, contending on the read-data and HREADY paths.
• Omitting the HREADY term → the subordinate acts while a previous transfer is still completing (HREADY low) → it starts too early, mis-timing its access relative to the pipeline (chapter 3.8) — the "works alone, breaks next to a slow peer" bug.

A crucial hardware subtlety is which HREADY a subordinate samples. As covered in chapter 3.8, a subordinate watches the shared HREADY input (the bus-wide one, formed from the selected subordinate's HREADYOUT) to know when the bus advances — it does not just use its own HREADYOUT. So the HREADY term in the access-enable is the incoming, shared HREADY, which is what correctly aligns the subordinate to the pipeline regardless of which subordinate (possibly a different, slow one) was stalling. This is exactly the qualification rule from 3.8, now placed in the committed-transfer conjunction.

So in hardware, the committed-transfer rule is a three-term AND on the access-enable, sampling the shared HREADY, and getting all three terms right is the difference between a correct subordinate and one with phantom-access, wrong-responder, or mis-timing bugs. The logic is trivial; the correctness is essential.

5. System Architecture Perspective

At the system level, the committed-transfer rule is the correctness contract every subordinate must satisfy, and it is what verification and protocol checkers enforce.

For a multi-subordinate AHB system to work, every subordinate must implement the three-condition rule correctly. If even one subordinate gets it wrong — acts on IDLE, acts when not selected, or acts before HREADY — it misbehaves in ways that corrupt the shared bus or its own state, often intermittently and hard to localize. So the rule is not just per-subordinate correctness; it is a system invariant: all subordinates qualify their accesses identically, which is what lets them compose on one pipelined, multi-subordinate bus. The rule is the shared discipline that makes the system coherent.

This is why protocol checkers and verification environments key off exactly this rule. A bus monitor verifies, for each subordinate, that it performs an access only on a committed transfer (HTRANS real, HSEL high, HREADY high) and never otherwise — flagging any access on an IDLE/BUSY cycle (phantom access), any response when not selected (wrong responder), or any action during a wait state (mis-timing). So the committed-transfer rule is the formal property that subordinate verification checks; it is the spec against which correctness is measured. A subordinate that passes "never acts except on a committed transfer" is correct on this axis; one that fails has one of the three bug classes.

The rule also underpins the throughput accounting from chapter 4.6: a productive cycle (one that moves data) is exactly a committed transfer completing — the same three conditions. So the committed-transfer rule is simultaneously the correctness rule (act only when committed) and the productivity rule (data moves only on committed transfers). This dual role makes it the single most important rule in the transfer-type module: it defines both when a subordinate should act and when the bus is actually doing work. Master it and both the correctness and the performance of an AHB subsystem become legible.

So at the system level, the committed-transfer rule is the universal subordinate correctness contract, the property verification enforces, and the definition of a productive cycle — the synthesis of HTRANS, HSEL, and HREADY into the one rule that governs AHB subordinate behaviour.

6. Engineering Tradeoffs

This rule is about correctness, so the "tradeoffs" are really about why it takes the form it does.

• Three conditions vs a single 'valid' bit. AHB requires three signals (HTRANS, HSEL, HREADY) to identify a committed transfer rather than one combined "valid" bit. This is more for a subordinate to check, but each condition is genuinely independent (real? for me? now?) and carries information the others do not — a single bit could not distinguish the non-committed cases (idle vs not-selected vs wait), losing the diagnostic value. The three-condition rule is the minimal correct set, not redundancy.
• Subordinate-side qualification vs centralized. Each subordinate independently checks the three conditions, rather than a central block telling each "act now." This keeps subordinates self-contained and composable (a subordinate works in any system because it qualifies locally), at the cost of every subordinate needing the qualification logic. The local approach is the right one — it is what makes subordinates reusable.
• Sampling shared HREADY vs own HREADYOUT. The rule uses the incoming shared HREADY, not the subordinate's own HREADYOUT, so the subordinate aligns to the bus's advance (which may be gated by a different subordinate). This is essential for multi-subordinate correctness (3.8) — using its own HREADYOUT would break it next to a slow peer. The shared-HREADY choice is mandatory, not optional.
• Strict conjunction vs lenient. Requiring all three strictly (no shortcuts) is what guarantees correctness; any leniency (e.g., acting on HTRANS+HSEL without HREADY) reintroduces a bug class. There is no beneficial leniency here — the strict three-way AND is simply correct, and weakening it is a bug.

The throughline: the committed-transfer rule is the minimal, strict, locally-checked conjunction that correctly identifies when a subordinate should act on a pipelined, multi-subordinate, wait-state-capable bus. Its form is dictated by correctness — three independent questions, each needing its signal, all required, sampled correctly. There is no real tradeoff to tune; there is only getting it right.

7. Industry Example

Trace the committed-transfer rule through a multi-subordinate scenario, and the bugs from violating it.

A system has a fast SRAM (A) and a slow peripheral (B) on one AHB, with a processor accessing both.

• A correct committed transfer. The processor accesses SRAM A: HTRANS = NONSEQ (real), HSEL_A high (A selected), and HREADY high (bus advancing). All three conditions hold for A, so A performs the access. This is the rule working: A acts because, and only because, all three are true.
• Not committed — wrong subordinate (HSEL). During A's access, peripheral B sees the same HTRANS = NONSEQ and HREADY high, but HSEL_B is low (the access is for A, not B). B correctly does nothing — the HSEL condition fails for B. If B were buggy and ignored HSEL, it would respond to A's access too, contending on the bus. The HSEL term prevents this.
• Not committed — wait state (HREADY). The processor then accesses slow peripheral B: HTRANS real, HSEL_B high — but B inserts a wait state, so HREADY is low for a cycle. During that cycle the transfer is not committed (HREADY low); B must not complete the access yet. Meanwhile, if the next access (aimed at A) has its address phase on the bus, A sees HTRANS real and HSEL_A high but HREADY low — so A must wait, not act. The HREADY term keeps A correctly aligned: it acts only when the bus advances (HREADY high), not while B is still stalling. This is the "works alone, breaks next to a slow peer" scenario — A is correct because it requires HREADY.
• Not committed — non-transfer (HTRANS). Between accesses, the processor drives IDLE. Both A and B see IDLE; HTRANS is not a real transfer, so neither acts (the HTRANS condition fails). If either ignored HTRANS, it would phantom-access on the idle cycle. The HTRANS term prevents this.
• The unified view. Every subordinate, every cycle, applies the same rule: act only when real, selected, and advancing. A acts on its committed cycles; B acts on its committed cycles (after its wait states); neither acts otherwise. The three conditions, checked by each subordinate, make the multi-subordinate system correct.

The scenario shows all three conditions doing their job — HTRANS preventing phantom accesses, HSEL preventing wrong-responder contention, HREADY preventing mis-timing next to a slow peer — and the rule unifying them into correct subordinate behaviour.

8. Common Mistakes

9. Interview Insight

This is one of the most important AHB interview questions: how a subordinate knows it has a real transfer.

The answer that lands states the three-condition rule and the questions it answers: "A subordinate performs an access only when three conditions hold on the same cycle: HTRANS is a real transfer — NONSEQ or SEQ — so it's a genuine access; HSEL is high, so the access is for this subordinate; and HREADY is high, so the bus is advancing and the transfer is completing now. Real, for me, now. Crucially the HREADY is the shared incoming one, so the subordinate aligns to the pipeline even when another subordinate is stalling. And each missing condition is a distinct bug — dropping HTRANS gives phantom accesses, dropping HSEL gives wrong-subordinate responses, dropping HREADY gives mis-timed accesses." The three-condition conjunction, the shared-HREADY point, and the per-condition bug mapping are the senior signals.

10. Practice Challenge

Reason from the three-condition conjunction.

1. State the rule. Give the three conditions for a committed transfer and the question each answers.
2. Read the waveform. From Figure 2, identify the committed cycle and explain why the others are not committed.
3. Map the bugs. For each omitted condition (HTRANS, HSEL, HREADY), name the resulting bug.
4. Pick the HREADY. Explain why the rule uses the shared incoming HREADY, not the subordinate's own HREADYOUT.
5. Diagnose integration failure. A subordinate works alone but corrupts next to a slow peer. Name the likely missing condition and the fix.

11. Key Takeaways

• A committed transfer requires HTRANS (NONSEQ/SEQ) AND HSEL AND HREADY, all high on the same cycle — real, for me, now. This is the master rule of AHB subordinate design.
• The three conditions are independent questions — activity (HTRANS), selection (HSEL), timing (HREADY) — each carried by its own signal, all required.
• The HREADY used is the shared incoming one, so the subordinate aligns to the bus's advance even when another subordinate is stalling — not its own HREADYOUT.
• Each missing condition is a distinct bug: drop HTRANS → phantom accesses; drop HSEL → wrong-subordinate responses; drop HREADY → mis-timed accesses (breaks next to a slow peer).
• The rule is a system invariant — every subordinate must satisfy it for the multi-subordinate bus to be correct, and it is exactly what protocol checkers verify.
• It also defines a productive cycle — data moves only on a committed transfer — unifying correctness and throughput. This is the most important rule in the module.

12. What Comes Next

You now have the central rule of subordinate behaviour. The final Module 4 chapter catalogues what goes wrong when it (and the transfer types) are mishandled:

• 4.8 — Common HTRANS Bugs (coming next) — the classic transfer-type mistakes (missing IDLE handling, wrong SEQ/NONSEQ, ignoring the committed-transfer rule) and how to catch them, closing the module.

To revisit the signals this rule combines, see HTRANS, HSEL, and HREADY & HREADYOUT; for how it defines productive cycles, see How HTRANS Controls Bus Activity. For the broader protocol map, see the AMBA family overview.