Re: [sv-ec] scoping rules for classes

Francoise Martinolle wrote:

> 1) Have we settled the scoping rules for classes?
> I have an example of a parameterized class extending from a base class 
> specialization. The base class specialization
> uses a parameter declared in the derived class declaration. Is that legal?

Yes

> The main question is which scope is the parser currently in, when it 
> tries to resolve
> symbols appearing in the extends. Are we in the scope of class d? or are 
> we in the scope of the module because
> it has encountered the closing parenthesis of the parameter port list. 
> Is the scope of class d defined at that point even though
> we have not reached the ;
>  
>  
> module m;
> class c (parameter int p = 1);
> endclass
> 
> class d #(parameter int q = 2) extends c#(q);
> endclass
> 
> d #(3) handle;
> endmodule
> 
> If that is legal, then it is like having the extends "inside the class 
> declaration immediately after the parameter port list?


Kind of.

There are two aspects here -- the parameters and the types
being specialized.

The parameter values (or parameter types) can be used in
describing the relationship to the base class, but since
the *type* of the specialization is under construction,
you can't refer to inherited members yet since the
inheritance relationship is being constructed.

So, the meaning of:
    class d #(parameter int q = 2) extends c#(q);
is "set parameter q; create a type c#(2); create a type
d#(2) extends c#(2)".


> That means that the symbol q is first attempted to be resolved inside 
> the class decl for d.

Not quite -- you only look at the parameters of the
parameterized class.

> The parameter declaration of q would hide any previous parameter 
> declaration.
>  
> 2)Can you use a scoped class parameter?

Addressing this requires great care in understanding when
you are talking about a *type* and when you aren't.

> class d #(parameter int q = 2, int p = c#(q) :: p);

This is Ok.  In order to determine the default value for
"p", we need to compute the type c#(q). So the elaboration
does that (if that type doesn't exist yet) and then finds
the value of p within that type.  c#(q) must fully
exist as a type for the "::" to make sense.

> or class d #(parameter int q = 2, int p = d#(q)::q);  // refers to its 
> own specialization

This would be a cyclic value dependency if one ever did a
specialization of, say, d#(2).

In order to determine the default for "p" the elaboration would
be required to construct the *type* d#(q).  Substituting in
for "q", you'd be required to compute the *type* d#(2).  No
such type yet exists so you have to construct it.  This leads
to an infinite dependency.  Theoretically in some cases one
might be able to argue that you could find a fixed point of the
implied type relationships, but that is a bit much to require
I think.  I consider this to be an invalid cyclical type
dependency causing an elaboration error.

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