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

Please see 1800-2005 4.9:

    User-defined type identifiers have the same scoping rules as data identifiers,
    except that hierarchical reference to type identifiers shall not be allowed.

As in all programming languages, even though something is syntactically
derivable, it may not be semantically legal.

So $root.type_name is not legal.


I don't know what you mean by $unit ambiguity.  There isn't any that
I know of.  Can you give an example of what you consider to be
ambiguous?

Originally you said:

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

There is no "override" going on.

The "T v;" declaration refers to "reg" as does "$unit::T v".

Each compilation unit is a distinct name space and there is no mechanism
to have visibility across different $unit contexts.

Gord.




danielm wrote:
> 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 *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 <http://www.mailscanner.info/>**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.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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