RISC-V Comes To The BeagleBoard Ecosystem With Upcoming Beagle V SBC

The Beagle V, a RISC-V-based single board computer from a collaboration between BeagleBoard and Seeed Studios aims to be “The First Affordable RISC-V Computer Designed to Run Linux”. RISC-V is the open-source processor architecture that everyone is interested in because it bypasses proprietary silicon of manufacturers such as Intel or AMD, allowing companies to roll their own silicon processors without licensing fees for the core.

BeagleBoard has long been one of the major players in the Single-Board Computer arena so far dominated by the Raspberry Pi. The board, slightly larger than the company’s previous offerings, features a StarFive dual-core 64-bit RISC-V processor running at a 1.0 GHz clock speed. The spec sheet on their GitHub repo indicates 4 and 8 GB RAM options, built-in WiFi and Bluetooth, and hardware video support for decoding, two camera connectors, one DSI connector for an external display, as well as a full-sized HDMI port. Gigabit Ethernet, four USB-3 ports, an audio jack, and USB-C as the power supply are packed onto the edges of the board. GPIO is routed to a 2×20 pin header.

Seeed Studio pegs the cost of the board at $149 for the 8 GB RAM version, although currently you must apply and be selected to purchase a board in this early stage. It’s unclear if the price will remain unchanged after this first run; the product page notes a coupon code is necessary and the Seeed Studios article indicates this is an introductory price. However, the same article also lists the 4 GB RAM variant at $119. The BeagleBoard page shows a timeline of April 2021 for a “pilot run for community”.

It’s exciting to see RISC-V continue to make inroads. This is a powerful board based around the core, and if successful it will help further prove the viability of open source processing cores in increasingly mainstream products.

54 thoughts on “RISC-V Comes To The BeagleBoard Ecosystem With Upcoming Beagle V SBC

  1. I am simply ignorant, but what is better about Risc-V compared to ARM ? Are there technical reasons to want to work with Risc-V ? Most of what I have heard have been phiilosophical and “moral” sort of (but that is a poor choice of words).

    In other words is it better than ARM in any way other than legal issues and licensing?

    1. Licensing is also a technical issue. The appeal of RISC-V for businesses is that they can build a custom chip around a RISC-V core with the specific peripherals they need for a product without having to pay a license fee. Building around an open architecture is presumably also nice for being less reliant on black magic voodoo binary blobs and hardware support for Linux or whatever platform.

        1. Raspberry pi is not “open” at all, no tech specs available for the SOC, no schematic available, video driver and bootloader are closed source. It’s no more open than a Mac. Great for doing stuff but a miserable fail if you want to learn how stuff works.

          1. You are wrong ‘X’ stop spreading false information. There are parts of the SOC that are closed. It would be naive to expect otherwise. But plenty of it is open source including the video driver.

      1. You are right about the licensing. This is really handy if you are going to use it as a softcore in an FPGA. You have no idea how many FPGAs use 8051 soft cores because they are free.
        For bigger users yes making a custom solution is really of high value for example Western Digital is going to use them for storage controllers.
        As to why you might want to use one? A good reason is for employment. The RISC-V is gaining interest in industry so have experience with it will be of value. If you actually have some kernel commits for it then you value is even higher. Plus it is just fun to learn and play with cool new hardware.

      2. So far all of the above has been mostly no more than a dream.

        Companies just aren’t launching RISC-V products. From what we’ve seen, the only companies that have brought RISC-V chips to market have been based in mainland China. Most commonly this has been through seeed, like the Kendryte K210 and now the SoC powering this beagleboard.

        One driving force may be that Chinese fabs are concerned about loosing legal access to the ARM architecture, instead of simply paying fees. (For more information, see the recent splintering off of ARM’s government-owned Chinese branch)

        There was briefly the HiFive1 arduino competitor, but those are no longer commercially available. WD has expressed some interest in RISC-V and ported the Chinese Kendryte K210 to Linux, but that’s about it for tangible products from western companies.

        Suppose then, that you aren’t concerned about Chinese government involvement. Of the Chinese RISC-V products that DO exist, one can’t say that they’re particularly open. Despite using an open *architecture* none of the chips are any more “open source” than your usual fare from Broadcom or Frescale. You’re lucky to get a half-decent english datasheet describing registers and source code for linux support.

        They certainly can’t compare to the expected (hopeful) result of the Libre-SoC (formerly Libre-RISCV) project, with full HDL, tooling, masks, and chips available. It’s worth noting that the Libre-RISCV project was ironically forced out of RISC-V by the extreme secrecy of the few companies interested. They’re now based on OpenPOWER.

        I don’t have high hopes for future openness among RISC-V implementors. There’s absolutely nothing that says the chips need to be as open as the architectural specification. I can’t comment on the openness of american chips that don’t exist, but I expect that the chips coming out of mainland fabs will continue to follow the trajectory of the ESP8266. It first popped up on seeed and became wildly popular, but requires a large binary blob between yourself and the internet, controlling the WiFi radio. To this day that’s still the case.

        As a personal experiment in openess I have had a look for other WiFi-enabled microcontrollers. Unfortunately, it looks like all the STMicro stuff has been killed off and TI stuff is fairly obscure. Hobbyist WiFi will probably continue to use Chinese blobs or large OpenWRT WiFi routers/Raspis for the forseeable future.

          1. As noted here [1], those chips are based on the “Nuclei RISC-V Process Core” from Nuclei System Technology in mainland china. See [2].

            It’s important to follow the chain of manufacture. As noted below, the canned WiFi modules used on many official Arduino boards, for example, are actually ESP8266s repackaged by a firm in europe. Same chip, same Chinese binary blob between you and the internet.

            In this case, it looks you’ll be using Nuclei’s SDK containing their own binaries.

            [1] https://doc.nucleisys.com/nuclei_sdk/design/soc/gd32vf103.html

            [2] https://www.nucleisys.com/

          2. @M
            A quick search on the nucleisys site points to this modified snapshot of riscv-openocd.
            https://github.com/riscv-mcu/riscv-openocd (This branch is 238 commits ahead, 839 commits behind riscv:riscv)
            So maybe using a FPGA based on riscv-openocd would be a safer option, if you are concerned about state sponsored spyware.

            But if you know the ISA that a binary blob runs on you can disassemble it and fully inspect its functions.

        1. The company I work for is sure making R-V cores, but no one cares or knows as it is deep inside ASICs.

          China has embraced RISC-V, as it is western enough to be accepted elsewhere (so it is not too Chineesy) and is free as in ‘goodbye ARM’.

          I don’t see western companies taking RISC-V seriously, as their upper management must obey the shareholders interests, and day after day big companies are merging. A big investor on NVIDIA or Softbank is most probably also an investor on Apple, Intel, Broadcom, Qualcomm, etc, so the money must be kept rotating between them.

          It’s about profit, and the free part of RISC-V reduces some of it.

          Unless you’re Chinese. There is a national strategy to follow there. Capital works for the State and not the other way around.

        2. Obviously most RISC-V CPU/SOC, near all of them, will be closed, as closed as ARM SOC, even a very high percentage of RISC-V will be invisible to us (auxiliary CPU, CPU inside devices like SSD, etc. etc).

          BUT it can be some open minded RISC-V CPU or SOC, where you have all documentation and there be no closed parts (at least no more than indispensableĀ¹, as there are some tech having IP), will reach market for people/companies worried about privacy, freedom and related facts. That is simply impossible with modern x86 or ARM ISA. For me, as a user, that is the big difference. On other side knowing RISC-V can be a professional option as this ISA will be very used (mostly for closed hard).

          *** So, yes, open RISC-V CPU/SOC will be very few, probably a niche market, but that market may exist, where it can exist on x86 nor ARM. ***

          The same for implementations of RISC-V ISA (particular CPU design using RISC-V ISA): If you don’t design your own and you use one yet designed, most of them will require a license/payment, but there will be open designs, probably not so good like pay-for/licensed designs, but they exist. Open RISC-V core design exist at present moment, and there will be more and more. This is equally impossible with x86 or ARM due to licensing/copyright ISA limitations on those architectures.

          I am not saying you need an RISC-V open CPU implementation to have a no-closed no-blob (or near no-blob) no-totally-documented RISC-V CPU/SOC. You can use design/implementations from few companies following that way, like I suppose Si-Five and others, although most companies designing RISC-V won’t follow that way, of course.

          Ā¹: For example if you look at MNT Reform notebook, you will see there is only one mandatory small non-ARM blob for DDR4 controller, and other “optional” blob for HDMI (you can use it of you want to use HDMI, or don’t use that blob nor HDMI).

        3. Addendum: How could I forget that future ESP chips (made by Espressif in china) will be based on RISC-V? Probably packing the same closed-source binary blobs running the radio and other peripherals.

          In case you were wondering, those canned WiFi modues used in a handful of arduino boards are just rebranded ESP8266 chips….in a metal can. Same chip, same blobs.

    2. Since there is no license fee you will see lots of competing products and the price will be low. ARM licences are expensive and hard to get so RISCV will open up a lot of new opportunities for new products. Learn it now and get in front of the wave.

      1. ARM licences are cheap, dirt cheap, and quite easy to get, even for chinese companies.
        But it’s mostly an end of an era, royalties can only go up from here and US/China trade war has started, so better be prepared for that.
        I am not even talking about nvidia potential acquisition (which can pretty much goes belly-up due to trade war), this will be a full blown shock (nvidia want to be above 50% margins, 60 to 70% mostly).

        1. Royalties as you say are really cheap for ARM ISA, but the point isn’t low price but conditions and availability.

          If you license ARM IP you are very constrained (even more if you are not a very big one), and you can’t do all you want (and it is not the same a license for using ARM cores/IP than licensing ISA itself so you can design your own cores like for example Apple does). While on RISC-V ISA you can do simply all what you want without asking permission.

          An the other point you stated: trade war. China stills plays with ARM, but they want to be totally technology independent from western/US by 2030, so they can’t rely licensing on a US/western ISA. In fact we have seen how last year Huawei was banned from using new ARM designs.

          RISC-V has moved to be incorporated in Switzerland, so it will be neutral on those trade wars. In this way it is an international libre ISA, not aware of trade/policy wars, totally neutral on that way.

          PD: A Chinese company have an x86 license from Via old license I think, and they have designed their own x86 for Chinese market, but on the long way I don’t see advantage on using a so dated CISC ISA having much better modern ISA like RISC-V (of course that x86 can be useful to run x86 soft until emulation on a modern ISA be good enough; Apple has showed how good can be their ARM running x86 soft with Rosetta 2).

    3. On paper it could be free of binary blobs. But in reality with a powerful machine with the latest and greatest hardware there will binary blobs somewhere. e.g. blobs in the firmware of the Wifi/bluetooth chip.

      But at the end of the day it is just another ISA, a very pretty one that takes lots from expired patents. You could say that there is nothing new in the ISA at all, and technically you would be right. But if copyright had a duration similar to patents it would be akin taking the best lyrics up until 2000 (e.g. Bob Dylan, Simon And Garfunkel, Louis Armstrong, David Bowie,… ), mixing that with the best guitar rifts up until 2000 (Jimi Hendrix, Cream, Rolling Stones, Chuck Berry, …) adding blending that with the best beat up until 2000 (Gene Krupa, John Bonham, Buddy Rich, Keith Moon, Neil Peart, Stewart Copeland, Dave Grohl, …) and you may end up with nothing new, but if done right it could be damn fine.

      1. Ā« there will binary blobs somewhere. e.g. blobs in the firmware of the Wifi/bluetooth chip Ā»: Yes, some components will require blobs and are no IP-free and there is no open driver in most cases. But the point is to have that components in some way separated and not mixed with user CPU and user SO, to better warranting your security and freedom.

        For example in Librem 5 you have a cellular modem and that component is totally separated from main SOC, running its own CPU+SO and communicating with main SOC by a line controlled by this SOC. Even you can turn it off. On modern smartphones from a lot of years ago it is usual that cellular modem be inside SOC and/or controlled by a software running with higher priority than user SO, so they could have access to your OS+apps/data. It is like IME running in a in inner level with higher priority inside your Intel CPU PC.

        Of course, we won’t see this on best, more powerful SOC. Openness/privacy/etc minded market will be a small niche market with theirs implications.

    4. Yes, yes. I know all of that and have heard it many times. I am not arguing with it or taking sides in any way, but I was asking an entirely different question that nobody has answered yet.

      1. I work with RISC-V professionally, currently working on a RISC-V SoC design at a mid size tech firm.

        To answer your initial question, from a technical side, RISC-V is about as performant as ARM, in fact it has very similar code size, and execution speed on matched architectures (comparing apples to apples, because RISC-V has lots of extensions).

        So the question is why would you choose an architecture that is just slightly as good as ARM? The answer is simplicity, you can read the entirety of the RISC-V standard in about a day, while it would take a month for ARM. RISC-V is incredibly well defined, and modern, it solves all the idiosyncracies of ARM, and takes a ton of really nice shortcuts while not compromising performance.

        So from a technical side, it is easier to implement a RISC-V core, it is easier to program it, the tools are open source and free, overall it is a superior technical choice.

        the only caveat is that it is only the start, RISC-V is only starting to get actual industry acceptance for the more basic extensions IMC, Integer only, on chip multiplier, with compressed instructions.

        The way I see it, RISC-V is slow and steady, it will take time, but it will penetrate all the strata of processor design, it will never replace ARM or x86, but it will be the only architecture we see everywhere from toothbrushes, to desktop, to supercomputers.

        1. This is a great answer and helps me a lot. I have indeed struggled under the ocean of ARM documentation. Better that than meager or non-existant documentation mind you. The apple of my eye is currently the Zynq-7000 with its duo of ARM cores and this FPGA nut it has for me to crack.

          But Hackaday is how I keep my ear to the rail. I try to avoid every learning curve, so I evaluate which waves to try to ride. Life is short.

          Up to now I have only heard what I could term “political statments” on what Risc-V is all about and I was hoping for more. You have given me that! Thanks. I’ll take a peek given what you say about simplicity and accessibility in a days time. Modern clean design also is appealing.

        2. Thanks Val, I am a senior developer for a public company, and could not agree more with your comments.
          I do however see potential as a soft core.

          But again, as others have pointed out “why change now” ?

      2. Seems to me that the biggest upsides at the moment look like low power use and frequency scaling. Some versions are claimed to use a tenth the power per performance unit as equivalent ARM. Clock frequencies have been pushed up past 6Ghz experimentally. So longer term, it looks like you could have 20 core 4 Ghz RISC-V in your phone with the same battery life as 2Ghz quad ARMs. However performance per clock is looking a tad slower than ARM on some workloads, but you get into the which ARM vs which RISC-V featureset thing.

        Would you want one on a desktop or in a laptop? Well yeah if they can just throw Ghz and number of cores at the performance issues and not have to worry about power. Could get insane performance out of the amount you could run on 10 or 15W.

    5. > ARM in any way other than legal issues and licensing?

      At the end of the day, the consumer have to get values from his/her money. Does the platform have better performance/price ratio? Is it more readily available? Are there more software or better support? Is it less buggy?

      It is not like having something open source is very different than software with mininal cost other than time. It doesn’t mean that eveyone is an processor expert that can fix bugs and have the resource to order some SoC and get system designed.

      It is not like any savings in licensing is going to be passed on directly to the consumer. In the end, it only benefit the corporations and their bottom line. You might actually get more competition and savings from higher volume from the different Arm SoC vendors.

      The perference at this point is mostly a political statement.

      1. > The perference at this point is mostly a political statement.

        I consider is it more a strategic decission. Like buying a house or renting a house. The house that you did buy, is the house that you are allowed to adopt to your needs. Also the one you are allowed the study. Do know that professors are smart and they train their students to be even smarter. There is much more learning in implement than just using technology.

        > > Where is RISC-V better then ARM?

        Not important, even the wrong question. As wrong as “Where is my partner that I love better as the movie star I admire?”

      2. “The perference at this point is mostly a political statement.”

        So when I choose a part that I can get specs for, as opposed to a part where specs are unavailable, that is political? Seems like a Purely Practical reason to me

    6. RISC-V ISA is designed for extensibility, for adding custom instructions for compute accelerators and whatever else you may want. And having a development platform with a similar ISA helps a lot. So yes, it’s the most exciting as a development platform for those few who design RISC-V extensions, and not some raspberry pi replacement.

      1. Not only that: it is designed to allow to deprecate instructions and replace them with new ones. This can simplify future designs, which would be fully binary compatible with old designs while keeping the design to a minimum.

    7. The RISC-V Instruction set is not better then ARM. I’d rather say, ARM/x86 have more extensions standardized that RISC-V doesn’t. Like SSE/AVX,Neon, RISC-V has a draft Vector extension but it’s not final yet. From a technological standpoint it is weaker then ARM/x86 in propaply very many ways.
      The advantage now is, you don’t have to pay for the instruction set. This is only an advantage if you want to design your own CPU. Using a finished Risc-V CPU has no technological advantage over ARM unless the RISC-V was specifically made for your use-case.
      If Risc-V is successful enough and open source, high performance/low power CPU-Core designs are available and FABs get their setup costs way down so you can efficiently design and manufacture your own CPU only then the end customer will have a real advantage. Think like JLCPCB allows you to manufacture assembled PCBs for cheaper then buying them pre-made (in quantities of >10). (That Voltage Step-Down from yesterday was 3$ on tindie, JLCPCB can manufacture and ship 10 for 30$ or 20 for 35$) But the advantage is not (for a looong time) that it may be cheaper to build your own, it is that you can get exactly the right chip for your use-case. Big companies can use that advantage already today without paying for an expensive ARM IP license.

    1. it’s not about the implementation being open, RISC-V isn’t for the schmuck on the street who wants to know what’s inside their processor. The open source-ness is for implementers to use the instruction set and benefit from all the software support.

      The open source benefits companies, no people, and it was designed to be this way, and it is a very positive thing that often gets misunderstood about RISC-V

        1. The specs of the ISA? Sure. The specs of the CPU you bought? Not at all. They might release them, but they are under no legal pressure to do so. Why would you share the specs of your GPU on Risc-V but not on Arm?

        2. RISC-V ISA is free/open, but it doesn’t mean RISC-V chip or particular design be free/open. In fact, RISC-V is “SO FREE” that it lets you build TOTALLY CLOSED CPU. I.e. with RISC-V you decide and you can design a CPU and open it or maintain it totally closed.

          Most companies using RISC-V will do work totally closed, even a lot of them only for internal use. I think only a small fraction will do open RISC-V CPU or SOC where you at least get no obscure/undocumented/blobs parts.

          The good point is that there can be some companies, although very few, giving that type or CPU/SOCĀ¹.

          Ā¹: Of course some components in a typical SOC have no free IP.

  2. Does this dispense with the deterministic Programmable Realtime Unit (PRU)? I don’t see them mentioned. Sure, it’s for a different use case entirely, I get it, no problem. Just wondering if I missed something or if it’s slated for Version 4 or something.

    1. My understanding is that the PRU is part of the TI AM3 chips used in beagle boards up until now. But since beagleboard+StarFive+Seed Studio appear to be creating bespoke silicon created (I am guessing at a fab in Taiwan), depending on the patents held by TI on this feature may be added, or maybe not. Since the final chip will not be on the board going to the beta testers, it is far too early to know for sure. It does sound like a feature that would be mentioned, but due to TI trademarks might end up being called something different.

      But technically that feature makes the chip a controlled item covered by EAR(/ITAR) category 3 “e. Electronic equipment for time delay generation or time interval measurement, as follows: e.1. Digital time delay generators with a resolution of 50 nanoseconds or less over time intervals of 1 microsecond or greater; or e.2. Multi-channel (three or more) or modular time interval meter and chronometry equipment with resolution of 50 nanoseconds or less over time intervals of 1 microsecond or greater”, but then again you could easily argue that the same is true of most CPU and FPGA chips that are sold today. A signal with a wavelength of 50ns would have a frequency of 20 MHz, lots of equipment could easily be in violation of that particular Export Administration Regulation. But since the CPU will probably not be manufactured by US company, and be manufactured outside the US, EAR would not apply anyhow or would it ? Is there an IAR (Import Administration Regulation body in the US) ?

    2. I was going to mention the PRU. They are one of the big reasons to go with the TI chip based beagles. I don’t expect to see them in the Risc-V based units, but if they or something like them were licensed and made part of the new boards it would be a good thing. IO on the new boards looks a bit meager frankly.

      Being able to run linux on the ARM and bare-metal code with deterministic timing on the PRU units is what made the beagleboards unique and special. Now something like the Zynq-7000 with an FPGA alongside the processor cores would be another (and even better way, apart from the learning curve) to provide that kind of functionality.

    3. I’m curious but would say the TIMER function in chip like the GD32VF103 processor provide the functionality that you need ? (or any generic MCU, I just happened to be reading the user manual for that chip)
      (ref: chapter 15 in a document found by searching for “GD32VF103 MCU User Manual filetype:pdf” in your searchengine of choice)

      o Total channel num: 4.
      o Counter width: 16-bit.
      o Clock source of timer is selectable: internal clock, internal trigger, external input, external trigger.
      o Multiple counter modes: up counting, down counting and center-aligned counting.
      o Quadrature decoder: used for motion tracking and determination of both rotation direction and position.
      o Hall sensor function: used for 3-phase motor control.
      o Programmable prescaler: 16-bit. The factor can be changed ongoing.
      o Each channel is user-configurable: input capture mode, output compare mode, programmable PWM mode and single pulse mode
      o Auto-reload function.
      o Interrupt output or DMA request: update event, trigger event and compare/capture event.
      o Daisy chaining of timer modules to allow a single timer to initiate multiple timing events.
      o Timer synchronization allows selected timers to start counting on the same clock cycle.
      o Timer master/slave mode controller.”

      A GD32VF103 is a typical MCU with between 6kiB and 32KiB of SRAM with between 16KiB and 128KiB of FLASH, it is nothing special, but it is MCU so it is not running an OS. It is not the same as a PRU, but almost any generic MCU’s could be shoehorned into covering the common PRU use cases (and probably at a much lower price point).

      1. What I want to do is run a Linux desktop that can bit-bang an S-100 bus at close enough to original 1976 speeds (a couple of megahertz) so I could run a floppy controller in polled mode. I need gobs of GPIO pins, some of which can be pretty slow, but some of them need to be able to imitate a bus request, and then start clocking in bytes and incrementing 16 bit addresses at about 800 KHz. The Raspberry Pi family doesn’t have enough GPIO pins, at least not to do it the easy way. I can do it if I multiplex everything to death, but the speed will be even worse. A brute-force solution should be easily possible on a Beaglebone. Very easy on an Apple ][ (oh the irony [grin] ).

        I’m on this minor kick of connecting everything to an S-100 bus.

        1. I often think about this problem, it’s interesting.

          Mixing hard realtime and a normal computer. Some other solutions that come to mind are parallel dual port memory and just running a connected microcontroller to do the timing critical stuff, and have it pass messages to the modern computer using your favorite protocol. As long as you’re writing the micro firmware it’s still “yours”.

  3. My understanding is that RISC-V is more of an open sourced ISA than a silicon implementation. There are now companies setting up to design RISC-V cores and licensing them. These will be the same old licensing models that Arm uses. The only difference is that the ISA is common and open sourced. Sure there will be the open silicon implementations but you can be assured they will not be the best, fastest, lower power chips. Designers mostly want to be paid for their work, and they are not going to give that away.

    Can you license an Apple M1 design? Nope. It’s proprietary to Apple – it’s not even an ARM licensed core! It just uses an ARM ISA and even that may not be totally true. Apple have been designing their cores for 10 years. They even released a 64bit ARM before ARM had their own to license.

    RISC-V is great for universities, and has advantages for small companies to build small (slow) RISC-V micros for internal embedded use (eg Western Digital etc) so they don’t need to pay royalties.

    Sure you might eventually see servers built using RISC-V (think Google, AWS, and even perhaps MS) but don’t expect that the silicon design will be open sourced. It will just be the ISA being used.

    So, in most respects, it’s a con job.

  4. I’d love to see a ‘real’ mainboard (or system on a backplane) with upgradable RAM and card slots where I can decide to have or not to have a GPU or only a serial or ethernet console. These all in one board cannot be the last word! Back to bus systems and upgradeable cards and components! Maybe even like S100 or Eurocard systems!

    Upgrade-ability reduces e-trash!

    1. I agree – kinda. But for every upgraded PC, there are probably 2 PCs that are never upgraded. So they throw away a bunch of stuff more then if it was all integrated. No PCIe/RAM Slots, smaller Mainboard & Case, less cables, better signal quality between components (since its soldered) and much more… I like my self-build PC, but for the majority of applications, an overpowered mass-produced SBC is the cheaper option and probably also ecologically not worse.

    2. The full motherboard version is going to start shipping in March https://www.sifive.com/boards/hifive-unmatched
      not cheap though!

      The upgradeable ram is tricky–DDR4 requires training on a per-module basis which is horrendously complicated and expensive to verify (~$1M worth of test equipment and software licenses), so it is a huge time saver for a project like this to just pick a vendor of DRAM and validate the board with those specific chips on it as opposed to supporting removable dimms.

    3. I think Risc-V is not yet supported enough to really be able to make use of PCI style bus – it can have the IO header, know and work with the rules of the PCI devices standards, but ultimately the arch still has an influence on if software for that device will function.

      I’d love to see more Risc-V, and being open there is hope it will grow rapidly and have the rough edges fixed in short order.. But I don’t think its yet really ready to play ATX style computing, and I’m not convinced it should be any time soon – When you really want to create that universal computing device with heaps of options its a massive catch up required to get even close to x86 and 64bit, pushing for that now will just disappoint any user expecting that frictionless experience.

      Wonder how much performance these native silicon Risc-V’s have.. I’d love to play with em’ but I think FPGA soft-core options are probably better for my experimentations for now. Though this is highly tempting to play with..

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.