Soft Constraints in SystemVerilog

Semantics and Challenges

Mark Strickland, Joseph Hanli Zhang Jason Chen, Dhiraj Goswami, Alex Wakefield
Cisco Systems Synopsys Inc.
{mastrick, jhzhang}@cisco.com {jasonc, dhiraj, alexw}@synopsys.com

Abstract—This pape r introduces SystemVerilog soft constraints, examines all the active constraints to generate a legal solution
de scribing their syntax and semantics. We then examine how soft where all constraints are satisfied. Sometimes it would be
constraints can be applied to verification, how they can be used to desirable to have the constraint solver disregard certain
manage constraint complexity and used with VIP. Lastly we constraints if (and only if) no solution is possible when they
discuss tool requirements including debug features.
are included.
Keywords-SystemVerilo g, constraint solver, so ft constraint
This requirement is more pronounced when VIP is used, as
I. INTRODUCTION is typical in today's SoC environment. Here the test writer is
often not familiar with all the constraint details of the VIP and
Constrained random verification is the leading
methodology for verification of chip designs today. As this simply wants to override some of the constraints to generate
methodology has grown in popularity, so has the size and an error condition or direct the distribution of specific
variables. Soft constraints allow the VIP creator to specify
complexity of the environments used to verify increasingly
complex System-on-Chip (SoC) designs. One of the rules that can be easily overridden by the test writer. In other
words, soft constraints provide more scope for relaxing these
challenges facing verification engineers is the number of
constraints present in the verification environment, and how rules.
these constraints are reused between projects or can be
leveraged from existing Verification IP (VIP) components. Soft constraints are the constraints that need to be satisfied
if possible; otherwise, they are disregarded. If no solution is
The IEEE P1800 (SystemVerilog) [1] standard provides possible when all the hard and soft constraints are considered,
individual soft constraints are iteratively disregarded based on
two mechanisms to modify constraints – (1) overriding by
defining a constraint block with the same name, and (2) a priority scheme (described in section III.A). Soft is applied
to individual constraint expressions, not the entire constraint
constraint mode control to enable and disable an existing
constraint block. block, providing fine grain control for each constraint
expression.
The IEEE P1647 (e) standard [2] defines soft constraints as
a mechanism to allow constraints to be overridden by other B. Soft Constraint Examples
constraints. A proposal (Mantis 2987 [3]) was recently
approved by the P1800 working group to add soft constrains to Figure 1 shows a simple example of a soft constraint being
the 2012 revision of the SystemVerilog standard. Later in this honored.
paper we will details the similarities and differences between
e and SystemVerilog soft constraint semantics.
class A;
rand int x;
We believe both of these concepts provide complementary constraint A1 {
ways of managing constraints in a large verification soft x == 10 ;
environment. This paper will describe the semantics for soft }
constraints, discuss methodology for using soft constraints endclass
effectively, and investigate some additional SystemVerilog
specific issues. A obj = new ();
obj.randomize() with {x inside {[8:12]}; };
II. SOFT CONS TRAINT => Result: solver generates x == 10
A. What Are Soft Constraints?
Figure 1 – Soft Constraint Honored Example
SystemVerilog and e simulators both use a constraint
solver to create random stimulus. The constraint solver
 There is a soft constraint (x == 10) and a hard constraint ( However there is one area where we must extend the
x inside { [8:12] } ). The solver will apply maximum semantics for SystemVerilog. e always uses the file order to
satisfiability on constraints and since the soft constraint does determine priority when multiple soft constraints conflict. This
not cause a constraint conflict in the presence of the hard is not possible in SystemVerilog. While SystemVerilog
constraint (i.e. 10 is inside the range between 8 and 12), the requires a limited file order dependency (base class must be
soft constraint is honored. The solver generates a value of 10 compiled before a derived class), it does allow packages and
for the random variable x. units to be compiled in an arbitrary order to a certain extent.
For this reason, SystemVerilog soft constraints must have a
Figure 2 shows a slightly different example with a dropped well-defined priority scheme for determining which
soft constraint. constraints are disabled if there are conflicts between two or
more expressions.
class A;
rand int x; A. Soft Constraint Priorities
constraint A1 { Soft constraints are assigned priorities and this is an
soft x == 10 ; important concept to understand when and how a soft
} constraint is honored or dropped. Obviously, the hard
endclass
constraints must always be satisfied. If there are two soft
A obj = new (); constraints, SC1 and SC2, and SC2 is a higher priority
obj.randomize() with {x inside {[5:9]};}; constraint than SC1, and if both constraints SC1 and SC2 can
be satisfied, then they will both be honored. Otherwise, if SC2
=> Result: solver generates x==5,6,7,8 or 9 can be satisfied, SC1 will be dropped. If the presence of SC2
will cause a constraint conflict, SC2 will be dropped and SC1
Figure 2 – Soft Constraint Dropped Example be honored, if possible. Otherwise both SC1 and SC2 will be
dropped.
If the constraint expression inside the constraint block
“A::A1” were not declared as soft, the call to randomize Mantis 2987 proposal [3] to SV-EC IEEE 1800 committee
would have failed as there would be no solution that would defines the priorities of soft constraints:
satisfy both x == 10 and x inside the range of [5:9]. To - Constraint expressions that appear later in the same
resolve the solver failure, the user would need to introduce construct (constraint block, class, or struct) have
some additional procedural code to turn off the constraint higher priority.
block “A1” or extend class A to override the constraint block - Constraint expressions in out-of-body constraint
“A1” with additional constraints. Either way, it makes the test blocks whose prototypes appear later in the class have
more complicated. higher priority.
- Constraints in contained objects (rand class handles)
With the constraint expression ( x == 10 ) declared as a have lower priority than all constraints in the container
soft constraint, this soft constraint automatically gets turned object (class or struct).
off by the solver because if it were honored, it would have - Constraints in objects whose handles appear later in
been in conflict with the hard constraint ( x inside { [5:9] } ). the container object have higher priority
The outcome is a simpler test. - Constraints in derived classes have higher priority
than all constraints in their super classes
- Constraints within inline constraint blocks have higher
III. SOFT CONS TRAINT SEMANTICS priority than constraints in the class being randomized.
- Latter iterations within a foreach constraint have
Similar to the soft constraint definition in the e verification higher priority than former iterations
language, SystemVerilog soft constraints are often used to
specify default values and relations that can be disregarded in Consider the following example in Figure 3:
the presence of conflicting hard or other soft constraints.
 class M;
rand int x;
constraint a { soft x > 2; soft x < 10; class M;
} rand int x;
endclass constraint a { soft x > 2; soft x < 10; }
endclass
class N extends M;
constraint b; M obj = new();
constraint c { soft x == 5; }
endclass obj.randomize() with { x inside {[0:20]};};
=> Result: x == 3...9
constraint N::b { soft x == 9; }
// disable soft constraints on ‘x’
class Q ; obj.randomize() with {
rand N n; disable soft x;
constraint d { soft n.x inside {[5:8]}; x inside {[0:20]};
} };
endclass => Result: x == 0...20

Q obj = new();
obj.randomize() with { soft n.x >= 7; }; Figure 4 – Disable Soft Example
=> Result: solver generates x = 7 or 8

Figure 3 – Soft Constraint Priority Example IV. M ETHODOLOGY

A. Stimulus Solution Space
All constraints in the above example are soft constraints.
The priorities for the soft constraints are as follows: Constraints are declarative in nature and specify a set of
equations or rules that the solver will use to generate test
Highest stimulus. It is useful to draw a diagram of the possible
x >= 7 inline constraint solution space to describe how the VIP creator and test writer
x inside { [5:8] } Q::d in the container class will modify this space for their needs as shown in Figure 5.
x == 5 N::c (appear later)
x == 9 N::b, out of body (appear earlier)
x < 10; M::a (appear later)
x > 2; M::a (appear earlier)
Lowest

Not all soft constraints above can be satisfied as it is clear

that to satisfy (x >= 7), the highest priority soft constraint in
this example, (x == 5) and (x == 9) constraints could not have
been satisfied. For this reason, these two soft constraints (x
== 5) and (x == 9) are dropped; the other soft constraints are
honored.
The solution for x, considering all the honored soft
constraints, is { [7:8] }.

B. Discarding Soft Constraints

Sometimes a test writer would like to disable or turn off
soft constraints on a variable. This can be accomplished using
the „disable soft‟ construct as shown in Figure 4. The disable
soft construct removes any existing soft constraints on a
variable so new constraints can be applied. This is important
when a soft constraint restricts variable values to a range and
the test level constraints want to expand on this range.
Figure 5 – Solution Space
We have split the diagram into several areas to describe the
B. Comparison of Constraint Modification Mechanisms
test space. (These areas are not part of the SystemVerilog
standard, but are useful to describe soft constraint
methodology.) The SystemVerilog language provides several mechanisms
for modifying, overriding or disabling constraints. We will
a) The entire solution space possible for the random review each of these constructs and then discuss issues with
variables with no constraints present. This is the set of each in relation to the (f) and (g) requirements above.
stimulus that would be created if no restrictions were
placed on the stimulus class being randomized. This i. Inheritance with different constraint block name.
range is often not useful at all, as predictable behavior If constraints are specified in the derived class in a constraint
from the DUT is not defined. Examples are CPU stimulus block whose name is different than any constraint block in the
with an infinite loop, corrupt configuration registers or base classes, then the new constraints add to the existing
packets of almost infinite length. This is represented by constraint set and all are solved when the class is randomized,
the outer box in Figure 5. as shown in the long_packet class in Figure 6.

b) The VIP code typically contains a set of “exercisable ii. Inheritance with the same constraint block name.
space” constraints, which define the stimulus where a
If the constraint block name in the derived class is the same as
predictable response from the DUT is defined. This range
a block name in a base class, then the constraints in the base
will contain many cases where the stimulus violates the
block are replaced by those in the derived, as shown in the
protocol, yet a well-defined error response is produced. error_packet class in Figure 6. To use this strategy to
Using these constraints the testbench will create the legal
accomplish overriding, one must know the name of the
and error stimulus that is possible for the protocol.
original constraint block, and that original block must not
contain other constraints that are not intended to be
c) A set of “legal space” constraints will generate valid
overridden.
stimulus, without any error injection. A default test with
only these constraints would eventually generate all legal class packet;
input stimuli. rand bit [15:0] len;
constraint valid_len {
len inside {[0:1500]};
d) The VIP code also constrains a set of “typical space” }
constraints. These will cause the stimulus to be more endclass
useful and coverage for the protocol or the design will be
hit more quickly using these constraints. class long_packet extends packet;
constraint long_len {
len > 1000; // used with valid_len
e) Variables in the constraint space are often related to other }
variables via implication. This is shown in the diagram endclass;
by a bidirectional arrow linking the two variable range
spaces. class error_packet extends packet;
constraint valid_len { //overrides
The test writer typically defines two sets of constraints at len inside {[1501:1600]};
}
the test-level.
endclass
f) Test specific constraints that further restrict the range of
values generated. These are biases or directives for a Figure 6 – Parent/Child Class Constraints
specific test to increase the chance of hitting a coverage
point or corner case. These are the typical constrained- iii. Procedural calls to constraint_mode()
random tests that are part of a level-1 or level-2 test suite. As constraint blocks are named in SystemVerilog, each block
can be enabled or disabled using procedural code. The test
g) Test specific constraints that change or expand the range writer can simply disable any constraint block explicitly in the
of values generated to some range outside the “typical test, as shown in Figure 7. To use this strategy, one must
space” to hit a corner case. These are typically know the name of the original constraint block and that the
constrained-random tests created during the coverage original block must not contain other constraints that are not
closure process, where corner cases are targeted by adding intended to be overridden, and because constraint_mode() is
constraints. set on an instance, it must be repeated for all instances where
the override is required.
 class packet;
rand bit [15:0] len; The requirements for (g) are quite different – here we want
constraint valid_len { to disable one or more VIP constraints to allow the test
len inside {[0:1500]}; constraints to define the space. We are effectively enlarging
} the space in some area above and beyond what was specified
endclass as typical by the VIP developer.
// Test invalid length 1500-1600.
// Disable valid_len cst (0-1500) There are several problems with the existing solutions:
// Gen packets with len 1501-1600
a) The user must determine which constraints need to be
pkt.valid_len.constraint_mode(0); overridden or disabled, which is often not easy to
pkt.randomize() with { calculate or intuitive to code. In many cases the
len inside {[1501:1600]}; constraints dropped will depend on state variables so
}; cannot be calculated statically and coded into the test.

Figure 7 – constraint_mode() b) The user must know the name of the constraint block
in order to override it or disable it. That puts a
burden on documentation, especially if the block is in
iv. Dist to approximate soft constraints. encrypted code.
A distribution constraint with extreme bias will be honored
if possible yet will not cause a conflict even if as few as one of c) If a constraint block is overridden or disabled to
the distribution alternatives overlaps with other constraints. If remove a particular constraint, any other constraints
the desired typical space is given a very large weight and the in that block need to be re-specified. This suggests a
exercisable space is given a very small weight, then the test methodology of always putting constraints in their
writer can in effect override the constraint specified as dist own block if they are known to be subject to being
without disabling or re-defining the constraint block, as shown disabled. Such a methodology can be hard to enforce
in Figure 8. There is, of course, a small chance that the typical and maintain (a later decision that a constraint should
space would not be chosen. be possible to disable means blocks would be
subsequently partitioned).
class packet;
rand bit [15:0] len; d) For the override or disable solutions, even though the
constraint valid_len { original intent may have been to allow the test to not
len dist {[0:1500] := 10000, use the constraint, the test still has to write extra code
[0:1600] := 1}; to make that happen.
};
endclass e) If a conflicting constraint is presented in the “with”
packet pkt = new();
clause of a randomize call, there is no derived class
pkt.randomize(); within which to apply the override.
=> Results: len very likely in 0:1500
f) The solution of using a skewed dist constraint can fail
// overlapping range with a finite probability. Distribution issues can arise
pkt.randomize() with { if a second dist is specified (e.g. in the test) for the
len inside {[1400:1600]}; same variable. The constraint solver will determine
}; some dist variables to relax, however there is no
=> Results: len very likely in 1400:1500
control over the priority and no way to specify which
// conflict range dist variables should be relaxed in the test.
pkt.randomize() with {
len inside {[1501:1600]};
C. Soft Constraint Methodology/Solution
};
=> Results: len in 1501:1600
Soft constraints solve all of the issues listed above when a
Figure 8 – dist Approximating Soft Constraint Example test writer needs to expand the solution space.

Soft constraints that do not conflict are simply additive,

To satisfy the requirements for the test to further res trict and follow the same rules are regular constraints, satisfying
range (f), the inheritance with a differently named constraint requirement (f).
block can be used. This simply adds additional constraints
and further restricts the solution space.
 When a soft constraint is present but a conflict occurs, then
the soft constraint may be disabled by a regular (hard) class packet;
constraint or another soft constraint with higher importance. rand bit [15:0] len;
// Eth protocol has len 0-1500
This allows the VIP creator to specify some constraints as // DUT timeout at 5000 bytes
// Exercisable 0..6000 bytes
soft, knowing that these may then be disabled by the test constraint exercisable_len {
writer using either a hard constraint or another soft constraint len inside {[0:6000]};
with higher priority. }
endclass
The VIP creator also knows that the soft constraint will be
disabled only if a conflict occurs, which is determined at packet pkt = new();
runtime based on the state variables.
// Test valid/invalid lengths
// Packets with length 1400-1600
No false failures due to a small but finite probability of a pkt.randomize() with {
dist choosing a heavily biased value can occur. The len inside {[1400:1600]};
constraints either conflict and are disabled or do not conflict };
and remain. Results are predictable and failures do not occur => Results: len in 1400:1600
due to specific seeds being used.
Figure 9 –Exercisable (Hard) Space Constraints
Finally, if a soft-constraint in the VIP must be disabled,
this can be accomplished using the “disable soft” construct. ii. Legal and Typical Space
This causes the soft constraints on a specified variable to be
disabled across all constraint blocks (as was shown in Figure The legal and typical space should be defined using a mix
4). of hard and soft constraints. The soft constraints should be
used for areas where you want the test writer to easily override
D. Soft Constraint Examples the settings to expand the solution space.

The concepts discussed above will now be explained with a set

of simple examples, to illustrate the points in the context of a
verification environment.

Each of the requirements from the VIP and test-writer

needs to be mapped to these language features in a well-
defined manner so the test-writer can understand how the test
will affect the underlying VIP code.
Figure 10 – Legal and Typical Space
i. Exercisable Space
class packet;
The exercisable space is the stimulus the DUT will return a rand bit [15:0] len;
predictable result. This space should be defined using regular // Protocol len 0..1500
(hard) constraints. These constraints will not be dis abled by // Use 0..1600 for testing
the tool unless an explicit call to constraint_mode() is made to // of valid + error traffic
turn them off for some design specific reason. constraint legal_len {
len inside {[0:1600]};
Soft constraints should not be used for this purpose, as it is too }
endclass
easy to accidentally override them and cause illegal stimulus
to be injected into the design, wasting considerable time packet pkt = new();
debugging false failures.
pkt.randomize();
An example is shown in Figure 9 where the packet length is a => Results: len in 0:1600
16-bit field. We want to inject packets larger than 1500
allowed by the protocol but do not want to inject packets of
very large length that would be slow to simulate or hang the Figure 11 – Legal Space Constraints
test.
 class typ_packet extends packet; As the hard constraint to generate packets of length 1490-
// Bias towards interesting len 1510 does not conflict with the earlier soft constraints nothing
constraint typical_len { is dropped. The solver can find a solution using all
soft len dist { constraints, and returns length 1490-1500. This may not be
[ 1: 5] :/ 30, // short the desired test behavior. Functional coverage provides an
[ 2:1498] :/ 40, // med important check that the full range of desired stimulus was
[1495:1500] :/ 30}; // long
applied.
}
endclass
To generate the error lengths, where the error space
typ_packet typ_pkt = new(); partially overlaps with the previous ranges, we need to remove
the soft constraint. The disable soft function can be used to
typ_pkt.randomize(); perform this action. Calling disable soft on a variable causes
=> Results: distribution shown all soft constraints on that variable to be dropped. This allows
the new constraint to now define the required space as shown
Figure 12 – Typical Space Constraints in Figure 15.
.
iii. Corner Case Space class err_packet extends typ_packet;

To close coverage, additional stimulus values need to be // Generate error lengths

injected into the DUT to hit specific corner cases. This constraint error_len {
usually requires some slight expanding of the typical space as disable soft len;
shown in Figure 13. len inside {[1490:1510]};
}
endclass

err_packet err_pkt = new();

err_pkt.randomize();

=> Results: len = 1490:1510

Figure 15 – Overlapping Error Solution Constraints

iv. Implication Constraints

One cannot apply all of the necessary solution space
shaping using the relational and distribution constraints shown
Figure 13 – Corner Case Space so far. A very important category of constraints is the
implication constraint, which can be implemented with either
the “->” operator or an “if-else” constraint. Let‟s look at how
Simply adding a constraint with the new extended range
the concept of soft constraints works in conjunction with
will not work as the solver can find a valid solution in the
implication constraints.
intersection of typical and corner space. This is shown in
Figure 14 where the interesting packet length range of 1490-
One permutation is that there is a hard implication
1510 does not conflict with the typical space constraints in
constraint and a soft constraint referencing the same variable.
Figure 12.
In this situation, it does not matter whether the variable in
question is in the left or right side of the implication; if the
class err_packet extends typ_packet; possible range of the variable after consideration of the
// Generate error lengths
implication constraint allows the soft constraint to be satisfied,
constraint error_len {
len inside {[1490:1510]};
the soft constraint will be considered, and otherwise it will be
} ignored. This is illustrated in Figure 16. So any critical
endclass implication constraint applied by the test or by the
environment is certain to be honored, and the typical space
err_packet err_pkt = new(); specified by soft constraints will be honored if possible. Be
err_pkt.randomize(); aware that a reduction in the range of the other variable (not
the soft constrained one) in the implication may be necessary
=> Results: len = 1490:1500 to find a solution (see the value of y in Figure 16).

Figure 14 – Corner Case Constraints

 class tst_packet extends typ_packet;
With soft constraints, some of the constraints may be
constraint x_y_len { dropped due to a conflict, and this can then affect the resulting
x < 2 -> len inside {[1490:1510]}; distribution or solution set. A tool supporting soft constraints
y < 2 -> len > 1500 ; will need to have a capability to debug this functionality.
}
endclass
The debug functionality must show which constraints are
tst_packet tst_pkt = new(); dropped and which are honored. This can be done in a similar
tst_pkt.randomize(); manner to showing when a constraint block is overridden due
to inheritance. One key difference is that an overridden block
=> Results: len in 1490:1500 if x < 2 due to inheritance disabled the entire block, while soft
or len uses distribution from typ_packet constraints are disabled at the individual equation level.
otherwise; y >= 2 (assuming no other
hard constraint on y) The tool must report which soft constraints are dropped,
and which other conflicting constraints caused this behavior.
Figure 16 – Hard Implication Constraints Some graphical way of displaying this information is
preferred.
A variation which is likely less common is that there is an Finally, it is useful to interactively debug soft constraints
implication constraint that itself should be considered a soft by stopping in the simulator GUI, and then be able to re-
constraint. Perhaps a variable x has a typical space only when randomize the result with some soft constraints converted into
another variable y has certain values. In that case, you can hard constraints. This allows conflicts to be reported and
create a constraint of the form “y inside {[…]} -> soft x inside show why a soft constraint could not be satisfied.
{[…]}”. Now if the left-hand side expression is true, the
constraint on the right-hand side will be honored if possible. All of these features should be available with links to
Unlike the hard implication constraint, if there are other source code, waveforms, class browser, object browser and
constraints that make the right-hand side impossible to satisfy, local watch panes.
values can still be chosen that cause the left-hand side to be
true. A soft implication constraint is illustrated in Figure 17. VI. CONCLUS ION
The addition of soft constraint to the SystemVerilog
class typ2_packet extends packet; language provides an effective and efficient way to specify
constraint typical_len {
constraints in the VIP layer that can easily be overridden by
x < 2 -> soft len inside {[0:100]};
}
the a test writer. The priority of which constraints are dropped
endclass is controlled in a well defined manner and allows the VIP
creator and test writer to determine which items will be
typ2_packet typ_pkt = new(); dropped in a predictable way. The software tools can assist
with debug of soft constraints by providing various GUI and
typ_pkt.randomize() ; interactive features.
=> Results: len in 0:100 if x < 2,
otherwise unconstrained VII. REFERENCES
typ_pkt.randomize() with
{len > 100; x < 2}; [1] “ IEEE Standard for SystemVerilog – Unified Hardware Design,
=> Results: len > 100 and x < 2, soft Speci fication and Veri fi cation Language” IEEE Computer Society,
IEEE, New York, NY, IEEE Std 1800-2009
constraint ignored
http://standards.ieee.org/findstds/standard/1800-2009.html
[2] “ IEEE Standard for the Functional Veri fi cation Language e” IEEE
Computer Society, IEEE New York, NY. IEEE Std 1647-2008
Figure 17 – Soft Implication Constraints http://standards.ieee.org/findstds/standard/1647-2008.html

[3] “ Mantis 2987 [proposal to SV-EC IEEE 1800 committee] P1800-2012”,

http://www.eda.org/mantis/file_download.php?file_id=5478&type=bug
V. DEBUG
Debugging soft constraints introduces some additional
complexity. Previously all constraints were solved correctly
or a conflict was reported. The conflict could then be
debugged and changes made to the source code.