UVM Is Not A Methodology (The TDD Remix)

Forgot about this in last week’s post! Another interesting question from the functional verification seminar I delivered in Mountain View a few weeks ago was: if you could only pick one or the other, would you rather use UVM or test-driven development? Of all the great questions that came up, that was by far the easiest to answer. My response…

I’d take TDD over UVM any day. No contest.

Now before we go too far here, I want to be clear that choosing between the two is a pure hypothetical. UVM or TDD is not an either/or choice. In fact, the first time I used TDD was on a project where I was also using UVM. There is no reason to choose one over the other. You can use both. In fact, if you’re using UVM you should use both… which takes me to the topic of the day.

Challenging the idea of UVM being a proper methodology is something I started in the spring of 2011 with an article called UVM Is Not A Methodology. Even though it’s been a couple years since I posted that article, I really don’t think I’d change anything with it today. I didn’t think UVM was a methodology at the time and nothing has happened since that has me thinking any differently. I would, however, like to offer an update to the People Centric Universal Verification Methodology I outline in UVM Is Not A Methodology. I forgot about TDD, which, after having used it, becomes an important practice for successfully building a UVM testbench.

I should have included TDD in UVM Is Not A Methodology. Had I done so, it would have looked a little like this…

Test-driven Development

I’ve heard UVM described as a go-fast-to-go-slow methodology. I like that description because I’ve seen UVM encourage rapid deployment of technology that ultimately slows teams down. One reason teams get bogged down is complexity, which is inherent to UVM. Another is high defect rates, a characteristic of the open-loop coding style used by most verification engineers. Combining the complexity of UVM with high defect rates results in nightmarish debug scenarios that eat schedule and demoralize teams. Relentlessly.

While we users can’t do much to address the complexity of UVM, we can address unacceptable defect rates. TDD is a very productive way of doing so. Teams can verify the functionality of agents, components and transactions before they’re used to ensure a high quality, highly functional UVM testbench.

So along with the practices I originally suggest in UVM Is Not A Methodology – a sustained training strategy, mentoring of new teammates, regular review cycles, early design integration, early model integration, incremental development/testing/coverage collection and organization specific refinement, I’d also propose TDD an an important part of turning UVM the framework into UVM the methodology.

…but all that said, if by some strange series of events it does ever come down to a decision between UVM and TDD, I’d take TDD any day. No contest.

-neil

Share/Bookmark

About nosnhojn

I've been working in ASIC and FPGA development for more than 13 years at various IP and product development companies and now as a consultant with XtremeEDA Corp. In 2008 I took an interest in agile software development. I've found a massive amount of material out there related to agile development, all of it is interesting and most of it is applicable to hardware development in one form or another. So I'm here to find what agile concepts will work for hardware development and to help other developers use them successfully. I've been fortunate to have the chance to speak about agile hardware development at various conferences like Agile2011, Agile2012, Intel Lean/Agile Conference 2013 and SNUG. I also do lunch-n-learn talks for small groups and enjoy talking to anyone with an agile hardware story to tell! You can find me at neil.johnson@agilesoc.com.
This entry was posted in Functional Verification, TDD and tagged . Bookmark the permalink.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>