Re: [sv-bc] question about integer expression

Dave is right, the committee should only be working on ballot
comments at this point in time.


Neil



On 04/23/09 10:33, Rich, Dave wrote:
> The committee can only address ballot comments now, and the 
> recirculation ballot can only comment on responses to those initial 
> ballot comments.
> 
>  
> 
> I suggest we focus on those ballot comments now.
> 
>  
> 
> Dave
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] 
> *On Behalf Of *Bresticker, Shalom
> *Sent:* Thursday, April 23, 2009 7:54 AM
> *To:* Brad Pierce; sv-bc@eda.org
> *Subject:* RE: [sv-bc] question about integer expression
> 
>  
> 
> My opinion:
> 
>  
> 
> 1. Probably not.
> 
> 2. Probably not.
> 
> 3. Mantis 1302 captured some of this, but that Mantis is now closed, so 
> a new one is probably needed.
> 
>  
> 
> Shalom
> 
>  
> 
> Shalom Bresticker
> Intel LAD DA
> Jerusalem, Israel
> +972  2 589 6582 (office)
> +972 54 721 1033 (cell)
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] 
> *On Behalf Of *Brad Pierce
> *Sent:* Wednesday, April 22, 2009 9:22 PM
> *To:* sv-bc@eda.org
> *Subject:* 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
> 
> ---------------------------------------------------------------------
> 
> Intel Israel (74) Limited
> 
>  
> 
> This e-mail and any attachments may contain confidential material for
> 
> the sole use of the intended recipient(s). Any review or distribution
> 
> by others is strictly prohibited. If you are not the intended
> 
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> 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* <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.