Pentium-III autopsy | Hacker News Reader

Pentium-III autopsy

sciencystuff.com

316 pointssathyabhat23 comments

Interesting stuff. The method of inverting the die and bonding it to the processor carrier is called Flip-Chip (https://secure.wikimedia.org/wikipedia/en/wiki/Flip_chip), and replaced bonding wires for higher density and better thermal properties (you get direct access to the back of the silicon substrate)

The electron microscope images are all cross-sectional, because it appears he doesn't have the equipment to do surface etching, and just cleaved the chip. I've not generally seen good sectional images around though, so it's definitely an interesting look.

http://www.flylogic.net/blog/ has a lot of stuff about depackaging and reverse-engineering chips, as does "Dr Decapitator" (http://decap.mameworld.info/), who decaps old arcade ROMs, and then extracts their actual data from micrograph images to produce romfiles for emulators.

Edit:

The Sparkfun Saga of the Fake MCUs:

Part 1: https://webcache.googleusercontent.com/search?q=cache:kMgE8B...

Part 2: https://webcache.googleusercontent.com/search?q=cache:mEZ-8g...

Part 3: https://webcache.googleusercontent.com/search?q=cache:3Tlcu2...

(Links via google cache because they seem to have broken their old news URL structure)

Edit^2: I forgot I had this old image of a System-in-Package radio module that I made myself (Digital camera through optical microscope at, iirc, 20x)

http://metavore.org/faff/chip.jpg

The thick black lines at the bottom are millimetre markings on a ruler. The processor is at the centre, and the various other modules are SAW filters (https://secure.wikimedia.org/wikipedia/en/wiki/SAW_filter#SA...)

I am a circuit designer and SEM cross-sections are quite commonly used by transistor device designers during design and debug. They also appear in papers about transistor device design. A relevant conference is International Electron Devices Meeting and the related journal paper is IEEE Transactions on Electron Devices. Unfortunately, most of those papers are behind the IEEE paywall.

Chipworks is a company that reverse engineers chips for analysis by competitors. Their websites has lots of cool SEM cross-sections: http://www.google.com/search?cx=w&q=chipworks+SEM&tb...

Even though I design circuits using these devices, I still find the SEMs mindblowing.

You'll probably see this on the Sparkfun saga, but the way to remove it at the Atmega lab (with a hotplate and acetone) is quite dangerous. Don't try that at home.

Instead, drop the whole chip in a test tube of fuming nitric acid at room temp, and let it work slowly overnight. Anything with fuming nitric acid is dangerous, but this is much safer than the hot plate method. See this tutorial by Travis Goodspeed:

http://travisgoodspeed.blogspot.com/2009/06/cold-labless-hno...

Yeah, it's not something I'd attempt without a fume hood and someone who knows what they're doing.

The pic of mine had a simple brazed metal 'lid', which I managed to separate by scraping out the solder with a scalpel, and then finally a hot-air gun to melt the rest and pop the top off.

I'm sure I've seen references to HF (Hydrofluoric acid) used in depackaging, but since it also etches silicon, I'd imagine you'd need to be pretty amazingly accurate with it.

Ordinarily, you use (fuming) nitric acid. This dissolves the epoxy packaging, but leaves silicon and metal intact.

You need the HF to etch the top layers of metal/silicon from the die. These layers are above the actual circuitry, and help increase security so that an attacker can't steal IP by using nitric acid and microprobes or UV light to modify the operation of the IC. Flylogic has a special technique by which they selectively etch areas of the metal layers, but not the circuitry below.

Reminds me of the breakdown of the Mifare Classic RFID cards, but on a much larger scale. They took cross-sectional images of the circuits, then used a Matlab script to turn the images back into simulated circuits. Then they performed cryptanalysis on it! Papers and video: http://events.ccc.de/congress/2007/Fahrplan/track/Hacking/23... The video is long but entertaining :)

Edit: if the torrents aren't being seeded anymore, you can watch the video here http://www.podcast.tv/video-episodes/24c3-2378-mifare-282189... or download from ftp://media.ccc.de/congress/24C3/matroska/24c3-2378-en-mifare_security.mkv

For an interesting look at the defense measures, see "Physical Security Devices for Computer Subsystems: A Survey of Attacks and Defences" http://www.atsec.com/downloads/pdf/phy_sec_dev.pdf

IIRC there's a chapter on it in "Security Engineering" by Ross Anderson, too: https://www.cl.cam.ac.uk/~rja14/book.html (whole 1st edition is at the bottom of the page)

Edit: The story of Chris Tarnovsky and his work in satellite TV smartcards is also a pretty good read - http://www.wired.com/politics/security/news/2008/05/tarnovsk...

Kinda off-topic, but does anyone know how many registers the P-III and later have? I've read the P-II has 40, so I assume later chips have many more.

Register allocation is one of the more expensive phases in a compiler, and register allocation on the Intel instruction set is particularly hard because it has some few registers. It's kinda ironic that internally modern chips have zillions of registers. There's a fat chunk of software that squeezes a program in 8 registers and then a fat chunk of silicon that expands into however many registers the chip has. Not only is this wasted effort, the extra silicon costs Intel in terms of power consumption and it one reason at ARM are pWning them on low power platforms.

The P-III has 8 general purpose registers, just like all pre-64bit x86 CPUs, all the way back to the 8086. x86-64 (aka amd64) CPUs have 16.

But it gets a bit more complicated. I'm talking about (and your references to compilers suggests that you are as well) architectural registers; the things assembly programmers and compiler writers see.

The actual register file in the CPU has many more registers on out-of-order CPUs like the Pentium Pro and later; these are physical registers, and are mapped to the architectural registers dynamically by the register renamer. This is done to prevent false dependencies from preventing parallel execution of instructions in the same instruction stream.

The work done by the compiler to map live variables into architectural registers is mostly orthogonal to the work the CPU's instruction scheduler does to map architectural registers to physical ones. In some sense, more architectural registers are better, but there are diminishing returns, and eventually other considerations make more worse. x86-64's 16 architectural registers is a pretty good compromise for current generation CPUs.

Your comparison between ARM CPUs and x86 is somewhat spurious, since the instruction set defines the architectural registers: 16 for x86-64, 32 for ARM. A given out-of-order implementation can choose whatever number of physical registers gives optimal performance, and given the stakes and available engineering resources, both ARM and Intel/AMD will choose optimal (or exceptionally close to optimal) numbers for this.

Long story short, the number of architectural registers is an extremely small part of why ARM is or isn't "pWning" Intel on low power platforms.

Jeri Ellsworth makes NMOS transistors on silicon wafer chips at home, with an oven, rust remover and some other home chemicals: http://www.youtube.com/watch?v=w_znRopGtbE

I actually still have a P-III laying around here from an old PC that was being thrown, but the slot version with a massive heatsink. Just gathering dust, but a piece of history...

My bittorrent machine is a P-III Coppermine at 667 Mhz. I found it in the middle of the street a year ago.

It's still a bit amazing to think back on that period, where you could get 50% gains in a year. I remember dropping a big chunk of my savings as a teenager to buy a 700 coppermine, 4 years later they were sitting on roads even if they still worked perfectly.

Clock speed was king then. I'm sure everyone remembers when they stalled out ramping up the clock speed around 3.4-3.6GHZ and then it's pretty much been "back to the drawing board" ever since.

Fun fact: The Pentium 4 was originally anticipated by Intel to eventually run at 10 GHz after a few years of process shrink. Seriously.

Fun fact: If Intel wanted to, they could release a 10 GHz Pentium 4 design CPU. But it would be single-core and draw 500W, and require a many-thousands-of-dollars cooling system.

Intel was quite correct in predicting that we would continue to get faster transistors, and the Pentium 4 was absolutely the right design to take advantage of faster transistors. The story of the past decade of CPU architecture is all about heat becoming a primary design problem for the first time in history.

The point is that they grossly underestimated the impact of the power wall. They were aware of the power issue and you can find early papers by Pentium 4 architects like Doug Carmean which address that concern and make it seem like they have it under control. Many engineers at Intel (including the main Pentium 4 architects) must have known the problem was more dire than that. But everyone falls prey to wishful thinking, and changing the bearing of a mammoth ship is not something easily accomplished.

> Pentium 4 was absolutely the right design to take advantage of faster transistors

No, it was a horrible design in many ways, irrespective of those constraints and any wishful thinking about the power wall, and it gave the advantage to AMD for years. Not a big surprise as it was designed by Intel's B team. The Pentium M which has been the microarchitectural basis for their subsequent desktop processors was designed by the A team.

everyone falls prey to wishful thinking

To be fair, nobody has ever designed a CPU based on current process technologies. Design teams are always saying "we think the process technology we'll end up working with will look something like this...", and based on past history there was no reason to think that the power issue wouldn't get solved like it had the past N times.

I'm certainly not claiming I could have done better. But the Pentium 4 was such a spectacular failure and Intel's competition managed to navigate that transition well enough that I feel a certain amount of pointing and laughing is justified. :)

Yeah, but to get those they had to make a much less efficient architecture (the P4 required more clock cycles to do the same things). The Pentium M (CPU part of Centrino), which I believe became the Core, was based off of the P3 architecture, and was faster at something like 33% lower click speed. So those 3+ GHz P4s were kind of evolutionary dead ends. But man, was it exciting when they broke 3...

This was true of pretty much every CPU generation before the P4. Deeper pipelines result in lower FO4 (and thus higher attainable clock frequency), but a higher penalty for branch misprediction, among other things.

Historically (pre-P4) this was a great tradeoff. The Alpha 21064 was a barn-stormer; it ran at nearly twice the Mhz of its brainiac competitors at the time. This more than made up for a deeper pipeline and simpler execution units.

What killed the P4 was that they hit the power wall. Moore's law scaling of gate size no longer resulted in a corresponding scaling of power usage.

It is hard to blame the P4 designers too much for this, since people have been prophesying the end of Moore's law since the mid-80s at least. They happened to be designing when it actually happened on power. Current designers should look to that lesson when relying on increasing density...

Of course, these lessons are pretty useless, because much like a stock market bubble, Moore's law continues on a given metric until it doesn't. And it is always obvious in retrospect.

The good thing since then is that industry started focusing on power consuption. Maybe the "mobile revolution" wouldn't take place if they kept running for clock improvements at each and every project.

I think that the best possible comment is: Simply Amazing!

Reply on news.ycombinator.com