What are some ways we can protect our Verilog source, given that
whatever we do, the final verilog code needs to run in the
customer's environment?
We use Verilog-XL/NCverilog, and I have read about the
"`protect/`endprotect" directives. I heard this was cracked
a long time ago, but Cadence's FAQ claims they revised the
encryption code and that it's now more secure than ever before!
And ideas are welcome!
iutroutroi wrote:
Just stick to your guns and insist on the potential customer signing the
NDA first. Its totally standard for evaluations and, if it were me, I'd
want to hear exceptionally good reasons before giving way.
If you really can't win on that one then why not supply a flattened
post-synthesis netlist where all the wire/reg/instantiation names have
been changed to random values. the target technology would have to be
one where the simulation primitive libraries are available to your
potential customer e.g. some FPGA family.
Not sure about the lastest Verilog protection, but I'd be wary (assume
it's crackable if they try hard enough) if they refuse to sign an NDA.
Paul
Here is what I found:
To protect the source description of selected modules or regions,
follow these steps:
Place two compiler directives in the source description to define the
protected region: `protect marks the beginning of the protected
region;
`endprotect marks the end of the protected region.
Compile the Verilog-XL source description file with the command-line
option +protect.
Compilation creates a new source file in which the regions marked for
protection
become unreadable. This protected source file does not overwrite the
original,
unprotected source file.
Note: Whether you protect the source of an entire module or only
selected regions
inside that module, Verilog-XL considers the entire the module to be
protected.
Paul <n...@psam.here> wrote in message news:<3CE6C934...@psam.here>...
Yes, I read the same Cadence document before posting. I've
heard rumors that this feature cryptographically very weak. I'm
not looking for ultra-secure encryption -- I just want to keep
honest customers honest.
Originally, I heard the +protect could be broken triviallly with
a PERL script, in which case the encryption has no protection value
whatsoever. I'd like to the strength of the *current*
Verilog-XL/NC-Verilog +protect implementation. I
> What are some ways we can protect our Verilog source, given that
> whatever we do, the final verilog code needs to run in the
> customer's environment?
>
> We use Verilog-XL/NCverilog, and I have read about the
> "`protect/`endprotect" directives. I heard this was cracked
> a long time ago, but Cadence's FAQ claims they revised the
> encryption code and that it's now more secure than ever before!
I don't know about this revised encryption mode, but there was a perl
script or similar which was available for download some time ago to
crack the old encryption code.
I've used VMC (from Chronologic, but they have been purchased by
Synopsys) to compile the verilog code into object code (for SPARC in
my case) and then distribute this object as a PLI library with a
verilog top level wrapper. This is not encryption, but it will serve
the same purpose. It will be quite difficult to reverse engineer if
you run it on the gate level netlist.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
2. Use Verilog XL/NC to encrypt to your code.
Even, if some on breaks your code its allmost impossible to extra
what is the logic inside and can not use for synthesis.
But, There are some problmes with this method and it depends on
your code. But simulate and verify before sending to custmor.
iutroutroi <iriuoi...@iuotiowtr.com> wrote in message news:<3CE67C52...@iuotiowtr.com>...
ncrelocate -help
HTH,
Srinivasan
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt Ltd. - an Intel company
Bangalore, India
I don't speak for Intel
"iutroutroi" <iriuoi...@iuotiowtr.com> wrote in message
news:3CE7D722...@iuotiowtr.com...
> > You may want to look at CDSDOC.
<SNIP>
Take a look at the Model Packager(previously known as AMP) in cdsdoc - it
achieves what is required for securing the users IP. It works with
VHDL/Verilog/C and will produce model that can also be read by other
simulators through their c-interface.
Compared to the `protect methodology, it will take some extra time to setup
and prepare everything for packaging. It is free to use and NCSim end-users
do not need any license to run a packaged model. A couple of features are;
being able to specify nodes within the model that can be viewed and being
able to create "licensed" models so that you have control over when the
model will expire.
If they are using another simulator, then you will need an export license
from Cadence to package the model. NCSim customers are using the tool to
ship and receive IP, but as its a "free" tool it does get overlooked unless
you happen to read the documentation.
Martyn
--
Martyn Pollard
NCSim - High Performance VHDL/Verilog Simulation
NCVHDL, NCVerilog, Verification Cockpit
Cadence Design Systems. http://www.cadence.com/ncsim
Sign-up for the Talk Verification Newsletter
http://www.cadence.com/newsletters/newsletter.html
"Martyn Pollard" <m...@abccadence.com> wrote in message
news:3ce93326$1...@news.cadence.com...
> "Srinivasan Venkataramanan" <srini...@siliconsystems.no_spam.co.in>
wrote
> in message news:aca4dj$r...@news.or.intel.com...
<SNIP>
>
> Take a look at the Model Packager(previously known as AMP) in cdsdoc - it
> achieves what is required for securing the users IP. It works with
> VHDL/Verilog/C and will produce model that can also be read by other
> simulators through their c-interface.
>
> Compared to the `protect methodology, it will take some extra time to
setup
> and prepare everything for packaging. It is free to use and NCSim
end-users
> do not need any license to run a packaged model. A couple of features
are;
> being able to specify nodes within the model that can be viewed and being
> able to create "licensed" models so that you have control over when the
> model will expire.
If I understand you well enough, if I own a NCSIM license, then I can use
all the features (including "licensed model creation") - even if my customer
DOES NOT HAVE A NCSIM License - am I correct?
>
> If they are using another simulator, then you will need an export license
> from Cadence to package the model.
Is it sold separately?
> NCSim customers are using the tool to
> ship and receive IP, but as its a "free" tool it does get overlooked
unless
> you happen to read the documentation.
>
I tried to quickly browse through cdsdoc, but couldn't get clearly what I
need (may be didn't look deep enough):
" Does the customer need a Cadence License to use my model with say VCS"?
Thanks for any insight.
Regards,
My company is selling a Verilog Obfuscator. Take a look at
www.eda-utilities.com
An yes, an obfuscator does not replace an NDA. In fact, NDA should be
needed regardless of what you hand over (be it encrypted simulation
model, or gate level netlist).
Regards,
Eng Han
www.eda-utilities.com
> > If they are using another simulator, then you will need an export
license
> > from Cadence to package the model.
>
> Is it sold separately?
Yes, Contact the Cadence sales people for the price. Ask for feature 28010.
> I tried to quickly browse through cdsdoc, but couldn't get clearly what
I
> need (may be didn't look deep enough):
Open the cdsdoc gui -> ncsim -> Cadence Model Packager Guide (for Model
Creators)
>
> " Does the customer need a Cadence License to use my model with say VCS"?
If you packaged using the export license, then no. Otherwise it will require
an NCSim license during simulation. The export license puts the onus on the
IP packager to make it simulator independent.
Lousy cryptographic scheme, but all encryption
schemes are ultimately just tests of the reciever's
effort levels to crack them. So if the customer
isn't willing to go through a lot of work,
this can be useful and he can still evaluate
what you have.
We make obfuscators. See example at
http://www.semdesigns.com/Products/Formatters/ObfuscatorExample.html
--
Ira Baxter, Ph.D. CTO Semantic Designs
www.semdesigns.com 512-250-1018
"iutroutroi" <iriuoi...@iuotiowtr.com> wrote in message
news:3CE67C52...@iuotiowtr.com...