From: jesse lackey on
doug wrote:
> Memory leaks come from sloppy programmers. Not fixing memory leaks
> comes from lazy or incompetent programmers. It is clear that the
> programmers did not test their code. They seem to think that "testing"
> means looking to see if it blows up in the first ten seconds. This is

Actually, memory leaks are just another bug, like any other, better
programmers will have fewer of them than worse/sloppy programmers.
There will be bugs. Testing is QA's responsibility. The decision to
fix things is up to project management.

The fault of ISE rather clunky behavior and problems - I'm a newbie
here, been using it for a few days and 600 lines of VHDL - can be laid
at the feet of middle managment at Xilinx. If one feels insulted and
frustrated that Xilinx doesn't believe it is worth it to prioritize
fixing longstanding issues, then you have to vote with your qty 10,000
design decisions. It is the only thing that makes businesspeople really

I've seen some of the problems mentioned here already. Process "_pn"
hanging around. Multi-second lag times to start tools. Weird project
setting problems in iMpact or whatever it is called (fortunately I just
use it to make a hex file I process with a script to make a const array
in C for the microcontroller code). Somewhat disappointing but so far
no synthesis bugs.

To ISE's credit, having error messages have a link to knowledgebase
articles on has been very handy. Smart.

From: Michal HUSEJKO on
Hi Brian,

On the XESS website you can find a very good description how to use
Xilinx's tools with makefiles. This is a direct link:

I found this description very helpful to build my own scripts. Since
one year I use makefiles for most of my projects and I don't have all
these problems related to the ISE GUI.


From: Martin Thompson on
Daniel O'Connor <darius(a)> writes:

> Martin Thompson wrote:
>> If by ISE we mean the GUI (as I think we do) then I disagree...
>> The best development environment I have ever used for Xilinx devices
>> is Emacs (with vhdl-mode) and a command-line build script :-)
> A man after my own heart..

:-) U get strange looks from people when they see me avoiding the mouse!

>> I had problems with ISE crashing when reading files of network drives,
>> which is what drove me to build scripts, but I'd not go back now!
> Do you mind sharing your scripts? I have some makefiles I leeched off
> someone them hacked up, however I still haven't worked out simulation
> properly..

Simulation I use vhdl-mode for, it scans my entire set of files and
builds me a complete makefile. Anyone who hasn't spent 2 or 3 weeks
attempting to get up the learning curve of emacs/vhdl-mode has missed
out IMHO. Two of my colleagues (who are distinctly mouse and windows
types) are converted to Emacs for vhdl writing (purely down to the
power of vhdl-mode). I used to use Codewright, which I thought was
pretty hot, but it's not a patch on emacs, especially for VHDL.

The rest of my scripts are simple bat files in windows, I just make a
"working directory", copy in the EDF, UCF and any other NGD files I
might need, then run NGCbuild, map, par etc. I have a few other bits
ont he end for our internal use which generate a C-file with the
bitstream as an array, and embed the time of compile into the UserID

Hope that helps!


TRW Conekt - Consultancy in Engineering, Knowledge and Technology

From: Martin Thompson on
"bgshea" <bgshea(a)> writes:

> So, I ask Martin, as he posted a method of using build scripts, if you
> could even if in part, post some of what you use, that might benefit
> the community here. I would certainly build on those scripts and post
> them back.

I've posted some details upthread somewhere, I don't think my employer
would like me to post the raw scripts I'm afraid.

I have this makefile from my home linux system, which I have used in
the past also... It's not as well tested, but it met my needs at the

You'll notice this was from when I was playing with myhdl...

It has targets for stopping at various points along the compile, as
well as a PROG target which creates an impact script and then runs it.

So all I have to do when I've hacked my code is "make prog" and then
go and make a cuppa (my aging dual-celeron box takes a while!)

Hope this helps someone!


##### Makefile starts here

..PHONY: myhdl
..PHONY: bits
..PHONY: synth
..PHONY: sim
..PHONY: clean
..PHONY: prog
prog: work/$(TOP).bit
@echo "setPreference -pref StartupCLock:AUTO_CORRECTION" > work/impact.cmd
@echo "setMode -bs" >> work/impact.cmd
@echo "setCable -port auto" >> work/impact.cmd
@echo "Identify" >> work/impact.cmd
@echo "setAttribute -position 1 -attr configFileName -value $(TOP).bit" >> work/impact.cmd
@echo "Program -p 1 " >> work/impact.cmd
@echo "quit" >> work/impact.cmd
cd work && impact -batch impact.cmd

sim: work/$(TOP).v
iverilog -v tb.v && vvp -v a.out +lxt
cat work/$(TOP)_sim.results
cd work && xflow -config bitgen.opt -p xc3s200-ft256-4 $(TOP).ncd | tee logfile_par.log

par: work/$(TOP).ncd
work/$(TOP).ncd: work/$(TOP).ngc $(TOP).ucf
cp $(TOP).ucf work/
cd work && xflow -implement fast_runtime -p xc3s200-ft256-4 $(TOP).ngc | tee logfile_par.log

work/$(TOP).ngc: work/$(TOP).v
cp $(TOP).ucf work/
chmod u+w work/$(TOP).ucf
cp xst_verilog.opt work/
chmod u+w xst_verilog.opt
cd work && xflow -synth xst_verilog -p xc3s200-ft256-4 $(TOP).v | tee logfile_syn.log

rm -rf work/*

work/$(TOP).v: $(SOURCES)
@echo MyHDL Verilogging $<
python2.4 $<
mv $(@F) work

############ Makefile ends here #######

TRW Conekt - Consultancy in Engineering, Knowledge and Technology

From: Martin Thompson on
Sean Durkin <news_jan07(a)> writes:

> I think the main problem is that Xilinx releases new ISE versions in a
> predefined schedule, as Austin mentioned in Antti's thread about
> non-volatile Xilinx-FPGAs. A new ISE release comes out regularly, not
> when it's done. But on the other hand, it doesn't make sense to release
> a new version, when there's nothing new in it. The marketing department
> has to brag about it being another 30% faster than the previous release,
> having gazillions of new features, and so on.

I don't suppose they'd want to advertise 30% less bugs would they?
Even though most engineers would rather see it :-)


TRW Conekt - Consultancy in Engineering, Knowledge and Technology