[sv-ec] RE: Mantis 3028, constraints for unique array elements

From: Chris Spear <Chris.Spear@synopsys.com>
Date: Fri Aug 20 2010 - 09:31:19 PDT

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.
Received on Fri Aug 20 09:31:38 2010

This archive was generated by hypermail 2.1.8 : Fri Aug 20 2010 - 09:31:42 PDT