Microwatt: A tiny Open POWER ISA softcore written in VHDL 2008
github.com
github.com
https://github.com/antonblanchard/microwatt/tree/master/test...
Also, how many transistors does this equate to? Because IIRC PowerPC is quite an extensive instruction set, and some instructions are quite involved
Microwatt fits in a Lattice ECP5 FPGA with 85,000 LUTs (plus some block ram). Not sure how you'd get to transistors from that, wild guess times by 15 maybe? (But then the FPGA also has other special hardware blocks intended for interfacing with DDR RAM and other things, so those would be more as well).
You can see how the Power instruction decode is implemented https://github.com/antonblanchard/microwatt/blob/master/deco...
It's also an unwise search term on the web. Ask me how I know!
The big thing that complicates figuring out a transistor count for a soft CPU core is that FPGAs have hardware multipliers, which would be pretty big if you had to build them yourself.
Of course, this is all very approximate.
There goes "tiny"...
There are big FPGAs that cost many thousands of $.
Medium-size FPGAs, which may cost a few hundreds of $, have a few hundred thousand LUTs.
An evaluation board for the medium-to-small ECP5 FPGA is $100.
It comfortably surpasses the capacity of most of the Actel aerospace FPGAs that I tend to work with.
And I think it's so "micro" that the majority of all of Lattice's FPGAs wouldn't fit it either.
And the Lattice ECP5 is advertised with 85k LUTs, which would seemingly limit its use to edification as instantiating this softcore would consume the entire chip. For any other purpose if you wanted a chip that was only a CPU, you would buy a CPU.
Any PowerPC core, even a relatively small one like this, is much more powerful than the soft cores that are used in FPGAs when minimum size is desired.
There are also a few other bigger open-source POWER cores, which can be used for higher performance.
Technically it's a core that's supplied as RTL (code). There's nothing stopping you using it in custom silicon instead of on an FPGA. Whereas a "hard IP" core is already compiled down to a specific technology and can only be used there. It's possible for a hard macro to be for an FPGA, but it would be for a specific product line. A "hard macro" for custom silicon would be specific to a particular fab process.
Using the tools specific for each FPGA vendor, e.g. AMD (i.e. Xilinx), Altera (to be spun off soon by Intel), Lattice or Microchip, the HDL code can be synthesized into logic gates, then placed and routed, then the bit string with the corresponding configuration can be loaded into an FPGA.
If in the same FPGA one also implements a memory controller and peripheral interfaces, it can be used instead of a standard CPU.
The disadvantage is a low clock frequency, typically of a few hundred MHz, and high power consumption in comparison with a standard CPU with the same performance.
The advantage is that you can be certain that the CPU does only what you want, with no hidden functions or backdoors, and that you can customize it in ways that are not possible with standard CPUs, e.g. by adding instructions or accelerator blocks for performing some tasks that are done inefficiently in software or for interfacing with certain hardware devices that have real-time requirements that are difficult to achieve in a non-deterministic standard CPU.
I'm not sure that's quite true?
https://github.com/antonblanchard/microwatt/blob/master/fpu....
I presume v.state := ... is what the FPU will do next, like a deferred goto. you can unroll the whole process following that.
lookup table: https://github.com/antonblanchard/microwatt/blob/master/fpu....
I have first-hand experience porting https://phoenix-rtos.com/ to PowerPC back in the early 2000s and it's a very sane CPU arch (in comparison to x86). However, it's evident that POWER lags behind x86, ARM, and now RISC-V, both in terms of use and public attention.
Anything is sane compared to current x86. Each generation is an added layer of complication on top of the previous one and it's been going on since the late 70's.
If anything x86 is a proof that evolution works better in market adoption than nuking everything, specially when not every company cares about the bazaar, only their cathedrals.
You'd lose. There were two platforms who made that jump, but the architectures have no lineage in common at all.
There seems to have been a lot of work on emulation by Gary Davidian from an early stage - starting with the AMD 29000 then 88k and then finally on PowerPC - according to his CHM oral history.
https://youtu.be/XYWp_R33mDs?si=4czECGOaHiM-MQqt
Roughly lines up with the history recounted here:
https://lowendmac.com/2014/ibm-apple-risc-and-the-roots-of-t...
Apple was planning to go with a radical new design, breaking with the past in both software and hardware, but Gary Davidian & co. saved them from their own foolishness via a skunkworks project that actually could ship.
By complete co-incidence I have a blog post on the various Mac CPU transitions in draft that should be out tomorrow.
One mildly amusing point, which I don't think is mentioned in either link is that the Cognac project was so called because the surname of John Hennessy, of Stanford RISC and MIPS fame, is also, of course, the name of a brand of Cognac.
Already in 1964, in IBM System/360, the condition-code was a part of a bigger register, the "processor status word". The terms are much older than that.
Also in MC68000, the CCR is a part of the bigger status register, which, unlike the CCR, can be accessed only by privileged programs.
In POWER, the condition register also holds only the condition-code part of the status, but it has room for 8 groups of condition codes, to allow high speed even for cheaper in-order CPUs, which do not have register renaming (where otherwise a shared condition-code register would prevent the concurrent execution of instructions).
Be a little patient. A bunch of very high performance application cores are hitting the market next year.
Sure judgement can be delayed till then.