Note this is the same Clifford Wolf who has built a Verilog synthesizer [1] and reverse engineered the Lattice FPGA bitstream format [2].

On a slightly different topic, the RISC-V group has built an impressive Javascript RISC-V emulator that boots Linux in your browser: http://riscv.org/angel/

[1] https://github.com/cliffordwolf/yosys

[2] http://www.clifford.at/icestorm/

Very nice!

Boot http://riscv.org/angel/ into linux busybox in the browser

/ # cat /proc/cpuinfo

CPU info: PUNT!

/ #

What does "PUNT!" mean?

It means that the RISC-V Linux port hasn't decided what to put in /proc/cpuinfo yet. The contents of that file are not standardized across architectures, and indeed there isn't much meaningful information to provide there on certain CPUs.

It means that there's still work to do on the Linux port and RISC-Vs supervisor mode ISA in general.

There's an OpenRisc in-browser emulator which seems to give you a more functional linux:

http://s-macke.github.io/jor1k

The cpu in /proc/cpuinfo is OpenRISC-12 @ 20MHz ;)

The actual verilog code is only 1450 lines. I didn't realize that you could be so productive (I've never done any chip design before, but have watched longingly for some time).

The actual verilog is often the easy part. Writing a good simulation (see testbench.v and the firmware folder) to make sure that verilog does what you expect takes a fair amount of work. Getting the verilog to synthesize and meet timing is also another large piece of the work. It appears that (unlike a lot of FPGA projects) the author of this has actually written scripts to automate that part, but you can bet there was a fair amount of trial and error to get those scripts correct. There's always a lot of "fighting the tools" involved in this process.

RISC-V, this is the RV32I set of instructions, is relatively simple, e.g. there is no hardware support for integer math errors, overflow, etc. besides divide by zero (http://riscv.org/spec/riscv-spec-v2.0.pdf):

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.

I would see a core like this being used for things like network protocol checksum and segmentation offload or providing a slightly smarter interface to flash chips for a bigger RISC-V core, the instruction set limitations seem fine to me.

The guys behind RISC-V have implemented some chips. A big brother of pico in 28nm is reported at https://aspire.eecs.berkeley.edu/wp/wp-content/uploads/2015/...

Has anyone try to synthesize pico or similar small-footprint RISC-V? If so, we would love to hear results.

I know nothing about Verilog, FPGAs or chip design.

How hard is it to go from something like this to an actual hardware chip you could put into hobby electronic projects?

Manufacturing a chip is expensive, it requires volume.

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.

This repo appears to include scripts to build this for a Xilinx 7 series FGPA. So once you buy a dev board with an Artix 7 (a quick google search shows it's about $400) and install the Xilinx tools (should be free) you can just type make and it will build the bitstream that you can load onto the FPGA.

A Parallella board is a fair bit less than $400, the Zynq is 7 series too, the scripts would need modifying a bit though.

The larger Rocket RISC-V implementation will also run on a Xilinx Zynq.

Here at Berkeley, we've successfully run our RV32I processor, Zscale, on an $89 lx9 microboard. But this took some hacking of the FPGA support repo, so it isn't officially supported.

A fair bit harder unfortunately. You only have the core here.

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).

Yeah. Vendors like Altera have a whole library of peripherals like serial, GPIO, etc for their own softcore processors and graphical tools for hooking them up; I don't think there's anything like that for RISC-V yet.

> Furthermore it is possible to choose between a single-port and a dual-port register file implementation. The former provides better performance while the latter results in a smaller core.

Surely this is backwards? A dual-port register file should be faster and bigger than a single-port one.

indeed. thanks for pointing this out. I have now fixed that typo.

https://github.com/cliffordwolf/picorv32/commit/f8c96d6d37b6...

What are the chances that one day we'll have desktops and laptops running on Risc-V chips?

This as far as I know is the strongest effort there, although they're a little more ambitious, planning on adding two bits of tags to the architecture to allow some safety improvements with our current software stacks as well as the usual things you can use tags for: http://www.lowrisc.org/