Xilinx ISE 8.2
in [FPGA]
|
From: jbnote on 23 Jan 2007 16:57 > Memory leaks come from sloppy programmers. Not fixing memory leaks > comes from lazy or incompetent programmers. Even incompetent programmers can manage this. The use of valgrind [http://www.valgrind.org] 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
From: bgshea on 23 Jan 2007 18:43 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 On Jan 23, 2:57 pm, "jbnote" <jbn...(a)gmail.com> wrote: > > Memory leaks come from sloppy programmers. Not fixing memory leaks > > comes from lazy or incompetent programmers.Even incompetent programmers can manage this. The use of valgrind > [http://www.valgrind.org] 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
From: Sean Durkin on 24 Jan 2007 01:19 bgshea wrote: > 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. Xemacs including VHDL mode is available for Windows as well. And you can install Cygwin (http://www.cygwin.com) 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...
From: Phil Hays on 24 Jan 2007 01:42 bgshea wrote: > ISE has been, IMHO, going down hill. With each new release the projects > become backward incompatible. 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. http://subversion.tigris.org/ As you like emacs, you might also like this: http://www.xsteve.at/prg/vc_svn/index.html -- Phil Hays (Xilinx, but always speaking for myself)
From: Sean Durkin on 24 Jan 2007 02:03
doug wrote: > 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. 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... |