RE: [sv-bc] question about integer expression

A few process questions -


1)      Is this ambiguity important enough that we should be asking P1800 permission to fix it in 2009?

2)      Do they have the power to give us such permission?

3)      Is there a Mantis item that captures these concerns?

-- Brad

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon
Sent: Friday, April 03, 2009 2:53 PM
To: sv-bc@eda.org
Subject: Re: [sv-bc] question about integer expression

I don't detect any disappointment with the capacity side of this
question.  I think John's original question concerns the semantics
specified for evaluation of expressions that appear in the role of
an index or bound.  There are several possibilities given the
many conventions Verilog imposes on its expression semantics.

 1.  Individual expressions in such roles are disjointly self-determined.
Steven points out that the final result might then be cast to what might
be one particular implementation-defined integral type.  It is not clear
precisely where in the arithmetic such a cast applies, in particular
whether it can ever occur before the array bounds check is applied.
 2.  Individual index or bound expressions evaluate in the context of an
assignment to an integer variable.  Presumably unsignedness here
would work in the standard way.  Again unclear whether this assignment
cast comes before or after the array bounds are checked.
 3.  If "context-determined" is a viable idea (a big if!) the context could be
determined as: the maximum width of that dimension's declared bounds.
Still we need to take care when truncating wider index expressions.
 4.  If "self-determined" is a viable idea (and the LRM does point to it),
maybe, like a case expression and its labels, all bounds and index
expressions (taken as a group) mutually self-determine one data type used
in all evaluations for that dimension.  This finesses the bounds check
question, but given hierarchical reference, it makes parsing the
index expression prohibitively expensive, maybe ill-defined, and
rife with inscrutable outcomes that depend on non-local source text.
As Gordon, and others observe, we have some immovable legacy systems to
consider here.  Do they send any clear signal? Just as clearly, we have
designs moving onto 64bit platforms that have every right to expect increased
indexing capacity.

Am I right in guessing that only options 1 and 2 above are found in the wild?
Is there any option 2 system using a non-32-bit index type?

Greg

P.S. I'm limiting this to SV-BC on the hunch that its mainly our issue.
P.P.S.  Usual disclaimer.

Gordon Vreugdenhil wrote:

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<mailto:sharp@cadence.com>









--

--------------------------------------------------------------------

Gordon Vreugdenhil                                503-685-0808

Model Technology (Mentor Graphics)                gordonv@model.com<mailto:gordonv@model.com>





--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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