In this edition, Alex Melikian discusses with Verilab consultant Jonathan Bromley about the various verification languages that exist today, and where they may be headed for tomorrow. Jonathan is a veteran consultant and author of numerous conference papers, including the SNUG Austin 2012 Best Paper “Taming Testbench Timing”. He has closely monitored the development of design and verification languages, and since 2005 has served on the IEEE committee that works on development of testbench features in SystemVerilog.

In Part 1, Alex and Jonathan review the different verification languages available today, their histories and differences.

Alex Melikian: Hello, Jonathan, thanks for joining me on this edition of “Thoughts on Verification”. So the theme of this conversation is going to be about verification languages, the ones that exist today and what they’re going to be like tomorrow. So to get started, for the readers out there who are not too familiar with verification languages, maybe you can run through a few of them and describe what exists and what is available.

Jonathan Bromley: Well, whatever I say, I’m sure it will be incomplete. But if you go back maybe 15 years, people who were doing verification of any digital designs were likely using the same languages that they were using to do the design itself. And I guess there’s a good historical reason for that because those languages typically were actually designed for verification. They were designed to model electronic systems rather than to create them. And it was only at the beginning of the 1990’s that logic synthesis became popular as a way of taking a subset of those languages and turning it into physical hardware. So it makes good historical sense that those traditional languages, typically VHDL and Verilog, would have been used for doing verification.

But it wasn’t too long before people began to realize those languages were running out of steam and weren’t flexible enough. They weren’t dynamic enough. They weren’t good enough at coping with the kind of software-like constructs like strings, for example, that you expect to be able to use. So people moved on, and we now see people doing verification with languages that may or may not look quite a lot like those earlier ones.

Nevertheless there is still a huge bunch of people doing verification using VHDL; there’s still a huge bunch of people doing verification with what we all know as vanilla Verilog (I mean, there’s no such thing as vanilla Verilog anymore; the standard got absorbed in to SystemVerilog a few years back, but people are still doing that stuff). But overwhelmingly, I think, if people are doing serious verification of their digital designs, they’re using dedicated languages for it.

So what have we got? Well, the obvious big hitter is SystemVerilog. That grew out of Verilog itself, and also some other origins we can talk about later. It began to come into the public consciousness around about 2003, began to get useful around 2005, and has become very useful recently with the availability of UVM. (I guess we’ll talk about that some more later). So SystemVerilog is here to stay. It allows you to take what looks quite a lot like traditional Verilog, and then suddenly, you glom onto it a whole load of software stuff like object oriented programming and strings and interfacing to C language constructs and a ton of stuff like that. It might be perhaps a little frightening for IC [integrated circuit] designers, but it’s cool for software people.

Then there are other people who are doing verification using much more traditional software-like languages. You may well have come across SystemC, which is an object oriented library totally written in C++. There’s nothing magic about it; it’s a class library written in C++ but carefully designed to be useful for modeling and verifying digital systems. It turns out that that’s most useful, I think, not for the IC designers but for the systems integrators and the system concept engineers who want to work out what the architecture of the system should look like, and model it, long before it’s designed. But nevertheless, SystemC is out there and doing good stuff for people in the verification world too.

Next, there are many, many people doing their verification largely based on C or C++ code integrated with their Verilog device-under-test using features of the simulator that let you do that, the PLI or VPI features. And of course, once you’re in a language like C or C++, you can do basically what you like. There have been a few libraries developed by various third parties. I guess, again, we can talk about those later, too.

AM: I certainly think that developing with a language that streamlines integration such that you can have the common code going to the target device or used in the simulator is quite beneficial. So it makes SystemC and C++ base environments still very attractive.

JB: Right, absolutely. Although it has to be said that it’s quite a big step from writing code that will execute on the target system, and writing the kind of C or C++ that will be used to do verification. You can do both those things, for sure, but there’s a lot of machinery in between those two things.

AM: Sure. Of course, it’s always easier said than done.

JB: Right. But as you say, there are a load of people doing that stuff and making really good use of it and modeling the behavior of their electronic systems in precisely the way they’re going to be used by the software that’s running on the application processor. And that’s a great thing to be able to do.

AM: What about the languages that were specifically made for verification like Specman/e and Vera?

JB: Okay… They’re kind of in between those two areas, I guess. Between SystemVerilog, which is absolutely the outgrowth of a hardware design language, and C++ which is absolutely from the software world. Somewhere in the middle, there’s a bunch of languages that were designed as dedicated verification languages. And I guess the two big hitters there are Vera, which is a Synopsys product dating from – I’m trying to remember now exactly when it was first introduced, but it was something in the order of 15 years ago – and e, the language that goes with the Specman product that is now marketed by Cadence.

So yeah, there are those interesting, dedicated verification languages. Vera, in fact, provided a lot of the impetus for SystemVerilog’s verification extensions, so there is a lot of commonality between the way Vera works and the way that SystemVerilog works. The e language that goes with Specman is quite a different beast, very interesting, fascinating from a software and language design point of view, and has its own strong army of followers for its own unusual and very interesting and very productive features. But there have been some other attempts at dedicated verification languages, too.

Going in another direction, there have been various different attempts to do verification using other standard languages hooked to a Verilog or VHDL simulator by specialized libraries. There are people using Python, for example, as their primary verification language. But I’m not aware of any commercially available products that make that possible with the kind of level of confidence for ordinary users that you would get from buying a SystemVerilog simulator, or Specman, or another of the commercial tools that we all know and love.

AM: We’ll get into that a bit later in the conversation. So you mentioned some of the languages that have come through from a background of design modeling and some from software modeling. Coming back to Specman or Vera, as we mentioned they have evolved from about 15 years ago. However, we don’t see so much evolution anymore in those languages. Is it because they’ve gone through their maturity process and plateaued? Do you see any more room for improvement in some of those languages? Especially, if we compare it to, say, SystemVerilog, which seems to be still in its process of evolution.

JB: Okay… I think it would probably be better to mute the microphone right now because anything I say at this point is likely to lead me into the law courts (laughs). But we have to accept the fact that Vera and e, the Specman language, are both proprietary in the sense that they’re absolutely owned by one specific corporation. And that ownership brings its own benefits and its own drawbacks for users. It means that that corporation can do precisely what they want with the language. If they see an opportunity to do something exciting and new, they can do it, as they have no standardizing body to answer to. But on the other hand, it means that a user is basically locked into a single vendor. [Editor's note: The e language in fact has an IEEE standard (1647), but the vendor's implementation has consistently been a superset of that standard.]

So that’s clearly a real compromise for users. They will see new, cutting edge ideas getting into the language faster and perhaps more effectively than they might expect with a more standardized language. But they’ve got the fear of being locked into a single vendor. What do you do about that? I can’t comment on that. That’s a decision that individual users have to make for themselves.

I kind of take issue with you, about you suggesting there was some stagnation going on there. I’m not sure it’s true because if you look at what’s happened to Specman, for example, over the last handful of years, it has had a process of steady development, cleaning up of raw edges, and general improvements. And it’s still heavily used by a significant user base. So is it stagnant? I’m not sure.

AM: Well, I agree that there has been a good, steady progression the past couple of years, but these changes have not been as ‘ground-breaking’ as the ones we were seeing about 10 or 15 years ago, when the language was still emerging in the industry. However, I think it’s natural for a new language to evolve very quickly initially and less quickly afterwards. I feel those languages have kind of matured. There’s always room for improvement, but I personally feel that they’ve reached a level of maturity whereas maybe the other languages are playing catch-up. It’s important that one must not confuse maturity of a language with the negative connotations of stagnation in its capabilities.

JB: Still, there’s a potential leading question going on there, isn’t there? Are you saying to me that Vera and e are now mature languages that are ready for prime-time use and SystemVerilog is not? Clearly, that’s not quite the situation. But equally, you’re right that there is a huge effort continuing in SystemVerilog to improve it and modify it and change it. And the standards committee is still active. It’s on the point right now of coming out with SystemVerilog – I was going to say 2012 but I’m not sure, it might end up being called SystemVerilog 2013 depending on precisely when it’s formally released. But anyway, there’s a new revision of the SystemVerilog standard coming out any day now. And then the standards committees will continue to work on the enhancement of SystemVerilog after that.

This entry was posted by Alex Melikian on Tuesday, February 5, 2013 at 8:33 pm and is filed under Interview, News. 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.