Build a RISC-V CPU from scratch | Hacker News Reader

Build a RISC-V CPU from scratch

spectrum.ieee.org

151 pointsazhenley41 comments

This page (linked from the IEEE article) actually has a picture of the thing:

https://hackaday.io/project/178826-pineapple-one

Very impressive especially considering Filip is only 19 and this was his first project using custom PCBs. I'd love to know how he discovered and solved the timing bug.

This seems to be the only viable option if you want some certainty of not being spied on through a hardware back door, rather than modern chips where you're pretty much a guest on some kind of mysterious hypervisor.

I wonder what the theoretical limits to performance and usability of a 74xxx computer is. Email and chat should be possible as they were on 74xxx machines in the past, maybe even Gopher-style web browsing. But it's a hard sell when everyone's hooked on HD or even 4K video streaming.

As far as switching frequencies, see:

https://electronics.stackexchange.com/questions/260477/why-d...

Why would an FPGA-based computer be ruled out as an option?

Everything VLSI is going to be pretty opaque. Is there at least an FPGA with a completely open bitstream specification yet?

They're working on it for the Xilinx 7-series.

https://symbiflow.github.io/

Actually more than one, and new projects are started everyday to RE more architectures as we gathertools and knowledge from previous efforts. While the newer higher end fpgas are still out of reach a Lattice ECP5 can do pciE, gigabit ethernet, hdmi, ddr3, usb3, and of course has more than enough for a RISC-V (as a matter of fact you can fo one in a much cheaper/smaller ice40: https://github.com/cliffordwolf/picorv32

If you're going down this route, an FPGA can have a whole opaque processor embedded in it (usually an ARM) that theoretically is doing things you don't know about.

The first generation of PDP-11 computers were built from 74xxx-style discrete components.

https://archive.org/details/bitsavers_decpdp1111eb70_6917800

Can 4k video even be decoded without something massively parallel like GPU?

Video is generally not decoded on GPUs but on special purpose chips or blocks on an SoC.

Is this a battle you can win?

Use someone's riscv soc: can you trust that company?

Use custom asic: do you trust the fab?

Use fpga: do you trust fpga vendor?

Use 74xx & SRAM: can be backdoor-ed too. Also provably Van Eck all the way to Fort Mede.

Use transistors: probably safe but will you finish that project in this lifetime ?

Not to mention that the compiler, synthesiser and all that software can be backdoor-ed too.

I guess any 74xx chip can contain an SoC running a complete OS, and in the case of RAM be able to read and write anything it wants and phone home about it. But it would be very conspicuous when a chip that should only contain a handful of transistors or a simple grid pattern of memory cells is decapped. They are far more auditable than anything VLSI.

It's true that the battle can't be won, but that means it's a war of attrition. Backdooring 74xx chips would be very inconvenient and expensive compared to just pushing some code into the Intel ME or AMD PSP. The flip side of that is that building and using a 74xx computer is going to be just as inconvenient and expensive for the user. So this is more of a fun thought experiment than a serious solution.

Yes...you could run CLI apps just fine on TTL machines. I have a DEC VAX-11/730, which is TTL+2901 Bit slice (so not all 7400) going at about 1/3 MIPS. Runs BSD 4.3 and is on ethernet, and I can develop software (C/C++), chat (IRC), gopher, games (nethack) and even HTML web (lynx). But crypto (TLS) is rough, and things like streaming media and modern web are right out. And it uses a couple of times more power than my dryer does...not very environmentally friendly.

But practically, the limits of a 74xx series in creating a 'modern feature' (like, 32-bit) CPU are manifold. Assuming DIP chips, it would pack an average of 4 logic gates in about 1 sq inch (hand-waving a bit, and including board space). A Cortex-M0 has approx 12,000 gates [1]. So it would be huge. Assuming LS logic, each chip would draw about 4.5mA peak, so about 13.5 amps peak. So it would use a lot of power. Propagation delay (maybe 10ns per gate in LS) means it will be much slower than integrated logic...perhaps a couple of orders of magnitude slower than an M0.

There are mitigations. You could use SMT packages and pack more on a board. You could use a more power-efficient logic family than LS (e.g. ALVT or some CMOS family). Or go for faster logic at the cost of power. But you're never going to get within an order of magnitude or 3 of the speed+efficiencies of a monolithic chip.

There are a number of homebrew TTL CPUs out there for comparison. Most are 4- or 8-bit.

[1] https://www.electronicsweekly.com/news/products/micros/arms-...

> monolithic chip

Now I know how to market it! "You're not doing real microservices unless you do it on the gate level!"

But it's cool that you have a working VAX. I've been wanting some kind of minicomputer for a long time, but if I could find a complete one I probably couldn't justify the cost.

"It uses over 230 integrated circuits, mostly from the 74HCT series of logic chips"

That's actually an impressively low number of 74xxx chips given that it's a "real" 32 bit CPU. Ben Eater's "8 bit CPU from TTL" kit has ~43 74xxx chips.

I would love to have a utility which could convert an arbitrary Verilog module into its equivalent in a series of 74 series chips.

It's been done before (http://pepijndevos.nl/2019/07/18/vhdl-to-pcb.html see also Hackaday), but not exactly a standard use of yosys.

Oh, that's awesome.

The first VAX was also made from TTL - I'm not sure how many chips exactly (enough to fill a relatively large cabinet), but that's also a fully-featured 32-bit CPU.

A picture of said cabinet, which is supposedly 4 feet wide, and all the cpu boards mounted vertically occupy a pretty wide swath of that. I think it's safe to assume it's more than 230 TTL chips.

https://rcsri.org/collection/vax-11-785/

makes heavy use of 74181 4-bit slices - remember it's from a different age, very CISC, lots of microcode

Lots of us built what you would call a RISC processor out of 74181/Am2901 bit-sliced processors back in the day. Mostly because we didn't have the microcode skills to do what the pros did on things like the VAX or DGs.

Well it is apples to oranges. In the late 70s, high-end RAM was maybe 250ns, so you wanted a 5mhz CPU. In order to clock that on the VAX, they implemented numerous smaller micro operations and associated specialized TTL and then used microcode. So this limited the maximum propagation delay possible for any single cycle micro-op at the expense of complexity and power. Then each macro sizsd op took variable cycles. Also, the VAX had 4 priv states, ecc capable dram controller, i/o, fault recovery and the like.

I was an admin on a VAX-11/780, the first generation, in the Before Times. Yeah, the basic CPU was 26 or so hex-width Unibus boards about 16"x9". Memory and I/O was extra. A lot more than 230 TTL chips.

They eventually boiled it down to a couple of ASICs so you had a VAX on a single card.

But to be fair, the VAX implemented a vast amount of stuff that you wouldn't if you were designing your own TTL CPU.

The MIT Lisp Machine used many of the same TTL devices as the first VAX, the circuit diagrams are available so it would be fairly easy to count the chips.

The memory chips can be abused as big lookup tables, condensing potentially hundreds of discrete logic gates into one chip.

That's pretty much how all programmable gate logic works.

No, they're a bit different. If you take a look at GAL22V10 (or its replacement ATF22V10¹), you can see from the functional diagram that with a sensible organisation, you need way less memory than would be required from a giant look up table.

The tradeoffs are very different: with a giant look up table, you can encode any operation with the device. The problem is the rather huge amount of memory you need (with two 8-bit inputs and one 8-bits outputs you need 64KiB of internal memory to account for all possible inputs). With a PAL/GAL like the ATF22V10, you are fairly limited (your operation must be expressible in normal form, and it will have a limited number of terms), but the number of fuses (or memory cells) required to encode this are much, much lower.

Personally, I feel like using actual memory to encode behaviour is a bit "cheating" (that's just my own aesthetics). I would totally do this for actual micro-code, but for an ALU this seems wasteful.

[1]: https://ww1.microchip.com/downloads/en/DeviceDoc/doc0735.pdf

GALs are in essence ROM with both "halves" programmable (as the address decoding logic can also be implemented by mask or fuse programmable bit array). The end result is that you trade bit of generallity for smaller, cheaper and faster device.

Modern FPGAs (and IIRC even many CPLDs, as the line got somewhat blurred) are usually implemented as array of LUTs implemented as normal memory with fixed address decode and not with this PLA/PAL/GAL trick. Hence, "programmable logic is just bunch of ROMs".

Of interesting historical note is Connection Machine, which while marketed as "computer", is essentially an FPGA stood on it's head. Each of the thousands of CPUs is in essence FPGA LUT block, whose configuration changes for each microinstruction, while routing is fixed.

Most fpgas are exactly mini async srams used as LUTs. The old MachXO series I'm working on actually allows using the luts as 16x2 bits RAMS (synchronous, single port or pseudo dual port). It also integrates a d flipflop/latch, a couple of muxes and some carry logic in each cell to give a little more power/flexibility, but the main architecture is sram luts, flipflops and giant muxes at each input to do the routing

> Most fpgas are exactly mini async srams used as LUTs

Most fpgas contain mini async srams used as LUTs. It's very different from using one giant LUT, which is what abusing memory chips is all about.

The LUTs we find if FPGAs are very small, often with as little as 6 input bits. Because the size of the LUT grows exponentially with the number of inputs, there's a natural sweet spot: two few inputs, and the LUT isn't powerful enough. Too many, and the LUT is too bloated.

Using a 64K ROM to encode a 16-bit LUT definitely leans in towards "way too bloated" for me.

Sorry I guess I just read too quickly and missed the part about using memories as BIG lookup tables. I am with you on this one.

There are a bunch of fun discrete logic computers on Hackaday, if anyone is interested. This one looks nice: https://hackaday.com/2019/06/23/a-ttl-cpu-minimising-its-chi...

Very cool. Out of curiosity, wonder how much power it uses while running? :)

The author talks about "Computer Organization and Design, RISC-V Edition".

Is the book worth a read even if one read the other (and older) edition of the Patterson book? Can I sufficently learn RISC-V from it, or is it used as mere "reference" architecture?

You could skim a PDF of it +7$5 to get up to scratch with RISC-V, and it is more of a reference.

FWIW I think H&P books are extremely important references but basically rubbish pedagogically.

It's the main textbook used in university courses on microprocessor design and microarchitecture, so quite useful pedagogically. While you will certainly learn a lot and have a lot of fun by creating your own CPU out of 74-serial chips, this is no way to design a high performance, modern CPU. For that you need to understand the math, trade-offs, and sophisticated dataflow techniques which the book will teach you. (And then you'll need to spend years at one of the big design houses to learn the stuff that no one teaches)

But I think it's a poorly written book. Ignoring the issues with it like that the appendixes have to found online even after buying the book (i.e. not on the website), it simply doesn't teach very effectively

CO&D is a textbook about computer architecture in general, and only tangentially about RISC-V. There are better reference manuals to learn about RISC-V itself.

Reply on news.ycombinator.com