cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Participant
Participant
2,404 Views
Registered: ‎09-26-2016

HDL files used in custom IP could not be updated. Advise please.

Jump to solution

Hi.

 

I have few custom IPs in a common folder (repository). Each of them has a structure generated by Vivado. HDL files are placed in a hdl folder for each IP. Then, I have few HDL files which are shared by different IPs. Those files are located in a separate folder called Library, which is also located in the repository, at the same level as folders for all other IPs. Structure of repository looks something like this:

 

- repo:

   - ip_1

   - ip_2

   - ip_3

   - library

 

These IPs are used in one Vivado project. Of course, there they are "read-only" and could not be modified (unless IP is opened with "Edit in IP-Packager"). I am editing them in external editor. If I modify HDL file which is used only by a single IP (located in hdl folder under its own structure), then those modifications are updated in Vivado. But if I make a change in a file which is located in Library folder (shared by other IPs), then those changes are not visible in Vivado. Also if I open IP with "Edit in IP-Packager" command and do this modification there (on a file originally stored in Library) and Re-Packed it, then, these changes will not be updated in a project where an IP is used.

 

The reason for that is because a project copies all IP HDL files in its own structure. My goal is to make a modification in a HDL file located in Library and this should be visible in the project where this IP is used. Also if this file is shared by 2 different IPs used in the same project (which is why I put it in a Library), both of them should be updated with this common modification.

 

Do you have any advice how to achieve that?

 

Best regards.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
2,532 Views
Registered: ‎04-26-2012

@matic  "it still requires more steps than someone would expect. But it is much better than before"

 

Yes, using the 'library core' as a  'sub-core reference' makes IPI aware of those shared files without the bad side-effects of packaging sources outside of an IP directory tree.

 

>

> This is quite OK, but is there any trick to make this process even shorter?

>

The best trick I know is to avoid using IP {dis}Integrator whenever possible  :)  

 

That said, the sub-core reference update bug is known to Xilinx, so if they ever get around to fixing it, that extra re-packaging step after editing a 'library core' would no longer be necessary.

 

-Brian

 

View solution in original post

7 Replies
Highlighted
Scholar
Scholar
2,375 Views
Registered: ‎04-26-2012

@matic  "Also if this file is shared by 2 different IPs used in the same project (which is why I put it in a Library), both of them should be updated with this common modification."

 

Use the "Package a Specified Directory => Package as a library core" option within the IP packager to package up your library directory, which makes the shared code visible to other IP as a "library core" in Xilinx terminology- see pages 38-39 of UG1118 2018.1

 

-Brian

 

p.s.

I would recommend using a more unique name than library to avoid potential language keyword conflicts.

e.g. ip_library, acme_ip_shared  or similar

 

0 Kudos
Highlighted
Moderator
Moderator
2,352 Views
Registered: ‎09-15-2016

Hi @matic,

 

Check if this (forum_link) discussion would help.

 

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

0 Kudos
Highlighted
Participant
Participant
2,341 Views
Registered: ‎09-26-2016

Thanks @brimdavis

 

If I understand you, I should create another IP only from my common HDL files. But as a package this IP has no sense, because those modules are not in a hierarchy. Am I missing something here?

 

Then, if I package such an IP (library core) I get new .xml file. What should I do next? Do I have to include that file somewhere in my project?

 

Thank you

0 Kudos
Highlighted
Participant
Participant
2,338 Views
Registered: ‎09-26-2016

Thanks @prathikm

 

I went through that link, but my "Library" files are already added with the relative path.

 

As I said, when I open custom IP with "Edit in IP Packager", do the modification there on one such file (located in "Library" folder) and then re-package it, this change will not be applied to that IP in my main project. Because the project copied all library files into its project folder:

 

project.srcs -> sources_1 -> bd -> design_1 -> Library

 

Any advice?

0 Kudos
Highlighted
Scholar
Scholar
2,319 Views
Registered: ‎04-26-2012

@matic  "But as a package this IP has no sense, because those modules are not in a hierarchy. Am I missing something here?"

 

Yes - packaging with the "library core" option makes the shared files usable by other IP within IPI.

( Like much of IP {dis}Integrator, the terminology is Xilinx-specific and confusing - calling this a "core" is a misnomer. )

 

>

> Then, if I package such an IP (library core) I get new .xml file.

> What should I do next? Do I have to include that file somewhere in my project?

>

No, you don't have to do anything special with that xml file, other than including that repository in your project.

 

>

> my "Library" files are already added with the relative path.

>

You'll need to remove these individual source files, add instead a "sub-core reference", then re-package each IP that uses the library.

 

In the IP packager, under File Groups:

  - remove the original library source files that you had added

 

  - right click on Synthesis and Simulation and select the "Add sub-core reference" option

      - from the list of IP, select the "library core" that you created earlier

 

  - If you are using VHDL, add a library clause to your IP RTL

    the library name will be the same as the directory name that you packaged

 

  - re-package the IP

 

See also UG1119 pages 42-49, page 48 has a picture of an IP File Groups with sub-core references.

 

Also note, I have seen some forum posts and AR's suggesting that Vivado doesn't always pick up changes to "sub-core references" unless you first re-package the IP, see AR66292

 

-Brian

 

 

 

0 Kudos
Highlighted
Participant
Participant
2,301 Views
Registered: ‎09-26-2016

Hi @brimdavis

 

Thank you for your detailed description. It now works, but it still requires more steps than someone would expect. But it is much better than before, when I have included Verilog files from Library into each IP. As you said, now, I removed them and add sub-core reference.

 

Current flow now is:

1. I make a change on a library Verilog file in external editor and save it there.

 

2 Then, in the main Vivado project nothing happens. I have to go to "Create and package new IP..." --> "Package a specified

directory"  --> (here I choose my library folder and check "Package as a library core") --> (files here are updated) Re-Package IP

 

3. In my main Vivado project I have to first "Reset output products" for my design.

 

4. And then "Generate output products" again.

 

After that, files in the output products are updated with the changes made in external editor and I could run the synthesis and implementation.

 

This is quite OK, but is there any trick to make this process even shorter?

 

Thank you a lot.

Matic

0 Kudos
Highlighted
Scholar
Scholar
2,533 Views
Registered: ‎04-26-2012

@matic  "it still requires more steps than someone would expect. But it is much better than before"

 

Yes, using the 'library core' as a  'sub-core reference' makes IPI aware of those shared files without the bad side-effects of packaging sources outside of an IP directory tree.

 

>

> This is quite OK, but is there any trick to make this process even shorter?

>

The best trick I know is to avoid using IP {dis}Integrator whenever possible  :)  

 

That said, the sub-core reference update bug is known to Xilinx, so if they ever get around to fixing it, that extra re-packaging step after editing a 'library core' would no longer be necessary.

 

-Brian

 

View solution in original post