Subject: RE: [sv-ec] EXT-14: 12.4.11 Object handle guards
From: Ryan, Ray (Ray_Ryan@mentorg.com)
Date: Wed Sep 10 2003 - 15:45:04 PDT
Arturo,
I appreciate you clarification for declaration of an object handle as
rand. It makes more sense
that this includes the object's random variables rather than my
misinterpretation of applying
the rand to the object's variables.
I still have problems with object handle guards, (or more generally
contraint guards).
1) As originally defined, a predicated constraint defines a logical
relationship between the
expression and the constraint. That is a => b is equivalent to !a ||
b (section 12.4.5).
2) EXT-14 identifies the need to have a guarded constraint, where the
'guard' controls whether
the constraint is included as an 'active' constraint. A guarded
constraint is needed when
evaluation of the constraint may cause an error. Two cases are
identified (are there others):
a) the constraint references a variable through an object handle and
the object handle may be null.
b) the constraint references an array with an index out of range
(specifically in a foreach constraint).
3) EXT-14 proposes that the expression in a predicated constraint be
treated as a guard when:
a) the expression involves object handle comparisons
b) the predicated constraint occurs in the constraint set of a
foreach construct.
Some problems with #3:
The criteria that the expression involves object handle comparisons
likely needs to be more
specific. That is, which of the following predicate expressions are
guards - they all involve
an object handle comparison?
Class Slist;
rand int n;
rand int A[10];
rand Slist left;
rand Slist right;
constraint c1 { (left != null) => n < left.n; }
constraint c2 { ((left != null) && (right != null)) => left.n <
right.n; }
constraint c3 { ((left == left) && (n < 10) ) => A[n] == 0; }
constraint c4 { ((left != null) + (right != null) == 2) => n <
left.n; }
endclass
The expression in c3 includes (involves) a object handle comparison
simply to cause the expression
to be treated as a guard.
The specification that "Predicate expressions within a foreach behave as
guards ..." (proposed 12.4.7)
has the restrictive effect that regular implication constraints cannot
be used within a foreach
constraint. For example, in the following:
Class C;
rand int A[];
rand bit B[];
rand bit x;
constraint { A.size == B.size; }
constraint f1 { foreach ( A[k] ) (A[k] < 0) => x == 1; }
constraint f2 { foreach ( A[k] ) (B[k] == 1) => A[k] < 0; } //
also, is "B[k]" allowed here
endclass
In f1 and f2, the predicate expression (A[k] < 0) and (B[k] ==1) are
guard expressions. This will
cause an implicit variable ordering (similar to functions). That is,
each B[k] is solved before
A[k], and each A[k] is solved before x.
In this case, the user may perfer that these not be treated as guard
conditions.
In summary, I'd prefer that rather than try to identify the cases where
a predicate expression
should implicitly be treated as a constraint guard, there should be a
explicit means of
specifying a guarded constraint or a predicated constraint. That is, let
the user explicitly
specify which form of constraint is desired. (This is also perferable to
by previous suggestion
that a state variable expression be implicitly treated a guard).
As a possability, how about if the implication operator specifies a
predicated constraint (ie
specifies a logical relation between the expression and constraint) and
an if ..else constraint
specifies a guarded constraint (ie conditional inclusion of the
constraint as active) ?
Ray
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Tuesday, September 09, 2003 3:59 PM
To: Ryan, Ray; 'sv-ec@server.eda.org'
Subject: Re: [sv-ec] EXT-14: 12.4.11 Object handle guards
Ray,
You raise two distinct issues. First, a proposal to generalize
predicated constraint expressions. Second, an attempt to clarify the
definition of object handles declared random. let me deal with each one
separately.
First issue:
The object guards proposal states that a predicated expression such as
'expression' => 'constraint'
behave thus:
During loop (foreach) constraint generation, if the expression involves
object handle comparisons, the expression is evaluated in order for the
solver to decide whether to keep the constraint. If the constraint is
eliminated, no error is issued on illegal access within the constraint.
If we merge the existing proposal with Ray's suggestion, we end up with
the following:
During loop (foreach) constraint generation, if the expression involves
object handle comparisons or it is a state variable expression, the
expression is evaluated in order for the solver to decide whether to
keep the constraint. If the constraint is eliminated, no error is issued
on illegal access within the constraint.
Basically, this allows an object handle itself to be treated the same as
a state variable. On this, Ray's proposal and the original proposal both
agree. The observation that the handles themselves are not randomized is
right on. However, I believe that Ray's proposal goes beyond this and
attempts to generalize what I believe is just an optimization, which is
best left to the implementation. For example, Ray's suggestion would
force to optimize a case like:
a == 1 => x == 0;
where "a" is a state variable. Whether the constraint is eliminated
during constraint generation, or during constraint solving, should be
left to the implementation. The effect will be the same. The only
difference is in which phase of the constraint solution the expression
might be evaluated, which is highly implementation dependant. The only
observable difference is whether an illegal array index within the
predicated constraint generates an error or not. For example, if we make
the following change to the above constraint:
a == 1 => x[7] == 0;
Where 7 is an illegal index to array variable "x". The current scheme
might result in an illegal array index error whereas Ray's proposal will
not.
Thus, Ray's comment on deactivating constraints is accurate, but it has
multiple implementations. In either implementation, if the guard
evaluates to FALSE, the constraint is indeed inactive. Note that
evaluating guards during constraint generation raises the possibility of
evaluating expressions that have rand variables as well, e.g.,
a == 1 && y == 0 => x == 0;
Here, if "a" is not 1, then we might short-circuit the condition. This
can get arbitrarily hairy. Again, this is best left to the
implementation. In either case, there should be no semantic differences.
_____
The second issue is deals with object handles declared rand.
The LRM says:
"An object handle can be declared rand in which case all of that
object's variables and constraints are solved concurrently with the
variables and constraints of the object that contains the handle."
And Ray states:
"Declaration of an object handle as random, declares all the variables
within the instance of the object to be random, but the handle itself is
not a random variable - the value of the handle is never randomized (ie
a new instance is never generated by randomization)."
There is a partial truth to what Ray says. The handle itself is never
randomized. But, it does not say that the contents of the object are
declared random. Rather, that the random variables declared within the
object along with the object's constraints are solved concurrently. I
think the wording of the LRM may be misleading.
Perhaps the LRM should be changed to:
"An object handle can be declared rand in which case all of that
object's random variables and constraints are solved concurrently with
the variables and constraints of the object that contains the handle."
I hope this clarifies the issue.
Arturo
----- Original Message -----
From: "Ryan, Ray" < <mailto:Ray_Ryan@mentorg.com> Ray_Ryan@mentorg.com>
To: " <mailto:'sv-ec@server.eda.org'> 'sv-ec@server.eda.org'" <
<mailto:sv-ec@eda.org> sv-ec@eda.org>
Sent: Monday, September 08, 2003 10:32 AM
Subject: [sv-ec] EXT-14: 12.4.11 Object handle guards
In the description for EXT-14 the section 12.4.11 introduces
Object handle guards (for constraints).
In this section, a special case is made for predicate expressions
that involve comparisons between two object handles. I believe that
instead, a more general clarification should be made for predicated
constaints.
A predicated constraint consists of a 'expression' and a 'constraint
set' (12.4.5, 12.4.6). I propose that a distinction be made depending
on whether the 'expression' contains a reference to any active random
variable.
If the expression does not contain a reference to any active random
variable, then the expression is a guard for the constraint set. If the
value of the guard expression is false, then the constraint set is
inactive.
This definition of a guard expression should apply to both the
implication
and if..else forms of conditional constraints.
This construct could be used for other cases, where evaluation of
a constraint would be invalid (besides the special case involving
object handles).
The case of an object handle in a conditional expression may need the
clarification that an object handle itself is never a random variable.
Declaration of an object handle as random, declares all the variables
within the instance of the object to be random, but the handle itself
is not a random variable - the value of the handle is never randomized
(ie a new instance is never generated by randomization).
Therefore an expression that include a object handle (and no other
random variable) is a guard expression, and acts to control whether or
not the constraint set is active.
- Ray Ryan
This archive was generated by hypermail 2b28 : Wed Sep 10 2003 - 15:48:11 PDT