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!

Reply

PR flow for modules that contains closed IPs

Highlighted
Observer
Posts: 30
Registered: ‎12-30-2015

PR flow for modules that contains closed IPs

Hello,
I've successfully used many times the PR flow described in the XAPP1231 Wiki page to synthesize modules designed with HLS. In this scripted flow, each PR module is described by <mod_name>.prj file. Internally, the contains the names of the VHDL/Verilog source files that constitute the module.

The problem arises if the HLS modules included IP cores (LogiCORE) that are not available as source code eg: "floating_point". In such a case I noticed that the VHDL code, in the architecture section, contains special strings used by Vivado to instantiate the IP cores, instead of a plain VHDL description.


If I plug one of such modules (that contains closed IPs) into the PR flow the process fails claiming that the PR module contains black boxes. I've searched the Xilinx forum and docs for this issue but didn't find anything. Does anyone know how to solve this issue?


Thanks.

Xilinx Employee
Posts: 428
Registered: ‎04-16-2008

Re: PR flow for modules that contains closed IPs

Hi @twoism_

 

Were you able to work past this? I believe this issue is that if you have floating point in your design, VHLS does not write out RTL but just instantiates the IP (as you stated). 

 

If you package up the IP as an IP Package or a DCP, and take that into Vivado, those packages include an .xci file which will resolve the blackbox for the Xilinx IP, and synthesis should complete with no issues.  

 

However, if you simply copy the RTL over to Vivado as Verilog or VHDL files, it won’t have the necessary .xci files and Vivado won't know how to link in the “missing RTL". Only the instantiation will be present.

 

So, this should be taken care of automatically if the IP is packaged in VHLS. We DO NOT support/recommend taking the Verilog and VHDL (since if the design uses IP, you won’t everything you need).

 

Hope this helps.

Observer
Posts: 30
Registered: ‎12-30-2015

Re: PR flow for modules that contains closed IPs

Hi @woodsd, thank you for the answer,

The problem is that the IP package exported by HLS (2016.4) does not contain any .xci file. The archive contains only a set of plain hdl sources in the ./hdl/vhdl or ./hdl/verilog folder plus some vhd file in the ./hdl/ip folder for the Xilinx's closed IPs. I'm sending the IP archive generated by HLS as attached file.

Observer
Posts: 30
Registered: ‎12-30-2015

Re: PR flow for modules that contains closed IPs

 

I found a workaround. As suggested by @woodsd proprietary IPs are specified by a xci file. Such xci files are not exported by HLS in the archive but the can be found inside the project dir "solution1/impl/vhdl/project.srcs/sources_1/ip" and added to the module specification in the design.tcl script. I don't know if this is a good practice (a feedback would be appreciated) but it works.

 

 

set module1_variant2 "minv"
set variant $module1_variant2
add_module $variant
set_attribute module $variant moduleName   $module1
set_attribute module $variant prj          $prjDir/$variant.prj
set_attribute module $variant ip           [list $srcDir/ip/$variant/ipc/hwmod_ap_fadd_3_full_dsp_32/hwmod_ap_fadd_3_full_dsp_32.xci \
                                                 $srcDir/ip/$variant/ipc/hwmod_ap_faddfsub_3_full_dsp_32/hwmod_ap_faddfsub_3_full_dsp_32.xci \
                                                 $srcDir/ip/$variant/ipc/hwmod_ap_fcmp_0_no_dsp_32/hwmod_ap_fcmp_0_no_dsp_32.xci \
                                                 $srcDir/ip/$variant/ipc/hwmod_ap_fdiv_14_no_dsp_32/hwmod_ap_fdiv_14_no_dsp_32.xci \
                                                 $srcDir/ip/$variant/ipc/hwmod_ap_fmul_2_max_dsp_32/hwmod_ap_fmul_2_max_dsp_32.xci \
                                                 $srcDir/ip/$variant/ipc/hwmod_ap_fsqrt_10_no_dsp_32/hwmod_ap_fsqrt_10_no_dsp_32.xci \
                                           ]
                                                                                                                                        
set_attribute module $variant xdc          $ipDir/$variant/constraints/hwmod_ooc.xdc
set_attribute module $variant synth        ${run.rmSynth}

  

Xilinx Employee
Posts: 428
Registered: ‎04-16-2008

Re: PR flow for modules that contains closed IPs

Hi @twoism_

 

Thanks for the update on this.  Yes, this is good practice. I'm sorry I wasn't able to more clearly define this solution for you earlier.  I was quite aware of how HLS handles these IP, or why the XCI is not included in the packaged closed IP.  

 

However, dealing with IP via the XCI is definitely the recommended solution, so adding the XCI file as you have will allow the tools to to find an manage all parts of the IP (hdl, dcps, xdc, etc).  

 

The resulting DCP you get from your "minv" OOC synthesis should be fully resolved with no black boxes, and should be able to be passed on to the PR implementation.