Protecting IP in a Modern Design Flow

By Dan Moritz, Virage Logic Corporation -- Burnsville, MN USA
Saverio Fazzari, Consultant -- Columbia, MD USA

Abstract:

The development of a new product requires constant changes and enhancements to meet the demands of an expectant marketplace.   In a modern System-on-Chip (SoC) design, there are a significant number of functional blocks or intellectual property (IP). These pieces include internally developed technology, blocks from partners, and IP for standard interfaces.   Return on investment (ROI) decisions are driven by external and internal sources. The overall challenge is how to integrate and verify the design within a certain timeframe. All of the different pieces need to work together successfully; otherwise the time-to- market/volume will be too costly.

Many different IP sources can be used in the design – from processor cores to embedded memory, logic and BIST – all implemented in a target foundry technology. The time and cost involved for successfully acquiring and using IP is a significant investment. There are legal agreements to be signed concerning usage, liability and support; verification that the IP works successfully; and assurance that the IP will not change in the overall design process.
IP protection is important so that successful usage within the legal and design environments is ensured. An IP provider must balance between providing support, end-user customization and IP theft. The user’s perspective is to ensure the IP is not adversely changed.

The challenge is to make sure the IP protection provides a secure mechanism that does not significantly impact the end-user’s design schedule.

There are many different ways to provide IP protection. This paper will discuss a number of different approaches and the impact each one has on the design environment.   There is an industry need to identify a method for the IP provider and the consumer to effectively use the IP in a flow. The objective is to provide a clear path for effective usage, support and security of IP in a multiple vendor design environment.

Protecting IP in a Modern Design Flow

The nature of market requirements has changed the development process.   Project tools have allowed closer scrutiny of the methods and costs associated with the various design steps.   For example, a marketing team defines a potential market and the product development costs are determined that allow certain decisions to be made. Much of the product development might be done by an in-house team. Larger companies have the resources needed to create and deliver the building blocks needed for the design.   A project design team works with other groups inside the company to get access to the building blocks of IP needed for the project. This limits the scope of potential projects since everything is done internally and the costs associated are rolled into the project.

As markets evolve, requirements and time-to- market pressures increase. The customer base also evolves, requiring new features much faster. Customers can not afford to wait for design teams to revise everything in order to deliver new products. Companies tend to develop in-house capabilities and outsource some features to external companies to improve efficiency. Why build it yourself, if it can be done by someone else? This led to the development of design chains with various partners responsible for different pieces of the process, including integration.   Companies started distributing the risk to a trusted set of partners in order to meet the target.   Looking at the modern SoC today, it is easy to see the different pieces that make up the design.   The source for these third-party IP blocks has grown dramatically. There are many companies that have become experts in providing IP blocks now. For example, there are multiple suppliers for high value IP like processors. Standards based blocks have become available to enable smooth interfaces. This extends from the complex USB core all the way down to the technology specific libraries used by synthesis tools.

The integrated circuit (IC) market is a good example of this evolution.   Companies began outsourcing the development of the ICs to third parties which caused the ASIC model to grow. Companies would take netlists and produce a chip; guaranteeing its performance. This model eroded the design process. Customers created the physical layout and outsourced the fabrication and other manufacturing steps to third party fabs. These fabs focused on delivering the part at the most cost-effective point. Core library cells and memory blocks are outsourced to third party companies by emerging foundries to help make their offering competitive. This allows the foundries to concentrate on their key differentiators.

Selection of IP is important for the successful completion of a design project.   Reusable IP allows design teams to focus on the development of key innovations, so the IP must work in the design chain effectively. This means IP must support multiple design tools. The model is created by diverse teams that must interact successfully. There are different levels of model abstractions that are used to make the task successful. For example, one may need a hard IP block for a particular piece since performance is critical and the hard IP block may be pre-optimized for the right technology.

Differentiated IP solutions are available from many companies. The table below shows the IP provider market as defined by Gartner. These companies are dependent on the ability to provide IP at cost-effective points for various design flows.

Top Ten IP Companies (Millions of Dollars U.S.) 2004 Rank	2003 Rank	Company Name	2004 Revenue	2003 Revenue	Percent Change	Percent of Total
1	1	ARM (including Artisan)	312.2	175.2	78.0%	24.5%
2	2	Rambus	144.9	118.1	23.0%	11.4%
3	4	TTPCom	104.1	73.5	36.0%	8.1%
4	3	Synopsys	76.2	81.2	-3.0%	6.0%
5	5	MIPS Technologies	56.7	40.3	40.0%	4.5%
6	6	Virage Logic	53.0	40.0	30.0%	4.2%
7	7	Ceva	38.5	36.8	5.0%	3.0%
8	8	Imagination Technologies	28.6	23.6	21.0%	2.2%
9	9	Mentor Graphics	27.3	22.2	23.0%	2.1%
10	10	Silicon Image	20.8	N/A	N/A	1.6%
		Other Companies	411.5	326.0	-4.0%	32.3%
		Total	1,273.8	936.9	0.8%	100.0%

Source: Gartner/Dataquest

The Design Ecosystem

The development flow for the IP block can be as wide and varied as the end system in which it might be used.   There are different types of models provided to customers for integration purposes. These vary from high-level code, to library models, to layout that must be integrated and tested in the target system.

This leads to a protection problem. In order to use an IP block effectively, you must be able to implement and verify that the behavior is what you expected it to be. For example, a design team inserts a core and then verifies that it works correctly.

IP that is needed for verification can be protected in a relatively straight forward manner. The EDA tool reads the IP and then verifies the design . This approach can be used by the various physical and logic verification tools that are typically found in a design process. Tools like Verilog or Spice simulators currently support this capability today. An IP provider can deliver a model that is protected and can be used by the design team. We will discuss different format examples later.

The second piece of the protection challenge concerns implementation IP. These are blocks that must be integrated with the designer’s pieces to create the final design. They must also be manipulated either by hand or by a tool, such as synthesis. Typically there is a debug step in which the design must be integrated. A designer will want to see as much of the available data for this step. This means that the IP must be exposed to the user. Given that the design containing the IP is being manipulated by multiple groups and designers, how can an IP provider secure their property?

For example, a design team is using a USB core which has been integrated into the RTL code of their design. During the synthesis process, the design team requires access to more information about the model to perform debug. The EDA tool requires access to the model in order to exhibit information about potential performance issues. The design team must analyze the issue to see if the problem is with their code or with the IP model. Many times, a design team wants the plain text version of the code so they can make their design work to their specifications. This can lead to other problems.

A designer may modify the IP to achieve a particular performance goal. This could possibly change the IP source code. Now the verification shows an error in the complete design.   The design team then works with the IP provider to resolve the issue. The cost for debugging the problem can be high if an IP company is unaware of a change that was made to their IP.

This problem may continue in the layout phase of the design.   When merging in hard IP, often times there can be mismatched layer information, physical incompatibilities at the edges resulting in DRC errors and performance degradation once the IP is in context and routes are made over the top.

The need and selection of IP is important. If a design team is successful, the usage cost for the blocks could be reduced.   The risk however, can be high. It is believed that integration costs for external IP can be 2x or 3x the cost of IP, without taking the risk of failure into account. Still, companies are compelled to license and use external IP and successfully protect it in the flow so that it does not lose its value.

No one solution will fit the many ways that IP can be developed, delivered, and designed in. There are three key solution areas that make up a well protected IP design and reuse ecosystem:

security by abstraction;
security by verification; and,
security by authentication.

By using a combination of these, we believe a majority of today’s challenges can be eliminated or greatly reduced.

Security by Abstraction

Abstraction is an interesting term.   The thrust here is around various methods to provide an alternative representation of the IP to be given to the user. The IP provider must be able to deliver and protect their IP, yet still provide the usability needed by the end user.

In this method of protecting IP, usable, but non- manufacturable views are provided by the IP provider to the SoC designer. For example, shipping LEF in place of GDS. For hard IP, this would require a trusted partner to merge GDS and create a manufacturable GDS that is fully functional with the proper performance.

Accuracy of the abstracted views is a primary concern, especially for high-performance IP that pushes the limits of the technology. Guardbanding and conservative route blockages must be added to avoid timing and signal integrity issues. The flattened design must perform reasonably close to the results seen by the SoC designer. For those pushing the technology who can not afford the performance loss, a trusted partner relationship must be built with IP safeguards in place. The value of the IP can then be protected with more favorable financial terms for the IP provider.

Another benefit of this approach can be disinformation. The abstraction can be made to confuse “black hat users” engaged in reverse engineering. This becomes more difficult with grey-box models, but can be accomplished with selective areas of black boxing.

Soft IP is typically provided in the form of HDL code and a series of constraint files for the tools. The HDL code needs to be protected so that it can not be modified or stolen. The common method used to be providing a compiled IP model that would link into the simulation environment. This block allowed a user to simulate, but they needed a specific model that worked on the appropriate platform.

Providing encryption support for the HDL files is also of interest. This permits easier data transfer because it is an obfuscated text file. The EDA community united together to add capability in Verilog (IEEE1499) to support different Encryption capabilities.   These new features expanded the language to include the infrastructure that would support the necessary pieces needed for encryption support. You could use the U.S. government’s recommended encryption standards such as AES. Most EDA tools are able to implement the encryption algorithm in their own particular method. Access to the IP is provided by a series of keys that are created by the partners in the IP design chain to allow the tool to use the IP successfully in the process.

One effective method of abstraction can be accomplished by implementing IP in plug-in or API based EDA systems. There are PLI interfaces for simulators, design database APIs, such as Open Access, and cell level modeling APIs, such as IEEE 1481. The IP content can be developed as a tri-mode model: black, grey and white box. License managers can be embedded to ensure the IP user has legitimate access rights.
New solutions are needed for each design entry point. Various IP models create different deliverables. Some might be a Matlab algorithm, while others could be a hardware/software co-design environment setup, or simply verilog or GDS. The key to abstraction is retaining usability, while obscuring the most valuable (manufacturable) part, ensuring that each licensee has paid the developer.

Within this approach, there are many different techniques to protect the IP. The key questions involve the right to access for IP for usage. How do you unlock the IP for usage by the intended party? Another problem is, once the IP is made accessible, how do you prevent additional access by unauthorized parties?. The keys to unlocking the IP must be closely managed.

To protect the IP, you must know who has the right to access the IP. These are the trusted partners.   They must have access to use the IP successfully. It is important that IP usage be made as easy as possible. Unauthorized parties must be limited in access to the particular blocks.

Finally, there is an unresolved question concerning the trusted partner. If a foundry and their auditors are trusted, the GDS merge could possibly be done there. If not, a respected and accountable third party could be used to merge in the IP and provide an accounting to the IP developer.   This approach has been used by companies looking at markets where they feel that IP protection laws are minimal. You create a trusted design house to enable the development of the final product.

Security by Verification/Repair

A continual progress commoditizes all IP. As the IP is used successfully, maturity grows in the block and companies are able to provide IP solutions for a particular function that are well proven. Since it is mature, there will typically be more competition. IP consumers and users will pay less for the block since there is less risk involved. So, the dynamics of SoC development change. The problem was the integration and successful validation of the IP, both internal and externally developed. As verification becomes the largest cost of producing a SoC, the corresponding value of IP verification also goes up. Effective test benches and qualification of IP have comparably more, and longer lasting, value than the IP itself.

This has lead to the growth of a verification market that helps enable designers using advanced standards based protocols. They are able to test that their implementation can work successfully with the bus they need. An Open Core Protocal (OCP) verification IP block can help ensure that the MIPS core successfully links to the I/0 blocks.

These verification IP blocks contain information that can validate that the behavior matches the standard. A Verification Intellectual Property (VIP) block also can create compliant traffic to help test the overall system behavior. It allows the design to ensure the block is in place correctly.

Securing the IP can be done by licensing the testbenches and/or the repair function in the case of memory IP. The built-in self-test (BIST) functions on a chip have value and are most effective when implemented by the developer of the IP being used. Virage Logic licenses the Self Test and Repair (STAR) Memory System™ that works with its memories. There is value in a memory instance, but a greater and more long lasting value is using that memory within a STAR Memory System bundle that tests and repairs itself on the tester with e-fuses.

Security by Authentication

Authentication is a critical problem with IP, especially for companies providing chips to consumers.   There are many examples of processors being counterfeited and sold with a higher performance number – a 2.0 GHz chip actually is 1.4 GHz chip.   There must be a way to ensure that the IP is what it expected or specified to be. This is also important for IP support purposes. An IP provider wants to ensure the part has not been modified by the user.

Authentication should be able to occur anywhere in the design process to ensure that the IP is what it should be. Typically, companies will use a test pattern to help define that this is the correct module.

Ideally, IP could be authenticated and enabled before and after manufacturing. Prior to manufacturing we mentioned that a trusted third party partner would be helpful in authenticating the SoC designer is a valid licensee of an IP block. To further expand on this, an independent, trusted, industry-wide clearing house could possibly be a preferred solution. However, legal concerns might preclude this scenario from being viable worldwide. In this instance, it might be preferable to have a key-based system that enables the IP manufactured on the SoC. In this post-manufacturing stage there are two options, authenticating during testing or during chip power up.

For example, to perform authentication on a tester, the IP provider would use a “test” pattern in the STAR Memory System that contains the IP enable key(s). This could be done permanently with e-fuses. During this step, microcodes could be configured to enforce a power-on authentication.

Authenticating on power up requires some non-volatile memory, such as Virage Logic’s NOVeA®. NOVeA has been used successfully for Digital Rights Management (DRM) by several customers and manufacturers. This fundamentally can solve the same problem. A license key can be stored and a mandatory power up sequence can be designed by the IP providers to use this convention.

The Ideal Ecosystem

The ideal ecosystem would be an honest world where every SoC designer and foundry would work together with IP providers and EDA vendors to report every IP transaction for license and royalties to be paid. Assuming that is not the current situation, we propose adopting the following:

Open Access + IEEE 1481 API-based design flows currently under development by a bi-lateral change committee.
Replace GDS with OASIS + encryption and security features.
Comprehensive specifications for encrypting and protecting algorithmic and high-level IP. This includes physical and functional watermarking.
Create an industry clearing house for all leading and emerging foundries to accurately collect, report, and merge IP prior to fabrication.
Creation of a standard minimum area IP licensing block. This hard IP would be required on all SoCs not fabricated at an in-house foundry. It would be responsible for verifying IP licenses and watermarks.
A common test standard for methodologies enabling IP on the tester.

There are many benefits to implementing these changes in the design and integration environment for increasing IP protection:

Creating flexible IP delivery models behind design implementation and modeling APIs.
Reusing standard license managers with these design APIs. (This is not possible with text based models.)
Obscuring watermarks and other IP protections by packaging them in a binary form behind the API.
Creating industry-wide trust through an independent third party that can aid in trend and market analysis.
Implementing post-manufacturing IP license verification and enablement to effectively eliminate piracy.

Conclusion

Finding the right balance of IP protection and design productivity will allow for bold new advances in IP development and delivery. When the value of IP is protected, investment and innovation are more viable and attractive. By using the three techniques defined, investments in the industry can be made more rapidly and innovation can continue to serve the SoC design community.