Proposal to get declarations and structures moving along

From: Michael McNamara (mac@surefirev.com)
Date: Mon May 11 1998 - 09:38:57 PDT

Next message: Tom Fitzpatrick: "Re: Proposal to get declarations and structures moving along"
Previous message: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Next in thread: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Reply: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Reply: Tom Fitzpatrick: "Re: Proposal to get declarations and structures moving along"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Here is the beginings of a proposal for ansi declarations and
structures

<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.
 
 This proposal first enhances the input_declaration,
 output_declaration, and inout declaration, and would further allow
 the input_declaration, output_declaration and/or inout_declaration
 to be used as port_references, as follows:

<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>
<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></td><td>...</td></tr>

<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
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, IT_IL_RQ, IT_RQ_VLD, RdMsg,
 WrMsg, AccessOK, XX_IL_PIODONE,
 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> 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.
 </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 May 4 09:02:53 PDT 1998

 </body>
</html>
</x-html>From ???@??? Sat May 09 16:15:11 1998
Return-Path: <owner-btf@boyd.com>
Received: (from majordomo@localhost)
 by gw.boyd.com (8.8.7/8.8.5) id OAA08993
 for btf-list; Sat, 9 May 1998 14:22:44 -0700
X-Authentication-Warning: gw.boyd.com: majordomo set sender to owner-btf@boyd.com using -f
Received: from greatdane.webnexus.com (greatdane.webnexus.com [165.227.96.3])
 by gw.boyd.com (8.8.7/8.8.5) with ESMTP id OAA08990
 for <btf@boyd.com>; Sat, 9 May 1998 14:22:32 -0700
Received: from bcarsde4 (mailgate.nortel.ca [192.58.194.74])
 by greatdane.webnexus.com (8.8.7/8.8.5/WN-1.2) with ESMTP id MAA32716
 for <btf@boyd.com>; Sat, 9 May 1998 12:05:14 -0700 (PDT)
Received: from bcarsca3 by mailgate; Sat, 9 May 1998 15:01:16 -0400
Received: from bcarsb82.bnr.ca (actually bcarsb82.ca.nortel.com) by bcarsca3;
 Sat, 9 May 1998 15:00:25 -0400
Received: by bcarsb82.bnr.ca (4.1/SMI-4.1 BNR V4.2 P1) id AA02079;
 Sat, 9 May 98 15:00:10 EDT
Date: Sat, 9 May 98 15:00:10 EDT
From: "Anders Nordstrom" <andersn@nortel.ca>
Message-Id: <9805091900.AA02079@bcarsb82.bnr.ca>
To: btf@boyd.com
Subject: BTF: Errata 45 to review before conf call May 12
Sender: owner-btf@boyd.com
Precedence: bulk
Status: RO
Dear BTF Members,

Please review this updated Errata and be prepared to vote on it on
May 12. I appologize for the short notice but I hope you can review
it anyway. As you know we do have a fairly tight schedule.

Regards
Anders

<HTML>
<HEAD>
<TITLE> Errata to vote on by BTF </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">

<H2> BE45 - Behavioral function definition </H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD> Section: </TD><TD> 11 </TD>
</TR><TR>
<TD> Date Submitted: </TD><TD> 961217 </TD>
</TR><TR>
<TD> Requestor: </TD><TD> Steve Meyer </TD>
</TR><TR>
<TD> Status: </TD><TD> Proposal </TD>
</TR><TR>
<TD> Analyzed by: </TD><TD> Adam Krolnik & Karen Pieper </TD>
</TR>
</TABLE>

<H3> Details </H3>

I just ran into the following function that I think may be illegal
according to the IEEE P1364 standard but probably needs to be explicitly
allowed because break and continue require named blocks. The function below
does not work in Cver because it treats named blocks as task enables
since they can be disabled, and for nested named blocks the downward
chain disabling rule (section 11-1 Oct. 1995 draft) must be applied.

The problem is probably one of documentation clarity. I read section
11 page 1 (but not the remaining examples) as allowing disable of any
named block, therefore named blocks are illegal inside function definitions,
but my interpretation must be wrong since the function is part of the DA
solutions benchmarks and works on other simulators.

Also, I am not sure what the meaning of parallel blocks (fork-join)
is inside functions.

The LRM grammar, in my view correctly, does not define timing behavior
semantics inside functions (see A.2 and A.6). It allows any statement.

I assume it is illegal from outside a function to disable a named block
inside a function because that implies timing control that is explicitly
dis-allowed inside functions. Such disable is, I think, unlikely except for
debuggers that allow statement by statement tracing inside functions.
However, I read section 5.4.2 sentence 2 as allowing functions to be
interrupted in the middle (say) to execute other events because there is
no non timing control statement group atomicity condition.

I hope behavior within functions and for named blocks will be defined more
exactly in the new version of the LRM.

/Steve

Function from DA Solutions public domain bench marks das_cpu example
<PRE>
function [0:31] sign_extend;

input [0:15] D2;
reg [0:31] result;

begin
 begin
 begin : sextend
 integer i;
 begin
 for (i = 0; i < 16; i = i+1)
 begin
 result[i] = D2[0];
 result[i+16] = D2[i];
 end
 end
 end
 sign_extend = result;
end
endfunction
endmodule
</PRE>
Here is a test top level module
<PRE>
module top;
reg [0:15] D, X;

initial
begin
 D = 6;
 X = sign_extend(D);
 $display("sign extend of %b is %b", D, X);
end

-- 
Steve Meyer				Phone: (415) 296-7017
Pragmatic C Software Corp.		Fax:   (415) 781-1116
220 Montgomery St., Suite 925		email: sjmeyer@crl.com
San Francisco, CA 94104
</PRE>
Hi, Steve.
I'll add my two cents worth.
Let me preface my remarks by saying that I have only the April 1995 draft
since I apparently have not been judged eligible to get 1364 mailings on a 
regular basis.
I don't agree with your interpretations.
I don't think that named blocks should be considered task enables.
My P1364 draft seems to distinguish between named blocks and tasks.
1364 does not imply, in my opinion, that because named blocks can be disabled,
then they are like task enables.  You don't explain why you think that
one necessarily follows from the other.
In certain respects, they are similar, but different in others.
I don't see a reason that named blocks should be illegal in functions.
I have in the past argued that functions MUST be executed atomically
in order to guarantee coherent execution.
Regards,<BR>
<PRE>
******************************************************************************
Shalom Bresticker				email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd.		Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL		Fax #: +972 9 9522444
******************************************************************************
</PRE>
---------------------------------------------------------------------------
The following code is acceptable by both XL and VCS; the disable statement
terminates execution of the block and the function returns the current value
assigned to it.
<PRE>
module test;
function f;
  input a,b,c;
  begin :block
  f = a|b & c;
  disable block;
  f = 'b0;
  end
endfunction
initial begin
  $display("Result is %0b.", f('b1, 'b0, 'b1));
  end
endmodule
</PRE>
<H3> Proposal </H3>
Change the last paragraph of section 11 "Disabling of named blocks and tasks" from
"The disable statement can be used within blocks and tasks to disable the particluar
block or task containing the disable statement. The disable statement cannot be used
to disable functions."
to:
"The disable statement can be used within blocks and tasks to disable the particluar
block or task containing the disable statement. The disable statement can be used to
disable named blocks within a function, but cannot be used to disable functions. In cases where a disable statement within a function disables a block or a 
task that called the function, the behavior is undefined."
 
<HR SIZE=5 NOSHADE>
</BODY>
</HTML>

Next message: Tom Fitzpatrick: "Re: Proposal to get declarations and structures moving along"
Previous message: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Next in thread: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Reply: Adam Krolnik: "Re: Proposal to get declarations and structures moving along"
Reply: Tom Fitzpatrick: "Re: Proposal to get declarations and structures moving along"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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