David Antliff wrote:

> - we are using Xilinx 10.1 service pack 3 on Windows XP, and a recent
> installation of Cygwin.
> - we are trying to incorporate Xilinx into our automated build system
> - so we are running the Xilinx command-line applications from a GNU
> Makefile invoked from a Cygwin bash shell.
> - we want to avoid the project .ise file completely as this seems to
> change every time anyone opens it - this makes build tracking difficult
> and therefore the .ise file is unsuitable as an input to our automated
> build process.

As the .ise working file changes every run, and is binary to boot, it can
not be an input into a stable and maintainable build process. So the
solution I've used when using gnu make under Cygwin is to delete the
whole result directory (bld) at the start of the build. There are other
files in the result directory (and sub-directories under it) that can
influence the build, and the only way that I'm aware of to get a
consistent result is to start with a fresh directory.

Directory tree I've used looks something like this (Ascii art follows,
view with fixed pitch font)

Project
|
-----------
| |
src bld
|
-------
| |
hdl cores

The makefile exists in .src, and if any source file has changed it does
this:
rm -rf ../bld
mkdir ../bld

> We would like the output from ISE to exactly match the output from the
> commandline, and if this is not possible then we'd like to know why the
> two output files differ.

One option for doing this would be to have the make file call a Project
Navigator Tcl script (using xtclsh). This script would create a
fresh .ise file every run, and could also be used to run from the GUI. I
posted a script for this sometime ago, and will update it if desired.


> HOWEVER
>
> Instead of "Reading in constraint information from 'Constraints/
> FPGA_DAC16v2.ucf'..." we see this instead:
>
> ...
> Applying constraints in "d:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
> Constraints/FPGA_DAC16V2.ucf" to the design... ...
>
> This is not what the ISE flow said it was doing. It read the UCF file
> but it certainly didn't say it was applying the constraints!

This is because the ISE flow seems to read the UCF file into a data base
first, and then applies the constraints later.


> 4. why does the .ise Project file continually change? Even running
> 'ngdbuild -ise FPGA_DAC16V2.ise -h' to display the program's HELP text
> causes the .ise file to change! Why? This makes it very difficult to
> manage in a Source Control tool because it's continually changing
> without a clear reason.

The .ise file has lots of date and time information. The solution to this
is to think of the .ise file as a working file, rather than a project
file and to delete it at the start of any build script. There are other
working files, such as the constraint data base (which lives in a
subdirectory of bld), and it is safest to delete them all by removing the
working directory. Even the command lines tools can create and use a .ise
file for their own use.

To difference the .bit files, the header needs to be ignored. To make
this automatic, I've written a little difference utility using Tcl. Would
this be of interest?

(phil_hays at eeei.gro (fix the order for email)