Re: [sv-bc] Review of changes for erratum 168

My further suggestions on Kath'ys refinements are included below.
Surrendra
At 02:41 PM 1/27/2005 -0500, you wrote:
>Hello,
>
>First, let me say that Stu has done a phenomenal job of incorporating
>the changes. I cannot imagine how he has kept it all straight. Matt and
>I did find a few issues related to Erratum 168. Except for a couple
>of missing grammar changes, they are all very minor. I have grouped
>the issues into the following categories:
>
> - Missing changes
> - Changes not consistent with proposed text
> - Resolution of errata collisions
>
>Kathy
>
>---------------
>MISSING CHANGES
>---------------
>
>
>A.2.1.3 and Syntax 5-2
>
>The replacement of "net_type_or_trireg" specified below has not
>been made in either section:
>
> REPLACE
> net_declaration ::=
> net_type_or_trireg ...
> WITH
> net_declaration ::=
> net_type ...
>
>The replacement of "variable_declaration" specified below has not
>been made in either section:
>
> In data_declaration, REPLACE
> [ const ] [ lifetime ] variable_declaration
> WITH
> [ const ] [ var ] [ lifetime ] data_type_or_implicit
> list_of_variable_decl_assignments ;
>
>
>-----------------------------------------
>CHANGES NOT CONSISTENT WITH PROPOSED TEXT
>-----------------------------------------
>
>3.1
>
>In the resolution of 168, the following is a separate paragraph:
>
> The additional strength information associated with bits of a net is not
> considered part of the data type.
>
>In the draft, this sentence is appended to the preceeding paragraph
>instead.
>
>The following sentence in the resolution of 168 is:
>
> Verilog-2001 provides arbitrary fixed length arithmetic using 4-state
> logic.
>
>In the LRM draft that sentence is:
>
> Verilog provides arbitrary fixed length arithmetic using 4-state data
> types.
>
>Seems 'data types' should be changed to 'logic' in the LRM.
>

May be better to leave it as "data type" as it may exclude other data types
such as packed structs and arrays of 4-state types

>5.5
>
>The resolution for 168 has the following two sentences in separate
>paragraphs.
>
> If a data type is not specified in the net declaration then the data
> type of the net is logic.
>
> Certain restrictions apply to the data type of a net. A valid data type
> for a net shall be one of the following: ...
>
>The LRM draft merges tht two paragraphs together.
>
> If a data type is not specified in the net declaration then the data
> type of the net is logic. Certain restrictions apply to the data type
> of a net. A valid data type for a net shall be one of the following: ...
>
>
>18.8
>
>In the paragraph that begins "For subsequent ports in the port list",
>the last sentence should be:
>
> This default net type can be changed using the `default_nettype
> compiler directive, as in Verilog.
>
>In the draft, the change from "type" to "net type" has not been made:
>
> This default type can be changed using the `default_nettype
> compiler directive, as in Verilog.
>
>
>Annex J
>
>The resolution says:
>
> An integral data type represents integral, or integer, values.
>
>The draft is missing a comma after "integer":
>
> An integral data type represents integral, or integer values.
>

I'm not sure about the intention of using two similar words. It should
either say
"An integral data type represents integral values."
or
"An integral data type represents integer values."

>-------------------------------
>RESOLUTION OF ERRATA COLLISIONS
>-------------------------------
>
>3.7
>
>For the first paragraph, the draft notes that erratum 275 is assumed
>to supersede erratum 168. The point of the change in erratum 168 was
>to make correct use of the term "data type". The text from 275 does
>not preserve the intent of 168.
>
>Original:
>
> SystemVerilog includes a string data type, which is a variable size,
> dynamically allocated array of bytes.
>
>Proposal from erratum 168:
>
> SystemVerilog includes a string data type. The values of the string
> data type are dynamically allocated arrays of bytes of arbitrary size.
>
>Current LRM language (from erratum 275):
>
> SystemVerilog includes a string data type, which is an ordered
> collection of characters.
>
>Wording that better conforms with the intent of #168 would be:
>
> SystemVerilog includes a string data type. The values of the string
> data type are ordered collections of characters.
>

The second sentence is confusing as it suggests multiple values of a string
data type. I suggest
"SystemVerilog includes string data type whose value is an ordered
collection of characters."

>23.7: Array querying system functions
>
>The 101 and 168 errata both propose changes to the same sentence,
>without taking each other into account. Erratum 101 adds a reference
>to the "integer type", and erratum 168 seeks to generalize the definition
>to apply to more than just variables, and to consistently apply the terms
>"data object" and "data type".
>
> Original:
>
> SystemVerilog provides system functions to return information about
> a particular dimension of an array variable or type.
>
> New:
>
> SystemVerilog provides system functions to return information about
> a particular dimension of an array object (see Clause 4) or integral
> type (see 3.3.1) or data type.
>
> Erratum 101:
>
> SystemVerilog provides system functions to return information about
> a particular dimension of an array (see section 4) or integer type
> (see section 3.3) or variable of such type.
>
> Erratum 168:
>
> SystemVerilog provides system functions to return information about
> a particular dimension of an array data object or data type.
>
>The following wording might more closely match the intent of erratum 168:
>
> Suggested New:
>
> SystemVerilog provides system functions to return information about
> a particular dimension of an array (see Clause 4) or integer (see
> 3.3.1) data type, or data objects of such a data type.

Since this is an introductory sentence. I suggest a simpler wording
"SystemVerilog provides system functions to return information about
dimensions of array data types and objects."
Technically, all types are allowed to be arguments, although only array
types have the intended benefits provided by these functions.

**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752

Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
Received on Thu Jan 27 13:28:14 2005