WRT the 34.10 matter: In June I entered Mantis item 1859, which requested . the deletion of the redundant 34.10 . a reworked sentence or two in 34.7. The item passed in June; apparently, Neil Korpusik added some notes in Sept. and then Stu has flagged it as done as of 10/3/07. I didn't know about the recent doings but it looks like the 34.10 and 34.7 changes have been made. Ralph -----Original Message----- From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org]On Behalf Of Warmke, Doug Sent: Thursday, October 11, 2007 10:09 AM To: Bresticker, Shalom; sv-bc@server.eda.org Cc: SV-CC Subject: [sv-cc] RE: [sv-bc] Stu's QUESTIONS and NOTES in Draft 4 Hi Shalom, I can take a stab at a few of these, mostly in the DPI area. (Hence I'm copying SV-CC, hello guys) 34.10: I can no longer see the question in Draft4, but I do see all the strike-through text. (Maybe my Acrobat is acting up again, though I do see other questions). I remember Stu asked SV-CC this question some months back, and the answer was "Yes", the text is redundant and can be removed. I.9.1.3 I think we should change the comment to read as follows: /* * Returns one of the following version strings: * "1800-2008" * "1800-2005" * "SV3.1a" */ const char* svDpiVersion(); I filed Mantis 2101 and uploaded a proposal for this one. SV-CC should add this to their list of items at the next meeting. (It's trivial) I.12 I think the deprecated clause should be referenced in Annex C, like the rest of the deprecated PLI material. That would be for SV-CC to decide, maybe at the next meeting? Thanks, Doug From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, October 11, 2007 4:32 AM To: sv-bc@server.eda.org Subject: [sv-bc] Stu's QUESTIONS and NOTES in Draft 4 These are all the editor's questions that I found in Draft 4. I filed them as Mantis 2099. 3.10.1: These (22.7, 22.6) are the cross-references that were in 1800-2005. Are they correct? 3.12, Table 3-1: Should "step" be added to this table? (per A.8.4) 3.12.1: The term "time scaling" is not defined in 1364-2005 or 1800-2005. Does it need to be? 6.6, Syntax 6-1: are more productions needed? (e.g. to show packed and unpacked dimensions) 6.7, Syntax 6-2: Are all these productions needed here? 6.20.1: Does this rule only apply to parameter port lists? 6.24.3: The description of this example would make more sense if the definition of source_t and dest_t were added. 6.24.3: Is "xor()" a keyword in this context (should it be bold)? (also see 7.13.3) 7.4.3: Are these rules really for "all arrays", including dynamic, associative and string? 7.13.3: Are "and()" "or()" and "xor()" keywords in this context (should they be bold)? 8.2: "A common convention is to capitalize the first letter of the class name so that it is easy to recognize class declarations." Should this LRM follow this convention? 9.6.2, Example 3: Is a new example needed? I added indentation for clarity, but: 1) The second "always" has no context. 2) The task disable does not show the "terminate execution of a named block" in the description. 10.6.1: Does the result of a cont. assign to a variable update immediately when the variable is released? 10.6.1: What about unpacked stucts, enums, classes, etc.? 10.6.2: What about unpacked stucts, enums, classes, etc. 11.2.1: Are all operators listed in table 11-1 after merging in SV still legal in constant expressions? 11.5.2: This text comes directly from 1364-2005. There was no matching subclause from 1800-2005 to merge in. Is new text needed for SV array addressing ? 11.6.1, Table 11-23: SV operators need to be added to this table. 13.4.4: Also interface and program? 16.14.3: This code looks like a mix of BNF and example. Should it be all one or the other? 19.5: should $signed/$unsigned be moved to Annex D since SV has sign casting? 20.3.1: Is string type legal? 20.3.7: Is string type legal? 21.4: What is this "unchanged behavior"? I could not find it in 1364. 22.3.1: Is this last sentence still true in SV (i.e. can it be one interface or one program)? 22.3.3.3: Is 'z correct for all net type (e.g. tri1)? 24.9: Shouldn't this new example have an intro paragraph and explanation? (Update for Draft 4: This question is filed as Mantis 1742, but is not resolved) 26.3, Syntax 26-1: The 1364-2005 BNF was organized differently than 1800's. The BC committee needs to verify that I copied the right productions. 28.3.2: Can "logic" also be used? 30.6: Can the notifier be any variable type (per the BNF) or are only 1-bit types allowed? 31.9: Is string type legal? 32.7: Are there any changes to this subclause to support SV design blocks? 34.10: This subclause seems to be mostly, if not entirely, redundant with the rest of this Clause. Can this subclause be deleted? If not, can the redundant text be replaced with cross references? 35.11: These tables were not updated as part of the merge. Are there additional routines to add? Would a better place for these tables be the beginning of clause 37? 40.7: Should this subclause be merged into Clause 36? 40.12: Should this subclause be merged into Clause 37? D.2: does "vector" need to be changed to allow for a single bit of a multidimensional packed array? D.12: does "vector" need to be changed to allow for other SV types? D.13: can the SV string type also be used? I.9.1.3: should this be changed to "P1800-2008"? I.12: Should this deprecated subclause be moved to, or referenced in, Annex C? Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, 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 Thu Oct 11 11:17:06 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 11 2007 - 11:17:25 PDT