AMBA AXI · Module 14

Reset Sequencing

AXI reset discipline — ARESETn behavior, the rule that all VALID signals must be low during reset and the first VALID comes after deassertion, the asynchronous-assert/synchronous-deassert technique, and reset coordination across clock domains.

Every AXI interface has a reset, ARESETn (active-low), that brings it to a known quiescent state. Reset seems simple, but it has specific protocol rules (all VALIDs low during reset; the first VALID only after deassertion) and a timing discipline (asynchronous assert, synchronous deassert) that, if violated, cause metastability and spurious transactions. And in a multi-clock system (Chapter 14.1–14.2), reset must be coordinated across domains. This chapter covers ARESETn behavior, the reset protocol rules, the async-assert/sync-deassert technique and why it's necessary, and cross-domain reset coordination.

1. ARESETn and the Reset Rules

ARESETn is AXI's active-low reset. While it's asserted (low), the interface must be quiescent — no transactions in progress. The protocol rules:

All VALID signals must be driven LOW during reset — AWVALID, WVALID, BVALID, ARVALID, RVALID are all deasserted. No channel is offering a transfer.
The earliest a VALID may assert is at a rising clock edge after ARESETn is high. So no transaction starts during reset or at the exact deassertion edge — the interface waits at least until the first clock edge with reset released.
Other signals are don't-care during reset. Address, data, and control values needn't be defined while reset is asserted (only the VALIDs must be low); they become meaningful only when a transaction is actually issued after reset.

So reset's protocol contract is narrow but firm: VALIDs low while reset, first VALID after release. This guarantees both sides come out of reset with no phantom transaction in flight — the interface starts clean.

reset-deassert — VALID low during reset, first VALID after deassertion

8 cycles

Figure 1 — reset-deassert: ARESETn behavior. While ARESETn is low (reset), all VALID signals are held low (quiescent — no transactions). ARESETn deasserts synchronously on a clock edge; the first VALID may assert only at a rising edge after reset is high. Here AWVALID stays low through reset and first asserts the cycle after deassertion — the clean-start contract.

2. Asynchronous Assert, Synchronous Deassert

The standard reset timing discipline is asynchronous assertion, synchronous deassertion:

Asynchronous assert: reset can be applied immediately (asynchronously), without waiting for a clock edge — so the design enters reset right away (important for power-up or emergency reset, when the clock may not even be running). Flops have an async reset input that forces them to the reset state regardless of the clock.
Synchronous deassert: reset must be released synchronously — the deassertion is aligned to (synchronized to) the clock so that all flops exit reset on the same clock edge. This requires a small reset synchronizer (the incoming async reset is asserted async but its release is passed through flops clocked by the destination clock).

Why this combination? Asserting async is safe (forcing everything to a known state has no race). But releasing async is dangerous: if reset deasserts arbitrarily close to a clock edge, some flops might sample the release and exit reset this cycle while others exit next cycle (metastability on the reset signal itself, or skew) — leaving the logic in an inconsistent state. Synchronizing the deassertion ensures a clean, simultaneous exit. This is the universal reset discipline, and AXI's ARESETn follows it.

Figure 2 — asynchronous-assert, synchronous-deassert. Reset asserts immediately (async — forces a known state even without a clock), but its release is passed through a reset synchronizer so deassertion is aligned to the clock and all flops exit reset on the same edge. Async release would risk metastability/skew (some flops out, some not → inconsistent state); synchronous release guarantees a clean simultaneous exit.

3. Why It Matters — Clean Start, No Phantom Transactions

The two disciplines together guarantee a clean start. Consider what goes wrong without them:

If VALIDs weren't forced low during reset: a stale or random VALID could make the other side think a transaction is in progress as reset releases — a phantom transaction with garbage address/data. The "VALIDs low during reset" rule prevents this — the interface is definitively idle.
If reset deasserted asynchronously: flops exit reset on different edges, so (for example) the logic driving AWVALID might come out of reset a cycle before the logic driving AWADDR — asserting VALID with an undefined address, or the receiver might see VALID while still partly in reset. The synchronous deassert ensures everything exits together, so the first transaction is well-formed.

So the rules and discipline jointly ensure: at reset release, both sides are simultaneously idle and consistent, and the first transaction is clean (well-formed, no phantom). This is why reset isn't an afterthought — getting it wrong produces spurious transactions or metastable startup, which are nasty intermittent bugs. Reset is also generally a full-interface (often full-system) event: any in-flight transactions are abandoned (the spec returns the interface to quiescent), so reset isn't used mid-operation to cancel a single transaction.

Figure 3 — why the rules matter. VALIDs-low-during-reset prevents a phantom transaction (a stale VALID making the other side act on garbage as reset releases). Synchronous deassert prevents inconsistent exit (some flops out of reset before others → VALID with undefined address, or receiver partly in reset). Together they guarantee both sides start simultaneously idle and consistent, with a clean first transaction.

4. Reset Across Clock Domains

In a multi-clock system (Chapters 14.1–14.2), reset must be handled per domain and coordinated:

Per-domain synchronization: each clock domain has its reset synchronized to its own clock (async-assert/sync-deassert in that domain), because a single reset signal crossing into multiple domains must be released cleanly relative to each domain's clock — you can't share one synchronous deassertion across asynchronous clocks.
Coordination for bridges: an async AXI bridge (Chapter 14.2) spans two domains, with FIFO pointers and state in each. Its reset must be coordinated so the bridge initializes consistently — e.g., the FIFO is empty and both pointers are reset before either side starts issuing, and the two domains' resets overlap appropriately so no half-reset state lets a transaction through. A common discipline is to assert reset to both domains together and release each synchronously to its own clock, ensuring the bridge is fully quiescent before either side resumes.

So cross-domain reset is "one logical reset, synchronized into each domain, coordinated so shared structures (bridges/FIFOs) come up consistent." Mishandling it — releasing one domain's reset while the other is still resetting, or initializing FIFO pointers inconsistently — causes startup glitches or corrupted CDC structures. Reset coordination is part of the bridge/clock-converter design (Chapter 12.7).

Figure 4 — reset across clock domains. Each domain synchronizes its reset to its own clock (async-assert/sync-deassert per domain — you can't share one synchronous release across async clocks). For an async bridge spanning domains, the resets are coordinated so shared structures (FIFO pointers/state) initialize consistently — both sides quiescent before either resumes. Mishandling causes startup glitches or corrupted CDC state.

5. Common Misconceptions

Myths to unlearn

"Reset can be deasserted whenever." No — deassertion must be synchronous (aligned to the clock via a reset synchronizer) so all flops exit reset on the same edge. Async deassert risks metastability and inconsistent state.
"All signals must be defined during reset." Only the VALIDs must be low; address/data/control are don't-care during reset. The contract is "VALIDs low, first VALID after release."
"A transaction can start at the deassertion edge." No — the first VALID may assert only at a rising edge after ARESETn is high, so no transaction overlaps the release.
"Reset cancels a single in-flight transaction." Reset returns the whole interface to quiescent (abandons all in-flight transactions) — it's a full-interface/system event, not a per-transaction cancel.
"One reset signal works fine across all clock domains." Each domain must synchronize the reset to its own clock; a shared async deassertion can't be clean for multiple async clocks. Bridges need coordinated reset.
"Async assert is dangerous like async deassert." Async assert is safe (forcing a known state has no race); only async deassert (release) is dangerous. Hence async-assert/sync-deassert.

6. Debugging Insight

🔍 Debugging insight — startup glitches and reset-timing bugs

Reset bugs manifest at startup or after a reset event:

A phantom/garbage transaction right after reset? A VALID not held low during reset — the other side acted on a stale VALID with undefined address/data as reset released. Ensure all VALIDs are forced low while ARESETn is asserted.
Intermittent metastable startup / inconsistent post-reset state? Async deassertion — reset released near a clock edge, flops exited on different edges. Add a reset synchronizer (async-assert/sync-deassert).
A transaction appears to start during reset? A VALID asserted at or before the deassertion edge — it must wait until a rising edge after ARESETn is high. Check the master's reset-release timing.
A bridge/FIFO comes up corrupted after reset? Cross-domain reset not coordinated — one domain released while the other still resetting, or FIFO pointers initialized inconsistently. Coordinate the domains' resets so the bridge is fully quiescent before either side resumes.
Works on power-up but fails on warm reset (or vice versa)? Reset assertion width too short (some logic didn't fully reset) or a timing difference between power-on and warm reset paths. Ensure reset is held long enough and both paths follow the discipline.

The triage: phantom transaction → VALID-not-low; metastable startup → async deassert (add synchronizer); transaction-during-reset → first-VALID-timing; bridge corrupt → cross-domain coordination; warm-vs-cold difference → assertion width/path. Reset bugs are startup/intermittent — design the discipline in, don't debug it after.

7. Verification Insight

✅ Verification insight — reset protocol rules and the deassert discipline

Reset verification checks both the protocol rules and the timing discipline. Protocol: assert that all VALIDs are low whenever ARESETn is asserted (a continuous check — any VALID high during reset is a violation), and that no VALID asserts until a rising edge after deassertion (the first-transaction-after-release rule). Apply reset at various points — power-up, and mid-operation (with transactions in flight) — and confirm the interface returns to quiescent and resumes cleanly (in-flight transactions abandoned, no phantom transaction on release). Timing: the deassertion discipline (async-assert/sync-deassert) is partly a structural/CDC property — verify (via CDC analysis) that the reset deassertion is synchronized in each domain, since metastable reset release won't show in functional sim (like other CDC issues, Chapter 14.1).

Coverage should include: reset asserted and released cleanly; reset mid-transaction (each channel mid-burst — confirm clean abandonment and restart, feeding Chapter 14.4); the first transaction after release (well-formed); minimum and longer reset assertion widths; and, for multi-domain designs, coordinated cross-domain reset (the bridge/FIFOs come up consistent). The highest-value checks are the VALID-low-during-reset assertion (catches phantom-transaction bugs) and the reset-mid-operation recovery (the realistic stress — a system reset while busy). Combine functional reset testing with CDC analysis of the reset synchronization — because, like all CDC, a metastable reset deassertion is invisible to functional sim and must be proven structurally.

8. Interview Questions

9. Summary

AXI reset is governed by ARESETn (active-low) with firm protocol rules and a timing discipline. The rules: all VALIDs must be low during reset (the interface is quiescent — no phantom transaction), and the first VALID may assert only at a rising edge after ARESETn is high (no transaction overlaps the release); other signals are don't-care during reset. The discipline is asynchronous assert, synchronous deassert: reset applies immediately (safe — forcing a known state, works even without a clock), but its release is synchronized to the clock (via a reset synchronizer) so all flops exit reset on the same edge — avoiding the metastability/skew of an async release that would leave the logic inconsistent (and could assert VALID with an undefined address).

Together these guarantee a clean start: both sides simultaneously idle and consistent, with a well-formed first transaction. Across clock domains, reset is synchronized per domain (you can't share one synchronous release across async clocks) and coordinated for spanning structures (async bridges/FIFOs must initialize consistently). Crucially, reset deassertion is a CDC problem — the async reset release is a single-bit crossing synchronized like any control signal (Chapter 14.1) — so its correctness is structural, verified by static CDC analysis (metastable release is invisible to functional sim). Reset bugs (phantom transactions, metastable startup, corrupted bridge init) are intermittent and startup-specific, so the discipline is designed in. Next: avoiding partial transactions — how reset mid-burst corrupts state and how to prevent it.

10. What Comes Next

You've got reset discipline; next, the mid-burst reset hazard:

14.4 — Avoiding Partial Transactions (coming next) — how a reset mid-burst corrupts state and how to prevent partial/orphaned transactions.
14.5 — CDC Handshake Safety (coming soon) — the rules that keep VALID/READY safe across domains.

Previous: 14.2 — Asynchronous AXI Bridges. Related: 14.1 — AXI Across Clock Domains for the CDC/synchronizer foundation, and 12.7 — Clock & Reset in Interconnect for reset in the fabric. For the broader protocol catalog, see the AMBA family overview doc.