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

Bresticker, Shalom wrote:
> 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.

I feel the scales tipping...

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

What I wrote raised an issue, but didn't really make a firm point.
All index evaluation involves "doing the math" carefully.
Normalized bounds would consume minimal bits, if we could always
treat them as unsigned.
If there /is/ any point here, it goes to the "normalizers" for
driving the redundant bits out of the range.

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

Thanks; I'm glad it is codified in a way that erodes support for the
  "17 17 4" answer.

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