The following guidelines are based mostly on the IEEE Standard Style
Guide and quote from it, with some additional material from me.
Shalom
We use the terms "normative" and "informative".
"Normative" text is an official part of the standard.
"Informative" text is included in a standard for information only and is not an official part of the standard
itself. Standards writers should carefully consider the nature of the material placed in informative test. The
working group should also understand that informative material is considered part of the balloted document
and copyrighted to the IEEE. As such, it shall be submitted to the IEEE-SA Standards Board and is not subject to
change after approval.
Normally, the main body of the standard is normative, at least unless otherwise specified.
On the other hand, every annex (appendix) must be labelled as either normative or informative.
Normative annexes are official parts of the standard that are placed after the body of the standard for reasons of
convenience or to create a hierarchical distinction. In many cases, normative annexes are used for conformance
test procedures or tables. Some standards place syntax definitions, lists of keywords, or printed source code in
normative annexes. Normative annexes may also be used for context-specific applications of the standard.
A normative section may contain explanations, etc., that are not really part of the standard in that they do
not describe requirements, etc. Nevertheless, they do not need to be labelled explicitly as informative.
So in 1364-2001, subclause 20.1 probably need not have been labelled as informative.
On the other hand, Table 88 is explicitly labelled as informative and probably needs to be in order to avoid misunderstanding.
The introductory sections of each clause in SV 3.1a (2.1, 3.1, etc.) probably should not be labelled as informative.
Tables are normative unless otherwise specified.
Figures are normative unless otherwise specified.
Syntax Boxes are normative unelss otherwise specified.
Examples are INFORMATIVE.
Normative material should not be stated only in informative text.
For example, a normative requirement should not be described only in a comment in a code example.
Notes
-----
Notes are INFORMATIVE.
Explanatory statements may be used in the text for emphasis or to offer informative suggestions about the
technical content of the standard. These notes provide additional information to assist the reader with a particular
passage. A note in the text is not an official part of the approved standard and should follow that paragraph to
which it belongs. Such statements shall be set apart from the text by introducing them with the capitalized word
"NOTE-".
A Note to a Table/Figure is INFORMATIVE.
Footnotes
---------
Footnotes are INFORMATIVE.
Footnotes may be included in a standard only for information, clarification, and aid in the use of the standard.
Mandatory requirements shall not be included in footnotes because footnotes are not officially a part of the
standard, but they shall be included in the draft that is submitted to the IEEE-SA Standards Board.
A Footnote to a Table may be normative.
This is DIFFERENT from Footnotes to the main text.
Word Usage
----------
"Shall, should, may, and can"
The word "shall" is used to indicate mandatory requirements strictly to be followed in order to conform to the
standard and from which no deviation is permitted ("shall" equals "is required to"). The use of the word "must" is
DEPRECATED and SHALL NOT be used when stating mandatory requirements; "must" is used only to describe
unavoidable situations. The use of the word "will" is deprecated and shall not be used when stating mandatory
requirements; "will" is only used in statements of fact.
The word "should" is used to indicate that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required;
or that (in the negative form) a certain course of action is deprecated but not prohibited ("should" equals "is
recommended that").
The word "may" is used to indicate a course of action permissible within the limits of the standard ("may" equals "is
permitted").
The word "can" is used for statements of possibility and capability, whether material, physical, or causal ("can" equals
"is able to").
It follows from this that "may not" should not be used. "shall not" should be used instead.
In the context of SV, the beginning of 1364-2001 may be useful in clarifying the application of these definitions.
(except that instead of the word "can", 1364-2001 should have used "may" instead):
The term "shall" is used throughout this standard to indicate mandatory requirements, whereas the term "can" is used to indicate optional features. These terms denote different meanings to different readers of this standard:
To the developers of tools that process the Verilog HDL, the term "shall" denotes a requirement that the standard imposes. The resulting implementation is required to enforce the requirements and to issue an error if the requirement is not met by the input.
To the Verilog HDL model developer, the term "shall" denotes that the characteristics of the Verilog HDL are natural consequences of the language definition. The model developer is required to adhere to the constraint implied by the characteristic. The term "can" denotes optional features that the model developer can exercise at discretion. If used, however, the model developer is required to follow the requirements set forth by the language definition.
To the Verilog HDL model user, the term "shall" denotes that the characteristics of the models are natural consequences of the language definition. The model user can depend on the characteristics of the model implied by its Verilog HDL source text.
-- 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 ProprietaryReceived on Mon Jul 19 05:27:51 2004
This archive was generated by hypermail 2.1.8 : Mon Jul 19 2004 - 05:28:18 PDT