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

Greg,

Maybe you meant (6,6,4), not (0,6,4). (0,6,4) doesn't make sense to me.
First, it is not clear what 0 corresponds to. Second, choosing (0,6,4)
means that selection from packed array has different bounds from
selection from unpacked array (note that the two arrays have exactly the
same bounds; the packedness is the only difference). Making such a
difference seems to me an unnecessary complication in the definition.

--Yulik.

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Greg Jaxon
Sent: Monday, March 12, 2007 8:18 PM
To: Brad Pierce
Cc: sv-bc@server.eda-stds.org
Subject: Re: [sv-bc] part selects on arbitrary expressions

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.

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