From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Feb 10 2000 - 02:09:17 PST
----------------------------------------
SOURCE: Cliff Cummings
page iv
WAS:
Maqsoodul (Maq) Mannan, Chair
Kasumi Hamaguchi, Vice Chair (Japan)
Alec G. Stanculescu, Vice Chair (USA)
Andrew T. Lynch, Leader PLI/VPI Task Force
Lynn A. Horobin, Secretary
Yatin Trivedi, Technical Editor
Andrew T. Lynch, Leader PLI/VPI Task Force
IS:
Maqsoodul (Maq) Mannan, Chair
Kasumi Hamaguchi, Vice Chair (Japan)
Alec G. Stanculescu, Vice Chair (USA)
Lynn A. Horobin, Secretary
Yatin Trivedi, Technical Editor
PROPOSED CHANGE:
Drew is listed on the next page as the PLI Task Force Chair
----------------------------------------
SOURCE: E-mail from: andersn@nortelnetworks.com
Date: Fri, 03 Dec 1999
WAS:
The Behavioral Task Force consisted of the following members:
Clifford E. Cummings, Leader
Kurt Baty
J. Bhasker
Leigh Brady
Dan Fitzptrick
Tom Fitzpatrick
James Markevitch
Michael McNamara
Steve Meyer
Anders Nordstrom
Karen Pieper
Vivek Sagdeo
Steven Sharp
Alec Stanculescu
Alex Zamfirecsu
IS:
The Behavioral Task Force consisted of the following members:
Clifford E. Cummings, Leader
Kurt Baty
Stephen Boyd
Shalom Bresticker
Tom Fitzpatrick
Adam Krolnik
James Markevitch
Michael McNamara
Anders Nordstrom
Karen Pieper
Steven Sharp
Stuart Sutherland
PROPOSED CHANGE:
Recognize actual BTF participants
----------------------------------------
SECTION 2
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
28 Jan 2000
Section 2.8 Attributes
Was:
See the syntax at the end of this section for a list of statements that may
have attributes attached to them.
Proposed:
See the syntax box at the end of this section for a list of statements that
may have attributes attached to them.
Syntax 2-3 Statements with attributes attached.
module declarations
module or generate item
inout declaration
input declaration
output declaration
integer declaration
net declaration
reg declaration
time declaration
real declaration
realtime declaration
event declaration
function declaration
task declaration
block reg declaration
parameter declaration
local parameter declaration
specparam declaration
gate instantiation
module instantiation
ordered port connection
named port connection
udp declaration
udp output declaration
udp input declaration
initial construct
always construct
par(allel) block
seq(ential) block
statement
conditional statement
if else if statement
case statement
case_item
loop_statement
function statement
function case statement
function loop statement
function seq(ential) block
function conditional statement
function call
constant function call
system function call
unary operator
binary operator
conditional operator
Proposed change:
Add missing table referred to in the text.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 9, section 2.5.1 Integer constants, ninth paragraph)
WAS:
shall be treated signed integers
PROPOSED IS:
shall be treated as signed integers
PROPOSED CHANGE:
Grammatical correction: add the missing word "as".
----------------------------------------
SECTION 3
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 3.11.3, Syntax box 3.5, the title of the box
WAS:
Syntax 3-5-Syntaof the specparam declaration
PROPOSED IS
Syntax 3-5-Syntax of the specparam declaration
PROPOSED CHANGE:
Correct spelling typo
----------------------------------------
SECTION 4
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
13 Dec 1999
Draft 4 page 57, Table 4-21
WAS:
---------------------
i op j, where op is:
+ - / % & | ^ ^~ ~^
---------------------
op i, where op is:
+,-,~,i*j
---------------------
<p>PROPOSED IS:
---------------------
i op j, where op is:
+ - * / % & | ^ ^~ ~^
---------------------
op i, where op is:
+ - ~
---------------------
PROPOSED CHANGE:
The multiplication operator '*' was incorrectly put in with the unary
operators instead of with the binary operators. It needs to be moved
up one line. It also should just say '*', not 'i*j', to be consistent
with the rest of the table. Also, some of the operator listings use
commas to separate the different operators, while others use spaces.
This should be made consistent for all entries, either all using commas
or all using spaces.
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
SOURCE: E-mail from: sharp@cadence.com
13 Dec 1999
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Draft 4 page 41, section 4.1.5, paragraph 2 (after table 4-5).
WAS:
Real results of the power operator shall match the result of the pow()
function from the C math library, including exceptional cases.
>>Need more here re: pow<<
PROPOSED IS:
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.
PROPOSED CHANGE:
Modify as requested by VSG.
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
13 Dec 1999
Replaced later by e-mail dated:
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
13 Dec 1999
Replaced later by e-mail dated:
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
13 Dec 1999
Draft 4 page 169, Syntax 12-3
WAS:
generate_loop_statement ::=
for ( genvar_assignment; genvar_expression; genvar_assignment) generate_item
begin : generate_block_identifier
{ generate_item }
end
<p>PROPOSED IS:
generate_loop_statement ::=
for ( genvar_assignment; genvar_expression; genvar_assignment)
begin : generate_block_identifier
{ generate_item }
end
PROPOSED CHANGE:
Remove extraneous 'generate_item' accidentally left from old syntax.
<p>Draft 4 page 174, example 5
WAS:
// scope B1[i].B2[j
PROPOSED IS:
// scope B1[1].B2[j]
PROPOSED_CHANGE:
Add missing close bracket.
The rest of the proposed changes for generates appear to be fine.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 40, section 4.1.3 Using integer numbers in expressions)
WAS:
IntA = -'4sd 12 / 3; // -'4sd12 is the negative of the 4-bit
PROPOSED IS:
IntA = -4'sd 12 / 3; // -4'sd12 is the negative of the 4-bit
PROPOSED CHANGE:
Transpose the digit 4 and quote characters in two places on this line.
This makes the example syntactically correct.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 275, section 17 System tasks and functions)
WAS:
$fsscanf
$ftel
PROPOSED IS:
$sscanf
$ftell
PROPOSED CHANGE:
Correct typos: $ftel and $fsscanf.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
(Draft 4 page 58, section 4.4.3)
PROPOSED CHANGE:
The sentence "Simulator output for this example:" should be against
the left margin and should use the standard font, not the typewriter
font.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 4.2.1: The 4th paragraph is out of context - pg. 50
WAS: (1st & 4th paragraph)
Bit-selects extract a particular bit from a vector net or reg. 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.
...
The bit-select or part-select of a reg declared as real or realtime shall
be considered illegal.
PROPOSED IS (1st paragraph)
Bit-selects extract a particular bit from a vector net or reg. 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. The bit-select or part-select of a reg declared as
real or realtime shall be considered illegal.
PROPOSED CHANGE:
Combine paragraphs 1 & 4
----------------------------------------
SECTION 6
----------------------------------------
SOURCE: E-mail from: jam@magic.com
20 Dec 1999
WAS:
6.2.1 reg declaration statement
Register declaration assignments are special cases of procedural
assignments as they assign values to declarations of integer, real,
realtime, reg and time variables. Register declaration assignments allow an
initial value to be made in the same statement which declares integer,
real, realtime, reg and time variables. The assignment shall be a constant
expression. The assignment does not have duration; instead, the register
variables hold values until the next assignment to the individual register
variables. Register declaration assignments to arrays are not allowed.
PROPOSED IS:
6.2.1 Variable declaration statement
The variable declaration assignment is a special case of procedural
assignment in that it assigns a value
to a variable. It allows an initial value to be placed in a variable in the
same statement that declares the
variable. The assignment must be to a constant expression. The assignment
does not have duration; instead,
the variable holds the value until the next assignment to that variable.
Variable declaration assignments to an array are not allowed. Variable
declaration assignments are only allowed at the module level.
PROPOSED CHANGE:
Add a clarification about a restriction on the use of variable declaration
assignment.
----------------------------------------
SECTION 9
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
(Draft 4 page 139, section 9.7.7 Intra-assignment timing controls)
WAS:
will not execute event_expression.
if a is assigned -3 it will execute the event_expression
if a is declared as an unsigned reg but not if it is signed.
PROPOSED IS:
// will not execute event_expression.
// if a is assigned -3 it will execute the event_expression
// if a is declared as an unsigned reg but not if it is signed.
PROPOSED CHANGE:
In the example, the three comments should begin with comment characters.
----------------------------------------
SECTION 10
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
WAS:
module ram_model (address, write, chip_select, data);
parameter data_width = 8;
parameter ram_depth = 256;
localparam adder_width = clogb2(ram_depth);
input [adder_width - 1:0] address;
input write, chip_select;
inout [data_width - 1:0] data;
//define the clogb2 function
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
IS:
module ram_model (address, write, chip_select, data);
parameter data_width = 8;
parameter ram_depth = 256;
localparam adder_width = clogb2(ram_depth);
input [adder_width - 1:0] address;
input write, chip_select;
inout [data_width - 1:0] data;
//define the clogb2 function
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
PROPOSED CHANGE:
The indentation in the example is not a good, intuitive style.
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
28 Jan 2000
Draft 4 page 153, section 10.2.3, only paragraph.
WAS:
A task may be enabled more than once concurrently. Regs declared
automatic and all regs of an automatic task shall be replicated on
each concurrent task invocation to store state specific to that
invocation. Regs declared static (not automatic) for a static task
shall be static in that there shall be a single reg corresponding to
each declared local reg, regardless of the number of concurrent
activations of the task.
PROPOSED IS:
A task may be enabled more than once concurrently. All variables of an
automatic task shall be replicated on each concurrent task invocation
to store state specific to that invocation. All variables of a static task
shall be static in that there shall be a single variable corresponding to
each declared local variable in a module instance, regardless of the number
of concurrent activations of the task. However, static tasks in
different instances of a module shall have separate storage from each
other.
<p>PROPOSED CHANGE:
This change was submitted for Draft 4, but somehow failed to get
included. Now it has been modified to replace references to the word
reg with references to the word variable.
----------------------------------------
SOURCE: E-mail from: sharp@cadence.com
28 Jan 2000
<p>Draft 4 page 153, section 10.2.3, new paragraphs after paragraph 1
WAS:
PROPOSED IS:
Variables declared in static tasks shall retain their values between
invocations. They shall be initialized to the default initialization
value as described in section 3.2.2. Variables declared in automatic tasks
shall be initialized to the default initialization value whenever
execution enters their scope.
Because variables declared in automatic tasks are deallocated at the end
of the task invocation, they shall not be used in certain constructs
that might refer to them after that point.
-- They shall not be assigned values using non-blocking assignments
or procedural continuous assignments.
-- They shall not be referenced by procedural continuous assignments
or procedural force statements.
-- They shall not be referenced in intra-assignment event controls
of non-blocking assignments.
-- They shall not be traced with system tasks such as $monitor and
$dumpvars.
PROPOSED CHANGE:
This change was submitted for Draft 4, but somehow failed to get
included. Now modified to replace references to regs with references
to variables.
Describe the initialization and constraints on automatic variables as
approved by the BTF. This text could be put at the end of section
10.2.1 instead.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 10.3.1, first paragraph after the function syntax box, last three
sentences: pg. 154
WAS:
... If used, range_or_type shall specify the the return value of the
function is a real, and integer,a time a realtime or a value with a range
of [n:m] bits. A function shall have at least one input declared. A
function shall have at least one input declared.
PROPOSED IS:
... 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.
PROPOSED CHANGE:
- "the the" should be just "the"
- "and integer" should be "an integer.
- There should be a comma after "a time".
- The last sentence should be deleted. It is a repeat of the next to the
last sentence.
----------------------------------------
SECTION 12
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
Section 12.1, 2nd paragraph:
WAS:
A module definition shall be enclosed between the keywords module and
endmodule. The identifier following the keyword module shall be the name of
the module being defined. The optional list of list of parameter
definitions shall specify an ordered list of the parameters of the module.
The optional list of ports or port definition shall specify an ordered list
of the ports of the module. The order used used in defining the list of
parameters in the module_parameter_port_list and in the list of ports can
be significant when instantiating the module (see 12.1.2). The identifiers
in this list shall be declared in input, output, and inout statements
within the module definition. Ports declared in the list of port
declaration shall not be redeclared. The module items define what
constitutes a module, and they include many different types of declarations
and definitions; many of them have already been introduced.
PROPOSED IS:
A module definition shall be enclosed between the keywords module and
endmodule. The identifier following the keyword module shall be the name of
the module being defined. The optional list of parameter declarations shall
specify an ordered list of the parameters for the module. The optional list
of ports or port declaraionts shall specify an ordered list of the ports
for the module. The order used in defining the list of parameters in the
module_parameter_port_list and in the list of ports can be significant when
instantiating the module (see 12.1.2). The identifiers in this list shall
be declared in input, output, and inout statements within the module
definition. Ports declared in the list of port declarations shall not be
redeclared within the body of the module. The module items define what
constitutes a module, and they include many different types of declarations
and definitions; many of them have already been introduced.
PROPOSED CHANGE:
Delete duplicates and typos. New port terminology (less definition, more
declaration).
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
29 Dec 1999
Draft 4, 12.1.2, pp 165-166, paragraphs at bottom of 165 and top of 166.
WAS:
The list of module connections shall be provided only for modules defined
with ports. The parentheses, however, are always required. When a list of
module connections is given using the ordered port connection method, the
first element in the list shall connect to the first port declared in the
module, the second to the second port, and so on. See 12.3 for a more
detailed discussion of ports and port connection rules.
A connection can be a simple reference to a reg or a net identifier, an
expression, or a blank. An expression can be used for supplying a value to
a module input port. A blank module connection shall represent the
situation where the port is not to be connected.
PROPOSED IS:
The list of port connections shall be provided only for modules defined
with ports. The parentheses, however, are always required. When a list of
port connections is given using the ordered port connection method, the
first element in the list shall connect to the first port declared in the
module, the second to the second port, and so on. See 12.3 for a more
detailed discussion of ports and port connection rules.
A connection can be a simple reference to a variable or a net identifier,
an expression, or a blank. An expression can be used for supplying a value
to a module input port. A blank port connection shall represent the
situation where the port is not to be connected.
<p>PROPOSED CHANGE:
Change module connections to port connections
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.2.1, last paragraph begins:
WAS:
"IThe value of a genvar..."
^
PROPOSED IS:
"The value of a genvar..."
PROPOSED CHANGE:
The spurious letter "I" should be deleted.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3, 3rd paragraph:
WAS:
"localparam" in courier font, but "parameter" is not.
PROPOSED CHANGE:
Use non-courier font for both
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2, in the paragraph just after example 2:
WAS:
The models in examples 3 and 4 are parameterized modules of ripple adders
using a loop to generate Verilog gate primitives. Example 3 uses a two
dimensional net declaration outside of the module to make the connections
between the gate primitives while example 4 makes the net declaration
inside of the generate loop to generate the wires needed connect the gate
primitives for each iteration of the loop.
PROPOSED IS:
The models in examples 3 and 4 are parameterized modules of ripple adders
using a loop to generate Verilog gate primitives. Example 3 uses a two
dimensional net declaration outside of the generate loop to make the
connections between the gate primitives while example 4 makes the net
declaration inside of the generate loop to generate the wires needed
connect the gate primitives for each iteration of the loop.
PROPOSED CHANGE:
The net is not declared outside of the module (which would be illegal)
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2, example 3
WAS:
genvar i, j;
PROPOSED IS:
genvar i;
PROPOSED CHANGE:
The genvar variable "j" is not used, remove it from example 3.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2, example 4
WAS:
genvar i, j;
PROPOSED IS:
genvar i;
PROPOSED CHANGE:
The genvar variable "j" is not used, remove it from example 4.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2, example 4:
PROPOSED CHANGE:
The last few lines of the example are missing. The text is actually in the
Framemaker file, but is clipped because the text box containing the example
is too small. Increase the text box size.
(Cliff-note: there may be more text box size problems in this section)
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2:
PROPOSED CHANGE:
The example 3 caption on page 171 should be on the same page as the example
code on page 172.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2:
PROPOSED CHANGE:
The example 4 caption on page 172 should be on the same page as the example
code on page 173.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.2:
PROPOSED CHANGE:
The example 5 caption on page 173 should be on the same page as the example
code on page 174.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.3:
PROPOSED CHANGE:
The example 6 caption on page 174 should be on the same page as the example
code on page 175.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.1.3.4:
PROPOSED CHANGE:
The example 8 caption on page 175 should be on the same page as the example
code on page 176.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
Section 12.2 - pg. 178
WAS:
parameter FIFO_MSB = DEPTH*MSB; // These parameters are local, and
parameter FIFO_LSB = LSB; // cannot be overridden. They can be
// affected by altering the public
// parameters above, and the module
// will work correctly.
PROPOSED IS:
localparam FIFO_MSB = DEPTH*MSB; // These parameters are local, and
localparam FIFO_LSB = LSB; // cannot be overridden. They can be
// affected by altering the public
// parameters above, and the module
// will work correctly.
PROPOSED CHANGE:
Change the parameter keyword to localparam
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
(Draft 4 page 179, section 12.2.1 defparam statement)
WAS:
When defparams are encountered in source files, e.g., found by library
searching, the defparam from which the parameter takes it's value is
undefined.
PROPOSED IS:
When defparams are encountered in multiple source files, e.g., found by
library searching, the defparam from which the parameter takes it's value
is undefined.
PROPOSED CHANGE:
The last sentence of section 12.2.1 has the word "multiple" missing
from it.
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
"12.3.1 Port Definitions" - pg. 182
WAS:
The syntax for a port is given in Syntax 12-5.
PROPOSED IS:
The syntax for ports and a list of ports is given in Syntax 12-5.
PROPOSED CHANGE:
Going to add list_of_ports to the syntax box and delete port_definitions.
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
04 Jan 2000
"12.3.2 List of ports - pg. 182
WAS:
The port expression in the port definition can be one of the following:
- A simple identifier
- A bit-select of a vector declared within the module
- A part-select of a vector declared within the module
- A concatenation of any of the above"
PROPOSED IS:
The port reference for each port in the list of ports at the top of each
module declaration can be one of the following:
- A simple or escaped identifier
- A bit-select of a vector declared within the module
- A part-select of a vector declared within the module
- A concatenation of any of the above"
PROPOSED CHANGE:
The first line "A simple identifier" excludes escaped identifiers, which is
incorrect.
That line should be "A simple or escaped identifier".
Also changed "port expression in the port definition" to "port reference
for each port in the list of ports at the top of each module declaration"
to help clarify that we are talking about the port reference identifier
name at the top of each module declaration.
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
"12.3.2" - pp. 181-182
WAS:
The first type of module port definition with only a port_expression is an
implicit port definition. The second type is the explicit port definition.
This explicitly specifies the port_identifier used for connecting module
instance ports by name (see 12.3.6) and the port_expression which contains
identifiers declared inside the module as described in 12.3.3. Use of named
port connections shall not be used for implicit port definitions unless the
port_expression is a simple port_identifier.
PROPOSED IS:
The first type of module port with only a port_expression is an implicit
port. The second type is the explicit port. This explicitly specifies the
port_identifier used for connecting module instance ports by name (see
12.3.6) and the port_expression which contains identifiers declared inside
the module as described in 12.3.3. Use of named port connections shall not
be used for implicit ports unless the port_expression is a simple
port_identifier.
PROPOSED CHANGE:
Remove the confusing, multiply listed word "definition"
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
12.3.3, 1st paragraph - pg. 182
WAS:
Each port_expression listed in the list of ports for the module definition
shall be declared in the body of the module as an input, output, or inout
(bidirectional). This is in addition to any other declaration for a
particular port- for example, a reg or wire. The syntax for port
declarations is given in Syntax 12-6.
PROPOSED IS:
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). This is in addition
to any other data type declaration for a particular port- for example, a
reg or wire. The syntax for port declarations is given in Syntax 12-6.
PROPOSED CHANGE:
Replace module definition with module declaration (matches BNF) and clarify
that both port declarations and data type declarations are required. List
of ports and port expressions refer to the old port style. List of port
declarations refer to the new style.
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
12.3.3, 2nd paragraph - pg. 182
WAS:
If a port declaration includes a net_type or reg_type, then the port is
considered completely defined and it is an error for the port to be defined
again as a register or net. Because of this, all other aspects of the port
shall be defined in such a port declaration, including the signed and range
attributes if needed.
PROPOSED IS:
If a port declaration includes a net_type or reg_type, then the port is
considered completely declared and it is an error for the port to be
declared again with a variable or net data type declaration. Because of
this, all other aspects of the port shall be declared in such a port
declaration, including the signed and range definitions if needed.
PROPOSED CHANGE:
Replace more definitions with declarations and clarified that both port
declarations and data type declarations for the same port would be a syntax
error. Changed "signed and range attributes" to "signed and range
definitions" to avoid confusion with attributes.
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Anders in a BTF conference call, Jan 2000
(Draft 4 page 183, section 12.3.3, 2nd paragraph after syntax box 12-6)
WAS:
If a port declaration does not include a net_type or reg_type, then the
port can be again declared in a net or reg declaration. If the net or reg
is declared as a vector, the range specification between the two
declarations of a port declaration shall be identical. Once a name is
defined in a port declaration it shall not be defined again with the same
type or another type.
PROPOSED IS:
If a port declaration does not include a net_type or variable_type, then
the port can be again declared in a net or variable declaration. If the net
or variable is declared as a vector, the range specification between the
two declarations of a port shall be identical. Once a name is used in a
port declaration it shall not be declared again in another port declaration
or in a data type declaration.
Example:
input aport; // First declaration - okay.
input aport; // Error - multiple declaration, port declaration
output aport; // Error - multiple declaration, port declaration
reg aport; // Error - multiple declaration, data type declaration
PROPOSED CHANGE:
Removed " declaration" from the second to last sentence and added second
reference to "in a port declaration" in the last sentence of the paragraph
for clarification.
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4 page 184, from example at top of page
WAS:
module complex_ports ({c,d}, .e(f)); // Nets {c,d} receive the first
// port bits. Name 'f' is defined inside the module.
// Name 'e' is defined outside the module.
// Can't use named port connections of first port.
...
module same_port (.a(i), .b(i)); // Name 'i' is defined inside the
// module as a inout port. Names 'a' and 'b' are
// defined for port connections.
PROPOSED IS:
module complex_ports ({c,d}, .e(f)); // Nets {c,d} receive the first
// port bits. Name 'f' is declared inside the module.
// Name 'e' is defined outside the module.
// Can't use named port connections of first port.
...
module same_port (.a(i), .b(i)); // Name 'i' is declared inside the
// module as a inout port. Names 'a' and 'b' are
// defined for port connections.
PROPOSED CHANGE:
Removed "define" with "declared" in two places
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4 12.3.4, page 184, 1st paragraph
WAS:
An alternate syntax which minimizes the duplication of data can be used to
specify the ports of a module. Modules shall either be declared entirely
with the list of ports syntax as described in 12.3.2 or entirely using the
list of port_declarations as described in this section.
PROPOSED IS:
An alternate syntax which minimizes the duplication of data can be used to
specify the ports of a module. Modules shall either be declared entirely
with the list of ports syntax as described in 12.3.2 or entirely using the
list_of_port_declarations as described in this section.
PROPOSED CHANGE:
list_of_port_declarations (italicized and with all underscores)
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4 12.3.4, page 184, 2nd paragraph
WAS:
Each port definition provides the complete information about the port. The
ports direction, width, net or reg type, and whether the port is signed or
unsigned is completely described. The same syntax for input, inout and
output declarations is used as would be used for the list of port style
declaration; except the declaration is included in the port list rather
than separately.
PROPOSED IS:
Each declared port provides the complete information about the port. The
ports direction, width, net or variable type, and whether the port is
signed or unsigned is completely described. The same syntax for input,
inout and output declarations is used in the module header as would be used
for the list of ports style declaration; except the
list_of_port_declarations are included in the module header rather than
separately, after the ";" that terminates the module header.
PROPOSED CHANGE:
list_of_port_declarations italicized
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.4, page 185, 1st paragraph after the example at the top of
the page
WAS:
The port_reference type of module port declaration shall not be done using
list of port definition module declarations. Also ports so defined shall
only be simple identifiers. They shall not be bit-selects, part-selects or
concatenations (as in the example complex_ports); nor can a port be split
(as in the example split_ports), nor can they be named ports (as in the
example same_port).
PROPOSED IS:
The port_reference type of module port declaration shall not be done using
list_of_port_declarations style of module declarations. Also ports declared
using the list_of_port_declarations style shall only be simple identifiers.
They shall not be bit-selects, part-selects or concatenations (as in the
example complex_ports); nor can a port be split (as in the example
split_ports), nor can they be named ports (as in the example same_port).
PROPOSED CHANGE:
list_of_port_declarations italicized
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.5, page 185, 1st paragraph
WAS:
One method of making the connection between the ports expressions listed in
a module instantiation and the ports defined by the instantiated module is
the ordered list-that is, the ports expressions listed for the module
instance shall be in the same order as the ports listed in the module
definition.
PROPOSED IS:
One method of making the connection between the port expressions listed in
a module instantiation and the ports declared within the instantiated
module is the ordered list-that is, the port expressions listed for the
module instance shall be in the same order as the ports listed in the
module declaration.
PROPOSED CHANGE:
Correct typos and change definitions to declarations
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.5, page 185, module examples
PROPOSED CHANGE:
Add appropriate indenting for module examples
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
30 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.6, pp 185-186, paragraphs 1, 2 and bulleted list
WAS:
The second way to connect module ports consists of explicitly linking the
two names port for each side of the connection port definition name from
the module declaration to the expression - the name used in the module
definition, followed by the name used in the instantiating module. This
compound name is then placed in the list of module connections. The name of
port shall be the name specified in the module definition. The name of port
cannot be a bit-select, a part-select, or a concatenation of ports. If the
module port definition was implicit, the port_expression must be a simple
port_identifer which is used as name of port. If the module port definition
was explicit, the explicit name is used as the name of port.
The port expression can be any valid expression using identifiers in the
scope of the instantiating module:
- A simple identifier
- A bit-select of a vector declared within the module
- A part-select of a vector declared within the module
- A concatenation of any of the above
PROPOSED IS:
The second way to connect module ports consists of explicitly linking the
two names for each side of the connection, the port declaration name from
the module declaration to the expression - the name used in the module
declaration, followed by the name used in the instantiating module. This
compound name is then placed in the list of module connections. The port
name shall be the name specified in the module declaration. The port name
cannot be a bit-select, a part-select, or a concatenation of ports. If the
module port declaration was implicit, the port_expression must be a simple
port_identifer which is used as the port name. If the module port
declaration was explicit, the explicit name is used as the name of port.
The port expression can be any valid expression.
PROPOSED CHANGE:
Clarification and delete the bullet list.
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.6, page 186, module examples
PROPOSED CHANGE:
Add appropriate indenting for module examples
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4, 12.3.9.2, bullet list at top of page 188
WAS:
The following external items shall not be connected to the output or inout
ports of modules:
-Regs
- Expressions other than
- A scalar net
- A vector net
- A constant bit-select of a vector net
- A part-select of a vector net
- A concatenation of the expressions listed above
PROPOSED IS:
The following external items shall not be connected to the output or inout
ports of modules:
-Regs
- Expressions other than
- A scalar net
- A vector net
- A constant bit-select of a vector net
- A part-select of a vector net
- A concatenation of the expressions listed above
PROPOSED CHANGE:
More indentation on sub-list
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
28 Dec 1999
SOURCE: Cliff Cummings
09 Feb 2000
Draft 4 12.3.4, page 184, section title
WAS:
12.3.4 Lists of ports_definitions
PROPOSED IS:
12.3.4 Lists of port declarations
PROPOSED CHANGE:
Section title change
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
(Draft 4 page 192, section 12.5 Upwards name referencing)
WAS:
Variables V can be referenced if the name of the higher-level module
or its instance name is known.
PROPOSED IS:
Variables can be referenced if the name of the higher-level module
or its instance name is known.
PROPOSED CHANGE:
Remove extraneous "V" in the sentence.
----------------------------------------
SECTION 13
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
Section 13.2.1 Specifying libraries.
Was
library rtlLib "/*.v"; // matches all files in the current directory with a
.v suffix
library gateLib "./*.vg"; // matches all files in the current directory
with a .vg suffix
Proposed:
library rtlLib *.v; // matches all files in the current directory with
a .v suffix
library gateLib ./*.vg; // matches all files in the current directory
with a .vg suffix
Proposed change. Remove the erroneous '/' to indicate the current
directory. Remove "" from library declarations. Add more space between ";"
and comments.
----------------------------------------
SOURCE: Cliff Cummings
09 Feb 2000
WAS:
Example:
:
file top.v
IS:
Example:
file top.v
PROPOSED CHANGE:
Delete extra ":"
----------------------------------------
SECTION 17
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
27 Jan 2000
Section 17.1.1.2 - Table 17.2, pp. - 277-278
Was:
Proposed:
%l or %L Display library binding information
The formatting specification %l (or %L) is defined for displaying
the library information of the specific module. This information
shall be displayed as "library.cell" corresponding to the library
name the current module instance was extracted from and the cell
name of the current module instance. See section 13 for information
on libraries and configuring designs.
Proposed change:
Add definition of %l with rest of format specifiers. Functionality is
not new, only proposed paragraph text.
---------------------------------------------------------------
Section 17.10.2 "$value$plusargs(user_string, variable)
WAS:
If no string is found matching, the function returns the integer
value zero and the variable provided is not modified.
Proposed:
If no string is found matching, the function returns the integer
value zero and the variable provided is not modified. No warnings
shall be generated when the function returns 0.
Proposed change:
Clarify intention about use of function. Nonexistance of plusarg string
is define by return value of function; not by warning message issued.
<p><p>WAS:
The remainder string of the matching plusarg (the remainder is
the part of the plusarg string after the portion that matches the users
plusarg_string) will be converted from a string into the format
indicated by the format string and stored in the variable provided.
Proposed:
<Same>. If there is no remainding string, the value stored into the
variable should either be a zero or an empty string value.
Proposed change:
Clarify corner case for implementation. One could say the variable
should not be changed - however one is not left with an option
to produce an empty string if required.
<p>WAS:
This system function searches the list of plusargs (like the
$test$plusargs system function) for a user specified plusarg string.
Proposed:
<Same> The string is specified in the first argument to the system
function as either a string, or a register which will be intepreted
as a string.
Proposed change is:
Allow functionality in this example...
<user command line addition>
+TEST12
<example code>
reg [64*8:1] pstring;
...
pstring = "+TEST%d";
if ($value$plusargs(pstring, test[31:0))
begin
$display("Running test number %0d.", test);
startTest();
end
<output of example>
Running test number 12
The variable 'test' would get the value 'd12.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
20 Dec 1999
(Draft 3 page 281, section 17.5)
PROPOSED CHANGE:
Add the sentence: "Note that the input terms may be nets or variables
whereas the output terms must be variables." after syntax box 17-9.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
(Draft 4 page 302, section 17.5.4 Logic array personality formats)
WAS:
A synchronized version of this example has the following description:
PROPOSED IS:
A synchronous version of this example has the following description:
PROPOSED CHANGE:
Change the word "synchronized" to "synchronous" per friendly ammendment
of 11/1/99 VSG meeting.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
18 Jan 2000
Section 17.2.3:
WAS:
Optionally, these system tasks can be redefined (or additionally defined)
as functions that return the Number of characters in the resulting string
before any truncation that would occur if the reg to hold the result is not
large enough.
PROPSED IS:
<delete this paragraph>
PROPOSED CHANGE:
Delete the first of two paragraphs on page 287, section 17.2.3 that start
with the word "Optionally"
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
18 Jan 2000
Section 17.2.3:
WAS:
Optionally, the system task can be redefined (or additionally defined) as a
function that returns the number of characters in the resulting string
before any truncation that would occur if the reg to hold the result is not
large enough.
PROPSED IS:
<delete this paragraph>
PROPOSED CHANGE:
Delete the second of two paragraphs on page 287, section 17.2.3 that start
with the word "Optionally"
----------------------------------------
SCETION 19
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
Was:
Section 19.7 `line, last sentence of paragraph 2.
"The level parameter indicates whether an include file has
been specified (value is 1), an include file is exited (value is 2),
or neither has been done (value is 0).
Proposed:
"The level parameter indicates whether an include file has
been entered (value is 1), an include file is exited (value is 2),
or neither has been done (value is 0).
<p>Proposed change:
Switch 'specified' to 'entered' - removes ambiguity.
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
WAS:
-- If there is an `else compiler directive, the `else group of lines
is compiled.
Although the names of compiler directives are contained in the same
name space as text macro names, the names of compiler directives are
considered not to be defined by `ifdef, `ifndef, and `elseif.
PROPOSED IS:
-- If there is an `else compiler directive, the `else group of lines
is compiled.
-- Although the names of compiler directives are contained in the same
name space as text macro names, the names of compiler directives are
considered not to be defined by `ifdef, `ifndef, and `elsif.
PROPOSED CHANGE:
The new paragraph which begins "Although the names of compiler
directives" should have a long-dash in front of it, just like the
other items. It should also have some empty space separating it from
the previous item.
ALSO: correct the spelling of `elsif (the last word of the sentence).
----------------------------------------
SOURCE: E-mail from: shalom@msil.sps.mot.com
16 Dec 1999
PROPOSED CHANGES:
1. page 349, in Syntax 19-3, "text_macro_identifier" should not have italics.
text_macro_identifier is not a general identifier, only a simple_identifier.
2. page 349, 1st text line: "`text_macro" should be "`text_macro_name".
3. page 350, in Section 19.4 (`ifdef, etc.), paragraphs 1 and 2,
replace "variable name" by "text_macro_name".
4. page 351, in Syntax 19-5, "`elsif text_macro_name"
should be "`elsif text_macro_identifier". (in 2 places)
5. page 351, 1st text line: "text_macro_name" should be
"text_macro_identifier".
6. page 351, 2nd text line: Change "The `else compiler directive" to "The
`else and `elsif compiler directives".
7. page 351: Add an explanation of `ifndef as well as `ifdef.
8 . page 351: Add a blank line before the paragraph beginning "Although the
names of compiler directives ...". Otherwise, it looks like a continuation
of the 'else explanation. --
----------------------------------------
SOURCE: E-mail from: andersn@nortelnetworks.com
(*** modified by Cliff Cummings ***)
26 Jan 2000
WAS:
The time values in the modules that follow this directive are multiples of
10 sbecause
PROPOSED IS:
The time values in the modules that follow this directive are multiples of
10 us because
PROPOSED CHANGE:
Here is a minor typo on page 356 in the second 3 line paragraph, "sbecause"
should be "us because"
----------------------------------------
SOURCE: E-mail from: andersn@nortelnetworks.com
26 Jan 2000
Draft 4 page 355 section 19.8 second paragraph under Syntax 19-8
WAS:
The time_precision aregument specifies how delay values are rounded
before being used in simulation. The values used are accurate to within
the unit of time that is specified here. The smallest time_precision
argument of all the `timescale compiler directives in the design determines
the time unit of the simulation."
PROPOSED IS:
The time_precision aregument specifies how delay values are rounded
before being used in simulation. The values used are accurate to within
the unit of time that is specified here even if there is a smaller
time_precision argument elsewhere in the design. The smallest time_precision
argument of all the `timescale compiler directives in the design determines
the precision of the time unit of the simulation."
PROPOSED CHANGE:
Added clarifying comments: " even if there is a smaller time_precision
argument elsewhere in the design." and "the precision of"
----------------------------------------
@BNF
----------------------------------------
SOURCE: E-mail from: krolnik@lsil.com
15 Dec 1999
28 Jan 2000
Attributes
PROPOSED CHANGE: see BNF
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
10 Jan 2000
17 Jan 2000
18 Jan 2000
19 Jan 2000
24 Jan 2000
Many BNF Changes
PROPOSED CHANGE: see BNF
----------------------------------------
SOURCE: E-mail from: mac@verisity.com
7 Feb 2000
Function Calls
PROPOSED CHANGE: see BNF
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
A.8.2 - Function Declarations
PROPOSED CHANGE: see BNF
----------------------------------------
@ANNEXB
----------------------------------------
SOURCE: E-mail from: jam@magic.com
21 Dec 1999
Remove the word "unsigned" from Annex B
----------------------------------------
@ANNEXE
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 799, Annex E)
PROPOSED CHANGE:
Add the indication "normative" to this section as in 1364-1995.
----------------------------------------
@ANNEXF
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 807, Annex F)
PROPOSED CHANGE:
Add the indication "normative" to this section as in 1364-1995.
----------------------------------------
@ANNEXG
----------------------------------------
SOURCE: E-mail from: jam@magic.com
15 Dec 1999
(Draft 4 page 815, Annex G)
PROPOSED CHANGE:
Add the indication "normative" to this section as in 1364-1995.
----------------------------------------
@INDEX
----------------------------------------
SOURCE: E-mail from: andersn@nortelnetworks.com
Date: Fri, 03 Dec 1999
PROPOSED CHANGE: On page 833 in the index there is still a problem with
`timescale.
It shows up twice but with different types of accent.
The last one before Numerics should be changed. Is the problem that it is
wrong in the text on page 612?
----------------------------------------
SOURCE: E-mail from: jam@magic.com
23 Jan 2000
PROPOSED CHANGE:
Need to add "constant functions" to the index.
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
PROPOSED CHANGE:
add "**" and "power operator" to the index ( Section 4.1.5 )
----------------------------------------
SOURCE: E-mail from: stuart@sutherland-hdl.com
02 Feb 2000
PROPOSED CHANGE:
Add "$signed" and "$unsigned" to the index ( Section 4.5)
----------------------------------------
<p>//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design, Inc. Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:11 PDT
and
sponsored by Boyd Technology, Inc.