On May 21, 3:37*pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> Are you sure that the settings you are using are identical. *I was under
> the impression that ISE was just a GUI wrapper that sent commands to a common
> set of implementation programs.

Hi Matthew,

I'm working with Andrew on this project.

The settings are not identical because ngdbuild.exe invoked by ISE has
an '-ise project.ise' and '-intstyle ise' options. We want to avoid
the use of the .ise project file entirely.

Also it seems that the GUI calls a different set of executables in the
"unwrapped" subdirectory of "ISE/bin/nt". It also passes the ISE
project file as a parameter and there's evidence that some settings
(such as the UCF file) are drawn from this. As I mention later,
running the same executable as the ISE generates a strange fatal
exception.

Let me try and describe the issue fully.

- 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.
- we first synthesize an EDIF file with Synplify 9.6.2 - this is
called FPGA_DAC16V2.edf in the examples below
- the Xilinx Project Navigator ISE file contains just two sources:
FPGA_DAC16V2.edf
Constraints/FPGA_DAC16V2.ucf

Once we have our EDIF, we wanted to see how to drive the Xilinx
Translate process (ngdbuild.exe) from the command line:

- the <project>.cmd_log file that Project Navigator creates during
Translate shows ngdbuild executing as follows:

ngdbuild -ise "D:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
FPGA_DAC16V2.ise" -intstyle ise -dd _ngo -nt timestamp -i -p xc3s1000-
ft256-4 "D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd

- hmm, there are two 'ngdbuild.exe' programs under .../ISE/bin/nt -
which one is being run? We think it's 'bin/nt/unwrapped/ngdbuild.exe'.
- anyway, we note the '-i' option means 'ignore the User Constraints
File', although the log output shows:
...
Reading in constraint information from 'Constraints/
FPGA_DAC16v2.ucf'...

...

- we believe ngdbuild is picking up the presence of this UCF file
from the referenced .ise file, but perhaps not actually applying the
constraints due to -i option.
- now, because we want to remove the .ise file from our process, we
manually converted this into the following command using "xflow"
integration:

D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo -nt
timestamp -i -p xc3s1000-ft256-4
"D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/
FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd

However the log output from this shows that this time, the constraint
information is not read, presumably because ngdbuild does not know
about the UCF file. This also results in a file about 100kb smaller
than the ISE generated .ngd file - certainly a different output. If
the entire process is run to generate a .bit file, a binary diff shows
these two .bit files as *significantly* different.

- so we determine that the UCF is probably required, changing the
command line to (replacing -i with -uc <file>):

D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo -nt
timestamp -uc Constraints/FPGA_DAC16V2.ucf -p xc3s1000-ft256-4 "D:/
DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/FPGA_DAC16V2.edf"
FPGA_DAC16V2.ngd

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!

Not only this, but the resulting .ngd file is still different - in
this case, the ISE generated .ngd file is 5333871 bytes and the one
generated by the commandline is only 5333798 bytes, or 73 bytes
smaller. A binary diff shows the files are almost entirely different.
This results in all other files beyond ngdbuild (such as map, par,
etc) to be different too. And the problem is, we don't know what is
actually different!

Interestingly, although all the resulting intermediate files that
follow on from this are different between the two processes, the
final .bit file is thankfully identical except for a few bytes that
look like a timestamp near the top of the file. This is a huge relief!
However we would still like to know what is going on because if we
can't generate identical ngd files, or at least be sure that they
differ only by a timestamp, then building confidence in our build
system will be difficult. Who is to say that future builds will
deviate in unknown ways?

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.

This raises a few questions:

1. is the .ngd output file encrypted or perhaps compressed? This would
explain the massive difference in the two files, especially if there's
a timestamp embedded in them.

2. how can we get the output .ngd files to be the same without
referencing the .ise file - what are we missing on the command line?

3. why does the ISE flow appear to not apply the UCF constraints, yet
if we don't do this with our command-line build, the resulting .bit
file is completely different.

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.

5. what is the difference between the file .../ISE/bin/nt/ngdbuild.exe
and .../ISE/bin/nt/unwrapped/ngdbuild.exe? The 'unwrapped' version of
ngdbuild.exe is used by ISE but when used in the example command-lines
above it frequently fails to find the UCF file and aborts:

ERROR:ProjectMgmt:356 - Problem loading constraints.
....
FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This
application
has discovered an exceptional condition from which it cannot
recover.
Process will terminate. For technical support on this issue, please
open a
WebCase with this project attached at http://www.xilinx.com/support.

I assume from this that we are not supposed to be calling the
'unwrapped' version of the exe file? Perhaps this is for internal ISE
use only?

So it appears it is not possible to run a). the same ngdbuild
executable, or b). the same command line options if you want to
completely avoid referencing the ISE project file with a command-line
invocation of ngdbuild.



-- David Antliff