Methodology for protection and Licensing of HDL IP

by Tarun Batra, Cadence Design Systems, Inc.
Noida, India
   
Abstract

HDL Intellectual Property commerce depends mainly on two factors: protection of investment and flexibility of usage. These two are diverse factors; the higher is the protection, the lower is the flexibility to use or debug the IP in the user environment. Therefore, IP authors intending to protect their investments would prefer some effective mechanisms of protecting their IPs, which are flexible enough for wide adoption and are reliable at the same time.
In this paper, we introduce a methodology for protection of HDL Intellectual Property, which enables platform independent protection, seamless integration of IP in all kinds of HDL designs, compatibility of the solution across the verification flow and multiple-level licensing mechanism for debuggability and controllability. We focus on HDL IPs, which are HDL Designs (Soft IPs’) and are primarily used for RTL design/ verification flow.

INTRODUCTION

The increasing complexity of the SOC designs and the strict Time to Market are the main driver for the emergence of IP re-use phenomenon. Design engineers are compelled to re-use existing design blocks in creating extremely large and complex systems in the given short time [1]. Also, the perils of reinventing the wheel drives the designers to make re-usable blocks in the first place and then use them in their system designs incrementally over various product releases to the market. Such re-usable blocks can either be taken from internal design libraries or be purchased from third party vendors.

While trading such IPs’, the IP providers have to strike the right balance between two fundamental aspects of their product: flexibility or debuggability of the IP and the protection of their investments. It
is a tradeoff between these two concerns. If an IP has to be flexible, it must be appropriately accessible to a user to verify the correctness and quality (in terms of area, speed, power and testability), but it seriously compromises the protection and the intellectual investment of the IP provider. On the other hand, if the protection is so strict that required debuggability is not available with the IP, then the IP is hardly useful in a development environment & the user will be reluctant in using such IPs.

The legal aspects of IP protection are discussed in [2,3]. Here, the author talks about the importance of selection of an IP protection technique, which would preserve the investment appropriately.

A conventional IP protection technique is watermarking [4], which was originally used to protect a country’s currency from being counterfeited. In the digital world embedding a digital signature into the IP components serves to protect the digital IP. Since the digital signature cannot be removed from the IP, it is easy to prove an illegal use of such a component in litigation. However, the fact that this technique does not hide the actual intellectual property and only serves to protect the interest of the IP provider in case of illegal instantiations, stands as its biggest limitation.

The other alternative, particularly used for protecting HDL IPs, is based on Model Encryption technique [5]. In this case, the provider releases an accurate simulation model to the user, protecting their intellectual property at the same time by encrypting it (usually by text obfuscation). The packaged/encrypted simulation model can then be instantiated and simulated in the user’s design environment. However, since the encrypted model is provided to the model consumer as a pre-compiled object file to be linked to the simulator, the object model is not portable. This technique leads to limited flexibility of the packaged IP in terms of debuggability and controllability. Simulation performance degradation is another big penalty for this solution.

In this paper, we introduce a cryptography-based methodology for protection of HDL Intellectual Property. The proposed technique enables:

 

 

1. Platform independent, tool independent, simple yet reliable protection.
2. Flexible/seamless integration of IPs in all kinds of HDL designs.
3. Multiple-level encryption mechanism for debuggability and controllability.
4. Standardization of the scheme to support the protection across the design & verification Flow tools.

PREVIOUS WORK

Cadence’s existing IP Model Packager (AMP) [5] is a typical example of  the traditional protection solution, which has been used by its customers for over a decade. The IP Model Packager exports a Verilog or VHDL model in a protected form that is suitable for integration into standard HDL simulation environments. The input to the packager is a pre-compiled model using NC Verilog, VHDL, or mixed-language design library, or a model written in C and/or C++. The output of the packager is a tar file containing a set of binary model data, a model installation utility, and a set of software integration components for simulating the model. The model gets connected to the simulator using the IEEE-1499 Open-Model-Interface(OMI) standard [6]
 

Fig1:  Amp Model Flow

A packaged model is delivered as a binary data file. The model packaging process exposes only the boundary objects, such as ports and viewports, which have been specified by the model creator. The Model Packager also hides design hierarchy information that would otherwise be displayed in timing warning or error messages. The drawbacks in this technique as mentioned in the previous section are:

 

 

 

1. Models are not portable across different target architectures. This is an over burden on the IP provider that he/she has to create the object files of the same IP for different target architecture for different customers.
2. Flexibility for debugging is not very high. Due to lack of debugging capabilities of the IP, the consumer has to trust on the correctness of the IP.
3. Emulation/ Hardware prototyping based verification Flow cannot work with these models.

The other protection capability that Cadence provides is based on text obfuscation by encryption. A ‘protect directive is used to encrypt the Verilog HDL file with Verilog-XL. This encrypted file is shipped to the IP user and it is decrypted and used in the design environment during simulation with Verilog-XL. However, a big limitation here is that this is limited to pure Verilog designs. Some other EDA vendors also provide a capability similar to Verilog-XL, where the protected HDL code is made invisible to a user.

CRYTOGRAPHY BASED IP PROTECTION

The Protection mechanism proposed by us here is based on the RSA  cryptography based IP Protection. The biggest advantage of using cryptography-based encryption is the fact that, since the encryption techniques are algorithmic, encryption and decryption are machine architecture independent. This feature obviates the generation and shipment of protected design files for different target architectures for different consumers of the same IP.
The usage of the industry standard RSA [7] encryption methodology builds in the confidence in the IP community over the strength of the protection.
 

Fig2: Cryptography based IP protection Flow

The standard encryption algorithms are available in the RSA libraries [7], in 2(a), the IP author protects the IP using an encryption algorithm and a key (or keys), thereby working at a higher abstract level. In 2(b), various IP Users, consume the same encrypted design file.

This protection mechanism also incorporates the Pragma based  Licensing and control of the accessibility of the IP by the IP author. This mechanism is explained in details in Sec 4.2

The EDA tools regenerate the original IP and perform the requisite operation. It is extremely important to make sure that the form in which the HDL source is regenerated continues to protect the interest of the IP author. This is discussed in the next section where we scope ourselves down to IP Protection from Cadence.

EDA TOOL IP PROTECTION

In this section, we shall describe the IP protection flow and compare it with the existing methodologies. The presentation will delve in detail about the NCSimTM  implementation of this solution.

The complete flow

Referring to figure 3, the flow described in 3(a) is at the IP author end, where the HDL source of the created IP is protected with the help of the protection tool, ncprotect. The ncprotect tool, basically, performs textual encryption, given the encryption algorithm and the encryption keys. Since the standard RSA libraries are used by ncprotect, various algorithms like RSA, RC2, RC4, AES, DSA can be opted for. The tool ncprotect is ported on various 32 and 64 bit platforms like, HP, Linux, IBM, Solaris, windows etc. Therefore, it becomes extremely convenient for various IP developers to use it.


Fig3: IP Protection Verification Flow

The flow diagram depicted in 3(b) is that of flow at the IP consumer end. The IP is typically used as a part of some system or design environment like an SOC as an instantiated component. This whole system, when read by simulation (ncsimTM) tools, is dumped as design units readable only by the various Cadence Verification tools.

Here, as before, the decryption license is required to take care of the legal issues and the decryption algorithm and the relevant keys are required to perform the decryption. This enables the dynamic verification of the system design with the help of simulation and even provides debugging capability with the aid of various C interfaces (VPI, VHPI), TCL interfaces. However, the extent of information that could be extracted for the protected IP component using these interfaces and the utilities is completely dependent on the level of protection induced in the protected IP at the first place.

The salient feature here is that the IP author decides the level of debuggability (permission to reveal to the simulator) they intend to provide for their IP.

Going back to the question on the security aspect mentioned in the last section, this protection technique mentioned above makes sure that the source code of the protect IP cannot be reproduced using reverse engineering (decompilation, in this case).

Some additional security features are: “Asymmetric keys” based encryption that not only the key management burden but also provides an extra protection. Usage of the “Digital Signatures” to ensure that the protected IP is rendered unusable if pilfered by the users.

Controlling the level of protection and the flexibility with protection

Controlling the level of protection of an Intellectual Property is of prime importance because of the nature of tradeoff described in « Introduction » section.

If the IP is a relatively well-tested IP or highly confidential, the IP author might chose to protect it completely and not even provide the IP consumer with anything more than just the regulation test jigs or probes. On the other hand, if the IP is a newly developed one or meant for internal customers or has not been thoroughly tested in various development environments, the IP developers might chose to give more debuggability of the IP.

The extent of protection of the source code (in fig 3(a)), which, in turn, translates into the level of debuggability for a protected IP, can be controlled using protection pragmas. Protection pragmas are pragma directives (markers), that are inserted into the HDL designs to be read by the encryption and the decryption tools. These are similar to synthesis pragmas in an RTL design, which indicate the synthesis tool to pick up specific architectural functional components for logic blocks. The protection pragma specifications provide the encryption and decryption tools with parameters like, the areas of the code to be protected, the encryption/decryption algorithm to by used, the keys to be used for encryption and decryption and even the licenses to be used, incase the protection is supposed to be licensed and time-bound ( the IP would have an 'expiration event').

The scheme is expandable and lots of other controls deemed required for the IP commerce can be incorporated.

 
Fig4: Flexibility with protection

Figure 4(a) describes the controllability of protection with the help of protection pragma specifications. (1) demonstrates the case where only specific blocks within an architecture body of a VHDL design is protected, thus giving more debug and probing options (through the interfaces mentioned in section 3) to the internal signals of the design. On the other hand, (2) encrypts the complete architecture, not allowing any probing options on the internal signals.

Figure 4(b) shows that the same pragma specifications file (containing the specification of various algorithms and keys) can be used to encrypt multiple IPs and facilitate the packaging and shipment of the IPs to their consumers. Figure 4(c) shows the multiple level of encryption, the technical model for which will enable selective usage of various features of a multi-featured IP based on the keys that are available at the consumer end. In this case, block3 is encrypted using key3, block 2 and encrypted block 3 using key2 and block1 and the rest encrypted blocks using key1. So, a user who’s bought the complete functionality of the IP will be provided all the three keys. But a user who is just interested in the block1 for his design development requirement need not pay for the complete investment of the IP developer. Figure 4 (d) shows the capability of protecting the IP source code with multiple algorithms and keys at the IP author end. This protected IP can then be shipped to the consumer who can use this protected IP even if he/she has a single of the algorithm and key pairs.

This provides the IP author with the flexibility of avoiding the creation of separate encrypted files and shipping them to separate customers who have their own keys (specially incase of private and public key cryptography, where the public key is known but he private key is known only to the IP consumer).

Support by other tools in Verification Flow

Since SOC Verification requires not just simulation but lots of other EDA tools to work in a flow to complete the verification the solution should be expandable to the other tools (across vendors) too. This methodology is extremely flexible for all these accounts. An SOC uses various IP from multiple IP vendors and they may be in various descriptions like C models, VHDL, Verilog and even SystemC. Therefore, this protection methodology provides seamless integration of protected IPs in such systems. The protection solution is expandable so that the linting, Emulation and even the TestBenching tools can work in tandem with these protected IPs without compromising the authors investments.
Cadence is committed to extend the support for this methodology to all Verification tools offered under the Incisive platform

The protection pragma format specification has been  donated to Accellera HDL working groups (IEEE). This is expected to bring about a level of standardization in the area of HDL IP protection and allow the users to even use the across the board vendors for their verifications. This will be followed by protected components support by synthesis tool & Design layout Flows.

LICENSING OF IP

Licensing of the IP is an essential component of this Methodology. There is a provision for the IP developer to ship license strings along with the IPs and the keys to the IP users. The IP users will be able to simulate the protected IP successfully at their end only if the license string is available to the EDA tool. This is not a greate achievement because it can be easily accomplished with even an elimentary PLI plugin.

However, this alone is not enough to catalyze the IP commerce activities. We need more dimensions to the Licensing of the IP:

 

 

 

1. Multiple levels of IP license: Capability to allow debuggability control on the License.
2. License Limits: Providing a capability to allow a license to lapse after a duration or after a stipulated sessions.
3. Verification Flow control: This will allow an IP to be used across the complete ASIC flow for different tools. A license will allow an IP for simulation session but another may allow for both both simulation and emulation or synthesis.

There are lots of other such dimensions. While with ncprotect, Cadence has provided some of the above capabilities. There is still a lot of scope.

CUSTOMER ADOPTIONS

The real strength of a solution lies in it’s adoption. For ncprotect  some FPGA and ASIC design houses have started using the solution. They are heavily using the solution primarily because of its platform independence, RSA based encryption and flexible debuggability feature.
It is projected that once the pragma format specification is accepted by IEEE, more and more IP developers and users will move towards adopting this methodology.

CONCLUSIONS AND FUTURE WORK

In this paper we have introduced an HDL IP protection methodology, which is cryptography-based and scores over the existing methodologies in the following areas:

 

 

 

1. The IP industry needs a standard and reliable encryption solution.
2. Platform independent, tool independent, simple yet reliable protection.
3. Flexible/seamless integration of IPs in all kinds of HDL designs.
4. Multiple-level encryption mechanism for debuggability and controllability.
5. Extension of the Methodology to complete design and verification Flow.
6. The use model and the implementation for the Licensing is an area that needs to be worked on critically; this will be the most revolutionary step for accelerating the growth of the IP Commerce.

REFERENCES

[1]    D. Gajski, “IP-based design methodology”, Proceedings of the 36th Design Automation Conference, 1999.

[2]    Donner I.H, “Intellectual property protection: everything you've always wanted to know”, Computer Volume: 27  Issue: 10  Oct 1994

[3]    Irah H. Donner, “Will your IP protection provide the protection you expect”, IEEE Transactions on CAD, July 1996.

[4]    A. Kahng, et al., “Watermarking techniques for intellectual property protection”, Proceedings of the 35th Design Automation Conference, 1998.

[5]     “Cadence IP Model Packager Guide for Model Creators”, Product Documentation, Version 5.3

[6]    “IEEE standard interface for hardware description models of electronic components”: IEEE Std 1499-1998

[7]    http://www.rsa.com

[8]    Saverio Fazzari, “A Process for IP Protection” , DesignCon-2005