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

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Thu May 05 2005 - 11:34:28 PDT
My claim that parameterized subroutines are just syntactic sugar is
independent of this issue, because the following rewrite works under
either interpretation --

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

            --->

     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: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Thursday, May 05, 2005 10:09 AM
To: Brad.Pierce@synopsys.COM
Cc: sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-ec] RE: [sv-bc] Parameterizing functions using classes
-- ballot issue 225




Brad Pierce wrote:

> 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?

Exactly.

>
> If you think the text could be interpreted otherwise, we should clarify
> it.

Requoting the LRM (12.23) (without the non-normative parenthetical
comment) we have:
     Each specialization of a class has a separate set of static
     member variables.
     To share static member variables among several class specializations,
     they must be placed in a nonparameterized base class.

How can you possibly interpret this to say "There is only one static
member variable in the entire system for each unique parameterization
of the class." ?

There is no definition of "unique parameterization" to even base
such a statement on and the second sentence unambiguously states
that the only way to get sharing is to have the shared static
members be in a non-parameterized base class.


I would have some real issues with making it work the other way
right now since you would have to require a post-elaboration
unification of all signatures and would have to define exactly
what all of that means.

I absolutely agree that in a future rev of the LRM this should
be changed but it is way to late to do that now.


Gord.


> 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 11:34:34 2005

This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 11:34:39 PDT