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 second generated instance change:

sms_16b2080

to
sms_16b208t0

On the second line of both instantiations of the
sms memory change:

.ba(ba[0])
to
.ba(ba)

On the first line of the task read_mem starting with
word[3], and at the line starting "byte[7]".... at
the end of the line add a comment:

// read_mem in sms module

* Fit the example on 1 page
* Fix the indentation in both instances of read_mem.

* Delete the last part of the example between
the first endmodule and section 12.2
179 lrmdraft
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)."
180 lrmdraft
2001b: 14.3.2
14.3.2: "s ' x" should be "s -> x"

In 14.3.2, 2nd para., items (a) and (b), before Table 48,
change

"s ' x"
to
"s -> x"

and change

"x ' s"
to
"x -> s"


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

The following is incorporated in and superceded by #123.

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 lrmdraft
2001b, 9.7 (Syntax 9-8), 9.7.7 (Syntax 9-12), A.6.5, Syntaxes 9-1, 9-2
Syntax 9-8: event_control

In A.6.5 and Syntaxes 9-1, 9-2, 9-8, 9-12 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

184 lrmdraft
2001b: 23.4
23.4: "the an" should be "the"

23.4, para.4:

"Otherwise, it can be more efficient to use the an acc_next_ routine directly."

"the an" should be "the specific".
185 lrmdraft
2001b: 23.21, 23.22, 23.34, 23.36, 23.48
23.21-48: Bad Table and Figure cross-references

Fix the following cross-references from the text to Tables
and Figures:

In 23.21, "Table 141" should be "Table 145".
In 23.22, "Table 141" should be "Table 146".
In 23.34, "Table 143" should be "Table 156".
In 23.48, "Table 141" should be "Table 164".

In 23.36, "Figure 96" (in para. before Fig. 97)
should be "Figure 97".
186 lrmdraft
2001b: 23.26, 23.33, 25.26, 25.27
23.26, 23.33, 25.26-27: "s" should be "us"

In Tables 150, 155, 190, and 191,

CHANGE "s" to "us" for -4, -5, -6.
187 lrmdraft
2001b: 23.27 (Figure 89)
23.27, Fig. 89: missing comma at end of code line

Add comma after '"%s %s %s"'.
188 lrmdraft
2001b: 23.28 (Figure 90)
23.28, Fig. 90: extra colon at end of code line?

Delete 2nd colon at end of specified line.

192 lrmdraft
2001b: 3.3.1, 3.10, 4.2.1, 4.2.2
3.3.1: are real values for ranges allowed?

Slight modifications:

1. In 3.3.1:

REPLACE the 2nd paragraph:

"Both msb constant expression and lsb constant expression shall be
constant expressions. The msb and lsb constant expressions can be
any value -- positive, negative or zero. The lsb constant expresson
can be a greater, equal, or lesser value than the msb constant
expression."

WITH:

"Both the msb constant expression and the lsb constant expression
shall be constant integer expressions. The msb and lsb constant
expressions can be any integer value -- positive, negative or
zero. The lsb value may be greater than, equal to, or
less than the msb value."


2. In 3.10, para. 2, change sentence 5 FROM:

"The expression(s) that specify the indices of the array shall be constant
expressions."

TO:

"The expressions that specify the indices of the array shall
be constant integer expressions."


3. In 4.2.1, in para. 3, CHANGE

"Both expressions shall be constant expressions."

TO

"Both the msb_expr and lsb_expr shall be constant integer
expressions."


In para. 5, CHANGE:

"The width_expr shall be a constant expression. It also
shall not be affected by run-time parameter assignments."

TO:

"The msb_base_expr and lsb_base_expr shall be integer
expressions, and the width_expr shall be a positive constant
integer expression."
(Note: This supercedes the fix of issue #228, part 1).


4. In 4.2.2:

In para. 5, CHANGE

"The addr_expr can be any expression;"

TO:

"The addr_expr can be any integer expression".


In para. 9, CHANGE:

"The syntax for access to the array ... an expression for each addressed
dimension:"

TO:

"The syntax for access to the array ... an integer expression for each addressed
dimension:"


In para. 10, CHANGE:

"As before, the addr_expr can be any expression."

TO:

"As before, the addr_expr can be any integer expression."


5. New issue (#395) filed with problems found in 3.9.1.
193 lrmdraft
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 lrmdraft
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 ]

195 lrmdraft
2001b: 3.11.3
3.11.3: last example has syntax errors

REPLACE:

module RAM16GEN (DOUT, DIN, ADR, WE, CE)

WITH:

module RAM16GEN (output [7:0] DOUT, input [7:0] DIN,
input [5:0] ADR, input WE, CE) ;
196 lrmdraft
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 } ';'

197 lrmdraft
2001b: 17.2.4.3
17.2.4.3: sscanf/"string" incompatibility


This is Charles Dawson's proposal from Jan. 12, 2004.

In 17.2.4.3, following "The control string can contain"
(end of 4th paragraph following the syntax).

CHANGE

"a)White-space characters (blanks, tabs, new-lines, or
form-feeds) that, except in one case described below, cause
input to be read up to the next non-white-space character."

TO

"a) White-space characters (blanks, tabs, new-lines, or
form-feeds) that, except in one case described below, cause
input to be read up to the next non-white-space character.
For $sscanf, null characters shall also be considered
white-space."


(Note that this change also affects null characters that
are embedded within the string.)

200 lrmdraft
2001b: 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 ]

205 lrmdraft
2001b: 2.8, 3.12
2.8, 3.12: Attribute names can/cannot be redefined

In the third paragraph of section 3.12:

REPLACE

"Once a name is defined within one of the five name spaces,
it shall not"

WITH

"Once a name is defined within the block,
module, port, or specify block name
spaces, it shall not"


Add the following sentence to the end of that same paragraph:

"As described in 2.8, it is legal to redefine names within
the attribute name space."

(Of course, use a reference for the reference to 2.8 in the
above sentence)
206 lrmdraft
2001b: 9.2.1, 9.2.2, 9.3.1, 9.7.3, 9.7.5
9.2, 9.3, 9.7: editorial bugs

1. In 9.7.5, 2nd bullet of para. 2, change
"hierarchical_reg_identifier" to
"hierarchical_variable_identifier".

2. Similarly, change "reg_lvalue" to "variable_lvalue" in:

9.7.5, para. 2, bullet 2
9.2.1, para. 3, twice
9.2.2, para. 3, thrice

3. The wording of 9.2.1, para. 3 and 9.2.2, para. 3 should
be more similar. A separate issue will be filed on this.

4. 9.7.3, end of next to last para: "-> trig)" should be on
same line as previous word.

5. 2001b only: 9.7.5, Example 6: fix indentation and
alignment, font type ("case") and bolding of keywords
("if", "or").

6. Also, in 9.3.1, para. 1, sentence 3, change "reg" to
"variable".
207 lrmdraft
2001b: 17.9.3, 26.6.9, E, F, G
"1364-2000" should be "1364-2001"

"1364-2000" appears a number of times.
It should be "1364-2001".

Places:
17.9.3 code header
Annex E header
Annex F header
Annex G header and many places in code
26.6.9 footnote
208 lrmdraft
2001b: 12.4 (Syntax 12-7), A.9.4
12.4, A.9.4: no negative indexes in hierarchical_identifiers

In Syntax 12-7 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_identifier [ "[" constant_expression "]" ]
{ .simple_identifier [ "[" constant_expression "]" ] }

escaped_hierarchical_branch ::=
escaped_identifier [ "[" constant_expression "]" ]
{ .escaped_identifier [ "[" constant_expression "]" ] }

When text is written for issue #247 explaining hierarchical
references to instance arrays, the text should mention that
the ranges and indices must be INTEGER expressions.
209 lrmdraft
2001b: 12.4 (Syntax 12-7), A.9.3, A.9.4
12.4, A.9.3: simple, escaped hierarchical_identifiers difference

The original issue is resolved by going back to basic
elements and redefining hierarchical_identifier more simply.

DELETE:

simple_hierarchical_identifier AND
escaped_hierarchical_identifier in Syntax 12-7 and A.9.3

simple_hierarchical_branch AND
escaped_hierarchical_branch in Syntax 12-7 and A.9.4


REPLACE hierarchical_identifier in Syntax 12-7 and A.9.3 with the following:

hierarchical_identifier ::=
{ identifier [ "[" constant_expression "]" ] "." } identifier

That is, a hierarchical_identifier is composed of an identifier optionally
preceded by a sequence of zero or more of the following: an identifier, one
optional constant (integer) index, and a period.

Each identifier part of an hierarchical_identifier can be either a
simple_identifier or an escaped_identifier, and there is no need to
distinguish between simple and escaped hierarchical_identifiers or
simple and escaped hierarchical_branches.

This proposal also assumes the changes proposed in issue #257
and also supercedes the proposal in issue #208.

211 lrmdraft
2001b: 3.11.2, 12.2.2.1, 12.2.3
3.11.2: localparam behavior not clear

This comes to update the proposal to #211 according to
Shalom's comments on James's proposal.
However, it is not in a final state.
It still needs to be refined according to Steven Sharp's
comments.


In 12.2.2.1

Add the following to the end of the section:

Local parameters cannot be overridden, therefore, they are not
considered part of the ordered list for parameter value assignment.
In the following example, addr_width will be assigned the value of 12
and data_width will be assigned the value of 16. mem_size will not be
explicitly assigned a value due to the ordered list, but will have
the value 4096 due to its declaration expression.

module my_mem (addr, data);

parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule


In 12.2.3

Add the following sentence between the first and second sentences:

However, overriding a parameter, whether by a defparam
statement or in a module instantiation statement,
effectively replaces the parameter definition with
the new expression.

Add the following sentence to the paragraph:

If memory_size is updated due to either a defparam or instantiation
statement, then it will take on that value, regardless of the value
of word_size.
214 lrmdraft
2001b: 23.90
23.90: wrong comment in Figure 151?

Replace "typical" by "min:typ:max" in the three places.
216 lrmdraft
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."


217 lrmdraft
2001b
Note that task/func params can only be overridden by defparams

Add the following paragraph to the end of 12.2.2:

"A parameter declared in a named block, task or function
can only be directly redefined using a defparam statement.
However, if the parameter value is dependent on a second
parameter, then redefining the second parameter
will update the value of the first parameter as well
(see 12.2.3)."
218 lrmdraft
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 lrmdraft
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 lrmdraft
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".
223 lrmdraft
2001b: 9.5, 17.10
9.5, 17.10: typos

9.5: In Note, CHANGE "is same" to "is the same".

17.10: At end of para. 1: CHANGE "the starting" to "their starting".
224 lrmdraft
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 ]

225 lrmdraft
2001b: 12.3.3
12.3.3: The fourth port direction

Add the example:

module mixed_direction (.p({a, e}));
input a; // p contains both input and output directions
output e;

226 lrmdraft
2001b
Illegal to assign mintypmax expression to parameter?

In A.2.4

REPLACE

param_assignment ::=
parameter_identifier '='
constant_expression

WITH

param_assignment ::=
parameter_identifier '='
constant_mintypmax_expression

and in Syntax 12-2 and A.4.1

REPLACE

ordered_parameter_assignment ::= expression
named_parameter_assignment ::=
'.' parameter_identifer
'(' [ expression ] ')'

WITH

ordered_parameter_assignment ::= mintypmax_expression
named_parameter_assignment ::=
'.' parameter_identifer
'(' [ mintypmax_expression ] ')'

228 lrmdraft
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,
starting with "reg [31:0] big_vect;" through line beginning with
"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)

231 lrmdraft
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 lrmdraft
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]})] ;

235 lrmdraft
2001b: 8.1.6 (Table 40)
Table 40 (8.1.6): UDP output should allow X

Section 8.0 fifth paragraph is even clearer on allowing X. It states:
"Each UDP has exactly one output, which can be in one of three states; 0, 1 or x."

Change the comment on line 3 in Table 40 to read:
Permitted in the input and output fields of all UDPs and in the current state field of sequential UDPs.
238 lrmdraft
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 lrmdraft
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."

242 lrmdraft
2001b: 23.9, 27.15
23.9, 27.15: Is -f standard ?

Section 23.9 acc_fetch_argv
page 425 (second paragraph)
Replace :
The argument following a -f argument shall contain a pointer
to a NULL terminated array of pointers to characters. This
new array shall contain the parsed contents of the file.
The value in entry zero shall contain the name of the file.
The remaining entries shall contain pointers to NULL
terminated character arrays containing the different options
in the file. The last entry in this array shall be a NULL.
If one of the options is a -f then the next pointer shall
behave the same as described above.


With:
"The vendor tool may provide a command line option to pass
a file containing a set of options. In that case, the
argument strings returned by acc_fetch_argv() shall contain
the vendor option string name followed by a pointer to a
NULL terminated array of pointers to characters. This new
array shall contain the parsed contents of the file. The
value in entry zero shall contain the name of the file.
The remaining entries shall contain pointers to NULL
terminated character arrays containing the different
options in the file. The last entry in this array shall be
NULL. If one of the options is the vendor file option,
then the next pointer shall behave the same as described
above.


Section 27.15 vpi_get_vlog_info
page 682 last paragraph:
Replace :
The argument following a -f argument shall contain a pointer
to a NULL terminated array of pointers to characters. This
new array shall contain the parsed contents of the file.
The value in entry zero shall contain the name of the file.
The remaining entries shall contain pointers to NULL
terminated character arrays containing the different options
in the file. The last entry in this array shall be a NULL.
If one of the options is a -f then the next pointer shall
behave the same as described above.


With:
"The vendor tool may provide a command line option to pass
a file containing a set of options. In that case, the
argument strings returned by vpi_get_vlog_info() shall
contain the vendor option string name followed by a pointer
to a NULL terminated array of pointers to characters. This
new array shall contain the parsed contents of the file.
The value in entry zero shall contain the name of the file.
The remaining entries shall contain pointers to NULL
terminated character arrays containing the different options
in the file. The last entry in this array shall be NULL.
If one of the options is the vendor file option, then the
next pointer shall behave the same as described above.
243 lrmdraft
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."

244 lrmdraft
2001b: 12.1.2 (Syntax 12-2), A.4.1
A.4.1: change name_of_instance to name_of_module_instance

Change name_of_instance to name_of_module_instance in
Syntax 12-2 (2 places) and in A.4.1 (2 places).

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

251 lrmdraft
2001b: 27.37
27.37: struckout "stdout" should be deleted


Delete "stdout"

253 lrmdraft
2001b: 26.6.6, 26.6.7
typos in 26.6.6 note 19, 26.6.7 note 12

In 26.6.6 note 19
and 26.6.7 note 12,

delete one of the "in the"s.
257 lrmdraft
2001b: 12.4, 12.5, A.Notes
Should white space be allowed in hierarchical references?

Delete the restriction that hierarchical references may not
contain spaces.

Specifically:

1. In Syntax 12-7, DELETE the first and second footnotes

("The period in escaped_hierarchical_identifier and
escaped_hierarchical_branch shall be preceded by white_space,
but shall not be followed by white_space.",

"The period (.) in simple_hierarchical_identifier and
simple_hierarchical_branch shall not be preceded or followed
by white_space.")


2. In Section 12.5, DELETE the following paragraph:

"There shall be no spaces within the hierarchical name
reference, except for escaped identifiers embedded in the
hierarchical name reference, which are followed by
separators composed of white space and a period-character."


3. In the NOTES following A.9.5, DELETE Notes 3 and 4.

(These notes are the same as footnotes 1 and 2 in Syntax
12-7, quoted above.)
258 lrmdraft
2001b: 12.3.2, 12.3.4, 12.3.6
12.3.4: "simple identifier" is misleading

In 12.3.4 (para before last) REPLACE

"Also ports declared using the
list_of_port_declarations
shall only be simple identifiers."

WITH

"Also ports declared using the
list_of_port_declarations
shall only be simple identifiers
or escaped identifiers."


In 12.3.2 (end) REPLACE

"Use of named port connections
shall not be used for implicit ports
unless the port_expression is a simple
port_identifier."

WITH

"Named port connections
shall not be used for implicit ports
unless the port_expression is a simple
identifier or an escaped identifier,
which shall be used as the port name."

AND "port_expression" should be in a constant-width
font, rather than italicized.


In 12.3.6 (para 1), REPLACE

"If the module port declaration was implicit,
the port_expression shall be a simple
port_identifer which is used as the port name."

WITH

"If the module port declaration was implicit,
the port_expression shall be a simple identifier
or escaped identifier, which shall be used as the
port name."

259 lrmdraft
2001b: Syntax 19-2, A.9.3
19.3.1: Allow escaped identifiers as text macro names


In 19.3.1 (Syntax 19-2), and in A.9.3
CHANGE
text_macro_identifier ::= simple_identifier

TO
text_macro_identifier ::= identifier


In 19.3.1, paragraph 9, DELETE the sentence:

"The text macro name shall be a simple identifier."


In 19.4, paragraph 6, CHANGE the first sentence FROM:

"The text_macro_identifier is a Verilog HDL simple_identifier."

TO:

"The text_macro_identifier is a Verilog HDL identifier."
260 lrmdraft
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 %%)"

261 lrmdraft
2001b
Clarify whether a is the same as a[0:0] when a is a scalar?

In section 4.2.1, CHANGE the last sentence of the first
paragraph FROM

"The bit-select or part-select of a variable declared as
real or realtime shall be considered illegal."

TO

"A bit-select or part-select of a scalar, or of a variable
declared as real or realtime, shall be illegal."

(The words "real" and "realtime" should be in keyword font.)
262 lrmdraft
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 lrmdraft
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 lrmdraft
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".

265 lrmdraft
2001b: 9.2.2, 5.4.1(2)
9.2.2: misc editorial fixes


In 9.2.2:

1.In paragraph preceding Example 4 ("The order of the
execution of distinct nonblocking assignments to a given
variable shall be preserved"), add a reference to 5.4.1(2),
and a reference from 5.4.1(2) to 9.2.2.

2. In last comment unnamed of example preceding Example 6,
delete word "endmodule" at end of line.

3. Rearrange the comments in that same example (indentation,
line breaks) to be much more readable and orderly. Also, the
top of the first line in the example is slightly cut off,
fix it.

4. Rename this as Example 6, and change the next one from
Example 6 to Example 7.

5. Rename the modules in Examples 4 to 7 in
order from "multiple" to "multiple4".

6. Fix the boxes in the figure preceding Section 9.3.
267 lrmdraft
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 lrmdraft
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"
270 lrmdraft
2001b: 9.7, 12.2
9.7, 12.2: keyword "or" should be bold

1. "or", when used as a keyword in a @(a or b) construct,
should be bold.

Fix non-bold cases in 9.7.4, 9.7.5, end of 9.7.7,
and in 12.2.


2. Also, there is an unneeded page break in the middle of
9.7.7. Delete it.
271 lrmdraft
2001b: 26.3.3, 26.6.1
26.3.3, 26.6.1 refer to `file directive

Proposal:
Since there is no `file compile directives, we should remove the mention of it in the PLI sections.


Resolution:
REPLACE:
Section 26.3.3

The properties vpiLineNo and vpiFile can be affected by the ‘line and ‘file compiler directives. See Section 19 for
more details on these compiler directives.

WITH:
The properties vpiLineNo and vpiFile can be affected by the ‘line compiler directive. See Section 19.7 for
more details on the 'line compiler directive.

REPLACE:
Section 26.6.1 Module:
Note #3:
3—The properties vpiDefLineNo and vpiDefFile can be affected by the `line and `file compiler directives. See Section 19 for
more details on these compiler directives.

WITH:
Note #3:
3—The properties vpiDefLineNo and vpiDefFile can be affected by the `line compiler directive. See Section 19.7 for
more details on the 'line compiler directive.
275 lrmdraft
2001b: 15.2.3, 15.2.6
15.2.3, 15.2.6: "timecheck" should be timestamp"


In 15.2.3, paragraphs 9, CHANGE:

"(beginning of time window) < (timecheck time) <= (end of time window)"

TO:

"(beginning of time window) < (timestamp time) <= (end of time window)"

This changes "timecheck" to "timestamp".
Note that the quoted line occurs twice in this section.
Only the first should be changed.


The same change should be made in 15.2.6, paragraph 8.
There also, it occurs twice and only the first should be
changed.
276 lrmdraft
2001b: A.6.4
A.6.4: BNF doesn't allow fork/join in functions

In A.6.4,

REPLACE function_statement
WITH

function_statement ::= statement

plus a footnote that

"Function statements are limited by the rules of 10.3.4."

In A.6.2, REMOVE function_blocking_assignment.
In A.6.3 and Syntax 9-13, REMOVE function_seq_block.
In A.6.4, REMOVE function_statement_or_null.
In A.6.6 and Syntax 9-4, REMOVE function_conditional_statement.
In A.6.6 and Syntax 9-5, REMOVE function_if_else_if_statement.
In A.6.7 and Syntax 9-6, REMOVE function_case_statement.
In A.6.7 and Syntax 9-6, REMOVE function_case_item.
In A.6.8 and Syntax 9-7, REMOVE function_loop_statement.

In 10.3.4, REPLACE

"a) A function definition shall not contain
any time-controlled statements, that is,
any statements introduced with #, @, or wait."

WITH

"a) A function definition shall not contain
any time-controlled statements, that is,
any statements containing #, @, or wait."

and REPLACE

"f) A function shall not have any nonblocking
assignments"

WITH

"f) A function shall not have any nonblocking or
procedural continuous assignments."

and ADD the following rule --

"g) A function shall not have any event triggers."

Note that this issue supercedes #229
(which was controversial).
277 lrmdraft
2001b: 3.9, 3.9.1
3.9: bad references, etc.


In 3.9:

- Para. 3: Change
"The syntax for list of reg variables" to
"The syntax for a list of reg variables".

- Para. 9, bullet 1: Change
"See Table 17 for lists of valid and invalid operators for real numbers and real variables." to
"See Table 10 and Table 11 for lists of valid and invalid operators for real numbers and real
variables."

- Para. 9, bullet 2: Add period at end of line.

In 3.9.1:

- Change:
"Table 4-9 lists the valid operators for use with real numbers and real variables." to
"Table 10 lists the valid operators for use with real numbers and real variables."

- In bullet 1, "Edge descriptors (posedge, negedge) applied to real variables",
change "posedge" to "negedge" to bold keyword font.

- In bullet 2, "Bit-select or part-select references of variables declared as real",
change "real" to bold keyword font.
282 lrmdraft
2001b: 4.5
4.5: sign extension and bit-length rules not clear enough

Proposal for expression signedness and sizing issues

Commentary:

This is a stab at clarifying the description of how context-determined
signedness and expression sizing works (a variety of errata). It also
covers how reals work (erratum 83), and the special behavior of compares.
It may not be adequate to resolve the issues, but it is an attempt. It
was done in a hurry, so there may be problems with it. Insert more
disclaimers here.

The new text refers to a "primary" from the grammar. For some reason,
"primary" does not include a string. Instead, strings are listed separately
as expressions. This is apparently an error in the grammar, since it
prevents the use of unary operators on strings, which should be legal. The
new text assumes that this will be fixed; otherwise it needs to say
"primary or string".

Changes:

In 4.5.2, CHANGE:

-- Coerce the type of each operand of the expression (excepting those which
are self-determined) to the type of the expression.
-- Extend the size of each operand (excepting those which are self-determined)
to the size of the expression. Perform sign extension if and only if the
operand type (after type coercion) is signed.

TO:

-- Propagate the type and size of the expression (or self-determined sub-
expression) back down to the context-determined operands of the expression.
In general, any context-determined operand of an operator is the same
type and size as the result of the operator. However, there are two
exceptions:
- If the result type of the operator is real, and it has a context-
determined operand that is not real, that operand is treated as if
it were self-determined and then converted to real just before the
operator is applied.
- The relational and equality operators have operands that are neither
fully self-determined nor fully context-determined. The operands affect
each other as if they were context-determined operands with a result
type and size (maximum of the two operand sizes) determined from them.
However, the actual result type is always 1 bit unsigned. The type
and size of the operands is independent of the rest of the expression
and vice-versa.
-- When propagation reaches a simple operand as defined in 4.2 (a primary
as defined in A.8.4), then that operand is converted to the propagated
type and size. If the operand must be extended, then it is sign-extended
only if the propagated type is signed.
283 lrmdraft
2001b: 2.5.1
Syntax 2-1: 'dx, 'dz

In 2.5.1 before the paragraph about '_', add the
following paragraph --

"In a decimal constant, the unsigned number token
shall not contain any x, z, or ? digits, unless
there is exactly one digit in the token,
indicating that every bit in the decimal constant
is x or z."

and at the end of Example 3 of 2.5.1 add the following
line --

16'sd? // the same as 16'sbz

284 lrmdraft
2001b: 13.6, 26.6, Annex G
errata/284: vpiUseBinding not defined in Annex G

remove the line:

vpiUseBinding - the library.cell binding information for a
module instance

from section 13.6.

In the second paragraph of section 13.6, "new vpiProperties" should be "VPI properties". Also the font should match that of the rest of the sentence.

286 lrmdraft
2001b: 26.6
26.6.25: vpiBitSelect is not defined

The label to the one to one transition from simple expr
to the unnamed class on the right hand side of the diagram
should be changed from:

vpiIParent

to

vpiParent

288 lrmdraft
2001b: 4.1.14
4.1.14: replication operator and function calls

REPLACE

If the replication operator is used on a function
call operand, the function need not be evaluated
multiple times. For example:

result = {4{func(w)}

may be computed as

result = { func(w), func(w), func(w), func(w)}

or

y = func(w) ;
result = { y, y, y, y}

This is another form of expression evaluation
short-circuiting.

WITH

When a replication expression is evaluated, the
operand shall be evaluated exactly once, even if
the replication constant is zero.

294 lrmdraft
2001b: 26.6.42
vpiDefAttribute on non-modules 26.6.42

26.6.42 add:
NOTE: The property vpiDefAttribute shall return true if the
attribute was defined on a module as part of the module
definition. The property shall return false for attributes
defined on a module as part of a module instantiation or for any other object other than a module.
295 lrmdraft
2001b: A.1.5
A.1.5: Attribute on generated_instantiation

In section A.1.5, and in Syntax 2-6, 12-1, 12-3,
in the rules for module_item and non_port_module_item,
remove "{attribute_instance}" from before
generated_instantiation. Specifically, in module_item
and non_port_module_item,

CHANGE

| {attribute_instance} generated_instantiation

TO

| generated_instantiation
303 lrmdraft
2001b: 26.6.25
26.6.25: incorrectly italicized words


In 26.6.25, Simple expressions diagram:

In the right hand column "cont assign" and "cont assign bit"
are incorrectly italicized.

Remove italics.
304 lrmdraft
2001b: 26.6.26
26.6.26: "parenthesis" should be "parentheses"

In 26.6.26 Expressions

In Note 2 - parenthesis" should be
"parentheses" (plural) in both places where the word appears.

Change "parenthesis" to "parentheses" in both places.
305 lrmdraft
2001b: 26.6.31
26.6.31: Redundant note


Delay control (26.6.29) and Event control (26.6.31) each
have a NOTE about assignments and NULL.

The NOTE in 26.6.31 reiterates the same information.
This is redundant.

Remove the note in 26.6.31.
306 lrmdraft
2001b: 26.6.40
26.6.40: Time queue - note 3 improperly worded

In 26.6.40, Note 3,

CHANGE

If any events after read only sync remain in the current time queue, then it shall not be returned as part of the iteration.

TO

The current time queue shall only be returned as part of the
iteration if there are events that precede read only sync.
308 lrmdraft
2001b: 9.7.2
9.7.2 ambiguous about @r when r is a vector

AS REVISED AND PASSED BY ETF ON 2004-11-01:

In 9.7.2,

CHANGE

"If the expression evaluates to more than a 1-bit result, the edge transition
shall be detected on the least significant bit of the result. The change of
value in any of the operands without a change in the value of the least
significant bit of the expression result shall not be detected as an edge."

TO

"An implicit event shall be detected on any change in the value of the
expression. An edge event shall be detected only on the least
significant bit of the expression. A change of value in any operand
of the expression without a change in the result of the expression
shall not be detected as an event."


Also, in 9.7.7,

DELETE

"The event expression shall be resolved to a 1-bit value."

309 lrmdraft
2001b: 19.4 (Example 3)
19.4, Example 3: two run-on $display lines


In 19.4, Example 3,

CHANGE THE LINES

`ifndef last_result
   initial $display("first_block, second_block, last_result
              not defined.");
`elsif real_last
   initial $display("first_block, second_block not defined,
              last_result and real_last defined.");


such that each of the 2 $display statements is split over 2
lines with each line beginning and ending with double quotes.

310 lrmdraft
2001b: 3.9.2, 6.2, 17.2.4.3, 26.3.3, etc.
wrong or poor xrefs

(I added in E2, that the same correction should be made at
tne end of 17.2.4.3)

A. In 3.9.2, para. 3, change the xref in
"See Clause 17 for a discussion of system tasks that perform
explicit conversion." to "17.8".

B. In 6.2, para. 3, change "always, initial (see Clause 9)"
to "always, initial (see 9.9)".

C. In 17.2.4.3, format specification "z",
change "Figure 27-8" to "Figure 179".

D. Duplicates #271.

E1. At the end of the first line of 2.8.2,
"Syntax 2-4 -- Syntax 2-11" should be
"Syntax 2-4 -- Syntax 2-9".

E2. In 17.2.4.2 and 17.2.4.3, last line:
"(see below)" should be "(see 17.2.7)".

F. In 17.6.1-17.6.3, the 3 references to Table 79 should be
to Table 81.

G. In 22.8.2, end of para. 1, reference to Table 115 should
be to Table 116.

H. In 23.6, last para.,
"acc_replace_delays" should be "acc_append_delays".

I. In 23.18, para. 1,
reference to Figure 84 should be to Figure 77.

J. In 23.24, last para.,
"acc_fetch_paramtype()" should be "acc_fetch_paramval()".

K. In 23.33, para. 2,
the reference to Figure 82 should be to Figure 93.

L. Duplicates #185.
317 lrmdraft
2001b:3.10
3.10: max array size not clear enough

In 3.10, in the final sentence before 3.10.1,

CHANGE

"they shall at least be 16777216 (2^24)"

TO

"they shall allow at least 16777216 (2^24) elements"

320 lrmdraft
2001b: 26.6.7, 26.6.9
26.6: Should memories be of type vpiMemory or vpiRegArray?

This is a duplicate of 341.
322 lrmdraft
2001b: 14.5
14.5, para. 2: "Figure 40" should be "Figure 39"

In 14.5, para. 2, change xref from "Figure 40" to "Figure 39".
325 lrmdraft
2001b: 12.4
12.4 confused on hierarchy for automatics

In 12.4:

In the second paragraph, REPLACE

"Only non-recursively referenced automatic tasks and/or
functions create visible branches that can be referenced.
Recursively called tasks and functions, declared using the
automatic keyword and recursively called from within the
same task or function, do not create visible branches that
can be referenced. See 10.2.1 and 10.3.1 for a discussion
of automatic tasks and functions."

WITH

"Automatic tasks and functions are exceptions,
and do not create visible branches that can be referenced
(see 10.2.1, 10.3.1)."


In the fourth paragraph, REPLACE

"with the exception of items of automatic tasks and
automatic task item declarations. These declarations can
not be accessed by their hierarchical names."

WITH

". Objects declared in automatic tasks and functions are
exceptions, and cannot be accessed by hierarchical name references."
328 lrmdraft
2001b: 23.42
23.42: "acc_next_datapath" should be "acc_handle_datapath"


In 23.42, first paragraph, change
"acc_next_datapath()" to "acc_handle_datapath()".
331 lrmdraft
2001b: 19.3.1
19.3.1: when is a `define argument not an argument?

(The following is based on CPP documentation.)

In 19.3.1, after the text

"When formal arguments are used to define a text macro, the
scope of the formal argument shall extend up to the end of
the macro text. A formal argument can be used in the macro
text in the same manner as an identifier."

ADD the following new text:

"If formal arguments are used,
the list of formal argument names shall be enclosed in
parentheses following the name of the macro. The formal
argument names shall be simple_identifiers, separated by
commas and optionally whitespace. The left parenthesis shall
follow the macro name immediately, with no space in between."


After the text,

"For a macro without arguments, the text shall be
substituted "as is" for every occurrence of `text_macro_name.
However, a text macro with one or more arguments shall be
expanded by substituting each formal argument with the
expression used as the actual argument in the macro usage."

ADD the following new text:

"To use a macro defined with arguments, the name of the macro
shall be followed by a list of actual arguments in parentheses,
separated by commas. White space shall be allowed between the
macro name and the left parenthesis. The number of actual
arguments shall match the number of formal arguments. "

334 lrmdraft
2001b: 12.6, Example 2
12.7, Example 2: incorrect comment "redundant assignments to reg r"

12.7 Example 2 is almost completely incorrect.

So CHANGE

Example 2-The following example shows an incompletely defined downward reference that can be accessed.

task t;
reg r, s;
begin : b
t.b.r = 0; // poorly defined but found by upward search
t.s = 0; // fully defined downward reference
end
endtask

TO

Example 2-The following example shows how variables can be accessed
directly or with hierarchical names.

task t;
reg s;
begin : b
reg r;

t.b.r = 0; // These three lines access the same variable r
b.r = 0;
r = 0;

t.s = 0; // These two lines access the same variable s
s = 0;
end
endtask
335 lrmdraft
2001b: 23.24
23.24: "acc_fetch_paramtype" should be "acc_fetch_paramval" x 2

In 23.24, CHANGE
"acc_fetch_paramtype" TO "acc_fetch_paramval" twice,
in first and last paragraphs.

Case of last paragraph is covered by issue #310,
but case of first paragraph is new.
337 lrmdraft
2001b: A.1.5
A.1.5: BNF allows attribute on specify_block

In section A.1.5, and in Syntax 2-6, 12-1, 12-3,
in the rules for module_item and non_port_module_item,
remove "{attribute_instance}" from before "specify_block". Specifically, in module_item and non_port_module_item,

CHANGE

| {attribute_instance} specify_block

TO

| specify_block


338 lrmdraft
2001b: Syntax 14-4, A.7.4
Syntax 14-4, A.7.4: syntax of edge sensitive module path descriptions

In Syntax 14-4 and in A.7.4, the syntax of parallel_edge_sensitive_path_description
and full_edge_sensitive_path_description should be corrected as follows:

CHANGE

parallel_edge_sensitive_path_description ::= 
        "(" [ edge_identifier ] specify_input_terminal_descriptor "=>" 
        specify_output_terminal_descriptor [ polarity_operator ] ":" data_source_expression ")" 

TO 

parallel_edge_sensitive_path_description ::= 
        "(" [ edge_identifier ] specify_input_terminal_descriptor "=>" 
        "(" specify_output_terminal_descriptor [ polarity_operator ] ":" data_source_expression ")" ")" 

and

CHANGE

full_edge_sensitive_path_description ::= 
        "(" [ edge_identifier ] list_of_path_inputs "*>" 
        list_of_path_outputs [ polarity_operator ] ":" data_source_expression ")" 

TO

full_edge_sensitive_path_description ::= 
        "(" [ edge_identifier ] list_of_path_inputs "*>" 
        "(" list_of_path_outputs [ polarity_operator ] ":" data_source_expression ")" ")" 



The quotation marks around a symbol in the above mean it should be in bold font.

In both cases, the correction is an extra pair of parentheses around the outputs.
341 lrmdraft
2001b: 26.6.7, 26.6.9
How are two dimensional arrays of regs to be treated in VPI?

In order to reconcile a 2 dimensional array of regs,
formerly known as a memory, with arrays of regs with more
dimensions, I propose the following changes:

Make the following changes to section 26.6.1:

- Change the reference enclosure "memory" to "reg array"
- Add a "vpiMemory" label to the 1 to many iteration to
memory.

Make the following changes to section 26.6.3:
- Rename the memory solid enclosure as reg array
- Label the one to many transition from scope to
memory with vpiMemory.

Make the following changes to section 26.6.9:

- Change the definition enclosure "memory" to
a reference enclosure "reg array"
- Change the definition enclosure "memory word"
to a reference enclosure "reg"
- Add a label "vpiMemory" to the 1 to many iteration
from module and scope.
- Add a label "vpiMemoryWord" to the 1 to many iteration
from memory to memory word.
- Add a property to memory:

-> is a memory
bool: vpiIsMemory

- Remove the properties name and size from memory, as
they are duplicates of those in 26.6.7
- Remove the properties constant selection name, size,
and value from memory word, as they are duplicates of
those in 26.6.7.
- Replace the three notes with one that says:

The objects vpiMemory and vpiMemoryWord have been
generalized with the addition of arrays of regs. To
preserve backward compatibility, they have been
converted into methods which will return objects of
type vpiRegArray and vpiReg, respectively. See
section 26.6.7 for the definitions of regs and reg
arrays.

Make the following changes to section 26.6.19:

- Remove the memory solid enclosure in the unnamed
dotted enclosure accessed via vpiArgument

Make the following changes to section 26.6.25:

- Remove the 2 memory word reference enclosures.

Make the following changes to section 26.6.42:

- Remove the memory reference enclosure.

Make the following changes to section 26.6.43:

- Remove the memory reference enclosure.

Add the following to annex G:

- Immediately after vpiIndexedPartSelectType:

#define vpiIsMemory 73 /* TRUE for a one dimensional reg array */

Notes from proposer:

- The #define in the include file (annex G) may need
to be reconciled with other PTF items.
343 lrmdraft
2001b: 22.9.4
22.9.4: code example cut off at left side


In the code example in 22.9.4,
move the code a few characters to the right to expose the
cut-off text.
346 lrmdraft
2001b: A.2.6
A.2.6: no attributes on old-style function arguments

Change the production in A.2.6

FROM:

function_item_declaration ::=
block_item_declaration
| tf_input_declaration ;

TO:

function_item_declaration ::=
block_item_declaration
| {attribute_instance} tf_input_declaration ;
351 lrmdraft
2001b: 9.2.2, Example 7
9.2.2, Example 7: unclear comment

In 9.2.2, Example 7:

module multiple4;
reg r1;
reg [2:0] i;

initial begin
// starts at time 0, does not hold the block
r1 = 0;
// makes assignments to r1 without cancelling previous assignments
for (i = 0; i <= 5; i = i+1)
r1 <= # (i*10) i[0];
end
endmodule

DELETE the lines

"// starts at time 0, does not hold the block
r1 = 0; "

352 lrmdraft
2001b: 10.2.2
10.2.2 implies task arguments can be left off

CHANGE:

The list of arguments for a task enabling statement shall
be optional. If the list of arguments is provided, the
list shall be an ordered list of expressions that has to
match the order of the list of arguments in the task
definition.

TO:


If the task definition has no arguments, a list of arguments
shall not be provided in the task enabling statement. Otherwise,
there shall be an ordered list of expressions that matches the
length and order of the list of arguments in the task definition.
A null expression shall not be used as an argument in a task
enabling statement.
354 lrmdraft
2001c: 17.2.8
17.2.8: There is no $feof function

PROPOSAL revised and passed by BTF:

ADD to list of File I/O tasks in introduction of section 17:

$feof


ADD new section:

17.2.8 Detecting end of file

integer code;
code = $feof ( fd );

Returns a non-zero value when EOF has previously been detected reading
the input file fd. Returns zero otherwise.


ADD correct bolding to this new section.

CHANGE following section numbers to accomodate the new section.


356 lrmdraft
2001b: 16
16: "1497-1999" should be "1497-2001"

In the third paragraph in Clause 16,
change "1497-1999" to "1497-2001".
361 lrmdraft
2001b: Syntax 14-1
Syntax 14-1 omits specify_block

In Syntax 14-1:

ADD the following at the top of the box:

specify_block ::= (From Annex A - A.7.1)

specify { specify_item } endspecify"


DELETE "(From Annex A - A.7.1)" from "specify_item".
365 lrmdraft
2001b: 26.6.6
26.6.6 vpiLeftRange/vpiRightRange from net bit makes no sense

Change the diagram in 26.6.6 as follows:

Make the one to one transitions labeled vpiLeftRange and
vpiRightRange go from net instead of nets.

Change the diagram in 26.6.7 as follows:

Make the one to one transitions labeled vpiLeftRange and
vpiRightRange go from reg instead of regs.
366 lrmdraft
2001b: 26.6.8
26.6.8: Variables should clarify use of range iteration

Section 26.6.6, add new note 21 to the end of the notes
- vpi_iterate(vpiRange, net_array_handle) shall return the set of array
range declarations beginning with the left-most range of the array
declaration, and iterate to the right-most range of the array declaration.

Section 26.6.7, add new note 14 to the end of the notes
- vpi_iterate(vpiRange, array_handle) shall return the set of array range
declarations beginning with the left-most range of the array declaration,
and iterate to the right-most range of the array declaration.

Section 26.6.8, add new note 5, pushing existing note 5 and subsequent notes
up in number.
- vpiRange shall apply to variables when vpiArray is TRUE.
vpi_iterate(vpiRange, variable_array_handle) shall return the set of array
range declarations beginning with the left-most range of the array
declaration, and iterate to the right-most range of the array declaration.

Section 26.6.8, change existing note 5
FROM:
5) vpiLeftRange and vpiRightRange shall apply to variables when vpiArray is
TRUE, and represent the array range declaration. These relationships are
only valid when vpiArray is TRUE.

TO:
6) vpiLeftRange and vpiRightRange shall apply to variables when vpiArray is
TRUE, and represent the array range declaration of the right-most range of
an array. These relationships are a short cut for accessing the range
declarations of a one-dimensional variable array. To access the range
declarations for all dimensions of a multi-dimensional array, first iterate
on vpiRange.


367 lrmdraft
2001b: 27.32
27.32 Cancelling event does not say what happens to handle

27.32, third full paragraph, which begins:

"The handle to the event can be cancelled...",

Replace the first sentence with:

"A scheduled event can be canceled by calling
vpi_put_value() with obj set to the vpiSchedEvent
handle and flags set to vpiCancelEvent."

Where "obj" and "flags" are italicized.
Add to end of the paragraph:

"Cancelling an event shall also free the handle to
that event."

380 lrmdraft
2001b: 12.1.3
12.1.3: should allow tasks/functions in generate loops

In 12.1.3, paragraph 8, delete the phrase
", however not in a generate loop" from the sentence:

"Task and function declarations shall also be permitted
within the generate scope, however not in a generate loop."
387 lrmdraft
2001c: 4, 10.3.5, A.8.4
calling system tasks at elaboration

Revised as passed by BTF 2004-11-29:

This proposal is for allowing 'pure' system functions to be
used in constant expressions which are evaluated at
elaboration time, such as parameter values.

It is assumed that in parallel to this proposal,
there will be another that will add a few math functions
in a new section at the end of Section 17 (BTF #390).

It also assumes final approval of issue #483.

After #483, Clause 4 paragraph 3 says,

"Some statement constructs require an expression to be a constant expression.
The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only,
but they can use any of the operators defined in Table 4-1."

CHANGE

"and constant function calls (see 10.3.5) only"

TO

"constant function calls (see 10.3.5) and constant
system function calls
only".

ADD new paragraph immediately after paragraph 3:

"Constant system function calls are calls to certain
built-in
system functions where the arguments are constant expressions.
When used in constant expressions, these function calls shall
be evaluated at elaboration time. The system functions which
may be used in constant system function calls are "pure"
functions, i.e. those whose value depends only on their
input arguments and which have no side effects. Specifically,
the system functions allowed in constant expressions are the
conversion system functions listed in 17.8 and the
mathematical system functions listed in 17.11".

--

In 10.3.5, CHANGE

"All system functions within a constant function shall be
illegal."

TO

"It shall be legal to call any system function which is
allowed in a constant_expression (see Clause 4).
Calls to other system functions shall be illegal."

--

In Syntax 4-2 and A.8.4, in constant_primary,

CHANGE

| constant_function_call

TO

| constant_function_call
| constant_system_function_call


In A.8.2, ADD

constant_system_function_call ::=
system_function_identifier
"(" constant_expression { "," constant_expression } ")"


390 lrmdraft
2001b: 17.11
17.11: math functions

As revised and passed by BTF 2004-11-29:

In Section 17 introduction, ADD to list of system functions:

Math functions [17.11]

$clog2 $asin
$ln $acos
$log10 $atan
$exp $atan2
$sqrt $hypot
$pow $sinh
$floor $cosh
$ceil $tanh
$sin $asinh
$cos $acosh
$tan $atanh

In Section 17, ADD:

17.11 Math functions

There are integer and real math functions.

17.11.1 Integer math functions

integer result;
result = $clog2(n);

The system function $clog2 returns the ceiling of the log base 2 of the
argument (the log rounded up to an integer value). The argument can be
an integer or an arbitrary sized vector value. The argument is treated
as an unsigned value, and an argument value of 0 will produce a result
of 0.

This system function can be used to compute the minimum address width
necessary to address a memory of a given size, or the minimum vector
width necessary to represent a given number of states. It can be used
in a constant expression, as specified in Clause 4.

17.11.2 Real math functions

---------------------------------------------------
Function C equivalent Description
---------------------------------------------------
$ln(x) log(x) Natural logarithm
$log10(x) log10(x) Decimal logarithm
$exp(x) exp(x) Exponential
$sqrt(x) sqrt(x) Square root
$pow(x,y) pow(x,y) x**y
$floor(x) floor(x) Floor
$ceil(x) ceil(x) Ceiling
$sin(x) sin(x) Sine
$cos(x) cos(x) Cosine
$tan(x) tan(x) Tangent
$asin(x) asin(x) Arc-sine
$acos(x) acos(x) Arc-cosine
$atan(x) atan(x) Arc-tangent
$atan2(x,y) atan2(x,y) Arc-tangent of x/y
$hypot(x,y) hypot(x,y) sqrt(x*x + y*y)
$sinh(x) sinh(x) Hyperbolic sine
$cosh(x) cosh(x) Hyperbolic cosine
$tanh(x) tanh(x) Hyperbolic tangent
$asinh(x) asinh(x) Arc-hyperbolic sine
$acosh(x) acosh(x) Arc-hyperbolic cosine
$atanh(x) atanh(x) Arc-hyperbolic tangent
---------------------------------------------------

These system functions accept real arguments, and return
a real result. Their behavior matches the equivalent C
language standard math library function indicated.
398 lrmdraft
2001b
27.18: Description of return value is incorrect

1. The diagram modifications are:
In diagram 26.6.2, under the Instance array class add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.5, under the Ports class add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.6, under the Nets class add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.6 under the Net array class, add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.7, under the Regs class add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.7 under the Reg array class, add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.8 under the Variables class, add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.9 (Memory diagram) under the
regarray diagram add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

In diagram 26.6.11 under the Named Event Array class, add:
-> access by index
vpi_handle_by_index()
vpi_handle_by_multi_index()

2. modify vpi_handle_by_index (27.17) as:
CHANGE description:
The VPI routine vpi_handle_by_index() shall return a
handle to an object based on the index number of the
object within a parent object. This function can be
used to access all objects that can access an
expression using vpiIndex. argument obj shall represent
the parent of the indexed object. For example, to
access a netbit, obj would be the associated net, while
for a memory word, obj would be the associated memory.

TO:
The VPI routine vpi_handle_by_index() shall return a
handle to an object based on the index number of the
object within the reference object, obj. The reference
object shall be an object that has the access by index
property. For example, to access a net bit, obj would
be the associated net, to access an element of a reg
array, obj would be the array. If the selection
represented by the index number does not lead to the
construction of a legal Verilog index select
expression, the routine shall return a null handle.

3. modify vpi_handle_by_multi_index (27.18) as:
CHANGE synopsis section:
Obtain a handle to a sub object using an array of
indexes and a parent object.
TO:
Obtain a handle to a sub object using an array of
indices and a reference object.

CHANGE in the description of the argument num_index:
number of indexes in the index array
TO:
number of indices in the index array

CHANGE in the description of argument index_array
array of indexes.
TO:
array of indices.

CHANGE the Returns description:
Handle to an object of type vpiRegBit, vpiNetBit,
vpiRegWord, or vpiNetWord
TO:
Handle to an object

CHANGE description:
The VPI routine vpi_handle_by_multi_index() shall
return a handle to an object based on the list of
indexes and parent object passed in. The argument
num_index will contain the number of indexes in the
provided array index_array. The order of the indexes
provided, shall be for the left most select first,
progressing to the right most select last. This
function can be used to access all objects whose
property vpiMultiArray is TRUE. This routine shall
only provide access to a bit or word of the parent
object.

TO:
The VPI routine vpi_handle_by_multi_index() shall
provide access to an index selected sub object of the
reference handle. The reference object shall be an
object that has the access by index property. This
routine shall return a handle to a valid Verilog
object based on the list of indices provided by the
argument index_array, and reference handle denoted by
obj. The argument num_index shall contain the number
of indices in the provided array index_array. The
order of the indices provided, shall follow the array
dimension declaration from the left most range to the
right most range of the reference handle; the array
indices may be optionally followed by a bit select
index. If the indices provided do not lead to the
construction of a legal Verilog index select
expression, the routine shall return a null handle.
402 lrmdraft
2001b: 9.5
9.5: evaluation of case expression

At the beginning of the paragraph after
the first "simple example" of Section 9.5
prepend the following sentence --

ADD

The case expression given in parentheses
shall be evaluated exactly once and before
any of the case item expressions.

403 lrmdraft
2001b: 4.1.13
4.1.13: "known" and "ambiguous" are ambiguous

In 4.1.13, replace:

The evaluation of a conditional operator shall begin with
the evaluation of expression1. If expression1 evaluates
to false (0), then expression3 shall be evaluated and used
as the result of the conditional expression. If
expression1 evaluates to true (known value other than 0),
then expression2 is evaluated and used as the
result. If expression1 evaluates to ambiguous value (x or z),
then both expression2 and expression3 shall be
evaluated and their results shall be combined, bit by bit.

With:

The evaluation of a conditional operator shall begin with
a logical equality comparison (see 4.1.8) of expression1
with zero, termed the condition. If the condition evaluates
to false (0), then expression3 shall be evaluated and used
as the result of the conditional expression. If
the condition evaluates to true (1),
then expression2 is evaluated and used as the
result. If the condition evaluates to an ambiguous value (x or z),
then both expression2 and expression3 shall be
evaluated and their results shall be combined, bit by bit.
412 lrmdraft
2001b: 2.5.1
2.5.1: rearrange text on x/z

In 2.5.1,

CHANGE:

"The first token, a size constant, shall specify the size of the constant in terms of its exact number of bits. It
shall be specified as a non-zero unsigned decimal number. For example, the size specification for two hexadecimal
digits is 8, because one hexadecimal digit requires 4 bits. Unsized unsigned constants where the
high order bit is unknown (X or x) or three-state (Z or z) are extended to the size of the expression containing
the constant.

NOTE--In IEEE Std 1364-1995, unsized constants where the high order bit is unknown or three-state, the x or z was
only extended to 32 bits.

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 (' ). Legal base specifications are d, D, h, H, o, O, b, or B, for the bases decimal, hexadecimal,
octal, and binary respectively.

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


TO:

"The first token, a size constant, shall specify the size of the constant in terms of its exact number of bits. It
shall be specified as a non-zero unsigned decimal number. For example, the size specification for two hexadecimal
digits is 8, because one hexadecimal digit requires 4 bits.

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 ( ). Legal base specifications are d, D, h, H, o, O, b, or B, for the bases decimal, hexadecimal,
octal, and binary respectively.

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


AND CHANGE

"An x represents the unknown value in hexadecimal, octal, and binary constants. A z represents the highimpedance
value. See 3.1 for a discussion of the Verilog HDL value set. An x shall set 4 bits to unknown in
the hexadecimal base, 3 bits in the octal base, and 1 bit in the binary base. Similarly, a z shall set 4 bits, 3
bits, and 1 bit, respectively, to the high-impedance value.

If the size of the unsigned number is smaller than the size specified for the constant, the unsigned number
shall be padded to the left with zeros. If the leftmost bit in the unsigned number is an x or a z, then an x or a
z shall be used to pad to the left respectively."

TO:

"An x represents the unknown value in hexadecimal, octal,
and binary constants. A z represents the high impedance
value. See 3.1 for a discussion of the Verilog HDL value
set. An x shall set 4 bits to unknown in the hexadecimal
base, 3 bits in the octal base, and 1 bit in the binary
base. Similarly, a z shall set 4 bits, 3 bits, and 1 bit,
respectively, to the high-impedance value.

If the size of the unsigned number is smaller than the size
specified for the constant, the unsigned number shall be
padded to the left with zeros. If the leftmost bit in the
unsigned number is an x or a z, then an x or a z shall be
used to pad to the left respectively.

Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) are extended to the
size of the expression containing the constant.

NOTE--In IEEE Std 1364-1995, unsized constants where the
high order bit is unknown or three-state, the x or z was
only extended to 32 bits.

The use of x and z in defining the value of a number is case
insensitive."
413 lrmdraft
2001b: 4
4. scalar expressions

Delete paragraph 4 in Clause 4
("A scalar expression ...").
415 lrmdraft
2001b: 4.3, A.8.4
BNF: redundant function calls in "module_path_primary" and "primary"

In the BNF productions of "module_path_primary" and
"primary", delete the line

"| constant_function_call".


The BNF of "primary" appears in:

Syntax 4-2 (Section 4.3)
A.8.4

The BNF of "module_path_primary" appears in:

A.8.4


"system_function_call" should not be deleted,
it is not included in "function_call".

425 lrmdraft
2001c: 3.12, 12.3, 13.1.1, 13.3.1.6
"macromodule" use


It is inconsistent to mention macromodules sometimes in
addition to modules, but not always. It gives the impression
that where they are not mentioned, there is a difference.

It also encourages their use and simply makes the text
more verbose and lengthier.

Note also that they are nowhere mentioned in the PLI.


I propose to delete mention of macromodule everywhere except
in 12.1 para. 3:

"The keyword macromodule can be used interchangeably with
the keyword module to define a module. An implementation
may choose to treat module definitions beginning with the
macromodule keyword differently."

and in Syntax 12-1 and A.1.3:

module_keyword ::= module | macromodule

and in the list of keywords in Annex B.


Specifically, I propose to delete the mention of macromodules
from the following places:

3.12 Namespaces, para. 1 (in 3 places):

"In Verilog HDL, there are seven name spaces; two are global and five are local. The global name spaces are definitions and text macros. The definitions name space unifies all the module (see 12.1), macromodule (see 12.1), and primitive (see 8.1) definitions. Once a name is used to define a module, macromodule, or primitive, the name shall not be used again to declare another module, macromodule, or primitive."

para. 5:

"The module name space is introduced by the module, macromodule, and primitive constructs. It unifies the definition of functions, tasks, named blocks, instance names, parameters, named events, net type of declaration, and variable type of declaration. The net type of declaration includes wire, wor, wand, tri, trior, triand, tri0, tri1, trireg, supply0, and supply1 (see 3.7)."

para. 6:

"The port name space is introduced by the module, macromodule, primitive, function, and task constructs. It provides a means of structurally defining connections between two objects that are in two different name spaces. The connection can be unidirectional (either input or output) or bidirectional (inout). The port name space overlaps the module and the block name spaces. Essentially, the port name space specifies the type of connection between names in different name spaces. The port type of declarations include input, output, and inout (see 12.3). A port name introduced in the port name space can be reintroduced in the module name space by declaring a variable or a wire with the same name as the port name."


12.3 Ports:

"Ports provide a means of interconnecting a hardware description consisting of modules, primitives, and macromodules. For example, module A can instantiate module B, using port connections appropriate to module A. These port names can differ from the names of the internal nets and variables specified in the definition of module B."


13.1.1 Library notation, para. 1 (in 2 places) and para. 2:

"In order to map a Verilog instance to a source description, the concept of a symbolic library, which is simply a logical collection of design elements (such as modules, macromodules, primitives, or configs) can be used. These design elements can be referred to as cells. The cell name shall be the same as the name of the module/macromodule/primitive/config being processed. Syntax 13-1 specifies a cell from a given library.

This notation gives a symbolic method of referring to source descriptions; the method of mapping source descriptions into libraries is shown in greater detail in 13.2.1. The optional :config extension shall be used explicitly to refer to a config in the case where a config has the same name as a module/macromodule/primitive."


13.3.1.6 The use clause, para. 4:

"If the lib.cell being referred to by the use clause is a config which has the same name as a module/macromodule/primitive in the same library, then the optional :config suffix can be added to the lib.cell to specify the config explicitly."

426 lrmdraft
2001b
26.6.3 transition from module to scope needs vpiInternalScope label

Add the label vpiInternalScope to the transition from module to scope.

The reference to the class "taskfunc" (1 word) needs to be
"task func" (two words).
439 lrmdraft
2001b: Syntax 6-2
Syntax 6-2 should be titled "Syntax for variable declaration

In 6.2.2, in the title of Syntax 6-2,

CHANGE

"Syntax for reg declaration assignment"

TO

"Syntax for variable declaration assignment"



441 lrmdraft
2001b: 3.2.2, 4.1.6
3.2.2, 4.1.6: Nets also have signedness

In the CAUTION box of 3.2.2

CHANGE

"Variables can be assigned negative values,
but only signed regs, integer, real, and
realtime variables shall retain the significance
of the sign. The unsigned reg and time variables
shall treat the value assigned to them as an
unsigned value. Refer to 4.1.6 for a description
of how signed and unsigned variables are treated
by certain Verilog operators."

TO

"Nets and variables can be assigned negative values,
but only integer, real, realtime and signed reg
variables and signed nets shall retain the
significance of the sign. Time and unsigned
reg variables and unsigned nets shall treat the
value assigned to them as an unsigned value.
Refer to 4.1.6 for a description of how signed
and unsigned nets and variables are treated by
certain Verilog operators."

and in 4.1.6

CHANGE

"A reg data type shall be treated as an unsigned
value unless explicitly declared to be signed.
An integer variable shall be treated as signed.
Signed values shall use a 2's complement
representation."

TO

"A value assigned to a reg variable or net
shall be treated as an unsigned value unless
the reg variable or net has been explicitly
declared to be signed. A value assigned to an
integer, real or realtime variable shall be treated
as signed. A value assigned to a time variable
shall be treated as unsigned. Signed values,
except for those assigned to real and realtime
variables, shall use a 2's complement representation.
Values assigned to real and realtime variables
shall use a floating-point representation."

445 lrmdraft
2001c: Syntax 17-1, 2, 4, 5, 13, 17, 18
Section 17: syntax misbolding

This fixes the bolding in the Section 17 syntax boxes,
and also places some optional syntax in square brackets.

Also removes "integer" in Syntax 17-4 and
improves syntax form in Syntax 17-13.

--

In Syntax 17-1, CHANGE the display_tasks production to

display_tasks ::=
display_task_name [ ( list_of_arguments ) ] ;

Bold: parentheses and semicolon

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

In Syntax 17-2, CHANGE the strobe_tasks production to

strobe_tasks ::=
strobe_task_name [ ( list_of_arguments ) ] ;

Bold: parentheses and semicolon

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

In Syntax 17-4, CHANGE

file_open_function ::=
integer multi_channel_descriptor = $fopen ( " file_name " );
| integer fd = $fopen ( " file_name ", type );
file_close_task ::=
$fclose ( multi_channel_descriptor );
| $fclose (fd);

TO

file_open_function ::=
multi_channel_descriptor = $fopen ( " file_name " ) ;
| fd = $fopen ( " file_name " , type ) ;
file_close_task ::=
$fclose ( multi_channel_descriptor ) ;
| $fclose ( fd ) ;

Bold: $fopen, $fclose, parentheses, quotation marks,
semicolons, comma, equals sign

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

In Syntax 17-5, CHANGE

file_output_tasks ::=
file_output_task_name ( multi_channel_descriptor , list_of_arguments ) ;
| file_output_task_name ( fd , list_of_arguments ) ;

TO

file_output_tasks ::=
file_output_task_name ( multi_channel_descriptor [ , list_of_arguments ] ) ;
| file_output_task_name ( fd [ , list_of_arguments ] ) ;

Bold: parentheses, commas, semicolons

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

In Syntax 17-13, CHANGE

pla_system_task ::=
$array_type$logic$format ( memory_type , input_terms , output_terms ) ;

TO

pla_system_task ::=
$array_type$logic$format ( memory_identifier , input_terms , output_terms ) ;

memory_identifier ::=
identifier

Bold: dollar signs, parentheses, semicolon, commas

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

In Syntax 17-17, CHANGE

random_function ::=
$random [ ( seed ) ]

TO

random_function ::=
$random [ ( seed ) ]

Bold: $random, parentheses

(The change is in the bolding)

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

In Syntax 17-18:

dist_functions ::=
$dist_uniform ( seed , start , end )
| $dist_normal ( seed , mean , standard_deviation )
| $dist_exponential ( seed , mean )
| $dist_poisson ( seed , mean )
| $dist_chi_square ( seed , degree_of_freedom )
| $dist_t ( seed , degree_of_freedom )
| $dist_erlang ( seed , k_stage , mean )

REMOVE the bolding from the function arguments.

Only the function names and the parentheses should be in bold.

454 lrmdraft
2001b: 2.5.1
2.5.1: 2'sb0000000_10 == 2'sb10 ?

In 2.5.1, at the end of the paragraph

If the size of the unsigned number is smaller than the size specified for the constant, the unsigned number shall be padded to the left with zeros. If the leftmost bit in the unsigned number is an x or a z, then an x or a z shall be used to pad to the left respectively.

ADD the following sentence

If the size of the unsigned number is larger than the size specifed for the constant, the unsigned number shall be truncated from the left.

462 lrmdraft
2001b: Syntax 13-2 & 13-3, A.1.1
A.1.1: " < file_path_spec > " should be "file_path_spec"

In Syntax 13-2 and 13-3 and in A.1.1:

CHANGE
              " include_statement = include < file_path_spec > ; "

              TO 

              " include_statement = include file_path_spec ; "

The angle brackets should not be there.
The keyword "include" and the semicolon should be bold.
464 lrmdraft
2001b: 14.2.4.2 (Example 1)
14.2.4.2: syntax error in Example 1

In Example 1 of 14.2.4.2,

add semicolon to end of first specparam declaration,
change end of line "input a, b:" from colon to semicolon.

(I will already do these in 2001c.)
470 lrmdraft
2001b
19.2: Compiler directives and source file boundaries

In 19.2,

REMOVE

"It affects all modules that follow the directive,
even across source file boundaries."

as redundant.


Also, in 19, first paragraph, sentence 4,

CHANGE

"The scope of compiler directives extends from the point
where it is processed ..."

TO

"The scope of a compiler directive extends from the point
where it is processed ..."

483 lrmdraft
2001b: 4.2
4.2: Bit/part-selects of parameters

2004-11-15: In this final version of the proposal, I:
- deleted part 2, which related to the scalared and vectored keywords,
due to controversy;
- in part 7, added "strings" after "constant numbers"
- in part 8, added "(not real)" in array element selects
- in part 15 (BNF), changed curly brackets to square brackets


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. Deleted from proposal


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


5A. In 3.11.2 ("Local parameters - localparam"), ADD a new
paragraph after the first paragraph as follows:

"Bit-selects and part-selects of local parameters which are
not of type real shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real) or string
-- Parameter (including local and specify parameters)
-- Parameter (not real) bit-select or part-select (including local and specify parameters)
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element (not real) bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier [ [ constant_range_expression ] ]
| specparam_identifier [ [ constant_range_expression ] ]

484 lrmdraft
2001b: 10.3.4e
10.3.4.e: assignment of function result value

REMOVE (10.3.4):
Bullet e: "A function definition shall include an assignment of the function result value to the internal variable that has the same name as the function name."

"six" from first paragraph "Functions are more limited than tasks.The following six rules govern their usage:"
493 lrmdraft
2001b
Can defparam assignment use parenless mintypmax expression?

In A.2.4, REPLACE

defparam_assignment ::=
hierarchical_parameter_identifier
'=' constant_expression

WITH

defparam_assignment ::=
hierarchical_parameter_identifier
'=' constant_mintypmax_expression
504 lrmdraft
2001b: A.2.2.1
A.2.2.1: simplify BNF of real_type, variable_type

In 3.2.2 (Syntax 3-2), 3.9 (Syntax 3-3), 6.2.2 (Syntax 6-2),
and A.2.2.1:

CHANGE

real_type ::=
real_identifier [ = constant_expression ]
| real_identifier dimension { dimension }

variable_type ::=
variable_identifier [ = constant_expression ]
| variable_identifier dimension { dimension }


TO

real_type ::=
real_identifier { dimension }
| real_identifier = constant_expression


variable_type ::=
variable_identifier { dimension }
| variable_identifier = constant_expression
505 lrmdraft
2001b
10.2.1 -- declaration of portless tasks

In Syntax 10-1 and in A.2.7, REPLACE

task_declaration ::=
"task" [ "automatic" ] task_identifier ";"
{ task_item_declaration }
statement_or_null
"endtask"
| "task" [ "automatic" ]
task_identifier "(" task_port_list ") ;"
{ block_item_declaration }
statement_or_null
"endtask"

WITH

task_declaration ::=
"task" [ "automatic" ] task_identifier ";"
{ task_item_declaration }
statement_or_null
"endtask"
| "task" [ "automatic" ]
task_identifier "(" [ task_port_list ] ") ;"
{ block_item_declaration }
statement_or_null
"endtask"



511 lrmdraft
2001b
9.8.4 typo: "procedural blocks" should be "parallel blocks"

In sentence 1 of 9.8.4, CHANGE

"Both sequential and procedural blocks"

TO

"Both sequential and parallel blocks".
512 lrmdraft

27.33 index field for s_cb_data struct won't work for MDAs

Change the third paragraph on page 700 (printed version) from:

For a cbValueChange callback, if the obj is a memory or
variable array, the value in the s_cb_data structure shall
be the value of the memory word or variable select that
changed value. The index field shall contain the index of
the memory word or variable select that changed value. If
a cbValueChange callback is registered and the format is
set to vpiStrengthVal then the callback shall occur
whenever the object changes strength, including changes
that do not result in a value change.

To:

For a cbValueChange callback, if the obj has the vpiArray
property set to TRUE, the value in the s_cb_data structure
shall be the value of array member that changed value.
The index field shall contain the index of the right-most
range of the array declaration. Use
vpi_iterate(vpiIndex,obj) to find all the indices.

If a cbValueChange callback is registered and the format
is set to vpiStrengthVal then the callback shall occur
whenever the object changes strength, including changes
that do not result in a value change.

513 lrmdraft

26.6.2 vpiParamAssign to an expr is wrong

Change the diagram in section 26.6.2 as follows:

- Replace the expr dotted enclosure in the instance array
diagram to which there is a one to many iteration labeled
vpiParamAssign with a reference solid enclosure of type
param assign.

- Remove the vpiParamAssign label on the one to many
iteration.
515 lrmdraft
2001b: 1.3b
1.3b: keyword size is not larger

In 1.3(b), DELETE the sentence

"These words appear in a larger font for distinction."
516 lrmdraft

27.13 and 27.31 doesn't talk about what happens with a save/restart/reset

After the last paragraph of both sections, add the following
paragraph:

After a restart or a reset, subsequent calls to
vpi_get_userdata() shall return NULL. It is the
application's responsibility to save the data during a
save using vpi_put_data() and to then retrieve it using
vpi_get_data(). The user data field can be setup again
during or after callbacks of type cbEndOfRestart or
cbEndOfReset.
518 lrmdraft

26.6.40 no discussion of how vpi_get_time() and vpiTimeQueue works

I propose the following change to the description of 27.12 vpi_get_time()

FROM:

The VPI routine vpi_get_time() shall retrieve the current
simulation time, using the time scale of the object. If obj
is NULL, the simulation time is retrieved using the simulation
time unit. The time_p->type ...

TO:

The VPI routine vpi_get_time() shall retrieve the current
simulation time, using the time scale of the object. If obj
is NULL, the current simulation time is retrieved using the
simulation time unit. If obj is a time queue object, the
scheduled time of the future event is retrieved using the
simulation time unit. The time_p->type ...
522 lrmdraft
2001b
A.2.2.3: delay2 and delay3 should be constant expressions


In 7.14.1, delete the statements that the delays are
constant expressions.

Specifically, DELETE the word "constant" twice in
paragraph 1 in the following sentences:

"The minimum, typical, and
maximum values for each delay shall be specified as constant
expressions separated by colons. There shall be no required
relation (e.g., min <= typ <= max) between the expressions
for minimum, typical, and maximum delays.
These can be any three constant expressions."

525 lrmdraft

Memory for callback routine's structures should be allocated by simulator

Section 27.33.

After the paragraph that begins:

The cb_rtn field of the s_cb_data structure shall be set to
the application routine, which shall be ...

Add the following new paragraph:

The callback routine shall be passed a pointer to an
s_cb_data structure. This structure, and all structures
to which it points belong to the simulator. If the
application needs any of this data, it must copy it prior
to returning from the callback routine.

526 lrmdraft
2001b: 7.1.2, 7.8
7.8: "conflicting strength is ignored" ??


In 7.8,

CHANGE

"The signals that these sources place on nets shall have pull strength in the
absence of a strength specification. If conflicting strength specification is
declared, it shall be ignored."

TO

"The signals that these sources place on nets shall have pull strength in the
absence of a strength specification. If there is
a strength1 specification on a pullup source or
a strength0 specification on a pulldown source,
the signals shall have the strength specified.

A strength0 specification on a pullup source and
a strength1 specification on a pulldown source
shall be ignored."

CHANGE the last sentence in 7.8 from

"In this example, the p1 instance drives neta and the p2 instance drives netb."

TO

"In this example, the p1 instance drives neta and the p2 instance drives netb
with strong strength."


In 7.1.2, at the end of the paragraph discussing pullups and pulldowns,
add "See 7.8 for more details."


527 lrmdraft
2001b
Replication operator on concats involving function calls

As pointed out in

http://boydtechinc.com/etf/archive/etf_2004/2251.html

this is a duplicate of 288. Propose to close as such.


535 lrmdraft

errors in $width, 15.3.4 and 15.5


1. In 15.3.4, Syntax 15-12, and in A.7.5.1,
CHANGE the BNF of $width from

$width_timing_check ::=
$width ( controlled_reference_event , timing_check_limit
, threshold [ , [ notify_reg ] ] ) ;

TO

$width_timing_check ::=
$width ( controlled_reference_event , timing_check_limit
[ , threshold [ , notify_reg ] ] ) ;

The following are bold: "$width", the parentheses, commas,
and semicolon.


2. In 15.3.4, DELETE the paragraph

"If the comma before the threshold is present,
the comma before the notifier shall also be present,
even though both arguments are optional."


3. In 15.5, Example 1, CHANGE

$width( posedge clk, 16, notify_reg ) ;

TO

$width( posedge clk, 16, 0, notify_reg ) ;

536 lrmdraft
2001b
17.1.1.4: does not deal with mixed x and z bits


In 17.1.1.4:

1. Under "In decimal (%d) format",
CHANGE

"If some, but not all, bits are at the high impedance value,
the uppercase Z character is displayed."

TO

"If some, but not all, bits are at the high impedance value,
the uppercase Z character is displayed, unless there are
also some bits at the unknown value, in which case the
uppercase X character is displayed."


2. Under "In hexadecimal (%h) and octal (%o) formats",

CHANGE

"If some, but not all, bits in a group are at a high
impedance state, then an uppercase Z is displayed for
that digit."

TO

"If some, but not all, bits in a group are at a high
impedance state, then an uppercase Z is displayed for
that digit, unless there are also some bits at the unknown
value, in which case an uppercase X is displayed for that digit."

541 lrmdraft
2001c: 18.2.38
18.2.38, Syntax 18-16: var_type should include "realtime"


In 18.2.3.8, Syntax 18-16, in "var_type",

add "| realtime" after "real".

544 lrmdraft
2001b: 15.5
15.5, Table 61: does notifier toggle from X to 0 or to 1?

15.5, Table 61:

Change Table 61 to say that notifier toggles from X to
either 1 or 0.

Change title of Table 61 to
"Notifier value responses to timing violations".
546 lrmdraft
2001c: Syntaxes 15-1 to 15-14, 15.5 Example 1, A.7.5.1-2
15, A.7.5: change "notify_reg" to "notifier"


In Clause 15 (including 15.5, Exmaple 1)
and in A.7.5.1 and A.7.5.2,
change "notify_reg" to "notifier" everywhere.

Delete "notify_reg ::= variable_identifier"
from Syntax 15-3 to 15-14.
547 lrmdraft
2001c: 4.1.14
define size zero replication constant

In 4.1.14 (Concatenations):

CHANGE

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

TO

"An operator that can be applied only to concatenations is replication, which is
expressed by a concatenation preceded by a non-negative, non-x and non-z
constant expression, called a replication constant, enclosed together
within brace characters, and which indicates a joining together of that many
copies of the concatenation."

DELETE the example

{0{1'b0}} // illegal

At the end of 4.1.14, ADD the following:

A replication operation may have a replication constant with a value of
zero. This is useful in parameterized code. A replication with a zero
replication constant is considered to have a size of zero and is ignored.
Such a replication shall appear only within a concatenation in which at
least one of the operands of the concatenation has a positive size.


Examples:

parameter P = 32;

// The following is legal for all P from 1 to 32

assign b[31:0] = { {32-P{1'b1}}, a[P-1:0] } ;

// The following is illegal for P=32,
// because the zero replication appears alone within a concatenation

assign c[31:0] = { {{32-P{1'b1}}}, a[P-1:0] } ;

// The following is illegal for P=32

initial
$displayb({32-P{1'b1}}, a[P-1:0]);
551 lrmdraft
2001c: 3.1
3.1: reals don't have x/z


In 3.1, CHANGE

"Almost all of the data types in the Verilog HDL store all
four basic values. The exception is the *event* type
(see 9.7.3), which has no storage."

TO

"Almost all of the data types in the Verilog HDL store all
four basic values. Exceptions are the *event* type
(see 9.7.3), which has no storage, and the *real* data type
(see 3.9)."


552 lrmdraft
2001b
3.2.1: "shall" should be "can"


In 3.2.1, change

"The net data types shall represent physical connections
between structural entities, such as gates."

TO

"The net data types can represent physical connections
between structural entities, such as gates."
553 lrmdraft
2001c: 1.2
1.2: "can" vs. "may"

In 1.2,

"The term shall is used throughout this standard to
indicate mandatory requirements, whereas the term can
is used to indicate optional features."

"The term can denotes optional features that the
model developer can exercise at discretion."

CHANGE "can" to "may".

554 lrmdraft
2001b: 10.3.1, A.2.6
A.2.6: function_declaration BNF bug for return type declarations

In Syntax 1-3 and in A.2.6,
in "function_declaration", CHANGE in 2 places

[ signed ] [ range_or_type ]

TO

[ function_range_or_type ]


CHANGE

range_or_type ::=
range
| integer
| real
| realtime
| time

TO

function_range_or_type ::=
[ signed ] [ range ]
| integer
| real
| realtime
| time

In 10.3.1, CHANGE the following paragraph

"A function definition shall begin with the keyword function,
followed by the optional keyword automatic, followed by the
optional signed designator, followed by the range or type of
the return value from the function, followed by the name of
the function, and then either a semicolon, or a function port
list enclosed in parenthesis, and then a semicolon, and then
shall end with the keyword endfunction. The use of a
range_or_type shall be optional. A function specified without
a range or type defaults to a one bit reg for the return value.
If used, range_or_type shall specify the return value of the
function is a real, an integer, a time, a realtime or a value
with a range of [n:m] bits. A function shall have at least
one input declared."

TO

"A function definition shall begin with the keyword function,
followed by the optional keyword automatic, followed by an
optional function_range_or_type of the return value from the
function, followed by the name of the function, and then
either a semicolon, or a function port list enclosed in
parenthesis, and then a semicolon, and then
shall end with the keyword endfunction.

The use of a function_range_or_type shall be optional.
A function specified without a function_range_or_type
shall default to a scalar for the return value.
If used, function_range_or_type shall specify that the
return value of the function is a real, an integer, a time,
a realtime, or a vector (optionally signed) with a range of
[n:m] bits.

A function shall have at least one input declared."


CLOSE issue #607 as a duplicate of #554.
557 lrmdraft
2001b: 9.3.2
9.3.2, para. 2: net "continuous assignment"

This version of the proposal incorporates Gord's suggestion.

In 9.3.2,

CHANGE paragraphs 2-4 FROM

A force statement to a variable shall override a procedural assignment or procedural continuous assignment that takes place on the variable until a release procedural statement is executed on the variable. After the release procedural statement is executed, the variable shall not immediately change value (as would a net that is assigned with a procedural continuous assignment). The value specified in the force statement shall be maintained in the variable until the next procedural assignment takes place, except in the case where a procedural continuous assignment is active on the variable.

A force procedural statement on a net overrides all drivers of the net-gate outputs, module outputs, and continuous assignments-until a release procedural statement is executed on the net.

Releasing a variable that currently has an active procedural continuous assignment shall re-establish that assignment.

TO

A *force* statement to a variable shall override a procedural assignment
or an *assign* procedural continuous assignment to the variable until a *release*
procedural statement is executed on the variable.
When released, then if the variable does not currently
have an active *assign* procedural continuous assignment, the variable shall
not immediately change value. The variable shall maintain its current value
until the next procedural assignment or procedural continuous assignment to the variable.
Releasing a variable that currently has an active *assign* procedural
continuous assignment shall immediately re-establish that assignment.

A *force* procedural statement on a net shall override all drivers of the net --
gate outputs, module outputs, and continuous assignments -- until a *release*
procedural statement is executed on the net. When released,
the net shall immediately be assigned the value determined
by the drivers of the net.
563 lrmdraft
2001c: 9.3.2
9.3.2, Example: minor corrections


In the example in 9.3.2,

DELETE "$stop;" from the code.

CHANGE the word "Results:" to Times font.

CHANGE the following text:

"In this example, an and gate instance and1 is "patched" as an or gate by
a force procedural statement that forces its output to the value of its
logical or inputs, and an assign procedural statement of logical and
values is "patched" as an assign procedural statement of logical or values."

TO

"In this example, an *and* gate instance and1 is "patched" to act like an
*or* gate by a *force* procedural statement that forces its output to the
value of its ORed inputs, and an *assign* procedural statement of ANDed
values is "patched" to act like an *assign* statement of ORed values."

564 lrmdraft
2001c: 15.3.6, 15.5
15.3.6, 15.5: timing checks are not system tasks


In 15.3.6, last para.,
CHANGE "$nochange system task"
TO "the $nochange timing check".

In 15.5, para. 2,
CHANGE "the system task"
TO "the timing check".

In 15.5, para. 3,
CHANGE "the system task call"
TO "the timing check call".


575 lrmdraft
2001b
17.6: misplaced phrase

17.6, "Stochastic analysis tasks", In the sentence,

"This clause describes a set of system tasks and functions
that manage queues and generate random numbers with specific
distributions."

DELETE the words "and generate random numbers with specific
distributions."

Also, since $q_full is a function, not a task, there should
be no semicolon at the end of the line

"$q_full (q_id, status) ;"


PROPOSAL:

Delete the semicolon at the end of the $q_full line.
586 lrmdraft

signedness of case expression size extensions (9.5)

In 9.5, before the NOTE, AFTER

The length of all the case item expressions, as well as the
case expression in the parentheses, shall be made equal to
the length of the longest case expression and case item
expression.

ADD

If any of these expressions is unsigned, then all of them
are treated as unsigned. If all of these expressions are
signed, then they are treated as signed.

602 lrmdraft

A.2.4: Extraneous semicolons in pulse_control_specparam

In Syntax 3-5 (in 3.11.3), Syntax 14-7 (in 14.6.1),
and in A.2.4,

DELETE the semicolons at the ends of the lines from the
following BNF:

pulse_control_specparam ::=
PATHPULSE$ = ( reject_limit_value [ , error_limit_value ] ) ;
| PATHPULSE$specify_input_terminal_descriptor$specify_output_terminal_descriptor
= ( reject_limit_value [ , error_limit_value ] ) ;

603 lrmdraft
2001b
Revised generate proposal from 113

1. In 10.3.5, CHANGE

"-- They shall not be declared inside a generate scope."

TO

"-- They shall not be declared inside a generate block
(see 12.4)."


2. In 12.4.1, in the text after Example 4, CHANGE

"These generate scope names can be used in hierarchical
path names"

TO


"These names can be used in hierarchical path names"


3. In 12.4.3, Example 10, CHANGE

"The following generate scope", wherever it occurs

TO

"The following generate block"

Also, CHANGE

// Note that the previous generate construct would have been
// named genblk3 if it had not been explicitly named g1

TO

// Note that the previous generate block would have been
// named genblk3 if it had not been explicitly named g1


Also, CHANGE

// The following generate scope is implicitly named genblk1
// as the first nested scope of genblk4

TO

// The following generate block is implicitly named genblk1
// as the first nested generate block in genblk4
604 lrmdraft

12.8: defparam ambiguity with generates

12.8 Elaboration

Elaboration is the process that occurs between parsing and simulation. It binds modules to module instances, builds the model hierarchy, computes parameter values, resolves hierarchical names, establishes net connectivity and prepares all of this for simulation. With the addition of generate statements, the order in which these tasks occur becomes significant.


12.8.1 Order of elaboration

Because of generate constructs, the model hierarchy can depend on parameter values. Because defparam statements can alter parameter values from almost anywhere in the heirarchy, the result of elaboration can be ambiguous when generate constructs are involved. The final model heirarchy can depend on the order in which defparams and generate constructs are evaluated.

The following algorithm defines an order that produces the correct hierarchy.

1. A list of starting points is initialized with the list of top-level modules.

2. The hierarchy below each starting point is expanded as much as possible without elaborating generate constructs. All parameters encountered during this expansion are given their final values by applying initial values, parameter overrides and defparam statements. This means that any defparam statement whose target can be resolved within the hierarchy elaborated so far must have its target resolved and its value applied. Defparam statements whose target cannot be resolved are deferred until the next iteration of this step.

3. Each generate construct encountered in step 2 is revisited, and the generate scheme is evaluated. The resulting generate block instantiations make up the new list of starting points. If the new list of starting points is not empty, go to step 2.

Note that no defparam inside the hierarchy below a generate construct is allowed to refer to a parameter outside the generate construct. Therefore it is possible for parameters to get their final values in step 2.


12.8.2 Early resolution of hierarchical names

In order to comply with this algorithm, hierarchical names in some defparam statements will need to be resolved prior to the full elaboration of the hierarchy. It is possible that when elaboration is complete, rules for name resolution would dictate that a hierarchical name in a defparam statement would have resolved differently had early resolution not been required. This could result in a situation where an identical hierarchical name in some other statement in the same scope would resolve differently from the one in the defparam statement. Below is an example of a design that has this problem:

module m;
  mid1 n();
endmodule

module mid1;
  parameter p = 2;

  defparam m.n.p = 1;
  initial $display(m.n.p);

  generate
    if (p == 1) begin : m
      mid2 n();
    end
  endgenerate
endmodule
        
module mid2();
  parameter p = 3;
endmodule


In this example, the defparam must be evaluated before the conditional generate is elaborated. At this point in elaboration, the name resolves to parameter p in module mid1, and this parameter is used in the generate scheme. The result of the defparam is to set that parameter to 1, so the generate condition is true. After the hierarchy below the generate construct is elaborated, the rules for hierarchical name resolution would dictate that the name should have resolved to parameter p in module mid2. In fact, the identical name in the $display statement will resove to that other parameter.

It shall be an error if a hierarchical name in a defparam is resolved before the hierarchy is completely elaborated and that name would resolve differently once the model is completely elaborated.

This situation will occur very rarely. In order to cause the error, there has to be a named generate block that has the same name as one of the scopes in its full hierarchical name. Furthermore, there have to be two instances with the same name, one in the generate block and one in the other scope with the same name as the generate block. Then, inside these instances there have to be parameters with the same name. If this problem occurs, it can be easily fixed by changing the name of the generate block.

[End 12.8]


- In 10.3.5 (Constant functions), after sentence 1,
"Constant function calls are used to support the building of complex calculations of values at elaboration time."
ADD
"(see 12.8)".


- In new 12.4, at end of para. 3, after sentence,
"Therefore, all expressions in generate schemes must be constant expressions, deterministic at elaboration time."
ADD new sentence,
"For more details on elaboration, see 12.8."


- In 12.6 (Upwards name referencing), in the paragraph,
"There is an exception to these rules for hierarchical names on the left hand side of defparam statements. See 12.2.1 for details."
CHANGE the reference from 12.2.1 to 12.8.

609 lrmdraft

A.8.3-4:string should be a primary not an expression

Remove "string" from productions for

constant_expression (Syntax 4-2, A.8.3)
expression (Syntax 4-2, A.8.3)
genvar_expression (new Syntax 12-5, new A.4.2)

Add "string" to productions for

constant_primary (Syntax 4-2, A.8.4)
primary (Syntax 4-2, A.8.4)

611 lrmdraft
2001c: 14.6.4.2
14.6.4.2: Errors in last example

In 14.6.4.2, CHANGE the second Example 2 FROM

"Example 2-Both these specify blocks produce the same result. Outputs out and out_b are both declared showcancelled and on_detect.

specify
showcancelled out;
pulsestyle_ondetect out;
(a =>out)=(2,3);
(a=>out)=(4,5);
showcancelled out_b;
pulsestyle_ondetect out_b;
(b=>out_b)=(5,6);
(b=>out_b)=(3,4);
endspecify

specify
showcancelled out,out_b;
pulsestyle_ondetect out,out_b;
(a =>out)=(2,3);
(b=>out)=(3,4);
(a =>out_b)=(3,4);
(b=>out_b)=(5,6);
endspecify"

TO

"Example 3-Both these specify blocks produce the same result. Outputs out and out_b are both declared showcancelled and on-detect.

specify
showcancelled out;
pulsestyle_ondetect out;
(a => out)=(2,3);
(b => out)=(4,5);
showcancelled out_b;
pulsestyle_ondetect out_b;
(a => out_b)=(3,4);
(b => out_b)=(5,6);
endspecify

specify
showcancelled out,out_b;
pulsestyle_ondetect out,out_b;
(a => out)=(2,3);
(b => out)=(4,5);
(a => out_b)=(3,4);
(b => out_b)=(5,6);
endspecify"

In addition to "specify" and "endspecify" being bold,
"showcancelled" and "pulsestyle_ondetect" should also be bold.

617 lrmdraft
2001b
word "parameter" should be "argument"

CHANGE "parameter" TO "argument" in the following locations,
except as noted otherwise:


* 5.6.7, para. 1:
"Task and function parameter passing is by value".


* 17.1.1:
"A $write task supplied without parameters prints nothing at all."


* 17.1.1.7:
"For each %s specification that appears in a string, a corresponding
parameter shall follow the string in the argument list."


* 17.2.2:
"The first parameter shall be either a multi channel descriptor or a file
descriptor,"

"The messages variable can then be used as the first parameter in a file
output task to direct output to all three channels at once."


* 17.2.3:
"The first parameter to $swrite shall be a reg variable to which the
resulting string shall be written,"


* 17.2.8:
"If both start and finish addresses are specified as parameters to the
task,"

"When addressing information is specified both in the system task and in
the data file, the addresses in the data file shall be within the
address range specified by the system task parameters;"


* 17.4.1:
Table 77 (column heading) "Parameter value"


* 17.6.1:
"The q_id parameter is an integer input that shall uniquely identify the
new queue. The q_type parameter is an integer input. The value of the
q_type parameter specifies the type of the queue as shown in Table 17-14."

"The maximum length parameter is an integer input that specifies the
maximum number of entries allowed on the queue."

CHANGE "maximum length" to "max_length" in Courier font.


* 17.6.2:
"The q_id parameter is an integer input that indicates to which queue to
add the entry. The job_id parameter is an integer input that identifies
the job.
The inform_id parameter is an integer input that is associated with the
queue entry. Its meaning is user-defined. For example, inform_id
parameter can represent execution time for an entry in a CPU model. The
status parameter reports on the success of the operation or error
conditions as described in Table 17-16."

Change "For example, inform_id parameter"
to "For example, the inform_id parameter"

Change "status" to Courier font.
Change "status parameter" to "status code".


* 17.6.3:
"The q_id parameter is an integer input that indicates from which queue
to remove. The job_id parameter is an integer output that identifies the
entry being removed. The inform_id parameter is an integer output that
the queue manager stored during $q_add. Its meaning is user-defined. The
status parameter reports on the success of the operation or error
conditions as described in Table 17-16. "

Change "status" to Courier font.
Change "status parameter" to "status code".


* 17.6.4: ADD to the end,
"The status code reports on the success of the operation or error
conditions as described in Table 17-16." ("status" in Courier font.)


* 17.6.5:
Table 17-15 (title) "Parameter values for $q_exam system task"


* 17.6.5: ADD to the end,
"The status code reports on the success of the operation or error
conditions as described in Table 17-16." ("status" in Courier font.)


* 17.6.6:
"All of the queue management tasks and functions return an output status
parameter. The status parameter
values and corresponding information are described in Table 17-16."

Change "status parameter" to "status code".


* Table 17-16 (title, column heading) "Status parameter value"

Change "status parameter" to "status code".


* 17.9.1:
"The seed parameter controls the numbers that $random returns such that
different seeds generate different random streams. The seed parameter
shall be either a reg, an integer, or a time variable."


* 17.9.2:
"All parameters to the system functions are integer values. For the
exponential, poisson, chisquare, t, and erlang functions, the parameters
mean, degree of freedom, and k_stage shall be greater than 0.

Change "mean, degree of freedom, "
to "mean, degree_of_freedom, " in Courier font.


"That is, $dist_uniform returns random numbers uniformly distributed in
the interval specified by its parameters.


"For each system function, the seed parameter is an inout parameter; ...

Change "seed" to Courier font.


"The argument for the seed parameter should be an integer variable that
is initialized by the user and only updated by the system function.

Change "The argument for the seed parameter" to "The seed argument".
Change "seed" to Courier font.


"In the $dist_uniform function, the start and end parameters are integer
inputs that bound the values returned.

Change "start" and "end" to Courier font, also a 2nd time in this paragraph.


"The mean parameter, used by $dist_normal, $dist_exponential,
$dist_poisson, and $dist_erlang, ...

Change "mean" to Courier font.


"The standard deviation parameter used with the $dist_normal function is
an integer input that helps determine the shape of the density function.

Change "standard deviation"
to "standard_deviation" in Courier font twice in this paragraph.


"The degree of freedom parameter used with the $dist_chi_square and
$dist_t functions is an integer input
that helps determine the shape of the density function.

Change "degree of freedom"
to "degree_of_freedom" in Courier font.


* The new 19.7 (`line), from issue #16, contains "parameter" once in para. 4
and 3 times in para. 6 according to the paragraph division that I made in
editing:
"All parameters in the `line directive are required."
"The number parameter shall be a positive integer ...
The filename parameter shall be a string constant ...
The level parameter shall be 0, 1, or 2."

However, "argument" does not sound natural here, so leave "parameter".


* C.1, para. 2 once, para. 3 twice:
"The number of parameters to the system function may vary according to how much information is desired."
"If additional parameters are supplied to the $countdrivers function, each parameter returns the information described in Table C-1."


* Table C-1 title "Parameter return value for $countdriver function", twice.


* C.2, para. 2:
"the parameter to the system function is a memory element reference".


* C.4, last para:
"An optional file name parameter for $key causes ..."


* C.5, para. 1 twice:
"When invoked without a parameter, $list produces ..."
"If an optional parameter is supplied, it shall refer ..."


* C.6, para. 2:
"An optional file name parameter for $log causes ..."


* C.7, para. 2:
"The $reset_value system function returns the value specified by the the
reset_value parameter argument to the $reset system task."

Delete "parameter".


* C.8, para. 2 and 3:
"All three system tasks take a file name as a parameter."
"The $save system task saves the complete state into the host operating
system file specified as a parameter."

Delete the words "host operating sysem".
Change "a parameter" to "an argument".


* C.10:
"This task accepts a single parameter argument that shall be the ..".

Delete "parameter".


* C.11, three times:
"An optional integer parameter can be given to $showscopes.
A non-zero parameter value causes ...
No parameter or a zero value results in ..."


* C.12:
"When invoked without parameters, $showvars displays the status ..."

620 lrmdraft
2005: 17.2.8
17.2.8: $readmem clarifications

In 17.2.8,

CHANGE paragraph 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 lowest
address in the memory. Consecutive words shall be loaded
until either the memory is full or the data file is
completely read. 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 toward
the highest address in the memory.

TO (changes in CAPITALS)

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. Consecutive words shall be loaded
until either the HIGHEST ADDRESS IN THE MEMORY IS REACHED or
the data file is completely read.
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 toward
the highest address in the memory. IN BOTH CASES, LOADING
SHALL CONTINUE UPWARD EVEN AFTER AN ADDRESS SPECIFICATION IN
THE DATA FILE.
627 lrmdraft
2001b
5.4.1(2): "time step 1" should be "0" ?

Propose to CHANGE in 5.4.1(2)
FROM

"time step 1"

TO

"simulation time 0".

628 lrmdraft
2001c: 13.2, A.1.1
13.2, A.1.1: file_path_spec vs. file_path (175B)

1. In Syntax 13-2 and A.1.1, DELETE

"file_path_spec ::= file_path".


2. In NOTE 1 after Syntax 13-2, CHANGE

"The file_path uses file system-specific notation ..."

TO

"file_path_spec uses file system-specific notation ..."


3. In the paragraph following NOTE 2,

"Any file encountered by the compiler which does not match any library's
file_path specification shall by default be compiled into a library named work."

CHANGE "file_path specification" to "file_path_spec".

629 lrmdraft
2005: 12.4.2
12.4.2: generate clarification on naming of nested constructs

In para. 5 of new 12.4.2 ("Conditional generate constructs"), which says,

CHANGE the sentence

"The generate blocks of the directly nested construct are treated as if they belong to the outer construct, and therefore can have the
same name as the generate blocks of the outer construct."

TO

"The generate blocks of the directly nested construct are treated as if
they belong to the outer construct. Therefore they can have the same name
as the generate blocks of the outer construct, and they cannot have the
same name as any declaration in the scope enclosing the outer construct
(including other generate blocks in other generate constructs in that scope)."


ADD a paragraph break between

"This allows complex conditional generate schemes to be expressed without creating unnecessary levels of generate block hierarchy."
and "The most common use of this would be to create an if-else-if generate scheme with any number of else-if clauses, ..."


630 lrmdraft
2001c: 17.2.1
17.2.1: missing closure of parenthetical comment

In 17.2.1,

CHANGE

"If a file can not be opened (either the file doesn't exist,
and the type specified is "r", "rb", "r+", "r+b", or "rb+",
or the permissions do not allow the file to be opened at
that path, a zero is returned for either the mcd or the fd.
Applications can call $ferror to determine the cause of the
most recent error (see 17.2.7)."

TO

"If a file can not be opened (either the file does not exist
and the type specified is "r", "rb", "r+", "r+b" or "rb+",
or the permissions do not allow the file to be opened at
that path), a zero is returned for the mcd or fd.
Applications can call $ferror to determine the cause of the
most recent error (see 17.2.7)."


632 lrmdraft
2001c: 17.2.1
2001c: 17.2.1: MSB is 31, not 32

In 17.2.1, in

"The most significant bit (bit 32) of a multi channel descriptor is reserved"

and

"The most significant bit (bit 32) of a fd is reserved, and shall always be set"

CHANGE 32 to 31.
633 lrmdraft
2001c: 10.2.2
10.2.2: "concatenation of real" is illegal

In 10.2.2, list following para. 3:

CHANGE

"Concatenations of reg, integer, real, realtime and time variables"

TO

"Concatenations of reg, integer and time variables"

635 lrmdraft
2005_D3
2005D4/12.5: overly restrictive hierref limitation

In 1364-2005/D4, 12.5 ("Hierarchical names"):


DELETE the sentence:

"Automatic tasks and functions are exceptions, and do not
create visible branches that can be referenced (see 10.2.1
and 10.3.1)."

CHANGE the sentence

"Unnamed generate blocks are also exceptions."

TO

"Unnamed generate blocks are exceptions."
636 lrmdraft
2001b
4.2.3.2 et al: null character is "NUL", not "NULL"

CHANGE "NULL" to "NUL" in

4.2.3.2: "The comparison and concatenation operators shall not distinguish
between zeros resulting from padding and the original string characters (\0,
ASCII NULL)."


4.2.3.3: The null string ("") shall be considered equivalent to the ASCII NULL
("\0") which has a value zero (0), which is different from a string "0".


27.15: "The format of the argv array is that each pointer in
the array shall point to a NULL terminated character array
which contains the string located on the tool's invocation command line."

27.15: "The remaining entries shall contain pointers to
NULL terminated character arrays containing the different options in the file."

637 lrmdraft
2001c: 12.7
12.7: missing words

In 12.7, DELETE the sentence in para. 3:

"The search shall cross generate block, named block, task,
and function boundaries but not module boundaries."

639 vsgpassed
2001c
fix use of "shall" and "may" by IEEE rules

The editor is requested to examine in his copious free
time the use of the terms "shall", "will" and "must"
in the LRM, change where needed to conform to IEEE style,
and submit to the WG a list of changes he
made and of possible additional changes.

Similarly,
the editor is requested to examine in his copious free
time the use of the terms "can" and "may"
in the LRM, change where needed to conform to IEEE style,
and submit to the WG a list of changes he
made and of possible additional changes.
640 lrmdraft

Add 'uwire' net type to enforce single-driver restriction

-----------------------------------------------------------------------------
Annex A - A.2.2.2 and syntax box in 3.2.1:

CHANGE:

    net_type ::=
          supply0 | supply1
        | tri  | triand | trior | tri0 | tri1 | wire | wand | wor 

TO:

    net_type ::=
          supply0 | supply1
        | tri  | triand | trior | tri0 | tri1 | uwire | wire | wand | wor


-----------------------------------------------------------------------------
3.7 Net types

In table 2, CHANGE:

 | wor     | trior  | trireg  |         |

TO:

 | wor     | trior  | trireg  | uwire   |

----------------------------------------------------------------------------
3.7 Net types

CHANGE:

3.7.5 Supply nets

TO:

3.7.6 Supply nets

ADD NEW SECTION 3.7.5:

 3.7.5 Unresolved nets

 The uwire net is an unresolved or unidriver wire, and is used to model
 nets that allow only a single driver. The uwire type can be used to
 enforce this restriction. It shall be an error to connect any bit of a
 uwire net to more than one driver. It shall be an error to connect a
 uwire net to a bidirectional terminal of a bidirectional pass switch. 

 The port connection rule in 12.3.9.3 ensures that an implementation
 enforces this restriction across the net hierarchy, or gives a warning
 if it does not.

----------------------------------------------------------------------------
3.12 Name spaces

CHANGE

 "includes wire, wor, wand, tri, trior, triand, tri0, tri1, trireg, supply0,
  and supply1"

TO

 "includes wire, wor, wand, tri, trior, triand, tri0, tri1, trireg, uwire,
  supply0, and supply1"

----------------------------------------------------------------------------
12.3.9 Port connection rules

ADD THIS SECTION:

 12.3.9.3 Rule 3

 If the net on either side of a port has the net type uwire,
 a warning shall be issued if the nets are not merged into
 a single net, as described in 12.3.10. 


-----------------------------------------------------------------------------
12.3.10.2 Net type table

CHANGE:

---------------------------------------------------------------------
         |                     External net
Internal |-----------------------------------------------------------  
  net    |wire,|wand,  |wor,  |trireg | tri0 | tri1 |supply0 |supply1  
         | tri |triand |trior |       |      |      |        |         
---------+-----+-------+------+-------+------+------+--------+---------
wire,    | ext | ext   | ext  | ext   | ext  | ext  | ext    | ext     
 tri     |     |       |      |       |      |      |        |              
---------+-----+-------+------+-------+-----+-----+--------+---------
wand,    | int | ext   | warn | warn  | warn | warn | ext    | ext      
triand   |     |       |      |       |      |      |        |              
---------+-----+-------+------+-------+------+------+--------+---------
wor,     | int | warn  | ext  | warn  | warn | warn | ext    | ext     
trior    |     |       |      |       |      |      |        |              
---------+-----+-------+------+-------+-----+-----+--------+---------
trireg   | int | warn  | warn | ext   | ext  | ext  | ext    | ext     
---------+-----+-------+------+-------+------+------+--------+---------
tri0     | int | warn  | warn | int   | ext  | warn | ext    | ext     
---------+-----+-------+------+-------+------+------+--------+---------
tri1     | int | warn  | warn | int   | warn | ext  | ext    | ext     
---------+-----+-------+------+-------+------+------+--------+---------
supply0  | int | int   | int  | int   | int  | int  | ext    | warn     
---------+-----+-------+------+-------+--- --+------+--------+---------
supply1  | int | int   | int  | int   | int  | int  | warn   | ext      
---------------------------------------------------------------------
KEY:
ext = The external net type is used
int = The internal net type is used
warn = A warning is issued and the external net type is used
--------------------------------------------------------------------------
TO:
----------------------------------------------------------------------------
         |                     External net
Internal |------------------------------------------------------------------  
  net    |wire,|wand,  |wor,  |trireg | tri0 | tri1 |uwire |supply0 |supply1
         | tri |triand |trior |       |      |      |      |        |
---------+-----+-------+------+-------+------+------+------+--------+-----
wire,    | ext | ext   | ext  | ext   | ext  | ext  | ext  | ext    | ext
 tri     |     |       |      |       |      |      |      |        |     
---------+-----+-------+------+-------+------+------+------+--------+-----
wand,    | int | ext   | ext  | ext   | ext  | ext  | ext  | ext    | ext
triand   |     |       | warn | warn  | warn | warn | warn |        | 
---------+-----+-------+------+-------+------+------+------+--------+-----
wor,     | int | ext   | ext  | ext   | ext  | ext  | ext  | ext    | ext
trior    |     | warn  |      | warn  | warn | warn | warn |        | 
---------+-----+-------+------+-------+------+------+------+--------+-----
trireg   | int | ext   | ext  | ext   | ext  | ext  | ext  | ext    | ext
         |     | warn  | warn |       |      |      | warn |        | 
---------+-----+-------+------+-------+------+------+------+--------+-----
tri0     | int | ext   | ext  | int   | ext  | ext  | ext  | ext    | ext
         |     | warn  | warn |       |      | warn | warn |        | 
---------+-----+-------+------+-------+------+------+------+--------+-----
tri1     | int | ext   | ext  | int   | ext  | ext  | ext  | ext    | ext
         |     | warn  | warn |       | warn |      | warn |        | 
---------+-----+-------+------+-------+------+------+------+--------+-----
uwire    | int | int   | int  | int   | int  | int  | ext  | ext    | ext
         |     | warn  | warn | warn  | warn | warn |      |        |     
---------+-----+-------+------+-------+------+------+------+--------+-----
supply0  | int | int   | int  | int   | int  | int  | int  | ext    | ext
         |     |       |      |       |      |      |      |        | warn    
---------+-----+-------+------+-------+------+------+------+--------+-----
supply1  | int | int   | int  | int   | int  | int  | int  | ext    | ext
         |     |       |      |       |      |      |      | warn   |     
--------------------------------------------------------------------------
KEY:
ext = The external net type is used
int = The internal net type is used
warn = A warning is issued 
----------------------------------------------------------------------------

----------------------------------------------------------------------------
19.2 `default_nettype

In Syntax 19-1, CHANGE

 trior|trireg|none

TO

 trior|trireg|uwire|none


----------------------------------------------------------------------------
18.2.3.8 $var

AFTER THE NUMBERED LIST, ADD THE FOLLOWING PARAGRAPH:

In the $var section, a net of net type uwire shall have a variable type 
of wire. 

----------------------------------------------------------------------------
Annex G: vpi_user.h

AFTER:

#define vpiNone 12    /* no default net type (1364-2000) */

ADD:

#define vpiUwire 13   /* unresolved wire net (1364-2005) */


----------------------------------------------------------------------------
Annex B

ADD "uwire" to list of keywords.

<\pre>



643 lrmdraft
2001b
17.2.2: not a logical OR

In 17.2.2,

DELETE the word "logical" from the sentence,

"To create a descriptor that directs output to the standard output as
well, the messages variable is a bit-wise logical or with the constant 1,
which effectively enables channel 0."

647 lrmdraft

Built-in functions use in constant expressions

Unknown
648 lrmdraft

Addition of Clause 2 is required

Unknown

Hosted by Boyd Technology