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 ronnywebers
Scholar
9,295 Views
Registered: ‎10-10-2014

(re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

UG1119 (Creating and Packaging Custom IP) lab 1 shows how to package a custom ip project into a v1.0 custom IP package.

 

What I am missing is best practice guidance on the following :

 

once the IP was packaged with a v1.0, how do you update the IP to a v1.1, but keep both versions around (i.e. when different versions of the IP are referenced by different projects, and it's not possible to update all the projects to the latest IP (because it was already rolled-out in the field).

 

Q1: do you re-package each time into a different (IP) destination folder? so each version of the custom IP gets it's own folder? I tried using the 'create archive option', which creates .zip files for each version, that kind of keeps around all the versions, but in a project where you use the IP, Vivado always wants to update the ip to the latest version.

 

UG1198 (Revision Control Systems) lab 3 shows how to manage a custom IP  under revision control. Starting from sources, constraints, a script and a makefile it creates and packages a custom IP. The output folder is then copied to some central library folder, and put under git revision control.

 

Q2: What I'm missing is how to keep the 'development project' that you used to develop and simulate the custom IP with also under version control, and closely related to the IP, in case I decide later to add some features to the IP. So it's nice that lab 3 shows how to package a custom IP, but I'm missing guidance on how to manage the related development project for that IP. Most of the time such IP is iteratively developed, and might be extended with features much later on. In that case it would be good to have the development project still around, in version control.

 

Q3: how would I combine Q1 and Q2? in other words, I want to keep multiple versions of a custom IP available for different projects, as well as the different versions of the development project, all under git control. Is there anything more in depth guidance available?

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
7 Replies
Moderator
Moderator
8,764 Views
Registered: ‎06-24-2015

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

Hi @ronnywebers,

 

Can you see if this XAPP helps: http://www.xilinx.com/support/documentation/application_notes/xapp1165.pdf

Thanks,
Nupur
--------------------------------------------------------------------------------------------
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 (click on the 'thumbs-up' button).
0 Kudos
Contributor
Contributor
1,184 Views
Registered: ‎06-07-2012

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

Hi Nupur,

 

I have mostly the same question as ronnywebers, but checked XAPP1165 and the question remains unanswered.

 

I have a custom IP version 1.0: xyz_1.0(rev. 13) .  Now I want to modify the IP a little bit and it will become incompatible with the version 1.0, so I want to copy the rev 1.0 and change its number to 1.1 or 2.0.  I want to the 1.0 version to stay in the local repository and add the new 2.0 version so that old project with block-design that call the 1.0 version can still call it and new project can use the new version.

 

So what I actually need is to copy the IP content into a new IP and renumber it.  If I edit the IP in ip-packager, it would overwrite the current directory and make the 1.0 version unavailable in the future.

 

If I copy the directory changing the name to xyx_1.1, the IP catalog complains of course that the same ip is duplicated in 2 directory. That's not good.

 

If I edit the IP in the IP-Packager and change the version number, I can then rename de IP directory to _v1.1.  However, only the component.xml is changed.  All the other _v1.0 in that were generated automatically in the file names and entity name when I first created the custom IP form the wizard all stay at _v1.0 instead of being updated to _v1.1 that I punched in the IP packager identification section.

 

Shouldn't there be a better way of doing this?

 

Thank you,

 

jf

0 Kudos
Xilinx Employee
Xilinx Employee
1,173 Views
Registered: ‎07-22-2008

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

Two things I can think of that might help.

- Keep the original project or directory that is being packaged, Put the location of the created IP in a separate directory location.  Then, instead of editing the packaged IP, edit  and package the original project again to create a new repo separate from the first.

 

- If you edit the packaged IP select the option in the IP packager settings to create an archive when you package.  If you consistently do this you will have an archive of every version of the IP.  You can unarchive the these all to parallel directories based on the archive name and then point to the parent directory as an IP repository.

0 Kudos
Highlighted
Scholar ronnywebers
Scholar
1,144 Views
Registered: ‎10-10-2014

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

since a while I use (git) version control for my custom IP, I tag my 'release' commits, and in my project script I do a checkout using the version tag. I check out my IP per project, not in a central repository that is shared amongst projects, because that indeed requires different/parallel folder names per version. It's what you prefer I think.

 

here's another post of me where we discuss the version numbering and corresponding file names

 

then to iteratively develop my custom IP, (re)simulate it, re-package it, ...  , I'm using a method that I discovered in a paper somewhere and fine-tuned, and so far it works fine for my situation. I documented it here. Though I'm still hoping someone from Xilinx reviews this method, and corrects it / improves it. 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Contributor
Contributor
1,131 Views
Registered: ‎06-07-2012

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

Hi,

 

I read with great interest you other post on version numbering.  It summarizes the issue with great detail.

 

On my side, I edited the IP and rename de directory, then I searched and replaced all the _v1_0 from all the .VHDL files to make a version-less source code.

 

That way, I can compare multiple versions by just comparing directories.  I don't get mismatched number (ie IP version 1.3 with entity name _v1_0) and I can keep  multiple versions of the IP in the central repository which can be called by block design creation scripts from many project, each calling the right version by its number.  If I start editing an old project, I can then upgrade the IP to the newer version provided it make sense. If I just regenerate the project, it continues to work in a legacy way.

 

I just wished Xilinx did one of the following:

A)When generating a new IP from scratch, it  wish the tool wouldn't put the version number everywhere in the source. It only has to be on the main directory name and into the version number field of in the component.xml file.

B)When editing IP, in the IP packager, if the user changes the IP version in the dialog box, let's say from 1.0 to 1.1, I wish the Packager would be smart enough to search for all the v1_0 in the source code (and file name) and replace it for 1.1 since I explicitely asked for that change in the dialog box.

 

Stripping all the version number gives me A) without too much work...

 

Best Regards,

 

jf

Scholar ronnywebers
Scholar
1,098 Views
Registered: ‎10-10-2014

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

yes I put a lot of detail in that post, unfortunately, no one from Xilinx picked this up - maybe @howardp or @nupurs could have a look at that post.

 

Also if you both would be so kind to take a look at my method of iteratively developing custom IP, and keeping a development & simulation project around with multiple simulation sets, waveform config files, ... around works rather fine.

 

UG1198 only shows a scripted way of 'version controlling' your custom IP. But it doesn't show how you could keep a development project around with simulation sets, etc. as I do in a 'GUI' kind of way. Or would it be better to do this in a scripted way?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Xilinx Employee
Xilinx Employee
1,081 Views
Registered: ‎07-22-2008

Re: (re)packaging Custom IP and keeping multiple versions around (UG1119 and UG1198)

@ronnywebers,

 

What I would suggest is method 1.  However, instead of repackaging the entire project each time, just open the IP-XACT file (component.xml), integrate the changes that have been made and repackage.  This is essentially what you are doing with method 2 except you are creating and saving a new version of the project and saving it to a new location.

 

In your write-up you stated something to the effect that most users edit their IP by using the "Edit in IP Packager" option.  This may be true but is unfortunate as that option is only there to support users who do not have the original IP project and source files to edit.  We have added some messaging to Vivado 2018.1 and will continue to try to make this more clear.

 

In the end, either method will work.  The biggest problem with the Edit in IP packer flow for users who have the original source files, is users realizing that there is a new project and the source files are in a new location.  Then they update a file that they think will be packaged and it is not pulled in, or the file in the original location is not updated as they expect.  It seems like you have a good handle on where the files are that are getting updated so I believe you will be fine using the method you are currently using.

0 Kudos