Get email delivery of the Cadence blog featured here
The Universal Verification Methodology (UVM) is a big step forward for verification IP interoperability, but it needs to be embraced as part of a bigger, broader, people-centric definition of methodology, according to Neil Johnson, principal consultant at Cadence partner and design services provider XtremeEDA, In this guest blog he describes the "big picture" that is needed for UVM to succeed.
The 2011 release of the UVM 1.0 is touted as a major milestone in the world of EDA and functional verification. The following description is from http://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 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?
The word methodology has been used a lot in the past decade to describe advanced verification frameworks built on e, OpenVera and most recently SystemVerilog. But there's another definition of the word that unfortunately isn't used much in hardware design -- one that includes technology like UVM but also guidelines for communication and teamwork. This "big" definition of methodology is borrowed from Agile Development: The Cooperative Game by Alistair Cockburn:
"...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."
The UVM is great new technology that goes a long way to accomplishing its end goal of universal verification IP interoperability as stated on http://www.uvmworld.org/. To be successful, however, the UVM must be embraced as part of the bigger, broader, people centric definition of methodology. Doing so means complimenting it with other critical features that above all take into account the context in which it is used and the people that are using it. These features are listed below.
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 one-time course focused solely on the UVM does not qualify as such.
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 team's 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.
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, and component demos 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.
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.
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 the Open SystemC Initiative (OSCI) transaction-level modeling (TLM2) standard, the UVM provides 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.
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).
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.
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.
Arguably the people know-how is where we need to play catch-up. Thus, the next great challenge is to embrace technical know-how within a larger People Centric Universal Verification Methodology. Semiconductor development starts and ends with people. Just because we can't be standardized doesn't mean there can't be room for improvement!
This guest blog entry was adapted from The UVM Is Not A Methodology posted on www.agilesoc.com. For anyone interested in other articles and video presentations on agile hardware development, visit www.agilesoc.com