Another delat on the structures proposal

From: Michael McNamara (mac@surefirev.com)
Date: Wed Jun 03 1998 - 18:10:30 PDT

Next message: Adam Krolnik: "Re: BTF - Verilog Identifiers and Hierarchical Referencing"
Previous message: Anders Nordstrom: "BTF: Updated B14 proposal"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

I've incorporated some suggestions from Adam Krolnik in the structure
section.

<!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 [ range ] struct_identifier struct_items endstruct</td></tr>
<tr><td>struct_items</td><td>::= struct_item { struct_item }
<tr><td>struct_item</td><td>::= net_declaration ;</td></tr>
<tr><td></td><td>| reg_declaration;</td></tr>
<tr><td></td><td>| parameter_declaration;</td></tr>
</table>
</td>
</table>

The structure definition is global, at the same scope as the module
declaration. If two structures are declared with the same
struct_identifier, then they must match exactly; otherwise the system
shall signal an error.

If there is a range specified, the structure is limited to the size
of that range [and an error shall be generated if the number of bits
required to implement the structure is not equal to the size of the
range.] Bit and part selects of the structure would have to fall
within the range. If there is no range specified, the size of the
structure is the sum of the sizes of the individual elements.

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
 parameter NDEV = 4;
 wire [31:0] address;
 wire [63:0] data;
 wire [1<<NDEV:0] req;
 wire [1<<NDEV:0] grt;
 wire buserr;
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(Pbus.req)
        0,1,2,4,8,16,32,64 : Pbus.grt = Pbus.req;
        default: // left as exercise...
      endcase // case(Pbus.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
 Pbus.req[id] = 1;
 state <= WAIT_FOR_WRITE_GRANT;
 end // case: WANT_TO_WRITE

 WANT_TO_READ: begin
 Pbus.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: Wed Jun 3 18:08:53 PDT 1998

 </body>
</html>

Next message: Adam Krolnik: "Re: BTF - Verilog Identifiers and Hierarchical Referencing"
Previous message: Anders Nordstrom: "BTF: Updated B14 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.