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.)
- Badri Gopalan’s wishlist
- David Jones’s wishlist
- Jonathan Bromley on modports as data types (shortcut to PDF)
- Frustrations with packages
- Frustrations with array bounds checking
- Functions with unconstrained array input/output
- Can’t extend methods/constraints of package code
- Hierarchical covergroups and crosses of crosses
Plus see also
- Jonathan Bromley’s wishlist and his “Towards a Practical Design Methodology with SystemVerilog Interfaces and Modports” (paper, presentation)
- What is SV-BC saying?
- Infineon on interfaces
- ARM on AOP and multiple inheritance
- SystemVerilog gotchas
- 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.
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.