before they betrayed their donators and mission, yes
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
Author here. Happy to answer technical questions: about HFI BIOS, partitioning hypervisor (gRouvr), QSOE RTOS.
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.
Why the emphasis on RVA23? Since when are vector instructions a minimal necessity? Plain RV64GC is mooore than powerful enough for industrial/machine controllers & the like - assuming a standard sw/hw platform.
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.
My guess: The goal is EU industrial infrastructure . In that context, a somewhat more expensive cpu doesn't matter much, but if the same chip can cover more use cases, it ensures more volume and better protection against obsolescence.
I just had a look at the HFI paper, and I want to say that I have been waiting for this for a long time (both for ARM and RISCV), so I hope this becomes successful !
One question : in your mind, the device tree blob could/would be embedded in the same package as this HFI firmware (so that there is no longer a need to install the DTB separately on the emmc, and even a 10-year old board with a fresh SSD/flash could boot with a generic Linux kernel) ? Will you also consider to have an UI for the user to manage secure boot keys (similar to mokutil) in this firmware ?
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 ?
> ... the device tree blob could/would be embedded in the same package as this HFI firmware
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.
This is just a webpage some individual put up, right? I mean as far as I can see there's no institute, no company, no government behind this. Just one RISC-V enthusiast on the contact page.
Compared to x86, which is wholly owned by an American duopoly and needs licensing to produce legally, boosting RISC-V is a major step towards chip independence for Europe. With the current state of the US it almost seems a necessity. The only downside here is that it didn't happen sooner.
While ARM Holdings is based in Cambridge, England, it is majority owned by SoftBank Group which is a Japanese investment conglomerate.
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.
This statement seems to be factually untrue. Mashayoshi Son owns 32-33% of Softbank and then the investors are like the Japanese Master Trust bank etc. Saudi Arabia is not even in top 10 of the investors list.
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.
Others have already talked about the Japanese and Suadis.
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.
It is if you define the UK being in Europe (the continent). It isn't part of the EU as of today, although there's a good chance it will be again in the future.
Even though it's Japanese-owned most of their R&D still takes place in England.
You don't need to define the UK being in Europe. UK is and forever will be in Europe, full stop.
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.
Even if Intel licensed x86 no one in Europe would want to make them. Unless they're guaranteed a monopoly there will be no takers. European companies and conglomerates are extremely lazy and risk averse.
Arm would be a better choice the problem in Europe isn’t tech the problem is mainly a lack of will, I hope someone will pick up the gauntlet. And I don’t mean the free pizza and beer approach ie Linux.
Such development boards are a completeley different thing compared to RVA23-profile RISC-V CPUs.
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...
You aren't going to be running ERICI's Linux on a Cortex-M0-like RV32E, no, but I'd think that most industrial equipment has a lot more need for RV32E or similar than it does for Linux.
You can certainly do a lot even with low end CPUs in automation (and they are certainly used a lot there).
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).
This is certainly true, but I think that some of it is a question of industrial designs lagging behind the state of the art in computery stuff.
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.
> ERICI's plan to run Linux under a real-time hypervisor...
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.
As I said, it's been working since the 01990s. Barabanov's original research on what would become RT-Linux and Yodaiken's paper about it were 01996. L⁴Linux was 01997. Heck, MERT was 01975. And, I'm sorry, but I'm not going to watch your demonstration video.
Excuse me, but what Barabanov, Yodaiken and all the stuff you mentioned have to do with the subject?
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.
What "that approach"? In the scope of the initiative, we are talking about full isolation of operating systems (which is possible with the hypervisor). I still don't understand why are you offering me to read about L4 and RT-Linux.
(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.)
The approach you were asking about: using a hypervisor to drive real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation. I was answering your question as to which hypervisor was used. Sorry that wasn't clear.
You do have valid points with the "better to avoid mixed criticality when possible" and "isolate the most latency sensitive compontents on dedicated hardware".
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).
That makes a lot of sense, and I greatly appreciate you sharing your experience. It helps me to understand why the industrial automation world looks the way it does.
These implement 16-register cut down RISC-V RV32EC_Zmmul instruction set. It's an interesting choice. I wonder if they can run Coremark or Dhrystone so one can get an impression of their performance at 48MHz.
8k RAM, 64k ROM, compressed RISC-V insn set.
Edit: Apparently it's a QingKe RISC-V with about 130 Coremark.
They shouldn't have any trouble running Dhrystone, either. RV32EC_Zmmul is closely comparable to the Thumb-1 ISA implemented by Cortex-M0, but I'd expect a little lower DMIPS/MHz than a Cortex-M0.
These are more than sufficient for simple control applications. I'm just wondering if I can run a small GUI on it driving an OLED display. That's what I'm gonna find out.
I'm confident you won't have any trouble at all doing that. 8KB RAM doesn't sound like much, but it's plenty fast enough to make up for it unless your OLED display is huge and your graphics are very complicated. It's roughly 50 times as fast as the original Macintosh, but with one sixteenth of the RAM, a combination that you may find favors IMGUI approaches. Popular OLED display controllers like the SSD1306BZ have their own framebuffers onboard, so you don't have to regenerate the pixels dozens of times a second to refresh the display the way you do for VGA or NTSC.
CPEU is coming! I love RISC-V and have been following its progress for so long. I hope it gets more and more adoption in the world for desktops and servers. Its already massive in MCU's but we need it everywhere. Open ISA is the best ISA
Google says it's "CPEU most commonly stands for Continuing Professional Education Unit, a credit system used by dietitians and nutrition professionals.". Yeah, not sure how that is related to RISC-V. Perhaps we should eat RISC-V powered nanobots to, uh, future sci-fi something?
No to a fixed tech stack. And no to this dual kernel nonsense. As someone who is exhausted with all the terrible ideas in industrial automation, I am not interested.
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.
As much as I think ACPI and uEFI are messy kludges that should be taken out back and shot twice, I'd take them any day over yet another vendor kernel with undocumented Linux drivers no one will give a damn about in few years. Even with AI you're still SOL if you can't get docs to write reliable drivers.
I keep wondering if there's a market for semiconductor products like this:
"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!"
I know someone building a dual core RISC-V SoC that is along similar lines. He has a prototype working in an FPGA and planning to get actual silicon fabbed once he gets it to a satisfactory state. The idea is to be a simple no-frills SoC with enough hardware to run a desktop class OS, have a booting and hardware discovery standard, and well documented to make OS porting simple. He does a lot of low level systems work, network hardware, and security expert. I'll have to poke him at some point to see if he's still working on it.
What sort of IP block would one use for a GPU/display controller? AFAICT, all of those are covered by some licensing deal that probably comes with an NDA...
Agree, all of them in same industry mostly have similar posters. My eyes keep ignoring them and focus on service quality of barbershop and restaurants.
Is it content-free? I don't think so. Is it hard to read? I don't think so either. Is it incorrect? I hope it's not %))
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.
I've been wondering the same since the scandal that hit the French literary world a couple of months ago [0]. Until a journalist (anonymously) accused the author of having written his novel with AI, literary critics and fellow writers were fawning all over the book, and the book was set to grab most of this year's literary prizes.
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].
Why a SpaceMiT and not a Cortus, Codasip, or anything European? (I think there are also other companies also trying to sell their IP that could be more innovative)
The initiative originates in Europe, thus it's European. It aims at solving very concrete problems, particularly about running RTOSes used in industrial computing, and efficient resource partitioning. It invites industrial companies to join.
They can run, but if one of the computer-related parts breaks down your only choice is scrounging eBay for replacement parts because (as an example) the software is proprietary and it runs on a weird MCA card with really precise timing and strong anti-piracy measures.
In the 90s and early 2000s server uptime might be counted in multiple years and extremes in the decades
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…
I do remember a Freebsd 2.2 server, that after it's setup in 98, reached 800 days of uptime without any kernel upgrade, but the main reason for that, we were too afraid to do an upgrade, let alone a reboot, because if the server hadn't started, getting to it physically with a new boot CD, would have been a big issue. And that was the single server that the company had at that time, for a long time :)
You need to maintain both the software and hardware. It is not just that time an installation may last but the time the ecosystem stays viable.
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.
It's interesting to see that both "Firefly AIBOX-K3" and "Milk-V Jupiter2" use cores from SpacemiT, a Chinese company. It's even listed as the "Reference stack" that is "Defined together, verified together"!
That’s the question I’m asking. Where is Siemens and Bosch these days… all I see is China is playing to get through EU compliance to ensure more phoning home from
Industry 4.0 appliances. Meh.
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.
I think you misunderstood. I’m happy to buy RISC-V computer but from a vendor that I can trust I don’t need to place in DMZ or I see funny traffic on the routers
> European RISC-V Industrial Computing Initiative
> Based in Europe, open worldwide
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:
The eProcessor TC1 is a RISC-V CPU with cores designed by Cortus (Mauguio, France) and fabricated in GlobalFoundries Dresden fab (22FDX). But that's a public initiative, not a private one.
I don't think so. The best you could find I think is some router with NXP or ST chips, but following the manufacturer you may or may not be able to do whatever you want with it.
Sadly we Europeans have taken our industry behind a shed and we put it out of its misery of having to pay exorbitant electricity prices and deal with our environmental regulations.
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.
It is supposed to be a sturdy industrial computer with a RVA23-capable SoC inside, capable of running two or more OSes simultaneously. At least one of those OSes must be a hard-real-time OS, used e.g. in control or robot tasks.
It makes sense for the Chinese to make Loongson be performant, its an ISA they fully control and only have to do with domestic Loongson standard body politics instead of having to deal with global Politics in the RISC-V standard bodies.
At this point I've stopped considering TT as a serious company.
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.
So it's late to deliver hugely complex cores according to some optimistic timeline? That's a weird measure of success. The ISA is successful in the low end and is seeing huge investment on large cores, though most of the promising companies are now focusing on AI or getting bought by large players like Qualcomm. So yeah it might take a while still before we see competitive high end consumer cores. I would still put my money on RISC-V rather than Loongson for the long term but we'll see.
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.
That's using he most enthusiastic fanboy predictions as the baseline by which to judge success, not a recipe for reaching the right conclusions.
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.
RISC-V was a young, purely academic project in 2011. The pivot to industry came in 2015. This was followed by announcements by companies that they were shifting to RISC-V, but guess what, it takes time. For example Western Digital announced in 2017 but shipped only in 2021.
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?
But is it not a bit early to judge the ISA's potential based on the chips on shelves today?
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.
Is it though? AI can rapidly push through an objectively better standard if a group becomes motivated to make one. There’s no need to marry ourselves permanently to a mediocre design like we did with C interop.
By some coincidence RISC-V became successful just before/while AI took off, and I'm glad it did. The design is pretty good for low end cores and probably good enough for high end cores, so there's a chance it will become one of the dominant ISAs in the mid-term.
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.
This cultish nonsense is one reason I've stopped taking RISC-V seriously for desktop/server usage. There are other reasons too:
- 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.
Not an expert, but reading the article you linked it seems it was quite stressful?
> 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..
This seems to be run by a random dude looking for funding:
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.
(https://erici.eu/impressum.html)
Have you noticed the words "non-commercial" at the bottom of the page?
The random dude is not looking for funding.
non-commercial doesn't mean not looking for funding (neither does it mean 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
Like openai
before they betrayed their donators and mission, yes
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
You don't accomplish anything like this without funding. This is computing fanfic, at best.
Did you notice the words "funding phase"?
founding != funding
No, I did not. Are you looking at some other page?
Author here. Happy to answer technical questions: about HFI BIOS, partitioning hypervisor (gRouvr), QSOE RTOS.
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.
Why the emphasis on RVA23? Since when are vector instructions a minimal necessity? Plain RV64GC is mooore than powerful enough for industrial/machine controllers & the like - assuming a standard sw/hw platform.
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?
> Why the emphasis on RVA23?
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.
My guess: The goal is EU industrial infrastructure . In that context, a somewhat more expensive cpu doesn't matter much, but if the same chip can cover more use cases, it ensures more volume and better protection against obsolescence.
I just had a look at the HFI paper, and I want to say that I have been waiting for this for a long time (both for ARM and RISCV), so I hope this becomes successful ! One question : in your mind, the device tree blob could/would be embedded in the same package as this HFI firmware (so that there is no longer a need to install the DTB separately on the emmc, and even a 10-year old board with a fresh SSD/flash could boot with a generic Linux kernel) ? Will you also consider to have an UI for the user to manage secure boot keys (similar to mokutil) in this firmware ?
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 ?
> ... the device tree blob could/would be embedded in the same package as this HFI firmware
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.
[dead]
This is just a webpage some individual put up, right? I mean as far as I can see there's no institute, no company, no government behind this. Just one RISC-V enthusiast on the contact page.
Step 1 in lean startup: quickest possible experiment to see if there is potential interest.
It also seems AI generated?
Great idea, but if the important EU players aren't there, what's the point?
Is this something more than a flag-waiving exercise? Who's actually manufacturing and selling these "European" CPUs?
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."
[1]: https://www.aliexpress.com/item/1005011967676963.html
Compared to x86, which is wholly owned by an American duopoly and needs licensing to produce legally, boosting RISC-V is a major step towards chip independence for Europe. With the current state of the US it almost seems a necessity. The only downside here is that it didn't happen sooner.
What about ARM? Isn't it also European?
While ARM Holdings is based in Cambridge, England, it is majority owned by SoftBank Group which is a Japanese investment conglomerate.
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.
SoftBank is technically hedquartered in Japan but it is mostly owned by Saudis.
This statement seems to be factually untrue. Mashayoshi Son owns 32-33% of Softbank and then the investors are like the Japanese Master Trust bank etc. Saudi Arabia is not even in top 10 of the investors list.
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.
Others have already talked about the Japanese and Suadis.
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.
It was British until a short-sighted company sold it to the Japanese, the EU at the time was also looking in the other direction too.
It is if you define the UK being in Europe (the continent). It isn't part of the EU as of today, although there's a good chance it will be again in the future.
Even though it's Japanese-owned most of their R&D still takes place in England.
You don't need to define the UK being in Europe. UK is and forever will be in Europe, full stop.
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".
ARM is still IP locked like x86_64.
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.
Even if Intel licensed x86 no one in Europe would want to make them. Unless they're guaranteed a monopoly there will be no takers. European companies and conglomerates are extremely lazy and risk averse.
All they want is to suck on the government's tit.
Arm would be a better choice the problem in Europe isn’t tech the problem is mainly a lack of will, I hope someone will pick up the gauntlet. And I don’t mean the free pizza and beer approach ie Linux.
ARM is a markedly worse choice than RISC-V for Europe. It's expensive to license, relatively inflexible, and not majority-owned by European firms.
There is no tangible advantage to Europe adopting the ARM ISA for domestic chips at any scale.
Such development boards are a completeley different thing compared to RVA23-profile RISC-V CPUs.
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...
You aren't going to be running ERICI's Linux on a Cortex-M0-like RV32E, no, but I'd think that most industrial equipment has a lot more need for RV32E or similar than it does for Linux.
You can certainly do a lot even with low end CPUs in automation (and they are certainly used a lot there).
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:
https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/
This is certainly true, but I think that some of it is a question of industrial designs lagging behind the state of the art in computery stuff.
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.
> ERICI's plan to run Linux under a real-time hypervisor...
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.
As I said, it's been working since the 01990s. Barabanov's original research on what would become RT-Linux and Yodaiken's paper about it were 01996. L⁴Linux was 01997. Heck, MERT was 01975. And, I'm sorry, but I'm not going to watch your demonstration video.
Excuse me, but what Barabanov, Yodaiken and all the stuff you mentioned have to do with the subject?
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?
L4: https://pdos.csail.mit.edu/6.828/2026/readings/microkernel.p... and RTLinux: https://web.archive.org/web/19970307183643/https://luz.cs.nm...
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.
What "that approach"? In the scope of the initiative, we are talking about full isolation of operating systems (which is possible with the hypervisor). I still don't understand why are you offering me to read about L4 and RT-Linux.
(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.)
The approach you were asking about: using a hypervisor to drive real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation. I was answering your question as to which hypervisor was used. Sorry that wasn't clear.
You do have valid points with the "better to avoid mixed criticality when possible" and "isolate the most latency sensitive compontents on dedicated hardware".
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).
That makes a lot of sense, and I greatly appreciate you sharing your experience. It helps me to understand why the industrial automation world looks the way it does.
These implement 16-register cut down RISC-V RV32EC_Zmmul instruction set. It's an interesting choice. I wonder if they can run Coremark or Dhrystone so one can get an impression of their performance at 48MHz.
8k RAM, 64k ROM, compressed RISC-V insn set.
Edit: Apparently it's a QingKe RISC-V with about 130 Coremark.
The Coremark website claims the CH32X033F8P7 has a Coremark of 41.6.
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.
They shouldn't have any trouble running Dhrystone, either. RV32EC_Zmmul is closely comparable to the Thumb-1 ISA implemented by Cortex-M0, but I'd expect a little lower DMIPS/MHz than a Cortex-M0.
These are more than sufficient for simple control applications. I'm just wondering if I can run a small GUI on it driving an OLED display. That's what I'm gonna find out.
I'm confident you won't have any trouble at all doing that. 8KB RAM doesn't sound like much, but it's plenty fast enough to make up for it unless your OLED display is huge and your graphics are very complicated. It's roughly 50 times as fast as the original Macintosh, but with one sixteenth of the RAM, a combination that you may find favors IMGUI approaches. Popular OLED display controllers like the SSD1306BZ have their own framebuffers onboard, so you don't have to regenerate the pixels dozens of times a second to refresh the display the way you do for VGA or NTSC.
Who actually builds these manufacturing facilities? Is America just a financial services empire now? Two can play this game.
Neat. This seems like exactly the sort of thing Europe should be pushing
CPEU is coming! I love RISC-V and have been following its progress for so long. I hope it gets more and more adoption in the world for desktops and servers. Its already massive in MCU's but we need it everywhere. Open ISA is the best ISA
What is CPEU? I don't see that acronym on the page.
Probably a nice merge of CPU and EU
Just something I made up when promoting that EU should make CPU's . So its exactly what you say a merge of CPU and EU :-)
Ah okay, I was thinking something like Central Processing Embedded Units.
Google says it's "CPEU most commonly stands for Continuing Professional Education Unit, a credit system used by dietitians and nutrition professionals.". Yeah, not sure how that is related to RISC-V. Perhaps we should eat RISC-V powered nanobots to, uh, future sci-fi something?
Its just a merge of CPU and EU https://x.com/per_arneng/status/2116461926859346020?a=T6N47u...
No to a fixed tech stack. And no to this dual kernel nonsense. As someone who is exhausted with all the terrible ideas in industrial automation, I am not interested.
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.
I cannot believe that nobody is addressing this. CHRP and ARC, for instance, are decades-old examples.
As much as I think ACPI and uEFI are messy kludges that should be taken out back and shot twice, I'd take them any day over yet another vendor kernel with undocumented Linux drivers no one will give a damn about in few years. Even with AI you're still SOL if you can't get docs to write reliable drivers.
I keep wondering if there's a market for semiconductor products like this:
"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!"
I know someone building a dual core RISC-V SoC that is along similar lines. He has a prototype working in an FPGA and planning to get actual silicon fabbed once he gets it to a satisfactory state. The idea is to be a simple no-frills SoC with enough hardware to run a desktop class OS, have a booting and hardware discovery standard, and well documented to make OS porting simple. He does a lot of low level systems work, network hardware, and security expert. I'll have to poke him at some point to see if he's still working on it.
What sort of IP block would one use for a GPU/display controller? AFAICT, all of those are covered by some licensing deal that probably comes with an NDA...
RISC architecture's going to change everything.
RISC architecture is about as old as x86
It did change everything, didn't it?
Yeah, RISC is good.
Vibe coded site and copy
i am tired of seeing same patterns and designs on Internet. It is kind of frustration
And also real life.. there's no reason why a laundromat, barbershop and Japanese restaurant have posters that looks similar
Agree, all of them in same industry mostly have similar posters. My eyes keep ignoring them and focus on service quality of barbershop and restaurants.
You know, not everyone has taste etc to make visually appealing websites. Would you rather read extremely basic text ones?
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.
> Would you rather read extremely basic text ones?
Yes, very much so.
WordPress or something else. Site builders have existed for decades.
By now I just want everything just to be black on white or white on black text and nothing else. Or better, just an md file.
Yet it will be worse when we aren't able to detect it as easily
what exactly will be worse once no qualitative difference is detectible?
No difference in presentation doesn't make presented slop content less sloppy.
Is it content-free? I don't think so. Is it hard to read? I don't think so either. Is it incorrect? I hope it's not %))
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.
Ok, buddy.
Indeed:
"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...
"The silicon is here. The industrial computer isn't yet."
"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?
I've been wondering the same since the scandal that hit the French literary world a couple of months ago [0]. Until a journalist (anonymously) accused the author of having written his novel with AI, literary critics and fellow writers were fawning all over the book, and the book was set to grab most of this year's literary prizes.
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...
[dead]
I would have loved to see a clause in the EU CHIPS Act to follow the principle of public money = public code for hardware.
We are financing private shareholders with public money.
Why a SpaceMiT and not a Cortus, Codasip, or anything European? (I think there are also other companies also trying to sell their IP that could be more innovative)
Would be happy to port the stack to a RVA23-capable system from Cortus, Codasip or any other European firm! Once the board is available, of course.
Cool, I also hope one gets available too, I would love seeing some competition.
Very sad that the silicon itself is not made in EU.
So one person creates a (fantasy ?) website and it gets on the 1st page of HN being mistaken for an European initiative?
The initiative originates in Europe, thus it's European. It aims at solving very concrete problems, particularly about running RTOSes used in industrial computing, and efficient resource partitioning. It invites industrial companies to join.
Or what exactly was your question about?
> A machine expected to run for 15 years should not depend on one company's roadmap, or one government's decisions."
> 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.
They can run, but if one of the computer-related parts breaks down your only choice is scrounging eBay for replacement parts because (as an example) the software is proprietary and it runs on a weird MCA card with really precise timing and strong anti-piracy measures.
In the 90s and early 2000s server uptime might be counted in multiple years and extremes in the decades
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 do remember a Freebsd 2.2 server, that after it's setup in 98, reached 800 days of uptime without any kernel upgrade, but the main reason for that, we were too afraid to do an upgrade, let alone a reboot, because if the server hadn't started, getting to it physically with a new boot CD, would have been a big issue. And that was the single server that the company had at that time, for a long time :)
> In the 90s and early 2000s server uptime might be counted in multiple years and extremes in the decades
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.
Industrial machines are pets. You do not have K8S clusters of CNC controllers or quality control systems.
You need to maintain both the software and hardware. It is not just that time an installation may last but the time the ecosystem stays viable.
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.
I like RISC-V as a concept but still only Chinese are focused on manufacturing those today.
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..
That goes to show how low the things have gone with the US administration.
In fact several countries do support Huawei store in addition to Apple and Google ones, including having the usual bank apps available there.
https://consumer.huawei.com/pt/offer
https://consumer.huawei.com/pt/campanhas/appgallery
> That goes to show how low the things have gone with the US administration.
As others ITT have pointed out, this is a vibecoded site from one guy lol
https://news.ycombinator.com/item?id=50349860
Soon, there will be vibe fabricated chips in our computers and machines. Can't wait for coming hardware revolution.
Fair enough, however being vibe coded is all the rage nowadays.
It's interesting to see that both "Firefly AIBOX-K3" and "Milk-V Jupiter2" use cores from SpacemiT, a Chinese company. It's even listed as the "Reference stack" that is "Defined together, verified together"!
> Hardware
> RVA23 SoC with IOMMU
> SpacemiT K3
> 8× X100 cores, hypervisor extension, IOMMU
That’s the question I’m asking. Where is Siemens and Bosch these days… all I see is China is playing to get through EU compliance to ensure more phoning home from Industry 4.0 appliances. Meh.
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.
> Where is Siemens and Bosch these days…
Hopefully they praise the initiative. ;-)
There's glorious open hardware rpi pico 2.
I think you misunderstood. I’m happy to buy RISC-V computer but from a vendor that I can trust I don’t need to place in DMZ or I see funny traffic on the routers
I don't understand. You will trust it only if you make it yourself?
Nope, but I hope EU would be capable not only to create regulations but being able to actually manufacture and produce stuff.
And the chips will be manufactured in China. Truly a genius move.
> European RISC-V Industrial Computing Initiative > Based in Europe, open worldwide
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]
[1]: https://milkv.io/about
Wake me up when someone can actually build a computer from scratch with EU-made parts.
The eProcessor TC1 is a RISC-V CPU with cores designed by Cortus (Mauguio, France) and fabricated in GlobalFoundries Dresden fab (22FDX). But that's a public initiative, not a private one.
Is there a cheap .dev board (assembled in EU) available for purchase by regular consumers?
I don't think so. The best you could find I think is some router with NXP or ST chips, but following the manufacturer you may or may not be able to do whatever you want with it.
Sadly we Europeans have taken our industry behind a shed and we put it out of its misery of having to pay exorbitant electricity prices and deal with our environmental regulations.
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.
> build a computer from scratch
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.
A lot of ST made ARM chips should be more or less EU made, or at least Western made
> Wake me up when someone can actually build a computer from scratch with EU-made parts.
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?
Little unclear.
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?
It is supposed to be a sturdy industrial computer with a RVA23-capable SoC inside, capable of running two or more OSes simultaneously. At least one of those OSes must be a hard-real-time OS, used e.g. in control or robot tasks.
Pure model slop. When I read this I get a headache and feel repulsed.
Yes, Dead internet stinks and is approaching faster than AI market collapse.
Likewise. I'm a RISC-V fan but a slop page like this is not a good look.
[flagged]
[dead]
How long do we keep RISCV going without facing that it has failed? We were supposed to be surrounded by M1 level RVA23 devices by now.
The telling thing is in benchmarks the Loongson outperforms them, by a lot.
It makes sense for the Chinese to make Loongson be performant, its an ISA they fully control and only have to do with domestic Loongson standard body politics instead of having to deal with global Politics in the RISC-V standard bodies.
Isn't it a bit hasty to say this, when one of the more powerful RISC-V CPU cores (Ascalon) hasn't been taped out yet?
No, it's not hasty to say that a processor that I can buy and benchmark today outperforms a processor that hasn't even been taped out.
The devboard, was supposed to come out end of last year, now it's sometime next year with 1.38GHz on 12nm.
This stuff has all been six months away for years now.
At some point we have to accept it isn’t happening.
At this point I've stopped considering TT as a serious company.
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.
Have to agree.
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.
So it's late to deliver hugely complex cores according to some optimistic timeline? That's a weird measure of success. The ISA is successful in the low end and is seeing huge investment on large cores, though most of the promising companies are now focusing on AI or getting bought by large players like Qualcomm. So yeah it might take a while still before we see competitive high end consumer cores. I would still put my money on RISC-V rather than Loongson for the long term but we'll see.
That's a weird measure of success.
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.
That's using he most enthusiastic fanboy predictions as the baseline by which to judge success, not a recipe for reaching the right conclusions.
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.
> I'd rather look at all the data available
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.
RISC-V was a young, purely academic project in 2011. The pivot to industry came in 2015. This was followed by announcements by companies that they were shifting to RISC-V, but guess what, it takes time. For example Western Digital announced in 2017 but shipped only in 2021.
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?
But is it not a bit early to judge the ISA's potential based on the chips on shelves today?
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 no data to suggest RISCV can ever be competitive in the large core space.
There is also no data to suggest otherwise.
RISC-V is inevitable.
Not sure this quasi-religious framing does RISC-V any good.
Is it though? AI can rapidly push through an objectively better standard if a group becomes motivated to make one. There’s no need to marry ourselves permanently to a mediocre design like we did with C interop.
By some coincidence RISC-V became successful just before/while AI took off, and I'm glad it did. The design is pretty good for low end cores and probably good enough for high end cores, so there's a chance it will become one of the dominant ISAs in the mid-term.
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.
This cultish nonsense is one reason I've stopped taking RISC-V seriously for desktop/server usage. There are other reasons too:
- 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.
Yet another "initiative". I remember the European Processor Initiative that went precisely nowhere.
https://en.wikipedia.org/wiki/European_Processor_Initiative
Not an expert, but reading the article you linked it seems it was quite stressful?
> 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..