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: 
Contributor
Contributor
8,556 Views
Registered: ‎02-27-2016

Resolve Sub-Core Reference in Packaged IP Project

I am trying to figure out how to resolve references to reusable IP libraries made from a packaged custom IP project.  The steps that I have followed thus far to package my custom IP are:

 

  1. Create a new Vivado project.

  2. Create a top level VHDL source file that calls out a library "fifo_generator_v13_1_0" and then uses the "fifo_generator_v13_1_0.fifo_generator_v13_1_0" package.  An instantiation of the "fifo_generator_v13_1_0" component is then added.

  3. Select "Tools -> Create and Package IP..." and select "Package your current project".

  4. Opening up the "component.xml" in Vivado and selecting the "File Groups" pane, I see that a sub-core reference has been added to the component as "Standard/Synthesis/Sub-Core References/xilinx.com:ip:fifo_generator:13.1".

  5. If I look at project sour hierarchy, the icon next to the "fifo_generator_v13_1_0" item still contains a "?" meaning it recognizes that there is an instantiation but hasn't resolved it to the components source.

Since the "fifo_generator_v13_1_0" never resolves, I can't run simulations or test synthesis or the like from the current project.

 

 

I know the normal way would be to actually create a configured IP of the FIFO and include the "XCI" file, however, I need the ability to tweak the generics of the FIFO instantiation based on generics passed to my custom IP.  This means I have to directly instantiate the FIFO rather than use XCI.

DornerWorks
https://goo.gl/8wtknW
0 Kudos
19 Replies
Xilinx Employee
Xilinx Employee
8,552 Views
Registered: ‎09-20-2012

Re: Resolve Sub-Core Reference in Packaged IP Project

Hi @corrin.meyer

 

This discussion might be helpful https://forums.xilinx.com/t5/System-Logic/How-can-I-natively-instantiate-a-fifo-generator-FIFO-in-Verilog/td-p/683952

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Contributor
Contributor
8,548 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@vemulad

 

Thank you for the pointer.  I think I am looking for something a little different.  The example provided in the indicated thread imports the FIFO sources rather than referencing them as remote sources (and in my case remote sources via a Sub-Core Reference), which is what I would like to do.

DornerWorks
https://goo.gl/8wtknW
0 Kudos
8,536 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project


@corrin.meyer wrote:

I know the normal way would be to actually create a configured IP of the FIFO and include the "XCI" file, however, I need the ability to tweak the generics of the FIFO instantiation based on generics passed to my custom IP.  This means I have to directly instantiate the FIFO rather than use XCI.


usually when we you it "the regular way" you end up instantiating a wrapper, but the FIFO object comes with a verilog, a vhdl wrapper but also with a  top level file.

You can probably route a generic to that block, try to declare this top level file as a component and try to use it, let me know if it works.

I guess the problem if you do it this way, is you're going to loose the "higher level" interface, like an AXIS wrapper for instance, you have to use the original data buses .

 

I am interested in your results, I have never done it but I feel like I will have to very soon

G.W.,
NIST - Time Frequency metrology
0 Kudos
Contributor
Contributor
8,523 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres

 

That is how I started, but the result is that it still imports all of the FIFO Generator IP sources into the project rather than referencing them as remote sources.  I suppose I can deal with that for non-library IP, but then library IP causes another headache.

 

If you have IP packaged as a library, you can't instantiate it, the only way to have a packaged IP, A, reference a packaged library IP, B, is to add 'B' as a "Sub-Core Reference" via the component.xml for 'A'.  But the library 'B' is not resolved until you add a configured version of 'A' to another project.

 

Feels as if I need four different projects for a large IP:  one for initial development, a second for packaging, a third to add a configured version of the IP to, and a fourth to develop the IP with resolved references to sub-cores.  I have to be missing something.

DornerWorks
https://goo.gl/8wtknW
0 Kudos
8,336 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project

@corrin.meyer,

 

you might want to look at the last chapter of this presentation:

http://www.cl.cam.ac.uk/research/srg/netos/projects/netfpga/workshop/technion-august-2015/material/slides/2015_Summer_Camp_Day3_IPs.pdf

 

apparently it is doable but only in tcl mode: "a created IP (from the IP catalog or command line) can only have a single set of values for its parameters"

 

We should use add_subcore and subcore references, I will keep you updated on my progress

 

 

G.W.,
NIST - Time Frequency metrology
0 Kudos
Contributor
Contributor
8,302 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres

 

Thank you for the information; it looks interesting.  However, I am not sure any of it really pertains to my issue with resolving references to sources of sub-cores without instantiating the core itself in a separate project.  Maybe I missed something?

 

The 'add_subcore' command will add a reference to the sub-core, but if you open the packaging project and look where the sub-core is instantiate you will see that the instance can't be resolved.  Now, package the IP and instantiate the custom IP in a new project and the sub-core will resolve.

DornerWorks
https://goo.gl/8wtknW
0 Kudos
8,291 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project

@corrin.meyer,

 


@corrin.meyer wrote:

The 'add_subcore' command will add a reference to the sub-core, but if you open the packaging project and look where the sub-core is instantiate you will see that the instance can't be resolved.  Now, package the IP and instantiate the custom IP in a new project and the sub-core will resolve.


I think I'm stuck at the same state, the "File Groups" tab in the IP-packager contains the subcore reference, but I guess you are referring to the file hierarchy which does not know what the sub-core is.

 

I don't really understand how you worked it around, you actually packaged the IP in this state, used it in a design and expected the undefined reference to resolve?
I don't like leaving the IP with an undefined reference because that means you cannot run a simulation in the IP-packager

G.W.,
NIST - Time Frequency metrology
0 Kudos
Contributor
Contributor
8,280 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres

 

Yes, that is exactly my problem.  If you package it and then use it in another projects it should resolve (given the appropriate search paths for IP repositories) but, as you said, you can't simulate via your original project.

 

I feel like I have to be missing a step in how to use a sub-core, but honestly, it seems the documentation on properly using sub-core references is pretty minimal.  I was hoping that Xilinx would have some more pointers.

DornerWorks
https://goo.gl/8wtknW
8,082 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project

@corrin.meyer,

 

have you inquired about packaging the sub-core as a "library core"?

if you have a look at lab3 from http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_2/ug1119-vivado-creating-packaging-ip-tutorial.pdf the custom IP they are creating uses "axi_lite_ip_if" to handle the AXI data bus. axi_lite_ip_if is packaged a as "library-core". When packaging the new IP, axi_lite_ip_if is referenced as a subcore.

If you download the tutorial source files, you can see in lab3/axi_gpio.vhd they include:

 

library axi_lite_ipif_v1_01_a;

which is then used with

 

data_bus_handler: entity axi_lite_ipif_v1_01_a.axi_lite_ipif
generic map( 
   [...]
) port map (
   [...]
);

I tried to do the same thing in my own case scenario: a triple port multiplier using a dual port multiplier previously packaged. I would like to make my libraries more robust where complex IPs call simple IPs (dedicated functions), this way I would avoid rewriting the same thing over and over again, plus it could by highly parametrized. The best result I have had so far is the project knows what "dual_port_multiplier_v1_00" is, but I still cannot instanciate the object properly

G.W.,
NIST - Time Frequency metrology
8,056 Views
Registered: ‎12-30-2015

Re: Resolve Sub-Core Reference in Packaged IP Project

I've come across the same issue as above when trying to use Library Cores as Sub-Core References.

 

I've been attempting to call out the Library in my but no luck so far.

 

i.e.

 

library ip;
use ip.<my_sub_core_ip>;
0 Kudos
8,044 Views
Registered: ‎12-30-2015

Re: Resolve Sub-Core Reference in Packaged IP Project

Ok I think I got it! At least I have it working for a custom Library Core/Sub-Core Reference.

 

What I did was create a Library Core ("my_lib_core") using the above "Package Directory" flow. I then added that as a subcore reference to my custom ip ("my_ip").

 

Now in the top for my_ip I has to include the sub-core library

 

library my_lib_core;

Then you don't declare the component but use the "entity" call type when you instantiate it.

 

my_lib_core_inst : entity my_lib_core.my_lib_core

It now gets recognized properly in the hierarchy view and gets pulled in for simulation.

 

 

You should be able to do this the same for non custom Sub-Core References also. Though in the past I found that I just included the core container in my IP.

 

I'd imagine you can do this the same for any Xilinx IP.

 

8,041 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project

haha awesome @christopher.jamieson I also got it working on my side I was just about to tell you guys!

 

I followed the exact same path

G.W.,
NIST - Time Frequency metrology
0 Kudos
8,038 Views
Registered: ‎12-30-2015

Re: Resolve Sub-Core Reference in Packaged IP Project

Thanks for pointing me in the right direction. Your clue was the missing piece.
0 Kudos
Contributor
Contributor
8,036 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres and @christopher.jamieson

 

I have actually packaged custom HDL as a library and have successfully used it in a CIP.  It is a little complicated to explain my entire current workflow.  I am developing a project template for use at my company and I might be able to get it up on GitHub, but it isn't their yet.

 

As an example I would have my CIP at "modules/my_cip/component.xml" with sources located at "modules/my_cip/src".  I would then have a project that I use for synthesis and implementation evaluation located at "modules/my_cip/work/top_prj/my_cip.xpr".  An IP library would be located at "modules/my_lib/component.xml" with the library sources located at "modules/my_lib/src".

 

If 'my_cip' makes use of 'my_lib', then "modules/my_cip/work/top_prj/my_cip.xpr" would include as remote sources both the sources from "modules/my_cip/src" and "modules/my_lib/src", making sure to compile each source to the appropriate library.

 

When I get read to package "my_cip", I would open the "modules/my_cip/work/top_prj/my_cip.xpr" project and then choose "Tools -> Create and Package IP" and choose to package a specified directory (don't package the current project) and select the "modules/my_cip" directory.  This will create a temporary project whose sole purpose is to package "my_cip".  If the HDL library "my_lib" is not already packaged, then from this temporary project you can select "Tools -> Create and Package IP" and choose to package a specified directory "modules/my_lib".  When packaging "my_lib", make sure to specify the library that the library sources should compile to.

 

Once "my_lib" is packaged, you can close its packaging project.  Return to the packaging project for "my_cip" and under the "File Groups" section of the packaging tab, right click on "Synthesis" and select "Add Sub-Core Reference..." and select "my_lib".  Then package the IP and close the packaging project.

 

In all cases, to see IP to be added as a sub-core reference you will need to make sure that "modules/" is added to the list of IP repositories.

 

DornerWorks
https://goo.gl/8wtknW
0 Kudos
8,021 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project

@christopher.jamieson,

 

I am still not certain whether the IP we want to refer to as a subcore has to be packaged as a "library core" or not. I don't really like that option because you cannot use it in a block-diagram, it is hidden in the IP catalog.

 

I resolve the undefined reference by adding the subcore reference in file tab, then pressing "package", then by closing & re-opening the project. At that time the reference was resolved & the relevant files were added to the project.

 

You can see in the "library" tabs that "my_library_core" was added as a library. that is why Vivado understands the line

my_instance: entity my_library_core.my_library_core

I tried to do so without packaging my_library_core as a library-core, but as a regular IP. When I did the same thing, the files were added into the project but not within another library, they were added into the "work" library.

to use them I had to do:

 

my_instance: entity xil_defaultlib.my_library_core

questions:

  1. have you tried not packaging my_library_core as a library_core?
  2. do you tweak things a little in the "library" tab (right next to the "file" tab, in the file hierarchy).

 

 

 

G.W.,
NIST - Time Frequency metrology
0 Kudos
7,985 Views
Registered: ‎12-30-2015

Re: Resolve Sub-Core Reference in Packaged IP Project

@corrin.meyer That sounds like basically the same flow that I have.

 

The part I was missing until yesterday was once you have "my_lib" packaged as a Library Core and referenced as a Sub-Core Reference in "my_cip" you also have to call it in a specific way in the top file of "my_cip" for the simulation to pick it up correctly.

 

library my_lib

You do not declare it as a component, then when you instantiate it:

 

my_lib_inst : entity my_lib.my_lib

This will have it picked up in the sim of your "my_cip" project.

0 Kudos
7,982 Views
Registered: ‎12-30-2015

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres

 

I have not tried it as a non Library Core. I have a set of not to be used in the block diagram common blocks that I've made into Library Cores. The rest of my to be used in the Block Diagram IPs are regular Custom IPs. Like the OP my problem was when I wanted to simulate a Custom IP that included a Sub-Core Reference to a Library Core, it wouldn't pick up the Sub-Core properly. The instantiation changes fixed this.

 

So for your questions:

  1. I have tried leaving it as a module, and Vivado seems to mess up when the module is located outside of the custom IPs directory. Thus I had to go to Library Cores.
  2. I did not tweak anything in the library tab. In fact I didn't know it was there. Looking now that would have saved me some serious trial and error yesterday when trying to figure out how to link to my Library Core.

 

 

As far as I aware you can just add regular IP as a source file. It will create an .xcix file in /src/ of your Custom IP (if you have core containers turned on). This .xcix file is the customization for the regular IP from your IP Library. I've never had to add it as a Sub-Core Reference this way.

 

That being said, it's totally possible I'm not doing it in the intended Xilinx way, but it seems to work.

 

0 Kudos
Contributor
Contributor
7,981 Views
Registered: ‎02-27-2016

Re: Resolve Sub-Core Reference in Packaged IP Project

@guillaumebres

 

It is possible to use both Library and Non-Library IP as sub-core references.

 

If you are packaging HDL meant to be instantiated only as part of another IP, or it is a collection of processes or modules to be used by another IP, then you would package the HDL as a library.

 

When packaging IP you do want to tweak the "library" field in the "file" tab.  This will help make sure that modules with common names don't stomp on each other.

 

@christopher.jamieson

 

That is one way to pick it up.

 

I think it is also possible to add a component declaration in your simulation for "my_lib.my_lib", or, include a package "my_lib_pkg" to be packaged with "my_lib" that declares the component for "my_lib.my_lib" and then in your simulation add "use my_lib.my_lib_pkg.all".

DornerWorks
https://goo.gl/8wtknW
0 Kudos
7,962 Views
Registered: ‎03-27-2014

Re: Resolve Sub-Core Reference in Packaged IP Project


@corrin.meyer wrote:

It is possible to use both Library and Non-Library IP as sub-core references.


I confirm it works, that is the way I do it now


@corrin.meyer wrote:

If you are packaging HDL meant to be instantiated only as part of another IP, or it is a collection of processes or modules to be used by another IP, then you would package the HDL as a library.


you are right, I have really few cases where that is really true, I want most of my IPs available in the catalog

G.W.,
NIST - Time Frequency metrology
0 Kudos