I find well prompted AI makes nice looking websites. Are they better than some designer could do?
Probably not, are they better than a guy that hasn't done a minute of fronted work in 20+ years in the industry? Probably.
Does it sound like a typical LLM-generated text? In many areas, it does. But why would I care? This is not expected to be a piece of literary art. Equally, the pictures illustrating it are not artistic masterpieces, and aren't expected to be. And even the letters in the text are not carefully handwritten by a human but machine-generated.
Get used to it, and get past it. It's not worth the attention.
"RVA23 silicon has arrived. The industrial computer built on it has not."
"Until recently it lacked what industrial systems need. That has changed."
So tiresome...
"An industrial computer has to do more: survive the control cabinet, talk to the field, and stay available for a decade or longer."
Do people think this sounds good?
And what if it does, but you and I are just tired from seeing it everywhere?
Then people like you and me, who read AI prose all day long, went and read the book, and we all immediately knew the book was, at the very least, heavily AI-generated. For a few tragicomic months, people were in denial, going on TV to defend his book and defiantly proclaiming that "a machine could not have written this", only exposing their insulated ignorance.
Hence the question: do we dislike this style because we read it all day long? Was it originally pleasing (it probably arose out of RLHF), but then used excessively? All while famous French writers and critics had nothing but the highest praise for the book...
Note: after the author could not prove authorship, his editor officially declared that he had, indeed, used AI to write the book [0].
[0] https://www.msn.com/en-us/technology/artificial-intelligence...
> EPI demonstrated several results just after the Phase 2 end in 2026.[11] SiPearl demonstrated the Rhea1 chip running a complete HPC software stack. The system booted on a test board, with a standard Linux distribution running with high-speed HBM memories and their associated hardware performance monitoring counters. It successfully executed the HPL and STREAM benchmarks, demonstrating the readiness of the complete Rhea1 hardware and software ecosystem for HPC workloads to power Exascale systems. Rhea1 features 80 arm® Neoverse V1 cores, more than 61 billion transistors (7.8 billion equivalent gates), built-in High Bandwidth Memory, with 4 stacks of HBM, 4 DDR5 interfaces supporting 2 DIMMs Per Channel, and 104 lanes of PCIe Gen5 interface: up to 6 x 16 lanes + 2 x 4 lanes. Rhea1 was selected for implementation in Jupiter, Europe’s first exascale supercomputer. The next version, Rhea2, was selected for implementation in Alice Recoque, the second European exascale supercomputer.
And then more paragraphs how work was taken forward..
> A machine that runs for 15 years needs software that can be maintained for 15 years.
I don't quite understand. Has this been a problem for industrial machines? Can't they already run for 30 years and more?
What exactly is this initiative looking to fix and improve? Besides of the basic idea of FOSS being good, and whatever.
The industry can barely keep an npm update from breaking the world now.. and that’s build tools and environments and so it’s independent of “we use stable languages”
Now add the possibility of political sanctions on ISA licensing and you have -
Hardware that’s fails quicker and may not be available to buy, software that barely builds months later, and a world where the US president can sanction entities at will if they don’t comply…
Yeah, open source isn’t all that’s required
I know uptimes were a flex back in the day but now a long uptime is an indicator that maybe you’re treating your machine as a pet instead of cattle.
There are many CPU architectures, even some that became quite popular, that have gone extinct. Some lasted less than 30 years in total.
x86 has lasted decades but, as it relies on only one to two companies, it is not guaranteed to do so.
But the biggest risk going forward is geopolitical. You may completely lose access to a technology even if it continues to be available elsewhere. If you are in Europe, technology from the US in particular may be a concern. I think that is the main motivation for this project.
So.. it's a bit funny to read there is an European Initiative... to promote Chinese computer appliances.
In times when fridges with Chinese electronics that are phoning home become more hack-able today than ever..
> Hardware
> RVA23 SoC with IOMMU
> SpacemiT K3
> 8× X100 cores, hypervisor extension, IOMMU
And no, I’m not American, nor I think Americans can be trusted more these days in the race of global surveillance programs.
But having open, patent free standards is noble. I love the idea.
Hopefully they praise the initiative. ;-)
In fact several countries do support Huawei store in addition to Apple and Google ones, including having the usual bank apps available there.
As others ITT have pointed out, this is a vibecoded site from one guy lol
We're probably getting to a point where AIs will just generate optimized binaries directly, so I'd rather have them generate them in a machine language that is human friendly. RISC-V being designed by humans with a focus on simplicity is close to the best we could wish for.
- RISC-V is "open", except in none of the ways that matter to me. What I want is a well-documented platform able to run fully open software. RISC-V does not inherently provide the former and the latter has nothing to do with ISA. If anything, manufacturers seem to take GPL-licensed software, modify it then _not_ publish the modified source code.
- Lately I've started to care a lot more about minimal software stacks that are easier to prove to work as intended. Part of that includes generating raw machine code and I hate the terrible immediate encoding especially for C instructions. Compare with x86-64 where you can just write the constant straight to memory. x86-64 would actually be a nice ISA if it were not for prefixes + lack of explicit instruction length.
- It seems there is an excessive focus on hardware "simplicity" (for very small cores) while neglecting simplicity on the software side. I would benefit greatly from automatic bounds checks, checked arithmetic... and many "safe" languages would too. This "simplicity" apparently is also why the immediate encoding is so ridiculous.
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.
Even though it's Japanese-owned most of their R&D still takes place in England.
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.
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".
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.
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.
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).
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.)
8k RAM, 64k ROM, compressed RISC-V insn set.
Edit: Apparently it's a QingKe RISC-V with about 130 Coremark.
So European, right?
I'm immediately thinking: there's got to be some sort of sovereign aspect to the initiative ... right?
I mean, if there's one place you want a silicon stack that wasn't manufactured in China, it's most definitely in the guts of your industrial infrastructure (assuming you still have one, yes, point taken).
But, if you look at the "The silicon is here." section and dig a little:
> "Shenzhen MilkV Technology Co., Ltd" [1]
Wake me up when someone can actually build a computer from scratch with EU-made parts.
What would it take to make this possible, if not completely then at least move in the right direction?
Aside from re-thinking computer manufacturing from the ground up.. RISC-V, or something like it, seems like the right idea as part of the solution.
That may be a high bar. Would all countries in the world collaborating, except for China, Taiwan and South Korea, even be able to do this?
Good luck starting a fab in Europe... Maybe "hobby sized" attached to some university. But certainly not anything that can make parts in volume.
It used to be the case China competed mainly on price thanks to low labour costs. These days they still compete on price but because of supply chain integration.
If like me you dabble in hobby grade electronics you know how parts and services availability looks like here in Europe. We have only one component distributor now that UK left the EU. And even them (Mouser) if you try to order any advanced components that run at high frequencies etc tend to ship stuff from US warehouses.
Dont get me wrong. I'm still amazed they can get an order to me from US to Poland for $15 and 3-4 days time. But if I lived in China I could walk to one of bajillion physical suppliers and have every component made available same day. If I don't want to overspend on my prototype I could buy used parts without having to wait 3 weeks for delivery.
Then we have PCB manufacturing and assembly. It makes zero financial sense to use these services domestically. I'd love to support local EU industry, but I'm not spending 10x the cost for the privilege.
Great idea, but if the important EU players aren't there, what's the point?
About ERICI
ERICI is a non-commercial initiative in its founding phase. It is not yet a legal entity, sells nothing and charges no fees.
The random dude is not looking for funding.
it means not intended with the purpose to make money from it
founding doesn't always imply. a startup-like process of selling stock (or similar) to investors which in turn want some profit from it long term
it can also mean looking for donations to found a project, i.e. cover it's costs
but also not every non-commercial project ends like that, most do not
and even in case of OpenAI especially the larger donators could have sued, and had a decent chance of success. They just didn't (at least not until years later when the legal time frame to sue had been long passed).
naturally when you plan to make a large donation you should
- look at the exact used legal form
- if there are legally binding self imposed limitations
- if they are reasonably well formulated
- decide what you actually want from this donation, and when you think there was a breach of donation use-case binding (probably not the right English term)
- lastly vet the people in leading executive positions
in the end large donations are always a bit of an gamble, but what isn't
The telling thing is in benchmarks the Loongson outperforms them, by a lot.
It's a far better measure than "despite all the years of unfulfilled hype and promises we'll absolutely have a smorgasbord of performant RISC-V cores Real Soon Now". Single core performance down in the Intel Core range? Needs 96 cores to even be competitive on a handful of benchmarks that don't equal a modern users compute needs? The competition isn't sitting on their hands, and RISC-V hasn't delivered the performance it's fanbois have told us is 'inevitable'. Loongson has at least managed late-2010s levels of performance.
Maybe RISC-V will completely take over the embedded market. That's not a bad gig. High volume, tho slim margins, lot's of niches for lots of innovation (want to continue to go crazy with ISA extension? Not a big deal in the embedded world). But they're still selling billions of 8051s, ARM is ubiquitous but even they didn't take over that world, and I know how I would lay my bets there, too.
I'd rather look at all the data available. If you want to compare to Loongson, you have to include the 20 years head start that this company has in developing microarchitectures, a big part of which can be transferred to the Loongson designs. And factor in the strategic investments in China who doesn't want to depend on ARM and x86, while in the Western world people were happy with x86 and ARM and big money is mostly flowing to AI chips, where RISC-V is successful.
Then there is Xiangshan Kunminghu... For some reason the most powerful open source CPU is RISC-V. Chinese and not Loongson.
There is no data to suggest RISCV can ever be competitive in the large core space. The longer this absence goes on (now approaching 15 years) the more evidence there is that it is structurally incapable of competitive implementations.
If you wanted to create a project to distract a whole generation of computer architects from getting anywhere this is exactly what it would look like.
Now consider that RVA23 was ratified only two years ago, and the server platform specification 6 months ago! This bigger standardized base is important for larger cores, and of course these cores take longer to develop than the small ones like Western Digital's.
I share the frustration with the lack of competitive application cores (looks like extending an ISA through open and collaborative processes takes more time than in a company). But is it not a bit early to judge the ISA's potential based on the chips on shelves today?
Anyway large RISC-V cores do exist. The SiFive P870-D is a 6-wide core you can buy now with the BigSky SF-2U870. Ascalon (8-wide) has been available as IP for a while (though I will grant you I don't know how competitive it will be when it's finally taped out).
Oh and the Arbel by NextSilicon (10-wide, 480-entry ROB) has been taped out. Is that large enough?
Hopes and prayers are not a basis to judge hardware. No one will be sad about a 3rd option performant ISA, but call us when something competitive ships.
There is also no data to suggest otherwise.
At some point we have to accept it isn’t happening.
Their original slides had Ascalon silicon in 2024 at 3ish GHz, now the devboard is supposed to be next year at 1.38GHz on an older node and it still has not taped out yet as of last month.
One of the lessons for whatever follows RISC V is having rivals (commercial and academic) compete during spec writing before any competitive hardware is produced will doom you all to failure as everyone tries to lock everyone else into their games ahead of actually winning as a team.
I hope that leading European industrial computer manufacturers notice the initiative and join -- or at least start evaluating the possibility to use RVA23 SoCs in their devices. Yes, currently only Chinese vendors can provide such chips, but the world is changing fast.
What's missing here is the "made in Europe" bit. Currently (very few exceptions), RISC-V SoCs are designed by Chinese companies, maybe fabricated in Taiwan, and boards they go on manufactured in China.
Imho that is what Europe needs to address. With EU-made boards available, the software side is the easy part.
There is some European CPU initiative. Sounds great but where are the boards?
Easy. In fact, the emphasis will be on RVA23 _and_ on working IOMMU hardware. This is needed for hardware resource isolation between operating systems running on the hypervisor.
RVA23 is mandatory for Ubuntu, for example. So the requirement is not new at all.
Another question for silicon experts : on PCs, there is usually a NOR flash that hosts the BIOS/UEFI. On ARM/RISCV boards, u-boot and DTB are often stored on the same media as the OS, which means that a fresh install requires to have access to the proper board-specific u-boot and DTB (which may be difficult when reviving an old board) => is there technically a way to colocate some kind of flash memory on the same die as the CPU to store this HFI+DTB rom, that would persist even if the main NAND/emmc/SSD hosting the OS is wiped out, and would also avoid the cost of an external NOR flash ?
Why "could/would"? It is part of the firmware, now. HFI BIOS is U-Boot + VideoBIOS + Set-Up program. Its job is to initialize your hardware (video controller included) and start your boot loader (EFI program), just like in a PC.
> ... even if the main NAND/emmc/SSD hosting the OS is wiped out
There is [almost] always the possibility of recovery. I have three RISC-V systems, and each of them cannot be "bricked": * X-Modem for VF2; * SD-card boot for Unmatched; * fastboot (Android) protocol for the K3
> on PCs, there is usually a NOR flash that hosts the BIOS/UEFI.
Same on Unmatched, for example: you may store HFI BIOS in NOR (boots very fast!), or on your SD card (boots slow, only 81 KB/sec). What to boot from is selected by DIP switches. Similar mechanism on VF2 too.
Or what exactly was your question about?
Is this supposed to be the hardware to replace a PLC?
Or just another small form factor PC for industry, but happens to be RISC?
We are financing private shareholders with public money.
As for the hardware: please stop endorsing devicetree nonsense and demand discoverable hardware. Enough already with the random per-SoC kernel madness. Did Risc-v learn nothing? MAKE AN ACTUAL PLATFORM with standards for booting and hardware discoverability. Make hardware standard and stop rearranging the register furniture between versions and manufactures.
"Our stuff is not the fastest, not the cheapest, not the most power-efficient...but we're within 50% of the price of the ones that are...and ours come with sufficient documentation (not under NDA!) for anyone to write a driver for!"