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 09:26:43 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 09:26:48 PDT