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/
Well... considering nVidia IS considering RISC-V, shouldn't that tell those others you mention that they might be missing out?
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.
Nvidia's Risc V CPU is intended to replace Nvidia's Falcon (FAst Logic CONtroller) CPU, which is the internal controller of their graphics cards.
I think the old Macs were like that and even though they ran at 1/1000th the speed, they booted 100 times faster.
For a very short time in history Apple had a CPU that with the correct software and lot of skilled work could do tasks at a good speed.
The Intel went full fast.
Domestic spying is now "Benign Information Gathering"
If you want open hardware then you're going to have to buckle down and start designing and writing drivers for it yourself. Sandisk/AMD/Intel/NVIDIA/WesternDigital/Seagate/RAID manufacturers/Creative clearly don't give a shit about making open source hardware. Now many of their patents and methods have already expired so it should be possible to raid the patent libraries to make some pretty reasonable hardware, but the software is going to all have to be written from scratch as existing code is under copyright protection.
Why not SPARC?
Kriston
Intel excels at main memory access performance and cache utilization due to variable length instruction. Most ARM processors have relatively poor main memory access performance even when the run at higher core speeds.
Why do Qualcomm and Samsung use ARM for their mobile chips (Exynos and Snapdragon) instead of RISC-V? Superior performance? Price?
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
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
Assuming you meant workloads and not warlords, it still does in terms of processing power per watt in some situations if you are talking about t-series.
Personally, I would love more server manufacturers to sell "the most power you can get in a box for 100W/200W", for which I use Sparc, but would be happy to use Arm or Mips or Risc-V. (I use very little floating point and quite a lot of I/O bandwidth).
Granny always told me not to put my eggs in a basket called x86.
Sent from my ASR33 using ASCII
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.
I think the most common computer at a Warlord's base is going to be the Toyota ECM. Without that, your technicals won't have good traction control or extreme weather performance.
He said he's drunk, can't you even read?!
Thy are also free to use AMD there is an existing expertise so it should be easier to use than something new.
It's outrageous you can copyright an instruction set. Its a language, and you shouldnt be able to copyright languages, protocols, etc. Didnt transmeta and several other companies implement x86 without paying Intel a fee? It seems the fee should only be for licensing Intels schematics. but if your going to use all of your own electronic designs it should be fine to support an existing ISA. ISAs are not difficult to implement. In fact you can create one in an hour. This certainly is not worth millions of dollars of fees. 99.9% of the effort to create your own CPU is in laying out the electronics, making the masks, and all of the difficulties of being able to fabricate the thing. Maybe I am missing something here but something does not make sense.
It helped that a lot of the OS was in ROM.
https://en.wikipedia.org/wiki/Inverted_totalitarianism