From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Sun Oct 07 2001 - 01:03:29 PDT
Hi, Cliff.
I know you requested a separate email for each typo, but I don't have time for it.
(I work just a half-day today, then I have a 2-day vacation.)
In this mail, I will summarize the relevant entries from the BTF database,
then I will try in a later mail to list others I found in my BTF archive.
Note that syntax fixes need to be fixed both in Appendix A and where they are used in the body of the
standard.
Of the following, I think the more important ones are: 3, 6, 8, 12, 18, 19, 26, 29, 30, 31, 36.
Shalom
<p><p>errata/3: contradiction in 10.3.5 - see details
<p>errata/6: 12.1.3, para. 7:
REPLACE:
"Parameter redefinition using by the ordered or named
parameter = value assignment or defparam statements can also
be declared within the generate scope."
WITH:
"Parameters may be redefined within the generate scope by defparam statements (12.2.1) or module instance parameter
value assignments (12.2.2)."
<p>errata/8: 4.1.7, 4.1.8 - zero-extension of relational and equality operators
Should be sign-extended for signed operands - see details
<p>errata/10: Section 7.1.6, Example 3 (top of p. 84):
The declaration "input [15:0] in;"
should be "busin" instead of "in".
<p>errata/11: 12.1.3.4 example 8 - see details - fix at least the most egregious errors
<p>errata/12: hierarchical parameter identifier - see details
<p>errata/13: Named Parameter Association (Section 12.2.2.2)
===========================
The example for named parameter association is given before the
section that describes named parameter association. I suggest
that
we remove the code that shows named parameter association in the
example on Pg. 189
<p>errata/15: Addtl cond compilation (`ifndef, `elsif, `undef) (Section
19.4)
- Typo on page 363 (line 13 from the bottom); 2 consecutive
"the"s
- There should be better indentation for the sections that
describe how the compiler directives work. I suggest the
following
change on Page 363 (and a similarly indented change for the
corresponding section on Page 364).
- When an `ifdef is encountered, the ifdef text macro .....
- If the ifdef text macro is defined ...
- If the ifdef test macro has not been defined, ...
o If there is an `elsif compiler directive, ...
o If the elsif text macro is defined,..
o etc, etc
<p>errata/18:
Table 4-1 should have arithmetic operators
'>>>' and '<<<' on page 63 of 1364/D6:
Was:
i op j, where op is:
>> << **
Proposed:
i op j, where op is:
>> << >>> <<< **
<p><p>errata/19:
In section 4.1.14 it says:
A concatenation is the joining together of bits resulting from
two or
more expressions.
This is inconsistent with the example on page 322 and with the
BNF.
REPLACE WITH: "one or more expressions".
<p>errata/22:
In syntax of @* (A.6.5), there should probably be an optional
space between @ and *.
<p>errata/23:
In syntax of $hold _timing_check (A.7.5.1), there should be
NO space between $hold and _timing_check .
<p>errata/24:
In A.2.4, pulse_control_specparam syntax,
"PATHPULSE$specify_input_terminal_descriptor$specify_output_terminal_descriptor
= ( reject_limit_value [ , error_limit_value ] ) ;"
the 2nd $, between input and output terminal_descriptors,
should be Bold font.
<p>errata/25:
In A.4.1, named_port_connection syntax,
named_port_connection ::= { attribute_instance } .port_identifier
( [ expression ] )
there should be a space between "." and "port_identifier".
<p>errata/26:
Syntax of list_of_path_delay_expressions in A.7.4:
The 12-expression list is missing a comma between
expressions 6 and 7.
<p>errata/27:
Section 2.7.4 states:
"The $identifier system task or function can be defined in three
places
-- A standard set of $identifier system tasks and functions, as
defined in Sections 17 and 19...."
No $identifiers are defined in section 19.
Some are defined in section 18 however - perhaps that was
intended.
<p>errata/29:
In A.8.7, syntaxes of decimal_number, binary_number,
octal_number, hex_number contain "[ size ]", where "[" and
"]" are in bold, meaning actual literal characters.
They should not be in bold, meaning that "size" is an
optional field.
<p>errata/30:
The definition of an edge_control_specifier given as
edge_control_specifier ::= edge [ edge_descriptor [ ,
edge_descriptor ] ]
in
Syntax 15-2 (p249)
Syntax 15-15 (p267)
Annex 7.5.3 (p791)
Should read
edge_control_specifier ::= edge [ edge_descriptor { ,
edge_descriptor } ]
where the square brackets are in BOLD.
See the example in section 15.4 which says
"posedge clr
is equivalent to the following:
edge[01, 0x, x1] clr"
<p>errata/31:
A.9.4 "Identifier branches" defines
simple_hierarchial_branch as, for example,
simple_identifier [ [ unsigned_number ] ]
In all 4 places in A.9.4 where "[ [ unsigned_number ] ]"
appears, the inner brackets around "unisgned_number" should
be bold.
<p>errata/32:
A.Note.2 says, "A simple_identifier and arrayed_reference
shall start with an alpha or underscore ..."
"arrayed_reference" does not appear in the standard.
<p>errata/34:
Syntax 17-6 (p299) contains the following typo:
non-terminal string_output_tasks makes
use of non-terminal string_output_tasks_name
string_output_tasks_name is NOT defined
string_output_task_name is defined instead
Suggest changing string_output_tasks_name to
string_output_task_name,
as other similar syntaxes use the singular form.
Also
The definition of variable_format_string_output_task mentions a
"format".
This is called a "format_string" everywhere else.
Also
p299 contains a paragraph beginning
"The syntax for the string output system tasks is..." which
(1) is redundant wrt the table "Syntax 17-6" *immediately* above
it
(2) shows the assignment of a $sformat system TASK to "length":
length
is never referenced and the use of a TASK in an assignment is not
explained.
<p>errata/36:
At the top of page 144 in P1364/D6 (11/30/01)
Line 4 reads:
Its occurrence can be recognized by using the event control
syntax described in
REPLACE WITH : "described in 9.7.2"
-- ************************************************************************** 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:46 PDT
and
sponsored by Boyd Technology, Inc.