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

Kathy,

I was double checking the corrections in the data base for Draft4 against
e-mail comments on draft 3, and saw that the changes below were not entered
into the data base as bug-notes to #168. I went ahead and made the changes
in P1800/D4.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Kathy McKinley
> Sent: Thursday, January 27, 2005 11:41 AM
> To: sv-bc@eda.org
> Subject: [sv-bc] Review of changes for erratum 168
>
> 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.
>
>
> 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.
>
>
> -------------------------------
> 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.
>
>
> 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.
>
>
>
Received on Fri Feb 11 21:53:21 2005