AMBA AXI · Module 14

Avoiding Partial Transactions

How a reset mid-burst leaves partial/orphaned AXI transactions that corrupt state — the hazard at master, interconnect, and slave — and the prevention: global simultaneous reset or graceful quiesce-then-reset.

Reset returns an AXI interface to quiescent (Chapter 14.3) — but what about transactions that were in flight when reset hit? A reset mid-burst leaves a partial transaction: write beats sent but no WLAST/B, or read beats returned but no RLAST — and the persistent state around it (partially-written memory, dangling tracker entries, half-full FIFOs) can be left inconsistent. Because reset is asynchronous to transaction boundaries, it can interrupt at any point. This chapter covers the hazard (where partial transactions corrupt state), the transaction FSM and reset, and the two prevention strategies: global simultaneous reset (everyone forgets together) or graceful quiesce-then-reset (drain first).

1. The Partial-Transaction Hazard

A burst is a multi-beat sequence; if reset hits partway through, the transaction is neither completed nor cleanly cancelled at the protocol level — both ends just go to reset. The danger is persistent state that doesn't reset cleanly or was already partially committed:

Slave side: a write burst with some W beats applied but not all — memory partially written (some bytes updated, some not); or an outstanding-transaction tracker left with a dangling entry expecting beats that never come.
Interconnect: dangling outstanding-tracking entries, ID-routing state left mid-transaction, or a FIFO holding a partial burst — inconsistent CDC/routing state.
Master side: logic waiting for a B/R response that was abandoned (though reset clears the master too, so this self-resolves if reset is global).

The root issue: reset is asynchronous to transaction boundaries, so it can land mid-burst, and any state that survives reset (memory contents, or logic/FIFOs not properly reset) is left in a half-updated, inconsistent condition. A partial write to memory is the worst case — it's a real data-corruption, not just a protocol hiccup.

Figure 1 — the partial-transaction hazard. A reset mid-burst leaves orphaned beats: at the slave, memory partially written and a dangling tracker entry; at the interconnect, dangling outstanding/ID state and a FIFO with a partial burst; at the master, a response never arriving. Reset is asynchronous to transaction boundaries, so persistent state (especially partially-written memory) is left inconsistent.

2. On the Wire — Reset Mid-Burst

A write burst interrupted by reset before WLAST / the B response:

reset-mid-burst — a write burst abandoned by reset before WLAST

8 cycles

Figure 2 — reset-mid-burst: a write burst (D0, D1, D2 …) interrupted when ARESETn asserts mid-burst. WLAST is never reached and no B response is returned — the burst is abandoned. The VALIDs are forced low by reset; on release the interface is quiescent, but any beats already applied to memory left it partially written. The transaction was neither completed nor protocol-cancelled.

3. The Transaction FSM and Reset

A transaction is a small state machine — idle → active (address + data beats) → response → idle — and reset can strike in any state:

Figure 3 — the transaction FSM with reset. Normal flow: Idle → Active (AW/AR accepted, data beats) → Done (WLAST/RLAST + B/R response) → Idle. Reset can hit in any state; from Active it abandons the burst mid-flight (the partial-transaction risk — beats sent, no WLAST/response, possible partial memory write). The FSM resets to Idle cleanly, but persistent side effects (partial writes) are the hazard reset alone doesn't undo.

The FSM itself resets cleanly to Idle from any state — that's straightforward. The problem is the side effects already committed in the Active state: beats already written to memory, a tracker entry already allocated, a FIFO already partially filled. Resetting the FSM forgets the control state, but doesn't undo a partial memory write or guarantee a downstream FIFO is flushed. So "reset to Idle" makes the interface quiescent but can leave persistent state inconsistent — which is exactly what the prevention strategies address.

4. Prevention — Global Reset or Quiesce-Then-Reset

Two strategies prevent partial-transaction corruption:

Global simultaneous reset (the standard): reset the master, interconnect, and slave together as one system event. Since everyone goes to Idle and forgets all transaction state at once, there's no "half" — no side waiting for a response, no dangling tracker, no FIFO mismatch. The partial memory write may still have happened, but it's understood that a reset discards all in-flight work and the system reinitializes from a known state (e.g., reloads/reinitializes memory regions as needed). This is the common case: reset is a coordinated system-wide event, not a localized one.
Graceful quiesce-then-reset: when you need to reset without corrupting persistent state (e.g., a partial-system reset, or to safely reconfigure), first quiesce — stop issuing new transactions and wait for all outstanding ones to complete (every B/R received, every burst finished with LAST) — then assert reset. This guarantees no transaction is in flight when reset hits, so there's no partial state. It requires a quiesce mechanism (a "stop and drain" handshake) and costs the drain time, but it's the safe way to reset a subsystem mid-operation.

The key principle: AXI has no per-transaction abort — you cannot cleanly cancel a single in-flight burst (the only "abort" is reset, which is all-or-nothing). So either reset everything together (global — accept that in-flight work is discarded and reinitialize) or drain first (quiesce — no in-flight work to corrupt). Never reset part of the system mid-burst and expect the rest to be consistent.

Figure 4 — prevention. Global simultaneous reset (standard): reset master + interconnect + slave together so everyone forgets in-flight state at once — no dangling/mismatched state, system reinitializes from known state. Graceful quiesce-then-reset: stop issuing, wait for all outstanding to complete (drain), then reset — no in-flight transaction to corrupt. AXI has no per-transaction abort, so reset everything together or drain first; never reset part mid-burst.

5. Common Misconceptions

Myths to unlearn

"Reset cleanly cancels an in-flight transaction." It forces the interface to Idle, but doesn't undo side effects — a partial memory write or a half-filled downstream FIFO can be left inconsistent. Reset isn't a clean per-transaction abort.
"AXI has a way to abort a single burst." It does not — there's no per-transaction cancel. The only abort is reset, which is all-or-nothing for the whole interface.
"Resetting the FSM is enough." The control FSM resets to Idle easily, but persistent state (memory, trackers, FIFOs) committed mid-burst isn't undone by the FSM reset. That's the actual hazard.
"You can reset just the slave (or just one block) mid-operation." Not safely — a partial reset leaves the rest of the system with dangling state (a master awaiting a response, an interconnect tracker). Reset globally or quiesce first.
"Global reset avoids the partial write." It avoids the inconsistent control state (everyone forgets), but the partial memory write may still have happened — the system must reinitialize from a known state, not assume memory is intact.
"Quiesce is unnecessary if reset is fast." Speed doesn't help — a fast reset still hits mid-burst. Quiesce (drain) is the only way to ensure no in-flight transaction when you can't reset everything.

6. Debugging Insight

🔍 Debugging insight — corruption and hangs after a reset event

Partial-transaction bugs appear after a reset (especially a non-global or mid-operation reset):

Memory corrupted after a reset? A write burst was reset mid-flight, leaving memory partially written. If the reset was supposed to be clean, you needed to quiesce (drain outstanding writes) before resetting, or reinitialize the affected memory after a global reset.
A block hangs after reset, waiting forever? A partial/non-global reset — one block was reset while another wasn't, so e.g. the master is reset but the slave/interconnect has a dangling tracker entry (or vice versa, a master awaiting a B/R that was discarded). Reset must be global (all together) or coordinated.
Protocol violation on the first transaction after reset? Residual state from an abandoned burst (a tracker entry, a partial FIFO not flushed) interfered with the restart. Ensure all transaction state (not just the FSM) is reset/flushed.
A bridge/FIFO inconsistent after reset? A burst was mid-crossing when reset hit, and the FIFO/pointers weren't reset consistently across domains (Chapter 14.3). Coordinate cross-domain reset and flush the FIFOs.
Intermittent, only when reset coincides with traffic? Classic mid-burst reset — it only corrupts when reset happens to land during a transaction. Reproduce by asserting reset at various points in a burst.

The triage: memory corruption → mid-burst write (quiesce or reinitialize); hang → non-global/partial reset (dangling state); restart violation → residual transaction state not flushed; bridge inconsistent → cross-domain reset; intermittent-with-traffic → mid-burst timing. The fix is almost always "reset globally" or "quiesce first," plus ensuring all state (not just FSMs) resets/flushes.

7. Verification Insight

✅ Verification insight — reset at every point in a burst, check recovery

The defining test is reset injection at every point in a transaction: assert reset during the address phase, after each data beat, between the last beat and the response, and during the response — for both reads and writes — and confirm clean recovery: the interface returns to quiescent (all VALIDs low, FSMs in Idle), no dangling state remains (trackers cleared, FIFOs flushed), and the first transaction after reset is well-formed (no protocol violation from residual state). For writes, check the memory/state consistency model: after a mid-burst-reset write, the reference model should reflect the defined post-reset behavior (e.g., partial write discarded or reinitialized — per the design's contract), and the system must not silently believe a partial write completed.

Coverage should include: reset at each beat index of various burst lengths; reset during read vs write; reset of the whole system (global) vs (if the design supports it) a quiesce-then-reset sequence (confirm the quiesce drains all outstanding before reset); reset coinciding with maximum outstanding transactions (many in-flight to abandon); and cross-domain reset for bridges (FIFO consistency, Chapter 14.3). The highest-value test is reset mid-burst then verify clean restart — it's the realistic system-reset-while-busy scenario, and it catches dangling-state and residual-state bugs that a quiescent-reset test misses. If the design supports graceful reset, also verify the quiesce actually waits for all outstanding to complete before reset (no transaction in flight at reset). Reset-recovery verification is essential because reset will eventually coincide with traffic in the field.

8. Interview Questions

9. Summary

A reset mid-burst leaves a partial transaction — beats sent without WLAST/B or RLAST — abandoned neither completed nor protocol-cancelled, because reset is asynchronous to transaction boundaries. The hazard is persistent state left inconsistent: a slave's partially-written memory (real data corruption), dangling outstanding-tracker entries, half-filled FIFOs, and mid-transaction interconnect/ID state. Resetting the transaction FSM forgets the control state but doesn't undo these committed side effects — which is the actual danger.

Prevention is one of two strategies, because AXI has no per-transaction abort: global simultaneous reset (reset master + interconnect + slave together so everyone forgets coherently — no dangling control state, though a partial memory write must be reinitialized) or graceful quiesce-then-reset (stop issuing, drain all outstanding to completion, then reset — nothing in flight to corrupt, preserving state). Never reset part of the system mid-burst. Verify by injecting reset at every point in a burst under heavy outstanding load and confirming clean recovery and persistent-state consistency — the realistic "reset while busy" case that quiescent-reset tests miss, and a frequent source of silicon field failures. Next: CDC handshake safety — the rules that keep VALID/READY safe across domains.

10. What Comes Next

You've got partial-transaction safety; next, the handshake CDC rules:

14.5 — CDC Handshake Safety (coming next) — the rules that keep the VALID/READY handshake safe across clock domains, closing out the clock-domain module.

Previous: 14.3 — Reset Sequencing. Related: 7.1 — Burst Length, Size & Beats for burst structure, and 8.5 — Interconnect Implications for the outstanding state that goes dangling. For the broader protocol catalog, see the AMBA family overview doc.