Seeing Debug for What It Is

Debug is problem solving. For many hardware developers, debug is a purpose. Finding a bug is a victory!

Heck, debug can be flat out heroic. I’m sure we can all think back to colleagues that put in a few 80 hour, coffee fueled weeks, with managers peering over both shoulders, to fix an insidious string of bugs that threatened to further demolish a broken schedule and sabotage tape-out.

We hardware engineers love our debug. Fixing a bug deep, deep down in a design can be quite a high. But there’s lots of other stuff that can get people high. Like crystal meth.

I won’t even pretend to be an expert on drug addiction – definitely don’t intend to trivialize it or make light of how serious the consequences can be – but if seven seasons of Breaking Bad has taught me anything it’s that meth addicts have a tendency to spend a lot of money on meth. Sometimes all their money. And spending all a person’s money on meth leads to big problems, like how to afford more meth. In fact I’d be willing to bet that a survey of meth addicts would show not being able to afford more meth is their number one problem. That’s a serious situation: in order to succeed (i.e. get more meth), they need to solve a problem (i.e. get more money).

Getting money can be a full-time problem for meth addicts. It blocks out other distractions completely; there’s no time to ponder anything else, like why they need the meth in the first place. That’s quite a coincidence considering [debug] can be a full-time problem for [hardware engineers]. It blocks out other distractions completely; there’s no time to ponder anything else, like [how the bugs got there] in the first place.

I wonder if meth addicts spend more time finding money to buy more meth than hardware engineers spend fixing bugs to tape-out devices?

I’m guessing it’s about even… maybe 37% of our time… give or take.

We love our debug… we need our debug… we binge on debug because our development habits have turned us into addicts. And like addicts, we’re fixated on solving the wrong problem (i.e. better/faster debug) while the real problem relentlessly – but unassumingly – tightens it’s grip on us.

It’s time for an intervention; it starts by admitting to what’s really going on. For meth addicts this is an easy one: meth isn’t about getting high (a perceived benefit), it’s about wasting your life burning holes in your brain (a very negative reality). For hardware engineers: debug isn’t about solving problems (a positive), it’s about wasting effort on poor quality code (a costly negative).

Then comes the part where we start calling debug what it really is:

Redo.

Redo isn’t victory and it certainly isn’t heroic.

Redo is the side effect of the technical practices we use to produce poor quality RTL and testbench code. That’s going to be tough for many of us to admit, but it’s true. You don’t develop an addiction to redo with code that’s already solid.

So seeing as how poor quality is our motivation for improvement, let’s call this a quality intervention. I’ll finish up by getting it started. I hope to have you follow along.

“Hi. My name is Neil. I’m a verification engineer. I waste time on redo because my code… well… uh… my code… it’s pretty bad.”