A RISC-V That The Rest Of Us Can Understand

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.

32 thoughts on “A RISC-V That The Rest Of Us Can Understand

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

    1. “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…

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

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

    2. 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?

    3. >”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.

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

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

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

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

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.