Re: [sv-bc] Re: implicit instantiation of top-level modules?


Subject: Re: [sv-bc] Re: implicit instantiation of top-level modules?
From: Dave Rich (David.Rich@synopsys.com)
Date: Wed Jul 09 2003 - 10:35:48 PDT


Must be a slow work week for you guys! :-)

My interpretation of the sentence ( and I believe Verilog-XL, VCS, and
all other simulators is

Top-level modules are modules that are included in the source text but
are not instantiated/ by any other module and are therefore implicitly
instantiated at the root level.
/
If I have the following description, how else would the simulator know
to create only one copy of r, not two.
-----------------
module top;
bot bot();
endmodule

module bot;
reg r;
endmodule
------------------

I believe the original question posed by the SV-BC has been answered
sufficiently, and we now have a mechanism to recursively define module
instances inside of nested module definitions.

Dave

Michael McNamara wrote:

>Shalom Bresticker writes:
> > Precedence: bulk
> >
> > Yes, and it does not say anything about implicit instantiation. It
> > talks about module names, not instance names.
> >
> > Similarly, 12.1.1 says, "Top-level modules are modules that are
> > included in the source text but are not instantiated."
> >
> > But the main place to look at is 12.5:
>
> > "The name of a module or module instance is sufficient to identify
> > the module and its location in the hierarchy. A lower-level module
> > can reference items in a module above it in the hierarchy.Variables
> > can be referenced if the name of the higher-level module or its
> > instance name is known."
> >
> > Now see the Example. In the example, there are two top-level
> > modules, a and d. Both a and d instantiate b, with instance names
> > a_b1 and d_b1 respectively.
> >
> > Module b instantiates c. c contains a reference to "b.i", where i
> > is an integer declared in module b. The example states that this
> > references both a.a_b1.i and d.d_b1.i by upwards name referencing.
> >
> > But note that b is explictly instantiated and it is not a top-level
> > module. Yet c can still refer to it by its module name even though
> > it is not the module instance name.
> >
> > I believe that the same mechanism is used for full hierarchical
> > names which start with the top-level module name. That is why it
> > works even though the top-level module is not instantiated.
> >
> > Shalom
>
>
>I believe Shalom is correct here, in stating that the top level
>modules are never instantiated.
>
>However, as I recall in VCS, we in truth created an instance of each
>top level module, with the instance name being the name of the module;
>then the code to implement things like $display("%m"); was very
>simple.
>
>However, one does need to pay attention to the ability to use a module
>name as an element in a hierarchial path.
>
> > Dave Rich wrote:
> >
> > > Actually, I did find the wording in section 12.4 of 1364-2001, second
> > > paragraph
> > >
> > > "At the top of the name hierarchy are the names of one or more root
> > > modules of which no instances have been
> > > created. This root or these parallel root modules make up one or more
> > > hierarchies in a design description or
> > > description."
> > >
> > > Karen Pieper wrote:
> > >
> > > > Verilog 2K does have implicit instantiation at the $root level
> > > > creating top-level modules. We believe
> > > > there must be language in the V2K spec indicating that the implicit
> > > > name for those modules is
> > > > the same as the module name. There is another issue that addresses
> > > > implicit instantiation of
> > > > modules declared within other modules.
> > > >
> > > > K
> > > >
> > > > At 01:12 PM 7/8/03 +0300, you wrote:
> > > >
> > > >> Regarding "11. Is there wording on the Verilog 2K spec for this?":
> > > >>
> > > >> I don't understand the question. The feature does not exist in
> > > >> 1364-2001, so
> > > >> there is no wording on it.
> > > >>
> > > >> Shalom
> > > >>
> > > >>
> > > >>
> > > >> "Karen L. Pieper" wrote:
> > > >>
> > > >> > Hi, all,
> > > >> >
> > > >> > The minutes for the 7/7/03 meeting have been posted to the sv-bc
> > > >> website.
> > > >> >
> > > >> > http://www.eda.org/sv-bc/minutes
> > > >> >
> > > >> > K
> >
> >
> > --
> > Shalom Bresticker Shalom.Bresticker@motorola.com
> > Design & Reuse Methodology Tel: +972 9 9522268
> > Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
> > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
> >
> >
>
>
>
>

-- 
--
Dave Rich
Principal Engineer, CAE, VTG
Tel:  650-584-4026
Cell: 510-589-2625
DaveR@Synopsys.com



This archive was generated by hypermail 2b28 : Wed Jul 09 2003 - 10:37:22 PDT