Fri Mar 7 22:36:15 2003 PST

64 ETF PASSED ISSUES

ReleaseMeaning
2001aIssue against 1364-2001 First Edition
2001bIssue against 1364-2001 Second Edition (Possibly also issue in First Edition)
2001a, 2001bIssue against both 1364-2001 First and Second Editions (i.e. errata partial fix in 2001b, but more changes required)

ISSUE Release Synopsis Fix
20 2001b: A.2.8, 2.8.2, 9.8.1-2, 10.2.1, 10.3.1
A.2.8 should prevent all variable declaration assignments in named blocks

REPLACE the following BNF rules of section A.2.8:

 
     block_item_declaration ::=
         { attribute_instance } block_reg_declaration
       | { attribute_instance } event_declaration
       | { attribute_instance } integer_declaration
       | { attribute_instance } local_parameter_declaration
       | { attribute_instance } parameter_declaration
       | { attribute_instance } real_declaration
       | { attribute_instance } realtime_declaration
       | { attribute_instance } time_declaration
 
     block_reg_declaration ::=
         "reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"
 
     list_of_block_variable_identifiers ::=
         block_variable_type { "," block_variable_type }
 
     block_variable_type ::=
         variable_identifier
       | variable_identifier dimension { dimension }


WITH the following new rules for section A.2.8:

block_item_declaration ::=
    {attribute_instance} "reg" ["signed"] [range] list_of_block_variable_identifiers ";"
  | {attribute_instance} "integer"  list_of_block_variable_identifiers ";"
  | {attribute_instance} "time"     list_of_block_variable_identifiers ";"
  | {attribute_instance} "real"     list_of_block_real_identifiers ";"
  | {attribute_instance} "realtime" list_of_block_real_identifiers ";"
  | {attribute_instance} event_declaration
  | {attribute_instance} local_parameter_declaration
  | {attribute_instance} parameter_declaration

list_of_block_variable_identifiers ::=
    block_variable_type { "," block_variable_type }
  
list_of_block_real_identifiers ::=
    block_real_type     { "," block_real_type }
  
block_variable_type ::= variable_identifier { dimension }
block_real_type ::=     real_identifier     { dimension }


These notations are not part of the proposal and should not
be included in the updated section A.2.8.

Note: Syntax items that appear in "quotes" should be
interpreted as being in BOLD font.

These same updates should also be made to the following
syntax boxes which appear within IEEE 1364-2001:

1. Section 2.8.2, Syntax 2-7: The rule for "block_item_declaration"
should be updated as proposed above.

2. Section 9.8.1, Syntax 9-13: The rule for "block_item_declaration"
should be updated as proposed above.

3. Section 9.8.2, Syntax 9-14: The rule for "block_item_declaration"
should be updated as proposed above.

4. Section 10.2.1, Syntax 10-1: The rules for "block_item_declaration",
"block_reg_declaration", "list_of_block_variable_identifiers",
and "block_variable_type" should all be replaced with the
entire set of proposed rules above.

5. Section 10.3.1, Syntax 10-3: The rules for "block_item_declaration"
"block_reg_declaration", "list_of_block_variable_identifiers",
and "block_variable_type" should all be replaced with the
entire set of proposed rules above.

34 2001b: 17.2.3
17.2.3: "Formatting data to a string"

A. In 17.2.3, in Syntax 17-6, in the first production, change

"string_output_tasks_name"

to

"string_output_task_name"

************************************************************
Shalom's additions:

B. In the last line of Syntax 17-6, CHANGE

$sformat (output_reg ,format ,list_of_arguments );

TO

$sformat (output_reg ,format_string ,list_of_arguments );

**

C. Following Syntax 17-6, DELETE the following lines:

"The syntax for the string output system tasks is

$swrite (output_reg , list_of_arguments );
$sformat (output_reg , format_string , list_of_arguments );
length = $sformat (output_reg , format_string , list_of_arguments );"

**

D. Delete the following paragraph (which appears two
paragraphs after the preceding), as it also appears at the
end of 17.2.3:

"The variable output_reg is assigned using the Verilog's
string assignment to variable rules,as specified in 4.2.3."

**

E. CHANGE the last paragraph of 17.2.3 FROM

"The variable output_reg is assigned using the Verilog's
string assignment to variable rules, as specified in 4.2.3."

TO

"The variable output_reg is assigned using the
string assignment to variable rules, as specified in 4.2.3."

************************************************************
64 2001b: 9.3 (Syntax 9-3), A.6.2, A.6.3
A.6.2-3: variable_assignment BNF production is in wrong place

Move variable_assignment from A.6.3 to A.6.2.

Remove reference to A.6.3 from Syntax 9-3 (9.3).
65 2001b: A.2.7, 10.2.1 (Syntax 10-1)
error in task_declaration syntax


Modified by Shalom:

In Syntax 10-1 of 10.2.1 and in A.2.7,
change each of the four occurrences of

"statement"

to

"statement_or_null"

Note that this change applies ONLY to tasks and NOT to
functions, because functions MUST contain at least one
statement, an assignment to the function output.
67 2001b: A.6.5
A.6.5: "event_trigger" production in BNF does not allow array indexing


CHANGE

event_trigger ::=
-> hierarchical_event_identifier ;

TO

event_trigger ::=
"->" hierarchical_event_identifier {"[" expression "]"} ";"

in A.6.5 and Syntax 9-10.

70 2001b: 4.4.1 (Table 29)
Table 29: Logical operator (&& ||) sizing rules incorrect

The (&&, ||) operators should be removed from the 5th row,
and a new row should be inserted for them stating that their
operands are "self-determined" in the "Comments" column.

The modified 5th row, and the new row should look like the
following:

+-----------------------------+------------+--------------------------+
| Expression                  | Bit Length | Comments                 |
+-----------------------------+------------+--------------------------+
| i op j, where op is         |   1        | operands are sized to    |
|   === !== == != > >= < <=   |            | max(L(i), L(j)           |
+-----------------------------+------------+--------------------------+
| i op j, where op is         |   1        | All operands are         |
|   && ||                     |            | self-determined          |
+-----------------------------+------------+--------------------------+

75 2001b: 6 (Table 30), 9.2
Table 30 omits nested concatenations

1. In Table 30, CHANGE last lines in right-hand column of both
rows to say,

"Concatenation or nested concatenation of any of the above LHS".


2. Also, MOVE line

"Memory word"

after line

"Indexed part select of a vector reg, integer, or time variable".


3. In 9.2, para. 2, dashed item 5, CHANGE from:

"Concatenation of any of the above:
a concatenation of any of the
previous four forms can be specified, which effectively
partitions the result of the right-hand side expression and
assigns the partition parts, in order, to the various parts
of the concatenation."

TO:

"Concatenation or nested concatenation of any of the above:
a concatenation or nested concatenation of any of the
previous four forms can be specified, which effectively
partitions the result of the right-hand side expression and
assigns the partition parts, in order, to the various parts
of the concatenation or nested concatenation."


4. Widen right-hand column of table to be large enough to
prevent line wraps.

76 2001b: 4.1.14
4.1.14: unclear examples of illegal concatenations

In 4.1.14,

CHANGE FROM:

Another form of concatenation is the replication operation.
The first expression shall be a non-zero, non-X and non-Z
constant expression, the second expression follows the rules
for concatenations. This example replicates "w" 4 times.

{4{w}} // This is equivalent to {w, w, w, w}
a[31:0] = {1'b1, {0{1'b0}} }; //illegal. RHS becomes {1'b1,;
a[31:0] = {1'b1, {1'bz{1'b0}} }; //illegal. RHS becomes {1'b1,;
a[31:0] = {1'b1, {1'bx{1'b0}} }; //illegal. RHS becomes {1'b1,;


TO:


Another form of concatenation is the replication operation.
The first expression shall be a positive, non-X and non-Z
constant expression, the second expression follows the rules
for concatenations.

The following example replicates "w" 4 times.

{4{w}} // This is equivalent to {w, w, w, w} 


The following examples show illegal concatenations.

{   0{1'b0}}  //illegal 
{1'bz{1'b0}}  //illegal 
{1'bx{1'b0}}  //illegal 

77 2001b: 6 (Table 30)
Table 30: Last LHS line is not clear

************************************************************
Shalom: 2002-01-07

Propose to close this issue as being supreceded by # 75.
78 2001b: passim
passim: Inconsistent spelling of "bit-select" and "part-select"

Change all "bit select" to "bit-select".
Change all "part select" to "part-select".

Change all "bit and part selects" and "bit- and part-selects"
to "bit-selects and part-selects".

Change all "bit or part selects" and "bit- or part-selects"
to "bit-selects or part-selects".

Change all "bit or part select" and "bit- or part-select"
to "bit-select or part-select".
85 2001b: 9.7 (Syntax 9-8), A.6.5
A.6.5: repeat event_control grammar ambiguity

In A.6.5, after event_expression add the following
new nonterminal and definition --

procedural_timing_control ::=
delay_control
| event_control

and change the definition of
procedural_timing_control_statement from

   procedural_timing_control_statement ::=
         delay_or_event_control   statement_or_null


to

   procedural_timing_control_statement ::=
         procedural_timing_control   statement_or_null



And in Syntax 9-8 (9.7),

DELETE: delay_or_event_control
event_expression

ADD at the top the new definitions of
procedural_timing_control_statement and
procedural_timing_control.
87 2001b: 17.2.8
17.2.8: $readmem default start_addr should be lowest address


Changes based on
http://boydtechinc.com/btf/archive/btf_1998/0395.html

1. CHANGE 1st sentence in para. 7 FROM:

If no addressing information is specified within the system
task, and no address specifications appear within the data
file, then the default start address shall be the left-hand
address given in the declaration of the memory.

TO:

If no addressing information is specified within the system
task and no address specifications appear within the data
file, then the default start address shall be the lowest
address in the memory.


2. CHANGE 3rd sentence FROM:

If the start address is specified in the task without the
finish address, then loading shall start at the specified
start address and shall continue towards the right-hand
address given in the declaration of the memory.

TO:

If the start address is specified in the task without the
finish address, then loading shall start at the specified
start address and shall continue upward towards the highest
address in the memory.


3. CHANGE para. 8 FROM:

If both start and finish addresses are specified as
parameters to the task, then loading shall begin at the
start address and shall continue toward the finish address,
regardless of how the addresses are specified in the memory
declaration.

TO:

If both start and finish addresses are specified as
parameters to the task, then loading shall begin at the
start address and shall continue toward the finish address.
Note that if the start address is greater than the finish
address, then the address will be decremented between
consecutive loads rather than being incremented. Loading
shall continue to follow this direction even after an
address specification in the data file.


4. CHANGE para. 10 FROM:

A warning message shall be issued if the number of data
words in the file differs from the number of words in the
range implied by the start through finish addresses.

TO:

A warning message shall be issued if the number of data
words in the file differs from the number of words in the
range implied by the start through finish addresses and no
address specifications appear within the data file.

89 2001b: 2.8.1
2.8.1: Multiple Attribute Instances in BNF

Multiple attribute instances are OK.
Nested attributes are the subject of issue #218.

Change one of the example to show multiple instances:

In 2.8.1, Example 1 contains three examples of full_case, parallel_case:

(* full_case, parallel_case *)
(* full_case=1, parallel_case=1 *)
(* full_case, // no value assigned
parallel_case=1 *)

CHANGE the second from:

(* full_case=1, parallel_case=1 *)

TO:

(* full_case=1 *) (* parallel_case=1 *) // Multiple attribute instances also OK

(including the comment)
92 2001b: 17.10.2
17.10.2 should talk about leading plus sign

Add the following sentence after the second sentence of the
first paragraph of section 17.10.2:

"This string should not include the leading plus sign of
the command line argument."

************************************************************
Shalom:

1. That should be:

"This string shall not ..." instead of "should not".

Also:

2. In para. 2,

CHANGE: "as well as a leading 0 forms"
TO : "as well as leading 0 forms".


3. In para. 3, end of line 3,

CHANGE: "users plusarg_string"
TO : "user's plusarg string".


4. In para. 4, end of line 1,

CHANGE: "zero (0) padded"
TO: "zero-padded".

************************************************************
Shalom (added 2003-01-06):

CHANGE THE 3rd and 4th sentences in the first paragraph
FROM:

"If the string is found, the remainder of the string is
converted to the type specified in the user_string and the
resulting value stored in the variable provided. If a string
is found, the function returns a non-zero integer."

TO (incorporating wording from 17.10.1):

"The plusargs present on the command line are searched in
the order provided. If the prefix of one of the supplied
plusargs matches all characters in the provided string,
the function returns a non-zero integer,
the remainder of the string is
converted to the type specified in the user_string and the
resulting value is stored in the variable provided."

************************************************************

103 2001b: Index
Index missing

Return Index.

Work together with IEEE Editor.

Index must refer to Subclause #, not page #.

Note: there may not be time to add index references to text
added in 2001c.
109 2001b: 10.3.5
10.3.5: redundant restriction on system functions

In 10.3.5, in the 2nd constraint, delete the sentence "System functions shall not be invoked."
115 2001b: 9.8
9.8: "block statement" definition

In the first sentence of 9.8, delete

"two or more"
119 2001b: 2.6.3 (Table 1), 17.1.1.1 (Table 66)
2.6.3 (Table 1): Octal escape sequences

In Table 1 of section 2.6.3


REPLACE:

A character specified in 1-3 octal digits (0<= d <= 7)

WITH:

A character specified in 1-3 octal digits (0 <= d <= 7).
If less than three characters are used, the following
character must not be an octal digit. Implementations
may issue an error if the character represented is
greater than \199.

***********************
Shalom's addition:

Same change in Table 66 in 17.1.1.1
***********************

123 2001b: A.8.4, 4.3 (Syntax 4-2)
identifier and indexing syntax

In 181, we passed a change to replace the existing
alternatives of hierarchical_identifier in the primary
production with the following:

hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]

If this change is accepted,
then presumably the same change should be made to
net_lvalue and variable_lvalue modifying the already
passed fixes to 53.

CHANGE from (after the fixes in #53):

net_lvalue ::=
hierarchical_net_identifier {'['constant_expression']'}
['['constant_range_expression']']
| '{' net_lvalue { ',' net_lvalue } '}'

variable_lvalue ::=
hierarchical_variable_identifier {'['expression']'}
['['range_expression']']
| '{' variable_lvalue { ',' variable_lvalue } '}'


TO:


net_lvalue ::=
hierarchical_net_identifier [{'['constant_expression']'}
'['constant_range_expression']']
| '{' net_lvalue { ',' net_lvalue } '}'

variable_lvalue ::=
hierarchical_variable_identifier [{'['expression']'}
'['range_expression']']
| '{' variable_lvalue { ',' variable_lvalue } '}'

************************************************************
129 2001a,b: passim
unordered list dashes (em dash) did not print in 2001a

Make sure all dashed lists come out in PDF.

Find dashed lists which still did not come out in 2001b,
and fix them as well.

************************************************************
Update by Shalom:

See issue #169.

Apparently problem occurred with TimesNewRoman fonts.
The "em dashes" did not print in IEEE.
When these are converted to Times font, which appears
almost identical, it comes out OK.

On my Unix FrameMaker, TimesNewRoman gets converted to
Times anyway, so it still comes out OK.

However, in 2001b, IEEE did not fix all the places.

In particular, some of the NOTEs are still in TimesNewRoman,
so they did not come out even in 2001b.

The solution is to convert all paragraphs with "em dashes"
in TimesNewRoman to Times.

************************************************************

133 2001b: 4.1.2
Table 12: Precedence rules for operators

Change subclause name
FROM: "Binary operator precedence"
TO : "Operator precedence".


Change the first paragraph
FROM:
"The precedence order of binary operators and the
conditional operator (?:) is shown in Table 12.
The Verilog HDL has two equality operators.
They are discussed in 4.1.8."

TO:
"The precedence order of the Verilog operators
is shown in Table 12."


Change Table 12 as follows:

Change top row
FROM: "+ - ! ~ (unary)"
TO : "Unary + - ! ~ & ~& | ~| ^ ~^ ^~"

Change rows 8-10
FROM:
& ~&
^ ^~ ~^
| ~|

TO:
& (binary)
^ ^~ ~^ (binary)
| (binary)

In last row (conditional operator), delete "Lowest precedence".

Add new row at bottom: "{} {{}} Lowest precedence".

REMOVE: last line of Table-10 and last line of Table-9
and Section 4.1.15
136 2001b: 12.4 (Syntax 12-7), 13.2.1 (Syntax 13-2), 13.3.1.5 (Syntax 13-8), A.1.1, A.1.2, A.9.4
Annex A et al: BNF: redundant [] around {}

Remove redundant square brackets as follows:

1. In Syntax 13-2 (13.2.1) and A.1.1, CHANGE:

library_declaration ::= 
library library_identifier file_path_spec [ { , file_path_spec } ]
    [ -incdir file_path_spec [ { , file_path_spec } ] ;  

TO:

library_declaration ::= 
library library_identifier file_path_spec { , file_path_spec }
    [ -incdir file_path_spec { , file_path_spec } ] ;  


Note that a right square bracket was missing at the end to
close the -incdir option. Now it is there.


2. In Syntax 13-8 (13.3.1.5) and A.1.2, CHANGE:

liblist_clause ::= liblist [{library_identifier}]  

TO:

liblist_clause ::= liblist { library_identifier }



3. In Syntax 12-7 (12.4), CHANGE:
(Note: it is already correct in A.9.3)

escaped_hierarchical_identifier ::= (From Annex A - A.9.3)
  escaped_hierarchical_branch 
    [ { .simple_hierarchical_branch | .escaped_hierarchical_branch } ]

TO:

escaped_hierarchical_identifier ::= (From Annex A - A.9.3)
  escaped_hierarchical_branch 
    { .simple_hierarchical_branch | .escaped_hierarchical_branch }



4. In Syntax 12-7 (12.4) and A.9.4, CHANGE:

simple_hierarchical_branch ::=  
          simple_identifier [ [ unsigned_number ] ]  
                [ { .simple_identifier [ [ unsigned_number ] ] } ]  

escaped_hierarchical_branch ::=  
          escaped_identifier [ [ unsigned_number ] ]  
                [ { .escaped_identifier [ [ unsigned_number ] ] } ]  

TO:

simple_hierarchical_branch ::=  
          simple_identifier  [ [ unsigned_number ] ]  
                { .simple_identifier  [ [ unsigned_number ] ] }

escaped_hierarchical_branch ::=  
          escaped_identifier [ [ unsigned_number ] ]  
                { .escaped_identifier [ [ unsigned_number ] ] }

137 2001b
Fwd: IEEE Std 1364-2001, 19.2 and Annex B -- 'none' keyword

Propose that this is not a bug and that we close the
issue.
138 2001b
IEEE Std 1364-2001, Syntax 19-2 -- formal_argument_identifier

Propose this issue be closed as the issue raised here
is also raised in issue #139, along with a few other
issues in the same section.
140 2001b
Section 4.1.5: Definition of power operator result type

Part I:

REPLACE (3rd paragraph of 4.1.5):
The result of the power operator shall be real if either operand is a
real, integer or signed. If both operands are unsigned then the
result shall be unsigned. The result of the power operator is
unspecified if the first operand is zero and the second operand is
non-positive, or if the first operand is negative and the second
operand is not an integral value.

WITH (new 3rd and 4th paragraphs of 4.1.5):
If either operand of the power operator is real, then the result type
shall be real. The result value is undefined if the first operand
is zero and the second operand is non-positive, or if the first operand
is negative and the second operand is not an integral value.

If neither operand of the power operator is real, then the result type
shall be determined as outlined in 4.4.1 and 4.5.1, with the second
operand treated as self-determined. In this case, the power operator
shall always interpret the second operand as an unsigned value, and the
result value shall be 1 if both operands are zero.

------------------------------------------------------------------------

Part II:

REPLACE (Title of Table 15 in 4.1.5):
Examples of modulus operators

WITH (new Title of Table 15 in 4.1.5):
Examples of modulus and power operators

------------------------------------------------------------------------

Part III:

REPLACE (The sentence immediately prior to Table 15):
Table 15 gives examples of modulus operations.

WITH
Table 15 gives examples of some modulus and power operations.

------------------------------------------------------------------------

Part IV:

REPLACE (heading of first column in Table 15):
Modulus expression

WITH (new heading of first column in Table 15):
Expression

------------------------------------------------------------------------

Part V:

Append the following power operator examples to Table 15:

   Expression         Result       Comments
   3**2               9            3*3
   2**3               8            2*2*2, same result as 1<<3
   2**0               1            By definition, and same result as 1<<0
   2**-3'sb1          128          -3'sb1 treated as unsigned 7, same as 1<<-3'sb1
   2.0**-3'sb1        0.5          -3'sb1 coerced to -1.0, giving real reciprocal
   0.0**-1            Undefined    Division by zero is undefined
   9**0.5             3.0          Real square root
   9.0**(1/2)         1.0          Integer division truncates exponent to zero
   -9.0**0.5          Undefined    Square root of negative number is undefined
   -3.0**2.0          9.0          Defined, because real 2.0 is still integral value
   2**(-3'so4/3'so2)  64           Exponent is -3'so2, but is interpreted as 3'o6

145 2001b: 19.2 (Syntax 19-1)
19.2: Syntax 19-1 defines net_type differently than A.2.2.1

In Syntax 19-1 of section 19.2 change both occurrences of

"net_type"

to

"default_nettype_value"



146 2001b: 3.9
3.9: poor cross-reference to $time section


Change 17 to 17.7.1

149 2001b: 2.7.4
2.7.4: System tasks and functions

Proposal:

1) Change the first bullet following paragraph 3 of
section/clause 2.7.4:

REPLACE:
- A standard set of $identifier system tasks and
functions, as defined in Clauses 17 and 19.

WITH:
- A standard set of $identifier system tasks and
functions, as defined in Clauses 17 and 18.

************************************************************
Shalom: The above was already handled in issue #27.
************************************************************

2) Change the second sentence of paragraph 4 of
section/clause 2.7.4:

REPLACE:
The system tasks and functions described in
Clause 17 are part of this standard.

WITH:
The system tasks and functions described in
Clauses 17 and 18 are part of this standard.
153 2001b: 12.3.3 (Syntax 12-6), A.2.1.2
12.3.3, A.2.1.2: output_declaration is ambiguous

Brad's proposal looks good:

Delete the 2nd and 4th alternatives of the output_declaration BNF rule
of section A.2.1.2.

REPLACE:
output_declaration ::=
"output" [ net_type ] [ "signed" ] [ range ] list_of_port_identifiers
| "output" [ "reg" ] [ "signed" ] [ range ] list_of_port_identifiers
| "output" "reg" [ "signed" ] [ range ] list_of_variable_port_identifiers
| "output" [ output_variable_type ] list_of_port_identifiers
| "output" output_variable_type list_of_variable_port_identifiers

WITH:
output_declaration ::=
"output" [ net_type ] [ "signed" ] [ range ] list_of_port_identifiers
| "output" "reg" [ "signed" ] [ range ] list_of_variable_port_identifiers
| "output" output_variable_type list_of_variable_port_identifiers

Note: Quoted items should be interpreted as being in BOLD font.
154 2001b: 2.8.2 (Syntax 2-6), 12.1 (Syntax 12-1), 12.1.3 (Syntax 12-3), A.1.5
A.1.5: attribute ambiguity in non_port_module_items

REPLACE the following two BNF rules of section A.1.5
(Also in Syntax 2-6 (2.8.2), Syntax 12-1 (12.1),
and Syntax 12-3 (12.1.3):

module_item ::=
module_or_generate_item
| port_declaration ";"
| { attribute_instance } generated_instantiation
| { attribute_instance } local_parameter_declaration
| { attribute_instance } parameter_declaration
| { attribute_instance } specify_block
| { attribute_instance } specparam_declaration

non_port_module_item ::=
{ attribute_instance } generated_instantiation
| { attribute_instance } local_parameter_declaration
| { attribute_instance } module_or_generate_item
| { attribute_instance } parameter_declaration
| { attribute_instance } specify_block
| { attribute_instance } specparam_declaration

WITH:
module_item ::=
| port_declaration ";"
| non_port_module_item

non_port_module_item ::=
module_or_generate_item
| { attribute_instance } generated_instantiation
| { attribute_instance } local_parameter_declaration
| { attribute_instance } parameter_declaration
| { attribute_instance } specify_block
| { attribute_instance } specparam_declaration


NOTE: Items enclosed in "" should be interpreted as being in BOLD font.
156 2001b: 10.3.1, A.2.6
10.3.1,A.2.6:In function, block_item_declaration is optional

In Syntax 10-3 (10.3.1) and in A.2.6,
in BNF of function_declaration with function_port_list,

CHANGE:

"block_item_declaration { block_item_declaration }"

TO:

"{ block_item_declaration }".
160 2001a,b
PDF bookmarks


Make PDF bookmarks for all levels of
sub-clauses in all clauses.

161 2001a,b: passim
hyperlink cross-references


1. Fix all unresolved cross-references.

2. Find (as much as possible) and fix references which are
just text and change them into FrameMaker cross-references
with hyperlinks.

166 2001b: 1.4
1.4: "Clause 2" missing clause title


In 1.4, change Clause 2 reference to:

"Clause 2--Lexical conventions: This clause
describes the lexical tokens used in Verilog HDL source
text and their conventions. It describes how to specify
and interpret the lexical tokens."

168 2001b: 12.3.2
12.3.2: Bad grammar

In the last sentence in section 12.3.2, change

"Use of named port connections shall not be
used for..."

to

"Named port connections shall not be used for ..."


and in the first sentence in the same paragraph
add commas to

"The first type of module port with only a
port_expression is an implicit port."

as follows:

"The first type of module port, with only a
port_expression, is an implicit port."
173 2001b: 1.4, 2.5.1, 3.1, 7.10.1, 7.10.2, passim
misc typos

The first typo on Clause 2 is covered by issue 166, so
I deleted it from this proposal--Karen 2/10/03
*******************************************************

Section 1.4: Paragraph beginning "Clause 21": The title should end with colon. Next sentence should begin on same line.

**********************************************************
This piece of the proposal is covered by 116, so I deleted
it from this proposal--Karen 2/10/03
**********************************************************

Section 3.1: End of paragraph. Change ".." to "." .

Section 7.10.1, last sentence: Change "pull 1" to "pull1" and change both occurrences of "strong 0" to "strong0", and change all three to bold Times, as shown at beginning of 7.9.
************************************************************
Shalom: Note - the format of strength indications is
inconsistent elsewhere as well.
************************************************************

Section 7.10.2, 1st paragraph, 2nd bullet: In "strength1" and "strength0", change the "0" and "1" to Times font, not fixed font, as in bullets 3 and 4.

Entire document: Change all Clause titles to Helvetica 14 point including the number.
176 2001b, 12.1.3.2
12.1.3.2, Example 5: wrong generate name

In section 12.1.3.2 example 5: 

Change the for loop condition  on the first line after the 
generate <bold generate> from:

 (i=0; i<SIZE+1; i=i+1) to:
 (i=0; i<SIZE; i=i+1)  

On the next line in the comment change:

B1[i].N1[i]  to:
B1[i].N1   

179 2001b, 12.3.3
12.3.3 Port declarations

Change the first sentence in 12.3.3

"Each port_expression
in the list of ports for the module declaration shall also be
declared
in the body of the module as one of the following port declarations:
input, output, or inout (bidirectional)."

to
"Each port_identifier in a port_expression
in the list of ports for the module declaration shall also be
declared
in the body of the module as one of the following port declarations:
input, output, or inout (bidirectional)."
181 2001b: 4.3 (Syntax 4-2), 9.2.1 (Syntax 9-1), 9.2.2 (Syntax 9-2), 9.2.3 (Syntax 9-3), A.8.4, A.8.5
4.3, 9.2.1-3, A.8.4-5: 12 productions better expressed with 3

In A.8.4 and Syntax 4-2

REPLACE:
bnf production for primary

WITH

primary ::=
number
| hierarchical_identifier { [ expression ] } [ [ range_expression ] ]
| concatenation
| multiple_concatentation
| function_call
| system_function_call
| constant_function_call
| ( mintypmax_expression )
182 2001b, 9.7 (Syntax 9-8), 9.7.7 (Syntax 9-12), A.6.5
Syntax 9-8: event_control

In A.6.5 and Syntax 9-8 change

event_control ::= @ event_identifier
| @ ( event_expression )
| @ *
| @ ( * )

event_expression ::= expression
| hierarchical_identifier
| posedge expression
| negedge expression
| event_expression or event_expression
| event_expression , event_expression

to

event_control ::= @ hierarchical_event_identifier
| @ ( event_expression )
| @ *
| @ ( * )

event_expression ::= expression
| posedge expression
| negedge expression
| event_expression or event_expression
| event_expression , event_expression

193 2001b: 3.2.1 (Syntax 3-1), 9.7.3 (Syntax 9-9), A.2.3
3.2.1, 9.7.3, A.2.3: simplification of list BNFs

A. In Syntax 9-9 and A.2.3,

CHANGE

list_of_event_identifiers ::= 
  event_identifier [ dimension { dimension }] 
    { , event_identifier [ dimension { dimension }] } 


TO

list_of_event_identifiers ::= 
  event_identifier { dimension }
    { , event_identifier { dimension } } 



B. In Syntax 3-1 and A.2.3,

CHANGE

list_of_net_identifiers ::= 
  net_identifier [ dimension { dimension }] 
    { , net_identifier [ dimension { dimension }] } 


TO

list_of_net_identifiers ::= 
  net_identifier { dimension }
    { , net_identifier { dimension } }

194 2001b: 2.8 (Syntax 2-3), A.9.1
2.8, A.9.1: simplify attr_spec BNF

Change --

attr_spec ::= attr_name = constant_expression
| attr_name

to

attr_spec ::= attr_name [ = constant_expression ]

196 2001b: 8.6 (Syntax 8-2)
8.6 -- udp_instantiation BNF different in 8.6 than in Annex A

In Syntax 8-2, remove "[attribute_instance]"
from udp_instantiation, making it the same
as in Annex A.5.4.

udp_instantiation ::= udp_identifier
[ drive_strength ] [ delay2 ]
udp_instance { , udp_instance } ';'

200 2001b: 7.1 (Syntax 7-1), 8.6 (Syntax 8-2), 12.1.2 (Syntax 12-2), A.3.1, A.4.1, A.5.4, A.9.3
A.3.1, A.4.1, A.5.4, A.9.3 et al: extra [range]


1. In A.9.3, CHANGE

gate_instance_identifier ::= arrayed_identifier
udp_instance_identifier ::= arrayed_identifier
module_instance_identifier ::= arrayed_identifier

TO

gate_instance_identifier ::= identifier
udp_instance_identifier ::= identifier
module_instance_identifier ::= identifier

2. In A.9.3, DELETE

arrayed_identifier
escaped_arrayed_identifier
simple_arrayed_identifier

3. NO CHANGE TO

name_of_gate_instance ::= gate_instance_identifier [ range ]
name_of_udp_instance ::= udp_instance_identifier [ range ]
name_of_instance ::= module_instance_identifier [ range ]

216 2001b: 9.5
9.5: when is case default executed

After the sentence

"The case item expressions shall be evaluated
and compared in the exact order in which they
are given."

insert the following sentence

"If there is a default case item, it is ignored
during this linear search."


218 2001b, 2.8
Nested attributes should be prohibited

Append the following paragraph to the end
of section 2.8 (before section 2.8.1) --

"Nesting of attribute instances is disallowed.
It shall be illegal to specify the value of
an attribute with a constant expression that
contains an attribute instance."
219 2001b: 17.9.3
17.9.3: wrong bolding in C code

In section 17.9.3 remove all bolding from the C code,
in particular from each occurrence of 'if', 'else', 'end',
'while', and 'for'.
221 2001b
passim: right-hand and left-hand misspelled

Throughout the document change "right hand" and "righthand"
to "right-hand" and change "left hand" and "lefthand" to
"left-hand". Specifically, in 3.11.1, 9.7.5, 12.1.3.2
change "right hand" to "right-hand", in 3.3.1 change
"righthand" to "right-hand", in 9.7.5, 16.6 change
"left hand" to "left-hand". In C.2 change "lefthand"
to "left-hand".
224 2001b: 10.2 (Syntax 10-1), A.2.7
10.2, A.2.7: tf port declarations

In A.2.7 and in Syntax 10-1 of 10.2, delete
the square brackets from each occurrence of

[ task_port_type ]

228 2001b: 4.2.1
4.2.1: indexed part-select with width-expression of -5


1. Legal values for the width expressions should be a
semantic restriction. Specifically, after the sentence,
"The width_expr shall be a constant expression.",
add the following:

"The value of the width_expr shall be a positive integer."


2. Change the Examples preceding Example 1,
from "reg [31:0] big_vect;" to
"dword[8*sel +:8] = big_vect[7:0]; // Replace the byte selected."

with the following:

reg [31: 0] big_vect;
reg [0 :31] little_vect;
reg [63: 0] dword;
integer sel;

big_vect[ 0 +: 8]    // == big_vect[ 7 : 0]
big_vect[15 -: 8]    // == big_vect[15 : 8]

little_vect[ 0 +: 8] // == little_vect[0 : 7]
little_vect[15 -: 8] // == little_vect[8 :15]

dword[8*sel +: 8]    // variable part-select with fixed width


("reg" and "integer" keywords in bold)

229 2001b: 9.6 (Syntax 9-7), 9.8.1 (Syntax 9-13), A.6.3, A.6.8
A.6.3, A.6.8: some function_statement should be function_statement_or_null


CHANGE "function_statement" to "function_statement_or_null"
in following places:

function_loop_statement (Syntax 9-7 (9.6), A.6.8)
function_seq_block (Syntax 9-13 (9.8.1), A.6.3)

231 2001b: A.6.2, A.6.4
A.6.2: function_statement_or_null should be in A.6.4


Move function_statement_or_null from A.6.2 to A.6.4.

232 2001b: 2.7.4 (Syntax 2-2), A.6.9
Syntax 2-2, A.6.9: system_task_enable with null arguments


In Syntax 2-2 (2.7.4) and A.6.9, CHANGE

system_task_enable ::=
system_task_identifier [ ( expression { , expression } ) ] ;

TO:

system_task_enable ::=
system_task_identifier [([expression] {,[expression]})] ;

236 2001b: 6 (Table 30)
Table 30: Last line should be Concatenation of any of the above


Close this issue as being superceded by #75.

238 2001b: 12.1 (Syntax 12-1), 12.3.1 (Syntax 12-5), 14.2.2 (Syntax 14-3), A.1.4, A.7.3
A.1.4, A.7.3: Should range_expression be constant_range_expression?

REPLACE:

port_reference ::= (A.1.4, Syntax 12-1, 12-5)
  port_identifier 
| port_identifier [ constant_expression ] 
| port_identifier [ range_expression ] 

specify_input_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  input_identifier 
| input_identifier [ constant_expression ] 
| input_identifier [ range_expression ]  

specify_output_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  output_identifier 
| output_identifier [ constant_expression ] 
| output_identifier [ range_expression ]  

WITH:
              
port_reference ::= (A.1.4, Syntax 12-1, 12-5)
  port_identifier [ [ constant_range_expression ] ] 

specify_input_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  input_identifier [ [ constant_range_expression ] ] 

specify_output_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  output_identifier [ [ constant_range_expression ] ] 

239 2001b: 1.4
1.4: "veriuser.h" and "vpi_user.h" reversed


In 1.4, change Annex F and G references to :
"
Annex F--veriuser.h:This normative annex provides a
listing of the contents of the veriuser.h file.

Annex G--vpi_user.h:This normative annex provides a
listing of the contents of the vpi_user.h file."

243 2001b: 10.3.1
10.3.1: Call functions "reentrant", not "recursive"


In 10.3.1, change

"The keyword automatic declares a recursive function with
all the function declarations allocated dynamically for
each recursive call."

TO:

"The keyword automatic declares an automatic function that
is reentrant with all the function declarations allocated
dynamically for each concurrent function call."

249 2001b: 3.11.3
3.11.3: needless reference to 1364-1995


In 3.11.3, para. 2, change the following sentence FROM:

"Originally permitted only in specify blocks (see Section
14), with this revision specify parameters (also called
specparams) are now permitted both within the specify block
and in the main module body."

TO:

"Specify parameters (also called specparams) are permitted
both within the specify block (see Clause 14) and in the
main module body."

260 2001b: 17.1.1, 17.1.1.2
17.1.1: typo, missing comma

In 17.1.1, para. 4, 2nd item:

CHANGE

"character, with the exception of %m that"

TO

"character, with the exception of %m or %%, that"


In 17.1.1.2, para. 1:

CHANGE

"character (except %m)"

TO

"character (except %m or %%)"

262 2001b: 13.1
Formatting problem in example in Clause 13.1


Fix first example in 13.1 as follows:

              The first column should look like this:

              file top.v
              module top();
              adder a1 (...) ;
              adder a2 (...) ;
              endmodule

              The second column should look like this:

              file adder.v
              module adder(...);
              //rtl adder description
              ...
              endmodule

              The third column should look like this:

              file adder.vg
              module adder(...);
              //gate-level adder description
              ...
              endmodule


The keywords 'module' and 'endmodule' should be in bold
keyword font.

263 2001b: 17.9.1, 17.9.2
17.9: incorrect bolding in BNFs


In Syntax 17-17 and 17-18,
remove bolding from arguments and square brackets.

Remove semicolons

264 2001b: 3.7.4, 3.8, 4.1.12, 4.2.1, 15.6, 27.14
misc. editorial boo-boos


1. 27.14: In Table 214, column 3, rows 2 and 4, right
brackets came out overstriking Z. EDITOR TO FIX.


2. 3.8: In last sentence, CHANGE "needs" TO "need".


3. 3.7.4: At end of para. 1, DELETE period after
"See Clause 7".


4. 15.6: In 2nd line of Example 2, "the" should not be bold.
CHANGE to regular font.


5. 4.1.12: In line 8 of para. 1, CHANGE "unknown or high
impedence" TO "x or z".


6. 4.2.1: End of para. 4: DELETE the sentence:
"If the part-select is out of the address bounds or the
part-select is x or z,
then the value returned by the reference shall be x".

In para. 6, make the sentence that starts
"Part-selects that address a range of bits ..."
begin a new paragraph.

In that same sentence, CHANGE "Part-selects" to
"Part-selects of any type".

267 2001b: 2.5.1
2.5.1: Integer constants


In 2.5.1, para. 2,
CHANGE

"The second form specifies a size constant"

TO

"The second form specifies a based constant"
("based constant" italicized)

269 2001b
more keyword bolding


Make the following keywords bold:



Table 31 - all
Table 37 - all
27.3.2 paragraph 7, "force" and "release"
D.1, last sentence, "infinite"

Hosted by Boyd Technology