cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
8,233 Views
Registered: ‎08-10-2009

Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

I'm launching my ModelSim tool (v10.0b) from Vivado (v2014.2) to simulate a divider core I generated through divider generator. The automated process launches ModelSim and appears to successfully create (vlib) and assign logical names (vmap) to the suite of libraries associated with divider IP. It also proceeds to compile a handful of core models associated with the divider IP into the respective libs. But strangely, after demonstrating a handful of successful compiles of encrypted models, it hits an error on one particular file due to "in protected region."

 

Below is a partial list of the compile commands from the DO script. All of these commands appear to compile successfully except for the very last one, xbip_dsp48a_wrapper_v3_0.vhd, which fails due to the protected region. It doesn't make sense to me why the previous encrypted models compile successfully; why does the tool all of a sudden have an issue with this particular file?

 

It's also strange to me that for the successful compiles, those respective libraries are still being denoted as "empty" by the ModelSim Library viewer.

 

Thanks for any insight. Here is the list of compile commands (all successful except for the last one due to 'in protected region'):

 

vcom  -work xbip_utils_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_utils_v3_0/hdl/xbip_utils_v3_0_pkg.vhd"
vcom  -work xbip_utils_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_utils_v3_0/hdl/xcc_utils_v3_0.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/global_util_pkg.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/axi_utils_v2_0_pkg.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/axi_utils_comps.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/glb_srl_fifo.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/glb_ifx_slave.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/glb_ifx_master.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/axi_slave_2to1.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/axi_slave_3to1.vhd"
vcom  -work axi_utils_v2_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/axi_utils_v2_0/hdl/axi_slave_4to1.vhd"
vcom  -work xbip_pipe_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_pipe_v3_0/hdl/xbip_pipe_v3_0_viv_comp.vhd"
vcom  -work xbip_pipe_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_pipe_v3_0/hdl/xbip_pipe_v3_0_comp.vhd"
vcom  -work xbip_pipe_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_pipe_v3_0/hdl/xbip_pipe_v3_0_viv.vhd"
vcom  -work xbip_pipe_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_pipe_v3_0/hdl/xbip_pipe_v3_0.vhd"
vcom  -work xbip_dsp48_wrapper_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48_wrapper_v3_0_pkg.vhd"
vcom  -work xbip_dsp48_wrapper_v3_0 -93 "c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48a_wrapper_v3_0.vhd"

 

 

0 Kudos
1 Solution

Accepted Solutions
Observer
Observer
14,316 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

I was finally able to get past my compilation errors. The key was to start off clean by prepping my own simulation environment properly with the Xilinx libs completely, before compiling the IP files.

 

(Yes, I realize this is recommended, and the tools even warn you of this when the simulator target is changed in Vivado. I thought I had those libs already compiled but there must have been something missing from that structure...)

 

So in Vivado 2015.4, I ran this compile command:

 

compile_simlib -directory xil_sim_libs -simulator modelsim -family zynq -library all -language all

 

It took about 15 minutes or so. Once it completed successfully, I was then able to run the DO script to compile the Divider IP files (first the libs were created using vlib commands; next the libs were mapped using vmap commands; then the files were compiled into the particular target libs).

 

So I now consider this issue resolved.

 

POSTSCRIPT: I did hit an error when I compiled the top level file of the divider IP into ModelSim toward the end of the DO script. A VHDL error was flagged because a particular model in a library couldn't be found using the following USE command:

 

USE div_gen_v5_1_9.div_gen_v5_1_9;

 

To get around this error, I replaced the ".div_gen_v5_1_9" with ".all" and it worked. This could be a bug in the generated files.

View solution in original post

7 Replies
Highlighted
Observer
Observer
8,214 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

Just an update on this situation. This divider IP core contains 241 files to be compiled in the DO script that was auto-generated by Vivado. When I try to compile all those files, it appears to be intermittent (random?) as to which files get the "in protected region" error and which ones compile successfully. I would say roughly 60-70% compiled successfully.

0 Kudos
Highlighted
Teacher
Teacher
8,209 Views
Registered: ‎07-09-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

 I dont know ,

 

But I seem to remember 

 

a) only certain modelsims work with encrypted files,

 

b) you need to compile the unisim lib for modelsim 

 

may be one of these is the bug .

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Observer
Observer
8,190 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

Thanks for the ideas. I do have the unisims lib compiled into my modelsim environment. Regarding the modelsim versions, I guess my question would be, why would some encrypted files be compiled successfully while others do not? I assume that once the process of decrypting with the right key, etc., has been demonstrated, that version of the tool should be able to decrypt all such files encrypted in the same manner.

0 Kudos
Highlighted
Observer
Observer
8,118 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

Just a theory, but ModelSim could be reporting that there is an error in the particular compile, and the error happens to be in the protected region. So perhaps there isn't a problem decrypting. I'll have to think about this, and why certain files auto-generated by Vivado divider generator would result in compile errors.

 

 

vcom -work xbip_dsp48_wrapper_v3_0 -93 "c:/<USER_PATH>/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48a1_wrapper_v3_0.vhd"
# Model Technology ModelSim PE vcom 10.0b Compiler 2011.05 May  5 2011
# -- Loading package STANDARD
# ** Error: c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48a1_wrapper_v3_0.vhd(46)): in protected region.
# ** Error: c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48a1_wrapper_v3_0.vhd(46)): in protected region.
# ** Error: c:/ODI/NEC/2016/working_DAS_ZedBoard/das_fpga/divider_radix2/divider_radix2.srcs/sources_1/ip/div_gen_0/xbip_dsp48_wrapper_v3_0/hdl/xbip_dsp48a1_wrapper_v3_0.vhd(46)): in protected region.
# C:/modeltech_pe_10.0b/win32pe/vcom failed.

0 Kudos
Highlighted
Observer
Observer
8,117 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

Here is a forum case very similar: https://forums.xilinx.com/t5/Simulation-and-Verification/encrypted-fifo-file-fails-Questa-compilation-in-encrypted-region/m-p/621177#M13033. I did base my compile script completely on the auto-generated script from Vivado, so I don't see how this is what is causing my problems. 

 

Also, I went ahead and tried to simulate with the files that do successfully compile, but I hit an error complaining about a missing module which happens to be one of the modules that compile with an error.

0 Kudos
Highlighted
Observer
Observer
8,062 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

UPDATE: I generated my divider core in Vivado 2015.4. It seemed to generate a different set of divider files, a much smaller list of files. I followed the modelsim DO script that was also auto-generated. But my result was similar as before. Some files compile successfully, some files hit the error "in protected region." As I mentioned, I am using ModelSim 10.0b. I'm wondering if these files would only compile in a newer version of ModelSim, but this doesn't make sense to me, and this would cost me to upgade just to get beyond this bug, if that is the problem.

0 Kudos
Observer
Observer
14,317 Views
Registered: ‎08-10-2009

Re: Vivado/ModelSim: compile fails on encrypted file after successfully compiling other encrypted files

Jump to solution

I was finally able to get past my compilation errors. The key was to start off clean by prepping my own simulation environment properly with the Xilinx libs completely, before compiling the IP files.

 

(Yes, I realize this is recommended, and the tools even warn you of this when the simulator target is changed in Vivado. I thought I had those libs already compiled but there must have been something missing from that structure...)

 

So in Vivado 2015.4, I ran this compile command:

 

compile_simlib -directory xil_sim_libs -simulator modelsim -family zynq -library all -language all

 

It took about 15 minutes or so. Once it completed successfully, I was then able to run the DO script to compile the Divider IP files (first the libs were created using vlib commands; next the libs were mapped using vmap commands; then the files were compiled into the particular target libs).

 

So I now consider this issue resolved.

 

POSTSCRIPT: I did hit an error when I compiled the top level file of the divider IP into ModelSim toward the end of the DO script. A VHDL error was flagged because a particular model in a library couldn't be found using the following USE command:

 

USE div_gen_v5_1_9.div_gen_v5_1_9;

 

To get around this error, I replaced the ".div_gen_v5_1_9" with ".all" and it worked. This could be a bug in the generated files.

View solution in original post