Re: [sv-bc] Quick scope operator question

Francoise Martinolle wrote:

> I was thinking only for the simpler case where the function can be 
> resolved in the package itself;
>  the package should be self contained. Is the forward simple reference 
> to f still considered a hierarchical reference?

This area is full of issues.  What actually constitutes a
"hierarchical name" versus what in a post long ago I called
a "dotted name".

Simple task and function names (scope names really) are a special case
of names that resolve relatively late and need to be treated
"as though" they were hierarchical.  My approach, outlined in
the algorithm I posted, is that I think that the decision about
whether something is hierarchical should be deferred.  For
example, "f" is not really "hierarchical" if it binds lexically
into $unit.  One could possibly think of it as such, but doing
so would pose issues when determining the relationship between
various compilation units when doing a real (dotted) hierarchical
resolution.

I would prefer that we actually got away from talking about
forward scope references as "hierarchical" and actually started
talking about them as forward references.  That would allow us
to more clearly state what kind of forward references are
permitted and to distinguish in discussions between lexically
bound forward references and hierarchical references that bind
in the elaboration model.  This difference has become significant
in SV and just talking about hierarchical resolution is making
things much harder to reason about.

I consider "p::f()" to be a valid forward reference to a scope
within "p".  I do NOT consider it to really be a "hierarchical
reference".  In the same manner, I would consider other
"dotted names" inside a package to also be valid if they
bind within the package.  For example:
    package p;
        task t1;
           reg x;
        endtask
        task t2;
           reg y;
           y = t1.x;
        endtask
    endpackage

I consider this to be valid (if very bad form).  The
"t1.x" is "hierarchical" in the sense that it is a dotted
name between tasks; it is not "hierarchical" in the sense
that it does not escape the design unit in which it occurs.
I think that the LRM *intended* to require "non-escaping
hierarchical references" when it banned "hierachical
references" from packages.  It is just that there is not
good way in current "LRM speak" to talk about the difference
in a concise manner.


> So, if the function was in another package that is not imported or 
> another design unit, that would be a true hierarchical
> reference and the compiler should not find it.

Right.  In fact, a bare reference to "f" must bind within "p"
since packages have *no* hierarchical relationship to the overall
design.  "Hierarchical reference" is, really, not meaningful
when talking about something within the context of a package since
a package has *no* parent in the hierarchical (instantiation forest)
sense.

Gord.


>  
> 
>     ------------------------------------------------------------------------
>     From: Vreugdenhil, Gordon [mailto:gordon_vreugdenhil@mentor.com]
>     Sent: Wednesday, November 22, 2006 1:01 PM
>     To: Francoise Martinolle; Mark Hartoog
>     Cc: Greg Jaxon; SV_BC List; Vreugdenhil, Gordon
>     Subject: RE: [sv-bc] Quick scope operator question
> 
> 
> 
>     Francoise,
> 
>     It is actually a bit of an interesting question as to whether a
>     "forward" bare reference to "f" should work.  "f" normally
>     resolves only because task/function names are considered
>     to be hierarchical references.  But hierarchical references
>     are not permitted in packages.
> 
>     An amusing side-effect is probably that all task/function
>     calls are illegal within packages..... :-)
> 
>     Gord.
> 
> 
> 
>     -----Original Message-----
>     From: Francoise Martinolle [mailto:fm@cadence.com]
>     Sent: Wed 11/22/2006 9:49 AM
>     To: Mark Hartoog; Vreugdenhil, Gordon
>     Cc: Greg Jaxon; SV_BC List
>     Subject: RE: [sv-bc] Quick scope operator question
> 
> 
>     By extending the existing Verilog rules for function look up in modules
>     to packages
>     if you change p2::f to just f, that will/should work.
> 
>      package p;
>              function int f(int x);
>                  return f2(x);
>               endfunction
>               function f2(int x);
>                  return 1;
>               endfunction
>           endpackage
> 
>     -----Original Message-----
>     From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Mark
>     Hartoog
>     Sent: Tuesday, November 21, 2006 6:02 PM
>     To: Gordon Vreugdenhil; Mark Hartoog
>     Cc: Greg Jaxon; SV_BC List
>     Subject: RE: [sv-bc] Quick scope operator question
> 
> 
>      > So does that mean that you think that:
>      >
>      >      package p;
>      >          function int f(int x);
>      >             return p::f2(x);
>      >          endfunction
>      >          function f2(int x);
>      >             return 1;
>      >          endfunction
>      >      endpackage
>      >
>      > should be an error?
>      >
>      > I don't.
> 
>     I think you could argue this both ways. Verilog designers, who think
>     that functions can be called before they are declared, would expect this
>     to work.
> 
>     In section 4.9 of the LRM it says user defined types can only be
>     referenced before they are defined if they are first declared as a type
>     by an empty typedef.
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com