[sv-dc] Revised proposal for 3398 and response to Shalom's comments

Attached is the revised proposal.
Here is the proposed response to Shalom's comments. I 'cc' Shalom so that he can see the new revised proposal and our
response.

Shalom,

"A.9.3 Identifiers" should include "net_type_identifier ::= identifier".
Added production

In "A.2.1.3 Type declarations", "data_declaration" should include "net_type_declaration".
Added
The BNF definition of net_type_declaration in 6.6.7 should have a syntax "box".
Added 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'.
Replaced all occurrences with data type.
"user defined" should be "user-defined" everywhere.
Replaced all occurrences with user-defined
6.6.7 mentions a "composite value", but this term is not defined and will not be clear to many readers.
Replaced with aggregate value. (The composite term is more a VHDL term).

In 6.6.7, "Re-Active" should be "Reactive".
Changed.
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.
I did move the restrictions on the kind of function that were in a following paragraph back up with where we defined what is a user-defined resolution function.

Is it allowed to re-define a built-in net type as a user-defined net type?
No it is not allowed, built-in net types such as wand and wor are keywords . The BNF does not allow to redefine a builtin nettype as a user-defined nettype.
We do not think we need to add text to say that.

6.6.7 says, "A force statement can override the value of a user-defined net". "force" should be in bold code font.
Done
"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.
I agree. What we should have said is a net of a user-defined nettype. Wording has been changed throughout the proposal.
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.
The terms 'atomic net' and 'net of user-defined nettype' are not equivalent.
The atomicity of a net is a property of a net. A net with a user-defined nettype is always an atomic net. A regular logic net (without a user-defined nettype is also an atomic net).
The atomicity is a property of the net value updation and resolution. The net value needs to be updated as a whole, consequently the net is said to be atomic. I made modification to define what is an atomic net in 6.6.7

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.
We added a sentence to clarify force and release for atomic nets.

6.6.7 has the following code comment:
"// a nettype 'wTsum' whose data_type is T and"
"nettype" should be bold.
I bolded the nettype occurrences in the text and in the systemVerilog code, I did not bolded keywords in the comments. I found several occurences in the LRM
where comments were just plain font.
The single quotes in the code comments everywhere should be straight and not "smart quotes".
I remove the quotes everywhere they were used in the comments.

The code examples in 6.6.7 and 6.7.1 should be combined. The duplication is unneeded.
We prefer to leave the code part related to nettype declarations in section 6.6.7 (which is a section about nettype declarations)
and the code part that is related to the net declarations in section 6.7.1 (since 6.7 is a section about net declaration).
The example in 6.7.1 has comments stating refer to the section in 6.6.7 for the nettype and resolution function declarations.
So there is still some code duplication which is necessary to the user understanding.
 In the second code example in 6.6.7, in the line "real r;", the "r" should not be bold.
Fixed
A few lines down, "Tsum.r= 0.0;" there should be a space before the = sign.
Fixed

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

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."
.
This only applies to nets of non user-defined nettypes. Next sections 6.7.1 and 6.7.2 will define the legal datatypes for nets of user defined nettype
and their default initialization value. I added text at the end of section 6.7.2 to describe the legal data types for a net with a user-defined nettype.

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 no
 The resolution function is guaranteed to be called once at time zero no matter what, driver updates may happen after it and so the resolution function will be called again.

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.
The default value for a net of user-defined nettype needs some discussion. The table 6.7 that you refer to is for variables and contains datatypes that are not allowed for nets. I added a sentence in 6.7.2 to indicate that this table also applies to net of user-defined nettype for datatypes legal for these nets.
I also added a sentence to section 7.7.2 to indicate that initailization of members of struct apply to nets of user-defined nettypes.

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.
   We agree to remove that sentence and that section.

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