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

Kathy and Surrendra,

The editing for #168 was a huge challenge. It was a very large change, and
did not have the proper, and required, markup of what text was to be deleted
and what text was to be added. Its good to hear that I at least got most of
it right.

It would seem that the two of you do not agree on some of the corrections I
need to make. Please figure out the final wording to correct the editing of
#168, and then upload this as a text file attachment to #168. Also add a
bug-note to #168 indicating that this new text file has the editing
correction that need to be made. Of course, the status of #168 will need to
be changed back to assigned, to flag it as something I need to work on for
the final ballot draft.

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 Surrendra Dudani
> Sent: Thursday, January 27, 2005 1:27 PM
> To: sv-bc@eda.org
> Subject: 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 14:48:01 2005