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 <mailto:fm@cadence.com>
To: 'Sv-Bc' <mailto:sv-bc@eda.org>
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 07:57:16 2004