-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
Is your feature request related to a problem? Please describe.
The TCL currently doesn't support a "3rd party" IP repository for projects. It supports the default IP repository search path (managed by vivado.ini, in the tool install directory), plus the ADI IP repository (in <adi_hdl>/library), but I'm unable to add another IP folder to the build.
The way the ADI TCL is structured, there's no way to insert anything or make any changes to the project between the call to adi_project {} and the start of system_bd.tcl.
In Vivado 2022.2, it seemed to allow us to add to the lib_dir path in the system_bd.tcl file, but now when we've migrated to 2025.1 it gives us a critical warning that you can't do this when a BD project is open.
It seems we can co-opt "ADI_GHDL_DIR" and use the environment variable, but it's clunky and we'd rather not use that mechanism (I imagine it has a use for something else, though I can't really find any documentation on it)
Describe the solution you'd like
Some way of adding a path or set of paths to the IP/LIB search paths so that we can use an IP repository that isn't built in the ADI library directory. Or, more directly, a way of having our IP separate from ADI IP so we can version them separately.
Describe alternatives you've considered
- Updating the Vivado.ini file in the tools install directory. Not workable for us because our 3rd party IP is part of our git repo, and the absolute path changes on our CI/CD machines.
- A global variable for "extra IP repo directories" that gets added to the IP search path in adi_project_xilinx.tcl. (This is our current local modification we're using)
- A callout from the TCL stack to a project local function or file that allows settings on the project after being created, but prior to the BD file being created. This would probably be the most flexible approach, since it would allow for any properties to be managed however we want.
Additional context
This is important to us because we're trying to keep our IP separate from ADIs IP, mostly to prevent us from accidentally modifying the ADI IP in ways that make it more difficult to upgrade in the future. We also prefer to have our IP and project directories "alone" so what's ours is more obvious and navigable. It also allows us to version them separately.