Xilinx ISE 8.2
in [FPGA]
|
From: jesse lackey on 24 Jan 2007 03:45 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 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
From: Michal HUSEJKO on 24 Jan 2007 04:05 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: http://www.xess.com/appnotes/makefile.html 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
From: Martin Thompson on 24 Jan 2007 04:09 Daniel O'Connor <darius(a)dons.net.au> 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 register. Hope that helps! Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Martin Thompson on 24 Jan 2007 04:20 "bgshea" <bgshea(a)gmail.com> writes: <snip> > 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 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(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Martin Thompson on 24 Jan 2007 04:22
Sean Durkin <news_jan07(a)durkin.de> 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 :-) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html |