RE: [sv-bc] Name resolution and imports

Hi Logie,

The end user does not and should not need to import all the packages
that an IP Vendor used IP vendor used. They only need to import the
packages that they intent to use themselves. If they need to import
48bitPackage::type48bit to in order use the IP, then they are users of
48bitPackage::type48bit themselves.

Also, the way I have seen IP developers structure their code is a s
follows

package IP_VendorA;
`include "this_stuff.sv"
`include "that_stuff.sv"
endpackage


A package does not have to be a replacement for the include file
mechanism, and they can be used together effectively.


Dave


> -----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 7:41 AM
> To: Mark Hartoog; Vreugdenhil, Gordon; SV_BC List; SV_EC List; sv-
> ac@server.verilog.org
> Subject: RE: [sv-bc] Name resolution and imports
> 
> 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
> >
> >
>