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

I can't accept Dave's position. As Daniel has quoted,
 
"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."

and also

"Once a name is used to define a module, primitive, program, or
interface within one compilation unit, the name shall not be used again
(in any compilation unit) to declare another non-nested module,
primitive, program, or interface outside all other declarations."

I think the LRM is as explicit as it can be that you cannot elaborate
together one or more compilation units that contain two package
declarations with the same name or two module declarations with the same
name.

(Though how that squares with the use of configurations to select
different versions of the same module for different instantiations is a
question I've never gotten an answer to, and there is also an open
Mantis on that issue.)

Regarding overriding std, I agree that it is not allowed. However, I
don't think it is obvious from the LRM, and therefore I think it needs
to be more explicit. In fact, using the reverse of Dave's logic, I could
claim that since in other places, the LRM bothers to explicitly forbid
overriding of a name, then it implicitly implies that it *is* allowed
where such a statement does not appear.

Shalom

 

________________________________

	From: Daniel Mlynek [mailto:daniel.mlynek@aldec.com] 
	Sent: Thursday, July 17, 2008 10:06 AM
	To: 'Rich, Dave'; Bresticker, Shalom; sv-bc@server.eda-stds.org
	Cc: 'Sergei Zaychenko'
	Subject: RE: [sv-bc] package vs packge ; package vs module
override issues
	
	
	>[DR] std is a built-in package and cannot be overridden. It is
not a reserved keyword, but just like any other built-in name, you
cannot override a built-in name within the namespace it is defined. 

	>You should be able to extend the classes defined in std.
However there is no way represent the mailbox class using SV syntax
(mantis 1714) or the presence of arguments to randomize.

	>[DR] This is a tool issue. In a separate compilation model, how
does one distinguish between two compilation units, and a re-compilation
of the same unit?

	 

	The idea in LRM is rather clear that it should be forbidden - if
it cannot be implemented - as you claim then maybe it should be changed
- and overriding described in this place:
	"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."

	The issue commes when we have:
	1st compilation:
	package p;
	 int a;
	endpackage
	module top;
	    initial $display(p::a);
	
	    initial $display(p::r);// this would be visible after 2nd
compilation - but here should trigger syntax - unknown 
	endmodule
	 
	
	2nd compilation:
	package p;
	 int r;
	endpackage //after this was compiled p gets overriden and there
is no more p::a in the design - elaboration failure?
	module top1;
	    initial $display(p::r);
	endmodule
	 
	 
	DANiel

________________________________

	From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
	Sent: 16 lipca 2008 21:28
	To: Bresticker, Shalom; Daniel Mlynek; sv-bc@server.eda-stds.org
	Cc: Sergei Zaychenko
	Subject: RE: [sv-bc] package vs packge ; package vs module
override issues
	
	

		 

		 

		ISSUE 111111111111111111111111111111:

		1st compilation unit:

		    package p;
		        int a=1;
		    endpackage

		2st compilation unit

		    package p;
		        int a=2;
		    endmodule[DR]  endpackage - right?

		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?

		[DR] Yes, the second package declaration should override
the first; same as for modules. But if there were any compilation units
in between 1st and 2nd that imported package p, those would need to get
re-compiled, like in VHDL.

		 

		 

		[SB] If it is the same as for modules, it is illegal.
You can't compile two modules with the same name.[DR] This is a tool
issue. In a separate compilation model, how does one distinguish between
two compilation units, and a re-compilation of the same unit?

		 

		 

		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 availed?

		[DR] std is a built-in package and cannot be overridden.
It is not a reserved keyword, but just like any other built-in name, you
cannot override a built-in name within the namespace it is defined. You
should be able to extend the classes defined in std. However there is no
way represent the mailbox class using SV syntax (mantis 1714) or the
presence of arguments to randomize.

		
		[SB] This is not clear. For example, you can override
built-in system tasks and functions by defining them in the PLI.[DR]
That is allowed because it is explicitly defined. There is no mechanism
defined for methods and packages. Whether it *should* be allowed may not
be clear, but it's clear to be that it is currently not allowed since
there is no mechanism to do so.

		Shalom 

	
---------------------------------------------------------------------
	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.