Design Con 2015
Breaking News
Comments
Newest First | Oldest First | Threaded View
<<   <   Page 6 / 7   >   >>
pattrsn
User Rank
Rookie
Re: Why not build on OpenRISC
pattrsn   8/7/2014 9:36:45 PM
NO RATINGS
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.

 

krste
User Rank
Rookie
Re: Apples vs oranges comparisons...
krste   8/7/2014 9:31:18 PM
NO RATINGS
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.

pattrsn
User Rank
Rookie
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

(http://www.arm.com/products/processors/cortex-a/cortex-a5.php)

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
Author
OS support for RISC-V
rick merritt   8/7/2014 8:36:43 PM
NO RATINGS
Wilco suggests a question: What's going on in terms of getting Android and any other OSes in RISC-V?

Wilco1
User Rank
CEO
Apples vs oranges comparisons...
Wilco1   8/7/2014 8:08:22 PM
NO RATINGS
"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
Author
Re: RISC-V eco-system
rick merritt   8/7/2014 5:09:08 PM
NO RATINGS
@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
Author
Re: RISC-V for Parallella?
rick merritt   8/7/2014 5:04:43 PM
NO RATINGS
@Andreas: I'd love to see whatever comparative results you get vs. ARM or MIPS.

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

adapteva
User Rank
Manager
RISC-V for Parallella?
adapteva   8/7/2014 1:41:25 PM
NO RATINGS
David,

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.:-)

http://riscv.org/download.html#tab_#zynqfpga

Andreas

 

jeremybennett
User Rank
Rookie
Re: Why not build on OpenRISC
jeremybennett   8/7/2014 1:32:16 PM
NO RATINGS
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   >   >>


Top Comments of the Week
Flash Poll
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Max's BADASS Display: A Comedy of Errors
Max Maxfield
3 comments
Good grief -- where does the time go? I first determined to build my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display way back in the mists of time we used ...

<b><a href=Betajet">

The Circle – The Future's Imperfect in the Present Tense
Betajet
5 comments
The Circle, a satirical, dystopian novel published in 2013 by San Francisco-based writer Dave Eggers, is about a large, very powerful technology company that combines aspects of Google, ...

Martin Rowe

Make This Engineering Museum a Reality
Martin Rowe
Post a comment
Vincent Valentine is a man on a mission. He wants to make the first house to ever have a telephone into a telephone museum. Without help, it may not happen.

Rich Quinnell

Making the Grade in Industrial Design
Rich Quinnell
16 comments
As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

Special Video Section
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 ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
10:29
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...
TE Connectivity's clear-plastic, full-size model car shows ...
Why culture makes Linear Tech a winner.
Recently formed Architects of Modern Power consortium ...
Specially modified Corvette C7 Stingray responds to ex Indy ...
Avago’s ACPL-K30T is the first solid-state driver qualified ...
NXP launches its line of multi-gate, multifunction, ...
Doug Bailey, VP of marketing at Power Integrations, gives a ...
See how to ease software bring-up with DesignWare IP ...
DesignWare IP Prototyping Kits enable fast software ...
This video explores the LT3086, a new member of our LDO+ ...
In today’s modern electronic systems, the need for power ...