Subject: Re: [sv-bc] Re: implicit instantiation of top-level modules?
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu Jul 10 2003 - 02:01:59 PDT
Dave,
You must be tired!
You are taking the text and turning it on its head!
The text you quoted says,
> > > "At the top of the name hierarchy are the names of one or more root
> > > modules of which no instances have been created."
You are turning it from "no instances" to "an implicit instance".
Now don't misunderstand me.
Obviously the simulator creates an active copy of top-level modules.
That can be related to as an "implicit instance", which is in fact what VCS does,
according to Mac.
However, a simulator could also relate to it as a special case and come out with
the equivalent functionality.
Also note that the SV issue as worded relates to the NAME of the implicit
instance.
On that, 1364 certainly does not say anything.
On the contrary, 1364 goes out of its way to talk about the "module name OR the
instance name".
If instance names were sufficient, there would be no need to mention instance
names as well.
Note again that upwards name referencing allows you to reference the module name
even though
it is explicitly instanciated with different names. That reference to the module
name is not referencing
an additional, implicit instance with the same name as the module. On the
contrary, it simultaneously references all the instances of that module together.
That same mechanism allows referencing top-level modules with requiring an
implicit instance with the same name as the module.
Again, it can be implemented that way, but it does not have to be.
Since with respect to the top-level modules, the functionality is equivalent, you
can in SV go in that direction without breaking compatibility with 1364, but
don't say that that is what 1364 says. Also remember that you will still have to
allow upwards name referencing by module name, not just by instance name.
Dave Rich wrote:
> 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
-- 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
This archive was generated by hypermail 2b28 : Thu Jul 10 2003 - 02:03:48 PDT