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.comReceived on Mon Sep 11 07:55:03 2006
This archive was generated by hypermail 2.1.8 : Mon Sep 11 2006 - 07:55:14 PDT