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.
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.
From: doug on 24 Jan 2007 14:15
>>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.
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
From: Austin Lesea on 24 Jan 2007 12:54
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,
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
I offer no excuses: software quality is of the utmost importance.
Please continue the thread,
From: steve.lass on 24 Jan 2007 12:54
"Sean Durkin" <news_jan07(a)durkin.de> wrote in message
> I think the main problem is that Xilinx releases new ISE versions in a
> predefined schedule
> 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
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
> 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
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
date is the best way to accomplish this. So instead, we define a feature
date. If a feature can't be done by that date, it gets pushed to the next
> 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,
we have a lot of customers using it.
One final note. We do take quality and these posts seriously. In 8.1 and
we allowed features into the release after feature freeze and quality
That has resulted in a quality initiative that I expect will have a dramatic
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.
One of those Marketing guys.