With the early dies with thousands of transistors you really can see the logic gates, once it gets to the millions you can see the structures minimized and multiplied but once it gets to the billions on modern dies it becomes so small and abstract I wonder if any image can capture the detail contained in them.
I've got a copy of "High Tech: Window to the Future"
by Gene Bylinsky. It's got an actual Am8052 die embedded in the front cover. Published in 1986, so it is ancient, but it covers they heyday of microprocessor development, when transistors were big enough to see. It's not a "deep" boo, but it does have plenty of pretty pictures.
That maker list is unusable. It's not sorted in any way, contains duplicates (MOS Technology & Commodore CSG are the same), and would gain from reorganizing some brands (gathering Nintendo CPUs together, for instance).
I belive what we today see as x86 started with the 386, from 1985-ish. Not 8008 which is a completely different architecture and ISA.
Todays PCs run AMD x64, which some people call x86-64. But again this is a completely different beast compared to the good old x86. It was introduced in 2000 after Intels 64 architecture proposal failed miserably.
Most instructions of 8008 are still implemented by the latest Intel-AMD CPUs, even if for most of them there is normally no reason to use them, especially in a 64-bit program, where operations with 8-bit registers should be avoided.
Intel 8080 has changed some instruction encodings and it has replaced a few instructions, but it has retained almost all the 8008 instruction set as a subset. Intel 8086 has changed completely the instruction encodings, but again it has retained almost all the 8080 instruction set as a subset. The Intel 8086 instruction set is still implemented completely by the most recent Intel-AMD CPUs, remaining assembly-code compatible with 8080 and even with much of the 8008 assembly code.
In 64-bit mode, a few of the 8086 instructions are removed and for the others, if they reference memory, the 64-bit addressing modes are used instead of the 16-bit addressing modes, but otherwise they still work like in 8086, or even like in 8080 or 8008, if they belong to those subsets.
Insufficient support for operations with 8-bit registers is a bottleneck even in 64-bit CPUs.
For example, let's suppose that you have a for loop. You could update 8 uint8 values simultaneously by packing them into a uint64 and adding a constant. But when you need to unpack those 8 bytes to actually use them as indexes, the unpacking costs a lot of CPU cycles, so you lose the advantage you gained by avoiding 8 separate additions.
All you can do is access AH and AL (or `SIL`, `DIL`, `BPL`, `SPL`, etc.), but this does not take just 1 CPU cycle. It takes many cycles, and only the lowest bytes can be accessed. There is a lot of performance left on the table because of insufficient support for small registers inside larger registers.
Just because they can execute some similar instructions it doesnt mean they are the same. 8008 came from a common-bus design with an accumulator-centric ISA, which is miles aways from today's x64.
Besides, ISA is just the CPU frontend and does not reflect the uarch. You can probably make a Ryzen execute ARM or MIPS code by changing a few frontend opcode / fw tables.
I would imagine this is of decent interest to people reverse engineering chip designs, or doing failure analysis, so it’s possible someone might actually be trying this at scale.
You can destructively deprocess dies, removing a layer at a time and imaging at each layer. 20ish years ago you could still do this with a polishing wheel and a fine slurry; don’t know if that’s still viable.
In Glasgow there was a hair salon called "Curl Up and Dye", but until now I never realised the implication of uploading a file to a server to fab a processor.
That's what Lynn Conway's students did with FTP, before curl was a thing!
December 5-6, 1978: The MIT class's layout files, encoded in CIF 2.0 (Caltech Intermediate Form), were transmitted over the ARPANET to Xerox PARC. Nineteen projects were merged for fabrication. Micro Mask made the masks; Hewlett-Packard's Deer Creek research facility in Palo Alto fabricated the wafers. Packaged chips, individually wire-bonded to connect the appropriate project, were available for testing in January 1979. Conway's course archive gives January 18.
December 4, 1979: The larger MPC79 run closed submissions at 5 p.m. Pacific. It contained 82 projects from 124 designers at 12 universities, arranged across 12 die types on two wafer sets. Distribution of the packaged, custom-wire-bonded chips began January 2, 1980: 29 days later.
The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in. David's project is in the lower right corner of the first image, and you can see his name "LEVITT" if you zoom way in.
Here is a photo of a chalkboard with status of the various projects:
The final sanity check before maskmaking: A wall-sized overall check plot made at Xerox PARC from Arpanet-transmitted design files, showing the student design projects merged into multiproject chip set.
One of the wafers just off the HP fab line containing the MIT'78 VLSI design projects: Wafers were then diced into chips, and the chips packaged and wire bonded to specific projects, which were then tested back at M.I.T.
We present a design for a class of computers whose “instruction sets” are based on LISP. LISP, like traditional stored-program machine languages and unlike most high-level languages, conceptually stores programs and data in the same way and explicitly allows programs to be manipulated as data, and so is a suitable basis for a stored-program computer architecture. LISP differs from traditional machine languages in that the program/data storage is conceptually an unordered set of linked record structures of various sizes, rather than an ordered, indexable vector of integers or bit fields of fixed size. An instruction set can be designed for programs expressed as trees of record structures. A processor can interpret these program trees in a recursive fashion and provide automatic storage management for the record structures. We discuss a small-scale prototype VLSI microprocessor which has been designed and fabricated, containing a sufficiently complete instruction interpreter to execute small programs and a rudimentary storage allocator.
Here's a map of the projects on that chip, and a list of the people who made them and what they did:
Just 29 days after the design deadline time at the end of the courses, packaged custom wire-bonded chips were shipped back to all the MPC79 designers. Many of these worked as planned, and the overall activity was a great success. I'll now project photos of several interesting MPC79 projects. First is one of the multiproject chips produced by students and faculty researchers at Stanford University (Fig. 5). Among these is the first prototype of the "Geometry Engine", a high performance computer graphics image-generation system, designed by Jim Clark. That project has since evolved into a very interesting architectural exploration and development project.[9]
Figure 5. Photo of MPC79 Die-Type BK (containing projects from Stanford University):
The text itself passed through drafts, became a manuscript, went on to become a published text. Design environments evolved from primitive CIF editors and CIF plotting software on to include all sorts of advanced symbolic layout generators and analysis aids. Some new architectural paradigms have begun to similarly evolve. An example is the series of designs produced by the OM project here at Caltech. At MIT there has been the work on evolving the LISP microprocessors [3,10]. At Stanford, Jim Clark's prototype geometry engine, done as a project for MPC79, has gone on to become the basis of a very powerful graphics processing system architecture [9], involving a later iteration of his prototype plus new work by Marc Hannah on an image memory processor [20].
[...]
For example, the early circuit extractor work done by Clark Baker [16] at MIT became very widely known because Clark made access to the program available to a number of people in the network community. From Clark's viewpoint, this further tested the program and validated the concepts involved. But Clark's use of the network made many, many people aware of what the concept was about. The extractor proved so useful that knowledge about it propagated very rapidly through the community. (Another factor may have been the clever and often bizarre error-messages that Clark's program generated when it found an error in a user's design!)
9. J. Clark, "A VLSI Geometry Processor for Graphics", Computer, Vol. 13, No. 7, July, 1980.
[...]
The above is all from Lynn Conway's fascinating web site, which includes her great book "VLSI Reminiscence" available for free:
These photos look very beautiful to me, and it's interesting to scroll around the hires image of the Quux's Lisp Microprocessor while looking at the map from page 22 that I linked to above. There really isn't that much too it, so even though it's the biggest one, it really isn't all that complicated, so I'd say that "SIMPLE" graffiti is not totally inappropriate. (It's microcoded, and you can actually see the rough but semi-regular "texture" of the code!)
This paper has lots more beautiful Vintage VLSI Porn, if you're into that kind of stuff like I am:
A full color hires image of the chip including James Clark's Geometry Engine is on page 23, model "MPC79BK", upside down in the upper right corner, "Geometry Engine (C) 1979 James Clark", with a close-up "centerfold spread" on page 27.
Is the "document chip" on page 20, model "MPC79AH", a hardware implementation of Literate Programming?
If somebody catches you looking at page 27, you can quickly flip to page 20, and tell them that you only look at Vintage VLSI Porn Magazines for the articles!
There is quite literally a Playboy Bunny logo on page 21, model "MPC79B1", so who knows what else you might find in there by zooming in and scrolling around stuff like the "infamous buffalo chip"?
With the early dies with thousands of transistors you really can see the logic gates, once it gets to the millions you can see the structures minimized and multiplied but once it gets to the billions on modern dies it becomes so small and abstract I wonder if any image can capture the detail contained in them.
I would pay for this as a high quality book. Ideally some info and detail about each processor. Anyone else?
I've got a copy of "High Tech: Window to the Future" by Gene Bylinsky. It's got an actual Am8052 die embedded in the front cover. Published in 1986, so it is ancient, but it covers they heyday of microprocessor development, when transistors were big enough to see. It's not a "deep" boo, but it does have plenty of pretty pictures.
https://openlibrary.org/works/OL6322148W/High_Tech?edition=k...
https://www.ebay.com.au/itm/334312859146
https://arenamag.com/silicon
That maker list is unusable. It's not sorted in any way, contains duplicates (MOS Technology & Commodore CSG are the same), and would gain from reorganizing some brands (gathering Nintendo CPUs together, for instance).
I can't believe x86 is half a century old, and we're still using it.
I belive what we today see as x86 started with the 386, from 1985-ish. Not 8008 which is a completely different architecture and ISA.
Todays PCs run AMD x64, which some people call x86-64. But again this is a completely different beast compared to the good old x86. It was introduced in 2000 after Intels 64 architecture proposal failed miserably.
Most instructions of 8008 are still implemented by the latest Intel-AMD CPUs, even if for most of them there is normally no reason to use them, especially in a 64-bit program, where operations with 8-bit registers should be avoided.
Intel 8080 has changed some instruction encodings and it has replaced a few instructions, but it has retained almost all the 8008 instruction set as a subset. Intel 8086 has changed completely the instruction encodings, but again it has retained almost all the 8080 instruction set as a subset. The Intel 8086 instruction set is still implemented completely by the most recent Intel-AMD CPUs, remaining assembly-code compatible with 8080 and even with much of the 8008 assembly code.
In 64-bit mode, a few of the 8086 instructions are removed and for the others, if they reference memory, the 64-bit addressing modes are used instead of the 16-bit addressing modes, but otherwise they still work like in 8086, or even like in 8080 or 8008, if they belong to those subsets.
Insufficient support for operations with 8-bit registers is a bottleneck even in 64-bit CPUs.
For example, let's suppose that you have a for loop. You could update 8 uint8 values simultaneously by packing them into a uint64 and adding a constant. But when you need to unpack those 8 bytes to actually use them as indexes, the unpacking costs a lot of CPU cycles, so you lose the advantage you gained by avoiding 8 separate additions.
All you can do is access AH and AL (or `SIL`, `DIL`, `BPL`, `SPL`, etc.), but this does not take just 1 CPU cycle. It takes many cycles, and only the lowest bytes can be accessed. There is a lot of performance left on the table because of insufficient support for small registers inside larger registers.
Lacking modularity of the ISA, I can understand why many of those instructions were carried forward.
But all the legacy operating modes too? A modern x86 cpu should only have 2:
# Full-on 64 bit, legacy cruft cleared out as much as possible
# A compatibility mode to run application code written for 32-bit protected mode OSes like Win2k/XP etc
And even that last mode could be optional. Any other legacy support is just waste of transistors imho (however 'few').
Intel made a move in that direction years ago (X86S). Sadly that went nowhere.
Just because they can execute some similar instructions it doesnt mean they are the same. 8008 came from a common-bus design with an accumulator-centric ISA, which is miles aways from today's x64.
Besides, ISA is just the CPU frontend and does not reflect the uarch. You can probably make a Ryzen execute ARM or MIPS code by changing a few frontend opcode / fw tables.
Well the computer is 80 years old and we're still using those.
Fascinating.
The site links to its original pictures which allow zooming in much further on a phone revealing more details.
See also Ken Shirriff's blog, which has die photos plus detailed explanation of how things work.
https://www.righto.com/
https://news.ycombinator.com/from?site=righto.com
Have people tried training models to decode these photographs into code?
How would you do that if there's like 60 layers of metal conductors over the silicon substrate?
Fair. I guess it would be necessary to CT scan them, like the Vesuvius Challenge
Not sure if regular tomography would work, but this has been done at high enough resolution with some fancier techniques (ptychography): https://www.nature.com/articles/s41586-024-07615-6
I would imagine this is of decent interest to people reverse engineering chip designs, or doing failure analysis, so it’s possible someone might actually be trying this at scale.
You can destructively deprocess dies, removing a layer at a time and imaging at each layer. 20ish years ago you could still do this with a polishing wheel and a fine slurry; don’t know if that’s still viable.
Computer, enhance!
We need two people on the keyboard at the same time to enahnce.
Has been seen to work before: https://youtu.be/kl6rsi7BEtk?si=mXLk7yJwgTfn09as&t=12
It’s like taking a picture of someone’s house to determine their current medical diagnosis.
Garbage in, it’ Herpes.
Could have just said to determine where all the pipes are but you know, you could go all the way to herpes I suppose… :)
https://github.com/giulioz/mmo-chip described in talk https://youtu.be/5211iYEqnzo?t=44m30s
Amazing site. I've a friend who is an aspiring oil painter and I just sent him this link. I can't wait to see the results!
Not all, I’m missing at least a DMG-CPU-A from John McMaster’s site, siliconprawn.org
I know of some that are freely available but are missing. Has anyone figured out how to get word to them?
Here is one more (intel 4004)
https://image.jimcdn.com/app/cms/image/transf/none/path/s674...
In Glasgow there was a hair salon called "Curl Up and Dye", but until now I never realised the implication of uploading a file to a server to fab a processor.
That's what Lynn Conway's students did with FTP, before curl was a thing!
https://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.htm...
December 5-6, 1978: The MIT class's layout files, encoded in CIF 2.0 (Caltech Intermediate Form), were transmitted over the ARPANET to Xerox PARC. Nineteen projects were merged for fabrication. Micro Mask made the masks; Hewlett-Packard's Deer Creek research facility in Palo Alto fabricated the wafers. Packaged chips, individually wire-bonded to connect the appropriate project, were available for testing in January 1979. Conway's course archive gives January 18.
December 4, 1979: The larger MPC79 run closed submissions at 5 p.m. Pacific. It contained 82 projects from 124 designers at 12 universities, arranged across 12 die types on two wafer sets. Distribution of the packaged, custom-wire-bonded chips began January 2, 1980: 29 days later.
https://news.ycombinator.com/item?id=31758139
Here's some historic Vintage VLSI Porn that I posted 6 years ago, from Lynn Conway's famous VLSI Design course at MIT:
https://en.wikipedia.org/wiki/Lynn_Conway
https://ai.eecs.umich.edu/people/conway/conway.html
https://news.ycombinator.com/item?id=8860722
DonHopkins on Jan 9, 2015 | on: Design of Lisp-Based Processors Or, LAMBDA: The Ul...
I believe this is about the Lisp Microprocessor that Guy Steele created in Lynn Conway's groundbreaking 1978 MIT VLSI System Design Course:
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.html
My friend David Levitt is crouching down in this class photo so his big 1978 hair doesn't block Guy Steele's face:
The class photo is in two parts, left and right:
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class2s.jp...
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class3s.jp...
Here are hires images of the two halves of the chip the class made:
http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c...
http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c...
The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in. David's project is in the lower right corner of the first image, and you can see his name "LEVITT" if you zoom way in.
Here is a photo of a chalkboard with status of the various projects:
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Status%20E...
The final sanity check before maskmaking: A wall-sized overall check plot made at Xerox PARC from Arpanet-transmitted design files, showing the student design projects merged into multiproject chip set.
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Checkplot%...
One of the wafers just off the HP fab line containing the MIT'78 VLSI design projects: Wafers were then diced into chips, and the chips packaged and wire bonded to specific projects, which were then tested back at M.I.T.
http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Wafer%20s....
Design of a LISP-based microprocessor
http://dl.acm.org/citation.cfm?id=359031
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf
Page 22 has a map of the processor layout:
https://web.archive.org/web/20230427181813if_/https://i.imgu...
We present a design for a class of computers whose “instruction sets” are based on LISP. LISP, like traditional stored-program machine languages and unlike most high-level languages, conceptually stores programs and data in the same way and explicitly allows programs to be manipulated as data, and so is a suitable basis for a stored-program computer architecture. LISP differs from traditional machine languages in that the program/data storage is conceptually an unordered set of linked record structures of various sizes, rather than an ordered, indexable vector of integers or bit fields of fixed size. An instruction set can be designed for programs expressed as trees of record structures. A processor can interpret these program trees in a recursive fashion and provide automatic storage management for the record structures. We discuss a small-scale prototype VLSI microprocessor which has been designed and fabricated, containing a sufficiently complete instruction interpreter to execute small programs and a rudimentary storage allocator.
Here's a map of the projects on that chip, and a list of the people who made them and what they did:
http://ai.eecs.umich.edu/people/conway/VLSI/MPCAdv/SU-BK1.jp...
1. Sandra Azoury, N. Lynn Bowen Jorge Rubenstein: Charge flow transistors (moisture sensors) integrated into digital subsystem for testing.
2. Andy Boughton, J. Dean Brock, Randy Bryant, Clement Leung: Serial data manipulator subsystem for searching and sorting data base operations.
3. Jim Cherry: Graphics memory subsystem for mirroring/rotating image data.
4. Mike Coln: Switched capacitor, serial quantizing D/A converter.
5. Steve Frank: Writeable PLA project, based on the 3-transistor ram cell.
6. Jim Frankel: Data path portion of a bit-slice microprocessor.
7. Nelson Goldikener, Scott Westbrook: Electrical test patterns for chip set.
8. Tak Hiratsuka: Subsystem for data base operations.
9. Siu Ho Lam: Autocorrelator subsystem.
10. Dave Levitt: Synchronously timed FIFO.
11. Craig Olson: Bus interface for 7-segment display data.
12. Dave Otten: Bus interfaceable real time clock/calendar.
13. Ernesto Perea: 4-Bit slice microprogram sequencer.
14. Gerald Roylance: LRU virtual memory paging subsystem.
15. Dave Shaver Multi-function smart memory.
16. Alan Snyder Associative memory.
17. Guy Steele: LISP microprocessor (LISP expression evaluator and associated memory manager; operates directly on LISP expressions stored in memory).
18. Richard Stern: Finite impulse response digital filter.
19. Runchan Yang: Armstrong type bubble sorting memory.
The following projects were completed but not quite in time for inclusion in the project set:
20. Sandra Azoury, N. Lynn Bowen, Jorge Rubenstein: In addition to project 1 above, this team completed a CRT controller project.
21. Martin Fraeman: Programmable interval clock.
22. Bob Baldwin: LCS net nametable project.
23. Moshe Bain: Programmable word generator.
24. Rae McLellan: Chaos net address matcher.
25. Robert Reynolds: Digital Subsystem to be used with project 4.
Also, Jim Clark (SGI, Netscape) was one of Lynn Conway's students, and she taught him how to make his first prototype "Geometry Engine"!
http://ai.eecs.umich.edu/people/conway/VLSI/MPCAdv/MPCAdv.ht...
Just 29 days after the design deadline time at the end of the courses, packaged custom wire-bonded chips were shipped back to all the MPC79 designers. Many of these worked as planned, and the overall activity was a great success. I'll now project photos of several interesting MPC79 projects. First is one of the multiproject chips produced by students and faculty researchers at Stanford University (Fig. 5). Among these is the first prototype of the "Geometry Engine", a high performance computer graphics image-generation system, designed by Jim Clark. That project has since evolved into a very interesting architectural exploration and development project.[9]
Figure 5. Photo of MPC79 Die-Type BK (containing projects from Stanford University):
http://ai.eecs.umich.edu/people/conway/VLSI/MPCAdv/SU-BK1.jp...
[...]
The text itself passed through drafts, became a manuscript, went on to become a published text. Design environments evolved from primitive CIF editors and CIF plotting software on to include all sorts of advanced symbolic layout generators and analysis aids. Some new architectural paradigms have begun to similarly evolve. An example is the series of designs produced by the OM project here at Caltech. At MIT there has been the work on evolving the LISP microprocessors [3,10]. At Stanford, Jim Clark's prototype geometry engine, done as a project for MPC79, has gone on to become the basis of a very powerful graphics processing system architecture [9], involving a later iteration of his prototype plus new work by Marc Hannah on an image memory processor [20].
[...]
For example, the early circuit extractor work done by Clark Baker [16] at MIT became very widely known because Clark made access to the program available to a number of people in the network community. From Clark's viewpoint, this further tested the program and validated the concepts involved. But Clark's use of the network made many, many people aware of what the concept was about. The extractor proved so useful that knowledge about it propagated very rapidly through the community. (Another factor may have been the clever and often bizarre error-messages that Clark's program generated when it found an error in a user's design!)
9. J. Clark, "A VLSI Geometry Processor for Graphics", Computer, Vol. 13, No. 7, July, 1980.
[...]
The above is all from Lynn Conway's fascinating web site, which includes her great book "VLSI Reminiscence" available for free:
http://ai.eecs.umich.edu/people/conway/
These photos look very beautiful to me, and it's interesting to scroll around the hires image of the Quux's Lisp Microprocessor while looking at the map from page 22 that I linked to above. There really isn't that much too it, so even though it's the biggest one, it really isn't all that complicated, so I'd say that "SIMPLE" graffiti is not totally inappropriate. (It's microcoded, and you can actually see the rough but semi-regular "texture" of the code!)
This paper has lots more beautiful Vintage VLSI Porn, if you're into that kind of stuff like I am:
http://ai.eecs.umich.edu/people/conway/VLSI/MPC79/Photos/PDF...
A full color hires image of the chip including James Clark's Geometry Engine is on page 23, model "MPC79BK", upside down in the upper right corner, "Geometry Engine (C) 1979 James Clark", with a close-up "centerfold spread" on page 27.
Is the "document chip" on page 20, model "MPC79AH", a hardware implementation of Literate Programming?
If somebody catches you looking at page 27, you can quickly flip to page 20, and tell them that you only look at Vintage VLSI Porn Magazines for the articles!
There is quite literally a Playboy Bunny logo on page 21, model "MPC79B1", so who knows what else you might find in there by zooming in and scrolling around stuff like the "infamous buffalo chip"?
http://ai.eecs.umich.edu/people/conway/VLSI/VLSIarchive.html
http://ai.eecs.umich.edu/people/conway/VLSI/VLSI.archive.spr...
sitkack on June 16, 2022 | prev [–]
The Mead Conway book is absolutely beautiful, I have like 3 copies.
https://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V2/...