How to script Xilinx ISE - xflow, batch file, tcl, ?

[Dave]

Hi Group,

In the past when I have wanted to use a script with ISE I have always
simply run the flow using the gui first and then created a batch file
using the command lines printed in the individual reports from xst,
ngdbuild, etc. Seemed to work quite well especially when using the
errorlevel returns (in Windows) to catch errors.

I am aware of the xflow system and that something can also no doubt be
done using tcl and I am wondering what the "best" method is.

What do you use and why?

One key feature I want to include in the design I'm starting now is
automatic build number increments by way of automatically increasing
an integer generic supplied to XST. This will be used to set the
reset value of a register in the VHDL. I am guessing a tcl script
would be best for this but can this also be done using xflow?

Many thanks for your time.

[Steve Ravet]

I use xflow, it has a couple small advantages over batch/shell script. One
is that you don't have to do any exit code checking, xflow will
automatically stop if one of the backend tools fails. Another is that the
format of the file lends itself to commenting the various tool options a
little cleaner that a batch/script would. I haven't done this, but I
believe that xflow can rerun only a portion of the flow, for example static
timing or bitgen, depending on the command line arguments.

What it can't do (I don't think) is run a point tool more than once. I
usually run static timing twice, once for an error report and once for an
unconstrained path report. I can't get xflow to run both of these reports
in a single invocation.

I haven't used XST so I can't comment on that part.

--steve

"Dave" <doome...@yahoo.co.uk> wrote in message
news:53b2d3d7-69e3-4454...@v25g2000yqk.googlegroups.com...
: Hi Group,

[Anssi Saari]

Dave <doome...@yahoo.co.uk> writes:

> What do you use and why?

Well, I've mostly used a "straight up" script file to just run the
commands, which is fine but not very flexible. But it doesn't eat much
in the way of developement time either.

At a customer site once they had a perl script to run the flow which
was pretty handy. It read tool options and file names from a config
file, so tweaking settings was easy. There was also the option to
start the flow from a certain point. On the other hand the script was
typical perl spaghetti code, so I didn't want to touch it and it only
went as far as bitgen. We needed to insert software and produce both
an MCS and a special byte swapped raw binary. We also had slightly
complicated synthesis which we basically did by hand, in a few steps.
Also we used Chipscope and again we had to do the insertion part by
hand every time, but after that the script was again useful since we
could start it from the right phase after Chipscope insertion.

Based on this, flexibility and maintainability is useful especially in
a large project and if you want to use your script in different
projects. But then, that goes for any software...

[Jim Wu]

I would recommend Makefile for command line flow. Not only does it
check the return code, but also it checks dependencies. You can find a
Makefile example here: http://groups.google.com/group/my-design-space/web/my-tools-page

Cheers,
Jim
http://myfpgablog.blogspot.com/

[kkoorndyk]

On Nov 10, 3:48 am, Dave <doomedd...@yahoo.co.uk> wrote:

We perform most of our development on Linux workstations and execute
implementation using Make files. I haven't tried this method with EDK
projects yet, but will start on that very soon.

The method we use to generate a unique build name is to set a variable
in the make file and use that to name the output from the tools.
Example of a ripped apart make file:

# environmental
targets
buildDate=$(shell date +%m%d%y%H
%M)
buildStamp=$(shell date +%m%d%y
%H)
buildName=fpga_$(buildDate)

ngdbuild $(ngdflags) ../fpga.edf $(buildName).ngd | tee -i pnr.log

map $(mapflags) -o $(buildName)_map.ncd $(buildName).ngd $
(buildName).pcf | tee -ai pnr.log

par $(parflags) $(buildName)_map.ncd $(buildName).ncd $(buildName).pcf
| tee -ai pnr.log

trce -e 3 -l 3 -xml $(buildName) $(buildName).ncd -o $(buildName).twr $
(buildName).pcf | tee -ai pnr.log

bitgen -f fpga.ut $(buildName).ncd | tee -ai pnr.log

Here's a method we've used to automagically modify a register setting
within the design. The original source includes a known register
value that gets modifed at the time the makefile is executed.

sed 's/ABCDEF00/$(buildStamp)/' ../path/to/source/
filewithVersionRegister.vhd > $(localTemp)/project
/path/to/source/filewithVersionRegister.vhd

We tend to have the make file copy all of the source to a build
directory and then move into that directory to execute the
implementation. That way we have a good record of source file
versions included with the build.

We'll see how well this process works with EDK, though.