>"As just one example, a recent microprocessor design using
RISC-V has a clock speed of 5 gigahertz,
well above a recent, top-of-the-line Intel Xeon server chip, E7, running at 3.2 gigahertz.
Yet the novel RISC-V chip burns just 1 watt of power at 1.1 volts, less than one percent of the power
burned by the Intel Xeon.
[...]
"It's kind of amazing," said David Patterson, a professor at the University of California at Berkeley who helped create RISC-V, in an interview with ZDNet, describing his impression of a demo he was given of the chip recently. "I think IBM mainframes have a 5-gigahertz product that's liquid-cooled, and takes 100 watts" to run.
"I've also heard some impressive numbers around people doing
FPGAs, around 600 megahertz,"
said Patterson, referring to re-programmable chips. "For a soft core, that seems pretty fast."
[...]
Because of the simplicity of the instruction set of RISC-V, Micro Magic was able to have its chip produced using a standard silicon wafer with no special tweaking. That makes it possible to use what is called a shuttle run, where the chip is grouped together in the manufacturing process with other people's chips, on the same wafer. That can be vastly cheaper because the wafer's cost is shared among so many parties."
Unfortunately this sounds too good to be true. Based on what the article said a single core is about as fast as all cores on the Raspberry Pi 3 combined [0] while still consuming less power.
Why are there no other embedded processors with similar efficiency and performance? If you can get an edge through a bespoke ISA then there would be at least a few manufacturers producing such a highly efficient chip with their own proprietary ISA. Hardware companies would then try to make it work despite the proprietary ISA because the benefits are too great to pass up.
Isn't the point to be able to produce more performance at lower clock speeds, using OOB execution, paralellism, to use less energy and produce less heat?
Since there is an upper bound of clock speeds that can be done at room temperature, and high clock speed produce tons of heat. But this article is like OMG 5GHz!!!!
In this M1-related video[1], it appears that when the very first ARM chip was tested it showed zero power (or powered through I/O pins?). I suppose this time there could have been a simulation-based prediction in advance.
It doesnt actually explain wether or not its truly an achievement. any tiny single core can reach 5 ghz at low power because you have to worry less about signal propogation problems. the 26000 score of the xeon is also a single core but it comes with the obvious caveat that a xeon does slightly more. I'm sure Coremark is a decent benchmark but it is unfair towards the xeon usecase.
"EEMBC’s CoreMark® is a benchmark that measures the performance of microcontrollers (MCUs) and central processing units (CPUs) used in embedded systems. Replacing the antiquated Dhrystone benchmark, Coremark contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC (cyclic redundancy check). It is designed to run on devices from 8-bit microcontrollers to 64-bit microprocessors."
Maybe someone has a list of OTHER small embedded microcontrollers to compare with this processor? Still fun to see risk-v in the news again.
Me, I'm ready to see a Risc-6 fork. By keeping most of the details, and just fixing certain unfortunate early choices, it could benefit from almost all the work done on RISC-V, but outpace it in performance.
RISC-V embodies many unnecessarily weird and costly choices that would be easy to patch if you were not obliged to retain bitwise compatibility. At the same time, it benefits from a great deal of verification work that could itself be retargeted relatively cheaply, and applied to the forked ISA. Similarly, implementations could be forked with minimal effort, and get a very cheap performance boost. Compiler code generators would also be easy to fork.
Pretty comprehensive lists of small but costly design booboos have already been published.
Probably the biggest fundamental problem in the RISC-V world is the extensions architecture, where each huge extension effectively holds hostage its few most valuable instructions.
For example, the base instruction set lacks the extremely valuable POPCNT instruction. You don't get it without swallowing the whole, huge B extension, which itself has not even been finalized. Likewise ROTL/ROTR, essential in hashes and crypto. Even multiplication is missing from the base set, unavailable without a lot of other stuff.
Freedom to fork is one of the great benefits of the Free Software movement. The same kind of benefits should be possible for a forked ISA.
Really, network benefits can accumulate for two or more related ISAs as well as for just one, if no corporate walled garden prevents it.
> For example, the base instruction set lacks the extremely valuable POPCNT instruction. You don't get it without swallowing the whole, huge B extension, which itself has not even been finalized.
You can make a processor implementing the RISC-V base instruction set plus standard popcnt. It won't be a full implementation of the B extension, but as long as it's 100% forward-compatible with one there no issue that I'm aware of.
You can, but this amounts to a fork of RISC-V that does not fix its numerous small but expensive design flaws. As such, it is a fork not attractive enough to evoke a compiler code-generator fork, or an FPGA implementation variant, or to attract users. That's fine for your on-off product, but does me no good.
To get all the benefits we expect from the open ISA design, we need enough network effects to amortize the work of maintaining it.
It is a fine point to choose how far to go in the fork. Too close, and it's not worth doing. Too far, and work on RISC-V doesn't help it too.
For example, a close-enough fork can be verified by demonstrating that each delta is exactly as correct as the corresponding RISC-V feature, by simple mapping.
You are talking about forking the project even though the spec is not yet finished and the project is open source and open to participation.
Instead of forking, just let the RISC-V team know what the problems are.
> Pretty comprehensive lists of small but costly design booboos have already been published.
But published by whom?
Nowadays it's a great game for all the people who think they're hardware gods to say that RISC-V has big problems.
However, most of the time this is due to a lack of understanding or knowledge of the field.
For example, the article from the man who calls himself an ARM former employee.
But he was neither a core designer nor a core architect, he was in charge of the verification of the core.
To verify a core you don't need to understand all the internal workings and why it's designed this way, you are not a core architect.
And in fact there is a lot of incomprehension in the criticism he makes.
So in order for your criticism to be valid, you must make it clear which error list you are talking about. Otherwise we just can't answer your argument.
> You don't get it without swallowing the whole, huge B extension, which itself has not even been finalized.
How is the fact that the extension is not finished a valid criticism?
In addition, extension B is currently divided into several sub-extensions Z. Including Zbb which contains the rotation, bitcnt, and some logical operation.
So RISC-V already addresses the problem you are mentioning.
> Even multiplication is missing from the base set, unavailable without a lot of other stuff.
The fact that multiplication is not in the base instruction set is a feature, not a issue.
And the fact that multiplication comes with division is indeed questionable, but a RISC-V M core can be designed without implementation of division and implement the division in software. The RISC-V spec is designed to allow trap on non-implemented instructions.
And we can tell the compiler not to use the division instruction with the flag "-mno-div" on gcc.
I think that RISC-V potentially has some small issues. But they are not that serious.
And these are none of your criticisms.
“Today Micro Magic, Inc. announced the world’s fastest 64-bit RISC-V core achieving 5GHz and 13,000 CoreMarks at 1.1V. A single Micro Magic core running at 0.8V nominal delivers 11,000 CoreMarks at 4.25GHz consuming only 200mW.
Read the full release.”
(Tip: only click that “Read the full release” link if you want to laugh or cry)
12 comments
[ 3.9 ms ] story [ 37.7 ms ] threadRISC-V has a clock speed of 5 gigahertz,
well above a recent, top-of-the-line Intel Xeon server chip, E7, running at 3.2 gigahertz.
Yet the novel RISC-V chip burns just 1 watt of power at 1.1 volts, less than one percent of the power
burned by the Intel Xeon.
[...]
"It's kind of amazing," said David Patterson, a professor at the University of California at Berkeley who helped create RISC-V, in an interview with ZDNet, describing his impression of a demo he was given of the chip recently. "I think IBM mainframes have a 5-gigahertz product that's liquid-cooled, and takes 100 watts" to run.
"I've also heard some impressive numbers around people doing
FPGAs, around 600 megahertz,"
said Patterson, referring to re-programmable chips. "For a soft core, that seems pretty fast."
[...]
Because of the simplicity of the instruction set of RISC-V, Micro Magic was able to have its chip produced using a standard silicon wafer with no special tweaking. That makes it possible to use what is called a shuttle run, where the chip is grouped together in the manufacturing process with other people's chips, on the same wafer. That can be vastly cheaper because the wafer's cost is shared among so many parties."
Why are there no other embedded processors with similar efficiency and performance? If you can get an edge through a bespoke ISA then there would be at least a few manufacturers producing such a highly efficient chip with their own proprietary ISA. Hardware companies would then try to make it work despite the proprietary ISA because the benefits are too great to pass up.
[0] https://www.eembc.org/coremark/scores.php search for Raspberry Pi 3 (exact score: 15363.93)
Since there is an upper bound of clock speeds that can be done at room temperature, and high clock speed produce tons of heat. But this article is like OMG 5GHz!!!!
[1] https://youtu.be/OuF9weSkS68?t=434
"EEMBC’s CoreMark® is a benchmark that measures the performance of microcontrollers (MCUs) and central processing units (CPUs) used in embedded systems. Replacing the antiquated Dhrystone benchmark, Coremark contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC (cyclic redundancy check). It is designed to run on devices from 8-bit microcontrollers to 64-bit microprocessors."
Maybe someone has a list of OTHER small embedded microcontrollers to compare with this processor? Still fun to see risk-v in the news again.
RISC-V embodies many unnecessarily weird and costly choices that would be easy to patch if you were not obliged to retain bitwise compatibility. At the same time, it benefits from a great deal of verification work that could itself be retargeted relatively cheaply, and applied to the forked ISA. Similarly, implementations could be forked with minimal effort, and get a very cheap performance boost. Compiler code generators would also be easy to fork.
Pretty comprehensive lists of small but costly design booboos have already been published.
Probably the biggest fundamental problem in the RISC-V world is the extensions architecture, where each huge extension effectively holds hostage its few most valuable instructions.
For example, the base instruction set lacks the extremely valuable POPCNT instruction. You don't get it without swallowing the whole, huge B extension, which itself has not even been finalized. Likewise ROTL/ROTR, essential in hashes and crypto. Even multiplication is missing from the base set, unavailable without a lot of other stuff.
Freedom to fork is one of the great benefits of the Free Software movement. The same kind of benefits should be possible for a forked ISA.
Really, network benefits can accumulate for two or more related ISAs as well as for just one, if no corporate walled garden prevents it.
You can make a processor implementing the RISC-V base instruction set plus standard popcnt. It won't be a full implementation of the B extension, but as long as it's 100% forward-compatible with one there no issue that I'm aware of.
To get all the benefits we expect from the open ISA design, we need enough network effects to amortize the work of maintaining it.
It is a fine point to choose how far to go in the fork. Too close, and it's not worth doing. Too far, and work on RISC-V doesn't help it too.
For example, a close-enough fork can be verified by demonstrating that each delta is exactly as correct as the corresponding RISC-V feature, by simple mapping.
You are talking about forking the project even though the spec is not yet finished and the project is open source and open to participation. Instead of forking, just let the RISC-V team know what the problems are.
> Pretty comprehensive lists of small but costly design booboos have already been published.
But published by whom? Nowadays it's a great game for all the people who think they're hardware gods to say that RISC-V has big problems. However, most of the time this is due to a lack of understanding or knowledge of the field. For example, the article from the man who calls himself an ARM former employee. But he was neither a core designer nor a core architect, he was in charge of the verification of the core. To verify a core you don't need to understand all the internal workings and why it's designed this way, you are not a core architect. And in fact there is a lot of incomprehension in the criticism he makes. So in order for your criticism to be valid, you must make it clear which error list you are talking about. Otherwise we just can't answer your argument.
> You don't get it without swallowing the whole, huge B extension, which itself has not even been finalized.
How is the fact that the extension is not finished a valid criticism? In addition, extension B is currently divided into several sub-extensions Z. Including Zbb which contains the rotation, bitcnt, and some logical operation. So RISC-V already addresses the problem you are mentioning.
> Even multiplication is missing from the base set, unavailable without a lot of other stuff.
The fact that multiplication is not in the base instruction set is a feature, not a issue. And the fact that multiplication comes with division is indeed questionable, but a RISC-V M core can be designed without implementation of division and implement the division in software. The RISC-V spec is designed to allow trap on non-implemented instructions. And we can tell the compiler not to use the division instruction with the flag "-mno-div" on gcc.
I think that RISC-V potentially has some small issues. But they are not that serious. And these are none of your criticisms.
It’s short:
“Today Micro Magic, Inc. announced the world’s fastest 64-bit RISC-V core achieving 5GHz and 13,000 CoreMarks at 1.1V. A single Micro Magic core running at 0.8V nominal delivers 11,000 CoreMarks at 4.25GHz consuming only 200mW.
Read the full release.”
(Tip: only click that “Read the full release” link if you want to laugh or cry)