> Dave Rich wrote: > > Arturo, > > Yes, making structs behave more like classes and classes behave more > like structs is the way to go. > I agree that structs can benefit from some class-like features, and we have recently passed one such enhancement that was raised by Mentor. But I don't know how classes could benefit from anything available only to structs? Presumably you mean static classes, which have been reviewed and rejected. > We're doing the language a disservice if we add a template-like feature > for functions and not classes, or if we later find the way that works > for functions won't work for classes. > I'm not sure what to make of this. Classes are already parameterized, and I do see problems with the parameterized function proposals that have been discussed. > Dave > > > > -----Original Message----- > > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] > > Sent: Thursday, May 05, 2005 12:23 PM > > To: Rich, Dave; Brad.Pierce@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org > > Subject: Re: [sv-ec] RE: [sv-bc] Parameterizing functions using > classes -- > > ballot issue 225 > > > > Dave, > > > > It's possible that certain limited types of classes will become > > synthesizable. > > However, in addition to the limitations you propose you'll most likely > > need > > to disallow virtual methods. Presumably, in synthesis these class > handles > > are all null (because they are const, the constructor can only be > called > > in > > as part of the declaration, which is a non-synthesizable > initialization). > > > > Also, a class with no properties will not be particularly useful, and > to > > support > > that, a relaxation of the rules may be needed. But, if we were to do > that, > > we > > would have to deal with the question of handle creation in a > synthesizable > > context. Perhaps, parametric structs with methods may be a better fit > for > > synthesis. > > > > Arturo > > > > ----- Original Message ----- > > From: "Rich, Dave" <Dave_Rich@mentor.com> > > To: <Brad.Pierce@synopsys.COM>; <sv-bc@eda.org>; <sv-ec@eda.org> > > Sent: Thursday, May 05, 2005 9:26 AM > > 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 22:45:13 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 22:45:18 PDT