SystemVerilog 2012

 

Current SV enhancement requests.

What’s your SV wish list?

Add a comment below.  Name and e-mail are entirely optional.

Advertisements

15 Comments

  1. If general parameterization as Sergey suggests is not possible, SV should at least have support for parameterized functions and tasks.

    From reading Mantis item 696, I understand that this can be done with static methods of a parametrizable class, but this is useless for design engineers because the tool vendors do not support classes as part of the synthesizable subset and have no plans to do so AFAIK.

    Perhaps the problem is that the LRM takes no official stance on what subset of the language is synthesizable, leaving it up to the tool vendors to make their own interpretation.

    Like

    • The approach of 696 is clearly synthesizable. The market will decide whether synthesis tools add support for it.

      Like

  2. SV’s class copy is a shallow copy. To do a deep copy, you have to write your own routine. SV should have a built-in deep copy capability.

    Shalom

    Like

  3. Jonathan Bromley and Gordon Vreugdenhil presented a paper on SV interfaces at DVCON 2009. It is now available as a white paper from Mentor.

    Also, Dave Rich is going to present a paper at DVCON this year called, “The Problems with Lack of Multiple Inheritance in SystemVerilog and a Solution”.

    Both of these point to directions that should be considered for the next revision of the standard.

    Shalom

    Like

  4. A frequent request is for AOP (Aspect-Oriented Programming) capability in SV.

    e users say it is one of the most useful aspects of the language.

    Shalom

    Like

  5. The top 3 items on my wishlist for SV 201x are:

    #1 Support for subprogram overloading. Even if this could only be provided for class member functions (including constructor).

    #2 References to static objects (if you can have a virtual interface, why not a “virtual module”?)

    #3 Multiple inheritance of interface classes, e.g. as in Java (would simplify creation of TLM classes).

    David Long
    Doulos
    ==========

    Like

  6. That’s a really smart trick with the ‘let’ 🙂 Hopefully EDAs will be capable to digest such dainties before 2012.

    Like

  7. I beg your pardon for my impetuous utterance. I didn’t mean to hurt somebody’s feelings. My expansiveness aroused from big disapointment at what I expected from the new standard and what it really turned to be – on my opinion, as I told before, it is not a new standard, but purification of the previous. I felt that sorrow after I saw the presentation of Mr. Sutherland at DVCon in 2008 (concerning my saying “seems to be very proud”). There was a title “Lots of new stuff in the next version of SystemVerilog”, which I thought was not 100% fair, i.e. (imho) not really “lots” and not so distinguishably “new”.
    Concerning the BlueSpec or to be more precise “type parametrization”, I remember that the discussion started somewhere around the time the previous standard was going to be published. That time there was a dispute on if it is syntatically possible to realize templatization within the current SV “flavour”(let’s say). And there was a definite answer from a guy from BlueSpec that it is so and moreover they already did so in their product. So even that it was possibly not a matter of direct donation (as they stopped participation some years ago) it was clear that tepmlatization is syntatically realizable 4 yeas ago. Now the question is if it is really that vital. On my opinion the answer is “yes”. I wouldn’t go deeply into discussion on the new level of language abstraction and its practicality for a HW designer, coz it is a fundamental discussion and I wouldn’t dare to try to reason it thoroughly and completely. I just want to show an evidence of its actuality. I see that one of two main difference that can be recognized in the newer VHDL(one is direct PSL) is ubiquitous parameterization (data, subroutines, packages, etc.), which really give a new flavour to the language.
    Regards,
    Sergey

    Like

    • I agree that the lack of parameterization is frustrating. This is the topic of unresolved Mantis item 696.

      A little progress in that direction was the approved ‘let’ syntax of Mantis item 1728. There are examples of its usage here.

      Like

      • Hallo Brad,
        it seems that p1800-2009 will give a broader way for parametrization ( at least according to the data that could be found in open sources http://www.eda.org/svdb/file_download.php?file_id=2908&type=bug ). Again (like function parametrization) the trick is to use interfaces (but now) for data structure parametrization, e.g.

        interface #(parameter type templatization_type_pt = int, parameter int size_p=8 )type_templated_if;
        typedef templatization_type_pt templated_array_type_t[size];
        endinterface

        module my_m(type_templated_if my_if);
        typedef my_if.templated_array_type_t my_templated_array_t;
        my_templated_array_t my_typed_array;
        endmodule

        I don’t know if we could call it one step “forward” or a step “aside”, but it seems that interfaces become somewhat like parameterizable packages. And I guess it was not the initial intent (well at least they become something between HW interfaces and interfaces in programming word paradigm).

        Like

  8. I would be quite happy if the standard allowed templatization (or parameterization in general terms). That would be a great improvement for disign engineers.
    Actually I am very disappointed with the activity of the BC guys. The upcomming standard seems to be just a v.2005-bugs-free, i.e. no real progress at all, though for example BlueSpec SV had much more advanced syntax years ago, the BueSpec guys were in the committee and they were ready to donate their solutions. Instead of that all the committee(BC) could do is such stuff like e.g. dubious implication operators (->, ), which they seem to be very proud of.

    Like

    • The last time BlueSpec attended SV-BC was April 1, 2005. The BlueSpec donation of tagged unions became part of the IEEE SystemVerilog 2005 standard.

      I haven’t noticed anyone being “very proud” of implication operators. Your evidence for that claim …?

      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