I just purchased a boatload of Chinese RISC-V development boards for about $2.30 a piece. Can't wait to start playing with them.
"RISC(-V) architecture is going to change everything."
What's important in the context of a European "sovereign computing" initiative is the licensing of the instruction set architecture. Like x86, ARM is still proprietary, while RISC-V is a free and open standard.
Saudi Arabia did recently invest 45 billion dollars in the vision fund which is an investment fund managed by Softbank but they haven't really invested within Softbank itself so not it is not mostly owned by Saudis from what the data can tell.
My point would be that it has already been demonstrated that you can lose access to ARM technology as a consequence of US sanctions.
ARM is not a sufficiently independent ISA to guarantee sovereignty.
With RISC-V, you may lose access to a specific core, chip, or supply chain. But your ecosystem can pivot to an alternative. Long-term, you have the option of complete in-sourcing.
So, even working with Chinese chips and boards today can be progress, as long as more domestic RVA23 options can be expected to arrive later.
Even though it's Japanese-owned most of their R&D still takes place in England.
I know that sometimes "European" is used as a synonym for "in the EU", but most of the time this is sloppy. Nobody in Europe thinks UK is "not European".
RISC-V is IP UNlocked. I bought RISC-V mini-boards (so cheap) years ago because I was planning to build my keyboard... but I am still on other projects... and there are even better RISC-V miniboard nowdays (better USB, more GPIOs... for a full fledge BFO-9000 keyboard!).
What I am waiting for are RISC-V high performance micro-architectures which will use the best silicon node (desktop, mobile, and for servers it seems there are a few attempts). One of the main issue seems... the compressed instructions which should be removed as it increases implementation complexity significantly in order to apply some of the known high-performance optimizations (it is not anectodale if ARM removed thumb machine instructions).
I like the idea, I code as much as possible things in RISC-V assembly now, and re-use a ton of code paths (at the assembly level!). I have even written a small RISC-V interpreter for x86_64 for static exes.
All they want is to suck on the government's tit.
There is no tangible advantage to Europe adopting the ARM ISA for domestic chips at any scale.
This is like comparing an 48MHz ARM-Cortex-M0 with the CPU in your Macbook. Yes both of them are ARM cores, but the small embedded processor has very little RAM/Flash/clockspeed, no memory management unit, no cache, no modern RAM interface.
Not even the instruction set is really the same, because you (typically) won't even have floating point instructions/registers on the small MCUs, much less vector instructions.
The Milk-V Jupiter 2 mentioned in the post is basically a full-fledged Desktop CPU and it's price is not gonna be anywhere close to $2 either...
But there's a lot of basically-desktop CPUs in industrial automation too, because those are not that expensive and very useful for higher bandwidth interfaces (think ethernet based), cycle times in the microsecond range (higher CPU clock gives you a much more generous cycle budget) and just a generally easier time doing anything where a FPU and memory helps (motion planning, driving some UI on a touch panel, etc).
See:
The CPU clock cycle time of any random Cortex-M0+ is on the order of 30 nanoseconds, a much higher clock speed than the microsecond range you're taking about. The microcontroller also has much better response-time predictability than you can get on a basically-desktop CPU, with its TLBs, three layers of cache, DRAM CAS latency, variable latency to open DRAM pages, SMM, Intel ME, high-priority DMA delaying the CPU's RAM access, etc.
ERICI's plan to run Linux under a real-time hypervisor is definitely a thing that can be done, and a thing that is regularly done on cellphones and industrial-control systems, and has been since the 01990s, among other things, with RTLinux and Linux-CNC. But, although I need to say that I lack any experience in the area, I'm skeptical that it is a sensible tradeoff in 02026, where by rearchitecting the entire system to run under a hypervisor you can maybe avoid spending 9.97¢ on a 48MHz Cortex-M0+ https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU... or 17¢ on a 48MHz RV32E CH32V003 https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU.... I think it made more sense in the 01990s where EMC/LinuxCNC was running on an 80486 that was half as fast as the Cortex-M0+ but cost US$2500. I think it might be a better tradeoff to avoid having any CPUs that have to run "mixed-criticality" workloads, as seL4 calls them — where the same CPU is timeshared between a best-effort Linux workload and hard real-time code. The problem with hard real-time code in industrial automation is that, if it misses a deadline, it can crash your lathe and cost you US$159,532.53. You're depending on your real-time hypervisor to make sure that nothing Linux can do can make that happen.
It seems like it would probably be better engineering now to run the hard real-time control loops on a tiny dedicated computer that costs 37¢, and communicate with the Linux box over I²C or USB or a UART or PCIe or something. To get the response times lower than microcontrollers can guarantee, people seem to be moving to FPGAs. You can get a small FPGA for US$2 now, and the latency from inputs to outputs is typically on the order of 10 nanoseconds, much quicker than a microcontroller can respond from an ISR.
Avoiding one crashed lathe can pay for a lot of microcontrollers.
Why plan? It's working right now, alongside QSOE/N. Resources nicely partitioned: graphics controller and UFS storage for Linux; NVMe, Ethernet UART for QSOE. Please see the demonstration video.
Have you noticed that Linux on the diagram is a general-purpose OS, used for non-critical tasks? Or, refusing to watch the video, you refuse also to see what's actually depicted on the page?
> it's been working since the 01990s
What's been working since the "01990s"? What hypervisor in 1990s drove real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation?
LinuxCNC (EMC2) was using that approach too, but at first I think they were trying to get hard-real-time performance out of Linux itself, and later I think they might have been using paravirtualization rather than full virtualization, which was conventionally considered impossible on the i386.
(QSOE/L does use seL4 as one of its possible kernels. But I guess you also haven't noticed this, because, perhaps, you don't care.)
I work in embedded software and I have some insight on why the reality often looks very different from this:
Software "cost" works differently. In a startup environment, you can spread the fixed costs for software development on thousands of installs (or even more). Automation software is very different, and solutions are often bespoke; even if you're building and selling machines, the numbers will be much lower than for consumer stuff.
This means that fixed costs for software development matter much more, and that hard developer productivity (as in: how many factories can your PLC programmers automate per year) is much more important. Vendoring dependencies is much more costly, splitting your codebase over multiple subsystems is less desirable (=> overhead for general development, update, configuration management, redundant subcomponents, slower iteration), heterogenous systems are very undesirable (because specialized employees are more expensive to manage and less flexible).
This is why much of the industry is so willing to shell out for "overpriced" PLC controllers (when freely programmable MCUs can be had for cents), proprietary frameworks and what you might perceive as obsolete garbage tooling for HMI/cloud integration: All those things help to build solutions that are "good enough" with less programmers, less training, less specialization and thus, crucially, less software-fixed-costs (that you wouldn't be able to recoup).
One other thing: software being formally correct vs. reliable/robust is much more orthogonal in practice than you might assume, and industry typically cares more about the latter. My perspective is that formalizing/certifying software is (overly) concerned with eliminating lower risk holdouts (think: proving latency bounds on memory allocation or somesuch), while "robustifying" software looks at "actual highest risk" parts first (sanity checking requirements/specifications, avoiding pitfalls for users when configuring/operating your system, fixing false positives).
8k RAM, 64k ROM, compressed RISC-V insn set.
Edit: Apparently it's a QingKe RISC-V with about 130 Coremark.
An Atmel AVR has a Coremark of 7.5 so these little $2.50 MCUs are about 5 times (!) as fast as the 8-bit AVR.