Subject: Re: [sv-ec] EXT-14: 12.4.11 Object handle guards
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Sep 09 2003 - 15:58:39 PDT
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" <Ray_Ryan@mentorg.com>
To: "'sv-ec@server.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 : Tue Sep 09 2003 - 15:59:47 PDT