Thought Leadership

SystemVerilog: A time for change? Maybe not.

February 25, 2010 • 2 MIN READ
By Dave Rich

The SystemVerilog IEEE 1800-2009 Language Reference Manual (LRM) was published a few months ago with an unprecedented 472 updates. That’s in addition to the changes required as part of the merging process with the Verilog 1364-2005 LRM. And in that five year timeframe, the Mantis system that tracks all of the LRM issues has grown to 986 open issues, becoming a black hole for issues. The SystemVerilog Working Group is collecting input for the next revision.

Inconsistencies in Implementations

There’s a lot of variety in what’s in the latest LRM versus what’s actually implemented in simulators today. Vendors have different sets of customers with different sets of priorities that drive implementing SystemVerilog features. Ambiguities in the LRM that have yet to be addressed wind up as inconsistencies in vendor‘s simulators.

Even some of what was specified in IEEE 1800-2005 has yet to be implemented. Take pattern matching of tagged union for example. This feature was put into Accellera SystemVerilog before IEEE standardization, but to my knowledge, had yet to be implemented in any simulator.

Why? There are several reasons. The most likely reason is that no customer has asked for it, or it has been below the threshold level to make it into anyone’s list to be implemented. Another reason is that there might be ambiguities in the LRM that need to be resolved before the feature can even begin to be implemented.

The result of all this is that users who want vendor interoperability are forced into restricted coding rules that limit themselves to a much smaller subset of SystemVerilog. Those same users often fail to realize that they need to drive their vendors to follow and fix the standard (See the recent discussion at Cool Verification).

The Problem

How did we get into this situation? Part of the problem lies with the PAR process. This is the IEEE process mandated to produce a revision of a standard. Five years is too long between revisions for an actively used standard. Users running into gaping holes in SystemVerilog functionality usually drive their vendors to bypass the PAR process and introduce proprietary extensions.

A Proposed Solution

After such a long revision process with so many changes, both users and vendors need to catch their breath. While it may be too radical to say no changes, we can propose a short period of stabilization where the main focus would be to address errata and ambiguities that drive convergence in implementations. We can improve the process that lets enhancements into the standard by making sure there is widespread support for that enhancement before work begins on it. Other areas for improvement could be to split the LRM is to separate standards (DPI/PLI) with their own schedules.

Input from users is welcome and needed.

Dave Rich

Dave Rich

Dave Rich is Verification Technologist at Mentor Graphics and is one of the authors of Mentor’s Advanced Verification Methodology cookbook. He began his career as a design and verification engineer in 1981 at Data General. In 1987, he joined Gateway Design Automation as one of the first application engineers to support Verilog-XL. At Gateway, he helped design many of the early features of the Verilog Hardware Description Language (HDL), and after Cadence acquired Gateway, helped prepare the Language Reference Manual (LRM) that would eventually be donated to the newly formed Open Verilog International. In 1995, he joined another Verilog simulation company, Frontline Design Automation as an AE manager and later as a Product Manager after it was acquired by Avant!. In 1998, he joined Ambit Design and worked as a consulting engineer for both synthesis and simulation products after it was acquired by Cadence. In 2000, he joined Co-Design Automation as Director of Application Engineering where the Superlog HDL was being developed that eventually became the basis of the Accellera SystemVerilog 3.0 standard. Co-Design Automation was acquired by Synopsys in 2002. Dave began work on numerous technical committees within Accellera and later the IEEE P1800 working group, which he continues today.

More from this author

What to read next:

Comments

3 thoughts about “SystemVerilog: A time for change? Maybe not.”

  • Dave,

    This was similar reasoning for SystemVerilog 3.1a: Give industry a time to implement and learn from that to improve, modify or change the language. Would pausing also make a positive impact towards more interoperable SystemVerilog are you point out is a problem.

  • Dave,
    Indeed a very noble thought, actually people in a given company just uses a subset of such a feature rich language like SV which almost becomes very deterministic after a particular language has been used in a given product line, so addition of features to a language without the stabilization of the simulators and the langauage itself is not the worth.
    So its a great thought to provide SV-2005 to settle down!!!

  • Dave,

    I can’t agree more! There is no doubt that the language is not perfect and needs to evolve, but first it must be standing on solid ground. Further evolutions should wait until all vendors (and users!) have had reasonable time to catch up with everything that’s in 1800-2009.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.stage.sw.siemens.com/verificationhorizons/2010/02/25/systemverilog-a-time-for-change-maybe-not/