In the early days of RTL verification, the Verilog language was perhaps the most likely language to be found being used as a verification language as well. Others preferred the C language because of the additional flexibility it gave them and its ability to inject some degree of randomization. But it was soon realized that this was not enough and a new breed of languages was developed, primarily represented by Vera and the e language. These languages gave birth to the new verification methodologies that are now common place in the industry, namely, constrained random test pattern generation. Those languages, while great for what they do, did not seem to fully please the industry in that they started to call for a single language that could cover both design and verification. It is not clear if this really was a user driven call, or if it was a call concocted by the EDA companies to try and displace the market leaders. Whatever the reason, SystemVerilog came along to fill that need and it would appear as if this is quickly rising as a popular RTL verification language, even though it appears to have had less success with adoption as a design language.

Now, as we move to ESL, the market has responded quite loudly to the fact that SystemVerilog is not the language of choice for abstract design. The most popular languages right now fall into three camps. The first is C and C++. There are lots of people who know how to program in these languages, they are heavily used in the software domain and the systems engineers seem to quite like them. Second, there is SystemC – an extension of C++ that includes hardware specific concepts. I put this in a different camp because I believe it does significantly change the mindset of the solution space and the types of people that are likely to use it. This language allows hardware datatypes to be defined and has explicit control over concurrency. The downside is that it is a new language that must be learned even though at its heart it is still C++. Finally, there are the dataplane people who usually start in MATLAB, and find the M-language the best suited for their needs. No-one that I know of, is using SystemVerilog as a system level language and no vendor has released tools that support it above the RTL level except for inclusion of a few extensions that have made it into RTL synthesis tools.

So the question is – what will eventually happen in the verification languages space for ESL? In figure 1, we take a look at the languages that are prime candidates for adoption as an ESL design languages. There are high-synthesis tools on the market today that support all three of these. However, none of them presuppose a suitable verification language.

Figure 1: Design and Verification Languages

The C, C++ languages were deemed unsuitable for verification many years ago. This is because it leaves too much work to the verification environment developer and does not define consistent interfaces that could be used to support a 3^rd party verification IP community. Just because the design flow is now potentially using them does not automatically make them the right choice for verification. Attempts were made some years ago to create a set of classes that would make it possible for SystemC to be used as a verification language. There are some people who have adopted this and it is in use in some companies, but there are severe limitations with this when compared to the capabilities provided by languages such as Vera, e or SystemVerilog. So, while we can expect to see SystemC used as a reference model, and potentially for some other parts of the verification environment, it is unlikely to become the exclusive language for the entire environment. Finally, there is the M language, and while I am not fully conversant in this language, I do not believe it provides anything that could be considered as a modern verification language. It is possible to provide a few directed test cases, but this is the extent of its capabilities.

Now we have to add into the mix that there is a strong need for a single language to be used at all levels for verification. Unlike design where there is a synthesis process that can transform from one language to another, there is no such equivalent for the verification flow. The testbench created for functional verification at the ES level must be the same testbench that is used to verify functionality in the implemented RTL model. Plus we need to have the ability to incrementally add to the verification suite, without having to go back and modify the original source. This is in effect, the same requirement as exists for the design flow such that many implementations can be derived from a single source without having to re-verify that original source file. We need to ensure that the testbench is not damaged in any way just because we wish to add additional capabilities to it to include added functionality or features that come in during the design process.

SystemVerilog caused the creation of two methodologies that attempt to encapsulate verification components into building blocks – namely OVM and VMM. Perhaps these are the key to the next generation of verification language. These methodologies create a transaction level interface between the components and this becomes suitable for both ESL and RTL verification needs. OVM is also multi-language capable, supporting SystemC and e in addition to SystemVerilog. This, in my mind, gives OVM a distinct advantage. In addition, Accellera has recently decided that this is the best base on which to move forward with the development of a standard verification methodology library. In addition, the choice of OVM also makes the e language a contender again. There are many companies who are still committed to e, and its aspect oriented features make it better at dealing with incremental capabilities than SystemVerilog.

Another possibility is to look at some of the new verification companies that are being formed these days that use more declarative languages for the verification environment. Will these languages evolve into the next generation of verification language?

I would love for you to weight in with your opinions on this, and find out what you think are the most important requirements are for the next generation verification languages.

-----------------------------------------------
Brian Bailey - keeping you covered