Viewpoint: Towards a lean and mean SystemVerilog

While neither the number of pages of the SystemVerilog standard nor the number of keywords it needs suggests anything about its efficiency, as an empirical measure, together they may...

IEEE Std. 1800-2009 – A Merger of Two TitansIEEE 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 EverythingOver 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 TasksSince 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:

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).

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.

Conclusion and Call to ActionsmPla 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.

Author BiographySwapnajit 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]).

Thanks Dennis and others for giving inputs to the thread. I was attached to the development process for SystemVerilog, so my opinion may be biased. Nonetheless, as the author of this article, I felt I might as well throw in my 2 cents in response to Dennis’ questions.
Overall, I think there are 3 different topics:
1) Should we eliminate PLA system calls from a combined Verilog and SystemVerilog?
My response to this is obvious from this article. I have not seen anyone cheering to keep them as they are. I am assuming we all concur that no tear will ever be shed if they disappear.
2) Should we look into the SystemVerilog LRM for all redundant/duplicated/competing features and scrutinize them for possible elimination?
My answer is - once again should be obvious from the article - Yes. I never heard anyone arguing in favor of keeping anything that is redundant/duplicated/competing/inefficient or something that makes the overall language cumbersome. I would assume everyone concurs on this as well.
3) Should we throw away SystemVerilog all together and start from anew?
Although it may seem like just the other day, SystemVerilog has been around now for about 10 years in real code that verified real system. Just as in any other language, SystemVerilog may have flaws and any such flaw needs to be corrected. But rejecting SystemVerilog all together will amount to throwing the baby with bath water and will negate the investments made by all concerned - users in building their knowledge, companies who developed their products using it and of course the EDA companies. Or, in other words, I do not see disagreement here either.
In light of the above agreements, if I may re-state the 'Call to Action' part one more time:
(a) Accept the fact that SystemVerilog still needs to go through growing pain, continuously cleaning up any flaw it may have,
(b) Contribute to the above process by participating in standard activities,
(c) Use SystemVerilog in all of your projects.

This is reminding me of Stuart Swan's claim the other day at his IEEE talk that the "language wars" were over. It would be true if they all worked properly, but they don't. VHDL is particularly bad with respect to simulation semantics - i.e. it's crap for modeling.
Verilog-AMS which is key to modeling analog things - like power-management - has not been integrated with either of these "titans", so I expect things will get worse before they get better.
SystemVerilog is an unholy mess, and I voted that it shouldn't go to the IEEE before being cleaned up. Recent SV additions for discrete analog modeling are completely dysfunctional - and were done deliberately ignoring existing Verilog-AMS approaches.
Is there a fix? - definitely, but I don't think there is enough space here to get into that, and I can think of some people that won't like it.

Swapnajit,
This reminds me of the "first 'shot over the bow' in the VHDL 1998 wars" by Krolikoski, Levia & Ussery of Cadence. (http://www.it.uc3m.es/~ifip/chdl97/tut-mb.html) The war never happened.
At the time the "trimming" was suggested the team I was a member of was in the market with a rather full implementation.
While there may be a few who have to know all or ever will know all of SystemVerilog, the specializations by many allow a subset of it to be used to make the task of designing and verifying something that can be accomplished.
I am open to hear what others think would be a good alternate to what exists today. Should we start from scratch with something new? Or should we just remove that which no longer represents the state-of-the-art, like the PLA system tasks?
-Dennis

To answer your question 'if there is no longer a need for PLA system tasks why would anyone bother to implement a replacement in SV?'
This is the line from the above article: '...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.' The users of these tasks are small but not zero.

Nice idea to thin down Verilog/SV but your case study sort of contradicts itself. If there is no longer a need for PLA system tasks why would anyone bother to implement a replacement in SV?
Maybe Verilog/SV has become the COLBOL of the EDA world?
BTW if they count "begin" and "end" as Verilog keywords, then { and } should be counted as such in C/Java ;-)