Soft constraints and inheritance

Requirements and preferences

A hard constraint must hold in every successful call. A soft constraint, written with the keyword soft, is a default: the solver keeps it when it can and drops it when it conflicts with a hard constraint.

A soft constraint can never cause a failure. If every soft constraint is dropped and the hard rules still have no solution, the call fails because of the hard rules alone.

That makes soft constraints right for typical traffic, such as a usual burst length, and wrong for anything the protocol requires. The difference shows up only when a request conflicts with the rule.

constraint defaults { soft beats == 4; }
...
t.randomize() with { beats == 2; }

constraint legal { beats inside {[1:8]}; }
...
t.randomize() with { beats == 12; }

Both behaviours are useful, as long as each rule is in the right group. A soft length lets any test ask for another length without editing the class. A hard alignment rule turns a mistaken request, like the one in the opening story, into a failed call that the test reports at once.

Soft constraints also suit bring-up. soft addr < 8'h40; keeps early tests inside the first 64 bytes, and later tests widen the range with an inline constraint instead of editing the class.

Error injection is the usual reason people make a protocol rule soft. Lesson 5.5 shows the better tool: switch the hard rule off with constraint_mode(0) for the one object that needs illegal traffic.

Which soft constraint wins

Two soft constraints can disagree with each other. Then the one with the higher priority is kept and the other is dropped.

Priority matters only in that case. When soft constraints agree, and no hard rule conflicts, the solver keeps all of them. A soft constraint dropped in one call is back for the next, because the decision is made afresh every time.

The rule of thumb is that the more specific or later constraint wins. A test can therefore set its own default with an inline soft constraint and still let a later, more specific request override it.

To drop the defaults for one call, write disable soft beats; inside the with block. It removes every soft constraint on beats for that call and leaves the hard rules in place.

Inheritance adds rules, and a same-named block replaces one

A derived class inherits every constraint block of its base and can add more. A block with a new name adds rules, and a block with the same name as a base block replaces that block completely.

That makes block names part of what a class promises to its users. Replacing defaults to change a preference is the intended use. Replacing legal by accident, as wide_burst does in the example, deletes the protocol rules, and nothing reports it.

Keep the protocol rules in one block with a distinctive name, and treat that name as reserved. An error-injection class should turn the rules off on purpose, as lesson 5.5 shows, never by a name collision.

Derived classes are how a test library offers variants such as short_burst, long_burst and error_burst. Each one changes defaults or adds rules, a factory (Module 4) chooses which one to build, and no test has to edit the base class.

All the layers combine in one solve: the base rules, the derived class's blocks and any with block from the test. Before you extend a class, read its block names; a one-line comment on what each block holds is the most useful note a transaction class can carry.

Try it

The base class gives 4 by default, accepts an inline request for 2 by dropping its soft default, and rejects 12 because the hard range wins. short_burst changes only the default.

wide_burst replaced the block named legal, so a 12-beat burst at a misaligned address now succeeds. Rename its block to wide_range and predict the last line.

Check yourself

class burst_txn;
  rand int unsigned beats;
  constraint legal    { beats inside {[1:8]}; }
  constraint defaults { soft beats == 4; }
endclass

class short_burst extends burst_txn;
  constraint short_default { soft beats == 2; }
endclass

module tb;
  burst_txn   b = new;
  short_burst s = new;
  int x, y;
  initial begin
    if (!b.randomize()) $fatal(1, "b failed");
    x = b.beats;
    if (!s.randomize()) $fatal(1, "s failed");
    y = s.beats;
    if (!b.randomize() with { soft beats == 6; }) $fatal(1, "inline failed");
    $display("%0d %0d %0d", x, y, b.beats);
  end
endmodule

constraint defaults { soft beats == 2; }

constraint legal { addr[1:0] == 0; }

constraint long_default { soft beats == 8; }

constraint short_only { beats <= 4; }

Practice

• Override a soft default Implement · Easy