P1800 Champions,

 

We are conducting an email vote for mantis items that are in the resolved

state. There are 15 mantis items ready for the Champions. I have put 10

of them into this email vote.

 

Mark your votes as being either Approve or Oppose. If you Oppose, please

specify a reason.  You have until October 17, midnight (PST) to cast your

votes.

 

Neil

I think that our procedures specify that in the Mantis item page, old proposal versions should be deleted.

  1. 3564 SV-AC Sec 9.2.2.2.1 needs to clarify whether variables read in an assertion contribute to the sensitivity of an always_comb
    There is a proposal (1 page)
    Approved by voice vote 2011-09-27: 12y/0n/0a.

    Approve _x_ Oppose __

Friendly amendment: specify that the new paragraph comes after the new paragraphs added in Mantis 2081.

 

  1. 3145 SV-AC Need to clearly define "maximal property"
    There is a proposal (1 page)
    Approved by voice vote 2011-09-27: 12y/0n/0a.

    Approve _x_ Oppose __

 

  1. 3046 SV-EC Dotted names within inlined constraints
    There is a proposal (1 page)
    Approved in sv-ec meeting 8/15/2011:proposal 3046_inline_dotted_names_rev3.pdf 1 No vote, 0 abstain.

    Approve _x_ Oppose __

 

  1. 1091 SV-EC Jeda verification enhancements
    No change required
    Unanimously voted in sv-ec email vote 9/26/2011 to be CLOSED as already implemented in SystemVerilog.

    Approve _x_ Oppose __

 

  1. 3001 SV-EC Proper Polymorphic behavior of instantiation
    There is a proposal (2 pages)
    unanimously approved in email vote 9/26/2011

    Approve _x_ Oppose __

Approval conditional on fixing the following editorial problems:

The proposal says that the concept of a superclass type is described in 8.12.  Superclass types are actually described in 8.14.

In the first paragraph, in "adds class_scope immediately before the new keyword", "new" should be in bold code font.

Twice, "clause" is used where it should be "subclause". Best would be to delete the word entirely.

In the first example, there is a comment, "variable c of superclass type now references". I think it would be better to change "superclass type" to "superclass type C".

In the last example, some keywords need to be in bold ("type", "int", "byte").

 

  1. 1523 SV-BC How is ?: defined for non-integral data types?
    There is a proposal (2 pages)
    On September 26, 2011 the SV-BC unanimously approved the revised proposal, 1523_rev5_shalom.pdf.

    Approve _x_ Oppose __

 

  1. 2987 SV-EC Soft Constraints
    There is a proposal (5 pages)
    Approved in sv-ec meeting, 9/26/2011, the proposal Mantis2987_SoftConstraintsProposal_v5.pdf. 8 yes, 4 abstain, 1 no

    Approve __ Oppose _x_

Editorial problems:

The proposal is not quite in standard proposal format. Normally the new text should be in blue, and the BNF changes at the end of the proposal would be in CHANGE FROM – TO format, with red crossouts and blue additions.

In 18.15.13, "a constraint expression defined as soft", the word "soft" should be in italics.

"constraint-solver" should not have a hyphen.

"or use a new class" should be "or by using a new class".

"In contrast, the soft constraint automatically overrides the default value" should be rewritten. The soft constraint does not override, it is overridden.

In 18.15.13.1, in the second dashed item, "The priority depends on the prototype declaration and not on the out-of-body declarations," the second "declarations" should be singular, to be consistent with the first.

The following sentence, "Constraint expressions in out-of-body constraint blocks whose prototypes appear later in the class have higher priority," is confusing. It also seems redundant, so I think it is best to just delete it.

In the following dashed item, "Constraints in contained objects (rand class handles) have lower priority than all constraints in the container object (class or struct)," the words "class" and "struct" should be in bold code font.

On the next page, "super-classes" should not have a hyphen.

In the following example, some keywords are not bolded: int, endclass, new, extends. Also in other examples, both preceding and following.

The horizontal line under each soft constraint, with a soft constraint "name" underneath, look like division symbols, and are confusing. Can they be changed to something else, such as curly brackets?

"And it [the constraint solver] must satisfy the following properties:" – I think "must" should be "shall".

In 18.5.13.2, references to constraint names in the text should be in code font.

"The constraint A2 instructs the solver to discard all soft constraints of lower priority on random variable x. resulting in constraint A1 to be discarded." – The period following "x" should be a comma. "to be" should be "being" (or change "resulting in" to "causing").

Need to add "soft" to Annex B.

 

  1. 3724 SV-DC Allow generic interconnect for "typeless" connections
    There is a proposal (10 pages)
    Passed in e-mail vote that ended on 2011-09-30. 9y/0n/0a

    Approve __ Oppose __

Abstain. Not enough time.

 

  1. 2476 SV-AC Need clarification about system functions $onehot, etc
    There is a proposal (7 pages)
    Amended proposal passed by voice vote 2011-08-30: 10y/0n/0a.
    This was part of the Champion's email vote which ended on Sept 20, 2011. At that time, some of the Champions needed more time to review it.

    Approve _x_ Oppose __

Approval conditional on fixing the following:

Add note to editor in 16.9.3 that "expression" changes to "expression1". Otherwise, he may not see the difference.

In the title of 20.9, "20.9 Bit Vector System Functions", only the first word, "Bit", should be capitalized.

Same for 20.14, "Sampled Value System Functions", and its addition in 20.1.

In Syntax 20-9, "list_of_control_bits ::== control_bit {, control_bit}", the symbol should have only one equals sign after the double colon.

"This function returns an int equal to the number of bits in expression whose values match one of the control_bit entries." – "int" should be bold.

Later, "The return type of $countones is int. The return type of $onehot, $onehot0, and $isunknown is bit." – "int" and "bit" should be bold code font.

 

  1. 1356 SV-EC Multiple inheritance
    There is a proposal (11 pages)
    Proposal 1356_Interface_Classes_rev12.pdf was uanimously approved in sv-ec 9/12/2011 meeting.
    This was part of the Champion's email vote which ended on Oct 2nd, 2011. At that time, some of

    Approve __ Oppose _x_

I did not have enough time to review this adequately (holiday season here in Israel). I only got in detail through a little less than three pages. However, I found a large number of editorial issues, mostly on the first part of the proposal, and so I am voting against approval:

The description of Clause 8 in subclause 1.8 should be modified to mention interface classes.

In 8.1, "Interface Classes" should be "Interface classes" (small "c")

All subclause titles should have only the first word capitalized.

In the addition to the class_declaration syntax in 8.3 and in 8.25.1, the curly brackets around interface_class_type should not be bold.

The first two sentences of 8.25 are confusing and should be reworded: "A set of classes may be created that can be viewed as all having a common set of behaviors. This is characterized as an interface class." As worded, it sounds like "this" ( = interface class) is referring to "a set of class" whereas it was intended to refer, to the best of my understanding, to "a common set of behaviors", which is itself an inadequate description of an interface class. I think it would be clearer if, for example, the second sentence were reworded as "Such a common set of behaviors may be created using interface classes."

"non interface class" should have a hyphen after "non" (in two places).

I would also reorder the sentences in that first paragraph of 8.25. Without touching the first two sentences, which need to be reworded, as stated above, I would reorder the sentences like this:

"A set of classes may be created that can be viewed as all having a common set of behaviors. This is characterized as an interface class. An interface class makes it unnecessary for related classes to share a common abstract superclass or for that superclass to contain all method definitions needed by all subclasses. This interface implementation allows classes to support common behaviors without sharing any implementation. A non-interface class can be declared as implementing one or more interface classes. This creates a requirement for the non-interface class to provide implementations for a set of methods which shall satisfy the requirements of a virtual method override (see 8.19)."

At the bottom of page 2, in the example, in "int DEPTH = 1", "int" should be bold. Same at top of page 3. Also elsewhere.

At the bottom of page 3, there is a cross-reference "(See 8.25.5 Partial implementations)". "See" should not be capitalized. "8.25.5" should be "8.25.7". "Partial implementations" should not be plural. In general, it is not required in a cross-reference to give the name of the subclause, though it is allowed.

In the second paragraph of 8.25.2: "An interface class may extend, but not implement, one or more interface classes; meaning that the interface subclass inherits multiple interface class' members and may add additional member types, pure virtual method prototypes and parameters," the semicolon should be a comma or the sentence should be reworded. It is not clear whether "multiple" refers to "multiple interface classes" or "multiple members". I also don't think the apostrophe after "interface class" is correct as is.

At the top of page 4, "The following example a class is both extending a base class and implementing two interface classes:" is missing a word. Maybe "In the following example, …".

In the first example in 8.25.3, the "interface class" header line is missing a semicolon at the end.

In 8.25.4, the following statement needs a semicolon at the end: "virtual class Fifo #(type T = PutImp) implements T".

Also in 8.25.4, the endclass statements refer to the wrong class_identifiers.

The line, "typedef class IntfD;", according to the change in 6.18, apparently needs to be "typedef interface class".

In the example in 8.25.5, "class" and "endclass" need to be bold.

The proposal extends "class handles" to interface class handles" in several places in the LRM. That appears to be missing from 11.4.11, 10.10, 11.4.5, and 11.4.6.