I believe this kind of forward across the compilation unit scope was explicitly discussed and made legal. Not for parameterized classes explicitly, but for structs and the like. It would be very irregular to make an exception for parameterized classes. Unfortunately this means that the entire compilation unit must be seen before you can deal with parameterized classes. There was some discussion about restricting forward types by requiring incomplete types to be made complete before the beginning of the next design unit (covering nested modules as well) but there were non-vendors that strongly wanted the very general use model to be preserved. Gord. Mark Hartoog wrote: > I believe we have discussed making things like this illegal in the past, > but I cannot find any text in the LRM that makes it illegal. > > I don't think this is particularly useful, but there is currently > nothing that makes it illegal. > > -----Original Message----- > From: Francoise Martinolle [mailto:fm@cadence.com] > > 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 > -- -------------------------------------------------------------------- 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 Fri Nov 21 09:28:16 2008
This archive was generated by hypermail 2.1.8 : Fri Nov 21 2008 - 09:29:28 PST