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

As Gord indicates $root.<typeName> is illegal in P1800.

In System Verilog 3.0/3.1 this was legal. In SV 3.0/3.1 declarations
outside of modules were in $root and you could refer to types in
$root this as $root.<typeName>.

When $unit was introduced to replace $root, a new meaning was attached
to $root as the root of the instance hierarchy. 

Tools may currently have backwards compatibility modes with SV 3.0/3.1
where
they are still accepting $root.<typeName>, but this is now illegal and
should
be changed to $unit::<typeName>. 

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Tuesday, November 06, 2007 6:55 AM
> To: danielm
> Cc: 'Bresticker, Shalom'; sv-ec@eda.org
> Subject: 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.
> 
> 

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