[sv-ec] Feedback from the Champions

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Mon Aug 20 2007 - 09:53:45 PDT
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