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 08:12:45 2005
This archive was generated by hypermail 2.1.8 : Tue May 03 2005 - 08:12:48 PDT