Honey… I’m Being Eaten By A Bear: 10 Need to Know Tips

Last week I stumbled across a verification post that used my favorite verification graphic from the Wilson Research Group Functional Verification Survey that Mentor sponsors every few years. Here it is again for anyone that hasn’t seen it posted here before (I’m sure this makes about a half-dozen times for me. It is, after all, my favorite verification graphic)…

Screen Shot 2013-08-12 at 9.15.13 AM

 

I continue to think this data paints a very dim view of our development process and even after all this time I still cringe when I see it. It’s the time wasted on debug, at 36%, that really hurts… all of us. What also makes me cringe is that our industry’s response to this data is to create more effective debug tools and methods. I’ve always seen that as a knee jerk reaction that ignores root cause; the real reason we’re wasting 36% of a person’s time on debug is because we write buggy code, not because we have poor tools.

But I’ve obviously failed in getting that point across because I’ve been unable to spark the industry-wide outrage I think this data deserves :( . So instead of more serious discussion, I’m going to try a different approach.

First off, a variation of the original graphic…

verif

I’ve taken the liberty of clumping all of ‘Test Planning’, ‘Testbench Development’, ‘Creating and Running Tests’ and ‘Other’ into 2 categories: Being productive and Creating defects. When it all comes down to it, regardless of the specific task, we’re either taking a step forward or a step back. Writing code that works is a step forward, writing code that doesn’t work (i.e. buggy code) is a step back. With 36% of our time lost to debug, I think I’ve given us the benefit of the doubt by suggesting that only about 20% or our time is used creating defects. The rest of the time, roughly 40-45% of our time is actually productive in that what we do doesn’t need to be fixed or redone at a later date.

So that’s 36% of our time debugging, ~20% creating defects and ~45% of our time doing productive work.

Now forget about the debug time and let’s focus on the creating defects, because that’s really what this is all about. Maybe examples from outside ASIC and FPGA development can help us understand the proper way forward…

marathon

house

eatingdiggingbears

Obviously these data represent serious circumstances that require even serious’er solutions. Luckily, I found these papers online as examples of how others are handling the problems they create for themselves:

Funny… I would have thought avoiding the honey in the first place would have been the best way to defend yourself against a bear.

-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. Bookmark the permalink.

One Response to Honey… I’m Being Eaten By A Bear: 10 Need to Know Tips

  1. Tudor Timi says:

    Another pet peeve of mine that leads to a lot of debug effort is improper use of source code management tools. Hardware engineers don’t really understand a lot of the basics of SCM and tend to step on each other’s toes when doing commits.

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>