From: Michael McNamara (mac@verisity.com)
Date: Fri Dec 22 2000 - 18:00:04 PST
The following proposal has been made and seconded in the BTF, and I
send it on to the main group. Due to oversight, and the merging of
two proposals, the implementation of tasks and fucntions with the new
'ansi port' syntax was done wrong. The following proposal corrects
this. This is an errata, and _must_ be included in Verilog 2000 for
the thing to make any sense at all.
<x-html>
<html>
<body>
<p>Change section 10.2.1 to read:
<table><tr><td bgcolor="white">
<h1>10.2.1 Task declarations </h1>
<p>The syntax for defining tasks is given in Syntax 10-1.</p>
<table border="1">
<tr>
<td>
<tt>
<pre>
task_declaration ::= <i>(From Annex A - A.2.7)</i>
<b>task</b> [automatic ] task_identifier ;
{ task_item_declaration }
statement
<b>endtask</b>
| <b>task</b> [ automatic ] task_identifier ( task_port_list ) ;
{block_item_declaration }
statement
<b>endtask</b>
task_item_declaration ::=
block_item_declaration
| { attribute_instance } <font color="red">tf_</font>input_declaration ;
| { attribute_instance } <font color="red">tf_</font>output_declaration ;
| { attribute_instance } <font color="red">tf_</font>inout_declaration ;
task_port_list ::=
task_port_item { ,task_port_item }
task_port_item ::=
{ attribute_instance } <font color="red">tf_</font>input_declaration
| { attribute_instance } <font color="red">tf_</font>output_declaration
| { attribute_instance } <font color="red">tf_</font>inout_declaration
<font color="red">
tf_input_declaration ::=
<b>input [ reg ] [ signed ]</b> [ range ]
list_of_port_identifiers
| <b>input [ task_port_type ]</b>
list_of_port_identifiers
tf_output_declaration ::=
<b>output [ reg ] [ signed ]</b> [ range ]
list_of_port_identifiers
| <b>output [ task_port_type ]</b>
list_of_port_identifiers
tf_inout_declaration ::=
<b>inout [ reg ] [ signed ]</b> [ range ]
list_of_port_identifiers
| <b>inout [ task_port_type ]</b>
list_of_port_identifiers
task_port_type ::=
<b>time | real | realtime | integer</b>
</font>
block_item_declaration ::= (From Annex A - A.2.8)
{ 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 ::=
<b>reg [ signed ]</b> [ 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 }
</tt>
</pre>
</table>
<center>
Syntax 10-1 Syntax for task declaration
</center>
<p>
There are two alternate task declaration syntaxes. </p>
<p>The first syntax shall begin with the keyword task, followed by the
optional keyword automatic, followed by a name for the task and a
semicolon, and ending with the keyword endtask. The keyword automatic
declares an automatic task that is reentrant with all the task
declarations allocated dynamically for each concurrent task
entry. Task item declarations can specify the following: </p>
<ul>
<li>Input arguments</li>
<li>Output arguments</li>
<li>Inout arguments</li>
<li>All data types that can be declared in a procedural block</li>
</ul>
<p>The second syntax shall begin with the keyword task, followed by a
name for the task and a parenthesis enclosed task_port_list. The
task_port_list shall consist of zero or more comma separated
task_port_items. There shall be a semicolon after the close
parenthesis. The task body shall follow and then the keyword
endtask. <font color="red">In both syntaxes, the port declarations
have the syntax as defined by the tf_input_declaration,
tf_output_declaration and tf_inout_declaration, as detailed in the
syntax box above.</font>
</p>
<p>Tasks without the optional keyword automatic are static tasks, with
all declared items being statically allocated. These items shall be
shared across all uses of the task executing concurrently. Task with
the optional keyword automatic are automatic tasks. All items declared
inside automatic tasks are allocated dynamically for each
invocation. Automatic task items can not be accessed by hierarchical
references. Automatic tasks can be invoked through use of their
hierarchical name.</p>
</td></tr></table>
Change Section 10.3 to read:
<table><tr><td bgcolor="white">
<h1>10.3 Functions and function calling </h1>
<p>The purpose of a function is to return a value that is to be used
in an expression. The rest of this clause explains how to define and
use functions.</p>
<h1>10.3.1 Function declarations</h1>
<p>The syntax for defining a function is given in Syntax 10-3.</p>
<table border="1">
<tr>
<td>
<tt>
<pre>
function_declaration ::= <i>(From Annex A - A.2.6)</i>
<b>function [ automatic ] [ signed ]</b> [ range_or_type ]
function_identifier ;
function_item_declaration { function_item_declaration }
function_statement
<b>endfunction</b>
| <b>function [ automatic ] [ signed ] </b>[ range_or_type ]
function_identifier ( function_port_list ) ;
block_item_declaration { block_item_declaration }
function_statement
<b>endfunction</b>
function_item_declaration ::=
block_item_declaration
| <font color="red">tf_</font>input_declaration ;
function_port_list ::=
{ attribute_instance } <font color="red">tf_</font>input_declaration
{ , { attribute_instance } <font color="red">tf_</font>input_declaration }
<font color="red">
tf_input_declaration ::=
<b>input [reg] [signed] </b>
[ range ] list_of_port_identifiers
| <b>input</b> [task_port_type] list_of_port_identifiers
</font>
range_or_type ::=
range | <b>integer</b> | <b>real</b> | <b>realtime</b> | <b>time</b>
block_item_declaration ::= <i>(From Annex A - A.2.8)</i>
{ 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 ::=
<b>reg [ signed ]</b> [ 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 }
</td>
</tr>
</table>
<center>
Syntax 10-3 Syntax for function declaration
</center>
<p>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
semi-colon, 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.</p>
<p>The keyword automatic declares a recursive function with all the
function declarations allocated dynamically for each recursive
call. Automatic function items can not be accessed by hierarchical
references. Automatic functions can be invoked through the use of
their hierarchical name.</p>
<p>Function inputs shall be declared one of two ways. The first method
shall have the name of the function followed by a semicolon. After the
semicolon one or more input declarations optionally mixed with block
item declarations shall follow. After the function item declarations
there shall be a behavioral statement and then the endfunction
keyword.</p>
<p>The second method shall have the name of the function, followed by an
open parenthesis, and one or more input declarations, separated by
commas. After all the input declarations, there shall be a close
parenthesis, and a semicolon. After the semicolon, there shall be zero
or more block item declarations, followed by a behavioral statement,
and then the endfunction keyword.</p>
</table>
</body>
</html>
</x-html>
-mac
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:15 PDT
and
sponsored by Boyd Technology, Inc.