Tue Oct 4 01:00:37 2005 PST

290 VSG 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 State Release Synopsis Fix
3 lrmdraft
2001b: 10.3.5
10.3.5: Inconsistent restrictions on system tasks in constant functions


Delete 5th bullet:

- The only system task that may be invoked is $display,
and it shall be ignored when invoked at elaboration time.

If there is a another issue regarding constant functions,
a new erratum entry should be filed.

5 lrmdraft
2001a, 2001b, 3.5
Bad description of implicit nets created from continuous assignments

This was submitted to IEEE in Oct, 2001
Passed 10/7/02:

Add to 3.5 the following additional item:

If an identifier appears on the left-hand side of a continuous
assignment statement, and that identifier has not been declared
previously, an implicit scalar net declaration of the default net
type is assumed.

6 lrmdraft
2001a,b: 12.1.3
12.1.3 : Unclear parameter restriction in generated instantation

In 12.1.3, paragraph 7:

CHANGE

"Parameter redefinition using by the ordered or named
parameter = value assignment or defparam statements can also
be declared within the generate scope."

TO

"Parameters may be redefined using the defparam statements
(12.2.1) or module instance parameter value assignments (12.2.2)
within the generate scope."
8 lrmdraft
2001a 2001b, 4.1.7
Incorrect zero extend rules for relational and equality operators

Submitted to IEEE in October 2001:
Changes incorporated into 2001a:
Passed 10/7/02:

BTF-PR8: Section 4.1.7 - 3rd & 2nd to last paragraphs
REPLACE: When two operands of unequal bit lengths are used, the
smaller operand shall be zero filled on
the most significant bit side to extend to the size of the larger
operand.

WITH: When two operands of unequal bit lengths are used and one
or both of the operands is unsigned, the
smaller operand shall be zero filled on the most significant bit
side to extend to the size of the larger
operand.

REPLACE: When both operands of a relational expression are signed
integral operands (an integer, or a
unsized, unbased integer) then the expression shall be
interpreted as a comparison between signed values.

WITH: When both operands of a relational expression are
signed integral operands (an integer, a signed reg
data type, or an unsized, unbased integer) then the expression
shall be interpreted as a comparison between
signed values.

Additional changes passed for 2001b 10/7/2002:

REPLACE: When both operands of a relational expression are
signed integral operands (an integer, a signed reg
data type, or an unsized, unbased integer) then the expression
shall be interpreted as a comparison between
signed values.

WITH: When both operands of a relational expression are
signed operands, then the expression
shall be interpreted as a comparison between
signed values.


9 lrmdraft
2001b: 4.6
Please define truncation rules

Add a new 4.6 subsection with wording as follows:

4.6 Assignments and truncation

If the width of the right-hand side (RHS) expression is
larger than the width of the left-hand side (LHS) in an
assignment, the MSBs of the RHS expression will always
be discarded to match the size of the LHS. Implementations
are not required to warn or report any errors related to
assignment size-mismatch or truncation. Truncating the
sign bit of a signed expression may change the sign of the
result.

Example:
    reg        [5:0] a;  
    reg signed [4:0] b;
 
    initial begin
      a = 8'hff; // After the assignment, a = 6'h3f
      b = 8'hff; // After the assignment, b = 5'h1f
    end
 
 Example:
    reg        [0:5] a;  
    reg signed [0:4] b, c;  

    initial begin
      a = 8'sh8f; // After the assignment, a = 6'h0f
      b = 8'sh8f; // After the assignment, b = 5'h0f
      c = -113;   // After the assignment, c = 15
    end
    // 1000_1111 = (-'h71 = -113) truncates to ('h0F = 15)
 
 Example:
    reg        [7:0] a;
    reg signed [7:0] b;  
    reg signed [5:0] c, d;

    initial begin
      a = 8'hff;
      c = a;      // After the assignment, c = 6'h3f
      b = -113;
      d = b;      // After the assignment, d = 6'h0f
    end

10 lrmdraft
2001a, 7.1.6
typo p.84

Sent to IEEE in Oct 2001:
Fixed 10/7/2002:

Section 7.1.6, Example 3 (top of p.84):
REPLACE:
input [15:0] in;

WITH:
input [15:0] busin;


11 lrmdraft
2001a 2001b, 12.1.3.4
12.1.3.4 Example 8: typos and other problems

Passed 10/7/02:
Sent to IEEE in October 2001:
NOTE: This was not correctly fixed in 2001b. Still needs entire
example to be replaced.

Section 12.1.3.4 - Example 8 (Replace the entire example with the following):
module dimm (adr, ba, rasx, casx, csx, wex, dqm, cke, data, clk,
dev_id);
  parameter [31:0] MEM_SIZE  = 8,  // in mbytes
                   MEM_WIDTH = 16;
  input [10:0] adr;
  input        ba;
  input        rasx, casx, csx, wex;
  input [ 7:0] dqm;
  input        cke;
  inout [63:0] data;
  input        clk;
  input [ 4:0] dev_id;

  genvar       i;

  generate
    case ({MEM_SIZE, MEM_WIDTH})
      {32'd8, 32'd16}: // 8Meg x 16 bits wide.
      begin
        // The generated instance names are word[3].p, word[2].p,
        // word[1].p, word[0].p, and the task read_mem
        for (i=0; i<4; i=i+1) begin:word
          sms_16b216t0 p (.clk(clk), .csb(csx), .cke(cke),
              .ba(ba[0]), .addr(adr[10:0]), .rasb(rasx), 
              .casb(casx), .web(wex), .udqm(dqm[2*i+1]), 
              .ldqm(dqm[2*i]), .dqi(data[15+16*i:16*i]), 
              .dev_id(dev_id[4:0]));
        end
        task read_mem;
          input  [31:0] address;
          output [63:0] data;
          begin
            word[3].p.read_mem(address, data[63:48]);
            word[2].p.read_mem(address, data[47:32]);
            word[1].p.read_mem(address, data[31:16]);
            word[0].p.read_mem(address, data[15:0]);
          end
        endtask
      end
      
      {32'd16, 32'd8}: // 16Meg x 8 bits wide.
        begin
          // The generated instance names are byte[7].p,
	  byte[6].p,
          // byte[5].p, byte[4].p, byte[3].p, byte[2].p,
	  byte[1].p,
          // byte[0].p and the task read_mem
          for (i=0; i<8; i=i+1) begin:byte
            sms_16b208t0 p (.clk(clk), .csb(csx), .cke(cke),
                .ba(ba[0]), .addr(adr[10:0]), .rasb(rasx), 
                .casb(casx), .web(wex), .dqm(dqm[i]), 
                .dqi(data[7+8*i:8*i]),.dev_id(dev_id[4:0]));
          end
          task read_mem;
            input  [31:0] address;
            output [63:0] data;
            begin
              byte[7].p.read_mem(address, data[63:56]);
              byte[6].p.read_mem(address, data[55:48]);
              byte[5].p.read_mem(address, data[47:40]);
              byte[4].p.read_mem(address, data[39:32]);
              byte[3].p.read_mem(address, data[31:24]);
              byte[2].p.read_mem(address, data[23:16]);
              byte[1].p.read_mem(address, data[15:8]);
              byte[0].p.read_mem(address, data[7:0]);
            end
          endtask
        end
      // Other memory cases ...
    endcase
  endgenerate
endmodule

12 lrmdraft
2001b, 12.1 (Syntax 12-1), A.1.5, A.2.3, A.2.4, A.9.3
hierarchical parameter identifier

The BNF of a defparam statement is:

parameter_override ::=
defparam list_of_param_assignments ;

list_of_param_assignments ::=
param_assignment {, param_assignment }

param_assignment ::=
parameter_identifier = constant_expression

The problem is that this does not allow defparam with
hierarchical parameter identifiers.

The proposed fix is:

1. Change parameter_override to

parameter_override ::=
defparam list_of_defparam_assignments ;

2. Add

list_of_defparam_assignments ::=
defparam_assignment { ',' defparam_assignment }

defparam_assignment ::=
hierarchical_parameter_identifier = constant_expression

hierarchical_parameter_identifier ::=
hierarchical_identifier

This affects Syntax 12-1 in 12.1, A.1.5,
A.2.3 (list_of_defparam_assignments will go there),
A.2.4 (defparam_assignment will go there), and
A.9.3 (hierarchical_parameter_identifier will go there).

13 lrmdraft
2001b: 12.2.2.1, 12.2.2.2
12.2.2:example of named param passing before its description

SEE: Example at the end of section 12.2.2.1 and the
paragraph just before the example.

WAS: "Consider the following example, where the parameters
within module instance mod_a are changed during
instantiation." (and replace the example)

PROPOSED: Consider the following example, where the
parameters within module instances mod_a,
mod_c, and mod_d are changed during
instantiation.


module tb1;

  wire [9:0] out_a, out_d;
  wire [4:0] out_b, out_c;
  reg  [9:0] in_a, in_d;
  reg  [4:0] in_b, in_c;
  reg        clk;

  // testbench clock & stimulus generation code ...
  
  // Four instances of vdff with parameter value assignment by ordered list

  // mod_a has new parameter values size=10 and delay=15
  // mod_b has default parameters (size=5, delay=1)
  // mod_c has one default size=5 and one new delay=12
  //   Note that in order to change the value of delay,
  //   it is necessary to specify the (default) value of size as well.
  // mod_d has a new parameter value size=10. delay retains its default value

  vdff #(10,15) mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff          mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #( 5,12) mod_c (.out(out_c), .in(in_c), .clk(clk));
  vdff #(10)    mod_d (.out(out_d), .in(in_d), .clk(clk));

endmodule

module vdff (out, in, clk);
  parameter size=5, delay=1;
  output [size-1:0] out;
  input  [size-1:0] in;
  input             clk;
  reg    [size-1:0] out;
  
  always @(posedge clk)
    #delay out = in;

endmodule


SEE: Section 12.2.2.2. Add the following to the end of
section 12.2.2.2



PROPOSED:

Consider the following example, where both parameters of
mod_a and only one parameter of mod_c and
mod_d are changed during instantiation.


module tb2;

  wire [9:0] out_a, out_d;
  wire [4:0] out_b, out_c;
  reg  [9:0] in_a, in_d;
  reg  [4:0] in_b, in_c;
  reg        clk;

  // testbench clock & stimulus generation code ...
  
  // Four instances of vdff with parameter value assignment by name

  // mod_a has new parameter values size=10 and delay=15
  // mod_b has default parameters (size=5, delay=1)
  // mod_c has one default size=5 and one new delay=12
  // mod_d has a new parameter value size=10. delay retains its default value

  vdff #(.size(10),.delay(15)) mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff                         mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #(.delay(12))           mod_c (.out(out_c), .in(in_c), .clk(clk));
  vdff #(.delay( ), .size(10)) mod_d (.out(out_d), .in(in_d), .clk(clk));

endmodule


module vdff #(parameter size=5, delay=1)
  (output reg [size-1:0] out,
   input      [size-1:0] in,
   input                 clk);

  always @(posedge clk)
    #delay out = in;

endmodule


It shall be legal to instantiate modules using different
types of parameter redefinition in the same top-level
module. Consider the following example, where the parameters
of mod_a are changed using parameter redefinition by
ordered list and the second parameter of mod_c is
changed using parameter redefinition by name during
instantiation.


module tb3;
  // declarations & code ...

  // legal mixture of instance with positional parameters and 
  // another instance with named parameters

  vdff #(10, 15)     mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff               mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #(.delay(12)) mod_c (.out(out_c), .in(in_c), .clk(clk));

endmodule


It shall be illegal to instantiate any module using a
mixture of parameter redefinitions by order and by name as
shown in the instantiation of mod_a below.


  // mod_a instance with ILLEGAL mixture of parameter assignments
  vdff #(10, .delay(15)) mod_a (.out(out_a), .in(in_a), .clk(clk));


15 lrmdraft
2001a, 19.4
Section 19.4: Conditional compilation directives description unclear

Fixed in second edition.
Section 19.4, after syntax box 19-5, second bullet, remove second "the"

16 lrmdraft
2001b: 19.7
19.7: `line - meaning of level parameter is unclear

REWRITE 19.7 as follows:

"19.7 `line

It is important for Verilog tools to keep track of the filenames of the
Verilog source files and the line numbers in the files. This information
can be used for error messages or source code debugging, and can be
accessed by the Verilog PLI.

In many cases, however, the Verilog source is preprocessed by some other
tool, and the line and file information of the original source file can
be lost because the preprocessor might add additional lines to the source
code file, combine multiple source code lines into one line, concatenate
multiple source files, and so on.

The `line compiler directive can be used to specify the original source
code line number and filename. This allows the location in the original
file to be maintained if another process modifies the source. After the
new line number and filename are specified, the compiler can correctly
refer to the original source location. However, a tool is not required to
produce `line directives. These directives are not intended to be inserted
manually into the code, although they can be.

The compiler shall maintain the current line number and filename
of the file being compiled. The `line directive shall set
the line number and filename of the following line to those
specified in the directive.
The directive can be specified anywhere within the Verilog HDL source
description. However, only white space may appear on the
same line as the `line directive. Comments are not allowed
on the same line as a 'line directive.
All parameters in the `line directive are required. The
results of this directive are not affected by the `resetall
directive.

The syntax for the `line directive is given in Syntax 19-7.

line_compiler_directive ::=
`line number "filename" level

Syntax 19-7 Syntax for `line compiler directive

The number parameter shall be a positive integer that specifies
the new line number of the following text line. The filename parameter shall
be a string constant that is treated as the new name of the file. The filename
can also be a full or relative path name. The level parameter shall be 0, 1,
or 2. The value 1 indicates that the following line is the first line after
an include file has been entered. The value 2 indicates that the following line
is the first line after an include file has been exited. The value 0 indicates
any other line.

Example:
`line 3 "orig.v" 2
// This line is line 3 of orig.v after exiting include file

As the compiler processes the remainder of the file and new
files, the line number shall be incremented as each line is
read and the name shall be updated to the new current file
being processed. The line number shall be reset to 1 at the
beginning of each file. When beginning to read include files, the current line
and filename shall be stored for restoration at the termination of the include
file. The updated line number and filename information shall be available for
PLI access. The mechanism of library searching is not affected by the effects
of the `line compiler directive."


Also CLOSE errata/291 as superceded by the fix to errata/16.
17 lrmdraft
2001b, 12.1.3, 12.2.1
12.1.3 is not clear enough about permitted defparam usage

The following proposal was worked out by Jason and Gord,
only slightly edited by Shalom.

12.1.3 was deleted by the resolution of issue #113.

That leaves the following discussion in para. 1 of 12.2.1:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. However, a defparam
statement in a hierarchy under a generate scope or array of
instances shall not change a parameter value outside that
hierarchy. See 12.5 for hierarchical names."

(The xref is to 12.4 in 2001/D3, but issue #113 bumps 12.4
to 12.5 instead.)


This proposal is to change para. 1 of 12.2.1 to:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. See 12.5 for
hierarchical names.

However, a defparam statement in a hierarchy in or under a
generate block instance (see 12.4) or an array of instances
shall not change a parameter value outside that hierarchy.

Note: Each instantiation of a generate block is considered
to be a separate hierarchy scope. Therefore this rule
implies that a defparam statement in a generate block may
not target a parameter in another instantiation of the same
generate block, even when the other instantiation is created
by the same loop generate construct. For example, the
following code is not allowed:

genvar i;

generate
for(i=0; i < 8; i = i+1) begin : somename
flop my_flop(in[i], in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz = i ;
end
endgenerate

Similarly, a defparam statement in one instance of an array
of instances may not target a parameter in another instance
of the array.
18 lrmdraft
2001a, 4.4.1
Section 4.4.1, Table 29: Arithmetic shift operators missing

Sent to IEEE in October, 2001:
Passed 10/7/02:

BTF-PR18: Section 4.4.1 - 8 th row of Table 29, 1 st
column - missing >>> and <<< operators

REPLACE:
i op j, where op is:
>> << **

WITH:
i op j, where op is:
>> << ** >>> <<<

19 lrmdraft
2001b, 4.1.14
Section 4.1.14: Incorrect concatenation operator description

Passed 10/7/02:
Section 4.1.14:

REPLACE:
A concatenation is the joining together of bits resulting from
two or more expressions.

WITH:
A concatenation is the result of the joining together of bits
resulting from one or more expressions.

20 lrmdraft
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 }


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.

21 lrmdraft
2001b, A.9.3
memory_identifier is not used anywhere

Passed 10/7/2002:

Delete memory_identifier from BNF

23 lrmdraft
2001b, 15.1, 15.2.2, A.7.5.1
$hold _timing_check should have no space

Passed 10/7/02:

Remove space between $hold and _timing_check in A.7.5.1:
$hold _timing_check should be $hold_timing_check

Note that this syntax from Annex A is copied into:
Syntax 15-1 in Section 15.1
Syntax 15-4 in Section 15.2.2

24 lrmdraft
2001a, A.2.4, 3.11.3, 14.6.1
In PATHPULSE$ syntax, 2nd $ should be Bold

Sent to IEEE in October 2001:
Passed 10/7/2002

BTF-PR24 - Syntax 3-5 (section 3.11.3) and
BTF-PR24 - Syntax 14-7 (section 14.6.1) and
BTF-PR24 - Section A.2.4
(The second $ should be bold)
REPLACE:
| PATHPULSE$specify_input_terminal_descriptor$specify_output_terminal_descriptor
= ( reject_limit_value [ , error_limit_value ] ) ;
WITH:
| PATHPULSE$specify_input_terminal_descriptor$specify_output_terminal_descriptor
= ( reject_limit_value [ , error_limit_value ] ) ;


ETF Amendment 10/21/02:
Example at end of section 14.6.1:

All '$' characters should be bold:

REPLACE:
specparam
PATHPULSE$
clk$q = (2,9),
PATHPULSE$clr$q = (0,4),
PATHPULSE$ = 3;

WITH:
specparam
PATHPULSE$
clk$q = (2,9),
PATHPULSE$clr$q = (0,4),
PATHPULSE$ = 3;

25 lrmdraft
2001b, A.4.1, 2,8.2, 12.1.2
named_port_connection BNF missing space after .

Passed 10/7/02:
In A.4.1, named_port_connection syntax,

WAS:
named_port_connection ::= { attribute_instance } .port_identifier ( [ expression ] )

CHANGE:
named_port_connection ::= { attribute_instance } . port_identifier ( [ expression ] )

Note that this section of Annex A is copied into:
Syntax 2-8 in Section 2.8.2
Syntax 12-2 in Section 12.1.2

26 lrmdraft
2001a, A.7.4, 14.3
list_of_path_delay_expressions syntax missing comma

Passed 10/7/02:

BTF-PR26: Syntax box 14-6 (section 14.3) - 5 th line from the bottom
- end of line - missing ,
Same problem: Section A.7.4 - 8 th line from the top -
end of line - missing ,
REPLACE:
| t01_path_delay_expression , t10_path_delay_expression ,
t0z_path_delay_expression ,
tz1_path_delay_expression , t1z_path_delay_expression ,
tz0_path_delay_expression
t0x_path_delay_expression , tx1_path_delay_expression ,
t1x_path_delay_expression ,
tx0_path_delay_expression , txz_path_delay_expression ,
tzx_path_delay_expression
WITH: (bold font for the missing , )
| t01_path_delay_expression , t10_path_delay_expression ,
t0z_path_delay_expression ,
tz1_path_delay_expression , t1z_path_delay_expression ,
tz0_path_delay_expression ,
t0x_path_delay_expression , tx1_path_delay_expression ,
t1x_path_delay_expression ,
tx0_path_delay_expression , txz_path_delay_expression ,
tzx_path_delay_expression
27 lrmdraft
2001b, 2.7.4
Incorrect cross-reference (Section 2.7.4)

Passed 10/7/2002:

Section 2.7.4:
REPLACE:
The $identifier system task or function can be defined in three places
--- A sandard set of $identifier system tasks and functions, as defined in Clauses 17 and 19....
WITH:
The $identifier system task or function can be defined in three places
--- A standard set of $identifier system tasks and functions, as defined in Clauses 17 and 18....

28 lrmdraft
2001b, A.8.2, A.9.3
A.8.2: genvar_function_call is not used


Remove genvar_function_call from A.8.2
and genvar_function_identifier from A.9.3 and associated notes.

29 lrmdraft
2001a, A.8.7, 2.5
A.8.7: [] around size should not be bold

Passed 10/7/02:

Section A.8.7 (Change 6 pairs of brackets to non-bold typeface):
Section 2.5 - Syntax 2-1:

Bold "]" and "[" should not be in bold, meaning that "size" is an
optional field.

REPLACE:
decimal_number ::=
unsigned_number
| [ size ] decimal_base unsigned_number
| [ size ] decimal_base x_digit { _ }
| [ size ] decimal_base z_digit { _ }
binary_number ::= [ size ] binary_base binary_value
octal_number ::= [ size ] octal_base octal_value
hex_number ::= [ size ] hex_base hex_value

WITH:
decimal_number ::=
unsigned_number
| [ size ] decimal_base unsigned_number
| [ size ] decimal_base x_digit { _ }
| [ size ] decimal_base z_digit { _ }
binary_number ::= [ size ] binary_base binary_value
octal_number ::= [ size ] octal_base octal_value
hex_number ::= [ size ] hex_base hex_value

30 lrmdraft
2001b, Syntax 15-2 & 15-15, A.7.5.3
Incorrect syntax: edge_control_specifier

Passed 10/7/02:

Syntax 15-2 Section 15.1 (p249)
Syntax 15-15 Section 15.4(p267)
Annex 7.5.3 (p791)

Definition of an edge_control_specifier given with the square
brackets in BOLD. Inner brackets should become curly braces.

REPLACE:
edge_control_specifier ::= edge [ edge_descriptor [ , edge_descriptor ] ]

WITH:
edge_control_specifier ::= edge [ edge_descriptor { , edge_descriptor } ]


31 lrmdraft
2001a, A.9.4, 12.4
A.9.4: inner brackets should be bold

Sent to IEEE in October 2001:
Passed 10/7/02:

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.

Section A.9.4 and Syntax 12-7 (Section 12.4):

REPLACE (4 places):
simple_identifier [ [ unsigned_number ] ]

WITH:
simple_identifier [ [ unsigned_number ] ]

32 lrmdraft
2001b, A.Note.2, 12.4
A.Note.2: "arrayed_reference" is not used anywhere

Passed 10/7/02:

Syntax 12-7 (Section 12.4):
A.Note.2:

REPLACE:
2) A simple_identifier and arrayed_reference shall start with an
alpha or underscore (_)character, shall have at least one
character,and shall not have any spaces.

WITH:
2) A simple_identifier shall start with an
alpha or underscore (_)character, shall have at least one
character,and shall not have any spaces.

33 lrmdraft
2001b, 17.2
17.2: Use of keyword "integer"

The following proposal may not be complete,
in that the LRM should clearly define the type of the
value returned by the system function in each case,
and the LRM does not always do so.

However, the proposal does solve the immediate problem.

In Syntax 17-4 in 17.2.1, in file_open_function, DELETE "integer" twice.

In 17.2.4.2, CHANGE

integer code = $fgets ( str, fd ) ;
TO
integer code ;
code = $fgets ( str, fd ) ;

In 17.2.4.3, CHANGE

integer code = $fscanf ( fd, format, args );
integer code = $sscanf ( str, format, args );
TO
integer code ;
code = $fscanf ( fd, format, args );
code = $sscanf ( str, format, args );

In 17.2.4.4, CHANGE

integer code = $fread ( myreg, fd ) ;
integer code = $fread ( mem, fd ) ;
integer code = $fread ( mem, fd, start ) ;
integer code = $fread ( mem, fd, start, count ) ;
integer code = $fread ( mem, fd, count ) ;
TO
integer code ;
code = $fread ( myreg, fd ) ;
code = $fread ( mem, fd ) ;
code = $fread ( mem, fd, start ) ;
code = $fread ( mem, fd, start, count ) ;
code = $fread ( mem, fd, count ) ;

In 17.2.5, CHANGE

integer pos = $ftell ( fd ) ;
TO
integer pos ;
pos = $ftell ( fd ) ;

In 17.2.7, CHANGE

integer errno = $ferror ( fd, str ) ;
TO
integer errno ;
errno = $ferror ( fd, str ) ;

34 lrmdraft
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"

**

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."

36 lrmdraft
2001a 2001b, 9.7.3
Section 9.7.3: unfinished sentence

Sent to IEEE in October 2001:
Passed 10/7/02:

Section 9.7.3:

First paragraph had wrong cross reference in both first and second editions:

REPLACE:
It can be used in an event expression to control the execution of
procedural statements in the same manner as event control
described in 9.7.1. Named events can be made to occur from a procedure.

WITH:
It can be used in an event expression to control the execution of
procedural statements in the same manner as event control
described in 9.7.2. Named events can be made to occur from a procedure.

Third bullet of third paragraph was wrong in the first edition
but corrected in the second:

REPLACE:
-- Its occurrence can be recognized by using the event control
syntax described in.

WITH:
-- Its occurrence can be recognized by using the event control
syntax described in 9.7.2.


39 lrmdraft
2001a: 12.3.3
12.3.3 describes wrong tied connections

Sent to IEEE in October 2001:
Passed 10/7/02:

Change last line of example in 12.3.3:

REPLACE:
input a; // This is legal. The inputs are ored together.

WITH:
input a; // This is legal. The inputs are tied together.

40 lrmdraft
2001b, 4.4.3
Misleading comment in example in 4.4.3

Passed 10/7/02:

Section 4.4.3 example:

REPLACE:
c = {a**b};              // expression a**b is self determined
$display ("a**b=%x", c); // due to {}


WITH:
c = {a**b}; // expression a**b is self determined
            // due to concatenation operator {}
$display ("a**b=%x", c); 


NOTE TO EDITOR: Keep $display on line after comment regarding
"concatenation operator {}"

41 lrmdraft
2001b: 17.2.3
17.2.3: Is $sformat a task or a function ?

Passed 10/7/02:

Section 17.2.3 (delete line):

REPLACE:
$sformat(output_reg, format_string, list_of_arguments );
length = $sformat(output_reg, format_string, list_of_arguments );

WITH:
$sformat(output_reg, format_string, list_of_arguments );

42 lrmdraft
2001b: 17.2.3
17.2.3: typos

Passed 10/7/02:
Section 17.2.3:

REPLACE:
The $swrite family of tasks are based on the $fwrite family of tasks, ...

WITH:
The $swrite family of tasks is based on the $fwrite family of tasks, ...

CHANGE:
In the continuation, change $sformat and $swrite from Courier
font to bold Times font.

REPLACE:
The system task $sformat ... with a one major difference.

WITH:
The system task $sformat ... with one major difference.

43 lrmdraft
2001b, Syntax 3-5, 13-2
Typos in syntax boxes 3-5 and 13-2

Passed 10/7/02:
Section 3.11.3, Syntax 3-5:

REPLACE:
specparam_declaration ::= (From Annex A -A.2.2.1)

WITH:
specparam_declaration ::= (From Annex A -A.2.1.1)

Section 13.2.1, Syntax 13-2:

REPLACE:
escaped_hierarchical_identifier* ::= (From Annex A - A.1.1)
library_text ::=
{ library_descriptions }

WITH:
library_text ::= (From Annex A - A.1.1)
{ library_descriptions }

DELETE:
*The period in escaped_hierarchical_identifier and
escaped_hierarchical_branch shall be preceded by
white_space, but shall not be followed by white_space.

44 lrmdraft
2001b, 4.4.3
Misleading comment: Section 4, example 4.4.3 -- value can't be verified

Passed 10/7/02:
Section 4.4.3 example:

REPLACE:
b = 6'ha;

WITH:
b = 6'hA;

REPLACE:
a*b=16 // 96 was truncated since expression size is 6

WITH:
a*b=16 // 'h96 was truncated to 'h16 since expression size is 6

REPLACE (%x changed to %h):
$display ("a*b=%x", a*b); // expression size is self determined
c = {a**b};               // expression a**b is self determined
$display ("a**b=%x", c);  // due to {}
c = a**b;                 // expression size is determined by c
$display ("c=%x", c);


WITH:
$display ("a*b=%h", a*b); // expression size is self determined
c = {a**b};               // expression a**b is self determined
                          // due to concatenation operator {}
$display ("a**b=%h", c); 
c = a**b;                 // expression size is determined by c
$display ("c=%h", c);


Editors note: Note that this includes changes to comments from
issue #40

45 lrmdraft
2001b, 4.5
Example in Section 4.5: Incorrect comment

Passed 10/7/02:
Section 4.5 example:

REPLACE:
reg [7:0] regA;
reg signed [7:0] regS;
regA = $unsigned (-4); // regA = 4'b1100
regS = $signed (4'b1100); // regS = -4

WITH
reg [7:0] regA, regB;
reg signed [7:0] regS;
regA = $unsigned(-4); // regA = 8'b11111100
regB = $unsigned(-4'sd4); // regB = 8'b00001100
regS = $signed(4'b1100); // regS = -4


47 lrmdraft
2001b: 3.7.4, Tables 6 & 7
3.7.4: Wrong description of tri0/1 in 3.7.4

In Section 3.7.4

Replace the first three paragraphs with:

"The tri0 and tri1 nets model nets with resistive pulldown
and resistive pullup devices on them. A tri0 net is
equivalent to a wire net with a continuous 0 value of pull
strength driving it. A tri1 net is equivalent to a wire net
with a continuous 1 value of pull strength driving it.

When no driver drives a tri0 net, its value is 0 with
strength pull. When no driver drives a tri1 net, its value
is 1 with strength pull. When there are drivers on a tri0
or tri1 net, the drivers combine with the strength pull
value implicitly driven on the net to determine the net's
value. See 7.9 for a discussion of logic strength modeling.

Table 6 and Table 7 are truth tables for modeling multiple
drivers of strength strong on tri0 and tri1 nets. The
resulting value on the net has strength strong, unless both
drivers are z, in which case the net has strength pull."

(In the last paragraph, "strong" and "pull" should be bold.)
49 lrmdraft
2001b, 4.4.3
Section 4.4.3: incorrect output in example

Passed 10/7/02:
Section 4.4.3 example:

REPLACE:
c=21 // example size is 16 bits (size of c)

WITH:
c=ac61 // expression size is 16 bits (size of c)

50 lrmdraft
2001b, 19.5, 19.7
Section 19.5: descriptions of `include

Proposed:

Section 19.5, last line before example:
REPLACE:
included files

WITH:
include files

First sentence of the example of 19.5:
REPLACE:
"The examples of legal comments for the `include compiler
directive are as follows:"

WITH:
"Examples of `include comiler directives are as follows:"

51 lrmdraft
2001b, 12.2
12.2 - typos

Section 12.2, in the 2nd paragraph between the 2 examples:
In first line, "and or" should be "and/or"
In second line, "and second" should be "and the second"

53 lrmdraft
2001b, Syntaxes 9-1, 9-2, 9-3, A.8.1, A.8.5
net_lvalue BNF allows {x[i]}

* New productions for net_lvalue and variable_lvalue
(This incorporates changes from #181)

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 } '}'


* Eliminate productions:

net_concatenation
net_concatenation_value
variable_concatenation
variable_concatenation_value
56 lrmdraft
2001b: 12.3.11, 12.4
Keywords should be bold

In 12.3.11, in the first sentence, in "the signed keyword must be used", the word "signed" should be bold.

In 12.4, in the 2nd paragraph, in the penultimate sentence, in "declared using the automatic keyword", the word "automatic" should be bold.
59 lrmdraft
2001b: 17.9.3
chi_square function is wrong


In 17.9.3, replace chi_square function text with the
following:

static double
chi_square(seed,deg_of_free)
long *seed,deg_of_free;
{
    double x;
    long k;
    if(deg_of_free % 2)
    {
        x = normal(seed,0,1);
        x = x * x;
    }
    else
    {
        x = 0.0;
    }
    for(k = 2;k <= deg_of_free;k = k + 2)
    {
        x = x + 2 * exponential(seed,1);
    }
    return(x);
}

60 lrmdraft
2001b: 17.9.3
17.9.3: "1364-2000" should be "1364-2001" in code header

Change "1364-2000" to "1364-2001" in 17.9.3 code header.
64 lrmdraft
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 lrmdraft
2001b: A.2.7, 10.2.1 (Syntax 10-1)
error in task_declaration syntax


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 lrmdraft
2001b: A.6.5, Syntax 9-10
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 lrmdraft
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          |
+-----------------------------+------------+--------------------------+

71 lrmdraft
2001b: 26.6.26
26.6.26: Indexed part-selects (+: and -:) do not have

Modify the section 26.6.26 as per the diagram
http://www.verilog-2001.com/pli_errata/
See vpi_expressions1.pdf

Also add the following to annex G:

1) Immediately after the define for vpiNamedEventArray (line 177):

#define vpiIndexedPartSelect 130 /* Indexed part-select object */

2) Immediately after the define for vpiTaskFunc (line 239):

#define vpiBaseExpr 131 /* Indexed Part Select's base expression */
#define vpiWidthExpr 132 /* Indexed Part Select's width expression */

3) Immediately after the define for vpiModPathHasIfNone (line 482):

#define vpiIndexedPartSelectType 72 /* Index part-select type */
#define vpiPosIndexed 1 /* +: */
#define vpiNegIndexed 2 /* -: */


73 lrmdraft
2001b: 4.1.14
4.1.14 implies replication legal lvalue

In 4.1.14,

CHANGE

"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
follows the rules for concatenation."

TO

"An operator that can be applied only to concatenations
is replication, which is expressed by a concatenation
preceded by a positive, non-X and non-Z constant
expression, enclosed together within brace
characters, and which indicates a joining together
of that many copies of the concatenation. Unlike
regular concatenations, expressions containing
replications shall not appear on the left-hand
side of an assignment and shall not be connected
to output or inout ports."

and in the example that follows these sentences,

CHANGE

"// This is equivalent to"

TO

"// This yields the same value as"

and in the final example of 4.1.14,

CHANGE

"nested concatenations"

TO
"a replication nested within a concatenation"

and

CHANGE

"// This is equivalent to"

TO

"// This yields the same value as"

75 lrmdraft
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 lrmdraft
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 lrmdraft
2001b: 6 (Table 30)
Table 30: Last LHS line is not clear

Propose to close this issue as being supreceded by # 75.
78 lrmdraft
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".
79 lrmdraft
2001b, 3.5
Section 3.5 Implicit declarations wrong or misleading

Section 3.5, first bullet:
Change "implicit net of type wire" to "implicit net of
default net type".

85 lrmdraft
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 lrmdraft
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 lrmdraft
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)
91 lrmdraft
2001b: 26.6.5
Note 7 in section 26.6.5 is misleading

Section 26.6.5, change note 7
FROM:
"7)vpiHighConn and vpiLowConn shall return NULL if the port is not connected."

TO:
"7) vpiLowConn shall return NULL if the module port is a null port (e.g. module M();). vpiHighConn shall return NULL if the instance of the module does not have a connection to the port."
92 lrmdraft
2001b: 17.10.2
17.10.2 should talk about leading plus sign

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

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

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".

5. 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."

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

93 lrmdraft
2001b: 17.10.2
17.10.2: errors in the example

Replace the entire example, including the command line args
and expected output with the following:

Examples:

Given the following Verilog HDL:


`define STRING reg [1024 * 8:1]

module goodtasks;
  `STRING str;
  integer int;
  reg [31:0] vect;
  real realvar;

  initial
    begin
      if ($value$plusargs("TEST=%d",int))
        $display("value was %d",int);
      else
        $display("+TEST= not found");
      #100 $finish;
    end

endmodule

module ieee1364_example;
  real frequency;
  reg [8*32:1] testname;
  reg [64*8:1] pstring;
  reg clk;

  initial
    begin
      if ($value$plusargs("TESTNAME=%s",testname))
        begin
          $display(" TESTNAME= %s.",testname);
          $finish;
        end

      if (!($value$plusargs("FREQ+%0F",frequency)))
        frequency = 8.33333; // 166 MHz
      $display("frequency = %f",frequency);

      pstring = "TEST%d";
      if ($value$plusargs(pstring, testname))
        $display("Running test number %0d.",testname);
    end

endmodule


Adding the following plusarg to the tool's command line:

+TEST=5 


will result in the following output:

value was           5
frequency = 8.333330
Running text number x.


Adding the following plusarg to the tool's command line:

+TESTNAME=bar


will result in the following output:

+TEST= not found
 TESTNAME=                              bar.


Adding the following plusarg to the tool's command line:

+FREQ+9.234


will result in the following output:

+TEST= not found
frequency = 9.234000


Adding the following plusarg to the tool's command line:

+TEST23


will result in the following output:

+TEST= not found
frequency = 8.333330
Running test number 23.


(Note: my earlier comments that "frequency = 8.333330" and
"Running text number x." should also be printed in the
second case as well, were incorrect.)

94 lrmdraft
2001b: 19.2 (Syntax 19-1)
tri1 missing from `default_nettype in Syntax 19-1

Add tri1 to the list in Syntax 19-1.
95 lrmdraft
2001b: 21.1.4
21.1.4 should also list reason_finish

Add 'reason_finish' to the list at the end of
section 21.1.4.
97 lrmdraft
2001b: 12.1
12.1: simple typo

In 12.1, in the 2nd paragraph, in the fifth sentence,
change "used used" to "used".

In 12,1, in the 2nd paragraph, in the last sentence,
change the semicolon (;) to a comma (,).



100 lrmdraft
2001b: 10.2.3
10.2.3: output arguments of automatic tasks not initialized

In 10.2.3, para. 2,

REPLACE

"Variables declared in static tasks shall retain their values
between invocations. They shall be initialized to the
default initialization value as described in 3.2.2.
Variables declared in automatic tasks shall be initialized
to the default initialization value whenever execution
enters their scope."

WITH

"Variables declared in static tasks, including input,
output, and inout type arguments, shall retain their values
between invocations. They shall be initialized to the
default initialization value as described in 3.2.2.

Variables declared in automatic tasks,
including output type arguments, shall be initialized
to the default initialization value whenever execution
enters their scope. Input and inout type arguments shall be
initialized to the values passed from the expressions
corresponding to these arguments
listed in the task enabling statements."

101 lrmdraft
2001b: 17.10.1, 17.10.2
17.10.1: $test$plusargs argument

Change the first sentence of section 17.10.1 FROM:

This system function searches the list of plusargs for the
provided string.

TO:

This system function searches the list of plusargs for a
user specified plusarg string. The string is specified in
the argument to the system function as either a
string or a or non-real variable that is interpreted as a string.
This string shall not include the leading plus sign of
the command line argument.

Change the second sentence in 17.10.2:

REPLACE:
register

WITH:
non-real variable

REPLACE:
which

WITH:
that

102 lrmdraft
2001b: TOC
TOC goes only 1 level down

Expand the table of contents to include 2 levels of subclauses
except subclauses 23, 25 and 27 and sub-subclauses of 26.6.

103 lrmdraft
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.
104 lrmdraft
2001b: 3.2.2
3.2.2: typo

In the 'NOTE' of section 3.2.2, change

"types; but that the term"

to

"types, but that term"

106 lrmdraft
2001c: 4.1.7, 4.1.8
4.1.8: Incorrect zero-extend rules for equality operators

In 4.1.7, CHANGE the paragraph order as follows:

1. "Table 4-9 lists and defines the relational operators."
2. "An expression using these relational operators shall yield the scalar ..."
3. The paragraphs discussing operand types and signedness (details below)
4. The paragraphs discussing operator precedence:
- "All the relational operators shall have the same precedence ..."
- "Examples:"
- "The following examples.."
- "When foo - (1 < a) evaluates..."

REWORD the paragraphs discussing operand types and signedness as follows:

"When one or both operands of a relational expression are unsigned, the
expression shall be interpreted as a comparison between unsigned values.
If the operands are of unequal bit lengths, the smaller operand shall be
zero-extended to the size of the larger operand.

When both operands are signed, the
expression shall be interpreted as a comparison between signed values.
If the operands are of unequal bit lengths, the smaller operand shall be
sign-extended to the size of the larger operand.

If either operand is a real operand, then the other operand shall be converted
to an equivalent real value and the expression shall be interpreted as a
comparison between real values."


In 4.1.8, in paragraph 2, CHANGE the sentence

"These four operators compare operands bit for bit, with zero filling if the
two operands are of unequal length."

TO

"These four operators compare operands bit for bit."


INSERT the following after paragraph 2:

"If the operands are of unequal bit lengths, then if one or both operands are
unsigned, the smaller operand shall be zero-extended to the size of the larger
operand. If both operands are signed,
the smaller operand shall be sign-extended to the size of the larger operand.

If either operand is a real operand, then the other operand shall be converted
to an equivalent real value and the expression shall be interpreted as a
comparison between real values."

109 lrmdraft
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."
113 lrmdraft
2001b: 12.1.3
interaction of generate and scope definitions

We did not get this officially into the database:

The proposal can be found at

http://boydtechinc.com/etf/archive/etf_2004/2566.html
114 lrmdraft
2001b: 2.8.2, 3.11.1, 9.8.1-2, 10.2-3, 12.1, A.1.5, A.2.1.1, A.2.8
A.1.5, A.2.1.1, A.2.8: port style parameter declarations

See
http://boydtechinc.com/btf/archive/att-1803/01-ParameterFix_20020415.pdf
as modified by applying the changes to localparams as well.

The final changes are as follows:

1. (Note: The following is affected by issues #20, #154)

In BNF of the following items:

a) module_item

(Syntax 2-6 (2.8.2), Syntax 12-1 (12.1),
Syntax 12-3 (12.1.3), A.1.5)

b)non_port_module_item

(as above, except Syntax 12-3)

and c) block_item_declaration

(Syntax 2-7 (2.8.2), Syntax 9-13 ( 9.8.1),
Syntax 9-14 (9.8.2), Syntax 10-1 (10.2.1),
Syntax 10-3 (10.3.1), A.2.8),

CHANGE:

| { attribute_instance } local_parameter_declaration
| { attribute_instance } parameter_declaration


TO:

| { attribute_instance } local_parameter_declaration ";"
| { attribute_instance } parameter_declaration ";"



2. (Note: The following is affected by issue #165)

In Syntax 3-4 (3.11.1) and A.2.1.1,

CHANGE BNFs of

local_parameter_declaration and parameter_declaration

FROM:


local_parameter_declaration ::=  
    localparam [ signed ] [ range ] list_of_param_assignments ;
  | localparam integer  list_of_param_assignments ;
  | localparam real     list_of_param_assignments ;
  | localparam realtime list_of_param_assignments ;
  | localparam time     list_of_param_assignments ;

parameter_declaration ::=
    parameter [ signed ] [ range ] list_of_param_assignments ;
  | parameter integer   list_of_param_assignments ;
  | parameter real      list_of_param_assignments ;
  | parameter realtime  list_of_param_assignments ;
  | parameter time      list_of_param_assignments ;



TO:


local_parameter_declaration ::=  
    localparam [ signed ] [ range ] list_of_param_assignments
  | localparam integer  list_of_param_assignments 
  | localparam real     list_of_param_assignments 
  | localparam realtime list_of_param_assignments 
  | localparam time     list_of_param_assignments 

parameter_declaration ::=
    parameter [ signed ] [ range ] list_of_param_assignments
  | parameter integer   list_of_param_assignments 
  | parameter real      list_of_param_assignments 
  | parameter realtime  list_of_param_assignments 
  | parameter time      list_of_param_assignments 



115 lrmdraft
2001b: 9.8
9.8: "block statement" definition

In the first sentence of 9.8, delete

"two or more"
116 lrmdraft
2001b: 2.5.1, 2.7.5, 19, 25.52-53, 25.55-56
19, para. 1: Grave accent, apostrophe character


1. In 2.5.1:

A. CHANGE the third sentence of paragraph 2 FROM

"The second form specifies a size constant, which shall be 
composed of up to three tokens-an optional size constant, a 
single quote followed by a base format character, and the 
digits representing the value of the number."

TO:

"The second form specifies a based constant, which shall be 
composed of up to three tokens-an optional size constant, an
apostrophe character (', ASCII 0x27) followed by a base 
format character, and the 
digits representing the value of the number."

(Note that issue #267 changes "size constant" to "based 
constant".)

B. CHANGE the first sentence of paragraph 5 FROM

"The second token, a base_format, shall consist of a 
case-insensitive letter specifying the base for the number, 
optionally preceded by the single character s (or S) to 
indicate a signed quantity, preceded by the single quote 
character (')."

TO:

"The second token, a base_format, shall consist of a 
case-insensitive letter specifying the base for the number, 
optionally preceded by the single character s (or S) to 
indicate a signed quantity, preceded by the apostrophe
character."

C. CHANGE paragraph 7 FROM

"The single quote and the base format character shall not 
be separated by any white space."
 
TO:

"The apostrophe character and the base format character 
shall not be separated by any white space."


2. CHANGE the first sentence of 2.7.5 FROM

"The ` character (the ASCII value 60, called open quote 
or accent grave) introduces a language construct used to 
implement compiler directives."

TO:

"The ` character (the ASCII value 0x60, called 
grave accent) introduces a language construct used to 
implement compiler directives."


3. CHANGE the first three sentences of section 19 FROM

"All Verilog compiler directives are preceded by the (` ) 
character. This character is called accent grave. It is 
different from the character ('), which is the single quote 
character."

TO

"All Verilog compiler directives are preceded by the (` ) 
character. This character is called grave accent
(ASCII 0x60). It is 
different from the character ('), which is the apostrophe
character (ASCII 0x27)."

(Note to editor:
The ` and ' characters should be in Courier font.
The apostrophe character should be straight vertical, not
slanted.)


4. The term "single quote" appears in 25.52-53, 55-56 in the
phrase "A character in single quotes ...", referring to C code.
Leave the phrase as is in those places.


5. Editor to make sure that everywhere the apostrophe character
is supposed to appear in code text, both Verilog and C, the 
plain straight up-and-down apostrophe character is used, not a 
curly quote nor a slanted quote character.

Similarly, make sure that the regular plain grave accent 
character is used wherever it is needed, not a curly version.

Similarly, double quotes in code text should be regular 
straight up-and-down quotation marks, not 'smart', slanted
quotes.

(Note to editor: change CourierNew font to Courier, 
 TimesNewRoman to Times.) 

117 lrmdraft
2001b: 19.1, 19.6, 19.9
19.1,19.6,19.9: `unconnected_drive and `celldefine

No syntax boxes will be added.

In section 19.1, REPLACE

"It is advisable to pair each `celldefine with an `endcelldefine."

WITH

"It is advisable to pair each `celldefine with an `endcelldefine,
but it is not required. The latest occurrence of either directive
in the source controls whether modules are tagged as cell modules."

In section 19.9, REPLACE

"These directives shall be specified in pairs, and outside of the
module declarations."

WITH

"It is advisable to pair each `unconnected_drive with a
`nounconnected drive, but it is not required. The latest occurrence
of either directive in the source controls what happens to unconnected
ports. These directives shall be specified outside of the module
declarations."

In section 19.9, REPLACE

"The `resetall directive includes the effect of a `endcelldefine
directive."

WITH

"The `resetall directive includes the effect of a `nounconnected_drive
directive."
118 lrmdraft
2001b: 12.3.4
12.3.4: Bad syntax in example

In section 12.3.4:

Replace:

output signed reg [7:0] f, g

With:

output reg signed [7:0] f, g
119 lrmdraft
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 \377.

***********************
Note:

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

121 lrmdraft
2001b: 12.4 (Syntax 12-7)
Syntax 12-7

Shalom (editor) to implement the replacement back to what we had
before the IEEE's changes.
122 lrmdraft
2001b: 19.4
: 19.4, example 2, last two $display lines

In section 19.4 in Example 2:

Indent second initial $display line one tab stop.

and inside the 'else branch of 'ifdef wow

Replace:

nest_two

With:

second_nest
123 lrmdraft
2001b: A.8.4, A.8.5, 4.3 (Syntax 4-2), Syntaxes 9-1, 9-2, 9-3
A.8.4, A.8.5: identifier and indexing syntax

 
  
The following fix incorporates and supercedes issue #181. 
 
In "primary" BNF in Syntax 4-2 and in A.8.4, 
CHANGE the following 4 lines from: 
 
| hierarchical_identifier 
| hierarchical_identifier [ expression ] { [ expression ] } 
| hierarchical_identifier [ expression ] { [ expression ] } [ range_expression ] 
| hierarchical_identifier [ range_expression ] 
 
TO: 
 
| hierarchical_identifier [ {"["expression"]"} "["range_expression"]" ] 
 
 
The following fix partly supercedes issue #53. 
 
In "net_lvalue" BNF in Syntax 9-3 and in A.8.5, 
CHANGE the following 4 lines from: 
 
| hierarchical_net_identifier 
| hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] } 
| hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] }[ constant_range_expression ] 
| hierarchical_net_identifier [ constant_range_expression ] 
 
TO: 
 
| hierarchical_net_identifier [ {"["constant_expression"]"} 
"["constant_range_expression"]" ] 
 
 
The following fix partly supercedes #53. 
 
In "variable_lvalue" BNF in Syntaxes 9-1, 9-2, 9-3, and in
A.8.5, 
CHANGE the following 4 lines from: 
 
| hierarchical_variable_identifier 
| hierarchical_variable_identifier [ expression ] { [ expression ] } 
| hierarchical_variable_identifier [ expression ] { [ expression ] }[ range_expression ] 
| hierarchical_variable_identifier [ range_expression ] 
 
TO: 
 
| hierarchical_variable_identifier [ {"["expression"]"} "["range_expression"]" ] 
 

124 lrmdraft
2001b: 17.2.4.3
17.2.4.3: Second sentence for %m should be in own paragraph


Change the following:

m Returns the current hierarchical path as a string. Does not read data from the input file or str argument. If an invalid conversion character follows the %, the results of the operation are implementation dependent.

to


m Returns the current hierarchical path as a string. Does not read data from the input file or str argument.

If an invalid conversion character follows the %, the results of the operation are implementation dependent.
125 lrmdraft
2001b, 3.5
3.5 Implicit Declarations (cont.)

Section 3.5:

Add following sentence to the end of the third bullet:
See 6.1.2 for a discussion of continuous assignment statements.

Remove last sentence of second bullet.

Add paragraph after bullets:
See 19.2 for a discussion of control of the type for implicitly
declared nets with the `default_nettype compiler directive.

126 lrmdraft
2001a
"nonblocking" spelling

This is fixed in the Second Edition.

Correction sent to IEEE in Oct, 2001
Passed 12/16/2002:

Replace all occurrences of "non blocking" and "non-blocking" with
"nonblocking"

127 lrmdraft
2001a,b: 9.7.5
9.7.5: 4th paragraph - pp.140-141

In 9.7.5, change the 4th paragraph from

"Nets and variables which appear on the right hand
side of assignments, in function and task calls, or
case and conditional expressions shall all be included
by these rules."

to

"Nets and variables which appear on the right-hand
side of assignments, in function and task calls,
in case and conditional expressions, as an index
variable on the left-hand side of assignments or
as variables in case item expressions shall all be
included by these rules."


And insert the following Examples 5 and 6 just
before 9.7.6, indenting as appropriate,
bolding the keywords and italicizing
"Example 5" and "Example 6":

Example 5

always @* begin // same as @(a or en)
y = 8'hff ;
y[a] = !en ;
end


Example 6

always @* begin // same as @(state or go or ws)
next = 4'b0 ;
case (1'b1)
state[IDLE]: if (go) next[READ] = 1'b1 ;
else next[IDLE] = 1'b1 ;
state[READ]: next[DLY ] = 1'b1 ;
state[DLY ]: if (!ws) next[DONE] = 1'b1 ;
else next[READ] = 1'b1 ;
state[DONE]: next[IDLE] = 1'b1 ;
endcase
end
128 lrmdraft
2001a,b: 10.3.5
10.3.5 Example: ram_model


In example in 10.3.5:

1. REPLACE:

localparam adder_width = clogb2(ram_depth);
input [adder_width-1:0] address ;


WITH:

localparam addr_width = clogb2(ram_depth);
input [addr_width-1:0] address ;


("localparam" in bold)
(I.e., CHANGE "adder_width" to "addr_width".)


2. REPLACE:

function integer clogb2 ;
input depth ;
integer i, result ;
begin
  for (i=0; 2**i < depth; i=i+1)
    result = i + 1 ;
  clogb2 = result ;
end
endfunction


WITH:

  function integer clogb2 ;
    input [31:0] value ;
    begin
      value = value - 1 ;
      for (clogb2 = 0; value > 0; clogb2 = clogb2 + 1) 
        value = value >> 1 ;
    end
  endfunction


(All keywords in bold.)
NOTE that there is no semicolon after "clogb2+1".
A semicolon was incorrectly inserted in 2001b. Delete it.


3. CHANGE:

// the rest to the ram model

TO:

// the rest of the ram model
129 lrmdraft
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.

The solution is to convert all paragraphs with "em dashes"
in TimesNewRoman to Times.
131 lrmdraft
2001a: intro
Page iii - 2nd paragraph after "INTRODUCTION"

In the 2nd paragraph of Introduction,
in the first sentence, the superscript
on the first occurrence of the word
'Verilog' should be the "Registered" symbol,
that is, an "R" in a circle.

132 lrmdraft
2001b: passim
Change Table and Figure numbering from consecutive to X-Y


Change Table and Figure numbering from consecutive
throught the entire document to X-Y, where X is the Clause
number and Y is the Table/Figure number within the Clause.
So Table 12 becomes Table 4-4.

That is how it was in Draft 6.

The price is being different from the current document.

133 lrmdraft
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 lrmdraft
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 lrmdraft
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 lrmdraft
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.
139 lrmdraft
2001b, 19.3.1
19.3.1 miscellaneous small errata

Proposal for Errata 139:

Part I:

In Syntax Box 19-2:

Change each existing occurrence of "formal_argument_identifier" where
the "formal_argument" part is in italics to be in all normal
non-italic font.

Part II:

In Syntax Box 19-2:

Add the following rule after the existing rule for "text_macro_identifier":

formal_argument_identifier ::= simple_identifier

No italics should be used in the above rule.

Part III:

In Paragraph 1 of 19.3.1:

REPLACE the 4th sentence:

"The compiler shall substitute the text of the macro for the string `macro_name."

Note: `macro_name is in courier font.

WITH:

The compiler shall substitute the text of the macro for the string `text_macro_name
and any actual arguments which follow it.

Note: `text_macro_name is in courier font.

Part IV:

In Note 1) of 19.3.1:

The last sentence in Note 1) is in courier font and is formatted as
if it were part of the example code that precedes it.

REFORMAT the sentence:

"Here, the larger of the two expressions p + q and r + s
will be evaluated twice."

so that it is separated from the example that precedes it and is
in the same font as the other regular text in the note.
140 lrmdraft
2001b: 4.1.5
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):
In all cases the second operand shall be treated as self-determined.
If either operand of the power operator is real then:
The result type shall be real. 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.
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
The result value is 'bx if the first operand is zero and the second
operand is negative. The result value is 1 if the second operand is
zero.


These statements are illustrated in the following table
op1 ** op2 where op1, op2 are not real:

                op1 is    negative<-1     -1                 zero     1    positive>1
              ------------------------------------------------------------------------
              op2 is            
              positive    op1 ** op2   op2 is odd -> -1       0       1    op1 ** op2
                                       op2 is even -> 1
            
              zero           1             1                  1       1       1
            
              negative       0         op2 is odd -> -1      'bx      1       0
                                       op2 is even -> 1





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


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
              2**0               1            anything to the zero exponent is 1
              0**0               1            zero to the zero exponent is also 1
              2.0**-3'sb1        0.5          2.0 is real, giving real reciprocal     
              2**-3'sb1          0            2**-1 = 1/2 Integer division truncates to zero
              0**-1              'bx          0**-1 = 1/0 Integer division by zero is 'bx
              9**0.5             3.0          Real square root
              9.0**(1/2)         1.0          Integer division truncates exponent to zero
              -3.0**2.0          9.0          Defined, because real 2.0 is still integral value

141 lrmdraft
2001b: 19.7
19.7: `line number

No change is needed here.

The reference to "number" in the syntax description is
not really a reference to the BNF rule "number".
142 lrmdraft
2001b: 2.5.1
2.5.1: bad cross-reference to Table 8-1

See issue #161.

Fix cross-reference.

Change "state table" preceding xref to "state tables".
143 lrmdraft
2001b: passim
cross-references to "Section" instead of "Clause"

All cross-references to "Section n", for
example, "Section 6" should be changed to
"Clause n", for example, "Clause 6".

References to subclauses should be without the
word "clause" at all. See, for example, third column in
third row in Table 117.
144 lrmdraft
2001b, 3.5
3.5 IEEE did not fix errata/5 correctly

Issue had the fix for the second edition that was fixed wrong:

Change paragraph format for the last paragraph of 3.5 to be
bullet format (part of the list).
145 lrmdraft
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 lrmdraft
2001b: 3.9
3.9: poor cross-reference to $time section


Change 17 to 17.7.1

147 lrmdraft
2001b: 9.5
9.5: case -- what happens after first match and execution


Section 9.5, first paragraph after first example (starting with
"The case item expression shall...":

REPLACE:
During the linear search, if one of the case item expressions
matches the case expression given in parentheses, then the
statement associated with that case item shall be executed.

WITH:
During the linear search, if one of the case item expressions
matches the case expression given in parentheses, then the
statement associated with that case item shall be executed and
the linear search shall terminate.


148 lrmdraft
2001b: Annex B
Annex B: 'unsigned' is not really a keyword

Add note to Annex B:
"unsigned is reserved for possible future usage."

149 lrmdraft
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.

************************************************************
Note: 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.
150 lrmdraft
2001b: 3.11.2
3.11.2: Local parameters - wording issues

CHANGE FROM:

"Verilog HDL localparam - local parameter(s) are identical to parameters except
that they can not directly be modified with the defparam statement or by the
ordered or named parameter value assignment. Local parameters can be assigned
to a constant expression containing a parameter which can be modified with the
defparam statement or named parameter value assignment. See 12.1.3 for details."

TO:

"Verilog HDL localparam - local parameter(s) are
identical to parameters except that they can not directly be
modified by defparam statements (12.2.1)
or module instance parameter value assignments (12.2.2).
Local parameters can be assigned constant expressions
containing parameters, which CAN be modified with
defparam statements or module instance parameter
value assignments."

("CAN" is an emphasis which I suppose is done in the LRM
with italics.)

Note: further issues in issue #211.
151 lrmdraft
2001b: 1.3f
1.3f uses bad example

In section 1.3f, replace each of the three
occurrences of "constant_expression" with "index".
152 lrmdraft
2001b: 12.2.1, 12.2.2.2
12.2.1, 12.2.2.2: "it's" should be "its"

In 12.2.1, last sentence, change "it s" to "its".

In 12.2.2.2, first sentence, change "it's" to "its".
153 lrmdraft
2001b: 12.3.3 (Syntax 12-6), A.2.1.2
12.3.3, A.2.1.2: output_declaration is ambiguous

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 lrmdraft
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.
155 lrmdraft
2001b: 2.8.2 (Syntax 2-4), 12.1 (Syntax 12-1), A.1.3
A.1.3, module_declaration ambiguous

Section A.1.3
Passed 11/18/02 by ETF:
Remove the square brackets around the
list_of_ports element in the old style
module_declaration production.

REPLACE:
module_declaration ::=
{ attribute_instance } module_keyword module_identifier
[ module_parameter_port_list ]
[ list_of_ports ] ; { module_item }
endmodule
| { attribute_instance } module_keyword module_identifier
[ module_parameter_port_list ]
[ list_of_port_declarations ] ; { non_port_module_item }
endmodule

WITH:
module_declaration ::=
{ attribute_instance } module_keyword module_identifier
[ module_parameter_port_list ]
list_of_ports ; { module_item }
endmodule
| { attribute_instance } module_keyword module_identifier
[ module_parameter_port_list ]
[ list_of_port_declarations ] ; { non_port_module_item }
endmodule

156 lrmdraft
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 }".
158 lrmdraft
2001b: 27.32
Section 27.32 vpi_put_value() w/vpiReleaseFlag; Whose data?

Part I:

In the first paragraph of 27.32 vpi_put_value():

REPLACE the 2nd sentence which reads:

"The value to be set shall be stored in an s_vpi_value structure that
has been allocated."

WITH:

"The value to be set shall be stored in an s_vpi_value
structure that has been allocated by the calling routine.
Any storage referenced by the s_vpi_value structure shall
also be allocated by the calling routine.

The delay time before the value is set shall be stored in
an s_vpi_time structure that has been allocated by the
calling routine.


Part II:

In the description of the "vpiReleaseFlag" in the table
following the first paragraph of 27.32 vpi_put_value():

REPLACE the last sentence:

"The value_p shall be updated with the value of the object
after its release."

WITH:

"The value_p shall be updated with the value of the object
after its release. If the value is a string, time,
vector, strength or miscellaneous value, the data pointed
to by the value_p argument shall be owned by the
interface."
159 lrmdraft
2001b, many
footnote numbering in syntax boxes

Shalom (editor) to implement the replacement back to what we had
before the IEEE's changes.
160 lrmdraft
2001a,b
PDF bookmarks


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

161 lrmdraft
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.

163 lrmdraft
2001a,b: passim
document formatting problems


A. "em dashes": dealt with separately in issue #169.

B. line overruns:
The editor will search thru the document for all such cases,
submit a list, and deal with each of them one by one.

C. Extra space after "[" in code font:
Change all CourierNew fonts to Courier font, globally.

D. PLI code cut off: Fixed already in 2001b.
Any unfixed places should be reported to the editor.

E. Smart quotes in code text:
The editor will change them to straight up-down quotes.
See issue #116.

F. Disappearing apostrophes: like part A.
Editor will search for apostrophes in TimesNewRoman font,
and change them to Times font.
(fixed by #169)

G. Other disappearing sepcial characters:
The special footnote characters in Syntax 12-7 were fixed by
changing them to letters.
"Em dashes" and apostrophes are dealt with separately.
Other special characters which did not print should be
brought to attention of the editor.
(fixed by #169)

165 lrmdraft
2001b: 3.11.1, A.2.1.1, 10.2.1, A.2.7
3.11.1, A.2.1.1: reuse task_port_type

1. In 3.11.1 (Syntax 3-4) and in A.2.1.1

REPLACE

local_parameter_declaration ::=
localparam [ signed ] [ range ] list_of_param_assignments
| localparam integer list_of_param_assignments
| localparam real list_of_param_assignments
| localparam realtime list_of_param_assignments
| localparam time list_of_param_assignments

parameter_declaration ::=
parameter [ signed ] [ range ] list_of_param_assignments
| parameter integer list_of_param_assignments
| parameter real list_of_param_assignments
| parameter realtime list_of_param_assignments
| parameter time list_of_param_assignments

(Note: #114 deleted ";" at end of these lines.)

WITH

local_parameter_declaration ::=
localparam [ signed ] [ range ] list_of_param_assignments
| localparam parameter_type list_of_param_assignments

parameter_declaration ::=
parameter [ signed ] [ range ] list_of_param_assignments
| parameter parameter_type list_of_param_assignments

parameter_type ::= integer | real | realtime | time



2. In 10.2.1 (Syntax 10-1) and A.2.7, CHANGE

task_port_type ::=
time | real | realtime | integer

TO

task_port_type ::=
integer | real | realtime | time

(This simply changes order to alphabetical.)


(I had considered changing the names of real_type and
variable_type, but I did not find a good replacement, so I
did not change them.)
166 lrmdraft
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."

167 lrmdraft
2001b: 25.13, 25.31
2001b, 25.13, 25.31: tf_error and tf_message outside checktf

Section 25.13 on tf_error(), add the following paragraph to the end of the section:
"When tf_error() is called from a sizetf, calltf, or misctf application, the message shall be reported, but no other action shall be taken."

Section 25.31 on tf_message(), add the following paragraph just before the third paragraph, which begins with "The facility and code fields shall be string arguments...":
"When tf_message() is called with any severity level from a sizetf, calltf, or misctf application, the message shall be reported, but no other action shall be taken."
168 lrmdraft
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."
169 lrmdraft
2001b: passim
passim: more em dashes don't print in 2001b

Change all TimeNewRoman to Times.

171 lrmdraft
2001b: 19.4
19.4 `ifdef - followup to #15


19.4 paragraph appears twice:

"Although the names of compiler directives are contained in the same
name space as text macro names, the names of compiler directives are considered
not to be defined by `ifdef, `ifndef, and `elsif."

FIX:
Remove first copy of paragraph.

REPLACE occurances of "ifdef", "ifndef",
"elsif", and "else" in fixed-font (without
back-tic) in 19.4, in paragraphs beginning with "The `ifdef,
`else, `elsif, and `endif compiler directives work together in
the following manner:"

WITH:
"`ifdef", "`ifndef", "`elsif", and
"`else" in Bold Times font (with back-tic).

173 lrmdraft
2001b: 1.4, 2.5.1, 3.1, 7.10.1, 7.10.2, passim
misc typos

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

2. Section 2.5.1: This piece of the proposal is covered by 116.

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

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

5, 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.

6. Entire document:
Change all Clause titles to Helvetica 14 point
including the number.
174 lrmdraft
2001b: 3.2.1 (Syntax 3-1), A.2.2.3
3.2.1, A.2.2.3 -- delay_value ambiguous

Sections 3.2.1, A.2.2.3:
11/18/02 - Passed by ETF

REPLACE (note '()' are bold):
delay3 ::= # delay_value | #( delay_value [ , delay_value [ ,delay_value ] ] )
delay2 ::= # delay_value | #( delay_value [ , delay_value ] )
delay_value ::=
unsigned_number
| parameter_identifier
| specparam_identifier
| mintypmax_expression

WITH (note '()' are bold):
delay3 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression [, mintypmax_expression]])
delay2 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression])
delay_value ::= unsigned_number
| real_number
| identifier

176 lrmdraft
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   

177 lrmdraft
2001b: 12.1.3.4 (Example 8)
12.1.3.4, Example 8 (again): ba instead of ba[0]

Section 12.1.3.4 Example 8:

In the secon