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.
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.
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.
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.
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.
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/
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.
> 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.
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/
21 comments
[ 1.7 ms ] story [ 83.8 ms ] threadWe 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.
How hard is it to go from something like this to an actual hardware chip you could put into hobby electronic projects?
The larger Rocket RISC-V implementation will also run on a Xilinx Zynq.
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.
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).
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/
Boot http://riscv.org/angel/ into linux busybox in the browser
/ # cat /proc/cpuinfo
CPU info: PUNT!
/ #
What does "PUNT!" mean?
http://s-macke.github.io/jor1k
The cpu in /proc/cpuinfo is OpenRISC-12 @ 20MHz ;)
Surely this is backwards? A dual-port register file should be faster and bigger than a single-port one.
https://github.com/cliffordwolf/picorv32/commit/f8c96d6d37b6...
Has anyone try to synthesize pico or similar small-footprint RISC-V? If so, we would love to hear results.