You are correct in that simple case, but, consider the following example package p1; class base; int x; virtual function void F(base x); ... endfunction endclass endpackage package p2; class derived extends p1::base; int y; endclass endpackage module top; import p2::*; class p3 extends derived; virtual function void F(base x); // this is not legal without the re-import ... endfunction ... endmdodule In this case, the base class is not visible to the importing scope without explicitly importing package p1. Or is it? Why should end-users need to add an explicit import of p1 (import p1::*) or explicitly write (p1::base)? Arturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Monday, September 11, 2006 10:50 AM To: Arturo Salz Cc: Logie Ramachandran; Mark Hartoog; SV_BC List; SV_EC List; sv-ac@verilog.org Subject: Re: [sv-ec] Re: [sv-bc] Name resolution and imports Arturo Salz wrote: > 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. But that isn't an issue. If you have: package p1; class base; int x; endclass endpackage package p2; import p1::*; class derived extends base; int y; endclass endpackage module top; import p2::*; derived d = new; initial begin d.x = 1; d.y = 2; end endmdodule There is absolutely no requirement for "top" in import p1 unless the user wanted to *declare* something of type p1::base. Gord. > 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:59:42 2006
This archive was generated by hypermail 2.1.8 : Mon Sep 11 2006 - 10:59:49 PDT