Forum Discussion
Altera_Forum
Honored Contributor
10 years ago --- Quote Start --- this seems to work, but GREATLY reduces flexibility of where we can check-out the files. A relative-path solution would be preferred.... In the code in your link you seem to refer to an environment variable ($::env(VHDL)). Would work, but isn't there a nicer way? --- Quote End --- In my latest versions of the .qip code, I use Tcl to copy a template file and modify that file to set a VHDL variable. I had to stop using $::env() variables as the support is broken in 15.0 in some of the Qsys Tcl interpreters (the env still exists, but user variables like VHDL are missing). My comments from the attached _hw.tcl file are:
# QIP file generation
# -------------------
#
# Quartus copies the .qip file to the build area, so the .qip
# file cannot reference source files using relative paths.
# Quartus 13.1 and on execute the _hw.tcl files in a Java
# Tcl interpreted that has several restrictions;
#
# * The environment ::env does not include any user-defined
# values, so you cannot set a VHDL_PATH variable on the
# NIOS II IDE shell command-line and reference that
# variable in the _hw.tcl script.
#
# * The variable ::quartus is not available in all versions
#
# * The Tcl support provided by the Java VM is incomplete
#
# - set path does not work, so use
# set path is a work-around
#
# - set path does not work, so use
# set path ]
#
# The file path in the _hw.tcl file is relative to the _hw.tcl
# script, so accesses to the template files do not need a full
# path.
I've uploaded a zip that contains the _hw.tcl file, a top-level wrapper template, and a .qip template. The top-level template was required so that I could reference the VHDL library and package, and to use a 'real' data type (the Qsys GUI accepts a string entry, and the Tcl converts it to a VHDL 'real' type). The Tcl modifies the variable VHDL_VAL to reflect the source location. The .qip file compiles the source into a 'control' library - the same library referenced by the top-level wrapper VHDL. This "solution" was determined by trial-and-error. If anyone has a better solution, please let us know! Cheers, Dave