Xilinx ISE 8.2

As compared to what?

Xilinx ISE is the best development software for Xilinx FPGAs that I've ever used.

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 :-)

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!

I still have to use the chipscope core inserter from the GUI though. When that works off the command-line, we'll really be there!

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

A man after my own heart..

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

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Brain,

I have the same memory leak problem. But it doesn't seem like many people have this issue. At least not posted to this news group or on the Xilinx help. I can not use any 8.2 because of the memory leaks and since it is "free" you really can't complain to anyone at Xilinx. I have been using 7.1.04i which does the job for me. Version 9.1 is out and I am going to see it it is any better.

Dave Colson

Brian,

Details the technical answer on this subject.

Austin

WOW, thanks everyone for the input. I'm going to dig though this info and esp. the links provided.

I would love to see some linux build scripts. I love EMACS!! and use it for all my c/c++ developement in linux. However, i don't have a PC to space in my office for linux yet. But i can certainly try on one of my personal Linux boxes.

ISE has been, IMHO, going down hill. With each new release the projects become backward incompatible. So what i end up with is many copes of projects for each new release. I'm not one to binldly trust any software so when upgrading i always copy my project directory to /projects/Xilinx_version/project_xxx ensuring a quick esacpe if something goes wrong.

I can't say i've had many problems with accessing files on network shares, was that Samba or NFS that was used? This would be nice to know, if you already stated, i appoligize for not reading everthing

100%.

I going to post this thread on my site, when i get it done, I'll post the link.

Regards,

Brian

doug wrote:

Even incompetent programmers can manage this. The use of valgrind

will pinpoint memory leaks right to the line where the allocation was made. It runs on unmodified software. This would be, oh, one hour work maximum if you have the source.

JB

I am a long time lurker on this newgroup and have learned a lot from it. I very much appreciate the presence of Austin and Peter and the help that they provide.

However, what got me to post this is that the url above just adds insult to injury regarding ise. I am a long time user of Xilinx software starting in about 1991. For most of that period the software has been terrible. The XACT software required you to reboot after every run, either voluntarily or it would do it for you. By the time of the Foundation series, the software was getting reasonable. I even bought a copy for my personal use.

ISE has been an experience. By version 6.3 it was reasonably good. It did what I wanted and did not cause too much trouble. Version 7 was a huge step backwards. Project navigator got user surly and very slow. Whoever did the design never used it for anything. Version 8 reached a new low. The stupid design to change the project files, later partly removed, made for lots of headaches.

Fortunately I was spared a lot of the headaches of version 8 since it would not compile my design. For a variety of reasons, mostly historical, a large part of my design is schematics. There is a major memory leak in the schvhdl module. It leaks at about 1mb per second of cpu time. Version 7 would complete the xst portion in about five minutes with a peak memory useage of around 120mb. Version 8 took an hour or so of time and then crashed at just over

2gb of useage. There was no way to compile the project and this was confirmed by Xilinx tech support. The only "workaround" was to tell it to compile to verilog instead of vhdl since that memory leak was not as bad. Unfortunately this was not an option since the peak memory useage was just about the 2gb point where the vhdl conversion failed and blew up the program.

The memory leak was a problem in version 8.1 It was not fixed in 8.1 sp1 It was not fixed in 8.1 sp2 It was not fixed in 8.1 sp3 It was not fixed in 8.2 It was not fixed in 8.2 sp1 It was not fixed in 8.2 sp2 It was not fixed in 8.2 sp3 It was not fixed in 9.1 It was not fixed in 9.1 sp1

So the latest and greatest version 9.1 and its service pack have done nothing to help make a relatively small design work. If they are not going to improve things, why break stuff that was working ok?

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 not some exotic hard to reproduce bug. Take an 2 input and gate and put iopins on it. The memory leak is about 3mb as I recall. This is not subtle or hard to find. They did not even look. They have not been looking since it was pointed out and there is no reason to believe that they have any intention of looking for the leaks.

At one point I sent in a list of fourteen bugs in ise for version 7. They are all still there plus lots of new ones I have seen in the little I have been able to use the newer versions.

The conclusion of this is that pointing to a url which just points out that the programmers did not bother to test their code does not help the users. What is needed is to get programmers who know what they are doing and FIX the problems.

Xilinx support recommended vhdl as it is more portable. That is true and will make it easier to take designs to other manufacturers.

I don't doubt what you are saying about the memory leaks. However, i have to take in to consideration JAVA, which has no real memory management, and by this i mean you cannot malloc and free memory, rather it relys on the fact that you use the new and delete operators. But even then if it suspects that a block of memory is going to be used it will not let it go.

As much as i love Firefox it suffers from the same memory leak issues. About once every 3 or 4 days i have to close out all browsers and free up about 600MB of memory.

I also cannot blame Xilinx for using JAVA, as it works on my Linux x86_64 AMD machine (at least i could start the project navagator) with very little fuss.

I also agree version 8 was a step backward, it added some new icons, design partitions and a whole bunch of nothing usefull. I have never had the pleasure of using 6.3 in depth, when i got in to CPLD/FPGAs, (early 2000) i used CUPL on an Altera Device, and needless to say it worked very well as a glue logic chip. I think i used Xilinx 6.3 for about one or 2 months before 7.1 appeared and quiclky switched.

Right now, i would like to find a good method of using the Xilinx Tools, since I'm using their FPGAs, to conduct long term hardware validations without restarting all the tools about once every 10 builds. Yes, i know that i am probably not doing this 100% right and more simulation could lead to less building but, if i had all the time in the world to complete my projects i would simulate every last aspect including my drive to work to ensure it would not effect my coding style that day, you get what i mean.

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 still have not received a difinitive answer to a key question i had posted, if anyone knows, can you provide some light on the subject.

Does Xilinx use it's own canned JRE or does it use the installed JRE?

I have just downloaded and installed Java SE Runtime Environment 6 from Sun, maybe it will help maybe not.

--Brian

manage this. The use of valgrind

Xemacs including VHDL mode is available for Windows as well. And you can install Cygwin

on any Windows box to get an almost complete UNIX-like environment, with Bash, grep, sed, awk, make, Perl, whatever you need to run build scripts.

cu, Sean

--
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Perhaps you should try script based builds such Tcl or makefiles, and use a source control program such as SVN.

Tcl or "tool control language" is a industry standard language. Documented Tcl was new with 8.2, and in my never humble opinion was a big step forward. I've taken a design I'm working on between 8.2 and 9.1 and back again several times without changing the Tcl script. Nice section on Tcl in the manual.

A source control program will allow you to have access to any past revision of your code, to show the differences between each revision, allow changes to be reverted (or backed out). It also makes it easier to work on multiple machines, or for multiple people to work on the same design.

As you like emacs, you might also like this:

--
Phil Hays (Xilinx, but always speaking for myself)

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. This approach results in the software department always being busy integrating new features so they can make the fixed deadline for the new software release, resulting in software that's usually not usable until three service packs later, and just when it finally *IS* usable, support is dropped because the next release comes out and it all starts over again.

Sometimes you get the idea that a new ISE is not just a new software version, but an entirely new product. Maybe it was just quicker to start from scratch than to fix what was already there. And then you get effects like bugs that were fixed in 7.1 re-appearing in 8.1 and things like that...

We had a Xilinx FAE here in late November, introducing us to Virtex-5, and when the topic of bugs in ISE came up, he actually said that we needn't bother sending in bug reports now, since the entire software department at Xilinx was now scrambling to make the deadline for the 9.1 release and nothing would really happen until after that anyway. And bug reports for ISE8.2 were useless anyway, since all the work is going into

9.1 now...

Add to this the additional support for Linux (which wasn't there before

6.3, I believe, and which I highly appreciate, BTW), and you get a situation where even competent programmers can't produce decent software, IMHO.

What is it with that regular release cycle? Does any other FPGA manufacturer do this? Or any other software company? What good is it? Customers have licenses, that are valid for one year, so you have to pop out one release a year so they get something for their money or what? I don't really get it. Software-quality-wise it does not make sense at all IMHO.

And then things like Antti mentioned happen: ISE9.1 is out, and it has support for devices that aren't even announced yet, i.e. no small customer is going to get for another year anyway. Why not just fix some bugs instead of integrating phantom devices? Why not just fix what's broken instead of adding even more new stuff that's broken as well?

Partial reconfiguration is another example. I've been fiddling around with this since ISE4, gave up with ISE7, since I always ran into some "FATAL_ERROR"-thingies that "will be fixed in the next service pack" or "will be fixed in the next ISE release", but never were. Now with software radio being a high-volume-application, they seem to have fixed it, but only in specially patched ISE8-versions you have to get through your FAE.

And does anyone besides me think that it's ridiculous to release the first service pack only days after the software? Doesn't that in itself tell you that obviously the software wasn't ready to be released in the first place? Service pack sizes of > 300MB, where basically every single file in the installation is replaced, aren't a good sign either.

--
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

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

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 xilinx.com has been very handy. Smart.

J

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.

HTH Michal

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

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

Hope that helps!

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

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

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!

Cheers, Martin

##### Makefile starts here

TOP=osc SOURCES=osc.py dco.py .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 bits:work/$(TOP).bit work/$(TOP).bit:work/$(TOP).ncd 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

synth:work/$(TOP).ngc 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

clean: rm -rf work/*

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

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

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

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

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Exactly. But that's a common problem in all of the industry nowadays. Look at digital cameras. They advertise more and more megapixels, but noone ever says something like "30% less image noise than the previous model". So you get more and more pixels, but the actual image quality (which in my thinking should be the deciding factor) deteriorates from generation to generation. Same with TV: HDTV is all the hype, but what does a higher resolution help if you use a crappy lossy video compression codec for transmission and a display that doesn't have a decent deinterlacing circuit and smears motions over 50 frames?

Advertising improved quality somehow implies that you didn't do a good job before, so all the hype is about things that weren't there before, not things (like bugs) that were removed.

That's what marketing thinks, at least. But I believe most engineers think differently. I guess most of us would be happy to have less features, but being sure they all work all right. And I'm talking here about the products we design as well as the products we use.

cu, Sean

--
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

I think the mentality is that you need new features to get new customers. Fixing old issues keeps old customers happy, but that's not good for growth.

-a