This page introduces several topics related to the work in P1735-2012. These are candidate areas for future work under a future PAR. The working group's assessment is that omitting them from the current work is best to get the more urgent and important issues ratified in a timely manner.

Additional common rights

Arriving at consensus for a common right - the name, possible values, and meaning of each - is a significant task. It is expected that the current version of P1735 will contain one common right for visibility. Future work may include definining additional common rights such as activity (simulation, synthesis, etc.).

Compiler directives

The precise meaning of encryption/protection of code that is separate from a module or entity is not defined in the current P1735. Future work may include specific rules that apply to protection of functions, macros, include files, etc.

Key management enhancements

The current P1735 assumes that IP authors have access to public keys of EDA tools that they wish to authorize, and that there is a trusted means for the IP author to acquire the keys. No policies are adopted on how long a key should live and how an IP author should acquire a new key. In addition, one class of tools creates IP in the field, where key access and encryption need to occur "in the wild".


Verilog and VHDL are supported by the current P1735. other formats including SDF and SDC would benefit from official support in order to consistently hide information that the IP author considers proprietary. Higher level languages such as System-C are also candidates.

IP protection

If a public key is easy to access, it is possible for a malicious party to create IP that is of low quality or outright malicious, and misrepresent this product. Being encrypted, it can be difficult for a user to inspect and verify the source and authenticity of the IP. A standard means to digitally sign the IP would greatly improve confidence.

Some IP suppliers may not be able to do full verification of their digital envelopes are are susceptible to counterfeit public keys finding their way into the process. Such keys could match a malicious decryptor resulting in theft of the IP. A standard means to digitally sign the public key would greatly improve confidence.

Hackers may have tools and techniques that could result in IP overuse if cracking licensing or IP theft if cracking EDA applications. Best practices for piracy prevention and detection may add significant value to future P1735 work. Techniques that hide private keys in applications and license proxies are included in this topic.


Tagging and/or watermarking IP with support in P1735 and the EDA tools that read and write the IP, could contribute to validation of trusted sources and pursuing infractions.

-- DaveGraubart - 2012-05-08

Topic revision: r1 - 2012-05-08 - 20:25:30 - DaveGraubart
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback