From: Michael McNamara (mac@surefirev.com)
Date: Mon Jan 11 1999 - 08:47:36 PST
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:53:31 PDT
and
sponsored by Boyd Technology, Inc.