RE: [sv-ec] class related questions

From: Francoise Martinolle <fm_at_.....>
Date: Thu Jul 10 2008 - 07:23:31 PDT
 
Gordon,

So I am interpreting your response that with incomplete forward type,
you can refer to 
anything inside the class before the class declaration is fully seen?

typedef C;
parameter q = C#()::cp;
typedef C#()::T C_T;

class C #(parameter cp = 0);
  typedef bit T;
endclass

Is that right?

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Wednesday, July 09, 2008 6:40 PM
To: Francoise Martinolle
Cc: Rich, Dave; sv-ec@eda.org
Subject: Re: [sv-ec] class related questions


I'm comfortable with allowing both.

Note that the LRM in 6.18 has:

    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.

So for a forward type you can't have something like:

    typedef C;
    C::T x;
    class C;
       typedef int T;
    endclass

but you can have:

    typedef C;
    typedef C::T c_t;
    class C;
       typedef int T;
    endclass

Similarly if "C" was a type parameter or type from an interface based
typedef (i.e. "typedef intf.T C;".  Note that there is no restriction
regarding non-type references with such kinds of prefix.

This was all explicitly considered at the time (certainly Mark and I had
in-committee discussions).  The resulting LRM text reflects the
consensus and allows "::" references to parameters, typedefs, etc.  It
would be extremely odd to me to consider a "::"
reference to a class parameter as not being a constant expression and I
would certainly oppose any restatement to that effect.

Gord.



Francoise Martinolle wrote:
> Thanks Dave,
>  
> I agree with 1 but disagree that we should allow 2).
> Seems like a bad idea to consider C::q as a constant expression.
> Class declarations can be declared much later in the source code since

> we allow forward type declarations.
> We could end up with circular dependencies where p in the module 
> depends on a parameter declared in a class specialization and the 
> class depends on the module parameter.
> Sounds safer to disallow this, no?
>  
> Also can we use C::q (class scope parameter) in a range?
> Francoise
>        '
> 
>
------------------------------------------------------------------------
>     *From:* Rich, Dave [mailto:Dave_Rich@mentor.com]
>     *Sent:* Wednesday, July 09, 2008 5:21 PM
>     *To:* Francoise Martinolle; sv-ec@eda.org
>     *Subject:* RE: [sv-ec] class related questions
> 
>     
> ----------------------------------------------------------------------
> --
> 
>     *From:* owner-sv-ec@server.eda.org
>     [mailto:owner-sv-ec@server.eda.org] *On Behalf Of *Francoise
Martinolle
>     *Sent:* Wednesday, July 09, 2008 1:29 PM
>     *To:* sv-ec@server.eda.org
>     *Subject:* [sv-ec] class related questions
> 
>      
> 
>     Question 1:
> 
>     Can you use the "dot" to refer to a type declared inside a class?
> 
>     module top;
> 
>     class C;
> 
>       typedef bit T[4];
> 
>     endclass
> 
>     C c = new;
> 
>        bit b;
> 
>        initial
> 
>           b = c.T'{0, 1, 0, 1};
> 
>     endmodule
> 
>      
> 
>     The bnf for assignment pattern type does not allow the above, 
> neither
> 
>     does it allow C::T'{0, 1, 0, 1}
> 
>      
> 
>     I also remember that we decided that hierarchical identifiers to
>     types are not legal, but does c.T qualifies
> 
>     as a hierarchical identifier? or is it just what we called a
dotted
>     name?
> 
>     */[DR] You can not use a dotted name as a type. The only exception
>     is with an interface port. And had introduced the scope operator
>     '::' at the time, we should have used that instead of allowing 
> '.'./*
> 
>     */ /*
> 
>     */I think C::T should be allowed as we have used it resolve Mantis
>     1857. It might be an oversight in the BNF./*
> 
>     */ /*
> 
>      
> 
>     Question 2:
> 
>      
> 
>     Can a parameter initial expression be a class scoped identifier?
> 
>     The LRM currently only allows package references. I assume this is
>     not legal:
> 
>      
> 
>     module top;
> 
>     class C #(parameter q = 0, parameter type T = byte);
> 
>     endclass
> 
>      
> 
>     parameter p = C::q;
> 
>     parameter type R = C::T;
> 
>      
> 
>     endmodule
> 
>     */[DR] Again, I think there is LRM text to support this usage in
>     terms of parameters that are nested in classes, but no BNF. For
>     example T::p refers to the parameter up in the class hierarchy./*
> 
>     */ /*
> 
>     class C #(parameter p = 0) extends T;
> 
>     parameter q = T::p;
> 
>     endclass
> 
>      
> 
>     */Another example, T::p refers to a parameter within the class/*
> 
>     class C #(parameter type T = int);
> 
>     parameter q = T::p;
> 
>     endclass
> 
>     */ /*
> 
>     */./*
> 
>      
> 
> 
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean. 
> 
> 
> --
> 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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jul 10 07:24:23 2008

This archive was generated by hypermail 2.1.8 : Thu Jul 10 2008 - 07:26:33 PDT