34 Design Flaws in 20 Days of Intel Core Duo 356
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."
Re:Should've gone with AMD (Score:4, Informative)
AMD errata (Score:5, Informative)
First time with BUGs?!?! (Score:5, Informative)
Huh? That's clearly wrong. When Intel had its famous FDIV bug, they shipped it knowing that the problem was there (the chips were already manufactured before they noticed it in their internal design validation.) In fact I would highly doubt that any Intel chip (or AMD chip) has shipped without some known bugs in them.
Its just a question of severity. Most of these bugs tend to be highly marginal in a "real software doesn't push that hard on the CPU" sense.
Why is this an Apple issue? (Score:5, Informative)
All modern processors have bugs on release (Score:5, Informative)
Of course, what happens is that the alpha/beta silicon ships to select customers without many errata (though internal testing often finds them too, and they ship with those). Then the manufacturer goes back, resolves a few, then the cycle repeats until everyone is happy with the bugs and it's released with a book of errata on them, and workarounds for the severe ones.
"No fix" errata are common. The most serious of those have workarounds. Fixed errata are for things where there can be no possible software workaround. But there's a large number of varying severity - from cache incoherences, lock failures (you try to lock something, and it either can't be unlocked the usual way, or it doesn't reliably indicate lock), to bus and spec violations.
Nothing new here...
Image Mirror (Score:3, Informative)
All CPU, controllers, etc. have errata... (Score:5, Informative)
For eample...
The MPC7410 family of chips (aka G4) from Freescale (formally part of Motorola) has 21 errata currently listed: MPC7410CE.pdf [freescale.com]
The MPC7447 family of chips (aka G4) from Freescale has 36 errata currently listed: MPC7457CE.pdf [freescale.com]
The PPC 970FX (aka G5) from IBM has 24 errata currently listed: 970fx_errata_dd3.x_v1.6.pdf [ibm.com]
AMD Opteron errata (Score:3, Informative)
Re:20 days? (Score:5, Informative)
http://www.amd.com/us-en/assets/content_type/whit
There's a lot more listed there than for the Core Duo so far, and quite a few marked as "Won't be Fixed" and are scary sounding. Here's an example of a rather nasty looking ordering bug that results in system hang:
Downstream non-posted requests to devices that are dependent on the completion of an upstream
non-posted request can cause a deadlock in the presence of transactions resulting in bus locks, as shown in the following two scenarios:
1. A downstream non-posted read to the LPC bus occurs while an LPC bus DMA is in progress. The legacy LPC DMA blocks downstream traffic until it completes its upstream reads.
2. A downstream non-posted read is sent to a device that must first send an upstream non-posted read before it can complete the downstream read.
In both cases, a locked transaction causes the upstream channel to be blocked, causing the deadlock condition.
Potential Effect on System
The system fails due to a bus deadlock.
It's normal to not fix silicon bugs (Score:5, Informative)
Unless the bug is so fatal that you can't work around it, or the bug could potentially cost lives, the primary solution is to work around it. Either you write driver code to avoid the bug, or you find some other cheap solution. Sometimes, it's a simple matter of removing a feature from your marketing literature.
Intel's typical means to mask processor bugs is microcode. This hurts performance, but they can typically create a workaround that routes everything around the bug. I can't read the article (it's slashdotted), but I'm sure that by saying they won't fix some bugs, they're saying that they won't respin the silicon but rather mask the bug in some other way.
Listing the bugs (and not fixing them in this version) is an appropriate thing for Intel to do.
(I'm no Intel fanboy. I think they're bastards. But this is NOT an example of them being bastards.)
Re:Does anyone know.... (Score:5, Informative)
Google html of the pdf:
http://64.233.179.104/search?q=cache:HFDm3zBojEcJ
Amd's original (pdf!)
http://www.amd.com/us-en/assets/content_type/whit
I think this is what he meant (Score:3, Informative)
Re:Should've gone with AMD (Score:5, Informative)
I didn't bother to actually count the number of unfixed or no fix planned glitches / bugs in there, so I don't know if it actually validates the 80+ the grandparent claimed, but there are quite a few known bugs in A64 and its HTT bus.
In fact there are going to be any CPU released, even stuff like Power / Itanium / USpark are going to have errata like this. Microprocessors are inredibly complex equipment, and 100% stable and glitch free under all possible conditions just isn't going to happen. Who ever submitted this story is blowing this entirely out of proportion. The link is already Slashdotted so I haven't gotten a chance to read what the bugs / glitches are, but I would be good money a normal user could go through the entire life of their Core Dou Mac and never notice one. These are typically very small gliches / bugs that occur under very specific conditions, and are meant more for hardware manufacturers to be aware of than they are to warn a user there could be problems with their chips.
publishing them publicly I think is a good move on Intel's part, but they do run this risk where people don't understand that this is a completely and utterly ordinary and expected thing to happen.
Re:Should've gone with AMD (Score:4, Informative)
Re:No buy (Score:3, Informative)
Re:Does anyone know.... (Score:1, Informative)
Re:Oh thats it! (Score:2, Informative)
I like #7 and #11 myself
Apple hasn't used that rainbow-colored apple logo in ages, have they?
Re:No buy (Score:5, Informative)
The documented and known errata are not what you should be concerned with. It's the unknown ones that freeze your computer or cause all robots to attack their masters.
If someone's complaining about this, they should just turn off their computers, because as we ALL know, every operating system (the OS is what runs on chips that have the errata) also are shipped with hundreds, if not thousands, of known bugs. You're not going to find a perfect chip in the real world. How many errata did the G4/G5 have? By comparison the IBM PowerPC 970FX has 24 errata, none of which is planned for a fix. When you consider the 970FX is a fairly mature chip, 34 errata on a new chip is hardly news worthy. As transistors get more and more compact and miniaturized, I'm sure we're bound to see more.
Re:It's normal to not fix silicon bugs (Score:4, Informative)
That's true. Every Intel CPU since the Pentium Pro can update its microcode. Many times, BIOS will contain microcode updates from Intel. Linux also has a microcode update driver [urbanmyth.org].
"I'm sure that by saying they won't fix some bugs, they're saying that they won't respin the silicon but rather mask the bug in some other way."
I'm not sure about that. "Will fix" seems to imply the errata could be fixed in silicon or microcode, while "Will not fix" means it won't get fixed at all.
Re:All modern processors have bugs on release (Score:1, Informative)
Re:It's normal to not fix silicon bugs (Score:3, Informative)
A workaround isn't considered as a FIX, WONTFIX is wontfix even with published workarounds (including microcode). WONTFIX means that the error won't be fixed at the silicon level, which is the subject of errata papers.
Re:Faster (Score:5, Informative)
Given the fact that a very substantial part of the extra chip estate is being used as L1 and L2 chache, the error rate should increase less than proportionally. If you upgrade cache size from say 8 kB to 1 MB, then there is only a relative small increase in complexity of the cache controler, not of the cache itself.
Add the new chip design software and the use of hardware libraries for standard chip functionality, then the error rate should increase even slower.
"85 pages" is a misleading comment. (Score:5, Informative)
I don't dispute your comment regarding the experience of a chipset designer.
Re:It's normal to not fix silicon bugs (Score:4, Informative)
So if you look at the list of errata, you see things like flags not getting set properly after the execution of an instruction. What could cause this? 1.) The design was logically incorrect. 2.) The design was logically correct, but the flag is never properly latched on the correct cycle for all hardware. 3.) The flag doesnt get set for slow hardware. 4.) The flag doesn't get set for hardware that has issues with supply integrity. Etc etc.
One would think that if they screwed up the implementation of a long-lived feature, it wasn't a logic error (likely to be caught by running verification) but an error caused by the analog or physical world intruding upon the digital domain. Some small amount of this may be expected-- oh crap! 1% of chips have an obscure timing issue we can't catch in test-- but if it is a true logic bug, someone screwed up.
Re:There isn't anything out of the ordinary about (Score:3, Informative)
Complexity of the CPU contributes some to the amount of bugs - more project work = more bugs, though only in cases of introducing new algorithms, not in case of adding "more of the same" - dual core CPU is NOT supposed to have twice as many bugs as single-core counterpart, because the two cores are identical, contain the same flaws as the single core, and new ones are introduced only by the extra glue logic that makes it "dual". Twice the complexity usually means twice the number of gates, not twice the difficulty of design - stuff like cache memory swallows a major part of available space but 64KB of cache is associated with the same number of bugs as 4MB of it. So not x2 by complexity. At most x1.5 or so.
And thet errors are not manufacturing flaws, they are design flaws / software (VHDL) bugs. If I write a program twice as long as original and save it to a harddrive of double the capacity, am I expected to have four times as many bugs? The new technology has its own share of problems but they are to be caught before releasing the chip from the factory, and chip that has a technology-related fault is just faulty and should be replaced. It has nothing to do with what appears in errata.
So - the new CPU can have more bugs than the old one. But not four times as many!
Re:Up front (Score:4, Informative)
For those still reading books, I suggest "Computer Architecture" by John L. Hennessy and David A. Patterson.
Radicode
Re:Up front (Score:2, Informative)
Re:Up front (Score:2, Informative)
Re:Thank you (Score:2, Informative)
Re:Hardware vs. Software testing (Score:3, Informative)
Secondly, no, these chips are probably revision 8 or 9 internally; they'll typically do a few runs at a time to make sure that yields are where they want them to be, and that mechanically the chip checks out. However, you can not do intrinsic debugging at this level, because of the simple supply problem; there are not enough chips made at this point to get all of your engineers looking at them. This is why most manufacturers won't catch an error until the first production run is underway, and by then it's far too late to go back to your design drafts, fix a bug, and re-tape the processor. It'd delay the product by 4-6 months; you've got to remake all of your lithograph templates and make sure they're all exactly created to spec, you've got to re-send out all of these plates to all of your fabs, you've got to then go through recert and make sure that the chips work (yes, that means you have to make more wafers of bad chips), and then you're still looking at debug time.
And for what? Your processor's accidentially got a single instruction that's lightly flawed which can be checked and fixed in software (if (value == (INTEL_DEBUG_VALUE && expected_value)) { intel_fix(); } ).
Lastly, if you need an example of any product shipping flawed, take a look over at the car industry. There are recalls, after recalls, after recalls on parts that are often bad, and require a new bolt to fix something. Think of this as the same thing, only you don't have to take your car into the garage; you are likely to never know, speak with, or hear of the people who are fixing the problems mentioned in this article. These are problems for OS developers, who are working in debug mode, who *might* run into this problem if and only if some crazy absurd bit-pattern is laid out just right in a register when a command is executed (for example).
So please, before you tell a Computer Engineer how to make a microprocessor, make sure you know what you're talking about. It's better that they catch these problems in the weeks after release so that the OS developers will have time to fix them before their next major version goes out and they actually have to release a patch to deal with it. It's better that they catch them before they run the next production run, just in case there is an error that warrants fixing (and they've only discovered ONE of such errors, and they are probably going to wait until Core Duo rev B to do it). And it's better that they catch them at all, instead of a year down the line when everyone starts to realize their floating point math is going screwy on their multimillion dollar simulations.
Re:"one of the first times"? (Score:3, Informative)
Every chip Intel has ever shipped has had errata. This isn't unique to Intel, of course -- every chip ever shipped has had errata. The only news here is that apparently people have found a lot of bugs in this specific chip fairly quickly. But Mac users are a demanding bunch...
http://www.amd.com/epd/desiging/tsdocs/2.erratash
http://www.rcollins.org/Errata/ErrataSeries.html [rcollins.org] documents some Intel errata from the late 90's.
http://mysearch.intel.com/corporate/default.aspx?
http://www.freescale.com/webapp/search/MainSERP.j
You get the idea.