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

Alec,

I was using the term "inlining" because someone else had already
started using that term.

The actual term used in the Verilog-XL documentation is "expansion".

In Verilog-XL, if A were an expanded macro module which contained
a net N, and its hierarchical name normally would be top.A.N,
then after expansion, its name would be top.\A^N .
The backslash is an escape character.

Referring to that as top.A.N would cause confusion as to when
the period represents hierarchy or not.

And it would not be back-compatible with Verilog-XL,
if that is important.

With respect to external references into the instance of a macro
module, it's a chicken and egg question. People might avoid making
something into a macro module if they need those references.
I do know that I have written monitors which refer to nodes
internal to gate-level cells.

Finally, I again remind that Verilog-XL has great restrictions
on what macro module instances can be expanded. There are reasons
for those restrictions.

Shalom

On Wed, 23 Jun 2004, Alec Stanculescu wrote:

> Shalom,
>
> I agree with you that the current LRM makes no difference between
> module and macro module.
>
> Macro Modules (as the name suggests to each of us) could have the
> useful semantics of not introducing hierarchy. Whether they are
> inlined or not that is another matter, because they could be inlined
> and still preserve hierarchy, i.e. objects decalred inside the macro
> module could be referenced by an external reference by using the
> instance name of the macro module or by just using the object:
> top.inst1.macro_inst1.obj vs top.inst1.obj.
>
> By not introducing hierarchy the user helps the tool save some space
> to store that hierarchy, because the user knows that no name conflict
> will arise (conflict which will be reported by the tool if it occurs).
>
> My impression is that tools other than simulators made already use of
> this.
>
> So, this could be an enhancement request with little or no problems
> regarding compatibility with existing code because I doubt that there
> are external references into the instance of a macro module.
>
> Regards,
>
> Alec
>

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