Forum Discussion
Occasional ContributorHow to organize a shared cache for qsys systems?
I have written a system to generate command lines and scripts/templates for various EDA tools. This will let me share the same same design across different implementations. The designs typically reside in a git (or some other VC) repository.
For Altera IP's only the *.ip is kept in the git repository. The cache tag is generated from a hash of the content of the *.ip and the Quartus version used as this uniquely defines a single *.ip file.
The build script will copy the '*.ip' file and run qsys-generate in the $cache/$tag location which will be added to the IP_FILE in the tcl build script. The next time the same Quartus version and same *.ip file is used it's referenced by the IP_FILE variable. This works pretty well.
Putting the *.qsys itself into a similar structure works too. But distributing the *.ip and *.qsys children of the parent.qsys in the same cache seem to be problematic as the parent.qsys logicalView XML tag seem to contain a partial relative sub-path.
Is there a way to make sure that only references to the child.ip or child.qsys will be present in the parent.qsys so that it can be located by the full absolute path specified in the IP_FILE?
Also how are *_hw.tcl files located and what type of references and relations between these and their respective *.ip and/or *.qsys files are stored in these files?
Or is the only solution to copy the full tree structure of the qsys into the cache and hash its full content?
BTW I'm using Linux only.
3 Replies
- RichardT_altera
Super Contributor
I would suggest Not to treat a parent .qsys as self-contained through IP_FILE. For nested Platform Designer systems, use a directory that preserves the original relative structure, and configure that directory through IP_SEARCH_PATHS or .ipx files.
The parent .qsys stores child-system and component metadata, including path information. IP_FILE registers a specific .ip instance with Quartus, but it is not a universal override for resolving every child referenced inside a .qsys.
In short, use IP_FILE for project-level .ip instances, and use the project IP search path or .ipx files to discover _hw.tcl defined components. Preserve the nested .qsys dependency structure separately.
2.6.5.2. Defining the IP Search Path with Index Files
https://docs.altera.com/r/docs/683609/26.1/quartus-prime-pro-edition-user-guide-platform-designer/ip-component-description-files
The Quartus® Prime software identifies parameterizable IP components in the IP search path for the following files:
- Component Description File (_hw.tcl)—defines a single IP core.
- IP Index File (.ipx)—each .ipx file indexes a collection of available IP cores. This file specifies the relative path of directories to search for IP cores. In general, .ipx files facilitate faster searches.
sstrell_hw.tcl files, when created for new custom components via Component Editor, get placed in the Quartus project directory for some reason. Back in the day, they used to get placed along with the location of the HDL code that defined the custom component, making it easier to have that connection between _hw.tcl and the code. As for the connections between files, simply open the _hw.tcl file and you'll see the paths pointing to the associated code. Remember that .ip files define an instance of a component with a particular selection of parameter settings added to the system so it should point to the _hw.tcl, I believe.
I can't help with the prior question.
zenerThank you for the info.
