[sv-champions] email vote

Here are my votes, I need more time to review 16 and 17.
I will send these tomorrow.
Francoise
        '

 1. 1653<http://www.eda-twiki.org/svdb/view.php?id=1653> SV-CC Cannot get to class defn from VPI class typespec
No change required
On Sep-28-2011, the SV-CC voted to resolve this issue as 'no change required'. (unanimous)

Approve _X_ Oppose __

 2. 1649<http://www.eda-twiki.org/svdb/view.php?id=1649> SV-CC Undefined possibly redundant VPI constraint object types
No change required
On Sep-28-2011, the SV-CC voted to resolve this issue as 'no change required'. (unanimous)

Approve _X_ Oppose __

 3. 3772<http://www.eda-twiki.org/svdb/view.php?id=3772> SV-CC vpiParameter label is missing in first diagram in "37.2 Parameter, spec param...."
There is a proposal (1 page) - very minor change
On Sep-28-2011, the SV-CC PASSED this proposal. (unanimous)

Approve _X_ Oppose __

 4. 3192<http://www.eda-twiki.org/svdb/view.php?id=3192> SV-CC 37.8 section has wrong value definitions for vpiAccessType
There is a proposal (1 page) - minor changes
On Sep-28-2011, the SV-CC PASSED this proposal. (unanimous)

Approve _X_ Oppose __

 5. 3230<http://www.eda-twiki.org/svdb/view.php?id=3230> SV-EC task should be function in definition of static functions
There is a proposal (1 page)
On November 8, 2010 the SV-BC unanimously approved the attached proposal.

Approve _X_ Oppose __

I approve the change but the mantis proposal does not match the entered issue and the mantis proposal does not follow the guidelines. The title (Class tasks and functions may not be static) is different from the title (tsk should be function in definition of static functions) in the mantis database and the changes are different than the ones described in mantis. I think that a note to the editor explaining what has been done should be sufficient to clarify the changes made.

 6. 2845<http://www.eda-twiki.org/svdb/view.php?id=2845> SV-EC virtual interface type checking versus interface type that had been defparam'ed
There is a proposal (1 page)

    approved in Jan17 2011 sv-ec meeting:
    Move: Francoise accept 2845-v3.pdf proposal for this mantis
  Second: Jonathan
 Abstain: Gord, Arturo
          [no inherent objection, but this could potentially complicate sv-bc changes]
          [no inherent objection, this has to do with a deprecated syntax/feature]
 Opposed:
 Aapproved [13 people were on line at the time of the vote]

Approve _X_ Oppose __

 7. 1352<http://www.eda-twiki.org/svdb/view.php?id=1352> SV-CC VPI 27.37 "Multiclock sequence expression" error
There is a proposal (2 pages)
On Aug-17-2011, the SV-CC voted to re-submit the proposal to the Champions based upon the comments by Bassam and Shalom. (unanimous)
Approve _X_ Oppose __

Note to the editor that 37.52 is the wrong reference, should be 37.54

 8. 3022<http://www.eda-twiki.org/svdb/view.php?id=3022> SV-CC Annex I import/export reversals
There is a proposal (2 pages) - minor changes
On Aug-31-2011, the SV-CC PASSED this proposal. (unanimous)

Approve _X_ Oppose __

 9. 1067<http://www.eda-twiki.org/svdb/view.php?id=1067> SV-BC out-of-range or x/z index to array of reals
There is a proposal (3 pages)
On September 26, 2011 the SV-BC unanimously approved the attached proposal.

Approve _X_ Oppose __

 10. 2093<http://www.eda-twiki.org/svdb/view.php?id=2093> SV-AC Checker construct should permit output arguments
There is a proposal (6 pages)
The proposal was updated based on Champion's feedback.

Approve __ Oppose __

Oppose with comments: Page 6 says: Checker actual output arguments shall be variable_lvalue or net_lvalue. I thought that checker arguments could not be nets. Can you pass an input wire to a checker? can you have an output argument be a net? Note that VPI still does not have checker VPI model

 11. 3069<http://www.eda-twiki.org/svdb/view.php?id=3069> SV-AC Relax rules for $global_clock resolution
There is a proposal (6 pages)
The amended proposal passed by voice vote 2011-08-23: 7y/0n/0a.

Approve __ Oppose __

I will approve if a reason is given of why can't a global clock be declared in the compilation unit or a package, that way it would be visible to the whole design or to where the package is imported.

 12. 3113<http://www.eda-twiki.org/svdb/view.php?id=3113> SV-AC Add port_identifier to constant_primary BNF for sequences, properties and checkers
There is a proposal (7 pages)
Passed by voice vote 2011-08-30: 10y/0n/0a.

Approve _X_ Oppose __

 13. 3206<http://www.eda-twiki.org/svdb/view.php?id=3206> SV-AC Deferred assertions are sensitive to glitches
There is a proposal (6 pages)
Amended proposal approved by voice vote 2011-09-06: 10y/0n/0a.

Approve _X_ Oppose __

 14. 2328<http://www.eda-twiki.org/svdb/view.php?id=2328> SV-AC Review and relax restrictions on data types in assertions
There is a proposal (9 pages)
Passed by email ballot 2011-08-22: 9y/0n/0a.

Approve _X_ Oppose __

 15. 3295<http://www.eda-twiki.org/svdb/view.php?id=3295> SV-AC need a way to control only asserts/covers/assume directives
There is a proposal (11 pages)
Amended proposal passed by voice vote 2011-08-16: 9y/0n/0a.

Approve __ Oppose _X_

I think that this kind of language enhancement should be reviewed by the BC or EC committee. It could be complex to try to control assertion execution. This smells like fine grain assertion control. I am wondering if process kill, suspend and resume could be used to the same effect. Have we considered the implementation complexity for controlling assertions?

 16. 3213<http://www.eda-twiki.org/svdb/view.php?id=3213> SV-AC Update definition of sampled value
There is a proposal (11 pages)
The proposal amended following Stu's comments was accepted by the voice vote 2011-10-11: 8y/0n/0a.

Approve __ Oppose __

 17. 3033<http://www.eda-twiki.org/svdb/view.php?id=3033> SV-AC Enhance checker modeling capabilities
There is a proposal (19 pages)
Some of the Champions needed more time to review the proposal.
Changed the proposal summary to "Enhance checker modeling capabilities" following Shalom's request. This change was approved by the SV-AC voice vote 2011-10-11: 8y/0n/0a.

Approve __ Oppose __

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