cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
yuzuki
Visitor
Visitor
1,898 Views
Registered: ‎09-02-2016

IP packager inserts parent directories (../../../../) into relative paths (Vivado 2018.2)

Jump to solution

Greetings.

When packaging a project in Vivado 2018.2, the packager inserts as much parent directories as possible into the path.

For example, i have a repo at C:\Projects\Project100500\ip_repo, and an IP called my_ip. When the packager generates component.xml, it adds files with a path like this :

 

<spirit:name>../../../../Projects/Project100500/ip_repo/my_ip/hdl/my_ip_main.vhdl</spirit:name>
 
instead of simple
 
<spirit:name>hdl/my_ip_main.vhdl</spirit:name>
 
like 2017.2 did.
 
This have a side effect of duplicating this path in .srcs directory of the project that uses the core. It works when the core is used at first. The problem arises when you need to change the core and upgrade it to a newer version. As my experiments show, one have to either manually remove extra from relative paths in component.xml , or manually delete a copy of the core inside the duplicated path in .srcs to proceed.
 
Is there a way to revert the packager to its previous behaviour, keeping the relative paths simple? Or maybe i'm missing something here?
0 Kudos
1 Solution

Accepted Solutions
scott_shultis
Visitor
Visitor
1,872 Views
Registered: ‎11-07-2017

I also have seen this problem.  Maybe this will help you recreate it.  Every IP I build this way has exhibits this problem.  I've done it four of five times so repeatability is really high.  I store my original source remotely from the project.  It is not clear from other posts if this is a common thread or not.

 

I'm building a project using source IP developed for reuse in multiple projects.  The source is distributed across multiple folders, and remotely to the project.  I start with a project specifically for the IP I am packaging, and select "copy to project directory" to make the source local to the new IP project I'm creating.  The project and source are basically at the same level in the directory structure.

 

I package the IP, and the tool creates the temp. project at a location, outside of the original project. (see v2018.2 UG1118 pg 31).

 

If files are stored remotely from the project source directory, the IP location is

determined based upon where the majority of project files are relatively located.

 

The paths for the temp. project become: ../../hard/path/(central location for project/source code).  Again, this is relative to the original source, and the fact I have copied all source into the project does not matter!

 

All the paths in the component.xml are described by the central point determined by temp. projects creation: ../../hard/path

 

The archive of the project is as shown, the file path for the source in the zipped archive uses the same path as the component.xml uses.  So what I'm saying is the archive starts at a relative path of ../, then a sub-directory ../, then sub-directory hard/ etc.  It looks like the component.xml path is recreated/copied in the IP archive. 

 

Based on what I'm seeing, if the source is local to the project, everything may work out just fine.  Remote storage may corrupt  how the newest version of the tool creates the paths.

View solution in original post

Capture.PNG
4 Replies
prathikm
Moderator
Moderator
1,839 Views
Registered: ‎09-15-2016

Hi @yuzuki,

 

I did notice your observation on packager source file paths in both tools and tried two things: Created a custom IP in 2018.2 and used it in same tool (new BD project). Also created a custom IP in 2017.2 and used it in 2018.2 (BD) with other logic after upgrading the IP.

After packaging the IP, in new project I just added the repo path and IP in BD and it is validated and also synthesized without issues in both cases. But it depends on what is being packaged and how it's being used.

Is there a test example you can share to point out the problem with relative paths? For me, archiving the project worked in both cases, where the repo path was indeed inside the .srcs/sources_1/<folder> for the custom IP.

Thanks

Prathik

-----------------------------------------------------------------------------------

Don't forget to reply, kudo, and mark the appropriate post as 'accept as solution'.

-----------------------------------------------------------------------------------

0 Kudos
scott_shultis
Visitor
Visitor
1,873 Views
Registered: ‎11-07-2017

I also have seen this problem.  Maybe this will help you recreate it.  Every IP I build this way has exhibits this problem.  I've done it four of five times so repeatability is really high.  I store my original source remotely from the project.  It is not clear from other posts if this is a common thread or not.

 

I'm building a project using source IP developed for reuse in multiple projects.  The source is distributed across multiple folders, and remotely to the project.  I start with a project specifically for the IP I am packaging, and select "copy to project directory" to make the source local to the new IP project I'm creating.  The project and source are basically at the same level in the directory structure.

 

I package the IP, and the tool creates the temp. project at a location, outside of the original project. (see v2018.2 UG1118 pg 31).

 

If files are stored remotely from the project source directory, the IP location is

determined based upon where the majority of project files are relatively located.

 

The paths for the temp. project become: ../../hard/path/(central location for project/source code).  Again, this is relative to the original source, and the fact I have copied all source into the project does not matter!

 

All the paths in the component.xml are described by the central point determined by temp. projects creation: ../../hard/path

 

The archive of the project is as shown, the file path for the source in the zipped archive uses the same path as the component.xml uses.  So what I'm saying is the archive starts at a relative path of ../, then a sub-directory ../, then sub-directory hard/ etc.  It looks like the component.xml path is recreated/copied in the IP archive. 

 

Based on what I'm seeing, if the source is local to the project, everything may work out just fine.  Remote storage may corrupt  how the newest version of the tool creates the paths.

View solution in original post

Capture.PNG
yuzuki
Visitor
Visitor
1,796 Views
Registered: ‎09-02-2016

Thanks for all your answers, it helped me (kinda). It appears that while optimizing vivado for my own case i stranded away from the recommended process, and now the tools do not support directly what i want.

 

I always created and edited IPs as an independent projects, never using "edit in ip packager" option, because that option tended to eat every resource available and hang my system within minutes. It's probably fixed now.

So as Scott said, current Vivado release misbehaves in this case, trying to find whatever top path available to include all the cores, and somehow screwing up and choosing drive root instead, leading to the effects described.

 

I tried to recreate the problem using the recommended path, and the generator tool didn't even created a .xpr project for the IP, so i had to either use "edit in ip packager" option (which i did, and there were no side effects), or create the project manually (like i did before).

 

Thanks for clearing things up, now i suppose i will switch back to the recommended flow, provided it won't conflict too much with the version control.

0 Kudos
1,087 Views
Registered: ‎04-16-2019

I found this problem as well.  It turns out that it's a "capital letter" problem on the vivado Ip packager default path.  When packaging up a project using the ip packager window, Vivado starts out with all lower case letters in the calculated path.  Then when it passes this path onward to grab the sources.  The "souce file grabber" doesn't find the path because it does a case sensitive search.  So for instance, let's say your root xilinx project directory is:

C:\myproj\Firmware\Fpga\IpCoreProj

Vivado's default ip packager path is c:\myproj\firmware\fpga\ipcoreproj.  Then the tool will look for the sources here, but IpCoreProj isn't ipcoreproj because of the case issue, so it continues upward until it finds the first all lower case path.  Then travels back down to the sources.

 

 

0 Kudos