System/Verilog Basic Committee: [sv-bc] Results of the Champions

From: Neil Korpusik <neil.korpusik@oracle.com>
Date: Wed Jan 12 2011 - 18:03:29 PST

To all Technical Committees,

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

Neil

-- 
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 Dec. 13th. The mantis database has been updated to reflect this. Neil

2839 Errata SV-AC Contradictory statement of increment/decrement operators usage.
There is a proposal. A one line change.
Was up for a vote in the Champions (10/3/10).
The Champion's feedback was addressed.
```
   Brad - opposed
     Not clear whether "This restriction prevents side effects." is being deleted.
```
3168 Errata SV-AC expression1 is not an argument to $past
Duplicate of 3008
```
 
   Was approved unanimously by the champions. 
```
2252 Errata SV-AC Several symbols in Annex F are in green
No change required
This mantis item mentions a problem where some text is in green.
The green text showed up in 1800-2009 draft 5.
The problem was corrected in draft 6.
```
 
   Was approved unanimously by the champions. 
```
2948 Errata SV-BC Wrong example in protected envelope
There is a proposal. "data_block" was shown in the wrong location.
On November 8, 2010 the SV-BC unanimously approved the attached proposal.
```
 
   Was approved unanimously by the champions. 
```

1933 Errata SV-AC 16.13.6 reference to triggered method can be improved
No change required.
The champions feedback has been addressed.

 
   Francoise - opposed
     The reference to section 9.4.3 should be changed to 9.4.4

   Shalom    - opposed
     Agrees with Francoise, the reference should be changed to 9.4.4.
	9.4.3 describes 'wait'.
	9.4.4 describes the use of 'wait' on the 'triggered' method of a sequence.

   Note: The changes mentioned by Francoise and Shalom will be treated as 
	 friendly ammendments.

2107 Errata SV-BC Clarifications needed for scope operator
No change required
On November 8, 2010 the SV-BC unanimously approved resolution of this issue as addressed in 1800-2009.
```
 
   Was approved unanimously by the champions. 
```
2206 Enhancement SV-AC Random simulation of non-deterministic free variables in checkers
No change required.
Was already reviewed by the Champions (was miscategorized as "duplicate" at that time).
Passed by voice vote 2010-11-09: 13y/0n/0a.
```
 
   Was approved unanimously by the champions. 
```
3231 Errata SV-BC Functions can contain the fork statement
There is a proposal. A small one-line clarification.
On October 25, 2010 the SV-BC unanimously approved the attached proposal.
```
 
   Was approved unanimously by the champions. 
```
3210 Errata SV-BC Declarations of port_identifiers in explicit non-ANSI port declarations
No change required.
On October 25, 2010 the SV-BC unanimously agreed that this is not a bug and no change is required.
```
 
   Was approved unanimously by the champions. 
```
3137 Errata SV-BC wrong reference in "Port connection rules for variables"
No change required.
On October 25, 2010 the SV-BC unanimously agreed that this is not a mistake and no change is required.
```
 
   Was approved unanimously by the champions. 
```
3080 Clarification SV-BC When reporting an escaped identifier, should .name() add a leading backslash?
Duplicate of 2678
On October 25, 2010 the SV-BC unanimously approved as a duplicate of 2678.
```
 
   Was approved unanimously by the champions. 
```
1133 Enhancement SV-BC allow reverse part-select [lsb:msb]
No change required.
On October 25, 2010 the SV-BC unanimously approved to resolve this issue with no change as it is addressed by the streaming operator.
```
 
   Was approved unanimously by the champions. 
```
3225 Errata SV-BC Footnote 18 is wrong, too restrictive
There is a proposal. Clarifies one paragraph in Annex A (footnote 18).
On October 25, 2010 the SV-BC unanimously approved the attached proposal.
```
 
   Was approved unanimously by the champions. 
```
1170 Clarification SV-BC nonport declarations for identifiers mentioned in list_of_port_declarations
There is a proposal. A short clarification on port declarations.
On October 25, 2010 the SV-BC unanimously approved the attached proposal.
```
 
   Was approved unanimously by the champions. 
```
1627 Errata SV-AC 17.16: clarify that expect statement not allowed in functions
There is a proposal. A short clarification on 'expect'.
Passed by email ballot 2010-07-12: 9y/0n/0a.
On October 25, 2010 the SV-BC unanimously approved the attached proposal.
```
 
   Was approved unanimously by the champions. 
```

2412 Enhancement SV-AC Allow clock inference in sequences
There is a proposal. This is a fairly long proposal.
This was previously rejected by the Champions.
The Champions feedback has been incorporated.
Approved by email ballot 2010-10-01: 9y/0n/0a.

 
   Shalom - opposed

The proposal adds the following paragraph in 16.14.6:

   "The sequence on which a method is applied should either be clocked or it 
    may infer the clock from the context where it is used. The same rules are 
    used to infer the clocking event as specified in 16.9.3 for sampled value 
    functions."

This uses the words "should" and "may".

   "should" is a recommendation.
   "may" indicates optional behavior.

I don't think that was the intent.


Additional, minor editorial points:

Later in 16.14.6, it says,

   "If a sequence with a method is passed as an actual argument to a checker 
    instantiation, it is substituted in place of the corresponding formal 
    argument. Such a sequence shall be clocked as if it was instantiated 
    inside the checker.

If a sequence with a method is passed as an actual argument to a module 
instantiation, it shall be clocked as if it is instantiated at the place of 
module instantiation. The same rule shall apply if a sequence with a method is 
passed as an actual argument to an interface, program, function or task 
instantiation."

   "as if it was" and "as if it is" should be "as if it were".

Also, modules, interfaces, and programs do not have "actual arguments". 
They have "port connections".

   Dave - opposed
     I believe the intent of the sentence Shalom pointed out should read
     "The sequence on which a method is applied shall either be clocked or 
      infer the clock from the context where it is used. The same rules are 
      used to infer the clocking event as specified in 16.9.3 for sampled 
      value functions."

3135 Clarification SV-AC Verbal explanation of nexttime and always is misleading for multiple clocks.
There is a proposal. Two new paragraphs are being added.
Approved by email ballot 2010-10-01: 9y/0n/0a.
```
 
   Brad - opposed
     The introductory phrase of the 2nd paragraph, "Note that as in nexttime 
     properties", is weird. The editor can fix that up though.
```
2904 Clarification SV-AC Clarify when disable iff condition must occur relative to starting and ending of an attempt
There is a proposal. A one-line clarification.
Approved by email ballot 2010-10-01: 9y/0n/0a.
```
 
   Was approved unanimously by the champions. 
```

2938 Clarification SV-AC Surprising (to some users) interaction between deferred assertions & short-circuiting
There is a proposal. Adding an additional example and explanation.
This was previously rejected by the Champions.
The proposal was updated to address Champions feedback, and the updated proposal was approved by the SV-AC by voice vote on 10/26/2010: 6y, 0n 0a

 
   Brad - opposed
     I still worry about the LRM suggesting workarounds, "Note that if the 
     bitwise | operator, which does not allow short-circuiting, were used 
     instead of || in the assignment to a, then f would be evaluated each time 
     the assignment was reached." But it could be argued that the proposed 
     resolution for 696 is a grand workaround. So, if it helps users get their 
     job done, why not?

2205 Clarification SV-AC $asseroff, $assertkill and $asserton description is ambiguous
There is a proposal. It is now very small.
The proposal was previously rejected by the Champions.
The mantis item was updated to address Champions feedback, and the new proposal was approved by the SV-AC by voice vote on 12/26/2010: 7y, 0n, 0a
```
 
   Was approved unanimously by the champions. 
```
1763 Clarification SV-AC The LRM does not define whether assertion control tasks affect sequence methods and events
No change required.
Was previously rejected by the Champions. The submitter has added a note as to why no change is required.
The SV-AC voted on 2010-10-19 to again resolve this issue as "no change required": Voice vote, 7y/0n/0a
```
 
   Was approved unanimously by the champions. 
```
2034 Errata SV-CC sv_vpi_user.h lacks vpiChandleVar and vpiChandleTypespec
No change required.
On Jun-09-2010, the SV-CC declared this as 'No change required'. (unanimous)
```
 
   Was approved unanimously by the champions. 
```
1581 Errata SV-CC Immediate assertion VPI diagram needs a special section
No change required.
On Jun-09-2010, the SV-CC declared this as 'No change required'. (unanimous)
```
 
   Was approved unanimously by the champions. 
```
1652 Errata SV-CC Which VPI class defn does a data member class var refer to?
Duplicate
On Jun-09-2010, the SV-CC declared this a duplicate of Item 2094. (unanimous)
```
 
   Was approved unanimously by the champions. 
```
744 Clarification SV-CC Does vpiMethods iteration include built-in functions and tasks?
Duplicate
On Jun-09-2010, the SV-CC declared this a duplicate of Item 2094. (unanimous)
```
 
   Was approved unanimously by the champions. 
```
3116 Errata SV-CC No method/transition path to get to typespecs of named events or named event arrays
There is a proposal. Adding a bubble to two diagrams.
On Sep-15-2010, the SV-CC PASSED the proposed solution (unanimous)
```
 
   Was approved unanimously by the champions. 
```
3188 Enhancement SV-CC No way to distinguish join, join_none, and join_any for fork-join blocks in VPI
There is a proposal. Small changes in a few places.
On Sep-15-2010, the SV-CC PASSED the proposed solution (unanimous)
```
 
   Was approved unanimously by the champions. 
```
3193 Errata SV-CC Need defined value for built-in class type process-class for vpiClassType property.
There is a proposal. Adds one #define.
On Sep-15-2010, the SV-CC PASSED the proposed solution (by consent)
```
 
   Was approved unanimously by the champions. 
```

1477 Errata SV-CC virtual interfaces information model
There is a proposal. Lots of changes (20 pages).
On Sep-15-2010, the SV-CC PASSED the proposed solution (Bassam abstained - was still concerned about backward compatibility issues).

 
   Brad - opposed
     I would like an explanation of why the change is valuable enough to break 
     backward compatibility. I'm not doubting that it is valuable enough, I'd 
     just like to understand, especially because P1800 will presumably also 
     want an explanation, and we should have one ready to go.

   Shalom - opposed

      I did not review 1477 completely, but in what I did review, I have some 
      problems and need some clarifications before I can approve it:

      Minor editorial: in the changes to 37.15 on page 3, the paragraphs 
      beginning "A ref obj may be obtained ..." should be labeled as detail "2)".

      Minor editorial: in the changes to 37.15 on page 4, the detail paragraphs 
      labeled 4 and 5, should be 5 and 6.

      Question: This is not part of the proposal, but in the typespec diagram 
      in 37.23, "class typespec" is not bold. Is that correct?

      Minor editorial: In the code examples in the new sections 37.27 and 37.28, 
      on pages 8-10, a large number of keywords need to be made bold.

      Question: In the changes to 37.28 and 37.29, "ref obj" was replaced by 
      "virtual interface var". However, in 37.27 (page 11), "ref obj" was 
      simply deleted. Is that correct?

      Probable error: In 37.28 in the LRM, "vpiInterfaceDecl" appears in detail 2. 
      I speculate that it should be deleted.

      The change to "#define vpiVirtual" on page 20 adds the comment "Deprecated". 
      However, vpiVirtual is used also in the diagrams for classes (37.27), 
      methods (37.37), and constraints (37.30). So is it correct to label it 
      "Deprecated"?

1434 Errata SV-CC Which kind of fork join is not available in VPI (27.9)
Duplicate of 3188.
On Sep-15-2010, the SV-CC voted to declare this a duplicate of Item 3188. (unanimous)
```
 
   Was approved unanimously by the champions. 
```
3134 Errata SV-AC sequence and property range parameters are erroneously defined
There is a proposal. Adding a couple of new paragraphs.
Approved by email vote 2010-10-04: 10y/0n/0a.
```
 
   Was approved unanimously by the champions. 
```

Received on Wed Jan 12 18:05:55 2011

This archive was generated by hypermail 2.1.8 : Wed Jan 12 2011 - 18:06:19 PST

[sv-bc] Results of the Champions email vote ending on December 13th, 2010