Also popular here because some folks imagine a new ecosystem of cheap Rpi type boards with no magical binary blobs. See, for example, lowrisc.org (though they seem far from shipping)
I thought that the biggest blob in most linux systems is GPU driver and RISC-V doesn't solves this.
https://www.heise.de/select/ct/2016/8/1460193213013079/conte...
It makes no sense to counter a hypetrain with intelligent arguments. :-)
Of course, you are right.
On-GPU firmware is not that interesting or concerning, you can consider it part of the hardware.
So people don't like it if kernel drivers are closed source, but if all the functionality is moved to firmware and the open kernel driver just pokes the closed firmware that does all the work it's fine? What? How does that logic work?
It depends on how it can communicate with the external world. If it only eats numbers and draws pixels, then no problems, but if its driver nature (ie, running at higher privileges than anything including root/administrator) allows it to create a covert channel with other hardware (say a network chip) and send vital information to the outside world, then it becomes a huge potential vulnerability. In open source systems, CPU/GPU/system chipsets firmware and closed device drivers are the places where malware can hide unnoticed for ages, and incidentally the one where it can do the most damage due to the aforementioned privileges, therefore those should be the first parts of a system in which we should demand for total openness.
A simple program with no access to files (therefore considered safe) reading the CPU load and populating a remote graph with numbers can become an effective spying tool if paired with another seemingly innocuous program which has no network access (considered safe as well) but reads files and busy loads one CPU core with values resulting from some encoding of the data it reads. They're 100% safe by themselves, but once paired (say because they're written by the same entity, or different entities obeying to the same government/s) they can exfiltrate information pretty easily. Back on the firmware topic, we can't know if there any seemingly unrelated device drivers talking each other unbeknownst of the system administrator, but should they do, that would be the most dangerous backdooring toolkit ever conceived. Until they stay closed, there's no way to know if they do other things.
At any rate, I hadn't heard about anyone trying to make a completely open GPU. That would be cool though.
If you are jumping on risc-v to save money you have your priorities very wrong. On the other hand if you are Huawei and can't do business with arm...
Furthermore, those 1.5% covered more than just the CPU (peripherals, buss technologies, patents, manufacturing know-how).
I'm not saying WD is wrong, but I think they are overestimating how much they can save. This is probably just to get a better deal from arm.
That would be enough people for a very advanced chip, but WD doesn't need to build the next supercomputer. Instead, they want a chip customized to handle their specific workload with high throughput and probably some specialized instructions to put some algorithms in hardware. Moreover, their RISCV chip design expense should reduce over time both because they don't need to change chip micro-architectures very often and because as more companies switch to shared, open hardware, the costs are reduced
Another example is Nvidia. They continue to hold an ARM license for several ARM designs and another license for their own custom Denver/Carmel designs. Despite this, they still opted to use RISCV in their GPUs.
These companies manufacture chip designs for a living. They certainly understand the costs involved and have determined the immediate and long-term costs are lower vs the provided benefits.
Does that change with ARM? If you're licensing the ISA, or even bits of HDL, you're still fabbing your own stuff, right?
If it was the choice between pre-made RISCV and pre-made ARM, then the licensing could play into a cost difference between models, but otherwise they'd both be pre-fabbed, ready-to-use-products?
I think there is some merit to risc-v but people pushing hard for it's use RIGHT NOW don't seem to understand the challenges of SoC design and manufacturing.
Some of the engineers thought making our own CPU designs was a stupid idea and some thought that switching to ARM designs was a stupid idea. The only fact I have is that our CPU designs were not the main cause of bugs in our chips. If you asked the digital designers, they'd say things like, "Why are software engineers so interested in CPU designs. The kinds of embedded CPUs we need are easy to design. Implementing a correct power management state machine is hard. Implementing an efficient WiFi PHY is hard. Get off my lawn..."
Some problems with putting ARM CPUs in our chips were: a) integration engineering costs (ie find a way to multiplex some existing pins on the package with the jtag debug port), b) having to do price and contract negotiation with ARM (that part of the company was less efficient than the digital engineering team), c) finding that the change you wanted to make to the chip was incompatible with the ARM contract you'd just spent 6 months negotiating.
Not trying to be hostile, just pointing out how costly "let's design our own soc, how hard can it be?" is.
I know a few people who joined ARM after CSR closed down but that could be just some offices shutting down.
(not an arm employee, btw)
That said the chips certainly did there job at a good price point once you got everything stable and fixes made to the binary blobs that you had no way to debug.
Yep. Sorry about that. Not that it was my fault. Anyhow, I guess my belief is that a similar company to CSR could put RISCV cores in their chips now, which would avoid the problem you describe and some of the problems I described with using ARM.