Boot http://riscv.org/angel/ into linux busybox in the browser
/ # cat /proc/cpuinfo
CPU info: PUNT!
What does "PUNT!" mean?
The cpu in /proc/cpuinfo is OpenRISC-12 @ 20MHz ;)
We did not include special instruction set support for overflow checks on integer arithmetic
operations. Most popular programming languages do not support checks for integer overflow,
partly because most architectures impose a significant runtime penalty to check for overflow on
integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior.
At this level, there's no multiply, let along division instructions (which can be OK, the original Lisp Machine didn't have any hardware support for that, the three major "upgrade" features of the LMI LAMBDA processor were speed (Fairchild FAST logic, i.e. 74Fxx parts), an extra bit of address space, and adding a TRW 16 bit multiply chip).
To a noob like me at this sort of thing, their story of how their instruction formats are particularly easy to implement sounded good.
Has anyone try to synthesize pico or similar small-footprint RISC-V? If so, we would love to hear results.
How hard is it to go from something like this to an actual hardware chip you could put into hobby electronic projects?
But you can put this in altera's new flash fpga's(max10) and have a working mcu(if this fits you might even get this is in a $3-4 chip) ,but the core is only a part of the design, you need to add peripherals and memories.
The larger Rocket RISC-V implementation will also run on a Xilinx Zynq.
A regular microcontroller has a lot of necessary extras in there. You generally want modules to handle power and clock generation. Flash memory is usually in there to hold firmware. Then you need a way to load that memory via an interface. You have internal RAM for running stuff.
Debugging module like JTAG is usually in there but maybe you skip that if you use an FPGA.
Microcontrollers have various I/O like GPIO, Analog to digital, Pulse Width Modulation module, Serial Peripheral Interface.
You have to figure out your pins. The design has currently 300+ IO ports at first glance. That's not realistic.
Other posters seem to be jumping the gun and talking about loading this on a FPGA board like all the work is done. There's a lot more design still needed to get it doing anything useful (Unless your hobby is executing instructions on a CPU).
Surely this is backwards? A dual-port register file should be faster and bigger than a single-port one.