RE: [sv-ac] Re: [sv-ec] Re: [sv-bc] question about integer expression

Gord,

I believe the discussion is not restricted to testbench, and I showed earlier an example of an array declaration that satisfies the 2^16 limit, but has nonetheless index bounds that are larger than 32-bits:

        reg [48'hfffffffffff0:48'hfffffffffff3] foo;

The above is a 4-bit (wide) vector, but the index bounds are 48-bit wide. I agree with all of you that there are real practical concerns as well as legacy issues, and I believe that most implementations will have issues with the above declaration, and I am unsure whether it is even legal or not.

        Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, April 03, 2009 1:20 PM
To: Steven Sharp
Cc: john.havlicek@freescale.com; Greg.Jaxon@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org; sv-ac@eda.org
Subject: [sv-ac] Re: [sv-ec] Re: [sv-bc] question about integer expression


I'm with Steven on this.

In fact the LRM in 7.4.2 has an even stronger statement:
    Implementations may limit the maximum size of an array,
    but they shall allow at least 16 777 216 (2^24) elements.
Splitting hairs, the above doesn't say that the index *range*
must be bounded by 24 bit values, but preceding text is
certainly consistent with that assumption.

There are pragmatic concerns in terms of existing (very long
standing) legacy systems that would make is somewhat unlikely
to have wide-spread support for dense arrays with final index
values beyond 32bits.  Certainly there would need to be a pretty
thorough scrub of the LRM to even claim that the LRM
consistently permits such an interpretation never mind requires
it.  If, realistically, such very large arrays are required in
a testbench, one could at least deal with them cleanly be using
an associative  array which clearly is defined for very large
index values.  Practically, that does assume that such very large
arrays are (quite) sparse for non-default values but such an
assumption is likely not too unreasonable.

Gord.

Steven Sharp wrote:
> I mostly agree with what Greg wrote, but with some minor differences.
>
> I agree that there is no 32-bit context affecting the arithmetic of
> those index expressions.  They are self-determined.  I agree that the
> rewrites that Greg describes are not truly equivalent, but are just
> descriptions of approximately what it means, for a human reader.
>
> I also agree that it would be a mistake to rely on an index or range
> value larger than can be represented in 32 bits.  I would be a little
> more specific than Greg on this.  It should be fine to use an expression
> wider than 32 bits, with arithmetic of that greater width.  However, you
> should expect that the final result may be truncated to 32 bits before it
> is used as an index or range value.  Intermediate values in the expression
> may be wider than 32 bits, but the index itself will only be 32 bits.
>
> I would go further than Greg and say that this is not just a practical
> implementation issue.  The LRM contains indications that these indexes
> are actually limited to 32 bits.  The size methods return ints.  Those
> array locator methods that deal with indexes use ints for the indexes of
> non-associative arrays.  In a foreach loop, a loop variable iterating
> through a non-associative array dimension is implicitly declared to be
> of type int.  (Actually the text says that it is auto-cast to int if used
> in an expression.  This would allow an implementation to use a larger
> index for the iteration, as long as it treated it as an int when used in
> an expression.  In practice, this is not much of a distinction.)  The
> array query system functions $left, $right, $high, $low and $size all
> return type integer.  There are probably indications in other places that
> I didn't look.
>
> Steven Sharp
> sharp@cadence.com
>
>

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


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