Brad Pierce wrote: > Gord, > > There is only one specialization C#(5). It is not like an instantiation. > If this were not so, how would it make sense to use it, say, as the type > of a subroutine input port? Exactly. > > If you think the text could be interpreted otherwise, we should clarify > it. Requoting the LRM (12.23) (without the non-normative parenthetical comment) we have: Each specialization of a class has a separate set of static member variables. To share static member variables among several class specializations, they must be placed in a nonparameterized base class. How can you possibly interpret this to say "There is only one static member variable in the entire system for each unique parameterization of the class." ? There is no definition of "unique parameterization" to even base such a statement on and the second sentence unambiguously states that the only way to get sharing is to have the shared static members be in a non-parameterized base class. I would have some real issues with making it work the other way right now since you would have to require a post-elaboration unification of all signatures and would have to define exactly what all of that means. I absolutely agree that in a future rev of the LRM this should be changed but it is way to late to do that now. Gord. > For example, it could be noted that when a parameter is a type, > then type matching (not type equivalence) is used to determine if it's > the same specialization. > > I continue to think, as in http://www.eda.org/sv-bc/hm/3096.html , that > parameterized subroutines add no new functionality to the language, > but are only (a very useful) syntactic sugar. > > -- Brad > > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of > Gordon Vreugdenhil > Sent: Thursday, May 05, 2005 7:11 AM > To: Maidment, Matthew R > Cc: Brad.Pierce@synopsys.COM; sv-bc@eda.org > Subject: Re: [sv-bc] Parameterizing functions using classes -- ballot > issue 225 > > > Matt, > > As I've said before, I think you are really after something > like C++ templates. There are problems with thinking about > parameters as template arguments; the concept of Verilog instantiation > is quite different than C++ template instantiation. > > The LRM already has serious problems in this space. For example, > consider a parameterized class (C) with a static member, and > declarations: > C #(5) a = new; > C #(5) b = new; > > The LRM (12.23) says: > Each specialization of a class has a separate set of static > member variables (this is consistent with C++ templated classes). > To share static member variables among several class specializations, > they must be placed in a nonparameterized base class. > > This clearly says that the statics of "a" and "b" are not shared. > > Unfortunately the clause "(this is consistent with C++ templated classes)" > is wrong. C++ templatization creates new types only **ONCE** for > each unique signature for the template so statics would be shared > if we really did what C++ does. > > So someone has already fundamentally confused C++ templatization and > Verilog parameterization in the LRM. > > I don't want this to become any worse; we've probably already got > into a bad space and doing something in the function/task space > is only going to exacerbate the issues. > > If we want a templatization facility, let's actually sit down > and define something consistent and complete. Mixing the concept > of Verilog parameterization and instantiation with templatization > is a recipe for confusion. > > Finally, if you truly believe that this is so pressing that you are > willing to live with future problems in trying to make things > consistent, I've already said that I might be convinced to go along > with the parameterization approach but only with the additional > restrictions that I've suggested. Those restrictions (in addition > to the ones that Brad already has in the proposal) give me the > ability to avoid future problems by ensuring that there is no > possible visible difference between the template approach and the > instantiation approach and allow me to deal with separate compilation > concerns. > > I'm not trying to say that your problem isn't important. I am saying > that what is being proposed has serious impact on future directions > for resolving existing confusion and I don't think we're really ready > to go down that road. > > Gord > > > > Maidment, Matthew R wrote: > >>Sorry if I missed discussion on this in the last meeting. >> >>The notion of using a parameterized interface was considered >>long ago. Brad's macros make things a bit more readable, >>but it remains undesirable to instantiate the interfaces >>before calling the functions. It's quite tedious to "specialize" >>the various functions: >> >>`SPECIALIZE(reverse4, #(4)) >>`SPECIALIZE(reverse3, #(3)) >>`SPECIALIZE(reverse2, #(2)) >>`SPECIALIZE(reverse1, #(1)) >> >>It forces coders to break their current thought process, do >>some bit-width calculations and then reconcile the result >>with what's already been instantiated. >> >>Parameterized functions or something along those lines >>is intended to make this process a lot easier. >> >>Matt >> >> >> >>>-----Original Message----- >>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On >>>Behalf Of Gordon Vreugdenhil >>>Sent: Tuesday, May 03, 2005 12:55 PM >>>To: Brad.Pierce@synopsys.com >>>Cc: sv-bc@eda.org >>>Subject: Re: [sv-bc] Parameterizing functions using classes -- >>>ballot issue 225 >>> >>>Yup - at least it is clear that there is an instantiation >>>taking place and that the user is explicitly aware of the >>>instantiation point. This follows existing Verilog semantics >>>and expectations regarding instantiations. >>> >>>My suggestion (explicit naming) just makes the syntactic form >>>cleaner than the macro form. >>> >>>Gord. >>> >>> >>> >>>Brad Pierce wrote: >>> >>> >>> >>>>They might as well keep using macros then, e.g., >>>> >>>> `FUNCTION(reverse, #(N=32, type T=type(logic[N-1:0]))) >>>> T reverse (T vector); >>>> foreach (reverse[i]) >>>> reverse[i] = vector[(N-1)-i]; >>>> `ENDFUNCTION(reverse) >>>> >>>> module test; >>>> `SPECIALIZE(reverse, #(4)) >>>> initial >>>> $displayb(`CALL(reverse)(4'b0101)); >>>> endmodule >>>> >>>>where >>>> >>>> `define TF_NAME(foo) IFC_tf_``foo >>>> >>>> `define FUNCTION(foo,params) \ >>>> interface `TF_NAME(foo) params (); \ >>>> function automatic >>>> >>>> `define ENDFUNCTION(foo) \ >>>> endfunction : foo \ >>>> endinterface : `TF_NAME(foo) >>>> >>>> `define SPECIALIZE(foo,params) \ >>>> `TF_NAME(foo) params `TF_NAME(foo) (); >>>> >>>> `define CALL(foo) \ >>>> `TF_NAME(foo).foo >>>> >>>>-- Brad >>>> >>>> >>>>-----Original Message----- >>>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of >>>>Gordon Vreugdenhil >>>>Sent: Tuesday, May 03, 2005 8:13 AM >>>>To: Mark Hartoog >>>>Cc: Brad.Pierce@synopsys.COM; sv-bc@eda.org >>>>Subject: Re: [sv-bc] Parameterizing functions using classes >>> >>>-- ballot >>> >>> >>>>issue 225 >>>> >>>> >>>> >>>>The recursion issue would go away if we went to a directly >>> >>>named form. >>> >>> >>>>For example: >>>> >>>> function some_foo is foo #(20); >>>> >>>>This is pretty VHDL'ish (egads) but removing the directly >>>>parameterized call forms would alleviate my concerns. >>>> >>>>Another alternative would be to fully develop a C++ like >>>>templatization approach which would allow one to properly anchor >>>>recursions. That however is a strictly compile time >>> >>>activity and not >>> >>> >>>>"elaboration time" as in Verilog. >>>> >>>>Parameters are NOT the same as C++ template arguments. If you want >>>>them to behave that way, you must deal with a number of other issues. >>>> >>>>Gord. >>>> >>>> >>>>Mark Hartoog wrote: >>>> >>>> >>>> >>>> >>>>>I agree with most of Gord's reservations. Consider for example: >>>>> >>>>>function #(N = 20) int foo(input i); >>>>> if (i > N) begin >>>>> return foo #(n+1)(i-1); >>>>> end >>>>> else begin >>>>> return (i-1); >>>>> end >>>>>endfunction >>>>> >>>>>For what values of N do we need to generate code for this function? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of >>>>>>Gordon Vreugdenhil >>>>>>Sent: Tuesday, May 03, 2005 7:03 AM >>>>>>To: Brad.Pierce@synopsys.COM >>>>>>Cc: sv-bc@eda.org >>>>>>Subject: Re: [sv-bc] Parameterizing functions using classes >>>>>>-- ballot issue 225 >>>>>> >>>>>> >>>>>>Brad, >>>>>> >>>>>>In order for me to be able to support this at all, I would want to >>>>>>see the following additional changes: >>>>>>1) restrict parameterized routines to not be permitted as methods >>>>>>2) parameterized routines shall not callable hierarchically >>>>>>3) in the current proposal there is no way to anchor any >>>>>> recursive instantiation; I think that should be made explicit >>>>>> and should be disallowed. Something like "no routine >>>>>> shall directly or indirectly instantiate itself". >>>>>> Users are already massively confused about what constitutes >>>>>> an elaboration condition and what doesn't. Just recently >>>>>> I had someone that had a ternary expression as the actual >>>>>> of a port connect and was surprised that it wasn't the >>>>>> same as conditionally selecting an actual (i.e. that it >>>>>> produced a legal lval). This is going to seriously >>>>>> compound that kind of confusion. >>>>>> >>>>>>Given the above, I may be willing to live with the proposal. >>>>>>I still would need other Mentor opinions before signing off since >>>>>>there is definitely opposition to this idea in its entirety. >>>>>> >>>>>>Class methods are problematic due to issues of virtual methods and >>>>>>other issues. Hierarchical calls in the presence of separate >>>>>>compilation are problematic for a number of reasons, including the >>>>>>interaction of parameters and default function arguments, etc. >>>>>> >>>>>>This leaves routines in packages and routines defined >>> >>>within the same >>> >>> >>>>>>module as the calls. Those can likely be handled in a reasonable >>>>>>clean manner and permit the kinds of things that you intend. >>>>>> >>>>>>However, I still have serious reservations about this approach. >>>>>> >>>>>>In VHDL (2002?), one may have functions with generics but there is >>>>>>still an explicit instantiation of the function to create a newly >>>>>>named function. I really, really do not like the implicit >>>>>>instantiation that is being added, particularly since the implicit >>>>>>instantiation is driven by sequential code. >>>>>>Given all the restrictions that are in place right now, it is >>>>>>reasonably easy to argue that any such call can be transformed into >>>>>>an instantiation in some enclosing non-sequential construct, but it >>>>>>would be really easy to run into serious issues with this in the >>>>>>future because it is so irregular. >>>>>> >>>>>> >>>>>>Gord >>>>>> >>>>>> >>>>>>Brad Pierce wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>In Verilog, the effect of a parameterized function can be >>>>>> >>>>>>achieved by >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>declaring it within a parameterized module, instantiating >>>>>> >>>>>>the module >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>as needed and calling the function via a hierarchical name. >>>>>>> >>>>>>>In SystemVerilog, it's more convenient to get this effect >>>>>> >>>>>>instead by >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>declaring the function within a parameterized class (see 12.23). >>>>>>> >>>>>>>For example, >>>>>>> >>>>>>> a = f#(33,type(int))(x,y) + pkg::g#(22)(z); >>>>>>> >>>>>>>can be implemented as >>>>>>> >>>>>>> begin >>>>>>> var f_class#(33,type(int)) f_dummy = new; >>>>>>> var pkg::g_class#(22) g_dummy = new; >>>>>>> a = f_dummy.f(x,y) + g_dummy(z); >>>>>>> end >>>>>>> >>>>>>>I don't think that the syntax proposed for ballot issue 225 >>>>>> >>>>>>adds any >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>new functionality to SystemVerilog. >>>>>>> >>>>>>> http://www.eda.org/svdb/bug_view_page.php?bug_id=696 >>>>>>> >>>>>>>Probably the current proposal is too restrictive semantically. >>>>>>>Although it's correct that parameterized subroutines, like >>>>>> >>>>>>subroutines >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>declared as class methods, should be automatic by default, >>>>>> >>>>>>there would >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>be no harm in allowing them to be explicitly declared >>>>>> >>>>>>static, as can >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>already be done with class methods. >>>>>>> >>>>>>>-- Brad >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>-- >>>>>>-------------------------------------------------------------------- >>>>>>Gordon Vreugdenhil, Staff Engineer 503-685-0808 >>>>>>Model Technology (Mentor Graphics) gordonv@model.com >>>>>> >>>>> >>>>> >>>>> >>>-- >>>-------------------------------------------------------------------- >>>Gordon Vreugdenhil, Staff Engineer 503-685-0808 >>>Model Technology (Mentor Graphics) gordonv@model.com >> > -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu May 5 10:08:42 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 10:08:47 PDT