Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Thu Jun 19 2003 - 08:55:38 PDT
This mail bounced...
K
> >From owner-sv-bc Wed Jun 18 23:02:48 2003
>Received: from sccrmhc12.attbi.com (sccrmhc12.comcast.net [204.127.202.56])
> by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id
> h5J62kFr012534
> for <sv-bc@eda.org>; Wed, 18 Jun 2003 23:02:48 -0700 (PDT)
>Received: from grfx.com
>(12-235-192-62.client.attbi.com[12.235.192.62](untrusted sender))
> by attbi.com (sccrmhc12) with ESMTP
> id <20030619060244012004um02e>; Thu, 19 Jun 2003 06:02:45 +0000
>Received: (from dkc@localhost)
> by grfx.com (8.11.6+Sun/8.11.6) id h5J5sR306846;
> Wed, 18 Jun 2003 22:54:27 -0700 (PDT)
>Date: Wed, 18 Jun 2003 22:54:27 -0700 (PDT)
>From: Kevin Cameron <dkc@grfx.com>
>Message-Id: <200306190554.h5J5sR306846@grfx.com>
>To: sv-bc@server.eda.org
>Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
>Cc: krolnik@lsil.com, ram@model.com
>X-Sun-Charset: US-ASCII
>
> > From: Randy Misustin <ram@model.com>
> >
> > Hi Adam,
> >
> > Adam Krolnik wrote:
> >
> > > Hi Randy;
> > >
> > > On the surface, namespaces look like modules. It may be helpful in
> > > analyzing
> > > this to see a comparison between modules and namespaces.
> >
> > Yeah, this certainly occurred to me many times while putting the
> > proposal together. The main distinction, in the end, is that namespaces
> > are a vehicle intended to allow sharing without occupying a place in the
> > hierarchy. Modules occupy hierarchy. It seems a historical hack that
> > one might use secondary toplevel modules to achieve this effect in
> > classic Verilog and, I would imagine, is what led to the use of $root as
> > a repository for declarations in Superlog/SystemVerilog (which is what
> > I'm trying to fix with this proposal).
> >
> >
> > I was trying to provide a scope from which to import symbols. If one
> > wishes to substitute a module for this usage, then one would presumably
> > import a hierarchical path rather than the name of a declarative region.
> > The notion of importing the symbols from one hierarchical region into
> > another is abhorrent (at least to me). This all led me to want the
> > target of the import to be something different than anything that exists
> > today in Verilog.
>
>I would have thought that you would use '::' and '.' to specify a type path
>and an instance/hierarchical path (respectively), so there wouldn't be
>confusion. E.g.:
>
> module foo;
> module bar;
> ...
> endmodule
> bar;
> endmodule
>
>foo::bar is a module declaration, foo.bar is a module instance, so you could
>say something like -
>
> module my_top;
>
> foo::bar b1;
>
>or
>
> module my_top;
>
> import foo;
>
> bar b1;
>
>
>I think a more explicit mechanism for setting the top modules in the
>instance hierarchy might help too.
>
>Kev.
>
> > > You also write that import statements outside a module or scope will
> > > affect subsequent
> > > module or interface scopes.
> > >
> > > Do import statements only have file scope? Or could one import
> > > something for the first
> > > file and have subsequent files obtain the effects of the import?
> >
> > I didn't give this a lot of thought, but my thinking at the time was
> > that it would simply affect the next module/macromodule/interface and
> > not all modules in a file or compilation unit.
> >
> > > I presume they have file scope. Thus for files with multiple modules
> > > one import is
> > > sufficient.
> > >
> > > For the import statement, why would it be necessary to say
> > >
> > > import Myspace.*;
> > >
> > > Other languages (such as Perl) only require reference to the name to
> > > import all
> > > the definitions:
> > >
> > > use Getopt::Long; # Get all definitions
> > >
> > > import Complex; // Get all verilog complex math functions.
> >
> > I'm not too hung up on ".*". I modeled it somewhat on VHDL ("use
> > lib.pkg.all;'") but without the addtional keyword.
> >
> > > Can one import a wire/net declared in the namespace? What does this
> > > mean? a wire
> > > that is shared by all modules importing it? What does it mean if you
> > > import a
> > > wire but are not in a module scope? in a named scope?
> >
> > Yeah, I wanted to allow importing of a wire/net. My sense is that the
> > wire/net/variable "live" in the namespace. Importing simply provides
> > convenient visibility of these objects in the local scope (an alias?).
> >
> > -randy.
> >
> > > Thanks.
> > >
> > > Adam Krolnik
> > > Verification Mgr.
> > > LSI Logic Corp.
> > > Plano TX. 75074
> >
> >
> >
This archive was generated by hypermail 2b28 : Thu Jun 19 2003 - 08:58:36 PDT