UVM Is Not A Methodology

Neil Johnson, Principal Consultant – XtremeEDA Corp.

The Universal Verification “Methodology”

The 2011 release of the UVM1.0 is touted as a major milestone in the world of EDA and functional verification. From www.uvmworld.org:

“The Universal Verification Methodology, UVM, is a standard being developed by Accellera for the expressed purpose of fostering universal verification IP interoperability. Led by electronics companies and supported by a suite of companies representing the breadth of the verification ecosystem, the UVM will increase productivity by eliminating expensive interfacing that slows verification IP reuse.”

Beyond what it delivers on a technical level and because it has readily been adopted by all three of the big EDA companies, UVM also gives hope for future collaboration–or at least consultation–within EDA; the trickle down effects of which should be felt positively in semiconductor design. But with all the hype around the UVM becoming the de facto industry starting point for functional verification, does it really deserve the attention it gets, or should it be viewed as merely part of the bigger picture?

In A Method Is Not A Methodology, an AgileSoC.com article from December 2009, it is argued that the focus and importance placed on advanced verification libraries is slightly misplaced. The article builds to that position by capturing the characteristics that functional verification engineers have come to associate with pre-UVM verification methodologies:

“…as a group their purpose is similar: to increase productivity by addressing various technical challenges found in functional verification… Each embody a tremendous amount of detail and expertise. They are very powerful and more than adequate as a basis for implementing advanced verification techniques. Methodology seemed like a perfect descriptor when you consider their breadth and highly integrated nature.”

The UVM certainly fits the same mold, building on the best from a number of verification worlds and minds. Further, it is supported by multiple vendors which lends significant credibility to its universality. Just as its predecessors, the UVM certainly seems to deserve the status of methodology.

Later in the same article, reference is made to a grander view of what it means to be a methodology. In Agile Development: The Cooperative Game by Alistair Cockburn, a methodology is described as:

“everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.”

It would be unfair to play down the collaboration and hard work that went into the creation of the UVM and that certainly is not the intention here. But similar to its predecessors it also falls short of fulfilling the requirements that would make it worthy of the term methodology.

The People Centric Universal Verification Methodology

The added collaboration within EDA demonstrates a step in the right direction, but the UVM is not a methodology. It does not take into account the unique needs of an organization. It cannot make decisions, interview and hire new engineers, mentor junior engineers, facilitate meetings, support customers, work late nor encourage the team to do better. The UVM can however become an integral part of a broader, people centric definition of methodology. To do that, it must be complimented by other critical features that take into account who is using it and the context in which it is used.

A Sustained Training Strategy

For teams that are new to the UVM, a decent 1-3 day training course from an experienced instructor should be seen as mandatory for getting started. But that should not be the end of the training. Refresher courses and advanced training should be made available as people require them. New teammates should be offered the same training opportunities to bring them up-to-speed as quickly as possible. Do not overlook the importance of Systemverilog training as the language is an absolute requirement to understanding the library. Similarly, do not underestimate the value of software courses that teach object oriented programming in languages like C++ and Java. Training should be seen as a diverse and sustained investment and a onetime course focused solely on the UVM does not qualify as such.

Mentoring Of New Teammates

Even with the framework that the UVM provides, there are still many ways to architect a reusable verification environment and write effective tests productively. Documentation can be used to capture the teams intent, but a document is never as good as whiteboard discussions and direct guidance from someone that knows what is going on. Make it standard practice to have experienced developers assigned as mentors to work regularly and directly with new teammates until they are comfortable with the team’s verification processes and techniques.

Regular Review Cycles

Like any technology, there are aspects of the UVM that need to be experienced before people really understand what is going on. Peer reviews can be especially useful for ensuring that experience is disseminated across the entire development team. In addition to regular training and the usual documentation reviews, create opportunities like code reviews, environment walkthroughs, component demos, etc to share experience throughout development. As people use new features of the UVM, have them share or demonstrate their usage experience with the rest of the team.

Early Design Integration

Relative isolation with document-based communication seems to be the norm for interaction between front-end design and verification. For some, this stems from the idea that knowledge shared from one to the other risks polluting what are intended to be independent thought processes. While this is a valid concern, surely checks and balances can be built into a more efficient process rooted in a shared approach to problem solving. Early design integration can help kick-start a streamlined development process where close and continuous collaboration replaces isolation as the norm. Developers from both teams should be dedicated to strengthening that collaboration through to delivery.

Early Model Integration

System modeling and verification is another divide where relative isolation can hinder productivity. It is no coincidence that this is an area where the UVM can help. By incorporating TLM2, the UVM brings the standard communications mechanisms that are designed to close the technical gap between systems engineers and verification engineers. The UVM cannot, however, do much to facilitate the teamwork required to apply these standard communications. The mechanics are there, but they require cooperation between modeling and verification teams to be used effectively. Focusing on early model integration creates opportunities to kick-start meaningful collaboration with system modeling similar to how early design integration spurs collaboration with designers.

Incremental Development, Testing and Coverage Collection

Feedback is important when adopting new technology. Unfortunately, the scope and relative complexity of the UVM suggests that a corresponding increase in environment development time should be expected. The danger of accepting that increase translates to a long period where feedback cannot be collected until well into development (via test and coverage results). Delay means uncertainty regarding how effectively the team is using the UVM; worse is the uncertainty it creates regarding where the team stands relative to delivery goals.

Incremental development of the verification environment with early testing and collection of coverage results can change that. By working toward functional milestones that gradually increase in terms of features supported, incremental development gives a team opportunities to regularly assess its effective use of the UVM as well as an objective view of where it stands with respect to delivery goals (more on incremental development can be found in Agile Transformation in IC Development).

Organization Specific Refinement

The UVM is a universal framework specifically developed to be used by any organization and for many applications. That does not mean that every organization needs to use it in the same way. Whether it is restricting use of particular features, customization of existing UVM library components or addition of new features like transaction libraries and environment or integration structures, teams must develop a usage model that suits their needs, strengths and product requirements. It would be valuable to regularly review the usage model as the UVM continues to mature. Obviously, all of the above should be done without compromising the motivation behind using the UVM in the first place, which is to foster universal verification IP interoperability (i.e. teams need to maintain the integrity of the interfaces and protocols). As a team grows more experienced it can and should make customizations and additions that make it more productive.

Methodologies Of The Future

The UVM is a big deal. There is no denying that. It is necessary technical advancement in a highly technical field not to mention a triumph of collaboration within EDA with valid claim to the word universal. It is worthy of the attention it receives and the people that put it together deserve huge credit. But here is one minor suggestion: let’s be more realistic and instead refer to it as the Universal Verification Framework. It does not and cannot take into account “the combined job descriptions, procedures, and conventions of everyone on your team”–as Alistair Cockburn suggests inAgile Software: The Cooperative Game–so organizations need to go further to make it a methodology.

What next? The UVM was created through collaboration between EDA rivals among others. This demonstrates that great things are possible through a collaboration of teams and colleagues from across organizations and across the semiconductor industry as a whole. The industry is flush with technical know-how; the UVM is the latest example. The next step is for the industry to embrace that technical know-how within a larger People Centric Universal Verification Methodology. A PCUVM–aka: the next big leap in functional verification and semiconductor development in general–recognizes unequivocally that people, not technology, form the core of product development. Technology is here to support those people, not the other way around.

Copyright 2011 – Neil Johnson

One thought on “UVM Is Not A Methodology

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.