Slashdot Mirror
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.
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.
license their tech to a Chinese company? At this point I think AMD is big enough and advanced (pun intended) enough to stand on their own. I'm sure they have to license patents from Intel, but last I checked that was required by law (that's kind of the point of patents) and I'm sure they've got their own patents to license.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I think the article should say "[W]hat's so compelling about RISC-V isn't just the technology".
The instruction set is modern and tight, made to be easy to pipeline and scale. There are RISC-V chips that rival ARM in performance / watt at the same manufacturing process.
The ISA is modular so engineers could strip out the parts they don't need and get more power savings that way.
But I would not say that it is mature yet. There are important parts, such as the memory consistency model that I have not yet seen set in stone.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
The greater the return!
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.
RISC really shined during a brief period where there was an extreme premium on getting every part of a CPU on a single die, and memory speeds weren't totally out of wack with CPU speeds. That favored its approach of the minimum number of transistors on a chip and using memory a bit more wastefully than older approaches grounded in the days when memory was both slow and very expensive, e.g. during the transition from core to DRAM.
Now, of course, we can put relative to those days an infinite number of transistors on a die, and memory speeds are again out of wack with CPU speeds. We've got plenty of main memory, but cache is still dear. To the point that pretty much any execution micro-optimization that causes your working set to exceed a level of caching ends up running slower. And Intel's IA-32 macro architecture didn't make any fatal mistakes like e.g. the VAX's so that it could be made to run quickly without insane effort.
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
Yes, RISC-V is lowend for now...
But ARM was always lowend, and so was x86, support from a large number of vendors and huge sales volume push the lowend up while the highend architectures have all failed or been pushed into tiny expensive niches.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Indeed. The higher transistor count needed to quickly decode Intel's variable length instructions is now trivially affordable, so ARM processors don't gain much there, and tend to lose it when memory hierarchy performance is factored in.
Except that we should note that "lots more" transistors to decode or otherwise make a CPU run quickly is harmful for energy usage, so ARM still wins in mobile (although some of Intel's issues there are due to it just not seriously pursuing that potentially high volume but low profit margin niche, including developing low cost fab nodes (possibly low power ones as well), note their fairly recently still using TSMC for Altera's lowest cost line of FPGAs). And being able to run at high clock speeds is generally less desirable in mobile, again to conserve on overall system energy consumption, nothing like Moore's Law has every applied to batteries.
Because sane people do not wish to be on the same planet as Larry Ellison.
Sent from my ASR33 using ASCII