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. Sum, Checksum & Distribution Drills

Part 3 · Constraint Randomization · Intermediate

Sum, Checksum & Distribution Drills

Drill: four bytes totalling 600, a 70/20/10 weighting, and a delay budget.

On this page

    Why this matters

    A byte-total drill passed on one simulator and failed every call on another. The answer had not widened the sum, and only one tool forgave it.

    After this lesson you can: write a widened total, a weighting with the right operator, and a bounded budget, and know which mistakes a given tool will forgive.

    The three prompts

    Drill 1. rand bit [7:0] b[4]: the four bytes total exactly 600.

    Drill 2. rand bit [1:0] kind: kind 0 about 70% of the time, kind 1 about 20%, kind 2 about 10%, and never 3.

    Drill 3. rand bit [4:0] d[4]: four delays, each 1 to 20 cycles, totalling exactly 40.

    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
    // Drill starter: write each answer_c, then run it.
    // Drills: sums and weights.
    class drill1;                                   // four bytes total exactly 600
      rand bit [7:0] b[4];
      constraint answer_c { /* your answer here */ }
    endclass
    
    class drill2;                                   // kind 0, 1, 2 about 70, 20 and 10 percent; never 3
      rand bit [1:0] kind;
      constraint answer_c { /* your answer here */ }
    endclass
    
    class drill3;                                   // four delays, each 1 to 20 cycles, total exactly 40
      rand bit [4:0] d[4];
      constraint answer_c { /* your answer here */ }
    endclass
    
    Predict first Before you write drill 2: kind inside {0, 1, 2} gives every value the same chance. Why can it not do this job?

    inside only says which values are legal. Only dist sets weights.

    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
    // Drills: sums and weights.
    class drill1;                                   // four bytes total exactly 600
      rand bit [7:0] b[4];
      constraint answer_c { b.sum() with (int'(item)) == 600; }
    endclass
    
    class drill2;                                   // kind 0, 1, 2 about 70, 20 and 10 percent; never 3
      rand bit [1:0] kind;
      constraint answer_c { kind dist { 0 := 70, 1 := 20, 2 := 10 }; }
    endclass
    
    class drill3;                                   // four delays, each 1 to 20 cycles, total exactly 40
      rand bit [4:0] d[4];
      constraint answer_c { foreach (d[i]) d[i] inside {[1:20]}; d.sum() with (int'(item)) == 40; }
    endclass
    
    Terminal
    drill 1, bytes total 600: ok
    drill 2, 70 / 20 / 10 weights: ok
    drill 3, delay budget of 40: ok
    PASS: all 3 drills right

    Why these answers

    The standard sums bit [7:0] elements in 8 bits, so b.sum() == 600 can never hold, and a smaller target can be met by bytes whose real total wraps. Widen each item: b.sum() with (int'(item)). State the feasibility bounds aloud too: four bytes reach 0 to 1020, so 600 is inside.

    The grader cannot catch an unwidened sum on Verilator 5.048, which computed the total wide and solved it anyway. Another simulator fails every call. Write the widened form, which is right everywhere.

    Bin

    :/ total

    := total

    [1:10] weight 50, plus 20 weight 50

    50 + 50 = 100; x == 5 gets 5%

    500 + 50 = 550; x == 5 gets about 9.1%

    Single values {0, 1, 2}

    Identical: no range to split

    Identical: no range to split

    Weights are relative, so 7:2:1 and 70:20:10 agree. Values left out of a dist are illegal, which is what keeps kind 3 away.

    A budget is bounded elements plus a pinned total. The per-element bounds matter: without them one delay can take the whole budget and starve the rest. The grader pins 20 + 18 + 1 + 1 to catch an answer that bounds the elements too tightly.

    Common pitfall

    An unwidened sum is the most-asked trap on this page. Any byte total above 255 wraps under the standard, and the wrapped value can still satisfy the comparison.

    Interview

    Likely follow-ups: equal probability over disjoint sets, a jittered average pinned exactly, and an arbiter fairness bound. The answers are := per value, bounded elements plus a pinned sum, and a sum over a comparison.

    Remember

    • Widen every sum with int'(item).

    • Only dist sets weights; values left out are illegal.

    • A budget is bounded elements plus a pinned total.

    Rule of thumb: write the form that is right on every tool, not the one that passes on yours.

    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.

    Verilator solved the unwidened b.sum() == 600, so the grader cannot catch that mistake on it.

    Related topics

    • Dependent-Field Puzzles

    Previous

    95 / 259

    Next: Dependent-Field Puzzles

    Up next

    Up nextDependent-Field Puzzles

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Even/Odd, Alignment & Divisibility
    • Powers of 2, One-Hot & Bit Games
    • Q&A: rand, randc & randomize()