Dave sent this to the Champions and it bounced.
K
>Karen,
>
>
>
>I can recommend all items except for SystemVerilog-BC 254, on which I will abstain.
>
>
>
>I have two reasons for not recommending 254 at this time:
>
>
> * This is a backward incompatible change from already implemented syntax of the Accellera SystemVerilog 3.0 standard. By the time this change is ratified and available to the end user, there will be a significant amount of code that will no longer be compatible.
> * I do not agree with the process in which this proposal was put through to be passed. Although I commend the effort that everyone put into this, especially Brad Pierce, I believe there was not nearly enough time (less than three days) review the 20 pages of changes, other dependencies, and explore alternative solutions that could have preserved the existing syntax.
>
>
>Dave
>
>
>
>
>
>
>
>
>
>----------
>From: owner-sv-champions@eda.org [mailto:owner-sv-champions@eda.org] On Behalf Of Karen Pieper
>Sent: Thursday, February 03, 2005 8:33 AM
>To: sv-champions@eda.org; srouji@us.ibm.com; Karen.Pieper@synopsys.com; matthew.r.maidment@intel.com; Brad.Pierce@synopsys.com; Mehdi.Mohtashemi@synopsys.com; Neil.Korpusik@Sun.COM; chas@cadence.com; Ghassan.Khoory@synopsys.com; fhaque@cisco.com; Arif.Samad@synopsys.com; ieee1800@eda.org; Warmke, Doug
>Subject: [sv-champions] Champions spreadsheet posted
>
>
>
>Hi, all,
>
> I've posted the Champions issue list for tomorrow mornings P1800 meeting at:
>
>http://www.eda-twiki.org/sv/sv-champions/Resolved_Issues_05_02_02.htm
>
> Note: this is the last meeting where issues can be passed before the balloting LRM is created.
>
>Chairs, please review the list to make sure that everything your committee needs to have passed is in the list.
>
>Champions, please cast a vote on each item in the spreadsheet by 8pm Pacific time tonight. The choices are:
>
> Recommend approval
> Recommend rejection for this revision of the LRM (please add a comment that I can read to the P1800)
>
>The list again for voting:
>
>IdCategorySummaryResolutionDup IDSV-* Vote
>368SV-BCBNF for bind_target_scopefixed0Unanimous
>367SV-BCReconcile conflicts in approved proposalsfixed0Unanimous
>366SV-CCPart Select Utility Semantics: Choice and Clarificationfixed0Unanimous
>365SV-ACmisleading use of semicolon in action blocksfixed0Unanimous
>364SV-ACIncorrect use of ## for multiple clock concatenationfixed0Unanimous
>363SV-ACMisleading labels for the last assume examplefixed0Unanimous
>362SV-ACIncorrect description of last example for multi-clocksfixed0Unanimous
>361SV-ACIncorrect multi-clock examplefixed0Unanimous
>360SV-ACIncorrect description of a figure/examplefixed0Unanimous
>359SV-ACMissing assume statementfixed0Unanimous
>358SV-ACIncorrect description of an examplefixed0Unanimous
>357SV-BCUnpacked wire assignment requires element equivalencefixed0Unanimous
>356SV-BCerror in example section 2.7fixed0Unanimous
>355SV-CCvpiMember, not vpiMembersduplicate353Unanimous
>350SV-CCSmall change needed in svdpi.h preprocessor codefixed0Unanimous
>349SV-CCconst-ness needed for DPI string argumentsfixed0Unanimous
>333SV-CCVPI support for types on wiresfixed0Unanimous
>313V-PTFPTF 296: Generate stmts will need change made in VPIfixed0Unanimous
>254SV-BCAggregate expressions (14, 94, 100, 102, 112, 146, 212)fixed01 opposedConcern for loss of backwards compatibility and divergence from C, polymorphism
>234SV-ECassociative_dimension BNFfixed0Unanimous
>196SV-ACHM1: Allow optional argument types in sequences/propertiesfixed0Unanimous
>52SV-CCvpiFuncType return values for systemVerilog datatypesfixed0Unanimous
>50SV-CCChange DPI svLogicVec32 representation to match PLI/VPI aval/bval representationfixed0Unanimous
>
>Thanks,
>
>Karen
Received on Thu Feb 3 15:35:04 2005
This archive was generated by hypermail 2.1.8 : Thu Feb 03 2005 - 15:35:06 PST