6 ms·

"No FPGAs, no microcontrollers, just discrete logic" Very hard to believe that. .. How? Is it a SUBLEQ-style Turing tarpit that uses a very high clock and simp

"No FPGAs, no microcontrollers, just discrete logic" Very hard to believe that. .. How? Is it a SUBLEQ-style Turing tarpit that uses a very high clock and simple hardware to run RISC-V "in software" at a slower clock? Do the discrete logic gates get woven into an ad-hoc FPGA? Considering the breadboard CPUs I saw a few years ago, it just doesn't look like enough board space... I could be wrong.

Pixelbrick 3y ago
The same way it used to be done before we had LSI/VLSI!
0xDEF 3y ago
There is no way it implements the entire RV32I base profile. Maybe it only implements the instructions that are relevant for CS students taking a computer architecture class. That is typically what these breadboard CPUs implement.
- monocasa 3y ago
  RV32I is pretty tiny. Particularly when you can squint hard enough at the spec. FENCE can be a nop. EBREAK and ECALL can be something like a halt of the machine.
  - Joker_vD 3y ago
    Arguably, RV32I is "only the instructions that are relevant for CS students taking a computer architecture class", judging by the history in its earliest published spec [0]. [0] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...
segfaultbuserr 3y ago
From the picture, the logic chips are all in SOIC packages. The use of surface-mount components with 4-layer PCB should already significantly boost routing density compared to a breadboard with DIP chips. All the chips can be tightly packed together. Furthermore, both the ALU and the Control Unit are entirely in EEPROMs. The ALU uses 7 ROMs [2], the Control Unit uses 3 ROMs [3], the program counter uses 5 ROMs [4], the bit shifter uses another ROM [5], so I already see 16 EEPROMs in total. This means all the discrete components needed for random logic are largely eliminated, consolidating possibly hundreds (or thousands?) of gates into just a few chips and some lookup tables to program. In fact anther maker already demonstrated that it's sufficient to design a functional CPU entirely using RAM and ROM with just 15 chips in total. [6] Programmmers usually think ROMs as data storage devices, but they are also the most rudimentary form of programmable logic, as they transform x-bit of address inputs into arbitrary y-bit data outputs, so they can implement arbitrary combinational logic. In fact, lookup tables are the heart of modern FPGAs. As a result, you may argue that this means any ROM-based design has ad-hoc FPGAs (especially when EEPROMs are so large after the 1980s, 64 K for 16-bit chips). But the use of Mask ROMs and PLAs in Control Units has always been a legitimate and standard way to design CPUs even back in the 70s, so I won't call it "cheating" (and using ROMs for ALUs or Control Unit wouldn't really be much different from using a pre-made 74181 or AMD Am2900 anyway). [1] https://github.com/pineapple-one/hardware-eagle https://github.com/pineapple-one/hardware-eagle [2] https://github.com/pineapple-one/hardware-eagle/blob/main/control-unit/doc/Control_unit.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/co... [3] https://github.com/pineapple-one/hardware-eagle/blob/main/alu/doc/ALU.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/al... [4] https://github.com/pineapple-one/hardware-eagle/blob/main/program-counter/doc/Program_counter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/pr... [5] https://github.com/pineapple-one/hardware-eagle/blob/main/shifter/doc/Shifter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/sh... [6] https://bailleux.net/pub/ob-project-gray1.pdf https://bailleux.net/pub/ob-project-gray1.pdf
- ReactiveJelly 3y ago
  Very cool! Someone else mentioned breadboard vs. PCB density of course. So if it's real, maybe I'll get one.
- mips_r4300i 3y ago
  Thanks for pointing this out. In the olden days it used to be fairly common to use eeproms (or just proms) with a few latches as a state machine. This way it was possible to accomplish many of the things you'd need a CPU for, but without needing one at all. It's not too far to add an ALU and some control flow after that, hehe.
  - segfaultbuserr 3y ago
    The use of microcode in CPUs began like this too. Originally, people replaced random logic in a CPU's Control Unit with a Mask ROM or a PLA. The goal was simply to avoid the trouble of building decoders from gates one by one. Although it's a form of programmable logic, few would describe these simple ROM lookup tables as "programs". Later, people pushed the idea further to build a small state machine to control the ALUs, and the microcode in ROM would then be used in turn to control that state machine. This marked the birth of "micro-sequencers". In addition to the internal use in integrated circuits, they also found applications as universal blocking blocks for custom discrete CPUs in the 1980s, examples included the AMD Am2900, Am29100 and Am29300 series chips. Building a CPU became as easy as connecting these logic blocks together and writing some microcode for the micro-sequencer. Continue the development of microcode further, and you eventually get the final form, which is a CPU within a CPU, and you may argue that the CPU is not really hardware anymore, but is driven by software. At which point does the use of microcode makes a CPU software rather than hardware? There's really no clear boundary, so the microcode always exists on the blurring line between hardware and software. This issue was also a heavily-contented subject in several lawsuits that involved cloning CPUs, as hardware is not covered by copyright, but software is.
monocasa 3y ago
There's a logisim simulation of the uarch. Assuming that matches the boards, it looks like a relatively straightforward pipeline-less implementation of a RISC. And it'd be much larger on a breadboard. Breadboards don't really allow your wiring and connections to be nearly as dense as even two layer boards. This project seems doable to me with relatively high scale integration chips handling a lot of heavy lifting, and maybe an EEPROM or two as a poor man's PLD for certain kinds of combinatory logic.
- segfaultbuserr 3y ago
  > and maybe an EEPROM or two as a poor man's PLD for certain kinds of combinatory logic. The entire ALU and Control Unit of the CPU are programmed in EEPROMs. The ALU uses 7 ROMs [1], the Control Unit uses 3 ROMs [2], the program counter uses 5 ROMs [3], the bit shifter uses another ROM [4], so I see 16 EEPROMs in total. Thus, hundreds if not thousands of logic gates are replaced by bitstreams in EEPROMs. This CPU certainly is based on the design philosophy of "EEPROMs as poor-man's FPGA" (not meant to be interpreted in a discouraging way, I found this design is still rather interesting). [1] https://github.com/pineapple-one/hardware-eagle/blob/main/alu/doc/ALU.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/al... [2] https://github.com/pineapple-one/hardware-eagle/blob/main/control-unit/doc/Control_unit.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/co... [3] https://github.com/pineapple-one/hardware-eagle/blob/main/program-counter/doc/Program_counter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/pr... [4] https://github.com/pineapple-one/hardware-eagle/blob/main/shifter/doc/Shifter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/sh...
  - ReactiveJelly 3y ago
    Yeah that is cool, because I hear that the tooling for FPGAs is still very proprietary. And it doesn't do much good if one's CPU is "Click the CPU button on the FPGA GUI" EEPROMS, I assume, you can build your own programmer pretty easily?
    - segfaultbuserr 3y ago
gleenn 3y ago
Interestingly it's only 500kHz clockrate
- vitiral 3y ago
  Common for large scale systems. IIUC wire lengths and connectors/joints add impedence
tzs 3y ago
A few years ago I considered trying to build a simple 32-bit RISC processor out of 74xx series logic chips. I had just taken parts 1 and 3 of the the MITx MOOC 6.004x, "Computation Structures". Part 1 covered CMOS, combinatorial logic, sequential logic, FSMs and stuff like that, and performance considerations, and culminated with designing a 32-bit ALU, which did add, sub, all 16 logic ops, compares, and shifts (logical or arithmetic) of 0 to 31 bits in either direction. In part 2 the students design a 32-bit processor and implement it in the simulator. The design is all at the gate level, except we were given two things as black boxes: (1) a register file of 32 32-bit registers, and (2) a ROM with 64 18-bit words. Part 3 adds caching and other performance. Here was the parts list I came up with for my design, not counting whatever it would have to do the 32x32 register file and the 64x18 ROM. In the follows the name of a logic element (NOR, MUX, etc) followed by a number means an element with that number of inputs. E.g, NOR2 is a 2 input NOT gate, and MUX4 is a 4 input multiplexor. DREG is something that can store 1 bit, which would probably be a D flip flop. The parts list: 295 AND2 8 AND3 32 DREG 3 NOR2 4 OR2 96 OR3 20 OR4 226 XOR2 6 NOT 563 MUX2 161 MUX4 That came out to around 350 chips. My biggest breadboard could hold about 32 chips, so I'd need around 11 or 12 of those, plus whatever more would be needed for the register file and ROM. 353 of those 563 MUX2s are in the shifter in the ALU, which can handle left or right arithmetic or logical shift by 0 to 31 in one clock cycle. If I added a new instruction that just does a logic right shift by 1 and made the old shift instructions all trap so they can be handled in software that would get rid of most of those 353 MUX2s. That would cut the chip count to around 270. That was still more than I was willing to deal with so that was the end of that. Given that with a PCB instead of a breadboard you'd get higher density, I think mine would have easily fit (even with the full shifter) in the amount of space that it looks like they are using with plenty left over, if I'm estimating the size of their boards right from the photos, so I don't see anything obviously implausible about their project.
- fsckboy 3y ago
  do you mean 74xx series logic? or 70xx series voltage detectors?
  - tzs 3y ago
gbraad 3y ago
I miss some nice clear board shots to see what is used. Harts to open the kicad/eagle file on a mobile device
benj111 3y ago
>Do the discrete logic gates get woven into an ad-hoc FPGA? Like literally? Wouldn't that require even more chips? Or are you saying that the act of combining logic chips itself constitutes a 'buggy, poorly specified [FPGA]'? In which case aren't you erasing the distinction between an FPGA and the alternative.

Pixelbrick 3y ago

The same way it used to be done before we had LSI/VLSI!

0xDEF 3y ago

There is no way it implements the entire RV32I base profile. Maybe it only implements the instructions that are relevant for CS students taking a computer architecture class. That is typically what these breadboard CPUs implement.

monocasa 3y ago
RV32I is pretty tiny. Particularly when you can squint hard enough at the spec. FENCE can be a nop. EBREAK and ECALL can be something like a halt of the machine.
- Joker_vD 3y ago
  Arguably, RV32I is "only the instructions that are relevant for CS students taking a computer architecture class", judging by the history in its earliest published spec [0]. [0] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...

segfaultbuserr 3y ago

From the picture, the logic chips are all in SOIC packages. The use of surface-mount components with 4-layer PCB should already significantly boost routing density compared to a breadboard with DIP chips. All the chips can be tightly packed together. Furthermore, both the ALU and the Control Unit are entirely in EEPROMs. The ALU uses 7 ROMs [2], the Control Unit uses 3 ROMs [3], the program counter uses 5 ROMs [4], the bit shifter uses another ROM [5], so I already see 16 EEPROMs in total. This means all the discrete components needed for random logic are largely eliminated, consolidating possibly hundreds (or thousands?) of gates into just a few chips and some lookup tables to program. In fact anther maker already demonstrated that it's sufficient to design a functional CPU entirely using RAM and ROM with just 15 chips in total. [6] Programmmers usually think ROMs as data storage devices, but they are also the most rudimentary form of programmable logic, as they transform x-bit of address inputs into arbitrary y-bit data outputs, so they can implement arbitrary combinational logic. In fact, lookup tables are the heart of modern FPGAs. As a result, you may argue that this means any ROM-based design has ad-hoc FPGAs (especially when EEPROMs are so large after the 1980s, 64 K for 16-bit chips). But the use of Mask ROMs and PLAs in Control Units has always been a legitimate and standard way to design CPUs even back in the 70s, so I won't call it "cheating" (and using ROMs for ALUs or Control Unit wouldn't really be much different from using a pre-made 74181 or AMD Am2900 anyway). [1] https://github.com/pineapple-one/hardware-eagle https://github.com/pineapple-one/hardware-eagle [2] https://github.com/pineapple-one/hardware-eagle/blob/main/control-unit/doc/Control_unit.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/co... [3] https://github.com/pineapple-one/hardware-eagle/blob/main/alu/doc/ALU.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/al... [4] https://github.com/pineapple-one/hardware-eagle/blob/main/program-counter/doc/Program_counter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/pr... [5] https://github.com/pineapple-one/hardware-eagle/blob/main/shifter/doc/Shifter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/sh... [6] https://bailleux.net/pub/ob-project-gray1.pdf https://bailleux.net/pub/ob-project-gray1.pdf

ReactiveJelly 3y ago
Very cool! Someone else mentioned breadboard vs. PCB density of course. So if it's real, maybe I'll get one.
mips_r4300i 3y ago
Thanks for pointing this out. In the olden days it used to be fairly common to use eeproms (or just proms) with a few latches as a state machine. This way it was possible to accomplish many of the things you'd need a CPU for, but without needing one at all. It's not too far to add an ALU and some control flow after that, hehe.
- segfaultbuserr 3y ago
  The use of microcode in CPUs began like this too. Originally, people replaced random logic in a CPU's Control Unit with a Mask ROM or a PLA. The goal was simply to avoid the trouble of building decoders from gates one by one. Although it's a form of programmable logic, few would describe these simple ROM lookup tables as "programs". Later, people pushed the idea further to build a small state machine to control the ALUs, and the microcode in ROM would then be used in turn to control that state machine. This marked the birth of "micro-sequencers". In addition to the internal use in integrated circuits, they also found applications as universal blocking blocks for custom discrete CPUs in the 1980s, examples included the AMD Am2900, Am29100 and Am29300 series chips. Building a CPU became as easy as connecting these logic blocks together and writing some microcode for the micro-sequencer. Continue the development of microcode further, and you eventually get the final form, which is a CPU within a CPU, and you may argue that the CPU is not really hardware anymore, but is driven by software. At which point does the use of microcode makes a CPU software rather than hardware? There's really no clear boundary, so the microcode always exists on the blurring line between hardware and software. This issue was also a heavily-contented subject in several lawsuits that involved cloning CPUs, as hardware is not covered by copyright, but software is.

monocasa 3y ago

There's a logisim simulation of the uarch. Assuming that matches the boards, it looks like a relatively straightforward pipeline-less implementation of a RISC. And it'd be much larger on a breadboard. Breadboards don't really allow your wiring and connections to be nearly as dense as even two layer boards. This project seems doable to me with relatively high scale integration chips handling a lot of heavy lifting, and maybe an EEPROM or two as a poor man's PLD for certain kinds of combinatory logic.

segfaultbuserr 3y ago
> and maybe an EEPROM or two as a poor man's PLD for certain kinds of combinatory logic. The entire ALU and Control Unit of the CPU are programmed in EEPROMs. The ALU uses 7 ROMs [1], the Control Unit uses 3 ROMs [2], the program counter uses 5 ROMs [3], the bit shifter uses another ROM [4], so I see 16 EEPROMs in total. Thus, hundreds if not thousands of logic gates are replaced by bitstreams in EEPROMs. This CPU certainly is based on the design philosophy of "EEPROMs as poor-man's FPGA" (not meant to be interpreted in a discouraging way, I found this design is still rather interesting). [1] https://github.com/pineapple-one/hardware-eagle/blob/main/alu/doc/ALU.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/al... [2] https://github.com/pineapple-one/hardware-eagle/blob/main/control-unit/doc/Control_unit.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/co... [3] https://github.com/pineapple-one/hardware-eagle/blob/main/program-counter/doc/Program_counter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/pr... [4] https://github.com/pineapple-one/hardware-eagle/blob/main/shifter/doc/Shifter.pdf https://github.com/pineapple-one/hardware-eagle/blob/main/sh...
- ReactiveJelly 3y ago
  Yeah that is cool, because I hear that the tooling for FPGAs is still very proprietary. And it doesn't do much good if one's CPU is "Click the CPU button on the FPGA GUI" EEPROMS, I assume, you can build your own programmer pretty easily?
  - segfaultbuserr 3y ago

gleenn 3y ago

Interestingly it's only 500kHz clockrate

vitiral 3y ago
Common for large scale systems. IIUC wire lengths and connectors/joints add impedence

tzs 3y ago

A few years ago I considered trying to build a simple 32-bit RISC processor out of 74xx series logic chips. I had just taken parts 1 and 3 of the the MITx MOOC 6.004x, "Computation Structures". Part 1 covered CMOS, combinatorial logic, sequential logic, FSMs and stuff like that, and performance considerations, and culminated with designing a 32-bit ALU, which did add, sub, all 16 logic ops, compares, and shifts (logical or arithmetic) of 0 to 31 bits in either direction. In part 2 the students design a 32-bit processor and implement it in the simulator. The design is all at the gate level, except we were given two things as black boxes: (1) a register file of 32 32-bit registers, and (2) a ROM with 64 18-bit words. Part 3 adds caching and other performance. Here was the parts list I came up with for my design, not counting whatever it would have to do the 32x32 register file and the 64x18 ROM. In the follows the name of a logic element (NOR, MUX, etc) followed by a number means an element with that number of inputs. E.g, NOR2 is a 2 input NOT gate, and MUX4 is a 4 input multiplexor. DREG is something that can store 1 bit, which would probably be a D flip flop. The parts list: 295 AND2 8 AND3 32 DREG 3 NOR2 4 OR2 96 OR3 20 OR4 226 XOR2 6 NOT 563 MUX2 161 MUX4 That came out to around 350 chips. My biggest breadboard could hold about 32 chips, so I'd need around 11 or 12 of those, plus whatever more would be needed for the register file and ROM. 353 of those 563 MUX2s are in the shifter in the ALU, which can handle left or right arithmetic or logical shift by 0 to 31 in one clock cycle. If I added a new instruction that just does a logic right shift by 1 and made the old shift instructions all trap so they can be handled in software that would get rid of most of those 353 MUX2s. That would cut the chip count to around 270. That was still more than I was willing to deal with so that was the end of that. Given that with a PCB instead of a breadboard you'd get higher density, I think mine would have easily fit (even with the full shifter) in the amount of space that it looks like they are using with plenty left over, if I'm estimating the size of their boards right from the photos, so I don't see anything obviously implausible about their project.

fsckboy 3y ago
do you mean 74xx series logic? or 70xx series voltage detectors?
- tzs 3y ago

gbraad 3y ago

I miss some nice clear board shots to see what is used. Harts to open the kicad/eagle file on a mobile device

benj111 3y ago

>Do the discrete logic gates get woven into an ad-hoc FPGA? Like literally? Wouldn't that require even more chips? Or are you saying that the act of combining logic chips itself constitutes a 'buggy, poorly specified [FPGA]'? In which case aren't you erasing the distinction between an FPGA and the alternative.