Re: [sv-ec] classes questions

In Mantis item
http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000907 I've
suggested that default parameter assignments should be optional.

Here's the description 
----------------------

In a parameter declaration it ought to be possible to omit the default
assignment, forcing any instance to choose an explict value or type for
it. There may not even be a sensible default value or type.

It ought to be allowed to write

   module test #(N, type T) ...

instead of something arbitrary like

   module test #(N=0, type T=logic) ...

Subroutines don't require default values for their arguments, why should
modules require default assignments for their parameters?

In A.2.4, it should be

   param_assignment ::= parameter_identifier { unpacked_dimension } [ =
constant_param_expression ]

   type_assignment ::= type_identifier [ = data_type ]

-- Brad

-----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