IP Core Delivery Format Info

[Jason Luska]

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.

 

[maxascent]

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 fil
encryption. So you could possibly encrypt the source file for simulatio
and just give it to the client. This doesnt help you with regards t
synthesis. I did read somewhere that there is a new standard being release
soon that will encrypt ip and enable it to be synthesised. I think the bes
you can hope for at the moment is to create a netlist for the targe
device.

Jon

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

 

[Gabor]

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

 

[scrts]

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.

 

[glen herrmannsfeldt]

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

 

[Gabor]

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

 

[jay]

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.

 

[Sebastien Bourdeauducq]

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.

 

[jay]

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.

 

[Sebastien Bourdeauducq]

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

 

[jay]

Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote:

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

I've read that. It's only a partial reversal, and is outdated due to
current bitstream encryption methods.

 

[Sebastien Bourdeauducq]

Maybe the Ulogic implementation lacks a few features, but I can't see any obstacle to implement them using the proposed methods.

Are you talking about the battery-backed SRAM holding the encryption key? I have not seen any consumer device using this, and I also do not know how strong this protection is for someone armed with strong knowledge of FPGA internals and bitstream format.

For example, readback of the cleartext of an encrypted bitstream is allowed through the ICAP on Spartan-6. Now, you can't partially reconfigure an encrypted FPGA to gain access to the ICAP, but what about inserting the malicious logic while the FPGA reads its encrypted bitstream? Normally CBC would prevent that, but perhaps this could be in turn circumvented by unexpected modifications of the on-chip configuration system's frame address register during the transfer of the encrypted data. That's something that needs some research I think, before blindly believing in the promises of the FPGA companies.

 

[Mark Curry]

In article <ikvjsl$41r$3@news.eternal-september.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

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.

I've often wondered what I'd do in the OP's position. I'd think
I'd just supply the source. It's just not worth the trouble,
and all those darned protection methods are a PITA for you, waste your
resources (time) on throw-away work, and pisses the customer off.

Maybe if you didn't have the GENERICS issue - supply just a synthesized
netlist, and an NGC. But the GENERICS screw this route.

At the very most, I'd use an obfuscator as Glen suggested. Here,
it still works plain and simple, and the customer could debug
things - it's not much worse than debugging
netlists that have been hammered by a synthesis engine. But not many
people are going to go through too much trouble to reverse engineer the obfuscation.

--Mark

 

[Jason Luska]

On Mar 8, 12:37 pm, gtw...@sonic.net (Mark Curry) wrote:

In article <ikvjsl$41...@news.eternal-september.org>,
glen herrmannsfeldt  <g...@ugcs.caltech.edu> wrote:

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.

I've often wondered what I'd do in the OP's position.  I'd think
I'd just supply the source.  It's just not worth the trouble,
and all those darned protection methods are a PITA for you, waste your
resources (time) on throw-away work, and pisses the customer off.  

Maybe if you didn't have the GENERICS issue - supply just a synthesized
netlist, and an NGC.  But the GENERICS screw this route.

At the very most, I'd use an obfuscator as Glen suggested.  Here,
it still works plain and simple, and the customer could debug
things - it's not much worse than debugging
netlists that have been hammered by a synthesis engine.  But not many
people are going to go through too much trouble to reverse engineer the obfuscation.

--Mark

Hey Guys,

Thanks for all your replies. Its amazing there seems be no standard/
safe way of IP delivery (if you don't want to supply source)!

Cheers
Jason

 

[Nial Stewart]

But not many
people are going to go through too much trouble to reverse engineer the obfuscation.

But why would they bother if the source works?

They can just use the obfuscated module wherever they want.


Nial.

 

[maxascent]

It seems to me that obfustication is only really worthwhile if you want t
try and stop someone finding out how your ip works. It will not stop anyon
from actually using the ip which is surely what most people would want.

Jon

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

 

[Nial Stewart]

"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote in message
news:IaidneHsCrW-w-vQnZ2dnUVZ_s6dnZ2d@giganews.com...

It seems to me that obfustication is only really worthwhile if you want to
try and stop someone finding out how your ip works. It will not stop anyone
from actually using the ip which is surely what most people would want.
Jon

Exactly.


Nial.

 

[luudee]

On Mar 5, 5:36 pm, Jason Luska <jasonlu...@gmail.com> wrote:

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.

Jason,

there is no true security. Regardless of what you deliver.

The questions you have to ask yourself is how motivated is your
client in reverse engineering the IP Core ?

Typically, if you are clever enough to reverse engineer an IP Core,
you might as well write it yourself. If the IP Core is rather trivial
and
small it will be easy to reverse engineer it and get pretty close to
the
original source code. The more complex an IP Core is, the harder it
is to reverse engineer it and make sense out what you get.

The IP Core Source Code is typically only 1/4 of the value of an IP
Core. Other parts are Test Bench, Documentation, Certification and
3rd party hardware validation, and most of all tech support.

Good Luck,
rudi