There is great excitement in the world of microprocessors, surrounding the RISC-V architecture. This is an open source modular instruction set specification that has seen implementations on FPGAs, and is starting to emerge in dedicated silicon.
If you are not yet up to speed on what is probably going to be the most important microprocessor development of a generation, you should watch this video. As [Robert Baruch] sets out to demonstrate, the combination of RISC technology and a modular instruction set means that the simplest processor compliant with the RISC-V specification can be surprisingly accessible. And to demonstrate this he’s building one from LSI and MSI TTL CMOS chips, something we’d more usually expect to see in a recreation of a much older architecture.
The video below the break is the first of a forthcoming series, and in it he introduces the project and gives us an easily-understandable overview of RISC-V before explaining the mechanics of a register for his RISC-V implementation. This will be his first module, and he’s created a PCB for it. He runs through its design, his choice of indicator LEDs, and then his choice of PCB house. There is also a breakout board, with two of the PCI sockets he’ll be using for his backplane. Finally we see the board being tested, with LEDs lighting up in response to values being stored in a completed register.
[Robert] has appeared on these pages many times before, among the most recent with his TMS9900-based breadboard computer. This build moves away from his retro fare though, and should be well worth watching for future installments.
Thanks [KAN] for the tip.
Accessible, performance is the other thing.
if it will be relatively compact – it will reach ~100-150mhz clock speed with a bit of careful planning. ECL chips can speed it up even more.
Yeah, but 150 millihertz is still hideously slow!
I’d rather settle for millihertz than get stuck level shifting for ECL, what a PITA. I have some old ECL SRAM but its just not worth using yet.
“I will always press shift when I type MHz” x 100. :(
What an outstanding video. I’m really looking forward to the rest of this series, Robert has a clear and concise presentation style that makes this unfamiliar content (to me) pretty easy to understand.
“I’m really looking forward to the rest of this series”
Definitely!
I sure will not built it (I already have too much “Stehrümpelchen”), but building and testing the modules in the same order as a Verilog implementation maybe makes sense too? I’ll decide on that after the next episodes…
How do you build an executable for a modular instruction set? Wouldn’t the compiler have to assume what instructions the target processor supports? That would mean that RISC-V binaries wouldn’t be portable between different models of processor. That might be fine for microcontroller-type stuff, but something like an embedded Linux system would be almost impossible without building the entire OS from source yourself.
RISC-V ignoramus here. Could the instruction set modularity be handled similarly to how some compilers on 8086/8088 systems (Turbo C being an example I know) dynamically handled having an 8087 floating point coprocessor? One check was done at runtime, and if the chip wasn’t there then the instructions were stubbed out to call a software interrupt that implemented the instruction in software. The same binary ran fine either with the coprocessor (fast) or without (slow).
x86 has been adding new instructions with every new family. There are a “few” options in gcc related to this for example:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
ARM instruction sets are also different between various versions of the cores, where bigger cores have more instructions.
Even everyone’s favorite Arduino, the AVR chip, has variations on the instruction set.
So why would it suddenly be an issue for RISC-V?
Software libraries, e.g. floating point emulation. The compiler would have to know which modules are supported.
Also there are opcode traps that an implementation can catch and then call those emulations.
>”That would mean that RISC-V binaries wouldn’t be portable between different models of processor.”
That’s correct. There’s three ways of dealing with it: 1) compile for the specific processor so you have multiple binaries available. 2) construct “fallback” functions so each part of your code can be substituted with one that actually runs on your system, 3) JIT – compile your program into bytecode which is then translated in runtime into a binary which operates on your specific hardware.
Number 3 is very popular today in cellphones on the ARM platform, i.e. how Android works. Obviously you can’t do very deep optimization, or rely on your code running with specific timing or performance.
Outside of Java, Python, etc. Mobile userspace applications are pretty much the only area in which JIT is the preferred option.
Almost everything else is compiled for a specific platform and/or processor. Particularly for embedded systems which rarely have the resources available for JIT compilation.
Outside of two of the most popular programming languages in the enterprise space, BTW you left out c# so make that 3 of the most popular languages in the enterprise space.
“Almost everything else is compiled for a specific platform and/or processor” You left out Javascript with this one.
“Particularly for embedded systems which rarely have the resources available for JIT compilation.”
Embedded means a lot of things today. I am working on one that even uses BASH as part of the system.
it’s true that RV32G code is not runable on RV32i for example, but RV32i can run on RV32i, im, ima, g etc…. When running linux this implies RV32G or RV64G support, that’s a requirement from kernel (as far as I remember), so you can run all other variant.
For custom extension you need to provide your own compiler anyway and it’s mainly targeted for companies that use custom risc-v design in custom product.
You specify the architecture + extensions when you compile the code (including compiling the standard libraries). Just a flag you pass to your compiler, doesn’t require any effort on the programmer’s part.
For shrink-wrapped software like OSes, you can either compile for the lowest common denominator (i.e., base integer ISA), or specify a set of extensions required by your software. For example, Linux distributions will probably require RV64GC as their minimum ISA (64-bit, compressed instructions, hardware multiply/divide, atomic operations, hardware floats, hardware double floats). The foundation is leaving these decisions up to the people shipping the shrink-wrapped software.
I agree with dongwaffle.
…words I never thought I’d be typing “I agree” with.
Seriously, even if you don’t care about CPU architecture, the first few minutes of this video give you enough to talk smart about RISC-V at a cocktail party or trade fair.
CMOS, not TTL.
TY.
Thanks for the concise presentation of what is RISC-V.
epiphany is better
meybe hybrid risc v and parallela is more open than normaly parallela.
now epiphany working on 1024 core prcesor
RISC-V has 4096 core chips in the pipeline also: https://www.esperanto.ai/single-post/2017/11/28/Esperanto-Technologies-Plans-Energy-Efficient-Chips-for-Artificial-Intelligence-and-Machine-Learning-based-on-the-open-RISC-V-standard
Interesting times. :-)
David Ditzel… Now that’s a name I’ve not heard in a long time.
There’s also http://opencelerity.org/ and http://bjump.org/manycore/
Not to mention GRVI Phalanx https://carrv.github.io/2017/slides/gray-phalanx-carrv2017-slides.pdf
Sadly, Epiphany is dead: https://parallella.org/forums/viewtopic.php?f=9&t=4087#p19196
A tiled MPP SoC using RISC-V is inevitable.
And yet another website goes crashing to the ground in flames under the baleful gaze of the Hackaday Readers ™
Of possible interest: GRVI Phalanx joins the Kilocore Club
(1680 RISC-V cores in an XCVU9P)
http://fpga.org/2017/01/12/grvi-phalanx-joins-the-kilocore-club/
I was going to post this! I love your work Mr Gray :) Have seen a couple of your talks on YouTube.
> Implements ganged 3-port register file
> uses one of the ports for LEDs
Truly a god among men