Design teams take a huge variety of approaches to selecting intellectual property. That is clear from even a cursory conversation with IP vendors, even before any systematic data gathering. Some teams are inherently rigorous and exhaustive, others rely on proven vendor relationships, others are far more ad hoc.
A call for opinions on the best way to choose IP will result in a Babel of voices.
To make any sense of the babble, one has to realize that it is not a chorus. There are several conversations going on at once. Not only do individuals and individual design teams differ in their approach to IP selection, but there are different kinds of IP that present different problems, and those problems must be treated differently.
This article will attempt to organize IP into categories and highlight the differences that separate them.
Dividing up the problem
Fundamentally, there are three different areas in which IP must be examined during the selection process. The first and most obvious is functionality. The second is fit into the target design. The third, and most often overlooked, is fit into the user's design flow.
The question of functionality seems pretty straightforward. You find a piece of IP that performs a function necessary to your architectural requirements. But in fact we can make at least one major distinction between different kinds of IP, based on how the functionality is implemented.
The second issue is not about functionality so much as it is about interfaces. Obviously, the IP inputs and outputs must be compatible with the needs of the rest of the system not just in information content, but also in coding, timing, transfer protocol and electrical levels. In more advanced processes, this issue may extend to such nonsignal concerns as noise levels and timing variations, both of which can have a profound influence on surrounding circuitry.
The third issue is also about interfaces, but in a more abstract way. In today's design flows, a piece of IP must interface to an amazing number of specific EDA tools all the way from providing an appropriate behavioral model for the design team's preferred architectural exploration tool to providing a known-good set of constraints and synthesis directives to, at the end of the day, working in the target process. Given the huge array of tool and process combinations in use in system-on-chip (SoC) design now, and given the limited resources of many IP providers, evaluating the quality of these interfaces can be a daunting challenge.