Thoughts on Verification: A ‘Fresh’ Look at UVM (part 2 of 2)
In Part 2, Verilab consultants Alex Melikian and Vanessa Cooper discuss some of the challenges of learning and adopting the UVM into a new verification environment, or an existing one. They also provide tips and available resources to help one accelerate their ramp-up and adoption process. Part 1 can be viewed here.
Alex Melikian: Let’s talk about the learning curve involved with adopting UVM. These things always imply an initial investment in terms of time. What do you say is the quickest payoff or quickest ROI that someone can gain from using UVM?
Vanessa Cooper: Well, I guess I’ll go back to the reuse issue. You’ve created some code – say, an AHB VIP. Hopefully, the next person who needs an AHB driver doesn’t have to reinvent the wheel because you’ve already created it. If they can pick it up off the shelf and run with it, that’s the quickest payback.
And once you get over the hump of learning the UVM I think productivity increases because everybody’s marching along the same path. You know where the files are. You know what type of files you need to create.
And it’s just a lot easier when someone new comes in, and they know UVM. They don’t have that huge learning curve of “okay now, where would I find my stimulus?” They know exactly where that is. That is another quick payback. But like you said, there is an initial learning curve. I’ll go back to what you said about the registers. I think on my first UVM project the register model was the biggest thorn in my side because it was a tad bit more challenging to learn than just the basic concepts of getting stimulus up and going.
And it took awhile of really stepping through the library, understanding what was going on, and how the register could be used as a scoreboard, how to do checking before I got it up and working correctly. Now, once that’s done, doing it again is simpler.
AM: So you do feel that there is a quick payback, and it’s not just a long, arduous intellectual investment. Hence there are aspects of it – if done correctly – that can payback quickly.
VC: As far as intellectual investment, that should be evaluated on how a team wants to continue improving their verification environment. Whether that’s with UVM or another type of methodology. Hopefully, if someone sees a way that UVM can be greatly improved they would send that feedback to the Accellera committee.
So there is a quick payback from UVM, but I’m hoping that UVM is something that is long term as well because every two years you don’t want to be switching verification methodologies. That is just counterproductive.
AM: Yeah, I’ve been there – a lot of frustrations with methodology libraries earlier on. AVM went through a few versions. Then OVM came along when just as I felt I was settling in with AVM and that investment was paying back. And it didn’t seem long before UVM followed.
So yeah, there have been quite a few changes. However, it’s been over two years now since the UVM ‘early adopters’ version was released. There doesn’t seem to be another change on the horizon, and it looks like the industry is backing UVM very well and sticking to it.
So let’s talk for someone who is working with UVM for the first time, what do you think are the most helpful resources you can suggest to him or her?
VC: Well, back to documentation. The documentation is probably still the first place to go. There are two main documents, one is the Accellera standard, and the other is the user manual, which is a set of recommendations and examples. If you can take advantage of a UVM training course, that’s great because it’s always great to learn some of the material, actually do the lab, and work with it. Now, we’ve probably all been through a few training courses. You’re not going to become a UVM expert after taking a three-day class, but it does give you a good head start to start working on your own project. I also advocate reading the code. Now, you shouldn’t just print out the UVM library and sit there and read it; but as you’re working with it, don’t be afraid to step through the code.
It’s open source for a reason. Go look and see what it’s doing. Really with the register model, I had to do that a lot to understand, especially if something wasn’t working right. Okay, where is it going in the code? What was this code doing? Oh, now I understand. I’ve made a certain mistake that I can now correct. So look at the documentation but also check out the source code.
AM: That sounds like a good tip.
VC: And I would also encourage anyone if you find a bug in the source code to report it. I mean, UVM is only going be as good as the users make it.
AM: Yeah, let’s not forget that very important point. It is after all open to the community of developers and that the community should always keep an eye for bugs and bug reports. One thing I particularly like about UVM is that in the past couple of years, there seems to have been good traction with related resources that come from the industry, like whitepapers and presentations.
Recently, a YouTube video was produced. It’s sort of a 12 step or 12 lessons of UVM with some nice video production visually explaining the concepts for those not familiar with it.
Now I’m not trying to bash OVM, but does it mean that people who are using OVM right now screwed? Or is the transition from OVM to UVM easy?
VC: Well, I’ll say this before I answer the question. With the OVM along with the AVM and the VMM, you were tied to a particular vendor. If a user did a paper on it because it was they were going to a specific conference.
Whereas with the UVM being supported by the three major EDA vendors, you’re no longer tied to a vendor. It’s easy to adopt; and if you need to switch for whatever reason, you can do that. So people I think feel a little bit like there’s – they have this freedom now with UVM. And since all three vendors are supporting it, it’s not likely to change in the next year and a half to something new.
But are people who are using OVM screwed? No, I don’t think so. I think transitioning if you need to should be fairly simple. I learned UVM first, and now I’m working on a project that’s using OVM. And I knew that OVM and UVM were remarkably similar, but there are some differences. For example, there is a register model in UVM, and the configuration database is different.
So having worked with both now, I prefer UVM; but I think transitioning from OVM to UVM should be fairly simple. There’s some good material on how to do this from Mentor Graphics and from Cadence. Now, it’s not as simple as just changing all the O’s to U’s unfortunately. If that were the case, it would be the same methodology. But I do think anyone who’s learned OVM can easily transition to UVM without any trouble.
AM: It’s annoying when you hear those claims that all you have to do is just change the ‘O’ to ‘U’; and magically, everything gets fixed. But obviously, when you look under the hood and get your hands dirty with both methodologies, you notice that there are differences. They are subtle, but there are some key differences between the two shattering the promise that the transition is trivial.
There are, of course, a lot of similarities, especially at the conceptual level, that would make the transition easy from one to the other. But as you know, and as the saying goes: ‘the devil is in the details’.
VC: That’s true.
AM: So after you’ve worked with UVM, you actually had an opportunity to make a presentation on your experiences with it at the 2012 DVCon. That was also your first presentation, I believe; was it not?
VC: Yes, it was my first DVCon presentation, and I had an excellent time. It’s a great conference, and it was nice to be able to present on my experience of ramping up on UVM.
AM: I remember you mentioned to me after your presentation detailing your experiences with UVM that people were approaching you afterwards and asking you questions about it from a perspective of a ‘beginner’. Did that surprise you? Were there any typical questions that you got asked frequently?
VC: I was surprised. I was also surprised by the turnout in the UVM tutorial. It was an all-day tutorial. In the morning were mini lessons on how to code UVM; and then the afternoon was user experiences. People in the session ask a lot of thought provoking questions and you could tell they were really engaged. There was lot of energy around adopting UVM.
And I did get a lot of people afterwards saying they really enjoyed my presentation and they asked a lot of follow-up questions. The most common questions I can remember were on the UVM register package and it’s use model. It was great to see so many people excited about the methodology and to be able to be a part of the UVM tutorial at DVCon. I was able to really interact with some of my fellow verification engineers and talk to them about their experiences or what they’re about to undertake.
AM: It’s good to see that there is some substantial interest behind this. It’s not only a good sign to the industry but also a signal that they have something to build upon. They can use it as stable ground and continue developing this methodology for the years to come. However, it doesn’t stop there for you in terms of presenting and talking about UVM. You’ve been working on a book on UVM; is that true?
VC: That’s true. It’s entitled: Getting Started With UVM: A Beginner’s Guide. And it’s designed to be an introductory guide on how to really get started and understand the basics. My motivation for writing the book was “if I’m a verification engineer who needs to ramp up on UVM and I need to do it quickly, what’s a good resource to get started?” So that’s the direction I’m taking with the book.
AM: Sounds good, I look forward to reading it because it’s always interesting to reintroduce yourself to something like UVM. Also, I find there’s a lot of benefit to view something you already know from a perspective of a ‘beginner’, it opens your eyes to things you missed when you personally go through the process of learning something.
So that’s all the time we have. Thanks again Vanessa for participating in this conversation.
VC: Oh, thank you. I enjoyed it.
AM: Pleasure was all mine. Ciao Vanessa.
