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."
You do realize that there is an 85 page PDF of errors in the AMD64, right?
Revision Guide for AMD AthlonTM 64 and AMD OpteronTM Processors. Just for balance. (only two of them are really interesting, #113 is one of them IIRC)
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.
Apple is not the only manufacturer using the Core Duo chip.
Strange women lying in ponds distributing swords is no basis for a system of government.
It's called "errata", and it's common for most processors to be released with pages and pages and pages of errata.
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...
Not sure I understand the point of this new article... all chips have errata. This is like reporting that the sun set again or that slashdotters have no love life.
For eample...
The MPC7410 family of chips (aka G4) from Freescale (formally part of Motorola) has 21 errata currently listed: MPC7410CE.pdf
The MPC7447 family of chips (aka G4) from Freescale has 36 errata currently listed: MPC7457CE.pdf
The PPC 970FX (aka G5) from IBM has 24 errata currently listed: 970fx_errata_dd3.x_v1.6.pdf
And AMD has no bugs in their chips? Here's the Athlon 64 Revision History document off of AMD's own website:
e _papers_and_tech_docs/25759.pdf
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.
As an ASIC designer, I have produced my fair share of silicon bugs. Chips are expensive to produce, making bugs expensive to fix. As a result, chip designers (even ones with deep pockets like Intel) do not look at bugs as something to FIX, but rather as something to MASK. I don't mean to hide it from people (although that does happen), but to make it not a bug by working around it.
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.)
At least 136 in the Athlon.
: www.amd.com/us-en/assets/content_type/white_papers _and_tech_docs/25759.pdf+amd+athlon+errata&hl=en&c lient=firefox-a
e _papers_and_tech_docs/25759.pdf
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
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf
And as an aside, it took two seconds (actually .08) seconds to look up on Google. Maybe try that next time.
How pathetic are you that you follow me from topic to topic and waste all your mod points at once modding me down?
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.
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf
And you think that the A64, and P4 are clean and squaeky?
All chips have errata, and custmarily are well documented and are published on the vendor's web site. BTW, errata can be something as simple as a correction to the datasheet. Most are usually minor and are dealt with by the compiler. For example, if there's an error with calculations dealing with a certain registry and decimal values, the compiler would just not use that registry for the calculations.
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.
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.
Your comment is misleading. The document lists only 61 errata and contains their respective details. The initial table of errata -- table 5 -- is only four pages long (begins 13 and ends 16) and is most likely to group the problems by the wafer families; the next two pages reiterate the errata for each given brand name of AMD K7/K8 chip; all but one of the remaining pages detail the errata and their suggested workarounds/fixes. The last page is a list of extra resources.
I don't dispute your comment regarding the experience of a chipset designer.
And I would add that most "flaws" can be avoided by the compiler. Programmers (except the ones making the compiler) don't have to worry about those. These bugs occur in really rare conditions that can be avoided. CPU design is really complex... if you thought assembler instructions were executing one after the other, you're wrong. Usually, they will execute in mixed order, many at the same time. That's what makes a fast CPU.
For those still reading books, I suggest "Computer Architecture" by John L. Hennessy and David A. Patterson.
Radicode