ISSUE 210

Number 210
Category errata
Synopsis A.4.1, A.5.4: Why no anonymous module instances?
State closed
Class errata-discuss
Arrival-DateDec 04 2002
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001b: A.4.1, A.5.4
Environment
Description
Why can't a module_instance be anonymous, like a udp_instance can be?

Is this just tradition, or is there a justification for the difference?
In A.4.1, if the name_of_instance were made optional in module_instance,
would it cause any harm?

-- Brad

Fix
Reject the issue
Audit-Trail

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Thu, 05 Dec 2002 11:30:42 +0200

>
> Why can't a module_instance be anonymous, like a udp_instance can be?
>
> Is this just tradition, or is there a justification for the difference?
> In A.4.1, if the name_of_instance were made optional in module_instance,
> would it cause any harm?

I don't know for sure, but I would guess it is connected to the fact that
gates and udp's
have no internal components which need to be referenced, whereas modules
contains
nets and variables, tasks and functions, and instantiate other modules,
etc.

Interestingly, Verilog-XL contains compiler directives `remove_gatenames
and
`remove_netnames.


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Thu, 5 Dec 2002 18:17:11 -0500 (EST)

>Why can't a module_instance be anonymous, like a udp_instance can be?

Because it is important to be able to reference all objects by a unique
hierarchical name. In addition to hierarchical references within the
HDL, this is needed for things like VCD dumping and interactive debugging.
UDPs don't really have anything declared inside them, so this isn't an
issue for them.

Steven Sharp
sharp@cadence.com


From: Peter Flake <Peter.Flake@synopsys.com>
To: "Brad Pierce" <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Thu, 05 Dec 2002 17:30:44 +0000

Brad,

It would mean that there was no hierarchical name for items in the module
and for %m in $display.

Peter.

At 06:47 PM 12/4/02 -0800, Brad Pierce wrote:
>Precedence: bulk
>
>
> >Number: 210
> >Category: errata
> >Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
> >Environment:
> >Description:
>
>Why can't a module_instance be anonymous, like a udp_instance can be?
>
>Is this just tradition, or is there a justification for the difference?
>In A.4.1, if the name_of_instance were made optional in module_instance,
>would it cause any harm?
>
>-- Brad



From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Sun, 8 Dec 2002 14:26:39 +0200 (IST)

But as I wrote, Verilog-XL has had an option for years to remove gate names and
wire names. You could require an instance name if there is a hierarchical
reference and allow anonymity otherwise. You could say that VCD would not work
on such
a module. Same for interactive debugging, PLI, etc. All these things would
simply be inaccessible. Similarly, you have a 'vectored' vector, which removes
the accessibility of the individual bits. And VCS and NCV have all sorts of
restrictions on what you can do in default mode. For example, you have to set a
special switch in order to do interactive debugging.

> >Why can't a module_instance be anonymous, like a udp_instance can be?
>
> Because it is important to be able to reference all objects by a unique
> hierarchical name. In addition to hierarchical references within the
> HDL, this is needed for things like VCD dumping and interactive debugging.
> UDPs don't really have anything declared inside them, so this isn't an
> issue for them.


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Mon, 05 May 2003 19:13:41 +0300

Resend.

Proposal: reject the comment

Although it might have made sense to allow anonymous module instantiation
when Verilog was a new language, at this point the impact of making such a
change is probably substantial.

As has been pointed out from the e-mail thread on this topic, instance
names for instantiated modules are valuable in their use of examining the
hierarchy below that instantiation. Adding the notion of anonymous module
instantiation would result in: loss of the ability to inspect the contents
of such an instatiation; and/or, loss of PLI access to such a module; and/or
the requirement to specify how such access could be restored.

James Markevitch

From: Stephen Williams <steve@icarus.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/210: A.4.1,A.5.4: Why no anonymous module instances?
Date: Mon, 05 May 2003 09:48:50 -0700

> As has been pointed out from the e-mail thread on this topic, instance
> names for instantiated modules are valuable in their use of examining the
> hierarchy below that instantiation.

A module instance creates a new scope, which by definition has a
name of some sort. However, faced with an "anonymous" instantiation,
a reasonable compiler writer would simply create a unique name
automatically. I see no problem here.

This internally generated name can be extracted from the design using
existing PLI functions. For example, a %m of a $display within the
anonymous module would print the generated name. The $display can
implement that functionality simply by asking the VPI for the name
of its containing scope.

I see no difficulties allowing anonymous module instantiations. I can
implement it in an afternoon if you need an example.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."


Unformatted



Hosted by Boyd Technology