[sv-ec] Results from the Champions and the P1800

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Sat Sep 01 2007 - 20:20:11 PDT
See the attachment for details.

Neil



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Results of Champions and P1800 Working Group reviews of SV-EC mantis items:

  - At the P1800 Working Group meeting held Aug 30th all of the mantis items
    that were passed by the Champions were approved by the P1800. This
    includes those mantis items that were approved by the Champions in their
    5-day email vote which concluded Aug 29.
  - The six mantis items that failed the Champions email vote will be on the
    agenda for the next Champions meeting.  It is still possible for these to
    pass at the next Champions meeting, since it only takes one no vote during
    an email vote to cause a proposal to fail.
  - Those mantis items with friendly ammendments can not be sent to the Editor
    until the friendly amendments are made by the Technical Committee. This
    requirement was stipulated in the motion made in the P1800 Working Group
    meeting.
  - I am the person that will send the mantis items to the Editor.


1.  1789  passed
2.  1787  passed - friendly ammendments suggested
3.  1777  passed - friendly ammendments suggested
4.  1736  passed 
5.  1723  failed   2 no votes
6.  1680  passed - mantis 2002 was opened to address additional issues
7.  1655  passed - friendly ammendments suggested
8.  1615  failed   2 no votes 
9.  1612  passed  
10. 1609  failed   1 no vote 
11. 1605  passed  
12. 1580  failed   2 no votes
13. 1556  failed   3 no votes 
14. 1545  passed 
15. 1480  passed 
16. 1427  passed  
17. 1371  passed - friendly ammendments suggested
18. 1336  failed   1 no vote
19.  888  passed - friendly ammendments suggested
20.  594  passed



SV-EC Mantis items passed by the Champions after making friendly ammendments:
-----------------------------------------------------------------------------
10.    1789  Friendly ammendments were added


SV-EC Mantis items sent back to the sv-ec for updates and further review:
-------------------------------------------------------------------------
11.    1787  changes by the Champions were made
             Friendly ammendments suggested
             1) The editor, when implementing 1787, change both occurrences 
                of "range_value" to "value_range".
12.    1777  changes by the Champions were made
             Friendly ammendments suggested
	     1) The editor, when implementing 1777, change both occurrences of
		"An arbitrary number" to "Any number" and delete 'arbitrary' 
                from "any number of arbitrary".
	     2) In the next to last paragraph, in "Transition bin b5", the word
	        "Transition" should be added and not struck out.

13.    1736  changes by the Champions were made
14. No 1723  changes by the Champions were made
             1) Needs an example of the new method.
             2) Not clear that that the indexing expressions are still legal 
                after the change from [*] to [int].
	     3) Not clear that the change from [*] to [int] is correct, 
                "According to [7.9.4], all of these unsigned 
	        integral values are sign extended to 32 bits, becoming negative 
	        ints.  Was that the intent of your change?"

	        Can't it be left unchanged, as [*] ?

15.    1680  changes by the Champions were made
	     Several changes suggested to be addressed in a separate mantis.  
             These are listed in a bugnote to mantis 1680.
	     [Neil] mantis item 2002 has been opened to address these issues.

16.    1655  changes by the Champions were made
             Friendly ammendments suggested
	     The sentence, "The changes in this proposal are based on the
	     P1800-2008-draft2.pdf document" should refer to Draft 3a to avoid
	     confusion.

17. No 1615  changes by the Champions were made
	     I still feel that this language of 1615 is confusing:
		"Calling a function that executes a fork..join_none block shall 
		be illegal in any context in which ... or any context other 
		than in ..." 
	     1) Is there any reason to write, "in any context in which" instead 
		of simply "wherever"?
	     2) Can't "illegal in ... any context other than in" be written 
		simply as "legal only in"?
	     3) Probably "or" should be "and".

	     I don't think this is minor wordsmithing. I think the proposed 
	     language is confusing.

	     4) Also, in "Examples of such illegal contexts are ... static 
		variable declaration initialized", should the last word be 
		"initializers"?
	     5) "initial block" should be "initial procedure".
	     6) The sentence pointed out by Shalom is confusing : 
	        "Calling a function that executes a fork..join_none block 
                 shall be illegal in any context in which ... or any context 
                 other than in ..." 

             Friendly ammendments suggested
	     The editor, when implementing 1615, change "join_noen" to 
	     "join_none".
18.    1612  changes by the Champions were made
19. No 1609  changes by the Champions were made
	     The new text is out of place where proposed, as becomes more
	     apparent if you look at the full original paragraph instead of 
	     just the proposal in isolation.  The better place for this 
	     restriction is a normative footnote in the BNF, specifically on 
	     the first production in class_property of A.1.8.  It should say 
	     something like, "It shall be illegal for a data_declaration in a 
	     class_property to be a package_import_declaration."
20.    1605  changes by the Champions were made
21. No 1580  changes by the Champions were made
	     1) If the following re-ordering suggesting is adopted, I would 
                change my vote to yes.

	    "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)."

	 Maybe it's just an ordering problem, and should say something like

	    "When an interface is connected with a modport in either the module
	 header or port connection, then, for those types of objects legal to be
	 listed in a modport (nets, variables, subroutines, and clocking 
         blocks), access through a port or through a virtual interface is 
         limited to only those objects listed in the modport."

	 Now looking at your commentary, I see it says that "The wording wasn't
	 changed since the sv-ec went through several iterations to converge on
	 the correct wording."  I don't agree that it's the "correct wording".

	     2) I still think the last sentence, "All other objects may be 
	        referenced," is still a little unclear. Better would be, if I 
		have understood it correctly, "All other objects may be 
		referenced even through a port or a virtual interface." If I 
		did not understand it correctly, then my vote is still no.
	     Editorial corrections:
	     3) Change "in either the module header or port connection" to
	        "in either the module header or a port connection".
	     4) Change "or if there are modports" to "or whether there are 
		modports".
	     5) The last two sentences conflict with each other.
	        The sentence "When an interface...is limited to ...". 
	        Next sentence " All other objects may be referenced"
             Friendly ammendments suggested
	     1) The editor, when implementing 1580, clarify the text to make 
                it read more smoothly, taking into account Shalom's earlier 
                comments, and reordering the penultimate sentence to "When an 
                interface is connected with a modport in either the module 
                header or port connection, then, for those types of objects 
                legal to be listed in a modport (nets, variables, subroutines, 
                and clocking blocks), access through a port or through a 
                virtual interface is limited to only those objects listed in 
                the modport."
22. No 1556  no changes were needed
	     1) Doesn't this break backward compatibility with traditional
	        Verilog by requiring an explicit lifetime keyword for all 
                initialized variables in static tasks and functions?
	     2) In any case, reverting this change is not necessary.  Users
	        are free to add 'static', and methodologies are free to require
	        'static', but there's no language reason to again make it 
                mandatory for everybody.
	     3) The example is confusing.
	     4) The comments in the example are wrong, because they say 
                1 2 3 3 3 3 3 3 3 3 should be printed, 
                but actually it should be 2 3 4 4 4 4 4 4 4
             5) The example comments are not correct, since the code should 
		not compile.  The actual behavior would depend on how the 
		illegality is fixed.  It also seems to depend on an execution 
		ordering which is not specified in the LRM.

23.    1545  section numbers were updated
24.    1480  no changes were needed
25.    1427  section numbers were updated
26.    1371  no changes were required
             Friendly ammendments suggested
	     "constructs", as in "initial constructs", should be "procedures".

27. No 1336  section numbers were updated
	     1) Same wording problem as in 1615.
	     2) Question:
		1615 proposal says, "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."

		1336 proposal says, "A function that tries to schedule an event 
		that will become active only after that function returns shall 
		be an error in any context in which a side effect is disallowed 
		or in any context other than a thread originating in an initial 
		or always block."

		1615 proposal does not mention always block and 1336 proposal 
		does. Is that correct?
	     3) "always block" should be "always procedure".
             Friendly ammendments suggested
	     The editor, when implementing 1336, change "shall not have" 
             to "shall not contain".
28.     888  section numbers were updated
             Friendly ammendments suggested
	     The editor, when implmenting 888, make sure the dot after 
             implicit_class_handle is red.
29.     594  section numbers were updated
Received on Sat Sep 1 20:20:36 2007

This archive was generated by hypermail 2.1.8 : Sat Sep 01 2007 - 20:21:04 PDT