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.

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