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

Steven Sharp wrote:
>>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.  


Sorry, I was going back to my packed array an extrapolating
the rule I had in mind to other packed types.


You have some very good points in your response.


There are some problematic scenarios.  The "constructive"
issue that I was bringing up was that there are expressions
that can be used with "type" that don't have declared
types.  That was part of the point of the expression in my
original example:

     wire [63:33] a;
     typedef type(a[40:33] + 5) t2;

"t2" cannot have the bounds of [40:33] since it has a width
of 32.  There are clearly other scenarios.  For example,
consider the following:

    int i;
    typedef packed struct {
        logic [3:0] a;
        logic [3:0] b;
    } S;
    S s1;

If we have "type(s1.a)" I assume that you would like to get the
bounds [3:0].  If you have "type(s1[7:4])" you would like
[7:0], right?   What about (for some int i):
    i = 4;
    type(s1[i +: 4])
This obviously cannot be tied to the value of "i" both since
this is *required* to not evaluate "i" and since the time
at which you must determine the type is during elaboration
(since the type could be used as a type parameter).

I don't think there is any choice but to have this be a zero
based range (i.e. [3:0]).

Now, what about a constant value in place of "i"?  Is it
required to be evaluated?

What about (s1.a + s1.a)?  That clearly has the width of
s1.a, but what about its bounds?  Are they preserved or not?

This problem also exists for slices since the index position
of an indexed slice can also be non-constant.

Finally, if an select is partially (or completely) out of range,
should the resulting type reflect the expressed bounds?

     logic [3:0] a;
     type(a[4:3])   // is this still 4:3?


In general, I don't mind preserving the bounds of direct
part selects (or non-indexed slices) since those are
statically determinable, but it is likely going to be
very annoying to users to have to figure out when they
will have expressed bounds in a resulting type and when
they will have 0-based bounds.  It seems to me that if
we require "type" to produce 0-based bounds for any packed
type, then it will be easier to write code that doesn't
depend on the form of the select expression.

I don't know exactly where I am on all of this; to some
extent I may end up being more comfortable with rules
for "type" that don't directly correspond to how assigment
patterns work.  For packed types, assignment
compatibility doesn't rely on bounds.  Since I have the
most issues with the type of general packed expressions,
I'm not sure that it is a problem to always use a 0-based
type for the result of "type".  That doesn't mean I would
throw away all the underlying type information (clearly
one cannot due to other queries), but I'm not sure that
there is any downside with "type" itself and I like the
regularity of what user code could look like with more
predictable results.

There doesn't seem to be a clearly defined type system
tied to expressions in terms of the bounds.  The widths
and signedness are defined, but there is no comparable
calculus for bounds.  Given that, it is hard to argue
about what should and shouldn't work and why.

Gord.





> 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
> 

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