RE: [sv-bc] package vs packge ; package vs module override issues

Why is it a problem? The reference in test is clearly to the module top.
References to contents of top are disambiguated by whether top is
followed by a period or a double colon.
 
Shalom


________________________________

	From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] 
	Sent: Wednesday, July 16, 2008 12:06 PM
	To: Bresticker, Shalom
	Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko
	Subject: Re: [sv-bc] package vs packge ; package vs module
override issues
	
	
	Hi,
	Consider the following case:
	module top;
	endmodule
	
	package top;
	endpackage
	
	module test;
	        top t();
	endmodule
	
	Is it a valid case? I think package and module should share same
name space, LRM needs correction here.
	
	Regards
	Surya


	-------- Original Message  --------
	Subject: Re:[sv-bc] package vs packge ; package vs module
override issues
	From: Bresticker, Shalom <shalom.bresticker@intel.com>
<mailto:shalom.bresticker@intel.com> 
	To: Daniel Mlynek <daniel.mlynek@aldec.com>
<mailto:daniel.mlynek@aldec.com> , sv-bc@eda-stds.org
	Cc: "Sergei Zaychenko" <Sergei.Zaychenko@aldec.com>
<mailto:Sergei.Zaychenko@aldec.com> 
	Date: Wednesday, July 16, 2008 1:40:52 PM
	

		Hi,
		 
		In Draft 6, 3.12 says,
		 
		"The package name space unifies all the package
identifiers defined among all compilation units. Once a name is used to
define a package within one compilation unit, the name shall not be used
again to declare another package within any compilation unit."

		
		So the first case should be illegal.
		 
		Module and package names are in different name spaces,
so I think it is legal to have a package and a module with the same
name.
		 
		The LRM does not explicitly say whether a user-defined
package can have the name std. I would expect it to be illegal.
		 
		Shalom


________________________________

			From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Daniel Mlynek
			Sent: Wednesday, July 16, 2008 10:54 AM
			To: sv-bc@server.eda-stds.org
			Cc: 'Sergei Zaychenko'
			Subject: [sv-bc] package vs packge ; package vs
module override issues
			
			
			I've doubts what should be the bahaviour in
below cases:
			 
			 
			ISSUE 111111111111111111111111111111:
			1st compilation unit:
			    package p;
			        int a=1;
			    endpackage
			2st compilation unit
			    package p;
			        int a=2;
			    endmodule
			
			Above packages compiled in single compilation -
is clearly for me tool dependend, but compiled as shown above? should it
behave the same module overriden in separate compaltion- i mean package
defined in 2nd compilation will override 1st one in whole design?
			 
			ISSUE 222222222222222222222222222222:
			This issue is much more interesting. Package and
module cannot be used in the same cotext because its nature is different
- so maybe it should be allowed in common and separate compilation units
- and in both cases both package p and module p should exist in desing?
			package p;
			int a=1;
			endpackage
			 
			module p;
			int a=2;
			initial $display(p.a, p::a);
			endmodule
			
			 
			ISSUE 333333333333333333333333333333333:
			what about overriding std package - with user
defined module or package with "std" name? rules should be the same as
in above cases?
			so defining package std; should override
predefined std package which will be no longer avaible?

			-- 
			This message has been scanned for viruses and 
			dangerous content by MailScanner
<http://www.mailscanner.info/> , and is 
			believed to be clean. 

	
---------------------------------------------------------------------
		Intel Israel (74) Limited
		
		This e-mail and any attachments may contain confidential
material for
		the sole use of the intended recipient(s). Any review or
distribution
		by others is strictly prohibited. If you are not the
intended
		recipient, please contact the sender and delete all
copies.
		  

		-- 
		This message has been scanned for viruses and 
		dangerous content by MailScanner
<http://www.mailscanner.info/> , and is 
		believed to be clean. 


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.