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
      • inside, Ranges & Set Membership
      • dist: Weighted Distributions
      • Implication, if/else and solve...before
      • soft Constraints
    • Dynamic Constraint Control
    • Randomizing Arrays and Queues
    • How the Constraint Solver Works
    • Debugging Randomization Failures
    • Interview Drills — Constraints and Randomization Q&A
  • 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

‹Constraint Operators & Expressions
  1. Topics
  2. SystemVerilog
  3. Constraint Randomization — Interview-Critical Deep Dive
  4. Constraint Operators & Expressions
  5. soft Constraints

Part 3 · Constraint Randomization · Intermediate

soft Constraints

Overridable soft defaults, discard order and function-call staging.

On this page

    Why this matters

    A reusable packet class hard-coded its default length, and every test that needed a jumbo frame failed to randomize. A soft default steps aside when a test asks for something else.

    After this lesson you can: write soft defaults, predict which soft constraint survives a conflict, and keep protocol legality hard while policy stays soft.

    soft defaults that yield

    A soft constraint holds whenever it can, and it is dropped when a hard constraint contradicts it. That makes it the natural tool for defaults in reusable transactions.

    While active, a soft constraint is full strength, shaping the set exactly like a hard one. Discarding is all-or-nothing per soft constraint, and only genuine contradiction triggers it.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    // snippet: also in the bench below
    class eth_pkt;
      rand bit [13:0] len;
    
      // Default: ordinary frame sizes, but only a preference
      constraint len_default { soft len inside {[64:1500]}; }
    endclass

    A plain call keeps the default range. A hard inline constraint such as len == 9000 discards the soft one and succeeds, where a hard default would fail on the empty intersection.

    Discard order and soft distributions

    Priority

    Where the soft constraint is written

    Lowest

    Declared earlier in the class

    Higher

    Declared later in the class, or in a derived class

    Highest

    In an inline with at the call

    Hard constraints always hold. Softs are kept from the highest priority down, and one is discarded only if it cannot hold together with every higher-priority soft already kept. Example: class softs x < 10 then x > 5, and an inline soft x == 20: the inline one holds, x > 5 fits with it, and x < 10 is dropped.

    IEEE 1800 18.5.14.1 defines the priority: a later soft in the same class outranks an earlier one, a derived class outranks its base, and an inline with outranks the class. Keep one soft default per field anyway, so the result stays easy to read.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    // snippet: also in the bench below
    class prio_demo;
      rand int x;
      constraint c_low { soft x == 1; }   // declared first: lower priority
      constraint c_high { soft x == 2; }  // declared second: higher priority
    endclass
    // Both cannot hold, so the lower-priority (earlier) soft x==1 is discarded.
    // LRM result (18.5.14.1): x == 2. Keep such chains rare.
    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    // snippet: also in the bench below
    class axi_txn;
      rand bit [1:0] resp;   // 0=OKAY 1=EXOKAY 2=SLVERR 3=DECERR
    
      // Default shape: overwhelmingly OKAY, but only a default
      constraint resp_default { soft resp dist { 0 :/ 95, [2:3] :/ 5 }; }
    endclass
    // An error test with a hard inline resp == 3 discards the soft dist.
    // Soft cannot rescue hard-versus-hard clashes, and soft on randc is illegal.

    Situation

    Outcome

    Soft default alone

    Holds fully, exactly like a hard constraint.

    Soft against hard

    Soft is discarded and randomize succeeds.

    Two soft defaults in tension

    The lower-priority (earlier) soft is discarded, per IEEE 1800 18.5.14.1.

    Hard against hard

    Nothing is dropped and randomize fails.

    Common pitfall

    Treating soft as a weak weight is the costly mistake. Active soft constraints bind fully, and only contradiction removes them. Keep protocol legality hard and put policy defaults in soft.

    Interview

    Contrast soft with constraint_mode(0): soft discards itself per conflict, while the mode call is an explicit procedural toggle of a whole named block.

    Check yourself A test adds a hard inline constraint that clashes with a class-level soft default. What happens?

    The soft constraint is discarded and randomize succeeds with the inline value. Only a hard-versus-hard clash fails.

    Check yourself Two soft constraints in one class contradict each other and nothing else constrains the field. Does randomize() fail?

    No. The earlier-declared soft is discarded and the later one holds; a soft constraint never makes the call fail.

    Testbench

    Predict first eth_pkt has soft len inside {[64:1500]}. A test calls randomize() with { len == 9000; }. Does the call succeed, and what is len?

    It succeeds with len == 9000. The hard inline rule contradicts the soft default, so the soft one is discarded instead of the call failing.

    The classes from this lesson: the soft default, a hard override, two softs in conflict, and a soft dist.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    class eth_pkt;
      rand bit [13:0] len;
      // Default: ordinary frame sizes, but only a preference
      constraint len_default { soft len inside {[64:1500]}; }
    endclass
    
    class prio_demo;
      rand int x;
      constraint c_low  { soft x == 1; }   // declared first: lower priority
      constraint c_high { soft x == 2; }   // declared second: higher priority
    endclass
    
    class axi_txn;
      rand bit [1:0] resp;   // 0=OKAY 1=EXOKAY 2=SLVERR 3=DECERR
      constraint resp_default { soft resp dist { 0 :/ 95, [2:3] :/ 5 }; }
    endclass
    
    Terminal
    inline len == 9000: returned 1, len = 9000
    two softs in conflict: x = 2 (the later one wins)
    soft dist: OKAY in 946 of 1000 (weight 95 of 100)
    PASS: the soft default held until a hard rule contradicted it, and the later soft won the tie

    The standard also discards a soft dist when a hard rule contradicts it. One of the simulators used here does not: a hard resp == 3 made the call fail, so the bench checks only the soft weights.

    Remember

    • A soft constraint binds fully until a hard rule contradicts it, then it is dropped.

    • Later softs beat earlier ones; inline softs beat class softs.

    • Only hard-against-hard conflicts make randomize() fail.

    Rule of thumb: legality hard, defaults soft.

    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.

    Verilator 5.048 did not discard a soft dist when a hard inline rule contradicted it: randomize() returned 0. The bench checks only the soft weights.

    Related topics

    • Next topic: Dynamic Constraint Control

    Previous

    72 / 259

    Next: Dynamic Constraint Control

    Up next

    Up nextDynamic Constraint Control

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • inside, Ranges & Set Membership
    • dist: Weighted Distributions