[sv-ec] RE: Default and Solt constraints (2987, 2988)

Regarding the "allow" option (I had given this to Tom a long time ago, man did I ramble and overcomplicate the proposal) the usage model is to enable an environment or library to place default constraints which only allow legal types of traffic to be generated, but enable a random invalid cycle to be generated for error testing. In particular, the goal is to be able to disable a soft constraint from inside a with {} rather than disable it prior to the randomize() call. Here is an example:

typedef enum {READ, WRITE, INVALID} command_t;
class xaction;
  rand command_t command;
  constraint command_c {
    soft command inside {READ, WRITE};
  }
endclass

xaction X_i, Y_i;
X_i = new();
X_i.randomize() with {allow command == INVALID; dist command {READ := 2, WRITE := 2, INVALID := 1};};

The allow clause expands the solution space. Effectively, the constraint solver sees "soft constraint || allow constraint" wherever a soft constraint and an allow constraint refer to any variables in common. If the xaction class didn't declare the constraint on command as soft, then randomizing X_i.randomize() would result in a randomization failure.

Things would get a little messy if the soft constraint were placed on a dist; there are a few options including making it illegal or implementation dependent.

-Brandon

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Ryan, Ray
Sent: Monday, August 01, 2011 10:58 AM
To: sv-ec@eda.org
Subject: [sv-ec] Default and Solt constraints (2987, 2988)

Some observations on Default and Soft constraints:

Default Constraints:
As I understand it, a default constraint ONLY applies if there are NO other constraints on the random variables within the default constraint.
A default constraint is relatively inexpensive since the decision whether a default constraint is included does not require analysis of the solution space. Simply, if any random variable within a default constraint occurs in any 'other' constraint, the default constraint is ignore.
The example seems to indicate that more specifically, only non-default constraints are examined for conflict with a default constraints . IE a random variable can be constrained by more than 1 default constraint.
Default constraints are limited in that they cannot be further refined by a 'with' clause. For example if there is a default constraint that "x inside { [500:2000] }" the 'with' clause "with { x > 600; }" will cause the default constraint to be ignored - thus allowing values greater than 2000.

Soft Constraint:
Generally a soft constraint applies if it does not conflict with other constraints.
Soft constraints can be more expensive (analysis) than regular constraints.
Soft constraint require definition of an 'order' for the soft constraint. Prior to 'soft' constraint, the 'order' of constraint is not significant. The ordering is needed to resolve conflict between soft constraints - which is applied.

'Allow' option to disable soft constraints:
The mantis item indicates that 'allow' constraints are used to disable 'soft' constraint that conflict with the 'allow'.
It would be good to get a bit more of the usage model.
If 'allow' is adopted, the semantics should be that a 'soft' constraint is disable by an 'allow' only when the conflict can be detected by consideration of only the 'soft' constraint and the 'allow' constraint. For example the soft constraint "x < 10" could be disabled by "allow x == 100", however, the soft constraint "x < y" (where x,y are random) would NOT be disabled by "allow x == 100".

Ray

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.