Re: [sv-bc] part selects on arbitrary expressions

Brad Pierce wrote:
> A type reference such as type(A[7:4]) can be used in a comparison
> controlling a generate (as described in 6.10 and 6.9.1).  And it appears
> to be legal to ask for $left(type(A[7:4])).  Plus, there's always the
> $typename() function of 22.2.
> 
> So the meaning of a legal SV program could easily depend on knowing the
> exact type of the result of a part-select.  It's not in general enough
> to only know the size of that type.
> 
> If the LRM has not fully specified the result types of part-selects yet,
> that's a serious gap.

No it hasn't been specified.  You'll likely be unhappy about
what "type(...) == type(...)" means in any case.

6.10 says:
   Two type references shall be considered equal in such comparisons
   if, and only if, the types to which they refer match (see 6.9.1).

6.9.1 boils down to saying that a packed vector can match
a predefined but it is NEVER the case that two "anonymous"
packed vectors will match.  So, for a packed item "bit [1:0] a",
even the trivial condition
    type(a[1:0]) == type(a[1:0])
will be false.

Such types are equivalent but not matching.

For an unpacked array, it isn't clear.  If you have:
    int a[20:10];
    ...
      type(a) == type(a[20:10])
matching requires that the bounds of an unpacked array
are the same (equivalent just requires the shape).  For
the above to be "true" would imply that the bounds of
the select are preserved in the result.  I haven't found
any requirement in the LRM for that to hold.

For $left, things are a bit more murky yet.  5.4 is not clear
since it distinguishes slice and part select at the beginning and
then just talks about slices.  I think it implies that
a slice of a packed type is identical to a part select
but if that is the case then certainly the bounds for that
are ill-defined.  In addition, it isn't completely obvious
that $left of a part-select is valid (versus $left of a
slice) so the equivalence of a slice and part-select is
important in terms of validity of the queries.

Most of the other operations (assignments, etc) are not
defined in terms of actual bounds; the only time when this
is significant is when one uses the array querying
functions or type operator in a context where bounds
are significant -- type comparisons and declarations
are the obvious ones.


It certainly appears that there are issues in the relationships
in addition to the concerns raised about making "[]" an
operator.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.