Tool Flows

Use Models – Guidelines for the parties –

  • Right to Parse/Read the encrypted Data Block is controlled by the Session Key.
  • Use and Output Rights are defined using Pragmas and explicit Licensing
  • Every Right that is not explicitly enabled is disabled
    • There are no implicit rights (the right to produce an implementation netlist does not imply the right to produce reports).
    • Tools SHALL provide the ability to report enabled rights
      • (Must this be enabled as a right?)

  • Rights are specified for and applied to
    • Activities (classes of tools)
    • Specific EDA Vendor tools
    • Specific Target outputs
  • Extensibility of Rights for Activities and EDA Vendor Tools is required
  • License definition to support shared library external licensing scheme (easily spoof able) as well as EDA tool licensing scheme. (more detail needed)

IP providers

  • Create IP
  • Decide what that they want to allow
  • Decide who they want to trust to ensure this
  • Obtain the public keys of the tool providers
    • The IP vendor has the responsibility to oversee key management and appropriate implementation of an appropriate trust model. It is out of the scope of this whitepaper recommendation to cover an appropriate set of trust models. It may be within the scope of the IEEE study group or work group

Tool providers

  • Support encryption specification and standard rights definitions
  • Provide public key to IP vendors
  • Optionally support extended rights in collaboration with IP vendor(s)

Tool and IP users

  • Obtain IP from vendor including a license if required
  • Verify that IP vendor supports the EDA Tools that will be used.
  • Install license if required

Encrypted IP Usage Scenarios

A standard encryption scheme must provide sufficient flexibility to support the different needs of multiple IP vendors. A description of intended use scenarios follows.

Evaluate the IP – Some IP providers desire the ability to safely distribute their IP to potential customers for evaluation without entering into a license agreement. In this use model, the consumer has the ability to evaluate the encrypted IP and obtain information about the IP such as area to implement or estimated performance, but does not have the ability to produce or obtain information required to implement the IP. In this case the IP vendor may enable a simulator to display waveforms and enable a synthesis tool to produce reports, but would not enable the synthesis tool to produce an implementation netlist.

Protect the RTL – Some IP providers desire the ability to encrypt the RTL description of the IP, but do not require encryption of the EDA Tool output files. For some providers, the post synthesis netlist is sufficiently obscured to provide the required level of protection of the IP and a clear text output file is acceptable. Other providers may require additional obfuscation of the output file. A feature of this model is that it provides some protection of the IP, but does not require that tools that follow in the design flow to be able to consume an encrypted file.

Protect the IP through synthesis – This flow requires that the IP is always encrypted. The RTL is encrypted and any tool that processes the IP produces encrypted output files that are then consumed by the next tool in the design flow.

Synthesis tools transform the design data and may produce output that is of a different format than the input (example - input Verilog => output EDIF or input VHDL => output Verilog). The synthesis tool produces output design data that although transformed, is encrypted using the same data key as was used to encrypt the input design data.

A standard mechanism for transferring Usage Rights from the input design description to the output design description is required. This will enable the tools that follow in the design flow to process the transformed design description that is produced by the synthesis tool. The preferred mechanism is one where the synthesis tool does not read, process, transform or write the Usage Rights for any other tool.

Abstract Flow model

We can model the flow abstractly as an iterative process of design refinement, where each iteration involves one or more of the following:

  1. Direct modification of the design
  2. Behavioral analysis
  3. Design attribute extraction and annotation
  4. Computed transformations of design topology
  5. Rendering the design for physical implementation
  6. System integration and validation

Questions to resolve

  1. What is the relationship between protected blocks.
  2. Do we understand the flow of data between tools that make up the flow.
    1. Consider SDF back-annotation
    2. Do we cover the flow through physical realization
  3. Where in the flow do the various forms of IP protection apply (encryption, obfuscation, etc)
  4. Tool classes that need to appear in the flow include:
    1. Read-only tools (simulation for example)
    2. Read/write tools that produce symbolic output (Synthesis)
    3. Read/write tools that produce/map to physical objects (FPGA bitstream, GDS/II files)

-- StevenDovich - 09 Jul 2008

Topic revision: r4 - 2010-04-19 - 13:43:29 - StevenDovich
 
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback