On May 20, 10:53 pm, David Antliff <david.antl...@gmail.com> wrote:
> 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 athttp://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

I have been successful converting a project from GUI to command line
with identical bit files.

Take a very close look at the log files left behind by the GUI build.
There are options that you will probably not recognize - the GUI knows
better than you what you want it to do

You can get rid of the -intstyle ISE flag. I use a .prj file format
and that works just fine for me.

Most options can be set in a number of places. I'm not 100% sure
which location for the option has priority; I had some weird results
which went away when I made them all match.

The XST user guide was (actually) helpful in this process. Reasonably
hard to read, it looks like a disgruntled synopsys employee modeled it
after the dc_shell documentation. But with a little patience and
perseverance, it can be made to work.

Another thing to look out for: The GUI scatters work directories all
over the place. Weirdness in these directories can cause run to run
inconsistencies; audit the location and cleanup of these directories
carefully.

AL