From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Mon Jul 30 2001 - 21:42:15 PDT
I found the attached in my archives.
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 **************************************************************************<p><p><p>
<strong>attached mail follows:</strong><hr noshade>
Adam Krolnik writes: > > Good morning Mac: > > A few simple comments: > > 1. I don't understand the parameter_port list functionality. > A. Why is it # ( parameter blah...)? Doesn't this seem redundant > to require two syntactic devices (the #() and 'parameter'.) > I would consider folding the parameter declarations into > the regular port list.
I had parameter declarations intermixed with port declarations in the last proposal, but pressure from folks caused me to move them out. Basically, the gist of the argument to move them out is that when you instantiate, you use two separate lists, both which can be positionally oriented. If you declare them in one list, them looking at the declaration and the instantiation can be very confusing.
> > B. You say, 'where the parameters are used to size the width of > input, output and inout ports.' Does this mean, I have to > record parameters for other purposes somewhere else? Or > is this the place to declare parameters that can be redefined > by the instantiation parameter override?
The new syntax is an extra optional place to declare parameters. We don't want to mek existing modules illegal; so it is still legal to declare parameters where ever they can be declared today. However, new modules written using the new syntax that have parameters that are used in the declaration of the widths of I/Os, need to have those parameters declared before use. There then needs to be a place to declare them that is before the module port list.
I actually like the coding style requirement that parameters that are intended to be overloaded go in this list, and other local parameters go outside this list. However, this proposal is not making that requirement.
> > 2. I don't see the usefulness to modify/extend the syntax for tasks/functions. > It doesn't seem to buy anything except some consistency with module > definitions. I presume this is exactly the reason it was introduced. > Is there any other functionality extension that goes with it?
At vote was taken in the last full 1364 meeting, and like 9 people wanted ansi style ports, in a parenthesis list, as long as they could also code tasks and functions this way. Just because 'consistency is the hobgoblin of small minds' doesn't mean consistency is a bad thing... :-)
Just 1 person wanted all declarations to look like the existing task syntax, and even that person said they wanted it that way because they felt the other was too big a change; however seeing the strong support for that change, that person said they would go along.
> > 3. Okay, now I'm confused (you probably answered my questions in 1b already.) > So the example of point 7 shows that not only parameters that can be > overridden at instantiation time need to be declared above, but any > locally computed parameters also need to be listed there (as shown by > the example.) So does this mean that we still need the 'localparam' > proposal to limit parameters that are overridable to a subset of > the parameters defined in the parameter_port_list?! You probably > don't want the name 'parameter_port' if you have to declare parameters > that also are needed to compute declarations of the ports and are not > allowed to be overridden at instantiation.
At present parameters must be declared before being used. If we keep this requirement (no one is proposing a change), then one must include the whole 'cone of logic' of parameters that are used to define the width of a port before the port is declared.
Given that we have added constant functions, an example is needed to show how one could use constant functions to define the width of a port. The body of the function might use parameters, which hence get into the 'cone of logic' and hence must be declared before being used. The point of the example is that the parameter is used at the point where the function is called, not where the function is declared.
> > 4. What about the initialization of registers (aka B14?) > Should this be a valid port definition? > > output reg [7:0] out_byte = 'b0; > > Also, if this is allowed, it should be allowed for output port > definitions of tasks.
My first inclination is yes, reg initializations are allowed. However, I would not want to allow wire assigns... So then I'm thinking that no, neither register initialization nor wire assigns are not allowed in the port list.
I of course look for comments here. My justification is because in the port list we are defining the interface, not the implementation. We save so very very much by unifing the port list, the port declaration and the net or reg declaration, that leaving reg initialization and wire assigns out of the port list is actually good. It calls attention to these importnat implementation details.
module foo ( input wire [7:0] a; input wire [7:0] b; output wire [7:0] o; output reg override; );
initial override = 1; assign o = a&b;
endmodule
It also limits the amount of executable code hidden in the port list. (one can still say: module foo ( input wire [7:0] .a(b));)
If we said yes, then this would be equivalent to the above:
module foo ( input wire [7:0] a; input wire [7:0] b; output wire [7:0] o = a &b; output reg override = 1; );
/* Ack: No body needed! */
endmodule > > I want this port delclaration functionality as part of the standard > - I hate writing thrice the ports! > > > Adam Krolnik > Verification Engineer > Cyrix - NSC. > Richardson TX. 75085 >
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:43 PDT
and
sponsored by Boyd Technology, Inc.