Xilinx ISE 8.2
in [FPGA]
|
From: Sean Durkin on 24 Jan 2007 05:06 Martin Thompson wrote: > I don't suppose they'd want to advertise 30% less bugs would they? > Even though most engineers would rather see it :-) 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...
From: ammonton on 24 Jan 2007 07:56 Sean Durkin <news_jan07(a)durkin.de> wrote: > 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. 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
From: doug on 24 Jan 2007 14:15 jbnote 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 > So, Austin and the other Xilinx people that monitor the board-- Why is Xilinx not willing to take the hour to fix a show stopper problem that has existed for at least a year in at least NINE versions of ISE? There have been 7 sevice packs issued which still have this problem. This means it is a management decision to not fix things. The fact that the service pack and the release came at the same time was a very bad sign. On the other hand, could I get a job as a xilinx programmer, or better yet, as a manager. I have always had bosses who exptected me to do things correctly. This would be a nice change.
From: Austin Lesea on 24 Jan 2007 12:54 doug, This thread is not being ignored. I will comment when I have something useful to add to it. Trashing software is not uncommon. Especially when that software has become quite common (over 300,000 "seats" in use, not including Xilinx, Xilinx FAEs). I have a rule, which I call the "rule of tens." Sell ten of something, find all the bugs, fix them, and then sell some more. At or about the shipment of the 100th item, a bug is found, that is so bad, that you hear "how stupid could you be!" You fix that bug, and then go on. Again, at the 1000th ship date, another "totally fatal" bug happens, and again is heard "how..." I have seen this personally up to shipment of the 100,000th item (once upon a time). I have no doubts that there are bugs (I use the software, too). I also report my bugs, and I see the lists of "correction requests" which get found, and fixed. Generally speaking, we are also dependent upon others (Microsoft, Red Hat, Sun), so a "memory leak" may be some weird combination of an operating system, our code, and perhaps even Java. Add to that Dell, HP, and so on, with different 'compatible hardware' and it gets pretty tough. I offer no excuses: software quality is of the utmost importance. Please continue the thread, Austin
From: steve.lass on 24 Jan 2007 12:54
"Sean Durkin" <news_jan07(a)durkin.de> wrote in message news:51oelhF1kmsn8U1(a)mid.individual.net... > I think the main problem is that Xilinx releases new ISE versions in a > predefined schedule Text clipped. > 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 Actually, for the 9.1i release, feature freeze was in June 2006 and the release to manufacturing was in December. We spend about 6 months fixing bugs and improving quality. > > 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... Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The database was created in 1990 and needed to be rewritten and so did the GUI. > > 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... While it's true that the software team was working on 9.1i, bug reports for 8.2i would only be useless if the bug was fixed in 9.1i. Even getting duplicate bug reports is useful because it raises the priority of fixing that bug. > > What is it with that regular release cycle? It's not as simple as saying we will release when its ready because of other dependencies. We need to make sure all of our other software products (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and 3rd party tools all work together. Defining a release date and sticking to that date is the best way to accomplish this. So instead, we define a feature freeze date. If a feature can't be done by that date, it gets pushed to the next release. > > 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. I agree with all of this. To be honest, no customers told us they were using partial reconfig in ISE 4 - 7, so we did not make it a priority. Now it is, and we have a lot of customers using it. One final note. We do take quality and these posts seriously. In 8.1 and 8.2, we allowed features into the release after feature freeze and quality suffered. That has resulted in a quality initiative that I expect will have a dramatic effect over the next year or two. Don't be shy about reporting bugs to us and don't complain about bugs not being fixed if you don't report them. Steve Lass One of those Marketing guys. |