$119+ BeagleV powerful, open-hardware RISC-V Linux SBC targets AI applications

Running Linux on RISC-V hardware is already possible, but you’d have a choice of low-end platforms like Kendryte K210 that’s not really practical for anything, or higher-end board like SiFive HiFive Unmatched or PolarBerry for which you’d have to spend several hundred dollars, or even over one thousand dollars to have a complete system.

So an affordable, usable RISC-V Linux SBC is clearly needed. We previously wrote about an upcoming Allwinner RISC-V Linux SBC that will be mostly useful for camera applications without 3D GPU, and a maximum of 256MB RAM. But today, we have excellent news, as the BeagleBoard.org foundation, Seeed Studio, and Chinese fabless silicon vendor Starfive partnered to design and launch the BeagleV SBC (pronounced Beagle Five) powered by StarFive JH7100 dual-core SiFive U74 RISC-V processor with Vision DSP, NVDLA engine, and neural network engine for AI acceleration.

Beagle V Rev A1

BeagleV specifications:

  • SoC – StarFive JH7100 Vision SoC with:
    • RISC-V U74 dual-core with 2MB L2 cache @ 1.5 GHz
    • Vision DSP Tensilica-VP6 for computing vision
    • NVDLA Engine 1 core (configuration 2048 MACs @ 800MHz  – 3.5 TOPS)
    • Neural Network Engine (1024MACs @ 500MHz – 1 TOPS)
    • VPU – H.264/H.265 decoder up to 4Kp60, dual-stream decoding up to 2Kp30
    • JPEG encoder/decoder
    • Audio Processing DSP and sub-system
  • System Memory – 4GB or 8GB LPDDR4
  • Storage – MicroSD card slot
  • Video output
    • 1x HDMI port up to 1080p30
    • 1x MIPI DSI interface up to 4Kp30
    • MIPI-CSI TX for video output after ISP and AI processing
  • Camera
    • Dual channels of ISP, each channel support up to 4K @ 30FPS
    • 2 x MIPI-CSI Rx
  • Audio – 3.5mm audio jack
  • Connectivity – 1x Gigabit Ethernet, 2.4 GHz 802.11b/g/n WiFi 4, and Bluetooth 4.2
  • USB – 4x USB 3.0 Ports
  • Expansion – 40-pin GPIO header with 28 x GPIO, I2C, I2S, SPI, UART
  • Security – Support TRNG and OTP
  • Misc – Reset and power buttons
  • Power Supply – 5V/3A via USB Type-C port
  • Dimensions – TBD

Based on our previous article about SiFive U74 core, performance should be similar to Cortex-A55, so a dual-core U74 RISC processor will not have that much processing power compared to other Arm board, but the network accelerator should make it competitive against other AI boards like Coral Dev Board mini.

One obvious item missing from the specifications is a GPU, and I was told while the first batch scheduled in March will be GPU less, but the next batch – slated to be manufactured in September – will come with an Imagination Technologies GPU.

BeagleV will be supported by mainline Linux and a Debian-based software image will be provided. I can also see mentions of Fedora and FreeRTOS. The RISC-V Linux SBC will be open-source hardware just like other boards from the BeagleBoard.org foundation meaning hardware design files, firmware, and the software will be made available publicly.

BeagleV SBC will eventually be sold for $119 with 4GB RAM and $149 with 8GB RAM, but for the first batch, only the version with 8GB RAM will be available. Due to the limited supply, the BeagleBoard.org foundation asks people to fill an application form to provide information about software experience and the expected use for the board. It’s also possible to pre-order the board on Seeed Studio, but you’d still need to fill the application form. Additional information may be found on the product page [Update: pages are down due to the project’s cancellation].

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

22 Replies to “$119+ BeagleV powerful, open-hardware RISC-V Linux SBC targets AI applications”

    1. Interestingly, the PicoRio Risc-V SBC will also be first released without a GPU and integrate an imagination GPU in a later revision. What is so bad about imagination GPUs? Linux driver support?

      1. Driver support in general, also when imtel licensed it for their atom it was a pain also under windows.
        And honestly why would I want a linux sbc with a driver situation worse than an android phone? Noone can be sure about the time frame sw updated will be possible. Kernel might well be stuck forever at the same revision the device was released with. Not goo6for safety situation.

    1. The memory controller, the DMA controller, the SerDes/PCI/USB controller are customized for each CPU inside a SoC. And the CPU must handle all those interrupts correctly. But I’m a Java deloper … maybe a VHDL/Verilog enginner will offer a better answer.

    2. Do not be discouraged, CNX is a great source of information and knowledge of the embedded universe. You are on the right track.

    3. If you are a silicon company that already offers an ARM-based SoC, it’s not hard to replace it with RISC-V CPU, but with NRE costs in the order of millions for cutting-edge technologies, you need a good reason (e.g. paying customer) to produce a RISC-V SoC.

        1. “non recurring engineering cost”. It’s a one-time cost that occurs during the development of the product.

    4. Its roughly equivalent to saying – what prevents us from sawing the wings off a 747 and replacing them with the wings of an A380.

      Quite apart from the fact that you’d need to fix all the massive bugs that everyone has already mentioned. You’d then need to verify it (which is 2/3rds of the digital design development effort) and all your verification test benches would be totally different. Then you’d need to re-layout the entire chip (which is all the physical design effort).

      Seriously it would probably be almost as easy to design a new chip from scratch.

  1. The CPU may seem a bit slow but if it really performs like two 1.0GHz A55’s then this is actually pretty usable.

    The RAM is a bit on the generous side. My rule of thumb for RAM allocation is “how much RAM can the CPU read/modify/write in 1 second?” For a modern x86 quad-core that’s around 12GB. This thing will have best-case 1/32nd that level of performance, so 384MB would have been sufficient. 8GB represents more memory than it can meaningfully do something with in 30 seconds… in other words even a spun-down HDD can wake and feed it faster than it can keep up. That’s utterly pointless.

    1. I was also surprised by the amount of RAM at first, but I think it might be needed by the AI accelerators.

    2. I think that a CPU with a 1ns cycle time should be able to saturate a memory bus.
      The x86 memory bus is probably wider so the x86 could get more written than the Beagle-V can in one second.

      This is really to say that your particular rule of thumb doesn’t make sense to me. But there is a useful notion there.

      My heuristic for memory size is (a) the more the better, and (b) the cost of RAM, CPU, and disk should be in a reasonable proportion (balanced).

      1. “The more the better” doesn’t always hold true. When you’re dealing with huge amounts of RAM and little caches, you figure that your data are never found in the caches and that your machine is extremely slow. You’ll tell me that it depends on the workload, but the point is that if you have plenty of RAM you will use it, possibly keeping multiple apps loaded and *that* is exactly what is causing such misses. Recycling memory contents more often leads to better cache hit ratio. And when you see some x86 machines with 32MB of cache for 1TB of RAM, you quickly figure there’s something wrong if your cache is only 1/32768 of the RAM!

  2. Super cool. Filling the RISC-V gap: something that is usable for Linux, but not hundreds of Euro’s / dollars

  3. Small but important Update! Please update the article. The beta BeagleV Starlight board has the StarFive JH7100, BUT StarFive JH7110 is the mass production chip which will be used in future BeagleV Starlight boards. JH7110 will have a upgrade from 2x to 4x U74 cores and adds PCIe and GPU. The GPU will be Imagination Tech IMG BXE-4-32 IP based.

Leave a Reply

Your email address will not be published.