Forum Discussion
Community ManagerHow to organize a shared cache for qsys systems?_FA
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.
1 Reply
ai_responderThis is a nuanced build-system design question. Let me address each part from what the documentation explicitly covers.
parent.qsys child references and the relative-path problem
The core constraint is documented: Platform Designer stores the converted .ip files inside an
ipfolder, relative to the Platform Designer system file (.qsys) location. Quartus® Prime Pro Edition User Guide This relative placement is reflected in the logicalView XML inside parent.qsys — it encodes sub-paths relative to the parent's own location, not absolute paths. There is no documented option in Platform Designer Standard or Pro to force that internal XML to emit absolute paths to children instead.The IP_SEARCH_PATHS mechanism operates at the IP catalog discovery level, not at the parent-child .qsys resolution level. IP_SEARCH_PATHS specifies which paths Quartus should use to search for IP components and IP index files. You can specify multiple paths, separated by semicolons. The paths can be absolute or relative to a Quartus project folder. IP_SEARCH_PATHS This controls what shows up in the IP Catalog, but does not reroute the parent.qsys's hardcoded relative references to its child .ip/.qsys files.
The one built-in mechanism that does update all internal references when you reorganize the file layout is the Archive System feature: When enabled, Platform Designer collects the system's .qsys files in the root directory, and the .ip files in a single ip directory, while updating all references. Quartus® Prime Pro Edition User Guide And Platform Designer automatically identifies the .qsys and .ip files needed for system archiving when using Archive System. Quartus® Prime Pro Edition User Guide However, this is a GUI-driven operation, not a scripted path substitution, and it still produces a canonical relative layout rather than absolute-path references.
The practical implication for your cache design: because the logicalView sub-paths are relative to the parent.qsys's own location, the relative directory structure between parent.qsys and its children must be preserved in whatever cache location you copy them to. You cannot independently cache children at arbitrary absolute paths and expect parent.qsys to find them by IP_FILE alone.
How _hw.tcl files are located and what they reference
During the discovery phase, Platform Designer reads the _hw.tcl file to identify information that appears in the IP Catalog, such as the component's name, version, and documentation URLs. Each time you open Platform Designer, the tool searches for the following file types using the default search locations and entries in the IP Search Path: _hw.tcl files — each _hw.tcl file defines a single component. Intel Quartus Prime Standard Edition User Guide Platform Designer
The default search locations are hierarchical: PROJECT_DIR/* finds IP components and index files in the Quartus Prime project directory. PROJECT_DIR/ip/**/* finds IP components and index files in any subdirectory of the /ip subdirectory of the Quartus Prime project directory. IP Search Path Recursive Search
Critically for your caching scenario, the paths inside a _hw.tcl to its associated HDL files are relative, not absolute: The _hw.tcl file contains relative paths to the other files, so if you move an _hw.tcl file, you should also move all the HDL and other files associated with it. Quartus® Prime Pro Edition User Guide Source file paths within the _hw.tcl itself may be expressed either way: Adds a file to the generation directory. You can specify source file locations with either an absolute path, or a path relative to the IP component's _hw.tcl file. Intel Quartus Prime Standard Edition User Guide Platform Designer So a _hw.tcl that uses absolute internal paths would survive relocation, but one generated by the Component Editor will use relative paths by default, requiring the HDL tree to move with it.
The relation between _hw.tcl and .ip/.qsys: the _hw.tcl is the component description consumed during the discovery and elaboration phases. The .ip file is the parameterized instance record; it points back to the component type (resolved via the IP search path to the _hw.tcl). During the static component definition phase, Platform Designer reads the _hw.tcl file to identify static parameter declarations, interface properties, interface signals, and HDL files that define the component. At this stage of the life cycle, the component interfaces may be only partially defined. Intel Quartus Prime Standard Edition User Guide Platform Designer
Recommended cache strategy
Given the above, for a hierarchical .qsys system the only robust approach for your cache is to preserve the complete relative tree layout. This is further confirmed by the known issue around archiving: When a design includes a Qsys system and the Archive Project feature is used, it does not automatically archive all input files necessary to regenerate the Qsys system. Workaround: in the Archive Project dialog, click Advanced, then Add, and manually select all related IP HDL and _hw.tcl files, hierarchical Qsys systems, and any files generated for simulation. Archive Project feature does not automatically archive all the input files required to regenerate a Qsys system
In practice this means your cache tag hash for a hierarchical system needs to cover the full tree — parent.qsys, all child .ip and .qsys files, and any _hw.tcl plus associated HDL files — and the cached copy must mirror the relative layout exactly. Your current approach (independent caching of flat .ip files via qsys-generate, referenced by IP_FILE) works cleanly for leaf IP variations. For hierarchical systems with a parent.qsys, the subtree must be cached as a unit with its internal relative structure intact.
Note: To continue using AI Responder, please start your next inquiry with ai_responder
Disclaimer (Beta): The AI Responder is currently provided as a beta feature. AI-generated responses may contain errors or omissions. Please verify technical guidance with official Altera documentation before implementation.
Thank you very much.
