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