HP Nanoprocessor part II: Reverse-engineering the circuits from the masks(righto.com)
righto.com
HP Nanoprocessor part II: Reverse-engineering the circuits from the masks
http://www.righto.com/2020/09/hp-nanoprocessor-part-ii-reverse.html
5 comments
I wonder if you could train a neural network to analyze these masks. I.e. going from physical mask images back down to EDA simulation without humans needing to decode everything visually.
There is pretty impressive work going on in bioinformatics, using image segmentation to digitally reconstruct three dimensional networks of tens of thousands of neurons:
https://www.youtube.com/watch?v=h6dF0htsTFc
https://www.youtube.com/watch?v=PeyHKdmBpqY
So yeah, probably!
https://www.youtube.com/watch?v=h6dF0htsTFc
https://www.youtube.com/watch?v=PeyHKdmBpqY
So yeah, probably!
Going from the masks to circuitry is straightforward. I wrote a program that turns the masks into connected components, finds transistors, and organizes the transistors into gates.
The harder problem is starting with die photos rather than clean masks. I did a few experiments with machine learning and TensorFlow but I couldn't get anything useful out of it. One problem is that every chip I look at is very different in how it looks under the microscope. By the time you manually create enough training data, you're halfway done with the chip. And then I couldn't get good results from the machine learning (which is probably my fault, not a fundamental issue).
The harder problem is starting with die photos rather than clean masks. I did a few experiments with machine learning and TensorFlow but I couldn't get anything useful out of it. One problem is that every chip I look at is very different in how it looks under the microscope. By the time you manually create enough training data, you're halfway done with the chip. And then I couldn't get good results from the machine learning (which is probably my fault, not a fundamental issue).
Author here to answer your questions about the Nanoprocessor :-)
Thanks for another great post!
One thing I don't fully understand is the economics. How could HP make a processor that was competitive with the 6800 using inferior metal gate technology (which presumably meant a much bigger die size) for only $15 compared to $360 for the 6800?
One thing I don't fully understand is the economics. How could HP make a processor that was competitive with the 6800 using inferior metal gate technology (which presumably meant a much bigger die size) for only $15 compared to $360 for the 6800?
My guess is that there were two aspects to the economics. First, Motorola's price included a big profit margin, since the price rapidly dropped when the 6502 provided competition. Second, if HP already had paid for a metal-gate fab, it was probably cheaper to use it than build a new fab.
How about another question: why doesn't your site redirect http to https??
I'll see myself out...
Cool article! Its crazy to me that back in the day schematics and layouts were drawn by hand and LVS was done by inspection. Now it's all RTL with day-long place and route followed by many-hour LVS.
I'll see myself out...
Cool article! Its crazy to me that back in the day schematics and layouts were drawn by hand and LVS was done by inspection. Now it's all RTL with day-long place and route followed by many-hour LVS.
> why doesn't your site redirect http to https
My site is a mess with the blog hosted by Blogger, images stored on AWS, and other files elsewhere, and Cloudflare thrown on top. It was a considerable effort to get https to work at all. I tried a Blogger option to force https and it broke everything for a day so I'm hesitant to try again. I figure that people can go to https directly if it's important to them.
My site is a mess with the blog hosted by Blogger, images stored on AWS, and other files elsewhere, and Cloudflare thrown on top. It was a considerable effort to get https to work at all. I tried a Blogger option to force https and it broke everything for a day so I'm hesitant to try again. I figure that people can go to https directly if it's important to them.
> > why doesn't your site redirect http to https
Please don't; if we want https, we can[1] do that redirection on the browser side; doing it on the server side means your site doesn't work[0] with user agents that don't include whatever random cryptographic code your site has decided to make de-facto mandatory.
> I figure that people can go to https directly if it's important to them.
Exactly, thank you.
0: because `GET /whatever` no longer returns a http response body; the fact that the status code is 3xx rather than 200 OK or the presence of a Location header isn't directly relevant.
1: Obviously it's good to support https in addition to http; it's not supporting http that's a problem.
Please don't; if we want https, we can[1] do that redirection on the browser side; doing it on the server side means your site doesn't work[0] with user agents that don't include whatever random cryptographic code your site has decided to make de-facto mandatory.
> I figure that people can go to https directly if it's important to them.
Exactly, thank you.
0: because `GET /whatever` no longer returns a http response body; the fact that the status code is 3xx rather than 200 OK or the presence of a Location header isn't directly relevant.
1: Obviously it's good to support https in addition to http; it's not supporting http that's a problem.
If you can serve HTTP-Strict-Transport-Security (HSTS) headers on https, you can maybe set your favicon to load via https?
It's not a redirect, but a modern browser will load everything from https after that. (Until the hsts header expires)
It's not a redirect, but a modern browser will load everything from https after that. (Until the hsts header expires)
Speaking of increment/decrement architectures and Turing completeness, the Brainfuck programming language provides only one-byte increment, decrement, index via the single register and inc/dec, and branch-on-zero operations, and is Turing complete. It is very specifically designed to be unpleasant to program in, but to provide a glow of satisfaction at having succeeded in programming anything at all recognizable.
A Brainfuck interpreter in Brainfuck is around ~4-500 bytes. In C, it has been achieved (taking truly gross liberties with C semantics) in 144 bytes -- about two lines, necessarily including substrings "main(c,v)" and "putchar(".
Programming a nanoprocessor would differ from programming Brainfuck, but would feel curiously familiar.
A Brainfuck interpreter in Brainfuck is around ~4-500 bytes. In C, it has been achieved (taking truly gross liberties with C semantics) in 144 bytes -- about two lines, necessarily including substrings "main(c,v)" and "putchar(".
Programming a nanoprocessor would differ from programming Brainfuck, but would feel curiously familiar.
Seeing the detail analysis of what is now an esoteric item is really fascinating. How much work does it take to get a close look at a chip this sized?
I haven't taken die photos of the Nanoprocessor myself (yet), but it's pretty easy with a chip like that. Since it has a metal lid, it can be opened up in about 5 seconds with a chisel; no boiling acids required. The inconvenient part is that you need a metallurgical microscope to get a good view. A metallurgical microscope shines the light down through the lens so you get a clear image under high magnification. You can see interesting stuff with a regular microscope or an inspection scope, but the details are obscured.
To make a detailed die photo, I take about 50-100 closeup image and then stitch them together using the Hugin panorama program. This usually takes a couple of hours.
To make a detailed die photo, I take about 50-100 closeup image and then stitch them together using the Hugin panorama program. This usually takes a couple of hours.