Tue Oct 4 01:00:37 2005 PST
| Release | Meaning |
|---|---|
| 2001a | Issue against 1364-2001 First Edition |
| 2001b | Issue against 1364-2001 Second Edition (Possibly also issue in First Edition) |
| 2001a, 2001b | Issue 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
|
| 173 | lrmdraft
|
2001b: 1.4, 2.5.1, 3.1, 7.10.1, 7.10.2, passim
|
misc typos
|
1. Section 1.4: Paragraph beginning "Clause 21": The title should end with colon. Next sentence should begin on same line. 2. Section 2.5.1: This piece of the proposal is covered by 116. 3. Section 3.1: End of paragraph. Change ".." to "." . 4. Section 7.10.1, last sentence: Change "pull 1" to "pull1". Change both occurrences of "strong 0" to "strong0" Change all three to bold Times, as shown at beginning of 7.9. (Note - the format of strength indications is inconsistent elsewhere as well.) 5, Section 7.10.2, 1st paragraph, 2nd bullet: In "strength1" and "strength0", change the "0" and "1" to Times font, not fixed font, as in bullets 3 and 4. 6. Entire document: Change all Clause titles to Helvetica 14 point including the number. |
| 174 | lrmdraft
|
2001b: 3.2.1 (Syntax 3-1), A.2.2.3
|
3.2.1, A.2.2.3 -- delay_value ambiguous
|
Sections 3.2.1, A.2.2.3: 11/18/02 - Passed by ETF REPLACE (note '()' are bold): delay3 ::= # delay_value | #( delay_value [ , delay_value [ ,delay_value ] ] ) delay2 ::= # delay_value | #( delay_value [ , delay_value ] ) delay_value ::= unsigned_number | parameter_identifier | specparam_identifier | mintypmax_expression WITH (note '()' are bold): delay3 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression [, mintypmax_expression]]) delay2 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression]) delay_value ::= unsigned_number | real_number | identifier |
| 176 | lrmdraft
|
2001b, 12.1.3.2
|
12.1.3.2, Example 5: wrong generate name
|
In section 12.1.3.2 example 5: Change the for loop condition on the first line after the generate <bold generate> from: (i=0; i<SIZE+1; i=i+1) to: (i=0; i<SIZE; i=i+1) On the next line in the comment change: B1[i].N1[i] to: B1[i].N1 |
| 177 | lrmdraft
|
2001b: 12.1.3.4 (Example 8)
|
12.1.3.4, Example 8 (again): ba instead of ba[0]
|
Section 12.1.3.4 Example 8: In the secon |