Constraint Override in System Verilog:

Reusing a base class and tightening its random ranges in a derived class is a common testbench need. SystemVerilog lets you do this cleanly through constraint naming. Understanding the same-name versus different-name rule saves you from confusing randomization failures.

A simple way to picture it

Think of a house rule written on the fridge: “bedtime is 9 pm.” If a parent later writes a new note titled with the same words, “bedtime,” saying 10 pm, the new note replaces the old one; there is one bedtime rule and it says 10 pm. But if the new note has a different title, such as “weekend bedtime,” now there are two rules and both apply. If the two rules disagree for the same night, nobody can follow both, and the plan fails. Constraint names work the same way.

Same name: the child overrides the parent

When the child constraint has the same name as the parent constraint, the child block replaces the parent block. The solver only sees the child rule. Here the parent limits data to 100 through 200, but the child restates the same constraint name as 250 through 500, so the result lands in the child range.

class base_pkt;
  rand int data;
  constraint c_range { data inside {[100:200]}; }
endclass

class child_pkt extends base_pkt;
  // same name c_range => replaces the parent rule
  constraint c_range { data inside {[250:500]}; }
endclass

module tb;
  initial begin
    child_pkt p = new();
    if (p.randomize())
      $display("data = %0d", p.data);   // 250..500
    else
      $display("randomize failed");
  end
endmodule

Because the names match, the parent range is gone. Every solved value falls in 250 through 500.

Different name: both constraints apply

If the child uses a different constraint name, the parent rule is not replaced. Both are active at once. When the two ranges do not overlap, there is no legal value and randomize returns 0.

class base_pkt;
  rand int data;
  constraint c_range  { data inside {[100:200]}; }
endclass

class child_pkt extends base_pkt;
  // different name => added, not replaced
  constraint c_child  { data inside {[250:500]}; }
endclass

module tb;
  initial begin
    child_pkt p = new();
    if (p.randomize())
      $display("data = %0d", p.data);
    else
      $display("randomize failed: ranges do not overlap");  // this runs
  end
endmodule

Here 100 to 200 and 250 to 500 have no common value, so no number can satisfy both. The randomize call fails. If the two ranges had overlapped, the solver would pick a value from the overlap.

Same name vs different name at a glance

Example: overlapping different-name constraints

Different names do not always fail. If the two ranges share values, the solver simply picks from the shared part. Here the child narrows the parent instead of contradicting it.

class base_pkt;
  rand int data;
  constraint c_range { data inside {[100:300]}; }
endclass

class child_pkt extends base_pkt;
  constraint c_tight { data inside {[200:400]}; }
endclass

module tb;
  initial begin
    child_pkt p = new();
    if (p.randomize())
      $display("data = %0d", p.data);   // 200..300, the overlap
  end
endmodule

Expected output, in plain words

The same-name example always prints a value between 250 and 500 because the child rule replaced the parent. The non-overlapping different-name example prints the failure message because no value can satisfy both. The overlapping different-name example prints a value between 200 and 300, the shared part of the two ranges.

Note: these outputs describe what the code is written to produce from a read of the IEEE 1800 LRM. Randomization picks a legal value, so the exact number varies by run and seed. Compile and run on your own simulator or EDA Playground to confirm.

When to use each approach

• Same name to replace: use it when a derived test needs a completely different range and the base rule should no longer apply.
• Different name to add: use it when you want to keep the base rule and tighten it further, so both hold.
• Turn a rule off instead: if you only need to disable a base constraint for one test, consider constraint_mode(0) rather than redefining it.

Common mistakes to avoid

• Expecting a different-name child to replace the parent: it does not; both apply and may clash.
• Contradicting ranges by accident: non-overlapping different-name constraints make randomize fail silently unless you check the return value.
• Ignoring the randomize return value: always test if (p.randomize()) so a failure does not pass unnoticed.
• Forgetting inheritance still applies: a same-name child override affects every place that uses the child handle, including through a base handle.

Constraint override vs constraint_mode

Overriding by name changes what a rule says. If you instead want to keep the rule defined but switch it off for a specific run, use constraint_mode(0) to disable it and constraint_mode(1) to enable it again. Override edits the rule; constraint_mode toggles it. We cover toggling in our guide on enable and disable constraint.

For the difference between the two ways to call randomization, see randomize vs std::randomize. More on class rules is in our guide on inheritance, and more tutorials are in the SystemVerilog section.

Frequently asked questions

Share this post: on Twitter on Facebook