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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Tue Jan 22 2008 - 08:27:20 PST
Daniel,

I do not agree that $unit::top.a is legal.

A module (or its implicit instantiation) is not part of the
$unit scope, it is part of the global instance tree and/or
module definition space.  Saying that $unit::top.a is legal would
imply that you could have two different files each with a *module*
(instance) named "top" and have those be distinct.  That isn't valid.

Module names and/or implicit instances are NOT in the $unit
name space.  Please see 3.11(c) in 2008 draft 4 -- modules
and/or instances are not part of the $unit name space.


Gord.


danielm wrote:
> Doug , regarding to LRM I can do the same as in yours  example by usig $unit
> (in single compilation scope ofcource) since hier paths are allowed after
> $unit. I must say that I was a bbit suprosed by this fact that thi is
> allowed to use hier paths. 
> 
>  
> module top;
>     logic a = 1'b0;
>     bottom top();
>     initial begin
>         $display("top.a = %b", top.a);                // Should print 1
>         $display("$root.top.a = %b", $unit::top.a);    // Should print 0
> <<<<<<<<<<<<<<<here
>     end
> endmodule
> 
> module bottom;
>     logic a = 1'b1;
> endmodule
> 
> 
> So the diffs between $root and $path are:
> 1.$unit can reference to everything what is allowed for $root but the
> reference is resolved in current compilation scope:	
> 2.$root can reference to all indentifiers which may be referenced
> hierarhically (same as $unit but types, classes definition?) - identifiers
> are resolved globally
> 
> LRM allows also strange case:
> 
> $unit::$root.top.a  //<<<<<<<<<<<here
> 
> 
> DANiel
> 
> -----Original Message-----
> From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
> Sent: Tuesday, November 06, 2007 8:16 PM
> To: Steven Sharp; Vreugdenhil, Gordon; danielm@aldec.com.pl;
> Mark.Hartoog@synopsys.com
> Cc: shalom.bresticker@intel.com; sv-ec@server.eda.org
> Subject: RE: [sv-ec] $root vs $unit
> 
> There is still at least one use for $root:
> Disambiguating names during upward searches.
> 
> module top;
>     logic a = 1'b0;
>     bottom top();
>     initial begin
>         $display("top.a = %b", top.a);                // Should print 1
>         $display("$root.top.a = %b", $root.top.a);    // Should print 0
>     end
> endmodule
> 
> module bottom;
>     logic a = 1'b1;
> endmodule
> 
> Regards,
> Doug
> 
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
> Behalf Of Steven Sharp
> Sent: Tuesday, November 06, 2007 10:43 AM
> To: Vreugdenhil, Gordon; danielm@aldec.com.pl; Mark.Hartoog@synopsys.com
> Cc: shalom.bresticker@intel.com; sv-ec@server.eda.org
> Subject: RE: [sv-ec] $root vs $unit
> 
> 
>> As Gord indicates $root.<typeName> is illegal in P1800.
> 
> The illegality goes beyond the fact that hierarchical names are not allowed
> in type references.  It would also be illegal to have $root.<varName>.  The
> LRM says that $root can be added to the front of a hiearchical name.  But a
> hierarchical name must start with a scope (which would have to be a
> top-level instance in this case).
> 
> I don't think I have ever seen this pointed out before, but it follows from
> the LRM text, and neatly avoids a problem.
> 
> As Shalom pointed out, $root.<identifier> could be ambiguous if the same
> identifier name appears in multiple $units.  However, this is not a legal
> hierarchical name unless <identifier> is a top-level instance.  Since
> top-level instance names must be unique, the problem is avoided.
> 
> So the old meaning of $root to talk about things in the top-level scope is
> completely gone, replaced by $unit.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, 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.
Received on Tue Jan 22 08:29:22 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 22 2008 - 08:29:31 PST