[sv-champions] Minutes of Champions meeting held Nov 8th

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Tue Nov 13 2007 - 17:37:27 PST
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Champions meeting minutes of November 8, 2007
8am - 10am PST

Attendees:
----------
* Stu
* Surrendra
* Brad
* Francoise
* Shalom
* John
* Dave
* Neil 


1. List of mantis items that failed a previous Champion's email vote:

 1383	SV-AC	Property coverage definition

	John - The last time this Mantis item was reviewed by the Champions it 
	       hadn't yet been voted by the svac to be resolved as "won't fix"
	 Stu - The current resolution is "won't fix" but it looks like it is 
	       actually a duplicate of 805 (Re: bug notes)
        John - It touches a bunch of stuff, including 1768
	     - A resolution of duplicate is more accurate.

	    Move: Stu - approve moving the resolution for 1383 to duplicate
	  Second: Brad 
	    passed unanimously


 1751	SV-CC	Clarify vpiParent for part selects

      Shalom - accepts Jim's feedback on the issue he raised in the bug note.

            Move: Francoise - approve the proposal for 1751
          Second: Shalom 
	    passed unanimously


 1745	SV-BC	"outside of" and "inside of" are bad style

	Neil - Dave voted no in the email vote, didn't object to the proposal
	       but thought that the change didn't justify the amount of time. 

            Move: Brad - approve the proposal for mantis 1745
          Second: Stu
	    passed unanimously (Dave was not online at the time)


 1462	SV-BC	19.5, A.1.2: timeunits_declaration formatting confusing

AI/Shalom - remove the proposals , move to duplicate state

            Move: Shalom - approve the resolution of "duplicate" for 1462
          Second: Stu
	    passed unanimously


 1340	SV-BC	inconsistency between module ports and task arguments

      Shalom - did some research on John's comments. 
	     - there are several places in the LRM that could be affected:
	       modules, interfaces, programs
	     - tasks and functions are a bit different (don't have wires)
	     - the rules in the LRM may not be defined well enough today
	     - it concerns him
	     - it doesn't seem to invalidate this proposal though
	     - the proposal doesn't make the situation any worse
	     - John's comments are valid
      John   - was unable to assign an unambiguous value to the language in this 
	       proposal, but is an existing issue. 
	     - the existing rules are not clear
	     - there will also be an issues in the svac for sequences for the 
	       same problem
	     - in John's example in the bug note - what is b?
	FM   - the full definition is either all there or not at all, b is a
	       signed logic in this example
      Shalom - the LRM is not clear on this point
      Stu    - Doesn't want to create a new mantis item for this issue
	       wants the global fix to be made instead.
      Brad   - a new mantis item most likely won't get fixed due to the workload
	       If this one is rejected it will raise the urgency of the issue.
	     - should it be done in this version of the LRM?
      Shalom - thinks it should be fixed.
      Stu    - thinks the svbc will address the issue if the champions reject it
	          1. already on their plate
	          2. svac needs input also on the same issue
      John   - the svac will be working on 1667 with this issue in it
      Brad   - send it back if champions think it should be fixed
   Surrendra - the proposal changes the statement, a little bit (inaccurate)
      Shalom - the svbc thought the proposal was more accurate
		(int i, j)  - j is an int, it inherits, existing text 

            Move: Stu - send 1340 back to the svbc - with this issue flagged.
		 The svbc needs to update the LRM with more global rules for 
		 the issue raised in item 1. of John's feedback as a Champion,
		 which is shown in the bug note that Neil added on Oct 3rd.
		 This particular proposal doesn't add anything that is wrong but
		 it has made it clear that an issue exists.
		 Other constructs with port lists and argument list have issues 
		 with the "inheritance of argument lists".
          Second: John
	    passed unanimously


2. List of mantis items not yet reviewed by the Champions:

 2090	SV-AC	Concurrent assertion instantiation - inconsistent wording

        John - the Word doc is for sharing the source so others can make 
	       minor changes. The pdf file contains the official proposal.

            Move: Brad - approve the proposal for mantis 2090
          Second: Shalom
	    passed unanimously


 1758	SV-AC	Boolean implication -> and equivalence <->

   Francoise - this introduces a couple of new operators, the vpi will need to 
	       be updated as well
	     - we could create a new mantis item for that
	John - Bassam is on both committees and he has been defining the VPI
	       changes for several of the svac mantis proposals.
	Dave - it needs to go to the svbc, the proposal has nothing to do with 
	       assertions
	John - the changes are being added at the expression level not the
	       assertion level
	     - the svbc needs to review it
      Shalom - svac should send the svbc some reasons for adding this
	Dave - has no problem with the operators themselves, but we need to 
	       make sure that they are added properly
	Brad - had a question on the parenthesizing shorthand, in particular 
	       with the associativity rules
      Shalom - not the same associativity as in operators it is built from.

            Move: Dave - send mantis item 1758 to the svbc for approval
          Second: Brad
	    passed unanimously

AI/John - send input to the svbc on the reasons behind adding these new 
          operators
AI/Neil - Make sure Mantis 1758 is sent to the svcc as well.
	  Needs to be approved by the svbc and a new mantis needs to be 
	  opened for the svcc if the svbc approves 1758, two new boolean 
	  operator are being added.


 1728	SV-AC	Introduce "let"statement

      Shalom - has a minor issue with the examples:
	       the equivalent code seems to need an extra set of 
	       parenthesis in several places (see Shalom's bug note)
      John   - thinks Shalom is correct
	     - the svac would need to re-approve it 
	       ok for champions to send it back to the svac
   Francoise - did svcc review the vpi changes? - page 11, and 36.76, 
       Brad  - (bit clock) - in part e - bits can't be inout - logic clock 
	       would be ok, or say input   <----- friendly amendment
      Shalom - original has c cat and d dog as logic, rewritten one has bit
	     - need to check other examples

            Move: Francoise - send mantis item 1728 back to svac for changes.
			      Shalom's changes to the examples need to be made.
			      Brad's friendly amendment needs to be addressed.
			      Some of the examples seem to have changes in 
			      unexpected places. 
			      Needs to be reviewed by the svcc
          Second: John
	    passed unanimously


 1668	SV-AC	Local variable initializers.

        John - this proposal was reviewed in detail by the svac
        Stu  - Editor concern - in F.1 - note to editor in green 
	       Which section is does this refer to?
	John - new sub-clause in this file is the one they are referring to. 
	     - change note to point to the new clause. 
	Stu  - multiple pdfs - he only looks at latest file
	     - there needs to be a note in the pdf that there are multiple 
	       parts to the changes
	     - can name the two parts as part 1, 2
	John - he can merge the two proposals into one pdf
	Stu  - the fonts used in here can also be problematic (with IEEE also)
	     - graphics text box for special symbols
	Neil - at this point we moved to 1549... 
	       there is a dependency in annex F on 1549
	       <stopped here>
	     - ok, we are done with 1549 (sent it back)
	       <can't finish up with 1668 since 1549 was sent back>

AI/John - make those changes to the notes to the editor


 1641  SV-AC  need a way to specify severity for printing general error messages
       <we didn't discuss this, we jumped around a bit and then ran out of time>

 1549	SV-AC  add missing formal argument types

	John - the first 2 files in Mantis are commentary
	     - 2 docs contain the proposal - pdf for first part, pdf and word 
	       for second part
        Stu  - heavy use of the word "may" (seems like a lot should be "can")
        John - there are some issues with parentheses being allowed 
	       or not ($,etc) 
	Brad - why need parens around a primary?
	     - the text is unusual in that it says only added when needed.
	     - could there be issues later because missing parens?
	       sometimes can't have parens since illegal
      Shalom - if the actual argument is a+b, when the formal argument is c
             - c*d is in the code 
	       a+b*d are the substituted values but really want (a+b)*d
             - acts like text substitution in a macro
        John - thinks the cases where parens are not legal don't cause problems 
	       concern about later can't be a compound expression 
	Brad - should the special cases be enumerated?
	       it is strangely written today
	John - there might be other cases that aren't known
	     - could declare other cases to be illegal
        Brad - ok with creating a new mantis to address this parens issue
        Stu  - did the svac take a serious look at the use of the word 'may'
	       (John used it on purpose) deliberate choices were used to 
	       select which word used?
	       The answer was yes, they were. 
	John - "is permitted to" - may  - legality of language usage
	       "is able to"      - can  - potentially useful ways of employing
		the language
  	       is ok to review the switch with Stu
      Shalom - a tool "may" issue a warning, an overflow "can" occur (examples)
             - didn't see a problem in the usages of may flagged by Stu
        Stu  - footnotes are informative, those on page 5 appear to be normative
	     - IEEE rule 
      Shalom - footnotes to tables are normative! (yes, the rules are confusing)
	     - see mantis 1982 about making $ a primary (FYI)

AI/John - move footnotes into the body of the text
AI/John - create a new mantis item on $, and parens issue
AI/Brad - issue with annex A.10 - footnotes always informative?
AI/John - Make it obvious that there are 2 pdfs involved in the proposal
AI/John - talk to Stu about the font issues to make editor's life easier
	  svcc delivers some documents as frame source files

            Move: John - send mantis item 1549 back to the svac for changes
          Second: Brad
	    passed unanimously


 1942	SV-CC Deprecated vpiArray property still appears in several places 
	      where vpiArrayMember should replace it.
 1367	SV-CC Section 27.11 Ports - the port and port bit objects should be bold

            Move: Francoise - approve the proposals for Mantis 1942 and 1367
          Second: Shalom
	    passed unanimously


 1570	SV-CC Clarify legality of 'integer' and 'time' as DPI parameter types
    
      Shalom - there is a section number problem
      <we were running out of time and did not have time to do more with this>


At least one Champion had an issue with each of the following 3 mantis items. 
We pulled this set out of the list of svbc items that we then passed as a group.
We did this since we were almost out of time and wanted to pass as many items
as possible before ending the conference call. 

 1278	SV-BC	"initial" and "always" "constructs"
 1939	SV-BC	Hexadecimal escapes in strings (Table 5-1)
 2056	SV-BC	12.7.1: Description of for-loop step assignment is not precise


The following set of Mantis items were approved as a group. 

 1750	SV-BC   %p printing should also work with non-aggregates 
		(based on mantis 331)
 2092	SV-BC	Clarify that wires may be fixed-sized unpacked arrays
 2029	SV-BC	BNF does not allow 'string' as casting_type
 2024	SV-BC	Table 25-18 column headings
 2006	SV-BC	Clarify empty argument characteristics
 1993	SV-BC	29.4.4.4: bad specify block ifnone example
 1989	SV-BC	Consistant use of string terminology
 1988	SV-BC	13.4.2: contradiction
 1949	SV-BC	19.6.1 $typename example error?
 1940	SV-BC	6.8: Inaccurate text
 1937	SV-BC	Title of 22.2.2.3 misleading
 1846	SV-BC   D3 21.13: add 1800-2008 to `begin_keywords
 1792	SV-BC	Aggregate array not defined
 1767	SV-BC	Missing 's' in BNF example of 1.4
 1645	SV-BC	behavior of keywords directives at end of compilation unit
 1610	SV-BC	Scoping of unnamed sequential blocks
 1588	SV-BC	Add predefined macros for file and line number
 1554	SV-BC	Array query functions as constant primaries (22.6)
 1489	SV-BC	19.4: "top-level instance" vs. "top-level module"
 1487	SV-BC	wild/wildcard inconsistency
 1473	SV-BC	Is 4.2step legal?
 1468	SV-BC	always_latch has same restrictions as always_comb (11.3)
 1464	SV-BC	19.7 (22.5 in D4): misleading (and illegal) example
 1417	SV-BC	1.2 mentions queues twice
 1354	SV-BC	endxxx : identifier description missing from text
 1348	SV-BC	10.8,9 (9.3.4-5 in D3a) don't say that statement labels 
		create named blocks
 1294	SV-BC	10.4: conditional_statement syntax (BNF)
 1265	SV-BC	8.13.1: unclear sentence - what is "more arrays" ?
 1228	SV-BC	8.11 does not define expansion of longest static prefix
 1035	SV-BC	Syntax 8-1 and Table 8-1 misclassifications
 933	SV-BC	Width casting
 909	SV-BC	All footnotes in Syntax boxes should be hyperlinks
 907	SV-BC	Default parameter assignment should be optional
 699	SV-BC	Overloading -- based on equivalence or matching?
 1710	V-1364	15.3.5: $period error
 1450	V-1364	3.8: attribute syntax clarification
 1425	V-1364	Type/size propagation does not stop at parens (5.5.2, V-2005)
 1302	V-1364	Selects use self-determined evaluation
 1175	V-1364	Add field widths to print formats
 1134	V-1364	Add localparam to ANSI-type param list

            Move: Brad - approve the proposals and resolutions for Mantis 
			 items 1750 through 1134 in the above list
          Second: Shalom
         Abstain: Stu - didn't get through all of them for the Editor review
	    passed with one abstain


3. Next Meeting:
   ------------
   Nov 28 - 8-10 PST
Received on Tue Nov 13 17:37:53 2007

This archive was generated by hypermail 2.1.8 : Tue Nov 13 2007 - 17:37:55 PST