Attached to this email is the feedback from the Champions on mantis items that were passed by the sv-ec. One mantis item was approved, after making 3 friendly amendments to it. All of the other items from the sv-ec were sent back to the sv-ec. Several of them were reviewed in detail by one or more of the Champions. The Champions decided to send the rest of them back to the sv-ec because of the large number of issues identified. The sv-ec needs to go through the feedback provided by the Champions and review those that had no specific feedback to ensure that they are ready for the Champions. The next Champions meeting is 2-weeks from this Wednesday (Sep 5th). If any of the sv-ec mantis items are to be reviewed in that meeting they need to be ready by this Thursday. 1648 - the Champions would like the sv-ec to review this mantis item to see if it is applicable to covergroups. Neil -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-276-6385 Frontend Technologies (FTAP) Fax: 408-276-5092 Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Mantis items passed by the Champions after making friendly ammendments ---------------------------------------------------------------------- Id Summary 1789 Clarification of string behavior svec Passed unanimously by email vote June 22, 2007 Friendly ammendments: - "1. Change this sentence (on page 128)": in Draft 3a, this is page 126. - In 2, " bit [10:0] a = "\x41"; // assigns to a `b000_0100_0001": the back-tic in the comment preceding 'b' should be an apostrophe. - In 4, "one of them can be a string literal which is implicitly converted to a string type data object for the comparison": this appears twice, there should be a comma before the word 'which'. Mantis items sent back to the sv-ec for updates: ------------------------------------------------ 1787 LRM needs to discuss transition bins of length 1 svec Approved on April 30, 2007 unanimously. - 1787 should refer to 18.5.1 instead of 18.4.1. - The mantis "Additional info" section refers to sv-178702.html but that attachment was not found - There was an approved friendly amendment ("shall be illegal") That update is not in the current proposal. 1777 Clarification of 1800-2005 section 18.4.1 svec Approved on April 30, 2007 unanimously. - 1777 is not updated to Draft 3a. It refers to 18.4.1 in 1800-2005, which is apparently 18.5.1 in Draft 3a. - The struck-out text starts with "The goto repetition with nonconsecutive occurrence", but I don't see the word "goto" in the original. There may be other differences. - The capitalization of 'goto' in the proposal is inconsistent. In Draft 3a, it seems to be consistently uncapitalized. - The intransitive "will increment" is inconsistent with the rest of the paragraph that says bins are "incremented". - It's a little odd that it says "Next, ..." regarding what happens on the 15th-18th samples, and only after that talks about what happens on the 12th-13th samples. 1736 Example in 12.4.2 has dynamic array packed. svec Approved on April/24/2007 unanimously by email vote. Would be nice to change xref in Mantis summary line to 13.5.2. 1723 Size method for associative arrays svec Approved on June/11/2007 with 2 No votes: Cliff - doesn't think of size as being the number of elements, thinks of it as the address spanned, encompassed by elements already allocated. Stu - no change needed - The reference should be to 7.10.1 instead of 17.10.1. - Grammar issues "The syntax for the num() and size()methods are as follows:" should be "The syntax for the num() and size()methods is as follows:" 1680 "literal string" should be "string literal" svec Approved on April/24/2007 unanimously by email vote. - 1680 was not updated to Draft 3a. - There are text as well as section number issues. 1655 Coverage Calculation Corner Case Crumminess svec Approved on April 30, 2007 unanimously. 1. The title line of the proposal says 18.10, but it should be 18.11 (or 18.6 and 18.11). 2. Similarly, the line "ADD the specified blue text 18.5 as follows:" should refer to 18.6. 3. "intersect cross-products specified" should not be hyphenated, for consistency with LRM. 4. In "since the explicitly declared bins covers all cases for which i == 0", "bins" should be "bin". 5. "ADD the specified blue text to 18.5.1 as follows:" should refer to 18.6.1. 6. In "Additionally, the cross retains those automatically-generated bins that represent cross-products not intersecting any of the user-defined bins. There are 6 of these: <b1,a3>, <b1,a4>, <b3,a3>, <b3,a4>, <b4,a3>, and <b4,a4>," "cross-product" should not be hyphenated, and the cross products should be specified with a before b, e.g., <a3,b1> instead of <b1,a3>. 7. "MODIFY 18.6 as follows:" should be 18.7. 8. "In Table 18-29, the alignment of the cell bodies in the top three rows is not consistent with the rest of the table. The six inconsistent cells should be modified to match the rest of the table" looks already fixed in Draft 3a. 9. "MODIFY 18.10 as follows:" should be 18.11. 10. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments; the numerator and denominator." should be "is called". Yes, I know the mistake is in the existing text. 11. "In consistency with the above behavior, $get_coverage shall return a value of 100.0 if called on a design that has no constructed covergroups, or if called on a design in which all covergroups have a weight of 0." "In consistency with" sounds strange. "Consistent with" sounds better. "$get_coverage" should be "get_coverage()"? What is a "constructed covergroup"? The term does not seem to appear in the LRM. Is there a non-constructed covergroup? If not, why not just 'covergroup'? 12. "MODIFY 18.10.1 as follows:" should ne 8.11.1. 13. "ADD the following text at the very end of 18.10.2:" should be 8.11.2. 14. "In case the denominator of the cross coverage calculation formula has a value of zero:" - Better is "If the denominator ..." 15. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments-the numerator and denominator." - should be "is called". 1615 can processes spawned by functions execute blocking statements? svec Approved on October/23/2006 unanimously. - This proposal wanted to add 11.6.1 (in 1800-2005) after 11.6. The text from 11.6 is now in 9.3.2. I don't like 4th level subclauses (9.3.2.1), so I am not sure where and how to place this. - The following sentence seems hard to understand: "Calling a function that executes a fork..join_none block shall be illegal in any context in which a side effect is disallowed or any context other than procedural code originating in an initial block." I think the following would be simpler: "Calling a function that executes a fork..join_none block shall be legal only in procedural code originating in an initial block and illegal in any context in which a side effect is disallowed." (Is there a difference between "originating in an initial block" and "in an initial block"? If so, are readers going to understand the difference?) - Is the following sentence needed: "Implementations shall issue an error either at compile time or run time when they have determined the illegal condition.?" - The function declaration is called start_check, but the function calls start_checks. 1612 Timeunits decls don't make sense in class decls (BNF) svec Approved on May 2,2007 unanimously by email vote. Reference to Syntax 7-1 should be 8-1. Footnote 17 should be footnote 16. 1609 import statements should not be allowed in class scopes svec Approved on June/25/2007 unanimously. 25.2 should be 25.3. 1605 Clarification of mailbox/semaphore constructor svec Approved on October/23/2006 unanimously. The references should be 15.3.1 and 15.4.1 1580 Access to interface objects via virtual interface svec Approved on May 2, 2007 unanimously by email vote. - 20.9 should be 24.10. - "Access to all objects declared in an interface is always available by hierarchical reference, regardless of whether the interface is accessed through a port, through a virtual interface, or if there are modports to restrict those access mechanisms." I think "if" should also be "whether". - "When an interface is connected with a modport in either the module header or port connection, access through a port or through a virtual interface is limited to only objects listed in the modport, for only types of objects legal to be listed in a modport (nets, variables, tasks, functions, and clocking blocks). All other objects may be referenced." I find this wording very unclear. It is unclear what "all other objects" refers to, and it is unclear how they may be referenced. - The original text had, "All objects are still visible by hierarchical reference." This seemed to repeat the first sentence, "Access to all objects declared in an interface is always available by hierarchical reference," and if so, to be redundant. Does this proposal intend to change the meaning of the last sentence? - I also find the difference between "module header" and "port connection" unclear, since I think of port connections as part of the module header. 1556 in-line static variable initialization - require keyword static? svec Approved on June/11/2007 unanimously. 1545 13.12.1: $urandom example error svec Approved on October/9/2006 unanimously. 1480 method_call_root BNF should use primary, not expression svec Approved on October/9/2006 unanimously. 1459 Mailbox 'new' method should never return null svec Approved on September/11/2006 unanimously. 1427 dynamic_array_new svec Approved on April 30, 2007 unanimously. 1371 Semantic of program block $exit svec Approved on June/25/2007 unanimously. 1336 Rules for allowed statements in a function svec Approved on Jan/22/2007. unanimously. 888 foreach identifiers are too restrictive svec Approved on October/23/2006 unanimously. 594 15.8 special syntax for accessing interfaces through clocking block svec Approved on October/9/2006 unanimously.Received on Mon Aug 20 09:54:35 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 20 2007 - 09:55:25 PDT