Re: [sv-ec] email vote concurrently run for both sv-ec and the champions, ending May 27th

My ballot is attached.

Steven Sharp
sharp@cadence.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



1.  Mantis 2693   

    Ballot comment #138: Virtual interface in coverpoint?
    Yes _X_ No ___ Abstain ___

2.  Mantis 2598   

2.1 Ballot comment #52 How can class type parameters be accessed?

    Now handled by Mantis 2575 
    Close as a duplicate of 2575
    Yes _X_ No ___ Abstain ___

2.2 Ballot comment #64 Access to class type parameters

    Now handled by Mantis 2575 
    Close as a duplicate of 2575
    Yes _X_ No ___ Abstain ___

3.  Mantis 2575   

3.1 Ballot comment #50 Is this.<param_name> or handle.<param_name> allowed for 
    class parameters or local parameters of a class?
    Yes _X_ No ___ Abstain ___

3.2 Ballot comment #52 How can class type parameters be accessed?
    Yes _X_ No ___ Abstain ___

3.3 Ballot comment #55 Related to specification of hierarchical class methods 
    for triggerring. Is this limited to only static class methods or user can 
    specify object specific method as well. What happens if the object is not 
    existing?
    Yes ___ No _X_ Abstain ___

This description does not match what I have in my spreadsheet for ballot
comment #55.  The proposal for Mantis 2575 does cover what I see for #55
in my spreadsheet, so I would vote Yes if the description is changed.

I am not sure what it means to vote for some of these items and against
others anyway.  I am approving the proposal for Mantix 2575.  If we are
voting whether we think this covers the Ballot comments, then I think
this covers #55 as described in my spreadsheet.  It does not cover the
comment as described here.

3.4 Ballot comment #59 can :: or . be applied to access a class parameter or a 
    param declared inside the class?
    Yes _X_ No ___ Abstain ___

3.5 Ballot comment #64 Access to class type parameters
    Yes _X_ No ___ Abstain ___

NOTE: I do think that the wording of one of the changes in 8.22 needs to be
modified.  The intent of the first sentence in the mentioned paragraph was
to say that the operator uniquely identifies a member of a *particular*
class.  Adding the parameters after that loses the emphasis that it lets
us identify those parameters as coming from a *particular* class.  I think
the sentence

"a member of a particular class, a class parameter, or class local parameter."

should be changed to

"a member, class parameter, or class local parameter of a particular class."


4.  Mantis 2608

    Ballot Comment #59 :: access and dot access to class value parameters and 
    local parameters should be allowed

    Now handled by Mantis 2575 
    Close as a duplicate of 2575
    Yes _X_ No ___ Abstain ___

5.  Mantis 2746  

    Ballot comment #113 "others" coverage bin example
    Yes _X_ No ___ Abstain ___

6.  Mantis 2749  

    Ballot comment #53 class properties and methods are public
    Yes _X_ No ___ Abstain ___

7.  Mantis 2750  

    Ballot comment #121 "expression" should be "constant_expression" 
    Yes _X_ No ___ Abstain ___

8.  Mantis 2748

    Ballot comment #19 Preponed PLI region not included (but should be removed 
    from LRM anyway as it does not really exist)
    No change required. 
    See the bug note for an explanation as to why the figure does not need
    to be updated. 
    Yes ___ No ___ Abstain _X_

If it is possible to determine whether the simulation region or the PLI region
is executed first, then they shouldn't be specified as being the same region.
This may be impossible, if the simulator is just sampling and PLI is not
allowed to change anything during this region.  I am not certain, so I will
abstain.

9.  Mantis 2745 

    Ballot comment #111 impicit coverpoint for cross
    An enhancement request 
    Move to "Status=Resolved, Resolution=Open" and add the following bug note. 

    "The committee read and considered this feedback. the committee believes it
     is too broad for the scope of the draft to implement at this time but may
     be considered for future revisions."
    Yes _X_ No ___ Abstain ___