Bridging the Gap Between IP Provider and Silicon Design Center
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.
Figure 1: Bridging the Gap
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.
Most silicon foundries, the ASIC foundries for sure, are realizing the most success by specializing in a process or capability that is in limited supply. This is basic economics. Products in scarce supply demand a higher price and therefore higher profit margin. In silicon, this may be ultra low power, low EMC, high temp or voltage or low entry cost structured products. These specialty processes many times require special methodologies. It is impractical to expect that a single piece of IP with a stated methodology could adhere to all the requirements sight unseen.
There are several examples of these custom methodologies that are worth discussing. First, in the area of Design-For-Test (DFT), the way that test features are inserted into the design should be consistent with what the test engineers are expecting. Commonality from one design to the next eases the amount of design effort the test engineer must put into the program. Tap controllers, BIST, NAND tree test and how analog cells are tested should be done in a standard fashion to minimize the effort and cost. It is even possible that these approaches may vary from one piece of test equipment to the next.
The second example is a design requiring ultra low power. These are commonly seen in battery or solar powered applications. Gating clocks is a frequent way of designing circuits for ultra low power. Specialty flip-flops that have master and slave clocks brought externally is another approach. Both of these require special attention to the methodology when they are used. Static timing analysis (STA), Logic Equivalence Checking (LEC) and timing driven layout are impacted.
The third example is high reliability devices. Automotive applications and Medical devices require 1 part per million reliability. To achieve this, extraordinary measures must be taken in the area of design for test. Especially in the area of analog circuitry. Special DFT methodologies are required.
Role and Responsibility of the IP Support Group
The solution to this problem is to have an internal design group responsible for qualification and dissemination of the IP to the rest of the company. The four main responsibilities of this group are Certification, Creation, Integration and Release Management of IP.
- Certification
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.
Fault insertion is an exercise where you intentionally introduce an error into the RTL and verify that the test bench flags the problem. As the code coverage metrics and tools improve this step may be deemed unnecessary.
It may be necessary to generate encrypted models due to licensing limitations of distributing RTL. Encrypted models will most likely be handled on a tactical basis.
The IP Support group should generate a verification report that shows the results of the verification effort. This report should provide a summary of the results of the above steps and also include detailed results in the form of an appendix or separate document.
- Development of IP
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.
- Integration of IP
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.
Some of the more complex IP blocks will require supporting items to help the customers and/or design centers learn to use the IP. This will be accomplished with Reference Designs and Demonstrations kits. These items also help the marketing and sales teams establish a high level of confidence with the customer.
The Reference Designs may take the form of:
- FPGA Designs
- Silicon
- Board level products
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:
- Pre-sales support. Convincing the customer that the IP will perform to meet their needs.
- Quote support. Helping the sales engineer understand gate count estimates, license fees and royalty schemes.
- Application debug. In cases where failures are observed either in the design center or at customer sites, the IP designer will apply his subject matter expertise to help resolve the issue.
- IP Release Management
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.
Figure 2: Cost of Producing an ASIC
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.
Figure 3: Cost over Time
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.
In essence, IP vendors should view their silicon design partners as a channel to market rather than customers. If a design center is well versed in a piece of IP and is happy with the quality, they will seek to use it on as many designs as possible. These subsequent sales require very little support from the IP vendor.
Conclusion
High quality, easy to use IP is a great way to help silicon houses win designs and then execute on their commitments. The current ways of structuring IP cost is not working in a wide range of situations. The best approach is one of partnership. This paper put forth a compelling argument to change the IP cost structure and made suggestions on how best to do so.
Pivotal is the formation of an IP Support Group closely aligned to the silicon design center. The need for this group has been detailed in this paper. Formation of such a group will help to keep the IP vendor’s support cost down and therefore enable alternative licensing arrangements. Suggested in this paper is a staged licensing arrangement that addresses the IP vendors up front costs but also creates an environment where vendor and silicon house share in the risk.
|
Related Articles
- The silicon enigma: Bridging the gap between simulation and silicon
- Static timing analysis: bridging the gap between simulation and silicon
- Bridging the Gap Between Silicon and Software Validation
- Bridging the Gap between Pre-Silicon Verification and Post-Silicon Validation in Networking SoC designs
- Bridging the gap between speed and power in Asynchronous SRAMs
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |