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 -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) 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, and is believed to be clean.Received on Thu Apr 23 10:40:34 2009
This archive was generated by hypermail 2.1.8 : Thu Apr 23 2009 - 10:41:35 PDT