Viewpoint: Towards a lean and mean SystemVerilog

Swapnajit Mitra

March 13, 2012

Swapnajit Mitra

IEEE Std. 1800-2009 – A Merger of Two Titans
IEEE Std. 1800-2009 combines Verilog and SystemVerilog (SV) languages under the auspices of one single language standard. This was long overdue as the first step towards streamlining what was essentially the same language covered by two different language standards – IEEE Std. 1800-2005 and IEEE Std. 1364-2005.

However, the current version of the standard just starts that process of streamlining and the process is far from being over. This is apparent if one looks at the size of the current standard (1285 pages) and compares it with language standards from other fields, such as ANSI C (C99 has 554 pages) and ECMA JavaScript (ECMA-262 has 258 pages).

Another measure of language brevity is the number of keywords that the language needs. IEEE Std. 1800-2009 has 244 keywords, nearly doubled from 124 in IEEE Std. 1364-2005 (the last published separate Verilog standard). When compared to C (37 keywords) or JavaScript (42 current and future keywords), the numbers speak for themselves. This is in spite of the fact that the numbers of keywords needed as listed above for SV or Verilog may be a bit deceptive since those numbers do not include system tasks/functions (such as, $display or $error) or compiler directives as keywords.

While obviously neither the number of pages of a language standard nor the number of keywords it needs suggests anything about its efficiency, as an empirical measure, together they may. If the goal of IEEE Std. 1800-2009 was an integration of the two language standards, the next step will be to purge anything non-essential, duplicate entries from both languages, or even worse, competing entries from them.

This article proposes one potential area for efficient purging with one case study. Hopefully, it will encourage the SV community to start a debate towards finding other ways to make SV a better fighting machine to address today’s verification needs.

Verilog - A Kitchen Sink of Everything
Over the years, Verilog has been many things to many people. It is still the just about the only choice for RTL design (besides VHDL). It has been used, and is still being used, extensively by many as a Hardware Verification Language (HVL) for constructing testbenches. And then, at least one property checking library (Open Verification Library or OVL) has been built using Verilog.

In order to serve these disparate needs, Verilog had to add new features over the years that cater to various usages of the language. In addition, there were language features that were introduced initially (ostensibly to cater some early users), but today nobody is sure why those features still exist.

As the language standards for Verilog and SV evolved and new features were added to these languages (sometimes introducing new keywords), previous facilities that addressed the same needs that these new features addressed more efficiently now were left behind. This was done to maintain backward compatibility and to keep legacy code could still be compiled.

Is it now the time to take a second look into these duplicate features and get rid of the extra baggage that IEEE Std. 1800-2009 is carrying on its shoulder?

Verilog PLA Built-in System Tasks
Since its early days Verilog has 16 PLA (Programmable Array Logic) related system tasks which now have found their way to be part of IEEE Std. 1800-2009 (see the blue box to the left).

From hardware perspective, the usage of programmable array logic over the years has evolved into more complex FPGA products, though simple programmable logic array chips still exist today (for example, see [2]).  Most of the current usages of these PALs are for board level logic, not for chip design.

It is doubtful how much functional verification is done on this type of logic. In a survey [3] conducted on functional verification related groups on LinkedIn,  more than 75% responded that they did not use these system tasks in their verification environment in last 10 years or more with 60% of them responding they never used it ever.

Given this, it is only reasonable to think whether these system tasks should be deprecated from the language. If they are, a migration path for the users of these system tasks should be provided.

Enter smPla to the scene.

smPla – A Case Study
‘smPla’ is a case study in replacing Verilog system tasks with SV language constructs. It is a freeware package [1] that mimics the functionality of all 16 PLA related Verilog system tasks using only ‘native’ SV language construct. The package is now available in Beta and is in Version 0.1. It is distributed under GNU Public License Version 3 (GPLv3).

To its users smPla is a simple Verilog module-based wrapper that hides the complexity underneath. It employs only one module to replace all 16 system tasks. It does so by on-the-fly customization of the module in two ways:

1. Customization of personality array width and depth is done by parameterizing this module and then passing the appropriate values of the parameters during instantiation (see Table 1).
2. User can also customize

a.    The sync or async type,
b.    The type of the logic (or, and, nor, nand, etc.) and
c.    Array versus plane over simulation time by passing appropriate values to two inputs to the module (see Table 2).

Internally, the module employs an always_comb process to evaluate the inputs and compute the outputs based on the personality array.

Besides the core logic, the package also contains test bench, build and documentation directories.
The package smPla is supported by any simulator compliant to IEEE Std. 1800-2009. It is tested in Synopsys VCS 2009-06, Mentor Graphics Questa 6.6b and freeware Icarus Verilog.

Conclusion and Call to Action
smPla is a simple example of how a set of seldom used system tasks can be replaced by native SV code freeing up the responsibility of the language to provide such system tasks or functions. The module defined in the package smPla can be used similar to any other verification IP and can be compiled in only when it is needed using `include macro.

Are there other system tasks/functions in SV that can be similarly replaced using native SV constructs? With 98 such system tasks or functions (as of IEEE Std. 1364-2005) in Verilog alone and several more in SV, probably it will not take too much effort to find one or more. The harder task is, of course, to build consensus in the SV community to debate the need for a leaner SystemVerilog language to make any such replacement happen.

Hopefully this article will start the process.

Postscript: Upcoming IEEE Std. 1800-2012, the next revision of SystemVerilog language standard, has 1304 pages as of its 6th draft.

References
[1] smPla website on SourceForge: http://smPla.sourceforge.net
[2] Texas Instrument TICPAL22V10Z-25C datasheet, http://www.ti.com/lit/ds/symlink/ticpal22v10z-25c.pdf
[3] http://www.linkedin.com/groupItem?view=&gid=117645&type=member&item=96037949

Author Biography
Swapnajit Mitra works for PLX Technology where he is responsible for designing input-output chips. Swapnajit is a past Chair of SystemVerilog Standard Committee and his website http://www.project-veripage.com  promotes use of SystemVerilog. The views expressed here are his own.

---

If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).