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.comReceived on Tue May 3 12:55:20 2005
This archive was generated by hypermail 2.1.8 : Tue May 03 2005 - 12:55:24 PDT