IP Core Delivery Format Info

Hi Guys,

Hope one of you guys can help me out here. I have to supply a client a
IP core that we have developed but we don't want to give the VHDL
source. I have a few questions regarding delivery format. The core
will run on a Xilinx FPGA.

1) Would the NGC file out of the synthesizer be the most appropriate
delivery format?
2) How safe is NGC file (in regards to reverse-engineering)?
3) Can a NGC file synthesized for one device, say Spartan 3A DSP, be
used in a design that targets another device, say Virtex4?

4) The IP core port has few GENERICS to configure the core. It looks
like once the core has been synthesised (standalone) the generics are
fixed to the default values and the design that uses the IP core (as a
NGC file) is not able to change generics. ISE throws the following
warning:

Reading core <MA_FILTER.ngc>.
WARNING:Xst:1474 - Core <MA_FILTER> was not loaded for <MA_FILTER_1>
as one or more ports did not line up with component declaration.
Declared input port <DATA_IN<17>> was not found in the core.  Please
make sure that component declaration ports are consistent with the
core ports including direction and bus-naming conventions.

WARNING:Xst:616 - Invalid property "gAVG_LEN 8": Did not attach to
MA_FILTER_1.
WARNING:Xst:616 - Invalid property "gIN_LEN 18": Did not attach to
MA_FILTER_1.

How can the design that uses the core be able to pass in GENERICS?

5) The core uses a custom package and the design that uses the core
would also like to use the same package (there are few functions that
the toplevel design would like to use). How do you deliver the package
without giving the VHDL source?

6) The client would like to be able to simulate the core in their
design using Modelsim. What needs to be provided to allow this? A
search on google resulted in pre-compiled library but I couldn't find
anything on how to generate a pre-compiled library for a core. Is the
pre-compiled library the way to go?

Thanks in advance

Jason.

>Hi Guys,
>
>Hope one of you guys can help me out here. I have to supply a client a
>IP core that we have developed but we don't want to give the VHDL
>source. I have a few questions regarding delivery format. The core
>will run on a Xilinx FPGA.
>
>1) Would the NGC file out of the synthesizer be the most appropriate
>delivery format?
>2) How safe is NGC file (in regards to reverse-engineering)?
>3) Can a NGC file synthesized for one device, say Spartan 3A DSP, be
>used in a design that targets another device, say Virtex4?
>
>4) The IP core port has few GENERICS to configure the core. It looks
>like once the core has been synthesised (standalone) the generics are
>fixed to the default values and the design that uses the IP core (as a
>NGC file) is not able to change generics. ISE throws the following
>warning:
>
>Reading core <MA_FILTER.ngc>.
>WARNING:Xst:1474 - Core <MA_FILTER> was not loaded for <MA_FILTER_1>
>as one or more ports did not line up with component declaration.
>Declared input port <DATA_IN<17>> was not found in the core.  Please
>make sure that component declaration ports are consistent with the
>core ports including direction and bus-naming conventions.
>
>WARNING:Xst:616 - Invalid property "gAVG_LEN 8": Did not attach to
>MA_FILTER_1.
>WARNING:Xst:616 - Invalid property "gIN_LEN 18": Did not attach to
>MA_FILTER_1.
>
>How can the design that uses the core be able to pass in GENERICS?
>
>5) The core uses a custom package and the design that uses the core
>would also like to use the same package (there are few functions that
>the toplevel design would like to use). How do you deliver the package
>without giving the VHDL source?
>
>6) The client would like to be able to simulate the core in their
>design using Modelsim. What needs to be provided to allow this? A
>search on google resulted in pre-compiled library but I couldn't find
>anything on how to generate a pre-compiled library for a core. Is the
>pre-compiled library the way to go?
>
>Thanks in advance
>
>Jason.
>

I believe that most of the major simulators now support source file
encryption. So you could possibly encrypt the source file for simulation
and just give it to the client. This doesnt help you with regards to
synthesis. I did read somewhere that there is a new standard being releases
soon that will encrypt ip and enable it to be synthesised. I think the best
you can hope for at the moment is to create a netlist for the target
device.

Jon 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Actually XST supports encrypted sources.  PLDA
delivers their "EZ-DMA" core as an encrypted
source.  This allows users to customize
the core.  I'd be very surprised if the major
third-party synthesis tools didn't also
allow encrypted sources.

-- Gabor

Gabor <gabor@alacron.com> wrote:

> Actually XST supports encrypted sources.  PLDA
> delivers their "EZ-DMA" core as an encrypted
> source.  This allows users to customize
> the core.  I'd be very surprised if the major
> third-party synthesis tools didn't also
> allow encrypted sources.

But if XST can decrypt it, then why can't someone else,
if they find the decryption key?  

The question, then, is how valuable is the IP?
How hard do you need to make it to reverse engineer?

There is always the obfuscator, that replaces all the symbolic
(and maybe human readable) names with random symbols, often
made of 0, 1, O, I, and maybe l.  Presumably also removing
any comments that were in there.

-- glen

-- glen

> I believe that most of the major simulators now support source file
> encryption. So you could possibly encrypt the source file for simulation
> and just give it to the client. This doesnt help you with regards to
> synthesis. I did read somewhere that there is a new standard being 
> releases
> soon that will encrypt ip and enable it to be synthesised. I think the 
> best
> you can hope for at the moment is to create a netlist for the target
> device.
>
> Jon

Some of the IP cores can be easily decrypted. I am talking not about a 
particular cores, but particular vendor. In this case, many cores are 
encrypted with the same algorithm, so it is possible to decrypt them too. If 
this core is expensive - think about a good way of encryption. However, 
there was an issue, when a vendor asked 75k USD for a core and engineers 
made the core by themselves in 2 weeks. 

On Sunday, March 6, 2011 4:24:38 AM UTC-5, glen herrmannsfeldt wrote:
> Gabor <ga...@alacron.com> wrote:
> 
> > Actually XST supports encrypted sources.  PLDA
> > delivers their "EZ-DMA" core as an encrypted
> > source.  This allows users to customize
> > the core.  I'd be very surprised if the major
> > third-party synthesis tools didn't also
> > allow encrypted sources.
> 
> But if XST can decrypt it, then why can't someone else,
> if they find the decryption key?  
> 
XST uses license manager to do the decryption.  The
key is not made public.  So someone else would need
to also have the same node ID for a node locked
license as well as the decryption license file.
This is no better and no worse than the license
control for most software products.

-- Gabor
> 
> -- glen
> 
> -- glen

Gabor <gabor@alacron.com> wrote:
> On Sunday, March 6, 2011 4:24:38 AM UTC-5, glen herrmannsfeldt wrote:
>> Gabor <ga...@alacron.com> wrote:
>> 
>>> Actually XST supports encrypted sources.  PLDA
>>> delivers their "EZ-DMA" core as an encrypted
>>> source.  This allows users to customize
>>> the core.  I'd be very surprised if the major
>>> third-party synthesis tools didn't also
>>> allow encrypted sources.
>> 
>> But if XST can decrypt it, then why can't someone else,
>> if they find the decryption key?  
>> 
> XST uses license manager to do the decryption.  The
> key is not made public.  So someone else would need
> to also have the same node ID for a node locked
> license as well as the decryption license file.
> This is no better and no worse than the license
> control for most software products.
> 
> -- Gabor
>> 
>> -- glen
>> 
>> -- glen
Yes, these are somewhat trivial to circumvent. 

Also, obfuscation != security.

Forget about that obfuscation snake oil (decrypting Modelsim-compatible enc=
rypted models and messing with Xst's NGC files isn't even hard) and DRM-lik=
e "protections" that create more problems than they solve. The only true wa=
y you can enforce your IP licenses is by having a tool that automatically t=
ells you if some binary bitstream uses your code so you can catch and sue p=
eople who violate your license.

Something akin to http://arstechnica.com/open-source/news/2010/04/tool-snif=
fs-oss-binaries-for-sweet-smell-of-license-compliance.ars would be perfect.=
 Who wants to develop that?

S.

PS: Please no whining about the proprietary FPGA bitstream format: it can, =
and has been, reverse engineered. By whining about that you will only show =
your incompetence and laziness. And I never said that developing such a too=
l would be easy, both technically and legally-wise.

Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote:
> Forget about that obfuscation snake oil (decrypting Modelsim-compatible
> encrypted models and messing with Xst's NGC files isn't even hard) and
> DRM-like "protections" that create more problems than they solve. The
> only true way you can enforce your IP licenses is by having a tool that
> automatically tells you if some binary bitstream uses your code so you
> can catch and sue people who violate your license.
> 
> Something akin to
> http://arstechnica.com/open-source/news/2010/04/tool-sniffs-oss-binaries-for-sweet-smell-of-license-compliance.ars
> would be perfect. Who wants to develop that?
> 
> S.
> 
> PS: Please no whining about the proprietary FPGA bitstream format: it
> can, and has been, reverse engineered. By whining about that you will
> only show your incompetence and laziness. And I never said that
> developing such a tool would be easy, both technically and legally-wise.
Could you provide a source for the complete reverse engineer (bitstream to
source/netlist) of a bitstream. I'd like to read about it.

http://www.ulogic.org
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdf