RE: [sv-bc] sv 3.1a section 3.1 on truncation warnings

> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of David W. Smith
...
> Just a comment. One of the reasons we had Stu as editor was
> so that he could
> help to insure that the LRM does meet the IEEE style
> guidelines.
...

All,

For the record, I did try to maintain the 1364 wording usage of "can" and
"shall" as much as I could. I also tried to reword the first-person (use of
"we", "you", etc.) writing style that many of the SV subcommittees used in
their change requests. However, I had very limited power to do wording
changes on the text beyond the wording that had been voted on and approved
by the SystemVerilog committee and subcommittees.

Some key points to note about the state of the SystemVerilog LRM, that the
next editor, and the P1800 committee, need to be aware of are:

1. The Adobe Framemaker template I used as a basis for the SystemVerilog LRM
was from the IEEE 1364-2001 ballot draft (editing of the SystemVerilog LRM
began very shortly after work on the 1364-2001 LRM was completed). I have
since learned that the ballot draft of the 1364 LRM was not all that
compliant with IEEE document standards. The IEEE documentation group made
many changes to the 1364 document formatting subsequent to that draft, but I
did not--and still do not--have access to the revised Framemaker files or an
updated IEEE Framemaker template.

2. The base document we started with for the SystemVerilog LRM was a
Microsoft Word document that was radically different both in formatting and
wording style from the IEEE 1364-2001 LRM. Those roots are still apparent
in the SystemVerilog LRM.

3. Nearly every change request that was implemented (thousands over the
three-year editing process) flagrantly violated IEEE wording style. I did
not have the authority to make significant changes to the text I was given
to insert into the SV LRM.

4. Perhaps the most important note to make regarding the state of the SV
3.1a LRM is that is was expected all along that the document wording would
be brought into conformance with IEEE standards as the various sections and
subsections were pulled apart and integrated into the IEEE 1364 standard.
Therefore no emphasis was placed on IEEE style by the Accellera SV
committees and subcommittees. Hindsight proves that this was a mistake on
the part of the Accellera SystemVerilog committee.

5. Moving forward, the P1800 committee needs to work differently than the
Accellera SV committee, by either only approving text that is already
correctly worded per IEEE guidelines, or by giving the editor carte blanche
authority to re-word text so that it conforms to IEEE requirements.

6. I consider Shalom to be the expert on what the IEEE requires for both
formatting and wording style, as well as any latitude the IEEE gives on
these matters. The P1800 committee would do well to retain Shalom as either
the editor, or as an advisor to the editor, for both the Verilog and
SystemVerilog LRMs.

7. As recent co-chair of the 1364 PLI task force, and as the editor of the
PLI sections for both the 1364-1995 and 1364-2001 LRM, I want to emphasize
two very important shortcomings in the VPI sections of the SV 3.1a LRM:

a) The VPI diagrams in the SV LRM do not conform in to the 1364 LRM in any
way. The SV LRM uses different fonts, different Framemaker paragraph tags,
different Framemaker character tags, different Framemaker drawing symbols,
etc. I did not put in the 100+ man hours to totally rework the SV VPI
drawings that were given to me by the SV-CC committee because I was aware
that the 1364 PLI task force was already planning to re-do the 1364 VPI
diagrams from scratch, using a different diagram convention. Since it was
expected that the SV diagrams would be integrated into the 1364 diagrams, it
would have been a waste of time and money for me to have completely re-drawn
the SV diagrams for the SV 3.1a LRM.

b) The SV 3.1a VPI diagrams CANNOT stand on their own as they are currently
documented. The diagrams are modified excerpts from the 1364-2001 LRM. By
themselves, these excerpts are unusable. The fact that these modified
diagrams exist makes the 1364 diagrams unusable. The ONLY way the VPI
diagrams can be usable is for an integrated single set of diagrams that
cover both the 1364 standard and the SystemVerilog standard. The same issue
applies to the modified vpi_user.h file in the SV 3.1a LRM. It is not
usable--and not C-language compliant--to have two standard vpi_user.h files.
There can only be a single vpi_user.h standard. The P1800 committee needs
to decide in which LRM that single set of diagrams and single standard
header file will reside.

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

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of David W. Smith
> Sent: Wednesday, July 14, 2004 8:49 AM
> To: 'Shalom Bresticker'; Vassilios.Gerousis@Infineon.Com
> Cc: 'Shalom Bresticker'; sv-bc@eda.org
> Subject: RE: [sv-bc] sv 3.1a section 3.1 on truncation warnings
>
> Hi Shalom,
> Just a comment. One of the reasons we had Stu as editor was
> so that he could
> help to insure that the LRM does meet the IEEE style
> guidelines. I am sure
> that some things have been missed but that was the intent of the LRM
> development all along. I know that Stu made many corrections
> and changes to
> try to make sure it did meet the guidelines.
>
> Any specific things that need changed would be greatly appreciated.
>
> Regards
> David
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Shalom
> Bresticker
> Sent: Tuesday, July 13, 2004 11:01 PM
> To: Vassilios.Gerousis@Infineon.Com
> Cc: Shalom Bresticker; sv-bc@eda.org
> Subject: Re: [sv-bc] sv 3.1a section 3.1 on truncation warnings
>
> Hi, Vassilios.
>
> As the LRM is turned into an IEEE draft standard, the entire
> LRM needs to be
> reviewed line by line whether it meets IEEE style guidelines,
> which are
> intended
> to remove ambiguity, among other things.
>
> This is not as difficult as it sounds, but it does take some time and
> resources.
> It is better that the developers of the LRM do it than to rely on the
> IEEE Publications staff, who are not familiar with the
> material content.
>
> I believe I can make a summary of those IEEE style guidelines
> which are
> relevant
> in this context.
>
> Shalom
>
>
> Vassilios.Gerousis@Infineon.Com wrote:
>
> > All your feedbacks are good and valid. I would prefer to
> see specific
> > comments on specific sentences or paragraphs. Shalom
> comments are very
> > constructive, and we will do that the first round.
> Jonathan, if you have
> > specific information to provide please do so and follow our process
> > please.
>
> --
> Shalom Bresticker Shalom.Bresticker
> @freescale.com
> Design & Reuse Methodology Tel:
> +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax:
> +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell:
> +972 50 5441478
>
> [ ]Freescale Internal Use Only [ ]Freescale Confidential
> Proprietary
Received on Wed Jul 14 10:38:40 2004