FPGA Central

Hi,
We are switching to a makefile to build our Xilinx FPGA bit files. Can
we expect to get an identical bit file (except for date/time in the
bitfile header) if we build through the ISE gui vs building via the
command line?

What we have found is that the output ngd file from the ngdbuild
process (Translate) is not the same in both cases. The file size
differs by 100 bytes, and the resulting bitfiles end up being very
different. Can we expect the ngd file to be identical?

We use synplicity to synthesize the design, which creates an edif
netlist. The edif netlist going into the ISE flow and makefile flow
are identical.

Cheers
Andrew

> Hi,
> We are switching to a makefile to build our Xilinx FPGA bit files. Can
> we expect to get an identical bit file (except for date/time in the
> bitfile header) if we build through the ISE gui vs building via the
> command line?
> What we have found is that the output ngd file from the ngdbuild
> process (Translate) is not the same in both cases. The file size
> differs by 100 bytes, and the resulting bitfiles end up being very
> different. Can we expect the ngd file to be identical?
>
> We use synplicity to synthesize the design, which creates an edif
> netlist. The edif netlist going into the ISE flow and makefile flow
> are identical.
>
> Cheers
> Andrew

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.


---Matthew Hicks

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

On Wed, 20 May 2009 19:16:41 -0700 (PDT), andrew.newsgroup@gmail.com wrote:

>Hi,
>We are switching to a makefile to build our Xilinx FPGA bit files. Can
>we expect to get an identical bit file (except for date/time in the
>bitfile header) if we build through the ISE gui vs building via the
>command line?
>
>What we have found is that the output ngd file from the ngdbuild
>process (Translate) is not the same in both cases. The file size
>differs by 100 bytes, and the resulting bitfiles end up being very
>different. Can we expect the ngd file to be identical?
>
>We use synplicity to synthesize the design, which creates an edif
>netlist. The edif netlist going into the ISE flow and makefile flow
>are identical.
>

You'd like to think so, and if ALL the flags and options are identical, I
believe it should be the case. But achieving that may not be trivial.

Try running Translate from the command line with the exact command line given in
the ".cmdlog" file - including the "-intstyle ISE" flag and see if that gives
the same result as the GUI flow.

The 'project.ise' can supposedly be exported as a script, reading which should
help discover the missing options. These should then be applicable through the
command line.

However...

One worrying datapoint is Xilinx's own PCIe interface project for the V5 ML506
board, where the advice given is to use the implementation shell script rather
than attempting to build through the GUI; with no further explanation.

Indeed an apparently successful run through the GUI tools produces a
non-functional bitfile! I have not had time to explore deeply enough to
find out why.

- Brian

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)

phil hays wrote:
....
> the only way that I'm aware of to get a
> consistent result is to start with a fresh directory.

ise 10.1 allows project exports of type tcl or ise.
For me, the tcl restore worked, the ise didn't.

....
> 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.

If do you update it, I would make use of it.

-- Mike Treseler

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

On May 21, 11:33*pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> Try running Translate from the command line with the exact command line given in
> the ".cmdlog" file - including the "-intstyle ISE" flag and see if that gives
> the same result as the GUI flow.

Thanks for your reply, Brian.

Unfortunately, the cmdlog indicates that the GUI flow uses a different
executable - unwrapped/ngdbuild.exe which has the problem I described
with loading constraints when run from the command line. So one issue
right at the start is that the GUI uses different binaries.

> Indeed an apparently successful run through the GUI tools produces a
> non-functional bitfile! I have not had time to explore deeply enough to
> find out why.

I don't think it's safe to assume the GUI and command-line flows have
the same results. From what I've seen, the two have diverged.
Fortunately, by manually including the UCF file (and therefore
deliberately disregarding the -i flag that cmdlog said we should use)
we are able to produce an identical final bit-file, excluding
timestamp in header, even though the intermediate files are all
different.

That's with our current inputs at least. Who knows whether this will
be the case tomorrow, or next month?

-- David.

On May 23, 5:07*am, LittleAlex <alex.lo...@email.com> wrote:
> I have been successful converting a project from GUI to command line
> with identical bit files.

Hi LittleAlex, thank you for your comments.

We too get identical bitfiles (excluding header), but my concern is
that the intermediate files are all different. All this does is give
me confidence that *this* build is identical, but who can say if
future builds will be? We have no way to test this for every build
either. For serious use of the Xilinx tools in an engineering
environment, this sort of behaviour is ridiculous.

> 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

In fact the GUI got it wrong - it said to use the -i flag, but in fact
this was wrong and what was required was removal of the -i flag, and
use of the -uc flag instead.

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

What flow do you use with that? -intstyle xflow?

> 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.

Is the .prj format similar to Synplify's TCL .prj format? I'll have to
look up the .prj format - could be useful.

> 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.

Yes, our Makefile cleans up pretty well. A 'git clean -fdx' also does
the trick during a build.

Regards,

-- David.

On May 22, 2:30*am, phil hays <philh...@dont.spam> wrote:
> 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.

Hi phil, thank you for your reply.

> 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.

This sounds useful - can you direct me towards a recent version of
this please?

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

However the ISE flow is using the '-i' flag, which is supposed to
ignore constraints... I only get the same behaviour from the command
line if I ditch the -i flag and use -uc instead, to include
constraints.

> 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.

In conjunction with your earlier comment, this makes sense. However I
understand if -intstyle ise is *not* used, there's no dependency on
the ise file whatsoever. I'd prefer this at build time, although we
would like to automatically create an ise file for local use inside
the GUI.

> 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?

Yes, this would be useful please.

Regards,

-- David.

"David Antliff" <david.antliff@gmail.com> wrote in message
news:ece3bfd9-eb3f-495f-8371-722e105e915d@b7g2000pre.googlegroups.com...
> 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.

This sounds useful - can you direct me towards a recent version of
this please?

=========
I just use the <project>.xise file. Starting the gui with just that file in
the project directory produces all the other files.

On May 27, 3:25*am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> I just use the <project>.xise file. Starting the gui with just that file in
> the project directory produces all the other files.

Assuming you meant '.ise' not '.xise' (apologies if there really is
a .xise file, I haven't seen one) - as I mentioned earlier, we cannot
use the .ise file as an input to our build system because it
constantly changes. This also means we would prefer not to have it
tracked by our source control tool (git) as a constantly changing file
is nothing short of exceptionally annoying. So if we can generate
an .ise at build-time from a TCL script, we can provide a way to
generate a non-controlled .ise for use locally in the GUI tool. I
still don't want to use the .ise as a build input.

"David Antliff" <david.antliff@gmail.com> wrote in message
news:b284f6e3-e758-47e7-a392-2e0ce77c73f8@p6g2000pre.googlegroups.com...
On May 27, 3:25 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> I just use the <project>.xise file. Starting the gui with just that file
> in
> the project directory produces all the other files.

Assuming you meant '.ise' not '.xise' (apologies if there really is
a .xise file, I haven't seen one) - as I mentioned earlier, we cannot
use the .ise file as an input to our build system because it
constantly changes. This also means we would prefer not to have it
tracked by our source control tool (git) as a constantly changing file
is nothing short of exceptionally annoying. So if we can generate
an .ise at build-time from a TCL script, we can provide a way to
generate a non-controlled .ise for use locally in the GUI tool. I
still don't want to use the .ise as a build input.

=========
I really did mean explicitly .xise, as opposed to .ise. It's apparently new
with 11.1. It looks like well formed XML, but I didn't look in any detail.
The .ise file looks to be a TCL script, likely generated from .xise.

On May 27, 10:03*am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> I really did mean explicitly .xise, as opposed to .ise. It's apparently new
> with 11.1. It looks like well formed XML, but I didn't look in any detail..
> The .ise file looks to be a TCL script, likely generated from .xise.

Ok - sorry for the confusion. This sounds useful, although we haven't
upgraded to 11.1 just yet. I'll definitely keep it in mind when we do.
Thanks for the info.

On May 21, 5:53*pm, David Antliff <david.antl...@gmail.com> wrote:
> Let me try and describe the issue fully.

A quick followup for this.

After consulting with someone at Xilinx, it's clear that the .ngd file
is encrypted. Assuming it contains a timestamp, this explains why it
is always very different.

I have been told the correct thing to do is to compare the reported
Checksum (in the .par file for Xilinx 10.1, and the .map file for
Xilinx 11.1). I have confirmed that although the output from ngdbuild
and everything after this is different, that reported Checksum is the
same.

I was advised to omit the .ise file entirely from an automated system,
which was our original goal.

Thanks to everyone for your replies.

-- David.

David Antliff wrote:

> On May 22, 2:30Â*am, phil hays <philh...@dont.spam> wrote:
....
>> 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?
>
> Yes, this would be useful please.

I've created a webpage with a link to this script. I lost the original,
so I had to write a new script with the same function.

http://mysite.verizon.net/res12uj6d/


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

On May 29, 12:24*pm, phil hays <philh...@dont.spam> wrote:
> I've created a webpage with a link to this script. I lost the original,
> so I had to write a new script with the same function.
>
> http://mysite.verizon.net/res12uj6d/

Great, thank you very much for writing and posting this.

Regards,

-- David.

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


An ISE 10.x or 11.x project might have multiple UCF files. But the
ngdbuild is allowed only a single UCF as a parameter. I was told by
Xilinx tech support that ISE concatenates all included UCFs into a
single temp file and uses it to pass to ngdbuild. So if you build such
a project from a script, you shouldn't forget to concatenate all the
UCFs yourself.

- Evgeni

http://OutputLogic.com