Business Considerations in SoC IP Procurement

Kenneth D. Wagner and Alan Nakamoto, PMC-Sierra, Inc.
Burnaby, British Columbia, Canada

1. Abstract

System-on-chip (SOC) devices are the heart of system platforms being developed for the consumer and enterprise markets. SOCs normally contain one or more commercial processor cores, additional data and control processing elements, on-chip bus and combinations of low-speed through high-speed interfaces for off-chip data communications and control. The SOC executes embedded firmware and may run operating system and applications code loaded from on or off-chip.

Among other key tasks, engineers design, reuse, or evaluate and acquire complex intellectual property (IP) for integration into SOC subsystems. To evaluate and acquire IP, the SOC developer must identify and engage effectively with IP vendors. The integration of the IP must also be coordinated with EDA vendors, development partners and design services contractors.

This paper details the legal, business and procedural considerations associated with the acquisition of commercial IP from IP vendors and partnering to facilitate its integration into an SOC device. It outlines PMC-Sierra’s experiences with commercial IP purchase and use over the past four years. At PMC, internally developed procedures are used to ensure an effective procurement process. Post-acquisition, the IP is audited for quality, ease of integration and vendor support. The objectives are to continuously improve the IP management and selection procedure and to rank vendors by their IP quality and service. Vendor support for hard, soft, verification and software IP must be available throughout the SOC lifecycle.

2. Introduction

Contemporary semiconductor integrated circuits are often complete SOCs, requiring skills in many different engineering domains to properly design and manufacture. The company developing the device, or SOC developer (in this case PMC-Sierra, Inc.), must collaborate effectively with its partners shown in Figure 1. These partners include: commercial sources for embedded components (IP vendors), third-party contractors (design services) who may be engaged to complement the team or to build accompanying collateral such as reference platforms, and CAD tool suppliers (EDA vendors), to debug tool and flow issues. To develop a flexible SOC-based platform also requires a substantial software development effort, often exceeding the hardware design investment and requiring more lead-time. SOC system platforms facilitate mass customization, where a flexible product can be adapted to the requirements of multiple customers.

Figure 1: IP Partners

Semiconductor IP can be purchased or developed for SOCs. If purchased, commercial IP is available in many forms: on-chip components suitable for hardware implementation (hard IP cores in a specific process technology or portable soft IP cores synthesizable to multiple target technologies), independent hardware verification test suites (verification IP), embedded chip firmware (firmware IP) and operating system or application software (software IP). Commercial IP can be purchased directly from IP vendors or, if unavailable, outsourced to IP vendors or design services focused on IP creation. Whether the SOC developer outsources device design work to a design services company, works with an IP vendor partner to procure or jointly develop new IP, or coordinates with a development partner, proper legal and secure access to the IP must be arranged.

3. The Business Case

3.1 The Case for IP Acquisition

An SOC developer may purchase IP rather than develop it internally because it has insufficient resources or skills in-house, anticipates unacceptably long lead-time or risk with internal development, or prefers to purchase mature high quality IP when available. Conversely, certain IP may be considered key to corporate strategy, so it will be developed internally to expand a core competency and to provide an anticipated competitive advantage.

To justify IP purchase rather than internal development [1], PMC requires an adequate return-on-investment (ROI) or payback period. An example ROI spreadsheet is shown in Figure 2. The spreadsheet compares internal development with commercial acquisition using a straightforward analysis that does not factor in indirect costs such as opportunity cost.

To proceed with the purchase, the ROI for a single IP use must exceed 3 for mature IP and 1.5 for immature IP. These criteria have been developed based on analysis of PMC’s total investment in specific IP evaluated after their release to production. The immature IP target of 1.5x allows a 50% margin for error in pre-acquisition estimation accuracy while maintaining a minimum effective ROI equal to one. This tolerance has proven necessary due to the difficulty of estimating resources when integrating unfamiliar commercial IP. Several other factors are considered in the decision process, including lead-time to IP availability in each scenario.

Figure 2: ROI Spreadsheet

To evaluate and calibrate the cost of PMC’s internal development for the ROI calculation, the leading IP vendor candidates are interviewed and asked to detail their investments to produce the IP. This data is used in the “PMC Internal Development” section of Figure 2. The accuracy of this analysis is then reviewed post-tapeout and post-silicon to improve the estimation process for succeeding acquisitions. For example, an unanticipated issue was that product validation (PV) costs to qualify commercial IP exceeded costs associated with internal development, so now different costs are used (PV lab engineers used validation boards sold with the IP that were unfamiliar to them).

3.2 Evaluation & Decision Process

To identify and determine an IP Vendor for an SOC program, qualified vendors for each specific IP type are contacted and sent a requirements document after signing a non-disclosure agreement (NDA). The document is either a request for quote (RFQ) or statement of work (SOW) Ultimately, the stability, accuracy and completeness of the RFQ/SOW and its satisfaction are the most important factors in a successful IP engagement.

The RFQ/SOW should include compliance to relevant standards when appropriate. When the RFQ/SOW specification is unstable, inaccurate or incomplete, the IP match will be compromised.

A review of the RFQ/SOW responses and appropriate engineering follow-up identifies the most promising IP vendors. A more detailed review of the selected candidates includes systematic checks of features, deliverables, schedule and references. The candidates are not evaluated based on IP cost, since IP vendors generally offer competitive rates after negotiation.

Although several foundries and other groups have established norms to identify the quality and maturity of their IP, the need for independent diligence remains. Efforts to establish standard metrics are challenging, since evaluation requires a substantial effort, ideally including review of silicon performance. IP vendors are better able to provide the status of IP usage (in beta, taped out, in silicon, etc.) rather than quantitative metrics. Currently a VSI Alliance Pillar group, in association with the Fabless Semiconductor Association (FSA), is beta testing Quality of IP (QIP) checklists [2] for soft, hard and verification IP (for more information, see www.vsi.org/pillars/IP_Quality_Pillar.htm and www.fsa.org). These checklists may better inform the customer and assist the IP vendor in qualifying and marketing their IP.

In PMC’s IP acquisition procedure (see Figure 3), leading vendors are requested to provide their deliverables for evaluation after executing an evaluation agreement. While a prudent step to reduce risk, direct evaluation of IP can be a costly process, especially if it requires lab analysis. So the list of leading vendors must be kept short. To select the best-qualified vendors, proposals are reviewed against key factors that in the past have indicated superior IP quality and vendor support. These factors include SOW/RFQ match, references, vendor support, performance and compliance logs and code structure. Using indirect measures rather than reviewing the source code itself is also very useful. For instance, for soft cores, portability, testbench completeness and audited standards compliance (if appropriate) essentially determine the quality of the RTL deliverable.

Figure 3 –PMC Acquisition Procedure

If it is determined that the selected IP will require customization, it is preferable that the IP vendor not IP/SOC 2005 – December 7-8, 2005 3 make one-off modifications, since this immediately creates a divergent code branch. It can then be very difficult and time-consuming to decide whether succeeding base IP updates are relevant and merge code branches appropriately. And custom IP may quickly become unsupported if the vendor does not consider the changes made strategic and integrate them into the main code branch.

So although it is tempting to try to lead the market by specifying customized IP, ultimately commercial IP should be acquired to leverage their eventual status as a commodity in the market and not to create unique cores (which ultimately is rarely a scaleable or profitable business for the IP vendor).

Conversely, purchase of highly configurable (via compile time option) or very programmable cores (via run-time options such as register settings) offering hundreds of separate configurations should also be viewed skeptically – their verification across a broad range of configurations and runtime settings is often inadequate.

4 The Legal Agreement

Negotiating a fair agreement for both parties should guide the business negotiations. To establish rights and protections for the SOC developer acquiring the IP as well as for the IP vendor selling it, the acquisition of IP requires a license agreement or an equivalent contract. Sometimes a master agreement may be executed to cover the IP architecture or product family and individual amendments signed for each IP type.

The business terms of the agreement are confidential and must be limited to senior managers and executives with a need-to-know. The engineering team itself must review final deliverables and abide by the security and confidentiality terms of the agreement. And the corporate data management infrastructure must be adequate to ensure that the treatment of IP satisfies contractual terms.

No industry-standard template exists for SOC IP license agreements despite several attempts. The failure of these efforts is due to the broad range of contract objectives for an engagement, specific needs of the parties and variations in contract law and IP law by jurisdiction. At PMC, a checklist listing key corporate objectives has been developed to ensure that important IP contract conditions are met. It is assumed that contract jurisdiction will be in the State of California and that US Federal regulations will govern issues of IP protection. The following sections describe key aspects and risks of an IP license agreement.

4.1 Confidential Information

Prior to any exchange of confidential information, a NDA or equivalent must be executed. A two-way NDA protects the proprietary information of both parties. Its subject should be specific to the purpose of the engagement.

4.2 Residual Rights

The term intellectual property rights (IPR) residuals means information in intangible form which may be retained in the unaided memories of the persons who have had access to the confidential information, including ideas, concepts, know-how or techniques. A person's memory is unaided if the person has not intentionally memorized the confidential information for the purpose of retaining and subsequently using or disclosing it.

If the SOC developer is also considering internal development while exploring commercial IP, it must preserve the right to independently develop domain IP while being exposed to commercial IP. So retaining residual rights can be important during IP evaluation and subsequent partnerships and necessary to arrange immediately. The NDA should contain a clause granting the SOC developer residual rights to develop IP in the same or a related domain. Of course, the IP vendor’s own rights and ownership continue, and no license is granted to the IP without a separate agreement. A residual rights clause also protects the parties against claims of violation of trade secrets. Of course, such a clause may increase the IP vendor’s concern and hence may make information exchange more difficult.

4.3 Third-Party Contractors and Design Services

License agreements should allow use of contractors on-site and, if required, off-site. The use of off-site contractors may be subject to audit by the IP vendor to ensure adequate IP protection on contractor premises. The SOC developer should perform an initial design services audit to ensure the overall security of the program.

4.4 Access and Security

IP access and security requirements must be carefully documented in the contract and be within the capability of the SOC developer’s data management systems. Very restricted access can make it difficult for a collaborative team to use IP efficiently. Each commercial IP deliverable should have the least restricted level of security possible, reducing the management burden and customer exposure. IP security must be balanced with collaboration and data management effort.

4.5 Indemnification

The SOC developer should always be indemnified against infringement by the IP vendor. The vendor should disclose all known or pending infringement issues before sale, so that risk can be properly assessed by its customer and to ensure that the vendor is not at legal risk to its customer.

The IP vendor must make best efforts to resolve infringement brought to its attention directly or by its customers. If infringement is alleged, the IP vendor will normally ask for control of its defense and, when appropriate, (1) arrange for permission to use infringing IP through cross-license, payment or other business arrangement; or (2) release a non-infringing version of the IP.

The SOC developer must also retain manufacturing rights to the infringing version, if necessary at its own risk. This is necessary due to the substantial cost of revising an soc device and the cost for customers to re-qualify a modified SOC. So solution option (1) is preferred and option (2) should be used to address only new SOC devices.

4.6 Escrow

If source databases are not shipped directly, the SOC developer must have the right to escrow the IP with a third-party in case the IP vendor fails to meet its support, maintenance or other obligations. The license agreement must also contain a clause stating that the SOC developer has the right to examine escrow material to ensure its quality.

4.7 Copyright and Source Documents

Legal permission must be secured to share selected deliverables with customers. To allow such sharing, additional legal agreements may be required between the SOC developer and its customers, for instance, sublicensing the source code for a software stack or a reference driver.

In the IP license agreement, it is important for the SOC developer to secure the right to receive and copy vendor source documentation for reuse in its internal engineering and customer datasheets and manuals. For both documentation and other source code, IP copyrights notices must remain intact i.e., original copyright notices should be retained and new notices due to later modifications added.

4.8 Rights to Modify and IP Ownership

The SOC developer often requests the right to modify commercial IP. This is a backup strategy in case the vendor ultimately cannot meet its obligations. Of course, such a vendor failure would be an exceptional case and any modification would be unsupported and potentially risky. The SOC developer should assert exclusive IP ownership rights to custom modifications, granting a use exception only if such rights deny other customers conventional use of the IP.

4.9 Support and Maintenance/Updates

To correspond to the SOC design cycle, 18 months of support and maintenance (updates) should be purchased with the IP. Unfortunately, most IP vendors offer only annual renewable support and maintenance. Response and classification of support requests should be addressed within 48 hours. All affected engineering staff must be allowed to file and monitor support requests.

4.10 Use Definition

The definition of a single IP usage can be a contentious issue - a very broad definition benefits the SOC developer acquiring the IP and a very restrictive definition benefits the IP Vendor. Minor variants of an SOC and multiple use of the same IP core on an SOC should not incur a new license fee.

The generally accepted definition of a single use is that the layout/artwork of a device does not change. Variants such as revisions to correct errors, different bondouts, software or pad reconfiguration or part numbers with limited features should be treated as the same use. More contentious areas are device revisions where the layout has changed beyond simply defect fixes, i.e., cost optimized versions or versions with reduced feature sets. These more substantial variants should incur at most a scaled reuse fee.

4.11 Payments and Royalties

Payments for proven mature IP can be more immediate as they represent a lower risk. Corporate cashflow requirements may determine the payment schedule. Payment for less mature IP should be staged and back-end loaded to ensure that successful IP use is achieved prior to final payment. So payment milestones should be planned carefully and described accurately in the contract. Some IP vendors participate in successful products through royalty-based fees. Royalties can be traded off with licensing fees, since license fee payments are lower risk and made earlier.

5 Post-Acquisition Procedures

5.1 QA of Deliverables

Quality assurance (QA) on IP vendor deliverables must be performed to ensure their quality for acceptance and payment. Key quality assurance checks necessary for acceptance should ensure that:

1. all expected deliverables are present;
2. the deliverables have been or can be configured to device requirements;
3. (hard or soft IP) the testbench can be regressed against the RTL and is sufficiently portable, with no dependencies on internal hierarchy;
4. (hard or soft IP) the testbench meets the expected standard of coverage and compliance;
5. (soft IP) the RTL can be synthesized to target timing with default scripts and constraints;
6. (firmware/software IP) the software compiles error-free and the expected software development environment is available
7. the engineering documentation and any other logs and reports are adequate;
8. the documentation source can be copied and inserted into engineering and customer documents (copyright notice displayed); and,
9. the vendor IP would pass the same audit as internally-developed IP.

5.2 Ongoing Support

The SOC developer should carefully track the use of all commercial IP. It must be properly indexed and catalogued to ensure that engineering groups can easily query for the IP type, find the specific IP purchased including its reuse and royalty costs and review its complete usage history. The database should contain information concerning defects found both in the field and reported to/by the IP vendor since the last release used. Should errata be issued for an existing device or an updated IP release used for a new device? The SOC developer should also feed back performance data to the IP vendor to encourage improvements for the benefit of all the vendor’s customers.

The IP vendor should be monitored on a regular basis to ensure the quality of its support and maintenance (updates).

6 Summary and Conclusions

With the rapid adoption of SOCs across the semiconductor industry, commercial IP plays an increasingly important role in getting products to market quickly. There are important procedural, business, legal and technical challenges to IP acquisition. SOC developers, IP vendors, EDA vendors and design services must interact effectively to ensure successful SOC IP integration. All parties should consider more standardized practices to improve efficiency and quality to benefit the SOC IP industry.

7 References

[1] John Weekley, Synopsys, Inc., “Modeling Total Cost of Ownership for Semiconductor IP, Fabless Semiconductor Assoc. Presentation IC Series, 2005.

[2] Fazzari Savario and Dan Moritz, “Is IP Quality Achievable, Measurable and Enforceable through the Design Chain,” IP/SOC Conference, 2004.