RE: [P1800] Re: Champions spreadsheet posted

 yes, it should be i.

 The tick provides a differentiator between a concatenation and a
constructor.
A concatenation is a regular verilog concatenation of bits whereas a
constructor (now called assignment pattern) is not.
If you don't make that syntactic difference, it is quite complex to figure
out
what the expression is, for both the tool and the users.

Francoise
    '

-----Original Message-----
From: owner-ieee1800@eda.org [mailto:owner-ieee1800@eda.org] On Behalf Of
Neil Korpusik
Sent: Thursday, February 03, 2005 7:30 PM
To: Karen Pieper
Cc: sv-champions@eda.org; srouji@us.ibm.com; matthew.r.maidment@intel.com;
Brad.Pierce@synopsys.com; Mehdi.Mohtashemi@synopsys.com; chas;
Ghassan.Khoory@synopsys.com; fhaque@cisco.com; Arif.Samad@synopsys.com;
ieee1800@eda.org; Warmke, Doug
Subject: [P1800] Re: Champions spreadsheet posted

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
---------------------------------------------------------------------