Riding the RISC-V wave
semiengineering.com
semiengineering.com
The end goal would be to make ARM+other GPU technical viable but non copetive so that most customers will have to buy ARM+Nvidea to be competive leading to a hard to touch quasi monopoly of Nvidea for android phones (maybe except cheap ones) and and embedded ML.
Oh and at some point they probably would restrict new "custom silicon" contacts to prevent something like Apple silicon from happening again.
I'm willing to bet this is entirely around controlling their own future, not changing the way ARM is licensed. With Intel at least acting like they're going to REALLY try to enter the GPU space at this point, Nvidia needed to acquire AMD or ARM to solidify their position. AMD was probably the preferred path but divesting of the GPU business would've been difficult if not impossible with all the embedded graphics chips they've put onto the market. Plus I would imagine the IP pollution potential would open them up to lawsuits from whoever acquired the GPU assets. And if Intel were to be the acquirer (seems like the most likely suitor) - they'd actually have to be seriously concerned about their GPU leadership.
Technically superior, yes. But at a price point for even the high-end flagship phones? No. The Tegra are quite expensive.
https://www.droid-life.com/2015/11/17/nvidia-releases-the-sh...
You don't see Qualcomm out there making their own phones because they couldn't sell the chips they manufactured.
Based on... what? The only reason there wasn't an X1 tablet was because of the exclusive deal with Nintendo.
I don't see Qualcomm out there making phones because they make far more money extorting others. If they didn't have the ability to push their patent portfolio down the throats of anyone who wants to make a phone that can actually connect to a cellular network, they would absolutely be making their own handsets.
The fact that it's the same innards as an original Shield tablet, just rebranded and launched for a bargain basement price on what was supposed to be a flagship quality chip? A chip that didn't get any major users?
And can you cite this exclusive deal with Nintendo from somewhere other than a rumor site?
> I don't see Qualcomm out there making phones because they make far more money extorting others. If they didn't have the ability to push their patent portfolio down the throats of anyone who wants to make a phone that can actually connect to a cellular network, they would absolutely be making their own handsets.
Why would that stop Qualcomm? If they have so much pull and vertical integration is what you want to be doing, then why haven't they done that in addition to selling their chips to others? It makes sense for Samsung since they literally manufacture a great deal of the screens and other components anyway, and for Apple since they have the margins to pull it off. But it doesn't really make sense for anyone else except to dump extra inventory that you couldn't sell as glorified dev kits.
In reality it's not winning in the mobile SoC market and owning Arm will enable it to hinder its competitors.
What exactly would their end-game be if ARM were acquired by say... a Chinese firm who DID decide to end licensing terms. Then what?
The problem is that controlling its own destiny gives it control over all its competitors destinies too - and that's not good. I have nothing particularly against Nvidia btw - the same issue would apply for any major SoC designer buying Arm.
What? No they do not. All Tegra CPUs are pretty damn lousy compared to contemporary alternatives when fit inside cellphone power envelope.
I believe that's where they'll hit the hardest. They can keep GPU at the same competitive state, could even make it "easier" for competitors, but if they get a bit of advantage over ML, that's where phones and everything else will be kind of forced to go Nvidia for both GPU and ML.
They don't have much competition as far as I am aware in that sphere, so they'll be able to argue that GPU were able to work with ARM without issues, even did X and Y to make it even easier for them while masking that they made it harder for everyone to compete on ML.
That's just conspiracy theory though, I still have hope they understands the value of an open environment like ARM and buying them was just a way to protect that environment.
Having Ubuntu on Desktops, RedHat on some corporate servers, Debian on others, Pine in VM's, raspberian on rpi's, openwrt on routers, Android on mobile phones, yada, yada, yada doesn't seem to have done Linux any damage. Quite the reverse. It's almost certainly a major factor in Linux wiping the floor against Windows. Microsoft doesn't have the manpower to turn Windows into something that address all those niche's. While it's true Microsoft have succesfully defended the desktop for now, they have in the mean time lost the war on every other front.
So, one can argue that the quality of Windows is changing, but building an operating system is no easy task. And Microsoft’s commitment to backwards compatibility is quite an achievement.
I don't mind, really, Windows 7 isn't even supported anymore. But Linux would install without a second thought and run the most updated version of almost everything (excepting things like packages not compiled for arm yet or something). Saying Windows should get lots of credit for backwards compatibility feels a little disingenuous when compared to Linux... which actually still runs on hardware from the 90s.
When people talk about Windows backwards compatibility they're mostly referring to running on apps on a new OS, not new apps running an old OS. I bet you could get very old versions Microsoft Office running on Windows 10. I've run Visual Studio 6.0 on a Win10 machine no problem. And yeah linux nowadays has a lot of drivers included with the kernel (I've bene shocked at some of the supported hardware) but vendor provided drivers of often super outdated. I have a decent chance trusting old driver binaries to run on windows. On Linux you likely have to be a driver developer yourself to just to get some vendor's driver source for an old 2.X kernel to compile, let alone run.
It has been a very, very long time since I've run into hardware that I had any incentive to install vendor provided drivers for in order to get a computer running with Linux, with the exception of VMWare kernel modules and NVidia drivers, but Nvidia cards still run with noveau so the computer will still work so that you can get the proprietary drivers. And VMWare is proprietary software, so that's no surprise.
I just have not done it for actual hardware other than Nvidia graphics cards in at least a decade. Maybe I've gotten lucky in the hardware I've bought or something, but I haven't had any drivers broken badly enough that I even would file a bug report except for my Nvidia proprietary driver that is buggy as heck.
But I accept that my experience is also an anecdote.
Of course Windows excel in apps backward compatiblity better than Linux (it's not about hardware). You can't just run old Linux games CD. You would have a better time using Wine with Windows version of the game.
> Ubuntu on Desktops, RedHat on some corporate servers, Debian on others, Pine in VM's, raspberian on rpi's, openwrt on routers, Android on mobile phones, yada, yada, yada
?
Red Hat is IBM nowadays.
Android might just be running on Fuchsia in a near future, and Linux kernel is not exposed to userspace, so it is pretty much irrelevant what Android runs on.
BSD, NuttX, RTOS, Azure RTOS, Green Hills, QNX, Zephyr, Harmmony OS, yada, yada, yada
I doubt Shuttleworth would consider selling anyway, least of all to Microsoft.
As long as the system collects and exfiltrates data without me explicitly allowing this, and does OS updates just before somebody wants to give a presentation, it is not the feel of running Linux. The feeling of running Linux is the user being in control of his/her device and his/her data. A 1990 MS DOS installation is closer to that feeling than any recent Windows.
So basically that leaves IBM and Microsoft calling the shots what Linux is supposed to be.
Plus in what matters in embedded space I will give about 10 years for MIT OS like Azure RTOS and Zephyr to wipe the floor of GPL based Linux distributions.
Never heard of Azure RTOS before, but it seems MS went and bought Express Logic. That's quite big.
But it doesn't seem to be MIT?
https://github.com/azure-rtos/threadx/blob/master/LICENSE.tx...
Either they're doing something unique enough in hardware that you pay for the development seats and special interfacing hardware, or you go with a generic part and get to use all the cheap/opensource tools.
RISC-V strategy make sense, first standise the core that allows you to run all tooling. At necessary thigns like floats and so on. And the move on into more interesting extentions like Vectors.
If a company does something unique, the can take the standard compiler and have standard way to add an extra extention.
Of courese because the world is not perfect you will have some sudo standards and companies that have their own version of some of these.
Profiles is a way to manage that and to find configuration of extentions that often work together for desktop, embeeded or something like that. Seem relativivly well thought out for something that has such braod application.
In theory yes, what happens in practice is for your application, you only need a few operations from N different extensions and now you have to implement all those extensions, if you want to be compatible.
The alternative is you develop the few ops as custom isa and break compatibility.
So you can either be non compatible and lean or compatible and bloated. Guess what will processor/chip designers will prefer given the energy constraints.
> So you can either be non compatible and lean or compatible and bloated.
That's a waste overstatement. The profiles are optimized for specific fields already and you have to evaluate if you want to take advantage of all the software and infrastructure around that profile of if you want to redo all the work just so you can cut out a few specific instruction.
You act like as if every company makes its own costume chips with the minimal set of instructions they need, but that is about 0.01% of the market or less. For the waste majority of use case simply not required and standard embedded profile is perfectly reasonable. And the commercial chips and commercial software will also target that profile.
If you really want to redo everything with your costume chips and compilers, software and so on then that's your choice and RISC-V should not prevent that.
It's Free as in freedom, not price. Think of it as unencumbered. Risc-v is not open source like software, there are some open sorce implementations though.
Here's the full quote from the article:
> “Often people say, ‘Open source, it’s free.’ But it’s not free,” says Dominic Rizzo, project lead at Google and project director for OpenTitan. “This is why we find the most successful open-source projects are ones where people have a long-term vested interest and are working together in a collaborative fashion. This contrasts to the style of open source where people developed something and kicked it over the wall as open source.”
But the specifications themselves seem free as in freedom (CC-BY-4.0):
They also have private mailing lists, but I agree, it is certainly FOSS.
Open always wins....given enough time. No single company can compete with a collective open ecosystem at scale.
Providers of RISC-V HW or Designs, like Alibaba, SiFive or Western Digital, do lots of testing too.
It would be like saying that Linux does not provides the quality of commercial closed OS (kernel), this is just wrong in multiple ways:
1. Linux is also sold as base of some commercial OS (e.g., RHEL, SUSE)
2. Lots of commercial companies revenue depends directly or indirectly on it, so there's a massive testing effort. In it's sum it so massive that I cannot believe that it's matched by any closed commercial kernel (no actual numbers here, sorry, this is really just personal ball parking).
The same can happen to RISC-V, the combined testing effort can easily outnumber the one of ARM in the future.
So while yes, testing and verification is not free, it is just not an argument at all against any open CPU design, be it openPOWER, RISC-V, open MIPS, ... Rather, it speaks again for openness as combined test effort will be hard to be matched by a single closed player.
Open source CPU design is fundamentally different than open source software design. In the latter costs are extremely low - just the cost of a computer per developer. That developer's computer need not be replaced for years. There is no significant incremental cost for a software bug - just recompile and in a few minutes you're off to the races with a new executable which can be distributed over the internet for next to nothing. Contrast that with CPU design - every time a hardware bug is found you'd have to fix the design, verify it in software simulations, fabricate a new wafer, package it, install it in test hardware, and then perform hardware verification. This is 5 to 6 orders of magnitude slower and more expensive than software. Sure, corporations can perform this open CPU design, verification and manufacturing function. But in the end for a CPU to have a certain level of speed and reliability, you'd have to spend at least the same amount of money as the commercial CPU makers. Companies that produce an open source CPU chip are incurring huge monetary risks - and would have to be compensated for this risk if their chips have bugs and cannot be sold.
The only way for an open source chip design to be remotely competitive would be if they were to embrace FPGA technology. But FPGAs run 4 times slower than purpose built ASICs and are at least 10 times more expensive per unit in volume.
This also means you'll see more and more vendors of RISC-V cores and RISC-V verification suits. Chip designers are just as willing to pay a license and support fee to these as to ARM, as long as the cost is lower. So I'm absolutely certain that you'll eventually see RISC-V cores verified to the same level as ARM.
Also remember that open source RISC-V cores is more likely to get free verification efforts from universities, students and hobbyists.
> The only way for an open source chip design to be remotely competitive would be if they were to embrace FPGA technology. But FPGAs run 4 times slower than purpose built ASICs and are at least 10 times more expensive per unit in volume.
Ah, yes, but you can verify on FPGA and ship on ASIC. That's why even hobbyists can now work on developing and verifying RISC-V cores.
These days it's really not that hard to verify a microcontroller-level CPU core. It might take a long while until you get a state-of-the-art superscalar multicore RISC-V CPU for servers and desktops, but I think it'll eventually happen for RISC-V the same way it did for ARM. Hell, the open-source designs are already there, and they're pretty well verified, which is way further than ARM was at the same stage (they had zero incentives to do anything that wasn't commercially viable after all, unlike the research communities developing RISC-V cores), you just need further optimization and verification.
A true alternative to ARM need to come out of China.
https://www.reuters.com/article/us-usa-china-semiconductors-...
U.S.-based chip-tech group moving to Switzerland over trade curb fears
SAN FRANCISCO/WASHINGTON (Reuters) - A U.S.-based foundation overseeing promising semiconductor technology developed with Pentagon support will soon move to Switzerland after several of the group’s foreign members raised concerns about potential U.S. trade curbs.
Ironically these kind of decisions might just give enough boost to Tizen and Harmony to hit hard Android's hegemony.
[0] https://www.european-processor-initiative.eu/
[1] https://riscv.org/2019/08/how-the-european-processor-initiat...
Better PR is nice but it doesn't change the underlying incentives.