[sv-bc] RE: Evaluating bounds in array declarations

From: Brad Pierce <Brad.Pierce@synopsys.com>
Date: Mon Jun 27 2011 - 13:17:58 PDT

http://www.eda.org/svdb/view.php?id=1302 was similar

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Monday, June 27, 2011 1:14 PM
To: Brad Pierce; sv-bc
Subject: RE: Evaluating bounds in array declarations

Isn't there a Mantis on this?

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce
Sent: Monday, June 27, 2011 10:42 PM
To: sv-bc
Subject: [sv-bc] Evaluating bounds in array declarations

In an array declaration, such as

         wire [constant_expression : 0] w;

is the constant_expression

     1) statically cast to 'integer' in the SV style (that is, evaluated in the context of an assignment to the signed type 'integer'), or
     2) evaluated in a self-determined context and used as is (possibly unsigned), or
     3) evaluated in a self-determined context, but then cast to an integer?

I'm guessing 3, but don't find an answer in the LRM. Why 3? Because the issue far predates SV and its static cast, and the result of self-determined context used as-is leads to strange results.

For example, does the following have 2 bits, or a huge number of bits?

       wire [ 32'b0 - 1 : 0] w1; // type(32'b0 - 1) is unsigned

For example, does the following have 7 bits or 1 bit?

       wire [ 1'b1 + 1'b1 + 1'b1 << 1 : 0] w2; // 6 == (1'b1 + 1'b1 + 1'b1 << 1)

-- Brad

--
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, and is
believed to be clean.
Received on Mon Jun 27 13:18:35 2011

This archive was generated by hypermail 2.1.8 : Mon Jun 27 2011 - 13:18:39 PDT