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