RE: [sv-ec](updated) Email Vote: Response requested by Wednesday May 11 2011 11:59pm

I understand your concern and I agree that a clarification is needed. However, the "target class" includes all super-classes of the class in which the call is made. Plus, as I said I think the "downward manner" sentence will invite more questions.

I think we can close this fairly quickly since we agree (I think) on the intent and semantics, but need to do some wordsmithing. It also wouldn't hurt to avoid much of the redundancy in the current proposal.

                Arturo

From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Friday, May 06, 2011 1:06 PM
To: Arturo Salz
Cc: Mehdi Mohtashemi; sv-ec@eda.org
Subject: Re: [sv-ec](updated) Email Vote: Response requested by Wednesday May 11 2011 11:59pm

On 5/6/2011 1:01 PM, Arturo Salz wrote:

Below are my votes:

(1) Mantis 3046 ___Yes _X_No

The term "strictly downwards manner" is not well defined. Also, the language is a bit awkward in treating dotted names specially when all it should say is that normal rules apply, which already deal with the first name of a dotted name. I do agree with the outcome of the examples shown in the Mantis.

But normal rules do not apply. If the first name is not present in the
target class, one does not want to do a hierarchical search upwards
from the location of the class type definition. One wants to terminate
the search immediately and start the search in the context surrounding
the inline constraint, not the context of the class object type. That
is why a clarification is needed.

Feel free to suggest better wording. But I don't think that "normal search"
is going to be correct.

Gord.

(2) Mantis 2506 _X_Yes ___No

(3) Mantis 3531 _X_Yes ___No

(4) Mantis 3394 _X_Yes ___No

(5) Mantis 2905 _X_Yes ___No

(6) Mantis 3254 _X_Yes ___No

The sentence seems somewhat tautological: constraint_set is .. constraint set. Perhaps we can find better verbiage - the intent is to define a constraint_set as either a single constrain or a group of constrains bracketed by curly braces. I'm voting yes because the same language exists in implication so this is no worse.

(7) Mantis 3298 ___Yes _X_No

Must mention constrains: A friendly amendment (which may need discussion):

The this keyword shall only be used within nonstatic class methods, constrains, inlined constrain methods, or embedded covergroups (see 19.4) ;

(8) Mantis 3054 ___Yes _X_No

Although allowing $countones and $onehot in constrains is reasonable. There is no explicit proposal that describes the semantics associated with such constrains. For example, do these function calls partition the constrains (as with other "allowed" functions) or are they to be treated differently? If the semantics are the same as for other function calls, the LRM can simply state that constrains will allow functions *and system function* that adhere to the existing limitations.

(9) Mantis 2935 _X_Yes ___No

Arturo

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com<mailto:gordonv@model.com>
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.