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.