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 07:11:27 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 07:11:41 PDT