RE: [sv-ec] classes questions

Gord,

I agree with most of what you wrote. But, I disagree with your last
statement:

Given the declaration:

    class C #(int p = 1);
       static int x = p;
    endclass

Then C::x does indeed mean "the x in the type created by the default
specialization". Otherwise, what's the point of providing a default
parameter? 
Why would you allow 
	typedef C xyz;	// this does mean the default specialization
But not allow C::x ? 
BTW, what about the form "C()::x"? That is very clear that it means the
default specialization.

Another question regarding this is:

    class D #(int p = 1);
       enum Bool { FALSE, TRUE = p };
    endclass

Would you disallow "D::Bool" , but allow "typedef X D::Bool" ?

I would agree with your assessment if Brad's proposal to omit default
types passes and the parameterized class were written with no default.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Friday, October 13, 2006 1:34 PM
To: Francoise Martinolle
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] classes questions



Francoise Martinolle wrote:

> I have a few questions related to classes.
>  
> Should default class specializations be elaborated. or not? 

No.  In general it is going to be hard to tell whether one
does or doesn't elaborate an unused specialization but
it would be visible under various other tools and/or vpi
access.

If a user uses the parameterized class as a type, a specialization
must be created, but it must not exist if the default is never used.

For example:
    class C #(int p = 1);
    endclass

    class D #(int p = 1);
    endclass

    C#(5) c;
    D d;

Here we end up with exactly two types -- C specialized with
the value 5 and D specialized with its default value, 1.

 > If a default
> class exists, should I be able to
> look at the value of its static members?

Immaterial due to the above.


> Should the content of a generic class be legal. For example, the class

> could have a parameter that is a type parameter.
> That type parameter could have a default of logic. Can you use the
type 
> parameter to declare a object and then
> use some syntax that is not valid if the type is logic but will be
valid 
> for all class specializations?

>  
> For ex:
>  
> class C #( parameter type t = logic);
> T m1;
> task t;
>  begin
>     m1.a = 0;
>  end
> endtask
> endclass
>  
> However if I create a specialization of that class as:
> typedef struct {logic a, b} ustruct;
> C#( ustruct ) ch;


Certainly this is legal.

This is similar to doing the following:

    module M #(parameter type T = int);
       T foo;
       initial foo.a = 0;
    endmodule

It is only the elaboration of the module (or class) that causes
a particular set of type and operation relationships to be
legal or illegal.  One cannot make any assumptions about the
nature of a type parameter until a specialization (or
instantiation for design units) occurs.


> Can you refer to a covergroup declared inside a class using the 
> scope_operator?

You can if it is a class **type**.  The point is that parameterized
class aren't *types*, they are really only type "factories" or
"templates" or whatever term you want to use.

So, given something like:
    class C #(int p = 1);
       static int x = p;
    endclass

It is nonsensical to refer to C::x since there is no such thing.
There are as many static "x" variables as there are specializations
of C (potentially none).

You can do something like:
    typedef C#(2) C_2;
or even
    typedef C C_default;
and then refer to C_2::x or C_default::x, but there is no
singular item of C::x.

The same argument applies to types, covergroups, etc. within
a parameterized class.


One could argue that C::x should be interpreted to mean
"the x in the type created by the default specialization" but
that can get pretty confusing to users.  In Questa, we've decided
to not adopt that interpretation at this point but could be
convinced that such an interpretation would be reasonable.


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