From: Michael McNamara (mac@verisity.com)
Date: Mon Jul 30 2001 - 22:21:50 PDT
Thanks, Shalom. Clearly the net is a better memory device than my own
head. Of course learning 'e' has been pushing out my memory of our
exciting BTF email exchanges.
Or dear, I am also reminded by looking at this old email that my
mother always told be to check my work for misspellings before I send
them out... *sigh*
That aside, it does seem that one can indeed use parameters with ansi
style port declarations, which is great. One can not use localparams
for this which is unfortunate; but not the end of the world.
Shalom Bresticker writes:
> [1 <multipart/alternative>]
>
> [1.1 <text/plain; us-ascii (7bit)>]
> 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
> **************************************************************************
>
>
> [1.2 <text/html; us-ascii (7bit)>]
>
> [2 <message/rfc822>]
>
> [2.1 Re: Port Proposal in HTML <text/plain; us-ascii (7bit)>]
> From: Michael McNamara <mac@surefirev.com>
> Sender: owner-btf@boyd.com
> To: Adam Krolnik <adamk@cyrix.com>
> Cc: mac@surefirev.com, btf@boyd.com
> Subject: Re: Port Proposal in HTML
> Date: Mon, 11 Jan 1999 08:47:36 -0800 (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:54:43 PDT
and
sponsored by Boyd Technology, Inc.