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

Kathy,

The corrections to the editing that you have noted do not need to be nicely
formatted with coloring and such. They are simple corrections and a text
description as you have done is all that is needed.

However, providing these as an e-mail to me does not adequately document the
history, nor follow the procedures outlined for correcting editing. A
couple of lines long correction can be noted in the bug-notes of the errata
item. Since this is much more than a few lines, it should be noted as an
attachment to the errata, and bug-note added to refer to the attachment.

I think the door is open wide enough on these editing corrections to also
make minor rephrasing of a sentence to make it either more clear or better
grammar. The key, of course, is that any rewording cannot change the
meaning of what was already approved. If the meaning has to change because
it is not correct, that would require a new errata number and going through
committee, champions and working group approval. There is time for that as
well, because we have scheduled a special working group meeting for Feb 4 to
cover any last minute corrections (committees must have changes to Karen by
Feb 3 in order for the champions to review them).

Regarding the two collisions in errata, lets get it right at this time.
Those really are corrections to the editing. When multiple errata did
modify the same sentence or paragraph, a complete rewording may be the right
thing to do, in order to properly merge the multiple errata.

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

> -----Original Message-----
> From: Kathy McKinley [mailto:mckinley@cadence.com]
> Sent: Thursday, January 27, 2005 4:18 PM
> To: Surrendra.Dudani@synopsys.com; mckinley@cadence.com;
> stuart@sutherland-hdl.com
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Review of changes for erratum 168
>
> From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
> To: "'Kathy McKinley'" <mckinley@cadence.com>,
> "'Surrendra Dudani'" <Surrendra.Dudani@synopsys.com>
> Cc: <sv-bc@eda.org>
> Subject: RE: [sv-bc] Review of changes for erratum 168
> Date: Thu, 27 Jan 2005 14:47:45 -0800
>
> Hi Stu,
>
> I apologize for providing a resolution that does not meet the
> markup requirements, and I really appreciate the care that
> you took to make the changes correctly. I cannot tell you how
> impressed I am.
>
> I believe that the grammar changes for A.2.1.3 and Syntax 5-2
> are in the correct form in the resolution of #168, thanks to Brad.
> These changes are missing in the draft LRM. I don't think
> that I have priveleges to download things or change the status.
>
> The others that I classified as "Changes not consistent with
> proposed text" are very minor issues. Some are simply
> formatting issues such as missing paragraph breaks. Would it
> be acceptable if I tried a more precise description (with the
> colors, etc.) in a mail to you?
>
> The last two items were subjective judgments about errata collisions.
> Both were in areas that the datatypes subgroup classified as
> nonessential changes. We were trying to apply terminology
> consistently, but we did not feel that any critical
> misunderstanding would result if the changes were not made. I
> am fine with leaving this text as it is in the draft LRM.
> This is not the time for being pedantic. Matt and Surrendra,
> would you agree?
>
> Kathy
>
> >>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 17:29:25 2005