Altered States: To Change or Not to Change?

Bill Martin, Mentor Graphics

Most people purchase a product and never think about modifying their recent purchase to perform additional functions. If we have issues with these products, we go to the manufacturer or a skilled service provider to fix or replace them, because we know the price of product ‘tinkering’ equals voided warranties and support.

Motive: when it comes to purchased IP, engineers feel they can always improve “off-the-shelf” purchases. The logic says the original designer did not fully understand my specific need, so by adding ‘minor’ tweaks it will enhance the product’s usability. Or will it and at what cost?

Then why do we have different expectations with purchased IP?
Opportunity and Means: Engineers have the opportunity, and means are available to them. Soft IP (RTL) is provided via source code which offers up the opportunity to reconfigure IP. Many engineers can write and understand Verilog or VHDL, providing the means.

So what’s the problem?
Once a modification, however trivial, is implemented on the IP, the original value and purpose created by the IP vendor has been negated. For years, Numetrics has collected various data concerning IC design and the impact of reuse. Figure 1 shows a block that was altered by 25% and the impact on its value. In this case, 25% change reduced the effort saved by 50%. Are the alterations worth the cost?

Figure 1

The verification, validation and compliance work must be re-done to maintain the original value; very similar to restoring an old car back to its original condition. Few people consider restoration due to the amount of money and work required. The same thoughts should be applied when contemplating IP changes. For IP, the industry does not understand how the IP design team constructed their product or the standard (i.e. USB) specification. At least when re-storing or re-tuning cars, you can buy a complete manual with hundreds/thousands of pages on how the car was constructed with complete BOM and specified parts. Over time, this documentation should become a standard offering available for each IP.

How to avoid domino effects?
In my career, I have had teams that quickly implemented a bug workaround believing that they had complete knowledge of the IP’s interactions. While this might have fixed a specific customer’s issue, it created other issues for other customers’ applications. And this is from the original design team. If they could not understand all the interactions, how could a designer with little history with this IP be able to perform surgery?

I have also had teams that quickly thought of a solution but wanted to run full regression tests to ensure that a small change in one area of the design did not cause issues in other areas. These teams understood that given the IP’s complexity and Murphy’s Law, they were human and could easily introduce bugs.

With the growing complexity of IP, I prefer the latter team’s approach. Determine a solution and re-test it with your regression and silicon validation suites to ensure no unexpected bugs are introduced. The latter approach helps improve IP quality.

Each of us wants to add our own value to a project, but maybe the value we add is by NOT touching an IP block that was purchased. If changes are required, go to the original design team and get a quote from them. In the long run, this will be cheaper and faster.

What are your thoughts on altering IP?