Re: [sv-bc] $root question

I am saying all those thing, namely:

- $root.p (where p is a package) is not legal.
- $root.p is not needed to disambiguate a package name from a
   scope because packages live in their own namespace and are
   accessed using the :: operator.
- A package is not a scope. Your example is illegal for two reasons:
    1) The only operations defined on a package p are "import p::..." and
        package references "p::..." . The use of p by itself (without the ::) is
        not defined.
    2) Tools may remove unused elements from a package, so that a
        $dumpvars on a package as you are suggesting is not defined.
    3) The expression $root.p refers to a top-level instance named p, not to
        a package p.

In general a scope p and package p do not collide. For example:
            
        initial begin: p
           bit a;
           $write(p.a); // scope p
           $write(p::a); // package p
        end

Also, your statement defining packages is inaccurate. The LRM does not
define packages as being top-level instances. In particular, there may exist
a top-level instance with the same name as a package, and that is valid. For
example:

    module p;
        reg r;
    endmodule

    package p;
        reg r;
    endpackage

    module other;
        initial $display( $root.p.r ); // this is module instance p, not package p.
    endmodule;

    Arturo

----- Original Message -----
From: Francoise Martinolle
To: 'Arturo Salz' ; 'Francoise Martinolle' ; 'Sv-Bc'
Sent: Monday, November 08, 2004 7:57 AM
Subject: RE: [sv-bc] $root question

Your response states that packages are not part of the instantiation hierarchy.
This can be argued, in my opinion, for each package that is used, there is a single instance
and it is a top level instance which does not contain any sub-hierarchy.
Any package is elaborated and therefore instantiated, but it always results in a single
instance.

I am not sure I understand what you say. Are you saying that $root.p where p is a package
name is legal? Are you saying that there is no need for $root to be able to refer to
a package name or item declared in a package as someone can refer to it already
with p::i?

The rational for $root was to be able to indicate that the path starts at the root of the instantiation
hierarchy and can be used to hide some local symbols which would have been picked up
by verilog upward search.
For ex, certain system tasks take a scope as an argument, we may find it useful to be able to
disambiguate between a package name and a local scope name.

initial begin: p
   $dumpvars(p, ...); // scope p
   $dumpvars($root.p, ...); // package p
end

Francoise
       '

------------------------------------------------------------------------------
  From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Arturo Salz
  Sent: Friday, November 05, 2004 2:16 PM
  To: Francoise Martinolle; 'Sv-Bc'
  Subject: Re: [sv-bc] $root question

  Francoise,

  Note that $root followed by a package name is essentially a hierarchical reference
  to the package. The reason is that $root is the root of the instantiation hierarchy, thus
  $root.p amounts to a hierarchical reference.
  Packages live in their own namesapce, and are accessed using the :: operator, thus,
  the only object that could collide with a package is a class declaration of the same
  name. And, in that case, the package can be disambiguated by using the import
  statement, which is not allowed for classes. Both class declarations and packages are
  part of the declaration hierarchy. And, even though actual variables within packages must
  be instantiated somewhere, the packages are not part of the instantiation hierarchy. I find
  it useful to think of :: as giving access into the declaration hierarchy, whereas . (among
  other things) gives access to the instantiation hierarchy.

      Arturo

  ----- Original Message -----
  From: Francoise Martinolle
  To: 'Sv-Bc'
  Sent: Friday, November 05, 2004 7:37 AM
  Subject: [sv-bc] $root question

  Can $root be followed by a package name?
  The bnf syntax does not seem to allow something like:

  $root.p::i

  BNF is:
  hierarchical_identifier ::= [ $root . ] { identifier { [ constant_expression ] } . } identifier

  But it seems to allow $root.p where p is the name of a package.

  The description of $root in 18.4 does not provide any restriction on the type of top level instance.
  A package is a top level instance, so does it mean that $root.p should be legal and so $root.p::i?
  If not, we may want to add a note in section 18.4.

  For the same rational as in 18.4, $root.p can be useful to distinguish a package p from a locally declared item
  p in the scope.

  Section 18.4 is as follows:

  The name $root is added 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. In Verilog, 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). Verilog addresses that ambiguity by giving priority

  to the local scope, 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.
Received on Mon Nov 8 10:32:39 2004