Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
  • Reconvergence and Gray Coding16
  • Reset Domain Crossing16
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
    • RDC Methodology
    • Reset-aware Simulation
      • Why Reset-aware Simulation
      • Reset Sequences and Random Resets
      • Reset Checks and Assertions
      • Reset Coverage
    • Chip-level RDC Closure
    • RDC Signoff Dashboard
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Reset-aware Simulation
  1. Topics
  2. CDC & RDC
  3. RDC Signoff
  4. Reset-aware Simulation
  5. Reset Checks and Assertions

Part 8 · RDC Signoff · All levels

Reset Checks and Assertions

Assertions for reset behaviour: safe outputs during reset, no activity before release, and cleared state.

On this page

    Reset sequences are only as good as their checkers. A test that asserts reset mid-transfer but never checks the outputs during reset proves nothing. Three properties cover most reset behaviour: outputs stay safe while reset is asserted, nothing starts before release is complete, and no stale state survives the reset.

    The three properties

    Property

    What it forbids

    Example on the buffer

    Safe outputs during reset

    Control outputs asserting while the block is in reset.

    The output valid must be low whenever reset is asserted.

    No activity before release

    The block accepting work while still in reset.

    No accept handshake completes while reset is asserted.

    State cleared

    Stale pre-reset state leaking into post-reset operation.

    After release, the buffer is empty: no valid output until a new word is accepted.

    Concurrent assertions, where the simulator supports them

    The properties below are written as concurrent assertions for simulators with assertion support. They state the contract independently of any one test, so every reset sequence in the regression checks them automatically.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    // not-run: concurrent assertions need a simulator with SVA support
    // Properties for the buffer of the previous lesson.
    // Bind the signals clk, rst_n, s_valid, s_ready and m_valid at the point of use.
    property safe_while_in_reset;
      @(posedge clk) !rst_n |-> !m_valid;
    endproperty
    assert property (safe_while_in_reset);
    
    property no_accept_while_in_reset;
      @(posedge clk) !rst_n |-> !(s_valid && s_ready);
    endproperty
    assert property (no_accept_while_in_reset);
    
    property empty_after_release;
      @(posedge clk) $rose(rst_n) |-> ##1 !m_valid;
    endproperty
    assert property (empty_after_release);

    The equivalent plain checker, runnable anywhere

    Where concurrent assertions are unavailable, the same three properties become plain checkers sampled on the falling edge, when all signals are settled. The buffer is repeated here so this example runs on its own.

    xfer_buf_mon.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    `timescale 1ns/1ps
    
    // One-entry valid/ready buffer, repeated so this example runs on its own.
    module xfer_buf_mon (
      input  logic clk,
      input  logic rst_n,
      input  logic s_valid,
      output logic s_ready,
      input  logic [7:0] s_data,
      output logic m_valid,
      input  logic m_ready,
      output logic [7:0] m_data
    );
      logic full_q;
      logic [7:0] data_q;
    
      assign s_ready = ~full_q & rst_n;   // not ready while in reset: a source holding valid must see no accept
      assign m_valid = full_q;
      assign m_data = data_q;
    
      always @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
          full_q <= 1'b0;
          data_q <= 8'h00;
        end else if (s_valid && s_ready) begin
          full_q <= 1'b1;
          data_q <= s_data;
        end else if (m_valid && m_ready) begin
          full_q <= 1'b0;
        end
      end
    endmodule
    

    What the checks and the review look for

    The review checks that every reset sequence in the regression is covered by at least the safe-outputs property, either as a concurrent assertion or as a plain checker, and that the properties are bound in every configuration, not just the default one. An assertion that never fires because it was never bound is worse than no assertion: it looks like coverage.

    Common pitfall

    Checking only the final state after release misses the dangerous window: outputs glitching during reset can trigger neighbours even if the final state is correct. Always check behaviour during reset, not just after it.

    Check yourself The plain checker samples on the falling edge. Why?

    Because all signals are settled there: the design updates on the rising edge and reset moves away from edges, so a falling-edge sample never races the design.

    Check yourself A regression binds the safe-outputs assertion in only one of three configurations. Is reset behaviour proven?

    No. The other two configurations run with no reset checking at all. Bind the properties in every configuration or the passing result is hollow.

    Related topics

    • Reset sequences and random resets

    • Reset coverage

    • RTL: CDC verification

    Previous

    125 / 179

    Next: Reset Coverage

    Up next

    Up nextReset Coverage

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Reset-aware Simulation