RE: [sv-ec] $root vs $unit

1. The LRM says,
The name $root is used to unambiguously refer to a top-level instance or
to an instance path starting from

the root of the instantiation tree. $root is the root of the
instantiation tree.

For example:

$root.A.B // item B within top instance A

$root.A.B.C // item C within instance B within instance A

$root allows explicit access to the top of the instantiation tree. This
is useful to disambiguate a local path

(which takes precedence) from the rooted path. If $root is not
specified, a hierarchical path is ambiguous.

For example, A.B.C can mean the local A.B.C or the top-level A.B.C
(assuming there is an instance A that

contains an instance B at both the top level and in the current module).
The ambiguity is resolved by giving

priority to the local scope and thereby preventing access to the
top-level path. $root allows explicit access

to the top level in those cases in which the name of the top-level
module is insufficient to uniquely identify

the path.

T is not within the instantiation tree.
 
2. $unit refers to the local compilation unit. If you compile together
into the same compilation unit the two typedef declarations, then the
second will generate an error because you are redeclaring T within the
same compilation unit.
 
If the two compilations are to different compilation units, then only
the second declaration of T will be seen by the code that follows.
 
Why use $unit? 
 
For example, for declarations that you want to be available to more than
one design element within the compilation unit, a common typedef for
example.
 
This avoids naming collisions with declarations within other compilation
units.
 
Shalom
 


________________________________

	From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of danielm
	Sent: Tuesday, November 06, 2007 2:36 PM
	To: Bresticker, Shalom; sv-ec@server.eda.org
	Subject: RE: [sv-ec] $root vs $unit
	
	
	1. I've checked the LRM and I cannot find any statement
forbidding $root.T
	 
	2.about $unit:: you claim that I can do for example :
	 
	1st compilation:
	  typedef int T;
	2nd compilation
	  typedef reg T;
	  T v; //this will be int?
	  $unit::T v; //this will be reg?
	 
	2nd compilation to the same lib for sure override T from 1st
one. What is the sens of using $unit?
	 
	 
	DANiel
	
	
________________________________

	From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
	Sent: Tuesday, November 06, 2007 12:57 PM
	To: danielm; sv-ec@server.eda.org
	Subject: RE: [sv-ec] $root vs $unit
	
	
	I don't think $root.T is legal. 
	T exists in $unit, not $root.
	Consider what would happen if T were defined in two different
compilation units. $unit always refers to the local compilation unit,
but what would $root.T refer to? There are two different T's.
	 
	Shalom


________________________________

		From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of danielm
		Sent: Tuesday, November 06, 2007 12:43 PM
		To: sv-ec@server.eda.org
		Subject: [sv-ec] $root vs $unit
		
		
		What is the diff between $root and $unit ie in below
case.
		What should be the types of a,b,c.
		 
		typedef reg T;
		module top;
		 typedef int T;
		 typedef $root.T T1;
		
		 typedef $unit::T T2;
		 
		 T a;
		 T1 b;
		 T2 c;
		endomdule
		 
		 
		DANiel

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