The ASIC industry was born out of the need of systems companies to achieve product differentiation, time-to-market advantage and cost optimization. During the past 20 years, the industry has evolved through new levels of technology scaling and has learned how to pack tens of millions of logic gates on a single piece of silicon. That capacity growth has enabled higher levels of on-chip integration of different functions. While manufacturing capacity has offered the means to realize the great system-on-chip promise, the precipitous lag in design productivity, methodology and tools has hindered the industry's ability to deal with growing complexity.
SoC represents an evolution of ASIC methodology. The creation of ASIC cell libraries marked the first, innovative step toward achieving higher design productivity through reuse. Also, ASIC libraries were among the first technologies that could claim some intellectual-property (IP)attributes.
In the late 1980s, ASIC companies pushed to participate in high-volume market sectors by delivering application-specific standard products. They licensed compute engines such as Sparc and MIPS and built standard products around them. Thus, the IP business was born, and the concept of design reuse emerged.
An expansive cottage industry was created to feed the increasing appetite of the "new and improved" ASIC companies and systems companies that had the capability to design chips containing function building blocks or IP cores. Efforts revolved around the idea of creating standard products.
During the early years of SoC evolution, SoC designs containing a compute engine were designed using different on-chip bus architectures based on a designer's prior experience. As a result, individually designed building blocks, or IP cores, had to be interfaced to a specific bus every time the same building blocks were to be implemented in a new design.
What followed was the emergence of IP core libraries as part of the overall ASIC technology capability. This initially seemed like the next step in library growth and reuse. However, the transition that had to occur in order to enable the use of IP cores in ASICs has proved to be quite difficult.
Designers must take much the same steps to implement IP cores in an application-specific standard-product design flow as they have for years in doing custom chips.
IP cores can be incorporated into a standard product through the use of brute force or the process can be simplified by following a methodology. In contrast, handling IP implementations and reuse in SoC or IP-ASIC designs demands a more deliberate, elaborate methodology and discipline, because the need exists to quickly implement any number of IP cores into many different SoC ASICs.
To support IP reuse, the organization must establish a resource structure that is able to provide application-level expertise for each particular IP block. Skills include the ability to address RTL functionality, compliance, synthesis, back-end issues and other challenges that customers face during design implementation. In general, customers don't have the time or resources to become experts in all of the IP they need in their products; vendors must provide the expertise. Seamless environment
To meet customers' time-to-market requirements, vendors need complete knowledge of the functionality and application of complex IP cores. If, for example, customers want to implement a USB 2.0 I/O pipe in a design, they should not have to take the time to learn about the USB 2.0 standard protocol. Instead, customers prefer to have IP vendors address the core-testing and validation issues that arise in system testing, and provide design and verification of the required bus interface and/or dedicated DMA engine for the core.
This example leads to the conclusion that successful IP reuse is not based on a simplistic drop-and-stitch process. It requires experience and skill sets that can create the seamless environment for IP reuse. Leaders in SoC design using IP must build highly skilled design and application teams that are supported by sophisticated design automation tools.
Bridging the gap
Those resources serve as a bridge between the ASIC company and the original IP provider, or, if the IP comes from a third party, the licensor. This concerns every aspect of IP specifications, implementation, performance and compliance. Leading-edge companies using new or unique IP for the first time can expect to undergo a trial-and-error process before the IP can be integrated into an SoC.
Having the resources to implement a workable methodology also plays a pivotal role in the validation and integration of new IP cores. Consider, for example, early adopters of new IP such as a processor-specific cache subsystem or a 10G Ethernet media-access controller. Lack of familiarity with those components can hinder both the chip design and the validation process, and cause significant schedule delays.
Leaders in the industry must create methodologies for IP release. At Fujitsu, methodologies include problem analysis and a verification process that provides quick tracing and resolution of problems by engineers familiar with the specific IP core. IP quality may differ because some IP is so new and lacks field data and maturity. Or, quality may hinge on the quality of the IP test suite. Those factors, coupled with the depth and robustness of the verification strategy, define elements that may contribute to design errors.
IP licensees have responsibilities, too. These include understanding legal obligations and staffing their own teams with employees who can interpret and manage IP transactions.
Developers must deal with the technical and logistical issues in the SoC or IP-ASIC design environment in order to have a good chance of obtaining successful results. If not addressed properly, these issues can be time-consuming and costly and can jeopardize the customer-vendor relationship.
Because of their mission and business model, EDA companies can only focus on design automation tools. It is the responsibility of the SoC or IP-ASIC service provider companies to address these issues. The need for IP reuse will increase as design complexity grows to higher levels. This support structure forms an invisible layer that would make SoC/IP-ASIC engagements as seamless as possible.