SystemVerilog Soft Constraints

Ordinary constraints are called hard constraints, because it's mandatory for the solver to always satisfy them — if it can't, randomization fails outright. A constraint declared soft gives the solver some flexibility instead: it doesn't have to be satisfied if some other, higher-priority constraint conflicts with it — either a hard constraint, or a soft constraint the solver has decided takes precedence. Soft constraints are commonly used to specify default values and distributions for random variables.

12 min read | Intermediate Level

What You'll Learn

• The difference between a hard constraint (must always be satisfied) and a soft one (a default that yields to conflicts)
• Why soft applies to individual expressions, not to an entire constraint block, even when both appear together
• What happens when a soft constraint genuinely conflicts with something else — a hard constraint, or an inline one
• Why the exact same conflicting inline constraint produces a completely different outcome depending on whether the original was soft or hard
• How disable soft cleanly replaces an inherited soft default, removing any ambiguity about which of two competing soft constraints actually takes effect

Example

Here, a soft constraint tells the solver to produce values between 4 and 12 for data — but only the first expression is actually soft:

class ABC;
  rand bit [3:0] data;
  
  // This constraint is defined as "soft"
  constraint c_data { soft data >= 4;
                     data <= 12; }
endclass

module tb;
  ABC abc;
  
  initial begin
    abc = new;
    for (int i = 0; i < 5; i++) begin
      abc.randomize();
      $display ("abc = 0x%0h", abc.data);
    end
  end
endmodule

As expected, the randomized values fall within 4 and 12:

ncsim> run
abc = 0x4
abc = 0x8
abc = 0x4
abc = 0x7
abc = 0x7
ncsim: *W,RNQUIE: Simulation is complete.

soft applies only to the specific expression it directly precedes — here, data >= 4. data <= 12 has no soft keyword of its own, so it remains a hard constraint, even though it's sitting in the same block. Mixing soft and hard expressions within one constraint block is completely legal, and each expression's own priority is entirely independent of the others around it.

Now let's see how a contradicting inline constraint is handled:

module tb;
  ABC abc;
  
  initial begin
    abc = new;
    for (int i = 0; i < 5; i++) begin
      abc.randomize() with { data == 2; };
      $display ("abc = 0x%0h", abc.data);
    end
  end
endmodule

The contradicting inline constraint successfully sets data to 2 — contradicting because the original constraint's soft part asked for data >= 4, but the inline constraint demands 2, which is outside that range:

ncsim> run
abc = 0x2
abc = 0x2
abc = 0x2
abc = 0x2
abc = 0x2
ncsim: *W,RNQUIE: Simulation is complete.

Since the inline constraint (data == 2) outranks the soft one, the soft data >= 4 rule simply yields — no failure, no error, just a quietly overridden default. The hard part, data <= 12, is untouched by any of this, since 2 never conflicted with it in the first place.

How Is It Different From Hard Constraints?

Now the same class, with soft removed entirely — both expressions are hard — and the same conflicting inline constraint:

class ABC;
  rand bit [3:0] data;

  constraint c_data { data >= 4;
                     data <= 12; }
endclass

module tb;
  ABC abc;
  
  initial begin
    abc = new;
    for (int i = 0; i < 1; i++) begin
      abc.randomize() with { data == 2; };
      $display ("abc = 0x%0h", abc.data);
    end
  end
endmodule

This time the solver fails outright, because of the contradicting constraint, and data is left at 0:

ncsim> run
      abc.randomize() with { data == 2; };
                  |
ncsim: *W,SVRNDF (./testbench.sv,14|18): The randomize method call failed. The unique id of the failed randomize call is 4.
Observed simulation time : 0 FS + 0
ncsim: *W,RNDOCS: These constraints contribute to the set of conflicting constraints:

  constraint c_data { data >= 4; (./testbench.sv,4)
      abc.randomize() with { data == 2; }; (./testbench.sv,14)
ncsim: *W,RNDOCS: These variables contribute to the set of conflicting constraints:

rand variables:
       data [./testbench.sv, 2]

abc = 0x0
ncsim: *W,RNQUIE: Simulation is complete.

Same class, same conflicting inline value — but a completely different outcome, purely because data >= 4 is no longer negotiable. This is the entire practical value of soft: the exact same rule either yields gracefully or blocks the entire solve, depending only on whether it was declared soft.

Replacing an Inherited Soft Constraint With disable soft

A subclass can inherit a soft constraint from its parent and simply add a conflicting hard constraint of its own — as already shown, the soft one yields automatically, no extra syntax required. But what if the subclass wants to replace that soft default with a different soft default, rather than a hard rule? Adding a second soft constraint on the same variable, without removing the first, leaves two soft constraints competing on the same variable at once — which one actually takes effect then depends on the solver's own priority rules, rather than being something the subclass author explicitly controls.

disable soft removes that ambiguity. Placed inside a constraint block, it strips away any soft constraint currently active on a specific variable, so whatever comes next — soft or hard — is guaranteed to be the only one governing that variable, rather than one of two competing defaults:

class ABC;
  rand bit [3:0] data;

  constraint c_data { soft data >= 4;
                     data <= 12; }
endclass

class XYZ extends ABC;
  constraint c_new {
    disable soft data;             // Remove the inherited soft default entirely
    soft data inside {0, 1, 2};    // This is now the only soft rule on 'data'
  }
endclass

XYZ inherits ABC's constraints, including the soft data >= 4 default and the hard data <= 12 rule. disable soft data; removes just the inherited soft default, leaving the hard data <= 12 constraint from the parent fully intact. The new soft rule, data inside {0, 1, 2}, is now the only soft constraint in play for data — there's no second soft default left to compete with it.

Common Beginner Mistakes