Application Specific IP - Ensuring Semiconductor IP Quality
Gerardo Nahum and Omri Raisman, Rosetta IP
Abstract:
One of the major barriers for Semiconductor IP commercialization is to provide evidence for an IP’s quality. A common approach by IP vendors is to prove the quality of their IP in a test chip. Usually the Die contains the IP block separated from the System-on-a-Chip (SoC) . It is, though, uncertain how the block will function in ASSP and ASIC products, potentially damaging its perceived commercial value.
The current model of an IP company is usually based on a single IP product, providing a specific functionality, independent of the market and the application in which the targeted product for that IP is going to be used. This model in fact, is the main criteria determining the value and the quality of an IP.
Being totally agnostic to the rest of the chip, the application and market in which the IP is targeted for integration, diffuse any attempt to prove the quality and determine the value of the IP; which elevates the risk of using the IP for a certain device.
In Rosetta’s methodology, the IP Core is a block within a subsystem, integrated to enable the subsystem functionality and targeted for a specific market and application. By analyzing the specific requirements of the market and application, and by providing an IP package targeted at those requirements, we solve and mitigate the IP quality risk. Rosetta’s methodology turns the IP block into a solution rather than a standalone block within the SoC.
This paper describes the making of such an analysis, as well as a comparison between different IP blocks, stressing the commercial and technical differences between standalone blocks and application-specific IPs.
Semiconductor IP
Semiconductor Intellectual Property has always been defined as a generic block which can be instantiated and reused in many designs regardless of the nature of the design.
This definition pushed the industry to generate Semiconductor IP only for standard interfaces, Memories and CPUs. 99% of the IP market is dominated by companies generating such design cores, with the goal of providing as standard an IP block as possible.
Companies like ARM®, MIPS®, and others target their products to generic applications. Eventually, market forces and customer demands tag the specific IP to specific markets. Would it make sense to design the IP to target a specific market?
In fact, the correlation of an IP to a specific application is now the reality.
The main problem is how to leverage this reality to enhance the value in terms of business being generated, quality enhancement, cost effectiveness, R&D cost saving, and tuning the support infrastructure of the IP.
The dilemma is clear - generic versus specific. In the general case, an IP starts as generic and ends as specific.
In the chip industry, the dilemma has been solved a long time ago by creating two type of products, ASSP and ASIC.
Would it make sense to use the same methodology for IP cores?
The need for IP is not only in standard blocks but on any of the functions of a SoC.
IP providers target their technology to be as generic as possible in order to capture as much of the market and as many applications as possible.
In this paper we review this decision and reveal the implications. We compare two types of approach and their results.
Application Needs
The IP community has used the term “Application” to describe the usage of a certain electronic system by its users. For this reason semiconductor vendors communicated the level of support provided by the product they offer for a certain market or use. As a result, the trade-off for allowing the system developer to enable a system function like Boot, On/Off, Read/Write, Store, Filter, etc., was between hardware and software. Early systems were designed and developed in-house, and each vendor captured the user’s application in a product requirement document which detailed the product specification and system architecture.
As today, engineers working on these documents took into consideration the various development and technology trade-offs such as cost, size, power, speed, robustness, ease-of-use, time-to-market, second source, etc. Today the process of defining a solution for an application is more structured, mainly because companies tend to design more fragmented system solutions that allow the combination of multiple solution pieces into a single system. In this kind of environment, vendors tend to propose a standard solution to a given application. Often, when several vendors offer different solutions for the same application, they tend to compete on a specific domain while making sure they are aligned on other aspects.
For example, WiMax Mobile and LTE are aligned to support 4G market requirements, BlueRay and DVD-HD both targeted the same optical media, etc. Today, common practice is for the System company to capture the Application (user experience and system functionality). A good example of such practice is the development of the Apple iPhone ® and its unique user experience. In most cases the system company deals with the integration of the various system components at the hardware level as well as the top software level. The system company will often handle the Graphic User Interface and mass production and field support, leaving the rest of the R&D to their software and hardware subcontractors. TI OMAP® provides a perfect example of how a semiconductor vendor off-loads R&D from the mobile handset developers, like Nokia and SonyEricsson, by tuning its DSP to support their multimedia application requirements.
As a result of this approach, the dependencies between the different vendors in developing a complete system is limited to the support level provided by the vendor to answer the application needs. In this kind of business environment, the vendor tries to justify their product by aligning it to a specific application, trying to make it a cornerstone technology to be used in any system product for that application. In other cases, vendors stress the benefits of the specific implementation, hardware versus software, performance versus price, etc.
Ethernet PHY IP as an example
Ethernet PHY has been licensed as IP for a long time to several markets. Industrial Automation has adopted Ethernet as its main communication protocol to synchronize several of its actuators and sensors. To gain this market, a great deal of work has been done on the standard Ethernet PHYs in order to lower their latency, whereas an up-front decision on the design and architecture of the PHY would have saved a lot of fixing effort.
The cost of porting a technology to be compliant with the application and market requirements is much higher than up-front design.
In this specific case, the design of the PHY took about 20 man/years. Adapting the PHY to the Industrial Automation market took about 2 man/years, which were mostly dedicated to re-coding and repetitive verification.
The risk associated with this type of work must also be considered, and the loss of time-to-market should be taken into account.
Many of the features of the original design are not used today, and up-front design could brought savings in design, verification and validation.
These features were present in order to stay as generic as possible.
Fig 1: Development Effort
A thorough market analysis enables IP architects and designers to perform a much more cost effective and efficient job. In addition, the quality of the IP would be greatly increased since the application’s features would be solved either by design, or tested in real scenarios.
Figure 1 describes the efforts that have been made to capture the different market requirements over the years.
The first design was intended to capture the enterprise market. With the need to address the home market, a new set of features and processes had to be implemented, which additional added another 5 man/years and, later, the need to address industrial automation added another 2 man/years.
Application Specific IP – ASIP
There is a need to differentiate the standard IP cells from the complex blocks which are targeted to specific applications.
Standard IP cells are agnostic to the application and can be instantiated in several typeof application. The way IPs are defined today implies an attempt to capture as many markets as possible.
A complete The use case scenarios that an IP may encounter cannot be tested into a verification suite because of the span large number variation in the different environments the end product will encounter in reality required.
Knowing the set of applications in which an IP will be used gives a great advantage. This valuable information can be used for all levels, from the architecture, through the design and verification stages, and also for the on to marketing and sales efforts.
On the Architecture, the number of features the IP needs to support is constraint by the application.
The number of use cases for which the architecture needs to be valid is limited and are therefore manageable.
An optimal architecture leads to a much more cost effective design and therefore a higher value IP.
The main gain is at verification, in which testing the IP in its final environment enhances the quality of the IP by an order of magnitude. Quality as a major factor can be translated into business.
Quality is one of the major hurdles an IP vendor must overcome to license its products.
The IP provider can greatly enhance its offering by showing the quality on a specific application rather than in a generic way.
On the business side, positioning the IP as target for a specific application and market gives a great impact in today’s competitive landscape.
A company with a need for IP will associate such approach as a benefit and as an evidence for required expertise available thru the support provided by the IP vendor.
The propose terminology for this solution is, ASIP: Application Specific IP.
Similar to the chip vendors, there is a differentiation between ASIC and standard products. An ASIC’s value depends on the application in which it is been used.
Conclusion
The value of targeting the IP for specific application is demonstrated in various aspects of the IP product, from cost savings on design and verification to quality enhancement and addressing customer specific concerns. Therefore having an IP targeted, knowing for a specific application, have a great value for both the IP provider and customer.
The initial market research is critical to generate this knowledge before the design starts (rather than opportunistic) and maximize the value from this approach.
The entire development plan from architecture to test, to marketing and sales must consider the type of application for which the IP will be integrated and must address a solution to the customer pain.
Application Specific IPs can be a great way to increase return on investment for the IP vendors and increase the value of their product offerings.
About the Authors
Gerardo Nahum and Omri Raisman are co-founders of Rosetta IP, representing more than 20 years of experience in business development and semiconductor technology. Rosetta IP provides innovative technology in the form of IP cores to the semiconductor industry.
Related Articles
- Semiconductor Reliability and Quality Assurance--Failure Mode, Mechanism and Analysis (FMMEA)
- Application of Option in Semiconductor IP Business Strategy
- Improving Verification Efficiency Using Application Specific Instruction Processors
- Semiconductor IP Quality - A User guide
- Ensuring software quality & reliability with configuration & change management
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |