Slashdot Mirror
34 Design Flaws in 20 Days of Intel Core Duo
Pray_4_Mojo writes "Geek.com is reporting that Intel's errata (bug) documentation shows that the Intel Core Duo chip has 34 known issues found in the 20 days since the launch of the iMac Core Duo. (you can read the list) with only plans to fix one of them. While bugs in hardware is nothing new (the P4 has 64 known issues, at this time Intel does not plan to fix a single one) this marks one of the first times that Intel released a processor with known bugs, and some of the bugs are of higher severity than in the past. Also alarming is the rate the flaws have been found, at one and half per day since the launch of the iMac Core Duo."
this marks one of the first times that Intel released a processor with known bugs
No: either it is the first time or it is not. There can be only one... first time.
and some of the bugs are of higher severity then in the past
then != than
I want to drag this out as long as possible. Bring me my protractor.
It's a little disohnest to use the phrasing "Core Duo chip has 34 known issues found in the 20 days since the launch of the iMac Core Duo."
Most of these bugs were found well before the release of Core Duo. Many of the bugs are listed as having been observed by Intel only. That means the verficiation teams did hit these issues, either with very bizarre code setup, or doing something that's probably not technically legal anyway. Odds of seeing most of it in an end-user platform are very unlikely.
The problem with x86 comes from the fact that a large number of instructions interact in relatively complex ways with others. Changing a small amount of silicon can change a side-effect of an instruction, which is then a bug. An ISA such as Alpha eliminated this by keeping inter-instruction interactions to a minimum (no condition registers, etc).
I am TheRaven on Soylent News
So not only how many bugs in Athlon, etc, but also...
How many bugs in other Pentium chips?
What was the rate of discovery of bugs in other chips?
Keep in mind that during Intel's entire history they've released one desktop processor that had a bug sufficient to require a recall. Most of the bugs are easily worked around including that one. Hell, I've got an old P60 that I was using as a router until the last year or so and it just worked fine and it was always amusing to see Linux notice the FDIV bug on boot.
This sig has been temporarily disconnected or is no longer in service
It seems likely that given the increasing complexity, the error rate is going to rise proportionally. I mean, how many errors do you expect in a 100,000 transistor chip vs a 100,000,000 transistor chip?
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
That assumes that intel wants the safety critical market for this processor. In most cases, when you develop in this sector, you have to use hardware that is specificly designed for these applications. developing chips that can be certified for SC applications can be a pain in the ass, and the may simply not car for this chip.
What I am saying is that in general, what's the use of getting better and faster at finding bugs if there aren't plans to fix it?
Because the purpose of finding silicon bugs is almsot never to fix it. Fixing CPU bugs is often impractical. You find the flaws so you can route around them. This is the case with every consumer chip on the market, including the one you are using to read this right now.
Information wants to be anthropomorphized.
Take a look at the error list for a second. Over 50% of them are caused by dropping the processor into Debug mode, with over 75% of them only being observed by Intel themselves. Now, certainly there are more bugs reported so far, but does that mean that there are actually more bugs, or that Intel is getting better at finding bugs and reporting them?
Time will only tell.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I think your estimates are *way* off.
Silicon fab facilities are extremely expensive and capital intensive, but they produce shitloads of chips. The process scales; making 1000 wafers in these fabs is as easy as making one.
Engineering analysis of complex IC designs is a perfect example of combinatorial explosion. Each bit of state in the chip doubles the state space in which bugs can exist. Yes, *most* of that state is in the cache which has regularity in its structure, but that regularity didn't happen by accident: it was *designed* that way.
You can only test to a spec, and if the spec is imperfect and has gaps, you will leave space for bugs. Given that specs are written by engineers, they cannot be nearly complete for anything other than the most trivial circuits; the infrastructure used to suppor engineering of non-trivial circuits could itself have bugs.
The part of the spec that covers the cache is simple, and can conceivably be error-free and well-tested, and perhaps with methods that are amenable to mathematical proof. But that's not where the errors crop up. The errors crop up in the hugely complex mechanisms that handle all the pipelining, branch prediction, translation to microinstructions, handling of interrupts, etc., etc., that are not highly regular and modular and are not easy to spec, and are not easy to approach with formal methods.