Arturo, Chris,
Comment in text below.
________________________________
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Friday, August 20, 2010 6:49 PM
To: Chris Spear; Ryan, Ray; sv-ec@eda.org
Subject: RE: Mantis 3028, constraints for unique array elements
Ray,
As I mentioned in the meeting I do not support unique
constraints on heterogeneous collections. No matter what semantics we
try to dream up to make it work, the outcome will very likely be
perceived as bugs by users. Furthermore, because it all happens inside
the solver, with no apparent solver failures, users will have little
recourse for debugging the problem.
I haven't seen specific User requests for the heterogeneous collection -
so I'm willing to considter only unpacked arrays. However, I don't see
the 'hidden' problem. If 'unique' values can be found, the randomize
assigns these and returnes success, otherwise it returns 0.
To only allow arrays, the grammar could be:
constraint_expression ::=
...
| unique random_variable_primary
I particularly dislike the idea of solving the constraint using
maximal bit-width. Consider using your proposed semantics on the
following example:
bit [0:1] a;
bit [0:2] b;
int c;
constraint X { unique { a, b, c } };
The solver would ignore the individual bit width while solving
the above problem and solve all 3 values as 32-bits (the signdedness may
be unimportant for equality). Then, a valid solution would be { 12, 8, 0
}, which after truncation would yield a=0, b=0, and c=0. Since a unique
constrain is a request for mutually exclusive values, the user would
expect a,b,c to have the different values.
Some clarification, I only suggested that max width be used for the
implied comparisons needed to determine uniqueness. That is, a solution
{v1, v2, v3} for the random variables {a,b,c} meets the unique
requirement if
32'(a) != 32'(b);
32'(a) != 32'(c);
32'(b) != 32'(a);
32'(b) != 32'(c);
32'(c) != 32'(a);
32'(c) != 32'(b);
The set of values { 12, 8, 0} would NOT be a valid solution, because 12
is not a legal value for 'a' and 8 is not a legal value for 'b'.
Consider what happens if any of those variables are used in
other constraints. For example, constraint { mem[b] == 5 }. Which 'b'
value should the solver use? The one prior to truncation (8) or the one
following truncation (0) ? Depending on the answer, an assertion
post-constraint solving with the same expression may fail (assert mem[b]
== 5).
I really don't see the why there would be two values for 'b', or that
the suggested unique semantics are any different than
b != c;
mem[b] == 5;
Here, 'b' is extended to 32 bit for the comparison to 'c', but that
doesn't mean there are two values, one prior to truncation, the other
following truncation.
BTW, "mem[b]" is illegal since array indicies cannot be random variables
(in constraints).
Another approach would be for the solver to auto-insert
additional constraints related to the bit-widths. In the example above
this would mean the solver would add the following 2 constraints on top
of the user-specified unique constraint:
a inside {0:3};
b inside {0:7};
This would result in a better solution (at least matching the
users intent of mutually exclusive values). However, the additional
constrains will make the distribution appear to be skewed (towards
larger values on c) and users will probably not understand the reasons
for the distribution change.
Also don't see the point. Yes, since 'a' is a 3-bit value, it is
restricted to the values 0 to 3.
If we stick to arrays, its much simpler since they guarantee
type homogeneity without the need to do any additional checking. But, I
can live with the variable set as long as the homogeneous type is a hard
restriction.
As for Chris' questions, here are my two cents:
- What about the case where there are more elements in the
unique constraint than values?
Constraints will fail in this case. Need not be done at
compile time.
Agreed, the constraint would fail - but need not be detected at compile
time (when randomize is called, the constraint might be disabled with
constraint_mode - in which case randomize could suceed).
- Would randc variables be allowed in the unique constraint?
I don't see the restriction as absolutely necessary, but
it would surely simplify things.
Agreed, not necessary.
- What if there are additional constraints on elements of the
unique constraint?
Those constraints should be honored by the solver. If
they lead to a contradiction then the solver will fail.
Agreed, additional constraints should be allowed and must be honored.
As for sorted collections, I believe these are best handled in
the procedural context - perhaps using the built-in array manipulation
methods. Otherwise, they create very complex constrains that may fail or
take too long to solve.
I see 'sorted' constraints as very similar to the 'unique' constraint -
in that there are two purposes to the additional construct:
1) The constraint is a simplified syntax for what would otherwise be
a set of explicit constraints / foreach constraints.
2) The higher level constraint construct can potentially be used by
the solver for better performance.
Arturo
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf
Of Chris Spear
Sent: Friday, August 20, 2010 9:31 AM
To: Ryan, Ray; sv-ec@eda.org
Subject: [sv-ec] RE: Mantis 3028, constraints for unique array
elements
Hi Ray,
- What about the case where there are more elements in the
unique constraint than values?
bit a, b, c;
constraint none_left {
unique {a, b, c};
}
This could be determined by analysis at compile time, and create
an error.
- Would randc variables be allowed in the unique constraint?
Probably not as they are solved before rand variables.
- What if there are additional constraints on elements of the
unique constraint?
bit [1:0] a, b, c;
constraint four { unique {a, b, c}; }
constraint at_least {
a > 2; // unsolvable
b > 2;
}
- Once you have these issues worked out, is there any interest
in sort and rsort constraints? These would put all elements in a sorted
order, similar to the constraint:
foreach (array[i])
if (i > 0)
array[i] > array[i-1];
Thanks!
Chris
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf
Of Ryan, Ray
Sent: Friday, August 20, 2010 12:11 PM
To: sv-ec@eda.org
Subject: [sv-ec] Mantis 3028, constraints for unique array
elements
For mantis I'd suggest a grammar something like:
constraint_expression ::=
expression_or_dist ;
| expression -> constraint_set
| if ( expression ) constraint_set [ else
constraint_set
]
| foreach ( ps_or_hierarchical_array_identifier [
loop_variables ] ) constraint_set
| unique { random_variable_list }
where "solve_before_list" is re-named to "random_variable_list"
and
used in both "constraint_expression"
and "constraint_block_item" as in:
constraint_block_item ::=
solve random_variable_list before
random_variable_list ;
| constraint_expression
random_variable_list ::= random_variable_primary { ,
random_variable_primary }
random_variable_primary ::= [ implicit_class_handle . |
class_scope ] hierarchical_identifier select
The description of a 'unique' constraint would be something
like:
In a 'unique' constraint each random variable in the
random_variable_list must be of an integral type or an unpacked
array,
associative array or queue where the element type is an integral
type.
For unpacked random variables, the 'unique' constraint applies
to each
packed element of the variable.
<unique can't be applied to a class handle.>
A 'unique' constraint requires that each random variable
in the
random_variable_list is assigned a unique random value.
For the unique value comparison:
- If any value is unsigned, all comparisons are
unsigned
otherwise all are signed.
- Each value is extended to the maximum width of
any of
the values.
Some concerns I have about 'unique' constraints.
1) The construct needs to be a 'constraint_expression' and NOT a
general
expression. If there is a kind of 'unique' expression then the
following
constraints would be syntactically allowed:
if ( <unique_expression> ) { <constraint> }
<expression> || !<unique_expression>
I don't think it is meaningful (or what would it mean) to write
a
constraint that a set of variable are NOT unique.
The same kind of syntactic restriction is there today for
distribution,
implication, if-then-else and foreach constraints. That is, you
can't
write a constraint requiring that a variable does NOT have a
specific
distribution. I believe the same should apply to the unique
constraint.
2) In defining the 'unique' construct as a kind of constraint,
'unique'
is only a keyword (a part of the constraint grammar). It does
not become
a operator and so don't need to included in the other sections
regarding
operators.
3) The above syntax would still allow a conditional 'unique'
constraint.
That is,
if (condition) { unique { A, B } }
If this is undesirable, the unique constraint could be defined
as a
"constraint_block_item" rather than a "expression_constraint".
Solve-before constraint are defined this way so that they cannot
be
conditional.
Regards,
Ray
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Aug 30 08:42:22 2010
This archive was generated by hypermail 2.1.8 : Mon Aug 30 2010 - 08:42:25 PDT