Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Wed Jun 18 2003 - 12:30:39 PDT
Another issue that would need to be clarified in terms of implicit
name inclusion (the .* form or equivalent) is whether the existence
of multiple implicit homographs hides all of them or whether you would
still permit bindings to the first implicit name based on order
of inclusion. Reasonable arguments can be made for each side. I
think that VHDL requires hiding of all such homographs (it's been
a while so please correct me if I'm wrong on that).
Jay, another option is to disallow the "global" imports and
have imports bind to just module scopes. This would then
require redundant imports so I don't know if that is a
reasonable choice.
Gord.
Jay Lawrence wrote:
>
> I agree with Kevin and Adam in that I don't see a difference between a
> namespace and top-level module. The interesting part of this proposal is
> the 'import' statement that allows visibility without an explicit
> hierarchical name.
>
> It appears that to do this in Verilog however, you would have to add the
> concept of order of compilation and dependancies between modules. Even
> for a guy with a VHDL background like me, this is a really really scary
> addition to Verilog. For instance, what is the requirements on search
> order when someone uses a -y/-v command line switch or `uselib to bring
> in a whole library?
>
> The other choice of course is to not require validation of the import at
> compile time and defer it to elaboration. This would mean that any
> module that has an 'import' could have any names in it and you wouldn't
> produce an error until elaboration.
>
> Jay
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> > -----Original Message-----
> > From: Kevin Cameron [mailto:sv-xx@grfx.com]
> > Sent: Wednesday, June 18, 2003 1:29 PM
> > To: sv-bc@eda.org
> > Cc: ram@model.com; krolnik@lsil.com
> > Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
> >
> >
> > > From: Adam Krolnik <krolnik@lsil.com>
> > >
> > > Hi Randy;
> > >
> > > On the surface, namespaces look like modules. It may be
> > helpful in analyzing
> > > this to see a comparison between modules and namespaces.
> >
> > Good point. What is the difference between nesting in a
> > module and nesting
> > in a namespace? - personally I didn't think the module
> > nesting was particularly
> > functional, maybe if you add the namespace semantics it will
> > work sensibly
> > [without anther keyword :-) ].
> >
> > > 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 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.
> >
> > An import statement in Perl would cause the interpreter to go
> > find the module
> > and load it - what's the implication for SV? - are you
> > assuming the namespace
> > is already defined (in a header)?
> >
> > Kev.
> >
> > > 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?
> > >
> > >
> > > Thanks.
> > >
> > > Adam Krolnik
> > > Verification Mgr.
> > > LSI Logic Corp.
> > > Plano TX. 75074
> > >
> >
> >
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2b28 : Wed Jun 18 2003 - 12:32:17 PDT