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: 
Scholar mistercoffee
Scholar
5,738 Views
Registered: ‎04-04-2014

Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

Hi,

 

I am now using Vivado 2017.2 I am trying to adapt my old project flow to the new recommended Vivado flow and have encountered a problem. 

 

I have two projects that have a set of common IP. The two projects are targeted towards different parts, Kintex-160 and Kintex-325. My previous design flow would have a manage IP repository, with each IP pre-synthesized and imported into each project as it was used. New Vivado doesn't like this so I need a new IP flow.

 

Here is my thought process:

- I don't want to have a duplicated IP repository, one for each target part. If I make a change to any IP I need to be really careful that I mirror the change exactly to the other repository as they don't share a common xci.

- I could import the IP unsynthesized and synthesize the IP globally as part of each project run. This will considerably increase build time and also mean I can't follow the recommended revision control flow that says I should manage the entire IP folder structure and generated files. This is because the target files will change depending on which target part is used to synthesize the IP.

 

Is there a third way I am unaware of. How can I easily manage this situation? Is there a way to generate two sets of target files, one for each target part, when I work with IP in my IP repository? And then only use the relevant set of files when I import the xci into each project?

 

Thanks

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
Guide avrumw
Guide
9,549 Views
Registered: ‎01-23-2009

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

You can't have your cake and eat it too...

 

A synthesized IP is synthesized to a particular target device and is locked to that device. If you want to use it for different devices, then you have to synthesize it for different devices. One way or another this means two different IP directories - one for each project.

 

However, it is possible to do this from a single "source", and not have to manually maintain two copies of the IP (one for each device). Even before the .xci file, an IP is generated by a set of Tcl commands. The IP is created with the create_ip command, it is configured using the set_property <PROPERTY> <VALUE> [get_ips <ip_name>] and is generated with the generate_target command. Assuming you are running in a scripted mode, these commands can be added to your script to generate the IP. The IP will be generated for the current device, so the Tcl commands do not need to be altered for each device - you could put the commands in a .tcl script and source it in both projects. The Tcl commands to generate an IP show up in the console whenever you generate an IP from the IP catalog - you can cut the commands from there and paste them into a Tcl script for use the next time.

 

However, this means that the IP is being built (and ultimately synthesized) for both targets. You will incur the run time penalty of synthesizing the IP each time you build either project.

 

Avrum

View solution in original post

9 Replies
Guide avrumw
Guide
9,550 Views
Registered: ‎01-23-2009

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

You can't have your cake and eat it too...

 

A synthesized IP is synthesized to a particular target device and is locked to that device. If you want to use it for different devices, then you have to synthesize it for different devices. One way or another this means two different IP directories - one for each project.

 

However, it is possible to do this from a single "source", and not have to manually maintain two copies of the IP (one for each device). Even before the .xci file, an IP is generated by a set of Tcl commands. The IP is created with the create_ip command, it is configured using the set_property <PROPERTY> <VALUE> [get_ips <ip_name>] and is generated with the generate_target command. Assuming you are running in a scripted mode, these commands can be added to your script to generate the IP. The IP will be generated for the current device, so the Tcl commands do not need to be altered for each device - you could put the commands in a .tcl script and source it in both projects. The Tcl commands to generate an IP show up in the console whenever you generate an IP from the IP catalog - you can cut the commands from there and paste them into a Tcl script for use the next time.

 

However, this means that the IP is being built (and ultimately synthesized) for both targets. You will incur the run time penalty of synthesizing the IP each time you build either project.

 

Avrum

View solution in original post

Scholar mistercoffee
Scholar
5,721 Views
Registered: ‎04-04-2014

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

Thanks for the reply avrumw. I suppose it is a bit have your cake and eat it, but it does feel a bit restrictive to have an IP repository that can only be used with one device. It kind of defeats the object of design reuse, but then if the parts are massively different (not my case) then I can see that the IP would have to be configured differently anyway.

 

Ok, so I can use a Tcl script instead as my IP "source", instead of the xci (which is obviously target independent)? Then source the Tcl script in my larger project, which will create local copies of the IP, synthesized for the current target device? Ok, I can see this would work. I guess then I can't use my managed IP project and GUI to configure the IP as I have to specify the IP in Tcl. It's not ideal but I suppose it work.

 

It is also a shame that I would have to synthesize as part of my larger run. There is another way I suppose....I could have a revision controlled directory of IP Tcl scripts. I could then have two IP repositories, one for each target part that reads in each IP Tcl script and synthesizes locally to the repository. I could then import the relevant synthesized IP (xci) into my larger run?

 

 

 

 

Guide avrumw
Guide
5,712 Views
Registered: ‎01-23-2009

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

Ok, so I can use a Tcl script instead as my IP "source", instead of the xci (which is obviously target independent)?

 

Just to make sure the wording is clear. The XCI is target dependent - the Tcl commands are target independent.

 

It is also a shame that I would have to synthesize as part of my larger run. There is another way I suppose....I could have a revision controlled directory of IP Tcl scripts. I could then have two IP repositories, one for each target part that reads in each IP Tcl script and synthesizes locally to the repository. I could then import the relevant synthesized IP (xci) into my larger run?

 

Yes, this sounds like it would work.

 

Avrum

0 Kudos
Scholar mistercoffee
Scholar
5,709 Views
Registered: ‎04-04-2014

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

I'm going to give this a go. The major pain right now is that there isn't an IP equivalent of write_project_tcl or write_bd_tcl. As you suggest, I literally have to copy the Tcl commands out of the console, into my script. If I'm creating a brand new IP this isn't much work. But right now I have a repository of around 20 IPs that I need to convert to Tcl. To do this I need to create a brand new IP, with all the same settings as the old one that already exists, in order for the console to give me the commands that will reproduce it. Annoying!

 

But, thanks for your input...

Scholar mistercoffee
Scholar
5,707 Views
Registered: ‎04-04-2014

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

@avrumw wrote:

 

Just to make sure the wording is clear. The XCI is target dependent - the Tcl commands are target independent.

  


Yep, you're right and I did understand but my wording was far from clear there. 

Highlighted
Guide avrumw
Guide
5,695 Views
Registered: ‎01-23-2009

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

To do this I need to create a brand new IP, with all the same settings as the old one that already exists, in order for the console to give me the commands that will reproduce it. Annoying!

 

Hmmm... Tricky...

 

Yes, the "best" way is to re-build all the IP from the wizard, but there might be another way...

 

All the configuration of the IP end up being properties of the IP. You can do something like

 

report_property [get_ips <ip_name>]

 

all the "CONFIG.*" properties are what actually configure the IP. In theory if you extract all of these, you can put them into your script. But the "real" ones generated by the wizard, only set the properties that are different than the IP defaults. This is generally a much smaller list.

 

In theory, you could just use the full list, but that makes it less likely that the same commands will be able to work on a future version of the IP - the name and number of CONFIG properties can change from version to version. Conversely, listing them all prevents the possibility of you ending up with a different configuration if a future version changes the default value of one of the parameters (but I don't think I have ever seen that happen).

 

Avrum

Tags (2)
Scholar mistercoffee
Scholar
5,685 Views
Registered: ‎04-04-2014

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

@avrumw wrote:

 


In theory, you could just use the full list, but that makes it less likely that the same commands will be able to work on a future version of the IP - the name and number of CONFIG properties can change from version to version. Conversely, listing them all prevents the possibility of you ending up with a different configuration if a future version changes the default value of one of the parameters (but I don't think I have ever seen that happen).

 

Avrum


Yes, well it seems neither way is perfect. We did wonder whether the default properties would change form version to version and therefore mask important changes to the behaviour of the IP. However, the create_ip command does include a version number when you create it. This at least stops you from creating the new IP without knowing there may be changes. 

 

I'm not quite sure what the flow then is when you want to upgrade the IP as you'd normally do this to an xci, which you then can't create. 

 

I am erring on the side of specifying all the properties using report_property...

0 Kudos
Explorer
Explorer
984 Views
Registered: ‎08-18-2011

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

Has there been any progress on this flow in the later tools?

This flow is very cumbersome and error prone

0 Kudos
Scholar mistercoffee
Scholar
971 Views
Registered: ‎04-04-2014

Re: Recommended Vivado flow for shared IP/BD library used by projects with different target parts?

Jump to solution

I will at least share what qwe have been doing for the past 2 years since I made this thread.

All our IP is now stored as a Tcl script under version control. This script is called by the project Tcl during projecxt creation/builds. It doesn't matter, for the most part, what the part is. Occasionally though it does, and we have to add a part detectino and if else condition to configure the appropriate parameters. 

You're right, it's cumbersome and error prone, but it can work, despite Xilinx. 

 

0 Kudos