cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dstorrar
Visitor
Visitor
679 Views
Registered: ‎01-29-2020

Edit Packaged IP: how should it work?

Jump to solution

I'm relatively new to using Vivado, but have been doing ASIC design for 20+ years.  I'm finding it impossible to get Vivado to do what I want with custom IP.

Here's what I'm trying to do:

  • Create a re-usable AXI block (AXI-Lite slave for register programming; AXI-Stream slave for incoming data; AXI4 master for processed data to memory)
  • Use the block in different projects and/or multiple instances in a block-design
  • Have a single master set of files for the IP, under Git revision control
  • Have a single IP repository containing packaged IP of multiple IPs.  Also under Git revision control
  • When the IP block at release quality - create a new IP release into the repository (maybe replacing the current one, maybe creating a new major release).

Here's what I've done for the IP block:

  • Files are created according to revision control recommendation in UG892 Ch5
    • All sources (HDL, constraints, block-designs, testbench) are external (remote) from the Vivado project.
    • All sources are under revision control: ip_design/<ip_name>/hdl,constraints,etc.
    • A working-directory is used for the Vivado project, and only the XPR file is under revision control: ip_design/<ip_name>/work/<ip_name>.xpr
  • Next, the Package IP wizard is run
    • The output directory is set to ip_repo/<ip_name> and a temporary project pops up, as expected.
    • I make changes in the various packaging steps (document parameters, tweak ports etc.)
    • I package the IP, and all the sources are copied to ip_repo/<ip_name>/src and the IP-XACT file appears in ip_repo/<ip_name>/component.xml
    • The temporary project is closed, and I'm back in the original IP design project, but the XML file (from ip_repo) has now appeared in the design sources as an IP-XACT file. 

Everything looks great so far, but here's the problem.  I now want to do a new IP release (to fix a bug, or add a feature - whatever), so I want to re-package the block. Seems straightforward - click "Edit Packaged IP" in the flow navigator right?

  •  Package IP window opens, some steps are now un-ticked (but the file-groups are unchanged and show the green-tick)
  • I choose an un-ticked step and click on the "Merge changes" banner at the top
  • Now my File Groups are showing a warning.  Which is because the packager has now added all the ip_design files in, as well as the existing ones from ip_repo.  So I've got a bunch of duplicate files

Before Merge:

Before MergeBefore Merge

After Merge:

IP_packager_after.PNG

 

 

 

 

So, is this expected behaviour?  What's the point of the "Edit Packaged IP" function in that case - it seems broken to me.  What is the recommended way to update an IP?

I suppose I could re-run the Package IP wizard, but then I have to go through all the manual changes to the packaging steps again (adding descriptions and range limits to the parameters, etc.) - which is super tedious.  Anyone got any suggestions?

Cheers
Dave

 

0 Kudos
1 Solution

Accepted Solutions
dstorrar
Visitor
Visitor
546 Views
Registered: ‎01-29-2020

Hi @marcb 

Thanks for the reply, appreciate it.

My point about the second image is that it wasn't me that added the duplicates - it was the act of choosing the "Merge changes from..." link at the top of the the Customization Parameters step in the packager that added those files.

I've since had a more comprehensive examination of the IP Packaging flow, and I'm beginning to see how it works, although I don't necessarily like it.

When packaging to a remote location, the component.xml that is added back into the source project is useless (created by the "ipx::move_temp_component_back" in the TCL log) - it enables the "Edit Packaged IP" link in the Project Manager, but doing edits that way just doesn't work (duplicate files).

As I see it I have two choices:

  1. Run the IP Packager with the default output location (inside my project).  After packaging, copy the sources and resulting component.xml to my shared IP repository (maintaining the relative location of the sources and the component.xml).
  2. Run the IP Packager with an output path set to my shared IP repository. The packager copies all my source files and creates the component.xml in the repo. 

With option-1 all the packaging steps (parameter names, limits, interface allocation etc) are held in the project component.xml. So when I want to make changes and re-package, then I can just choose "Edit Packaged IP" from the Project Manager group in the Flow Navigator and re-package.  Then I repeat the copy step.

Option-2 is what I described in my original posting, and with this flow the source project is redundant as soon as the IP Packaging is run the first time.  All further changes to the IP are performed from the IP Catalog using the "Edit IP in Packager" right-click menu item.  The remote packaged IP is then the master.

I think I'm going for option-1 - it fits better with the way I prefer to develop an IP.  Happy to hear other recommendations though!

Dave

View solution in original post

4 Replies
marcb
Moderator
Moderator
613 Views
Registered: ‎05-08-2012

Hi @dstorrar 

I see the last image has file paths prepended with "../../". This could cause duplicate files. Within the top-level project that uses the packaged IP, Vivado at most can delete files that are one level away from the XML file or "../". Where ever the packaged project resides, the sources are expected to reside within the same directory as the XML.

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
dstorrar
Visitor
Visitor
547 Views
Registered: ‎01-29-2020

Hi @marcb 

Thanks for the reply, appreciate it.

My point about the second image is that it wasn't me that added the duplicates - it was the act of choosing the "Merge changes from..." link at the top of the the Customization Parameters step in the packager that added those files.

I've since had a more comprehensive examination of the IP Packaging flow, and I'm beginning to see how it works, although I don't necessarily like it.

When packaging to a remote location, the component.xml that is added back into the source project is useless (created by the "ipx::move_temp_component_back" in the TCL log) - it enables the "Edit Packaged IP" link in the Project Manager, but doing edits that way just doesn't work (duplicate files).

As I see it I have two choices:

  1. Run the IP Packager with the default output location (inside my project).  After packaging, copy the sources and resulting component.xml to my shared IP repository (maintaining the relative location of the sources and the component.xml).
  2. Run the IP Packager with an output path set to my shared IP repository. The packager copies all my source files and creates the component.xml in the repo. 

With option-1 all the packaging steps (parameter names, limits, interface allocation etc) are held in the project component.xml. So when I want to make changes and re-package, then I can just choose "Edit Packaged IP" from the Project Manager group in the Flow Navigator and re-package.  Then I repeat the copy step.

Option-2 is what I described in my original posting, and with this flow the source project is redundant as soon as the IP Packaging is run the first time.  All further changes to the IP are performed from the IP Catalog using the "Edit IP in Packager" right-click menu item.  The remote packaged IP is then the master.

I think I'm going for option-1 - it fits better with the way I prefer to develop an IP.  Happy to hear other recommendations though!

Dave

View solution in original post

dstorrar
Visitor
Visitor
496 Views
Registered: ‎01-29-2020
In the absence of any other ideas, I'm accepting my own answer as the solution :$
0 Kudos
pkinzer
Observer
Observer
457 Views
Registered: ‎10-07-2019

Here's how we do re-usable AXI IP (Lite, Slave&Master) with Vivado (2019.2), which has been working well with version control (TFS - we're not at git yet).  All of our IP blocks are in subfolders outside of the VIvado project hierarchy, but in the same repository - Let's call it "IP_BLOCKS".  Each IP has a subfolder (IP_BLOCKS/Block_1), with a src folder under that for the VHDL.  We create the AXI interface using Xilinx's port naming convention (s_axi_aclk, s_axi_aresetn, etc.), so the IP Packager picks up the axi interface automatically.  We select "Package a specified directory", add in any additional source files under "Standard/Synthesis", manually change the type to "vhdlSource-2008" (Undocumented, and Vivado fails to do this automatically).

This creates a component.xml in IP_BLOCKS\Block_1, and a tcl script in IP_BLOCKS\Block_1\xgui - both are needed.  This folder is the one we sync with version control, so no copies (yet).

In Vivado project settings, we add IP_BLOCKS to the "IP Repositories", so they show up in the IP Catalog.

Each Vivado project will copy source into it's project, buried in ProjectName.ip_user_files, ProjectName.cache, ProjectName.srcs, but those are temporary - deleting those folders will guarantee a fresh build if needed - Vivado doesn't always pick up changes to the source in IP_BLOCKS.

The only files we version control from Vivado are the .XPR, a .TCL to re-create the Block Diagram, top level .XDC files, and a top-level VHDL file that defines our pins and instantiates the block diagram.

If we modify IP_BLOCKS/Block_1, IP Packager modifies the component.xml and xgui .tcl in place, no copies.

Hope this helps,

-Paul

0 Kudos