Embedded Systems Conference
Breaking News
Newest First | Oldest First | Threaded View
<<   <   Page 6 / 7   >   >>
User Rank
Re: Why not build on OpenRISC
pattrsn   8/7/2014 9:36:45 PM
RISC-V is not following the same worn path of past instruction sets, which traditionally grow in size over time, and then compilers need to figure out how to include new instructions every year or so. 80x86 has added on average on instruction per month over its 30+ year liifetime. They kind of track Moore's Law, just not that fast.

RISC-V has a well designed integer base that will never change (RVI). The optional compressed instructions (RVC) are handled by the assembler, since there is a 1-1 mapping of every 16-bit format to the equivalent 32-bit one.

As those who read the RISC-V manual can see, we recommend people target software for RVG, which is shorthand for the following optional extensions: IMAFD (Integer, Multiply, Atomic, Single Precision Fl Pt, Double Precision Fl Pt)

Many of the other optional extensions will be done in libraries (e.g., decimal floating point).

As the tables in the technical report show, there are surprisingly few instructions that need to be added when going from 32-bit addresses to 64-bit addresses to 128-bit addresses. Basically, all the registers just get wider.

RISC-V also has a very fast unimplemented instruciton trap to user mode as well as 16-bit and 32-bit jump and link instructions that can be used by a linker to replace any unimplemented instruction with a jump and link to library code that implements the missing instruction. 

By having all this instruction planning laid out up front, we believe the complier issues are well in hand, and yet we can adapt to needs of the SoC by other leaving out what you don't need or adding extensions that you do need.

We need to prove this, but we thought about it carefully while designing RISC-V, and so we're aware of the implications of what we're doing.


User Rank
Re: Apples vs oranges comparisons...
krste   8/7/2014 9:31:18 PM
Sorry that we did not have enough space to fully describe that particular experiment. The area numbers we pulled from ARM exclude floating point and NEON, see http://www.arm.com/products/processors/cortex-a/ cortex-a5.php. Also, the RISC-V core used had TLBs, branch prediction (BTB, BHT, and return address stack), and caches designed to match the Cortex-A5 memory hierarchy. We didn't have time to strip our core down to 32-bits to match the ARM core, so unfortunately we were handicapped with the full
64-bit virtual address width in TLB/BTB/RAS, as well as in the integer regfile.

Variants of this RISC-V "Rocket" core have been fabricated multiple times in 45nm and 28nm processes, with the resulting chips booting Linux. Some variants run well over 1GHz. Some of the variants include full 64-bit IEEE-754/2008 vector floating-point units, with well over 10 GFLOPS/W energy efficiency running actual kernels (not just peak). Some of the variants are cache-coherent multicores. Other variants run below 0.5V with extremely high energy efficiency. One of our first chip publications will appear at ESSCIRC in September if you'd like to see more concrete details.

We look forward to seeing ARM publish SPEC numbers, or other open benchmark scores, for representative versions of their cores, so we can have fair and open comparisons.

To be clear, we believe ARM is a great company that has built a very productive ecosystem for SoC designers. However, there are significant markets that don't match ARM's business model and we would like to provide an alternative.

User Rank
Re: Apples vs oranges comparisons...
pattrsn   8/7/2014 9:05:37 PM
(It's fun to critcized again about RISC benchmarks; I'm feeling a wave of nostalgia. In fact, I'm playing Aerosmith in the background while writing this response.)

Rocket has caches, TLBs, FPUs, .. the whole nine yards. It boots Linux and we run SPEC2006 on it.  And by the way, it has 64-bit addresses and datapaths. Its a real computer.

We picked Cortex-A5 (even though it's just a wimpy 32-biter) because it is a single issue in order pipeline like Rocket and because, as ARM currently says on its web site :

The ARM® Cortex®-A5 processor is the smallest, lowest cost and lowest power ARMv7


Rocket is 1/2 the size, 1/2 the power, and 10% faster at the same GHz.

Should have we compared size and power to a larger ARM implementation?

We'd LOVE to get SPEC numbers for ARM. We asked our friends at ARM, and they said there are no such numbers available. We even asked them to reccommend a platform that we could do it ourselves, and they couldn't come up with one that would run SPEC2006.

Alas, only benchmark that runs on ARM that we can compare against is Dhrystone (!). 

Hennessy and I dropped the pitfall about not running Dhrystone in the 3rd edition of Computer Archtecture: A Quantiative Approach because we thought Dhrystone was dead. Apparently, Dhrystone is the Dracula of bad benchmarks.

Until we can get our hand on something that runs full Linux on ARM, it's the best we can do, as we're anxious to show off RISC-V on real programs.


rick merritt
User Rank
OS support for RISC-V
rick merritt   8/7/2014 8:36:43 PM
Wilco suggests a question: What's going on in terms of getting Android and any other OSes in RISC-V?

User Rank
Apples vs oranges comparisons...
Wilco1   8/7/2014 8:08:22 PM
"Thanks in part to the open-source Chisel hardware design system, one 64-bit RISC-V core is half the area, half the power, and faster than a 32-bit ARM core with a similar pipeline made in the identical process."

This is hardly a valid comparison. The Cortex-A5 supports fast multiplies, DSP extensions, SIMD extensions, large TLBs and caches, branch prediction, compressed instructions, hardware Java execution, security extensions, interrupt control, multi-core etc etc. The base RISC-V ISA is more similar to a Cortex-M0 which is significantly smaller and more efficient than a Cortex-A5. But like RISC-V's basic ISA it is not suitable to run eg. Android. 

It is easy to make a simple MIPS-like RISC ISA and a bare-bones CPU which appears to do well on Dhrystone. However that's hardly proof of anything. MIPS used to have various CPUs that showed that with 64-bit load/store and delayed branches you get amazing 32-bit Dhrystone scores from a simple pipeline - nice trick, just a shame that it didn't help nearly as much when running real code. Cortex-A5 actually runs Android pretty well, and I bet RISC-V with its very basic ISA won't be able to keep up.

Also this appears to be a comparison of a 5 year old widely used CPU with a simulation of an unfinished CPU. Let's compare when actual hardware is available - and instead of Dhrystone, compare with the 64-bit A53 running eg. SPEC2000.

rick merritt
User Rank
Re: RISC-V eco-system
rick merritt   8/7/2014 5:09:08 PM
@GSMD: I'd love to hear more about the status of those tailored fabrics, the open IP and I believe the computer system you are bulding with all this.

I think I am looong overdue on getting back to you about this effort.

rick merritt
User Rank
Re: RISC-V for Parallella?
rick merritt   8/7/2014 5:04:43 PM
@Andreas: I'd love to see whatever comparative results you get vs. ARM or MIPS.

rick merritt
User Rank
Re: Why not build on OpenRISC
rick merritt   8/7/2014 5:03:35 PM
@Jeremy: What's on the horizon for OpenRISC in terms of any new enhancements or commercial uses?

User Rank
RISC-V for Parallella?
adapteva   8/7/2014 1:41:25 PM

This is so cool!

What kind of use range do you see for the RISC-V?

Do you envision having variants of the architecture for different domains (like MIPS and ARM) or do you think we should move forward with a heterogeneous apporach (different ISAs/approachs for different tasks)?

btw. Love the fact that it runs on Zynq! We will give it a try on Parallella immediately.:-)




User Rank
Re: Why not build on OpenRISC
jeremybennett   8/7/2014 1:32:16 PM
Hi David,

Thanks for the quick reply. I've used it as an excuse to go off and read the V2.0 ISA spec for RISC-V instead of doing the day job :-) I see that RISC-V does have multicore support in its memory model.

OpenRISC has a core instruction set, which is stable and then various extensions around that core. We have debated the number of extension sets - there are too many at present, meaning compilers need too many multilibs to use them efficiently.

As we have found with the OpenRISC GCC implementation, combinatorial explosion of multilibs may be a challenge for RISC-V. There are a 32-bit base, 64-bit base, 128-bit base and 10 standard extensions, so a compiler potentially needs 8192 multilib variants to efficiently support all possible combinations of ISA. It is possible that some extensions will have no impact on compiled code, but the number of multilibs will still be too high, so the compiler will need to restrict itself to likely popular combinations, degrading efficiency - 15-20 multilibs is a practical limit. Alternatively the user builds a compiler just for their specific architecture, but that still puts a demand on the compiler writer to be able to juggle all the possible options (consider for example how to optimally compile a * b for all C/C++ types with all possible combinations of optional ISA extensions).

BTW, OpenRISC made delayed branches optional a few years ago. All the recent implementations (e.g. Julius Baxter's mor1kx implementations) don't have delayed branches. The online version of the OpenRISC 1000 architecture spec should reflect this.

I hope RISC-V is successful, but I would rather it focussed on forward-looking innovation in ISA development, instead of industry standardization, which is innevitably backwards looking.

<<   <   Page 6 / 7   >   >>

As data rates begin to move beyond 25 Gbps channels, new problems arise. Getting to 50 Gbps channels might not be possible with the traditional NRZ (2-level) signaling. PAM4 lets data rates double with only a small increase in channel bandwidth by sending two bits per symbol. But, it brings new measurement and analysis problems. Signal integrity sage Ransom Stephens will explain how PAM4 differs from NRZ and what to expect in design, measurement, and signal analysis.

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
Special Video Section
The LTC®6363 is a low power, low noise, fully differential ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...
The LT®3752/LT3752-1 are current mode PWM controllers ...
LED lighting is an important feature in today’s and future ...
Active balancing of series connected battery stacks exists ...
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...