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 >Received on Thu May 5 04:23:36 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 04:23:43 PDT