Generically Reusable IP No One Uses

I can’t tell you how many times this line has jumped into my mind over the last couple decades, probably because I lost count sometime in 1998…

Manager: “…why do they put a guarantee on the box then?”

Tommy: “‘Cause they know all they sold you was a guaranteed piece of s***.”

That’s an exchange from the movie Tommy Boy, a classic from my university days. Tommy Callahan, new college graduate (barely) and bong hitting heir to the Callahan Auto throne, is thrust into the family company’s lead role after his dad, Big Tom, dies suddenly of a heart attack. The company is struggling with mounting debt as Tommy steps in so his immediate concern as newly minted leader is selling enough brake pads to pay the debt and save the company.

Tommy decides the best course of action is to hit the road as traveling salesman. Accompanied by his sidekick Richard, Tommy stumbles repeatedly through meetings, having zero success, at one point even starting a model car on fire, until he finally nails his pitch and makes his first sale. The fella he’s talking to puts up a strong front, insisting that he can’t sell brake pads that don’t come with a guarantee; that just having the word guarantee on the box helps customers sleep at night. Tommy counters with the argument that a guarantee means nothing without quality. It’s enough to close his first deal.

If you’re looking for two words that match the significance of the word ‘guarantee’ in functional verification, look no further than ‘reusable’ and ‘generic’. Those are the two words we put on the box to help our colleagues – managers included – sleep at night.

To me, calling your own code generic or reusable is kind of like giving yourself a nickname. That’s a major faux-pas where I come from. Friends decide your nickname, not you. Likewise, colleagues decide if your code is generic and/or reusable, not you. If you insist on calling your code reusable or generic, we need some ground rules to help people understand when it’s acceptable. To me, code has to hit several criteria in order to be declared reusable…

• Your code has been used once
• Your code has been used two or more times
• Your code has been used by someone other than you
• That other person didn’t need you to use your code for them

OK… so the first bullet is more a prerequisite than a requirement, and I can’t believe it’s something we’d even need to point out, but unfortunately it’s where we start. Calling code reusable before anyone has used it, not even you, is putting the cart before the horse. Way before! Yet I’d guess this is the 2nd most typical situation when it comes to people calling code reusable; they set out to solve a problem common to many colleagues, write the code accordingly, wait for the masses to flock to it, the masses don’t flock to it, the code rusts in the repository and is eventually deleted to recoup storage space. Without ‘use’, there can be no ‘reuse’.

From 2nd most typical, we go to the most typical. To say that ‘reuse’ requires code to have been ‘reused’ at least once seems obvious, doesn’t it? Yet how many times have you seen this: buddy writes code he/she thinks is pretty cool, uses it to solve his/her problem, expects others will also find it cool enough to solve their problem(s), buddy calls his/her code reusable, casually hints others should use it, more forcefully hints others should use it, specifically suggests others should use it, no one else uses it, buddy doesn’t use it again either.

Let’s call that the reuse-on-the-box scenario; thinking one success and labeling it is enough to qualify as reusable. But the word reusable, at an absolute minimum, means that code has been used, then used again. Using it once is just ‘use’.

So maybe you’re thinking used twice is good enough to call code reusable. Technically I guess that could be true but for me that’s setting the bar too low. If you have the gall to tell others your code is reusable, that should mean someone other than you has actually used it. If that hasn’t happened, your code isn’t reusable.

Last but not least is a variation of the reuse-on-the-box-scenario; let’s call it the vicarious-reuse scenario. In the vicarious-reuse scenario, instead of accepting that no one wants to reuse your code, or maybe they can’t figure out how to reuse your code, you reuse it for them. You do all the integration and setup work. You also do a lot of the debug and/or interpretation of results. They maybe put in a little effort, and maybe reap some of the benefits, if there are any, but don’t mistake this for reuse. Block level testbenches tend to fit this bill. Sadly, some 3rd party IP also qualifies.

As often as we abuse the word ‘reuse’ and all it’s derivatives, I think we’re even worse with the word generic. In my mind, generic code must meet all the reuse criteria. As well:

• Your code accomplishes a goal for which it wasn’t specifically designed to accomplish
• Your code actually does something but not everything

An example to the first point, proper use of the word generic could mean a scoreboard that checks whatchamacallits is also suited to checking thingamajigs and dingledongs without modification. If it’s just really great for checking whatchamacallits, it is not generic.

The second criteria has to do with the two ends of the generic-ness spectrum. On one end is code that is so generic it doesn’t do anything useful. Good example here is a component base class that provides no notable behavior or value beyond being a base class. (Full disclosure: when I was first introduced to HVLs and OO programming, I used to generalize verification code to the point the individual pieces provided zero value. Luckily I’ve grown out of that habit). On the other end of the spectrum is code that aims to solve every foreseeable problem through configuration and branching. This code is also not generic, it’s swiss army kitchen sink code.

If you’ve written code that covers all of the above, congratulations! It’s probably safe to say that what you have is generic and/or reusable. If you’re looking for the ultimate test, however, reuse is the surprise of finding a colleague who uses your code successfully without you knowing. This is the one true measure for generic and/or reusable code. It’s code that stands on it’s own to fulfill a purpose for colleagues who actually want to use it without your extra effort or intervention. Incidentally, this situation has arisen most often for me when my focus is quality, not reuse. Quality is surprisingly reusable!

In the functional verification club, we need to start using ‘generic’ and ‘reuse’ more carefully before they become meaningless. That or we risk them becoming even more meaningful than they are now. If we just keep putting generically reusable on the box, all we’re doing is selling our colleagues a generically reusable piece of shit.

PS: If you’re interested – I’m sure everyone is – here’s Tommy Callahan making his first sale..