Re: [sv-champions] Email vote ending July 1, 2011

P1800 Champions,

We are conducting an email vote for mantis items that are in the resolved state. There are 8 mantis items ready for the Champions. I have put all 8 into this email vote. Three of these mantis items are for for no changes at all. Four of them have a significant amount of changes.
Mark your votes as being either Approve or Oppose. If you Oppose, please specify a reason. You have until July 1, 6pm (PST) to cast your votes.
Neil
1.

3398<http://www.eda-twiki.org/svdb/view.php?id=3398> SV-DC User defined nets and resolution functions
There is a proposal (6 pages of completely new text)
Unanimous voice vote in SV-DC committee meeting on 2011-06-15.

Approve __ Oppose _x_
"A.9.3 Identifiers" should include "net_type_identifier ::= identifier".

In "A.2.1.3 Type declarations", "data_declaration" should include "net_type_declaration".

The BNF definition of net_type_declaration in 6.6.7 should have a syntax "box".
"datatype" should be "data type" everywhere in the text. The code comments use a mixture of 'datatype' and 'data_type'. They should be all 'data type' or all 'data_type'.
"user defined" should be "user-defined" everywhere.
6.6.7 mentions a "composite value", but this term is not defined and will not be clear to many readers.
In 6.6.7, "Re-Active" should be "Reactive".
6.6.7 says, "A user defined resolution function for an atomic net with a data type T shall be an automatic function with a return type of T and a single input argument whose type is a dynamic array of elements of type T." Then, two paragraphs later, it says, "A resolution function shall be automatic (or preserve no state information) and have no side effects." The descriptions of and restrictions on resolution functions should be combined and redundancies should be removed.
Is it allowed to re-define a built-in net type as a user-defined net type?
6.6.7 says, "A force statement can override the value of a user-defined net". "force" should be in bold code font.
"user-defined net" is used here, before being defined in 6.7.1.
I dislike the term "user-defined net" anyway. All nets are user-defined. The term does not reflect the intended meaning, that the net has a net type that is user-defined. For example, we do not call a variable whose data type is defined in a typedef, a "user-defined variable", and rightly so.

The term "atomic net" also does not reflect the nature of the net. A net can be defined with type integer, which belongs to integer_atom_type. Why would that be less of an 'atomic net'?
In any case, I see no reason to invent two terms. Just have one term and use it everywhere.

10.6.2 says, "The left-hand side of the assignment can be a reference to a singular variable, a net, a constant bit-select of a vector net, a constant part-select of a vector net, or a concatenation of these." That should be updated to reflect the new types of nets as well.

6.6.7 has the following code comment:
"// a nettype 'wTsum' whose data_type is T and"
"nettype" should be bold.
The single quotes in the code comments everywhere should be straight and not "smart quotes".

The code examples in 6.6.7 and 6.7.1 should be combined. The duplication is unneeded.

In the second code example in 6.6.7, in the line "real r;", the "r" should not be bold.
A few lines down, "Tsum.r= 0.0;" there should be a space before the = sign.

The BNF change to net_declaration in 6.7, etc. should be in CHANGE FROM - TO form.

The following text in 6.7 needs to change:
"A valid data type for a net shall be one of the following:
a) A 4-state integral type, including a packed array or packed structure.
b) A fixed-size unpacked array or unpacked structure, where each element has a valid data type for a net.
The effect of this recursive definition is that a net is composed entirely of 4-state bits and is treated accordingly. In addition to a signal value, each bit of a net shall have additional strength information.
...
The default initialization value for a net shall be the value z."

6.7.2 says, "Since the actual evaluation of the resolution function is subject to scheduling non-determinism, no assumptions can be made regarding the state of driven values during the guaranteed call, which may precede or follow any driver changes at time zero."

But even if a driver values follows the resolution function evaluation at time 0, won't the resolution function then be re-evaluated? The sentence is not clear about that, and appears to hint that possibly not.

6.7.2 says, "The default initialization value for a user-defined net shall be the default value defined by the datatype." This is not clear. Table 6-7 specifies default intialization values for various data types. But it relates only to variables. For example, it says that the default value of a 4-state integral type is X. But for a normal wire (except trireg), it is Z. Till now, wires could only have these 4-state integral types, but this proposal allows them other types. So what value is applied here? Also see Mantis 2409 and 2420.

6.10 says, "It shall be illegal to implicitly declare a user defined net." I don't see that as needed or relevant. The LRM says that an implicitly declared net has the default nettype, which can not be a user-defined net type.

I did not review the rest of the proposal, so in the future there might be more comments.

2.

3213<http://www.eda-twiki.org/svdb/view.php?id=3213> SV-AC Update definition of sampled value
There is a proposal (11 pages)
Passed by voice vote 2011-06-14: 12y/0n/0a.

Approve __ Oppose _x_

The proposal document should begin with the Mantis number and a 1-line description of it in bold font.

In the new 16.5.1, the first paragraph ends, "Below is the formal definition of the sampled value.". The next paragraph begins, "The default sampled value of an expression is defined as follows:". That is, what actually follows the preceding sentence is a definition of 'default sample value', not of 'sampled value'. That is confusing.
"sub-expressions" should not have a hyphen.
The following two paragraphs seem to be contradictory. The difference should be made clearer:
"- Sampled values of automatic variables (see 16.15.6), local variables (see 16.10), and active free checker variables (see 17.7.2) are their current values.

- When a past or a future value of an active free checker variable is referenced by a sampled value function (see 16.9.3 and 16.9.4), this value is sampled in the Postponed region of the corresponding past or future clock tick."

In "When a past or a future value of an automatic variable is referenced by a sampled value function, the current value of automatic variable is taken instead," add "the" after "the current value of".
In "The sampled value of such variable is the sampled value produced by the clocking block," add "a" after "such".
In the following two paragraphs,
"- The sampled value of a constant cast expression (see 16.15.6) is defined as a current value of its argument. For example, if a is a variable, then the sampled value of const'(a) is the current value of a.
- When a past or a future value of a constant cast expression is referenced by a sampled value function, the current value of this expression is taken instead."

"constant cast" should be "const cast," where const is in bold code font. A constant cast is a cast of a constant expression (see the BNF).
Add a xref to 6.24.1 as well as to 16.15.6.
"a current value" should be "the current value".
On the following:
"The sampled value of sequence methods triggered and matched (see 16.14.6) are defined as current values returned by these methods. When a past or a future value of a sequence method is referenced by a sampled value function (see 16.9.3 and 16.9.4), this value is sampled in the Postponed region of the corresponding past or future clock tick."

"The sampled value" at the start of the paragraph should be plural. "as current values" should be "as the current values". As before, the distinction between the cases described by the two sentences is not clear.

In the following paragraph,

"The sampled value of any other expression is defined recursively using values of its arguments. For example, a sampled value of an expression e1 & e2, where e1 and e2 are expressions, is the bitwise and of the sampled values of e1 and e2. In particular, if an expression contains a function application, to evaluate the sampled value of this expression, the function is applied to sampled values of its arguments at the time of the expression evaluation. For example, if a is a static module variable, s is a sequence, and f is a function, the sampled value of f(a, s.triggered) is the result of the application of f to the sampled values of a and s.triggered, i.e., to the value of a taken from the Preponed region and to the current value of s.triggered."

"using values" should be "using the values". "a sampled value" should be "the sampled value". "bitwise and" should be "bitwise AND".

        The LRM does not use the term "apply" with respect to functions.

Before the next change, "REPLACE", it would be good to add a note that it is also referring to 16.5, as two pages have passed since the previous reference.
This change adds a heading "16.5.3 Assertion clock". The previous change adds 16.5.1. However, there is no 16.5.2.

Before the next change, "REPLACE", it would be good to add a note that it is also referring to 16.5, as the addition of the 16.5.3 header in the previous change could make the location of the text of this change unclear.
This proposal deletes subclause 16.6.2. So the following also have to change:
In 16.6, "There are certain restrictions on the expressions that can appear in concurrent assertions. The restrictions on operand types, variables, and operators are specified in 16.6.1, 16.6.2, and 16.6.3."

In 16.6.1, " - class, static class members are allowed (see 16.6.2)". See Mantis 2353.
In 16.9.3, if the intent is for "The following functions are provided:" to begin a new paragraph (which I think is good), then an explicit note to the editor should be added. Otherwise, it may not be noticed.
In 16.9.3, "The function $sampled is useful to access the value of expressions used in concurrent assertions in their action block," "action block" should be plural.
I did not review the rest of the proposal, so there may be more comments in the future.

3.

3293<http://www.eda-twiki.org/svdb/view.php?id=3293> SV-EC Clarify $cast behaviour on class handles
There is a proposal (1 page - all new text)
Unanimously approved in sv-ec meeting June 6 2011, proposal 3293-proposal-v4.pdf

Approve __ Oppose _x_

No technical objections, but:
The proposal document should begin with the Mantis number.

Add a cross-reference from 6.24.2 to 8.15.
After adding in the first paragraph the reference to $cast, the second paragraph becomes redundant and awkward and should be deleted.
The first paragraph refers to "the $cast function". $cast can also be a task.
That reference should be followed by "(see 6.24.2)".
The font of "$cast" should be consistent.
6.24.2 shows the function form of $cast first, then the task form. Here, it is reversed.
"function int" should be bold.
6.24.2 shows the $cast arguments as "dest_var" and "source_exp", whereas here they are "dest_handle" and "source_handle". If they are going to be shown here in a context-specific form, then "singular" is not needed.
The end of the first paragraph says "an object whose actual type is assignment compatible with", whereas the text of the second case is, "an object that is assignment compatible with", omitting "whose actual type". They should be consistent.
"will fail" should be "shall fail".
The font size of the last paragraph should be like that of the rest.

4.

3279<http://www.eda-twiki.org/svdb/view.php?id=3279> SV-EC Enhance method override rules to allow covariant typing
Close as duplicate of 3278.
Unanimously approved to CLOSE, already merged into 3278, in email vote, ended June 6 2011.

Approve _x_ Oppose __

5.

3278<http://www.eda-twiki.org/svdb/view.php?id=3278> SV-EC virtual method type rules
There is a proposal (2 pages)
Unamiously approved at sv-ec meeting, June 6 2011, proposal: 3278-v4.pdf

Approve __ Oppose _x_

No technical objection, but:
The proposal document header should state more clearly which Mantis it is associated with in the database.
The proposal should incorporate the changes in 8.19 from Mantis 2950.
"virtual function" in the text should be "virtual method" everywhere.
"super class" should have no space.
In the following paragraph:

"Example 2 illustrates the use of derived class types for virtual function return type, and formal argument matching types. In the derived class D, the virtual function return type is D, a derived class type of C. The formal argument datatype is T which is a matching datatype of the predefined type int."

there is a singular-plural mismatch between "class types" and "return type". "formal argument matching types" should be "matching formal argument types". "datatype" should be "data type", twice. "int" should be in bold code font.
The following example should be preceded by "Example 2:"
In the line, "class E (type Y = logic) extends C;", "type" and "logic" should be bold.
In the lines,
"E #() v1; // Illegal: type parameter Y resolves to logic which is not a matching type for argument 'a'
 E #(int) v2; // Legal: type parameter Y resolves to int"

        "logic" and "int" should be bold, and the quotes around "a" should be straight.

6.

0210<http://www.eda-twiki.org/svdb/view.php?id=0210> SV-BC Allow use of generate in module port list
No change required
On May 23, 2011 the SV-BC unanimously voted to resolve this issue with no change as the committee was unable to find a solution that is technically sound and acceptable to users.

Approve _x_ Oppose __

7.

2556<http://www.eda-twiki.org/svdb/view.php?id=2556> SV-AC Explicit package scope indication is not allowed for checkers
There is a proposal (2 pages - a small number of BNF changes)
Passed by voice vote 2011-05-31: 11y/0n/0a.

Approve _x_ Oppose __

This is OK, though I think the introduction of ps_checker_identifier was not necessary.
It could simply have been written
checker_instantiation ::=
[ package_scope ] checker_identifier name_of_instance ( [list_of_checker_port_connections] ) ;

8.

3036<http://www.eda-twiki.org/svdb/view.php?id=3036> SV-AC Explicitly allow unpacked data types for arguments of assertion system functions
Duplicate of 2476
Approved by the voice vote 2011-01-17: 7y/0n/0a.

Approve _x_ Oppose __

Shalom Bresticker
Intel LAD DA, Jerusalem, Israel
+972 2 589 6582 (office)
+972 54 721 1033 (cell)
http://www.linkedin.com/in/shalombresticker

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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