RE: [sv-bc] $root question

Arturo,
 
thanks for the clarification. Sorry for the delay in responding to this
email, it was hidden by a multitude of
other emails.
I accept the behaviour you state for $root. However, we need to be able to
probe global
elements from a package or global declarations in the compilation unit
space.
There are $system tasks which allow to take a scope as an argument
for ex $scope, $dumpvars, $dumpports.
I understand that you recommend that $scope does not work on a package name.
I can agree with this.
I think that for the probe or dumping system tasks, user may want to only
probe package references which
are being used and you recommend that the variable/net from the package
being listed specificatlly in the
list of variables/nets to be dumped/probed is <p::var_net_name> order to
reduce the amount of unnecessary probing.
That way, if the user wants to probe a certain package net/variable, he
would have to request it and that
would keep the best simulation performance.
 
Is that what you have in mind?
 
Francoise
       '

  _____

From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Monday, November 08, 2004 1:36 PM
To: Francoise Martinolle; 'Sv-Bc'
Subject: 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 <mailto:fm@cadence.com>
To: 'Arturo Salz' <mailto:Arturo.Salz@synopsys.COM> ; 'Francoise
<mailto:fm@gda.Cadence.COM> Martinolle' ; 'Sv-Bc' <mailto:sv-bc@eda.org>
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 <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 22 09:14:16 2004