RE: IP Protection Draft

Hi Darren,

I will go ahead and update the draft to illustrate the use of the
rf_module.is_encrypted() method within the IP protection process. Since the
encryption process is compiler implementation-specific, I assume that this
method's implementation is similar, as its result depends on the compiler's
ability to decrypt the code.
In this case, the standard can focus on the significance of the result of
this method for IP protection purposes and leave the implementation details
to the compiler.

A new sub-section can therefore be included which will discuss the IP
protection features that a P1647 compiler needs to provide when
rf_module.is_encrypted()==TRUE. At this point, I assume that it is at least
used to restrict encrypted code access to the outside world (if that's the
case, I hope the user can not override this method). If anyone has in-depth
knowledge on how this method is used for IP protection, please let me know.

Furthermore, I will also clarify the requirement that an IP provider needs
to provide different versions of the IP for any given P1647 compiler
implementation. The draft already makes a strong statement to that effect in
page 1, lines 16-18 but a rewrite may be needed to remove any ambiguities.

Best Regards,

Iraklis.

-----Original Message-----
From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
Sent: Thursday, April 22, 2010 3:16 PM
To: iraklis@globetechsolutions.com
Cc: ieee1647@eda.org
Subject: RE: IP Protection Draft

Hi Iraklis,

I've been over the Mantis submission concerning IP protection, and I have
included the original information below:

"In section 30.3.4.1 (Reflection API -> Aspect Information -> Modules and
packages -> rf_module), sub-section f defines the method
rf_module.is_encrypted(), and states "Returns TRUE if the module is
encrypted. Otherwise, returns FALSE."

However, there is no other mention of encryption in the LRM, so how does the
rf_module struct know that the struct is encrypted? How is this information
stored? Thinking about it a bit more, how do we encrypt/decrypt a struct or
unit - none of this is covered in the spec. This would mean that 3rd party
IP which was encrypted currently wouldn't work with another e implementation
which followed the standard, as it wouldn't know how to handle it - does the
Amiq DVT implementation handle encrypted code? Encryption is mentioned in
the Verilog standard, so should it be mentioned in ours? Or should it be
removed entirely?"

The IP protection draft should at consider how the Reflection API gets and
stores the information about whether it is encrypted or not. It was earlier
thought (please go through the e-mail archive on the website to see the
discussions between Stylianos and others) that a given implementation of e
would use a given encryption, so an IP supplier would have to release
his/her IP encoded for multiple implementations - should this be mentioned
in the document, or can it be inferred?

You might need to talk to Matan to find out more about how this is currently
implemented.

Cheers,

Darren
 

-----Original Message-----
From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of
Iraklis Diamantidis
Sent: Monday, April 19, 2010 10:19 AM
To: ieee1647@eda.org
Subject: IP Protection Draft

Hi all,

I am attaching an updated version of the IP protection draft and would
appreciate your feedback.
After reviewing the P1647 material and Specman documentation, I believe that
the P1647 LRM does not provide any encryption specific language constructs,
as the 2005 Verilog LRM does. If that is indeed the case, any encryption
capabilities have to be implementation specific within a P1647
compiler/toolset, so they cannot be part of the standard.
With that in mind, I have decided to only include a typical IP
encryption/decryption flow in the IP protection document.

Also, I have modified the document to follow the "_D1.pdf" P1647 document
formatting as closely as possible.
Is there a document template available that I can use?

Best Regards,

Iraklis.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.