| Number | 639
|
| Notify-List |
|
| Category | errata
|
| Synopsis | fix use of "shall" and "may" by IEEE rules
|
| State | vsgpassed
|
| Class | errata-simple
|
| Arrival-Date | Nov 29 2004
|
| Originator | Shalom.Bresticker@freescale.com
|
| Release | 2001c
|
| Environment |
|
| Description |
The editor is requested to examine in his copious free time the use of the terms "shall", "will" and "must" in the LRM and submit to the WG a list of changes he made and of possible additional changes. He will submit a list of possible changes to the WG. Similarly, the editor is requested to examine in his copious free time the use of the terms "can" and "may" in the LRM and submit to the WG a list of changes he made and of possible additional changes. |
| Fix |
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. |
| Audit-Trail |
Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 09:33:26 2004 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. 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 From: Shalom.Bresticker@freescale.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/639: PROPOSAL - fix use of "shall" and "may" by IEEE rules Date: Sun, 6 Feb 2005 18:44:56 +0200 (IST) In 12.3.3, I took the following note "NOTE-Implementations may limit maximum number of ports in a module definition, but they will at least be 256." and turned it into the following normative text: "Implementations may limit the maximum number of ports in a module definition, but the limit shall be at least 256." -- 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 |
| Unformatted |
|
Hosted by Boyd Technology