At Last, A Beagle V In The Wild

The RISC-V ISA specification contains the recipe for everything from the humblest of microcontrollers to the most accomplished of high-end application processors, but it’s fair to say that at our end of the market it’s mostly been something for the lower end. There are plenty of inexpensive small RISC-V microcontrollers, but so far not much powerful enough for example to run a Linux-based operating system.

It’s a situation that’s slowly changing though, and it looks as though things may have taken a turn for the better as a new BeagleBoard has appeared using a RISC-V chip. The BeagleV-Ahead has a BeagleBone form factor and packs an Alibaba T-Head TH1520 SoC, a 2GHz quad-core part with a GPU and DSP components on-board. They link to a selection of distributors, from which one can seemingly be bought for about $170.

It’s a departure from the ARM chips that have until now powered the BeagleBoard line, but its appearance shouldn’t come as a surprise to seasoned Beagle watchers as they announced their RISC-V developments back in 2021. We’re guessing they too had to contend with the chip shortage which hit other players such as Raspberry Pi, so we’re pleased to see a product on the market. In particular though we’re pleased to see one on a BeagleBoard. because unlike a random no-name single board computer they’re a manufacturer who supports their products.

There’s a page with a good choice of operating systems for the board, and we hope that this means they provide kernel support for this SoC. This is the real benefit of buying a BeagleBoard or a Raspberry Pi, because cheap competitors will typically support only one kernel version compared with their years of support. So while this board is by no means cheap, we’re hoping it heralds a new wave of powerful RISC-V computers. Something to look forward to indeed.

40 thoughts on “At Last, A Beagle V In The Wild

  1. Why did they choose a TH1520, it contains four Xuantie C910 RISC-V cores. And they all implement the pre-ratification RISC-V Vector Extension 0.7.1 which is incompatible at a binary and assembly language level with the ratified, since 2021-11, RISC-V Vector Extension 1.0.

      1. Perhaps it will become decently documented now its been chosen for a product, the way there is so much atmega328p info online given arduino picked it as the default chip.

        1. By Alibaba I think was their point. Probably the reason for using a non-ratified version of the vector extensions is the time taken between design starting and production of a chip. The design work will have been completed before the standard was ratified.

          The problems that RISC-V has is in price (it’s not cheaper than ARM, except possibly in very cheap microcontrollers), it hasn’t settled down in terms of ISA spec and its performance doesn’t yet come close to ARMs flagship parts (even older higher end designs). The “Open Source” ness of the design has no practical advantage to end users. The chip makers usually take an off the shelf core design, so unless it’s very cheap to them then it has no advantage there either. Only chip designers have any advantage, and it takes them a couple of years to spin a design up to actual silicon.

          1. The open ness of the ISA is meant to appeal to chip makers, it was never made to appeal to end users, it’s the whole point.

            You are right that it takes a couple of years to spin a working part, and that is why RISC-V is still expensive, except in low power parts. You need to climb the complexity ladder, just like ARM did not come out with 64 bits desktop chips, RISC-V will take some years to make it’s way up the industry.

            It is seeing widespread adoption though and you can very well expect it to overtake ARM long term. The ISA is just amazingly designed with the latest progress and attention to implementation ease. We will see the benefits, but it will take 5-10 more years.

          2. The vector extension is particularly tricky as well, because it’s unique: RISC-V vector processing is *very* different than SIMD, and I wouldn’t be surprised if chip vendors had to internally go through a few design iterations to figure out how to allocate chip area to resources.

            Unlike SIMD extensions, the vector instructions for RISC-V don’t really tell you how to build the chip – which is a big advantage for flexibility, but does make it harder to figure out what’s the best way to use it.

          3. Exactly, RISC-V is no better than ARM just because it is an open source ISA. The hardware designs that companies come up with don’t have to be open source, so they then need licensed, just like ARM. Very few companies are going to make their own RISC-V cores when they can just license one, if they wanted to do that there was nothing stopping them making their own processors before RISC-V was a thing but it just made much more sense to license from ARM. That hasn’t changed like so many people think it has. They still license cores from companies, there are just more companies than just ARM.

            Also most companies do not care if an open source core exists, they would rather license a core and get support from the designers and a guarantee that the core has been tested and works like it is supposed to. Hence companies will still license cores and just because it is RISC-V does not mean that the licensing will be cheaper. It potentially means it will be more expensive. With ARM they have a design team and loads of people license their cores, meaning they have more profits and hence could offer the cores cheaper. With lots of smaller companies licensing their cores and only getting a small number of clients each then they aren’t making as much profit so they have to charge more for the licenses. A single company having more profits also means that they have more to spend on R&D and more to spend on better designs and testing. Having lots of companies with worse profits and smaller design teams means that corners will probably be cut.

            RISC-V also is at risk of becoming fragmented and we are seeing that already. ARM will release a feature when it is ready, with RISC-V the extensions are released before they are ratified, so companies are making cores with those extensions and then it all changes and it isn’t compatible anymore. RISC-V is not compatible between different vendors and chips either which can be a problem, at least with ARM you know roughly what a Cortex M0+ is or a Cortex M4 and can expect very similar performance at the same clock speeds, you don’t get that with RISC-V since everyone is free to create their own microarchitecture so they are harder to compare and can vary massively in performance.

          4. I’ve been very happy with RISC-V as a means for embedded a processor in an ASIC. I’m a software guy, and it makes my job a lot easier when we can have well understood SW components for toolchain, runtime, and kernel/RTOS.
            I think as the chip for your central processing needs, we’re still at the stage where early adopters are paying a heavy price. For experiments and toys I use the Allwinner D1, which has a whole host of binary compatible problems, but it is very cheap so it will be painless on the day I have to throw it out and upgrade to a RISC-V that fully conforms to spec. You won’t see me sinking $1500 into a sketchy laptop that might not be around in another 2 years. I’d rather go for an ARM and if I really want to be open source friendly that MNT laptop might satisfy that open source itch better than a similarly priced and massively faster Apple.

    1. There aren’t really any available SoCs with the ratified vector extension, or at least there weren’t when this thing was being designed (I haven’t really been following risc-v for half a year, this may have changed).

      I’d say it’s better to have some pre-ratified vector extensions than wait the year and a half or whatever the lag time was between early revs and ratification. According to Bruce Hoult, they’re functionally pretty much the same, even if the exact instruction syntax changed a bit. Better to have it available and get people writing code for it, and have compiler/linker checks for the extension version.

      1. > have compiler/linker checks for the extension version
        The people writing compilers are just going: “not going to happen”, we will never support any pre-ratified Extensions.

        So you end up with a forked compiler tool chain ( e.g. ) produced by the people who designed the chip, that will support the pre-ratified Vector Extension and any other custom Xuantie Extensions they added – that are not part of the RISC-V ratification process, and their custom compiler tool chain will probably receive updates for as long as they are selling the chips in bulk, but once that ends, they will probably never be updated again.

      2. Using an extension when it is pre-ratified just fragments what RISC-V is. You have some chips working with pre-ratified versions and some with ratified versions and they aren’t compatible.

    2. BeagleV is the Foundations’s brand for RISC-V single board computers. We plan to have a variety of models in the future based on various RISC-V SoCs. The primary constraints on SoC selection are sufficient quantity to do a production run of boards, and low enough cost for the board to not be too expensive (MSRP under $200, ideally far less than that).

      Our ideal SoC vendor sells their chips into catalogue distribution (like Digikey) and therefore has detailed public documentation and the chip can be ordered in low quantity. This is the standard set for our ARM based BeagleBoard, BeagleBone and BeaglePlay.

      We aspire to have those same values for our BeagleV boards, but, for now, we have prioritized getting designs out with the currently available RISC-V SoCs.

      Regarding vector, an unfortunate reality of how long it took for Vector to be ratified is that it is taking a long time to for there to be shipping SoCs that implement RVV1.0. I am looking forward to the next generation of SoCs that hopefully implement RVA23 which includes RVV1.0 and several other important extensions ratified at the end of 2021. Longer term, RVA24 will be a major release that we will probably see a lot of systems standardize on.

      -Drew Fustini

  2. The PRU of the original BeagleBones were a great feature at its time. Others had something like that too (think of this OpenRISC, AR100, etc.), but were not that easily accessible (lacking good documentation, small user community, …).

    What is outstanding on this board with its TH1520? It is neither more powerful, nor has features not to be found on other SOC. It is not eaven cheaper than its proven SOC competitors.

    1. Although great, it´s a pain in the ass to program, it lacks much documentation and examples, and the user base is definitely too small (chicken and egg situation) and not growing.

    2. 4 TOPS NPU, 4K H.265, 2xCSI, 1xDSI, 50 GFLOPS Imagination 3D GPU … this SoC has a lot more than just the fastest currently available RISCV64GC CPU cores. I’m confused what you might consider more powerful.

      It does not have PRUs…. BeagleBoard is not moving away from TI SoCs that *do* have PRUs.

    1. Fear what you cannot understand. That backdoor thing is largely a myth, when cost-optimization factor tend to squeeze the die as much as possible. I don´t say it does not exist, but I doubt very much such chips got one.

      And the people who fear using chinese chips all have a smartphone, how ironic…

  3. “because unlike a random no-name single board computer they’re a manufacturer who supports their products”

    Hmmm. I’ve recently looked at the BeaglePlay and BeagleConnect Freedom, and the biggest struggle I’ve has is that the fact that the documentation is still mostly “TO DO” placeholders. For a board they billed as an easy plug-and-play experience, it really wasn’t. I suspect now that focus has already moved on to the next shiny thing that it will probably remain “TO DO” forever.

    I know that the open source ethos is “well, it’s open so grab the datasheet, work it all out from scratch, maybe update the documentation yourself”. However, when I could just grab a Raspberry Pi and know I can just get on with things instead that’s hard to justify.

    I love the BeagleBoard hardware, but the documentation and support not so much.

    1. I have an original BeagleBoard. (looks) Last distro version was 2018. 10 years after it was launched? Not too bad for support I’d say. That’s no guarantee they’ll do the same with this one, but I said that based upon that experience.

  4. Grammar…

    There are plenty of inexpensive small RISC-V microcontrollers. So far not many powerful enough, for example, to run a Linux-based operating system.

    It’s still an awkward sentence.

    There are many inexpensive RISC-V microcontrollers, but few are powerful enough to run a Linux-based operating system.

    Removing the duplicated sentiments and unnecessary turns of phrase makes it much more clear what you are trying to say.

    1. Funny, I simply noticed a missing comma after “So far”. Maybe that’s because I’m German, not sure. Some of us use a lot of side sentences, separated by commas, so reading isn’t so boring, or lengthy. Alas, I assume, English language isn’t exactly the same, though, because it has, in parts, to some degree, departed from its German roots, with the Latin and French parts being more present in nowadays English. Otherwise, I think, there would be more German derived words, such as rain shade, which could be an alternate word to umbrella, because it relates to it in a similar manner like sun shade relates to parasol.

    1. not that that isn’t an interesting board, and $11 an interesting price point! but i think that kind of makes the point…a board with 64MB RAM is pretty low-end these days. (but i’m only using 41MB out of the 2GB on my pi, it would actually suit my use fine.) the RISC-V ecosystem is still very young and doesn’t yet seem to have compelling options at all the different scales.

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.