RE: [sv-bc] Name resolution and imports

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Logie Ramachandran
> Sent: Monday, September 11, 2006 8:29 AM
> To: Vreugdenhil, Gordon; Logie Ramachandran
> Cc: Mark Hartoog; SV_BC List; SV_EC List; sv-ac@server.verilog.org
> Subject: RE: [sv-bc] Name resolution and imports
> 
> Hi Gordon,
> 
> Unfortunately the 1800 standard does not provide for
> differences in interface and implementation as far as
> packages are concerned. The only choice we have today
> is
> a) import everything in a package
[DR>] This is not a currently available option. You can only make
everything candidates for import. You still have to explicitly reference
an identifier that has not been declared in the importing scope for the
import to occur.

> b) import specific things in a package.
> 
> Based on today's available mechanisms we have no other
> choice but to support chaining of imports.
[DR>] Actually, I don't see a thing in the current LRM that excludes
either choice
> 
> If there was a mechanism for forwarding
> a subset of the package items explicity to the next
> level (i.e, interface) then other
> solutions may be possible.  We can certainly discuss
> these ideas but I cant comment on those at this point
> in time.
[DR>] Flexibility is usually better than inflexibility, as long as it
doesn't come at too high a cost.
> 
> If you look at a C++ example,  users are expected to
> #include "systemc.h". Users need
> not worry about the explicit dependencies of
> "systemc.h". No one worries about  what
> #include statements are found in "systemc.h".
> I think this should be analogous for SV packages.
[DR>] again, you are confusing includes an imports.
> 
> Thanks
> 
> Logie.
> 
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Monday, September 11, 2006 7:55 AM
> To: Logie Ramachandran
> Cc: Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org
> Subject: Re: [sv-bc] Name resolution and imports
> 
> 
> There is a difference between *interface* and *implementation*.
> 
> Your assumption is that everything needed for *implementation*
> should be exposed in the *interface*.  That makes for substantial
> problems downstream in large designs since names will tend to
> "leak" through and cause downstream things to break.
> 
> I do think that there needs to be a mechanism for *explicitly*
> forwarding a definition through a package which *explicitly*
> makes it part of the "interface" to the package, but doing that
> by default is going to be chaotic.
> 
> "typedef" already gives us that mechanism for types; it would
> be trivial to do something similar for other declarations.
> 
> Alternatively, I might consider a "local" import which doesn't
> have the troublesome behavior.  I do feel very strongly that
> maintaining a distinction between the interface and implementation
> is crucial.
> 
> One can always come up with examples for which either default
> seems best.  Given that C++ and VHDL have opted for the more
> restrictive default behavior, it also seems more consistent from
> a methodological standpoint to retain consistency.
> 
> Gord.
> 
> 
> 
> Logie Ramachandran wrote:
> > Hi Mark,
> >
> > Thanks for providing the example. For the purposes of this
discussion
> > it would be good to separate out three different kinds of users.
> >
> > 1) Base package providers - could be coming from external
> >                             methodology groups
> > 2) IP provider  -  independent third party IP provider
> > 3) End user -      intending to use the IPs.
> >
> > In your example the first package "mytypes" could  be coming from
> > (1),  the second packaage could be coming from an IP vendor (2)
> > and the module code is written by end user.
> >
> > The IP provider could potentially uses multiple packages
> > from various sources to build his/her IP.  The assumption here is
> > that the IP provider is  amenable to carefully importing the items
> > that are necessary for the functioning of the IP.
> > import 48bitPackage::type48bit;
> > import 36bitPackage::type36bit;
> >
> > However the end user typically does not want to be saddled with all
> > the packages that the IP vendor used. The end user should
> > be able to do a "single import statement" (e.g. import IP::*) and
> > interact with the IP.
> >
> > I think it is a big disadvantage if end users have to worry about
> > and become knowledgeable about all the packages that the IP vendors
> > use.
> >
> > Thanks
> >
> > Logie.
> >
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Mark
> > Hartoog
> > Sent: Saturday, September 09, 2006 1:02 PM
> > To: Gordon Vreugdenhil; SV_BC List; SV_EC List; sv-ac@verilog.org
> > Subject: RE: [sv-bc] Name resolution and imports
> >
> > I have been very busy and not able to comment on this discussion.
> >
> > Several objects have been raised about chaining of package imports.
> One
> > issue is pollution of the name space. I think name space pollution
> > created by wild card package imports is a problem with System
Verilog,
> > but I believe package import chaining reduces name space pollution,
> > because it gives package developers the tools to do something about
> this
> > problem. My assumption is that most Verilog writers will be using
> > wildcard imports. Consider this example without package import
> chaining:
> >
> > package mytypes;
> >   typedef int myint;
> > endpackage
> >
> > package mystuff;
> >   import mytypes::*;
> >   function myint myfunc();
> >        return 0;
> >   endfunction
> > endpackage
> >
> >
> > module mycode();
> > import mytypes::*;
> > import mystuff::*;
> > myint x;
> > initial x = myfunc();
> > endmodule
> >
> > I am assuming here that most engineers will just use wildcard
imports
> on
> > all packages. Because the author of the mycode module was not sure
> what
> > types he might need from the mytypes package in order to use the
> > functions from mystuff, he just wildcard imported all of them. If
> latter
> > on, other types are added to the mytypes package, then they will be
> > available for import into mycode.
> >
> > On the other hand, with package chaining, mycode could be written:
> >
> > module mycode();
> > import mystuff::*;
> > myint x;
> > initial x = myfunc();
> > endmodule
> >
> > Now only the symbols from mytypes that are actually used in mystuff
> are
> > available for import into mycode. If someone adds another type in
> > mytypes that has nothing to do with mystuff, it is not available for
> > import into mycode.
> >
> > I would also add that it is much more likely that the people writing
> > packages can be trained to worry about the dangers of wildcard
imports
> > then it would be to train all engineers to worry about this. I
expect
> > most engineers will be using wildcard imports because that is the
> > easiest thing to do.
> >
> > Another issue about chaining is that it creates alias names, and I
> guess
> > people consider that objectionable. I don't understand this
argument,
> > since System Verilog is already full of aliases. Typedefs and type
> > parameters create aliases for type names already. In fact, package
> > mystuff could just say:
> >
> > typedef mytypes::myint myint;
> >
> > and then it could be written without any import statement. Chaining
of
> > package imports is no different then writing the package like this.
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> >>Behalf Of Gordon Vreugdenhil
> >>Sent: Thursday, August 31, 2006 10:03 AM
> >>To: SV_BC List; SV_EC List; sv-ac@verilog.org
> >>Subject: [sv-bc] Name resolution and imports
> >>
> >>All,
> >>
> >>The name resolution working group has encountered an issue
> >>that needs to be resolved at the committee level.  The issue
> >>is directly addressed by Mantis 1323 -- "are imported names
> >>visible to hierarchical references".  Mentor and Cadence have
> >>both taken the position that they are not; Synopsys has taken
> >>the position that they are.  This needs to be resolved
> >>quickly as implementations have (and will continue) to
> >>diverge.  This also impacts the issue of chained imports (is
> >>a symbol imported into a package available for import) which
> >>is also addressed by Mantis 1323.
> >>
> >>This issue has a direct bearing on back-annotation, pli, and
> >>related issues since it impacts what the system must present
> >>as members of a scope and whether hierarchical names for
> >>items in a design are unique or not.
> >>
> >>Currently Mantis 1323 is listed as a BC issue.  I'd like to
> >>have this issue be resolved asap due to the overall impact of
> >>the interpretation differences.
> >>
> >>Question:  should this immediately be elevated to the
> >>champions level or is it appropriate to leave for SV-BC?
> >>
> >>Independent of that decision, it would be worthwhile for
> >>people to speak to this from various perspectives so that we
> >>can make an informed decision.
> >>
> >>Gord
> >>--
> >>--------------------------------------------------------------------
> >>Gordon Vreugdenhil                                503-685-0808
> >>Model Technology (Mentor Graphics)                gordonv@model.com
> >>
> >>
> >
> >
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com