Fwd: Re: errata/639: PROPOSAL - fix use of "shall" and "may" by IEEE rules

From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Mon Jan 03 2005 - 09:03:33 PST

  • Next message: Karen Pieper: "Updated Database"

    Please review for our meeting on 1/10.

    K

    >Date: Fri, 31 Dec 2004 00:10:01 -0800
    >From: Shalom.Bresticker@freescale.com
    >To: etf-bugs@boyd.com
    >Subject: Re: errata/639: PROPOSAL - fix use of "shall" and "may" by IEEE
    > rules
    >Sender: owner-etf@boyd.com
    >X-pstn-levels: (S:83.26156/99.90000 R:95.9108 P:95.9108 M:97.0232 C:98.7678 )
    >
    >The following reply was made to PR errata/639; it has been noted by GNATS.
    >
    >From: Shalom.Bresticker@freescale.com
    >To: etf-bugs@boyd.com
    >Cc: sv-champions@eda.org, ieee1800@eda.org
    >Subject: Re: errata/639: PROPOSAL - fix use of "shall" and "may" by IEEE
    > rules
    >Date: Fri, 31 Dec 2004 10:22:23 +0200 (IST)
    >
    > Hi, regarding this task:
    >
    > > The editor is requested to examine in his copious free
    > > time the use of the terms "shall", "will" and "must"
    > > in the LRM, change where needed to conform to IEEE style,
    > > and submit to the WG a list of changes he
    > > made and of possible additional changes.
    > >
    > > Similarly,
    > > the editor is requested to examine in his copious free
    > > time the use of the terms "can" and "may"
    > > in the LRM, change where needed to conform to IEEE style,
    > > and submit to the WG a list of changes he
    > > made and of possible additional changes.
    >
    > > http://wa.boyd.com/cgi-bin/issueproposal.pl?cmd=view&database=default&pr=639
    >
    > I have not done a systematic review of the 1364 LRM,
    > but over time I have made some changes of this nature.
    >
    > By running compare utilities on new and old versions of the LRM,
    > I have made an attempt to locate those changes which I have made.
    >
    > I list them here.
    >
    > A few of them were voted on by the 1364 VSG, even if not stated so below.
    > There may be a few additional changes which I did not find because they
    > were a part of larger changes, but such cases were probably voted on by
    > the VSG.
    >
    > In reviewing the changes I found, I decided to be conservative and change
    > some of them back to the original text, so I have not listed them here.
    > Such cases would appear in the changed form in Draft 4, but will revert to
    > the original form in Draft 5.
    >
    > Quick Reference:
    >
    > "shall" = requirement of the standard on legal behavior
    > "may" = permission, optional behavior
    > "can" = possiblity of reality, e.g., adding 3-bit numbers "can" result in
    > a 4-bit number
    > "must" = deprecated, not to be used instead of "shall", to be used to
    > indicate constraint on reality, e.g., I "must" apply power to my
    > chip for it to work.
    > "will" = indicates a result that will occur in reality, e.g., If I am
    > fired, I "will" be sad.
    >
    >
    > 1.2 Conventions used in this standard (ETF 553)
    >
    > from "The term CAN is used to indicate optional features"
    > from "The term MAY is used to indicate optional features"
    >
    > from "The term CAN denotes optional features"
    > from "The term MAY denotes optional features"
    >
    >
    > 2.5.1 Integer constants
    >
    > from "Unsized unsigned constants ... ARE extended to the size of the expression ..."
    > to "Unsized unsigned constants ... SHALL BE extended to the size of the expression ..."
    >
    >
    > 2.6 Table 2-1 Specifying special characters in string
    >
    > from "the following character MUST not be an octal digit"
    > to "the following character SHALL not be an octal digit"
    >
    >
    > 2.8 Attributes
    >
    > from "a mechanism ... for specifying properties ... that MAY be used by various tools ..."
    > to "a mechanism ... for specifying properties ... that CAN be used by various tools ..."
    >
    >
    > 3.2.1 Net declarations
    >
    > from "The net data type SHALL represent physical connections ..."
    > to "The net data type CAN represent physical connections ..."
    >
    >
    > 3.3.1 Specifying vectors
    >
    > from "Implementations may set a limit on the ... length ..., but they WILL be at least 65536 bits"
    > to "Implementations may set a limit on the ... length ..., but the limit SHALL be at least 65536 bits"
    >
    > from "Implementations DO NOT HAVE to detect overflow of integer operations."
    > to "Implementations ARE NOT REQUIRED to detect overflow of integer operations."
    >
    >
    > 3.7.5 Supply nets
    >
    > from "The supply0 and supply1 nets MAY be used to model the power supplies ..."
    > to "The supply0 and supply1 nets CAN be used to model the power supplies ..."
    >
    >
    > 3.10.3 Specify parameters
    >
    > from "a specify parameter ... MAY be modified through SDF annotation ..."
    > to "a specify parameter ... CAN be modified through SDF annotation ..."
    >
    > from "Specify parameters and module parameters SHALL not be interchangeable."
    > from "Specify parameters and module parameters ARE not interchangeable."
    >
    >
    > 4.1.8 Equality operators
    >
    > from
    > "a == b a equal to b, result MAY be unknown
    > a != b a not equal to b, result MAY be unknown"
    > to
    > "a == b a equal to b, result CAN be unknown
    > a != b a not equal to b, result CAN be unknown"
    >
    >
    > 4.4.2 An example ...
    >
    > from "where a and b are to be added, which MAY result in an overflow"
    > to "where a and b are to be added, which CAN result in an overflow"
    >
    >
    > 9.7.1 Delay control
    >
    > from "[Specify parameters] MAY be overridden by SDF annotation"
    > to "[Specify parameters] CAN be overridden by SDF annotation"
    >
    >
    > 11 Disabling of named blocks and tasks
    >
    > from "The results of the following activities that MAY be initiated by a task ..."
    > to "The results of the following activities that CAN be initiated by a task ..."
    >
    >
    > 14.6 Pulse filtering behavior
    >
    > from "The e-limit MUST always be at least as large as the r-limit."
    > to "The e-limit SHALL always be at least as large as the r-limit."
    >
    >
    > 15.7 Vector signals in timing checks
    >
    > from "Simulators CAN provide an option causing vectors in timing checks to ..."
    > to "Simulators MAY provide an option causing vectors in timing checks to ..."
    >
    >
    > Table 17-1 Escape sequences for priniting special characters
    >
    > from "the following character MUST not be an octal digit"
    > to "the following character SHALL not be an octal digit"
    >
    >
    > 19.2 `default_nettype
    >
    > from "When `default_nettype is set to none, all nets MUST be explicitly declared."
    > to "When `default_nettype is set to none, all nets SHALL be explicitly declared."
    >
    >
    > 19.4 `ifdef
    >
    > from "This directive [`elsif] MUST be preceded by an `ifdef or `ifndef directive."
    > to "This directive [`elsif] SHALL be preceded by an `ifdef or `ifndef directive."
    >
    >
    > 19.7 `line
    >
    > from "The number parameter IS ..."
    > to "The number parameter SHALL BE a positive integer ..."
    >
    >
    > --
    > Shalom Bresticker Shalom.Bresticker @freescale.com
    > Design & Verification 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
    >

    This archive was generated by hypermail 2.1.4 : Tue Jan 04 2005 - 08:39:26 PST and
    sponsored by Boyd Technology, Inc.