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

1. Instantation tree is not defined within LRM, while $root usage is defined
as:
hierarchical_identifier ::= [ $root . ] { identifier constant_bit_select . }
identifier

and

type_identifier ::= identifier

so from both above I can say that 

$root.TYPE_IDENTIFIER 

is  ok

2. lets stay close to an example can you give me one. Does it deal with some
separate compilation ambiguity or it works only in single compilation scope?


  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Tuesday, November 06, 2007 1:53 PM
To: danielm; sv-ec@server.eda.org
Subject: 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  <http://www.mailscanner.info/> MailScanner, 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  <http://www.mailscanner.info/> MailScanner, 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.