Verification Languages: Tower of Babel?

One of the cliches we hear from time to time in the industry is “designers want to stick with a single language, but verification engineers love learning new things.” The implication seems to be that because verification engineers have diverse jobs that require them to juggle lots of different tools and models, they necessarily have to learn new languages and methodologies on a regular basis. Of course, they may not actually love learning new languages; doing so may just be in the nature of their work.

Regardless of whether or not they “love” new languages, it is clear that most verification projects involve multiple languages and multiple approaches. One way to gauge the current situation is to turn to the excellent survey that Mentor Graphics performs with Wilson Research Group every couple of years. Harry Foster wrote a series of posts on the Mentor verification blog that give considerable insight into what verification (and design) engineers are doing on real projects.

For our purposes today, the most interesting result is the trend in verification language adoption for ASIC and IC development. Unsurprisingly, SystemVerilog is dominant (used in over 60% of testbenches) and still growing. VHDL and pure Verilog have both dropped off dramatically from their peaks. But the two other major languages that support constrained-random simulation, SystemC and e, each have more than 10% usage. About a third of the testbenches also use C/C++, also not surprising since linking to C reference models and running embedded code in SoC simulation are both common practices.

It’s also no surprise that two-thirds of the ASIC/IC testbenches have adopted Accellera’s Universal Verification Methodology (UVM) standard, although there is still some usage of legacy methodologies from Synopsys, Cadence, Mentor, and Cadence+Mentor. When assertion languages for simulation and formal analysis are considered, SystemVerilog Assertions (SVA) are used on fully three-quarters of the projects. However, the Property Specification Language (PSL) and the Open Verification Library (OVL), also both Accellera standards, are holding fairly steady at 10-15% usage.

The Mentor survey also covered FPGA projects, where the results are similar but with a few noteworthy differences. For verification languages, SystemVerilog is on the rise but has yet to cross the 40% line. VHDL is used for more than half of the testbenches, with Verilog not far behind. C/C++ usage is a just a bit lower than for non-FPGA projects, but SystemC and e play almost no role. For methodologies, the UVM sits at 40%, with most of the legacy methodologies in the same range as for ASIC/IC.

Three results stand out for FPGA verification versus ASIC/IC. First, SystemVerilog and UVM adoption appears to be about two years behind. Second, there remains greater use of “none/other” methodologies, which could mean primitive 0/1 testbenches rather than constrained-random.  Finally, assertion adoption is dominated by SystemVerilog but usage is at 40%, just over half that for ASIC/IC projects. These conclusions mirror the common belief that the average FPGA project is less complex, although there are plenty of FPGA SoCs as well.

The results from the survey are certainly interesting, and we thank Mentor for providing them to our industry in such a useful and professional way.  One could easily conclude that the historical Babel of verification languages and methodologies is giving way to a unified focus on the UVM and SystemVerilog (including SVA). Incidentally, the design language results also show a partial shift toward SystemVerilog. So is there really one language that can do it all?

One observation about this survey is that is considers testbenches and assertions, but not the rest of the complex environment needed to verify a large ASIC, IC, or FPGA design. Scripting languages are used extensively to tie tools together and automate the process. Python and Perl are very common, with legacy Unix tools such as sed, grep, and awk sometimes in the mix. Some of the linking programs are written in C/C++ for efficiency purposes, so we suspect that the wording of the survey leads to an under-representation of C/C++ usage.

Last but certainly not least, the scope of verification for this survey seems focused entirely on simulation and formal. Electronic system-level (ESL) architecture, performance, and power assessment is usually performed in a C/C++/SystemC environment. Further, many chip projects use in-circuit emulation or FPGA prototyping as a critical part of their pre-silicon verification. Then, once the chip has been fabricated, it must be validated in the bring-up lab. In all of these three hardware platforms, there is no testbench, UVM, or SystemVerilog.  Bring-up tests and diagnostics are almost always written in C/C++.

We’ve argued before, in the context of a portable stimulus standard, that C/C++ is the closest thing we have to a universal verification language. We presented a series of posts in which we showed how all three layers required by a portable stimulus solution can be supported by C/C++ and a simple application programming interface (API). No new constructs or new languages are needed. We’ll pick up on this idea next week, but in the meantime please comment with your thoughts on the verification languages you use now and intend to use in the future.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, API, Breker, C/C++, Cadence, e, EDA, ESL, functional verification, Harry Foster, horizontal reuse, Mentor Graphics, OVL, portable stimulus, PSWG, simulation, SoC verification, subsystem, Synopsys, SystemC, SystemVerilog, Universal Verification Methodology, uvm, vertical reuse, VHDL

This entry was posted on Wednesday, November 11th, 2015 at 6:10 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.