Get email delivery of the Cadence blog featured here
The Universal Verification Methodology (UVM) has compelling advantages for IC verification but can be challenging to adopt, according to panelists from four user companies at an Accellera breakfast at the recent Design Automation Conference (DAC 2014). Panelists discussed reasons for moving to UVM, costs of adoption, what's still needed, whether the current feature set should be "frozen," and the need for a multi-language UVM standard.
The panel was moderated by John Aynsley, CTO of training firm Doulos (far left in photo). Panelists were as follows, shown left to right in the photo below.
UVM provides a standard verification methodology that enables verification IP (VIP) reuse and supports features such as constrained-random test generation. It is derived primarily from the Open Verification Methodology developed by Cadence and Mentor Graphics. The current Accellera standard is UVM 1.1, and UVM 1.2 is soon to follow. While the current standard is based on SystemVerilog, a multi-language UVM standard is under development.
Following are some of the significant points made during the panel.
Q: What are the advantages of using UVM?
Newton: When you hire people, it's really helpful to find people who use the methodology. They can hit the ground running, look at the setup of testbenches, and understand the basics of it.
McKellar: We successfully adopted it. We did a bug analysis pre- and post-UVM adoption, and probably 70-80% of the bugs we find now are found with constrained-random methodologies. We're catching a lot of corner cases that we otherwise would have found post-silicon.
Bhinge: You get a cleaner verification environment that people all over the world can understand. There is better support from vendors, including third-party IP providers. You can fine-tune simulation and debugging performance. And it definitely helps us find and retain talent.
Q: Sounds like a UVM love-in. Is it really that rosy? What is not working well?
McKellar: Complexity. It is a feature-rich language that comes with a cost. We have found that it is expensive to get people up to speed. Also, we are expecting hardware engineers to take on constructs that in a lot of cases are alien to them.
Newton: We're trying to figure this [complexity] out as we move to UVM. Should we use macros or not? Should we use callbacks or not? Every vendor says something different. And performance is something I'm concerned about, especially with UVM registers.
Bhinge: We have a register modeling standard, IP-XACT, but it is not well integrated inside UVM. Vendors have chosen their own ways of doing register modeling. Most VIP is not built in UVM. That's a big challenge for us. There is no tool to convert from our internal methodology to UVM—it is all manual effort. And when I hear UVM 1.2 is not going to be backwards compatible, it scares me.
Elmalaki: When we defined the register model, we went with the simplest implementation that met the requirements. UVM is complex and will get more complex as we go. The challenge is to find an acceptable implementation.
Q: Where do we need to go from here with UVM?
Elmalaki: The first thing is to freeze [current] features for a while. There should be a very high bar for any extra feature to be added to the UVM class library, with strict backwards compatibility. The second thing is to focus on is quality—the amount of testing that UVM has had is not good enough. The last thing is to encourage community contributions. We should build over UVM rather than into UVM.
Q: Can we freeze the core of UVM?
McKellar: I'd be happy to freeze the core.
Newton: Right, a moving target in standardization is something we want to avoid. We are starting a multi-year project. We don't want to go back and start rewriting things, or find that something doesn't work.
Elmalaki: Eventually we will have to add features. The implementation can change, but the APIs have to remain constant. I cannot support absorbing more features into UVM before the existing infrastructure and existing features are well tested.
Bhinge: I'm not against changes, but we have to make sure they're well documented. Backwards compatibility is very important.
Q: Is mixed language support an issue for everybody? How do we need to solve it?
Elmalaki: I'm very optimistic about the multi-language working group. Multi-language UVM is actually our main technical activity for this year. We might need to modify some stuff but so far as I know, what we have right now is enough without modifying the APIs for multi-language.
If we standardize the way to do this, I can pick up a Specman e VIP or a C++ VIP and be able to communicate between them. I can work with an IP team that has learned a certain language, and we can verify the whole system. Certain languages are better for certain aspects. I might want to use a VIP that has added quality because it has been around for three or four years.
McKellar: We use reference models in C or SystemC as a large chunk of our verification methodology, but there is no [UVM] standard yet in multi-language. That is a huge hole for us. It is one of the key things that we in the industry need to put together.
Q: Are you using VIP from outside sources?
Bhinge: Yes. The big difference we see is that third-party IP and VIP are now talking the same language. IP and VIP support is getting better and there's a prospect for more improvement because [UVM] is a standard. I am very excited about that and I can see a big paradigm shift.
Q: What are the costs of using UVM? How long does it take for an organization to get up to speed?
McKellar: We adopted UVM three years ago, and we're not close to having consistent adoption in the company.
Bhinge: For us, it's been a year. We probably have 500 test cases in UVM now. It's not free—you have to train people. The presumption is that it will pay off in the long run.
Elmalaki: There's a high cost of adoption when you move from directed testing to random testing. That's the big investment. The UVM library is not that big a deal to adopt.
Note: You can learn more about UVM and download the 1.1 version from the Accellera website.
Related Blog Posts
- Accellera Approves UVM 1.0—Bold Step Forward for Functional Verification
- DVCon 2014 Video: HP Engineers Apply "Test Driven Development" to UVM-e
- User View: UVM Sequence Layering Brings IC Functional Verification to Higher Level