I don't know anything about this market so I may be completely off-topic here but would RISC-V help in this case? RISC-V has a modular design where the size and complexity of you CPU can be adapted pretty dramatically (RV32I is not that much more complex than a 6502) and being "open" and free can be manufactured by anyone.
Indeed today it remains a niche but we see some reasonable momentum and it's getting traction.
Again I don't know anything about PCEngine (reading the title I though they were still making that game console from the 90s...) but I am interested to see where RISC-V could take over some x86 business and that's looks like it.
No. RISC-V is just the ISA spec. It doesn't give you an actual chip. Producing an actual reasonably fast CPU is much much more challenging. So RISC-V can be as modular as it can be, it is up to the manufacturers to create chips using it.
RISC-V doesn't give you a magic wand to create chips. It just gives manifacturers easier terms for licensing. Not you or PC Engines an easier time to design and source things. AMD also has all the licenses it wants. The advantages that RISC-V brings doesn't affect them.
Moreover any actual RISC-V chip that's worth replacing the AMD in PC Engines will be at least as proprietary as the AMD chip. It will have its own design requirements that PC Engines still needs to obtain from the whatever manufacturer.
RISC-V only makes the job of the IC manufacturers easier. For everybody else, it is yet another thing to struggle with porting.
But what RISC-V would provide is a "standard" ISA. You can avoid having a manufacturer/vendor lock-in. Anyone can manufacture a RV64EMAFDZicsr.
> Not PC Engines an easier time to design and source things
Isn't it better to rely on a "standard" technology than a proprietary one? x86 is not standard, it's widespread. The Duopoly in place can decide the price, the feature, even its client. They can decide one day to stop providing what you need and that's it. With a standard chip, you can go next door in Shenzhen and get what you need.
> Moreover any actual RISC-V chip that's worth replacing the AMD in PC Engines will be at least as proprietary as the AMD chip
Why? We are not talking about a supercomputer to train LLM here but simple network appliance than needs efficiency. The GX-412TC PC Engines was using, doesn't look that impressive. Aren't there already RISC-V chip today on par with it? Like VisionFive for example?
> But what RISC-V would provide is a "standard" ISA. You can avoid having a manufacturer/vendor lock-in. Anyone can manufacture a RV64EMAFDZicsr.
Anyone can manufacture a chip based around one of Arm's CPU core designs if they pay a licensing fee to Arm, and many different manufacturers do. If you want to, you can even make your own CPU design supporting an Arm ISA, again if you pay a licensing fee.
Likewise, you could license a RISC-V CPU design from some company… for a smaller licensing fee, but you will have RISC-V's worse software compatibility, and probably worse overall performance, efficiency, die area and quality.
The ISA is a tiny piece of the puzzle and not the most important one. RISC-V is cool because Arm won't sue you for making a hobby project that implements it in hardware, but it doesn't solve problems other than “Arm's license fees are too high”.
>and probably worse overall performance, efficiency, die area and quality.
Unlikely. E.g. SiFive offerings beat the crap of ARM equivalents, in performance, power and area.
>but you will have RISC-V's worse software compatibility,
Using the standard ISA gets you the widest possible ecosystem.
Of course, this isn't true yet, but it will be in practice, when considering the current trends and the fact hardware takes years from the time the decision is made till having hardware in hand.
>RISC-V is cool because Arm won't sue you for making a hobby project that implements it in hardware,
With 10b+ cores shipped in 2022, we're well past the "niche ISA for hobby projects" stage.
> The question on everyone’s mind is when RISC-V will come to user-facing applications. The answer is that this may be closer than people expect. There are currently 4 companies working on large RISC-V cores that compete with the biggest and fastest from Intel, AMD, Arm, Apple, etc. These 4 companies are Ventana Micro Systems, Tenstorrent, Rivos, and Akeana. Each of these companies have teams with impressive pedigrees, but that alone doesn’t guarantee success.
Yet, the most reliable services people use every day run on x86. It's not "really bad".
>due to its complexity
I don't see the complexity of the instruction set causing downtime. Compilers abstract 99% of it away.
>due to obtrusive (SMM mode), non-auditable firmware.
I've never seen SMM mode cause down time, nor have I had the non-auditability of the firmware caus me down time. These are low level things that are a part of how the CPU works. When you are working at a high level you can just ignore them for the most part. For reliability you are always going to need to be able to handle bad chips due to manufacturing defects once you are operating at scale.
> I've never seen SMM mode cause down time, nor have I had the non-auditability of the firmware caus me down time.
Hyperscalers (OCP) pushing for coreboot and LinuxBoot have probably different experience. AFAIK they hate SMM especially with SMI handlers coming form unknown source.
Not saying SMI latency is huge problem in industrial applications like CNC.
>Yet, the most reliable services people use every day run on x86. It's not "really bad".
When reliability is paramount (e.g. pacemakers), x86 is naturally avoided.
>I don't see the complexity of the instruction set causing downtime. Compilers abstract 99% of it away.
Complexity of the ISA affects the whole system. It breeds bugs not just in hardware, but also in operating systems and toolchains. These can affect reliability.
>I've never seen SMM mode cause down time
I have. With SMM, the rug is pulled under the OS's feet. Your CPU can be taken away at any time, for any unexplained reason, without prior warning, and for an undetermined amount of time.
I have seen SMM cause spikes of latency breaking pro audio pipelines, and I have seen SMM grab a CPU and not return it.
I'm not a RISC-V expert, primarily relying on open-source firmware community knowledge and the opinion of such figures as Ron Minnich, but AFAIK, most firmware for production RISC-V deployments is closed-source, so we can't say if vendors use OpenSBI implementation or some modified version for their malicious purposes. If I need to be corrected, please point me to products that state how they transparently use SBI. There is evidence of transparent use of SMM in coreboot. SBI is not the only RISC-V TEE. There are also other concepts, like MultiZone [1] and PMP-based Keystone [2], advertised as trusted execution environments
The openness of specification only matters a little here - UEFI specification about management mode is also open. But IBVs screwed us many times [3] by implementing low-quality SMIs that could elevate privileges, and the spec does not guarantee that implementers follow it. Lack of tooling makes compliance difficult - it slowly changes with various startups seeing that as an opportunity (e.g., Binarly, Eclypsium?).
My point is that SMM as TEE is not a unique x86 feature, and other significant architectures have similar mechanisms. OS has a means of figuring out that it was in SMI, so it is not entirely hidden but still has superpowers. In the CNC world SMI latency is measured from OS [4].
Trusted execution environments are hammers and can be used for a good purpose in a transparent way and for malicious purposes. Further typically depends on the trustworthiness of mechanisms implemented and used by vendors, but thus keep the fact that TEEs and peripheral MCUs are everywhere, which may lead to the extended attack surface.
Why do we see those TEEs, peripheral MCUs, everywhere? I like the explanation in this lecture [5]. No architecture can quickly fix that problem.
There's little RISC-V could do to prevent bad SMIs.
It already did well enough by standardizing SBI and by providing a high-quality open implementation of it.
This minimizes (or even removes) incentives to provide a proprietary solution.
Some vendors will of course do whatever they want, instead of just using opensbi.
But they'll be opting out of being compliant with the platform specs, and of benefiting from the support for SBI present in operating systems and embedded toolchains. Such an implementation would just make themselves and everybody else miserable.
In an ideal world, the market will avoid non-compliant SoCs. In practice, there will be some of these to point at as examples of how not to operate.
You're mixing implementations and the ISA. A RISC-V chip can be as daunting as any other x86 and I can assure you they will be.
Those modes are one of the ways to enforce export controls. Any competitive chip has something similar, say ARM TrustZone or whatever x86 manufacturers name their security mode.
If you don't put such features, the Asian manufacturers will instantly copy your IC.
Indeed today it remains a niche but we see some reasonable momentum and it's getting traction.
Again I don't know anything about PCEngine (reading the title I though they were still making that game console from the 90s...) but I am interested to see where RISC-V could take over some x86 business and that's looks like it.