RE: [sv-ec] Re: [sv-bc] Name resolution and imports

I might disagree that is not legal. Class p3 will get access to the
symbols via the class hierarchy mechanism. It does not need to go
through the package.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Arturo Salz
> Sent: Monday, September 11, 2006 11:00 AM
> To: Vreugdenhil, Gordon; Arturo Salz
> Cc: Logie Ramachandran; Mark Hartoog; SV_BC List; SV_EC List; sv-
> ac@server.verilog.org
> Subject: RE: [sv-ec] Re: [sv-bc] Name resolution and imports
> 
> 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.com