Re: IP Protection Draft

Hi Darren,

   DVT just skips encrypted files. The following points reflect our view of
the encrypted world.

   1) On "An IP supplier would have to release his/her IP encoded for multiple
implementations"
   I guess this is the only way to go. Unfortunatelly it won't be practical
and I am not sure IP providers will bother.

   2) On reflection vs. encryption
   I am not sure if encrypted API should be visible via reflection. For
example one may say that encrypted method declarations, fields etc. are part
of the IP and should not be visible through the reflection API as it is a
mean to bypass the whole idea of protecting encrypted content.

   3) One path we considered for DVT needs
   For 3rd party IP handling and protection, ideally encrypted packages should
have a set of "header" files which declare at least the API. For example:
   
--- ahb_api_h.e
struct ahb_transfer {
   // field declarations
   // event declarations
   // method/tcm declarations
   m() is undefined;
   ...
   // default constraints?
};

---
   The only notable and dramatic exception is for "define as" and "define as 
computed" which don't have a "is undefined" aspect like most other 
constructs. And they are used in most eVCs. And they are encrypted in most 
eVCs. And even with aspects, things won't work, as we cannot reparse 
such "define as" constructs.
Some rough ideas, Cristian
On Thursday 22 April 2010 03:16:18 pm darren.galpin@infineon.com wrote:
> 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.