Re: [sv-bc] question about integer expression

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Fri Apr 03 2009 - 14:53:05 PDT

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


    

--
--------------------------------------------------------------------
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. Received on Fri Apr 3 14:53:50 2009