Some amazing statistics: Third-party semiconductor IP is now a $1 billion per year business, with thousands of suppliers. One-third of all logic in a design is now reused legacy IP, and that figure will grow to 50 percent by 2015.
The reasoning behind this is simple: More integration of IP into new designs increases productivity accordingly, or does it?
We hear a lot about "leveraging" IP to address new applications, speed production, and tailor products to meet customers' needs. In a perfect world this makes sense, but when IP originally created for other purposes is integrated into a new design there are numerous factors to consider.
Most importantly, adding existing IP means modifying your RTL, a high-cost/high-risk proposition. Ron Collett, President and CEO of Numetrics which provides software and services to manage IC development risks, recently wrote that "making 30 percent of your design from reused IP blocks doesn't mean you're going to be 30 percent more productive at the end of the project. That's because IC design teams tend to underestimate the work needed to implement the reused IP," a dilemma illustrated in the following chart:
Click on image to enlarge.
In fact, Collett wrote, even a small percentage of reuse can add outsized effort to a development project. "For example, if you add one new block of 600,000 gates to a 6 million-gate design, you're adding 10 percent to the IC but increasing the effort required on the project by 24 percent. Adding 10 percent new circuitry to all blocks in that 6 million-gate design with 90 percent of each block being reused doubles the effort required on the project, even though it increases the IC size by just 10 percent to 6.6 million gates."
Now from our point of view as verification experts, we are witnessing these challenges every day, as our customers strive to reach definitive answers to crucial questions relating to IP reuse and design verification. For example, there typically exists an enormous verification environment that is larger than the RTL itself and just as difficult to modify as the code; and documentation can be incomplete, ambiguous or even inaccurate, and may not even correlate to the original designer's intentions.