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
> 
>