All, I have reviewed the list of "trivial issues" that Chas. put forth. For the most part, I agree that they are minor changes. There are a few that I feel need a more specific proposal, or that I feel the proposed change is not correct. These item numbers are 582, 566, 535, 476, 470, 446, 444, 443, 439, 456. I am in favor of all of the other items. Details on the items I feel need further consideration follow. Stu ------------------------------------------------- > 0000582 31.8.4.2 grammar I disagree with the proposed change, which is to change "might or might not" to "may or may not" in the following paragraph: "Jump behavior refers to the behavior of vpi_goto() with a vpiTime control constant, vpiTrvsObj type, and a jump time argument. The user specifies a time to which he or she would like the traverse handle to jump, but the specified time might or might not have value changes. In that case, the traverse handle shall point to the latest VC equal to or less than the time requested." First, the word "may" has an official IEEE definition, which is "is permitted to" (see section 1.3). This definition does not fit the context of this paragraph. The word "might" is correct for this context. Second, the sentence in question is prefacing the sentence that follows. That sentance defines what should happen if the go-to time does not have a value change. Therefore, the preceding sentance should only "might not have a value change", instead of "might or might not". Third, the use of "he or she" is not proper wording in an IEEE standard. I propose that the correction 31.8.4.2 be ammended to: "Jump behavior refers to the behavior of vpi_goto() with a vpiTime control constant, vpiTrvsObj type, and a jump time argument. The user specifies a time to which he or she would like the traverse handle to should jump, but the specified time might or might not have value changes. In that case, the traverse handle shall point to the latest VC equal to or less than the time requested." Further, I propose the following related correction (removing "he") be added to errata #582: Change 31.8 item 2), fourth sentance to: Alternatively, if the user wishes he can (also) choose to add a specific vpi_load() call (this can be done at any point in time) to load, or force the load of, a specific object or collection of objects. ------------------------------------------------- > 0000566 31.6 Why is there a double line between vpi_iterate() and vpi_handle()? The PDF file for this item is not clear on what has to change. Is the the only change to remove the double line between the two rows? If so, then I agree with the change. If not, then the PDF file needs to be updated to show the exact deletions and/or additions in color before I approve the change. The PDF file describing the change indicates that the table number is to be changed. I disagree with that change. ------------------------------------------------- > 0000535 32.26 font size of note is inconsistent I agree that the font size of 31.26, note 3 is incorrect. The font sizes in 31.22 are correct. ------------------------------------------------- > 0000476 32.23 clarify vpiParent label I disagree that there is a probloem. I think the tag is as close to the one-to-one arrow as it can be, and cannot be made more clear. Unless this proposal is ammended to include a diagram showing how to make the association of the tag and the transition more obvious than it already is, I vote to disapprove this errata. My grounds for disapproval is that no change is needed. ------------------------------------------------- > 0000470 32.21 Properties should be with defn not ref I am not convinced that the proposed change is correct. It makes most of the relationships come from the class defn reference, instead of the class defn definition. I am also not convinced that any change is needed. Only one object in the diagram is being defined, so it is obvious that the properties are for that object. If a change is needed, then it should be to move the properties to under the top class defn definition, and reposition the class defn reference and associated arrows around the properties (I can do that). I would approve of this ammended change, even though I really don't think it is necessary. ------------------------------------------------- > 0000446 32.5 incorrect note The data base does not contain a proposal for the correct wording of this note. I agree that there is a problem, but cannot not vote to approve this errata without a proposal for the correction, and a chance to review the proposal. ------------------------------------------------- > 0000444 32.3 & 32.6 Superfluous note should be removed The errata comment proposes two solutions. I approve the solution to remove the note on 32.3 and 32.6. ------------------------------------------------- > 0000443 32.2 The note needs to go in section 32.7 I propose ammending the proposed to change to say that the note should be moved to 32.7, note 4, incrementing the number of subsequent notes. ------------------------------------------------- > 0000439 Annex I - implied properties are really return values I propose ammending the proposed change by modifying the comment: /* Return values for vpiConstType: */ To: /* Return values for vpiConstType property */ ------------------------------------------------- > 0000456 32.13 poorly drawn diagram - regression The required changes are not clearly described. Before I can approve this errata, a more accurate proposal needs to be made and reviewed. ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com +1-503-692-0898 > -----Original Message----- > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On > Behalf Of Charles Dawson > Sent: Thursday, March 31, 2005 11:04 AM > To: SV-CC > Subject: [sv-cc] Handling trivial issues > > Hi All, > > The following items have been identified as trivial, and the > fixes are obvious. I have assigned them to Stu, and he has > agreed to take a look at them prior to our next meeting. > Here is how I would like to address them: At our next > meeting, I would like to pass them en masse, without going > through the trouble of producing formal proposals for each of > them. In order to do this everyone (Stu in > particular) needs to look at them, and agree that the fix is > both trivial and obvious. Any issue on this list that > someone has a doubt about, I will remove, and we will address > it individually. > > So, here's the list: > > 0000603 "callee's declared the formals"? > 0000591 31.11 vpi_get_time() is a void routine - backwards > compatibility > 0000582 31.8.4.2 grammar > 0000574 31.8.3.2 Typo > 0000569 31.8.1 typos > 0000566 31.6 Why is there a double line between vpi_iterate() and vpi_handle()? > 0000535 32.26 font size of note is inconsistent 0000530 > Annex E - Examples should use DPI-C label > 0000527 32.14 grammatical error > 0000525 32.13 grammatical error > 0000504 32.53 Missing info from P1364 26.6.42 > 0000503 32.52 'return stmt' should be 'return' > 0000498 32.50 minor clarification needed here > 0000491 32.40 Missing null stmt definition > 0000479 32.26 'refobj' should be 'ref obj'. > 0000476 32.23 clarify vpiParent label > 0000471 32.21 typo in note 6 > 0000470 32.21 Properties should be with defn not ref > 0000466 32.20 'nets' should be 'scope' > 0000462 32.14 vpiParent label is poorly placed > 0000461 32.30 indentation for properties is incorrect > 0000460 32.13 need parens at end of routine properties > 0000447 32.5 missing types for properties > 0000446 32.5 incorrect note > 0000444 32.3 & 32.6 Superfluous note should be removed > 0000443 32.2 The note needs to go in section 32.7 > 0000439 Annex I - implied properties are really return values > 0000428 29.4.2 needs better whitespace > 0000502 32.51 vpiExpr should apply to entire disables class > 0000500 32.47 Implies all expressions have a vpiName > property 0000490 32.39 Indexed part select is missing > 0000488 32.38 vpiMemory should be removed > 0000477 32.25 missing newer changes from P1364 > 0000457 32.13 LHS of bottom diagram incorrectly drawn > 0000456 32.13 poorly drawn diagram - regression > > > -Chas > > > -- > Charles Dawson > Senior Engineering Manager > NC-Verilog Team > Cadence Design Systems, Inc. > 270 Billerica Road > Chelmsford, MA 01824 > (978) 262 - 6273 > chas@cadence.com > > > >Received on Fri Apr 8 07:54:43 2005
This archive was generated by hypermail 2.1.8 : Fri Apr 08 2005 - 07:54:49 PDT