RE: [sv-sc] RE: [sv-bc] Const cast of Mantis 2398

Actually, Shalom, are you sure we need a change here?
If I'm reading right, in both cases, there is an ellipsis '...', which could theoretically represent code that includes an 'end'.

________________________________
From: Bresticker, Shalom
Sent: Wednesday, August 13, 2008 7:45 AM
To: Bresticker, Shalom; Seligman, Erik; Brad Pierce; sv-bc@server.eda.org
Cc: sv-sc@server.eda.org
Subject: RE: [sv-sc] RE: [sv-bc] Const cast of Mantis 2398

I scanned through those proposals now and did not spot any violations of this.
The examples use almost exclusively single element selects, not multiple selects.

But I may have spotted a minor other problem.
In p. 14 of 2398, there are 2 versions of an example. The example contains "else begin". I think the "begin" is missing a matching "end" in both versions.

Regards,
Shalom

________________________________
From: owner-sv-sc@server.eda.org [mailto:owner-sv-sc@server.eda.org] On Behalf Of Bresticker, Shalom
Sent: Wednesday, August 13, 2008 5:35 PM
To: Seligman, Erik; Brad Pierce; sv-bc@server.eda.org
Cc: sv-sc@server.eda.org
Subject: [sv-sc] RE: [sv-bc] Const cast of Mantis 2398

I write this before looking at the proposals again:

A bit-select can be a variable.

In a non-indexed part-select, e.g. name[i:j], both the msb and lsb indexes need to be elaboration-time constants, otherwise the size (number of bits), i.e., the type (since size is part of the type) will vary at run-time.

In an indexed part-select, e.g., name[i+:width], the first part of the index (i.e., starting position) can be variable, the second part of the index, the width, must be an elab-time constant.

Shalom

________________________________
From: Seligman, Erik
Sent: Wednesday, August 13, 2008 5:29 PM
To: Bresticker, Shalom; Brad Pierce; sv-bc@server.eda.org
Cc: sv-sc@eda.org
Subject: RE: [sv-bc] Const cast of Mantis 2398

Hold on-- does the index of an expression have to be an elaboration-time constant?  Wouldn't this invalidate examples in 1900 and 2398, and in fact defeat the entire concept of assertions & checkers in procedural code as described in these proposals, since we would not be able to effectively use procedural variables in indexes?

________________________________
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
Sent: Tuesday, August 12, 2008 11:42 PM
To: Brad Pierce; sv-bc@server.eda.org
Subject: RE: [sv-bc] Const cast of Mantis 2398

Yes, that is correct.

Shalom

________________________________
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
Sent: Wednesday, August 13, 2008 9:34 AM
To: sv-bc@server.eda.org
Subject: [sv-bc] Const cast of Mantis 2398

As I understand the new const'() cast of

   http://www.eda-stds.org/svdb/view.php?id=2398

the following part-select would be illegal

       for (int i = 3; i >= 0; i--) begin
      y[ const'(i)*2 + 1 : const'(i)*2 ] = i;
   end

because const'(i) would be like a simulation-time const variable, not like an elaboration-time constant expression.

An expression may be changed to a constant with a const cast.

             const'(x)

When casting an expression as a constant, the type of the expression to be cast shall pass through unchanged. The only effect is to treat the value as though it had been used to define a const variable of the type of the expression.

Correct understanding?


n  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<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.