Hi Gord, I believe you missed the point that Logie was trying to make. His point is that C++ users have access to libraries. In SystemVerilog, the closest thing to a C library is a package. And while it is true that a #include defines the symbols to the compiler, users do not need to be aware from which library the symbols will ultimately be imported. This is the benefit that re-importing identifiers from a package will add. In particular I'm thinking of this scenario: a package "A" defines a class that is subsequently extended by package "B". Then, the end-user should only be required to import package "B" to have full access to the class, otherwise packages will be largely useless as re-usable items. I believe there's no disagreement as to the benefit of re-imported identifiers, the only issue is what should be the mechanism for allowing them. Arturo -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil Sent: Monday, September 11, 2006 8:51 AM To: Logie Ramachandran Cc: Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org Subject: [sv-ec] Re: [sv-bc] Name resolution and imports Logie Ramachandran wrote: > Hi Gordon, > [...] > 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. I think you are confusing include and import. Please take a look at C++ "use" of a namespace. That is what should be analogous to an SV import (and is analogous to a VHDL use). The intent and mechanism of an import and an include are very different; trying to think of them in the same manner is not the right approach. Gord. > > 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.comReceived on Mon Sep 11 10:39:37 2006
This archive was generated by hypermail 2.1.8 : Mon Sep 11 2006 - 10:39:52 PDT