[sv-bc] FW: Mantis Items 3075-3081

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Daniel Schostak
Sent: Monday, October 25, 2010 8:04 PM
To: sv-ec@eda.org
Subject: [sv-ec] Mantis Items 3075-3081

Mantis Item 3075 (elaboration of bind statements):
--------------------------------------------------

From the discussion in the meeting on Sep 27 2010, it appears that a number of restrictions on bind statements have been relaxed but the text of the Standard has not necessarily been updated to reflect this. For example, the statement in section 23.11 that:

"If multiple bind statements are present in a given scope, the order of those statements is not important. An implementation is free to elaborate bind statements in any order it chooses."

could be taken as forbidding one bind statement making hierarchical references to an instance created by another bind statement in the same scope. I believe from the discussion it should not be interpreted in this way and therefore I am not sure what it is trying to add. The simplest proposal would be to delete it, but if someone thinks the statement still has value I think it would be worth adding a clarifying sentence about cross module references and bind statements.

Mantis Item 3076 (standardization of $typename):
------------------------------------------------

From the discussion in the meeting on Sep 27 2010, this may be problematic to get any agreement on. However, I will try suggesting a minimum level of information for classes (which is the area I was trying to get some agreement on). I would suggest at the most basic level $typename should return the name of the class referenced by an object handle (if the object handle was a base class object handle and the class instance was a derived class the name of the derived class would be returned). I think this would facilitate creating messages for unexpected failure cases in class based testbenches so that you may have an idea of what has gone wrong before you rerun the failure with the debug features of whatever tool you are using enabled.

Mantis Item 3077 (randomization order):
---------------------------------------

Section 18.6.2 states that:

"When obj.randomize() is invoked, it first invokes pre_randomize() on obj and also all of its random object members that are enabled. After the new random values are computed and assigned, randomize() invokes post_randomize() on obj and also all of its random object members are enabled."

I would propose adding "in declaration order" at the end of both sentences. This change would imply that pre_randomize() is not invoked if an object handle is initialized by the pre_randomize() function associated with an object instance that is declared after it, but at least this clarifies what can be expected.

Mantis Item 3078 (repeating default arguments):
-----------------------------------------------

Can be closed as a duplicate of 2451 now that 2451 is resolved.

Mantis Item 3079 (%0b formatter and 4 state msb):
-------------------------------------------------

Section 21.2.1.3 indicates that if the field width is 0, or smaller than the value to be displayed, the result should be displayed in minimum width, with no leading zeros. Implementations diverge when the msb and following bit are xx and 0x: some give x and 0x respectively; whereas others give xx and x. I think that the latter is more consistent with the current wording of the Standard. Both solutions allow you to distinguish when different values are displayed, so either could be adopted as correct. I think that we need to reach a consensus on which is preferred. Once that consensus is reached I would propose adding an example to the Standard to make it clear what can be expected (it might be useful to enumerate all permutations of msb and following bit).

Mantis Item 3080 (.name() and escaped identifiers):
---------------------------------------------------

sv-bc has voted to close this as a duplicate of 2678. However, I think that the proposal associated with 2678 is inconsistent with section 5.6.1 of the Standard which states that:

"Neither the leading backslash character nor the terminating white space is considered to be part of the identifier. Therefore, an escaped identifier \cpu3 is treated the same as a nonescaped identifier cpu3."

since this implies that the leading backslash and the terminating white space should not be included.

Mantis Item 3081 ($value$plusargs and empty actual argument):
-------------------------------------------------------------

Having reread the relevant portion of the Standard I am no longer certain anything needs clarifying. I have also not been able to remind myself of what I thought the problem was by trying experiments with different implementations, so I am happy for this mantis item to be closed without any action.

From, Daniel Schostak.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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