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 16:18:38 2005