System/Verilog C/C++ Committee: [sv-cc] Results of Champions ema

From: Neil Korpusik <neil.korpusik@oracle.com>
Date: Tue Oct 12 2010 - 16:40:38 PDT

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

To all Technical Committees,

Enclosed are the results of the Champion's email vote that concluded on Sept. 29th.
The mantis database has been updated to reflect this.

Neil

2571 SV-AC confusing assertion clock inference rule
There is a proposal - a simple one line reword
Approved by email ballot 2010-08-30: 11y/0n/1a.
```
   Was approved unanimously by the champions.
```

2205 SV-AC $asseroff, $assertkill and $asserton description is ambiguous
There is a proposal - added cross references and changed "assertion statements" to "assertions".
See the discussion in the notes.
Existing text addresses most of Stu's concerns.
Approved by voice vote 2010-08-31: 8y/0n/0a.

   Brad      - opposed (same reasons as Shalom)
   Shalom    - opposed
     Mantis 2205 and 2476 both make changes to Section 20.13.
     2476 should take precedence and the change to 20.13 in 2205 should be removed.
   Dave Rich - approve (with the following requirements)
     SV-AC should vote to rescind 2205 before approving 2476. 
     2205 should stand until 2476 comes to the champions.
   Shalom response to Dave 
     No, because 2205 contains additional changes not affected by 2476.

2080 SV-EC "::" is ambiguous in parameterized classes
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Brad - opposed
   Mantis should be updated with "duplicate" link to 1857. If Mantis updated, then I approve.
```
2022 SV-EC index value width extension for associative arrays
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Was approved unanimously by the champions.
```
2018 SV-EC Is a queue an array or not?
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Was approved unanimously by the champions.
```
1740 SV-EC Item 1457 did not correct section 10.5.3
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Was approved unanimously by the champions.
```
1672 SV-EC 18.9: "type" should be "option"
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Brad - opposed
   Update Mantis with "duplicate" link to 1279. If Mantis updated, then I approve.
```
0802 SV-EC Assigning too many elements to a queue
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.
```
   Brad - opposed
   Update Mantis with "duplicate" link to 802. If Mantis updated, then I approve.
```

0251 SV-EC multiple user defined bins for cross
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

   Shalom - opposed (originally abstain) - questioned how 2506 addressed 251
   Brad   - opposed (referenced Shalom's feedback)

   Dave (addressing Shalom's comment)
      251 is more of a dissatisfaction of the current semantics of crosses 
      without a suggested direction. If nothing else, mantis 2506 has a loose 
      proposal that should alleviate the concerns raised by 251.

   Shalom-
   The description of 251 says,

   "For cross coverage, the syntax in table 20-4 does not allow multiple bins
    to be created for user defined bins, i.e. using the [] notation with the
    binsof construct. So the only way to track the crosses separately is
    through automatically created bins. Was there any specific reason for not
    allowing that. The syntax should be enhanced to allow multiple bins being
    created for user defined bins. The example in Section 20.5.1 should also
    be suitably enhanced."

    That looks to me exactly like a "suggested direction".

   John Havlicek
    Hmm ... I can't make any specific sense of what is being suggested in 251.

    One of the restrictions in defining cross bins is that they are limited
    to tuples of bins from the component coverpoints being crossed.  One
    does not have full flexibility at the level of the cross to ignore or
    redefine the bin structure that comes from the coverpoints.

    The proposal for 2506 respects this approach and extends it.

    I can't really tell what the reporter of 251 wants.  Nevertheless, I
    agree with Dave that the general area of concern is covered or, at
    least, overlaps significantly with 2506, and I would hope that the
    reporter of 251 would participate in resolution of 2506 and/or 2953.

   Shalom 
    But that does not make 251 a duplicate of 2506.

    SV-EC can decide that it does not want to implement the request in 251 and
    close the issue on that basis, but not as a duplicate of 2506.

    I change my vote from "Abstain" to "Oppose".

2451 SV-EC Omitting body defaults
There is a proposal - several clarifying statements were added.
Approved unanimously in sv-ec meeting August 30 2010. Proposal2451v2b.pdf
```
   Was approved unanimously by the champions.
```
1349 SV-EC fork/join_none: what if parent thread terminates without blocking statement?
There is a proposal - a simple clarifying change to one sentence.
Approved unanimously in sv-ec meeting August 30 2010.
```
   Was approved unanimously by the champions.
```

2794 SV-EC Clarify queue methods return status
There is a 2-page proposal - several clarifying statements added.
Approved unanimously in sv-ec meeting August 30 2010. proposal-2794-2a.pdf

   Shalom - opposed
   Dave   - opposed (same reasons as Shalom)
   Brad   - opposed (also agreed with Shalom's feedback)
      The multiple "If this method is called on an empty queue" sentences are weird.

   Shalom - 
   The proposal contains:
 
   "ADD to the end of 7.10.2.4:
 
   If this method is called on an empty queue, its return value shall be the
   default initial value for the type of queue element (as described in
   Table 7-1).

   If this method is called on an empty queue, then the method call shall have
   no effect on the queue and may cause a warning to be issued.

   ADD to the end of 7.10.2.5:

   If this method is called on an empty queue, its return value shall be the
   default initial value for the type of queue element (as described in
   Table 7-1).

   If this method is called on an empty queue, then the method call shall have
   no effect on the queue and may cause a warning to be issued."

   As noted in 0001067:

   1. Table 7-1 does not specify values for real and chandle types.
   2. Table 7-1 is labeled "Value read from a nonexistent associative array
      entry", not "Default initial values".

   "default initial value" is not even correct for event types. The default
    initial value for an event is a "new event", as specified in Table 6-7.

   (By the way, it looks awkward to begin two consecutive sentences with the
    same phrase, "If this method is called on an empty queue".)

2956 SV-EC clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5)
There is a one page proposal - fixed a typedef and added missing methods from "class process" in 9.7.
Approved unanimously in sv-ec meeting August 30 2010. NOTE to the editor: Add cross references to the functions listed in this table.
```
   Was approved unanimously by the champions.
```
2950 SV-EC virtual method prototype matching
Added a one-word clarification to one sentence and added a second sentence.
Approved unanimously in sv-ec meeting August 30 2010. 2950.pdf proposal.
```
   Was approved unanimously by the champions.
```
2949 SV-EC LRM is silent about the semantics of referencing a clocking block output
What was one sentence in the LRM is now expanded to further clarify clockvars (inout, input, output).
Approved unanimously, sv-ec meeting August 16 2010. proposal 2949-1a.pdf
```
   Brad - opposed
   I infer from this change that writing to an inout clockvar has no effect on
   a subsequent read from it. If that's correct, please consider adding a note
   about it.
```
2734 SV-BC Mechanism to initialize an array to a constant value
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because the feature is already there.
```
   Was approved unanimously by the champions.
```
2574 SV-BC class_scope parameter identifier missing in ps_parameter_identifier
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because it's already fixed.
```
   Was approved unanimously by the champions.
```
2533 SV-BC Equivalent to what?
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because made irrelevant by 2380.
```
   Was approved unanimously by the champions.
```
2525 SV-BC Allow hierarchical references in $unit scope
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue as resolved by 2663.
```
   Was approved unanimously by the champions.
```
1685 SV-BC 6.3.2 should be clarified as allowing string literals
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue because already fixed.
```
   Was approved unanimously by the champions.
```
1223 SV-BC red hyperlinked BNF?
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue because already fixed.
```
   Was approved unanimously by the champions.
```
1222 SV-BC clarify explicitly whether a module may instantiate itself
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because no change required.
```
   Was approved unanimously by the champions.
```
1204 SV-BC Add lists of figures, tables, syntaxes
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because already fixed.
```
   Was approved unanimously by the champions.
```
1162 SV-BC A.1.4: list_of_port_declarations BNF rule
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue because it is already fixed.
```
   Was approved unanimously by the champions.
```
1029 SV-BC some 1364 examples use 1800 keywords
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because it is already fixed.
```
   Was approved unanimously by the champions.
```
0991 SV-BC 2, 12: improving syntax boxes
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue, because it was already fixed.
```
   Was approved unanimously by the champions.
```
0968 SV-BC The 'list package' is not a package (D.1)
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue. List package has already been removed.
```
   Was approved unanimously by the champions.
```
0154 SV-BC Jeita 29: Dual Data Rate needed in always_ff
I propose to close this issue as resolved by 0002396. [Shalom]
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue.
```
   Was approved unanimously by the champions.
```
0931 SV-BC BNF should be hyperlinked
Propose to close, same as 0001223. [Shalom]
SV-BC unanimously resolved by email vote ending Aug. 2, 2010 to close this issue.
```
   Was approved unanimously by the champions.
```
1678 SV-AC Clarify that rewriting algorithm doesn't replace name resolution.
no change required
Passed by voice vote 2010-08-24: 10y/0n/0a.
```
   Was approved unanimously by the champions.
```
2494 SV-AC 37.44 Assertion diagram missing restrict
VPI syntax diagrams -- added "restrict" to 37.45 and 39.3.2
Passed by voice vote 2010-08-24: 10y/0n/0a.
```
   Was approved unanimously by the champions.
```

1763 SV-AC The LRM does not define whether assertion control tasks affect sequence methods and events
no change required
Passed by voice vote 2010-08-24: 9y/0n/0a.

   Brad - opposed
      Ed's issue begins, "There is no description of whether the system tasks 
      $asserton/off/kill affect sequences that are used with the methods ended, 
      matched, triggered and as events in @sequence."  
      So is the resolution that there is indeed such a description, or that it 
      doesn't matter that there's no such description?

2412 SV-AC Allow clock inference in sequences
Assertions clock related changes (5 page writeup)
Passed by voice vote 2010-08-17: 11y/0n/0a.

Brad   - opposed
   The rules from 16.9.3 are copy-pasted into 16.14.6, but should be in one 
   section only, and cross-reference used. The "Note that..." should be an 
   actual Note. And should "is clocked as if" in a couple places be "shall be 
   clocked as if", or are those notes, too? Likewise, "same rule applies" or 
   "same Rule shall apply"? I'm having trouble determining from the new text 
   whether it's making rules, or just restating rules made elsewhere, which 
   latter seems likely given the preceding copy-paste.

Shalom - abstain (I did not review this thoroughly enough)
Friendly amendments:

   On page 2, change "If method triggered is used in a disable condition" to 
                 "If the method triggered is used in a disable condition".

   The added text to 16.14.6 duplicates the rules specified in 16.9.3. 
   Duplicated text tends to accumulate inconsistencies. Is it possible to write instead, 
   "The same rules are used to infer the clocking event as specified in 16.9.3 for sampled value functions."? 
   Also, 16.9.3 says, "the clocking event shall be explicitly specified as an 
   argument or inferred from the code where the function is called", whereas 
   the proposed text for 16.14.6 uses the word "context" instead of "code". 
   I don't think it matters, but it is better to be consistent.

2754 SV-AC P1800-2009 : Can clock change in conditional branch of 'if' operator
no change required
Accepted by voice vote 2010-08-17: 11y/0n/0a.
```
   Was approved unanimously by the champions.
```
2095 SV-AC Clarify meaning of distribution as condition for "disable iff"
no change required
Passed by voice vote 2010-08-17: 11y/0n/0a.
The LRM explicitly defines the behavior and semantics of distributions.
This behavior is not always intuitive and may be revised in the future.
However, given the existing definition, the interpretation is unambiguous.
```
   Was approved unanimously by the champions.
```
2485 SV-AC terminology related to immediate and deferred assertions
A couple of minor wording changes.
Passed by email ballot 2010-08-09: 8y/0n/1a.
```
Dave Rich - approve (with friendly ammendment)
Change "can" to "may" in last sentence
```

2938 SV-AC Surprising (to some users) interaction between deferred assertions & short-circuiting
A new example added to the end of 16.4.2 Deferred assertion flush points (a half-page proposal).
Passed by email ballot 2010-08-16: 11y/n/0a.

Brad      - opposed 
    '#0' shouldn't be bold. The 'always_comb' procedure is missing an 'end' or 
    an ellipsis. 
    More importantly, I think the final workaround sentence is 
    counter-productive, unless we intend to deprecate '||'.

Dave Rich - opposed (same reasons as Shalom)
Shalom    - opposed
   There are some syntax problems with the example.
   Some statements are missing semicolons at the ends of the line.
   The function declaration is missing a declaration of the argument v.
   The function should have an endfunction, and the always_comb "begin" should have an "end".

2558 SV-AC Restriction inside checker construct
Removed one sentence and added a cross-reference in its place.
Passed by email ballot 2010-08-09: 9y/0n/0a.
The _1 version addresses the friendly amendments sent during the ballot.
```
   Was approved unanimously by the champions.
```
2732 SV-AC Clarify timing diagram in Figure 16-4. Future value change
Expanded explanation of figure 16-4. A one paragraph proposal.
Approved by voice vote 2010-08-03: 12y/0n/0a.
```
   Was approved unanimously by the champions.
```

2353 SV-AC 'classes' missing from description
A couple of minor changes and added a couple of cross references.
Approved by voice vote 2010-08-03: 12y/0n/0a.

Shalom - approved (with friendly ammendment)

   In the change to 16.6.2, it should be explicitly noted (in red cross-out) 
   that the word "or" before "clocking blocks" is being deleted.

Received on Tue Oct 12 16:42:59 2010

This archive was generated by hypermail 2.1.8 : Tue Oct 12 2010 - 16:43:05 PDT

[sv-cc] Results of Champions email vote which closed on Sept 29th