ANSI prototype proposal

From: Michael McNamara (mac@surefirev.com)
Date: Mon Jun 01 1998 - 11:23:20 PDT

Next message: Adam Krolnik: "Re: ANSI prototype proposal"
Previous message: Anders Nordstrom: "B07 Proposed wording"
Next in thread: Adam Krolnik: "Re: ANSI prototype proposal"
Reply: Adam Krolnik: "Re: ANSI prototype proposal"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Here is my re-worked ansi prototype proposal

<x-html><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
 <head>
 <title>ANSI Port Declarations, and Structures for Verilog</title>
 </head>

<body>
 <h1>ANSI Port Declarations, and Structures for Verilog</h1>
 
 This proposal adds an alternate method for declaring module
 ports, as well as introducing structures to the Verilog Hardware
 Description Language.
 
 <hr width="10%" align=center>
 <h2> Port Declaration </h2>
 <hr>
 
 At present, the Verilog language requires that the ports of a
 module 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>module_declaration </td><td>::= module_keyword module_identifier [ list_of_ports ] ;	{ module_item } endmodule </td>
</tr>
<tr>
<td>module_keyword</td><td>::= module | macromodule</td>
</tr>
<tr>
<td>list_of_ports</td><td>::= ( port { , port } )</td>
</tr>
<tr>
<td>port</td> <td>::= [ port_expression ]</td>
</tr>
<td></td> <td>| . port_identifier ( [ port_expression ] ) </td>
<tr>
<td>port_expression</td><td>::= port_reference </td>
</tr>
<tr>
<td></td><td>| { port_reference { , port_reference } }</td>
</tr>
<tr>
<td>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>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>input_declaration </td><td>::= input [ range ] list_of_port_identifiers ;</td></tr>
<tr><td>output_declaration </td><td>::= output [ range ] list_of_port_identifiers ; </td></tr>
<tr><td>inout_declaration </td><td>::= inout [ range ] list_of_port_identifiers ; </td></tr>

</table>
</td>
</table>
 Of course this is very similar to the original C Programming
 Language, (affectionately known as K&R C), which was enhanced by
 simpler port declarations in ANSI C.
 
 There is much attraction to the proposer in following the ANSI
 C enhancement directly, and pull the input and output declaration
 directly into the parenthesized port list. However, it has been
 pointed out that this causes problems with parameterized port
 widths, which require a definition of the parameter before the
 first use. The proposer has bowed to pressure to alter this
 proposal to simplify module port declaration by following the
 example of tasks and functions.

 Therefore this proposal does the following:
 <ol type="1">

 <li> Enhances the input_declaration, output_declaration, and
 inout declaration, by allowing in a single declaration the size,
 width, type and direction of each port.

<li>This proposal further allows the list_of_ports to be
 ommitted, and inferred by the order of the input_declaration,
 output_declaration and inout_declaration, as they occur in the
 module. This of course is familiar, as it is how port order is
 defined in the function and task declarations.

<li> The list_of_ports is not removed from the language, for a
 number of reasons: 1) backwards compatibility; 2) it is still
 useful for including port_expressions in the module for
 interface hiding.
 </ol>

Proposal 1) R E S O L V E D :
 <ol type="a">
 <li> The BNF for input_declaration, output_declaration and
 inout_declaration shall be changed to:

<table border=1>
 <td>
 <table>
 <tr><td>input_declaration </td><td>::= input[ signed ] [ net_type ] [ range ] list_of_port_identifiers </td></tr>
 <tr><td>output_declaration </td><td>::= output[ signed ] [ net_type ] [ range ] list_of_port_identifiers </td></tr>
 <tr><td>output_declaration </td><td>::= output[ signed ] [ reg_type ] [ range ] list_of_port_identifiers </td></tr>
 <tr><td>inout_declaration </td><td>::= inout [ signed ] [ net_type ] [ range ] list_of_port_identifiers </td></tr>
 <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
 </li>

<li> Section 21.1 Modules shall be changed by adding the
 underlined sentence:

 ... The optional list of ports shall specify an ordered
 list of the ports in the module. If a port list is not
 supplied, then the ports are ordered by the order of the port
 declarations in the module. The order can be signifigant
 when instatiating the module (See section 12.1.2). ...

<li> The wording in Section 12.3 Port Declarations, page
 142 shall be to reflect this change. (Yatin to implement). In
 truth there is another proposal which greatly cleans up this
 section, and hence I do not try to wordsmith in this area right
 now. However we need to direct that that wordsmithing handle the
 new semantics we propose for optional port_lists..</li>
 </ol>

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);
 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 [63:0] CaptureData;
 output IL_IT_GT,
 IL_XX_PIORD,
 IL_XX_PIOWR,
 IL_OM_RQ,
 SelectResp,
 SetRespVld,
 ClrRespVld;
 reg [31:0] CaptureAddress;
 reg [63: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 ;
 input wire CLK, RST;
 input wire IT_IL_RQ,
 IT_RQ_VLD,
 RdMsg,
 WrMsg,
 AccessOK,
 XX_IL_PIODONE;
 input wire OM_IL_GT,
 RespVld;
 output reg [31:0] CaptureAddress;
 output reg [63: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> The second module declaration is parametric port width
 friendly; one could define a parameter before any input or
 output port which used that parameter.

<li> The second module declaration is familiar; the task
 and function declarations currently include no port list,
 and take as the order of arguments the order that input and
 output declarations appear in the declaration.

 </ol>
 <hr>
 <hr width="10%" align=center>
 <h2> Structures </h2>
 <hr>
 Structures are very familiar to users of modern computer
 languages, yet Verilog does not support them. This proposal adds
 structures to the language, in manner consistent with Verilog's
 concept of the directionality of a data reference.

Verilog does have a notion of hierarchy, and the dot (.)
 is reserved in the language to refer to sub elements of an
 object. At present there is no use of the dot to reference sub
 elements of signals, and hence we propose using the dot to
 references to elements of a structure.
 <h3> Directions </h3>
 In the Verilog language, signals are connected between modules
 via ports. These ports can be input, output or
 inout connections. Input ports can only be read from; the
 module cannot drive a value to these ports. Output ports can be
 driven, yet when read from will only show the resolved values of
 the local drivers; essentially these drivers are isolated from any
 external drivers of the port. Inout ports can be driven, and when
 read will show the final resolved value of all the drivers of that
 object, whether internal or external to the module.

A group of signals that quite logically might be contained in a
 structure could quite conceivably have elements that are read-only
 (wire), write-only (output) and/or read-write (inout) -- at
 different times according to the module accessing the object. For
 example, consider a bus:
 <xmp>
 wire [31:0] address;
 wire [63:0] data;
 wire [15:0] req;
 wire [15:0] grt;
 wire buserr;
 </xmp>
 The bus arbiter module needs just read access to the req
 wires, and needs write access to the grt lines, and
 read-write access to the buserror line, and really no access
 to any other line.

A bus master needs write access to one of the req lines,
 read access to the matching grt line, and read-write access
 to the address, data and buserror lines.

A bus slave might need just read-write access to the
address, data and buserror lines.

A bus monitor would need read access to all the bus lines.

Therefore including direction in a structure declaration would
be less than useful.

<h3>Proposal</h3>
 The following syntax is proposed:
<table border=1>
<td>
<table>
<td>structure_declaration</td><td>::= struct struct_identifier begin struct_items end</td></tr>
<tr><td>struct_items</td><td>::= struct_item { struct_item }
<tr><td>struct_item</td><td>::= [ signed ] [ range ] list_of_struct_identifiers ; </td></tr>
</table>
</td>
</table>

The structure definition is global, at the same scope as the module
declaration, and hence it is an error to declare two structures with
the same name. Note: When global module declarations are fixed, we
would fix global structure declarations as well.

Structures are used in net and reg declarations as an alternate for
the range production, as follows:
<table border=1>
<td>
<table>
<tr><td>reg_declaration</td><td> ::= reg [ range ] list_of_register_identifiers ;</td></tr>
<tr><td>list_of_real_identifiers</td><td> ::= real_identifier { , real_identifier }</td></tr>
<tr><td>list_of_register_identifiers</td><td> ::= register_name { , register_name }</td></tr>
<tr><td>register_name</td><td> ::= register_identifier</td></tr>
<tr><td></td><td>| memory_identifier [ upper_limit_constant_expression : lower_limit_constant_expression ]</td></tr>
<tr><td>time_declaration</td><td> ::= time list_of_register_identifiers ;</td></tr>
<tr><td>integer_declaration</td><td> ::= integer list_of_register_identifiers ;</td></tr>
<tr><td>real_declaration</td><td> ::= real list_of_real_identifiers ;</td></tr>
<tr><td>realtime_declaration</td><td> ::= realtime list_of_real_identifiers ;</td></tr>
<tr><td>event_declaration</td><td> ::= event event_identifier { , event_identifier } ;</td></tr>
<tr><td>net_declaration</td><td> ::=net_type [ vectored | scalared ] [ signed | unsigned ] [ range ] [ delay3 ] list_of_net_identifiers ;</td></tr>
<tr><td></td><td>| trireg [ vectored | scalared ] [ signed | unsigned ] [ charge_strength ] [ range ] [ delay3 ] list_of_net_identifiers ;</td></tr>
<tr><td></td><td>| net_type [ vectored | scalared ] [ signed | unsigned ] [ drive_strength ] [ range ] [ delay3 ] list_of_net_decl_assignments</td></tr>
<tr><td>net_type</td><td> ::= wire | tri | tri1 | supply0 | wand | triand | tri0 | supply1 | wor | trior</td></tr>
<tr><td>drive_strength</td><td> ::= ( strength0 , strength1 )</td></tr>
<tr><td><td><td>| ( strength1 , strength0 )</td></tr>
<tr><td><td><td>| ( strength0 , highz1 )</td></tr>
<tr><td><td><td>| ( strength1 , highz0 )</td></tr>
<tr><td><td><td>| ( highz0 , strength1 )</td></tr>
<tr><td><td><td>| ( highz1, strength0 )</td></tr>
<tr><td>strength0</td><td> ::= supply0 | strong0 | pull0 | weak0</td></tr>
<tr><td>strength1</td><td> ::= supply1 | strong1 | pull1 | weak1</td></tr>
<tr><td>charge_strength</td><td> ::= ( small ) | ( medium ) | ( large )</td></tr>
<tr><td>delay3</td><td> ::= # delay_value | # (delay_value [ , delay_value [ , delay_value ] ] )</td></tr>
<tr><td>delay2</td><td> ::= # delay_value | # (delay_value [ , delay_value ] )</td></tr>
<tr><td>delay_value</td><td> ::= unsigned_number | parameter_identifier | constant_mintypmax_expression</td></tr>
<tr><td>list_of_net_identifiers</td><td> ::= net_identifier { , net_identifier }</td></tr>
<tr><td>list_of_net_decl_assignments</td><td> ::= net_decl_assignment { , net_decl_assignment }</td></tr>
<tr><td>net_decl_assignment</td><td> ::= net_identifier = expression</td></tr>

<tr><td>range</td><td> ::= [ msb_constant_expression : lsb_constant_expression ]</td></tr>
<tr><td></td><td bgcolor=red>| struct_identifier</td></tr>
<tr><td>net_identifier</td><td> ::= identifier</td></tr>
<tr><td></td><td bgcolor=red>| { struct_identifier.} identifier</td></tr>
<tr><td>reg_identifier</td><td> ::= identifier</td></tr>
<tr><td></td><td bgcolor=red>| { struct_identifier.} identifier</td></tr>
</table>
</td>
</table>

Given the above additions to the BNF, one could code the bus devices as follows:
<xmp>
struct Pbus
 begin
 parameter NDEV = 4;
 wire [31:0] address;
 wire [63:0] data;
 wire [1<<NDEV:0] req;
 wire [1<<NDEV:0] grt;
 wire buserr;
 end
endstruct // Pbus

module top;
   wire Pbus thePbus;
   wire clk;

   pbus_monitor p_mon( .Pbus(thePbus),.clk(clk));

   pbus_arb p_arb( .Pbus(thePbus), .clk(clk));
   pbus_cpu p_cpu0( .Pbus(thePbus), .clk(clk) .id(4'd0));
   pbus_cpu p_cpu1( .Pbus(thePbus), .clk(clk) .id(4'd1));

   pbus_mem p_mem0( .Pbus(thePbus), .clk(clk) .id(4'd2));
   pbus_mem p_mem1( .Pbus(thePbus), .clk(clk) .id(4'd3));
   pbus_mem p_mem2( .Pbus(thePbus), .clk(clk) .id(4'd4));
   pbus_mem p_mem3( .Pbus(thePbus), .clk(clk) .id(4'd5));

endmodule

module pbus_monitor( input Pbus my_Pbus );
   always @(my_Pbus.buserr) begin
      $display($time,,"BUSERR!!");
   end
   ...
endmodule // pbus_monitor

module pbus_arb( input Pbus.req,
                 output reg Pbus.grt,
                 inout Pbus.buserr,
                 input clk );
   always @(clk) begin
      case(req)
        0,1,2,4,8,16,32,64 : grt = req;
        default: // left as exercise...
      endcase // case(req)
   end

endmodule

module pbus_cpu( output reg Pbus.req,
 input Pbus.grt,
 inout Pbus.buserr,
 inout Pbus.data,
 inout Pbus.address, // for cache invalidate logic
 input [Pbus.NDEV:0] id,
 input clk );
 always @(clk) begin
 case (state)
 WANT_TO_WRITE: begin
 req[id] = 1;
 state <= WAIT_FOR_WRITE_GRANT;
 end // case: WANT_TO_WRITE

 WANT_TO_READ: begin
 req[id] = 1;
 state <= WAIT_FOR_READ_GRANT;
 end // case: WANT_TO_READ

 ...
 endcase // case(state)
 end // always @ (clk)

endmodule // pbus_cpu
</xmp>
 <address><a href="mailto:mac@silicon-sorcery.com">Michael McNamara</a></address>


Last modified: Mon Jun 1 11:21:23 PDT 1998

 </body>
</html>
</x-html>From ???@??? Mon Jun 01 15:25:38 1998
Return-Path: <owner-btf@boyd.com>
Received: (from majordomo@localhost)
 by gw.boyd.com (8.8.7/8.8.5) id OAA01762
 for btf-list; Mon, 1 Jun 1998 14:35:06 -0700
X-Authentication-Warning: gw.boyd.com: majordomo set sender to owner-btf@boyd.com using -f
Received: from smtpott2 (smtpott2.nortel.ca [192.58.194.80])
 by gw.boyd.com (8.8.7/8.8.5) with ESMTP id OAA01759
 for <btf@boyd.com>; Mon, 1 Jun 1998 14:34:54 -0700
Received: from bcarsca3 by smtpott2; Mon, 1 Jun 1998 18:15:41 -0400
Received: from bcarsb82.bnr.ca (actually 47.92.2.28) by bcarsca3;
 Mon, 1 Jun 1998 18:15:11 -0400
Received: by bcarsb82.bnr.ca (4.1/SMI-4.1 BNR V4.2 P1) id AA08107;
 Mon, 1 Jun 98 18:15:10 EDT
Date: Mon, 1 Jun 98 18:15:10 EDT
From: "Anders Nordstrom" <andersn@nortel.ca>
Message-Id: <9806012215.AA08107@bcarsb82.bnr.ca>
To: btf@boyd.com
Subject: BTF - B06 Proposed wording
Sender: owner-btf@boyd.com
Precedence: bulk
Status: RO
Dear BTF members,

This enhancement request was passed by the BTF in March last year.
Please review the proposed LRM changes before the June 4 conference call.

Regards,

Anders

+-----------------------------------------------------------------------+
| Anders Nordstrom |
| Senior ASIC Designer |
| |
| Northern Telecom Ltd. Email: andersn@nortel.ca |
| P.O. Box 3511 Station C Phone: 613-763-9186 |
| Ottawa, Ontario K1Y 4H7 Fax: 613-763-2626 |
+-----------------------------------------------------------------------+

<H2> B06 - Parameter passing by name (explicit & implicit) </H2>

<TABLE BORDER COLS=2 WIDTH="75%" >
<TR><TD>
Section: </TD><TD> 12.2 page 139
</TD></TR><TR><TD>
Date Submitted: </TD><TD> 970218
</TD></TR><TR><TD>
Requestor: </TD><TD> kurt@wsfdb.com (Kurt Baty)
</TD></TR><TR><TD>
Status: </TD><TD> Passed by BTF 970331
</TD></TR><TR><TD>
Analyzed by: </TD><TD> BTF Team & Anders Nordstrom
</TD></TR><TR><TD>
Synthesizable: </TD><TD> Yes
</TD></TR>
</TABLE>

<H3> Details </H3>

Abstract: Verilog currently supports port connections by name or by
position. Verilog only permits module instance parameter passing by position
and to redefine the 3rd parameter in a module, the 1st and 2nd parameters
must also be passed, even if they do not change (a separate defparam
statement is also allowed).

<H3> Proposal </H3>

In Section 12.2 on page 139 add "The module instance parameter value
assignment comes in two forms, by ordered list or by name." before the
last sentence which starts "The next two subclauses..."

Replace the first paragraph of Section 12.2.2 on page 140 with:

"An alternative method for assigning values to parameters within module 
instances is to use one of the two forms of module instance parameter 
value assignment. They are assignment by ordered list and assignment 
by name. The two types module instance parameter value assignment shall 
not be mixed; parameter assignments to a particular module instance 
shall be all by order or all by name.

Module instance parameter value assignment by ordered list is similar in
appearance to the assignment of delay values to gate instances and assignment
by name is similar to connecting module ports by name. It supplies values
for particular instances of a module to any parameters that have been
specified in the definition of that module."

Create a new section called 12.2.2.1 "Parameter value assignment by
ordered list". The text of the section should be the current second
paragraph in section 12.2.2 on page 140. In this section add "by
ordered list" after "...parameter value assignment" in the first
sentence.

Create a new section called 12.2.2.2 "Parameter value assignment by name"
with the following text: 
"Parameter assignment by name consists of explicitly linking the parameter
name and it's new value. The name of the parameter shall be the name
specified in the instanciated module. 
It is not necessary to assign values to all of the parameters within
a module when using this method. Only those parameters that are assigned
new values needs to be specified. 
The parameter expression is optional so that the instantiating module can
document the existence of a parameter without assigning anything to it.
The parentheses are required.

Add the following lines to the example on page 141 before the first
endmodule statement: 
<PRE>
// create an instance and set one parameter
vdff #(.delay(12)) mod_c(out_c, in_c, clk);
</PRE>
Add the following declaration under module m: 
wire [0:4] out_c, in_c; 
Correct the default value of the parameter size to 5.

Add the following text to the end of the last paragraph in 12.2.2 on page
141: 
"The construct #(.delay(12)) assigns the parameter delay the value 12
in the instance of module vdff called mod_c.

Replace the syntax for parameter_value_assignment in Syntax 12-2 on page 137
and Annex A.4 on page 597 with the BNF below:
<PRE>
parameter_value_assignment ::= # (list_of_parameter_assignments)

list_of_parameter_assignments ::=
ordered_parameter_assignment {, ordered_parameter_assignment} |
named_parameter_assignment {, named_parameter_assignment}

ordered_parameter_assignment ::= expression

named_parameter_assignment ::= . parameter_identifier ([expression])

</PRE>

Next message: Adam Krolnik: "Re: ANSI prototype proposal"
Previous message: Anders Nordstrom: "B07 Proposed wording"
Next in thread: Adam Krolnik: "Re: ANSI prototype proposal"
Reply: Adam Krolnik: "Re: ANSI prototype proposal"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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