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

Hi. Small comments:

First, I should clarify that I think Stu did a great job.

On Wed, 14 Jul 2004, Stuart Sutherland wrote:

> 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.

I do.

Also, in working on Version C of 1364-2001 and on the drafts of 1364-2005,
I have done a lot of behind-the-scenes cleanup of formats, fonts, etc.

It's not perfect, but it is in a lot better state than it was before.

> 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.

I'm not sure, because it probably sped things up. But no matter now.

> 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.

The latter is dangerous.

In 1364, occasionally changes I have made have turned out to be wrong
for various reasons, and then I have had to change them back.

There could be a compromise of letting the editor do what he feels needs
to be done, and then submit it to review with clear indications of what
he changed.

> 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.

Thanks for the compliments.

As I have an employer, who I don't believe is willing to donate my time to
do editorial work, I don't think it is possible for me to be editor.
It also helps for the editor to have a good understanding of what he is
editing.

I'll be glad to advise, though.

> 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.

In addition, graphics work takes a lot more time than work on text.

 
> 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.

As a side note, I personally find the vpi_user.h file not well organized.
I would suggest considering a new organization. In addition, it is
difficult to find what you want. An index to the file would be helpful.

Finally, consider a CD version of the LRM including the vpi_user.h in
its own separate file.

Regards,
Shalom

-- 
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