Anybody remember Microsoft’s “get the facts” campaign? Well, ARM is having its “get the facts” moment, with the British company launching a site to disparage the open source RISC-V architecture.
The instruction set architecture (ISA) is the foundation of all chip or System-on-Chip (SoC) products. It is therefore one of the most fundamental design choices you will make. If you are considering using an open-source ISA, such as RISC-V, it is critical to understand the key factors you should consider as part of your go-to-market strategy.
It seems odd for ARM – riding high as it is – to attack RISC-V like this, which seems to barely be making a dent anywhere.
I can only see this backfiring on ARM
Someone felt threatened at ARM. This is a knee jerk kind of action which is quite common in general. I don’t see anything surprising at all.
The fallout is going to cost the PR deparment an arm and a leg.
Japanese company — it was sold to SoftBank group for ^Alb24 billion
“There’s no such thing as bad publicity”. (that’s glib of course, however, some of ARM’s negatives also look like positives!)
I don’t know how that quote ever got legs. Nobody who works in PR or comms believes that, that’s for sure!! Companies measure the damage to their brand value from bad publicity in the hundreds of millions of dollars.
Fair enough. I mean, for home use it’s fine, but for a commercial product, that be, well… quite RISC-v.
Can ARM still be regarded as British? It doesn’t manufacture anything (so no factory in the UK), has design offices spread around the world and is owned by a Japanese company and Saudi/Abu Dhabi venture capitalists.
Sure, its HQ is in the UK but it just seems less British than BMW Mini and Jaguar Land Rover, for example.
As for the RISC-V thing, it’s a bizarre move by ARM – the equivalent of “you know that thing you’re not thinking about? don’t think about that thing, even though I’ve mentioned that thing and got you thinking about that thing”
Edited 2018-07-09 20:34 UTC
They are seeing the writing on the wall.
32bit ^AuCs are already sold well below 1$ a pop.
Saveing 1-2c in this region is a big deal.
And once you have the new ISA implemented in silicon and dev-tools nothing is stopping you from deploying it in higher-end ^AuCs.
Edited 2018-07-09 20:31 UTC
… they fight you, then you win.
So they already ignored and laughed at RISC-V. I guess RISC-V will win soon.
I am hopefull.
That yet another standard ISA can replace many other standard ISAs? Perhaps nice. But I’m not sure RISC V is the one I’d like to see as the replacement.
While RISC-V cores might not show up in phones or computers (yet) it’s already had a very large impact in the market for deeply embedded cores.
There are a vast number of cores you don’t see in today’s electronics. Practically every piece of hardware contains one or more small cores whose purpose is usually to execute a specific task (usually implemented by custom hardware) or control other computing resources. Hard-drive and SSD controllers, GPUs, video encoders/decoders, network cards, cellular modems are a few examples of hardware components that often contain multiple dedicated cores.
These cores all have a few things in common: they are not particularly high performance nor general purpose, but they all come with custom hardware attached to them used to implement the hardware’s functionality.
These cores have traditionally come from a number of vendors, some of which you might never heard about such as Tensilica. ARM is one of those and has been pushing into this market with their Cortex R series.
RISC-V made huge inroads in this market in a very short time because of a number of factors: first of all these cores are custom so vendors don’t care about backwards compatibility. Adopting a new ISA isn’t an issue. These cores are customized so they will often ship with non-standard instructions and the RISC-V ISA has been designed as a module and extensible ISA making it perfect for this role. Finally, RISC-V is free, not only as-in-speech but also as-in-beer and already has a number of open-source cores available plus very modern tooling for adapting them and integrating them in new designs. As Microsoft found out trying to keep Linux outside of the server market it’s very hard to beat something that’s free.
Following the links on that website brings you to a page where ARM is offering free access to some of their designs for evaluation purposes. That really shows where RISC-V is hurting them with its free, open-source nature.
Anyway to get an idea of what I’m talking about regarding RISC-V’s success it’s enough to say that Western Digital has decided to switch all its internal microcontroller designs to RISC-V [1] and so is doing nVidia [2] [3].
[1] https://www.theregister.co.uk/2017/12/01/wdc_risc_v_edge_strategy/
[2] https://riscv.org/wp-content/uploads/2016/07/Tue1100_Nvidia_RISCV_St…
[3] https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDIA-Sijste…
For what it’s worth, ARM sees something we don’t see. I see future competition. I saw that in the Cheap Chi-PAD market years ago in RISC. I wonder what the stock market is whispering about?
The bit about fragmentation is true. Android has shown that fragmentation is a real problem when OEMs get to have their way with something open source. The only thing keeping Android together is the proprietary extensions known as GMS. RISC-V CPUs have no such thing.
Hm, though Chinese Androids don’t have proprietary Google services, and it’s still kept together… (at the very least, Statcounter counts Chinese users as Android
)
But the problem with android is exactly the fact that has so many parts closed and for that to happen google pretty much forked linux kernel.
Provided opensource drivers that could be easily ported from one android version to the next following the linux project standards that potentially could bring them in kernel, then android would be truely fragmented but in the way linux/bsd distros work, that is liberated from the choices made by someone else based on his priorities.
When did fragmentation of Android become an issue? Far as I can tell everything runs fine across Android devices from Google, HTC, Samsung, etc.
And since when is GMS the only thing holding android together? I’ve seen it used quite successfully on HMI’s (lexmark printers come to mind), automotive infotainment devices, and Amazon’s own Fire OS is GMS free and quite sucessful in fire tablets, sticks and STB’s.
The thing about Android that sucks is its goofy architecture of a non-standard Java VM on top of a forked Linux kernel. Back then it made sense when the mobile market was new, cpu and ram severely limited and multiple isa’s were kicked around besides arm. Now it’s all arm and the native interface is used extensively by cross platform frameworks which ironically negate the need for isa portability and thus the entire java stack which is dead weight at this point. I get why it was done, but the implementation was sloppy and short sighted; it feels like a hack. And it’s replacement, fuschia, isn’t exactly exciting from an OS perspective though it looks a lot cleaner than android.
PS. Also, being proprietary didn’t stop Windows Mobile/Phone from becoming sort of quite fragmented, across versions…
https://en.wikipedia.org/wiki/RISC-V#Competitors
Twelve undo ops in the last two days and counting! You can bet the mods will be keeping a closer eye on the RISC-V page until this gets settled.
RISC-V has a *lot* of momentum on the development side of the engineering pipeline.
Lots of people are looking at it from the “cheap licensing” perspective. Within the last year: Linux kernel support, GCC support, binutils support, LLVM support.
I think that from a business perspective, license cost is probably not a huge win for RISC-V. Designs like SuperH and UltraSparc already exist as open source hardware designs without license costs, and already have full support in Linux and BSDs (along with Illumos and several others for UltraSparc), and mature compiler toolchain support.
Edited 2018-07-10 21:53 UTC
With ARM one contacts them and get a license to a tested core often tested and optimized for the particular process one want to use. With RISC V one can download a non-optimized core using a non-standard development system and have to port it to the process of choice oneself. And then there’s the support from experienced people from ARM.
That can change in the future but it’s the current state of things. But even in the future there may be x companies providing support and testing of RISC V cores each of which have to pay the costs for that.
RISC V also supports customization which is a potential problem especially as the support companies probably want to make their offering stand out from the rest – a danger of fragmentation.
We’ll see.
ARM posts an article stating why they rock and a competitor doesn’t. Shocking, I know.
…. and it’s gone. Guessing someone at ARM realized how bad of an idea it was
Luckily the internet doesn’t forget:
https://web.archive.org/web/20180710130206/https://riscv-basics.com/
Edited 2018-07-10 19:35 UTC
Even folks at ARM thought this was a low blow according to this latest from El Reg: https://www.theregister.co.uk/2018/07/10/arm_riscv_web
Edited 2018-07-11 17:37 UTC
Never Risc, too masochistic only makes people use more high-level languages.
Rather Eisc, Extended Instruction Set, making ASM less masochistic, and reducing the want for using high-level languages.
From nyt.cloud : https://nyt.cloud/showthread.php?tid=2
“An OS is I/O via virtualized nodes, signal routing (scheduling etc) and usually a visual user interface. Programmed with a code-sequence of a certain dialect, usually Esthetic C. Peak jitter below 200^I 1/4 s converges to optimal. Streaming conventions could be implemented in a new standard, and protocol aswell, Could even be a whole new language with bytecode directly transported to CPU, combining scripting, interpreted, and native speed, by adding more instructions, getting several “clocks” in 1. Particulary since a lot of C is just assembly macros anyway, giving a less masochistic machine code. A lot of DSP are clear candidates, a 4pole filter (one input, one output), can be combined into a one clock operation aswell. JSR could take arguments. And ofcourse commonly used functions. Even larger things that has just one input, and one output. And this could even be done in parallel. Where instead of HTML commands, this for swiftness and low-latency. Why not even have parallel OS functions on multiple cpus, for common things like audio, and other low-latency I/O, getting better response overall. Buses could be parallelized on the mainboard aswell. And with all digital distribution goods marked with author, county/country, and automatically delegated a fair non-selfrejecting welldefined value – Delyar. Code components for OS, also being digitalgoods etc, decentralized independent author news, scholarship, media etc. Giving optimal network synergistics.”
Do YOU not want to rid yourself of “centrality makes things work?” De-centralized online work, for any place.
More at nyt.cloud BBS.
Peace.
Edited 2018-07-11 18:02 UTC