[HN Gopher] Pineapple ONE: open-source 32 bit RISC-V CPU that yo...
___________________________________________________________________
Pineapple ONE: open-source 32 bit RISC-V CPU that you can make at
home
Author : todsacerdoti
Score : 184 points
Date : 2023-09-16 06:04 UTC (1 days ago)
(HTM) web link (pineapple-one.github.io)
(TXT) w3m dump (pineapple-one.github.io)
| xrd wrote:
| Everyone that comments here, please note a lot of this is based
| on the work of a high school kid from Czech Republic. That's
| alone worth upvoting!
|
| I am currently reading "Gaming the Iron Curtain"
| (https://ironcurtain.svelch.com/). It's about the incredible
| innovations happening in the Czech Republic before the fall of
| the wall and what people there did to participate in the computer
| revolution. This kid seems like he comes from that heritage!
| [deleted]
| ngcc_hk wrote:
| You do not aware of this dimension if you just concentrate on
| the technical side. Great comment.
| ReactiveJelly wrote:
| "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.
| gleenn wrote:
| Interestingly it's only 500kHz clockrate
| vitiral wrote:
| Common for large scale systems. IIUC wire lengths and
| connectors/joints add impedence
| Pixelbrick wrote:
| The same way it used to be done before we had LSI/VLSI!
| 0xDEF wrote:
| 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 wrote:
| 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.
| segfaultbuserr wrote:
| 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
|
| [2] https://github.com/pineapple-one/hardware-
| eagle/blob/main/co...
|
| [3] https://github.com/pineapple-one/hardware-
| eagle/blob/main/al...
|
| [4] https://github.com/pineapple-one/hardware-
| eagle/blob/main/pr...
|
| [5] https://github.com/pineapple-one/hardware-
| eagle/blob/main/sh...
|
| [6] https://bailleux.net/pub/ob-project-gray1.pdf
| ReactiveJelly wrote:
| Very cool! Someone else mentioned breadboard vs. PCB density
| of course.
|
| So if it's real, maybe I'll get one.
| monocasa wrote:
| 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 wrote:
| > _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/al...
|
| [2] https://github.com/pineapple-one/hardware-
| eagle/blob/main/co...
|
| [3] https://github.com/pineapple-one/hardware-
| eagle/blob/main/pr...
|
| [4] https://github.com/pineapple-one/hardware-
| eagle/blob/main/sh...
| tzs wrote:
| 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 wrote:
| do you mean 74xx series logic? or 70xx series voltage
| detectors?
| tzs wrote:
| Oops, yeah 74xx. I've fixed it.
| codedokode wrote:
| > If I added a new instruction that just does a logic right
| shift by 1 and made the old shift instructions all trap
|
| You can use microcode for that. Also microcode can be used to
| implement multiply/divide by adding/subtracting in a loop.
| Microcode is very bad for performance, but in a DIY project
| it can save lot of chips. Microcode was used in 60s and 70s
| computers.
|
| And the simplest microcode sequencer is made of 1 (one)
| register and 1 (one) ROM. Although, for a RISC-V you would
| probably need more than 1 ROM (microcode is usually very
| wide, 16- or more bits).
| charcircuit wrote:
| >Our goal is to prove that designing a "modern" CPU isn't that
| hard
|
| I don't understand what is modern about the CPU that was
| designed. It looks like a toy CPU that got a marketing campaign
| made for it.
| sethhochberg wrote:
| I think it's fair enough in this case to say "modern" probably
| means "modern programming languages can compile to and run on
| it"
|
| There's some question in the comments here about how much of
| the ISA is actually implemented but it should theoretically be
| possible to write Rust code and run it on this thing, for
| example. There are many other toy CPU designs out there which
| are much more limited in terms of what can compile to run on
| them.
| ninjha wrote:
| Architecture-wise, even a regular modern CPU isn't _that_ hard.
| For example, Berkeley has the BOOMv3 core[0] which is
| performance-competitive[1] with commercial chips taped out in
| the last few years. I think commercial chips are faster because
| of improvements in analog design, and not some super special
| architecture sauce (although I 'm sure there's _some_ special
| sauce -- it 's probably not the defining factor).
|
| [0]: https://boom-core.org
|
| [1]:
| https://carrv.github.io/2020/papers/CARRV2020_paper_15_Zhao....
| ObscureMind wrote:
| Along the lines of building a full computer out of discrete logic
| parts, slu4 created the Minimal 64, described in his Youtube
| channel: https://www.youtube.com/@slu467
| turbobooster wrote:
| [dead]
| dragontamer wrote:
| Hmmm.
|
| Is a vertical stack like that really the best? Even if you are
| using large discrete chips like NAND gates or multiplexers, those
| connectors and 0.1" headers obviously take up so much space.
|
| And then the parasitics... Connectors like that will have
| resistance, capacitance and inductance that grossly complicates
| the flow of electricity.
|
| I mean, PCB traces also have parasitic elements, but we humans
| are better able to understand a microstrip transmission line
| than... well.... Whatever is going on in that vertical stack.
|
| It's impressive nonetheless and a show of good work. My immediate
| revision would be maybe mounting the board vertically and running
| fewer layers. Some connectors and 0.1" pin headers are useful,
| but you really shouldn't have this meany IMO.
| teraflop wrote:
| At a 500kHz clock rate, with reasonable rise/fall times, the
| electrical effect of some 0.1" headers is minuscule.
| "Microstrip transmission lines" are enormous overkill.
| dragontamer wrote:
| "Can do" vs "must do" is the key here.
|
| On a PCB, you "can" or you "may" perform advanced
| transmission line analysis upon your PCB traces. I don't
| think that a project like this needs much more than a 2-layer
| board (so microstrips are definitely overkill), but that
| doesn't change the fact that PCB parasitics analysis is
| basically a solved problem today and available on a lot of
| software packages.
|
| Anyway, my overall point is that large contiguous blocks of
| PCB are easier than thinking about connector issues (or for
| the matter: being forced to solder and manage all those
| connectors or headers).
|
| Not only is it easier to go header-free (and use a larger
| PCB), its better engineering due to tighter specs and
| analysis available.
|
| ------------
|
| Now a bit of connector doodads and having fun is probably fun
| and all. But a stackup of 9x PCBs is reaching the point of
| absurdity. I can't think of any good engineering reason to
| have so many connectors.
|
| That's 9-separate PCBs on this design, meaning at a minimum,
| 9-separate ground planes on this design. Is that... good
| engineering? I don't think so. Its horribly complex but for
| seemingly no appreciable reason. Maybe sound / analog
| circuits go on a separate board, but I'm not seeing any sound
| here...
|
| ------------
|
| That being said: I agree that at 500kHz maybe this level of
| analysis is not needed. But... on the other hand... these
| 74xxxx chips all have 30ns rise/fall times, so its not
| outside the realm of reality to be running this computer at
| 5MHz or 10MHz or so, 10x to 20x faster. At those higher
| speeds, you'll possibly need to think about these issues a
| bit more (or perhaps... more appropriately I should say...
| the author of this project "could have" aimed at a higher-
| speed target if they so chose)
| amelius wrote:
| What open source software would you recommend for PCB
| parasitics analysis?
| segfaultbuserr wrote:
| Unless you want to get a beautiful spectrum on a EMI/EMC test
| receiver, but it's certainly not relevant in this project...
| Building a discrete CPU at some MHz and passing modern
| EMI/EMC tests sound like a fun (and somewhat expensive [1])
| nerd-snipping project to do.
|
| [1] The expense of EMI/EMC tests at an actual lab is well-
| known. Doing it in a home lab at a much lower expense is
| possible with pre-compliance tools like a TEM cell, a
| broadband antenna and a spectrum analyzer, but these
| equipment still costs a few thousand dollars.
| rwmj wrote:
| Looking at their github: https://github.com/pineapple-one/ what
| exactly is this? What's the key repository with source?
| codetrotter wrote:
| Hardware seems to be at https://github.com/pineapple-
| one/hardware-eagle
___________________________________________________________________
(page generated 2023-09-17 23:00 UTC)