Determine version of Xilinx ISE programatically

Question

I'm using the Xilinx toolchain and I'd like to automate (with TCL scripts) some things. While the ISE Suite can be extensively automated via TCL and their TCL shell (xtclsh.exe), there doesn't seem to be any way for me to programatically determine which version of the Xilinx tools are installed so I can know where the shell resides. I can't just hardcode the path since each version of the tools is installed in a subdirectory that includes the version number. I run the risk of invalidating all my scripts as soon as I update to the newest version they release. This same question has come up on the Xilinx forums, apparently to no avail. Does anyone know a way (some script/batch file/environmental variable) to get the path to the newest version of the Xilinx executable installed programatically?

Answer 1

With the newer Xilinx (12 upwards) tools, you have to run a script before running any of them. The script sets some environment variables to point to the "right version"

If you run the tools from the usual launcher icons, that script is run for you transparently. If you open your own dos box and want to run a compile within it, you have to run <path to xilinx tools>\<version>\ise_ds\settings[32|64].bat to get the environment set up.

You then get a set of XILINX_* environment variables set up, the most fundamental of which is called XILINX. On my 12.4 installation it points to

XILINX=c:\Xilinx\12.4\ISE_DS\ISE

This is also then added to the path, so when you call map, par etc, the right one gets called. So you shouldn't need to actually know the path in your scripts, unless you want to access some of the datafiles within the installation.

---

How can I find the correct "root" programmatically?

In my experience, the "correct" way of operating is to require that the correct root is explicitly defined by the user. We have many different versions of ISE installed and select which one depending on the project. Once a project has started we freeze the tools used (to the extent that with production projects, the build script checks the version of the tools as a first task and bombs out of the user has selected the wrong one). Particularly between major releases, there is sufficient churn that migrating toolsets can be quite a large job, especially if you are using the wider toolset (eg EDK, system generator etc).

However, if you really want to run the the latest tools you can find all the time, I think there may be some registry keys (assuming you are a Windows user) you could iterate through. They may contain a pointer to the root which you could then use.