A RISC-V Supercluster For Very Low Cost

As ARM continues to make inroads in the personal computing space thanks to its more modern and streamlined instruction set architecture (ISA) and its reduced power demands especially compared to x86 machines, the main reason it continues to become more widespread is how easy it is to get a license to make chips using this ISA. It’s still not a fully open source instruction set, though, so if you want something even more easily accessible than ARM you’ll need to find something like these chips running the fully open-source RISC-V ISA and possibly put them to work in a custom supercluster.

[bitluni] recently acquired a large number of CH32V003 microcontrollers and managed to configure them all to work together in a cluster. The entire array is only $2 (not including all of the other components attached to the board) so a cluster of arbitrary size is potentially possible. [bitluni] built a four-layer PCB for this project with an 8-bit bus so the microcontrollers can communicate with each other. Each chip has its own ADC and I/O that are wired to a set of GPIO pins on the sides of the board. The build is rounded out with a USB interface for programming and power.

There were a few quirks to get this supercluster up and running, including some issues with the way the reset and debug pins work on these specific microcontrollers. With some bugs like this out of the way, the entire cluster is up and running, and [bitluni] hints that his design could be easily interfaced with even larger RISC-V superclusters. As for a use for this build, sometimes clusters like these are built just to build them, but since the I/O and ADCs are accessible in theory this cluster could do anything a larger microcontroller might be able to do, only at a much lower price.

Thanks to [Måns] for the tip!

22 thoughts on “A RISC-V Supercluster For Very Low Cost

      1. I’m just now learning, from a newer HaD article, that the WCH implementation of RISC-V doesn’t allow executing code from RAM. Which is a show-stopper for me, at least for current projects. I don’t know if this is something they just left out of the RISC-V architecture, or a decision WCH made, but it’s a pretty important distinction, and to me a bummer.

          1. I looked through the datasheet myself, and found something that said that the SRAM was for data and the FLASH for program, without actually saying you couldn’t use the SRAM for code. Then I saw this, https://hackaday.com/2023/04/23/run-linux-by-emulating-risc-v-on-a-risc-v-microcontroller/, second paragraph, which tells me,
            “The ESP32-C3 lies towards the less complicated end of this curve, though that’s not the whole reason for the emulation. The PSRAM storage is used by the C3 as data storage and can’t be used to run software, so to access all that memory capacity an emulator is required that in turn can use the PSRAM as its program memory.”
            I don’t take this as gospel, but without something contradicting it from the manufacturer, it’s all I’ve got.

            Where did you hear that the CH32V003 can run code from RAM?

          2. Hold up, you’re reading the ESP32-C3 datasheet and applying its limitations to the CH32V003? PSRAM is not SRAM, it’s a small chunk of DRAM with a controller wrapped around it to handle refresh. In this context, it’s also got an SPI bus controller that makes it look like a normal SPI chip. The ESP32-C3 may have these limitations because of the way it’s designed, but the SRAM in the CH32V003 is internal and the core is completely different.

            Here’s code running from SRAM on the CH32V003: https://github.com/cnlohr/cnixxi/blob/master/firmware/nixitest1/nixitest1.c

          3. In my defense, WCH makes no effort at all to make this clear. In both the CH32V003 and CH32V303_305_307 datasheets, they refer to SRAM as “volatile data storage area SRAM”, which to me was a red flag. Only now do I see that the datasheet for the CH32V003 specifies power consumption both for code in FLASH and code in SRAM, which is the ONLY thing I could find in the datasheet that made this implication.

  1. It’s a nice job, but the youtube presentation just bugs me. I wish there was less focus on producing a flashy audio-visual immersive experience, and more boring focus on the actual design.

  2. So while this is really only meant as a proof of concept, I can see one really good use for this exact type setup. The primary computer in a space probe/rover, or any device that needs multiple redundancy. Have them all “vote” (running the math), with one microcontroller not voting and standing in as the vote counter and to act as the controller for the device (also to keep the voters an odd number). These are so cheap that populating a 16x slot board would be trivial. Failure of any amount up to 12 would not require any changes to the ongoing operations. After twelve, a different voting scheme with reduced functionality would have to be engaged, but the chances of 12+ all failing before something else more critical elsewhere breaks is extremely low.

    This inside a cube sat or some other cheaper space device would be perfect.

  3. Using gcc c compiler to produce portable machine code on x86 platforms and ARM A72 Raspberry Pi 4B 64-bit OS works.

    /*gcc -o ee I64b.c
    gcc -g -c I64b.c
    objdump -d -M inte1 -S I64b.o
    // #include
    int main()
    long long a,b,c ;
    a=-pow(2,63) ;
    b= a +-1 ; // -1 = FF FF FF FF FF FF FF FF. 1 = 00 00 00 00 00 00 00 01
    printf(“%lld”,a) ;
    printf(“%lld”,b) ;
    printf(“%lld”,c) ;
    return 0;

    First gcc terminal line runs code.

    Second displays the disassembly.

    Do not have risc-v platform with a Linus supporting gcc yet.

    1. Don’t need one. There’s no point in using Linux for small projects that don’t need multitasking. What I need is a *nix that doesn’t require memory management.

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.