How HTRANS Controls Bus Activity

The previous chapters examined each transfer type individually. This chapter ties them together by answering a single practical question: does real work happen this cycle, and what decides it? The answer is HTRANS — it is, in effect, the bus's activity enable. NONSEQ and SEQ cause a committed access (the subordinate does work); IDLE and BUSY cause none (the subordinate responds OKAY but does nothing). Combined with HREADY, HTRANS also governs whether the pipeline advances. Understanding HTRANS as the activity control is what lets you read a waveform and see, cycle by cycle, where the bus is actually moving data — and where BUSY and wait states are eating into throughput. This synthesizes 4.2–4.5.

1. What Is It?

HTRANS acts as the activity enable of the bus: the transfer type each cycle determines whether real work happens.

The activity per type:

• NONSEQ and SEQ are real transfers — when committed (qualified by HSEL and HREADY, chapter 4.7), a genuine access happens and the subordinate does work (reads or writes data). The response can be OKAY or ERROR.
• IDLE and BUSY are non-transfers — no access happens and the subordinate does no work, responding OKAY only. (IDLE is not in a burst; BUSY keeps a burst alive.)

So HTRANS divides cycles into work (NONSEQ/SEQ) and no-work (IDLE/BUSY). This is the unifying view of the transfer types: rather than four separate things to memorize, they are two work-cycles (start and continue) and two no-work-cycles (idle and pause). The subordinate uses HTRANS as the enable: act on a real transfer, do nothing on a non-transfer. And throughput — how much data actually moves — is the count of work-cycles, which is why IDLE and BUSY (and, separately, wait states) reduce a burst's effective rate.

2. Why Does It Exist?

The activity-control role of HTRANS exists because a subordinate must know, every cycle, whether to do work — and inferring that from other signals would be ambiguous and error-prone.

A subordinate sitting on the bus sees address, control, and data lines every cycle, but most cycles it should do nothing — the bus is idle, or paused, or the access is for a different subordinate. It needs an explicit, unambiguous signal that says "this cycle, perform a real access" versus "this cycle, do nothing." HTRANS provides exactly that: NONSEQ/SEQ mean "real work" and IDLE/BUSY mean "no work." Without this explicit activity enable, a subordinate would have to guess whether a cycle is real — from the address changing, or from some heuristic — which is precisely the ambiguity that causes phantom accesses (chapter 4.2). So HTRANS-as-activity-enable exists to make "do work or not" an explicit, reliable decision.

The reason HTRANS alone is not the whole story — why it combines with HSEL and HREADY — is that "real work" has three independent conditions: the cycle must be a real transfer type (HTRANS NONSEQ/SEQ), the access must be for this subordinate (HSEL), and the bus must be advancing to this access (HREADY high). HTRANS answers "is this a real transfer at all?"; HSEL answers "is it for me?"; HREADY answers "is it happening now?". All three are needed because they are genuinely separate questions (chapter 4.7 develops the combined rule). HTRANS exists to answer the first — the activity question — which the other two then refine to "committed to me, now."

The activity-control framing also exists because it directly explains throughput. The bus moves data only on work-cycles (committed NONSEQ/SEQ with the bus advancing). Every IDLE, every BUSY, and every wait state is a non-work cycle that does not move data. So a burst's effective throughput is the fraction of its cycles that are productive work — and understanding HTRANS as the activity enable is what lets you see, and minimize, the non-work cycles. This is why the activity view matters for performance, not just correctness: it is the lens through which you count where data actually moves.

3. Mental Model

Model HTRANS as a factory line's "production" versus "no-op" signal at each station.

A factory line (the bus) ticks every cycle, but not every tick produces a part. A control signal at each station says "produce" (NONSEQ/SEQ — do real work this tick) or "no-op" (IDLE/BUSY — this tick, do nothing). The station (subordinate) watches the signal: on "produce" it does its work; on "no-op" it idles cleanly. Separately, a line-advance signal (HREADY) says whether the line moves forward this tick — if a station is still finishing (a wait state), the whole line holds. So productivity is the count of ticks that are both "produce" and "advancing." No-op ticks (IDLE/BUSY) and held ticks (wait states) are non-productive.

Watch HTRANS gate activity across a session:

The model's lesson: HTRANS is the produce/no-op signal — it decides which ticks do real work — and HREADY decides which ticks advance. In the waveform, the "work?" row follows HTRANS (yes on NONSEQ/SEQ, no on IDLE/BUSY); reading it tells you exactly where the bus is moving data. The non-work cycles (the BUSY here, plus the IDLEs) are where throughput is lost.

4. Real Hardware Perspective

In hardware, HTRANS-as-activity-enable shows up as the condition that gates a subordinate's access logic, working together with HSEL and HREADY.

A correct subordinate computes an access-enable roughly as: HTRANS is a real transfer (NONSEQ or SEQ) AND HSEL asserted (this subordinate is selected) AND HREADY high (the bus is advancing to this access). When all three hold, the subordinate performs the access; otherwise it does nothing. HTRANS is the activity term of this enable — it is what makes IDLE and BUSY cycles produce no access regardless of the address. So in hardware, HTRANS gating is one input to the access-enable, and getting it wrong (omitting the HTRANS check) is the phantom-access bug from chapter 4.2.

The interaction with HREADY is the second half of activity control. HTRANS decides whether a cycle is a real transfer; HREADY decides whether the pipeline advances. On a committed real transfer, the access completes — and the pipeline advances — only when HREADY is high. If HREADY is low (a wait state), the real transfer is held: the work is happening but not yet complete, and the pipeline does not advance. So a productive cycle requires both a real transfer type (HTRANS) and the bus advancing (HREADY high). A real transfer stalled by wait states is "work in progress but not completing," which is why wait states reduce throughput even on NONSEQ/SEQ cycles.

This gives a clean hardware picture of throughput: data moves on cycles that are committed real transfers completing this cycle — NONSEQ/SEQ, HSEL high, HREADY high. Every other cycle moves no data: IDLE (no transfer), BUSY (master pause), wait states (HREADY low, real transfer not completing), and accesses to other subordinates (HSEL low for this one). So a subordinate's or a burst's effective throughput is the count of these productive cycles, and the non-productive cycles fall into named categories (idle, master-pause, subordinate-wait, not-selected) that tell you why a cycle was unproductive. This categorization is the basis for performance debugging: count the non-work cycles and attribute them.

5. System Architecture Perspective

At the system level, the activity-control view of HTRANS is the foundation of throughput analysis and performance debugging.

A system's bus throughput is, fundamentally, how many cycles carry productive work. Using the activity view, you can decompose any window of bus time into productive cycles (committed transfers completing) and non-productive cycles, and the non-productive ones into named categories: IDLE (master had nothing to do), BUSY (master paused mid-burst, e.g. FIFO underrun), wait states (subordinate too slow), and not-selected (the bus was serving someone else). This decomposition is exactly what a performance engineer needs: it turns "the bus is slow" into a quantified attribution — this fraction was idle, this fraction was BUSY, this fraction was wait states — which points directly at the fix (feed the master better, speed up the subordinate, reduce contention).

The activity view also clarifies the two-ended nature of burst slowdown (from chapters 3.8 and 4.3). A burst's beats are productive only when they are committed real transfers completing. They become non-productive from the master side (BUSY — the master not ready) or the subordinate side (wait states — the subordinate not ready). So the activity view gives a unified accounting: a burst's lost throughput is BUSY cycles (blame the master's data supply) plus wait-state cycles (blame the subordinate's speed). Attributing the non-work cycles to the right end is the diagnostic payoff — and it comes directly from reading HTRANS (for BUSY) and HREADY (for wait states) alongside the work-cycles.

This is why HTRANS is central to bus monitors and protocol analyzers. They key off HTRANS to classify every cycle, compute throughput (work-cycle count), and flag both correctness issues (a subordinate acting on a non-work cycle — phantom access) and performance issues (excessive BUSY or wait states reducing throughput). So the activity-control role of HTRANS is not just a teaching framing; it is the operational basis for how AHB performance and correctness are measured in practice. An engineer reading a capture is applying the activity view: which cycles did work, which did not, and why.

So at the system level, HTRANS-as-activity-enable underpins throughput measurement, the attribution of lost cycles to named causes, the two-ended view of burst slowdown, and the operation of the tools that analyze AHB behaviour. It is the lens that turns the transfer types into a performance and correctness framework.

6. Engineering Tradeoffs

The activity-control design reflects the transfer-type system's choices, viewed through performance.

• Explicit activity enable (HTRANS) vs inferred. Marking work/no-work explicitly via HTRANS lets subordinates reliably gate their access and lets tools cleanly measure throughput, at the cost of the HTRANS signal (already present). Inferring activity would be ambiguous (phantom-access risk) and would make throughput measurement guesswork. Explicit is clearly right.
• Three-condition productivity (HTRANS + HSEL + HREADY) vs simpler. Requiring three signals to define a productive cycle is more than a single "valid" bit, but it cleanly separates the three independent questions (real? for me? now?) and gives precise throughput accounting. A single bit could not distinguish the non-work categories (idle vs not-selected vs wait), losing the diagnostic attribution. The three-condition rule is worth its complexity.
• Allowing non-work cycles (BUSY/IDLE) vs forbidding them. Permitting IDLE and BUSY means the bus can have non-productive cycles (a throughput cost), but they serve essential purposes — IDLE for resting and error-cancel, BUSY for sustaining bursts through underruns. Forbidding them would be impossible (masters genuinely have gaps). The trade is accepting some non-work cycles for the flexibility they provide, with the activity view making their cost visible.
• Visibility vs overhead. Because every cycle is classified by HTRANS, throughput and its losses are fully visible on the bus — a tool can account for every cycle. This visibility costs nothing extra (HTRANS is already there) and is a major benefit for debugging. There is essentially no tradeoff here; the classification is free and the visibility is valuable.

The throughline: the activity-control design makes bus productivity explicit and fully accountable — every cycle is classifiable as work or a named kind of no-work, at no extra cost beyond the HTRANS signal. This is the basis for throughput analysis and performance debugging, and it is one of the quieter virtues of the transfer-type system: it does not just sequence transfers, it makes the bus's productivity measurable.

7. Industry Example

Trace a DMA burst's throughput using the activity view, with both kinds of loss.

A DMA streams a block to memory; we analyze a window of the burst from a capture.

• The productive cycles. Most beats are committed SEQ transfers completing — HTRANS = SEQ, the DMA selected (HSEL high), HREADY high. These are the work-cycles: each moves a beat of data. Counting them gives the burst's actual data movement.
• A BUSY loss (master side). Partway through, the DMA's FIFO underruns, and it drives BUSY for two cycles (chapter 4.3). These are non-work cycles — no data moves — attributable to the master's data supply. In the activity view, they are BUSY non-work cycles; the fix is on the master side (a deeper FIFO, faster upstream feed), not the subordinate or the clock.
• A wait-state loss (subordinate side). Later, the memory needs a wait state on a beat — HTRANS = SEQ but HREADY low for a cycle. This is also a non-work cycle (the real transfer is in progress but not completing), attributable to the subordinate's speed. In the activity view, it is a wait-state non-work cycle; the fix is on the subordinate side (a faster memory, or bridging it).
• The throughput verdict. The burst's effective throughput is the work-cycles divided by the total cycles. The losses decompose cleanly: the BUSY cycles (master) plus the wait-state cycles (subordinate). An engineer reading the capture sees exactly where the throughput went — and crucially, which end to fix. If the BUSY cycles dominate, fix the DMA's feed; if the wait states dominate, fix the memory. The activity view turned a vague "the DMA is slow" into a specific, attributed diagnosis.
• The wrong instinct it prevents. Without the activity view, a tempting "fix" is to raise the clock. But the capture shows the losses are BUSY (master) and wait states (subordinate) — non-work cycles that a faster clock does not remove (it would just make the idle waiting faster). The activity view prevents this misdirected optimization by attributing the losses to their true causes.

The burst analysis shows the activity view's value: counting work-cycles measures throughput, and attributing non-work cycles (BUSY = master, wait state = subordinate) localizes the bottleneck — the everyday use of HTRANS-as-activity-control in performance work.

8. Common Mistakes

9. Interview Insight

This topic tests whether you can reason about throughput from the transfer types and HREADY.

The answer that lands frames HTRANS as the activity enable and connects it to throughput: "HTRANS gates whether real work happens each cycle — NONSEQ and SEQ produce a committed access and the subordinate does work; IDLE and BUSY produce no access, the subordinate just responds OKAY. Whether work happens for a given subordinate now needs all three: a real transfer type, HSEL selected, and HREADY high. And throughput is the count of those productive cycles — so IDLE, BUSY, and wait states are non-work cycles that reduce a burst's effective rate. To analyze a slow bus, I'd count the work-cycles and attribute the rest: BUSY to the master's data supply, wait states to the subordinate's speed." The throughput-as-work-cycle-count framing and the attribution of losses are the senior signals.

10. Practice Challenge

Reason from the work/no-work classification and throughput.

1. Classify the cycles. For each transfer type, state whether real work happens and what the subordinate does.
2. State the productivity rule. Give the three-condition rule for a cycle that moves data.
3. Read the waveform. From Figure 2, mark which cycles do real work and which do not, and why.
4. Decompose throughput. Given a burst window, list the categories of non-work cycles and what each is attributed to.
5. Avoid the wrong fix. A burst is slow; the capture shows mostly BUSY and wait-state losses. Explain why a faster clock will not help and what will.

11. Key Takeaways

• HTRANS is the bus's activity enable: NONSEQ/SEQ produce a committed access and subordinate work; IDLE/BUSY produce no access and no work (OKAY only).
• A cycle moves data only when three conditions hold: real transfer type (HTRANS NONSEQ/SEQ), selected (HSEL high), and advancing (HREADY high). HTRANS is the activity term of this rule.
• HTRANS gates whether there is work; HREADY gates when the pipeline advances — both are needed for a productive cycle.
• Throughput is the count of productive work-cycles — IDLE, BUSY, wait states, and not-selected cycles are non-work and reduce a burst's effective rate.
• Non-work cycles attribute to named causes: IDLE (master idle), BUSY (master pause — fix the feed), wait states (subordinate slow — fix the subordinate), not-selected (contention — fix routing).
• The activity view is the basis of throughput analysis and performance debugging — decompose a capture's cycles before optimizing, and fix the right end rather than reflexively raising the clock.

12. What Comes Next

You now understand how HTRANS governs bus activity. The remaining Module 4 chapters formalize the committed-transfer rule and catalogue the bugs:

• 4.7 — Valid Transfer Identification (coming next) — the precise rule for recognizing a committed transfer (HTRANS + HSEL + HREADY), which this chapter has been building toward.
• 4.8 — Common HTRANS Bugs (coming soon) — the classic transfer-type mistakes and how to catch them.

To revisit the types this chapter unifies, see IDLE Transfers, BUSY Transfers, NONSEQ Transfers, and SEQ Transfers; for the HREADY and HSEL that combine with HTRANS, see HREADY & HREADYOUT and HSEL. For the broader protocol map, see the AMBA family overview.