Feed on
Posts
Comments

Thoughts on Verification: A ‘Fresh’ Look at UVM (part 1 of 2)

The subject of this edition of “Thoughts on Verification” is the UVM, or the Universal Verification Methodology. Verilab consultants Alex Melikian and Vanessa Cooper discuss, explain and give insight to their experiences with the UVM. Before learning UVM, Vanessa had no previous experience with verification methodology. Hence, her opinions provide a ‘fresh’ point of view on the UVM, and what it can offer to the verification community.

In Part 1, Alex gives a brief historical summary on the UVM and its past predecessors. Vanessa talks about her experiences learning and adopting the UVM, having no prior experience with employing any verification methodology library. Alex and Vanessa also discuss UVM’s pros and cons from their respective experiences with it.

Alex Melikian: Hi Vanessa.  Thanks for joining me on this conversation.

Vanessa Cooper: Hi Alex.  How are you today?

AM: I’m doing fine, thank you.  So we’re here today to have a conversation about the UVM, the verification methodology widely pushed by the EDA industry. Not only is it available in SystemVerilog but also for Specman/e.  And before we get into it and your experiences with learning and using UVM, perhaps I should talk about its history for readers who are not familiar with it.

Well, firstly UVM is a verification methodology library standard, where open source code libraries are available as reference implementation.  The available libraries are under the Apache license, but in practical terms it is free. It is not a commercial product, nor an EDA tool.  It’s straight out code that is either based in SystemVerilog or Specman e, but its intent is to be used as a Universal Verification Methodology.  That’s what UVM stands for. Where it came about is from a lineage of previous verification methodologies from different EDA vendors.

If we stay in the SystemVerilog world, the first verification methodologies that came out were AVM and VMM. This was back around 2005-2006. The problem however was that these verification methodologies were tied to their vendors, even though in the case of AVM, which was open source. Of course, it should be mentioned that Specman had the eRM, which was released around 2003, when Verisity was an independent EDA vendor. I mention the eRM because many of its concepts were transposed into the UVM. Back to the SystemVerilog world, after AVM and VMM, OVM came along in 2008. OVM was an evolution of Mentor’s AVM with concepts from Cadence’s URM SystemVerilog methodology. VMM continued on its own evolving path. So again, OVM was not quite universal. OVM was supported and available on some of the major simulators, but not all of them.

And finally, a couple of years later, the EDA industry reached a consensus and produced the UVM. Which, as the name implies, is universal.  All major simulator vendors support it and provide it for their customers.  And of course, the advantage of this is that people can write compatible VIPs, the same code structures, the same look and feel of their verification code.

So in essence, UVM is a standard defining how verification objects and modules can work together.  I could go on, however, Vanessa, I would like to get into your experiences with UVM. Before we do that, maybe you’d like to tell our readers a little bit about your professional background.

VC: Sure.  I graduated with a Computer Engineering Degree from Mississippi State University; and upon graduating I moved to Austin, Texas, where I worked for Motorola and then Freescale doing verification for six years.  And then I took an interesting diversion in my career.  I worked for Cadence for five years doing support, which was really interesting because I got to see verification from a slightly different perspective and see how different verification engineers across different companies utilize tools and also methodologies in how they approach similar problems differently.  After that, I had the urge to do verification again, and that’s how I landed at Verilab last year.

AM: Yes, I remember we did our first assignment together.  It was to experiment with UVM, and both of us had no prior experience with it.  I want to focus on your experiences.  What was your first impression of UVM? I’m particularly interested because you don’t have that typical background of a verification engineer and you had never previously worked with any of the other verification methodologies.

VC: Well, my first impression was that it was really kind of neat because it seemed like this “magic under the hood” thing that was delivered to the customer.  Obviously that’s not the case, but it’s really innovative that the top three EDA vendors, along with Accellera, could collaborate and develop this methodology.

UVM is an Accellera standard available for SystemVerilog that will really help verification engineers and design houses in general increase the effectiveness of their verification cycle.

AM: So what was the first myth or misconception you felt was shattered as you were getting more familiar with it?

VC: Well, I guess I had heard repeatedly how hard UVM was to learn; and I wholeheartedly disagree with that.  And I think the reason people think it’s hard is something you alluded to in your introduction.  UVM is a library, and that’s it.  It’s a library based on SystemVerilog, so people have the idea that oh, to adopt UVM I have to learn this new language.

UVM is not a language.  SystemVerilog is the language.  UVM is just a library that’s created to help you utilize SystemVerilog.  And I think once people get over that fundamental hump then learning it becomes a lot easier.

AM: Well, you say ‘people’ were having trouble with it or had these misconceptions of it.  Were there any specific groups or any specific individuals?

VC: Oh, I just think verification engineers in general that were trying to adopt it.  Management says, “Okay, on this next project we’re going to adopt UVM.  And they engineers are thinking “Oh, great.  We have to learn another methodology and another language.”

But it’s just building on what you already know.  It’s code that’s provided to you so that you can standardize what you’re doing and reuse components of what you’re doing, so you’re not learning a new language.  Don’t get me wrong, learning UVM takes time.  But you already have the fundamental knowledge if you know SystemVerilog, or if you know object-oriented programming.  And once you realize that, I think learning the library is a lot easier.

AM: Okay.  So what quirks or hang-ups do you think someone will have when they’re first working with UVM?

VC: Phasing.  Phasing is exactly what it sounds like: in a certain phase you do certain things.  In the next phase you do certain things.  So for example, in the build phase you’re basically creating all of your dynamic objects, your components.

And then you have an end of elaboration phase and start of a simulation phase or run phase where most of the activity happens.  The simulation is segmented into those phases so that you know when everything is happening.  Everything happens at the appropriate time, so you’re not trying to do something before an object is created.

But phasing can be a little daunting at first when you’re trying to use it and understand exactly how those phases interact and work together.  And during your run phase, there are phases within that phase which can be a little confusing.

AM: That’s an interesting and interestingly specific answer.  If I would venture a guess as to why UVM phases would particularly be the major hang-up for most people, it would be because it’s a paradigm from software that can be a bit alien to those who are used to thinking in a mindset of hardware. Despite the existence of concurrency, things in hardware can be quite sequential, like a state machine; it’s one state, one set of associated operations at a time.

Whereas UVM phases can be quite orthogonal, multiple related operations happening in parallel, like a multithreaded software program.  So that’s an interesting answer.  But what do you think was the trick that helped you get over your hang-ups when you were learning UVM?

VC: I think anytime you’re learning something new it’s good to have good resources, and I know we’ll probably talk about this a little bit later in the conversation, but I know I had to refer a lot to the documentation or the code to really understand what the phases were doing and look at examples too.

Once I understood exactly what needed to go in a certain phase then once you did it the first time, doing it again it was easier.  Once you get over that first project or VIP [Verification IP] and gone through the challenges of development, the second one is not as difficult.

AM: So you’ve had a few opportunities to work with UVM and face a few challenges in the industry with it.  Now that you have some of that under your belt, what do you think are the greatest advantages of using UVM?

VC: Well, probably the greatest advantage is obviously to enable reuse capability.  I can create a UVM component or VIP, and someone else from let’s say my team or a different group can come and pick up that VIP, which is just an encapsulation of code.  Pick that up and plug it into their UVM environment with little effort. So that’s the greatest advantage in my opinion.

AM: And when you say ‘with little effort’ do you mean look and feel and APIs of all the blocks are standardized?

VC: First, I think it’s important to go over all the bits that are involved in creating VIP. With the UVM you have the concept of agents, which contain your driver, your sequencer, your monitor; and so you can create this agent for whatever – let’s say an AHB bus protocol.

And so if another group needs that, they can just come pick it up off the shelf so to speak and plug it into their environment and drive their AHB interface because they’re using the same methodology.

AM: Now nothing is perfect in this world, and the UVM is no exception. As a member of the Accellera VIP Technical Subcommittee since 2008, Verilab has been involved with the development of the UVM from the start. UVM is a work in progress, and it’s clear that some areas have room to improve.  I believe some of the documentation can be improved, particularly the more recently added features like phasing and the register package. Time and care should be employed when trying to introduce these concepts, especially to inexperienced users if we hope for UVM to gain a higher adoption rate.

Users interested in filing bug reports or suggesting feature enhancements to the UVM can contact the VIP-TSC directly via the Accellera website (or as described here).

How about you Vanessa? Where do you feel are the areas that the UVM can improve on?

VC: The UVM reporting mechanism – and I think this is something that is actually being worked on – should be able to generate reports in different formats that you could easily publish and then go through and pull out information that you want from a particular simulation, as opposed to just creating one huge log file that you’re trying to traverse to find whatever information you need.

I do think one great thing about UVM is that the top vendors support it since it’s an Accellera standard. You have a team of devoted volunteers who are working on the code. They are constantly working to improve the code and getting feedback.  So I think as time goes on, we’ll see a lot of great improvements.

[ ADDENDUM:

A few clarifications and corrections were made in the section describing the evolution of OVM in regards to AVM & VMM. Also clarifications were added specifying only AVM was open source to the public, whereas VMM was not. ]

Leave a Reply

Captcha
Enter the letters you see above.

Work For Verilab