Thoughts on Verification: Verification Languages of Today and Tomorrow (Part 3 of 3)
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.
So my personal take would be that there are some extremely worthy efforts out there that have done really great things. For example, one that springs to mind is the library from trusster.com, which is a C++ library of verification tools that you can hook into a Verilog simulator. It works. It’s based on a standard language. So how bad could that be? But it hasn’t really taken off in a very big way – it hasn’t had industry wide traction – and personally I think that’s overwhelmingly because it can’t be as complete as it needs to be. There are things that it has not got around to doing, and that’s no criticism of the people who put it together. As I say, it’s a great job, and it does really good things. But you need your tools to be complete, otherwise, you’re always fighting.
And so somehow, you get some critical mass behind some tools. SystemVerilog is the obvious example of that. Somehow or other, the industry decided it was a good thing and collectively threw its weight behind the development of SystemVerilog. And - lo and behold - it’s now looking pretty complete, looking in pretty good shape, whereas some other approaches aren’t.
And the other requirement, as I said, is standardization. Anything that looks like it’s locked into a single vendor tends to make users jumpy.
AM: True. I think in these days, business is moving so fast and market forces change so quickly that development teams have to be ready to move quickly and adapt. Being locked into one vendor or tool can make some people a bit nervous.
JB: Right. And oftentimes, the choice of vendor is made at a somewhat different level than the technical people on the ground writing the code. And if you spent the last five years investing huge amounts of technical effort in building a verification environment in language ‘Y’, and then suddenly, your management tells you we must for commercial reasons move to a vendor that doesn’t support language ‘Y’, then life is not great.
AM: If I can suggest another verification language that’s out there and is not exclusive to any of the big vendors, it would be PyHVL. It’s based in Python, so you have all the qualities of that language at your disposal, in addition to its standard and open-source libraries. PyHVL also provides a VPI library allowing you to hook into any simulator that supports it, which is pretty much a standard feature these days. Of course, PyHVL is not a fully developed commercial product, so it has its limitations, namely there is currently no support for directly interfacing with VHDL. Also, PyHVL has no native constructs for making constrained-randomization statements, nor anything for implementing functional coverage. However, someone can creatively use the rich set of functionality available in Python libraries to construct something that would be a subset of these features. It’s not perfect, but I think PyHVL can make an interesting candidate for someone who is limited to choosing a verification platform outside those provided from the major vendors.
So let’s go back on the topic of completeness in the context of a verification language. When we say ‘completeness’, we’re talking about constrained-randomization and good support for implementing functional coverage. Of course, let’s not forget the ability to produce both high-level and low-level modeling. Am I missing something?
JB: Well, if you knew what we were all missing, then I’m quite sure your future would be very bright, Alex! But that sounds like a pretty good hit list to me. One of the things that really makes a verification language stand out from other general purpose languages is the way they provide dedicated support for randomization and coverage. Those are two things that are really quite difficult to code up as libraries in a general purpose language. You can do it -of course you can because it’s only code. But it’s very hard to do it in a way that looks smooth and fluid and convenient to use when you’re actually putting a verification environment together. And having dedicated support in the language is just exactly what you need. So I would always, writing verification code, go for a language that has that support if I got the chance.
AM: Definitely something someone has to look out for should they choose not to go with the commercial route, and is either limited to or wants to take a third party route when choosing a suitable verification language.
Well, that’s about all the time that we have, thank you Jonathan for joining me in this conversation on verification languages!
JB: Okay. Thank you, Alex. Good speaking with you.
