Earlier this year, the Accellera VIP-TSC approved version 1.0 of the UVM. Supported by all of the major EDA vendors, the UVM has been billed as the next generation in verification methodology goodness. Better than the VMM. Better than the OVM. A chance for the verification community to shed some of the baggage carried over from years of backward-compatibility requirements and methodology fits and starts. Another purported benefit is that testbenches written with SystemVerilog/UVM can be more easily ported to simulators from different vendors. There is also a developing market in UVM verification IP to allow testbenches, in theory, to be quickly constructed from commercially available components.
All of this sounds great, right? Vendors standardizing on languages and methodologies and competing on tools. It's how the world should be. Except there are a few small problems that vendors are unlikely to tell you about before you start your next project.
First and foremost is a problem that is glaringly obvious to anyone who's tried learning SystemVerilog and the UVM (or one of the other VMs over the years): it's difficult and time consuming to learn SystemVerilog and any of the VMs... especially if you have never used a verification language before. Folks with limited software backgrounds (read: most design and verification engineers) find seemingly simple concepts like inheritance and factories to be mind boggling, even if they won't admit it. And folks with deep software backgrounds will find SystemVerilog an absolute pit of despair when compared with modern languages such as Python and Ruby, and the UVM complex in a way that clearly is meant to patch over serious deficiencies in the underlying language. Plus, any testbench that has to deal with multi-language issues is clearly out of luck in the simplicity and ease of use department.
Now that the UVM has arrived and the methodology bickering between the major vendors has mostly (well, somewhat) ceased, the complexity of the UVM and the earlier VMs on which it is based can be viewed more clearly and with less controversy. And the results are not good. After years of experience working with many multiple clients, it seems the only way out of our current dilemma is to start looking at other languages and development frameworks. For that to happen, major semiconductor companies may need to start funding this type of development again, since it is abundantly clear the EDA vendors are incapable of this level of innovative thinking. Or more kindly, perhaps they feel there is no money in innovation. Either way, major advances in design and verification productivity need to get here sooner rather than later.