If you saw last week’s post you’ll know that I’m pondering a DVCon proposal. As it stands, my proposal centers around unit testing in hardware development. Trouble is, unit testing on it’s own – nevermind TDD which is where I really want to go – has been a tough sell for hardware developers. Lucky for me, I’ve recently found that if I show off unit testing within a context people actually care about (i.e. UVM), suddenly they take an interest. Odd how that happens :). So that’s where I am, an abstract that describes the value of unit testing as we’ve applied it to UVM. It’s called How UVM-1.1d Makes the Case for Unit Testing. The proposal is not a sure thing yet. If you’re on board with it, you can help make it happen over here.
Assuming people like the abstract, I’m looking for an ice breaker or two that in addition to what we’ve done with UVM help convey the value of unit testing. That’s taken me back again to Mentor’s 2012 Wilson Research Group Functional Verification Study and a twist on the time wasted debugging graphic that I love so much. Here’s a snapshot with the graphic and Harry Foster’s analysis from Mentor’s website. I’ve shown the graphic so many times already. Let’s focus on the analysis this time, shall we?
For such a strong indicator, I think Harry is taking it easy on us; probably doesn’t want to hurt anyone’s feelings! I’m going to offer a translation that’s a little more direct…
Let’s look at the mean time verification engineers spend wasting their time. Unless you’re blind, you’ll see verification engineers burn an incredible amount of time fixing defects that they and their colleagues create through a careless disregard for code quality. Ideally, if we realized that people aren’t perfectly molded futuristic efficiency drones, that they make mistakes and that unit testing code is a great way to catch these mistakes before they become a huge time-suck, we’d be free to find more entertaining ways to spend almost 3 hours/day, like windsurfing or smelling flowers or doing chin-ups. Yet, unfortunately, because we don’t generally unit test our code to eliminate defects in a focused and disciplined way (or even make the effort to keep track of where we inject these defects), the time required to find them can vary significantly from project-to-project – big surprise there – which means project managers, team leaders and executives are often left wondering what the hell could be taking us so long to finish up considering we told them we were done writing the RTL and building our testbench several months ago.
There… the colour and analysis I think that graphic deserves. And depending on the interest I get, a nice opening for a DVCon paper describing the benefits of unit testing in hardware. If it sounds good to you, could go read and vote for the abstract… or you could just vote for it here.Sorry, there are no polls available at the moment.
PS: As I’ve said before, reading through Mentor’s 2012 Wilson Research Group Functional Verification Study is time well spent. Lots of important little nuggets in there. This comes from part 6. This morning I see Harry has just posted part 9.