Given the momentum of Coreboot and Libreboot for having completely "free and open" architecture, how many years away are we from having commercial laptops available using RISC-V processors?
SiFive is shipping real silicon now. But it's a microcontroller implementation without a MMU, so not something you'd put in a laptop. They have a 64 bit synthesizable application core listed as a product too (and what appears to be HDL source for it on github), but I can't find a reference to anyone actually using it yet.
Probably many: the processor has to be made by millions (per model, not in total) to become reasonably priced, and it will still be slower and/or hotter than an offering from Intel who have spend untold man-years honing their architecture. Think Talos and IBM Power8, IBM being a serious force behind the Power architecture, with companies like Google among its customers.
RISC-V should have a key advantage and exploit it. IDK if the advantage of openness would be key for general-purpose laptops. Special laptops would probably be available but pricey; compare to other niche laptops, like highly-protected ones.
It's completely unreasonable to expect some underdog architecture to get anywhere close to the big ones, which have pured dozens of billions of dollars into research over decades to optimize their designs, tooling and fabrication.
A reasonable expectation is to get some low-end-ish CPUs out that might be on the same level (in terms of efficiency) than older, not really optimised ARM designs.
The biggest incentive RISC-V can offer is less legacy bullshit (like AArch64) and the fact that you don't have to pair royalties to ARM. Perhaps better standardisation of peripherals compared to ARM, so less time/money spent on integration, BSPs and stuff like that.
(And even then: Looking at recent POWER one can see that they can outperform related Intel offerings, while being drastically less efficient.)
What about the architecture/design itself, is any of that open? Could I find a design, send it off to china, and have them print off a couple hundred, even at a much higher price than some other processor?
Uh, well I guess...? But generally speaking IC fabbing doesn't happen in the "couple hundreds". If you really want that, you'd be looking at MPW (multi project wafers), were a bunch of designs are slapped on a single mask to spread yield and reduce per-party costs. (It pretty much works like PCB group manufacturing - a bunch of designs is slapped together 'til the maximum size of the fab, and then that is produced a couple times, e-tested, cut and bad pieces discarded. Everyone gets a couple copies of their design.)
Today it's a bit better, since eg. GF can (in theory) offer recent nodes (eg 22 nm and smaller), which wasn't something you could get ten years ago (back then that'd be 65 nm - most low-volume and custom stuff has been iirc 130 or 180 nm).
Not quite because you have a few more steps in the process after the design phase. For instance, you need to perform testing on the fabricated parts to determine if there are physical defects. That means creating the tests then paying for the testing to be performed at the fabrication place.
This is a fallacy that I see repeated about the quality of open products all the time.
It's true, Intel spends more money on R&D than RISC-V is likely to ever get. But that means next to nothing. When a huge, monolithic, management-driven company spends billions of dollars on something, a lot of those billions of dollars aren't being used very effectively.
Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev. Does that mean Windows is better than Linux? No; in fact, many people who have to use both would probably say the opposite. Why is Linux the OS of choice for many production applications in tech-savvy industries? It just works better and easier than the high-budget closed competition.
That's not to say that Linux is starved for funding; many large companies volunteer serious man-hours towards Linux development, because they want an open system that competes with (and beats) the crappy license-uncumbered alternative they would have to use otherwise. I expect the same thing to happen with RISC-V.
You also have this phenomenon in the open-source world where you have grad students, researchers, and enthusiasts embarking on ultra-high-risk projects that would never get funded at most companies, but pay off in a big way when they work. Now that we have an open ISA to work with, I fully expect a huge outpouring of automated synthesis software based on clever new ideas that beats the clunky stuff available in industry. We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System)Verilog). Give it some time for the silicon side of things to improve as well.
> Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev.
I'm not so sure about that, if we only consider the kernel (everything else would be a lame comparison). Linux likely has had many more paid devs than the NT kernel for the last 10-15 years, if not more.
> This is a fallacy
I also don't think this is a fallacy. Yes, of course a large company has a big head and spending is generally much less directed and efficient than in smaller companies (big news). But, lots of money also tends to pay great talents.
> that I see repeated about the quality of open products all the time.
... and I didn't mention quality anywhere.
As for open source: Software has near zero initial cost, iterations are extremely fast compared to anything manufactured and software engineering is an abundant skill. Hardware has high initial costs, high manufacturing costs, iterations take a lot of time and HW design encompasses quite some areas with a much smaller pool of people being able to do it.
Also, a massive company like Intel which sucks up talent all the time from the hiring pool has the resources to evaluate multiple avenues of optimization at the same time, pick what looks best, and iterate (which, pretty much, is what Intel has been doing ever since Sandy Bridge). Another example here would be Intel developing P4, a massive and staggering failure comparable to the PowerPC970 debacle (just bigger) -- and then pulling the Core arch out of the hat (which originates, guess what, from a different engineering team in a whole different branch of Intel -- again, resources!).
What I do expect here is that some companies might think they can influence an arch early on by diverting resources to it, to maybe save some money in the future (by not paying ARM anymore and other synergetic effects I mentioned above), and perhaps in the hope of getting a product that outperforms ARM/the competition in some metric(s).
(Also we have seen in the past in quite some instances that CPU design is a very delicate art and even pouring massive monies into it might actually not get you very far - see AIM/PowerPC [although it was quite successful in some niches] - or, on the other hand, that radically new architectures that might theoretically be better don't succeed, because you don't get the fab access, or tooling access, or software, see eg. Transputer and many related examples)
Well, on the mobile market Intel can't sell a chip if they staple money to it. So its not like Intel can just win everything all the time.
I don't think RISC-V will beat Intel on servers any time soon, I just hope it will establish itself in the market, get a foothold and then hope it openness will help it to grow.
I think you vastly underestimate the amount of money that was spent on Linux by various vendors. All the major companies in that wanted to sell servers or server related software essentially converged on linux as their platform of choice, since then IBM, RedHat, Google, Intel,... probably poured many billions more into Linux than Microsoft spend on the NT kernel.
Do you think a similar series of events are unlikely to play out when you look at the microprocessor field right now? I see similarities in that there essentially are no open source processor options (MIPS is the only one I can think of off the top of my head). Intel, AMD, IBM, TI, ARM, Qualcomm, Oracle, the lot of them are closed source and I would think the same benefits that came with an open source operating system would come with an open source processor architecture.
That said, I think the biggest difference is the parity between OSes in in the 70s vs ARM/Intel's current dominance. That's definitely going to make it more difficult to get people to adopt RISC-V. I'd imagine if there was any likelihood that IBM, RedHat, Google, or Intel could customize a RISC-V chipset to outperform (whether it's TWP, flops/sec, whathaveyou) any current offerings they'd pour dumptrucks of money into it just the same.
That's wrong. See OpenSPARC, where you can get the Verilog code for the T1 and T2 (Niagara-based) processors. (IIRC this was only one year after their commercial release).
SPARC in general is perhaps not a bad example, since the ISA is open and royalty-free and there are actually independent implementations (well, today only Fujitsu and ofc. Oracle).
It's quite interesting to see RISC raising again after it died rather harshly in the late 90s -- were literally every year a major manufacturer announced the end of an architecture -- and early 2000s (and remained dead rather firmly throughout the 2000s).
"We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System) Verilog).
"
As someone in the industry, I would have to disagree. I question this every time someone claims it's so awesome. None of those solutions can run simulations on the back annotated netlist . How do you design without a simulation tool that can work at every stage of the design flow?
RTL is a behavioral model. Post synthesis is the physical model. What do you think synthesis engineers do? Just sit around watching the tools run?
Things don't just work automatically. Some idiot can throw a design in that doesn't just synthesize.
After synthesis, your RTL becomes a gate level representation. You then place your logic i.e. Your memory logic near your memories, I/O logic near your pins etc.
You then make clock trees for your various clocks. You don't want related logic clocked by different parts of the clock tree. Once you have stuff physically located, you back annotate and do your static timing analysis.
You generally run simulation on the different stages of synthesis. Someone has to debug all these simulations. They never just pass.
There is a big difference between RTL and gate level simulation. A test passing in RTL is only the 1st stage. RTL doesn't have any wire models so no delays are in there. Gate level sims can run with delays in there.
Synthesis tools can also tell you it doesn't pass timing through static timing analysis but asynchronous parts of the design can't be analyzed. You need simulation there!
FE310 appears to outperform every state-of-the-art official ARM core (and perhaps every architecture-licensee core) in its class, with maximum stable clock speeds also much higher. BooM could be described as beating Cortex A15 and matching Cortex A53 (granted without a tapeout to prove it, only simulations).
Both of these designs are publicly available and under licenses which allow proprietary derivatives.
In every category; die area, power dissipation, total throughput, licensing cost, lead time, design flexibility, code density, technical debt, academic buy-in; real RISC-V cores which have been made in silicon are right-now beating ARM cores. At this point, ARM has but two things going for it: legacy and design maturity.
Once RISC-V designs are mature enough to be expected to run all general-purpose software correctly; there will be few other axes to compete on. RISC-V has an immense zero-day advantage in its clean, worldly design. I think it would be foolish to downplay the likelihood of great success.
> Probably many: the processor has to be made by millions (per model, not in total) to become reasonably priced, and it will still be slower and/or hotter than an offering from Intel
Why should R5 compete with the big players? It doesn't need to support the bloated OSes. It would be sufficient if Linux runs with acceptable performance. If Linux is able to run on a 12 MHz 68k [1], and SiFive already runs with 320 MHz [2] then I think we don't have to wait too much to get a suitable cpu, since it could also be a "weak" massive multicore, or we could stick multiple cpus together in a cluster.
By the way, Fabrice Bellard has already published a Linux/R5 emulator [3]. As for me, I am really excited about the R5 movement!
The distribution of Linux running on a 68k microcontroller is very different from the distribution running on a laptop. Desktop operating systems have to support a much wider set of software, often with quite intensive costs. How well do you think a web browser would run on a 68K?
There's a lot of embedded hardware where running Linux makes sense but running a browser does not. This market may be even larger than the desktop market.
OTOH this rules out laptops that OP wanted.
OT3rdH ARM started with devices like these in mind, but went all the way to pretty powerful, desktop-comparable machines like current smartphones.
I can imagine that government agencies of various countries would be quite interested in a completely open, inspectable, patent-unencumbered, hardware design. Gives you a bit of certainty that your key infrastructure won't be remotely disrupted by a hidden silicon circuit.
> How well do you think a web browser would run on a 68K?
It depends. If you want something like Opera or Firefox it won't run at all. If you are satisfied with basic functionality then you can use browsers like w3m which work well on low-powered devices. I think some developers will find a good compromise between performance and functionality.
And by the way, the very first R5 already runs with 320 MHz :-)
I assume you are referring to SiFive's HiFive board. It's certainly a great accomplishment. I'm actually a Ph.D. student in the UC Berkeley lab that produced the RISC-V ISA and interned at SiFive over the summer. I've worked on the RocketChip SoC generator they used to produce the RISC-V processor on that board. So I definitely want them to succeed.
But there is still a very long way to go. Clock speed is not the only determinant of processor performance. Even low end laptops like the ARM-based Chromebook have out-of-order processors. The Rocket CPU used in the HiFive board is an in-order machine. There is an out-of-order implementation called BOOM, but it is not quite as mature. Whereas Rocket has been taped out and validated many times in our Berkeley test chips and now in SiFive's commercial silicon, BOOM has not yet been taped out.
And I'll be the first to admit that RocketChip is not nearly as reliable as you would like for a consumer product. SiFive's done a lot of work to improve the system, but there are probably still outstanding bugs in the memory system.
> How well do you think a web browser would run on a 68K?
They run fine; I find Voyager 3 to be a bit bloated, but IBrowse runs quite well.
As others have mentioned, text-based browsers like w3m will probably be even smoother (although I usually run w3m via emacs-w3m, which would probably be much slower than using a normal terminal interface).
Not sure but I bet that ARM is starting to pay it some attention!
The great thing about being open is it allows academics and inventors to try out new ideas and have the ISA and associated "backend" flows just work without the worry of having to pay for licenses.
I'm not sure I'd describe Coreboot and Libreboot as "having momentum", at least not at the level where anyone is thinking about them while making PC hardware?
For RISC-V, the biggest issue seems to be a) actually designing a full chip with all the necessary peripherals (assuming just scaling the core bits is comparatively easy) and b) motivating someone to invest the fab time. I guess many potential commercial users will continue going with ARM, just because it is proven, designs and knowledge are available, ...
Before laptops, I'd expect more microcontroller-type stuff, where customization and license costs probably are more relevant, less complex periphery is used and the necessary fabrication capacity is more easily available.
I think (though I'm no expert) it's more likely that RISC-V will be in embedded devices and appliances around your house than in your laptop, where even ARM is a dubious proposition at this point.
Given the open IP and ease of customization, we might even see RISC-V inside peripherals or on the motherboard in a PC doing specialized tasks. But not as the main CPU.
Completele free and open is going to be difficult. Even the already existing and announced RISC-V boards you have non open hard or software involved. Its still going to be a huge step foreward.
But I think within the next year or two, we should get something that can run Linux resonable well and is mostly open.
Actuall production laptops is going to be difficult. Im rather waiting for "build it yourself laptop" kits, or something along those lines.
There are allready projects like it, for other hardware.
Maybe somebody from SiFive or lowRISC can comment. They probebly have the best information.
44 comments
[ 2.1 ms ] story [ 88.7 ms ] threadGoogle, HP, Oracle Join RISC-V
http://www.eetimes.com/document.asp?doc_id=1328561
Adapteva: Why I will be using RISC-V in my next chip
http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...
RISC-V should have a key advantage and exploit it. IDK if the advantage of openness would be key for general-purpose laptops. Special laptops would probably be available but pricey; compare to other niche laptops, like highly-protected ones.
A reasonable expectation is to get some low-end-ish CPUs out that might be on the same level (in terms of efficiency) than older, not really optimised ARM designs.
The biggest incentive RISC-V can offer is less legacy bullshit (like AArch64) and the fact that you don't have to pair royalties to ARM. Perhaps better standardisation of peripherals compared to ARM, so less time/money spent on integration, BSPs and stuff like that.
(And even then: Looking at recent POWER one can see that they can outperform related Intel offerings, while being drastically less efficient.)
Furthermore, research about architecture of chips has been published and can be used to create faster chips.
But I have to agree that it is not easy. Especially because chip design is partly generated by software and computed by many powerful machines.
Today it's a bit better, since eg. GF can (in theory) offer recent nodes (eg 22 nm and smaller), which wasn't something you could get ten years ago (back then that'd be 65 nm - most low-volume and custom stuff has been iirc 130 or 180 nm).
It's true, Intel spends more money on R&D than RISC-V is likely to ever get. But that means next to nothing. When a huge, monolithic, management-driven company spends billions of dollars on something, a lot of those billions of dollars aren't being used very effectively.
Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev. Does that mean Windows is better than Linux? No; in fact, many people who have to use both would probably say the opposite. Why is Linux the OS of choice for many production applications in tech-savvy industries? It just works better and easier than the high-budget closed competition.
That's not to say that Linux is starved for funding; many large companies volunteer serious man-hours towards Linux development, because they want an open system that competes with (and beats) the crappy license-uncumbered alternative they would have to use otherwise. I expect the same thing to happen with RISC-V.
You also have this phenomenon in the open-source world where you have grad students, researchers, and enthusiasts embarking on ultra-high-risk projects that would never get funded at most companies, but pay off in a big way when they work. Now that we have an open ISA to work with, I fully expect a huge outpouring of automated synthesis software based on clever new ideas that beats the clunky stuff available in industry. We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System)Verilog). Give it some time for the silicon side of things to improve as well.
I'm not so sure about that, if we only consider the kernel (everything else would be a lame comparison). Linux likely has had many more paid devs than the NT kernel for the last 10-15 years, if not more.
> This is a fallacy
I also don't think this is a fallacy. Yes, of course a large company has a big head and spending is generally much less directed and efficient than in smaller companies (big news). But, lots of money also tends to pay great talents.
> that I see repeated about the quality of open products all the time.
... and I didn't mention quality anywhere.
As for open source: Software has near zero initial cost, iterations are extremely fast compared to anything manufactured and software engineering is an abundant skill. Hardware has high initial costs, high manufacturing costs, iterations take a lot of time and HW design encompasses quite some areas with a much smaller pool of people being able to do it.
Also, a massive company like Intel which sucks up talent all the time from the hiring pool has the resources to evaluate multiple avenues of optimization at the same time, pick what looks best, and iterate (which, pretty much, is what Intel has been doing ever since Sandy Bridge). Another example here would be Intel developing P4, a massive and staggering failure comparable to the PowerPC970 debacle (just bigger) -- and then pulling the Core arch out of the hat (which originates, guess what, from a different engineering team in a whole different branch of Intel -- again, resources!).
What I do expect here is that some companies might think they can influence an arch early on by diverting resources to it, to maybe save some money in the future (by not paying ARM anymore and other synergetic effects I mentioned above), and perhaps in the hope of getting a product that outperforms ARM/the competition in some metric(s).
(Also we have seen in the past in quite some instances that CPU design is a very delicate art and even pouring massive monies into it might actually not get you very far - see AIM/PowerPC [although it was quite successful in some niches] - or, on the other hand, that radically new architectures that might theoretically be better don't succeed, because you don't get the fab access, or tooling access, or software, see eg. Transputer and many related examples)
I've spent my computer hobbyist life betting against Intel and losing -- 6502, 68000, PowerPC.
I don't think RISC-V will beat Intel on servers any time soon, I just hope it will establish itself in the market, get a foothold and then hope it openness will help it to grow.
That said, I think the biggest difference is the parity between OSes in in the 70s vs ARM/Intel's current dominance. That's definitely going to make it more difficult to get people to adopt RISC-V. I'd imagine if there was any likelihood that IBM, RedHat, Google, or Intel could customize a RISC-V chipset to outperform (whether it's TWP, flops/sec, whathaveyou) any current offerings they'd pour dumptrucks of money into it just the same.
That's wrong. See OpenSPARC, where you can get the Verilog code for the T1 and T2 (Niagara-based) processors. (IIRC this was only one year after their commercial release).
SPARC in general is perhaps not a bad example, since the ISA is open and royalty-free and there are actually independent implementations (well, today only Fujitsu and ofc. Oracle).
It's quite interesting to see RISC raising again after it died rather harshly in the late 90s -- were literally every year a major manufacturer announced the end of an architecture -- and early 2000s (and remained dead rather firmly throughout the 2000s).
As someone in the industry, I would have to disagree. I question this every time someone claims it's so awesome. None of those solutions can run simulations on the back annotated netlist . How do you design without a simulation tool that can work at every stage of the design flow?
RTL is a behavioral model. Post synthesis is the physical model. What do you think synthesis engineers do? Just sit around watching the tools run?
Can you explain briefly for someone not in the industry why it's not that simple? This seems like it should be a 100% automatable process.
After synthesis, your RTL becomes a gate level representation. You then place your logic i.e. Your memory logic near your memories, I/O logic near your pins etc. You then make clock trees for your various clocks. You don't want related logic clocked by different parts of the clock tree. Once you have stuff physically located, you back annotate and do your static timing analysis.
You generally run simulation on the different stages of synthesis. Someone has to debug all these simulations. They never just pass.
There is a big difference between RTL and gate level simulation. A test passing in RTL is only the 1st stage. RTL doesn't have any wire models so no delays are in there. Gate level sims can run with delays in there.
Synthesis tools can also tell you it doesn't pass timing through static timing analysis but asynchronous parts of the design can't be analyzed. You need simulation there!
Both of these designs are publicly available and under licenses which allow proprietary derivatives.
In every category; die area, power dissipation, total throughput, licensing cost, lead time, design flexibility, code density, technical debt, academic buy-in; real RISC-V cores which have been made in silicon are right-now beating ARM cores. At this point, ARM has but two things going for it: legacy and design maturity.
Once RISC-V designs are mature enough to be expected to run all general-purpose software correctly; there will be few other axes to compete on. RISC-V has an immense zero-day advantage in its clean, worldly design. I think it would be foolish to downplay the likelihood of great success.
Why should R5 compete with the big players? It doesn't need to support the bloated OSes. It would be sufficient if Linux runs with acceptable performance. If Linux is able to run on a 12 MHz 68k [1], and SiFive already runs with 320 MHz [2] then I think we don't have to wait too much to get a suitable cpu, since it could also be a "weak" massive multicore, or we could stick multiple cpus together in a cluster.
By the way, Fabrice Bellard has already published a Linux/R5 emulator [3]. As for me, I am really excited about the R5 movement!
[1] http://www.bigmessowires.com/68-katy/
[2] https://www.crowdsupply.com/sifive/hifive1
[3] http://bellard.org/riscvemu/
OTOH this rules out laptops that OP wanted. OT3rdH ARM started with devices like these in mind, but went all the way to pretty powerful, desktop-comparable machines like current smartphones.
Open ISA and open hardware should be a major security concern for most countries.
http://www.lowrisc.org/
It depends. If you want something like Opera or Firefox it won't run at all. If you are satisfied with basic functionality then you can use browsers like w3m which work well on low-powered devices. I think some developers will find a good compromise between performance and functionality.
And by the way, the very first R5 already runs with 320 MHz :-)
But there is still a very long way to go. Clock speed is not the only determinant of processor performance. Even low end laptops like the ARM-based Chromebook have out-of-order processors. The Rocket CPU used in the HiFive board is an in-order machine. There is an out-of-order implementation called BOOM, but it is not quite as mature. Whereas Rocket has been taped out and validated many times in our Berkeley test chips and now in SiFive's commercial silicon, BOOM has not yet been taped out.
And I'll be the first to admit that RocketChip is not nearly as reliable as you would like for a consumer product. SiFive's done a lot of work to improve the system, but there are probably still outstanding bugs in the memory system.
They run fine; I find Voyager 3 to be a bit bloated, but IBrowse runs quite well.
As others have mentioned, text-based browsers like w3m will probably be even smoother (although I usually run w3m via emacs-w3m, which would probably be much slower than using a normal terminal interface).
The great thing about being open is it allows academics and inventors to try out new ideas and have the ISA and associated "backend" flows just work without the worry of having to pay for licenses.
For RISC-V, the biggest issue seems to be a) actually designing a full chip with all the necessary peripherals (assuming just scaling the core bits is comparatively easy) and b) motivating someone to invest the fab time. I guess many potential commercial users will continue going with ARM, just because it is proven, designs and knowledge are available, ...
Before laptops, I'd expect more microcontroller-type stuff, where customization and license costs probably are more relevant, less complex periphery is used and the necessary fabrication capacity is more easily available.
Given the open IP and ease of customization, we might even see RISC-V inside peripherals or on the motherboard in a PC doing specialized tasks. But not as the main CPU.
But I think within the next year or two, we should get something that can run Linux resonable well and is mostly open.
Actuall production laptops is going to be difficult. Im rather waiting for "build it yourself laptop" kits, or something along those lines.
There are allready projects like it, for other hardware.
Maybe somebody from SiFive or lowRISC can comment. They probebly have the best information.
^ Related discussion from when this port was submitted.
RISC-V did make it to llvm[2], with there being healthy development there. I remember Fedora running on RISC-V successfully.
Anyone know what happened with the whole copyright assignment problem?
[1]:https://news.ycombinator.com/item?id=12633037
[2]:http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748....
EDIT: I found a comment[3] in the old submission which answers my question.
[3]:https://news.ycombinator.com/item?id=13385968