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

According to IEEE 1364-2001, the standard implementation of a macromodule
(actually called "macro module", with a space, in Verilog-XL documentation,
except for the actual keyword) makes it identical to a module.

(In any case, a tool's internal implementation of a module or macromodule
is not the concern of the standard. The standard only specifies its
behavior as seen by a user.)

Optionally, however, a tool may do something different with a macromodule
which makes it distinct from a module. This is allowed by the standard.
But each tool may do something different. Basically, the standard implies
that if you want to guarantee interoperabilty and portability, then use
module. macromodule was kept for back-compatability with Verilog-XL.

In fact, the standard does not say anything about in-lining or any other
way of relating to macromodules. Not about optimization or restrictions
or anything else. It just says "differently".

In fact, even Verilog-XL does not in-line all macromodules, only those that
obey a long list of restrictions both on their contents and on their
instantiations. macromodules that do not fulfill those restrictions are
treated like regular modules. So you could have some instances in-lined
and others not.

In-lining also affects the hierarchical names of the nets within the
macromodule. To be portable, you would have to avoid hierarchical references
to those nets. If you obeyed that restriction and maybe a few others as well,
then your code would work in both an implementation that in-line the
macromodule instance and one that did not.

So since the standard, default behavior is to treat macromodules as modules,
it would not be back-compatible to require to treat them differently.

And you can't even simply talk about in-lining them, because even Verilog-XL
only sometimes in-lines them, but not always.

Now, regarding paramsets, as I wrote previously, someone who really wants to
understand the idea should read the proposal document on the AMS website.

I am not sure about some of the rest of this stuff, but I do like the idea of
being able to group a set of parameter values into a set and then just
having to refer to the set name in order to get the entire list of parameter
values defined in the test. A little like one of the reasons behind interfaces,
or structs, where you can refer to a whole set of signals with a single
high-level name.

I also like the idea of implicit parameter connections using #(.*).

Some of this, on the other hand, sounds less nice to me.
For example, it sounds like I would instantiate a certain module with a certain
set of parameters by instantiating the paramset name. I don't like that
because it adds obscurity to the code. I write that I am instantiating X when
really I am instantiating Y, just indirectly. And even if I know that X is
a paramset, I have to go look up its definition in order to find what module
it really does instantiate.

Shalom

On Tue, 22 Jun 2004, Steven Sharp wrote:

> > 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.
>
> It would be problematic for an AMS implementation built on top of a 1364
> implementation. It would also be problematic for users who want to be
> able to use the digital subset of their design in both AMS and digital
> Verilog.
>
> Steven Sharp
> sharp@cadence.com
>

-- 
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