RE: [sv-ec] forward typedefs

 
How about this :

typedef class c;

module top;

  c#(3) v_pos;   ===> is this legal
  c #(.p(3)) v_named; ===> is this legal
endmodule

class c #(parameter p = 0);
endclass

or would we require an intermediate typedef just like we do for the
example below:

   some_class::T myLocalVar;    // illegal
    typedef some_class::T myT;   // legal


Francoise
    '
-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, November 21, 2008 10:56 AM
To: Mark Hartoog
Cc: Francoise Martinolle; sv-ec@eda.org
Subject: Re: [sv-ec] forward typedefs

Mark, you didn't address the named association -- but if you agree that
the rest that is legal, I'm assuming that you wouldn't want to exclude
that.  It would be pretty irregular to do so.

One edge case (which I think follows directly) is based on the LRM
statement that a forward type is incomplete until the final definition
is seen.  So, for example you can't directly refer to a type within a
forward class using "::" (though we did explicitly allow such references
in a further typedef).
I think that a type defined by a specialization of a forward
parameterized class is also incomplete.

Example:
    typedef c;
    typedef c#(1) some_class;

    some_class::T myLocalVar;    // illegal
    typedef some_class::T myT;   // legal

    class c #(int p = 1);
       typedef bit[p:0] T;
    endclass

myLocalVar is illegal since "some_class" is incomplete until the body of
"c" is defined.

Gord

Mark Hartoog wrote:
> I agree with Gord that your original case should be legal. I also 
> think you can use parameter pass by value and default parameter
values.
> 
> For the case raised by Gord:
> 
>     typedef class c;
>     typedef c d;
>     c c_0; // should be legal
>     d c_1; // Should be legal
>     c #(9) c_2; // should be legal
>     d #(7) c_3; // should be illegal
>     class c #(parameter p = 0); endclass
> 
> You can use a forward typedef to define a new type, but the type 'd' 
> is the class 'c' with default parameter values. You cannot override 
> those parameter values when you use 'd'.
> 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Francoise Martinolle
> Sent: Thursday, November 20, 2008 6:48 PM
> To: Gordon Vreugdenhil
> Cc: sv-ec@eda.org
> Subject: RE: [sv-ec] forward typedefs
> 
> 
>  
> 
> If we assume it is legal to do this, can we only use positional 
> association for the parameter values?
> 
> typedef class c;
>  
>  typedef c#(1,1) c_1_1;                
>  typedef c#(.q (1), .p(2)) c_2_1;      // is this legal
>  typedef c#(,1) c_0_1;                 // can you use default values
>   
>  class c #(parameter p = 0, q = 0);
>  endclass
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Thursday, November 20, 2008 7:39 PM
> To: Francoise Martinolle
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] forward typedefs
> 
> 
> This was discussed at some point though I don't recall if it was 
> through the reflector buried in the wider discussion or just in a 
> meeting.  It certainly wasn't specified in the LRM.
> 
> My recollection was that Mark and I agreed that it would be legal to 
> have a forward specialization as in your example.
> I think that there was some disagreement as to whether the implicit 
> default specialization using just the name should be allowed.
Example:
> 
>     typedef class c;
>     typedef c d;
>     class c #(parameter p = 0); endclass
> 
> I was somewhat opposed to considering this as legal although it is 
> more symmetric to allow it.  My argument against is mostly one of 
> readability in terms of intent for a forward type "c#()" used as a 
> forward is more obvious as to intent.
> 
> Gord.
> 
> 
> Francoise Martinolle wrote:
>> Can you create a class specialization of a class for which we only 
>> have a forward typedefs?
>>  
>> Is this allowed?
>>  
>>  
>> typedef class c;
>>  
>> typedef c#(1) c_1;
>>  
>> class c #(parameter p = 0);
>> endclass
>>  
>> In mantis 2211, we discussed the usage of :: for incomplete typedefs 
>> and we speicifed the
>>  
>> following text:
>>  
>>
>> A forward typedef shall be considered incomplete prior to the final 
>> type definition. While incomplete forward
>>
>> types, type parameters, and types defined by an interface based 
>> typedef may resolve to class types, use
>>
>> of the class scope resolution operator (see 8.22) to select a type 
>> with such a prefix shall be restricted to a
>>
>> typedef declaration. It shall be an error if the prefix does not 
>> resolve to a class.
>>
>> Example:
>>
>> * *
>>
>> *typedef *C;
>>
>> C::T x; // illegal; C is an incomplete forward type
>>
>> typedef C::T c_t; // legal; reference to C::T is made by a typedef
>>
>> c_t y;
>>
>> * *
>>
>> *class *C;
>>
>> * *
>>
>> *typedef *int T;
>>
>> * *
>>
>> *endclass*
>>
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> *MailScanner* <http://www.mailscanner.info/>, and is believed to be 
>> clean.
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.