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