Wrong HTRANS

After the catastrophic stuck HREADY (18.1), this chapter covers a subtler but common bug: a wrong HTRANS. HTRANS encodes the transfer type — IDLE (no transfer), BUSY (a pause within a burst), NONSEQ (the first beat of a burst, or a single transfer), SEQ (a continuing beat of a burst) — and its sequencing must follow legal rules. A wrong HTRANS is an illegal value for the burst position — and unlike a stuck HREADY (which announces itself by hanging), a wrong HTRANS is quieter: it causes the slave to restart, mis-track the burst, or access the wrong address — downstream data/addressing errors without an obvious freeze. The legal rules: a burst begins with NONSEQ (first beat), then SEQ for the remaining beats; BUSY may be inserted between beats to pause, after which the burst resumes with SEQ; IDLE appears between unrelated transfers. The common violations: a NONSEQ mid-burst (wrongly restarting the burst instead of continuing with SEQ), a SEQ with no preceding NONSEQ (a continuing beat with nothing to continue), an IDLE mid-burst (breaking the burst instead of using BUSY to pause), and a BUSY outside a burst (meaningless). To debug, track the burst position and compare the actual HTRANS against the legal value for that position; the cause is almost always the master's HTRANS generation (or a beat-tracking bug). This chapter builds the diagnosis.

1. What Is It?

Wrong HTRANS is an illegal transfer-type sequence; debugging it means comparing the actual HTRANS against the legal value for the burst position. Its parts:

• The four values — IDLE (no transfer), BUSY (pause within a burst), NONSEQ (burst start / single), SEQ (continuing burst beat).
• The legal rules — burst = NONSEQ then SEQ; BUSY pauses within a burst (resume with SEQ); IDLE between bursts.
• The common violations — NONSEQ mid-burst (restarts), SEQ with no NONSEQ (orphan), IDLE mid-burst (breaks the burst), BUSY outside a burst.
• The diagnosis — track the burst position and compare HTRANS against the legal value; the cause is the master's HTRANS generation / beat-tracking.

So wrong HTRANS is a sequencing bug — an HTRANS value that's illegal for where the transfer is in a burst. The key to debugging it is recognizing that HTRANS's legality is contextual: the same value can be legal or illegal depending on the burst position. A NONSEQ is legal at a burst start but illegal mid-burst (where SEQ is required); a SEQ is legal continuing a burst but illegal with no preceding NONSEQ; an IDLE is legal between bursts but illegal within one (where BUSY is the pause). So you can't judge HTRANS in isolation — you must track the burst position (which beat? is a burst in progress?) and compare the HTRANS against the legal value for that position. The symptom is an HTRANS that doesn't match the position; the cause is the master's HTRANS generation (it's the master that drives HTRANS) — usually a beat-tracking bug (the master's burst counter/state is wrong). The effect is downstream: the slave (which also tracks the burst via HTRANS) restarts, mis-tracks, or accesses the wrong address. So wrong HTRANS is the contextual-sequencing bug debugged by position-tracking. So it's a quieter but common AHB bug.

2. Why Does It Exist?

Wrong HTRANS exists as a bug because HTRANS's legality is contextual (depends on the burst position, which is state), because the master generates it from its burst-tracking state (which can be wrong), and because the effect is downstream and quiet (the slave mis-tracks, causing data/addressing errors without an obvious hang) — so it must be debugged by reconstructing the burst context.

The legality is contextual is the root: unlike a signal that's legal in isolation, HTRANS's legality depends on the burst position — a NONSEQ is legal at a start but illegal mid-burst. So whether an HTRANS is wrong is a function of state (the burst progress). This means the bug (a wrong HTRANS) and its detection both require knowing the context. So wrong HTRANS exists as a contextual bug — you can't judge HTRANS alone. So it's context-dependent. So legality needs the context.

The the master generates it from state drives the cause: HTRANS is driven by the master, computed from the master's burst-tracking state (which beat? burst in progress? pausing?). If that state is wrong (a burst counter miscounts, a state machine mis-transitions, a pause mishandled), the master generates the wrong HTRANS. So the cause of a wrong HTRANS is almost always in the master's burst-tracking logic. So wrong HTRANS exists because the master's state can be wrong. So it's a master-state bug. So the generation can err.

The the effect is downstream and quiet is why debug matters: a wrong HTRANS doesn't (usually) hang the bus — it's quiet. But the slave also uses HTRANS (to know when a real transfer occurs — the qualified select — 16.7 — and to track the burst). So a wrong HTRANS causes the slave to mis-behave: a NONSEQ mid-burst makes the slave restart (re-capturing the address — wrong); an IDLE mid-burst makes the slave think the burst ended (losing the continuation). So the effect is downstream data/addressing errors — quiet but real. So wrong HTRANS must be debugged (it won't announce itself like a hang). So wrong HTRANS exists because: HTRANS's legality is contextual (depends on the burst position — state — so it can't be judged alone — the why); the master generates it from its burst-tracking state (which can be wrong — the cause); and the effect is downstream and quiet (the slave mis-tracks → data/addressing errors, no obvious hang — the consequence). So wrong HTRANS is the contextual sequencing bug — caused by the master's burst-tracking, causing quiet downstream data/addressing errors, debugged by reconstructing the burst context and comparing HTRANS to the legal value for the position. So this chapter teaches the context-based diagnosis. So track the burst position to judge HTRANS.

3. Mental Model

Model debugging a wrong HTRANS as checking whether someone used the right turn signal for where they are in a route — you can't judge a signal in isolation; you need to know the route position. A "turning" signal is correct at an intersection but wrong mid-straightaway; a "continuing straight" gesture is fine on the road but meaningless in a parking lot. To catch a wrong signal, you track where they are in the route (which leg?) and compare the signal they gave against what's correct for that position. A turn signal flashed mid-block — like a NONSEQ mid-burst — means they're (wrongly) signaling a new turn when they should just be continuing.

A driver (the master) following a route (a burst) and using turn signals (HTRANS) to announce each move. The signals are: "starting a new leg / turning" (NONSEQ — burst start), "continuing this leg" (SEQ — continuing beat), "pausing briefly, still on this leg" (BUSY — pause within the burst), and "parked, no movement" (IDLE — between bursts). Now, which signal is correct depends entirely on where they are in the route — you can't judge a signal in isolation. A "turning" signal (NONSEQ) is correct at an intersection (the start of a leg) but wrong in the middle of a straightaway (where "continuing" — SEQ — is correct). A "continuing straight" gesture (SEQ) is fine on the road (continuing a leg) but meaningless in a parking lot (with no leg to continue — an orphan SEQ). A "parked" signal (IDLE) is fine between trips but wrong mid-route (where "pausing" — BUSY — is correct if they need a beat). So to catch a wrong signal, you track where they are in the route — which leg? mid-leg or at a junction? pausing or stopped? — and compare the signal they gave against what's correct for that position. A "turning" signal flashed mid-block (NONSEQ mid-burst) tells you they're wrongly signaling a new turn when they should just be continuing — and anyone following them (the slave) will wrongly think a new leg started and go the wrong way. The bug is in the driver's sense of route position (the master's burst-tracking); the effect is on followers (the slave mis-tracking).

This captures wrong-HTRANS debug: the route = the burst; the turn signals = HTRANS values; "turning"/"continuing"/"pausing"/"parked" = NONSEQ/SEQ/BUSY/IDLE; a signal's correctness depending on route position = HTRANS's contextual legality; you can't judge a signal in isolation = you can't judge HTRANS without the burst position; tracking where they are in the route = tracking the burst position; comparing the signal to what's correct for the position = comparing HTRANS to the legal value; "turning" mid-block = NONSEQ mid-burst; the driver's wrong sense of position = the master's burst-tracking bug; followers going the wrong way = the slave mis-tracking. Track the route position, then judge whether the signal was right.

Watch a wrong HTRANS on the waveform — a NONSEQ mid-burst:

The model's lesson: track the route position, then judge whether the signal was right. In the waveform, beat 2's HTRANS is judged wrong only by knowing it's mid-burst (where SEQ is required) — the NONSEQ restarts the burst in the slave's view. The trace: track the burst position → compare HTRANS to the legal value → the master's beat-tracking is the cause.

4. Real Hardware Perspective

In debug, you reconstruct the burst context from the waveform (track NONSEQ/SEQ and the address sequence), compare each HTRANS against the legal value for the position, trace the wrong value to the master's burst-tracking, and use a monitor/assertion to catch it automatically.

The reconstruct the burst context: on the waveform, track the burst — a NONSEQ starts a burst (note the address, size, burst type), then each SEQ continues it (the address should increment/wrap per the burst type — 8.x). So you build the expected sequence: which beat are we on, is a burst in progress, what HTRANS is legal next. So in debug, reconstruct the burst position. So it's context reconstruction. So that's step one.

The compare and trace to the master: with the expected HTRANS known for each position, compare the actual HTRANS. A mismatch (e.g. NONSEQ where SEQ is expected, or IDLE where BUSY is expected) is the violation. Then trace the cause: HTRANS is driven by the master, so the bug is in the master's burst-tracking — a burst counter that miscounts, a state machine that mis-transitions (e.g. resetting to the start state mid-burst → NONSEQ), or a pause mishandled (using IDLE instead of BUSY). So in debug, the mismatch points to the master's logic. So it's master-state tracing. So that localizes it.

The monitor/assertion catches it: the legal-HTRANS-sequence check — a monitor (17.3) reconstructing the burst and validating the HTRANS sequence, or an assertion (17.2) encoding the legal transitions (mid_burst |-> HTRANS inside {SEQ, BUSY}, etc.) — catches a wrong HTRANS automatically (at the exact cycle). And note the BUSY-vs-IDLE confusion is the most common (using IDLE to pause within a burst instead of BUSY) — so specifically check that. So in debug, wrong HTRANS is a context-reconstruction trace (rebuild the burst position → compare HTRANS to the legal value → mismatch → trace to the master's burst-tracking → fix) plus a monitor/assertion to catch it. So in debug, reconstruct the context and check against the legal value. So that's the method.

5. System Architecture Perspective

At the system level, a wrong HTRANS is a protocol-contract violation between the master and slave (both rely on HTRANS to agree on the burst structure) — so it breaks their shared understanding, causing data/addressing errors; and it's exactly the kind of bug assertions and monitors (Module 17) are built to catch.

The shared-contract violation: HTRANS is part of the contract between the master and slave — both use it to agree on the burst structure (where it starts, continues, pauses, ends). The master drives it (announcing the structure); the slave reads it (tracking the structure). So a wrong HTRANS breaks their shared understanding — the master thinks one thing, the slave infers another. So at the system level, a wrong HTRANS is a contract violation that desynchronizes the master and slave. So it's a broken contract. So they disagree.

The data/addressing consequence: because the slave uses HTRANS to track the burst (and qualify its accesses — 16.7), a wrong HTRANS causes the slave to access the wrong address (a NONSEQ mid-burst makes it restart at the wrong place) or mis-handle the burst (an IDLE mid-burst makes it drop the burst). So the consequence is data/addressing errors — real corruption, quietly. So at the system level, wrong HTRANS corrupts via the broken contract. So it's data corruption. So the consequence is real.

The caught by the verification methodology: a wrong HTRANS is precisely the kind of protocol-rule violation that Module 17's methodology targets — an assertion (the legal-HTRANS-sequence rule — 17.2) or a monitor (reconstructing and validating the burst — 17.3) catches it automatically. So at the system level, wrong HTRANS is a protocol-contract violation (master and slave disagree on the burst structure — desynchronized), a data/addressing-corruption cause (the slave mis-tracks/wrong-addresses — quiet but real), and exactly what the verification methodology catches (the legal-HTRANS assertion/monitor — 17.2/17.3). So wrong HTRANS is a broken master-slave contract that corrupts data quietly — prevented by the protocol-checker mindset (catch it with an assertion) and debugged (when it escapes) by reconstructing the burst context. So encode the HTRANS rules as assertions, and debug escapes by context. So treat HTRANS as a contract and check it.

6. Engineering Tradeoffs

Debugging a wrong HTRANS embodies the context-reconstruction, compare-to-legal, trace-to-master approach.

• Context-reconstruction vs judge-in-isolation. Reconstructing the burst position lets you judge HTRANS correctly (its legality is contextual); judging in isolation is impossible (the same value is legal/illegal by position). Always reconstruct the context.
• Trace to the master vs blame the slave. The master drives HTRANS, so the cause is the master's burst-tracking; the slave is the victim (it mis-tracks because of the wrong HTRANS). Trace to the master.
• Assertion/monitor vs manual. A legal-HTRANS assertion/monitor catches it automatically (every cycle); manual waveform inspection is slow and error-prone. Use the assertion.
• BUSY vs IDLE awareness. The most common confusion is IDLE mid-burst (should be BUSY); specifically check the pause mechanism. Know BUSY pauses within, IDLE separates between.

The throughline: a wrong HTRANS is an illegal transfer-type value for the burst position — HTRANS's legality is contextual, so debug it by reconstructing the burst position and comparing the actual value against the legal one. The legal rules: burst = NONSEQ then SEQ; BUSY pauses within a burst (resume SEQ); IDLE between bursts. The common violations: NONSEQ mid-burst (restarts), SEQ with no NONSEQ (orphan), IDLE mid-burst (breaks the burst — the BUSY-vs-IDLE confusion), BUSY outside a burst. The cause is the master's HTRANS generation (burst-tracking/beat-counter); the effect is downstream (the slave mis-tracks → data/addressing errors, quietly). It's a master-slave contract violation — caught by the legal-HTRANS assertion/monitor (17.2/17.3) and debugged by context reconstruction.

7. Industry Example

Debug a wrong HTRANS causing corrupted burst data in a DMA transfer.

A DMA engine (master) does burst writes to a memory, but the memory ends up with corrupted/misplaced data — not a hang, just wrong data at wrong addresses.

• The symptom. No hang. But the scoreboard (or a memory dump) shows burst data landing at the wrong addresses — some beats overwriting earlier ones, the burst not advancing as expected.
• Reconstruct the burst context. On the waveform, you track the DMA's burst: beat 0 is NONSEQ at A0 (correct start), beat 1 is SEQ at A4 (correct). But beat 2 — which should be SEQ at A8 — shows HTRANS = NONSEQ.
• The violation. A NONSEQ mid-burst — illegal. The slave (memory), seeing NONSEQ, treats beat 2 as a new burst start: it re-captures and treats A8 as a fresh burst, losing the original burst's continuation. (And depending on the master's address logic, A8 might even be wrong — the master's burst-address generator also relies on the burst state.)
• Trace to the master. HTRANS is driven by the DMA master. You trace its burst-tracking FSM: on beat 2, a bug caused the FSM to reset to its start state (mis-handling an internal stall), so it re-issued NONSEQ instead of SEQ. The master's burst-tracking is the cause (the memory slave was the victim).
• The fix. Correct the DMA's burst-tracking FSM so it stays in the burst (issuing SEQ) across the internal stall, instead of restarting. (If the master needed to pause, it should have used BUSY, not restarted.)
• Add an assertion. You add the legal-HTRANS-sequence assertion (17.2) — mid_burst |-> HTRANS inside {SEQ, BUSY} — which catches this automatically (and would have caught it in verification, before silicon).

The example shows the context-based debug: the symptom (wrong data, no hang) → reconstruct the burst → spot the NONSEQ mid-burst → trace to the master's burst-tracking FSM (the cause; the slave was the victim) → fix the FSM → add the assertion. The contextual judgment (NONSEQ is wrong because it's mid-burst) and the trace to the master are the keys. This is how you debug a quiet HTRANS bug. This is the contract restored.

8. Common Mistakes

9. Interview Insight

Wrong HTRANS is a solid debug interview topic — the contextual-legality insight, the trace-to-the-master, and the BUSY-vs-IDLE distinction are the signals.

The answer that lands gives the contextual legality and the trace: "HTRANS encodes the transfer type — IDLE, BUSY, NONSEQ, SEQ — and a wrong HTRANS is an illegal value for the burst position. The crucial thing is that HTRANS's legality is contextual: you can't judge a value in isolation; the same value is legal or illegal depending on where you are in a burst. A NONSEQ is correct at a burst start but wrong mid-burst, where SEQ is required; a SEQ is correct continuing a burst but wrong with no preceding NONSEQ; an IDLE is correct between bursts but wrong within one, where BUSY is the pause. So to debug it, I reconstruct the burst context — track where the burst started, which beat we're on, whether it's paused — and compare the actual HTRANS against the legal value for that position. The common violations are a NONSEQ mid-burst, which makes the slave think a new burst started and restart, a SEQ with no preceding NONSEQ, an IDLE mid-burst instead of BUSY, and a BUSY outside any burst. Two things are key. First, the cause is the master — HTRANS is driven by the master, computed from its burst-tracking state, so a wrong HTRANS comes from a master beat-counter or state-machine bug. The slave is the victim — it's correctly reacting to the wrong HTRANS it was given — so I trace to the master, not the slave. Second, the most common confusion is BUSY versus IDLE: BUSY pauses within a burst, and the burst resumes with SEQ preserving the address sequence; IDLE means no transfer and is for gaps between bursts, so using IDLE mid-burst breaks the burst and loses the address continuation. Unlike a stuck HREADY, a wrong HTRANS doesn't hang the bus — it's quiet, causing the slave to mis-track or access the wrong address, so it shows up as data and addressing errors. And it's exactly what a legal-HTRANS-sequence assertion or monitor catches automatically, which is how you'd catch it in verification before silicon." The contextual-legality insight, the trace-to-the-master, and the BUSY-vs-IDLE distinction are the senior signals.

10. Practice Challenge

Build and reason from debugging a wrong HTRANS.

1. The values and rules. State the four HTRANS values and the legal sequencing rules (NONSEQ→SEQ, BUSY within, IDLE between).
2. Contextual legality. Explain why you can't judge HTRANS in isolation and must reconstruct the burst position.
3. Read the waveform. From Figure 2, explain why beat 2's NONSEQ is wrong and what the slave does in response.
4. Trace to the master. Explain why the cause is the master's burst-tracking and the slave is the victim.
5. BUSY vs IDLE. Explain the BUSY-vs-IDLE confusion, the consequence of IDLE mid-burst, and the fix.

11. Key Takeaways

• A wrong HTRANS is an illegal transfer-type value for the burst position — HTRANS's legality is contextual, so you can't judge it in isolation; track the burst position and compare to the legal value.
• Legal rules: burst = NONSEQ (start) → SEQ (continue); BUSY pauses within a burst (resume SEQ); IDLE goes between bursts.
• Common violations: NONSEQ mid-burst (restarts the burst), SEQ with no NONSEQ (orphan), IDLE mid-burst (breaks the burst), BUSY outside a burst.
• The cause is the master — HTRANS is driven by the master (from its burst-tracking state); a wrong value is a master beat-counter/FSM bug. The slave is the victim (correctly reacting). Trace to the master.
• BUSY vs IDLE is the #1 confusion — BUSY pauses within a burst (resume SEQ, address preserved); IDLE separates between bursts. IDLE mid-burst breaks the burst.
• It's quiet — unlike a stuck HREADY, a wrong HTRANS doesn't hang; it causes the slave to mis-track / wrong-address → data/addressing errors. A legal-HTRANS assertion/monitor (17.2/17.3) catches it.

12. What Comes Next

You now can debug a wrong HTRANS. The next chapters cover the other failure modes:

• Address / Data Misalignment (next) — diagnose data captured in the wrong phase or cycle (the pipeline mis-aligned).
• Incorrect HSEL, Wrong HRDATA Timing, and the rest — diagnose the other failures, building to a general waveform-debug methodology.

To revisit HTRANS itself, see HTRANS and How HTRANS Controls Bus Activity; for the BUSY mechanism, see BUSY Cycles Inside Bursts; for catching it automatically, see AHB Assertions (SVA).