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

  • Start Here6
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive36
  • SystemVerilog Assertions — Interview-Critical Deep Dive40
  • Functional Coverage in SystemVerilog22
  • Testbench Architecture in SystemVerilog23
  • Advanced Language & Integration25
  • Senior & Interview Preparation21
    • Senior Debug Playbook
    • Reviewing Verification Code
    • Verification Strategy: Spec to Sign-Off
    • SystemVerilog Interview Q&A Bank
      • Q&A: Language Core
      • Q&A: Testbench Plumbing
      • Q&A: Classes and Interfaces
      • Q&A: Constraint and Assertion Fire-Drill
      • Q&A: Scenario and Design Questions
    • Capstone: Verify a Parameterized FIFO
  • Principal-Level Verification28
Loading lesson

‹SystemVerilog Interview Q&A Bank
  1. Topics
  2. SystemVerilog
  3. Senior & Interview Preparation
  4. SystemVerilog Interview Q&A Bank
  5. Q&A: Constraint and Assertion Fire-Drill

Part 8 · Senior & Interview Prep · Intermediate

Q&A: Constraint and Assertion Fire-Drill

Fast revision map for constraint and SVA fluency, with links to the dedicated drills topics.

On this page

    This page is a revision map, not a second source. Each answer below is the ten-second version; the solver math and the sequence depth live in the drills topics.

    A revision map, not a second source

    If the interviewer asks

    Revise in

    Even values, dist weights, soft, solve-before, with, randc

    Randomization interview drills

    Overlapping versus non-overlapping implication, vacuity, repetition, past values, reset handling

    SVA interview drills

    What coverage proves and when it closes

    Coverage closure

    Constraint one-liners you must recite

    Q: Even values, aligned values, how do you constrain them

    Zero the low bits: addr[0] == 1'b0 for even, addr[1:0] == 2'b00 for multiples of four. The bit form shows hardware thinking; multiples of 2 to the N have N low zeros.

    Q: Assign-weight versus divide-weight in dist, what changes

    := weights each value in the range; :/ shares one weight across the range. Both forms also define the legal set: unlisted values can never generate.

    Q: Soft constraints, when do they lose

    A soft constraint is a default the solver drops silently whenever any hard constraint contradicts it. Two contradicting soft constraints resolve by declaration order, derived over base.

    Q: Solve-before, what does it change

    Only the distribution, never the legal set. Solving the rare flag first equalizes branch probabilities that uniform pair-picking would skew.

    Q: Inline with-blocks, whose names do they see

    A with block adds one-call hard constraints layered over the class constraints. Names resolve to the object first, so a local with the same name is shadowed; local:: reaches the test scope.

    Q: Random-cyclic, what is the contract

    randc permutes through every legal value exactly once per cycle. It fits small fields only: no dist, solved before plain rand, and the cycle restarts when constraints change.

    The one-liners below are fragments, so this course's checks do not run them.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    // snippet
    // rand bit [7:0] addr;
    // constraint c_even { addr[0] == 1'b0; }
    // constraint c_len  { len dist { 1 := 50, [2:9] := 5 }; }
    // constraint c_dflt { soft len inside {[1:8]}; }
    // constraint c_ord  { solve err before code; }
    // assert(t.randomize() with { len == local::len; });
    // randc bit [1:0] chan;   // cycles 0,1,2,3 in a fresh order

    The bit math behind the even-value answer runs here directly. The testbench proves the low-bit mask matches modulo for all 256 byte values.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    module tb_even_bits;
      bit [7:0] vec;
      int errors = 0;
      initial begin
        for (int v = 0; v < 256; v++) begin
          vec = v[7:0];
          if ((vec[0] == 1'b0) !== (v % 2 == 0)) errors++;
          if ((vec[1:0] == 2'b00) !== (v % 4 == 0)) errors++;
        end
        if (errors == 0) $display("PASS: low-bit masks match modulo for all 256 byte values");
        else $fatal(1, "FAIL: evenness check wrong");
        $finish;
      end
    endmodule

    Assertion one-liners you must recite

    Q: Overlapping versus non-overlapping implication

    |-> is overlapping: the consequent starts the same cycle the antecedent completes. |=> waits one cycle; a |=> b equals a |-> ##1 b.

    Registered responses need the non-overlapping form. Demanding a same-cycle answer from flopped logic fails correct RTL.

    Q: Vacuous passes, why are they dangerous

    An implication passes vacuously whenever its antecedent never matches, checking nothing. The standing defense is a cover on every antecedent, audited at closure.

    Q: Repetition flavors, where does each match point land

    Consecutive [*N] needs N back-to-back cycles. Goto [->N] lands exactly on the Nth occurrence. Non-consecutive [=N] counts N occurrences but its endpoint floats, so chaining ##1 after it anchors to the wrong place.

    Q: Past values and reset handling, what are the gotchas

    Before N ticks of history exist, $past returns the type's default value (X for 4-state, 0 for 2-state), so gate the opening cycles. disable iff aborts in-flight attempts asynchronously; an antecedent guard only checks reset at attempt start.

    Assertions sample in the Preponed region, like flops. Waveform cursors showing post-edge values explain most false alarms.

    The one-liners below are fragments, so this course's checks do not run them. Placed in a module with the signals declared, they run under verilator --assert.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    // snippet
    // a_same: assert property (@(posedge clk) req |-> gnt);
    // a_next: assert property (@(posedge clk) req |=> gnt);
    // c_req:  cover property (@(posedge clk) req);
    // a_burst: assert property (@(posedge clk) start |-> (beat [->3]) ##1 done);
    // a_stable: assert property (@(posedge clk) disable iff (!rst_n)
    //   (valid && !ready) ##1 valid |-> data == $past(data));

    The timing idea runs here as plain procedural checks. A combinational path answers same-cycle and a flopped path answers next-cycle, which is exactly how the two operators split.

    two_path_dut.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
    module two_path_dut (
      input  logic clk,
      input  logic req,
      output logic gnt_comb,
      output logic gnt_reg
    );
      assign gnt_comb = req;
      always_ff @(posedge clk) gnt_reg <= req;
    endmodule
    
    module tb_implication;
      timeunit 1ns; timeprecision 1ps;
      logic clk = 0;
      always #5 clk = ~clk;
      logic req, gnt_comb, gnt_reg;
      two_path_dut dut (.*);
      int errors = 0;
      initial begin
        req = 0; @(posedge clk); #1;
        req = 1; #1;
        if (gnt_comb !== 1'b1) errors++;   // overlapping: same-cycle answer
        @(posedge clk); #1;
        if (gnt_reg !== 1'b1) errors++;    // non-overlapping: next-cycle answer
        req = 0;
        @(posedge clk); #1;
        if (gnt_reg !== 1'b0) errors++;
        if (errors == 0) $display("PASS: combinational path answers same-cycle and flopped path next-cycle");
        else $fatal(1, "FAIL: response timing wrong");
        $finish;
      end
    endmodule

    What coverage proves

    Three checkers divide the work: the scoreboard catches data and ordering bugs, assertions catch cycle-accurate protocol violations, and coverage proves what was exercised. Coverage catches nothing by itself.

    A cover on every assertion antecedent turns vacuity from a silent hole into a coverage number. Zero-hit covers at closure name the behaviors no test ever reached.

    The manual counter below is the runnable shape of a covergroup: bins, hits and a closure check. It proves all three request classes were exercised.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    module tb_manual_cover;
      timeunit 1ns; timeprecision 1ps;
      logic [1:0] req;
      int hit_idle = 0, hit_single = 0, hit_multi = 0;
      int errors = 0;
      initial begin
        for (int r = 0; r < 4; r++) begin
          req = r[1:0]; #1;
          case (req)
            2'b00: hit_idle++;
            2'b01, 2'b10: hit_single++;
            default: hit_multi++;
          endcase
        end
        if (hit_idle !== 1 || hit_single !== 2 || hit_multi !== 1) errors++;
        if (errors == 0) $display("PASS: manual bins saw idle once, single twice and multi once");
        else $fatal(1, "FAIL: coverage count wrong");
        $finish;
      end
    endmodule

    Common pitfall

    A dist that never lists a value can never generate it. Chaining ##1 after [=N] anchors to a floating endpoint. Both read as stimulus or assertion bugs when they are really specification slips.

    Interview

    The solve-before marker is one sentence: same solution set, different probability. Say it first, then give the rare-flag example.

    Check yourself len dist { 1 := 50, [2:9] := 5 }: what weight does each value from 2 to 9 carry, and can 10 generate?

    Each carries weight 5, and 10 can never generate. The dist defines the legal set as well as the weights.

    Check yourself A green assertion never saw its antecedent fire. What did it verify?

    Nothing. The passes are vacuous, which is why every assert ships with a cover on its antecedent.

    Related topics

    • Randomization interview drills

    • SVA interview drills

    • Coverage: covergroup basics

    • Coverage: closure

    Previous

    226 / 259

    Next: Q&A: Scenario and Design Questions

    Up next

    Up nextQ&A: Scenario and Design Questions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Q&A: Language Core
    • Q&A: Testbench Plumbing