Why C/C++ Is the Lingua Franca for Verification

In last week’s post, we dissected the results for verification languages and methodologies from a recent survey by Mentor Graphics and Wilson Research Group. The main result was that SystemVerilog is growing in popularity on all fronts, but we observed that C/C++ has a significant presence. We also argued that the survey’s focus on simulation likely resulted in C/C++ being under-represented since these languages are widely used for verification with hardware platforms and for silicon validation in the lab.

We see C/C++ as the common link for many types of programming activities, and so widely known that many consider it the lingua franca of software. Just type “lingua franca C/C++” into your favorite search engine and scan the results for some interesting arguments and a few counter-arguments. To be fair, some observers consider C the lingua franca and downplay C++. We tend to group them together since object-oriented programming is now widespread and so moving from C to C++ should be a natural transition.

In addition to the Mentor EDA survey, we looked at some other wider measures of popularity and usage for programming languages. IEEE recently did its second annual assessment on this topic. In their list, Java just edges out C, followed very closely by C++. Python and the “multi-paradigm programming language” C# round out the top five. Below that we find the R “big data” language, PHP, JavaScript, Ruby, and Matlab.

Clearly C and C++ remain hugely important to programming in general, which is actually one of the reasons they’re popular for verification. It’s easy to find engineers with experience in C/C++ and so much of the EDA infrastructure is written in these languages. Because C was designed to be relatively close to the hardware for efficiency purposes, it is widely used for “bare metal” software from simulation through hardware platforms, all the way to silicon in the lab.

Java may be slightly more popular than C, but we don’t see verification engineers writing bare metal test cases using Java, or PHP or Ruby for that matter. There are many languages used to write applications that run on top of an operating system or RTOS, and these do figure into chip validation. Ultimately all SoC teams want to boot Linux and run some apps on in-circuit emulation (ICE) system or an FPGA prototype before taping out. Once the silicon arrives from the foundry, they will repeat the process.

However, as we’ve pointed out before, production software almost never runs immediately on a new platform. Further, it is not efficient at finding or diagnosing lingering design bugs. The verification and validation engineers need bare metal test cases to ensure that there are no hardware bugs and to work their way up to booting an operating system and running apps. They almost always write these test cases in C/C++ because they need to be manually adapted for each new platform and all the engineers involved know this lingua franca.

Returning to the topic of a portable stimulus standard, it makes perfect sense that the automatically generated test cases be in C/C++. The verification and bring-up teams already know these languages and have the programming development environments and infrastructure in place to support them. They can run the test cases on the SoC’s embedded processors in any platform just as they used to run their own hand-written tests.

Finally, we come to the question of the input format for the portable stimulus standard being developed within Accellera. As usual, we’re not going to reveal any internal discussions of the working group but, as we have noted before, there are a number of directions that the standard could take. The final result might be an existing language (or multiple languages) with an API, extensions to an existing language (or languages), or an entirely new language.

As we mentioned last week, we have shown in a series of posts how a portable stimulus solution can be supported by C/C++ and a simple application programming interface (API). We believe that this is the best approach for the standard because so many of the engineers who will write portable stimulus models already know C/C++ and are comfortable with that input format. There are others in the industry who support a new language instead, so it will be interesting to see how it all turns out. As always, we welcome any comments that you may have.

Tom A.

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

Tags: Accellera, API, Breker, C/C++, EDA, ESL, functional verification, horizontal reuse, Java, Mentor Graphics, portable stimulus, PSWG, Python, Ruby, simulation, SoC verification, subsystem, SystemVerilog, uvm, vertical reuse, VHDL

This entry was posted on Tuesday, November 17th, 2015 at 4:11 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.