RISC-V CTO: We won't dictate chip design like Arm and x86 Chip technologies from Arm and x86 are getting the most attention amid semiconductor shortages and trade wars. But in the background, the open-source RISC-V chip architecture is stealthily emerging as a viable third architecture that is cheaper, flexible, and free of political intrigue. RISC-V is often referred to as the Linux …
Last time I checked, ARM licensing is peanuts. The expensive part as always it getting the things made into physical products. You save 8 cents on royalties for the chip, but still need to find a multibillion dollar fabrication plant to make the thing in.
For software, compiling into a functioning thing is super cheap.
But you saved 8 cents! Well it still cost 10 dollars to make.
Linux is a bad compare as an example. Windows was expensive relative to the cost of a PC and buggy as shit. AIX is an even worse example.
For the humble bloke on the street, it means nothing. Even the most geeky of geeks is not going to be able to verify the chip they have in their new phone is a pure version of the RIS V VHDL they think they saw rather than the thing that's compiled. Its not going to be like downloading the latest Linux kernel and recompiling.
At the end of the day, all kinds of taint could be in the CPU you are using.
8 cents?
Great, I wish to pay for 250 licenses please.
Gimme a selection of all CPUs you have please. Say 4 of each type.
Where do I pay ?
Where do I download all the IP in verilog/RTL format so I can work on my designs and organise a fab. Yes that is possible :)
I already have access to your ARM DesignStart(tm) but you only provide 2 very low end processors, with problemaic limitations. I assume because I paid I don't have these limitations now.
Also the recommended Kali ARM compiler is around 3k GBP just for toolchain. GCC and LLVM seems better. The website looks like it is from the 90s.
Thanks very much.
Where do I sent that 20 quid now?
The point to RISC-V is less about saving licensing costs and more about control over the technology. If NVIDIA are able to buy ARM then they can set whatever terms and conditions they want when it comes time to renew your license. The number of people outside of NVIDIA who don't see this as a problem are vanishingly small.
It's also about sovereignty. Nobody is going to be able to declare that one of your country's major CPU dependent industries is a "threat to national security" and cut off your licenses.
What is more, it's also about the building blocks of the IT industry increasingly becoming commodities. There is no reason why the CPU should be exempt from this. Low end GPUs will follow.
When a RISC-V Raspberry Pi equivalent comes out, I'm looking forward to buying one and working with it.
“ If NVIDIA are able to buy ARM then they can set whatever terms and conditions they want when it comes time to renew your license”.
Is totally, 100%, correct. This is it, all of it.
The “sovereignty” angle is purest nonsense, as anyone who has run an ASIC program for real will tell you. If your usage really is such as to annoy the US, then they can (and will) stop you.
I could write a very long list of all the technical dependencies you have in the other stages of chip manufacturer, that the US can leverage. From the EDA tools, to the FPGAs you use to prototype it, to the dozens of critical but less well-known IPs you integrate (codecs? analogue serdes?), to the packaging, to the shipping companies.
But the absolute killer is that if the US decides it doesn’t like what you are doing, then it just gets the DoD to invoke ITAR. When it comes time for your customer to pay you, their bank is threatened with disconnection from the SWIFT payments system if they do so.
That’s a game-over threat, used frequently against Iran etc.
*The US controls the worlds reserve currency and payments system*. Pretending you can circumvent that is just stooopid.
“ If NVIDIA are able to buy ARM then they can set whatever terms and conditions they want when it comes time to renew your license”.
For new projects maybe, but paying big billions for a tech and then kill it by encouraging potential clients to look elsewhere, which in turn will accelerate development of the open source rival, leaving NVidia with dwindling existing royalties only. Unless they plan to keep the tech to themselves.
With the rise of an open source alternative, ARM need to get a bit more generous with terms and conditions.
So no, that is definitely not all of it.
There are RISC-V boards similar in performance to Pi Zero through to Pi 4. At the moment they cost more, but that's a market size and mass production problem not a technology problem.
For example the $17 Sipeed LicheeRV is similar to a Pi Zero compute module, and docks giving a good set of I/O connectors start from $5.
https://www.aliexpress.com/item/1005003594875290.html
https://www.aliexpress.com/item/1005003741287162.html
The ICE RVB has similar performance to a Pi 4, though with fewer cores and a much higher price (just as the "Nezha" EVB has the same SoC as the LicheeRV but at a much higher price). Expect to see the same SoC appear on much cheaper boards in the next few months -- I suspect BeagleBoard will be one of the vendors.
https://www.aliexpress.com/item/1005003395978459.html
You, of course, can't. You need to shell out a few million dollars to get a license or you won't get one.
So that's a hurdle right there. Most small companies can't afford this. And then there are the recurring costs such as support and software that too cost millions a year.
See there why all the innovation is occurring at small startups using RISC-V.
And for the Chinese, even those 8 cents are non-trivial. They need MCU's for a $10 alarm clock, so they need one that only costs a dime.
RISC-V was never about licensing costs. It's about flexibility and freedom, and the ability to move fast.
Forget the cost, reliable sources say that it typically takes one or two years for the lawyers to simply negotiate the contract with ARM. And that's for an off-the-shelf standard core.
Only a few few of ARM's licensees ("Architecture License") have the right to modify ARM's microarchitecture, or to design their own core. Until the last year NO ONE had the right to add or subtract any instructions from the ARM Instruction Set.
RISC-V core vendors such as SiFive or Andes also change licensing fees. They might or night not be less than ARMs, but they are not zero. If you don't want to pay them (or others) you are free to design your own core -- *everyone* in the world effectively has a free Architecture License -- but you're going to have to hire some expensive people to do that and it will cost you more than licensing a commercial core.
But you get flexibility.
Do you want a very small core like a Cortex M0, but you want it to run faster than 48 MHz? Sorry, ARM won't do that. SiFive will license you an E20 that will run at 1 GHz on 7 nm if you want to - and Andes has something similar. Do you want a very small core like a Cortex M0, but you want it to have 64 bit registers and addresses instead of 32 bit? You can't do that with ARM -- their smallest 64 bit core is much bigger. Do you want to get something like a Cortex M0 but with an FPU, or with a vector processing unit? You can't do that with ARM, but SiFive or Andes will be very happy to license you one.
The same applies up and down the line. RISC-V vendors give you much more flexibility than ARM does -- up to their current upper limit on core performance, which is currently in Cortex A73 to A76 range depending on which vendor. Or if you have a lot of money and think you can do a better job yourself then you are free to -- while still getting the benefit of standard gcc, LLVM, Linux, FreeRTOS, Zephyr etc etc.
The drawback is, of course, fragmentation of the platform. If you get a myriad of incompatible cores the software and hardware support will eventually suffer.
ARM is guarding against this fragmentation by limiting the number of permutations one can license from them. This ensures that the software developers supporting the hardware have a limited set of hardware they need to support.
Fragmentation is not an issue in many workloads. Say the automotive sector decides t move away from PowerPC in say a transmission controller. If they design or use a custom core, fragmentation is not an issue. The software running on it is already custom.
So I would expect for many large companies or even sectors, that custom cores and fragmentation are not an issue. If Bosch decides to create or use a custom core, software and hardware support is not an issue at all.
If a phone manufacturer decides to use a custom core, then fragmentation can be an issue.
The auto world already uses plenty of different instruction sets: Power, ARM, Aurix, STM 16 bit, japanese Hitachi-PDP11 (no joking), japanese Mitsubish and probably 25 other instruction sets. It looks like the japanese now switch to ARM and use these controllers also in cameras, TVs etc.
That is possible, because automotive control units are custom-developed from pcb to housing to connectors to software. There is now some standardization from the AUTOSAR operating system, which is typically delivered in source by Vector Informatik. Modern auto software is fully done in C and is (to 99,99% of code) only a recompile away from a new mikrocontroller, if Vector Informatik has ported the OS to this MCU. Drivers are a different story, of course as they must fit to the MCU registers.
The control unit developer company must then demonstrate that the unit will meet all requirements defined by the auto company for the unit (including timing requirements). Unit and software testing should be done on the new controller to see that the compiler and the processor dont have funny behaviour. There is no additional effort for a new instruction set to perform this. Rather, the big effort is to define, create and debug all of these test cases.
In the IT sphere, a properly developed C++, Rust or Sappeur program will simply rebuild and run nicely on any major POSIX platfrom and CPU. If not, it is almost always due to a hidden bug. I have done this with great success from SPARC to ARM to ELBRUS:
http://sappeur.ddnss.de/
http://gauss.ddnss.de/
For example, the ELRBUS instruction set is a secret, but there exists a nice tcc C++ compiler. I never bothered to look at the generated binary code, it just runs quite nicely at approx RPI speed.
Fragmentation is an issue if you use an operating system, since the open-source developers refuse to support too much permutations of the hardware.
I don't know if the automotive industry has already started using operating systems for their ECU's, but unless they want to stick with expensive bespoke operating systems (either commercial of in-house developed ones) they'll need to limit the number of customizations.
If you have an infinite amount of money and labor you can always roll your own, but that's not an option for many SME's.
Espressif releases the ESP32-H2 later this year and like every cheap wifi light / gadget out of China has an esp8266 inside, every new thread/zigbee device will have RISC-V inside. The reason will be because it will be the lowest cost 802.15.4 module as there will be no ARM royalties to be added to the BOM cost.
The reason will be because it will be the lowest cost 802.15.4 module as there will be no ARM royalties to be added to the BOM cost.
I wonder how much of that is purely down to chip cost, and how much is driven by the fact that for IoT applications WiFi is a prerequisite.
I look at chips like the RP2040 -- inexpensive dual-core Arm M0 -- and wonder where the WiFi is, then I look at the RP2040 solutions that do have WiFi and see that in every case it is provided by adding (say) and ESP8266 as a second processor communicating over a slow serial connection. In most of those cases the whole design could be driven by the ESP8266 alone. The difference in cost between the Arm and Tensilica processors isn't the important factor, it's the fact that there need to be TWO procerssors in the Arm-based design, because it doesn't have WiFi.
Risc-V SoCs with onboard WiFi will be indeed very interesting when they become widely available.
@msobkow
I am not interested in spending any more time on this but perhaps there is something here for somebody else interested in that topic.
On the Top500 list of supercomputers you find as number 4
Sunway MPP, Sunway SW26010 260C 1.45GHz, Sunway
And about the CPU Sunway SW26010 you find this on the Wikipedia:
"The SW26010 is a 260-core manycore processor designed by the National High Performance Integrated Circuit Design Center in Shanghai. It implements the Sunway architecture, a 64-bit reduced instruction set computing (RISC) architecture designed in China".
And it runs Linux of course, like they all do.
https://www.top500.org/lists/top500/2021/11/highs/
https://en.wikipedia.org/wiki/Sunway_SW26010
The poster misunderstands and is simply comparing a.n.other RISC architecture with the RISC-V "standard" ... Seems people think RISC means RISC-V and it's all a bright and shiny new thing but we were working on RISC architectures in the 80's. The "open source model" is really the new feature but with (essential in my view) big company backing, from the likes of Google, how long will it be before it's driven and controlled by big companies, the likes of ... ?
>Ideals don't get you far in the real world of products and projects.
The RISC-V architecture is a rationalization of a type of RISC processor design that's been used successfully for decades. I've used it as a MIPS or one of the 'soft' processors such as Xilinx's Microblaze. Even the basic ARM architecture is just a thinned down version of this architecture (16 instead of 32 registers) with a bit of secret sauce in the form of an instruction skip capability. So its not really the processor design that's revolutionary so much as the standardization.
Remember, people didn't coalesce around Intel's architecture because it was the best. It became the most common because of the PC and then WinTel but from an architectural perspective their processors are a dog's breakfast, a set of ad-hoc extensions that were built on the original capabilities (and limitations) of the 8080. ARM's processors are the same. Their original claim to fame was that they were simple and took up minimal space on a die. Their abysmal performance was unimportant. It was only after their low power use and wide support found them being widely used in portable devices that they gained a niche alongside Intel. The situation was livable with because perfection isn't necessary when brute force can overcome limitations but the calculus has been changed by making these architectures political property; its opened the door for a true global architecture and I suspect that this will eventually prevail (or Intel and/or ARM will finally tell their respective governments to 'go take a hike' because its either that or they're doomed to eventually fail).
Apple has thrown their huge money and manpower behind ARM and have created the world's fastest (publicly know) CPU. ARM was slow in the past because it came from the phone world, where you can waste so much Joules as in the data center or the always power connected PC world.
Too low end? It's in all the landfill routers we have. I think RISC-V are aiming higher. I'm currently using a STM32 Nucleo board for a little home-brew project. It has a ARM core but also I and D cache and a crude MPU, that was a godsend for turning off the D-Cache on my DMA buffers. This, I'm thinking, is where RISC-V wants to be, and more.
RISC-V is similar in philosophy to MIPS. The RISC-V assembly language uses many of the same mnemonics as MIPS, but with different semantics and binary encoding. Many of the instructions are completely different, especially around function call and return and conditional branching (though neither uses condition codes). The most recent MIPS specifications (MIPS R6 and NanoMIPS) adopted some of RISC-V's ideas.
RISC-V and MIPS are also both very similar to DEC Alpha, and to a slightly lesser extent ARM Aarch64.
It's not free to implement your own MIPS core.
MIPS wanting about $5 million for *just* the rights to use the ISA (not even supplying a core) was the reason Berkeley university developed RISC-V instead.
MIPS announced an "open source" program in April 2019. It had pretty awful terms. You had to apply for entry to the program, giving details of what you intended to use the MIPS ISA for, your business plans etc. You were only allowed to do things within very narrow parameters. You had to have your core certified by MIPS. You were not allowed to distribute the design of your core to others.
And then in November 2019 -- just seven months later -- MIPS cancelled the program entirely, long before anyone could have had a chance to ship anything.
Now MIPS has announced they are dumping their own ISA and switching to RISC-V.
The fact is that there weren't a lot of open source Unix-like operating systems around in 1991 when Torvalds came up with Linux.
What Linux taught me is that there's an enormous need for an open-source operating system, even if it isn't the best. Companies embraced Linux because they needed a full-size operating system for their smart, internet connected gadgets. Rolling your own became too expensive and cumbersome after a while.
These days there are a myriad of open-source operating systems around, but none has the hardware support Linux has, so they all dwindle.
One of the reasons Linux has succeeded in so many areas is that it uses the GPL license. It requires that you must provide the source code to any interested customer of your product. The network effect of that has proved essential and it is something the BSD world doesn't have.
Does the RISC-V community have something similar to the GPL? The ability to remix customizations.
That the success of Linux was because of its licence is a popular misconception. Certainly, the FSF became an effective champion of Linux for a while, but it was a long time before corporations got involved in Linux and that only after the legal department has decided what they could and couldn't do. Even now, with things like the NTFS driver, licensing issues hold Linux back. I remember reading an e-mail in HP which advised employees to avoid GPL code, even when not at work for fear of potential law suits.
And corporations like Google, Amazon but also RedHat, now part of IBM, have shown how easily they can work around the GPL.
It's no coincidence that the GPL has become less and less popular for open source projects for years.
To answer that question, no, there is no requirement to contribute back. RISC-V is provided in the form of a spec an the tools to verify that an implementation meets the requirements. Nothing needs to be shared about how a core is actually implemented (and indeed the fab manufacturers of many of the more advanced process nodes forbid the sharing of technical details of how the nodes work, so that detail wouldn’t be available anyway).
I agree. Linux support grew rapidly because many developers in the '90's weren't keen on working for free with commercial companies running with their code and doing whatever they wanted with it (BSD license).
They wanted the ecosystem to grow by an ever larger number contributions and there were simply too few that we willing to work for free.
Long story short: the GPL licensing has been instrumental in the success of Linux.
Actually, the corporate IP lawyers will get very unhappy also if you contribute to BSD without first clearing with them, or use it within products. GPL and its implications are by now well-understood by competent IP lawyers, they don't get freaked out by it. It just have some different conditions than the BSD one. Licenses that are not GPL, BSD, MIT or other well-known ones are what make them nervous. But whatever it is, they require clearance.
Actually, the corporate IP lawyers will get very unhappy also if you contribute to BSD without first clearing with them, or use it within products.
The two are distinct and separate issues. The point I was making was that, at the time, HP positively discouraged employees from even looking GPL source. Things did quieten down eventually but it was an example of how the GPL hindered corporate engagement in Linux.
FreeBSD came along in 1993, and arguably has been pretty successful There's a $3trillion company that's done very well out of it... We also easily forget the period of time when Solaris was essentially an OSS project - OpenSolaris was a thing. Oracle slammed that door shut, which was probably an error...
Linux was around first in 1991, but that doesn't really mean anything. It's not like everyone suddenly jumped on to it and immediately rolled out vast data centres using it; I can remember that it remained essentially no more than a curiosity for a very long time. Some companies went with Linux, others went with FreeBSD. What made the distinction was that companies like Intel and IBM recognised that Linux was going to be popular in back end service provision, so it was worth putting in the effort making sure Linux ran well on their hardware. FreeBSD was made popular on client-side - Sony PS, Apple - where the companies could afford to do that work behind closed doors.
GPL has made it very complex to support hardware in Linux. Just look at the debacle over WiFi...
FreeBSD was first released in 1993, and came about as a re-write of some of the proprietary bits of BSD. Clue is in the name!
It's not consistent to demand adherence to GPL2 (as some do), give opinions of illegality against those who stick to GPL2 in a way that other people don't like (as others do), accept BSD licensed and proprietary drivers within a GPL2 project, and then also reject purely OSS licensed code like ZFS.
Having BSD licensed drivers simply underlines the issues that GPL2 causes, going forwards. Having all sorts of shenanigans where such drivers aren't "linked" by not putting them into the initfs is another illustration of the issue.
None of this is Linus's fault of course - he just picked up a ready-to-go license and went with it.
But really there needs to be a way in which Linux licensing is re-thought, because it is being severely held back now and its only going to get worse. There is the problem of dead contributors' code not being re-licenseable, but I reckon that a concerted effort to get permission from the living would leave very little code that would have to be re-written to avoid being sued from beyond the grave (and even then their estates could give permission). And given that there's already a lot of stretching of GPL2 done to make Linus at all usable on modern hardware, there's always the option of "Just Doing It Because Everyone Who Will Notice Has Already Agreed To It, Kinda".
Sorting out this kind of thing that the FSF should be doing, rather than sticking with their "GPL! GPL!" mantra...
But in the background, the open-source RISC-V chip architecture is stealthily emerging as a viable third architecture…
To be sure, it may be many years until RISC-V emerges as a viable alternative to x86 and Arm…
It is either emerging or will take years to do so… The interview demonstrates little grasp of exactly what RISC-V is, where it might be used, where it is already being used and where it might end up being used. At the moment, for China, RISC-V offers the best opportunity for silicon that is not at the whim of the US government. For nearly everyone else overall price and time to market remain the key criteria.
That's endemic with the confusion thrown around when using the term "tech". Earlier this week there was a news item on the radio about "tech" skills shortages:
Interviewer: So, you will be training people in coding and programming?
Interviewee: Yes, we train people to be IT technicians, front line support, tech support....
ARRGH!G!OUI!^V!)*&V% ^!(V )*&( $! (&£ (
I wonder if this interview was verbal and transcribed. If so, I think that the punctuation might be incorrect. The phrase reads as "It's a lot easier to talk about all the variants of Linux – Zephyr, FreeRTOS, Alpine", but I could also see it being "It's a lot easier to talk about all the variants of Linux, Zephyr, FreeRTOS, Alpine". I.E. a list of things, and the variants of Linux are just one item in it. Since Zephyr is also not Linux (Linux foundation project, but doesn't use the Linux kernel), this seems likely to me.
As for the automotive companies, they use and develop a lot of technology, but so does basically everything that manufactures stuff. This gets even worse when we include software development, because now every sufficiently large company that develops some computer-based service is in tech. In that sense, I'm not sure I have an objection to having a category for those companies that develop tech as the primary product, rather than developing tech only for a different type of product for which their company is known. Where would you draw the line?
Making an ISA is trivial, so China can happily do its own.
The value of the ISA is to sell to *others*.
Remember that only the RISCV ISA is open source, the processors don't have to be and as far as I know, outside of academia are closed implementations. Only a very basic subset is common, so a sw can be made to work if it is generic, but likely will underperform without the custom extensions or compilers.
This also is an indirect way to for eg circumvent open source. You can give the source code, but without a compiler for the processor, it is basically useless code to update or overcome planned obsolescence.
It is open in name only.
Arm and X86 enforce the ISA so any compiler for the ISA would do.
The article is marketing fluff - there is little insight into the vision of building an ecosystem when everyone can just DIY their own incompatible change. A concept so open to cause chaos, which means some defacto winner will need to emerge, who will control it.
If they locked the ISA, and allowed updates by consensus, and required no local customisations, maybe they'd be on to something.
Right now it is for companies to just to save on royalty, because they are fine with proprietary opaque binaries for their products.
They don't want care that you can't build fw from source for openddrt and lineage. Add one register or move 1bit on their next RISCV processor incarnation and any reverse engineering has to begin again.
That "very basic RISC-V common subset" includes 32 bit and 64 bit ISAs, FPU, SVE-like vectors, cache control, hypervisor, crypto (e.g. SHA, AES, TRNG).
Anyone wishing to use the trademark "RISC-V" with their products must pass conformance tests for the standard parts of the ISA, and therefore correctly run any code from standard compilers such as gcc and LLVM.
If someone adds extensions then all standard software will continue to run correctly. Of course programs using the extensions won't run elsewhere but that's the point -- custom extensions are by nature usually very specialised.
The microarchitecture is not. Having the basic isa from some compiler gives no predictability of either performance or functionality.
So SW can run. Correctly? Not assured. It can run slow, it can crop up race errors specific to a processor implementation.
It could be as simple as a cache evict instruction, as a custom extension, on top of the standard ISA. Will another compiler produced code run? Sure. Will it work the same way as the vendors private compiler? Not necessarily. Getting a RISCV certification absolutely does not secure that.
It can be in the interest of someone putting in a custom core to not do that, especially iot. If they are selling it as a separate microcontroller, the licensing saving from Arm is moot. So RISV needs some uber feature to be chosen as a controller of choice over existing offerings.
See Andes and CODENSE as a case in point. Custom compression meaning a standard compiler code can run, but need not fit in the flash memory. You would need a CODENSE compiler.
There seems to be a common misconception that IC design is done using circuit diagrams of transistors and logic gates. These days silicon (and indeed many PCBs) are laid out by computer based on a fairly C-like programming languages. These describe the logic and get "compiled" to hardware layouts.
Take a look at how modern FPGA boards are programmed. Usually chips are first simulated on these before going into full silicon production. The source code used is the same.
There's a bit of manual layout (usually due to thermals), but it's more "guiding the compiler" than drawing circuits on paper.
I don't think that RISC-V is going to be mass market accepted, not for a long, long time. The software really, really matters, and in the mobile space a huge amount of it is for ARM and only ARM. There's simply not a large enough downside to ARM for there to be a large gap in the market that a new ISA can bust wide open and exploit. The last time that happened, it was ARM doing it to Intel and everyone else.
At best, a company moving away from ARM to RISC--V brings about only modest gains (whilst you can charge $100s for a phone) with the massive downside of no-one building software for RISC-V. This is going to mean that the fastest, lowest power chips are more likely to be ARM, and less likely to be RISC-V; there's little market sense in buying expensive time on TSMC's fabs to make chips that are harder to sell... RISC-V can and already has found a home in things like HDD controllers - places where there is a very limited need to run third party software.
Intel had this problem in the mobile space; Intel Android was always a lame duck due to all the software being built for ARM...
I think the criticism of OpenPower or OpenSPARC is a bit off the mark. AFAIK the OpenPower foundation has full access to the entirety of the design of the POWER processors, and it's an independent legal entity separate from IBM.
Same for open source SPARCs; you didn't need Sun's help to build them for oneself. And it's not even as if you couldn't tinker with design. Fujitsu did just that with SPARC, basing the K-Machine super computer on SPARC but tinkering with it really quite a lot. Fujitsu have now just gone and done a similar amount of tinkering with ARM cores, adding the Tofu interconnect, etc. for their latest very impressive super computer.
So it's not like RISC-V has a monopoly on the ability to fiddle with and adapt designs to specific needs; everyone else has already been doing that for years. I suppose the difference is that a small ARM licensee isn't permitted to tinker beyond bolting on peripherals, but then again that's been a hugely successful model even so.
If phones and desktop PC's were cars, AMD, ARM and Intel would be the ones dictating how their engines were designed or built.
The great thing of RISC-V is that many can now tinker with the design and create actual products, just like every self respecting car manufacturer produces their car engines.
RISC-V allows many more thousands of smart people to invent and test innovations in CPU design, without experiencing constraints due to corporate politics, marketing or technical luggage from the past.
This and the fact that the most advanced fabs nowadays are not owned by Intel or IBM, will probably create conditions allowing rapid improvement of CPU capabilities not seen in the previous decades where the CPU world was ruled by less than a handful.
Getting a new CPU to run android requires Linux and a google compatible Java engine to run, since Android is written in Java.
Maybe you are correct for phones, because of the logistics of binary code (as opposed to portable Java code). But, there are plenty domains which can easily switch:
Data Centers (they run various Riscs since 1992 or so, Now Amazon has ARM)
Apple Devices
Automotive
Telecom infrastructure
GPUs
Medical
Rail
Aerospace
TV, Radio
Many of them currently switch to ARM from much more exotic stuff such as japanese Hitachi PDP11 and can do another switch to Risc-V, if ARM plays too complicated.
Non gaming android applications are written in java. IIRC google play builds an x-86 version when you submit to the google play store. So assuming they adopt it there it could take off.
Where you run into issues is when you want to play mobile fps (why would you). That uses android NDK meaning it is just a binary. At that point there will need to support from the game engine and the developer.
The good news is that all the android graphics libraries (Vulkan and OGL) are open anyway so there won't be an issues of getting support from those like directX for windows as you can just build it yourself. Although I'd be surprised if khronos wouldn't support it natively assuming there was interest from the manufacturers.
Of course, any potential RISC-V smartphone would target the low end at least initially anyway. So the gaming point becomes somewhat less relevant. RISC-V is really 15 years late to the game for mobile and it will take a lot to have any chance of not becoming the next Linux for the desktop.
RISC-V is an elegant way to hand over American designed IP to Ch-i-na. Well done! You have managed to subvert your governmental efforts and are effectively serving processor technologies on a platter to not so humane people. Remember ignorance is not an excuse you will be able to clutch onto forever.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
