RE: [sv-bc] Parameterizing functions using classes -- ballot issue 225

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
>