Long touted as a silver bullet, IP reuse often fails to live up to expectations when it comes to increasing semiconductor R&D productivity and throughput . That’s because most IC development teams fail to recognize a critical non-linear relationship exists between the amount of circuitry they modify or “improve” in pre-existing IP blocks and the effort the engineering team expends in making those modified blocks operate properly in the target IC. Bottom line: small changes can have a disproportionate impact on project effort. Not being fully cognizant of the specifics of this non-linear behavior is a common trap into which myriad engineering teams unwittingly fall.
Conventional thinking, for example, might presume that modifying a mere 20 percent to 30 percent of a block translates into a relatively modest amount of engineering effort, compared to the effort the team would expend if creating that block from scratch. After all, most of the block remains untouched, has already been verified and perhaps even implemented in silicon. But therein lies the rub. Because of the non-linear relationship, the 20 to 30 percent change (or even less) often translates to engineering effort far in excess of what the project team anticipates.
Frequently, the additional effort is significant. For instance, when teams modify upwards of 40 percent or 50 percent of a block, the total effort expended to make the block work in the target IC can be equivalent to designing it from scratch.
Yet the biggest problem is not the additional effort, but rather it’s that it’s unexpected, which is a common root cause of schedule slip and poor predictability , as well as low R&D productivity. It’s an insidious problem that often disrupts the entire project development pipeline, as resources fail to roll in a timely manner from one project to the next.
Each family of circuit blocks has a unique set of non-linear reuse curves—analog, RF, logic, processor, memory, etc.—and the curves vary with respect to whether the particular IP is hard or soft and the amount of its verification suite reused. When teams apply the curves during the project’s planning phase, the impact can be tremendous: dramatically reduced schedule slip, greatly improved predictability and noticeable productivity gains, all of which go right to the financial bottom line.
Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4218842/The-realities-of-IP-reuse
8/17/2011 6:26 PM EDT
The numbers I have seen in the software industry indicate that if you need to modify as little as 25% of the code, you are ahead to start from scratch; the modifications will take longer and cost more.
8/18/2011 9:35 AM EDT
All true but the real point here is that if you don’t have a well defined need with standard or well defined I/O that does NOT require modification you are shopping in the wrong aisle. Design reuse is different than integrating an IP block. An experianced project manager should know the difference and schedule accordingly.
8/18/2011 11:58 AM EDT
I don’t think the software industry gets enough credit in this regard. Consider that language and OS libraries are really just code reuse. If each developer had to hand code all of the functionality that lives in libraries, then we could say that IP reuse doesn’t really exist.
As it is, we’re typically only looking at the in-house coding and ignoring all of the externally developed code.
8/18/2011 3:28 PM EDT
I stole this from somewhere – don’t remember where … sometimes, the best IP reuse is to recover the disk space …