Number | 210
|
Category | errata
|
Synopsis | A.4.1, A.5.4: Why no anonymous module instances?
|
State | closed
|
Class | errata-discuss
|
Arrival-Date | Dec 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