Updated Port proposal, which includes UDP's

From: Michael McNamara (mac@surefirev.com)
Date: Mon Apr 19 1999 - 09:51:54 PDT

Next message: Anders Nordstrom: "BTF Conference Calls"
Previous message: Anders Nordstrom: "REMINDER: BTF Conference Call on Monday"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Here is an updated proposal, which includes UDP's:

<x-html><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
 <head>
 <title>ANSI Port Declarations</title>
 </head>

<body bgcolor="ffffff">
 <h1>ANSI Port Declarations</h1>
 
 This proposal adds an alternate method for declaring module,
 user defined primitives (UDP's), task and function ports to the
 Verilog Hardware Description Language.
 
 <hr width="10%" align=center>
 <h2> Port Declarations </h2>
 <hr>
 
 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
 input, output or inout. Optionally the port
 may again be declared as a wire (the default) or as a
 reg.
 
<table border=1>
<td>
<table>
<tr>
<td valign="top">module_declaration </td><td>::= module_keyword module_identifier [ list_of_ports ] ;	{ module_item } endmodule </td>
</tr>
<tr>
<td valign="top">module_keyword</td><td>::= module | macromodule</td>
</tr>
<tr>
<td valign="top">list_of_ports</td><td>::= ( port { , port } )</td>
</tr>
<tr>
<td valign="top">port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| . port_identifier ( [ port_expression ] ) </td>
<tr>
<td valign="top">port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| { port_reference { , port_reference } }</td>
</tr>
<tr>
<td valign="top">port_reference</td><td>::= port_identifier </td>
</tr>
<tr>
<td></td><td>| port_identifier [ constant_expression ]</td></tr>
<tr>
<td></td><td>| port_identifier [ msb_constant_expression : lsb_constant_expression ]</td></tr>
</table>
</td>
</table>
 And then as a module item we have:
<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>...</td></tr>

<tr><td valign="top">input_declaration </td><td>::= input [ range ] list_of_port_identifiers ;</td></tr>
<tr><td valign="top">output_declaration </td><td>::= output [ range ] list_of_port_identifiers ; </td></tr>
<tr><td valign="top">inout_declaration </td><td>::= inout [ range ] list_of_port_identifiers ; </td></tr>

</table>
</td>
</table>
 Similarily for UDPs, we have:
<table border=1>
<td>
<table>
<tr><td>udp_declaration</td><td>::= primitive udp_identifier ( udp_port_list ) ;</td>
<tr><td></td><td>udp_port_declaration { udp_port_declaration }</td>
<tr><td></td><td>udp_body</td>
<tr><td></td><td>endprimitive</td>
<tr><td>udp_port_list</td><td>::= output_port_identifier , input_port_identifier { , input_port_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>
 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.

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.

<table border=1>
<td>
<table>
<tr>
<td valign="top">function_declaration</td><td>::= function [range_or_type] function_identifier ; function_item_declaration {function_item_declaration} statement endfunction</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>::= task task_identifier ; task_item_declaration {task_item_declaration} statement endtask</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>

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.

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.

 This proposal does the following, with the BNF below:
 <ol type="1">

<li> enhances the input_declaration,
 output_declaration, and inout_declaration to
 allow specification of net or reg type and signedness.

<li> allows input_declarations,
 output_declarations and inout_declarations to be
 used as port_references.

<li> allows input_declarations and
output_declarations to be used in the udp_port_list.

<li> introduces a function_port_list and
 task_port_list that can be used as an alternative to
 the current function and task declaration syntax.

 <li> introduces a parameter_port_list 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 the semantic 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 use modules tasks and functions, where some are
 declared in the old syntax, and some in the new syntax.
 </ol>

<table border=1>
<td>
<table>
<tr>
<td valign="top">module_declaration </td><td>::= module_keyword module_identifier [ parameter_port_list ] [ list_of_ports ] ;	{ module_item } endmodule </td>
</tr>
<tr>
<td valign="top">module_keyword</td><td>::= module | macromodule</td>
</tr>
<tr>
<td valign="top">parameter_port_list</td><td>::= # ( parameter_declaration { parameter_declaration } )</td>
</tr>
<tr>
<td valign="top">list_of_ports</td><td>::= ( port { , port } )</td>
</tr>
<tr>
<td valign="top">port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| . port_identifier ( [ port_expression ] ) </td>
<tr>
<td valign="top">port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| { port_reference { , port_reference } }</td>
</tr>
<tr>
<td valign="top">port_reference</td><td>::= port_identifier </td>
</tr>
<tr>
<td></td><td>| port_identifier [ constant_expression ]</td></tr>
<tr>
<td></td><td>| port_identifier [ msb_constant_expression : lsb_constant_expression ]</td></tr>
<tr>
<td></td><td>| port_identifier [ constant_expression ]</td></tr>
<td></td><td>| input_declaration</td></tr>
<td></td><td>| output_declaration</td></tr>
<td></td><td>| inout_declaration</td></tr>

<tr><td>udp_declaration</td><td>::= primitive udp_identifier ( udp_port_list ) ;</td>
<tr><td></td><td>udp_port_declaration { udp_port_declaration }</td>
<tr><td></td><td>udp_body</td>
<tr><td></td><td>endprimitive</td>
<tr><td>udp_port_list</td><td>::= output_port_identifier , input_port_identifier { , input_port_identifier }</td>
<tr><td></td><td>| output_declaration , input_declaration { , input_declaration }</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 valign="top">input_declaration </td><td>::= input [ signed ] [ net_type ] [ range ] list_of_port_identifiers</td></tr>
<tr><td valign="top">output_declaration </td><td>::= output [ signed ] [ net_type ] [ range ] list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= output [ signed ] [ reg_type ] [ range ] list_of_port_identifiers</td></tr>
<tr><td valign="top"></td><td>::= output [ signed ] [ reg_type ] [ range ] list_of_reg_decl_assignments</td></tr>
<tr><td valign="top">inout_declaration </td><td>::= inout [ signed ] [ net_type ] [ range ] list_of_port_identifiers</td></tr>
<tr>
<tr>
<tr>
<td valign="top">function_declaration</td><td>::= function [range_or_type] function_identifier ; function_item_declaration {function_item_declaration} statement endfunction</td>
</tr>
<tr><td valign="top"></td><td> | function [range_or_type] function_identifier ( function_port_list ) ; block_item_declaration {block_item_declaration} statement endfunction</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">function_port_list</td><td>::= input_declaration { input_declaration } </td></tr>
<tr>
<td valign="top">task_declaration</td><td>::= task task_identifier ; task_item_declaration {task_item_declaration} statement endtask</td>
</tr>
<tr>
<td valign="top"></td><td> | task task_identifier ( task_port_list ) ; block_item_declaration {block_item_declaration} statement endtask</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>

<tr><td valign="top">task_port_list</td><td>::= task_port_item { task_port_item } </td></tr>
<tr><td valign="top">task_port_item</td><td>::= input_declaration</td></tr>
<tr><td></td><td>| output_declaration</td></tr>
<tr><td></td><td>| inout_declaration</td></tr>

</table>
</td>
</table>
 Note that a separate proposal is adding the keyword signed
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
Given this syntax, the following two module declarations are
equivalent: <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>
 and
<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>

Things to note:
 <ol>
 <li> The second module declaration is much more compact.(38
 words instead of 70). Also note that this is a small
 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>   Last modified: Fri Jan 8 18:16:27 PST
 1999 
 </body>
</html>
</x-html>
And for the html challenged:

ANSI Port Declarations

This proposal adds an alternate method for declaring module, user defined
primitives (UDP's), task and function ports to the Verilog Hardware
Description Language.

Port Declarations

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 input, output or inout. Optionally the port may again be
declared as a wire (the default) or as a reg.

module_declaration ::= module_keyword module_identifier [ list_of_ports
                     ] ; { module_item } endmodule
module_keyword ::= module | macromodule
list_of_ports ::= ( port { , port } )
port ::= [ port_expression ]
                     | . port_identifier ( [ port_expression ] )
port_expression ::= port_reference
                     | { port_reference { , port_reference } }
port_reference ::= port_identifier
                     | port_identifier [ constant_expression ]
                     | port_identifier [ msb_constant_expression :
                     lsb_constant_expression ]

And then as a module item we have:

module_item ::= module_item_declaration

module_item_declaration ::= parameter_declaration
                         | input_declaration
                         | output_declaration
                         | inout_declaration
                         | net_declaration
                         | reg_declaration
                         ...
input_declaration ::= input [ range ] list_of_port_identifiers ;
output_declaration ::= output [ range ] list_of_port_identifiers ;
inout_declaration ::= inout [ range ] list_of_port_identifiers ;

Similarily for UDPs, we have:

udp_declaration ::= primitive udp_identifier ( udp_port_list ) ;
                      udp_port_declaration { udp_port_declaration }
                      udp_body
                      endprimitive

udp_port_list ::= output_port_identifier , input_port_identifier {
                      , input_port_identifier }
udp_port_declaration ::= output_declaration
                      | input_declaration
                      | reg_declaration

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.

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.

function_declaration ::= function [range_or_type]
                           function_identifier ;
                           function_item_declaration
                           {function_item_declaration}
                           statement
                           endfunction

function_item_declaration ::= block_item_declaration
                           | input_declaration
task_declaration ::= task task_identifier ;
                           task_item_declaration {task_item_declaration}
                           statement
                           endtask

task_item_declaration ::= block_item_declaration
                           | input_declaration
                           | output_declaration
                           | inout_declaration

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.

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.

This proposal does the following, with the BNF below:

  1. enhances the input_declaration, output_declaration, and
     inout_declaration to allow specification of net or reg type and
     signedness.
  2. allows input_declarations, output_declarations and inout_declarations
     to be used as port_references.
  3. allows input_declarations and output_declarations to be used in the
     udp_port_list.
  4. introduces a function_port_list and task_port_list that can be used as
     an alternative to the current function and task declaration syntax.
  5. introduces a parameter_port_list 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.
  6. 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.
  7. 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.
  8. introduces the semantic 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 use modules tasks and
     functions, where some are declared in the old syntax, and some in the
     new syntax.

module_declaration ::= module_keyword module_identifier [
                           parameter_port_list ] [ list_of_ports ] ; {
                           module_item } endmodule
module_keyword ::= module | macromodule
parameter_port_list ::= # ( parameter_declaration {
                           parameter_declaration } )
list_of_ports ::= ( port { , port } )
port ::= [ port_expression ]
                           | . port_identifier ( [ port_expression ] )
port_expression ::= port_reference
                           | { port_reference { , port_reference } }
port_reference ::= port_identifier
                           | port_identifier [ constant_expression ]
                           | port_identifier [ msb_constant_expression :
                           lsb_constant_expression ]
                           | port_identifier [ constant_expression ]
                           | input_declaration
                           | output_declaration
                           | inout_declaration
                           ...

udp_declaration ::= primitive udp_identifier ( udp_port_list )
                           ;
                           udp_port_declaration { udp_port_declaration }
                           udp_body
                           endprimitive
                           ::= output_port_identifier ,
udp_port_list input_port_identifier { , input_port_identifier
                           }
                           | output_declaration , input_declaration { ,
                           input_declaration }
udp_port_declaration ::= output_declaration
                           | input_declaration
                           | reg_declaration
                           ...
input_declaration ::= input [ signed ] [ net_type ] [ range ]
                           list_of_port_identifiers
output_declaration ::= output [ signed ] [ net_type ] [ range ]
                           list_of_port_identifiers
                           ::= output [ signed ] [ reg_type ] [ range ]
                           list_of_port_identifiers
                           ::= output [ signed ] [ reg_type ] [ range ]
                           list_of_reg_decl_assignments
inout_declaration ::= inout [ signed ] [ net_type ] [ range ]
                           list_of_port_identifiers

function_declaration ::= function [range_or_type]
                           function_identifier ;
                           function_item_declaration
                           {function_item_declaration}
                           statement
                           endfunction
                           | function [range_or_type] function_identifier
                           ( function_port_list ) ;
                           block_item_declaration {block_item_declaration}

statement
endfunction

function_item_declaration ::= block_item_declaration
                           | input_declaration
function_port_list ::= input_declaration { input_declaration }
task_declaration ::= task task_identifier ;
                           task_item_declaration {task_item_declaration}
                           statement
                           endtask
                           | task task_identifier ( task_port_list ) ;
                           block_item_declaration {block_item_declaration}
                           statement
                           endtask

task_item_declaration ::= block_item_declaration
                           | input_declaration
                           | output_declaration
                           | inout_declaration
task_port_list ::= task_port_item { task_port_item }
task_port_item ::= input_declaration
                           | output_declaration
                           | inout_declaration

Note that a separate proposal is adding the keyword signed 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

Given this syntax, the following two module declarations are equivalent:

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;

and

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;

Things to note:

  1. The second module declaration is much more compact.(38 words instead of
     70). Also note that this is a small example; many datapath modules
     contain as many as a thousand ports, each which may need to be declared
     three times.
  2. 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.
  3. With the second module declaration local variables are clearly distinct
     from port variables.
  4. 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.
  5. 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.
  6. 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.
  7. 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:
      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

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

Michael McNamara
Last modified: Fri Jan 8 18:16:27 PST 1999

Next message: Anders Nordstrom: "BTF Conference Calls"
Previous message: Anders Nordstrom: "REMINDER: BTF Conference Call on Monday"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:53:26 PDT and
sponsored by Boyd Technology, Inc.