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

Greg,

Some comments:

1. Part-selects are already different from the whole in at least one
way. For 'logic signed [31:0] a', a is signed, whereas a[31:0] is
unsigned.

2. Regarding "doing the math", I don't see your point. Even [MAX_INT:-1]
has MAX_INT+2 possible values, so you need enough bits to handle it. On
the contrary, normalizing can require less bits. [17:11] requires 5
bits, [6:0] needs only 3.

3. Regarding PARAMETER P = A;, you are wrong. 1364-2005, 4.10.1, says,
"A parameter with no range specification and with either a signed type
specification or no type specification shall have an implied range with
an lsb equal to 0 and an msb equal to one less than the size of the
final value assigned to the parameter." It looks at the type of the
value of A, not the type of A. There is a difference.

Regards,
Shalom


> Brad Pierce wrote:
> > What should be displayed for the following simple test case?
> >
> > //    6 6 4 ?
> > //    0 6 4 ?
> > //  17 17 4 ?
> > module test;
> >    logic [7:0] unpacked_array [17:11];
> >    logic [17:11] [7:0] packed_array;
> >    logic [3:7] bit_vector1;
> >    logic [7:3] bit_vector2;
> >    localparam U = $left(type(unpacked_array[17:11]));
> >    localparam P = $left(type(  packed_array[17:11]));
> >    localparam A = $left(type(bit_vector1+bit_vector2));
> >    initial $display(U,P,A);
> > endmodule
> >
> > Until the LRM clearly specifies the values of the parameters U, P
> and A,
> > we shouldn't be adding more complications.
> >
> > [ In reply to http://www.eda-stds.org/sv-bc/hm/5684.html .]
> 
> The sensible answers, in my opinion, are either 0 6 4 or 17 17 4.
> 
> Let's call 0 6 and 4 the "normalized" left bound of the above
> testcases,
> because it is the bound we have elsewhere specified that the language
> delivers when it knows only the length of a given result dimension.
> 
> Although conservative instinct makes us wish that $left of
> bit_vector2 + bit_vector2 would be "7", Brad immediately reminds us,
> with
> bit_vector1 + bit_vector2, that consistency requires us to accept "4",
> even when the operands had the same bounds (it might just be
> coincidence!).
> 
> I can only think of only one good reason that part select should yield
> a result
> with normalized bounds on the selected dimension.
> 
> 1) We need normalized bounds for the result of "slice" notation:  A[x-
> :L].
>     The length L is constant whereas x may vary.  Here slice is acting
>     like a typical operator - It seems 'consistent' to carry this rule
>     over to traditional part-selects.
> 
> I can think of two reasons for part-select to retain the bounds it was
> given:
> 
> 1) "Doing the math" to normalize them comes with some complications.
>     A[MAX_INT: -1] requires us to construct MAX_INT+1 as an upper
> bound.
>     You can snicker at this counter-example, but More's empty arrays
> can
>     have such dimensions... and, in general, the precision needed to
>     store any length is one bit wider than needed by its bounds, which
>     might affect some implementers.
> 
> 2) PARAMETER P = A;  is probably already well-defined so that P picks
> up
>     the bounds declared for A, not normalized bounds (is this true?).
>     In any case, part-selects of the whole array are easy to mistake
> for the
>     array itself, and users might not appreciate a difference between
>     "parameter P[17:11] = A;" and "parameter P = A[17:11];"  when
> those are
>     the bounds declared for A.
> 
> The conservative rule - that the bounds of the part select A[L:R]
> should be L and R - is seductive and a few systems may already do this
> (?).
> But it's not so consistent with the view that part-select is one of
> the
> "operators", which typically lose bounds info, not preserve it.
> 
> I regard the reasons for conserving bounds as more sentimental than
> formal.
> So I favor 0 6 4 as the answer to Brad's question.
> If saying so improves 17 17 4's chances in committee, I apologize.
> 
> Greg

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