Nvidia, Western Digital Turn to Open Source RISC-V Processors (ieee.org)

An anonymous reader quotes IEEE Spectrum: [W]hat's so compelling about RISC-V isn't the technology -- it's the economics. The instruction set is open source. Anyone can download it and design a chip based on the architecture without paying a fee. If you wanted to do that with ARM, you'd have to pay its developer, Arm Holding, a few million dollars for a license. If you wanted to use x86, you're out of luck because Intel licenses its instruction set only to Advanced Micro Devices. For manufacturers, the open-source approach could lower the risks associated with building custom chips.

Already, Nvidia and Western Digital Corp. have decided to use RISC-V in their own internally developed silicon. Western Digital's chief technology officer has said that in 2019 or 2020, the company will unveil a new RISC-V processor for the more than 1 billion cores the storage firm ships each year. Likewise, Nvidia is using RISC-V for a governing microcontroller that it places on the board to manage its massively multicore graphics processors.

Comments

Stealth CPUs

[nateman1352]

So RISC-V's market is going to be mostly in non-exposed, internal processors running secret unreplacable firmware doing unknown things our GPUs and SSDs... Kinda like the Intel ME and AMD PSP. Are we supposed to feel good about that?

I find it ironic that the first thing that comes out of an open CPU design is more of the closed systems that supposedly RISC-V was designed to discourage. I don't think we can blindly apply the same approach to open hardware that was taken for open software, the economics of hardware production is very different than the economics of distributing software on the Internet.

Re:Stealth CPUs

[ledow]

Not being funny - but almost every chip you've ever used could have secret unreplaceable firmware and you'd know nothing about it.

This has been true throughout the history of computing, really. Sure, we know now that the Z80 was okay but we had no way of sensibly telling back then and it was all we could use.

Has anyone ever decapped a 386? What about those old AMI BIOS chips, sure we know what firmware can load onto them, but how do we know that's all that's in that chip and there isn't a secret ROM activated under certain conditions? We don't, until the chip is dead and out of the market, and even then we may never know.

Sorry, but "open" hardware of any significant specification is a fallacy... because you cannot verify it without an awful lot of very expensive equipment, even if it operates as if it were a RISC-V processor. Anything could be tapping into that core specification and leaking or acting on data secretly and you'd never know - it would just look and work like RISC-V chips all do to all outside appearances.

Honestly, if you think that nVidia using RISC-V is a bad thing, and isn't going to boost RISC-V adoption, reputation and development, or that your system is somehow going to avoid all such avenues of compromise, you're so wrong that it's laughable.

In fact, if anything, such code makes it incredibly easy to modify such a thing, use its name AND get away with it because nobody will ever check and/or ever be able to sue, that doing that to some big-name chip manufacturer.

Re: Why not others?

[Anonymous Coward]

Not necessarily.

Instruction set is far less important than toolchain in 2018.

In 1999 when I was working with ARM, Ericsson, Redhat, Opera and some others, we were investing very heavily in sorting out Linux on non-x86 processors. It was a disaster because so much of GCC, Linux, globe and binutils were optimized to death for x86.

We had our biggest challenge trying to make dynamic software (software with indeterminate memory requirements) operate on CPUs lacking an MMU. The web changed everything. Because none of the software vendors involved in the project could dictate the data sets to be consumed on the devices, we had serious memory fragmentationâ(TM)s issues. In a multi-process operating system that needed to support HTML in mail and in the web browser, Linux was suffering terribly on systems lacking MMUs.

We had a lot of other problems as well. GCC 2.91 was such a horrible codebase that had spaghetti everywhere in code generation because Stallman did such a painfully piss poor job in his design. Academics and companies everywhere had been spamming the codebase for years inserting AST reduction oriented optimizations which would be carried over to code generation. And since GCC didnâ(TM)t really have a maintainer in the sense that Linus maintains the kernel and CVS was also a nightmare, letâ(TM)s just say that GCC worked almost by accident.

Binutils was ugly too. Even today, binutils is not nearly what it should be. This is still a point of clear superiority for Microsoft. If for no other reason than that Microsoft made it a standard requirement of Windows DLL files to explicitly describe entry points which would permit far more intelligent linkers to be written.

Of course any language that actually needs a compile time linker in 2018 is a piece of crap by design. Most C/C++ code would be substantially better if all the source files were included from a single source file which then would be compiled and linked with clear entry point definitions by GCC or CLang instead of using a linker which lacks an AST.

So, the year is 2018 and both GCC and LLVM are highly retargetable. Binutils works much better than ever. Most JITs are well designed and easily portable. .NET Core run on x86, x64, ARM, ARM64, and apparently one of Microsoftâ(TM)s own CPU designs. Java runs everywhere. Oh and Mono can run pretty much anywhere a C compiler is available.

If you want to make a new CPU design, you need to port code generators and binutils to the new CPU and then porting Linux is pretty straight forward. Most of the platform native code in Linux these days is a single directory and that directory can be very lightweight. The DEC Alpha directory is ridiculously easy to port as itâ(TM)s mostly C code tweaked to produce good code. Alternatively, thereâ(TM)s the ZPU project which worked pretty well and is almost all C.

Last, you need to make a first stage bootloader and porting some UEFI code is easier than youâ(TM)d think.

Once those things are done, compiling Fedora or Ubuntu for the platform is pretty easy.

Iâ(TM)ve seen and end to end new CPU bootstrap on modern Debian by 5 developers in a month. It took a small team a year to implement optimizations since the CPU was an extremely different architecture, but it was done by a robot dink $10 a year company.

Now enter RISC V or other CPUs which already have a toolchain... there is no value in using ARM anymore since those toolchain are already stable and the platforms are also stable. They have some disadvantages, for example, theyâ(TM)re designed mostly for FPGA which means that design decisions have been made based on structure or LUs. Multipliers are probably based on stacked 9 but pyramid multipliers and dividers are probably suboptimal. As NVidia and others get their hands on it, they will contribute better ASIC blocks because they have the skill set required and also have more than enough of their own IP for those things... like reduced gate d