SV parameterized functions

Please see this sketch about a possible way to add parameterized functions to SystemVerilog.

Yes, I know, it’s not unconstrained array types.

Advertisements

17 Comments

  1. des00,

    That is still new syntax, even though you are introducing no new keywords.

    VHDL has no built-in vectors – everything is handled dynamically via resolution functions from standard packages. It not handles by the compiler; which is one reason it executes so much slower than Verilog.

    Dave

    Like

  2. I am just as worried when we start adding more syntax to a language already overburdened with syntax just because of a marketing perception issue.

    C++ class are already synthesizable by commercially availible tools and there’s no reason other than perception to think that SV class are not synthesizable.
    In fact, I can think of only one restriction you would need to make classes easily synthesizable and that is to require all class variables must be const variables. That makes them behave similar to statically constructed classes in C++.

    Dave

    Like

    • I agree with Sergey. I don’t like the idea to use classes inside RTL code for synthesis. IMHO It’s wrong way to failure. Why you can’t do sometheing like VHDL aproach to detect operator bitwidth at function call?. It can be like this

      function logic [$:0] pipa (input logic [$:0] data)
      logic [$size(data)-1 : 0] tmp;
      for (int i = 0; i < $size(data); i++) begin
      if (data[i]) tmp = bla -bla -bla;
      end
      return tmp;
      endfunction
      there is no any new syntax, symbol $ is used for quenes and assertions.

      Compiler detect bitwidth using system $size/$high/$low functions and we only need to tel it don't truncate operator bitwidth at function call.

      This approach is more simple then making class synthesable i think.

      Like

      • Hallo everybody,
        There is some more criticism I would like to give out about the question. I hope it can be helpful:
        (in general)
        I would agree that syntax is a bit overburdened, but worse is that being overburdened the language still does not meet some basic needs. And the broader parameterization is an example.
        It seems to me that the source of this distortion is a) a poor feedback mechanism from the broad community of end user to the “narrow” community of thinkers, i.e. the committee: there is no forum for broad discussion and ideas selection, which can be helpful for the committee; b) it seems there is no ranking system for language innovations that are going to be introduced in the standard and there is no long-term planning of the language future(a strategic roadmap).
        (in particular)
        1) My concern about vendors vs. class synthesis was not for the sake of vendors’ comfort. I know a lot of more trivial things that the majors still haven’t realized properly. So the matter was really the time when an end user will be able to enjoy subroutines templatization after the standard will see the light. I’m talking about the users that chose the tools from the majors and do not rely on small-caps, who are typically more advanced in their solutions but at the same time less stable in the market (I guess these users are the majority).
        2) The approach with classes will normally mean 1 class = 1 function. Is it not a potential threat for name space? It was from my experience that when I was using the interface mechanism for function templatization a function name was easy to invent, but I always stuck when I had to give a name to the correspondent interface declaration. It was because I feel that a name should match functionality. But what is the functionality of an interface in this case? Just a container for a function. This means the interface should have the same name as its function has + something that will differentiate them. It will be the same problem with classes for me.
        3) I always use self-commenting names, which means at least a dozen of characters. It is not anymore an innocent “a=C#(4)::DECODER_f(decoder_in);” it will be something like “some_value_name_st=some_function_name_cl#(4)::some_function_name();” minimum. Again, from my experience it looked a bit ugly, coz the difference between interface and class function calls will only be in “#(4)::”, i.e. the same endless codelines.
        4) Normally templetization in HDLs is needed for HW designers, because modeling and verification guys are not so interested in precise data-formats and accurate functionality at the signal level. Let’s forget for a while about ESL synthesis, which has not become yet a default way for synthesis (and it is not clear when it will be so). HW designers are not programmers and they did not have to know what OOP is, and often they do even want know it. It is just because they always lived in the world of objects without OOP. Their objects are modules, interfaces, signals. HDLs utilize procedural language paradigm which conform with templatization without any add-ons. Is it humane to force them to study OOP without a real need except for function templatization? I’m not sure that OOP, which just mimics objective world in programming world, is a virtue for languages that naturally have objects in their concept (please, note that I mean only HW design, not modelling or verification, where classes are absolutely good, and I do not mean ESL synthesis, which has undefined future yet).
        Thanks for attention
        Kind regards, Sergey

        Like

  3. 2) as I mentioned before the synthesis software vendors are very inertial. they will have to accept and realize the idea that classes are synthesizable constructions. They will have to say in their manuals “Classes are synthesizable, but only those that are … /and here is a long list of constraints that should eventually result effectively just in parameterizable functions/”. I do not think that they will be very enthusiastic in rewriting their compilers to introduce a new synthesizable substance and a lot of rules restricting the other possible use of classes inside a synthesizable code.
    3) Moreover I see it not attractive for them from the point of view of marketing. I see it is much more beneficial for product promotion to give a slogan “We now support a newly approved syntax for functions”, than to say “We now support classes for synthesis BUT … and so and so and so (which actually means that it works only for function parameterization)”.
    That is what I worry about, when I see the initiative with the static class functions.
    Thanks for attention,
    Kind regards, Sergey

    Like

  4. Hallo Brad,
    I’ve noticed that there was some progress in the matter of parameterizable functions in the recent past, as it can be seen here http://www.eda-stds.org/sv-bc/hm/10547.html I do not know the other way I can share my opinion with the guys from the BC on that except writing it here.
    I find the following objectives against the proposed approach, which might be helpful for those that build up the new standard:
    1) I think it break the rule that may be phrased something like “I will get what I expect to get”. I think the SV community got to the understanding that the standard becoming too tangled (once you noted that as well in your blog). I think the proposed approach helps it to be even more complicated, less intuitive and plain. The approach IMHO does not differ much from the trick with interfaces with the only exception the one do not have to instantiate an object. It is a pity, that the initial sense of entities becomes perverted. Now a class can be seen something like parameterizable library of subroutines(could be seen as not full-fledged package). I really do not understand this logic.

    Like

  5. I’d like to see datatype and value parameters available to functions. I’d like to see the return type affected by the parameters if desired. I’d like to see the parameter syntax used at the calling site, too.

    function #(parameter N = 32) logic[N-1:0] foo return M*N;
    endfunction

    integer o;
    initial
    o = foo#(.N(2))(12);

    Inference sounds nice but I’m ok with it not happening.

    Like

    • Implementers will be happier with requiring parameter specialization syntax at the call site, but I’d feel more comfortable with the usability of that approach if some real uses were tried.

      However, if that’s all we want, then we could just say that

      foo#(.N(2))(12);

      is shorthand for

      foo#(.N(2))::foo(12)

      where foo is both a class and a static method inside the class

      class foo#(…);
      static function foo(…); endfunction
      endclass

      Then we wouldn’t need to introduce anything additional, just slightly extend the calling syntax.

      Like

      • Does it mean that we may hope that parameterizable functions will ever be synthesizable? I think that vendors will never even think about support for classes in their synthesis tools. So extended function syntax is needed more for forcing vendors to support more flexible and tunable description for synthesis, rather than to achieve the effect of parameterization with different tricks.
        If the direct function syntax extension is so unfavorable for some reasons, so that we need to find a solution with minimal syntax amendment and max effect, the better idea I see (as far as I am able) is the introduction of parameterizable packages. This I think can solve as well the problem with parameterizable structures.
        Regards,
        Sergey

        Like

        • I don’t think the proposal on this page will go anywhere, and, if anything, the static class method approach, as in this, will prevail. It all comes down to what customers demand.

          Like

  6. Is there a reason we encapsulate the parameterized types with in the function definition? We don’t do this with module types that are passed in as parameters. Otherwise I like the idea.

    Like

    • If a function call is buried deep within a generate, you may not have an obvious name for the type of the argument or for its size. If you don’t, then you can’t write something like

      f#(T,N)(a+b,c+d)

      and are forced to copy those arguments into a calculation of the type or size, such as

      f#(type(a+b),$bits(c+d))(a+b,c+d)

      or

      localparam type T = type(a+b);
      localparam N = $bits(c+d);
      … f#(T,N)(a+b,c+d) …

      which is not only a hassle, but is error-prone. It will likely be hidden behind a macro, which is not as easy to read or debug.

      Like

  7. Brad,

    Another SV precedent is the SV-2009 ‘let’ construct, which can be used in place of simple functions and also has sort of an inferred return type. It’s not exactly that, but it can be looked at that way.

    Shalom

    Like

    • Thanks, Shalom, ‘let’ completely escaped my mind this week. I added a very relevant LRM example (an example that I myself originally wrote!) to slide 4.

      — Brad

      Like

Tell me (anonymous OK)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s