Dave, Maybe a worked example would help me understand what you're saying. The running example is a function that reverses an array, say, function automatic #(type T=int) T reverse(T array); localparam N = $left(T); for (int i = 0; i <= N; i++) reverse[i] = array[N-i]; endfunction And I need to call this on multiple vectors of different sizes, say, x, y, z reverse#(type(x))(x) reverse#(type(y))(y) reverse#(type(z))(z) I don't like the way Verilog forces me to make the type explicit, instead of inferring the types from the arguments. But how would SV classes help me get around this? -- Brad -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Rich, Dave Sent: Thursday, May 05, 2005 9:49 AM To: Brad.Pierce@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org Subject: [sv-ec] RE: [sv-bc] Re: Parameterizing functions using classes -- ballot issue 225 Well I would prefer a = f(x,y) + pkg::(z); to a = f#(33,type(int))(x,y) + pkg::g#(22)(z); Especially when the parameters you are trying to pass are most likely determined from the arguments being passed. Dave > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad > Pierce > Sent: Thursday, May 05, 2005 9:37 AM > To: sv-bc@eda.org; sv-ec@eda.org > Subject: [sv-bc] Re: Parameterizing functions using classes -- ballot > issue 225 > > I prefer > > a = f#(33,type(int))(x,y) + pkg::g#(22)(z); > > to > > 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.g(z); > end > > -- Brad > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Rich, > Dave > Sent: Thursday, May 05, 2005 9:26 AM > To: Brad.Pierce@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org > Subject: [sv-ec] RE: [sv-bc] Parameterizing functions using classes -- > ballot issue 225 > > > So Brad, > > Why can't synthesis tools support the synthesis of classes with no > properties and only allow the declaration of const class handles? :) > > Dave > > > > -----Original Message----- > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > Brad > > Pierce > > Sent: Thursday, May 05, 2005 9:11 AM > > To: sv-bc@eda.org; sv-ec@eda.org > > Subject: RE: [sv-bc] Parameterizing functions using classes -- ballot > > issue 225 > > > > 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? > > > > If you think the text could be interpreted otherwise, we should > clarify > > it. 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.com > > > > > > >Received on Thu May 5 11:14:39 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 11:14:45 PDT