[HN Gopher] A CT scanner reveals surprises inside the 386 proces...
___________________________________________________________________
A CT scanner reveals surprises inside the 386 processor's ceramic
package
Author : robin_reala
Score : 138 points
Date : 2025-08-09 17:17 UTC (5 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here for all your CT scanning questions :-)
| OptionOfT wrote:
| What is your CPU's yearly deductible?
| loa_in_ wrote:
| Is the CPU destroyed by the process or did you reassemble this
| particular specimen?
| kens wrote:
| I took the metal lid off the chip to improve the scan
| quality. If I had left the chip intact, it would probably be
| fine. (I assume the X-ray levels are low enough to avoid
| damage, but I haven't confirmed that.)
| johnklos wrote:
| This isn't about CT scanning, but about the chip itself.
|
| Since the bond wires are just hanging out in air, does this
| mean that a chip like this could be ruined by dropping it which
| might cause the bond wires to move enough to short something?
|
| Thanks for all your hard work!
| imoverclocked wrote:
| Does it look like the _almost_ connected pins could have been
| purposely severed during production? ie: could they have been
| connected and then using a calculated pulse of power,
| disconnected?
| kens wrote:
| If they installed wire bonds and removed them, there would be
| visible remnants on the die, which aren't there.
| TZubiri wrote:
| What CT scanner was used? The images are surprisingly detailed
| for something so small, while we are used to coarser scales of
| human anatomy.
| kens wrote:
| It's a Lumafield scanner, but I don't know the specific
| model.
| bunabhucan wrote:
| What is the last node/cpu that had the smallest features
| visible at optical microscope scales?
| s1110 wrote:
| Genuine question: the website doesn't work in Russia. Did you
| restrict the access or is it my ISP doing that? Someone tries
| to prevent me from studying of very niche info on ancient Intel
| CPUs. Thanks! P.S. Big fan of your work!
| Mountain_Skies wrote:
| > From the circuitry on the die, this pin appears to be an
| output. If someone with a 386 chip hooks this pin to an
| oscilloscope, maybe they will see something interesting.
|
| Would be a fun surprise if the 386 had its own Halt and Catch
| Fire mode.
| mrlonglong wrote:
| Where's A0 and A1?
| kens wrote:
| Since the 386 is a 32-bit processor, the address specifies a
| 32-bit word and doesn't use address bits A0 and A1. But what if
| you just want to read a byte or a 16-bit word? The trick is
| that the 386 provides four Byte Enable outputs (BE0#-BE3#) that
| indicate which bytes in the word are being transferred. Of
| course, it's not that simple. If the lower 16 bits of the data
| bus aren't being used, the upper 16 bits of the data bus are
| duplicated on the lower 16 bits to make 16-bit buses more
| efficient (somehow).
| mrlonglong wrote:
| Neat, saves two wires.
| phire wrote:
| Yes and no. You replaced two address pins with four byte
| enable pins.
|
| But the byte enable pins also implicitly communicate size,
| which would otherwise require another two pins. So this
| byte enable scheme breaks even (at least for chips with
| 16bit or 32bit buses).
|
| The main goal is simplify the design of the motherboard.
| gregsadetsky wrote:
| Hey @kens, congrats on the page! Extremely super small usability
| note/suggestion: if you changed your inputs (above the tool that
| lets you see all of the layers) to something like this:
| <input name="layer" type="radio" onclick="show('https://static.ri
| ghto.com/images/386-package/layer0.jpg')" id="layer1">
| <label for="layer1">Pins</label>
|
| then it would be possible to click the label name (i.e. Pins, I/O
| Vcc, etc.) instead of having to click the small radio circles.
|
| It's a small thing, but I think it's a lot more fun/easy/fast to
| click the different label names rather than the circles. It's
| truly a small nit - just in case it's an easy fix for you.
| Cheers!
|
| (just to make sure: you need to add a unique "id" attribute for
| each "input", and then make a <label> tag for each label
| referencing that id in the "for")
| kens wrote:
| Thanks for pointing this out. I should have remembered the
| label tag. I've updated the page so it should work better now.
| mlhpdx wrote:
| A bit of a trip down memory lane for me. I performed an analysis
| of the thermo-mechanical cyclic fatigue in later packages using
| detailed CAD, FEA and empirical tests. A lot of work went into
| finding it wasn't a big deal for the most part. Still, I don't
| recommend that museums power cycle old PCs daily...
| nxobject wrote:
| Knowing nothing about how survival/durability testing is done
| in VLSI: how did you do the empirical tests?
|
| For example, I know that thermal samples for the Pentium 5-era
| Xeon (Jayhawk) were produced, but I'd always wondered Intel
| went from the dummy to realizing "oh, shit, this is going to be
| way too hot in the long run."
| mlhpdx wrote:
| I can't really speak to the thermals other than as an input
| to my work. I was narrowly focused on the cyclic loading
| based on the temperature gradients (etc.) I was given.
| devmor wrote:
| Super cool! This was the CPU in my very first PC (which I got to
| build myself, under the tutelage of a family friend). I remember
| that it was cooled by nothing but a tiny stick-on heatsink and a
| small plastic fan that clipped on top of that.
|
| 8MB of DRAM, a 250MB spinning disk hard drive, 5.25 and 3.5 inch
| floppy bays, removable bios that I had to sort through a
| tupperware of chips to find the correct unit, some unnamed AGP
| video card that I had to slot removable chips into as well and a
| great big 16" CRT.
|
| I think I had to install a special serial card in an ISA slot to
| use a mouse too.
| bartread wrote:
| > some unnamed AGP video card
|
| Do you mean VGA rather than AGP? AGP came much later than the
| 386 and wouldn't have been supported by its motherboard
| chipsets.
___________________________________________________________________
(page generated 2025-08-09 23:00 UTC)