Main Menu

Search

Quick Links

There’s been a lot of buzz about the UVM lately and for a reason. The Universal Verification Methodology is about to change the rules of the game pretty soon, if not already. That is interesting because not too long ago verification engineers questioned the need for adopting any verification methodology… Today, however, the question is entirely different – it is WHICH methodology to adopt. So as the UVM is gradually taking form and drawing the attention of verification stakeholders I think it’s a great time to stop and remind ourselves why we need a verification methodology in the first place, and more importantly - what makes a verification methodology so good that the only question about it would be “how quickly can I learn it”? I have identified 3 elements of a good verification methodology that work together, each on a separate track, to make it do its magic. The first element is Guidance, the second is Efficiency, and the third one – perhaps the most exciting one – is what I call The Real Added Value.

Guidance

To benefit from a good verification methodology you have to pay a price. You must take the time to learn it. But as with all successful investments, you will see return on your invested time and energy once the learning curve is over. Nevertheless, a good verification methodology should be compiled of a collection of relatively simple (yet powerful) principles. Those principles, that should be fairly easy for you to understand, will guide you and provide you with the basic concepts and approaches that form the foundation of your verification environment. For example, code encapsulation rules and topology guidelines. A good methodology should also provide guidance on more mundane issues such as naming convention, common terminology, file names, etc. These will help you keep a good level of uniformity and consistency across your verification environment. Guidance should be given also on the best known verification methods and how they can be implemented. Now the most effective way to deliver all that information to prospective users, is by providing them with many examples and tutorials. Reference manuals are great too, but most of the times a good example or a code snippet can do the job much quicker. A good methodology should also be good at educating its target users.

Efficiency

Obviously you adopt a verification methodology with the hope that it will help you become more efficient. Why else would you bother? Don’t worry. A good verification methodology will help you save precious time. How? That’s easy. Verification methodologies provide “off-the-shelf” constructs and components that help you avoid “reinventing the wheel”. Need a generator? No problem. We've got one for you, just instantiate it and you’re ready to go. But not only that, code integration becomes ten times quicker when everybody uses standard elements who all share a common API. This is a powerful thing. Another example of how a verification methodology can help you save time is the Register Package. This kind of code package – that usually ships with any leading methodology today - will help you model and simulate the entire register activity in your chip and save you tremendous amount of time by simply introducing automation to an area where it didn’t exist before. Today register packages provide a powerful API and can also run automatic tests for you. So less code to develop, less bugs in the environment and less time spent on code integration all translate into quicker time to market. Another nice thing about sticking to an industry standard methodology is that it’s out there, available to everybody else as well. And so, 3rd party developers are encouraged to develop extensions and utilities that can sometime help you become even more efficient. For example - a utility that further automates register modeling, straight from MS WORD.

The Real Added Value

You might not be able to sense it upfront, but adopting an industry standard methodology comes with more value than meets the eye. For instance, If your verification environment is kept XYZ-compliant, then it implicitly promotes reuse! Much has been said about the “price” you have to pay to make your code reusable, but the truth is that if you stick to your chosen methodology, reusability will take care of its own. The components you develop will be reusable in the context of your current project, and possibly in the context of other ones. Another great thing about methodology is that it helps you think about your environment in a top-down manner rather than a bottom-up manner. Your natural habit, especially if you’re less experienced in verification, might be to construct your environment from the bottom up which might turn into trouble at the code integration phase. Unless you have a solid methodology, that is. The thing is, verification methodologies help you visualize the overall verification architecture that’s needed for your project by showing you how low level components will fit perfectly into the top level puzzle.

Counting on methodology to do its magic, you can safely split the work among different people, some will implement the low level parts, and others will be able to focus on the big picture. You are virtually guaranteed that everything is going to fall into place during integration. Thinking big upfront helps in bringing fundamental verification problems onto the surface very early in the verification process, which is when you want to deal with them. A good verification methodology also provides implicit protection. You don’t (and not required to) know how much stuff is going on behind the scene - arbitration, thread synchronization, debug utilities, warning messages - just to name a few. All of that good stuff is usually taken care of for you to help you focus on your most important tasks, and provide you with a robust verification platform. There’s yet another big added value to adopting an industry standard verification methodology - and this is one of my favorites - inherent flexibility. You see, the nature of verification projects is such that the more flexible an environment is (i.e. promoting future extensions and tweaks) – the better. Unfortunately, building a robust environment that’s also very flexible is not so easy. The good news is that the folks who develop verification methodologies (UVM being the perfect example) are well aware of that. In fact, a great deal of attention is given to this subject in all popular methodologies so once you nail the concepts of your chosen methodology and stick to them, flexibility is pretty much guaranteed. You don’t have to worry about it too much. Good examples are the increasingly popular TLM ports and software paradigms such as class factories and callback functions.

Overall – a methodology is a good thing and you should adopt one. The UVM might turn into the perfect choice for you as it is being driven and developed by the people who understand verification better than anyone else on the planet. UVM is all about bringing together the best verification concepts currently available today and unifying them into a single entity.

More articles :

» Method Manipulation In SV and e

If you're familiar with SystemVerilog and taking your first steps in e (or vice versa) you might find this useful. Here are some of the most common method manipulations that you''ll need to master and how you should go about implementing them in e...

» Let The New Game Begin

Things are changing. The EDA industry is changing, and the verification world is changing (check out Janick Bergeron's inspiring at SNUG San Jose for a glimpse of the future of verification). One of the major challenges we’re already facing today...

» Coverage Driven Thoughts

In today’s short post what I’ll try to do is share with you some of the recent trends and ideas that deal with coverage. I won’t go into much technical detail today in order not to wear you (and myself) out, but really - if I want to be more...

» Get On The Buss

Wow, it’s been a while since we last had a good old techie talk about Specman so why not now? Today I’d like to focus on applying reuse to Specman external ports. Very much like little caterpillars, DUTs often have tens or even hundreds of pins...

» My Story With Certitude

Long time no see. My website has been down for a while (technical issues - web experts contact me if you want to help) but now it's up again. And going through some of my old articles here (well, they're all old, I should probably do something about...

Comments

Another great post! I do however, have several concerns about UVM and me.

First call UVM what it really is, Ugly Verification Methodology. It's an amalgam of RMV/VMM and AVM/OVM, which themselves are mediocre methodology examples. (That's a topic for a different post.)

As to Guidance, I agree wholeheartedly. And does VMM's 842 rules provide the right quality and quantify of guidance? Guidance is best done with examples and text. Both are lacking in the current public domain (yes I have read the cookbooks and Writing testbenches* and *VMM). I have written a comprehensive OOP/Methodology book that covers this topic fairly well. I provide guidance on "mundane issues such as naming convention, common terminology, file names, etc" as examples, because these are constantly evolving (with you, your team, the company, and the industry).

(Continued...)Efficiency is a tricky thing. It really depends on the individual, team and company. I do take issue with your "Need a generator? No problem. We've got one for you, just instantiate it and you?re ready to go." Not true at all ! While you can talk about the "concept" of a generator, transitioning to a base class is an entirely different matter. There is not common *good* base class for a generator. Here are some common considerations: should the generator be a thread (i.e. have a start) or should it have a send_one (or send_n) interface? Does the generator need to be part of a nested set of generators? How should the generator be connected to its consumers?

(Continued)Looking st you comments on a register package, a register package is nice, but should never be a a large part of your verification. In all my work, the registers are tested with a generic test and then the real drivers/monitors. They just aren't a big deal.

Any "industry standard methodology" should be open source, supported by more than the bug three, small, minimal, and flexible. And it should probably exist in multiple languages.

When you say "Good examples are the increasingly popular TLM ports and software paradigms such as class factories and callback functions.", I would caution that TLM as a concept is very appropriate, but TLM as a class library is just wrong. There are too many design variables to consider to make even a decent class library. With class factories, again the concept is correct, but implementing a global one (as in UVM) is just insane.

(continued)Class factories are good in certain local scopes, they are complete wrong in a global scope. As for callbacks, they are the weakest of a spectrum of connection techniques, each one with trade-offs. They are not a good general technique,but should be one of your considerations when connecting two verification components. My book has an entire chapter devoted to connecting objects.

So, while I agree that a common methodology can be a very good thing for our industry, UVM is not it.

I have to agree with Mike. The overhead of the "standard" Methodology seems very huge when I look at my light weight system. All the objectness of the SV methods seems to have some overhead that is never mentioned. Like a generator will fit all my needs? Not likely.

I've read your comments and you're both making some very valid points. I would like, however, to address some of them. But before I do that, let me just clarify that my main argument was that whatever methodology you're using, the CONCEPTS of UVM (or eRM/VMM/OVM for that matter) are what’s important. Implemented one way or another, SV or e, AOP or OOP- it doesn’t matter. All that matters is that methodology makes verifiers more productive. It is impossible, I’m afraid, to be successful in verifying a 10 million gate ASIC without having a strong methodology in place. And thinking only about simple block verification and trying to deduce from that to verification as a whole would be a mistake, IMHO. So overall, a good methodology offers an approach, and a library of base classes that you can use (or tweak). I’ve provided some specific examples in my article just to give a sense of what I was talking about, but obviously verification methodologies are not just register packages and standard generators. I’d like to address 3 topics in detail:1. Register modeling is far more than just a means to launch CPU transactions to test register access. Register modeling can do that too of course, but its main purpose is to model the registers of the DUT. Standardization here means that you can generate a register model off of your spec in 60 seconds, even with a coverage model in place! A register package helps in building automatic test benches by providing a coherent model of internal DUT state. It offers a convenient API to test writers and developers (read, check, predict, set, reset, and much more) and promotes reuse and automation. It simply saves time.2. Off-the-shelf generators and other off-the-shelf components are indeed a bit limited in that they cannot offer the full spectrum of features. You always have to tweak something to get it just right for what you need. However, most of these off-the-shelf components are usually good enough unless you have a really unusual system to verify. I would argue that for most SoCs and communication systems involving frames and packets, VMM and OVM are exactly what you need.3. Factories and callbacks are design patterns that are needed to make up for the lack of AOP and standard ports. The need for AOP-like functionality is fundamental in verification, so if your language doesn’t support it natively, methodology comes to the rescue. Matan Vax from Cadence explains this better than me here - http://www.youtube.com/watch?v=3VJN6n6CaOI. Moreover, seems like SV folks are asking for this too - http://bit.ly/cyOrQe