Poorly designed or managed chips can reach the point that hot spots in the silicon literally melt, which happens at ~1400C. Thermodynamics sitting on an insulator (relative to the metal portions of the chip at least) on very small scales is very weird and can reach wild spot temps.
That's why chip thermals is its own whole subfield of physical design.
Sure, but the center of a PWR fuel rod reaches high temperature in normal operation. Uranium dioxide is not a great conductor of heat.
Chips have the advantage that the workings are right at the surface, mere microns from it. So the heat can easily get out. The power density in that thin surface layer can be very high. Perhaps similarly, the power density of a PV cell can be very high, if one just looks at the active layer where light is being absorbed. In CdTe this layer is < 1 micron thick. The energy delivered over the life of the cell per atom in this layer can approach that of nuclear reactions.
I will add that if we're talking about abnormal operation, say in a reactor meltdown, uranium dioxide can reach its melting point, 2865 C.
Anyway, it's a promising comparison, since the core of a PWR can reach volumetric power density of ~100 MW/m^3 (and probably higher in naval reactors). Servers can potentially be made very compact.
I found it interesting that this uinstr format doesn't include omnipresent control flow bits like I see in most uinstr archs. I was going to ask about RNI being it's own instruction, but looked at the microcode dump you linked to, and it's clear that you'd need a nop in almost all of those slots anyway because of the delay apparently needed after register transfers.
So I guess my question is: what do you see as the reasons why you'd pick a particular school of micro control flow as a microcode engine implementer? ie. along the spectrum of 'no increment on upc, every uinstr explicitly encodes jump, maybe oring bits into the address for conditional control flow', to 'looks like a relatively normal assembly, assumed incrementing program counter, specialized control flow uinstrs otherwise'.
> So I guess my question is: what do you see as the reasons why you'd pick a particular school of micro control flow as a microcode engine implementer?
For a comprehensive answer, a good vintage introductory digital design textbook is Ward and Halstead's 1989 Computation Structures, from the "peak CISC" era! [1]
There, the second (vertical) type is often used for highly complex instructions/fancy addressing modes, that you might want to implement with some sort of procedure abstraction, loops, working memory, etc. A "luxury" vertical microcode engine would have facilities like "microprocedure calls", a micro-stack and workspace RAM, a micro-ALU, dispatch table micro-instructions. The authors use the suggestive term "interpretive microcode".
String instructions come to mind as a complex example; non-register machine architectures (stack machines); tagged data architectures that have instruction-level polymorphism (e.g. Lisp machines).
The culminating project of Ward and Halstead is an elaborate two-level microcode system (vertical on horizontal/second on first). I think the first Motorola 68k had this architecture -- here is the patent. [2]
It's genuinely a fun read. The "write an micro-interpreter for your CISC ISA" approach is hopelessly out of date now that we need pervasive microarchitectural parallelism, and have HDLs.
So, I've read Computation Structures. And agreed, an absolutely fantastic text. [0]
However, my question is kind of orthogonal to vertical versus horizontal microcode.
As a counter example I'd point to the microcode format of the system 370/145, which while pretty clearly being something that would be described as vertical microcode also doesn't have implicit control flow [1]. It's a little on the wide side for vertical microcode at 32 bits, I'll grant you, but it has an op field(s) with about a dozen variants that then is used to further decode the other fields, at an overall decode complexity comparable to a RISC arch. Horizontal microcode looks more like 'these specific bits just always plug into this mux, and are simply set to some default if unused in this specific operation, reducing decode to essentially wires'. That being said, it also doesn't have an incrementer on the program counter, with the last byte of instructions encoding a (conditional) branch to the next instruction[2].
For another example, I'd point to modern microcode formats in Intel and AMD cores. They pretty universally have a vertical microcode instruction format (though grouped into triads or quads of instructions typically) then paired with explicit, dedicated microprogram control flow field for the group. The uops there are pretty wide at 48-64 bits typical, but they sort of need to be to fit immediates that are common for 64 bit archs, and also fit into that RISC like level of decode complexity you see in vertical microcode. [3]
[0] - As an aside, if you like Computation Structures, I'd recommend The Anatomy of a High-Performance Microprocessor: A Systems Perspective by Shriver and Smith as well. The mad lads stuck a surprising amount of the RTL for the AMD K6 in that book, albeit translated into some custom academic langauge. That mid 90s era design of a multi instruction per clock CISC decoder dumping a speculative instruction stream into an OoO RISC like backend is arguably just as much peak CISC as the early 80s given that it won against the UNIX RISCs by the early 2000s and survives to this day with remarkably few tweaks relatively speaking. CISC seems to be kind of like the Roman empire; any time it starts losing the war, it just unashamedly starts integrating the concepts of its competitor it's losing to. Which is great in this case. That's called good engineering.
[2] - Though it does have an explicit far jump/call instruction for control flow outside that window addressable by that byte, and a couple other bits sometimes depending on the instruction format.
Basically why my car is so old it doesn't even have a CAN bus.
Roslin: I heard you're one of those people. You're actually afraid of computers.
Adama: No, there are many computers on this ship. But they're not networked.
Roslin: A computerized network would simply make it faster and easier for the teachers to be able to teach-
Adama: Let me explain something to you. Many good men and women lost their lives aboard this ship because someone wanted a faster computer to make life easier. I'm sorry that I'm inconveniencing you or the teachers, but I will not allow a networked computerized system to be placed on this ship while I'm in command. Is that clear?
But they used Floppy disks and data chip thingies for transferring data. If the Cylons were any good they’d have eventually created a self perpetuating virus. Even humans have pulled that off (Stuxnet and Iranian nuclear centrifuges)
Same. Want to update the firmware in the computer? Sure but you'll need to unscrew the driver's seat, unscrew the desktop PC sized ECU, unscrew its four pencil-thick battery connections, unplug its 27 connectors, unscrew the 50 screws in three slightly different sizes holding the top cover on, remove the heatsinks, unscrew the eight screws holding the motherboard in, and desolder both the 144-pin 68HCxxx chips that do all the thinking.
There's a big custom chip made by GEC Plessey that has a small flash chip beside it, but it's totally undocumented. They also make the custom chips in the door, window switch, and seat outstations. I found some very very general documentation about them but nothing enough to start picking the firmware apart.
They had to calculate jump fast to join the fleet and the only way was to break the taboo - connecting the computers.
Cylons seized the opportunity and despite of the software firewall they managed to periodically disturb this network. In the end all computers were disconnected. IIRC Gaeta later had to wipe drives and install operating systems again, from these fancy octagonal "cds".
I never understood this. They're networked? So what? Don't connect it to other ships, or the Baltarnet or whatever they call it. Is the idea that if a Cylon gets on the ship, they can access the CIC from the thermostat in the bathroom? Did I miss something? Did I watch it wrong?
I wouldn't quite go that far. Linux runs on nommu systems. With some psram you should be able to get a version to run on at least the rp2350 using the riscv cores with relatively minimal fuss.
I image that'd be handled via a fairly regular minor bit of additional fine tuning to update them with new information rather than polluting the context space.
Part of the delay is really just commercial. Fabs are optimized for utilization - throughput, not latency. A fab operator will prefer to queue up a load of work with as few gaps as possible, and your shuttle service run has to fit in one of the gaps. If you're NVIDIA and you've already booked the fab, there might not be so much delay. But not zero.
Just to buttress and embroider around your point that a fab is not a small business:
If there was a realistic way even to go from bare wafers to non-trivial custom chips in a small-batch fashion, you can bet there would be a cottage industry around it. I would love to live in a world where I could manufacture custom silicon as easily as I can manufacture a custom PCB or custom mechanical part.
But as it stands, quick-turn, rapid-proto "micro" fabs are obscenely expensive, to the extent that if you aren't absolutely certain you need the performance gains from custom silicon, justified by years of R&D that confirms the inadequacy of a multi-chip solution, then the idea is killed before any layout engineer is contacted.
Microfabs are either operated by research institutes, or they're booked solid for years, and basically printing money.
IMEC is a lab, not a fab. They have partnerships with all major fabs for driving research forwards and making prototypes and concepts, but they don't manufacture anything there, it's still up to Samsung, Intel or TSMC to try out whatever IMEC comes up with.
They may have lasers, electron microscopes, probes, etc on-site for testing what Intel or TSMC ship them and verify research results, but that's pretty far away from a "cottage industry".
Intel and Samsung are the true "cottage industries" as they do full vertical integration of IP, R&D and manufacturing under the same roof.
IMEC is more like the UN of semi companies, a place for them to come together, talk, share knowledge and results and decide industry standardisation based on that.
Accelerating the process is an incredibly obvious desire for literally everyone in the industry and there are already gobs of money being put into R&D.
The fact of the matter is that we're dealing with physical and chemical processes. It simply takes time for atoms to move across space. In many steps of the semiconductor fab process we are literally building up the chip by single-atom thick layers.
There's very finite limits to how fast you can throw atoms at a substrate. There are finite limits to how much time a photoresist must be exposed. There are finite limits to how fast chemicals can etch the surface. You can only saw a wafer so fast, you can only physically transport dice through space so fast.
These are problems that the entire industry wants to solve. These are problems at the bleeding edge of physics. This is not something a startup is going to solve, purely because you need to already have an entire semiconductor fab to iterate in.
There are startups trying to reduce the time/cost of chip-fab. Atomic Semi is one. Most of the big players have shuttle services which one can use to put a small chip on for fabrication for not a lot of money ~ $10k for a few chips. Tiny Tapeout acts as an OshPark or JLC PCB for chip design using 2 different fabs - skywater's 130nm and IHP's 130nm node. Wafer.space uses Gobal Foundries 180nm (~ $7 per 20mm^2 chip).
At the end of the day the industry has evolved and optimized to stamp out millions of chips a year with very little defects. However that requires a fairly hefty upfront commitment in design/verification time along with a capital commitment to make enough chips to get economies of scale. This breaks down when trying to build small volumes of chips quickly. It's like trying to turn an oil tanker quickly....
When you say that the 125 added memory management, what does that mean a little more specifically? My guess is either PDP-11/z280 style paging without page tables (the 16 bit address space makes just having enough IO registers to cover the address space tractable) or some simple segmentation hardware, but it'd be neat if there was another hardware object capability system I didn't know about.
The Mitra 125 had memory segmentation. It seems similar to the 8086, with descriptors that specified base address and length for a segment. Accessing memory outside a segment caused a trap.
That's why chip thermals is its own whole subfield of physical design.
reply