Protecting IP in a collaborative signoff environment

John Ferguson is the director of marketing for Calibre DRC applications at Mentor Graphics. John has worked extensively in the area of physical design verification for the manufacture of leading edge integrated circuits.

The idea of encrypting physical verification information has been around for some time. It emerged in the early, anxiety-filled days of design for manufacturing (DFM).

Engineers needed manufacturing process information to verify that designs were free from systematic yield limiters, but foundries were reluctant to distribute process information that could reveal best practices and trade secrets. Encryption enabled the protection of selected design rules, process data and other information while still giving customers the details they needed.

In this discussion, you must understand that the required protection is much more than just an obfuscation of rule definitions so they are no longer human readable. The process also includes the encryption of related files and control over all the outputs from the tool environment that provide information about any checks.

To illustrate, in the base case the Calibre verification platform is designed to provide virtually everything there is to know about design rules and how they interact with a layout. So to protect intellectual property, Calibre’s reports and displays must also be constrained to hide the information to be protected.

Today, the amount of collaboration required across designers, foundries, IP suppliers and EDA vendors to ensure successful designs at leading edge nodes has increased tremendously. This has created a need for more information sharing and more targeted protection schemes.

For example, design companies often create proprietary rules and data that they need to share with third^–party IP providers and other partners but shield from competitors. The supply chain stakeholders each need access to specific information to do their jobs, but want to protect their own critical information.

When the rules and data associated with design rule checks are ‘locked up’ it becomes all but impossible for anyone other than the owner to diagnose, debug or modify them. This does not work for the designers who need to debug violations, nor IP suppliers that need to understand the rules they are trying to pass.

Figure 1 is a simplified diagram of some stakeholders in the verification environment and some activities that require access to protected information. It helps show why a more sophisticated and flexible solution than simple text or file encryption is needed to manage information access across all users and use models. 

Figure 1. The collaborative signoff environment (Source: Mentor Graphics)

Various stakeholders’ sensitivity to exposing their data can vary greatly.  A vendor or foundry may want to hide unique rule syntax from non-licensed users who may intercept a rule file, but want that information to be accessible to licensed users. Or a foundry may want certain rules to be protected, but not care if variables and constants are revealed. 

To illustrate some of the inherent complexity of these protection requirements, consider that PV rule definition languages now have programming constructs like variables, constants, loops, macros and procedures. When portions of the rule definitions are hidden it becomes difficult to see how these elements interact and what all the dependencies are. Setting up a proper runtime environment and diagnosing errors can become all but impossible.

A standard practice for early protection schemes was to precompile rule files with any associated dependencies (include files, data files, etc.) to ensure that they would run successfully in the end-user’s environment.  But pre-compilation makes it difficult—sometimes impossible—to incrementally and collaboratively modify or add to existing rule decks because some of the bindings will change, leading to compile or runtime errors. If some of the structure and dependencies are hidden, the tool user cannot fix these problems. 

Another common scenario is when a rule deck is modified by several players in the supply chain. A foundry’s golden rule deck may be extended by one of its fabless customers to enforce a proprietary design style within the boundaries of the foundry’s requirements. The modified rule deck is then sent to an IP supplier for qualification of an IP library. The fabless customer wants the IP supplier to see output from, say, Calibre to help debug violations, but does not want to reveal the foundry’s proprietary data or its own proprietary rules. The protection scheme must honor several levels of protection, and ensure the IP suppliers see only what they need to in terms of the rule definitions and all the output provided by the Calibre run.

Providing such flexibility requires more robust rights management for physical verification—one that allows users to define what to protect, to specify multiple levels of access and visibility, and to easily manage access lists and associated encryption keys. It must be hierarchical, like traditional access privileges, so that stakeholders can add additional protections for their IP, but cannot remove protection from other stakeholder’s IP. Also, as new physical verification tools and syntaxes are created, the rights management mechanisms must be forward- and backward-compatible.

Given a flexible rights management methodology, it becomes simpler for multiple parties to pass and share physical verification rules without inadvertently exposing a partner’s IP. Collaboration between foundries, IP designers, ASIC design houses, EDA vendors and third party contractors becomes a smoother process, easing the concerns of IP and NDAs.