Today's extremely large and complex ASIC and FPGA designs use significant amounts of third-party intellectual property, in the form of general-purpose processor cores, digital signal processor cores, memory controllers, communications functions and so on. Furthermore, this third-party IP, which may account for a large proportion of the overall design, often originates from a number of IP vendors.

Due to the fact that each IP block represents a considerable amount of time and investment, it's no surprise that the IP vendors wish to guard their secrets. The way to do so is to encrypt the source. The problem is that right now there is no standard for encryption and decryption in electronic design flows that facilitates industrywide interoperability. Different IP vendors and

EDA vendors have used a variety of proprietary schemes, resulting in a huge support burden on the various organizations. Also, this practice is confusing to the end user and can result in a lack of consistency (simulating one version of the IP block and synthesizing a different version, for example).

To address this issue, the scientists and engineers at Synplicity have invented and implemented an open IP encryption environment that will facilitate the use of protected IP throughout the design flow: from IP vendor to EDA vendor to silicon vendor.

The advantages of Synplicity's proposed hybrid symmetric/asymmetric encryption/decryption technique are manifold. For starters, the IP vendor need create only a single version of the encrypted data, which is supplied to all interested parties. This ensures consistency, because it guarantees that the same IP will be used by all of the downstream tools. Moreover, fast symmetric encryption can be used for the large data blocks, while slower, more compute-intensive asymmetric algorithms are applied only to the small data keys.

But the key advantages to this scheme are that it is open, it leverages existing technologies and it fully addresses the needs of modern electronic-design environments. It facilitates industrywide interoperability, is applicable to both ASIC and FPGA design flows, and would be easy for IP, EDA and silicon/FPGA vendors to adopt.

Synplicity proposes that these techniques should be formally endorsed by industry leaders and placed under the auspices of the appropriate standards bodies.

Before examining the various encryption/decryption options in detail, it's important to understand where these activities occur in the design flow. As an example, let's consider the encryption and decryption activities with regard to the synthesis component of an FPGA flow.

The IP block, whose function is typically captured as a register-transfer-level (RTL) representation, is originally encrypted by the third-party IP vendor. This encrypted block is subsequently passed to the customer's design team, which will typically combine it with other IP blocks and with its own custom-generated RTL to create a representation of the entire design. The team will then use synthesis tools from an EDA vendor to translate this design into a gate-level netlist. Later, they will use the place-and-route tools provided by the FPGA vendor to generate the configuration bit stream that will ultimately be used to configure (program) the FPGA.

It may be necessary for the encrypted IP block to be used by multiple EDA tools--such as synthesis and simulation--which are often supplied by different vendors.

In the case of synthesis, the IP block is first decrypted and then synthesized, along with any unprotected portions of the design. In many cases, the ensuing netlist--or at least the portions of the netlist representing the protected IP functions--will be re-encrypted before being fed forward to the FPGA vendor's tools.

It is important to note that all decryption, data manipulation and encryption activities take place inside the synthesis application itself; the unencrypted IP is never accessible by the user. The encrypted files are decrypted in memory only (no disk storage), and the decryption is performed on small blocks so as to thwart hacking via memory dump techniques.

Following synthesis, the encrypted netlist is passed to the FPGA vendor's tools. Once again, any protected portions of the netlist are first decrypted before being processed by the place-and-route engines. The final step is the encryption of the bit stream generated by the silicon vendor's place-and-route application. In this case, the place-and-route tool may encrypt either the entire bit stream or only those portions of the bit stream representing the protected IP. This step falls under the responsibility of the FPGA vendor's tools; it is a function of the underlying FPGA architecture.

An ASIC design flow is very similar to the FPGA flow. The ASIC flow will, however, include many verification steps that are not present in the FPGA flow; each of these steps will require the use of an EDA tool, and each of these tools may come from a different EDA vendor. Furthermore, in the case of an ASIC flow, the output from the place-and-route engines will be the GDSII files that are used to create the photomasks, which are in turn used to fabricate the device. These files are typically not encrypted at the present time, but the methodology Synplicity is proposing could easily be applied to this content too.

There are two major classes of encryption/decryption algorithms, which may be classed as symmetric and asymmetric. In the case of symmetric, the encryption algorithm uses a special number known as the key. The value of this key modifies the detailed operation of the algorithm--that is, the way the contents of the original file will be "scrambled." This means that if the same file is encrypted using two different keys, the results will be totally dissimilar. To open the encrypted file and access its data, the end user also requires access to an appropriate key.

Speed advantage
The advantage of this technique is speed, due to its relatively low computational requirements. Encrypting even a large file using a symmetric algorithm takes only seconds, and the time taken to decrypt the file when it is accessed by an application such as synthesis is imperceptible by the user. Examples of this type of algorithm are the Data Encryption Standard, Triple DES and the more sophisticated Advanced Encryption Standard (AES), which was adopted in 2001.

The Achilles' heel of symmetric encryption is the need to communicate the key. The situation is further confused by the fact that there are so many IP and EDA vendors. Although actual numbers are difficult to pin down, there are probably 300 to 500 significant IP vendors in the world distributing anywhere from 25,000 to 30,000 different IP blocks (of these, approximately two-thirds are digital, while a third are analog and mixed-signal).

If each IP vendor used only a single key, then in the event that key were leaked or cracked, all of the IP from that vendor would be compromised. Thus, in order to maximize security, each IP vendor is obliged to associate a unique key with each EDA vendor. Similarly, each EDA vendor needs to associate a unique key with each silicon/FPGA vendor. The end result is a morass of confusion.

Furthermore, if the IP vendor decides to change a key and reissue that IP, users will have to wait until the next release of the EDA application (which has the keys from the various IP and silicon/FPGA vendors embedded inside it) is in production.