From: Michael McNamara (mac@surefirev.com)
Date: Mon Sep 27 1999 - 18:29:50 PDT
Clifford E. Cummings writes:
> Thanks to Stephen Boyd for passing me the May VSG minutes on the ANSI ports.
>
> In looking over the minutes, we have compiled a great set of rules to
> describe ANSI ports but we did not complete the LRM wording proposal. I
> have talked to Joe Daniels over at Seva and he has agreed to put the BNF
> (which includes the ANSI port BNF) into Annex A but we will need to put
> together the wording and pass it for Draft #4.
>
> Ted Elkind mentioned that he has some ATF BNF, but I can't find it and
> unless it is passed to Joe to go into Draft #3, I will help modify the BNF
> for Draft #4.
>
> As a reminder, I would greatly appreciate it if all e-mail regarding
> problems with the BNF include the subject line: BNF ERRATA to help me sort
> and filter the errata into one place so that I don't miss any of your
> comments.
>
> Thanks to you all for the help.
>
> Regards - Cliff Cummings
I'm not done, but thought I'd send out what I've typed in so far for
BTF 09:
<x-html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>B09</title>
</head>
<body>
<h1>Here is the suggested implementation of BTF proposal 9</h1>
<p> The text of the proposal, as approved is <a href="#proposal">
included</a>
<p>
The first bit of Section 12.3.1 should be replaced with:
<table width="100%" bgcolor="ffffff">
<td>
<b>12.3.1 Port definition</b> <br>
<p>
The syntax for a port is given in Syntax 12-5:
<p>
<table border=1 >
<td>
<table>
<tr>
<td valign="top">list_of_ports</td><td>::= <B>(</B> port { <B>,</B> port } <B>)</b></td>
</tr>
<td valign="top"></td><td><font color="red">| <B>(</B> port_definition { <B>,</B> port_definition } <B>)</b></font></td>
</tr>
<tr>
<td valign="top">port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| <B>.</B> <I>port</I>_identifier <B>(</B> [ port_expression ] <B>) </td>
<p><tr>
<td valign="top">port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| <B>{</B> port_reference { <B>,</B> port_reference } <B>}</B></td>
</tr>
<tr>
<td valign="top">port_reference</td><td>::= <I>port</I>_identifier </td>
</tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> <I>msb</I>_constant_expression <B>:</B> <I>lsb</I>_constant_expression <B>]</b></td></tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> constant_expression <B>]</B></td></tr>
<td valign="top"><font color="red">port_definition</td><td><font color="red">::= input_declaration</font></td></tr>
<td></td><td><font color="red">| output_declaration</font></td></tr>
<td></td><td><font color="red">| inout_declaration</font></td></tr>
</table>
</table>
<p>
Modules can be declared either using a list of <b>port</b>s, or as a
list of <b>port_definition</b>s. A list of <b>port</b>s can be made
up of any combination of <b>port_expression</b>s, and
<b>port_reference</b>s. A list of <b>port_definition</b>s can only
include 1 or more <b>port_definition</b>s.
</p>
<p>
<b> 12.3.2 Lists of Ports</b><br>
<p>The port experssion in the list of ports can be one of the following:</p>
<ul type="-">
<li> A simple identifier
<li> A bit select of a vector declared withing the module
<li> A part select of a vector declared within the module
<li> A concatenation of any combination of the above
</ul>
</table>
<p>
Then copy verbatim the last two paragraphs of 12.3.1.
<p>
Rename the current 12.3.2 to 12.3.2.1.
<p>
Replace Syntax 12-6, and the immediatly following paragraph with:
<table width="100%" bgcolor="ffffff">
<td>
<table border=1>
<td>
<table>
<tr><td valign="top">input_declaration </td><td>::= <B>input</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">output_declaration </td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ reg_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">inout_declaration </td><td>::= <B>inout</B> <font color="red">[ <B>signed </B>] [ net_type ] </font><B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">list_of_port_identifiers</td><td>::=<i>port</i>_identifier {, <i>port</i>_identifer }</tr>
<tr>
<tr>
</table>
</table>
<p>
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 must be defined in such a port declaration,
including the signed and range attributes if needed.
<p>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 declaration includes a range, then the corrosponding port
declaration shall also contain an identical range declaration.
</table>
<p>
Then insert just before the current 12.3.3:
<table width="100%" bgcolor="ffffff">
<td>
<b> 12.3.3 Lists of Ports_Definitions</b><br>
<p>
An alternate syntax that minimizes the duplication of data can be used
to specify the ports of a module. Modules must either be declared
entirely with the list of ports syntax as described in Section
12.3.1.1 above, or entirely using the list of port_declaraations as
described in this section.
<p>
<table border=1>
<td>
<table>
<tr>
<td valign="top">list_of_ports</td><td>::= <B>(</B> port { <B>,</B> port } <B>)</b></td>
</tr>
<td valign="top"></td><td><font color="red">| <B>(</B> port_definition { <B>,</B> port_definition } <B>)</b></font></td>
</tr>
<td valign="top"><font color="red">port_definition</td><td><font color="red">::= input_declaration</font></td></tr>
<td></td><td><font color="red">| output_declaration</font></td></tr>
<td></td><td><font color="red">| inout_declaration</font></td></tr>
<tr><td valign="top">input_declaration </td><td>::= <B>input</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">output_declaration </td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ reg_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">inout_declaration </td><td>::= <B>inout</B> <font color="red">[ <B>signed </B>] [ net_type ] </font><B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr>
<tr>
<tr>
</table>
</table>
<p>
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.
<p>
Note that the port_reference type of port declaration can not be done
using list of port definition module declarations. Also ports so
defined can only be simple identifers. They can not be bit-selects,
part-selects or concatenations.
<p></table>
<h2>New Task and Function syntax</h2>
Section 10.2.1 should be changed to:
<table width="100%" bgcolor="ffffff">
<td>
<b>10.2.1 Defining a task</b>
<p>
The syntax for defining a task is given in Syntax 10-1.
<p>
<table border="1">
<td>
<table>
<td valign="top">task_declaration</td><td>::= <b>task</b> <i>task</i>_identifier ;<br>task_item_declaration {task_item_declaration}<br> statement<br> <b>endtask</b></td>
</tr>
<tr>
<td valign="top"></td><td><font color="red"> | <b>task</b> <i>task</i>_identifier ( task_port_list ) ;<br>block_item_declaration {block_item_declaration}<br> statement<br> <b>endtask</b></font></td>
</tr>
<tr>
<tr><td valign="top">task_item_declaration</td><td>::= block_item_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<tr><td></td><td>| output_declaration</td></tr>
<tr><td></td><td>| inout_declaration</td></tr>
<font color="red">
<tr><td valign="top"><font color="red">task_port_list</td><td><font color="red">::= task_port_item {, task_port_item } </td></tr>
<tr><td valign="top"><font color="red">task_port_item</td><td><font color="red">::= input_declaration</td></tr>
<tr><td></td><td><font color="red">| output_declaration</td></tr>
<tr><td></td><td><font color="red">| inout_declaration</td></tr>
</font>
</table>
</td>
</table>
<p>
There are two alternate task declaration syntaxes.
<p>The first syntax shall begin with the keyword <b>task</b>, followed
by a name for the task and a semicolon, and ending with the keyword
<b>endtask</b>. Task item declarations can specify the following:
<ul>
<li> Input arguments
<li> Output arguments
<li> Inout arguments
<li> All data types that can be declared in a procedural block
</ul>
<p>The second syntax shall begin with the keyword <b>task</b>,
followed by a name for the task and a parenthesis enclosed
<b>task_port_list</b>. The <b>task_port_list</b> shall consist of
zero or more comma separated <b>task_port_items</b>. There shall be a
semicolon after the close parenthesis. The task body shall follow,
and then the keyword <b>endtask</b>.
<p>In both syntaxes, the declarations have the same syntax as the
coorosponding declarations in a module definition (see section 12.3.2
and section 3.2.2). The task declaration shall not declare a net data
type. The body of the task shall contain zero or more behavioral
statemets (see Section 9).
</td>
</table>
<p> Further, replace Example 1 in Section 10.2.2 with:
<table width="100%" bgcolor="ffffff">
<td>
<pre>
<b>task</b> my_task;
<b>input</b> a,b;
<b>inout</b> c;
<b>output</b> d,e;
<b>begin</b>
... // statements that perform the work of the task
...
c = foo1; // the assignments that initialize result registers
d = foo2;
e = foo3;
<b>end</b>
<b>endtask</b>
</pre>
<p> Or using the second form of a task declaration, the task could be defined as:
<pre>
<b>task</b> my_task (<b>input</b> a, b, <b>inout</b> c, <b>output</b> d, e) ;
<b>begin</b>
... // statements that perform the work of the task
...
c = foo1; // the assignments that initialize result registers
d = foo2;
e = foo3;
<b>end</b>
<b>endtask</b>
</pre>
</table>
<p>
Then continue on with "The following statement enables the task:"...
<p>Section 10
<p><p><a name="proposal"></a>
<h1>Here is the text of the ANSI Port Declarations proposal</h1>
<p>
This proposal adds an alternate method for declaring module,
user defined primitives (UDP's), task and function ports to the
Verilog Hardware Description Language.</p>
<h3><u>ChangeLog</u></h3>
<ul>
<li><b>B36?</b> : Modified to allow UDP declaration using the new syntax 4/15/98</li>
<li><b>B37</b> : Modified to exclude connection by name in new style module port declaration 4/15/99</li>
</ul>
<p>
<hr width="10%" align=center>
<h2> Port Declarations </h2>
<hr>
<p>
At present, the Verilog language requires that the ports of a
module (and of a UDP) be listed, by name, in parenthetical list
just after the module name. Further, it is required that each
port be again declared somewhere in the module as one of an
<b>input</b>, <b>output</b> or <b>inout</b>. Optionally the port
may again be declared as a <b>wire</b> (the default) or as a
<b>reg</b>.
</p>
<table border=1>
<td>
<table>
<tr>
<td valign="top">module_declaration </td><td>::= module_keyword <I>module</I>_identifier [ list_of_ports ] <B>;</B>	{ module_item } <B>endmodule</b> </td>
</tr>
<tr>
<td valign="top">module_keyword</td><td>::= <B>module</B> | <B>macromodule</b></td>
</tr>
<tr>
<td valign="top">list_of_ports</td><td>::= <B>(</B> port { <B>,</B> port } <B>)</b></td>
</tr>
<tr>
<td valign="top">port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| <B>.</B> <I>port</I>_identifier <B>(</B> [ port_expression ] <B>) </td>
<tr>
<td valign="top">port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| <B>{</B> port_reference { <B>,</B> port_reference } <B>}</B></td>
</tr>
<tr>
<td valign="top">port_reference</td><td>::= <I>port</I>_identifier </td>
</tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> constant_expression <B>]</B></td></tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> <I>msb</I>_constant_expression <B>:</B> <I>lsb</I>_constant_expression <B>]</td></tr>
</table>
</td>
</table>
<p>And then as a module item we have:</p>
<table border=1>
<td>
<table>
<tr>
<td>module_item</td><td>::= module_item_declaration</td>
</tr>
<tr>
<tr><td valign="top">module_item_declaration</td><td>::= parameter_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<tr><td></td><td>| output_declaration</td></tr>
<tr><td></td><td>| inout_declaration</td></tr>
<tr><td></td><td>| net_declaration</td></tr>
<tr><td></td><td>| reg_declaration</td></tr>
<tr><td></td><td><b>...</b></td></tr>
<tr><td valign="top">input_declaration </td><td>::= <B>input</B> <B>[</B> range <B>]</B> list_of_port_identifiers <B>;</b></td></tr>
<tr><td valign="top"><P>output_declaration </td><td>::= <B>output</B> <B>[</B> range <B>]</B> list_of_port_identifiers <B>;</b> </td></tr>
<tr><td valign="top"><P>inout_declaration </td><td>::= <B>inout</B> <B>[</B> range <B>]</B> list_of_port_identifiers <B>;</b> </td></tr>
</table>
</td>
</table>
<p> Similarily for UDPs, we have:
<table border=1>
<td>
<table>
<tr><td>udp_declaration</td><td>::= <B>primitive</B> <I>udp</I>_identifier <B>(</B> udp_port_list <B>)</B> <B>;</b></td>
<tr><td></td><td>udp_port_declaration { udp_port_declaration }</td>
<tr><td></td><td>udp_body</td>
<tr><td></td><td><B>endprimitive</b></td>
<tr><td>udp_port_list</td><td>::= <I>output_port</I>_identifier <B>,</B> <I>input_port</I>_identifier { <B>,</B> <I>input_port</I>_identifier }</td>
<tr><td>udp_port_declaration</td><td>::= output_declaration</td>
<tr><td></td><td>| input_declaration</td>
<tr><td></td><td>| reg_declaration</td>
</table>
</td>
</table>
<p> Of course these are very similar to the original C Programming
Language, (affectionately known as K&R C), which was enhanced by
simpler port declarations in ANSI C.
</p>
<p> Further, at present declarations of tasks and functions do not
support a parenthetical list of ports. Instead the inputs, locals,
and in the case of tasks, outputs and inouts of the tasks must be
listed after the task or function name declaration.</p>
<table border=1>
<td>
<table>
<tr>
<td valign="top">function_declaration</td><td>::= <b>function</b> [range_or_type] <i>function</i>_identifier ; <br>function_item_declaration {function_item_declaration} <br>statement<br> <b>endfunction</b></td>
</tr>
<tr>
<tr><td valign="top">function_item_declaration</td><td>::= block_item_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<td valign="top">task_declaration</td><td>::= <b>task</b> <i>task</i>_identifier ;<br>task_item_declaration {task_item_declaration}<br> statement<br> <b>endtask</b></td>
</tr>
<tr>
<tr><td valign="top">task_item_declaration</td><td>::= block_item_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<tr><td></td><td>| output_declaration</td></tr>
<tr><td></td><td>| inout_declaration</td></tr>
</table>
</table>
<p> After some discussion in the Verilog-1364 Behavioral Task
Force, and later in the entire Verilog-1364 working group,
consensus emerged supporting an extension to the Verilog language
closely following that of ANSI C's enhancement to K&R C, as
follows.</p>
<p> For module, UDP, task and function declarations, users can
either continue to use the existing syntax, or they can use the
new parenthetical port declaration syntax.</p>
<p> This proposal does the following, with the BNF below:
<ol type="1">
<li> enhances the <b>input_declaration</b>,
<b>output_declaration</b>, and <b>inout_declaration</b> to
allow specification of net or reg type and signedness.
<li> introduces a <b>port_definiton</b> which can be used to
build a <b>list_of_ports</b>.
<li> allows <b>input_declaration</b>s,
<b>output_declaration</b>s and <b>inout_declaration</b>s to be
used as <b>port_definition</b>s.
<li> allows <b>input_declaration</b>s and
<b>output_declaration</b>s to be used in the udp_port_list.
<li> introduces a <b>function_port_list</b> and
<b>task_port_list</b> that can be used as an alternative to
the current function and task declaration syntax.
<li> introduces a <b>parameter_port_list</b> that can be used
to define parameters and local parameters of modules, tasks
and functions, especially where the parameters are used to
size the width of input, output and inout ports.
<li> introduces the semantic restriction that only those
parameters in the #(..) list may be overridden. This means
that a new style module, task or function declaration that
includes no #(..) list, no parameters may be overridden.
<li> introduces the semantic clarification that parameter
overrides by position shall skip over any local parameters
declarations in the paramter port list when calculating which
override applies to which parameter declaration.
<li> introduces in the BNF a restriction that a particular
module, task or function declaration must either use the
existing 1364-1995 port declaration syntax, or the new syntax;
but may not mix both styles in the same declaration. A given
design may mix modules, tasks and functions, where some are
declared in the old syntax, and some in the new syntax.
<li> introduces in the BNF a restriction that the connection
by name style of port definition can only be used with the
1364-1995 declaration syntax. Note that this restriction has
no effect on the instantiation of a module, only on its
declaration.
</ol>
<table border=1>
<td>
<table>
<tr>
<td valign="top">module_declaration </td><td>::= module_keyword <I>module</I>_identifier <font color="red"> [ parameter_port_list ] </font> [ list_of_ports ] <B>;</B>	{ module_item } <B>endmodule</b> </td>
</tr>
<tr>
<td valign="top">module_keyword</td><td>::= <B>module</B> | <B>macromodule</b></td>
</tr>
<tr>
<td valign="top"><font color="red">parameter_port_list</font></td><td><font color="red">::= <B># (</B> parameter_declaration { parameter_declaration } <B>)</b></font></td>
</tr>
<tr>
<td valign="top">list_of_ports</td><td>::= <B>(</B> port { <B>,</B> port } <B>)</b></td>
</tr>
<td valign="top"></td><td><font color="red">| <B>(</B> port_definition { <B>,</B> port_definition } <B>)</b></font></td>
</tr>
<tr>
<td valign="top">port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| <B>.</B> <I>port</I>_identifier <B>(</B> [ port_expression ] <B>) </td>
<tr>
<td valign="top">port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| <B>{</B> port_reference { <B>,</B> port_reference } <B>}</B></td>
</tr>
<tr>
<td valign="top">port_reference</td><td>::= <I>port</I>_identifier </td>
</tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> constant_expression <B>]</B></td></tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> <I>msb</I>_constant_expression <B>:</B> <I>lsb</I>_constant_expression <B>]</b></td></tr>
<tr>
<td></td><td>| <I>port</I>_identifier <B>[</B> constant_expression <B>]</B></td></tr>
<td valign="top"><font color="red">port_definition</td><td><font color="red">::= input_declaration</font></td></tr>
<td></td><td><font color="red">| output_declaration</font></td></tr>
<td></td><td><font color="red">| inout_declaration</font></td></tr>
<tr><td></td><td><b>...</b></td></tr>
<tr><td>udp_declaration</td><td>::= <B>primitive</B> <I>udp</I>_identifier <B>(</B> udp_port_list <B>)</B> <B>;</b></td>
<tr><td></td><td>udp_port_declaration { udp_port_declaration }</td>
<tr><td></td><td>udp_body</td>
<tr><td></td><td><B>endprimitive</b></td>
<tr><td>udp_port_list</td><td>::= <I>output_port</I>_identifier <B>,</B> <I>input_port</I>_identifier { <B>,</B> <I>input_port</I>_identifier }</td>
<tr><td></td><td><font color="red">| output_declaration <B>,</B> input_declaration { <B>,</B> input_declaration }</font></td>
<tr><td>udp_port_declaration</td><td>::= output_declaration</td>
<tr><td></td><td>| input_declaration</td>
<tr><td></td><td>| reg_declaration</td>
<tr><td></td><td><b>...</b></td></tr>
<tr><td valign="top">input_declaration </td><td>::= <B>input</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top">output_declaration </td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ net_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ reg_type ] </font> <B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= <B>output</B> <font color="red">[ <B>signed </B>] [ reg_type ] </font> <B>[</B> range <B>]</B> list_of_reg_decl_assignments</td></tr>
<tr><td valign="top">inout_declaration </td><td>::= <B>inout</B> <font color="red">[ <B>signed </B>] [ net_type ] </font><B>[</B> range <B>]</B> list_of_port_identifiers</td></tr>
<tr>
<tr>
<tr>
<td valign="top">function_declaration</td><td>::= <b>function</b> [range_or_type] <i>function</i>_identifier ; <br>function_item_declaration {function_item_declaration} <br>statement<br> <b>endfunction</b></td>
</tr>
<tr><td valign="top"></td><td><font color="red"> | <b>function</b> [range_or_type] <i>function</i>_identifier ( function_port_list ) ; <br>block_item_declaration {block_item_declaration} <br>statement<br> <b>endfunction</b></font></td>
</tr>
<tr>
<tr><td valign="top">function_item_declaration</td><td>::= block_item_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<tr><td valign="top"><font color="red">function_port_list</td><td><font color="red">::= input_declaration {, input_declaration } <br></td></tr>
<tr>
<td valign="top">task_declaration</td><td>::= <b>task</b> <i>task</i>_identifier ;<br>task_item_declaration {task_item_declaration}<br> statement<br> <b>endtask</b></td>
</tr>
<tr>
<td valign="top"></td><td><font color="red"> | <b>task</b> <i>task</i>_identifier ( task_port_list ) ;<br>block_item_declaration {block_item_declaration}<br> statement<br> <b>endtask</b></font></td>
</tr>
<tr>
<tr><td valign="top">task_item_declaration</td><td>::= block_item_declaration</td></tr>
<tr><td></td><td>| input_declaration</td></tr>
<tr><td></td><td>| output_declaration</td></tr>
<tr><td></td><td>| inout_declaration</td></tr>
<font color="red">
<tr><td valign="top"><font color="red">task_port_list</td><td><font color="red">::= task_port_item {, task_port_item } </td></tr>
<tr><td valign="top"><font color="red">task_port_item</td><td><font color="red">::= input_declaration</td></tr>
<tr><td></td><td><font color="red">| output_declaration</td></tr>
<tr><td></td><td><font color="red">| inout_declaration</td></tr>
</font>
</table>
</td>
</table>
<p> Note that a separate proposal is adding the keyword <b>signed</b>
to the language; and the optional keyword signed is merely included
here to show that should signed constructs be introduced, it would be
legal to include the declaration in the port_reference production</p>
<p>Given this syntax, the following two module declarations are
equivalent:<p> <table border=1><td>
<xmp>
module acc_fsm( CLK, RST, IT_IL_RQ, IT_RQ_VLD, RdMsg,
WrMsg, AccessOK, XX_IL_PIODONE, OM_IL_GT,
RespVld, IL_IT_GT, CaptureAddress, CaptureData,
IL_XX_PIORD, IL_XX_PIOWR, IL_OM_RQ,
SelectResp, SetRespVld, ClrRespVld);
parameter DATAWIDTH=64;
input CLK, RST;
input IT_IL_RQ,
IT_RQ_VLD,
RdMsg,
WrMsg,
AccessOK,
XX_IL_PIODONE;
input OM_IL_GT,
RespVld;
output [31:0] CaptureAddress;
output [DATAWIDTH-1:0] CaptureData;
output IL_IT_GT,
IL_XX_PIORD,
IL_XX_PIOWR,
IL_OM_RQ,
SelectResp,
SetRespVld,
ClrRespVld;
reg [31:0] CaptureAddress;
reg [DATAWIDTH-1:0] CaptureData,
reg [2:0] LE_NxtState,
LE_State;
reg IL_IT_GT,
IL_XX_PIORD;
reg IL_XX_PIOWR,
IL_OM_RQ,
SelectResp,
SetRespVld,
ClrRespVld;
</xmp>
</td></table>
<p>and</p>
<table border=1><td>
<xmp>
module acc_fsm #( parameter DATAWIDTH=64)
( input wire CLK, RST, IT_IL_RQ, IT_RQ_VLD, RdMsg,
WrMsg, AccessOK, XX_IL_PIODONE,
OM_IL_GT, RespVld,
output reg [31:0] CaptureAddress,
output reg [DATAWIDTH-1:0] CaptureData,
output reg IL_IT_GT, IL_XX_PIORD, IL_XX_PIOWR,
IL_OM_RQ, SelectResp, SetRespVld, ClrRespVld
);
reg [ 2 : 0] LE_NxtState,
LE_State;
</xmp>
</td></table>
<p> Things to note:
<ol>
<li> The second module declaration is much more compact.(38
words instead of 70). Also note that this is a <b>small</b>
example; many datapath modules contain as many as a thousand
ports, each which may need to be declared three times.
<li> The second module declaration is much easier to reuse:
changing the width of the CaptureAddress bus to 48 bits requires
modifying one location, instead of two, which potentially are
many lines apart.
<li> With the second module declaration local variables are
clearly distinct from port variables.
<li> With the second module declaration global analysis can
examine just the port list in order to determine all necessary
information about the input output characteristics of a module.
<li> Declaring the modifiable parameter declarations in a
separate list, with the list enclosed in '#(' and )' looks just
like the module instance parameter override syntax. This also
encapsulates and focuses attention the interface nature of these
parameters.
<li> Overall, the new module declaration centers the information
that a user of this module must look at to successfully
interface to the module in one place, at the top of the module.
The details of the implementation are listed later. Hence Verilog
becomes more object oriented.
<li> There has been some suggestion that using constant
functions in module i/o declarations to define widths would
require that the definition of the constant function precede the
use; however private discussion has cleared this up. The value
of the parameters at the point of the 'call' to the constant
function are all that is needed to determine its value. An
exaple is useful:
<table border=1><td>
<xmp>
module acc_fsm #( parameter DATAWIDTH=8, TSIZE=cf_tsize(DATAWIDTH) )
( input wire CLK, RST,
output reg [TSIZE-1:0] CaptureDataOut,
input wire [TSIZE-1:0] CaptureDataIn
);
reg [2:0] LE_NxtState,
LE_State;
parameter B=DATAWIDTH*2;
function [31:0] cf_tsize(input [31:0] w);
cf_tsize = w**B;
endfunction
endmodule
</xmp>
</td></table>
The parameter B is not yet defined at the location that TSIZE is
assigned the value of the constant function cf_tsize, and hence this
usage is illegal. The fix would be to move the definition of the
parameter B into the parameter port list. (perhaps even as a
localparam).
</ol>
<hr>
<address><a href="mailto:mac@surefirev.com">Michael McNamara</a></address>
<!-- Created: Fri Sep 24 15:31:01 PDT 1999 -->
<!-- hhmts start -->
Last modified: Mon Sep 27 18:26:54 PDT 1999
<!-- hhmts end -->
</body>
</html>
</x-html>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:29 PDT
and
sponsored by Boyd Technology, Inc.