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

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Wed Jul 16 2008 - 02:26:14 PDT
Yes, that issue is mentioned in Mantis 1214. I don't know whether the
issue was ever resolved, but the Mantis is still open.
 
Thanks,
Shalom


________________________________

	From: Daniel Mlynek [mailto:daniel.mlynek@aldec.com] 
	Sent: Wednesday, July 16, 2008 12:21 PM
	To: Bresticker, Shalom; 'Surya Pratik Saha'
	Cc: sv-bc@eda.org; 'Sergei Zaychenko'
	Subject: RE: [sv-bc] package vs packge ; package vs module
override issues
	
	
	Yes, but LRM allows to use :: for both class and package and put
both into different name spaces - what are the searching rules for case
like below - I cannot find them neither in compilation unit scope
chapter neither in scope rules chapter
	 
	
	
	package P;
	    typedef reg T;
	endpackage
	 
	
	class P;
	    typedef reg T;
	endclass
	 
	module M;
	    P::T r; // which definition is referred here ? is there any
way to refer the other one in such situation ?
	endmodule
	 
	 
	DANiel

________________________________

	From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
	Sent: 16 lipca 2008 11:12
	To: Surya Pratik Saha
	Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko
	Subject: 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.

---------------------------------------------------------------------
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.
Received on Wed Jul 16 02:27:09 2008

This archive was generated by hypermail 2.1.8 : Wed Jul 16 2008 - 02:30:56 PDT