cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Saving Compile Time Series 5 - Reuse remote IP cache for multiple Vivado projects

txu
Xilinx Employee
Xilinx Employee
3 1 444

In the design cycle, users can have multiple versions of projects which use the same IPs with the same configurations. Rerunning the whole project can cause regeneration of the IPs every time, and is time-consuming.

In the Vivado project settings, the user IP repositories allow users to add their own IP to the Vivado IP catalog and when used alongside a Remote IP Cache, compile times can significantly reduce. This blog entry explains how to set this up.

You can find all of the entries in the Saving Compile Time Series here.

Prerequisites:

 

Before reading through this design entry, make sure you are familiar with how to Package IP cores. The information can be found in UG1118  and in these Quick Take Videos 

Before starting with the steps below, it is best to create a formatted directory structure:

/iprepo

/<IP 1 Name>

/<IP 2 Name>

/ipcache

Note: there should be a top-level parent directory, for example iprepo, and then child directories; one for each IP, and one for a Remote IP Cache that can be created by Vivado.

The IP must be in a sibling directory to the Remote IP Cache. This is because Vivado stops searching the directory structure for IP Caches when it encounters a component.xml file, which is always generated with the packaged IP directory.

 

Step 1: Package an IP with all of the required source files

The general IP packaging steps include the following 3 steps, and the packaged IP files are managed together.

  1. Add the RTL to a Vivado project and verify that it is complete by synthesizing it
  2. Package the RTL by using the Tools option in Vivado:
    1.png
  3. Make sure to choose a directory based on the IP Name within the ip_repo directory

 

Step 2: Verify and generate all remote caching files

 

In this step, you need to instantiate the packaged IPs from the packaged IP folder, but with no logical connections.

After that, generate the netlist for different IP configurations in the repository.

  1. Add the newly created user IP Repository to a Vivado project via the project settings:

    cacha.PNG

  2. Add the IP to the newly created IP Integrator Block Design.  You can easily bring all of the ports of the IP out to external ports by selecting it and pressing Ctrl-T. 
    Otherwise, you can add it to a design.

  3. If your IP is configurable, add multiple configurations to further populate the IP Cache with common configurations.  

    Note: there are lots of restrictions when applying this work-around, any mismatch from the user's IP settings could cause a regeneration of the instantiated IP

    • Ensure that the software build matches
    • Ensure that the device part/speed_grade/board name matches
    • Ensure the IP settings matches with the IP caching file when it is generated. Checks should be performed as sometimes parameter propagation could cause some parameters on the user's IP to be overridden, for example, the clocking frequency propagated from upstream would be overridden. 

  4. Validate the design and review any Error and Critical Warnings

  5. Before generating the design, specify the remote IP Repository within the IP Repository directory, for example, /iprepo/ipcache:

    Cacheb.PNG

  6. Generate the Block Design by using the default Out of context per IP option:

      4.png

  7. After generation is complete, you should see the Remote IP Cache populated.
    There will be new directories that have a hash code as the directory name.

Step 3: Instantiate the IP in the formal design and reuse the remote IP repository

Using the user IP repository and IP Cache in a project:

  1. Now you only have to point to the top-level IP Repository directory to use both the User IP and the Remote IP Cache.

    cacha.PNG
  2. When you generate the design now, re-synthesis will not occur if the part/board used and IP configuration options do not change, and you will see the "Using cached IP results" for the IP run status:
    6.png

 

Suggested Revision Management:

  • Either package a user IP by script or create a standalone project to package the IPs.
  • Create a standalone project to instantiate the user IPs with all of the different configurations, and generate the IP, along with exporting the cache.
  • Adopt the IP in the formal project and follow the guidance in the documentation.

 

This blog entry was written with contributions from: Ben Curry, Nabeel Shirazi and Yolanda Xu.

Tags (2)
1 Comment
maps-mpls
Mentor
Mentor

This is very cool.

 

On:

>Either package a user IP by script 

I have this working.  And it was a bear to troubleshoot.  While doing it, I had to reverse engineer a lot.  And it leaves me sad because IPI and the IP Catalog were so close to being very powerful.  On some of the issues I ran into, e.g., running a tcl script to generate an XDC based on user customization GUI customization, I basically got the message that I was encroaching on proprietary areas of Vivado.  (Maybe it was just a can of support worms).

 

Do you have a document that describes the creation and packaging of complex IP, adding drivers, Vitis scripts, etc.?


Like I said, I have everything worked out (except generating or modifying a .XDC based on user input in the customization GUI).  This last feature is obviously done by Xilinx for some of their IP in the IP catalog, and is quite powerful.