Xilinx specification requirements for using IEEE Encryption Modules
Version 2.0
Written by: Howard Walker & Premduth Vidyanandan
Last updated: February 16, 2016
1.0 Introduction
Purpose
This document describes how Xilinx will use the IEEE encryption specification as
outlined in the IEEE Verilog Std1364-2005 spec dated April 2006. Xilinx intends to
use encryption to replace the use SmartModels and planned support for this will begin
with the ISE 10.1i software. Any new protected modules developed in the ISE 10.1i
and later software will only be developed and supported using the encryption
specification. Use of existing SmartModels will continue to be supported in ISE
10.1i, but a phase out plan will later be defined so that only encryption modules are
supported in future releases of ISE.
Scope
This document describes how Xilinx will use of the IEEE encryption feature for
encrypted modules that will be supported in our Partner simulation software and used
by customers.
2.0 General Requirements
1. The use of encryption by Xilinx will be done on a module/file basis, which will
replace the current use of SmartModels. Since each SmartModel module was a
separate Verilog file, we want to use the encryption program from a partner to
encrypt each Verilog source file into an encrypted equivalent file. We would also
want to use the Verilog compiler to compile and encrypt specific IP core source
code files to a designated encrypted file name one file at a time. One suggested
feature we would like to have for ease of use would be to specify the
begin_protected and end_protected pragmas in separate source files so that the
encryption program would entirely encrypt the source files even if the source files
don’t explicitly use the begin_protected and end_protected flags within the source
code. We want to specify the begin_protected and all the encryption options
(including pragma protect options for data method, key owner, key method, key
name, and author info) in a “protect.v” file and the end_protected specification
will be in an “end_protect.v” file.
We would also want to use the Verilog compiler to compile and encrypt specific
IP core source code files to a designated encrypted file name one file at a time.
We will use a script that includes all the source files for a given IP core using a
format similar to following:
vlog +protect=gtp_dual_001.vp protect.v GTP_DUAL_SWIFT.v
vlog +protect=gtp_dual_002.vp protect.v gtp5_gtpdual_top_shell.v
….
2. The encrypted module needs to provide read-only visibility access to a set of
specified internal registers, and signals for a customer to reference. Since some
partners have indicated that partially encrypted modules present a security issue,
we have agreed that as an alternative a top level non-encrypted wrapper file can
be created which will that contain the needed signals or registers for visibility
requirements while all the other lower level modules will be entirely encrypted.
In this case all the lower level modules will contain the protect pragmas and will
not allow any kind of register or signal visibility to end users For this
implementation the software granularity would be so that the entire module is
encrypted if protect pragmas are contained anywhere in a module source code
file. Please see the example shown in section 5.0 below for more details.
3. Xilinx will specify the key used to enable customers to run simulations of
encrypted Xilinx modules by our Partner simulator tools within the “protect.v”
file. This key will be encrypted by the software partners using their own private
key. For simulation, the software partners will use their private key to decrypt the
Xilinx key and proceed to decrypt and compile the encrypted IP Core. This
scheme follows the encryption system outlined in Appendix H.3 (Titled Digital
Envelopes) in the IEEE Verilog Std1364-2005 Spec titled IP Author secret key
encryption system.
4. Xilinx would prefer to use Advanced Encryption Standard (128 bit AES) on
encrypted modules that are distributed to customers. If there are any issues that
come up with using the AES 128 bit encryption standard we can use just 64 bits
of the 128 key as an alternative.
5. There should be no simulation differences seen between running an RTL module
and running the same encrypted module in the simulator. If there is a difference
the simulation Partner is responsible to correcting the simulation behavior.
6. The encrypted models Xilinx initially intends to develop and support are in
Verilog, however we later expect to have support for VHDL as well. There should
be no additional license requirements due to the use of encryption. We also
recognize that the use of our Partners software will be subject to the same
licensing requirements as with non-encrypted RTL, regardless of language.
7. The use of encrypted models should not impact simulation performance. There
should be no overhead for running encrypted models vs. running standard RTL
simulation.
8. The customer should not have to do anything special to run simulation with
encrypted modules. This flow should be seamless from the customer standpoint.
9. Xilinx would like to recommend that partners look into a language neutral
licensing scheme for encrypted blocks. It would be in the best interest of Xilinx
and partners to not require a mixed-mode licensing scheme when simulating
encrypted IP
10. Support should be available for all configurations of simulation software from our
Partners and on all the platforms that their software is supported on. All the
platforms that these may be used on with the ISE software are listed in section 3.0
under System Requirements.
11. The encrypted modules should always be compatible with new or updated
software releases distributed by simulation software Partners. This would include
all future releases from when initial support begins as well as software patches or
updates. This will also be contingent on any future changes or enhancements to
the 1364 or 1800 LRMs.
12. The encryption software should encrypt any `include files that is referenced from
an RTL source file that is specified to be encrypted. All encrypted files should be
concatenated into a single file. Xilinx will distribute the IP core models as
encrypted files under a library sub-directory. The encrypted IP Core models will
be compiled when the customer runs Xilinx’s Compxlib program with a given
version of the Partners software.
13. Encrypted IP Cores need to maintain adequate security when they used in the
Partners software tools. When an IP core uses the encryption methodology, no
lower level module, signal or register names or hierarchical names should be
referenced as clear text in either the compilation or simulation log files or from
the GUI or work directories that are created. Any references to names specified
within encrypted blocks will either be removed or encrypted.
14. When encrypted IP modules are used the Partner needs to insure that all the
Verilog compilation commands listed below will also be applicable to use with
encryption. This should include all compile search paths and file handling.




-v (specifies a Verilog library file that will be read, encrypt, and save
as filename.vp. Note that the entire library file is encrypted regardless
of whether there are undefined instantiated modules in the source
code)
-y (specifies a Verilog library directory. The software will encrypt all
the files under the given directory, and will generate an encrypted file
by the name.vp)
+incdir (This option should be available on the command line during
encryption so we don’t have to rename or compile the encrypted file for
simulation. Any `include files need to be encrypted as *.vp files and our
preference is that these be incorporated into the encrypted file that
references it for simulation).
-f
 -F
 -file
Plus the following which may be needed in combination with the
above ones:
 -define (this option will not resolve macros during encryption, either
the command line or separate file will specify the macro definition.The
macro name should not require that it be assigned a value on the
command line.)
3.0 System Requirements
The encryption feature we be used on machines with the OS listed below:
PC Platform Support
o
Windows XP Pro, Windows Vista -32 and 64 bit
LINUX Platform Support

Redhat EE WS 4.0, 5.0 -32 and 64 bit
Suse Platform Support

SLED version 10 -32 and 64 bit
4.0 Visibility in Encrypted Modules
Part of the encryption spec allows for signals within a given module to be made
visible if they are listed outside of the begin_protect/end_protect tags. This provides the
customer with the ability to have visibility of designated registers, signals and nets as
mentioned in item #2 under the General Requirements Section. The general requirement
will be the same for VHDL encryption tool once the VHDL LRM is finalized.
5.0 Alternative option to provide read access to selected signals within encrypted
modules
As an alternative to providing selective encryption within a single Verilog module (the
preferred method), we are allowing some partners to provide a script which creates a top
level wrapper module which contains signals that need to be visible to the end user for
debugging purposes. Besides creating a top level wrapper file the script also need to add
the required assignment information to a lower level module so that signals from the
lower level and correctly displayed in the top level wrapper module.
This alternative method is an IP deployment methodology that requires Xilinx (the IP
provider) to place the encrypted IP within a public (non-encrypted) wrapper module;
hence the contents of the wrapper module are visible to anyone. As stated above, the
granularity of the IP to be encrypted is a Verilog module. The encrypted IP module is
instantiated inside the wrapper module. The wrapper module will contain the same ports
as the original IP. This allows users to instantiate the wrapper module and connect to
ports directly as if it were the original IP.
In addition to the encrypted IP instance, the wrapper module will include an instance of
non-encrypted module containing only a set of variable declarations. Each such variable
declaration corresponds to one of the observable signals within the encrypted IP. Nothing
else should appear in the non-encrypted module.
Finally, a continuous assignment will be added in the encrypted IP module for each
observable signal declared in the non-encrypted module. The destination (left-hand side)
of the continuous assignment is a hierarchical expression that refers to the observable
signal in the non-encrypted module; the source (right-hand side) of the continuous
assignment corresponds to the actual signal (variable or net) within the IP, which can be a
hierarchical expression as well. Note that since the public signals are all variables (not
nets), Verilog will ensure that no additional drivers are allowed to modify the observable
signals in the public module.
The following conventions are proposed. For an IP module whose original name is X:
 The name of the wrapper module is X - the original name of the encrypted IP.
 The name of the encrypted IP module becomes X_private.
 The name of the encrypted IP instance is always IP.
 The name of the module containing observable signal declarations is X_public.
 The instance name of the X_public module is always public.
For example, using the example of section 4.0, the proposal leads to the following:
Note - the original name of the IP block was CPU, it is renamed CPU_private.
module CPU ( <cpu_ports> );
CPU_private IP( … );
CPU_public public();
endmodule
// same ports as CPU_private
// IP instance (encrypted)
// observable data instance
module CPU_public;
// Only data declarations
reg [0:7] PROGRAM_COUNTER;
logic READ_ENABLE;
endmodule
`begin_protected
module CPU_private( <cpu_ports> )
...
assign public.PROGRAM_COUNTER = READ_MEM_instance.prog_cntr;
assign public.READ_ENABLE = READ_MEM_instance.rd_en;
endmoule
`end_protected
The above methodology is compliant with all Verilog simulators, and satisfies all of Xilinx’s
requirements:
 The observable signals (wires/registers) in the encrypted IP are not visible to users.
 The hierarchical path of the actual observable signals is not visible.