Xilinx ISE 8.2
in [FPGA]
|
From: doug on 25 Jan 2007 16:28 steve.lass(a)xilinx.com wrote: > Doug, > > The case was created on December 6, 2006. We reproduced the problem in-house > and > created the CRs on December 13. This was after 9.1i was released. > > CR 430822 is a memory leak and has been scheduled to be fixed in 10.1 to > coincide with > an intiative we have to fix memory issues. We're going to try to fix CR > 430823 in 9.2. > > Regarding spending an hour running Valgrind and finding all of the memory > leaks, that might > make sense for a smaller application, but isn't possible for a multi-million > line program that > has a large number of developers. We do use Valgrind and have spent at least > a man year > on this resulting in many of the issues found and fixed, but not all. > > Steve > > Thank you for your reply but it does leave me puzzled. I am not the only one to have experienced memory leak problems with ISE as shown by the warnings on your website. Xilinx has known about the memory leak problems for at least a year now. Xilinx does not plan to fix the memory leak problems for another year. That means you are shippin nonfunctional software for TWO YEARS. This is something that would do Microsoft proud and is a poweerful argument for open source software. Memory leaks are due to sloppy or incompetent programmers. Not fixing them is due to poor management. Things like scheduling bug fixes for releases is also odd. What are service packs for? Are there so many pressing bugs that you have a year's worth of bug fixes lined up? This is a scary thought. I hope it just means that the management puts little effort into bug fixes and only works on them when there is nothing else to do. Of course, that is scary as well. I realize that you and Austin and Peter are not personally responsible for these issues but you are the only ones we have to discuss the issues with. These comments are not out of anger but rather out of frustration. Thank you for taking the time.
From: ammonton on 25 Jan 2007 15:35 doug <doug(a)doug> wrote: > Memory leaks are due to sloppy or incompetent programmers. Not fixing > them is due to poor management. Obviously I can't speak for Xilinx, but IME some leaks are due to design errors that can require whole subsystems to be rewritten to fix properly. That alone makes such fixes unsuitable for service packs, and when you additionally have to take into account how the fix affects other subsystems then postponing it to a future major release isn't as dumb as it seems. At work I have to deal with these types of issues all the time (very large, old codebase with new features continually being added and no documentation for the underlying design). -a
From: Ben Jones on 26 Jan 2007 05:00 <ammonton(a)cc.full.stop.helsinki.fi> wrote in message news:epb4ak$evj$1(a)oravannahka.helsinki.fi... > doug <doug(a)doug> wrote: > >> Memory leaks are due to sloppy or incompetent programmers. Not fixing >> them is due to poor management. > > Obviously I can't speak for Xilinx, but IME some leaks are due to > design errors that can require whole subsystems to be rewritten to fix > properly. Entering the conversation rather late, but as an (internal) user of the ISE tools and someone else who has seen their fair share of these memory issues, I thought I ought to chime in. I'm not going to leap to the defence of the ISE programmers and pretend that there are no problems, but I wanted to draw attention to what I see as an important distinction between two similar but separate issues: (1) Memory leaks, and (2) Excessive memory consumption. No-one will argue that problem (1) is acceptable in commercial production software. However, a lot of the time what looks like a memory leak is really just problem (2): an inefficient algorithm that consumes a massive amount of memory when it runs, but is in fact perfectly well-behaved in terms of returning memory to the system when it has finished with it. (Usually this is a result of someone writing the simplest possible algorithm to get the job done, not expecting it to become the critical section of code. I think it's fair to say most of us have been guilty of that at one time or another! :-)) Many times, I and other developers in my group have encountered excessive runtimes and memory consumption for synthesizing quite simple pieces of HDL code. Upon investigation, this has often turned out to be due to complexity of coding style - for example, nested loops in VHDL function calls are a common culprit. Usually there turns out to be a way to re-phrase the code in question so that XST behaves better. Often what seems to happen is that problems in class (2) are deemed "annoyances" rather than defects, and thus get a lower priority than "real" bugs that cause crashes or data corruption. Nevertheless, the bottom line is that the more people who report that they're having problems, the more likely something is to get fixed. So please, carry on complaining... :-\ -Ben-
From: Martin Thompson on 26 Jan 2007 08:37 Daniel O'Connor <darius(a)dons.net.au> writes: > Martin Thompson wrote: >> 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 > > Sure that's VHDL mode? I can't see anything in the docs about simulation.. > Yep, definitely... It's in the compilation section as none of it is simulation specific, I just target the Modelsim compiler. >> 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. > > Hmm, it looks very interesting but I use Verilog :) > Ahh, in that case, sorry, you're out of luck I think. Unless verilog-mode is as far on as vhdl-mode... >> 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. > > I need to know the commands.. I am software guy and all the "compile" steps > are confusing :) > See my makefile I posted elsewhere on this thread... Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: doug on 26 Jan 2007 14:45
Ben Jones wrote: > <ammonton(a)cc.full.stop.helsinki.fi> wrote in message > news:epb4ak$evj$1(a)oravannahka.helsinki.fi... > >>doug <doug(a)doug> wrote: >> >> >>>Memory leaks are due to sloppy or incompetent programmers. Not fixing >>>them is due to poor management. >> >>Obviously I can't speak for Xilinx, but IME some leaks are due to >>design errors that can require whole subsystems to be rewritten to fix >>properly. > > > Entering the conversation rather late, but as an (internal) user of the ISE > tools and someone else who has seen their fair share of these memory issues, > I thought I ought to chime in. I'm not going to leap to the defence of the > ISE programmers and pretend that there are no problems, but I wanted to draw > attention to what I see as an important distinction between two similar but > separate issues: > > (1) Memory leaks, and > (2) Excessive memory consumption. > > No-one will argue that problem (1) is acceptable in commercial production > software. However, a lot of the time what looks like a memory leak is really > just problem (2): an inefficient algorithm that consumes a massive amount of > memory when it runs, but is in fact perfectly well-behaved in terms of > returning memory to the system when it has finished with it. (Usually this > is a result of someone writing the simplest possible algorithm to get the > job done, not expecting it to become the critical section of code. I think > it's fair to say most of us have been guilty of that at one time or another! > :-)) > > Many times, I and other developers in my group have encountered excessive > runtimes and memory consumption for synthesizing quite simple pieces of HDL > code. Upon investigation, this has often turned out to be due to complexity > of coding style - for example, nested loops in VHDL function calls are a > common culprit. Usually there turns out to be a way to re-phrase the code in > question so that XST behaves better. > > Often what seems to happen is that problems in class (2) are deemed > "annoyances" rather than defects, and thus get a lower priority than "real" > bugs that cause crashes or data corruption. Nevertheless, the bottom line is > that the more people who report that they're having problems, the more > likely something is to get fixed. > > So please, carry on complaining... :-\ > > -Ben- > > Just to be clear in this case here are the differences in 7.1 and 8 or 9 for the same project. ISE 7.1 max memory useage about 120mB and 5 minutes ISE89 crashes at 2GB after an hour. This is definitely the memory leak category. The other question, of course is how they managed to write bad enough code to take 50 times as long (when 8 or 9 crashes, it is about 25% done). Even if it did not crash, this would be a major pain as it implies a xst process time of around four hours. |