Re: [sv-bc] Type bounds and "type" operator

>From: Gordon Vreugdenhil <gordonv@model.com>

>Steven,  I can argue both what you are suggesting and what
>I am since there are semi-conflicting indications in the LRM.
>The LRM wants to be able to treat a select into a packed
>element as being equivalent to a part select or indexed
>part select or the equivalent vector.

OK, I'm not sure what packed element you are talking about
here.  The array in my example was an unpacked array, and
clearly a selected element of an unpacked array must retain
its type.  So if you were talking about the select into the
array, it was not a select into a packed array.  If you are
talking about the packed element of the unpacked array, that
also must retain its type and range.  If it didn't, then an
expression such as a[1][3:0] would not work as specified in
Verilog.  The part select must use the range declared for the
word in the declaration of array a.

If I can apply a part select to an element of an array, and
it uses the range from the declaration of that element, then
that is a pretty strong argument that the element has that
range when a query function is used.

Even aside from that, I would have to disagree that the LRM
defines a select into a packed array as equivalent to a part
select or indexed part select.  While that is a convenient
way to think about it or explain it, I don't believe it is
defined that way.  I don't believe there is any indication in
the LRM that an element of an unpacked array has any less of
a type than an element of a packed array.

This issue of ranges is not the only place where having a
type on an element of a packed array is significant.  I would
expect to be able to use an assignment pattern to set the value
of a packed struct or packed array that is an element of a
packed array.  For example:

logic [7:0][3:0][1:0] doubleword;

initial
doubleword[0] = '{ 1, 2, 3, 4 };

If doubleword[0] is just a 32-bit part-select, and not a packed
array of four 8-bit fields, then I couldn't do this.  Are you
suggesting that this is not allowed?

The LRM currently doesn't appear to allow packed arrays of enums
for some reason, which I think is a flaw.  If it is later extended
to allow this, then those need to retain their types also.

>I think that where you are is in thinking about operations
>that are "type constructive" versus "type referencing".  I
>can buy that approach, but I'm not sure that I am convinced
>that is the better of the two approaches.

If your approach won't allow the use of assignment patterns for
elements of packed arrays, then I would have to argue that mine
is better.

Steven Sharp
sharp@cadence.com