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
    • Testbench Anatomy & Layering
    • Stimulus: Generators, Transactions & Drivers
      • Transaction Design for Stimulus
      • Layered Constraint Architecture
      • Shaping Stimulus with Knobs and Policies
      • Protocol Legality and Error Injection
      • Randomizing Scenarios, Not Just Items
      • Generator Patterns
      • Driver Design
      • Mixing Directed and Random Stimulus
    • Monitors, Scoreboards & Reference Models
    • Self-Checking Tests & Regression
    • From Hand-Built TB to UVM
  • Advanced Language & Integration25
  • Senior & Interview Preparation21
  • Principal-Level Verification28
Loading lesson

‹Stimulus: Generators, Transactions & Drivers
  1. Topics
  2. SystemVerilog
  3. Testbench Architecture in SystemVerilog
  4. Stimulus: Generators, Transactions & Drivers
  5. Layered Constraint Architecture

Part 6 · Testbench Architecture · Intermediate

Layered Constraint Architecture

Three constraint layers: spec legality, soft typicality, and per-test intent.

On this page

    The layering principle

    Subclass constraints are ANDed with every inherited constraint, except a block replaced by name. A derived class therefore narrows the solution space and never widens it.

    Layer

    Owner

    Content and lifetime

    Legality

    Protocol spec

    valid_c: what the spec permits, never disabled except for error injection

    Typicality

    VIP author

    Soft defaults and weights, overridable per test

    Test intent

    Test writer

    Subclass, inline, or policy; lives for one test

    The base transaction carries only legality. Every narrower preference lives in a layer above it.

    Base legality plus soft typicality

    The next listing is not run in this course's checks. It is classes only, with no top module.

    design.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
    // not-run: classes only, no top module
    class bus_txn;
      rand bit [31:0] addr;
      rand bit [3:0]  len;
      rand bit [2:0]  size;
      rand bit        write;
      constraint valid_c {
        len inside {[1:15]};
        size <= 3'd2;
        addr % (32'd1 << size) == 0;
      }
      constraint typical_c {
        soft len inside {[1:4]};
        soft size == 3'd2;
      }
    endclass
    
    class long_burst_txn extends bus_txn;
      constraint intent_c { len inside {[12:15]}; }
    endclass
    
    class relaxed_txn extends bus_txn;
      constraint typical_c {
        soft len inside {[1:15]};
        soft size == 3'd2;      // repeated: the override replaces the whole block
      }
    endclass

    Soft marks a low-priority preference per expression: the solver keeps a maximal satisfiable subset against hard constraints. The same-named typical_c block replaces the whole parent block instead of ANDing. Every preference in it goes, so the override repeats soft size == 3'd2 to keep that one. That is why block granularity is the override granularity.

    • No DDR window or bring-up length belongs in the base: those are test intent, not legality.

    • A hard test constraint beats soft typicality with no ceremony and no constraint_mode call.

    • Block naming is the override granularity, so legality and typicality stay in separate blocks.

    Common mistakes

    Common pitfall

    Putting project preferences such as short bursts into valid_c traps future tests. They must then disable legality to escape one preference, or fork a parallel class.

    Interview

    Likely question: how do constraints compose under inheritance?

    They AND, so subclasses narrow and never widen. Same-name blocks replace. The three-layer answer places legality, typicality, and intent with their owners.

    Check yourself A test needs len 12 to 15 while typical_c prefers 1 to 4. What happens?

    The hard intent wins over the soft preference for that expression. Legality still holds, so the burst stays aligned and inside bounds.

    Check yourself What does constraint_mode(0) scattered through tests indicate?

    A layering failure in the base class. Tests fight over-tight hard constraints instead of overriding soft typicality.

    Testbench

    A legality function plus a testbench that proves bias never changes the verdict.

    design.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
    33
    34
    35
    36
    37
    38
    39
    module tb_layers;
      reg [31:0] addr;
      reg [3:0]  len;
      reg [2:0]  size;
      reg        bias_high;
      reg        ok;
      reg        prefer;
      integer    problems;
      // The three valid_c rules, and nothing else.
      task automatic check;
        begin
          ok = 1;
          if (len < 1 || len > 15) ok = 0;
          if (size > 2) ok = 0;
          if ((addr % (32'd1 << size)) != 0) ok = 0;
          prefer = (bias_high && len >= 12);
        end
      endtask
      initial begin
        problems = 0;
        bias_high = 0;
        addr = 32'h1000; len = 4; size = 2; check; if (!ok) problems = problems + 1;
        addr = 32'h1003; len = 1; size = 0; check; if (!ok) problems = problems + 1;
        addr = 32'h2000; len = 15; size = 2; check; if (!ok) problems = problems + 1;
        addr = 32'h3000; len = 0; size = 2; check; if (ok) problems = problems + 1;
        addr = 32'h1002; len = 4; size = 2; check; if (ok) problems = problems + 1;
        addr = 32'h1000; len = 4; size = 3; check; if (ok) problems = problems + 1;
        bias_high = 1;
        addr = 32'h1000; len = 4; size = 2; check;
        if (!ok) problems = problems + 1;
        if (prefer) problems = problems + 1;
        addr = 32'h2000; len = 15; size = 2; check;
        if (!ok) problems = problems + 1;
        if (!prefer) problems = problems + 1;
        if (problems == 0) $display("PASS: legality admits 3 shapes, rejects 3, bias changes none");
        else $fatal(1, "FAIL: found %0d unexpected verdicts", problems);
        $finish;
      end
    endmodule

    Related topics

    • Transaction Design for Stimulus

    • Shaping Stimulus with Knobs and Policies

    Previous

    168 / 259

    Next: Shaping Stimulus with Knobs and Policies

    Up next

    Up nextShaping Stimulus with Knobs and Policies

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Protocol Legality and Error Injection
    • Randomizing Scenarios, Not Just Items
    • Generator Patterns