Gen Depends

Specifying Generation Dependencies with Constraints
(User View)
When creating reusable verification environments, developers need to capture the
architectural dependencies between fields (and data structures). Constraints are used both
to define the relationship between the fields, as well as capturing the design intent for the
‘directionality’ of these dependencies. Quite often, the design intent is for a unidirectional
behavior which can be described as 'cause and effect' or 'dependency'.
This document describes the issues surrounding the specification of design intent around
dependency between fields, using constraints.
Typically the architectural parts of verification code consist of a set of 'user interface' fields
and some 'internal' fields that should be controlled by the user interface. If bi-directional
constraints are used to specify such architectural relationships, the design intent must be
highlighted to make sure that the generator interprets it correctly.
To influence the generation order one can use either the 'keep gen before' construct or
'value()' calls. In addition, a new syntax will be provided in the future, to specify
unidirectional intent in bi-directional constraints. This syntax will be introduced gradually,
first as sn_pre_t() (a temporary simple implementation), and later as pre(). The intent of
pre() is to say, within the context of a constraint, that the fields inside the pre() should be
considered as pre-conditions for deducing the values for the other fields.
keep soft a == pre(b);
The sn_pre_t() provided at the first stage will translate in fact into a “gen before” in the
context of the constraint. Later, the pre() construct will be provided, to replace the
sn_pre_t() construct. It will be superior to sn_pre_t(), as it will also change the propagation
rules to be unidirectional.
We recommend to use the methodological workarounds suggested below until sn_pre_t()
is available. When sn_pre_t() is available, we recommend to convert the code to use this
new construct as a preparation for the final pre(), which we expect to solve all the issues
described below.
The patterns below show typical examples with the suggested solution and current
workarounds.
General guideline – when to apply the following patterns

The new pre() is a strong architectural constraint that cannot be overridden. It should only
be used to enforce the developer’s intent in constraints connecting user controllable fields
with internal fields. Excessive use of pre(), value() or gen before may unnecessarily
reduce the power of the generator and therefore should be avoided.
Version 1.0 Verisity Design Confidential 1

P1: Capturing simple unidirectional dependencies
P1: Capturing simple unidirectional dependencies

P1a: hard constraint
Assume there is a simple dependency on external control, captured by:
keep a == b;
To indicate that ‘a’ depends on ‘b’ use:
keep a == pre(b);
Current workaround:
keep a == value(b);
P1b: soft constraint

Assume there is a soft dependency on external control, captured by:
keep soft a == b;
To indicate that ‘a’ depends on ‘b’ (as the default value) use:
keep soft a == pre(b);
Current workaround:
keep gen (b) before (a);
Note: value() has no effect in soft constraint
P2: Conditional dependencies with fixed condition

P2a: implication
Assume there is a simple cause and effect relationship, captured by:
keep a => b;
To indicate that ‘b’ depends on ‘a’ (generate the condition first) use:
keep pre(a) => b;
Current workaround:
keep gen (a) before (b);
P2b: conditional dependency

Assume there is a complex cause and effect relationship: when ‘a’ is true we want ‘b’ to
get the value of ‘c’:
keep a => (b == c);
2 Verisity Design Confidential Version 1.0

P3: Conditional dependencies in for-each loop
To indicate that ‘b’ depends on both ‘a’ and ‘c’ use:

keep pre(a) => b == pre(c);
Current workaround:
keep gen (a) before (b, c);
keep gen (c) before (b);
P3: Conditional dependencies in for-each loop

Assume there is a list that depends on conditional constraints in for-each loop.
keep for each in a {index > 5 => .x == b};
To indicate that ‘a’ depends on ‘b’ use:
keep for each in a {index > 5 => .x == pre(b)};
Current workaround:
keep gen (b) before (a)
P4: Covering alternatives

Assume all the alternatives are covered, but defined in separate constraints.
keep a => b == c;
keep not a => b == d;
To indicate that ‘b’ depends on ‘a’, ‘c’ and ‘d’ use.
keep pre(a) => b == pre(c);
keep not pre(a) => b == pre(d);
Current workaround (wherever possible):
keep b == value(a?c:d);
P5: Conditional dependency with fixed condition

Assume the left hand side of a constraint is a fixed condition.
keep sys.condition() => a == foo(b);
Here ‘a’ obviously depends on ‘b’ but since the right-hand side of the implication does not
affect ordering, constraint may remain unsatisfied. To avoid use:
keep sys.condition() => a == foo(pre(b));
Current workaround :
keep gen (b) before (a);
Version 1.0 Verisity Design Confidential 3

P6: List size in list field definition
P6: List size in list field definition

Assume a variable list size is being constrained.
a : integer;
b[a] : list of ...
To indicate that ‘b’ depends on ‘a’ use:
keep gen (a) before (b);
Note: this is a general recommendation not related to pre()
If unpacking is not required, the preferred syntax is:
a : integer;
b : list of ...
keep b.size() == pre(a);
Current workaround :
keep b.size() == value(a);
4 Verisity Design Confidential Version 1.0

Gen Depends

Uploaded by

Copyright:

Available Formats

Gen Depends

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gen Depends

Uploaded by

Copyright:

Available Formats

Specifying Generation Dependencies with Constraints

General guideline – when to apply the following patterns

Version 1.0 Verisity Design Confidential 1

P1: Capturing simple unidirectional dependencies

P1b: soft constraint

P2: Conditional dependencies with fixed condition

P2b: conditional dependency

2 Verisity Design Confidential Version 1.0

To indicate that ‘b’ depends on both ‘a’ and ‘c’ use:

P3: Conditional dependencies in for-each loop

P4: Covering alternatives

P5: Conditional dependency with fixed condition

Version 1.0 Verisity Design Confidential 3

P6: List size in list field definition

4 Verisity Design Confidential Version 1.0

You might also like