Geoffrey.Coram wrote:
>Kevin Cameron wrote:
>
>
>>If the LRM says macromodules shouldn't introduce hierarchy that's good enough for me :-)
>>
>>
>
>
>Where does it say that, Kevin?
>
>The Verilog-AMS LRM (2.1) says only (in section 7.1) that:
>
> The keyword macromodule can be used interchangeably with
> the keyword module to define a module. An implementation
> can choose to treat module definitions beginning with the
> macromodule keyword differently.
>
>which is essentially the same as what Shalom excerpted from
>the 1364-2001 LRM.
>
>
>
It was my understanding that macromodules don't introduce hierarchy -
obviously an invalid assumption :-(
>Obviously, since paramsets don't exist yet, we can say that
>they don't introduce hierarchy.
>
>
But it's just a easy to be strict about macromodules, the treatment
should be consistent across all simulators, "An implementation can
choose to treat module definitions beginning with the macromodule
keyword differently." seems inappropriate for an LRM to me.
NB: We are not merging with IEEE 1364 Verilog, we are merging with
SysytemVerilog, and the original question was:
Do we want to use paramsets for module overloading or do we want a
more general mechanism for module overloading?
I suggested an alternative for the sake of argument, since the
functionality in paramsets seemed a little too narrowly focused for me,
and module overloading seems like useful functionality. In particular,
if at some future time we want to overload based on port types I don't
want to have an entirely different mechanism from parameter based
overloading for doing it.
Kev.
>
>-Geoffrey
>
>
Received on Tue Jun 22 10:07:23 2004
This archive was generated by hypermail 2.1.8 : Tue Jun 22 2004 - 10:07:25 PDT