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