From: Michael McNamara (mac@surefirev.com)
Date: Mon May 11 1998 - 13:51:25 PDT
Adam Krolnik writes:
>
>
> Michael McNamra writes:
>
> >Are you saing clif has it as:
>
> > module foo ;
> > input a,b,c;
> > output d;
> > endmodule
>
> >I don't like this as folks will intermingle io declarations with local
> >declarations to the confusion of us all.
>
> Date: Fri, 2 May 1997 08:00:47 -0700 (PDT)
> To: 1364core@galaxy.nsc.com (IEEE-1364 Core Group Reflector)
> From: cliffc@europa.com (Clifford E. Cummings)
> Subject: BTF - B09 - ANSI Declarations
>
> Could I suggest a couple of modifications to this request?
>
> module acontroller;
> parameter AMSB = 31, DMSB = 7;
> input req, reset, clock, start;
> input[7:0] data;
> output reg ack, end, full, empty;
> output error;
> output reg [AMSB:0] ad;
> output reg [DMSB:0] head;
> output reg [3:0] cbe;
>
> First: Instead of making a (port list), I would propose an I/O list similar
> to VHDL. Believe me I am not trying to make Verilog into VHDL but they
> actually had a good idea here (don't let any VHDL-types know I said that ;-)
> Reason: This allows parameter declarations before the I/O list to create
> parameterized modules.
Content-Length: 3777
X-Lines: 112
X-Status: $$$$
X-UID: 0000000440
Status: RO
To me that isn't sufficient argument; we could require a
complete scan for paramters in the module, and still key the
declarations in the port list.
But you are right; I don't know of a Verilog that accepts:
module foo(a,b,c);
input [A:B] a,b,c;
parameter A = 31, B = 16;
endmodule // foo
<p> >
> Second: I would recommend the syntax to be <I/O type> <optional net_reg
> type> <optional_range> <IO_list>. I believe it is easier to scan the I/O
> list this way.
I believe that is what I have as well; and so we are in
agreement.
>
> Third: If both a port list and I/O list are declared, the port list
> determines the port order, otherwise the I/O list determines the port order.
> This is only important when instantiating modules with positional ports as
> opposed to named ports.
Fine, although I'd like to get rid of what you are calling I/O
list; especially because it isn't a single list, but a collection of
objects that can be distributed throughout the module.
>
> Fourth: (Here comes the biggy!), I argue that declaring default wire and reg
> types are not necessary. Assignments within procedural blocks are always to
> reg types. Assignments outside of procedural blocks are always to wire types
> (assign, instance and gate primitive outputs). Assignments to a variable
> from both within and outside a procedural block is a syntax error ("Syntax
> error: assignment to variable "foo" from both a procedural assignment (line
> #x) and a non-procedural assignment (line #y) is illegal").
>
> Optional wire and reg declarations would be permitted, and non-default
> types, tri1, tri0, integer, etc. would still be required.
>
> I always forget my output reg declarations and I frequently switch back and
> forth between making an output assignment from within a procedural
> assignment and with a continuous assignment without changing the type
> declaration.
<p> This is quite a large change, and one that is not at all
specific to port declarations; I'd suggest it be a separate proposal.
>
> I believe this makes Verilog even easier to use and reduces redundant
> typing. This would not break any existing models.
>
> Regards - Cliff
>
>
> > >
> > > 5. Why is there a need for begin/end? What can be specified between
> > > the 'struct' identifier and the 'begin' keyword?
>
> > The 'Verilog way' No real need.
>
> I would like to recommend the begin/end pair be removed from the
> spec.
Ok by me.
>
> > >
> > > 6. I would still be interested in specifying the size of the structure as
> > > an additional check - A warning or error if structure size exceeds the
> > > stated size. E.g.
>
> > This does introduce the possibility of an error that is
> >unnecessary: what if 43:0 is too big/small for the sum of the
> >constituent items?
>
> Sigh! I guess that people would be too confused if we would make the absense
> of a range/size specification imply no specific size instead of a single bit.
> This is what I was thinking -- absense implies any size, presence implies size
> must match specification. What if we removed the brackets [] from the size?
>
> struct 43:0 p_bus ...
>
> One other thing I see as an interesting question. Is there a way to
> discover the size of the structure, presumably to declare other
> signals or other things.
$sizeof(struct Pcibus) should return 44.
If we were going to support a size specification in the
structure declaration, I would definately keep the brackets --
everyone would know what they mean. And in truth, they could provide
a alternate mapping of the whole structure to the individual bits:
struct [64:23] p_bus;
reg [7:0] pa;
reg [23:14] pb;
...
endstruct
<p> >
> Adam
>
>
>
>
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:52 PDT
and
sponsored by Boyd Technology, Inc.