Common HTRANS Bugs

This closes Module 4 by gathering the transfer-type mistakes scattered through the previous chapters into one catalogue. HTRANS is simple to encode and easy to misuse, and the misuses are consequential — phantom accesses that corrupt side-effect registers, bursts that silently restart, subordinates that work alone but break in a system. We organize the bugs into two families: subordinate (access) bugs, which all stem from a weak access check and share one fix (the committed-transfer rule from 4.7), and master (type) bugs, which come from driving the wrong transfer type or violating burst constraints. For each, we give the cause, the symptom, and the fix — turning the module's lessons into a debugging checklist.

1. What Is It?

The common HTRANS bugs fall into two families:

Subordinate (access) bugs — a subordinate performs an access when it should not, because it does not properly check the committed-transfer rule (HTRANS + HSEL + HREADY, chapter 4.7):

• Acting on IDLE/BUSY (missing the HTRANS check) → phantom accesses.
• Acting when not selected (missing the HSEL check) → wrong-subordinate responses.
• Acting during a wait state (missing the HREADY check) → mis-timed accesses.
• Erroring on IDLE/BUSY → spurious errors (a non-transfer must respond OKAY).

Master (type) bugs — a master drives the wrong transfer type or violates a burst rule:

• IDLE instead of BUSY to pause mid-burst → abandoned bursts (costly restarts).
• First beat as SEQ (no preceding NONSEQ) → burst never properly started.
• Off-pattern SEQ address → broken burst (defeats prefetch, corrupts).
• Control change mid-burst (HSIZE/HWRITE/HBURST changes) → corrupted access.

The useful organizing insight: the subordinate access bugs share a single fix — require the full committed-transfer rule before acting — while the master type bugs are each about driving the correct transfer type and respecting burst constraints (constant control, pattern addresses, NONSEQ-then-SEQ ordering). So this catalogue is really two checklists: one for subordinate access logic, one for master transfer-type generation.

2. Why Does It Exist? (Why these bugs are common)

These bugs are common because the transfer types are simple to encode but require discipline to use, and the discipline is easy to skip in ways that pass minimal testing.

The subordinate access bugs are common because the naive implementation — "decode the address, perform the access" — almost works. In a minimal test (single subordinate, no wait states, mostly real transfers), a subordinate that just decodes the address may appear correct. The committed-transfer conditions it skipped (HTRANS, HSEL, HREADY) only bite when the full system exercises them: IDLE cycles (frequent in real traffic), accesses to other subordinates (multi-subordinate systems), and wait states (slow peers). So these bugs hide in isolation and surface on integration — the "works alone, breaks in the system" pattern. They are common precisely because the missing checks are invisible until the right conditions occur.

The master type bugs are common because driving the correct transfer type each cycle requires tracking burst state, and it is easy to get a corner case wrong. Pausing mid-burst correctly (BUSY, not IDLE) requires knowing you are in a burst; marking the first beat NONSEQ and continuations SEQ requires tracking burst position; keeping control constant and addresses on-pattern requires holding burst parameters. A master that mis-tracks its burst state drives the wrong type — IDLE when it meant BUSY, or SEQ for a first beat. These are common because burst state management has corner cases (underruns, boundaries, restarts) that are easy to mishandle.

So the bugs exist because the transfer-type encoding is trivial but the correct usage — the committed-transfer rule on the subordinate side, correct type generation on the master side — requires discipline that is easy to omit and whose omission is easy to miss in testing. This catalogue exists to make the discipline explicit and the bugs recognizable, so they are caught in design and verification rather than discovered in integration or the field.

3. Mental Model

Model the bugs as two kinds of misreading a conversation: the listener (subordinate) responding when not addressed, and the speaker (master) saying the wrong thing.

A listener bug is responding inappropriately: answering when someone else was addressed (acting when not selected), answering to silence (acting on IDLE), or answering before the speaker finished (acting during a wait state). The fix is the same for all: listen for the full cue before responding — only respond when it is a real statement (HTRANS), directed at you (HSEL), and finished (HREADY). That full cue is the committed-transfer rule.

A speaker bug is saying the wrong thing: pausing by going silent (IDLE) when you meant to hold your turn (BUSY), so the listener thinks you are done; starting mid-sentence as if continuing (first-beat SEQ); or changing the subject mid-sentence (control change mid-burst). The fix is to speak correctly: use the right pause (BUSY in a burst), start properly (NONSEQ), and keep the sentence consistent (constant control, pattern address).

Watch a phantom-access bug versus correct behaviour:

The model's lesson: listener bugs are responding when you shouldn't (fix: require the full cue); speaker bugs are saying the wrong thing (fix: speak correctly). The waveform shows the listener bug — the buggy subordinate "acts" on IDLE cycles where the correct one stays silent. The fix is requiring HTRANS (and HSEL, HREADY) before acting.

4. Real Hardware Perspective

In hardware, the subordinate bugs trace to a too-weak access-enable, and the master bugs to mis-managed burst state — and both have clean fixes.

The subordinate access bugs all come from the access-enable being too weak — gating on "address matches" or a subset of conditions instead of the full conjunction. The fix is a single change: make the access-enable HTRANS (NONSEQ/SEQ) AND HSEL AND HREADY, sampling the shared HREADY. This one correct enable eliminates phantom accesses (HTRANS term), wrong-responder contention (HSEL term), and mis-timing (HREADY term) together. So in hardware, the four subordinate access bugs share one root cause (weak enable) and one fix (the committed-transfer rule) — which is why 4.7 is the keystone chapter. The spurious-error-on-IDLE bug is a related variant: the subordinate must respond OKAY (not ERROR) on non-transfer cycles, which falls out of correctly not treating IDLE/BUSY as accesses.

The master type bugs come from burst-state mismanagement, and each has a specific fix:

• IDLE instead of BUSY: the master must track whether it is in a burst and drive BUSY (not IDLE) to pause within one. Fix: a burst-active state that selects BUSY for mid-burst pauses.
• First beat as SEQ: the master must drive NONSEQ for a burst's first beat and SEQ only for continuations. Fix: a beat counter that drives NONSEQ on beat 0, SEQ thereafter.
• Off-pattern SEQ address: the master's address generator must follow the burst pattern (increment by beat size, or wrap). Fix: a correct address counter respecting the burst type and the 1 KB boundary.
• Control change mid-burst: the master must hold HWRITE/HSIZE/HBURST/HPROT constant for the burst. Fix: register the burst parameters at the NONSEQ and hold them.

So in hardware, the master bugs are about correct burst-state machinery (a burst-active flag, a beat counter, an address counter, held parameters). They are not exotic — they are standard burst-generation logic — but corner cases (underruns triggering pauses, bursts hitting boundaries) are where they go wrong. The fix in each case is correct state tracking.

The unifying hardware view: subordinate bugs = weak access-enable (one fix); master bugs = mis-managed burst state (per-bug fixes in standard burst logic). Both are caught by verification that exercises the full conditions — idle cycles, multiple subordinates, wait states, bursts with pauses and boundaries.

5. System Architecture Perspective

At the system level, these bugs are what verification and protocol checkers are built to catch, and recognizing them is core to debugging real AHB systems.

A protocol checker monitoring the bus encodes exactly these bugs as assertions: it flags any subordinate that acts on a non-committed cycle (phantom access, wrong responder, mis-timing), any ERROR on an IDLE/BUSY, any SEQ without a preceding NONSEQ, any off-pattern SEQ address, and any control change mid-burst. So this catalogue is, in effect, the checklist a protocol checker implements. Running such a checker in simulation (and sometimes in emulation) catches these bugs before silicon — which matters because several of them (phantom accesses on side-effect registers, mis-timing next to slow peers) are intermittent and field-elusive if they escape. The system-level value of this catalogue is that it defines what to assert.

For debugging, the catalogue is a symptom-to-cause map. When a real system misbehaves, the symptom often points at a transfer-type bug: side-effect registers changing when the bus is quiet → phantom access on IDLE; a subordinate works alone but corrupts in the system → missing HSEL or HREADY check; bursts keep restarting under load → IDLE-instead-of-BUSY; burst data corrupts tracking the burst shape → control change mid-burst or off-pattern SEQ. So an engineer who knows this catalogue can go from symptom to likely cause quickly, then confirm by checking the relevant logic (the subordinate's access-enable, or the master's burst-state machinery). This symptom-to-cause fluency is exactly what makes transfer-type debugging fast.

The catalogue also reinforces the test-the-full-conditions lesson at the system level: because these bugs hide in minimal tests and surface only under the full conditions (idle cycles, multiple subordinates, wait states, bursts with pauses and boundaries), verification must exercise those conditions. A test suite that only does back-to-back real transfers to a single subordinate will miss most of them. So the system-level takeaway is to verify under realistic conditions — idle traffic, multi-subordinate configurations, stalling peers, bursts that pause and cross boundaries — which is where these bugs live. The catalogue tells you which conditions to create.

So at the system level, the common HTRANS bugs define the protocol checker's assertions, provide a symptom-to-cause debugging map, and dictate that verification exercise the full bus conditions. Knowing them is what turns the transfer-type knowledge of this module into the practical ability to prevent, catch, and fix real bugs.

6. Engineering Tradeoffs

This chapter is about avoiding bugs, so the "tradeoffs" are about prevention effort versus risk.

• Correct access-enable vs minimal logic. The full committed-transfer conjunction is slightly more logic than a weak address-only check, but it prevents three bug classes. There is no real tradeoff — the extra logic is trivial and the bugs are severe. Always implement the full rule.
• Correct burst-state machinery vs simpler masters. Proper burst generation (burst-active flag, beat counter, address counter, held parameters) is more than a naive master, but it is standard, necessary logic for correct bursts. Skipping it to simplify the master causes the master type bugs. The machinery is required, not optional.
• Thorough verification vs minimal tests. Exercising the full conditions (idle, multi-subordinate, wait states, bursts with pauses/boundaries) costs more verification effort than minimal tests, but it is the only way to catch these bugs before integration or the field. Given that several are intermittent and field-elusive, the verification investment is clearly worth it. Minimal testing is a false economy.
• Protocol checker vs hand-checking. Running a protocol checker (asserting the committed-transfer rule and burst constraints) costs setup but automates catching the whole catalogue, far more reliably than manual waveform inspection. For any non-trivial AHB system, the checker is the right investment.

The throughline: preventing these bugs costs modest, standard effort (correct access-enable, correct burst logic, thorough verification with a protocol checker), and the cost of not preventing them is severe (corrupted state, intermittent field failures, hard-to-localize integration bugs). There is essentially no case for cutting these corners — the catalogue exists to make the small upfront discipline obvious and the consequences of skipping it concrete.

7. Industry Example

Trace two real debugging sessions using the catalogue.

Session 1: side-effect registers corrupting (a subordinate bug). A peripheral's clear-on-read status register keeps clearing and its FIFO loses data, seemingly at random, when the bus should be quiet. Using the catalogue: phantom activity when the bus is quiet → the subordinate is acting on IDLE cycles. The engineer checks the peripheral's access-enable and finds it gates on "address matches" without checking HTRANS. On the frequent IDLE cycles, the stale address points at the peripheral, and it phantom-reads — clearing status and popping the FIFO. The fix is to add the HTRANS (and HSEL, HREADY) check — the committed-transfer rule. After the fix, the peripheral acts only on committed transfers, and the corruption stops. This is the most common and most damaging subordinate bug, caught by recognizing the phantom-access symptom.

Session 2: a DMA's bursts restarting (a master bug). A DMA's throughput is far below expected, and a capture shows its bursts constantly restarting — SEQ…, IDLE, NONSEQ, SEQ… repeatedly. Using the catalogue: bursts keep restarting under load → IDLE-instead-of-BUSY. The engineer checks the DMA's transfer-type generation and finds that on a FIFO underrun mid-burst, it drives IDLE instead of BUSY — abandoning the burst and forcing a restart on every underrun. The fix is to drive BUSY (not IDLE) for mid-burst pauses, keeping the burst alive. After the fix, the captures show SEQ…, BUSY, SEQ… — one burst with pauses — and throughput recovers. This is the classic master burst bug, caught by recognizing the restart pattern on the HTRANS track.

The common thread. In both, the symptom pointed (via the catalogue) at a transfer-type cause, and the fix was in the relevant logic — the subordinate's access-enable (Session 1) or the master's burst-state generation (Session 2). The engineer did not flail; they matched the symptom to the catalogue, inspected the named logic, and applied the known fix. This symptom-to-cause-to-fix flow is exactly what knowing the common bugs gives you — and it is why a debugging catalogue is a fitting close to the transfer-type module.

8. Common Mistakes

9. Interview Insight

Bug questions test whether you can connect symptoms to transfer-type causes — the mark of real debugging experience.

The answer that lands organizes the bugs into the two families and gives the fixes: "There are two families. Subordinate access bugs — acting on IDLE (phantom access), acting when not selected (wrong responder), acting during a wait state (mis-timing) — all come from a weak access check and share one fix: require the full committed-transfer rule, HTRANS real AND HSEL AND HREADY. Master type bugs — using IDLE instead of BUSY mid-burst (abandons the burst), first beat as SEQ, off-pattern SEQ addresses, changing control mid-burst — come from mis-managed burst state, fixed by correct type generation and constant control. And the symptom usually names the cause: phantom activity on a quiet bus → IDLE acting; works-alone-breaks-in-system → missing HSEL/HREADY; bursts restarting → IDLE-not-BUSY." The two-family organization and the symptom-to-cause mapping are the senior signals.

10. Practice Challenge

Use the catalogue as a symptom-to-cause map.

1. Classify the families. List the subordinate access bugs and the master type bugs, and state the shared fix for the access bugs.
2. Symptom to cause. For each symptom — side-effect regs corrupting on a quiet bus; works-alone-breaks-in-system; bursts restarting; burst data corrupting by shape — name the likely bug.
3. The one fix. Explain why three subordinate access bugs share the committed-transfer-rule fix.
4. Master burst fixes. For IDLE-not-BUSY, first-beat-SEQ, off-pattern SEQ, and control-change, give the burst-logic fix.
5. Verification plan. List the bus conditions a test suite must exercise to catch these bugs, and why minimal tests miss them.

11. Key Takeaways

• The HTRANS bugs split into two families: subordinate access bugs (acting when not committed) and master type bugs (wrong type or broken burst).
• The subordinate access bugs share one fix — require the full committed-transfer rule (HTRANS NONSEQ/SEQ AND HSEL AND HREADY). This eliminates phantom accesses, wrong-responder contention, and mis-timing together.
• Phantom accesses (acting on IDLE) are the most damaging — they corrupt side-effect registers (clear status, pop FIFOs), not just return garbage.
• The master type bugs come from mis-managed burst state — IDLE-instead-of-BUSY (abandons bursts), first-beat-SEQ, off-pattern SEQ, control change mid-burst — fixed by correct burst generation and constant control.
• Symptoms map to causes: quiet-bus corruption → phantom access; works-alone-breaks-in-system → missing HSEL/HREADY; bursts restarting → IDLE-not-BUSY; shape-tracking corruption → control change or off-pattern SEQ.
• These bugs hide in minimal tests — verify under idle traffic, multiple subordinates, wait states, and bursts with pauses and boundaries, with a protocol checker asserting the committed-transfer rule and burst constraints.

12. What Comes Next

This completes Module 4 — Transfer Types (HTRANS). You now understand each transfer type, how they sequence and control bus activity, the committed-transfer rule, and the bugs that come from getting them wrong. The curriculum continues with the next module applying this foundation.

• Module 5 onward (coming next) — building on the transfer-type and signal foundations into deeper transaction behaviour, multi-master systems, bridges, the bus matrix, and the design and verification practice that follows.

To revisit the rule whose violations this chapter catalogues, see Valid Transfer Identification; for the types and behaviours involved, see Transfer Types Overview, IDLE Transfers, BUSY Transfers, and How HTRANS Controls Bus Activity. For the broader protocol map, see the AMBA family overview.