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
    • Randomization Basics: rand, randc & randomize()
    • Constraint Operators & Expressions
    • Dynamic Constraint Control
    • Randomizing Arrays and Queues
    • How the Constraint Solver Works
    • Debugging Randomization Failures
    • Interview Drills — Constraints and Randomization Q&A
      • Even/Odd, Alignment & Divisibility
      • Powers of 2, One-Hot & Bit Games
      • Unique Values & Ordering
      • Sum, Checksum & Distribution Drills
      • Dependent-Field Puzzles
      • Q&A: rand, randc & randomize()
      • Q&A: dist, inside, soft, solve-before
      • Q&A: Controlling Randomization
      • Q&A: Arrays & Nested Objects
  • SystemVerilog Assertions — Interview-Critical Deep Dive40
  • Functional Coverage in SystemVerilog22
  • Testbench Architecture in SystemVerilog23
  • Advanced Language & Integration25
  • Senior & Interview Preparation21
  • Principal-Level Verification28
Loading lesson

‹Interview Drills — Constraints and Randomization Q&A
  1. Topics
  2. SystemVerilog
  3. Constraint Randomization — Interview-Critical Deep Dive
  4. Interview Drills — Constraints and Randomization Q&A
  5. Even/Odd, Alignment & Divisibility

Part 3 · Constraint Randomization · Intermediate

Even/Odd, Alignment & Divisibility

Drill: an even value, an address aligned to a random size, and a range with a hole.

On this page

    Why this matters

    An interviewer asked for an even address aligned to a random size, and the candidate wrote an assignment in post_randomize. It worked, and it was the wrong answer: the solver never saw the rule.

    After this lesson you can: write parity, size-dependent alignment and a range with a hole as constraints, under time pressure, and check them on a real solver.

    The three prompts

    Drill 1. rand bit [7:0] x: make x even.

    Drill 2. rand bit [31:0] addr and rand bit [3:0] size: size is 1, 2, 4 or 8, and addr is a multiple of size. Both are random in the same call.

    Drill 3. rand bit [15:0] x: x is between 0 and 1000, but never between 100 and 200.

    Write the three answers before opening the reveal. Copy the starter into the Code Lab, fill in each empty answer_c, and run it on Verilator. The grader solves each class hundreds of times and checks every result, then pins a few values that must be legal; it prints ok or the first rule your answer broke.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    // Drill starter: write each answer_c, then run it.
    // Drills: parity, alignment and holes.
    class drill1;                                   // x is even
      rand bit [7:0] x;
      constraint answer_c { /* your answer here */ }
    endclass
    
    class drill2;                                   // size is 1, 2, 4 or 8, and addr is a multiple of size
      rand bit [31:0] addr;
      rand bit [3:0]  size;
      constraint answer_c { /* your answer here */ }
    endclass
    
    class drill3;                                   // x is 0 to 1000 but never 100 to 200
      rand bit [15:0] x;
      constraint answer_c { /* your answer here */ }
    endclass
    
    Predict first Before you write drill 3: what does 100 <= x <= 200 constrain?

    Nothing useful. It parses as (100 <= x) <= 200, a 1-bit result compared with 200, which is always true. Write two relations, or use inside.

    Check yourself Reveal one set of answers (open only after your own run)

    One set of answers, run through the same grader:

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    // Drills: parity, alignment and holes.
    class drill1;                                   // x is even
      rand bit [7:0] x;
      constraint answer_c { x[0] == 1'b0; }
    endclass
    
    class drill2;                                   // size is 1, 2, 4 or 8, and addr is a multiple of size
      rand bit [31:0] addr;
      rand bit [3:0]  size;
      constraint answer_c { size inside {1, 2, 4, 8}; (addr & (size - 1)) == 0; }
    endclass
    
    class drill3;                                   // x is 0 to 1000 but never 100 to 200
      rand bit [15:0] x;
      constraint answer_c { x inside {[0:1000]}; !(x inside {[100:200]}); }
    endclass
    
    Terminal
    drill 1, even x: ok
    drill 2, aligned addr: ok
    drill 3, range with a hole: ok
    PASS: all 3 drills right

    Why these answers

    Form

    Spelling

    When to reach for it

    Bit slice

    x[0] == 0

    Production code: a single cheap equality

    Modulo

    x % 2 == 0

    Any divisor, including non-powers of two

    Shift round-trip

    (x >> 1) << 1 == x

    Showing bit mechanics on a whiteboard

    For alignment, size - 1 is a mask of the low bits only when size is a power of two: for 8 it is 0111, so three address bits go to zero. The solver picks size and addr together, in one call. When size can be 3, the mask fails and addr % size == 0 with size > 0 is the answer.

    For the hole, a range and a negated inside combine: x inside {[0:1000]}; !(x inside {[100:200]});. Writing the two outer pieces, x inside {[0:99], [201:1000]}, is the same set.

    A note on the grader: Verilator 5.048 spreads this hole range unevenly. Across 400 calls it gave fewer than 15 values below 100, where an even spread over the 900 legal values gives about 44. That is why the grader pins values such as 0 and 99 instead of waiting for random results to land there.

    Common pitfall

    Chained comparisons compile cleanly and never error, which makes them the worst kind of bug. Write two relations, or one inside, never the math-notation chain.

    Interview

    Likely follow-ups: align to a size of 3, exclude a hole the test sets at run time, and keep a random window feasible. The answers are modulo, a negated inside over state bounds, and a check of the gap in test code before the call.

    Remember

    • Evenness is x[0] == 0; alignment to a power of two is a low-bit mask.

    • 100 <= x <= 200 constrains nothing; write two relations or inside.

    • A pinned call checks that a value is legal without waiting for luck.

    Rule of thumb: write the drill before opening the reveal.

    How this was checked

    Run with Verilator 5.048 (--binary --timing) on 2026-10-18; every bench printed the PASS line shown. Verilator prints a harmless WIDTHTRUNC warning for if (!obj.randomize()), because randomize() returns an int, and an UNSATCONSTR warning when a solve fails on purpose. Icarus 13 does not support constraints.

    Each starter was run with its answers left empty, and its grader reported all three drills wrong; each revealed answer passed the same grader. The graders also caught an unwidened size * count and an over-tight even rule when tried.

    Related topics

    • Powers of 2, One-Hot and Bit Games

    Previous

    92 / 259

    Next: Powers of 2, One-Hot & Bit Games

    Up next

    Up nextPowers of 2, One-Hot & Bit Games

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Unique Values & Ordering
    • Sum, Checksum & Distribution Drills
    • Dependent-Field Puzzles