[HN Gopher] Siliconpr0n: High Resolution Chip Maps
___________________________________________________________________
Siliconpr0n: High Resolution Chip Maps
Author : lelf
Score : 275 points
Date : 2021-01-30 00:55 UTC (22 hours ago)
(HTM) web link (siliconpr0n.org)
(TXT) w3m dump (siliconpr0n.org)
| Panoramix wrote:
| How would I go about building an application for displaying very
| hi-res images like this? you know, allows to zoom, only load when
| it needs to, etc.
|
| Is it a big project? I'm really clueless (I'm not a programmer as
| you can tell though I know my way around Python).
| andrewf wrote:
| This site uses (1) prerendering different resolutions and (2)
| tiling.
|
| (1) If you take a look under
| https://siliconpr0n.org/map/intel/4004/m0_200x/l1-tiles/ you'll
| see that the 1/ subdirectory has the most zoomed-out version of
| the chip image, 2/ has slightly higher-res images, and so on
| until 6/, which is full-resolution.
|
| (2) Tiling means you might take a 12000x12000 (ie 144
| megapixel) image, and split it into a 20x20 grid of 600x600
| subimages (ie 0.36 megapixels each).
|
| When you go to a URL like
| https://siliconpr0n.org/map/intel/4004/m0_200x/#x=2160&y=189...
| the site will (1) use the z=3 parameter to know it should be
| loading images from under
| https://siliconpr0n.org/map/intel/4004/m0_200x/l1-tiles/3/ then
| (2) do some arithmetic with the x+y parameters, and the browser
| window dimensions, to figure out which subimages actually need
| to be loaded from the server.
|
| Zooming and panning can now be implemented by having your UI
| alter the x, y and z parameters.
|
| I figured this out by opening the network tab (View ->
| Developer -> Developer Tools in Chrome) and watching the
| browser load files when I did things. Because all the files
| have simple names like "1.jpg", "2.jpg" inside a directory
| structure, I needed to hover over the filenames to see the full
| image URLs in a tooltip.
|
| ===
|
| All of the above works with entire image files, which is good,
| because common file formats and APIs often won't let you do
| anything other than "load the entire file".
|
| Some file formats allow you to load part of an image
| effectively. For instance, many PDFs will let you read page 53
| by (a) reading enough of the header/index in the file (b)
| reading page 53, without needing pages 1-52 first. If you were
| writing something like a desktop image viewer you'd probably
| want to take advantage of this, but the details are likely to
| be very file-format-specific. You'd likely build on top of
| specialized libraries for TIFF, RAW, PDF and so on, rather than
| generic "load any image file" APIs.
| mmastrac wrote:
| Ooh. I sponsored a decap of a Casio SK-1 chip a while back. I
| need to contribute the scans to this (although they need to be
| stitched together).
| jmspring wrote:
| Shitty name for an informative site.
| johndmcmaster wrote:
| The topic has come up a few times and I'm not opposed to
| changing it. If a good replacement name came up and someone
| helped with logos etc I'd change it
| Something1234 wrote:
| This is the greatest name of all time. It's whimsical. It's
| full of internet humor and without the suits.
| rektide wrote:
| first, silicpr0n would be funnier, because it rhymes
| better/is more glib.
|
| disclaimer, before heading on: i'm not sure how i feel about
| it to be honest. it's ok i suppose. decent. but it feels
| uninspired, at this point: traditional, expected.
|
| yes, i love the site, what it does, what it shows. the name
| itself doesn't titilate me further, doesn't add to my
| enjoyment- i think. although i enjoy a little glibness, a
| little playfulness. it still is kind of manufactured.
| abandonedporn, architectureporn, cableporn, conduitporn,
| engineeringporn, futureporn, .... how many varieties of
| thing-"porn" do i need?
|
| my core meta-analysis? i do think the whole internet is as a
| local maxima where attaching -pron or -porn or -pr0n to the
| end of any subject is how we say "pretty pictures". i get it,
| it gets the point, "in your dreams", but like, we're deep
| into Simulacra & Simulation territory, third degree:
| simulacra now precedes reality, the signified becomes
| meaningless. porn itself, real porn, is often unreal, often
| part simulation, but it still is second order, still
| signified a real. unmooring ourselves from sex, using porn to
| just mean, "hardly believable attractive take" on a thing,
| it's a direct enough disassociation, it makes sense. but it's
| also tiring to me, exhausting, that we have no other frames
| of desire or beauty we can hitch ourselves to.
|
| i wouldn't mind finding some other ways to anchor ourselves,
| meaning. i want whimsy, i think there is "something" added by
| the playfulness, the bending of meaning. reviewing, i think
| i'm being kind of cantankerous in my assessment. but it does
| seem like we're low on good options. that this space could
| use some inspiration & opening.
| LargoLasskhyfv wrote:
| Imagine _AlphaPP_ for 1st rate pretty pictures instead?
| rbanffy wrote:
| I think they imaged the wrong side of the IBM z13.
|
| https://siliconpr0n.org/map/ibm/z13s_cpu/mz_mit5x/
| marcan_42 wrote:
| That is a top layer shot of a flip-chip die. Every modern
| complex IC looks like that. Any time you see a pretty die shot
| with identifiable blocks of any kind of modern CPU or SoC,
| instead of a grid of balls, it's because someone has gone
| through the trouble of removing most or all of the metal layers
| which obscure all the circuitry. Otherwise it looks like that
| photo. Balls and power buses.
| 1MachineElf wrote:
| I've never looked at images like this before. Really cool. I
| don't know the nomenclature, but one question I have is, why are
| the points where metal contacts touch the IC so... complicated?
| For example:
|
| There's a lot going on this AMD IC where the metal leads make
| contact with it. Not really sure what they are, just a bunch of
| wavy lines, maybe:
| https://siliconpr0n.org/map/amd/d87c51/mz_mit20x/#x=5299&y=1...
|
| Btw, I think it's really cool how the URL changes depending on
| what part of the image is zoomed in on.
| kens wrote:
| Those are output driver transistors. There's a pull-up
| transistor on one side of the pad and a pull-down transistor on
| the other. The transistors are interdigitated to make them
| large so they can provide high currents.
| [deleted]
| chronomex wrote:
| ESD protection Zener diodes, maybe?
| tt433 wrote:
| Throw in some post processing and these make good
| greebles/texture details
| systemvoltage wrote:
| Just wanted to comment on the usability of directory listings
| (Apache server?). No javascript bs, no UI frameworks, no SPA
| garbage, just good ol folder listing in HTML. Glorious, fast and
| shall I say, impeccable?
|
| In 2021, this would be a "card" based page, about 6 cards
| visible, rounded corners, and it would have fucking infinite
| scroll, ofcourse with spinners to let you know its processing.
| God, help us.
|
| Edit: I should clarify, I like JS for form submission and a few
| things. If you're building Google Docs competitor, by all means,
| go for SPA and big JS frameworks. That's what they're designed
| for.
| ashas451 wrote:
| Totally perfect apart from the fact I don't have a fuckin clue
| what most of this shorthand and naming means. Sort of detail
| someone might include on of those silly cards or newfangled js
| dohicky
| systemvoltage wrote:
| Lol, I empathize. Some description of what these folders mean
| would be helpful.
| mnem wrote:
| If you go up to the main site, you can get to the wiki which
| has descriptions. For example:
| https://siliconpr0n.org/archive/doku.php?id=type
| gorkish wrote:
| They aren't using it, but the Apache directory listing module
| does have support for descriptions that will be displayed
| beside the file names.
| cdubzzz wrote:
| Eh. It's pretty terrible on mobile, though. I can't read or
| click anything without zooming and a page load for each
| directory resets the zoom. I would say the content isn't really
| relevant for mobile users but the images themselves actually
| work pretty well on my device. Far better than the site itself.
| mgraczyk wrote:
| I think it's fine.
|
| The time it took me to double-tap zoom was less than the time
| it would have taken for an SPA to load over my weak ass
| T-Mobile connection
| rbanffy wrote:
| The whole website is probably smaller than a minimal React
| app...
| systemvoltage wrote:
| It's actually pretty decent on mobile IMO. Pinch and zoom is
| easy to do, atleast on the iPhone. Then you just scroll
| naturally. The entire page doesn't move on you.
|
| I agree with you in general, its not great on mobile, but
| it's not _terrible_. Far better than hamburger menu 'ed UI
| that I see in the wild that seems to show 1 card at a time
| and hijacks the scroll mechanism.
|
| A lot of "Not designed for mobile" fear stems from early days
| of smartphones in 2010-era which still lingers today. Things
| have changed. Screens have gotten much better in resolution,
| responsiveness has improved and touch experience on modern
| phones is exceptional.
| asddubs wrote:
| all they really need is a viewport tag to fix that. Weird
| that no one has bothered to do that yet, seems like it would
| be a one line pull request
| systemvoltage wrote:
| Thanks. TIL: > "This virtual viewport is a way to make non-
| mobile-optimized sites in general look better on narrow
| screen devices."
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Viewport_m...
| ObsoleteNerd wrote:
| At least for iOS: Double-tap in the white space between the
| directory links and the dates, it'll fit to the screen
| nicely.
| kayson wrote:
| That's so easy to solve with css. See something like
| https://github.com/Vestride/fancy-index
|
| Specifically: https://github.com/Vestride/fancy-
| index/raw/main/after_mobil...
| systemvoltage wrote:
| I actually find this [1] more readable than this [2].
|
| [1] https://github.com/Vestride/fancy-
| index/blob/main/before.png
|
| [2] https://github.com/Vestride/fancy-
| index/blob/main/after.png
|
| It's also not the same directory they're comparing. IMO why
| add padding? Why change #000000 to some grey text?
|
| Just add icons to [1] and you're good to go. May be use
| Sans-serif fonts if you wanna feel bit _~fancy~_.
| makeworld wrote:
| If you look at the mobile before and after it becomes
| more clear why this is useful.
| modeless wrote:
| I don't know why people are terrified of zooming. Frankly,
| zooming to use a desktop site is better UX than 90% of mobile
| sites. All you have to do is ensure your text lines aren't
| too long, which is good practice anyway.
|
| Maybe it's because iOS don't have a one finger zoom gesture
| like Android? I wonder why Apple never added that one?
| simonbw wrote:
| On iOS you can double tap a paragraph to zoom in on it.
| That's been around as long as I can remember.
| modeless wrote:
| Yeah it was in the first iPhone but you can't control the
| amount of zoom and it often guesses wrong or just doesn't
| work. I pretty much gave up on using it. On Android in
| most apps you can double tap, hold the second tap, then
| swipe up and down to zoom. It's a lot more natural than
| it sounds and it gives you precise control over both the
| zoom location and zoom amount.
|
| On iOS you can try the gesture in Maps, and then wonder
| why they never added it to Safari.
| paxswill wrote:
| AA sibling comment mentions double tap to zoom in on a
| paragraph, but there's also a single finger zoom (tap and
| hold, then move the held finger vertically) for Maps (and
| by default in MapBoxGL last I checked).
| modeless wrote:
| Yeah, in Android that's been available for a long time in
| almost all apps that support zooming, not just Maps. Most
| critically, Chrome.
| based2 wrote:
| By default, to me, it is not sorted by date in the correct
| order.
| johndmcmaster wrote:
| Glad you are enjoying! I've aggregated some question responses
| below to try to clarify a few things.
|
| Browsing the /map directory directly isn't intended to be
| informative in the way people are looking for. It's more of a
| file store that just happens to be browsable for advanced
| users. Rather this information is intended to be from the wiki
| which has more detail and is searchable etc. See for example:
| https://siliconpr0n.org/archive/doku.php?id=mcmaster:raspber...
|
| Similarly if you can find additional information the wiki such
| as image conventions
| (https://siliconpr0n.org/archive/doku.php?id=conventions) and
| additional copyright info (ex:
| https://siliconpr0n.org/archive/doku.php?id=tommi:start)
|
| I'm looking over people's suggestions and trying to see if
| there is anything I can take in to improve the site. Thanks for
| the feedback and feel free to reach out to me directly if you
| want to contribute something directly!
|
| PS: yes I know there is some crufty stuff on there like search
| is doing weird stuff right now with the side bar. I upgraded
| the wiki software recently and haven't yet been
| sillysaurusx wrote:
| Does anyone know which framework they're using to load the
| images google-maps style?
| https://siliconpr0n.org/map/intel/4004/m0_200x/#x=1603&y=145...
|
| I doubt it's a custom framework, but view source just shows
| uninformative compressed javascript and no info.
|
| I'd like to display my high resolution ML images in a similar
| way.
| adamhearn wrote:
| Looks like LeafletJS: https://leafletjs.com/
| scq wrote:
| Specifically, a tool called GroupXIV based on Leaflet.
| https://github.com/whitequark/groupXIV
| sillysaurusx wrote:
| Fantastic! Thank you both. Such a high quality repo, and
| only 28 stars.
|
| The viewer is really cool. I wonder if it'd be possible
| to modify it to display a folder of PNGs in a nice
| streamable way...
|
| (It looks like it only supports slicing a single png,
| whereas we usually have tens of thousands of pngs. I've
| been thinking of ways of letting people view lots of ML
| images better than e.g. how tensorboard does it.)
| johndmcmaster wrote:
| Even more specifically it's pr0nmap => GroupXIV =>
| leaflet. I use GroupXIV's javascript, but my own tile
| cutter
|
| https://github.com/JohnDMcMaster/pr0nmap
| sillysaurusx wrote:
| Thank you very much!
| Maha-pudma wrote:
| I couldnt agree more, I use ublock in advanced mode (even on
| mobile) and I was expecting to have to enable multiple scripts,
| which nearly always consist or analitics and ads, to be able to
| use this thing. Nope, all first party scripts, brilliant.
|
| Better folder descriptions maybe but other than that perfect!
| KronisLV wrote:
| Quick question: is there a particular reason why the table and
| the other elements aren't centered in the browser by default?
| Even this site seems to do that to some degree, which improves
| the usability at least somewhat.
|
| AFAIK that would require just a text-align rule for the title
| and margin-left: auto; and margin-right: auto; for the table,
| which seems a bit more readable on wide screens.
|
| Here's a screenshot: https://i.imgur.com/y447V3g.png
| 4ad wrote:
| I really dislike centered websites. That means that if I
| change the width of the browser window, the position of the
| website elements changes. So when I make the window bigger
| for ONE annoying tab that requires more width, it changes ALL
| other tabs. This is horrible for my muscle memory.
|
| Also, I arrange my windows such that overlapping windows
| don't hide important stuff underneath them. So I can see
| essential elements of a site even with chat windows on top.
| But if the website position changes on browser window width
| change, this invalidates ALL my other windows. It's simply
| awful.
|
| I want degrees of freedom to be independent, otherwise they
| are far less useful.
|
| People want centered websites because they are using browser
| windows that are far too wide, usually full screen. Just use
| a narrow browser window and left-aligned websites will look
| just fine. You'd think that with everyone having a narrow
| smartphone, websites would work well with narrow browser
| windows, but no, usually they use a different (bad!) layout
| on desktop browsers. I really hate this.
| airstrike wrote:
| _Apache /2.4.41 (Ubuntu) Server at siliconpr0n.org Port 443_,
| as a matter of fact
| astrange wrote:
| It's pretty good, but Apache tries to cut off long filenames
| and isn't Unicode-aware when it does this, so it looks untidy
| because names come out at apparently random lengths...
| drocer88 wrote:
| See here to fix the long filenames:
| https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html
|
| NameWidth=[n | *] The NameWidth keyword
| allows you to specify the width of the filename column in
| bytes.
| arduinomancer wrote:
| Are the colours in these images real or added for effect in post?
| kens wrote:
| The colors are real, mostly generated by thin-film interference
| depending on the thickness of the layers. Some people boost the
| saturation to make it more dramatic, but I think John's photos
| are natural.
|
| There's a color chart here:
| http://www.htelabs.com/appnotes/sio2_color_chart_thermal_sil...
| johndmcmaster wrote:
| Mostly yes (ex: through thin film interference as mentioned),
| but there may be significant color correction for things like
| halogen light yellow color. There are also techniques to
| produce colorful images such as DIC and using a confocal
| microscope (ex: the 4004 ones I believe are confocal)
| DonHopkins wrote:
| Wow, the 4004 is a thing of beauty. Pity how it turned out.
|
| https://siliconpr0n.org/map/intel/4004/m0_200x/#x=2688&y=202...
| klelatti wrote:
| Why a pity? Seems to have been the start of a good run for
| Intel.
| mysterydip wrote:
| The 4004 could have performed much better than it did (up to
| 3x faster) if intel hadn't insisted on the 16 pin DIP. This
| limited how much data could be accessed per cycle and relied
| on shift registers etc to get full instructions and memory.
| klelatti wrote:
| Yes, I remember Federico Faggin saying he was frustrated at
| Intel's policy on the number of pins.
|
| The whole exercise does seem like Faggin, Shima and Mazor
| trying to produce the chip with little help from the rest
| of Intel.
|
| I think given the target market though the speed wasn't a
| major issue and they soon rectified the mistake
| olejorgenb wrote:
| The watermark is really obnoxious. Did they really have to
| plaster it _all_ over the image?
|
| It's cool how "intel" (bottom right) and "FF" [1] (top right)
| is signed using the same process as the rest of the chip :D
|
| [1] initials of Federico Faggin
| ece wrote:
| You can actually go see blown-up individual mask traces (how
| they made the chip) for at least some of the layers at the
| Intel Museum in Santa Clara.
|
| edit (some more info):
| http://intel4004.com/current_intel_museum.htm
| codegladiator wrote:
| haha that looks like a screenshot of a factorio game play
| erwinh wrote:
| I'm thinking for a while already to make an art collection using
| chip designs as source material.
|
| Does somebody know of a place to get open source publicly
| available design data files for chips?
| arthurcolle wrote:
| Could you actually go out and build one of these based on these
| pictures? Just curious
| praveen9920 wrote:
| This is listed here in the same site.
| https://siliconpr0n.org/wiki/doku.php?id=capture
| sahin wrote:
| We need thisisnotarealchip
| mhh__ wrote:
| AI generated microarchitecture could be fun, although I assume
| they do something similar already (What's the optimal cache
| parameters, number of execution pipelines etc. etc.)
| madengr wrote:
| No compound semiconductor pr0n, which is much more intriguing.
| abhayb wrote:
| Finally a place for new desktop wallpapers after
| http://exoteric.roach.org/bg/
|
| Also I would describe your server situation as "brave" and "a
| mood" (I mean that in the very best possible sense)
|
| And finally, a question: what other interesting stories does the
| creator have to tell?
| johndmcmaster wrote:
| Thanks!
|
| This is a good starting point:
| http://uvicrec.blogspot.com/2015/12/lab-explosions-and-accid...
| zwegner wrote:
| If you like this, I'd highly recommend also checking out
| Fritzchens Fritz's flickr account:
| https://www.flickr.com/photos/130561288@N04/albums
|
| There's a ton of gorgeous high resolution die shots of (mostly)
| modern chips, all in the public domain.
| jzer0cool wrote:
| These die shots are all very pretty. Are people mostly
| interested in these just at the pure beauty of how so many
| circuitry can be packed into a small space and the feat of
| engineering, or for some other reason?
| anewguy9000 wrote:
| I'm dating one
| gnunez wrote:
| Some hobbyists use these die shots to reverse engineer older
| chips, bypassing the need to decap the chips themselves. The
| craft is explained nicely in this video
| https://www.youtube.com/watch?v=aHx-XUA6f9g.
| rektide wrote:
| somehow printing & printers came up in hn a couple months ago,
| and there were some supporters of not owning printers: just buy
| whatever prints you need.
|
| maybe they're still right, but i feel like this demonstrates well
| why i'd want a decent slightly-wide-format cost-effective
| printer: a rotating selection of cpu print outs, to hang on the
| walls.
| monsieurbanana wrote:
| That seems exactly like the kind of use case where you would
| really want to just buy high quality prints to hang on your
| walls, not the printer.
| rektide wrote:
| At ~$10 per print, I feel a little weird about spending the
| money, time & time again, to get photos.
|
| But buying a $1000 Epson with an EcoTank- it comes with two
| free years of ink, and will be cheap to run after that- it
| might/might not make financial sense. 100 photos is a lot to
| print out. But I feel like it's something that I'd want to
| use, would be happy to use, am incentivized to use. Where-as
| I would be hestitant to keep throwing $10 after prints, that
| I wasn't super sure about. Buying my own printer lets me
| leave the scarcity model behind. It frees me from the act of
| deliberation. It gives me faster turn around, to experiment.
|
| I'm not sure why people keep foisting what seems like such
| terrible & limiting advice on me, to not invest in ownership,
| not invest in myself. It's confusing. It's not backed up with
| arguments. This is the 3rd time I've had this exact same
| encounter on HN. I welcome some healthy questioning, but no
| one has given me any arguments, anything to go on.
|
| I should probably start by ordering some prints. See how that
| goes. Sample the idea. But even throwing $60 at some prints-
| it feels like a lot of money, that could be better invested.
| seattle_spring wrote:
| ooh check out the 386i bare all
| DonHopkins wrote:
| 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:
|
| http://i.imgur.com/zwaJMQC.jpg
|
| 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...
| jecel wrote:
| One interesting feature of the Lisp microprocessor is that it
| doesn't have an ALU. At that time an ALU was a very large part
| of a processor design and the idea was that Lisp didn't need it
| and not having one would allow the project to fit (barely) in
| the limited area allocated to each student.
|
| You can define numbers from scratch in Lisp by using lists and
| having their length (for example) represent the number's
| magnitude.
|
| If we define the empty list as ZERO, and the successor of a
| number N as (CONS 'S N) we can build a whole math library from
| there: (DEFINE ADD '(LAMBDA (A B)
| (COND ((NIL? A) B) ((NIL? B) A)
| (T (ADD (CONS 'S A) (CDR B))) )))
| retrac wrote:
| Ah, the 70s. Hair got bigger and chips got smaller. Thank you
| for all this. It's both pretty, and educational.
___________________________________________________________________
(page generated 2021-01-30 23:02 UTC)