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 Wed Jul 9 15:41:00 2008
This archive was generated by hypermail 2.1.8 : Wed Jul 09 2008 - 15:41:07 PDT