RE: [sv-bc] Hierarchical resolution in nested modules

I still find nested modules very valuable, at least conceptually, as a way
of preventing a module from being instantiated in places it was never
intended to be used.  If I have an IP model with sub-levels of hierarchy, I
only want my IP model to be able to instantiate those sub-modules.  I do not
want some end-user of my IP model deliberately or accidentally directly
instantiating a sub-module without the intended parent-level module.

Regarding can a nested module be instantiated before it is defined, I expect
that to be true.

I also expect a nested module to be able to instantiate nested modules that
were defined in the parent of the nested module.  In other words, if a
nested module instantiates a module, the definition of that module is
searched upwards in the definition space of the nested module(s) prior to
looking in the global module declaration space.

It is too bad the SuperLog simulator is no longer available to use as a
reference simulator for determining the intent and implementability of
constructs that originated with the SuperLog donation.  

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> Sent: Monday, December 03, 2007 11:58 PM
> To: Bresticker, Shalom; Steven Sharp; sv-bc@server.eda.org
> Subject: RE: [sv-bc] Hierarchical resolution in nested modules
> 
> The original intent was that all modules were nested modules, and the
> top level module was called $root. Nested modules were also a way to
> deal with the problems of having a global module namespace in
> Verilog-1995.
> 
> Now that $root has disappeared as a declarative scope, and 
> configuration
> libraries in V2001 have addressed the issues of global module
> namespaces, I see no reason for using nested modules.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On
> > Behalf Of Bresticker, Shalom
> > Sent: Monday, December 03, 2007 10:37 PM
> > To: Steven Sharp; sv-bc@server.eda.org
> > Subject: RE: [sv-bc] Hierarchical resolution in nested modules
> > 
> > I did not found anything about it. Nested modules are from Superlog,
> > though.
> > 
> > I did find another issue about nested modules.
> > 
> > I had asked whether it was legal to instantiate a nested 
> module before
> > its definition.
> > Dave Rich said yes (http://www.eda-stds.org/sv-bc/hm/4854.html).
> Steven
> > Sharp questioned that (http://www.eda-stds.org/sv-bc/hm/4857.html).
> > 
> > I found such an example in the SV 3.1a LRM (Section 18.5):
> > 
> > module m3(...);
> > m1 i1(...); // instantiates the local m1 declared below
> > m2 i4(...); // instantiates m2 - no local declaration
> > module m1(...); ... endmodule // nested module declaration,
> > // m1 module name is in m3's name space
> > endmodule
> > 
> > However, this example was removed in 1800-2005. I don't know why.
> > 
> > Shalom
> > 
> > 
> > 
> > > >It is not even clear from the LRM that it is legal to 
> instantiate a
> > > >nested module from a scope which is lexically nested within
> > > the scope
> > > >where the nested module is declared. I don't object to it,
> > > but the LRM
> > > >does not make it clear that it is allowed.
> > >
> > > An intermediate interpretation of that text would be that it
> > > is legal, but names cannot be bound lexically to the outer
> > > module in that case.
> > >
> > > Whether it is illegal, legal but cannot bind lexically, or
> > > legal but binds from the point of instantiation, the text
> > > does not appear to support Gord's interpretation.
> > >
> > > Does someone know the original intent?
> > 
> ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> > 
> > This e-mail and any attachments may contain confidential 
> material for
> > the sole use of the intended recipient(s). Any review or 
> distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > 
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> > 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.