From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu Oct 11 2001 - 08:35:46 PDT
Cliff,
I apologize for arguing with you in public, but I feel I have no choice this time.
Please consider seriously what I have to say.
First, the criteria you used to classify changes as "critical" vs. "important" vs. "less important"
are not clear to me.
In my opinion, it is "critical" or "important" (I won't distinguish between them) to fix an error
in the technical content of the standard, which is liable to cause misunderstanding or confusion
of the standard.
I do not understand why some content errors are "critical" for you and others are only "important".
Typos are "less important" to me.
Using my criteria, I cannot agree that of all the errors we have found, misspelling of "nonblocking"
is one of the few "critical" errors. Frankly, what difference does it make ?? What is important is that
a person who reads the standard will correctly understand it.
I would not bring this up if I was sure that even our "less important" corrections would be accepted.
But if there is a chance that only "critical" errors will be corrected, I cannot agree that "nonblocking" is
a more important correction than so many others.
Now I will comment on your list by its order.
-- p. 3: "Pages 178-179 - Section 12.1.3.4 - Example 8":
I issued the bug report on this (BTF-PR11), but I don't think it's critical. Maybe important.
I don't think it will cause misunderstanding of the standard.
<p>-- p.4: "BTF-PR8: Page 46 - Section 4.1.7 - 3rd & 2nd to last paragraphs":
I think the correction to 4.1.8 is needed and equally important.
I will discuss this below.
<p>-- p.5, top, continuation of BTF-PR8:
You suggest the correction:
"When both operands of a relational expression are signed operands (an integer, a signed reg data type, or an unsized, unbased
integer)"
This formulation causes confusion between "an integer" and "an unsized, unbased integer".
I suggest the following:
"When both operands of a relational expression are signed operands (an integer variable, a signed reg data type, or an unsized,
unbased integer number)",
<p>-- p.5, "BTF-PR10: Page 80 - Section 7.1.6 - Port declarations for Example 3":
If I have to rank importance, this is "less important".
<p>-- p. 5: "BTF-PR7: Page 169 - Section 12.1.3 - 7th paragraph - Typo":
It should be PR6, not PR7. This is also my error report, by the way.
And the error is not a simple typo, fixed by just deleting "by the".
The entire sentence is garbled, incomprehensible, and just plain WRONG.
The proper correction, based on extensive research, is:
"Parameters may be redefined within the generate scope by defparam statements (12.2.1) or module instance parameter value
assignments (12.2.2)."
<p>-- p. 5: "Page 322 - Section 17.10.2 - Examples - reg declaration syntax error"
Again, less important.
<p>-- p. 6: "BTF-PR15: Page 354 - Section 19.4 - 2 nd list item at the bottom of the page - Typo"
Definitely less important.
<p>-- p. 6: "FORMATTING ERRORS - LESS IMPORTANT CHANGES"
You write, "These corrections have mostly to do with fonts and are requested only if the IEEE is willing to make changes to be
consistent with the descriptions set forth in section 1. There are probably hundreds of these ... These changes are not critical to
publication of the IEEE Verilog-2001 Standard at this time."
I cannot agree. Some of these errors are significant. Fonts in syntax boxes are not just for emphasis. They can be the
difference between a character being required or optional.
I also do not agree about "hundreds". At least in the case of the syntaxes, I carefully reviewed Annex A line by line, and I am
confident that only a small number of undetected font errors remain there.
Finally, at least in some cases, these changes may not be "critical", but they are definitely more important than fixing "the the" to
"the".
<p>-- p. 6: "Page iii - 2nd paragraph after "INTRODUCTION"
The "<funny character>" should be the "Registered" symbol, an "R" in a circle.
In Draft 6, it was OK.
I think this sort of typo reflects more on professionalism than "the the".
<p>-- p. 6: "BTF-PR29 - Page 7 - Syntax 2-1":
The explanation should be:
'(The [ ]'s enclosing "size" should NOT be bold)'.
There are no "second []'s".
This error causes []'s to be required characters, and "size" a required field.
The correction is that "size" is optional, and the []'s are not part of the syntax.
<p>-- p.7: "Section 4.1.8 does not describe equality comparisons between two operands of different sizes (signed or unsigned)."
I strongly disagree. 4.1.8 says, "These four operators compare operands bit for bit, with zero filling if the two operands are of
unequal bit length." That is exactly "equality comparisons between two operands of different sizes".
You write, "Establishing equality between two signed variables is similarly not bit-width dependent". I disagree. You can compare
between two signed regs of different length, or between a signed reg and an integer variable, etc. Here zero-extension of the smaller
variable will give the wrong result.
This MUST be fixed, similarly to 4.1.7
<p>-- p. 7: "I think the assumption was that bit-wise operations are performed on unsigned operands, even if both operands were declared to
be signed."
Here I agree, although I do not think it is written explicitly in the standard.
<p>-- p. 7: "Can anyone find a description in the Standard for truncation?"
I did not find one.
<p>-- p. 7: "BNF Fixes Might Be Required - But we don't have time to investigate and do them right now"
Here again I disagree.
In many of the cases, either no investigation is required because it is obvious or we have already investigated them. Remember
that all these bug reports have been distributed to the entire BTF.
I will classify each of them:
o BTF-PR12 - required, but does require investigation
o BTF-PR20 - required, but does require investigation
o BTF-PR21 - less important, but does not require investigation
o BTF-PR22 - less important, but does require investigation
o BTF-PR23 - less important, but does not require investigation
o BTF-PR25 - less important, but does require investigation
o BTF-PR28 - less important, but does not require investigation
o BTF-PR29 - appears above on p. 6
o BTF-PR30 - required, but does not require investigation
o BTF-PR32 - less important, but does not require investigation
o BTF-PR33 - requires investigation
o BTF-PR34 - typos: less important, but does not require investigation.
The last comment is dealt with in PR41.
o BTF-PR37 - requires investigation
o BTF-PR43 - less important, but does not require investigation
However there are some important additional PRs which are missing from the list:
o BTF-PR3 - required, but does not require investigation (I just found & sent the correction separately)
o BTF-PR19 - required. Just change "two or more" to "one or more". No further investigation required.
o BTF-PR27 - less important, but does not require investigation
o BTF-PR40 - required, but does not require investigation
o BTF-PR41 - required, but does require investigation, but probably only a little. At the very least, insert the text which was
supposed to be there.
o BTF-PR42 - less important, but does not require investigation
o BTF-PR44 - required, but does not require investigation
o BTF-PR47 - required, but does not require investigation for part of the correction. Just delete the new sentence.
Regards,
Shalom
<p>"Clifford E. Cummings" wrote:
> BTF List Compiled by Cliff Cummings, Chairperson of BTF - October 10, 2001
>
> I guess the only perk I get as chair of the BTF is prioritizing which
> mistakes are most critical. Attached is a PDF file containing the list of
> changes with assigned priority. In some cases, the changes (designated as
> BTF-PR##) are in response to Problem Reports being tracked on the BTF Gnats
> Reflector, being maintained by Stefen Boyd.
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 **************************************************************************
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:47 PDT
and
sponsored by Boyd Technology, Inc.