SystemVerilog-201x listening campaign

2009/12/14 — 6 Comments

Update 6: User requirement presentations.

Update 5: Captured on camera.

Update 4: The agenda. (Scroll down.)

Update 3: The call for participation and where to send your title and abstract.

Update 2: Details about venue, WebEx, RSVPs.

Update 1: The meeting will be on Feb. 26 from 8-4. Karen Pieper, the chair of the Working Group will send out a call for participation, with the title and abstract of your presentation due by Feb. 10, 2010.  According to these minutes

Anyone who wishes to speak will need to register in advance.  Many people beyond our committee have already expressed an interest to speak. … The presentations will be at the beginning of the meeting and discussion will be held in the afternoon.

As described in bullet 9 here, the IEEE SystemVerilog working group is actively seeking input on user priorities for the next revision of the standard.

This listening campaign will culminate with a day-long event during the week of DVCon 2010, on Feb. 26 at the San Jose campus of Mentor Graphics. Interested parties will be able to participate face-to-face or via the web.

Details have yet to be announced, but it’s time to start building your case for what you need most from the next revision of SystemVerilog.

Stay tuned for updates.

To get the conversation started, following are a few links sent to me by Shalom Bresticker. (He’s not endorsing these, just collecting viewpoints.)

  1. Badri Gopalan’s wishlist
  2. David Jones’s wishlist
  3. Jonathan Bromley on modports as data types (shortcut to PDF)
  4. Frustrations with packages
  5. Frustrations with array bounds checking
  6. Functions with unconstrained array input/output
  7. Can’t extend methods/constraints of package code
  8. Hierarchical covergroups and crosses of crosses

Plus see also

  1. Jonathan Bromley’s wishlist and his “Towards a Practical Design Methodology with SystemVerilog Interfaces and Modports” (paper, presentation)
  2. What is SV-BC saying?
  3. Infineon on interfaces
  4. ARM on AOP and multiple inheritance
  5. SystemVerilog gotchas
  6. The comments here, such as David Long’s wishlist.

Some of the comments in the last item are similar to what Shalom expressed here

SV does not have (or still does not have) extremely useful features that other hardware design/verification languages have (notably VHDL on the design side and e on the verification side). This causes users migrating from such other languages to feel that they are moving backwards instead of advancing forwards. The language should enable them to do what they want/need to, without getting in the way and making things hard for them.

and here

One type of complaint that I see frequently is “I am used to doing X in VHDL/e, it is useful and it is easy in VHDL/e, why does SystemVerilog make it so hard??”
I am not saying that we should blindly adopt VHDL or e features, but these complaints do indicate some productivity obstacles in SV, and we should relate to these seriously.

6 Comments

  1. I feel the need of the following in SV

    1. the keyword “singleton” for defining a class as singleton object. It shall get rid of the need of some weird way of getting singleton class in SV

    singleton class ABC;
    …
    endclass

    2. Unified verification methodology should be defined as a part of SV. There are way too many methodology now a days (like OVM, AVM, VMM and so on …). There should be one such standard methodology. It shall make life far easier for so many engineer.

    3. SV macros are a very powerful tool for reducing the amount of coding effort. SV improved quite a bit on verilog macro, but still there is a quite a bit scope for improvement.

    “ is a very rudimentary operator. It can’t be used for adding prefix to the input of the macro. See the hack that we need to do for adding prefix at http://learn-systemverilog.blogspot.com/2009/09/system-verilog-define-macros-why-and.html

    `define PREFIX(__prefix, __name) __prefix“__name
    `define COV2(__name) `PREFIX(cp_,__name) : coverpoint __name {bins b = {1}; }

    should be something like
    `define COV2(__name) cp_[[__name]] : coverpoint __name {bins b = {1}; }

    4. There is scope for adding macro programming ability to SV. It should have the ability of generating code during macro processing phase

    `for(int i=0; i<12; i++) begin \
    bind module_1 module_2 bind_mod_[[i]] (.*); \
    end

    Like

  2. Hi,

    Thanks for the System Verilog Listening Campaign.

    Here is my request;

    I use type string and would like to perform RegEx methodes on it. Currently I am using VCS SV simulator, and fortunately under Open Vera extensions there, there are some methodes available that are very useful but not part of the SV language. My request is that SV accept OV RegEX functions and offically make them part of the SV language. Or come up with equivalent or better.

    Thanks,
    Vahid

    Like

Tell me (anonymous OK)