|
||||||||||
Bridging the Gap Between IP Provider and Silicon Design Center
By Ron Landry, AMI Semiconductor, Inc.
Plano, Texas USA Abstract: In today’s IP marketplace, two forces are in place that is having the affect of distancing IP providers from their customers. The IP vendors are striving to provide products that have broad appeal and are compatible with a stated methodology, usually referred to as a “reference methodology”. Their customers on the other hand are striving to differentiate themselves in the market place and therefore seek to offer silicon solutions that are better, in some manner, than can be obtained from the bulk of the foundries in the market place. Reference methodologies just don’t cut it. In this paper the reasons why the gap exists and some practical approaches on how to fill the gap are explored. With this understanding, the different IP cost structures of license fee and royalties are discussed to see which fits best in which situations. Introduction In today’s business climate, silicon design centers are being pushed to produce more complex designs on a tighter schedule. To accomplish this they are looking to the IP market to meet their needs rather than designing from scratch. Given the fast pace, the design center needs IP that “drops into” their flows seamlessly. The IP vendor on the other hand seeks to provide IP with broad appeal. This creates a gap between what the design center seeks and what the vendor provides. This paper details the causes of such a gap. It presents a solution of having an internal IP support team to bridge this gap. With an understanding of the different roles played by vendor and support group, alternative licensing models are proposed.
Why the Gap Exists It was not that long ago that most of the methodologies practiced in silicon design houses was of the home grown nature. Scripts and utilities were put together by the engineers and the most useful of these became part of the methodology, almost by default. Remnants of these utilities still exist today to varying degrees in most silicon houses. Many times, these home grown scripts preclude the use of some or all aspects of the reference methodology.
The IP Support Group will review the deliverables for completeness, quality and accuracy. The output of this step is a report that includes an inventory of what has been reviewed and a list of items that should be addressed to improve the quality of the deliverables. With the basic understanding of the IP gained by reviewing the deliverables it is possible to generate a Verification plan. Each IP block should have it’s own custom plan. In addition the plan may include items that are specific to the type of IP that is being certified, for example, compliance tests. If physical prototyping is required the details should be documented in the Verification plan. Independent testbenches should be used to test the IP when available. Many interface and protocol standards have compliance test benches available from verification IP vendors. When available, and reasonable, these independent verification environments should be utilized to prove compatibility of the IP under test. In some cases the independent test bench can be developed by the IP Support Group. Source code design rule check should be performed on the IP using the latest released rule sets. The IP Support Group has the discretion to determine an acceptable level of RTL DRC results. In some cases the RTL may be released that is not 100% DRC clean. In those cases an explanation should be provided. Simulation of the supplied testbenches will be done on RTL and if applicable, netlists targeting specific technologies. In cases where the provided test bench environments are deemed to be inadequate, it may be necessary to augment the verification with tests developed in house. These additional tests may be requested from the IP vendor but in some cases this may not be practical. The IP Support Group should run Code Coverage analysis on the supplied testbenches. This data may be supplied from the IP vendor. Additionally, if functional verification is performed, coverage definition and level achieved should be supplied. The IP Support Group should develop synthesis scripts that are compatible with the supported technologies. These scripts serve as a reference for the design centers should they be doing the synthesis. Modifications to support the specific technology, voltage and temp corners will be done by the synthesis engineer. Sample synthesis runs in the target technologies should be performed. Some cores will overlap multiple applications and may need to be synthesized to multiple technologies. Netlist design checks should be performed. This is another example where in-house scripts are widely used. It has become quite common to perform some level of FPGA prototyping. This step should be performed to check the compatibility of the core with FPGA architectures. Static timing will be performed assuming reasonable numbers for input and output delay. The specifics of these numbers may be dependant on the core and will therefore be documented in the verification plan for the certification. The STA report should contain examples of the most critical multi-cycle paths and false paths. Running the functional vectors against the synthesized netlist will identify vector related simulation problems. For instance, signals that change on clock edges may simulate without issue in RTL but cause problems such as “X” states at gate level.
The development of IP should incorporate all of the elements outlined in the 3rd party section above with additional emphasis in some areas. The newly designed IP is assumed to be less robust than IP that has been used in many applications. For this reason newly generated IP should be scrutinized to a higher level. It should be assumed that the deliverables for new IP are less complete and contain more errors than mature IP. It should be expected that there would be more work required by the IP department to bring the deliverables up to an acceptable quality. Because of the nature of new code it is expected that the effort to analyze and resolve DRC issues will be greater for new IP. For new IP, the generation of functional simulations is perhaps the most important step the IP group will perform. Writing tests that exercise the core in an efficient way will be a challenge. This applies to analog simulations as well. Code coverage metrics for new IP should be stricter than proven IP. If the desired metrics are not achieved, the reasons should be documented in the code coverage section of the verification report.
The IP department should also participate in the integration of the IP into customer circuits from time to time. This will allow the designer to keep current his design skills. It will also be a way of helping the design center learn from someone experienced in the IP. When the IP support engineer is taking part in the integration, he should act as a member of the design team and should adhere to the methods and procedures governing that design. An example of integration work is making modifications to the code of a soft core. For example, the RTL produced could be subject to all of the requirements of code generated in the design center. The exact responsibilities of the IP designer shall be outlined in the project specification or project plan. The IP Support Group must also create design kits that are compatible with the company methodology. There are at least two different types of IP Design Kits. Customer kits contain all of the deliverables that can be given to customers. In most cases, license agreements limit what can be distributed. Design center kits contain all of the deliverables needed to implement the design in a circuit. As tools and methodologies change these kits will need to be updated. Distribution of these kits should be through the IP Support distribution system.
The Reference Designs may take the form of:
Support of both internal and external customers is perhaps the most important thing performed by the IP support group. The IP designer is the company’s subject matter expert on the cores she supports. The IP department supports its customers in the following ways:
The IP Support group should be responsible for the management and release of all IP to the rest of the organization. This includes tracking revision history and updating the users when issues are found in the IP. License Models Now that the need for, and an understanding of, the role the IP support group plays has been discussed, a dialogue of licensing models is warranted. First it is helpful to understand the costs involved in creating a device. The pie chart below outlines these costs at a very high level.
At first glance it stands out that the IP costs are but a sliver of the overall costs of the project. However, the chart below outlines when these costs are incurred. It can be seen that a major outlay of funds is required at the start of the project. Given that a large number of projects never get to volume production, this can cripple the overall profitability of the business. If you evaluate the reasons why projects do not complete you will see that technical reasons are in the minority. Most of the time, shifting market conditions is the cause.
To help remedy this situation, a staged approach to licensing is appropriate. A start of project fee, a design completion fee and a start of full production fee help the silicon vendor for those cases where the project is canceled before completion. It also helps the IP vendor in that they get enough money up front to cover their support costs. Realize that the internal IP support group will help to minimize those costs as well. In cases where royalties are appropriate, a maximum payout clause should be considered. This helps to ensure that the IP vendor gets their money but the overhead of managing royalty payments is held to a minimum.
|
Home | Feedback | Register | Site Map |
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |