Burst Termination

Bursts don't always run to their declared length. This chapter covers burst termination — how a burst ends, including early termination before its declared beat count. A burst ends normally when all its beats finish, but it can terminate early for several reasons: an ERROR response aborts it (chapter 7.6), the master loses the bus in a multi-master system, or the master simply decides to stop. In every case, the master signals the end by changing HTRANS away from SEQ — to IDLE (stop) or a new NONSEQ (start something else). The critical consequence is for subordinates: a subordinate must track HTRANS to follow the burst and must not assume a fixed-length burst always completes all its declared beats — because it might not. Getting this wrong (a subordinate that pre-commits to the full count) is a real early-termination bug.

1. What Is It?

Burst termination is how a burst ends. There are two cases:

• Normal completion: all the declared beats (of a fixed-length burst) or all the beats the master wants (of an INCR burst) finish.
• Early termination: the burst ends before its declared beat count, due to an ERROR response (a beat errors, the master aborts), the master losing the bus (multi-master grant removed), or the master deciding to stop (no more data to move).

The unifying mechanism is HTRANS: a burst continues while the master drives SEQ beats, and ends when the master changes HTRANS away from SEQ — to IDLE (no transfer, stopping) or to NONSEQ (starting a new, unrelated transfer). So the master controls termination purely through HTRANS: keep driving SEQ to continue, drive something else to end. This is true for both normal and early termination — the burst is "over" the moment HTRANS leaves SEQ. The key implication: a fixed-length burst's declared length (e.g., INCR4 says 4 beats) is an intent, not a guarantee — it can terminate early, so subordinates must follow HTRANS rather than rely on the declared count.

2. Why Does It Exist? (Why early termination happens)

Early termination exists because real conditions can interrupt a burst before it completes — an error, bus arbitration, or the master's changing needs — and the protocol must handle a burst ending at any beat, not just at its declared end.

The ERROR cause is the most important (chapter 7.6): when a beat of a burst errors, the master typically aborts the burst — continuing would launch more beats into a failing region. So the master terminates the burst early (drives IDLE in the error's warning cycle) and handles the error. So early termination exists to let a burst stop cleanly on a failure rather than blindly continuing. This is a correctness necessity: a burst that hit an error must be able to end early.

The loss of bus cause arises in multi-master systems: the arbiter grants the bus to masters, and in principle a master could lose its grant mid-burst. (In practice, well-designed arbiters avoid breaking bursts — they let a burst complete before re-arbitrating — but the possibility exists, and a master may need to yield.) So early termination exists partly because bus arbitration can interrupt a master. This is a multi-master consideration: the burst is subordinate to the bus-sharing mechanism, which can (in edge cases) cut it short.

The master deciding to stop cause is the master's own choice: the master may have no more data to move (it finished early), or its needs changed. So a master can simply end a burst when it's done, by driving IDLE or moving to a new transfer. This is the master's normal control over its own bursts — it ends them when appropriate. So early termination exists because the master is in control of how many beats it actually issues, regardless of the declared length.

The reason a subordinate must not assume the full beat count follows directly: since a burst can terminate at any beat (from any of these causes), a subordinate cannot rely on a fixed-length burst delivering all its declared beats. If it did — if it pre-committed to 4 beats for an INCR4 and waited for beats it never received — it would hang or mishandle the early-terminated burst. So the subordinate must instead track HTRANS: follow the burst while SEQ continues, and recognize the end when HTRANS leaves SEQ — handling whatever number of beats actually arrived. This requirement exists because early termination is possible: the subordinate must be robust to a burst ending early, which means tracking HTRANS, not assuming the count. So the "track HTRANS, don't assume" rule is the direct consequence of early termination being a real possibility.

3. Mental Model

Model burst termination as a planned multi-stop delivery route that can be cut short — the driver might finish early, get a "return to base" call, or hit a road closure — so the dispatcher tracks where the truck actually is, not just the planned route.

A delivery truck (the burst) has a planned route of stops (the declared beats). Normally it completes all stops (normal completion). But the route can be cut short: the driver finishes the deliveries early (the master stops — no more data), gets a "return to base now" call (the master loses the bus / yields), or hits a road closure and can't continue (an ERROR aborts the burst). So the dispatcher (the subordinate) can't assume the truck will hit all the planned stops — it must track where the truck actually goes (track HTRANS): the truck is still on the route while it's making stops (SEQ), and the route is over when the truck heads back or goes elsewhere (HTRANS leaves SEQ). A dispatcher who assumed all stops would be made — and waited for the truck at a stop it never reached — would be stuck. The robust dispatcher tracks the truck's actual movements.

This captures termination: the planned route = the declared beat count (intent); cut short = early termination (finished early / recalled / road closure = master stops / loses bus / ERROR); track where the truck actually is = track HTRANS (SEQ = still on route, else = route over); don't assume all stops = don't assume the full count. The route is a plan, not a guarantee — track the actual movement.

Watch an early-terminated burst:

The model's lesson: the declared length is a plan, not a guarantee — track HTRANS to see the actual end. In the waveform, the INCR4 declared 4 beats but ended after 2 (HTRANS went IDLE). A subordinate tracking HTRANS handles this; one assuming 4 beats would hang waiting for beats 2 and 3. Track the actual movement, not the plan.

4. Real Hardware Perspective

In hardware, the master terminates a burst by driving HTRANS=IDLE (or a new NONSEQ) instead of the next SEQ beat, and the subordinate's burst-tracking logic must be HTRANS-driven — following SEQ and ending on non-SEQ — rather than counting down a fixed length.

The master's termination is just what it drives on HTRANS. To continue the burst, it drives SEQ for the next beat; to terminate, it drives IDLE (stopping) or NONSEQ (a new transfer). For an ERROR-driven termination, the master drives IDLE in the error's warning cycle (chapter 7.6) — cancelling the next beat. For a voluntary stop, it drives IDLE or moves on. So in hardware, there's no special "terminate burst" signal — the master simply stops driving SEQ. This is clean: the burst's continuation is entirely in the HTRANS the master drives each address phase.

The subordinate's tracking must be HTRANS-driven for robustness. A naive subordinate might, on seeing a fixed-length HBURST (e.g., INCR4), set up to handle exactly 4 beats — counting them down, pre-fetching all 4, or expecting 4. But if the burst terminates early (only 2 beats arrive), such a subordinate could hang (waiting for beats 3 and 4) or mishandle (pre-fetched data for beats that never transferred). The robust subordinate instead tracks HTRANS: each beat, check HTRANS — SEQ means the burst continues (process this beat), non-SEQ means the burst ended (stop, regardless of how many beats arrived). So the subordinate's state machine follows HTRANS, treating the declared length as a hint (for prefetch, perhaps) but never as a guarantee. This HTRANS-tracking is the hardware-correct way to handle bursts.

The prefetch caveat for early termination: a subordinate/memory that prefetched ahead (for a fixed-length burst, fetching all declared beats) may have over-fetched if the burst terminates early — it fetched data for beats that never transferred. This is usually harmless (the over-fetched data is just discarded), but the subordinate must not depend on all beats transferring (e.g., it must not commit a write it pre-staged for a beat that never came). So prefetch off the declared length is fine as an optimization, but the subordinate must handle early termination by not committing to beats that didn't actually transfer. The declared length guides prefetch; HTRANS governs what actually happened.

A hardware note on the arbiter and bursts: in multi-master AHB, well-designed arbiters generally don't break bursts — they grant the bus to a master and let its burst complete before re-arbitrating, to avoid the inefficiency and complexity of broken bursts. So loss-of-bus mid-burst is uncommon in practice (the arbiter avoids it). But the protocol allows a burst to terminate at any beat, and robust subordinates handle it regardless. So while the arbiter usually protects bursts, subordinates are still designed to be robust to early termination — defense in depth. The "track HTRANS" rule makes subordinates robust to all termination causes, including the rare arbiter-induced one.

5. System Architecture Perspective

At the system level, early termination is a robustness requirement — every subordinate must handle a burst ending at any beat — and it interacts with error handling, arbitration, and the master's flow control, making "track HTRANS" a universal subordinate design rule.

The error-handling interaction is the most consequential: because an errored beat terminates the burst (chapter 7.6), every subordinate that can error mid-burst must handle the burst ending there — and every subordinate observing the bus must handle a burst it's part of ending on an error. So early termination is woven into error handling: a failure mid-burst means the burst ends, and subordinates must cope. This is why robust burst handling and robust error handling go together — a burst can end on an error at any beat, and the subordinate must handle both the error and the early end.

The universal design rule that emerges is "track HTRANS, don't assume the count" — a rule every AHB subordinate must follow to be robust. This is a key correctness principle for subordinate design: never hard-code the declared burst length as a guarantee; always follow HTRANS to know the actual sequence. So at the system level, this rule is part of what makes subordinates composable and robust — a subordinate that follows it works correctly with any master's bursts, including early-terminated ones, while one that assumes the count is fragile (works until a burst terminates early, then fails). So "track HTRANS" is a subordinate-design contract that ensures robustness across all burst behaviors. This is the same composability theme as the response and wait-state modules: follow the protocol's actual signals, don't assume.

The verification implication is that early termination is a case that must be tested: a verification suite must include early-terminated bursts (terminated by error, by the master stopping, by arbitration) to exercise subordinates' robustness. A subordinate tested only with bursts that always complete fully would have its early-termination handling untested — and might harbor a latent bug (like the wait-state latent bugs of chapter 6.7). So verification must deliberately terminate bursts early to test the "track HTRANS" handling. This is a real coverage requirement: early-terminated bursts are a distinct, important case. So at the system level, early termination drives both a design rule (track HTRANS) and a verification requirement (test early termination) — ensuring subordinates are robust to the full range of burst behaviors. The protocol allows bursts to end at any beat, so the system must design and verify for that.

6. Engineering Tradeoffs

Burst termination embodies the bursts-can-end-anytime, track-don't-assume design.

• Track HTRANS vs assume the count. Tracking HTRANS makes subordinates robust to early termination (handles any actual length) at the cost of HTRANS-driven logic rather than a simple counter. Assuming the count is simpler but fragile (breaks on early termination). AHB requires tracking HTRANS — robustness is essential.
• Declared length as hint vs guarantee. Treating the declared length as a hint (for prefetch) while tracking HTRANS for the actual sequence balances optimization (prefetch off the hint) with correctness (HTRANS governs reality). Treating it as a guarantee would be simpler but wrong. AHB: hint for prefetch, HTRANS for truth.
• Arbiter protects bursts vs allows breaking. Arbiters usually let bursts complete (avoiding the inefficiency of broken bursts) but the protocol allows termination at any beat. The arbiter's protection is an optimization; the subordinate's robustness is the safety net. Both: arbiter avoids breaking, subordinate handles it anyway.
• Clean error-abort vs blind continuation. Terminating a burst on an errored beat (rather than continuing into more failing beats) is correct (chapter 7.6) at the cost of the abort logic (drive IDLE in the warning cycle). Continuing would be wrong. AHB aborts on error.

The throughline: a burst can terminate at any beat — normally or early (ERROR, loss of bus, master stops) — signalled by changing HTRANS away from SEQ. The declared length is an intent, not a guarantee, so subordinates must track HTRANS (not assume the count) to be robust — a universal subordinate-design rule. This robustness, tested by verifying early-terminated bursts, makes subordinates composable across all burst behaviors. The cost (HTRANS-driven tracking) is accepted for the correctness it ensures.

7. Industry Example

Trace burst termination across several scenarios.

A system has a CPU, a DMA engine, and various subordinates handling bursts.

• Normal completion. The DMA issues an INCR8 burst that completes all 8 beats — normal completion. The subordinate processed 8 beats, then saw HTRANS leave SEQ (the DMA moved to its next burst or IDLE). The common case.
• Error termination. A CPU burst (INCR4) hits an errored beat on beat 3 (an access violation). The subordinate returns ERROR; the CPU aborts the burst, driving IDLE in the warning cycle (chapter 7.6). So the burst terminated after ~3 beats (the errored one being the last). The memory subordinate, tracking HTRANS, saw the burst end and didn't expect a 4th beat. Early termination on error, handled correctly.
• Master stops early. The DMA issues an INCR (undefined-length) burst and, having moved all its data, stops after 5 beats by driving IDLE. The subordinate, tracking HTRANS, processed 5 beats and saw the IDLE — burst over. The master ended its own burst when done. (For undefined INCR, this is the normal end; for a fixed-length burst, stopping early would be early termination.)
• A robust subordinate. A well-designed memory subordinate tracks HTRANS throughout: it processes each SEQ beat and stops when HTRANS leaves SEQ, never assuming a fixed-length burst's full count. So it handles all the above — normal completion, error termination, early stop — correctly, processing exactly the beats that arrived.
• A buggy subordinate. Suppose a custom subordinate, on seeing INCR4, hard-codes a 4-beat handler that waits for all 4 beats before completing its internal operation. When a burst terminates early (after 2 beats, say, due to an error elsewhere), this subordinate hangs — waiting for beats 3 and 4 that never arrive. This is the classic early-termination bug. The fix: track HTRANS, complete on whatever beats arrived.
• Verification caught it. The verification suite included early-terminated bursts (terminated by injected errors and master stops). These tests exercised the subordinate's early-termination handling and caught the hang in the buggy subordinate — before silicon. So testing early termination is what surfaced the latent bug.

The example shows burst termination across cases: normal completion (all beats), error termination (abort on errored beat), and early stop (master done) — all handled by a robust subordinate that tracks HTRANS. The buggy subordinate that assumed the count hangs on early termination, caught by verification that deliberately tests early-terminated bursts. The "track HTRANS" rule is what makes a subordinate robust across all these cases.

8. Common Mistakes

9. Interview Insight

Burst termination is a practical interview topic — the "track HTRANS, don't assume the count" rule is the key signal.

The answer that lands covers the causes, the mechanism, and the subordinate rule: "A burst can end normally — all its beats finishing — or terminate early, before its declared beat count. Early termination happens from an ERROR response (a beat errors, the master aborts), the master losing the bus in a multi-master system, or the master simply deciding to stop because it has no more data. In every case, the master signals the end by changing HTRANS away from SEQ — to IDLE to stop, or a new NONSEQ to start something else. There's no special 'end of burst' signal; the burst is over the moment HTRANS leaves SEQ. The critical consequence is for subordinates: a subordinate must track HTRANS to follow the burst, and must never assume a fixed-length burst always delivers all its declared beats — because it might terminate early. A subordinate that hard-codes the count would hang or mishandle an early-terminated burst. So the declared length is an intent, not a guarantee, and subordinates track HTRANS for the actual sequence." The early-termination causes, the HTRANS mechanism, and the track-don't-assume rule are the senior signals.

10. Practice Challenge

Reason from burst termination.

1. List the causes. Give the ways a burst can terminate early.
2. The mechanism. Explain how the master signals burst termination.
3. Read the waveform. From Figure 2, identify where and how the burst terminated, and how many beats transferred.
4. The subordinate rule. Explain why a subordinate must track HTRANS and what goes wrong if it assumes the count.
5. Verification. Explain why early-terminated bursts must be deliberately tested.

11. Key Takeaways

• A burst can end normally (all beats) or terminate early — before its declared count — from an ERROR (master aborts), the master losing the bus (multi-master), or the master deciding to stop.
• The master signals termination by changing HTRANS away from SEQ — to IDLE (stop) or a new NONSEQ (new transfer). There's no special end-of-burst signal.
• The declared length is an intent, not a guarantee — a fixed-length burst can terminate early, so it may deliver fewer than its declared beats.
• Subordinates must track HTRANS, not assume the count — SEQ = continue, non-SEQ = ended. Assuming the full count hangs or mishandles an early-terminated burst (a real, latent bug).
• Early termination is woven into error handling — an errored beat aborts the burst (via the two-cycle ERROR + IDLE), so robust burst and error handling go together.
• Test early termination — verification must deliberately terminate bursts early (by error, master stop, arbitration) to exercise subordinates' "track HTRANS" robustness.

12. What Comes Next

You now understand how bursts end. The next chapter covers how a burst pauses without ending:

• 8.11 — BUSY Cycles Inside Bursts (coming next) — how HTRANS=BUSY pauses a burst (master not ready for the next beat) without losing the sequence, distinct from terminating it.

To revisit the error-driven termination, see The Two-Cycle ERROR Response and How the Master Reacts. For the HTRANS values, see HTRANS, SEQ Transfers, and IDLE Transfers. For the burst overview, Burst Overview. For the broader protocol map, see the AMBA family overview.