UVM is not a Methodology Article: What do you think?

[bryan.morris.peng]

Interesting article giving reasons why UVM is not necessarily a "methodology" in the truest sense of the word.

http://www.agilesoc.com/uvm-is-not-a-methodology

Nice catchphrase in the article about "People Centric Universal Verification Methodology".

I'm curious about people's thoughts of the points raised there.

-- Bryan

[stephenh]

The article makes some valid points but falls into the same trap that I think a lot of people do; i.e. getting confused between the UVM code library and UVM the methodology.

The UVM library provides the bag of bits from which to assemble a UV Methodology-based testbench.

Cadence has always tried to deploy UVM (and eRM, URM and OVM before that) to customers in a consultative way that shows customers the real methodology.

Some people will have gotten different results from those engagements, depending on the time available, the experience of the AE and the customer team etc.

The key thing has always been, and will always be, to listen to the customer engineer's challenge, then show them a way of working from verification planning through to coding to completion.

The underlying library and language is somewhat circumstantial, because the methodology taught is far more focussed on how to design for true reuse, how to ensure effective testing, how to go from block to ship level etc.

UVM as a library enables these things but UVM as a methodology is what makes them happen.

My personal view after 6 years as a Cadence AE is that the customer teams who insist on self-learning the eRM/URM/OVM/UVM library or the (e, SC, or SV) language and won't ask for training or guidance are the ones who end up getting the least from the methodology. They also often end up writing some fantastic code that is impossible to comprehend, ineffective, very low-level and isn't portable. I've seen some pretty big name customers who crafted staggeringly complex directed testbenches on top of OVM/UVM, because they've really missed the point of the methodology. These same users achieve far less reuse and randomisation than they should be getting, and the effectiveness of their testing is much lower than it should be.

Where customers have invited me in to help architect their flow (and I emphasise _help_ not force), we've created some really nice modular environments that are reusable, maintainable and adaptable. These customer teams have become more productive and have then propagated that methodology experience to other teams in their company, much as the article describes. This is the real UVM, where code meets experience.

I'm saying this not to boast about Cadence or my own abilities, but to stress the point that getting all fired up about a code library isn't going to make you more productive or effective, there's a whole lot of hard work and care goes into really building a good UVM testbench.