cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
OparinVD
Visitor
Visitor
334 Views
Registered: ‎06-29-2021

Generation of the IP CORE failed during vpl: Step generate_target

Hello!

Some abstract: I use Viavado 2020.1 and I'm trying to create RTL kernel for U50. I have my custom ipcore which consists of standard blocks such as axis_interconnect and my other custom child subcore. This top core is packaged as a standard Vivado IP and placed to user ip_repo. I created a test design with MicroBlaze and placed my ipcore on BD. Synthesis and implementation were successful, so my custom ipcore is correct. Next, I packaged this top-level ipcore with tcl command "package_xo -xo_path ./MyKernel.xo -force -kernel_name MyKernel -kernel_xml ./kernel.xml -ip_directory ../../ip_repo/MyCore_U50".

To build the entire project I used one of Xilinx's examples MakeFile. "make all ..." command fails on vpl step generate_target.

One of the reasons is the critical warning: "CRITICAL WARNING: [IP_Flow 19-4065] The definition for subcore dependency 'user.org:user:subcore_u50:1.0' is not available in the repository." I tried to add the path to my IP repository but failed to find the way, how to do it. Default ip_repo in vivado.xml correctly points to my ip_repo: "<DEFAULT_IP_REPOS value="/home/vitaly/Designs/Vivado_VCS/ip_repo"/>" but it is not enough. All tcl sripts I can find are being regenerated when I launch "make all" so I can't add corresponding commands to add my ip_repo path to generated project.  How can I make my ip_repo visible to the generated project?

Another problem is connected with standard axis_interconnect, generation fails when trying to update from version 2.1 to 2.1. Maybe it is just a result of the first problem, but anyway...

"ERROR: [VPL 19-98] Generation of the IP CORE failed.
Upgrade IP is not supported for xilinx.com:ip:axis_interconnect:2.1.
%s Note that the upgraded IP will have an incomplete parameterization, and will require user recustomization." (from command shell log were "make" command launched)

"CRITICAL WARNING: [IP_Flow 19-3817] IP 'ulp_My0_0' failed to properly generate child IP 'MyCore_alveo_axis_interconnect_1_0'. Please edit or regenerate IP Definition to correct the child IP. Reason:
Upgrade IP is not supported for xilinx.com:ip:axis_interconnect:2.1.
%s Note that the upgraded IP will have an incomplete parameterization, and will require user recustomization." (from runme.log)

The issue was solved when I deleted interconnect and re-added it. But soon issue came back as immediate as unexpectedly it was solved that way. I rechecked the interface configuration of master-slave pairs, it matches. And the problem occurs not only with border interconnects but also inside block design too.

What is could be the reason?

Tags (1)
0 Kudos
2 Replies
yangc
Xilinx Employee
Xilinx Employee
252 Views
Registered: ‎02-27-2019

For IP path, you can use the --user_ip_repo_paths option in V++. As for the upgrade ip issue, what's your custom IP's target device?

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
OparinVD
Visitor
Visitor
228 Views
Registered: ‎06-29-2021

As a temporary decision for IP path I've discovered a "-parent_ip_directory" option and used it in conjunction with "-ip_directory" in "package_xo" command. But it packs the entire ip_repo, so "--user_ip_repo_paths" option in V++ looks better, thank you.

Initially, I created two KCU105 board based projects for sub-core and top-level core. It was fully tested in hardware. After it, I renamed projects, changed "Project device" to "Alveo U50..." and updated BD. Synth and implementation were successful, but during xclnbin generation the issue occurred.

I recreated projects from tcl (separate scripts for project and for BD), so sub-modules were added as new instead of updating, but it was no effect.

Finally, I changed all universal axis_interconnects to specific function modules (clock_converer, dwith_converter, switch, and so on) and it let me overcome the dead point. xclbin has been generated but it is still interesting, what it was and how to avoid similar problems in the future.

 

0 Kudos