Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Encrypting Verilog source

1,236 views
Skip to first unread message

iutroutroi

unread,
May 18, 2002, 12:05:47 PM5/18/02
to
We need to hand over some Verilog code to a potential customer.
They would like to evaluate our design before signing over
an NDA, but we'd like to sign the NDA before handing over our
design. (Classic chicken and egg problem.)

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!

Rick Filipkiewicz

unread,
May 18, 2002, 4:59:22 PM5/18/02
to

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.


Paul

unread,
May 18, 2002, 5:31:41 PM5/18/02
to
NDAs are pretty routine these days. What's the objection to signing it?
The only commitment they're making is not to disclose the Verilog. I
don't recall ever having a customer refuse to sign one before seeing
anything more detailed than a corporate overview PowerPoint presentation.


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

pini

unread,
May 19, 2002, 6:52:04 AM5/19/02
to
Hi
You may want to look at CDSDOC.

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>...

iutroutroi

unread,
May 19, 2002, 12:45:30 PM5/19/02
to
> You may want to look at CDSDOC.

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

Petter Gustad

unread,
May 19, 2002, 5:06:15 PM5/19/02
to
iutroutroi <iriuoi...@iuotiowtr.com> writes:

> 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

Sudhakar

unread,
May 20, 2002, 2:09:56 AM5/20/02
to
How to encrypt more secure:
--------------------------
1. Use vcs to convert your code in un-readable format.
Vcs compile there are couple of options to do that..it changes
your code variables names and all the stuff...no one can not find what
is there inside.

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>...

Srinivasan Venkataramanan

unread,
May 20, 2002, 2:17:16 AM5/20/02
to
Hi,
If you and your customer can agree on a particular tool + version, then
you could compile it in your workstation and send just the compiled code and
the Testbench and ask your customer to simulate it. In case of NC, try the
command:

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>


Martyn Pollard

unread,
May 20, 2002, 1:32:55 PM5/20/02
to
"Srinivasan Venkataramanan" <srini...@siliconsystems.no_spam.co.in> wrote
in message news:aca4dj$r...@news.or.intel.com...

> Hi,
> If you and your customer can agree on a particular tool + version,
then
> you could compile it in your workstation and send just the compiled code
and
> the Testbench and ask your customer to simulate it. In case of NC, try the
> command:
>
> ncrelocate -help


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

Srinivasan Venkataramanan

unread,
May 21, 2002, 2:52:25 AM5/21/02
to
Hi Martyn,

"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,

ehml

unread,
May 21, 2002, 1:01:03 PM5/21/02
to iutroutroi
Hi Iutroutroi,

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

Martyn Pollard

unread,
May 21, 2002, 4:33:37 PM5/21/02
to
> 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?
Can you clarify the last statement? To package the model you will need a
copy of NCSim and if you want to allow the model to run with another
simulator you will need an export license. Exporting is specified with
ampkg -export. Use ampkg -help to get all the switches.

> > 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.

Ira Baxter

unread,
May 25, 2002, 6:16:41 PM5/25/02
to
You could obfuscate the code.
That is, remove comments, indentation,
scramble line breaks, rename variables to
nonsense names, etc.

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...

0 new messages