In part 3, Jonathan and Alex discuss some of the alternative verification platforms available outside those offered by the major vendors, and the qualities that make a verification language so effective at its purpose. Part 1 and 2 can be found here and here respectively.

Alex Melikian: Changing gears a bit, and I know I risk dating you here, but you’ve been around for a while and seen a lot of languages come and go. And of course some of them have stuck around. The verification languages that we mentioned at the start of this conversation were not the only ones that have appeared. There have been some attempts by third party groups, some of who have constructed and publically released their languages for verification.

For those that didn’t catch on, what do you think are the reasons they failed to capture the interest of the verification community? Or, asking this from another angle, what elements to a verification language are absolutely necessary for it to be considered viable and worthy?

Jonathan Bromley: Well, beware of my personal bias here, obviously, because for one thing I’ve been heavily invested in SystemVerilog standardization for some time now. And for another thing, I’m personally a little conservative in my nature, so I would say that the two things that I would be looking for in any verification tool are completeness and standardization. Completeness is required because I don’t want to have to reinvent wheels for myself. I don’t mind writing code; that’s okay. But I do mind doing stuff that’s going to be superseded by somebody else’s efforts six months down the line. And standardization because I want my skills to be portable and I want my code to be portable as far as possible; I want to be confident that a range of different tool vendors are going to be supporting whatever code it is that I write.

(more…)

Come join us at DVCon 2013 in San Jose, CA. Several of us from Verilab will be involved in the following activities:

• Monday February 25th, Tutorial Lessons from the Trenches: Migrating Legacy Verification Environments to UVM™ Mark Litterick presenting
• Tuesday February 26th, Poster session Paul Marriott presenting “Run-Time Configuration of a Verification Environment – A Novel Use of the OVM/UVM Analysis Pattern” and Mark Litterick presenting “Pragmatic Verification Reuse in a Vertical World”
• Tuesday February 26th, Paul Marriott is chairing the REGULAR SESSION: Case Studies - I
• Wednesday February 27th “Session 11 - Hardcore UVM-II” Mark Litterick presenting “SVA Encapsulation in UVM - Enabling Phase and Configuration Aware Assertion”
• Wednesday February 27th Luncheon Best Practices in Verification” Jason Sprott, panelist
• Wednesday February 27th JL Gray moderates Industry Leaders Panel: The Road to 1M Design Starts

Verilab is also sponsoring the Best Paper and Poster Award.

In Part 2, Alex Melikian and Jonathan Bromley discuss the upcoming additions to the SystemVerilog LRM, as well as their approaches to handling new elements or constructs of a language. Part 1 can be viewed here.

Alex Melikian: You’ve been following the developments of SystemVerilog 2012 very closely. Can you tell us about some of the new language additions that we should be looking out for in this upcoming version of SystemVerilog?

Jonathan Bromley: Yes. I’ve been involved in that more than any normal, reasonable person should expect to be. I’ve been serving as a member of the IEEE committee that works on the testbench features of SystemVerilog for the past 7 years.  I think there’s some very exciting stuff coming up in SystemVerilog 2012. It was deliberately set up as a relatively fast track project. Normally, the revision cycle for IEEE standards is five years, but SystemVerilog 2012 comes only two and a half years after the 2009 standard. So it’s really fast tracked. And it was very carefully focused on a small number of new features. So there’s not a huge list of big ticket items. But there are a couple of things in the verification world that I think are really important.

The first one is a big extension to flexibility of the coverage definition system. You can now define your cover points and your cross cover points in a much more sophisticated, much more algorithmic way than was possible before. There’s a big bunch of stuff that came out there, which looks really exciting. And I get the impression that the vendors are going to rally behind these new items very quickly.
(more…)

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.
(more…)