RE: [sv-ec] Re: Quick poll for AMS extension to overload modules

To add a little historical perspective, at least the way I remember it...

In the days of the proprietary Gateway Verilog, modules required a new level
of hierarchy, and macromodule required a flattened (or in-lined) level of
hierarchy. Both keywords created a new naming scope, and were otherwise
similar in usage. The original Verilog simulator that Verilog was created
for took advantage of macromodules to optimize its simulation data structure
and performance. When Verilog was placed in the public domain, the OVI
Verilog LRM did not clearly document the flattened hierarchy requirement of
macromodules, and hence some products implemented macromodules with
hierarchy, and some products flattened macromodules. The OVI BNF, if I
recall correctly, treated macromodules as a different production than
modules, but did not make it clear what was different. For the 1364-1995,
we debated the issue, and decided to follow the general policy we were
operating under, which was to not break any existing implementations.
Therefore, we stated in 1364-1995 that macromodules were *syntactically*
identical to modules, but that software tools could optionally optimize
macromodules by flattening the hierarchy represented. I recall that we
discussed adding verbiage to the LRM that an implementation could specify
restrictions on macromodules in order to optimize them. It the restrictions
were not followed, then the macromodule was simply treated as a module. I
don't remember if that verbiage made it into the final 1364-1995 LRM. At
the moment, I don't have time to search for it. My intent here is to only
explain why we did what we did for the 1995 standard.

The fact that a user sees no syntactical difference between module and
macromodule means to a user they are interchangeable keywords. That is,
both can use the same constructs, and their contents can be referenced
hierarchically in the same way. I would think if Verilog-AMS can maintain
that syntactical equivalence, then it would not be an issue for AMS to add
to the 1364 a requirement that an AMS implementation shall (required)
in-line macromodules, while other types of implementations may (optional)
in-line macromodules, as it is now). I also do not see it as a problem for
AMS to specify restrictions on macromodules, if needed, in order to in-line
them. We did the same thing in 1364-2001 for constant functions. That is,
a function can only be used as a constant function if certain restrictions
are followed.

Just my thoughts...

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> Behalf Of Kevin Cameron
> Sent: Tuesday, June 22, 2004 11:35 AM
> To: Karen Pieper
> Cc: Shalom Bresticker; sv-ec@eda.org; verilog-ams@eda.org
> Subject: Re: [sv-ec] Re: Quick poll for AMS extension to
> overload modules
>
> Karen Pieper wrote:
>
> > The LRM gives tools the option of adding hierarchy or not.
> It turns
> > out that having the choice of not adding hierarchy is very
> convenient,
> > so I'd prefer we leave the language as it is.
> >
> > K
> > At 09:30 AM 6/22/2004 -0700, Kevin Cameron wrote:
>
> Very convenient for implementors.
>
> It's not convenient if you're a designer who actually needs
> to be able
> to add a layer of indirection in a design without breaking
> testbenches
> etc that are using cross-module references for probing.
>
> The "as is" is different for different implementations. The
> job of the
> committees is to agree on the correct behavior that everyone
> should follow.
>
> If "macromodule" is redundant it should be deprecated. I'd prefer it
> stayed and had "the no-extra-hiearachy" behavior.
>
> Kev.
>
> > Shalom Bresticker wrote:
> >
> >>>
> >>>In digital Verilog, that is only in one particular simulator, and
> >>>even then, not in all cases.
> >>>Most other tools treat macromodules identically to modules.
> >>>Thus, macromodule use is non-portable if you need to
> reference signals
> >>>inside the macromodule from
> >>>outside, say in a testbench.
> >>>
> >>>Shalom
> >>>
> >> If the LRM says macromodules shouldn't introduce hierarchy that's
> >> good enough for me :-)
> >>
> >> For the sake of (this) argument assume that it works
> properly in all
> >> simulators.
> >>
> >> Kev.
> >>
> >>>
> >>>Kevin Cameron wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>>
> >>>>>Why do you guys talk about macromodules so much?
> >>>>>
> >>>>>1364-2001, 12.1, says,
> >>>>>"The keyword macromodule can be used interchangeably with the
> >>>>>keyword module to define a module."
> >>>>>
> >>>>>I.e., macromodules are the same as modules.
> >>>>>
> >>>>>Does Verilog-AMS have a special definition of macromodules?
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>Macromodules (and paramsets) don't introduce extra hierarchy.
> >>>>
> >>>>Kev.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>--
> >>>>>Shalom
> >>>>>Bresticker
> >>>>>Shalom.Bresticker @freescale.com
> >>>>>Design & Reuse
> >>>>>Methodology
> >>>>>Tel: +972 9 9522268
> >>>>>Freescale Semiconductor Israel,
> >>>>>Ltd.
> >>>>>Fax: +972 9 9522890
> >>>>>POB 2208, Herzlia 46120,
> >>>>>ISRAEL
> >>>>>Cell: +972 50 5441478
> >>>>>
> >>>>>[ ]Freescale Internal Use Only
> >>>>>[ ]Freescale Confidential Proprietary
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>--
> >>>Shalom
> >>>Bresticker
> >>>Shalom.Bresticker @freescale.com
> >>>Design & Reuse
> >>>Methodology
> >>>Tel: +972 9 9522268
> >>>Freescale Semiconductor Israel,
> >>>Ltd.
> >>>Fax: +972 9 9522890
> >>>POB 2208, Herzlia 46120,
> >>>ISRAEL
> >>>Cell: +972 50 5441478
> >>>
> >>>[ ]Freescale Internal Use Only
> >>>[ ]Freescale Confidential Proprietary
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>
>
Received on Tue Jun 22 12:26:22 2004