HRESETn Behavior

This opens Module 15 — Reset and Clocking, the physical foundations that keep AHB transactions whole. The starting point is HRESETn — the AHB reset signal, and its precise semantics. Three things define it. First, it's active-low (n = "negated") — asserted (reset active) when 0, deasserted (normal operation) when 1. Second, its timing rule: it may be asserted asynchronously (so reset takes effect immediately, regardless of the clock — for a clean power-up or emergency reset) but must be deasserted synchronously (released on a rising HCLK edge, so all flip-flops leave reset on the same edge — no metastability). HRESETn is the only AHB signal allowed to be asynchronous to HCLK. Third, the post-reset state: while HRESETn is low, the bus is forced to a known idle state — the master drives HTRANS = IDLE, masters and slaves reset their state, and slaves drive HREADY = 1 and HRESP = OKAY (so the bus is not stuck). After HRESETn deasserts, the master begins its first transfer from this clean, defined starting point. This chapter covers the active-low semantics, the async-assert/sync-deassert rule, and the post-reset idle state.

1. What Is It?

HRESETn is the AHB reset signal, with specific semantics:

• Active-low — asserted (reset) = 0; deasserted (normal) = 1.
• Async assert, sync deassert — may go low any time (immediate reset); must go high on a rising HCLK edge (clean release).
• Only async signal — HRESETn is the only AHB signal allowed to be asynchronous to HCLK.
• Post-reset idle state — while asserted: HTRANS = IDLE (master), state reset, HREADY = 1 and HRESP = OKAY (slaves) — a clean, not-stuck idle.

So HRESETn defines the known, clean starting point for the bus. The active-low convention is standard for resets (n suffix). The async-assert/sync-deassert rule balances immediacy (assert any time — reset must work even if the clock isn't running yet, e.g. at power-up) with cleanliness (deassert on a clock edge — so all flops leave reset together, avoiding metastability from a release near an edge). The post-reset idle state ensures that when reset releases, the bus is in a defined, usable state (idle, ready, OKAY) — not in some random or stuck condition. So HRESETn is the reset that puts the bus in a known idle state, asserted immediately but released cleanly. So it's the foundation of a clean AHB startup.

2. Why Does It Exist?

HRESETn exists because the system needs a defined way to force the bus into a known state (at power-up or recovery), and its specific rules — async assert, sync deassert, idle post-reset state — each serve a purpose: immediate reset, clean release, and a usable starting point.

The need for a known state is the root: at power-up, flip-flops come up in random states — the bus would be in an undefined condition (random HTRANS, random HREADY, masters/slaves in arbitrary states). That's unusable — the bus couldn't operate correctly. So there must be a way to force everything to a known state — that's reset. HRESETn does this: asserting it forces the masters, slaves, and bus signals to defined values (idle, ready, OKAY). So HRESETn exists to establish a known state from the random power-up condition. So it's the bus's "known starting point" mechanism.

The reason it's asserted asynchronously is immediacy and clock-independence: reset must work even when the clock isn't reliable — at power-up, the clock (PLL) may not be stable or running yet. So reset can't depend on the clock to take effect — it must assert asynchronously (immediately, regardless of the clock). So you can hold the chip in reset before the clock is up, and reset takes effect even with no clock. So async assert exists for clock-independent, immediate reset. So it works before the clock is ready.

The reason it's deasserted synchronously is clean release / metastability avoidance: when reset releases, all the flip-flops should leave reset on the same clock edge — so they all start in their reset state together and the first clock edge after release clocks them coherently. If reset deasserted asynchronously (at a random time, possibly near a clock edge), some flops might catch the release this edge and others the next (or go metastable) — a corrupt, inconsistent startup. So reset is deasserted synchronously (aligned to a clock edge, via a reset synchroniser) — so the release is clean and coherent. So sync deassert exists for a metastability-free, coherent release. So the bus starts cleanly. So HRESETn exists because: the system needs to force a known state from random power-up (the why); it's asserted asynchronously for immediate, clock-independent reset (works before the clock is stable); it's deasserted synchronously for a clean, metastability-free, coherent release (all flops leave reset together); and it leaves the bus in a known idle state (HTRANS=IDLE, HREADY=1, HRESP=OKAY) so it's immediately usable (not stuck, not random) after release. So HRESETn is the carefully-specified reset that gives AHB a defined, clean, usable starting point — the foundation every transaction builds on.

3. Mental Model

Model HRESETn as the master power switch and "all-clear" procedure for a factory floor — you can hit the emergency stop any time (async assert — everything halts immediately, even mid-shift, regardless of the clock on the wall), but you restart the floor on a scheduled bell so every station resumes together in sync (sync deassert — no station starts a half-second early and collides with another); and while stopped, every machine sits in a defined safe idle (tools parked, lights green, ready to go) — not frozen mid-action — so when the bell rings, work begins cleanly from a known state.

A factory floor (the AHB bus) needs a way to stop and cleanly restart. The emergency stop (HRESETn assert) can be hit any time — mid-shift, regardless of the clock on the wall — and everything halts immediately (async assert: reset takes effect at once, not waiting for any schedule). This immediacy is essential — you can't wait for the next scheduled moment to stop in an emergency, and at startup the schedule (the clock) might not even be running yet. But the restart is different: you don't let stations resume whenever — you restart on a scheduled bell (sync deassert: aligned to a clock edge) so every station resumes together, in sync — if one started a half-second early (async release near an edge), it might collide with another that hadn't started (metastability/inconsistency). And crucially, while stopped, every machine sits in a defined safe idle — tools parked, lights green, ready (HTRANS=IDLE, HREADY=1, HRESP=OKAY) — not frozen mid-action in some random pose. So when the restart bell rings, every station begins work cleanly from a known, safe state. So: stop immediately any time, restart together on the bell, and sit in a defined ready-idle while stopped.

This captures HRESETn: the emergency stop hittable any time = async assert (immediate, clock-independent); the scheduled restart bell = sync deassert (clock-edge-aligned, coherent); stations colliding if one starts early = metastability from async release; the defined safe idle while stopped = the post-reset idle state (HTRANS=IDLE, HREADY=1, HRESP=OKAY); beginning work cleanly from a known state = the master starting its first transfer post-reset. Stop immediately, restart together on the bell, sit in a ready-idle while stopped.

Watch HRESETn force idle then release synchronously:

The model's lesson: stop immediately, restart together on the bell, sit in a ready-idle while stopped. In the waveform, reset forces the clean idle (IDLE/ready/OKAY), then releases on a clock edge, and the master starts its first transfer from the known state.

4. Real Hardware Perspective

In hardware, HRESETn is distributed to every master and slave (resetting their flops), generated through a reset synchroniser (async assert, sync deassert), and the reset values of the bus-control flops give the post-reset idle state.

The reset distribution: HRESETn is a global signal routed to every master and slave on the bus (and the interconnect). Each block uses it to reset its flip-flops — the master's state machine to IDLE, the slaves' state machines to their idle/ready state, the interconnect's logic to a known state. So in hardware, HRESETn fans out to all blocks' reset inputs. So it resets the whole bus subsystem.

The reset synchroniser: to achieve async-assert/sync-deassert, the reset path uses a reset synchroniser — typically a couple of flip-flops that pass the asserted (low) value through immediately (async assert — the low propagates without waiting for a clock) but register the deassertion (sync deassert — the rising edge releases reset only on a clock edge, through the synchroniser flops, avoiding metastability from a release near an edge). So in hardware, the reset synchroniser is what implements the timing rule. So async-assert/sync-deassert is a circuit, not just a convention. (This is a standard reset-synchroniser pattern, applied to HRESETn.)

The post-reset values from flop reset values: the idle state (HTRANS=IDLE, HREADY=1, HRESP=OKAY) comes from the reset values of the relevant flip-flops: the master's HTRANS-driving logic resets to IDLE, the slaves' HREADY/HRESP logic resets to ready/OKAY. So the post-reset state is built into the blocks' reset values — when HRESETn forces the flops to their reset values, those values are the idle state. So in hardware, the post-reset idle state is the designed reset values of the bus-control flops. So masters/slaves are designed to reset to idle/ready/OKAY. So in hardware, HRESETn is a globally-distributed reset, shaped by a reset synchroniser (async assert, sync deassert), with the post-reset idle state coming from the bus-control flops' designed reset values — together giving every AHB block a clean, coherent, known startup. So the hardware reality: distribute reset, synchronise its release, reset to idle.

5. System Architecture Perspective

At the system level, HRESETn's behavior is part of the SoC reset architecture — the sequencing of resets and clocks at startup — and the async-assert/sync-deassert rule is a fundamental reset-design principle applied throughout the chip, not just to the bus.

The SoC reset sequencing: a chip's startup is a sequence: power stabilizes, the clock (PLL) locks, reset is held (asserted) until the clock is stable, then reset releases (synchronously). HRESETn is part of this sequence — it's held low during power-up / clock-lock (the async assert lets it hold reset even before the clock is stable), then released synchronously once the clock is reliable. So HRESETn's behavior fits the SoC's power-up sequence. So at the system level, HRESETn is one element of the reset/clock startup sequencing — held until the clock is ready, released cleanly. So it's part of a larger startup choreography.

The async-assert/sync-deassert as a universal principle: the async-assert, sync-deassert rule isn't AHB-specific — it's a fundamental reset-design principle applied to resets throughout a synchronous chip. The reasoning (immediate reset, clock-independent assert; clean, metastability-free, coherent release) applies to any reset in any clocked logic. So HRESETn follows the standard reset discipline. So learning it teaches a transferable principle. So at the system level, HRESETn exemplifies the universal reset-design rule — async assert for immediacy/clock-independence, sync deassert for clean coherent release. So it's a general principle, instantiated for AHB.

The clean-startup foundation: the whole point is a clean, defined startup — the bus (and the chip) must come up in a known, usable state so that correct operation can begin. HRESETn's idle post-reset state (HTRANS=IDLE, HREADY=1, HRESP=OKAY) ensures the bus is immediately operable after release — the master can issue its first transfer, the slaves are ready, nothing is stuck. So HRESETn is the foundation of correct bus operation — every transaction depends on the bus having started from this known state. So at the system level, HRESETn's behavior is part of the SoC reset/clock startup sequencing (held until the clock is stable, released synchronously), exemplifies the universal async-assert/sync-deassert reset-design principle (transferable across the chip), and provides the clean, known startup state (idle/ready/OKAY) that all correct bus operation builds on. So HRESETn is where the bus's correctness begins — a defined starting point, established immediately and released cleanly. The rest of the module (reset-safe transfers, reset during a transfer, clocking, CDC) builds on this foundation. So HRESETn is the bedrock of AHB's physical correctness.

6. Engineering Tradeoffs

HRESETn embodies the immediate-assert, clean-release, known-idle reset design.

• Async assert vs sync assert. Async assert lets reset take effect immediately and before the clock is stable (essential at power-up) at the cost of needing a synchroniser for release; sync assert would require a running clock (can't reset before clock-lock). AHB uses async assert.
• Sync deassert vs async deassert. Sync deassert releases all flops coherently on one edge (no metastability) at the cost of the reset synchroniser; async deassert risks inconsistent/metastable release (some flops leave reset on different edges). AHB requires sync deassert.
• Known idle state vs undefined. Resetting to a defined idle (HTRANS=IDLE, HREADY=1, HRESP=OKAY) makes the bus immediately usable post-reset at the cost of designing the reset values; leaving it undefined would be unusable (random/stuck). AHB defines the idle state.
• Active-low vs active-high. Active-low (HRESETn) is the standard convention (and often better for noise immunity / default-reset behavior); the choice is conventional. AHB uses active-low.

The throughline: HRESETn is the active-low AHB reset — asserted asynchronously (immediate, clock-independent reset, essential at power-up) but deasserted synchronously (released on a rising HCLK edge so all flops leave reset coherently, no metastability); it's the only AHB signal allowed asynchronous. While asserted, the bus is forced to a known idle state — HTRANS = IDLE, HREADY = 1, HRESP = OKAY — so it's not stuck and is immediately usable after release. It's distributed to all blocks (via a reset synchroniser), the idle state comes from the bus-control flops' reset values, and it's the foundation of a clean SoC startup — exemplifying the universal async-assert/sync-deassert reset principle.

7. Industry Example

Trace HRESETn through an SoC power-up.

A microcontroller powers up; trace the reset sequence and the bus startup.

• Power-up (reset held). As power stabilizes, HRESETn is held low (asserted) — the reset controller asserts it asynchronously (immediately, before the clock is even stable). The whole bus subsystem (CPU master, memory/peripheral slaves, interconnect) is held in reset — all flops forced to their reset values.
• The bus in reset. While HRESETn is low, the bus is in its known idle state: the CPU master drives HTRANS = IDLE, the slaves drive HREADY = 1 and HRESP = OKAY. The bus is not stuck — it's a clean, defined idle. (Even though the CPU isn't executing yet, the bus signals are in their reset-defined idle.)
• Clock locks. The PLL locks and the clock (HCLK) becomes stable. Reset has been held through this (async assert didn't depend on the clock).
• Synchronous release. Once the clock is stable, the reset controller deasserts HRESETn synchronously — released on a rising HCLK edge, through a reset synchroniser, so all the bus flops leave reset on the same edge (coherent, no metastability).
• First transfer. From the synchronous release, the CPU begins executing — its first bus transfer is the first instruction fetch (HTRANS = NONSEQ, the reset-vector address). The bus operates correctly from the clean idle state.
• The async-release bug (counter-example). Had the reset been released asynchronously (e.g. a poorly-designed reset path without a synchroniser), some flops might have left reset a cycle before others — the CPU's FSM could come up in a bad state, or the bus in an undefined condition — an intermittent startup failure (working most resets, failing occasionally when the release lands in a metastability window). The synchroniser prevents this.

The example shows HRESETn in action: held low (async assert) through power-up/clock-lock, forcing the bus to its known idle state, then released synchronously (via a synchroniser) once the clock is stable, so the bus starts cleanly and the CPU's first fetch proceeds from a defined state. The async-release counter-example shows why sync deassert matters. This is how HRESETn gives a clean SoC startup.

8. Common Mistakes

9. Interview Insight

HRESETn is a foundational interview topic — the async-assert/sync-deassert rule (and why), and the post-reset idle state are the signals.

The answer that lands gives the timing rule and the post-reset state: "HRESETn is the AHB reset, active-low — asserted when it's 0, deasserted when it's 1. The key behavioral rule is its timing: it may be asserted asynchronously, so reset takes effect immediately regardless of the clock — which is essential at power-up, when the clock may not be stable or even running yet — but it must be deasserted synchronously, released on a rising HCLK edge, so that all the flip-flops leave reset on the same edge. The reason deassertion must be synchronous is metastability: if reset released asynchronously, near a clock edge, some flops might leave reset on one edge and others on the next, or go metastable — an inconsistent, corrupt startup. So a reset synchroniser passes the asserted-low through immediately but registers the release to a clean clock edge. HRESETn is actually the only AHB signal allowed to be asynchronous to HCLK. And while it's asserted, the bus is forced to a known idle state: the master drives HTRANS = IDLE, masters and slaves reset their state, and slaves drive HREADY = 1 and HRESP = OKAY, so the bus isn't stuck — it's a clean, defined idle. After deassertion, the master starts its first transfer from that known state. So it's active-low, async-assert and sync-deassert, leaving the bus in a clean idle." The async-assert/sync-deassert rule (with the metastability reasoning) and the post-reset idle state are the senior signals.

10. Practice Challenge

Reason from HRESETn behavior.

1. The semantics. State HRESETn's polarity, the async-assert/sync-deassert rule, and the post-reset state.
2. Why async assert. Explain why assertion is asynchronous (power-up, clock-independence).
3. Read the waveform. From Figure 2, identify the reset idle state and the synchronous release.
4. Why sync deassert. Explain what goes wrong with an asynchronous release (metastability, inconsistent startup).
5. Post-reset state. Explain why the bus resets to HTRANS=IDLE, HREADY=1, HRESP=OKAY.

11. Key Takeaways

• HRESETn is the active-low AHB reset — asserted = 0, deasserted = 1.
• Asserted asynchronously, deasserted synchronously — async assert takes effect immediately and before the clock is stable (essential at power-up); sync deassert releases all flops coherently on one clock edge (no metastability). It's the only AHB signal allowed asynchronous.
• Async release is a bug — an asynchronous deassertion risks metastability / inconsistent startup (flops leaving reset on different edges) — use a reset synchroniser.
• The post-reset state is a known idle — HTRANS = IDLE (master), state reset, HREADY = 1 and HRESP = OKAY (slaves) — so the bus is not stuck and is immediately usable; the master starts its first transfer from it.
• In hardware: globally distributed reset, shaped by a reset synchroniser, with the idle state from the bus-control flops' designed reset values.
• It's the clean-startup foundation — part of the SoC reset/clock sequencing (held until the clock is stable, released synchronously), exemplifying the universal async-assert/sync-deassert reset principle. Every transaction builds on this known starting point.

12. What Comes Next

You now understand HRESETn — the active-low, async-assert/sync-deassert reset that gives AHB a clean, known startup. The next chapters cover reset's interaction with transfers and the clocking concerns:

• Reset-Safe Transfers (next) — the rules that keep transfers safe around reset.
• Reset During an Active Transfer — how an in-flight transfer behaves when reset asserts.
• Clock Gating, Low-Power Implications, CDC Bridges — safe clock gating, power, and crossing clock domains.

To revisit the idle transfer type this resets to, see HTRANS & Bus Control; for HREADY (driven high in reset), see What HREADY Means.