Then the indentation is bad. Let's do it right instead of finding excuses for leaving it unfixed. I have no problem fixing it at the Champions' level without sending it back to SV-SC. Shalom ________________________________ From: Seligman, Erik Sent: Wednesday, August 13, 2008 8:41 PM To: Bresticker, Shalom; 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 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. --------------------------------------------------------------------- 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 Wed Aug 13 10:57:50 2008
This archive was generated by hypermail 2.1.8 : Wed Aug 13 2008 - 10:58:15 PDT