swapforth VS serv

Thanks! Found the port of this to the board I want :) https://github.com/jamesbowman/swapforth/tree/master/j1a

It's a standard thing to do in EE curricula; you normally do it in a one-semester class, and there are literally thousands of open-source synthesizable CPU cores on GitHub now.

To take two examples to show that designing a CPU is less work than writing a novel:

- Chuck Thacker's "A Tiny Computer", fairly similar to the Nova, is a page and a half of synthesizable Verilog; it runs at 66 MHz in 200 LUTs of a Virtex-5: https://www.cl.cam.ac.uk/~swm11/examples/bluespec/Tiny3/Thac...

- James Bowman's J1A is more like Chuck Moore's MuP21 and is about three pages of synthesizable Verilog: https://github.com/jamesbowman/swapforth/blob/master/j1a/ver... and https://github.com/jamesbowman/swapforth/blob/master/j1a/ver.... You can build it with Claire Wolf's iCEStorm (yosys, etc.) and run it on any but Lattice's tiniest FPGAs; it takes up 1162 4-input LUTs.

I haven't quite done it myself. Last time I played https://nandgame.com/ it took me a couple of hours to play through the hardware design levels. But that's not really "design" in the sense of defining the instruction set (which is also kind of Nova-like), thinking through state machine design, and trying different pipeline depths; you're mostly just doing the kind of logic minimization exercises you'd normally delegate to yosys.

In https://github.com/kragen/calculusvaporis I designed a CPU instruction set, wrote a simulator for it, wrote and tested some simple programs, designed a CPU at the RTL level, and sketched out gate-level logic designs to get an estimate of how big it would be. But I haven't simulated the RTL to verify it, written it down in an HDL, or breadboarded the circuit, so I'm reluctant to say that this qualifies as "designing a single CPU" either.

Also worth checking is the Swapforth Github repository.

> Right now, most devices on the market do not support the C extension

This is not true and easily verifiable.

The C extension is defacto required, the only cores that don't support it are special purpose soft cores.

C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file

Supports M and C extensions https://github.com/YosysHQ/picorv32

Another sized optimized core with C extension support https://github.com/lowrisc/ibex

C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html

This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax

In short: it works, though the implementation lacks the crystal clarity of FemtoRV32 and PicoRV32. The core is larger than SERV but has higher IPC and (very arguably) a more conventional implementation. The compressed instruction set is easier to expand into regular RV32I instructions than it is to execute directly.

https://github.com/olofk/serv

As for the size advantage: this mattered more when LUTs were precious and when PicoBlaze's competition was either similarly unorthodox (J1 Forth CPU) or several times larger (MicroBlaze). Nowadays, there are very small RISC-V cores like FemtoRV32 Quark or SERV. RISC-V benefits from mainstream open-source tooling and has momentum that's hard to beat.

The RISC-V spec does allow non-trapping behavior and SeRV in particular has non-trapping behavior, which is an important part of how it can fit into 200 4-input LUTs.

https://github.com/olofk/serv#good-to-know