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

I recall that this was discussed in the bc (see http://www.eda-stds.org/svdb/view.php?id=1302) where Shalom expressed an opinion that "integer expression" was intended to be interpreted as not a real number. That Mantis changed the rules for indexing expressions to be self-determined. However, that Mantis allowed the "integer expression" language to remain in the LRM, which has been interpreted by many people to mean "of type integer", that is, a 4-state, 32-bit, signed datum.

Sadly, having these two sentences talking about indexing expressions being "integer expression" and "self-determined" in the same paragraph IMHO makes the LRM contradictory. If an index expression is to be of type integer then the expression has an implicit (integer) context and can not really be evaluated in a self-determined context. Conversely, if it is evaluated in a self-determined context, it may not be an integer expression.

I believe the intent of the LRM was (as Shalom wrote) to require indexing expressions to be "integral expressions". A strong argument supporting this opinion is that from the perspective of a hardware specification language it would seem silly to require compliant hardware implementations to always use a 32-bit (i.e. integer) arithmetic unit to compute array indices - and I doubt any synthesis tool would do that. But, if that's indeed the case then I'm afraid we'll need a fair amount of clarification and clean regarding indices. Note that the same language (integer expressions and self-determined) is used for both indexed and non-indexed part-selects, and this also brings questions. For example, the examples in the LRM imply that V[E +: W] is the same as V[E : E+W], however, that indentify may not hold if E and W have different precisions (and they must each be evaluated in a self-determined context). Furthermore, section 6.9.1 uses the same language (integer expressions) when specifying the bounds (declaration) of a vector. That section seems pretty clear that an array width is implicitly an integer, which must be at least 2^16. And, the use of "integer expressions" in this section has been taken quite literally to mean expressions of type integer by several implementations - several tools will flag the following declaration as illegal:

  reg [48'hfffffffffff0:48'hfffffffffff3] r1;   // a 4-bit vector with large index values

Declarations like the one above suggest that perhaps not all index expressions must be signed - something that the LRM is quite explicit about. The answer to these questions also affects how other operations such foreach define the index type.
The bottom line is that the use of "integer expression", which was inherited from P1364 leads to a lot of ambiguity and is probably in need of much cleanup, regardless of which semantics the committee decides formulate.

        Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Wednesday, April 01, 2009 11:01 PM
To: john.havlicek@freescale.com; sv-bc@server.eda.org; sv-ec@server.eda.org; sv-ac@server.eda.org
Subject: [sv-ac] RE: [sv-ec] question about integer expression

Shouldn't it be "integral expression"?

Dmitry

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of John Havlicek
Sent: Thursday, April 02, 2009 2:27 AM
To: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-ac@server.eda.org
Subject: [sv-ec] question about integer expression

Hi Folks:

The LRM uses the phrases "integer expression" and "constant integer
expression" a number of places in Clauses 6, 7, and 11 in describing
indexing into vectors and arrays and bit- and part-selects.

I could not find a definition of "integer expression".

Can anyone comment on whether "integer expression" is intended to
limit the result of the expression evaluation to what can be stored in
the 32-bit integer data type?

I think that the answer should be "no".

There is a presentation of "integer types" in Clause 6.11, and it is
clear that "integer type" is not limited to 32 bits (could be shorter
or longer).

A prompt reply is greatly appreciated,

John Havlicek


--
This message has been scanned for viruses and
dangerous content by MailScanner, 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, and is
believed to be clean.



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