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

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Thu May 05 2005 - 09:36:39 PDT
I prefer

     a = f#(33,type(int))(x,y) + pkg::g#(22)(z);

to

     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.g(z);
     end

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Rich,
Dave
Sent: Thursday, May 05, 2005 9:26 AM
To: Brad.Pierce@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org
Subject: [sv-ec] RE: [sv-bc] Parameterizing functions using classes --
ballot issue 225


So Brad,

Why can't synthesis tools support the synthesis of classes with no
properties and only allow the declaration of const class handles? :)

Dave
 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Brad
> Pierce
> Sent: Thursday, May 05, 2005 9:11 AM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-bc] Parameterizing functions using classes -- ballot
> issue 225
> 
> Gord,
> 
> There is only one specialization C#(5).  It is not like an
instantiation.
> If this were not so, how would it make sense to use it, say, as the
type
> of a subroutine input port?
> 
> If you think the text could be interpreted otherwise, we should
clarify
> it.  For example, it could be noted that when a parameter is a type,
> then type matching (not type equivalence) is used to determine if it's
> the same specialization.
> 
> I continue to think, as in http://www.eda.org/sv-bc/hm/3096.html ,
that
> parameterized subroutines add no new functionality to the language,
> but are only (a very useful) syntactic sugar.
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
> Gordon Vreugdenhil
> Sent: Thursday, May 05, 2005 7:11 AM
> To: Maidment, Matthew R
> Cc: Brad.Pierce@synopsys.COM; sv-bc@eda.org
> Subject: Re: [sv-bc] Parameterizing functions using classes -- ballot
> issue 225
> 
> 
> Matt,
> 
> As I've said before, I think you are really after something
> like C++ templates.  There are problems with thinking about
> parameters as template arguments; the concept of Verilog instantiation
> is quite different than C++ template instantiation.
> 
> The LRM already has serious problems in this space.  For example,
> consider a parameterized class (C) with a static member, and
> declarations:
>     C #(5) a = new;
>     C #(5) b = new;
> 
> The LRM (12.23) says:
>     Each specialization of a class has a separate set of static
>     member variables (this is consistent with C++ templated classes).
>     To share static member variables among several class
specializations,
>     they must be placed in a nonparameterized base class.
> 
> This clearly says that the statics of "a" and "b" are not shared.
> 
> Unfortunately the clause "(this is consistent with C++ templated
classes)"
> is wrong.  C++ templatization creates new types only **ONCE** for
> each unique signature for the template so statics would be shared
> if we really did what C++ does.
> 
> So someone has already fundamentally confused C++ templatization and
> Verilog parameterization in the LRM.
> 
> I don't want this to become any worse; we've probably already got
> into a bad space and doing something in the function/task space
> is only going to exacerbate the issues.
> 
> If we want a templatization facility, let's actually sit down
> and define something consistent and complete.  Mixing the concept
> of Verilog parameterization and instantiation with templatization
> is a recipe for confusion.
> 
> Finally, if you truly believe that this is so pressing that you are
> willing to live with future problems in trying to make things
> consistent, I've already said that I might be convinced to go along
> with the parameterization approach but only with the additional
> restrictions that I've suggested.  Those restrictions (in addition
> to the ones that Brad already has in the proposal) give me the
> ability to avoid future problems by ensuring that there is no
> possible visible difference between the template approach and the
> instantiation approach and allow me to deal with separate compilation
> concerns.
> 
> I'm not trying to say that your problem isn't important.  I am saying
> that what is being proposed has serious impact on future directions
> for resolving existing confusion and I don't think we're really ready
> to go down that road.
> 
> Gord
> 
> 
> 
> Maidment, Matthew R wrote:
> > 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
> >
> >>
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
Received on Thu May 5 09:36:45 2005

This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 09:36:49 PDT