Reset Sequencing Across a Design

Chapter 7 · Section 7.4 · Reset & Initialization Debug

Project thread — the counter and FSM live in one reset domain; the mini-SoC ahead has several (CPU, timer, UART, bus) with dependencies. This lesson is how their resets are distributed and ordered so no block comes up X.

1. Why Should I Learn This?

A single flop's reset can be perfect and the design can still power up X — because reset is distributed.

• Coverage: reset must reach every flop (tree fan-out) or a subtree stays X (2.6/4.5).
• Ordering: a block released before its dependencies samples their X/invalid state.
• Domains: multiple resets, released in a dependency order.

This scales reset debugging from one flop to a whole design (and the mini-SoC).

2. Real Silicon Story — the block that came up X because it woke too early

In a multi-block design, one block powered up X even though its own reset was connected and correct.

The block's reset released early, while an upstream block it depended on was still held in reset. So it came out of reset and immediately sampled the upstream block's X/invalid outputs, latching garbage. Its own reset was fine — the release ordering across domains was wrong. Fixing the release sequence (upstream out of reset first) cleared it.

Lesson: a block can be correctly reset and still come up X if it's released before the blocks it depends on. Reset ordering across domains matters as much as connecting reset.

3. Concept — coverage, domains, and release order

Coverage — reset must reach every flop:

• Reset is distributed through a reset tree (buffered fan-out) to all flops that need it.
• A subtree the reset doesn't reach stays X — a reset gap at block scale (2.6), analogous to partial SDF coverage (4.5).

Domains — multiple resets:

• Real designs have multiple reset domains (per block, per clock, per power island).
• Each domain has its own reset assert/release.

Ordering — assert and release:

• Assertion order — usually less critical (asserting reset is safe, 7.3).
• Release order — critical: a block released before the blocks it depends on samples their X/invalid state.
• A reset/power controller releases resets in a dependency-respecting order.
• Reset-tree skew shifts release timing across the die (and interacts with recovery/removal, 7.3).

Framing:

• Reset sequencing is a design concern; GLS surfaces its failures (a block up X from early release or a gap).
• GLS is dynamic — it shows what your stimulus exercises; STA and reset-timing analysis sign off (0.3).

4. Mental Model — wake the kitchen before the waiters

Bringing a design out of reset is like opening a restaurant.

• Coverage: flip the lights on in every room — miss one and that room stays dark (X).
• Ordering: wake the kitchen (upstream) before the waiters (downstream) — a waiter who starts taking orders before the kitchen is ready collects requests no one can fill (samples X/invalid).
• The manager (reset controller) wakes staff in dependency order.

A perfectly rested waiter still fails if sent out before the kitchen is open — that's an ordering bug, not a per-person one.

5. Working Example — release ordering and a coverage gap

Release ordering in a reset controller (representative):

// Reset controller — REPRESENTATIVE. Release UPSTREAM before DOWNSTREAM (dependency order).
always_ff @(posedge clk or negedge por_n)
  if (!por_n) {rst_b_n, rst_a_n} <= 2'b00;         // assert all (safe, 7.3)
  else begin
    rst_b_n <= 1'b1;                                // release B (upstream) FIRST
    rst_a_n <= rst_b_n;                             // release A (downstream) only AFTER B is out
  end
// If A released before B, A samples B's X/invalid outputs -> A comes up X.

A coverage gap (reset doesn't reach a subtree):

// Reset-tree gap — REPRESENTATIVE. One domain's reset net not connected -> subtree stays X.
// blk_c flops driven by rst_c_n, but rst_c_n was never wired from the controller:
DFFRX1 u_c (.D(d), .CK(clk), .RN(rst_c_n), .Q(q));  // rst_c_n floating/unconnected -> q = X (gap)

Practical context (representative, tool-neutral):

# Reset-sequencing checks (tool-neutral):
#   coverage: does reset reach EVERY flop in every domain? (subtree X -> gap, 2.6/4.5)
#   order:    is each block released AFTER the blocks it depends on? (else samples X/invalid)
#   controller: releases resets in dependency order; watch reset-tree skew (7.3)
#   GLS surfaces both; reset-timing signoff (recovery/removal across paths) is STA (0.3)

A downstream block released before its dependency, as a real waveform:

6. Debugging Session — a block up X from early release

7. Common Mistakes

• Assuming a correct local reset means the block is fine. Release order and coverage also matter.
• Releasing downstream before upstream. The downstream block samples upstream X.
• Missing a reset-tree gap. A subtree the reset never reaches stays X (2.6/4.5).
• Ignoring reset-tree skew. It shifts release timing (interacts with recovery/removal, 7.3).
• Treating reset as one global event. It's distributed across domains.

8. Industry Best Practices

• Release resets in dependency order (upstream before downstream) via a controller.
• Verify reset coverage — every flop in every domain (no subtree gap).
• Account for reset-tree skew in release timing (7.3).
• Define reset domains explicitly and their dependencies.
• Use GLS to surface sequencing X, STA to sign off reset timing.

Senior Engineer Thinking

• Beginner: "This block is X but its reset is connected — I don't get it."
• Senior: "Its reset is fine — was it released before the block it depends on? If A wakes before B, A samples B's X. This is a release-ordering bug, not a local reset."

The senior thinks in reset domains and order, not just per-flop connection.

Silicon Impact

Reset sequencing bugs are system-level power-up failures — a block that samples an upstream block's X at bring-up can latch a garbage configuration, hang the bus, or corrupt state, producing intermittent, hard-to-reproduce power-up failures in silicon (0.3) even though every individual reset is correct. As designs grow to multiple domains (the mini-SoC: CPU, bus, peripherals), the release order and coverage become first-order correctness concerns. GLS is uniquely good at surfacing these (a block visibly up X from early release), and a dependency-ordered reset controller plus verified coverage is the fix. Getting sequencing right is what makes a multi-block chip come up cleanly, every time.

Engineering Checklist

• Released resets in dependency order (upstream before downstream).
• Verified coverage — reset reaches every flop in every domain (no gap).
• Accounted for reset-tree skew in release timing (7.3).
• Defined reset domains and their dependencies explicitly.
• Used GLS to surface sequencing X; deferred reset-timing signoff to STA.

Try Yourself

1. Build two blocks where A samples B's output; release A's reset before B's.
2. Observe: A comes out of reset while B is still resetting, samples B's X, and out_a is corrupted.
3. Change: reorder the controller to release B before A.
4. Expect: A now samples valid B data — clean. Then disconnect one block's reset entirely and watch that subtree stay X (coverage gap), independent of order.

Any free Verilog simulator reproduces reset ordering and coverage effects. No paid tool required.

Interview Perspective

• Weak: "Reset is a global signal — assert it and everything resets."
• Good: "Reset is distributed through a tree to multiple domains, and release order matters — a block released before its dependencies samples their X."
• Senior: "Two failure modes: coverage (reset must reach every flop, or a subtree stays X) and ordering (release upstream before downstream, or the downstream samples upstream X). A block up X with a correct local reset is usually a sequencing bug. GLS surfaces it; STA signs off reset timing."

9. Interview / Review Questions

10. Key Takeaways

• Reset is distributed, with two failure modes: coverage (must reach every flop via the reset tree, or a subtree stays X — 2.6/4.5) and ordering (release in the right sequence).
• Real designs have multiple reset domains; the release order is critical — a block released before the blocks it depends on samples their X/invalid state.
• A reset/power controller releases resets in a dependency-respecting order; reset-tree skew shifts release timing (interacts with recovery/removal, 7.3).
• A block coming up X with a correct local reset is usually a sequencing bug (early release) or a coverage gap — not a local reset problem.
• Reset sequencing is a design concern that GLS surfaces; reset-timing signoff across paths/corners is STA (0.3). Next: 7.5 — debugging a stuck reset (the counter).

Quick Revision

Reset is distributed: two failure modes — coverage (reach EVERY flop via the reset tree, else subtree X, 2.6/4.5) and ordering (release upstream before downstream, else the downstream samples upstream X). Multiple domains, released in dependency order by a controller; watch reset-tree skew (7.3). A block up X with a correct local reset = a sequencing bug. GLS surfaces it; STA signs off reset timing. Next: 7.5 — debugging a stuck reset.