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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Sep 11 2006 - 10:50:00 PDT
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
Received on Mon Sep 11 10:50:05 2006

This archive was generated by hypermail 2.1.8 : Mon Sep 11 2006 - 10:50:16 PDT