| 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. Functionality
The issue with functionality is not over what the IP is supposed to do, but with how it does it. There are three primary divisions of IP in this regard: programmable, parameterizable and fixed. Each requires a different approach to the selection process. The most straightforward of the three categories should be the last one — fixed-function IP. But in some ways it is the most difficult. Obviously, if you are looking at fixed-function IP, you choose blocks that do what your system requires. In some cases, the system requirements are neatly defined by a detailed industry standard, such as one of the levels of PCI bus or USB interface. In other cases, the definition of the system requirements is up to the system architects. It can be challenging to be at the same time precise, comprehensive and concise. But it is also necessary — any differences between the IP selected on the basis of the requirements definition and the actual needs of the system will have to be made up during the precious minutes of the design schedule, often by a cooperative effort between IP vendor and user design team.  Parameterizable IP attacks this problem by assuming at the outset that whatever the IP vendor might do, the user will need something slightly different. So some aspects of functionality and system interface specifications are made to be alterable by either the vendor or the user. In one respect, this does simplify things. Now instead of demonstrating that the IP does precisely what is required, it is only necessary to show that the requirements, whatever they turn out to really be, fall within the range of parameterization of the IP. Mathematically, at least, that is a less stringent criterion. But parameterizable IP raises several new issues. The tools necessary to parameterize the IP now become a key part of the deliverables. Are we talking about a five-page manual and a set of switches, or are we talking about an entire behavioral language and an IP generator tool? These will have to be evaluated. Does the parameterization process produce models in all the views necessary for the design flow, and are the models consistent? Perhaps most important, has the IP actually been generated, implemented in silicon and used in the configuration you need? Or will you be the first to try this particular set of switch settings? The third category of IP from a functional point of view is programmable IP. This set includes CPU cores, microcontrollers, programmable state machines and quite a variety of things that don't appear programmable but actually are, including some protocol controllers and I/O blocks. When the IP is programmable, the selection process is, unfortunately, like the selection process for a microcontroller or microprocessor — there are no shortcuts. This process is too lengthy to detail in a short article, but it means evaluation of instruction-set compatibility, programming tools, debug tools, kernel, middleware and application libraries and development environments. On another axis, it also requires benchmarking to determine whether the core is actually fast enough to meet the deadlines that the system will impose on real-time tasks. Needless to say, none of those are trivial questions. System interface
There are two important categories of IP with regard to their interface to the rest of the system: those that use industry-standard interfaces and those that do not. During the selection process, the differences between these categories are straightforward but not unimportant. There have been numerous attempts to create industry-standard interfaces between IP blocks. For the most part, the result has been the dominance of a single vendor-specific standard for bus-oriented SoCs and a plethora of approaches everywhere else. Among bus-oriented architectures, the de facto standard is of course the ARM bus architecture, Amba. Amba began its evolution with a relatively simple silicon bus issuing from the ARM7 core implementations. It was in effect a version of the bus coming out of an ARM7 microprocessor chip, but implemented with multiplexers rather than tristate logic. As on-chip architectures grew in complexity, so did Amba, evolving into a multilevel network of interconnects that could mix multiplexer-based, lower-speed branches with switch-based core bus structures. Throughout this process, ARM was reasonably successful at preserving the peripheral interface definitions, so that the ever-changing Amba really did act as an interface standard for developers of blocks that attached to the bus — especially the APB peripheral bus. Other vendors of processor IP have had their own bus standards of greater or lesser technical quality, though none has achieved the ubiquity of the Amba architecture. And several independent IP companies have attempted to market bus structures of their own, together with interface standards. Most notable among these, arguably, has been Sonics Inc. By creating more or less widely used buses, these efforts have created de facto interface standards of benefit to both IP vendors and SoC developers. If an architect chose an Amba bus, for example, that person could then simply specify AHB or APB compliance for the IP blocks that would attach to it. This had the effect of reducing the question of hardware interface compatibility to the simpler question of how well the block met the Amba specifications. Then there are the IP blocks that do not support a standard on-chip bus. Either these are intended to connect directly to other blocks, as in the case of segments of a signal-processing pipeline or of phase-locked loop IP, or they are provided with a parallel interface onto which one may graft whatever bus interface one wishes. In this case the selection process becomes not about whether the interface is standards-compliant, but whether it has the correct data definitions, flexibility and bandwidth to play its role in the system architecture. This is necessarily a very different kind of decision, involving either precise system requirements definitions or good IP models and some architectural modeling. Design flow interface issues
The toughest questions to evaluate during IP selection often involve how the IP will interact with the design flow. Everyone has at least minor differences in their choice of tools, constraints, switches and procedures. This is especially true when it comes to out-of-sight, out-of-mind issues like power and clock distribution, scan and design-for-test insertion. It is double the case in advanced processes where, explicit provision must be made for complex design rules and guidelines. But differences between the flow used by the IP vendor and your flow can result in anything from annoying problems to failure of the entire design. So the design team must take whatever steps are necessary to identify potential problems during the selection process. The most obvious distinction in regard to design flow interfaces is analog vs. digital. There are those who claim the entire concept of analog IP is meaningless — that analog designs are inherently unportable and exist only in their implementations. There are others who claim that, with very important restrictions, analog IP can indeed be reused. These restrictions bear directly on the design flow. The first requirement is that the hardware interfaces between the analog block and the rest of the chip be very well-defined and, for the most part, that they be digital. This is needed to prevent the IP integration process from becoming a redesign of the analog circuitry. This restriction means, however, that the circuitry within the IP block that creates the functionality will for the most part remain untouched by any of the tools in the design flow. Often, analog IP is supplied in hard form, and so it must even pass through the layout process unmolested. This is just as well, since most SoC design teams lack both the tools and the skills to molest such a block. The other important restriction is that the block be placed in such a way that electrical influences from its surroundings are nil. In mature processes, this simply means following the IP vendor's guidelines on placement, power provisioning, input and output isolation, and guard rings. In an advanced process, it implies a very significant level of analytical capability on the part of the physical-design team. Another important distinction is between soft and hard IP. Soft IP, provided as RTL or perhaps as an annotated netlist, must be synthesized, placed and routed by the user. Hard IP, in contrast, is provided as polygons — the circuitry has been placed, routed and, presumably, analyzed to death by the vendor. Soft IP, since it engages so much more of the design flow, requires considerably more questions during the selection process. Some of these are about compatibility with tool flows, as discussed above. Others are about the predictability of the design process. What is the certainty that plugging the RTL into the user's flow will in fact result in a physical block that meets requirements? Has this RTL ever traversed this flow before and been implemented in this process? Hard IP brings with it a different set of questions. Very specific compatibility questions arise at the polygon level, especially in advanced processes, where mask makers may require certain annotations on objects in the polygon geometry. But there are more profound questions about exactly what's in the hard-IP core. What — exactly — are the interface requirements, since it will be impossible to adjust the core to correct a misunderstanding. What verification process has been used in producing the core, and does it meet the standards of this design team? What techniques have been used for clock and power routing, on which metal layers, and what assumptions have been made about routing near or over the core? How has design-for-test been implemented? What requirements will DFT place on the rest of the chip, and is the test coverage adequate? In advanced processes, since there are so many variables involving nonmandatory design rules, guidelines and design-for-yield practices, exactly what has been done in this area? Finally, there is a last, highly contentious question: Has the core been implemented in silicon before, or is this the first time? If the IP has been used before, the evaluation process certainly should include a detailed interview with the previous user — ideally, a previous user of the same process and foundry as the current design. But even this is no guarantee, experts warn. Each instantiation of an IP block exercises it in a slightly different way. Without formal verification, it's likely that your design will find a state into which no one has ever put this block before. So even working silicon in the field is only a proof of concept, not a rigorous evaluation. Some design leaders are even more critical of the most common silicon proof offered by IP vendors — shuttle runs of test chips with the IP block bonded out on them. These runs not only do not implement the block in a natural environment, they often lack the statistical validity of a production run as well. Were there skew lots? Were all the process corners for this design checked? Often, unfortunately, the answer is no. The other case is even more sobering. Particularly when dealing with leading-edge IP — advanced processors, emerging interface standards or new codecs — it is often impossible to find IP that has been implemented before. Sometimes, it is impossible to find IP that has actually been completed, and the IP will be designed in parallel with the SoC that uses it. In this case, the effort ceases to resemble IP reuse, and begins to be a joint development. Here the thing being evaluated is not the projected IP — which, after all, doesn't really exist — but the IP design team that will create it. And the questions must once again be entirely different. So we have seen a number of important distinctions when it comes to IP: fixed, parameterizable or programmable; standard or ad hoc hardware interfaces; analog or digital; soft or hard; previously implemented or untried. Each combination of these variables will potentially lead to a different set of concerns, and hence a different selection process. No wonder the conversation about IP selection sounds like a Babel of voices. See related image | 
