There are times when I use agilesoc.com to step out on a limb and challenge the general consensus in hardware development. This post would definitely qualify as one of those times.

I don’t think the reusable verification IP we’ve been building is as reusable as we think it is. I don’t think reusable IP is reused as many times as we’d like (if at all). Nor do I think reusable IP is as valuable as we think it is.

There… I said it.

That hasn’t always been my opinion… in fact I used to be a person that preached the exact opposite… but that’s my opinion now and it feels good to get it out. Our entire idea of reuse is something I have a problem with because I think most of us are getting it completely wrong, myself included, for a very simple reason. In our haste to create IP that is reusable we’ve forgotten about the absolutely most fundamental requirement: the IP has to first be usable. Anyone can riddle a piece of IP with all the elaborate features and switches and hooks and callbacks and scripts necessary for infinite reusability (or extensibility). But in a lot of cases reusability ends up being inversely proportional to usability; the more requirements a piece of IP can fill the fewer it fills well.

Jack of all trades… and you know how the rest turns out.

If you’re working in hardware or embedded systems development, I’d appreciated you completing this survey.

If your code isn’t usable there’s no point in thinking it’ll be reusable so I’m going to suggest we step away from ‘reuse’ for the moment and focus all our attention on ‘use’. A simple way to do that is to look at building reusable IP as a two step process.

Step 1: Ensure you code is usable.

I think all IP should fill some pretty basic requirements related to usability:

• it works
• there are options for doing simple things in a simple way
• it takes 5 minutes or less to get the point across
• people only need to ask how to use it once
• to understand the usage model/api it takes nothing more than…
• a README and a short conversation for an expert; OR
• a README and a longer conversation and/or a whiteboard session for someone more junior to understand
• a full day training course (or longer) isn’t required to understand the usage model/api
• it takes a half a day or less to integrate (to the point where it becomes useful)
• it doesn’t unreasonably slow down compilation/simulation
• designers are willing to use it (or at least some part of it)
• designers don’t laugh, cringe or run the other way when you suggest they use it
• it doesn’t frustrate people to point they’re forced to build their own
• it’s easy to access
• it comes with examples
• it comes with a regression suite
• it takes 5min or less to figure out how to run the regression suite
• results of the regression suite are accessible and easy to interpret

Step 2: Ensure you code is reusable.

The tenets of reuse are already trumpeted regularly so I’ll only add a few general rules:

• Don’t make your code reusable if no one intends to reuse it
• Don’t impose a reuse model or framework on code that will never be reused
• Reusability is determined by the person doing the reusing

The upside is that reusable verification IP does actually exist so there is hope. There are teams that put out great IP. For the rest of us though, creating reusable IP isn’t any more likely than prancing through a meadow on a unicorn or funding your retirement with a leprechaun’s gold. And, unfortunately, we’re making it worse. Building reusable IP is hard enough; there’s no need to make it harder by forgetting the most important part.

‘Reuse’ without ‘use’ is just ‘re(diculous)’.

-neil

Q. Have a different opinion on reusable verification IP? Or any use/reuse requirements to add?