I approve all of the errata except for the following:
367 - This changes what was approved by the sv-ec in 275. The change approved
by the sv-bc should go to the sv-ec for review. I saw email from some
people that didn't agree with what was approved by the sv-bc.
366 - I suggest a minor correction here. It looks like the word parameter is
used where the work argument should be used instead.
It also appears that there is a mistake in the section that describes
which bits are read.
[(i+w-1):i] <--- destination bits for writing
[(i+w-1):0] <--- source bits for reading (shouldn't that 0 be i?)
254 - This erratum overlaps with work done in the SV-EC but the svec wasn't
involved in this errata.
The changes appear to be far-reaching and I question the wisdom of making
such a change in such a short period of time. All of those ticks
seem to be very messy.
Neil
Karen Pieper wrote:
> 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
>
-- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------Received on Thu Feb 3 16:29:55 2005
This archive was generated by hypermail 2.1.8 : Thu Feb 03 2005 - 16:29:59 PST