UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Scholar markcurry
Scholar
8,746 Views
Registered: ‎09-16-2009

IEEE P1735 encryption and sharing IP between vendors

Jump to solution

 

I've searched the forums and AR records, and can find no decent answers for how much the IEEE P1735 encryption standard is supported with Xilinx flows and IP.

 

I'm trying to build some of my designs with Synplify.  I know the quick stock answer - this is a Xilinx forum, not a Synopsys one, but allow me a little lattitude for a moment.

 

My design contains some Xilinx IP - which is encrypted with what I'm guessing is IEEE P1735.  Synplify is choking on the RTL with message like;

@W: Malformed decryption envelope in file './shared/pcores/blk_mem_gen/blk_mem_gen_v8_2/hdl/blk_mem_axi_read_fsm.vhd': No known key found in envelope

 

As you can see, this is just part of the Block Memory Generator within the xilinx IP.  It's encrypted.  Looking at the source files - I can see a readable header before the encrypted contents begin:

`protect key_keyowner = "Xilinx", key_keyname= "xilinx_2014_03", key_method = "rsa"
`protect encoding = (enctype = "BASE64", line_length = 76, bytes = 256)
`protect key_block

...
`protect key_keyowner = "Synopsys", key_keyname= "SNPS-VCS-RSA-1", key_method = "rsa"
`protect encoding = (enctype = "BASE64", line_length = 76, bytes = 128)
`protect key_block
GNmAK91+tvb5cCyfMjx77VtbQngb3/+wJAhoTr/uND4WhhPz4vOR0XSdlGdFWbNM7sSE0ObFKLOu
soVHD2jd24tqF/KSm2xCRxu9OrsIAHdawv9WcDxmVPwHgCl1sSWCJE7w78zxyYBRClBaXiLjqziH
unxuHPXdp1z4psmDDzQ=

So it APPEARS that there's info in there to allow the files to be read, and decrypted by Synplify.

 

However, it's not working.

 

Yes I have a ticket open with Synopsys.  No, I'm not making much progress. This is a gray area, between two vendors, with little room for me to gain any insight or debug.  I'm hoping perhaps someone with Xilinx can comment and point me in the correct direction for how to get this working.

 

Thanks,

 

Mark

0 Kudos
1 Solution

Accepted Solutions
Scholar austin
Scholar
16,246 Views
Registered: ‎02-27-2008

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

m,

 

What's happening here is that you are trying to synthesize a Xilinx
IP, the Block Memory Generator as it appears.  So almost all Xilinx IPs
are in encrypted RTL form.  MIG is the most notable exception, it's
clear text because modifications might be needed to fit special
application requirements.  So when we encrypt the RTL, we use IEEE P1735
and we encrypt using the public key of the _most commonly used
simulators_ (VCS, ModelSim, NCSim, Questa and maybe a couple more).

What we don't do is add any third-party _synthesis tool_ public key in
the encryption process.   We do not qualify and test with external

synthesis tools and their multiple versions that exist out there.

 

This RTL is meant to be synthesized with the Vivado
synthesis tool anyways (it uses special pragmas) and that's what the
tool does whenever you customize and generate an IP in Vivado.

If you are interested in importing the IP into the Synopsys
environment, Synplify has support for netlisting the IP content back
into Synplify and potentially re-optimized its content but again
Synplify won't be able to synthesize the IP RTL code directly. That
process is all explained in the Synplify documentation

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
5 Replies
Scholar austin
Scholar
16,247 Views
Registered: ‎02-27-2008

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

m,

 

What's happening here is that you are trying to synthesize a Xilinx
IP, the Block Memory Generator as it appears.  So almost all Xilinx IPs
are in encrypted RTL form.  MIG is the most notable exception, it's
clear text because modifications might be needed to fit special
application requirements.  So when we encrypt the RTL, we use IEEE P1735
and we encrypt using the public key of the _most commonly used
simulators_ (VCS, ModelSim, NCSim, Questa and maybe a couple more).

What we don't do is add any third-party _synthesis tool_ public key in
the encryption process.   We do not qualify and test with external

synthesis tools and their multiple versions that exist out there.

 

This RTL is meant to be synthesized with the Vivado
synthesis tool anyways (it uses special pragmas) and that's what the
tool does whenever you customize and generate an IP in Vivado.

If you are interested in importing the IP into the Synopsys
environment, Synplify has support for netlisting the IP content back
into Synplify and potentially re-optimized its content but again
Synplify won't be able to synthesize the IP RTL code directly. That
process is all explained in the Synplify documentation

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar markcurry
Scholar
8,726 Views
Registered: ‎09-16-2009

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

Thanks for the explanation Austin.  At least I know why.  I was hoping there was just some sort of trick with the decryption that I wasn't doing right.

 

Still frustrating, as this "road block" preventing Synplify from synthesizing Xilinx IP is well, stupid, IMHO, and counterproductive.  Preventing customers from using your IP serves no good purpose.  Hiding under the guise of "we don't qualify and test external synthesis tools" is just meaningless.  We integrate all sorts of IP, both internal, external, xilinx or not.  How we synthesize, and verify is our responsibility.  I think I trust the industry leader in Synthesis to do the job correctly.

 

So now I'm stuck with coming up with some sort of kludge flow where we "compile this will synplify", "compile that with Vivado", then somehow need to bring it all back together.. Ugh.

 

Thanks anyway. Not sure how I'll move forward.

 

--Mark

 

0 Kudos
Scholar austin
Scholar
8,722 Views
Registered: ‎02-27-2008

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

m,

 

Honestly, creating work for our support harms everyone, so this is not a dumb decision.


Throwing it all out there can be quite harmful.  I am sorry that you do not agree, but it is the right decision (most benefit to all).

 

As IP is becoming a majority of any new design, verifying that IP becomes paramount.  We can only guarantee what we have control over.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar markcurry
Scholar
8,720 Views
Registered: ‎09-16-2009

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

@austin wrote:

m,


 

As IP is becoming a majority of any new design, verifying that IP becomes paramount.  We can only guarantee what we have control over.

 

 


 

You do what any other IP vendor does - you guarantee what you can - the RTL, and the standard implementation.  If a customer decides to implement using a non-standard flow, then that's their responsibility. Don't prevent your customers from success.  Let them decide.  You'll find that most of your customers are smarter than you give them credit for.

 

Regards,

 

Mark

 

 

 

 

0 Kudos
Scholar austin
Scholar
8,713 Views
Registered: ‎02-27-2008

Re: IEEE P1735 encryption and sharing IP between vendors

Jump to solution

m,

 

I agree, most customers are smart.

 

Those are not the ones I worry about.

 

I worry about the ones who are struggling diverting our attention away from what is important.

 

I also want those who are struggling to be successful, without detracting from existing successful customers.

 

Thank you for your understanding,

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos