Hi, I've incorporated all of Jim's changes in this email except item (5), which I have left as is. I have addressed all his feedback from the previous 3 emails as well. It is easier for me to manage the change in real time and I can undo any of this if needed, but it is very reasonable and friendly. I am not going to repost anything just yet, but I certainly can on short notice. My plan is to wait for any other feedback and to allow Charlie to consider whether we need discussion. Regards, John ________________________________ From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On Behalf Of Shields, John Sent: Monday, September 29, 2008 3:00 PM To: Jim Vellenga Cc: sv-cc@server.eda.org Subject: RE: [sv-cc] mantis 2226 action completed Thanks, Jim. Comments below. ________________________________ From: Jim Vellenga [mailto:vellenga@cadence.com] Sent: Monday, September 29, 2008 1:51 PM To: Shields, John Cc: SV-CC Subject: RE: [sv-cc] mantis 2226 action completed John, you have completed a heroic effort. Thanks for all the work you've put in. I finally decided to start batching myadditional observations, thoughts, and questions. Some of these will be trivial, others we may need to talk about as a committee. (These are only for parts 2 and 3.) (1) In "37.28 Class variables and class objects", in detail 3, why was the sentence "If the class var has the value of NULL, the vpiClassObj relationship applied to the class var shall return a null handle" removed? It was removed long ago in the approved proposal. I'll guess that it was somehow viewed to be obvious and did not need to be stated, but I don't recall. It is fine with me to keep it. I'll add it as a friendly amendment. (2) In "37.29 Constraint, constraint ordering, distribution', why isn't the sentence "For details on memory allocation property, see <cross reference to 37.3.7>" an additional detail, as many similar sentences are? Should be. It was an omission in the approved proposal. I'll add it as a friendly amendment. (3) In "38.x vpi_get64()", there's a double period after PLI_INT64. Got it. (4) In "38.36.1 Simulation event callbacks," there's an extra period before "When" in the description for "cbReclaimObj". Got it. (5) In "38.36.1 Simulation event callbacks," now that you've added a sentence to the description of "cbReclaimObj," I'm wondering if we should clarify it by saying "any associated callbacks should be considered invalid, except that any associated pending cbEndOfObject callbacks shall first be executed." I didn't add anything. The approved proposal had this wording. I don't think we need to wordsmith this. There is a reality when there are multiple callbacks registered for the same purpose, perhaps even from different and unrelated applications, that they will all occur and in no defined order. All the end of life callbacks for a particular object are in this bucket. Your clarifying comment really refers that situation. I don't think it needs to be said and there certainly can be no ordering implied. The associated callbacks, as I intended it, was for things like value change callbacks. We happened to remove that particular one for classes very late in the discussion, because you had not had time to give it proper consideration. That is unfortunate because it was pretty key to logging classes, but you made a good point. It think the associated callbacks is an intent that we should not lose. If anything, we could add it for other end of life callbacks. I am comfortable taking that all up in the future. (6) In "38.36.1 Simulation event callbacks," in the description for cbEndOfThread, there's a stray space between "callback" and the ensuing comma. Got it. (7) In "38.36.1 Simulation event callbacks," in the paragraph beginning with "The cbValueChange callback may be placed ...," the string "s_cb_data" should be rendered in a fixed width font, while "vpiObjId" should be rendered in bold. Got it. (8) In "38.36.1 Simulation event callbacks," in the paragraph beginning with "For a cbReclaimObj callback...," the string "s_cb_data" should be rendered in a fixed width font, and the word "vpi" in "All vpi properties" should be changed to all upper case. Got it. (9) Now that I'm taking a fresh look at "37.x vpi_release_handle()", I'm wondering if it would be better to say "The VPI routine vpi_release_handle() shall free memory allocated for VPI handles" instead of "for objects." I realize we passed it as is once before, but I don't want the standard to give the impression that executing this routine will affect the underlying simulation in any way. (10) Also in "37.x vpi_release_handle()," would it be better to replace "vpi_release_handle() shall generally be used to free memory created for iterator objects" with "vpi_release_handle may be used to free memory created for iterator objects"? The existing wording, taken from the vpi_free_object() description, has bothered me for a long time because "shall" implies a requirement that doesn't really exist. I am fine with both (9) and (10) as friendly amendments. Regards, Jim Vellenga --------------------------------------------------------- James H. Vellenga 978-262-6381 Software Architect (FAX) 978-262-6636 Cadence Design Systems, Inc. vellenga@cadence.com 270 Billerica Rd Chelmsford, MA 01824-4179 "We all work with partial information." ---------------------------------------------------------- ________________________________ From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Shields, John Sent: Monday, September 29, 2008 2:07 PM To: sv-cc@eda.org Cc: sv-champions@eda.org; Neil.Korpusik@sun.com; Karen Pieper; Bresticker, Shalom; stuart@sutherland-hdl.com Subject: [sv-cc] mantis 2226 action completed Hi Everyone, I have completed my action on 2226. I changed it to review so that I could revise files. I've removed all the draft6 revisions and added the changes baselined to draft7. All the champion and reviewer feedback has been incorporated. The Champions and the Working Group have entrusted SV-CC to to this composition work and you have entrusted that all to me. In a perfect world, I would ask Charlie to close 2226 and he in turn would ask Neil to remark it approved and turn it over to Stu. I think it would be helpful to have a quick review for composition errors and to allow the friendly amendments to be seen in context. I leave the next action to Charlie to ask for review or close the item. Because of the number of files, I have packaged them in 3 zip files. fm-clauses-mantis2226.zip contain full framemaker files for each clause (except annex C). This is what Stu asked for to minimize his effort. My notes on that are: 1) Some diagrams I could show deletions, others the real estate for the deletion was reused and one sees only the addition. 2) The annexes need normal editor work. I did not have Annex C from Stu at all, but the edit is trivial. The other 2 annexes require some minor numbering. fm-changes-only-mantis2226.zip contains framemaker files representing only what has changed in a minimal fashion suitable for efficient review. pdf-changes-only-mantis2226.zip contains pdfs of those. The framemaker change only versions were necessary(to me) for composition and I used them to create the complete clauses. Normally, Stu would start with them. It is his option to look at them and validate that the edits to the full clauses were made accurately. I used paragraph tags properly in the full clauses, but the change-only requires tag mods to insure that the numbering matched the document. Regards, John -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Sep 29 15:28:20 2008
This archive was generated by hypermail 2.1.8 : Mon Sep 29 2008 - 15:28:35 PDT